New bounties, additions?

I’ve taken some of the ideas from here and added some new ones; worth adding?

I think that in order to get on a bounty list the target needs to be achievable!

I have no interest in many of those and Some I see as a time consuming distraction (like all of the ones mentioning C).

I would put multiple monitor support at the top of the list and would contribute to the bounty.

There are four bounties underway. That’s probably most of the available developers beavering away right now…

There are two more bounties that have reached their target (“More recent LanManFS protocols” & “Update and debug USB stack”) patiently awaiting developer interest/availibility.

And there are five other open bounties, three of them quite recent (“Desktop wide Unicode support”, “Filing system improvements (step 3)” & “Revised Programmer’s Reference Manuals (step 1 of 2)”)

In all there’s about £30k that’s been raised towards the open Bounties, excluding those underway.

This all hints at a combination of lack of developers and donor fatigue to the extent that I’m really not sure the scheme could sustain the addition of seventeen more bounties in its current format.

Maybe there could be a user poll to see which one or two of those is worthy of adding?

Given the real problem is developer resource, is there any way of polling them to find out what they’re interested in? They could even name a price?!

There are four bounties underway.

Let say 3 because Andrew Ramsley mentioned that the “File system improvement” bounty is on hold for the foreseeable future as the developer is too busy with is real work.

That reminds me, I wonder if the same thing is happening to Jason Tribbeck and his SoundSystem API? I don’t think we heard of him this year.

I have no interest in many of those and Some I see as a time consuming distraction (like all of the ones mentioning C)

Those mentioning C not only future proof RISC OS against CPU architecture changes, but also make the code far more maintainable and far more likely have new features added. I don’t think anyone would dare try to significantly extend BASIC while its still in Sophie’s hand tuned assembler.

I don’t think anyone would dare try to significantly extend BASIC while its still in Sophie’s hand tuned assembler.

You only have to look at the number of unpleasant bugs that we’re still shaking out of the Wimp a year after selections were added to writeable icons to realise that it’s not that maintainable and extendable as a monolithic slab of assembler, either.

That’s not the developer’s fault, by the way — if you look at the Wimp code, a lot of it is extremely gnomic, intertwined and impenetrable. Changes have knock-on effects that are not obvious until they bite. In a higher-level language, that wouldn’t be such an issue because you wouldn’t have uncommented code that relied on the state of processor flags or values in unmarked registers for many lines in a row.

ETA: I went looking for a couple of the bugs that I found, and having read just some of the blocks of code, have great respect for anyone who can add functionality to it… not least with the small number of issues that there have been.

Those mentioning C not only future proof RISC OS against CPU architecture changes, but also make the code far more maintainable and far more likely have new features added. I don’t think anyone would dare try to significantly extend BASIC while its still in Sophie’s hand tuned assembler.

But how willing are we to make the switch? See Julie’s CObey module which re-implements the Obey module in C, its been more than a year that its sitting in a corner gathering dust.

See Julie’s CObey module which re-implements the Obey module in C

Yes, I wondered about that. Seemed like a very good idea – start with a few smaller components to convert. Is there a technical reason why this hasn’t ended up being merged yet?

There is a long history of important things not getting merged here. There is little understanding of how the process works, or who should do what.

As far as I’m concerned it’s ready to go in. There are some further commits to be considered once the ‘like-for-like’ is accepted. I submitted CShell in the meantime, which was accepted with some help.

Dave I do indeed have little understanding of the process or who should do what! From my point of view if you decide to write a module for the OS then you’re also the one that has to do the ‘pushing’. If we are serious about writing more on volunteer time, then I think it would be worth it to have someone dedicated to making sure things are going through, and finding out why not if not, someone who knows who to talk to etc. I wrote CObey ‘on spec’, i.e. I didn’t ask beforehand whether ROOL wanted it; that’s certainly not a good approach.

This sounds like the sort of thing that would be perfect for a non-technical volunteer as a role, a point of contact who

• Welcomes new volunteers, makes sure they can get a compiler, and points to helpful information, e.g. how to commit, what the coding standards are, how submission works.

• Knows what work is being done, by whom, and helps volunteers work out what to do

• Promotes submissions e.g. by announcing what is available for testing in the nightly ROM. (Paolo touched on this before I believe)

Of course, all of these are done by people in this forum from time to time, but I think if someone is named ‘volunteer co-ordinator/project manager’ they would feel they can be pushier about it.

I wrote CObey ‘on spec’, i.e. I didn’t ask beforehand whether ROOL wanted it; that’s certainly not a good approach.

I think doing things on spec should be fine – most contributors are working on stuff in their own time and for fun, so coming up with an idea that appeals and then submitting it is surely OK. The submission can always be rejected if it’s not suitable.

