Re: [PHP-DEV] Why does mysqlnd get included in Linux 'core' PHP5 packages?
Le 03/09/2011 14:42, Johannes Schlüter a écrit : > Now there is one consequence: If mysqlnd is used it will be built > statically in PHP, even on Unix, even if the other MySQL modules are > built shared. This can be fixed by adding a specific configuration > option to enforce mysqlnd being build as its own shared .so, too. This will be great. For RPM, php is build 1 time for each sapi (apache, cli, ...) but extension are only build once (well twice in we also build zts). This is ok with libmysql. If we want to switch to mysqlnd (for RPM), this will imply to build mysqlnd for each sapi (don't find a flag for this except also building mysql or mysqli extensions) and so provide various copy of the "static" library (in the various binaries). Having mysqlnd as a shared library will also allow to provides easily mysql/mysqli build with both mysqlnd and libmysql and give the final user the choice. Regards, Remi. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] New extension proposal: meta
Hi Flavius! I am working on PHP Parser in user land code (https://github.com/nikic/PHP-Parser), which currently has capabilities to parse PHP 5.3 into an AST and compile the nodes back to PHP source. >From my experience in building it, some notes: First, you seem to try to lex the PHP code yourself too. Why don't you use PHP's internal lexing capabilities? (Like token_get_all does.) PHP is a hard to lex language (with all it's special encapsed string and heredoc syntaxes) and PHP's own lexer (http://lxr.php.net/xref/PHP_TRUNK/Zend/zend_language_scanner.l) is something like two and a half thousand lines long. Second, you seem to try to parse PHP using your own grammar. From my experience, the PHP grammar (http://lxr.php.net/xref/PHP_TRUNK/Zend/zend_language_parser.y) is really messed up and it's already quite hard to strictly adhere to that grammar (as it has lots of strange quirks) and make it AST-able. If you write up your own grammar I doubt that it will ever match the PHP grammar. I think you should stick as much as possible to the PHP grammar and only introduce changes where required. (The grammar I use (https://github.com/nikic/PHP-Parser/blob/master/grammar/zend_language_parser.phpy) is already made AST-able, though some quirks in the language required me to do brain-transplantation at one point.) For example you already have at least one error in the little grammar you have: The opening and closing tags should be filtered away before being passed to the parser as the may occur anywhere, even in the middle of an expression (`echo $hi . ?> wrote: > Hi > > I'm Flavius Aspra and over the past weeks [1] I've worked on a small > extension, which I think it has a lot of potential. Thanks to everyone > for being patient with me on #php.pecl during this time - I've learned a > lot! > > Meta will enable userland scripts to get the AST of a PHP source code, > to manipulate it, and if desired, to serialize it back to valid PHP code. > > The current status is "not really usable", but it has already reached > around 2k LOCs and I think it's easier for you to review it now, than later. > > The code is still hosted on github, please let me know what needs to be > done to make it PECL-compatible. Advices, bug fixes and improvements are > welcome. Pending TODOs are listed inline, in the code, as they fit, and > longer-term TODOs are in TODO.txt. > > I've already asked for a first thought on IRC, and people seem to see > the need for this extension. > > The project's page is at [2], it's called "phpmeta" there, so no > confusion arises. The extension is simply called "meta". Many other > details can be found in the README. Feel free to ask me anything. > > [1] Actually, I wanted to work on this for GSoC, but I was a little bit > late, so I've worked on it in my spare time > [2] https://github.com/OriginalCopy/phpmeta > > Cheers, > Flavius -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] New extension proposal: meta
On 09/04/2011 09:21 AM, Nikita Popov wrote: Hi Flavius! Hi Nikita First, you seem to try to lex the PHP code yourself too. Why don't you use PHP's internal lexing capabilities? I can't. This is documented in the README. Second, you seem to try to parse PHP using your own grammar. From my experience, the PHP grammar (http://lxr.php.net/xref/PHP_TRUNK/Zend/zend_language_parser.y) is really messed up and it's already quite hard to strictly adhere to that grammar (as it has lots of strange quirks) and make it AST-able. If you write up your own grammar I doubt that it will ever match the PHP grammar. This will become a non-issue, once we've formalized the grammar in standard EBNF, which is already on the TODO list (TODO.txt). I've heard there's an old need to do this among other developers, and I can do it, as I work on meta. I think you should stick as much as possible to the PHP grammar and only introduce changes where required. I can't. This is documented in the README. For example you already have at least one error in the little grammar you have: The opening and closing tags should be filtered away before being passed to the parser It's a feature, and it's documented in the README. There will be flags to instruct it to skip those tokens if desired - it's documented in the code. as the may occur anywhere, even in the middle of an expression (`echo $hi . ?> I know, there is no error handling yet. I've put it on the TODO list. Thanks, Flavius -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] New extension proposal: meta
On Sun, Sep 4, 2011 at 9:21 AM, Nikita Popov wrote: > Hi Flavius! > > I am working on PHP Parser in user land code > (https://github.com/nikic/PHP-Parser), which currently has > capabilities to parse PHP 5.3 into an AST and compile the nodes back > to PHP source. Just as a side note: we do have a PHP grammar parser already in the Drupal community: http://drupal.org/project/grammar_parser It has serialization and deserialization capabilities. It is independent of Drupal. Damien -- 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 04.09.2011 06:37, schrieb Stas Malyshev: > Hi! > > On 9/2/11 6:51 PM, Rasmus Lerdorf wrote: >> Forget the failed tests. A new PHP release is about improving the >> ecosystem. If the folks that maintain libmysql and mysqlnd suggest that >> mysqlnd is more robust and it is the path forward, why would we resist >> this? Do we not trust Oracle/MySQL enough to listen to their input? > > Because of the little thing called BC? what the hell are you speaking about? again: running some hundret domains and made the switch to PHP 5.3 AND mysqlnd at once, no single problem - there are no differences in the real world and yes we are running ALL servers with error_reporting E_ALL | E_STRICT > Right now I have at least two tests suggesting mysqlnd has different > semantics than libmysql, so why are these not reported upstream 1 year ago and fixed? > and not in some obscure corners either but in functions most people use every > day in every > piece of code. This is worrying >>> 2. last_insert_id semantics change. The test expects select queries to >>> reset last insert >>> it to 0, which does not happen with libmysql. Maybe it happens on later >>> versions of mysql >>> server, I do not know mhh in the real world some function makes the insert and giving back the ID this maybe only relevant in spaghetti code and even there you fetch the insertid after the insert and not 2000 lines later signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] [RFC] New extension proposal: meta
>> First, you seem to try to lex the PHP code yourself too. Why don't you
>> use PHP's internal lexing capabilities?
>
> I can't. This is documented in the README.
I should definitely have read your README first before answering ;)
But I don't quite get your argument in the README that the internal
lexer drops information. I just quick tried a
`var_dump(token_get_all("> For example you already
>> have at least one error in the little grammar you have: The opening
>> and closing tags should be filtered away before being passed to the
>> parser
>
> It's a feature, and it's documented in the README. There will be flags to
> instruct it to skip those tokens if desired - it's documented in the code.
That wasn't exactly what I meant. I meant to say that the opening and
closing tags can occur everywhere not just before and after a
statement list. They shouldn't be part of the grammar.
> Just as a side note: we do have a PHP grammar parser already in the
> Drupal community:
>
> http://drupal.org/project/grammar_parser
>
> It has serialization and deserialization capabilities. It is
> independent of Drupal.
I just tried to use that parser, but running it against the Symfony
codebase seemed to crash the Apache process :(
Nikita
--
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! On 9/4/11 2:13 AM, Reindl Harald wrote: again: running some hundret domains and made the switch to PHP 5.3 AND mysqlnd at once, no single problem - there are no differences in the real world That's assuming "real world" is exclusively your experience. In the meantime, outside of this "real world" I just sent to the list two examples where mysqlnd semantics as assumed by tests appears to be different from libmysql. so why are these not reported upstream 1 year ago and fixed? I don't know why. Why indeed? Why we have tests that fail and nobody fixed them 1 year ago or asked why they fail? I have no good answer to that, sorry. Do you? But while this may be very curious, the real question is - how we fix it *now*? mhh in the real world some function makes the insert and giving back the ID this maybe only relevant in spaghetti code and even there you fetch the insertid after the insert and not 2000 lines later By "real world" you again must be meaning exclusively your code. Let me be the first to congratulate you that your code won't be affected. However the point of BC is not to be compatible exclusively with your code, other code matters too. Including the code you may not like. -- 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] Make mysqlnd default over libmysql in 5.4
Stas, What are you actually afraid of? Libmysql will still be supported. Mysqlnd, despite your examples, work out of a bix with all major apps and frameworks out there. We do test it using drupal 6&7, wp, oscommerce, mediawiki, sugarcrm, etc since 5.3.0. We have zero compatibility. In short, I do not understand your opposition. On Sep 4, 2011 11:33 AM, "Stas Malyshev" wrote: > Hi! > > On 9/4/11 2:13 AM, Reindl Harald wrote: >> again: >> running some hundret domains and made the switch to PHP 5.3 AND mysqlnd >> at once, no single problem - there are no differences in the real world > > That's assuming "real world" is exclusively your experience. In the > meantime, outside of this "real world" I just sent to the list two > examples where mysqlnd semantics as assumed by tests appears to be > different from libmysql. > >> so why are these not reported upstream 1 year ago and fixed? > > I don't know why. Why indeed? Why we have tests that fail and nobody > fixed them 1 year ago or asked why they fail? I have no good answer to > that, sorry. Do you? > But while this may be very curious, the real question is - how we fix it > *now*? > >> mhh in the real world some function makes the insert and giving back the ID >> this maybe only relevant in spaghetti code and even there you fetch the >> insertid after the insert and not 2000 lines later > > By "real world" you again must be meaning exclusively your code. Let me > be the first to congratulate you that your code won't be affected. > However the point of BC is not to be compatible exclusively with your > code, other code matters too. Including the code you may not like. > -- > 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] Make mysqlnd default over libmysql in 5.4
Am 04.09.2011 11:33, schrieb Stas Malyshev: > Hi! > > On 9/4/11 2:13 AM, Reindl Harald wrote: >> again: >> running some hundret domains and made the switch to PHP 5.3 AND mysqlnd >> at once, no single problem - there are no differences in the real world > > That's assuming "real world" is exclusively your experience. In the meantime, > outside of this "real world" I just > sent to the list two examples where mysqlnd semantics as assumed by tests > appears to be different from libmysql. > >> so why are these not reported upstream 1 year ago and fixed? > > I don't know why. Why indeed? Why we have tests that fail and nobody fixed > them 1 year ago or asked why they fail? > I have no good answer to that, sorry. Do you? > But while this may be very curious, the real question is - how we fix it > *now*? > >> mhh in the real world some function makes the insert and giving back the ID >> this maybe only relevant in spaghetti code and even there you fetch the >> insertid after the insert and not 2000 lines later > > By "real world" you again must be meaning exclusively your code. Let me be > the first to congratulate you that your > code won't be affected. However the point of BC is not to be compatible > exclusively with your code, other code > matters too. Including the code you may not like i do not like wordpress and joomla, but both runnign with mysqlnd without troubles only error_reporting must be a little bit changed because the bad code quality signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] Make mysqlnd default over libmysql in 5.4
2011.09.04 12:13 Reindl Harald rašė: > > > Am 04.09.2011 06:37, schrieb Stas Malyshev: >> Hi! >> >> On 9/2/11 6:51 PM, Rasmus Lerdorf wrote: >>> Forget the failed tests. A new PHP release is about improving the >>> ecosystem. If the folks that maintain libmysql and mysqlnd suggest that >>> mysqlnd is more robust and it is the path forward, why would we resist >>> this? Do we not trust Oracle/MySQL enough to listen to their input? >> >> Because of the little thing called BC? > > what the hell are you speaking about? A little thing called backwards compatibility. If you change the way extension behaves and some application depends on that kind of behavior, it will break that application. >> Right now I have at least two tests suggesting mysqlnd has different >> semantics than libmysql, > > so why are these not reported upstream 1 year ago and fixed? Since when third party implementation can impose own standards on primary library implementation? Different semantics is not a bug for libmysql. -- Tomas -- 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 04.09.2011 11:54, schrieb Tomas Kuliavas: > 2011.09.04 12:13 Reindl Harald rašė: >> >> >> Am 04.09.2011 06:37, schrieb Stas Malyshev: >>> Hi! >>> >>> On 9/2/11 6:51 PM, Rasmus Lerdorf wrote: Forget the failed tests. A new PHP release is about improving the ecosystem. If the folks that maintain libmysql and mysqlnd suggest that mysqlnd is more robust and it is the path forward, why would we resist this? Do we not trust Oracle/MySQL enough to listen to their input? >>> >>> Because of the little thing called BC? >> >> what the hell are you speaking about? > > A little thing called backwards compatibility. If you change the way > extension behaves and some application depends on that kind of behavior, > it will break that application. well but mysqlnd is not new and well tested in the wild the only problem is that libmysql-support was not removed with the first 5.3 version, so we would have no discussion now >>> Right now I have at least two tests suggesting mysqlnd has different >>> semantics than libmysql, >> >> so why are these not reported upstream 1 year ago and fixed? > > Since when third party implementation can impose own standards on primary > library implementation? Different semantics is not a bug for libmysql AFAIK was mysqlnd also from sun/mysqlab/oracle anyways - the only thing what is intereresting me why in the world are failing tests ignored over years and the more or less broken code or if the code is not broken the test himslef not fixed why in the world does php permanently introduce redundances and never cleanup them? "mysql_escape_string" and "mysql_real_escape_string" is the best example now we have libmysql, mysqlnd and both used by mysql_* and mysqli_* instead release PHP 5.3 with removing mysql_*-functions and only msqlnd how long do we not have these ballast as everybody can see by for long times failing tests not really maintained my main-question is for what reason are tests introduced if nobofy caers about them for months and years? problems without any tests are hapenning and the reason for making tests, but ignoring failed tests is simply stupid - everywhere independent if we are speaking about opensource or commercial software signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] Make mysqlnd default over libmysql in 5.4
Hi! On 9/4/11 2:38 AM, Pierre Joye wrote: What are you actually afraid of? Having two different semantics inside one mysql extension. Libmysql will still be supported. Mysqlnd, despite your examples, work out of a bix with all major apps and frameworks out there. We do test it Do you really think "but it works for me" is of any value when there's an example where it does not? -- 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] Make mysqlnd default over libmysql in 5.4
Am 04.09.2011 12:22, schrieb Stas Malyshev: > Hi! > > On 9/4/11 2:38 AM, Pierre Joye wrote: >> What are you actually afraid of? > > Having two different semantics inside one mysql extension. so these have to be cleaned up >> Libmysql will still be supported. Mysqlnd, despite your examples, work >> out of a bix with all major apps and frameworks out there. We do test it > > Do you really think "but it works for me" is of any value when there's an > example where it does not? for a release like PHP 5.4 witch the chance to cleanup some thing SURELY and again: targeting mysqlnd as default in 5.4 maybe the missing reason for cleanup / fixup the code so that the tests will run finally signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] ext/pcre/tests/006.phpt
It fails for me too, but only in PHP_5_3 branch, PHP_5_4 and trunk are ok. It seems it starts to fail after Rasmus's default backtrack limit increasion (as Tyrael pointed in his message), which was fixed for PHP_5_4 and trunk in this commit: http://svn.php.net/viewvc?view=revision&revision=312110. Maybe PHP_5_3 branch should be changed accordingly? 2011/9/4 Stas Malyshev : > Hi! > > On 9/2/11 6:10 PM, Ferenc Kovacs wrote: >> >> http://svn.php.net/viewvc?view=revision&revision=311323 >> it seems that the behavior was depending on the backtrack limit, but >> I'm not sure what to do with the test. >> should I simply delete? or can we change the patter in such way that >> it would return NULL again? >> I'm not even sure what are we testing there. :/ > > This tests works for me. What is the failure in your case? > -- > 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 > > -- Regards, Shein Alexey -- 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
Can you please open you eyes a little bit so we can move fordward in this simehow sterile discussion? It is not "works for me" but what actually represent a very large amount of the running php codes out there. There are incimoatibilities too across libmysql versions and across mysql servers, which are actually affecting existing codes. I cannot find any code out there relying on this test case and I very much doubt there is any. It is a non issue (unlike the is_a change for example). On Sep 4, 2011 12:22 PM, "Stas Malyshev" wrote:
Re: [PHP-DEV] [RFC] New extension proposal: meta
On 09/03/2011 11:41 PM, Arpad Ray wrote: Haven't had much of a look yet but I really like the concept :) Glad to hear that. I had this idea for a long time, but I've never got time to look at it. A couple of minor things to note: - Now would be a good time to make it follow the PHP coding standards, before it gets much larger or other devs get involved. Done (but I could have missed a couple of things here and there). - Variable declarations should always begin a block, some platforms will bork otherwise. Done. Thanks. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Turn on error on mixed declarations (Was: New extension proposal: meta)
On 09/04/2011 05:28 AM, Gustavo Lopes wrote: On Sun, 04 Sep 2011 04:05:32 +0100, Kalle Sommer Nielsen wrote: 2011/9/3 Arpad Ray: - Variable declarations should always begin a block, some platforms will bork otherwise. Actually this is required for the C standard, the early ones that we use in PHP, whereas C++ allows them anywhere in a block, like PHP does :) By the way, since committing code with mixed declarations is a frequent problem -- GCC accepts it even without -std=C99 yet the Windows builds are broken --, we could make GCC treat this as an error with: -Werror=declaration-after-statement Thanks, I've compiled it with this parameter and I've fixed those mistakes. DISCLAIMER: I know playing around with CFLAGS in config.m4 is bad, those bits will be removed as documented in the lines right above that What else could I improve, beside the bits I already know about, which are documented in the code (as TODOs) and in TODO.txt? Cheers, Flavius -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ext/pcre/tests/006.phpt
thanks, I should have mentioned that I was playing with the 5_3 branch. On Sun, Sep 4, 2011 at 12:41 PM, Alexey Shein wrote: > It fails for me too, but only in PHP_5_3 branch, PHP_5_4 and trunk are > ok. It seems it starts to fail after Rasmus's default backtrack limit > increasion (as Tyrael pointed in his message), which was fixed for > PHP_5_4 and trunk in this commit: > http://svn.php.net/viewvc?view=revision&revision=312110. Maybe PHP_5_3 > branch should be changed accordingly? > > 2011/9/4 Stas Malyshev : >> Hi! >> >> On 9/2/11 6:10 PM, Ferenc Kovacs wrote: >>> >>> http://svn.php.net/viewvc?view=revision&revision=311323 >>> it seems that the behavior was depending on the backtrack limit, but >>> I'm not sure what to do with the test. >>> should I simply delete? or can we change the patter in such way that >>> it would return NULL again? >>> I'm not even sure what are we testing there. :/ >> >> This tests works for me. What is the failure in your case? >> -- >> 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 >> >> > > > > -- > Regards, > Shein Alexey > -- 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] ext/pcre/tests/006.phpt
On Sun, Sep 4, 2011 at 12:41 PM, Alexey Shein wrote: > It fails for me too, but only in PHP_5_3 branch, PHP_5_4 and trunk are > ok. It seems it starts to fail after Rasmus's default backtrack limit > increasion (as Tyrael pointed in his message), which was fixed for > PHP_5_4 and trunk in this commit: > http://svn.php.net/viewvc?view=revision&revision=312110. Maybe PHP_5_3 > branch should be changed accordingly? > I've just did that, thanks for the tip. http://svn.php.net/viewvc/php/php-src/branches/PHP_5_3/ext/pcre/tests/006.phpt?r1=316107&r2=316106&pathrev=316107 -- Ferenc Kovács @Tyr43l - http://tyrael.hu -- 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_3/ext/standard/tests/streams/bug46024.phpt branches/PHP_5_4/ext/standard/tests/streams/bug46024.phpt trunk/ext/standard/tests/streams/bug46024
Sorry, for the late reply, I missed this mail:
I checked the documentation, but I can't see a mention about this
http://php.net/realpath
could somebody confirm this?
On Sat, Sep 3, 2011 at 1:37 AM, Kalle Sommer Nielsen
wrote:
> Hi
>
> Afair realpath() is not always available, so maybe a function_exist() check
> here?
>
> Sendt fra min iPhone
>
> Den 02/09/2011 kl. 22.28 skrev Ferenc Kovacs :
>
>> tyrael Fri, 02 Sep 2011 20:28:39 +
>>
>> Revision: http://svn.php.net/viewvc?view=revision&revision=316056
>>
>> Log:
>> pass an absolute path for the php binary to proc_open, without this the test
>> would fail if ran with a relative TEST_DEV_EXECUTABLE
>>
>> Changed paths:
>> U php/php-src/branches/PHP_5_3/ext/standard/tests/streams/bug46024.phpt
>> U php/php-src/branches/PHP_5_4/ext/standard/tests/streams/bug46024.phpt
>> U php/php-src/trunk/ext/standard/tests/streams/bug46024.phpt
>>
>> Modified:
>> php/php-src/branches/PHP_5_3/ext/standard/tests/streams/bug46024.phpt
>> ===
>> --- php/php-src/branches/PHP_5_3/ext/standard/tests/streams/bug46024.phpt
>> 2011-09-02 20:02:12 UTC (rev 316055)
>> +++ php/php-src/branches/PHP_5_3/ext/standard/tests/streams/bug46024.phpt
>> 2011-09-02 20:28:39 UTC (rev 316056)
>> @@ -4,7 +4,7 @@
>> > defined"); ?>
>> --FILE--
>> > -$php = getenv('TEST_PHP_EXECUTABLE');
>> +$php = realpath(getenv('TEST_PHP_EXECUTABLE'));
>> $pipes = array();
>> $proc = proc_open(
>> "$php -n -i"
>>
>> Modified:
>> php/php-src/branches/PHP_5_4/ext/standard/tests/streams/bug46024.phpt
>> ===
>> --- php/php-src/branches/PHP_5_4/ext/standard/tests/streams/bug46024.phpt
>> 2011-09-02 20:02:12 UTC (rev 316055)
>> +++ php/php-src/branches/PHP_5_4/ext/standard/tests/streams/bug46024.phpt
>> 2011-09-02 20:28:39 UTC (rev 316056)
>> @@ -4,7 +4,7 @@
>> > defined"); ?>
>> --FILE--
>> > -$php = getenv('TEST_PHP_EXECUTABLE');
>> +$php = realpath(getenv('TEST_PHP_EXECUTABLE'));
>> $pipes = array();
>> $proc = proc_open(
>> "$php -n -i"
>>
>> Modified: php/php-src/trunk/ext/standard/tests/streams/bug46024.phpt
>> ===
>> --- php/php-src/trunk/ext/standard/tests/streams/bug46024.phpt 2011-09-02
>> 20:02:12 UTC (rev 316055)
>> +++ php/php-src/trunk/ext/standard/tests/streams/bug46024.phpt 2011-09-02
>> 20:28:39 UTC (rev 316056)
>> @@ -4,7 +4,7 @@
>> > defined"); ?>
>> --FILE--
>> > -$php = getenv('TEST_PHP_EXECUTABLE');
>> +$php = realpath(getenv('TEST_PHP_EXECUTABLE'));
>> $pipes = array();
>> $proc = proc_open(
>> "$php -n -i"
>>
>> --
>> PHP CVS Mailing List (http://www.php.net/)
>> To unsubscribe, visit: http://www.php.net/unsub.php
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/ branches/PHP_5_3/ext/standard/tests/streams/bug46024.phpt branches/PHP_5_4/ext/standard/tests/streams/bug46024.phpt trunk/ext/standard/tests/streams/bug46024
Hi 2011/9/4 Ferenc Kovacs : > Sorry, for the late reply, I missed this mail: > I checked the documentation, but I can't see a mention about this > http://php.net/realpath > could somebody confirm this? According to the source then it is commented out on BeOS and Netware in NTS and always available in ZTS mode, not sure why we haven't extended this to work in NTS for those two cases. -- regards, Kalle Sommer Nielsen ka...@php.net -- 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_3/ext/standard/tests/streams/bug46024.phpt branches/PHP_5_4/ext/standard/tests/streams/bug46024.phpt trunk/ext/standard/tests/streams/bug46024
On Sun, Sep 4, 2011 at 4:51 PM, Kalle Sommer Nielsen wrote: > Hi > > 2011/9/4 Ferenc Kovacs : >> Sorry, for the late reply, I missed this mail: >> I checked the documentation, but I can't see a mention about this >> http://php.net/realpath >> could somebody confirm this? > > According to the source then it is commented out on BeOS and Netware > in NTS and always available in ZTS mode, not sure why we haven't > extended this to work in NTS for those two cases. > > -- > regards, > > Kalle Sommer Nielsen > ka...@php.net > it seems that we have more tests using realpath already, what would be the best approach here? for middle/long term, it would be good to have realpath working on all supported platforms, because imo thats a pretty basic function. -- 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] Re: [PHP-CVS] svn: /php/php-src/ branches/PHP_5_3/ext/standard/tests/streams/bug46024.phpt branches/PHP_5_4/ext/standard/tests/streams/bug46024.phpt trunk/ext/standard/tests/streams/bug4
On Sun, Sep 4, 2011 at 5:11 PM, Ferenc Kovacs wrote: > it seems that we have more tests using realpath already, what would be > the best approach here? > for middle/long term, it would be good to have realpath working on all > supported platforms, because imo thats a pretty basic function. Afaict It is actually always available in userland, but maybe the OS realpath function may not be available, but that does not affect userland's realpath. -- 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] intl tests failures
hi, The following tests fail on our tests boxes and gcov: datefmt_localtime_code() [G:\php-sdk\php-src\branches\PHP_5_4\ext\intl\tests\dateformat_localtime.phpt] datefmt_parse_code() [G:\php-sdk\php-src\branches\PHP_5_4\ext\intl\tests\dateformat_parse.phpt] datefmt_parse_localtime() with parse pos [G:\php-sdk\php-src\branches\PHP_5_4\ext\intl\tests\dateformat_parse_localtime_parsepos.phpt] datefmt_parse_timestamp_code() with parse pos [G:\php-sdk\php-src\branches\PHP_5_4\ext\intl\tests\dateformat_parse_timestamp_parsepos.phpt] locale_get_display_region() [G:\php-sdk\php-src\branches\PHP_5_4\ext\intl\tests\locale_get_display_region.phpt] locale_get_region() [G:\php-sdk\php-src\branches\PHP_5_4\ext\intl\tests\locale_get_region.phpt] locale_parse_locale() [G:\php-sdk\php-src\branches\PHP_5_4\ext\intl\tests\locale_parse_locale.phpt] Stas, would you like to look at them or like me to do it? Some are DST related, not sure if it is related to a diff ICU version (we use the latest). 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] sapi/cli/tests/020.php
Hi. the test mentioned in the subject fails on the current trunk. it seems that Dynamic Library Support => enabled Path to sendmail => -t -i is now missing of the output of php -n --ri standard I've checked and with the current trunk, it is missing from even php -i(aka phpinfo) I think that this change isn't intentional, could somebody take a look? -- 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] Make mysqlnd default over libmysql in 5.4
Hi! On 9/4/11 3:43 AM, Pierre Joye wrote: It is not "works for me" but what actually represent a very large amount of the running php codes out there. So you're saying breaking BC is OK if only you can find some unaffected applications, right? There are incimoatibilities too across libmysql versions and across mysql servers, which are actually affecting existing codes. I don't know of any incompatibilities that change semantics on this level, and anyway libmysql is beyond our control, but mysqlnd isn't. I cannot find any code out there relying on this test case and I very much doubt there is any. It is a non issue (unlike the is_a change for example). Why we're testing for functions that, as you claim, nobody ever uses? -- 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] Make mysqlnd default over libmysql in 5.4
hi, On Sun, Sep 4, 2011 at 7:52 PM, Stas Malyshev wrote: > So you're saying breaking BC is OK if only you can find some unaffected > applications, right? No, just like what I said for the is_a change, but it was acceptable for is_a, right? is_a actually broken many (many) apps and codes out there and it was easily identified, and it was even acceptable in a patch release. Go figure. >> There are incimoatibilities too across libmysql versions and across >> mysql servers, which are actually affecting existing codes. > > I don't know of any incompatibilities that change semantics on this level, > and anyway libmysql is beyond our control, but mysqlnd isn't. Look at the history for the mysql's bugs, plenty of them, internally or in userland. >> I cannot find any code out there relying on this test case and I very >> much doubt there is any. It is a non issue (unlike the is_a change for >> example). > > Why we're testing for functions that, as you claim, nobody ever uses? Can you please, and seriously, that's my last attempt, read my answers and see what we actually test? I never claimed that nobody uses this behavior but I cannot find any code, app or framework failing with mysqlnd. Please find one and I will change my mind. Btw, I have seen many totally pointless tests written for the sake of having a better code coverage while the code itself makes absolutely no sense or could even represent something that should not work this way in the 1st place. 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] Re: intl tests failures
Hi! On 9/4/11 9:38 AM, Pierre Joye wrote: hi, Stas, would you like to look at them or like me to do it? Some are DST related, not sure if it is related to a diff ICU version (we use the latest). Just tried, all pass for me on my machine, so I suspect it's because of differences in CLDR data etc. in different ICU versions. Could you send me the results you're getting (just zipping test directory should be enough)? Thanks, -- 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] Make mysqlnd default over libmysql in 5.4
Hi! On 9/4/11 10:59 AM, Pierre Joye wrote: No, just like what I said for the is_a change, but it was acceptable for is_a, right? is_a actually broken many (many) apps and codes out there and it was easily identified, and it was even acceptable in a patch release. Go figure. Please do not drag totally unrelated matters into the discussion. It serves absolutely no purpose. Look at the history for the mysql's bugs, plenty of them, internally or in userland. OK, look at them and? What you want me to see there? Can you please, and seriously, that's my last attempt, read my answers and see what we actually test? I never claimed that nobody uses this behavior but I cannot find any code, app or framework failing with mysqlnd. Please find one and I will change my mind. You said "I cannot find any code out there relying on this test case and I very much doubt there is any.". This means you're claiming we're testing behavior for which there's no code out there - if your guesses reflect the truth - that is using it. I think you're wrong but that's exactly what you said. Btw, I have seen many totally pointless tests written for the sake of having a better code coverage while the code itself makes absolutely no sense or could even represent something that should not work this way in the 1st place. It is true, but this test actually proved useful - it discovered difference in semantics between mysqlnd and libmysql, and in frequently used functions at that. Now we know it and we have to decide what to do with it. I hope once the weekend is over, mysqlnd maintainers would voice their opinions on the matter - e.g., should it work this way or not. That's exactly what I want to achieve. -- 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] Make mysqlnd default over libmysql in 5.4
On Sun, Sep 4, 2011 at 8:08 PM, Stas Malyshev wrote: >> No, just like what I said for the is_a change, but it was acceptable >> for is_a, right? is_a actually broken many (many) apps and codes out >> there and it was easily identified, and it was even acceptable in a >> patch release. Go figure. > > Please do not drag totally unrelated matters into the discussion. It serves > absolutely no purpose. That's exactly the same situation, we change something and "fix the test" to adapt to the actual behavior. >> Look at the history for the mysql's bugs, plenty of them, internally >> or in userland. > > OK, look at them and? What you want me to see there? That's the libmysql world is far from being perfect (very far) and it is time to get mysqlnd mainstream. And if 5.4 is not the right time, the let kill that thing or move it to pecl as it is totally useless if almost nobody uses it (as it is the case right now) >> Can you please, and seriously, that's my last attempt, read my answers >> and see what we actually test? I never claimed that nobody uses this >> behavior but I cannot find any code, app or framework failing with >> mysqlnd. Please find one and I will change my mind. > > You said "I cannot find any code out there relying on this test case and I > very much doubt there is any.". This means you're claiming we're testing > behavior for which there's no code out there - if your guesses reflect the > truth - that is using it. I think you're wrong but that's exactly what you > said. In my book "I very much doubt" has another meaning than "I'm totally sure". Still waiting for an example outside this test tho'. 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
Re: [PHP-DEV] Make mysqlnd default over libmysql in 5.4
Am 04.09.2011 19:52, schrieb Stas Malyshev: >> There are incimoatibilities too across libmysql versions and across >> mysql servers, which are actually affecting existing codes. > > I don't know of any incompatibilities that change semantics on this level, > and anyway libmysql is beyond our control, but mysqlnd isn't how is libmysql under your control? and why isn't mysqlnd? maybe you mean exactly the opposite. signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] Make mysqlnd default over libmysql in 5.4
On Sun, Sep 4, 2011 at 7:59 PM, Reindl Harald wrote: > > > Am 04.09.2011 19:52, schrieb Stas Malyshev: > >>> There are incimoatibilities too across libmysql versions and across >>> mysql servers, which are actually affecting existing codes. >> >> I don't know of any incompatibilities that change semantics on this level, >> and anyway libmysql is beyond our control, but mysqlnd isn't > > how is libmysql under your control? > and why isn't mysqlnd? > > maybe you mean exactly the opposite. he wrote the exact oppsosite AFAIK. -- 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] Re: [PHP-CVS] svn: /php/php-src/ branches/PHP_5_3/ext/standard/tests/streams/bug46024.phpt branches/PHP_5_4/ext/standard/tests/streams/bug46024.phpt trunk/ext/standard/tests/streams/bug4
Hi Pierre 2011/9/4 Pierre Joye : > Afaict It is actually always available in userland, but maybe the OS > realpath function may not be available, but that does not affect > userland's realpath. http://lxr.php.net/opengrok/xref/PHP_TRUNK/ext/standard/file.c#2275 According to that its commented out for those systems, now I know that the BeOS might not be a first class citizen in the PHP world, although the Haiku project which is a revamp of BeOS will be supporting it. Not sure about Netware. But if its possible to always be available in ZTS, what would the reasoning for it not to be available in NTS? I haven't dug into the code that deeply so I'm just curious. -- regards, Kalle Sommer Nielsen ka...@php.net -- 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_3/ext/standard/tests/streams/bug46024.phpt branches/PHP_5_4/ext/standard/tests/streams/bug46024.phpt trunk/ext/standard/tests/streams/bug4
Hi! On 9/4/11 1:35 PM, Kalle Sommer Nielsen wrote: But if its possible to always be available in ZTS, what would the reasoning for it not to be available in NTS? I haven't dug into the code that deeply so I'm just curious. My guess - ZTS has virtualized directory handling system (VCWD), NTS doesn't and uses underlying APIs directly (on Unix at least). May be related to that. -- 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/intl/grapheme/grapheme_string.c branches/PHP_5_4/ext/intl/tests/bug55562.phpt trunk/ext/intl/grapheme/grapheme_string.c trunk/ext/intl/t
I think it is a bug fix and should be applied to 5.3, as the report is based 5.3 as well. 2011/9/4 Stas Malyshev : > Hi! > > On 9/4/11 2:44 PM, Pierre Joye wrote: >> 5.3? > > It changes the API (even though old one is wrong IMO) so I'm not sure if > it belongs there. Up to 5.3 RM. > > -- > Stanislav Malyshev, Software Architect > SugarCRM: http://www.sugarcrm.com/ > (408)454-6900 ext. 227 > -- 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
