Matrix Brandy BASIC VI for console and SDL1.2: V1.22.7 released

for discussion of bbc basic for windows/sdl, brandy and more
User avatar
Richard Russell
Posts: 1593
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Matrix Brandy BASIC VI for Linux with SDL: V1.22.6 released

Post by Richard Russell » Tue Jun 30, 2020 9:52 am

Soruk wrote:
Tue Jun 30, 2020 8:36 am
This surprised me as:

Code: Select all

a&=&FF
a&=a&+2
....gives 1.
For compatibility with all versions of BBC BASIC going back to the very start, unsigned 8-bit lvalues truncate before assignment.
You surely wouldn't expect a& to behave differently from ?v%%:

Code: Select all

      DIM v%% 0 
      ?v%% = &FF
      ?v%% = ?v%%+2
      PRINT ?v%%
Again, they can't behave differently in my BASICs, because internally there is no difference between a& and ?v%%!

Soruk
Posts: 774
Joined: Mon Jul 09, 2018 11:31 am
Location: Basingstoke, Hampshire
Contact:

Re: Matrix Brandy BASIC VI for Linux with SDL: V1.22.6 released

Post by Soruk » Tue Jun 30, 2020 10:32 am

Richard Russell wrote:
Tue Jun 30, 2020 9:52 am
Soruk wrote:
Tue Jun 30, 2020 8:36 am
This surprised me as:

Code: Select all

a&=&FF
a&=a&+2
....gives 1.
For compatibility with all versions of BBC BASIC going back to the very start, unsigned 8-bit lvalues truncate before assignment.
You surely wouldn't expect a& to behave differently from ?v%%:

Code: Select all

      DIM v%% 0 
      ?v%% = &FF
      ?v%% = ?v%%+2
      PRINT ?v%%
Again, they can't behave differently in my BASICs, because internally there is no difference between a& and ?v%%!
I wasn't criticising, I was just pointing out the apparent anomaly. Anyhow, Matrix Brandy also wraps around - and the two examples in the previous post neither raise an error in Matrix Brandy, and give &8000000 / -2147483648 as a result so at least they're consistent. While that deviates from the BBC - and RISC OS (even BASIC VI gives "Floating point exception" ( ! ) on the FPA build for RiscPC) in this instance I'm not changing it.
Matrix Brandy BASIC VI (work in progress)

User avatar
Richard Russell
Posts: 1593
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Matrix Brandy BASIC VI for Linux with SDL: V1.22.6 released

Post by Richard Russell » Tue Jun 30, 2020 11:08 am

Soruk wrote:
Tue Jun 30, 2020 10:32 am
While that deviates from the BBC - and RISC OS (even BASIC VI gives "Floating point exception" ( ! ) on the FPA build for RiscPC) in this instance I'm not changing it.
That's up to you, but if Matrix Brandy is going to behave differently from Sophie's BASICs I would have preferred it to issue an error in both cases rather than to truncate in both cases! The big risk with truncation, in my opinion, is that it can happen mid-way through a complex calculation and result in an answer that is wrong, but not so obviously so as to attract attention. That can make it potentially dangerous to use in some applications.

One of the major early commercial applications for BBC BASIC for Windows was SimpleEPOS (since discontinued) which was a Point-Of-Sale application for small retailers. Financial calculations should always be performed entirely in integers (since errors resulting from representing decimal fractions in floating-point binary can accumulate), typically of pence/cents or smaller denominations if required. I'm not suggesting it is likely, but undetected integer overflows are most undesirable in that kind of application!

Soruk
Posts: 774
Joined: Mon Jul 09, 2018 11:31 am
Location: Basingstoke, Hampshire
Contact:

Re: Matrix Brandy BASIC VI for Linux with SDL: V1.22.6 released

Post by Soruk » Tue Jun 30, 2020 2:20 pm

