[Ecls-list] examples or documentation on debugging...

[Tobias C. Rittweiler]

Juan Jose Garcia-Ripoll wrote:

> I was also made aware that using form number is not really useful when
> the code changes the readtable or use #+ or #-. Indeed, this is the
> case in a couple of libraries and should be a major problem debugging
> them.

Examples? People may have to adapt SWANK:*READTABLE-ALIST*, or
alternatively use named-readtables at

 http://common-lisp.net/~trittweiler/darcs/editor-hints/named-readtables/


> Things are as follows. First, Slime will have to be upgraded to
> understand the environment produced by C functions (basically it
> involves calling si::decode-ihs-env)

Are the new changes on the debugger and inspector documented? What can
be used to discriminate the current version from what was there before?

 
> Second, ECL is being changed to record not the form number, but the
> precise file position at which the form was read. Please understand
> that this is a complicated change -- we might not get it right the
> first time -- since it involves detecting forms that are ignorable
> (#+/- conditionals, comments, etc).

In my experience, form numbers work better than file positions because
there's somewhat less chance that they turn wrong on interactive
modification of the files.

Notice, now that you're working on it, that Slime can first go to a
tentative position (computed from form number, or given by file/line
position), and then search for a given snippet in a short region around
that position. The snippet comes from the Lisp implementation, e.g. the
first, say, 128 characters of a toplevel form.

Notice further, that Slime can cope with form paths. A form path is the
path into the tree that the source of a toplevel form represents. This
way, you can get various highlighting of the actual offending subforms
rather than the whole toplevel form.

  -T.