[PHP-DEV] Re: [PHP-CVS] cvs: php4 /main output.c

[Sebastian Bergmann]

Zeev Suraski wrote:
> zeevMon Sep 23 10:18:43 2002 EDT
>
>   Modified files:
> /php4/main  output.c
>   Log:
>   Fix bug #19525


echo 'test';

  now prints in HEAD

Cannot use output buffering in output buffering display handlers

  as it already does in the 4.2.3 release.

  How am I supposed to catch the result of an eval() command inside an
  output buffer?

  A possibility would be to change the behaviour of eval() and let it
  return an array with both output and return value of the evaluated
  code.

-- 
  Sebastian Bergmann
  http://sebastian-bergmann.de/ http://phpOpenTracker.de/

  Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: [PHP-CVS] cvs: php4 /main output.c

[Sebastian Bergmann]

Yasuo Ohgaki wrote:
> yohgaki Mon Sep 30 22:43:33 2002 EDT
>
>   Modified files:
> /php4/main  output.c
>   Log:
>   Fixed implicit flush.

  This commit broke my script, that I mentioned before, again. It now
  dumps the contents of a variable to stdout instead of writing it to a
  file.

-- 
  Sebastian Bergmann
  http://sebastian-bergmann.de/ http://phpOpenTracker.de/

  Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: [PHP-CVS] cvs: php4 /main output.c

[Yasuo Ohgaki]

Sebastian Bergmann wrote:
> Yasuo Ohgaki wrote:
> 
>>yohgaki Mon Sep 30 22:43:33 2002 EDT
>>
>>  Modified files:
>>/php4/main  output.c
>>  Log:
>>  Fixed implicit flush.
> 
> 
>   This commit broke my script, that I mentioned before, again. It now
>   dumps the contents of a variable to stdout instead of writing it to a
>   file.
> 

A little history. When 4.1.0 (or 4.2.0?) is released, I've fixed
crush with deleting wrong buffer with implicit flush. The fix
disabled implicit flush.

I finally fixed implicit flush. Users should worry about
implicit flush directive in php.ini now. e.g. implicit_flush=Off
for normal use.

Apparently, CLI SAPI implicitly enable implicit flush at
initialization no matter what the php.ini setting is. CLI behavior
is wrong, since there is no way to change implicit flush directive
once script is started. I notified this to Edin and he would address
this issue soon hopefully.

--
Yasuo Ohgaki


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: [PHP-CVS] cvs: php4 /main output.c

[Yasuo Ohgaki]

Yasuo Ohgaki wrote:
> A little history. When 4.1.0 (or 4.2.0?) is released, I've fixed
> crush with deleting wrong buffer with implicit flush. The fix
> disabled implicit flush.
> 
> I finally fixed implicit flush. Users should worry about
> implicit flush directive in php.ini now. e.g. implicit_flush=Off
> for normal use.

Implicit_flush is changeable SYSTEM or PER_DIR.
If it is enabled, PHP will _always_ flush implicitly.

ob_implicit_flush() uses output_globals, so it can be changed
in anywhere in script. However, ob_implict_flush() cannot turn off
implicit_flush set in php.ini. It works independently.

--
Yasuo Ohgaki




-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: [PHP-CVS] cvs: php4 /main output.c

[Yasuo Ohgaki]

Derick Rethans wrote:
> On Wed, 2 Oct 2002, Marcus Börger wrote:
> 
> 
>>helly Wed Oct  2 11:10:11 2002 EDT
>>
>>  Modified files:  
>>/php4/mainoutput.c 
>>  Log:
>>  Modified get_status(): Display chunk_size allways and size which is in
>>  most cases initial_size as well as block_size only when used.
> 
> 
> Can you please re-test things regarding to this? I reverted Yasuo's 
> commits and I might have overlooked something.
> 

What kind of diff you are using?
I guess you are willing to revert my patches, but you don't.

BTW, stop breaking things. All should be working as used be
(except a little difference) before your commit.

--
Yasuo Ohgaki


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /main output.c

[Marcus Börger]

