mkcl-devel July 2011

mkcl-devel@common-lisp.net

2 participants
3 discussions

[mkcl-devel] MKCL 1.0.1 is out.
by Jean-Claude Beaudoin 22 Jul '11

22 Jul '11

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

1 0

[mkcl-devel] Fwd: quiclisp
by Jean-Claude Beaudoin 02 Jul '11

02 Jul '11

---------- 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 >>>> >>>> >>> >> >

1 0

[mkcl-devel] quiclisp
by Robert Burghart 01 Jul '11

01 Jul '11

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.

2 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

mkcl-devel July 2011