OO debuggers 
Author Message
 OO debuggers

I am currently conducting some research into object oriented debugging tools
and techniques. I have been surprised and disappointed to learn that most
of the testing/debugging tools I have come across for OO languages seem to
be merely poor conversions of procedure-oriented language de{*filter*}s. It is
neither polite nor legal to mention any products by name, but with few
exceptions, most OO debugging tools seem to be afterthoughts. I might be
wrong, but I think that languages of a (relatively) new paradigm like OOP
need *new* innovative support tools to back them. Does anyone out there have
any opinions about this?

With this in mind, has anyone out there used a OO debug tool (or related
utility) of any real merit? Do you feel that a tool should be specialized
for the paradigm (or even language) which it supports?

In connection with this, does anyone have the addresses (email or otherwise)
of the following:-

Norm Kerth (University of Portland)
Dan Moore  (US West)

Both of whom submitted some interesting comments to the OO Tools workshop of
OOPSLA 87.

I would be eternally grateful for any help
J.P.

****************************************************************************
FROM: Jan Andrew Purchase           | Snail:     Room 208, PhD Lab.,
at : pyr1.cs.ucl.ac.uk              |            Computer Science Dept.,
                                    |            University College,
                                    |            London, UK.
                                    |


****************************************************************************
      (these are my views, and are not necessarily those of UCL)
****************************************************************************



Wed, 17 Feb 1993 21:25:00 GMT  
 OO debuggers

Hi Jan,

address of Norman Kerth is :

The University of Portland
Applied Research Center
Multnomah School of Engineering
5000 North Willamette Blvd.
Portland, Oregon 97203-5978.

Winnie.



Wed, 17 Feb 1993 16:44:00 GMT  
 OO debuggers
<<I am currently conducting some research into object oriented debugging tools
and techniques.  I have been surprised and disappointed to learn that most of
the testing/debugging tools I have come across for OO languages seem to >be
merely poor conversions of procedure-oriented language de{*filter*}s. >>

<...this lack of debugging tools is not confined to the OO domain. I defy you
to show you one generally-available de{*filter*} that is the least bit
"innovative".>

Unfortunately, C++ has taken the language veneer of object-orientation, just as
the Macintosh took the user-interface veneer.  Unless you narrowly define
"generally-available" as "one I can use on an arbitrary Unix object file", you
should look closely at the generally available Smalltalk-80 de{*filter*}, or even
the less capable, but more generally available (meaning cheaper), Smalltalk-V
de{*filter*}.  (I think "generally available" means you can buy it for a reasonable
price for the most popular computing platforms.)

C++ has a lot of catching up to do, but it seems to be evolving strictly in the
{*filter*}uous C-Unix environment.  It currently provides nowhere near the
productivity nor capability (except in execution speed, the least important
metric in the present "software crisis") of even a moderate Smalltalk
implementation, nor will it as long as people are thinking of dbx as the model
to improve upon!  C'mon, guys, if you're going to make things better, at least
start with what was state-of-the art in 1980!

:::::: Software Productivity Technologies -- Experiment Manager Project ::::::
:::::: Jan Steinman N7JDB       Box 500, MS 50-383      (w)503/627-5881 ::::::



Wed, 17 Feb 1993 18:19:00 GMT  
 OO debuggers
Quote:



>><...this lack of debugging tools is not confined to the OO domain. I defy you
>>to show you one generally-available de{*filter*} that is the least bit

                  ^^^^^^^^^^^^^^^^^^^

Quote:
>>"innovative".>

       Notice the operative adjective.

Quote:
>C++ has a lot of catching up to do, but it seems to be evolving strictly in the
>{*filter*}uous C-Unix environment.  It currently provides nowhere near the
>productivity nor capability (except in execution speed, the least important
>metric in the present "software crisis") of even a moderate Smalltalk
>implementation, nor will it as long as people are thinking of dbx as the model
>to improve upon!  

      Tom Cargill's Pi (Process Inspector) de{*filter*} is a step in the right
direction in the UNIX-C Domain.  Unfortunately, it is only available on the
research editions of UNIX.  With bit-mapped displays becoming more prevelant
these days, perhaps we shall see more efforts like this appear as commercial
products.  We need more than a fancy UI for dbx!  See the following papers:

        T. A. Cargill, "The Feel of Pi", 1986 Winter USENIX Conference
Proceedings, pp. 62-71.

        T.A. Cargill, "Pi: A Case Study in Object-Oriented Programming",
