Newsgroups: comp.lang.smalltalk
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!news.mathworks.com!news.kei.com!world!news.bu.edu!gw1.att.com!nntpa!ssbunews!ssbunews.ih.att.com!lgm
From: lgm@polaris.ih.att.com (Lawrence G. Mayka)
Subject: Re: Smalltalks need less intrusive breakpoint mechanism
In-Reply-To: dsiegel@panix.com's message of 16 Feb 1995 11:27:54 -0500
Message-ID: <LGM.95Feb26145436@polaris.ih.att.com>
Sender: news@ssbunews.ih.att.com (Netnews Administration)
Nntp-Posting-Host: polaris.ih.att.com
Organization: AT&T Bell Laboratories, Naperville, Illinois, USA
References: <MACRSHAP.95Feb16110652@labs-n.bbn.com> <3hvuea$3a0@panix.com>
Date: Sun, 26 Feb 1995 20:54:36 GMT
Lines: 30

In article <3hvuea$3a0@panix.com> dsiegel@panix.com (David Siegel) writes:

   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?

Yes, ADVISE or DEFADVICE (this is not entirely standardized,
unfortunately) typically accepts an arbitrary computation as the body
of the "advice."  Such advice can also typically be compiled for
speed, in contrast to typical extensions of TRACE, which also may
accept arbitrary computations but execute them interpretively.
--
        Lawrence G. Mayka
        AT&T Bell Laboratories
        lgm@ieain.att.com

Standard disclaimer.
