any plan about luajit2 support 5.2!

[zhiguo zhao]

Hi, Mike

   I like new feature of 5.2, I like high speed of luajit2.

   Any plan for lua2 support 5.2?

[Mike Pall-21]

zhiguo zhao wrote:
>    I like new feature of 5.2, I like high speed of luajit2.
>    Any plan for lua2 support 5.2?

Currently no.

IMHO adoption of Lua 5.2 will be rather slow. It breaks many
extension modules, it lacks any real killer features and it ain't
faster for sure. I guess 5.2 will be the 'Vista' of Lua releases.

So which features of Lua 5.2 do you really want to see in LuaJIT?
You can get most of them with add-ons for 5.1. And LuaJIT already
includes the two top features on the wishlist (bit ops and yield
everywhere).

I'm not going to start sorting out the API/ABI compatibility mess
until I see developers jumping ship in hordes. LuaJIT has a
user-base, too. And they don't like 'breaking' changes. However I
might pick individual features (like __pairs) if they are easy to
integrate and upwards-compatible. I'm open to suggestions.

--Mike

[zhiguo zhao]

Thanks.

__pairs is very useful for my extend module,  this meta can be support by lj2?

2010/11/17 Mike Pall <[hidden email]>

zhiguo zhao wrote:
>    I like new feature of 5.2, I like high speed of luajit2.
>    Any plan for lua2 support 5.2?

Currently no.

IMHO adoption of Lua 5.2 will be rather slow. It breaks many
extension modules, it lacks any real killer features and it ain't
faster for sure. I guess 5.2 will be the 'Vista' of Lua releases.

So which features of Lua 5.2 do you really want to see in LuaJIT?
You can get most of them with add-ons for 5.1. And LuaJIT already
includes the two top features on the wishlist (bit ops and yield
everywhere).

I'm not going to start sorting out the API/ABI compatibility mess
until I see developers jumping ship in hordes. LuaJIT has a
user-base, too. And they don't like 'breaking' changes. However I
might pick individual features (like __pairs) if they are easy to
integrate and upwards-compatible. I'm open to suggestions.

--Mike

[Mike Pall-21]

zhiguo zhao wrote:
> __pairs is very useful for my extend module,  this meta can be support by
> lj2?

Yes, that would be fairly easy. Same goes about __len for tables.
Anything else?

Does anyone object to adding support for this unconditionally?
I mean ... those metamethods are currently ignored, so in theory
nobody ought to have it in their metatables.

--Mike

[Valerio]

On Wed, Nov 17, 2010 at 1:19 PM, Mike Pall <[hidden email]> wrote:

> Anything else?

Empty code blocks please :-)

[steve donovan]

On Wed, Nov 17, 2010 at 2:41 PM, Valerio Schiavoni
<[hidden email]> wrote:
>> Anything else?
>
> Empty code blocks please :-)

What are these?  I thought we always could have an empty block...

steve d.

[Alex Bradbury]

On 17 November 2010 11:58, Mike Pall <[hidden email]> wrote:
> I'm not going to start sorting out the API/ABI compatibility mess
> until I see developers jumping ship in hordes. LuaJIT has a
> user-base, too. And they don't like 'breaking' changes. However I
> might pick individual features (like __pairs) if they are easy to
> integrate and upwards-compatible. I'm open to suggestions.

LuaJIT is an important part of the Lua ecosystem, so as long as it
doesn't support 5.2 that will be enough to dissuade many users from
migrating their code. Though I agree for someone who's happily using
LuaJIT or 5.1 + addons there won't be an obvious killer feature to
encourage an upgrade anyway.

Alex

[zhiguo zhao]

__pairs and __ipairs enough for me.

2010/11/17 Mike Pall <[hidden email]>

zhiguo zhao wrote:
> __pairs is very useful for my extend module,  this meta can be support by
> lj2?

Yes, that would be fairly easy. Same goes about __len for tables.
Anything else?

Does anyone object to adding support for this unconditionally?
I mean ... those metamethods are currently ignored, so in theory
nobody ought to have it in their metatables.

--Mike

[Alexander Gladysh]

> I guess 5.2 will be the 'Vista' of Lua releases.

Being 'Vista' is better than being 'Millenium' :-)

> I'm not going to start sorting out the API/ABI compatibility mess
> until I see developers jumping ship in hordes. LuaJIT has a
> user-base, too. And they don't like 'breaking' changes. However I
> might pick individual features (like __pairs) if they are easy to
> integrate and upwards-compatible. I'm open to suggestions.

Um. If I remember correctly, when the first work-version of 5.2 was
published, you said something about keeping 5.1 and 5.2 in parallel.

If there would be luajit2-5.1 and luajit2-5.2 targets, there will be
no breaking changes.

