Parley, wasn't it? I, too, worked around this issue on windows using parley.
-Dan -------- Original Message -------- On Jul 5, 2020, 13:29, Kristian Lein-Mathisen wrote: > 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 <georgeolive...@gmail.com> wrote: > >> Hello Kristian and thanks for looking into this. >> >> On Sun, Jul 5, 2020 at 12:51 AM Kristian Lein-Mathisen >> <kristianl...@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
