Any plans to have an open source toolchain to build RISC OS?

I’m assuming that you and Dave spotted the avatar?

Avatars are meaningless to me – a bit of decoration that seems to have no serious point. What about this avatar is special and should have meant something?

I apologise if I caused offence by expressing my opinion.

No offence taken. It just seemd an extraordinarily negative thing to say in a first posting. Clearly it is I who should apologise; and I do so.

It was more Dave’s “Looks like a troll who is about to get his account deleted” that I objected to. I was under the impression that Dave had account-deleting permissions purely for the purposes of deleting obvious spam; I didn’t realise he also got to decide who was trolling on our behalf.

I do have those permissions for that reason. In most cases, postings that shouldn’t be here are clear to see, in which case the postings and the accounts get taken down immediately. Occasionally the position is not clear; this was one such case, which is why I did not delete either the posting or the account. My comment was to alert people in case it was a troll; the information kinda gets shaken out in following postings. I was mistaken, and I’ve already apologised.

(I also sometimes tidy things up, such as deleting duplicate postings. Recently I saw what should clearly have been a blockquote but the space was missing.)

And, once done, it can’t be changed.

Now there is an extraordinarily negative thing to say. Once done anything can change, so long as there’s something that the older code can still use. A good example of this would be the floating point module by… was it Warm Silence?… that passed the FP operations to the FP unit in the x86 coprocessor in the RiscPC.

Think about that for a moment. It will have trapped the exception. Worked out what to do, set up whatever was necessary via the Diva chip to get an entirely alien architecture to perform the operation, retrieved the result, packaged it up to look like the FPA, then returned back to the caller who never knew the difference.

Other more extreme examples are any emulator ever written.

As long as the API looks the same, everything can change.

a bit of decoration that seems to have no serious point

My European Union flag would beg to differ.

It just seemd an extraordinarily negative thing to say in a first posting.

Clearly somebody who has had more than their fair share of being bitten in the ass by ServiceCalls, TaskWindow, etc etc. ;-) Some parts of the OS are nitro glycerine.

Oh the up side, it gave us something to talk about on a lockdown weekend. I mean, not a lot else to do, right? ;-)

As long as the API looks the same, everything can change.

It’s one of the things that is important regarding a possible future Territory system (one that works). It should be designed with a new API that reflects what is actually possible without all the dumb assumptions or dependencies (so probably best to completely ignore the likes of Keyboard and Alphabet in favour of something that uses standardised codes and recognises that Dvorák isn’t a country and Cornish is a valid identity that some might want to have understood).

However, and this is very important, there must also be a shim that bodges the new style into something that looks like the current method, and translates old style codes and options into new method ones. Because at the moment of release of the new API, pretty much nothing will be using it. If it proves to be useful, some stuff will adopt to while other stuff will refuse (because “older systems” [*]) and some stuff simply won’t be updated any more. So the existing API must always be supported even if/when something better comes along.

* - Something of a perennial problem with the platform. Unlike Linux, Windows, Android, etc where there is impetus and a push to get people upgraded to recent/new versions, and the old is quickly left behind; here in RISC OS land it would be considered rather extraordinary to seemingly arbitrarily cut out a swathe of users. For my recent game, as an example, it runs nicely on a Pi2 and that is it’s intended sort of platform.
However, I also had to consider machines of the RiscPC era (and their inherent limitations) and slower emulators on older hardware. While this wasn’t particularly difficult, the problem with consciously supporting quarter century old machines is that one cannot really use any of the more up to date API features as older machines won’t have them.
Somewhere a line needs to be drawn, but where, and to what benefit? That’s the question.

It is interesting to see memory management and wimp programming in BASIC being discussed yet again. I recognised these as problems in the last century and it was why I started on Basalt, which first saw a proper release in 2003. That already had very flexible memory, with blocks and arrays that could be resized and deleted. It also had full support for the Toolbox, which could be used in an object oriented manner. The wimp polling required just one keyword: POLL. ;-)

