Re: [OT] Re: [ANN] tRev's new 'decoder' now showing...video is up!

2009-08-26 Thread Jerry Daniels

Robert,

I like the idea of creating reports using data from tRev breakpoints-- 
as you and others are suggesting. Time would be a natural parameter  
for such reports. Reports can be sequestered from the general workflow  
of the app, also. So I am in favor of it, given enough time and sales  
to warrant and allow it.


As I said in previous posts, I think more actual use of the Decoder  
precedes any significant changes to it--given my release schedule.


Best,

Jerry Daniels
Watch tRev - The Movie
http://reveditor.com/trev-the-movie

On Aug 26, 2009, at 10:24 AM, Robert Maniquant wrote:



Food for thoughts..

Hi, I also rely heavily on "put" as soon as I notice a problem  
arise. I like
to follow what's happening ("into handler ZZ" "with value of  
EE=zz" ) I
dreamed of an "aware" decoder which would allow me just a) select a  
few

variables (among global, handlers and function parameters, internal
variables) b) review their history along the time-line. This  
timeLine would
be in 2D : horizontal axis would be time and the sequence of  
handlers where

the variables selected appear, plus maye be a systematic report on
parameters variables ; vertical axis would allow to report loops  
values of

these variables where needed.

it might be more simple to list time line vertically and provide a  
pop box

for loops reports, the basis idea is to have 2D somehow!

Any thoughts?

Robert Maniquant


Brian Yennie wrote:



1) Click on a variable name to "decode" it. tRev automagically sets
invisible (to me) breakpoints wherever that variable is used. You
could give some visual indicator (for instance, background color
change).

2) Run the script

3) View my script -- mouseover any instance of that variable and I  
get

the value at that point in the script.




--
View this message in context: 
http://www.nabble.com/-ANN--tRev%27s-new-%27decoder%27-now-showing...video-is-up%21-tp25138263p25151423.html
Sent from the Revolution - User mailing list archive at Nabble.com.

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your  
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-revolution


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: [OT] Re: [ANN] tRev's new 'decoder' now showing...video is up!

2009-08-26 Thread Robert Maniquant

Food for thoughts.. 

Hi, I also rely heavily on "put" as soon as I notice a problem arise. I like
to follow what's happening ("into handler ZZ" "with value of EE=zz" ) I
dreamed of an "aware" decoder which would allow me just a) select a few
variables (among global, handlers and function parameters, internal
variables) b) review their history along the time-line. This timeLine would
be in 2D : horizontal axis would be time and the sequence of handlers where
the variables selected appear, plus maye be a systematic report on
parameters variables ; vertical axis would allow to report loops values of
these variables where needed.

it might be more simple to list time line vertically and provide a pop box
for loops reports, the basis idea is to have 2D somehow! 

Any thoughts?

Robert Maniquant


Brian Yennie wrote:
> 
> 
> 1) Click on a variable name to "decode" it. tRev automagically sets  
> invisible (to me) breakpoints wherever that variable is used. You  
> could give some visual indicator (for instance, background color  
> change).
> 
> 2) Run the script
> 
> 3) View my script -- mouseover any instance of that variable and I get  
> the value at that point in the script.
> 
> 

-- 
View this message in context: 
http://www.nabble.com/-ANN--tRev%27s-new-%27decoder%27-now-showing...video-is-up%21-tp25138263p25151423.html
Sent from the Revolution - User mailing list archive at Nabble.com.

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: [OT] Re: [ANN] tRev's new 'decoder' now showing...video is up!

2009-08-26 Thread Jerry Daniels

Dick,

I wise man told me: when in doubt, leave it out.

I'm in doubt. I really do want to keep tRev simple. It's breakpoints  
are easy enough to spot for now.


--> simplicity: http://reveditor.com/avoiding-big-and-complicated-in-trev

Meantime I _will_ do the following:

1. Get our new Raptor feature ready for Feature Friday.

This feature is more game-changing than Decoder. In fact, most of it  
is already in tRev. It is so obvious that I doubt anyone will find it.  
Hehehe. It's one of those inventions that will be used in ways I'm  
sure I've never imagined.


--> live webinar: https://www2.gotomeeting.com/join/249440650

2. I will be thinking about all these cool ideas you and others have  
made for tRev breakpoints as I finish-up Raptor.


Once Raptor is out, we will be feature complete. Then, I will optimize  
and thoroughly debug tRev, getting rid of excess code, etc., and  
release it, giving out brand-new one year reg codes.


After release, I'll probably have some thoughts about breakpoints  
because we will all have had some time using them.


Funding for development is always an issue, so...let's see if we can't  
get at least 500 people using tRev before Fall comes. Right now we're  
at 108!


