[PHP-DEV] tag rename pushes
Hi! This message is for anybody that is going to create tags in PHP's git repo. If you are not going to do that ever, you may skip this message. As you probably know, we recently made mass rename of tags from something like PHP-4.1.2-RC1 to php-4.1.2RC1. However, turns out that git does not delete old tags from local repositories when they are deleted/changed on remote. What this leads to is that if you ever fetched old tags, they are with you forever unless you delete them manually (see below about that). Please see more discussion about the topic here: http://stackoverflow.com/q/1841341/214196 http://thread.gmane.org/gmane.comp.version-control.git/168833 So what happened today is that I created a tag for 5.4.1RC1, and pushed it to the remote repo. Unknown to me, old tags left from before the rename were still sitting in my repo, and came out of the woods when the push was done, resulting to massive spam on php-cvs list and major embarrassment for me. I'd like to apologize for inconvenience caused and would propose for everybody that has push access to check their tags (git tag -l) and if there are any old tags, remove them. As far as I understand the best recipe is to do this: git tag -l | xargs git tag -d # This will delete all local tags git fetch # This will reimport tags from remote repo If anybody has better recipe on how to do it, please share. In any case, if you are ever going to tag PHP repo, please check your tag list and see if there are no stale ones left. I think you can also push single tag with git push tag but I'm not sure about the exact syntax. Git gurus are welcome to chime in. Most people (including me) always use push --tags, but the danger in that is obvious now so please learn from my fail and be careful :) -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] session.use_cookies and session.use_only_cookies
Hi, While I was testing strict session, I noticed that there is a problem in current session module behavior. From the manual session.use_cookies specifies whether the module will use cookies to store the session id on the client side. Defaults to 1 (enabled). session.use_only_cookies specifies whether the module will only use cookies to store the session id on the client side. Enabling this setting prevents attacks involved passing session ids in URLs. This setting was added in PHP 4.3.0. Defaults to 1 (enabled) since PHP 5.3.0. When session.use_only_cookie=off, session.use_trans_sid=on should be effective. However, to make session.use_trans_sid=on effective, PHP 5.4 (maybe 5.3, too) requires session.use_cookie=off. This behavior makes session.use_only_cookie setting useless. Since cookie is mandatory for secure web applications, this behavior is not good for applications that need both cookie and URL based session, too. There are many mobile devices that do not support cookie still, so I would like to fix this issue. Is there any comment? -- Yasuo Ohgaki yohg...@ohgaki.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: cvs.php.net
On Sun, Mar 25, 2012 at 8:39 PM, Alexey Shein con...@gmail.com wrote: 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 :) judging from the lack of interest I guess you are right. I will remove the cvs/cvsup subdomain from our zone file, and the cvsup.php file (any any other cvs(up).php.net reference from the codebase, and I cc'ed the systems@ list, so that somebody with shell there can stop the cvs service. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] Re: cvs.php.net
On Thu, Mar 29, 2012 at 06:04, Ferenc Kovacs tyr...@gmail.com wrote: judging from the lack of interest I guess you are right. I will remove the cvs/cvsup subdomain from our zone file, and the cvsup.php file (any any other cvs(up).php.net reference from the codebase, and I cc'ed the systems@ list, so that somebody with shell there can stop the cvs service. The cvs subdomain automatically forwards (HTTP 301) to svn.php.net, and cvsup (same method) to bugs-beta.php.net. This was originally set up years ago, when we switched to SVN, in large part to jog people's memory (oh, yeah, CVS is gone). I don't see any harm in keeping the subdomains in the zone file, but I also don't see any reason they couldn't be removed. On a related note, the wiki entry mentions that the userlist and digest auth files are fetched from master2.php.net If this is still the case, can someone switch that back to simply master.php.net so we can decommission the master2 entry from the zone? Or, if anyone would rather, just throw my key (on master) on there and I'll be glad to do it today. -- /Daniel P. Brown Network Infrastructure Manager http://www.php.net/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Got a git merge conflict in main/output.c
I try to push a bug fix https://bugs.php.net/bug.php?id=60947 for php into 5.4 and trunk git merge --no-ff --log PHP-5.3 Auto-merging main/output.c CONFLICT (content): Merge conflict in main/output.c Automatic merge failed; fix conflicts and then commit the result. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Got a git merge conflict in main/output.c
On Thu, 29 Mar 2012 17:06:57 +0200, marius adrian popa map...@gmail.com wrote: I try to push a bug fix https://bugs.php.net/bug.php?id=60947 for php into 5.4 and trunk git merge --no-ff --log PHP-5.3 Auto-merging main/output.c CONFLICT (content): Merge conflict in main/output.c Automatic merge failed; fix conflicts and then commit the result. The 5.3 specific commit was left unmerged for a while, but it's already been merged (since 67bf07f). You likely forgot to pull. Do git fetch origin, go back to 5.3, rebase onto origin/PHP-5.3 (git rebase origin/PHP-5.3) and then resume merging upwards (not forgetting to, before the merge, pull or merge 5.4 and master with origin/PHP-5.4 or origin/master). -- Gustavo Lopes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: cvs.php.net
On Thu, Mar 29, 2012 at 4:48 PM, Daniel Brown danbr...@php.net wrote: On Thu, Mar 29, 2012 at 06:04, Ferenc Kovacs tyr...@gmail.com wrote: judging from the lack of interest I guess you are right. I will remove the cvs/cvsup subdomain from our zone file, and the cvsup.php file (any any other cvs(up).php.net reference from the codebase, and I cc'ed the systems@ list, so that somebody with shell there can stop the cvs service. The cvs subdomain automatically forwards (HTTP 301) to svn.php.net, and cvsup (same method) to bugs-beta.php.net. This was originally set up years ago, when we switched to SVN, in large part to jog people's memory (oh, yeah, CVS is gone). I don't see any harm in keeping the subdomains in the zone file, but I also don't see any reason they couldn't be removed. yeah, it is forwarding the http traffic, but the cvspserver is still running on cvs.php.net(and I was able to checkout from there): tyrael@thor:~/checkouts$ nmap cvs.php.net|grep cvs 2401/tcp open cvspserver would be nice if somebody could kill that. On a related note, the wiki entry mentions that the userlist and digest auth files are fetched from master2.php.net If this is still the case, can someone switch that back to simply master.php.net so we can decommission the master2 entry from the zone? Or, if anyone would rather, just throw my key (on master) on there and I'll be glad to do it today. I remember using master2 on people.php.net while we was in the process to migrate the master to the new box, I will check and change back those references to master.php.net -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] Got a git merge conflict in main/output.c
On Thu, Mar 29, 2012 at 6:14 PM, Gustavo Lopes glo...@nebm.ist.utl.pt wrote: On Thu, 29 Mar 2012 17:06:57 +0200, marius adrian popa map...@gmail.com wrote: I try to push a bug fix https://bugs.php.net/bug.php?id=60947 for php into 5.4 and trunk git merge --no-ff --log PHP-5.3 Auto-merging main/output.c CONFLICT (content): Merge conflict in main/output.c Automatic merge failed; fix conflicts and then commit the result. The 5.3 specific commit was left unmerged for a while, but it's already been merged (since 67bf07f). You likely forgot to pull. Do git fetch origin, go back to 5.3, rebase onto origin/PHP-5.3 (git rebase origin/PHP-5.3) and then resume merging upwards (not forgetting to, before the merge, pull or merge 5.4 and master with origin/PHP-5.4 or origin/master). Thanks that is solved now , but now seems that i need more karma for the ext/interbase/pdo_firebird folder git push origin remote: Welcome mariuz. remote: You have insufficient Karma! remote: I'm sorry, I cannot allow you to write to remote: php-src.git/ext/interbase/ibase_service.c remote: Have a nice day. To g...@git.php.net:php-src.git ! [remote rejected] PHP-5.3 - PHP-5.3 (pre-receive hook declined) ! [remote rejected] PHP-5.4 - PHP-5.4 (pre-receive hook declined) ! [remote rejected] master - master (pre-receive hook declined) error: failed to push some refs to 'g...@git.php.net:php-src.git' -- Gustavo Lopes -- 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
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-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
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. 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. 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? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Change all XFAIL tests to FAIL
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. could you elaborate on this part? where were we 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. yeah, but as we did see, the current approach makes it very easy to hide even the not so small issues (for example the bunch of date related XFAILS which you personally asked multiple times to be fixed before the 5.4 release). I think that in it's current form XFAIL hurts more than it helps. 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. yeah, and the exact same thing happened with the 5.3.7/CVE-2011-3189, even though that we have XFAILs. I think that eliminating the failing tests and making the fails noisy would be a better approach. I think that those spontaneous TestFests initiated by Rasmus really helped, and now that we are on git/github, there would be even greater audience. 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? http://www.phpunit.de/manual/3.2/en/incomplete-and-skipped-tests.html currently the XFAIL can mean that either the test is incomplete, or the functionality is missing/the code is broken, but we are expecting that for some reason. killing the XFAIL and adding the Incomplete test feature would allow the first, but the second should be a failing test. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
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] Change all XFAIL tests to FAIL
Hi! could you elaborate on this part? where were we a year ago? We had many failing tests that now XFAILs classified as regular FAILs. yeah, but as we did see, the current approach makes it very easy to hide even the not so small issues (for example the bunch of date related XFAILS which you personally asked multiple times to be fixed before the 5.4 release). And did that happen while they were FAILs? No, it did not. These fails were still ignored. I think that in it's current form XFAIL hurts more than it helps. Hurts what? What is worse than before? Every problem you describe we had before, and on top of that we have ones that we don't have now. I think that eliminating the failing tests and making the fails noisy would be a better approach. Better in which regard? We know for a fact that having test fails does not lead to people promptly fixing it. We just have 50 test failures for a year, and people stop regarding 50 test failures as something exceptional - we always had tons of test fails, who cares if there's one or two or ten more? So if you propose going back to what we already had a year ago, you still have to explain how situation would be better than it was a year ago - what exactly changed? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Change all XFAIL tests to FAIL
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? 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? 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. 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. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Merge from 5.3 and/or 5.4. What's the current policy?
Hi, Since the git work flow in the wiki requires to apply patch to lowest possible branch, then merge upwards. This changes old work flow, commit trunk, then merge to release. I've committed simple build problem fix to all branches, I think release masters don't care such merge. However, how about feature changes? I have simple patch for Request #47570 libpq's PG_VERSION should be exported to userland https://bugs.php.net/bug.php?id=47570 This is simple change, but it's new feature. (I added 2 new module constants for PG_VERSION, PG_VERSION_STR) Question is What's the standard work flow for new features? Regards, -- Yasuo Ohgaki yohg...@ohgaki.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
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
Re: [PHP-DEV] Change all XFAIL tests to FAIL
Hi, As a distribution maintainer, I would like to distinct failed test that is ok and failed test that is not ok. I think release versions should not have test that fails. How about add Dev and Release mode for tests with Dev mode as default? -- Yasuo Ohgaki yohg...@ohgaki.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Files generated by re2c
Hi,
I also would like to remove date from them.
It seems --no-generation-date is the option for that.
$ re2c --version
re2c 0.13.5
--
Yasuo Ohgaki
yohg...@ohgaki.net
2012/3/27 Sebastian Bergmann sebast...@php.net:
Zend/zend_language_scanner.c and Zend/zend_language_scanner_defs.h
are generated by re2c and under version control. This is not a
problem per-se. But since there is a timestamp in the generated
files they differ after a build, leaving the repository in an
unclean state:
➜ src git:(PHP-5.4) ✗ git diff
diff --git a/Zend/zend_language_scanner.c
b/Zend/zend_language_scanner.c
index 3f6189e..b7f1a0a 100644
--- a/Zend/zend_language_scanner.c
+++ b/Zend/zend_language_scanner.c
@@ -1,4 +1,4 @@
-/* Generated by re2c 0.13.5 on Thu Mar 1 21:27:30 2012 */
+/* Generated by re2c 0.13.5 on Tue Mar 27 11:03:20 2012 */
#line 1 Zend/zend_language_scanner.l
/*
diff --git a/Zend/zend_language_scanner_defs.h
b/Zend/zend_language_scanner_defs.h
index 015a903..61131ca 100644
--- a/Zend/zend_language_scanner_defs.h
+++ b/Zend/zend_language_scanner_defs.h
@@ -1,4 +1,4 @@
-/* Generated by re2c 0.13.5 on Thu Mar 1 21:27:30 2012 */
+/* Generated by re2c 0.13.5 on Tue Mar 27 11:03:20 2012 */
#line 3 Zend/zend_language_scanner_defs.h
enum YYCONDTYPE {
Can't we just remove the comment with the timestamp from the templates
these files are generated from? Thanks!
--
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
