Prev: IDE for C with good context sensitive help
Next: KOBWEB JAVA
From: Patricia Shanahan on 19 May 2010 16:01
stan wrote:
....
> I agree with the others as to possible causes, but I might add
> that this may be a perfect time to learn to step through code in a
> debugger. You might discover the problem with your code and you will
> certainly learn a skill which can be very handy. It won't be time
> wasted. Debuggers are not a silver bullet, they can't solve every
> problem all the time. But when you fine yourself stumped you can never
> have too many tools available.

Good advice. The OP needs to be particularly careful to debug a version
that actually fails, not a similar program that works.

Patricia
From: amelia jane on 19 May 2010 18:56
On May 19, 1:01 pm, Patricia Shanahan <p...(a)acm.org> wrote:
> stan wrote:
>
> ...
>
> > I agree with the others as to possible causes, but I might add
> > that this may be a perfect time to learn to step through code in a
> > debugger. You might discover the problem with your code and you will
> > certainly learn a skill which can be very handy. It won't be time
> > wasted. Debuggers are not a silver bullet, they can't solve every
> > problem all the time. But when you fine yourself stumped you can never
> > have too many tools available.
>
> Good advice. The OP needs to be particularly careful to debug a version
> that actually fails, not a similar program that works.
>
> Patricia

It was a real dumb problem. The variable in the loop was incremented
elsewhere making the loop to end prematurely. My bad...
From: Dann Corbit on 19 May 2010 19:38
In article <c90e4442-455f-4ca9-b9fb-e20c04c09b40
@z15g2000prh.googlegroups.com>, ameliajane42(a)gmail.com says...
>
> On May 19, 1:01�pm, Patricia Shanahan <p...(a)acm.org> wrote:
> > stan wrote:
> >
> > ...
> >
> > > I agree with the others as to possible causes, but I might add
> > > that this may be a perfect time to learn to step through code in a
> > > debugger. You might discover the problem with your code and you will
> > > certainly learn a skill which can be very handy. It won't be time
> > > wasted. Debuggers are not a silver bullet, they can't solve every
> > > problem all the time. But when you fine yourself stumped you can never
> > > have too many tools available.
> >
> > Good advice. The OP needs to be particularly careful to debug a version
> > that actually fails, not a similar program that works.
> >
> > Patricia
>
> It was a real dumb problem. The variable in the loop was incremented
> elsewhere making the loop to end prematurely. My bad...

This is why it is a good idea to post the actual code that reproduces
the problem.

From: Patricia Shanahan on 19 May 2010 19:51
Dann Corbit wrote:
> In article <c90e4442-455f-4ca9-b9fb-e20c04c09b40
> @z15g2000prh.googlegroups.com>, ameliajane42(a)gmail.com says...
>> On May 19, 1:01 pm, Patricia Shanahan <p...(a)acm.org> wrote:
>>> stan wrote:
>>>
>>> ...
>>>
>>>> I agree with the others as to possible causes, but I might add
>>>> that this may be a perfect time to learn to step through code in a
>>>> debugger. You might discover the problem with your code and you will
>>>> certainly learn a skill which can be very handy. It won't be time
>>>> wasted. Debuggers are not a silver bullet, they can't solve every
>>>> problem all the time. But when you fine yourself stumped you can never
>>>> have too many tools available.
>>> Good advice. The OP needs to be particularly careful to debug a version
>>> that actually fails, not a similar program that works.
>>>
>>> Patricia
>> It was a real dumb problem. The variable in the loop was incremented
>> elsewhere making the loop to end prematurely. My bad...
>
> This is why it is a good idea to post the actual code that reproduces
> the problem.
>

Often the original code is too big and complicated to post. Producing a
simplified example is very useful. However, it is essential to check
that the simplified code reproduces the original problem. If not, the
implication is that the problem involves something that was removed
during simplification, an important debug clue.

Patricia
From: bart.c on 19 May 2010 20:56

"Patricia Shanahan" <pats(a)acm.org> wrote in message
news:vqydnRl2_84J5GnWnZ2dnUVZ_rOdnZ2d(a)earthlink.com...
> Dann Corbit wrote:
>> In article <c90e4442-455f-4ca9-b9fb-e20c04c09b40
>> @z15g2000prh.googlegroups.com>, ameliajane42(a)gmail.com says...

>>> It was a real dumb problem. The variable in the loop was incremented
>>> elsewhere making the loop to end prematurely. My bad...
>>
>> This is why it is a good idea to post the actual code that reproduces the
>> problem.
>>
>
> Often the original code is too big and complicated to post. Producing a
> simplified example is very useful. However, it is essential to check
> that the simplified code reproduces the original problem. If not, the
> implication is that the problem involves something that was removed
> during simplification, an important debug clue.

The OP suggested that moving that loop upper limit to outside the loop fixed
the problem.

This should have made no difference if the problem was in fact the loop
variable 'i' being modified elsewhere (presumably elsewhere in the loop
body, unless 'i' was some global.)

So the reporting was misleading too.

--
Bartc

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: IDE for C with good context sensitive help
Next: KOBWEB JAVA