Re: csi on Windows, Emacs and srfi 18

Hi George,

I think the problem may also be that your primordial thread is blocking all srfi-18 threads in it's (read) call. Possibly in addition to the missing output-flush calls.

I used to get around this in Chicken 4 by using the 'perley' egg, but it's not available for Chicken 5. You could simply (current-input-port (make-perley-port)) and have a non-srfi18-blocking stdin.

Maybe you could see if http://wiki.call-cc.org/eggref/5/breadline or http://wiki.call-cc.org/eggref/5/linenoise could fix it?

Also, I found an old paste where I was having similar issues for subprocesses. You could see if there are some useful tricks in there: http://paste.call-cc.org/paste?id=dc1ec82557b9ea5846ec976a9987d53d83f401e3

In particular, you could try the last snippet:

;; don't block while reading anything from port p. port p must have an
;; associated filedescriptor.
(define (make-nonblocking-input-port p)
  (make-input-port (lambda ()
                     (thread-wait-for-i/o! (port->fileno p))
                     (read-char p))
                   (lambda () (char-ready? p))
                   (lambda () (close-input-port p))))

And then add:

(current-input-port (make-nonblocking-input-port (current-input-port)))

On Sun, Jul 5, 2020, 21:34 George Oliver <georgeolivergo@gmail.com> wrote:

Hello Kristian and thanks for looking into this.

On Sun, Jul 5, 2020 at 12:51 AM Kristian Lein-Mathisen
<kristianlein@gmail.com> wrote:

> The sys##flush-output here is what you're looking for I think. It's problably not being called due to tty-input? returning #f. But it might work to redefine it to our needs:

I think this could possibly work but I couldn't get it working on my
system. Example session on my Emacs:

===================

CHICKEN
(c) 2008-2020, The CHICKEN Team
(c) 2000-2007, Felix L. Winkelmann
Version 5.2.0 (rev 317468e4)
mingw32-windows-gnu-x86-64 [ 64bit dload ptables ]

Type ,? for help.
#;1> ; loading C:/Users/george/AppData/Roaming/chicken/11/srfi-18.import.so ...
; loading C:/Users/george/AppData/Roaming/chicken/11/srfi-18.so ...
#;2>
<------------ here I evaluated define foo from the example code in
my first email in the thread
#;3> ##sys#read-prompt-hook
#<procedure (##sys#read-prompt-hook)>
#;4> (set! ##sys#read-prompt-hook (lambda () (display "test> ") (flush-output)))
test> #<thread: thread24> <--------------
here I evaluated thread-start!
test> foo
10
test> foo
10
test> foo
10
test> ,q

Process scheme finished

===================

Curiously this behavior is different than evaluating the test without
redefining the read-prompt-hook; in that first case repeated evals of
foo will iterate the loop in the thread-start!.

I got the same result running csi from the WIndows console.

I say it could possibly work because it seems like output buffering is
an issue here, for reference see
https://lists.gnu.org/archive/html/help-gnu-emacs/2006-04/msg00250.html.

However I got farther with solution 2!

>
> ===== possible solution 2 =====
>
> It's possible that using a real socket might be a feasable workaround. `chicken-install nrepl` and start a session (outside of emacs) with
>
> > csi -R nrepl -e '(nrepl 1234)'

I actually had tried this earlier, but since Windows doesn't have the
nc utility it wasn't straightforward. I found the netcat Windows
utility but it took me a couple of tries to realize Windows was
disabling it (via Windows Security protection).

Example session:

==============

;; nrepl on (C:\Users\george\bin\chicken-5.2.0\bin\csi.exe -R nrepl -e
(nrepl 1234))
#;> <---------- here I evaluate the
import, not sure why it doesn't print the output
#;> <---------- here I evaluate define foo
#;> #<thread: thread30> <---------- evaluating thread-start!
#;> #<procedure (scheme#current-output-port . args)>
#<procedure (scheme#current-output-port . args)>
#<procedure (scheme#current-output-port . args)>
#<procedure (scheme#current-output-port . args)>
#<procedure (scheme#current-output-port . args)>
#<procedure (scheme#current-output-port . args)>
#<procedure (scheme#current-output-port . args)>
#<procedure (scheme#current-output-port . args)>
#<procedure (scheme#current-output-port . args)>
#<procedure (scheme#current-output-port . args)>
0 <--------------- evaluating foo
#;>

========================

So this seems like it could work!

One wrinkle is that csi toplevel commands don't seem to pass through
netcat correctly (for example ',q' returns 'Error: unbound variable:
unquote'). But that doesn't seem like a show stopper.

There is also a possibly more robust long-term solution that I just
learned about it. In recent Windows 10 updates MS released ConPTY,
which is a new pseudo tty API. See
https://devblogs.microsoft.com/commandline/windows-command-line-introducing-the-windows-pseudo-console-conpty/.
Currently, when Emacs creates an asynchronous subprocess, it assumes
Windows has no PTY and defaults to using a pipe. It seems workable to
patch Emacs to use the new ConPTY. I'm going to see about getting this
into Emacs.

thanks again, George

From:	Dan Leslie
Subject:	Re: csi on Windows, Emacs and srfi 18
Date:	Sun, 05 Jul 2020 23:07:14 +0000