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