Richard Russell wrote:
Tue Jun 30, 2020 11:08 am
Soruk wrote:
Tue Jun 30, 2020 10:32 am
While that deviates from the BBC - and RISC OS (even BASIC VI gives "Floating point exception" ( ! ) on the FPA build for RiscPC) in this instance I'm not changing it.
That's up to you, but if Matrix Brandy is going to behave differently from Sophie's BASICs I would have preferred it to issue an error in both cases rather than to truncate in both cases! The big risk with truncation, in my opinion, is that it can happen mid-way through a complex calculation and result in an answer that is wrong, but not so obviously so as to attract attention. That can make it potentially dangerous to use in some applications.

One of the major early commercial applications for BBC BASIC for Windows was SimpleEPOS (since discontinued) which was a Point-Of-Sale application for small retailers. Financial calculations should always be performed entirely in integers (since errors resulting from representing decimal fractions in floating-point binary can accumulate), typically of pence/cents or smaller denominations if required. I'm not suggesting it is likely, but undetected integer overflows are most undesirable in that kind of application!
You raise a very good point - adjusted.
Matrix Brandy BASIC VI (work in progress)

Soruk
Posts: 774
Joined: Mon Jul 09, 2018 11:31 am
Location: Basingstoke, Hampshire
Contact:

Re: Matrix Brandy BASIC VI for Linux with SDL: V1.22.6 released

Post by Soruk » Tue Jun 30, 2020 2:37 pm

I've merged the uint8 code on to mainline. Additionally, DELETE with no parameters now generates an error instead of nuking the program, and OLD now reports Unsupported, as it never worked properly and is rather pointless.
Valid combinations of DELETE include:
DELETE lineno
DELETE lineno, - deletes from lineno to end of program inclusive.
DELETE ,lineno - deletes from start of program to lineno inclusive.
DELETE startline,endline - deletes from startline to endline inclusive
DELETE , - deletes everything.

