unofficial mirror of guile-user@gnu.org 
 help / color / mirror / Atom feed
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 --]

  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).