On Fri, 05 Mar 2004 13:43:05 -0800, Walter wrote:

> 
> That looks like a bug :-(

Any plans for a release dmd_0.80a ?
I can't use 0.80 :(

Ant

J Anderson wrote:

[...]
> pick up two hidden bugs
[...]

Isn't the `hidden' redundant?

So long.

On Sat, 06 Mar 2004 14:28:08 +0000, Manfred Nowak wrote:

> J Anderson wrote:
> 
> [...]
>> pick up two hidden bugs
> [...]
> 
> Isn't the `hidden' redundant?
> 
> So long.

:)

not on the real world,
sometimes you know you need to fix
something...
sometimes you know exactly what to do...

Ant

Ant wrote:

>On Sat, 06 Mar 2004 14:28:08 +0000, Manfred Nowak wrote:
>
>  
>
>>J Anderson wrote:
>>
>>[...]
>>    
>>
>>>pick up two hidden bugs
>>>      
>>>
>>[...]
>>
>>Isn't the `hidden' redundant?
>>
>>So long.
>>    
>>
>
>:)
>
>not on the real world,
>sometimes you know you need to fix something...
>sometimes you know exactly what to do...
>
>Ant
>  
>
Exactly.  Also sometimes I have bugs that I know exactly where they are but need to ponder the best solution so they stay in the program for a while.


-- 
-Anderson: http://badmama.com.au/~anderson/

Welcome to .toString and you make my String class has good exhale ! Will
test it !
"Walter" <walter@digitalmars.com> wrote in message
news:c2ap6r$2s75$1@digitaldaemon.com...
> Didn't get all the bugs I wanted fixed done, but there's enough to justify
a
> bug fix update.
>
> http://www.digitalmars.com/d/changelog.html
>
>
>

J Anderson wrote:

[...]
> Also sometimes I have bugs that I know exactly where they are
[...]

I see. It is a matter of wording. I would prefer to call faulty/wrong code as such. For me only unlocalized faulty code is a bug.

IMO a system that has no known bugs according to its specification does not get buggy, when the specification changes and that system is considered the base of the implementation of the changed specification.

So long.

Manfred Nowak wrote:

>IMO a system that has no known bugs according to its specification does
>not get buggy, when the specification changes and that system is
>considered the base of the implementation of the changed specification.
>
>  
>
What about something like Y2K (ie number overflows, floating point errors).  Do you require every detail in the program to be in the specifications?  That would be impossible.

>So long.
>  
>

-- 
-Anderson: http://badmama.com.au/~anderson/

J Anderson wrote:

> What about something like Y2K (ie number overflows, floating point
> errors).

I do not quite catch what you mean with your examples. We had a system that was not Y2K compliant, because it was not a requirement in its specification. When Y2K approached the management decided to not make it the base of the implementation of a Y2K compliant system, but instead switch to a newly built system incorporating and using the meanwhile evolved techniques, by even establishing its own language and compilers.

> Do you require every detail in the program to be in the specifications?

Yes ...

> That would be impossible.

and disagreed. Vice versa: I know of projects that failed to fulfill the final check and taking over by the client because our knowledge engineers where not able to catch that the client wanted to do something illegal with the generated system and therefore had not expressed clearly what he wanted, but nevertheless had expressed his requirement in the task. So the system had no known bugs according to its specification, but the specification was itself faulty according to the task.

So long.

Manfred Nowak wrote:

>J Anderson wrote:
>
>  
>
>>What about something like Y2K (ie number overflows, floating point
>>errors).
>>    
>>
>
>I do not quite catch what you mean with your examples. We had a system
>that was not Y2K compliant, because it was not a requirement in its
>specification. When Y2K approached the management decided to not make it
>the base of the implementation of a Y2K compliant system, but instead
>switch to a newly built system incorporating and using the meanwhile
>evolved techniques, by even establishing its own language and compilers.
>  
>

Floating point errors:
Each time you perform an operation with floating point, details are lost in the calculations.  Now what if your specification said that the program was to run for 1000 years on a super computer but floating point wasn't in the specs.  Now you can't physically run the program for a 1000 years so the program would most likely crash due to this bug.

>>Do you require every detail in the program to be in the specifications? 
>>    
>>
>
>Yes ...
>  
>
>>That would be impossible.
>>    
>>
I should have said impossible with all but the simplest of applications. Unless you say the code is the specification, then of course (if that is the case) the specification could never be wrong.

>and disagreed. Vice versa: I know of projects that failed to fulfill the
>final check and taking over by the client because our knowledge engineers
>where not able to catch that the client wanted to do something illegal
>with the generated system and therefore had not expressed clearly what he
>wanted, but nevertheless had expressed his requirement in the task. So the
>system had no known bugs according to its specification, but the
>specification was itself faulty according to the task.
>
>So long. 
>  
>
Looking at any program I use today and they all have bug management systems.  Bugs keep appearing even though the specification is good.  Bug management is a cycle, programmers fix the bugs and the users find new ones.  Everytime they fix a bug they don't go and add that to the specification (imaging the specifications for windows it would be longer then the code itself and no-one would be able to read it).  ie

Fixed bug when : If player A has menu X up when player B clicks up player B doesn't have to pay for the selected item.

This is the kinda error that escapes the testing saftynet and is something you don't add to the specifications because it occurs so infrequently.  Users may pick it up eventually.  The trouble is you can't predict what data the user the is going to give the system. You can't predict everything the user is going to do.  There are so many pathways a program can go and each fork is exponential.

Specifications are an abstraction, the details are where the bugs occur.

-- 
-Anderson: http://badmama.com.au/~anderson/

J Anderson wrote:

> Floating point errors:
> Each time you perform an operation with floating point, details are lost
> in the calculations.  Now what if your specification said that the
> program was to run for 1000 years on a super computer but floating point
> wasn't in the specs.  Now you can't physically run the program for a
> 1000 years so the program would most likely crash due to this bug.

Still not catching what you mean. If the specification does not mention floating point operations, then every use of them is related to faulty code. If the required runtime exceeds the MTBF of the underlying hardware by a certain threshold the specification itself is faulty.

> I should have said impossible with all but the simplest of applications. Unless you say the code is the specification, then of course (if that is the case) the specification could never be wrong.

Nope. If you have this opinion, then you should never take over a task which output might harm human life.

> Looking at any program I use today ...

I see. And I do not believe that you use programs for the control of transportation systems(railways, aeroplanes, rockets), atomic reactors, medic equipment (X-rays, artificial respiration), weapon systems, banking systems, store keeping, production robots, ... etc.

So long.