--> buy tRev: http://runrev.com/products/related-software/trev-editor/

Best,

Jerry Daniels
Watch tRev - The Movie
http://reveditor.com/trev-the-movie

On Aug 26, 2009, at 2:22 AM, Dick Kriesel wrote:


Thanks, Jerry, and you're welcome.

The behavior of your breakpoint is so different from Rev's that I can
imagine wanting to use both.  So I'd prefer you to distinguish the  
two:
breakpoint and, say, tRev_checkpoint.  uRIP resolves the name space  
thing.


tRev, instead of inserting the string "breakpoint," could insert a
one-liner:

if "tRev" is among the lines of the stacksInUse then tRev_checkpoint

or, less obtrusively,

try; tRev_checkpoint; end try

Would that work for you?

-- Dick


On 8/25/09 4:55 PM, "Jerry Daniels"  wrote:


Hey, Dick! Good to hear from you.

I would need to deal with the whole name space thing...if some other
program used checkpoint, etc.

Using "breakpoint" has two sizeable advantages over alternatives (now
that I'm really considering your suggestion):

1. I don't have to worry about another program using it.

2. It has a use when tRev is not in use. E.g., when you give someone
else your code and they don't have tRev (because of a religious
injunction or something).

Great idea, though. I'll play around with it some. Thanks.

Best,

Jerry Daniels
Watch tRev - The Movie
http://reveditor.com/trev-the-movie

On Aug 25, 2009, at 6:40 PM, Dick Kriesel wrote:


On 8/25/09 3:18 PM, "Jerry Daniels"  wrote:


I agree TOTALLY with the request, but alas, Rev forbids it.


Hi, Jerry.  Could you proceed without Rev's traceback message?

on mouseUp
  put 1 into t1
  put 2 into t2
  checkPoint
end mouseUp

command checkPoint
  set the debugcontext to line -2 of the executioncontexts
  global gREVVariableWatcherValue
  debugdo "revDebuggerGrabValue the variableNames"
  repeat for each item tVariableName in line 2 of
gREVVariableWatcherValue
debugdo "revDebuggerGrabValue" && tVariableName
put gREVVariableWatcherValue into tVariables[tVariableName]
  end repeat
  set the debugcontext to empty
  -- ... "store the full context into a database"

  breakpoint -- just so you can see tVariables[]
end checkPoint


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your  
subscription

preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution



___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your  
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-revolution


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: [OT] Re: [ANN] tRev's new 'decoder' now showing...video is up!

2009-08-26 Thread Sarah Reichelt
> Personally, I prefer the simplest approach. I can remember what the word
> 'breakpoint' means, not sure if I can remember alexpoint, or lenpoint, or
> some sort of fancy graphic which shows up in a funny color on my Vista
> computer.

I agree with this. And I wouldn't want any accidental "lenpoints"
causing problems for people who use my scripts and don't use tRev.
I don't think Jerry should be adding tokens to Rev, but just
leveraging the existing ones as he is already.

Congratulations Jerry - I think you just made debugging a whole lot
easier and more reliable.

Cheers,
Sarah
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: [OT] Re: [ANN] tRev's new 'decoder' now showing...video is up!

2009-08-26 Thread Chipp Walters
Jerry,
Most cool-- way to go with some serious out of the box thinking on this one.

Personally, I prefer the simplest approach. I can remember what the word
'breakpoint' means, not sure if I can remember alexpoint, or lenpoint, or
some sort of fancy graphic which shows up in a funny color on my Vista
computer.

You are of course correct in aspiring to terse features, terse terminology,
and terse architecture when creating an IDE for Rev. You've already
successfully navigated the most complex script editors every created for an
Xtalk, and have, I assume, a new-found passion for the simple.

Even so, making things simple is sometimes the hardest to do. Great job.
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: [OT] Re: [ANN] tRev's new 'decoder' now showing...video is up!

2009-08-26 Thread Dick Kriesel
Thanks, Jerry, and you're welcome.

The behavior of your breakpoint is so different from Rev's that I can
imagine wanting to use both.  So I'd prefer you to distinguish the two:
breakpoint and, say, tRev_checkpoint.  uRIP resolves the name space thing.

tRev, instead of inserting the string "breakpoint," could insert a
one-liner:

if "tRev" is among the lines of the stacksInUse then tRev_checkpoint

or, less obtrusively,

try; tRev_checkpoint; end try

Would that work for you?

-- Dick


On 8/25/09 4:55 PM, "Jerry Daniels"  wrote:

