Sun, 13 Sep 2026 21:14:35 +0000
BBC BASIC is still a “proper language”, and shouldn’t be too unfamiliar. It’s adequate for a lot of programs.
Coding with LLMs, or notSun, 13 Sep 2026 19:45:33 +0000
Paulo: Thanks for the detailed and eloquently-put explanation. With an awful lot more insight than I have, that’s how I personally feel or, to put it another way, I am learning the old way so that I do learn, do understand and can then update code, which I have had to do as despite being a beginner, my programs (currently built in VBA) are used by coworkers and so I’ve faced having to add features or adjust for changed business logic. Next step for me is moving to a ‘proper’ language and making ‘real’ desktop programs instead of them sitting in Office, which is obviously where things are about to get a bit harder.
Coding with LLMs, or notSun, 13 Sep 2026 19:43:33 +0000
‘Vector chains’ sounds complicated. I’m still on libraries and variables, and even then I think I’m using the term variable incorrectly (name = “Black”, for example). Anyway, it’s been good to get the insight of people who know their stuff.
Wimp path lengthsSun, 13 Sep 2026 19:24:26 +0000
A Message_DataLoadAck (4) is normally a response to the Message_DataLoad (3) message. The blocks of these are a little different from each other.
The Message_DataLoad has the filename, a zero byte, then it aligns to the next four bytes and fills in the column and row in the next two words.
That message data you have listed would fit. In offset 244, it has the last g (from jpg) and the zero. Then there is room for the column number in offset 248 and the row in 252.
For your slightly longer filename (that ends json), the four bytes at 244 contain the bytes for ‘json’, then the first byte at 248 is the zero terminator. We then align to the next aligned word and offset 252 will have the column but offset 256 should have the row, however bytes 256, 257, 258 and 259 do not exist in the 256 block. So perhaps the Wimp (or Filer) is seeing this overflow and not sending the message?
As a potential solution, you could set Dwarf$path on boot up to (include the last full stop): LanMan98::NAS2photo.$.Dwarf.
Now you can open the directory with (include the colon and put this perhaps in an obey file) *Filer_OpenDir Dwarf:
Dragging your file from a filer directory with Dwarf: as the title will send Dwarf:Galaxies. (…) .stacked/jpg which is a slightly shorter filename and the example you gave would fit in the 203 (is that right?) maximum length for message 3.
!RDPClient 0.90 - Scroll Wheel SupportSun, 13 Sep 2026 17:52:02 +0000
I assume these worked previously, I’ll have a look when I get the chance (hopefully tomorrow or Tuesday) as currently renovating the kitchen and just rewiring it at the moment.
Both issues are present in 0.88 so maybe they have always been there.
Coding with LLMs, or notSun, 13 Sep 2026 16:48:34 +0000
@ William
I’ve noticed things are getting worse and worse in terms of stability, and things are frequently launched and then withdrawn when it turns out they don’t work. Things are also connected in ways that boggle the mind, as in one thing can break another but there is no reason for a connection between the two.
Yes, this is the effect of code maintenance when using AI. To explain this also for non-coder readers:
When we write programs, we are actually performing multiple activities at once:
1. Solution design (this is the visible part; people refer to this as feature design)
2. We solve a problem with code
3. We exercise our knowledge of the programming language, the underlying OS/Hardware, and the entire application structure
4. We memorise the details of that code
When, instead, people decide to use vibe coding, and also, to some extent, AI-assisted coding, all we are practising is “design” at best (in the above list, just point 1).
What happens from point 2 onwards is that the AI has made a lot of decisions by itself if we use vibe coding, or slightly fewer if we use AI-assisted development. That is because, in AI-assisted development, we stop at a “smaller unit of work” than in vibe coding, review and change what the AI has done (this is called co-authoring), and then commit, so the AI can start on the next step, but with all previous steps way more under humans control.
BTW, this is why AI-assisted coding is usually better than vibe coding. However, AI-assisted development requires skilled developers, and we do not “leave the system working for 72 hours on its own”. So Andrew’s examples are technically vibe coding, potentially with a coder reviewing the result at the very end of a full development cycle, rather than after each smaller unit of work.
So, in the case of vibe coding, if everything goes well, OK, you get software that works. The AI may also have decided to write the code in a maintainable way and add comments, but again, that is an AI choice that we can influence through our specs (at point 1). The AI, however, is not required to follow those specs to the letter.
If things do not go well, or user requirements change, then we enter the AI hell of code maintenance.
Why might things not have gone well? Besides the more traditional issues with AI, such as hallucinations, the reality with agents is that they are more reliable than GenAI chats because of their internal step-by-step testing. So the actual problems that can occur with vibe coding are:
1. AI hyperfocus on a spec, which can change or influence things in the rest of the code far more than it should.
2. AI context leakage. I described this in detail in a technical article on my blog. This can be caused by the spiralling increase in certain terms, which can unbalance, or more precisely bias, the prediction process, leading to unexpected results. This is normal because AI is not sentient.
3. The AI did not include a specific implied requirement in the process, and things therefore went off track.
In all these cases, what happens is that the amount of understanding of the entire codebase possessed by the vibe-coding user may not be adequate enough to tell the AI what to change and where in the source tree. It may also require substantial changes in certain cases. As a side note, this can also happen with work produced by junior developers, BTW, so it is a known issue in the field.
At that point, the vibe-coding user becomes dependent on the AI and starts cycling through attempts to overcome the issues, while still either giving the AI freedom or providing new guardrails. The risk here is that the AI will focus on fixing one problem and, in doing so, may again make decisions that break other things in the code. The token dance has started.
However, this type of issue only happens when the “scope” is large, while writing small utilities and tools rarely causes these kinds of problems. So, in your case, it seems your team is dealing with a large application and is slowly giving up control to the AI, while the AI has started to struggle with the scope.
Can this happen with AI used for RISC OS? If someone goes off and tries to redesign RISC OS for modern use cases, then yes, they will indeed end up facing these kinds of problems. However, with small modules and tools, I do not think the problem will manifest itself as much as it does in other environments. So I still think AI can be useful to the RISC OS community.
However, and this is where my response is categorically no (for me of course), I would not use any of these AI-based projects to rewrite RISC OS, not even remotely. So, to me, at the moment, the so-called RISC OS renaissance that Andrew has mentioned is based only on Simon’s work.
I know some users here think of my Merlin OS as part of that renaissance, but it is not. Merlin is NOT RISC OS and therefore cannot be listed among RISC OS programs, projects, or anything else intended to save RISC OS itself. Merlin is a modern, professionally designed kernel that can do far more than RISC OS does or can do, and it is compatible with legacy RISC OS only through a RISC OS personality: a subsystem designed to allow Merlin to run RISC OS modules, vector chains, and applications.
!RDPClient 0.90 - Scroll Wheel SupportSun, 13 Sep 2026 15:46:23 +0000
If ‘−u ’ is not specified the user field gets corrupted (NULL pointer dereference?) and it’s not possible to type into the field.
bq. Copy and pasting from the remote to RISC OS produced corrupted data. Mostly NULLs.
I assume these worked previously, I’ll have a look when I get the chance (hopefully tomorrow or Tuesday) as currently renovating the kitchen and just rewiring it at the moment.
Wimp path lengthsSun, 13 Sep 2026 15:34:48 +0000
Thanks Steve. I tried Message Monitor, and the stacked/jpg file gave this (edited for brevity):
Message_DataLoadAck (&000004) [Message]
From ‘PhotoDesk’ to ‘Filer’
My ref: &0B11246F; Your ref: &0B11246B
20 : 201A6A39 : 9j. : 538602041
24 : FFFFFFFF : …. : 1 : 758132781
28 : 0000020C : …. : 524
32 : 00000450 : P… : 1104
36 : 00000000 : …. : 0
40 : 00000C85 : …. : 3205
44 : 4D6E614C : LanM : 1299079500
48 : 38396E61 : an98 : 943287905
52 : 414E3A3A : ::NA : 1095645754
56 : 68703253 : S2ph : 1752183379
60 : 2E6F746F : oto. : 779056239
64 : 77442E24 : $.Dw : 2000956964
68 : 2E667261 : arf. : 778465889
72 : 616C6147 : Gala : 1634492743
76 : 73656978 : xies : 1936025976
[snip]
220 : 2D30302D : -00
224 : 302D3830 : 08-0 : 808269872
228 : 33322D32 : 2-23 : 858926386
232 : 74732E37 : 7.st : 1953705527
236 : 656B6361 : acke : 1701536609
240 : 706A2F64 : d/jp : 1886007140
244 : 80000067 : g… : -2147483545
248 : 000007F6 : …. : 2038
252 : 0000130C : …. : 4876
Reporter 2.74 (01 Aug 2021) Listed 2986 lines
That’s the 201 character path. But the 204-length one gave nothing; no messages appeared at all in the Reporter window. I would have thought it could fit in the buffer, there’s some spare bytes at the end.
(Sorry about the strike-through, don’t know where that came from.)
Sun, 13 Sep 2026 15:31:23 +0000
I have a friend who works as a translator and interpreter. She is more and more seeing clients send her documents that have been translated by machine, asking her to tidy them up and correct any mistakes. They of course expect to pay cheaper rates for this even though it takes almost as long to check a translation carefully as to create one from scratch. That’s taking away the pleasure from the job as well as the reward.
For that kind of thing, I regard the online translation as a useful tool for a non-native English developer to get a first-pass translation of their documentation.
Their talents lie in programming, documentation is likely to a sub-ordinate ability and translation further down the list.
Expecting professional standard translation and involving Artificial Idiocy (Idiot Savant perhaps) is bad logic.
Frankly using it and expecting a cheaper rate for the professionalism is extracting the urine.
Any of us doing a professional job and having to remove mistakes made by someone, or something, without our abilities should be charging extra for removing the mistakes.
Sun, 13 Sep 2026 14:56:11 +0000
Thanks all for the replies. I found that a really interesting read.
I work for a very large company and the number of software engineers is immense. LLMs have been aggressively deployed, and the high number of coders and their use of LLMs is shouted from the rooftops. However, as a user of the systems they write and maintain, I’ve noticed things are getting worse and worse in terms of stability, and things are frequently launched and then withdrawn when it turns out they don’t work. Things are also connected in ways that boggle the mind, as in one thing can break another but there is no reason for a connection between the two. Meanwhile, our old mainframe programs just work, and remain stable even though some are updated to match the business logic very frequently.
I’m consequently heavily biased in that the old ways are best, so was interested in challenging that with this topic. Many thanks again for all the replies.
Coding with LLMs, or notSun, 13 Sep 2026 14:41:05 +0000
“RISC OS: you know it makes cents”. At the time of its release there were quite a few other applications which appeared to be commercially viable still, but if R-Comp cannot make money out of software any more then I doubt anyone else is.
The idea I had to help here was UltimaVM, the bytecode VM, which indeed allows people to code on RISC OS more quickly, while applications can also run on Linux, Windows, macOS, BSD, and obviously RISC OS Merlin too. This gives people who wish to code ON RISC OS and FOR RISC OS a way to reach a much larger market while still enjoying their passion for RISC OS.
The project is still progressing, and I will bring a couple of early high-level programming language compilers to the London Show. The only downside is that, as usual, no one has offered to join the project and help. That is fine, but obviously I am not The Flash.
In any case, as demonstrated at last year’s London Show, UltimaVM brings:
Again, if anyone feels like joining the project, please get in contact, as usual, using my “Contact Me” page. UltimaVM is written entirely in ANSI C99 and builds with both GCC and DDE, so you can work on it using your favourite development environment too.
For those who are not into coding, what does all this mean?
Ultima is not complete yet, so either people join the project and help, or they will have to wait for it to reach release 1.0.
Obviously, progress will be demonstrated every year at the London Show. I may also find the time to make some videos, but work has been really busy lately, so no promises.
On a side note: Steve Revill (at the last London Show) had a really good idea, which is to add UltimaVM as a target for DDE (which is doable, given UltimaVM bytecode is very close to ARM Assembly). That would make it possible to build preemptive apps directly in DDE ANSI C99 etc.
HTH
P.S. kudos to Sprow who helped to fix a bunch of issues on modern DDE to use it to build for 26bit smoothly, which made it possible to have a very nice and optimised build for Ultima that runs all th way down to my Archie 310! XD