Re: [OT] Re: [ANN] tRev's new 'decoder' now showing...video is up!
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 jerry.dani...@me.com 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 jerry.dani...@me.com 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!
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!
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!
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!
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 jerry.dani...@me.com 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 jerry.dani...@me.com 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!
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
[OT] Re: [ANN] tRev's new 'decoder' now showing...video is up!
Jerry Daniels wrote: Here's the link to the video showing how tRev's decoder works to help you debug your code. http://reveditor.com/de-construct-your-code-with-trevs-decoder-0 This video talks about tRev and the new feature called 'decoder', but also has a fairly in-depth discussion of modal debuggers and why they have had difficulty in Revolution. Love it. Thanks Jerry. One suggestion (perhaps for discussion) you mentioned the frequent requests for features that belong in a traditional debugger, but not in decoder. I think you would help reduce this, and help us all to remember that it is a different beast from an old-fashioned debugger, if you could change the terminology used. They are not breakpoints ! the execution doesn't 'break' when it gets to one. I think you should call them statuspoints or contextpoints or monitorpoints of some other name that more closely reflects their purpose and effect. -- Alex. ___ 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!
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!
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 jerry.dani...@me.com 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!
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 jerry.dani...@me.com 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!
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!
On 8/25/09 3:18 PM, Jerry Daniels jerry.dani...@me.com 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!
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 jerry.dani...@me.com 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!
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!
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!
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!
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!
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!
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!
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
