5.2 and 5.1

classic Classic list List threaded Threaded
70 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

5.2 and 5.1

D Burgess-4
5.2 has been around for some time. It would seem to me that many of
the packages that, I use, have made no move towards 5.2. Also Lua 5.2
does not look like it will get luajit support anytime soon.

The question I have of the seasoned Lua application authors:
Is the move to 5.2 worth the effort?


--
David Burgess

Reply | Threaded
Open this post in threaded view
|

Re: 5.2 and 5.1

Matthew Wild
On 8 April 2013 22:05, David Burgess <[hidden email]> wrote:
> 5.2 has been around for some time. It would seem to me that many of
> the packages that, I use, have made no move towards 5.2. Also Lua 5.2
> does not look like it will get luajit support anytime soon.
>
> The question I have of the seasoned Lua application authors:
> Is the move to 5.2 worth the effort?

No, you evidently have an incorrect perspective - Lua 5.1 has been
around some time. Lua 5.2 is quite young :)

There's nothing inherently wrong with 5.1, and there's nothing
amazingly attractive about 5.2. I expect the majority of people will
continue with the version they are on for some time, there are people
still using Lua 4.0 and earlier just fine.

However more and more new projects will be developed using 5.2, and
gradually it'll cover as much ground as its older brother currently
does. Just in time for 5.3 (where the # operator will always return
the value the user wants).

Make a sensible judgement for your project - if libraries you need are
5.1-only and are not easily ported, or you don't want to invest time
in it, I wouldn't be afraid of sticking with 5.1. On the other hand,
if you can use 5.2... why not go for it?

Regards,
Matthew

Reply | Threaded
Open this post in threaded view
|

Re: 5.2 and 5.1

Tomás Guisasola-2
In reply to this post by D Burgess-4
  Hi David

On Tue, 9 Apr 2013, David Burgess wrote:

> 5.2 has been around for some time. It would seem to me that many of
> the packages that, I use, have made no move towards 5.2.
  I think some (several?) packages will run well on both versions,
since the distance between them is small.  I spent some time converting
libraries last year and wrote some guidelines based on this experience:

http://lua-users.org/wiki/CompatibilityWithLuaFive

> The question I have of the seasoned Lua application authors:
> Is the move to 5.2 worth the effort?
  I was surprised how easy was to convert LuaSQL to work with
all three Lua 5.X versions.  Was really simple; no hacks :-)  Now I am
converting CGILua, since we have a great amount of code based on it.
We plan to switch versions by the end of this month (this schedule is due
to a non-technical reason) and I am really confident it will be harmless.
LuaRocks is helping a lot!

  Regards,
  Tomás
Reply | Threaded
Open this post in threaded view
|

Re: 5.2 and 5.1

Luiz Henrique de Figueiredo
In reply to this post by Matthew Wild
> if libraries you need are 5.1-only and are not easily ported

I expect that most 5.1 libraries are easily ported to 5.2, especially
if they are written in C. See this thread:
        http://lua-users.org/lists/lua-l/2012-09/msg00596.html

For 5.1 libraries written in Lua, the only difficulty will be dealing
with setfenv. Ideally this should be handled by rewritten them using the
new _ENV mechanism or using the new env arg in load. The other common
problem is the removal of the module function; it is recommended that
libraries be rewritten in the current, simpler scheme.

I thought there was a wiki page on porting 5.1 libraries to 5.2 but
I can't find it now.

Reply | Threaded
Open this post in threaded view
|

Re: 5.2 and 5.1

Paul K
Hi Luiz,

> I expect that most 5.1 libraries are easily ported to 5.2, especially
> if they are written in C. See this thread: http://lua-users.org/lists/lua-l/2012-09/msg00596.html

This is interesting. Given that there are only few functions that need to be mapped, is there a "good" way to provide a library that could work with both Lua 5.1 and Lua 5.2 run-times?

Both Linux and OSX provide a way to do dynamic symbol lookup (-undefined dynamic_lookup). It should be possible to provide "proxy" for those functions that have changed between 5.1 and 5.2 and resolve them at run time depending on the version of loaded Lua libraries.

Windows may be a bit more challenging, but could be doable too using something like this proxy DLL (http://lua-users.org/wiki/LuaProxyDllFour) using statically compiled Lua executables.

Or am I completely off with this idea?

Paul.


On Mon, Apr 8, 2013 at 5:20 PM, Luiz Henrique de Figueiredo <[hidden email]> wrote:
> if libraries you need are 5.1-only and are not easily ported

I expect that most 5.1 libraries are easily ported to 5.2, especially
if they are written in C. See this thread:
        http://lua-users.org/lists/lua-l/2012-09/msg00596.html

For 5.1 libraries written in Lua, the only difficulty will be dealing
with setfenv. Ideally this should be handled by rewritten them using the
new _ENV mechanism or using the new env arg in load. The other common
problem is the removal of the module function; it is recommended that
libraries be rewritten in the current, simpler scheme.

I thought there was a wiki page on porting 5.1 libraries to 5.2 but
I can't find it now.


Reply | Threaded
Open this post in threaded view
|

Re: 5.2 and 5.1

Luiz Henrique de Figueiredo
> This is interesting. Given that there are only few functions that need to
> be mapped, is there a "good" way to provide a library that could work with
> both Lua 5.1 and Lua 5.2 run-times?

I don't know. Even if the changes are small I keep separate versions of
my libraries.

> Both Linux and OSX provide a way to do dynamic symbol lookup (-undefined
> dynamic_lookup). It should be possible to provide "proxy" for those
> functions that have changed between 5.1 and 5.2 and resolve them at run
> time depending on the version of loaded Lua libraries.

Lua does not support binary compatibility across versions.

Reply | Threaded
Open this post in threaded view
|

Re: 5.2 and 5.1

Miles Bader-2
In reply to this post by Luiz Henrique de Figueiredo
Luiz Henrique de Figueiredo <[hidden email]> writes:
> For 5.1 libraries written in Lua, the only difficulty will be dealing
> with setfenv. Ideally this should be handled by rewritten them using the
> new _ENV mechanism or using the new env arg in load.

.... and even that maybe not so difficult... :]

When I added 5.2 support to my code, I realized I was _always_ using
load+setefenv in pairs (even when sometimes they were separated by
quite a bit of other code), although I never intentionally did so, and
that it wasn't hard to make sure the environment was available at
load-time and pass it in to load (5.1 load will just ignore it of
course).  Sometimes a little refactoring was required, but this tended
to make the code clearer anyway....

-miles

--
雨上がり に歩いて、風 柔らかい

Reply | Threaded
Open this post in threaded view
|

Re: 5.2 and 5.1

D Burgess-4
Thanks for the replies, but I think I will wait for luajit to change.

On Tue, Apr 9, 2013 at 3:20 PM, Miles Bader <[hidden email]> wrote:

> Luiz Henrique de Figueiredo <[hidden email]> writes:
>> For 5.1 libraries written in Lua, the only difficulty will be dealing
>> with setfenv. Ideally this should be handled by rewritten them using the
>> new _ENV mechanism or using the new env arg in load.
>
> .... and even that maybe not so difficult... :]
>
> When I added 5.2 support to my code, I realized I was _always_ using
> load+setefenv in pairs (even when sometimes they were separated by
> quite a bit of other code), although I never intentionally did so, and
> that it wasn't hard to make sure the environment was available at
> load-time and pass it in to load (5.1 load will just ignore it of
> course).  Sometimes a little refactoring was required, but this tended
> to make the code clearer anyway....
>
> -miles
>
> --
> 雨上がり に歩いて、風 柔らかい
>



--
David Burgess

Reply | Threaded
Open this post in threaded view
|

Re: 5.2 and 5.1

Coda Highland
You're going to be waiting a very long time, then. 5.2 isn't on
LuaJIT's roadmap at all.

/s/ Adam

On Mon, Apr 8, 2013 at 11:53 PM, David Burgess <[hidden email]> wrote:

> Thanks for the replies, but I think I will wait for luajit to change.
>
> On Tue, Apr 9, 2013 at 3:20 PM, Miles Bader <[hidden email]> wrote:
>> Luiz Henrique de Figueiredo <[hidden email]> writes:
>>> For 5.1 libraries written in Lua, the only difficulty will be dealing
>>> with setfenv. Ideally this should be handled by rewritten them using the
>>> new _ENV mechanism or using the new env arg in load.
>>
>> .... and even that maybe not so difficult... :]
>>
>> When I added 5.2 support to my code, I realized I was _always_ using
>> load+setefenv in pairs (even when sometimes they were separated by
>> quite a bit of other code), although I never intentionally did so, and
>> that it wasn't hard to make sure the environment was available at
>> load-time and pass it in to load (5.1 load will just ignore it of
>> course).  Sometimes a little refactoring was required, but this tended
>> to make the code clearer anyway....
>>
>> -miles
>>
>> --
>> 雨上がり に歩いて、風 柔らかい
>>
>
>
>
> --
> David Burgess
>

