Re: How do you forth experts drop a break_point ?
- From: Jonah Thomas <jethomas5@xxxxxxxxx>
- Date: Sat, 22 Nov 2008 09:18:01 -0500
"H.C. Chen (gmail)" <hcchen5600@xxxxxxxxx> wrote:
I wish to be able to make a word like below conceptual design. Is it
do-able or is there a better way exists?
: *break_point* ( -- ) \ redirect the source of next word from
console (instead from the running dictionary)
The first month I used Forth I wrote something like that. But then after
awhile I noticed that I never used it. You can find facilities like that
in some Forth systems. You may not get advice about how to use them from
the other people who're familiar with those systems because nobody uses
those tools.
I need that ability so seldom that when I do, when I feel so clueless
that I want to do that while I wait for an inspiration about what else
to do, I do it like this:
Say that you have a word A that does:
: a
b c d e f g h ;
And you want to check something inside e which does:
: e
l m n o p q r ;
and what you're interested in is inside o which does:
: o
s t u v w x y ;
Then what I do is:
b c d .s
I check what's going on at the start of E.
l m n .s
I check what's going on at the start of O.
Now I'm ready to single-step through O and see what's happening.
s .s
And now I test anything I want to test.
t .s
And test again.
u .s
Keep testing.
And so on. I haven't had to do a whole lot to get to my breakpoint.
Say that I believe the problem is at step 2417 of a do loop.
: v
DO aa ab ac ad ae af ag LOOP ;
Then I write
2415 0 v and test
2416 2415 v and test at 2415.
2417 2416 v test at 2416
aa
ab
ac
ad etc.
If I think I'll need to do this repeatedly, then automate the silly
details.
: a'
b c d
l m n
s t u ;
: v'
2415 0 v CR print potentially useful info
2416 2415 v CR print stuff
2417 2416 v CR print stuff
;
And I can get to my trouble spot with minimal effort.
But here's the thing that got me to mostly stop doing this stuff: If I
am so confused about what the code is doing that I need a breakpoint,
that's a strong sign that there's something wrong with the code. If I
rummage through it enough to find this error and fix it, chances are
I'll just have to do the same thing over again for the next error.
Better to rewrite it until it's so simple and obvious it can't be wrong.
There's a strong temptation not to do that for commercial code because
you wind up putting in a lot of time to produce a little bit of code. If
you do it right the first time then you can keep it. If you do it wrong
and waste some time patching it, you'll spend even more time starting
over to do it right. And there's the chance the second try won't be
right either. Much more pleasant to think that one last patch will fix
the bad code.
And there's a strong temptation not to do it for noncommercial code
since after all you're just playing around and you aren't really
serious.
One thing that helps is to carefully divide your time into testing and
coding. When you're testing, you're figuring out in detail what the
problem is that needs to be solved. Whatever code you write at that
point is there to help you define the problem. Once you have the problem
clearly in mind, then you can look for a good solution. If you start
solving the problem before you're clear what the problem is, you're
likely to get a mess.
.
- Follow-Ups:
- Re: How do you forth experts drop a break_point ?
- From: H.C. Chen (gmail)
- Re: How do you forth experts drop a break_point ?
- References:
- How do you forth experts drop a break_point ?
- From: H.C. Chen (gmail)
- How do you forth experts drop a break_point ?
- Prev by Date: Re: How do you forth experts drop a break_point ?
- Next by Date: Re: How do you forth experts drop a break_point ?
- Previous by thread: Re: How do you forth experts drop a break_point ?
- Next by thread: Re: How do you forth experts drop a break_point ?
- Index(es):
Relevant Pages
|
