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
next prev parent 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).