Programming IDE for RISC OS (CodeCube Cloverleaf project)

Also works between multiple documents.

And between multiple programs?

and if everyone should write code as part of using computers (I say they should).

Elitist twaddle. That’s like saying everybody who owns a car should be a mechanic.

Either way they use way more code than talking strait to the WIMP.

Of course. Because they are trying to simplify things for the programmer.

Look, I know that “frameworks” is a personal beserk button that causes you to want to inflict random suffered upon yourself, however I would like to ask you some questions:

• Wouldn’t it be nice if, as part as a “how to use me” tutorial, you could load a picture into a box on the screen? I mean thisbox.picture = <filename> or something. No buggering around with redraw loops, with working out what sort of colour translation to use, with working out what sort of image file it is (sprite, JPEG, PNG…?). No, you just say “show this image in this box” and it happens.
• Wouldn’t it be nice to expand that to have the ability to show a video in that box instead? Hell, give it a URL and let it fetch it, buffer it, and render it. That’s generic stuff, something a library ought to be able to look after, not something the programmer has to construct from scratch.
• Recently it was mentioned about having a “filer” style view. Wouldn’t it be nice to make a list of objects, let’s say pairs – display name and sprite name (so “MyFile” and “file_fff” for one entry), and from that the widget will build and populate a filer-like window. And when you select something, it will return the object name rather than some random offset number.
• That filer view… maybe sorting according to type or some other metric should be an intrinsic part of the view, that can happen without the app intervening. As the program gets back the name, it doesn’t matter how it is being displayed, the same thing being clicked on with cause the same result.
• Outputting “The character 桜 is said as sa-ku-ra and it refers to the pink cherry blossom from ornamental cherry trees. It is also a very popular girl’s name, where it is frequently written as さくら. The yearly ritual of appreciating the blossom and drinking or having a picnic under the blossom is called Hanami (花見) and is a very important event in Japan. Cherry blossoms also turn up a lot in drama and animated series set in high school as the flowering coincides with the change of school year, which happens in the spring in Japan (as opposed to the summer in the West).”
  Just take a moment to imagine how much wrestling it would take with the FontManager to be able to output something like that, with random bits of Japanese script in the middle of the sentences. Wouldn’t it be nice to say “output this” (with some options like where and if justified) and have it just go ahead and do it?

Just some examples off the top of my head. The sorts of things people would expect. If you point them at sockets and Wimp_GetRectangle, they’ll run away screaming “what the fu……!!!!”.

We have the best possible kind of debugger built into the OS.

Sadly, I know you’re being serious. You’re also being delusional.

As I would want to debug the running code, not the debug statements or the high level code it is compiled from.

Something that is quite clear from reading your messages on this topic is that you don’t have the faintest clue about how people write software in the twenty first century.

No, nobody wants to be saddled staring at a pile of incomprehensible gibberish. They want their debugger to stop with the faulty line highlighted. Some things can be determined easily enough, like if myval = ptr->offset; then one doesn’t need to stare at an LDR instruction (or whatever the hell it is in x86) to see that the base register is zero. Just look to see if the ptr pointer is still NULL. Hell, the environment might be able to do that programatically and flag up that ptr is being used before it has been initialised. Hell, sometimes the compiler can do that much!

Us grey haired gits that grew up in the ‘70s and ’80s (hands up if you can name the 6502 NOP opcode hex value without looking it up) grew up with PEEK and POKE and exposure to the low level innards of the machine. These days it’s quite different. Consider an Android app. It’s basically Java. So you have a source, and you have a semi-compiled object. And the time when you hit anything that can be expressed in assembler is when the app gets “installed” on the end user’s machine.
So if you’re debugging, no, assembler will not be a help. You don’t even go there unless you believe that the runtime is actually somehow broken.

I would imagine a rather large sample of modern young programmers couldn’t tell x86 code from ARM code. And why should they, if they have a development environment where debugging doesn’t require the ridiculous steps of mentally translating the source into executable, to then match up what’s actually running with the source.
Do you know why we do that? It’s because our debugging support is shit. When a C program crashes, it gives a backtrace. Half the time it can’t tell what all the entry variables were, and a lot of the time people release programs without function names, so it’s just a pile of anonymous functions. Hell, the debugger dumps that Jeffrey added are usually more helpful than a backtrace. And neither is a “break in and say ‘this is where it cocked up’”.

I shouldn’t have to know assembly to debug C.

That solves that problem without an IDE.

That solves the problems that you can see. It doesn’t solve all the problems of things that you’d know about if you used an environment from this century…