> Hey, Dick! Good to hear from you.
> 
> I would need to deal with the whole name space thing...if some other
> program used checkpoint, etc.
> 
> Using "breakpoint" has two sizeable advantages over alternatives (now
> that I'm really considering your suggestion):
> 
> 1. I don't have to worry about another program using it.
> 
> 2. It has a use when tRev is not in use. E.g., when you give someone
> else your code and they don't have tRev (because of a religious
> injunction or something).
> 
> Great idea, though. I'll play around with it some. Thanks.
> 
> Best,
> 
> Jerry Daniels
> Watch tRev - The Movie
> http://reveditor.com/trev-the-movie
> 
> On Aug 25, 2009, at 6:40 PM, Dick Kriesel wrote:
> 
>> On 8/25/09 3:18 PM, "Jerry Daniels"  wrote:
>> 
>>> I agree TOTALLY with the request, but alas, Rev forbids it.
>> 
>> Hi, Jerry.  Could you proceed without Rev's traceback message?
>> 
>> on mouseUp
>>put 1 into t1
>>put 2 into t2
>>checkPoint
>> end mouseUp
>> 
>> command checkPoint
>>set the debugcontext to line -2 of the executioncontexts
>>global gREVVariableWatcherValue
>>debugdo "revDebuggerGrabValue the variableNames"
>>repeat for each item tVariableName in line 2 of
>> gREVVariableWatcherValue
>>  debugdo "revDebuggerGrabValue" && tVariableName
>>  put gREVVariableWatcherValue into tVariables[tVariableName]
>>end repeat
>>set the debugcontext to empty
>>-- ... "store the full context into a database"
>> 
>>breakpoint -- just so you can see tVariables[]
>> end checkPoint
>> 
>> 
>> ___
>> use-revolution mailing list
>> use-revolution@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-revolution
> 
> ___
> use-revolution mailing list
> use-revolution@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: [OT] Re: [ANN] tRev's new 'decoder' now showing...video is up!

2009-08-25 Thread Jerry Daniels
I have indeed done something very similar to this. It was called a pre- 
compiler. Is it worth it for a word? What is really gained? What is  
the benefit? There is a cost to everything we do, of course.


On Aug 25, 2009, at 10:08 PM, Len Morgan wrote:

If it's all about "text", could you not replace the DISPLAYED word  
"Breakpoint" to "LenPoint" ONLY IN THE TREV DISPLAY.  Leave the  
"real" word as breakpoint when you save the file but when you show  
me the script, just do a global substitution.  Everybody's happy.

Just a thought...

len morgan

Jerry Daniels wrote:
I don't really think the breakpoint terminology will hurt and it  
does help with cross-editor considerations, etc.


Code is all about text, afterall.

Best,

Jerry Daniels
Watch tRev - The Movie
http://reveditor.com/trev-the-movie

On Aug 25, 2009, at 8:15 PM, Brian Yennie wrote:


Jerry,

I was thinking more of an inline image than the Rev "dot" next to  
a line. It would occupy a line of its own. Doesn't make much of a  
difference to me, but seemed like an alternative to the concerns  
about terminology. For example:


on mouseUp
 put 1 into someVar
 BREAKPOINT #1386243
 doSomething
end mouseUp

would become:

on mouseUp
 put 1 into someVar
 ===> #1386243
end mouseUp

Where the "=>" is an actual image.

Basically, it was just a middle ground between changing the name  
of breakpoints and going back to red dots =).



Brian,

Have you ever noticed the dots in Rev's debugger? How, if your  
script has very many lines at all, the dots can't keep pace with  
scrolling, returns, etc.? I have. Not pretty, to say the least.  
So, no images floating around for me, thank you.


Also, keeping a separate array of breakpoints and keeping them in  
sync with the actual code is not easy in a world where tRev is  
not the only script editor. I used to have lots of these sorts of  
"proprietary" approaches. It always came back to bite me in the  
behind when people traded code with others or used more than one  
editor.


So, a couple years ago, i decided to use text to indicate a  
breakpoint. Easy to see, easy to delete, follows the code  
wherever it goes, never gets out of sync. It's all good. Now that  
we've added record id's as comments following the word  
"breakpoint", we can attach loads of data to a breakpoint.


I'm warming up to the idea, too! I think everyone needs to buy  
the product now!!


Best,

Jerry Daniels
Watch tRev - The Movie
http://reveditor.com/trev-the-movie

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your  
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-revolution


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your  
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-revolution



___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your  
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-revolution


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: [OT] Re: [ANN] tRev's new 'decoder' now showing...video is up!

2009-08-25 Thread Len Morgan
If it's all about "text", could you not replace the DISPLAYED word 
"Breakpoint" to "LenPoint" ONLY IN THE TREV DISPLAY.  Leave the "real" 
word as breakpoint when you save the file but when you show me the 
script, just do a global substitution.  Everybody's happy. 


