Programming IDE for RISC OS (CodeCube Cloverleaf project)
Stefan Fröhling (7826) 167 posts |
I think there is a necessity for a comprehensive programming IDE for RISC OS. For BASIC there exists AppBASIC which is a well designed IDE if you want to program in BASIC. A good example how new programmers struggle you can see in Simon Ayers video: A really good base for an IDE would make !sourcery from A-really-small-software-company by Richard Windley. Sadly he doesn’t answer to his contact form or his email. Does anyone have a direct contact to Richard Windley? (I have his gmail address) We would first base the IDE on GCC as the DDE is not free available. But it should be possible to integrate the DDE at a later stage wihout a big effort. As editor I would try to integrate StrongED in a modified form to make it more compatible to modern text editors. One big issue is also debugging in RISC OS and I would like here to use the new UCDebug which supports ELF files that are produced by GCC. Here is a short incomplete list of features of the IDE Functions of CodeCube Any comments and suggestions are welcome. |
Andrew McCarthy (3688) 605 posts |
Sounds great. I’m currently dabbling in C with OSLib and the ToolBox. I found the lack of a working Vi editor an initial hurdle, settled on Zap (emacs keymap), utilising the TaskWindow and Make-files. As a reference, I’m using “Learn C the hard way”, the Toolbox manual, and I’ve used James Hobson’s videos. Both StrongED and Zap could be better with “out of the box” GCC compatibility. The ToolBox manual is probably great for WIMP experts but not a new starter; it’s hard to find what you need. I guess there are various approaches: |
Rick Murray (539) 13840 posts |
I think what we really need (and thus, impractically unfeasible) is something akin to Visual Basic where the IDE is a complete self contained development system with editor, window designer, menu designer, debugger, etc all within. But not just that, how VB worked was by allowing you to write code for specific “events” (program starting, clicked on this icon, etc etc). All of the underlying grunt work was handled by the environment. I didn’t have to start up the program, load resources, open templates, load each window, define the menus… all that was done automatically. As such, I’ve written several programs for Windows quite quickly, quite simply, and with no idea of the underlying mechanisms of the system. We need something like that. Something where you can attach code to things (like this function runs if I click this icon in this window) with all the boilerplate hidden. Another good thing that VB offered was methods applying to the icons. There was a set of functions, but for doing something like setting the text of an icon, it was something like With something like that, programming on RISC OS will be easy and pleasant and ought to attract some people. Attaching plasters and chewing gum to existing tools is more a crutch. The problem is that we have editors, libraries, and languages that are simple by today’s standards. We’re used to them because we grew up with them, but to others it might seem all a bit Dark Ages… |
GavinWraith (26) 1563 posts |
Anything that makes programming easier for RISC OS is to be welcomed. That said, I am not sure that the IDE idea (one all-singing all-dancing application) fits very well with the idea behind RISC OS (lots of small interworking tools). RISC OS emphasizes the GUI and plays down the use of the keyboard. In my unsteady first steps with Linux I found myself missing StrongED, Zap and even Edit. Where in the Linux world can you find an editor where you can drag and drop selections of text between windows? Or drag a script (Awk, Python, Lua, …) into a window of text to modify that text without recourse to the keyboard? Yes, I know that I am coming at this with a very different perspective – anything that involves use of the keyboard apart from editing text or naming a file seems like a clumsiness. Very few window managers for Linux offer the user any facility for exploiting drags of objects across the screen. It is easy to understand why; in a multi-user system, Alice’s tasks have no right to know what Bob’s are doing. RISC OS has the advantage of a single window-manager. Many IDEs are partly there to offset the graphical disadvantages of a multi-user system. That is why so many Linux applications seem to be recreating the filer for themselves, with inconsistent graphics if they are using different graphics libraries. There have been application-generators for RISC OS since the beginning. Their purpose is to shield the user from knowing about Obeyfiles, and AppBasic is a good example. However, I am not sure that they are doing any favours for newcomers to RISC OS programming. At some point you need to understand system-variables and Obeyfiles; though I grant that the absolute beginner might be happier to avoid them. I am probably too well known for banging the drum for Lua, particularly as a good language for beginners. Like BASIC or Python you can write a program with a text-editor, save it to a file, set its filetype to Lua, and click on it to run it. I think Lua is rather simpler than Python; by design it is not batteries included . Lua has powerful debugging facilities, which have not received the attention they deserve. It may be that I have not done Lua justice in my attempts to promote it as a useful language for RISC OS. Perhaps I have put people off? Anyway, I claim that is a whole lot easier than C or BASIC, and that there are some jobs, data-extraction for example, for which it is particularly suited. |
Dave Higton (1515) 3525 posts |
Before I retired, I used the Microsoft IDE a lot. The built-in editor is a two-edged sword: the tabbing makes it possible to swap quick looks into multiple files, but also restricts the view on the main file being worked on because it only occupies a part of the IDE’s window, and, let’s face it, screens are never big enough to see the part(s) of the file you’re working on with enough context. So it must always be possible for the editor to escape the IDE’s confines and occupy as much of the screen as the user wishes. Context-sensitive lists of auto-complete options are handy, but I’m not convinced that they speed up coding much. Too much time is taken swapping between typing and selecting. They tend to cancel out. |
Alan Buckley (167) 232 posts |
I think the main things I miss on RISC OS are:
I don’t have a preference for if it’s a single IDE or multiple applications. StrongED always seems a pretty good editor, so maybe some sort of plugin that could give StrongED a project wide look at the source files so it knows where to search for things might be possible. |
Rick Murray (539) 13840 posts |
I’m not looking at what RISC OS does, I’m looking at what can be found elsewhere.
I’m my limited experience, RISC OS is one of the few systems to have made any sort of useful drag and drop.
Swings and roundabouts. I would actually prefer the Windows setup (as of XP) if it was consistent. If you’re using both hands on the keyboard, it’s a mental and physical break to leave the keyboard and reach for the mouse to do something simple. To give an example, I’m quite used to the RISC OS drag-select way of selecting text in an editor, but I can’t help but think that holding Shift and using the cursors (and Page Up/Down plus Ctrl) isn’t a more flexible way to select text.
You’re picking specific cases like dragging files around. How about taking a document edited in, say, Notepad++ and pasting it into a website? ^A ^C The first selects the document and then copies it to the clipboard. It’s how I update my blog on Windows and Android. Maybe 2-3 seconds tops. On RISC OS, press F3 to call up the save dialogue, then drag the icon into the browser. It’s how I update my blog on RISC OS. It takes 2-3 seconds to make the shift from keyboard to mouse and locate the pointer… Having to leave the keyboard (and interrupt flow) is a clumsiness.
I don’t get this comparison. The GUI is a viewport to a virtual workspace of the currently logged in user. When it is showing Alice’s tasks, Bob’s shouldn’t appear. The only time they should be seen to exist is if Alice has admin rights…or logs in as Bob.
Frankly, it’s because the filesystem access and drag-drop is shit. The system will provide a generic “save as” box, but the moment you want to add something specific to the program, you basically have to create your own custom dialogue. I have numerous programs on my PC that do this. The problem is that these systems have poor/lousy/pathologically broken drag and drop, so the way to access the filesystem is for every app to have its own “portal” into the filesystem.
Yes, I’ve written one (unfinished) called Seashell (sorry…).
Therein lies the problem. The generator should shield the user from the nuts and bolts of the language. You shouldn’t need to know how a polling loop works until you start to want to do some more advanced stuff. You shouldn’t need to know how to bring up an application and load its resources. The problem with coding on RISC OS is that jumping through all the boilerplate is something we have to look at every time we create an application. I think the Toolbox was a start at making something more higher level.
You have posted some nice little snippets along the way, but I’ll be honest – it looks like random letters and punctuation abuse. I’ve not had the time or brainpower to learn any Lua, so this (found by a quick search) will make sense to you. I don’t even know how to begin parsing it: (getmetatable "").__mod = \ (s, t) => s:gsub ("%$([%w_]+)", t) end Maybe it’s a little too concise? ;-)
I’d say “a debugger” period. You’ll know I’m not a fan of DDT as it’s rather crashy and a real PITA to use. Plus it seems that if you ^C to run a program at full speed until it crashes, it’ll stop and report the crash, but it won’t tell you how you got to that point.
Yes. If it’s a library you don’t use often, or a library that is utter gibberish (like RISC_OSLib), it can be extremely useful to have a prompt for structure elements. It’s either that or rummage around in header files or hope a StrongHelp file exists.
Yes, you see, it’s little things like that which can make a difference.
Because there’s a lot of boring grunt work in getting all the bits talking to each other, and even then it is incomplete (as noted above, pop up prompting of function parameters, structure elements, etc). Little things that make a programmer’s life easier.
There is value in having things integrated. When writing code for the ESP32, I selected what my board was from the UI, picked additional libraries from the UI, then wrote the code in the editor. I did need to fiddle around with pytool and Python on the command line, but that’s because I am still using XP. It was a one-off, from that point on it’s all done through the UI. I give this as an example because around these parts you need to call the compiler and the linker yourself (command line or Obey file) or figure out how to write a MakeFile. Zap/StrongEd will invoke the MakeFile with Sh^C to build the project. Anything else will need more MakeFile magic or more steps. Steve (Fryatt?) has his builds create a ready to upload zip file. I like that idea, but I’ve not sussed Makefiles enough to add such a thing. Are you starting to see the difference between RISC OS and elsewhere? Sure, it’s a lot more powerful the way we do it (one could wonder if Steve’s archive method could be expanded to call wget with a PUT request to directly upload the archive?) but on the other hand it is a lot more fiddling around, and is a lot of work for the typical uncomplicated use case. It’s not particularly friendly.
Hmm, I’ve never used folding in an editor. To my mind, such a thing is an open admission that it doesn’t properly support chapters or sections (text document) or the ability to jump to functions (code).
Haha hahahahahahaha. Okay, wait, you’re being serious. Try interactive in-editor debugging and code tracing. Not in a stand alone program, directly in the editor/environment. VB5 could do this 24 years ago. Another thing to consider is that children’s first experiences with “programming” may well be dragging and dropping named pieces of program together like this: If you’re about the same age as me, you probably learned BASIC. There’s nothing wrong with BASIC (and Edsger Dijkstra can go swivel), but if people are expecting something easy and friendly and they have to contend with what we use…they may decide to just not. I mean DADebug and spewing stuff to vdu are how I do most of my debugging. Not so very different to how I did it on the BBC Micro. There ought to be something wrong with that, you know… ;-) |
Richard Walker (2090) 431 posts |
Well, quite, Rick! I used to use VB6 extensively, and it was miles ahead of anything on RISC OS. The step-through debugging, variable editing and manipulating the program counter, it is easy-peasy to debug. VB6 also included tooltips with comprehensive function prototypes and links to documentation. And the discovering of APIs was super-simple with intelli-sense. And this was all over 20 years ago. There is a bit of catching up to do! This looked interesting, but I have not yet given it a go. I would quite like auto-complete and pop-up help in StrongEd. And a tabbed view, where I can easily snap tabs between different windows and split a window for side-by-side coloured diffs. Oh, and to step through the C source whilst it is running, breakpoints etc. |
Steve Fryatt (216) 2105 posts |
No-one seems to have mentioned source control yet… We need it, badly, with support for at least Git and SVN, and possibly CVS for the masochists. It would also need to handle filetypes in the same way that they’re handled if the sources are edited over on Linux under the GCCSDK (so the usual trick of ,xxx filename suffixes). With that comes the desirability of being able to store BASIC programs as text in the source control system, to enable it to do what it needs to do.
Having VSC look up the parameters for (or even the exact names of) the functions that I need to call is incredibly useful. It’s almost removed the need for documentation.
Yes, that’s me… they also spit out RiscPkg-ready packages, these days, too. It takes a lot of the hassle out of releases and test builds, which is an incentive to actually do releases. :) [For those who are interested, the files can be found here. They’re for use on Linux, within the GCCSDK, though — see my description of my build environment for what that looks like.] |
Steve Fryatt (216) 2105 posts |
The ones that I’ve seen just call the Toolbox SWIs.
Most people would prefer to step through the code that they’ve written in the first instance, seeing the contents of structures, the values of variables and watching execution stepping in and out of loops, if statements and functions. ARM code level debugging is what one does when one has found a compiler bug, or when there isn’t a modern debugger available. |
Steve Pampling (1551) 8170 posts |
Our age group was either past primary/secondary education by the time home computers were common so learning structured languages and “normal” coding was probably a leisure time activity or a tertiary education thing. Ricks pretty picture sums up modern education – no real knowledge of the nuts and bolts. |
Colin Ferris (399) 1814 posts |
Big thing with the built in BASIC – is that does thing right away – and you can use Progs like Druck’s version of Task window for multi tasking. There is a Prog for modifying BASIC so you step through the code – seeing selected variables as you go (26bit at the moment) Big problems comes with Modules ie testing/debugging. AndyS has a magic version of RPCemu that spits out Function names as RO/Prog is running. |
Stefan Fröhling (7826) 167 posts |
Thanks for the valuable feedback all! @Andrew McCarthy I will check out the other libraries and IDE programs. I know also Lazarus as IDE which is the open source successor of @RickMurray
This is exactly what I want to do with the IDE.
Yes that would be my prefered solution also for the CodeCube IDE. (similar Delphi and as you describe VisualBasic)
Yes is excactly how Delphi also worked. For each element there is a set of variables and events that can be accessed easily.
Yes that is the problem in RISC OS that many things are a patchwork or tools and fixes.
That is what I am saying. Looks at the best of all OSs and include them into RISC OS if it doesn‘t oppose what represents RISC OS.
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.
That is one of the many reasons Linux is no alternative for me to RISC OS. Some Linux filers have even no option to change the file type and you must do it in command line mode….what year is this? 2021 or 1985? @GavinWraith About Lua: Well maybe Lua can be also one of the program languages supported by !CodeCube. @Dave Higton Noted! @Alan Buckley
The UCDebug should solve that. Although it was designed for teaching purposes at the moment so we might need to add some features.
This functions can be added.
Yes an overview of all files included in the project/program is one part missing in !StrongEd as it is „just“ a text editor and not an IDE. Also the menu structure needs to be modernized as many option look very „80th-ish“. @DavidS
An IDE provides a „One-stop“ solution of programmers. Install it and start use it.
Hahaha! I am not laughting about you but what you say sounds funny as you are the first programmer that says that they are happy about the debugger environment in RISC OS. Well if you are happy then I am happy too!
I would like feedback from you or more infos about codefolding when the IDE is running already. About BASIC: @Richard Walker
That is exactly what we need to do! @Steve Fryatt
Is source control part of an IDE? |
Andreas Skyman (8677) 170 posts |
In many modern IDEs, yes. Most modern IDEs, in my experience, are also organised around a plugin-structure, so that the user can add functionality for the program language they are currently working on. There are (several) open standards for things like syntax-highlighting and other editor configurations that you could implement if you want to go this route. The alternative, again in my experience, is IDEs geared toward a single programming language and (attempting, with mixed results) doing it well for that use case. |
David J. Ruck (33) 1635 posts |
A debugger for GCC code. Last time I spoke to them, it was only going to be an assembler debugger and they had no plans to support GCC. Has this changed? |
Andrew McCarthy (3688) 605 posts |
;) Basic Meh, so cliched! For new starters, I’d argue that Python should be the focus. C, C++, Lua, Perl and of course Basic should be a supported language, along with other languages that have compiler support. Let people decide which language they want to use. :) Libraries relating to C and C++ .., TBX, OSLib and SharedClib. As we know, the audience for CodeCube might expect different things. A complete beginner, a new user, just an IDE. A beginner familiar with RISC OS, then there’s the Linux or Windows users each will have expectations of an IDE, especially around keyboard shortcuts. Would a Vi, EMACS, Visual Studio and Atom user be able to utilise the IDE without thinking too much about it? Another IDE perspective to consider. Would picking up a book on Coding, then trying to use RISC OS be made easy or a chore? How can that be addressed? BTW I am grateful to those that work on the GCC toolset and associated tools that includes PackMan, FileUtils, Zap and Cppcheck. These tools together have enabled me to use a beginners book on C (LCTHW) without too much effort. Incorporating some other debugging tools GDB, Valgrind and Cppcheck (already available on RISC OS) might be useful. An IDE that could debug code in a virtual environment would be a great asset, especially one with access to the GPIO pins of an RPi. |
GavinWraith (26) 1563 posts |
You are quite right Rick. It is too concise. My problem is that I come across something that I think is neat, and then I blurt it out without sufficient thought for explaining it properly or the impression it may make. In this case (close your eyes now if you are not ready for it :) what does is allow you to put variables prefixed by a dollar sign in a string s so that the string s % t is got by evaluating the variables by looking them up in the table t . It helps to know that gsub stands for global substitution and that the % operator is often called mod ulo. There is no particular reason why I chose the per-cent sign. This is an example of how you can extend Lua’s syntax by using metatables. The first argument to gsub is a pattern that captures (that is what the parentheses do) the variable name part after the dollar sign. Unfortunately, recognizing what patterns mean, needs, like programming in general, a good dose of try-it-yourself.
I have always liked StrongED’s configurability. I have just fired off an email to Fred enquiring whether there is any way of colouring a section of text. IDEs should be able to describe parse-trees. I quite like the way TechWriter can display the structure of a document, using coloured lines down the left hand side; this is a good solution to the problem of identifying nested structures. The trouble is that writing mode files for StrongED has become something of a black art that only a few know. |
Alan Adams (2486) 1149 posts |
I’d love to have that in StrongED’s BASIC mode. It exists in notepad++ in Windows, and is invaluable when writing PHP. |
Fred Graute (114) 645 posts |
@Stefan Fröhling
Something could be written that implements the same features (I did a fair bit of that for AppLua). The main problem is the extensive help system that Joe created, which is one of AppBasic’s greatest assets. @Andrew McCarthy
Could you elaborate on that? I’m sure StrongED’s GCC support could be improved, provided I know what to aim for.
Sorry but I have to disagree with that. Using AppBasic as an example, setting the text for an action button is done by:
Which is way easier than using the Wimp directly; find the button’s text buffer, write a string to it then call Wimp_SetIconState to force a redraw. @Alan Buckley
In StrongED, place the cursor in the name and press c-G (twice if definition is in a different text).
The idea behind StrongED is that all source are loaded into it, hidden (cs-H) and accessed through the List-of-Windows window (c-L). Searching for things is then done in memory (c-F or F2). That’s why there is no directory search built in. I did create an add-on to search in the directory of the current file (c-F11, requires Lua). Just to be clear, I’m only explaining why it currently works the way it does. I’m not saying it couldn’t or shouldn’t be changed. @DavidS
In what way should folding in StrongED – currently the only RISC OS editor that supports folding) – be improved? @Stefan Fröhling
What menu structure would you propose for StrongED? 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. @Gavin Wraith
I don’t have TechWriter so could you load a file, say a Lua script, into StrongED. Configure it to use an outline font and set the size really small, say 3pt. Is that similar to what TechWriter does?
Writing mode files hasn’t really changed over the years. What has changes is the number of mode authors, there are very few left. These days almost all modes are maintained by me. |
Alan Adams (2486) 1149 posts |
That sounds like the way Notepad++ does it, as below: In the PHP case shown, when the cursor is after the opening bracket of a structure the red line is drawn to the closing bracket. The edge marker also shows the same extent. If a closing bracket is missing, the edge marker goes to the end of the document. |
Andrew McCarthy (3688) 605 posts |
@Fred Graute StrongEd and GCC. I create the directories needed and the required subfolders; c and potentially h and o. I write some code and make a Makefile. What do I do next? Click on the Run icon; click on the MakeFile icon? From memory, I gave up because I couldn’t work out how to configure StrongEd’s TaskWindow with enough memory for the compiler to run; you’ve since helped me out with that :) |
Steffen Huber (91) 1953 posts |
Please name a few examples. Then we can compile a list of “source code you should NOT look at when learning how to use the Toolbox”. If used right, the Toolbox can save an awful amount of code. Only for complex UIs you sometimes need to fall back to plain WIMP, and then it is just “as much code as using plain WIMP”, because that’s what you are doing. |
Steffen Huber (91) 1953 posts |
I am constantly switching between developing on RISC OS and developing on Windows. I can certainly say that using a powerful IDE (on powerful hardware, so I don’t care much about the amount of memory used, and it feels really quick for most operations) makes development at least an order of magnitude faster, less error-prone, more efficient. 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). So…most of the things I wrote about above do not even begin to exist on RISC OS, so it is surely not more efficient and not easier. And if these features/tools were available, I could not imagine using twenty seperate tools for those jobs without good integration. Integration – that is what IDEs are all about.
A good start would be an implementation of a LSP client for StrongED. Perhaps 1% of the way to a full IDE. Or to an Emacs clone, the favourite IDE of the bearded Unix devs (or was it vi?) :-) |
Ron Briscoe (400) 78 posts |
@DavidS, As a low life non-coding user of RISC OS I note that you are the only one in this thread Well as a user of software written by the majority of this threads various contributors I As an aside, before making sweeping statements it would be a good idea to check your facts first. Regards Ron. |
Kuemmel (439) 384 posts |
…and exactly here you are completely wrong when it comes to the topic discussed here. Here we have to listen to people who wrote or want to write major apps for RISC OS or on other system. I myself would never need a full blown IDE as I mostly write only my small ARM assembler intro/demo stuff and I’m happy with a text editor and some disassembler so I would never argue discussing here. What was your recent application developement…? |