Re: stack/table overflows on storing complex scripts
Re: stack/table overflows on storing complex scripts
- Subject: Re: stack/table overflows on storing complex scripts
- From: "Arthur J. Knapp" <email@hidden>
- Date: Wed, 21 Aug 2002 12:48:42 -0400
>
Date: Wed, 21 Aug 2002 14:33:21 +0100
>
From: has <email@hidden>
>
Subject: stack/table overflows on storing complex scripts
>
Getting ticked off again at the problems encountered when trying to store a
>
script object that contains a large number of other script objects.
This is an interesting challenge. The problem is that the "links" are,
(in some hidden AppleScript sort of way), pointers, (data-sharing entities),
whereas the act of trying to write them out to file causes AS to
"dereference" the pointers to the actual data structure.
(I sound pretty knowledgeable when I'm making things up, don't I). ;-)
Consider the problems you would have if you used a multiply linked
structure:
-- script's a, b, and c
-- link a <-> b
--
set a's next_link to b
set b's prev_link to a
-- link b <-> c
--
set b's next_link to c
set c's prev_link to b
store script a
So AppleScript attempts to writes script a out to file, but it
encounters a property next_link that references script b. OK, so AS
grabs script b's data, only to find a pointer to a. Fine, so it grabs
script a and etc, etc, etc.
>
Example: I've just implemented some new stack/queue objects that store
>
values in an object-based linked list (1), and find these will break a
>
'store script stackObj' command if the linked list is more than 540 items
>
long.
Actually, links may not be the problem. I seem to recall some basic
data-size limit associated with the store script command, though I don't
remember the specifics.
>
Interestingly enough, I find that reimplementing the stack object's nodes
>
as records instead of script objects also breaks, only this time it breaks
>
while adding items to the stack object (again, somewhere around the
>
540-item mark). At least using script objects you can keep adding nodes
>
[almost?] indefinitely; you only get punished if you attempt to dump the
>
object to file.
Objects as nodes and records as nodes. One other interesting way to
go is to use list-nodes:
property nil : missing value
property prev_node : 1
property the_value : 2
property next_node : 3
property node : { nil, nil, nil }
-- Create 3 nodes:
--
copy node to a
copy node to b
copy node to c
-- Link a <-> b
--
set a's item next_node to b
set b's item prev_node to a
-- Link b <-> c
--
set b's item next_node to c
set c's item prev_node to b
-- Delete b from structure, (pretending that we don't know about
-- a or c).
--
set b's item prev_node's item next_node to b's item next_node
set b's item next_node's item prev_node to b's item prev_node
--
--> a <-> c, b removed
Using lists ends up using slightly less memory than records, and
considerably less memory than script objects.
>
I know this isn't a major issue for most users (overflows on tokenising
>
strings and various 32KB limits are much bigger hassles, and ones that
>
affect the majority), but I wanted to see if anyone knew anything more
>
specific on it as there's few things more annoying than writing really cool
>
new code and then having to glue health warnings all over it.
I will have to look up on the Internet how linked pointers are generally
handled when written to file.
>
(1) I'm aware of AS's built in linked list types, but as Chris N has
>
indicated that these may [not unreasonably] be dropped in a future AS
>
version it seems safest to roll my own.
Yes, there is no point to having a linked structure where the user has
no explicit control of the linking mechanism.
>
p.s. Here's the code if anyone wants to play with it:
Surely most people already have their own custom-rolled AppleScript
stacks and queues. ;-)
(I can hear Shane Stanley snickering cynically)...
>
store script foo() in file "frank:test" replacing yes
Again, it may be a simple memory limit with the store script command.
Try just creating an object with a very large string or list property
and see how large it can get.
{ Arthur J. Knapp, of <
http://www.STELLARViSIONs.com>
a r t h u r @ s t e l l a r v i s i o n s . c o m
}
_______________________________________________
applescript-users mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/applescript-users
Do not post admin requests to the list. They will be ignored.