[ANNOUNCE] Lua 5.0 (work0)

classic Classic list List threaded Threaded
29 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[ANNOUNCE] Lua 5.0 (work0)

Luiz Henrique de Figueiredo
A snapshot of Lua 5.0 (work) is now available at
	http://www.tecgraf.puc-rio.br/lua/work/lua-5.0-work0.tar.gz

I'll post later a precise list of what is new.

No manual is available yet. We're working on it. Also, the examples in test/
have not been updated but they should run if you first load compat.lua.
A new feature in lua.c is that you can do this automatically by setting
the environment variable LUA_INIT to "@compat.lua".

Like the others work versions, none of the changes is definitive. This is
simply a work version that is being made available so that you can experiment
with it and send us your feedback.

Enjoy.
--lhf

Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCE] Lua 5.0 (work0)

Roberto Ierusalimschy
Here is a list of changes in 5.0w0. Probably I will forget some of them,
or list some which were already present in 4.1w4...


- the biggest change is the packing of the standard libraries into tables.
We changed the names of some of them ('string', 'table'), but we could
not think of good long names for the 'io' and the 'os' libraries...


- all "tag method" names are prefixed with '__'


- As several people complained about the global statement (saying it was
too complex, the worst sin for us ;-), we removed it. We are thinking
now in a much simpler mechanism (not yet implemented). It would be more
or less equivalent to

  global in exp

That is, each function can have its "own" global table. When several
functions share the same global table we have a namespace. With
that mechanism, it is much easier to apply tag methods to those
tables, as they only affect the respective module, and not the whole
program. Therefore, each module could decide whether it wants forced
declarations, declarations only for writing, what to import, etc.


- we introduced a new tag method, __newindex, called when we insert a
new key into a table (that is, when we do "t[x]=y" and the old value of
"t[x]" was nil).


- we did some changes in the way chunks are loaded. The core now has only
one "lua_load" function, that gets a "reader" function as argument. Then
auxlib defines the usual luaL_loadfile and luaL_loadbuffer. As a result,
the core now does not use "stdio.h" for anything, except for a single
use of sprintf to convert numbers to strings. (Yes, we also removed all
other uses of sprintf, as now Lua has its own simplified version of
sprintf, where we don't have to worry about memory.)


- we introduced the lightweight userdata, a simple "void *" without
a metatable.


- we are changing some things in error handling. Now, errors are not
printed, but returned, so the caller decides what to do with them. The
"call" function is being replaced by "pcall" (protected call):
"pcall(f, a, b, c)" calls "f(a,b,c)", and returns true plus all returns
from f, or in case of any error, false plus the error message.
(Actually the error value, as the error "message" don't have to be
a string.) The details are still fluid, particularly about the
_ERRORMESSAGE (its work cannot be done after the function returns,
as by then the stack is gone).


- we changed the generic for, so that now it handles a state.

       for var_1, ..., var_n in explist do block end

is equivalent to

       do
         local _f, _s, var_1 = explist
         local var_2, ..., var_n
         while 1 do
           var_1, ..., var_n = _f(_s, var_1)
           if var_1 == nil then break end
           block
         end
       end

So, a call like

  for i,k in nexti{'a','b','c'} do print(k) end

creates no objects. (The name 'nexti' is weird, but the function shows
the idea.) The "usual" for is simply

  for k,v in next,t do ... end

although the old "for k,v in t do ... end" still works.


- we introduced "block comments", --[[ ... ]]


- lua.c now runs the environment variable LUA_INIT, if present. It can
be "@filename", to run a file, or the chunk itself.

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCE] Lua 5.0 (work0)

Eric Tetz-2
--- Roberto Ierusalimschy <[hidden email]> wrote:
> We changed the names of some of them ('string', 'table'), but we could
> not think of good long names for the 'io' and the 'os' libraries...

For the 'os' namespace, several languages use 'system'. Not that I dislike 'os', I prefer short
namespace names.

Personally, I think splitting the Lua's tiny library up into all these different namespaces is
overkill.  C++'s standard library dwarfs Lua's, and it does just fine with one namespace (std).
The most important thing is getting the library out of the user's namespace. I think one 'lua'
namespace would have been more than enough, and would have kept the namespace moniker short and
sweet (and impossible to forget). 

