FAQ
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

Search Discussions

  • Laruence at Aug 31, 2011 at 3:57 am
    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

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php


    --
    Laruence  Xinchen Hui
    http://www.laruence.com/
  • Laruence at Aug 31, 2011 at 3:59 am
    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

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php


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


    --
    Laruence  Xinchen Hui
    http://www.laruence.com/
  • Stas Malyshev at Aug 31, 2011 at 4:01 am
    Hi!
    On 8/30/11 8:57 PM, Laruence wrote:
    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
  • Rasmus Lerdorf at Aug 31, 2011 at 4:13 am

    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 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
  • Stas Malyshev at Aug 31, 2011 at 4:53 am
    Hi!
    On 8/30/11 9:13 PM, Rasmus Lerdorf wrote:
    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
  • Stas Malyshev at Aug 31, 2011 at 5:08 am
    Hi!
    On 8/30/11 9:53 PM, Stas Malyshev wrote:
    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
  • Rasmus Lerdorf at Aug 31, 2011 at 5:23 am

    On 08/30/2011 10:08 PM, Stas Malyshev wrote:
    Hi!
    On 8/30/11 9:53 PM, Stas Malyshev wrote:
    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
  • Stas Malyshev at Aug 31, 2011 at 5:53 am
    Hi!
    On 8/30/11 10:23 PM, Rasmus Lerdorf wrote:
    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
  • Rasmus Lerdorf at Aug 31, 2011 at 5:54 am
    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
  • Stas Malyshev at Aug 31, 2011 at 6:33 am
    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
  • Lonny Kapelushnik at Aug 31, 2011 at 6:52 am

    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
  • Matthew Weier O'Phinney at Aug 31, 2011 at 2:42 pm

    On 2011-08-31, 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'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
  • Johannes Schlüter at Aug 31, 2011 at 4:20 pm

    On Wed, 2011-08-31 at 10:42 -0400, Matthew Weier O'Phinney wrote:
    On 2011-08-31, 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
    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
  • Daniel Convissor at Sep 1, 2011 at 7:57 pm
    Hi:
    On Tue, Aug 30, 2011 at 10:55:48PM -0700, Rasmus Lerdorf wrote:

    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
  • Daniel Convissor at Sep 2, 2011 at 1:41 pm
    Hi Again:
    On Thu, Sep 01, 2011 at 03:56:57PM -0400, Daniel Convissor wrote:

    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
  • Tjerk Meesters at Aug 31, 2011 at 11:48 am

    On Aug 31, 2011 12:14 PM, "Rasmus Lerdorf" 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=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

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Laruence at Aug 31, 2011 at 7:53 am
    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

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php


    --
    Laruence  Xinchen Hui
    http://www.laruence.com/
  • Stas Malyshev at Aug 31, 2011 at 7:56 am
    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
  • Christian Stocker at Aug 31, 2011 at 9:39 am

    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=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
  • Christian Stocker at Aug 31, 2011 at 10:00 am
    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=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 at Aug 31, 2011 at 10:25 am
    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
    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=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


    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php


    --
    Laruence  Xinchen Hui
    http://www.laruence.com/
  • Christian Stocker at Aug 31, 2011 at 10:58 am

    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.stocker@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=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


    --
    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
  • Ilia Alshanetsky at Aug 31, 2011 at 11:32 am
    Revert sounds find to me, the change was indeed to fix the test.

    On Wed, Aug 31, 2011 at 6:58 AM, Christian Stocker
    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.stocker@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=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


    --
    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
  • Christian Stocker at Aug 31, 2011 at 11:45 am

    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
    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.stocker@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=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


    --
    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
  • Rob Richards at Aug 31, 2011 at 11:41 am

    On Aug 31, 2011, at 5:39 AM, 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=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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupphp-internals @
categoriesphp
postedAug 31, '11 at 3:39a
activeSep 2, '11 at 1:41p
posts26
users11
websitephp.net

People

Translate

site design / logo © 2022 Grokbase