Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #15275 > unrolled thread

Single Step Debugging, why or why not?

Back to article view | Back to comp.lang.forth

Contents

  Single Step Debugging,  why or why not? Jason Damisch <jasondamisch@yahoo.com> - 2012-08-30 11:27 -0700
    Re: Single Step Debugging,  why or why not? "Elizabeth D. Rather" <erather@forth.com> - 2012-08-30 08:42 -1000
    Single Step Debugging,  why or why not? Mark Wills <markrobertwills@yahoo.co.uk> - 2012-08-30 14:37 -0700
      Re: Single Step Debugging,  why or why not? "Elizabeth D. Rather" <erather@forth.com> - 2012-08-30 14:26 -1000
        Re: Single Step Debugging, why or why not? Mark Wills <markrobertwills@yahoo.co.uk> - 2012-08-31 02:25 -0700
          Re: Single Step Debugging, why or why not? "Elizabeth D. Rather" <erather@forth.com> - 2012-08-31 08:18 -1000
    Re: Single Step Debugging,  why or why not? Paul Rubin <no.email@nospam.invalid> - 2012-08-30 18:48 -0700
      Re: Single Step Debugging, why or why not? Mark Wills <markrobertwills@yahoo.co.uk> - 2012-08-31 02:12 -0700
    Re: Single Step Debugging,  why or why not? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-08-31 08:54 +0000
      Re: Single Step Debugging,  why or why not? Paul Rubin <no.email@nospam.invalid> - 2012-08-31 02:46 -0700
        Re: Single Step Debugging,  why or why not? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-08-31 05:56 -0500
          Re: Single Step Debugging,  why or why not? Paul Rubin <no.email@nospam.invalid> - 2012-08-31 09:10 -0700
            Re: Single Step Debugging,  why or why not? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-08-31 11:33 -0500
              Re: Single Step Debugging, why or why not? Mark Wills <markrobertwills@yahoo.co.uk> - 2012-08-31 12:51 -0700
                Re: Single Step Debugging, why or why not? Coos Haak <chforth@hccnet.nl> - 2012-08-31 23:23 +0200
                Re: Single Step Debugging, why or why not? Paul Rubin <no.email@nospam.invalid> - 2012-08-31 15:42 -0700
                  Re: Single Step Debugging, why or why not? Bernd Paysan <bernd.paysan@gmx.de> - 2012-09-01 01:52 +0200
                    Re: Single Step Debugging, why or why not? Paul Rubin <no.email@nospam.invalid> - 2012-09-01 17:41 -0700
            Re: Single Step Debugging,  why or why not? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2012-08-31 17:54 +0100
            Re: Single Step Debugging,  why or why not? "Elizabeth D. Rather" <erather@forth.com> - 2012-08-31 08:22 -1000
            Re: Single Step Debugging,  why or why not? "Ed" <invalid@nospam.com> - 2012-09-03 22:15 +1000

Page 1 of 2  [1] 2  Next page →

#15275 — Single Step Debugging, why or why not?

I thought that I had my brain wrapped around the issue of single stepping and why it may be discouraged in Forth.  But, then recently my brain went 'thump' and straightened itself out.  So, I wanted to ask people, and hopefully I will receive some erudite explanations as to the advantages and disadvantages of single stepping.  Examples cases would be appreciated.  

Also note that I see that SwiftForth includes single stepping and also that the PSC1000 has hardware support for single stepping.

Jason

[toc] | [next] | [standalone]

#15276

On 8/30/12 8:27 AM, Jason Damisch wrote:
> I thought that I had my brain wrapped around the issue of single
 > stepping and why it may be discouraged in Forth.  But, then recently
> my brain went 'thump' and straightened itself out.  So, I wanted to
> ask people, and hopefully I will receive some erudite explanations
> as to the advantages and disadvantages of single stepping.
> Examples cases would be appreciated.
>
> Also note that I see that SwiftForth includes single stepping
> and also that the PSC1000 has hardware support for single stepping.

SwiftForth includes a single-stepper because it is a commercial product, 
and if potential customers want tools we try to provide them. The 
programmers I work with rarely use it, though, because it's more trouble 
to use a single-stepper than to simply debug definitions directly using 
something like the steps I just described in a different thread.

Single steppers are, indeed, necessary for a programming style that 
produces programs a page or more in length. Good Forth style doesn't 
have that problem.

I'd be interested in knowing what revelation resulted from your brain 
'thump'?

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[toc] | [prev] | [next] | [standalone]

#15282

