Max length of Script?

Is there a maximum length of an applescript?

I have about 9,000 lines of code and when I try to save it, I get " The document could not be saved.

When I (* *) out a huge section it lets me save.

I saw a few posts on the forums, but no real solutions?

EDIT

As a work around, I copied and pasted the lines into TextWrangler and saved as .scpt

I ran it via terminal and it seems to work.

osascript /Users/xxxx/Desktop/testscript.scpt

What could be happening here?

I have a large script which, when it’s saved as .appleScript take 506658 bytes on disk.
If can’t save it as .scpt.
I created a copy deprived of every comments which may be saved as .scpt.
Adding one comment makes it unable to save.

I decided to split it in two parts.
When the first part is executed, it executes an instruction which launch the second part.

Maybe it would be more efficient to replace launch by run to execute the second part but here it doesn’t apply because the script must be able to execute code from part1 if the user decide to move back in the flow of code.

Yvan KOENIG running El Capitan 10.11.6 in French (VALLAURIS, France) dimanche 14 aout 2016 09:44:29

Hi snaplash.

I’m not aware of any current script length limit, although 9,000 lines does seem rather a lot.

A fairly common cause of saving problems with compiled scripts (or of errors after they’re run) is the use of persistent variables to hold massive amounts of data ” such as large texts, lists, image data, or whatever. A “persistent” variable is a top-level property, a global, or a variable used in the run handler (the top level of the script). The value it has when the script finishes is kept. If you save a script after running it, the values of all its persistent values are saved with it. Similarly, if you run a script which has already been saved as a compiled script, the values of all its persistent values are automatically saved back to the file when it finishes. If these values involve significant amounts of data, they can choke up the saves. I can’t say if this is definitely the cause of your problem, but given the amount of code and the fact that there are no apparent problems when the script’s run from a text file, it seems a strong possibility.

Cures within the script can be either to reset persistent variables to short values (such as “”) before it finishes or to declare and use them as locals:

property scriptName : "Fred" -- Property. Persistent.

global aGlobal
local aLocal

set aVariable to (read file completeWorksOfShakespeare) -- Run-handler variable. Persistent.
set aGlobal to (read file EncyclopeadiaBritannica) -- Explicit global. Ditto.
set aLocal to (read file WarAndPeace) -- Explicit local. Not persistent.

-- Blah blah blah.

set aVariable to "" -- Reduce variable contents before finishing.
set aGlobal to "" -- Ditto.

I personally prefer to put my “top level” code in an ordinary handler so that all variables are local unless I declare them otherwise:

main() -- The only thing in my run handler.

on main()
	set aVariable to (read file oneOfNGsExplanations) -- Local by default. Not persistent.
	
	-- Blah blah blah.
end main

The “.scpt” name extension is properly for compiled scripts. The correct extension for scripts saved as text is “.applescript”. You can normally save them as such by choosing the relevant File Format option in Script Editor’s Save. dialog. It’s a good idea to recompile scripts immediately before saving them so that Script Editor doesn’t try to save the persistent values left over from tests too.

Yvan:

Thank you. Yes, I have the same problem. I need to access the variables all the way through the script, splitting could be an option, but with a bit of manipulation and duplication.

Nigel, I tried your second solution “on main()” but to no avail unfortunately.

On your first solution - resetting the variables, would that mean that each variable I have declared throughout the 9k of code would need to be reset to “”?

If that is the case, is there a way to list all variables contained within the script? There are a lot which is probably causing the -2707 internal table overflow

FIXED! I feel foolish.

I had written the code over a year or so and sometimes when something “works” you leave it alone without really looking for a more efficient way or mistakes.Sometimes you cant see the forest for the trees

I feel like a bit of a dummy.

I had the script looping through a spreadsheet multiple times with “repeat with i from 1 to rowColumns” for every one of the Header Titles.

After I stripped out the repeats and used it just once it was fixed.

No wonder I invoked an overflow. I had over 400 repeat loops.

Thank you both for your Insight and sorry to have wasted your time.

EDIT:

Nigel, I will be using your “on main()” technique from now on. It makes a lot of sense. As someone who started AS just by cobbling things together, I had no idea about Globals etc. Although the last day or so has been frustrating, I learned alot which cant be a bad thing so once again thank you!

We all have such moments. :wink: You can take satisfaction from the fact that you found and fixed the problem yourself. :slight_smile:

I think I got the idea ” certainly the handler name ” from a guy named Bill Briggs, who was a prominent contributor on the AppleScript-Users e-mail list a few years ago. He called his handler main() after the similarly named function in C, but the term has no special meaning in AppleScript.

To answer the question to this topic. There is not something like maximum number of lines of codes but there is a maximum to an script object (table) and stack call for instance. It is never a good idea to write one long script. The (implicit) script object with all handlers in it in such a compressed syntax as AppleScript should never exceed a thousand lines of code, just a rule of thumb. I have written some code in AppleScript in the past with more than 45k lines of code, but it was divided over more than 60 AppleScript objects containing all small routines.

For the record:The main() function in C is equivalent to the run handler in AppleScript. After the C environment is initialized the main function is the first function called by C’s runtime. The run handler in AppleScript works the same, the run handler is called after initialization of the runtime. However there is a slight difference between these two. Main() is the first function called in a procedural language which mean each function (symbol) may exists only once in the entire program. The run handler is actually a “method” contained by every script object making each object be able run, AppleScript will call the run handler from the root object after it’s initialized. For people whose programming skills goes further than AppleScript (Java, VBA or Python for example) I think using the main() handler can actually be confusing. I know AppleScript allows multiple paradigms but I would rather use AppleScript’s own entry point or none as the language allows but not a pseudo one.