Re: PLEASE: debugging embedded guile code

[Neil Jerram]

>>>>> "Bruce" == Bruce Korb <address@hidden> writes:

    Bruce> Neil Jerram wrote:
    >> 
    >> Does this help?

    Bruce> Yes.  A lot.  I think I know why I didn't think of it
    Bruce> before, though.  :-)

:-)

    Bruce> except instead of "<string port>" I'd supply the name of the
    Bruce> file I was reading to get the Scheme code.

Good idea.  You might check out `emacs-load' in (ice-9 emacs) which
uses the same trick to set port name and position for code sent to it
from Emacs.

    Bruce> Right near [1] I would want to add the starting line number
    Bruce> to the evaluator's notion of what the current line number
    Bruce> is.  If I'm on line 100 of my clients input text, it would
    Bruce> be nice for the display-error code to display a line number
    Bruce> 99 higher than otherwise.  I'd do this by using some of my
    Bruce> own functions:

    >> (define (eval-client-input str)
    >>   (stack-catch #t
    >>     (lambda ()
    >>       (call-with-input-string str
    >>         (lambda (p)
    >>           (set-port-filename! p (tpl-file))
    >>           (SET-PORT-FILELINE! p (string->number (tpl-file-line "%2$d")))
    >>           (list (primitive-eval (read p))))))
    >>     (lambda (key . args)
    >>       ;; [1]
    >>       (apply display-error (fluid-ref the-last-stack)
    >>                            (current-error-port)
    >>                            args)
    >>       (set! stack-saved? #f)
    >>       #f)))

Exactly (except that set-port-fileline! is actually set-port-line!).

    >> Note - the code above assumes that `args' has the right
    >> structure (see doc for display-error), which is true for all
    >> the exceptions generated by Guile itself.  If you want to
    >> handle exceptions generated by your own or your client's code,
    >> you need to add code at [1] to identify non-core exceptions and
    >> turn their throw args into suitable parameters for
    >> display-error.

    Bruce> I think I'd want to test for a client error list massaging
    Bruce> procedure and invoke that if present.

Yes, I've been thinking about a mechanism for this, probably
GOOPS-based.  My thinking now (much advanced by this thread) is that
there are 3 points of weakness in the error handling system:

1. No documentation :-)

2. No mechanism for relating the throw or error args at the point
   where an exception is raised to how they should be interpreted or
   displayed by the catch handler.

3. The fragile interdependencies of stack-catch,
   lazy-handler-dispatch, the-last-stack and stack-saved?

We can live with 3 for a while longer, but I think it won't be too
hard to specify a nice mechanism for 2; so I'd like to do that and
then document the whole thing.

    Bruce> The only places I throw errors, I call scm_wrong_type_arg
    Bruce> directly.  I would guess it would have args set up okay. :)

Yes, I believe so.  Anything that goes through scm_error will be OK.

        Neil