Proposal to extend SYS statement (BBCSDL)

Here you can suggest additions and modifications to BB4W or BBCSDL
RichardRussell
Posts: 94
Joined: Tue 15 Oct 2019, 09:10

Proposal to extend SYS statement (BBCSDL)

Post by RichardRussell » Mon 04 Nov 2019, 15:06

In both BBC BASIC for Windows and BBC BASIC for SDL 2.0 a semicolon (;) at the end of a *RUN (or OSCLI "run...") command signifies that it should return immediately rather than waiting for the command to execute. On a multi-core CPU (which is the norm these days) this means that the interpreter can be getting on with something else, and hence save time. Of course this is only possible when the succeeding BASIC code doesn't depend on the outcome of the command.

In BBCSDL (but not BB4W) a similar situation can occur with the SYS statement. If it calls a GUI function (typically one of the SDL 2.0 functions), indicated by one of the parameters being @memhdc%, it must be executed in the context of the main thread, not the interpreter's thread. In principle it would be possible for the interpreter to continue execution whilst the function executes, so long as nothing is returned, but currently there is no syntax to indicate this.

So my proposal is to leverage the semicolon for this purpose as well. The syntax of the SYS statement would become:

Code: Select all

      SYS `function` [,parameters] [TO var]|[;]
The optional trailing semicolon would necessarily be mutually exclusive with the TO clause, because the latter implies that the return value is wanted. Such a feature would be particularly valuable in the case of multiple graphics calls, such as:

Code: Select all

      SDL `SDL_SetRenderDrawColor`, @memhdc%, r&, g&, b&, a& ;
      SDL `SDL_SetRenderDrawBlendMode`, @memhdc%, SDL_BLENDMODE_ADD ;
      SDL `SDL_RenderFillRect`, @memhdc%, rect{}
Not having to wait for the first two functions to return would allow a degree of concurrency which should speed up the operation somewhat.

Do you think such a change is a good idea, and more importantly would you make use of it? I don't want to waste my time implementing a feature that is never used.
My posts are moderated; if you are seeing this it has already been approved. If you have a comment about the style or tone of the message please report it to the moderators by clicking the exclamation mark icon rather than complaining on the public forum.

KenDown
Posts: 91
Joined: Wed 04 Apr 2018, 06:36

Re: Proposal to extend SYS statement (BBCSDL)

Post by KenDown » Mon 04 Nov 2019, 17:21

I must admit that I was unaware of this semi-colon business - perhaps it is less important in BB4W. As I don't write code that is so time dependant (ie. no games) I doubt I would use such a facility, but of course that is just me.

RichardRussell
Posts: 94
Joined: Tue 15 Oct 2019, 09:10

Re: Proposal to extend SYS statement (BBCSDL)

Post by RichardRussell » Mon 04 Nov 2019, 17:56

KenDown wrote:
Mon 04 Nov 2019, 17:21
I must admit that I was unaware of this semi-colon business - perhaps it is less important in BB4W.
The semicolon in *RUN (OSCLI "run...") is every bit as important in BB4W. Even something as simple as spawning a copy of 'bbcwrun6', as for example an IDE would need to do to run a BASIC program, is going to need the semicolon because it wouldn't be desirable to have to wait 'indefinitely' for the spawned program to exit before the IDE regains control! The code in SDLIDE.bbc (which is compatible with BB4W as well as BBCSDL) to do this is:

