-
Notifications
You must be signed in to change notification settings - Fork 329
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
SBCL stream sockets fail to flush #29
Labels
Comments
@brown, you attached this patch to this original issue, can you confirm it still holds?
|
A change similar to the patch I recommended was present in Slime when I Bob |
great! |
melisgl
pushed a commit
to melisgl/slime
that referenced
this issue
Feb 10, 2022
Spawning a pygmentize process every time a code block needs to be processed takes up a lot of time. It may take up to minutes to process a small blog. It is far more efficient to spawn one colorizing process and keep it running. One can then send code and receive colorized HTML via standard IO. This is the approach that this patch enables while keeping the old behavior as a default for the sake of backwards compatibility. Fixes slime#29 Fixes slime#30
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
bug imported from https://bugs.launchpad.net/slime/+bug/820649
When doing stream I/O over an SBCL socket, Slime should set
the serve-events property of the stream to NIL. The default is T.
I've included a patch that makes the change.
When serve-events is T, SBCL will queue data it cannot flush to
the stream, assuming that some code will later flush it using
the serve-events infrastructure. When a stream specifies NIL
for serve-events, SBCL will correctly flush all the data to the socket
before returning from force-output.
The text was updated successfully, but these errors were encountered: