>George,
>
>Now that you've had the opportunity to bask in the glory for a few days I'd like to make a few comments about this epistle. They are interspersed between your paragraphs/sentences.

What glory? It wasn't written for self-aggrandizement. It was written for two purposes. First, to state a personal position. Second, to try to bring some sense of realization about "bugs".

>>Dear All,
>>
>>During my period of time here on the UT, and with the VFP community in general, I’ve attempted to live up to a simple credo, or set of rules. These are:
>>
>>1. I tell people when I know the answer.
>>2. I tell them when I’m guessing,
>>3. When proven wrong, I'll admit my mistake and apologize.
>
>While it obviously wouldn't be a part of your "credo", let me add one:
>4. To get antagonistic/personal/nasty with a specific few individuals.

Only when provoked. For example, I didn't get " antagonistic/personal/nasty" with you until you brought my character into question in a public forum. BTW, someone else said that about your post.

I did also when you took what I said out of context, then later blatantly mis-quoted me and wholly mis-characterized what I had said.

If someone does that to me, then I fight back. You did it, and you fail to take responsibility for your remarks. You can't be the victim when you're the instigator.

OTOH, I don't believe that I have ever attacked someone without, what I believed at the time, just provocation. Unfortunately, you can't say the same. (Word to wise: Don't go here, for I'll be happy to demonstrate via your own posts.)

>>I think that, over the last five years here, I’ve done a reasonable job of living up to that credo. Have I not at times? Perhaps so, but I am human, with my own set of foibles. I’m reminded here of a quote
>>
>>“Every man is as heaven made him, and sometimes a good deal worse.” – Cervantes
>>
>>I believe that, in general, I have lived up to the credo expressed above. Others may take issue with this.
>
>In the general case you have lived up to it nicely, but in a few individuals' cases you simply forget the whole "credo" every time you choose to reply to them. To those people your "credo" doesn't exist.

Beyond my recent posts to you, who are these individuals? And to which posts do you refer?

>>
>>The thing I believe about programming is that it is a combination of art and science. Art in the fact that by definition it’s the conscience use of skill or knowledge in the creation of something. Science, by the fact that it utilizes the theoretical in proper design, and demands that we prove any algorithm we create.
>>
>>The latter is an important point, Basically, what it says is that we are scientists. As such, we should be required to adhere to the scientific method. I like to sum this up in a series of steps.
>>
>>1. Realization – This is the point where we realize what the problem is that we have to solve, or realize that something doesn’t work as we thought it would. Here, we form the hypothesis as to why this occurred.
>>2. Confirmation – We determine, either through someone else or another application, whether or not the problem has been solve, or, in the case of a bug, still exits.
>>3. Explanation – We document why something works, or form a hypothesis as to why it doesn’t. In the latter case, this takes us back to step one.
>
>These are fine except that only the MS VFP Team is in a position to "explain" those things that remain in the apparent state of not working as expected so when the "explanation" step has such a conclusion then "back to step one" is not really an option with "bugs".

And you cannot categorize something as a bug when a reasonable and plausible explanation exists has to why something's behavior changed. Simply calling something a "bug" under these circumstances is, IMV, wholly inappropriate. Calling it a bug, without acknowledging that it may be by design, makes it appear as if it were fact, when, in reality, this is not the case at all.

>>
>>I believe that the three most important words in science are, “I don’t know” since they are the starting point to acquiring new knowledge. A good scientist, however, must have an open mind and when multiple plausible and reasonable explanations exist will not take one over the other by calling one factual.
>>
>>Recently, there has been much discussion on the subject of bugs. First, of course, we must define what a “bug” really is. Therefore, for purposes of definition, I will define it this was: A command or function that doesn’t work as anticipated. Now there are two plausible and reasonable explanations for a “bug”. It is unintentional or it is intentional and by design.
>>
>>Regardless of the circumstances, every time such is encountered, as good scientists, we should have an open mind to the issue in order to properly determine whether or not it is, indeed, a bug. If a plausible and reasonable explanation exists, however, the best we can say is, “I don’t know”.
>>
>>Let’s take a recent example. The behavior of VFP in regards to division by zero changed between versions 6.0 and 7.0. Some feel that this is a bug; others believe that it isn’t and may be by design. The situation arises because of checking for numeric overflow. For example, consider the following snippet:

CREATE CURSOR Foo (Foo N(2))
>>APPEND BLANK
>>REPLACE Foo.Foo WITH 100 && Numeric overflow occurs.
>>APPEND BLANK
>>REPLACE Foo.Foo WITH 1 / 0 && Numeric overflow occurs.

