Getting scheme error informations when running scheme code from C

Getting scheme error informations when running scheme code from C

[Christian Mauduit]

Hello,

I'm currently coding a game using scheme as a scripting language. The
main program is a C program which first exports C functions to scheme
and then calls a scheme script. This scheme script is responsible for
all game logic, interaction, control, whatever, and the C functions are
low-level stuff (such as OpenGL graphics, simple core algorithms which
needs to run as fast as possible, and so on).

Of course I'm using Guile for this 8-)

I'm pretty happy with it for now, I'm just discovering Scheme
(previously experienced with Perl, Python and Lua) and it's performing
pretty well. Most of all it does what I need.

But... (there's always a "but...") I find it hard to debug. I assume I'm
not using it the correct way, or that I missed something. Here's my
problem: when there's an error in scheme code, Guile terminates my
program immediately and gives me an error message which is often not
precise enough for proper debugging. Here's an example, with code
excerpts (full code on http://ufoot.hd.free.fr/snapshot/pub/ , project
liquidwar6).

When I run scheme code from C code, placing on purpose an error in the
scheme code (I add a "(car ())" line in some random place) and call it with:
---------8<------------------------------------------------
scm_c_primitive_load (script);
---------8<------------------------------------------------
with script a char * pointing to "src/script/liquidwar6.scm"

I get the following output:
---------8<------------------------------------------------
liquidwar6: registering C functions for Guile
liquidwar6: loading "src/script/liquidwar6.scm"
ERROR: missing or extra expression
---------8<------------------------------------------------
The lines with liquidwar6: are output from my C program, using C log
functions. The line with "ERROR" is an output from Guile, which
terminates the program. As a side note the fact that it terminates the
program is a bit annoying, since I would like to "trap" this message.
Indeed a windows user will never read console output, and if I want
proper bug reports from players, I'd better display this message in a popup.

Then this message is a little "light" for proper debugging. When I'll
have 10000 lines of scheme code, it will be impossible to track bugs
without informations like line number for instance.

Point is if I call "load" are "primitive-load" from the Guile
interpreter I get much more information:

---------8<------------------------------------------------
guile> (load "src/script/liquidwar6.scm")
src/script/loop.scm:20:1: While evaluating arguments to car in
expression (car ()):
src/script/loop.scm:20:1: missing or extra expression
ABORT: (misc-error)

Type "(backtrace)" to get more information or "(debug)" to enter the
debugger.
guile>
---------8<------------------------------------------------

---------8<------------------------------------------------
guile> (primitive-load "src/script/liquidwar6.scm")
src/script/loop.scm:20:1: While evaluating arguments to car in
expression (car ()):
src/script/loop.scm:20:1: missing or extra expression
ABORT: (misc-error)
guile>
---------8<------------------------------------------------

This would be very fine: filename, line number, code excerpt, these are
the very informations I need.

Anyone would have an idea on how to:
1) trap, redirecet or place a hook on the Guile "error handler" (if such
a handler exists?) and get these errors in C, and then decide what to do
with it.
2) actually get precise error informations (file, line, source, error
description) the way the interactive Guile interpreter does.

I read the Guile manual, but:
http://www.gnu.org/software/guile/docs/guile-ref/Debugging-Features.html
and:
http://www.gnu.org/software/guile/docs/guile-ref/Hooks.html
did not solve my problem. At least I couldn't find a solution reading them.

Any clue?

Thanks in advance,

Christian.

