Re: AppleScript error, overflow.
Re: AppleScript error, overflow.
- Subject: Re: AppleScript error, overflow.
- From: Hanaan Rosenthal <email@hidden>
- Date: Fri, 8 Jul 2005 13:12:49 -0400
Thank you Has for the suggestions.
Loader does seem cool and I will look into it.
How is it different that normal loading of scripts?
Also I was wondering, would I create a problem if I loaded ALL my
subroutines into a single app and ran it as stay-open (as you
suggested)?
Would that impact speed?
As a test, I created an app with 420K of subroutines and it seemed
worked fine...
Thanks again,
Hanaan
On Jul 8, 2005, at 12:30 PM, has wrote:
Hanaan Rosenthal wrote:
My AppleScript system is encountering the following error:
Internal Table Overflow -2707
It is happening when loading script libraries.
Yep. That can happen in AS when your system gets big and complex
enough. Lots of hardcoded limits that seemed perfectly reasonable
back when you'd run out of RAM on your Mac II long before you ever
hit them. Not so reasonable now, of course; darn these multi-gig
machines. :p
Possible courses of action:
1. Increase RAM. This may be completely dumb, but the G5 is running
on 1GB and has 8 apps running, some are RAM-hungry.
Won't make any difference if the problem is a fixed-size table. And
if you're running on OS X then it would allocate all the real/
virtual memory your system asked for anyway.
2. Change library structure:
[...]
Would it be better to have the loaded script 'refer' to the libraries
that are already used by the Main Processor script (tell
script_library_x of parent)?
Yes. I wrote AppleMods' Loader system to deal with exactly this
sort of thing; see <http://applemods.sourceforge.net/
getstarted.html>. Might want to look into using that; the design is
a little quirky in places, but it's a solid, flexible solution and
will resolve shared dependencies no problem. Developer
documentation's not so hot, but you can grab the basics from my
site <http://freespace.virgin.net/hamish.sanderson/LoaderDocs.sit>
and there's plenty examples of existing use on AM.
Also look out for stuff like 'copy someScriptObject to someVar'.
AppleScript's 'copy' statement always does a deep copy, which for
script objects means copying their parent, and their parent's
parent, and so on, usually ending up with copying your entire top-
level script and all its state. That can blow the internal tables
pretty quickly, and wreaks havoc in OO systems by breaking shared
state too.
Another option is refactoring your code to reduce its size, though
obviously that'll only apply if it already contains unnecessary
duplication or bloat. And if all else fails, you might see if you
can hive off chunks of related functionality as standalone stay-
open applets.
HTH
has
--
http://freespace.virgin.net/hamish.sanderson/
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Applescript-users mailing list (Applescript-
email@hidden)
Help/Unsubscribe/Update your Subscription:
40cox.net
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Applescript-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden