MathGroup Archive 2007

[Date Index] [Thread Index] [Author Index]

Search the Archive

Re: Can't abort a loop with Print inside (V6)

  • To: mathgroup at
  • Subject: [mg83190] Re: Can't abort a loop with Print inside (V6)
  • From: Yaroslav Bulatov <yaroslavvb at>
  • Date: Wed, 14 Nov 2007 04:49:59 -0500 (EST)
  • References: <fhboff$rl7$>

Possible solution might be to have Mathematica suppress outputs
consisting of very many cells.
In other words, if the evaluation produces a million "Print"
statements, it would give "a very large output was generated" and only
show a few of them. Since new cells could be produced in real-time, it
could group excessive cells by time, ie, all cells sent in 0.1 seconds
could be put in the first "a very large output" group, cells after
that would go into second group, etc.

But an even simpler solution would be to give user a throttle option
-- if the front-end receives more than t output cells in 1 second, it
would print something like "further output suppressed" and ignore
kernel output for a few seconds.


On Nov 13, 12:49 am, Bill Rowe <readnews... at> wrote:
> On 11/12/07 at 5:09 AM, b... at (Bo Hu) wrote:
> >This is not about a loop running faster than one could stop it
> >before it ends.  The simple loop runs for quite a few seconds on my
> >Macbook Pro, because of the Print statement.  It appears to be
> >improper synchronization between the kernel and the front end.  More
> >like a misfeature if that's the intended behavior.
> I did not mean to imply the loop would complete sooner than one
> could stop it before it ends. Instead, I was trying to describe
> the case where the time for the to see a key press is to small.
> That is a sufficiently tight loop simply doesn't allow enough
> time for the key press to be seen.
> As far as I know, this has always been present. And I do not
> believe this issue is strictly a Mathematica issue. Any program
> that runs a sufficiently tight loop will see the same behavior.
> I believe the only way Wolfram could prevent this behavior is to
> intentionally place a maximum loop rate. That is intentionally
> add a minimum delay into loops so that there is time to see user
> key presses. And I think this would be more of a problem than
> the current situation.
> --
> To reply via email subtract one hundred and four

  • Prev by Date: Re: negative FileByteCount
  • Next by Date: Re: Compile a Module
  • Previous by thread: Re: Can't abort a loop with Print inside (V6)
  • Next by thread: Re: Can't abort a loop with Print inside (V6)