Chris Van Dusen
cavandusen at gmail.com
Mon Mar 29 08:39:20 PDT 2010
Thanks for the explanation. And thanks to Tobias for the quick fix.
Given the fix, would it be not unreasonable to revert the change to
*print-readably* in CCL?
On Mon, Mar 29, 2010 at 9:14 AM, Sudhir Shenoy <sshenoy at gol.com> wrote:
> The specific problem with SLIME is that if *print-readably* is true, then
> the communication between Emacs and the Swank server in the repl thread
> throws an error during initialization. This is because in the process of
> setting up a connection, the character encoding needs to be specified and
> when this encoding spec is written to the connection stream, it cannot be
> written "readably" and an error is thrown by prin1.
> So SLIME is expecting a certain behaviour (*print-readbly* being false) in
> a newly spawned thread. Whether this expectation is correct or not, I have
> no idea but I presume it is reasonable as Gary stated in his earlier email.
> There is a mechanism in SLIME (currently unused) to bind variables prior to
> thread creation so one could conceivably bind *print-readably* to nil prior
> to a new worker thread being spawned if the CL implementation was setting it
> to t (it wouldn't affect any other CL implementation either). However, I
> thought this was a simple mistake (CCL behaviour changed and I hadn't read
> the spec on with-standard-io-syntax at that point) which is why I asked the
> On Mar 29, 2010, at 9:02 PM, Chris Van Dusen wrote:
> > Me neither...
> > My question is where the problem lies when *print-readably* is t, SLIME,
> CCL, Spec?
> > There's much to be said for something being a good thing (despite not
> being a Good Idea), and I what would like to understand that aspect rather
> than the default/standard/special rabbit hole aspect.
> > Thanks,
> > Chris.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openmcl-devel