Beings as you are intentionally omiting the tools to automate 95% of creating a make file, so it sounds like it takes work. So I need not respond further to that section.

Need not, or can not?
The tool under RISC OS is “Make”. It generates very simplistic (and rather weird) MakeFiles. Doing pretty much anything else requires delving into the way MakeFiles work. And, yes, that takes work as the process must have been dreampt up in a haze of weed or something.

Like that thing where it generates a bit of MakeFile to build each target in turn? You don’t need that. You need to set up what to do with “c” files and “s” files, and then just give it a list of such and let it get on with it.
There may be smarter tools on other platforms. I’m not using other platforms.

No-one seems to have mentioned source control yet…

Oh, you mean that directory called “old”, or maybe it’s that one called “older”, or possibly that one called “old2”? ;-)

For me BASIC is good language to start learn about programming.

Python.

I don’t know Python, and I don’t really have interest in learning, but I do know that it is pretty ubiquitous. You can run it under Windows, Linux, on a smartphone/tablet (well, Android at least, abilities may vary on iPhone/iPad due to Control Freakism), etc etc.

Any system-specific language arbitrarily restricts one to that system (yes, there’s BASIC for Windows and the Brandy interpreter, but these aren’t the same).

I am actually no fan of C as it is powerful but complicates things also many times.

Oh my god – only teach C to a kid who already has some idea about how to program. You don’t start off with C. There’s just way to much bizarre crap kicking around the language!
Not to mention explaining short <= int <= long and signed/unsigned and… scream now… pointers !
C pointers are so traumatising that entire books have been written. And why is it sometimes “meh” and sometimes “&meh”? And sometimes “this.that” and sometimes “this→that”? When you use the language, it’ll start to become clear (hopefully!), but it’s not the sort of thing I’d inflict upon a newbie. At least with BASIC-like languages, the ! and ? indirection is quite clear in what it is actually doing. C? It’s late, let’s just not…

So…most of the things I wrote about above do not even begin to exist on RISC OS

This. All of this. The entire freakin’ paragraph.

I’ve been thinking about this all day. There has already been excessive verbiage on this thread, so I will be uncharacteristically brief¹. The stress of doing this may cause me to explode².

Almost all of my professional programming career (three decades of it, so not as many as some of you) has been in a unix/linux environment, and most of that has been deep system development rather than using X. In that environment, I am very happy using lots and lots of terminals running vim, various command-line utilities, and whatnot. On the rare occasions where I have had to create a GUI, I’ve used an IDE (QT Creator is my preferred one) for only the GUI bits, and continue to work in vim for the rest of the code. I know vim back to front³ and upside down⁴, and have used vi and vim basically since forever. Using an IDE in this environment only ever serves to slow me down because I know how to use vim.

A few years ago I started, grudgingly and with very bad grace, to write some WIN32 code. Didn’t want to. Still hate doing it. I used Visual Studio for the GUI bits of this, but as vim is actively developed for Windows, I could still resort to my beloved editor.

Now I’m returning to RISC OS, but from a programming perspective I’m pretty much a newbie. I know that vim is available, but as I understand it, it is about 15 years out of date (please correct me if I’m wrong). Still, it’s usable. But writing code for RISC OS is very different to writing code for Windows, is very different to writing code for *n*x. And it’s a hobby. I’m not going to have the time or patience to learn how to do clever things with the WIMP. (Who knows, maybe in another ten years?) Writing code on and for RISC OS at the moment is daunting, and feels like a chore and a burden. (This is about me; I’m not commenting on the preferences of those people who have been writing code for RISC OS for many years, and who know it inside out.)

An IDE which can integrate version control and debugging at the source language level, and which can hide the complexities of writing WIMP code (unless I specifically want to see it) is going to make me much more likely to spend my scant hours of rest and relaxation playing around with RISC OS. Who knows? I might write some code which someone finds useful.

I feel reasonably confident in stating that I’m not the only (relative) newcomer to RISC OS who feels this way.

¹ I lied.

² It didn’t.⁵

³ miv.

⁴ ɯᴉʌ or ʌᴉɯ, depending on the axis of rotation.

⁵ Ah, so there needs to be a newline between footnotes, does there? Tricksy.

@DavidS,

Like a RISC OS editor that has code folding?

Who else but you is strongly against a good IDE?

I will make you an offer. If you can provide me with a useful app I will pay
for a copy of the DDE for you.*

But remember that I only use modern RISC OS machines and am a mere user.

Elitist twaddle. That’s like saying everybody who owns a car should be a mechanic.

+1

At work (when actually in there) I have heard, oh so many times, the derision from some of the 2nd line support staff of our users.
These are people qualified in medical practices they are talking about, not IT.

There are two points to note:

1. Each to their own – others don’t know what I know¹, but then I don’t know what they know.
2. Everyone has to start somewhere, so starting with a specification for a new development tool that is not usable by the beginner is a sure-fire way of having it languish in a bit bin somewhere.

Some people deride BASIC, and when I consider the versions of BASIC I’ve seen on other platforms I can understand. BBC BASIC has always been one to make structured programs easy. Having tools to single step that, and possibly other languages would make visualising the program flow easier for many.
Understanding the structure is key to learning a flexible work method that avoids the specifics of BASIC, or C or Python.

The tools should not only be easy to use by all including beginners, they should especially be usable by beginners.

You need to set up what to do with “c” files and “s” files, and then just give it a list of such and let it get on with it.

I find it especially entertaining to be reminded by recent discussions that if you haven’t created certain directories for temporary and intermediate files to build into the compiler will helpfully error out with a fairly cryptic error rather than create the missing directory.

So, simple to use and intuitive.
Let’s give the currently-not-programming users a shot at converting the ideas they have into something like functional code.

¹ Including some loud conversationalists in the workshop outside our office. Dunning – Kruger and all that.

I am completely with you on this, Rick. We can make things easier to think about by hiding their complexity. An important aspect of programming is that it is not just about humans telling computers what to do, it is also, perhaps more crucially, about humans telling other humans about what they really mean. Simplicity is an illusion – a useful one. We like mechanisms when we can encompass them in our heads. In the early days of computing it was all about algorithms (50 years back), and then datatypes (40 years back). Ever looked at Internetworking with TCP/IP by Douglas Comer? I bought those volumes 30 years ago. The historical development of networking protocols is all about coping with complexity by using layers of abstractions.

Isaac Asimov was a great joker. Naive people take his Laws of Robotics without irony, but of course they were jokes, indended (I believe) to make a point about the gulf between human thinking and computers. We find it simple to say do no harm ; but should we try to specify what that actually means we soon find ourselves floundering, not only in complexity but also in metaphysics.

In mathematics one talks of proofs from first principles . These are rare, because life is too short. Usually proofs proceed by using theorems, proved by other people, and one’s confidence in them rests upon a complex network of trust. Those theorems in turn depend on the theorems of others, and so on. Google Shinicho Mochizuki if you want a good example of how difficult it is to establish the truth of quite a straightforward statement – the ABC conjecture .

I must echo the comments about built-in source control integration. How did I miss that? I am being a naughty boy with USBJoystick just because I don’t know where to start with Git on RISC OS.

It might make the whole job easier to divide the task up into pieces. I wouldn’t start with starting from zero and trying to build Visual Studio! What about adding code completion and tabbed documents? Then make something to show the ‘project files’ in a nice tree view and talk to a Git client? And something else to create pretty diffs and show/edit the result in StrongEd? And finally, tackle the debugger.

Something I wondered about when Justin did the first JFPatch-as-a-service… Maybe it would be easier to build a complete RISC OS IDE as a web app, complete with building and executing test suites! Probably easier to write it with some modern tooling on a modern system. :)

Is source control part of an IDE?

Yes, very much so.

A decent IDE (I tend to use Visual Studio Code on Linux for doing RISC OS work these days) will show you changed files, as well as the changes made (a diff view). It will allow you to stage files for commit (or whatever the SVN parlance is) without typing pages of text at the terminal, and to commit files using a clear GUI interface. This is vastly easier than driving Git or SVN via their command interfaces for day-to-day stuff.

Yes as I said before the RISC OS clipboard must be brought up to the standards of other OS. Maybe we can make an even better one? Maybe a clipboard that hold all previous copy actions. And keypress (eg Cltr-Y) to add more text to the current copied. A clipboard window that shows you all copied media and select the one you want.

You might find this surprisingly difficult, unless you plan to stop older applications from interacting with the Clipboard without them all being re-written. There are a couple of unfortunate design decisions in the clipboard protocol which make the job of a “clipboard holder” application writer very tricky — the main one being that it’s not actually possible to find out what is on the clipboard without causing that material to be degraded from what was originally put there.

I’d love a memory hogging monolithic IDE. Modern RISC OS machines have between 512MB and 4GB of RAM, and we’ve got sod all else that makes use of more than a few MB.

The lack of an IDE is the reason that I haven’t developed a major RISC OS program on RISC OS in over 20 years. Without being able to debug things on IDEs such as Visual Studio and Eclipse, DiscKnight wouldn’t have made past version 1.00 and I wouldn’t even have attempted ARMalyser. To develop C or C++ code I need a proper visual debugger integrated with the source code editor. I can go back to the dark ages of command line debuggers for businesses willing to pay my hour rates, but I’m never going to do that on RISC OS for fun.

Things like automatic make file generation and git integration are not deal breakers for me, but they are an expected part of an IDE these days, and the easier and more familiar with the way of working on other platforms an IDE is, the more likely a wider range of developers are to use it and have a dabble with RISC OS.

But open source means also less service.

That’s a very… curious… view from someone supporting an, er, Open Source OS…

What’s the licencing going to be for the IDE, by the way? Will it be Open, so that other developers can contribute and help move it forward?

As many have repeated they hate my code,

You’re Piers Morgan and I claim my £5.

Nobody said they hate your code.
We pretty much all said that, compared to the rest of the world, our development tools are antiques. Possibly not fit for purpose in the 21st century.

Did you miss the part where I said I shouldn’t need tu know assembler in order to debug C? Or where you too busy stressing out to be able to think?

Get a grip for fsck’s sake. You can program however you like. Enter instructions in hex words if that’s what floats your boat. Just don’t be surprised if everybody else is “dude, what the hell?”.
There are certain expectations these days. Read, well, everybody elses posts carefully.

Enter instructions in hex words if that’s what floats your boat.

Ooh! HECTOR; the Open University’s computer in a shoe box. That’s such a long time ago and so traumatic (1979? and TM221) that I don’t think I’ve recalled it in the intervening years, thank goodness. Mind you, I completed the module successfully. My brain was a lot more effective in those days. :-(

@All No fighting please guys!

Yes the overall question was who is interested in an IDE and who not. But…. the IDE is for sure not aimed at RISC OS programmers that are into the business for 30 years. An IDE is aimed for newcomers and for people who want to achieve a good result in the mimimum time with the the maximum comfort.
At the end the IDE should be as good so it is a good tool also for professional and low-level programmers.
For that I want to collect oppinions and knowledge to get to that point in the minimum time and minimum money and the best result.

PS: I don’t like negative thinking as it is highly demotivating!

For that I want to collect opinions and knowledge

Some rambling thoughts from an amateur.

I think an IDE as described here is a really excellent idea. Does anyone remember Archway?

Meanwhile, here is how I handle something that reaches the status of ‘project’, rather than ‘fiddling’.

• I have a standard way of arranging an application’s files. My way has no more merit than any other, but it does mean I can get going quickly. I do not need an IDE to do this, but it might be ‘nice’. ¹

• I use StrongED, with a mode much modified from the standard BASIC mode. I am one of those who does write modefiles ². ;-)

• I use folding and colour to make subdivisions very visible. Principally this is for definitions, but sometimes I will fold blocks of definitions. ³

• I subdivide assembler code into FNs as macros so that the folding is the same as above.

• StrongED allows me to swap from file to file instantly and brings a file with throwback to the top. I can move around a folded program largely visually, but if needed I can find a definition instantly.

• I use Reporter, largely as an error hander with throwback, but sometimes for tracing the execution. Reporter has far more on offer than I actually use.

• I document definitions in the code, so I do not need any ‘tooltip’ help. I also use StrongHelp F1 lookup a lot and I have written manuals for BASIC libraries. ⁵

• My version control is poor. I save a file with an alphabetical suffix before a major modification. I periodically place a working version in a Zip file before starting a new version. ⁴ ;-(

The bold items are important to me. Because I program for fun I quite enjoy the process of setting everything up, but it is not efficient.

Ramble over.

¹ AppBasic can create an application this way for you.

The Basalt module included a dummy application placed in Resources:$.Apps that could be copied under a different name and would run with the Toolbox bare minimum of Iconbar icon and menu. Its files could then be modified and extended.

² A long while back, in the days of Guttorm, a wrote most of a StrongHelp manual for modefiles and analysed them in a highly structured manner.

³ I want the whole program to be visible in one window. Often I will create libraries simply to keep the code being worked on completely visible.

⁴ The Zips get uploaded to my web space, so there is a little security there, but I could really use a better system.

⁵ Writing SH manuals is not a general skill and I think there may be an automated method for doing this from the code documentation out there.

I don’t like negative thinking either, but I am afraid that it comes with the medium, especially in times of plague when some unfortunates have fewer means of social interaction.

The best approximation to an IDE that we currently have seems to be Joe Taylor’s AppBasic. He spent many years refining and rewriting it, gaining much insight into how the toolbox works. He certainly intended that all the sources should be available, and was well aware of the obfuscation that results from compressing or compiling BASIC programs. The toolbox was designed to be usable by any programming language with means to call SWIs. Joe’s approach was that AppBasic should provide procedures for every possible response to the Wimp, and that once the user had supplied her own the redundant ones should be eliminated. There were various BASIC compressors available that performed these eliminations – though the author of the one that Joe preferred was unreachable for many years. In part, Joe was forced to such a design because BASIC lacks a nil value, a default for when a value or procedure is missing (Lua and Python have these). Joe was also keen on the idea that a program has a tree structure, not a linear sequence, and that !RunImage should be a directory of separate files.

Fred Graute made a brave start with a project that he named AppLua based on the premise that because Lua resembles BASIC in its iterative and conditional structures ( while, for, repeat, if – then – else, ..) it should be feasible to try a straight translation from BASIC to Lua. I hope I am not misrepresenting him in saying this. Unfortunately, subsequent analysis showed up some flaws in this premise that were not at first apparent. They concern the differences in operational semantics between BASIC and Lua, particularly with regard to mutual recursion, which AppBasic uses implicitly. This is probably not the place to go into too much detail. In Lua definitions of values must precede their use. Mutual recursion of a restricted kind is possible but not as straightforward as in BASIC, where procedure definitions are looked up in an eager fashion as soon as they are needed. I am sure it should be possible to have a useful AppLua, but it cannot simply adopt the design of AppBasic.

Where Lua can shine is in providing abstractions; something at which BASIC is very poor. Over the years I have been trying out Lua libraries that conceal the messy details of SWI calls, the loading of window templates, draggable objects, etc. But I have been reluctant to undertake the masses of work needed for a usable system, not only from laziness but also wariness at baking in a design that might not be the most appropriate. Without feedback from others there would be little point in it. BASIC, for all its drawbacks, appears to command a bigger audience, and for development that may be the deciding factor.

the IDE is for sure not aimed at RISC OS programmers that are into the business for 30 years. An IDE is aimed for newcomers and for people who want to achieve a good result in the mimimum time with the the maximum comfort.

I disagree, an IDE is for anyone who wants to actually write programs, rather than faff about. Those of us which have been in the business for 30 years, really don’t want to be stuck using stuff which every other platform had left behind in the 1990s.

I disagree, an IDE is for anyone who wants to actually write programs, rather than faff about.

Indeed. There’s a good reason why this RISC OS programmer, who has been in the business for 30 years¹, is doing his development on Linux using Visual Studio Code, then running the compiled/tokenised results on the RISC OS.

An IDE should work for everyone, and would benefit from experienced people contributing — hence my question about its Openness.

¹ Eek!

Eek!

Depressing, innit? I find that a good single malt helps.

Seems to me that we ought to first define what such an environment ought to offer. I rather suspect that the first step may be to create a new editor. One that can (via add-ons) understand code, colour it, perform completion, suggest members of structures, and pop up help on function parameters.

We’d need add-ons for BASIC and C as a minimum, as these are the most used on the platform, with Lua and Python to follow.

But – and this is why it may work better as an IDE rather than an editor with bits bolted on, is that it would be possible to create a window and put some icons in it. Double clicking on an icon will open up the editor with an appropriate function already created. The entire process between the polling loop and “it’s this icon” should be handled by the environment (and only shown to the programmer if they delve into the advanced options.

(think how VB does it)

That will allow new users the quickest way to get functional programs.

But, of course, it will need an option to turn that bit off, in order that the environment be useful to those with existing code, different libraries, etc etc.

And this doesn’t even touch on source control and debugging. (Eek again)

I rather suspect that the first step may be to create a new editor.

Could this be pluginable? Thinking about those people who are already wedded to their editor of choice, they might prefer to do their editing in, eg, !Zap, and might be less enthusiastic about learning a new editor, even if it does come with bright, shiny bells and whistles.

Could this be pluginable?

This is an incredibly interesting idea⁰, that also seems very RISCOSy to me.

⁰ In particular if I manage to get vim running on my Pi 3… ;)

Vim == love. I haven’t looked at Steve (the rPi4) this week, so I haven’t tried to install vim yet. Maybe tonight.

I can see two immediate benefits to using a plugin system:

• It It’s one less thing for Cloverleaf to have to write in order to get a minimally-usable IDE.
• It makes for a smoother transition for existing RISC OS programmers who already have an intimate relationship with their own text editor.

There are surely others. What would the downsides be?

Vim on RISC OS allegedly needs GAS and some TLC ;)

Okay. Now I’m going to cry.