unofficial mirror of guile-user@gnu.org 
 help / color / mirror / Atom feed
From: Bruce Korb <bkorb@veritas.com>
Cc: Joris van der Hoeven <TeXmacs@math.u-psud.fr>
Subject: Re: PLEASE: debugging embedded guile code
Date: Sat, 26 Apr 2003 09:40:49 -0700	[thread overview]
Message-ID: <3EAAB691.6AD935B5@veritas.com> (raw)
In-Reply-To: m3znmd8g72.fsf@laruns.ossau.uklinux.net

Neil Jerram wrote:
>     >> So: what should I do in order to enable debugging support
>     >> for embedded Guile code? How can I retrieve the location of
>     >> a possible error when calling guile code from the main program?

>     Dale> Here is how I did it in mod-guile:
> 
>     Dale> SCM
>     Dale> mg_lazy_handler(void *data, SCM tag, SCM throw_args)
>     Dale> {
>     Dale>   SCM eport = scm_current_error_port(); [...]
> 
> I'm curious about this because the question of error handling keeps
> popping up and I'm wondering whether our current solution is good
> enough.  (With a strong suspicion that it isn't.)
> 
> One thing I'm not sure I understand is why you want (or perhaps need)
> to do this lazy-catch in C rather than in Scheme, since it would be
> much easier in Scheme.  Can you explain?

The need is to be able to point our clients to problems in the
Scheme code.  We (or, at least, I) know where in our client's
input we are when we hand a string off to Guile for evaluation.
I'd like to be able to tell Guile what the current file name
and line number so that when it emits an error message, Guile
can refer to our client's source file.  As it is, I have to
set an atexit routine.  All it is able to tell is that Guile
called exit(3C) and it must now emit a generic "this is where
we were when Guile called exit" message:

    switch (procState) {
    case PROC_STATE_EMITTING:
    case PROC_STATE_INCLUDING:
        /*
         *  A library (viz., Guile) procedure has called exit(3C).
         *  The AutoGen abort paths all set procState to PROC_STATE_ABORTING.
         */
        if (*pzOopsPrefix != NUL) {
            /*
             *  Emit the CGI page header for an error message.
             */
            fputs( pzOopsPrefix, stderr );
            pzOopsPrefix = "";
        }

        fprintf( stderr, zErr, pCurTemplate->pzFileName, pCurMacro->lineNo );

Of course, I have to do a bunch of magic anyway because if there
is an error exit, I may or may not have to emit a CGI-style preamble:

> static const char zOops[] =
> "Content-type: text/plain\n\n"
> "AutoGen form processing error:\n";

but it would still be nice to have the above file/line woven into
the native Guile message as it is for the interactive guile program.


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


  reply	other threads:[~2003-04-26 16:40 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-02-08 11:12 Source locations Joris van der Hoeven
2003-02-08 17:22 ` Wolfgang Jaehrling
2003-02-09 19:05   ` Joris van der Hoeven
2003-02-25 14:19     ` PLEASE: debugging embedded guile code Joris van der Hoeven
2003-02-25 14:36       ` Dale P. Smith
2003-02-27 12:17         ` Customized error reports Joris van der Hoeven
2003-02-28 18:06           ` Paul Jarc
2003-04-26 14:51         ` PLEASE: debugging embedded guile code Neil Jerram
2003-04-26 16:40           ` Bruce Korb [this message]
2003-04-26 19:12             ` Neil Jerram
2003-04-26 20:13               ` Bruce Korb
2003-04-26 22:25                 ` Thien-Thi Nguyen
2003-04-27 20:49                 ` Neil Jerram
2003-04-27 21:57                   ` Bruce Korb
2003-04-28 15:54                     ` Paul Jarc
2003-04-28 16:07                       ` Bruce Korb
2003-04-28 19:21                     ` Neil Jerram
2003-04-28 20:06                       ` Bruce Korb
2003-04-28 20:58                         ` Neil Jerram
2003-05-16 17:19                           ` Bruce Korb
2003-05-16 19:23                             ` Neil Jerram
2003-05-16 20:27                               ` Bruce Korb
2003-05-16 21:21                                 ` Rob Browning
2003-05-16 21:56                                   ` Bruce Korb
2003-05-17  0:31                                     ` Bruce Korb
2003-05-17  2:33                                       ` Bruce Korb
2003-05-19 15:00                                         ` Paul Jarc
2003-04-28 13:52           ` Mikael Djurfeldt
2003-04-28 19:26             ` Neil Jerram
2003-04-26 14:45       ` Neil Jerram

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3EAAB691.6AD935B5@veritas.com \
    --to=bkorb@veritas.com \
    --cc=TeXmacs@math.u-psud.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).