I havent come across the need for one with Forth - if your code is factored well enough then you can just feed data to your words. If one sticks to the 'no more than two lines' maxim then words are rarely that complex as to require a single stepper. I'm sure you're aware of all this already!

I could imagine it might come in handy in multi-tasking systems, however where un-expected interactions are taking place. 

[toc] | [prev] | [next] | [standalone]

#15283

On 8/30/12 11:37 AM, Mark Wills wrote:
> I havent come across the need for one with Forth - if your code is factored well enough then you can just feed data to your words. If one sticks to the 'no more than two lines' maxim then words are rarely that complex as to require a single stepper. I'm sure you're aware of all this already!
>
> I could imagine it might come in handy in multi-tasking systems, however where un-expected interactions are taking place.
>

A single-stepper is useless in that case, because you can only step 
definitions in one task.

SwiftForth has the ability to run a dynamic memory window that can watch 
one or more regions of memory during the running of an application with 
multiple threads going. That can help. My experience, though, is that 
such interactions are rare.

Really, the most common sources of errors in the programs I've worked on 
is just logical mistakes on the programmer's part.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[toc] | [prev] | [next] | [standalone]

#15305 — Re: Single Step Debugging, why or why not?

On Aug 31, 1:26 am, "Elizabeth D. Rather" <erat...@forth.com> wrote:
> On 8/30/12 11:37 AM, Mark Wills wrote:
>
> > I havent come across the need for one with Forth - if your code is factored well enough then you can just feed data to your words. If one sticks to the 'no more than two lines' maxim then words are rarely that complex as to require a single stepper. I'm sure you're aware of all this already!
>
> > I could imagine it might come in handy in multi-tasking systems, however where un-expected interactions are taking place.
>
> A single-stepper is useless in that case, because you can only step
> definitions in one task.
>
> SwiftForth has the ability to run a dynamic memory window that can watch
> one or more regions of memory during the running of an application with
> multiple threads going. That can help. My experience, though, is that
> such interactions are rare.
>
> Really, the most common sources of errors in the programs I've worked on
> is just logical mistakes on the programmer's part.
>
> Cheers,
> Elizabeth
>
> --
> ==================================================
> Elizabeth D. Rather   (US & Canada)   800-55-FORTH
> FORTH Inc.                         +1 310.999.6784
> 5959 West Century Blvd. Suite 700
> Los Angeles, CA 90045http://www.forth.com
>
> "Forth-based products and Services for real-time
> applications since 1973."
> ==================================================

That's interesting. I've no experience at all with (Forth) de-buggers/
single-steppers, but I would have expected a single-stepper to follow
the execution thread through a context switch and into the next task.
Admittedly, that might be tricky on a pre-emptive system, but in a
classic cooperative system (using PAUSE) it should be possible to
follow the code all the way through PAUSE and into the next task,
should it not?

I actually wrote a simple de-bugger thingy for my own system. It can
show the entry and exit to/from words (with data stack dump before and
after entry) and includes a single word BREAK that stops the program,
gives a stack dump, and gives shows the return stack nesting (i.e.
gives the names of the words all the back up to QUIT). I was very
pleased with myself.

I've to use it, though! I generally don't have any problems debugging
(my own) Forth programs... Just go one word at a time. Sometimes I
struggle to keep the shape of the stack in my head, so I reach for a
paper and pencil and write the code out with stack diagrams. When it
happens it's probably a warning sign that I need to factor at that
point.

Regards

Mark

[toc] | [prev] | [next] | [standalone]

#15322 — Re: Single Step Debugging, why or why not?

On 8/30/12 11:25 PM, Mark Wills wrote:
> On Aug 31, 1:26 am, "Elizabeth D. Rather" <erat...@forth.com> wrote:
>> On 8/30/12 11:37 AM, Mark Wills wrote:
>>
>>> I havent come across the need for one with Forth - if your code is factored well enough then you can just feed data to your words. If one sticks to the 'no more than two lines' maxim then words are rarely that complex as to require a single stepper. I'm sure you're aware of all this already!
>>
>>> I could imagine it might come in handy in multi-tasking systems, however where un-expected interactions are taking place.
>>
>> A single-stepper is useless in that case, because you can only step
>> definitions in one task.
>>
>> SwiftForth has the ability to run a dynamic memory window that can watch
>> one or more regions of memory during the running of an application with
>> multiple threads going. That can help. My experience, though, is that
>> such interactions are rare.
>>
>> Really, the most common sources of errors in the programs I've worked on
>> is just logical mistakes on the programmer's part.
...
> That's interesting. I've no experience at all with (Forth) de-buggers/
> single-steppers, but I would have expected a single-stepper to follow
> the execution thread through a context switch and into the next task.
> Admittedly, that might be tricky on a pre-emptive system, but in a
> classic cooperative system (using PAUSE) it should be possible to
> follow the code all the way through PAUSE and into the next task,
> should it not?

