is this list really alive?

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

is this list really alive?

Luiz Henrique de Figueiredo-5
Listproc has been having problems with the new sendmail installed at tecgraf.
This message is just to see if everything is ok now.

This happened during the last 10 days or so.
It seems that messages to lua-l were not distributed, but were archived.
So, I've updated the archive at
        ftp://ftp.tecgraf.puc-rio.br/pub/lua/lua-l-archive.gz
--lhf

Reply | Threaded
Open this post in threaded view
|

Re: is this list really alive?

Erik Hougaard
Luiz Henrique de Figueiredo wrote:
> 
> Listproc has been having problems with the new sendmail installed at tecgraf.
> This message is just to see if everything is ok now.
> 
> This happened during the last 10 days or so.
> It seems that messages to lua-l were not distributed, but were archived.
> So, I've updated the archive at
>         ftp://ftp.tecgraf.puc-rio.br/pub/lua/lua-l-archive.gz
> --lhf

I got that message - Now that you opened a random thread - Let me throw
this question out:

Has any of you done any debugging stuff - the ldb looks nice but has
some serious design issues regarding states and some bugs just to finish
it of?

Erik

Reply | Threaded
Open this post in threaded view
|

Lua release form

Erik Hougaard
In reply to this post by Luiz Henrique de Figueiredo-5
I was thinking:

When Lua 3.2 (or whatever the version might be) is release, how about
distributing the RCS diff between 3.1 and 3.2. That would be a great
help for us who have done heavy modifications on the base Lua ?

Erik

p.s. Just a though now that the list is back up??

Reply | Threaded
Open this post in threaded view
|

Re: is this list really alive?

Luiz Henrique de Figueiredo
In reply to this post by Luiz Henrique de Figueiredo-5
>From: [hidden email] (Erik Hougaard)
>
>I got that message

yes, it seems that lua-l is back.

>Has any of you done any debugging stuff - the ldb looks nice but has
>some serious design issues regarding states and some bugs just to finish
>it of?

ldb has been revised recently. see http://www.tecgraf.puc-rio.br/~tomas/ldb/

what are these "serious design issues" and bugs?
you could post them here or send them directly to Tomás Guisasola Gorham at
[hidden email] (also cc: [hidden email]).

thanks.
--lhf

Reply | Threaded
Open this post in threaded view
|

Re: is this list really alive?

Erik Hougaard

Luiz Henrique de Figueiredo wrote:
> what are these "serious design issues" and bugs?
> you could post them here or send them directly to Tomás Guisasola Gorham at
> [hidden email] (also cc: [hidden email]).

Design issue: ldb is designed with only one state in mind, if you are
running multible states (like multitasking) ldb starts acting strange
(Like a breakpoint jumping to a different state !! My solution was to
add the debug information into the state structure.

The bugs are related to setting breakpoints. (Like a break(20) to break
at line 20). The code for setting the loc->file on a linenumber basis
(Within the get_location) does not update curr_loc.file at all. My
solution was to do a:

 f = lua_stackedfunction(1);
 lua_funcinfo(f,&curr_loc.file,&curr_loc.line);

before assigning loc->file

I some cases the update_location does funky stuff also, but I havent
found it yet!

Erik

p.s. It was not sent as a flame or anything . I was just getting used to
the very high quality of the Lua source!!

Reply | Threaded
Open this post in threaded view
|

Re: is this list really alive?

Jay Glascoe
In reply to this post by Luiz Henrique de Figueiredo-5
ping.

;)

Reply | Threaded
Open this post in threaded view
|

Re: is this list really alive?

Kevin J. Craig
pong.
;)

Jay Glascoe wrote:

> ping.
>
> ;)
begin:vcard 
n:J. Craig;Kevin
tel;fax:439-6374
tel;work:430-0164
x-mozilla-html:TRUE
url:www.bioware.com
org:BioWare Corporation;QA
adr:;;;Edmonton;Alberta;T6E-6H2;Canada
version:2.1
email;internet:[hidden email]
title:Lead Beta Tester/Designer
note;quoted-printable:(ICQ: 1971204)=0D=0A"I have lived no cloistered life and hold in contempt the wise man who has not lived and the scholar who will not share. There have been many wiser men than I, but few have traveled as much road. I have seen life from the top down and the bottom up. I know how it looks both ways. And I know there is wisdom and that there is hope." -L. Ron Hubbard
x-mozilla-cpt:;23376
fn:Kevin J. Craig
end:vcard
Reply | Threaded
Open this post in threaded view
|

About Ldb

