Mail Archives: djgpp/2001/05/17/12:30:14
--------------097242CCA3E593C224393EC9
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Eli Zaretskii wrote:
> On Thu, 17 May 2001, Michiel de Bondt wrote:
>
> > Strange. What I do is removing the bar of progress asterisks by cprintf ("\b
> > \b")'s
> > Then, I do printf("Some message.\n ").
>
> That is a bad idea. You should not mix cprintf and printf, since they
> use different methods to deliver data to the screen. Simply print the
> message via cprintf.
>
> > The cprintf ("\b \b")'s might be done in a procedure
> > called by an alarm event.
>
> This just adds to complexity. I'd advise against such complex design,
> just to print and remove a message.
>
What do you suggest. I wish to control the frequency of printing progress info:
asteriks
or search path. There must not be to much printing, since that will affect the
speed of
the algorithm. This way the user can determine how many seconds should elapse
between progress prints. I will use the same idea for key reads. Removal of the
asterisks
can be done by another procedure, but the old progress value must be read in
order to get
the right number of "\b \b"'s to be printed. Another solution uses a "\r" instead
of "\b"'s:
I can print "\r", then 79 spaces, then "\r", and then a few spaces again. But do
all terminals
have more than 79 columns?
Besides, not using eprintf in the search procedure is faster, since the compiler
optimizes
the search procedure better then.
>
> > > And what do you want to do with progress indicator and search path? IN
> > > particular, what do you want to do with them if stdout is redirected?
> >
> > I wish them to be printed to the screen.
>
> Then print those with fprintf to stderr.
>
> > > > The program dvips distinguishes console output and
> > > > standard output as well, i.e. it seems so at least. How can that be?
> > >
> > > Perhaps because it prints part of the text to stderr and the rest to
> > > stdout.
> >
> > But can stderr and stdout not conflict since they are both the screen?
>
> No, the device driver takes care of that. In addition, you could use
> fflush to force all data to go out, if you want to be sure.
Best regards, Michiel
--------------097242CCA3E593C224393EC9
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Eli Zaretskii wrote:
<blockquote TYPE=CITE>On Thu, 17 May 2001, Michiel de Bondt wrote:
<p>> Strange. What I do is removing the bar of progress asterisks by cprintf
("\b
<br>> \b")'s
<br>> Then, I do printf("Some message.\n ").
<p>That is a bad idea. You should not mix cprintf and printf, since
they
<br>use different methods to deliver data to the screen. Simply print
the
<br>message via cprintf.
<p>> The cprintf ("\b \b")'s might be done in a procedure
<br>> called by an alarm event.
<p>This just adds to complexity. I'd advise against such complex
design,
<br>just to print and remove a message.
<br> </blockquote>
What do you suggest. I wish to control the frequency of printing progress
info: asteriks
<br>or search path. There must not be to much printing, since that will
affect the speed of
<br>the algorithm. This way the user can determine how many seconds should
elapse
<br>between progress prints. I will use the same idea for key reads. Removal
of the asterisks
<br>can be done by another procedure, but the old progress value must be
read in order to get
<br>the right number of "\b \b"'s to be printed. Another solution uses
a "\r" instead of "\b"'s:
<br>I can print "\r", then 79 spaces, then "\r", and then a few spaces
again. But do all terminals
<br>have more than 79 columns?
<br>Besides, not using eprintf in the search procedure is faster, since
the compiler optimizes
<br>the search procedure better then.
<blockquote TYPE=CITE>
<br>> > And what do you want to do with progress indicator and search path?
IN
<br>> > particular, what do you want to do with them if stdout is redirected?
<br>>
<br>> I wish them to be printed to the screen.
<p>Then print those with fprintf to stderr.
<p>> > > The program dvips distinguishes console output and
<br>> > > standard output as well, i.e. it seems so at least. How can that
be?
<br>> >
<br>> > Perhaps because it prints part of the text to stderr and the rest
to
<br>> > stdout.
<br>>
<br>> But can stderr and stdout not conflict since they are both the screen?
<p>No, the device driver takes care of that. In addition, you could
use
<br>fflush to force all data to go out, if you want to be sure.</blockquote>
Best regards, Michiel
<br>
<pre></pre>
</html>
--------------097242CCA3E593C224393EC9--
- Raw text -