On lua5 and embedding

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

On lua5 and embedding

Dimitris Papavasileiou
Lua was designed to be an embeddable extension language and it seems
to me that it does the second part pretty good.It's very
simple(allmost everything is implemented with tables) and efficient
and it fits nicely into C.Regarding the first point though,
embedding.I rencently took a look at python(I had to write a plugin
for an application) and after reading the Python to C interface I was
almost ready to switch to python(after reading about the language
itself though I reconsidered).You could define your own data types and
do almost anything.Now I agree that userdata and metatables can
achieve the same functionality and may be more elegant and unified in
the sense of the everything-is-a-table philosofy but why the heck are
there so few metamethods?I mean a few like:
__get,__set,__getindex,__setindex would hepl interfacing lua to C
immensely(just take a look at many of the previous threads).I assume
that the problems is the metamethod look-up overhead in frequent
operations like getting and setting global values but couldn't this be
handled with caching of some sort?Besides __get and __set metamethods
on userdata could help implementing a lot of things without assigning
a metatable to the globals table.
btw why the distinction between full and light userdata in Lua5.Light
ones can be implemented with full ones anyway(using a full userdata of
size sizeof(void *)).I know it's not so important but it seems to me
that it unnecessarily adds complexity when lua's goal seems to be
simplicity.
That's all my bitching for now,
Dimitris


Reply | Threaded
Open this post in threaded view
|

RE: On lua5 and embedding

Bilyk, Alex
Yeah, I was complaining about this as well. Then someone said that __get and __set have been removed as a speed improvement. Curiously enough, IMHO, one could actually do more with tags in Lua4 and it would run faster as well. Meta-tables are slower and you'd want to get rid of anything you can get away with while using them. In fact, in current implementation of Lua5 Beta, it is partially optimized for when one does NOT use meta-methods (Duh!  What an important case for a language whose main virtue is meta-table based extensibility). Basically, as long as one runs plain vanilla Lua5 scripts they will go pretty fast. But as soon as one starts using inheritance, call and other meta-methods on their objects that is when the meta-method overhead jumps in. Syntax-wise meta-tables are pretty but with respect to functionality they are impaired feature-wise as well as speed-wise, in may view, compared to tags in Lua4 (boy, am I repeating myself or what?). My only hopes are that meta-methods access will get optimized at some point for a case when one actually uses them and that computers are getting faster and faster allowing applications to become a little more wasteful in terms of CPU and memory use and letting programmers become less thoughtful at the same time. In my port of a ton of scripts from Lua 4 to 5 I implemented a tag system on top meta-tables. My C code has almost not changed at all (renamed a few functions and such). Then a little massage to scripts fixed the rest of the differences. Another thing that may compensate for MT overhead is that the VM in Lua5 is reportedly faster then in Lua4.

Anyway, Lua5 is still more then well suited for what we use it (even better due to co-routines).

AB

-----Original Message-----
From: jimmyp_gr <[hidden email]> [[hidden email]]
Sent: Tuesday, January 28, 2003 11:12 AM
To: Multiple recipients of list
Subject: On lua5 and embedding

Lua was designed to be an embeddable extension language and it seems
to me that it does the second part pretty good.It's very
simple(allmost everything is implemented with tables) and efficient
and it fits nicely into C.Regarding the first point though,
embedding.I rencently took a look at python(I had to write a plugin
for an application) and after reading the Python to C interface I was
almost ready to switch to python(after reading about the language
itself though I reconsidered).You could define your own data types and
do almost anything.Now I agree that userdata and metatables can
achieve the same functionality and may be more elegant and unified in
the sense of the everything-is-a-table philosofy but why the heck are
there so few metamethods?I mean a few like:
__get,__set,__getindex,__setindex would hepl interfacing lua to C
immensely(just take a look at many of the previous threads).I assume
that the problems is the metamethod look-up overhead in frequent
operations like getting and setting global values but couldn't this be
handled with caching of some sort?Besides __get and __set metamethods
on userdata could help implementing a lot of things without assigning
a metatable to the globals table.
btw why the distinction between full and light userdata in Lua5.Light
ones can be implemented with full ones anyway(using a full userdata of
size sizeof(void *)).I know it's not so important but it seems to me
that it unnecessarily adds complexity when lua's goal seems to be
simplicity.
That's all my bitching for now,
Dimitris


