Re: [PHP-DEV] I hope this is the last email about this :)
Derick Rethans wrote: On Tue, 29 Oct 2002, Yasuo Ohgaki wrote: Zeev Suraski wrote: Please revert. There is no need. Derick has been changed it w/o discussion. Nice joke :) Don't you forget I've posted I'll change it? I get reply only from you, though. Old code was bogus as everyone knew now. Your patch made impossible to turn off implicit flushing at all. I know you've modified code at very late stage of discussion to fix it, even if I've mentioned the problem number of times. Nice joke to you :) -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I hope this is the last email about this :)
On Tue, 29 Oct 2002, Yasuo Ohgaki wrote: Derick Rethans wrote: On Tue, 29 Oct 2002, Yasuo Ohgaki wrote: There is no need. Derick has been changed it w/o discussion. Nice joke :) Don't you forget I've posted I'll change it? I get reply only from you, though. Old code was bogus as everyone knew now. Bogus? *sigh*... no more comments on this. Your patch made impossible to turn off implicit flushing at all. I know you've modified code at very late stage of discussion to fix it, even if I've mentioned the problem number of times. That is not even true, you always could disable that hardcoded setting by passing the -d option to the Command Line Interface. 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 http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I hope this is the last email about this :)
Derick Rethans wrote: Your patch made impossible to turn off implicit flushing at all. I know you've modified code at very late stage of discussion to fix it, even if I've mentioned the problem number of times. That is not even true, you always could disable that hardcoded setting by passing the -d option to the Command Line Interface. True, but everyone has to wait until everyone installs php/cli to standard location, such as /usr/bin/php, to have control behavior of php scripts for distributing :) I have no idea about Windows ;) -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] I hope this is the last email about this :)
-Original Message- From: Zeev Suraski [mailto:zeev;zend.com] Sent: 28 October 2002 02:06 Thank you for the detailed explanation, I'm sure everybody understands it now. Let's go for the voting phase. I vote we keep PHP-CLI with implicit_flush on by default. +1 Cheers! Mike - Mike Ford, Electronic Information Services Adviser, Learning Support Services, Learning Information Services, JG125, James Graham Building, Leeds Metropolitan University, Beckett Park, LEEDS, LS6 3QS, United Kingdom Email: [EMAIL PROTECTED] Tel: +44 113 283 2600 extn 4730 Fax: +44 113 283 3211 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I hope this is the last email about this :)
Zeev Suraski wrote: At 15:29 25/10/2002, Yasuo Ohgaki wrote: Are you going to set output_buffering=Off by default, too? Since the obscurity still exists with output buffers. It's even worse with broken output buffer function. Huh? It IS off by default. Of course I know it is off by default in php.ini-dist and code, but it is on by default in php.ini-recommended. If users have php.ini based on php.ini-recommended, there will be a default buffer. It does not make sense at all. I really don't understand why people are having problems to understand such intuitive issue. BTW, I don't object to have output_buffering=Off by default for CLI, since it's default of php.ini-dist and it does not make much sense for CLI. Its default in php.ini-dist is OFF. You might be mixing it with php.ini-recommended, which also comes with an explanation of what it would do, but either way, php.ini-recommended has much less exposure when compraed to php.ini-dist. Don't you want usable behavior with CLI? Even if users are using their web server php.ini? Use php.ini-recommended as your default, then you'll see. BTW, we should better to have a little different ini selection for CLI. For instance, /etc/phprc or php.ini ~/.phprc or php.ini which are standard locations of rc files under UNIX like systems. -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I hope this is the last email about this :)
Zeev Suraski wrote: Thank you for the detailed explanation, I'm sure everybody understands it now. Let's go for the voting phase. I vote we keep PHP-CLI with implicit_flush on by default. You vote against. Of course :) I vote -1 for it. It does not make sense to have it on by default which should be turn off almost always. -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I hope this is the last email about this :)
+1 FLUSH -- Maxim Maletsky [EMAIL PROTECTED] www.PHPBeginner.com // PHP for Beginners www.maxim.cx // my Home // my Wish List: ( Get me something! ) http://www.amazon.com/exec/obidos/registry/2IXE7SMI5EDI3 Zeev Suraski [EMAIL PROTECTED] wrote... : Thank you for the detailed explanation, I'm sure everybody understands it now. Let's go for the voting phase. I vote we keep PHP-CLI with implicit_flush on by default. You vote against. Can we get some other votes now (not opinions, everything was already said a dozen times, just votes to get this over with). Thanks! Zeev At 15:11 25/10/2002, Yasuo Ohgaki wrote: Zeev Suraski wrote: At 09:15 25/10/2002, Yasuo Ohgaki wrote: Zeev Suraski wrote: You print something, it doesn't print out. How is it trivial to solve this? If you happen to know that there's IO buffering and that there's a function called flush() then maybe it trivial, but then there are the other million users who don't. Hence the idea of setting is to implicit flush for the masses, who not only don't know about the existence of flush(), but also don't know why it's even necessary. Ok. If we are argue about what is mass or not Don't forget about - millions(?) of _current_ PHP users who are used to implicit_flush=off by default. Few of them use CLI. As I mentioned already, people are used to implicit_off=off and it's the default of other SAPIs, therefore, it's not intuitive for existing users. If we aren't care about much about existing users base, I think we should set short_tag=Off by default, but you're insisting it should be on even if much fewer people are using. I'm confused. People expects PHP/CLI behave like Apache SAPI, CGI SAPI, etc. Well, if I weren't developer and didn't know discussion, I'll certainly write bug report that implicit flush is enabled wrongly. - millions of decent programmers who are used to _usual_ behavior. I consider myself a decent programmer, and I also consider the need to flush explicitly extremely annoying. Moreover, many PHP programmers (if not most) aren't used to this 'usual' behavior, because they either never programmed in another language, or they still didn't bump into that specific behavior. Don't you think flushing is needed only very limited applications? i.e. We don't write interactive CUI applications much now a days. - millions of scripts/echo/print don't need automatic flush at all. i.e. much fewer number of script/echo/print need auto flushing. It doesn't matter. When you're screwed by the lack of implicit flush, it's much worse than a mere slow down. Hmm. Since console is line buffered. There aren't many thing that is missed by implicit flushing. Please list programming languages (i.e. not shell) that do automatic/inefficient/unneeded flushing by default in program mode. Read my fingertips - PHP IN CLI MODE. There's one, that's the only one I care about. My point is we should learn from many smart peoples designs' of languages. If we are argue about difficulty of flushing, We're not. We're arguing about the obscurity of the problem. implicit_flush=On is obscure for current users. Suppose not flushing is extremely obscure, but default is better to set which is better/suitable for more occasions and is better to be consistent with other SAPIs. Is this the main point of auto flushing? If there are other points, please list them. -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I hope this is the last email about this :)
+1 to keep PHP-CLI with implicit_flush. Ilia On October 27, 2002 09:05 pm, Zeev Suraski wrote: Thank you for the detailed explanation, I'm sure everybody understands it now. Let's go for the voting phase. I vote we keep PHP-CLI with implicit_flush on by default. You vote against. Can we get some other votes now (not opinions, everything was already said a dozen times, just votes to get this over with). Thanks! Zeev At 15:11 25/10/2002, Yasuo Ohgaki wrote: Zeev Suraski wrote: At 09:15 25/10/2002, Yasuo Ohgaki wrote: Zeev Suraski wrote: You print something, it doesn't print out. How is it trivial to solve this? If you happen to know that there's IO buffering and that there's a function called flush() then maybe it trivial, but then there are the other million users who don't. Hence the idea of setting is to implicit flush for the masses, who not only don't know about the existence of flush(), but also don't know why it's even necessary. Ok. If we are argue about what is mass or not Don't forget about - millions(?) of _current_ PHP users who are used to implicit_flush=off by default. Few of them use CLI. As I mentioned already, people are used to implicit_off=off and it's the default of other SAPIs, therefore, it's not intuitive for existing users. If we aren't care about much about existing users base, I think we should set short_tag=Off by default, but you're insisting it should be on even if much fewer people are using. I'm confused. People expects PHP/CLI behave like Apache SAPI, CGI SAPI, etc. Well, if I weren't developer and didn't know discussion, I'll certainly write bug report that implicit flush is enabled wrongly. - millions of decent programmers who are used to _usual_ behavior. I consider myself a decent programmer, and I also consider the need to flush explicitly extremely annoying. Moreover, many PHP programmers (if not most) aren't used to this 'usual' behavior, because they either never programmed in another language, or they still didn't bump into that specific behavior. Don't you think flushing is needed only very limited applications? i.e. We don't write interactive CUI applications much now a days. - millions of scripts/echo/print don't need automatic flush at all. i.e. much fewer number of script/echo/print need auto flushing. It doesn't matter. When you're screwed by the lack of implicit flush, it's much worse than a mere slow down. Hmm. Since console is line buffered. There aren't many thing that is missed by implicit flushing. Please list programming languages (i.e. not shell) that do automatic/inefficient/unneeded flushing by default in program mode. Read my fingertips - PHP IN CLI MODE. There's one, that's the only one I care about. My point is we should learn from many smart peoples designs' of languages. If we are argue about difficulty of flushing, We're not. We're arguing about the obscurity of the problem. implicit_flush=On is obscure for current users. Suppose not flushing is extremely obscure, but default is better to set which is better/suitable for more occasions and is better to be consistent with other SAPIs. Is this the main point of auto flushing? If there are other points, please list them. -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I hope this is the last email about this :)
At 07:38 PM 10/28/02 +0900, Yasuo Ohgaki wrote: BTW, we should better to have a little different ini selection for CLI. For instance, /etc/phprc or php.ini ~/.phprc or php.ini which are standard locations of rc files under UNIX like systems. This I can agree with. I would prefer /etc/php.ini which I am already using. Rick -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I hope this is the last email about this :)
Yasuo, I think the picture is pretty clear now. There were no votes in favour of keeping it off, and at least half a dozen votes to keep it on. While I don't particularly like these ad-hoc votes, it appeared to be the only way to demonstrate to you that in this discussion, people are simply not buying into your reasoning, as reasonable as it may sound to you personally. Please revert. Zeev At 04:21 28/10/2002, Ilia A. wrote: +1 to keep PHP-CLI with implicit_flush. Ilia On October 27, 2002 09:05 pm, Zeev Suraski wrote: Thank you for the detailed explanation, I'm sure everybody understands it now. Let's go for the voting phase. I vote we keep PHP-CLI with implicit_flush on by default. You vote against. Can we get some other votes now (not opinions, everything was already said a dozen times, just votes to get this over with). Thanks! Zeev At 15:11 25/10/2002, Yasuo Ohgaki wrote: Zeev Suraski wrote: At 09:15 25/10/2002, Yasuo Ohgaki wrote: Zeev Suraski wrote: You print something, it doesn't print out. How is it trivial to solve this? If you happen to know that there's IO buffering and that there's a function called flush() then maybe it trivial, but then there are the other million users who don't. Hence the idea of setting is to implicit flush for the masses, who not only don't know about the existence of flush(), but also don't know why it's even necessary. Ok. If we are argue about what is mass or not Don't forget about - millions(?) of _current_ PHP users who are used to implicit_flush=off by default. Few of them use CLI. As I mentioned already, people are used to implicit_off=off and it's the default of other SAPIs, therefore, it's not intuitive for existing users. If we aren't care about much about existing users base, I think we should set short_tag=Off by default, but you're insisting it should be on even if much fewer people are using. I'm confused. People expects PHP/CLI behave like Apache SAPI, CGI SAPI, etc. Well, if I weren't developer and didn't know discussion, I'll certainly write bug report that implicit flush is enabled wrongly. - millions of decent programmers who are used to _usual_ behavior. I consider myself a decent programmer, and I also consider the need to flush explicitly extremely annoying. Moreover, many PHP programmers (if not most) aren't used to this 'usual' behavior, because they either never programmed in another language, or they still didn't bump into that specific behavior. Don't you think flushing is needed only very limited applications? i.e. We don't write interactive CUI applications much now a days. - millions of scripts/echo/print don't need automatic flush at all. i.e. much fewer number of script/echo/print need auto flushing. It doesn't matter. When you're screwed by the lack of implicit flush, it's much worse than a mere slow down. Hmm. Since console is line buffered. There aren't many thing that is missed by implicit flushing. Please list programming languages (i.e. not shell) that do automatic/inefficient/unneeded flushing by default in program mode. Read my fingertips - PHP IN CLI MODE. There's one, that's the only one I care about. My point is we should learn from many smart peoples designs' of languages. If we are argue about difficulty of flushing, We're not. We're arguing about the obscurity of the problem. implicit_flush=On is obscure for current users. Suppose not flushing is extremely obscure, but default is better to set which is better/suitable for more occasions and is better to be consistent with other SAPIs. Is this the main point of auto flushing? If there are other points, please list them. -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I hope this is the last email about this :)
On Mon, 28 Oct 2002, Zeev Suraski wrote: Yasuo, I think the picture is pretty clear now. There were no votes in favour of keeping it off, and at least half a dozen votes to keep it on. While I don't particularly like these ad-hoc votes, it appeared to be the only way to demonstrate to you that in this discussion, people are simply not buying into your reasoning, as reasonable as it may sound to you personally. full list: [EMAIL PROTECTED] +1 [EMAIL PROTECTED] +1 [EMAIL PROTECTED] +1 [EMAIL PROTECTED] -0 [EMAIL PROTECTED] +1 [EMAIL PROTECTED]+1 [EMAIL PROTECTED]+1 [EMAIL PROTECTED]+1 [EMAIL PROTECTED] +1 [EMAIL PROTECTED] -1 [EMAIL PROTECTED] +1 [EMAIL PROTECTED]+1 [EMAIL PROTECTED] +1 [EMAIL PROTECTED]+1 total: +10.5 Please revert. Already done myself a few days ago. 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 http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I hope this is the last email about this :)
Zeev Suraski wrote: Please revert. There is no need. Derick has been changed it w/o discussion. -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I hope this is the last email about this :)
hello, I just remember the subject :- [PHP-DEV] I hope this is the last email about this :) sorry, cannot resist to do it :-) -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I hope this is the last email about this :)
On Tue, 29 Oct 2002, Yasuo Ohgaki wrote: Zeev Suraski wrote: Please revert. There is no need. Derick has been changed it w/o discussion. Nice joke :) 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 http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I hope this is the last email about this :)
Thank you for the detailed explanation, I'm sure everybody understands it now. Let's go for the voting phase. I vote we keep PHP-CLI with implicit_flush on by default. You vote against. Can we get some other votes now (not opinions, everything was already said a dozen times, just votes to get this over with). Thanks! Zeev At 15:11 25/10/2002, Yasuo Ohgaki wrote: Zeev Suraski wrote: At 09:15 25/10/2002, Yasuo Ohgaki wrote: Zeev Suraski wrote: You print something, it doesn't print out. How is it trivial to solve this? If you happen to know that there's IO buffering and that there's a function called flush() then maybe it trivial, but then there are the other million users who don't. Hence the idea of setting is to implicit flush for the masses, who not only don't know about the existence of flush(), but also don't know why it's even necessary. Ok. If we are argue about what is mass or not Don't forget about - millions(?) of _current_ PHP users who are used to implicit_flush=off by default. Few of them use CLI. As I mentioned already, people are used to implicit_off=off and it's the default of other SAPIs, therefore, it's not intuitive for existing users. If we aren't care about much about existing users base, I think we should set short_tag=Off by default, but you're insisting it should be on even if much fewer people are using. I'm confused. People expects PHP/CLI behave like Apache SAPI, CGI SAPI, etc. Well, if I weren't developer and didn't know discussion, I'll certainly write bug report that implicit flush is enabled wrongly. - millions of decent programmers who are used to _usual_ behavior. I consider myself a decent programmer, and I also consider the need to flush explicitly extremely annoying. Moreover, many PHP programmers (if not most) aren't used to this 'usual' behavior, because they either never programmed in another language, or they still didn't bump into that specific behavior. Don't you think flushing is needed only very limited applications? i.e. We don't write interactive CUI applications much now a days. - millions of scripts/echo/print don't need automatic flush at all. i.e. much fewer number of script/echo/print need auto flushing. It doesn't matter. When you're screwed by the lack of implicit flush, it's much worse than a mere slow down. Hmm. Since console is line buffered. There aren't many thing that is missed by implicit flushing. Please list programming languages (i.e. not shell) that do automatic/inefficient/unneeded flushing by default in program mode. Read my fingertips - PHP IN CLI MODE. There's one, that's the only one I care about. My point is we should learn from many smart peoples designs' of languages. If we are argue about difficulty of flushing, We're not. We're arguing about the obscurity of the problem. implicit_flush=On is obscure for current users. Suppose not flushing is extremely obscure, but default is better to set which is better/suitable for more occasions and is better to be consistent with other SAPIs. Is this the main point of auto flushing? If there are other points, please list them. -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I hope this is the last email about this :)
At 15:29 25/10/2002, Yasuo Ohgaki wrote: Are you going to set output_buffering=Off by default, too? Since the obscurity still exists with output buffers. It's even worse with broken output buffer function. Huh? It IS off by default. BTW, I don't object to have output_buffering=Off by default for CLI, since it's default of php.ini-dist and it does not make much sense for CLI. Its default in php.ini-dist is OFF. You might be mixing it with php.ini-recommended, which also comes with an explanation of what it would do, but either way, php.ini-recommended has much less exposure when compraed to php.ini-dist. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I hope this is the last email about this :)
I vote we leave it on. Chris Zeev Suraski wrote: Thank you for the detailed explanation, I'm sure everybody understands it now. Let's go for the voting phase. I vote we keep PHP-CLI with implicit_flush on by default. You vote against. Can we get some other votes now (not opinions, everything was already said a dozen times, just votes to get this over with). -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I hope this is the last email about this :)
On Sun, 27 Oct 2002, Zeev Suraski wrote: Let's go for the voting phase. I vote we keep PHP-CLI with implicit_flush on by default. You vote against. Can we get some other votes now (not opinions, everything was already said a dozen times, just votes to get this over with). Leave it on by default with CLI. --Jani -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I hope this is the last email about this :)
That was +1 for changing it to off. :) On Sunday, October 27, 2002, at 09:37 PM, George Schlossnagle wrote: +1 unless it is set as an INI_ANY, then +0. George On Sunday, October 27, 2002, at 09:05 PM, Zeev Suraski wrote: Thank you for the detailed explanation, I'm sure everybody understands it now. Let's go for the voting phase. I vote we keep PHP-CLI with implicit_flush on by default. You vote against. Can we get some other votes now (not opinions, everything was already said a dozen times, just votes to get this over with). Thanks! Zeev At 15:11 25/10/2002, Yasuo Ohgaki wrote: Zeev Suraski wrote: At 09:15 25/10/2002, Yasuo Ohgaki wrote: Zeev Suraski wrote: You print something, it doesn't print out. How is it trivial to solve this? If you happen to know that there's IO buffering and that there's a function called flush() then maybe it trivial, but then there are the other million users who don't. Hence the idea of setting is to implicit flush for the masses, who not only don't know about the existence of flush(), but also don't know why it's even necessary. Ok. If we are argue about what is mass or not Don't forget about - millions(?) of _current_ PHP users who are used to implicit_flush=off by default. Few of them use CLI. As I mentioned already, people are used to implicit_off=off and it's the default of other SAPIs, therefore, it's not intuitive for existing users. If we aren't care about much about existing users base, I think we should set short_tag=Off by default, but you're insisting it should be on even if much fewer people are using. I'm confused. People expects PHP/CLI behave like Apache SAPI, CGI SAPI, etc. Well, if I weren't developer and didn't know discussion, I'll certainly write bug report that implicit flush is enabled wrongly. - millions of decent programmers who are used to _usual_ behavior. I consider myself a decent programmer, and I also consider the need to flush explicitly extremely annoying. Moreover, many PHP programmers (if not most) aren't used to this 'usual' behavior, because they either never programmed in another language, or they still didn't bump into that specific behavior. Don't you think flushing is needed only very limited applications? i.e. We don't write interactive CUI applications much now a days. - millions of scripts/echo/print don't need automatic flush at all. i.e. much fewer number of script/echo/print need auto flushing. It doesn't matter. When you're screwed by the lack of implicit flush, it's much worse than a mere slow down. Hmm. Since console is line buffered. There aren't many thing that is missed by implicit flushing. Please list programming languages (i.e. not shell) that do automatic/inefficient/unneeded flushing by default in program mode. Read my fingertips - PHP IN CLI MODE. There's one, that's the only one I care about. My point is we should learn from many smart peoples designs' of languages. If we are argue about difficulty of flushing, We're not. We're arguing about the obscurity of the problem. implicit_flush=On is obscure for current users. Suppose not flushing is extremely obscure, but default is better to set which is better/suitable for more occasions and is better to be consistent with other SAPIs. Is this the main point of auto flushing? If there are other points, please list them. -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php // George Schlossnagle // Principal Consultant // OmniTI, Inc http://www.omniti.com // (c) 240.460.5234 (e) [EMAIL PROTECTED] // 1024D/1100A5A0 1370 F70A 9365 96C9 2F5E 56C2 B2B9 262F 1100 A5A0 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I hope this is the last email about this :)
At 18:37 27/10/2002, George Schlossnagle wrote: +1 unless it is set as an INI_ANY, then +0. It's already INI_ANY... -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I hope this is the last email about this :)
Indeed it appears to be... +0 then. :) On Monday, October 28, 2002, at 07:44 AM, Zeev Suraski wrote: At 18:37 27/10/2002, George Schlossnagle wrote: +1 unless it is set as an INI_ANY, then +0. It's already INI_ANY... -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php // George Schlossnagle // Principal Consultant // OmniTI, Inc http://www.omniti.com // (c) 240.460.5234 (e) [EMAIL PROTECTED] // 1024D/1100A5A0 1370 F70A 9365 96C9 2F5E 56C2 B2B9 262F 1100 A5A0 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] I hope this is the last email about this :)
Zeev Suraski writes: I vote we keep PHP-CLI with implicit_flush on by default. Ditto. Regards Mike Robinson -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I hope this is the last email about this :)
Let's go for the voting phase. I vote we keep PHP-CLI with implicit_flush on by default. You vote against. I'm with Zeev on this one. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I hope this is the last email about this :)
On 28/10/02, Zeev Suraski [EMAIL PROTECTED] wrote: Thank you for the detailed explanation, I'm sure everybody understands it now. Let's go for the voting phase. I vote we keep PHP-CLI with implicit_flush on by default. +1 --Wez. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] I hope this is the last email about this :)
At 09:57 PM 10/27/2002 -0500, Mike Robinson wrote: Zeev Suraski writes: I vote we keep PHP-CLI with implicit_flush on by default. Ditto. Make that Ditto * 2. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I hope this is the last email about this :)
At 06:05 PM 10/27/02 -0800, Zeev Suraski wrote: Thank you for the detailed explanation, I'm sure everybody understands it now. I vote we keep PHP-CLI with implicit_flush on by default. +1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I hope this is the last email about this :)
On Sun, 27 Oct 2002, Zeev Suraski wrote: Thank you for the detailed explanation, I'm sure everybody understands it now. Let's go for the voting phase. I vote we keep PHP-CLI with implicit_flush on by default. You vote against. +1 to keep implicit_flush enabled. 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 http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I hope this is the last email about this :)
Zeev Suraski wrote: You print something, it doesn't print out. How is it trivial to solve this? If you happen to know that there's IO buffering and that there's a function called flush() then maybe it trivial, but then there are the other million users who don't. Hence the idea of setting is to implicit flush for the masses, who not only don't know about the existence of flush(), but also don't know why it's even necessary. Ok. If we are argue about what is mass or not Don't forget about - millions(?) of _current_ PHP users who are used to implicit_flush=off by default. - millions of decent programmers who are used to _usual_ behavior. - millions of scripts/echo/print don't need automatic flush at all. i.e. much fewer number of script/echo/print need auto flushing. Please list programming languages (i.e. not shell) that do automatic/inefficient/unneeded flushing by default in program mode. If we are argue about difficulty of flushing, - there are many tiny small things that may not be trivial to newbies, flush may be one of them. They should learn these simple idioms anyway. - line buffering is easy enough to learn. Even newbies should find it flushes with newline. It should be enough for them, if they cannot find/learn flush(). - are we going to detect things that may not be intuitive to newbies? e.g. infinite loop/recusion, etc. I guess not. implicit_flush=On by default is bad for both newbies and experienced users. Newbies (even experienced users) write inefficient programs, since they don't know auto flushing. Experienced users have to unset auto flushing almost always. -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I hope this is the last email about this :) (was RF
Mike Ford wrote: BTW, real language (i.e. not shell) don't flush. Please let me know if there is real language that do automatic flushing by default. But PHP-CLI *is* a shell-scripting language, and therefore should behave like one. Other flavours of PHP aren't, and shouldn't. QED. You explained yourself as experienced programmer, but please research what is shell. Do you have this in your /etc/passwd file ;) root:x:0:0:root:/root:/bin/php Try that, it should be fun to use php as shell. Don't forget to copy your php binary to /bin! -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I hope this is the last email about this :) (was RF
Mike,
It seems my last mail is a bit too negative. Sorry.
Mike Ford wrote:
-Original Message-
From: Yasuo Ohgaki [mailto:yohgaki;ohgaki.net]
Sent: 24 October 2002 07:42
To: [EMAIL PROTECTED]; Alan Knowles
Alan Knowles wrote:
Im +1 for reverting the patch - (for what it's worth)
This makes 2+ for having auto flushing :)
Add one more -- or even more, as I 'd say I'm +1 for this!
BTW, real language (i.e. not shell) don't flush. Please let me
know if there is real language that do automatic flushing by
default.
But PHP-CLI *is* a shell-scripting language, and therefore should behave
like one. Other flavours of PHP aren't, and shouldn't. QED.
I'm referring to actual shell used for user interface, such as
bash, csh.
AFAIK, all shells flushes automatically, but no programing language
that is designed for programming do not flush.
In addition, is it too difficult to write this kind of code?
function prompt($prefix) {
echo $prefix;
flush();
}
I think this kind of code will be taught at the first
class of programming course. (I could be wrong,
since I don't know where people learned programming ;)
At university: learned half-a-dozen languages; *all* of them flushed streams
open on TTY either after every character, or (at line-end or when input
requested from same device). I've been programming now for over 25 years,
and this is *still* the behaviour I expect by default when programming
command-line-executable scripts or programs.
If people would like to a script that can be used as filter,
auto flushing is evil.
If people writing interactive CUI programs,
function prompt($prefix) {
echo $prefix;
flush();
}
is enough.
Line buffering is enough for all most all purposes.
Don't forget auto flushing make system call flush stream twice
with following script always.
echo abc\n;
And flushing is relatively heavy thing to do.
Let's guess something interesting.
How much % of scripts actually needs automatic flushing?
My guess is less than 1%. What is yours?
For PHP-CLI: more than 90%.
For PHP CGI or SAPI: much less than 1%.
I think only very little CLI programs, less than 1%, a few %
at most, need auto flushing.
--
Yasuo Ohgaki
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I hope this is the last email about this :) (was RF
Yasuo,
can you please stop this discussion now, it's not going to change. It
only wastes time which we could have spend on numerous other things for
PHP, such as fixing bugs and writing tests for the test system.
Derick
On Fri, 25 Oct 2002, Yasuo Ohgaki wrote:
Mike,
It seems my last mail is a bit too negative. Sorry.
Mike Ford wrote:
-Original Message-
From: Yasuo Ohgaki [mailto:yohgaki;ohgaki.net]
Sent: 24 October 2002 07:42
To: [EMAIL PROTECTED]; Alan Knowles
Alan Knowles wrote:
Im +1 for reverting the patch - (for what it's worth)
This makes 2+ for having auto flushing :)
Add one more -- or even more, as I 'd say I'm +1 for this!
BTW, real language (i.e. not shell) don't flush. Please let me
know if there is real language that do automatic flushing by
default.
But PHP-CLI *is* a shell-scripting language, and therefore should behave
like one. Other flavours of PHP aren't, and shouldn't. QED.
I'm referring to actual shell used for user interface, such as
bash, csh.
AFAIK, all shells flushes automatically, but no programing language
that is designed for programming do not flush.
In addition, is it too difficult to write this kind of code?
function prompt($prefix) {
echo $prefix;
flush();
}
I think this kind of code will be taught at the first
class of programming course. (I could be wrong,
since I don't know where people learned programming ;)
At university: learned half-a-dozen languages; *all* of them flushed streams
open on TTY either after every character, or (at line-end or when input
requested from same device). I've been programming now for over 25 years,
and this is *still* the behaviour I expect by default when programming
command-line-executable scripts or programs.
If people would like to a script that can be used as filter,
auto flushing is evil.
If people writing interactive CUI programs,
function prompt($prefix) {
echo $prefix;
flush();
}
is enough.
Line buffering is enough for all most all purposes.
Don't forget auto flushing make system call flush stream twice
with following script always.
echo abc\n;
And flushing is relatively heavy thing to do.
Let's guess something interesting.
How much % of scripts actually needs automatic flushing?
My guess is less than 1%. What is yours?
For PHP-CLI: more than 90%.
For PHP CGI or SAPI: much less than 1%.
I think only very little CLI programs, less than 1%, a few %
at most, need auto flushing.
--
Yasuo Ohgaki
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
--
---
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 http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I hope this is the last email about this :)
At 09:15 25/10/2002, Yasuo Ohgaki wrote: Zeev Suraski wrote: You print something, it doesn't print out. How is it trivial to solve this? If you happen to know that there's IO buffering and that there's a function called flush() then maybe it trivial, but then there are the other million users who don't. Hence the idea of setting is to implicit flush for the masses, who not only don't know about the existence of flush(), but also don't know why it's even necessary. Ok. If we are argue about what is mass or not Don't forget about - millions(?) of _current_ PHP users who are used to implicit_flush=off by default. Few of them use CLI. - millions of decent programmers who are used to _usual_ behavior. I consider myself a decent programmer, and I also consider the need to flush explicitly extremely annoying. Moreover, many PHP programmers (if not most) aren't used to this 'usual' behavior, because they either never programmed in another language, or they still didn't bump into that specific behavior. - millions of scripts/echo/print don't need automatic flush at all. i.e. much fewer number of script/echo/print need auto flushing. It doesn't matter. When you're screwed by the lack of implicit flush, it's much worse than a mere slow down. Please list programming languages (i.e. not shell) that do automatic/inefficient/unneeded flushing by default in program mode. Read my fingertips - PHP IN CLI MODE. There's one, that's the only one I care about. If we are argue about difficulty of flushing, We're not. We're arguing about the obscurity of the problem. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I hope this is the last email about this :)
Zeev Suraski wrote: At 09:15 25/10/2002, Yasuo Ohgaki wrote: Zeev Suraski wrote: You print something, it doesn't print out. How is it trivial to solve this? If you happen to know that there's IO buffering and that there's a function called flush() then maybe it trivial, but then there are the other million users who don't. Hence the idea of setting is to implicit flush for the masses, who not only don't know about the existence of flush(), but also don't know why it's even necessary. Ok. If we are argue about what is mass or not Don't forget about - millions(?) of _current_ PHP users who are used to implicit_flush=off by default. Few of them use CLI. As I mentioned already, people are used to implicit_off=off and it's the default of other SAPIs, therefore, it's not intuitive for existing users. If we aren't care about much about existing users base, I think we should set short_tag=Off by default, but you're insisting it should be on even if much fewer people are using. I'm confused. People expects PHP/CLI behave like Apache SAPI, CGI SAPI, etc. Well, if I weren't developer and didn't know discussion, I'll certainly write bug report that implicit flush is enabled wrongly. - millions of decent programmers who are used to _usual_ behavior. I consider myself a decent programmer, and I also consider the need to flush explicitly extremely annoying. Moreover, many PHP programmers (if not most) aren't used to this 'usual' behavior, because they either never programmed in another language, or they still didn't bump into that specific behavior. Don't you think flushing is needed only very limited applications? i.e. We don't write interactive CUI applications much now a days. - millions of scripts/echo/print don't need automatic flush at all. i.e. much fewer number of script/echo/print need auto flushing. It doesn't matter. When you're screwed by the lack of implicit flush, it's much worse than a mere slow down. Hmm. Since console is line buffered. There aren't many thing that is missed by implicit flushing. Please list programming languages (i.e. not shell) that do automatic/inefficient/unneeded flushing by default in program mode. Read my fingertips - PHP IN CLI MODE. There's one, that's the only one I care about. My point is we should learn from many smart peoples designs' of languages. If we are argue about difficulty of flushing, We're not. We're arguing about the obscurity of the problem. implicit_flush=On is obscure for current users. Suppose not flushing is extremely obscure, but default is better to set which is better/suitable for more occasions and is better to be consistent with other SAPIs. Is this the main point of auto flushing? If there are other points, please list them. -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I hope this is the last email about this :) (was RF
Derick Rethans wrote:
Yasuo,
can you please stop this discussion now, it's not going to change. It
only wastes time which we could have spend on numerous other things for
PHP, such as fixing bugs and writing tests for the test system.
I don't want to waste my time too. I just trying to make PHP
a little better.
Anyway, can you please stop patching without full knowledge or
understanding issues? If you aren't certain, ask.
Recent examples are:
Makefile.global
- You insisted it should be INI independent without fixing
dependency issue
main.c
- You wrongly applied patch that enable without understanding
the patch is bogus with the code.
(I know you changed code more reasonable later, but it's still
not a good idea)
It's a waste of time, since it just makes discussion harder.
BTW, I think current output buffer code is not good enough.
It's much better to write it with streams. Think about
the implication of implicit flushing by default.
--
Yasuo Ohgaki
On Fri, 25 Oct 2002, Yasuo Ohgaki wrote:
Mike,
It seems my last mail is a bit too negative. Sorry.
Mike Ford wrote:
-Original Message-
From: Yasuo Ohgaki [mailto:yohgaki;ohgaki.net]
Sent: 24 October 2002 07:42
To: [EMAIL PROTECTED]; Alan Knowles
Alan Knowles wrote:
Im +1 for reverting the patch - (for what it's worth)
This makes 2+ for having auto flushing :)
Add one more -- or even more, as I 'd say I'm +1 for this!
BTW, real language (i.e. not shell) don't flush. Please let me
know if there is real language that do automatic flushing by
default.
But PHP-CLI *is* a shell-scripting language, and therefore should behave
like one. Other flavours of PHP aren't, and shouldn't. QED.
I'm referring to actual shell used for user interface, such as
bash, csh.
AFAIK, all shells flushes automatically, but no programing language
that is designed for programming do not flush.
In addition, is it too difficult to write this kind of code?
function prompt($prefix) {
echo $prefix;
flush();
}
I think this kind of code will be taught at the first
class of programming course. (I could be wrong,
since I don't know where people learned programming ;)
At university: learned half-a-dozen languages; *all* of them flushed streams
open on TTY either after every character, or (at line-end or when input
requested from same device). I've been programming now for over 25 years,
and this is *still* the behaviour I expect by default when programming
command-line-executable scripts or programs.
If people would like to a script that can be used as filter,
auto flushing is evil.
If people writing interactive CUI programs,
function prompt($prefix) {
echo $prefix;
flush();
}
is enough.
Line buffering is enough for all most all purposes.
Don't forget auto flushing make system call flush stream twice
with following script always.
echo abc\n;
And flushing is relatively heavy thing to do.
Let's guess something interesting.
How much % of scripts actually needs automatic flushing?
My guess is less than 1%. What is yours?
For PHP-CLI: more than 90%.
For PHP CGI or SAPI: much less than 1%.
I think only very little CLI programs, less than 1%, a few %
at most, need auto flushing.
--
Yasuo Ohgaki
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
--
---
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 http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I hope this is the last email about this :)
I need to add a little. Zeev Suraski wrote: If we are argue about difficulty of flushing, We're not. We're arguing about the obscurity of the problem. Are you going to set output_buffering=Off by default, too? Since the obscurity still exists with output buffers. It's even worse with broken output buffer function. BTW, I don't object to have output_buffering=Off by default for CLI, since it's default of php.ini-dist and it does not make much sense for CLI. However, I objects implicit_flush=On by default for reasons I mentioned. -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I hope this is the last email about this :) (was RF
At 01:22 26-10-2002, Yasuo Ohgaki wrote: Makefile.global - You insisted it should be INI independent without fixing dependency issue Some settings cannot be hardcoded. Granted. Some we may want to hardcode for run-tests.php. Granted. php.ini-dist is not the one to do it with. It's purpose is to provide the default settings, for the DISTribution. You'll get discussions on what is better for run-tests.php, and it shouldn't matter for distribution defaults. Not a good idea. If there should be something to fix, via an ini file, than let's use php.ini-test. But let's agree on this FIRST, before changing stuff in files, that are maintained by people knowing core best, and/or which affects behavior accross the distribution. Met vriendelijke groeten / With kind regards, Webmaster IDG.nl Melvyn Sopacua -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I hope this is the last email about this :) (was RF
Melvyn Sopacua wrote: *SNIP* If there should be something to fix, via an ini file, than let's use php.ini-test. No objection from me, of course. It's even better since we don't care about changes in php.ini-dist. -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I hope this is the last email about this :) (was RFC:
Alan Knowles wrote:
Im +1 for reverting the patch - (for what it's worth)
Why?
Well - most 'average' (and below) PHP programmers when attempting to do
CLI programming, will get a serious WTF reaction from wondering why when
they 'echo' stuff, it doesnt appear. The more advanced Users can
manually turn off flushing, but for most small, quick scripts (eg.
50%+), this instant flush is going to be perfectly acceptable..
This makes 2+ for having auto flushing :)
BTW, real language (i.e. not shell) don't flush. Please let me
know if there is real language that do automatic flushing by
default.
In addition, is it too difficult to write this kind of code?
function prompt($prefix) {
echo $prefix;
flush();
}
I think this kind of code will be taught at the first
class of programming course. (I could be wrong,
since I don't know where people learned programming ;)
I probably disable automatic flushing almost always.
Why? My script will process XML and other formatted
text almost always. Auto-flushing is useless.
Let's guess something interesting.
How much % of scripts actually needs automatic flushing?
My guess is less than 1%. What is yours?
That said, does it still worth to have?
--
Yasuo Ohgaki
Anyway Just my 2c
Regards
Alan
It's a very _bad_ default. Fortunately, it's not released yet.
That's why I'm against it strongly.
IMO, flushing on every output by default is stupid setting.
If you ever programmed interactive programs, you should know
that unless you're ignorant about efficiency.
I guess my questions are too hard to be understood by you
compare to the last one. Derick, it seems you're alone so far.
http://news.php.net/article.php?group=php.devarticle=89995
Do you finally realize your argument actually did not make sense?
(Unless you need stupid PHP/CLI shell that requires start/end tag
to do anything, of course ;)
I'm going to fix it again unless many people want to make
PHP/CLI behave like a shell rather than programming language.
Alternatively, could you fix it again? (including Makefile.global)
Thank you and I hope this is the last mail about this.
PS: If you would like to write INI independent scripts, I
suggest you to use php.ini-recommended at least. You don't/
didn't know phps crashing and make test does not work well with
php.ini-recommended, nonetheless, you're insisting there is no
problems.
--
Yasuo Ohgaki
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Test suite and user space (Was: Re: [PHP-DEV] I hope this is the last email about this :))
At 00:27 24-10-2002, Yasuo Ohgaki wrote:
PS: If you would like to write INI independent scripts, I
suggest you to use php.ini-recommended at least. You don't/
didn't know phps crashing and make test does not work well with
php.ini-recommended, nonetheless, you're insisting there is no
problems.
This is a totally different issue. If ini settings affect the test suite,
it's a bug in the test suite, period. If you depend on a preset environment,
you are testing how things behave in that environment, you are not testing
how that specific build for the __end user__ will behave once installed.
Test authors, can enforce specific settings they need, in the --INI--
section. If other settings affect the tests behavior, it is a good thing (tm)
to know this. It may be totally unexpected and shed light on why certain
bugs surface.
I also removed your statement in README.TESTING, which stated that if a test
fails, the user can see if it's a real bug. There are no maybe's in a test
suite. It's a bug or it isn't. Putting in maybe's makes it's purpose confusing
and unreliable.
This is one of the reasons, that during QA periods, some major bugs are not
uncovered ('file_exists'). People feel like oh well, the test is probably
bogus, and do not report it.
Current work being done on the testsuite is IMO the right direction. Tests for
every function under whatever environment and the option to post to QA so that
the data can now be collected and analyzed.
If you see that the test suite is not working well, with php.ini-recommended,
than please report the tests affected. You don't adjust the road, just because
certain cars, have questionable steering - you fix the cars.
Met vriendelijke groeten / With kind regards,
Webmaster IDG.nl
Melvyn Sopacua
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I hope this is the last email about this :) (was RFC: CLI behave like SH or PERL/RUBY/PYTHON?)
At 02:51 24-10-2002, Alan Knowles wrote: Im +1 for reverting the patch - (for what it's worth) Why? Well - most 'average' (and below) PHP programmers when attempting to do CLI programming, will get a serious WTF reaction from wondering why when they 'echo' stuff, it doesnt appear. The more advanced Users can manually turn off flushing, but for most small, quick scripts (eg. 50%+), this instant flush is going to be perfectly acceptable.. My thoughts exactly. Defaults should work for the masses - it's not like it's enforced behavior, that is irreversible. With kind regards, Melvyn Sopacua ?php include(not_reflecting_employers_views.txt); ? -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I hope this is the last email about this :) (was RFC:
At 08:42 24-10-2002, Yasuo Ohgaki wrote: I think this kind of code will be taught at the first class of programming course. (I could be wrong, since I don't know where people learned programming ;) Why do you assume people learned programming? I think Rasmus has made the case for PHP to be a language that solves problems, not be academically correct, many times on this list. With kind regards, Melvyn Sopacua ?php include(not_reflecting_employers_views.txt); ? -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I hope this is the last email about this :) (was RFC:
Melvyn Sopacua wrote: At 08:42 24-10-2002, Yasuo Ohgaki wrote: I think this kind of code will be taught at the first class of programming course. (I could be wrong, since I don't know where people learned programming ;) Why do you assume people learned programming? I think Rasmus has made the case for PHP to be a language that solves problems, not be academically correct, many times on this list. Sure, some people just learn programming by themselves. Are you trying to say it justifies to have useless settings for almost all scripts? I hope not. They should learn such simple thing even to be Sunday programmer. Beside, the knowledge is useful for other popular languages, C/C++, Java, Perl, Python, Ruby, etc. -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Test suite and user space (Was: Re: [PHP-DEV] I hope this is the last email about this :))
Melvyn Sopacua wrote:
At 00:27 24-10-2002, Yasuo Ohgaki wrote:
PS: If you would like to write INI independent scripts, I
suggest you to use php.ini-recommended at least. You don't/
didn't know phps crashing and make test does not work well with
php.ini-recommended, nonetheless, you're insisting there is no
problems.
This is a totally different issue. If ini settings affect the test suite,
it's a bug in the test suite, period. If you depend on a preset
environment,
you are testing how things behave in that environment, you are not testing
how that specific build for the __end user__ will behave once installed.
Do you realize php.ini used by run-tests.php and phpt differs?
Nothing to do with between them.
Test authors, can enforce specific settings they need, in the --INI--
section. If other settings affect the tests behavior, it is a good thing
(tm)
to know this. It may be totally unexpected and shed light on why certain
bugs surface.
I'm writing the same thing _number_ of times
Do you realize php.ini used by run-tests.php and phpt differs?
Nothing to do with between them.
I also removed your statement in README.TESTING, which stated that if a
test
fails, the user can see if it's a real bug. There are no maybe's in a test
suite. It's a bug or it isn't. Putting in maybe's makes it's purpose
confusing
and unreliable.
That's fine. When I wrote it, there were more than 30% of failed tests
due to improper maintenance of phpt, etc. It was unrealistic to check
them all at that time. I guess you don't know this fact.
This is one of the reasons, that during QA periods, some major bugs are not
uncovered ('file_exists'). People feel like oh well, the test is probably
bogus, and do not report it.
Current work being done on the testsuite is IMO the right direction.
Tests for
every function under whatever environment and the option to post to QA
so that
the data can now be collected and analyzed.
It should be.
That's why I wrote README.TESTING to make test suite better.
If the more people understood tests, the more people help to
maintain ;)
If you see that the test suite is not working well, with
php.ini-recommended,
than please report the tests affected. You don't adjust the road, just
because
certain cars, have questionable steering - you fix the cars.
Do you realize php.ini used by run-tests.php and phpt differs?
Nothing to do with between them.
The more I get reply, the more I believe we should specify
php.ini-dist for run-tests.php. i.e. People are confused.
We do test with phpt, but we shouldn't test run-tests.php.
It's just a waste of time.
Remember, Derick removed the -c option, yet he does not understand
the problem with it, even if I've clearly mentioned _MANY_ times.
This incident is enough to illustrate that people cannot write ini
dependent script even if one has CVS account.
Sometimes simple things became harder to understand...
--
Yasuo Ohgaki
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I hope this is the last email about this :) (was RFC:
At 16:42 10/24/2002 +0900, Yasuo Ohgaki wrote:
Melvyn Sopacua wrote:
At 08:42 24-10-2002, Yasuo Ohgaki wrote:
I think this kind of code will be taught at the first
class of programming course. (I could be wrong,
since I don't know where people learned programming ;)
Why do you assume people learned programming?
I think Rasmus has made the case for PHP to be a language that
solves problems, not be academically correct, many times on this
list.
Sure, some people just learn programming by themselves.
Indeed.
Are you trying to say it justifies to have useless settings for
almost all scripts? I hope not.
No, it justifies less academically correct __overridable defaults__, which are
intuitive for beginners.
Let me emphasize overridable defaults again, just to make sure you get
that I mean overridable defaults.
They should learn such simple thing even to be Sunday programmer.
Beside, the knowledge is useful for other popular languages, C/C++,
Java, Perl, Python, Ruby, etc.
Don't assume people ambition a career in programming, just because they use
a tool, to solve a specific problem they're facing.
/MELVYN
void wakeup() {
for(unsigned int cuppajava;drink();cuppajava++);
}
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I hope this is the last email about this :) (was
Melvyn Sopacua wrote: At 02:51 24-10-2002, Alan Knowles wrote: Im +1 for reverting the patch - (for what it's worth) Why? Well - most 'average' (and below) PHP programmers when attempting to do CLI programming, will get a serious WTF reaction from wondering why when they 'echo' stuff, it doesnt appear. The more advanced Users can manually turn off flushing, but for most small, quick scripts (eg. 50%+), this instant flush is going to be perfectly acceptable.. My thoughts exactly. Defaults should work for the masses - it's not like it's enforced behavior, that is irreversible. ? Which mass ? Are you going to insist most scripts need inefficient auto flushing? Have you ever used other programming languages? I don't get it, but this is the 3rd vote. Too few still and reasoning is too weak. BTW, if anyone would like to vote for inefficient/mostly useless auto flushing. Please add your vote to this article. http://news.php.net/article.php?group=php.devarticle=89995 -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I hope this is the last email about this :) (was
On Thu, 24 Oct 2002, Yasuo Ohgaki wrote: Melvyn Sopacua wrote: My thoughts exactly. Defaults should work for the masses - it's not like it's enforced behavior, that is irreversible. ? Which mass ? Are you going to insist most scripts need inefficient auto flushing? __ __ \ \ / /__ ___ \ V / _ \/ __| | | __/\__ \ |_|\___||___/ , because it is inituitive for a COMMAND line interface to flush after every outputted character. If you DONT want this inituitive bahavior you _can_ override it _anytime_ you want. Have you ever used other programming languages? Tons of them, starting with pascal about 10 years ago, and did certainly flush after every character. I don't get it, but this is the 3rd vote. Too few still and reasoning is too weak. As you're clearly not listening to other people's comments I'm going to put that line back into php_cli.c as the only flawed reasoning is yours. 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 http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I hope this is the last email about this :) (was RFC:
This has nothing to do with academical correctness. Flushing or not flushing is not a matter of right or wrong, it's a matter of choice. There's one 'real language' that does automatic flushing, it's called PHP, and it's going to stay that way. Why other languages chose not to do it (maybe they don't have the facilities to do it?) is beside the point and not all that interesting. Thank you. Zeev At 09:17 24/10/2002, Melvyn Sopacua wrote: At 08:42 24-10-2002, Yasuo Ohgaki wrote: I think this kind of code will be taught at the first class of programming course. (I could be wrong, since I don't know where people learned programming ;) Why do you assume people learned programming? I think Rasmus has made the case for PHP to be a language that solves problems, not be academically correct, many times on this list. With kind regards, Melvyn Sopacua ?php include(not_reflecting_employers_views.txt); ? -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I hope this is the last email about this :) (was
At 10:01 24/10/2002, Yasuo Ohgaki wrote: Melvyn Sopacua wrote: At 02:51 24-10-2002, Alan Knowles wrote: Im +1 for reverting the patch - (for what it's worth) Why? Well - most 'average' (and below) PHP programmers when attempting to do CLI programming, will get a serious WTF reaction from wondering why when they 'echo' stuff, it doesnt appear. The more advanced Users can manually turn off flushing, but for most small, quick scripts (eg. 50%+), this instant flush is going to be perfectly acceptable.. My thoughts exactly. Defaults should work for the masses - it's not like it's enforced behavior, that is irreversible. ? Which mass ? Are you going to insist most scripts need inefficient auto flushing? Have you ever used other programming languages? I don't get it, but this is the 3rd vote. Too few still and reasoning is too weak. Too few? It's 3 times more than the votes in favour, and now it's 4 times more. Too weak? That's your opinion, and it doesn't weigh more than others'. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I hope this is the last email about this :)
Zeev Suraski wrote:
At 10:01 24/10/2002, Yasuo Ohgaki wrote:
Melvyn Sopacua wrote:
At 02:51 24-10-2002, Alan Knowles wrote:
Im +1 for reverting the patch - (for what it's worth)
Why?
Well - most 'average' (and below) PHP programmers when attempting to
do CLI programming, will get a serious WTF reaction from wondering
why when they 'echo' stuff, it doesnt appear. The more advanced
Users can manually turn off flushing, but for most small, quick
scripts (eg. 50%+), this instant flush is going to be perfectly
acceptable..
My thoughts exactly. Defaults should work for the masses - it's not
like it's enforced behavior, that is irreversible.
? Which mass ?
Are you going to insist most scripts need inefficient auto flushing?
Have you ever used other programming languages?
I don't get it, but this is the 3rd vote.
Too few still and reasoning is too weak.
Too few? It's 3 times more than the votes in favour, and now it's 4
times more. Too weak? That's your opinion, and it doesn't weigh more
than others'.
I'm mentioning weakness of reasoning. At least, I was tried to ;)
My thoughts exactly. Defaults should work for the masses - it's not
like it's enforced behavior, that is irreversible.
implies most/many scripts/users need additional flushing.
This is obviously wrong.
Only very small portion of scripts need flushing for every outputs.
(I'm guessing, but nobody objects right?)
Even when flushing is needed
function prompt($prefix) {
echo $prefix;
flush();
}
is _TRIVIAL_ to write. People should have this kind of
function instead of enabling inefficient implicit flushing
since it's more efficient and reliable.
Therefore, "enabling it for the *mass*/ intuitive for users"
does not make sense, hence weak reasoning.
If implicit flush is preferred for some scripts, it should be
enabled when it is needed because the needs is obviously fewer.
I agree, it's a choice but there is good and bad even
if it's not clear sometimes.
Why don't we follow simple rule "more needs" = default,
"less needs" = optional especially when it's easy to switch.
(we haven't released it yet :)
BTW, please vote to this thread. It easier to follow who is
voting for.
http://news.php.net/article.php?group=php.devarticle=89995
Anyway, what kind of default we have for implicit flush in
php.ini-dest/recommended now and in the future? We have _OFF_
by default. It also help us to make better decision, IMO.
Default OFF is more intuitive, IMHO.
--
Yasuo Ohgaki
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I hope this is the last email about this :)
Just wanted to add little more emphasis for the reason why I say "weak reasoning". My thoughts exactly. Defaults should work for the masses - it's not like it's enforced behavior, that is irreversible. Anyway, what kind of default we have for implicit flush in php.ini-dest/recommended now and in the future? We have _OFF_ by default. It also help us to make better decision, IMO. Default OFF is more intuitive, IMHO. I'm talking virtually all current users who are used to implicit_flush=Off by default. This should be called the *MASSES*. -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] I hope this is the last email about this :) (was
-Original Message- From: Yasuo Ohgaki [mailto:yohgaki;ohgaki.net] Sent: 24 October 2002 09:01 To: [EMAIL PROTECTED]; Melvyn Sopacua Are you going to insist most scripts need inefficient auto flushing? For CLI, yes. Have you ever used other programming languages? Yes -- over 40 at last count! (Even written the odd compiler in my time!) I don't get it, but this is the 3rd vote. Too few still and reasoning is too weak. BTW, if anyone would like to vote for inefficient/mostly useless auto flushing. Please add your vote to this article. http://news.php.net/article.php?group=php.devarticle=89995 I would, but I can't see any way of replying/voting on the page that URL takes me to...! Cheers! Mike - Mike Ford, Electronic Information Services Adviser, Learning Support Services, Learning Information Services, JG125, James Graham Building, Leeds Metropolitan University, Beckett Park, LEEDS, LS6 3QS, United Kingdom Email: [EMAIL PROTECTED] Tel: +44 113 283 2600 extn 4730 Fax: +44 113 283 3211 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] I hope this is the last email about this :) (was RFC:
-Original Message-
From: Yasuo Ohgaki [mailto:yohgaki;ohgaki.net]
Sent: 24 October 2002 07:42
To: [EMAIL PROTECTED]; Alan Knowles
Alan Knowles wrote:
Im +1 for reverting the patch - (for what it's worth)
This makes 2+ for having auto flushing :)
Add one more -- or even more, as I 'd say I'm +1 for this!
BTW, real language (i.e. not shell) don't flush. Please let me
know if there is real language that do automatic flushing by
default.
But PHP-CLI *is* a shell-scripting language, and therefore should behave
like one. Other flavours of PHP aren't, and shouldn't. QED.
In addition, is it too difficult to write this kind of code?
function prompt($prefix) {
echo $prefix;
flush();
}
I think this kind of code will be taught at the first
class of programming course. (I could be wrong,
since I don't know where people learned programming ;)
At university: learned half-a-dozen languages; *all* of them flushed streams
open on TTY either after every character, or (at line-end or when input
requested from same device). I've been programming now for over 25 years,
and this is *still* the behaviour I expect by default when programming
command-line-executable scripts or programs.
Let's guess something interesting.
How much % of scripts actually needs automatic flushing?
My guess is less than 1%. What is yours?
For PHP-CLI: more than 90%.
For PHP CGI or SAPI: much less than 1%.
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I hope this is the last email about this :)
At 12:23 24/10/2002, Yasuo Ohgaki wrote:
function prompt($prefix) {
echo $prefix;
flush();
}
is _TRIVIAL_ to write. People should have this kind of
function instead of enabling inefficient implicit flushing
since it's more efficient and reliable.
You print something, it doesn't print out. How is it trivial to solve
this? If you happen to know that there's IO buffering and that there's a
function called flush() then maybe it trivial, but then there are the other
million users who don't. Hence the idea of setting is to implicit flush
for the masses, who not only don't know about the existence of flush(), but
also don't know why it's even necessary.
Zeev
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I hope this is the last email about this :) (was RFC:CLI behave like SH or PERL/RUBY/PYTHON?)
Derick Rethans wrote: 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 Derick, It's a very _bad_ default. Fortunately, it's not released yet. That's why I'm against it strongly. IMO, flushing on every output by default is stupid setting. If you ever programmed interactive programs, you should know that unless you're ignorant about efficiency. I guess my questions are too hard to be understood by you compare to the last one. Derick, it seems you're alone so far. http://news.php.net/article.php?group=php.devarticle=89995 Do you finally realize your argument actually did not make sense? (Unless you need stupid PHP/CLI shell that requires start/end tag to do anything, of course ;) I'm going to fix it again unless many people want to make PHP/CLI behave like a shell rather than programming language. Alternatively, could you fix it again? (including Makefile.global) Thank you and I hope this is the last mail about this. PS: If you would like to write INI independent scripts, I suggest you to use php.ini-recommended at least. You don't/ didn't know phps crashing and make test does not work well with php.ini-recommended, nonetheless, you're insisting there is no problems. -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I hope this is the last email about this :) (was RFC: CLI behave like SH or PERL/RUBY/PYTHON?)
I thought that we have agreed that you should revert the patch. You can now change the default behavior by both ini_set() and .the -d switch if you don't like the default. Edin On Thursday 24 October 2002 00:27, Yasuo Ohgaki wrote: Derick Rethans wrote: 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 Derick, It's a very _bad_ default. Fortunately, it's not released yet. That's why I'm against it strongly. IMO, flushing on every output by default is stupid setting. If you ever programmed interactive programs, you should know that unless you're ignorant about efficiency. I guess my questions are too hard to be understood by you compare to the last one. Derick, it seems you're alone so far. http://news.php.net/article.php?group=php.devarticle=89995 Do you finally realize your argument actually did not make sense? (Unless you need stupid PHP/CLI shell that requires start/end tag to do anything, of course ;) I'm going to fix it again unless many people want to make PHP/CLI behave like a shell rather than programming language. Alternatively, could you fix it again? (including Makefile.global) Thank you and I hope this is the last mail about this. PS: If you would like to write INI independent scripts, I suggest you to use php.ini-recommended at least. You don't/ didn't know phps crashing and make test does not work well with php.ini-recommended, nonetheless, you're insisting there is no problems. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I hope this is the last email about this :) (was RFC:CLI behave like SH or PERL/RUBY/PYTHON?)
Edin Kadribasic wrote: I thought that we have agreed that you should revert the patch. You can now change the default behavior by both ini_set() and .the -d switch if you don't like the default. Yes. It's ok as a temporally solution, but not as a long term. I explicitly wrote I would like to see how it affects to Windows platform for few days and will modify the line afterwards. (Markus mentioned the setting may be needed for Windows) Anyway, it seems there is problems in ini handling code. If it's the case, we're better to fix everything now. http://news.php.net/article.php?group=php.devarticle=89995 This should explain the reason behind. Don't you think other language developers will make fun of the default auto flushing feature? If I were, I'll. The default is stupid and only Derick likes it, I suppose. ;) -- Yasuo Ohgaki Edin On Thursday 24 October 2002 00:27, Yasuo Ohgaki wrote: Derick Rethans wrote: 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 Derick, It's a very _bad_ default. Fortunately, it's not released yet. That's why I'm against it strongly. IMO, flushing on every output by default is stupid setting. If you ever programmed interactive programs, you should know that unless you're ignorant about efficiency. I guess my questions are too hard to be understood by you compare to the last one. Derick, it seems you're alone so far. http://news.php.net/article.php?group=php.devarticle=89995 Do you finally realize your argument actually did not make sense? (Unless you need stupid PHP/CLI shell that requires start/end tag to do anything, of course ;) I'm going to fix it again unless many people want to make PHP/CLI behave like a shell rather than programming language. Alternatively, could you fix it again? (including Makefile.global) Thank you and I hope this is the last mail about this. PS: If you would like to write INI independent scripts, I suggest you to use php.ini-recommended at least. You don't/ didn't know phps crashing and make test does not work well with php.ini-recommended, nonetheless, you're insisting there is no problems. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I hope this is the last email about this :) (was RFC:CLI behave like SH or PERL/RUBY/PYTHON?)
Im +1 for reverting the patch - (for what it's worth) Why? Well - most 'average' (and below) PHP programmers when attempting to do CLI programming, will get a serious WTF reaction from wondering why when they 'echo' stuff, it doesnt appear. The more advanced Users can manually turn off flushing, but for most small, quick scripts (eg. 50%+), this instant flush is going to be perfectly acceptable.. Anyway Just my 2c Regards Alan It's a very _bad_ default. Fortunately, it's not released yet. That's why I'm against it strongly. IMO, flushing on every output by default is stupid setting. If you ever programmed interactive programs, you should know that unless you're ignorant about efficiency. I guess my questions are too hard to be understood by you compare to the last one. Derick, it seems you're alone so far. http://news.php.net/article.php?group=php.devarticle=89995 Do you finally realize your argument actually did not make sense? (Unless you need stupid PHP/CLI shell that requires start/end tag to do anything, of course ;) I'm going to fix it again unless many people want to make PHP/CLI behave like a shell rather than programming language. Alternatively, could you fix it again? (including Makefile.global) Thank you and I hope this is the last mail about this. PS: If you would like to write INI independent scripts, I suggest you to use php.ini-recommended at least. You don't/ didn't know phps crashing and make test does not work well with php.ini-recommended, nonetheless, you're insisting there is no problems. -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
