Re: [PHP-DEV] 5.4 beta tests
Hi! On 8/30/11 10:55 PM, Rasmus Lerdorf wrote: I am down to 34 test failures compiling against mysqlnd instead of libmysql http://codepad.org/ZV8imUuc I did have to set MYSQL_TEST_SOCKET=/var/run/mysqld/mysqld.sock in my environment though. It was defaulting to /tmp/mysql.sock I'm looking into htmlentities() test. Something weird is going on there - first of all, I don't understand what passing charset '' is supposed to mean. Secondly, I don't see which code is supposed to generate the expected numeric entities - for me, it just ignores the characters. Third, apparently htmlentities() has tons of flags which aren't documented anywhere. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 beta tests
Test strtolower() function [ext/standard/tests/strings/strtolower.phpt] Test strtoupper() function [ext/standard/tests/strings/strtoupper1.phpt] I believe these fail on OSX because we test for undefined ASCII behavior. We call strtolower/strtoupper for all 256 ASCII characters, but ASCII is only defined for 128. The failure in these tests on OSX is above 128, which I do not think we should be testing for. I created a bug for the tests and added a patch to remove testing above 128 chars: https://bugs.php.net/bug.php?id=55546
Re: [PHP-DEV] 5.4 beta tests
Hi: it's odd that parse_ini_*.phpt failed in my built environ, but seems didn't fail in your list. so maybe my changes is not appropriate? thanks 2011/8/31 Stas Malyshev smalys...@sugarcrm.com: Hi! I've checked the unit tests on my Mac and I see 48 failures so far. I've put them here: https://wiki.php.net/todo/tests54?#tested_2011-08-30_on_mac_os_x Most of them are mysql, but others too. So, is there anybody working or willing to work to fix them all for beta? Should we postpone the beta for a week to wait for that or it doesn't make difference? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 beta tests
Hi! For simplexml test (ext/simplexml/tests/bug48601.phpt), it looks like Ilia reverted the fix for bug #48601 with this: http://svn.php.net/viewvc/php/php-src/branches/PHP_5_4/ext/simplexml/simplexml.c?r1=311870r2=311874 I'm not sure what simplexml is supposed to return in each case, the tests seem to be contradictory. Anybody knows what is the right thing to do here? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Cannot build ext/intl on Fedora 15
On 08/27/2011 10:49 AM, Sebastian Bergmann wrote: /usr/bin/ld: ext/intl/msgformat/msgformat_helpers.o: undefined reference to symbol '__gxx_personality_v0@@CXXABI_1.3' /usr/bin/ld: note: '__gxx_personality_v0@@CXXABI_1.3' is defined in DSO /usr/lib64/libstdc++.so.6 so try adding it to the linker command line /usr/lib64/libstdc++.so.6: could not read symbols: Invalid operation collect2: ld returned 1 exit status Can somebody please fix this? It would be nice if PHP would build without such issues on new distributions. Thanks! -- Sebastian BergmannCo-Founder and Principal Consultant http://sebastian-bergmann.de/ http://thePHP.cc/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Cannot build ext/intl on Fedora 15
you are the only one to actually experience this, so I suppose you are the only who can fix it as well :) On Wed, Aug 31, 2011 at 11:18 AM, Sebastian Bergmann sebast...@php.net wrote: On 08/27/2011 10:49 AM, Sebastian Bergmann wrote: /usr/bin/ld: ext/intl/msgformat/msgformat_helpers.o: undefined reference to symbol '__gxx_personality_v0@@CXXABI_1.3' /usr/bin/ld: note: '__gxx_personality_v0@@CXXABI_1.3' is defined in DSO /usr/lib64/libstdc++.so.6 so try adding it to the linker command line /usr/lib64/libstdc++.so.6: could not read symbols: Invalid operation collect2: ld returned 1 exit status Can somebody please fix this? It would be nice if PHP would build without such issues on new distributions. Thanks! -- Sebastian Bergmann Co-Founder and Principal Consultant http://sebastian-bergmann.de/ http://thePHP.cc/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 beta tests
On 31.08.11 09:47, Stas Malyshev wrote: Hi! For simplexml test (ext/simplexml/tests/bug48601.phpt), it looks like Ilia reverted the fix for bug #48601 with this: http://svn.php.net/viewvc/php/php-src/branches/PHP_5_4/ext/simplexml/simplexml.c?r1=311870r2=311874 I'm not sure what simplexml is supposed to return in each case, the tests seem to be contradictory. Anybody knows what is the right thing to do here? Ilia fixed test 0008.phpt with that, but for some reason an XPath of *** isn't considered invalid by libxml (but ** is, don't ask me why ;)). I'd say if libxml doesn't think the XPath expression is invalid, we should return an empty array and not false. With DOM exactly that happens. I therefore vote for reverting Ilia's patch mentioned above. chregu -- Liip AG // Feldstrasse 133 // CH-8004 Zurich Tel +41 43 500 39 81 // Mobile +41 76 561 88 60 www.liip.ch // blog.liip.ch // GnuPG 0x0748D5FE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 beta tests
Hi Here's my proposed patch https://gist.github.com/1183212 If noone objects, I'll commit it soon chregu On 31.08.11 11:39, Christian Stocker wrote: On 31.08.11 09:47, Stas Malyshev wrote: Hi! For simplexml test (ext/simplexml/tests/bug48601.phpt), it looks like Ilia reverted the fix for bug #48601 with this: http://svn.php.net/viewvc/php/php-src/branches/PHP_5_4/ext/simplexml/simplexml.c?r1=311870r2=311874 I'm not sure what simplexml is supposed to return in each case, the tests seem to be contradictory. Anybody knows what is the right thing to do here? Ilia fixed test 0008.phpt with that, but for some reason an XPath of *** isn't considered invalid by libxml (but ** is, don't ask me why ;)). I'd say if libxml doesn't think the XPath expression is invalid, we should return an empty array and not false. With DOM exactly that happens. I therefore vote for reverting Ilia's patch mentioned above. chregu -- Liip AG // Feldstrasse 133 // CH-8004 Zurich Tel +41 43 500 39 81 // Mobile +41 76 561 88 60 www.liip.ch // blog.liip.ch // GnuPG 0x0748D5FE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Cannot build ext/intl on Fedora 15
On Wed, Aug 31, 2011 at 11:32 AM, Pierre Joye pierre@gmail.com wrote: you are the only one to actually experience this, so I suppose you are the only who can fix it as well :) from Gwynne: This issue exists on Darwin (OS X) as well. this will also happen with debian wheezy(next stable version): http://wiki.debian.org/ToolChain/DSOLinking#DSO_Linking_Changes_for_wheezy and it already happened with the last stable version of Ubuntu (Natty): https://blueprints.launchpad.net/ubuntu/+spec/foundations-n-dso-linking I think we should fix this on our end. -- Ferenc Kovács @Tyr43l - http://tyrael.hu -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 beta tests
Hi: I think you should not commit untill ask ilia for the reason of previous change, thanks 2011/8/31 Christian Stocker christian.stoc...@liip.ch: Hi Here's my proposed patch https://gist.github.com/1183212 If noone objects, I'll commit it soon chregu On 31.08.11 11:39, Christian Stocker wrote: On 31.08.11 09:47, Stas Malyshev wrote: Hi! For simplexml test (ext/simplexml/tests/bug48601.phpt), it looks like Ilia reverted the fix for bug #48601 with this: http://svn.php.net/viewvc/php/php-src/branches/PHP_5_4/ext/simplexml/simplexml.c?r1=311870r2=311874 I'm not sure what simplexml is supposed to return in each case, the tests seem to be contradictory. Anybody knows what is the right thing to do here? Ilia fixed test 0008.phpt with that, but for some reason an XPath of *** isn't considered invalid by libxml (but ** is, don't ask me why ;)). I'd say if libxml doesn't think the XPath expression is invalid, we should return an empty array and not false. With DOM exactly that happens. I therefore vote for reverting Ilia's patch mentioned above. chregu -- Liip AG // Feldstrasse 133 // CH-8004 Zurich Tel +41 43 500 39 81 // Mobile +41 76 561 88 60 www.liip.ch // blog.liip.ch // GnuPG 0x0748D5FE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 beta tests
On 31.08.11 12:25, Laruence wrote: Hi: I think you should not commit untill ask ilia for the reason of previous change, sure, but my guess is he just fixed the code to pass the test, but IMHO the test was wrong (and my patches fixes that). ilia? chregu thanks 2011/8/31 Christian Stocker christian.stoc...@liip.ch: Hi Here's my proposed patch https://gist.github.com/1183212 If noone objects, I'll commit it soon chregu On 31.08.11 11:39, Christian Stocker wrote: On 31.08.11 09:47, Stas Malyshev wrote: Hi! For simplexml test (ext/simplexml/tests/bug48601.phpt), it looks like Ilia reverted the fix for bug #48601 with this: http://svn.php.net/viewvc/php/php-src/branches/PHP_5_4/ext/simplexml/simplexml.c?r1=311870r2=311874 I'm not sure what simplexml is supposed to return in each case, the tests seem to be contradictory. Anybody knows what is the right thing to do here? Ilia fixed test 0008.phpt with that, but for some reason an XPath of *** isn't considered invalid by libxml (but ** is, don't ask me why ;)). I'd say if libxml doesn't think the XPath expression is invalid, we should return an empty array and not false. With DOM exactly that happens. I therefore vote for reverting Ilia's patch mentioned above. chregu -- Liip AG // Feldstrasse 133 // CH-8004 Zurich Tel +41 43 500 39 81 // Mobile +41 76 561 88 60 www.liip.ch // blog.liip.ch // GnuPG 0x0748D5FE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Liip AG // Feldstrasse 133 // CH-8004 Zurich Tel +41 43 500 39 81 // Mobile +41 76 561 88 60 www.liip.ch // blog.liip.ch // GnuPG 0x0748D5FE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 beta tests
Revert sounds find to me, the change was indeed to fix the test. On Wed, Aug 31, 2011 at 6:58 AM, Christian Stocker christian.stoc...@liip.ch wrote: On 31.08.11 12:25, Laruence wrote: Hi: I think you should not commit untill ask ilia for the reason of previous change, sure, but my guess is he just fixed the code to pass the test, but IMHO the test was wrong (and my patches fixes that). ilia? chregu thanks 2011/8/31 Christian Stocker christian.stoc...@liip.ch: Hi Here's my proposed patch https://gist.github.com/1183212 If noone objects, I'll commit it soon chregu On 31.08.11 11:39, Christian Stocker wrote: On 31.08.11 09:47, Stas Malyshev wrote: Hi! For simplexml test (ext/simplexml/tests/bug48601.phpt), it looks like Ilia reverted the fix for bug #48601 with this: http://svn.php.net/viewvc/php/php-src/branches/PHP_5_4/ext/simplexml/simplexml.c?r1=311870r2=311874 I'm not sure what simplexml is supposed to return in each case, the tests seem to be contradictory. Anybody knows what is the right thing to do here? Ilia fixed test 0008.phpt with that, but for some reason an XPath of *** isn't considered invalid by libxml (but ** is, don't ask me why ;)). I'd say if libxml doesn't think the XPath expression is invalid, we should return an empty array and not false. With DOM exactly that happens. I therefore vote for reverting Ilia's patch mentioned above. chregu -- Liip AG // Feldstrasse 133 // CH-8004 Zurich Tel +41 43 500 39 81 // Mobile +41 76 561 88 60 www.liip.ch // blog.liip.ch // GnuPG 0x0748D5FE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Liip AG // Feldstrasse 133 // CH-8004 Zurich Tel +41 43 500 39 81 // Mobile +41 76 561 88 60 www.liip.ch // blog.liip.ch // GnuPG 0x0748D5FE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 beta tests
On Aug 31, 2011, at 5:39 AM, Christian Stocker christian.stoc...@liip.ch wrote: On 31.08.11 09:47, Stas Malyshev wrote: Hi! For simplexml test (ext/simplexml/tests/bug48601.phpt), it looks like Ilia reverted the fix for bug #48601 with this: http://svn.php.net/viewvc/php/php-src/branches/PHP_5_4/ext/simplexml/simplexml.c?r1=311870r2=311874 I'm not sure what simplexml is supposed to return in each case, the tests seem to be contradictory. Anybody knows what is the right thing to do here? Ilia fixed test 0008.phpt with that, but for some reason an XPath of *** isn't considered invalid by libxml (but ** is, don't ask me why ;)). I'd say if libxml doesn't think the XPath expression is invalid, we should return an empty array and not false. With DOM exactly that happens. I therefore vote for reverting Ilia's patch mentioned above. chregu I'd like to revert it as well. Have been going back an forth myself. It look like sometimes internally libxml does see the expressions as invalid but doesn't communicate that back to the caller (bug there IMO) so right now you can always write a test that fails regardless of which code is used in simplexml Rob -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 beta tests
On 31.08.11 13:32, Ilia Alshanetsky wrote: Revert sounds find to me, the change was indeed to fix the test. Ok. Committed. JFTR, I also fixed the tests in xsl and libxml. They should pass now (at least on my machine they do :)) chregu On Wed, Aug 31, 2011 at 6:58 AM, Christian Stocker christian.stoc...@liip.ch wrote: On 31.08.11 12:25, Laruence wrote: Hi: I think you should not commit untill ask ilia for the reason of previous change, sure, but my guess is he just fixed the code to pass the test, but IMHO the test was wrong (and my patches fixes that). ilia? chregu thanks 2011/8/31 Christian Stocker christian.stoc...@liip.ch: Hi Here's my proposed patch https://gist.github.com/1183212 If noone objects, I'll commit it soon chregu On 31.08.11 11:39, Christian Stocker wrote: On 31.08.11 09:47, Stas Malyshev wrote: Hi! For simplexml test (ext/simplexml/tests/bug48601.phpt), it looks like Ilia reverted the fix for bug #48601 with this: http://svn.php.net/viewvc/php/php-src/branches/PHP_5_4/ext/simplexml/simplexml.c?r1=311870r2=311874 I'm not sure what simplexml is supposed to return in each case, the tests seem to be contradictory. Anybody knows what is the right thing to do here? Ilia fixed test 0008.phpt with that, but for some reason an XPath of *** isn't considered invalid by libxml (but ** is, don't ask me why ;)). I'd say if libxml doesn't think the XPath expression is invalid, we should return an empty array and not false. With DOM exactly that happens. I therefore vote for reverting Ilia's patch mentioned above. chregu -- Liip AG // Feldstrasse 133 // CH-8004 Zurich Tel +41 43 500 39 81 // Mobile +41 76 561 88 60 www.liip.ch // blog.liip.ch // GnuPG 0x0748D5FE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Liip AG // Feldstrasse 133 // CH-8004 Zurich Tel +41 43 500 39 81 // Mobile +41 76 561 88 60 www.liip.ch // blog.liip.ch // GnuPG 0x0748D5FE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Liip AG // Feldstrasse 133 // CH-8004 Zurich Tel +41 43 500 39 81 // Mobile +41 76 561 88 60 www.liip.ch // blog.liip.ch // GnuPG 0x0748D5FE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 beta tests
On Aug 31, 2011 12:14 PM, Rasmus Lerdorf ras...@lerdorf.com wrote: On 08/30/2011 08:39 PM, Stas Malyshev wrote: Hi! I've checked the unit tests on my Mac and I see 48 failures so far. I've put them here: https://wiki.php.net/todo/tests54?#tested_2011-08-30_on_mac_os_x Most of them are mysql, but others too. So, is there anybody working or willing to work to fix them all for beta? Should we postpone the beta for a week to wait for that or it doesn't make difference? I say we postpone. We really need to get used to the fact that failing tests matter and that they block releases. Why is your tests/func/005a.phpt failing? That seems to pass consistently for most people. tests/lang/045.phpt is the one that fails for everyone because we don't re-apply the timeout for a registered shutdown function. We should either fix that or mark it as an XFAIL. The timeout gets applied but the SIG_ALARM gets filtered by the signal handler because SIGG(running) is still true. Setting running to false inside zend_timeout before calling the other functions seems a (hack?) solution. The two openbasedir tests were broken by these commits: http://svn.php.net/viewvc/php/php-src/branches/PHP_5_4/tests/security/open_basedir_linkinfo.phpt?r1=311033r2=311509 http://svn.php.net/viewvc/php/php-src/branches/PHP_5_4/tests/security/open_basedir_readlink.phpt?r1=311033r2=311507 which you merged from trunk based on changes by jeraimee: http://svn.php.net/viewvc/php/php-src/trunk/tests/security/open_basedir_linkinfo.phpt?r1=296679r2=311141 so we should figure out why that was changed. I don't think this behaviour is difference between trunk and 5.4 so I don't understand the change. ext/date/tests/bug33532.phpt doesn't fail for me. LOCALE differences? What is your diff on that one? I'm not sure how we should attack it, but I think with a little bit of discussion on each failing test we can plow through these pretty quickly. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 beta tests
On 2011-08-31, Rasmus Lerdorf ras...@lerdorf.com wrote: I am down to 34 test failures compiling against mysqlnd instead of libmysql http://codepad.org/ZV8imUuc I did have to set MYSQL_TEST_SOCKET=/var/run/mysqld/mysqld.sock in my environment though. It was defaulting to /tmp/mysql.sock I've noticed this on Ubuntu for the last year or two; the extension does not appear to honor the default_socket config directive. -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/ branches/PHP_5_4/ext/standard/tests/strings/htmlentities15.phpt trunk/ext/standard/tests/strings/htmlentities15.phpt
On Wed, 31 Aug 2011 07:39:43 +0100, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! On 8/30/11 11:32 PM, Gustavo André dos Santos Lopes wrote: cataphract Wed, 31 Aug 2011 06:32:05 + Revision: http://svn.php.net/viewvc?view=revisionrevision=315851 Log: - Fixed test htmlentities15.phpt. Changed paths: U php/php-src/branches/PHP_5_4/ext/standard/tests/strings/htmlentities15.phpt U php/php-src/trunk/ext/standard/tests/strings/htmlentities15.phpt Modified: php/php-src/branches/PHP_5_4/ext/standard/tests/strings/htmlentities15.phpt === --- php/php-src/branches/PHP_5_4/ext/standard/tests/strings/htmlentities15.phpt 2011-08-31 06:26:39 UTC (rev 315850) +++ php/php-src/branches/PHP_5_4/ext/standard/tests/strings/htmlentities15.phpt 2011-08-31 06:32:05 UTC (rev 315851) @@ -11,6 +11,9 @@ die(skip setlocale() failed\n); } ? +--COMMENT-- +As of PHP 5.4, htmlentities() no longer makes replacements with numerical +entities. Hence, for this input there's no substitution. --FILE-- ?php setlocale(LC_CTYPE, ru_RU.koi8r, ru_RU.KOI8-R); @@ -19,4 +22,4 @@ ? --EXPECT-- string(9) � -string(63) #1088;#1086;#1089;#1082;#1086;#1096;#1085;#1099;#1081; +string(9) � Could you explain what this test is doing and why? What '' encoding means (docs say nothing of it), why we set locale to KOI8-R? The '' encoding activates the old behavior of detecting the encoding. This detection from the locale and other sources dates to before htmlentitites had an encoding parameter. It's been working this way since 2001: http://lxr.php.net/xref/PHP_TRUNK/ext/standard/html.c?a=truer=50559#229 In the revision before, not specifying the encoding would have the same effect as specifying '', i.e. autodetection. But you're right, it should be documented. (CC to internals because you also sent an e-mail about this test there) -- Gustavo Lopes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Latest Revsion to PDO_MySQL
http://svn.php.net/viewvc?view=revisionsortby=daterevision=315905 shouldnt the php pages for this, really use preg instead of ereg, just a wonder really
Re: [PHP-DEV] Latest Revsion to PDO_MySQL
On Wed, 2011-08-31 at 16:54 +0100, Keloran wrote: http://svn.php.net/viewvc?view=revisionsortby=daterevision=315905 shouldnt the php pages for this, really use preg instead of ereg, Well it's a utility for maintainers, no page or something, run every few years. Yes using preg might be better, but doesn't matter too much - the next time it will be run MySQL will probably have changed the file format a bit more so it has to be re-done ... johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 beta tests
On Wed, 2011-08-31 at 10:42 -0400, Matthew Weier O'Phinney wrote: On 2011-08-31, Rasmus Lerdorf ras...@lerdorf.com wrote: I am down to 34 test failures compiling against mysqlnd instead of libmysql http://codepad.org/ZV8imUuc I did have to set MYSQL_TEST_SOCKET=/var/run/mysqld/mysqld.sock in my environment though. It was defaulting to /tmp/mysql.sock You can also use --with-mysql-sock=DIR, with mysqlnd we don't know what was set on MySQL side. I've noticed this on Ubuntu for the last year or two; the extension does not appear to honor the default_socket config directive. Which extension? - Mind that the three MySQL extensions all have their own ini setting. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] 5.4 beta postponing
Hi! I see we're making good progress on unit tests fails, though a bunch still remains. So in case somebody didn't read the discussion - I'm moving beta target to next week, September 8, in hope we'll have 0 unit test fails by then. Thanks for everybody contributing to fixing the tests and keep the good work! :) -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] 2 new test failures
Pierre, your changes today caused 2 new test failures: Bug #51709 (Can't use keywords as method names) [tests/basic/bug51709_1.phpt] Bug #51709 (Can't use keywords as method names) [tests/basic/bug51709_2.phpt] The diffs: 001+ Parse error: syntax error, unexpected 'for' (T_FOR), expecting identifier (T_STRING) in /home/rasmus/php-src/branches/PHP_5_4/tests/basic/bug51709_1.php on line 4 001- Parse error: %s error, %s(T_STRING)%s in %sbug51709_1.php on line %d 001+ Parse error: syntax error, unexpected 'goto' (T_GOTO), expecting identifier (T_STRING) in /home/rasmus/php-src/branches/PHP_5_4/tests/basic/bug51709_2.php on line 4 001- Parse error: %s error, %s(T_STRING)%s in %sbug51709_2.php on line %d -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] simplexml inconsistencies in the last few releases (the same issue already discussed)
Hi
It's about the two tests in
http://svn.php.net/viewvc/php/php-src/branches/PHP_5_3/ext/simplexml/tests/008.phpt
and
http://svn.php.net/viewvc/php/php-src/branches/PHP_5_3/ext/simplexml/tests/bug48601.phpt
which contractited themself and we had back and forth commits due to this.
So we had the following history
5.3.0 old behaviour
...
5.3.3 new behaviour
...
5.3.7 old behaviour
...
5.4.0 new behaviour
The main question now is, should we introduce back the new behavior in
the 5.3 line? Since the new behaviour was already there since more than
a year, but now isn't, i'm not sure, what to do.
The good point about the new behaviour is that it's almost BC, so going
from the old to the new shouldn't cause much problems, but vice versa it
does. The reason is that if you do an valid xpath query which returns
zero results, the old behaviour returned false, the new one returns an
empty array, so before 5.3.3 you had to write
***
$res = $sx-query(/some/xpath);
if ($res) {
foreach($res as $node) {}
}
***
Which still will work with the new behaviour, but that if is not
really needed with the new behaviour, so going back to the old one may
break if nothing is found (there may be problems when you asked for
zero-results with checking if $res is false)
Anyway, I'd appreciate some opinions about introducing back the new
beehaviour in 5.3 or not (I guess 5.3.8 wasn't the last 5.3 release :))
chregu
--
Liip AG // Feldstrasse 133 // CH-8004 Zurich
Tel +41 43 500 39 81 // Mobile +41 76 561 88 60
www.liip.ch // blog.liip.ch // GnuPG 0x0748D5FE
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
