Taskwindow, LineEditor & OS_ReadC

I have been using the LineEditor module v2.76d (03 Mar 2003) for many years, as supplied with Zap, simply for the facility to recall previous command lines entered which I frequently use.

Recently I have noticed that whenever I closed a TaskWindow (even if immediately after opening it), an Abort in Data Transfer error was logged by Reporter, although there was no other evidence of a problem.

The abort is in LineEditor at +&CC0, trying to get a byte from a table that is &1FF long with an offset of &20002744. This often is unreadable storage, provoking the abort. The bad offset is the r0 key value from an earlier XOS_ReadC (as LineEditor provides a replacement OS_ReadLine).

With RO5.24, 5.28 and 5.29 up to 24/11/2020 on my Titanium, and RO5.29 24/01/2021 on RPi3, LineEditor sits in the ReadC waiting for input, but it does not return when the TaskWindow is closed, so no abort.

With RO5.29 07/03/2021 & 22/04/2021 on my Titanium it does return from the ReadC on close, but with an obvious rubbish key value in r0 (and C is clear), usually causing an abort.

I have tried using TaskWindows from Edit, Zap and StrongEd, and killing DeepKeys, and with Alignment Exceptions On and Off – but all with no effect.

I have looked in the ROOL change logs between 24/11/2020 and 7/3/2021 but can see nothing, although that is my main suspicion.

Even though the abort seems to cause no problems, it is obviously a symptom of something wrong. If anyone else has noticed this abort, or has any suggestions of the cause, it would be useful to know!

&20002744 seems like it could be an error pointer. Is V set? Are you able to peek at the location? (preferably by adding extra code to LineEditor, just in case it’s a MessageTrans error buffer that gets reused soon after the abort)

As an address, the example I have points to a value of &A83 (2691) so could be an error number, I suppose, but V is not set, so seems unlikely. The bad r0 may always be &2000xxyy, where yy are &44, but that is based on little evidence.

&A83 is TaskWindow_Dying – so it looks like an error is being returned, but either V isn’t being set or it’s being dropped by something.

https://gitlab.riscosopen.org/RiscOS/Sources/Programmer/HdrSrc/-/blob/HdrSrc-2_94/hdr/NewErrors#L844

Interesting … but I have just had an r0=&20001F44 pointing to &124 (292) … which is the start of the error block for “System variable ‘vncserv_debug’ not found”

Sounds like it could be this.

Thanks Julie – it certainly fits, as here TaskWindow v0.81 is ok, and v0.82 causes the abort. I will look more closely at that change, though currently it is not very clear to me.

The change in TW v0.82 seems to claim that:

This results in error being returned from sleeping SWI calls

but from what I have seen OS_ReadC may now return an error block pointer in r0, but does not set V or C. Should V be set? Or possibly C? Or is that change just the wrong thing to do?

I can get an abort with 0.81 by quitting it from the task manager. It looks like it leaves through CopyError which does set V.

If I do SYS “OS_ReadC” in BASIC and then send it Message_Quit, Reporter shows me error Task Dying. This is 0.81 still, so I think the bug is in LineEditor not checking for the V flag.

I was being misled because I had not read my own documentation on Report_Regs! That clearly states that ‘The V flag will always be shown OFF’. However, on return from OS_ReadC V is certainly ON when a TW is closed with v0.82. It is also on with v0.81 when a TW is quit from TaskManager.

Adding a BVS badreadc after the ReadC seems to fix both problems.
Thanks to Jeffrey and Julie for helping with this.

Now I just have to work out how to make this available to others – Rick has a v2.76e I have found, and Phil Pemberton has a v2.76 on github. What their licensing situation is I am not sure.

v2.76 corrupts R4 in ReadLineV, I fixed that and modified it to support RO3.11 avoiding the use of DA’s. I’m up to v2.78 myself.

If you like I’ll post it on my forum and you can see if it also fixes the problem you’re seeing.

EDIT: There’s also a bug where it breaks OFF in BASIC which I haven’t looked at

@Jon: I will have a look at your version. Mind you, it now seems there are at least 5 versions around: Zap site, Rick, github, mine and yours. Another horrible example of fragmentation.

Zap site and github are pretty much the same aren’t they?

As for Rick, well, I’ll take whichever incarnation works. ;-)

Yes, it is unpleasant fragmentation, but if the alternative is – as happens so very often – the author moving on and the sources getting lost/forgotten/deleted, then I’ll take the fragmentation. Sources that exist can be fixed. Things can be coalesced into a master version should anybody wish to step up as an official maintainer. That’s better than “…”, isn’t it?

Zap site and github are pretty much the same aren’t they?

I’m assuming that the reference to Phil Pemberton means that there’s a forked version on GitHub. The Zap stuff is under James Aylett’s account at present.

Mind you, it now seems there are at least 5 versions around: Zap site, Rick, github, mine and yours. Another horrible example of fragmentation.

Probably one of the reasons that ROOL put “Adopt Zap editor” on the roadmap!

While we are on the subject, can I put in the regular call for Line Editor functionality to be part of the OS!

can I put in the regular call for Line Editor functionality to be part of the OS!

+1
I almost made the same comment last night.
Then cat #2¹ wanted feeding and then #1 and #3, and I lost track somewhere round #2 wanting portion 2

¹ The one that doesn’t try to remove skin during a de-flea session.

can I put in the regular call for Line Editor functionality to be part of the OS!

+1
I almost made the same comment last night.
Then cat #2¹ wanted feeding and then #1 and #3, and I lost track somewhere round #2 want

Anyway, definitely. The functionality line editor has should be in the OS

¹ The one that doesn’t try to remove skin during a de-flea session.

I agree totally that the functions of LineEditor should be part of the OS – it is used every time I use commands, and I find working without it very frustrating. New users probably just expect it to be there!

Another +1. This ought to be standard OS_ReadLine[32] behaviour.

+1 from me as well, command history is basic OS functionality these days.

can I put in the regular call for Line Editor functionality to be part of the OS!

another +1

I love the LineEditor, but does have an impact on how the VDU system works, for example having to press Ctrl-Q to pass on most control characters to the VDU. If you’ve come from the BBC Micro era and remember how to do things such as redefine the palette and set up text windows using control sequences, it does make things more difficult – probably an edge case these days though.

It also gives back on black text in 2 colour modes, but that really only affects !GraphTask which uses a 1 bpp display, as even on the Pi with AnyMode you don’t get a true 2 colour mode.

I love the LineEditor, but does have an impact on how the VDU system works, for example having to press Ctrl-Q to pass on most control characters to the VDU.

I’ve not really looked, but if my memory is vaguely correct there’s a facility for mapping keys, so you could have just the basics active.
Then again, as everyone says it should be in the OS and obviously that implementation would perhaps be more to your liking.

probably and edge case these days though.

Dave, that’s not the edge.
The edge is the bit you can see in the distance when you look toward the Hub mountains. :)