Re: [ANN] LuaJIT-2.0.0-beta1

[Andrew Wilson <agrwagrw@...>]

Mike Very impressive!! & Great Job!

I've an older machine PC I run linux on.

andrew:/usr/local/bin$ /usr/local/bin/luajit-2.0.0-beta1
/home/andrew/spectral.lua 5500
/usr/local/bin/luajit-2.0.0-beta1: Sorry, SSE2 CPU support required
for this beta release

Will SSE2 support be minimum required?

Cheers
Andrew

On Sun, Nov 1, 2009 at 5:18 PM, François Perrad
<francois.perrad@gadz.org> wrote:
> 2009/11/1 Mike Pall <mikelu-0911@mike.de>:
>> François Perrad wrote:
>>> 1) numeric for with step = 0 causes infinite loop
>>>     $ luajit -e 'for i = 5, 7, 0 do end'
>>
>> This is testing implementation-defined behavior, i.e. you'll get
>> undefined results. Should 'for i=a,b,0' run upwards or downwards?
>> And what about 'for i=a,b,-0'?
>>
>> LJ2 chooses to look at the sign bit and runs downwards it it's
>> set. Lua runs upwards if 0 < step. Now, please don't ask what
>> happens if step is NaN. :-)
>>
>
> Nobody writes a for loop with direct 0.
> The step could be the return of a function.
> So, I prefer the Lua choice which prevents a infinite loop when a
> positive increment is excepted.
> But 'for i = 7, 5, 0' is a infinite loop with Lua.
>
>>> 2) losing arguments with metamethod __call
>>>     m = {}
>>>     setmetatable(m, {
>>>         __call = function (obj, ...)
>>>                      print('m.__call ' .. tostring(obj) .. ', ' ..
>>> table.concat(arg, ', '))
>>>                  end
>>>     })
>>>     m()
>>>     m(1, 2) --> arguments are lost
>>
>> 'arg' is a Lua 5.0 feature. Not supported. Use {...}.
>>
>>> and some new minor issues or delta :
>>> 1) getfenv(-3) gives a more general message :
>>>     bad argument #1 to 'getfenv' (invalid level)
>>> instead of
>>>     bad argument #1 to 'getfenv' (level must be non-negative)
>>> same issue with setfenv().
>>
>> Intentional change. The common error message is precise enough.
>>
>>> 2) tostring of C function
>>>     $ luajit -e 'print(tostring(print))'
>>>     function: fast#29
>>> when lua gives :
>>>     function: 0x9a5d020
>>
>> The exact format of of a tostring'ized object is implementation-
>> defined. Giving more information (since it's there) is intentional.
>>
>>> 3) xpcall without error handler
>>>     $ luajit -e 'print(xpcall(assert, nil))'
>>>     luajit: (command line):1: bad argument #2 to 'xpcall' (function
>>> expected, got nil)
>>> instead of :
>>>     false     error in error handling
>>
>> I'm testing that the error handler is a function. This is
>> apparently missing in the Lua codebase and it's erroring out
>> later (which is not useful). File a bug against Lua.
>>
>
> Another suspect behavior is flush() with a closed file f :
>   f:flush() throws the expected error
>   io.flush(f) doesn't
>
>>> 4) table.maxn
>>>     $ luajit -e 't = {3,4}; print(table.maxn(t))'
>>>     1
>>> instead of :
>>>     2
>>
>> Definitely a bug. Patch attached. Thank you!
>>
>>> 5) deprecated table.setn
>>>     $ luajit -e 'table.setn({},7)'
>>>     luajit: (command line):1: attempt to call field 'setn' (a nil value)
>>> instead of :
>>>     lua: (command line):1: 'setn' is obsolete
>>
>> Intentional.
>>
>>> 6) math.random with extra arguments
>>>     $ luajit -e 'print(math.random(1, 2, 3))'
>>>     2
>>> instead of :
>>>     lua: (command line):1: wrong number of arguments
>>
>> Intentional. None of the other library functions care when more
>> arguments than necessary are passed.
>>
>
> Another exception is table.insert().
>
> I'll update my test suite.
>
> François
>
>> Thanks for helping with testing!
>>
>> --Mike
>>
>