No, it's following a stream of code in memory, for the task that's 
operating the user interface.

> I actually wrote a simple de-bugger thingy for my own system. It can
> show the entry and exit to/from words (with data stack dump before and
> after entry) and includes a single word BREAK that stops the program,
> gives a stack dump, and gives shows the return stack nesting (i.e.
> gives the names of the words all the back up to QUIT). I was very
> pleased with myself.
>
> I've to use it, though! I generally don't have any problems debugging
> (my own) Forth programs... Just go one word at a time. Sometimes I
> struggle to keep the shape of the stack in my head, so I reach for a
> paper and pencil and write the code out with stack diagrams. When it
> happens it's probably a warning sign that I need to factor at that
> point.

Yes, that's a very good strategy, especially if you're still learning.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[toc] | [prev] | [next] | [standalone]

#15284

Jason Damisch <jasondamisch@yahoo.com> writes:
> hopefully I will receive some erudite explanations as
> to the advantages and disadvantages of single stepping.  Examples
> cases would be appreciated.

Besides debugging, single stepping is very useful for getting to
understand the workings of big programs.  There's too much code to read
and comprehend all at once, so you set breakpoints in the area where you
want to work, run the program, and inspect what it is doing when it gets
to the area of interest.

[toc] | [prev] | [next] | [standalone]

#15303 — Re: Single Step Debugging, why or why not?

On Aug 31, 2:48 am, Paul Rubin <no.em...@nospam.invalid> wrote:
> Jason Damisch <jasondami...@yahoo.com> writes:
> > hopefully I will receive some erudite explanations as
> > to the advantages and disadvantages of single stepping.  Examples
> > cases would be appreciated.
>
> Besides debugging, single stepping is very useful for getting to
> understand the workings of big programs.  There's too much code to read
> and comprehend all at once, so you set breakpoints in the area where you
> want to work, run the program, and inspect what it is doing when it gets
> to the area of interest.

Very good point.

[toc] | [prev] | [next] | [standalone]

#15304

Jason Damisch <jasondamisch@yahoo.com> writes:
>I thought that I had my brain wrapped around the issue of single stepping a=
>nd why it may be discouraged in Forth.  But, then recently my brain went 't=
>hump' and straightened itself out.  So, I wanted to ask people, and hopeful=
>ly I will receive some erudite explanations as to the advantages and disadv=
>antages of single stepping.  Examples cases would be appreciated. =20

Disadvantage: You can waste a lot of time for stepping through the
program and checking at many steps whether the state is still as
intended.

Advantages: None

When there is a bug, it invariably shows itself after the buggy code
has been executed.  The state of the program is wrong afterwards and
correct before.  Stepping through the program before the buggy code is
a waste of time.  But since you don't know where the bug ist, you
waste a lot of time this way.  And at every step you examine the
state.  Very time-consuming.

I don't find the interactive variant of single-stepping (that others
suggest) useful in most cases, either.  However, if you have test
cases for each word and each word is simple enough, then there may be
no need for more sophisticated debugging.  But I consider that only
effective if most of the test cases are developped for testing, not
for debugging.

Running backwards from the point where the bug showed itself, with
backwards watchpoints and maybe backwards breakpoints and stepping,
would allow to find the buggy code relatively fast.

If we don't have that, tracing (known as "printf() debugging" to C
programmers) allows quite effective debugging: You put tracers
(printing words that show the state) in strategic places and run the
program.  When the bug shows up, you can look at the output and scan
backwards until you find a correct state; then the bug is between this
tracer and the next.  If needed, you can insert additional tracers
between these points and repeat.  Stepping debugging is a kind of
linear search process, this refinement approach is logarithmic like
binary search.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2012: http://www.euroforth.org/ef12/

[toc] | [prev] | [next] | [standalone]

#15308

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> Disadvantage: You can waste a lot of time for stepping through the
> program and checking at many steps whether the state is still as
> intended.