Reply | Threaded
Open this post in threaded view
|

Re: 5.2 and 5.1

steve donovan
On Tue, Apr 9, 2013 at 9:02 AM, Coda Highland <[hidden email]> wrote:
You're going to be waiting a very long time, then. 5.2 isn't on
LuaJIT's roadmap at all.

But you can compile LuaJIT to have a lot of Lua 5.2 compatibility, although without _ENV and overriding __gc for tables. I don't think Mike P regards the latter as intrinsically bad, but he will wait for his new garbage collector in 2.1 before implementing it. 


Reply | Threaded
Open this post in threaded view
|

Re: 5.2 and 5.1

Rob Kendrick-2
In reply to this post by Matthew Wild
On Mon, Apr 08, 2013 at 11:46:18PM +0100, Matthew Wild wrote:
> No, you evidently have an incorrect perspective - Lua 5.1 has been
> around some time. Lua 5.2 is quite young :)
>
> There's nothing inherently wrong with 5.1, and there's nothing
> amazingly attractive about 5.2. I expect the majority of people will
> continue with the version they are on for some time, there are people
> still using Lua 4.0 and earlier just fine.

I dare not touch it:
+++ Talker Name:            Meta Hills
+++ Version:                1.46 (14 Feb 2011) (c) Rob Kendrick (Lua 4.0)
+++ Compiled:               Mon Feb 14 11:00:18 GMT 2011 (Linux i686)
+++ Started:                Tue Jul 05 09:03:40 BST 2011
+++ Up for:                 1 year, 39 weeks, 6 days, 23 hours, 34 minutes, 55 seconds.

I've no immediate plans to move to Lua 5.2; I still maintain Lua 4.0
software, almost all my own current developments are done for 5.1.
However, I do make an effort for any extensions I write to be compatible
with 5.2 too: you never know.

For the moment, the attraction of more expressive metatables does not
overcome my function environment anxiety.

B.

Reply | Threaded
Open this post in threaded view
|

Re: 5.2 and 5.1

Miles Bader-2
In reply to this post by D Burgess-4
David Burgess <[hidden email]> writes:

> Thanks for the replies, but I think I will wait for luajit to change.

Fair enough.

The only point I wanted to make is that making an app compatible with
both 5.1 and 5.2 can be pretty easy, even for those that use
setfenv...

In many cases I suspect the pain of _not_ supporting 5.2 (user
complaints, confusion, yadayada) may be greater than the pain of
adding support.

-miles

--
Electricity, n. The cause of all natural phenomena not known to be caused by
something else.

Reply | Threaded
Open this post in threaded view
|

Re: 5.2 and 5.1

steve donovan
On Tue, Apr 9, 2013 at 10:46 AM, Miles Bader <[hidden email]> wrote:
The only point I wanted to make is that making an app compatible with
both 5.1 and 5.2 can be pretty easy, even for those that use
setfenv...

My experience matches with Miles - generally the new load() does exactly what's needed. One has to write a few compatibility functions, but then things just work.  David Manura has written a little module that bridges the gap.

As for recompiling for 5.2, it's not difficult with a few #ifdefs, especially if Lua 5.2 is compiled with the 5.1 compat flags (the default).

Many of the API issues I encountered are old 5.0-isms that have finally been dropped.



Reply | Threaded
Open this post in threaded view
|

Re: 5.2 and 5.1

Luiz Henrique de Figueiredo
> As for recompiling for 5.2, it's not difficult with a few #ifdefs,
> especially if Lua 5.2 is compiled with the 5.1 compat flags (the default).

Note that the compat flags are on by default only in the Makefile from
lua.org. If you embed Lua 5.2, you'll have to turn them on yourself. In
this case, that'll be a good time to think about what compatibility you
do want.

Reply | Threaded
Open this post in threaded view
|

Re: 5.2 and 5.1

D Burgess-4
Still thinking about it and probabaly will be for some time

