Announcement

Collapse
No announcement yet.

PB9 Bugs?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • PB9 Bugs?

    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

  • #2
    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.
    Rick Angell

    Comment


    • #3
      >"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
      Michael Mattias
      Tal Systems (retired)
      Port Washington WI USA
      [email protected]
      http://www.talsystems.com

      Comment


      • #4
        Originally posted by William Martin View Post
        ...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!

        Comment


        • #5
          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.
          Michael Mattias
          Tal Systems (retired)
          Port Washington WI USA
          [email protected]
          http://www.talsystems.com

          Comment


          • #6
            Originally posted by Michael Mattias View Post
            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.

            Comment


            • #7
              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.
              Rick Angell

              Comment


              • #8
                Originally posted by William Martin View Post
                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)
                ============================================
                It's a pretty day. I hope you enjoy it.

                Gösta

                JWAM: (Quit Smoking): http://www.SwedesDock.com/smoking
                LDN - A Miracle Drug: http://www.SwedesDock.com/LDN/

                Comment


                • #9
                  > 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
                  Michael Mattias
                  Tal Systems (retired)
                  Port Washington WI USA
                  [email protected]
                  http://www.talsystems.com

                  Comment


                  • #10
                    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

                    Comment


                    • #11
                      >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:
                      Code:
                      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
                      Michael Mattias
                      Tal Systems (retired)
                      Port Washington WI USA
                      [email protected]
                      http://www.talsystems.com

                      Comment


                      • #12
                        As in:
                        Code:
                          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
                        Code:
                          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.
                        Barry

                        Comment


                        • #13
                          > 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
                          Code:
                          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.
                          Last edited by Michael Mattias; 1 Nov 2008, 09:13 AM.
                          Michael Mattias
                          Tal Systems (retired)
                          Port Washington WI USA
                          [email protected]
                          http://www.talsystems.com

                          Comment

                          Working...
                          X