Note this is more permissive than ARM BBC BASIC (RiscOS, not Richard's BB4C for RasPi) which strictly only allows DELETE startline,endline.
Matrix Brandy BASIC VI (work in progress)

Soruk
Posts: 774
Joined: Mon Jul 09, 2018 11:31 am
Location: Basingstoke, Hampshire
Contact:

Re: Matrix Brandy BASIC VI for Linux with SDL: V1.22.6 released

Post by Soruk » Tue Jun 30, 2020 5:25 pm

Another change is that Immediate mode commands (e.g. LIST, RUN, AUTO) can no longer be entered in lower case (it can be re-enabled at compile time with -DBRANDY_ALLOW_LOWERCASE_COMMANDS).

I've also rebuilt the nightlies for today's date.
Matrix Brandy BASIC VI (work in progress)

scruss
Posts: 262
Joined: Sun Jul 01, 2018 4:12 pm
Location: Toronto
Contact:

Re: Matrix Brandy BASIC VI for Linux with SDL: V1.22.6 released

Post by scruss » Tue Jun 30, 2020 6:24 pm

aww, the lower-case immediate mode commands were handy. I know that BBC BASIC is traditionally all about the shouting, but I so often forget the capslock. I know I can enable them, though, so I'm just whingeing.

On one of my systems, OLD is the command for LOAD.But it's a very old system: letter-number variables, IF .. GOTO (but no THEN or ELSE), -2048..2047 integer range, and the worst error reporting ever. The joys of 12-bit computing ...

Soruk
Posts: 774
Joined: Mon Jul 09, 2018 11:31 am
Location: Basingstoke, Hampshire
Contact:

Re: Matrix Brandy BASIC VI for Linux with SDL: V1.22.6 released

Post by Soruk » Tue Jun 30, 2020 6:42 pm

scruss wrote:
Tue Jun 30, 2020 6:24 pm
aww, the lower-case immediate mode commands were handy. I know that BBC BASIC is traditionally all about the shouting, but I so often forget the capslock. I know I can enable them, though, so I'm just whingeing.

On one of my systems, OLD is the command for LOAD.But it's a very old system: letter-number variables, IF .. GOTO (but no THEN or ELSE), -2048..2047 integer range, and the worst error reporting ever. The joys of 12-bit computing ...

Code: Select all

export BRANDY_BUILD_FLAGS=-DBRANDY_ALLOW_LOWERCASE_COMMANDS
and rebuild.
Matrix Brandy BASIC VI (work in progress)

User avatar
Richard Russell
Posts: 1593
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Matrix Brandy BASIC VI for Linux with SDL: V1.22.6 released

Post by Richard Russell » Tue Jun 30, 2020 7:09 pm

scruss wrote:
Tue Jun 30, 2020 6:24 pm
the lower-case immediate mode commands were handy.
From a historical BBC BASIC perspective, allowing lowercase commands but not lowercase statements or functions makes no sense. In all early versions the commands shared the same token space as all the other keywords, indeed there was nothing to stop you putting a command in a program (it would execute but then exit to immediate mode). So commands inevitably needed to be in capitals as well.

What I do in my BASICs (BBC BASIC for Windows and BBC BASIC for SDL 2.0) is to allow you to enable lowercase keywords if you wish - although it's not recommended - but that option affects statements, functions and commands (when available) equally.

Incidentally it's not always appreciated that one reason why BBC BASIC doesn't allow lowercase keywords (or when it does it is deprecated) is because of the relatively unusual characteristic of the language that keywords don't always have to be separated from what follows. So whilst in most languages you would need to write something like SIN(RAD(angle)) BBC BASIC will allow SINRADangle. The reason for this, of course, was to allow spaces to be omitted and make the program more compact, which could be important with the very restricted memory of the BBC Micro.

Because of this feature, allowing lowercase keywords causes many variable names to become illegal: printer (not allowed because it's parsed as print er), value (because it's parsed as val ue), total (to tal) etc. There are so many examples that allowing lowercase keywords can be quite a pain.

Coeus
Posts: 1659
Joined: Mon Jul 25, 2016 12:05 pm
Contact:

Re: Matrix Brandy BASIC VI for Linux with SDL: V1.22.6 released

Post by Coeus » Tue Jun 30, 2020 7:58 pm

Richard Russell wrote:
Tue Jun 30, 2020 7:09 pm
Incidentally it's not always appreciated that one reason why BBC BASIC doesn't allow lowercase keywords (or when it does it is deprecated) is because of the relatively unusual characteristic of the language that keywords don't always have to be separated from what follows. So whilst in most languages you would need to write something like SIN(RAD(angle)) BBC BASIC will allow SINRADangle. The reason for this, of course, was to allow spaces to be omitted and make the program more compact, which could be important with the very restricted memory of the BBC Micro.

Because of this feature, allowing lowercase keywords causes many variable names to become illegal: printer (not allowed because it's parsed as print er), value (because it's parsed as val ue), total (to tal) etc. There are so many examples that allowing lowercase keywords can be quite a pain.
But there isn't there one token, at least, with a trailing bracket on it? To me, a more elegant solution to keeping the namespace for variables clean, would have been to make the tokeniser inspect the character after a token and require it to be some kind of punctuation or white space for the token to match. If it's punctuation it is stored, otherwise discarded. Then on generating a listing, after printing a token, if the next character is not punctuation then an extra space would be printed.

Soruk
Posts: 774
Joined: Mon Jul 09, 2018 11:31 am
Location: Basingstoke, Hampshire
Contact:

Re: Matrix Brandy BASIC VI for Linux with SDL: V1.22.6 released

Post by Soruk » Tue Jun 30, 2020 8:00 pm

Coeus wrote:
Tue Jun 30, 2020 7:58 pm
But there isn't there one token, at least, with a trailing bracket on it?
LEFT$(, MID$( and RIGHT$( spring to mind.
Matrix Brandy BASIC VI (work in progress)

User avatar
Richard Russell
Posts: 1593
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Matrix Brandy BASIC VI for Linux with SDL: V1.22.6 released

Post by Richard Russell » Tue Jun 30, 2020 8:11 pm

Coeus wrote:
Tue Jun 30, 2020 7:58 pm
But there isn't there one token, at least, with a trailing bracket on it?
Several, and there are also several BBC BASIC keywords that do need to be followed by whitespace or a non-alphabetic character. That's why I said "don't always have to be separated from what follows"; some do, some don't.
If it's punctuation it is stored, otherwise discarded. Then on generating a listing, after printing a token, if the next character is not punctuation then an extra space would be printed.
That could probably have worked, and as I've said in another context I'll be sure to suggest it when I get my time machine trip back to 1981. :roll:

It's only too easy to find fault with Sophie's original BBC BASIC, there are many things that she would probably do differently with the benefit of hindsight. There are things I would do differently if I started BBC BASIC for Windows today. But we are stuck with what we've got.

Soruk
Posts: 774
Joined: Mon Jul 09, 2018 11:31 am
Location: Basingstoke, Hampshire
Contact:

Re: Matrix Brandy BASIC VI for console and SDL1.2: V1.22.6 released

Post by Soruk » Thu Jul 02, 2020 4:12 pm

I've been doing an audit of the code, and as a practical upshot, as in MANY places there are similar lumps of code that branch depending on what sort of number is being retrieved (and being massaged into), that I've abstracted those out so hopefully fewer instances of a function not being happy with the type of variable it was given. It's also made the code noticeably smaller. It might be a fraction slower as there's an extra function call being made. On the flip side, it should make it easier to maintain!
Matrix Brandy BASIC VI (work in progress)

Soruk
Posts: 774
Joined: Mon Jul 09, 2018 11:31 am
Location: Basingstoke, Hampshire
Contact:

Re: Matrix Brandy BASIC VI for console and SDL1.2: V1.22.6 released

Post by Soruk » Sun Jul 05, 2020 9:13 am

I've checked in code for a new *-command, *BrandyInfo. While functionally the same as *Help BASIC and *Help MemInfo, there is a special hook so this command is also recognised within the RISC OS build. Normally, on RISC OS all *-commands are just passed to the OS.
Matrix Brandy BASIC VI (work in progress)

User avatar
Richard Russell
Posts: 1593
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Matrix Brandy BASIC VI for console and SDL1.2: V1.22.6 released

Post by Richard Russell » Mon Jul 06, 2020 12:29 am

With reference to our discussion in the other thread, what will TIME do if Matrix Brandy is left running for more than 248 days (or thereabouts)? Will it wrap from a large positive number to a large negative number, or will it keep increasing past &7FFFFFFF and remain positive, so that it cannot be stored in a 32-bit integer variable anymore?

Soruk
Posts: 774
Joined: Mon Jul 09, 2018 11:31 am
Location: Basingstoke, Hampshire
Contact:

Re: Matrix Brandy BASIC VI for console and SDL1.2: V1.22.6 released

Post by Soruk » Mon Jul 06, 2020 12:36 am

Richard Russell wrote:
Mon Jul 06, 2020 12:29 am
With reference to our discussion in the other thread, what will TIME do if Matrix Brandy is left running for more than 248 days (or thereabouts)? Will it wrap from a large positive number to a large negative number, or will it keep increasing past &7FFFFFFF and remain positive, so that it cannot be stored in a 32-bit integer variable anymore?
It will wrap. I manually bumped it close to the limit...

Code: Select all

>PRINT ~TIME
  7FFFFFEB
>PRINT ~TIME
  8000004B
>PRINT TIME
-2.14748083E+09
>_
Edit: The BBC Micro (at least JSBeeb) does the same.
Matrix Brandy BASIC VI (work in progress)

User avatar
Richard Russell
Posts: 1593
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Matrix Brandy BASIC VI for console and SDL1.2: V1.22.6 released

Post by Richard Russell » Mon Jul 06, 2020 4:39 am

Soruk wrote:
Mon Jul 06, 2020 12:36 am
Edit: The BBC Micro (at least JSBeeb) does the same.
In versions of BBC BASIC which support only 32-bit integers TIME is pretty much bound to be signed. This only becomes an issue with 64-bit extensions; in BB4W and BBCSDL I deliberately modified the behaviour of TIME so that it returns an unsigned value.

There's no clear-cut advantage one way or the other: if TIME is signed it will flip from positive to negative after 228 days, which is likely to confuse software which expects it to be montonically increasing (waiting loops such as REPEAT UNTIL TIME > timeout% may get stuck). On the other hand keeping TIME positive means that after 228 days it can no longer be stored in a 32-bit integer variable.

User avatar
sweh
Posts: 2191
Joined: Sat Mar 10, 2012 12:05 pm
Location: New York, New York
Contact:

Re: Matrix Brandy BASIC VI for console and SDL1.2: V1.22.6 released

Post by sweh » Mon Jul 06, 2020 4:50 am

I'm wondering if we need two different variables, for compatibility. TIME being 32bit and TIME%% being 64bit. 'Cos otherwise "x%=TIME" might not produce the expected result after 228 days.
Rgds
Stephen

User avatar
Richard Russell
Posts: 1593
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Matrix Brandy BASIC VI for console and SDL1.2: V1.22.6 released

Post by Richard Russell » Mon Jul 06, 2020 9:38 am

sweh wrote:
Mon Jul 06, 2020 4:50 am
I'm wondering if we need two different variables, for compatibility. TIME being 32bit and TIME%% being 64bit. 'Cos otherwise "x%=TIME" might not produce the expected result after 228 days.
How many existing programs do you think have been written to cope correctly with TIME rolling over from a large positive value to a large negative value anyway? I agree that if a program has been written with this expectation it would probably fail if TIME is allowed to keep increasing.

On the other hand there is a counter-argument that causing x%=TIME to fail with a 'Number too big' error is preferable to allowing a program to misbehave, possibly entering an 'infinite loop', when TIME wraps.

Anyway I'm not sure how plausible it is that a BBC BASIC program would be running continuously for more than 228 days, especially when you consider that we're only talking about 'desktop' editions of BBC BASIC, not embedded systems.

Soruk
Posts: 774
Joined: Mon Jul 09, 2018 11:31 am
Location: Basingstoke, Hampshire
Contact:

Re: Matrix Brandy BASIC VI for console and SDL1.2: V1.22.6 released

Post by Soruk » Mon Jul 06, 2020 9:59 am

Richard Russell wrote:
Mon Jul 06, 2020 9:38 am
sweh wrote:
Mon Jul 06, 2020 4:50 am
I'm wondering if we need two different variables, for compatibility. TIME being 32bit and TIME%% being 64bit. 'Cos otherwise "x%=TIME" might not produce the expected result after 228 days.
How many existing programs do you think have been written to cope correctly with TIME rolling over from a large positive value to a large negative value anyway? I agree that if a program has been written with this expectation it would probably fail if TIME is allowed to keep increasing.

On the other hand there is a counter-argument that causing x%=TIME to fail with a 'Number too big' error is preferable to allowing a program to misbehave, possibly entering an 'infinite loop', when TIME wraps.

Anyway I'm not sure how plausible it is that a BBC BASIC program would be running continuously for more than 228 days, especially when you consider that we're only talking about 'desktop' editions of BBC BASIC, not embedded systems.
I'm more inclined to keep TIME as is (as it has been since year dot), but may make a SYS "Brandy_someting" call to pull the underlying 64-bit value (as my centisecond timer is 64-bit under the lid).
Matrix Brandy BASIC VI (work in progress)

User avatar
Richard Russell
Posts: 1593
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Matrix Brandy BASIC VI for console and SDL1.2: V1.22.6 released

Post by Richard Russell » Mon Jul 06, 2020 10:35 am

Soruk wrote:
Mon Jul 06, 2020 9:59 am
I'm more inclined to keep TIME as is (as it has been since year dot), but may make a SYS "Brandy_someting" call to pull the underlying 64-bit value (as my centisecond timer is 64-bit under the lid).
Another 'gotcha' with TIME is that it is supposed to be a global value, i.e. different programs running in different processes should see the same value (unless altered with TIME=n). I achieve that in BB4W and the new Console Mode editions, but not in BBCSDL because my only source of elapsed time is SDL_GetTicks() which seems to be a per-process value that starts at zero each time.

This is a particular issue with programs which use TIME to seed RND, as many do, because it may greatly reduce the potential range of seeds. It's actually better not to seed RND at all but many program writers don't realise that.

Soruk
Posts: 774
Joined: Mon Jul 09, 2018 11:31 am
Location: Basingstoke, Hampshire
Contact:

Re: Matrix Brandy BASIC VI for console and SDL1.2: V1.22.6 released

Post by Soruk » Mon Jul 06, 2020 12:06 pm

Richard Russell wrote:
Mon Jul 06, 2020 10:35 am
Soruk wrote:
Mon Jul 06, 2020 9:59 am
I'm more inclined to keep TIME as is (as it has been since year dot), but may make a SYS "Brandy_someting" call to pull the underlying 64-bit value (as my centisecond timer is 64-bit under the lid).
Another 'gotcha' with TIME is that it is supposed to be a global value, i.e. different programs running in different processes should see the same value (unless altered with TIME=n). I achieve that in BB4W and the new Console Mode editions, but not in BBCSDL because my only source of elapsed time is SDL_GetTicks() which seems to be a per-process value that starts at zero each time.

This is a particular issue with programs which use TIME to seed RND, as many do, because it may greatly reduce the potential range of seeds. It's actually better not to seed RND at all but many program writers don't realise that.
Can you not use gettimeofday()? I'm using:

Code: Select all

int64 mos_centiseconds(void) {
  struct timeval tv;
  gettimeofday (&tv, NULL);
  /* tv.tv_sec  = Seconds since 1970 */
  /* tv.tv_usec = and microseconds */
  return (((unsigned)tv.tv_sec * 100) + ((unsigned)tv.tv_usec / 10000));
}
Matrix Brandy BASIC VI (work in progress)

User avatar
Richard Russell
Posts: 1593
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Matrix Brandy BASIC VI for console and SDL1.2: V1.22.6 released

Post by Richard Russell » Mon Jul 06, 2020 12:27 pm

Soruk wrote:
Mon Jul 06, 2020 12:06 pm
Can you not use gettimeofday()?
Not in BBCSDL, no, because that's not a function available on all the platforms.

In any case TIME should never be derived from a real-time clock because that can cause unexpected jumps (even backwards) when the system's clock is set (e.g. manually or automatically from a time server). That's why in the Linux and MacOS Console Mode editions I call clock_gettime(MONOTONIC...) rather than clock_gettime(REALTIME...).
I'm using:
My code is almost identical to yours, in Linux and MacOS, except that it uses the monotonic clock. The real-time clock should be used for TIME$, of course, but not for TIME in my judgement.

Soruk
Posts: 774
Joined: Mon Jul 09, 2018 11:31 am
Location: Basingstoke, Hampshire
Contact:

Re: Matrix Brandy BASIC VI for console and SDL1.2: V1.22.6 released

Post by Soruk » Mon Jul 06, 2020 2:30 pm

Richard Russell wrote:
Mon Jul 06, 2020 12:27 pm
Soruk wrote:
Mon Jul 06, 2020 12:06 pm
Can you not use gettimeofday()?
Not in BBCSDL, no, because that's not a function available on all the platforms.

In any case TIME should never be derived from a real-time clock because that can cause unexpected jumps (even backwards) when the system's clock is set (e.g. manually or automatically from a time server). That's why in the Linux and MacOS Console Mode editions I call clock_gettime(MONOTONIC...) rather than clock_gettime(REALTIME...).
I'm using:
My code is almost identical to yours, in Linux and MacOS, except that it uses the monotonic clock. The real-time clock should be used for TIME$, of course, but not for TIME in my judgement.
That's a very fair point. I've converted Matrix Brandy over to using clock_gettime(MONOTONIC..) (which has required some makefile changes, and MacOS now has its own set of makefiles). I've rebuilt the nightly Windows builds.
Matrix Brandy BASIC VI (work in progress)

User avatar
Richard Russell
Posts: 1593
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Matrix Brandy BASIC VI for console and SDL1.2: V1.22.6 released

Post by Richard Russell » Mon Jul 06, 2020 2:45 pm

Soruk wrote:
Mon Jul 06, 2020 2:30 pm
That's a very fair point. I've converted Matrix Brandy over to using clock_gettime(MONOTONIC..)
That's a worthwhile change, I would say. Can I just remind you, though, that whilst a REALTIME clock is guaranteed to exist, a MONOTONIC clock isn't. I've not yet encountered a system without one, but it's theoretically possible: "All implementations support the system-wide realtime clock, which is identified by CLOCK_REALTIME... More clocks may be implemented".

Soruk
Posts: 774
Joined: Mon Jul 09, 2018 11:31 am
Location: Basingstoke, Hampshire
Contact:

Re: Matrix Brandy BASIC VI for console and SDL1.2: V1.22.6 released

Post by Soruk » Mon Jul 06, 2020 3:23 pm

Richard Russell wrote:
Mon Jul 06, 2020 2:45 pm
Soruk wrote:
Mon Jul 06, 2020 2:30 pm
That's a very fair point. I've converted Matrix Brandy over to using clock_gettime(MONOTONIC..)
That's a worthwhile change, I would say. Can I just remind you, though, that whilst a REALTIME clock is guaranteed to exist, a MONOTONIC clock isn't. I've not yet encountered a system without one, but it's theoretically possible: "All implementations support the system-wide realtime clock, which is identified by CLOCK_REALTIME... More clocks may be implemented".
Good call. I've now created an init_clock which steps through CLOCK_MONOTONIC_RAW (on Linux), CLOCK_MONOTONIC and CLOCK_REALTIME and uses the first that clock_gettime doesn't complain about. This is excluding RISC OS, where I'm using clock() instead (code modified, but is what is used upstream and works on my RPCEmu setup).
Matrix Brandy BASIC VI (work in progress)

User avatar
Richard Russell
Posts: 1593
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Matrix Brandy BASIC VI for console and SDL1.2: V1.22.6 released

Post by Richard Russell » Mon Jul 06, 2020 3:59 pm

Soruk wrote:
Mon Jul 06, 2020 3:23 pm
I've now created an init_clock which steps through CLOCK_MONOTONIC_RAW (on Linux), CLOCK_MONOTONIC and CLOCK_REALTIME
I'm puzzled as to why you test for CLOCK_MONOTONIC_RAW (first, or indeed at all). From the point of view of TIME isn't CLOCK_MONOTONIC always a better choice? The only occasion (that I'm aware of) when one would choose the _RAW in preference, when available, is when consistency is more important than accuracy. But that's definitely not the case for TIME when a tiny amount of FM is irrelevant (it would be undetectable in interpreted BASIC) but long-term accuracy could be of some value.

I do wish you'd take more time to think about the pros and cons before rushing into making changes, but I know that's not your way! It's not conducive to developing confidence in Matrix Brandy. :(

Soruk
Posts: 774
Joined: Mon Jul 09, 2018 11:31 am
Location: Basingstoke, Hampshire
Contact:

Re: Matrix Brandy BASIC VI for console and SDL1.2: V1.22.6 released

Post by Soruk » Mon Jul 06, 2020 4:16 pm

Richard Russell wrote:
Mon Jul 06, 2020 3:59 pm
Soruk wrote:
Mon Jul 06, 2020 3:23 pm
I've now created an init_clock which steps through CLOCK_MONOTONIC_RAW (on Linux), CLOCK_MONOTONIC and CLOCK_REALTIME
I'm puzzled as to why you test for CLOCK_MONOTONIC_RAW (first, or indeed at all). From the point of view of TIME isn't CLOCK_MONOTONIC always a better choice? The only occasion (that I'm aware of) when one would choose the _RAW in preference, when available, is when consistency is more important than accuracy. But that's definitely not the case for TIME when a tiny amount of FM is irrelevant (it would be undetectable in interpreted BASIC) but long-term accuracy could be of some value.
From the man page:

Code: Select all

       CLOCK_MONOTONIC_RAW (since Linux 2.6.28; Linux-specific)
              Similar to CLOCK_MONOTONIC, but provides access to a  raw  hard-
              ware-based time that is not subject to NTP adjustments.
To me, that implies the best option if it's available.
Richard Russell wrote:
Mon Jul 06, 2020 3:59 pm
I do wish you'd take more time to think about the pros and cons before rushing into making changes, but I know that's not your way! It's not conducive to developing confidence in Matrix Brandy. :(
My git tree does include a lot of experimental changes, but I do try to stabilise things before I cut a release (and lay down a version tag). Sure, there will be some checkins that don't work and have to be reversed. And, while perhaps not the best approach, my other machines pull from my local git server to stay up to date rather than just scp'ing the source tree.(not to mention the fun and games of getting the code into RISC OS)
Matrix Brandy BASIC VI (work in progress)

User avatar
Richard Russell
Posts: 1593
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Matrix Brandy BASIC VI for console and SDL1.2: V1.22.6 released

Post by Richard Russell » Mon Jul 06, 2020 4:53 pm

Soruk wrote:
Mon Jul 06, 2020 4:16 pm
To me, that implies the best option if it's available.
Why? As I said, the NTP frequency adjustments will be undetectable in interpreted BASIC, so that only leaves long-term accuracy as the difference. Why do you prefer the less accurate clock?

I will continue to use CLOCK_MONOTONIC, with a fallback to CLOCK_REALTIME if it is not available (as I understand it there is never a CLOCK_MONOTONIC_RAW without there also being a CLOCK_MONOTONIC, since if there was only one it would have the latter name).

Soruk
Posts: 774
Joined: Mon Jul 09, 2018 11:31 am
Location: Basingstoke, Hampshire
Contact:

Re: Matrix Brandy BASIC VI for console and SDL1.2: V1.22.6 released

Post by Soruk » Mon Jul 06, 2020 5:41 pm

Richard Russell wrote:
Mon Jul 06, 2020 4:53 pm
Soruk wrote:
Mon Jul 06, 2020 4:16 pm
To me, that implies the best option if it's available.
Why? As I said, the NTP frequency adjustments will be undetectable in interpreted BASIC, so that only leaves long-term accuracy as the difference. Why do you prefer the less accurate clock?
I'm not so sure it would be less accurate. Indeed, I've seen odd stuff with system clocks on the production environment where I work if there's been a network hiccup and the NTP server has disappeared, or when a machine has been "vmotioned" from one VM host to another. It soon corrects itself but blips in the clock of over a second aren't unknown. I would need to carry out some experiments to see which gives a more stable counter in such an environment but can only do this on the systems at work so would need careful planning...
Matrix Brandy BASIC VI (work in progress)

Post Reply

Return to “modern implementations of classic programming languages”