Programming IDE for RISC OS

To be honest, it’s stuff like this that drove me to use an IDE on a platform that wasn’t RISC OS…

New thread. ;)

Surprisingly, neither ROOL nor ROD have picked up on this. But others have. Perhaps, instead of competing stacks or drivers, one might look at a modern IDE in light of the discussion here.

One of the old BASIC RO editors would show the the Def Proc alongside the Proc – if a Ctrl W was typed in the Proc.

I wonder if that could be added to StrongEd!

Indeed – something like it for ‘C’ code.

For C code, Sh-Ctrl-H in Zap will pop up a list of defined functions in the current file.
I can’t remember if it works for BASIC (still only on my second tea so I’m only barely functional).
I would imagine StrongEd has something similar.

As for searching for where something is defined in a long list of files, in Zap (and StrongEd), you can drop a bunch of files to be opened at once, and then do a search through all of the files at once, optionally outputting the results to a list in a separate window.

I understand that trying to track something down in C is a pain, I find the TCP/IP library especially annoying for this. In my own code I use the convention that function names begin with the library name. So something like midi_loadfile will be in the source file called “midi”, fetcher_parseurl will be in the one called “fetcher”, and so on. DeskLib pretty much follows the same method so it’s fairly easy to tell not only where things are defined, but also which bits need to be included to make stuff work.

Certainly, I would not say no to an editor that can provide suggestions, such as the parameters to a function, elements in an array, and so on. Little aids like that can make things so much easier – no need to keep referring to header files…or in the case of my SinpleSeq program, printing a copy of the header file to save time.

One of the old BASIC RO editors would show the the Def Proc alongside the Proc – if a Ctrl W was typed in the Proc.

It’s been a good 30 years now, but IIRC StrongED has a ‘push’ and ‘pop’ keypress, my muscle memory suggests I could press a key on a PROCSomething and it would push the location and jump to the DEF PROCSomething, then I could press something else to pop the old location off and return to it. (I think it might’ve been CTRL+P+P to push and CTRL+P+G to pop.. but again… 30 years ago…)

I used to combine this with a (Director I think?) global keypress to open my ‘Work’ folder along the left of the screen in list mode (which would become my ‘project view’), that, StrongED and throwback were the closest to a modern IDE I came on RISC OS.

Like Rick says, I suspect were I to time travel back to that workflow now it would be the lack of autocomplete and suggestions that I would find most jarring.