At 15:45 02.10.2002, Sebastian Bergmann wrote:
>Yasuo Ohgaki wrote:
> > yohgaki Mon Sep 30 22:43:33 2002 EDT
> >
> >   Modified files:
> > /php4/main  output.c
> >   Log:
> >   Fixed implicit flush.
>
>   This commit broke my script, that I mentioned before, again. It now
>   dumps the contents of a variable to stdout instead of writing it to a
>   file.

It also breaks my testcases, too.

marcus


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /main output.c

[Alan Knowles]

Yasuo Ohgaki wrote:

> Sebastian Bergmann wrote:
>
>> Yasuo Ohgaki wrote:
>>
>>> yohgaki Mon Sep 30 22:43:33 2002 EDT
>>>
>>>  Modified files:
>>>/php4/main  output.c
>>>  Log:
>>>  Fixed implicit flush.
>>
>>
>>
>>   This commit broke my script, that I mentioned before, again. It now
>>   dumps the contents of a variable to stdout instead of writing it to a
>>   file.
>>
>
> A little history. When 4.1.0 (or 4.2.0?) is released, I've fixed
> crush with deleting wrong buffer with implicit flush. The fix
> disabled implicit flush.
>
> I finally fixed implicit flush. Users should worry about
> implicit flush directive in php.ini now. e.g. implicit_flush=Off
> for normal use.
>
> Apparently, CLI SAPI implicitly enable implicit flush at
> initialization no matter what the php.ini setting is. CLI behavior
> is wrong, since there is no way to change implicit flush directive
> once script is started. I notified this to Edin and he would address
> this issue soon hopefully. 

Is it worth adding a note to the output control page
http://www.php.net/manual/en/ref.outcontrol.php and/or ob_start to say
"Note: When upgrading from PHP 4.1 (& 4.2) to 4.3 that due to a bug in 
earlier versions you must ensure that implict_flush is OFF in your 
php.ini, otherwise any output withing ob_start, will be not be hidden 
from output"

or something similar?
(at least it will be documented, even if nobody reads it :)

Regards
Alan

>
>
> -- 
> Yasuo Ohgaki
>
>




-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /main output.c

[Yasuo Ohgaki]

Alan Knowles wrote:
> Yasuo Ohgaki wrote:
>> A little history. When 4.1.0 (or 4.2.0?) is released, I've fixed
>> crush with deleting wrong buffer with implicit flush. The fix
>> disabled implicit flush.
>>
>> I finally fixed implicit flush. Users should worry about
>> implicit flush directive in php.ini now. e.g. implicit_flush=Off
>> for normal use.
>>
>> Apparently, CLI SAPI implicitly enable implicit flush at
>> initialization no matter what the php.ini setting is. CLI behavior
>> is wrong, since there is no way to change implicit flush directive
>> once script is started. I notified this to Edin and he would address
>> this issue soon hopefully. 
> 
> 
> Is it worth adding a note to the output control page
> http://www.php.net/manual/en/ref.outcontrol.php and/or ob_start to say
> "Note: When upgrading from PHP 4.1 (& 4.2) to 4.3 that due to a bug in 
> earlier versions you must ensure that implict_flush is OFF in your 
> php.ini, otherwise any output withing ob_start, will be not be hidden 
> from output"
> 
> or something similar?
> (at least it will be documented, even if nobody reads it :)
> 

Done :)

--
Yasuo Ohgaki


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /main output.c

[Derick Rethans]

On Thu, 3 Oct 2002, Yasuo Ohgaki wrote:

> A little history. When 4.1.0 (or 4.2.0?) is released, I've fixed
> crush with deleting wrong buffer with implicit flush. The fix
> disabled implicit flush.
> 
> I finally fixed implicit flush. Users should worry about
> implicit flush directive in php.ini now. e.g. implicit_flush=Off
> for normal use.
> 
> Apparently, CLI SAPI implicitly enable implicit flush at
> initialization no matter what the php.ini setting is. CLI behavior
> is wrong, since there is no way to change implicit flush directive
> once script is started. I notified this to Edin and he would address
> this issue soon hopefully.

Can be, but implicit_flush is documented like this (which is correct):

implicit_flush  boolean

FALSE by default. Changing this to TRUE tells PHP to tell the output 
layer to flush itself automatically after every output block. This is 
equivalent to calling the PHP function flush() after each and every call 
to print() or echo() and each and every HTML block. 

