debugger anomaly updated

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

debugger anomaly updated

Timothy Miller-2
The debugger anomaly in my stacks has been discussed on the list over
the past few days. In brief, the debugger will debug a stack script,
but not a background script. In a bg script, the script window does
open, but the script window remains behind the others and the script
does not pause.

I can force a pause and bring the script window to the front by
deliberately placing an error in the bg script. When the script
pauses and the error window opens, I click on the "debug" button on
the error window. When the script window opens, the debug buttons in
the script window are absent, and the debug menu items are dimmed
out. As far as I can tell, the script won't resume. All I can to is
remove the bad line and save.

When scripts are moved from the bg script to the stack script, the
debugger works normally.

Further testing reveals -- tentatively -- that this anomaly only
appears in my stacks whose original ancestors were created in an
early version of hyperCard, possibly 1.0. Unfortunately, I have about
five of them, fairly large, complex, and very important.

My stacks that were originally created in recent versions of
hyperCard, or Rev, do not have this anomaly.

A week before, there was discussion of another anomaly I struggled
with -- "mark cards by finding..." I won't go into the details. I'd
guess this also ultimately arose from funky data left over from the
earliest versions of hyperCard.

Maybe it's nothing I need to worry about. I can find other ways to
debug bg scripts when I need to. I only wonder about what other
anomalies might lie ahead.

Thanks to the list for all the help and encouragement.

Tim
_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
Reply | Threaded
Open this post in threaded view
|

Re: debugger anomaly updated

Alex Tweedly
Timothy Miller wrote:

> The debugger anomaly in my stacks has been discussed on the list over
> the past few days. In brief, the debugger will debug a stack script,
> but not a background script. In a bg script, the script window does
> open, but the script window remains behind the others and the script
> does not pause.
>
> I can force a pause and bring the script window to the front by
> deliberately placing an error in the bg script. When the script pauses
> and the error window opens, I click on the "debug" button on the error
> window. When the script window opens, the debug buttons in the script
> window are absent, and the debug menu items are dimmed out. As far as
> I can tell, the script won't resume. All I can to is remove the bad
> line and save.
>
> When scripts are moved from the bg script to the stack script, the
> debugger works normally.
>
> Further testing reveals -- tentatively -- that this anomaly only
> appears in my stacks whose original ancestors were created in an early
> version of hyperCard, possibly 1.0. Unfortunately, I have about five
> of them, fairly large, complex, and very important.
>
> My stacks that were originally created in recent versions of
> hyperCard, or Rev, do not have this anomaly.
>
Would it be at all possible to write a stack that would "export" another
stack to some textual format, and then another which would "import" it
again (i.e. into a new clean stack)?

I know the general problem is hard - but I also know that my own stacks
tend to follow certain patterns (combination of me getting in a rut, and
the fact that I only know about 10% of what Rev can do), so it *might*
be feasible to write such a tool that would work for my stacks.

You probably wouldn't want to write a *product* to do that - but you
might be able to write *tool* to do it.

--
Alex Tweedly       http://www.tweedly.net



--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.323 / Virus Database: 267.8.12/46 - Release Date: 11/07/2005

_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
Reply | Threaded
Open this post in threaded view
|

Re: debugger anomaly updated

Jon-3
Sounds like a great suggsetion, Alex! If the output were in text form
(or XML?), you could even edit it if there were problems (like non
printable characters in names, etc).  A simple (ha!) import/export stack
for stacks!

:)

Jon


Alex Tweedly wrote:

> Timothy Miller wrote:
>
>> The debugger anomaly in my stacks has been discussed on the list over
>> the past few days. In brief, the debugger will debug a stack script,
>> but not a background script. In a bg script, the script window does
>> open, but the script window remains behind the others and the script
>> does not pause.
>>
>> I can force a pause and bring the script window to the front by
>> deliberately placing an error in the bg script. When the script
>> pauses and the error window opens, I click on the "debug" button on
>> the error window. When the script window opens, the debug buttons in
>> the script window are absent, and the debug menu items are dimmed
>> out. As far as I can tell, the script won't resume. All I can to is
>> remove the bad line and save.
>>
>> When scripts are moved from the bg script to the stack script, the
>> debugger works normally.
>>
>> Further testing reveals -- tentatively -- that this anomaly only
>> appears in my stacks whose original ancestors were created in an
>> early version of hyperCard, possibly 1.0. Unfortunately, I have about
>> five of them, fairly large, complex, and very important.
>>
>> My stacks that were originally created in recent versions of
>> hyperCard, or Rev, do not have this anomaly.
>>
> Would it be at all possible to write a stack that would "export"
> another stack to some textual format, and then another which would
> "import" it again (i.e. into a new clean stack)?
>
> I know the general problem is hard - but I also know that my own
> stacks tend to follow certain patterns (combination of me getting in a
> rut, and the fact that I only know about 10% of what Rev can do), so
> it *might* be feasible to write such a tool that would work for my
> stacks.
>
> You probably wouldn't want to write a *product* to do that - but you
> might be able to write *tool* to do it.
>
_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
Reply | Threaded
Open this post in threaded view
|

