Spending a Million on RISC OS

David F, There are instructions for installing GCCSDK, and a mailing list for getting assistance.
Configure is called with ‘ro-config’. Using linux configure and modifying the make file would not work well with a configure that modifies more files than just the makefile, which happens often enough. It is possible to move the configured sources to RISC OS for !GCC as long as reconfiguring doesn’t need to take place during ‘Making’.

http://www.riscos.info/index.php/Using_GCCSDK

Just out of interest, why do people want to use threads on RISC OS?

Correct me if I am wrong – but isn’t a thread basically an application that splits itself into two (or more?) interrelated applications – specifically it can behave as if it had multiple applications running, yet they would share the memory (including variables, etc) of the original application?

Mmm… How would such a thing be supported within the Wimp? Multiple initialisations and multiple polling loops? I can imagine this could get messy in a hurry.

Why? The only example that comes to mind is a media player that uses separate threads for, say, audio and video decoding, so both can concentrate on their task while running side by side.

That said, the POSIX model provides threads as standard so if we’re trying to port something that doesn’t offer threads, we’ve already hit a wall.

The problem here is that there’s almost certainly going to be a big difference between the real value of these assets – by whatever methodology we select – and the views held by the current owners,

I was thinking about this at work and I wonder… because while it would be nice to drop a load of cash into getting the two branches united; there surely comes a point where one wonders if it wouldn’t be less bother to find some coders to implement the bits that are liked, and then just pretend that the obsolete version no longer exists.

Personally, I believe we should Open Source the lot,

Apart from the two criteria:

• No non-ARM port (but good luck if you want to rewrite the Wimp in x86 or something!)
• Non-commercial without a licence from Castle

it is all but open source. Certainly, if you are happy with ARM (which is a niggling thing since it is an OS written in huge chunks of ARM code, so…) and you don’t plan any commercial usage, there shouldn’t be anything to get stressed over. Okay, yeah, Castle is horrible and they are stealing people’s IP and flogging it off as their own product, can’t you see the queues of people lining up to buy RISC OS… <cough> meanwhile in reality…

In reality, if you are interested in further developing RISC OS and helping the community, then your benefits will be seen and appreciated regardless of whether or not Castle can sell it. After all, thanks to them, RISC OS is available to us now (and for free). If this small tweak to the otherwise open licence is what they ask in return, well, arguing it would be churlish.

maximise the chances of RISC OS growing in a way that allows the emergence of an actual, sustainable market around it.

That would be nice, but markets have developed around proprietary products in the past – the operating system IS. The existence of the source is only relevant if you’re the sort of person that wants to go dive in. A market can exist regardless, so long as the OS offers something to justify the market.

It’s a harder call these days. Back when, software carried monetary value. These days, everybody wants something good for free. There is quite a lot available, and if some group makes a bad decision, count to ten and download the alternative fork. ;-)
The problem, therefore, is the perceived value of software. Who is going to want to pay ££ for a word processor when you can get an entire office suite for zero? This mentality (and the lack of understanding where exactly software comes from, it isn’t nuggets dug up in the back garden) will make the emergence of a market harder.
So I feel we’re back to the question I posed a while back. What is RISC OS’s strength? How can we maximise this?

RO4/6 isn’t particularly relevant to this, IMO

There, fixed that for you.

It was, once. It isn’t, now.

but I do wonder whether the current Shared Source arrangement is holding things back

If RISC OS becomes proper open source, it will need to be either bsd or CDDL or the like (due to the mixed licences). I’m going to put a ten euro note on the table. My ten euro note says that an Open Source (capital O, capital S – OSI friendly) RISC OS will be the wrong sort of Open Source. Immediately those “who would have contributed” will complain that it isn’t the “right sort of Open Source”. And, oh look, we’ll be right back where we started.

Why? The only example that comes to mind is a media player that uses separate threads for, say, audio and video decoding, so both can concentrate on their task while running side by side.

I read somewhere this is taken a step further when using dual core processors, audio in one core, video in the other.

Rick:

I was thinking about this at work and I wonder… because while it would be nice to drop a load of cash into getting the two branches united; there surely comes a point where one wonders if it wouldn’t be less bother to find some coders to implement the bits that are liked, and then just pretend that the obsolete version no longer exists.