Just now, almost certainly for my own amusement only, I am working on a set of pure BASIC libraries to provide a full object oriented system to include the Toolbox, but also any other classes. This approach makes the actual !RunImage very short and sweet. If you download my Crunchie you can see a very early version of Oobi used for the front end, but I have moved on from that. ;-)

Now there is an extraordinarily negative thing to say.

You may contardict that later on…

As long as the API looks the same, everything can change.

We’re specifically talking about the rather weird (to the uninitiated) way that BASIC handles local variables. In many senses, the undesirable bit of it is the API, so it won’t change. It’s why ABC isn’t BASIC.

In the more general sense: of course, that’s one of the reasons why you modularise big stuff into small chunks. :-)

What about this avatar is special and should have meant something?

The style looked quite familiar, and when I checked, it turned out to be exactly the symbol used somewhere else. Which suggested that “Charles Ferguson” was most likely a pen name: either of someone specific, or of someone who wanted to pretend that they were someone specific.

It’s why ABC isn’t BASIC.

That alone is a subject for an entirely different discussion. ;-)

I’m led to believe that RiscBasic handled this correctly, though I’ve never used it myself (and sadly it never made the transition to 32 bit).

I’m inclined to think that the problem here is not a flaw with BASIC’s API, but a limitation in ABC’s implementation. Like how it still can’t cope with GCOL r,g,b or string$()="" etc etc, and only recently learned how to deal with mixed case (or lower case in my experience) hex (I’m guessing it tried parsing it itself rather than passing the string to the OS routines?).
The
A problem in one thing doesn’t necessarily invalidate the API. ;-)

That said, does it not make sense that LOCAL values are passed to children of the function containing the LOCAL? BASIC only really has two levels of scope, LOCAL and everything else. So if a function calls a function that uses the same variable, one or the other will need to be offered.
That also being said, in a language with poor scope, using a global and then defining the same variable name locally and then using it again in a sub procedure without explicitly passing it as a parameter? That’s madness. I’d run in horror from code like that.

was most likely a pen name

And happens to match a filmmaker, writer, and software entrepreneur.
http://cferguson.com/blog/

We’re specifically talking about the rather weird (to the uninitiated) way that BASIC handles local variables. In many senses, the undesirable bit of it is the API, so it won’t change. It’s why ABC isn’t BASIC.

Perl had dynamically scoped variables. It still does. But now you have the choice of how to use them (`local` vs `my` vs `our`). And it’s still Perl.

Use feature flags. Use a different token. Use a pre-processor to keep the same underlying system and just change how the user uses things. Basalt, which Mr Drain mention, proved that you can do this. Same goes for the issue of long strings. The multitude of patches on to the BASIC assembler show that you can modify it to do other wacky things. You /can/ change the behaviour, and yes, you have to be careful, but there’s almost always a way to make it happen.

Otherwise, you have a mine left lying around. That code path you didn’t test; the error handler that was taken which inadvertantly changed a variable you didn’t know could change there.

Because of course, we all have unit tests for our BASIC code, don’t we? We all run those unit tests with TRACE enabled so that we can check that we’re actually covering the code we think we are, don’t we? And we all run those automatically so that we can check that we’ve not regressed, don’t we?

No?¹ Because those things are hard, and the system doesn’t make it easy to do those things. If people are using BASIC in anger², then it’s a development area that should be looked at.

¹ Maybe people do; the only real BASIC I’ve written in the past 13 years was to hack some code to fix silly bugs last month, so I don’t really know. Seriously, speak up, because code coverage in BBC BASIC would actually be cute, and I’d be interested to see.

² Pun not intended, but it amuses me.

you have a mine left lying around.

It happens…though most people wouldn’t pick the thing up and take it home. That’s just nuts.

