Programming IDE for RISC OS (CodeCube Cloverleaf project)

To be honest I think we’d get much further faster by not writing/porting an IDE for RISC OS, but rather take one that runs on Linux and concentrate on getting it to remote debug code running on a RISC OS machine. The reason being anyone sensible doing development already has a separate RISC OS machine to test code on, as RISC OS is so easy to crash.

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.

You do a Language Server Protocol Client and have already C, Lua and Python covered (multiple solutions already available). And countless others of course. Then you integrate it into Zap and StrongED. Sounds easy :-)

The double R in the spelling being a play on something from my childhood.

Z

Vim == love.

Nah, still has the core of evil in it.

Could this be pluginable?

WinEd already contains a very early chunk of code referred to as “IDE”, which appears to be a set of Wimp messages which it can send instead of editing windows directly.

Or, at least, that’s where I think it was supposed to be headed. It didn’t seem to do much, so I disabled it before creating the 3.23+ releases. I think it also could be backwards, as it seems to be about palming off the template editing work on to a third-party, whereas I’d expect WinEd to do that and tell the third-party what it’s doing.

That said, I wonder if there’s any mileage in pursuing the idea. A system of standardised Wimp messages through which a template or resource editor could inform an IDE that the user wanted to create a click event handler for an icon called “No” in a window called “Are You Really Sure About That” could have some potential, for example — although it would need some care to ensure that it was language agnostic.

@Rick

Double clicking on an icon will open up the editor with an appropriate function already created.

Thinking only of BASIC and the Toolbox, this is an idea that has haunted me for a long while, but I do not think it could work quite so easily.

The Wimp is event-driven and you can have several events associated with an icon. Even if you could get over the problem below, you would end up having to parse the possible events with a CASE structure – ugh!. There are also the events that are not associated with icons to deal with.

The problem that makes this tricky is not having a namespace for icons. These are uniquely numbered in a window, but references to, and function names for, icons will be like ‘MainWindow4’, which is somewhat cryptic.

The project I have had simmering for a year or so, Oobi (Object-oriented BASIC Interface) uses the Help field in ResEd to define names by tagging “_name” to the help string. This is found during initialisation and then removed. I have a version of ResEd with modified Help messages to prompt this.

The programmer (that’s me!) still has to write the event function code, but it will be of the form:

DEFFNChoices_Save_Selected
 PROCSetOptions
 PROCWriteChoices("<Choices$Write>.Crunchie.Choices")
=FALSE

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.

This is something I can whole-heartedly agree with. ;-)

However, getting BASIC and the Toolbox to do this is not easy. If you are brave enough you can see Oobi in action by looking at the front-end ‘!RunImage’ to Crunchie. This is a work-in-progress and Oobi uses a lot of ‘magic’. ;-)

I do not think AppBasic gets there, but Joe’s superb documentation makes it really very useful. I can provide all the information for Oobi, but I will never be able to match Joe.

Going back to the original start of the discussion.

I think there is a necessity for a comprehensive programming IDE for RISC OS. What currently exist for C is only a collection of programs that you can use. This makes it quiet difficult for programming newcomers to RISC OS to get started.

I don’t think a “comprehensive programming IDE” is a realistic target within say a few man-years of effort.

It is true that the existing toolchains are not really easy to use. But we can make it much more usable by providing comprehensive beginner-friendly documentation and project templates.

So, a first and universally useful step would be to decide on a lib that you want to base that documentation on, write some tutorials, provide skeleton projects, document best practice for structuring projects and putting them into a VCS and building them, package up all the necessary tools to follow those tutorials, and THEN think about better integration into something that might be as useful as an IDE on other platforms.

On the BBC BASIC side there is (at least) DrWimp, AppBasic and WimpWorks. There was an effort called DrWimpC to bring DrWimp (and therefore all of its great documentation and examples) to the world of C, but I think it is no longer available – the web server seems to be dead at the moment.

I don’t think a “comprehensive programming IDE” is a realistic target within say a few man-years of effort.

A framework in which to plugin various elements is a realistic short term goal though, is it not?

@David J. Ruck

(The UCDebug should solve that.)
Last time I spoke to them, it was only going to be an assembler debugger and they had no plans to support GCC.

I was told that GCC created ELF files and that UCDebug uses ELF files too. So I was thinking that should be compatible.
But that sounds must extend UCDebug to understand GCC ELF code. Need to contact the programmer.

@Fred Graute
Good to know that you are the current programmer at StrongED. We should have a private chat to figure out how we can integrate StrongED in our IDE. Have to check also about legal issues as our product will be commercial to fund its development.

