Taskwindow, LineEditor & OS_ReadC
Martin Avison (27) 1479 posts |
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! |
Jeffrey Lee (213) 6048 posts |
&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) |
Martin Avison (27) 1479 posts |
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. |
Jeffrey Lee (213) 6048 posts |
&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 |
Martin Avison (27) 1479 posts |
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” |
Julie Stamp (8365) 467 posts |
Sounds like it could be this. |
Martin Avison (27) 1479 posts |
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. |
Martin Avison (27) 1479 posts |
The change in TW v0.82 seems to claim that:
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? |
Julie Stamp (8365) 467 posts |
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. |
Martin Avison (27) 1479 posts |
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 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. |
Jon Abbott (1421) 2640 posts |
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 |
Martin Avison (27) 1479 posts |
@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. |
Rick Murray (539) 13747 posts |
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? |
Steve Fryatt (216) 2095 posts |
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. |
Chris Mahoney (1684) 2160 posts |
Probably one of the reasons that ROOL put “Adopt Zap editor” on the roadmap! |
Bryan Hogan (339) 584 posts |
While we are on the subject, can I put in the regular call for Line Editor functionality to be part of the OS! |
Steve Pampling (1551) 8125 posts |
+1 1 The one that doesn’t try to remove skin during a de-flea session. |
Steve Pampling (1551) 8125 posts |
+1 Anyway, definitely. The functionality line editor has should be in the OS 1 The one that doesn’t try to remove skin during a de-flea session. |
Martin Avison (27) 1479 posts |
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! |
Rick Murray (539) 13747 posts |
Another +1. This ought to be standard OS_ReadLine[32] behaviour. |
Jon Abbott (1421) 2640 posts |
+1 from me as well, command history is basic OS functionality these days. |
Paolo Fabio Zaino (28) 1821 posts |
another +1 |
David J. Ruck (33) 1585 posts |
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. |
Steve Pampling (1551) 8125 posts |
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.
Dave, that’s not the edge. |