Re: wrong type of agument... where ?

[Danny Milosavljevic]

Hi Chris,

On Sat, 06 Jan 2018 17:46:46 -0800
Chris Marusich <address@hidden> wrote:

> Danny Milosavljevic <address@hidden> 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 :)