About menu structure I need to investigate first what we need or what is the standard in other IDEs.
I think most of the display options are heavily related to Assembler or binary manipulations which are not necessary for a modern IDE. They could be moved in a choices/settings page to not to loose the options but 99.99% of programmers are not going to use these features in 2021. So they are more confusing than helpfull.

I have one issue with the menu structure configuring for example the display font used. There is no info in the documenation how to achieve it. After asking around Micheal Grundlitz informed me that it can be done over the menu shown when click menu on the bottom bar. (The contextual menu system of RISC OS backfires here). If you know where to find the feature then it is cool but if not….
I would expect such a configuration function in the main menu related to a choices page where all configuration can be accessed. Also I think that the font must/can be set for each of the modes (programming language) seperately is overkill and I doubt that it is neccessary. There should be a global setting for it.

I think settings/choices should be available from the main menu or RISC OS style from the toolbar menu.

In what way should folding in StrongED – currently the only RISC OS editor that supports folding) – be improved?

It would be nice if we can work together to make StrongED part of our IDE. Maybe you can improve key features of StrongED that benefits also the original StrongED and we do the integration into the IDE.

Changing the menu structure is a significant piece of work as the structure is reflected in the code. So changing the menu means changing the code.

This statement is a little troubling if I understand it right. The UI should initiate actions by the program by procedures/functions or is StrongED written in ARM assembler?!

About „80s Stylish“:
Why is the standard font set to a bitmap font? That might appeal to retro programmers but not to any other.
The „any other“ get probably a shock and think „Well, RISC OS is a nice operating system that I should have used 30 years ago. But not now…“
It is time to get to 2020 standards if we want that RISC OS get more users.
@Alan Adams
That folding and highlighting looks nice and the NotePad++ is also open source… mmmm
„NotePad++ Website“:https://notepad-plus-plus.org

@Steffen Huber

The IDE understands the code. It can auto-format the code, so it is easy to follow a style guide. It integrates the VCS of choice (in my case, CVS and SVN and Mercurial and Git) into a unified UI so I don’t have to remember arcane command line details for every VCS. I can easily access the version history of any file or the whole repository, explore the branches, make diffs between revisions (and, because it understands the code structure, can show them in a logical way instead of a simple line-based diff), find out what has been changed and when. The IDE provides a powerful source-level debugger which makes it easy to follow your code executing with full insight into fields and objects, being able to change values and even code to try out changes while keeping the code running. Because the IDE understands the code, it can provide refactoring tools that go way beyond anything possible on a search-replace basis. Auto-completion based on semantic information like availability and accessibility. Quick-fixes for common errors. Showing syntax errors without the need to compile. Showing warnings for typical bug patterns spotted by sophisticated bug detection tools with configurable rules. Showing API documentation wherever I need it, nicely integrated inside the editor. Giving high-level structural information on every abstraction level. This allows for quick navigation around any parts of the code, no matter how complex the project is. Or even a large amount of projects at the same time (the currently open workspace of my IDE has 28 projects open and accessible at the same time, each consisting of tens to hundreds of files).

Nice listing of features needed in a modern IDE so that would be definitively the long term goal to achieve.

@Rick Murray,

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 = 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.

Yes that is how the IDE should work like.
The font stuff should be actually solved by a new sophisticated Font manager that Nemo is working on since…
And I agree to all other you said there.

@Richard H
Thanks for confirming that we are on the right path.

@Ron Briscoe
Better you support our crowdfunding on Kickstarter next week than someone that surely doesn‘t want the same than yourself.

@Steve Pampling

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

Agreed!

@Steve Fryatt

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.

Well that looks that we need to make a big cut about the RISC OS Clipboard system. If it is unfixable how it is now then we have startover and make the best one that is out there. And all maintained program can implement the new system and for the old ápps the old clipboard should be still present.

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?

That RISC OS is open source is the reason why I am doing this here. As I don‘t need to wait or pray that someone does something. I can do it by myself if I want. But I cannot give the results just for free as I need to pay my bills. I am not in pensions and probably never will be.
So our work needs to be paid. One step to achieve that is by the crowdfunding but that will not be enough to finance that all. So later sale of the products until we got all the work funded. If some one wants to join to program the IDE or to program some other stuff (for example new Clipboard) they are welcome.
There is a lot of stuff to do. Bluetooth, USB 3, 2D/3D support by GPU, video decoding by GPU, font manager and so on.
The aim is to modernize RISC OS as fast as possible. So anyone that can do a good job and most important can complete the job in a decent time is very appreciated as it reduces cost and also the development time.

WinEd might be used and modified to function as Windows editor.

@Steve Drain
Thanks for the insights!
But what stuff are you programming?

@GavinWraith

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.

Yes that is why we should to channel the efforts of good RISC OS programmers in projects that bring the maximum benefits for the RISC OS community.

By the way I have read from you about an idea of a 3D filer implementation. I would like to know how you imagine that to work.

@David J Ruck

bq. 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 agree! :-D

@Rick Murray

One that can (via add-ons) understand code, colour it, perform completion, suggest members of structures, and pop up help on function parameters.

StrongEd doesn‘t do that?

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.

I agree. Sounds similar Delphi did it.

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.

That should be possible that the IDE then only is used for managing the project files, compiling and debugging.

@Richard H

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.

Only if the editor like Zap would support the needed integration. Loading of files for editing should not be the problem but more to start compiling by keyboard shortcut etc.

@DavidS

On topic, I think the idea of using a modular design to accomplish the effect of a fully integrated environment sounds good, as suggested by others above. While I think I was not clear enough this is close in nature to what I was attempting to suggest.

That might be possible but I am not going to promise that at this stage.
PS: You show progress: Stay on topic and less rambling! :-)

@Richard H
Well if we all agree (or most) that VIM would be a good VCS for the IDE then we can have a look at it and try to ingtrate it.
Plug-ins is a wide field. You could just do a config for what app needs to be loaded to do something.
More complicated it gets when the plugin must intact with the underlying system.

@David J. Ruck

To be honest I think we’d get much further faster by not writing/porting an IDE for RISC OS, but rather take one that runs on Linux and concentrate on getting it to remote debug code running on a RISC OS machine. The reason being anyone sensible doing development already has a separate RISC OS machine to test code on, as RISC OS is so easy to crash.

well yes and no. Crashing of RISC OS is a problem. That should be fixed somehow at the next major overhaul…
No because if RISC OS has no serious development system by it‘s own I can‘t regard it as an serious competative OS.
And that is what I am aiming for.

@Steve Drain
here is a screenshot what the Borland Delhpi IDE provided to deign window content:

A framework in which to plugin various elements is a realistic short term goal though, is it not?

If “various” is “two or three”, if you don’t want to provide beginner-friendly docs, and the “framework” is only a handful of lukewarm ideas on where you might go, and “short term” means 6 months – perhaps.

The ideas on how to develop software for RISC OS are “all over the place”. BASIC or Assembler or C or C++ or Lua or Python, on RISC OS or on a different platform, use a VCS or not, use CI/CD infrastructure or not, provide proper packages or simply zip up the app, put it into !Store or on your website, use the Toolbox or plain WIMP, use a third-party lib (DeskLib? Desk? OSLib? TBX? AppBasic? DrWimp? WimpWorks?) or roll-your-own, TemplEd or WinEd (and this is probably the easiest decision!), StrongED or Zap…

Most active developers (yes, all five of them!) have spent a lot of time to optimize their way of working. Those workflows all differ quite fundamentally, and if you ask any of them, how much work it would be to bundle it all up and document it so a different developer could use it, I am sure the estimates of effort would be “multiple man-months”. There is a reason why there are so many workflows for software development no matter where you look – like e.g. number of build tools for Java…or number of different VCSes…or number of different editors…it is not a RISC OS problem, it is an IT problem. But because we are so few developers (probably less than 0.1% compared to say Gnome-on-Linux), you end up with one fundamentally different process per developer.

And I don’t have the slightest idea on how to make significant improvements to the situation without first providing a few basic tools that you need anyway to be able to build upon something that is tried and tested. Even if the whole RISC OS community suddenly decides to favour only one environment and process and way of doing – e.g. “develop on Linux with GCCSDK, Git, Jenkins, RPCEmu, TBX and integrate all the tooling that it supports seamless integration between dev environment and test environment” – it would be an uphill struggle. Especially if you think about new developers and/or beginners.

I feel like RISC OS has been a lot less prone to crashing fatally of late than it used to be.
I make plenty of programming mistakes that don’t immediately bring the entire system down :)
All that partial memory protection is doing something useful.

@RISCOSproject pic.twitter.com/IHQw1NInFs

— nemo (@nemo20000) March 11, 2021

All that partial memory protection is doing something useful.

Still difficult to get people to acknowledge the benefit of the Zero page work, and the consequentially enforced updates of quite a few buggy bits of software.

