ROOL Forum: Recent posts

Sun, 20 Sep 2026 17:59:05 +0000

And there have also been a number of instances of malware being submitted to the Arch User Repository (AUR), which just goes to show that you cannot trust that individuals submitting code to an open-source project are behaving honestly.

Once again, though, malware or other nefarious code is not the same as copyright infringement.

Sun, 20 Sep 2026 16:25:25 +0000

I currently am writing some code for an app which should allow to get a quick help on specific procedures saved into Sourcery via Zap. I am using Wimp_TransferBlock to get to a Zap title window, but it doesn’t work, I always get an empty buffer. Here’s my code:

====================
gWT_blk
% 256

getWindowTitle ; r0 = Zap window handle, r1 → my buffer for title, r2 = buffer length

Push “r0-r4,lr”

MOV R3,R1 ; ready for
MOV R4,R2 ; Wimp_TransferBlock

ADR R1,gWT_blk
STR R0,[R1]
Orr r1,#1 ; don’t return icons
SWI Wimp_GetWindowInfo
Bic r1,#1

LDR R0,[R1]
BL getWindowTask
; now r0 = source task handle
LDR R1,[R1,#76]
; now r1 = source task address (→ window title)
LDR R2,taskhandle
; r3,r4 already set up
SWI Wimp_TransferBlock

; following for debugging purposes only
MOV R0,R3
MOV R14,#0
STRB R14,[R0,ppP_titlestrlen-1]
BL reportValueAndString
B exit;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

Pull “r0-r4,pc”
====================

I strongly suspect Zap’s blocking these sorts of transfers – but I’m not sure.
What can I do?

Any help warmly welcome!

Cheers,
Walter Lo Nigro

Sun, 20 Sep 2026 16:17:28 +0000

libglib*

Note the * — !Locate accepts wildcards.
This should track down any instances of libglib… on your machine.

It seems that on my Pi 3, I didn’t install !Iris from PackMan, but updated an earlier version using the link on the Iris home page.

I think it’s probably trying to set up !Python3 — in order to use !DeBrown3 — that has caused this. None of the other !DeBrowns use anything to do with glib or the standard UNIX library.

[On the Pi3, running updated RISC OS Direct (RO5.31) there isn’t a copy of libglib… inside Python3 ­— but there is inside Python2… ]

Sun, 20 Sep 2026 16:10:39 +0000

@Doug:

Is this why well known repositories end up with malicous code in them as they are trusted or am I dream that this doesn’t happen.

I don’t know what you were meaning, but there have quite a few instances of malware on the Google Play Store. And there have also been a number of instances of malware being submitted to the Arch User Repository (AUR), which just goes to show that you cannot trust that individuals submitting code to an open-source project are behaving honestly.

Sun, 20 Sep 2026 16:06:46 +0000

I agree with David Ruck – AI tools are not at all equivalent to compilers.

There are some similarities:

• They are both computer programs that generate other (lower-level) program code.

• The code that they produce might not be understandable to the person running the program.

It’s quite true, of course, that given the same input, a compiler will always produce the same output. There isn’t any guarantee, however, that it will echo exactly the intent of the programmer if it an optimizing compiler — as many are.

Gavin, I don’t know whether you’re an academic in computing — but I was for over 20 years, most of it spent teaching programming. I used to find that students made mistakes that other people probably wouldn’t. Compilers might be more reliable now, but I’ve encountered:

In 1990, a Fortran compiler (nominally Fortran 77, but with non-standard additions) that crashed on being presented with a perfectly valid (though unusually structured) program. It turned out that the program was crashing the optimizer, and when that was turned off the program did compile.

Another case involved a C++ program that behaved completely differently to what the student had programmed. This turned out to be another compiler oddity:

1. The student had mistyped the name of the main() function.

1. Despite this the compiler and linker produced an executable file, without giving any warnings.

1. It turned out that in these circumstances, the executable program started by running the first function found in the file — which wasn’t the (mis-spelled) main function.

Those two compilers were both running on VAX/VMS. But I’ve also encountered this C++ code on more than one occasion:

char name[80]; cout << "Enter your name:"; cin >> "name";

Note the double quotes round name in the last time. At the time when this occurred, both gcc and Visual C++ would compile this without an error message (neither does now). Depending on the optimization level set, this code could result in the string literal name being changed to a different value if it appeared in other parts of the same program…

The main difference with LLMs is that part of the input — the training data — is not under the control of the programmer. But where did the compiler writer get his knowledge of the code to generate from?

Sun, 20 Sep 2026 15:56:22 +0000

Add to that: what file name would I be looking for?

Sun, 20 Sep 2026 15:55:32 +0000

Some time ago, I did some tests using B, G, and R the results are good, for a reason that has to do with the color, you chose blue which is the complementary color of yellow, but debrown is not a pure color and we must therefore take into account the two other components R and G.

The program is inspired by yours. I didn’t have time to make a version that corresponds to the work you did with Compo. To do
A Compo version with settings, with sliders, to test!!!

Sun, 20 Sep 2026 15:54:31 +0000

The question in my mind is why the version I was using of !Iris has now stopped? The implication is that I do have a copy of the relevant library file somewhere on my machine, but that setting up !DeBrown has banjaxed being able to find it! So will !Locate find it?? If so, what then do I do with it?… copy it to somewhere else?… if so, where to?

Sun, 20 Sep 2026 15:23:31 +0000

@Andrew: The ROOD source has not been added. I must have installed Iris from the updates link on this machine (I definitely installed it from PackMan on the Pinebook Pro).

However, I can’t get PackMan to update its lists at the moment…

@Chris: That explains it. There appear to have been many issues with riscos.info in recent times—it would be a good idea if ROOL could have independent copies of package lists etc. so as not to depend on it. How achievable this would be, I don’t know.

Sun, 20 Sep 2026 14:39:40 +0000

The domain riscos.info doesn’t seem to exist at the moment.

http://packages.riscosopen.org/packages/pkg/programs-armv5 points to riscos.info.

Sun, 20 Sep 2026 14:28:19 +0000

Well, I’d suggest using !Locate (you can install it from !Store)

Or from PackMan, or even direct from https://www.stevefryatt.org.uk/risc-os/locate if that's easier.