unofficial mirror of guile-user@gnu.org 
 help / color / mirror / Atom feed
From: Andy Wingo <wingo@pobox.com>
To: guile-user@gnu.org
Subject: Re: REPL history
Date: Tue, 07 Mar 2017 10:23:02 +0100	[thread overview]
Message-ID: <87wpc18mq1.fsf@pobox.com> (raw)
In-Reply-To: <20170306214429.GB27659@localhost.localdomain> (Vladimir Zhbanov's message of "Tue, 7 Mar 2017 00:44:29 +0300")

On Mon 06 Mar 2017 22:44, Vladimir Zhbanov <vzhbanov@gmail.com> writes:

> What I tried so far is to manually save dynamic state in repl:
>   (define ds (current-dynamic-state))
>
> and use it in GUI (with support of guile expression evaluation):
>   (with-dynamic-state ds (lambda () (write-history history-filename)))
>
> This is for readline history saving, and works pretty well.
>
> So I was thinking to bake something like this into the above code,
> probably by adding a variable on the repl-eval stage to store
> initial dynamic state in repl. The problem occured when I started
> to call (quit) or (throw 'quit) the same way, that is, in the
> thunk called in with-dynamic-state. It just segfaulted.
>
> And my app is tied to 2.0 these days.

There is a bug in 2.0 (and actually in 2.2 as well; closer to being
fixed but not fixed entirely) about moving dynamic states between
threads.  Basically the dynamic state also captures exception handlers,
but attempting to handle the exceptions tries to abort to prompts that
aren't live, leading to sadness.  This NEWS entry discusses part of the
problem:

  ** Fix too-broad capture of dynamic stack by delimited continuations

  Guile was using explicit stacks to represent, for example, the chain of
  current exception handlers.  This means that a delimited continuation
  that captured a "catch" expression would capture the whole stack of
  exception handlers, not just the exception handler added by the "catch".
  This led to strangeness when resuming the continuation in some other
  context like other threads; "throw" could see an invalid stack of
  exception handlers.  This has been fixed by the addition of the new
  "fluid-ref*" procedure that can access older values of fluids; in this
  way the exception handler stack is now implicit.  See "Fluids and
  Dynamic States" in the manual, for more on fluid-ref*.

I don't know if we will be able to fix this in 2.0 or not :/ I'm very
sorry that you have run into all these problems though!

Andy



  reply	other threads:[~2017-03-07  9:23 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-05 17:06 REPL history Vladimir Zhbanov
2017-03-05 17:57 ` tomas
2017-03-06 19:15   ` Vladimir Zhbanov
2017-03-06 20:29     ` tomas
2017-03-06 20:48     ` Andy Wingo
2017-03-06 21:44       ` Vladimir Zhbanov
2017-03-07  9:23         ` Andy Wingo [this message]
2017-03-07 14:44           ` Vladimir Zhbanov

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=87wpc18mq1.fsf@pobox.com \
    --to=wingo@pobox.com \
    --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).