Figured out the last issue. SLIME was interacting with the image, and causing stderr (I presume) to get all messed up. I built the App within slime and then launched it from the Terminal. Turns out this is not a good idea...<div>
<br></div><div>If you build the app from Terminal and then launch it from Terminal (or double click), everything works.</div><div><br></div><div>So if anyone else wants an image that can be launched from the command line, that has Cocoa loaded, that has the Terminal REPL decoupled from the GUI REPL, and that allows command-line arguments (like -l) to be given on the command line, these steps worked for me:</div>
<div><br></div><div>[1] Patch the build-ide function in the GUI package in cocoa-ide/start.lisp. Comment out all but the first argument to save-application in that function.</div><div>[2] Launch CCL from the terminal, load the patched function, then execute (require :cocoa-application)</div>
<div>[3] Then you can run Clozure\ CL64.app/Contents/MacOS/dx86cl64 -e '(gui::start-cocoa-ide)' -l test.lisp -e '(quit)'</div><div><br><br><div class="gmail_quote">On Wed, Jun 12, 2013 at 10:34 PM, Clayton Stanley <span dir="ltr"><<a href="mailto:cstanley@cstanley.no-ip.biz" target="_blank">cstanley@cstanley.no-ip.biz</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Thanks for the hint to launch the executable within the built App.</div><div dir="ltr"><br></div><div dir="ltr">
This approach is almost working. </div><div dir="ltr"><br></div><div dir="ltr">Here's what I would like to be able to do:</div>
<div dir="ltr">./[path-to-executable] -l tests.lisp -e '(quit)'</div><div dir="ltr"><br></div><div dir="ltr">And have :cocoa already loaded in the image associated with that executable.</div><div dir="ltr"><br></div>
<div dir="ltr">Here is what I have:</div><div dir="ltr"><div dir="ltr">Clozure\ CL64.app/Contents/MacOS/dx86cl64 -e '(gui::start-cocoa-ide)' -l test.lisp -e '(quit)'</div><div dir="ltr"><br></div><div dir="ltr">
This works except that I do not get any feedback (i.e., the program freezes) if I cause lisp to throw an exception. Interesting thing is, if I just build a default :cocoa app (with require :cocoa-application), I still do not get any feedback if I cause lisp to throw an exception when typing in the GUI REPL. The whole program freezes when I do this. Is this issue reproducible on a machine other than mine? If I can fix this, then I have a working solution.</div>
<div><br></div><div>Here is how I got there:</div><div>Comment out all but the first argument in the save-application call in the build-ide function:</div><div><br></div><div><div>$ git df cocoa-ide/start.lisp</div><div>
diff --git a/cocoa-ide/start.lisp b/cocoa-ide/start.lisp</div>
<div>index 478d8d4..2e59715 100644</div><div>--- a/cocoa-ide/start.lisp</div><div>+++ b/cocoa-ide/start.lisp</div><div>@@ -147,9 +147,10 @@</div><div> (ccl:copy-file (ccl::kernel-path) kernel-file :if-exists :supersede </div>
<div> :preserve-attributes t)</div><div> (save-application image-file</div><div>- :application-class 'cocoa-ide</div><div>- #+windows-target #+windows-target</div>
<div>- :application-type :gui)))</div><div>+ ;:application-class 'cocoa-ide</div><div>+ ;#+windows-target #+windows-target</div><div>+ ;:application-type :gui</div>
<div>+ )))</div></div><div><br></div><div>This change ensures that the CCL Gui App Window doesn't automatically launch when running the executable. This is necessary because I would like to pass arguments (the -l in particular) when launching the executable. If the arguments to save-application are uncommented, I am not able to pass any arguments when launching the executable, which means that I cannot pass the important -l argument that loads the test file. </div>
<div><br></div><div>This change also decouples the terminal from the CCL GUI App listener (like it is with Slime), so that compiler warnings stdout, etc. go to the Terminal, and not the GUI App. This is important when running the tests, because I want all of that trace to persist after the CCL image closes. If it is placed on the GUI App's listener window, it disappears after running through the tests. If it's placed on the Terminal, I can redirect it to a file easily, or simply just scroll through the output after the tests run.</div>
<div><br></div><div>I'll be interested to see if anyone can reproduce the last issue I found. Simple test procedure:</div><div>[1] Launch CCL</div><div>[2] (require :cocoa-application)</div><div>[3] double click the new app</div>
<div>[4] type (lslslslslsls) in the listener</div><div>[5] does it hang?</div><div><br></div><div><br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 12, 2013 at 5:09 PM, Gary Byers <span dir="ltr"><<a href="mailto:gb@clozure.com" target="_blank">gb@clozure.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">You can run any bundled application from the command line via:<br>
<br>
$ /path/to/application.app/<u></u>Contents/MacOS/executable-name<br>
<br>
(e.g.,<br>
<br>
$ /path/to/ClozureCL\ 64.app/Contents/MacOS/dx86cl64<br>
<br>
)<br>
<br>
What happens in that case is very similar to what happens when you double-click<br>
on the application's icon; the primary difference is that the process-wide<br>
standard I/O fds remain attached to the terminal/shell buffer/whatever. I don't<br>
know if that actually helps you, because I don't really understand what you're<br>
trying to do; do you plan on having the application run an event loop, or do<br>
you plan on having it run your tests ?<br>
<br>
That may or may not be a fair question. Another such question: is what you're<br>
trying to do the sort of thing that could/should be done via AppleScript/Automator ?<br>
<br>
Whatever the answers to these questions, you may find it worthwhile to try<br>
to understand what happens when (REQUIRE "COCOA") is called and when a bundled<br>
CCL application starts up. (Just guessing clearly doesn't work ...)<div><br>
<br>
<br>
<br>
<br>
On Wed, 12 Jun 2013, Clayton Stanley wrote:<br>
<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
I am running a suite of testing code that uses Cocoa in CCL. To make sure each test is<br>
isolated from the others, I would like to launch a CCL instance for each test, which<br>
means I'll need to launch CCL about 15 times to run all tests.<br>
A (require :cocoa) call on my machine takes about 15 seconds to compile and load all<br>
Cocoa code. This is fine when running a development instance of CCL through Slime for<br>
an entire day, but is too slow when having to do this 15 times to run through the test<br>
suite (especially since the time required for most of the tests to run is less than a<br>
second; and I'd like to run the test suite more often than once a day).<br>
<br>
I would like a CCL .image file that has :cocoa loaded in it that I can launch from the<br></div>
command line when running the tests.?<div><br>
<br>
I tried commenting out (gui::start-cocoa-ide) in cocoa-ide/cocoa.lisp. Then (require<br>
:cocoa), then (save-application ...). The idea was to get all Cocoa lisp code compiled<br>
and loaded into the saved core. Then when launching the modified image, I'd type<br>
(gui::start-cocoa-ide), and the Cocoa window would quickly boot up. But this didn't<br>
work. The Cocoa window doesn't appear on my machine, and CCL becomes unresponsive<br>
after calling (gui::start-cocoa-ide).<br>
<br>
Any other ideas?<br>
<br>
I can't use the CCL App from the App Store or a double-clickable CCL GUI Application<br>
because I need to be able to launch the ccl image from the command line. This is so<br>
that I can run the test suite from the command line (so that it can be automated and<br>
incorporated into the build scripts), and also so that the workflow to run the test<br>
suite matches a Slime development workflow, where Slime is simply pointed to a lisp<br>
image (and not a GUI app) when booting up.<br>
<br>
Thanks for the help,<br>
-Clayton<br>
<br>
<br>
<br>
</div></blockquote>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>