[Openmcl-devel] new 0.14 binaries (finally!)

[Gary Byers]

There are (finally) new 0.14 binaries in the testing directory:

<ftp://clozure.com/pub/testing/>
<http://openmcl.clozure.com/FTP/testing/>
<http://www.clozure.com/openmcl/ftp/>

There's also a source archive in the testing directory.  (It contains
CVS metainformation, so hopefully doing "cvs update" - possibly after
a "cvs login" - from the "ccl" directory in that archive will work.)

The HTML documentation is included in the binary archives.  The
documentation source (in LyX format) is now in a separate CVS
module ("ccldoc").

To review:

 - 0.14 isn't binary compatible with 0.13; you presumably want to
   maintain separate "ccl" hierarchies for 0.14 and earlier versions.
 - 0.14 on OSX depends on functionality introduced in 10.2 (Jaguar).
 - Building 0.14 from source on OSX requires Jaguar-specific interface
   files (look for the most recent "jaguar-interfaces*.tar.gz" archive
   in the testing directory.)


-----------------------------------------------------------------------
OpenMCL 0.14-030623 Release Notes

 General

First of all: I'm sorry that it's been so long (over a
month) between "stable" (i.e., buildable-from-CVS) 0.14
releases. It's not a good thing if I'm the only person
who's able to run a recent version of 0.14 and that's
been the case since mid-May; I quite honestly expected
to reach a relatively stable point a lot sooner than
this. I'm not sure exactly how, but I'll try to keep
things from getting as badly out of synch with the next
set of low-level changes.

FASL files produced by earlier versions of 0.14 won't
load into the current version (and vice versa.)

There is some good new here; perhaps most notably,
OpenMCL 0.14 now (at least nominally) supports a large
subset of the MOP. ("Nominally" in this case means that
the functionality's there and has been exercised to
some degree, and that deviations from what the MOP
document specifies should be considered bugs.) The
parts of the MOP that're currently unsupported
primarily deal with the generic function invocation
protocol (section 5.5.5 in the AMOP book); it seems
wise to think carefully about various tradeoffs before
deciding how to proceed in this direction.

Euphemistally, there are "lots of opportunities for
performance improvements" in the current CLOS/MOP
implementation. Some of those opportunities have
existed for a long time (SLOT-VALUE has never been very
fast in MCL/OpenMCL, and adding a generic function call
to SLOT-VALUE-USING-CLASS didn't speed it up any) and
others are newly introduced (there's more type- and
bounds-checking going on internally; that extra
paranoia isn't necessary in theory but in practice
helped to catch a lot of bugs before they were able to
-really- foul things up.) I'm fairly confident in
saying that things won't get worse performance-wise
than they currently are, and fairly confident in saying
that they'll get better soon.

There's some documentation on the MOP support in the "mop.html"
 file (available on the website and in the "ccl;doc;HTML;"
 directory in the binary distributions. Aside from a
checklist showing what's implemented and what isn't
(and some other details), there's a paragraph or two on
CLOS/MOP concurrency issues. It made sense when I wrote
it, but it perhaps doesn't say things quite as clearly
as it might. The short version is that weird things can
happen when threads modify CLOS data structures that
other threads are accessing, the implementation doesn't
yet do as much as it could to minimize this wierdness,
and there may be some limits on what the implementation
-can- do to minimize it. I'll try to think about that
harder and clarify what the implementation can do to
ensure some level of consistency (and what issues
applications that redefine CLOS classes and generic
functions at runtime must deal with.)

Some other recent changes include:

* it should now be possible to call lisp code from
  (native) threads that weren't created by lisp. On the
  first such callback, the foreign thread will be
  connected to the lisp runtime system and lisp stacks
  and other data structures (including a lisp process
  with default attributes) will be associated with the
  thread; all of this should be cleaned up
  automatically when the native thread exits.

* The ephemeral garbage collector still doesn't work.
  The good news is that there's now a plan that should
  allow the EGC to work well with native threads and to
  reduce some pervasive EGC-related costs. That
  cost-reduction has already taken place: the compiler
  has a couple of more (previously dedicated) registers
  available to it, and the background-noise associated
  with maintaining the EGC write-barrier is now gone.

* PROCESS-INTERRUPT requests that occur during
  exception handling are now handled when the exception
  handler exits (they'd been silently ignored, which
  made it hard to interrupt programs that were consing
  hysterically or otherwise generating very frequent exceptions.)

* It should now be possible to continue from
  UNDEFINED-FUNCTION-CALL errors again.

* MACPTRs now have a couple of extra fields, intended
  to make it easier to cache foreign type information.
  Hopefully, two extra fields will be enough to enable
  us to recognize that the CLASS-OF some MACPTRs might
  be something like #<OBJC-CLASS NS-WINDOW>.

* The partial integration of the lisp condition system
  and the ObjC exception system that I mentioned on
  openmcl-devel several weeks ago is ... still partial.
  The good news is that the runtime support that this
  depends on is in the current binaries.

* Standard instances and generic-functions each wound
  up with an otherwise unused word; in both cases, the
  code invoked by ALLOCATE-INSTANCE fills that word
  with a more-or-less random fixnum that can be used as
  a hash key. (A few months ago, I was delusionally
  trying to get rid of all address-based hashing;
  having sobered up, it still seems clear that avoiding
  address-based hashing when possible is a good thing.)

* several bug fixes, most of them far too gruesome to
  discuss in detail ...

 Some known bugs/problems

* I think that I'm ready to admit that there has to be
  some better solution to the "shared terminal input"
  problem than what OpenMCL implements. This becomes
  very obvious when something goes wrong when the lisp
  is quitting: one sees a message to the effect that
  the initial process needs access to terminal input,
  but there's no longer a listener to type (:y 0) to ...

* There are undoubtedly still bugs in the thread code
  (missing locking, etc.) and there are likely to be
  newly-introduced bugs in CLOS and the MOP. Any help
  in finding these would be greatly appreciated; any
  suggestions for making it easier to test/use 0.14
  would also be greatly appreciated.

_______________________________________________
Openmcl-devel mailing list
Openmcl-devel at clozure.com
http://clozure.com/cgi-bin/mailman/listinfo/openmcl-devel