Code: Select all

      DEF PROCexecute(bbcfile$, flag$)
      ON ERROR LOCAL IF FALSE THEN
        IF BB4W% THEN
          OSCLI "RUN """ + @lib$ + "..\bbcwrun6.exe"" """ + bbcfile$ + """;"
        ELSE
          CASE @platform% AND &F OF
            WHEN 0:
              SYS "WinExec", """" + @lib$ + "..\bbcsdl"" """ + bbcfile$ + """ " + flag$, 1
            OTHERWISE:
              OSCLI "RUN """ + @lib$ + "../bbcsdl"" """ + bbcfile$ + """ " + flag$ + ";"
          ENDCASE
        ENDIF
      ENDIF : RESTORE ERROR
      ENDPROC
with the relevant line being:

Code: Select all

          OSCLI "RUN """ + @lib$ + "..\bbcwrun6.exe"" """ + bbcfile$ + """;"
But your reaction makes me doubt whether adding the feature to the SYS statement in BBCSDL is worthwhile. How much do you use BBCSDL? How familiar are you with calling SDL2 GUI functions from BBC BASIC? It's only of value in those combined circumstances.
My posts are moderated; if you are seeing this it has already been approved. If you have a comment about the style or tone of the message please report it to the moderators by clicking the exclamation mark icon rather than complaining on the public forum.

KenDown
Posts: 91
Joined: Wed 04 Apr 2018, 06:36

Re: Proposal to extend SYS statement (BBCSDL)

Post by KenDown » Tue 05 Nov 2019, 06:28

As I don't use BBC SDL at all, you can hardly use my response as an indication for whether it would be useful in that language. Indeed, I have never, to the best of my recollection, used *RUN in BB4W, so again, my response shouldn't be taken as indicative.

I do have a feature in my Display program that allows me to execute another program, usually one that plots a graph or performs some other graphical function, but in that case I just use

OSCLI(progname$)

Would OSCLI("RUN "+prognames$) offer any advantage other than allowing the Display program to continue without waiting for the called program to complete?

I can't find this SDLIDE.bbc - is it one of the example programs?

svein
Posts: 34
Joined: Tue 03 Apr 2018, 19:34

Re: Proposal to extend SYS statement (BBCSDL)

Post by svein » Tue 05 Nov 2019, 09:46

Do you think such a change is a good idea, and more importantly would you make use of it?
Yes and yes.
How much do you use BBCSDL?
Not as much as BB4W as of today, but if my transition from windows to linux goes well, then i will only use BBCSDL.

Regards Svein

DDRM
Administrator
Posts: 150
Joined: Mon 02 Apr 2018, 18:04

Re: Proposal to extend SYS statement (BBCSDL)

Post by DDRM » Tue 05 Nov 2019, 10:39

My tuppence worth (if it's worth that much...):

I can see that this would be a useful feature to add - if I understand correctly, it would allow a degree of concurrency between screen drawing activities and other processing, which will surely be a good thing, at least most of the time.

In terms of MY usage: at the moment I don't use BBC-SDL much, but since I am spending more and more time in unix environments, and now have a smart phone, I can quite see that that might change!

I'm guessing that the most valuable situation would be in games programming, which tend to be both graphically intensive and speed-critical? Enhancing this aspect of BBC-SDL can only improve its attractiveness.

Best wishes,

D

RichardRussell
Posts: 94
Joined: Tue 15 Oct 2019, 09:10

Re: Proposal to extend SYS statement (BBCSDL)

Post by RichardRussell » Tue 05 Nov 2019, 12:32

KenDown wrote:
Tue 05 Nov 2019, 06:28
As I don't use BBC SDL at all
I hope you're not typical! BBCSDL runs perfectly well in Windows and is completely free and unrestricted, so is a good choice for anybody who might want their programs to run on other platforms (or simply prefers not to pay!). It's also being actively developed, unlike BB4W.

Where it admittedly does fall short is that it doesn't support calling Windows API functions (which means you can't write programs that exactly reproduce the standard Windows GUI), it can't create single-file executables (instead it creates an 'application bundle' in the form of a zip file) and it doesn't support hard-copy output (e.g. to a printer).
I do have a feature in my Display program that allows me to execute another program, usually one that plots a graph or performs some other graphical function, but in that case I just use OSCLI(progname$)
OSCLI progname$ is synonymous with OSCLI "RUN " + progname$, the only difference being that the former will fail if progname$ happens to start with the name of one of the built-in commands, whereas the latter will work in that situation. This has been the case since the BBC Micro in 1982. In BB4W or BBCSDL both commands can take a trailing semicolon to indicate 'return immediately without waiting for the command to terminate'; this is documented here.
I can't find this SDLIDE.bbc - is it one of the example programs?
Sorry, I assumed you were familiar with BBCSDL. SDLIDE is one of the two IDEs (Integrated Development Environments) supplied: Andy Parkes' BBCEdit and my SDLIDE. BBCEdit was the original IDE whereas mine came along some while later; both remain supported but mine has been more actively developed of late. SDLIDE is designed to have a similar look-and-feel to the BB4W IDE.

One of the crucial features of BBCSDL, which constrasts starkly with BB4W, is that both IDEs are themselves BBC BASIC programs! When BB4W was released in 2001 PCs weren't fast enough, and BBC BASIC wasn't sophisticated enough, for the IDE to be written in BASIC; instead it was written in C. But now BBC BASIC is more than capable of implementing a fairly sophisticated IDE, and of course that confers some significant advantages. Firstly it is inherently cross-platform; secondly it is amenable to modification by the user - if there's a feature you want or something that doesn't work the way you prefer, change it!

But to get back on topic, one of the many advantages of BBCSDL is that by executing the BASIC program via OSCLI (with a trailing semicolon) the IDE is completely protected from the user's program crashing, however catastrophically. In BB4W a BASIC program can, and often does, take the IDE down with it if it fails sufficiently seriously.
My posts are moderated; if you are seeing this it has already been approved. If you have a comment about the style or tone of the message please report it to the moderators by clicking the exclamation mark icon rather than complaining on the public forum.

KenDown
Posts: 91
Joined: Wed 04 Apr 2018, 06:36

Re: Proposal to extend SYS statement (BBCSDL)

Post by KenDown » Tue 05 Nov 2019, 14:49

That would be a problem for me, as I do use the Windows routines extensively - creating windows, making them transparent, positioning and resizing them, reading the length of UTF strings, using text edit routines, and on and on.

Thanks for clarifying about OSCLI and OSCLI(RUN. I presume that by "built-in commands" you mean something like a BASIC keyword such as PRINT or DRAW. Not that I want to do any such thing, but as I always use upper case for BASIC keywords, would a file name such as "draw.exe" work or is the case irrelevant?

Yes, that business about the IDE being written in BASIC and therefore easy for the user to modify or add to is very attractive. One day I'll get around to downloading BBC SDL and trying it, but at the moment, with my Display program stable and doing all the things that I want, I'm resting on my laurels, so to speak!

RichardRussell
Posts: 94
Joined: Tue 15 Oct 2019, 09:10

Re: Proposal to extend SYS statement (BBCSDL)

Post by RichardRussell » Tue 05 Nov 2019, 16:01

KenDown wrote:
Tue 05 Nov 2019, 14:49
That would be a problem for me, as I do use the Windows routines extensively - creating windows, making them transparent, positioning and resizing them, reading the length of UTF strings, using text edit routines, and on and on.
Most of the features you described (such as creating, positioning and resizing windows, reading the length of UTF8 strings etc.) aren't specific to Microsoft Windows; all modern desktop operating systems (including Linux and MacOS) support equivalent operations, and SDL 2.0 exposes them in its API. SDLIDE relies on those features to create its user interface.

You would of course have to learn how to do those things in a cross-platform fashion rather than in a Windows-specific fashion, but that's as much an opportunity as a problem! I spent at least 15 years programming virtually exclusively in BBC BASIC for Windows, learning how to achieve what I needed using a combination of native BBC BASIC statements and calls to the OS. Now I almost never use BB4W, and I'm gradually learning how to do those same things in SDL 2.0.

Of course SDL2 isn't as rich in its capabilities as Windows (or any 'native' windowing OS) is, that's inevitable because of its cross-platform nature. It necessarily can only support features that all common operating systems share, and are used sufficiently commonly to be worth implementing. So there will be things that you are used to being able to do in Windows which have no direct equivalent, but the challenge then is to work around such limitations.
I presume that by "built-in commands" you mean something like a BASIC keyword such as PRINT or DRAW.
No, they are statements, not commands (you may consider the distinction pedantic, but it's important here). The built-in star commands are listed in the Help manual; the list is a long one but includes *CD, *COPY, *DIR, *DISPLAY, *HELP and so on; many, probably most, of your programs are likely to use at least one. The point I was making is that OSCLI progname$ will fail if progname$ starts with one of those commands:

Code: Select all

      OSCLI "myhelp.exe"   tries to run the program 'myhelp'
      OSCLI "helper.exe"   displays the version number of BB4W or BBCSDL!
To run the program 'helper.exe' you would have to add the RUN to avoid the ambiguity:

Code: Select all

      OSCLI "RUN helper.exe"
I always use upper case for BASIC keywords
Star commands are not case-sensitive. *HELP and *help are synonymous (and again I would point out that this has been the case for 38 years!).
My posts are moderated; if you are seeing this it has already been approved. If you have a comment about the style or tone of the message please report it to the moderators by clicking the exclamation mark icon rather than complaining on the public forum.

KenDown
Posts: 91
Joined: Wed 04 Apr 2018, 06:36

Re: Proposal to extend SYS statement (BBCSDL)

Post by KenDown » Wed 06 Nov 2019, 06:25

No, not pedantic, just my ignorance of the distinction.

I certainly agree about opportunities rather than problems - it's the right attitude to have - but at the same time one needs to have the spare time to put into making use of the opportunity! A big motive is the cross-platform capability: does one need to compile (or whatever the expression is) separately for Apple, Windows and Linux and how could I be certain that it would work on an Apple unless I go to the expense of buying one?

Post Reply