Newsgroups: comp.sys.acorn
Subject: Re: StrongED II version 1.10
From: jwil1@cs.aukuni.ac.nz (TMOTA)
Date: Tue, 29 Sep 1992 02:03:26 GMT
 <1992Sep3.152209.18447@alf.uib.no> <18fvmnINN8kj@frigate.doc.ic.ac.uk>   
 <1992Sep23.123203.10305@cl.cam.ac.uk> <1992Sep23.225752.2310@cs.aukuni.ac.nz> <1992Sep25.000348.22840@infodev.cam.ac.uk>
Organization: Computer Science Dept. University of Auckland

crj10@phx.cam.ac.uk (Clive Jones) writes:

>>Any user with a large text file and an ability to use search and replace.
>>This can take a *long* time, so it'spossible to go and have a cup of tea...

>Hmm. !Edit can't even load a file long enough to cause such problems,
>surely! One of my programs, working off hard disc will happily search
>at hard disc speed, and hence churn through hundreds of kilobytes a
>second - not likely to take very long. But anyway...

Yes, but !Edit isn't ... ah... efficient... like that.
Running on an Arm-2 machine, a search & replace operation can take ages.
A painful experience is bringing several hundred kB of text file onto your
machine from a mac or PC, and finding that it has CRs instead of LFs for
line breaks. Edit treats the *entire* file as ONE line, and is thus *very*
slow.