OOPSLA'86 Conference Proceedings, pp. 350-360.

--
George W. Leach                                 Paradyne Corporation
..!uunet!pdn!reggie                             Mail stop LF-207
Phone: (813) 530-2376                           P.O. Box 2826
                                                Largo, FL  34649-2826



Wed, 17 Feb 1993 11:31:00 GMT  
 OO debuggers

Quote:

>C++ ... seems to be evolving strictly in the
>{*filter*}uous C-Unix environment.  It currently provides nowhere near the
>productivity nor capability (except in execution speed, the least important
>metric in the present "software crisis") of even a moderate Smalltalk
>implementation...

Au contraire, execution speed is a major metric in the software crisis,
although somewhat indirectly:  it is important because lack of it leads to
otherwise-promising software tools being rejected as impractical.  Whether
this is rational or not -- and personally I think there is much to be said
for it -- it is the way things are.  Smalltalk's performance problems, more
than anything else, have given it its reputation of being a nice toy for
researchers and nothing more.  I don't think anybody would claim that C++
is as nice as Smalltalk, but it moves a useful distance in the right
direction, and it does a much better job of meeting performance constraints
that are considered non-negotiable in many applications.

Let us not forget how C became a major programming language, while many
prettier languages were forgotten, by being more practical.  C++ is "the
next C" in more ways than one.
--
NASA is into artificial        |     Henry Spencer at U of Toronto Zoology



Wed, 17 Feb 1993 00:22:00 GMT  
 OO debuggers


<<C++... provides nowhere near the productivity nor capability (except in
execution speed, the least important metric in the present "software crisis")
of even a moderate Smalltalk implementation...>>

<Au contraire, execution speed is a major metric in the software crisis...
because lack of it leads to otherwise-promising software tools being rejected
as impractical...  Smalltalk's performance problems, more than anything else,
have given it its reputation...>

This is close to what I was describing:

<<C++ has a lot of catching up to do, but it seems to be evolving strictly in
the  {*filter*}uous C-Unix environment...>>

Smalltalk is rejected for its reputation, not for anything based in recent
fact.  Most people who have seriously considered Smalltalk for projects, and
then rejected it, have a slew of other problems with it, but they generally are
willing to take a modest performance hit for what it buys them.  Let's look at
a few cases:

Garbage collection: yes, it's a pain when it fires off in the middle of some
critical code.  It's more of a pain when, through "programmer garbage
collection" you destroy an object that still has references, or when unused,
undestroyed objects fragment memory space, or when a project runs over because
destructor conventions were not followed consistently, none of which happens in
Smalltalk.  The solution is not to throw out GC as performance-costly, but to
build better collectors, and to give users some degree of control.  Most who
gripe at GC would be satisfied with some kind of "don't you dare interrupt me
till I'm through with this stuff" directive.

Run-time binding:  in my opinion, any C++ application that does not use virtual
functions is not object oriented, and those that do are difficult to design,
and often lack the flexibility of true polymorphism.  In Smalltalk, the
programmer doesn't even have to think about it -- it just happens.  By
dispatching through function tables instead of truly implementing run-time
binding, C++ gains only slightly.  Typical Smalltalk run-time binding enjoys a
97% method cache hit rate, negating most of the arguments of those who claim
run-time binding is a major performance bottleneck.

