unofficial mirror of guile-user@gnu.org 
 help / color / mirror / Atom feed
From: Neil Jerram <neil@ossau.uklinux.net>
Cc: Clinton Ebadi <clinton@unknownlamer.org>,
	Guile Users <guile-user@gnu.org>
Subject: Re: Enabling Debugging
Date: Mon, 04 Sep 2006 08:35:37 +0100	[thread overview]
Message-ID: <878xl09j92.fsf@ossau.uklinux.net> (raw)
In-Reply-To: <20060801104631.GC1323@alamut.tdm.local> (Volkan YAZICI's message of "Tue, 1 Aug 2006 13:46:31 +0300")

Volkan YAZICI <yazicivo@ttnet.net.tr> writes:

> On Jul 31 10:53, dave wrote:
>> I had to work through this a while back, and the problem I had was that
>> there are two types of error handler callback - one is called before the
>> stack is unwound, the other after. If you only set the error callback
>> for after the unwind there is no stack to do the debugging...
>
> Can you send an example working code snippet please?

You've probably seen the new doc on this subject that I posted to the
guile list a few days ago.  This is also now in the CVS reference
manual (node "Debug on Error"), and I hope that it answers most of
your questions; please let me know if not.

> I've considered your "before the stack is unwound and the other after"
> explanation and concluded with such a scm_c_catch() call:
>
>   scm_c_catch(SCM_BOOL_T,                       /* tag */
>              (scm_t_catch_body) eval_code,      /* body */
>              (void *) code,                     /* body data */
>              (scm_t_catch_handler) catch_err,   /* handler */
>              (void *) code,                     /* handler data */
>              (scm_t_catch_handler) unwind_catch,
>              (void *) code);
>
> But scm_backtrace(), that's placed in both catch_err() and
> unwind_catch(), still complains that "No backtrace available".

Yes; this is because the stack still needs to be captured explicitly
by a scm_make_stack call, within unwind_catch.

> Doesn't anybody have a working example code snippet? How did ppl achieve
> to write so much programs using guile?

I personally like to write as much as possible in Scheme, so I'm
afraid I don't have a tested example.

(In other words, I make a single call out from C to Scheme, using
scm_call or scm_apply, then code whatever exception handling I need
in Scheme, within the function that was called from C.)

> Furthermore, I've another problem: How do we receive information from
> tag and args variables passed to exception handlers? I was using
>
>   buf = SCM_STRING_CHARS(tag);
>   len = SCM_STRING_LENGTH(tag);
>   while (len-- > 0)
>       putchar(*buf++);
>
> method but, in the new 1.8 release it says that I'm using deprecated
> functions. So how can get the pointer pointing to the related text
> buffer? I cannot use gh_scm2newstr() in this situation, because it
> allocates required buffer itself and just dumps an error to stderr
> in case of a failure. Actually, I'm working on a shared memory segment
> thus I don't want guile to make any memory allocations on its own.
> Can I achieve such a functionality? (I want it to use palloc/pfree
> instead of recent malloc/free calls.) Can a macro hack like
>
>   #define malloc palloc
>   #define free   pfree
>
> solve that problem?

The tag is actually a symbol.  What do you want to do with it?  If you
want to test it for equality (with scm_misc_error_key, for example),
use "scm_is_eq (tag, scm_misc_error_key)".  If you want to print it
out to the current output port, use "scm_display (tag,
SCM_UNDEFINED)".

> Moreover, as far as SCM_CONSP(args) says so, the third param (args)
> passed to exception handlers is a cons. Despite I've tried some
> gh_car(), gh_cdr() tricks, I couldn't manage to figure out how to use
> that information too.

This - i.e. knowing how to interpret exception args - is an ongoing
problem.  Please see and contribute to the discussion in another
thread.

Regards,
     Neil



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


      reply	other threads:[~2006-09-04  7:35 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-07-29 11:30 Enabling Debugging Volkan YAZICI
2006-07-29 19:08 ` Clinton Ebadi
2006-07-31  7:13   ` Volkan YAZICI
2006-07-31  9:53     ` dave
2006-08-01 10:46       ` Volkan YAZICI
2006-09-04  7:35         ` Neil Jerram [this message]

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=878xl09j92.fsf@ossau.uklinux.net \
    --to=neil@ossau.uklinux.net \
    --cc=clinton@unknownlamer.org \
    --cc=guile-user@gnu.org \
    /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).