Re: Lua 5.1 (beta) now available

[Mike Pall <mikelu-0511@...>]

Hi,

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.

Ok, having caught up with two weeks of messages, here's my list
of comments:

- Autodetecting system capabilities is a can of worms ...

  Right now this is mixed up between the top-level Makefile
  (one needs to select the proper target) and luaconf.h
  (guesses some things, but not others). IMHO more consistency
  would help here.

  Since it's impossible to cater for all system variants out
  there in the field, I suggest to limit ourselves to the
  following common cases:

  - Linux: 'make linux' defines LUA_USE_POSIX and LUA_DL_DLOPEN
    and adds MYLIBS="-Wl,-E -ldl".
  - *BSD: 'make bsd' defines LUA_USE_POSIX, LUA_DL_DLOPEN and
    LUA_USE_ULONGJMP.
  - Mac OS X: 'make osx' defines LUA_USE_POSIX, LUA_DL_DYLD and
    LUA_USE_ULONGJMP.
  - Generic POSIX: 'make posix' defines LUA_USE_POSIX.
  - Generic POSIX w/ dlopen: 'make posixdl' defines LUA_USE_POSIX
    and LUA_DL_DLOPEN. [This is to be used by most other systems
    out there, e.g. Solaris, HP-UX, AIX ...]
  - Windows w/ MSVC: checks for _WIN32 in luaconf.h and optional
    use of etc/luavs.bat.
  - Windows w/ MinGW: checks for _WIN32 in luaconf.h and use of
    'make mingw' which modifies the build process.
  - Strict ANSI compliance: 'make ansi' defines LUA_ANSI.
  - Generic: 'make generic' defines nothing.

  A plain 'make' at the toplevel prints a list of the possible
  targets but does not build anything. This avoids mixed up
  builds (first time with the proper target, but on recompile
  without a target -- happened to me often enough).

  Then in luaconf.h at the top there is a check for LUA_USE_POSIX
  which defines LUA_USE_MKSTEMP, LUA_USE_ISATTY and LUA_USE_POPEN.
  No other system dependent checks there (except for _WIN32).

  [The alternative is to put all system dependent checks into
  luaconf.h. Which is hard because there is no define to check
  for POSIX systems or dlopen support. And Linux would still
  need the change to MYLIBS in the Makefile. Oh well ...]

- The luai_num* macros lost their first argument 'L'. This
  makes it difficult to throw errors or use state information
  for implementations using other number types.

  I can see the rationale for not allowing them to throw errors
  due to the introduction of constant-expression evaluation
  at compile time. Well, constfolding() in lcode.c already takes
  care not to evaluate x/0 at compile time. But x%0 is still
  evaluated before throwing the NaN out?

  IMHO for replacing these macros with integer arithmetic
  equivalents there needs to be a strict guideline. Either
  they throw errors for the corner cases and constfolding()
  carefully avoids these. Or they must return some integer
  pseudo-NaN (probably the largest negative integer). I tend
  to the latter.
  [pseudo-NaN because it's not propagated like a proper NaN.]

- Quite a few people have attempted to change the type of lua_Number
  and got it wrong. IMHO there is no point in everyone reinventing
  the wheel.

  Adding definitions for the 3 1/2 interesting cases to luaconf.h
  shouldn't be too much overhead. This would be double, float,
  int/long (long only for 16 bit systems).

  A LUA_NUMBER_PRECISION define (53, 24, 31) would help some
  external modules that need to compile different code depending
  on the type of lua_Number (even if you don't intend to
  add all cases to the standard luaconf.h).

- OP_TEST is marked in lopcodes.c as an instruction setting
  register A. This is clearly not true since the introduction
  of OP_TESTSET. I wonder why this was changed from 5.1-alpha
  to 5.1-beta?

- table.maxn(t) should be documented as 'expensive' and only
  to be used if #t does not work (for arrays with holes or
  tables with non-integer keys).

- Using proper empty-element tags in the docs is a good step
  towards xhtml compliance (but many end tags are still missing).
  For compatibilty to older standards it's a good idea to use
  the form '<name />' instead of '<name/>'.
  There are still some upper-case element/attribute names left.

- The optimization to remove the LOADNIL at the start of a function
  adds one more branch to the fast path for function calls in
  luaD_precall(). It's a predictable branch though. I haven't
  checked whether this has a performance impact (yet) ...

- The check for (defined(__i386) || defined(_M_IX86)) in luaconf.h
  does not work for OpenBSD. One needs to add defined(__i386__), too.
  [This was already reported for 5.1-alpha.]

Bye,
     Mike