Programming IDE for RISC OS

possibly DDT with copyright license

Maybe they are worried that we’ll run away screaming if we got to see DDT’s internals? ;)
I bet it does some icky things, imagine TaskWindow turned up to eleven.

Althought if StrongEd insists on having both C and C++ under the same mode

Given C++ is a superset of C, I’m interested to know why this is a problem? Do you prefer different colours for C++?

Given C++ is a superset of C, I’m interested to know why this is a problem? Do you prefer different colours for C++?

Let me correct you here, C++ WAS a superset of C. Not anymore, they are almost two different languages with common ancestors: ALGOL and C.

For instance:
- “auto” keyword means two different things in C and modern C++ (luckly for STrongEd old mode is a language keyword on both of them thought)
- class has obviously {} which the C mode doesn’t take care of when contracting. I can use a variable called class in C, but in this case the old C mixed Mode will highlight it as a language keyword, the same happens for all the other C++ specific keywords like “using” etc. which does not exist in C and so in C they would be just container’s names.
- C++ uses < > in a special way, C does not. For instance have a look at the way lambdas work in C++ (the definition of one of those will look funny on StrongEd mixed mode):
https://en.cppreference.com/w/cpp/language/lambda

So yes, I have created my C++ Mode and was hoping the C mode would stick to C only, but on 4.69f13 is still the mixed one.

I haven’t moved yet to 4.70 (so I don’t know if Fred adopted my old C++ Mode for 4.70)

Interesting stuff in this thread!

I can’t believe I missed a big one of my earlier list: source control (git) integration.

I’ll also add my voice to the ‘DDT isn’t a respectable debugger’ crowd. Actually, Rick has brought up a good level… if we had something as capable as VB5, that would be amazing. But I agree it’s a pretty large undertaking, and perhaps totally pointless. With emulators, there are other options. Imagine RPCEmu with an integrated debugger? Or something like Pyromaniac? I think it would be significantly less work to build on things like that.

Or is this all against the spirit? There is something nice and retro about doing things natively! If I was just going to use Linux, then just use Linux and forget about RISC OS, eh?

It seems to me – that there is not a flag to set for modules to operate in user mode.

Presumably Linux RO is running the OS in User mode.

I have cheated in the past in directly going to user mode – but I don’t want to upset Gerfs breakfast:-)

Let me correct you here, C++ WAS a superset of C. Not anymore, they are almost two different languages with common ancestors

That doesn’t make a huge difference to the debugger, what is important is the ability to decode the debugging symbol table for executable format, so it can identify the line of source code for a code location, and the basic/compound types of any data in registers or on the stack. A bonus for C++ is to be able to decode the symbol name managing which I almost managed for both CFront and GCC (there are a couple of obscure encodings which I could never work out). ARMalyser will decode the debug symbol table with unmangling, but I haven’t tried it with anything later than GCC4 (CFront will be the same as it was in 1998).

Or is this all against the spirit? There is something nice and retro about doing things natively! If I was just going to use Linux, then just use Linux and forget about RISC OS, eh?

Well I couldn’t have never debugged something of the complexity of DiscKnight or ARMalyser on RISC OS, so it was done using Visual Studio on Windows, and these days Linux if I ever need to make an update. Unfortunately now I neither have the time or patience to try to develop anything on RISC OS, it is like going back to the stone-age and trying to build an aircraft.

That doesn’t make a huge difference to the debugger,

Indeed, but the subtopic you’re refering to has nothing to do with the debugger, it’s a response to Rick question’s about StrongEd C Mode that is a mix of C and C++ code highlight.

I neither have the time or patience to try to develop anything on RISC OS, it is like going back to the stone-age and trying to build an aircraft.

I agree. RISC OS is old and it’s pretty obvious. Nowadays, people mostly code on it for fun or out of nostalgia. That’s why we don’t see many big applications being developed for it anymore. I know some people might not like hearing this, but it’s the truth. Just imagine trying to run Photoshop, Visual Studio, or modern music software like Sibelius on RISC OS. Or even playing AAA games with stunning graphics and real-time rendering. It’s just not equipped for that.

