From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Christian Mauduit Newsgroups: gmane.lisp.guile.user Subject: Re: Getting scheme error informations when running scheme code from C Date: Sat, 10 Sep 2005 23:36:17 +0200 Message-ID: <432351D1.8010102@ufoot.org> References: <4322DE2C.60801@ufoot.org> <4322EEBA.1090202@mail.msen.com> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: sea.gmane.org 1126388112 26204 80.91.229.2 (10 Sep 2005 21:35:12 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 10 Sep 2005 21:35:12 +0000 (UTC) Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Sat Sep 10 23:35:01 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1EECz1-0000ss-0l for guile-user@m.gmane.org; Sat, 10 Sep 2005 23:33:59 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EECyz-0007ix-De for guile-user@m.gmane.org; Sat, 10 Sep 2005 17:33:57 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EECyF-0007Rz-Eu for guile-user@gnu.org; Sat, 10 Sep 2005 17:33:11 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EECy8-0007PR-O6 for guile-user@gnu.org; Sat, 10 Sep 2005 17:33:06 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EECy8-0007PF-EF for guile-user@gnu.org; Sat, 10 Sep 2005 17:33:04 -0400 Original-Received: from [212.27.42.29] (helo=smtp3-g19.free.fr) by monty-python.gnu.org with esmtp (Exim 4.34) id 1EECxL-0002F6-L8 for guile-user@gnu.org; Sat, 10 Sep 2005 17:32:16 -0400 Original-Received: from moulin (arl95-1-82-232-241-64.fbx.proxad.net [82.232.241.64]) by smtp3-g19.free.fr (Postfix) with ESMTP id 89A4B23E7C for ; Sat, 10 Sep 2005 23:31:56 +0200 (CEST) Original-Received: from guenegaud.streets ([192.168.0.4]) by moulin with esmtp (Exim 4.50) id 1EECx1-0004yX-10 for guile-user@gnu.org; Sat, 10 Sep 2005 23:31:56 +0200 User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050803) X-Accept-Language: fr, en Original-To: guile-user@gnu.org In-Reply-To: <4322EEBA.1090202@mail.msen.com> X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.user:4734 Archived-At: Alan Grover a =E9crit : > My comments are for Guile version 1.6.4. >=20 > 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. >=20 > 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 an= d > 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")? Yo= u > could wrap your scheme code in a "catch", or use scm_catch. Section "Ho= w > to Handle Errors in C Code" has some hints. Lazy-catch lets you capture > the stack. >=20 > 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 an= d > just call it.) >=20 > You may also find the section "Debugging Infrastructure" interesting. I= t > talks about decoding the stack, and limiting the backtrace. >=20 >=20 > 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. --=20 Christian Mauduit __/\__ ___ \~/ ~/(`_ \ ___ 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