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

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!

On Sat, Jul 4, 2020, 04:46 George Oliver <georgeolivergo@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

From:	Kristian Lein-Mathisen
Subject:	Re: csi on Windows, Emacs and srfi 18
Date:	Sun, 5 Jul 2020 09:51:22 +0200