Reply | Threaded
Open this post in threaded view
|

Re: On lua5 and embedding

Dimitris Papavasileiou
--- In [hidden email], "Bilyk, Alex" <ABilyk@m...> wrote:
> Yeah, I was complaining about this as well. Then someone said that
__get and __set have been removed as a speed improvement. Curiously
enough, IMHO, one could actually do more with tags in Lua4 and it
would run faster as well. Meta-tables are slower and you'd want to get
rid of anything you can get away with while using them. In fact, in
current implementation of Lua5 Beta, it is partially optimized for
when one does NOT use meta-methods (Duh!  What an important case for a
language whose main virtue is meta-table based extensibility).

Strange... To me tag methods and metamethods look a lot alike.Is the
table lookup to get the method what causes the slowdown.

> Basically, as long as one runs plain vanilla Lua5 scripts they will
go pretty fast. But as soon as one starts using inheritance, call and
other meta-methods on their objects that is when the meta-method
overhead jumps in. Syntax-wise meta-tables are pretty but with respect
to functionality they are impaired feature-wise as well as speed-wise,
in may view, compared to tags in Lua4 (boy, am I repeating myself or
what?). My only hopes are that meta-methods access will get optimized
at some point for a case when one actually uses them and that
computers are getting faster and faster allowing applications to
become a little more wasteful in terms of CPU and memory use and
letting programmers become less thoughtful at the same time.

I still don't get this.Can't some sort of caching system be
implemented.For example when settagmethod is called it can get the
values(or function pointers) of the defined metamethods and cache them
in an internal C table.Then the code to return the value of an
object(that is the __getindex or __get calls) could look like:

#define __GET somevalue

method=internal[__GET];

if(method==NULL)
    return luavalue(...);
else
    method(...);

Now that can't be so much slower than just:

return luavalue(..);

unless maybe inside a loop or something but then again lua is an
interpreted scripting language.


Reply | Threaded
Open this post in threaded view
|

RE: On lua5 and embedding

Bilyk, Alex
In reply to this post by Bilyk, Alex
Yes, the caching is done. But... To my taste it is done for the wrong case. Namely, culling non-existent meta-methods for some selected events is the fastest case (just a flag check). But access to any existing meta-method is a Lua-table lookup. I am not saying the caching is not possible, it is very much possible, I am just saying it has not been done for either shortage of time or a disregard to this particular aspect of implementation altogether. This is all theory however. In practice, this needs to be carefully benchmarked with some real world applications in mind and the decision has to be made whether or not it makes sense to do this. We are using Lua in games. Every bit of speed improvement is a benefit. If someone writes CGI scripts, networking apps or file utilities why would they care? In such cases they wouldn't notice another 10x slowdown on meta-tables. 1GHZ CPU does IO so much faster than any network or disk IO that it is utterly pointless to even bother thinking about this kind of stuff, IMHO:) In games you usually have so much other things fighting for CPU clocks withing the same application that every milisecond saved on script execution is a very desirable thing to have.

AB

-----Original Message-----
From: jimmyp_gr <[hidden email]> [[hidden email]]
Sent: Tuesday, January 28, 2003 3:31 PM
To: Multiple recipients of list
Subject: Re: On lua5 and embedding