-- 
Christian Mauduit <ufoot@ufoot.org>     __/\__ ___
                                        \~/ ~/(`_ \   ___
http://www.ufoot.org/                   /_o _\   \ \_/ _ \_
http://www.ufoot.org/gnupg.pub            \/      \___/ \__)


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: Getting scheme error informations when running scheme code from C

[Alan Grover]

My comments are for Guile version 1.6.4.

To get a backtrace, you want something that does the same thing as the
--debug option. However:
"Using the debugging evaluator will give you better error messages but
it will slow down execution."
So, you don't want it in production-code.

I believe this will turn on the debug-evaluator at run-time (so the
documentation implies):
	(debug-enable 'debug)
Hope that causes a stack-trace for you. See "Configuration, Features and
Runtime Options" in the documentation, subsection "Debugger Options".


Have you considered using "catch" to catch errors (or "lazy-catch")? You
could wrap your scheme code in a "catch", or use scm_catch. Section "How
to Handle Errors in C Code" has some hints. Lazy-catch lets you capture
the stack.

I don't see a mechanism for adding a "catch" for primitive-load. The
empty documentation for "REPL Hooks" is suggestive. So, use scm_catch,
or "eval" something like:
	(catch #t
		(lambda () (primitive-load ...))
		(lambda (key . args) (deal with error here)))
(of course, you could add a function that does this to the top-level and
just call it.)

You may also find the section "Debugging Infrastructure" interesting. It
talks about decoding the stack, and limiting the backtrace.


Lazy-catch will let you examine the stack as it exists at the time of
the throw/exception. You could dump the stack with "display-backtrace"
or programatically try to find the relevant stack-frame (an interesting
problem since tail calls may-not generate a frame). See section
"Examining the Stack".

Christian Mauduit wrote:
> ...
> Here's my
> problem: when there's an error in scheme code, Guile terminates my
> program immediately and gives me an error message which is often not
> precise enough for proper debugging. Here's an example, with code
> excerpts (full code on http://ufoot.hd.free.fr/snapshot/pub/ , project
> liquidwar6).
> 
> When I run scheme code from C code, placing on purpose an error in the
> scheme code (I add a "(car ())" line in some random place) and call it with:
> ---------8<------------------------------------------------
> scm_c_primitive_load (script);
> ---------8<------------------------------------------------
> with script a char * pointing to "src/script/liquidwar6.scm"
> 
> I get the following output:
> ---------8<------------------------------------------------
> liquidwar6: registering C functions for Guile
> liquidwar6: loading "src/script/liquidwar6.scm"
> ERROR: missing or extra expression
> ---------8<------------------------------------------------
> The lines with liquidwar6: are output from my C program, using C log
> functions. The line with "ERROR" is an output from Guile, which
> terminates the program. As a side note the fact that it terminates the
> program is a bit annoying, since I would like to "trap" this message.
> Indeed a windows user will never read console output, and if I want
> proper bug reports from players, I'd better display this message in a popup.
> 
> Then this message is a little "light" for proper debugging. When I'll
> have 10000 lines of scheme code, it will be impossible to track bugs
> without informations like line number for instance.
> 
> Point is if I call "load" are "primitive-load" from the Guile
> interpreter I get much more information:
> 
> ---------8<------------------------------------------------
> guile> (load "src/script/liquidwar6.scm")
> src/script/loop.scm:20:1: While evaluating arguments to car in
> expression (car ()):
> src/script/loop.scm:20:1: missing or extra expression
> ABORT: (misc-error)
> 
> Type "(backtrace)" to get more information or "(debug)" to enter the
> debugger.
> guile>
> ---------8<------------------------------------------------
> 
> ---------8<------------------------------------------------
> guile> (primitive-load "src/script/liquidwar6.scm")
> src/script/loop.scm:20:1: While evaluating arguments to car in
> expression (car ()):
> src/script/loop.scm:20:1: missing or extra expression
> ABORT: (misc-error)
> guile>
> ---------8<------------------------------------------------
> 
> This would be very fine: filename, line number, code excerpt, these are
> the very informations I need.
> 
> Anyone would have an idea on how to:
> 1) trap, redirecet or place a hook on the Guile "error handler" (if such
> a handler exists?) and get these errors in C, and then decide what to do
> with it.
> 2) actually get precise error informations (file, line, source, error
> description) the way the interactive Guile interpreter does.
> 
> I read the Guile manual, but:
> http://www.gnu.org/software/guile/docs/guile-ref/Debugging-Features.html
> and:
> http://www.gnu.org/software/guile/docs/guile-ref/Hooks.html
> did not solve my problem. At least I couldn't find a solution reading them.
> 
> Any clue?
> 
> Thanks in advance,
> 
> Christian.
> 


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: Getting scheme error informations when running scheme code from C

[Christian Mauduit]

Alan Grover a écrit :
> My comments are for Guile version 1.6.4.
> 
> To get a backtrace, you want something that does the same thing as the
> --debug option. However:
> "Using the debugging evaluator will give you better error messages but
> it will slow down execution."
> So, you don't want it in production-code.
> 
> I believe this will turn on the debug-evaluator at run-time (so the
> documentation implies):
> 	(debug-enable 'debug)
> Hope that causes a stack-trace for you. See "Configuration, Features and
> Runtime Options" in the documentation, subsection "Debugger Options".
mmm, OK I see, indeed using:

(debug-enable 'debug)
(debug-enable 'backtrace)

gave me much more detailed output, thanks for the tip.

> Have you considered using "catch" to catch errors (or "lazy-catch")? You
> could wrap your scheme code in a "catch", or use scm_catch. Section "How
> to Handle Errors in C Code" has some hints. Lazy-catch lets you capture
> the stack.
> 
> I don't see a mechanism for adding a "catch" for primitive-load. The
> empty documentation for "REPL Hooks" is suggestive. So, use scm_catch,
> or "eval" something like:
> 	(catch #t
> 		(lambda () (primitive-load ...))
> 		(lambda (key . args) (deal with error here)))
> (of course, you could add a function that does this to the top-level and
> just call it.)
> 
> You may also find the section "Debugging Infrastructure" interesting. It
> talks about decoding the stack, and limiting the backtrace.
> 
> 
> Lazy-catch will let you examine the stack as it exists at the time of
> the throw/exception. You could dump the stack with "display-backtrace"
> or programatically try to find the relevant stack-frame (an interesting
> problem since tail calls may-not generate a frame). See section
> "Examining the Stack".
Well, using lazy-catch and a handler with the line:

(display-backtrace (make-stack #t) some-user-string-output-port)

actually got me very close from solving my problem completely. The only
point is that the stack I obtain contains many useless things (such as
the actual functions I'm using within the error handler, which are
useless...) so I get a garbaged output. I guess there's some way to get
rid of this by passing cryptic arguments to make-stack. BTW trying to
handle the object returned by make-stack and produce a string output "by
hand" from it sounded awfully hairy to me. Wee.

If I get an elegant solution to my problem, I'll try to package it and
make a short text on the question, by searching the web I found out that
I'm not the only one to wish to handle his errors himself, but the
tutorial does not seem to be written yet 8-)

Have a nice day and thanks for your help,

Christian.

-- 
Christian Mauduit <ufoot@ufoot.org>     __/\__ ___
                                        \~/ ~/(`_ \   ___
http://www.ufoot.org/                   /_o _\   \ \_/ _ \_
http://www.ufoot.org/gnupg.pub            \/      \___/ \__)


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: Getting scheme error informations when running scheme code from C

[Alan Grover]

Christian Mauduit wrote:
> ...
> Well, using lazy-catch and a handler with the line:
> 
> (display-backtrace (make-stack #t) some-user-string-output-port)
> 
> actually got me very close from solving my problem completely. The only
> point is that the stack I obtain contains many useless things (such as
> the actual functions I'm using within the error handler, which are
> useless...) so I get a garbaged output. I guess there's some way to get
> rid of this by passing cryptic arguments to make-stack. BTW trying to
> handle the object returned by make-stack and produce a string output "by
> hand" from it sounded awfully hairy to me. Wee.

If we assume that the catch'ing lambda is always the same, then the
stack-frames related to it should be stable. So, you should be able to
discard the bottom n frames every time:

For example:
(lazy-catch #t
        (lambda () (+ 1 (hubert)))
        (lambda (key . args)
        (let ((s (make-stack #t)))
        (display (list key args))
        (newline)
        (display-backtrace s (current-output-port)
                (- (stack-length s) 1)
                (- (stack-length s) 3)))
        (newline)
        (display "throw on") (newline)
        (throw 'bob)))
Always truncates the stack at the "(hubert)" call (i.e. trims off the
lazy-catch). Note the need to subtract 1 from stack-length for the
"first" argument of display-backtrace. The documentation is not clear:
the "first" argument is "how far back" to start (i.e. 1  would mean "1
before bottom"), "depth" is number of frames to display. Since I know I
want to discard the last 3 (by examination), I subtracted 3 from the
stack-length. Capture the stack as the first thing in the catch-lambda,
then the "trim" is stable as you elaborate the body.


Note that changing the debugger option 'frames will possibly change the
depth. Probably some other debug/runtime things will disturb it too.


It does look like you could auto-magically "do the right thing" with
args to make-stack. Then you could use "display-error". I don't know how
to provide the right args to make-stack, however.


I had already decoded the frame for my own purposes (a logging
function), so here's the code above plus it outputs the decoded frame
info (I don't claim this is bullet proof!):
(lazy-catch #t
    (lambda () (+ 1 (hubert)))
    (lambda (key . args)
        (let* (
            (s (make-stack #t))
            (bottom-frames-to-trim 3)
            (frame-of-interest
                (stack-ref s
                    bottom-frames-to-trim))
            (source-me (frame-source frame-of-interest))
            (fname (and source-me (source-property source-me 'filename)))
            (procedure (frame-procedure (frame-of-interest))
            (source-line (and source-me (1+ (source-property source-me
'line))))
            )

        (display (list key args))
        (newline)
        (display-backtrace s (current-output-port)
            (- (stack-length s) 1)
            (- (stack-length s) bottom-frames-to-trim))
    (newline)
    (display ; the decoded frame
        (list
            "file" fname
            "line" source-line
            "argument-of" procedure
            "source" (if (memoized? source-me)
                (unmemoize source-me) source-me)))
    (newline)
    (display "throw on") (newline)
    (throw 'bob))))

Remove the parens from "(hubert)" to see a more interesting
"argument-of" value.


> 
> If I get an elegant solution to my problem, I'll try to package it and
> make a short text on the question, by searching the web I found out that
> I'm not the only one to wish to handle his errors himself, but the
> tutorial does not seem to be written yet 8-)
> 
> Have a nice day and thanks for your help,
> 
> Christian.
> 


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: Getting scheme error informations when running scheme code from C

[Neil Jerram]

Christian Mauduit <ufoot@ufoot.org> writes:

> mmm, OK I see, indeed using:
>
> (debug-enable 'debug)
> (debug-enable 'backtrace)
>
> gave me much more detailed output, thanks for the tip.

FWIW, I use this at the start of my Scheme script (which is also
loaded by a C program - very similar overall structure to yours):

(debug-set! stack 100000)
(if #t
    (begin
      (read-enable 'positions)
      (debug-enable 'debug)
      (debug-enable 'backtrace)
      (debug-set! frames 8)
      (debug-set! depth 50)))

> Well, using lazy-catch and a handler with the line:
>
> (display-backtrace (make-stack #t) some-user-string-output-port)
>
> actually got me very close from solving my problem completely. The only
> point is that the stack I obtain contains many useless things (such as
> the actual functions I'm using within the error handler, which are
> useless...) so I get a garbaged output. I guess there's some way to get
> rid of this by passing cryptic arguments to make-stack.

Not that cryptic; you just pass either an integer or a procedure.  If
you always have 5 frames of your own error handling, for example, then
you just need to say (make-stack #t 5).  The procedure approach
usually looks something like this:

  (define (lazy-catch-handler key . args)
    (let ((stack (make-stack #t lazy-catch-handler)))
      ;; do whatever you want with stack, such as
      ;; saving it off or calling display-backtrace
      )
    (apply throw key args))
  (lazy-catch #t
              thunk
              lazy-catch-handler)

In this case the lazy-catch-handler arg to make-stack means "throw
away all the innermost frames up to and including the
lazy-catch-handler frame".

> BTW trying to
> handle the object returned by make-stack and produce a string output "by
> hand" from it sounded awfully hairy to me. Wee.

Why awfully hairy?  A stack is just a list of frames, and there are
procedures available for getting all the interesting information about
each frame ... how would you improve this?

> If I get an elegant solution to my problem, I'll try to package it and
> make a short text on the question, by searching the web I found out that
> I'm not the only one to wish to handle his errors himself, but the
> tutorial does not seem to be written yet 8-)

Writing a tutorial for this area would indeed be very helpful!

Finally, you might like to know that my guile-debugging package
includes a kind of Emacs display-backtrace front end.  In other words,
when an error occurs, the stack is popped up in Emacs, and Emacs will
pop up the source code for each frame, and so on.  Although the raw
backtrace information is the same (as if you just do a
display-backtrace to some port), I've found this front end to be
effective in allowing me to analyze backtraces very quickly.

Regards,
        Neil



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: Getting scheme error informations when running scheme code from C

[Christian Mauduit]

Hi,

> If we assume that the catch'ing lambda is always the same, then the
> stack-frames related to it should be stable. So, you should be able to
> discard the bottom n frames every time:
> 
> For example:
> (lazy-catch #t
>         (lambda () (+ 1 (hubert)))
>         (lambda (key . args)
>         (let ((s (make-stack #t)))
>         (display (list key args))
>         (newline)
>         (display-backtrace s (current-output-port)
>                 (- (stack-length s) 1)
>                 (- (stack-length s) 3)))
>         (newline)
>         (display "throw on") (newline)
>         (throw 'bob)))
Thanks, this helped a lot!

> I had already decoded the frame for my own purposes (a logging
> function), so here's the code above plus it outputs the decoded frame
> info (I don't claim this is bullet proof!):
> (lazy-catch #t
>     (lambda () (+ 1 (hubert)))
>     (lambda (key . args)
>         (let* (
>             (s (make-stack #t))
>             (bottom-frames-to-trim 3)
>             (frame-of-interest
>                 (stack-ref s
>                     bottom-frames-to-trim))
>             (source-me (frame-source frame-of-interest))
>             (fname (and source-me (source-property source-me 'filename)))
>             (procedure (frame-procedure (frame-of-interest))
>             (source-line (and source-me (1+ (source-property source-me
> 'line))))
>             )
> 
>         (display (list key args))
FYI I use the following code instead, to display args:

(apply format (cons #f (cons (cadr args) (caddr args))))

Unelegant in the source, but displays things in a nicer way IMHO.

Have a nice day,

Christian, problem fixed, happy coder 8-)

-- 
Christian Mauduit <ufoot@ufoot.org>     __/\__ ___
                                        \~/ ~/(`_ \   ___
http://www.ufoot.org/                   /_o _\   \ \_/ _ \_
http://www.ufoot.org/gnupg.pub            \/      \___/ \__)


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: Getting scheme error informations when running scheme code from C

[Stephen Compall]

[-- Attachment #1.1: Type: text/plain, Size: 674 bytes --]

On Sun, 2005-09-11 at 22:19 +0200, Christian Mauduit wrote:
> FYI I use the following code instead, to display args:
> 
> (apply format (cons #f (cons (cadr args) (caddr args))))
> 
> Unelegant in the source, but displays things in a nicer way IMHO.

This is common enough -- requiring some arguments, then providing a rest
argument -- that apply handles it for you:

(apply format #f (cadr args) (caddr args))

Only the last argument must be a list; arguments from the second onward,
but the last one, are effectively consed on to the front of the last
argument (a list), as you do manually.

-- 
Stephen Compall
http://scompall.nocandysoftware.com/blog

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 140 bytes --]

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: Getting scheme error informations when running scheme code from C

[Ludovic Courtès]

Hi,

Neil Jerram <neil@ossau.uklinux.net> writes:

> Finally, you might like to know that my guile-debugging package
> includes a kind of Emacs display-backtrace front end.  In other words,
> when an error occurs, the stack is popped up in Emacs, and Emacs will
> pop up the source code for each frame, and so on.  Although the raw
> backtrace information is the same (as if you just do a
> display-backtrace to some port), I've found this front end to be
> effective in allowing me to analyze backtraces very quickly.

That sounds nice!

What are your plans wrt. to distribution of guile-debugging?  Are you
willing to eventually integrate it into Guile, or to keep distributing
it as a separate package?  In the latter case, it would cool if somebody
volunteered to create a Debian package for it.  :-)

Thanks,
Ludovic.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: Getting scheme error informations when running scheme code from C

[Neil Jerram]

ludovic.courtes@laas.fr (Ludovic Courtès) writes:

> Hi,
>
> Neil Jerram <neil@ossau.uklinux.net> writes:
>
>> Finally, you might like to know that my guile-debugging package
>> includes a kind of Emacs display-backtrace front end.  [...]
>
> That sounds nice!
>
> What are your plans wrt. to distribution of guile-debugging?  Are you
> willing to eventually integrate it into Guile, or to keep distributing
> it as a separate package?

In my view it makes sense to keep it separate for now, while it's
still in the early stages of development.  This means that I can
prepare distributions without being constrained by the core release
cycle, and target both 1.6 and 1.8 with the same code base.

Longer term I think it makes sense to integrate into the core
distribution.

>  In the latter case, it would cool if somebody
> volunteered to create a Debian package for it.  :-)

Absolutely.  I'm not a Debian maintainer myself, but if someone wants
to do this I'm happy to give them write access to the repository on
gna.org, and happy for the debian packaging files to live in the
upstream package (if that's desirable).

> Thanks,
> Ludovic.

Regards,
        Neil



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user