(I think it might’ve been CTRL+P+P to push and CTRL+P+G to pop..

Currently, it is CTRL-G to push (think Go to definition) and CTRL-Y to pop (think Yeah, go back now).

Surprisingly, neither ROOL nor ROD have picked up on this. But others have. Perhaps, instead of competing TCP/IP stacks, one might look at a modern IDE in light of the discussion here.

A modern IDE is probably a larger project than any other existing piece of commercial software since RISC OS was created, including Impression, Ovation Pro, Artworks, etc. So I don’t see one being written for scratch, the alternative would be a port, but the most common ones for other platforms are either written using Javascript frameworks or Java, which are basically non starters on RISC OS.

A modern IDE is probably a larger project than all other pieces combined …

Surprising what you pick up after all these years – I wonder if Zap does the same with some Ctrl keys.

What does ‘autocomplete’ do?

What does ‘autocomplete’ do?

One example would be where you’ve just typed the name of a variable that’s a structure followed by dot, e.g. foobar. Then the IDE might offer you a choice of which member to insert. This requires a whole lot more information than just an editor would have to hand.

Surprising what you pick up after all these years – I wonder if Zap does the same with some Ctrl keys.

Doesn’t really work for the described use case. I didn’t know StrongEd had a “Jump to function definition” option, so I just loaded it (4.69b5, an oldish one on this machine) to test it. The jump to definition works just fine with functions in the same file, but it reports that the string wasn’t found if the function is in a different file (even if it’s loaded).

Honestly, it’s much simpler just to drop all the files into the editor and search all files to a list. In Zap, that’s F4 and tick the “to Window” option top centre. In StrongEd, press F2.

What does ‘autocomplete’ do?

You have an array sort of like this:

struct
{
   int min;
   int max;
} coords;

struct
{
   coords x;
   coords y;
} box;

struct
{
   // some stuff
   box  position;
   // some stuff
} object;

This gives you placement values of the form objname.position.x.min and objname.position.x.max, and so on.

So if you type “ob” then it’ll suggest “jname” which you can accept (usually by pressing Space or Tab or something). You type the ‘.’ and it’ll pop up a list of possible options, which you can choose “position” either by typing, tabbing, or cursor-enter (the exact method depends upon the editor). Type ‘.’ again, it’ll suggest ‘x’ and ‘y’. Pick and press ‘.’ again and it’ll suggest ‘min’ and ‘max’ (and a good editor will also annotate this with the variable type (like ‘signed int’) in brackets as an aide memoire.

The alternative is to remember all of this, to keep the header file open in a window, or to print it out to read.

I’ve only used an editor like this ‘lightly’ (the VisualBasic 5 IDE), but I could absolutely see the benefits of such a thing.

Another thing is that, elsewhere, one doesn’t need to keep track of MakeFiles, options, and such. It’s all done at a UI level. You pick what libraries you want to make use of, and the relevant bits are included automatically. It’s IDE-dependent whether it tracks the actual bits used and includes only those (and dependencies) or if it just bungs the entire library in there.

Take, for example, writing stuff for an Arduino/ESP32/etc. You pick libraries, you write some C-like code, it gets on with building an entire firmware for you and then flashes it to the device.

By comparison, writing code for RISC OS is quite primitive. I write my software in that way because I’m used to it… and I don’t have a fancy PC with which to run a modern IDE.

A modern IDE is probably a larger project than all other pieces combined …

Possibly larger than everything combined. For how many actual people, ultimately?

I didn’t know StrongEd had a “Jump to function definition” option, so I just loaded it (4.69b5, an oldish one on this machine) to test it. The jump to definition works just fine with functions in the same file, but it reports that the string wasn’t found if the function is in a different file (even if it’s loaded).

Ctrl-G searches the current file only, Ctrl-Shift-G searches through all open files. Much quicker than doing a search and then using the result list, plus you can use Ctrl-Y to move the cursor back to where you were.

StrongED also has an add-on that provides directory search. This will search through the directory (and optionally subdirectories) that the current file lives in. This uses grep and results are returned using throwback. Files can be included or excluded based on filetype and/or path.

A more specialist add-on is what I use for the ROOL asssembler sources. It’s a Lua based script that allows me to Shift-double-click on a label, macro name, variable. The add-on will then search the current component (eg Wimp) and the Hdr path for the definition.

Recently I wanted to find where ‘msDataRequest_filetypes_end’ (in Sources.Desktop.Wimp.CBTask) was defined so I Shift-double-clicked on it and got back a throwback window telling me it’s in: AcornC/C++.Export.APCS-32.Hdr.Global.Messages

Although not an IDE, when it comes to finding things StrongED isn’t too bad. :-)

ctags anyone?

Although not an IDE, when it comes to finding things StrongED isn’t too bad. :-)

I knew you’d pop up and say “Actually…”.

Have a (virtual) beer. ;)

StrongED also has an add-on…

Any clues where StrongEd add-ons can be found please?
Both I and the SE help manual are not aware such things existed!
I do use Ctrl-G and Ctrl-Y extensively.

Any clues where StrongEd add-ons can be found please? Both I and the SE help manual are not aware such things existed!

First let me say that I use the term add-on very loosely as meaning a program that is somehow interfaced with StrongED.

For example, The directory search add-on is called from StrongED. It then reads the sysvar StrongED$Tmp_FilePath to find the directory to search, and it reads StrongED$Tmp_MarkWord which is used as the initial search term. These sysvars can be set by calling StrongED’s SetTmp() function prior to invoking the add-on.

DigDirSED, as the add-on is called, then opens its window where the search can be refined by specifying recursion, case-sensitivity and inclusion / exclusion. From this it builds a command to run grep which performs the search and returns results using throwback.

As you can see DigDirSED’s interaction with StrongED is quite minimal, just reading some StrongED sysvars and using throwback, but it still adds some very useful functionality.

Most add-ons that I’ve created are shipped with StrongED and can be found in the !StrongED.Defaults.Tools directory. There are a number of modes that have their own add-ons that provide mode specific support.

To name of few: AppBasic mode has an add-on that provides completions for AppBasic’s Toolbox veneers. C mode has one to load header files. Obey has an add-on to show the value of sysvars.

Add-ons can be created easily, all you need is a programming language that can make OS calls. You’ll also need to understand ModeFiles and some StrongED functions (mainly SetTmp, Run and Process).