s A common check for numeric overflow is to compare the field value against division by zero. However, as the above shows, division by zero isn’t the only cause of numeric overflow.
>>
>>Is there a reasonable and plausible explanation for this change in behavior? Certainly, but before getting to that consider that VFP is one of the few languages that doesn’t consider it to be an error. I began working with Fox in FoxBASE+ 2.10. When I initially started, I was surprised that division by zero didn’t throw an error. Based on my recollection, I don’t recall ever seeing an explanation of this. I may be wrong about this but that’s my recollection.
>>
>>Now in checking for numeric overflow, it is a common practice to use an expression like: Alias.Fieldname = 1 / 0. However, strictly, this isn’t always true. For example, in the above snippet, the value in the first record clearly isn’t equal to the value in the second. While it may have been that in versions of FoxPro prior to 7.0 this would return true regardless of the cause of the overflow, 7.0 considers division by zero clearly differently than its predecessors.
>>
>>Mathematically speaking, division by zero results in an unknown. In many ways, but not all it is very similar to a null. With a null the expression: .NULL. = .NULL. returns false because it cannot be evaluated. Similarly, 1 / 0 = 1 / 0 returns false in 7.0 (but true in previous versions). It makes sense that the preceding statement returns false for the exact same reason that comparing a null to itself returns false. The statement can’t be evaluated and therefore cannot be equal to anything.
>>
>>Further, it should be considered that the printer drivers from both HP and Lexmark, contrary to DDK specifications, leave the state of the FPU in a way that they expect that the calling software handle exceptions. This led to problems with 6.0 prior to SP3 because of fault tolerance. While many of these errors have been resolved. There are still some cases where using the reports to either print to a preview mode or to the printer, cause errors.
>>
>>Is it plausible and reasonable to think that this change in behavior was implemented to circumvent these problems? I believe so. Yet certain people believe it to be a bug simply because it hasn’t been documented. While I respect their right to their opinions, I must say that such opinions run contrary to the “open mindedness” that science requires. Is this a bug? The answer is simple: I don’t know.
>
>Well I don't know, George (not trying to be funny). If this has come up in a thread, and you did participate in that thread, was your first and final answer "I don't know"?

I happen to be, I believe, the first one who, on this forum brought the issue up. The question of whether or not it's a bug wasn't posed to me. I reported the behavior change, along with an explanation of why I thought it was made (much of which was repeated here). If I had been asked, I would said that it could be, or could be by design. FWIW, SET COMPATIBLE has no impact on the results regardless of the setting. You could make a point that it indicates either case.

>Let me assume that you did and it was OR that you yourself discovered this anomaly between the versions of VFP, rationalized it exactly as stated above and decided to be satisfied with that "explanation".
>Even if that is the case, why cannot another "scientist" come to the conclusion that such an "explanation", self-proposed or otherwise proffered, is not the end of the trail? What if that other "scientist" felt some additional internal pressures like
>1) informing "the community" about it in case it might affect some of their production applications;
>2) reporting it to MS as a "bug" despite the rationalization, on the bases that:
>------ a) It may well not have been by design despite a quality rationale to the contrary;
>------ b) It is in MS and the VFP team's interest to amend any documentation that may be relevant to report the fact to VFP users.
>Surely such a person does not lose their standing of "scientist" for acting differently than you would, do they?

Of course, they don't. However, when the scientist presents one side of the story as fact and doesn't acknowledge that the other side even when confronted with evidence that he/she may incorrect is another story.

Does this mean we shouldn't report it? No. Does this mean we shouldn't advise the community. No, but we do need, I believe, when reporting such that it may in fact not be a bug. I've dealt directly with Randy Brown on a couple of bugs. However, because when I report it, I didn't know for a fact that it was, indeed, a bug, I refered to it as an "issue".
>>
>> What is of specific concern here is the fact that, as an MVP, I have a “hidden agenda”. That because I’ve been honored by Microsoft that I’m “in their pocket”, their “shill”, and as David Frankenbach put it, a “sycophant”. Fundamentally, this is an insult. It is an insult, because in trying to be helpful and point out that there may be a reason behind a problem other than simply a bug, we don’t concur with people who are predisposed to think otherwise. I won’t speak for David, but I’m sure that his experience is the same as mine. I have never once been told by Microsoft not to speak negatively about them.
>
>Ahh, let me ASS-U-ME that this aspect of your epistle is directly related to a comment I made in a reply in Re: VFP 7 bug on SET RESOURCE command Thread #657030 Message #658174 that "Some people here have hidden agendas.". If that is NOT the case then feel free to skip this entire paragraph. Yes, you are one who I believe has a "hidden agenda" but you are way way off base in your assumption of what I believe that agenda to be. So that there is no longer any doubt let me state it for you: to ridicule Jim Nelson at every opportunity! There is ample evidence to support this.

