Changelog for 5

classic Classic list List threaded Threaded
93 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

Changelog for 5

Ben Woodhead
Hello Everybody

Been a long time since I looked at lua and I am wondering what the changes
are in 5. Is there a changelog somewere, or any hit as to how close we are
getting to a release and most importantly is there anything for c++ users.

Ben




Reply | Threaded
Open this post in threaded view
|

Re: Changelog for 5

Szabolcs Szasz
> Been a long time since I looked at lua and I am wondering what the changes
> are in 5. Is there a changelog somewere, or any hit as to how close we are
> getting to a release and most importantly is there anything for c++ users.
> 
> Ben


> I know this is asked a lot, but what are the actual differences for 
> Lua5?  If you go to the Web page there aren't many links or 
> discussion on 5 that are authoritative, and being on this list I kind 
> of get lost between the "would be nice", "is going in", "is being 
> removed" and "we're thinking about it" discussions =)
> 
> It would be nice if the distribution had a download page that talks 
> about the changes.  Right now if you click on the link you're 
> immediately given a .tar.gz to download.
> 
> Brian


Let me join you in this...

Sab


Reply | Threaded
Open this post in threaded view
|

Re: Changelog for 5

Martin Spernau
A quick search through the archives :
http://lua-users.org/cgi-bin/namazu.cgi?query=lua+5+changes&sort=score&idxna
me=lua-l&max=20
gives some very good strting points
(Lua 5 beta announcement, Lua 5 alpha announcement)
Top starting point micht be:

a.. changes (not incompatibilities) to Lua 5.0 beta
http://lua-users.org/lists/lua-l/2002-11/msg00153.html

-Martin
----- Original Message -----
From: "Szabolcs Szasz" <[hidden email]>
To: "Multiple recipients of list" <[hidden email]>
Sent: Monday, March 03, 2003 11:04 PM
Subject: Re: Changelog for 5


> > Been a long time since I looked at lua and I am wondering what the
changes
> > are in 5. Is there a changelog somewere, or any hit as to how close we
are
> > getting to a release and most importantly is there anything for c++
users.
> >
> > Ben
>
>
> > I know this is asked a lot, but what are the actual differences for
> > Lua5?  If you go to the Web page there aren't many links or
> > discussion on 5 that are authoritative, and being on this list I kind
> > of get lost between the "would be nice", "is going in", "is being
> > removed" and "we're thinking about it" discussions =)
> >
> > It would be nice if the distribution had a download page that talks
> > about the changes.  Right now if you click on the link you're
> > immediately given a .tar.gz to download.
> >
> > Brian
>
>
> Let me join you in this...
>
> Sab
>



Reply | Threaded
Open this post in threaded view
|

Re: Changelog for 5

Brian Hook-2
>A quick search through the archives : http://lua-users.org/cgi-
>bin/namazu.cgi?query=lua+5+changes&sort=score&idxna me=lua-l&max=20
>gives some very good strting points (Lua 5 beta announcement, Lua 5
>alpha announcement) 

Agreed, but that means that someone really has to know about the 
mailing list and be willing to search it and build up a gestalt 
understanding of the changes and differences based on multiple 
threads.

A simple summary would seem to be easy for someone "in the know" to 
put together and simply put on a page with a link to the actual 
download.

Brian



Reply | Threaded
Open this post in threaded view
|

Re: Changelog for 5

Ben Woodhead
In reply to this post by Martin Spernau
Hello Everybody

Thanks for the responces. I had looked around the site but didn't think to
look at the lua-user stuff. So there is no Changelog to be found. I will
look threw all the mail.

Thanks, Ben





Reply | Threaded
Open this post in threaded view
|

Re: Changelog for 5

Szabolcs Szasz
> Thanks for the responces. I had looked around the site but didn't think to
> look at the lua-user stuff. So there is no Changelog to be found. I will
> look threw all the mail.
>
> Thanks, Ben