That is not the way to do it.  Identify something that has gone wrong
(like x has somehow been set to 5 when it should be zero), then set
either a watchpoint on x or a conditional breakpoint on something that
might set x, then run the program til x gets set to 5.  If it's still
not obvious where the bug is, find some other wrong data in the image
and set more conditional breakpoints to see how it got that way.  If
your debugger can run code backwards, that's great.  Otherwise you have
to re-run the code multiple times, but that's not too bad if the bug is
reproduceable.

For intermittent bugs, debuggers are even more valuable, since you set
conditional breakpoints where things can go wrong, and you can examine
and modify the complete contents of memory when the breakpoint is
reached.  The bug may not occur often enough for repeatedly inserting
trace messages (~~) to catch the bug anytime soon.

[toc] | [prev] | [next] | [standalone]

#15313

Paul Rubin <no.email@nospam.invalid> wrote:
> 
> For intermittent bugs, debuggers are even more valuable, since you set
> conditional breakpoints where things can go wrong, and you can examine
> and modify the complete contents of memory when the breakpoint is
> reached.  The bug may not occur often enough for repeatedly inserting
> trace messages (~~) to catch the bug anytime soon.

Well, yes, but Forth itself is mutable: if you want conditional
breakpoints or watchpoints you can modify the data access words or the
compiler, so that it inserts trace points.  You don't need a separate
debugger to help you because Forth is the debugger.

Andrew.

[toc] | [prev] | [next] | [standalone]

#15317

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
> Well, yes, but Forth itself is mutable: if you want conditional
> breakpoints or watchpoints you can modify the data access words or the
> compiler, so that it inserts trace points.  You don't need a separate
> debugger to help you because Forth is the debugger.

Is there a way to stop the program execution and give an interactive
prompt, so that the stacks and dictionary can be inspected, I guess from
another task?  That would be pretty cool.

[toc] | [prev] | [next] | [standalone]

#15319

Paul Rubin <no.email@nospam.invalid> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>> Well, yes, but Forth itself is mutable: if you want conditional
>> breakpoints or watchpoints you can modify the data access words or the
>> compiler, so that it inserts trace points.  You don't need a separate
>> debugger to help you because Forth is the debugger.
> 
> Is there a way to stop the program execution and give an interactive
> prompt, so that the stacks and dictionary can be inspected, I guess
> from another task?  That would be pretty cool.

You can simply use QUIT, but that empties the return stack.  To
inspect some other task you'd have to freeze it somehow.  I've never
needed to do that, because my Forth debugging is much as Elizabeth
describes it.

Andrew.

[toc] | [prev] | [next] | [standalone]

#15327 — Re: Single Step Debugging, why or why not?

On Aug 31, 5:33 pm, Andrew Haley <andre...@littlepinkcloud.invalid>
wrote:
> Paul Rubin <no.em...@nospam.invalid> wrote:
> > Andrew Haley <andre...@littlepinkcloud.invalid> writes:
> >> Well, yes, but Forth itself is mutable: if you want conditional
> >> breakpoints or watchpoints you can modify the data access words or the
> >> compiler, so that it inserts trace points.  You don't need a separate
> >> debugger to help you because Forth is the debugger.
>
> > Is there a way to stop the program execution and give an interactive
> > prompt, so that the stacks and dictionary can be inspected, I guess
> > from another task?  That would be pretty cool.
>
> You can simply use QUIT, but that empties the return stack.  To
> inspect some other task you'd have to freeze it somehow.  I've never
> needed to do that, because my Forth debugging is much as Elizabeth
> describes it.
>
> Andrew.

Just call INTERPRET. Example:

VARIABLE ESCAPE
: TEST 1000 0 DO I . I 50 = IF BEGIN INTERPRET ESCAPE @ UNTIL THEN
LOOP ;

The above works on my system. It repeatedly calls the interpreter
until I type FALSE ESCAPE ! then it just carries on.

You just gotta love Forth!

[toc] | [prev] | [next] | [standalone]

#15335 — Re: Single Step Debugging, why or why not?

Op Fri, 31 Aug 2012 12:51:04 -0700 (PDT) schreef Mark Wills:

