Re: Bugs.. ? (was: Re: Lua-users standard libraries project: anyone game?)

[Reuben Thomas <rrt@...>]

> Hmm... begin to see a pattern here.. I miss the coresponding c libs
> needed (like bits and rex etc). Maybe the lib should check wheter these
> libraries are available or not, before doing their stuff :)

Yes, that's true. I should put in a test, and have now. It's a while since
I thought about it, but I think the reason I didn't do anything was that
it's not entirely obvious what my approach should be if the library isn't
loaded. Should I complain? Silently fail to compile the requisite
functions? Load them anyway (but they won't work unless/until you load the
C part)? And what about extensions to the standard C libraries (table,
string &c.)? What if they're not there?

For the moment, I've made the loading of std.bit and std.rex conditional
on the existence of tables bit and rex *in std.lua*. So if you say
require "std" and you are lacking bit or rex, it won't complain, but if
you say require "std.bit" and you don't have bit, you'll get the error you
just got. That's the simplest solution I can think of that definitely
improves what I have at the moment.

I'd be interested to hear ideas on solving the more general problem. I
guess this is something that has to be solved for integration into
LuaCheia.

> o std.table.lua:122 shouldn't the metamethod be __index?

It should, thanks. I clearly haven't tested this since Lua 4.

> o std.base.lua:tostring need to check for self referencing tables, or it
> goes down an endless circle of tostring calls.

Thanks. I had fun trying to fix this. I have committed the result, which
seems to work for things like

a = {}; a[1]=a; print(a)
a = {{}}; a[1][1]=a; print(a)
a = {}; b = {a}; a[1] = b; print (a)
a = {}; b = {a,a}; print (b)

I don't claim to have got it right first time, though.

-- 
http://www.mupsych.org/~rrt/
motive, n.  a mental wolf in moral wool (Bierce)