PB9 Bugs?

[William Martin]

Where should one report PB9 bugs? Or for that matter, where does one go to see a list of known bugs so one can tell whether to bother reporting or not?

Thanks.

Bill

[Richard Angell]

Before suggesting you have found a bug, which might be misleading to others here as PB usually notes, there are several usual steps folks take:

1. Look in the Power Base forum for announcements
2. Search the forum for topics that may deal with your problem
3. Post a discussion thread with your failing code and error codes
4. If still unresolved, send an e-mail with your failing file(s) to [email protected]

"Bugs" can be a point-of-view situation, which may just require clarification. The steps above, which PB might amplify or change, are those that I have seen usually result in a more thorough examination and help. In some cases a "bug" is more perception from the POV of the poster or a few PB'ers, than that of others.

[Michael Mattias]

>"Bugs" can be a point-of-view situation

???

BUG = Product does not behave as documented. Period.

Eg, PB/CC 5, STDERR function fails (produces NO output) if STDERR redirected to disk file. (leftover bug from PB CC 4x)
eg PB/Win 9, THREAD CREATE will not accept SUSPEND argument
eg PB/Win 9, correct DIR$ syntax not as documented. (attribute is optional even if TO DIRDATAVAR is used).


These are real, reported bugs BTW. (I did, that's who reported them). PowerBase Forum is a little behind.


MCM

[Chris Holbrook]

...where does one go to see a list of known bugs so one can tell whether to bother reporting or not?

I don't think that there is an official public bug list, although as you say it would simplify reporting. In fact, as PowerBasic Inc does not publish a list, then they must have designed or evolved an efficient internal mechanism for dealing with duplicated reports - so if in doubt, report!

[Michael Mattias]

I have been under the impression that is what the PowerBase Forum is supposed to be:

"Programmer's database keeps you apprised of issues in current PowerBASIC products"

PB has used "issue" in lieu of "the b-word" for years.

[Chris Holbrook]

I have been under the impression that is what the PowerBase Forum is supposed to be....

Just goes to show how issue-free the compilers are!

I think that Rick Angell pointed to it above (POV) - in other words, whether it is a bug or not CAN BE a matter of interpretation. For example, taking your strict view of what a bug is, all bugs could be fixed by changing the documentation. Well, from my POV that would not be best practice!

Personally I feel that it is the quality of the underlying product and service which counts, not whether bugs are issues. However, there must be a limit to the amount of legwork one is expected to do before reporting a - er, an, issue. If something is clearly wrong, then it's wrong, and no amount of colleague referral will put it right. If it's an "own goal" on the part of the developer, so be it, PowerBasic Inc won't be shy about letting one know.

If Mr Zale can operate with the current arrangements, informal by some standards, and there is not a scandalous pile of unsolved issues, then I assume that we all benefit in reduced costs compared with a more formal, better documented system.

[Richard Angell]

My stating that "Bugs" can be a point-of-view (POV) situation, does not by any stretch imply that all "issues" are POV situations. It does imply that sometimes folks perceive a situation where they may have a mis-understanding or incorrectly coded procedure ... they think it is a code eating insect.

Likewise, equating documentation oversights to bugs is a rather Draconian view, not necessarily viewed the same way by all. Otherwise every typo or omission might be classed as severe mis-information. Such can be addressed in the forum, whereas a quite obviously may have to wait for a compiler revision for resolution of the situation.

[Gösta H. Lovgren-2]

Where should one report PB9 bugs? Or for that matter, where does one go to see a list of known bugs so one can tell whether to bother reporting or not?

Thanks.

Bill

Bill,

In my experience, the BEST mechanism to report PB bugs is to post example (compileable is best) code in the Programming Forum demonstrating the failure or unexpected behavior.

9 times out 8 the "bug" will be resolved. (Not be a bug by any reasonable interpretation). At the least someone will have a work around. And really, if you have uncovered a bug, it's only fair to let the rest of us know (at least until PB gets around to actually posting an "issue" list.)

============================================
"It's not the size of the dog in the fight,
it's the size of the fight in the dog."
Mark Twain (1835-1910)
============================================

[Michael Mattias]

> all bugs could be fixed by changing the documentation

Sure. Of course they could. But when you use my definition, you know there is an error SOMEWHERE... either the compiler is not behaving as designed, or the documentation is in error. ( Or both but I'd usually bet against that).

The problem is, you just don't know until the publisher tells you which is wrong!

MCM

[William Martin]

I just wanted to pass along that I have reported my "bug" to PB via e-mail and got a prompt response. It's still a bug as far as I know, but after several iterations with them they're apparently analyzing it.

Still, personally, it seems to me, IMHO, it would be nice to have somewhere one could check on known bugs - and I'm willing to have "known" defined by the PB staff any way they want.

FWIW...

Bill

[Michael Mattias]

>IMHO, it would be nice to have somewhere one could check on known bugs

That is AFAIK the reason the PowerBase Forum exists.

>and I'm willing to have "known" defined by the PB staff any way they want.

That's the ONLY way this could work. We see lots of " bugs" posted here, but I'll bet nine out of ten are not really bugs, they are programmer error. I'd like to see only "known, confirmed by someone who should know" things appear on any list.

Hopefully each such "official" notificiation would include a suggested temporary "workaround" and not just be limited to "will be addressed in a future release."

eg. Until STDERR redirection problem is fixed, you can use this:

FUNCTION STDERR2 (s AS STRING) AS LONG
 LOCAL hStdErr AS LONG, hFile AS LONG

  hStdErr =  GetStdHandle (%STD_ERROR_HANDLE)
  hFile = FREEFILE
  OPEN HANDLE hStdErr FOR OUTPUT AS hFile
  PRINT #hFile, S
  CLOSE hFile

END FUNCTION

MCM

[Barry Erick]

As in:

  GET$ f,8,st$
  Get f,myWord  <<<< bad record number if you mix GET$ and GET

If you mix the two, you must use record number

  GET f,SEEK(f),myWord

I can't find this clarification in the doc's, so even with a easy workaround, it is a bug.

[Michael Mattias]

> Get f,myWord <<<< bad record number if you mix GET$ and GET

Sorry, Barry, I think that is Error 1: Programmer error.

That particular syntax (2 params) is only valid with the file opened FOR RANDOM, but you used it on a file opened FOR BINARY.
You needed

GET f,,myword

While the compiler cannot know at COMPILE time the mode in which "f" is opened, you CAN at runtime... with FILEATTR.

Sure it's a crummy syntax design (not that I can think of anything better), but given the syntax, I think this is your problem.

FWIW, you CAN ask for record number zero... if you open the file FOR RANDOM BASE=0.