Error - Doesn't seem to belong to applescript

Script Debugger
#1

Once of my compiled scripts was corrupted. I was able to retrieve it as a text file using the Recovery Damaged Script feature.

Unfortunately, when I try to save the script file as a compiled SCPT file, i consistently get the error “Script doesn’t seem to belong to AppleScript”.

The compiler marks the line:
"use libemailfunctionslib4 : script “email_functions_lib4”

As you can see in the attached image, this “use” declaration has the same syntax as several similar lines above it.
I have checked to be sure that the library file referenced exists, is itself compilable, and that the spelling is correct.
I have even saved the library file as text and resaved it as a compiled SCPT.
All the other referenced library files are in the same folder as this one.

Any clue as to what is going wrong here?

Screen Shot 2016-07-22 at 2.53.55 PM.png1326×578 201 KB

#2

Are you trying to directly reserve the file you opened? That could be the issue. I’d copy and paste the text into a new script file and see if that will compile and save.

#3

Your library script is saved with debugging enabled. Open the library, disable debugging, and reserve. Then you should be able to open and run your script.

#4

Thanks a lot. This was a real stumbling block. I could not figure out what was special about that library.

It did work after I turned off Script Debugging in the library file and re-saved it.

I do not know what “reserve” means in this context.

#5

reserve == resave (autocorrect bites)

#6

This is a real gotcha, especially for new users like me. It’s not obvious what the changed icon means nor is the visual indicator in SD’s interface that useful until AFTER you’re already aware of this behaviour.

I think it’s because having an alternate save behaviour isn’t familiar from other apps. As I mentioned in my review, I only fully realised what was going on when I saw it referred to in the Advanced Debugging tutorial video.

I don’t know if you get a lot of reports that boil down to this issue, but if so, a warning dialogue box when saving in Debug mode for the first time would be really useful. To avoid annoying those who know, you could add a ‘Do not show this warning again’ checkbox.

1 Like
#7

fwiw, I was confused by that as well when I first started using SD and had saved a file in SD’s debugging mode. Was surprised to find I couldn’t execute the script in another context anymore ( run it from Quicksilver). I did figure it out quickly enough, but still… a bit unexpected that depending on the mode of execution a different version of the script is saved. Not that the behavior isn’t useful once you’ve gotten to know it… (although I still sometimes accidentally save a file in debugging mode when I really just wanted to save it regularly.)

#8

Yes, this is a problem that I recognize. Unfortunately, a solution was outside the scope of the Script Debugger 6.0 effort.

What follows is simply an explanation, not a defence of the current state of affairs.

AppleScript provides a very limited API for developers, and absolutely nothing to facilitate debugging. Everything Script Debugger offers is done by various forms of hacks. Think of Script Debugger as a Porsche 911: a really bad idea executed very well.

Back before the appearance of AppleScript Libraries, AppleScript scripts were monolithic. Sure, you could use the load script command and Script Debugger had its own library facilities, but most scripts were the result of a single compilation unit.

Script Debugger’s exploits this single compilation unit model to introduce its debugging hooks at compile time. This is accomplished using Script Debugger’s own OSA component (~/Library/Components/Script Debugger.component). The use of a custom OSA component facilitates debugging within other host applications (Mail, etc.).

But, as always, there is a problem when AppleScript loads code on the user’s behalf (load script, use script, run script). These actions take place within AppleScript and beyond the reach of Script Debugger. As a result, Script Debugger is unable to introduce its debugging hacks where needed. Further, because Script Debugger uses its own OSA component, AppleScript interprets code saved with debugging enabled as something other than AppleScript and reports the errors you are seeing.

There are other issues as well: Script Debugger’s UI is built around the we need to adopt an Xcode-like UI where a script is composed of many source documents. This is a massive change.

