Debugging loaded scriptlibrary from within main script


(Luc Naets) #1

I have a very very very :slight_smile: long script and I already split it up in about 5 separate parts, 1 part to talk to InDesign, another part to talk to a WebService and another one is doing the styling of a table in InDesign, and some more…

I’m loading the different parts with the use command in a main script.

so in my main script I can say tell StyleTableLibrary to doSomething()

in the StyleTableLibrary I have a property with the InDesignLibrary
so in the StyleTableLibrary handler doSomething() you can call a handler in the InDesignLibrary

Now I want to debug a handler in the StyleTableLibrary script.
So I thought to place the complete StyleTableLibrary in the main script but then ScriptDebugger hangs probably because the complete scripts becomes too long.

Is there any way to debug the StyleTableLibrary without the need to import that script in the main script?

Can somebody guide me in a correct direction?


(Mark Alldritt) #2

Maybe. You can use cross-document scripting. This is where you open the StyleTableLibrary script, enable debugging, and then create a second test-harness document which invokes handlers within StyleTableLibrary:

tell document "StyleTableLibrary"
end tell

With this approach, you can debug handlers within your library in place.

Now, there are limitations to this imposed by the AppleEvent transport and AppleScript. For instance, you cannot pass object specifiers (references) to handlers. Script objects should not be sent in this way either. But if you handler parameters are scalers, lists or records it should work.

(Luc Naets) #3

Thanks Mark,
But what about inheritance? How does the Parent script menu item under the Script menu? What does this do and how to use it then?

(Mark Alldritt) #4

That feature does not help us with debugging libraries. It defines a parent-child relationship which can be used for AppleScript inheritance, but in order to debug within Script Debugger, we cannot allow AppleScript to dispatch handler calls for us. We must invoke handlers explicitly within the context of the script library which is what the cross-document scripting trick accomplishes.

If you have inheritance within your script library, that is fine. However, if there is inheritance across script libraries then we are blocked.

(Luc Naets) #5

but my library is in fact a script that is loaded

(Mark Alldritt) #6

I don’t understand.

Presumably, your library has an API (a set of handlers that can be invoked). If your library is designed to be used via inheritance, then perhaps you can define a procedural API within your library that the test harness can call into.

(Luc Naets) #7

Hey Mark,
It’s rather difficult to explain it… I’ve created a very samll setup as an example…

use AppleScript version "2.4" -- Yosemite (10.10) or later
use scripting additions

use LIB_gentool : script "testObjC.scptd" without importing
(* -- part saved as testObjC.scpt

	use AppleScript version "2.4" -- Yosemite (10.10) or later
	use framework "Foundation"
	on makeCaseUpper(sourceText)
		set the sourceString to current application's NSString's stringWithString:sourceText
		set the adjustedString to sourceString's uppercaseString()
		return adjustedString as string
	end makeCaseUpper


script grandma
	-- property type : "grandma"
	property sGenTools : null
	on sayHello()
		set mGreeting to "Grandma's greeting…"
		tell sGenTools to set mGreeting to makeCaseUpper(mGreeting)
		onShow(mGreeting as Unicode text)
	end sayHello
	on onShow(mTxt)
		display dialog mTxt
	end onShow
end script

script mommy
	property parent : grandma
	property pName : "Mommy"
	on talk()
		onShow("How do you do? " & pName)
	end talk
end script

script baby
	property parent : mommy
	on sayHello()
		set mName to mommy's pName
		tell mommy's sGenTools to set mName to makeCaseUpper(mName)
	end sayHello
end script

copy LIB_gentool to grandma's sGenTools

grandma's sayHello()
baby's talk() -- How do you do?
baby's sayHello()

And then place the script grandma, mommy and baby all in separate script files that are loaded into the main script. And when I want to debug I place only that specific handler of that specific script in my main script

(Mark Alldritt) #8

I cannot provide a solution for the need to copy testObjC.scptd into variables, etc. However, if all you want to do is debug code with testObjC.scptd then you can do something such as this (opening LIB_gentool first in another Script Debugger window/tab):

tell document "testObjC.scptd"
	makeCaseUpper("this is a Test") --> "THIS IS A TEST"
end tell

(Luc Naets) #9

Thnx Marc,
I was just trying to show you what the idea was.
The issue is that the scripts are long: about 1000 to 1500 lines and when I place the script inside one of the other scripts to debug SD becomes unresponsible for several minutes before showing a result or no longer responds at all. So I was looking for something easier to debug and teh idea was then to place the handler with the error in the main script with as parent that script where the handler normally resides.
I will further try to track down my issue by adding logging teh old fashioned way then :slight_smile:

Would it be a good idea to call in Shane Stanley on this one? Does he read this thread?

(Shane Stanley) #10

I don’t have anything useful to add. Anything more than about 600-650 lines starts to ring alarm bells for me. I also tend to avoid inheritance if practical, precisely because it can be difficult to debug.

There’s a distance between what AppleScript is capable of doing and what it’s wise to ask it to do, IMO.

(Luc Naets) #11

OK Shane, you do read every thread :slight_smile:
When you say ‘ring alarm bells’ what do you want to say? Ugly scripting ( it’s the start of a rework of a script I made back in 2007) or way too large and you should split it up in different parts :slight_smile: and then were back at the start.

As already said I will use the old logging solution to find the line were the errors occur and then try to do everything better in a refactered solution.

Thnx for the ideas.

(Shane Stanley) #12

I mean you’re risking problems. To be sure, I’ve seen much bigger scripts behave perfectly — but it’s a rule of thumb I’ve come to follow.

(Luc Naets) #13

Hey Shane,
Can you then give some good advice in how to structure such a larger project in AppleScript and especially Mark’s wonderful SD app?

Any tips will be greatly appreciated :slight_smile:

(Shane Stanley) #14

I can only tell you what I do: unless it’s impossible, I keep libraries and any loaded scripts self-contained. Once that starts to get difficult, I then generally move to hybrid Objective-C/AppleScript apps.

(Luc Naets) #15

Good afternoon, maybe morning for you Mark,

I want to followup on this request.

What could make the debugging of a script with about 800 lines, white lines included…
whitelines excl 640 lines, of code slow?
I’m using SD 6.0.5 on a macbookpro 2,3 GHz Intel Core i7 - 16 GB 1600 MHz DDR3.

Should I avoid any special things?

(Mark Alldritt) #16

Looking at the crash report you submitted yesterday, Script Debugger is failing to handle code folding in your script. Something in the text of your script is causing Script Debugger to recur infinitely. If you would like to send me the text of your script, I’ll look into the problem and develop a fix.