Re: [PHP-DEV] 5.4 beta
Hi! On 8/28/11 10:55 PM, Gustavo Lopes wrote: I should ask someone with Zend karma to commit the closure rebinding patch. Context: https://wiki.php.net/rfc/closures/object-extension#privateprotected_members_scope Vote: https://wiki.php.net/todo/php54/vote Done. -- 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: [SPAM?]: Re: [PHP-DEV] Make mysqlnd default over libmysql in 5.4
Hi, On 09/07/2011 07:17 AM, Tomas Kuliavas wrote: 2011.09.06 23:20 Ulf Wendel rašė: Am 06.09.2011 21:33, schrieb Stas Malyshev: Hi! Any new PHP major release is about setting new directions. I, Andrey and Johannes, the guys maintaining ext/*mysql* recommend going mysqlnd after an "incubation" of some four years (5.3x series + dev time). My concern was also that making mysqlnd the default would make libmysql support considered secondary and unimportant. As I was assured it is not the case and the differences between mysqlnd and libmysql flavors seem to be rectified or in the process of being rectified, and I heard no objections for this as a default, I'm OK with it now. Jippie! Removing libmysql support would be crazy. Not only from a PHP perspective but also from a MySQL one. For PHP it is a must-have fallback option. For MySQL the PHP stuff is a nice libmysql test drive. Not a welcome job among the mysqlnd fan boys, as you noticed. But then, sometimes we count mysqlnd vs. libmysql issues... Bouncing bug reports (https://bugs.php.net/bug.php?id=55001) that are not reproducible on setup with mysqlnd when user reports about issue with libmysql is not the way bugs are solved. mysqlnd is not authoritative source for mysql extension behavior. libmysql is. That bug report shows semantics differences Stas was talking about and bug status shows the way you are handling it. If libmysql semantics change between versions, indicate that in bug report instead refusing to solve the problem with 'mysqlnd works fine' The specific case you are talking about is a bug in libmysql. Seems like a very old one as it has been reproduced with a vast range of versions. What Ulf tells you is that you might want to consider mysqlnd, as it had exposed less bugs than libmysql did so far and crashes less in some weirdo cases, than libmysql does. And we talk about libmysql, not the extensions than wrap it. The interface to libmysql won't die, we will support it but be sure that mysqlnd will be better because it is and will be engineered towards the needs of PHP and not like libmysql towards the needs of everyone but the aliens. I hope that even the hardcore supporters for mysqlX@libmysql will some day realize that waiting for a libmysql fix in a mission critical environment will cost them (in time and hence money) a lot more than waiting for the proper mysqlnd fix (applying a patch from svn). Best, Andrey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Compiling warnings should be fixed
Hi Laruence, I fully agree, the amount of warnings is way too big and only seeing the delta between two builds is useful right now. Btw, if you have patches for Zend, please send them over so we can review and test them :) Cheers, On Wed, Sep 7, 2011 at 3:15 AM, Laruence wrote: > Hi: > there is a lot of compiling warnings in truk(branch also), I have > fixed most of them unless those in Zend/* > here is the warning log: http://pastebin.com/ah3qtP6A (compile with > > I think it is better to fix them all, since we should release a > perfect project(although most of them are no issue) > > of course I can do it, but need a zend karma. > > thanks > > -- > Laruence Xinchen Hui > http://www.laruence.com/ > -- 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] CI for 5.4
hi Stas, A new box is being setup with numerous VMs (Dan is on it). Each of of them will cover one supported platform (debian, rh, bsd, win) and will run the builds and tests using rmtools in controlled environment, like what I began to do with windows a while back already. Build and tests log will be available more than daily (will see how fast the tests can be run, but 3-4x daily if necessary should be possible). Code coverage won't be available for all run tho', as it slow down the process and it is not necessary on each revision or change :) Cheers, On Wed, Sep 7, 2011 at 3:29 AM, Stas Malyshev wrote: > Hi! > > Since we started to pay real attention to our unit tests now, I wonder if we > could set up some kind of frequently-running CI system that could be used to > screen commits and identify breakage early? That'd help with 5.4 process I > think. > We have http://gcov.php.net/ but it doesn't run with the frequency I'd like > and since it says the run takes 44 hours it's kind of understandable. So I > wonder if we could have something that just builds it and runs unit tests > and we could see it in the same format as on gcov? Ideally after each commit > would be nice, but say once an hour or two (even fullest unit tests run > should take more than that, I think) would be OK too. If we could have two > of them, like Linux & Windows, it'd be even better, but at least one would > be nice. > What do you think? > -- > 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 > > -- 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: [SPAM?]: Re: [PHP-DEV] Make mysqlnd default over libmysql in 5.4
2011.09.06 23:20 Ulf Wendel rašė: > Am 06.09.2011 21:33, schrieb Stas Malyshev: >> Hi! >> >>> Any new PHP major release is about setting new directions. I, Andrey >>> and >>> Johannes, the guys maintaining ext/*mysql* recommend going mysqlnd >>> after >>> an "incubation" of some four years (5.3x series + dev time). >> >> My concern was also that making mysqlnd the default would make libmysql >> support considered secondary and unimportant. As I was assured it is not >> the case and the differences between mysqlnd and libmysql flavors seem >> to be rectified or in the process of being rectified, and I heard no >> objections for this as a default, I'm OK with it now. > > Jippie! > > Removing libmysql support would be crazy. Not only from a PHP > perspective but also from a MySQL one. For PHP it is a must-have > fallback option. For MySQL the PHP stuff is a nice libmysql test drive. > Not a welcome job among the mysqlnd fan boys, as you noticed. But then, > sometimes we count mysqlnd vs. libmysql issues... Bouncing bug reports (https://bugs.php.net/bug.php?id=55001) that are not reproducible on setup with mysqlnd when user reports about issue with libmysql is not the way bugs are solved. mysqlnd is not authoritative source for mysql extension behavior. libmysql is. That bug report shows semantics differences Stas was talking about and bug status shows the way you are handling it. If libmysql semantics change between versions, indicate that in bug report instead refusing to solve the problem with 'mysqlnd works fine' -- Tomas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CI for 5.4
On Wed, Sep 7, 2011 at 3:29 AM, Stas Malyshev wrote: > Hi! > > Since we started to pay real attention to our unit tests now, I wonder if we > could set up some kind of frequently-running CI system that could be used to > screen commits and identify breakage early? That'd help with 5.4 process I > think. > We have http://gcov.php.net/ but it doesn't run with the frequency I'd like > and since it says the run takes 44 hours it's kind of understandable. So I > wonder if we could have something that just builds it and runs unit tests > and we could see it in the same format as on gcov? Ideally after each commit > would be nice, but say once an hour or two (even fullest unit tests run > should take more than that, I think) would be OK too. If we could have two > of them, like Linux & Windows, it'd be even better, but at least one would > be nice. > What do you think? > -- > 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 > > Hi, I also support the idea. I would suggest setting up a jenkins(ex-hudson) cluster, it is the leading CI product on the market (and a really successful open source project), and it is really well-known in the php community as well, and because I have used for my other projects in the past(not just for php, but for some C apps also). Jenkins supports having multiple slave instances running on different platforms, nicely bound together, so you only access the master instance through your browser, but the builds itself can be off-loaded to the slaves ( https://wiki.jenkins-ci.org/display/JENKINS/Distributed+builds ). I would be happy to help setting it up. -- 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] CI for 5.4
+1 thanks 2011/9/7 Stas Malyshev : > Hi! > > Since we started to pay real attention to our unit tests now, I wonder if we > could set up some kind of frequently-running CI system that could be used to > screen commits and identify breakage early? That'd help with 5.4 process I > think. > We have http://gcov.php.net/ but it doesn't run with the frequency I'd like > and since it says the run takes 44 hours it's kind of understandable. So I > wonder if we could have something that just builds it and runs unit tests > and we could see it in the same format as on gcov? Ideally after each commit > would be nice, but say once an hour or two (even fullest unit tests run > should take more than that, I think) would be OK too. If we could have two > of them, like Linux & Windows, it'd be even better, but at least one would > be nice. > What do you think? > -- > 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
[PHP-DEV] CI for 5.4
Hi! Since we started to pay real attention to our unit tests now, I wonder if we could set up some kind of frequently-running CI system that could be used to screen commits and identify breakage early? That'd help with 5.4 process I think. We have http://gcov.php.net/ but it doesn't run with the frequency I'd like and since it says the run takes 44 hours it's kind of understandable. So I wonder if we could have something that just builds it and runs unit tests and we could see it in the same format as on gcov? Ideally after each commit would be nice, but say once an hour or two (even fullest unit tests run should take more than that, I think) would be OK too. If we could have two of them, like Linux & Windows, it'd be even better, but at least one would be nice. What do you think? -- 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] Compiling warnings should be fixed
Hi: there is a lot of compiling warnings in truk(branch also), I have fixed most of them unless those in Zend/* here is the warning log: http://pastebin.com/ah3qtP6A (compile with I think it is better to fix them all, since we should release a perfect project(although most of them are no issue) of course I can do it, but need a zend karma. thanks -- 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] zlib issues in 5.4 and trunk
Hi: ext/zlib/tests/gzencode_variation1.phpt failed in Linux(redhat 64-bit) test log http://pastebin.com/TzpW8GTK thanks 2011/9/6 Pierre Joye : > hi, > > It seems that 5.4 and trunk has something broken in zlib and maybe > bas64 encoding/decoding. > > We have a serie of tests failing on linux or windows: > > ext\zlib\tests\bug_52944.phpt > ext\zlib\tests\gzcompress_basic1.phpt > ext\zlib\tests\gzcompress_variation1.phpt > ext\zlib\tests\gzdeflate_basic1.phpt > ext\zlib\tests\gzdeflate_variation1.phpt > ext\zlib\tests\gzencode_basic1.phpt > ext\zlib\tests\gzencode_variation1-win32.phpt (the unix version too) > ext\zlib\tests\gzfile_basic.phpt > ext\zlib\tests\gzfile_basic2.phpt > \tests\gzfilegzreadfile.phpt > ext\zlib\tests\gzuncompress_basic1.phpt > ext\zlib\tests\readgzfile_basic.phpt > ext\zlib\tests\readgzfile_basic2.phpt > > cheers, > -- > 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 > > -- 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] [VOTE] Weak References
Hi, On Sat, Sep 3, 2011 at 19:21, Nicolas Grekas wrote: > > > > $pseudoWeakMap = array(); > > $pseudoWeakMap[spl_object_**hash($obj)] = new WeakReference($obj); > > > > or did I misunderstand the concept? I hope I'll have a chance to use > > WeakReferences soon in my project;) > > > > I also believe that this is the logic, but from the doc, when an object is > destroyed, its hash may be reused for other objects. > So this implementation could possibly have bad side effect, isn't it ? > > Nicolas > I don't understand how the code you just gave would be useful in practice? I've implemented a WeakMap class in the weakref pecl ext, see: http://svn.php.net/viewvc/pecl/weakref/trunk/tests/weakmap_001.phpt?revision=316293&view=markup for an example of usage. I believe this better fit people's needs. Or did you have something else in mind? Best, -- Etienne Kneuss http://www.colder.ch
Re: [PHP-DEV] zlib issues in 5.4 and trunk
On Wed, Sep 7, 2011 at 1:26 AM, Hannes Magnusson wrote: > On Tue, Sep 6, 2011 at 21:09, Pierre Joye wrote: >> On Tue, Sep 6, 2011 at 9:03 PM, Stas Malyshev wrote: >>> Hi! >>> >>> On 9/6/11 11:35 AM, Pierre Joye wrote: Yes, we use the same libs for 5.3 and 5.4 and same tests pass in 5.3. Bu it is also reproducible on many unrelated hosts. >>> >>> Well, maybe somebody that could reproduce it could look into it? Because I'm >>> unable to reproduce any of it... >> >> Really? three linux (ubuntu latest and debian 5/6 here) as well on windows. >> > > What is "Ubuntu latest"? is that 11.04 or the current beta? > I'm running Ubuntu 11.04, and none of these fail for me. > Two skipped (win only), and one expected to fail due to bug #47178 it seems. > > Please be a darling and post the diff so we can have something to look > at. Maybe seeing the output could jumpstart someones memory and help > you debug it. > > -Hannes > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > those tests passes on my debian squeeze(amd64) tyrael@phpize:~/checkouts/php-src/trunk$ TEST_PHP_EXECUTABLE=sapi/cli/php sapi/cli/php run-tests.php -g SKIP,XFAIL,FAIL -n -c tmp-php.ini ext/zlib/ = PHP : sapi/cli/php PHP_SAPI: cli PHP_VERSION : 5.5.0-dev ZEND_VERSION: 2.4.0 PHP_OS : Linux - Linux phpize 2.6.32-5-amd64 #1 SMP Tue Jun 14 09:42:28 UTC 2011 x86_64 INI actual : /home/tyrael/checkouts/php-src/trunk More .INIs : CWD : /home/tyrael/checkouts/php-src/trunk Extra dirs : VALGRIND: Not used = Running selected tests. SKIP Test gzencode() function : variation [ext/zlib/tests/gzencode_variation1-win32.phpt] reason: only for Windows SKIP Test gzencode() function : variation - verify header contents with all encoding modes [ext/zlib/tests/gzencode_variation2-win32.phpt] reason: .. only for Windows XFAIL Test gzencode() function : variation - verify header contents with all encoding modes [ext/zlib/tests/gzencode_variation2.phpt] XFAIL REASON: Test will fail until bug #47178 resolved; missing gzip headers when FORCE_DEFLATE specified = Number of tests : 146 144 Tests skipped :2 ( 1.4%) Tests warned:0 ( 0.0%) ( 0.0%) Tests failed:0 ( 0.0%) ( 0.0%) Expected fail :1 ( 0.7%) ( 0.7%) Tests passed: 143 ( 97.9%) ( 99.3%) - Time taken : 10 seconds = = EXPECTED FAILED TEST SUMMARY - Test gzencode() function : variation - verify header contents with all encoding modes [ext/zlib/tests/gzencode_variation2.phpt] XFAIL REASON: Test will fail until bug #47178 resolved; missing gzip headers when FORCE_DEFLATE specified = -- 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] zlib issues in 5.4 and trunk
On Tue, Sep 6, 2011 at 21:09, Pierre Joye wrote: > On Tue, Sep 6, 2011 at 9:03 PM, Stas Malyshev wrote: >> Hi! >> >> On 9/6/11 11:35 AM, Pierre Joye wrote: >>> >>> Yes, we use the same libs for 5.3 and 5.4 and same tests pass in 5.3. >>> Bu it is also reproducible on many unrelated hosts. >> >> Well, maybe somebody that could reproduce it could look into it? Because I'm >> unable to reproduce any of it... > > Really? three linux (ubuntu latest and debian 5/6 here) as well on windows. > What is "Ubuntu latest"? is that 11.04 or the current beta? I'm running Ubuntu 11.04, and none of these fail for me. Two skipped (win only), and one expected to fail due to bug #47178 it seems. Please be a darling and post the diff so we can have something to look at. Maybe seeing the output could jumpstart someones memory and help you debug it. -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [SPAM?]: Re: [PHP-DEV] Make mysqlnd default over libmysql in 5.4
Am 06.09.2011 21:33, schrieb Stas Malyshev: Hi! Any new PHP major release is about setting new directions. I, Andrey and Johannes, the guys maintaining ext/*mysql* recommend going mysqlnd after an "incubation" of some four years (5.3x series + dev time). My concern was also that making mysqlnd the default would make libmysql support considered secondary and unimportant. As I was assured it is not the case and the differences between mysqlnd and libmysql flavors seem to be rectified or in the process of being rectified, and I heard no objections for this as a default, I'm OK with it now. Jippie! Removing libmysql support would be crazy. Not only from a PHP perspective but also from a MySQL one. For PHP it is a must-have fallback option. For MySQL the PHP stuff is a nice libmysql test drive. Not a welcome job among the mysqlnd fan boys, as you noticed. But then, sometimes we count mysqlnd vs. libmysql issues... Ulf -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/ branches/PHP_5_4/ext/mysqli/tests/bug55582.phpt trunk/ext/mysqli/tests/bug55582.phpt
On 09/06/2011 09:54 PM, Andrey Hristov wrote: On 09/06/2011 09:08 PM, Stas Malyshev wrote: Hi! On 9/6/11 11:05 AM, Andrey Hristov wrote: I've looked into mysqli_result_is_unbuffered_and_not_everything_is_fetched() and it looks like for libmysql it checks this: (((r)->handle&& (r)->handle->status == MYSQL_STATUS_USE_RESULT) || ((r)->data == NULL)) When I step through your code, r->data (which is result->data) is always NULL for me, which means warning is generated and 0 is returned. Is it a problem in libmysql? r->data should be always NULL, for an unbuffered fetch, r->data holds the data for buffered result sets. It is additional protection, an If r->data is always null, then - please look at the code above - mysqli_result_is_unbuffered_and_not_everything_is_fetched() is always true. Which I think is not what was intended, because the test implies otherwise, but maybe I am mistaken. That's what I am trying to find out - is this behavior of libmysql/mysqli implementation, that always returns 0 and produces an error for "use" results for num_rows - intentional or is it some kind of error. assert. I don't see a problem with that. I don't see also the behavior you describe - 0 returned even after the last fetch. If all data is fetched r->handle->status will be no more MYSQL_STATUS_USE_RESULT but something else (MYSQL_STATUS_READY), this will signal, that everything has been fetched. Of course, the check could have been !res->eof, but This is true, however if you look at the condition, it returns true always when r->data us NULL regardless of what is there in the status. What I am trying to find out is if this behavior is intended - and then the test is wrong for this situation - or is it not intended and needs to be fixed. Good catch. I just fixed it in svn. There is one more remaining issue. mysqli_num_rows() returns different value than mysqli::num_rows due to the way properties are implemented - most properties call directly the underlying function. In this case for libmysql there is difference. mysqli@ should deliver the expected 0 when !EOF. I mean mysqli@mysqlnd Andrey Andrey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/ branches/PHP_5_4/ext/mysqli/tests/bug55582.phpt trunk/ext/mysqli/tests/bug55582.phpt
On 09/06/2011 09:08 PM, Stas Malyshev wrote: Hi! On 9/6/11 11:05 AM, Andrey Hristov wrote: I've looked into mysqli_result_is_unbuffered_and_not_everything_is_fetched() and it looks like for libmysql it checks this: (((r)->handle&& (r)->handle->status == MYSQL_STATUS_USE_RESULT) || ((r)->data == NULL)) When I step through your code, r->data (which is result->data) is always NULL for me, which means warning is generated and 0 is returned. Is it a problem in libmysql? r->data should be always NULL, for an unbuffered fetch, r->data holds the data for buffered result sets. It is additional protection, an If r->data is always null, then - please look at the code above - mysqli_result_is_unbuffered_and_not_everything_is_fetched() is always true. Which I think is not what was intended, because the test implies otherwise, but maybe I am mistaken. That's what I am trying to find out - is this behavior of libmysql/mysqli implementation, that always returns 0 and produces an error for "use" results for num_rows - intentional or is it some kind of error. assert. I don't see a problem with that. I don't see also the behavior you describe - 0 returned even after the last fetch. If all data is fetched r->handle->status will be no more MYSQL_STATUS_USE_RESULT but something else (MYSQL_STATUS_READY), this will signal, that everything has been fetched. Of course, the check could have been !res->eof, but This is true, however if you look at the condition, it returns true always when r->data us NULL regardless of what is there in the status. What I am trying to find out is if this behavior is intended - and then the test is wrong for this situation - or is it not intended and needs to be fixed. Good catch. I just fixed it in svn. There is one more remaining issue. mysqli_num_rows() returns different value than mysqli::num_rows due to the way properties are implemented - most properties call directly the underlying function. In this case for libmysql there is difference. mysqli@ should deliver the expected 0 when !EOF. Andrey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Make mysqlnd default over libmysql in 5.4
Hi! Any new PHP major release is about setting new directions. I, Andrey and Johannes, the guys maintaining ext/*mysql* recommend going mysqlnd after an "incubation" of some four years (5.3x series + dev time). My concern was also that making mysqlnd the default would make libmysql support considered secondary and unimportant. As I was assured it is not the case and the differences between mysqlnd and libmysql flavors seem to be rectified or in the process of being rectified, and I heard no objections for this as a default, I'm OK with it now. -- 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] zlib issues in 5.4 and trunk
On Tue, Sep 6, 2011 at 9:03 PM, Stas Malyshev wrote: > Hi! > > On 9/6/11 11:35 AM, Pierre Joye wrote: >> >> Yes, we use the same libs for 5.3 and 5.4 and same tests pass in 5.3. >> Bu it is also reproducible on many unrelated hosts. > > Well, maybe somebody that could reproduce it could look into it? Because I'm > unable to reproduce any of it... Really? three linux (ubuntu latest and debian 5/6 here) as well on windows. -- 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] Re: [PHP-CVS] svn: /php/php-src/ branches/PHP_5_4/ext/mysqli/tests/bug55582.phpt trunk/ext/mysqli/tests/bug55582.phpt
Hi! On 9/6/11 11:05 AM, Andrey Hristov wrote: I've looked into mysqli_result_is_unbuffered_and_not_everything_is_fetched() and it looks like for libmysql it checks this: (((r)->handle&& (r)->handle->status == MYSQL_STATUS_USE_RESULT) || ((r)->data == NULL)) When I step through your code, r->data (which is result->data) is always NULL for me, which means warning is generated and 0 is returned. Is it a problem in libmysql? r->data should be always NULL, for an unbuffered fetch, r->data holds the data for buffered result sets. It is additional protection, an If r->data is always null, then - please look at the code above - mysqli_result_is_unbuffered_and_not_everything_is_fetched() is always true. Which I think is not what was intended, because the test implies otherwise, but maybe I am mistaken. That's what I am trying to find out - is this behavior of libmysql/mysqli implementation, that always returns 0 and produces an error for "use" results for num_rows - intentional or is it some kind of error. assert. I don't see a problem with that. I don't see also the behavior you describe - 0 returned even after the last fetch. If all data is fetched r->handle->status will be no more MYSQL_STATUS_USE_RESULT but something else (MYSQL_STATUS_READY), this will signal, that everything has been fetched. Of course, the check could have been !res->eof, but This is true, however if you look at the condition, it returns true always when r->data us NULL regardless of what is there in the status. What I am trying to find out is if this behavior is intended - and then the test is wrong for this situation - or is it not intended and needs to be fixed. -- 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] zlib issues in 5.4 and trunk
Hi! On 9/6/11 11:35 AM, Pierre Joye wrote: Yes, we use the same libs for 5.3 and 5.4 and same tests pass in 5.3. Bu it is also reproducible on many unrelated hosts. Well, maybe somebody that could reproduce it could look into it? Because I'm unable to reproduce any of it... -- 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] zlib issues in 5.4 and trunk
On Tue, Sep 6, 2011 at 8:03 PM, Stas Malyshev wrote: > Hmm... Kind of hard to go on "from time to time" - are you sure there's no > build/old library issue? Do we have a reproduction for the segfaults? The > diffs look like your gzip is producing different data - I wonder if some > version might be doing something slightly different. Yes, we use the same libs for 5.3 and 5.4 and same tests pass in 5.3. Bu it is also reproducible on many unrelated hosts. Laruence will be back tomorrow, I will ask him to provide his diffs too (and some bt) -- 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] Re: [PHP-CVS] svn: /php/php-src/ branches/PHP_5_4/ext/mysqli/tests/bug55582.phpt trunk/ext/mysqli/tests/bug55582.phpt
Stas, On 09/06/2011 06:55 PM, Stas Malyshev wrote: Hi! On 9/6/11 2:46 AM, Andrey Hristov wrote: I've looked into mysqli_result_is_unbuffered_and_not_everything_is_fetched() and it looks like for libmysql it checks this: (((r)->handle&& (r)->handle->status == MYSQL_STATUS_USE_RESULT) || ((r)->data == NULL)) When I step through your code, r->data (which is result->data) is always NULL for me, which means warning is generated and 0 is returned. Is it a problem in libmysql? what kind of a Problem? Please read above. The above says php with libmysql does not return the result the tests expects - instead of returning number of rows after the last fetch it still returns 0. While mysqlnd does not return 0. I would like to know what is causing this and why php+libmysql result is different from what your test expects. r->data should be always NULL, for an unbuffered fetch, r->data holds the data for buffered result sets. It is additional protection, an assert. I don't see a problem with that. I don't see also the behavior you describe - 0 returned even after the last fetch. If all data is fetched r->handle->status will be no more MYSQL_STATUS_USE_RESULT but something else (MYSQL_STATUS_READY), this will signal, that everything has been fetched. Of course, the check could have been !res->eof, but this is not what Georg chose long ago (see 5_2) : if (result->handle && result->handle->status == MYSQL_STATUS_USE_RESULT) { On my box the test passes both with libmysql and mysqlnd. What I did was to create consistent behavior, something people expect, although libmysql returns something different, which was mysqlnd's behavior in the beginning too. Andrey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] zlib issues in 5.4 and trunk
Hi! On 9/6/11 10:05 AM, Pierre Joye wrote: here you go (from win) It fails variously on linux or windows. Laruence reproduces the fails on linux too, some segfault from time to time. Hmm... Kind of hard to go on "from time to time" - are you sure there's no build/old library issue? Do we have a reproduction for the segfaults? The diffs look like your gzip is producing different data - I wonder if some version might be doing something slightly different. -- 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] Borked SKIPIFs (PHP_5_4)
On Tue, Sep 6, 2011 at 6:53 PM, Ulf Wendel wrote: > Hi Pierre, hi all, > > those three should be left: > > BORK 8514/9248 [ext/standard/tests/strings/sha1_file.phpt] > BORK 8443/9248 [ext/standard/tests/strings/md5_file.phpt] those are fixed already :) > BORK 7328/9248 [ext/standard/tests/file/php_fd_wrapper_04.phpt] > > They might take more than 1 second (verbally) to fix. Leaving to someone > else to have a 30 seconds look... ;-) > > Ulf > > -- > 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] zlib issues in 5.4 and trunk
Hi! On 9/6/11 8:59 AM, Pierre Joye wrote: hi, It seems that 5.4 and trunk has something broken in zlib and maybe bas64 encoding/decoding. We have a serie of tests failing on linux or windows: Interestingly enough, none of these fail for me on Darwin. Could you publish the diffs? -- 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] Re: [PHP-CVS] svn: /php/php-src/ branches/PHP_5_4/ext/mysqli/tests/bug55582.phpt trunk/ext/mysqli/tests/bug55582.phpt
Hi! On 9/6/11 2:46 AM, Andrey Hristov wrote: I've looked into mysqli_result_is_unbuffered_and_not_everything_is_fetched() and it looks like for libmysql it checks this: (((r)->handle&& (r)->handle->status == MYSQL_STATUS_USE_RESULT) || ((r)->data == NULL)) When I step through your code, r->data (which is result->data) is always NULL for me, which means warning is generated and 0 is returned. Is it a problem in libmysql? what kind of a Problem? Please read above. The above says php with libmysql does not return the result the tests expects - instead of returning number of rows after the last fetch it still returns 0. While mysqlnd does not return 0. I would like to know what is causing this and why php+libmysql result is different from what your test expects. -- 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] Borked SKIPIFs (PHP_5_4)
Hi Pierre, hi all, those three should be left: BORK 8514/9248 [ext/standard/tests/strings/sha1_file.phpt] BORK 8443/9248 [ext/standard/tests/strings/md5_file.phpt] BORK 7328/9248 [ext/standard/tests/file/php_fd_wrapper_04.phpt] They might take more than 1 second (verbally) to fix. Leaving to someone else to have a 30 seconds look... ;-) Ulf -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Borked SKIPIFs (PHP_5_4)
hi Ulf, I fixed two. Feel free to fix the other as well if you have time. On Tue, Sep 6, 2011 at 4:40 PM, Ulf Wendel wrote: > Hi, > > annoyed by run-tests.php ignoring borked SKIPIF sections, I hacked it to > bail out at me if something seemed suspicious. Maintainers may want to have > a look at: > > Fatal/Parse error @ SKIPIF = SKIPIF non functional > > BORK 883/9126 [Zend/tests/bug31683.phpt] > BORK 4037/9248 [ext/phar/tests/fopen_edgecases2.phpt > BORK 8443/9248 [ext/standard/tests/strings/md5_file.phpt] > BORK 8514/9248 [ext/standard/tests/strings/sha1_file.phpt] > > Warnings/Notices @ SKIPIF = SKIPIF should work fine > > BORK 4451/9248 [ext/posix/tests/posix_getpgid_error.phpt] > BORK 4452/9248 [ext/posix/test/posix_getpgid_variation.phpt] > BORK 4865/9248 [ext/session/test/rfc1867_invalid_settings.phpt] > BORK 7328/9248 [ext/standard/tests/file/php_fd_wrapper_04.phpt] > > My PHP was built with pretty much nothing but MySQL stuff enabled. A fair > number of tests has probably been skipped. > > The run-tests.php hack I used is not worth sharing. All I did was check if > SKIPIF returns any output after removal of "-d display_errors=0". In other > words I made the assumption that SKIPIF sections must not output anything > but "skip " or the like, which causes false positives. > > Ulf > > > > > > Details: > > > BORK 883/9126 [Zend/tests/bug31683.phpt] > > Warning: require_once(skipif.inc): failed to open stream: No such file or > directory in > /home/nixnutz/php/php-src/branches/PHP_5_4/Zend/tests/bug31683.skip.php on > line 1 > Fatal error: require_once(): Failed opening required 'skipif.inc' > (include_path='.:/usr/local/lib/php') in > /home/nixnutz/php/php-src/branches/PHP_5_4/Zend/tests/bug31683.skip.php on > line 1 > > > BORK 4037/9248 [ext/phar/tests/fopen_edgecases2.phpt > > Fatal error: Call to undefined function php_version() in > /home/nixnutz/php/php-src/branches/PHP_5_4/ext/phar/tests/fopen_edgecases2.skip.php > on line 2 > > > BORK 4451/9248 [ext/posix/tests/posix_getpgid_error.phpt] > > Notice: Use of undefined constant posix_getpgid - assumed 'posix_getpgid' in > /home/nixnutz/php/php-src/branches/PHP_5_4/ext/posix/tests/posix_getpgid_error.skip.php > on line 2 > [] ext/posix/tests/posix_getpgid_error.phpt > > > BORK 4452/9248 [ext/posix/test/posix_getpgid_variation.phpt] > > Notice: Use of undefined constant posix_getpgid - assumed 'posix_getpgid' in > /home/nixnutz/php/php-src/branches/PHP_5_4/ext/posix/tests/posix_getpgid_variation.skip.php > on line 2 > > > BORK 4865/9248 [ext/session/test/rfc1867_invalid_settings.phpt] > > Warning: PHP Startup: session.upload_progress.freq must be greater than or > equal to zero in Unknown on line 0 > > > BORK 4866/9248 [ext/session/tests/rfc1867_invalid_settings_2.phpt] > > Warning: PHP Startup: session.upload_progress.freq cannot be over 100% in > Unknown on line 0 > > > BORK 7328/9248 [ext/standard/tests/file/php_fd_wrapper_04.phpt] > > Warning: include(skipif.inc): failed to open stream: No such file or > directory in > /home/nixnutz/php/php-src/branches/PHP_5_4/ext/standard/tests/file/php_fd_wrapper_04.skip.php > on line 1 > > > Warning: include(): Failed opening 'skipif.inc' for inclusion > (include_path='.:/usr/local/lib/php') in > /home/nixnutz/php/php-src/branches/PHP_5_4/ext/standard/tests/file/php_fd_wrapper_04.skip.php > in line 1 > > > BORK 8443/9248 [ext/standard/tests/strings/md5_file.phpt] > > Parse error: syntax error, unexpected '!', expecting '(' in > /home/nixnutz/php/php-src/branches/PHP_5_4/ext/standard/tests/strings/md5_file.skip.php > on line 6 > > > BORK 8514/9248 [ext/standard/tests/strings/sha1_file.phpt] > > Parse error: syntax error, unexpected '!', expecting '(' in > /home/nixnutz/php/php-src/branches/PHP_5_4/ext/standard/tests/strings/sha1_file.skip.php > on line 6 > > -- > 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
[PHP-DEV] zlib issues in 5.4 and trunk
hi, It seems that 5.4 and trunk has something broken in zlib and maybe bas64 encoding/decoding. We have a serie of tests failing on linux or windows: ext\zlib\tests\bug_52944.phpt ext\zlib\tests\gzcompress_basic1.phpt ext\zlib\tests\gzcompress_variation1.phpt ext\zlib\tests\gzdeflate_basic1.phpt ext\zlib\tests\gzdeflate_variation1.phpt ext\zlib\tests\gzencode_basic1.phpt ext\zlib\tests\gzencode_variation1-win32.phpt (the unix version too) ext\zlib\tests\gzfile_basic.phpt ext\zlib\tests\gzfile_basic2.phpt \tests\gzfilegzreadfile.phpt ext\zlib\tests\gzuncompress_basic1.phpt ext\zlib\tests\readgzfile_basic.phpt ext\zlib\tests\readgzfile_basic2.phpt cheers, -- 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
[PHP-DEV] Borked SKIPIFs (PHP_5_4)
Hi, annoyed by run-tests.php ignoring borked SKIPIF sections, I hacked it to bail out at me if something seemed suspicious. Maintainers may want to have a look at: Fatal/Parse error @ SKIPIF = SKIPIF non functional BORK 883/9126 [Zend/tests/bug31683.phpt] BORK 4037/9248 [ext/phar/tests/fopen_edgecases2.phpt BORK 8443/9248 [ext/standard/tests/strings/md5_file.phpt] BORK 8514/9248 [ext/standard/tests/strings/sha1_file.phpt] Warnings/Notices @ SKIPIF = SKIPIF should work fine BORK 4451/9248 [ext/posix/tests/posix_getpgid_error.phpt] BORK 4452/9248 [ext/posix/test/posix_getpgid_variation.phpt] BORK 4865/9248 [ext/session/test/rfc1867_invalid_settings.phpt] BORK 7328/9248 [ext/standard/tests/file/php_fd_wrapper_04.phpt] My PHP was built with pretty much nothing but MySQL stuff enabled. A fair number of tests has probably been skipped. The run-tests.php hack I used is not worth sharing. All I did was check if SKIPIF returns any output after removal of "-d display_errors=0". In other words I made the assumption that SKIPIF sections must not output anything but "skip " or the like, which causes false positives. Ulf Details: BORK 883/9126 [Zend/tests/bug31683.phpt] Warning: require_once(skipif.inc): failed to open stream: No such file or directory in /home/nixnutz/php/php-src/branches/PHP_5_4/Zend/tests/bug31683.skip.php on line 1 Fatal error: require_once(): Failed opening required 'skipif.inc' (include_path='.:/usr/local/lib/php') in /home/nixnutz/php/php-src/branches/PHP_5_4/Zend/tests/bug31683.skip.php on line 1 BORK 4037/9248 [ext/phar/tests/fopen_edgecases2.phpt Fatal error: Call to undefined function php_version() in /home/nixnutz/php/php-src/branches/PHP_5_4/ext/phar/tests/fopen_edgecases2.skip.php on line 2 BORK 4451/9248 [ext/posix/tests/posix_getpgid_error.phpt] Notice: Use of undefined constant posix_getpgid - assumed 'posix_getpgid' in /home/nixnutz/php/php-src/branches/PHP_5_4/ext/posix/tests/posix_getpgid_error.skip.php on line 2 [] ext/posix/tests/posix_getpgid_error.phpt BORK 4452/9248 [ext/posix/test/posix_getpgid_variation.phpt] Notice: Use of undefined constant posix_getpgid - assumed 'posix_getpgid' in /home/nixnutz/php/php-src/branches/PHP_5_4/ext/posix/tests/posix_getpgid_variation.skip.php on line 2 BORK 4865/9248 [ext/session/test/rfc1867_invalid_settings.phpt] Warning: PHP Startup: session.upload_progress.freq must be greater than or equal to zero in Unknown on line 0 BORK 4866/9248 [ext/session/tests/rfc1867_invalid_settings_2.phpt] Warning: PHP Startup: session.upload_progress.freq cannot be over 100% in Unknown on line 0 BORK 7328/9248 [ext/standard/tests/file/php_fd_wrapper_04.phpt] Warning: include(skipif.inc): failed to open stream: No such file or directory in /home/nixnutz/php/php-src/branches/PHP_5_4/ext/standard/tests/file/php_fd_wrapper_04.skip.php on line 1 Warning: include(): Failed opening 'skipif.inc' for inclusion (include_path='.:/usr/local/lib/php') in /home/nixnutz/php/php-src/branches/PHP_5_4/ext/standard/tests/file/php_fd_wrapper_04.skip.php in line 1 BORK 8443/9248 [ext/standard/tests/strings/md5_file.phpt] Parse error: syntax error, unexpected '!', expecting '(' in /home/nixnutz/php/php-src/branches/PHP_5_4/ext/standard/tests/strings/md5_file.skip.php on line 6 BORK 8514/9248 [ext/standard/tests/strings/sha1_file.phpt] Parse error: syntax error, unexpected '!', expecting '(' in /home/nixnutz/php/php-src/branches/PHP_5_4/ext/standard/tests/strings/sha1_file.skip.php on line 6 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 答复: [PHP-DEV] full LFS support
AFAIK Pierre has some point about Windows part. 2011/9/6 Ferenc Kovacs : > On Tue, Aug 17, 2010 at 4:22 PM, Ferenc Kovacs wrote: >>> >>> > Hi. >>> > >>> > I would like to know what is the current status of the LFS support for >>> > php. >>> > >>> > http://bugs.php.net/bug.php?id=27792 >>> > http://bugs.php.net/bug.php?id=48886 >>> > >>> > As far as I can see, there are some patches floating around, but some of >>> > them doesn't work, some of them are incomplete. >>> > >>> > As far as I can see, with the latest release(5.3.3) you can't stat or >>> > filesize a file where the size is >= 2GiB on 32bit OS, and >= 4GiB on >>> > 64bit. >>> > Is this true? >>> > From the proposed patches, it seems that there arent that many LOC which >>> > needs to be adjusted to provide a decent LFS support. >>> > Are there any blocker objections or architectural problems, or we just >>> > lack specification or manpower to fix this issue? >>> > If this gets fixed, will this be included into the 5.3 branch, or this >>> > can only be added with the next major version? >>> > >>> > Tyrael >>> > >>> > >>> > -- >>> > PHP Internals - PHP Runtime Development Mailing List >>> > To unsubscribe, visit: http://www.php.net/unsub.php >>> > >>> > >> >> bump. >> Tyrael > > bump > (hoping that maybe laruence or Felipe takes a look) > > Tyrael > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- Regards, Felipe Pena -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 答复: [PHP-DEV] full LFS support
On Tue, Aug 17, 2010 at 4:22 PM, Ferenc Kovacs wrote: >> >> > Hi. >> > >> > I would like to know what is the current status of the LFS support for >> > php. >> > >> > http://bugs.php.net/bug.php?id=27792 >> > http://bugs.php.net/bug.php?id=48886 >> > >> > As far as I can see, there are some patches floating around, but some of >> > them doesn't work, some of them are incomplete. >> > >> > As far as I can see, with the latest release(5.3.3) you can't stat or >> > filesize a file where the size is >= 2GiB on 32bit OS, and >= 4GiB on >> > 64bit. >> > Is this true? >> > From the proposed patches, it seems that there arent that many LOC which >> > needs to be adjusted to provide a decent LFS support. >> > Are there any blocker objections or architectural problems, or we just >> > lack specification or manpower to fix this issue? >> > If this gets fixed, will this be included into the 5.3 branch, or this >> > can only be added with the next major version? >> > >> > Tyrael >> > >> > >> > -- >> > PHP Internals - PHP Runtime Development Mailing List >> > To unsubscribe, visit: http://www.php.net/unsub.php >> > >> > > > bump. > Tyrael bump (hoping that maybe laruence or Felipe takes a look) Tyrael -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Make mysqlnd default over libmysql in 5.4
Am 05.09.2011 11:08, schrieb Stas Malyshev: Hi! On 9/5/11 1:24 AM, Andrey Hristov wrote: the problem is that libmysql breaks, maybe more often than mysqlnd does. We rarely find bugs in mysqli, there are two codepaths in mysqli. If there is a bug in libmysql, what do you want: If we're dealing with libmysql bug, then I guess the expected thing would be to report it upstream, and make the comment in the test with bug ID. But in the cases I mentioned it does not look like libmysql bug as everything works just according to Mysql documentation, however the tests expect it to work differently. Stas, what are we going to do now after the discussion has calmed down a bit? Any new PHP major release is about setting new directions. I, Andrey and Johannes, the guys maintaining ext/*mysql* recommend going mysqlnd after an "incubation" of some four years (5.3x series + dev time). You, in your role as 5.4 RM, raised some concerns about changing the default to mysqlnd. Your primary concern is rolling out something that breaks PHP. As an example, you have listed some mysqli test failures. After the weekend, I'm a lazy bastard refusing to work during weekends, test failures have been commented on: - connect_oo_* - libmysql only, no BC [1] - explain_meta - libmysql can crash PHP, mysqlnd works [2] - stmt_num_rows - differences in undefined behaviour [3] - insert_id - as a bug, it would be bogussed, undefined [4] Your four examples stand up against, for example, Pierre "Windows" Joye. The php.net windows binaries are using mysqlnd as of PHP 5.3. Windows is probaly the biggest individual distribution. Pierre, who is no MySQL fan boy, reports no BC issues. This is based on multiple years of php.net Windows users feedback and his continous integration testing using "drupal 6&7, wp, oscommerce, mediawiki, sugarcrm, etc." [5]. At least on Windows, users do expect to see mysqlnd meanwhile. Harald Reindl did the switch from libmysql to mysqlnd on "hundret domains" with "no single problem" [6]. OpenSuSE did the same. As a manager, you often have to make a decision without knowing all details, without checking everything yourself. You have named and set the #1 risk (BC) and heard people's opinion: mysqlnd is not flawless, but well worth a try. You also raised the question how or if a change will impact packagers. Tomas Kuliavas gave some great input on this [7]: SuSE: --with-mysql=shared,mysqlnd Debian, Mandriva and Fedora: --with-mysql=shared,/usr --with-mysqli=shared,/usr/bin/mysql_config' Looks like packages explicitly set config options. Thus, no break provoked if changing defaults. There's a bit of a buzz on shared builds, Johannes is working on that one - https://bugs.php.net/bug.php?id=55609 . IMHO all of the relevant concerns have been adressed. No high risks have been found. There is nothing in the way that cannot be tackled down as one moves forward. I see no reason for ignoring the vote of the maintainers. I fail to understand why PHP @ *nix should not catch up to Windows. Ulf [1] http://news.php.net/php.internals/55226 [2] http://news.php.net/php.internals/55221 [3] http://news.php.net/php.internals/55210 [4] http://news.php.net/php.internals/55228 [5] http://news.php.net/php.internals/55177 [6] http://news.php.net/php.internals/55174 [7] http://news.php.net/php.internals/55142 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/ branches/PHP_5_4/ext/mysqli/tests/bug55582.phpt trunk/ext/mysqli/tests/bug55582.phpt
On 09/06/2011 11:16 AM, Stas Malyshev wrote: Hi! Have you actually checked what libmysql returns??!? If _you_ just have tried to do it, you might actually find that libmysql does what mysqlnd did long ago, but mysqli was hiding it. Here is output from what libmysql does, after removing the following check from mysqli_api.c: I checked what my build of PHP returns (which was build against libmysql) and it always returns 0. Now I want to understand why it happens - is it a bug in libmysql, in mysqli handling results or in something else? I've looked into mysqli_result_is_unbuffered_and_not_everything_is_fetched() and it looks like for libmysql it checks this: (((r)->handle && (r)->handle->status == MYSQL_STATUS_USE_RESULT) || ((r)->data == NULL)) When I step through your code, r->data (which is result->data) is always NULL for me, which means warning is generated and 0 is returned. Is it a problem in libmysql? what kind of a Problem? Andrey -- 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/mysqli/tests/bug55582.phpt trunk/ext/mysqli/tests/bug55582.phpt
Hi! Have you actually checked what libmysql returns??!? If _you_ just have tried to do it, you might actually find that libmysql does what mysqlnd did long ago, but mysqli was hiding it. Here is output from what libmysql does, after removing the following check from mysqli_api.c: I checked what my build of PHP returns (which was build against libmysql) and it always returns 0. Now I want to understand why it happens - is it a bug in libmysql, in mysqli handling results or in something else? I've looked into mysqli_result_is_unbuffered_and_not_everything_is_fetched() and it looks like for libmysql it checks this: (((r)->handle && (r)->handle->status == MYSQL_STATUS_USE_RESULT) || ((r)->data == NULL)) When I step through your code, r->data (which is result->data) is always NULL for me, which means warning is generated and 0 is returned. Is it a problem in libmysql? -- 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] Re: [PHP-CVS] svn: /php/php-src/ branches/PHP_5_4/ext/mysqli/tests/bug55582.phpt trunk/ext/mysqli/tests/bug55582.phpt
On 09/06/2011 10:45 AM, Stas Malyshev wrote: Hi! On 9/6/11 1:24 AM, Andrey Hristov wrote: no, it's about consistency, which you want. mysqlnd should behave like libmysql, and it is a test that can test it. What libmysql returns in filtered in mysqli, mysqli_num_rows() is a direct wrapper around mysql_num_rows(), and this is what we test. Sorry, I don't understand. mysqlnd returns non-zero number of rows after last fetch, libmysql does not, and that's what you test for. Are you saying it's a bug in libmysql or mysqli driver that it doesn't return that number? Have you actually checked what libmysql returns??!? If _you_ just have tried to do it, you might actually find that libmysql does what mysqlnd did long ago, but mysqli was hiding it. Here is output from what libmysql does, after removing the following check from mysqli_api.c: // if (mysqli_result_is_unbuffered_and_not_everything_is_fetched(result)) { // php_error_docref(NULL TSRMLS_CC, E_WARNING, "Function cannot be used with MYSQL_USE_RESULT"); // RETURN_LONG(0); // } Read and learn: - libmysql - andrey@poohie:/work/vanilla/php/php-src/branches/PHP_5_3$ ./php_libmysql -r '$c=mysqli_connect("127.0.0.1","root","root","test");$c->real_query("SELECT 42 FROM mysql.user LIMIT 2");$res=$c->use_result();printf("num_rows=%d\n", mysqli_num_rows($res)); var_dump($res->fetch_assoc()); printf("num_rows=%d\n", mysqli_num_rows($res)); var_dump($res->fetch_assoc()); printf("num_rows=%d\n", mysqli_num_rows($res)); var_dump($res->fetch_assoc()); printf("num_rows=%d\n", mysqli_num_rows($res));' num_rows=0 array(1) { [42]=> string(2) "42" } num_rows=1 array(1) { [42]=> string(2) "42" } num_rows=2 NULL num_rows=2 -- mysqlnd andrey@poohie:/work/vanilla/php/php-src/branches/PHP_5_3$ ./php_mysqlnd -r '$c=mysqli_connect("127.0.0.1","root","root","test");$c->real_query("SELECT 42 FROM mysql.user LIMIT 2");$res=$c->use_result();printf("num_rows=%d\n", mysqli_num_rows($res)); var_dump($res->fetch_assoc()); printf("num_rows=%d\n", mysqli_num_rows($res)); var_dump($res->fetch_assoc()); printf("num_rows=%d\n", mysqli_num_rows($res)); var_dump($res->fetch_assoc()); printf("num_rows=%d\n", mysqli_num_rows($res));' num_rows=0 array(1) { [42]=> string(2) "42" } num_rows=0 array(1) { [42]=> string(2) "42" } num_rows=0 NULL num_rows=2 --- As you can see, libmysql returns different numbers, it increments the number of rows. The used client library is 5.1.54, which is stock from Ubuntu 11.04 . Best, Andrey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php