Cheers,
Eric

__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCE] Lua 5.0 (work0)

Russell Y. Webb
> From: Eric Tetz <[hidden email]>
> Subject: Re: [ANNOUNCE] Lua 5.0 (work0)
> 
>[...]
> The most important thing is getting the library out of the user's namespace. I
> think one 'lua'
> namespace would have been more than enough, and would have kept the namespace
> moniker short and
> sweet (and impossible to forget).
> 
> Cheers,
> Eric

I agree.  That way it's also clear what's in the standard distribution and
what's not.  

Russ


Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCE] Lua 5.0 (work0)

Thatcher Ulrich
In reply to this post by Eric Tetz-2
On Jun 06, 2002 at 02:10 -0700, Eric Tetz wrote:
> --- Roberto Ierusalimschy <[hidden email]> wrote:
> > We changed the names of some of them ('string', 'table'), but we could
> > not think of good long names for the 'io' and the 'os' libraries...
> 
> For the 'os' namespace, several languages use 'system'. Not that I
> dislike 'os', I prefer short namespace names.
> 
> Personally, I think splitting the Lua's tiny library up into all
> these different namespaces is overkill.  C++'s standard library
> dwarfs Lua's, and it does just fine with one namespace (std).  The
> most important thing is getting the library out of the user's
> namespace. I think one 'lua' namespace would have been more than
> enough, and would have kept the namespace moniker short and sweet
> (and impossible to forget).

I think it's nice that io & os are separate from the others at least,
because those are ones that many apps will want to exclude from their
embedded Lua (for security).  I think it makes that situation clearer
-- easier to describe, document & understand.

-- 
Thatcher Ulrich
http://tulrich.com

Reply | Threaded
Open this post in threaded view
|

RE: [ANNOUNCE] Lua 5.0 (work0)

Peter Prade
In reply to this post by Luiz Henrique de Figueiredo
> A snapshot of Lua 5.0 (work) is now available at
> 	http://www.tecgraf.puc-rio.br/lua/work/lua-5.0-work0.tar.gz

i am having problems downloading it from there (Forbidden - You don't have
permission to access /lua/work/lua-5.0-work0.tar.gz on this server.)

any mirrors?

Cheers,
Peter


Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCE] Lua 5.0 (work0)

Alex Bilyk
Same here:( I am adding LUA to our application this Monday. Would be nice to
have a look at version 5w0.

AB
----- Original Message -----
From: "Peter Prade" <[hidden email]>
To: "Multiple recipients of list" <[hidden email]>
Sent: Saturday, June 08, 2002 4:02 PM
Subject: RE: [ANNOUNCE] Lua 5.0 (work0)


> > A snapshot of Lua 5.0 (work) is now available at
> > http://www.tecgraf.puc-rio.br/lua/work/lua-5.0-work0.tar.gz
>
> i am having problems downloading it from there (Forbidden - You don't have
> permission to access /lua/work/lua-5.0-work0.tar.gz on this server.)
>
> any mirrors?
>
> Cheers,
> Peter
>
>


Reply | Threaded
Open this post in threaded view
|

RE: [ANNOUNCE] Lua 5.0 (work0)

Luiz Henrique de Figueiredo
In reply to this post by Luiz Henrique de Figueiredo
>> A snapshot of Lua 5.0 (work) is now available at
>> 	http://www.tecgraf.puc-rio.br/lua/work/lua-5.0-work0.tar.gz
>
>i am having problems downloading it from there (Forbidden - You don't have

The server went down but is up now.

>any mirrors?

No, sorry.
--lhf

Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCE] Lua 5.0 (work0)

Peter Shook-5
In reply to this post by Roberto Ierusalimschy
I like the new nexti function and the stateful for loops, but is there a 
simpler way than this to read the lines from a file:

    local f = io.open(file,'r')
    for line in function() return f:read() end do
        print(line)
    end
    f:close()

If I use "for line in f.read, f do print(line) end", then the call to read 
gets the variable 'line' passed to it and it complains.

just curious,

- Peter


Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCE] Lua 5.0 (work0)

Roberto Ierusalimschy
> but is there a simpler way than this to read the lines from a file:
> [...]

I think a good solution would be something like

  function lines (filename)
    local f = assert(io.open(filename, "r"))
    return function ()
      return f:read() or (assert(f:close()) and nil)
    end
  end

