[Openmcl-devel] trunk changes

Gary Byers gb at clozure.com
Mon Oct 1 03:20:33 PDT 2012


In a few minutes, I'll (hopefully) check in a fairly extensive set of
CCL kernel changes that're intended to help shield CCL from future
changes to OSX's Mach layer.  This has been tested (mostly) on OSX
10.6; other platforms and other OSX versions aren't supposed to be
affected, but the easiest way to verify that in practice is to check
in some changes and see what breaks.

We have (and have had for a few years) an automated build system that
rme set up.  Whenever anything is committed to the CCL trunk, that
system does an svn update and REBUILD-CCL on all supported platforms
(and runs a fairly extensive test suite on most platforms).  If any
part of this process fails, we find out about it fairly quickly
(modulo nap time ...) and if the process succeeds, we can have some
confidence that the changes at least didn't contain typos/brainos that
would be caught by that.  You can see the current build status at:

<http://clozure.com:8010/waterfall>

If the column(s) corresponding to platform(s) of interest to you don't
indicate that the most recent automated build was successful, then it's
probably advisable to check back a little later to see if that changes.
If you experience problems that the automated build system doesn't, that'd
be interesting.

CCL has used Mach-level exception handling on Darwin for the last 10
years or so because the versions of GDB that Apple distributes have
never worked with other exception handling mechanisms (POSIX signals.)
In the near future (once we resolve some code-signing and distribution
issues) we'll make a slightly modified version of GDB available and
it'll be necessary to use that modified version (or equivalent) to
debug CCL at the kernel level.  If you do that - and I assume that few
people do so on a regular basis - you might want to wait until that
modified GDB is available before updating.

The changes to how the CCL kernel does exception handling are supposed
to be entirely transparent to lisp code, so hopefully anyone who
updates their trunk sources will find doing so to be extremely
anticlimactic.  Hopefully, CCL will not be affected by whatever is
broken ("deprecated with extreme prejudice") in/by the next OSX
release, so the lack of drama could prove to be a good thing.




More information about the Openmcl-devel mailing list