Could you also post the summary of what 
you'd have found on the list, please?

Thanks,
Sab

Reply | Threaded
Open this post in threaded view
|

Re: Changelog for 5

Roberto Ierusalimschy
In reply to this post by Szabolcs Szasz
Quick list of changes from 4.0  to 5.0:

- coroutines
- lexical scoping
- metatables (x tags)
- weak tables
- generic for
- proper tail call
- boolean type
- new way to handle userdata in the C API (+ light userdata)
- new way to handle errors in the C API
- new functions (time/date, tmpfile, unpack, require, load*, )
- block comments  --[[...]]
- still faster
- better error messages


Quick list of changes from 5.0 beta to final:

- no-nonsense debug info about tail calls
- correct implementation for comparison metamethods
- getn/setn in lauxlib
- two new debug functions to manipulate upvalues
- string.byte returns nil for index out-of-range
- "require" returns value returned by package
- get/setglobals renamed to get/setfenv ("function environment")


-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: Changelog for 5

Brian Hook-2
Thanks Roberto.  Is there a quick list of "things that no longer 
work"?

Thanks,

Brian



Reply | Threaded
Open this post in threaded view
|

Bitflags

Brian Hook-2
In reply to this post by Roberto Ierusalimschy
I know this topic comes up every now and then, but I still haven't 
seen a succinct summary of it -- but basically fast bit flags don't 
seem possible with Lua, which somewhat limits it as a scripting 
language for a project I'm working on.

The key issue is that Lua doesn't have an integer type and the 
associate bit twiddling operators.  I'm assuming that this has been 
shot down numerous times as bad, so what are people doing in the 
interim to address this?

Thanks,

Brian



Reply | Threaded
Open this post in threaded view
|

Re: Bitflags

Asko Kauppi-3

I'm using BitAnd(a,b,...) etc. for SDL interface. Not nice but..

For me, the speed issue is not so decisive as the fact that any such function name usage clubbers the code and makes it harder to read. Yes, I do miss the '&', '|' etc. operators in Lua. But one can't have all? :)

-ak


Brian Hook kirjoittaa tiistaina, 4. maaliskuuta 2003, kello 01:31:

I know this topic comes up every now and then, but I still haven't
seen a succinct summary of it -- but basically fast bit flags don't
seem possible with Lua, which somewhat limits it as a scripting
language for a project I'm working on.

The key issue is that Lua doesn't have an integer type and the
associate bit twiddling operators.  I'm assuming that this has been
shot down numerous times as bad, so what are people doing in the
interim to address this?

Thanks,

Brian




Reply | Threaded
Open this post in threaded view
|

Re: Changelog for 5

John Belmonte-2
In reply to this post by Ben Woodhead
Ben Woodhead wrote:
Hello Everybody

Been a long time since I looked at lua and I am wondering what the changes
are in 5. Is there a changelog somewere, or any hit as to how close we are
getting to a release and most importantly is there anything for c++ users.

This page was burried on the wiki:

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


-John




--
http:// if   l .   /


Reply | Threaded
Open this post in threaded view
|

Re: Changelog for 5

Nick Davies
In reply to this post by Roberto Ierusalimschy
> Quick list of changes from 4.0  to 5.0:
>
> [...]
> - better error messages

Ah, yes, the elusive error messages.

Quite often, my program will simply quit after a call to lua_call() without
giving any sort of error message, and it's usually(i.e. always) due to some
mistake I made in lua files(such as trying to access an entry in a table
that doesn't exist). I assume that I'm doing things wrong here - how do I
get error messages from Lua to appear so that I can see what's going on
instead of relying on trial and error?

Thanks in advance,
~Nick



Reply | Threaded
Open this post in threaded view
|

Re: Changelog for 5

Terence Martin-2
Quoting Nick Davies <[hidden email]>:
If I remember correctly, what you want is lua_pcall and not
lua_call. pcall runs the code "protected", so that it can
catch errors. If you don't do that, the error handleer just
exits out.

What I can't remember is if the error messages get displayed
for you, or if they get returned on the stack and you have
to print them yourself.

> Quite often, my program will simply quit after a call to
> lua_call() without
> giving any sort of error message, and it's usually(i.e.
> always) due to some
> mistake I made in lua files(such as trying to access an
> entry in a table
> that doesn't exist). I assume that I'm doing things wrong
> here - how do I
> get error messages from Lua to appear so that I can see
> what's going on
> instead of relying on trial and error?
> 
> Thanks in advance,
> ~Nick
> 
> 
> 





Reply | Threaded
Open this post in threaded view
|

Capturing lua errors (was: Changelog for 5)

Kelvin McDowell
In reply to this post by Nick Davies
Error messages are returned on the stack.  Here's the code I use with beta 5
for my console, which compiles and executes a string.  LoadS and getS are
taken from code supplied with the lua distribution.  You can replace with
your own code if reading from a file.  Assumes that you've already created a
lua_State with lua_open

// scripting
lua_State * g_luastate = 0;

// taken from lua distribution
typedef struct LoadS
{
    const char *s;
    size_t size;
} LoadS;

// taken from lua distribution
static const char *getS (lua_State *L, void *ud, size_t *size)
{
    LoadS *ls = (LoadS *)ud;
    (void)L;
    if (ls->size == 0) return NULL;
    *size = ls->size;
    ls->size = 0;
    return ls->s;
}

// called whenever a line is input into the console
virtual void EventInput( const char * input )
{
    LoadS ls;
    ls.s = input;
    ls.size = strlen(input);

    int status;

    // compile string
    status = lua_load( g_luastate, getS, &ls, "console" );

    switch( status )
    {
    case 0: // no errors
        break;

    case LUA_ERRSYNTAX:
    case LUA_ERRMEM:
    default:
        console->stream() << "compile: " << lua_tostring( g_luastate, 1 );
// print error message
        lua_settop( g_luastate, 0 );
        return;
    }

    // execute bytecode
    status = lua_pcall( g_luastate, 0, LUA_MULTRET, 0 );

    switch( status )
    {
    case 0: // no errors;
        break;

    case LUA_ERRRUN:
    case LUA_ERRMEM:
    case LUA_ERRERR:
    default:
        console->stream() << "run: " << lua_tostring( g_luastate, 1 );    //
print error message
        lua_settop( g_luastate, 0 );
        return;
    }
}

----- Original Message -----
From: "Nick Davies" <[hidden email]>
To: "Multiple recipients of list" <[hidden email]>
Sent: Monday, March 03, 2003 6:44 PM
Subject: Re: Changelog for 5


> > Quick list of changes from 4.0  to 5.0:
> >
> > [...]
> > - better error messages
>
> Ah, yes, the elusive error messages.
>
> Quite often, my program will simply quit after a call to lua_call()
without
> giving any sort of error message, and it's usually(i.e. always) due to
some
> mistake I made in lua files(such as trying to access an entry in a table
> that doesn't exist). I assume that I'm doing things wrong here - how do I
> get error messages from Lua to appear so that I can see what's going on
> instead of relying on trial and error?
>
> Thanks in advance,
> ~Nick
>
>


Reply | Threaded
Open this post in threaded view
|

RE: Bitflags

John Passaniti-4
In reply to this post by Brian Hook-2
> I know this topic comes up every now and then,
> but I still haven't seen a succinct summary of
> it -- but basically fast bit flags don't seem
> possible with Lua, which somewhat limits it
> as a scripting language for a project I'm
> working on.

It shouldn't limit you at all.

Yes, doing bit manipulation in Lua is painfully slow.  You can speed it up
by using tables that precompute the values of the operations you care about.
For example, here's a table that lets you AND two nybbles:

nybbleAnd = {
    [0] = {[0]=0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0},
    [1] = {[0]=0,1,0,1,0,1,0,1,0,1,0,1,0,1,0,1},
    [2] = {[0]=0,0,2,2,0,0,2,2,0,0,2,2,0,0,2,2},
    [3] = {[0]=0,1,2,3,0,1,2,3,0,1,2,3,0,1,2,3},
    [4] = {[0]=0,0,0,0,4,4,4,4,0,0,0,0,4,4,4,4},
    [5] = {[0]=0,1,0,1,4,5,4,5,0,1,0,1,4,5,4,5},
    [6] = {[0]=0,0,2,2,4,4,6,6,0,0,2,2,4,4,6,6},
    [7] = {[0]=0,1,2,3,4,5,6,7,0,1,2,3,4,5,6,7},
    [8] = {[0]=0,0,0,0,0,0,0,0,8,8,8,8,8,8,8,8},
    [9] = {[0]=0,1,0,1,0,1,0,1,8,9,8,9,8,9,8,9},
    [10] = {[0]=0,0,2,2,0,0,2,2,8,8,10,10,8,8,10,10},
    [11] = {[0]=0,1,2,3,0,1,2,3,8,9,10,11,8,9,10,11},
    [12] = {[0]=0,0,0,0,4,4,4,4,8,8,8,8,12,12,12,12},
    [13] = {[0]=0,1,0,1,4,5,4,5,8,9,8,9,12,13,12,13},
    [14] = {[0]=0,0,2,2,4,4,6,6,8,8,10,10,12,12,14,14},
    [15] = {[0]=0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15}
}

Of course, this is insane.

The answer here is the punch line to the old joke "Doctor, it hurts when I
do this."  If something is painful to do in Lua, then don't do it in Lua!
Extend Lua with the functionality you want-- it's easy, and it's fun.  For
bit manipulation, you can extend Lua with the bitlib library that I
originally wrote and Reuben Thomas nicely improved.  I Googled and found a
link at http://www.mupsych.org/~rrt/Lua

I have mixed feelings about Lua not including such a library natively.  On
the one hand, bit manipulation is such a common operation that it should be
part of Lua.  On the other, part of the appeal of Lua is that the language
doesn't have a lot of fluff.  Lua is (to me at least) best thought of as a
framework for creating application-specific languages.  It provides the bare
essentials, and you build up from that.  It's the same kind mindset behind
languages like Forth, where the core language doesn't provide everything
"out of the box," but does provide what you need to extend the language as
necessary for your application.

> The key issue is that Lua doesn't have an integer
> type and the associate bit twiddling operators.
> I'm assuming that this has been shot down numerous
> times as bad, so what are people doing in the
> interim to address this?

As the bitlib shows, you don't need an integer type in Lua to do bit
manipulation.  It might have been more efficient if Lua provided an integer
type, but that would add complexity to the language that doesn't need to be
there.



Reply | Threaded
Open this post in threaded view
|

RE: Bitflags

Brian Hook-2
Sorry, can't pass up some snitty comments =)

>I have mixed feelings about Lua not including such a library
>natively.  On the one hand, bit manipulation is such a common
>operation that it should be part of Lua.  On the other, part of the
>appeal of Lua is that the language doesn't have a lot of fluff.  

Bit manipulation would seem to be, honestly, to be the complete 
counter-definition of "fluff".  Integers and bits, these are the 
fundamental building blocks of, um, everything.

>As the bitlib shows, you don't need an integer type in Lua to do bit
>manipulation.  It might have been more efficient if Lua provided an
>integer type, but that would add complexity to the language that
>doesn't need to be there.

It's hard for me to really reconcile the above statement and then the 
list of Lua's other features and think "yeah, thank goodness there 
are no integers and bit operations, those are heavyweight and aren't 
used a lot"

I kid, I kid.  Well, I don't kid really, but I jest.  I respect Lua 
and the team, this is just something that recently bit me in the ass 
trying to port some C code to Lua, and the C code is rather 
performance intensive and requires lots of bit manipulation.  Enough 
that this is a bottleneck.

Unfortunately, it's not structured such that I can just isolate it as 
a native function either.  

I'll survive, I'm sure =)

Thanks,

Brian



Reply | Threaded
Open this post in threaded view
|

Re: Changelog for 5

Brian Hook-2
In reply to this post by John Belmonte-2
>http://lua-users.org/wiki/LuaFiveFeatures

Anyone know how up to date that page is?  The early comments were 
"this is what we're planning", so it stands to reason that since it 
will be released fairly soon that specific details are available now?

Brian



Reply | Threaded
Open this post in threaded view
|

Re: Bitflags

Peter Hill-2
In reply to this post by Brian Hook-2
>>I have mixed feelings about Lua not including such a library
>>natively.  On the one hand, bit manipulation is such a common
>>operation that it should be part of Lua.  On the other, part of the
>>appeal of Lua is that the language doesn't have a lot of fluff.

Brian Hook
> Sorry, can't pass up some snitty comments =)
> Bit manipulation would seem to be, honestly, to be the complete
> counter-definition of "fluff".  Integers and bits, these are the
> fundamental building blocks of, um, everything.

Bits make up everything and are fundamental, while hash-keyed tables are far
from machine level. Yet Lua rates Tables as fundamental building blocks and
not bits. Why? Because it is a 'high level' language (ie, it adds a level of
abstraction).

How fundamental are Tables? EVERY Lua program uses them... you won't be able
to go more than a few lines before you see one being accessed.

What about Bits? Most programs have no need for them so they can hardly be
considered as 'fundamental' from a Lua point of view. Why clutter up the
memory with a feature perhaps 1 in 1000 programs might use? If you are doing
something that relates to the low level machine then add some C functions to
handle it.

> I kid, I kid.  Well, I don't kid really, but I jest.  I respect Lua
> and the team, this is just something that recently bit me in the ass
> trying to port some C code to Lua, and the C code is rather
> performance intensive and requires lots of bit manipulation.  Enough
> that this is a bottleneck.
>
> Unfortunately, it's not structured such that I can just isolate it as
> a native function either.
>
> I'll survive, I'm sure =)

