[Openmcl-devel] Problem with Cocoa IDE
gb at clozure.com
Sat Feb 22 16:06:57 EST 2003
On Sat, 22 Feb 2003, Rod Schmidt wrote:
> I went through the process to build the Cocoa IDE. It ran right after I
> did (require "cocoa-application"), but after that whenever I
> double-click on OpenMCL.app the following shows up in the console:
I just tried this, following the instructions in the comments in
"cocoa-application.lisp"; it seemed to work fine.
What should happen when you do (require "COCOA-APPLICATION") is:
a) after a few seconds, a menubar will be drawn and a Cocoa listener
will appear. You may have to activate a generic "OpenMCL" icon in
the OSX dock to see this.
b) in the original listener, you'll get a break loop advising you
to close any open Cocoa Listeners. (It'd be nice if it just did this
for you, and even nicer if this step wasn't necessary.)
Close the Cocoa listener(s), then proceeed from the break loop (via the
c) After the break loop exits, SAVE-APPLICATION will be called to save
a new heap image to "ccl:OpenMCL.app;Contents;MacOS;dppccl.image".
That application will have its application class changed to one which
ignores any command-line arguments it receives. (When a GUI
application is launched from the finder or via the shell "open"
command, it recevies a single argument of the form -pns_x_y, which
isn't particularly interesting.)
d) At this point, it's necessary to copy the lisp kernel from the
"ccl:" directory to "ccl:OpenMCL.app;Contents;MacOS;", so that it's
alongside the "dppccl.image" that was just created. That directory
should then contain both "dppcl" and "dppccl.image" (and possibly a
CVS directory as well, though that isn't very interesting either.)
Again, there's no good reason why this couldn't be done automatically.
If you get
> Unknown option: -psn_0_7340033
followed by a usage message, it sounds like the image that's being
launched is (a copy of ?) the regular dppccl.image, which expects
to receive command line arguments and doesn't know anything about
That's about what would happen if you just copied ccl:dppccl and
ccl:dppccl.image into the application bundle directory and tried
to launch the application.
> usage: /Applications/ccl/OpenMCL.app/Contents/MacOS/dppccl <options>
> or /Applications/ccl/OpenMCL.app/Contents/MacOS/dppccl <image-name>
> where <options> are one or more of:
> -h, --help : this text
> -n, --no-init : suppress loading of init file
> -e, --eval : evaluate <form> (may need to quote <form> in shell)
> -l, --load : load <file>
> -T, --set-lisp-heap-gc-threshold : set lisp-heap-gc-threshold
> to <n>
> -R, --heap-reserve <n>: reserve <n> (default: 1073741824)
> bytes for heap expansion
> -S, --stack-size <n>: set size of initial stacks to <n> (default:
> -b, --batch: exit when EOF on *STANDARD-INPUT*
> --no-sigtrap : obscure option for running under GDB
> -I, --image-name <image-name>
> and <image-name> defaults to
> Anybody know what's wrong?
Since you now have a kernel (dppccl) inside the
"ccl:OpenMCL.app;Contents;MacOS;" directory, you should be able to
run the lisp (using the regular kernel and heap image) from the shell,
do (require "COCOA-APPLICATION"), close the Cocoa Listener at the
break loop and proceed from the break loop.
The "ccl:OpenMCL.app;Contents;MacOS;" directory should then contain
a dppccl.image file that's larger and newer than the one in your
"ccl:" directory, and should contain a dppccl that's identical to
the one in your "ccl:" directory.
Launching the application should then run the kernel inside the
application bundle, which should load the heap image from the same
directory, which should start the Cocoa IDE without doing any sort
of command-line argument processing.
> Rod Schmidt
Openmcl-devel mailing list
Openmcl-devel at clozure.com
More information about the Openmcl-devel