Re: wrong type of agument... where ?

[Danny Milosavljevic <dannym@scratchpost.org>]

Hi Chris,

On Sat, 06 Jan 2018 17:46:46 -0800
Chris Marusich <cmmarusich@gmail.com> wrote:

> Danny Milosavljevic <dannym@scratchpost.org> writes:
> 
> > Try this:
> >
> > diff --git a/gnu/build/linux-boot.scm b/gnu/build/linux-boot.scm
> > index 4dd740174..810a0d63f 100644
> > --- a/gnu/build/linux-boot.scm
> > +++ b/gnu/build/linux-boot.scm
> > @@ -507,7 +507,14 @@ to it are lost."
> >               (switch-root "/root")
> >               (format #t "loading '~a'...\n" to-load)
> >  
> > -             (primitive-load to-load)
> > +             (catch #t
> > +               (lambda ()
> > +                 (primitive-load to-load))
> > +               (lambda (key . args)
> > +                 (format (current-error-port) "Error: ~a: ~a\n" key args)
> > +                 (reboot))
> > +               (lambda (key . args)
> > +                 (display-backtrace (make-stack #t) (current-error-port))))
> >  
> >               (format (current-error-port)
> >                       "boot program '~a' terminated, rebooting~%"
> >  
> 
> In some other languages (e.g., Java, Python), we get stack traces by
> default when an unhandled exception is thrown.  Is this not the case in
> Guile?

It is the case in Guile, too.  But Guile does even more - it automatically drops you into a debugger prompt.  Then the tester VM hangs waiting for keyboard input (typing a debugger command) - which we

(1) don't want to provide (we want it to fail the unit test automatically and not only after writing "please fail the unit test already" there) and
(2) can't provide through the Makefile (right now).

Also, we already catch some other exceptions in (guix ui) - and I wanted to pre-empt that. 

Also, for some reason, directly modifying (guix ui) (see "call-with-error-handling") to handle our new error doesn't work.

I tried extending (guix ui) to print a message and that message doesn't appear at runtime either for (gnu build linux-boot) - but visual source code inspection says that (gnu build linux-boot) DOES use (guix ui)'s call-with-error-handling.  No idea what's up with that.  Maybe some not-rebuilding problem.

Every testing round (in this thread, Catonano describes how to test it) takes hours on my computer so if I find a better way it will be by doing a little, from time to time, over weeks.  But a quick workaround is the above.

Furthermore, the automatic stack trace printer (which is the same as display-backtrace) does some ellipsizing (to keep the total line length under 78 characters or something) and omits valuable information in the stack trace (cuts strings etc).  I don't know what's the idea with omitting half the stuff in information meant only for *programmers* in the first place.

Therefore, I put a better stack trace printer into bug# 29922 - which is otherwise similar in approach to what I did in this thread here.

Also, I think that there's a further bug in Guix in that marionette-operating-system (which is only used for testing) doesn't even exit on guest kernel panic (it just hangs there forever).  I've also includes a fix for that in the same patch.

I think it's necessary to improve error handling - errors in error handling drive me up a wall.  If some contributor already has to battle his own error, we shouldn't prevent him from finding it by our errors :)