Re: REPL history

[Vladimir Zhbanov <vzhbanov@gmail.com>]

On Tue, Mar 07, 2017 at 10:23:02AM +0100, Andy Wingo wrote:
> 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!

Thank you for the explanation!

-- 
  Vladimir