Re: [Bug-apl] Can't break out of the middle on a display operation

[Peter Teeson]

In Sharp APL (IPSA) we had a "panic int" which interrupted whatever was being 
computed after a predetermined time.
It was inherent to the interpreter because we ran a timesharing system.
I don't recall the exact details but it went something like this;

1) Workspace gets swapped in for execution and is given a quantum of CPU time
2) At the end of that quantum a second but quite small (relative to the normal 
) additional amount of CPU was allocated 
 to see if that would allow an interrupt at a "suitable" point in the 
function/operation that was going on.
3) If that extra time was not sufficient the workspace was arbitrarily 
interrupted and AFAICR the user got )CLEAR WS.

That's probably not exactly correct (I never read the actual assembly code for 
that part of the interpreter).
But the idea worked for us.

On a single user system there is no real need for a specific quantum; the OS 
takes care of  scheduling.
But perhaps a "panic int" concept in some form or other might be useful?
Perhaps allowing the user to decide if they want to continue? 
Perhaps with a default value? Perhaps assignable by the user?

respect…

Peter

On 2014-07-08, at 1:50 PM, Blake McBride <address@hidden> wrote:

> If I do:
> 
>       z←⍳1000000
> 
> the operation is very fast.  But if I do:
> 
>       ⍳1000000
> 
> it is very slow, presumably because it is formatting the whole thing for 
> display.  No problem.
> 
> The problem is that during its effort to format for display, I cannot use ^C. 
>  ^C appears to work fine in normal situations - but not during the format for 
> display time.  During format-for-display time ^C is ignored.
> 
> This caused me a problem when I accidentally mis-typed something.  The 
> mis-type caused something very large to be displayed.  In fact, it was so 
> large that my machine started paging.  I was unable to use ^C to stop it.  
> After waiting an hour, I had to kill the process and loose my work.
> 
> Thanks.
> 
> Blake
>