I spent part of this morning chasing down a bug that’s bothered me all through Paperclip’s life-cycle. I kept thinking that the problem was with me. Perhaps I wasn’t utilizing Applescript correctly. I remained stymied as I couldn’t figure out anything that would resolve the issue. Well, I think I stumbled upon the problem today. I was about to take one more shot at it before I saw this. Apparently, Applescript is crash-prone when Cocoa’s Garbage Collection is turned on. I suspect that it also crashes when Garbage Collection is merely enabled. In any case, I turned it off and haven’t had a problem since.

The worst part of this is that it’s not a consistent crash. It happens whenever it feels like. I’ve run Paperclip for several days before a crash. Other times, Paperclip will run for a few minutes. It was impossible for me to reliable diagnose and resolve since I never if I had fixed it or not (for those times when Paperclip would run for a while).

In the end, Apple still hasn’t resolved this bug. Perhaps it’s fixed in Snow Leopard (10.6). In any case, I find it rather disheartening that Apple would release Leopard with a buggy bridge between Cocoa and Applescript. Imagine, every Cocoa app built with GC can and will crash during some Applescript operation at some point. How did that get based QA?

Apple updated their Applescript language guide. I did not see that one coming.

I saw this article on MacScripter. It describes using call method to access Cocoa objects and methods. Awesome. I don’t have a use for it offhand but I know I’ll use it in the future.

I just learned today that osascript (the command line Applescript interpreter) will print the result of the last statement made to stdout. This is good because it doesn’t like commands like display dialog (there’s no windowing system for the command line) or log (which seems to be a Script Editor-only thing). So, to print to stdout, you’d likely do something like the following:

property stdout : ""
on run(arg) -- As an aside, you can also pass args to applescripts using the `on run` handler
    (* Do stuff *)
    set stdout to stdout & "Stage 1 status: complete"

    (* Do more stuff *)
    if success then
        set stdout to stdout & return & "Stage 2 status: complete"
    else
        set stdout to stdout & return & "Stage 2 status: failed"
    end if
    stdout -- Will put stdout in result which will be written to the terminal
    -- Alternatively, you could write `set result to stdout`
end run

I’m planning on releasing some Python scripts that I’ve been working on later this week after I get some more testing done. I’m aware that many people are not familiar with Python or the command line so I thought I’d wrap it all up in an applescript application. Script Editor allows me to make script bundles that keep all of the files together. Unfortunately, do shell script does some funky things. I’ve got several versions of Python installed and running do shell script didn’t use the one that I preferred. I couldn’t hard code the path to my preferred Python because many users may have Python installed in a different place (either the default location, or using a package manager like Fink or MacPorts).

In a somewhat fortuitous result, the which command would return the path for my preferred Python installation. Now, in order to make sure that the preferred python is used, I do this in my scripts:

pythonpath = do shell script "which python"
do shell script pythonpath & " " & pathtoscript

So far, this has always used the python installation I expected.