Re:[ANNOUNCE] LuaThreads 1.0.1 (for Lua 5.0-work0)

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

Re:[ANNOUNCE] LuaThreads 1.0.1 (for Lua 5.0-work0)

Philippe Lhoste
Diego Nehab wrote:
> LuaThreads 1.0.1 for Lua 5.0-work0 is now available for download.

BTW, I will ask Lua authors to go fetch their crystal ball ;-)
Do you think the C API (including lauxlib) of Lua 5.0 will be pretty stable
now, or may it still have some deep changes, like those from Lua 4.0-work4 to
Lua 5.0-work0?

Minor changes are, for me, renaming a function, changing a parameter here or
there, or adding new functions.
Major changes are, for example, the handling of userdata or the use of
luaL_opennamedlib.

The purpose of the question is actually to know if we can start coding using
this version, coping with small changes as working on Lua goes, or does we
risk to have to rewrite major parts of the applications/libraries if we dare
to use this unofficial and experimental release?

Regards.

-- 
--=#=--=#=--=#=--=#=--=#=--=#=--=#=--=#=--=#=--
Philippe Lhoste (Paris -- France)
Professional programmer and amateur artist
http://jove.prohosting.com/~philho/
--=#=--=#=--=#=--=#=--=#=--=#=--=#=--=#=--=#=--

GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net


Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCE] LuaThreads 1.0.1 (for Lua 5.0-work0)

John Belmonte-2
Philippe Lhoste wrote:
BTW, I will ask Lua authors to go fetch their crystal ball ;-)
Do you think the C API (including lauxlib) of Lua 5.0 will be pretty stable
now, or may it still have some deep changes, like those from Lua 4.0-work4 to
Lua 5.0-work0?

I don't see how they could make such a promise, when API and feature changes occured on 4.0 even between alpha, beta, and release.

The purpose of the question is actually to know if we can start coding using
this version, coping with small changes as working on Lua goes, or does we
risk to have to rewrite major parts of the applications/libraries if we dare
to use this unofficial and experimental release?

Exactly. Now, before the Lua authors say "this is not worth the trouble so let's stop experimental releases", note that this same issue exists for alpha and beta versions too. When someone starts a project, commercial or otherwise, they must make the decision to go with the old stable version, or anticipate the upcoming version. If an alpha or beta release looks good (or even an experimental release, as we have witnessed with all the recent anouncements), many choose to bet on the upcoming version.

I'd ask the Lua authors to consider that many people need to track their releases. It would help if there was a pattern of convergence as the final release is approached. It would help if some simple policy where defined (for example, no API changes between beta and final release) and adhered to, so that people tracking the releases know what to expect.

-John


--
http:// i      .   /


Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCE] LuaThreads 1.0.1 (for Lua 5.0-work0)

Roberto Ierusalimschy
In reply to this post by Philippe Lhoste
> It would help if some simple policy where defined (for example, no API
> changes between beta and final release) and adhered to, so that people
> tracking the releases know what to expect.

We intend to do that: Only minor changes from alpha to beta, no external
changes from beta to final (unless forced by bugs or other major
disasters). That is why we did not release Lua 5.0 alpha yet.

(Minor changes == "renaming a function, changing a parameter here or
there, or adding new functions")


> BTW, I will ask Lua authors to go fetch their crystal ball ;-) Do
> you think the C API (including lauxlib) of Lua 5.0 will be pretty
> stable now, or may it still have some deep changes, like those from
> Lua 4.0-work4 to Lua 5.0-work0?

