Any plans to have an open source toolchain to build RISC OS?

Developing things for RISC OS is like working on a building site with no electricity or running water, having arrived on a bicycle.

You mean that’s not fun for you? I’d liken it more to working in a mine field, given the inherent risk you take in doing so many things.

Developing things for RISC OS is like

What you’re missing is that RISC OS is kind of a retro platform. Therefore using a third party text editor to write code to pass to command line utilities to build an executable either via typed in commands or magic incantations in makefiles (but don’t use that make, use this one), and pretty much sod all in the way of useful debugging… it’s all part of the retro charm.

working on a building site with no electricity or running water,

My first job, back in the dark ages, right out of school, was doing “builders cleans”. That is, cleaning new build houses from all the crap that builders leave behind.
You wouldn’t believe how many times we were pointed to a building with no electricity or running water.
You also wouldn’t believe how many times builders took a dump in a toilet before it had been connected to anything.
[I have a dim view of builders, as you might imagine]

having arrived on a bicycle.

Ecologically friendly…

Meanwhile other platforms

I will admit that variable completion for structures is pretty useful. However it’s usefulness is tarnished when it does stupid things like “if you press Shift by accident and capitalise a letter, it will retroactively rename all instances with that capital in place, and refuse to undo it because it prefers to accept your replacement lower case letter and promote it to the capital it thinks you wanted” or “these lines are long, let’s reformat them in a way that is utterly broken” or “you can change the colours of things but not everything and if you think you can change the bold and italics, think again”.
Hello Visual Studio circa 2000, I’m looking at you.
As for Eclipse, I could flipping well write Arthur from scratch in less time than it took that to load.

But sometimes you can be a lot more productive with an electric pillar drill than a hand drill.

And sometimes the exact opposite is true, as anybody who has ever used a hand blender to beat eggs will have discovered. Whisk them, but not too much.

temptation is to go over there where you can get more done with less hassle.

Funny. I came back to RISC OS. It was dead easy to do stuff with Visual Basic (I mean the real one, not the .Net imposter). Design a form, whack in some code for events, it’s like what DeskLib should have been. Make a functional program that actually does stuff in a single afternoon? Check.

But the moment you wanted to step outside the box? Oh boy. The API is extremely well detailed in the MSCD (is that the acronym? I forget) and it is obviously designed by drunken monkeys. There’s a world of pain in doing simple stuff. In realising that GDI and GDI+ are barely compatible with each other. And even though the likes of XP are UTF16, try telling that to VB which is UTF16 internally yet for some asinine reason uses only the eight bit ANSI API. I did manage to get a window to display Japanese (song titles for an online radio station) but it took weeks to figure it out and was never released as it was randomly crashy. And that’s only the joy of user space application code.

RISC OS has limitations, but at the same time you don’t spend ages arguing with the OS. Could I get the desktop to display song titles in Japanese? Not natively, no. Could I do it? Yes, I think so. Handle the window redraws myself, plot Cyberbit glyphs into the window, job done. It’s a bit of a cheat but if it works…

To each their own.

I’d liken it more to working in a mine field

Looks like a troll who is about to get his account deleted.

You also wouldn’t believe how many times builders took a dump in a toilet before it had been connected to anything.

Our building officially opened in about September last year, and still has no toilet paper holder in the nearest toilet to my office.

It’s somewhat like working in a minefield in that if you trip up there is a chance you will take your leg off. Things have improved greatly over the years, but it’s still fairly easy to take the machine out.

The flip side of that is you have a lot of flexibility to do what you want.

“With great power comes great responsibility” as they say.

Unrelated – having dealt with two sets of builders at the house my view of them is probably similar or worse than Ricks!

it’s still fairly easy to take the machine out.

True, it’s extremely easy to take the machine out (any stack imbalance or accidentally corrupted register in hand written module level assembler will do it ¹), but then if you know what you’re doing (cough!) you have a lot of flexibility and don’t have to worry about the system nannying you, arguing, or just flat out refusing to let you do something “because”.

“With great power comes great responsibility” as they say.

Indeed. One doesn’t pull out the safety pin, squeeze the handle, and then stand there saying “hey guys, what happens next?”.

