posted March 12, 2005 10:43 AM            

I just received PBCC 4 and was anxious to put it to work. I compiled a production program, not the ‘Hello world’ type of programs that every compiler company (in the world!) uses to show the prowess of their products. The program ran well compiled with PBCC 2.11, 3.0, and 3.04. I recompiled it, without any change in code, with PBCC 4. The program compiled well and performed well. One might expect a penalty in performance when many new features are added to the language. There was no change in performance, as far as I can tell.

My main curiosity and interest were directed at the (in)famous error handling of PBCC. After so many and intense debates, one would have hoped to see a final solution to error handling…errors by PBCC. Not! Non! Virtually the same incoherent and incorrect error handling. I caused several types of errors in the source code.

'FOR I=1 TO TOT-1: FOR J = I+1 TO TOT
    IF AvDv(I) > AvDv(J) THEN
       SWAP AvDv(I), AvDv(J)
    END IF
NEXT J: NEXT I
Primary source:  SUMS.BAS   {3309 total lines}
Target compilation:  SUMS.exe
Compile time:  0.2 seconds, at 992700 lines/minute
85140 bytes compiled code, 21019 bytes RTLibrary,
8352 bytes string literals, and 11952 bytes dgroup.
Executable stack size:  1048576 bytes.
Disk image: 127488 bytes   Memory image: 41323 bytes.

Curiously, the compiler did not care about the FOR/NEXT error!
I ran the program without and with the FOR/NEXT error.

a) - the correct results, without the forced error:

             Statistics For File: X:\LOTTERY\PA-5
      Drawings            Sum     AvgDev     AvgDel
====================================================
   2   8  18  29  30       87       9.92      7.00
   5  10  12  27  34       88      10.32      7.25
  10  24  29  33  34      130       7.20      6.00
====================================================
 Medians:                 100       8.64*     6.75
====================================================
b) - the INcorrect results, forcing an error:
             Statistics For File: X:\LOTTERY\PA-5
      Drawings            Sum      AvgDev     AvgDel
=====================================================
   2   8  18  29  30       87        9.92      7.00
   5  10  12  27  34       88       10.32      7.25
  10  24  29  33  34      130        7.20      6.00
=====================================================
 Medians:                 100        2.80**    6.75
=====================================================
The erroneous parameter is marked by **.
-------------------

OPEN FILE ERROR IGNORED BY THE COMPILER:

LOCATE 22, 10: PRINT " Writing the "; UCASE$(fi2$); " file to disk . . . "
' OPEN fi2$ FOR OUTPUT AS #2
PRINT #2,

Primary source:  SUMS.BAS   {3312 total lines}
Target compilation:  SUMS.exe
Compile time:  0.2 seconds, at 993600 lines/minute
85204 bytes compiled code, 21019 bytes RTLibrary,
8352 bytes string literals, and 11952 bytes dgroup.
Executable stack size:  1048576 bytes.
Disk image: 127488 bytes   Memory image: 41323 bytes.
-------------------
FOR/NEXT TYPE OF DETECTED ERRORS:
FOR I=1 TO TOT-1: FOR J = I+1 TO TOT
    IF Avg(I) > Avg(J) THEN
       SWAP Avg(I), Avg(J)
    END IF
'NEXT J: NEXT I
Error 447 in SUMS.BAS(1146:008):  IF expected
Line 1146:        ELSEIF Choice1$ = "R" THEN

The debugger always jumps to the highest hierarchic loop, regardless of its nature.

CONCLUSIONS
From PBCC help file:
“When a compile-time error is detected, PowerBASIC will display a message box indicating the error code, plus a brief description, along with the LINE NUMBER in the code where the error occurred. The offending line of code will also be displayed. If you are using the PowerBASIC IDE, the caret will move to the offending line once the error dialog has been dismissed.”
THAT’S MISLEADING INFORMATION!
This CAVEAT EMPTOR is the only accurate information:
“While this results in code that is considerably smaller and faster than any other Windows compiler product, it does put more of an ONUS on the programmer to write code that is BUG-FREE…”
Say, what? BUG-FREE? Has there been a perfect programmer — ever? Think about yourself, Bitser Zale. How many programming errors have you committed? Countless, of course. It’s human. Errare humanum est. Just look at the PBCC compiler… Sincerely, however, I consider you to be a true computing genius. But you need to pay much more attention to the error handling of PBCC. Just think what the consequences would have been for Microsoft IF their languages had handled errors like PBasic. After a few class action suits, MS would have gone the way of the dinosaur! “Run it at your own risk” does NOT work all the time in the legal system. I remember of a software company who wrote memory-expanding software for Windows. The company was killed shortly by a class-action lawsuit. The company had very visible warnings (like the tobacco products): “Run it at your own risk!” Of all people, I received a $30 check as the result of that lawsuit…

I am NOT implying legal action against PB. I do appreciate the creations of the tiny team of computing enthusiasts. I have written hundreds of programs in PowerBasic. The programs perform well. They are also small in size. The small size made possible for me to distribute hundreds of programs over the Internet. Should I have used VB, the results would have been a herd of dinosaurs. VB adds automatically 1.5MG (yes, megabytes) even to a ‘Hello, world’ program!

I am dissatisfied with the attitude of the PBasic guys! Not long ago, they tried to make believe that the way PBCC handled errors was a virtue, not a sin! Now, they dropped that claim. But they still don’t take fixing the error handling very seriously. It’s time for them to stop adding all kinds of garbage commands and statements to the compilERR (sic!) Instead, they must put every bit of their effort in fixing the debugger and error handling. They must offer a free fix to every programmer who bought PB compilers. The computing enthusiasts at PowerBasic Inc. owe that to their programming followers. That ‘Inc.’ is the most compelling reason!

Ion Saliu
Doctor and Patient in Errare Humanum Est
www.saliu.com

posted March 12, 2005 01:44 PM            

quote:

---

It’s time for them to stop adding all kinds of garbage commands and statements to the compilERR (sic!) Instead, they must put every bit of their effort in fixing the debugger and error handling.

---

I for one wouldn't complain about errors in my source code unless I had used the tools available to me to detect the error messages generated by the compiler.

That's just my opinion, but having been a customer of PB for nearly 2 decades, I'm willing to bet most people believe the same.

posted March 12, 2005 02:36 PM            

#COMPILE EXE
#DIM ALL
FUNCTION PBMAIN () AS LONG
LOCAL i AS LONG
LOCAL j AS LONG
LOCAL tot AS LONG
tot = 10
REDIM AvDv(tot) AS LONG
'FOR I=1 TO TOT-1: FOR J = I+1 TO TOT
    IF AvDv(I) > AvDv(J) THEN
       SWAP AvDv(I), AvDv(J)
    END IF
NEXT J: NEXT I

END FUNCTION      

And this one error 459: NEXT expected

#COMPILE EXE
#DIM ALL
FUNCTION PBMAIN () AS LONG
LOCAL i AS LONG
LOCAL j AS LONG
LOCAL tot AS LONG
tot = 10
REDIM AvDv(tot) AS LONG
FOR I=1 TO TOT-1: FOR J = I+1 TO TOT
    IF AvDv(I) > AvDv(J) THEN
       SWAP AvDv(I), AvDv(J)
    END IF
'NEXT J: NEXT I

END FUNCTION

Regarding PRINT#, why don't use ON ERROR or TRY/CATCH?

posted March 12, 2005 02:48 PM            

Thanks, Jose.

Bob

posted March 13, 2005 10:00 AM            

1) Yes, there is a LOT more than just one FOR/NEXT loop! They are deeply nested in SELECT CASE, IF/END IF blocks…
If there is more than one error, the consequences are even more unpredictable. If a GPF is triggered, the consequences resemble programming in the mad house!

Jose, why don’t you try to write a real program, something with one thousand more lines than ‘Hello, world’?

2) Here you distort the truth, just to make your parrot point:

FUNCTION PBMAIN () AS LONG
LOCAL i AS LONG
LOCAL j AS LONG
LOCAL tot AS LONG
tot = 10
REDIM AvDv(tot) AS LONG
FOR I=1 TO TOT-1: FOR J = I+1 TO TOT
    IF AvDv(I) > AvDv(J) THEN
       SWAP AvDv(I), AvDv(J)
    END IF
'NEXT J: NEXT I
END FUNCTION

It trips the compile error:
“Error 459 in C:\PBCC40\SAMPLES\PBForum1.bas(13:005): NEXT expected
Line 13: END FUNCTION”

3) About your parrot suggestion of using ON ERROR.
Every SUB has it’s own well thought out error handling routine. I always use DEBUG ERROR ON during development. I even keep DEBUG ERROR ON in some EXE files — I learned that the best way to look at PBCC is to mistrust it. Otherwise, grave errors can result. I know it first hand. But I keep using the compiler because I do like how the programs compiled in PBCC perform. I go beyond the cursing during the development, seeing light at the end of the tunnel: highly performing EXEs!

Some errors are not triggered by the compiler, even IF ON ERROR and/or DEBUG ERROR ON are enabled. The compiler simply doesn’t care about anything, sometimes!

4) As of TRY/CATCH, you parrot again one of Bitser Zale’s previous responses. “Tell us PRECISELY the erroneous statements, and we’ll help you.” If I had known PRECISELY the erroneous statements, would I have complained, o wise ones, o axiomatic sons of Logos and Axioma?

Who could add TRY/CATCH verification to hundreds of loops and logical blocks? You, tropical parrot, would suggest immediately: “Add TRY/CATCH precisely to the blocks where the errors occur!” “Gracias, but no, thanks!”

4) I post in this strong manner because I want to help PB and help myself in the process. I intend to keep using PBCC. So, a real improvement in error handling by PBCC would be of much help to my programming endeavors. I do not go as far as asking PBCC to handle error the same way as VB. VB does it so greatly, that PBCC looks like the cave man. But when comparing the EXE performance, VB looks like the girly man!

PBasic should look around. No serious compiler misbehaves so badly as PBCC regarding error handling. Every serious compiler points exactly the error, its type, and the line where it occurred. That’s a MUST for every compiler. PBCC disregards that compliance. Which makes PBCC’s slogan:
“Compile with a big compromise — dangerously erroneous error handling!”

It is a whole more than simply “put more of an ONUS on the programmer to write code that is BUG-FREE…”

Ion Saliu
Doctor and Patient in Errare Humanum Est
www.saliu.com

posted March 13, 2005 10:24 AM            

Excuse me, sir, but the little ten-line snippet you posted seems to pass all the required edits and returning the correct compile-time errors.

Since it is your "real program" which has a problem, let me suggest that perhaps you would get better-quality assistance if you posted the entire failing code along with your compiler name and version.

posted March 13, 2005 10:53 AM            

'Code posted won't compile here
'The compile caught the missing FOR/NEXT 
'Would you try this code and modify it to not work
'Are we using the same compilers?  
#COMPILE EXE
#DIM ALL
FUNCTION PBMAIN () AS LONG
 ON ERROR GOTO errorTrap
 LOCAL AvDv&(),I&,j&,t&,tot&
 DIM AvDv(1 TO 10)
 
 FOR I=1 TO TOT-1                         ' I is set to I and exits loop
  PRINT "I'm inside the I loop, wrong"
  
  FOR J = I+1 TO TOT
    PRINT "I'm inside the J loop, wrong"
    
    IF AvDv(I) > AvDv(J) THEN
       SWAP AvDv(I), AvDv(J)
    END IF
  NEXT J
  
 NEXT I
 PRINT "The value of I is "I
 
 PRINT "No error"
 GOTO Endprogram
