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
Hi:
I run make test yesterday, and seems the result is quite different
anyway, I will check it agian,
PS, it's better if there is the test.diff and the config.log
(like link against libmysql or mysqlnd )
thanks
2011/8/31 Stas Malyshev smalyshev@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_xMost 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--
--
Laruence Xinchen Hui
http://www.laruence.com/
Stas:
sorry for missing the info about diff ,
anyway, the http://qa.php.net/reports/ seems down:
"An error occured when reading a DB file."
thanks
2011/8/31 Laruence laruence@php.net:
Hi:
I run make test yesterday, and seems the result is quite differentanyway, I will check it agian,
PS, it's better if there is the test.diff and the config.log
(like link against libmysql or mysqlnd )thanks
2011/8/31 Stas Malyshev smalyshev@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_xMost 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--
--
Laruence Xinchen Hui
http://www.laruence.com/
--
Laruence Xinchen Hui
http://www.laruence.com/
Hi!
Hi:
I run make test yesterday, and seems the result is quite differentanyway, I will check it agian, PS, it's better if there is the test.diff and the config.log(like link against libmysql or mysqlnd )
I'm linking against libmysql, version 5.1.46.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
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_xMost 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 two openbasedir tests were broken by these commits:
which you merged from trunk based on changes by jeraimee:
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
Hi!
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.
Both of these are related to timeouts/shutdown functions and seem not to
work on my machine for some reason. May be related to Zend Signals patch.
The two openbasedir tests were broken by these commits:
Openbasedir tests fail because of a bug in opendir implementation which
doesn't allow to unlink symlink that is by itself OK but points to
prohibited file. I've XFAILed one tests and removed unlink from another,
since cleanup removes the link anyway. unlink() bug still needs to be fixed.
ext/date/tests/bug33532.phpt doesn't fail for me. LOCALE differences?
What is your diff on that one?
strftime() on Mac seems to ignore timezone arguments in struct tm for
some reason and uses environment TZ instead. Not sure how to address that.
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.
I'm most bothered by many mysql and mbstring failures. Also libxml seems
to be something broken in recent changes.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi!
strftime()on Mac seems to ignore timezone arguments in struct tm for
some reason and uses environment TZ instead. Not sure how to address that.
Looking into Mac strftime sources, it says this:
** C99 says that the UTC offset must
** be computed by looking only at
** tm_isdst. This requirement is
** incorrect, since it means the code
** must rely on magic (in this case
** altzone and timezone), and the
** magic might not have the correct
** offset. Doing things correctly is
** tricky and requires disobeying C99;
** see GNU C strftime for details.
** For now, punt and conform to the
** standard, even though it's incorrect.
Which means, since we can't touch the environment in php_date.c code, we
have to set TZ env variable for the test to pass, and strftime for Mac
is dependent on TZ env and we can't do a thing about it as it seems.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi!
strftime()on Mac seems to ignore timezone arguments in struct tm for
some reason and uses environment TZ instead. Not sure how to address
that.Looking into Mac strftime sources, it says this:
** C99 says that the UTC offset must ** be computed by looking only at ** tm_isdst. This requirement is ** incorrect, since it means the code ** must rely on magic (in this case ** altzone and timezone), and the ** magic might not have the correct ** offset. Doing things correctly is ** tricky and requires disobeying C99; ** see GNU C strftime for details. ** For now, punt and conform to the ** standard, even though it's incorrect.Which means, since we can't touch the environment in php_date.c code, we
have to set TZ env variable for the test to pass, and strftime for Mac
is dependent on TZ env and we can't do a thing about it as it seems.
Right, so this is an XFAIL test on the Mac I guess, although I don't
think we have any way to indicate a platform-specific XFAIL. So maybe
add a Mac check and make it a SKIP on the Mac.
-Rasmus
Hi!
Which means, since we can't touch the environment in php_date.c code, we
have to set TZ env variable for the test to pass, and strftime for Mac
is dependent on TZ env and we can't do a thing about it as it seems.Right, so this is an XFAIL test on the Mac I guess, although I don't
think we have any way to indicate a platform-specific XFAIL. So maybe
add a Mac check and make it a SKIP on the Mac.
I think I can just set the TZ for this test. It seems to be testing
another things...
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
I am down to 34 test failures compiling against mysqlnd instead of libmysql
I did have to set MYSQL_TEST_SOCKET=/var/run/mysqld/mysqld.sock in my
environment though. It was defaulting to /tmp/mysql.sock
-Rasmus
Hi!
I am down to 34 test failures compiling against mysqlnd instead of libmysql
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, apparentlyhtmlentities()has tons of flags which aren't
documented anywhere.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Test
strtolower()function [ext/standard/tests/strings/strtolower.phpt]
Teststrtoupper()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
I am down to 34 test failures compiling against mysqlnd instead of libmysql
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 | matthew@zend.com
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
I am down to 34 test failures compiling against mysqlnd instead of libmysql
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
Hi:
I see Rasmus is only getting one mysqli failure. I'm getting several.
The diff, out and exp files can be found here:
http://www.analysisandsolutions.com/php/mysqli.test.failures.tbz
I didn't modify the tests because they're working for other people.
Built 5.4 from svn checkout this afternoon using "--with-mysqli=mysqlnd."
mysqld Ver 5.1.41-3ubuntu12.10 for debian-linux-gnu on x86_64 ((Ubuntu))
Thanks,
--Dan
--
T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y
data intensive web and database programming
http://www.AnalysisAndSolutions.com/
4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409
Hi Again:
http://www.analysisandsolutions.com/php/mysqli.test.failures.tbz
I didn't modify the tests because they're working for other people.
Built 5.4 from svn checkout this afternoon using "--with-mysqli=mysqlnd."
mysqld Ver 5.1.41-3ubuntu12.10 for debian-linux-gnu on x86_64 ((Ubuntu))
I just ran tests after building "--with-mysqli=/usr/bin/mysql_config"
It produced even more failures:
http://www.analysisandsolutions.com/php/mysqli.test.failures.libmysql.tbz
Thanks,
--Dan
--
T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y
data intensive web and database programming
http://www.AnalysisAndSolutions.com/
4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409
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_xMost 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:
which you merged from trunk based on changes by jeraimee:
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
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 smalyshev@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_xMost 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--
--
Laruence Xinchen Hui
http://www.laruence.com/
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=311870&r2=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
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=311870&r2=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
Hi
Here's my proposed patch
https://gist.github.com/1183212
If noone objects, I'll commit it soon
chregu
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=311870&r2=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
Hi:
I think you should not commit untill ask ilia for the reason of
previous change,
thanks
2011/8/31 Christian Stocker christian.stocker@liip.ch:
Hi
Here's my proposed patch
https://gist.github.com/1183212If noone objects, I'll commit it soon
chregu
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=311870&r2=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--
--
Laruence Xinchen Hui
http://www.laruence.com/
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.stocker@liip.ch:
Hi
Here's my proposed patch
https://gist.github.com/1183212If noone objects, I'll commit it soon
chregu
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=311870&r2=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--
--
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
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.stocker@liip.ch 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.stocker@liip.ch:
Hi
Here's my proposed patch
https://gist.github.com/1183212If noone objects, I'll commit it soon
chregu
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=311870&r2=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--
--
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
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.stocker@liip.ch 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.stocker@liip.ch:
Hi
Here's my proposed patch
https://gist.github.com/1183212If noone objects, I'll commit it soon
chregu
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=311870&r2=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--
--
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--
--
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
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=311870&r2=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