It says totally NOTHING about output buffering issues. This change also 
breaks internal functions:


'foo'

(While it should not have dumped the contents at all). Please revert 
this, as this breaks backward compability BIG time, and IMO this is not 
a shortcoming of CLI. BTW, where did you get that implicit_flush should 
disable all output buffers?

Derick

--

---
 Derick Rethans   http://derickrethans.nl/ 
 JDI Media Solutions
--[ if you hold a unix shell to your ear, do you hear the c? ]-


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /main output.c

[Edin Kadribasic]

On Thursday 03 October 2002 09:14, Derick Rethans wrote:
[snip]
> (While it should not have dumped the contents at all). Please revert
> this, as this breaks backward compability BIG time, and IMO this is not
> a shortcoming of CLI. BTW, where did you get that implicit_flush should
> disable all output buffers?

I was also under the impression that implicit_flush was not supposed to turn 
off all the output buffering. CLI turns it on implicitly to allow interactive 
applications even when output buffering is enabled.

Edin

--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /main output.c

[Yasuo Ohgaki]

You are the one used unexported php_ob_* function in var.c :)
I'll fix var.c, then.

--
Yasuo Ohgaki


Derick Rethans wrote:
> On Thu, 3 Oct 2002, Yasuo Ohgaki wrote:
> 
> 
>>A little history. When 4.1.0 (or 4.2.0?) is released, I've fixed
>>crush with deleting wrong buffer with implicit flush. The fix
>>disabled implicit flush.
>>
>>I finally fixed implicit flush. Users should worry about
>>implicit flush directive in php.ini now. e.g. implicit_flush=Off
>>for normal use.
>>
>>Apparently, CLI SAPI implicitly enable implicit flush at
>>initialization no matter what the php.ini setting is. CLI behavior
>>is wrong, since there is no way to change implicit flush directive
>>once script is started. I notified this to Edin and he would address
>>this issue soon hopefully.
> 
> 
> Can be, but implicit_flush is documented like this (which is correct):
> 
> implicit_flush  boolean
> 
> FALSE by default. Changing this to TRUE tells PHP to tell the output 
> layer to flush itself automatically after every output block. This is 
> equivalent to calling the PHP function flush() after each and every call 
> to print() or echo() and each and every HTML block. 
> 
> It says totally NOTHING about output buffering issues. This change also 
> breaks internal functions:
> 
>  $str = var_export ("foo", TRUE);
> ?>
> 'foo'
> 
> (While it should not have dumped the contents at all). Please revert 
> this, as this breaks backward compability BIG time, and IMO this is not 
> a shortcoming of CLI. BTW, where did you get that implicit_flush should 
> disable all output buffers?
> 
> Derick
> 
> --
> 
> ---
>  Derick Rethans   http://derickrethans.nl/ 
>  JDI Media Solutions
> --[ if you hold a unix shell to your ear, do you hear the c? ]-
> 


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /main output.c

[Derick Rethans]

On Thu, 3 Oct 2002, Yasuo Ohgaki wrote:

> You are the one used unexported php_ob_* function in var.c :)
> I'll fix var.c, then.

No, don't. These functions were meant to be exported, see this chat log 
with Zeev from around the time I implemented the function:

php.bugs-2001-12-15:

