[Ecls-list] Line Number of errors ?

[Geo Carncross]

On Thu, Apr 24, 2008 at 10:26 AM, Juan Jose Garcia-Ripoll
<jjgarcia at users.sourceforge.net> wrote:
> On Thu, Apr 24, 2008 at 2:13 PM, Geo Carncross <geocar at gmail.com> wrote:
>  >  What about something with the SI:REGISTER-THING semantics
>  >  I described? Would patches be accepted that populated this database?
>  >  Or do you have a better way to go about this?
>
>  I saw the function, but I did not understand what is expected to do.
>  Should it be invoked by ECL? Is this a function for the user? Or just
>  for Slime?

It's something that ECL could use internally to track the location of
these things.
As you've pointed out, it's not something ECL presently does.

SLIME has two functions, one given a value finds out the source code
location of it,
and the other is given a symbol and finds its definition. I wouldn't
mind hooking these up
if you wanted to make the structure changes in ECL.

>  There is a different problem with ECL is that there are four stacks:
>  the stack that lists the function invocations, the stack that lists
>  points to which we can jump (i.e. BLOCKs, UNWIND-PROTECTs, etc), the
>  global binding variable stack and the interpreter stack. Writing code
>  to translate all this into Slime's desired format is not a trivial
>  task, but it is doable -- I am just missing a good specification of
>  what Slime wants. If any Slime expert sends me a set of functions and
>  a detailed specification what they should output, them I cand spend a
>  weekend coding it.

Slime assumes there's a single indexable list of "frames" and doesn't seem
to overspecify what a frame is. The indexes are just integers. Some function
would be called given one of those indexes, and the swank-backend would
lookup the given things accessible to that frame- for example:
frame-catch-tags returns
a list of all the catch tags at a index.

There are also functions like return-from-frame, eval-in-frame,
restart-frame which
return the result of a form directly from a frame, require evaluating
in a frame (SI::EVAL-WITH-ENV),
and restarts a call at a given frame.

Finally, swank-backend:compute-backtrace produces a list of THINGS
that print-frame will print,
swank-backend:frame-var-value looks up the value of some variable in
one of those THINGS.

Setting this up wouldn't be all that difficult if there were an easy
way to compare two stack entries
from different stacks, so we could tell whether an BDS entry were
"deeper" than a IHS. That looks like
the job of the FRS, but I haven't looked too closely at this yet.

On Thu, Apr 24, 2008 at 1:22 PM, Tobias C. Rittweiler <tcr at freebits.de> wrote:
>  P.S.: I looked at FIND-SOURCE-LOCATION in swank-ecl.lisp; There's a
>  *tmp* global variable straying around, most likely used for debugging
>  purpose to get something to the REPL.

Sorry, that's me. I use that when debugging and accidentally checked it in.

>  I think you have to do this this way, because ECL's swank-backend does
>  not implement the functions to evaluate an expression in the context of
>  a backtrace frame, or at least to get at the value of a stack variable.

SWANK's ECL backend doesn't implement a lot of things. It does many of the basic
things I do, but it's not even remotely complete. I don't mind hooking
things up, but
it's a bit hard for me to enumerate all the things it doesn't do yet :)