In my opinion, RISC OS is mainly a fun playground for retro coding and reminiscing about the past. It’s perfect for new engineers who want to experience what coding was like in the 80s/90s without needing to invest in old, clunky hardware like an Amiga. With a Raspberry Pi, you can get that nostalgic feeling without breaking the bank.

For me, it’s the ease of developing not big applications, but tiny little apps to do odd little jobs that I don’t have the software for on the Mac. Maybe they’d be equally easy to write for the Mac – although I suspect not – but for me, RISCOS is a familiar environment in which to write them. No DDE needed: I write them in BASIC (or in the past, in assembler) on Zap (or formerly in Edit).

Maybe they’d be equally easy to write for the Mac

Thing is, on a Mac you’d probably be writing them in something like Python… using an IDE like PyCharm or maybe VSCode, complete with a proper debugger.

From the perspective of someone who still writes RISC OS software in BBC BASIC and C, but also has the occasional need to create “tiny little apps to do odd little jobs” on Windows for work reasons, I use Python for that and there is no comparison.

I’m afraid that the world has moved on since 1987, and BBC BASIC, Zap and StrongED haven’t really followed that closely.

Nowadays, people mostly code on it for fun or out of nostalgia.

Very much this, in my case. It’s a fun platform when you have no deadlines and your time isn’t worth anything, but it’s certainly not practical. At the South West Show, I mentioned the issue that I’m having with Puzzles to a few people: the one where it takes the machine down¹ with a floating point exception when the “missing”² game starts up. That’s going to be fun to track down, but I’d put money on it simply being a case of running the code from VSCode and watching where the exception is thrown were I doing it on Windows.

I suppose I could investigate DDT.

¹ As in “reach for the reset button”. I get the error box to tell me what went wrong, but the system never recovers.

² The one that you won’t find in Saturday’s test build.

takes the machine down with a floating point exception

I don’t remember DDT being of any use with these.