https://www.ouest-france.fr/normandie/caen-14000/pres-de-caen-lors-d-une-balade-un-homme-trouve-une-mine-antichar-et-la-ramene-chez-lui-6817895

The style looked quite familiar, and when I checked, it turned out to be exactly the symbol used somewhere else.

Indeed, but I rather got the impression that one was broken.

It happens…though most people wouldn’t pick the thing up and take it home. That’s just nuts.

Hmm

1. Many people say I’m rather like my father.
2. As child in the war my father collected shrapnel from bomb sites. He kept the collection under his bed, which didn’t please my grandmother when she discovered the collection included two incendiaries in prime condition…
3. Age 14, or thereabouts, I made explosives/ You know that old trick with (old-fashioned) match heads and two bolts and a nut? Very nearly gave a whole new meaning to “shot his bolt”

That also being said, in a language with poor scope, using a global and then defining the same variable name locally and then using it again in a sub procedure without explicitly passing it as a parameter?

I remember trying to make sense of the Maestro source, which uses lots of variables with very vague names (such as X% and x% and GP% and GPx%, etc), some of which are global, and some of which are local but are used in a long hierarchy of sub procedures, so that it was sometimes genuinely difficult to see where things were defined and what they were supposed to do. I came away thinking that using local variables in long cascades of sub procedures wasn’t very helpful, at least for readability. I still tend to think that if a variable is important enough to be used by a number of different procedures, then it’s usually better to make it global and define it somewhere obvious, and keep local variables, by and large, for use within single procedures. (Though the most helpful thing in the Maestro case would have been to give the variables, local or global, some semi-meaningful names to start with :) )

Which suggested that “Charles Ferguson” was most likely a pen name

I am now even more embarrassed, because I now remember being, shall we say, somewhat surprised when I saw the email address attached to the name when he registered.

Let down by my increasingly fallible mamory.

Mr Ferguson, I apologise again!

The thing here is, Peter H pops up every now and then to raise his hobby horse, but I’ve never seen any useful engagement on asking why things haven’t changed. It’s just stamping feet and a few insults.

I can’t comment for Peter, but the purpose of my post was to point out that there are differing perspectives when viewed from outside. The danger with the RISC OS community is there’s a slight tendency towards groupthink in that the people who are happy with the status quo are those who stay, and the people who aren’t happy tend to leave. So there ends up being this self-reinforcing thing that everything is just fine because it suits the people who it’s just fine for, even if that view becomes increasingly divergent to that of people viewing from outside.

In this case, I was citing the relatively rough edges in terms of development. People assume this is about IDEs, but actually it’s more about ecosystem. On Linux, there’s some standardised ways to build software: make, cmake, autoconf (among others). There are thousands of useful libraries (too many to cite here). There are standardised ways to install tools and libraries: apt install libfoo-dev. There are debuggers: gdb, lldb. There are profiling and introspection tools: Valgrind, AddressSanitizer, strace. There are higher level languages: Python, Rust, Haskell, Node, Go (all of which have good library ecosystems). All of these help with improving productivity and building software at scale, with the result that more functional software can get built faster, by fewer people. The result is a virtuous circle: the ecosystem improves because all these tools exist that make it easier, and good tools help developing even better tools.

For the record, I think the scheme where the DDE is available for free to people who apply for it is a good one. It removes the barrier of cost, and reduces the friction needed to participate for committed newcomers. However it still deters casual newcomers (and most people are casual to begin with), and it isn’t a good look for an open source operating system not to be buildable with open source tools.

There are bigger problems out there TBH. But we should at least admit it’s a problem, as opposed to saying things like ‘I don’t mind paying £50 for basic tools’ because not everyone thinks like you.

Many people say I’m rather like my father.

People used to say I looked like him. Then they said I looked like my mother. Hmm…

Except one person who commented on how much my mother looked like me!

collected shrapnel from bomb sites.

I have some big ass bullets around here someplace. From a chain mounted gun. They came from the Falklands. Originally, not all were spent bullets. Mom took them apart and removed the gunpowder, after delivering an epic bollocking that the neighbours enjoyed overhearing. ;-)

Age 14, or thereabouts, I made explosives

Being at boarding school I missed on that rite of passage.

I made up for it a few years later, though. A cannibalised supercharged firework carefully built out of several large regular fireworks. I stuck the wooden pole firmly into the ground, lit the touchpaper, then moved hastily away.

And learned very quickly that the wooden support pole goes up with the firework. Or not.

It was a very very satisfying explosion. On a little island in a lake, which henceforth was referred to by people as “ring island” or “doughnut island”.

Somewhere around here – 426C+57 (paste that code into Google Maps). I don’t see it, but the route… follow the canal under the motorway, turn beside the pub, cross the railway… I don’t recall there being quite that many lakes. But, then, this was something like 27 years ago.

Some thoughts on the commentary here… which boils down to – what the user wants is key, and if the user is expected to be a developer, development tools and the ability to use the system reliably is what you need to provide…

—

I may be one of those people who makes things with their bare hands… Lovingly crafting the tools that I need – sometimes from scratch, sometimes using parts from elsewhere – building them into what I can and what I need. It took me a long time to build a collection of the tools that I needed, and the knowledge of how to use them properly, within the system. Not everyone will want to do that, and making it easier to do makes a lot of sense.

You’ll never entice anyone to RISC OS because it’s better than what exists elsewhere. It’s different in so many ways, and limited in so many more, that you’re not going to pull people in because it’s got some killer feature. What you will get are people who are interested in those differences, and in the way that it isn’t as locked down as other systems. You can poke around, and replace ungodly chunks of the system, or subvert it in ways that other systems don’t let you. But you do also need the tooling to be able to do that sort of thing.

The issue is generally wider than that of the DDE, although that was the original topic. I don’t know if a debugger has been produced which works with RISC OS, but the system itself doesn’t lend itself to that sort of thing, because you cannot easily trap the system and still have the system works – a problem with a monolithic system which has no process management or isolation. There are other things that are needed to make the system useful to people. People come in with the intention of playing with the system, then make it possible for them to do that in the way that they want to – if that means being able to twiddle GPIO and poke at hardware, then that’s awesome, because the low level bits are there for them to do that.

There are some cute things that people have done to make that possible in ways that aren’t making the alien RISC OS system get in the way – RiscLua, ARMForth spring to mind as implementations that let you do fun things in languages that people appreciate and can use in a relatively friendly way. Python too, and Chris’s making good progress there. Someone made comment about the way that we had StrongHelp back in the day, but beyond that there’s been nothing else. What’s significant for the discussion there is that StrongHelp wasn’t built by the people producing the tools, but externally – they had a need and they wanted to so they built it.

Embrace the things that people produce, enable them to do that, by making things possible. If it needs to be funded, or license restrictions prevent more wide dissemination, as may be the case with DDE, then that’s a barrier but that’s the world that we’re in – there are people who work on those problems behind the scenes, like Andrew and others, trying to bring things to the fore. Back in 2006 (ish – might have been a couple of years either way), I saw a wonderful demo that someone sent me a copy of a XML/CSS browser they had been playing with which was awesomely fast and looked good. It wasn’t something to displace stronghelp, but it could have been so cool, and was better than my port of Mozilla, and smaller than Netsurf. Zap and StrongEd were (probably still are) good editors, but they lack a lot of features that I rely on in my editor today (and they have more features than I can build into the current editors, too, don’t get me wrong). Few other editors offers the same kind of cuteness as throwback did (the ‘recognise strings in the output’ doesn’t count in my opinion, useful though it may be).

I built JFPatch because I needed a way to make it easier and quicker for me to be able to build modules and patches. It was my need, and I thought it was useful to others, and released it that way. JFPatch-as-a-service makes me chuckle. It runs RISC OS dynamically in the cloud, captures the output and supplies it to the user, just so that I can run JFPatch (or whatever). It may be a tool that nobody wanted, but it’s a way to achieve something that could not be done. Compare that to the ‘JavaScriptServiceList’ module, which was a way of trapping RISC OS interfaces (vectors, SWIs, events, services, etc) and using a scripting language to debug them. A tool for a need – highly niche, but if the tooling isn’t available to do these things, people will build it. Looking at small things that people produced, the Doggysoft SysLog was an amazing boon to those of us who needed a way to trap things off a system, and my implementation was a pale shadow of that. It helped me at a time when otherwise it had been suggested that I use The Missing Link (‘TML’), or the smaller DebugIt module implementations – that’s an example of other tooling that was not made available to people. Why does the ‘DiagnosticDump’ module exist? Because it wasn’t possible to easily debug when things go wrong, and if I’m seeing problems, then other people will have problems too.

It’s one reason why I wrote tools like Addr, the DiagnosticDump system, SysLog’s networking support, the previously mentioned JavascriptServiceList, and there’s a module around here from 3.1 that annotates who allocated RMA chunks so that you can find leaks when they exit or identify who owns a block when something went wrong. I don’t know if my updates to DDT ever made it back into the mainline, but they were useful if rather primitive by today’s standards. These things exist (for me) and some are public. Clearly other people have different issues if they don’t need these sorts of things (or don’t have the ability to build them themselves, maybe).

For tooling, having a debugger is great. Having to work without one forces you to attack things differently. Having an operating system that is fragile means that testing is harder, because the system under test is liable to take out the test system. But even more important is having the attitude that if you feel pain, others will, so try to address that.

What is the top developer want (outside of RISC OS) – the ability to be able to test what you’ve done and have confidence that what you’ve done works. In modern development that means testing frameworks and CI to exercise and report on them. Maybe that’s biased by my day to day job (I develop and maintain build systems, test infrastructure and CI for a company producing a reverseable debugger), but you can give people terrible systems and they can work with them… but without the means to be sure that you’ve actually produced something that works and will stay working, you’re working to the competencies of your developers and trust that they are doing good things. Modern tooling such as Gitlab allows reviews to be performed online, but it can never catch everything – you need multiple levels of review and testing to work well with things. Automated testing and CI is key to ensuring that systems are reliable, and themselves produce tools that developers can use in powerful ways.

JFPatch-as-a-service is a step in CI that I’ve made available publically. It’s a very small offshoot of the rest of the RISC OS CI pipeline that I use for my own development.

Regarding encouraging users and developers to do things well, if you build your tools to be tested, you can introduce testing and CI to a system. That’s not impossible to do on legacy code (there’s whole books on how you introduce this), but it’s harder if you don’t have a will to do so. It’s the reason that parts of the Filer, the Wimp, and the Kernel (probably other areas – I forget) are written in C. I’ve written elsewhere about this, so I won’t repeat myself, but all those C routines were written in an application environment, and tested before they saw the inside of those modules. ISTR that the code in the Kernel was actually written and tested entirely on Linux and only when it was working was it integrated into the Kernel. And when it’s built, the tests are built with it, and they check that we’re doing the right things. The extra Toolbox Window gadgets and objects I created were originally Toolbox applications, and can be built as such – testing then happens in the ‘safe’ environment of a task, not the scarey world of Toolbox filtering. Not everyone will ‘get’ that kind of working, but if it’s there in the way that developers work in general (in the OS code, or in guidance) then people will be able to use it.

Regarding BBC BASIC…

