Lua 5.1 (beta) now available

classic Classic list List threaded Threaded
42 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Lua 5.1 (beta) now available

Luiz Henrique de Figueiredo
Lua 5.1 (beta) is now available for testing at
       http://www.lua.org/work/lua-5.1-beta-rc.tar.gz

This is a pre-release. Unless major problems appear, it will be frozen
in a week or so (and the tarball renamed). Please take a look and send
us your comments or post them here.

If everything goes well, we shall release Lua 5.1 final by the end of
the year. Until then, we'll be working on revising the manual.

Enjoy.
--lhf

Reply | Threaded
Open this post in threaded view
|

RE: Lua 5.1 (beta) now available

Henderson, Michael D
Is there anything that lists the differences between the 5.1 alpha and
beta? The History file seems to cover only 5.0 to 5.1.

Thanks,
Mike

Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.1 (beta) now available

Roberto Ierusalimschy
> Is there anything that lists the differences between the 5.1 alpha and
> beta?

No... A tentative list follows:

- string.gsub accepts tables as the replacement (and related changes 
  already anounced)
- lua_gc has a new option to allow more precision for gc count
- new function lua_setallocf (to change the allocator function)
- new function table.maxn
- new function debug.getregistry
- getlocal/setlocal operate also on C locals and temporaries
- some changes in luaconf (give up the attempt to automatically
  discover what is available in each machine)
- several small issues that surfaced on the list (e.g., changes to avoid
  warnings in some compilers)

(The changes in luaconf need feedback...)

-- Roberto


Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.1 (beta) now available

Petite Abeille
In reply to this post by Luiz Henrique de Figueiredo

On Nov 01, 2005, at 18:55, Luiz Henrique de Figueiredo wrote:

This is a pre-release. Unless major problems appear, it will be frozen
in a week or so (and the tarball renamed). Please take a look and send
us your comments or post them here.

If you are using LuaSocket's url.parse(), watch out for the change in string.gsub semantic as this function relies on an implicit nil return to decompose the URL.

Cheers

--
PA, Onnay Equitursay
http://alt.textdrive.com/


Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.1 (beta) now available

D Burgess-4
In reply to this post by Roberto Ierusalimschy
I think there is a problem with lauxlib.c and the unguarded use of luaL_getn.
i.e.
luaL_getn can be removed with
#if defined(LUA_COMPAT_GETN)

DB


Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.1 (beta) now available

D Burgess-4
Ignore the previous comment
DB


Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.1 (beta) now available

Chris Marrin
In reply to this post by Roberto Ierusalimschy
Roberto Ierusalimschy wrote:
...
- getlocal/setlocal operate also on C locals and temporaries

This is just what I need!!! It looks like it always returns the string "(*temporary)" for a C function (which makes sense). Is it true that it will always return this string if the value gets pushed and will not push a value if the string is NULL? If so, then I can toss the little temporary function I wrote to do this!!!

Thanks...


--
chris marrin                ,""$,
[hidden email]          b`    $                             ,,.
                        mP     b'                            , 1$'
        ,.`           ,b`    ,`                              :$$'
     ,|`             mP    ,`                                       ,mm
   ,b"              b"   ,`            ,mm      m$$    ,m         ,`P$$
  m$`             ,b`  .` ,mm        ,'|$P   ,|"1$`  ,b$P       ,`  :$1
 b$`             ,$: :,`` |$$      ,`   $$` ,|` ,$$,,`"$$     .`    :$|
b$|            _m$`,:`    :$1   ,`     ,$Pm|`    `    :$$,..;"'     |$:
P$b,      _;b$$b$1"       |$$ ,`      ,$$"             ``'          $$
 ```"```'"    `"`         `""`        ""`                          ,P`
"As a general rule,don't solve puzzles that open portals to Hell"'

Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.1 (beta) now available

D Burgess-4
In reply to this post by Luiz Henrique de Figueiredo
BTB, Sorry about the previous dud messages.

I think we have a small  bug that has crept back in.

The luaconf.h now has a #include <math.h> re-introduced. It would seem
that ldo.c is
the only thing that needs this to compile. This include gives me some
grief (see below).
My solution was to remove it from luaconf and add an include for
math.h to ldo.c.