--- In [hidden email], "Bilyk, Alex" <ABilyk@m...> wrote:
> Yeah, I was complaining about this as well. Then someone said that
__get and __set have been removed as a speed improvement. Curiously
enough, IMHO, one could actually do more with tags in Lua4 and it
would run faster as well. Meta-tables are slower and you'd want to get
rid of anything you can get away with while using them. In fact, in
current implementation of Lua5 Beta, it is partially optimized for
when one does NOT use meta-methods (Duh!  What an important case for a
language whose main virtue is meta-table based extensibility).

Strange... To me tag methods and metamethods look a lot alike.Is the
table lookup to get the method what causes the slowdown.

> Basically, as long as one runs plain vanilla Lua5 scripts they will
go pretty fast. But as soon as one starts using inheritance, call and
other meta-methods on their objects that is when the meta-method
overhead jumps in. Syntax-wise meta-tables are pretty but with respect
to functionality they are impaired feature-wise as well as speed-wise,
in may view, compared to tags in Lua4 (boy, am I repeating myself or
what?). My only hopes are that meta-methods access will get optimized
at some point for a case when one actually uses them and that
computers are getting faster and faster allowing applications to
become a little more wasteful in terms of CPU and memory use and
letting programmers become less thoughtful at the same time.

I still don't get this.Can't some sort of caching system be
implemented.For example when settagmethod is called it can get the
values(or function pointers) of the defined metamethods and cache them
in an internal C table.Then the code to return the value of an
object(that is the __getindex or __get calls) could look like:

#define __GET somevalue

method=internal[__GET];

if(method==NULL)
    return luavalue(...);
else
    method(...);

Now that can't be so much slower than just:

return luavalue(..);

unless maybe inside a loop or something but then again lua is an
interpreted scripting language.


Reply | Threaded
Open this post in threaded view
|

Re: On lua5 and embedding

Dimitris Papavasileiou
> Yes, the caching is done. But... To my taste it is done for the
wrong case. Namely, culling non-existent meta-methods for some
selected events is the fastest case (just a flag check). But access to
any existing meta-method is a Lua-table lookup. I am not saying the 

ok then.Why not implement the __get and __set metamethods and let the
user set them if he/she wants to pay the price.They're existence
wouldn't bother anyone.And besides the actual metamethod function
pointers can be cached as well(not just existence flags) just get a
pointer to the value of the key "__get".The value may change but its
place in the table should remain fixed.

In any case a solution should be worked out.This is seriously damaging
lua functionality.I'd be interested in a response from someone from
the developer team on this...


Reply | Threaded
Open this post in threaded view
|

RE: On lua5 and embedding

Bilyk, Alex
In reply to this post by Bilyk, Alex
Well, those developing the language have pretty heavy load on the their hands when it comes to satisfying every Lua user out there. The authors of the language probably have their own agenda on the future of Lua in addition to being from academia where the real world problems are looked upon through a peculiar rainbow glasses at least part-time. On the other hand, it is in people's nature to exhibit certain amount of inertia when it comes to changes. Whatever the change, there will be someone who is not satisfied with it and inevitably bitches about it. So, I usually tend to move on and deal with it rather than arguing about things to death. I am sure you have similar attitude in your work. If one day I found that this meta-table performance issue is a showstopper, I would just implement the cache myself. Looks like about a day or two of work for someone who doesn't know all ins and outs.

AB

-----Original Message-----
From: jimmyp_gr <[hidden email]> [[hidden email]]
Sent: Tuesday, January 28, 2003 5:41 PM
To: Multiple recipients of list
Subject: Re: On lua5 and embedding

> Yes, the caching is done. But... To my taste it is done for the
wrong case. Namely, culling non-existent meta-methods for some
selected events is the fastest case (just a flag check). But access to
any existing meta-method is a Lua-table lookup. I am not saying the

ok then.Why not implement the __get and __set metamethods and let the
user set them if he/she wants to pay the price.They're existence
wouldn't bother anyone.And besides the actual metamethod function
pointers can be cached as well(not just existence flags) just get a
pointer to the value of the key "__get".The value may change but its
place in the table should remain fixed.

