5.4 beta & tests

13 years ago by Laruence — view source

unread

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_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

--

--
Laruence Xinchen Hui
http://www.laruence.com/

13 years ago by Laruence — view source

unread

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 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_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

--

--
Laruence Xinchen Hui
http://www.laruence.com/

--
Laruence Xinchen Hui
http://www.laruence.com/

13 years ago by Stas Malyshev — view source

unread

Hi!

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 )

I'm linking against libmysql, version 5.1.46.

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

13 years ago by Rasmus Lerdorf — view source

unread

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 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=311033&r2=311509

http://svn.php.net/viewvc/php/php-src/branches/PHP_5_4/tests/security/open_basedir_readlink.phpt?r1=311033&r2=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=296679&r2=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

13 years ago by Stas Malyshev — view source

unread

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

13 years ago by Stas Malyshev — view source

unread

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

13 years ago by Rasmus Lerdorf — view source

unread

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

13 years ago by Stas Malyshev — view source

unread

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

13 years ago by Rasmus Lerdorf — view source

unread

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

-Rasmus

13 years ago by Stas Malyshev — view source

unread

Hi!

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

13 years ago by Lonny Kapelushnik — view source

unread

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

13 years ago by Matthew Weier O'Phinney — view source

unread

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 | matthew@zend.com
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

13 years ago by johannes@schlueters.de — view source

unread

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

13 years ago by Daniel Convissor — view source

unread

Hi:

http://codepad.org/ZV8imUuc

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

13 years ago by Daniel Convissor — view source

unread

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

13 years ago by Tjerk Meesters — view source

unread

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=311033&r2=311509

http://svn.php.net/viewvc/php/php-src/branches/PHP_5_4/tests/security/open_basedir_readlink.phpt?r1=311033&r2=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=296679&r2=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

13 years ago by Laruence — view source

unread

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_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

--

--
Laruence Xinchen Hui
http://www.laruence.com/

13 years ago by Stas Malyshev — view source

unread

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

13 years ago by Christian Stocker — view source

unread

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

13 years ago by Christian Stocker — view source

unread

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

13 years ago by Laruence — view source

unread

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/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

--

--
Laruence Xinchen Hui
http://www.laruence.com/

13 years ago by Christian Stocker — view source

unread

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/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

--

--
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

13 years ago by Ilia Alshanetsky — view source

unread

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/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

--

--
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

13 years ago by Christian Stocker — view source

unread

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/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

--

--
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

13 years ago by Rob Richards — view source

unread

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

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?

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?

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'm most bothered by many mysql and mbstring failures. Also libxml seems
to be something broken in recent changes.

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.

I think I can just set the TZ for this test. It seems to be testing
another things...

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'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?

5.4 beta & tests

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?

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?

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'm most bothered by many mysql and mbstring failures. Also libxml seems to be something broken in recent changes.

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.

I think I can just set the TZ for this test. It seems to be testing another things...

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'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?

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?

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?

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'm most bothered by many mysql and mbstring failures. Also libxml seems
to be something broken in recent changes.

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.

I think I can just set the TZ for this test. It seems to be testing
another things...

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'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?