Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!ecngs!feeder2.ecngs.de!newsfeed.freenet.ag!news2.euro.net!postnews2.euro.net!news.wanadoo.nl!not-for-mail
From: mhx@iae.nl (Marcel Hendrix)
Subject: Re: OT: ANS Forth
Newsgroups: comp.lang.forth
Message-ID: <88980313018434@frunobulax.edu>
Date: Fri, 22 Feb 2013 00:05:15 +0200
References: <7xzjyyrq3v.fsf@ruckus.brouhaha.com>
X-Newsreader: iForth 2.0 console (October 21, 2006)
Lines: 22
Organization: Wanadoo
NNTP-Posting-Date: 21 Feb 2013 23:04:58 GMT
NNTP-Posting-Host: s529d937f.adsl.online.nl
X-Trace: 1361487898 dr5.euro.net 242 82.157.147.127:65515
X-Complaints-To: abuse@wanadoo.nl
Xref: csiph.com comp.lang.forth:19888

Paul Rubin <no.email@nospam.invalid> writes Re: OT: ANS Forth
[..]
> Testing individual words isn't of much help when the problem you're
> debugging is with how some bigger subsystems interact, or with some
> weird edge case that you're testing missed, or some word getting
> unexpected input that it wasn't written to handle, etc.  Soemwhere in
> there, it's a safe bet, actual debugging is still going to be needed
> from time to time.

When I have a problem in a DLL that my Forth calls, I set a breakpoint
in the ( C ) dll and attach to iForth. I then interactively work
with Forth until the breakpoint triggers. In the C debugger I can see 
registers and parameters or do single stepping. At any point I can 
go back to the Forth interpreter (continue, iForth catches the 
excpetion if there is one) and setup a scripts/words that trigger the
breakpoint with narrowed conditions or changed parameters. 
On the Forth commandline I have complete control over memory with DUMP, 
@, ! etc., (I never can remember the debugger commands). I find the 
combination extremely powerful.

-marcel