Just a thought...

len morgan

Jerry Daniels wrote:
I don't really think the breakpoint terminology will hurt and it does 
help with cross-editor considerations, etc.


Code is all about text, afterall.

Best,

Jerry Daniels
Watch tRev - The Movie
http://reveditor.com/trev-the-movie

On Aug 25, 2009, at 8:15 PM, Brian Yennie wrote:


Jerry,

I was thinking more of an inline image than the Rev "dot" next to a 
line. It would occupy a line of its own. Doesn't make much of a 
difference to me, but seemed like an alternative to the concerns 
about terminology. For example:


on mouseUp
  put 1 into someVar
  BREAKPOINT #1386243
  doSomething
end mouseUp

would become:

on mouseUp
  put 1 into someVar
  ===> #1386243
end mouseUp

Where the "=>" is an actual image.

Basically, it was just a middle ground between changing the name of 
breakpoints and going back to red dots =).



Brian,

Have you ever noticed the dots in Rev's debugger? How, if your 
script has very many lines at all, the dots can't keep pace with 
scrolling, returns, etc.? I have. Not pretty, to say the least. So, 
no images floating around for me, thank you.


Also, keeping a separate array of breakpoints and keeping them in 
sync with the actual code is not easy in a world where tRev is not 
the only script editor. I used to have lots of these sorts of 
"proprietary" approaches. It always came back to bite me in the 
behind when people traded code with others or used more than one 
editor.


So, a couple years ago, i decided to use text to indicate a 
breakpoint. Easy to see, easy to delete, follows the code wherever 
it goes, never gets out of sync. It's all good. Now that we've added 
record id's as comments following the word "breakpoint", we can 
attach loads of data to a breakpoint.


I'm warming up to the idea, too! I think everyone needs to buy the 
product now!!


Best,

Jerry Daniels
Watch tRev - The Movie
http://reveditor.com/trev-the-movie

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your 
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-revolution


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your 
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-revolution



___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: [OT] Re: [ANN] tRev's new 'decoder' now showing...video is up!

2009-08-25 Thread Jerry Daniels

Thanks, Brian.

Best,

Jerry Daniels
Watch tRev - The Movie
http://reveditor.com/trev-the-movie

On Aug 25, 2009, at 8:18 PM, Brian Yennie wrote:

Always my favorite confirmation that something is worth pursuing --  
when multiple people dream it up independently =).


I honestly don't have any current Rev projects right now, but I'll  
keep my eye fixed on tRev for the next one that comes along! And  
since we seem to be on the "same page", if anything strikes me while  
debugging elsewhere, I'll let ya now... kudos for thinking outside  
the box on this one.



Brian,

Your ideas for where this is going, they mirror my own. Cool.

SO...what're you waitin' for? Also, don't forget to get a mug or a  
tShirt.


Best,

Jerry Daniels
Watch tRev - The Movie
http://reveditor.com/trev-the-movie

On Aug 25, 2009, at 7:19 PM, Brian Yennie wrote:


Jerry,

I was honestly lukewarm about this at first as a heavy user of  
"full" debuggers, but I'm definitely warming up to it. Fact is,  
that about half the time I use a debugger and half the time I just  
litter my scripts with "put" statements. This is a nice middle  
ground approach.


With that said, here is one thing I would personally find very  
cool -- single variable "decode". I picture it like this:


1) Click on a variable name to "decode" it. tRev automagically  
sets invisible (to me) breakpoints wherever that variable is used.  
You could give some visual indicator (for instance, background  
color change).


2) Run the script

3) View my script -- mouseover any instance of that variable and I  
get the value at that point in the script.


I kind of think of it as "vertical debugging" -- often I know what  
variable is going awry and want to ignore all the rest of the  
information. And so instead of adding tons of "put" statements or  
wading through the context of all my other variables, I could very  
quickly pinpoint where things went wrong with that variable by  
clicking once and running.



Alex,

I would love to change the name of our breakpoints to alexpoints  
or lenpoints or kevpoints, but alas, I cannot. Only the keyword  
"breakpoint" will cause the tracebreak message to be sent to  
tRev's frontscript in Rev where it stores the full context into a  
database. It's this data that the decoder then uses in tRev to  
help you fix code with less effort.


I agree TOTALLY with the request, but alas, Rev forbids it. I am  
glad you like the decoder. I just updated it. You will see the  
"update available" link appear in the lower left of tRev editor  
any moment now.


Best,

Jerry Daniels
Watch tRev - The Movie
http://reveditor.com/trev-the-movie

On Aug 25, 2009, at 4:54 PM, Alex Tweedly wrote:

