Hi,
not so. I implemented ⎕SYL[⎕IO+26;] for that case. Just try:
* ⎕SYL[⎕IO+26]←2000
⍳1000000
...*
/// Jürgen
On 07/09/2014 05:11 AM, Elias Mårtenson wrote:
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
<mailto:blake1...@gmail.com>> wrote:
I wouldn't do that!
On Tue, Jul 8, 2014 at 10:01 PM, Elias Mårtenson
<loke...@gmail.com <mailto: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
<mailto: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 <mailto: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
<mailto: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 <mailto: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
>