In any case a solution should be worked out.This is seriously damaging
lua functionality.I'd be interested in a response from someone from
the developer team on this...


pau
Reply | Threaded
Open this post in threaded view
|

Re: On lua5 and embedding

pau
In reply to this post by Dimitris Papavasileiou
On Tue, Jan 28, 2003 at 07:11:30PM -0000, jimmyp_gr <[hidden email]> wrote:
>
> btw why the distinction between full and light userdata in Lua5.Light
> ones can be implemented with full ones anyway(using a full userdata of
> size sizeof(void *)).I know it's not so important but it seems to me
> that it unnecessarily adds complexity when lua's goal seems to be
> simplicity.

I guess the "light-weight" userdata is to ease the burden on Lua's
internals whenever necessasry, i.e., no meta table bookkeeping
stuff.

However, my biggest complaint of lua5 is now there seems no way to
define a "heavy-weight" userdata without using Lua's memory allocation
method. I can no longer define a GC method for pure C pointers. 
When it occurred to me almost impossible to convert my program to
Lua5, I'd still stick with Lua4 for now.

Or I could be wrong on this, can somebody enlighten me please?

Regards,
.paul.

Reply | Threaded
Open this post in threaded view
|

Re: On lua5 and embedding

Michael Naunton
I'd like enlightenment too. I currently just punted and wrote a C++
wrapper template to push userdata as a T*, classTag pair. That way I can
at least allocate my real data in mempools, etc, and vector GC stuff to
the real class. Ugly as hell, but at least the ugliness is contained.

- mike

[hidden email] wrote:

>I guess the "light-weight" userdata is to ease the burden on Lua's
>internals whenever necessasry, i.e., no meta table bookkeeping
>stuff.
>
>However, my biggest complaint of lua5 is now there seems no way to
>define a "heavy-weight" userdata without using Lua's memory allocation
>method. I can no longer define a GC method for pure C pointers. 
>When it occurred to me almost impossible to convert my program to
>Lua5, I'd still stick with Lua4 for now.
>
>Or I could be wrong on this, can somebody enlighten me please?
>
>Regards,
>.paul.
>
>  
>




Reply | Threaded
Open this post in threaded view
|

Re: On lua5 and embedding

Alex Bilyk
In my port of Lua 4 based application I just create full user data with
a "__gc" for my C++ pointers. It's all done in a tag emulation layer.
What else is there to do? Ideas?

I have just finished implemlementation for coroutines; have not tested
them yet. Basically I ended up creating a user data with every coroutine
because Lua threads/coroutines don't support "__gc" (nor any other
events for that matter). For coroutines, I wanted to have an aility to
kill them at will and so ended up doing an ID based API instead of
original lua_State* based one. In addition I needed to deallocate some
C++ objects associated with coroutines whenever they are killed. As a
consequence coroutines now have to kill themselves or be killed by
somone else explicitly now or they will persist until lua_close is
called otherwise. But this can be reprogrammed at Lua level.

Michael Naunton wrote:

>I'd like enlightenment too. I currently just punted and wrote a C++
>wrapper template to push userdata as a T*, classTag pair. That way I can
>at least allocate my real data in mempools, etc, and vector GC stuff to
>the real class. Ugly as hell, but at least the ugliness is contained.
>
I don't quite understand how you can save on full user data allocations
using <class*, tag> pairs. You would still need to have a full user data
per pair, wouldn't you? You could wire it to a single "__gc" handler,
but allocations... Hmm.

AB

>
>- mike
>
>[hidden email] wrote:
>
>  
>
>>I guess the "light-weight" userdata is to ease the burden on Lua's
>>internals whenever necessasry, i.e., no meta table bookkeeping
>>stuff.
>>
>>However, my biggest complaint of lua5 is now there seems no way to
>>define a "heavy-weight" userdata without using Lua's memory allocation
>>method. I can no longer define a GC method for pure C pointers. 
>>When it occurred to me almost impossible to convert my program to
>>Lua5, I'd still stick with Lua4 for now.
>>
>>Or I could be wrong on this, can somebody enlighten me please?
>>
>>Regards,
>>.paul.
>>
>> 
>>
>>    
>>
>
>
>
>
>  
>



