[Ecls-list] Questions about swank-ecl.lisp

[Juan Jose Garcia-Ripoll]

Hi Deepankar,

only a brief and temporary answer. We can discuss this further, but
today I think I will stop hacking and go back to other work.

On Thu, May 22, 2008 at 3:45 AM, Deepankar Sharma
<deepankar.sharma at gmail.com> wrote:
> 1) In "(defimplementation arglist (name) ... " in swank-ecl.lisp there is
> code that gets the arglist for a symbol. Currently it does not work for
> macros or for user defined functions.

Interpreted functions keep a list of arguments. There is no provision
for compiled functions to store their lambda lists anywhere, at least
yet. As for how to use it for interpreted functions

> (defun foo (x) (1+ x))
FOO
> (function-lambda-expression #'foo)
(SI:LAMBDA-BLOCK FOO (X) (1+ X))
NIL
FOO
> (defmacro faa (x) `(cos ,x))
FAA
> (fdefinition 'faa)
(SI:MACRO . #<bytecompiled-function FAA>)
> (function-lambda-expression (cdr (fdefinition 'faa)))
(SI:LAMBDA-BLOCK FAA
                 (#:G145 #:G144 &AUX
                  (X
                   (IF (CDR #:G145) (CADR #:G145) (SI::DM-TOO-FEW-ARGUMENTS))))
                 (DECLARE (IGNORE #:G144))
                 (SI::CHECK-ARG-LENGTH #:G145 2)
                 (SI:QUASIQUOTE (COS (SI:UNQUOTE X))))

Notice that macros rename their arguments when expanded, hence a lot
of information is lost. What I suggested in another message is to
change the definitions of DEFUN, DEFMACRO, etc, so that they use a
macro that register debug information. That macro would by default
expand to noting, but could be overwritten by slime to record any kind
of information.

> I had a look at sbcl's equivalent code which uses
> the sbcl introspection module , and I think it would be good to have such a
> module so that the code can be pushed there instead of living in the slime
> specific code.  Also, suggestions on how to implement storing / retrieving
> arglists for macros and user defined functions would be welcome.

I do not know what can and what cannot  be used from that module.
Seems like something very specific that would deal with stacks,
frames, function definitions, etc, so therefore not very portable.

> 2) Regarding the backtraces - i propose adding a variable called
> *backtrace-filter* to be used from is-ignorable-fun-p which will store a
> list of lambda's that users can add to. to filter away things they are not
> interested in. Please comment if this should go in.

I have no problems with that.

> 3) The backtraces currently contain a lot of frames that are ecl specific.
> These include apply's, and entries for bytecompiled functions called from
> the apply's and few evals with no local variables.  A standard way of
> identifying if a frame has been inserted by ecl would be helpful here.
> Please give me some pointers about this.

Let's say that they are not ECL specific. It is like when you have an
ordinary program, with lots of functions that call other functions.
ECL itself uses many functions and some of them appear in the stack
frame and some others do not.

The real problem is that we cannot set up a standard for this because
there are many ways to evaluate code and they will lead to different
stack configurations. If you use ECL's toplevel #'si::tpl there will
be a different frame than if you use one of Slime's many functions to
evaluate forms.

To solve this "problem" for Slime, you have to identify which frames
swank (not ECL) creates and then filter them out. A further
complication is that the frames are going to differ depending on
whether the code is compiled or not, and whether some function calls
are inlined or not.

One possibility is to force swank to call always the same function
when evaluating something. That way you can detect the beginning of
the backtrace. Furhtermore, this function can be forced to be compiled
or interpreted, thus fixing its behavior. Then you have too look at a
typical backtrace and see how many frames it consistently creates.

Note that you might be tempted to eliminate some frames, such as EVAL.
I am not sure this is 100% correct, because the IHS frame for EVAL
contains the bytecodes of the evaluated form and thus its original
lisp form.

I have changed the name of those frames, though, making them more
recognizable and probably more useful for filtering. But see more or
less what I mean:

> (cos 'a)
In function COS, the value of argument is
        A
which is not of expected type NUMBER
Broken at SI:BYTECODES.Available restarts:
1. (USE-VALUE) Supply a new value of type NUMBER.
Broken at SI:BYTECODES.
>> :b
Backtrace: SI:BYTECODES > si:bytecodes
>> :f
Broken at SI:BYTECODES.
>> :d

   0	PUSH	'A
   2	CALLG	1,COS
   5	EXIT
>> :lambda-expression

(COS 'A)
>> :p
Broken at SI:BYTECODES.
>> :f
Broken at SI:BYTECODES.
>> :d

   0	CALLG	0,TOP-LEVEL
   3	EXIT
>> :lambda-expression

(SI:TOP-LEVEL)

Notice however, that in the backtrace we also accidentally captured
the initial call to top-level. That is unfortunate and should be
fixed.

Juanjo

-- 
Facultad de Fisicas, Universidad Complutense,
Ciudad Universitaria s/n Madrid 28040 (Spain)
http://juanjose.garciaripoll.googlepages.com