Re: Guile debugger workgroup?

[Ludovic Courtès]

Hi,

Attila Lendvai <attila@lendvai.name> skribis:

> the first thing that pops to my mind is the service start gexp's in shepherd: 
> they felt impossible to debug. i often was pretty much resorting to staring 
> at the code, and then trying ad-hoc changes (with a minute+ long 
> edit-compile-test cycle).

Ah yes.  That’s a problem that has to do with staging, which makes
things more difficult.

The one multi-stage language I know of that did it well, but in a
totally different context, is Hop <https://hop.inria.fr>.
<https://hal.inria.fr/hal-01580582/document> briefly discusses
cross-stage debugging.

> there are multiple issues here. the first one is that there's no proper error 
> handling in shepherd. but if there was at least a semi-global error handler, 
> that logged a full backtrace into a log file, then it would have been 
> immensely helpful.

OK.  I guess there are cases where you do get logging with Shepherd 0.9,
and other cases less so (e.g., if the ‘start’ method refers to an
unbound variable).  We should look at typical examples to get a better
understanding of what’s missing.

> for inspiration, this is what we developed in common lisp:
>
> https://hub.darcs.net/hu.dwim/hu.dwim.util/browse/source/error-handling.lisp#10
>
> WITH-LAYERED-ERROR-HANDLERS is a macro for which you can provide a "level 1" 
> error handler hook that does whatever it wants. if any errors happen within 
> this hook, then a level2 error handler kicks in, turns off several things 
> (e.g. custom PRINT-OBJECT methods), and tries to log a backtrace in a 
> defensive way (e.g. there are error handlers installed while printing each 
> backtrace level).
>
> if even level2 errors out, then a super conservative level3 error handler 
> logs this fact, so that there's *some* sign of an error.

Looks like a good source of inspiration!

Thanks,
Ludo’.