REPL history

REPL history

[Vladimir Zhbanov]

Hi Guile users,

Is there any way to use history of work done in a spawned REPL?

My GUI application spawns a REPL server in background terminal:

(use-modules (system repl server))
(spawn server)

Then users manually run:
(use-modules (ice-9 readline))
(activate readline)

However, after quitting the application, the history is not
saved. I always see the history of commands used in guile itself,
not one of my app.

When I use readline-options, it shows some file is used:

scheme@(guile-user)> (readline-options 'history)
history-file		yes	Use history file.
history-length		200	History length.
bounce-parens		500	Time (ms) to show matching opening parenthesis (0 = off).

I don't know which file is used, anyway.

Are there any options to get history in spawned REPL?

-- 
  Vladimir

Re: REPL history

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sun, Mar 05, 2017 at 08:06:31PM +0300, Vladimir Zhbanov wrote:
> Hi Guile users,
> 
> Is there any way to use history of work done in a spawned REPL?
> 
> My GUI application spawns a REPL server in background terminal:
> 
> (use-modules (system repl server))
> (spawn server)
> 
> Then users manually run:
> (use-modules (ice-9 readline))
> (activate readline)
> 
> However, after quitting the application, the history is not
> saved. I always see the history of commands used in guile itself,
> not one of my app.
> 
> When I use readline-options, it shows some file is used:
> 
> scheme@(guile-user)> (readline-options 'history)
> history-file		yes	Use history file.
> history-length		200	History length.
> bounce-parens		500	Time (ms) to show matching opening parenthesis (0 = off).
> 
> I don't know which file is used, anyway.

Here it is ~/.guile_history (perhaps this helps you in your quest). And
the manual has this to say:

   You can specify a different history file by setting the environment
   variable `GUILE_HISTORY'.  And you can make Guile specific
   customizations to your `.inputrc' by testing for application `Guile'

I don't know off-the-bat whether there's a way to change that (other than
setting the environment variable, that is)

> Are there any options to get history in spawned REPL?

Hm. I'm not sure I understand what you mean.

Regards
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAli8UXkACgkQBcgs9XrR2kbYbACfbix3bIKrrHHMqlGGMezQUV+j
RzgAn0H0qfKvkqcSmnWkr48Y8PnyTxn8
=eaGw
-----END PGP SIGNATURE-----

Re: REPL history

[Vladimir Zhbanov]

I probably confused things and my previous post is not correct.

OK, put things other ways. I have a GUI app which starts REPL in
another thread. Is there a way to call a thunk in that REPL from
the GUI app? Basically, I want it to exit gracefully by calling
(quit) in the REPL before GUI exits. 

-- 
  Vladimir

Re: REPL history

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, Mar 06, 2017 at 10:15:02PM +0300, Vladimir Zhbanov wrote:
> I probably confused things and my previous post is not correct.
> 
> OK, put things other ways. I have a GUI app which starts REPL in
> another thread. Is there a way to call a thunk in that REPL from
> the GUI app? Basically, I want it to exit gracefully by calling
> (quit) in the REPL before GUI exits. 

Understood.

Sorry, I fear this is over my head. Hope more knowledgeable folks
chime in :-)

regards
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAli9xrcACgkQBcgs9XrR2kYvzQCfcqpt9ftJ5T5cNTNeBgC6vxtH
i+wAn1t7G93UOvwOhdaCFP+VuW+3agxa
=lIRd
-----END PGP SIGNATURE-----

Re: REPL history

[Andy Wingo]

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

> OK, put things other ways. I have a GUI app which starts REPL in
> another thread. Is there a way to call a thunk in that REPL from
> the GUI app? Basically, I want it to exit gracefully by calling
> (quit) in the REPL before GUI exits. 

What if, in your GUI app, you call stop-server-and-clients! from (system
repl server) ?  That aborts to a prompt to unwind the stack, so it's not
catchable but a dynamic-wind out guard will run.  Only really works in
2.2 tho I think.

Andy

Re: REPL history

[Vladimir Zhbanov]

On Mon, Mar 06, 2017 at 09:48:51PM +0100, Andy Wingo wrote:
> On Mon 06 Mar 2017 20:15, Vladimir Zhbanov <vzhbanov@gmail.com> writes:
> 
> > OK, put things other ways. I have a GUI app which starts REPL in
> > another thread. Is there a way to call a thunk in that REPL from
> > the GUI app? Basically, I want it to exit gracefully by calling
> > (quit) in the REPL before GUI exits. 
> 
> What if, in your GUI app, you call stop-server-and-clients! from (system
> repl server) ?  That aborts to a prompt to unwind the stack, so it's not
> catchable but a dynamic-wind out guard will run.  Only really works in
> 2.2 tho I think.

Well, I confused things, as I already said, and my first question
was incorrect. Really, I have a procedure something like the following:

(define (my-repl)
  (let ((repl (make-repl (current-language) #f))
        (history-filename (make-custom-history-filename)))
    (repl-eval repl
               `(begin
                  (use-modules (ice-9 session) ; help, apropos and such
                               (system repl command)) ; guile meta-commands
                  (display "Welcome to my REPL!\n" (current-error-port))
                  (resolve-module '(ice-9 readline))
                  ;; After resolving that module the variable
                  ;; *features* should contain 'readline.
                  (if (provided? 'readline)
                      (begin
                        (use-modules (ice-9 readline))
                        ((@ (ice-9 readline) activate-readline))
                        ((@ (ice-9 readline) read-history) ,history-filename))
                      (display "Readline is not supported in your configuration.\n")
                               (current-error-port))))
    (run-repl repl)))

So I don't use repl server here.

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.

-- 
  Vladimir

Re: REPL history

[Andy Wingo]

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

Re: REPL history

[Vladimir Zhbanov]

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