Looks like a troll who is about to get his account deleted.

One post. Clearly not been around long enough to appreciate why things are the way things are. Yes, it will crash and burn if you so much as blink when staring down a ServiceCall handler, but if you are familiar with the BBC Micro and passed by way of Arthur, a lot of the hows and whyfores are a logical progression.
Indeed, anybody that has difficulty with quirks of RISC OS at an API level really ought to spend an evening browsing through the BBC Micro Advanced User Guide. The eccentric VDU system, the chaos of OS_Byte, the mess that is the keyboard handler, ServiceCalls, and indeed the idea of modules will all make a lot more sense if one is more familiar with the origins.
That, of course, doesn’t make the system less likely to strenuously object to your errors, but at least you’ll better understand why you don’t get coddled when you’re playing with fire, and why some stuff is the way it is.

¹ This is why I’m an advocate of using C for modules. In 2020 I don’t expect to have to keep track of every single register and stack push and pull myself. Our species invented compilers to alleviate us from the low level grunt work…

and still has no toilet paper holder in the nearest toilet to my office.

Shocking.

If that was me doing the reapprovisionnement (and yes, stocking toilet paper is one of my many tasks), I would fire myself.

Missing a day, not good but acceptable. Sometimes stuff happens that’s more urgent.

Missing over half a year? Completely unthinkable.

I get what Theo says about making things as comfortable as possible. I guess there is a line. If we had everything, then it wouldn’t be RISC OS, would it? These machines are like classic cars!

Modern hardware and software could help with development, for example fancy simulators or debuggers. Isn’t this the sort of stuff the 8-bit guys get up to? And their final executable works on actual hardware, but they got more done with less effort to achieve their result?

One post. Clearly not been around long enough to appreciate why things are the way things are.

I’m assuming that you and Dave spotted the avatar?

I get what Theo says about making things as comfortable as possible.

The thing here is, Peter H pops up every now and then to raise his hobby horse, but I’ve never seen any useful engagement on asking why things haven’t changed. It’s just stamping feet and a few insults.

ROOL seem to be doing an awful lot of things which on the face of it look more administratively complex than simply making the DDE free to download. Why? We’re left concluding that either the money is important, or that there’s some other reason why it can’t suddenly become a free tool that anyone can take a copy of.

If the problem is the former, then a credible alternative funding stream would presumably do the trick. Suggestions welcome. If the latter, then no amount of posturing is likely to solve the issue until whatever is blocking progress can be sorted (if indeed it can, assuming that we’re talking licensing).

Or, of course, people could get on with making RISC OS build nicely with the freely available tools. :-)

Looks like a troll who is about to get his account deleted.

It was a throwaway comment, as a first attempt to show my face. I apologise if I caused offence by expressing my opinion.

temptation is to go over there where you can get more done with less hassle.

Funny. I came back to RISC OS. It was dead easy to do stuff

This in No Trumps, doubled and vulnerable.

The beauty of RISCOS is how easy it is to do stuff. There are still a few things I can’t do in RISCOS, but it’s an impenetrable jungle everywhere else. So much so that I can’t be bothered to tackle the learning cliff. From Windows machines, I’m a much relieved escapee. On a Mac, I’m a fairly experienced user, not any kind of an expert, and certainly couldn’t write an app.

On RISCOS? If I need an app to do something (usually to do with something I’m doing on the Mac) I just write it. These days, in BBC BASIC because it’s dead easy to write and fast enough – formerly, in assembly language for speed. Whichever, I write it in a nice, simple text editor – no farting about with incomprehensible, inconsistent Development Environments. (Nor even Libraries or Compilers, although I wouldn’t have a problem with those as long as they were sensible ones.)

Or, of course, people could get on with making RISC OS build nicely with the freely available tools. :-)

They could but even if you “costed” your time at minimum wage I suspect it would be cheaper to buy the DDE.

The beauty of RISCOS is how easy it is to do stuff. There are still a few things I can’t do in RISCOS, but it’s an impenetrable jungle everywhere else.

