BBC BASIC for Windows
IDE and Compiler >> Compiler >> Another bug in v 6.0?
http://bb4w.conforums.com/index.cgi?board=compiler&action=display&num=1437324693
Another bug in v 6.0?
Post by KenDown on Jul 19th, 2015, 3:40pm

Recently I upgraded to v. 6 and everything seemed to run fine. Then I wrote a short program that uses a transparent window to overlay the screen (specifically while playing video) and then read in subtitles from a file. (Don't ask: it was something I needed.)

I ran the program multiple times while writing it and everything worked fine. When I was satisfied I compiled it and to my astonishment it appeared to hang up. A little debugging produced the message "Mistake in line 0" - even when I used line numbers in the program.

After much hair-tearing I identified the offending line, a seemingly innocuous
w%=0

Remove it and the program worked fine when compiled (though of course there were problems later on when w% was called!) I tried varying the position, changing the variable name, setting it to FALSE rather than 0, but always the same problem and the same unhelpful error message.

Finally the light dawned. I loaded the program into v.5.95 and compiled it and it runs just fine.

I'll be happy to send the program if that would help.
Re: Another bug in v 6.0?
Post by rtr2 on Jul 19th, 2015, 4:38pm

on Jul 19th, 2015, 3:40pm, KenDown wrote:
Another bug in v 6.0?

Another? If it's really a bug it will be the first!

Quote:
A little debugging produced the message "Mistake in line 0" - even when I used line numbers in the program.

Whether you used line numbers in the source program or not is irrelevant: the compiler removes them (by default). Only if you actually reference the line number in the program - which hopefully you wouldn't - or if you deselect the 'Concatenate lines' option, are line numbers retained in an EXE.

Quote:
I'll be happy to send the program if that would help

Please do, although it would be very helpful if you can first pare it down to the minimum amount of code which demonstrates the issue.

Past experience makes me suspect it's not a bug but some faulty code which is accepted by the interpreter (through being more tolerant of mistakes) but not by the compiler.

Richard.
Re: Another bug in v 6.0?
Post by KenDown on Jul 19th, 2015, 5:19pm

It's a very short program. I don't use line numbers but may include them temporarily to help in debugging. I don't concatenate lines.

I have REMed out the lines which load arrow bmps into two of the buttons. The fault remains and is not exacerbated by their absence.

Note that the program works fine from the program editor provided there is a text file called "Overlay.txt" in the same directory, consisting of two or more lines of text separated by lines consisting of a single comma. When compiled, however, I have to use Ctrl+Alt+Delete and force the program to close.


PROCinit
*SYS 1

click%=0
ON SYS click%=FNsys(@msg%,@wparam%,@lparam%):RETURN
SYS"DragAcceptFiles",@hwnd%,1

REPEAT
pause%=INKEY(1)
CASEclick%OF
WHEN100:click%=0
IFword%>0word%-=1:VDU7
CLS
PROCprint(word$(word%))
WHEN101:click%=0
word%+=1
CLS
PROCprint(word$(word%))
IFword%>w%end%=TRUE
WHEN104:end%=TRUE
ENDCASE
MOUSEx%,y%,b%
CASEb%OF
WHEN4
CASETRUE OF
WHENdraw%=TRUE
MOVEx%,y%
REPEAT
MOUSEx%,y%,b%
IFy%>60DRAWx%,y%
UNTILb%=0
WHENfill%=TRUE
c%=POINT(x%,y%)
GCOL0,128+c%
IFy%>60FILLx%,y%
ENDCASE
SYS"BringWindowToTop",@hwnd%
WHEN2:CLS
PROCprint(word$(word%))
WHEN1
end%=TRUE
ENDCASE
UNTILend%
SYS"DeleteObject",larrow%
SYS"DeleteObject",rarrow%
CASETRUE OF
WHENINSTR(@dir$,"Desktop")>0:PROCdeletebmps
WHENINSTR(@dir$,"Transparent\")=0:PROCdeletebmps
ENDCASE
VDU7
QUIT
:
DEFPROCprint(a$):LOCALi%
py%=300
nw%=xscreen%-200
VDU5
REPEAT
REPEAT
REPEAT:i%+=1:UNTILMID$(a$,i%,1)=" "ORi%>LENa$
SYS"GetTextExtentPoint32",@memhdc%,LEFT$(a$,i%),i%,nsize{}
UNTILnsize.x%>nw%ORi%>LENa$
IFnsize.x%>nw%-16REPEAT:i%-=1:UNTILMID$(a$,i%,1)=" "
SYS"GetTextExtentPoint32",@memhdc%,LEFT$(a$,i%),i%,nsize{}
lx%=(xscreen%-nsize.x%)

GCOL0,0:MOVElx%,py%:PRINTLEFT$(a$,i%-1)
GCOL0,15:MOVElx%-8,py%+8:PRINTLEFT$(a$,i%-1)
a$=MID$(a$,i%+1):i%=0
py%-=100
UNTILa$=""ORpy%<100
VDU4
GCOL0,9
ENDPROC
:
DEFPROCdeletebmps
OSCLI("Delete leftarrow.bmp")
OSCLI("Delete rightarrow.bmp")
ENDPROC
:
DEFFNsys(M%,W%,L%)
CASEM%OF
WHEN273:click%=W%AND&FFF
REMWHEN563:PROCdrag(W%,L%):click%=0
ENDCASE
=click%
:
DEFPROCdrag(W%,L%)
SYS"DragQueryFile",W%,-1,0,0TON%
IFN%=0ENDPROC
SYS"DragQueryFile",W%,I%,K%,255
PROCopen($$K%)
ENDPROC

:
DEFPROCinit
INSTALL@lib$+"WINLIB5"

SYS"GetSystemMetrics",0TOxscreen%
SYS"GetSystemMetrics",1TOyscreen%
SYS"SetWindowLong",@hwnd%,-16,&16000000:REM Remove title bar and furniture
SYS"SetWindowPos",@hwnd%,-1,0,-30,xscreen%,yscreen%,32:REM Set window to full screen
VDU 26
COLOUR129:GCOL0,129
CLS
transparent%=TINT(0,0)
SYS"SetWindowLong",@hwnd%,-20,&80000
SYS"SetLayeredWindowAttributes",@hwnd%,transparent%,0,1
end%=FALSE
VDU23,23,4;0;0;0;
GCOL0,9
gcol%=9
bot%=yscreen%-30
but1%=FN_button("",0,30,60,30,100,&80)
but2%=FN_button("",xscreen%-60,30,60,30,101,&80)
but3%=FN_button("Load",0,62,60,30,102,0)
but4%=FN_button("Quit",0,94,60,30,104,0)

REMSYS"LoadImage",0,@dir$+"leftarrow.bmp",0,60,30,16TOlarrow%
REMSYS"LoadImage",0,@dir$+"rightarrow.bmp",0,60,30,16TOrarrow%
REMSYS"SendMessage",but1%,247,0,larrow%
REMSYS"SendMessage",but2%,247,0,rarrow%

draw%=TRUE
DIMword$(400)
DIMnsize{x%,y%}
F%=OPENIN(@dir$+"OverlayText.txt")
w%=0
REPEAT
a$=GET$#F%:IFa$=""a$=GET$#F%
IFa$<>","word$(w%)+=a$ELSEw%+=1
UNTILEOF#F%
CLOSE#F%

OSCLI("FONT Ariel,36,B")
word%=-1
ENDPROC
Re: Another bug in v 6.0?
Post by rtr2 on Jul 19th, 2015, 6:59pm

on Jul 19th, 2015, 5:19pm, KenDown wrote:
The fault remains...

As I suspected, it's something which is accepted by the interpreter but not by the compiler. To be precise you have omitted a required space here:

Code:
            IFword%>w%end%=TRUE

If you change this line to:

Code:
            IFword%>w% end%=TRUE

or, arguably even better:

Code:
            IF word%>w% THEN end%=TRUE

it will compile and run successfully.

In general you seem to be writing 'compressed' code - you have omitted spaces at almost every opportunity, as if you were wanting to squeeze the program in the 16K of a Model A BBC Micro!

Don't do it. On the contrary use plenty of 'white space', long variable names, loads of REMs etc. to make your program as readable and maintainable as possible. When you finally 'compile' your program BB4W will automatically take out all the 'unnecessary' verbosity.

Richard.
Re: Another bug in v 6.0?
Post by KenDown on Jul 19th, 2015, 9:22pm

Well, I did cut my teeth on a BBC model A until I could afford a B, so yes, I do omit spaces at every opportunity and actually find them an annoying distraction.

Anyway, thanks for finding the problem. Are there any other instances in which v.6 requires spaces? After all, the program compiles happily on v.5.95. If spaces are now required in certain circumstances, I think we should be alerted to them.

Thanks again.
Re: Another bug in v 6.0?
Post by rtr2 on Jul 19th, 2015, 10:44pm

on Jul 19th, 2015, 9:22pm, KenDown wrote:
Are there any other instances in which v.6 requires spaces?

BBC BASIC has always required spaces in many situations, such as:

Code:
      IFcondition variable=number

Obviously a space between "condition" and "variable" is essential here. However not all cases are as obvious:

Code:
      WAIT delay

Here, by analogy with the IF example above, one might expect it to be acceptable to omit the space, but it isn't.

Because the rules governing when you must include a space, and when it's optional, are quite complicated the safest thing to do is always to include it - and it makes the program much more readable.

Quote:
After all, the program compiles happily on v.5.95.

The change comes about because of the introduction of 64-bit integer variables having a %% suffix. Previously, if the compiler encountered a percent sign it knew it must be the last character of the variable name, but that is no longer the case. So now it waits until it sees a character which definitely cannot be part of the name (for example a space).

The interpreter, on the other hand, has the luxury of parsing the program as it is executed at run-time, so a similar ambiguity doesn't arise.

Quote:
If spaces are now required in certain circumstances, I think we should be alerted to them.

I would turn this on its head: where have you seen in the BB4W documentation that spaces can be omitted? As far as I am aware nowhere does it say that, and you will be hard pressed to find any example programs which do so (except RHEOLISM!).

Few if any other dialects of BASIC allow you to omit spaces in the way you are doing, it's a quirk of BBC BASIC which was exploited in the BBC Micro days to squeeze more functionality in the limited memory, but it has always been discouraged. I would never do it myself, and I would venture to suggest that you are probably the only BB4W user who does.

It's a habit I would try to kick.

Richard.