I'm really worried about LuaJIT 2 "5.1" straying further and further
away from the "language standard". I really don't want to see LuaJIT 2
as a Lua dialect. This will go bad for sure.

Please, keep 5.1 and 5.2 features separate.

Alexander.

[Mark Hamburg]

On Nov 17, 2010, at 3:58 AM, Mike Pall wrote:

> I'm not going to start sorting out the API/ABI compatibility mess
> until I see developers jumping ship in hordes. LuaJIT has a
> user-base, too. And they don't like 'breaking' changes. However I
> might pick individual features (like __pairs) if they are easy to
> integrate and upwards-compatible. I'm open to suggestions.

I'm not wild about the N-squared time complexity, but the ephemeron GC as a solution to semi-weak-table-induced collection problems is pretty useful.

Getting rid of function environments (at least as mutable properties of functions) ought to be an optimization opportunity, but I'm not writing anything that depends on that.

The messier issue for me is that working in some environments where LuaJIT isn't an option -- e.g., iOS on ARM -- I'm really attracted by the yieldable pcall support in 5.2. That then leaves me trying to figure out what to do in environments where LuaJIT is an option.

Mark

[Roberto Ierusalimschy]

> On Wed, Nov 17, 2010 at 2:41 PM, Valerio Schiavoni
> <[hidden email]> wrote:
> >> Anything else?
> >
> > Empty code blocks please :-)
>
> What are these?  I thought we always could have an empty block...

I would not call that "empty code blocks", but maybe he means empty
statements that allow free use of semicollons. For instance, the
following program is valid in 5.2, but not in 5.1:

  ;print'hi'

-- Roberto

[Alex Bradbury]

On 17 November 2010 15:34, Mark Hamburg <[hidden email]> wrote:
> The messier issue for me is that working in some environments where LuaJIT isn't an option -- e.g., iOS on ARM -- I'm really attracted by the yieldable pcall support in 5.2. That then leaves me trying to figure out what to do in environments where LuaJIT is an option.

I'm not sure I'm understanding what you're saying here. You can get
yieldable pcall with current LuaJIT, or with 5.2, or with 5.1 + CoCo
patch, or with 5.1 + RVM patch.

Alex

[Mike Pall-21]

Alexander Gladysh wrote:
> If there would be luajit2-5.1 and luajit2-5.2 targets, there will be
> no breaking changes.

Well, Lua source code is almost unaffected by the 5.2 changes (*).

Having two different targets is mainly required to handle the
Lua/C ABI breakage between 5.1 and 5.2. But until there are tons
of C extension modules that only work with 5.2, there's little
need for that. I'm not seeing that anytime soon.

(*) I guess most users won't care or won't need to know about _ENV.
    But those that do are unlikely to upgrade, as they'll have to
    ditch their sandboxing frameworks and redesign them from scratch.

> I'm really worried about LuaJIT 2 "5.1" straying further and further
> away from the "language standard". I really don't want to see LuaJIT 2
> as a Lua dialect. This will go bad for sure.

You're mixing up two things. I have no intention to diverge from
the 'Lua language' itself. But LuaJIT has always had extensions
and extra features. E.g. the JIT compiler. ;-)

And more extensions will come. I'm getting to the point where I
can check in the first part of the FFI in the next days. This will
pave the way for a slew of other features, e.g. 64 bit integers
and native complex numbers. And when the FFI is complete, you can
finally stop writing tedious C bindings (yay!).

I hope you're not suggesting I shouldn't include this feature,
just because standard Lua doesn't have it (and never will)?

> Please, keep 5.1 and 5.2 features separate.

Incompatible features will certainly get a compile-time switch.
But I'd first need to see a demonstrable need to litter the code
with #ifdef's for simple upwards-compatible features.

--Mike

[Mike Pall-21]

Mark Hamburg wrote:
> I'm not wild about the N-squared time complexity, but the
> ephemeron GC as a solution to semi-weak-table-induced collection
> problems is pretty useful.

It was already my plan to add this for the new LuaJIT GC
(postponed to 2.1).

> Getting rid of function environments (at least as mutable
> properties of functions) ought to be an optimization
> opportunity, but I'm not writing anything that depends on that.

Nope, not really. Since function environments were rarely changed,
they are treated as immutable. Similar things happen with upvalues,
since LuaJIT's alias analysis is quite good. Moving the environment
to an upvalue neither complicates things nor simplifies anything.

> The messier issue for me is that working in some environments
> where LuaJIT isn't an option -- e.g., iOS on ARM

Well, don't hold your breath. But I'm sure an ARM port will
happen.

> I'm really attracted by the yieldable pcall support in 5.2.

Alex already answered that -- you can have that feature right now
on all platforms.

--Mike