[lots of discussion about error reporting deleted, which included:]
>Ah. This must be some new meaning of the word "error" of which I was
>not previously aware. (-8  I agree that successful completion of an
...
>Again, not an error - that's a dialogue. Convention dictates that you
...

Yes. Maybe this is the problem. RISC OS applications treat "Tell the user
somethign of interest", "Tell the user they have done something wrong"
and "Tell the user I'm about to die horribly and corrupt their hard drive"
as "errors" that should be reported via the non-multitasking Wimp_ReportError
routine.

IMHO, the *only* errors that you should ever consider using Wimp_ReportError
for are very bad ones (fatal errors). All messages, reports, problems, and
non-serious errors should multitask.

>By errors, I was originally referring to boxes saying things like "I
>don't understand '::ping::' in a search expression", which are user
>errors, and will be in response to user input, while the user is at
>the machine. You seem to be concentrating on software errors. These
>tend to indicate that the machine is crumbling so badly that all
>applications will be affected, or that the individual application is

Even in the case where the error is generated during interaction
("Please do not press that button again"), there is simply NO reason why
the report/error box SHOULDN'T multitask, and therefore (IMHO) there is no
excuse for not making the report multitask.


>buggy - ideally, no application that you're not developing will ever
>present you with a software error, and those that do should just
>report the error and close down. Trying to resume after a software

It is quite conceivable that errors can occur in non-interactive cases.
What if your raytracer runs out of disc space to write its resulting image?
Surely the screensaver shouldn't stop updating the screen, and let that
picture of garfield burn in on the monitor?

And is there *any* reason why the raytracer should *not* multitask? All
it needs to do is *pause* the current operation, and plonk up a mtasking
error box - "Out of disc space: retry/cancel". While the error box is up
all other applications can continue doing their background things, and when
the user gets back to the machine they can (swear profusely and then) make
room on the disc in question (impossible with a non-multitasking errorbox)
and then abort or retry the operation.

If the fact that the disc is full also causes anopther program to fail,
you get another multitasking error box, and that other program pauses
until the user is available to sort out the problem...

When we get to errors (disc full) that the user can fix before the program
continues, the user NEEDS the error report to multitask so that they can
do anything with the machine to fix the problem. But if we go to the
bother of making these error reports multitask, it seems silly to bother
to work out if the error is of a type that should multitask or not.

I can't think of a single non-fatal error that can't be reported in a
non-multitasking way - fatal errors (including errors in redraw handlers)
are dangerous to multitask from within the application, so I feel the OS
should supply the means to report them - currently this is Wimp_ReportError,
but a multitasking version of this would be nice (the task giving the error
is halted but all others continue to run).

With most applications, even fatal errors don't affect other applications.
For example, if a pointer strays off the end of the application workspace,
an abort on data transfer will kill the application, but will have no
effect on the rest of the system.
I feel the error recovery system should assume that the error is localised
and try to struggle on. The idea is that as much of the operation of the
computer should continue unhindered as possible. How many times have you
ever had one program die with an infinite sequence of Wimp_ReportErrors
because of a redraw error? You CAN'T save files from the other applications
you have running, because you can never get away from the error boxes!
However, if they always multitasked, you would only ever have this problem
if the entire machine was brought down.

>Trying to resume after a software
>error is just plain foolhardy, unless you're the developer, in which
>case you can put the application in whatever testbed environment you
>want anyway.

I'm sorry? What do you consider a 'software error'? It is possible for a
bug in the program to cause a very non-fatal and extremely recoverable
error. For example, if you leave a preferences file open by accident,
you might later generate a 'file open' error when trying to write the
preferences. However, after reporting the error, there is no reason why
the application can't continue perfectly normally.

>>>The only exception to the rule is things which can be recovered from
>>>if the user is allowed to intervene. In such cases, multi-tasking is
>>>clearly appropriate. For example, the Filer_Action system under
>>>RiscOS3 has its own multi-tasking "clone" of the Wimp_ReportError box,
>>>which is very handy if you get a file open message while copying
>>>files, for example - you just close the file and click "Retry".
>>
>>Exactly. Why should everything else grind to a halt just because one
>>application gets into strife.

>This thread started off by talking about a text editor. Text editors
>are virtually 100% user-interaction applications. Filer actions are
>almost 0% user-interaction. That's the difference.

So you never get infinite recursion of error boxes from Edit?
(I have - try running out of memory when using a taskwindow. Edit keeps
telling you there's not enough memory for the taskwindow. However, I
believe that (apart from actually fixing the bug) edit could pause the
taskwindow, reporting the error in a multitasking box, and give me a chance to
save my source files, the spritefile I was editing in Paint, etc.)

Just because Edit requires a user to sit in front of it all day is not
a valid excuse for not making error boxes multitask.

The first thing that niggles me about this is that if I have any backgrounded
operation running, it STOPS for the second, seconds, minutes or whatever that
it takes me to respond to the error. WHY SHOULD IT STOP?
It's just a waste of processor time, and it's completely NEEDLESS.
This is a bad thing (not too bad, but still bad) if this is only a case of
1 or 2 seconds each time it happens (what's 4-8 million instructions among
friends?) but I quite often start things off (expand tabs on a 500kB file?)
and then go and get something to eat, and come back 3 or 4 minutes later,
and I find it very annoying to see an error occurred just after I left
the room, and I've now got to sit in front of the computer staring
blankly at the screen for 3-4 minutes while my compile finishes...

>You missed the point. I don't do this so that other applications keep
>running, I do it so that the user can intervene on behalf of my
>application. Again, the user will be at the keyboard, because this
>isn't a background operation.

And you missed the point. Sure the fact that it multitasks means that you
can use the desktop to fix the problem (low on memory).
BUT it ALSO means that everything else keeps running. if ONE program runs
low on memory, it doesn't necessarily follow that ALL programs will be
unable to continue running. And even if they can't, they should all be able
to get as far as possible before they in turn plonk up an error box.

At the very least, you are losing precious CPU seconds of time every time
an error box appears. At the very worst, it's bloody annoying and
extremely inconvenient.

The effort to actually *do* multiutasking error/report boxes is *minimal*.
(I feel I can say this with some authority as DSEdit II does just this, and
it works fine)
And we would have them in all programs now if Wimp_ReportError weren't
so easy and convenient for lazy programmers (no insult intended; I include
myself in this category).

Anyway, please let's not continue this, or it'll become a flame war that
none of us want...
-- 
_________________  "I'd like to answer this question in two ways:
  /____ _ _/_ __       First in my normal voice, and then
 // / //_//_ /_/       in a silly, high-pitched whine." (Monty Python)