Announcement

**Bob Zale** · 17 Apr 2005, 12:34 PM

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.

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

**Eric Pearson** · 17 Apr 2005, 12:39 PM

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).]

**Michael Mattias** · 17 Apr 2005, 02:18 PM

> 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** · 18 Apr 2005, 09:18 AM

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>

**John Youngquist** · 18 Apr 2005, 10:51 AM

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

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

**Bob Zale** · 18 Apr 2005, 11:16 AM

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.

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

**Michael Mattias** · 18 Apr 2005, 11:26 AM

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.

**Eric Pearson** · 18 Apr 2005, 12:43 PM

> 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).]

**Michael Mattias** · 18 Apr 2005, 02:56 PM

>(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.

**Matthew Berg** · 18 Apr 2005, 04:34 PM

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.

**Eric Pearson** · 18 Apr 2005, 04:45 PM

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).]

**Michael Mattias** · 18 Apr 2005, 05:34 PM

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).

**John Youngquist** · 18 Apr 2005, 09:21 PM

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

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

**Frank Cox** · 19 Apr 2005, 12:34 AM

>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

**John Youngquist** · 19 Apr 2005, 12:37 AM

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.

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

**John Youngquist** · 19 Apr 2005, 12:41 AM

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

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

**Frank Cox** · 19 Apr 2005, 01:42 AM

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

**Eric Pearson** · 19 Apr 2005, 06:44 AM

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).]

**Michael Mattias** · 19 Apr 2005, 07:31 AM

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.

Announcement

un resolvable compiler errors

un resolvable compiler errors

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment