[Openmcl-devel] Create a CCL image that can quickly load Cocoa using a command-line workflow

[Clayton Stanley]

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...

If you build the app from Terminal and then launch it from Terminal (or
double click), everything works.

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:

[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.
[2] Launch CCL from the terminal, load the patched function, then execute
(require :cocoa-application)
[3] Then you can run Clozure\ CL64.app/Contents/MacOS/dx86cl64 -e
'(gui::start-cocoa-ide)' -l test.lisp -e '(quit)'


On Wed, Jun 12, 2013 at 10:34 PM, Clayton Stanley <
cstanley at cstanley.no-ip.biz> wrote:

> Thanks for the hint to launch the executable within the built App.
>
> This approach is almost working.
>
> Here's what I would like to be able to do:
> ./[path-to-executable] -l tests.lisp -e '(quit)'
>
> And have :cocoa already loaded in the image associated with that
> executable.
>
> Here is what I have:
> Clozure\ CL64.app/Contents/MacOS/dx86cl64 -e '(gui::start-cocoa-ide)' -l
> test.lisp -e '(quit)'
>
> 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.
>
> Here is how I got there:
> Comment out all but the first argument in the save-application call in the
> build-ide function:
>
> $ git df cocoa-ide/start.lisp
> diff --git a/cocoa-ide/start.lisp b/cocoa-ide/start.lisp
> index 478d8d4..2e59715 100644
> --- a/cocoa-ide/start.lisp
> +++ b/cocoa-ide/start.lisp
> @@ -147,9 +147,10 @@
>      (ccl:copy-file (ccl::kernel-path) kernel-file :if-exists :supersede
>                     :preserve-attributes t)
>      (save-application image-file
> -                     :application-class 'cocoa-ide
> -                     #+windows-target #+windows-target
> -                     :application-type :gui)))
> +                     ;:application-class 'cocoa-ide
> +                     ;#+windows-target #+windows-target
> +                     ;:application-type :gui
> +                      )))
>
> 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.
>
> 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.
>
> I'll be interested to see if anyone can reproduce the last issue I found.
> Simple test procedure:
> [1] Launch CCL
> [2] (require :cocoa-application)
> [3] double click the new app
> [4] type (lslslslslsls) in the listener
> [5] does it hang?
>
>
>
> On Wed, Jun 12, 2013 at 5:09 PM, Gary Byers <gb at clozure.com> wrote:
>
>> You can run any bundled application from the command line via:
>>
>> $ /path/to/application.app/**Contents/MacOS/executable-name
>>
>> (e.g.,
>>
>> $ /path/to/ClozureCL\ 64.app/Contents/MacOS/dx86cl64
>>
>> )
>>
>> What happens in that case is very similar to what happens when you
>> double-click
>> on the application's icon; the primary difference is that the process-wide
>> standard I/O fds remain attached to the terminal/shell buffer/whatever.
>>  I don't
>> know if that actually helps you, because I don't really understand what
>> you're
>> trying to do; do you plan on having the application run an event loop, or
>> do
>> you plan on having it run your tests ?
>>
>> That may or may not be a fair question.  Another such question: is what
>> you're
>> trying to do the sort of thing that could/should be done via
>> AppleScript/Automator ?
>>
>> Whatever the answers to these questions, you may find it worthwhile to try
>> to understand what happens when (REQUIRE "COCOA") is called and when a
>> bundled
>> CCL application starts up.  (Just guessing clearly doesn't work ...)
>>
>>
>>
>>
>>
>> On Wed, 12 Jun 2013, Clayton Stanley wrote:
>>
>>  I am running a suite of testing code that uses Cocoa in CCL. To make
>>> sure each test is
>>> isolated from the others, I would like to launch a CCL instance for each
>>> test, which
>>> means I'll need to launch CCL about 15 times to run all tests.
>>> A (require :cocoa) call on my machine takes about 15 seconds to compile
>>> and load all
>>> Cocoa code. This is fine when running a development instance of CCL
>>> through Slime for
>>> an entire day, but is too slow when having to do this 15 times to run
>>> through the test
>>> suite (especially since the time required for most of the tests to run
>>> is less than a
>>> second; and I'd like to run the test suite more often than once a day).
>>>
>>> I would like a CCL .image file that has :cocoa loaded in it that I can
>>> launch from the
>>> command line when running the tests.?
>>>
>>>
>>> I tried commenting out (gui::start-cocoa-ide) in cocoa-ide/cocoa.lisp.
>>> Then (require
>>> :cocoa), then (save-application ...). The idea was to get all Cocoa lisp
>>> code compiled
>>> and loaded into the saved core. Then when launching the modified image,
>>> I'd type
>>> (gui::start-cocoa-ide), and the Cocoa window would quickly boot up. But
>>> this didn't
>>> work. The Cocoa window doesn't appear on my machine, and CCL becomes
>>> unresponsive
>>> after calling (gui::start-cocoa-ide).
>>>
>>> Any other ideas?
>>>
>>> I can't use the CCL App from the App Store or a double-clickable CCL GUI
>>> Application
>>> because I need to be able to launch the ccl image from the command line.
>>> This is so
>>> that I can run the test suite from the command line (so that it can be
>>> automated and
>>> incorporated into the build scripts), and also so that the workflow to
>>> run the test
>>> suite matches a Slime development workflow, where Slime is simply
>>> pointed to a lisp
>>> image (and not a GUI app) when booting up.
>>>
>>> Thanks for the help,
>>> -Clayton
>>>
>>>
>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20130612/4fc89f4d/attachment.htm>