openmcl (perhaps others) needs to add connection streams to a list to be periodically flushed so that output appears in emacs in a timely manner. I could redefine or advise create-connection and close-connection but I think it might make more sense to make these methods and then I can define :around methods to do what needs to be done. Or you could add a hook.
Or is there some better place to do this.
-Alan
Alan Ruttenberg alanralanr@comcast.net writes:
openmcl (perhaps others) needs to add connection streams to a list to be periodically flushed so that output appears in emacs in a timely manner. I could redefine or advise create-connection and close-connection but I think it might make more sense to make these methods and then I can define :around methods to do what needs to be done. Or you could add a hook.
Maybe the gray-streams code is the place for the hook? e.g. advising MAKE-FN-STREAMS and the close methods of those streams?
Luke Gorrie luke@bluetail.com writes:
Alan Ruttenberg alanralanr@comcast.net writes:
openmcl (perhaps others) needs to add connection streams to a list to be periodically flushed so that output appears in emacs in a timely manner.
Is that actually needed? We already flush *standard-output* before returning from a RPC. Have you a test case where the current scheme fails?
I could redefine or advise create-connection andclose-connection but I think it might make more sense to make these methods and then I can define :around methods to do what needs to be done. Or you could add a hook.
Maybe the gray-streams code is the place for the hook? e.g. advising MAKE-FN-STREAMS and the close methods of those streams?
It would probably be good if *standard-output* where line buffered. Line buffering isn't difficult to implement for the gray streams, just a bit inefficient. Things are more complicated for the dedicated output stream case. The simplest solution for CMUCL/SBCL would be a 'buffering' argument to accept-connection, where buffering is either :full, :line, or :none. Don't now how to do the equivalent in OpenMCL, though. Any ideas?
We could implement the line buffering for the dedicated output stream with gray stream wrappers, but that's not very elegant.
Helmut.
On Tue, 20 Jan 2004, Helmut Eller wrote:
Luke Gorrie luke@bluetail.com writes:
It would probably be good if *standard-output* where line buffered. Line buffering isn't difficult to implement for the gray streams, just a bit inefficient. Things are more complicated for the dedicated output stream case. The simplest solution for CMUCL/SBCL would be a 'buffering' argument to accept-connection, where buffering is either :full, :line, or :none. Don't now how to do the equivalent in OpenMCL, though. Any ideas?
We could implement the line buffering for the dedicated output stream with gray stream wrappers, but that's not very elegant.
All (instantiable) streams in OpenMCL are Gray streams, which means that they follow a certain protocol for how things like READ-CHAR and LISTEN and FORCE-OUTPUT are implemented. The Gray streams protocol says nothing about how streams are buffered; presumably, interesting subclasses of FUNDAMENTAL-STREAM do buffering in appropriate ways.
Following the stdio (full/line/none) buffering model for interactive streams never struck me as being particularly appropriate: it's less important that output be flushed on every line/character/whatever than that the user see it in a timely manner. OpenMCL arranges to periodically try to FORCE-OUTPUT on certain designated streams; this seems to do a good job of maintaining the illusion that they're unbuffered without requiring the buffering code to follow the stdio (or similar) model.
Unfortunately, the mechanism by which streams are designated for this periodic buffer-flushing is ad hoc: it's currently tied in to the code that creates OpenMCL's own listener threads and establishes *TERMINAL-IO* streams for them. It should probably be an option to stream-creation primitives (including socket- creation primitives), and I imagine that there's already an abstraction layer around those primitives in SWANK/SLIME.
Helmut.
slime-devel site list slime-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/slime-devel
-
Alan Ruttenberg -
Gary Byers -
Helmut Eller -
Luke Gorrie