Re: saving and restoring the error stack trace

[Neil Jerram]

"Marco Maggi" <address@hidden> writes:

> Making the stack with this:
>
>   s_error_stack = scm_make_stack(SCM_BOOL_T, SCM_EOL);
>
> and using the function (scm_t = SCM): [...]
>
> I have error messages like:
>
> Backtrace:
> In unknown file:
>    ?: 0* [dotest "gsl-ode-error-2.4" #<procedure #f ()> ...]
>    ?: 1  (let* () (let* (# #) (let* # #)))
>    ...
>    ?: 2  (begin (display name) (if (thunk? setup) (setup)) ...)
>    ?: 3* (let (# # # ...) (set-current-input-port saved-in) ...)
>    ?: 4* (if catch-error (catch #t thunk (lambda (key .
> args) key)) (thunk))
>    ?: 5  [#<procedure #f ()>]
>    ...
>    ?: 6  (let* ((result (quote ()))) (if debugging
> (newline)) ...)
>    ?: 7* [gsl-ode-evolve #<universal GSL SMOB 404697f8>
> #:initial-indep-value ...]
>    ?: 8  (let-keywords args #f ...)
>    ...
>    ?: 9  [gsl-p-ode-evolve #<universal GSL SMOB 404697f8>
> 0.0 ...]
>
> <unnamed port>: In procedure gsl-ode-evolve in expression
> (gsl-p-ode-evolve ode initial-indep-value ...):
> <unnamed port>: my error message 1 and 2
> In unknown file:
>    ?: 10* [#<procedure #f (t y)> 0.0 #,(gsl-vector-real 1 2.0)]
>    ?: 11* [gsl-ode-invoke-fun 0.0 #,(gsl-vector-real 1 2.0) ...]
>    ?: 12  (let* ((o (func t #))) (if (gsl? o) (slot-ref o
> (quote v)) ...))
>    ?: 13* [#<procedure #f (t y)> 0.0 #,(gvr 1  2.0)]
>    ?: 14  [throwing-error]
>     ...
>    ?: 15  [scm-error my-own-error "sub-throwing-error" ...]
>
> which is not perfect but seems good enough for me.

OK.  Out of interest, though, what changes would you like to the
presentation?  (And, to ask a leading question, do you think that the
way my Emacs interface displays the stack is better or worse than
this?  http://www.ossau.uklinux.net/guile/debugging-demo/shot2.html)

> I am a little annoyed that I have to use a port to
> build the backtrace string,

That just needs getting used to; I'd say that ports are a fantastic
abstraction.  And the C API for a string port is very easy to use,
isn't it?

> and that the args content
> is not explicitly documented (that is, I was not
> able to find it) even if its content is well defined
> in 'scm_error_scm()':
>
>   scm_ithrow (key,
>         scm_list_4 (subr, message, args, data), 1);

Yes, here I completely agree with you.  I've been wondering what to do
about this for ages.  Do you think it can be solved adequately by
precise documentation, or do we need some way of describing the
expected throw args in code; perhaps even construct some kind of
object model around the args with methods for getting the useful bits
of information out?  (Use of which would be optional.)

Regards,
     Neil