BBC BASIC for SDL 2.0 version 1.09a released

[Deleted User 9295]

There's no particular urgency from my point of view though.

I wanted to discover if it's a bug in my code, and it is. The reason I didn't see an issue here is that I pasted your program, and hence tokenised it, on my Windows PC and then transferred the tokenised version onto the Mac to create the App bundle. Using that route it works. But if I paste/tokenise your program on the Mac, it doesn't. The difference arises because the Windows edition of BBCSDL is using the assembler version of the interpreter and the Mac edition is using the compiled-C version, and there is a difference between them (which there shouldn't be) in how ON GOTO and ON GOSUB statements get tokenised.

Specifically, in a statement like:

Code: Select all

      ON j GOTO 1234,5678

The Windows edition correctly converts both line numbers into their special encoded-binary form, but the Mac edition converts the first line number (1234) into the special form but leaves the second (5678) as plain ASCII. The insidious thing is that this doesn't affect execution of the program (apart from a slight difference in speed) but it does affect how the cruncher behaves when concatenating lines. It knows not to comcatenate line 1234 onto the previous line, but it doesn't know not to concatenate line 5678 onto the previous line.

Thus everything is explained. Thank you for helping to find this extremely subtle bug which could easily have gone unnoticed indefinitely (how many programs use ON GOTO, then get crunched, and can have the target line concatenated onto the previous one?).

[lurkio]

... Thank you for helping to find this extremely subtle bug

Fascinating! Glad I could help.

Btw, is there any way to look at the output of the Crunch process? Can the crunched program be loaded back into the BBCSDL editor?

And can the BBCSDL Cruncher produce "compressed" tokenised BASIC that could be loaded into BeebEm (in Model B mode) and run without error?

[Deleted User 9295]

Btw, is there any way to look at the output of the Crunch process? Can the crunched program be loaded back into the BBCSDL editor?

If I want to do that (and it's not something I recommend) I tend to use the 'other' IDE (Andy Parkes' BBCEdit) because it seems to be more tolerant of a crunched program than mine. On a Mac, navigating into the App Bundle to find and load the crunched program is straightforward.

And can the BBCSDL Cruncher produce "compressed" tokenised BASIC that could be loaded into BeebEm (in Model B mode) and run without error?

The BBCSDL cruncher is not ideal for this, because it offers no option to 'shorten' variable names without going the whole hog and converting them to 'fast' variables (embedded pointers to the heap), which obviously the Beeb interpreter doesn't understand. So you'd have to disable the 'Shorten names' option which largely defeats the purpose of crunching.

The BBC BASIC for Windows cruncher is more suitable for this, because it won't create 'fast' variables without an explicit REM!Fast compiler directive. Either way, the resulting crunched program would need to be converted to Acorn format, but that's easy (basically reversing the order of the first three bytes of every line).

[lurkio]

I've released version 1.09a of BBC BASIC for SDL 2.0

I noticed a minor issue with a Compiled app: the window title doesn't seem to be set correctly on launch -- it's set to some sort of random-looking alphanumeric string and remains so until you click out of the app window:

https://www.youtube.com/watch?v=II7kt1O-qrA

[Deleted User 9295]

I noticed a minor issue with a Compiled app: the window title doesn't seem to be set correctly on launch

It depends on what you mean by "correctly". There's no guarantee in my BASICs that the title bar will display anything specific; if you want it to you are expected to include a SYS "SDL_SetWindowTitle" statement in your program (or the equivalent for the particular dialect of BASIC). In the absence of such a statement the title will be set to some approximation of the filename, as ascertained by what appears in the command line. That works well on most editions, but in MacOS (and you'd have to ask Apple why) that mysterious string is appended to the command line.

[lurkio]

It depends on what you mean by "correctly". There's no guarantee in my BASICs that the title bar will display anything specific; if you want it to you are expected to include a SYS "SDL_SetWindowTitle" statement in your program

I actually already had put that SYS call in the program, as part of the code that also sets the font.

But I've now included the SYS call again, on the first line of the program, but I'm still seeing the same behaviour as before, where you have to click out of the window before the title is set to your chosen string.

Code: Select all

SYS "SDL_SetWindowTitle", @hwnd%, "Nellan Is Thirsty" 

[Deleted User 9295]

I've now included the SYS call again, on the first line of the program, but I'm still seeing the same behaviour as before

Try this to force thread affinity (it's MacOS being different from every other platform again: why should setting the window title require thread affinity?):

Code: Select all

SYS "SDL_SetWindowTitle", @hwnd%, "Nellan Is Thirsty", @memhdc%

It's in these subtle edge-cases that SDL2 fails to be a perfect abstraction layer, because although it can standardise the API it can't standardise things like thread-affinity, stack alignment and so on which the native OS might demand.

[lurkio]

Try this to force thread affinity (it's MacOS being different from every other platform again: why should setting the window title require thread affinity?):

Code: Select all

SYS "SDL_SetWindowTitle", @hwnd%, "Nellan Is Thirsty", @memhdc%

Yes, that did the trick! Thanks.