Isn’t that the traditional development model for each branch of RISC OS? Pretend that the other one doesn’t exist? ;)

Personally, I believe we should Open Source the lot,

Apart from the two criteria:

No non-ARM port (but good luck if you want to rewrite the Wimp in x86 or something!) Non-commercial without a licence from Castle

I thought fewer restrictions was the popular consensus around here! The first of those is an arbitrary technical one. The second is a potential roadblock for all sorts of activities: is selling CDs/DVDs at RISC OS events a commercial activity?

The problem, therefore, is the perceived value of software. Who is going to want to pay ££ for a word processor when you can get an entire office suite for zero? This mentality (and the lack of understanding where exactly software comes from, it isn’t nuggets dug up in the back garden) will make the emergence of a market harder.

People pay for support, feature improvements, updates, at least in theory.

Just out of interest, why do people want to use threads on RISC OS?

Correct me if I am wrong – but isn’t a thread basically an application that splits itself into two (or more?) interrelated applications – specifically it can behave as if it had multiple applications running, yet they would share the memory (including variables, etc) of the original application?

You’re about halfway there. Threads aren’t just a thing that are used by applications. The kernel, hardware drivers, utility libraries, etc. can all use threads for a variety of purposes.

Mmm… How would such a thing be supported within the Wimp? Multiple initialisations and multiple polling loops? I can imagine this could get messy in a hurry.

The traditional way other OS’s handle multithreaded applications is to limit it so that most (or all) of the interaction between the application and the windowing system is limited to one thread within that application.

Why? The only example that comes to mind is a media player that uses separate threads for, say, audio and video decoding, so both can concentrate on their task while running side by side.

Threads are also good candidates for lengthy activities like loading/saving large files, complex image processing in an image editor, fetching data from the internet, etc.

Obviously, threads aren’t the only way of implementing these things in a non-blocking manner. E.g. when hardware is involved you’re usually given the option of letting the driver perform the task in a non-blocking manner, leaving the application to either poll for completion or (more preferably) receive a callback. If you split your task up into chunks and implement a state machine based around those callbacks or polling points then that will allow your code to respond as soon as it has some work to do and then yield whenever it has to wait for the slow hardware. Or for something like image processing you can generally split it up and process N rows of the image at a time.

However the problem is that implementing such systems often isn’t as easy as just using threads. You have to decide when to yield, you have to save all your state to memory (since the stack + registers will be lost), you might have to re-architect large parts of code just to add a new yield point, and if you want to call some lengthy code which doesn’t offer callbacks/polling then you’re screwed. Plus your code will be limited to running on one core at a time.

For a view on how RISC OS is perceived in the real world Linux User has included RISC OS in a ‘Top 4 Raspberry Pi OS’ article

Linux User has included RISC OS in a ‘Top 4 Raspberry Pi OS’ article

Is it me or do they appear to have a lack of understanding of the use of various things?

Using RISC is different from other operating systems as it uses a three-button system for clicking and opening menus, unlike the two-button standard of today. This can be confusing for new users,

Right, so the reviewer never uses more than two buttons on their Linux distro.

along with the way apps open on the desktop and the way they don’t always require double-clicks to launch.

Key/mouse bounce on a Pi with a crappy PSU? Because my Apps all seem to need double click to launch, a single click on a loaded apps iconbar icon could be their issue, but then that just shows they haven’t read the documentation in the release, which for someone doing a review is criminal negligence.

When it is in a fullscreen window, it covers the panel and a whole host of other quirks.

Simple click in the window configuration settings – which I might say the review seems to have in non-default (it isn’t that way on my setup and I don’t recall changing it)

If you’re used to the traditional desktop metaphor there are a lot of new workflow processes to get your head around for something you’re unlikely to use as your main computer.

“Traditional desktop metaphor”? So exactly what is traditional about the Linux desktop if you’re used to industry standard¹ behaviour?

“new worflow processes” – amazing, despite starting that same paragraph with “While RISC OS is not Linux” they complain that it doesn’t behave like Linux.
I’ve worked in a newspaper editorial office² so I know that not all journalists are braindead but you do wonder at the percentage that don’t seem to be able to hold a thought process for any period.

Things have changed in the 18 months since we first checked out RISC OS on Pi, but it’s either not enough or it’s just never going to go in the direction of Raspbian

