[mkcl-devel] Fwd: quiclisp

[Jean-Claude Beaudoin]

---------- Forwarded message ----------
From: Jean-Claude Beaudoin <jean.claude.beaudoin at gmail.com>
Date: Fri, Jul 1, 2011 at 10:01 PM
Subject: Re: [mkcl-devel] quiclisp
To: Robert Burghart <jestersks at 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 at 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 at gmail.com> wrote:
>
>>
>>
>> On Thu, Jun 30, 2011 at 11:05 PM, Jean-Claude Beaudoin <
>> jean.claude.beaudoin at 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 at common-lisp.net
>>>> http://lists.common-lisp.net/cgi-bin/mailman/listinfo/mkcl-devel
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/mkcl-devel/attachments/20110701/fcd2b92b/attachment.html>