I’d say the exact opposite. Having written stuff for Windows (in a day-job capacity), it’s always slightly surprising how difficult the simple things are to do on RISC OS.

These days, in BBC BASIC because it’s dead easy to write and fast enough

And maintainable, for a large project like a multi-file document editor, or even a moderately large Wimp application with easy to use dialogue boxes?

Whichever, I write it in a nice, simple text editor – no farting about with incomprehensible, inconsistent Development Environments.

Again, there’s no real contest. As a Zap user who still tries to like StrongED in case I’m missing something, my RISC OS coding is these days done on the adjacent monitor using Visual Studio Code. The ease with which it navigates through the many files of a large project, syntax checks code – including library calls into RISC OS libraries – on the fly, and much else besides leaves no comparison with RISC OS tools. We were ahead of the game in 1990 with StrongHelp lookups, but then did nothing in the intervening 30 years.

And source control? Oh, yes… we might be getting a Git client soon.

Yes, again I use these tools away from RISC OS. But once you’ve used modern stuff, it’s very hard to return to the clunkyness of what we have natively on the RISC OS platform.

Different way of working – ie Basic Progs are usually one large file – C Progs are multi files – and you have to jump around the various files

Different way of working – ie Basic Progs are usually one large file – C Progs are multi files – and you have to jump around the various files

Not really. Any large-ish BASIC program should be multi-file, too, since modularising stuff to make it maintainable is a fundamental part of software development.

I’ve just had a look at Float, which is probably the largest BASIC program I still maintain, and that has 7 source files in the project itself and calls on a further 11 library files. These can be handled using BASIC’s LIBRARY command if you wish, and the program starts with the following to make that work:

LIBRARY "BASIC:Config"
LIBRARY "BASIC:Icon"
LIBRARY "BASIC:Menu"
LIBRARY "BASIC:Message"
LIBRARY "BASIC:Resources"
LIBRARY "BASIC:String"
LIBRARY "BASIC:Template"
LIBRARY "BASIC:Url"
LIBRARY "BASIC:WimpError"
LIBRARY "BASIC:WimpSprite"
LIBRARY "BASIC:Window"

LIBRARY "src/Choices.bbt"
LIBRARY "src/Code.bbt"
LIBRARY "src/Ignore.bbt"
LIBRARY "src/Mem.bbt"
LIBRARY "src/TaskMenu.bbt"
LIBRARY "src/Tokens.bbt"

It’s more normal for me to link them into a single BASIC file as part of the build/release process, however.

The odd .bbt extensions reflect the fact that I hold all source code in plain text format, to allow meaningful source version control. A quick TEXTLOAD and SAVE on all of the files back to the same names would yield a BASIC program that would run in the usual way if you’ve got <BASIC$Path> set to point to the folder holding your library.

Oh, and you’d need to fix the src/ directory prefix separator for RISC OS, too. Did I mention that I build things on Linux? :-)

And maintainable, for a large project like a multi-file document editor, or even a moderately large Wimp application with easy to use dialogue boxes?

No, of course not. We’re talking different kinds of work. I’m writing quick hacks, not major projects. I’m eternally grateful to the people who make my quick hacks possible. RISCOS, thanks to them, is a great environment for people like me to write quick hacks in – whereas Windows and MacOs are awful places to write quick hacks.

When developers complain about tooling and development problems then it’s important to try and fix them (when possible) because you can guarantee that there are many more developers feeling the same way.

So with that in mind, could we sort of get a Top 10 of developers ‘wants’ for RISC OS? So at least we can work out what can be done in the short, medium and long term?

One post. Clearly not been around long enough to appreciate why things are the way things are.

That’s not a reason to just dismiss then out of hand either. “Things are a bit rubbish, let me explain why” isn’t going to win many “vaguely interested” people to look much further.

If we want to get more developers on risc os we need to make things as comfortable for them as possible while managing expectations. There isn’t a visual studio-alike and if you need that then you’re probably not going to get far. Personally on Linux i edit files in eclipse but still build and run everything from a terminal, that’s what works for me.

Things i miss are being able to search the project files for something. There is grep I guess but that can get confused by files arranged in c and h directories as is the risc os way. One of the things I miss the way I work on Linux is throwback. Yes I could probably build from eclipse and if would work but I haven’t yet had the energy to do so.

So with that in mind, could we sort of get a Top 10 of developers ‘wants’ for RISC OS?

Going back to where we started – I wonder where “Free DDE” would be on that list. The only thing I would add though is we need to think about who the list comes from. What would make the existing developers “fitter, happier, more productive” could be a different list from what people who are looking at risc os for the first time, and there are also probably those who did stuff on it in the late 90s but might be taking a second look.

I’m assuming that you and Dave spotted the avatar?

Spotted it. I guess the sarcasm in the reply was missed? ;-)

It is a valid discussion, as this thread demonstrates, however…

If we want to get more developers on risc os we need to make things as comfortable for them as possible

The problem we are running into here, over and over, is lack of developers. So for the moment we’re pretty much stuck with the likes of the DDE just as we’re stuck with a FontManager too braindead to substitute fonts or revert to Latin# for broken UTF8 sequences. And don’t get me started on Territory (again!).

Additionally, when we talk about “backwards compatibility”, we often mean something in the order of thirty years, not to mention including a different branch of the OS that may have subtle differences, other services, etc etc.

I wonder where “Free DDE” would be on that list.

Probably fairly high up. Personally, I can’t imagine ROOL makes that much out of selling the DDE. And there are clearly developer incentives to making it freely available. Therefore, I surmise that there must be some sort of licencing issue that is preventing this from happening…

Having said that… making the OS “fully open source” didn’t cause developers to beat a path to our star prompt. The people asking for a free DDE are the ones who were asking last year. So if the DDE were to be free, great, people could hack their own RISC OS as they wished… but would this bring in more developers? I have my doubts, given that a huge majority of the source code is low level assembler. There are fewer and fewer people who mess with that sort of thing – this isn’t the ’80s!

it’s always slightly surprising how difficult the simple things are to do on RISC OS.

Define simple.

Speaking from experience with VB, there is certainly a lot of stuff that the OS (or perhaps, a properly competent library) could be doing to simplify matters. Slider bars, up/down selections – these sorts of gadgets ought to pretty much look after themselves (and I think the Toolbox was a start at trying to provide that). The available gadgets are greater in scope elsewhere. Perhaps the Wimp could do a bit more for the application authors?
[but, again, developers…]

And maintainable, for a large project like a multi-file document editor,

I wouldn’t use BASIC for that. You’’d basically need to write and manage your own memory handling for the documents as BASIC’s is very simplistic.

We were ahead of the game in 1990 with StrongHelp lookups, but then did nothing in the intervening 30 years.

One can’t help but observe that it would serve as a metaphor for the entire OS…

Things i miss are being able to search the project files for something.

Yes. I search for stuff in the various sources by dropping all of the files into Zap and telling it to search in all files and show the results in a window.
[similar functionality exists in StrongEd…]

But when it comes to looking for the definition of something used in the source, well, my god… it’s a convoluted mess of includes including other things which in turn include other things. Sometimes it’s just easier to copy the set of inclusions in the source of interest and write a program that is basically:

   printf("%d", VALUE_GOES_HERE);

Run it, get the value, job done.

I guess that’s part of the reason I resist using the shared makefiles. Having seen stuff scattered all over the development environment, I don’t really fancy adding another thing to it.

[plus, most of my recent makefiles Stamp the module containing ‘main()’ to force it to be rebuilt, and run a program called “_version” which creates a header containing the version, current date, etc that is pulled in by the main-module; thus meaning that built in dates and versions are kept up to date in one place. Not sure how I’d add that into the shared makefile system]

So with that in mind, could we sort of get a Top 10 of developers ‘wants’ for RISC OS?

Hmm.

Okay. Let’s get the ball rolling… Random order off the top of my head:

• [Free DDE] I don’t need this as I have the DDE, but it’s a fairly recurring request so I guess that it probably ought to get a mention.

• A tool that, given a symbol or function name, could tell you where it is defined and where it is called. With, of course, click-to-open-in-editor support, not just spitting out text to the command line.

• A debugger that isn’t kind of rubbish (fairly crash-prone, incapable of unloading itself after a crash so requires a machine reset, completely unable to cope with anything other than application code, doesn’t even spot null pointer writes unless the underlying OS throws an exception; and that’s just the stuff I remember). There’s a reason I use DADebug, it’s to avoid having to use DDT.

• Perhaps a remote debugger (network and/or serial port) that can operate with a greater scope than DDT, perhaps at machine level as well as task level?

• Better OS task security. What it is that causes those random cascading crashes where everything just dies? They’re a lot less common than they used to be with 3.70, but they do still crop up.

• More automation in Wimp libraries. One of the reasons I use DeskLib is that it tries to make things simpler. I can create a window, attach a handler for icon clicks, and when the user clicks an icon the function will be called with the icon number. How we get between the poll and the function being called is something DeskLib worries about, not me. We need more removal of boring boilerplate. This might be part of what Steve meant about the simple things. There’s a lot of hoops to jump through getting an application started (especially in BASIC), then more hoops in handling the polling loop, and… I trust by now everybody has their own pet library, because messing around with the Wimp’s various blocks for, say, deselecting an icon or changing the sprite that is shown, it’s a mess of shifting bits of memory around that becomes quite ugly in standard BASIC.

• Automatic tea dispensing after every half hour of coding (remember who is writing this message…).

• Variable name completion, especially for structures. And some sort of call-up-able help that can list what elements are available in the variable/struct that you’re looking at, and in the case of enum, what values are available.

• Autosave in the editor. I’m actually surprised that Zap doesn’t do this (or did I miss it?).

I guess the sarcasm in the reply was missed? ;-)

It was more Dave’s “Looks like a troll who is about to get his account deleted” that I objected to. I was under the impression that Dave had account-deleting permissions purely for the purposes of deleting obvious spam; I didn’t realise he also got to decide who was trolling on our behalf.

Personally, I can’t imagine ROOL makes that much out of selling the DDE. And there are clearly developer incentives to making it freely available. Therefore, I surmise that there must be some sort of licencing issue that is preventing this from happening…

That’s my suspicion, which is why I find the foot-stamping from a couple of people unhelpful. Posturing on this, if there’s no realistic chance of it being sorted, doesn’t help anyone and probably causes far more damage to the platform by creating discord than the cost of the DDE itself.

If ROOL are genuinely profiteering cynically from this at the expense of the platform then yes, let’s fight them every inch of the way. However, I feel that there are probably more profitable ways to go about profiteering than charging £50 a pop for an obscure ARM development environment. Which makes me tend towards the “licensing” explanation as being far more likely.

Speaking from experience with VB, there is certainly a lot of stuff that the OS (or perhaps, a properly competent library) could be doing to simplify matters. Slider bars, up/down selections – these sorts of gadgets ought to pretty much look after themselves (and I think the Toolbox was a start at trying to provide that).

That’s one area, although the toolbox and third party libraries mostly sort that. In my case, SFLib does most of the boring stuff without bothering the application, after a single registration call when the templates are loaded.

The available gadgets are greater in scope elsewhere. Perhaps the Wimp could do a bit more for the application authors?

This is definitely a thing. For example, CashBook pretty much required me to write a full implementation of a spreadsheet-like table for supporting the tabular windows. Even WinForms have standard gadgets that do this (and no, they’re not too bad).

And maintainable, for a large project like a multi-file document editor,

I wouldn’t use BASIC for that. You’’d basically need to write and manage your own memory handling for the documents as BASIC’s is very simplistic.

You might not use it, but even this thread (I think) has had people proudly stating that they used BASIC in 1990 because the DDE was £400 so they’re not going to start to use C now, dammit… because, well, Acorn would have won if they did…

And then we get to watch the fascinating threads over on csap where people are having issues debugging complex networking apps written in BASIC… :-)

RISC OS is an absolute pig to debug stuff on, although things like ZeroPain have helped a lot. It took a full day of lockdown this week to find a single NULL dereference in Launcher, because it actually had the interesting side-effect of causing RPCEmu to exit as well – losing a couple of lines from Reporter’s log in the process, and therefore pointing to a totally different piece of code (and causing an hour or two to be wasted chasing some non-existant stack corruption, since it looked as if the code wasn’t returning from a function).

