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". > Try ⍳100000 That should be able to print as you go - IBM APL does. Right now there is a significant delay - that I presume is unnecessarily using a significant amount of memory to hold the formatted string. Of course, you still can't ^C out of that either - but that's a different matter. I understand that in many situations you must format the whole thing before you can can see how it lays out. But that is not true in cases where it clearly doesn't fit (like ⍳100000) and many, many cases where it is too large to have a reasonable format. Those are the cases when print-as-you-go can be done and would be without delay, and save significant memory - and hopefully easier to interrupt. Thanks. Blake > > 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 >>>>> > >>>>> >>>>> >>>>> >>>> >>> >> >> > >
