Re: [PHP-DEV] Revert Tokenizer behavior for 5.4
What I am really hearing in this thread is some people have interest in a way to easily access the __COMPILER_HALT_OFFSET__ Well, not exactly for me : I'm not interested strictly on getting the offset. I'm more interested in doing generic static code analysis, and part of that is getting the halt offset, amongst many other data coming from tokens. The big pb with the fix applied since 5.3.6 is that we can not do that anymore without many complications. So in this way, I agree with Nikita, the second aspect of the patch (getting the binary data in a T_INLINE_HTML) is not a necessity, thought that may help. But the first aspect of the patch (counting 3 semantic tokens after T_HALT_COMPILER) is really needed. That would just give us back the power/feature we have lost since 5.3.6. So my request would be : plase apply the patch counting 3 semantic tokens for 5.4 asap, then we can discuss the remaining later for the shake of completeness of the discussion. Nicolas
Re: [PHP-DEV] Revert Tokenizer behavior for 5.4
Wait wait wait. Thats the point here? __COMPILER_HALT_OFFSET__ already tells you where the data starts. -Hannes I didn't sent this message first, but after reading the mail from Chris, I think maybe it would clear the confusion: It is about tokenizing a file which has __halt_compiler(); in it. before the fix of the original bugreport, one could get the warning Unexpected character in input if he tried to token_get_all() a script which had binary data after the __halt_compiler(); iliaa's fix was trivial: break from the tokenizer if __halt_compiler token is found. but it isn't good enough, because as the original bugreporter pointed out: 1, now the token_get_all() won't return the (); after __halt_compiler, which means that if you rebuild the code from the tokens, you will have invalid php code. 2, you have no way to get the binary data after the __halt_compiler via the tokenizer, so you can't rebuild the original file using only the tokenizer. (for example one could use the tokenizer to strip the whitespaces and comments from a given file in-place) both problems could be hacked around from userland, but imo it still worth fixing those. -- 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] 5.4 beta
On Thu, Sep 15, 2011 at 23:44, Pierre Joye pierre@gmail.com wrote: On Thu, Sep 15, 2011 at 11:42 PM, Stas Malyshev smalys...@sugarcrm.com wrote: The problem is data may vary by CLDR version, etc. and keeping pace with all variants on all platforms, etc. will be a nightmare. To have a couple of versions, say x.y, x.y+1 sounds reasonable and possible. Its not our responsibility to test the 3rd party library data, thats for intl to test. Just like its not our responsibility to test flex or OS network error messages. We need to test that we understand the data and work with it properly. My test failure seem to be both caused by data difference, but also float precision and timezone issues, and thats within our domain to ensure is working fine. -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Autoguessing TEST_PHP_EXECUTABLE if none is provided in run-tests.php
It seems last message didn't go to the list, resending 2011/9/12 Alexey Shein con...@gmail.com: Created bug report here, included Christopher's suggestion into the patch: https://bugs.php.net/bug.php?id=55672 Please, review the patch and tell me if there are any objections not to take it. Thank you. -- Regards, Shein Alexey -- 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/session/tests/rfc1867_invalid_settings.phpt branches/PHP_5_4/ext/session/tests/rfc1867_invalid_settings_2.phpt trunk/ext/session/tes
2011/9/15 Hannes Magnusson hannes.magnus...@gmail.com: On Wed, Sep 14, 2011 at 12:36, Alexey Shein con...@gmail.com wrote: 2011/9/14 Ferenc Kovacs tyr...@gmail.com: Why do we even have this tmp-php.ini? Why not just make test without any .ini files, i.e. just with -n option? [20:44:09] bjori Tyrael: tmp-php.ini is built from the system ini [20:44:45] bjori Tyrael: if he builds php with --with-config-file-scan-dir=/where/ever/he/has/another/php.ini, then it will use that ini [20:45:09] bjori Tyrael: and thats the whole point of tmp-php.ini, to not only test the default ini, but also random user configurations I agree that it is a bad practice to test random user configuration in our test suite. that's just another moving part in the system. I understand how it works, maybe should we do then this behavior optional (if user wants to test his current configuration) and default make test will run without any php.inis? No? For tests that require certain ini options we have the --INI-- section. For all other tests, we need to ensure they work in all environments, be it under openbasedir, different precision, call_time_pass_reference, variable order, and what have you. And we do want to load the shared extensions the user is using to test them too and ensure there isn't any new unexpected conflicts. Running tests exclusively in an environment known to work doesn't help us. Agreed. But you should cross the line somewhere. The test must be repeatable or it won't be useful, you will have all kinds of erratic tests (described for example here: http://xunitpatterns.com/Erratic%20Test.html). How do you know if the test failed for true or is that user borked his php.ini? It could create a lot of false negative bug reports on qa.php.net (but it's no problem since nobody is looking there :) ) Maybe run failed tests again without user's php.ini? When you write a test case you need to know what you are testing. Just writing a test to write one doesn't give us any benefits. We can easily write test cases that give us 90%+ code coverage, but that has absolutely no meaning if it doesn't actually test anything. -Hannes -- Regards, Shein Alexey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 beta
On Fri, Sep 16, 2011 at 10:10 AM, Hannes Magnusson hannes.magnus...@gmail.com wrote: On Thu, Sep 15, 2011 at 23:44, Pierre Joye pierre@gmail.com wrote: On Thu, Sep 15, 2011 at 11:42 PM, Stas Malyshev smalys...@sugarcrm.com wrote: The problem is data may vary by CLDR version, etc. and keeping pace with all variants on all platforms, etc. will be a nightmare. To have a couple of versions, say x.y, x.y+1 sounds reasonable and possible. Its not our responsibility to test the 3rd party library data, thats for intl to test. It is not about validating the correctness of ICU itself but our binding or APIs usage. And to do that we have to deal with the ICU results. -- 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] 5.4 beta
Hannes Magnusson wrote: My test failure seem to be both caused by data difference, but also float precision and timezone issues, and thats within our domain to ensure is working fine. The remaining interbase/firebird errors are similar niggles ... but I'm not sure just how one would know that the error was actually the same data just viewed slightly differently? Float with the E or fully expanded is one which pops up often? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] A couple of missing directories if configure.js is forgotten.
Sure thing. https://bugs.php.net/bug.php?id=55709 and https://bugs.php.net/bug.php?id=55710 2011/9/15 Pierre Joye pierre@gmail.com: hi Richard, Can you open a bug for each of your patches please? Thanks! 2011/9/15 Ángel González keis...@gmail.com: Richard Quadling wrote: Hi. Sometimes I remove Release prior to nmake to make sure everything builds clean. 2 directories fail to get build Release\win32 Release\devel The attached patch fixes that. - @for %D in ($(BUILD_DIRS_SUB)) do @if not exist %D @mkdir %D NUL + @for %D in ($(BUILD_DIRS_SUB) devel win32) do @if not exist %D @mkdir %D NUL Richard. Shouldn't you add them to BUILD_DIRS_SUB instead? -- 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 -- Richard Quadling Twitter : EE : Zend : PHPDoc @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] A couple of missing directories if configure.js is forgotten.
2011/9/15 Ángel González keis...@gmail.com: Richard Quadling wrote: Hi. Sometimes I remove Release prior to nmake to make sure everything builds clean. 2 directories fail to get build Release\win32 Release\devel The attached patch fixes that. - @for %D in ($(BUILD_DIRS_SUB)) do @if not exist %D @mkdir %D NUL + @for %D in ($(BUILD_DIRS_SUB) devel win32) do @if not exist %D @mkdir %D NUL Richard. Shouldn't you add them to BUILD_DIRS_SUB instead? Yep! See bug https://bugs.php.net/bug.php?id=55710 with latest patch. It was an edge case for the win32 directory caused by having pecl/win32service configured for building. Any extension with win32 in it would have caused the issue. -- Richard Quadling Twitter : EE : Zend : PHPDoc @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
