[Openmcl-devel] New OpenMCL 0.14 binaries (not visually compelling ...)

Gary Byers gb at clozure.com
Thu Aug 7 07:11:55 UTC 2003


New OpenMCL binaries (0.14-030806) are available in the testing directory
on clozure.com (<ftp://clozure.com/pub/testing/>).

I'm afraid that the "more visually compelling changes" suggested in the
last release notes will have to wait a bit longer; the changes in this
release don't really fall into the visually compelling category.

Bug fixes:

 - A few hours after the last binaries were released, I noticed that
   compiler-macros for REMOVE-IF and REMOVE-IF-NOT were still saying
   "... &rest nil ..." in their lambda lists.

 - The symbol ENSURE-GENERIC-FUNCTION was inadvertently exported from
   the OPENMCL-MOP package, shadowing the (presumably more interesting)
   symbol of the same name from the CL package.

 - The code which handles unbound slot references now uses the value
   returned by a specialized SLOT-UNBOUND method.

 - Setting a readtable's READTABLE-CASE to :INVERT now correctly handles
   mixed-case tokens (thanks to Thomas Russ)

 - The TIME macro doesn't doubly count memory freed by the GC.

 - The :DOCUMENTATION initialization arg to DEFGENERIC and to procedural
   attempts to instantiate a generic function now works, at least in the
   cases where the initarg is provided.  (Thanks to Ram Krishnan.)

Changes:

 - Code is compiled with support for embedded debugging symbols (aka
   "traceback tables"), which some diagnostic and profiling tools
   (at least some versions of those tools) can utilize.  (This is
   admittedly an experiment: until there's a bit more integration
   of OpenMCL with those tools, the most obvious impact of this
   change is further code bloat.)

 - There were some substantial changes to some parts of the process/thread
   API; these are documented in greater detail in "ccl:doc;HTML;threads.html".
   Code that tries to maintain "thread pools" via PROCESS-RESET/PROCESS-PRESET/
   PROCESS-ENABLE should now work much more reliably; since it wasn't at all
   reliable in previous 0.14 releases, any improvement would be much more
   reliable.

   I -didn't- try recompiling the modified version of the PortableAserve
   demo after making those changes; the current demo's based on a very old
   version of paserve and contains at least one attempt to work around
   a very old OpenMCL bug that CERRORs when attempting to redefine a
   builtin function.  I'll try to update the paserve demo soon

 - Writing short simple strings to file-descriptor based streams should be a
   bit faster (writing long strings should also be faster, but the difference
   should be more pronounced the shorter the strings are.)  There's some
   overhead that's just inherent in the Gray streams protocol here,
   but the case where the string is simple and START/END arguments default
   seems most common and most worth trying to optimize.

 - The whole awkward mechanism for sharing the terminal input stream
   probably needs to be re-thought, but it should work the way it's
   supposed to in at least a few more cases.  It still doesn't work
   entirely reliably.  (Thanks to Eric Marsden for pointing out that
   "background-terminal-input.html" wasn't linked to from the documentation
   index page.)

 - The previously undefined function CCL::KILL-LISP-THREAD is now defined
   (leaving one undefined-function-call warning in the build process.)  It's
   used to abruptly terminate threads that have not responded to more
   polite requests to terminate themselves.

Other issues:

 - Using OPEN to open a Unix device (like "/dev/null" or "/dev/zero" or
   "/dev/tty") sort-of half works: the resulting stream thinks that it's
   a FILE-STREAM, but doesn't behave like one and may fail some internal
   consistency checks.  It'd be convenient if OPEN continued to accept
   non file pathnames, but recognized them as such and made streams of
   a more appropriate class.


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



More information about the Openmcl-devel mailing list