Re: [PHP-DEV] PHP 5.5.0beta1 ZTS broken build
On Mar 26, 2013 12:59 AM, Christopher Jones christopher.jo...@oracle.com wrote: OK. I also tested bison 2.7. After locally patching Zend/acinclude.m4 to allow 2.7, then the PHP 5.5 testsuite has only five fails, all in gd. Which? Should be max 2 (merge issue).
Re: [PHP-DEV] Questions regarding DateTimeImmutable
Start simple: ask Derick to revert and go through the usual RFC process. @Derick: given the overall response on the list, could you revert the introduction of DateTimeImmutable? cu, Lars Am 26.03.2013 um 01:21 schrieb Levi Morrison morrison.l...@gmail.com: So how do we officially undo something that didn't use an RFC but should have? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Questions regarding DateTimeImmutable
On Tue, Mar 26, 2013 at 9:23 AM, Lars Strojny l...@strojny.net wrote: Start simple: ask Derick to revert and go through the usual RFC process. @Derick: given the overall response on the list, could you revert the introduction of DateTimeImmutable? huge +1. Even more for an extension that can't be disabled and always used as default date handling. Cheers, -- Pierre @pierrejoye -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP 5.5 and clang
Hi, I am trying to build PHP 5.5beta1 with clang, so the question is: Would you be interested in the results? This would be one shot only. The next step would be to do automatic builds and publishing results of scan-build (a Clang static analysis tool). Would you be interested? It does seem to produce lot of fatal errors on lot of places, so it seems that php5 can be used to improve llvm/clang as well :). O. -- Ondřej Surý ond...@sury.org
Re: [PHP-DEV] PHP 5.5 and clang
On Tue, 2013-03-26 at 15:55 +0100, Ondřej Surý wrote: It does seem to produce lot of fatal errors on lot of places, so it seems that php5 can be used to improve llvm/clang as well :). Recent clang versions work well for me with PHP. Earlier versions led to infinite hanging compilers and such which gave me some doubt about clang's state, while I like the way more helpful error messages clang provides than other compilers I know. I think it would be great if we could integrate scan-build and other checks into http://ci.qa.php.net/ and would give more focus on that. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Deprecate and remove calls from incompatible context
On Sun, Jan 20, 2013 at 8:17 PM, Gustavo Lopes glo...@nebm.ist.utl.ptwrote: I've opened the vote for the remove calls from incompatible context RFC: https://wiki.php.net/rfc/**incompat_ctx#votehttps://wiki.php.net/rfc/incompat_ctx#vote -- Gustavo Lopes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Hi Gustavo, What is the status with this one? AFAIK you never merged the change even though that the vote has ended, and now we are in the feature freeze, so this can be a problem. Am I missing something? -- Ferenc Kovács @Tyr43l - http://tyrael.hu
[PHP-DEV] DateTimeImmutable
Hi all! I am concerned by the introduction of DateTimeImmutable extending DateTime, and despite not being the talking guy, I'll try to outline the reasons why I and obviously a lot of other people think so. I can understand the frustration with a DateTime that should not have been modifiable in the first place and the wish to improve upon things and to lead users to the proper way. But, this is not the right way. If interoperability was in mind, it will not be given, because every single API which has been written in the last seven years and has DateTime in it's signature is potentially broken. The code may and should be able to expect a modifiable instance of DateTime, which is no longer guaranteed. The argument, that it was implemented this way, so that method signatures do not have to be changed, is weak, because every method has to be reviewed, and a method signature change would actually be the right thing to accept a DateTimeImmutable, because it does not act like a DateTime. It will lead to lots of boilerplate typechecking code with instanceof because it actually is not the same type. DateTimeImmutable extending DateTime will instantly create BC issues, which we will suffer from a long time. The toughtful developer, which already cloned the DateTimes in his methods won't benefit either, because now he's cloning DateTimeImmutables. In my opinion, the only way to solve this issue is through documentation, advocation, publication and providing DateTimeImmutable as a sibling to DateTime. DateTime is here, and we cannot go back in time, but we might deprecate DateTime* and introduce a date namespace in PHP-next to clean up this front, but this already goes beyond the issue with DateTimeImmutable. -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] libmagic 5.14 upgrade
Hi, I've developed a patch for libmagic 5.14 which is available under http://belski.net/phpz/finfo/finfo_5.14_5.patch.gz . For those willing to test please overwrite ext/fileinfo/tests/magic with http://belski.net/phpz/finfo/magic.mgc.gz (not contained in the patch). I've tested it on Linux and Windows, the issues it brings are minimal. The tests failing are test fails due to the lib upgrade. The reason I'm suggesting the patch now is that there was a discussion on IRC about upgrading libmagic for 5.5. We haven't have any upgrades to the filenfo extension on all the branches since about 1 year. That's why tickets like bug #64462 come to the life. David is going to tag the beta2 tomorrow, so there is kind of time pressure. IMHO it'd really make sense to put the upgraded libmagic into 5.5 despite it's beta already. Even 5.4 would come to question. At the moment we have libmagic 5.11 in all the branches. With this we're about a year back in time. Thinking that 5.5 without even have been released yet has two years old libmagic in a year is not nice. 5.4 would also profit from that IMHO. Of course I cant guarantee (as this is a bit sudden) the patch is perfect yet, it has some bugs for sure. However the patch is related only to libmagic, no line of fileinfo ext is touched. I'm sure any possible issues canbe fixed over the next couple of weeks. I'll be working on improvements to it in the next days anyway. What +/- I personally see upgrading this at this time: contra: - there might be bugs, the next release might have not all them fixed - 5.11 is what the latest linux exts have even as dev - older/custom magic files might be incompatible pro: - latest libmagic data - better safety for the future - in a year all that libs are for sure upgraded in the main distros - further upgrades can be better handled Please note that the latest libmagic upgrade was from 5.02 to 5.11 and there was no significant breach in 5.3+. I can just repeat that upgrading 5.4+ would make pretty much sense when looking forward. Cheers Anatol -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
