[Openmcl-devel] level-1/l1-boot-2.lisp

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?

Thanks again,

On Mon, Mar 29, 2010 at 9:14 AM, Sudhir Shenoy <sshenoy at gol.com> wrote:

> Chris,
> 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
> question.
> Cheers
> Sudhir
> 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...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20100329/678bc702/attachment.htm>

More information about the Openmcl-devel mailing list