They are not "breakpoints" !  the execution doesn't 'break' when  
it gets to one.

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your  
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-revolution


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: [OT] Re: [ANN] tRev's new 'decoder' now showing...video is up!

2009-08-25 Thread Jerry Daniels
I don't really think the breakpoint terminology will hurt and it does  
help with cross-editor considerations, etc.


Code is all about text, afterall.

Best,

Jerry Daniels
Watch tRev - The Movie
http://reveditor.com/trev-the-movie

On Aug 25, 2009, at 8:15 PM, Brian Yennie wrote:


Jerry,

I was thinking more of an inline image than the Rev "dot" next to a  
line. It would occupy a line of its own. Doesn't make much of a  
difference to me, but seemed like an alternative to the concerns  
about terminology. For example:


on mouseUp
  put 1 into someVar
  BREAKPOINT #1386243
  doSomething
end mouseUp

would become:

on mouseUp
  put 1 into someVar
  ===> #1386243
end mouseUp

Where the "=>" is an actual image.

Basically, it was just a middle ground between changing the name of  
breakpoints and going back to red dots =).



Brian,

Have you ever noticed the dots in Rev's debugger? How, if your  
script has very many lines at all, the dots can't keep pace with  
scrolling, returns, etc.? I have. Not pretty, to say the least. So,  
no images floating around for me, thank you.


Also, keeping a separate array of breakpoints and keeping them in  
sync with the actual code is not easy in a world where tRev is not  
the only script editor. I used to have lots of these sorts of  
"proprietary" approaches. It always came back to bite me in the  
behind when people traded code with others or used more than one  
editor.


So, a couple years ago, i decided to use text to indicate a  
breakpoint. Easy to see, easy to delete, follows the code wherever  
it goes, never gets out of sync. It's all good. Now that we've  
added record id's as comments following the word "breakpoint", we  
can attach loads of data to a breakpoint.


I'm warming up to the idea, too! I think everyone needs to buy the  
product now!!


Best,

Jerry Daniels
Watch tRev - The Movie
http://reveditor.com/trev-the-movie

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your  
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-revolution


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: [OT] Re: [ANN] tRev's new 'decoder' now showing...video is up!

2009-08-25 Thread Brian Yennie
Always my favorite confirmation that something is worth pursuing --  
when multiple people dream it up independently =).


I honestly don't have any current Rev projects right now, but I'll  
keep my eye fixed on tRev for the next one that comes along! And since  
we seem to be on the "same page", if anything strikes me while  
debugging elsewhere, I'll let ya now... kudos for thinking outside the  
box on this one.



Brian,

Your ideas for where this is going, they mirror my own. Cool.

SO...what're you waitin' for? Also, don't forget to get a mug or a  
tShirt.


Best,

Jerry Daniels
Watch tRev - The Movie
http://reveditor.com/trev-the-movie

On Aug 25, 2009, at 7:19 PM, Brian Yennie wrote:


Jerry,

I was honestly lukewarm about this at first as a heavy user of  
"full" debuggers, but I'm definitely warming up to it. Fact is,  
that about half the time I use a debugger and half the time I just  
litter my scripts with "put" statements. This is a nice middle  
ground approach.


With that said, here is one thing I would personally find very cool  
-- single variable "decode". I picture it like this:


1) Click on a variable name to "decode" it. tRev automagically sets  
invisible (to me) breakpoints wherever that variable is used. You  
could give some visual indicator (for instance, background color  
change).


2) Run the script

3) View my script -- mouseover any instance of that variable and I  
get the value at that point in the script.


I kind of think of it as "vertical debugging" -- often I know what  
variable is going awry and want to ignore all the rest of the  
information. And so instead of adding tons of "put" statements or  
wading through the context of all my other variables, I could very  
quickly pinpoint where things went wrong with that variable by  
clicking once and running.



Alex,

I would love to change the name of our breakpoints to alexpoints  
or lenpoints or kevpoints, but alas, I cannot. Only the keyword  
"breakpoint" will cause the tracebreak message to be sent to  
tRev's frontscript in Rev where it stores the full context into a  
database. It's this data that the decoder then uses in tRev to  
help you fix code with less effort.


I agree TOTALLY with the request, but alas, Rev forbids it. I am  
glad you like the decoder. I just updated it. You will see the  
"update available" link appear in the lower left of tRev editor  
any moment now.


Best,

Jerry Daniels
Watch tRev - The Movie
http://reveditor.com/trev-the-movie

On Aug 25, 2009, at 4:54 PM, Alex Tweedly wrote:

They are not "breakpoints" !  the execution doesn't 'break' when  
it gets to one.

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: [OT] Re: [ANN] tRev's new 'decoder' now showing...video is up!