so that we could use it without any other "preparation":

  for line in lines(file) do ... end

But I'm not sure whether such function belongs to the `io' lib or to
some extension library.

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCE] Lua 5.0 (work0)

Peter Shook-5
Very nice.

I particularly like the way the open, close, and error checking baggage are 
all wrapped up and tucked away into one function.

No need to add this to the 'io' lib.  The user may want to customize it to 
make the error messages more verbose, or add another 'for' loop to handle a 
list of files like Perl's magical  while( <> ).

Thanks,

- Peter

On Wednesday 12 June 2002 08:18, Roberto wrote:
> I think a good solution would be something like
>
>   function lines (filename)
>     local f = assert(io.open(filename, "r"))
>     return function ()
>       return f:read() or (assert(f:close()) and nil)
>     end
>   end
>
> so that we could use it without any other "preparation":
>
>   for line in lines(file) do ... end
>
> But I'm not sure whether such function belongs to the `io' lib or to
> some extension library.
>
> -- Roberto

Reply | Threaded
Open this post in threaded view
|

Lua state as a C++ class ...

Alex Bilyk
I have wrapped lua_State into a C++ class such that one can say

cLuaState ls;
ls.Open(100);
ls.PushNumber(3.14);
ls.SetGlobal("PI");
ls.DoString("print(PI)")
ls.Close();
etc.

However, I had to add a field to lua_State in order to be able to get to my
cLuaState from registered application functions written in C++. Needless to
say the function prototype had to change as well, as I had to hide lua_State
itself from the outside world completely. So my prototype looks something
like this

typedef (*tCFunction)(cLuaState::Context context);

Has anybody done this without making any changes to original LUA code? Not a
big deal just wondering:)

Thank you,
AB


Reply | Threaded
Open this post in threaded view
|

Re: Lua state as a C++ class ...

Daniel Silverstone
On Thu, Jun 13, 2002 at 02:13:27AM -0700, Alex Bilyk wrote:
> Has anybody done this without making any changes to original LUA code? Not a
> big deal just wondering:)

If you're using the STL in your code, then you could add the following...

class cLuaState {
.....
public:
  static cLuaState* GetStateFromLuaState( lua_State *L );
private:
  static std::map< lua_State*, cLuaState* > myStateMap;
};

Then manage creating/deleting entries in myStateMap in your constructor and
desstructors, and write a body for GetStateFromLuaState such that you can
have something like:

int myLuaFunction( lua_State *L ) {
  cLuaState* myStatePtr = cLuaState::GetStateFromLuaState( L );
  .....
}

I know this is terse, but I've not played with the STL in a while, so I
can't easily rattle off the incantations for managing the map :)

D.

-- 
Daniel Silverstone                               http://www.digital-scurf.org/
Hostmaster, Webmaster, and Chief Code Wibbler          Digital-Scurf Unlimited
GPG Public key available from keyring.debian.org               KeyId: 20687895
You will be a winner today.  Pick a fight with a four-year-old.

Reply | Threaded
Open this post in threaded view
|

RE: Lua state as a C++ class ...

Nick Trout-4
In reply to this post by Alex Bilyk
> I have wrapped lua_State into a C++ class such that one can say
> 
> cLuaState ls;
> ls.Open(100);
> ls.PushNumber(3.14);
> ls.SetGlobal("PI");
> ls.DoString("print(PI)")
> ls.Close();
> etc.
> 
> However, I had to add a field to lua_State in order to be 
> able to get to my
> cLuaState from registered application functions written in 
> C++. Needless to
> say the function prototype had to change as well, as I had to 
> hide lua_State
> itself from the outside world completely. So my prototype 
> looks something
> like this

Could you not just derive your state from Luas state struct and downcast?
Have I missed the point?


Reply | Threaded
Open this post in threaded view
|

Re: Lua state as a C++ class ...