Unless there’s a specific hold-up, I’d guess that it’s simply slipped down the list of merge requests and isn’t on the reviewers’ radars. Given that ROOL are also doing this in their spare time and for free, maybe this forum is the best place to gently enquire if there’s any hold up? Or perhaps through GitLab, which would pop it to the top of the list for consideration?

In any case, I thought the project looked like a nice one, so I hope it gets merged at some stage :)

Things have quietened down and I cannot stay away. ;-)

BASIC (Interpeter, convert to C)

This is just silly:

• BASIC is legacy, so many things depend on it and quite enough use branches to machine code routines in the module to cause trouble. ¹
• You would not write a assembler in C to go in it – would you? – and a lot of programs use in-line assembled code ²
• The interpreter in C is a few times slower than assembler – cf Brandy ³

¹ I suppose you could fudge that somehow, but would you?
² You cannot substitute pre-assembled code, because legacy.
³ This is less a problem, because speed may not be important.

If you want a BBC BASIC look-alike you could adopt Brandy or maybe ask Richard Russell about compiling his SDL version. If we are really looking for ‘the new BASIC’ I would suggest using Python or Lua.

Things have quietened down and I cannot stay away. ;-)

Comedy line: “Perhaps I can help?”
Serious: Do continue.

speed may not be important.

I think that speed should always be a consideration. Not the only consideration, but a significant one.
When you take too little note of the speed issue, you start down the track that Windows gouged: “We need a faster processor”

Speed is always nice, but the current generation of machines are at least 10x faster than the class of machine the majority of the RISC OS software was written on and for, so it’s not going to stop anything working. I think we could manage with a slightly slower C BASIC on 1.5 GHz Pi4B, it will still be faster than assembler BASIC on any of the older Pi’s, never mind an Iyonix or Risc PC.

Also any portable C version will be many times faster on a 64 bit only chip than emulating 32 bit assembler BASIC.

This is just silly:

and pointless in my opinion. My Raspberry Pi BASIC V will still be around long after somebody has taken all most the bugs out of a new version in C.

Also any portable C version will be many times faster on a 64 bit only chip than emulating 32 bit assembler BASIC.

And be incompatible with much legacy software. If you you want that use Brandy, extend it as with Matrix Brandy, and have done with the discussion.

I have to clarify when I propose re-writing things in C, I don’t really mean C, I mean C++. C is a glorified macro assembler with less facilities in some cases than BASIC, it has horrible fixed length buffers for strings, no built in collections, and memory handling is entirely manual, i.e. a bug magnet. I’d much rather things were written in C++ with STL (which means using gcc) so that strings are proper objects, and there is access to collections such as lists and variable length arrays, and memory management can be done on a RAII basis – which means less bugs. I do get very annoyed with syntax of C++ and find a lot of the languages facilities confusing and unnecessary, if it were available for RISC OS C# would be a much better choice, as it has all the advantages I’ve mentioned plus managed memory, but a much cleaner and more consistent syntax.

So as not to stray off topic, can we consider changing the references to “C Conversion” to “C/C++ Conversion”.

And be incompatible with much legacy software. If you you want that use Brandy, extend it as with Matrix Brandy, and have done with the discussion.

Nevertheless a future 64-bit-only RISC OS would need a built-in 64-bit BASIC which is code compatable with the current BASIC, i.e runs everything written in BASIC. In my view supporting things that call into the BASIC interpreter might be desirable, but should not be a design goal.

Aside from that I find myself wondering whether a 64-bit BASIC, written in C, could run in a 64-bit core of a modern processor, supporting a 32-bit RISC OS running on a different core – and would there be any advantage in doing it?

> C++ with STL (which means using GPL)

If that is true then it is only true when using GCC. The Clang C++ runtime library is, off the top, BSD licenced.

@Julie

From a quick glance at the CObey MR (https://gitlab.riscosopen.org/RiscOS/Sources/Programmer/Obey/-/merge_requests/1) it seems there is one issue that has not been closed. Although I see from the commit message that you resolved the issue.

So I would assume that the reason it’s not been merged, or being looked at is because of the supposed outstanding issue. Whether you can close the issue, or it needs the originator to do so, I am unsure.

That reminds me, I wonder if the same thing is happening to Jason Tribbeck and his SoundSystem API? I don’t think we heard of him this year.

@Andre
Work on the new audio architecture seems to be progressing. The latest build by Jason is dated 1 Nov 2021. You view and download it here

C++ with STL (which means using GPL)

If that is true then it is only true when using GCC. The Clang C++ runtime library is, off the top, BSD licenced.

Sorry didn’t mean GPL at all, meant gcc.

There is no licencing problem, its just a small issue of changing the RISC OS tool chain from Norcroft to gcc, as Norcroft doesn’t have C++.
(CFront from 1989 does not count)

Thanks Alan, I’ve closed it. In fact anyone logged in can resolve it — who is meant to I’ve never been sure. I’ll start a new thread.

Wasn’t the main problem the with issue the IOMD ROM overflowing when Obey is replaced with CObey?