The problem:

I compile 2 lua modules as C++(without going into why), this means
that I change the
the lua includes to be wrapped in extern "C" {. This means that the math.h
definitions/declarations are compiled within the extern "C" warpper.
Because math.h and others have conditional code guarded by
#ifdef __cplusplus
This not unsuprisingly generates a lot of compilation errors.

This got me to thinking about the validity of

#ifdef __cplusplus
extern "C" {
#endif

#include "lua.h"
#include "lauxlib.h"

#ifdef __cplusplus
}
#endif

Methinks that this is only valid if lua.h and lauxlib.h have *NO*
nested system (<>)
includes.  e.g. #include <math.h>

I think this varies with compiler, but the risks are high with math.h, stdarg.h,
stddefs.h, stdio.h. Each of these headers potentially have C++ specific
implementations.

David B


Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.1 (beta) now available

Roberto Ierusalimschy
In reply to this post by Chris Marrin
> It looks like it always returns the string "(*temporary)" for a C
> function (which makes sense).

Yes.


>  Is it true that it will always return this string if the value gets
> pushed and will not push a value if the string is NULL?

I did not understand what you meant...

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.1 (beta) now available

Roberto Ierusalimschy
In reply to this post by D Burgess-4
> The luaconf.h now has a #include <math.h> re-introduced. It would seem
> that ldo.c is the only thing that needs this to compile.

lcode.c also needs it now (for constant-expression evaluation; yes,
another novelty in beta...). But the main point is that, if you change
lua_Number (or the definitions of some airthmetic operations), they
may not need math.h anymore. We want to be able to correct that only
changing luaconf.h.


> I compile 2 lua modules as C++(without going into why), this means that
> I change the the lua includes to be wrapped in extern "C" {. This means
> that the math.h definitions/declarations are compiled within the extern
> "C" warpper.  Because math.h and others have conditional code guarded by
> #ifdef __cplusplus This not unsuprisingly generates a lot of compilation
> errors.

As you are already changing those modules, you can include math.h in
them before including the lua headers :)

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.1 (beta) now available

D Burgess-4
> As you are already changing those modules, you can include math.h in
> them before including the lua headers :)

The problem just got worse, my day is just ending and I have spent most of
it compiling and testing apps against 5.1 beta.
The math.h problem gives about half of my C++ modules that use Lua
the same problem as lvm.c, ldo.c, lcode.c. This is a *lot* of modules.
The problem exists with MS SDK headers in both VCs.
If the include is removed from luaconf.h the worst that happens is that
you get

warning C4013: 'xxxxx' undefined; assuming extern returning int

which is a friendly reminder to add the header to the module.

The other way out of this seems to be (not exhaustively tested) :

#if defined(LUA_CORE) || defined(LUA_LIB)
#ifdef __cplusplus
#define LUA_API extern "C" __declspec(dllexport)
#else
#define LUA_API __declspec(dllexport)
#endif
#else
#ifdef __cplusplus
#define LUA_API extern "C" __declspec(dllimport)
#else
#define LUA_API __declspec(dllimport)
#endif
#endif


and


#ifdef __cplusplus
#define LUAI_FUNC extern "C"
#else
#define LUAI_FUNC	extern
#endif


The "C" addition to extern when C++ seems to work ok in the few
cases that I have tried it.


David B


Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.1 (beta) now available

Adam D. Moss
In reply to this post by D Burgess-4
David Burgess wrote:
I compile 2 lua modules as C++(without going into why)

Is it so that Lua errors can be thrown as C++ exceptions?  Sorry to
pry.  If you don't elucidate then the natural response is 'don't do
that then' of course.  :)  Which isn't to say that this can't be
fixed in a way that makes everyone happy...

--Adam

Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.1 (beta) now available

D Burgess-4
You guessed one reason, the second is so that I can use Lua in
C++ modules that throw exceptions and use the same DLL for
mostly pure C apps.

I think I have a rather good solution (albeit I need to change a lot of code)
running with the following code.

1)  i get rid of every set guards like:
#ifdef __cplusplus
extern "C" {
#endif
#include "lua.h"
#include "lauxlib.h"
#include "lualib.h"
#ifdef __cplusplus
}
#endif