Alex Bilyk
In reply to this post by Daniel Silverstone
> On Thu, Jun 13, 2002 at 02:13:27AM -0700, Alex Bilyk wrote:
> > Has anybody done this without making any changes to original LUA code?
Not a
> > big deal just wondering:)
>
> If you're using the STL in your code, then you could add the following...
>
> class cLuaState {
> .....
> public:
>   static cLuaState* GetStateFromLuaState( lua_State *L );
> private:
>   static std::map< lua_State*, cLuaState* > myStateMap;
> };
>
> Then manage creating/deleting entries in myStateMap in your constructor
and
> desstructors, and write a body for GetStateFromLuaState such that you can
> have something like:
>
> int myLuaFunction( lua_State *L ) {
>   cLuaState* myStatePtr = cLuaState::GetStateFromLuaState( L );
>   .....
> }


I had considered this but could not use statics and wanted to avoid
searching for that state done by the map. My C++ class is hidden behind
COM-like interface.

AB

>
> I know this is terse, but I've not played with the STL in a while, so I
> can't easily rattle off the incantations for managing the map :)
>
> D.
>
> --



Reply | Threaded
Open this post in threaded view
|

Re: Lua state as a C++ class ...

Daniel Silverstone
On Thu, Jun 13, 2002 at 02:37:59AM -0700, Alex Bilyk wrote:
> I had considered this but could not use statics and wanted to avoid
> searching for that state done by the map. My C++ class is hidden behind
> COM-like interface.

Unfortunately you ultimately need the relationship which you have for
cLuaState->lua_State to work back the other way for lua_State->cLuaState

Your choices really are:
     1. Alter lua_State to include a cLuaState*
     2. Create a static mapping somewhere from lua_State* to cLuaState*

unfortunately that's it. Now either you map it inside the cLuaState object,
or you'll have to map it elsewhere.

The only other option is to make all the functions which need the cLuaState
pointer use a userdata to pass that in as a closure value.

The last option is perhaps what you'll end up doing, but isn't the most
elegant due to a need to remember to do that for each function you register

D.

-- 
Daniel Silverstone                               http://www.digital-scurf.org/
Hostmaster, Webmaster, and Chief Code Wibbler          Digital-Scurf Unlimited
GPG Public key available from keyring.debian.org               KeyId: 20687895
You will be winged by an anti-aircraft battery.

Reply | Threaded
Open this post in threaded view
|

Re: Lua state as a C++ class ...

Daniel Silverstone
In reply to this post by Nick Trout-4
On Thu, Jun 13, 2002 at 10:37:07AM +0100, Nick Trout wrote:
> Could you not just derive your state from Luas state struct and downcast?
> Have I missed the point?

Unless I'm completely wrong (as is my wont today for some reason) -- the
lua_State which things outside of the VM know exists, is what is known as an
"opaque type" in that we know a lua_State is a struct, and we always deal in
pointers to it.

Without the actual layout, it's unlikely that you could inherit from it.
Also I'm not completely convinced that C++ allows you to inherit a class
from a struct, although I could be wrong there too.

D.

-- 
Daniel Silverstone                               http://www.digital-scurf.org/
Hostmaster, Webmaster, and Chief Code Wibbler          Digital-Scurf Unlimited
GPG Public key available from keyring.debian.org               KeyId: 20687895
Your love life will be... interesting.

Reply | Threaded
Open this post in threaded view
|

RE: Lua state as a C++ class ...

Nick Trout-4
In reply to this post by Alex Bilyk
> On Thu, Jun 13, 2002 at 10:37:07AM +0100, Nick Trout wrote:
> > Could you not just derive your state from Luas state struct 
> and downcast?
> > Have I missed the point?
> 
> Unless I'm completely wrong (as is my wont today for some 
> reason) -- the
> lua_State which things outside of the VM know exists, is what 
> is known as an
> "opaque type" in that we know a lua_State is a struct, and we 
> always deal in
> pointers to it.

You are right. It was a silly idea :-)

Aggregation would be a better way to do it anyway and have reflective
pointer. If you are using Lua 4.0 then you'd have to modify the code, if you
are using 5.0 I think you just change a define to add data to the state. I
assume Alex is using 4.0 then.

> Also I'm not completely convinced that C++ allows you to 
> inherit a class
> from a struct, although I could be wrong there too.

A struct in C++ is exactly the same as a class except the default access is
public, not private.

N


Reply | Threaded
Open this post in threaded view
|

Re: Lua state as a C++ class ...

