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: has <email@hidden>
- Date: Thu, 22 Aug 2002 13:18:55 +0100
Arthur J. Knapp wrote:
>
> 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). ;-)
It's a talent we have.;)
I don't think the "dereferencing" theory has much of a leg to stand on, as
the point of storing to disk is to preserve state, not to change it. Still,
you may have something here, in that you can't very well preserve memory
pointers when transferring the object to file; they'd have to be turned
into some other kind of reference. So maybe there's a recursive routine in
AS somewhere responsible for this job, and it's this that pitches over when
it blows the call stack.
Of course, I'm making this up as well. Sounds like we really need a
responsible adult (<cough>Chris N.</cough>:) to step in here before us kids
start injuring ourselves on the thing.
>
Consider the problems you would have if you used a multiply linked
>
structure:
>
>
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.
Cyclical references are not a problem in AS. It handles them just fine. [1]
>
> 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.
I've stored bigger (my AWPSRenderer framework spews compiledTemplate
objects at 1/4MB apiece and behaves perfectly). Whatever limits there are,
they're not simple ones. If you remember the details, I'd be interested to
know.
>
> 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:
Tried this too. As with records, these blow up beyond a certain number of
items added. Besides, both record- and list- based nodes are markedly
slower, so there's no advantage to using them that I can see.
>
Using lists ends up using slightly less memory than records, and
>
considerably less memory than script objects.
Script objects take about the same memory as records, as far as I can tell.
(I imagine they're pretty similar internally: little more than a collection
of named slots.)
>
I will have to look up on the Internet how linked pointers are generally
>
handled when written to file.
Be interested to hear what you find.
>
> 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. ;-)
Funny man. Just wait till I start writing full-blown parsers in AppleScript
- then you'll be sorry... ;p
>
> 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.
Megabytes and megabytes and megabytes... It's not a simple memory limit:
the error messages should tell you that. No, it's something wicked and
cruel and deeply devious, put there by the hellish minions of Apple Corp to
beat and torture us for our ungodly sins. "I confess! I confess! I once had
an impure thought about a Dell box back around '97, but I'm sorry now!!
Stop! Stop! Ahhhh, no! Please don't hit me with that buffer overrun...
Nooooooooooo!"
--
>
Of course, a normal list-based solution is also possible:
Quite. (Shows how often you visit my site then...;p) But even with all the
pig-ugly list access optimisations I can throw at it, it still performs
poorly next to the new linked-list design. If it worked well then I
wouldn't be trying to replace it now, would I? ;)
My current thinking is to leave the original list-based stackLib as-is, and
release the faster, linked-list version under a different name so that folk
can pick and choose which to use (the interfaces are identical, so you can
swap them about no problem). Hardly the "elegant" answer though.:/
--
Anyway, I'm still open to suggestions, explanations, etc. I want to do some
work implementing other types of data structures in AS (one of my hopes is
to come up with something better than AS's own list type, which is
currently #1 on the List Of Things I'm Really Sick Of And Hate), and the
more I know about why AS throws these kinds of wobblies, the better chance
I'll have of avoiding them.
Thanks,
has
--
(My email address has changed from <email@hidden> to
<email@hidden>. Please update your address books accordingly.)
_______________________________________________
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.