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.
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.
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.