Re: csi on Windows, Emacs and srfi 18
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 wrote: > >> Hello Kristian and thanks for looking into this. >> >> On Sun, Jul 5, 2020 at 12:51 AM Kristian Lein-Mathisen >> 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 >> # >> #;4> (set! ##sys#read-prompt-hook (lambda () (display "test> ") >> (flush-output))) >> test> # <-- >> 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 >> #;> # <-- evaluating thread-start! >> #;> # >> # >> # >> # >> # >> # >> # >> # >> # >> # >> 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
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))) K. On Sun, Jul 5, 2020, 21:34 George Oliver wrote: > Hello Kristian and thanks for looking into this. > > On Sun, Jul 5, 2020 at 12:51 AM Kristian Lein-Mathisen > 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 > # > #;4> (set! ##sys#read-prompt-hook (lambda () (display "test> ") > (flush-output))) > test> # <-- > 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 > #;> # <-- evaluating thread-start! > #;> # > # > # > # > # > # > # > # > # > # > 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 > >
Re: csi on Windows, Emacs and srfi 18
Hello Kristian and thanks for looking into this. On Sun, Jul 5, 2020 at 12:51 AM Kristian Lein-Mathisen 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 # #;4> (set! ##sys#read-prompt-hook (lambda () (display "test> ") (flush-output))) test> # <-- 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 #;> # <-- evaluating thread-start! #;> # # # # # # # # # # 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
Re: csi on Windows, Emacs and srfi 18
Hi George, and welcome to the community! I made that video and I'm glad it caught your interest. I don't know a lot about the inner workings of Chicken or Win10 pretend-tty's, and I don't have a machine available where I can test. But I thought I'd throw in a couple of things you can try. = possible solution 1 = In csi.scm, I found: 262 | (define (tty-input?) 261 │ (or (##core#inline "C_i_tty_forcedp") 262 │ (##sys#tty-port? ##sys#standard-input))) 263 │ 264 │ (set! ##sys#break-on-error #f) 265 │ 266 │ (set! ##sys#read-prompt-hook 267 │ (let ([old ##sys#read-prompt-hook]) 268 │ (lambda () 269 │ (when (tty-input?) (old)) ) ) ) It seems the csi is trying to disable the input prompt unless we're interactive. In repl.scm, I found the hook: (define ##sys#read-prompt-hook 61 │ (let ((repl-prompt repl-prompt)) 62 │ (lambda () 63 │ (##sys#print ((repl-prompt)) #f ##sys#standa │ rd-output) 64 │ (##sys#flush-output ##sys#standard-output))) │ ) 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: me@termux > csi (c) 2008-2020, The CHICKEN Team (c) 2000-2007, Felix L. Winkelmann Version 5.2.0rc1 (prerelease) (rev 44ea9ed5) Type ,? for help. #;1> ##sys#read-prompt-hook # #;2> (set! ##sys#read-prompt-hook (lambda () (display "test> ") (flush-output))) test> "new prompt!" "new prompt!" test> ^C I hope that works on your win10-emacs session too. If not, you could try this: = 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)' Then, from emacs, do C-u M-x run-scheme nc localhost 1234 To have emacs use the networked REPL. Best of luck! K. On Sat, Jul 4, 2020, 04:46 George Oliver wrote: > hello, > > I'm a new Chicken user and new to Scheme in general, and I'm working > through an issue with csi and srfi 18 in Emacs on Windows 10 (though > the same problem seems to exist with csi in the native terminal). > Basically Windows doesn't properly flush output from a non-primordial > thread. An example of what I'm trying to replicate is in this tutorial > video, https://youtu.be/eXB3I3S3vJc?t=387 , and sample code would be: > > (import > (srfi 18)) > > (define foo 10) > > (thread-start! > (lambda () >(let loop () > (when (< 0 foo) >(set! foo (sub1 foo)) >(print foo) >(thread-sleep! 1) >(loop) > > > I think this is a general problem with Windows and was mentioned on > this list some time ago, > https://lists.nongnu.org/archive/html/chicken-users/2006-09/msg00222.html. > As a reply in that thread noted, > > > This is a Windows-specific problem - isatty() returns #f on Windows > inside > > emacs. I assume select() (which is AFAIK not particularly efective on > non-socket > > fd's under Windows) is the problem, since either -:c or > > ##sys#tty-port? -> #t should > > block the thread waiting for input on fd 0 (and thus letting other > threads run). > > I'm interested in trying to solve this problem and I'm wondering what > input Chicken users have on possible solutions and workarounds (other > than of course not using Windows or Windows/WSL). An Emacs maintainer > commented, > > > Evidently, the Scheme interpreter you run assumes it is always connected > to a terminal device. > > But MS-Windows doesn't have Unix PTYs, so subordinate processes are run > by Emacs via pipes, > > and the Scheme interpreter you are using doesn't seem to like it. > > > The way to solve this is in the Scheme interpreter: > > it should provide an optional behavior whereby the interactive features > work > > even if the standard streams are connected to a pipe, and it should > disable buffering > > of the standard streams in this case. > > Is that optional behavior workable? Or perhaps there is some other > indirection that could achieve the same result. > > In case it matters my ultimate goal here is to interactively develop > while the program is running. > > thanks for any advice, George > >
