From: Peter TB Brett <peter@peter-b.co.uk>
To: guile-user@gnu.org
Subject: Re: Help needed debugging segfault with Guile 1.8.7
Date: Tue, 30 Nov 2010 19:56:30 +0000 [thread overview]
Message-ID: <m38w0ah9g1.fsf@harrington.peter-b.co.uk> (raw)
In-Reply-To: AANLkTikAzGV1e21bZUFuqRrcQxVoi8aBDMwkZ2gpNHDZ@mail.gmail.com
[-- Attachment #1: Type: text/plain, Size: 1972 bytes --]
Linas Vepstas <linasvepstas@gmail.com> writes:
> Basically, if you are going to let users enter arbitrary scheme into
> your app, they *will* enter malformed, broken expressions, and you
> have to deal with these. Among other things, you have to give them
> a clue as to what the error was -- some sort of trace, error reporting.
>
> For me, this was implementing a REPL loop look-alike in my app.
> I can't say "work-alike", I think mine *almost* works-alike, but not sure.
>
> It took me a *long* time to figure out I needed the pre-unwind version
> of things, and even then, it took me a fair amount of effort to figure
> out what to put in there.
>
> Having a section showing how to implement a repl-work-alike loop
> in one's app, with reasonable debugging/stack-printing output,
> would be nice to have. Figuring out how to do this one one's
> own requires a lot of tenacity.
Guile 2.x would be hugely more attractive as an extension language if
there were some higher-level interfaces for application developers. In
gEDA, we have to use a ridiculous amount of C code just to set things up
so that user-provided Scheme expressions can't leave the user staring at
a command prompt wondering where the last hour's work disappeared to
(and even that's not as reliable as we'd like).
Ideally, there should be:
- An easily re-usable/embeddable and well-documented REPL, to aid
developers in implementing a "Scheme Interaction Window" or similar
in their apps.
- An high-level API for passing strings for evaluation, that reports
back the results or error information in a way that's easy to deal
with from C.
In a perfect world, these would be part of the same API. ;-) I believe
that these would actually be applicable to the majority of use-cases of
libguile.
Cheers,
Peter
--
Peter Brett <peter@peter-b.co.uk>
Remote Sensing Research Group
Surrey Space Centre
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
next prev parent reply other threads:[~2010-11-30 19:56 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-10 12:43 Help needed debugging segfault with Guile 1.8.7 Peter TB Brett
2010-11-10 21:35 ` Peter TB Brett
2010-11-11 10:52 ` Peter Brett
2010-11-11 12:37 ` Thien-Thi Nguyen
2010-11-11 14:22 ` Peter Brett
2010-11-28 11:38 ` Neil Jerram
2010-11-28 17:21 ` Linas Vepstas
2010-11-30 19:56 ` Peter TB Brett [this message]
2010-12-01 19:48 ` Andy Wingo
2010-11-30 19:43 ` Peter TB Brett
2010-12-01 13:46 ` Ludovic Courtès
2010-12-03 7:52 ` Peter TB Brett
2010-11-11 8:22 ` rixed
2010-11-11 8:33 ` Neil Jerram
2010-11-11 13:30 ` Ludovic Courtès
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=m38w0ah9g1.fsf@harrington.peter-b.co.uk \
--to=peter@peter-b.co.uk \
--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).