Re: Lua 5.1 (beta) now available
[
Date Prev][
Date Next][
Thread Prev][
Thread Next]
[
Date Index]
[
Thread Index]
- Subject: Re: Lua 5.1 (beta) now available
- From: Mike Pall <mikelu-0511@...>
- Date: 2005年11月11日 18:04:08 +0100
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