Script Debugger Dictionary Cache

Script Debugger
#1

I am developing a scriptable application and am having some problems with Script Debugger (6.0.3) not picking up the latest Xcode build’s dictionary (sdef) file.

Note: I use the app’s full path name in a “use” statement making sure the script compiles against the latest build product location. This works fine, as long as I am sure the previous app has been stopped (or killed) before the build, else it might not actually be replaced by the build. When I have issues I check the date/time on the app and confirm it IS the latest build; I have gone so far as to explore the app package to make sure the side is correct (and it has been).

Even when I do this, the changes in the sdef often do not reflect in SD. I have the SD preference “cache generated dictionaries” “off”, and even click “Clear Cache”, which sometimes but not always forces a reload, but sometimes I have to quit and restart SD. I would have expected having the “cache dictionaries” off should reload it every compile - or am I wrong?

A recent release of SD displayed a button on the upper right dictionary display corner when the sdef changed, asking if user wants to reload the dictionary. I have not seen this happen in 6.0.3. Could this be a bug?

#2

Please try this. Build your app and run it, then open its dictionary in SD. Click on some class, show Raw Syntax, and confirm the display in SD is correct.

Now change the name and/or code of a property of the class in its .sdef in Xcode, and click run to quit/relaunch it. When your app quits, the right side of the dictionary view will be blank, and once it is running again, click on the class and see if the property matches the change(s) you made.

#3

My application is a “background” application meant to launch only by the script, but I started it in Finder to run it, and did a property class code change on one of the SDEF class properties like you suggested.

In this environment I have to make sure between builds that I kill the app before a new build, and that I have SD Browse to the actual application when opening the Dictionary, using the the entries on the side bar, even the current running application, does not work, SD does not notice the change and reload the sdef even IF it is a new instance of the app. Also I have to force a re-compile of the script to make sure the newest 4-char code is used by the commands. All of these requirements make sense, although they are tedious and exacting in nature.

When I ran your suggested test just now, the dictionary display (Raw Syntax) WAS in sync with the sdef change and the affected script commands worked.

However, I did notice though, the corresponding property value displayed with the correct value after a script change in the “results” display, but shows with a yellow warning icon and "getting {property name}… in the “value” display for that property. Perhaps this is a revisit of an earlier SD 6 problem with that display.

I will keep an eye on this and report new data if it comes up.

Thanks

#4

If you can launch your app by hitting Run in Xcode, that should kill the old version first each time.

#5

I have the build configured to wait for the script, when I do hit “run” Xcode displays something like “waiting to application to launch externally”.

The testing process, though tedious, is not the real issue. Getting SD to load the latest sdef and correctly displaying property values is something I have not found a good workaround for.

#6

I understand. But if the testing process automatically quits and relaunches your app, then all you should need to do with your script in SD is recompile, and click on the app’s name to display the updated dictionary.

#7

The key word is “should”; but the point is, it does not. No matter how the application is built, SD does not pick up the changes as easily as that. When I adjust the script to reflect the changes in the app, the compile fails with error because the new command semantics do not match what SD thinks it should be. Catch-22, SD will not pick up new sdef without a compile, will not compile because of disagreement with the sdef.

#8

Just so I understand…

I have a scriptable app project open in Xcode. I click run, and then in SD I have a script like this:

tell application id "au.com.myriad-com.Sample-app-name" 
	testing property
end tell

I then go to the project and change the name of the application property to testing property xyz, and click Run again.

I go into SD, add xyz after the property name, hit compile, and the script compiles with the new terminology.

Do you see this behavior?

#9

This is getting complicated.

Per your suggestion. using my app as a test case, I added a property “abc” with 4-char code “kabc” to the application (NSApplication); just in the sdef.

I built the app and added a reference to “abc” in the script code. It showed in the dictionary as expected; and compiled without error. Execution of the “get” and “set” failed because they were not implemented in the app.

Then, as suggested, I changed the variable name from “abc” to “xyz”, rebuilt (without specifically killing the old), and the dictionary displayed “xyz” as it should. I’m not so sure the application itself changed - see the following.

I changed the script reference from “abc” to “xyz” and the code compiled but execution failed (as expected). The Event raw code for the get and set had the right terminology though - it came from the dictionary.

Then I tried a scenario closer to my experience with this app. I have my own class in the app, so I put property “abc” into that class, rebuilt, and examined the dictionary; property “abc” was now a property of that class. Then I changed “abc” to “xyz” in the sdef and the name changed in the dictionary, so far so good.

However the “abc” property was not (yet) implemented in my custom class, so I added property “abc” to the class (with getter and setter) and rebuilt the app with the old one still running. The change in the app itself was NOT picked up, the get and the set failed with the same scripting error I had before implementing the property in its class.

SO … I manually killed the app and rebuilt it. I forced the script to re-compile, and only then did the get and set work.

The only problem I see is that after setting “abc” to a new value, the change in value reflected in the result panel (and explorer) but the new value was not shown in the expression explorer, even after a “reload”. I initialized “abc” to “ABC” and set it to “wow” in the script. The value for “abc” in the result window is now “wow” but the value in the expression window is still “ABC”.

Now that I know those three things, 1) kill the app to be sure the binary file in the app package gets replaced (it is “busy” and locked - OS X will not delete or overwrite it), 2) force the script to recompile after changes to the app, and 3) do NOT trust the expression explorer, I can make progress.

#10

Keep in mind that much of this is out of SD’s hands. AppleScript itself caches dictionaries, and there’s no way SD can force it to update its cache. In fact, up to 10.10, any changes to an .sdef required relaunching of the editor; checking mod dates and reloading if changed was only introduced when scripts with their own terminology were introduced.

#11

Yes, I wondered if the problem might be rooted within Applescript itself, but was not sure.

This is my first attempt at putting scripting in an application, so when things don’t work as I expected I’m not sure if it is an error on my part, a bug, or just how things work. I guess this is a “just how things work” situation.

Can you be more specific what the Dictionary Preference facility actually does, the Cache generated dictionaries and the Clear Cache button?

Thanks for your help.

#12

When you run and compile a script, the dictionary stuff is all handled by AppleScript. Script Debugger takes your code and passes it to the compiler, which returns a compiled script object from which Script Debugger can then extract the styled composed code. So any and all caching involved here is up to AppleScript.

With the dictionary view, Script Debugger loads and prepares dictionaries for display, and this is what the caching settings control.

Does that help?