---------- Forwarded message ----------
From:
Jean-Claude Beaudoin <jean.claude.beaudoin@gmail.com>
Date: Fri, Jul 1, 2011 at 10:01 PM
Subject: Re: [mkcl-devel] quiclisp
To: Robert Burghart <
jestersks@gmail.com>
Although coming from the same code set of ECL 9.6.2, MKCL and ECL should now be considered now more like close cousins than as twins. Just having MKCL as a clone of ECL, however cleaned-up, would have been pretty much pointless.
This said, a good first approximation to a MKCL port would be to simply do:
(push :ecl *features*)
and see how far it goes with such a masquerade. ;-)
But this will be less and less successful as time passes, mainly with what is in works for MKCL 1.1 (entirely revised OS runtime interface to make it fully support Unicode, C99-complete FFI, memory image dump/load).
Do I hear someone say documentation...
On Fri, Jul 1, 2011 at 1:22 PM, Robert Burghart
<jestersks@gmail.com> wrote:
Very interesting. I was trying quicklisp since it shares a common root with ECL which is supported.
On Fri, Jul 1, 2011 at 12:40 PM, Jean-Claude Beaudoin
<jean.claude.beaudoin@gmail.com> wrote:
On Thu, Jun 30, 2011 at 11:05 PM, Jean-Claude Beaudoin
<jean.claude.beaudoin@gmail.com> wrote:
This makes, in a multi-threaded SBCL, impossible to predict the value of:
(equal (truename #P"") (truename #P""))
It may return T most of the time but not always since the current working directory may have been changed by some other thread between the two "truename" calls.
After verification I have to add that the statement here above is partially inexact for SBCL. In fact, SBCL seems to ignore the process current working directory after sampling it on startup and relies entirely on *default-pathname-defaults* ever after. But SBCL keeps *default-pathname-defaults* a true global variable and if one is not careful to rebind it locally in its own thread then you get the same unpredictable behavior stated above but for a somewhat different reason