I couldn’t help but think that, even in DotNET Core, the code would have stopped and the IDE would have highlighted the NULL function pointer for me. Instead I spent about four hours getting an address to work from, followed by another four hours using *MemoryI and manually disassembling the C code until I could identify a line in a function which related to the MOV R15,R2 in question.

So yes, erm, some decent debugging tools would be really good. :-)

I didn’t realise he also got to decide who was trolling on our behalf.

I hope not. It isn’t always easy to tell who is trolling and who is taking the p… as evidenced, no doubt, by that annoying git with the 9039 9040 posts.

which is why I find the foot-stamping from a couple of people unhelpful.

Sort of what I was hinting at in the past. There’s always an excuse not to do something. Big deal about the OS not being open source (as in OSI definition). Now it is, so noise about DDE not being free. If it was, I’m sure there would be some other great impediment…

If ROOL are genuinely profiteering cynically from this

They’d be better off selling handwash gel on eBay. Or running a cottage industry hand sewing face masks (with the ROOL cog, of course!).

then yes, let’s fight them every inch of the way.

Hmm, this isn’t going to be a wuxia movie. Plus, we’re mostly British, so fighting them every step of the way is what? Discontented mumbling?

Any large-ish BASIC program should be multi-file, too, since modularising stuff to make it maintainable is a fundamental part of software development.

Joe Taylor was very keen to promote multi-file programming with AppBasic. Unfortunately local variables seem like an afterthought in BASIC, which makes it a difficult language for protecting against accidental name-clashes – particularly if a project has many authors. Ever since I came across Lua I was impressed by its greater potential for debugging with its self-reflective facilities. Debugging Wimp programs is notoriously difficult, because once the thread of execution has departed from userland through the gateway of a SWI call into system-land there is little that you can do to track what is going on. RISC OS provides no debugging mode. The only possibility is to dump registers and other data to store before an SWI is entered. In RiscLua that is very simple. You just do

local raw_sys = riscos.sys
riscos.sys = \ ( ... )
         dumpreg ( ... )
         => raw_sys ( ... ) end  

Unfortunately local variables seem like an afterthought in BASIC, which makes it a difficult language for protecting against accidental name-clashes – particularly if a project has many authors.

Not so much an afterthought as efficiently implemented, I suspect. Variable lookup only has one route to go down, and the stack use is an entirely separate piece of code. Remember that it dates back to the Beeb, when saving every byte of space in the BASIC ROM was probably important. And, once done, it can’t be changed.

It might well have been from BB4W, but I’ve long used a BASIC convention that global variables are camelcase with no underscores, while local variables (which must be declared as LOCAL) are lower case with underscores.

In addition, anything global has its name start with the name of the module that it’s inside: so within Float’s Mem.bbt file, we have

DEF PROCmem_initialise
LOCAL new_slot_size%

MemStackSize% = 1024            : REM The required "stack" size, in bytes.
MemStackPtr% = 0
MemSharedInUse% = FALSE

REM Get the current WimpSlot size, then expand it to give space for the stack.

SYS "Wimp_SlotSize", -1, -1 TO MemBaseSlotSize%
SYS "Wimp_SlotSize", MemBaseSlotSize% + MemStackSize%, -1 TO new_slot_size%

REM \TODO -- We should probably error if less memory than expected was claimed.

REM Make the stack fill the actual new slot size.

MemStackSize% = new_slot_size% - MemBaseSlotSize%
MemBaseSlotSize% = new_slot_size%
ENDPROC

This makes it easy to find things (we know that anything starting Mem, PROCmem_ or FNmem_ must be defined inside Mem.bbt), and also significantly reduces the chance of any variables overwriting each other by mistake.

The lack of scoping is still a problem. And the lack of memory structures. And most of the other stuff that other languages take for granted. The fact that Mem.bbt is entirely devoted to providing chunks of scratch memory that other bits of Float can scribble over as needed and then release back to the free pool pretty much says it all, I think. :-)