At 09:50 AM 3/1/2002 +0000, Steve Wiseman wrote:

>On Thu, 28 Feb 2002, Abd ul-Rahman Lomax wrote:
> > I tested what I wrote before mailing it. I can only think of these
> > possibilities: (1) Mr. Wiseman does not understand what was written and is
> > therefore referring to some other command sequence, (2) his memory is
> > simply faulty and he has not verified what he is claiming, (3) there is a
> > bug which is not understood, or (4) his installation of Protel is damaged.
>None of the above - both of your test segments were attached to the same
>net - I suggested that copper which had been on the same net _did_ respond
>properly to global ops, but copper on previoulsy different nets didn't.

The history of this was that Mr. Wiseman reported a possible bug. I 
attempted to verify his bug, and was unable, at first pass, to do so. I 
reported what I had done, and he responded that, no, that did not work.

I had satisfied the literal description he had given of the bug, and the 
behavior I found did not match his description.

Now, in hindsight, we know what was happening. (1) was partially true 
because he was indeed referring to "some other command sequence," Update 
being included, and more than one original net being involved. (2) is 
possibly true because Mr. Wiseman has not reported verifying the problem as 
generic, but his memory was not faulty, his report was simply not complete.

And (3) was true: there is a bug which was not understood, which is really 
the same primitive net memory bug as previously reported. It is a net 
memory that does not persist through a file save.

There is a principle in common law, which is to presume that testimony is 
true unless it is controverted. One should be very careful about assuming 
that two different reports contradict, often the appearance of 
contradiction is a sign that one or both reports are incomplete; a complete 
report would show the underlying unity.

>Hmm - the description seems to have been as accurate as possible without
>attaching the project. I do try hard to report possible bugs accurately -
>it's an important issue, and since Protel normally does work, the bugs
>tend to be in the less-used sections of the program. I don't think I've
>called a bug falsely yet...

The description was not adequate to reproduce the bug, by itself. The 
original description did not mention that the nets became no-net from 
running Update, though that might have been inferred as the most likely way 
in which such a No Net assigment might have taken place.

The first post from Mr. Wiseman simply asked if global operations worked on 
No-Net primitives. The answer came back, "Yes." Mr. Wiseman then asserted, 
again, that it did not work. This time he gave a little more information, 
enough that *in hindsight*, if we remembered the net name persistence bug, 
was enough to identify the problem. He mentioned, "at best, I get all the 
features that
were on the same net, or maybe that are touching... Other "no net"
features aren't matched - I'm confused."

Actually, I verified that net persistence bug when it was first reported, 
but my own memory is not so persistent sometimes....

It was Mr. Velander who did remember the old bug and saw the connection. 
Others were reporting that they *could* globally select no-net track with 
what might have been thought to be the same conditions; but we can now be 
fairly sure that the boards involved had been saved and reloaded after 
Update, or they had gone through a net clearing with net list reload, which 
also eliminates the problem, if I recall correctly.

Mr. Wiseman did not "call a bug falsely." Rather, he reported buggy 
behavior to us without giving sufficient information to reproduce the bug. 
It was not necessary for him to attach the project, and, in fact, it would 
not have worked. I've reported bugs before, and have sent files which show 
the problem. But I *always* verify that the problem still exists in the 
file as I am sending. It's a necessary part of the process, for there is no 
use having someone else look at a file if, even on one's own system, it 
does not show the problem.

Instead, I would have had him try to reproduce the bug with a simple PCB, 
such as what I reported. Describing the file and the operations performed 
on it to cause the bug to appear would have been sufficient. If not, then 
we could look into sharing a file, but it would be a simple file, generally 
not an actual job file. Sharing job files can come into play when a 
cut-down file does not display the problem in spite of repeated attempts, 
but the full file continues to display the problem even through a file save 
and reload.

Now, not all of us have the time necessary to investigate bugs thoroughly. 
It was perfectly fine for Mr. Wiseman to make an incomplete report, it is, 
in fact, quite normal.

However, the process of making a complete report -- which includes 
information believed from experiment to be sufficient to reproduce the 
problem -- will quite often identify the problem or bug without further 
discussion. Sometimes one will simply realize that one has made a mistake, 
and nothing would be sent to the list except, perhaps, a report about the 
mistake if one thinks that others might be likely to make the same mistake....

Abdulrahman Lomax
Easthampton, Massachusetts USA

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* To post a message: mailto:[EMAIL PROTECTED]
* To leave this list visit:
* Contact the list manager:
* Forum Guidelines Rules:
* Browse or Search previous postings:
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Reply via email to