I’m getting it on things I haven’t resaved. I’ll re-save from the new version, and then if I still get it again when opening on the new version, I’ll let you know and send samples.
Thanks for the fix!
- Tom.
So, I’ve got command+option+s in Script Debugger set to run my deployment script, and I basically never hit command+s. So I basically work exactly as normal except I hit command+option+S when I save. That performs the local save to my git folder (as .AppleScript for most files, but as .scptd for things with bundled resources), but it also saves an exported copy to the correct place, based on where the file was in git.
Inside my ~/Libraries/Scripts folder, there’s an alias to one Dropbox folder. That’s where my scripts are standardly deployed. FastScripts and everything see them through the alias… but since it’s just an alias inside the folder, I can also manually deploy non-shared scripts there that are only local to a single user. Then ~/Library/Script Libraries is a symlink to another Dropbox folder… my only way to deploy a library to a local user without deploying it to the Dropbox folder to to deploy it to the System’s Library/Script Libraries folder, because to have the libraries work correctly, we’ve found the entire directory needs to be a symlink to work properly in some cases.
When I hit command+option+s, if I’m working in a file that’s saved in [git folder]/Script Libraries, in addition to saving to .git, it also exports a run-only copy to the Dropbox “Script Libraries” that’s symlinked; if the file is in [git folder] but not in it’s “Script Libraries” subfolder, then it saves it to the Dropbox folder that’s aliased inside ~/Libraries/Scripts.
So all I do is hit a command key to save, and then the library is “deployed.” If I recompile any other open script, it sees that library as current to what I just saved.
The scripts have a comment at the top that specifies the deployment file type (.scpt, .scptd, .app) and the deployment script saves the exported copy on Dropbox in the desired format regardless of the file type on git.
Additionally, we run branches on our code - we can deploy multiple git branches simultaneously. Each gets its own Dropbox folders for “Script Libraries” and “Scripts,” then we have another script that lets you select a branch by name, and it changes where the symlink and alias point to the appropriate set of Dropbox folders. So it’s super quick and easy to change branches. (That script that changes branches also restarts FastScripts, so it updates its caches of libraries, to avoid conflicts between scripts and the library versions they’re expecting). Then there’s also a script that loops through all the files on a git branch and runs the deployment script on them, so an entire branch can be deployed/refreshed off the git code “masters.” Although that’s not used often, because usually everything’s kept up-to-date with normal command+option+s saves. But when making a new branch and deploying it, it saves a lot of time.
The deployment script reads the current branch out of the git folder’s “.head” file, so when you hit the key command to save, it’s always saving the script to the correct branch with no user interaction.
This may sound like a lot, but since Script Debugger has a good Applescript dictionary itself, it’s really not a lot of lines of code.
Just to follow up, I have not gotten it on any files that were saved from the beta and opened with the beta. Looks fixed to me. Thanks so much!
Thanks for the feedback, Tom.
Thanks so much, @tspoon, for taking the time to explain all that. I really appreciate it. It does sound like a good system that I will slowly work towards.
I also did write a reply many weeks ago, a long one, but Safari froze and crashed as I was hitting the button to post it, and so I lost everything I had written. I was a bit demoralised from losing everything I had written so it’s taken me a while to write the reply again. But now I can’t remember what I had written.
I did go ahead and move one of my projects into git, but it hit a problem straight away.
It’s an enhanced applet (fancy droplet) that, among a number of libraries it depends on, uses 2 specific/dedicated libraries that I’m developing in tandem with it. I’ve saved the applet in git in .app format, and the 2 dedicated libraries in git in .scpt format. I’ve created aliases of the libraries in ~/Library/Script Libraries/. At the moment I don’t care too much that I can’t see the diffs, so long as I can revert to a previous commit if necessary based on the commit notes which, from my earlier testing, is possible.
The issue is that when I opened it in Script Debugger, immediately after putting the applet in git, the source code was replaced with the following message: “AppleScript failed to retrieve the script’s source code.” That issue persists until now.
Fortunately, the code is still all in main.recover.rtf in the Scripts folder within the Resources folder in the applet’s bundle.
But if I copy the code from main.recover.rtf and paste it into Script Debugger and try to compile, I get the following error message: “An error of type -4960 has occurred.”
@ShaneStanley, could you please help? Any idea what the issue is or how to fix it?
No idea. Email me a copy of before and after.
Thanks, @ShaneStanley – email just sent. Please don’t feel compelled to work on it over Easter. I’ve only raised the issue now as I have the time away from my day job, and no doubt you deserve some time away from your day job too.
I’ve looked at the files you sent. Both open and compile fine, as do the contents of the main.recover.rtf files.
Thanks for taking a look! That’s so weird.
Any idea why it doesn’t work for me?
What is “An error of type -4960”, do you know?
It’s coreFoundationUnknownErr. Not very helpful.
Are you in the Script Debugger beta? The bug with git is mentioned in the above thread, but I didn’t see for sure if you’d gotten the beta.
There’s a known issue here with Script Debugger and git where Script Debugger sees files as corrupted when you change git branches. It’s fixed in the beta.
When I had this, Script Debugger would say a Script was corrupt and offer to recover from the RTF. But if I did a recovery, it couldn’t compile the recovered copy either, it got an error. Can’t remember if it’s the same error you’re getting.
If I did a select all, copy, quit Script Debugger, relaunch Script Debugger, make a new document, paste the code in, then compile, it would work. Then I could save over the original.
A good suggestion, but from memory that only affects .scptd files, not applets.
No, I’m not currently running the beta. I’m running SD 8.0.3.
I thought I might be running into the same bug, but now I’m not so sure. Shane said he thought the bug only affected .scptd files, but I’m experiencing it with an applet. Also, I deleted the version in git and cracked open the version that I had archived before putting the project in git, and now I’m having the exact same issue with that copy of the applet. That copy has never been in a git repo so I’m now not sure how the issue could have anything to do with git, though it’s weirdly coincidental that the issue should occur just after I created the git repo.
I tried this just now, including the step you mentioned of quitting and re-launching Script Debugger before pasting and trying to compile the recovered code, but it still doesn’t compile. One of the libraries used by the applet is having the same issue, so I thought it might be a dependancy thing. I tried the same thing with the library – recovered the code, copied it, quit and re-launched Script Debugger, pasted and tried to compile, but got the same error. This is also using copies of the scripts that have never been in a git repo and which Shane says compile fine on his machine. I’ve also rebooted my Mac 2 or 3 times. In fact I upgraded to macOS 12.3.1. And having the issue on this latest OS as well.
It’s really odd. And now like my worst nightmare that the backup copies of the code I kept are seemingly next to useless if I can’t compile them. I do have another machine and now I think of it I’ll try see if it will compile on that machine, though it’s my work machine and I try and keep it clear of dev stuff. @ShaneStanley, are there any SD preferences or caches or anything that I should try deleting?
Hmm, of course after posting that I think I have found the issue. As mentioned above, I included 2 of the library dependancies in the git repo, with aliases in the ~/Library/Script Libraries/ directory. That seems to have been the cause of the issue , as once I move the libraries back into ~/Library/Script Libraries/ I can open the applet, compile and run as normal. @tspoon did say that he had found that there were issues unless you simlinked the entire Script Libraries directory. I should have listened.
I guess I’ll have to work on that build script to export the libraries every time I save.
Does Script Debugger have support for executing scripts/adding them to the menu? I can launch them with FastScript or Keyboard Maestro but curious whether I can add them directly to Script Debugger.
Look at the icon on the topline menu immediately to the left of Help. That’s the SD Script Menu. Click on it and you’ll see everything you need to access scripts from within SD.
1 Like
Thanks, @emendelson, for pointing out Script Debugger’s Scripts menu. I should have known that. But your reply was just the push I needed.
I’ve now set up a build/deployment script inspired by @tspoon so that I can keep scripts (at least ones that don’t need resources) in .AppleScript format in git and they get exported as compiled scripts into my ~/Library/Script Libraries/ folder every time I save, which I now do by pressing command-option-s to trigger my build script as per @tspoon’s suggestion.
I’ve decided to put my build script in git and make it public because… why not? So if anyone is ever interested you can check it out.
I’ve started with the bare minimum, nowhere near as robust or generic as @tspoon’s sounds, but no doubt as I use it more and bump painfully into those sharp edge cases I’ll improve and expand it as I go along.
Okay, so I’ve run into the first issue with this script already.
If I use Script Debugger’s direct export command, there are two issues. First, the UI will pop up to say the export is complete which I need to dismiss. If this script is to be used as often as I use command-s, that could get a little annoying. But perhaps I could still do command-s when compulsorily saving as a security blanket, and then do command-option-s to trigger the build script when I’ve made substantive changes. So perhaps I could live with this. Second, direct export doesn’t take a location parameter. It returns the exported file which I could then move to the desired export location, but it would leave the subfolders and other documents created by direct export behind in my git repo to clean up.
As an alternative, I tried using the classic save command, which takes a location as its “in” parameter and the script format as its “as” parameter. This effectively exports a version in the specified format, but the currently open document then changes to become the exported version, which makes it unusable for this purpose.
@tspoon, do you use the save or direct export command? Am I missing something?
My save line is:
save activeDoc in POSIX file savePath as exportFormat with run only
Regarding the dialog, there’s a relevant thread here:
At the moment, I do get the dialog… I do still hit [command + s] while developing sometimes, but use command + option + s to save and deploy.
Since when I deploy, I’m deploying live to a hundred people, it’s a pretty considered action and an additional dialog doesn’t phase me much. Like, I wouldn’t really want it to be silent in my case - I’d add a dialog to my deployment script if I weren’t getting one.
I’d be glad to send you a copy of my deployment script, but it’s a bit of a wreck of cruft, supporting prior standards from other programmers. Like, 2/3 of the code in it should be removed when we get a chance to refactor it.
Okay, cool. I’ll toughen up and deal with the confirmation dialog then. Odd though, I only get the dialog when using the direct export command, but I notice your script uses the save command and still gets it. But anyway, I guess I’ll use the direct export command and deal with the dialog.
Hahaha, I laughed so hard at this as I can very much relate. But hey, if we always indulged the itch to refactor and improve old code that ain’t broke we’d never get anything new done. Thanks a bunch for sharing I really appreciate it.
Update: I’ve gone back to using the save command rather than direct export. The issue I was having with the saved compiled script opening in place of the .AppleScript version was only if I saved without run only (i…e. set run only to false). If I set run only to true then of course it doesn’t open in place and effectively performs an export which makes sense. And consistent with that it shows the confirmation dialog which I can learn to live with. Why not just use the direct export command, you might ask. The direct export creates subfolders and stuff which is great when I’m exporting a build for release but I prefer to avoid the extra cruft if just doing a build for internal testing.