How to debug multi-file script?

Report · Aug 30, 2005

I have a script I'm working on that consists of multiple files. Just like I do in C++, each class has it's own file. I can get the script to run properly by using the #include directive, including all the script files from one master script file that lives in the startup directory.

But, I can't get breakpoints for the debugger or execution errors into the debugger to work in any of the files except the master script file.

How should I be configuring this for proper debugging with multiple source files?

--John

Report · Aug 31, 2005

John,

Page 233 of the Scripting Guide has the text regarding included files:

"Included source code is not shown n the debugger, so you cannot see breakpoints in it."

In Bridge, all scripts run in the same scripting engine and global namespace. You do not necessarily have to include your classes.

You may find it easier to do load your currently included files via a simple script:

MyScript.loadSupportingScript = function( path ) {
var f = new File( path );
f.open( "r" );
var buf = f.read();
f.close();
try {
eval( buf );
} catch ( e ) {
alert( "Script " + f.name + " failed to load.\nError in line " + e.line + " , " + e );
}
}

You get the idea. Don't just use that code, I wrote it on the fly, it hasn't been tested or checked or anything.

Bob
Adobe WAS Scripting

Report · Aug 31, 2005

Hmmm. That's a disappointment that the debugger doesn't work on included scripts.

A couple more questions.

1) If I just use separate script files and let Bridge load each of them from the startup directory, don't I end up having to put "debugger;" commands in everyone of them just to be able to set breakpoints in them? That gets to be a pain with multiple debugger commands to get through everytime you start up.

2) Stockphotos does exactly what you suggest and has a function called loadScript for this purpose. The only way I've found to debug their scripts is to put a debugger command in every file I want to use the debugger on. That causes it to show up in the debugger with a "temp" filename (since it isn't a real file when the debugger sees it). Is there not a better way?

I'm starting to wonder if I might have to make a build process that just concatenates all my source files together into one giant file before debugging to enable full use of the debugger. Any reason not to do that?

--John

Report · Aug 31, 2005

John,

You shouldn't have to do that. I place a single debugging statement in the master file and then step into routines in other files from the debugger.

As for concatenating files, you'll notice the WAS scripts (Import from Camera, Contact Sheet, etc. ) are sometimes VERY large files. We opted to use one file per script to keep installation as easy as possible. And of course, we rely heavily on the libraries.

Bob

Report · Aug 31, 2005

I find it too unproductive to write the code with everything in one file. I like small granular files (one class per file). It also makes me think more about the modular organization of my code and the object oriented nature of it becaues everytime I add some functionality, I have to think about where I put it and thus how it's organized.

So, I'll try it with the multiple files all being loaded separately from the startup directory without the include directives.

Then, when it comes time to distribute this to others, I will probably end up concatenating them all into one or maybe two files like you have done, but only as a last build step.

--John

Report · Aug 31, 2005

I just tried letting all the script files load separately from the startup directory. Here's what I found. Please correct me if I've got it wrong or am doing it the hard way:

1) You can step into a file that didn't have a debugger; call in it from another file. That works.

2) You can't set a breakpoint in a file without a debugger; call in it until you have stepped into it from a different file. Then, and only then, the breakpoint will work.

So, if I've done this right, here's the summary:

If you want to startup your program and have it stop on a breakpoint you set, you have to have a "debugger;" command in the file you set the breakpoint in. BTW, I've found this is also true for dynamically loaded scripts. You can't set breakpoints in them without them containing a "debugger;" command.

It appears that the debugger won't recognize a breakpoint until the debugger has "seen" that source file via either a "debugger;" command or via stepping into it. I'm hoping this is a bug that can be fixed because this is quite inconvenient when debugging a multi-file script. It means that I either have to have a "debugger;" command in every file (so that I can set a breakpoint anywhere) or I have to be constantly turning them on and off with editing everytime I want to set a breakpoint in a different file. Not impossible to manage, but a lot more inconvenient than it could/should be.

On a separate note, does this feedback get to the actual ExtendScript team?

--John

Report · Aug 31, 2005

Unfortunately, breakpoints are only applicable when the debugger is running. Hence I don't typically use them.

My habit from the early days of Java was to place debug code on non-indented lines. I find that makes it easier to find those line and recongnize what they are.

This feedback does get to the ExtendScript team, I am typically in contact with them a few times a week.

Bob
Adobe WAS Scripting

Report · Aug 31, 2005

Just to make sure you understand the point I was making. The debugger is already running. I make sure that I get it running everytime with a "debugger;" command in my main source file. I then make sure the appropriate breakpoints are set when it hits that debugger command.

But, even after it's running, breakpoints set in other files will not work until the debugger has directly "seen" that file either by stepping into it or by triggering a "debugger;" command in that file.

--John

Report · Aug 31, 2005

zactly....

I have sent it on to the team.

Bob

Report · Aug 31, 2005

Bob,
I've tried reading a JS file and then doing an eval and gotten flakey results in the past. This was in CS several months ago, so maybe CS2 has addressed the issue. I've found the sanest way to get appropriate results is to do something like.

var includeFiles = [];
var includeDir = app.path + "/Presets/ScriptsData/include";

includeFiles.push(includeDir + "/stdlib.js");
includeFiles.push(includeDir + "/PSConstants.js");

for (var i = 0; i < includeFiles.length; i++) {
eval('//@include "' + includeFiles + '";\r');
}

Some files _really_ need to be included at the global scope. I have to move code back and forth between CS and CS2 (and PS7, btw) so getting this stuff portable is essential.

Also, if you are ambitious, you can have a script to do the file inclusion for you making one file with all the master and include files that you then execute/debug. It would be a piece of cake in perl and probably not too hard in PS-JS.

ciao,
-X

Report · Sep 01, 2005

X

You have a point. Eval can sometimes be flakey still. The flakiness rears its head when running a script that was loaded via eval in the background using a scheduled task.

They way the ScriptManager loads scripts is via Thumbnail.open(). For that to work, the script must contain a #target directive.

Bob
Adobe WAS Scripting