To do libraries correctly I first need to find a new means of introducing Script Debugger’s debugging hacks into loaded code. I have ideas for this, based on the notion of JIT de-compilation and re-compilation. But even with that approach, there will be situations (i.e. use script in the body of a script) where Script Debugger will not be able to do its magic. Then, the entire Script Debugger UI for document management will have to be implemented, ore or less, from scratch to support a multi-source documents/script modal. There are side issues such as ensuring AppleScript re-loads libraries when are edited and the main script is not compiled, etc.

Quite frankly, Script Debugger’s market is so vanishingly small that its not clear that I can justify the investment needed to make all this happen. It remains to be seen if the reduction in price stimulates sales enough to justify this kind of effort. So far, we are in a negative position, compared to the release of Script Debugger 5.

Works in Script Editor, not in Script Debugger
#9

I’m sorry to hear that.

This has to be a marketing issue, though. Not just for SD, but of course for AS itself.

Tim Cook was today on Twitter promoting Swift playgrounds as ways to get kids into coding. Clearly, Tim doesn’t know Jack about coding in Swift. But AS IS a good way to get kids into coding. I’ve got both of mine into it (10yr & 8yr) simply by letting them play with “say” and lots of funny voices. They like to connect to the Bluetooth speaker in the kitchen and interupt their mum playing music with “give us all your money!” in some funny voice etc etc. If I had the time or the expertise I’d be writing a “Coding for Kids with AppleScript” book. Schools are mad for coding stuff these days.

And where are the competitions? A free SD license for the person that produces the most impressive < 10-line script that shows off what AS can do (you’d have to bar Shane, though)?

I don’t know. I’m a relative new comer to the scene, but I see old grey-beard Cocoa developers snorting condescendingly at AppleScript without the faintest idea that it’s a very real and easy way to bring people into coding (perhaps if AS gurus themselves – not naming any names – stopped wringing their hands over how “bad” it is). I had an argument the other day with a developer who claimed they wouldn’t go near Apple Events because they were worse than the “walking dead” – still, I saw them recommending a script I’d written to other people in the very next thread. :wink:

I’m neither a coding guru nor a marketing guru, but it seems to me that both what ails AS in general and SD in particular is not the coding, but the limited reach of the marketing.

#10

I have been in AppleScript since it first came out. I was a developer when it came out. So I have picked up a number of things over the years. Perhaps this will explain some of the politics that have surrounded AppleScript since it’s creation.

A lot of developers consider AS limited in it’s uses because the AppleScript language is not very powerful. There is a lot of truth to the claim the AS language is not that powerful. But what these people don’t understand is that the power of AS doesn’t come from a powerful language or sophisticated developments tools that have been perfected over decades of use. It comes from leveraging the power of existing applications and processes. Programers like there big powerful languages and they often don’t take AppleScript seriously. I have been able many times to find ways to work with existing applications to beat a development team to a solution because they they build all the parts of the software while I find existing apps that already supply what is needed or shell scripts that allow more customized solutions.

Too many technical people fail to see the power of AS. As times goes on some attitudes change. Right now AppleScript adapts the customers requirements to what existing software can supply and what AS can be made to do. To me all the phases of development are different for scriptures and developers except perhaps testing. Developers design a solution that exactly matches what the costumer asked for.

But engineering is changing and versatile plug and play stuff is becoming more in demand. AppleScript solutions are quicker and cheaper to develop for small and some medium sized projects. I think inter-application communication is the way of the future. But there are a lot of people who think the old ways are better. However Apple is beefing up their support of AppleScript lately so apparently Apple thinks there is a value to AppleScript. For a while Apple thought AppleScript was a security risk. But with the introduction of Sandboxes Apple stropped calling AppleScript is a security risk. The basic idea of a sandbox is each application gets its own sandbox (memory) to play in and an application can’t play in anyone elses sandbox (access some other process or application’s memory).

So AppleScript has a lot of politics and opinions associated with it. I think it is the politics and opinions that ultimately stifle any real serious marketing efforts from Apple when it comes to AppleScript. I’ve heard some heated debates when it comes to AppleScript versus “conventional programming.”

Bill