People round here aren’t working hard enough :) but he’s right it’s just never going to go in the direction of Rasbian

¹ Windows is of course innustry stannit
² I was but a youth seeking part time employment to fund youthful essentials – beer, concerts, records, electronic bit, more beer…

Oh, yes, forgot:

RISC OS is a very different operating system to the others on this test, which isn’t a bad thing but it is not conducive to education

So, education is about repeating the same rather than learning new or different. Encouraging thinking is clearly a bad idea.

Hmm… What I took away from that article is “everything is compared against Raspian”.

To paraphrase:

• Pidora? It’s a lot better than it was. But it ain’t Raspian.
• RISC OS? What the effing eff is this? It really ain’t Raspian.
• Arch Linux. It’s good, it’s fast. I’ll grudgingly suggest that it might do some things better than Raspbian but my recommendation will be “most users won’t notice much difference”.
• Raspian! Whee! Box of Kleenex at the ready!

So… Yeah… Biased much?

More specifically – “struggling to get any screenshots off the SD card”. This is actually a problem that I face, though I have David Pilling’s DPScan on Windows which understands RISC OS sprites. Perhaps I ought to write a little BMP convertor program? Everything and its donkey can read BMPs, and for straight sprites it is dead easy – flip the direction (BMPs go the other way up) and fudge the pixel data as necessary. Other than that, they’re much the same thing.

“This can be confusing for new users, along with the way apps open on the desktop and the way they don’t always require double-clicks to launch.” I can only imagine he is talking about the difference between running an application from the filing system, and then dealing with it once it is on the icon bar. This is, I think, something that tutorials should make extremely clear. When an application is on the iconbar, it has been started, it is ready, but RISC OS apps don’t have the obnoxious behaviour of requiring some sort of open window on the screen. In this day and age, the RISC OS user guide of old is no longer much good. When I used to do internet at the local library, I was sitting beside a very young girl who refused to let her mother take her away for a nappy change because she was using the computer. Not proficient in bladder control but already quite proficient in using a mouse and could find most things on the keyboard (but wasn’t so good at that part yet). What blew me away was that she didn’t have too much trouble with Google and Wikipedia for looking up and following links to details of what I presume is her favourite cartoon. So, really, explaining what a mouse is is a bit patronising in 2015. Our goal now is more “Windows (etc) does it like this, we do it like this” (and along the way, try to point out why this is a good idea without being too critical or snooty of other systems). The RISC OS UI is quite ancient looking, but it still provides numerous features that other systems either cannot do, or do with difficulty.

“When it is in a fullscreen window, it covers the panel and a whole host of other quirks.” – here again, “when the window is maximised, it covers the task bar/system tray”. Yes, without configuring RISC OS otherwise, it does. Why? Simple, why waste a band along the bottom of the screen when you have that much more space to deal with the job that you want to do? Unfortunately, I can imagine the author shrunk down the window and moved it. Because not only would it probably not occur to him that you can resize a maximised window, but it certainly wouldn’t occur to him that moving the pointer to the bottom of the screen for a second would pop the “panel” to the front. Or Shift-F12.

“You can access the GPIO port but it’s not very well suited for all projects” – I think what this boils down to is that our GPIO access is “complicated”. You can’t go to BASIC and say GPIO.SetState(blah, 1), or whatever it is in the modern trendy scripting stuff. And here, sadly, yet again Lua (which might be a good candidate for easier GPIO access?) was not even noticed.

“but it’s either not enough or it’s just never going to go in the direction of Raspbian” – and here we finally reach the truth. The “I don’t really understand this because it isn’t Raspbian” part.

<rant>

