|debuggers - request for information firstname.lastname@example.org (Arne Watnelie) (1995-07-12)|
|Re: debuggers - request for information email@example.com (steve (s.s.) simmons) (1995-07-17)|
|Re: debuggers - request for information Zhiqing.Liu@att.com (Zhiqing Liu) (1995-07-17)|
|Re: debuggers - request for information firstname.lastname@example.org (1995-07-17)|
|Re: debuggers - request for information email@example.com (1995-07-18)|
|Re: debuggers - request for information firstname.lastname@example.org (1995-07-18)|
|Re: debuggers - request for information email@example.com (1995-07-19)|
|Re: debuggers - request for information firstname.lastname@example.org (1995-07-20)|
|Re: debuggers - request for information email@example.com (1995-07-20)|
|Re: debuggers - request for information firstname.lastname@example.org (1995-07-20)|
|Re: debuggers - request for information R.Sosic@cit.gu.edu.au (1995-07-21)|
|Re: debuggers - request for information reid@HASKELL.SYSTEMSZ.CS.YALE.EDU (1995-07-22)|
|[5 later articles]|
|From:||email@example.com ("Dave Murphy")|
|Date:||Tue, 18 Jul 1995 22:24:10 GMT|
> I'm writing a master thesis on the subject of debugging, and about an
> implementation of a debugger with a new view on how one may debug
> (I'm a little abstract here, but the thesis and the program isn't
> yet :-)...)
> 3) Have anybody made any creative, new debuggers who breaks the
> of using breakpoints, stepping etc.? Implementing new, untraditional
> approaches to the debugging task?
> (Like when people suddenly made cursor-oriented editors instead of
> line-oriented/command-oriented editors.)
> 4) Any nice window/point and click debuggers out there?
> (Which is something else than a traditional debugger splited into
> than one window.)
You could look at Boundschecker for windows. It works as a complement to
the standard Turbo Debug type tools. Monitors heap usage, api calls etc.
I believe it can intercept calls to the windows api via spying on the
message stream so it can provide some monitoring of compiled programs not
written by you. ISTR some programmers monitored some early Microsoft
Windows APPS and discovered they didn't return memory properly.
I am not sure how you could use similar techniques in a Unix environment,
but it may give some ideas, particularly about checking/monitoring
allocation and deallocation of memory and known api calls.
There is also a visual software debugger called Look! Released last year
I believe. Works for C++ only and very much geared to object oriented
code. It display a visual chart of the program as it executes, so you
can see the construction/destruction of the objects as it executes. I
believe microfocus PC/Unix debugger for cobol (called animator) also does
Try firstname.lastname@example.org for Look!
email@example.com for the boundschecker program.
Don't have one for Microfocus, although i could probably get it if you
Return to the
Search the comp.compilers archives again.