I did make a start at implementing an IDE (see https://youtu.be/3_-YB3nca1U) but it was only intended to be a fairly minimal IDE to make life programming on RiscOS a little less hassle. Might be suitable for those new(ish) to programming, but not a full modern IDE for large scale projects.

My !tabby app was developed to make writing the IDE a bit easier – the last thing I was working on was replacing my simple editor with an editor borrowed from another program (e.g. !SrcEdt) so the rest of the IDE wraps around it in the same way that !tabby does.

Unfortunately real life keeps getting in the way of making more progress on anything at the moment :-(

That’s nice! I keep meaning to look at https://jeanmichelb.riscos.fr/Dev.html

I tend to use Visual Studio and Chrome Dev Tools in my day job, and then having used StrongEd a bit on RISC OS, I find the gaps are:

1. Lack of a tabbed interface – multiple documents, but one window
2. Auto help and code-completion – maybe LSP can help here?
3. A ‘project file structure’ tree view (Diderot seems to cover this)
4. Keyboard navigation/shortcuts (probably my user error). I like the Home/End in Visual Studio, and selecting text when holding SHIFT.

And… for the big one…

A debugger. At source code level. With breakpoints, variable inspection & modification and code editing. :-o

As today has demonstrated, a lack of good “objects”, like “here is an icon on a window, this is the picture I’d like you to show in it” and it just works.

For those who have looked to the dark side back in the day, cast your mind back to VisualBasic 5 or 6. There were numerous API things that you just fed data to and they took care off themselves. Picture boxes, lists, and so on. If I recall correctly, you could even print and draw into windows (in the absence of custom redraw code).

It’s just little things like that which remind you how bloody much work needs to be done on RISC OS in order to get the simplest things done. There are libraries that help, from DeskLib to the Toolbox, but it’s still a far cry from anything like VB…

A debugger.

We have one. It’s a pain to use but it exists.

At source code level.

Yes (provided you’ve built your program with debugging stuff within and DDT can locate the relevant source files).

With breakpoints

Yes. Breakpoints on address, event, and variable changing.

variable inspection & modification

Obviously.

and code editing.

That we don’t have, and we’re unlikely to have (except maybe in BASIC?). IDEs that can do that generate code differently to a regular compile so have access to a lot more information about the program and they often compile blocks into some sort of intermediate code that was easier for the IDE to manage. That’s how some can do fancy stuff like “insert a few extra lines of code and then restart this loop from the beginning”.

On RISC OS, for C, the intermediate stage is known only to the compiler. It isn’t accessible to us, it isn’t written out anywhere, and there are no hooks to snarf a copy of it.
It’s just source in, object file out.

That’s not to say a better debugger wouldn’t be welcome (though I’m not sure exactly how given the way the OS works), but on the fly source editing wouldn’t be a part of it.

and selecting text when holding SHIFT.

I like that too. RISC OS doesn’t have much of a concept for things like that because the OS was designed with the idea that there’s always going to be a mouse available. That’s why one can’t use cursors in menus, for instance.
Back in the days of Windows 3 it was entirely possible to have a machine with no mouse or tracker ball, and it had to be functional. Until Microsoft broke things in Windows 95 (specifically the system tray), it used to be possible to entirely use Windows without a mouse. Hell, you could even use F10 to open up menus in case you didn’t like or know about the Alt-xx keypresses.

That other systems (Linux/Mac) provide similar methods is because it is actually useful.

I don’t know about you, but if I’m typing something and then need to reach for the mouse, it’s an actual mental context switch to take my hands from keyboarding to mousing, then back again. I’ve been known to press F3 and type paths into the Save dialogue in order to avoid the context switch.

and selecting text when holding SHIFT

StrongED supports select by holding down Esc while you navigate with the keys.

to select some lines: hold Esc and press down arrow

to select to end of file: hold Esc and press Ctrl-down arrow

etc

We have one [a debugger]. It’s a pain to use but it exists.

I’m not even sure DDT even qualifies as such these days.

Nick Wirth was writing a desktop debugger, he used to send me copies right about when I stopped having any time to play with RISC OS.

I did a little play around with DDT – couldn’t make out whether it was made to work with modules – or was never finished.

Was there a particular reason the source was never released?

It’d be a total waste of time to write an IDE for RISC OS. Just use the web version of Visual Studio (vscode.dev), though it needs the File System API to be fully supported which the latest Safari doesn’t yet do.

There was a multi-window version of DDT floating around, many years ago which was a substantial improvement, though it was still single-tasking (it predated wimp filters, which is how I proposed upgrading it) and, more importantly, it was never made compatible with the RiscPC.

@ Colin

I did a little play around with DDT – couldn’t make out whether it was made to work with modules – or was never finished.

DDT is not designed to debug Modules. Only application code both CLI and WIMP (yes it can set breakpoints on events). Also DDT is designed only to support ASTDF (ARM Symbolic Debug Table Format), so cannot be used to debug ELF executables.

Here a video that I made to show how to debug OOP code (which requires some minimal tricks), which was kind of added later.

https://www.youtube.com/watch?v=H54uwru9G5k&t=1003s

BTW to everyone interested in DDT I suggest to use the latest release from ROOL, where a bunch of issues were fixed.

If you need to debug ELF32 there is this debugger, but to this date it can’t do source level debugging:

https://github.com/fuentesp/UCDebug

If you need to debug modules I would recommend either to use an emulator that supports debugging feature, like ArchiEmu or Arculator if your module works with old RISC OS versions or JTAG + GDB, but this is a little tricky to do source debugging (modules are always a pain to do source debugging).

Was there a particular reason the source was never released?

As far as I know, there are still portions of the compiler and possibly DDT with copyright license, if you want to help ROOL you’ll probably will need to still sign an NDA to have access to the sources.

HTH

@ Piers

It’d be a total waste of time to write an IDE for RISC OS. Just use the web version of Visual Studio (vscode.dev)

I agree, I use Iris with a JS based IDE, but, in all honesty, JS is still slow on RISC OS, so I find myself many times resort to my all time fav StrongEd. Althought if StrongEd insists on having both C and C++ under the same mode, so I have the pain of having to rip off that nonsense every time and replace it with my own modes, I wish those two were separated as they should.

Also the other issue with vscode.dev is running code and tests, for which I started a project I called RIDE (RISC OS IDE), which is actualy an environment for VSCode Studio that also embed an headless RPCEmu and containers combined with the template repo I made on the ROCOG community on github to have a clean and painless development, build and testing experience with code for RISC OS (however RIDE runs on Linux and macOS, not RISC OS itself).

If you need to debug modules

Assuming you’re using C, there are two approaches. I use both, though the latter most often.

A lot of stuff in modules that runs in a privileged mode does not need to have those privileges. Which means it’s perfectly possible to write a test cradle to run the code as a standalone application (in normal user mode, so if it blows up it won’t take everything with it). You could even use the debugger with this, and then paste the eventual code into the module. If you maintain the same interface (call passing a register block and some dummy privateword value) you could even link in the actual module code and run that. Modules don’t have a main() function, so you could do something like:

#include "ModHeader.h"
#include <stdio.h> [etc etc]

_kernel_swi_regs r;

int main(void)
{
   printf("Testing the first SWI\n");

   r.r[0] = something;
   r.r[1] = something_else;

   if ( module_swihandler(0, &r, NULL) != NULL )
   {
      printf("SWI returned an error.\n");
   }
   else
   {
      // check r.r[X] to see if the right things
      // have come out the other end.
      
      // then print "OKAY" / "FAIL" or whatever
   }

   return 0;
}

And since you’re running as an app, it’s fine to dump output to the screen.

The alternative is to embed a lot of debugging information that is enabled with conditionals (#ifdef stuff) to output to your elixir of choice, be that DADebug or Reporter or just spewing to the serial port (the latter is useful if the machine stiffs, as something else will have captured the data up until that point).

#ifdef DEBUGTHIS
   debug("Reticulating splines are %d / %d\n", spline_val, spline_div);
#endif

It helps to embed this sort of thing as a normal part of writing the code, as it’s a lot less hassle to think ahead than to patch in lots of debugging later. Save that for tracking specific things.

It’s also useful to categorise what you’re outputting, like “#define DEBUGTHIS 1” and “#define DEBUGTHAT 1”. You can then select what you want to look at rather than having everything thrown at you. DADebug and Reporter will cope fine (both have big buffers) but it’s a bit needle-in-a-haystack.

When you think the code is working well, do not remove the debugging code. Simply don’t #define the necessary values so it won’t get compiled.
Trust me, one day in the future you might need it again, so just leave it inert.

But, yeah, debugging modules under a live RISC OS system is maybe level 2½ of Dante’s rings.