I won't deny for a second that your use of that phrase came to mind when I was composing this. However, I was searching for words or phrases for the purpose of self-expression. Not to insult. I could take this whole post, if my "hidden agenda" was as you say, to demonstrate it. I haven't.

>Now, to set the record straight on my view of MVPs and "in MS pocket". I admire and respect MVPs, but do get to a point with one or two where their propensity to ridicule my writings or to insult me (usually in other threads and not to my face, as you have done within this very thread) causes some significant loss of the degree of respect. Nevertheless, I do believe that MVPs ARE affected by their status in what they write here. Not, however, to sycophancy at all (save Craig B. who wears his MS "pocket" proudly) but rather to far less criticism of MS and significant more defense of MS. I hope this clears this little business up.

It was not my intention to insult anyone with my post. You seem to have taken it personally. I took pains to try to de-personalize as much as possible. That was the reason I mentioned the division by zero problem.

How an individual MVP comports himself, is his business. Personally, if I were Craig, I'd be insulted by your remarks. I'm not Craig. At any rate, who are you to judge the amount of criticism an one or more MVPs give? Did it ever occur that what you see is the result of a deeper understanding than you may have? For example, I got blasted (not by you) on the issue of defending MS on the printer driver problem with HP printers. What I said at the time, and partially repeated here, was that there were three culprits. In order they were: 1. HP, 2. The developer, 3. VFP for not being more fault tolerant at the time. What I understood, that the person who levelled the blast didn't, was the nature and relationship of printing.

>>
>>I have said that I view shouting “bug” in the absence of conclusive evidence to the fact is like shouting “fire” in a crowded theatre. You have a right to do so, but any responsible person doesn’t. I think that, at this time, this is important.
>
>This is where, as far as I see it, you have dug yourself a nice big hole.
>You have accused me (and Andrus Moor too, most recently) of "shouting “bug” in the absence of conclusive evidence. In later responses in this very thread there is the notion that some people (IE me, Jim Nelson) get their jollies out of increasing the "bug count".

My post to Andrus was based on a mis-understanding. As I said before, I apologized to him. Further, I also tried to help him resolve the problem. I don't recall any involvement on your part to give him assistance.

>Firstly, in the reasonably recent past (6 months) I personally have "declared" here two (2) bugs.

>One had to do with an error in the documentation and that was acknowledged as a bug by MS in message #646698. Your "hidden agenda", of course, had you first dicrediting the report and then arguing that it didn't really qualify as a "bug" even though the MS Bug Reporting facility itself includes DOCERRs as "bug reports". I suppose that as a "scientist" I should have taken your wisdom on the matter.

My problem with this particular message is the title: "Bug - VFP 7..." Had you titled it "Doc Errata - VFP 7...". I wouldn't have made the comment. Traditionally and historically, documentation errata isn't a bug. MS uses its bug reporting facility to get information regarding both its software and documentation. Specifically, bugs refer to hardware or software, not documentation.

I don't believe that simply referring every deficiency as a bug simply because it's reported through the MS bug facility is appropriate, especially now. The MS KB itself doesn't do this. You have PRBs, BUGs, FIXs, HOWTO, etc.

Now for the record, here's my response in MESSAGE#646340:

"Nope, as I said to Sergey, I clicked the wrong link. Sorry (again). I also mentioned that IMV, it's Doc Errata that needs correction rather than a bug.

BTW, Yesterday, I added a suggestion for a UT improvement (see Task Tracker), that I think might be of interest to you."

So there's my hidden agenda. I made a mistake and admitted it, not once, but twice.

