Re: upgrading to 4.0(a)

[Stephan Herrmann <stephan@...>]

Hi again,

Luiz Henrique de Figueiredo <lhf@tecgraf.puc-rio.br> writes:
> > * 'gc' tagmethod not settable from Lua
> [...]
> So, we have restricted gc' tagmethods to userdata; and these can only be set
> in C, because typically all you want to do is free() those pointers.
No problem with this, just a matter of documentation to come up ;-)

> > * lua_seterrormethod disappeared. (Why?)
> To make it clear that the way to do it is to set _ALERT or _ERRORMESSAGE.
But that is exactly what lua_seterrormethod did. What's the difference?
 
> > * lua_State argument needed also in non-reentrant programs for luaL_verror()
> The API in 4.0b will different from 4.0a there wil no single-state version.
Really? I mean, this sounds like everybody will write his own set of
macros for compatibility? Positively spoken, only these macros made 
upgrading feasable for me at the current point in time. (I have > 5 kLoC
full of calls to the Lua-API, AND I don't want to force all my users
(students) to install the new Lua immediately - so I NEED such macros).

> > * how about a little guide on adapting custom made main-programs?
> >	(creating the lua_State, using begin/endblock() for opening libs..)
> Good suggestion.  We'll have to write this.
Sorry for causing more work ;-)
 
> > * below is a program that screws up the internal Lua-Stack. Doesn't look
> >   really dangerous, does it?
> This was a bug in 4.0a. It has been corrected in 4.0b.
<Took me half a day, to find out what happened.>
 
> >I'm the only one who needs this predictable ordering?
> Surely not. But I don't see a way out.
> Perhaps you can give more examples of why this would be useful and how this
> could be implemented...
Ok, what I was talking about, was not an ordered table, but ordered
_iteration_. I didn't mean to replace hashtables by a sorted data
structure. All I do is provide an alternative to foreach, which does
the sorting before iterating. AND: this iterator is robust: it is
possible to change the underlying table, whithout interfering with
the foreach. I enclose my implementation of sortedforeach (lua 4.0a).

Talking about examples: to be honest, 2 out of 3 examples can be
implemented using foreachi (which was not there, when I first
implemented sortedforeach). But consider a data structure whose values
are declared using nested tables, eg.
   Structure{
	Element1 = something{x, y},
	Element2 = somethingelse{z}
   }
Now the constructors something/somethingelse create internal structures
returning just an integer handle (ascending). Now I need to assert, 
that these handles are the some for different runs, provided the table
is not changed, ie. the order in which something/somethingelse are 
invoked must be constant. As I have no chance to look at the order
in which the table is written, all I can do is, to sort according
to the indices "Element1"/"Element2".

Maybe not a very common situation ;-), but that's what I need..
 
> >BTW: what is a tag, that is guaranteed to be invalid? -2 ?
> Yes. Perhaps we should add LUA_NOTAG, like we already have LUA_NOREF.
thanks.

ciao
Stephan

Attachment: sortedforeach.c
Description: Binary data