Well, you know what? I don’t much like Raspian. Or most other Linuxes. They look and feel like quirky Windows knock-offs but god help you if you need to configure them in some way that isn’t supported out of the box, or plug in some esoteric bit of hardware and expect it to work. The filesystem is a relic from a bygone age where the filenames are case sensitive (WTF? is this 1970?) and the command line is a blend of raw power and batpoop-crazy, with quirky command line syntax designed to bug the hell out of anybody. For example, the increasing trend of programs to prefix multi-character command line options with two dashes because the people who wrote the command line parser in the olden days were obviously a bit crap at it.
For Pidora I see this: “a lot of basic or useful yet obscure packages available for Raspbian just aren’t in the repository”. So, what, Pidora and Raspian are versions of Linux, but there’s evidently no binary compatibility to allow packages from one distro to work with another distro? Seriously? So applications must either be distributed as source (and built on the end user machine) or have a repository duplicating the efforts of other repositories. Seriously? I could perhaps (perhaps) understand if this was entirely different architectures (like ARMv6 vs ARMv7) , but it is for the exact same piece of hardware.
It might do for Linux, in general, to look at Windows and realise that broadly speaking the operating system is backwardly compatible and largely processor agnostic. My netbook is a little Intel Atom, my video decoder detects what sort of extensions (MMX, etc; GPU, etc) are available and uses them. The old NAS box is XP again, with the same basic set of programs. It’s an AMD processor. The machine I used to use prior is a slow old Celeron. The boot sale computer that I am slowly setting up is a Pentium4. The same base set of software will run on the machine. Because while nerds might pledge allegiance to a flavour of Linux or the politics behind it (hello GNOME!), the average end user just wants the damn software to install and run. It is not about the operating system, it is about the applications that you can run on them. It is possible to run OpenOffice (or whatever the politically favoured fork is this week) on many different systems. And, you know what? The only real distinguishing features should be “does this OS work well with my printer?” and “does it start up quickly?” and “is it friendly to use?”. Windows, Debian, Ubuntu… doesn’t actually make that much difference if the software that is wanted loads and works. So to be here, in 2015, reading stuff like "but a lot of basic or useful yet obscure packages available for Raspbian just aren’t in the repository’ is mind-blowing for all the wrong reasons.

</rant>

“but a lot of basic or useful yet obscure packages available for Raspbian just aren’t in the repository”

Can’t help wondering how many of the 36899 ¹ hits for “Package:” in the Raspbian package list are command line items that would work and could have a FrontEnd module shell bolted on.
Of course people would have to suffer a large dose of GPL in the packages.

¹ I wonder how many of these are the same thing in different clothes? I mean, really? 36900 entirely unique applications with no commonality? Or are we talking the software equivalent of 300 TV channels all with the same sort of dross which slims down to 2-3 hours of decent viewing a week?

However the problem is that implementing such systems often isn’t as easy as just using threads.

Especially since there is almost no facilities for this. It should be possible from Basic to tell “call this proc when event xxx is received” (for example a ‘ding’ from a timer, for an “every” command). Event management is still complex in Basic or C. Callbacks are complex in C, almost impossible in Basic.

If I had money, my first bounty (not too late to add this one on your list) would be a Rosetta code for RISC OS. solutions in C and Basic for common problems: open a window and plot inside it; launch proc every xxx seconds; make HTTP call and get answer in an array; use FPA code from Basic; create a screensaver; create a Basic Wimp application; create and manage a task in a Task Window, etc.

Hundred of example could be useful. But the most important today is an Internet kit to ease the development of apps that can access to web services from C or Basic (including template code for basic Wimp applications).

In a way, that’s what I try to achieve with the RISC OS FR BBC Basic contest: “give us your code, we’ll find a way to use it” (and tou can win a Pi too :) )

It should be possible from Basic to tell “call this proc when event xxx is received” (for example a ‘ding’ from a timer, for an “every” command). Event management is still complex in Basic or C. Callbacks are complex in C, almost impossible in Basic.

Hmm! No comment on C, but event management in BASIC has a long history. Let’s be certain first whether you are thinking of Wimp programs or single-tasking.

If you are thinking of single-tasking, then there is no easy way except setting up a loop to check the state – you cannot respond to interupts, for instance.

For the Wimp we use a poll loop and decode it with CASE structures – not elegant, but there a thousands of variants on it. If you want ‘after’ or ‘every’ you use Null events with poll idle. True, setting up the data structure to control multiple timed events is not for the beginner, but it is quite feasible and there are examples out there. Maybe this is the sort of Rosetta code you are thinking of.

For myself, I created easy Wimp/Toolbox/Message event handling in Basalt a long time ago and removed the need for CASE structures. More recently, I wrote a Call module that uses the OS CallAfter and CallEvery to send a task a timed message event and is simple to use from Basalt.

use FPA code from Basic

