My News and Updates for RISC OS Southwest Show 2024 - Sat February 24th
Paolo Fabio Zaino (28) 1865 posts |
To everyone interested, - (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! :) |
Paolo Fabio Zaino (28) 1865 posts |
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! |
Rick Murray (539) 13811 posts |
Don’t feel bad. We’re like, what, for dark mode capable versions of Android on and it still has problems. |
David Gee (1833) 268 posts |
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. |
David J. Ruck (33) 1630 posts |
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! |
Steve Pampling (1551) 8163 posts |
I used to have that problem, then I had my cataracts removed. |
Rick Murray (539) 13811 posts |
My newer phones run in dark mode all the time. With RISC OS, my normal view of it is Zap, which is colourised code on black. |
Paolo Fabio Zaino (28) 1865 posts |
Thanks Rick and David, @ Druck
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 |
Frank de Bruijn (160) 228 posts |
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. |
Paolo Fabio Zaino (28) 1865 posts |
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). |
Frank de Bruijn (160) 228 posts |
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… |
Rick Murray (539) 13811 posts |
Hey, if we’re posting desktop screenshots, here’s mine. ;) https://heyrick.eu/blog/files/mydesktop20240225.jpeg |
GavinWraith (26) 1563 posts |
Don’t tell me zombies count as light! |
John Rickman (71) 645 posts |
That is quite dark |
Simon Willcocks (1499) 509 posts |
Couldn’t you just reduce the brightness of the screen? What’s the difference? |
Paolo Fabio Zaino (28) 1865 posts |
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. - 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. 1 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. |
Paul Sprangers (346) 524 posts |
Creepy… but I’m curious about the ‘cup of tea’ icon… |
Stuart Swales (8827) 1350 posts |
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. |
Rick Murray (539) 13811 posts |
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… |
Stuart Swales (8827) 1350 posts |
Cold T? ∃ microwave oven. ;-) |
Rick Murray (539) 13811 posts |
Ewwwwwwwww!!!!!! (can’t you taste the difference?) |
Charles Ferguson (8243) 427 posts |
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:
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.
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. |
Steve Pampling (1551) 8163 posts |
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 |
Paolo Fabio Zaino (28) 1865 posts |
Indeed! :)
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)
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.
Precisely my thoughts on all counts.
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.
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
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 :) |
Rick Murray (539) 13811 posts |
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. 😪
The first two, certainly. The third, on the other hand…has a lot to answer for. |