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
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
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
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,
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
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
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
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
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
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
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
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
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
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
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
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,
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
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
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
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
20 matches
Mail list logo
