Text Editors -- Two Queries

Firstly, has anybody managed to use !Zap successfully on a Raspberry Pi/RO 5.19? I generally prefer it’s handling of C programs to StrongEd but I find it crashes very frequently usually with “abort on data transfer”. In fact it crashes more than any other program I’ve encountered since 1992…

Secondly, how is the default text editor determined? And how can it be changed, short of running the editor in question? Currently, if I have the system “look at” the Acorn C/C++ directory from the DDE (to load the libraries), SrcEdit is the default; if I don’t, !Zap is the default.

I’d like to be able to:

1. have the system “look at” the Acorn C/C++ directories
2. and have StrongEd be the default text editor
3. without either running StrongEd or uninstalling any of the other editors.

Possible? (It would be—and easily too—on any other OS I’ve used where defaults exist at all.)

how is the default text editor determined?

When the Filer sees an application for the first time (eg !Foo) it boots it (ie runs !Foo.!Boot if present). Editors take the opportunity to set an appropriate sysvar which, in this case, is Alias$@RunType_FFF.

Boot another text editor and it’ll change that and take over. That’s just the way it works.

Some editors are more humble and only set Alias$@RunType_<filetype> if it isn’t already set. So one way to solve your problem is change !SrcEdit’s !Boot to be more self-effacing. Since there’s never a case where Alias$@RunType_FFF isn’t set, you could just comment out that line with a vertical bar “|”.

OTOH The Filer only resorts to the sysvars if there isn’t already an application running that responds to the DataRun message it sent… so it is possible to write a small task to enforce your preferred defaults regardless of the state of the sysvars, but that would be unusual.

Firstly, has anybody managed to use !Zap successfully on a Raspberry Pi/RO 5.19?

Yes. Seems reliable for me (though my 5.19 is a few months old). The problem is the Ctrl-Shift-C to launch a compile freezes the machine until I press a letter (but given Angstrom on the Beagle refused to talk to my wonky keyboard, it’s just a good thing it works at all). Can’t blame Zap for a shonky keyboard!

I prefer Zap to StrongEd.

I use Zap for all my editing, but I have found it is now more unstable than it used to be – this is on all of Iyonix, BB, RPi, all recent versions of 5.19. It is worse when editing several pages at the same time. I have a vague feeling it is memory management related, but no hard evidence.

I’ve had many, many cases of StrongEd crashing out on my Pi. Very few actual crash-and-exit type problems, but usually something like list-of-found → boom, address exception. StrongEd will keep running but LOF won’t work anymore until quit/restart. I’ve not been able to correlate the problems with file sizes or number of files open or indeed any particular thing.

Firstly, has anybody managed to use !Zap successfully on a Raspberry Pi/RO 5.19?

Yes, I’m running it here. I’m using the forked version from http://www.tankstage.co.uk/software.html which seems to be more recent than the recent official release. BASIC and Text modes seem to be OK, haven’t tried any of the other modules.

StrongED is behaving very strangely on my Pi. First, when editing a BASIC program, every time I pressed Enter I got a security warning. Managed to edit the configuration files to cure this, but I still get a long pause (complete with hourglass) every time I press Enter while editing BASIC.

I use !Zap on my Pi, exactly as downloaded from !Store.

Firstly, has anybody managed to use !Zap successfully on a Raspberry Pi/RO 5.19? I generally prefer it’s handling of C programs to StrongEd

If there’s anything you’d like to see added or changed in StrongED then by all means get in touch and I’ll see what can be done.

I’ve had many, many cases of StrongEd crashing out on my Pi.

Why not send in bug report? Bugs won’t get fixed unless I know about them and so far I haven’t received any bug reports from you.

Are you running the Pi in ARMv7 mode? If so, make sure you’re using at least StrongED 4.69a4. The latest 4.69b2 would be even better.

StrongED is behaving very strangely on my Pi.

If you suspect something is wrong then please report it so that it has a chance of being fixed.

Some editors are more humble and only set Alias$@RunType_ if it isn’t already set.

Yes, that would be the right thing to do but unfortunately you can’t do that reliably. The reason is that Edit sets up the alias for text files as a macro and trying to do:

If "<Alias$@RunType_fff>" = "" Then [..]

results in an ‘Unknown operand’ error.

The only way to avoid the error is to claim the text filetype outright, as it would be a bit silly for a text editor to not claim that filetype.

Yes, I’m running it here. I’m using the forked version from http://www.tankstage.co.uk/software.html which seems to be more recent than the recent official release. BASIC and Text modes seem to be OK, haven’t tried any of the other modules.

I also use the version of Tank on my RPI. It works but I found that’s is not completely ARMv7 safe. One of the the rotated load emulations (tab placing code for Softwrap) is not correct. I fixed it and sent it to Tank but I didn’t get any reply till now, so this fix isn’t available at the moment.

Ah, I have my Pi in ARMv5 compatibility mode which may explain why Zap is more stable for me.

Fred: you’ve seen my report about StrongED here, do you want me to e-mail you as well?

My experience is with the Beagleboard, not the Raspberry Pi. I’m using the latest downloadable version from Tank. I find Zap is often pretty reliable for a whole evening’s programming, but some days it crashes once or twice, but rarely to the point of actually losing files: if I click “Continue” I can usually save, quit Zap and restart it without serious trouble.

The real annoyance for me is not being able to Alt-double-click to get StrongHelp C or OS SWI pages up. This works very nicely on the Iyonix but on the Beagleboard always results in a crash. I do not know whether the problem is at the Zap or the StrongHelp end, though it might be possible to determine this by examining the Wimp message traffic.

I recently upgraded to the latest StrongHelp in the hope this would be cured. It did improve some things: I can now click on StrongHelp’s iconbar icon without a crash, which helps. I will try to do some more investigation when I have some time and see if I can determine if the Alt-double-click crash is at Zap’s end or StrongHelp’s and then contact the relevant person. Unless someone else already has a solution of course.

The real annoyance for me is not being able to Alt-double-click to get StrongHelp C or OS SWI pages up. This works very nicely on the Iyonix but on the Beagleboard always results in a crash. I do not know whether the problem is at the Zap or the StrongHelp end, though it might be possible to determine this by examining the Wimp message traffic.

It is Zap.

I don’t have StrongHelp running, just tried Alt-doubleclick (on a BASIC keyword) and I got "Zap may have gone wrong. [blah blah etc] with the error “Internal error: undefined instruction at &0000081C”. It is recoverable (Continue works, life carries on).

&81C? That’s way below application workspace. I wonder what’s causing that?

System info:
Zap – Tank’s version “1.48 (16 Sep 2011) tnk-7”; hardware – Beagle xM; RISC OS 5.19 (25-Feb-13). Nothing else loaded other than the usual boot-up stuff.

I also use the version of Tank on my RPI. It works but I found that’s is not completely ARMv7 safe. One of the the rotated load emulations (tab placing code for Softwrap) is not correct. I fixed it and sent it to Tank but I didn’t get any reply till now, so this fix isn’t available at the moment.

Dick, at the moment, I cannot compile Zap with the latest version of the compiler as some of the macros seem to interfere with some of the new instructions added.
When I can reliably do this I will update the download.

The real annoyance for me is not being able to Alt-double-click to get StrongHelp C or OS SWI pages up.

Matthew, I have not been able to find and then hopefully cure this problem, but you can press Ctrl H to get the manual to show as a stopgap.

Fred: you’ve seen my report about StrongED here, do you want me to e-mail you as well?

Yes. please. The long pause you mention surprises me and I’d like to find out why that is, and for that I need to know more about your set-up. Hopefully that will allow me to fix the problem, if not then I can tell how to get rid of the delay.

Matthew, I have not been able to find and then hopefully cure this problem, but you can press Ctrl H to get the manual to show as a stopgap.

Great! That’s really useful to know. Thanks.

@Tank: any news on !Zap? It is far from stable on my Panda a.t.m.

the !Zap source code has macros littered with 26 bit dependencies.. usually to do with setting/clearing flags. How did you get this compiled for 32 bit?

the !Zap source code has macros littered with 26 bit dependencies.. usually to do with setting/clearing flags. How did you get this compiled for 32 bit?

Which source are you looking at? Tank’s mods are here: http://www.tankstage.co.uk/software.html

As for how – sweat, blood, and tears most likely. [note absence of smiley]

My bad, I was not looking correctly at the macros..
There are some instructions with PC and #1<<31 which apparently are not designed to work on status bits but are used to compute a value to set or clear specific status bits :-)

Mea culpa.

Now i still need to figure out how to get objasm to agree to compile it.

Ok with the help of ‘!bash’ and ‘sed’ i managed to change all the following macros:

SEV → SET_V
PUSH → ZPUSH
*RTV → *RT_V

This fixes the compilation of both !Zap and !ZapRedraw on the latest objasm.