Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #30343

Re: Reducing cache/buffer for faster display

From Rikishi42 <skunkworks@rikishi42.net>
Newsgroups comp.lang.python
Subject Re: Reducing cache/buffer for faster display
Date 2012-09-28 02:05 +0200
Organization A noiseless patient Spider
Message-ID <686fj9-aql.ln1@murmur.very.softly> (permalink)
References <cmuej9-0ml.ln1@murmur.very.softly> <mailman.1522.1348783807.27098.python-list@python.org> <k42jp3$1nc$1@reader1.panix.com> <mailman.1523.1348785513.27098.python-list@python.org>

Show all headers | View raw


On 2012-09-27, Chris Angelico <rosuav@gmail.com> wrote:
> On Fri, Sep 28, 2012 at 8:25 AM, John Gordon <gordon@panix.com> wrote:
>> Isn't terminal output line-buffered?  I don't understand why there would
>> be an output delay.  (Unless the "\r" is messing things up...)
>
> This is a classic progress-indication case, which does indeed mess up
> line-buffering. The carriage return (and no line feed, done in the
> Python 2 style of a trailing comma) puts the cursor back to the
> beginning of the line, ready to overwrite, and ripe for one of those
> old favorite incomplete overwrite errors - if nFiles monotonically
> increases, it's fine, but if it decreases, the display can get ugly.

True, but that wasn't the problem here. The updates where. Thanks for the
given answer, I'll try it.

The scripts in question only increase numbers. But should that not be the
case, solutions are simple enough. The numbers can be formatted to have a
fixed size. In the case of random line contents (a list of filesnames, say)
it's enough to create an output function that is aware of the length of the
previously printed line, and add enough spaces to the current one to wipe
exess content.


Thanks again for the suggestion.


-- 
When in doubt, use brute force.
                -- Ken Thompson

Back to comp.lang.python | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Reducing cache/buffer for faster display Rikishi42 <skunkworks@rikishi42.net> - 2012-09-27 23:57 +0200
  Re: Reducing cache/buffer for faster display Chris Angelico <rosuav@gmail.com> - 2012-09-28 08:09 +1000
    Re: Reducing cache/buffer for faster display John Gordon <gordon@panix.com> - 2012-09-27 22:25 +0000
      Re: Reducing cache/buffer for faster display Chris Angelico <rosuav@gmail.com> - 2012-09-28 08:38 +1000
        Re: Reducing cache/buffer for faster display Rikishi42 <skunkworks@rikishi42.net> - 2012-09-28 02:05 +0200
          Re: Reducing cache/buffer for faster display Chris Angelico <rosuav@gmail.com> - 2012-09-28 18:08 +1000
            Re: Reducing cache/buffer for faster display Rikishi42 <skunkworks@rikishi42.net> - 2012-09-29 02:31 +0200
      Re: Reducing cache/buffer for faster display Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2012-09-27 21:46 -0400
        Re: Reducing cache/buffer for faster display Rikishi42 <skunkworks@rikishi42.net> - 2012-09-29 02:20 +0200
          Re: Reducing cache/buffer for faster display Hans Mulder <hansmu@xs4all.nl> - 2012-09-29 14:32 +0200
          Re: Reducing cache/buffer for faster display Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2012-09-29 14:12 -0400
    Re: Reducing cache/buffer for faster display Rikishi42 <skunkworks@rikishi42.net> - 2012-09-28 02:15 +0200

csiph-web