Dear Juergen, I don't think that really solves the problem because:
A. You have to remember to set it - and then to set it only to get around what amounts to a bug - not being able to hit ^C B. Whatever you set it to, you still have a problem with lengths that approach that length. C. What if you are not in development, the user types a very large number accidentally in response to a prompt, the program dies and tries to display the arguments. You end up with a hung program that no one can interrupt. I don't understand why you have to format the whole thing before printing anything (which is what I presume because of the long delay). Presumably hand-in-hand, I don't understand what you can't catch ^C there too. Thanks. Blake On Mon, Jul 21, 2014 at 4:47 AM, Juergen Sauermann < juergen.sauerm...@t-online.de> wrote: > Hi Blake, > > I guess the proposed solution for both was ⎕SYL. Like: > > * ⎕SYL[27] ← 10000* > > /// Jürgen > > > > On 07/21/2014 12:26 AM, Blake McBride wrote: > > Are my two items below a dead issue? > > Thanks! > > Blake > > > On Tue, Jul 8, 2014 at 9:58 PM, 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 >>>> > >>>> >>>> >>>> >>> >> > >