Reply | Threaded
Open this post in threaded view
|

Re: On lua5 and embedding

Michael Naunton
Alex Bilyk wrote:

>Michael Naunton wrote:
>I'd like enlightenment too. I currently just punted and wrote a C++
>wrapper template to push userdata as a T*, classTag pair. That way I can
>at least allocate my real data in mempools, etc, and vector GC stuff to
>the real class. Ugly as hell, but at least the ugliness is contained.
>
>I don't quite understand how you can save on full user data allocations
>using <class*, tag> pairs. You would still need to have a full user data
>per pair, wouldn't you? You could wire it to a single "__gc" handler,
>but allocations... Hmm.
>
Sorry to not make myself clear - I accept the full user data
allocations. I just stick it in a wrapper hoping that either a) the
overhead will not prove to be too high, or b) someone will enlighten me
and then I rewrite my wrapper class.

>  
>


pau
Reply | Threaded
Open this post in threaded view
|

Re: On lua5 and embedding

pau
A TAG wrapper around lua5's userdata could be handy in porting
lua4 applications to lua5. But a hack is hack, no matter
how clever it is. At least for me, I don't see much advantage
in doing so. Extra wrapper for thousands of userdata used
in my program could be a serious overhead.

The real question is, can lua5 be improved to deal with 
heavy-weight userdata without using Lua's own malloc?

Regards, 
.paul.

On Wed, Jan 29, 2003 at 02:10:19AM -0500, Michael Naunton wrote:
> Alex Bilyk wrote:
> 
> >Michael Naunton wrote:
> >I'd like enlightenment too. I currently just punted and wrote a C++
> >wrapper template to push userdata as a T*, classTag pair. That way I can
> >at least allocate my real data in mempools, etc, and vector GC stuff to
> >the real class. Ugly as hell, but at least the ugliness is contained.
> >
> >I don't quite understand how you can save on full user data allocations
> >using <class*, tag> pairs. You would still need to have a full user data
> >per pair, wouldn't you? You could wire it to a single "__gc" handler,
> >but allocations... Hmm.
> >
> Sorry to not make myself clear - I accept the full user data
> allocations. I just stick it in a wrapper hoping that either a) the
> overhead will not prove to be too high, or b) someone will enlighten me
> and then I rewrite my wrapper class.
> 

Reply | Threaded
Open this post in threaded view
|

Re: On lua5 and embedding

Roberto Ierusalimschy
> A TAG wrapper around lua5's userdata could be handy in porting
> lua4 applications to lua5. But a hack is hack, no matter
> how clever it is. At least for me, I don't see much advantage
> in doing so. Extra wrapper for thousands of userdata used
> in my program could be a serious overhead.
> 
> The real question is, can lua5 be improved to deal with 
> heavy-weight userdata without using Lua's own malloc?

Maybe what is not very clear is that Lua 4.0 did that too. Everytime you
pushed a new userdata in Lua 4.0 it created a wrapper for your pointer,
exactly as Lua 5.0 does. But that creation was hidden from the user. Lua
5.0 only makes things more explicit: if you want a wrapper, you create
the wrapper. Another difference is that Lua 4.0 would coalesce a new
userdata into an old one if they have the same value. Lua 5.0 does not
do that, but it is easy to do that yourself if that is what you want
(that is what light userdata are for); and you do not have to do it
(and pay the price) if you do not need/want it.

-- Roberto

Frequently the problem is not performance, but the perception people
have about performance.

Reply | Threaded
Open this post in threaded view
|

Re: On lua5 and embedding