>The other bug that I reported was the now famous "REINDEX no longer removes bloat" (thread #652071) and you persist to this moment to claim that it is not a bug. Your hidden agenda really shines in this one, to the point that you couldn't resist raising it in the thread #657073 when all that I did was to ask you to please stop castigating people for "shouting bug" when you believe there clearly isn't one. Once again you were so quick that you didn't even try out Mr. Moor's download file as instructed before pronouncing such (which, of course, is brilliant "scientific method").

He also posted code, remember, that I understood would duplicate the problem. It didn't, thus the mis-understanding. Further, as I initially, told (and pointed out before), I did what I said I would do if proven wrong. BTW, I may have also helped him find a workaround to the problem.

>Now let me review the logic yet again for you in this second bug report that has you so upset. I have done a tiny bit more research just an hour ago, visiting the Compuserve forum for the first time ever.
>In my message #652071 I showed that there was a siginficant difference between the results of a REINDEX command run under VFP7SP1 versus the same command run on an identical file under VFP6SP5. This fulfilled points 1 and 2 of your scientific method outlined at the top. Now DavidF read that message and, focusing on the incorrect part of the message, declared that it was NOT a bug. Indeed, for the part that he focussed on, I agreed with him. Now in that same reply, however, DavidF also stated: "Please note I'm not disputing the valid part of the bug report about the near doubling of index size. I can tell you that MS is aware of this !!!!! worthy problem.. In addition I found a message on the Compuserve forum, #170613 dated 18-Feb-2002 at 4:03pm by Barbara P that 'MS now seems to be accepting this as a bug' as regards the near-doubled .CDX size observed with VFP7SP1.
>You will remember that ChristofL had only mentioned the problem regarding CDX files doubling in size on about May 1 in response to a message asking why some people are not upgrading to VFP7 and that this small mention was the first ever 'notice' of such a bug here on UT. SInce that mention said nothing about REINDEX I thought that I would go ahead and see if the "problem" could be addressed by using REINDEX, rationalizing that the extra size could well be "bloat" that I knew REINDEX nicely gets rid of). I had my old test .prgs around from a message proclaiming that REINDEX did, indeed remove bloat that I wrote well over a year ago. To my great surprise I found that the bloat REMAINED and that the file size was not at all diminished by a REINDEX in VFP7SP1. This, clearly, was a different problem than what ChristofL had mentioned, so I reported it as a bug.

As soon as MS verifies that it's a bug, I won't have a problem with your original post. However, a plausible and reasonable explanation as to why it may be by design exists. I would say, that, on your part, proclaiming this is a bug is premature. This is not fact yet.

>At this point I do not know what the status is of the problem of 'double-sized CDX files under VFP7SP1 because no one from MS has cared to respond to the thread. All I have to go on are DavidF's statement and Barbara P's message on Compuserve, both of which say that doubling of the CDX files under VFP7SP1 is an acknowledged bug. It is certainly likely that the two problems are related, but they nevertheless remain as two separate and distinct problems at this point and nothing that you or DavidF or Christof say about it has an impact on the final answer, which can only come from MS.

It takes time for these sort of things to go through the process established at MS. I, for one, would rather they devote their time resolving issue or documenting them rather than giving me feedback to the status.

>So there you have a bug count of two (2). Am I the champion? I sure must be based on the venom in your messages involving me. My slug morality notwithstanding, I continue to believe that I am correct in reporting the REINDEX problem as a bug.

I didn't raise the issue of "bug count". I don't have a problem with your reporting an issue, I just think that, at this time characterizing it factually as a bug, when a reasonable and plausible explanation exists, is potentitally harmful to the future of VFP and, therefore, irresponsible. You say you want to improve the product, great! I'm simply urging you that you not characterize something as fact when it isn't.

>>
>>Toledo is well on its way. People, in the past have complained about the marketing of VFP. The degree that Toledo is marketed depends on people upgrading to 7.0. The more upgrades, the more money that will be available for marketing. However, by shouting “bug” at every inconsistency, by refusing to admit that there may be another reasonable and plausible explanation for why something isn’t a bug, undermines the future. Someone who doesn’t know that 7.0 is the most stable version to date, may not upgrade because of this. To sum it up, we’re shooting ourselves in the foot with such.
>
>Maybe this rationale is why it has taken so long for the report about near-doubled CDX files from reaching the UT. If that is in any way, shape or form tha actual case, then it is a far surer way of one's shooting oneself in the foot than coming clean about the whole issue. Or any other issue that affect the product's useability. I point out here that it was a JimS who 'reported' this double-sized CDX files on Comupserve and stated outright that he most likely would NOT upgrade his client's system as planned strictly because of this. Just wanting to confirm that it does have real-world consequences. Now what boat would he have been in if he hadn't noticed and had gone ahead and done the conversion??? He mentioned that his client as very large tables with lots of indices and that it was just not on.
>
Certainly, you have to take in account the client's needs and the potential problems that may result. The client, in this case, may be the exception (in terms of size and number of indexes) rather than the rule. I firmly believe that having this knowledge is a good thing. However, as I explained before, how we make the community aware of a change is important as well.
>>
>>If you’ve gotten to this point, my thanks for your attention and my apologies for being so long winded.
>
>Yes, I got to here the first time too.
>
>regards
>slug-go