«

jacob navia wrote:
>
> In principle this is correct. But I have gotten used to develop in the
> debugger. I write a part to access some data structures, and put a
> breakpoint where the calculations/usage of those data structures are
> to be inserted. Then, within the debuggers, I write the new code.
>
Why don't you just write unit teats?

Checking code with a debugger is all well and good, but it's a one off
and can't be automated.

--
Ian Collins.

Ian Collins <ian-> writes:

> jacob navia wrote:
>>
>> In principle this is correct. But I have gotten used to develop in the
>> debugger. I write a part to access some data structures, and put a
>> breakpoint where the calculations/usage of those data structures are
>> to be inserted. Then, within the debuggers, I write the new code.
>>
> Why don't you just write unit teats?

because there are not the test case writers in existence who can cover
ALL situatins and bugs DO occue wich need

a) finding
b) familiarising with
b) fixing
c) testing
d) integrating back in

>
> Checking code with a debugger is all well and good, but it's a one off
> and can't be automated.

Did you read what he said? He uses the debugger to test (as I do) as he
is writing the code. This is often a long time before any unit tests in
time constrained projects.

Richard wrote:
> Ian Collins <ian-> writes:
>
>> jacob navia wrote:
>>> In principle this is correct. But I have gotten used to develop in the
>>> debugger. I write a part to access some data structures, and put a
>>> breakpoint where the calculations/usage of those data structures are
>>> to be inserted. Then, within the debuggers, I write the new code.
>>>
>> Why don't you just write unit teats?
>
> because there are not the test case writers in existence who can cover
> ALL situatins and bugs DO occue wich need
>
He was talking about new code, not debugging.

>
>> Checking code with a debugger is all well and good, but it's a one off
>> and can't be automated.
>
> Did you read what he said? He uses the debugger to test (as I do) as he
> is writing the code. This is often a long time before any unit tests in
> time constrained projects.
>
Ah, well I write my tests first, especially in time constrained
projects. The less time I have to spend tracking down bugs in untested
code, the faster I work.

--
Ian Collins.

On Mar 19, 4:47*am, jacob navia <ja...@nospam.com> wrote:
> Yes. But that is not the case today. Debuggers are no longer expensive.
>
> My objective with this series is to attract young people and technically
> interested people into this group. To show that C doesn't live in the
> past but it has a future. Your post is interesting, but doesn't apply to
> the environments of today.


As other have pointed out, yes, it does, many environments in which C
is used are not handy, easy, cheap, or whatever, places to run
debuggers. And as I mentioned later in my post, I spend a lot of my
time in such places.

I described the mainframe environment because your position seems to
be that such a development methodology is impossible, when, in fact,
it was very common, and widely used even by programmers of modest
talents, not all that long ago.


> In principle this is correct. But I have gotten used to develop in the
> debugger. I write a part to access some data structures, and put a
> breakpoint where the calculations/usage of those data structures are
> to be inserted. Then, within the debuggers, I write the new code.


As I mentioned, I know people who do that, and they seem to write
plenty of code. This methodology works for you, and you've clearly
written a significant chuck of code that way. Bully for you.

*I* don't like to work that way. I find the debugger to be much more
of a distraction than an asset in the ordinary course of events, and I
avoid it until I feel it's going to be a useful tool to use. I
personally find my way of doing things a superior technique, although
I'm perfectly willing to acknowledge that your way works for you.
OTOH, you've claimed that such an approach is impossible or silly, and
accused some people who claim to use that approach of being liars.
Just because you don't like that way of coding, is no reason to
dismiss it.

And just for grins, you should try Cleanroom* sometime, where not only
do you not get to use a debugger, you don't get to use the compiler
either...

*Personally I'd hate to work under those conditions

Ian Collins wrote:
> Richard wrote:
>> Ian Collins <ian-> writes:
>>
>>> jacob navia wrote:
>>>> In principle this is correct. But I have gotten used to develop in the
>>>> debugger. I write a part to access some data structures, and put a
>>>> breakpoint where the calculations/usage of those data structures are
>>>> to be inserted. Then, within the debuggers, I write the new code.
>>>>
>>> Why don't you just write unit teats?
>> because there are not the test case writers in existence who can cover
>> ALL situatins and bugs DO occue wich need
>>
> He was talking about new code, not debugging.
>
>>> Checking code with a debugger is all well and good, but it's a one off
>>> and can't be automated.
>> Did you read what he said? He uses the debugger to test (as I do) as he
>> is writing the code. This is often a long time before any unit tests in
>> time constrained projects.
>>
> Ah, well I write my tests first, especially in time constrained
> projects. The less time I have to spend tracking down bugs in untested
> code, the faster I work.
>


You are missing most of what an integrated development environment
has to offer then.

It is easy to find out how that member of structure x was called. You
just type

x.

and then the IDE shows you the structure members list. You have just
choose the right one.

You can see the values of all key variables at the point where
you will introduce new code.

