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 <[email protected]> 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
>
>