2) in luaconf.h alone I added

#if defined(__cplusplus)
#define LUADECLEXTERNC extern "C"
#define LUAEXTERNC "C"
#else
#define LUADECLEXTERNC
#define LUAEXTERNC
#endif

and changed

#if defined(LUA_CORE) || defined(LUA_LIB)
#define LUA_API LUADECLEXTERNC __declspec(dllexport)
#else
#define LUA_API LUADECLEXTERNC __declspec(dllimport)
#endif

#define LUAI_FUNC	extern LUAEXTERNC




On 11/3/05, Adam D. Moss <[hidden email]> wrote:
> David Burgess wrote:
> > I compile 2 lua modules as C++(without going into why)
>
> Is it so that Lua errors can be thrown as C++ exceptions?  Sorry to
> pry.  If you don't elucidate then the natural response is 'don't do
> that then' of course.  :)  Which isn't to say that this can't be
> fixed in a way that makes everyone happy...
>
> --Adam
>


Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.1 (beta) now available

D Burgess-4
In reply to this post by Adam D. Moss
I forget to mention. It is not just a Lua build problem, it is a
problem with any C++ app that wants to use Lua.
DB


Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.1 (beta) now available

Roberto Ierusalimschy
> I forget to mention. It is not just a Lua build problem, it is a
> problem with any C++ app that wants to use Lua.

That is weird. That #include is protected by a #ifdef LUA_CORE. It
should not happen in any outside code. Can you check that?

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.1 (beta) now available

D Burgess-4
I will check. Maybe not for another 12 hours.
David B
> That is weird. That #include is protected by a #ifdef LUA_CORE. It
> should not happen in any outside code. Can you check that?
>
> -- Roberto
>


Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.1 (beta) now available

D Burgess-4
> > That is weird. That #include is protected by a #ifdef LUA_CORE. It
> > should not happen in any outside code. Can you check that?

You are right, the problem is just with ldo.c and lua.c (The two I compile
as C++).

David B


Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.1 (beta) now available

Chris Marrin
In reply to this post by Roberto Ierusalimschy
Roberto Ierusalimschy wrote:

...
Is it true that it will always return this string if the value gets
pushed and will not push a value if the string is NULL?


I did not understand what you meant...

Sorry, I was just making sure I understood the semantics. Is it true that, if I call this and the returned string is NULL there is nothing pushed onto the stack?

--
chris marrin              ,""$, "As a general rule,don't solve puzzles
[hidden email]        b`    $  that open portals to Hell" ,,.
        ,.`           ,b`    ,`                            , 1$'
     ,|`             mP    ,`                              :$$'     ,mm
   ,b"              b"   ,`            ,mm      m$$    ,m         ,`P$$
  m$`             ,b`  .` ,mm        ,'|$P   ,|"1$`  ,b$P       ,`  :$1
 b$`             ,$: :,`` |$$      ,`   $$` ,|` ,$$,,`"$$     .`    :$|
b$|            _m$`,:`    :$1   ,`     ,$Pm|`    `    :$$,..;"'     |$:
P$b,      _;b$$b$1"       |$$ ,`      ,$$"             ``'          $$
 ```"```'"    `"`         `""`        ""`                          ,P`

Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.1 (beta) now available

Roberto Ierusalimschy
> Is it true that, if I call this and the returned string is NULL there is
> nothing pushed onto the stack?

Yes.

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Lua and SNMP

John Passaniti-2
In reply to this post by Chris Marrin
I am looking for either a SNMP library in Lua or a binding to an existing C library. My application for this is very simple and I care only about GET and SET requests on integers and strings against a SNMPv1 agent. I don't care about being able to read MIB files and symbolically address OIDs. I don't care about any exotica possible with SNMP as this is for communication with a fixed embedded system, not SNMP agents in general.

I am aware of LuaMan, but the web page states it is for Lua 2.5, and I doubt it would work on Lua 5.1 without fiddling around with it. And yes, I know about the Net-SNMP library (nee the Carnegie-Mellon SNMP library), but it would be a non-trivial effort to come up with a rational binding to it.

Any suggestions anyone has will be appreciated.



123