Roberto Ierusalimschy
In reply to this post by Dimitris Papavasileiou
> Basically, as long as one runs plain vanilla Lua5 scripts they will
> go pretty fast. But as soon as one starts using inheritance, call and
> other meta-methods on their objects that is when the meta-method
> overhead jumps in.

Can you give us your performance measures and details of your tests
(platform, etc.)? In our own tests, we did not detect any significant
difference between tag methods in Lua 4.0 and metamethods in Lua 5.0b.

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: On lua5 and embedding

Luiz Henrique de Figueiredo
In reply to this post by Dimitris Papavasileiou
>I guess the "light-weight" userdata is to ease the burden on Lua's
>internals whenever necessasry, i.e., no meta table bookkeeping
>stuff.

Right. But that was a request by the community: many people want simply to
store C pointers in Lua with as little overhead as possible to retrieve them
later. These C pointers point to areas that are managed by the application abd
they don't care whether there are references to it in Lua or not (and so need
not be told about GC for them).

>However, my biggest complaint of lua5 is now there seems no way to
>define a "heavy-weight" userdata without using Lua's memory allocation
>method.

By definition, that's what "heavy-weight" userdata is. Or is your complaint
about the use of Lua's memory allocation? You can always compile Lua to use
your own memory allocation method.

>I can no longer define a GC method for pure C pointers. 

You can "box" them inside a heavy userdata. C pointers that do not need GC
methods can be stored in light userdata.

For discussions of heavy x light userdata, search the lua-l archives for
lua_newuserdata. For instance:
   http://lua-users.org/lists/lua-l/2002-11/msg00062.html
   http://lua-users.org/lists/lua-l/2002-08/msg00162.html

>When it occurred to me almost impossible to convert my program to
>Lua5, I'd still stick with Lua4 for now.

Why impossible? The move to Lua 5 is meant to gain more users not lose them! :-(
Please, tell us how we can help.

It worries me that some people seem to have a negative impression of Lua 5
so near to it being officially released. Someone even said that we have
"seriously damaged Lua functionality"! Sure, Lua 5 is different from Lua 4.
The metamethod scheme is not the same as the tagmethod scheme, but it is
simpler and more flexible, even if sometimes you have to use proxy tables
for doing some stuff that was easy in Lua 4. Lua 5 was the outcome of a long
sequence of work versions of Lua 4.1 and has gone through alpha and now beta
stages. I'd think major design flaws would be found by now :-(
--lhf

Reply | Threaded
Open this post in threaded view
|

SV: On lua5 and embedding

Erik Hougaard
Here is thing, you need to write a LTN describing how to handle pointers,
with examples. How it was done in 4 and what to do in 5.

"The worst thing you gave people is a choice - then they *will* select the
wrong one"

/Erik


-----Oprindelig meddelelse-----
It worries me that some people seem to have a negative impression of Lua 5
so near to it being officially released. Someone even said that we have
"seriously damaged Lua functionality"! Sure, Lua 5 is different from Lua 4.
The metamethod scheme is not the same as the tagmethod scheme, but it is
simpler and more flexible, even if sometimes you have to use proxy tables
for doing some stuff that was easy in Lua 4. Lua 5 was the outcome of a long
sequence of work versions of Lua 4.1 and has gone through alpha and now beta
stages. I'd think major design flaws would be found by now :-(
--lhf


pau
Reply | Threaded
Open this post in threaded view
|

Re: On lua5 and embedding

pau
In reply to this post by Luiz Henrique de Figueiredo
On Wed, Jan 29, 2003 at 08:11:49AM -0200, Luiz Henrique de Figueiredo wrote:
> 
> Right. But that was a request by the community: many people want simply to
> store C pointers in Lua with as little overhead as possible to retrieve them
> later. These C pointers point to areas that are managed by the application abd
> they don't care whether there are references to it in Lua or not (and so need
> not be told about GC for them).

Yes, I certainly appreciate the design of light-weight userdata, it is
very clean for its purpose.
 
