Geoff, et al.,
Interesting and reasonable suggestions.
Where to store the data?
I always go back and forth on whether or not to store information in
the object or keep yet another local database of data for objects in
the session. The formatting of scripts, for instance, is kept local
to
Jerry,
I could easily see the utility of displaying only the globals that
are within the scope of the handler that is being debugged. Perhaps,
the watch list could have an option to automatically add (display)
all currently declared globals.
Dennis
On Dec 24, 2005, at 10:39 AM, Jerry
Dennis,
Good idea. YAP - Yet Another Preference. I've got the process of
adding prefs down to a science, now. It can take as little as 15
minutes.
Best,
Jerry Daniels
Tool makers for the 21st century
http://www.daniels-mara.com/products
On Dec 24, 2005, at 9:55 AM, Dennis Brown
I just modified my var watcher prototype to only show pertinent
globals and WOW what a difference THAT makes. Far less clutter, at
least from my point of view.
Best,
Jerry Daniels
Tool makers for the 21st century
http://www.daniels-mara.com/products
On Dec 24, 2005, at 9:55 AM,
Jerry-
Saturday, December 24, 2005, 10:03:29 AM, you wrote:
Good idea. YAP - Yet Another Preference. I've got the process of
adding prefs down to a science, now. It can take as little as 15
minutes.
Where you might want to display all globals is the case where you've
made a typo in the
Mark,
Good reason to have a folder of globals not being used in current
handler.
Best,
Jerry Daniels
Tool makers for the 21st century
http://www.daniels-mara.com/products
On Dec 24, 2005, at 2:29 PM, Mark Wieder wrote:
Jerry-
Saturday, December 24, 2005, 10:03:29 AM, you wrote:
Question for Variable Watching folks:
Why do we want a list of watched variables?
I ask this because I only want to see them if their value changes.
What if any value that changes is hilited?
That approach would be far more economical (processing time, and real
estate) AND I think it gives
The distinction in many debuggers is that a Watched variable causes
execution to pause (creates a breakpoint) whenever its value changes
-- as opposed to displaying its value, changed or not, whenever
something else (a breakpoint) pauses execution. Naturally a Watch
in that sense slows
Yes please, I'd like to give it a go. I haven't contributed to this
debate because I don't feel strongly about the VW the way some do, but
when in Constellation, it irks to have to step outside to use the
variable watcher. It fees like it should be part of the same window,
perhaps replacing some
As Charles said, true watched variables' are those being tracked
intensively and define a breakpoint, but VW is more like an 'inspector',
therefore I think you mean...
.. if any of the inspector-visible variables change, they are updated and
highlighted, rather than update all each cycle.
Yes,
Jerry,
The reason I wanted a watched variables folder was not because I
expected execution to stop if any value changed, it was because I
have so many variables, that I wanted to reduce the widow area needed
to see all the variables I needed to see in order to debug the
suspect area of a
Sarah,
As I said below, the Variable watcher I was talking about is not
embedded yet, but is freestanding.
Best,
Jerry Daniels
Tool makers for the 21st century
http://www.daniels-mara.com/products
On Dec 24, 2005, at 7:47 PM, Sarah Reichelt wrote:
Yes please, I'd like to give it a
It seems there are two requests...
- one to make a variable whose value has just changed to be easy to
see and
- another to stop execution, like a breakpoint.
Right?
Best,
Jerry Daniels
Tool makers for the 21st century
http://www.daniels-mara.com/products
On Dec 24, 2005, at 8:09
On 12/24/05 7:30 PM, Jerry Daniels [EMAIL PROTECTED] wrote:
It seems there are two requests...
- one to make a variable whose value has just changed to be easy to
see and
yes
- another to stop execution, like a breakpoint.
(not for me)
I care less about auto stop, since I have rarely used
I think (though I've certainly never written a debugger) that true
watch-points would be a whole lot harder to write. And they're by no
means as often useful. I'd let that go at least for now.
Charles
On Dec 24, 2005, at 10:30 PM, Jerry Daniels wrote:
It seems there are two requests...
Jerry-
Saturday, December 24, 2005, 7:30:31 PM, you wrote:
It seems there are two requests...
- one to make a variable whose value has just changed to be easy to
see and
- another to stop execution, like a breakpoint.
Setting a breakpoint when a watched variable hits a given value is
Apropos of this long (and very interesting) public conversation with
Jerry Daniels - I was in it at the beginning but have now been
swallowed whole by a family Christmas... however, in the discussion
as to how to refer to a calling script I didn't see an idea close to
my heart, which is a
Graham,
Not interested in marginally useful information?
I know it's the holiday season and all that, but I'm afraid this lack
of passion for useless detail in a debugger will have to be noted in
your permanent record.
It's a well known fact that attention to these sorts of details keep
On Dec 22, 2005, at 8:24 AM, Jerry Daniels wrote:
- new var watcher features
+ calling path
= drop down menu at top with calling path item in each
line of menu
In my dream version of this, it wouldn't be a drop down menu, which
forces you to take action to see what's
On Dec 22, 2005, at 8:31 AM, Jerry Daniels wrote:
At some point, doesn't it get easier just to write the expression
in the scripting environs, rather than working around you elbow so
see it in the var watcher?
Yes, but not if you're in the middle of debugging something.
On Dec 22, 2005, at 9:53 AM, Jerry Daniels wrote:
In either scenario, indented items would be capable of collapse and
expand functionality via disclosure triangles.
Whadda ya think?
However you like. The crucial thing for me would be to call out a
list of variables for special
On Dec 22, 2005, at 10:24 AM, Jerry Daniels wrote:
Right! Folder of watched vars would be possible. HOWEVER I will
then have to save those watched vars as a custom prop in the object.
How to create a watched var: drag a var into the watch folder.
Caveat: no folders no watched vars. Can't
Saving the watched set with the object is useful, because you may
have more than one project you are working on and debugging. It is
nice to start up where you left off --when rev crashes due to some
horrible bug in your code.
On the other hand, if you keep most of your handlers in a
On Dec 23, 2005, at 12:15 PM, Dennis Brown wrote:
Saving the watched set with the object is useful, because you may
have more than one project you are working on and debugging. It is
nice to start up where you left off --when rev crashes due to some
horrible bug in your code.
The
Mark Wieder wrote:
Alex-
Wednesday, December 21, 2005, 5:52:40 PM, you wrote:
- make it an expression watcher - i.e. allow the user to specify an
expression to evaluate display
Click in the gray column to the left of the variable name...
That brings up a dialog which allows me
Colleagues,
I'm encouraged by your enthusiasm for an embedded var watcher in
Constellation to replace the Rev Var watcher palette that we now use.
Here's what I'm proposing to do:
- inclusion of an embedded var watcher in Constellation as opposed to
using Rev's as a separate palette
-
Alex,
Sounds like we could use a preference for VW calling path verbosity.
Thanks for the encouragement.
Best,
Jerry Daniels
Tool makers for the 21st century
http://www.daniels-mara.com/products
On Dec 21, 2005, at 7:52 PM, Alex Tweedly wrote:
Jerry Daniels wrote:
Dick,
I threw
Alex, et al.,
At some point, doesn't it get easier just to write the expression in
the scripting environs, rather than working around you elbow so see
it in the var watcher?
Best,
Jerry Daniels
Tool makers for the 21st century
http://www.daniels-mara.com/products
On Dec 22, 2005,
An exciting prospect for the New Year!
Charles
On Dec 22, 2005, at 11:24 AM, Jerry Daniels wrote:
Colleagues,
I'm encouraged by your enthusiasm for an embedded var watcher in
Constellation to replace the Rev Var watcher palette that we now use.
Here's what I'm proposing to do:
-
Jerry,
One of the things I consider inconvenient in the Var Watcher today,
is that if you have a lot of variables (globals), the list is too
long and you end up scrolling all over the place to find the
variables of interest. I would welcome having a way to auto scroll
and highlight the
Good idea for the focus variables.. I know that I end up with a long list
and always seem to want to watch a few variables that start with
a,f,g,m,r,s,t,w,z in the actual order of z,a,w,f,t,g,s,a,z,a,t,... yuk
My suggestion to Jerry was that we have a left column for toggling focus
variables that
Jerry-
Thursday, December 22, 2005, 8:24:55 AM, you wrote:
Colleagues,
I'm encouraged by your enthusiasm for an embedded var watcher in
Constellation to replace the Rev Var watcher palette that we now use.
Here's what I'm proposing to do:
...and since you're taking requests...
I'd
on this.
Paul Looney
-Original Message-
From: Jerry Daniels [EMAIL PROTECTED]
To: How to use Revolution use-revolution@lists.runrev.com
Sent: Thu, 22 Dec 2005 10:24:55 -0600
Subject: Re: Debugging and the execution path
Colleagues,
I'm encouraged by your enthusiasm for an embedded var watcher
Alex-
Thursday, December 22, 2005, 2:29:33 AM, you wrote:
That brings up a dialog which allows me to specify a Stop condition.
Useful, but quite different from what I want.
Agreed, but probably as good as it gets for now.
--
-Mark
[EMAIL PROTECTED]
Dennis, et al.,
Thanks for the additional encouragement...can't have too much of that!
In my working prototype if have a layout like this (the Types would
be icons, btw):
var name Type Value
gTabEvent G true
Jerry,
I like the folder idea better. That way I can hide all the globals,
constants, or whatever. It also opens up the possibility to have a
folder of my watched variables of mixed types. ;-)
Dennis
On Dec 22, 2005, at 12:53 PM, Jerry Daniels wrote:
Dennis, et al.,
Thanks for the
Dennis, et al.
Right! Folder of watched vars would be possible. HOWEVER I will then
have to save those watched vars as a custom prop in the object.
How to create a watched var: drag a var into the watch folder.
Caveat: no folders no watched vars. Can't have everything.
Make sense?
Best,
Jerry,
Makes sense to me.
However, you could also have a checkbox next to each variable name if
it is a watched variable.
On the other hand, could it have more than one custom watched
variable folder?
That way we could set up several folders with a different set of
variables for debugging
Jerry-
Thursday, December 22, 2005, 10:24:59 AM, you wrote:
Dennis, et al.
Right! Folder of watched vars would be possible. HOWEVER I will then
have to save those watched vars as a custom prop in the object.
Sounds OK, but I'm not quite sure what the object is here. Do you
mean the object
The object being debugged at that moment...the context object.
Best,
Jerry Daniels
Tool makers for the 21st century
http://www.daniels-mara.com/products
On Dec 22, 2005, at 3:01 PM, Mark Wieder wrote:
Jerry-
Thursday, December 22, 2005, 10:24:59 AM, you wrote:
Dennis, et al.
Pierre, et al...
Assuming you could have a calling path in your debug environs, what
would it look like?
Examples to get you thinking...
1. First call to last call:
card billing machine card: resumeStack / field billings:
mouseUp / card billing machine card: disableAddEditDel
2.
On 12/21/05 9:30 AM, Jerry Daniels [EMAIL PROTECTED] wrote:
Assuming you could have a calling path in your debug environs, what
would it look like?
IMHO, since objects of the same type can have the same name, and objects in
different stacks can have the same abbreviated id, we need the calling
Dick,
I threw together a quick Var Watcher last night that puts the calling
path into a pop up menu above the vars, much like Rev's Var Watcher
does. Each item in the menu looks like this:
stack save test/button Button/handler mouseUp/line: 7
The label of the pop up menu is the
Jerry,
I would love to have a good variable watcher integrated into Constellation.
This is more important to me than the property list. Having everything together
in one place would be most helpful. And the Constellation layout, with the
attached and resizable panels, is almost ideal for
Timidly, I'll weigh in. I don't want the transcript syntax, which is
full of potential snares. (How many newbies -- not this one, anyway
-- can remember when some long string of prepositional phrases needs
a set of parentheses somewhere?) If I'm looking at a stack trace, I
expect to see it
On 12/21/05 2:31 PM, Jerry Daniels [EMAIL PROTECTED] wrote:
stack save test/button Button/handler mouseUp/line: 7
line 7 of handler mouseUp of button button of stack save
test
I guess you mean that each line in the context button's text would identify
the object whose script is
Jerry Daniels wrote:
Dick,
I threw together a quick Var Watcher last night that puts the calling
path into a pop up menu above the vars, much like Rev's Var Watcher
does. Each item in the menu looks like this:
stack save test/button Button/handler mouseUp/line: 7
I find that a bit
Alex-
Wednesday, December 21, 2005, 5:52:40 PM, you wrote:
- make it an expression watcher - i.e. allow the user to specify an
expression to evaluate display
Click in the gray column to the left of the variable name...
--
-Mark Wieder
[EMAIL PROTECTED]
On Dec 20, 2005, at 9:49 AM, J. Landman Gay wrote:
Jacque is having trouble remembering when the last single script
window was the maximum, so can't really make too much trouble for
you. ;) I think that was back in HyperCard 1.0, yes? Like, 20 years
ago?
I have enough windows open when
On Dec 18, 2005, at 9:18 AM, Mark Wieder wrote:
I remember the Bad Old Days when we had only a single script
editing window at a time and I certainly don't want to go back there
again. Keeping the functions separate does make some sense, though.
But the scroll button should be documented.
I
Geoff Canyon wrote:
On Dec 18, 2005, at 9:18 AM, Mark Wieder wrote:
I remember the Bad Old Days when we had only a single script
editing window at a time and I certainly don't want to go back there
again. Keeping the functions separate does make some sense, though.
But the scroll button
Geoff-
Tuesday, December 20, 2005, 7:51:09 AM, you wrote:
I have enough windows open when an app is running, I don't want a
plethora of new ones just because I'm debugging.
I want a purpose-built debugging window that shows variables, the
calling chain, and the currently executing code in
On 12/20/05 10:54 AM, Mark Wieder [EMAIL PROTECTED] wrote:
I think a tabbed script editor window with
tabs for each script you're editing or debugging would suit my needs.
The windows-all-over-the-screen thing gets to be a pain.
This is what you get with Constellation, tabbed in a single
Ho là là !!!
I need to use this feature too, just to avoid some erratic starting
procedures of my rev server's apps under the Mac OS X platform (all
works always fine under the Linux one). I would be very happy to
license the Constellation framework if this tool can help to
automate this
Alex-
Saturday, December 17, 2005, 11:47:26 AM, you wrote:
Hmmm - I kind of disagree with it, so I won't be voting. I sometimes use
the contexts to see the local variables in each context, but don't want
to switch my view of the script (and particularly don't want additional
script windows
On Dec 18, 2005, at 12:18 PM, Mark Wieder wrote:
Indeed yes. I want a full stack trace available. You can modify the
Variable Watcher to do this yourself, of course, but you'd have to do
this with each new release of the IDE.
You can? Did I miss that? To me it would be worth doing even if I
On Sat, 17 Dec 2005 21:41:32 +, Alex Tweedly [EMAIL PROTECTED]
wrote:
graham samuel wrote:
On Sat, 17 Dec 2005 16:49:19 +, Alex Tweedly [EMAIL PROTECTED]
wrote:
In the Variable Watcher, just to the right of the drop-down menu of
objects/contexts, there is a button like a scroll
Alex-
Saturday, December 17, 2005, 11:47:26 AM, you wrote:
Mark Wieder wrote:
I just tried this on 2.5, and when it hits a breakpoint, the bottom
section of the script window shows the Step Into, Step Over, ,
Abort and so the Go to box and button are no longer accessible. Is
there
graham-
Sunday, December 18, 2005, 9:32:16 AM, you wrote:
another, the cursor isn't set... I'd be happier if I could find some
official documentation for all this. I sure hope there is some, not
Nay, not so. Didn't even make it into the release notes.
Yep, but I would have had to write down
I heard that. Email me, Charles...let's see what we can do.
Best,
Jerry Daniels
Tool makers for the 21st century
http://www.daniels-mara.com/products
On Dec 18, 2005, at 11:19 AM, Charles Hartman wrote:
On Dec 18, 2005, at 12:18 PM, Mark Wieder wrote:
Indeed yes. I want a full stack
On 12/18/05 10:16 PM, Jerry Daniels [EMAIL PROTECTED] wrote:
I heard that. Email me, Charles...let's see what we can do.
In case you're still collecting ideas, I'd like to add a few based on my own
repeatedly-installed-through-the-upgrades hacks of the Variable Watcher.
I have other hacks for
Folks, for years I've been debugging Rev projects with what I now
realise is a rather poor subset of the available facilities:
basically I have set breakpoints, stepped through code using the
debugger, and looked at variables using the Variable Watcher.
Now however I have a tricky 'how did
graham samuel wrote:
Folks, for years I've been debugging Rev projects with what I now
realise is a rather poor subset of the available facilities:
basically I have set breakpoints, stepped through code using the
debugger, and looked at variables using the Variable Watcher.
Now however I
Alex-
Saturday, December 17, 2005, 8:49:19 AM, you wrote:
Also, in the script editor, you can use the menu View / Go to line ...
to go to a line number. Unfortunately, you can't do that while in
debugger mode - the whole View menu is not enabled at that point.
Interesting. This was possible
Mark Wieder wrote:
Alex-
Saturday, December 17, 2005, 8:49:19 AM, you wrote:
Also, in the script editor, you can use the menu View / Go to line ...
to go to a line number. Unfortunately, you can't do that while in
debugger mode - the whole View menu is not enabled at that point.
On Sat, 17 Dec 2005 16:49:19 +, Alex Tweedly [EMAIL PROTECTED]
wrote:
In the Variable Watcher, just to the right of the drop-down menu of
objects/contexts, there is a button like a scroll of paper.
Clicking on
that will take you to the script line of the currently selected
context.
graham samuel wrote:
On Sat, 17 Dec 2005 16:49:19 +, Alex Tweedly [EMAIL PROTECTED]
wrote:
In the Variable Watcher, just to the right of the drop-down menu of
objects/contexts, there is a button like a scroll of paper. Clicking on
that will take you to the script line of the currently
67 matches
Mail list logo
