Re: [PHP-DEV] emalloc() troubles
Derick Rethans wrote: On Sat, 28 Dec 2002, Yasuo Ohgaki wrote: PHP shouldn't leak memory even if output/input from/to external program differs. It seems it's a PHP problem for this matter. If you had read the thread you would have seen that the memory leak is only there in his patch. I realized that now. Anyway, if there is problem with qmail, I'll fix it iff I think it's really a problem. Ari hasn't sent me detailed problem description, yet. -- Yasuo Ohgaki Derick Ari Pollak wrote: Unless you come up with a way to migrate 500+ virtualhosts to some other MTA, no, that is not feasible. You can think of qmail like minix in both author and license, in that the author is really arrogant about changing the way his software behaves even though it's not standards-compliant, and you can't distribute modified binaries. And qmail has been on the same version for many years, so nobody is expecting him to actually put out a new version anytime soon. In any case, I'm not expecting any qmail patch to actually go into PHP, but I'd really like to get this memory leak fixed for those who need this patch (me). On Fri, Dec 27, 2002 at 11:00:32AM -0500, George Schlossnagle wrote: qmail devs == djb, right? If his support doesn't suffice (and you cant find it in the enormous un-merged patch contributions that seem to litter the qmail community websites), might I suggest a new MTA? Exim works quite nicely. -- 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] emalloc() troubles
I didn't know you have cvs access. Then I'll leave the problem alone :) -- Yasuo Ohgaki Ari Pollak wrote: Again, I told you that I already fixed the problem from within PHP, but there's just one memory leak that I can't track down. On Sun, Dec 29, 2002 at 06:39:18PM +0900, Yasuo Ohgaki wrote: I realized that now. Anyway, if there is problem with qmail, I'll fix it iff I think it's really a problem. Ari hasn't sent me detailed problem description, yet. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] emalloc() troubles
PHP shouldn't leak memory even if output/input from/to external program differs. It seems it's a PHP problem for this matter. Are you sure your input to mail() is RFC compliant? Even if input is not RFC compliant, PHP shouldn't leak memory, though. -- Yasuo Ohgaki Ari Pollak wrote: Unless you come up with a way to migrate 500+ virtualhosts to some other MTA, no, that is not feasible. You can think of qmail like minix in both author and license, in that the author is really arrogant about changing the way his software behaves even though it's not standards-compliant, and you can't distribute modified binaries. And qmail has been on the same version for many years, so nobody is expecting him to actually put out a new version anytime soon. In any case, I'm not expecting any qmail patch to actually go into PHP, but I'd really like to get this memory leak fixed for those who need this patch (me). On Fri, Dec 27, 2002 at 11:00:32AM -0500, George Schlossnagle wrote: qmail devs == djb, right? If his support doesn't suffice (and you cant find it in the enormous un-merged patch contributions that seem to litter the qmail community websites), might I suggest a new MTA? Exim works quite nicely. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] emalloc() troubles
Ari Pollak wrote: PHP isn't leaking memory, my modification to the mail() function is leaking memory, as said earlier in this thread, which is what's troubling me because I can't track down what's leaking. Ah. I see. I'm using qmail, but I don't realize problem you have mentioned. What kind of address format are you using? Please send me to a a short reproducing script. If I think the problem should be took care of, I'll take care of it. -- Yasuo Ohgaki Yasuo Ohgaki said: PHP shouldn't leak memory even if output/input from/to external program differs. It seems it's a PHP problem for this matter. Are you sure your input to mail() is RFC compliant? Even if input is not RFC compliant, PHP shouldn't leak memory, though. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php.exe - php-cgi.exe
Sebastian Nohn wrote:
(B Jan Schneider schrieb:
(B
(BI know this thread is ridden to death but I want to add
(Bone argument for
(Bcompleteness: If the cgi's name will be changed,
(Bthousands of administrators
(Bneed to fix their servers. But if the cli's name will be
(Bchanged thousands
(Bof "end users" of php cli scripts will have to change the
(Bscripts' shebang line.
(B
(BI have no idea if there are more administrators who have
(Bto care about php
(Bcgi or users who use php cli. But at least the first
(Bgroup will have less
(Bproblems fixing the name change than the latter.
(B
(B
(B
(B PHP-CLI was experimental so far, so anyone who uses it has to be aware
(B of any changes that can happen. PHP-CGI is very far from being
(B experimental. I have no problem with all that renaming thing, but if we
(B rename the CGI-PHP to php-cgi we should do it with php5, because more
(B people will realize that a lot of things change between 4.x and 5.x.
(B For psychological numbering-reasons people don't see any change between
(B 4.2 and 4.3.
(B
(BI guess Jan is trying to say, people are using CGI binary for
(Bgeneral scripting. If they want to switch to CLI for general
(Bscripting, they have to rename binary to use CLI.
(B
(Bi.e. from "#!/usr/local/bin/php -q" to "#!/usr/local/bin/php-cli"
(B
(BBTW, people may want to add ini_set('implicit_flush','off);
(Bto all of their CLI scripts to prevent needless/redundant
(Bflushing anyway, though. (CLI flushes on every output by
(Bdefault not like CGI)
(B
(Be.g. ?php echo "Hello world\n" ? makes system flush output
(Btwice on char devices, once for block devices.
(B
(BAdding needless flushing is stupid, since flushing is rather
(Bexpensive as some of you know.
(B
(B--
(BYasuo Ohgaki
(B
(B
(B--
(BPHP Development Mailing List http://www.php.net/
(BTo unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php.exe - php-cgi.exe
I'm a little surprised that people from Zend is rather prefer to call php for CGI and php-cli for CLI. IMO, Zend products, such as Zend Encoder or Zend IDE, have more chance to sell if PHP is used as replacement for Perl or Python (or even Java). The name of command line interface may not affect sales of Zend products, though. Just my .02 -- Yasuo Ohgaki Zeev Suraski wrote: At 19:46 09/12/2002, Andrei Zmievski wrote: On Mon, 09 Dec 2002, Andi Gutmans wrote: ducking Maybe phpsh would be a good idea for the name of the CLI? It wouldn't confuse ppl as much as php-cli /ducking I'm really not that sure it makes sense to rename the CGI from php to php-cgi after such a long time. It's not as if we're breaking BC for the sake of adding very much needed functionality. Anyway, I'm -0 for the change and +0 to find a more suitable name for the CLI :) I am actually in favor of CLI executable being 'php'. If it's a problem on Windows, then we could possibly compromise and have the CGI version being called php.exe, but I think that it's important we keep it 'php' on UNIX. Why? PHP as a shell is going to be used by only a fragment of the amount of users who use it as a CGI. In most senses, it's much more PHP than the CLI is. Even though the old version was being used as a shell, it was still quite clear that it is the CGI version. And it is quite clear that the CLI version is the one that's new... Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 4.2.3 mbstring patch?
Andrei Zmievski wrote: On Thu, 14 Nov 2002, lowbwtom wrote: Will there be a patch to fix the mbstring bug in 4.2.3? Any idea when? (specifically to fix the missing 4 characters in array posts) Some of us have been totally screwed by this bug - since our isp's have updated to 4.2.3 and left everyone's sites totally broken. They refuse to drop back to old version and are leaving everyone up the creek until php 4.3.0 is in final release or a 4.2.3 patch is released. For the love of PHP, give me relief! While it's not directly on topic of this post, this is *exactly* why mbstring will not be enabled by default in 4.3.0. This is one of the reason why we should *enable* mbstring by default i.e. discover sloppy patches to it. (BTW, I don't use array, since [] are illegal chars) Anyway, this the patch if you would like. http://cvs.php.net/diff.php/php4/ext/mbstring/mbstring.c?login=2r1=1.48.2.14r2=1.48.2.17ty=u -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 4.2.3 mbstring patch?
Additional note, since it seems it's misleading. Yasuo Ohgaki wrote: This is one of the reason why we should *enable* mbstring by default i.e. discover sloppy patches to it. The bug was introduced between 4.2.2 and 4.2.3. -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mbstring and 4.3.0
Derick Rethans wrote: On Wed, 13 Nov 2002, Yasuo Ohgaki wrote: Jani Taskinen wrote: Oh, I forgot: How many bug reports have we got so far for that fuckup with 4.2.3 ??? I _REALLY_ don't want to see another wave of those for 4.3.0.. Do you mean array input handling bug? It's not mbstring developers' fault. It doesn't really matter who's fault it was, it's a fact that the mbstring module caused this fuckup. This would be the reason why it should be enabled by default. Bug is reported repeatedly even if it isn't enabled by default. Most importantly, person who patched didn't test the patch well since it isn't enabled by default probably. -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mbstring and 4.3.0
Andrei Zmievski wrote: Explain to me please why --enable-mbstring is not enough. Obviously, --enable-mbstring is not enough. There are several reasons including crashes without mbstring. If one think it's not stable (while real users do not think its unstable), --enable mbstring should be enough. There are problems --disable-mbstirng or --enable-mbstring=shared, but it's users problem, if it's enabled by default. -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mbstring and 4.3.0
Moriyoshi Koizumi wrote: Hi, Thanks for the report. Although I found a bug in the overloading code, I wonder why the mail() function entry was not found on RINIT. Any insights? If sendmail binary cannot be found at configure time, mail() may not be compiled in PHP under UNIX like OS :( IMO, we should always compile mail() function. Distributors sometimes release PHP packages (i.e. RPM) w/o mail() sometimes. -- Yasuo Ohgaki Moriyoshi Ilia A. [EMAIL PROTECTED] wrote: On November 7, 2002 10:04 am, Andrei Zmievski wrote: At the PHP Conference in Germany several of us have discussed the current state of mbstring and there was a proposal to not have it enabled by default for 4.3.0 release. It seems that the extension attempts to do magic stuff by overloading functions in the executor globals and, as Thies said, that could be dangerous. Also, doesn't it affect run-tests.php script currently? On the note of overloading done by mbstring, it appears this behavior is not entirely stable. On at least one test system (Sun OS 5.9) it causes crashes and overruns by using the test script in the test suite. Ex: sapi/cli/php -d mbstring.func_overload=1 -r '' Unknown(0) : Fatal error - (null)() [http://www.php.net/ref.mbstring]: mbstring couldn't find function mail. Could not startup. [Tue Nov 12 21:01:33 2002] Script: '-' --- php4/Zend/zend_execute.h(44) : Block 0x001FB640 status: Beginning: Overrun (magic=0x001FE7F8, expected=0x7312F8DC) End: Unknown --- The test script itself (ext/mbstring/tests/overload.phpt) causes a segmentation fault. Here is a back trace: #0 0x001528f8 in shutdown_memory_manager (silent=1, clean_cache=1) at php4/Zend/zend_alloc.c:461 #1 0x0011d944 in php_module_shutdown () at php4/main/main.c:1219 #2 0x0018d8d0 in main (argc=39, argv=0xffbffa74) at php4/sapi/cli/php_cli.c:761 Ilia -- 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] mbstring and 4.3.0
Mike Robinson wrote: Jani Taskinen writes: I must (still) agree. +1 for making it disabled for now.. (people who need it, already know to use --enable-mbstring with 4.2.3) Exactly. It should remain off by default until it's solid. Guys, please comment when you use it actually. i.e. mention unsolid things, problems, etc. Bug reports are welcome. -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mbstring and 4.3.0
Jani Taskinen wrote: Oh, I forgot: How many bug reports have we got so far for that fuckup with 4.2.3 ??? I _REALLY_ don't want to see another wave of those for 4.3.0.. Do you mean array input handling bug? It's not mbstring developers' fault. -- Yasuo Ohgaki On Wed, 13 Nov 2002, Marcus Börger wrote: At 23:56 12.11.2002, Ilia A. wrote: Since I've gotten involved in this conversation would like to add my opinion to the tally. I too believe that at least at this point, the mbstring extension should not be enabled by default. There are two reasons for this decision: 1) Majority of PHP users do not require this functionality. Most PHP programs are developed with non-multibyte languages in mind and mbstring only adds unnecessary overhead. People who need it can easily enable it or ask their ISPs to enable it, if they had done so already. NO. Most people do not have the choice and ISPs usually take the default. If the default is not approriate they do not use it. If you read the whole thread you find enough reasons how apps benefit from mbstring and what could be easily achieved with languages like german. 2) mbstring extension is a fairly complex piece of code and iirc is the youngest extension of this magnitude that is enabled by default. Although the extension developers are very prompt at fixing bugs, the fact they need to do this fairly frequently, at least to me, implies that the extension is not yet mature enough to be enabled by default. Also, judging by the number of changes in the CVS to the extension, a lot of new functionality was added to the extension recently and has not been tested outside the pre process. Maybe by next PHP release is made, it will be better tested and more stable. Ilia Ok there are some problems and that is the backside of it: Some of us implement new functionality and some merge code from the original development tree. In other words: Maybe we should slow down or even stop feature development until 4.3 is out After php 4.3 we hope the new implementation can be used. As long as function overloading isn't used there is no harm from mbstring (disable is the default). And some extra bytes shouldn't affect anybody today. If you say most apps are not designed to use mbstring then it's nice that all those could try mbstring which would like to. So we can get feedback. As long as it isn't default there will be none or only little feedback. The stability is very high and we have many *.phpt tests to help us find failures and make it even more stable. marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mbstring and 4.3.0
Andrei Zmievski wrote: I very much agree and am extremly reluctant to have mbstring enabled by default, even though it is a very promising extension. I can change my mind only if someone writes smart module loader that detects module dependency. Otherwise, it's just confusing. i.e. undefined symbol errors from modules depend on mbstring. PHP dies badly with it obviously. Disabling it is the same as asking for troubles. I'm 0 iff there is smart loader patch. -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: mbstring and 4.3.0
Andrei Zmievski wrote: At the PHP Conference in Germany several of us have discussed the current state of mbstring and there was a proposal to not have it enabled by default for 4.3.0 release. It seems that the extension attempts to do magic stuff by overloading functions in the executor globals and, as Thies said, that could be dangerous. Also, doesn't it affect run-tests.php script currently? AFAIK, it doesn't. Comments are welcome. Encoding translation, which is hard coded in 4.2.x or less, is integrated and changeable by php.ini or .htaccess setting. And it's default to off. Function overloading is changeable by php.ini or .htaccess. It gives flexibility porting single byte application to multibyte aware with a lot less hassle. It's default to off and only changeable by INI_SYSTEM and INI_PERDIR. PHP 4.3.0's Zend Engine also comes with SJIS awareness. It does not make sense to have SJIS awareness without mbstring also. (Need compile option to enable SJIS awareness) There are few modules that depend on mbstring. Current module loader is not smart enough to detect dependency, too. Unfortunately, PHP 4.2.3 has problem for handling array inputs, but it's not mbstring developers' fault. -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: cvs: php4 / Makefile.global run-tests.php
Yasuo Ohgaki wrote: Derick, I've pointed out problems _WEEKS_ ago. I let you know problems _MANY_ times. Derick, be responsible with your change and opinion at least. Don't forget you're the one broke it w/o discussion first. When I add -c php.ini-dist, there is discussion. As a result, there is -c option. Please revert your patch. (And don't forget to remove double -d 'safe_mode=0') I don't see commit that fixes problems yet. When you'll do that? -- Yasuo Ohgaki BTW, everyone agree with Derick's statement for such a simple obvious bug fixes with CVS managed sources? -- Yasuo Ohgaki Derick Rethans wrote: On Thu, 31 Oct 2002, Yasuo Ohgaki wrote: Derick Rethans wrote: derickThu Oct 31 09:02:00 2002 EDT Modified files: /php4Makefile.global run-tests.php Log: Discuss first! Huh? What do you mean discuss first? There is discussion and the patch is valid. In addition, you're the one insisted certain ini should not be used. Let me know how you would like to solve puzzle. For instance, if users is disabling some functions that are needed by run-tests.php? You should have clever idea that I cannot think of ;) Authors: Ilia Alshanetsky [EMAIL PROTECTED] Preston L. Bannister [EMAIL PROTECTED] Marcus Boerger [EMAIL PROTECTED] Derick Rethans [EMAIL PROTECTED] Sander Roobol [EMAIL PROTECTED] Those people commit to run-tests.php from now, whether a patch is valid or not. If too much other people keep messing with it we will never get a valid and stable testsuite. Derick -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] shared build fails. gettext and imap
Recent CVS source fails to build gettext and imap (Bas shared module with my Linux. (B (BAnyone can build them as shared module? (B (B-- (BYasuo Ohgaki (B (B (B-- (BPHP Development Mailing List http://www.php.net/ (BTo unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: RfC: *_fetch_object()
I don't mind making pg_fetch_object() accept object (not class)
(Boptionally and initialize field values as object's properties.
(B
(BHow about other db module maintainers?
(B
(BBTW, pg_fetch_object() accepted 3rd optional parameter
(Bfor a long time. I've disabled it recently, since having
(B$obj-1, $obj-2, and so on does not make much sense.
(B(It can be accessible via. variable variable, but not
(Bdirectly) Some db modules may be needed to overload behavior
(Bdepend on parameter types.
(B
(B--
(BYasuo Ohgaki
(B
(BTimm Friebe wrote:
(B Hi,
(B what does everyone think about adding a second parameter to the
(B *_fetch_object() functions (sybase_fetch_object, mysql_fetch_object, ...
(B etc.) which allows users to define a class name which will then be used
(B instead of "stdClass"?
(B
(B E.g.:
(B class Article {
(B var $article_id, $caption, $text;
(B }
(B
(B $q= sybase_query('select * from article where article_id= 1');
(B if ($q) while ($a= sybase_fetch_object($q, 'Article')) {
(B var_dump($a);
(B }
(B
(B This saves a couple of lines of code in PHP (formerly, you'd either put
(B all of article's attributes in the constructor, made the constructor
(B accept an associative array or assigned all of the attributes like this:
(B
(B $a= new Article();
(B $a-article_id= $row['article_id'];
(B $a-caption= $row['caption'];
(B $a-text= $row['text'];
(B
(B ) all of which seems ugly and looks like unnecessary overhead. Since PHP
(B is missing a cast working on user-defined types (
(B
(B while ($o= sybase_fetch_object($q)) {
(B $a= (Article)$o;
(B }
(B
(B ) there would be another suggestion to introduce a function cast:
(B
(B while ($o= sybase_fetch_object($q)) {
(B $a= cast($o, 'Article');
(B }
(B
(B Though maybe the name isn't ideal and could be implemented in userland,
(B too (
(B function cast($var, $type) {
(B // [...Handle non-objects and normal types...]
(B // [...Handle non-existant classes w/ name $type...]
(B $ret= new $type();
(B foreach (get_object_vars($var) as $k= $v) {
(B $ret-$k= $v;
(B }
(B return $ret;
(B }
(B
(B ) but with more performance issues than if it was built-in. Maybe it's
(B even simpler to allow (MyType)$var syntax, but this would have to be
(B introduced into Zend Engine.
(B
(B Thoughts?
(B
(B
(B
(B--
(BPHP Development Mailing List http://www.php.net/
(BTo unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: cvs: php4 / Makefile.global run-tests.php
Derick Rethans wrote:
(B derickThu Oct 31 09:02:00 2002 EDT
(B
(B Modified files:
(B /php4 Makefile.global run-tests.php
(B Log:
(B Discuss first!
(B
(BHuh? What do you mean discuss first?
(BThere is discussion and the patch is valid.
(B
(BIn addition, you're the one insisted certain ini should
(Bnot be used.
(B
(BLet me know how you would like to solve puzzle. For instance,
(Bif users is disabling some functions that are needed by
(Brun-tests.php?
(B
(BYou should have clever idea that I cannot think of ;)
(B
(B--
(BYasuo Ohgaki
(B
(B
(B
(B Index: php4/Makefile.global
(B diff -u php4/Makefile.global:1.38 php4/Makefile.global:1.39
(B --- php4/Makefile.global:1.38 Thu Oct 31 08:52:58 2002
(B +++ php4/Makefile.global Thu Oct 31 09:01:58 2002
(B @@ -50,7 +50,7 @@
(B @TEST_PHP_EXECUTABLE=$(top_builddir)/$(SAPI_CLI_PATH) \
(BTEST_PHP_SRCDIR=$(top_srcdir) \
(BCC=$(CC) \
(B - $(top_builddir)/$(SAPI_CLI_PATH) -d 'open_basedir=' -d
(B'safe_mode=0' -d 'safe_mode=0' -d 'output_buffering=Off' -d 'auto_prepend_file=' -d
(B'auto_append_file=' -d 'output_handler=' -d 'register_argv=1' -d 'disable_functions='
(B$(top_srcdir)/run-tests.php $(TESTS)
(B + $(top_builddir)/$(SAPI_CLI_PATH) -d 'open_basedir=' -d
(B'safe_mode=0' $(top_srcdir)/run-tests.php $(TESTS)
(B
(B clean:
(B find . -name \*.lo -o -name \*.o | xargs rm -f
(B Index: php4/run-tests.php
(B diff -u php4/run-tests.php:1.103 php4/run-tests.php:1.104
(B --- php4/run-tests.php:1.103 Thu Oct 31 08:52:58 2002
(B +++ php4/run-tests.phpThu Oct 31 09:01:58 2002
(B @@ -44,9 +44,8 @@
(B
(B $cwd = getcwd();
(B set_time_limit(0);
(B +ob_implicit_flush();
(B error_reporting(E_ALL);
(B -ini_set('magic_quotes_runtime', 0);
(B -ini_set('memory_limit', '8M');
(B
(B if (ini_get('safe_mode')) {
(B echo SAFE_MODE_WARNING
(B
(B
(B
(B
(B--
(BPHP Development Mailing List http://www.php.net/
(BTo unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: cvs: php4 / Makefile.global run-tests.php
Derick, I've pointed out problems _WEEKS_ ago. I let you know problems _MANY_ times. Derick, be responsible with your change and opinion at least. Don't forget you're the one broke it w/o discussion first. When I add -c php.ini-dist, there is discussion. As a result, there is -c option. Please revert your patch. (And don't forget to remove double -d 'safe_mode=0') BTW, everyone agree with Derick's statement for such a simple obvious bug fixes with CVS managed sources? -- Yasuo Ohgaki Derick Rethans wrote: On Thu, 31 Oct 2002, Yasuo Ohgaki wrote: Derick Rethans wrote: derick Thu Oct 31 09:02:00 2002 EDT Modified files: /php4 Makefile.global run-tests.php Log: Discuss first! Huh? What do you mean discuss first? There is discussion and the patch is valid. In addition, you're the one insisted certain ini should not be used. Let me know how you would like to solve puzzle. For instance, if users is disabling some functions that are needed by run-tests.php? You should have clever idea that I cannot think of ;) Authors: Ilia Alshanetsky [EMAIL PROTECTED] Preston L. Bannister [EMAIL PROTECTED] Marcus Boerger [EMAIL PROTECTED] Derick Rethans [EMAIL PROTECTED] Sander Roobol [EMAIL PROTECTED] Those people commit to run-tests.php from now, whether a patch is valid or not. If too much other people keep messing with it we will never get a valid and stable testsuite. Derick -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Console Behavior
It's known issue... (B (B-- (BYasuo Ohgaki (B (BAdam Voigt wrote: (B Figured it out, turns out I had actually bothered to copy the php.ini (B from the recommended on the server it didn't work on, if I removed the (B config file (forcing PHP to use the default options), it worked fine, (B I narrowed the problem down to the output_buffering setting, changing (B it from 4096 (probably designed for website hit performance) to 0 made (B it work (with or without the call to flush()). (B (B Now my only question is, shouldn't flush() force the buffer to be (B sent out despite the config setting? (B (B Adam Voigt (B [EMAIL PROTECTED] (B (B On Thu, 2002-10-31 at 10:30, Rasmus Lerdorf wrote: (B (BRunning your code here gives me: (B (B8:27am thinkpad:~ ./foo (B (B (BAttach code? 12345 (B (B (B12345 (B (B (B8:27am thinkpad:~ (B (BSeems to work fine. (B (B-Rasmus (B (B (B (B (B (B-- (BPHP Development Mailing List http://www.php.net/ (BTo unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: cvs: php4 /ext/iconv config.m4
Moriyoshi Koizumi wrote: (B moriyoshi Thu Oct 31 15:23:53 2002 EDT (B (B Modified files: (B /php4/ext/iconv config.m4 (B Log: (B Fixed library capability detection behaviour. (B # Whew! I've fixed all the known problems. (B # And should I become a maintainer of this module? (B (BSounds good to me, but Ask Rui and Stig. (BIt's not even listed in EXTENSIONS. (B (B-- (BYasuo Ohgaki (B (B (B-- (BPHP Development Mailing List http://www.php.net/ (BTo unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: cvs: php4 / Makefile.global
Ilia Alshanetsky wrote: (B iliaa Tue Oct 29 10:22:41 2002 EDT (B (B Modified files: (B /php4 Makefile.global (B Log: (B Allows 'make test' to run without being harassed by open_basedir safe_mode. (B (BThis is just another example why we should use certain ini. (BI think we agreed to use certain php.ini, such as php.ini-test. (BNot setting one by one. (B (B-- (BYasuo Ohgaki (B (B (B-- (BPHP Development Mailing List http://www.php.net/ (BTo unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: cvs: php4 / Makefile.global
Derick Rethans wrote: On Wed, 30 Oct 2002, Yasuo Ohgaki wrote: Ilia Alshanetsky wrote: iliaa Tue Oct 29 10:22:41 2002 EDT Modified files: /php4 Makefile.global Log: Allows 'make test' to run without being harassed by open_basedir safe_mode. This is just another example why we should use certain ini. I think we agreed to use certain php.ini, such as php.ini-test. Not setting one by one. We did certainly not agree to use a certain php.ini for settings, but IIRC we did agree with explicitly setting them with either this, or ini_set() in the run-tests.php script. Since you insist this, you know other problems ;) Go ahead to fix others, in script or with -d. You're leaving problem for days even if I mentioned. -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: cvs: php4 / Makefile.global
Derick Rethans wrote: On Wed, 30 Oct 2002, Yasuo Ohgaki wrote: Ilia Alshanetsky wrote: iliaa Tue Oct 29 10:22:41 2002 EDT Modified files: /php4 Makefile.global Log: Allows 'make test' to run without being harassed by open_basedir safe_mode. This is just another example why we should use certain ini. I think we agreed to use certain php.ini, such as php.ini-test. Not setting one by one. We did certainly not agree to use a certain php.ini for settings, but IIRC we did agree with explicitly setting them with either this, or ini_set() in the run-tests.php script. BTW, since you are one of them replying to the thread, don't forget to post, if you object/have other idea. -- 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 :)
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
[PHP-DEV] Re: setting PHP_INI_SYSTEM config. variables in VHost sections (bug20009)
Matus Fantomas Uhlar wrote: (B Therefore I propose a change: (B (B PHP_INI_SYSTEM variables should be allowed to change by admin - in (B system-wide php.ini or httpd.conf, no matter if it's VHost or not. (B (BI've never tried to use php_value/php_admin_value/php_flag/php_admin_flag (Bin global httpd.conf context. Does it work with Apache1.x SAPI? (B (BHave you tried php_admin_vlaue/php_admin_flag? (B(PHP_INI_ALL directives can be modified in script at least under 4.3.0-dev, (Bthough) (B (BThere may be things that are behaving differently from Apache SAPI. (BPlease report it bug, see if Apache2 SAPI can be made work like (BApache SAPI. (Search bug db first, 1 bug/report, please) (B (B (B PHP_INI_PERDIR would be then made useless and .htaccess things can be (B checked with PHP_INI_USER. (B (B (BI probably don't understand this line correctly. (B (B-- (BYasuo Ohgaki (B (B (B-- (BPHP Development Mailing List http://www.php.net/ (BTo 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
[PHP-DEV] Re: [PHP-CVS] Discuss on php-dev, not on php-cvs please
Even stricter and be sure, prevent post from users like php-bugs? -- Yasuo Ohgaki Wez Furlong wrote: That would be ideal :) On Tue, 29 Oct 2002, Derick Rethans wrote: On Tue, 29 Oct 2002, Wez Furlong wrote: If you need to comment on a commit, can you please change the To/Cc line from php-cvs to php-dev. I think we can instruct the listmanager to set a Reply-To header instead, would that be a nice idea? -- 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
[PHP-DEV] Implicit_flush=On by default
Zeev Suraski wrote: (B Thank you for the detailed explanation, I'm sure everybody (B understands it now. (B (BYou're welcome. (B (B Let's go for the voting phase. I vote we keep PHP-CLI (B with implicit_flush on by default. You vote against. (B (BOf course :) (BI vote -1 for it. (B (BIt does not make sense to have it on by default (Bwhich should be turn off almost always. (B (B-- (BYasuo Ohgaki (B (B (B (B-- (BPHP Development Mailing List http://www.php.net/ (BTo 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] CLI ini selection
Edin Kadribasic wrote:
We already have sapi specific ini files. If php finds
php-{$SAPI}.ini (e.g. php-cli.ini, php-apache.ini, etc) it will use
it instead of php.ini. IMHO this should cover most of the needs for
differentiated ini settings.
I knew it, too :)
As I mentioned in several mails, use of web server ini files
could be confusing and annoying.
Good idea for Windows is needed, though.
--
Yasuo Ohgaki
Edin
- Original Message -
From: Melvyn Sopacua [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, October 28, 2002 3:41 PM
Subject: [PHP-DEV] CLI ini selection
Let's put this in the right thread.
At 14:34 28-10-2002, Rick Widmer wrote:
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.
+1 on /etc/php.ini being the equivalent of php_admin_value
+1 on ~/.php.ini being the equavalent of php_value
On windows this may clash bigtime though. The equivalent of
/etc/php.ini
would be
WINNT\ini\php.ini or maybe %ALLUSERPROFILE\Application Data\Php
Group\php.ini and
~/.php.ini would be %USERPROFILE%\Application Data\Php
Group\php.ini.
Yuk :)
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
[PHP-DEV] Re: [PHP-CVS] cvs: php4 /main streams.c
Wez Furlong wrote:
Hey Ilia,
Does this prevent opening of things like block and character special files?
If yes, then let's change it to explicitly check for directories instead,
as there are bound to be people out there that want to open things like
/dev/hda1 (for example).
And named pipes, too?
--
Yasuo Ohgaki
--Wez.
On 28/10/02, Ilia Alshanetsky [EMAIL PROTECTED] wrote:
Fixed bug #20110.
+ if (fstat(fileno(fp), st) == -1 || !S_ISREG(st.st_mode)) {
--
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 :)
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
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] Re: [PHP-CVS] cvs: php4 / Makefile.global
Jon Parise wrote: I still do not understand what magical values in php.ini-dist need to be applied to run-tests.php and why those values, if they are so important, can't be explicitly enabled via ini_set() calls. Glad to explain :) If you install php.ini-recommended as you default php.ini for CLI, the output is buffered since buffering is enabled in php.ini-recommended. This is very frustrating since I see output with 4096 byte chunks. i.e. type make test, then many seconds later, I see first chunk of outputs at once. We should make it execute run-tests.php well with php.ini-recommend, since it's shipped with PHP. The reason why I suggesting to use php.ini-dist is even person who has CVS account don't understand this. AND I'm not confident nor comfortable writing run-tests.php that runs well under any configuration. (Well I may be able to, but it's a waste of time IMO) Therefore, I'm insisting the use of php.ini-dist many times. -- 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
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
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 :)
Zeev Suraski wrote:
(B At 10:01 24/10/2002, Yasuo Ohgaki wrote:
(B
(B Melvyn Sopacua wrote:
(B
(B At 02:51 24-10-2002, Alan Knowles wrote:
(B
(B Im +1 for reverting the patch - (for what it's worth)
(B
(B Why?
(B Well - most 'average' (and below) PHP programmers when attempting to
(B do CLI programming, will get a serious WTF reaction from wondering
(B why when they 'echo' stuff, it doesnt appear. The more advanced
(B Users can manually turn off flushing, but for most small, quick
(B scripts (eg. 50%+), this instant flush is going to be perfectly
(B acceptable..
(B
(B
(B My thoughts exactly. Defaults should work for the masses - it's not
(B like it's enforced behavior, that is irreversible.
(B
(B
(B ? Which mass ?
(B Are you going to insist most scripts need inefficient auto flushing?
(B Have you ever used other programming languages?
(B
(B I don't get it, but this is the 3rd vote.
(B Too few still and reasoning is too weak.
(B
(B
(B Too few? It's 3 times more than the votes in favour, and now it's 4
(B times more. Too weak? That's your opinion, and it doesn't weigh more
(B than others'.
(B
(BI'm mentioning weakness of reasoning. At least, I was tried to ;)
(B
(B My thoughts exactly. Defaults should work for the masses - it's not
(B like it's enforced behavior, that is irreversible.
(B
(Bimplies most/many scripts/users need additional flushing.
(BThis is obviously wrong.
(B
(BOnly very small portion of scripts need flushing for every outputs.
(B(I'm guessing, but nobody objects right?)
(B
(BEven when flushing is needed
(B
(Bfunction prompt($prefix) {
(B echo $prefix;
(B flush();
(B}
(B
(Bis _TRIVIAL_ to write. People should have this kind of
(Bfunction instead of enabling inefficient implicit flushing
(Bsince it's more efficient and reliable.
(B
(BTherefore, "enabling it for the *mass*/ intuitive for users"
(Bdoes not make sense, hence weak reasoning.
(B
(BIf implicit flush is preferred for some scripts, it should be
(Benabled when it is needed because the needs is obviously fewer.
(B
(BI agree, it's a choice but there is good and bad even
(Bif it's not clear sometimes.
(B
(BWhy don't we follow simple rule "more needs" = default,
(B"less needs" = optional especially when it's easy to switch.
(B(we haven't released it yet :)
(B
(BBTW, please vote to this thread. It easier to follow who is
(Bvoting for.
(B
(Bhttp://news.php.net/article.php?group=php.devarticle=89995
(B
(BAnyway, what kind of default we have for implicit flush in
(Bphp.ini-dest/recommended now and in the future? We have _OFF_
(Bby default. It also help us to make better decision, IMO.
(B
(BDefault OFF is more intuitive, IMHO.
(B
(B--
(BYasuo Ohgaki
(B
(B
(B
(B
(B
(B
(B--
(BPHP Development Mailing List http://www.php.net/
(BTo 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 (Bsay "weak reasoning". (B (BMy thoughts exactly. Defaults should work for the masses - it's not (Blike it's enforced behavior, that is irreversible. (B (B Anyway, what kind of default we have for implicit flush in (B php.ini-dest/recommended now and in the future? We have _OFF_ (B by default. It also help us to make better decision, IMO. (B (B Default OFF is more intuitive, IMHO. (B (BI'm talking virtually all current users who are used to (Bimplicit_flush=Off by default. (B (BThis should be called the *MASSES*. (B (B-- (BYasuo Ohgaki (B (B (B-- (BPHP Development Mailing List http://www.php.net/ (BTo unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 / Makefile.global
Sander Roobol wrote: On Thu, Oct 24, 2002 at 11:59:19AM -0400, Jon Parise wrote: - Change the compiled default value for output_buffering to 0. - Allow output_buffering to be set by ini_set(). - Specify 'output_buffering = 0' via the -D command line option for run-tests.php. - Pass a php.ini configuration file to run-tests.php using -C. Can't we just flush all the open output buffers? Something like this: while(ob_get_level()) ob_end_clean(); Of course, I know that. But my points are - run-tests.php itself is not test script, but phpt is. - with specific ini, we can get rid of code aren't needed - we don't have to care about careless patches, and say 'Hey your patch does not work with my php.ini. - things are easier with certain ini. - etc, etc. So far, I didn't see any good point using various php.ini settings for run-tsets.php. Person, who get rid of the setting and insist specifying php.ini is not worth, even cannot find and fix problem with php.ini-recommended. Better choice is obvious, isn't? -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] The reason the way it is: About flushing... Please read and comment.
This is obvious to me but it seems I have to explain... (B (BThere are reasons why things are made in a certain way. (B (Bshells, by its nature, it's interactive for the most (Bpurposes, thus flushing every output make sense even (Bif it cost CPU time. (B (Bprogramming languages, by its nature, most part of (Bprograms do not have to be interactive even when (Bprogrammer is writing interactive programs. Thus, (Bflushing every output and lost CPU time does _not_ (Bmake sense. (B(I don't have to mention char device nature, right?) (B (BWhat we should do? (BWe make CLI a shell or programming language? (B (BPersonally, I don't need PHP/CLI shell... (B (BPlease speak up if you need PHP/CLI to be shell! (B (B-- (BYasuo Ohgaki (B (B (B (B (B-- (BPHP Development Mailing List http://www.php.net/ (BTo unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] cvs: php4 / Makefile.global
Jon Parise wrote: On Wed, Oct 23, 2002 at 05:38:09PM +0900, Yasuo Ohgaki wrote: Hi Ilia and Jon, Do you still think specifying ini used _for_ run-tests.php is bad thing? I hope I've explained enough. I think you don't care, do you? I don't want to involve myself in some sort of religious argument that I honestly know very little about. I do care about technical things, however. So, once again, all I really want to know is what is so special about php.ini-dist? And what _specific_ settings do you (Yasuo) feel must be applied to run-tests.php in order to run properly? And why can't they just be specified via ini_set() calls. In short, I just want to know why run-tests.php needs an external dependency on php.ini-dist. I would much prefer run-tests.php to be self-contained. I really fail to see why we need to ask troubles for executing run-tests.php. It's executed by various people and better to run always with less problems when people typed make test. Anyway, main problem is Derick is changing the line w/o knowledge of the consequence. He hasn't even fixed a issue I mentioned, yet he reverted my patch twice. 1st time is ok, since he didn't know, 2nd time is not ok since I let him know. He should fix the problem I mentioned at the same time at least. Don't think it's rude, Derick :) Or is it too difficult for you to fix, even the problem I explicitly 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 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?)
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
[PHP-DEV] Re: RFC: CLI behave like SH or PERL/RUBY/PYTHON?
BTW, this is 2nd time (B (Bhttp://marc.theaimsgroup.com/?l=php-devm=103525481227249w=2 (B (BYasuo Ohgaki wrote: (B I thought it's obvious choice, but it seems it's not. (B (B Which one you prefer CLI behave like (B (B SH (B (B or (B (B PERL/RUBY/PYTHON (B (B -- (B Yasuo Ohgaki (B (B (B (B (B-- (BPHP Development Mailing List http://www.php.net/ (BTo unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: CLI behave like SH or PERL/RUBY/PYTHON?
George Schlossnagle wrote: Not to be snarky, but I for one would prefer PHP to behave like PHP. ;) Without having to make everyone here sort through the commit messages, can you briefly list out the proposed changes? Oops. Sorry, I forgot. It's about flushing output every output statement. SH and current CLI does fflush() on stdout with echo A while others don't. And this setting cannot be changed by php.ini. User has to pass -D implicit_flush=Off as command line option. As we all know, character devices flushes by newline, so flushing is not really needed. If user would like to do flush, flush() function may be used (or change php.ini) -- Yasuo Ohgaki George On Wednesday, October 23, 2002, at 02:26 AM, Yasuo Ohgaki wrote: I thought it's obvious choice, but it seems it's not. Which one you prefer CLI behave like SH or PERL/RUBY/PYTHON -- 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
Re: [PHP-DEV] Re: RFC: CLI behave like SH or PERL/RUBY/PYTHON?
Alan Knowles wrote:
(B To try and clarify...
(B
(B #!/usr/bin/php -q
(B ?
(B
(B echo "please enter a word";
(B
(Bflush(); // is needed here, since above line does not have newline.
(B
(B $fh = fopen('php://stdin')
(B $s = fgets($fh,100);
(B echo "you entered $s" ;
(B
(B ?
(B
(B Would this be affected by the change? - eg. would you need to flush();
(B before the prompt appeared?
(B
(BI wrote impclit_flush setting in php_cli.c will prevent changing the
(Bsetting. (I thought it will not due to CLI doc)
(B
(BI take it back, since it is done in early stage, the setting is
(Bover written by php.ini apparently. It's confusing, since it's differs
(Bfrom php.ini-dist/recommended.
(B
(B[yohgaki@dev DEV]$ /usr/local/apache/bin/php -i | grep implicit_flush
(Bimplicit_flush = On = Off
(B(This makes PG(implicit_flush)=1 in php_cli.c still bogus)
(B
(BFrom main/main.c
(BSTD_PHP_INI_BOOLEAN("implicit_flush", "0",
(BPHP_INI_PERDIR|PHP
(B_INI_SYSTEM,OnUpdateBool, implicit_flush, php_core_globals,
(B co
(Bre_globals)
(B
(BThe default should be the same as main.c, IMO. Removing the
(Bline from the php_cli.c will make CLI behavior more consistent.
(B
(BIf CLI should flush for every echo/print, more consistent way of
(Bhandling the setting is needed at least.
(B
(BBTW, whether I like it or not, users can change OG(implicit_flush)
(Bto call flush() always when echo/print is used.
(B
(B--
(BYasuo Ohgaki
(B
(B
(B--
(BPHP Development Mailing List http://www.php.net/
(BTo unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: CLI behave like SH or PERL/RUBY/PYTHON?
Edin Kadribasic wrote: (B OTOH, having implicit_flush turned on makes writing interactive command line (B programs easier. Some programs (like pear installer) might even depend on it. (B (BIt may, but the current implementation is broken as I (Bmentioned in other mail. (B (BI don't argue with usefulness of implicit flushing. It (Bshould be optional and should behave more consistently. (B (B The way cli overwrites some ini settings is a whole different issue and I (B don't thinks we should start mixing the two on this thread. (B (BOk. Then we can narrow down a bit. (BPG(implicit_flush)=1 in php_cli.c was bogus as described (Bin other mail in this thread. (B (BIt's better to have more generic/consistent way of (Bsetting the implicit flushing. Any objection about (Bthis? (B (BWhether I like it or not, ob_implicit_flush() and/or (BOG(implicit_flush) may be used to turn on/off (BSAPI level flushing. This should be be enough. (B(current ob_implicit_flush() is just enabling SAPI (Blevel flushing) (B (BTo be honest, I prefer to have implicit_flush() and use (BPG(implicit_flush) instead of using ob_implicit_flush() (Bfor SAPI flushing. (B (BPS: Almost all script should not be affected by this (Bchange, since php.ini setting is overwritten and implicit (Bflushing was disabled by php.ini. (Bi.e. php.ini-dist/recommended users were not affected by (BPG(implicit_flush)=1 in php_cli.c. (B (B-- (BYasuo Ohgaki (B (B (B-- (BPHP Development Mailing List http://www.php.net/ (BTo unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: CLI behave like SH or PERL/RUBY/PYTHON?
Hartmut Holzgraefe wrote: Edin Kadribasic wrote: Doing flush after each output operation does carry a performance penalty. The following example illustrates it: php -d implicit_flush=0 -r 'for ($i=0; $i100; $i++) echo $i;' file This one executes about twice as fast on my machine compared to php with implicit_flush turned on. The example is of course written to emphasise the issue. ? default implicit_flush to isatty(stdout) should help here? This may be a great idea. There is cons also. Users may be looking the file with tail... We are better to have ability enable/disable implicit flushing at user's will. -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: CLI behave like SH or PERL/RUBY/PYTHON?
Edin Kadribasic wrote: Ok. Let's agree that the current implementation is not ideal, but it works. There were already several suggestions on how this can be improved, but I don't think this is the right time to start doing it. So my proposal is that Yasuo reverts his patch until 4.3.0 is branched and then let's have a look at how to solve CLI ini/flush issues. No problem, since the hard coded setting is over written by php.ini under almost all UNIX environment. Before I do, as Murkas pointed out, we are better to check how Windows users affected by this. I'll add the setting few days later. (It may be good idea ship pre2 with current code. Comments?) -- Yasuo Ohgaki Edin On Wednesday 23 October 2002 10:28, Yasuo Ohgaki wrote: Hartmut Holzgraefe wrote: Edin Kadribasic wrote: Doing flush after each output operation does carry a performance penalty. The following example illustrates it: php -d implicit_flush=0 -r 'for ($i=0; $i100; $i++) echo $i;' file This one executes about twice as fast on my machine compared to php with implicit_flush turned on. The example is of course written to emphasise the issue. ? default implicit_flush to isatty(stdout) should help here? This may be a great idea. There is cons also. Users may be looking the file with tail... We are better to have ability enable/disable implicit flushing at user's will. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: CLI behave like SH or PERL/RUBY/PYTHON?
Derick Rethans wrote: On Wed, 23 Oct 2002, Yasuo Ohgaki wrote: Edin Kadribasic wrote: Ok. Let's agree that the current implementation is not ideal, but it works. There were already several suggestions on how this can be improved, but I don't think this is the right time to start doing it. So my proposal is that Yasuo reverts his patch until 4.3.0 is branched and then let's have a look at how to solve CLI ini/flush issues. No problem, since the hard coded setting is over written by php.ini under almost all UNIX environment. Then what was the point in removing it in the first place? It's just a default. 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. In addition, I'm suspecting there is serious bug in overall ini handling in current code also. It was actually overriding php.ini and set PG(implict_flush)=1 when I was tried to fix output buffer flushing, but php.ini overrides the setting now. I didn't realize until now, but there should be something wrong. (or fixed? ;) Before I do, as Murkas pointed out, we are better to check how Windows users affected by this. I'll add the setting few days later. What setting do you need to add at all? You can disable this flushing: 1. with a -d parameter It works. 2. in the script with ini_set() I've pointed out _MANY_ times that PG(implicit_flush) is INI_SYSTEM|INI_PERDIR I start doubting you weren't reading my mail at all and replying. -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: CLI behave like SH or PERL/RUBY/PYTHON?
Edin Kadribasic wrote: Since your commit has a potential to break some programs that PEAR depends on, I still think that you should revert your patch. And I think that it should stay that way for 4.3.0. I'll take a look just few days, then. If PEAR is depending on the line, some people telling us problem since php.ini setting is overriding hard coded setting somehow. (or PEAR developers are not using recent versions) I'm sure it was not overriding hard coded setting few weeks ago. We have to fix something (or some thing is fixed and the side effect change the behavior?) Anyway, PEAR will fails with or without the patch if it depends on it at least on almost all UNIX environment with current behavior. -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] inplicit_flush off
Derick Rethans wrote: On Tue, 22 Oct 2002, Yasuo Ohgaki wrote: CLI should behave like other *modern* scripting language. i.e. behave like perl, ruby, python. Currently it behaves like sh. i.e. flushing stdout for every output. Like it *should*. Please don't start again on this issue, it is starting to annoy me. I know you bring the setting back ;) PG(implicit_flush)=1 cannot make sense in anyway. PG(implicit_flush) is INI_SYSTEM|INI_PERDIR. You know what it means. fflush on stdout for every output is not needed by the nature of char devices. Give some reasonable reasons why PHP/CLI should behave like sh instead of modern scripting languages like perl, ruby, etc at least. -- Yasuo Ohgaki Comments? --- php_cli.c.~1.37.~ Wed Oct 16 06:17:34 2002 +++ php_cli.c Tue Oct 22 11:45:09 2002 -466,7 +466,6 SG(options) |= SAPI_OPTION_NO_CHDIR; zend_alter_ini_entry(register_argc_argv, 19, 1, 1, PHP_INI_SYSTEM, PHP_INI_STAGE_ACTIVATE); zend_alter_ini_entry(html_errors, 12, 0, 1, PHP_INI_SYSTEM, PHP_INI_STAGE_ACTIVATE); - zend_alter_ini_entry(implicit_flush, 15, 1, 1, PHP_INI_SYSTEM, PHP_INI_STAGE_ACTIVATE); zend_alter_ini_entry(max_execution_time, 19, 0, 1, PHP_INI_SYSTEM, PHP_INI_STAGE_ACTIVATE); zend_uv.html_errors = 0; /* tell the engine we're in non-html mode */ -- 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] inplicit_flush off
Yasuo Ohgaki wrote: Derick Rethans wrote: On Tue, 22 Oct 2002, Yasuo Ohgaki wrote: CLI should behave like other *modern* scripting language. i.e. behave like perl, ruby, python. Currently it behaves like sh. i.e. flushing stdout for every output. Like it *should*. Please don't start again on this issue, it is starting to annoy me. I know you bring the setting back ;) PG(implicit_flush)=1 cannot make sense in anyway. PG(implicit_flush) is INI_SYSTEM|INI_PERDIR. You know what it means. fflush on stdout for every output is not needed by the nature of char devices. BTW, what possibly could may make sense is OG(implicit_flush)=1. It's changeable at scripting level. The setting does not make sense for the reason mentioned above, though. -- Yasuo Ohgaki Give some reasonable reasons why PHP/CLI should behave like sh instead of modern scripting languages like perl, ruby, etc at least. -- Yasuo Ohgaki Comments? --- php_cli.c.~1.37.~Wed Oct 16 06:17:34 2002 +++ php_cli.cTue Oct 22 11:45:09 2002 -466,7 +466,6 SG(options) |= SAPI_OPTION_NO_CHDIR; zend_alter_ini_entry(register_argc_argv, 19, 1, 1, PHP_INI_SYSTEM, PHP_INI_STAGE_ACTIVATE); zend_alter_ini_entry(html_errors, 12, 0, 1, PHP_INI_SYSTEM, PHP_INI_STAGE_ACTIVATE); -zend_alter_ini_entry(implicit_flush, 15, 1, 1, PHP_INI_SYSTEM, PHP_INI_STAGE_ACTIVATE); zend_alter_ini_entry(max_execution_time, 19, 0, 1, PHP_INI_SYSTEM, PHP_INI_STAGE_ACTIVATE); zend_uv.html_errors = 0; /* tell the engine we're in non-html mode */ -- 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] short_open_tag
Shane Caraveo wrote: Brad LaFountain wrote: It would be very bad for php if short tags were disabled. I 100% agree with andi. There are ways of dealing with xml and php without pissing off the WHOLE php user world. I don't even use long tags EVER, nor will I want to start. - Brad Damn, that comes from a SOAP developer too ;) Just wait till he starts embeding php in xsl :) (^_^) Sorry guys, but cannot resist post a smile. -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/db db.c
Jani Taskinen wrote: You propably didn't notice, but this extension is actually deprecated..you should use DBA instead. --Jani Move to PECL or remove? I think move to PECL make sense, since there should be users of db extension. -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] cvs: php4 /sapi/cli php_cli.c
Jani Taskinen wrote: Again..was this agreed upon? I suppose so. I didn't get any more objections. -- Yasuo Ohgaki --Jani On Wed, 23 Oct 2002, Yasuo Ohgaki wrote: yohgaki Tue Oct 22 21:21:40 2002 EDT Modified files: /php4/sapi/cli php_cli.c Log: Make CLI behave like other moder scripting languages. Index: php4/sapi/cli/php_cli.c diff -u php4/sapi/cli/php_cli.c:1.37 php4/sapi/cli/php_cli.c:1.38 --- php4/sapi/cli/php_cli.c:1.37 Mon Oct 14 07:59:58 2002 +++ php4/sapi/cli/php_cli.c Tue Oct 22 21:21:40 2002 -466,7 +466,6 SG(options) |= SAPI_OPTION_NO_CHDIR; zend_alter_ini_entry(register_argc_argv, 19, 1, 1, PHP_INI_SYSTEM, PHP_INI_STAGE_ACTIVATE); zend_alter_ini_entry(html_errors, 12, 0, 1, PHP_INI_SYSTEM, PHP_INI_STAGE_ACTIVATE); - zend_alter_ini_entry(implicit_flush, 15, 1, 1, PHP_INI_SYSTEM, PHP_INI_STAGE_ACTIVATE); zend_alter_ini_entry(max_execution_time, 19, 0, 1, PHP_INI_SYSTEM, PHP_INI_STAGE_ACTIVATE); zend_uv.html_errors = 0; /* tell the engine we're in non-html mode */ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /sapi/cli php_cli.c
Andi Gutmans wrote: At 12:20 PM 10/23/2002 +0900, Yasuo Ohgaki wrote: Jani Taskinen wrote: Again..was this agreed upon? I suppose so. I didn't get any more objections. It's not a big deal to me but I don't understand why this should need changing. Who cares what perl does? I don't think there's a right or wrong on this issue. Ok. Then start proposing PG(inplicit_flush) be INI_ALL and let us know the implication of the change. -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /sapi/cli php_cli.c
Andi Gutmans wrote: At 12:20 PM 10/23/2002 +0900, Yasuo Ohgaki wrote: Jani Taskinen wrote: Again..was this agreed upon? I suppose so. I didn't get any more objections. It's not a big deal to me but I don't understand why this should need changing. Who cares what perl does? I don't think there's a right or wrong on this issue. Let us know why modern and successful script language, perl, ruby and python, choice is wrong, too. if the setting was good. -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /sapi/cli php_cli.c
Derick Rethans wrote: On Wed, 23 Oct 2002, Yasuo Ohgaki wrote: Jani Taskinen wrote: Again..was this agreed upon? I suppose so. I didn't get any more objections. You got atleast one, and that was mine. I didn't see people agree either. The line was bogus with the current code. Did you read my email? -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /sapi/cli php_cli.c
Yasuo Ohgaki wrote: Derick Rethans wrote: On Wed, 23 Oct 2002, Yasuo Ohgaki wrote: Jani Taskinen wrote: Again..was this agreed upon? I suppose so. I didn't get any more objections. You got atleast one, and that was mine. I didn't see people agree either. BTW, you haven't reply [implicit_flush off] thread. Usually, it means agreed. I might gave you to little time, though. I don't get objection from Edin, too. Replying to the thread is fine if you would like. -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RFC: CLI behave like SH or PERL/RUBY/PYTHON?
I thought it's obvious choice, but it seems it's not. (B (BWhich one you prefer CLI behave like (B (BSH (B (Bor (B (BPERL/RUBY/PYTHON (B (B-- (BYasuo Ohgaki (B (B (B-- (BPHP Development Mailing List http://www.php.net/ (BTo unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/mbstring/tests 027.inc027.phpt
Moriyoshi Koizumi wrote: Hi, I'm for Derick's option. Can I begin repacking each case to the single files now? The only advantage putting everything in phpt is is we can take a look at whole thing in one file. Don't we have multiple windows or buffers? It's too little advantage compare to have 2 files. IMO, including script file give us more freedom to write/execute test script. It's not efficient creating normal script file when there is problem in phpt. Anyway, if you volunteer to change it, go ahead. (Please don't for pgsql tests :) Please rename 001.phpt to something meaningful. I just followed existing test script naming convention and I don't like it, too. ;) -- Yasuo Ohgaki Moriyoshi Yasuo Ohgaki [EMAIL PROTECTED] wrote: Derick Rethans wrote: Yes, works fine here: (even with * instead of 025.*) Thing has been changed ;) I hope it's documented somewhere. -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/mbstring/tests 027.inc027.phpt
Melvyn Sopacua wrote: At 22:00 10/21/2002 +0900, Yasuo Ohgaki wrote: Derick Rethans wrote: Yes, works fine here: (even with * instead of 025.*) Thing has been changed ;) I hope it's documented somewhere. Here's the docs: http://news.php.net/article.php?group=php.cvsarticle=14780 It's not called documentation, but CVS log, isn't it :) -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/mbstring/tests 027.inc 027.phpt
Derick Rethans wrote: Yes, works fine here: (even with * instead of 025.*) Thing has been changed ;) I hope it's documented somewhere. -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/mbstring/tests 027.inc027.phpt
Melvyn Sopacua wrote: However - it depends on include and relative path issues to work as expected. The problem is very frustrating, isn't? What's the plan for it? -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/mbstring/tests 027.inc027.phpt
Other option is create .php files from phpt file always.
It was useful when there is .php file is created when
error occurred. (Current run-tests.php does not create the
.php files, though)
If .php files is always created and left after running
run-tests.php, all needs are covered. It's a trivial change
to run-tests.php.
We may better to use some strange extension to avoid
unwanted over writes. .src may be a good choice.
Comments?
--
Yasuo Ohgaki
Moriyoshi Koizumi wrote:
echo ?php while(--\$argc=0){\$f=\$argv[\$argc];echo \\$f\n\;\
\$b=preg_replace(\
'/\\?php\\s+include\\(\\s*[\\\']([^\\\']+)[\\\']\\s*\\);\\s*\\?/e',\
'file_get_contents(\\$1\)',\file_get_contents(\$f));\
\$p=fopen(\$f,'w');fwrite(\$p,\$b);fclose(\$p);}? \
| sapi/cli/php -- ext/mbstring/tests/*.phpt
done (a bit dirty).
Moriyoshi
Moriyoshi Koizumi [EMAIL PROTECTED] wrote:
Hi,
I'm for Derick's option. Can I begin repacking each case to the single
files now?
Moriyoshi
Yasuo Ohgaki [EMAIL PROTECTED] wrote:
Derick Rethans wrote:
Yes, works fine here:
(even with * instead of 025.*)
Thing has been changed ;)
I hope it's documented somewhere.
--
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
[PHP-DEV] inplicit_flush off
CLI should behave like other *modern* scripting
(Blanguage. i.e. behave like perl, ruby, python.
(B
(BCurrently it behaves like sh.
(Bi.e. flushing stdout for every output.
(B
(BComments?
(B
(B--- php_cli.c.~1.37.~ Wed Oct 16 06:17:34 2002
(B+++ php_cli.c Tue Oct 22 11:45:09 2002
(B@@ -466,7 +466,6 @@
(BSG(options) |= SAPI_OPTION_NO_CHDIR;
(Bzend_alter_ini_entry("register_argc_argv", 19, "1", 1, PHP_INI_SYSTEM,
(BPHP_INI_STAGE_ACTIVATE);
(Bzend_alter_ini_entry("html_errors", 12, "0", 1, PHP_INI_SYSTEM,
(BPHP_INI_STAGE_ACTIVATE);
(B- zend_alter_ini_entry("implicit_flush", 15, "1", 1, PHP_INI_SYSTEM,
(BPHP_INI_STAGE_ACTIVATE);
(Bzend_alter_ini_entry("max_execution_time", 19, "0", 1, PHP_INI_SYSTEM,
(BPHP_INI_STAGE_ACTIVATE);
(B
(Bzend_uv.html_errors = 0; /* tell the engine we're in non-html mode */
(B
(B
(B--
(BYasuo Ohgaki
(B
(B
(B--
(BPHP Development Mailing List http://www.php.net/
(BTo unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] short_open_tag
Zeev Suraski wrote: At 11:10 17/10/2002, Yasuo Ohgaki wrote: Zeev Suraski wrote: No, we shouldn't have. It is not a deprecated feature or a discouraged feature. If you use the *FAIRLY RARE* combination of using PHP to generate XML, you'd have to configure your PHP. If you're with the vast majority of the population and couldn't care less about writing XML-embedded scripts, you enjoy a working short tag. I know it's a kind of religious issue :) Anyway, if it's rare we don't need ?xml awareness in parser. Since there are no drawbacks at all to the ?xml detection, and since it does cover a great deal of the problem (taking into account the very limited scope of the problem), I don't see a good reason not to add it. Rasmus put it very well in one of his recent letters - PHP is not a purists' language, complex problem sometimes require 'ugly' solutions... Hmm. I fails to see importance of ?xml awareness. I see side effect of ? tag as PHP start tag. IMHO, language that supposed to process XML document should not have ? as start tag. Use of ? should be discouraged if a language suppose to work with ?xml. I'm not insisting removal of it, but having ? start tag, and keep encouraging use of it, is a design flaw to me. -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: removing apidoc.txt
+1 It's time to do so. -- Yasuo Ohgaki Andrei Zmievski wrote: I propose we remove apidoc.txt from the tree. It is prety outdated and only promotes confusion. We have a module for API documentation and it is available online as well. -Andrei http://www.gravitonic.com/ Computers are useless. They can only give you answers. --Pablo Picasso -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] short_open_tag
Andi Gutmans wrote: I don't think we should add special hacks to the scanner. Soon we're going to have a zillion hacks for other XML/SGML/foobar documents. I agree. We are better to leave it as documentation issue, IMO. -- Yasuo Ohgaki Andi At 12:17 PM 10/16/2002 -0400, Ilia A. wrote: Since the general consensus by the developers is not to remove the short_tags or even disable them. Perhaps we should consider alternate solutions to this problem. Given the buzzword popularity of XML and its slowly growing popularity among website designers (XHTML) this issue is likely to come up in the future yet again. The solution I would like to offer, is a patch that adds special handling for ?xml. Thus preventing the language parser from attempting to parse data inside ?xml as PHP source. Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [4.3] Current critical bugs
Andrei Zmievski wrote: Hi, We have 10 critical bugs in the list currently. If you could please see about fixing at least one of them, we'd be that much closer to a release candidate. Summary: Apache2 sending 304 - not modified header http://bugs.php.net/bug.php?id=17098 This is serious problem for serious sites. (Serious sites shouldn't use Apache2, though) -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Changing entity charset
Wez Furlong wrote: Err, I suggest you read that patch again. The default will be the mbstring.internal_charset That's not the same thing! Since the guess code is in #if, PHP is changing behavior without the patch according to the compiled environment. How about add current guess code if internal_encoding =NULL? Is there any other concerns? -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [4.3] Current critical bugs
Ilia A. wrote: Summary: Apache2 sending 304 - not modified header http://bugs.php.net/bug.php?id=17098 This is serious problem for serious sites. (Serious sites shouldn't use Apache2, though) This looks like an Apache 2 bug, rather then aPHP one. I am guessing the fix they made did not work properly. Great! Then we can just wait their fix :) -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: #19771 - patch
Tal Peer wrote:
hello,
this patch tries to fix the performance issues described in bug #19771.
i cannot benchmark this at the moment, so if anyone can, please do.
the patch is available at http://tal.madcode.org/file.c.patch
and thanks to wez :)
Getting better, but it still too slow somehow...
[yohgakidev DEV]$ ./sapi/cli/php t.php
-
markertime indexex time perct
-
Start 1034946698.39588300 - 0.00%
-
fread 1034946698.41885300 0.022970080375671 4.36%
-
file 1034946698.82063700 0.40178394317627 76.32%
-
file_get_contents 1034946698.90671300 0.086076021194458 16.35%
-
fgets 1034946698.92197300 0.015259981155396 2.90%
-
Stop 1034946698.92232000 0.00034701824188232 0.07%
-
total - 0.52643704414368 100.00%
-
[yohgakidev DEV]$ cat t.php
?php
$filename = '/var/log/httpd/error_log.1';
require(Benchmark/Timer.php);
$time = new Benchmark_Timer;
$time - setMarker('Start');
$fp = fopen($filename,'r');
for ($i = 0; $i100; $i++)
$s = explode(\n, fread($fp, filesize($filename)));
fclose($fp);
$time - setMarker('fread');
for ($i = 0; $i100; $i++)
$s = file($filename);
$time - setMarker('file');
for ($i = 0; $i100; $i++)
$s = file_get_contents($filename);
$time - setMarker('file_get_contents');
$fp = fopen($filename,'r');
for ($i = 0; $i100; $i++)
$s = explode(\n, fgets($fp,filesize($filename)));
$time - setMarker('fgets');
fclose($fp);
$time - setMarker('Stop');
$time - display();
?
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: #19771 - patch
Yasuo Ohgaki wrote:
Tal Peer wrote:
hello,
this patch tries to fix the performance issues described in bug #19771.
i cannot benchmark this at the moment, so if anyone can, please do.
the patch is available at http://tal.madcode.org/file.c.patch
and thanks to wez :)
Getting better, but it still too slow somehow...
Never mind. There is stupid mistake in the script...
It should be Ok.
[yohgakidev DEV]$ ./sapi/cli/php t.php
-
markertime indexex time perct
-
Start 1034947649.40024700 - 0.00%
-
fread 1034947649.82932800 0.42908096313477 44.84%
-
file 1034947650.23224900 0.40292108058929 42.11%
-
file_get_contents 1034947650.32007600 0.087826967239389.18%
-
fgets 1034947650.35698600 0.036910057067871 3.86%
-
Stop 1034947650.35716300 0.00017690658569336 0.02%
-
total - 0.956915974617100.00%
-
[yohgakidev DEV]$ cat t.php
?php
$filename = '/var/log/httpd/error_log.1';
require(Benchmark/Timer.php);
$time = new Benchmark_Timer;
$time - setMarker('Start');
for ($i = 0; $i100; $i++) {
$fp = fopen($filename,'r');
$s = explode(\n, fread($fp, filesize($filename)));
fclose($fp);
}
$time - setMarker('fread');
for ($i = 0; $i100; $i++)
$s = file($filename);
$time - setMarker('file');
for ($i = 0; $i100; $i++)
$s = file_get_contents($filename);
$time - setMarker('file_get_contents');
for ($i = 0; $i100; $i++) {
$fp = fopen($filename,'r');
//$s = explode(\n, fgets($fp,filesize($filename)));
$s = explode(\n, fgets($fp));
fclose($fp);
}
$time - setMarker('fgets');
$time - setMarker('Stop');
$time - display();
?
[yohgakidev DEV]$
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: #19771 - patch
Tal Peer wrote:
hello,
this patch tries to fix the performance issues described in bug #19771.
i cannot benchmark this at the moment, so if anyone can, please do.
the patch is available at http://tal.madcode.org/file.c.patch
and thanks to wez :)
It's not related to file(), but I found another problem.
Sorry, I don't have time look into.
[yohgakidev DEV]$ ./sapi/cli/php t.php
-
markertime indexex time perct
-
Start 1034948606.60534400 - 0.00%
-
Stop 1034948607.94562700 1.3402829170227 100.00%
-
total - 1.3402829170227 100.00%
-
/home/yohgaki/cvs/php.net/DEV/Zend/zend_hash.c(406) : Freeing 0x08E84D74 (35 bytes), script=t.php
Last leak repeated 47438 times
/home/yohgaki/cvs/php.net/DEV/Zend/zend_API.c(846) : Freeing 0x08E84D3C (1 bytes), script=t.php
Last leak repeated 47438 times
/home/yohgaki/cvs/php.net/DEV/Zend/zend_API.c(845) : Freeing 0x08E84CFC (12 bytes), script=t.php
Last leak repeated 47438 times
/home/yohgaki/cvs/php.net/DEV/Zend/zend_hash.c(440) : Freeing 0x08E3E5EC (32768 bytes), script=t.php
Last leak repeated 8 times
/home/yohgaki/cvs/php.net/DEV/ext/standard/string.c(796) : Freeing 0x08AED524 (44 bytes), script=t.php
/home/yohgaki/cvs/php.net/DEV/Zend/zend_API.c(565) : Actual location (location was relayed)
Last leak repeated 8 times
[yohgakidev DEV]$ cat t.php
?php
$filename = 'libtool';
require(Benchmark/Timer.php);
$time = new Benchmark_Timer;
$time - setMarker('Start');
$s = '';
for ($i = 0; $i10; $i++) {
$fp = fopen($filename,'r');
while (!feof($fp))
$s .= fgets($fp);
$s = explode(\n, $s);
fclose($fp);
}
$time - setMarker('Stop');
$time - display();
?
[yohgakidev DEV]$
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] short_open_tag
Zeev Suraski wrote: No, we shouldn't have. It is not a deprecated feature or a discouraged feature. If you use the *FAIRLY RARE* combination of using PHP to generate XML, you'd have to configure your PHP. If you're with the vast majority of the population and couldn't care less about writing XML-embedded scripts, you enjoy a working short tag. I know it's a kind of religious issue :) Anyway, if it's rare we don't need ?xml awareness in parser. We are better to note php.ini-dist/recommened that portable script writer should not depend on short tags. Any objection for adding the comment? NOTE: The same comment in Basic Syntax section of the manual. Index: php.ini-dist === RCS file: /repository/php4/php.ini-dist,v retrieving revision 1.165 diff -u -r1.165 php.ini-dist --- php.ini-dist9 Oct 2002 09:03:04 - 1.165 +++ php.ini-dist17 Oct 2002 09:08:02 - -67,7 +67,12 ; Enable the PHP scripting language engine under Apache. engine = On -; Allow the ? tag. Otherwise, only ?php and script tags are recognized. +; Allow the ? tag. Otherwise, only ?php and script tags are recognized. +; NOTE: Using short tags should be avoided when developing applications or +; libraries that are meant for redistribution, or deployment on PHP +; servers which are not under your control, because short tags may not +; be supported on the target server. For portable, redistributable code, +; be sure not to use short tags. short_open_tag = On ; Allow ASP-style % % tags. -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Changing entity charset
Wez Furlong wrote: Search for htmlentities charset. Both myself and thies (and probably others were discussing this). In short: there are many, many, many people who have scripts that rely on htmlentities defaulting to iso-8859-1 (the documented default for ever). With the patch, ISO 8859-1 is default still. Therefore, I don't see problems. Do you see any problems other than this? I'm going to read archives more carefully, though I think even handling the charset in phpinfo() will yield the same discussion in the future. This is a separate issue and nothing to do with changing the behaviour of htmlentities(). Please no automatic entity conversion for phpinfo(), it's for debugging. i.e. It does not need 100% conformance to standards to be useful... -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] short_open_tag
Mike Hall wrote: I would have no problem - as a user - with the removal of short_tags IF ?php=$var? was allowed!! Because the ?= short cut is the only reason I use ? at all! Just to add fuel to the fire ;-) I know that. You know that Most of know that it's just another fuel ;) -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Multibyte ([PHP-INST] Re: If-Modified-Since..)
Ryo Takagi wrote: If the line: print ( mb_convert_encoding( $jstr, ISO-2022-JP ) ) ; in this script is modified to: print ( mb_convert_encoding( $jstr, ISO-2022-JP, EUC-JP ) ) ; then it works again. This cannot be fixed. Check modify your detect order by mb_detect_order(). -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Multibyte ([PHP-INST] Re: If-Modified-Since..)
Forgot to what it's doing. Since the multibyte char sequence is too short, mbstring is failing to detect encoding correctly. In this case, we can specify encoding or modify detect order. -- Yasuo Ohgaki Yasuo Ohgaki wrote: Ryo Takagi wrote: If the line: print ( mb_convert_encoding( $jstr, ISO-2022-JP ) ) ; in this script is modified to: print ( mb_convert_encoding( $jstr, ISO-2022-JP, EUC-JP ) ) ; then it works again. This cannot be fixed. Check modify your detect order by mb_detect_order(). -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] short_open_tag
Ilia A. wrote: Since the general consensus by the developers is not to remove the short_tags or even disable them. Perhaps we should consider alternate solutions to this problem. Given the buzzword popularity of XML and its slowly growing popularity among website designers (XHTML) this issue is likely to come up in the future yet again. The solution I would like to offer, is a patch that adds special handling for ?xml. Thus preventing the language parser from attempting to parse data inside ?xml as PHP source. I think it's reasonable patch, but ? is XML Processing Instruction tag... We never know how many processing tags will be in the future. We don't know if there will be xml processor that processes php tag or not. Therefore, user should turn short tag off by themselves if the want to use XML, or echo ?xml .. at the beginning of output. IMO, disabling short tag in php.ini-recommended is ok in the future. I know Zeev don't like it and I understand the reasoning. :) Isn't BIG caution for short_open_tag=Off while having short_open_tag=On enough for now? Something like; == ;If you are willing to process XML file with PHP, you should ;turn short tag off or echo XML processing tag, ? whenever ;needed. Turning off this directive and use of ?php is generally ;recommended with XML documents. ; ;!!CAUTION!! If you have a script start with short tag and short_open_tag=Off, ; ?, the content(source) is displayed!! In future version of ;php.ini-recommended will have short_open_tag=Off by default! Use of short ;open tag is discouraged. ; ;NOTE: Authors writing portable scripts should check this ini setting. ;or echo ?. short_open_tag=On == -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Changing entity charset handling
Wez Furlong wrote: Search the archives for the discussion. phpinfo could determine the charset as your patch does at the start, phpinfo() better not to detect charsets, since user are using it to see variables' values. i.e. Variables may contains different encoding var to var. Applying htmlentities() to phpinfo() output prevents ability to change encoding on users(browser) side. Besides phpinfo() issue, I'm +1 for the patch. It shouldn't break compatibility, since converting chars to entities with different encoding does not work/make sense or I must be missing some. BTW, we're better to have PHPAPI function returns internal encoding, rather than switch(). -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Multibyte ([PHP-INST] Re: If-Modified-Since..)
Masaki Fujimoto wrote: nah... If it(==from_encoding) is not specified, the internal encoding will be used. (http://jp.php.net/manual/en/function.mb-convert-encoding.php) so it's just because mbstring.internal_encoding is not properly set? Thanks for heads up. I made the same mistake several times even if I wrote english version of the manual page. Guessing encoding every time is stupid :) You should have wrong internal_encoding. -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] short_open_tag
Ilia A. wrote: Isn't BIG caution for short_open_tag=Off while having short_open_tag=On enough for now? Something like; Nope, please consider a hosting enviroment where an average user does not even have access to the php.ini file. In fact, most ISP won't make user's life difficult by forcing ?php because they know that'll lead to waste of their time and money since they'll be forced to deal with user complains about why their PHP scripts are not working. Even people with the ability to modify this file will not necessarily edit it and only do so if they need to change an option not changeable via other means. We should have warned people not to use short tags years ago. We can try it from now. Until we get rid of short tag or disable it by default, we suggest users to work around problem. echo ?xml ..? works always and authors of portable scripts should use it. If there are new processing tags, echo ?new_xml_PI .? instead of adding new PI to parser. (We never know if user use custom PI tag or not) IMHO, it's good enough work around until we have PHP6 or later. -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] short_open_tag
We had the same discussion. I brought it up last time. There were patch for ?xml just like yours. The outcome was modified manual page that discourages use of short tag for portable script. http://www.php.net/manual/en/language.basic-syntax.php Current php.ini-dist has == ; Allow the ? tag. Otherwise, only ?php and script tags are recognized. short_open_tag = On == Adding appropriate comment is better than adding token to language. i.e. compatibility between new and old PHP. The best way to go is discourage use of short tag whenever possible, change default few years later, IMHO. Even if we never change the default, ?php echo ?xml ..?;? works always w/o patch. -- Yasuo Ohgaki Ilia A. wrote: On October 16, 2002 11:11 pm, Yasuo Ohgaki wrote: Ilia A. wrote: Isn't BIG caution for short_open_tag=Off while having short_open_tag=On enough for now? Something like; Nope, please consider a hosting enviroment where an average user does not even have access to the php.ini file. In fact, most ISP won't make user's life difficult by forcing ?php because they know that'll lead to waste of their time and money since they'll be forced to deal with user complains about why their PHP scripts are not working. Even people with the ability to modify this file will not necessarily edit it and only do so if they need to change an option not changeable via other means. We should have warned people not to use short tags years ago. What happened in the past is in the past, lets concentrate on the future. We can try it from now. Until we get rid of short tag or disable it by default, we suggest users to work around problem. echo ?xml ..? works always and authors of portable scripts should use it. If there are new processing tags, echo ?new_xml_PI .? instead of adding new PI to parser. (We never know if user use custom PI tag or not) I think that we can say with a fair degree of certainty ?xml will remain as is. No one will want to change for BC reasons ;). I find it even less likely that we'd drop short tags when PHP6 comes around because they'll be even more users using them then there are now (assuming php usage increases). For most people it is easier to use ? then ?php and since it works just about everywhere it is 'safe' to do, at least as far as they know. It is also to easier to remember, especially for newbies, which imho is the most common reasons people use them. Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] short_open_tag
Ilia A. wrote: We should have warned people not to use short tags years ago. What happened in the past is in the past, lets concentrate on the future. Sure. We should. The best way to go is discourage use of short tag whenever possible, change default few years later, IMHO. Even if we never change the default, ?php echo ?xml ..?;? works always w/o patch. Yes, that works, but what about all the people who for whatever reason make their PHP parse all pages, even .html ones. On such a server if someone places an XML (XHTML) document, won't they be surprised by the parse errors they get. This person may not even know PHP exists and yet they would get PHP errors. No amount of documentation will solve this sort of a problem and this is just one example, there are more. This is one of the reason why I think we should try to change short_open_tag default. ? is reserved for XML PI (Processing Instruction). There may be many (and/or custom) PI tags and it may become more serious problem in the future. We may even have XML processor that processes PHP code in XML documents in the future. i.e. PHP interpreter is invoked from XML processor. Fortunately, we don't have much problem now. I think we are better to start discourage use of short tag more loudly instead of work around one by one. -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: $_GET, $_POST, $_COOKIE, $_FILES == $_REQUEST?
Another option. How about remove $_FILES contents from $_REQUEST? It seems it has less impact. -- Yasuo Ohgaki Sterling Hughes wrote: Hey, If you haven't taken a look @: http://bugs.php.net/bug.php?id=19848 please do so... In thinking about it, to me, there are 2 solutions: 1) Rearranging files to work in an un-braindead manner, ie: instead of $_FILES['toto']['type']['c'] equaling the filetype of the form variable: INPUT TYPE="file" NAME="toto[c]" We have :: $_FILES['toto']['c']['type'] Of course this breaks BC, which is not good, but then again, neither is the alternative. 2) The alternative is to add some custom code (I'll write it up) that will re-arrange the $_FILES array when it is inserted into the $_REQUEST array (leaving the $_FILES array alone, but modifying its order when its merged into $_REQUEST). so you have: $_REQUEST['toto']['c']['type'] and $_FILES['toto']['type']['c'] which is ugly and just not right, but it maintains backwards compatibility with the $_FILES array. My personal opinion is that the second solution should be merged in for PHP 4.3, and that for PHPv5 we should normalize the $_FILE array. Thoughts? Comments? Questions? I'll start working on this tommorow unless i hear otherwise.. -Sterling -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: $_GET, $_POST, $_COOKIE, $_FILES == $_REQUEST?
Melvyn Sopacua wrote: First 'force' people to use superglobals, then say ehm - yeah, but ehm uploaded files are not userdata, because they are not in $_REQUEST. Is it very important? Anyway, it is easier to write more robust application with $_GET/$_PSOT/$_COOKIE/$_FILES, IMO. $_REQUEST is useful but $_FILES is not strictly needed to be in $_REQUEST especially when $_FILES structure needed to be changed to make it work correctly. Changes in $_FILES structure breaks all applications uses $_FILES. Removing $_FILES from $_REQUEST does not break not many applications, I hope ;) Anyway, I'm 0 for all options. If we'll fix $_FILES structure, sooner is better. -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