2009-08-25 Thread Brian Yennie

Jerry,

I was thinking more of an inline image than the Rev "dot" next to a  
line. It would occupy a line of its own. Doesn't make much of a  
difference to me, but seemed like an alternative to the concerns about  
terminology. For example:


on mouseUp
   put 1 into someVar
   BREAKPOINT #1386243
   doSomething
end mouseUp

would become:

on mouseUp
   put 1 into someVar
   ===> #1386243
end mouseUp

Where the "=>" is an actual image.

Basically, it was just a middle ground between changing the name of  
breakpoints and going back to red dots =).



Brian,

Have you ever noticed the dots in Rev's debugger? How, if your  
script has very many lines at all, the dots can't keep pace with  
scrolling, returns, etc.? I have. Not pretty, to say the least. So,  
no images floating around for me, thank you.


Also, keeping a separate array of breakpoints and keeping them in  
sync with the actual code is not easy in a world where tRev is not  
the only script editor. I used to have lots of these sorts of  
"proprietary" approaches. It always came back to bite me in the  
behind when people traded code with others or used more than one  
editor.


So, a couple years ago, i decided to use text to indicate a  
breakpoint. Easy to see, easy to delete, follows the code wherever  
it goes, never gets out of sync. It's all good. Now that we've added  
record id's as comments following the word "breakpoint", we can  
attach loads of data to a breakpoint.


I'm warming up to the idea, too! I think everyone needs to buy the  
product now!!


Best,

Jerry Daniels
Watch tRev - The Movie
http://reveditor.com/trev-the-movie

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: [OT] Re: [ANN] tRev's new 'decoder' now showing...video is up!

2009-08-25 Thread Jerry Daniels

Brian,

Your ideas for where this is going, they mirror my own. Cool.

SO...what're you waitin' for? Also, don't forget to get a mug or a  
tShirt.


Best,

Jerry Daniels
Watch tRev - The Movie
http://reveditor.com/trev-the-movie

On Aug 25, 2009, at 7:19 PM, Brian Yennie wrote:


Jerry,

I was honestly lukewarm about this at first as a heavy user of  
"full" debuggers, but I'm definitely warming up to it. Fact is, that  
about half the time I use a debugger and half the time I just litter  
my scripts with "put" statements. This is a nice middle ground  
approach.


With that said, here is one thing I would personally find very cool  
-- single variable "decode". I picture it like this:


1) Click on a variable name to "decode" it. tRev automagically sets  
invisible (to me) breakpoints wherever that variable is used. You  
could give some visual indicator (for instance, background color  
change).


2) Run the script

3) View my script -- mouseover any instance of that variable and I  
get the value at that point in the script.


I kind of think of it as "vertical debugging" -- often I know what  
variable is going awry and want to ignore all the rest of the  
information. And so instead of adding tons of "put" statements or  
wading through the context of all my other variables, I could very  
quickly pinpoint where things went wrong with that variable by  
clicking once and running.



Alex,

I would love to change the name of our breakpoints to alexpoints or  
lenpoints or kevpoints, but alas, I cannot. Only the keyword  
"breakpoint" will cause the tracebreak message to be sent to tRev's  
frontscript in Rev where it stores the full context into a  
database. It's this data that the decoder then uses in tRev to help  
you fix code with less effort.


I agree TOTALLY with the request, but alas, Rev forbids it. I am  
glad you like the decoder. I just updated it. You will see the  
"update available" link appear in the lower left of tRev editor any  
moment now.


Best,

Jerry Daniels
Watch tRev - The Movie
http://reveditor.com/trev-the-movie

On Aug 25, 2009, at 4:54 PM, Alex Tweedly wrote:

They are not "breakpoints" !  the execution doesn't 'break' when  
it gets to one.

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your  
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-revolution


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: [OT] Re: [ANN] tRev's new 'decoder' now showing...video is up!

2009-08-25 Thread Jerry Daniels

Brian,

Have you ever noticed the dots in Rev's debugger? How, if your script  
has very many lines at all, the dots can't keep pace with scrolling,  
returns, etc.? I have. Not pretty, to say the least. So, no images  
floating around for me, thank you.


Also, keeping a separate array of breakpoints and keeping them in sync  
with the actual code is not easy in a world where tRev is not the only  
script editor. I used to have lots of these sorts of "proprietary"  
approaches. It always came back to bite me in the behind when people  
traded code with others or used more than one editor.


So, a couple years ago, i decided to use text to indicate a  
breakpoint. Easy to see, easy to delete, follows the code wherever it  
goes, never gets out of sync. It's all good. Now that we've added  
record id's as comments following the word "breakpoint", we can attach  
loads of data to a breakpoint.


