sshenoy at gol.com
Mon Mar 29 07:14:22 PDT 2010
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.
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.
More information about the Openmcl-devel