Despite what I said above it might be nice if Lua added a few more
(metatable trapable) infix & prefix function miscellaneous symbols for
people to use (eg, "|", "&", "!"), even if they don't have any direct Lua
meaning. Otoh, I guess it's best to save symbols for when they might be
needed!

*cheers*
Peter Hill.



Reply | Threaded
Open this post in threaded view
|

Re: Bitflags

Wim Couwenberg-2
In reply to this post by Brian Hook-2
Hi,

> so what are people doing in the
> interim to address this?

To test a single flag bit I once used the following (Lua 4 code, mod moved
to math.mod in Lua 5):

function testflag(x, n)  -- n should be a power of 2
    return mod(x, 2*n) >= n
end

Making mod an upvalue speeds things up slightly:

do
    local mod = mod
    function testflag(x, n)  -- n should be a power of 2
        return %mod(x, 2*n) >= n
    end
end

Bye,
Wim



Reply | Threaded
Open this post in threaded view
|

Re: Bitflags

Ignacio Castaño
In reply to this post by Peter Hill-2
Peter Hill wrote: 
> Despite what I said above it might be nice if Lua added a few more
> (metatable trapable) infix & prefix function miscellaneous symbols for
> people to use (eg, "|", "&", "!"), even if they don't have any direct Lua
> meaning. Otoh, I guess it's best to save symbols for when they might be
> needed!

Agreed. Having metamethods for those symbols would be really usefull to
extend the language with ease.

Ignacio Castaño
[hidden email]


___________________________________________________
Yahoo! Móviles
Personaliza tu móvil con tu logo y melodía favorito 
en http://moviles.yahoo.es

12345