On Jun 2, 2009, at 1:35 PM, Helmut Eller wrote:
- mikel evins [2009-06-02 17:31+0200] writes:
Doubtless this is because we don't properly understand what swank is doing with the streams. I frankly don't know how to frame an intelligent question on this subject, because I don't know enough about what swank is trying to accomplish and how it's going about it.
Basically SWANK installs a custom stream in *STANDARD-OUTPUT* and that stream forwards any output to the slime-repl Emacs buffer. We usually do this with dynamic bindings like
(let ((*standard-output* <custom-stream>) (*standard-input* <custom-stream>) (*debug-io* <custom-stream>) (*query-io* <custom-stream>) (*terminal-io* <custom-stream>)) ...)before evaluating code that (potentially) generates output. We actually use PROGV but that's a minor detail.
A more problematic feature is "global IO redirection". This installs our stream as the truly global value for *STANDARD-OUTPUT* etc. and also as the default value for new threads. The reason to do such a global thing at all is the desire to redirect the output of threads created by a HTTP server, or generally threads that are not created by us. Global IO redirection is not enabled by default.
So, what questions should I ask? My goal is to ensure that CCL controls the standard streams in a way it can rely on, while still allowing a swank server to be created and run.
With *globally-redirect-io* enabled you're probably out of luck because we take over control. As often in CL, this could be solved by some convention but there is no established convention.
If you guys would help me zero in on the right questions to ask you about swank's operation, I'd appreciate it.
Maybe you could think about the HTTP server example and where debug output of worker threads should go and how to control that.
The problem at present is that loading and running swank is a way to destabilize CCL's Cocoa IDE.
The Cocoa IDE relies on a socket connection to an external process for certain critical situations. For example, a bug in a Cocoa event- handler can cause a Cocoa app written in CCL to become unresponsive: no events are being processed, because the event-handling thread is blocked on a break loop. CCL solves this problem by presenting the break loop in a separate application process (presently a dumb glass TTY in a Cocoa window).
It appears that loading and running swank can cause this connection to become unreliable, apparently by shuffling streams underneath us. One solution, favored by some users, is "don't load swank." Some of us are SLIME users, though. We'd rather figure out how to make swank coexist peacefully with the rest of the Cocoa CCL environment. In fact, those of us who are SLIME users would prefer to further extend SLIME and swank, for example, to arrange for the event-thread error handlers to be able to pop open a buffer in which we can present the break-loop UI. However, speculating about any such feature extensions is premature until we can guarantee the integrity of lower-level required features that must work correctly whether or not swank and SLIME are present.
When the CCL Cocoa app starts up, it also starts its glass TTY process, AltConsole. It creates a socket pair, connecting AltConsole's standard output, standard input, and standard error to one end of the socket, and CCL's *TERMINAL-IO* to the other end. We require the ability to guarantee the integrity of those stream connections. Is there a way to guarantee that integrity when swank is loaded and a server created? I'm perfectly willing to change CCL code or swank code to accomplish it, if need be. One way or another, though, that integrity is a requirement at our end.
--me