15:03 <@Derick> lets see if I can fix var_export
15:03 <@Zeev> what are you guys working on
15:03 <@Zeev> SRM?
15:03 <@Derick> making var_export not output to STDOUT, but return the data in a var
15:03 <@Derick> and this has nothing to do with SRM :)
15:03 <@Zeev> what's var_Export?
15:03 <@Zeev> and why not use output buffering/
15:03 <@Markus> hehe!!!
15:04 <@Derick> var_dump, but than real PHP code
15:04 <@Zeev> just use output buffering
15:04 <@Derick> yeah, that's hacky
15:04 <@Zeev> you can even use it internally
15:04 <@Zeev> no it's not
15:04 <@Markus> zeev: its really ... annoying to use ob_start(); var_dump($foo); 
$blaat = ob_get_contents() ...
15:04 <@Derick> Zeev: tell me how then :)
15:04 <@Zeev> writing specific support for every function is hacky
15:04 <@Zeev> output buffering does exactly this :)
15:04 <@Zeev> well
15:05 <@Derick> or do you have any good example?
15:05 <@Markus> damn var_dump() hasn't returned the content since the beginning as a 
return value
15:05 <@Zeev> php_start_ob_buffer(NULL, 0);
15:05 <@Zeev> do all the printing
15:05 <@Zeev> and then php_ob_get_buffer(&zval)
15:05 <@Zeev> and then php_end_ob_buffer(0, 0);
15:05 <@Derick> that's all?
15:05 <@Zeev> yeah
15:05 <@Derick> oh, let me check
15:11 <@Markus> opensrc you lazy boy :) 
http://lxr.php.net/source/php4/main/output.c#391
15:12 <@Derick> mmm?
15:12 <@Zeev> opensrc yes
15:50 <@Zeev> it worked?
15:50 <@Derick> yeah
15:50 <@Derick> I think so :)
15:51 <@Zeev> cool
15:51 <@Derick> I don't like testing :)
15:51 <@Zeev> it's the first time it's been done I think :)
15:51 <@Derick> hehe
15:51 <@Zeev> you're missing TSRMLS's there :)
15:51 <@Derick> I'll add something to the api docs then
15:51 <@Derick> Zeev: where? you didn't tell me about that :)
15:51 <@Zeev> you just copy&pasted eh? :)
15:51 <@Derick> sure
15:51 <@Derick> :)
15:52 <@Zeev> all of them take TSRMLS_CC
15:52 <@Derick> ok
15:52 <@Derick> but it did compile fine for me
15:52 <@Derick> php_ob_get_buffer (return_value TSRMLS_CC);
15:52 <@Derick> php_end_ob_buffer (0, 0 TSRMLS_CC);
15:52 <@Derick> that better?
15:53 <@Zeev> you need it in start_ob_buffer too
15:53 <@Derick> mmm
15:53 <@Zeev> but yeah it's good


Derick

> Derick Rethans wrote:
> > On Thu, 3 Oct 2002, Yasuo Ohgaki wrote:
> > 
> > 
> >>A little history. When 4.1.0 (or 4.2.0?) is released, I've fixed
> >>crush with deleting wrong buffer with implicit flush. The fix
> >>disabled implicit flush.
> >>
> >>I finally fixed implicit flush. Users should worry about
> >>implicit flush directive in php.ini now. e.g. implicit_flush=Off
> >>for normal use.
> >>
> >>Apparently, CLI SAPI implicitly enable implicit flush at
> >>initialization no matter what the php.ini setting is. CLI behavior
> >>is wrong, since there is no way to change implicit flush directive
> >>once script is started. I notified this to Edin and he would address
> >>this issue soon hopefully.
> > 
> > 
> > Can be, but implicit_flush is documented like this (which is correct):
> > 
> > implicit_flush  boolean
> > 
> > FALSE by default. Changing this to TRUE tells PHP to tell the output 
> > layer to flush itself automatically after every output block. This is 
> > equivalent to calling the PHP function flush() after each and every call 
> > to print() or echo() and each and every HTML block. 
> > 
> > It says totally NOTHING about output buffering issues. This change also 
> > breaks internal functions:
> > 
> >  > $str = var_export ("foo", TRUE);
> > ?>
> > 'foo'
> > 
> > (While it should not have dumped the contents at all). Please revert 
> > this, as this breaks backward compability BIG time, and IMO this is not 
> > a shortcoming of CLI. BTW, where did you get that implicit_flush should 
> > disable all output buffers?
> > 
> > Derick
> > 
> > --
> > 
> > ---
> >  Derick Rethans   http://derickrethans.nl/ 
> >  JDI Media Solutions
> > --[ if you hold a unix shell to your ear, do you hear the c? ]-
> > 
> 
> 

--

---
 Derick Rethans   http://derickrethans.nl/ 
 JDI Media Solutions
--[ if you hold a unix shell to your ear, do you hear the c? ]-


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /main output.c

[Zeev Suraski]

Yasuo,

Implicit flush has nothing to do with the PHP-level output buffering 
layers.  Implicit flush only means that the server-specific flush function 
should be called whenever output is being written using the server-specific 
output function.  As long as you're not calling the server-specific output 
function (e.g., if you're using PHP's output buffering layers), implicit 
flush has no meaning.

In other words - if you have implicit flush on, and turn output buffering 
on, and print out something - this something will go to the output buffer, 
and will NOT be flushed.  In no way should enabling implicit-flush change 
the output of an application, it must not interfere with the programmable 
output buffering layers of PHP.

That's the desired behavior, please make sure you did not deviate from it...

Thanks,

Zeev

At 05:48 03/10/2002, Yasuo Ohgaki wrote:
>Alan Knowles wrote:
>>Yasuo Ohgaki wrote:
>>>A little history. When 4.1.0 (or 4.2.0?) is released, I've fixed
>>>crush with deleting wrong buffer with implicit flush. The fix
>>>disabled implicit flush.
>>>
>>>I finally fixed implicit flush. Users should worry about
>>>implicit flush directive in php.ini now. e.g. implicit_flush=Off
>>>for normal use.
>>>
>>>Apparently, CLI SAPI implicitly enable implicit flush at
>>>initialization no matter what the php.ini setting is. CLI behavior
>>>is wrong, since there is no way to change implicit flush directive
>>>once script is started. I notified this to Edin and he would address
>>>this issue soon hopefully.
>>
>>Is it worth adding a note to the output control page
>>http://www.php.net/manual/en/ref.outcontrol.php and/or ob_start to say
>>"Note: When upgrading from PHP 4.1 (& 4.2) to 4.3 that due to a bug in 
>>earlier versions you must ensure that implict_flush is OFF in your 
>>php.ini, otherwise any output withing ob_start, will be not be hidden 
>>from output"
>>or something similar?
>>(at least it will be documented, even if nobody reads it :)
>
>Done :)
>
>--
>Yasuo Ohgaki
>
>
>--
>PHP Development Mailing List 
>To unsubscribe, visit: http://www.php.net/unsub.php


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /main output.c

[Sebastian Bergmann]

Zeev Suraski wrote:
> That's the desired behavior, please make sure you did not deviate from
> it.

  He deviated from it.

  Functions like highlight_string() or var_export() currently don't work
  with implicit_flush enabled.

-- 
  Sebastian Bergmann
  http://sebastian-bergmann.de/ http://phpOpenTracker.de/

  Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /main output.c

[Yasuo Ohgaki]

Derick Rethans wrote:
> On Thu, 3 Oct 2002, Yasuo Ohgaki wrote:
> 
> 
>>You are the one used unexported php_ob_* function in var.c :)
>>I'll fix var.c, then.
> 
> 
> No, don't. These functions were meant to be exported, see this chat log 
> with Zeev from around the time I implemented the function:

I'm not against exporting it. In fact, I added PHPAPI before it
hours ago, so that it's obvious that is exported. The PHPAPI prefix
shouldn't be need even for Windows, but we're better to follow
the standard rule. i.e. Use only PHPAPI function in other places.

var.c is fixed and I've added appropriate comment to output.c

--
Yasuo Ohgaki


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /main output.c

[Yasuo Ohgaki]

Sebastian Bergmann wrote:
> Zeev Suraski wrote:
> 
>>That's the desired behavior, please make sure you did not deviate from
>>it.
> 
> 
>   He deviated from it.
> 
>   Functions like highlight_string() or var_export() currently don't work
>   with implicit_flush enabled.

Guys,

implicit flush feature is broken for a looonng time.
Please refer to my comment recently added to output.c

--
Yasuo Ohgaki




-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /main output.c

[Zeev Suraski]

At 12:13 03/10/2002, Yasuo Ohgaki wrote:
>Sebastian Bergmann wrote:
>>Zeev Suraski wrote:
>>
>>>That's the desired behavior, please make sure you did not deviate from
>>>it.
>>
>>   He deviated from it.
>>   Functions like highlight_string() or var_export() currently don't work
>>   with implicit_flush enabled.
>
>Guys,
>
>implicit flush feature is broken for a looonng time.
>Please refer to my comment recently added to output.c

But it does not seem as if you fixed it properly.  I don't see how implicit 
flush can be at all related to output buffering.  If it was, it should have 
been trivial to fix it, at a centralized place.  You appear to be adding 
code all over the codebase, and as far as I understood from the thread, 
apparently you also made implicit flush disable output buffers, which is 
completely undesired behavior.  Please revert!  If there's still an issue 
with implicit flush after you revert, I will fix it.

Thanks,

Zeev


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /main output.c

[Yasuo Ohgaki]

Zeev Suraski wrote:
> But it does not seem as if you fixed it properly.  I don't see how 
> implicit flush can be at all related to output buffering.  If it was, it 
> should have been trivial to fix it, at a centralized place.  You appear 
> to be adding code all over the codebase, and as far as I understood from 
> the thread, apparently you also made implicit flush disable output 
> buffers, which is completely undesired behavior.  Please revert!  If 
> there's still an issue with implicit flush after you revert, I will fix it.

Zeev,

ob_implicit_flush() and php.ini's implicit_flush never worked for
nested output buffers.

Why? Older (which is very older now) code before my fix,
ob_implicit_flush() and implicit_flush was assuming there is
only one buffer always. It caused all kinds of problems due
to broken memory.

Now, ppl is complaining w/o knowing how implicit flush and output
buffer is working. (which I think very rude)

For others,

implicit_flush in php.ini only for debugging.
It may do something unwanted thing in your script, but
this is original design. Old code is just deleting
buffer to disable buffering. Newer code, which is much
better than deleting all buffers, process all buffers
and output.

implicit_flush should only be used for debugging.
If you need implicit flush, use ob_implicit_flush() to have
more control.

BTW, I think I found what's wrong in CLI thanks to Edin's
example.

--
Yasuo Ohgaki


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /main output.c

[Zeev Suraski]

At 12:48 03/10/2002, Yasuo Ohgaki wrote:
>Zeev Suraski wrote:
>>But it does not seem as if you fixed it properly.  I don't see how 
>>implicit flush can be at all related to output buffering.  If it was, it 
>>should have been trivial to fix it, at a centralized place.  You appear 
>>to be adding code all over the codebase, and as far as I understood from 
>>the thread, apparently you also made implicit flush disable output 
>>buffers, which is completely undesired behavior.  Please revert!  If 
>>there's still an issue with implicit flush after you revert, I will fix it.
>
>Zeev,
>
>ob_implicit_flush() and php.ini's implicit_flush never worked for
>nested output buffers.
>
>Why? Older (which is very older now) code before my fix,
>ob_implicit_flush() and implicit_flush was assuming there is
>only one buffer always. It caused all kinds of problems due
>to broken memory.
>
>Now, ppl is complaining w/o knowing how implicit flush and output
>buffer is working. (which I think very rude)
>
>For others,
>
>implicit_flush in php.ini only for debugging.
>It may do something unwanted thing in your script, but
>this is original design.

As the one who introduced implicit_flush, no, it is not the original design 
at all.  It's not something for debugging only, but also useful in certain 
interactive or report applications, including in the web environment.

Again, Yasuo, I'm not sure why implicit_flush was related in any way to 
output buffering. You say that it was somehow incompatible with multiple 
buffers, and I believe you, but fixing it in a way that ties it with output 
buffering is wrong, period.  Looking at the old code it looks like the bug 
was actually introduced by me (I disabled output buffering 
start_implicit_flush(), for no good reason), but greatly expanded by your 
recent patches.  It's time to completely decouple these two, instead of 
strengthening their coupling.

Zeev


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /main output.c

[Yasuo Ohgaki]

Zeev Suraski wrote:
>> implicit_flush in php.ini only for debugging.
>> It may do something unwanted thing in your script, but
>> this is original design.
> 
> 
> As the one who introduced implicit_flush, no, it is not the original 
> design at all.  It's not something for debugging only, but also useful 
> in certain interactive or report applications, including in the web 
> environment.

I'm not sure what is your worry.
implicit_flush in php.ini is never worked for nested buffers.

It was simply deleting OG(active_buffer), which is obviously
wrong for nested output buffers.

Yes. It may be little different as original intention, but
it works as it should. Suppose these are buffer stacked like this

lev 2: mb_output_handler
lev 1: default buffer