I'm warming up to the idea, too! I think everyone needs to buy the  
product now!!


Best,

Jerry Daniels
Watch tRev - The Movie
http://reveditor.com/trev-the-movie

On Aug 25, 2009, at 7:13 PM, Brian Yennie wrote:

Off the cusp idea -- what about just making "breakpoints" completely  
visual in tRev? Perhaps use an image with an arrow and some sort of  
useful icon? That way you'd maintain the use of actual breakpoints  
for all of the reasons you outlined, but just give the user  
something tRev-specific to look at.



Hey, Dick! Good to hear from you.

I would need to deal with the whole name space thing...if some  
other program used checkpoint, etc.


Using "breakpoint" has two sizeable advantages over alternatives  
(now that I'm really considering your suggestion):


1. I don't have to worry about another program using it.

2. It has a use when tRev is not in use. E.g., when you give  
someone else your code and they don't have tRev (because of a  
religious injunction or something).


Great idea, though. I'll play around with it some. Thanks.

Best,

Jerry Daniels
Watch tRev - The Movie
http://reveditor.com/trev-the-movie

On Aug 25, 2009, at 6:40 PM, Dick Kriesel wrote:


On 8/25/09 3:18 PM, "Jerry Daniels"  wrote:


I agree TOTALLY with the request, but alas, Rev forbids it.


Hi, Jerry.  Could you proceed without Rev's traceback message?

on mouseUp
put 1 into t1
put 2 into t2
checkPoint
end mouseUp

command checkPoint
set the debugcontext to line -2 of the executioncontexts
global gREVVariableWatcherValue
debugdo "revDebuggerGrabValue the variableNames"
repeat for each item tVariableName in line 2 of  
gREVVariableWatcherValue

  debugdo "revDebuggerGrabValue" && tVariableName
  put gREVVariableWatcherValue into tVariables[tVariableName]
end repeat
set the debugcontext to empty
-- ... "store the full context into a database"

breakpoint -- just so you can see tVariables[]
end checkPoint

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your  
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-revolution


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: [OT] Re: [ANN] tRev's new 'decoder' now showing...video is up!

2009-08-25 Thread Brian Yennie

Jerry,

I was honestly lukewarm about this at first as a heavy user of "full"  
debuggers, but I'm definitely warming up to it. Fact is, that about  
half the time I use a debugger and half the time I just litter my  
scripts with "put" statements. This is a nice middle ground approach.


With that said, here is one thing I would personally find very cool --  
single variable "decode". I picture it like this:


1) Click on a variable name to "decode" it. tRev automagically sets  
invisible (to me) breakpoints wherever that variable is used. You  
could give some visual indicator (for instance, background color  
change).


2) Run the script

3) View my script -- mouseover any instance of that variable and I get  
the value at that point in the script.


I kind of think of it as "vertical debugging" -- often I know what  
variable is going awry and want to ignore all the rest of the  
information. And so instead of adding tons of "put" statements or  
wading through the context of all my other variables, I could very  
quickly pinpoint where things went wrong with that variable by  
clicking once and running.



Alex,

I would love to change the name of our breakpoints to alexpoints or  
lenpoints or kevpoints, but alas, I cannot. Only the keyword  
"breakpoint" will cause the tracebreak message to be sent to tRev's  
frontscript in Rev where it stores the full context into a database.  
It's this data that the decoder then uses in tRev to help you fix  
code with less effort.


I agree TOTALLY with the request, but alas, Rev forbids it. I am  
glad you like the decoder. I just updated it. You will see the  
"update available" link appear in the lower left of tRev editor any  
moment now.


Best,

Jerry Daniels
Watch tRev - The Movie
http://reveditor.com/trev-the-movie

On Aug 25, 2009, at 4:54 PM, Alex Tweedly wrote:

They are not "breakpoints" !  the execution doesn't 'break' when it  
gets to one.

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: [OT] Re: [ANN] tRev's new 'decoder' now showing...video is up!

2009-08-25 Thread Brian Yennie
Off the cusp idea -- what about just making "breakpoints" completely  
visual in tRev? Perhaps use an image with an arrow and some sort of  
useful icon? That way you'd maintain the use of actual breakpoints for  
all of the reasons you outlined, but just give the user something tRev- 
specific to look at.



Hey, Dick! Good to hear from you.

I would need to deal with the whole name space thing...if some other  
program used checkpoint, etc.


Using "breakpoint" has two sizeable advantages over alternatives  
(now that I'm really considering your suggestion):


1. I don't have to worry about another program using it.

2. It has a use when tRev is not in use. E.g., when you give someone  
else your code and they don't have tRev (because of a religious  
injunction or something).


