lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

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 regarding this?


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