Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

No support for line-buffered ports or non-buffered custom ports #930

Open
dusxmt opened this issue Jul 29, 2023 · 1 comment
Open

No support for line-buffered ports or non-buffered custom ports #930

dusxmt opened this issue Jul 29, 2023 · 1 comment

Comments

@dusxmt
Copy link

dusxmt commented Jul 29, 2023

Hi there,

I'm writing a GUI application where I'd like to use Chibi-Scheme as an embedded interpreter, with it directly available to the user through a REPL implemented in a text view widget, but I've hit a bit of a limitation with the custom ports.

Currently, the only type of custom port that's supported are buffered ports, which is great for generating batches of data, but not ideal for interactive use (implementing stdout and stderr with the custom ports).

Now, I can somewhat work around this by flushing stdout and stderr each time a command runs to completion, and by asking the user to call (flush-output) or (flush-output-port) when they want output data to appear immediately (e.g. during long computations or when stdin input is requested), but then a problem arises with exceptions, which are by their very nature unpredictable, so I'd like to be able use a non-buffered or at least line-buffered stream for my custom stderr port.

Is this something that you'd be willing to add to the project? I'd potentially be willing to work on a merge request!

Thanks!
Marek

p.s. the arguments and return values for the custom port callbacks are really counter-intuitive, instead of a "start index" and "end index", I think a better description would be "start buffer fill" (for input) and "buffer size" (since it's off-by-one to be an end index), with the return value of the input callback being the "resulting buffer fill", since its value is start+bytes_read. What should the return value of the write callback be? Since it seems to be always called with 0 for the start argument, so "byte count written" works, but I'm not sure, since that wasn't the case for the input callback.

@ashinn
Copy link
Owner

ashinn commented May 30, 2024

I don't have time myself but patches are welcome. If you can keep it small and non-intrusive it can go into (chibi io), otherwise a separate library would be better.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants