Re: [ANN] Lua 5.2.0 (alpha) now available

[Lorenzo Donati <lorenzodonatibz@...>]

Thank you very much for the prompt reply!

Luiz Henrique de Figueiredo wrote:
> > this quick switch from work5 to alpha was quite a surprise (for me - my bad
>
> http://lua-users.org/lists/lua-l/2010-10/msg00834.html said that we were
> getting close to an alpha version. Note that we're still at alpha-rc1.

As I said: "my bad" :-)
I read that message but I didn't really realize that we were _so_ close :-)
I once stumbled upon the timeline of Lua evolution and was really struck 
- positively I mean - by the negation of the principle "release early, 
release often" ("release crap" - I would sometimes add to that :-) ). 
That trend has somehow stuck in my mind, so ... :-)

> > I noticed that Lua's build is quite customizable through luaconf.h, so I 
> > wonder how a script can detect the different options used to compile the 
> > Lua interpreter under it is running.
>
> Try this:
>
>   gcc -E -P - -I. <<EOF
>   #include "lua.h"
>   VALUE_OF_LUAL_BUFFERSIZE = LUAL_BUFFERSIZE
>   EOF
>
> But I understand that this is not from inside running a Lua interpreter.
Thanks! But that is some sort of "C-compiler magic" that I'm not very 
accustomed to! I understand that many experienced Lua programmers are 
also C Wizards, but I feel always a bit uneasy at C (and don't know gcc 
so well :-( )
Last time I used C in a more serious ways was back around 1992 with 
turbo C! :-)


> > Couldn't some of those defines (or even some other parameters not found 
> > in luaconf.h, like max number of item that can be unpacked) be made 
> > available as "constants" in a table, or maybe through a function
>
> You can do that yourself, using the technique above.
Ok.
> > Am I missing something why Lua doesn't provide such informations? Isn't 
> > that so useful as I think?
>
> It's probably not that useful. Plus it encourages complicated programming.
Oh. I see.
But I wonder whether it is safe, for example, not to know (officially - 
It is not written in the reference manual) that the limit for unpacking 
a table is far lower than the memory limit.
This way a novice programmer (not knowledgeable of the C inner workings 
of Lua) could think that unpacking a 10,000 items array should be 
doable, and instead get an error (maybe in production code). At least it 
should be mentioned in the manual that unpack has some limit and is not 
intended for large array operations.
Moreover the manual itself could be misleading. From Lua's 5.1.4 refman 
- unpack description:
"...except that the above code can be written only for a fixed number of 
elements"
This could lead one to think that unpack is designed to handle tables of 
arbitrary length (at least in the limit of the available memory).

Sorry for focusing on "unpack", but it is just an example to make my 
point as clear as possible.

I remember reading something on sqlite3 documentation where the authors 
regretted that in early versions of sqlite there were no documented 
limits (by design - they thought a good idea to omit that information) 
and this led to very subtle bugs (http://www.sqlite.org/limits.html).

Maybe in Lua there are statistically no significants threats in this 
area, but still I feel some more information (carefully selected, 
possibly) either at runtime or in the docs (at the very least a pointer 
to the relevant section of lua.h or luaconf.h) should be added.
Maybe a table generated from the trick above in an automatic way should 
be an integral part of the refman of stock Lua, so a non-C programmer 
could have a general idea of what stock Lua can handle (and that to 
alter those limits one has to poke around with C).

Thanks a lot.

-- Lorenzo

P.S.: still curious about the funny format of package.config :-)