Myself, I’d just turn off FP exceptions (https://en.cppreference.com/w/c/numeric/fenv/feholdexcept for the uninitiated) and watch the NaNs or Infs propagate. At least you can insert code to test for them, which is somewhat quicker than continually resetting.

it’s the ease of developing not big applications

This.
For when you want a fairly simple but also fairly specific job done.
My latest example is here https://heyrick.eu/blog/index.php?diary=20240225 and I’ve just written s TaskObey file for “today” and another for “tomorrow”. Click one, a few seconds later I get the results I want without all the headaches/nonsense of other methods.

Myself, I’d just turn off FP exceptions

I’d be more wondering how does an FP exception take the machine down? An app will be running in user mode and I know RISC OS isn’t great (understatement!) at locking stuff down, but a reset button scenario for a div-by-zero or whatever?!?

Unhandled exceptions in redraw events don’t help.

Myself, I’d just turn off FP exceptions (https://en.cppreference.com/w/c/numeric/fenv/feholdexcept for the uninitiated) and watch the NaNs or Infs propagate.

Ooh, thanks for that. I wasn’t aware of that possibility – is it obvious that I don’t use floats or doubles much in C…?

It certainly lets the game start up and play, so that probably opens up a profitable line for debugging. As the code works on other platforms, I assume that (unless the exceptions are somehow RISC OS specific, which seems unlikely in standard C) it may be that they can simply be ignored.

That’s all something for another day, however! There’s a lot of maths involved in setting up the game grids, and I don’t feel like trawling through it all right now…

Unhandled exceptions in redraw events don’t help.

It might be that. They occur during the creation of a new game, and somewhere in there there will be VDU redirection as the game redraws itself to the sprite that it uses as a canvas and then later on redraw of the sprite to the screen in a Redraw event.

I’m afraid that the world has moved on since 1987, and BBC BASIC, Zap and StrongED haven’t really followed that closely.

Therein lies the truth of the matter: the world has moved on, and to a large extent I haven’t…I can imagine learning Python to run on the Mac, but how easy is it to handle drag-and-drop, menus & other WIMPy things in Python? How easy is the learning curve for all that? OK, BBC BASIC doesn’t do it terribly friendlily, but I know how to do it, and it’s mostly boiler plate for me.

I’m not trying to sell it to anyone else…but is there any good reason for me to change?

but how easy is it to handle drag-and-drop, menus & other WIMPy things in Python?

Here is a simple GUI example, it’s just an hello-world kind of thing, but gives you an idea how how much it could match the typical BBC BASIC developer logic:

import tkinter as tk

# Create a new Tkinter application
app = tk.Tk()

# Set the window title
app.title("Greeting")

# Set the window size
app.geometry("200x100")

# Create a label widget with your message
message = tk.Label(app, text="Hello Clive!")
message.pack()

# Start the application
app.mainloop()

Just copy and past the above code in a file on your Mac and call it greetings.py or whatever you’d like. then run it with:

python3 ./greetings.py

I am sure there are tons of sites/youtube channels that explain how to write what you need in Python, it’s a very simple language to learn.

Here is an example of a sligthely more useful window with a button to open a filer window and select a file from it and display its name on the main window¹:

import tkinter as tk
from tkinter import filedialog

def open_file_dialog():
    # Open a file dialog and update the label with the selected file's name
    filepath = filedialog.askopenfilename()
    if filepath:
        file_name_label.config(text=f"File: {filepath}")

# Create the main window
root = tk.Tk()
root.title("File Selector")
root.geometry("400x200")

# Create a label to display the selected file name
file_name_label = tk.Label(root, text="Select a file", pady=20, padx=20)
file_name_label.pack(expand=True, fill=tk.BOTH)

# Create a button to open the file dialog
open_file_btn = tk.Button(root, text="Open File Dialog", command=open_file_dialog)
open_file_btn.pack(side=tk.BOTTOM, pady=20)

# Start the Tkinter event loop
root.mainloop()

copy and past this little program on your mac in a file you call it as you want and then run it with:

python3 clive_first_mac_desktop_app.py

So, as you can see, it’s extremely easy. If you add to this that on your Mac you’ll have really hard time to crash it in case of mistakes, you have a ton of helpful resources and even plenty of code on GitHub to either look at or use/integrate with your work. You can see why Python has become so popular.

HTH

¹ You can do proper Drag and Drop, but it requires some library and I’d suggest to start with what is most certainly already installed on your mac ;) – Hence I wrote these uber simplified examples.

I’m not trying to sell it to anyone else…but is there any good reason for me to change?

Clive, based on what you say in your post. No.

But if you are curious about Python on RISC OS, join tonight’s meetup.

Alternatively, there’s Lua, and Gavin has a solid argument for its use on RISC OS.

but how easy is it to handle drag-and-drop, menus & other WIMPy things in Python?

Clive if you are are tempted to to try Python have a go on RISC OS rather than the Mac.
As Paolo says the drag and drop wimpy thingy is fairly easy on on Mac using tkinter.
But you will not be able to run your code on RISC OS because tkinter library has not been ported.
However, thanks to Chris Johns there is a working ToolBox library and good suport for python in StrongED.
You can make a really helpful contribution to RISC OS by using the python we have got.
The number of people actively developing python prorams on RISC OS is 3 or 4 at the most.

Then saith he unto his disciples, The harvest truly is plenteous, but the labourers are few; Pray ye therefore the Lord of the harvest, that he will send forth labourers into his harvest.

Interesting as all that sounds, John, for me the only reason to climb the Python learning curve would be exactly so I could do things on the Mac, the things I can do easily on the Pi with BBC BASIC. I do by far the most of my work on the Mac – if I could do the things I do on the Pi easily on the Mac, it’d save a lot of faffing about.

It wouldn’t make the Pi completely obsolete for me, because I’ve still not got anything on the Mac that I like as much as !Draw or !Zap for what they’re good at. Everything else I do on the Pi is either using apps I wrote myself, or things I can do equally happily on either.