Re: REPL history

[Andy Wingo]

On Mon 06 Mar 2017 22:44, Vladimir Zhbanov <address@hidden> 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