EXIT FUNCTION
ErrorTrap:
 RESUME EndProgram
EndProgram:
 PRINT "End program, press any key"
 PRINT "The value of J" J
 PRINT "The value of I" I
 PRINT "The value of Tot"Tot
 WAITKEY$
END FUNCTION

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

posted March 13, 2005 11:18 AM            

quote:

---

2) Here you distort the truth, just to make your parrot point:

---

quote:

---

Jose, why don’t you try to write a real program, something with one thousand more lines than ‘Hello, world’?

---

quote:

---

Who could add TRY/CATCH verification to hundreds of loops and logical blocks? You, tropical parrot, would suggest immediately: “Add TRY/CATCH precisely to the blocks where the errors occur!” “Gracias, but no, thanks!”

---

If we repeat the general advices for proper error trapping is not
because we are tropical parrots, but because some people are deaf.
------------------

posted March 13, 2005 11:59 AM            

"Profanity and rude or derogatory comments (about PowerBASIC or others)
is prohibited. Do not post credit card numbers or product serial numbers.
PowerBASIC, Inc. reserves the right to remove any messages deemed inappropriate."

Also, if you have a specific complaint, please send a compilable example to
PB support so we can investigate. So far you have only managed to show the
compiler correctly traps even a user-constructed For/Next error. So..?

posted March 13, 2005 12:03 PM            

I really think you need to relax and take a deep breath.

You are making accusations that the compiler is malfunctioning based on an a snippet of code that will error out, EVERY TIME.

We can only make suggestions and offer help based on the code you post.

You haven't even posted the snippet of code around the offending line:

quote:

---

Error 447 in SUMS.BAS(1146:008):  IF expected
Line 1146:        ELSEIF Choice1$ = "R" THEN

---

The compiler doesn't list every error it finds, it lists the first, and drops out if it encounters one.

Is the for/next loop before or after line 1146?

If so, it won't catch it until you correct error 447...

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

posted March 13, 2005 12:54 PM            

#COMPILE EXE
#DIM ALL
FUNCTION PBMAIN () AS LONG
   LOCAL i AS LONG
   LOCAL x AS LONG
   FOR x = 1 TO 20
   'NEXT x
   ' Add a thousand lines here to make it a "real" program
   'FOR i = 1 TO 10
      x = x + i
   NEXT i
END FUNCTION

Post only these lines:

   'FOR i = 1 TO 10
      x = x + i
   NEXT i

Ask why it compiles and why x shows a "wrong" value of 21.

Take the opportunity to show your bad manners.

posted March 13, 2005 01:57 PM            

Your posted code shows absolutely no flaw in PowerBASIC Compilers.

If you actually believe you have discovered a flaw, please send a specific example to support@powerbasic.com, or post the code here. So far, you have only shown that PowerBASIC compiles perfectly. I think it's fair to say that most everyone here sees right through your trolling.

It's also fair to warn that you have repeatedly violated the rules of these forums. Your disparaging remarks (directed towards anyone) aren't welcome here. You must treat everyone with normal business respect. If you do that, we'll do our best to treat you in the same manner, and answer any question you may have. However, if you persist with antagonism, I'll need to take steps to stop it. Please don't force me to do that.

Regards,

Bob Zale
PowerBASIC Inc.

posted March 13, 2005 06:26 PM            

Ion,
I'm sure your intentions are good, but in all the years I've been around PB, I can count on one hand the number of times people complained about the error processing of the compilers. This really is a non-issue with most of us. In light of that, you really need to ask yourself why you have such a hard problem with it. There are ample tools built into the products to produce bug-free code. That's not to say that every program will be bug-free, just that the tools are there if you use them.

