MKCL 1.0.1 is a bug fix release in the 1.0 series. It corrects a number of
bugs, mostly in the area of CLOS class shared slots and unusual pathnames
(like #P"...").
Enjoy,
Jean-Claude Beaudoin
---------- Forwarded message ----------
From: Jean-Claude Beaudoin <jean.claude.beaudoin(a)gmail.com>
Date: Fri, Jul 1, 2011 at 10:01 PM
Subject: Re: [mkcl-devel] quiclisp
To: Robert Burghart <jestersks(a)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(a)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(a)gmail.com> wrote:
>
>>
>>
>> On Thu, Jun 30, 2011 at 11:05 PM, Jean-Claude Beaudoin <
>> jean.claude.beaudoin(a)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
>>
>>
>>>
>>>
>>
>>>> _______________________________________________
>>>> mkcl-devel mailing list
>>>> mkcl-devel(a)common-lisp.net
>>>> http://lists.common-lisp.net/cgi-bin/mailman/listinfo/mkcl-devel
>>>>
>>>>
>>>
>>
>
On Windows XP SP3 I tried to load quicklisp.lisp using mkcl an it errors out
near the bottom of the file at:
(setf *default-pathname-defaults* (truename *default-pathname-defaults*))
Apparently *default-pathname-defaults* defaults to "". Is that
intentional? From the hyperspec it says that it's implementation dependent
but that many will store the path where the repl was started in.