> On Aug 31, 5:33 pm, Andrew Haley <andre...@littlepinkcloud.invalid>
> wrote:
>> Paul Rubin <no.em...@nospam.invalid> wrote:
>>> Andrew Haley <andre...@littlepinkcloud.invalid> writes:
>>>> Well, yes, but Forth itself is mutable: if you want conditional
>>>> breakpoints or watchpoints you can modify the data access words or the
>>>> compiler, so that it inserts trace points.  You don't need a separate
>>>> debugger to help you because Forth is the debugger.
>>
>>> Is there a way to stop the program execution and give an interactive
>>> prompt, so that the stacks and dictionary can be inspected, I guess
>>> from another task?  That would be pretty cool.
>>
>> You can simply use QUIT, but that empties the return stack.  To
>> inspect some other task you'd have to freeze it somehow.  I've never
>> needed to do that, because my Forth debugging is much as Elizabeth
>> describes it.
>>
>> Andrew.
> 
> Just call INTERPRET. Example:
> 
> VARIABLE ESCAPE
>: TEST 1000 0 DO I . I 50 = IF BEGIN INTERPRET ESCAPE @ UNTIL THEN
> LOOP ;
> 
> The above works on my system. It repeatedly calls the interpreter
> until I type FALSE ESCAPE ! then it just carries on.
> 
> You just gotta love Forth!

Ha, but INTERPRET is not a standard word, it could be not implemented.
Still I use a tracer in Forth.

-- 
Coos

CHForth, 16 bit DOS applications
http://home.hccnet.nl/j.j.haak/forth.html 

[toc] | [prev] | [next] | [standalone]

#15340 — Re: Single Step Debugging, why or why not?

Mark Wills <markrobertwills@yahoo.co.uk> writes:
> Just call INTERPRET. Example:
>
> VARIABLE ESCAPE
> : TEST 1000 0 DO I . I 50 = IF BEGIN INTERPRET ESCAPE @ UNTIL THEN
> LOOP ;

I tried in gforth:

  0 value escape
  : repl ( -- ) begin interpret escape until ;
  repl

but it just looped without waiting for input.  Did I do something
obviously wrong?

[toc] | [prev] | [next] | [standalone]

#15346 — Re: Single Step Debugging, why or why not?

Paul Rubin wrote:
> I tried in gforth:
> 
>   0 value escape
>   : repl ( -- ) begin interpret escape until ;
>   repl
> 
> but it just looped without waiting for input.  Did I do something
> obviously wrong?

interpret doesn't read anything from the terminal.  It just interprets 
the input source.

In Gforth, you probably want something like

0 Value escape
: nest-loop ( -- )  0 to escape
  BEGIN  refill  WHILE  interpret prompt cr escape UNTIL  THEN ;
: ?? ( -- )  create-input ['] nest-loop catch pop-file throw ;
: q ( -- )  true to escape ;

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

[toc] | [prev] | [next] | [standalone]

#15379 — Re: Single Step Debugging, why or why not?

Bernd Paysan <bernd.paysan@gmx.de> writes:
> In Gforth, you probably want something like
>
> 0 Value escape
> : nest-loop ( -- )  0 to escape
>   BEGIN  refill  WHILE  interpret prompt cr escape UNTIL  THEN ;
> : ?? ( -- )  create-input ['] nest-loop catch pop-file throw ;
> : q ( -- )  true to escape ;

Thanks.

[toc] | [prev] | [next] | [standalone]

#15320

On 31/08/2012 17:10, Paul Rubin wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>> Well, yes, but Forth itself is mutable: if you want conditional
>> breakpoints or watchpoints you can modify the data access words or the
>> compiler, so that it inserts trace points.  You don't need a separate
>> debugger to help you because Forth is the debugger.
>
> Is there a way to stop the program execution and give an interactive
> prompt, so that the stacks and dictionary can be inspected, I guess from
> another task?  That would be pretty cool.
>

I don't know about from another task but you can always compile in a 
word such as ?? in appropriate places where ?? is defined as:

create buf 82 allot
: (?) cr ." Input: " buf dup 80 accept ;
: ?? begin (?) 2dup s" c" compare while evaluate repeat 2drop ;

and fiddle with things as needed, even compile and execute new words 
(unless ?? is executed in the middle of a colon definition of course). 
Type in a single c character + enter to resume execution of the program.

-- 
Gerry

[toc] | [prev] | [next] | [standalone]

#15323

On 8/31/12 6:10 AM, Paul Rubin wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>> Well, yes, but Forth itself is mutable: if you want conditional
>> breakpoints or watchpoints you can modify the data access words or the
>> compiler, so that it inserts trace points.  You don't need a separate
>> debugger to help you because Forth is the debugger.
>
> Is there a way to stop the program execution and give an interactive
> prompt, so that the stacks and dictionary can be inspected, I guess from
> another task?  That would be pretty cool.
>

That's the way the Open Firmware debugger works, in theory, although not 
all vendors fully implemented it (which I interpret to mean they didn't 
see enough value in it).

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.forth

csiph-web