Re: Debugger support (Re: Slashdot article)

[Asko Kauppi <asko.kauppi@...>]

Nice to see you interested in this. Now, I only hope it'll be fire too, 
and not just smoke.. ;)

In order to do that, how about listing the people who'd really like to 
"carry their straws" to this, and keep their discussion separate?  I 
mean something like luaCheia, but usable with any Lua distro. Should we 
start a separate list (& project) for this?

Here's my goals for the (remote) debugger:
	- lightwight (not slowing things down _too_ much)..
	- easily enablable(?)/disablable (gosh, what words!!) - I like your 
'require' approach :)
	- server & protocol standard, clients multiple implementations 
(cmdline, UI, VC++ extension..)
	- clients implemented (preferably) in Lua
	- crafted in the spirit of Lua (goes without saying, right..?)=
	- ..

What's the Lua authors' standpoint (Roberto et.al) regarding this?

-ak


17.6.2004 kello 22:20, Andre Carregal kirjoitti:

>  Good points indeed!
>
> In a perfect world, one could just require "remdebug" in the remote
> application and use the debugger locally through an IDE or command 
> line.
>
> The RemDebug server could implement the reflexive Debug interface 
> through a
> TCP connection and could be used with a host like Xavante to debug 
> CGILua
> scripts for example. It would also have to offer some API to 
> communicate
> with the remote application and be notified of program 
> starts/stops/etc.
>
> Andre Carregal
>
>
>
>
>
> -----Original Message-----
> From: lua-bounces@bazar2.conectiva.com.br
> [mailto:lua-bounces@bazar2.conectiva.com.br]On Behalf Of Tom Spilman
> Sent: Wednesday, June 16, 2004 5:40 PM
> To: 'Lua list'
> Subject: RE: Debugger support (Re: Slashdot article)
>
>
>
> > Another option would be using LuaXMLRPC/SOAP and Xavante. In
> > fact this is our initial plan for the Kepler remote debugger.
>
>  My initial impression is that it is more complex than needed, but I 
> need to
> look closer at it.  Also it seems to me that the debugger server and 
> client
> would be best implemented in C for performance and to keep the 
> debugger from
> stepping into itself.
>
>   Tom