Siome Klein Goldenstein
In reply to this post by Daniel Silverstone
On Thu, Jun 13, 2002 at 10:51:38AM +0100, Daniel Silverstone wrote:
> 
> Unfortunately you ultimately need the relationship which you have for
> cLuaState->lua_State to work back the other way for lua_State->cLuaState
> 
> Your choices really are:
>      1. Alter lua_State to include a cLuaState*
>      2. Create a static mapping somewhere from lua_State* to cLuaState*
> 

You need the mapping,  but I believe there is a third option.

What if you store the cLuaState not as a field in lua_State,
but as an userdata object inside the lua_State itself?
This is not the most efficient way to get it done,  but requires
no fiddling with the internals of lua.

I've had to this last week, in a module of our system.  I wanted to
use an independent lua_State to parse a configuration script, since we
may have to be able to have multiple instances of this module at the
same time.  Requires this lua_State->instance mapping just the same way.

Abbreviating parts of the code:

void
MarkerHandler::read_file(std::string fname)
{
  lua_State *lua_s = lua_open(0);

  lua_pushusertag(lua_s, static_cast<void*>(this), LUA_ANYTAG);
  lua_setglobal (lua_s, "MARKERHANDLERPTR");

  lua_register(lua_s,"markers", MarkerHandler::general_frame_marker);

  lua_dofile(lua_s, fname.c_str());

  lua_close(lua_s);
}

In this case the file has multiple calls to the static method
MarkerHandler::general_frame_marker.

/* static */ int
MarkerHandler::general_frame_marker(lua_State *lua_s)
{
  //// ... do a lot of stuff with the parameters

  /// This figures out the actual instance of the MarkerHandler.

  lua_getglobal(lua_s, "MARKERHANDLERPTR");
  MarkerHandler *mh = static_cast<MarkerHandler*>(lua_touserdata  (lua_s, 3));

  //  access the method of the right instance.
  mh->set_frame_markers(frame_number, vecmark); 

  // no return value for the lua interpreter 
  return 0;
}


> unfortunately that's it. Now either you map it inside the cLuaState object,
> or you'll have to map it elsewhere.
> 
> The only other option is to make all the functions which need the cLuaState
> pointer use a userdata to pass that in as a closure value.
> 
> The last option is perhaps what you'll end up doing, but isn't the most
> elegant due to a need to remember to do that for each function you register
> 
> D.
> 
> -- 
> Daniel Silverstone                               http://www.digital-scurf.org/
> Hostmaster, Webmaster, and Chief Code Wibbler          Digital-Scurf Unlimited
> GPG Public key available from keyring.debian.org               KeyId: 20687895
> You will be winged by an anti-aircraft battery.

-- 
----------------------------
Siome Klein Goldenstein
[hidden email]
http://www.cis.upenn.edu/~siome

Reply | Threaded
Open this post in threaded view
|

Re: Lua state as a C++ class ...

Christian Vogler-2
On Thu, Jun 13, 2002 at 12:57:16PM -0400, Siome Klein Goldenstein wrote:
> Abbreviating parts of the code:
> 
> void
> MarkerHandler::read_file(std::string fname)
> {
>   lua_State *lua_s = lua_open(0);
> 
>   lua_pushusertag(lua_s, static_cast<void*>(this), LUA_ANYTAG);
>   lua_setglobal (lua_s, "MARKERHANDLERPTR");
> 
>   lua_register(lua_s,"markers", MarkerHandler::general_frame_marker);
> 
>   lua_dofile(lua_s, fname.c_str());
> 
>   lua_close(lua_s);
> }


You can avoid polluting the global lua namespace by using the
registry API, as follows:

lua_getregistry(lua_s);
lua_pushstring(lua_s, "MARKERHANDLERPTR");
lua_pushusertag(lua_s, static_cast<void*>(this), LUA_ANYTAG);
lua_settable(lua_s, -3);
lua_pop(lua_s, 1);


and accessing it:

lua_getregistry(lua_s);
lua_pushstring(lua_s, "MARKERHANDLERPTR");
lua_gettable(lua_s, -2);
MarkerHandler *mh = static_cast<MarkerHandler*>(lua_touserdata  (lua_s, -1));
lua_pop(lua_s, 2);

- Christian

P.S. I know that it is a dead horse, but the then-new API in Lua 4.0
really *is* hard to use.

12