macOS Threading and Applescript Studio

[BrettB]

Hi All,
So I have a large Applescript Studio project that has really evolved and has thus started to require some threading. In my application I have a Table View that will run through many functions and print the results. I figured how to do "On Idle" and this works ok, however I have two main issues...
- I still can only press buttons and see the response about 2-3 seconds later, this is probably because what occurs on idle is still pretty big.
- I have random hands once and a while, perhaps something is causing the application to never go idle about half way down my table view.

Does anyone have any tips to address these two issues? I really don't like the lag of idle, is there a better solution?

Thanks for the help!
Brett

 

[Krevnik]

If there is a bridge that you can use to access C or Obj-C, then maybe you could thread Applescript. I don't know of a way to do it in Applescript natively though.

It might be a good idea to start looking at moving this to Obj-C at some point if it is getting big and hitting performance issues as a result.

 

[larkost]

I am going to echo the same advice: it is probably time to look at another language for this. Trying to thread AppleScript is going to be a losing proposition. You could start mixing-and-matching, but unless you are doing a lot of AppleEvent calls to other executables, it would probably make more sense to port directly to Obj-C (or maybe Python if you really like interpreted languages).

 

[jamdr]

Applescript Studio is nice for the simplest of applications, but I found that even for purposes that Applescript should be well-suited for, ASS doesn't have the power to pull off. PyObjC (now built-in to OS X) is a very good alternative and shouldn't be too hard to learn if you are using Applescript now. It is much faster and has threads.

 

[larkost]

Careful about python and threads. Python is not truly threaded, and only simulates it. For the purpose here (separating the GUI code from the worker code) it works well enough, but trying to do things that truly need threads in Python is a recipe for a headache.

But since threading only came into the picture as a ways of making the GUI more responsive, that works well with the Python-Obj-C bridge.

 

[hhas]

Careful about python and threads. Python is not truly threaded, and only simulates it.

Python has real threads; it doesn't 'simulate' them. The problem is that the CPython interpreter contains a lot of global state, and global state isn't exactly conducive to thread-safety. Hence the evil Global Interpreter Lock to maintain that state's integrity by ensuring multiple threads can't access thread-unsafe portions of interpreter at the same time. It's adequate for most tasks, but it's a schlonky arrangement that imposes some limits on what threaded Python processes can do, e.g. they can't take advantage of multiple cores, and requires some extra care when writing C extensions if you don't want them to block.

+1 for PyObjC as a RAD alternative to ASS, with the caveats that Xcode's Python templates are unreliable junk (I recommend using IB + your Python editor of choice + py2app instead), and you will need a little familiarity with ObjC so that you can understand the Cocoa documentation (which assumes you're using ObjC) and translate it into PyObjC for yourself.

There are a number of sample PyObjC projects bundled with PyObjC/Apple's developer tools; pulling those apart may be a good starting point.

Here's a good series of articles:

http://lethain.com/entry/2008/aug/22/an-epic-introduction-to-pyobjc-and-cocoa/

The python-mac mailing list is a good place for Python/PyObjC questions:

http://mail.python.org/mailman/listinfo/pythonmac-sig