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: Fri, 23 Aug 2002 00:22:37 +0100
Chris Nebel writes:
>
> 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.
>
>
Sorry, I was largely ignoring this thread, so I'm missing most of the
>
context,
Simple home-grown linked list implementation causes stack overflow errors
on storing to disk (when applet quits or on explicit 'store script'
command) when said list contains more than approx 540 items. The objects
are simple enough in design and the amount of data I'm putting in them is
piddlingly small; the problem in this particular case seems to be depth
(too many levels of objects within objects), for reasons I can't fathom.
Possibly related: a previous applet-based project containing a large number
of complex objects also blew up on quitting (aided and abetted by the
persistent behaviour of top level variables and/or tardy garbage
collecting, which meant they weren't being cleared out as they were
supposed to). For whatever reason, that one gave a table overflow error
(only time I've seen such an unusual beast).
If I knew more about why some designs break things when other [more
complex] ones don't, I might be able to avoid these problems a bit more...
and so delay the onset of screaming insanity attacks that threaten whenever
I try to do any halfway sophisticated coding.:p
>
but I think you're pretty much correct. AppleScript has its
>
own internal storage format for everything; in order to send an event
>
anywhere (e.g., to another application or a scripting addition like
>
"write"), it needs to turn that into Apple event, which means
>
duplicating the data in memory. If said data is sufficiently complex,
>
you could run out of stack space or memory.
Does the stack run out due to the data copying itself, or something else
(like retrieving that data in the first place)?
>
> Cyclical references are not a problem in AS. It handles them just
>
> fine. [1]
>
>
Except that they can't be turned into Apple events -- you'll get a
>
stack overflow error if you try.
[Oops, looks like I missed a footnote there (and can't remember what it was
now).]
Below is the sort of thing I was looking here (same idea as Arthur was
talking about):
======================================================================
on run
script a
property p : missing value
end script
script b
property p : a
end script
set a's p to b
store script b in file "frank:test"
end run
======================================================================
This stores just fine (sorry Arthur:), even though 'a' has a property
containing 'b' and 'b' has a property containing 'a'. From this I surmised
that AS is smart enough not to needlessly copy the same data repeatedly: if
the same object is pointed to by multiple properties, AS only writes a
single copy of the object to file, and presumably has some way of telling
those properties where to find it when the object is loaded up again. (Of
course, I don't have a clue what's really behind AS's properties: basic C
pointers, something higher-level, or what; so again I'm just making it up
as I go along and no doubt murdering terminology and concepts left, right
and center...)
>
> ... 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.
>
>
Sins? Nah, we do it for fun! That's right, we sit around and dream up
>
ways to torture you. We even know you all by name and write specific
>
bugs *just for you*.
Aha! This explains *EVERYTHING*. Especially my old 7500 [1]. >:|
Cheers,
has
[1] a.k.a. The Demon Spawn From Blackest Hell... drove me
**utterly**insane** for 18 months until I smashed it into tiny, tiny
pieces. You think I'm crazy now, you should've seen me back then...
--
(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.