Stack file organisation
ambassador at fourthworld.com
Sat Dec 21 16:26:01 EST 2002
> But in Rev/MC, when you experience symptoms that may appear to be simlar to
> HC corruption it may be more effective to look for different remdies. In
> most cases, if you rebuild the card _exactly_, you'll reproduce the problem
> If you just suggested user error, you certainly did it tactfully. :-)
I wish I wrote that well. :)
Actually, I was thinking more about the nature of corruption and how in a
system like Rev it's hard to make it happen (the only time it touches the
disk is when you explicitely tell it to with a save command, and then it
writes the whole file fresh in one clean pass).
Your environment is hopefully less convoluted than mine, but with some of my
older tools I have libraries that provide insufficient feedback to the
routines that call them (thankfully I cleaned those up over summer for newer
stuff), so sometimes I would have a behavior taking place that is not
triggered by any of the scripts in my stack, but instead coming from one of
my backscripts. In my less careful days, this sometimes made finding the
true source of the trouble difficult.
Given the rarity of corruption in a non-paged-memory system, I tend to try
to exhaust all other posibilities before deciding it's corruption. If
nothing else, the few times I've sent something to Scott Raney suggesting ut
was corruption with the exception of one case of button corruption back in
'98 in all other cases he proves me wrong. :)
> Actually, in such cases, I'm praying that it's my fault. But it appeared not
> to be--especially since these cards clearly exhibited odd behavior during the
> most elementary of troubleshooting tests. Extensive assaults on these cards
> from different angles (show, hide, move, put, etc.) convinced me that the
> cards themselves were simply clinkers. So alas, the culprit wasn't I, but that
> is always a bittersweet discovery, isn't it?
> Considering that I'm the only one who has responded about this particular
> issue, it appears to be uncommon across the board. If it ever happens again, I
> will send the offending card to RunRev for analysis.
That's probably optimal. I know from my one instance it is possible to have
a corrupt object, and if so having them examine the stack file should enable
them to verify if thats the case.
It may also be a bug, but if it is it should be reproducible. I had a case
two years ago in which the SC-to-Rev converter faithfully copied object
properties from SC to Rev, but in doing so it included a fillpat for a line
object -- this caused a crash due to a bug in QuickDraw which throws a fit
when trying to calculate the fill region (a line of course has no fill
region). SC apparently special-cases such things when it's rendering the
object so that having the value set doesn't trigger QD's error, and MC
itself clears that part of the record when creating lines. But when
building from a SIF export, the combination of properties was faithfully set
in the object, and passed by MC'smore generalized C++ class off to QD, and
QD choked on it.
It drove me nuts trying to pin it down, but thankfully Scott took a look at
the stack and the MacsBug stdlog I submitted with it, did some tests, and
got me an answer within 24 hours. I just wrote a routine that cleared that
prop from all of the line objects and it's worked swimmingly since.
So while it seemed like corruption, the object record itself was intact and
fully functional. Once Scott showed me how to get around that QD bug I was
able to continue working happily away with the same objects.
Fourth World Media Corporation
Developer of WebMerge 2.1: Publish any database on any site
Ambassador at FourthWorld.com http://www.FourthWorld.com
Tel: 323-225-3717 AIM: FourthWorldInc
More information about the Use-livecode