Re: [PHP-DEV] zend bison check
On 9 August 2013 02:48, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi, I proposed that specify any bison as developer wants. It seems it is not merged, yet. Usage: YACC=/usr/local/bin/mybison ./configure diff --git a/Zend/acinclude.m4 b/Zend/acinclude.m4 index 454513f..1440a2a 100644 --- a/Zend/acinclude.m4 +++ b/Zend/acinclude.m4 @@ -12,7 +12,7 @@ AC_DEFUN([LIBZEND_BISON_CHECK],[ bison_version=none if test $YACC; then AC_CACHE_CHECK([for bison version], php_cv_bison_version, [ - bison_version_vars=`bison --version 2 /dev/null | grep 'GNU Bison' | cut -d ' ' -f 4 | $SED -e 's/\./ + bison_version_vars=`$YACC --version 2 /dev/null | grep 'GNU Bison' | cut -d ' ' -f 4 | $SED -e 's/\./ php_cv_bison_version=invalid if test -n $bison_version_vars; then set $bison_version_vars On Fri, Aug 9, 2013 at 8:05 AM, Ángel González keis...@gmail.com wrote: On 08/08/13 20:56, Michael Wallner wrote: As I have no Zend karma, is anybody kind enough to merge the bison blacklist patch? https://github.com/php/php-src/pull/402 Maybe it should be bison_version_exclude=none so that the error message is nicer? Thank you, I incorporated all your suggestions -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] handling non-fatal compile-time errors
Ferenc Kovacs wrote: ps: on a related note, somehow I got the feeling that Lester complaining that E_STRICT errors fataling/crashing the application migrated to PHP 5.4 was related to this problem, and I'm a bit sad that we didn't managed to figure this out back then. I think I'm hitting the same problem here on migrating owncloud from Apache2.2 to Apache 2.4 ... The site works perfectly on 2.2 but on 2.4 we get 'white screen' and absolutely nothing in the error logs. I've spent several hours working my way through the 'loader' and identified point which fail, but still not nailed why :( I suspect it's apache rewrite messing up the loaded and I'll use your revised bug report to see if that helps track debugging! I get the usual criticism on the owncloud lists asking why I need to change Apache, but the answer is the same - the ISP's are moving (GoDaddy did without any warning!) but sites simply stop working :( -- 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 Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php_serialize session serialize handler
On 8 August 2013 23:31, Yasuo Ohgaki yohg...@ohgaki.net wrote: How php_serialize would cause BC issues for PHP users? Not everyone uses PHP in the way you would expect. Just how many sites out there do you think use PHPs session functionality? I'd go for hundreds of millions, and that's a pretty big target to hit. If you session_encode() something on 5.x with default settings and 5.x+1 cannot session_decode() it with default settings, that is a BC break.
Re: [PHP-DEV] php_serialize session serialize handler
Hi Leigh, On Fri, Aug 9, 2013 at 5:28 PM, Leigh lei...@gmail.com wrote: On 8 August 2013 23:31, Yasuo Ohgaki yohg...@ohgaki.net wrote: How php_serialize would cause BC issues for PHP users? Not everyone uses PHP in the way you would expect. Just how many sites out there do you think use PHPs session functionality? I'd go for hundreds of millions, and that's a pretty big target to hit. If you session_encode() something on 5.x with default settings and 5.x+1 cannot session_decode() it with default settings, that is a BC break. Mixing versions with shared data should be carefully handled for almost all apps. Even if this is the case, users may use old serializer so no BC. Anyway, we also have to consider number of bug/request reports that it solves. There are countless bug reports that were closed as won't fix/not a bug because of the register_globals support in session module. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] php_serialize session serialize handler
Leigh wrote: How php_serialize would cause BC issues for PHP users? Not everyone uses PHP in the way you would expect. Just how many sites out there do you think use PHPs session functionality? I'd go for hundreds of millions, and that's a pretty big target to hit. If you session_encode() something on 5.x with default settings and 5.x+1 cannot session_decode() it with default settings, that is a BC break. My own concerns with much of this are due to third party libraries using some 'new approach' which requires a particular setup such as changing a default, but another library still requires the old way of working. THAT is the problem. -- 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 Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php_serialize session serialize handler
Hi Lester, On Fri, Aug 9, 2013 at 6:29 PM, Lester Caine les...@lsces.co.uk wrote: Leigh wrote: How php_serialize would cause BC issues for PHP users? Not everyone uses PHP in the way you would expect. Just how many sites out there do you think use PHPs session functionality? I'd go for hundreds of millions, and that's a pretty big target to hit. If you session_encode() something on 5.x with default settings and 5.x+1 cannot session_decode() it with default settings, that is a BC break. My own concerns with much of this are due to third party libraries using some 'new approach' which requires a particular setup such as changing a default, but another library still requires the old way of working. THAT is the problem. On Fri, Aug 9, 2013 at 6:26 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Mixing versions with shared data should be carefully handled for almost all apps. Even if this is the case, users may use old serializer so no BC. Anyway, we also have to consider number of bug/request reports that it solves. There are countless bug reports that were closed as won't fix/not a bug because of the register_globals support in session module. As I wrote, there is no real BC issue as it's just a matter of ini setting. It's sounded like denial of improvement and removal of misdesigned component. I'm not going to remove old one, though. Search bug db, there are many bug reports/feature requests that this patch solves. If users aren't reading release note of minor version up, then it is users' fault, not ours. If it is, we cannot release new PHP. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] php_serialize session serialize handler
Yasuo Ohgaki wrote: If users aren't reading release note of minor version up, then it is users' fault, not ours. If it is, we cannot release new PHP. MANY users don't even know that their hosting has been changed until their sites stop working ... This happens a lot more often now than it ever used to! Silly little things like '?=' stopping working took a lot of time to address because the 'problem' was not easy to spot. Blaming the users is simply not acceptable! -- 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 Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php_serialize session serialize handler
Blaming the users is simply not acceptable! That actually depends on the organization's focus. I, for one, will gladly blame users when they don't care when their software is deprecated. Using deprecated software is their risk, not ours, especially when they are not keeping in close contact with their hosting providers.
Re: [PHP-DEV] php_serialize session serialize handler
Hi! As I wrote, there is no real BC issue as it's just a matter of ini setting. There is a BC issue if you need an ini setting. You keep dismissing it but if it affected the app your business relates on it'd be a major problem if on upgrade your app breaks and you need to scour release notes to figure out all settings you need to change for each upgrade. So we try to minimize such cases. In some instances, it's unavoidable - but in this case, the support for numerics in _SESSION is an exotic feature that will be of little use for 99% of PHP users. So introducing additional upgrade headaches for this is IMHO unnecessary. I'm not going to remove old one, though. Search bug db, there are many bug reports/feature requests that this patch solves. How many bug reports are there requesting numeric index support in session? If users aren't reading release note of minor version up, then it is users' fault, not ours. If it is, we cannot release new PHP. We can. We can also take some responsibility for making it easier to upgrade and not just say we had it all in the fine print, it's your own fault for not reading everything. Vendors that do that are usually disliked by their customers. -- 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] Re: [RFC] Importing namespaced functions
On Aug 8, 2013 9:31 PM, Daniel Bingham daniel.bing...@ellislab.com wrote: Hey Igor, I love the RFC, but how about: use bar\baz() as baz; As an alternative to use function. Still new syntax, but a little less wordy. The parenthesis add the feeling that it should be evaluated imho, I.e. the result of that function should be used as baz. That could possibly lead to confusion. I know you're suggesting as an additional syntax not alternative, but I don't get good vibes from it. Also might not even be possible due to how the parser handles parenthesis, but I'd have to look over the parser grammar to be sure. But another +1 from me on the RFC as a whole. Now its there I can't believe it took so long.
Re: [PHP-DEV] php_serialize session serialize handler
Hi Stas, On Sat, Aug 10, 2013 at 1:53 AM, Stas Malyshev smalys...@sugarcrm.comwrote: As I wrote, there is no real BC issue as it's just a matter of ini setting. There is a BC issue if you need an ini setting. You keep dismissing it but if it affected the app your business relates on it'd be a major problem if on upgrade your app breaks and you need to scour release notes to figure out all settings you need to change for each upgrade. So we try to minimize such cases. In some instances, it's unavoidable - but in this case, the support for numerics in _SESSION is an exotic feature that will be of little use for 99% of PHP users. So introducing additional upgrade headaches for this is IMHO unnecessary. I think we are not talking about newbie users. Users who share session data among web servers are advanced users and they would not have problem reading release notes before upgrading. Most of users don't have care at all. If there is old session data, it's just discarded. I'm not going to remove old one, though. Search bug db, there are many bug reports/feature requests that this patch solves. How many bug reports are there requesting numeric index support in session? It's one type of bug report that relates to this patch. There types bug/requests. Most of them are old one I suppose. IIRC, there were - Session fails to save if it contains special chars - Want unserialize session from session data, not from $_SESSION - Need function generates initial session data via dession_decode - Session should use plain serialize These are occasionally pops up and closed as not a bug/wont fix. I remember since I was one of them closed as not a bug/wont fix. If users aren't reading release note of minor version up, then it is users' fault, not ours. If it is, we cannot release new PHP. We can. We can also take some responsibility for making it easier to upgrade and not just say we had it all in the fine print, it's your own fault for not reading everything. Vendors that do that are usually disliked by their customers. Even if there are users do not reading release notes, it does not break apps as it creates new session data. Users don't have clue, they would not have problem. Users may have affected, they should be able to read release notes. There wouldn't be upgrade headache. We don't want to keep misdesigned component due to register_globals, don't we? Especially when the solution does not have real BC issue. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] php_serialize session serialize handler
Hi Stas, On Sat, Aug 10, 2013 at 1:53 AM, Stas Malyshev smalys...@sugarcrm.comwrote: We can also take some responsibility for making it easier to upgrade That's the reason why I proposed adding php_serialize to 5.5. Even if there are very few users may have problem with new serializer, it would be good to provide enough time to play with it. Adding php_serialize does not affect users at all unless they explicitly use it. Regards, -- Yasuo Ohgaki yohgaki@ohgaki.netHi
Re: [PHP-DEV] Re: [RFC] Importing namespaced functions
Hey Leigh, I disagree that it suggests evaluation, but it could easily be a personal interpretation thing. In my interpretation, when looking at use statements, I know nothing is being evaluated. Symbols are being imported into the namespace. How likely is it that baz returns something that can be imported as a symbol? Would that even make sense as a feature, importing the results of an evaluated function? Actually, given those two questions, I can see how it would cause confusion if your initial interpretation is that it is being evaluated. For me, the parenthesis make it easier to read when scanning code. When scanning use statements, I'm not scanning the keywords, I'm scanning the included names. It's easier to look for parenthesis to denote functions, it makes them stand out from the class names more. As in this example below: use foo\bar\baz as baz; use bar\foo\baz() as baz; use bar\baz as bbaz; use baz\foo\bar as bar; use foo\bar() as bar; use baz\bar as bbar; Where as with use function I'd have to check back to the beginning of the phrase to determine whether I was looking at a class name or function. use foo\bar\baz as baz; use function bar\foo\baz as baz; use bar\baz as bbaz; use baz\foo\bar as bar; use function foo\bar as bar; use baz\bar as bbar; I think the difference mostly comes down to personal preference, and would be somewhat alleviated by syntax highlighting. Also, I have no knowledge of the PHP parser, so I have no idea how easy or hard this would be to implement. Daniel On Fri, Aug 9, 2013 at 1:16 PM, Leigh lei...@gmail.com wrote: On Aug 8, 2013 9:31 PM, Daniel Bingham daniel.bing...@ellislab.com wrote: Hey Igor, I love the RFC, but how about: use bar\baz() as baz; As an alternative to use function. Still new syntax, but a little less wordy. The parenthesis add the feeling that it should be evaluated imho, I.e. the result of that function should be used as baz. That could possibly lead to confusion. I know you're suggesting as an additional syntax not alternative, but I don't get good vibes from it. Also might not even be possible due to how the parser handles parenthesis, but I'd have to look over the parser grammar to be sure. But another +1 from me on the RFC as a whole. Now its there I can't believe it took so long.
[PHP-DEV] Request #17860 Suggestion: auto detect whether session changed
Hi all, Following patch against master https://gist.github.com/yohgaki/6198611 implements FR #17860 https://bugs.php.net/bug.php?id=17860 This patch removes unneeded session writes. i.e. session data has not changed, just skip write and improve performance. Although it is safe to remove unneeded writes, if many of us want ini setting for enable/disable write short cut, I'll add setting for it. Any comments? P.S. Not all of tests are fixed yet. -- Yasuo Ohgaki yohg...@ohgaki.net