@ Steve Fryatt
I just had a look at !WinEd and I can imagine to use it as base for the IDE to create windows and define the elements values and manage events by it.
Some things need to be rearranged to serve our purposes.
So it can be a good starting point and save us some month work.

As I understand right it is also possible to use the GNU GPL to produce commercial software from it.

As I understand right it is also possible to use the GNU GPL to produce commercial software from it.

The GPL does not prohibit you from taking money from anyone. However, you must distribute the full source code with it (or at least give access to the source code), and everyone is free to pass on the stuff under the GPL to anyone else, so the possibilities to earn money from GPLed software in RISC OS world (where you usually sell the software and not services around software) are quite limited.

By the way I have read from you about an idea of a 3D filer implementation. I would like to know how you imagine that to work.

1. Age of file determines how deeply into the background a filer-object is to be represented. When stuff becomes nearly invisible put it into a special archive (compressed perhaps).

2. User-action to turn an object around, to reveal a back side on which notes can be written, with links to other objects or notes (StrongHelp possible here?).

3. Directories should be like furnishable rooms, to aid a sense of where the user is, and what is available in it. A background chosen by topic is a start, but a 3D background can go much further. Hide things behind the sofa? Put snippets into the top-drawer of the sideboard? The possibilities are endless, and possibly encourage footling unproductivity. But lets not be overhasty.

That sounds a bit like Acorn’s “Rooms” software. It’s so long ago I can’t be sure that I didn’t imagine such an awful concept.

That sounds a bit like Acorn’s “Rooms” software.

That sounds like something from a science fiction story I read years ago, virtual reality interface on a library etc. That involved bleeding edge super-computers. I don’t think the RPi can really match that title.

Hide things behind the sofa? Put snippets into the top-drawer of the sideboard?

And….you’ve just reinvented The Wimp Game. ;-)

I read years ago, […] That involved bleeding edge super-computers. I don’t think the RPi can really match that title.

That depends upon what you mean by “years ago”? A microwave likely has more processing power than the computers that took our species to Luna.

A tricked out watch has more processing power than an entire school campus in the 6502 era.

So, to put this into context… https://en.wikipedia.org/wiki/Cray_X-MP

A Cray supercomputer from the first half of the eighties. 64 bit quad processor running at around 110MHz, 400 MIPS, 800 MFLOPS, 128MiB RAM… costing $15M (about $40M in today’s money) and eating an insignificant 345kW.

The Pi2 can crunch 4,744 MIPS at 1GHz. You can get about 100 MFLOPS from a single core, so potentially 400 MFLOPS from the machine. That might only sound like half a Cray, but then we’re missing the secret weapon. The Pi’s GPU is measured in GFLOPS. The smallest earliest Pi had twice the memory of the Cray.

It probably takes closer to 345mA than 345kW, and it costs more like $40 than $40,000,000.

But either way, I think a bog standard Pi2 could hold its own against an early ’80s supercomputer. And the Pi4, modern games console, average PC could probably trounce any Cray from the ’80s.

So, yeah, I think the Pi can hold its head up if the story to which you refer was written >= ~ 35 years ago.

So, yeah, I think the Pi can hold its head up if the story to which you refer was written >= ~ 35 years ago.

As I recall it was talking about quantum computers, might not be there yet.

I hadn’t actually registered where the Pi was relative to the venerated old Cray – all that and people spend half their time using it for Tetris variants and “c u b4 t?”

@Steffen Huber GPL das muß ich mir mal genauer angucken… wäre ein Problem

@GavinWraith 3D filer

I was imagining something different, more technical style…like:
a) normal view:

1. X-ace all files in same folder
2. Y-axe file size
3. Z-axe sub folders

b) old files view

1. list in which folders are the biggest files

c) biggest files view

1. list in which folders are the files longest not used

Clicking on a box then will show all infos about a file

People are talking about something Visual Basic-esque (which sounds a good idea) and improving debugging (which sounds a good idea too), but UCDebug will be no good for debugging BASIC. Is there an existing interactive debugger for BASIC?

Also are you aware of the problems involved with single-stepping Wimp tasks?

Is there an existing interactive debugger for BASIC?

There was BasDT by Dick Alstein, see the thread here: https://www.riscosopen.org/forum/forums/5/topics/11961

I never used it, so cannot comment on how powerful it was.

Is there an existing interactive debugger for BASIC?

What do you need when you have got TRACE? :-) ;-)

Actually, do you need it interactive when you have *ReportTrace?