You can then, set the program counter several lines before and exercise
the new code immediately with JIT debugging (a capability lcc-win
doesn't have yet, I have to confess)

You can just right click into "go to definition" and you can see
where that variable or that function is defined.

All this makes for far less bugs than using a simple editor.

Obviously I start with the test case too. If not, I can't develop
correctly.

For instance, when I want to add a new functionality to the
compiler I start with a program that should compile, and then
work from there.

But obviously your mileage can be different.



--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

wrote:
> OTOH, you've claimed that such an approach is impossible or silly, and
> accused some people who claim to use that approach of being liars.
> Just because you don't like that way of coding, is no reason to
> dismiss it.

I am not dismissing it. What I just do not believe are the wild
claims being done here like Mr Heathfield saying he can debug
code over the phone without seeing it, or the others with their
stories of debugging with "just reading the code", etc.

But obviously I can debug code by reading it, and I do read
my code (and other people's ) very often. And, at the end
OBVIOUSLY the debugger can show you the source code but will
NOT tell you "the bug is in line 42"!

*YOU* have to find it,and you will find it by reading what the
debugger shows you. So I can't be against reading code.

The "super hero" stories however, I leave them to my son
(and daughter) that read a lot of comics.

Obviously reading code is a good method, as are code reviews,
and many other techniques.

But let's face it, a debugger is a real time saver. And if
you work in embedded realm, I have devloped debuggers for
very small chips (as I wrote in my previous post in this subject),
and as soon as my debugger was up and running, the programmers
immediately loved it, and it was considered *the* most important
piece of the development environment.

The theory behind it (read that article of Hanson, it is a good
read) it is very simple and can be used anywhere: a small monitor
that will allow to read selectively memory and register values
from the circuit being developed.

A serial line is all is needed!


--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

jacob navia wrote:
> Ian Collins wrote:

>> Ah, well I write my tests first, especially in time constrained
>> projects. The less time I have to spend tracking down bugs in untested
>> code, the faster I work.
>>
>
>
> You are missing most of what an integrated development environment
> has to offer then.
>
> It is easy to find out how that member of structure x was called. You
> just type
>
> x.
>
> and then the IDE shows you the structure members list. You have just
> choose the right one.
>
That's an IDE feature, not a debugger one. It is also one that drives
me nuts, so I turn it off. I prefer to have the header open in another
window and use two mouse clicks to copy the member over.

>
> You can then, set the program counter several lines before and exercise
> the new code immediately with JIT debugging (a capability lcc-win
> doesn't have yet, I have to confess)
>
But that's a one off manual process. If you write a unit test to
validate the change, it becomes part of your automated test suite which
can be run each time you build.

--
Ian Collins.

jacob navia said:

<snip>

> What I just do not believe are the wild
> claims being done here like Mr Heathfield saying he can debug
> code over the phone without seeing it, or the others with their
> stories of debugging with "just reading the code", etc.

Not only are these "wild claims" true, but they don't even describe
anything particularly clever. Debugging unseen code is *usually*
impossible (which is why we ask people here to show us their code) - but
*sometimes* it can be done, and although it creates a great impression, it
normally only happens when the code's author is a relative newcomer to C
or to programming, and has stumbled into a common trap. Debugging code by
reading it, without a debugger - this idea that Mr Navia finds so hard to
believe, is done by clc regulars daily - *right here in clc*. I can't
imagine that any of us particularly need to fire up a debugger for most of
the problems posed here.

> But obviously I can debug code by reading it,

Right - so you don't need a debugger after all. It's just a nice-to-have
for those who are good at taking advantage of its features.

<snip>

> But let's face it, a debugger is a real time saver.

For you, maybe. For me, it was a big time *sink*, and when I stopped using
it I saved a considerable amount of time. Your disbelief does not change
the facts.

<snip>

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

Ian Collins <ian-> writes:

> jacob navia wrote:
>> Ian Collins wrote:
>
>>> Ah, well I write my tests first, especially in time constrained
>>> projects. The less time I have to spend tracking down bugs in untested
>>> code, the faster I work.
>>>
>>
>>
>> You are missing most of what an integrated development environment
>> has to offer then.
>>
>> It is easy to find out how that member of structure x was called. You
>> just type
>>
>> x.
>>
>> and then the IDE shows you the structure members list. You have just
>> choose the right one.
>>
> That's an IDE feature, not a debugger one. It is also one that drives

A debugger is frequently part of an IDE.

> me nuts, so I turn it off. I prefer to have the header open in another
> window and use two mouse clicks to copy the member over.

Then I would hazard that you haven't used a well configured one.

The same is true of maybe watching a certain member of a struct not
specifically mentioned in the code you are looking at.

>>
>> You can then, set the program counter several lines before and exercise
>> the new code immediately with JIT debugging (a capability lcc-win
>> doesn't have yet, I have to confess)
>>
> But that's a one off manual process. If you write a unit test to
> validate the change, it becomes part of your automated test suite which
> can be run each time you build.

So what? You can pass all the unit tests you want and it still doesn't
stop the entire application having bugs.

Ian Collins wrote:
> jacob navia wrote:
>
>> In principle this is correct. But I have gotten used to develop
>> in the debugger. I write a part to access some data structures,
>> and put a breakpoint where the calculations/usage of those data
>> structures are to be inserted. Then, within the debuggers, I
>> write the new code.
>
> Why don't you just write unit teats?
>
> Checking code with a debugger is all well and good, but it's a
> one off and can't be automated.

I did something similar (debugger tests) about 50 years ago. Then
I learned better methods.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.



--
Posted via a free Usenet account from http://www.teranews.com