Awesome, that’s good to know.
So what are the drawbacks of .AppleScript format then (apart from it not automatically updating the name of an app or piping conflicted terminology etc)? I’d imagine there must be some otherwise it would presumably be the default.
Also, @ShaneStanley, does SD8’s feature of saving script bundles in version control friendly format apply to applets (e.g. enhanced applets) as well?
When you attempt to run such a script, the host has to load any referenced dictionaries and compile the script first, which can add some overhead.
It also doesn’t cope with terminology changes, although they’re pretty rare.
And the Script Debugger-related metadata (how the document is set-up) is inherently more fragile than in bundled formats.
No. They wouldn’t function if it did.
Hello @AppleScripter
You asked whether Keyboard Maestro could handle non comiled AppleScript files (.applescript Extension) …
I didn’t do that until now but maybe there could be a way if you do something like this:
use the Set Variable to Text Action with the Script File’s Path as Value
Check for File on the Disk with a If Then Else Action
use the Execute Shell Script Action with input from Variable as its setting and the Token of the File Variable you created and its Output as a Variable
Check for the temporary created compiled Script File using If Then Else
Use Execute AppleScript Action with “from File” setting and the Variable you defined as Shell Script result.
Just one thing … This is how I would do it because KM handles Compiled Scripts faster than Uncompiled Scripts.
Another thing to mention here is to think of course of Scripts whose have to store persistent Values. For them it would be better to have them as Compiled Script Files - otherwise they would not have the ability to store the Values.
Greetings from Germany
Tobias
Keyboard Maestro’s Execute an AppleScript action can run *.applescript files. No workaround needed (unless I missunderstood the goal).
In my situation, basically none of the drawbacks to .applescript apply except for its inability to contain associated resources. That’s because we have a separation between deployed code that’s run, and development code in git. All our deployed code is deployed by script, and it’s deployed as run-only .app or .scpt. Things like retaining deployment preferences aren’t relevant because they’re set by the deployment script on export.
Even for more local use, I recommend a deployment script and storing the editing code separately from the deployed code, it provides a great deal of control, and means you don’t need to find “one file format to rule them all” for development and running scripts. I just have a key command for saving that runs my deployment script, which both saves the local copy and a new deployed copy with the bundle ID, code signing, the proper file type, and anything else we need.
Hello @Pete ,
Even if I missed somewhat on Information on how the Execute AppleScript Action of KM works - and can read and compile .applescript Files I think my Idea of making this work is better because of the fact that you provide a compiled Script to the Execute AppleScript Action which will be somewhat like more less work for KM-Engine because you use osacompile from the OS to compile the Script before it gets executed.
It can be very Handy If you have for Example a Macro that calls somewhat like 10 or more AppleScripts. It runs faster because you compile the Scripts all at once before they get called in the Macro. Otherwise they would have to get compiled at run time by KM-Engine what can cause a slow down for the Engine depending on how many Macros like this are executed at the same Time - if I remember it right.
Greetings from Germany
Tobias
There’s no need to „manually“ provide a compiled script as Keyboard Maestro compiles *.applescript automatically (and I guess it does this faster than doing it „manually“). So for most users this is the far easier way to use *.applescript files in Keyboard Maestro.
I don’t understand that. Could you post a capture of a example macro?
Hello @Pete,
Yes - maybe you are right when you say that .applescript Files will get compiled automatically and they get compiled fast… but since these Files are just Plaintext Files you could also use the Execute AppleScript Action with the “as Text” Setting and paste your AppleScript code in the Action.
Keyboard Maestro compiles your Script temporarily if the Syntax is right but this remains only for the Time of displaying the Macro which contains the Script.
It is Plaintext. Nothing else.
The Engine needs to read the Plaintext Script then it passes the text into the osacompile comand and then it executes the script - after that there is no “compiled” form of your code. This is the same procedure with every Script File whose extension is .applescript and even with every Text Script in the Action it self - no matter how many Scripts are used in your Macro.
I have mentioned it today that Compiled Scripts run faster in KM - The Engine just executes the file.
This is why I think that it is better to compile them to temporary Files with their .scpt Extension before executing. If you Need to execute the same Macro several Times and the comiled Scripts haven’t been replaced by others they would only be executed.
I thought this would be clear.
You could even store the temporary compiled Script Files in a Sub Folder automatiacally named with the UUID of the Macro they are belonging to - If you do this the Scripts will never be replaced and you can execute all Macros whose contain one or more Scripts multiple Times all day long - The Scripts of a Macro only get comiled once and are kept until the temp Folder gets cleared out - when you log out of your User account for example.
I hope that you now fully understand my approach.
Greetings from Germany.
Tobias
Are there any drawbacks to developing in .AppleScript format? I presume you use Script Debugger?
Your workflow makes a lot of sense, @tspoon, it would just be a bunch of work to get that deployment script working. I had developed my own applet to export new builds, notarise them, create disk images for distribution, create a blog post with the release notes and an email announcing the new version, but it was flaky particularly at the disk image creation section. Now that SD supports direct export and SD Notary has made some improvements, and I’m now using Drop DMG with SD Notary, I’ve found that using the built-in solutions is good enough that I don’t have to bother with my somewhat flaky automation.
So I guess what I’m trying to grapple with is whether I’m better off developing that kind of deployment workflow so I can develop in .AppleScript format, or to just save things in git as binaries, or to use osagitfilter. I suspect that osagitfilter will be the simplest solution, but I’m a little hesitant to install something like that when I don’t entirely understand how it works and I haven’t heard from a ton of people that use it.
Sorry for all the questions and thanks for all the feedback as one way or another I really need to keep a better record of the various versions of my code.
That’s what I did when I started to use Keyboard Maestro. Meanwhile I’ve switched to *.applescript files because
Yes, I understand that a KM macro runs pre-compiled scripts faster. I just wasn’t sure what you were talking about, as you wrote …
… which I understood as 1 macro that got 10 or more AppleScript actions. But you meant 1 macro that’s called 10 times. It’s clear now, thanks!
Interesting idea!
Hello @Pete ,
no the otherway … You got what I was talking about but you put it in the opposite way… I meant 1 macro with 10 or more Scripts …
I’ve totally forgotten to give this answer of mine a better understanding.
This Idea came to me while I was writing my last answer. I am Glad that you like this Idea.
Greetings from Germany
Tobias
It’s just out. We’d be grateful for any feedback on how it works for you.
Thanks! I’m traveling, but I’ll get on it on Monday.
So I’ve now done some testing/playing around and I think for my applet projects I’ll just put the .app/.scpt binaries in git and potentially look at using osagitfilter at some point. With detailed commit messages it seems to work well enough. If I put some of my simple scripts into git that don’t use resources I might use .AppleScript format.
Is there anything I should put in my .gitignore file when using Script Debugger enhanced applets?
One other major issue. Most of my applets heavily use my own libraries. I save the development copy of the libraries in ~/Library/Script Libraries/ and often develop them in tandem with the applet, and Script Debugger helpfully includes the latest version of the library when exporting a run-only version.
What’s the best way to get those libraries into git?
Turning ~/Library/Script Libraries/ into a git repo seems like a bad idea for many reasons.
Could I place the library into my git repo somewhere else on my Mac and then include an alias in ~/Library/Script Libraries/?
Yes, that’s what we do. We actually have shared libraries for multiple users. ~/Library/Script Libraries/ is a symlink for us that points to a Dropbox folder. Inside our GIT repository is a directory called “Script Libraries.” Our library code lives in there, and the deployment script checks there the code it’s deploying lives, and if it’s inside the “[git]/Script Libraries” folder, then it deploys it to our symlinked “Script Libraries” folder.
The only thing I put in .gitignore is *.ds_store
Is the nature of the fix that it changes things when saving, when opening, both… ?
I installed the beta of 8.0.4 (8A50) (I assume that’s the one? It wasn’t entirely clear how to be sure I’m on the latest Beta) and I’m still getting the dialog:
Blockquote
The script “ArtBot Supervisor.scptd” failed to open because Mac OS error -1752.
Because this script was saved with Script Debugger, it may be possible to recover its source code.
The recovered source information may be out of date or damaged. Would you like to proceed with the recovery?
On some scripts. But maybe I just need to save them with the new version, and I won’t get this anymore?
Brilliant. Thank you! I didn’t think of linking the whole Script Libraries folder but that seems like a good idea just to have another redundant copy in the cloud in addition to Time Machine backups. Unless @ShaneStanley thinks it a bad idea?
If you only move your script libraries into the linked Script Libraries folders when deploying, how do you test them? When running your scripts in SD it presumably uses the old deployed versions of the libraries in ~/Library/Script Libraries/ rather than the version being developed in your git repo.
It changes both saving and opening.
That’s correct (or libraries elsewhere in the search list).