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 #<procedure> #;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 <RET> nc localhost 1234 To have emacs use the networked REPL. Best of luck! K. On Sat, Jul 4, 2020, 04:46 George Oliver <georgeolive...@gmail.com> 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 > >