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

Brian Yennie briany at qldlearning.com
Tue Aug 25 20:19:56 EDT 2009


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.



More information about the use-livecode mailing list