You're completely free to make suggestions for improvements, but if you notice that not too many people are agreeing with your stance, then don't get too upset to find your ideas have not been implemented. One of the criteria for changes come from the number of times a particular request is made. If only 3 people asked to have the color scheme of the IDE changed, there is not a very high likelyhood that Bob would change the color scheme. Know what I mean?

And has already been mentioned, calling your fellow programmers here parrots is not going to endear you to too many. Just relax, accept the fact that you're in a minority in this case, and move on.

posted March 14, 2005 02:02 AM            

I find that putting multiple statements one a single line, separated
by colons, do not lend themselves to readability, so I prefer the
alignment of statements like this:
IF ... THEN
ELSEIF ... THEN
ELSE
END IF
Of course that is a personal preference, and I admit to breaking
that rule from time to time. However, I am very strick in terms
of using a series of indents to vertically align my structures,
which makes them more visually appealing and easier to check.

So how does this relate? Well, if you use a source code
reformatter that adheres to some of these rules, then the level
of indentations currently in use can not only signal when you
have failed to complete one or more succeeding structures, but
when you attempt to close a structure that isn't even there. My
version of PBFORMAT even validates which structures are being
closed at any given time against the levels above.

So what I am saying is that the previous discussion is about
code lines that need to be there for the structures to work as
intended, but because of their compound nature, could be
missing and still have the program compile because an error here
is balanced out by an error there. The last post from J. Roca
shows this most clearly.

A program that reformats the source code by indentation alignment
and checks when the rules are broken can be very helpful in
verifying the source code structure in advance or in addition to
what the compiler tells you. Since my version always takes
commented lines and place them to the left side of the screen,
J. Roca's code would look like this:

#COMPILE EXE
#DIM ALL
FUNCTION PBMAIN () AS LONG
  LOCAL i AS LONG
  LOCAL x AS LONG
   
  FOR x = 1 TO 20
'NEXT x
' Add a thousand lines here to make it a "real" program
'FOR i = 1 TO 10
    x = x + i
  NEXT i
END FUNCTION

Note that the commented lines are move to the left edge and are
not indented as they would be if they were operational. So even
if you missed the single quote (') and the fact that it had been
commented out, the odd position for that line would indicated
that something was wrong. Commented lines in the IDE also have
their own color to set them apart, though these colors are not
supported in the Debugger in the complilers before then new
compilers.

Do maybe you should try using a program that reformats your
source code to make it more readable. There is one in the
download section that works fairly well, though not quite as
well as mine does, (IMHO)(g).

Another point: PowerBasic is like a fancy sports car that is
designed to be as fast as possible. It does not default to
elaborate error checking, because that would put the brakes on
and slow it down. It goes for speed, speed, speedm and that is
what we love about it.

But you always have the option to turn on debugging features and
either check for errors yourself, or trap for them. These are
often necessary during code development, and every programmer
has that option. Later, when you have some confidence in your
program, you may elect to turn them off or remove code that is
related to possible errors, but that is both your perogative and
your responsibility. PowerBasic does not "blind" you to
possible errors, it just races on without checking for them
unless you tell it to do otherwise. Even with error checking it
is very fast, and usually I turn on that feature and leave it
enabled. Fact is, I rarely use the complied EXE, just load the
IDE and the source code, and compile and run it on the fly. It
complies so fast that there is hardly any penality involved.

posted March 14, 2005 04:02 AM            

You get one or the other but not both..

Our original plant computer?
A Xerox Prodac P250 ( only turned off 1.5 years ago )
Discrete transistor flip flops..
32 K ( thats right K not M ) of ram
Processed some 1100 inputs 40/60 analog / digital.
Performed routine tasks, alarms, printouts etc.
Originally used paper tape for program input.

My point ? You had to be sure you did not code where an error
could be introduced.. it was your responsility not to allow errors
such as out of bounds, division by 0 .. etc...

Code Complete is a good book that will teach us all about good programming
habits... Hey how did I get on this soap box......