New code applies all buffer to each output when implicit_flush
is on. It also applies all buffers when user called ob_implicit_flush().

Without buffers, output could be totally useless.

> Again, Yasuo, I'm not sure why implicit_flush was related in any way to 
> output buffering. You say that it was somehow incompatible with multiple 
> buffers, and I believe you, but fixing it in a way that ties it with 
> output buffering is wrong, period.  Looking at the old code it looks 

It may not flush as user expected. It is depends on how each buffers
treat data. For instance, a handler may need 1024 bytes before output
anything.

Anyway, I'm not big fun of implicit flush and removing the feature
is ok to me, too.

--
Yasuo Ohgaki


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /main output.c

[Sebastian Bergmann]

Yasuo Ohgaki wrote:
> Anyway, I'm not big fun of implicit flush and removing the feature
> is ok to me, too.

  Do you actually read what other people post about this on php-dev?

-- 
  Sebastian Bergmann
  http://sebastian-bergmann.de/ http://phpOpenTracker.de/

  Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /main output.c

[Yasuo Ohgaki]

Sebastian Bergmann wrote:
> Yasuo Ohgaki wrote:
> 
>>Anyway, I'm not big fun of implicit flush and removing the feature
>>is ok to me, too.
> 
> 
>   Do you actually read what other people post about this on php-dev?
> 

Do you actually know how it is working?

Try some with current code. Let me know if there is
problem that I'm not aware of. I probably can fix problems :)

BTW, CLI SAPI HAD *BUG*. It enables implicit_flush in
the code statically.

--
Yasuo Ohgaki


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /main output.c

[Zeev Suraski]

At 13:26 03/10/2002, Yasuo Ohgaki wrote:
>It may not flush as user expected. It is depends on how each buffers
>treat data. For instance, a handler may need 1024 bytes before output
>anything.

I'm not sure what you're talking about really.  implicit_flush should 
effect ONLY what happens in the unbuffered_output_function SAPI handler, 
which is called only when we actually write output to the web server.  It 
is not, and cannot be related to output buffers.

>Anyway, I'm not big fun of implicit flush and removing the feature
>is ok to me, too.

That's fine and dandy, except this feature is very useful, so removing it 
is not ok with me at all.  Let's keep it as it was intended.

Zeev


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /main output.c

[Yasuo Ohgaki]

Zeev Suraski wrote:
> At 13:26 03/10/2002, Yasuo Ohgaki wrote:
> 
>> It may not flush as user expected. It is depends on how each buffers
>> treat data. For instance, a handler may need 1024 bytes before output
>> anything.
> 
> 
> I'm not sure what you're talking about really.  implicit_flush should 
> effect ONLY what happens in the unbuffered_output_function SAPI handler, 
> which is called only when we actually write output to the web server.  
> It is not, and cannot be related to output buffers.

Ok. My interpretation of implicit_flush was different from others.

> 
>> Anyway, I'm not big fun of implicit flush and removing the feature
>> is ok to me, too.
> 
> 
> That's fine and dandy, except this feature is very useful, so removing 
> it is not ok with me at all.  Let's keep it as it was intended.

I've committed new patch ignores PG(implicit_flush), now everyone
should be happy :)

It may not work if some buffer(s) require long or whole contents.
ob_implicit_flush() is made work in most cases.

--
Yasuo Ohgaki



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /main output.c

[Jon Parise]

On Thu, Oct 03, 2002 at 08:05:51PM +0900, Yasuo Ohgaki wrote:

> >Can you please re-test things regarding to this? I reverted Yasuo's 
> >commits and I might have overlooked something.
> 
> What kind of diff you are using?
> I guess you are willing to revert my patches, but you don't.
> 
> BTW, stop breaking things. All should be working as used be
> (except a little difference) before your commit.
 
This is starting to get silly, from where I sit.

This entire thing would be much simpler if you guys started posting
diff's of proposed changes to this list for open discussion.  This is
one of those cases where the propensity to commit changes as soon as
possible is turning the repository into a mess of changes and
reversions.

What's the hurry?  Give other people a chance to comment on your work.
That's the open source way.

-- 
Jon Parise ([EMAIL PROTECTED]) :: The PHP Project (http://www.php.net/)

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php