It is not stable :-(  That is one of the reasons this is not an alpha
version. As far as our crystal ball can tell, the coming non-minor
changes are

- error handling ("pcall" won't get an "errf" parameter)

- lua_setglobals/lua_getglobals (now, each Lua function has it own
global table)

- hooks: there will be only one hook function, which can be called in
several different events (calls, returns, line change, instruction
count).

-- Roberto


Reply | Threaded
Open this post in threaded view
|

remote debug

Tristan Rybak-2
In reply to this post by Philippe Lhoste
I am thinking where to keep information about breakpoints during remote
debug:
1. send all breakpoint information to client debug stub -> for small
embedded environments it has a big hit on memory...
2. keep all debug info in debugger -> big hit on performance because client
must ask debugger every debug line what to do.
What do You gurus think?
Cheers
Tristan



Reply | Threaded
Open this post in threaded view
|

Re: remote debug

Björn De Meyer
Tristan Rybak wrote:
> 
> I am thinking where to keep information about breakpoints during remote
> debug:
> 1. send all breakpoint information to client debug stub -> for small
> embedded environments it has a big hit on memory...
> 2. keep all debug info in debugger -> big hit on performance because client
> must ask debugger every debug line what to do.
> What do You gurus think?

This may sound silly, but why not program both and make 
it an option? Either approach has benefits
and problems, so allowing the user to choose might be 
the best solution. That way you can have your bread and eat it.

You could also split up the breakpoint data between the client and 
debugger in some clever way, of course.
 

-- 
"No one knows true heroes, for they speak not of their greatness." -- 
Daniel Remar.
Björn De Meyer 
[hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: remote debug

Benoit Germain
In reply to this post by Tristan Rybak-2
I am currently experimenting with such a scheme (lua state + debug stub on
target platform, binding to a tcp socket opened by the server side).
What I do is store all relevant information in the host application, and the
debugger is only a display (i am concentrating on the debugger features, and
my display is a console for now). Everything is stored in a table created in
the state's registry, including breakpoints.
Those are in a separate table, where the key is a string formed from the
file name and the line number, and the value is a lua string. The line hook
fetches an entry in this table, if non-nil, evaluates the lua string, and
breaks if the result is non-nil.
Since I don't intend to have several dozens breakpoints when debugging, I
hope the memory penalty should remain reasonable. Not sure a table access at
every line will speed up things, though :-)

Well, I'm not done yet, but I see no reason why it would not work, unless
evaluating a lua string is not possible inside the line hook ?

Cheers,

Benoit

> -----Original Message-----
> From: Tristan Rybak [[hidden email]]
> Sent: jeudi 4 juillet 2002 21:19
> To: Multiple recipients of list
> Subject: remote debug
> 
> 
> I am thinking where to keep information about breakpoints 
> during remote
> debug:
> 1. send all breakpoint information to client debug stub -> for small
> embedded environments it has a big hit on memory...
> 2. keep all debug info in debugger -> big hit on performance 
> because client
> must ask debugger every debug line what to do.
> What do You gurus think?
> Cheers
> Tristan
> 
> 

Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCE] LuaThreads 1.0.1 (for Lua 5.0-work0)

Thomas Wrensch-2
In reply to this post by Roberto Ierusalimschy
On Thu, 4 Jul 2002, Roberto Ierusalimschy wrote:

> - error handling ("pcall" won't get an "errf" parameter)

Hmm, how will you support error handling then?
 
> - lua_setglobals/lua_getglobals (now, each Lua function has it own
> global table)

Good! This should ease a number of minor problems I was having.

> - hooks: there will be only one hook function, which can be called in
> several different events (calls, returns, line change, instruction
> count).

I guess this is the answer to my first question?



  - Tom Wrensch


Reply | Threaded
Open this post in threaded view
|

Re: remote debug

Tristan Rybak-2
In reply to this post by Benoit Germain
It's very fast when you have all breapoint data locally (in debugger where
program goes)
But what if user wants to set breakpoint during program execution? or do a
execution break?
I have to ask debugging editor about every execution line in that situation.
Cheers

----- Original Message -----
From: "Benoit Germain" <[hidden email]>
To: "Multiple recipients of list" <[hidden email]>
Sent: Friday, July 05, 2002 9:47 AM
Subject: RE: remote debug


> I am currently experimenting with such a scheme (lua state + debug stub on
> target platform, binding to a tcp socket opened by the server side).
> What I do is store all relevant information in the host application, and
the
> debugger is only a display (i am concentrating on the debugger features,
and
> my display is a console for now). Everything is stored in a table created
in
> the state's registry, including breakpoints.
> Those are in a separate table, where the key is a string formed from the
> file name and the line number, and the value is a lua string. The line
hook
> fetches an entry in this table, if non-nil, evaluates the lua string, and
> breaks if the result is non-nil.
> Since I don't intend to have several dozens breakpoints when debugging, I
> hope the memory penalty should remain reasonable. Not sure a table access
at
> every line will speed up things, though :-)
>
> Well, I'm not done yet, but I see no reason why it would not work, unless
> evaluating a lua string is not possible inside the line hook ?
>
> Cheers,
>
> Benoit
>
> > -----Original Message-----
> > From: Tristan Rybak [[hidden email]]
> > Sent: jeudi 4 juillet 2002 21:19
> > To: Multiple recipients of list
> > Subject: remote debug
> >
> >
> > I am thinking where to keep information about breakpoints
> > during remote
> > debug:
> > 1. send all breakpoint information to client debug stub -> for small
> > embedded environments it has a big hit on memory...
> > 2. keep all debug info in debugger -> big hit on performance
> > because client
> > must ask debugger every debug line what to do.
> > What do You gurus think?
> > Cheers
> > Tristan
> >
> >
>


Reply | Threaded
Open this post in threaded view
|

RE: remote debug

Benoit Germain
In reply to this post by Tristan Rybak-2

> -----Original Message-----
> From: Tristan Rybak [[hidden email]]
> Sent: dimanche 7 juillet 2002 05:17
> To: Multiple recipients of list
> Subject: Re: remote debug
> 
> 
> It's very fast when you have all breapoint data locally (in 
> debugger where
> program goes)

This is the case. The debugger state is stored in the registry of the lua
state.

> But what if user wants to set breakpoint during program 
> execution? or do a
> execution break?

No problem, I have set up a tcp/ip socket which is polled inside the line
hook: the interface can send whatever commands it wants, the debugger will
be updated at tne next line hook call. The drawback I see is that socket
polling might slow down the state's execution quite mightily, along with the
table lookup so see if a breakpoint is encountered. But I am not done
implementing the stuff, so no benchmarking has benn done so far.

> I have to ask debugging editor about every execution line in 
> that situation.
> Cheers
> 

Regards,

Benoit.