Announcement

Collapse
No announcement yet.

un resolvable compiler errors

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

  • un resolvable compiler errors

    I am an exprienced programmer but new to PB/dos. I have a program
    written by someone else very poorly. I has 7K lines many statements
    per line for about 35K statements. It might be the worst I have ever
    seen. It was 18 includes but is now one large file cause PB search
    doesn't span files properly. Even though it is supposed to be a
    PB3.5 program there were hundreds of reserved word conflicts like
    labels called SORT. I have fixed them. I unintelligble errors on
    compile. Error 476 shows up at random adding a blank line thousands
    of line previous to the error might eliminate it. A DIM xxx(45) turned
    in to a DIM xxx(10) midway through the program. That is a reference to
    to xxx(33) was okay earlier but then a xxx(11) gives subscript error.
    A dim xxx(45) was put in just prior to the error which fixed it. But
    the error did not return when that dim was removed. WHAT IS THAT.

    I presume that PB does not do a complete syntax check and does not
    recover or report internal errors. Maybe if this program was
    written from scratch errors would be fixed one at a time. I have
    never seen a compiler affected by blank lines (in the right place)
    or demonstrate such bizzar behavior.

    I have contacted PB support they say there are to many errors
    what do I expect the compiler to handle. (I will tell my friends
    about that response for years - a compiler that can't handle
    and diagnose errors, what's next one that can't handle source?)

    What do you do when the compiler explodes. In my 35 years of
    programming in languages and assembly I've never seen
    anything like it.

    JY

  • #2
    Well, John, if your program has 200 errors, it's not possible to fix them all a one instant in time. First, you fix one, then you fix the next one, etc.

    So, find one error, define it clearly, and fix it. If you don't understand that error, you can ask support, or you can post a question here, and you'll likely get a good explanation. Then when it's fixed, go on to the next one. We'll be happy to help you in that way, and you'll get the job done. I think you'll find that approach to be more productive.

    Regards,

    Bob Zale
    PowerBASIC Inc.


    ------------------

    Comment


    • #3
      John --

      It seems impossible that that source code was written for PB/DOS. The PB/DOS compiler would never (for example) allow somebody to compile a program that contained a variable with a name that conflicted with a reserved word like SORT. I just tried it and the PB/DOS compiler displayed an error and put the cursor on the word SORT. So I'll assume that you are trying to port a program to PB/DOS. Or maybe the code is for a very, very old version of PB/DOS. Right? You have to ask yourself, if this program ever compiled in PB/DOS, why doesn't it compile now, without any changes at all? PB/DOS is a true compiler, so if a program contains an error it will fail at compile time. (Unlike QBasic, for example, where an error isn't detected until a line of code is actually executed.)

      > Error 476 shows up at random adding a blank line thousands
      > of line previous to the error might eliminate it.

      If a line of code conflicts with a previous line, most compilers will point to the later line and say "there is an error here". (Where would you expect the compiler to point if ten previous lines agreed and then an eleventh line conflicted?) This gets a little complex because PB/DOS is a 2-pass compiler, so "previous" isn't always obvious.

      If the compiler is pointing at blank lines, check your source files for improperly terminated lines, such as a CR without an LF, or multiple LFs, etc. PB/DOS is (of course) a DOS compiler and it expects files that follow normal DOS conventions.

      Error 476 is "Block/scanned statements not allowed here". That means that it found a single-line IF statement with a block statement (LOOP, etc) or something like a SUB defined within a SUB. Again, these things point toward non-PB code.

      Believe me, I do sympathize! It sounds like you are extemely frustrated right now, and I've been there. But I can tell you that based on my personal, extensive use of PB/DOS it is a very robust, compentent compiler. I suspect that the cause or your woe is:

      > a program written by someone else very poorly.

      > It might be the worst I have ever seen.

      ...not the PB/DOS compiler.

      Of course I can't speak for PB support, but I don't think it's reasonable to expect a compiler to make perfect sense of a program that was apparently written for another flavor of BASIC, much less one that's written as badly as you say. It sounds to me like PB support was simply commenting on the immensity of the task ahead of you.

      It seems likely that somebody who is experienced with PB/DOS could help you, but if it's not a matter of posting concise segements of code on this BBS you'll probably need to hire somebody.

      [added] I just re-read my own post and it sounds like I'm fishing for a job. I'm not. But if you want to send the original source code files (not your edited version) to the email address below I'll give you 10 minutes' worth of eval time, to point you in the right direction.

      -- Eric


      ------------------
      Perfect Sync Development Tools
      Perfect Sync Web Site
      Contact Us: mailto:[email protected][email protected]</A>



      [This message has been edited by Eric Pearson (edited April 17, 2005).]
      "Not my circus, not my monkeys."

      Comment


      • #4
        > I has 7K lines many statements per line for about 35K statements.

        Somewhere around here I wrote a program once to convert all multiple-statement lines into multiple single-statement lines.. much easier to figure out what the hell is going on in a program that way.

        If one of the 'prettifier/formatter' programs available here doesn't already do this, let me know and I'll look for it.

        Note that the other code formatters here also handle indenting, converting single-line IF to block IF and other stuff like that, which mine (if I remember correctly) does not do.

        Whoa, I found it... turns out someone else wrote it, but I modified it a lot.

        It's a "little" old as you can tell from the comments:
        Code:
        ' Program Name: BB.BAS
        ' Last cleaned: 02-17-1991, 09:41:41
        ' Modified 4/12/91 to
        ' 1) change colors on screen during the process
        ' 2) Prompt for filename if /C entered on command line. Original version
        'failed on ".BAS NOT FOUND" if command parameter was included without a
        'file name being supplied
        ' 5/22/91. Got the front end done. Works Good. Fixed COLOR problem on lines
        ' > max line width. Program fails on INVALID PATH ( ERR 76 ) if invalid path
        ' OR null file name supplied.
        ' 12.31.97 copied into PB32 directory in prep to move to PB 3.2
        ' will add new reserved words, change base indent to 0
        ' also: changed extended line to " _" from "_" as PB 3.2 requires
        ' a space before the underscore; changed standard indent to 0 (was 3)
        ' 12.14.98 Moved into PB 3.5.
        ' changes needed:
        ' recognize REM same as single quote.       DONE.
        ' do not change keywords in REM statments.  DONE.
        ' do not split the line in the middle of a ">=" operator
        ' echo options when done on command line    DONE.
        ' Make Size of reserved word list soft.
        It's 826 lines of source; I have the exe, too, so could send you source and exectable if you send me an email address...

        {more}
        FWIW, this does convert all the IF.. into block IF.. END IF, (optionally) upper-cases all reserved words, and re-indents everythng. Works command-line or interactive.

        This program was (and still is) called "BB" (for Basic Beautify); and no, I cannot find the name of the original author.

        Hmmm.. 1991.. IIRC, that was a very good year... (except perhaps for the Iraqi army)

        mailto:[email protected][email protected]</A>




        [This message has been edited by Michael Mattias (edited April 17, 2005).]
        Michael Mattias
        Tal Systems Inc. (retired)
        Racine WI USA
        [email protected]
        http://www.talsystems.com

        Comment


        • #5
          Anyone else wants this, just drop me a note. PB/DOS 3.5 source(no $INCLUDES)+exe= 43Kb ZIP file.

          mailto:[email protected][email protected]</A>

          Michael Mattias
          Tal Systems Inc. (retired)
          Racine WI USA
          [email protected]
          http://www.talsystems.com

          Comment


          • #6
            Thanks for everyones response. Here is an update.

            Thanks to Michael Mattias for sending me the Basic Format
            Beautifier program. It was well written and quickly fixed
            the format of this program. Even though it should not have
            changed the logic or syntax of the program the unjustified
            476 errors disappeared. I don't know why they were there or
            why they disappeared. It did however reveal some other funny
            behaviour. Single line IF's were converted to multiline IF's
            most of which worked well. Some that had line numbers within
            the IF created an unjustifiable error. I just changed them
            to single line IF's with no other changes and all was well.
            I can't figure why a proper line number should be trouble.
            I didn't check to see if other occurances of this form
            were allowed else where in the program.

            It finally compiles to the end of the program but errors out with
            a missing WEND. Which is indeed missing. I added that and get
            a new unjustified error expecting END IF. I can't find a cause
            for that and when I add one it comes back with undefined label
            reference. There are of course no label references within a mile
            of this code. Unless it is the IF to match the END IF missing.
            But then it thinks the END IF is required and the error message
            would be misleading.

            I have never encountered a compiler with little or no correlation
            between error messages and actual error causes. I don't think 12K
            statements should overwhelm a modern compiler. I compiled many
            Fortran programs larger than that on mini-computers with 32K
            of memory in the early 70's.

            Now the question to you experienced users:

            Does the error undefined line label reference have any
            special conotation? Or should a take it literally. I'm certain
            I understand what lines and labels are. I can't find anything
            near where the error shows up. In fact there are no references
            anywhere nearby. I would think it would show where the
            undefined reference is.

            What do you do when the compiler gives an eronious
            error message. I am reluctant to start tinkering with 12K lines
            to try and stumble across the cause. That could take a long long
            time.


            Let me clarify some previous information:

            One feature of the format conversion was elimination of mutiple
            statement lines. I also discovered I had vastly over-estimated
            the number of statements, it's about 12K.

            I found about 3 or 4 errors in the code I received that resulted
            a hundred edits - just labels or variables that conflicted with
            reserved words. The code was written in 96 time frame so 3.5
            was probably not around then. I guess that might explain the
            errors. I added one error myself when I tried to use console
            compiler and needed the new data read format. I sent it to
            the support people with one question why doesn't the DIM
            statement work? I got the answer the compiler had too
            many errors to handle. Considering it stops at the first one
            and has no idea how many remain. I thought this was hysterical
            if not a novel way of saying GET LOST KID. He also told me to
            go to Peer support. Last Monday when all this started I called
            PB to use their $4/min support which I thought would get great
            quality answers for that price. I was told no one could help
            and email my question to support. If had employees earning me
            $240/hr I have one standing by. Maybe no one uses this
            expensive service.

            JY


            ------------------

            Comment


            • #7
              I would imagine that your DIM statement doesn't work because you're using it improperly. Nobody could offer a better response than that because you haven't chosen to share any information at all about it.

              When you show some code which appears to "fail", you may get a more helpful response.

              The response you received from our support engineer was perfectly correct. It is not the job of our support folks to debug your programs for you. When you show them code with many, many obvious mistakes in it, they can't just fix everything in your code for you for free. That's what they would have to do in order to isolate the problem with your DIM statement.

              If you wish to avail yourself of our paid support option, I'll be happy to arrange it for you. Our rep was simply trying to offer you an alternative which would save you some money. For paid support, please call 1-800-780-7707 and ask for Tim. He'll be happy to arrange it.

              Regards,

              Bob Zale
              PowerBASIC Inc.


              ------------------

              Comment


              • #8
                FWIW, I've seen the source code.

                Trust me, it would be a simply terrific 'torture test' for any compiler. Or any programmer who has 'won' the job of maintaining it.

                Michael Mattias
                Tal Systems Inc. (retired)
                Racine WI USA
                [email protected]
                http://www.talsystems.com

                Comment


                • #9
                  > Even though it should not have changed the
                  > logic or syntax of the program the unjustified
                  > 476 errors disappeared.

                  Um... The PB/DOS documentation says that Error 476 means:

                  Block/scanned statements (like WHILE/WEND, DO/LOOP and SELECT CASE) and are not allowed in single-line IF statements

                  ...and when you used Michael's program to convert all of your single-line IF statements to IF-blocks, the errors went away. My guess would be that some of those single-line IF statements contained block/scanned statements. If that's the case, I don't see how you get "unjustified 476 errors" out of that. If that's not the case, please post an actual example. By being so vague you're making it really hard for people to help you.

                  Again, this really points toward a program that wasn't really written in PowerBASIC after all. PB has never allowed block statements inside single-line IFs, so how could the program ever have been successfully compiled with PB?

                  > I don't know why they were there

                  Because the source code violated the rules specified in the docs.

                  > or why they disappeared.

                  That seems pretty clear to me, getting rid of the single-line IFs got rid of one entire class of errors for you. Am I missing something?

                  > Some that had line numbers within
                  > the IF created an unjustifiable error.
                  > I just changed them to single line IF's
                  > with no other changes and all was well.

                  Can you (please) give us a specific example of that? And what was the error message? It's possible that the source code is so badly broken, or is written for a different flavor of BASIC, so that Michael's program couldn't understand it and caused some sort of additional error. (Micheal's code was written for the PowerBASIC syntax, right MCM?.)

                  > I added that and get
                  > a new unjustified error expecting END IF.

                  I'll bet if you count the IFs and END IFs in your program (excluding single-line IF statements of course) the numbers will not be the same. I spent thousands and thousands of hours -- no kidding! -- with PB/DOS and I have never seen it generate a truly unjustified "END IF expected" message.

                  > There are of course no label references within a mile
                  > of this code.

                  A "label" is not necessarily a line label. It could be that the compiler encountered something it could not identify (such as a reference to a missing SUB or variable) and was trying to tell you about it in a generic way. "Label" is a generic term.

                  > I have never encountered a compiler with little or no
                  > correlation between error messages and actual error causes.

                  Nor have I, and that includes PB/DOS.

                  > What do you do when the compiler gives an eronious
                  > error message.

                  I narrow it down to a small, clear example, and I send it to PB support. Then they usuallypoint out why my source code is broken, not the compiler. If not they fix it, and issue a compiler update. But IMO you can't realistically expect anybody to take a massively defective program like this as evidence that the compiler is broken. Or expect them to wade through it, just in case it might be a compiler error.

                  > I found about 3 or 4 errors in the code I received that resulted
                  > a hundred edits - just labels or variables that conflicted with
                  > reserved words. The code was written in 96 time frame so 3.5
                  > was probably not around then.

                  You said before that it was a PB 3.5 program. How certain are you that it really is a PB program at all? As I said, it's not possible to compile a PB program with variable names that conflict with reserved words, so I don't understand how this program could possibly have been created with PB. So expecting PB to understand it is... probably not realistic. Feed Spanish into your word processor's spell checker and see what happens.

                  Perhaps it's TurboBASIC, an ancestor of PowerBASIC? FirstBASIC, the free beginners compiler that PB used to publish? Even more likely (IMO) it's QuickBasic or QBasic, or Microsoft PDS. If any of those are the case I would expect a whole hornet's nest of nasty, difficult-to-find errors. Fix one and another pops up, etc.
                  Please take this in the spirit it's offered, but you seem very hostile toward the compiler itself. Take a look around this BBS (including the PB/DOS forum) and you'll see very, very, very few examples of actual compiler malfunctions. And a very good record of fixing them when they are found.

                  Micheal --

                  Any guesses about the original language?

                  -- Eric




                  [This message has been edited by Eric Pearson (edited April 18, 2005).]
                  "Not my circus, not my monkeys."

                  Comment


                  • #10
                    >(Micheal's code was written for the PowerBASIC syntax, right MCM?.)

                    Looks like either PB 2.0 or possibly Turbo BASIC. (No UDTs, so it 'could' be TB). (Needless to say, the author didn't insert the "compiler and version" comments I'm always whining about).

                    Or maybe... when was support for $INLINE pulled? This program uses $INLINE "filename.bin" in it.

                    One note is present.. code says it's copyright 1987-1995. I'm pretty sure that the "PowerBASIC" brand did not appear til '88 or '89.. so I guess it could be Turbo BASIC easily enough.

                    ' here's a fairly representative sample.. which gives away.. well, you tell me what you can learn from this code...

                    Code:
                    mw% = 7
                    ScrnArray = 9000
                    DIM wrow%(mw%),wrows%(mw%),wcol%(mw%),wcols%(mw%),wattr%(mw%),wbrdr%(mw%)
                    DIM wshdw%(mw%),scrn%(ScrnArray),wptr(mw%)
                    PAI#=4*ATN(1)
                    ON KEY(1) GOSUB HELPD
                    ON KEY(10) GOSUB KEYTRAP
                    ON KEY(2) GOSUB BAKS
                    ON ERROR GOTO DLOAD1
                    KEY(1) ON
                    KEY(2) ON
                    GOSUB MEXIST  'MOUSE CHECK
                      H=256:CLS
                      MA=0:KTP=0
                    9 COLOR 15,1,11
                      DEF SEG=&H9000
                      YP1=253:YP2=255
                    ' ** INITIAL CONSTANTS ******
                      N=0:OPEN "C:\tb\ecm\LANGP.DAT" FOR INPUT AS #1
                    LANG1:
                      INPUT #1,A$,A1$:PASS$(N,0)=A$:PASS$(N,1)=A1$:IF EOF(1) THEN CLOSE #1 ELSE N=N+1:GOTO LANG1
                      BLN=VAL(PASS$(0,0)):N=0:OPEN "C:\tb\ecm\TEX796.DAT" FOR INPUT AS #1
                    TEXINP:
                      INPUT #1,A$,A1$:IF A$="END" THEN CLOSE #1:GOTO LANG2
                    REM  SELECT CASE BLN
                    ...
                    Now picture 7519 lines like this.

                    Michael Mattias
                    Tal Systems Inc. (retired)
                    Racine WI USA
                    [email protected]
                    http://www.talsystems.com

                    Comment


                    • #11
                      when was support for $INLINE pulled?
                      It looks like $INLINE is still supported in PB/DOS 3.5.

                      Perhaps the references to "C:\tb\..." are a clue.

                      ------------------
                      If you try to make something idiot-proof, someone will invent a better idiot.
                      If you try to make something idiot-proof, someone will invent a better idiot.

                      Comment


                      • #12
                        Matthew --

                        Bingo. Good eye!

                        TB was the nickname for TurboBASIC, a Borland product, and that's the directory name that was used by default. When Borland dropped support for BASIC it was significantly enhanced by Bob Zale and became PowerBASIC 1.0. There's a lot of distance between TB v.anything and PB v3.5, so I'm not surprised that the compiler is balking at lots of different things.

                        > INPUT #1,A$,A1$:PASS$(N,0)=A$:PASS$(N,1)=A1$:IF EOF(1) THEN CLOSE #1 ELSE N=N+1:GOTO LANG1

                        Yikes! John, my sympathy goes out to you.

                        -- Eric

                        ------------------
                        Perfect Sync Development Tools
                        Perfect Sync Web Site
                        Contact Us: mailto:[email protected][email protected]</A>



                        [This message has been edited by Eric Pearson (edited April 18, 2005).]
                        "Not my circus, not my monkeys."

                        Comment


                        • #13
                          Finally! A chance for us old farts to feel useful again!

                          (FWIW, I thought TB was a hell of product for the approx $100 it cost me back in 1990).


                          Michael Mattias
                          Tal Systems Inc. (retired)
                          Racine WI USA
                          [email protected]
                          http://www.talsystems.com

                          Comment


                          • #14
                            I will respond to Bob Zales comments:

                            He said:

                            BZ: I would imagine that your DIM statement doesn't work because
                            you're using it improperly.

                            JY: I didn't write this thing.
                            But what's wrong with DIM CONST$(45)

                            BZ: Nobody could offer a better response than that because you
                            haven't chosen to share any information at all about it.

                            JY: Really???? I sent you the entire source file.

                            BZ: When you show some code which appears to "fail", you may get a
                            more helpful response. The response you received from our support
                            engineer was perfectly correct.

                            JY: I sent the entire file and simply asked why the DIM
                            statement failed.
                            I didn't expect anything but an answer to that question.
                            I warned him about the terible state of this code.


                            BZ: It is not the job of our support folks to debug your programs
                            for you. When you show them code with many, many obvious
                            mistakes in it, they can't just fix everything in your code
                            for you for free. That's what they would have to do in
                            order to isolate the problem with your DIM statement.

                            JY: The code I sent did not have hundreds of errors in it. In
                            fact I fixed about 4 errors to get it to compile correctly
                            right to the last line. It still reports one error at the end.

                            To answer the question that keeps comming up as to whether the
                            program was written in PB - I simply don't know. Maybe it started
                            in Borland basic and was completed in PB ?.? or something else.
                            The owner and possibly the author stated in no uncertain terms
                            PB 3.5. Given the creation date this is probably false. This one
                            of an on going series of machine control programs. Maybe they have
                            evolved from earlier varsions to PB 3.5 now. I am no
                            historian on Basic dialects on the PC but there is a remarkable
                            degree of compatability between this code and PB. I doubt I could
                            take 12K statements make a few changes and run it on another
                            compiler. I bought PBdos and PBcc based on this information.

                            BZ: If you wish to avail yourself of our paid support option,
                            I'll be happy to arrange it for you. Our rep was simply
                            trying to offer you an alternative which would save you
                            some money.

                            JY: Do you have some really knowledgable people for this?


                            John


                            ------------------

                            Comment


                            • #15
                              >To answer the question that keeps comming up as to whether the
                              >program was written in PB - I simply don't know. Maybe it started
                              >in Borland basic and was completed in PB ?.? or something else.
                              >The owner and possibly the author stated in no uncertain terms
                              >PB 3.5. Given the creation date this is probably false.

                              Given the fact that it doesn't compile using PB 3.5, it's definitely false.

                              As others have told you, the bit of source code posted here and the use of a "c:\tb" as the root directory for the program datafile strongly suggests that it is a Borland Turbo Basic program. Turbo Basic is NOT the same as PowerBasic, though they look similar on the surface. PowerBasic has a lot more reserved words, as one example of things that will trip you up on a project of this nature.

                              > JY: Do you have some really knowledgable people for this?

                              What, exactly, is your objective here? To compile the program so it can be run? To modify the program to meet new business requirements? Something else?

                              Depending on what it is that you wish to do, there are three options for you to consider.

                              First, you can attempt to convert the program to PB. This is the most obvious but may not be the most practical.

                              Second, you can get a copy of Turbo Basic and compile it with that. Someone may have a copy that they would be prepared to sell you, or they may be prepared to compile the source code for you and send you an executable. As one example, if I dig into my pile of "stuff" I can probably find a copy of Turbo Basic 1.0 and 1.1, whichever is required, and might be persuaded to compile your software for you using that for a small fee to cover my time and effort.

                              Third, you can scrap the existing code and re-write the program from scratch, either in PowerBasic or another language of your choice. You state that this is a machine control program; I have personally found that PB is an excellent language for control and logging applications.

                              Any of these options can be contracted out to a third party if you wish. There are probably several old-time BASIC-on-DOS programmers who read this message board (I know there is at least one because I'm here) and someone may be interested in working on this project.

                              As you can see, there are several solutions that you can explore to get your situation resolved in a satisfactory manner. At a greater or lesser cost in time and dollars, depending on your actual requirements.

                              Panic is not required.

                              ------------------
                              PB/DOS 3.5 on Fedora Linux

                              Comment


                              • #16
                                My response to Eric Peterson

                                Um... The PB/DOS documentation says that Error 476 means:

                                Block/scanned statements (like WHILE/WEND, DO/LOOP and
                                SELECT CASE) and are not allowed in single-line IF statements

                                JY: I read this and looked for errors in IF's But there
                                wasn't an IF anywhere near the error. Maybe I take the
                                documentation too literally. I call it unjustifiable when
                                an error regarding IF's happens at a SUB definition.

                                ...and when you used Michael's program to convert all
                                of your single-line IF statements to IF-blocks,
                                the errors went away. My guess would be that some
                                of those single-line IF statements contained
                                block/scanned statements. If that's the case,
                                I don't see how you get "unjustified 476 errors" out of that.
                                If that's not the case, please post an actual example.
                                By being so vague you're making it really hard for people
                                to help you.

                                Again, this really points toward a program that wasn't
                                really written in PowerBASIC after all. PB has never
                                allowed block statements inside single-line IFs,
                                so how could the program ever have been successfully
                                compiled with PB?

                                JY: As I have said before there were no erronious IF's
                                anywhere near the error. I have always assumed the compiler stops
                                at or at least near the error. Am I incorrect?


                                That seems pretty clear to me, getting rid of the single-line
                                IFs got rid of one entire class of errors for you.
                                Am I missing something?

                                JY YES there were no IF errors. Should I say it again and
                                again? In fact the conversion created 4 errors in multiline
                                IF's. Line numbered lines within the IF caused an error which
                                was fixed by putting them into single IF form. I deleted the
                                line number as a test first that fixed it.

                                Can you (please) give us a specific example of that?

                                JY Not easilly I edited them out. I'll try to backtrack
                                to re-create them. I'd like you to realize I am not dreaming.

                                It's possible that the source code is so badly broken,
                                or is written for a different flavor of BASIC,
                                so that Michael's program couldn't understand it
                                and caused some sort of additional error.

                                JY As I've said before it had only a few errors about 4.

                                (Micheal's code was written for the PowerBASIC syntax, right MCM?.)

                                > I added that and get
                                > a new unjustified error expecting END IF.

                                I'll bet if you count the IFs and END IFs in your program
                                (excluding single-line IF statements of course)
                                the numbers will not be the same.

                                JY I had not considered the entire scope of the program
                                for IF imbalance. If there is an IF left on the stack at the
                                end of the program why doesn't the compiler tell us where it is?
                                Others do.

                                > There are of course no label references within a mile
                                > of this code.

                                A "label" is not necessarily a line label.
                                It could be that the compiler encountered something it
                                could not identify (such as a reference to a missing SUB
                                or variable) and was trying to tell you about it in a
                                generic way. "Label" is a generic term.

                                JY Label doesn't mean label????

                                Label has a specific meaning in my experience. Do you
                                not discriminate between a symbol, a variable, a token
                                and a label. I will have to broadly expand my interpretation
                                of the documentation.


                                > I have never encountered a compiler with little or no
                                > correlation between error messages and actual error causes.

                                Nor have I, and that includes PB/DOS.

                                JY I have provided examples. My current problem is error 463
                                undefined line/label reference which occurs on the last
                                line. There are of course no references anywhere near this.

                                I tried the following: I inserted at random GOSUB DOGPOOP.
                                The compiler never pointed at the error, it instead reported
                                the error at the last line. Does this compiler not report
                                the error on the line on which it occured? This is what I
                                mean by little or no correlation. Any language I have
                                used would report a missing symbol on the line where
                                it occured. Is the reporting of errors nowhere near
                                the location normal for PB ??? Maybe I expect too much.


                                > What do you do when the compiler gives an eronious
                                > error message.

                                I narrow it down to a small, clear example, and I send
                                it to PB support. Then they usuallypoint out why my
                                source code is broken, not the compiler.

                                JY Simple example can be usefull or useless. I attributed
                                the problem to a compiler crash or overflow of some type.
                                I did envision a basic problem with DIM, how could anything
                                work in that case. I thought the only way to demonstrate it
                                would be in complete form. If you trouble shoot only trivial
                                cases you build and excellent compiler for trivial programs.

                                If not they fix it, and issue a compiler update.
                                But IMO you can't realistically expect anybody to
                                take a massively defective program like this as
                                evidence that the compiler is broken.
                                r expect them to wade through it, just in case
                                it might be a compiler error.

                                > I found about 3 or 4 errors in the code I received that resulted
                                > a hundred edits - just labels or variables that conflicted with
                                > reserved words. The code was written in 96 time frame so 3.5
                                > was probably not around then.

                                You said before that it was a PB 3.5 program.

                                JY No I was told it was a PB program. The conflicts put this
                                in question but when you consider a couple of conflicts and a
                                couple of errors it is mighty close.

                                How certain are you that it really is a PB program at all?

                                JY I didn't write it so I'm not at all certain. The owner
                                claims PB. Are you aware of any compilers that would
                                be this close?

                                JY My best guess would be an earlier version of PB.
                                I addressed this more detail in the response to Bob Zale.

                                As I said, it's not possible to compile a PB program
                                with variable names that conflict with reserved words,
                                so I don't understand how this program could possibly
                                have been created with PB. So expecting PB to understand it is... probably not realistic. Feed Spanish into your word processor's spell checker and see what happens.

                                JY With a few changes it appears to understand it well. Maybe
                                a few symbol global replacement were done to improve clarity
                                without re-compiling. I've seen funny things happen. It was
                                written in Japan presumably by people that had Engish as their
                                second language. Given that context they did a great job.

                                This program does not get high marks for style but is not unlike
                                most peoples early attempts at programming. It takes years to
                                become a good programmer and some will never get there. The end
                                result is this program runs thousands of machines all over the
                                world. In fact millions of PC memory modules - maybe even the ones
                                in your computer and mine were built by it. We use the machine
                                every day to build complicated aircraft instruments. As long as
                                it does that I don't have time to worry about what language it
                                is...was...or might be written in.

                                It's a lot easier to find terrible code than it is great code.
                                I'd bet there is a lot of code like this embedded in all sorts of
                                devices we take for granted.

                                I would not have written it this way nor would I have written it
                                in Basic. My goal is to get it running, make a few changes, fix
                                a few bugs and get back to my real job.


                                ------------------

                                Comment


                                • #17
                                  I put this in a previous reply but thought I should present it alone.

                                  Randomly put GOSUB DOGPOOP in your program. Does the compiler
                                  find it and report its location to you? Mine reports it at the end.
                                  Is this normal?


                                  JY

                                  ------------------

                                  Comment


                                  • #18
                                    Your program doesn't compile due to an apparent error 463.

                                    You add another error 463 condition to your program and it still doesn't compile due to error 463.

                                    I don't want to sound like I'm talking down to you, but what did you expect to see that you didn't see?

                                    I had a flat tire so I punctured the tire on the other side of the car and can't understand why I now have two flats.

                                    ------------------
                                    PB/DOS 3.5 on Fedora Linux

                                    Comment


                                    • #19
                                      John --

                                      As I mentioned before, PB/DOS (like most modern compilers) is a two-pass compiler. That means that it scans the source code once to collect certain information, then scans it a second time to create the executable. If you add a type of error that is not detected in pass 1 it will not be detected until you correct all of the errors that are detected in pass 1. Apparently your DOGPOOP error is a pass 2 error, so I'm not surprised that the compiler found the other error first, even if it is located physically "later" in the code.

                                      > I fixed about 4 errors to get it to compile correctly
                                      > right to the last line. It still reports one error at the end.

                                      At the end. Of pass one. It's likely that pass 2 will find even more errors, because that's when the "details" are analyzed. Getting an error on the last line of a program does not indicate that the rest of the program is error-free.

                                      > Maybe it started in Borland basic and
                                      > was completed in PB ?.?

                                      How can that possibly be true if the program will not compile in PB because of multiple keyword incompatabilities? I don't have any PB 1.0 manuals any more, but 2.0 lists SORT as a reserved word and I believe that 1.0 did as well. It looks to me like the guy who wrote it is not being accurate, or maybe he gave you an old version of a program that was later converted to PB. But it seems impossible for this program to have ever compiled in PB other than possibly 1.x. That does not imply perfect compatability with 3.5.

                                      > Maybe a few symbol global replacement were
                                      > done to improve clarity without re-compiling.

                                      Sorry, but I find that idea much less likely than "it's a TB program". Did they also change it to have syntax that isn't PB-compatible?

                                      > there is a remarkable degree of compatability
                                      > between this code and PB.
                                      > I doubt I could take 12K statements make
                                      > a few changes and run it on another compiler.

                                      But you were not able to do that! Or you wouldn't be here.

                                      > Label doesn't mean label?

                                      I was wrong about that one. I just looked up Label in the PB/DOS manual and you're right, "label" means "line label". So I guess I'd like to see a specific example of the compiler complaining about a missing label on a line that does not contain a reference to a label.

                                      By the way, did you check the file for improper CR/LFs as I suggested? That can make the compiler count lines incorrectly, resulting in an error "on the wrong line". Who knows what the TB editor did to the original files.

                                      Believe it or not I'm not just trying to shoot you down. I don't think you're dreaming. But your statements about this are 100% contrary to my own extensive experience with PB/DOS so I have been skeptical when you have posted claims that the compiler errors don't make any sense. My largest PB/DOS program was so large that it had to be broken up into 21 different .PBC chain files, and I have never run into an error message that was truly erroneous in PB/DOS 3.5. On the other hand I have never tried to compile a TB program with PB 3.5, so maybe you are finding something new. Maybe there's something in TB syntax that trips up PB. Without concrete examples we have no way to determine that.

                                      > I call it unjustifiable when
                                      > an error regarding IF's happens at a SUB definition.

                                      That's a perfect example! A SUB is a "scanned" statement, so you can't put one just anywhere. The documentation for 476 continues "Also, you cannot have a procedure or function definition nested within the body of another definition." A SUB is exactly that kind of definition.

                                      SUB is a scanned statement. The error message is "Block/scanned statement not allowed here". That does not sound like an unjustifiable error to me, it sounds like there is an error above the SUB, and some type of block is being left "unterminated". I would definitely expect that error if there was a missing END SUB above the SUB line, or a missing LOOP, END SELECT, WEND, or any other improperly finished block. Probably even an IF block under the right circumstances, and you have said that you had to change a lot of single-line IFs into blocks. Are you certain that they are all 100% correct?

                                      > I have always assumed the compiler stops
                                      > at or at least near the error

                                      It does. For example in the case above the compiler is being very clear about the line of code that is causing the problem: the SUB line is not allowed there.

                                      > If there is an IF left on the stack at the
                                      > end of the program why doesn't the compiler
                                      > tell us where it is?

                                      Because from the compiler's perspective the missing END IF isn't the problem, the SUB line is. There could be a missing $ENDIF, a missing LOOP, etc. etc. etc. So when the compiler finds something that isn't allowed it says "hey, this isn't allowed here". It doesn't back-track to try to figure out which of several possible errors caused it. If it pointed to an IF and said "missing END IF" and the problem turned out to be a missing $ENDIF you'd be even more confused. ($IF and $ENDIF can be used to "hide" sections of code, so a missing $ENDIF could hide an END IF, etc.) Pointing at the line that is causing the error is perfectly logical, IMO.

                                      Here's a better example... If a program contains this code:
                                      Code:
                                      IF whatever THEN
                                          '(lots of code)
                                          IF something THEN
                                              '(lots of code)
                                        END IF
                                        '(lots of code)
                                      SUB MySub
                                         '(lots of code)
                                      END SUB
                                      ...where should the compiler point? It can't rely on the indenting -- you're not even required to indent your code -- so which IF is missing its END IF? The only thing the compiler can do is point at the SUB and say "this isn't legal here". See what I mean? If the compiler guessed that it had to be the first IF, or the second, it might be wrong. Pointing to the SUB is the only guaranteed-accurate thing that it can do!

                                      Let's continue. Please, try to be very specific about one error message and let's focus on that. You don't have to post then entire program, just post the exact error message, the line where the compiler says the error is located, and (arbitrarily) 10 lines on either side.

                                      -- Eric




                                      [This message has been edited by Eric Pearson (edited April 19, 2005).]
                                      "Not my circus, not my monkeys."

                                      Comment


                                      • #20
                                        The 'indents' in that beautify program should be helping with this.

                                        However, it might be easier to spot these problems if you change the number of spaces per indent level, which you can do by changing one constant in the program:

                                        at line 33:
                                        Code:
                                        'standard indent increment is 3 spaces
                                           %indentincr = 3
                                        Change that to 8 or 10 and it should be a lot easier to spot "unclosed" block structures.

                                        Michael Mattias
                                        Tal Systems Inc. (retired)
                                        Racine WI USA
                                        [email protected]
                                        http://www.talsystems.com

                                        Comment

                                        Working...
                                        X