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 > >
csi on Windows, Emacs and srfi 18
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
