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