That is what BASIC VI is for, surely.

I applaud your efforts, but I cannot get a focus on your aims. Perhaps today there are so few active developers that the environment I learned everything in does not exist: there were several magazines with example code; there were multiple magazine and library discs with applications to pull apart and examine; there was a very active newsgroup with dozens of posts a day on all sorts of topics.

aaaaa

If you want ‘after’ or ‘every’ you use Null events with poll idle.

With HAL timers available, it’s a pity :)

Maybe this is the sort of Rosetta code you are thinking of.

Yep, but not only. Also examples on how to use new features.

For myself, I created easy Wimp/Toolbox/Message event handling in Basalt a long time ago and removed the need for CASE structures. More recently, I wrote a Call module that uses the OS CallAfter and CallEvery to send a task a timed message event and is simple to use from Basalt.

Good work.

With HAL timers available, it’s a pity :)

What would you do with HAL timers? A Wimp program marches to a centisecond beat and if it is not paged in it can do nothing.

A call fired from the timer would be better than to poll, IMHO. In my Basic programs, I loose a lot of time… just waiting the right time to do something. ‘Wait’ or ‘Every’ could be useful. Loops and other tricks are just, hum, tricks. I did use a lot timers in Locomotive Basic. Really fun.

‘Wait’ and ‘Every’ commands just need a ’don’t come back before xxx cs’ SWI: aka, an option for WIMP Poll. Then, you can check the NULL event without killing the Wimp, since it’s always the right time to do it. Could be very useful for games and animations. And cool for all the Wimp too.

Of course, it’s always the same idea behind: to get a more efficient CMT system. IMHO, it’s important to give a limit in time for tasks (a la Wimp2, when possible), but also important not to call a task if it’s not yet the time (of course if there is no events). Do !Alarm need to be called more than once a second? No. Is it possible to limit the execution time of !Calc (and so to preempt it)? Yes.

It’s not PMT, but a more ‘optimised CMT’. I think it’s a goal more easy to reach. Time limit will make the Wimp become more fluid, even if it will work only with a limited set of applications (aka: applications PMT compliant and a few others, as with Wimp2). A timed poll will solve the problem of CPU cycle used for nothing when you just want to wait xxx (‘Wait’) or wait xxx before repeating an action (‘Every’).

Of course, there is probably better ways to do all of this. Perhaps it’s just a documentation issue :)

Wimp_PollIdle?

Wimp_PollIdle?

Yes… more simple, but yes.

Classic Basic software (graphics, input, output) should be able to work directly in a CLI window, with tricks as Wait command (mapped to Wimp_PollIdle).

Nota: some templates could be enough to achieve all of this…
Or perhaps we really need a Wimp version of BBC Basic :)

Wimp_PollIdle?

I never made desktop applications (I’m from the Unix world, with only ANSI C knowledge…), but now that I look at the documentation, I’m surprised that Wimp_PollIdle is not the default way to poll (is there any non-null reason for this choice?). ‘Give me back the control as soon as I get an event, but not for the Null_Reason one, where a minimum delay applies.’ That’s perfect.

I’m surprised that Wimp_PollIdle is not the default way to poll (is there any non-null reason for this choice?)

You’d use Wimp_PollIdle if you were only doing anything when an external event occurred (user interaction, say). If you need to do some processing that takes time, you have to use Wimp_Poll so that you get null events, and can time-slice your processing so as not to hog the CPU.

I’m surprised that Wimp_PollIdle is not the default way to poll

For tasks that don’t do background processing, and therefore don’t need null events, you use Wimp_Poll with the null event masked out completely. That probably covers the vast majority of cases.

You only need Wimp_PollIdle if you need to get null events at intervals. Aside from the odd cases where you take a single null event and then mask them straight back out again (such as to find the end of some data transfer processes), you probably shouldn’t be unmasking null events unless you’re using Wimp_PollIdle.

Classic Basic software (graphics, input, output) should be able to work directly in a CLI window

Do you mean a Command window or a Task window. Not the former, I hope. If the latter, then you need druck’s GraphTask.

perhaps we really need a Wimp version of BBC Basic :)

That would be WimpBasic then. Not really a current option, though.

You can do a lot with a good library or you can do it quicker with a version of Toolbox BASIC I just happen to know about. ;-)