Great idea, though. I'll play around with it some. Thanks.

Best,

Jerry Daniels
Watch tRev - The Movie
http://reveditor.com/trev-the-movie

On Aug 25, 2009, at 6:40 PM, Dick Kriesel wrote:


On 8/25/09 3:18 PM, "Jerry Daniels"  wrote:


I agree TOTALLY with the request, but alas, Rev forbids it.


Hi, Jerry.  Could you proceed without Rev's traceback message?

on mouseUp
 put 1 into t1
 put 2 into t2
 checkPoint
end mouseUp

command checkPoint
 set the debugcontext to line -2 of the executioncontexts
 global gREVVariableWatcherValue
 debugdo "revDebuggerGrabValue the variableNames"
 repeat for each item tVariableName in line 2 of  
gREVVariableWatcherValue

   debugdo "revDebuggerGrabValue" && tVariableName
   put gREVVariableWatcherValue into tVariables[tVariableName]
 end repeat
 set the debugcontext to empty
 -- ... "store the full context into a database"

 breakpoint -- just so you can see tVariables[]
end checkPoint

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: [OT] Re: [ANN] tRev's new 'decoder' now showing...video is up!

2009-08-25 Thread Jerry Daniels

Hey, Dick! Good to hear from you.

I would need to deal with the whole name space thing...if some other  
program used checkpoint, etc.


Using "breakpoint" has two sizeable advantages over alternatives (now  
that I'm really considering your suggestion):


1. I don't have to worry about another program using it.

2. It has a use when tRev is not in use. E.g., when you give someone  
else your code and they don't have tRev (because of a religious  
injunction or something).


Great idea, though. I'll play around with it some. Thanks.

Best,

Jerry Daniels
Watch tRev - The Movie
http://reveditor.com/trev-the-movie

On Aug 25, 2009, at 6:40 PM, Dick Kriesel wrote:


On 8/25/09 3:18 PM, "Jerry Daniels"  wrote:


I agree TOTALLY with the request, but alas, Rev forbids it.


Hi, Jerry.  Could you proceed without Rev's traceback message?

on mouseUp
   put 1 into t1
   put 2 into t2
   checkPoint
end mouseUp

command checkPoint
   set the debugcontext to line -2 of the executioncontexts
   global gREVVariableWatcherValue
   debugdo "revDebuggerGrabValue the variableNames"
   repeat for each item tVariableName in line 2 of  
gREVVariableWatcherValue

 debugdo "revDebuggerGrabValue" && tVariableName
 put gREVVariableWatcherValue into tVariables[tVariableName]
   end repeat
   set the debugcontext to empty
   -- ... "store the full context into a database"

   breakpoint -- just so you can see tVariables[]
end checkPoint


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your  
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-revolution


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: [OT] Re: [ANN] tRev's new 'decoder' now showing...video is up!

2009-08-25 Thread Dick Kriesel
On 8/25/09 3:18 PM, "Jerry Daniels"  wrote:

> I agree TOTALLY with the request, but alas, Rev forbids it.

Hi, Jerry.  Could you proceed without Rev's traceback message?

on mouseUp
put 1 into t1
put 2 into t2
checkPoint
end mouseUp

command checkPoint
set the debugcontext to line -2 of the executioncontexts
global gREVVariableWatcherValue
debugdo "revDebuggerGrabValue the variableNames"
repeat for each item tVariableName in line 2 of gREVVariableWatcherValue
  debugdo "revDebuggerGrabValue" && tVariableName
  put gREVVariableWatcherValue into tVariables[tVariableName]
end repeat
set the debugcontext to empty
-- ... "store the full context into a database"

breakpoint -- just so you can see tVariables[]
end checkPoint


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: [OT] Re: [ANN] tRev's new 'decoder' now showing...video is up!

2009-08-25 Thread Jerry Daniels

Alex,

I would love to change the name of our breakpoints to alexpoints or  
lenpoints or kevpoints, but alas, I cannot. Only the keyword  
"breakpoint" will cause the tracebreak message to be sent to tRev's  
frontscript in Rev where it stores the full context into a database.  
It's this data that the decoder then uses in tRev to help you fix code  
with less effort.


I agree TOTALLY with the request, but alas, Rev forbids it. I am glad  
you like the decoder. I just updated it. You will see the "update  
available" link appear in the lower left of tRev editor any moment now.


Best,

Jerry Daniels
Watch tRev - The Movie
http://reveditor.com/trev-the-movie

On Aug 25, 2009, at 4:54 PM, Alex Tweedly wrote:

They are not "breakpoints" !  the execution doesn't 'break' when it  
gets to one.


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution