Newsgroups: comp.lang.smalltalk
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!news.mathworks.com!news.alpha.net!uwm.edu!msunews!harbinger.cc.monash.edu.au!news.cs.su.oz.au!tmx!news.tmx.com.au!news
From: Nick Ivanov <nick@oose.com.au>
Subject: Re: Smalltalks need less intrusive breakpoint mechanism
Message-ID: <D447M3.GwI@online.tmx.com.au>
Nntp-Posting-Host: 203.5.19.181
Sender: news@online.tmx.com.au (System Administrator)
Organization: The Message eXchange Pty Ltd
Date: Thu, 16 Feb 1995 22:54:03 GMT
References: <MACRSHAP.95Feb16110652@labs-n.bbn.com> <3hvuea$3a0@panix.com>
Lines: 41

dsiegel@panix.com (David Siegel) wrote:
>
> In <MACRSHAP.95Feb16110652@labs-n.bbn.com> macrshap@labs-n.bbn.com (Richard Shapiro) writes:
> 
> >Seems to me that the Lisp TRACE function is a *much* better way to do
> >this kind of thing, and I'm quite surprised something analagous hasn't
> >been done for Smalltalk. A general "advise" mechanism, which is what
> >TRACE is usually built on, would be even nicer of course...Even C/C++,
> >at least the one I commonly use on the Mac, offers an unintrusive way
> >to set breakpoints in source code.
> 
> >Are all Smalltalks like this, or is this problem unique to VW?
> 
> The "problem" exists in Digitalk as well.  I'm less exercised about this
> than you are, because I really, really like being able to write arbitrarily
> complex breakpoint code, and find implementations (like all the C++s I've
> used) that do not allow this painful.  Does Lisp's ADVISE support evaluating
> arbitrary Lisp expressions to decide if a breakpoint should be triggered?
> 
> -dms

I like having both an intrusive and a non-intrusive breakpoint
facility. I think both are useful.

I like having non-intrusive breakpoints because you can set and clear
them without modifying your source which is handy for change 
management. If the breakpoints are stored as meta-information 
(not in the source) then you can also turn off all breakpoints in
one foul swoop.

Intrusive breakpoints are useful when you want to set a breakpoint
unconditionally. 'Object >> halt: aString' in VisualWorks pops up
a notifier dialogue with 'aString' displayed. This way you can 
identify from where the breakpoint was set. This is useful for
debugging when you want to proceed to the next breakpoint without
checking the source. You can name breakpoints effectively.

nji
:-)

 