[Enrico Colombini]

On 17/11/2010 17.12, Mike Pall wrote:
> (*) I guess most users won't care or won't need to know about _ENV.
>      But those that do are unlikely to upgrade, as they'll have to
>      ditch their sandboxing frameworks and redesign them from scratch.

I always use a local copy of Lua executable + needed_libs in each
project, so changes can't break anything.

One of my projects would need to be redesigned for _ENV (it probably
will, in a distant future) but for new projects and for general
non-critical usage I think I'll upgrade to 5.2.

--
   Enrico

[Alex Bradbury]

On 17 November 2010 16:12, Mike Pall <[hidden email]> wrote:
> And more extensions will come. I'm getting to the point where I
> can check in the first part of the FFI in the next days. This will
> pave the way for a slew of other features, e.g. 64 bit integers
> and native complex numbers. And when the FFI is complete, you can
> finally stop writing tedious C bindings (yay!).

Do you envisage that this same FFI interface could be provided for
standard Lua for compatibility reasons? This would allow a library
author to primarily target LuaJIT, yet still support people using the
main Lua distribution. It's significantly easier to port an FFI to
another platform than to port LuaJIT (judging by libffi at least, I'm
not sure what your FFI includes) so those on platforms where LuaJIT is
not supported but want to use one of these future FFI-implemented
bindings would find this particularly useful.

Alex

[Mike Pall-21]

Alex Bradbury wrote:
> Do you envisage that this same FFI interface could be provided for
> standard Lua for compatibility reasons?

Unlikely. It's tightly integrated into the VM, esp. the garbage
collector.

> It's significantly easier to port an FFI to
> another platform than to port LuaJIT (judging by libffi at least, I'm
> not sure what your FFI includes)

Oooh, don't get me started about FFI portability. You'd think that
writing a C parser is tough, but the real challenge was handling
all the little platform differences (packed structs with aligned
members and bitfields, anyone?).

And I haven't even implemented the plethora of calling conventions
yet ... the first release of the FFI will only allow you to create
and use native data structures, but not call C functions (yet).
Already quite useful and helps on benchmarks, too. ;-)

> [...] so those on platforms where LuaJIT is not supported [...]

I'm sure this will be resolved over time. After x86/x64, PPC, ARM
and MIPS -- what's left? And I mean platforms suitable for a
dynamic language with a JIT compiler _and_ with some outlook for
the future plus a market share to speak of.

[Platforms which prohibit runtime code-generation can still
benefit from the faster LuaJIT interpreter. E.g. the PPC/e500 port
of the LuaJIT interpreter is complete now. It outruns the Lua
interpreter by a factor of 2x - 4x and in some cases up to 6x.
The sponsor is rather happy with this performance.]

--Mike

[Alex Bradbury]

On 17 November 2010 17:12, Mike Pall <[hidden email]> wrote:
> Oooh, don't get me started about FFI portability. You'd think that
> writing a C parser is tough, but the real challenge was handling
> all the little platform differences (packed structs with aligned
> members and bitfields, anyone?).

Ah, it seems I've misunderstood the scope of your FFI. I was imagining
something like Python ctypes or Lua alien, but JIT-aware and with
better support for native data structures. I didn't realise that (if I
understood you correctly) you've implemented a C parser as well. I'll
be watching the git repository with great interest.

Alex

[Leo Razoumov]

On Wed, Nov 17, 2010 at 06:58, Mike Pall <[hidden email]> wrote:
> zhiguo zhao wrote:
>>    I like new feature of 5.2, I like high speed of luajit2.
>>    Any plan for lua2 support 5.2?
>
> Currently no.
>
> IMHO adoption of Lua 5.2 will be rather slow. It breaks many
> extension modules, it lacks any real killer features and it ain't
> faster for sure. I guess 5.2 will be the 'Vista' of Lua releases.

I think more accurate comparison would be this:

Lua-5.2 is to Lua-5.1 what Python-3.x is to Python-2.x :-)

IMHO, two killer features that are missing from Lua-5.2 are:

(1) "continue" statement
(2) LPEG has not been merged in.

For now I am sticking with Lua-5.1.x.

--Leo--

[Petri Häkkinen]

On 17.11.2010, at 18.12, Mike Pall wrote:
> And more extensions will come. I'm getting to the point where I
> can check in the first part of the FFI in the next days. This will
> pave the way for a slew of other features, e.g. 64 bit integers
> and native complex numbers. And when the FFI is complete, you can
> finally stop writing tedious C bindings (yay!).

This is extremely interesting!

Have you considered adding support for native 2d/3d/4d vector types? I think this would make many game developers including me very happy. Allocating and garbage collecting hundreds or even thousands of temp vectors created each frame is currently a waste of precious CPU cycles.

Petri