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.... [EMAIL PROTECTED] Abdulrahman Lomax Easthampton, Massachusetts USA * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * To post a message: mailto:[EMAIL PROTECTED] * * To leave this list visit: * http://www.techservinc.com/protelusers/leave.html * * Contact the list manager: * mailto:[EMAIL PROTECTED] * * Forum Guidelines Rules: * http://www.techservinc.com/protelusers/forumrules.html * * Browse or Search previous postings: * http://www.mail-archive.com/[email protected] * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
