debugger anomaly updated

Timothy Miller gandalf at doctorTimothyMiller.com
Wed Jul 13 22:02:32 EDT 2005


>Alex-
>
>Wednesday, July 13, 2005, 2:42:17 PM, you wrote:
>
>AT> Would it be at all possible to write a stack that would "export" another
>AT> stack to some textual format, and then another which would "import" it
>AT> again (i.e. into a new clean stack)?
>
>AT> I know the general problem is hard - but I also know that my own stacks
>
>It's actually not that hard at all - that's the way my version control
>system works. An object can be described completely by its combination
>of properties, custom properties, and script. If you enumerate the
>objects in a stack in a hierarchy from the stack to the cards to the
>controls and save these off then you can recreate the whole thing or
>just parts.
>
>
>--
>-Mark Wieder
>  mwieder at ahsoftware.net

Great thread, guys.

Similar ideas occurred to me. There's a HC stack that rebuilds a new 
stack from scratch, an identical copy of an existing stack. It was 
used to "rescue" corrupted HC stacks. Typically, it was able to 
rebuild a stack by bypassing a bad card. It's been widely used for 
years. as you probably know.

I was hoping someone had done something similar in Rev. In theory, 
the HC Rescue stack might be imported into Rev, though some 
additional features necessary for rebuilding Rev stacks would have to 
be added. Rev is so much more feature-rich than hyperCard that it 
might not be realistic, though. It would depend on the Rev stack that 
needed rebuilding. Some use more Rev features than others.

I hear-tell that nobody has written a Rev stack like this because Rev 
stacks rarely become corrupted.

Opinion poll: Have I seen the worst of these anomalies? What are the 
chances that they are a portent of worse things to come?

I agree with Dan. HC-->Rev is a marvel. I must take care to avoid 
future nightmares, though. I'm a do-it-yourself end-user, I depend on 
these stacks, and my ability to solve software problems is limited. 
Once they work right, I depend on them to keep on working right, year 
after year.


Cheers,


Tim



More information about the use-livecode mailing list