Yeah, and neither would Jürgen. Seems like I was in the minority on that one. :-)
Regards, Elias On 9 July 2014 11:10, Blake McBride <blake1...@gmail.com> wrote: > I wouldn't do that! > > > > On Tue, Jul 8, 2014 at 10:01 PM, Elias Mårtenson <loke...@gmail.com> > wrote: > >> I suggested some time ago that very large data sets shouldn't be >> displayed at all, since they are not only slow, they are also largely >> useless in an interactive session. >> >> It was decided that this approach would not be taken, but I don't >> remember the justification for it. >> >> Regards, >> Elias >> >> >> On 9 July 2014 10:58, Blake McBride <blake1...@gmail.com> wrote: >> >>> I think the layout function need two modifications: >>> >>> 1. enable ^C >>> >>> 2. at least for large data, output as you go rather than format the >>> whole thing and then output the whole thing >>> >>> --blake >>> >>> >>> >>> On Tue, Jul 8, 2014 at 9:27 PM, Elias Mårtenson <loke...@gmail.com> >>> wrote: >>> >>>> There is already the SIGINT signal which is processed by GNU APL to >>>> interrupt a function execution. However, this interruptability is not >>>> extended to the layout function. >>>> >>>> >>>> On 9 July 2014 09:09, Peter Teeson <peter.tee...@icloud.com> wrote: >>>> >>>>> 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 <blake1...@gmail.com> 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 >>>>> > >>>>> >>>>> >>>>> >>>> >>> >> >
