[Openmcl-devel] New OpenMCL 0.14 binaries available

[Brendan Burns]

I'm getting the following error with the release binaries:

? (require "cocoa-application")
 > Error in process listener(1): value NIL is not of the expected type  
STRUCTURE.
 > While executing: CDB-GET
 > Type :POP to abort.
Type :? for other options.

ideas?

--brendan

On Tuesday, September 2, 2003, at 02:50 AM, Gary Byers wrote:

> New 0.14 binaries are available; there's a regular "release" web page  
> at
> <http://openmcl.clozure.com/Distributions/openmcl-release-0.14- 
> 030901.html>.
>
> I'd like to try to phase 0.14 in as the "official" branch; if anyone's
> aware of any reasons for not doing so, please let me (and/or this list)
> know of them.
>
> Thanks to Randall Beer for his work on a new Cocoa Bridge, which is
> included in this release (and used heavily in the Cocoa demo(s)).
>
> There seem to be some issues related to launching application bundles
> made via
>
> ? (require "COCOA-APPLICATION")
>
> under Panther prereleases.  (If it was permissable to discuss Panther
> prereleases publicly, we'd probably be talking about how the new
> caching performed by Launch Services is a little overzealous, but
> of course we can't say anything about that.  Yet.)
>
>
> Gary Byers
> gb at clozure.com
>
> **** Changes ****
> *** New Features: ***
>     * SAVE-APPLICATION now accepts :PREPEND-KERNEL and :MODE  
> arguments. (SAVE-
>       APPLICATION needs to be documented ...). The latter argument  
> specifies
>       the read/write/execute permissions to be given to the saved  
> image (in a
>       manner usable by the chmod system call.) The former argument  
> allows an
>       OpenMCL kernel (or practically anything else, I suppose) to be  
> prepended
>       to the resulting image; a kernel that has an image appended to it
>       will load that image in the absence of an explicit image-file  
> argument.
>       (SAVE-APPLICATION ... :PREPEND-KERNEL T ...) prepends the  
> currently
>       executing kernel to the image; any other non-nil value of the  
> :PREPEND-
>       KERNEL argument is interpreted as a pathname.
>       If a file to be "prepended" to a heap image appears to already  
> containe
>       an embedded heap image, that image is not included in the output.
>     * Hamilton Link's "opengl-ffi" example (which uses GLUT to display  
> a
>       graphic design in a window) has been conditionalized for OSX,  
> and has
>       been updated to run the GLUT event loop in a separate native  
> thread.
>     * The Cocoa IDE example (and the lisp<->ObjC infrastructure  
> underneath it)
>       has been redesigned and reimplemented; it exploits a new "Cocoa  
> Bridge"
>       contributed by Randall Beer, offers improved integration between  
> Cocoa
>       exceptions and CL's condition system, and is a little better  
> integrated
>       with OpenMCL's runtime system. There's even a (very) generic  
> application
>       icon. (If anyone with at least minimal design skills and some  
> free time
>       feels like creating a better-looking icon, it would be  
> appreciated.)
>       The demo IDE is still barely usable, but I think that it's a  
> little more
>       practical to work on improving it than it has been.
>     * Lisp processes are now STANDARD-OBJECTs; some of the functions  
> used to
>       access and manipulate processes are now generic. This -should-  
> all be
>       transparent, but one never knows ...)
>     * When given a path to a non-file device (e.g., "/dev/null"), the  
> OPEN
>       function now tries to return a stream that's not a FILE-STREAM.
> *** Bug Fixes: ***
>     * TRANSLATE-LOGICAL-PATHNAME had difficulty handling translations  
> involving
>       the root directory (#p"/").
>     * SLOT-EXISTS-P was completely broken.
>     * There were several bugs related to CLOS's treatment of FORWARD-
>       REFERENCED-CLASSES; perhaps the most severe of these was the  
> fact that
>       they couldn't be instantiated (there was a typo in the  
> ENSURE-CLASS-
>       USING-CLASS method for them.)
>     * Various flavors of FF-CALL didn't handle foreign functions whose  
> address
>       was passed as a MACPTR correctly.
>     * The kernel Makefile for Darwin now tries to infer the version of  
> GCC in
>       use, since some versions effectively invert the meaning of the
>       "-traditional-cpp" argument.
>     * There were some errors in some system call definitions for  
> Darwin (off_t
>       is signed).
>     * SAVE-APPLICATION wasn't accepting logical pathnames for its  
> output file.
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/cgi-bin/mailman/listinfo/openmcl-devel


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