upgrading to 4.0(a)

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

upgrading to 4.0(a)

Stephan Herrmann-2
Hi,

Finally, I made it to upgrade to Lua4.0(alpha).
Here are my (unpleasant) findings, some of which concern the
list of incompatibilities, but there is also one severe bug.

 * 'gc' tagmethod not settable from Lua
 * somewhere I learned, that type() returns two values: type and tag.
   Although it was undocumented, it is a feature that disappeared.
   And its disappearance produces errors that are not at all obvious.
 * lua_seterrormethod disappeared. (Why?)
 * lua_State argument needed also in non-reentrant programs for luaL_verror()
 * how about a little guide on adapting custom made main-programs?
	(creating the lua_State, using begin/endblock() for opening libs..)
 * below is a program that screws up the internal Lua-Stack. Doesn't look
   really dangerous, does it?
   Changing the if-condition to 1 changes the bug to a 
   segmentation violation. Using replacement (2) works around the bug.
   (Don't ask me, how I found that =:-0 )

Sorry, if some of this has been reported on the list before. I couldn't
follow the busy discussion of the last weeks very thoroughly.
(maybe Lua4.0beta will change everything, but I had the time for 
upgrading now, not in October :-(

ciao
Stephan

PS: I also had to dig into the sources a little deeper, because I need
a version of foreach which has repeatable order also for string indices.
Something comparable to foreachi, but -- for strings. Easiest way seems
to be to use qsort before iterating. Unfortunately using memcpy and qsort
to do the job requires low-level access to internal data structures..
I had posted a suggestion of "sortedforeach" some time ago and I still
wonder, whether I'm the only one who needs this predictable ordering?

BTW: what is a tag, that is guaranteed to be invalid? -2 ?

----------------------------------------------------------------------
$debug

function func1 () end

function func2()
    local a

    if nil then 
-- (1) if 1 then
        print("T1")
        a={func1()} 
-- (2)  a={}; a[1]=func1()
   end 
   print("T2") -- print is no longer print..
end

func2()

--------------------------------------------------------------------------
 Stephan Herrmann
 ----------------
 Technical University Berlin
 Software Engineering Research Group
 http://swt.cs.tu-berlin.de/~stephan
 phone: ++49 30 314 73174         
--------------------------------------------------------------------------


Reply | Threaded
Open this post in threaded view
|

Re: upgrading to 4.0(a)

Luiz Henrique de Figueiredo
>From: Stephan Herrmann <[hidden email]>
>
>Finally, I made it to upgrade to Lua4.0(alpha).
>Here are my (unpleasant) findings, some of which concern the
>list of incompatibilities, but there is also one severe bug.
>
> * 'gc' tagmethod not settable from Lua

'gc' tagmethods written in Lua open the way to subtle bugs.
Ditto for 'gc' tagmethods for tables.
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.
Moreover, gc' tagmethods for userdata are now called in decreasing order of
tags, so that you can free structures in the reverse order they were
created (in X11, for instance, you have to close a window before closing
the display).
 
> * somewhere I learned, that type() returns two values: type and tag.
>   Although it was undocumented, it is a feature that disappeared.

Two reasons: the tag is already returned by tag() and also it could give
unexpected results when passing type() to another function, because
multiple results are now passed along, ie f(type()) would receive 2 arguments.

Likewise, setglobal no longer returns a value.

>   And its disappearance produces errors that are not at all obvious.

Yes, I'm sorry.

> * lua_seterrormethod disappeared. (Why?)

To make it clear that the way to do it is to set _ALERT or _ERRORMESSAGE.

> * 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.

> * 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.

> * 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.

Thanks for the comments.

>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...

>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.
--lhf

Reply | Threaded
Open this post in threaded view
|

Re: upgrading to 4.0(a)

Edgar Toernig
Luiz Henrique de Figueiredo wrote:
> 
> >From: Stephan Herrmann <[hidden email]>
> >
> >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...

Ordered tables would be nice.  In MUMPS for example (terrible language but
cute arrays) all arrays are ordered.  And, arrays could be in-core or on-
disk.  They build complete databases with these (variable length key/data)
on-disk arrays.

They used b*trees for the on-disk arrays.  Don't know about the in-core
ones, I would guess either standard binary trees or even b*trees too to
get a simple memory management.

Putting ordered tables into Lua would cost a lot.  Good bye performance.
But, you could implement them as userdata.  There's just one pitfall:
You have to create references to the elements.  And that's memory
consuming and slow.  But if Lua were able to walk these userdata-tables
during the gc-phase (ie gc-mark tagmethod) ...  *hinthint*g*

Ciao, ET.

Reply | Threaded
Open this post in threaded view
|

Re: upgrading to 4.0(a)

Stephan Herrmann-2
In reply to this post by Luiz Henrique de Figueiredo
Hi again,

Luiz Henrique de Figueiredo <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: upgrading to 4.0(a)

Roberto Ierusalimschy
> : I also had to dig into the sources a little deeper, because I need
> a version of foreach which has repeatable order also for string indices.

What about this? Too slow?

  function foreachsorted (t, f)
    local a = {}
    foreach(t, function(name) tinsert(%a, name) end)
    sort(a)
    foreachi(a, function (i, n) %f(n, %t[n]) end)
  end


> > * below is a program that screws up the internal Lua-Stack. Doesn't look
> >   really dangerous, does it?

Somewhere in the list (around May, I guess) there is a one-line patch
for it.

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: upgrading to 4.0(a)

Luiz Henrique de Figueiredo
In reply to this post by Stephan Herrmann-2
>> > * below is a program that screws up the internal Lua-Stack. Doesn't look
>> >   really dangerous, does it?
>
>Somewhere in the list (around May, I guess) there is a one-line patch
>for it.

See below. Like I said, this has already been fixed in 4.0b.

 From: Edgar Toernig <[hidden email]>
 Date: Thu, 08 Jun 2000 04:51:13 +0200
 Message-ID: <[hidden email]>

 --- lparser.c.orig      Thu Jun  8 04:47:09 2000
 +++ lparser.c   Thu Jun  8 04:47:31 2000
 @@ -652,7 +652,7 @@
	  cd->k = 1;  /* record */
	}
	else {
 -        luaK_tostack(ls, &v, 0);
 +        luaK_tostack(ls, &v, 1);
	  cd->n = listfields(ls);
	  cd->k = 0;  /* list */
	}

--lhf