Re: [Announce] Second Alpha release of a Lua debugger

[Rici Lake <lua@...>]

Stephen Kellett wrote:
> Rici Lake wrote:
> > I'd love to make this simpler to use, but it's not immediately
> > clear to me how to do so.
>
> Suggestion: Add a command that will list the currently known lua file 
> names.
>
>     list allfiles
>
>     2 files:
>     c:\weebles\weeblesWobble.lua
>     c:\weebles\butTheyDontFallDown.lua
>
> I'm assuming you already know the names of these files.

From where would I know them? This is one of the annoyances of the
Lua debug interface: you can interrogate a known function for its
'source' attribute (if it was defined in a file, that will be the
filename preceded by an @) but there's no interface for getting at
all the filenames in the system.

The only filename I know about a priori, if the debugger was
started with the ldb command line script, is the main file.
That didn't seem very useful, since the user also knows that filename,
and in any event it will be the default filename for breakpoints set
right away (see below)

> If you don't,
> you can track them with a hook, or simpler, but less accurate, you could 
> get a backtrace and get some filenames from that.

Yes, but that would only get me filename already encountered. Also, it
seems like it would add even more overhead to hook handling. If it
was really useful, it would be worth it, but I'm not convinced that it
is.

Suppose you asked for a breakpoint in a file which has not yet been
executed, so the filename is not in the repository. The best I could
do is suggest that the filename was not correct, but it may well be
correct. Do you thing this warning would be helpful?

The solution I chose was to use the filename from the current context
as the default for the breakpoint command, which seems to work out
ok. I'm going to add a way of setting a breakpoint by providing the
function instead of the filename, which might also be helpful.

> Do you have a command that will list a fragment of a file (so you can 
> display say lines 3 to 46 of weeblesWobble.lua)?

No, although it would be easy to add as an add-on module. However, I
find it more comfortable to use the vim integration feature of ldb.
While I'm debugging, there is a gvim window beside the debug session;
the gvim window tracks the debugging session (through the integration
glue) so it always shows the source for the current debugging context
(as long as the source is a file -- I haven't yet done what would be
necessary to dump a source string into vim, but I think that might
be useful, too.)

This should work with other editors/IDEs as well; it's just a question
of figuring out how to send the editor a command to position the
file window at a particular file at a particular line. There is
a bunch of stuff about how to do this in the sample ldb-config
file in the distribution, but it may be that it is still
underdocumented.