> By definition, that's what "heavy-weight" userdata is. Or is your complaint
> about the use of Lua's memory allocation? You can always compile Lua to use
> your own memory allocation method.

I meant pointers returned from some other library, of which the programmer
has no control over their memory allocation, and yet wants to leverage on 
Lua's GC for management.
 
> >I can no longer define a GC method for pure C pointers. 
> 
> You can "box" them inside a heavy userdata. C pointers that do not need GC
> methods can be stored in light userdata.

"boxing" is kind of different from the in Lua4, since uniqueness isn't
preserved. Using weak tables may help to nail down the problem, but not
really ease the burden on programmers since now there is an extra table 
to be either "globally" referenced or "passed around" when needed.

BTW, thanks for the links. I wasn't aware of the lua_(un)boxpointer macros.
 
> >When it occurred to me almost impossible to convert my program to
> >Lua5, I'd still stick with Lua4 for now.
> 
> Why impossible? The move to Lua 5 is meant to gain more users not lose
> them! :-( Please, tell us how we can help.

I shouldn't have said "impossible", but the trouble with my program is
in its sheer size. Unless there is a painless migration by a wrapper 
interface "identical" to Lua4's tag mechanism, I am quite reluctant to
make the decision.

And even with such a wrapper in hand, the memory/performance gain isn't
very appealing, given the extra overhead of 1) the box itself; 2) weaktables
that map all boxed value to unboxed value; 3) metatable for every tag.
The overhead could be quite serious for memory management under a 
runtime situation where lots of userdata is created/freed every second.

Unless, of course, if Lua6 delivers the progressive GC promise. That'll
be the ultimate reason for porting all my Lua4 applications over ;-)

> It worries me that some people seem to have a negative impression of Lua 5
> so near to it being officially released. Someone even said that we have
> "seriously damaged Lua functionality"! Sure, Lua 5 is different from Lua 4.
> The metamethod scheme is not the same as the tagmethod scheme, but it is
> simpler and more flexible, even if sometimes you have to use proxy tables
> for doing some stuff that was easy in Lua 4. Lua 5 was the outcome of a long
> sequence of work versions of Lua 4.1 and has gone through alpha and now beta
> stages. I'd think major design flaws would be found by now :-(

The problem I've raised is certainly not a design flaw, but it does
pose some resistence for people to port old apps onto new Lua version,
especially which the old one works just fine. I'll consider adopting 
Lua5 in new porgrams by adjusting the design to take advantage of Lua5's
own merits. 

Regards,
.paul.

Reply | Threaded
Open this post in threaded view
|

Re: On lua5 and embedding

Dirk Zoller-2
In reply to this post by Luiz Henrique de Figueiredo

Hello list,

first I must apologize that I entirely missed the alpha and most of the
beta phase of Lua-5 being so happy with Lua-4.

It worries me that some people seem to have a negative impression of Lua 5
so near to it being officially released. Someone even said that we have
"seriously damaged Lua functionality"! Sure, Lua 5 is different from Lua 4.
The metamethod scheme is not the same as the tagmethod scheme, but it is
simpler and more flexible, even if sometimes you have to use proxy tables
for doing some stuff that was easy in Lua 4. Lua 5 was the outcome of a long
sequence of work versions of Lua 4.1 and has gone through alpha and now beta
stages. I'd think major design flaws would be found by now :-(
--lhf

