I have been wrestling with an extensive library and maintaining it. Each time I added a new subroutine it took longer to compile or wouldnt compile. When I added a new subroutine and it bugged out, I would improve code to the point it would have to work. Simple things like changing:
set variable to (objects whose name contains something and does not contain somethingelse)
to
set theObjects to some objects as list repeat with theObject in theObjects if name of theObject contains something and name of theObject does not contain somethingelse then set newVariable to theobject as string exit repeat end if end repeat
or
set variable to {} ------ if removed would be less likely err on save set variable to someObjects---- in illustrator or finder
In an effort to try one of my mass fixes, I converted all of my comments that could be partial code I commented out or notes from having dashes to using (* comment *). It seems to have worked and sped up compiling. Is it possible Script debugger is still reviewing the code somehow even though it is commented out with dash marks?
It sounds like your library has grown too large. We suggest limiting all AppleScript source files to 2000-2500 lines. Beyond this, you can run into issues with the AppleScript compiler which can be difficult to diagnose.
The problems you describe sound very much like the kinds of problems you’ll struggle with when a script grows too long. I think you’ll find that as you continue on, you will be forced into trying ever more bizarre source code gymnastics to avoid the limitations of the AppleScript compiler, sometimes at the expense of performance (as would be the case with your unrolling of a whose clause into a repeat loop in the example you give).
AppleScript syntax checks the contents of (* *) style comments during compilation. This means that unclosed (* *) style comments and string literals within a (* *) style comment cause compilation errors.
Note that Script Debugger its self does not play a role in this. The AppleScript compiler operates at Script Debugger’s direction, but does not involve Script Debugger as it operates. However, when Script Debugger’s debugging facilities are enabled, additional hidden AppleScript code is introduced into your script making it between 40 & 60% longer.
Mark Thanks for your quick response. So would it be better to have more libraries? (6000 lines lol)
Also you mentioned:
are u saying incomplete code gibberish inside (* *) will cause issues? is it the same with — gibberish?
sometimes ill do things like ----- starting here ---- or just comment code out when I replace on another line. Just looking for best practice here or to understand what you meant.
Yes, I suggest you break your one large library up into a series of smaller ones. 6000 lines is definitely in the danger zone and explains the issues you’ve been struggling with.
Yes, incomplete code within a (* *) style comment will lead to compilation errors. -- style comments are different and completely ignore the content of the comment.
It seems that removing the — comments had the most impact being able to add to my library. I converted the dashes to (* comment *)
Perhaps it doesnt have to review each line with – since (* *) can be multiple lines? I know this goes against what your saying but it is definately the reason its working. I may have gotten lucky on the incomplete code I selected to use style comments on.
I definately will break up the libraries and did not know there was a difference on comments between style comment and dash comments. Thank you as always!
What your are seeing is a consequence of the script exhausting one or more of AppleScript’s internal limitations because of its length. The AppleScript compiler is failing in ways that it should not.
Under normal circumstances your choice of comment type should not matter other than (* *) style comments do interpret their content and syntax errors can arise if there are unclosed string literals and (* *) style comments.
I’ve experienced problems with excessively long scripts where changes to comments, like you are doing, can help. In one script I had to remove all the comments to get it to compile. I’ve also found that reducing the number of unique variable names can help. Sometimes reducing the nesting level of statements can help. But its impossible to know how these types of changes interact with one another.
The only reliable solution is to make your scripts smaller.
@alldritt not being a wiseass but the theoretical limit of my library seems to be around 6400 lines. During my rush to add fixes for Illustrator 2020’s undocumented change to posix paths, I literally cleared out extra returns and old commented out code in order to be able to compile/save. Thought that would be entertaining. In all seriousness do you have any references to the limit or is it your past experiences?
AppleScript’s internal limits are many and interrelated. Code nesting effects maximum script length. The total number of unique identifiers seems to have an effect. What is placed within comment blocks has an effect. And there are other things that we’ve never been able to pin down. These limits can change from one OS release to another. While the number of lines of code isn’t actually the problem, it is a metric which we can easily track and roughly correlates with AppleScript’s limitations.
Our suggestion to limit AppleScript source files to 2000-2500 lines is guidance to avoid these kinds of problems. Some people, like yourself, have longer scripts that don’t exhibit any problems. If you are not experiencing issues, then carry on. Just be aware that you may encounter strangeness as your script evolves.
And, as we explain above, enabling Script Debugger’s debugging feature makes this problem worse because it adds additional hidden AppleScript code to your script to facilitate step-wise execution.
Possibly a stupid question: When you suggest that a script should not be longer than around 2000 (or whatever number) lines, does that number include or exclude comments and blank lines? My guess is that you mean actual working code, not comments, but I hope it’s not out of line to ask.
When a script is stored, every object in it is assigned an ID, and there’s a maximum number of those IDs. If a script is too complex, the table of IDs overflows.
The objects are stored in a tree that is used to generate AppleScript’s byte codes, and also to reconstruct source code. So anything in source code is potentially another object. But actual lines of code can contain a varying number of objects.
For example, here’s a line of code:
if x = 3 then say "Three!"
The source tree of objects the compiler builds for that line of code looks like this:
not at all.