lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

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 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"

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.

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 (

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 :-)