My impression is that if you can change something for the better then you
do it. Whatever it costs. I like this. Although for example the massive
changes in Lua's C-API from version 3.2 to 4.0 meant a lot of work for me.
(It is clearly better now, but please don't do this again.)

Now I'm a little concerned hearing about massive changes to userdata and tag
methods, both concepts we use a lot. I will continue with Lua-4 until I have
a week or so of time to tackle the changes needed for Lua-5.

This my statement is of no technical value whatsoever. All I want to say is
keep up the good work but don't be surprised if your users don't follow the
pace.

Dirk


Reply | Threaded
Open this post in threaded view
|

Re: On lua5 and embedding

Dimitris Papavasileiou
In reply to this post by Luiz Henrique de Figueiredo
> It worries me that some people seem to have a negative impression of
Lua 5
> so near to it being officially released. Someone even said that we have
> "seriously damaged Lua functionality"! Sure, Lua 5 is different from
Lua 4.
> The metamethod scheme is not the same as the tagmethod scheme, but it is
> simpler and more flexible, even if sometimes you have to use proxy
tables
> for doing some stuff that was easy in Lua 4. Lua 5 was the outcome
of a long
> sequence of work versions of Lua 4.1 and has gone through alpha and
now beta
> stages. I'd think major design flaws would be found by now :-(

Maybe I shouldn't have said "seriously damaged Lua functionality"...
If metamethods are so few because there is no other way(to implement
more and cleanly) then proxy tables etc. will do.It just seems strange
(design-wise)that there should be a metamethod only for getting and
setting a table for the first time etc. which forces people to use
workarounds to implement common stuff.


Reply | Threaded
Open this post in threaded view
|

Re: On lua5 and embedding

Juergen Fuhrmann
>  Wed, 29 Jan 2003 12:07:04 -0000
>  "jimmyp_gr <[hidden email]>" <[hidden email]> wrote:
>
>  > It worries me that some people seem to have a negative impression of
>  Lua 5
>  > so near to it being officially released. Someone even said that we have
>  > "seriously damaged Lua functionality"! Sure, Lua 5 is different from
>  Lua 4.
>  > The metamethod scheme is not the same as the tagmethod scheme, but it is
>  > simpler and more flexible, even if sometimes you have to use proxy
>  tables
>  > for doing some stuff that was easy in Lua 4. Lua 5 was the outcome
>  of a long
>  > sequence of work versions of Lua 4.1 and has gone through alpha and
>  now beta
>  > stages. I'd think major design flaws would be found by now :-(
>  
>  Maybe I shouldn't have said "seriously damaged Lua functionality"...
>  If metamethods are so few because there is no other way(to implement
>  more and cleanly) then proxy tables etc. will do.It just seems strange
>  (design-wise)that there should be a metamethod only for getting and
>  setting a table for the first time etc. which forces people to use
>  workarounds to implement common stuff.
>  
Hi,

IMHO  these  issues could  be  resolved  by  providing and  supporting
different  API layers.  We  had this  already: a  Lua3.1 compatibility
layer for  Lua4. Users  seem to have  different needs of  going deeply
into the C binding stuff. Some  really need every trick, and some just
want  to get  bound  their  code, without  worrying  about details  of
performance. 

I did not try out Lua5 so  far mainly for lack of time (which will not
change in the  near future :-( ).  Another reason is  that we base our
development on  tolua4.0 now.  While  having some flaws, this  tool is
really cool. Performance bottlenecks in  our case are seldom and could
be  tweaked by hand  just by  patching tolua  output.  If  tolua would
support Lua5,  I would not hesitate  to switch.  If it  will remain on
lua4, I will stick  with that for a long time (which  is no problem as
the source is that clean that one is able to understand it in order to
resolve possible bugs).

IMHO we could  have two or three supported API layers for Lua:
1) low level: the actual API we have now which may change quite completely with
   major releases
2) high level: for the "vanilla" user. Thus  could remain quite constant
   over  releases
3) tolua with some improvements



just my EUR 0.02

Juergen



Reply | Threaded
Open this post in threaded view
|

Re: On lua5 and embedding

Luiz Henrique de Figueiredo
In reply to this post by Dimitris Papavasileiou
>As for the __get and __set issue, proxy tables can
>indeed be used, however, it would be nice if there was 
>an example in the official distribution.

See readonly.lua, trace-globals.lua, and undefined.lua in test/ .
They use limited proxies (not totally empty tables), though.

>I think better documentation is what Lua 5 needs now the most. 

Right. I agree.
--lhf

12