Hi Juergen, Looking at ^C would really be helpful. All I can tell you is that, while experimenting with display of large objects, IBM APL 2 had no delays in any situation. GNU APL had large delays before starting to display. You probably know better than I why.
Thanks. Blake On Mon, Jul 21, 2014 at 5:33 AM, Juergen Sauermann < juergen.sauerm...@t-online.de> wrote: > Hi Blake, > > unfortunately the rules for APL output are such that you cannot "print as > you go". > > For example before printing the second item in the first row, the first > column must have > been formatted completely in order to know the width of the first column. > > I will see what I can do for aborting the formatting process or the > printout with ^C. > > /// Jürgen > > > > On 07/21/2014 11:57 AM, Blake McBride wrote: > > 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 >>>>> > >>>>> >>>>> >>>>> >>>> >>> >> >> > >
