Re: Scope
Re: Scope
- Subject: Re: Scope
- From: Paul Berkowitz <email@hidden>
- Date: Sun, 15 Dec 2002 10:20:43 -0800
On 12/15/02 7:34 AM, "Paul Skinner" <email@hidden> wrote:
>
Paul B,
>
I'm glad that you solved your problem and I'm sorry if you felt I was
>
being obtuse or critical.
"Tangential" might be a better word. Telling me, after I've spent several
months on a complex project that works very well aside from one, almost
trivial, error that I should start all over with a different design, is not
what I'm looking for at this point. I probably would do something different
next time, but - for this time - I just want to find the problem and solve
it. I was hoping that someone out there had run into the same thing and knew
what to do about it. In fact, Emmanuel's answer and suggestion did just
that, but I didn't fully understand his explanation which was not quite
complete and assumed I knew what he was doing, which I didn't. A private
email from has explained Emmanuel's method (see below), and then had a very
detailed plan for a different type of design. More below.
>
I'm developing a project that will handle hundreds of handlers for
>
multiple scripts and this problem seems to be pertinent. I also have an
>
error handler that gathers data from within subroutines and returns
>
them to the user.
Yes. You probably should do it one of the two other ways, not the way I did
it. I did not plan to have a second script, although if I had known how huge
this project would become I would have started that way from the beginning.
I had one script, but clearly organized into two main sections, plus a run
handler, "a FinishOff" handler, an error handler, a quit handler, and a
group of "utility" handlers. Aside from the utility handlers (removing items
from lists, making large lists with more than 4060 items from test by tids,
that sort of thing), each of the two halves is completely self-contained.
each as a sort of master "controller" handler that directs operations for
its half. Within each half there's also a separate subsection, also
self-contained, with its own subcontroller handler.
So, when I hit the bug in AS 1.9 that prevents script compilation when you
get to about 140 KB source text, it was very easy to break the script into
two halves and load the second script when needed. I also duplicated the
utility handlers into the second script so that I didn't have to go back and
forth. Because of the need to have a lot of information available whenever
an error resulting from corrupt data occurred, and also because of
limitations imposed by using a progress bar via 24U Appearance OSAX with
repeat loops, which again requires lots of globals to be directly available
at all times, I ended up with more properties and globals than I would like.
In order to be able to pass all the values I needed to script B and not have
to rewrite it all, I had to define all of them (I thought) as properties in
group B. So I gave them all 'missing value', then passed all the current
values from script A to script B before calling any handlers in script B.
Some of them are "running totals" which have to passed back at the end. in
fact there are only six variables which have to passed back to script A: 4
running totals being incremented on repeat loops, one boolean variable which
ight change from false to true during script B, and that one list (of
specific data for any item that errored) which might have items appended to
it. It's when NO items need to be appended to this list, so that the
variable representing the list never once gets called, that returning the
variable without 'my' apparently returns the initial 'missing value' instead
of returning the list sent by script A. Simply returning 'my' with the
variable forces it to evaluate the correct value which it otherwise doesn't
seem to notice. it's as if it ignores its own context and goes back to the
saved copy of itself top get the initial value. That shouldn't happen.
that's the bug, and no, it's not easily replicable. It doesn't happen with
short example scripts at all, only with immense scripts. (Each of script A
and script B is now up to about 90K.)
OK. I could see that Emmanuel's suggestion implied that I was passing a
script object from script A to script B. But I wasn't, so I didn't know what
to make of his suggestion. has explained that a loading script (A) can load
ITSELF into script B, so then you don't need to redefine any properties.
They all become properties of script B. I would do this do this by including
a parameter such as A, or - more clearly - mainScript in the controller
handler in script B I'd be calling. There it would look like
on ControllerHandler(mainScript, var4, var5)
--do stuff with mainScript's properties
--call other handlers, include mainScript every time
end ControllerHandler
Back in script A, you'd call that handler via
set f to load script alias "path:to:Script B"
set {var1, var2, var3} to f's ControllerHandler(me, var4, var5)
You can load 'me' into script B that way. What Emmanuel was warning me was
that in script B I should always refer to 'mainScript's var3', never just
'var3'. But I didn't know what he was telling me.
Again, at this point, even to use this method, I'd have to add
'mainScript's' hundreds of time to my 3000-line script B. If I tried that at
this point, I'd be sure to omit it 150 times, and I'd still be sitting here
debugging two months from now. So I'm not going to do it since I found my
simple solution. But that's because my script started as one and then split
into two. This would be a good way to do it if planned out.
But has has (there we go again ;-)) a completely different, totally OOP
modular way of doing it, which certainly is very clearly organized. If you
are writing a script for clients who might be maintaining the script
themselves, you'd definitely want to go that route. I will forward you has's
message, and if there is general demand I'm (or has) can post it here too.
It's very long.
>
>
I tried very hard to follow this thread, I tried creating each of the
>
variations of all of the posted scripts, I tried various versions of
>
scripts for script 'B' before you posted anything defining it. I tried
>
analyzing what I thought you were trying to do. I failed.
>
When I couldn't follow the thread I asked you to post a simpler
>
version. This is just the way that I go about finding bugs. Unnecessary
>
parts of the script get chucked until there's nothing but essential
>
code left.
The scripts were schematic "diagrams" needed just to explain what was
happening. I think I did a pretty good job of boiling two 90K scripts down
to a few lines. They were not examples of the bug itself. I said over and
over again that short scripts did not error, and that even the full scripts
did not error OMM.
>
I feel like you might have taken my request as an insult. Your reply
>
seems a bit angry. I hope I can make it clear that I understand your
>
frustration and the difficulty involved in presenting a problem clearly
>
that you don't fully understand. If it was easy to present, then you'd
>
probably have resolved it long ago.
Unfortunately not. It's worse than that. Explaining it solves absolutely
nothing, since it's an erratic, non-replicable bug.
>
>
On Saturday, December 14, 2002, at 05:21 PM, I wrote:
>
> All the non-crucial variables, comments as to what would
>
> happen in some other non-posted script and anecdotal evidence are just
>
> camouflage.
>
>
When I wrote this I was referring to the loop, the unused Var
>
variables, and even to the code that loaded scripts B and C. Even
>
though loading scripts is necessary in your final code, here it
>
obsfucates the problem and makes for more difficult testing. You could
>
place all these scripts within explicit script blocks in one window and
>
test the same effect as loading them. If this isn't true then that is
>
helpful information too. (I can't test this due to the fact that the
>
code works for me regardless.)
I got rid of 99.99999% of the code. It could not be made any simpler than it
was. Emmanuel and has followed it because they've done a lot with complex
structures and much of this was already familiar to them. Without a previous
familiarity with these problems, I can well understand that it would be
almost impossible to follow what was going on. the very process of trying to
make it simple and short enough to present here strips it of most of its
context, making it that much harder to follow. I'm sure I couldn't have
followed it myself if I had never run into it. I'm impressed, and touched,
that you put so much effort into it. I'm afraid that to have made it more
cogent, I would have had write twice as much, not half as much. It could not
be made any simpler, and the effort to simplify is in fact what made it not
comprehensible to you. There are just too many factors involved to be able
to make it simpler.
>
<snip>
>
>
I hope I'm not pushing my luck or your buttons when I ask if you can
>
post a script that Will produce the error reliably now?
No, I can't. If I ever discover a minimalized version, I'll send you two
scripts to illustrate it. Otherwise, if I ever see a post here that seems to
have run into this bug (or to a mysterious "0" in an error message where no
integers are involved), I'll know what to suggest.
--
Paul Berkowitz
_______________________________________________
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.
| References: | |
| | >Re: Scope (From: Paul Skinner <email@hidden>) |