Providing fixes for RISC OS source code - how to do?

I’m currently working on a project (I don’t want to say what it is until it progresses further, as din’t want to risk the whole vapourware thing!). However, I have a question:

Is there a way to discuss possible fixes / updates for the RISC OS source code? I know we have the ‘Code Review’ forum, and the git repository, but assume git is locked (otherwise too many cooks spoil the broth!), and don’t want to spam ‘Code Review’ with lots of small fixes, or discussions of possible extensions to the code?

As an example, I currently use a modified version of BBC BASIC, which has a number of additional options added; a particularly useful option is that I can set the assembler so that, upon encountering a negative immediate operand, it automatically checks whether the operand can be negated or inverted, and if so, it can switch ADD to SUB, MOV to MVN or vice versa, automatically negate (or invert) the immediate operand, and assemble the instruction; this is particularly in assembly code that uses a workspace pointer that has offsets above and below the pointer, especially when changing stuff that results in offsets changing sign between compilations!

I have also fixed a bug I found in the assembler code.

Anyway, is there a generally agreed way to go about discussing the above for consideration re: RISC OS source code? Given I have a good few useful additions / fixes, but many are not closely related, and would spam the ‘Code Review’ forum if I posted each one there?

Hi Tymaja,

Fixing a bug in the assembler sounds like a great place to start. Please e-mail code@riscosopen.org asking for an account on the GitLab (see here). You’ll then be able (after it’s set up) to make your merge request. You could also then if you wanted put up your BASIC with extra options as a personal project for people to see.

Deffo email ROOL to get yourself an account on their GitLab instance. That’s the simplest way to be able to easily clone and edit the code. You can then write-up a merge request with your changes.

Looking at the current pile of merge requests, I wonder if some of them need assistance. The descriptions are not always clear (background info, reasonings etc.) and it would make it much easier for people to test out if the component in question also had a build provided (not always feasible, I know).

I guess you could do without the ROOL account, and just work in your local git. And even push the changes elsewhere, like GitHub. But it seems that the preferred way to get something to become part of the OS is to create a merge request on ROOL’s GitLab. Makes sense, really.

Thank you for the advice – have done this just now :)

My current method of working on the RISC OS source code is …

1. Have the source code on a MacBook Pro 17” 2011 with working ATI graphics (most of them died years ago)
2. Raspberry Pi 5 connected via Ethernet, headless, VNCserver
3. Raspberry Pi 4 connected via Ethernet, running RISC OS
3. Put VNC fullscreen
4. Load up the ARMv4 ARMARM, and the ARMv8 one, also fullscreen

I end up with:

- a desktop (Mac) with : PRMs, BASIC reference manual, and RISC OS source code
- VNC screens from the Pi4 and Pi5
- ARMARMs x 3 (two copies of ARMv8 so one stays in Aarch32v8, the other in Aarch64v8;

The BASIC ‘port’ I am doing, and the VDU drivers, have all been done by reading code files on the Mac, then typing code into the Pi5 … No copy and paste at all 😳. It is definitely a good way to learn how it all works :)

The small amount of stuff I’ve done (USBJoystick) has all been 100% RISC OS native: StrongEd and the DDE. It’s not terribly productive, as I am much more used to working with Visual Studio or the Chrome Dev Tools. I really must investigate how to get a modern editor going on macOS which could also attempt to build the code: even some basic intelli-sense/LSP would be helpful, if not a full build to run on RISC OS Pi.

Or is anyone looking to port a modern editor which can talk to an LSP? I was wondering if extending StrongEd would be possible, then stopped when I realised it was written in assembly language!

I tended to use Xcode on the Mac, with swis.h and a couple of other headers transplanted from the DDE. The Xcode compiler would catch most errors and give suggestions for them, and for the stuff that was plain C (not using any RISC OS-specific functionality) it was easy to test things.

I’ve used past tense because, as those following SQLite will have noticed, I’ve not done anything useful in more than a year at this point… :(