[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: scm_wrong_num_args
From: |
Dirk Herrmann |
Subject: |
Re: scm_wrong_num_args |
Date: |
Thu, 29 Mar 2001 02:57:11 +0200 (MEST) |
On 29 Mar 2001, Gary Houston wrote:
> > From: Dirk Herrmann <address@hidden>
> > Date: Sun, 25 Mar 2001 18:17:37 +0200 (MEST)
> >
> > One aspect is (as you have suggested) to make the error reporting
> > functions create continuations to allow to continue the execution after an
> > error has occured. This idea can be extended, for example to use the
> > continuation to extract backtrace information (as a replacement or in
> > addition to the current explicit stack creation mechanism). This would
> > allow to show a mixture of C level and scheme level stack frames.
>
> Restartable exceptions were actually rejected when the current system
> was evolved, see:
>
> http://www.red-bean.com/guile/guile/old/0455.html
>
> Creating a continuation for every exception seems too slow to be used
> in non-debugging sessions.
Thanks for the link. Hmmm. I think that we do not necessarily have a
contradition here: First, we don't need to pass continuations for _every_
exception, only for errors. Further, we can make the creation of a
continuation depend on whether guile is run in debug mode or not.
I don't see the aspect of 'restartability' as the main reason to create a
continuation in case of an error, but rather the aspect that for debugging
a continuation provides all information about the stack you would like to
have (well, not really _all_ information: in case of tail calls you have
to add a little bit extra data).
The major concern that I have about this issue is, that adding such a
feature (i. e. the possibility to scan a C level stack and separate it
into several stack frames) will be quite complicated and require us to
include a lot of platform dependent code. The best solution would be if
some of gdb's code was available as a library, but it seems that such a
project (although once planned) was abandoned.
Best regards,
Dirk
- Re: scm_wrong_num_args, (continued)
- Re: scm_wrong_num_args, Marius Vollmer, 2001/03/13
- Re: scm_wrong_num_args, Martin Grabmueller, 2001/03/14
- Re: scm_wrong_num_args, Dirk Herrmann, 2001/03/14
- Re: scm_wrong_num_args, Dirk Herrmann, 2001/03/15
- Re: scm_wrong_num_args, Marius Vollmer, 2001/03/24
- Re: scm_wrong_num_args, Dirk Herrmann, 2001/03/25
- Re: scm_wrong_num_args, Dale P. Smith, 2001/03/27
- Re: scm_wrong_num_args, Marius Vollmer, 2001/03/30
- Re: scm_wrong_num_args, Dale P. Smith, 2001/03/27
- Re: scm_wrong_num_args, Gary Houston, 2001/03/28
- Re: scm_wrong_num_args,
Dirk Herrmann <=
- Re: scm_wrong_num_args, Marius Vollmer, 2001/03/30
- Re: scm_wrong_num_args, Marius Vollmer, 2001/03/30
- Re: scm_wrong_num_args, Marius Vollmer, 2001/03/24
- Re: scm_wrong_num_args, Dirk Herrmann, 2001/03/25
- Re: scm_wrong_num_args, Marius Vollmer, 2001/03/30