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))) K. On Sun, Jul 5, 2020, 21:34 George Oliver <[email protected]> wrote: > Hello Kristian and thanks for looking into this. > > On Sun, Jul 5, 2020 at 12:51 AM Kristian Lein-Mathisen > <[email protected]> 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 > >