Tomas Guisasola Gorham-2
In reply to this post by Erik Hougaard
> Design issue: ldb is designed with only one state in mind, if you are
> running multible states (like multitasking) ldb starts acting strange
> (Like a breakpoint jumping to a different state !! My solution was to
> add the debug information into the state structure.
	We knew that since the beginning of the project.  But we hadn't
time to spend and decided to wait until someone ask for.  I think there
are other people doing something like that.

> The bugs are related to setting breakpoints. (Like a break(20) to break
> at line 20). The code for setting the loc->file on a linenumber basis
> (Within the get_location) does not update curr_loc.file at all. My
> solution was to do a:
> 
>  f = lua_stackedfunction(1);
>  lua_funcinfo(f,&curr_loc.file,&curr_loc.line);
> 
> before assigning loc->file
	This was my last update (october, 1998).  Did you checked it?
I didn't tested it very much...  And it seemed to me that no one was
really using the tool.

	Please, send me all bugs you find, ok?
		Tomas

Reply | Threaded
Open this post in threaded view
|

Re: About Ldb

Erik Hougaard-2

Tomas Guisasola Gorham wrote:

>         This was my last update (october, 1998).  Did you checked it?
> I didn't tested it very much...  And it seemed to me that no one was
> really using the tool.

Well, anybody else but me using it (And how?) ??

Erik

Reply | Threaded
Open this post in threaded view
|

Re: About Ldb

Erik Hougaard-2
In reply to this post by Tomas Guisasola Gorham-2
>         This was my last update (october, 1998).  Did you checked it?
> I didn't tested it very much...  And it seemed to me that no one was
> really using the tool.
>
>         Please, send me all bugs you find, ok?
>                 Tomas

Well I have pretty much rewritten it at this point. These are the problems I
have found so far:

- (This is actual a lua thing) The lua_linehook and lua_callhook should be in
the state
- The whole thing about states (I have moved all the ldb stuff into the
state)
- The curr_loc.file does not get updated correct in all cases (get_location)
- Deleting a breakpoint  behaves funny (set 3 and delete the first!)
- I have a problem with the way file is declared in struct loc (*char)
because garbage collection might free the string that the location is pointed
to (If the breakpoint is set within a file that a dofile is performed on
several times). I planning on changing the loc.file to a char[filenamelength]
but I will ofcause keep the curr_loc.file as a *char for performance. (I
might need to check the ref stuff more in details - But I seems that there is
a problem there!)

Some of the stuff might not be a problem for you, but I need to make the
system foolproof to make sure that my users cannot crash the it by writing
funky code .

I'm rewriting the whole thing because I need the multistate debugging
function (The "debugger" userinterface is running in one state and the
"debugged" program in another state) and I'm working om a networked debugger
(The debugger running on one machine and the debugged state on another) via
my RPC library!

Erik

Reply | Threaded
Open this post in threaded view
|

Re: About Ldb

Tomas Guisasola Gorham-2
	Hi Erik,

> Well I have pretty much rewritten it at this point. These are the problems I
> have found so far:
> 
> - (This is actual a lua thing) The lua_linehook and lua_callhook should be in
> the state
> - The whole thing about states (I have moved all the ldb stuff into the
> state)
> - The curr_loc.file does not get updated correct in all cases (get_location)
> - Deleting a breakpoint  behaves funny (set 3 and delete the first!)
> - I have a problem with the way file is declared in struct loc (*char)
> because garbage collection might free the string that the location is pointed
> to (If the breakpoint is set within a file that a dofile is performed on
> several times). I planning on changing the loc.file to a char[filenamelength]
> but I will ofcause keep the curr_loc.file as a *char for performance. (I
> might need to check the ref stuff more in details - But I seems that there is
> a problem there!)
> 
> Some of the stuff might not be a problem for you, but I need to make the
> system foolproof to make sure that my users cannot crash the it by writing
> funky code .
> 
> I'm rewriting the whole thing because I need the multistate debugging
> function (The "debugger" userinterface is running in one state and the
> "debugged" program in another state) and I'm working om a networked debugger
> (The debugger running on one machine and the debugged state on another) via
> my RPC library!
	Great!  I was thinking...  Why don't you become the responsible
for the debugger?  I'm not using it anymore...  I'm planning a debugger
made in Lua to work with CGILua, which is the system I use at work!  What
do you think?

	Bye,
		Tomas

Reply | Threaded
Open this post in threaded view
|

Re: About Ldb

Erik Hougaard

Tomas Guisasola Gorham wrote:
>         Great!  I was thinking...  Why don't you become the responsible
> for the debugger?  I'm not using it anymore...  I'm planning a debugger
> made in Lua to work with CGILua, which is the system I use at work!  What
> do you think?

Well I think the big question here is if there is any bodywho is
interessed in a debugger for Lua - and in what shape?

Quick Poll: (please answer everybody!)

1. Are you using ldb (And how)?:
2. Are you interessed in a debugger for Lua ?:
3. What functionality whould you want from a Lua Debugger ?:

Erik

Reply | Threaded
Open this post in threaded view
|

RE: About Ldb

Ashley Fryer-2
>
> 1. Are you using ldb (And how)?:

No.

> 2. Are you interessed in a debugger for Lua ?:

Yes.

> 3. What functionality whould you want from a Lua Debugger ?:

I'm used to VC++, so I'd want at least comparable functionality.  Single
step, step in, step out, break execution, set break-points, conditional
breaks, look at the call stack.  Perhaps ldb already does these things ( I
haven't tried it ), but that's what I'd want.

ashley


Reply | Threaded
Open this post in threaded view
|

Re: About Ldb

Steve Dekorte-4
> > 3. What functionality whould you want from a Lua Debugger ?:
> 
> I'm used to VC++, so I'd want at least comparable functionality.  Single
> step, step in, step out, break execution, set break-points, conditional
> breaks, look at the call stack.  Perhaps ldb already does these things ( I
> haven't tried it ), but that's what I'd want.

I'd also want to be able to view and set local variables, and execute an 
input string.

Steve

Reply | Threaded
Open this post in threaded view
|

Re: About Ldb

Luiz Henrique de Figueiredo
In reply to this post by Tomas Guisasola Gorham-2
>From [hidden email] Wed Feb  3 08:25:46 1999
>
>Well I think the big question here is if there is any bodywho is
>interessed in a debugger for Lua - and in what shape?
>
>Quick Poll: (please answer everybody!)
>
>1. Are you using ldb (And how)?:
>2. Are you interessed in a debugger for Lua ?:
>3. What functionality whould you want from a Lua Debugger ?:

I think this is a very useful poll.

I for one think that a debugger is good, but several debuggers are better :-)
That's why we have the debugging interface ldebug.h -- users can write their
onw debuggers.

So, one related question is:

4. Do you think the debugging interface ldebug.h is useful as it is?

Another point is that Lua 3.2 will debugging functions exported to Lua,
in a new library ldblib.c.
So, it will be possible to write debuggers in Lua, not in C.

Finally, Antonio Scuri ([hidden email]) has written a simple
visual debugger that he'll be willing to share. I think it's almost done.

--lhf

Reply | Threaded
Open this post in threaded view
|

Re: About Ldb

Erik Hougaard
Luiz Henrique de Figueiredo wrote:
> 4. Do you think the debugging interface ldebug.h is useful as it is?

The lua_linehook and lua_callhook should be in the state and there
should be a lua_currentfile (Or the current line & file should be in the
state also!)

But I like the way that I can do my own debugger!!

Erik

Reply | Threaded
Open this post in threaded view
|

Re: About Ldb

Supratik Champati
In reply to this post by Erik Hougaard
> Quick Poll: (please answer everybody!)

> 1. Are you using ldb (And how)?:

I am not using it primarily because of the license restrictions

> 2. Are you interessed in a debugger for Lua ?:
Very much so

> 3. What functionality whould you want from a Lua Debugger ?:

I would like to echo ashleys thought here. Something in the
lines of VC++.

Come on I am sure there are more people out there that would like
to use the ldb. Please respond people.
    
supratik

Reply | Threaded
Open this post in threaded view
|

Re: About Ldb

Antonio Scuri
In reply to this post by Tomas Guisasola Gorham-2
>Finally, Antonio Scuri ([hidden email]) has written a simple
>visual debugger that he'll be willing to share. I think it's almost done.
>--lhf

 Yes. It is almost done. But I will release it only when Lua 3.2 is at
least in beta, because of some problems we already discussed off-line.

 Because It is a "visual" debugger, probably is not much related with
Erick's recent work. In fact, I can not use any of the ldb functionality.

 When the debugger became available, there will be a few constrains...

 I used the IUP interface library that I can not distribute and It is not
public available. Therefore the debugger code will be available. But you
will not be able to compile it. I think It wont be too hard to port to
another interface toolkit.

 But the binaries for many platforms (Win32, Linux, IRIX, Solaris, Mac)
will also be available for download. And I do provide a mechanism for
dynamic loading a shared/dynamic library using a configuration file in Lua
(this code will be also public).

 Soon I will post a message to the list informing the availability of the
debugger and where you can download it.

Best Regards,
Antonio Scuri.