BBC BASIC as it stands isn’t a good language for people to use, but it’s what you’re offered largely for RISC OS. That so many people try to defend it as a good environment (my past self included) is strange, as it’s hobbled many good developments. If you can’t use something from BASIC (or, heaven forbid, raw assembler), it’s not a good RISC OS interface. That hobbles a lot of development, but that is one place to sigh and move on because those are the users you have to cater for, and you ignore them and you ignore your entire mission statement. Improvements in BASIC would go a long way to aiding that situation – if you have to use it, it might as well be better. I’d tried to add direct linkage with C code (vaguely successful but very unfinished), and the ability to write modules directly in BBC BASIC (‘works’ but very explodey), and called it a day. Matt Godbolt (people may know better as the author of ‘Compiler Explorer’ and the JavaScript BBC emulator) wrote IRClient, with the need to for a scripting language, and created an object-oriented BBC BASIC variant – yes it’s not exactly BASIC V, but that sort of thing might avoid damaging people quite so much if they must use BASIC. There are similar improvements in the BBC Basic 4 Windows, and I was interested to hear what Mr Drain has been doing with his object oriented work. Other stuff would be good – backtraces in BASIC, variable examination, code coverage tracking, heck even a debugger to interact with it…

I would expect that my knowledge of RISC OS is woefully outdated given my absence from any RISC OS things for some years. I cringe thinking back to a very naive, younger, me sitting in a meeting room in Pace and trying to say how much of the system is not suitable for use by professionals outside the RISC OS world without knowing those ancient interfaces and their history, and how the lack of stability and functionality should be given a focus. I find myself of a very similar opinion now, and it makes me feel that maybe I hold on to how felt then about the way that RISC OS was, and haven’t updated my understanding of that world with anything that may have happened since. I have a suspicion that whilst that may be true of me, the reality is that the feeling is not wrong – things haven’t really changed in 20 years.

—

That might be a bit rambley. I wrote it over the course of the day, so sorry if none of it is useful to anyone. Just my opinion.

the way that it isn’t as locked down as other systems

That encapsulates my love of RISCOS, just as simple as that. But I’m not making huge apps; I’m making simple* apps to do fairly straightforward things that are painful or expensive or impossible to do on other platforms. Oh, and I like the way that Draw works, better than anything I’ve come across on other platforms. (Even expensive apps I’ve had to use at work, that can do anything you want – once you’ve climbed their learning cliff. And generally still with tediously bad user interfaces.)

*For some possibly non-standard meaning of the word, but certainly not on the major scale some folk are talking about.

This thread has somewhat deviated from the original question, but I think it’s been a useful one.

I think Charles makes a good point in that RISC OS doesn’t have any big ‘killer app’ draw for people. We’re not going to take over the world .. not yet anyway calling SWI Global_Control still tells me SWI name not known. :)

If we are to get people interested in the platform (and those who are interested to stay around) they need to be able to do what they want. This is part of the reason I started to port the newer python – it’s a language I use a lot in the ‘day job’ and find I can be very productive with it. It’s something that RISC OS didn’t have, so is set about porting it. Of course some of the more obvious RISC OS differences (the use of types rather than extensions and . as a directory separator) do cause a fair bit of work, although at the moment my main headache is running a subprocess with redirection to/from pipes. Yes there is PipeFS, bit it’s finickety at the best of times!

RISC OS does put you “close to the metal” a lot more than other systems. The good thing about RISC OS is it doesn’t lock you down.. the bad thing about RISC OS it it doesn’t lock you down. Perhaps the cooperative mutlti-asking is one example of this. You won’t get control taken away from you, so you have to “play nice” in a desktop environment.

So yes, RISC OS is different. We could change to a pre-emptive system, and we could change file types to extensions, the directory separator to / and various other things – but then it wouldn’t be RISC OS would it?

As to BASIC – I think some of that is because it was largely the only choice at least to start with. Once you start you build up an investment in that so there is a reluctance to just start again, and it’s “just this one limitation to work around” – which adds more investment and a higher reluctance to change. The sunk cost fallacy, I guess.

So .. what do we want “tools!” .. when do we want them … “now!” … what tools do we want? .. “umm… good question.”

Other stuff would be good – backtraces in BASIC, variable examination, code coverage tracking, heck even a debugger to interact with it…

add the ability to trap when and where a variable gets changed, preferably including if it’s due to memory being overwritten. !Reporter does a lot, but doesn’t go quite that far.

And in BASIC itself, the “undefined variable” message ought to show the name of the undefined variable.

@Alan: Have you checked out the *ReportMon command in Reporter?

I am just looking into start programming C on RISC OS and what I am missing most is:
– IDE or at least some form of code completion so that when you type the first letters of an SWI then the full SWI name is suggested (is there something that does this?)
– more toolbox gadgets, I miss one for HTML rendering and one for spreadsheet like tables
– and I am missing some kind of RISC OS developer event / workshop. I could imagine a weekend once a year where experienced programmers meet people interested in programming and/or learning something new. I feel it is often hard to get started, e.g. set up DDE to compile RISC OS or to write your own “Hello World” application in lua, C or python for example (thanks by the way for the new python port!) or to learn how the RISC OS code is organized.

I am not sure if SWI completion could be added to StrongEd? You’d need whatever provides the SWI to be loaded, but that would seem to be fair enough. A logical step from there would be to be able either just “complete” the SWI, or go to the corresponding StrongHelp page, if one exists.

A RISCOSDev conference? I guess the issue would be where to hold it, unless it was ‘virtual’. I’m guessing we don’t need to look at hiring the O2, but putting it on would incur an expense and folks would need to fund that and plus travel. Some of us would need to negotiate “time off” from home too (that’s probably the hardest part :))

I am not sure if SWI completion could be added to StrongEd?

Yes, it could. In fact, it’s already been done. :-)

The latest test version provides support for auto-completion and insertion templates. Both help to write code faster.

My most used mode (next to BasAsm of course) is AppBasic which makes using the Toolbox from BASIC much easier by providing veneers for Toolbox methods. To make entering these veneers faster I wrote an add-on that presents a menu of the relevant methods.

The trigger is cs-Space (c-Space is for regular auto-completion) after a couple of letters from the gadget name are entered. To get completion for the Button gadget you’d enter “but” .

This will bring up a menu with all methods for the Button gadget. Use up/down keys to select the one to enter and press c-Return. The veneer for the method will be inserted as an insertion template with the first parameter selected ready for you to enter the variable to use. Pressing Tab moves the selection to the next parameter, and so on.

For example, selecting the GetValue method would insert the following with the first parameter ‘object%’ selected:

Alternatives to c-Return are Return which just enters the method/event name and s-Return which enters the raw SYS call (for when the veneer is too restrictive).

Regular auto-completion still has an ‘issue’ and that’s deciding which source(s) to generate auto-completions from. At the moment it does a search through all loaded texts for matches, and each mode can have a Complete file containing a list of completions (eg SWI names). There may be cases where other schemes are more suitable, suggestions welcome.

@Fred That sounds very good, is it possible to download the test version or do you have an estimation when it will be released?

@Chris Of course at the moment such a conference is out of question. Maybe it could be combined with a RISC OS show, so DEV day on Saturday and show on sunday or vice versa.

Regular auto-completion still has an ‘issue’ and that’s deciding which source(s) to generate auto-completions from. At the moment it does a search through all loaded texts for matches, and each mode can have a Complete file containing a list of completions (eg SWI names). There may be cases where other schemes are more suitable, suggestions welcome.

I recently discovered that in the non-RISC OS world, IDEs are slowly standardising on the use of “Language Server Protocol”, which helps to remove a lot of the language-specific logic from IDEs (autocomplete, “go to definition”, etc.) and places it in reusable plugins instead. Might be something to take a look at, if you’re feeling like a challenge! (communication between the IDE and language server is using HTTP / JSON-RPC, so in theory you could prototype it by having StrongED talk to a language server running on a Windows/Unix machine)

https://microsoft.github.io/language-server-protocol/
https://langserver.org