Re: debugger anomaly updated

Dan Shafer
In reply to this post by Timothy Miller-2
Timothy....

I suspect you'd agree that the amazing thing isn't that you had a few  
anomalies, it's that converting from HC to Rev was even remotely  
possible in a semi-automatic way.


On Jul 13, 2005, at 2:17 PM, Timothy Miller wrote:

> Further testing reveals -- tentatively -- that this anomaly only  
> appears in my stacks whose original ancestors were created in an  
> early version of hyperCard, possibly 1.0. Unfortunately, I have  
> about five of them, fairly large, complex, and very important.
>
> My stacks that were originally created in recent versions of  
> hyperCard, or Rev, do not have this anomaly.
>


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Shafer, Revolution Consultant and Author
http://www.shafermedia.com
Get my book, "Revolution: Software at the Speed of Thought"
 From http://www.shafermedia.com/revolutionbooks.html




_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
Reply | Threaded
Open this post in threaded view
|

Re: debugger anomaly updated

Richard Gaskin
In reply to this post by Alex Tweedly
Alex Tweedly wrote:

> Would it be at all possible to write a stack that would "export" another
> stack to some textual format, and then another which would "import" it
> again (i.e. into a new clean stack)?
>
> I know the general problem is hard - but I also know that my own stacks
> tend to follow certain patterns (combination of me getting in a rut, and
> the fact that I only know about 10% of what Rev can do), so it *might*
> be feasible to write such a tool that would work for my stacks.
>
> You probably wouldn't want to write a *product* to do that - but you
> might be able to write *tool* to do it.

Amen to that. Years ago I started work on a project I called
"RosettaCard", which would have been a universal file format with
importers and exporters for all xTalks in common use.  What I found is
that it's a lot of work for little return:  such things are generally
only needed once, and there are just enough differences in syntax,
object model, properties, etc. that an inordinate amount of time gets
spent managing those differences.

If one needs to do this for just Rev I believe Geoff Canyon wrote one,
and there are likely others lying around.

But perhaps simpler for this case might be to just strip all the cRev
custom properties. Chipp has a tool for that, and those are the only
places where flags could be stored which would affect debugging behavior
(other than in the IDE itself, of course, but then that's a project for
RunRev rather than us <g>).

--
  Richard Gaskin
  Fourth World Media Corporation
  ___________________________________________________________
  [hidden email]       http://www.FourthWorld.com
_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
Reply | Threaded
Open this post in threaded view
|

Re: debugger anomaly updated

mwieder
In reply to this post by Alex Tweedly
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
 [hidden email]

_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
--
 Mark Wieder
 ahsoftware@gmail.com
Reply | Threaded
Open this post in threaded view
|

Re: debugger anomaly updated

Timothy Miller-2
>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
>  [hidden email]

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
_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
Reply | Threaded
Open this post in threaded view
|

Re: debugger anomaly updated

J. Landman Gay
On 7/13/05 9:02 PM, Timothy Miller wrote:

> 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.

If you are thinking of the "Recover" stack, that didn't do what Alex is
describing. It just did a straight card copy from the old stack to the
new. When it hit a bad card and crashed, it picked up on restart at the
next card and kept on copying. It didn't recreate objects.

In the case of badly formed HC stacks, copying cards might just copy the
bad parts along with the rest of the card and you'd be back where you
started. Also, copying cards can create duplicate backgrounds (as it
often did in HC) which isn't what you'd want.

Recreating objects individually from scratch by using a saved
description probably would work fine, as long as the model placed
background groups correctly.

--
Jacqueline Landman Gay         |     [hidden email]
HyperActive Software           |     http://www.hyperactivesw.com
_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
Reply | Threaded
Open this post in threaded view
|

Re: debugger anomaly updated

J. Landman Gay
In reply to this post by Richard Gaskin
On 7/13/05 5:47 PM, Richard Gaskin wrote:

> But perhaps simpler for this case might be to just strip all the cRev
> custom properties. Chipp has a tool for that, and those are the only
> places where flags could be stored which would affect debugging behavior
> (other than in the IDE itself, of course, but then that's a project for
> RunRev rather than us <g>).
>

In this particular case, I think the problem is due to an incorrect HC
import. The stack file structure on disk isn't right; the contents of
the stack (properties, data, etc) aren't the problem. I've seen this
occasionally with very old HC stacks. Apple changed the file format
between HC 1.0 and 2.0. Stacks that were converted from 1.0 to 2.0 may
have junk bits in the file that HC could deal with, but Rev can't.

I have seen this kind of badly formed HC import only two or three times.
It is pretty rare and usually Rev does a good job with the import. But
when nutty things like this debugging weirdness show up, I suspect the
stack structure. So far these cases have been HC stacks that have been
through any number of HC versions and then imported into Rev.

--
Jacqueline Landman Gay         |     [hidden email]
HyperActive Software           |     http://www.hyperactivesw.com
_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution