My News and Updates for RISC OS Southwest Show 2024 - Sat February 24th

To everyone interested,
here is the list of updates and new projects I’ll bring at the RISC OS Southwest Show 2024 – Sat February 24th.

- (new) QuantumPi(e), a fully distributed Quantum Computing Simulator for RISC OS (and Linux, BSD and macOS). This bad boy runs on my ROCluster and I may be able to show also a Turing Pi 2 used as a CoProcessor for a RISC OS Pi or something to off-load Quantum computations from traditional applications in eal time! And for the ROCluster fans out there (which always ask me to make it capable of simulating a single system), YES this NEW ROCluster protocol can run single step instructions in a distributed fashion, so yes all the Cluster nodes literally can act as a single super computer (where super is a simulation of a super computer lol don’t get too excited!)

- (new) UltimaVM, an high performance byte code interpreter for RISC OS (and Linux, BSD, macOS and Windows) that brings a lot of good features to RISC OS (included a security model, data encryption, hybrid preemptive multi-tasking and more) and (most of all) it’s much easier to target for modern compilers like LLVM (to allow compiling Rust, GoLang, C#, Java, JS and more for RISC OS)

- (update) RISCOS DME, The latest improvements and fixes to my RO Desktop modernization enging, will also be showing preliminary versions of the Dark Mode theme ;)

- (update) ZVector, a really useful C library to help building complex and powerful application in C on RISC OS with much, much less stress and big features like sorting CMT friendly, fancy RMA memory pools (from Jeffrey) and more.

- (update) answering questions about the YouTube channel and next videos

- Q/A for all of the above and happy to help forlks that started to use my libraries

Twitter thread here:

https://twitter.com/RISCOSOnGitHub/status/1760300948335804544

Hope to see many at the show, please come by and say hi! :)

After few questions received:

Q: How the distributed execution works?

A: A quantum program expressed in LLQPL language is read by a client thread and compiled into LLQPL bytecode, each bytecode instruction is then serialized as sent to the ROCluster (which is running the Quantum Registers Simulator, this can be all local to one single Raspberry Pi or distributed even over the Internet). The ROCluster Management Server decide to which node to dispatch the instruction for execution and then the node processes the instruction again a Quantum Resgiter using the Simulator.

A special execution status is returned to the client thread which uses it to decide if it needs to compile the next instruction or return an error (in case). The process continues until the LLQPL program execution has completed. To retrieve a Quantum Register value, in quantum computing we need to measure, so a Measure instruction has to be dispatched to the Simulator which will remove the Quantum Register from Superimposition state and simulate the Observer Effect and return the measure value.

This means that the program execution state is shared between the client thread and the Simulator via ROCluster protocol which is binary and optimized for best network performance.

If more quntum registers are needed, the ROCluster may dispatch to multiple CM4 nodes on a Turing Pi 2 (for example), this allows to run quite complex computations from a simple GCC or DDE C program.

Q: When can I try UltimaVM?

A: It’s still under active development, so it will take a while still, sorry.

Q: When the Themes will be available?

A: I am working on a Theme Management plugin, which should be available soon for early adopters, however Dark Mode still has some issues, some being addressed with ROD (for the Pinboard 2) and some with Alan (fonts gets distorted in PackMan), so it’s not ready yet for general use, but you can come at the show and have a look :)

HTH, seen you at the show!

however Dark Mode still has some issues

Don’t feel bad. We’re like, what, for dark mode capable versions of Android on and it still has problems.
Worse, some of the worst offenders are Google’s own apps (YouTube, I’m looking at you!) and because Google is “special”, their apps don’t show up in the list of “please don’t darkify these apps”…or maybe they think a menu looks correct when the background and text are the same colour?
[more likely, as is all too common nowadays, they probably didn’t even bother to check]

Select dark mode in Windows 11, and the message boxes still come up in light mode — although the file dialogs are dark.

Apple are about the only people who usually get dark mode right.

Most of the Linux desktops have been doing dark mode correctly for years. It’s why I want one for RISC OS, as switching to it from dark MATE causes severe blindness!

switching to it from dark MATE causes severe blindness!

I used to have that problem, then I had my cataracts removed.
I do dislike the overly bright displays though.

My newer phones run in dark mode all the time.
Firstly it’s better for battery life with (AM)OLEDs, and secondly my eyes are more sensitive than normal so I don’t like bright lights.

With RISC OS, my normal view of it is Zap, which is colourised code on black.

Thanks Rick and David,
I’ll pack the Dark Mode with the early release of the new Theme manager then, hopefully not too many complains will come from the usual grumpies XD

@ Druck

Most of the Linux desktops have been doing dark mode correctly for years.

Until you run an app designed for Gnome on KDE (or viceversa, or a different permutation of 2 different Desktop Managers). Linux Desktop inconsistency is legendary at this point XD, it’s ok for my daily work, but I won’t say “doing dark mode correctly for years”.

Plus the transition from X11 to Wayland is being another entertining/popcorn moment in the Linux community ahaha :D

I would add another joke at this point: And also 2024, is NOT going to be the year of the Linux Desktop! ;)

P.S. sorry, I couldn’t resist it ahah :D

but I won’t say “doing dark mode correctly for years”.

I would, having used one (on a desktop with both GTK and Qt applications) for over a decade. But since you seem to have made up your mind already, I won’t try to convince you.

having used one (on a desktop with both GTK and Qt applications) for over a decade. But since you seem to have made up your mind already, I won’t try to convince you.

Thanks Frank, I appreciate your not trying to change the evidence ;)

Also, just as a side note, what you are refering to are only the case when two different DM have the exact same theme, which is not doing dark mode right, just to be clear. Maybe a language thingy, in which case whatever, but technologically speaking and in terms of code implementation, Linux does NOT have a standard API and well defined general protocol for dark mode (or even non-dark mode for this matter).

Whatever. What matters to me is that the DE I’m using gives me a consistent dark mode, no matter what application I use. Windows doesn’t and unfortunately RISC OS doesn’t either. Lately I’ve been unable to do much work on what once was my favourite OS…

Hey, if we’re posting desktop screenshots, here’s mine. ;)

https://heyrick.eu/blog/files/mydesktop20240225.jpeg
(no dark mode…yet!)

Don’t tell me zombies count as light!

Hey, if we’re posting desktop screenshots, here’s mine. ;)

That is quite dark

Couldn’t you just reduce the brightness of the screen? What’s the difference?

(no dark mode…yet!)

XD – Rick I promise you’ll be the first beta tester for the Dark Mode, I am just trying to implement a congruent approach for all the configure plugins I’ll need for my DME. So, instead of “infesting” the traditional Configure Window, I am thinking of implementing a single Configure Plugin like “Desktop” which opens it’s own configuration infrstructure and there to have my Theme Manager configuration and other configure plugins. I think this is actually a great question for Gerph.

There are reasons for this:

- DME supports RISC OS from 3.10 all the way to 5 passing by 4 and 6

- DME provides a lot of desktop features enancements that I am working on, list will be increased as I move forward.
Each of which needs it’s own configuration and there is also a main tool to enable/disable features (to save memory on older manchines)¹.

- DME provides also a bin path for RunPath with extra commands and will deliver also the module based package manager

And given that folks have asked for a clean remove of the entire suite, I think it’s going to be much easier for me to have only one configuration “entry point” if that makes sense.

¹ I know many people don’t care about older systems in this forum, but I have plenty of users across all RISC OS releases, so that ain’t an option for me and, beside, I do use multiple releases myself and I want my desktop improvements to be available on all my systems.

Hey, if we’re posting desktop screenshots, here’s mine. ;)

Creepy… but I’m curious about the ‘cup of tea’ icon…

‘cup of tea’ icon…

First thought that it was a network mount! BITD we had beverage related servers, like Teapot and Cappucino. Stemming from an incident with a kettle lead, a Winchester drive, and a MD who wanted his cuppa.

It’s exactly what it says, it’s “the tea device”. After a certain amount of activity it reminds me to drink the tea that I have made (before it gets too cold) along with periodic reminders to go make fresh tea.

Otherwise, you know, I’ll get into something and before you know it it’s quarter past eight and dark outside…

Cold T? ∃ microwave oven. ;-)

Ewwwwwwwww!!!!!!

(can’t you taste the difference?)

I am just trying to implement a congruent approach for all the configure plugins I’ll need for my DME. So, instead of “infesting” the traditional Configure Window, I am thinking of implementing a single Configure Plugin like “Desktop” which opens it’s own configuration infrstructure and there to have my Theme Manager configuration and other configure plugins. I think this is actually a great question for Gerph.

I’m not sure what you’re asking as a question here.

I think you’re talking about having a way to provide plugins within the main Configure, so that everything isn’t a flat structure, and you can provide small independant plugins to configure the different areas of your system without having everything at the top level. If that’s what you’re asking then… welcome to 2001.

The RISC OS 4 structure that was supplied for configuration was a reasonable step to make it possible to have an application that could function as a gateway to others tools, allowing 3rd parties to supply configurations for their components as necessary. Plus it meant that any part of the system that needed its own configuration could be created and deployed independantly without having to rebuild a single application with a multitude of options. I presume that Acorn took their experience with ResEd’s and applied it to the !Configure system – as all the configuration plug ins used Toolbox, that seems likely. It’s what you have right now in RISC OS 5, I believe.

It’s very similar to the configuration system that I had created for RISC OS 3.1 in my !Config+ application, albeit mine was pretty awful because it used BASIC libraries to provide each of the plugins. Although I did describe the configuration windows through their functions rather than by designing templates (‘add an option button’, ‘add a slider’, ‘add a set of radio icons’, etc). Anyhow, Acorn did it far better…

But, they still had a problem. All your plugins live at one level. If you want to have a configuration for a sub-system that have multiple parts, then you still have to place everything in a single plugin. It hasn’t solved the problem, but just moved it to one layer of abstraction. And you’re left with a top level system that can be extended, but beyond that you are on your own.

This results in the second level applications having an inconsistent structure, and some areas of the configuration not being grouped. For example, the Keyboard and Mouse configuration are at the top level, despite both clearly being configuration for input devices. What happens when you add Joystick calibration and touchpad interfaces? How about adding support for the scroll wheel? Or a trackpad? Do they sit alongside the Keyboard and the Mouse at the top level? Well, maybe they could but that would rapidly become a cluttered mess, surely?

Or if you look at the Internet configuration window you see that it’s entirely at odds with the rest of the configuration system. It looked like it was from RISC OS 3.7 (and it was) (and it even still had a hard “I’m going to call OS_Reset now, because I don’t care about your data” in it – it was bad). It had these strange little lights under each icon to turn them on and off, and then you could configure the individual areas by clicking on them. If you wanted to add support for configuring ShareFS discs, or other Internet services like the Resolver, OmniClient, or manage the IPX network system, you’d have to do that independantly in a separate plugin. It’s inconsistent, it’s a pain for developers and it means that extending it is a process that repeats the mistakes of the past (that of having to rebuild a single application with extra support).

It’s also worse than this because clearly there had been some understanding of the problem – the Boot configuration plugin had 4 functions (adding to the Resources FS, Installing into the Boot structure, booting applications on startup and running applications on startup). And these are actually implemented by separate applications, but interposed between them is a configuration plugin that just dispatches to those applications.

And thus was the CPIShell born. The Configure Plug In Shell (!CPIShell) abstracts the filer-like interface used by the !Configure as created by Acorn and allows it to be invoked for multiple levels. It allowed plugins to be created to allow different parts of the system to be configured through applications without having to mess with the whole. Additionally it supported invoking these plugins by name, so you could tell the top level !Configure that you wanted to configure Input.Keyboard (I can’t remember if that was the way it worked, but it’s something like that) and it would launch the main !Configure and the next level down and open the Keyboard configuration.

Doing this allowed much more flexibility. The second-level configuration tools could be expanded by 3rd parties or be have new functions added by the system. The CPIShell would apply rules for each plugin, beyond the original rules that were used by RISC OS 4, controlling how the plugin appeared:

• It could be faded if a variable was set or unset. Multiple variables could be used.
• It could be faded if a module was present or absent. Multiple modules could be used.
• It could be faded if a podule was present or absent.
• It could be faded if a file was present or absent.
• It could cause the plugin to be hidden (useful if a plugin which was used in an earlier OS version was moved elsewhere in the structure or no longer useful).
• It could be removed if the OS version didn’t match.

The CPIShell handled installation as well. Dropping a new plugin on to the application would install it into the correct place in the OS heirarchy.

So, under Select, there are multiple levels – generally only 2, but there could be more.

• Boot configuration became a CPIShell client, and the 4 applications became proper configure plugins.
• Discs was split up, so that users are only presented with a single place for the discs to appear and 3rd parties could add their configuration there. Disc checking configuration was added, making 5 plugins (ADFS, CDs, Disc check, RAM disc, and SCSI disc). The disc locking plugin should have moved in here, but it never got a lot of love and hadn’t been moved :-(
• Screen was separated so that Screensaver and the display configuration were separate. This was necessary anyhow, as Display configuration is a hardware setting, whilst the screensaver is a user configuration, so you want them to be managed differently. ViewFinder’s configuration could be added there as well.
• The Fonts configuration was sadly not replaced – it was made to look like CPIShell, but it isn’t.
• Keyboard and Mouse moved into Input, and were joined by the scroll wheel configuration.
• The network configuration was ripped apart. Each facet of the confgiruation was given a separate plugin and some where greyed out if they weren’t appropriate. In mine here, I’ve probably got more than most (don’t know how many of these were released?): AUN (for enabling and network mappings), Econet (greyed if no Econet module), Extra (other config to run on network startup), Firewall (configuration for the built in firewall), Hosts (editor for the Hosts file), Interfaces (configuration for each individual interface, and the autoconfiguration options), MimeMap (to edit the MimeMap file), NetFS (for more AUN/Econet fun), OmniClient (greyed if not present), Proxies (to configure the proxying routes and overrides), Resolver (for the network resolution configuration and host name, plus the DNS server enable option), Routing (for explicit routes), and ShareFS (just to enable – I’m sure we had a disc configuration in there too, but maybe that got lost).
• Sound became a group and the Internal sound system was provided in there, but also the configuration for the sound frequency tracking to improve sound quality.
• The Window configuration was separated out into 2 plugins – Icons (as there were a lot more options for the shape and function of icons) and Windows (which includes the special highlighting colours, the text selection and the many 3D effects), plus the configuration for the order that the tools will be displayed in.

The many different ways of configuring the system were made possible by the CPIShell. Instead of being daunted by having to either add an option to an ugly configuration tool, or forced to put it somewhere that it doesn’t quite fit, or just not bothering, a new plugin could be written and dropped into the right place. Because the plugins could be anything you could mix BASIC and C applications in the same section, rather than being forced to use a particular language of the thing you were alongside.

The CPIShell replacement for !Configure was created to help myself and others to be able to extend the configuration system. It addressed the class of problem, enabling more things to be done, and allowing others to be able to extend parts of the configuration system without having to have access to other sources or to patch things in odd ways.

There’s more information rambled about here: https://gerph.org/riscos/ramble/configuration.html

From the look of the RISC OS 5 desktop, you’ve still got the old RISC OS 4 way of doing things, albeit with different icons. The Network configuration dialogue actually looks almost identical to the RISC OS 3.7 one. I guess the same sorts of goals weren’t seen as important to the maintainers and developers of that system. That’s fine – I know that my views on how to make things modular, how to extend things, and provide functionality aren’t always what other people want.

So there’s a bit of the history of the RISC OS Select plugin system, what it was trying to achieve, how it worked, and the way it was utilised with new extensions. Regardless of that, though, if you’re wanting to make things work all the way back to the 3.1 systems, you’re going to have to build that technology yourself, regardless.

Otherwise, you know, I’ll get into something and before you know it it’s quarter past eight and dark outside…

I recall times when the issue wasn’t that it had gone dark outside, but rather that it had done that for a while and then got light again…

Plus, 8:15 meant there were just 45 minutes to get ready and get in to work

I think you’re talking about having a way to provide plugins within the main Configure, so that everything isn’t a flat structure, and you can provide small independant plugins to configure the different areas of your system without having everything at the top level. If that’s what you’re asking then… welcome to 2001.

Indeed! :)

The RISC OS 4 structure that was supplied for configuration was a reasonable step to make it possible to have an application that could function as a gateway to others tools, allowing 3rd parties to supply configurations for their components as necessary.

Indeed, I had a look at that, but the issue I have is I need to support multiple RISC OS releases, so:

a) need to work from 3.10 to 5 (and 6)
b) my code is all Open Source, and everything RO 4 sounds not on the right path, unless AAron or whoever owns the rights for that code is willing to open it. I just don’t want to rely on anything closed source that becomes another problem down the line.

It hasn’t solved the problem, but just moved it to one layer of abstraction. And you’re left with a top level system that can be extended, but beyond that you are on your own.

Noticed that too, so started to lay down my own design, but wanted to have a better idea of the issues encountered in the past, so your response is actualy very helpful thanks.

This results in the second level applications having an inconsistent structure, and some areas of the configuration not being grouped. For example, the Keyboard and Mouse configuration are at the top level, despite both clearly being configuration for input devices. What happens when you add Joystick calibration and touchpad interfaces? How about adding support for the scroll wheel? Or a trackpad? Do they sit alongside the Keyboard and the Mouse at the top level? Well, maybe they could but that would rapidly become a cluttered mess, surely?

Precisely my thoughts on all counts.

It looked like it was from RISC OS 3.7 (and it was) (and it even still had a hard “I’m going to call OS_Reset now, because I don’t care about your data” in it – it was bad).

Absolutely, not to mention other inconsistencies in the actual NIC configuration, I’d much prefer to have all the configuration field in one single form, so if I have forgotten a static gateway defined, I’d see it when I am changing the NIC configuration to DHCP etc. but that is just my personal opinion on usability.

That’s fine – I know that my views on how to make things modular, how to extend things, and provide functionality aren’t always what other people want.

Sure, but there are also people (like me) that instead consider modular and extensible code (especially on the matter of configuration plugins) very important, and I do share a lot of your view. Given the DME is mostly for myself and to be shared with who likes it, in all honesty I couldn’t care less about what ROOL/ROD or even God think it’s important to them (with all the respect for all the aforementioned) XD

Regardless of that, though, if you’re wanting to make things work all the way back to the 3.1 systems, you’re going to have to build that technology yourself, regardless.

I have figured that out myself, but thanks for the history, again still very helpful to avoid pifals already experienced. I’ll keep working on my own tool, I am pretty sure that, if done in a non disruptive way, ROOL will be interested in it, Steve R. and others keep talking about improving the situation and looking at the future, so some of the reality we are in is probably just lack of people being able to do things (aka scarse resourcing). I certainly have very little time for RO stuff, so it will take a while before it’s ready, apologies with everyone waiting for more DME tools to become available.

Thanks Gerph, always good to send thoughts your way man :)

rather that it had done that for a while and then got light again…

Back when I was younger my ADHD (and plenty of tea) would see me though the night like that. Sometimes multiple nights, though god only knows why, there was never anything so important in my life that it required two all-nighters in a row, other than the static in my brain meaning sleep just wasn’t going to happen.

But now? My A is still D but the H is a different sort of D – depleted.

I still have the static, but less. I only wake about five or six times in the night, and get up for a 3am walk around the fields maybe once or twice a week. And, of course, I feel like a zombie during the day, which just makes my A even more D. 😪

in all honesty I couldn’t care less about what ROOL/ROD or even God think it’s important to them (with all the respect for all the aforementioned) XD

The first two, certainly. The third, on the other hand…has a lot to answer for.