Re: [PHP-DEV] is GD being actively maintained?
Hi, Rasmus, Just wanted to note that I've tested your script from http://fontjazz.com/metrics/test.php and couldn't reproduce the bug. I'm on the Ubuntu 12.04 with PHP 5.3.10-1ubuntu3.2 with Suhosin-Patch Have you tried upgrading your FreeType library and recompiling latest stable PHP with it? Good luck. P.S. I'm not a GD developer. 2012/9/6 Rasmus Schultz ras...@mindplay.dk: I opened this bug report 2 years ago: https://bugs.php.net/bug.php?id=52756 Is GD still actively maintained? If it isn't, then perhaps it's time to start thinking about switching to a graphics library that is maintained? Perhaps something more modern with real drawing capabilities and a better typographic engine? Just wondering... -- Regards, Shein Alexey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] is GD being actively maintained?
2012/9/6 Jannik Zschiesche he...@apfelbox.net: Am Donnerstag, 6. September 2012 um 15:05 schrieb Alexey Shein: Hi, Rasmus, Just wanted to note that I've tested your script from http://fontjazz.com/metrics/test.php and couldn't reproduce the bug. I'm on the Ubuntu 12.04 with PHP 5.3.10-1ubuntu3.2 with Suhosin-Patch Have you tried upgrading your FreeType library and recompiling latest stable PHP with it? Good luck. P.S. I'm not a GD developer. Hi Alexey, I just tested it on PHP 5.4.4 on OSX and I can confirm, that the issue is still present. (used font: Open Sans Regular/Bold/Italic, screenshots: http://min.us/mM2c5yyBU ) Here is mine with georgiai.ttf http://minus.com/mbcHodY8D8 -- Regards, Shein Alexey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] skipping optional parameters
18 апреля 2012 г. 11:40 пользователь Stas Malyshev smalys...@sugarcrm.com написал: Hi! NULL or empty string? I.e. will optional parameters always get NULLs or their default values? Their default values. That's the whole point of it - if I wanted just nulls, I could put nulls in the call, but if I want the actual default, I'd have to find the definition and copy-paste from there. Thank you, that's what I wanted to hear. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- Regards, Shein Alexey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] skipping optional parameters
Hi!
My opinion is that solution tries to overcome bad consequences of
legacy code, when it's not feasible to change something without
breakage a lot of code, although the real solution is to refactor
functions with long variable lists (as Uncle Bob says), maybe this
should be noted in documentation of this feature.
Alan nicely highlighted all cons of this feature, but instead of
voting against it I suggest to put that into the docs, so people can
use it wisely and understand consequences.
One question about implementation:
Given we have this function
function create_query($where, $order_by, $join_type='', $execute = false,
$report_errors = true) {}
and this statement
On the engine level, it will be implemented by putting NULL in the place
where the parameter is passed.
what value $join_type will get on this call?
create_query(deleted=0, name,,, /*report_errors*/ true);
NULL or empty string? I.e. will optional parameters always get NULLs
or their default values?
Thanks.
--
Regards,
Shein Alexey
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-DOC] Creating new remote branch: Fatal error.. but still seem to have worked
суббота, 7 апреля 2012 г. пользователь Hannes Magnusson писал: Hello I pushed a new branch (with no changes) just now, and got the following fatal error. The branch seems to have been pushed just fine though? vagrant@lucid32:~/src/phd$ git checkout -b PHD_1_1 Switched to a new branch 'PHD_1_1' vagrant@lucid32:~/src/phd$ git branch -a * PHD_1_1 master remotes/origin/GWYNNE_PLAYS_HERE remotes/origin/HEAD - origin/master remotes/origin/MAIN remotes/origin/PHD_0_2 remotes/origin/PHD_0_4 remotes/origin/PHD_ENTERPRISE remotes/origin/RESTRUCTURE remotes/origin/master remotes/origin/rsync vagrant@lucid32:~/src/phd$ git diff PHD_1_1..master vagrant@lucid32:~/src/phd$ git push origin PHD_1_1 Enter passphrase for key '/home/vagrant/.ssh/id_rsa': Total 0 (delta 0), reused 0 (delta 0) remote: Welcome bjori. remote: Changesets accepted. Thank you for your contribution. remote: remote: fatal: ambiguous argument 'refs/heads/MAIN refs/heads/PHD_0_2 refs/heads/PHD_0_4 refs/heads/PHD_1_1 refs/heads/PHD_ENTERPRISE refs/heads/RESTRUCTURE refs/heads/master refs/heads/rsync': unknown revision or path not in the working tree. remote: Use '--' to separate paths from revisions remote: Attempting to push to mirror remote: To g...@github.com:php/phd.git remote: * [new branch] PHD_1_1 - PHD_1_1 To g...@git.php.net:/phd.git * [new branch] PHD_1_1 - PHD_1_1 -Hannes Hi! This could happen if you have a branch and a tag with same names. Karma script should note that situation. -- Regards, Shein Alexey
Re: [PHP-DEV] resume after exception
3 апреля 2012 г. 0:40 пользователь Johannes Schlüter johan...@schlueters.de написал: On Mon, 2012-04-02 at 08:44 -0400, Rasmus Schultz wrote: I was just reading about the new async/await keywords in C# 5.0, and while this has no particular relevance to PHP as such, it got me thinking about this idea... What if you could resume execution after an exception was thrown? So some random piece of code might cause other code to execute, which was expected not to run (and therefore threw an exception). I fear this brings hardly understandable code flows. Yeah, don't like it either. It seems like goto is coming back. Oh, wait, goto is already come back in 5.3 :) -- Regards, Shein Alexey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Change all XFAIL tests to FAIL
1 апреля 2012 г. 2:38 пользователь Alexey Shein con...@gmail.com написал: 1 апреля 2012 г. 0:27 пользователь Johannes Schlüter johan...@schlueters.de написал: On Sat, 2012-03-31 at 13:21 +0500, Alexey Shein wrote: By constantly publishing newsletter with failed / xfail bugs you're telling them That's our current problems. Maybe you could help us with them. This way we could convert that discussing energy into some good patches. While many people will simply filter them out. At least that's my experience with such automated mails in different projects ;-) johannes Okay, let's find it out. I've created a poll here: https://wiki.php.net/xfail_poll. Please, leave your voice. I'll close the poll in a week. Thank you. It seems nobody likes the idea. Sorry for taking your time and any inconvenience I've created. -- Regards, Shein Alexey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Change all XFAIL tests to FAIL
1 апреля 2012 г. 14:27 пользователь Ferenc Kovacs tyr...@gmail.comjavascript:; написал: On Sun, Apr 1, 2012 at 9:39 AM, Christopher Jones christopher.jo...@oracle.com javascript:; wrote: On 3/31/12 2:38 PM, Alexey Shein wrote: 1 апреля 2012 г. 0:27 пользователь Johannes Schlüter johan...@schlueters.de javascript:; написал: On Sat, 2012-03-31 at 13:21 +0500, Alexey Shein wrote: By constantly publishing newsletter with failed / xfail bugs you're telling them That's our current problems. Maybe you could help us with them. This way we could convert that discussing energy into some good patches. While many people will simply filter them out. At least that's my experience with such automated mails in different projects ;-) johannes Okay, let's find it out. I've created a poll here: https://wiki.php.net/xfail_**poll https://wiki.php.net/xfail_poll. Please, leave your voice. I'll close the poll in a week. Thank you. Is there anything in the Jenkins work that makes this discussion irrelevant (or more relevant)? What other ways should we be running reviewing test failures? currently XFAILs are handled as passing tests. I'm working on a solution for having email notifications about new test failures. Wow, that was great post :) snip you can also see a single test result history via selecting a test and clicking on the History link ( http://ci.qa.php.net/job/php-src-5.4-matrix-build/651/architecture=x86,os=linux-debian-6.0/testReport/php-src.ext.libxml/tests/004_phpt___libxml_set_streams_context__/history/ ? for example) here you can also see the status for that test in each build, so you can see when was that introduced or fixed. for example you can see that the libxml_set_streams_context() started failing after build number 641, where you can see the Changes mentions a libxml bugfix: http://ci.qa.php.net/job/php-src-5.4-matrix-build/architecture=x86,os=linux-debian-6.0/641/changes The one problem I see here is that we keep only 100 last builds, so if bug is old enough you can't know build/revision where it's introduced. Maybe we should not keep in jenkins build php binary but only lightweight stuff like junit logs, coverage reports (if we have them) and etc. This way build size become smaller, so we can keep more of them. -- Regards, Shein Alexey -- Regards, Shein Alexey
Re: [PHP-DEV] Change all XFAIL tests to FAIL
30 марта 2012 г. 22:16 пользователь Christopher Jones christopher.jo...@oracle.com написал: On 3/29/12 3:00 PM, Alexey Shein wrote: Hi, internals! I've got a suggestion about refactoring our tests suite. I'd like to remove XFAIL institution and mark all failing tests just as FAIL. XFAIL has a problem that it hides attention from failing tests depending on not yet fixed bugs (most important), not yet implemented features (less important). Failed tests should make pain. They should bug you every day until you go and fix them. XFAILs serve now as a pain-killers, we've got about 50 of them in the repo, so devs (I assume) think this way: It's failing, but it's EXPECTED to fail, so let's leave it as is. That's wrong thinking. Either tests are correct and if they fail you should fix the code and leave them failed until the code is fixed, or, if the tests are incorrect - fix the tests or remove them completely. The XFAIL mechanism reflects the reality of open source that not all bugs are fixed. We need a simple, low maintenance way to have a 'clean' testsuite shipped which exhibits minimal noise so that users don't waste time investigating known failures. I'm trying to solve 2 different problems here: 1) Separate clean testsuite (new failed bugs) from known failed bugs (as you said) - XFAIL solves that 2) Keep devs' attention on known failures - XFAIL doesn't solve that. You remember about them when you run tests and if you want make attention at them. What I propose is a single *daily* newsletter saying Hey, guys! We still have XFAIL bugs on 5.3 list bugs, 5.4 list bugs and master list bugs. Bye! That will make some pressure, especially if those bugs have maintainers. We do get constant notification of bugs assigned to us. I don't believe it has any impact on the fix rate. Hmm, that's different. You get a notification if there's some change on that bug (new comment/state changed/patch etc.). If bug didn't change for years, you won't get any notifications - it's more likely you forget about it. XFAIL also allows end users to see when something has broken that used to work. Maybe, but not the best way, since it involves manual editing phpt source FAIL-XFAIL. Jenkins build failure notification solves it better. If the system is being overused, feel free to call people out on it. I don't think it should be used for unimplemented features long term. XFAIL is a simple mechanism. Anything different like moving tests to a special 'failed' directory adds burden. I don't belive we have extra cycles for this, but would be happy to be proved wrong. Agree, that's a lot of work, need to try something else. The problem is here what bugs need to be solved for release to be made?. We need to separate these somehow. XFAIL doesn't really helps here since it's just bugs that are hard to solve and it doesn't enforce any priority here. For 5.4 release Stas used wiki for keeping track of bugs stopping the release. -- Regards, Shein Alexey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Change all XFAIL tests to FAIL
31 марта 2012 г. 12:50 пользователь Stas Malyshev smalys...@sugarcrm.com написал: Hi! 2) Keep devs' attention on known failures - XFAIL doesn't solve that. You remember about them when you run tests and if you want make attention at them. Which devs you are referring to? Why you assume their attention needs help? Every developer on this list including core and non-core. There are a lot of people reading this list, that's clearly seen by lengthy feature discussions. If you're well-aware of current PHP problems (I assume you're the best person to ask about, since you're RM), others may even don't have a glue about that. By constantly publishing newsletter with failed / xfail bugs you're telling them That's our current problems. Maybe you could help us with them. This way we could convert that discussing energy into some good patches. What I propose is a single *daily* newsletter saying Hey, guys! We still have XFAIL bugs on 5.3 list bugs, 5.4 list bugs and master list bugs. Bye! That will make some pressure, especially if those bugs have maintainers. I would not subscribe to this and would not read this. Would you? Why? I don't mean a separate mailing list, but a letter to this list, internals. If i'm already here, I'd read it. If you think that daily is too much - let's make it weekly, but it should come every week, not just once or twice. If it annoys you too much or you think it's useless for you - you always can tune your spam filter. I'd read it, since I like writing/fixing tests in my spare time, maybe that letter would contain some tests I can easily fix (since I'm not good C-developer I work primarily on tests), or my investigation on problem will help somebody to make a patch. We know we have technical debt. It's not a secret. What we need is not more harassment but more people fixing that debt. Spamming whole list with messages that nobody would read is not the solution. You can't interest more people if they are not aware of your problems. That's why personal reminders won't work good here - if only bug maintainer will be notified, nobody else will recall that bug. -- Regards, Shein Alexey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Change all XFAIL tests to FAIL
31 марта 2012 г. 12:34 пользователь Rasmus Lerdorf ras...@lerdorf.com написал: On 03/30/2012 11:25 PM, Alexey Shein wrote: Hmm, that's different. You get a notification if there's some change on that bug (new comment/state changed/patch etc.). If bug didn't change for years, you won't get any notifications - it's more likely you forget about it. That's not true. There is a weekly reminder email if you have outstanding open bugs assigned to you. Although I haven't seen one for a little while, so we may finally have given up on that since it was completely ineffective. Ok, we have a weekly reminder to bug maintainers (that maybe not working). That's a bit different, I'm talking about public email about failed tests - if bug is closed, maintainer won't get a notfication and, if bug is reopened, only maintainer will get a notification, not everybody on list. -- Regards, Shein Alexey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] (*PATCH*) getters/setters Implementation
31 марта 2012 г. 18:19 пользователь Clint M Priest cpri...@zerocue.com написал: The patches are applied to this fork if anyone wants to check it out: https://github.com/cpriest/php-src It would be easier to discuss/review your patch if you'd make pull request: https://wiki.php.net/vcs/gitworkflow#workflow_for_external_contributors Thank you. -Original Message- From: Clint M Priest [mailto:cpri...@zerocue.com] Sent: Thursday, March 29, 2012 8:14 PM To: internals@lists.php.net Subject: RE: [PHP-DEV] (*PATCH*) getters/setters Implementation Thanks for the feedback, I'll take care of some of these. What did you mean about the out of sync regarding naming? With the unexpected values to the methods I'm not sure what you mean, there are no 'expected values' to be passed. For the auto-backed properties it would be assigned to whatever value was being passed, null or whatever. For the non auto-backed properties it would depend on the user-supplied getter/setter implementation. Am I missing something here? Regarding the open questions on read-only/write-only I don't think they are strictly necessary any longer. The original RFC had them for enforcing a value to be read only but it would be equivalent of setting an accessor with just a getter and final although it would allow for it to be over-ridden. Are the read-only/write-only tags desired? I think the test cases that are present are complete, I could not think of any further tests to write or I would have written them, any suggestions? I'll update the RFC with backward compatibility comments though I believe there are none, anyone else see any backward compatibility issues? -Original Message- From: Christopher Jones [mailto:christopher.jo...@oracle.com] Sent: Thursday, March 29, 2012 1:14 PM To: internals@lists.php.net Subject: Re: [PHP-DEV] (*PATCH*) getters/setters Implementation On 03/28/2012 08:13 PM, Clint M Priest wrote: What are the next steps to get this added to some future release? Attached is a patch against ~/trunk A couple of brief comments from the sidelines without having followed previous discussion in detail: - The RFC appears to have open questions e.g about the need for readonly etc keywords - The tests and RFC are out of sync regarding naming, e.g. readonly vs read-only - The RFC makes no mention of backward compatibility issues - Did I miss seeing tests that pass in unexpected values to the methods? - I would expect a larger number of tests overall when the feature is merged/completed. - If these are indeed magic methods they need __ prefixes, so consider the names __getter and __setter - I'd suggest biting the github bullet and creating your own PHP fork with your patches. People will be able to test and you might get more feedback. -- Email: christopher.jo...@oracle.com Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ -- PHP Internals - PHP Runtime Development Mailing List 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 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] Change all XFAIL tests to FAIL
1 апреля 2012 г. 0:27 пользователь Johannes Schlüter johan...@schlueters.de написал: On Sat, 2012-03-31 at 13:21 +0500, Alexey Shein wrote: By constantly publishing newsletter with failed / xfail bugs you're telling them That's our current problems. Maybe you could help us with them. This way we could convert that discussing energy into some good patches. While many people will simply filter them out. At least that's my experience with such automated mails in different projects ;-) johannes Okay, let's find it out. I've created a poll here: https://wiki.php.net/xfail_poll. Please, leave your voice. I'll close the poll in a week. Thank you. -- Regards, Shein Alexey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Change all XFAIL tests to FAIL
30 марта 2012 г. 5:55 пользователь Stas Malyshev smalys...@sugarcrm.com написал: Hi! The difference started from 5.3.9 release when we start to pay *much more* attention to tests. You now can cleanly see failing tests, it's not that huge list, so it's big difference. Yes, and removing XFAILs would kill that advantage. The main idea I'm trying to say is that it's comfortable to live with XFAILs. That's why they live by years. They don't get make any pressure, we don't have a release rule No failing tests, so they go You talk about making pressure, but when date fails were sitting in the tests as FAILs, they didn't make any pressure and nobody was fixing them. And if we had rule of no failing tests, we'd have no releases for years now, because nobody is fixing those tests and bugs behind them. You want to fix them? Go ahead, no problem. But if there's nobody to fix them - what's the use to put them in FAILs and prevent us from seeing issues that *are* going to be fixed? They didn't make any pressure because they were not frequently exposed on the list and irc. What I think should be done: 1) Make a *daily* notifications about failing tests in this mailing list and irc. This will create pressure and make sure that nobody will forget that we still have problems and they need to be solved. BTW, that's really strange that we still do not have *any* notifications about failed builds, but do have them on phpdoc project. I don't think those guys are smarter than us :) 2) Create explicit distinction release-stopper tests (let's call them acceptance) and usual functional/unit tests. For example, we create a folder acceptance under each tests/ folder and put there all tests that never should be broken. If those tests are broken, release can't be made. We have 3 failing tests and 35 xfails, I don't see any tons of fails here. Sorry, if I sound like a broken record, but if we need to fix those, we need to make more noise about that. OK, you made noise. Let's see how many of those 35 xfails get fixed, let's say, in a month. How many you would predict it would be? That's not a noise. See p.1 above. If we don't setup *constant* notifications, people won't feel pressure. Of course, it's easy to tune spam filter in your mail client or ban a bot on IRC, that's why I'm asking for agreement here, to make it a part of the development process. Guys, I respect you very much, all of you. I can feed my family because of your work. I'm really trying to help. Please, don't get it personally and let's try to find a decision together. I assume we at least agree that we have a problem here. XFAIL - expected to fail test. If it's fails - then it's ok. That's how I understand it. Failing test should not be ok, it's an error. If you get used to not paying attention on failing tests, you're in dangerous situation. It's like a fairy tale about boy that cried Nobody already *is* paying attention, so it's not an if, it's a fact. It's a sad fact, but still a fact. And it's not result of the XFAILs, because this situation predates XFAILs and was there before we moved such tests to XFAILs. See above. About incomplete, well, it seems it doesn't suite here much, it's about that test is not fully written or finished. If your test is not finished, do it in a fork. By the time the feature gets merged into main branches, it should be complete enough to run the tests. Yes, it's a sane way too. -- Regards, Shein Alexey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Change all XFAIL tests to FAIL
Hi, internals! I've got a suggestion about refactoring our tests suite. I'd like to remove XFAIL institution and mark all failing tests just as FAIL. XFAIL has a problem that it hides attention from failing tests depending on not yet fixed bugs (most important), not yet implemented features (less important). Failed tests should make pain. They should bug you every day until you go and fix them. XFAILs serve now as a pain-killers, we've got about 50 of them in the repo, so devs (I assume) think this way: It's failing, but it's EXPECTED to fail, so let's leave it as is. That's wrong thinking. Either tests are correct and if they fail you should fix the code and leave them failed until the code is fixed, or, if the tests are incorrect - fix the tests or remove them completely. Reasons introducing XFAILs were described in this article: http://zoomsplatter.blogspot.com/2008/06/why-xfail.html I'll quote some thoughts from there: The intention of XFAIL is to help people working on developing PHP. Consider first the situation where you (as a PHP implementer) are working through a set of failing tests. You do some analysis on one test but you can't fix the implementation until something else is fixed – however – you don't want to lose the analysis and it might be some time before you can get back to the failing test. In this case I think it's reasonable to add an XFAIL section with a brief description of the analysis. This takes the test out of the list of reported failures making it easier for you to see what is really on your priority list but still leaving the test as a failing test. If you need something else to be fixed, leave your failing test, it would annoy everybody, so something else will be fixed faster. If you don't want to lose analysis you can make a list of tests you need with (run-tests.php has -l option which can read/write test filenames from a file) and use that. Failing tests should not be hidden. The second place that I can see that XFAIL might be useful is when a group of people are working on the same development project. Essentially one person on the project finds a missing feature or capability but it isn't something they can add immediately, or maybe another person has agreed to implement it. A really good way to document the omission is to write a test case which is expected to fail but which will pass if the feature is implemented. This assumes that there is general agreement that implementation is a good idea and needs to be done at some stage. These feature tests can be put in a separate branch to not pollute main release branches until the feature is ready. These usually called acceptance tests so they mark if a feature fully implements its functions or not. We could also introduce Incomplete state like it's done in PHPUnit for these tests. What do you think? -- Regards, Shein Alexey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Change all XFAIL tests to FAIL
30 марта 2012 г. 3:19 пользователь Stas Malyshev smalys...@sugarcrm.com написал: Hi! I've got a suggestion about refactoring our tests suite. I'd like to remove XFAIL institution and mark all failing tests just as FAIL. XFAIL has a problem that it hides attention from failing tests depending on not yet fixed bugs (most important), not yet implemented features (less important). Failed tests should make pain. They should bug you every day until you go and fix them. Please note that we were in that position and we moved from there. So to move back, we need some argument about what's different this time from the place we were a year ago. XFAILs serve now as a pain-killers, we've got about 50 of them in the repo, so devs (I assume) think this way: It's failing, but it's EXPECTED to fail, so let's leave it as is. Leaving it as is was happening anyway. It's not like we had crowds of devs descending on test fails but ignoring xfails. Most of xfails were fails and were sitting there ignored for years. So the difference was running constantly with 50 fails or having some xfails but detecting new fails easily since we have no or very little fails normally. The problem is exactly that there are no devs thinking like you imagine them to think. The difference started from 5.3.9 release when we start to pay *much more* attention to tests. You now can cleanly see failing tests, it's not that huge list, so it's big difference. If the problem is only with finding new fails, we can use jenkins for that - it already detects new fails in builds and can mail it here, so they won't get unnoticed. It could also bug a commiter who failed the build - nice feature to have. The main idea I'm trying to say is that it's comfortable to live with XFAILs. That's why they live by years. They don't get make any pressure, we don't have a release rule No failing tests, so they go from release to release until some hero will come up and fix them. By turning them into FAILs they become common problem, because they start to annoy everyone, so it's easier to collaborate on their fixing. from a file) and use that. Failing tests should not be hidden. They are not hidden. But they were not being fixed when they were just fails - only thing that happened is that we constantly run with tons of fails, so it was impossible to distinguish situation of everything is fine from the build is FUBAR. They are not hidden, but they don't *really* bother everyone. My (quite limited setup though) on master branch reports this: Number of tests : 12100 8194 Tests skipped : 3906 ( 32.3%) Tests warned:0 ( 0.0%) ( 0.0%) Tests failed:3 ( 0.0%) ( 0.0%) Expected fail : 35 ( 0.3%) ( 0.4%) Tests passed: 8156 ( 67.4%) ( 99.5%) We have 3 failing tests and 35 xfails, I don't see any tons of fails here. Sorry, if I sound like a broken record, but if we need to fix those, we need to make more noise about that. functions or not. We could also introduce Incomplete state like it's done in PHPUnit for these tests. So what's the difference between xfail and incomplete? XFAIL - expected to fail test. If it's fails - then it's ok. That's how I understand it. Failing test should not be ok, it's an error. If you get used to not paying attention on failing tests, you're in dangerous situation. It's like a fairy tale about boy that cried Wolf!. In the end of the story nobody trusts him. That's why I think we should return trust back to failing tests. About incomplete, well, it seems it doesn't suite here much, it's about that test is not fully written or finished. For example, if we have a plan for some release branch (say, 5.4) about implementing some features, we can have failing/incomplete acceptance tests for those (in a separate suite for example), so release is just a matter of making all tests pass. If feature is quite big and can take several releases (traits come to my mind) it could always be put into separate branch until it's ready. -- Regards, Shein Alexey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Git merging fun and a local clone-per branch workflow
28 марта 2012 г. 0:18 пользователь Christopher Jones christopher.jo...@oracle.com написал: On 03/24/2012 11:17 AM, Alexey Shein wrote: Done: https://wiki.php.net/vcs/gitfaq#multiple_working_copies_workflow I tried it out today. It mostly went smoothly. Hi! Glad to hear that. Because of differing file contents in the branches (from my merge attempts last week) I had to resolve conflicts when merging to ~/php-src. I did a 'git commit -a' to resolve it. Was this the easiest way? If so I will add it to the workflow. This is the common technique afaik. If you get the conflict, you should resolve it somehow (manually or using some merge tools), after that to get know git about you're done, use $ git add files with conflicts Be sure to resolve all conflicts, watch out and strings in conflicted files, there shouldn't be any. $ git commit -m 'Resolved merging conflict' Generally, resolving conflicts in public branches is not a good idea. You'll get very messy branch history. Instead, you should resolve conflicts when rebasing your own private branches against up-to-date public ones. This way your branch becomes a patch to repository HEAD which is very clean and nice to see. When pushing I got: error: Cannot access URL https://git.php.net/repository/php-src.git/, return code 22 This was resolved after doing: cd ~/php-src git config remote.origin.pushurl https://git.php.net/push/php-src.git/ We were having chronic firewall failures while I was doing this, but I believe the above pushurl solved this particular issue. I guess the wording These both are push-urls only really applies to the g...@git.php.net:php-src.git resource. Can you confirm this (before I update the wiki)? Yes, it seems I messed up with those http urls. https://git.php.net/repository/php-src.git - is read-only https://git.php.net/push/php-src.git/ - is push-only So you've done everything right, sorry for confusion. Could you update the wiki, please? -- Regards, Shein Alexey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Adopt GitFlow process
26 марта 2012 г. 4:30 пользователь Stas Malyshev smalys...@sugarcrm.com написал: Hi! Main problem is that our current workflow doesn't allow branch-only changes. I.e. if you make a bugfix and want to stay it in PHP-5.3 only you can't merge 5.3 with 5.4 anymore, otherwise your bugfix will go there. Why would you want a bugfix to be in 5.3 but not in 5.4? Can you give an example? I can see it if the code had substantial change there so bugfix no longer applies. In this case, I would try the merge, see it fail and resolve it as all ours. It shouldn't take longer than 10 mins. Though it you have ideas how to improve that without disrupting the rest of the process and the common use case, you are welcome. For example this commit http://git.php.net/?p=php-src.git;a=commit;h=8d0760f38a9d3dabb3a31d1d47f85827d27d0db4 by Ilia was intentionally commited in PHP-5.3 only, maybe Ilia will describe better. It was then accidentally merged into PHP-5.4 by Hannes (which broke something in PHP-5.4) when he was merging his own changes which merge made a lot of confusion. We should really deal with this problem first before diving further, since it will have great impact on the whole working process with git. If we can live with simple git merge - it would be simply awesome. 1) use cherry-picking in one repo. This has big downside (as dsp pointed) that we can't use git annotate, bisect and other commands assuming that commit is introduced in repository only once. bisect is a bit weird now btw, since it seems to be a bit confused by 5.3-5.4 merge that happened not when it thinks it did - so if you try to bisect changes in 5.4 branch only, you will get some very old changes in. You can quickly go through that, marking them as good, but still not ideal situation. Yep, already tried bisect and it doesn't seem work good at least for php-5.3 branch. Okay, since I'm not too familiar with release process, assume following (please, correct me if I'm wrong): * PHP 5.3 can't have features, only bugfixes True. * PHP 5.3 can have bugfixes that are merged upstream (PHP-5.4 and master) and bugfixes that should stay only in PHP-5.3 Not entirely true - 5.3 code can have bugfixes that aren't merged up, but that would not be the common case. Example - bugfix regarding magic quotes or safe mode, which are not in 5.4. So it's still possible to have not-merged up bugfixes. That means that we should take that into account. I'm just trying to figure out our needs to better understand what needs to be done then. * PHP-5.4 and master can have bugfixes and features that are merged upstream (master) and bugfixes/features that should stay only in current branch 5.4-only fixes very unlikely, as master and 5.4 are very close today. If we ever do big changes in master this is a possibility, as described above, but still won't be a common case - unless we rewrite our engine completely, which doesn't seem to be likely. * All branches are have regular releases True, except for master. In gitflow you have 4 branches: * master - contains only production ready releases, nobody commits here directly * develop - main development branch, all work usually is get merged here * feature/name - feature/bugfix branches for separate bugfixes and features. Merged into develop. * hotfix/name - same that feature branches but is urgent and is always merged into master *and* develop. For example, when security release is issued, this fix should go into release and into main development branch. * release/name - pre-release stability branches, for bug-fixes only. Merged into develop and master (making a new release). When you have a release branch, you can't commit into develop (so hotfixes go here too, if we have release branch). I don't like that can't commit into thing - the main advantage of git as I see it that you can manage release branch and dev/stable branches separately and not have the situation of asking people to sit on their code for 2 months while release is being stabilized. Sorry, I messed this up. You actually can commit into the develop, new features go there, while bugfixes should go in release branch. If you want you can merge release branch into develop anytime you want, it's just should be done at least once when release branch is closed. Make a bugfix in 5.3 $ git flow feature start bugfix PHP-5.3 # create a bugfix branch based on 5.3 $ git flow feature finish -k bugfix 5.3-develop Bugfix get merged into 5.3-develop - this should be implemented since gitflow supports only 1 develop branch for now. -k says to keep branch after finish, since we'll need it to merge upstream Why would we need bugfix branch in our repo here? I would say keep it in your own fork, test it, show it off, get it ready - then merge it into php repo. What is the reason for us to keep halfbaked fix branches in our repo? Merge bugfix from 5.3 repo to 5.4 First, rebase branch against 5.4 $ git
Re: [PHP-DEV] Re: cvs.php.net
25 марта 2012 г. 23:33 пользователь Ferenc Kovacs tyr...@gmail.com написал: On Sun, Mar 18, 2012 at 8:20 PM, Ferenc Kovacs tyr...@gmail.com wrote: Hi, Now that the git migration is reaching php-src, I would like to know what will we do with cvs.php.net (eg. the pserver still running on it). There is also a mention of cvsup.php.net on http://php.net/cvsup.php I guess that also uses/depends on the pserver, but I'm not that familiar with the setup. Should we keep that cvs up and running, or maybe it is time to kill it completely? What do you think? I think it's the time to say good bye to cvs. If somebody still uses it (I doubt) he is already two steps back :) bump -- Ferenc Kovács @Tyr43l - http://tyrael.hu -- Regards, Shein Alexey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Adopt GitFlow process
Hi, internals! There was a discussion recently on IRC that our current git working process is not perfect (especially about keeping one branch-only bugfixes) so that's a suggestion to use (and modify to better suit our needs) nvie's gitflow process and git-flow tool he developed to ease the process. If you're not yet familiar what is that, please read his wonderful article http://nvie.com/posts/a-successful-git-branching-model/ another wonderful article about the gitflow tool http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow/ go to git-flow project on github: https://github.com/nvie/gitflow watch video tutorials about gitflow http://buildamodule.com/video/change-management-and-version-control-deploying-releases-features-and-fixes-with-git-how-to-use-a-scalable-git-branching-model-called-gitflow http://vimeo.com/16018419 http://codesherpas.com/screencasts/on_the_path_gitflow.mov Personally, I see migration from current setup that way so each release branch (PHP-5.3, PHP-5.4 and master) becomes a separate repository with adopted gitflow model (although it should be thought through more carefully). What do you think about that? -- Regards, Shein Alexey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Adopt GitFlow process
26 марта 2012 г. 2:04 пользователь Stas Malyshev smalys...@sugarcrm.com написал: Hi! There was a discussion recently on IRC that our current git working process is not perfect (especially about keeping one branch-only bugfixes) so that's a One thing with discussions on IRC is that nobody except those present there can neither participate nor know what was talked about. And since we have timezone differences and other stuff going on in our lives, that means, on my estimate, a substantial percentage of the people here wouldn't know anything about what was discussed. Thus, it would be useful to explain what exactly is the problem we are talking about. Main problem is that our current workflow doesn't allow branch-only changes. I.e. if you make a bugfix and want to stay it in PHP-5.3 only you can't merge 5.3 with 5.4 anymore, otherwise your bugfix will go there. After some thinking it seems that GitFlow doesn't solve this problem since it's based on merging :), so let's postpone its presence here for a while. What can we do here: 1) use cherry-picking in one repo. This has big downside (as dsp pointed) that we can't use git annotate, bisect and other commands assuming that commit is introduced in repository only once. 2) Simplify code that way so we won't need one-branch only changes, can't say anything concrete here since I'm not familiar with PHP internals at all. We still need a better solution here. If you're not yet familiar what is that, please read his wonderful article http://nvie.com/posts/a-successful-git-branching-model/ another wonderful article about the gitflow tool http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow/ This is a nice process, however I'm not sure how it could apply to PHP. Could you outline what will be done in this case when we have: 1. A bugfix for 5.3 Okay, since I'm not too familiar with release process, assume following (please, correct me if I'm wrong): * PHP 5.3 can't have features, only bugfixes * PHP 5.3 can have bugfixes that are merged upstream (PHP-5.4 and master) and bugfixes that should stay only in PHP-5.3 * PHP-5.4 and master can have bugfixes and features that are merged upstream (master) and bugfixes/features that should stay only in current branch * All branches are have regular releases Advantage of git flow is that your development process becomes more straightforward, you can concentrate on development then on merging bureaucracy. In gitflow you have 4 branches: * master - contains only production ready releases, nobody commits here directly * develop - main development branch, all work usually is get merged here * feature/name - feature/bugfix branches for separate bugfixes and features. Merged into develop. * hotfix/name - same that feature branches but is urgent and is always merged into master *and* develop. For example, when security release is issued, this fix should go into release and into main development branch. * release/name - pre-release stability branches, for bug-fixes only. Merged into develop and master (making a new release). When you have a release branch, you can't commit into develop (so hotfixes go here too, if we have release branch). That's canonical git-flow. We obviously will need several master and develop branches, since PHP release branches need own development and can't be merged in each other. That's not yet implemented and needs to be done in git-flow. So you want to make a bugfix in 5.3 that will be merged upstream Make a bugfix in 5.3 $ git flow feature start bugfix PHP-5.3 # create a bugfix branch based on 5.3 hack ... check ... test $ git add git commit $ git flow feature finish -k bugfix 5.3-develop Bugfix get merged into 5.3-develop - this should be implemented since gitflow supports only 1 develop branch for now. -k says to keep branch after finish, since we'll need it to merge upstream Merge bugfix from 5.3 repo to 5.4 First, rebase branch against 5.4 $ git rebase --onto develop-5.4 bugfix~num bugfix Where num is number of commits in your branch. I know it sucks, but that's how it works :) Or you can git cherry-pick each commit, (simpler solution anyone?). Now your bugfix branch is rebased against 5.4-develop and ready to be merged $ git flow feature finish -k bugfix 5.4-develop Repeat the same for master: $ git rebase --onto develop-master bugfix~num bugfix $ git flow feature finish -k bugfix master-develop Push changes: $ git push 2. A bugfix for 5.4 3. A feature addition for 5.4 Same as above. Since all work is done in branches there's no difference between bugfixes and features. 4. A release of 5.3.x $ git flow release start 5.3.58 bump version number now prepare NEWS, UPGRADING and all that stuff $ git flow release publish 5.3.58 # publish (push to remote repo) release-branch. It's not finished yet! When release is ready you do $ git flow release finish 5.3.58 Release get merged into 5.3-develop and 5.3-master, creating a tag 5.3.58 in 5.3-master 5. A
Re: [PHP-DEV] Git merging fun and a local clone-per branch workflow
Hello, Just wanted to say that I updated multiple working dirs scenario here https://gist.github.com/2165086/, which is *much* more simplified now, thanks to dsp for hint about git-new-workdir script. It should work fine if all changes from downstream branches (such as PHP-5.3) are always merged into upstream (PHP-5.4). If it's not the case, then some other solution is needed. -- Regards, Shein Alexey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Git merging fun and a local clone-per branch workflow
24 марта 2012 г. 18:23 пользователь David Soria Parra d...@php.net написал: On 2012-03-24, Alexey Shein con...@gmail.com wrote: Hello, Just wanted to say that I updated multiple working dirs scenario here https://gist.github.com/2165086/, which is *much* more simplified now, thanks to dsp for hint about git-new-workdir script. It should work fine if all changes from downstream branches (such as PHP-5.3) are always merged into upstream (PHP-5.4). If it's not the case, then some other solution is needed. Can you pleae add a description like that to the php wiki ? Done. https://wiki.php.net/vcs/gitfaq#multiple_working_copies_workflow -- 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] Git merging fun and a local clone-per branch workflow
Nice work Alexey. Can you expand on the if necessary part of the setting the pushurl? I removed that part and added some explanation about clone urls in the beginning. Since this workflow is generally for core devs ssh/https are read/write so you don't need separate setting push-urls. My sense of completeness makes me think the content of your text should be in the wiki, so it can be updated by anyone in the future. Done: https://wiki.php.net/vcs/gitfaq#multiple_working_copies_workflow Chris -- Email: christopher.jo...@oracle.com Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ -- 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] ECDSA support in the openssl extension
21 марта 2012 г. 3:34 пользователь Sergey Ryazanov ryazanov@gmail.com написал: Hello all. Openssl starting from version 0.9.8 supports the ECDSA signature algorithm. Return value of the openssl_get_md_methods() also includes ecdsa-with-SHA1 string. But if I call openssl_sign() with EC key then I have an error: key type not supported in this PHP build!. After some time of digging I discover that this error is rises in the php_openssl_is_private_key() in the openssl.c file. This function simply don't includes check for EVP_PKEY_EC. All signature related actions are performed by OpenSSL library by self and don't depend on any internal code. Is any chance that EVP_PKEY_EC check would be added in the next release? Could I do something to speed up ECDSA adding process? Hello, Sergey, Best you can do is to open a bug with your question in bugtracker and send a patch fixing your problem (with test case attached) against php 5.4 branch. Now it's even easier since php-src has finally moved to git, so you can use github's pull requests mechanism, see https://wiki.php.net/vcs/gitworkflow#workflow_for_external_contributors for the workflow and https://wiki.php.net/vcs/gitfaq for general questions. Thank you. -- With best wishes Sergey Ryazanov -- 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] ECDSA support in the openssl extension
21 марта 2012 г. 12:43 пользователь Sergey Ryazanov ryazanov@gmail.com написал: 21 марта 2012 г. 10:27 пользователь Alexey Shein con...@gmail.com написал: 21 марта 2012 г. 3:34 пользователь Sergey Ryazanov ryazanov@gmail.com написал: Hello all. Openssl starting from version 0.9.8 supports the ECDSA signature algorithm. Return value of the openssl_get_md_methods() also includes ecdsa-with-SHA1 string. But if I call openssl_sign() with EC key then I have an error: key type not supported in this PHP build!. After some time of digging I discover that this error is rises in the php_openssl_is_private_key() in the openssl.c file. This function simply don't includes check for EVP_PKEY_EC. All signature related actions are performed by OpenSSL library by self and don't depend on any internal code. Is any chance that EVP_PKEY_EC check would be added in the next release? Could I do something to speed up ECDSA adding process? Hello, Sergey, Best you can do is to open a bug with your question in bugtracker and send a patch fixing your problem (with test case attached) against php 5.4 branch. Now it's even easier since php-src has finally moved to git, so you can use github's pull requests mechanism, see https://wiki.php.net/vcs/gitworkflow#workflow_for_external_contributors for the workflow and https://wiki.php.net/vcs/gitfaq for general questions. Thank you for advice. I do so in couple of days. Btw is 5.3 branch in development state or only maintenance? If new feature could be added to the 5.3 branch. I preferred upgrade from 5.3.10 to 5.3.11 instead of 5.3.10 - 5.4. Can't say for sure, it's better ask maintainers, I've CC'ed David and Johannes. -- With best wishes Sergey Ryazanov -- Regards, Shein Alexey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Release process nit
13 марта 2012 г. 3:00 пользователь Stas Malyshev smalys...@sugarcrm.com написал: Hi! are they in svn? I can't see them in 5.4 They are not in SVN, but at least for autom4te.cache ones they seem to be generated when configure script is generated, and the packing script happily picks them up. I have no idea how orig files got there... If Ondřej applied any patches before compiling, patch(1) program could leave them as backup copies. -- 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] Git Migration Status Update
+1, Thanks David! 2012/1/26 Paul Dragoonis dragoo...@gmail.com: Hi David, Thanks for the great push on the DVCS push to git. I believe I speak for many people when I say your hard work is really appreciated. Look forward to testing out the git installation. - Paul. On Wed, Jan 25, 2012 at 11:36 PM, David Soria Parra d...@php.net wrote: Hi Internals, we are a few weeks into the git migration, so I want to give you a short status update. - web/ is completly migrated. all php websites are updating from the git repositories now. Checkout http://git.php.net/ - We support SSH keys now. Go to http://master.php.net/manage/users.php and add your ssh key. The pull and push URL is g...@git.php.net:repo - We mirror to github. See http://github.com/php - Please test a lot and play around with the playground repository on http://git.php.net - We are working on minor changes to the karma script, etc. There are a few known bugs. Go ahead and test extensviley, so we get everything sorted before we move the main source repository. - There is an ongoing discussion about the format of the commit messages. At the moment we send out one mail with all changests that are pushed. Advantage: You see who pushed what chain of changests in on mail Disadvantage: You cannot filter mails based on the subject (e.g. ext/date) We can go ahead and send out mails for every commit only. We can go ahead and send out mails for both pushes and for every comit on it's own. ...more options. Please discuss how you want it. NOTE: there is also always an RSS feed for updates to a specific directory available on http://git.php.net - There is a GIT faq: http://wiki.php.net/vcs/gitfaq - Questions? David -- 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] Git Migration: An Update
AFAIK, git natively supports rsync protocol, see man git pull. 2011/12/15 Johannes Schlüter johan...@schlueters.de: On Thu, 2011-12-15 at 18:11 +0100, Hannes Magnusson wrote: 1. Compile a list of scripts/sites that need to be changed in order to work with the git repo. Some sites are already on the list: - http://ci.qa.php.net - http://snaps.php.net - http://edit.php.net - http://lxr.php.net rsync.. does something like cvsup or svnsync exist? :] Yes git clone (or git pull) ;-) johannes -- 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] 5.4 regression: non-existent sub-sub keys now have values
2011/11/24 de...@lucato.it:
On 24 November 2011 01:38, Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
But neither is introducing a potential bomb of the kind that the 'date'
saga
created. The problem this change IS causing is likely to hit many live
sites
The claim that many live sites actually regularly use string multiple string
offsets to distinguish strings from arrays sounds implausible to me.
Hi,
I hadn't the opportunity to install php 5.4 to test this, so I was
wondering if someone could test how would this code behave ?
Hi, Davis, first of all you can use this service:
http://codepad.viper-7.com/ to test your code against 5.2, 5.3, 5.4
and latest trunk.
###
if (
!isset( $widget_options['dashboard_incoming_links'] )
|| !isset( $widget_options['dashboard_incoming_links']['home'] )
|| $widget_options['dashboard_incoming_links']['home'] != get_option('home')
)
###
Is that correct saying that if the first condition is false the second
will always be true ?
Note: that's a piece of Wordpress
About your question if I understand it correctly: if
$widget_options['dashboard_incoming_links'] is not set, then
$widget_options['dashboard_incoming_links']['home'] can't be set in
any conditions.
Thank you
Devis
--
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] Re: Character lost while convert from cp936 to utf-8 using mb_convert_encoding
Well done! :) 2011/11/18 Laruence larue...@php.net: Hi: I have fixed the bug(it is a simple fix that I didn't expect before I look into it ), ignore me... thanks On Fri, Nov 18, 2011 at 1:09 PM, Laruence larue...@php.net wrote: Hi: I have filed a bug about this issue: https://bugs.php.net/bug.php?id=60306 following script: ? $s = 洪仁; var_dump(mb_convert_encoding($s, utf8, gbk)); var_dump(iconv(gbk, utf8, $s)); ? save the script in fenc=cp936 then, run the script in php5.4 , output is : string(3) 洪 string(6) 洪仁 characters lost while converting from cp936 to utf8. this is really a big problem. thanks -- Laruence Xinchen Hui http://www.laruence.com/ -- Laruence Xinchen Hui http://www.laruence.com/ -- 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] PHP CLI webserver test failures
2011/11/17 Ferenc Kovacs tyr...@gmail.com: \o/ You could also ask Alex Shein, he was volunteered to update the http tests to use our new embedded developer server instead. Hi, I'm still into that, but unfortunately is very busy at work :( server-tests.php is a big outdated mess, and I still want to write my own phpt parser from scratch. Klaus, if you wanna help, you'd better to fix failing cli server tests before improving code coverage. On Wed, Nov 16, 2011 at 9:15 PM, Klaus Silveira klaussilve...@php.net wrote: I'll try to help Laruence improve the test coverage. If you guys have any suggestion for test starting point, let me know. On Wed, Nov 16, 2011 at 5:41 PM, Christopher Jones christopher.jo...@oracle.com wrote: Hi Laruence, Is there anyway to make the PHP CLI webserver tests more resilient? They are failing on gcov.php.net and are high on the list of user test reports: http://gcov.php.net/viewer.**php?version=PHP_HEADfunc=**testshttp://gcov.php.net/viewer.php?version=PHP_HEADfunc=tests http://qa.php.net/reports/?**version=5.4.0RC2-devhttp://qa.php.net/reports/?version=5.4.0RC2-dev Chris -- Email: christopher.jo...@oracle.com Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Ferenc Kovács @Tyr43l - http://tyrael.hu -- Regards, Shein Alexey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP CLI webserver test failures
2011/11/17 Ferenc Kovacs tyr...@gmail.com: On Wed, Nov 16, 2011 at 9:31 PM, Alexey Shein con...@gmail.com wrote: 2011/11/17 Ferenc Kovacs tyr...@gmail.com: \o/ You could also ask Alex Shein, he was volunteered to update the http tests to use our new embedded developer server instead. Hi, I'm still into that, but unfortunately is very busy at work :( server-tests.php is a big outdated mess, and I still want to write my own phpt parser from scratch. I would be also interested that (for run-tests.php), so if you have anything ping me Did you check the wiki about that? There are ideas laying around there, and there were even a effort to rewrite run-tests.php: https://wiki.php.net/qa/runtests/documentation Hm, nice catch, will definitely check that out. I was only refering to phpt spec here: http://qa.php.net/phpt_details.php phpruntests seems to had a better OOPish architechture, and it seems that it supported parallel test execution. Is there any code to see? Or just architecture in the wiki? I think that it would be a good think to first document the current behavior, use cases, and create a decoupled toolchain for running the testsuite. -- Ferenc Kovács @Tyr43l - http://tyrael.hu -- Regards, Shein Alexey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP CLI webserver test failures
2011/11/17 Christopher Jones christopher.jo...@oracle.com: On 11/16/2011 01:09 PM, Alexey Shein wrote: 2011/11/17 Ferenc Kovacstyr...@gmail.com: On Wed, Nov 16, 2011 at 9:31 PM, Alexey Sheincon...@gmail.com wrote: 2011/11/17 Ferenc Kovacstyr...@gmail.com: \o/ You could also ask Alex Shein, he was volunteered to update the http tests to use our new embedded developer server instead. Hi, I'm still into that, but unfortunately is very busy at work :( server-tests.php is a big outdated mess, and I still want to write my own phpt parser from scratch. I would be also interested that (for run-tests.php), so if you have anything ping me Did you check the wiki about that? There are ideas laying around there, and there were even a effort to rewrite run-tests.php: https://wiki.php.net/qa/runtests/documentation Hm, nice catch, will definitely check that out. I was only refering to phpt spec here: http://qa.php.net/phpt_details.php phpruntests seems to had a better OOPish architechture, and it seems that it supported parallel test execution. Is there any code to see? Or just architecture in the wiki? http://svn.php.net/viewvc/php/phpruntests/trunk/ For some background, there might be some posts on Zoe's blog e.g: http://zoomsplatter.blogspot.com/2009/07/on-no-not-more-tests.html Thanks. Chris -- Email: christopher.jo...@oracle.com Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ -- Regards, Shein Alexey -- 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] Running mhash tests
It's very strange but after 5-6 recompiles with different configurations (I tried to reduce breaking setup) my current configuration started to work itself. Thanks everybody for help. 2011/9/15 Scott MacVicar sc...@macvicar.net: On 14 Sep 2011, at 13:46, Alexey Shein wrote: 2011/9/15 Pierre Joye pierre@gmail.com: hi, On Wed, Sep 14, 2011 at 9:58 PM, Alexey Shein con...@gmail.com wrote: Should we delete these tests (and, maybe deprecate/move to pecl the extension itself)? I don't think we should, they are here to make sure that the emulation layer works fine. If not, I'd like to know how to run these tests. Maybe the skipif is wrong, as far as I remember there was an issue with seeing the mhash layer as being the mhash extension. Maybe we should change the skipif and uses function_exists instead? Have you tried it? They both return false for me: conf@laptop ~/php-src/trunk $ sapi/cli/php -r 'var_dump(extension_loaded(mhash), function_exists(mhash));' bool(false) bool(false) conf@laptop ~/php-src/trunk $ Definitely works for me on latest trunk. Does a shorter configure fix this? I wonder if something elsewhere is breaking this. macvicar-mba:trunk macvicar$ cat config.nice #! /bin/sh # # Created by configure './configure' \ '--disable-all' \ '--with-mhash' \ $@ macvicar-mba:trunk macvicar$ sapi/cli/php -m [PHP Modules] Core date ereg hash mhash pcre Reflection SPL standard [Zend Modules] macvicar-mba:trunk macvicar$ sapi/cli/php -r 'var_dump(extension_loaded(mhash));' bool(true) -- 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/13 Ferenc Kovacs tyr...@gmail.com: On Tue, Sep 13, 2011 at 6:23 PM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! On 9/13/11 7:49 AM, Ferenc Kovacs wrote: Stas, I still don't know why do have a custom php.ini, and why is it used. The make test should create tmp-php.ini for you (and copy your Everybody has custom php.ini, what do you mean why? Nobody uses just defaults. It is used because -n -c is not passed when you run run-tests. not everybody, but I guess you are right that most people has a system wide php installed with a custom php.ini on the machine that runs the test suite. to name an exception: I have a dedicate vm for building php and running the tests, and there is no system wide php installed there, hence no custom php.ini. as I mentioned before, make test (at least it should) passes the -n -c argument to run-tests.php see http://svn.php.net/viewvc/php/php-src/trunk/Makefile.global?view=markup#l104 which means if you run make test that can produce different result, than simply running run-tests.php Why do we even have this tmp-php.ini? Why not just make test without any .ini files, i.e. just with -n option? additional ini files there if you passed --with-config-file-scan-dir for the build) and pass -n -c tmp-php.ini as an argument to the invidual tests. That is not what I see happening. I've already sent you the actual command line, there's no -n and -c there. And I already mentioned and pointed out, that make test should pass those, the test target in the Makefile is pretty straightforward, so I can't see how can your make test not pass -n -c tmp-php.ini For the record, before our discussion I wasn't aware that the tmp-php.ini built by the make test can have random values(through --with-config-file-scan-dir) and I expected that most of the test results are generated through make test. Now knowing this, I now understand that theoretically each test should define every --INI-- value (except those set on http://svn.php.net/viewvc/php/php-src/trunk/run-tests.php?view=markup#l224 ) which could influence the result of the test. Even stuff like memory_limit, as I could have a custom php.ini with memory_limit=1 I'm pretty sure that I could screw up 99% of test results with a properly adjusted php.ini. I think that it would be a good idea to set up some baseline(or extend http://svn.php.net/viewvc/php/php-src/trunk/run-tests.php?view=markup#l224 ) php.ini for the test suite, otherwise we will test not the testsuite but the configuration. (somebody mentioned that it is intentional, but I think it is a bad practice) -- Ferenc Kovács @Tyr43l - http://tyrael.hu -- 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/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? -- Ferenc Kovács @Tyr43l - http://tyrael.hu -- Regards, Shein Alexey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Running mhash tests
Hello, I tried to run skipped mhash tests in ext/hash, these ones in trunk: SKIP mhash() test [ext/hash/tests/mhash_001.phpt] reason: mhash extension is not available SKIP mhash_get_block_size() mhash_get_hash_name() test [ext/hash/tests/mhash_002.phpt] reason: mhash extension is not available SKIP mhash_keygen_s2k() test [ext/hash/tests/mhash_003.phpt] reason: mhash extension is not available SKIP mhash() modifying algorithm parameter [ext/hash/tests/mhash_004.phpt] reason: mhash extension is not available My configure line: './configure' '--with-bz2' '--enable-bcmath' '--with-apxs2=/usr/bin/apxs2' '--with-gd' '--enable-calendar' '--enable-gd-native-ttf' '--with-freetype-dir' '--with-jpeg-dir' '--with-png-dir' '--enable-exif' '--with-mysql' '--with-zlib' '--with-gettext' '--with-mcrypt' '--with-ldap' '--with-iconv' '--enable-sockets' '--with-openssl' '--with-imap' '--with-imap-ssl' '--with-kerberos' '--with-pspell' '--with-pdo-mysql' '--with-pdo-sqlite' '--enable-soap' '--enable-xmlreader' '--with-xsl' '--enable-ftp' '--enable-cgi' '--with-curl' '--with-tidy' '--with-xmlrpc' '--enable-mbstring' '--enable-sysvsem' '--enable-sysvshm' '--enable-sysvmsg' '--enable-shmop' '--with-readline' '--with-mysqli' '--enable-zip' '--enable-wddx' '--enable-pdo' '--with-pdo-firebird' '--with-interbase' '--with-enchant' '--enable-intl' '--with-mhash' So, as you see, I actually have --with-mhash in the end and don't have --disable-hash, so usual hash tests pass correctly. From the docs (http://www.php.net/manual/en/mhash.installation.php) I've found out that mhash is now emulated by hash extension and is actually obsoleted. Should we delete these tests (and, maybe deprecate/move to pecl the extension itself)? If not, I'd like to know how to run these tests. Thank you. -- Regards, Shein Alexey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Running mhash tests
2011/9/15 Pierre Joye pierre@gmail.com: hi, On Wed, Sep 14, 2011 at 9:58 PM, Alexey Shein con...@gmail.com wrote: Should we delete these tests (and, maybe deprecate/move to pecl the extension itself)? I don't think we should, they are here to make sure that the emulation layer works fine. If not, I'd like to know how to run these tests. Maybe the skipif is wrong, as far as I remember there was an issue with seeing the mhash layer as being the mhash extension. Maybe we should change the skipif and uses function_exists instead? Have you tried it? They both return false for me: conf@laptop ~/php-src/trunk $ sapi/cli/php -r 'var_dump(extension_loaded(mhash), function_exists(mhash));' bool(false) bool(false) conf@laptop ~/php-src/trunk $ -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- 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
Just wanted to say, that I managed to reproduce your results for ./PHP_5_4/ext/session/tests/rfc1867_invalid_settings.phpt by adding date.timezone=UTC error_log=file settings into --INI-- section, this way test passes. I.e. logged message should go into the file and do not mess the output which is grabbed by the test and date.timezone setting prevents another startup warning about unconfigured timezone. Hope it helps. 2011/9/12 Ferenc Kovacs tyr...@gmail.com: I forget to reply-all to the list :/ On Mon, Sep 12, 2011 at 7:46 PM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! On 9/12/11 3:14 AM, Ferenc Kovacs wrote: you should pass both -n and -c as the make test pass those to the run-tests.php AFAIK, see: That's not what I see happening. as I mentioned above, you should have the -n -c arguments, if you don't then this can cause the differencies. That's not what I see run-tests is doing. what do you mean by my php.ini? for the test runs you shouldn't use any external php.ini, as it can cause differences between the test results. Maybe it shouldn't, but that's what happens. It doesn't use neither -c nor -n option. before we continue further with debugging, could someone else verify my reasoning, or repeat the those test steps? I'm pretty sure that the make test/run-test.php should run the tests without any external php.inis except the tmp-php.ini (passing -n -c tmp-php.ini). it is a possibility that Stas somehow borked up his environment, but as the gcov machine also generated the same output (at least for those session tests) I would like to know that what causes this different behavior for Stas and me, and which is the correct. thanks. -- Ferenc Kovács @Tyr43l - http://tyrael.hu -- 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] 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
Hello, these tests fail for me too, ubuntu 11.04 x86, both trunk and 5.4 branches. 2011/9/12 Ferenc Kovacs tyr...@gmail.com: On Sun, Sep 11, 2011 at 11:04 PM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! On 9/11/11 8:44 AM, Ferenc Kovacs wrote: AFAIK you shoud get it(as I did on my debian machines), as both display_startup_errors and error_reporting is force enabled for the tests: http://svn.php.net/viewvc/php/php-src/trunk/run-tests.php?view=markup#l232 http://svn.php.net/viewvc/php/php-src/trunk/run-tests.php?view=markup#l230 Well, maybe I should, but I am not. If you think it's a bug and have a fix you're welcome to propose it. I did, and you just reverted it, this is why I'm curious. :) could you please run the following (basically running those 2 tests with verbose output): TEST_PHP_EXECUTABLE=auto TEST_PHP_CGI_EXECUTABLE=auto ./sapi/cli/php run-tests.php -g 'SKIP,FAIL,XFAIL' -n -c tmp-php.ini -v ext/session/tests/rfc1867_invalid_settings*.phpt I would like to know how does your COMMAND look like. mine is something like: /home/tyrael/checkouts/php-src/trunk/sapi/cli/php -n -c 'tmp-php.ini' -d output_handler= -d open_basedir= -d safe_mode=0 -d disable_functions= -d output_buffering=Off -d error_reporting=32767 -d display_errors=1 -d display_startup_errors=1 -d log_errors=0 -d html_errors=0 -d track_errors=1 -d report_memleaks=1 -d report_zend_debug=0 -d docref_root= -d docref_ext=.html -d error_prepend_string= -d error_append_string= -d auto_prepend_file= -d auto_append_file= -d magic_quotes_runtime=0 -d ignore_repeated_errors=0 -d precision=14 -d unicode.runtime_encoding=ISO-8859-1 -d unicode.script_encoding=UTF-8 -d unicode.output_encoding=UTF-8 -d unicode.from_error_mode=U_INVALID_SUBSTITUTE -d session.auto_start=0 -d tidy.clean_output=0 -d zlib.output_compression=Off -d mbstring.func_overload=0 -d session.upload_progress.freq=-1 -f /home/tyrael/checkouts/php-src/trunk/ext/session/tests/rfc1867_invalid_settings.php 21 and the second thing: could you run the following: ./sapi/cli/php -n -d session.upload_progress.freq=200% -d error_reporting=-1 -d display_errors=1 -d display_startup_errors=1 -r '' this outputs for me: PHP Warning: PHP Startup: session.upload_progress.freq cannot be over 100% in Unknown on line 0 Warning: PHP Startup: session.upload_progress.freq cannot be over 100% in Unknown on line 0 I verified this with multiple php version on multiple machines, if you have both display_errors and display_startup_errors (and appropriate error_reporting level), you should see those two lines. btw: you can see from the reports that others also seeing this behaviour: http://qa.php.net/reports/viewreports.php?version=5.4.0beta1-devtest=%2Fext%2Fsession%2Ftests%2Frfc1867_invalid_settings.phpt http://qa.php.net/reports/viewreports.php?version=5.4.0beta1-devtest=%2Fext%2Fsession%2Ftests%2Frfc1867_invalid_settings_2.phpt -- Ferenc Kovács @Tyr43l - http://tyrael.hu -- 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] Using source code ...
Hello, Lester, try to start from scratch by running ./vcsclean first, often it helps to solve all cache issues from previous builds. 2011/9/9 Lester Caine les...@lsces.co.uk: I probably need to roll back a bit further, but I already have the current hg cone of php-src on the main repo here, so I've cloned a PHP5.3 and PHP5.4 from it to work on from my SUSE11.3 machine. This is a gash development machine so I can screw up the PHP to my harts content ;) Added autoconf2.13 to get ./buildconf running, and I'm in the 5.3 copy but I'm getting 'suspicious cache-id, must contain _cv_ to be cached' against the pdo drivers including php_firebird which is exactly where I want to work. Do I need to download all of this from SVN or am I simply missing something? A quick check seems to point to the _cv_ being a PHP5.4 change? -- 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 -- Regards, Shein Alexey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Running PDO tests ....
2011/9/9 Christopher Jones christopher.jo...@oracle.com: On 09/09/2011 10:02 AM, Lester Caine wrote: I'm not having much luck running the pdo_firebird tests ... I've got as far as building with ./configure --disable-all --with-interbase=/opt/fb25cs --enable-pdo --with-pdo-firebird=/opt/fb25cs --with-sqlite3 --with-pdo-sqlite Having first tried JUST the pdo_firebird driver, but the test are still being skipped, because there is no driver. What am I missing here? Triple-check everything from the start: - Any configure errors about unrecognized options? - Is there any configure message about firebird? - What does 'php -m' show? - are you running 'make test TESTS=pdo_firebird' ? Actually, it should be 'make test TESTS=ext/pdo_firebird' - if not, are you using the right php binary? - does a simple script work? -- Email: christopher.jo...@oracle.com Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ -- 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] [PATCH] Autoguessing TEST_PHP_EXECUTABLE if none is provided in run-tests.php
2011/9/9 Christopher Jones christopher.jo...@oracle.com:
On 09/08/2011 05:07 AM, Alexey Shein wrote:
Hello!
I've made some improvements to run-tests.php:
1) Autoguessing TEST_PHP_EXECUTABLE and TEST_PHP_CGI_EXECUTABLE if
they're not provided, i.e. assume they have value 'auto'. You can
still pass your own value as usual.
2) Added option -n (use no php.ini) to the shebang line
(#!/usr/bin/php -n) so it would run more reliably on some hosts. My
Ubuntu setup did not have E letter in variables_order (i.e.
variables_order=GPCS) so $_ENV array was empty and some tests were
skipped when they could be run.
3) Some better error handling of wrong paths
So now you can run run-tests.php with just
$ ./run-tests.php ext
instead of
$ TEST_PHP_EXECUTABLE=auto php -n run-tests.php ext
You can also run run-tests.php from sub-dir, it will correctly guess
'auto' as well:
$ cd ext/
$ ../run-tests.php zlib
Please, review this patch and, if there's no objections, I will
prepare 5.4 and 5.3 versions too.
I don't have a problem with the intent to make it easier and more
failsafe. In particular I'm +1 on autoguessing, which might be a
marginally contentious change for some developers.
A few of us build PHP outside the svn source tree. The following
modification to your patch fixes the intended autodetection in this
scenario:
if ($php == 'auto') {
$php = realpath($CUR_DIR . '/sapi/cli/php');
if (!$php) {
$php = realpath(__DIR__ . '/sapi/cli/php');
}
putenv(TEST_PHP_EXECUTABLE=$php);
}
$environment['TEST_PHP_EXECUTABLE'] = $php;
It allows the following to work for me:
cd ~/phpbuild
./sapi/cli/php -n ~/phpsrc/php/php-src/branches/PHP_5_4/run-tests.php
/tmp/array_bind_001.phpt
Since run-tests.php is kept in sync on all branches, you'll only need
one version of the patch.
So you mean to check sapi/cli/php in the current dir first and, if not
found, further in the directory related to run-tests.php (PHP_5_4 in
your example). Ok, that makes sense, usual running from svn tree will
not be changed.
Chris
--
Email: christopher.jo...@oracle.com
Tel: +1 650 506 8630
Blog: http://blogs.oracle.com/opal/
--
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] Using source code ...
Hello, Lester, I've managed to setup pdo_firebird, here's the process for the ubuntu if you're interested: 1) setup firebird superclassic: $ sudo apt-get install firebird2.5-superclassic firebird2.5-dev firebird2.5-examples superclassic is the server itself, dev package contains headers to compile pdo stuff, examples contains example db, i used it to run tests in it. Set up credentials for the server (see the link lower). Get employee.fdb as written here http://www.firebirdsql.org/manual/ubusetup.html to a some known and writable path by your user (which tests will be run on). 2) compile php with following flags, you'll need interbase too (some tests in pdo_firebird/tests need it) ./configure --disable-all --enable-pdo --with-pdo-firebird --with-interbase make 3) Run tests with environment variables that can be found in ext/pdo_firebird/tests/common.phpt, I ran it like this: $ PDO_FIREBIRD_TEST_DSN='firebird:dbname=/var/lib/firebird/2.5/data/employee.fdb' PDO_FIREBIRD_TEST_USER='SYSDBA' PDO_FIREBIRD_TEST_PASS='masterkey' TEST_PHP_EXECUTABLE=auto php -n ./run-tests.php ext/pdo_firebird Tests run very slowly and mostly (if not all) fail. You will get something like this: conf@laptop ~/php-src/trunk $ PDO_FIREBIRD_TEST_DSN='firebird:dbname=/var/lib/firebird/2.5/data/employee.fdb' PDO_FIREBIRD_TEST_USER='SYSDBA' PDO_FIREBIRD_TEST_PASS='masterkey' ./run-tests.php ext/pdo_firebird = PHP : /home/conf/php-src/trunk/sapi/cli/php PHP_SAPI: cli PHP_VERSION : 5.5.0-dev ZEND_VERSION: 2.4.0 PHP_OS : Linux - Linux laptop 2.6.38-11-generic #48-Ubuntu SMP Fri Jul 29 19:02:55 UTC 2011 x86_64 INI actual : /home/conf/php-src/trunk More .INIs : - PHP : /home/conf/php-src/trunk/sapi/cgi/php-cgi PHP_SAPI: cgi-fcgi PHP_VERSION : 5.5.0-dev ZEND_VERSION: 2.4.0 PHP_OS : Linux - Linux laptop 2.6.38-11-generic #48-Ubuntu SMP Fri Jul 29 19:02:55 UTC 2011 x86_64 INI actual : /home/conf/php-src/trunk More .INIs : - CWD : /home/conf/php-src/trunk Extra dirs : VALGRIND: Not used = Running selected tests. --- ext/pdo/tests (FIREBIRD [ext/pdo_firebird/tests/common.phpt]) begin PASS FIREBIRD Bug #47769 (Strange extends PDO) [ext/pdo_firebird/tests/bug47769.phpt] FAIL FIREBIRD PDO Common: Bug #34630 (inserting streams as LOBs) [ext/pdo_firebird/tests/bug_34630.phpt] PASS FIREBIRD PDO Common: Bug #34687 (query doesn't return error information) [ext/pdo_firebird/tests/bug_34687.phpt] FAIL FIREBIRD PDO Common: Bug #35671 (binding by name breakage) [ext/pdo_firebird/tests/bug_35671.phpt] PASS FIREBIRD PDO Common: Bug #36428 (Incorrect error message for PDO::fetchAll()) [ext/pdo_firebird/tests/bug_36428.phpt] FAIL FIREBIRD PDO Common: Bug #36798 (Error parsing named parameters with queries containing high-ascii chars) [ext/pdo_firebird/tests/bug_36798.phpt] FAIL FIREBIRD PDO Common: Bug #38253 (PDO produces segfault with default fetch mode) [ext/pdo_firebird/tests/bug_38253.phpt] FAIL FIREBIRD PDO Common: Bug #38394 (Prepared statement error stops subsequent statements) [ext/pdo_firebird/tests/bug_38394.phpt] FAIL FIREBIRD PDO Common: Bug #39398 (Booleans are not automatically translated to integers) [ext/pdo_firebird/tests/bug_39398.phpt] FAIL FIREBIRD PDO Common: Bug #39656 (Crash when calling fetch() on a PDO statment object after closeCursor()) [ext/pdo_firebird/tests/bug_39656.phpt] FAIL FIREBIRD PDO Common: Bug #40285 (The prepare parser goes into an infinite loop on ': or :) [ext/pdo_firebird/tests/bug_40285.phpt] FAIL FIREBIRD PDO Common: Bug #42917 (PDO::FETCH_KEY_PAIR doesn't work with setFetchMode) [ext/pdo_firebird/tests/bug_42917.phpt] FAIL FIREBIRD PDO Common: Bug #43130 (Bound parameters cannot have - in their name) [ext/pdo_firebird/tests/bug_43130.phpt] FAIL FIREBIRD PDO Common: Bug #43139 (PDO ignore ATTR_DEFAULT_FETCH_MODE in some cases with fetchAll()) [ext/pdo_firebird/tests/bug_43139.phpt] PASS FIREBIRD PDO Common: Bug #43663 (__call on classes derived from PDO) [ext/pdo_firebird/tests/bug_43663.phpt] PASS FIREBIRD Bug #44159 (Crash: $pdo-setAttribute(PDO::STATEMENT_ATTR_CLASS, NULL)) [ext/pdo_firebird/tests/bug_44159.phpt] FAIL FIREBIRD PDO Common: Bug #44173 (PDO-query() parameter parsing/checking needs an update) [ext/pdo_firebird/tests/bug_44173.phpt] FAIL FIREBIRD PDO Common: Bug #44409 (PDO::FETCH_SERIALIZE calls __construct()) [ext/pdo_firebird/tests/bug_44409.phpt] SKIP FIREBIRD PDO Common: Bug #44861 (scrollable cursor don't work with pgsql) [ext/pdo_firebird/tests/bug_44861.phpt] reason: Scrollable cursors not supported FAIL FIREBIRD PDO Common: Bug #50458 (PDO::FETCH_FUNC fails with Closures) [ext/pdo_firebird/tests/bug_50458.phpt] FAIL FIREBIRD PDO Common: PDO::FETCH_ASSOC
[PHP-DEV] [PATCH] Autoguessing TEST_PHP_EXECUTABLE if none is provided in run-tests.php
Hello!
I've made some improvements to run-tests.php:
1) Autoguessing TEST_PHP_EXECUTABLE and TEST_PHP_CGI_EXECUTABLE if
they're not provided, i.e. assume they have value 'auto'. You can
still pass your own value as usual.
2) Added option -n (use no php.ini) to the shebang line
(#!/usr/bin/php -n) so it would run more reliably on some hosts. My
Ubuntu setup did not have E letter in variables_order (i.e.
variables_order=GPCS) so $_ENV array was empty and some tests were
skipped when they could be run.
3) Some better error handling of wrong paths
So now you can run run-tests.php with just
$ ./run-tests.php ext
instead of
$ TEST_PHP_EXECUTABLE=auto php -n run-tests.php ext
You can also run run-tests.php from sub-dir, it will correctly guess
'auto' as well:
$ cd ext/
$ ../run-tests.php zlib
Please, review this patch and, if there's no objections, I will
prepare 5.4 and 5.3 versions too.
--
Regards,
Shein Alexey
Index: run-tests.php
===
--- run-tests.php (revision 316410)
+++ run-tests.php (working copy)
@@ -1,4 +1,4 @@
-#!/usr/bin/php
+#!/usr/bin/php -n
?php
/*
+--+
@@ -143,55 +143,40 @@
$environment[SystemRoot] = getenv(SystemRoot);
}
-// Don't ever guess at the PHP executable location.
-// Require the explicit specification.
-// Otherwise we could end up testing the wrong file!
+// Try to guess PHP executable location if env variable is not provided,
assume it to be 'auto'.
-$php = null;
-$php_cgi = null;
+$php = getenv('TEST_PHP_EXECUTABLE') ? getenv('TEST_PHP_EXECUTABLE') : 'auto';
+$php_cgi = getenv('TEST_PHP_CGI_EXECUTABLE') ?
getenv('TEST_PHP_CGI_EXECUTABLE') : 'auto';
-if (getenv('TEST_PHP_EXECUTABLE')) {
- $php = getenv('TEST_PHP_EXECUTABLE');
-
- if ($php=='auto') {
- $php = $cwd . '/sapi/cli/php';
- putenv(TEST_PHP_EXECUTABLE=$php);
-
- if (!getenv('TEST_PHP_CGI_EXECUTABLE')) {
- $php_cgi = $cwd . '/sapi/cgi/php-cgi';
-
- if (file_exists($php_cgi)) {
- putenv(TEST_PHP_CGI_EXECUTABLE=$php_cgi);
- } else {
- $php_cgi = null;
- }
- }
- }
- $environment['TEST_PHP_EXECUTABLE'] = $php;
+if ($php == 'auto') {
+ $php = realpath(__DIR__ . '/sapi/cli/php');
+ putenv(TEST_PHP_EXECUTABLE=$php);
}
+$environment['TEST_PHP_EXECUTABLE'] = $php;
-if (getenv('TEST_PHP_CGI_EXECUTABLE')) {
- $php_cgi = getenv('TEST_PHP_CGI_EXECUTABLE');
-
- if ($php_cgi=='auto') {
- $php_cgi = $cwd . '/sapi/cgi/php-cgi';
- putenv(TEST_PHP_CGI_EXECUTABLE=$php_cgi);
- }
-
- $environment['TEST_PHP_CGI_EXECUTABLE'] = $php_cgi;
+if ($php_cgi == 'auto') {
+ $php_cgi = realpath(__DIR__ . '/sapi/cgi/php-cgi');
+ putenv(TEST_PHP_CGI_EXECUTABLE=$php_cgi);
}
+$environment['TEST_PHP_CGI_EXECUTABLE'] = $php_cgi;
function verify_config()
{
- global $php;
+ global $php, $php_cgi;
- if (empty($php) || !file_exists($php)) {
+ if (empty($php) || !is_file($php)) {
error('environment variable TEST_PHP_EXECUTABLE must be set to
specify PHP executable!');
}
if (function_exists('is_executable') !is_executable($php)) {
error(invalid PHP executable specified by TEST_PHP_EXECUTABLE
= $php);
}
+
+ if (!empty($php_cgi)) {
+ if (!is_file($php_cgi) || (function_exists('is_executable')
!is_executable($php_cgi))) {
+ error(invalid PHP-CGI executable specified by
TEST_PHP_CGI_EXECUTABLE = $php_cgi);
+ }
+ }
}
if (getenv('TEST_PHP_LOG_FORMAT')) {
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
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=revisionrevision=312110. Maybe PHP_5_3 branch should be changed accordingly? 2011/9/4 Stas Malyshev smalys...@sugarcrm.com: Hi! On 9/2/11 6:10 PM, Ferenc Kovacs wrote: http://svn.php.net/viewvc?view=revisionrevision=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] New run-tests.php feature
2011/9/1 Ferenc Kovacs tyr...@gmail.com: On Thu, Sep 1, 2011 at 1:35 PM, Hannes Magnusson bj...@php.net wrote: Throw qa and internals@ into the loop to. I'd also like to move the XFAIL section (printed out in the end) above the FAIL section. We have bucketloads of xfailed tests, I actually have to scroll up to see the failed tests which is really annoying and silly. Anyone have strong opinion on the printout order? yeah, strongly agree Great addition. While you're at it, could you also add an option to print a list of skipped tests (maybe above XFAIL section), that's also currently can't be done with other options in run-tests.php. It could also be useful because some skipped tests maybe skipped for the wrong reason and be actually failed. It's also a great spot to notice obsolete tests that need to be removed from the suite and make running all process faster. -- Regards, Shein Alexey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.3.8 Released!
2011/8/24 Ferenc Kovacs tyr...@gmail.com: 2011/8/24 Johannes Schlüter johan...@schlueters.de: On Wed, 2011-08-24 at 12:24 +0200, Ferenc Kovacs wrote: we could have spotted this via two ways: - those who participated in fixing https://bugs.php.net/bug.php?id=53727 could have spotted this - our tests should have start failing after the change Third option: - RC testers might have spotted and reported it. I have the impression that very few people actually test these. When creating an RC we inform the primary testers as well as qa and internals list members. From there I get one or two responses in general. When I approach PHP users I often get answers like installing PHP without breaking their setup would be complicated (which is not the case but maybe needs education?) and they won't have time. I try to use a hypothetical case, like we have here in reality, to explain them why it is beneficial for their business if it is detected early as then we can fix it, fixing something after a release is hard. We also can try to improve our tests but we will never be able to test each and every way PHP is being used out there in the wild. So how can we motivate people to test new versions during RC not the day after it is being released? We don't push them out as news on the php.net frontpage and we don't send it out to the announce list for reasons like not confusing users. Should we change that? Other ideas? johannes agree, should have mentioned that. I think that currently testing the RCs have a very high barrier. usually they are going unnoticed for most people and compiling your own version (with all the extensions that you need) can be really cumbersome. - we need to get out the word to the masses (the current php.net site simply lacks this, maybe the http://prototype.php.net/ will be better in this regard), for which we also need to lower the barriers to entry: - better documentation about how to build your own php version would be a must, maybe phpfarm can be also useful for this I would really glad to have a script that will be eager to enable as much modules as it can find on my machine (plus enable debug flags as --enable-zts-maintainer and such) and even offer to install some missing dependencies from OS packages (I'm on ubuntu so it's easy to do some apt-get/yum install if you know what are you for). For now you have to read quite a long list of configure options and then install their dependencies which are quite non-obvious to find out. - we should cooperate with the major php projects out there to run their testsuites against the new releases or maybe even trunk, if I remember correctly somebody mentioned that we already do this for some projects (maybe Pierre mentioned this). this would be an easy way to boost our test coverage and make the BC breaks more obvious. - having pre-packaged versions of php available would also help, testing out the latest mysql versions are much more easy for example, as I can just grab the Linux - Generic archive, extract it, and voila, I can test it. - projects like http://apt.damz.org/ also help -- Ferenc Kovács @Tyr43l - http://tyrael.hu -- 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] Add \Countable support to \Closure
I think it's just a bad habit inherited from Javascript, where you can
do like this:
var a = function(a, b) { };
alert(a.length); // shows 2
I don't think that PHP needs it, explicit method is way better.
2011/8/8 Sebastian Bergmann sebast...@php.net:
On 08/08/2011 04:49 AM, Etienne Kneuss wrote:
I don't believe Countable implies ArrayAccess, but I do think that
Countable should only be implemented in cases where it is obvious what
it will return, for example collections.
In this case, count(Closure) is really not that explicit, I'd rather
have an explicit method.
ACK
--
Sebastian Bergmann Co-Founder and Principal Consultant
http://sebastian-bergmann.de/ http://thePHP.cc/
--
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] [PATCH] getimagesize - return named keys for width, height, type and attributes
2011/7/12 Michael Wallner m...@php.net: On Mon, 11 Jul 2011 22:33:31 +0100, Paul Dixon wrote: personally long term, I would aim to remove the position index entries completely. Which would make it unusable with list(). +1 this will be huge BC break for this function. Please, don't remove position indexes. -- 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] preg_match
2011/7/8 Rafael Dohms lis...@rafaeldohms.com.br:
Still, this is preg_match it only returns one match, why should i get
a array and have to use ugly things like $matches[0] afterwards?
It just makes for very ugly syntax and extra code, a simple function
would make this cleaner and more intuitive, first time using
preg_match is a nightmare.
You forget about subpatterns, so array can contain more than 1 value:
php preg_match('/p(hp)/', 'php', $matches); var_dump($matches);
array(2) {
[0]=
string(3) php
[1]=
string(2) hp
}
--
Rafael Dohms
PHP Evangelist and Community Leader
http://www.rafaeldohms.com.br
http://www.phpsp.org.br
--
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] [VOTE] voting rfc
Hi! Wouldn't it be better if wiki voting mechanism would be embedded in the page with rfc? Under the block Table of contents, for example. Just now green link Votes are open is not so noticeable, so having a chance to vote without leaving the page would better inspire people to take part in voting process. 2011/6/20 David Soria Parra d...@php.net: Hi Internals, we have been working on getting an rfc together on how to deal with votes on rfcs. We aim to provide a simple mechaism for votes while still maintaining freedom on how to do votes and how to work on rfcs. I want to move forward on the voting and release RFCs, so we can move forward on the 5.4 process. Therefore I call for votes on the voting RFC. The RFC can be found here: https://wiki.php.net/rfc/voting You can vote here: https://wiki.php.net/rfc/voting/vote Votes are open until Monday 27.06.2011. Thank you David -- 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] [VOTE] voting rfc
2011/6/21 Pierre Joye pierre@gmail.com: added a link to the vote page. It should be more clear now. Thank you. But why not just place doodle plugin in the bottom of the page with rfc? This will give some chances that people will read rfc till the end before voting. What's the idea behind keeping 2 separate pages for rfc and voting? On Tue, Jun 21, 2011 at 12:25 PM, Alexey Shein con...@gmail.com wrote: Hi! Wouldn't it be better if wiki voting mechanism would be embedded in the page with rfc? Under the block Table of contents, for example. Just now green link Votes are open is not so noticeable, so having a chance to vote without leaving the page would better inspire people to take part in voting process. 2011/6/20 David Soria Parra d...@php.net: Hi Internals, we have been working on getting an rfc together on how to deal with votes on rfcs. We aim to provide a simple mechaism for votes while still maintaining freedom on how to do votes and how to work on rfcs. I want to move forward on the voting and release RFCs, so we can move forward on the 5.4 process. Therefore I call for votes on the voting RFC. The RFC can be found here: https://wiki.php.net/rfc/voting You can vote here: https://wiki.php.net/rfc/voting/vote Votes are open until Monday 27.06.2011. Thank you David -- 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 -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- Regards, Shein Alexey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [IDEA/PRE-RFC] PHP Core Mentorship Program
Really great idea. I'd like to be a part of it (as a newcomer of course :)) 2011/6/10 David Coallier dav...@php.net: Hey all, Let me start by saying that this is merely an idea I'm trying to put together and before doing so, I need to see who would be interested. A short while ago, the Python community created something called The Python Core Mentorship Program [1][2] which is essentially an attempt to lower the barrier of entry to the Python core for new developers, students, etc. and connect everyone together in a more cohesive manner where people actually talk and interact. I strongly believe in such initiative and believe this is something we should also think about. Simply put, I'd love to put something together for the PHP core/internals where the goals of the program would be, not unlike the Python project, to get a few internals (Zend Contribs (Stas are you reading this? :P), Core contribs, PECL extensions developers, documentation maintainers) to be willing to help newcomers and provide a more comprehensive understanding of the contribution processes, internal trickeries, optimisations, etc. The general idea is to create a channel between the rest of the world and the internals of PHP where more experienced developers can transfer their knowledge and get a fresh perspectives from new developers that haven't approached the core before. Before continuing further into exploring this idea, we need to get volunteer mentors. The mentee process is likely to get a self-managed one and the mentors' role will hopefully be rather low in terms of time consumptions and the roles of the mentor will most likely be: - Introducing new developers to the processes - Answering questions - Helping with code review of patches Again, like the Python program and similarly to the GSOC projects, we should have a mailing list (restricted) dedicated only to the mentor (php-mentorship?) where anyone can ask the simpler questions. From this mailing list we should also be able to construct a solid baseline for new developers contributing to PHP. From the mailing list, we'll see what questions are coming over and over again we'll be able to build a wiki-faq-like sections for new contributors. I digress and here's what I'm hoping to achieve with this email: I want to get a few contributors from various aspects of the core including docs and pecl extensions willing to help new people. If you are interested, please raise your voice and if enough interest is displayed I'll get a proper wiki section started. Furthermore, one thing I am hoping this program will help bring is not only a stronger interest in the core and a fresh injection of talent but more importantly I hope we'll be able to contributors from our various communities that are scattered across the internet that barely ever interact with the internals. Hoping this email reaches as many of you and that my message is properly conveyed :-) P.S. This is really an attempt to find volunteers. If you are interested please feel free to contact me directly if you prefer so we can start organising whatever would have to be done: dav...@php.net References: [1]: http://pythonmentors.com/ [2]: http://jessenoller.com/2011/03/25/just-proposed-python-core-mentorship-program/ -- David Coallier Orchestra.io -- 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] Callable type
2011/6/8 Hannes Magnusson hannes.magnus...@gmail.com: We have the situation in the docs that parameters declared as arrays do not follow the typehinting rules, but parameters as class names do. Re-using the callback from the docs could get confusing when extensions start to typehint on it, but not the core.. I think there is a subtle difference between a callback, and a callable. In javascript for example, callback is something that is executed on certain events onsuccess is the typical example. There is nothing that says the callable parameter gets executed as a part of an event, and I think the default usecase would be to execute it right away (f.e. filtering data). I think I would prefer callable, but I could live with either. Wikipedia defines callback as a reference to executable code, or a piece of executable code, that is passed as an argument to other code. So there's no event meaning put by default, it's just very often seen callback's usage in javascript. I just like callback term more :) -- Regards, Shein Alexey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Callable type
2011/6/8 David Zülke david.zue...@bitextender.com:
On 08.06.2011, at 00:38, dukeofgaming wrote:
On Tue, Jun 7, 2011 at 4:41 PM, Matthew Weier O'Phinney
weierophin...@php.net wrote:
On 2011-06-07, dukeofgaming dukeofgam...@gmail.com wrote:
+1 for callable, it is really more consistent.
I was actually agreeing With David and Stas that callback was more
consistent, and casting my vote for that.
Oh. But then, shouldn't is_callable be deprecated for a more consistently
named is_callback?
No, because is_callable() also performs visibility checks.
Which of course begs the question... should the type hint do the same?
David
+1 to callback (and have mercy on docs/translation people, it's too
much work to search/replace for such a minor difference :))
And yes, two similar terms (callback/callable) will make situation worse.
Plus to Johanness question: will it add runtime performance overhead
on code like this:
function(callback $callback = 'non_existent_function') {}
--
Regards,
Shein Alexey
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward)
2011/6/3 Derick Rethans der...@php.net: On Thu, 2 Jun 2011, Stas Malyshev wrote: I'd like to set up a vote for the undecided TODO features on wiki.php.net, anybody could help me with setting up the voting module there if there's such thing on the wiki? Or set me up with the access to wiki machine and I'll install it :) Voting on the wiki? Yuck. If you want participation, do it here on the mailinglist and store the record in the wiki. If all votes are showing up just in the wiki then there is no exposure on the list and things are easy to miss (especially with the huge amount of noise that's already on the list). Why not just to separate voting from participation? I doubt there is somebody that counts all these +1 in the list and tracks progress. I suggest keep voting only in wiki and discussions in ML. Don't have consice opinion yet? Participate ML. Got opinion? Go and vote in the wiki, no need to +1/-1 in the list, it's already too much noise here. Derick -- 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] Need karma for committing test patches
Greetings Alexey, I'm unable to provide useful comments for this patch, but am CCing the official ext/curl maintainer (Ilia) and you now have karma for committing tests. Thank you, Philip, for karma and for pushing that forward, I really appreciate that. -- Regards, Shein Alexey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Fwd: [PHP-DEV] Need karma for committing test patches
: curl_multi_exec(): CURLOPT_STDERR handle is incorrect in %s on line %d
+
+Warning: curl_multi_exec(): %d is not a valid stream resource in %s on line %d
+
+Warning: curl_multi_exec(): CURLOPT_STDERR handle is incorrect in %s on line %d
+%a
+Ok for CURLOPT_STDERR
+
+Warning: curl_multi_exec(): %d is not a valid stream resource in %s on line %d
+
+Warning: curl_multi_exec(): CURLOPT_WRITEHEADER handle is incorrect in %s on
line %d
+
+Warning: curl_multi_exec(): %d is not a valid stream resource in %s on line %d
+
+Warning: curl_multi_exec(): CURLOPT_WRITEHEADER handle is incorrect in %s on
line %d
+%AOk for CURLOPT_WRITEHEADER
+
+Warning: curl_multi_exec(): %d is not a valid stream resource in %s on line %d
+
+Warning: curl_multi_exec(): CURLOPT_FILE handle is incorrect in %s on line %d
+
+Warning: curl_multi_exec(): %d is not a valid stream resource in %s on line %d
+
+Warning: curl_multi_exec(): CURLOPT_FILE handle is incorrect in %s on line %d
+%a
+Ok for CURLOPT_FILE
+
+Warning: curl_multi_exec(): %d is not a valid stream resource in %s on line %d
+
+Warning: curl_multi_exec(): CURLOPT_INFILE handle is incorrect in %s on line %d
+
+Warning: curl_multi_exec(): %d is not a valid stream resource in %s on line %d
+
+Warning: curl_multi_exec(): CURLOPT_INFILE handle is incorrect in %s on line %d
+Ok for CURLOPT_INFILE
Index: trunk/ext/curl/tests/curl_file_deleted_before_curl_close.phpt
===
--- trunk/ext/curl/tests/curl_file_deleted_before_curl_close.phpt
(revision )
+++ trunk/ext/curl/tests/curl_file_deleted_before_curl_close.phpt
(revision )
@@ -0,0 +1,37 @@
+--TEST--
+Memory corruption error if fp of just created file is closed before curl_close.
+--CREDITS--
+Alexey Shein con...@gmail.com
+--SKIPIF--
+?php if (!extension_loaded(curl) || false ===
getenv('PHP_CURL_HTTP_REMOTE_SERVER')) print skip; ?
+--FILE--
+?php
+
+$ch = curl_init(getenv('PHP_CURL_HTTP_REMOTE_SERVER'));
+
+$temp_file = dirname(__FILE__) . '/curl_file_deleted_before_curl_close.tmp';
+if (file_exists($temp_file)) {
+ unlink($temp_file); // file should not exist before test
+}
+
+$handle = fopen($temp_file, 'w');
+
+curl_setopt($ch, CURLOPT_STDERR, $handle);
+curl_setopt($ch, CURLOPT_VERBOSE, 1);
+curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
+
+curl_exec($ch);
+
+fclose($handle); // causes glibc memory error
+
+//unlink($temp_file); // uncomment to test segfault (file not found on
iowrite.c)
+
+curl_close($ch);
+echo Closed correctly\n;
+?
+--CLEAN--
+?php
+unlink(dirname(__FILE__) . '/curl_file_deleted_before_curl_close.tmp');
+?
+--EXPECTF--
+Closed correctly
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Need karma for committing test patches
* I think a better strategy would be to just dup the file descriptor gotten
after the cast in curl_setopt, store it (instead of storing the zval) and
close it on curl handle destruction. This way we wouldn't have to worry
about zval refcounts or whether the file descriptor obtained is still valid.
Could you see if this other strategy works? (otherwise I can do it later
this week)
Ok, I made it to work (thanks for consultation to Pierre and
Johannes). You were right, the bug remains with curl_multi_exec too.
BTW it happens not only with CURL_STDERR but also with all other
options that take fp as a parameter (CURLOPT_FILE,
CURLOPT_WRITEHEADER, CURLOPT_INFILE) so I added them to the test and
made separate test for curl_multi_exec (see the patch).
After some thoughts I think this is the case when user really wants to
shoot into his leg - probably from user pov we should generate a
warning that we can't write into the supplied pointer (but actually we
can :)) like my previous patch did, but it raised a couple of
problems:
1) curl_multi_exec is called directly without interception from php
and create a wrapper just for this check seems like an overkill to me
2) we need to add 3 more checks to restore default values for all fp
options (see above) in two places: curl_exec and curl_multi_exec -
again overkill.
So I decided to go with this patch.
What do you think?
P.S. This patch is just againt trunk, if it's ok I will add 5.3 and
5.4 versions too.
--
Regards,
Shein Alexey
Index: trunk/ext/curl/php_curl.h
===
--- trunk/ext/curl/php_curl.h (revision 306938)
+++ trunk/ext/curl/php_curl.h (revision )
@@ -109,7 +109,7 @@
php_curl_write *write_header;
php_curl_read *read;
zval *passwd;
- zval *std_err;
+ FILE *std_err;
php_curl_progress *progress;
} php_curl_handlers;
Index: trunk/ext/curl/tests/bug48203.phpt
===
--- trunk/ext/curl/tests/bug48203.phpt (revision 281989)
+++ trunk/ext/curl/tests/bug48203.phpt (revision )
@@ -1,5 +1,5 @@
--TEST--
-Bug #48203 (Crash when CURLOPT_STDERR is set to regular file)
+Bug #48203 (Crash when file pointers passed to curl are closed before calling
curl_exec)
--SKIPIF--
?php
if (!extension_loaded(curl)) {
@@ -12,22 +12,43 @@
--FILE--
?php
+function checkForClosedFilePointer($curl_option, $description) {
-$fp = fopen(dirname(__FILE__) . '/bug48203.tmp', 'w');
+ $fp = fopen(dirname(__FILE__) . '/bug48203.tmp', 'w');
-$ch = curl_init();
+ $ch = curl_init();
+ // we also need CURLOPT_VERBOSE to be set to test CURLOPT_STDERR
properly
+ if (CURLOPT_STDERR == $curl_option) {
-curl_setopt($ch, CURLOPT_VERBOSE, 1);
+ curl_setopt($ch, CURLOPT_VERBOSE, 1);
-curl_setopt($ch, CURLOPT_STDERR, $fp);
-curl_setopt($ch, CURLOPT_URL, );
+ }
+ curl_setopt($ch, $curl_option, $fp);
+
+ curl_setopt($ch, CURLOPT_URL, getenv(PHP_CURL_HTTP_REMOTE_SERVER));
+ curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
+
-fclose($fp); // -- premature close of $fp caused a crash!
+ fclose($fp); // -- premature close of $fp caused a crash!
-curl_exec($ch);
+ curl_exec($ch);
-echo Ok\n;
+ curl_close($ch);
+ echo Ok for $description\n;
+}
+
+$options_to_check = array(
+ CURLOPT_STDERR, CURLOPT_WRITEHEADER, CURLOPT_FILE,
CURLOPT_INFILE
+);
+
+foreach($options_to_check as $option) {
+ checkForClosedFilePointer(constant($option), $option);
+}
+
?
--CLEAN--
?php @unlink(dirname(__FILE__) . '/bug48203.tmp'); ?
--EXPECT--
-Ok
+Ok for CURLOPT_STDERR
+Ok for CURLOPT_WRITEHEADER
+Ok for CURLOPT_FILE
+Ok for CURLOPT_INFILE
Index: trunk/ext/curl/interface.c
===
--- trunk/ext/curl/interface.c (revision 309881)
+++ trunk/ext/curl/interface.c (revision )
@@ -1810,7 +1810,10 @@
RETVAL_FALSE;
return 1;
}
-
+
+ // dup fp to be safe if user closes fp before calling
curl_exec
+ fp = fdopen(dup(fileno(fp)), ((php_stream *)
what)-mode);
+
error = CURLE_OK;
switch (option) {
case CURLOPT_FILE:
@@ -1845,11 +1848,7 @@
break;
case CURLOPT_STDERR:
if (((php_stream *) what)-mode[0] !=
'r' || ((php_stream *) what)-mode[1] == '+') {
- if (ch-handlers-std_err) {
-
zval_ptr_dtor(ch-handlers-std_err);
- }
-
Re: [PHP-DEV] Need karma for committing test patches
So what do you think should be done here? Check closed streams and reset them to default as in my first try? -- Regards, Shein Alexey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Need karma for committing test patches
I need karma to commit test fixes:
1) session_encode_basic - added serialize_precision=100 ini setting
2) fix for http://bugs.php.net/48203: there's a segfault when
CURLOPT_STDERR file pointer is closed before calling curl_exec, i.e.
like this:
$fp = fopen(dirname(__FILE__) . '/bug48203.tmp', 'w');
$ch = curl_init();
curl_setopt($ch, CURLOPT_VERBOSE, 1);
curl_setopt($ch, CURLOPT_STDERR, $fp);
curl_setopt($ch, CURLOPT_URL, getenv(PHP_CURL_HTTP_REMOTE_SERVER));
fclose($fp); // -- premature close of $fp caused a crash!
curl_exec($ch); // segfault
All tests run ok on php5.3 php5.4 and trunk.
Could somebody review this patch since I'm new to developing php and
could make some silly mistakes?
I already have an account: shein
--
Regards,
Shein Alexey
Index: trunk/ext/curl/interface.c
===
--- trunk/ext/curl/interface.c (revision 311121)
+++ trunk/ext/curl/interface.c (working copy)
@@ -2204,6 +2204,16 @@
ZEND_FETCH_RESOURCE(ch, php_curl *, zid, -1, le_curl_name, le_curl);
+ // check if custom std_err is not already closed
+ if (ch-handlers-std_err) {
+ php_stream *stream;
+
+ if (!(php_stream_from_zval_no_verify(stream,
ch-handlers-std_err))) {
+ php_error_docref(NULL TSRMLS_CC, E_WARNING, STDERR file handle
is incorrect);
+ curl_easy_setopt(ch-cp, CURLOPT_STDERR, stderr);
+ }
+ }
+
_php_curl_cleanup_handle(ch);
error = curl_easy_perform(ch-cp);
Index: trunk/ext/curl/tests/bug48203.phpt
===
--- trunk/ext/curl/tests/bug48203.phpt (revision 311121)
+++ trunk/ext/curl/tests/bug48203.phpt (working copy)
@@ -18,16 +18,23 @@
curl_setopt($ch, CURLOPT_VERBOSE, 1);
curl_setopt($ch, CURLOPT_STDERR, $fp);
-curl_setopt($ch, CURLOPT_URL, );
+curl_setopt($ch, CURLOPT_URL, getenv(PHP_CURL_HTTP_REMOTE_SERVER));
fclose($fp); // -- premature close of $fp caused a crash!
curl_exec($ch);
+curl_close($ch);
+
echo Ok\n;
?
--CLEAN--
?php @unlink(dirname(__FILE__) . '/bug48203.tmp'); ?
---EXPECT--
+--EXPECTF--
+Warning: curl_exec(): %d is not a valid stream resource in %s on line %d
+
+Warning: curl_exec(): STDERR file handle is incorrect in %s on line %d
+* About to connect() %a
+* Closing connection #0
Ok
Index: branches/PHP_5_3/ext/curl/interface.c
===
--- branches/PHP_5_3/ext/curl/interface.c (revision 311132)
+++ branches/PHP_5_3/ext/curl/interface.c (working copy)
@@ -2208,6 +2208,16 @@
ZEND_FETCH_RESOURCE(ch, php_curl *, zid, -1, le_curl_name, le_curl);
+ // check if custom std_err is not already closed
+ if (ch-handlers-std_err) {
+ php_stream *stream;
+
+ if (!(php_stream_from_zval_no_verify(stream,
ch-handlers-std_err))) {
+ php_error_docref(NULL TSRMLS_CC, E_WARNING, STDERR file handle
is incorrect);
+ curl_easy_setopt(ch-cp, CURLOPT_STDERR, stderr);
+ }
+ }
+
_php_curl_cleanup_handle(ch);
error = curl_easy_perform(ch-cp);
Index: branches/PHP_5_3/ext/curl/tests/bug48203.phpt
===
--- branches/PHP_5_3/ext/curl/tests/bug48203.phpt (revision 311132)
+++ branches/PHP_5_3/ext/curl/tests/bug48203.phpt (working copy)
@@ -18,16 +18,23 @@
curl_setopt($ch, CURLOPT_VERBOSE, 1);
curl_setopt($ch, CURLOPT_STDERR, $fp);
-curl_setopt($ch, CURLOPT_URL, );
+curl_setopt($ch, CURLOPT_URL, getenv(PHP_CURL_HTTP_REMOTE_SERVER));
fclose($fp); // -- premature close of $fp caused a crash!
curl_exec($ch);
+curl_close($ch);
+
echo Ok\n;
?
--CLEAN--
?php @unlink(dirname(__FILE__) . '/bug48203.tmp'); ?
---EXPECT--
+--EXPECTF--
+Warning: curl_exec(): %d is not a valid stream resource in %s on line %d
+
+Warning: curl_exec(): STDERR file handle is incorrect in %s on line %d
+* About to connect() %a
+* Closing connection #0
Ok
Index: branches/PHP_5_4/ext/curl/interface.c
===
--- branches/PHP_5_4/ext/curl/interface.c (revision 311121)
+++ branches/PHP_5_4/ext/curl/interface.c (working copy)
@@ -2204,6 +2204,16 @@
ZEND_FETCH_RESOURCE(ch, php_curl *, zid, -1, le_curl_name, le_curl);
+ // check if custom std_err is not already closed
+ if (ch-handlers-std_err) {
+ php_stream *stream;
+
+ if (!(php_stream_from_zval_no_verify(stream,
ch-handlers-std_err))) {
+ php_error_docref(NULL TSRMLS_CC, E_WARNING, STDERR file handle
is incorrect);
+ curl_easy_setopt(ch-cp, CURLOPT_STDERR, stderr);
+ }
+ }
+
_php_curl_cleanup_handle(ch);
error = curl_easy_perform(ch-cp);
Index: branches/PHP_5_4/ext/curl/tests/bug48203.phpt
Re: [PHP-DEV] Need karma for committing test patches
2011/5/17 Pierre Joye pierre@gmail.com: hi, On Tue, May 17, 2011 at 3:40 PM, Alexey Shein con...@gmail.com wrote: I need karma to commit test fixes: 1) session_encode_basic - added serialize_precision=100 ini setting Is it not fixed already? As Tyrael already said this one was missed. 2) fix for http://bugs.php.net/48203: there's a segfault when Pls open a bug report and attach the patch to it, I will check and apply it later today. Should I reopen #48203 or create a new one? -- Regards, Shein Alexey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Need karma for committing test patches
Created http://bugs.php.net/bug.php?id=54798. -- Regards, Shein Alexey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Need karma for committing test patches
A few remarks: * Isn't this supposed to be fixed? Was there something that triggered a regression? As far as I can see Jani checked only case when already closed file descriptor was passed to curl_setopt. Here's the check is performed in curl_exec, i.e. in curl_setopt file descriptor was valid and at the moment of call curl_setopt it's closed/invalid. * If this strategy is used (checking whether the resource associated with the stored zval is valid), how about curl_multi_exec? The logic is simple - if resource is ok, then go with it, else it's changed to default stderr. Did not tested it on curl_multi_exec(), just took the failed phpt file and got it working :) * I think a better strategy would be to just dup the file descriptor gotten after the cast in curl_setopt, store it (instead of storing the zval) and close it on curl handle destruction. This way we wouldn't have to worry about zval refcounts or whether the file descriptor obtained is still valid. Could you see if this other strategy works? (otherwise I can do it later this week) Yes, I like your strategy, will try to do it. Also I would be happy if somebody could answer my questions because all documentation is written in C is not so easy to understand :) -- Gustavo Lopes -- 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] 5.4 again
It seems Rasmus already patched some date tests here:
http://svn.php.net/viewvc?view=revisionrevision=311014
And my second patch (in previous letter) about bug 51819 is wrong,
will try to investigate it further.
More test fixes:
/trunk/ext/curl/tests/curl_setopt_basic001.phpt should probably be
deleted, since it checked curl behavior in safe_mode and there's no
safe_mode anymore in trunk.
/trunk/ext/date/tests/DateInterval_format_a.phpt needs timezone set
(see attached patch)
/trunk/ext/session/tests/session_encode_basic.phpt - needs precision
serialize to be set (see attached patch)
I need some help with another bug. I'm looking into curl bug
http://bugs.php.net/48203 (test /trunk/ext/curl/tests/bug48203.phpt).
The bug is when std_err file pointer given to curl is closed before
calling curl_exec then curl causes segfault. How I can check that file
is already closed? File pointer is stored in zval as I can see
(ch-handlers-std_err in /ext/curl/interface.c around line 1852) .
2011/5/13 Alexey Shein con...@gmail.com:
Hi, list.
I've fixed some datetime tests in the trunk in answer to Rasmus call
for devs :)
There are two patches here.
First patch is quite trivial - it fixes some relative/absolute path
misconfiguration in phpt tests.
Second patch fixes some timezone errors in bug51819 - some timezones
like GB were not parsed correctly. Tests are ok now but don't know if
my solution is correct.
Hope these patches would be useful.
P.S. Please, note I'm very new to C and will be happy if someone can
answer to some of my newbie questions and gently point my mistakes :)
2011/5/12 Rasmus Lerdorf ras...@lerdorf.com:
On 05/11/2011 02:10 PM, Philip Olson wrote:
So, that's the concern there. But if the alpha is simply a trick to
convince people to test out a specific PHP 5.4 snapshot, and feel 5.4 is
real, then do it. ;)
There are still quite a few test failures in trunk. Some of them are also in
the 5_3 branch. In some cases the tests are simply bad. In a few the test
case contains binary data that got mangled in the move to Subversion. It
would be nice if just 1 in 10 people reading the list here would grab both
trunk and 5_3 and run make test in each tree and then fix at least 1 test
each. We would have no test failures by the end of the day other than a few
tricky ones. If an alpha release will encourage this, great. If we could get
people to just do it on their own without the alpha, even better.
And yes, I know the tests take forever to run. Get yourself a fast machine
with an SSD, and remember you can run partial tests using:
make test TESTS=ext/hash
for example to just run the tests for the hash extension.
Also, when a test fails, cd into the ext/hash/tests directory and you will
see .out, .exp, .diff and .php files for the failed test. That is, the
output, the expected output, the diff between them and the php script itself
extracted from the .phpt file containing the failed test case.
And if you can't figure out how to fix a test, post the details here. I'd
love to point some of the obvious talents and energy of this list towards
the code. If you don't have an svn account for committing your fixed test,
go to http://www.php.net/svn-php.php and fill in the little form at the
bottom there and put in the test that you fixed and a 1-liner about how you
fixed it and I will set you up with an account right away. Info on how to
check out the code from svn is here:
https://wiki.php.net/vcs/svnfaq
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
Regards,
Shein Alexey
--
Regards,
Shein Alexey
Index: ext/date/tests/DateInterval_format_a.phpt
===
--- ext/date/tests/DateInterval_format_a.phpt (revision 311069)
+++ ext/date/tests/DateInterval_format_a.phpt (working copy)
@@ -9,6 +9,7 @@
Windows VC6 libs' floor()/ceil() choke on floats
--FILE--
?php
+date_default_timezone_set('UTC');
$date1 = new DateTime('2000-01-01 00:00:00');
$date2 = new DateTime('2001-03-04 04:05:06');
Index: ext/session/tests/session_encode_basic.phpt
===
--- ext/session/tests/session_encode_basic.phpt (revision 311069)
+++ ext/session/tests/session_encode_basic.phpt (working copy)
@@ -1,5 +1,7 @@
--TEST--
Test session_encode() function : basic functionality
+--INI--
+serialize_precision=100
--SKIPIF--
?php include('skipif.inc'); ?
--FILE--
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 again
Hi, list.
I've fixed some datetime tests in the trunk in answer to Rasmus call
for devs :)
There are two patches here.
First patch is quite trivial - it fixes some relative/absolute path
misconfiguration in phpt tests.
Second patch fixes some timezone errors in bug51819 - some timezones
like GB were not parsed correctly. Tests are ok now but don't know if
my solution is correct.
Hope these patches would be useful.
P.S. Please, note I'm very new to C and will be happy if someone can
answer to some of my newbie questions and gently point my mistakes :)
2011/5/12 Rasmus Lerdorf ras...@lerdorf.com:
On 05/11/2011 02:10 PM, Philip Olson wrote:
So, that's the concern there. But if the alpha is simply a trick to
convince people to test out a specific PHP 5.4 snapshot, and feel 5.4 is
real, then do it. ;)
There are still quite a few test failures in trunk. Some of them are also in
the 5_3 branch. In some cases the tests are simply bad. In a few the test
case contains binary data that got mangled in the move to Subversion. It
would be nice if just 1 in 10 people reading the list here would grab both
trunk and 5_3 and run make test in each tree and then fix at least 1 test
each. We would have no test failures by the end of the day other than a few
tricky ones. If an alpha release will encourage this, great. If we could get
people to just do it on their own without the alpha, even better.
And yes, I know the tests take forever to run. Get yourself a fast machine
with an SSD, and remember you can run partial tests using:
make test TESTS=ext/hash
for example to just run the tests for the hash extension.
Also, when a test fails, cd into the ext/hash/tests directory and you will
see .out, .exp, .diff and .php files for the failed test. That is, the
output, the expected output, the diff between them and the php script itself
extracted from the .phpt file containing the failed test case.
And if you can't figure out how to fix a test, post the details here. I'd
love to point some of the obvious talents and energy of this list towards
the code. If you don't have an svn account for committing your fixed test,
go to http://www.php.net/svn-php.php and fill in the little form at the
bottom there and put in the test that you fixed and a 1-liner about how you
fixed it and I will set you up with an account right away. Info on how to
check out the code from svn is here:
https://wiki.php.net/vcs/svnfaq
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
Regards,
Shein Alexey
Index: ext/date/tests/DateTime_diff_add_sub-fall-type3-type2.phpt
===
--- ext/date/tests/DateTime_diff_add_sub-fall-type3-type2.phpt (revision
308238)
+++ ext/date/tests/DateTime_diff_add_sub-fall-type3-type2.phpt (revision )
@@ -12,7 +12,7 @@
* in a userland package. Please be so kind as to leave them.
*/
-require './examine_diff.inc';
+require __DIR__ . '/examine_diff.inc';
date_default_timezone_set('America/New_York');
Index: ext/date/tests/DateTime_diff_add_sub-spring-type3-type2.phpt
===
--- ext/date/tests/DateTime_diff_add_sub-spring-type3-type2.phpt
(revision 308238)
+++ ext/date/tests/DateTime_diff_add_sub-spring-type3-type2.phpt
(revision )
@@ -12,7 +12,7 @@
* in a userland package. Please be so kind as to leave them.
*/
-require './examine_diff.inc';
+require __DIR__ . '/examine_diff.inc';
date_default_timezone_set('America/New_York');
Index: ext/date/tests/DateTime_diff_add_sub-spring-type3-type3.phpt
===
--- ext/date/tests/DateTime_diff_add_sub-spring-type3-type3.phpt
(revision 308238)
+++ ext/date/tests/DateTime_diff_add_sub-spring-type3-type3.phpt
(revision )
@@ -12,7 +12,7 @@
* in a userland package. Please be so kind as to leave them.
*/
-require './examine_diff.inc';
+require __DIR__ . '/examine_diff.inc';
date_default_timezone_set('America/New_York');
Index: ext/date/tests/DateTime_diff_add_sub-massive.phpt
===
--- ext/date/tests/DateTime_diff_add_sub-massive.phpt (revision 308238)
+++ ext/date/tests/DateTime_diff_add_sub-massive.phpt (revision )
@@ -10,7 +10,7 @@
* in a userland package. Please be so kind as to leave them.
*/
-require './examine_diff.inc';
+require __DIR__ . '/examine_diff.inc';
date_default_timezone_set('America/New_York');
Index: ext/date/tests/DateTime_diff_add_sub-fall-type3-type3.phpt
===
--- ext/date/tests/DateTime_diff_add_sub-fall-type3-type3.phpt (revision
308238)
+++ ext/date/tests/DateTime_diff_add_sub-fall-type3-type3.phpt (revision )
@@ -12,7 +12,7 @@
* in a userland package. Please be so kind
