Hmm. It now appears that even the demo code won't run after being run from the Editor once. I swear it did in the past.
The bindings for *standard-input* and *standard-output* are indeed different depending on where the form is evaluated, but they are both instances of the same class:RUBBER-STREAM. I guess it makes sense that they would be different since they're going to different output-panes. If I wait around a couple of minutes, the Gtk window will come up, but will refuse to close and GNOME will tell me that it's not responding. I haven't had a lot of time to look at this the last few days, but maybe tonight I'll rummage through the innards of cells-gtk and try to figure out what's going on. This is too weird to just let it go. (BTW, cells and cells-gtk are pure glory. Thanks, Ken and Vasilis). On 8/14/06, Ken Tilton <[EMAIL PROTECTED]> wrote:
On 8/14/06, Bill Atkins <[EMAIL PROTECTED]> wrote: > Nope, I'm running from the LispWorks IDE. I'm getting by with SBCL > and SLIME at the moment, but I'd prefer to be back in LW. Not sure > what else to try. Wild guess: Have you looked at the runtime bindings of various special variables dedicated to input/output? Working with a different Lisp altogether and having similar REPL-OK, other-not issues, the folks at tech support ended up explaining that the IDE did cute things in re stuff like *standard-input*. But I am especially fascinated that the gtk-demo does not have this problem. I guess whatever difference the IDE creates running from there (such as the thread thing or some special binding) is not touched by gtk-demo code but is by yours. But did you call up all the different tabs? I would look especially at any difference in how the demo and my windows closed (I mean, the code that runs at close time) in the event that the issue is how gracefully one exits. hth, kt
-- Bill Atkins _______________________________________________ cells-gtk-devel site list [email protected] http://common-lisp.net/mailman/listinfo/cells-gtk-devel