On Tue, Apr 9, 2013 at 9:09 PM, Luiz Henrique de Figueiredo
<[hidden email]> wrote:
>> As for recompiling for 5.2, it's not difficult with a few #ifdefs,
>> especially if Lua 5.2 is compiled with the 5.1 compat flags (the default).
>
> Note that the compat flags are on by default only in the Makefile from
> lua.org. If you embed Lua 5.2, you'll have to turn them on yourself. In
> this case, that'll be a good time to think about what compatibility you
> do want.
>



--
David Burgess

Reply | Threaded
Open this post in threaded view
|

Re: 5.2 and 5.1

Joshua Jensen-2
In reply to this post by steve donovan
----- Original Message -----
From: steve donovan
Date: 4/9/2013 1:13 AM
On Tue, Apr 9, 2013 at 9:02 AM, Coda Highland <[hidden email]> wrote:
You're going to be waiting a very long time, then. 5.2 isn't on
LuaJIT's roadmap at all.

But you can compile LuaJIT to have a lot of Lua 5.2 compatibility, although without _ENV and overriding __gc for tables. I don't think Mike P regards the latter as intrinsically bad, but he will wait for his new garbage collector in 2.1 before implementing it. 


Someone posted an _ENV patch for LuaJIT a while back:

http://permalink.gmane.org/gmane.comp.lang.lua.luajit/1392

I've never tried it, but there you go.

-Josh
Reply | Threaded
Open this post in threaded view
|

Re: 5.2 and 5.1

steve donovan
On Tue, Apr 9, 2013 at 4:27 PM, Joshua Jensen <[hidden email]> wrote:
Someone posted an _ENV patch for LuaJIT a while back:

Somebody out there really likes _ENV!  Not my personal cup of strong caffeinated beverage, but to each their own... 
Reply | Threaded
Open this post in threaded view
|

Re: 5.2 and 5.1

Dirk Laurie-2
2013/4/9 steve donovan <[hidden email]>:

> Somebody out there really likes _ENV!  Not my personal cup of strong
> caffeinated beverage, but to each their own...

Your first upvalue is the current global table, unless you don't need it.
A name is reserved for it. Crystal-clear logic.

Being someone whose first language never was Lua 5.1 (I converted to
Luanity in November 2011, when 5.2 was already beta), I've never written
any Lua code that calls setfenv/getfenv. They feel like curious kludges
to me :-)

Reply | Threaded
Open this post in threaded view
|

Re: 5.2 and 5.1

steve donovan
On Tue, Apr 9, 2013 at 4:58 PM, Dirk Laurie <[hidden email]> wrote:
2013/4/9 steve donovan <[hidden email]>:
Your first upvalue is the current global table, unless you don't need it.
A name is reserved for it. Crystal-clear logic.

It might not be the first upvalue, depends whether a 'global' is referenced first before any other upvalues.

That's fine, always thought that function environments were _hard to explain_. (great way to evaluate a feature)

It's just that assigning _ENV to something else strikes me as magicky as module()
 

Being someone whose first language never was Lua 5.1 (I converted to
Luanity in November 2011, when 5.2 was already beta), I've never written
any Lua code that calls setfenv/getfenv. They feel like curious kludges
to me :-)


Reply | Threaded
Open this post in threaded view
|

Re: 5.2 and 5.1

Hisham
In reply to this post by Dirk Laurie-2
On 9 April 2013 11:58, Dirk Laurie <[hidden email]> wrote:

> 2013/4/9 steve donovan <[hidden email]>:
>
>> Somebody out there really likes _ENV!  Not my personal cup of strong
>> caffeinated beverage, but to each their own...
>
> Your first upvalue is the current global table, unless you don't need it.
> A name is reserved for it. Crystal-clear logic.
>
> Being someone whose first language never was Lua 5.1 (I converted to
> Luanity in November 2011, when 5.2 was already beta), I've never written
> any Lua code that calls setfenv/getfenv. They feel like curious kludges
> to me :-)

They felt that way to me even in 5.0! Well, perhaps I wouldn't say
"kludges", but they were one of those things that I always had to
double-check in the manual if I was using them right, unlike most of
the rest of the standard library, which quickly becomes second-nature.
_ENV, on the other hand, felt like second-nature from day one.

-- Hisham
http://hisham.hm/

1234