Yasuo Ohgaki wrote:
There is cons also. Users may be looking the file
with tail...
this user will most likely *expect* line-based output
--
Six Offene Systeme GmbH http://www.six.de/
i.A. Hartmut Holzgraefe
Email: [EMAIL PROTECTED]
Tel.: +49-711-99091-77
--
PHP Development Mailing List
I'm not a big fan of doing things the smart way. How hard is it to just
set ob_implicit_flush() on and off? If you want it off, just set it off
(or on, as the default ends up set) at the head of your script.
George
On Wednesday, October 23, 2002, at 04:11 AM, Kristian Koehntopp wrote:
On
Not to be snarky, but I for one would prefer PHP to behave like PHP. ;)
Without having to make everyone here sort through the commit messages,
can you briefly list out the proposed changes?
George
On Wednesday, October 23, 2002, at 02:26 AM, Yasuo Ohgaki wrote:
I thought it's obvious choice,
George Schlossnagle wrote:
Not to be snarky, but I for one would prefer PHP to behave like PHP. ;)
Without having to make everyone here sort through the commit messages,
can you briefly list out the proposed changes?
Oops. Sorry, I forgot.
It's about flushing output every output statement.
On Wed, Oct 23, 2002 at 03:45:42PM +0900, Yasuo Ohgaki wrote :
Oops. Sorry, I forgot.
It's about flushing output every output statement.
SH and current CLI does fflush() on stdout with
echo A
while others don't.
And this setting cannot be changed by php.ini.
User has to pass -D
That statement about character devices being line bufffered isn't quite
true, but otherwise I would say +0. Line buffering stdout and
unbuffering stderr seems to be the default of most languages.
On Wednesday, October 23, 2002, at 02:45 AM, Yasuo Ohgaki wrote:
George Schlossnagle wrote:
On Wednesday 23 October 2002 08:26, Yasuo Ohgaki wrote:
I thought it's obvious choice, but it seems it's not.
Which one you prefer CLI behave like
SH
or
PERL/RUBY/PYTHON
It would perhaps be easier for us to understand if you explained what problem
On Wednesday 23 October 2002 09:41, Edin Kadribasic wrote:
OTOH, having implicit_flush turned on makes writing interactive command
line programs easier. Some programs (like pear installer) might even depend
on it.
The proper way around this, as I see it, is to flush at the end
Edin Kadribasic wrote:
Doing flush after each output operation does carry a performance penalty. The
following example illustrates it:
php -d implicit_flush=0 -r 'for ($i=0; $i100; $i++) echo $i;' file
This one executes about twice as fast on my machine compared to php with
Edin Kadribasic wrote:
OTOH, having implicit_flush turned on makes writing interactive command line
programs easier. Some programs (like pear installer) might even depend on it.
It may, but the current implementation is broken as I
mentioned in other mail.
I don't argue
Hartmut Holzgraefe wrote:
Edin Kadribasic wrote:
Doing flush after each output operation does carry a performance penalty. The
following example illustrates it:
php -d implicit_flush=0 -r 'for ($i=0; $i100; $i++) echo $i;' file
This one executes about twice as fast on my machine
Ok. Let's agree that the current implementation is not ideal, but it works.
There were already several suggestions on how this can be improved, but I
don't think this is the right time to start doing it.
So my proposal is that Yasuo reverts his patch until 4.3.0 is branched and
then let's have
Edin Kadribasic wrote:
Ok. Let's agree that the current implementation is not ideal, but it works.
There were already several suggestions on how this can be improved, but I
don't think this is the right time to start doing it.
So my proposal is that Yasuo reverts his patch until 4.3.0 is
On Wed, 23 Oct 2002, Yasuo Ohgaki wrote:
Edin Kadribasic wrote:
Ok. Let's agree that the current implementation is not ideal, but it works.
There were already several suggestions on how this can be improved, but I
don't think this is the right time to start doing it.
So my proposal
On Wednesday 23 October 2002 10:55, Yasuo Ohgaki wrote:
Edin Kadribasic wrote:
Ok. Let's agree that the current implementation is not ideal, but it
works. There were already several suggestions on how this can be
improved, but I don't think this is the right time to start doing it.
So
Derick Rethans wrote:
On Wed, 23 Oct 2002, Yasuo Ohgaki wrote:
Edin Kadribasic wrote:
Ok. Let's agree that the current implementation is not ideal, but it works.
There were already several suggestions on how this can be improved, but I
don't think this is the right time to start doing it.
On Wed, 23 Oct 2002, Yasuo Ohgaki wrote:
Yes, since it should not set in php_cli.c.
It's a lot confusing, bad thing to do with current code,
inefficient, bad default, etc.
It's a very good default like Zeev explained in
http://news.php.net/article.php?group=php.devarticle=89976
What
Edin Kadribasic wrote:
Since your commit has a potential to break some programs that PEAR depends on,
I still think that you should revert your patch. And I think that it should
stay that way for 4.3.0.
I'll take a look just few days, then.
If PEAR is depending on the line, some people
At 11:21 23/10/2002, Yasuo Ohgaki wrote:
2. in the script with ini_set()
I've pointed out _MANY_ times that PG(implicit_flush)
is INI_SYSTEM|INI_PERDIR
That's a valid point. Note that you can still change it using
ob_implicit_flush().
However, it should be changed to INI_ALL so that it
On Wed, 23 Oct 2002, Yasuo Ohgaki wrote:
Edin Kadribasic wrote:
Since your commit has a potential to break some programs that PEAR depends on,
I still think that you should revert your patch. And I think that it should
stay that way for 4.3.0.
I'll take a look just few days, then.
Do
I thought it's obvious choice, but it seems it's not.
Which one you prefer CLI behave like
SH
or
PERL/RUBY/PYTHON
--
Yasuo Ohgaki
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
21 matches
Mail list logo