Byte-code interpretation: this is the one that makes C++ers laugh!  How dare
anyone use a system that "wastes" so much time simply figuring out what it has
to do!  However, look what it buys Smalltalk: incremental compilation (yes, I
know there are other ways to do this, why doesn't Unix/C do them?) and true
object-oriented control over the execution state.  It can be argued that the
first (in combination with run-time binding) is a major source of productivity
in Smalltalk -- you can change and run a method of a moderately sized
application ten times in the time consumed by one C++ edit-compile-link-run
cycle.  I don't expect those who's experience is limited to "traditional"
de{*filter*}s to truly understand the enormous power the latter gives you: to carry
on a dialogue with an execution state is much more than finding new ways of
changing memory locations and breakpointing!

Hardware is getting faster and faster.  Let us be reminded that the first
fortran compilers were greeted with contempt by those who said they wouldn't
produce adequately performing code.  "Adequately performing" is a relative
constant in many, many fields, and the leaps in performance that hardware is
giving us should be put to use reducing the software life-cycle cost.  If a
spreadsheet that took two months to build in Smalltalk performs just as well as
an identical one that took two years to build in C++, who cares if some
interpreter somewhere is chewing up 15% of the cycles?  By emphasizing "the
performance issue", people do stupid things like make benchmarks run fast,
rather than making systems more usable.

The big win is an area that is receiving distressing little research or
attention: hybrid systems.  "Smalltalk as a controller" is showing big success
with the work of Dave Thomas at CMU and{*filter*} Peskin at Rutgers, among others.  
Smalltalk appears to be ideally suited for rapidly assembling (an
re-assembling) optimally performing "computational units", whether they be
multi-processor nodes or snippets of assembly/C/C++ generated code.  PPS shows
little interest in this area, preferring to "protect their users from
themselves", while Digitalk has provided the hooks, but is too busy shipping
orders to put it all together.  Tektronix is the leader here, but is
unfortunately limited to Tektronix platforms through oppressive licensing.

<Let us not forget how C became a major programming language, while many
prettier languages were forgotten, by being more practical.  C++ is "the next
C" in more ways than one.>

And just as C was "a smart assembler" before it, C++ is simply providing a
prettier face for the same set of problems that are causing software costs to
go out of control.  I am not a Smalltalk chauvinist.  It is not without its
problems.  I even happen to like Unix and C++.  What I argue against is the
narrow-mindedness that many in the Unix/C community show for "other" conceptual
models; such thinking keeps them from even considering the next set of
problems.

(OK, I'd better say it: the above statements are my personal views only, and
some of them most certainly do not reflect the views of Tektronix.)

:::::: Software Productivity Technologies -- Experiment Manager Project ::::::
:::::: Jan Steinman N7JDB       Box 500, MS 50-383      (w)503/627-5881 ::::::



Wed, 17 Feb 1993 17:59:00 GMT  
 OO debuggers

Quote:
>      Tom Cargill's Pi (Process Inspector) de{*filter*} is a step in the right
>direction in the UNIX-C Domain.  Unfortunately, it is only available on the
>research editions of UNIX.  With bit-mapped displays becoming more prevelant
>these days, perhaps we shall see more efforts like this appear as commercial
>products.  We need more than a fancy UI for dbx!  See the following papers:

>    T. A. Cargill, "The Feel of Pi", 1986 Winter USENIX Conference
>Proceedings, pp. 62-71.

>    T.A. Cargill, "Pi: A Case Study in Object-Oriented Programming",
>OOPSLA'86 Conference Proceedings, pp. 350-360.

Does anybody have more references to papers on debugging ?
Please send me (E-)mail.

My special interest is debugging parallel/distributed programs. Any references
to OO-debugging papers are appreciated.

        Danny Backx

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
 Danny Backx                            |  mail: Danny Backx
 Tel: +32 16 200656 x 3544              |        Katholieke Universiteit Leuven
 Fax: +32 16 205308                     |        Dept. Computer Science

         ... mcvax!prlb2!kulcs!dannyb   |        B-3030 Leuven



Wed, 17 Feb 1993 13:12:00 GMT  
 OO debuggers
Oops!  I bet Dave Thomas was suprised when he woke up in Pittsburgh this
morning!  In my previous article, I mistakenly affiliated him with CMU.  Dave
Thomas is with Carleton University in Ottowa.

(Thanks to the readers who noticed the error.)

:::::: Software Productivity Technologies -- Experiment Manager Project ::::::
:::::: Jan Steinman N7JDB       Box 500, MS 50-383      (w)503/627-5881 ::::::



Wed, 17 Feb 1993 16:18:00 GMT  
 OO debuggers

Quote:

>Garbage collection: yes, it's a pain when it fires off in the middle of some
>critical code...

Personally, I rather like the idea of garbage collection, although I'm
not entirely convinced we know how to keep it under control.  Note that
there are experimental garbage-collecting allocators for C and/or C++.
You don't need Smalltalk for that.

Quote:
>Run-time binding: in my opinion, any C++ application that does not use virtual
>functions is not object oriented...

Puh-leeze, let us not get back into the debate about what "object oriented"
means.  (Although I do tend to agree.)

Quote:
>... Typical Smalltalk run-time binding enjoys a
>97% method cache hit rate, negating most of the arguments of those who claim
>run-time binding is a major performance bottleneck.

Well, I would point out that atypical cases are often a significant
performance issue.  Also, you miss another aspect of the difference:
run-time binding makes compile-time checking a lot harder.  This is not
a trivial issue for production programs, which are supposed to be right
*before* they are released.

Quote:
>...look what [interpretation] buys Smalltalk: incremental compilation (yes, I
>know there are other ways to do this, why doesn't Unix/C do them?)...

If you look around, you will find no shortage of people willing to sell you
incremental interpretive environments for C.  Now, how about showing me a
high-performance compile-time-checked environment for Smalltalk? :-)

Quote:
>Hardware is getting faster and faster.

The hardware installed in any given location gets faster only occasionally.
There is still a heavy premium for getting maximum use out of a specific
hardware configuration.

Quote:
>Let us be reminded that the first
>FORTRAN compilers were greeted with contempt by those who said they wouldn't
>produce adequately performing code...

Let us be reminded that the first FORTRAN compiler was accepted mostly
because those people were *wrong*:  it *DID* produce red-hot code, usually
equal to or even superior to what human assembly coders could do.  Backus
and his team at IBM worked long and hard to make this happen, and they are
seldom given adequate credit for it.  They knew what their customers'
priorities were, and they knew that excuses like "hardware is getting faster
and faster" wouldn't cut it.  They not only invented the true compiler,
they invented the super-optimizing compiler.

Quote:
>"Adequately performing" is a relative
>constant in many, many fields, and the leaps in performance that hardware is
>giving us should be put to use reducing the software life-cycle cost...

As Mike O'Dell observed a while ago (roughly):  "the machines keep getting
faster, but somehow the response at my keyboard hasn't improved much".  Too
many of the improvements in hardware performance are being eaten up by
software writers who assume that they don't have to care about efficiency
any more.

Quote:
>...  By emphasizing "the
>performance issue", people do stupid things like make benchmarks run fast,
>rather than making systems more usable.

By emphasizing "making systems more usable", people do stupid things like
building a system that has ultra-spiffy demos but bogs down hopelessly
when you try to use it for real work.  Ask Apple about the Lisa.

Quote:
>The big win is an area that is receiving distressing little research or
>attention: hybrid systems...

I agree that there is real promise there, although it's not clear to me
that Smalltalk is the ideal upper-level language for it.

Quote:
><Let us not forget how C became a major programming language, while many
>prettier languages were forgotten, by being more practical.  C++ is "the next
>C" in more ways than one.>

>And just as C was "a smart assembler" before it, C++ is simply providing a
>prettier face for the same set of problems that are causing software costs to
>go out of control...

You know, oddly enough, the people who tell me that C is "just a smart
assembler" have a tendency to define anything that their pretty little
language can't solve as "not a real problem", ignoring the fact that C
copes with it just fine.  The same silly remark can be made about most
programming languages; it is no more true for C than for the rest.

By the same token, Smalltalk is just smart BASIC, a prettier face for
the problems that have kept interpretive languages out of mainstream
production programming.

Quote:
>I am not a Smalltalk chauvinist.  It is not without its
>problems.  I even happen to like Unix and C++...

Actually, I'm not a C/C++ (Unix has little to do with this) chauvinist either.
Smalltalk has its points.  Unfortunately, while the C community has a
lamentable tendency to stress efficiency and disregard the importance of
easing development, the Smalltalk community tends to go the other way,
stressing easy development and ignoring the quality of the result.  There
is an important distinction here:  easy development of a program is valuable
(and getting more so all the time), but adequate performance of the result
is often a *constraint*, i.e. a non-negotiable requirement that absolutely
must be met.  To some extent the difference is a matter of perceptions
rather than deep underlying need, but that *is* the way things work today.
--
NASA is into artificial        |     Henry Spencer at U of Toronto Zoology



Wed, 17 Feb 1993 20:06:00 GMT  
 OO debuggers

Quote:

>As Mike O'Dell observed a while ago (roughly):  "the machines keep getting
>faster, but somehow the response at my keyboard hasn't improved much".  Too
>many of the improvements in hardware performance are being eaten up by
>software writers who assume that they don't have to care about efficiency
>any more.

      Another factor eating away at the improvements in hardware is the
increased functionality we expect from them.  We now have graphical user
interfaces, expert systems and relational databases to contend with.  These
all consume resources.  The systems we are building are far more ambitious
than those built years ago.  The more powerful you make the tools the more
applicable those tools become to difficult problems.

--
George W. Leach                                 Paradyne Corporation
..!uunet!pdn!reggie                             Mail stop LF-207
Phone: (813) 530-2376                           P.O. Box 2826
                                                Largo, FL  34649-2826



Wed, 17 Feb 1993 13:52:00 GMT  
 OO debuggers

KEY:

Quote:



>>>I have been surprised and disappointed to learn that most
>>>of the testing/debugging tools I have come across for OO languages seem to
>>>be merely poor conversions of procedure-oriented language de{*filter*}s.
>>So we have poor conversions of poor products ...
>>>I might be wrong, but I think that languages of a (relatively) new paradigm
>>>like OOP need *new* innovative support tools to back them. Does any one out
>>>there have any strong opinions about this?
>>You are not wrong - you are absolutely right.
>>However, this lack of debugging tools is not confined to the OO domain.
>>I defy you to show you one generally-available de{*filter*} that is the least
>>bit "innovative".  They all seem to be stuck in the Linton dbx mold --
>>i.e. dumb terminal textual rather than multiple window graphical (no
>>offense Mark, but the time has come to move on).  From what I can gather
>>there are precious few people working on the debugging problem
>>(Zellwegger and Cargill are exceptions).

I could not agree more. During my preliminary literature survey I noticed a
distinct lack of any truly innovative work after 1985. With the exceptions
of Bruegge and Cargill. One of my colleagues conducted a survey (amongst
colleges in London University) which showed that 40% of programmers *never*
use de{*filter*}s and of these who do 25% consider that they are not very useful
because they are: too cumbersome to use; are too difficult to learn and have
inadequate user interfaces. The lack of good tools, both OO and otherwise is
a problem.

Quote:
>>>With this in mind, has anyone out there used a OO debug tool (or related
>>>utility) of any real merit?
>>No (see above).  In my humble opinion, gdb+ doesn't even come close.
>>(Although, admittedly, it's better than almost anything else).

You mean you got gdb+ to work? I could get it to debug straightforward c++
but as soon as I used the methods-display command or any of the extra "OO
facilities" it went spurious on me.

Quote:
>you should look closely at the generally available Smalltalk-80 de{*filter*}, or
>even the less capable, but more generally available (meaning cheaper),
>Smalltalk-V de{*filter*}.  (I think "generally available" means you can buy it
>for a reasonable price for the most popular computing platforms.)

I have. I am preparing a few internal research reports on it now. Agreed its
better than gdb+ and one could not even begin to compare it to dbx (or
dbxtool) but it has its problems.

Quote:
>C++ has a lot of catching up to do, but it seems to be evolving strictly in
>the {*filter*}uous C-Unix environment.

Agreed. Sad isn't it?

Quote:
> ..execution speed, the least important metric in the present "software
> crisis" ...

I'm not sure I agree fully here. Although you are undoubtedly right
generally, one of the important properties of a de{*filter*} is that it has
minimal effect on the observable run-time behaviour of one's program.
Smalltalk's de{*filter*} (and one or two others I have used) falls over here.
Having to wait a minute for the de{*filter*} to simulate a method that
usually concludes in 200mS is unacceptable -- especially if you are
not informed of the delay in advance.

Quote:
>C'mon, guys, if you're going to make things better,
>at least start with what was state-of-the art in 1980!

I'm working on it!

Quote:
>>> Jan Purchase
>>  Jon Becher
>   Jan Steinman

Thanks for listening...

****************************************************************************
FROM : Jan Andrew Purchase          | Snail:     Room 208, PhD Lab.,
at   : pyr1.cs.ucl.ac.uk            |            Computer Science Dept.,
                                    |            University College,
                                    |            London, UK.
                                    |


****************************************************************************
      (these are my views, and are not necessarily those of UCL)
****************************************************************************



Wed, 17 Feb 1993 19:59:00 GMT  
 OO debuggers


Now, how about showing me a
high-performance compile-time-checked environment for Smalltalk? :-)
/* End of text from p.cs.uiuc.edu:comp.lang.smalltalk */

Typed Smalltalk is a high-performance compile-time-checked environment
for Smalltalk.  It is not finished yet, but we are starting to get
results.  There is a paper about it at OOPSLA'88, and I would be glad
to talk about it there with anybody else who is going.  Leave a message
for me at the message board and we can try to get together.

Ralph Johnson



Wed, 17 Feb 1993 16:25:00 GMT  
 OO debuggers

I have now seen this remark flash by my scream a couple of times:

 > C++ has a lot of catching up to do, but it seems to be evolving strictly in
 > the {*filter*}uous C-Unix environment.

and somebody even agrees:

 > Agreed. Sad isn't it?

I'm not sure the C/UNIX environment is more ``{*filter*}uous'' than other
environments, but even if it is the statement is flat wrong. C++ work
- including work that will directly affect the language and the way
it is used - is going on in other environments including the Mac, the
PCclone world, and Smalltalk.

Come on guys. C++ hasn't been generally available for 3 years yet.
It hasn't even completed its planned growth in its native UNIX environment.
How fast do you expect evolution to work?



Wed, 17 Feb 1993 01:34:00 GMT  
 OO debuggers


<<...you should look closely at the generally available Smalltalk-80
de{*filter*}...>

<I have... but it has its problems.>

I'm glad you have,and I agree that it is not without problems.  The fact that
it is quite different than most de{*filter*}s is what I want people to pay
attention to.  It's a matter of "execution state as an object" vs "rape and
pillage the process".

<<...execution speed, the least important metric in the present "software
crisis"...>>

(Boy, am I catching flak for this statement!)

<...one of the important properties of a de{*filter*} is that it has minimal effect
on the observable run-time behaviour of one's program. Smalltalk's de{*filter*}...
falls over here. Having to wait a minute for the de{*filter*} to simulate a method
that usually concludes in 200mS is unacceptable -- especially if you are not
informed of the delay in advance.>

(More specifically, the Smalltalk-80 V2.2 de{*filter*} from PPS.)  I plead the
ultimate cop-out, "it's an implementation detail."  It's unfortunate if anyone
has formed an impression of Smalltalk performance based on the de{*filter*}.  The
Tektronix Smalltalk de{*filter*} runs at full execution speed, while the original
Version 2 de{*filter*} (and PPS follow-ons) interpret (in Smalltalk) the executing
method.  I do not know how Smalltalk-V handles this, although I have heard good
things about their 286-version de{*filter*}.

But I digress.  Henry Spencer would turn this discussion into a
Smalltalk-bashing session, and seems to be unwilling to discuss the
shortcomings of C++ when used for OO.  I'm unwilling to be pressed into
defending Smalltalk, rather I'm saying, "Why aren't all you C++ object-oriented
neophytes looking at the rich body of OO knowledge that has evolved in
Smalltalk?", with the de{*filter*} as an example.

And also with the de{*filter*} as an example, I'm pointing out that C++
inadequately addresses Smalltalk's greatest strengths: rapid prototyping and
incremental development.  Smalltalk excels at the "make it work, then make it
fast" model of development, whereas it appears to me that C++ is heading in the
direction of more up-front design work, and less in the direction of promoting
evolutionary development.

I can only laugh sadly when I hear the unspoken undercurrent: "Now that C is
object-oriented, there's no longer any need for Smalltalk.", and am dismayed
that a whole generation is doomed to think C++ synonymous with
object-orientation.  ("Huh, what's Smalltalk?")  I am gratified that Jan Andrew
Purchase is taking a larger view than most OO newcomers have taken.

:::::: Software Productivity Technologies -- Experiment Manager Project ::::::
:::::: Jan Steinman N7JDB       Box 500, MS 50-383      (w)503/627-5881 ::::::



Wed, 17 Feb 1993 21:52:00 GMT  
 OO debuggers

Quote:

>I'm unwilling to be pressed into defending Smalltalk, rather I'm saying, "Why
>aren't all you C++ object-oriented neophytes looking at the rich body of OO
>knowledge that has evolved in Smalltalk?", with the de{*filter*} as an example.

I'll bite.  Is it something that can be adequately described in a
usenet article?

--
Steve Simmons           ...!umix!itivax!vax3!scs
Industrial Technology Institute, Ann Arbor, MI.
"You can't get here from here."



Wed, 17 Feb 1993 17:51:00 GMT  
 
 [ 17 post ]  Go to page: [1] [2]

 Relevant Pages 

1. OO debugger usage

2. OO debugger usage

3. OO debugger usage

4. OO debugger usage

5. Debugger for tcl/tk and OO tcl

6. Debuggers, Static Debuggers, and Algebraic Steppers

7. using python debugger (pdb) inside emacs debugger mode ...

8. SENIOR OO SOFTWARE DEVELOPER WITH OO SAVVY - TORONTO

9. OO SOFTWARE DEVELOPER WITH OO SAVVY - TORONTO

10. OO SOFTWARE DEVELOPER WITH OO SAVVY - TORONTO

11. OO SOFTWARE DEVELOPER WITH OO SAVVY - TORONTO

12. Use of O.O. metrics to estimate the effert and cost of O.O. projects

 

 
Powered by phpBB® Forum Software