Re: [PHP-DEV] Give the Language a Rest motion (fwd)
On Fri, 2013-02-22 at 08:44 +0100, Martin Keckeis wrote: I think there may come many critics maybe, but why not move those things also to github? It's used by many people. it works, it's easy! It is easily two steps back. Yay! (Tags are funny but don't help with categorization of bugs on PHP's scale, the initial comment was on improving the Voting, github has no voting at all, ...) So if you have issues with the bug tracker please log a bug ... johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
On Fri, Feb 22, 2013 at 8:44 AM, Martin Keckeis martin.kecke...@gmail.comwrote: 2013/2/21 Johannes Schlüter johan...@schlueters.de On Thu, 2013-02-21 at 19:13 +0100, Pascal Chevrel wrote: I am specifically thinking of Bugzilla which is already used by many open source projects. It has a lot more features than your current bug tracking system, it scales for large projects and it has a few Mozilla employees working full time on it. I'm a passive user of bugzilla, not involved with any project using it but every time I have to report a bug on a project using it I think twice, why do I have to register and run away if I have to remember the password I used 2 years ago when reporting my last bug. bugs.php.net might not be as shiny as others but it makes reporting easy, fill in a captcha and you are done, no registration or such, you might even use a fake mail address (not that it necessarily helps to be unreachable for getting things resolved) And then there is a religious thing: Bugzilla is written in a legacy language ;-) And yes. it has some rough edges, but it get's it's job done, integrates with out user system, our what's the current version-notification system, ... I think there may come many critics maybe, but why not move those things also to github? It's used by many people. it works, it's easy! Zend Framework also done the move from SVN, signing a CLA, own Bug tracking system. to github and I think it couldn't be better now! it would require some changes in our process and infrastructure: - currently the bugtracker supports private bugs (mostly 0day security reports) AFAIK github doesn't have that, so we would have to use another channel (like using the secur...@php.net alone), which would be worse than the current solution when the security bugs (with all of the discussion) are opened up after the fix is released - currently we don't require a registration for reporting bugs, with the github issues the reporter needs to be registered and logged into github. - currently the bugtracker authenticates the contributers using their php.net credentials, github doesn't provide a way for that, so potentially ever contributer should be registered on github and added as a collaborator to be able to assign/edit/resolve issues. (and potentially the process should be automated, so when a php.net user is approved/granted karma he/she should be added to the collaborators automatically, I suppose there is a way to do that in the github api). - currently the bugtracker supports blocking the comments for a specific bug, github doesn't have that kind of feature. - currently the bugtracker supports providing version, OS information, the github issues doesn't have any way to have custom fields, maybe the labels/tags could be (ab)used for this, and we would need to automate this so when a new version is added, the label should automatically pushed to github. - currently the bugtracker supports providing package information, that would either require us to split the php-src repo into multiple repositories (ext/*, Zend/, etc. this would be a bad idea imo) or we would need to use labels for this also(and the labels should.be automatically updated when a new package is created). - currently the bugtracker supports providing bugtype information(bug, feature request, documentation issue, security), see above. - currently the bugtracker supports closing the issues with Quick Fixes, where there is a predefined comment automatically added to the bug so we don't have to copypaste the resolution message for similar bugs (that the website/docs related fixes needs time to propagate, that fixing a bug in the head means that it will be fixed in a future release etc.), github issues doesn't have this kind of feature. These are the issues(from the top of my head) which need to be resolved if/when we wanna move the tracker to github. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
On Fri, Feb 22, 2013 at 10:39 AM, Johannes Schlüter johan...@schlueters.dewrote: On Fri, 2013-02-22 at 08:44 +0100, Martin Keckeis wrote: I think there may come many critics maybe, but why not move those things also to github? It's used by many people. it works, it's easy! It is easily two steps back. Yay! (Tags are funny but don't help with categorization of bugs on PHP's scale, the initial comment was on improving the Voting, github has no voting at all, ...) So if you have issues with the bug tracker please log a bug ... sigh, yeap, I forgot to mention the voting what we have (reproducible and importance), github also lacks those. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
2013/2/20 Derick Rethans der...@php.net: Looks like it is time to forward this email from 2006 again: -- Forwarded message -- Date: Thu, 09 Mar 2006 12:57:32 +0200 From: Zeev Suraski z...@zend.com To: internals@lists.php.net Subject: [PHP-DEV] Give the Language a Rest motion I'd like to raise a motion to 'Give the Language a Rest'. Almost a decade since we started with the 2nd iteration on the syntax (PHP 3), and 2 more major versions since then, and we're still heatedly debating on adding new syntactical, core level features. Is it really necessary? I'd say in almost all cases the answer's no, and a bunch of cases where a new feature could be useful does not constitute a good enough reason to add a syntax level feature. We might have to account for new technologies, or maybe new ways of thinking that might arise, but needless to say, most of the stuff we've been dealing with in recent times doesn't exactly fall in the category of cutting edge technology. My motion is to make it much, much more difficult to add new syntax-level features into PHP. Consider only features which have significant traction to a large chunk of our userbase, and not something that could be useful in some extremely specialized edge cases, usually of PHP being used for non web stuff. How do we do it? Unfortunately, I can't come up with a real mechanism to 'enforce' a due process and reasoning for new features. Instead, please take at least an hour to bounce this idea in the back of your mind, preferably more. Make sure you think about the full context, the huge audience out there, the consequences of making the learning curve steeper with every new feature, and the scope of the goodness that those new features bring. Consider how far we all come and how successful the PHP language is today, in implementing all sorts of applications most of us would have never even thought of when we created the language. Once you're done thinking, decide for yourself. Does it make sense to be discussing new language level features every other week? Or should we, perhaps, invest more in other fronts, which would be beneficial for a far bigger audience. The levels above - extensions to keep with the latest technologies, foundation classes, etc. Pretty much, the same direction other mature languages went to. To be clear, and to give this motion higher chances of success, I'm not talking about jump. PHP can live with jump, almost as well as it could live without it :) I'm talking about the general sentiment. Zeev -- 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 Agree. There are only a few core devs working daily in the PHP internals. I would say please give the Language (and devs) a rest motion, because there are a lot of bugs and work to be done but I'm afraid that is more easy/funny to request a new feature/syntax than do the grunt work :( -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
hi, On Thu, Feb 21, 2013 at 10:45 AM, Eloy Bote Falcon eloyb...@gmail.com wrote: Agree. There are only a few core devs working daily in the PHP internals. I would say please give the Language (and devs) a rest motion, because there are a lot of bugs and work to be done but I'm afraid that is more easy/funny to request a new feature/syntax than do the grunt work :( And those proposing new long awaited features are new contributors and those actually doing the household job too, since quite some time. So basically your last argument is contradicted by the reality. Cheers, -- Pierre @pierrejoye -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Give the Language a Rest motion (fwd)
What you're bringing up is not at all about adapting. Adapting is something we do at the extensions, frameworks and tools levels. I'm happy to say PHP's ecosystem here is very healthy, in my opinion. Adapting is not what we're dealing with here. We're talking about Adding. By adding more and more, we're making the language more and more complex, less and less accessible to both new and existing developers, thereby hurting its #1 appeal - simplicity. As we thrust forward towards 5.5, more than half of the community is still on 5.2. 5.4 is virtually nonexistent in terms of real world usage, and yet we thrust forward to 5.5, as if the community at large cares about all these new features. The community is voting with its feet, and that is probably the best survey we're ever going to get. I'm not saying we shouldn't add new features. But I am saying that we shouldn't add many of them. The very few we should add - should have exceptional 'return on investment'. To be clear, the investment isn't just the effort to develop or even maintain the implementation - that's not even the main point. It's the increased complexity that each and every new language construct brings with it, whether we like it or not. There used to be a language that was the Queen of the Web. It was full of clever syntax. It prided itself on having a variety of expressive ways of doing the same thing. You're on the mailing list of the language that dethroned it. Zeev -Original Message- From: Lars Strojny [mailto:l...@strojny.net] Sent: Thursday, February 21, 2013 1:15 AM To: Derick Rethans; PHP Developers Mailing List Subject: Re: [PHP-DEV] Give the Language a Rest motion (fwd) As a general reply: I'd like to disagree, and here is why. Yes, we should not let half baked features in but we need to add more and more features, also syntax wise. For three reasons: - Parity/expectations/me too: so you can do that in PHP as well - Expressiveness: allow better ways to express the same idea in more concise ways - Innovation: bring unexpected features to the language people didn't even expect Let's recall a few of the latest additions: - 5.3: namespaces. Provided the foundation for awesome stuff like PSR-1, which in turn provides the foundation for the even more awesome stuff composer is. - 5.3: goto. A good thing we can do it. I'm not sure for what exactly but I am sure there is somebody out there :) - 5.3: Closures, huge thing for us, a matter of parity to other languages. Really changes the face of a lot of APIs (see e.g. Doctrine transactional(), the whole micro framework movement, React) - 5.4: Closures 2.0 with $this binding. Honestly, without it, Closures are a little meh. But it was good we waited and got it right. - 5.4: Short array syntax. A parity/culture issue. - 5.4: Traits, I am happy we got horizontal reuse right - 5.4: array dereferencing. Very small but useful. To me it feels more like a bugfix - 5.4: callable type hint. Small change with a huge impact - 5.5: Generators, also a matter of parity and a matter of awesomeness - 5.5: ClassName::class syntax. A really good improvement to the overall usability of namespaces. Just imagine how much shorter unit test setUp() methods will become What we have on our list that, from my perspective, will sooner or later hit us: - Property accessors in some form or another: a lot of people seem to like it. - Annotation support: we would have a lot of customers for it. - Autoboxing for primitives. Allows us to fix a lot of problems in ext/standard. - Unicode. Obviously. - Named parameters. A recurring topic might be a topic worth digging deeper. - I'm positive the Generics discussion will arise at some point again. . and these are just the changes on a syntax/semantics level, I'm not talking about all the awesome technologies (one of which you are working on) we need to integrate tighter and eventually bundle with core. I don't believe we should let our users outgrow the language, quite the opposite, we should grow with our users and the broader web community, otherwise we will fail. PHP is nowadays used for tasks it never was intended to be used but that's a good thing. We need to continuously adapt. What's true for software projects is true for languages: stop improving actually reduces its value over time. cu, Lars Am 20.02.2013 um 19:18 schrieb Derick Rethans der...@php.net: Looks like it is time to forward this email from 2006 again: -- Forwarded message -- Date: Thu, 09 Mar 2006 12:57:32 +0200 From: Zeev Suraski z...@zend.com To: internals@lists.php.net Subject: [PHP-DEV] Give the Language a Rest motion I'd like to raise a motion to 'Give the Language a Rest'. Almost a decade since we started with the 2nd iteration on the syntax (PHP 3), and 2 more major versions since then, and we're still heatedly debating on adding new syntactical, core
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
hi Zeev, On Thu, Feb 21, 2013 at 10:56 AM, Zeev Suraski z...@zend.com wrote: What you're bringing up is not at all about adapting. Adapting is something we do at the extensions, frameworks and tools levels. I'm happy to say PHP's ecosystem here is very healthy, in my opinion. Yes, most of the time. But the language needs evolution, must have evolution. F.e., how long have we been battled for annotations? With all respects, it is about being blind and stubborn to say that PHP should not have annotations. But due to some I'm happy with what we have now way of doing things, we are very unlikely to have them any time soon, even if any major projects out there are waiting for it, for years. Even the ZendFramework leads want them now (changed their mind since the last attempt). This is not about borking the language with useless features. This is not about being on the cutting edge. this is about catching up with the competition. Adapting is not what we're dealing with here. We're talking about Adding. Adding? Surely a matter of wording. I'd to say evolve and catch up. By adding more and more, we're making the language more and more complex, less and less accessible to both new and existing developers, thereby hurting its #1 appeal - simplicity. I heard that in php 4 5 and OO, and all we rejected back then have been introduced since then. Not sure what is the best way, trying to stop with all four feet (to take your analogy) any kind of additions/evolution/catching up and then still doing it but years later, or trying to get a bit more open minded and listen to our communities. As we thrust forward towards 5.5, more than half of the community is still on 5.2. 5.4 is virtually nonexistent in terms of real world usage, and yet we thrust forward to 5.5, as if the community at large cares about all these new features. The community is voting with its feet, and that is probably the best survey we're ever going to get. Excuse me? Voting with its feet? Dare to explain the underlying meaning of this comment? I'm not saying we shouldn't add new features. But I am saying that we shouldn't add many of them. The very few we should add - should have exceptional 'return on investment'. To be clear, the investment isn't just the effort to develop or even maintain the implementation - that's not even the main point. It's the increased complexity that each and every new language construct brings with it, whether we like it or not. Yes, totally agree here. Annotation and usable getter/setter syntax have a huge ROI. Discuss with any application or framework developers/users will bring you to the same conclusion. There used to be a language that was the Queen of the Web. It was full of clever syntax. It prided itself on having a variety of expressive ways of doing the same thing. You're on the mailing list of the language that dethroned it. You are living in the past glory. We are not willing to make PHP more complex or kill it. We are willing to make compromises between the 2000s simplicity and the needs of modern application developments. These compromises are not only required but possible. Cheers, -- Pierre @pierrejoye -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
Zeev Suraski wrote: There used to be a language that was the Queen of the Web. It was full of clever syntax. It prided itself on having a variety of expressive ways of doing the same thing. You're on the mailing list of the language that dethroned it. And the majority of END USERS are more than happy with the websites it is serving up today! If you want to evolve the language then much more effort should be put into providing tools that update the current user base rather than simply throwing in switches which hide all the problems :( Having to manually update sites on a case by case basis is what is currently holding things back - and stopping ISP's switching to the 'latest and greatest'! -- 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] Give the Language a Rest motion (fwd)
Pierre, People who think differently from you are not necessarily blind of stubborn. I honestly think that those comments were completely out of line in several different ways. Regarding 'voting with feet', it's an idiom, look it up. Zeev -Original Message- From: Pierre Joye [mailto:pierre@gmail.com] Sent: Thursday, February 21, 2013 12:09 PM To: Zeev Suraski Cc: Lars Strojny; Derick Rethans; PHP Developers Mailing List Subject: Re: [PHP-DEV] Give the Language a Rest motion (fwd) hi Zeev, On Thu, Feb 21, 2013 at 10:56 AM, Zeev Suraski z...@zend.com wrote: What you're bringing up is not at all about adapting. Adapting is something we do at the extensions, frameworks and tools levels. I'm happy to say PHP's ecosystem here is very healthy, in my opinion. Yes, most of the time. But the language needs evolution, must have evolution. F.e., how long have we been battled for annotations? With all respects, it is about being blind and stubborn to say that PHP should not have annotations. But due to some I'm happy with what we have now way of doing things, we are very unlikely to have them any time soon, even if any major projects out there are waiting for it, for years. Even the ZendFramework leads want them now (changed their mind since the last attempt). This is not about borking the language with useless features. This is not about being on the cutting edge. this is about catching up with the competition. Adapting is not what we're dealing with here. We're talking about Adding. Adding? Surely a matter of wording. I'd to say evolve and catch up. By adding more and more, we're making the language more and more complex, less and less accessible to both new and existing developers, thereby hurting its #1 appeal - simplicity. I heard that in php 4 5 and OO, and all we rejected back then have been introduced since then. Not sure what is the best way, trying to stop with all four feet (to take your analogy) any kind of additions/evolution/catching up and then still doing it but years later, or trying to get a bit more open minded and listen to our communities. As we thrust forward towards 5.5, more than half of the community is still on 5.2. 5.4 is virtually nonexistent in terms of real world usage, and yet we thrust forward to 5.5, as if the community at large cares about all these new features. The community is voting with its feet, and that is probably the best survey we're ever going to get. Excuse me? Voting with its feet? Dare to explain the underlying meaning of this comment? I'm not saying we shouldn't add new features. But I am saying that we shouldn't add many of them. The very few we should add - should have exceptional 'return on investment'. To be clear, the investment isn't just the effort to develop or even maintain the implementation - that's not even the main point. It's the increased complexity that each and every new language construct brings with it, whether we like it or not. Yes, totally agree here. Annotation and usable getter/setter syntax have a huge ROI. Discuss with any application or framework developers/users will bring you to the same conclusion. There used to be a language that was the Queen of the Web. It was full of clever syntax. It prided itself on having a variety of expressive ways of doing the same thing. You're on the mailing list of the language that dethroned it. You are living in the past glory. We are not willing to make PHP more complex or kill it. We are willing to make compromises between the 2000s simplicity and the needs of modern application developments. These compromises are not only required but possible. Cheers, -- Pierre @pierrejoye -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
Here is a counterpoint to that expressed by Lars. Many if not most shared hosting providers don't offer PHP 5.4 yet. Ditto many enterprises have yet to adopt it. The main reason? I think its that old Backwards Compatibility issue that has been discussed heavily on this DL. When major apps like mediaWiki break with a new release of PHP (see http://www.mediawiki.org/wiki/Compatibility, and this is quite typical), upgrading PHP versions represents a major headache for both hosting providers and larger enterprises that want to maintain standard infrastructure build templates, as each none-BC PHP upgrade represents a major cost in either loss of customer satisfaction or IT investment for little or no tangible business benefit. New features are often nice for the app developer, so the result is that they then get used by apps development teams, and the provider or infrastructure team then has to manage the ripple effects on a complex infrastructure permitted configuration matrix across hundreds or thousands of apps. I am not saying that the PHP dev team should freeze PHP, but what I am suggesting is that the PHP team should also consider the compatibility impacts across versions so that enterprises and hosting providers who have adopted PHP can control their through-life maintenance costs. There are things that the PHP team could do to help mitigate this issue -- for example producing standard templates so that, say PHP 5.3, 5.4 and 5.5 based apps can coexist and perform (e.g. with APC or O+) on the *same* Apache2 (or nginx, ...) stack. Change is good, but too much change too fast without regard to the cost consequence will ultimately alienate the CIOs and CTOs who set platform policies. On 20/02/13 23:15, Lars Strojny wrote: As a general reply: I’d like to disagree, and here is why. Yes, we should not let half baked features in but we need to add more and more features, also syntax wise. For three reasons: - Parity/expectations/me too: so you can do that in PHP as well - Expressiveness: allow better ways to express the same idea in more concise ways - Innovation: bring unexpected features to the language people didn’t even expect Let’s recall a few of the latest additions: - 5.3: namespaces. Provided the foundation for awesome stuff like PSR-1, which in turn provides the foundation for the even more awesome stuff composer is. - 5.3: goto. A good thing we can do it. I'm not sure for what exactly but I am sure there is somebody out there :) - 5.3: Closures, huge thing for us, a matter of parity to other languages. Really changes the face of a lot of APIs (see e.g. Doctrine transactional(), the whole micro framework movement, React) - 5.4: Closures 2.0 with $this binding. Honestly, without it, Closures are a little meh. But it was good we waited and got it right. - 5.4: Short array syntax. A parity/culture issue. - 5.4: Traits, I am happy we got horizontal reuse right - 5.4: array dereferencing. Very small but useful. To me it feels more like a bugfix - 5.4: callable type hint. Small change with a huge impact - 5.5: Generators, also a matter of parity and a matter of awesomeness - 5.5: ClassName::class syntax. A really good improvement to the overall usability of namespaces. Just imagine how much shorter unit test setUp() methods will become What we have on our list that, from my perspective, will sooner or later hit us: - Property accessors in some form or another: a lot of people seem to like it. - Annotation support: we would have a lot of customers for it. - Autoboxing for primitives. Allows us to fix a lot of problems in ext/standard. - Unicode. Obviously. - Named parameters. A recurring topic might be a topic worth digging deeper. - I'm positive the Generics discussion will arise at some point again. … and these are just the changes on a syntax/semantics level, I'm not talking about all the awesome technologies (one of which you are working on) we need to integrate tighter and eventually bundle with core. I don’t believe we should let our users outgrow the language, quite the opposite, we should grow with our users and the broader web community, otherwise we will fail. PHP is nowadays used for tasks it never was intended to be used but that’s a good thing. We need to continuously adapt. What’s true for software projects is true for languages: stop improving actually reduces its value over time. cu, Lars
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
On Wed, Feb 20, 2013 at 7:18 PM, Derick Rethans der...@php.net wrote: Once you're done thinking, decide for yourself. Does it make sense to be discussing new language level features every other week? Or should we, perhaps, invest more in other fronts, which would be beneficial for a far bigger audience. The levels above - extensions to keep with the latest technologies, foundation classes, etc. Pretty much, the same direction other mature languages went to. Won't comment one the rest of this (to avoid more flame), but wanted to say something about this: If you want more foundation classes / libraries, then what PHP has to do is move more of it's standard library to PHP. C has a large implementational overhead and an even larger entry barrier. To make major advances on the library front, it needs to move to PHP. There are some tough problems associated with this, but I think they can be solved and PHP would benefit a lot from this. Nikita
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
Zeev, On Thu, Feb 21, 2013 at 12:24 PM, Zeev Suraski z...@zend.com wrote: Pierre, People who think differently from you are not necessarily blind of stubborn. I honestly think that those comments were completely out of line in several different ways. It is not my opinion but a simple fact. Yes, you can disagree with an idea or proposal, but the cost of such disagree, despite huge community support, is too high and it is more than counter productive. Hence this comment. Regarding 'voting with feet', it's an idiom, look it up. I know, still do not think it fits as comment either here. -- Pierre @pierrejoye -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
Pierre Joye wrote: Regarding 'voting with feet', it's an idiom, look it up. I know, still do not think it fits as comment either here. I read this as simply People are not leaving PHP in droves simply because it does not have xxx - actually the opposite, but that growth in use is not into PHP5.4 ... -- 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] Give the Language a Rest motion (fwd)
Hello, This might sound as a rant but I assure you it's not. It's just how I see the things from my perspective and that of my colleagues/employer. On Thu, Feb 21, 2013 at 11:56 AM, Zeev Suraski z...@zend.com wrote: What you're bringing up is not at all about adapting. Adapting is something we do at the extensions, frameworks and tools levels. I'm happy to say PHP's ecosystem here is very healthy, in my opinion. Could you please share how you measure that the ecosystem is healthy or not? And What do you mean in terms it's healthy? Is it adoption rate of new versions, penetration degree, influx of new people? Adapting is not what we're dealing with here. We're talking about Adding. I think that there are are cases where Adding is a mean for adapting. Like for example, the desire to have built-in annotation support. By adding more and more, we're making the language more and more complex, less and less accessible to both new and existing developers, thereby hurting its #1 appeal - simplicity. As we thrust forward towards 5.5, more than half of the community is still on 5.2. 5.4 is virtually nonexistent in terms of real world usage, and yet we thrust forward to 5.5, as if the community at large cares about all these new features. The community is voting with its feet, and that is probably the best survey we're ever going to get. The adoption of PHP 5.4 has been next to 0 because of the various BC breaks done, and even more, because APC has had a stable version only after about one year. Enterprise users such as myself can't just go to work and say: Hey, there's a new PHP version, it breaks some things for which we'll need time to fix, it adds features that we could really use but we can live without them and do workarounds like until now. Even if we'd had time to fix the broken things there's a tiny issue, we can't be sure of how APC will work and if it's going to crash our business or not. Enterprise users want stability above all else, even if it means that their devs will need to live without new features for a long time and work more in order to develop their software. Things that happened in PHP 5.4 should never happen again if you want to have larger adoption rates. ISPs can't just upgrade their software stack knowing that 99% of the sites they hold are at risk of not working due to BC breaks between 5.X releases. Deprecating is one thing, removing is another thing. I'm not saying we shouldn't add new features. But I am saying that we shouldn't add many of them. The very few we should add - should have exceptional 'return on investment'. To be clear, the investment isn't just the effort to develop or even maintain the implementation - that's not even the main point. It's the increased complexity that each and every new language construct brings with it, whether we like it or not. I totally agree with you on this one. Maybe extensions bundled with default distribution could be a good solution for adding new things that could be disabled on demand via configuration options. There used to be a language that was the Queen of the Web. It was full of clever syntax. It prided itself on having a variety of expressive ways of doing the same thing. You're on the mailing list of the language that dethroned it. Zeev Currently in PHP you can do the same thing about the same way. The difference is that right now, there's a bunch of things missing when compared to other languages and this is a push off. Consider the following scenario: We are a team of 60 programmers all with various PHP skills. We'll need say threading to better handle some reporting application. We all know PHP and maybe 2 of us know Erlang. Say we care about those who'll need to maintain the application when we'll be out of office or at other companies. The choice in this case is obvious for us. Use PHP. We simply can't afford to have new people hired that are specialized in a language that best fits our needs nor our colleagues might have time to learn how to fix something in a critical system when we are not around. Erlang should be the obvious choice in case of high concurrency and threading but we can't just use another language. Or have a look at annotations. Zend Framework 2 uses them (hint), Symfony2 uses them, Doctrine uses them and so on. All major players in the PHP world. It's frameworks and tools that also drive the adoption of a language not just the features. Imho, if most major players say they need something in order to build better tools for their users then I guess they should be heard of by the developers. Just like what happens when a end user of a framework wants a new feature in the framework they use. The problem with PHP is that it's written in C and even if it grew so big in the past years, the users to contributors conversion is very low. But then again, look at the website. There's nothing saying on it about contributions. There are no Bug hunt days events.
RE: [PHP-DEV] Give the Language a Rest motion (fwd)
People who think differently from you are not necessarily blind of stubborn. I honestly think that those comments were completely out of line in several different ways. It is not my opinion but a simple fact. That comment would have been funny if it wasn't sad. I'll leave it at that. Regarding 'voting with feet', it's an idiom, look it up. I know, still do not think it fits as comment either here. Of course it does. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Give the Language a Rest motion (fwd)
-Original Message- From: Florin Razvan Patan [mailto:florinpa...@gmail.com] Sent: Thursday, February 21, 2013 3:15 PM To: Zeev Suraski Cc: Lars Strojny; Derick Rethans; PHP Developers Mailing List Subject: Re: [PHP-DEV] Give the Language a Rest motion (fwd) On Thu, Feb 21, 2013 at 11:56 AM, Zeev Suraski z...@zend.com wrote: What you're bringing up is not at all about adapting. Adapting is something we do at the extensions, frameworks and tools levels. I'm happy to say PHP's ecosystem here is very healthy, in my opinion. Could you please share how you measure that the ecosystem is healthy or not? And What do you mean in terms it's healthy? Is it adoption rate of new versions, penetration degree, influx of new people? We have a good solid set of extensions, including lots of activity on PECL. We have flourishing framework ecosystems that are extremely active. We have excellent support from tools, both free and commercial. That's how I measure it. Adapting is not what we're dealing with here. We're talking about Adding. I think that there are are cases where Adding is a mean for adapting. Like for example, the desire to have built-in annotation support. That's not adaptation in my book. That's addition. It's not the technology landscape that changed that now you need annotations; It's that some people consider this feature cool and useful, and want to import it into PHP although it does not in fact enable you to do anything you can't do today, while it does add a lot of complexity to the language. By adding more and more, we're making the language more and more complex, less and less accessible to both new and existing developers, thereby hurting its #1 appeal - simplicity. As we thrust forward towards 5.5, more than half of the community is still on 5.2. 5.4 is virtually nonexistent in terms of real world usage, and yet we thrust forward to 5.5, as if the community at large cares about all these new features. The community is voting with its feet, and that is probably the best survey we're ever going to get. The adoption of PHP 5.4 has been next to 0 because of the various BC breaks done, and even more, because APC has had a stable version only after about one year. Enterprise users such as myself can't just go to work and say: Hey, there's a new PHP version, it breaks some things for which we'll need time to fix, it adds features that we could really use but we can live without them and do workarounds like until now. Even if we'd had time to fix the broken things there's a tiny issue, we can't be sure of how APC will work and if it's going to crash our business or not. PHP 5.4 actually brings very little BC breakage. Most companies as well as private users I know haven't even gotten to evaluate PHP 5.4 and even learn that APC doesn't work on it, because honestly, they couldn't care less. For them, 5.3 or even 5.2 are good enough, they don't even inquire into 5.4. For the vast majority of companies/users, the motivation to upgrade PHP would be coming from two places: 1. If they need it in order to run their apps (5.3 is required by a growing number of frameworks (ZF2, Sf2)). 2. If they're worried about security updates after the EOL. The point is that the sky is falling mentality that was expressed here by certain people could not be farther from reality. If we take a look at the userbase at large, people are content with PHP's syntax, and the constant drive for additions to it simply makes no sense. Enterprise users want stability above all else, even if it means that their devs will need to live without new features for a long time and work more in order to develop their software. It's not just enterprises, effectively it's anybody who uses PHP for anything that’s' beyond a hobby. I'm not saying we shouldn't add new features. But I am saying that we shouldn't add many of them. The very few we should add - should have exceptional 'return on investment'. To be clear, the investment isn't just the effort to develop or even maintain the implementation - that's not even the main point. It's the increased complexity that each and every new language construct brings with it, whether we like it or not. I totally agree with you on this one. Maybe extensions bundled with default distribution could be a good solution for adding new things that could be disabled on demand via configuration options. Potentially; Although generally language syntax is typically hard or impossible to implement through extensions. Currently in PHP you can do the same thing about the same way. The difference is that right now, there's a bunch of things missing when compared to other languages and this is a push off. Why does it matter that some features are 'missing'? Do all other languages continuously replicate all of PHP's and other leading languages feature sets too? Different languages have different
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
hi, On Thu, Feb 21, 2013 at 2:59 PM, Zeev Suraski z...@zend.com wrote: That's not adaptation in my book. That's addition. It's not the technology landscape that changed that now you need annotations; It's that some people consider this feature cool and useful, and want to import it into PHP although it does not in fact enable you to do anything you can't do today, while it does add a lot of complexity to the language. I can do everything PHP does in assembler, but I do not implement web apps in assembler. Cheers, -- Pierre @pierrejoye -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Give the Language a Rest motion (fwd)
-Original Message- From: Pierre Joye [mailto:pierre@gmail.com] Sent: Thursday, February 21, 2013 4:08 PM To: Zeev Suraski Cc: Florin Razvan Patan; Lars Strojny; Derick Rethans; PHP Developers Mailing List Subject: Re: [PHP-DEV] Give the Language a Rest motion (fwd) hi, On Thu, Feb 21, 2013 at 2:59 PM, Zeev Suraski z...@zend.com wrote: That's not adaptation in my book. That's addition. It's not the technology landscape that changed that now you need annotations; It's that some people consider this feature cool and useful, and want to import it into PHP although it does not in fact enable you to do anything you can't do today, while it does add a lot of complexity to the language. I can do everything PHP does in assembler, but I do not implement web apps in assembler. Actually no, you can't. You won't live long enough to write a meaningful web app in asm, even if you live to be exceptionally old, and I certainly wish you well. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
On Feb 21, 2013, at 1:56 AM, Zeev Suraski z...@zend.com wrote: There used to be a language that was the Queen of the Web. It was full of clever syntax. It prided itself on having a variety of expressive ways of doing the same thing. You're on the mailing list of the language that dethroned it. This needs to be printed and framed somewhere. Your comments are great, but this last paragraph is magnificent. +1 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
In the slice of the community where I spend most of my time, medium-to-large companies using PHP with their own custom code on hundreds to thousands or even 10's of thousands of servers, neither annotations nor getter/setter are anywhere on their wishlist radar. What they most desire is performance, robustness and security. They would love to see a PHP release that had no syntax changes, no BC changes, but was twice as fast and crashed half as much. I realize this is just one (small?) slice of the community but so is the part of the community wanting annotations. This is the balancing act we have to perform. It is not stubbornness, nor living in the past, it is recognizing that each and every major feature addition has a destabilizing effect on the codebase and if the addition only serves a small slice of the userbase we have to think long and hard about the merits of it. Personally I would love to see more RFCs focusing on performance and less on syntax changes. Of course, a syntax change RFC, and even the initial (often shaky) implementation of a syntax-related change is much much easier to whip up than the deep analysis, profiling and creativity required to find and come up with ways to make a complex piece of code faster or use less memory. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
Hello, didn't read the whole thread, just a few messages at the start. But because I'm replying to the starting message, it's not relevant :) In principle, as a user-land developer, I agree with the motion. It's too much fancy new shiny stuff lately and no actual improvement on the old stuff that really needs fixing or updating/rewriting (PDO anyone? Years behind every db driver extension there is in PHP, and as far as I'm concerned - it should be dropped and concentrate on standardize the db extension public API). As far as I see, there is technical debt piling up and except the actual core developers no one understands that - people just spawn RFC's like crazy. As it was said countless times - PHP core team lacks resources to fix many issues that are already there and new stuff just makes it worse. Actually, if I was a core team member (sadly C is not my love and most of the stuff I want to change requires actual coding), I would push a motion to temporary suspend accepting RFC's that introduce new features and devote release after 5.5 to fixing and rewriting the old stuff and bug fixing. And that can prove to be a much more positive that just new features. I think with last two releases there was ton of stuff added and it will take time to actually grasp it and start using it. Hell, I like traits, but I can't put a finger on how to use them at the moment. And it will take me some considerable time to actually find a place for them and integrate them into my work so that they fit just right. Late static binding? Hell, still didn't use it at all. Anonymous functions - yeah, this one is all over my code now (of course not just for the sake of it) and some other recent stuff I use too. Ok, I have to stop mumbling. What I wanted to say - it will take time for developers, community, frameworks and hosting companies to catch up with the stuff that was introduced in 5.3, 5.4 and will be in 5.5. To my opinion there should be a pause in new additions and time taken to take care of the old stuff that needs love, some need it desperately. Thanks, Arvids.
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
On 21 February 2013 16:30, Rasmus Lerdorf ras...@lerdorf.com wrote: In the slice of the community where I spend most of my time No hard feelings, but it would be awesome if that part of the community (the one that basically avoids social coding as far as I can see, not to be taken as a sin, but still meh) didn't just try to hold back PHP because of business decisions based on obsolescence. If there is some momentum to get change, I see these big brakes set by people who don't even express their opinion nor get interested in newly developed packages over here. It would already be nice to have them provide their opinion, assuming it goes a bit deeper than YAGNI. No BC changes is basically impossible if you want to get better software: improvement comes always with changes. I can absolutely understand that the core team does not have enough human resources to think about new functionality, and probably not even maintenance (I even feel like a stranger forcing his own ideas in here, since I also have no C-fu), but why would this stop things from being suggested? If you don't have time for a feature, then that's perfectly ok: just vote NO. Don't sell us the YAGNI or additional complexity story: annotations and property accessors already demonstrated that there are use cases that even bring performance improvements. Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
On Thu, 2013-02-21 at 16:54 +0100, Marco Pivetta wrote: No hard feelings, but it would be awesome if that part of the community (the one that basically avoids social coding as far as I can see, not to be taken as a sin, but still meh) didn't just try to hold back PHP because of business decisions based on obsolescence. The quoted business decision was We want something stable and fast, an emphasis of fixing bugs over adding new ones. This sounds sane to me. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
On 21 February 2013 17:04, Johannes Schlüter johan...@schlueters.de wrote: The quoted business decision was We want something stable and fast, an emphasis of fixing bugs over adding new ones. This sounds sane to me. johannes Doesn't exclude new features then: so what is this all about? Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
Personally I would love to see more RFCs focusing on performance and less on syntax changes. Some recent tests I performed indicate that JavaScript and Dart are both significantly faster than PHP when working with just arrays and numbers. If anyone is interested I can provide the test code for more scrutiny. I'd like to see more performance enhancements but I am not against other enhancements as well. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
Hello, On Thu, Feb 21, 2013 at 5:30 PM, Rasmus Lerdorf ras...@lerdorf.com wrote: In the slice of the community where I spend most of my time, medium-to-large companies using PHP with their own custom code on hundreds to thousands or even 10's of thousands of servers, neither annotations nor getter/setter are anywhere on their wishlist radar. What they most desire is performance, robustness and security. They would love to see a PHP release that had no syntax changes, no BC changes, but was twice as fast and crashed half as much. I realize this is just one (small?) slice of the community but so is the part of the community wanting annotations. This is the balancing act we have to perform. It is not stubbornness, nor living in the past, it is recognizing that each and every major feature addition has a destabilizing effect on the codebase and if the addition only serves a small slice of the userbase we have to think long and hard about the merits of it. I couldn't agree with you more. While the company that I'm working on just hit the hundred limit, this is one of our concerns as well. And like I've said, stability is a key factor for us. Speed is also critical and I agree that everyone needs more speed any time you ask them. The examples I gave where just examples, not something that I'm crying that is not added to the language but my company is also trying to be open to any new things that would make our lives easier and help us code faster, easier, better and so on. I think it would be helpful to have something like a roadmap with various features and changes both in regards to language and features as well as performance. Also, having a clear line of when features will be deprecated then removed will go a long way to help out users while writing their software. That way, people would know what to expect from the language and when it would be the time to upgrade. You could use the example of JetBrains and how they manage their products via their issue tracker, http://youtrack.jetbrains.com/issues/WI in which everyone that is not part of the core team can 'vote' for a feature or bug or what not and participate in a threaded discussion in a simpler manner. This would bring you a nicer interface that the current ones while being able to also gauge the community interest in certain issues. I think if the PHP group would ask JetBrains for their software for free, they wouldn't say no and I gave them as an example because I'm using their beta software since it the second is out on their download servers and I'm reporting every crash that I can as they made it really easy for me to help them out. And yes, I do feel like the current software stack of PHP.net is a bit out of sync with the modern tools that are already there, sorry if I offend someone. That's why I think that the next major version of PHP should happen sooner rather that later. I'm a strong believer that the current engine is hard to maintain and document and very few people know most of it. PHP 5.5 should be the last 5.X release then you should announce that PHP 6 needs more volunteers for a better (faster) parser, people who can help you on documenting it and so on. Just make PHP 6.0 a PHP 5.5 that's clean under the hood, maybe even brings some performance improvements along the way and that's it. You already know what are the requirements for everything, you already have feedback on what the community wants in the future, so why not help yourself by doing something that's clean and along the way will help you get more contributors? Also please see my other suggestions on how you could get more support from the users. Best regards. Florin Patan https://github.com/dlsniper -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
On 21.02.2013, at 20:08, Levi Morrison morrison.l...@gmail.com wrote: Personally I would love to see more RFCs focusing on performance and less on syntax changes. Some recent tests I performed indicate that JavaScript and Dart are both significantly faster than PHP when working with just arrays and numbers. If anyone is interested I can provide the test code for more scrutiny. I'd like to see more performance enhancements but I am not against other enhancements as well. That is expected. Both of them use JIT-compilation, which is not present in PHP. There was some effort to implement PHP in PyPy/RPython, but it is not active http://morepypy.blogspot.ru/2012/07/hello-everyone.html -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
On 2013-02-21, Rasmus Lerdorf ras...@lerdorf.com wrote: Personally I would love to see more RFCs focusing on performance and less on syntax changes. Of course, a syntax change RFC, and even the initial (often shaky) implementation of a syntax-related change is much much easier to whip up than the deep analysis, profiling and creativity required to find and come up with ways to make a complex piece of code faster or use less memory. +1. I think that the RFC process did the project very good and enabled new people and their patches into the project. Nevertheless we should be aware that a scripting language needs to be robust and fast. The more language syntax we add, the more complex the language gets and therefore it's quality as a very good beginners language. Also we just end up in the troubles we had over the last years when one could just hope that xdebug will catch up with new language changes (thanks to derick it usually does), and one knew that APC will not work. A lot of the language features in the last years didn't just make some people happy but also made others unhappy as they couldn't use the new language in production (and thats what counts). People are stuck with 5.3 atm because there is no opcode cache for 5.4 and the only good news for them is that the ZO+ RFC focuses and robustness and performance so the users will still have an opcache for a new version once 5.3 is EOL (in a year). (and i am not even talking about the headache everyone is already talking about because they used a lot of apc caching functions in their code and therefore are stuck with 5.3 for another 2 years and can just rely on distros for patching). So plesae when one talks about the userbase, make sure you just dont see you part of the bubble but all the others who are struggling with recent changes already. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
replying inline I think it would be helpful to have something like a roadmap with various features and changes both in regards to language and features as well as performance. We have discussed before and the problem is the nature of the project: it is an open source project where the contribution comes from the spare time of the volunters (with a couple of exceptions like people from Oracle working on the mysql drivers/docs etc.). So we can try and plan ahead, but in the end we can only release what we have, and there are no guarantees that somebody will do the job (or do in in a reasonable timeframe). PHP6 was an example of a release where we didn't timeboxed, but feature-boxed, and I think that even without the unicode part, it would still take too long or would have to break some promises. Some of the open source project do something in-between, not promising exact features/ideas for a given release but selecting a couple of areas/aspects where the release should improve on the current situation: that could also work imo. Also, having a clear line of when features will be deprecated then removed will go a long way to help out users while writing their software. That way, people would know what to expect from the language and when it would be the time to upgrade. I think that it isn't necessary a bad thing that we aren't forced to tell beforehand than a given deprecated version will be removed in which version, because this way we can push the decision to a later date, when we have more information to select the best option. I think that Linus had a really good job explaining that in the first chapter of http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=Documentation/ManagementStyle You could use the example of JetBrains and how they manage their products via their issue tracker, http://youtrack.jetbrains.com/issues/WI in which everyone that is not part of the core team can 'vote' for a feature or bug or what not and participate in a threaded discussion in a simpler manner. This would bring you a nicer interface that the current ones while being able to also gauge the community interest in certain issues. We already have comments and voting (and ordering on the votes) in the issue tracker, but if you think that you can improve on the interface, feel free to send a pull request, I'm sure that there is much room for improvements, especially in the UI/UX part. I think if the PHP group would ask JetBrains for their software for free, they wouldn't say no and I gave them as an example because I'm using their beta software since it the second is out on their download servers and I'm reporting every crash that I can as they made it really easy for me to help them out. Not sure how this is related to the discussion, but we already got some licenses from JetBrains (AFAIR Shein Alexey handled that for the phpdoc team). And yes, I do feel like the current software stack of PHP.net is a bit out of sync with the modern tools that are already there, sorry if I offend someone. it is, and it is a chicken and egg problem: even though that the usual my C-fu is weak argument doesn't apply there, we still lack contributors, and the archaic nature of the current codebase doesn't really helps bringing in new people. even if a newcomer would come around with a rewrite of the current bugtracker based on some modern framework (ZF2/sf2/etc.), it would be a hard decision, because who who knows what new bugs that codebase has and there would be a real issue if the original author leaves and there would be no people left having familiar with the codebase. the current codebase sucks, but it had time for the bugs to surface, and the people who work on it are familiar with it. there is also an issue, that most of the php.net infrastructure is older than any other framework lifecycle would provide, so switching to a 3rd party framework would require more maintainence work (ofc. it would also have advantages like better documentation and people outside of the project would have an easier time to jump into contributing to it). That's why I think that the next major version of PHP should happen sooner rather that later. I'm a strong believer that the current engine is hard to maintain and document and very few people know most of it. I'm a little bit confused, so you are talking about the PHP.net software stack or about the toolchain/stack used for the development of the language? I think that the current documentation team is doing a fine job (ofc. there is also room for improvement, like better/tigher integration/communication between the php-core and the documentation team), PHP 5.5 should be the last 5.X release then you should announce that PHP 6 needs more volunteers for a better (faster) parser, people who can help you on documenting it and so on. I think that we definitely need to be more engaging for the possible contributors, making it as easy as
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
Le 21/02/2013 18:56, Ferenc Kovacs a écrit : it is, and it is a chicken and egg problem: even though that the usual my C-fu is weak argument doesn't apply there, we still lack contributors, and the archaic nature of the current codebase doesn't really helps bringing in new people. even if a newcomer would come around with a rewrite of the current bugtracker based on some modern framework (ZF2/sf2/etc.), it would be a hard decision, because who who knows what new bugs that codebase has and there would be a real issue if the original author leaves and there would be no people left having familiar with the codebase. the current codebase sucks, but it had time for the bugs to surface, and the people who work on it are familiar with it. Maybe using a bug tracking system that is maintained by another project would be a good idea? I am specifically thinking of Bugzilla which is already used by many open source projects. It has a lot more features than your current bug tracking system, it scales for large projects and it has a few Mozilla employees working full time on it. Pascal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
On Thu, Feb 21, 2013 at 10:13 AM, Pascal Chevrel pascal.chev...@free.fr wrote: I am specifically thinking of Bugzilla which is already used by many open source projects. It has a lot more features than your current bug tracking system, it scales for large projects and it has a few Mozilla employees working full time on it. every bugzilla instance I've seen is obnoxious, ugly, too many options, etc. It's also written in that old, archaic language that PHP replaced. Ask the question: what is the current bug system not meeting? probably needs a couple tweaks is all. I bet it's written in PHP, too. Fancy that? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
On Thu, 2013-02-21 at 19:13 +0100, Pascal Chevrel wrote: I am specifically thinking of Bugzilla which is already used by many open source projects. It has a lot more features than your current bug tracking system, it scales for large projects and it has a few Mozilla employees working full time on it. I'm a passive user of bugzilla, not involved with any project using it but every time I have to report a bug on a project using it I think twice, why do I have to register and run away if I have to remember the password I used 2 years ago when reporting my last bug. bugs.php.net might not be as shiny as others but it makes reporting easy, fill in a captcha and you are done, no registration or such, you might even use a fake mail address (not that it necessarily helps to be unreachable for getting things resolved) And then there is a religious thing: Bugzilla is written in a legacy language ;-) And yes. it has some rough edges, but it get's it's job done, integrates with out user system, our what's the current version-notification system, ... johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
Arvids Godjuks wrote: In principle, as a user-land developer, I agree with the motion. It's too much fancy new shiny stuff lately and no actual improvement on the old stuff that really needs fixing or updating/rewriting (PDO anyone? Years behind every db driver extension there is in PHP, and as far as I'm concerned - it should be dropped and concentrate on standardize the db extension public API). A BIG +1 on that ... there are a number of better options which would actually be a step forward rather than dragging everything back to the past with PDO's limited API ! -- 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] Give the Language a Rest motion (fwd)
On Thu, 2013-02-21 at 17:06 +0100, Marco Pivetta wrote: On 21 February 2013 17:04, Johannes Schlüter johan...@schlueters.de wrote: The quoted business decision was We want something stable and fast, an emphasis of fixing bugs over adding new ones. This sounds sane to me. Doesn't exclude new features then: so what is this all about? * We have limited development resources * Developers can either fix bugs and tune code or add features * All new features go through different rounds of fixing newly introduced bugs * All new features increase the amount of things to maintain long-term I'm not against new features, but sometimes I wonder about the focus. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
On 02/21/2013 01:04 PM, Johannes Schlüter wrote: On Thu, 2013-02-21 at 17:06 +0100, Marco Pivetta wrote: On 21 February 2013 17:04, Johannes Schlüter johan...@schlueters.de wrote: The quoted business decision was We want something stable and fast, an emphasis of fixing bugs over adding new ones. This sounds sane to me. Doesn't exclude new features then: so what is this all about? * We have limited development resources * Developers can either fix bugs and tune code or add features * All new features go through different rounds of fixing newly introduced bugs * All new features increase the amount of things to maintain long-term I'm not against new features, but sometimes I wonder about the focus. Traits is a good example of that. We, and by we I mean Dmitry, are still fixing problems with Traits and we are closing in on 5 years after the initial proposal in 2008. And Traits is sort of middle of the road in terms of complexity. We have had more complex things proposed and we still only have one Dmitry. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
Hello List, how about sort of Tick-Tock development model? Tick = optimize/bugfix Tock = shiny new features e.g. http://en.wikipedia.org/wiki/Intel_Tick-Tock cryptocompress -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
Hi! F.e., how long have we been battled for annotations? With all respects, it is about being blind and stubborn to say that PHP should not have annotations. But due to some I'm happy with what we have It is about being blind and stubborn to hold opinion different than yours. And *this* not an opinion but a fact. Got it. This is not about borking the language with useless features. This is not about being on the cutting edge. this is about catching up with the competition. Keeping up with the Joneses is not a good idea in personal life, and is not a good idea in language design. Not everything Joneses have we should have, just because they do. You have to have better reasons. Sometimes there are better reasons, and we do borrow all the time. But doing that *just* because they have it makes little sense. *When* we decide that it makes sense for PHP, then we can look at how others do it and see if it translates. -- 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] Give the Language a Rest motion (fwd)
2013/2/21 Johannes Schlüter johan...@schlueters.de On Thu, 2013-02-21 at 19:13 +0100, Pascal Chevrel wrote: I am specifically thinking of Bugzilla which is already used by many open source projects. It has a lot more features than your current bug tracking system, it scales for large projects and it has a few Mozilla employees working full time on it. I'm a passive user of bugzilla, not involved with any project using it but every time I have to report a bug on a project using it I think twice, why do I have to register and run away if I have to remember the password I used 2 years ago when reporting my last bug. bugs.php.net might not be as shiny as others but it makes reporting easy, fill in a captcha and you are done, no registration or such, you might even use a fake mail address (not that it necessarily helps to be unreachable for getting things resolved) And then there is a religious thing: Bugzilla is written in a legacy language ;-) And yes. it has some rough edges, but it get's it's job done, integrates with out user system, our what's the current version-notification system, ... I think there may come many critics maybe, but why not move those things also to github? It's used by many people. it works, it's easy! Zend Framework also done the move from SVN, signing a CLA, own Bug tracking system. to github and I think it couldn't be better now!
[PHP-DEV] Give the Language a Rest motion (fwd)
Looks like it is time to forward this email from 2006 again: -- Forwarded message -- Date: Thu, 09 Mar 2006 12:57:32 +0200 From: Zeev Suraski z...@zend.com To: internals@lists.php.net Subject: [PHP-DEV] Give the Language a Rest motion I'd like to raise a motion to 'Give the Language a Rest'. Almost a decade since we started with the 2nd iteration on the syntax (PHP 3), and 2 more major versions since then, and we're still heatedly debating on adding new syntactical, core level features. Is it really necessary? I'd say in almost all cases the answer's no, and a bunch of cases where a new feature could be useful does not constitute a good enough reason to add a syntax level feature. We might have to account for new technologies, or maybe new ways of thinking that might arise, but needless to say, most of the stuff we've been dealing with in recent times doesn't exactly fall in the category of cutting edge technology. My motion is to make it much, much more difficult to add new syntax-level features into PHP. Consider only features which have significant traction to a large chunk of our userbase, and not something that could be useful in some extremely specialized edge cases, usually of PHP being used for non web stuff. How do we do it? Unfortunately, I can't come up with a real mechanism to 'enforce' a due process and reasoning for new features. Instead, please take at least an hour to bounce this idea in the back of your mind, preferably more. Make sure you think about the full context, the huge audience out there, the consequences of making the learning curve steeper with every new feature, and the scope of the goodness that those new features bring. Consider how far we all come and how successful the PHP language is today, in implementing all sorts of applications most of us would have never even thought of when we created the language. Once you're done thinking, decide for yourself. Does it make sense to be discussing new language level features every other week? Or should we, perhaps, invest more in other fronts, which would be beneficial for a far bigger audience. The levels above - extensions to keep with the latest technologies, foundation classes, etc. Pretty much, the same direction other mature languages went to. To be clear, and to give this motion higher chances of success, I'm not talking about jump. PHP can live with jump, almost as well as it could live without it :) I'm talking about the general sentiment. Zeev -- 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] Give the Language a Rest motion (fwd)
I would also say it us time for us to get back in sync with the communities needs. I am not talking about the last days RFCs but in general. On Feb 20, 2013 7:19 PM, Derick Rethans der...@php.net wrote: Looks like it is time to forward this email from 2006 again: -- Forwarded message -- Date: Thu, 09 Mar 2006 12:57:32 +0200 From: Zeev Suraski z...@zend.com To: internals@lists.php.net Subject: [PHP-DEV] Give the Language a Rest motion I'd like to raise a motion to 'Give the Language a Rest'. Almost a decade since we started with the 2nd iteration on the syntax (PHP 3), and 2 more major versions since then, and we're still heatedly debating on adding new syntactical, core level features. Is it really necessary? I'd say in almost all cases the answer's no, and a bunch of cases where a new feature could be useful does not constitute a good enough reason to add a syntax level feature. We might have to account for new technologies, or maybe new ways of thinking that might arise, but needless to say, most of the stuff we've been dealing with in recent times doesn't exactly fall in the category of cutting edge technology. My motion is to make it much, much more difficult to add new syntax-level features into PHP. Consider only features which have significant traction to a large chunk of our userbase, and not something that could be useful in some extremely specialized edge cases, usually of PHP being used for non web stuff. How do we do it? Unfortunately, I can't come up with a real mechanism to 'enforce' a due process and reasoning for new features. Instead, please take at least an hour to bounce this idea in the back of your mind, preferably more. Make sure you think about the full context, the huge audience out there, the consequences of making the learning curve steeper with every new feature, and the scope of the goodness that those new features bring. Consider how far we all come and how successful the PHP language is today, in implementing all sorts of applications most of us would have never even thought of when we created the language. Once you're done thinking, decide for yourself. Does it make sense to be discussing new language level features every other week? Or should we, perhaps, invest more in other fronts, which would be beneficial for a far bigger audience. The levels above - extensions to keep with the latest technologies, foundation classes, etc. Pretty much, the same direction other mature languages went to. To be clear, and to give this motion higher chances of success, I'm not talking about jump. PHP can live with jump, almost as well as it could live without it :) I'm talking about the general sentiment. Zeev -- 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] Give the Language a Rest motion (fwd)
As a general reply: I’d like to disagree, and here is why. Yes, we should not let half baked features in but we need to add more and more features, also syntax wise. For three reasons: - Parity/expectations/me too: so you can do that in PHP as well - Expressiveness: allow better ways to express the same idea in more concise ways - Innovation: bring unexpected features to the language people didn’t even expect Let’s recall a few of the latest additions: - 5.3: namespaces. Provided the foundation for awesome stuff like PSR-1, which in turn provides the foundation for the even more awesome stuff composer is. - 5.3: goto. A good thing we can do it. I'm not sure for what exactly but I am sure there is somebody out there :) - 5.3: Closures, huge thing for us, a matter of parity to other languages. Really changes the face of a lot of APIs (see e.g. Doctrine transactional(), the whole micro framework movement, React) - 5.4: Closures 2.0 with $this binding. Honestly, without it, Closures are a little meh. But it was good we waited and got it right. - 5.4: Short array syntax. A parity/culture issue. - 5.4: Traits, I am happy we got horizontal reuse right - 5.4: array dereferencing. Very small but useful. To me it feels more like a bugfix - 5.4: callable type hint. Small change with a huge impact - 5.5: Generators, also a matter of parity and a matter of awesomeness - 5.5: ClassName::class syntax. A really good improvement to the overall usability of namespaces. Just imagine how much shorter unit test setUp() methods will become What we have on our list that, from my perspective, will sooner or later hit us: - Property accessors in some form or another: a lot of people seem to like it. - Annotation support: we would have a lot of customers for it. - Autoboxing for primitives. Allows us to fix a lot of problems in ext/standard. - Unicode. Obviously. - Named parameters. A recurring topic might be a topic worth digging deeper. - I'm positive the Generics discussion will arise at some point again. … and these are just the changes on a syntax/semantics level, I'm not talking about all the awesome technologies (one of which you are working on) we need to integrate tighter and eventually bundle with core. I don’t believe we should let our users outgrow the language, quite the opposite, we should grow with our users and the broader web community, otherwise we will fail. PHP is nowadays used for tasks it never was intended to be used but that’s a good thing. We need to continuously adapt. What’s true for software projects is true for languages: stop improving actually reduces its value over time. cu, Lars Am 20.02.2013 um 19:18 schrieb Derick Rethans der...@php.net: Looks like it is time to forward this email from 2006 again: -- Forwarded message -- Date: Thu, 09 Mar 2006 12:57:32 +0200 From: Zeev Suraski z...@zend.com To: internals@lists.php.net Subject: [PHP-DEV] Give the Language a Rest motion I'd like to raise a motion to 'Give the Language a Rest'. Almost a decade since we started with the 2nd iteration on the syntax (PHP 3), and 2 more major versions since then, and we're still heatedly debating on adding new syntactical, core level features. Is it really necessary? I'd say in almost all cases the answer's no, and a bunch of cases where a new feature could be useful does not constitute a good enough reason to add a syntax level feature. We might have to account for new technologies, or maybe new ways of thinking that might arise, but needless to say, most of the stuff we've been dealing with in recent times doesn't exactly fall in the category of cutting edge technology. My motion is to make it much, much more difficult to add new syntax-level features into PHP. Consider only features which have significant traction to a large chunk of our userbase, and not something that could be useful in some extremely specialized edge cases, usually of PHP being used for non web stuff. How do we do it? Unfortunately, I can't come up with a real mechanism to 'enforce' a due process and reasoning for new features. Instead, please take at least an hour to bounce this idea in the back of your mind, preferably more. Make sure you think about the full context, the huge audience out there, the consequences of making the learning curve steeper with every new feature, and the scope of the goodness that those new features bring. Consider how far we all come and how successful the PHP language is today, in implementing all sorts of applications most of us would have never even thought of when we created the language. Once you're done thinking, decide for yourself. Does it make sense to be discussing new language level features every other week? Or should we, perhaps, invest more in other fronts, which would be beneficial for a far bigger audience. The levels above - extensions to keep with the latest
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
- 5.3: goto. A good thing we can do it. I'm not sure for what exactly but I am sure there is somebody out there :) An associate of mine used it in his HTTP message parser. He's sure glad it's there :) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
Levi Morrison wrote: - 5.3: goto. A good thing we can do it. I'm not sure for what exactly but I am sure there is somebody out there :) An associate of mine used it in his HTTP message parser. He's sure glad it's there :) Conversely, I have two HTTP message parsers that I maintain, and neither of them use goto. Certainly possible to avoid it there. That said, I do think goto has legitimate uses, even if I don't need it. -- Ryan McCue http://ryanmccue.info/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
Le 16/06/2011 08:10, Stas Malyshev a écrit : Hi! what I did every single time. Among all my bug reports I had one answer from decoder-...@own-hero.net (thanks to him) who reduced the test case for a memory leak (bug 54460). I'm not talking about bugs in modules but bugs in *core* which can be reproduced with few lines of *core* PHP. I am reading the list pretty closely and I don't remember any emails from you raising the question of reproducible corruption bugs recently, except indeed for 54460 which seems to be a memory leak, bug 54460 has disapeared from bugs.php.net . Is due to the crash ? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
On Wed, Jun 29, 2011 at 3:36 PM, Pascal COURTOIS pascal.court...@nouvo.com wrote: Le 16/06/2011 08:10, Stas Malyshev a écrit : Hi! what I did every single time. Among all my bug reports I had one answer from decoder-...@own-hero.net (thanks to him) who reduced the test case for a memory leak (bug 54460). I'm not talking about bugs in modules but bugs in *core* which can be reproduced with few lines of *core* PHP. I am reading the list pretty closely and I don't remember any emails from you raising the question of reproducible corruption bugs recently, except indeed for 54460 which seems to be a memory leak, bug 54460 has disapeared from bugs.php.net . Is due to the crash ? I also tried to access a bug linkg and bug.php?id=xxx failed to work. Has there been a data problem ? -- 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] Give the Language a Rest motion (fwd)
On Wed, Jun 29, 2011 at 16:43, Paul Dragoonis dragoo...@gmail.com wrote: On Wed, Jun 29, 2011 at 3:36 PM, Pascal COURTOIS pascal.court...@nouvo.com wrote: Le 16/06/2011 08:10, Stas Malyshev a écrit : Hi! what I did every single time. Among all my bug reports I had one answer from decoder-...@own-hero.net (thanks to him) who reduced the test case for a memory leak (bug 54460). I'm not talking about bugs in modules but bugs in *core* which can be reproduced with few lines of *core* PHP. I am reading the list pretty closely and I don't remember any emails from you raising the question of reproducible corruption bugs recently, except indeed for 54460 which seems to be a memory leak, bug 54460 has disapeared from bugs.php.net . Is due to the crash ? I also tried to access a bug linkg and bug.php?id=xxx failed to work. Has there been a data problem ? No. Some people just wanted some bugsweb so an old database was restored rather then waiting few hours for the actual data export. We have the data now and work is now ongoing migrating the two now. museum is also up, and snaps will probably be running before the weekend. -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
Le 29/06/2011 16:57, Hannes Magnusson a écrit : We have the data now and work is now ongoing migrating the two now. museum is also up, and snaps will probably be running before the weekend. great, thanks :-) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
On Jun 29, 2011, at 7:43 AM, Paul Dragoonis wrote: On Wed, Jun 29, 2011 at 3:36 PM, Pascal COURTOIS pascal.court...@nouvo.com wrote: Le 16/06/2011 08:10, Stas Malyshev a écrit : Hi! what I did every single time. Among all my bug reports I had one answer from decoder-...@own-hero.net (thanks to him) who reduced the test case for a memory leak (bug 54460). I'm not talking about bugs in modules but bugs in *core* which can be reproduced with few lines of *core* PHP. I am reading the list pretty closely and I don't remember any emails from you raising the question of reproducible corruption bugs recently, except indeed for 54460 which seems to be a memory leak, bug 54460 has disapeared from bugs.php.net . Is due to the crash ? I also tried to access a bug linkg and bug.php?id=xxx failed to work. Has there been a data problem ? A recent backup was restored minutes ago, so these bugs are back again. Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
On Wed, Jun 29, 2011 at 4:36 PM, Pascal COURTOIS pascal.court...@nouvo.com wrote: bug 54460 has disapeared from bugs.php.net . Is due to the crash ? Yes, the data was not available by the time we release PHP 5.4.0-alpha1. So we went with an alternative and temporary solution, see http://news.php.net/php.internals/53635 As you can see the data has been now restored and everything went fine as planed in our alternative plan. The old bugs will be editable again in the next couple of hours. Thanks for your understanding, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
On Wed, Jun 29, 2011 at 4:57 PM, Hannes Magnusson hannes.magnus...@gmail.com wrote: No. Some people just wanted some bugsweb so an old database was restored rather then waiting few hours for the actual data export. The some people actually make it so that bugs.php.net was available by the time 5.4.0 was released. After having waiting more than two weeks with absolutely zero progress nor info about a possible recovery of the data. I would appreciate if you would show a bit more respect to the people actually making the work and keep the house working, now and later. Thanks. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
On Thu, Jun 16, 2011 at 12:14 AM, Pascal COURTOIS pascal.court...@nouvo.com wrote: Le 16/06/2011 04:36, dukeofgaming a écrit : Hi, I think that —in any context— the if it aint broke don't fix it is a very depressing attitude to have, and a very wrong one in any open source community. What I feel depressing is the urge of the PHP core team to fix working features instead of focusing on the 1800 open bug tickets. Sorry if the question is dumb, but, how many core developers does PHP have?, how many in total (including non-core contributors)?. Regards, David
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
Hi! what I did every single time. Among all my bug reports I had one answer from decoder-...@own-hero.net (thanks to him) who reduced the test case for a memory leak (bug 54460). I'm not talking about bugs in modules but bugs in *core* which can be reproduced with few lines of *core* PHP. I am reading the list pretty closely and I don't remember any emails from you raising the question of reproducible corruption bugs recently, except indeed for 54460 which seems to be a memory leak, though presence of xcache in the trace suggests it may not even be a PHP bug. It talks about bug in a template engine containing thousands of lines. This is pretty hard work to debug something starting with huge unknown code, so no wonder nobody got to it yet. PHP is a volunteer project, and it's not easy to find volunteers to dig into thousand lines of unknown code to find a bug that may not even be there. It's quite a hard work. I must have missed other ones. But if they are still reproducible in 5.4 and you have reproducing code, you're welcome to share on the list. Unfortunately, bugs.php.net seems to be down, but once it gets up we could look into it and see if we can fix any. As I said, good reproduction makes it better. -- 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] Give the Language a Rest motion (fwd)
Le 16/06/2011 08:01, dukeofgaming a écrit : Sorry if the question is dumb, but, how many core developers does PHP have?, how many in total (including non-core contributors)?. That's not the point. Whatever the project is, every developer should fix existing bugs before even thinking about improving. That's the way I do and that's why there is no bug I'm aware in my programs. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
On Wed, 15 Jun 2011 23:10:24 -0700, Stas Malyshev wrote: Hi! what I did every single time. Among all my bug reports I had one answer Stas, how I can i finally persuade you to quote the name of the people you're replying to? :) I find it very hard to follow any discussion you're involved in. Thanks, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
On Thu, Jun 16, 2011 at 1:12 AM, Pascal COURTOIS pascal.court...@nouvo.comwrote: Le 16/06/2011 08:01, dukeofgaming a écrit : Sorry if the question is dumb, but, how many core developers does PHP have?, how many in total (including non-core contributors)?. That's not the point. Whatever the project is, every developer should fix existing bugs before even thinking about improving. That's the way I do and that's why there is no bug I'm aware in my programs. I really mean the question, regardless.
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
Le 16/06/2011 08:10, Stas Malyshev a écrit :
Hi!
what I did every single time. Among all my bug reports I had one
answer from decoder-...@own-hero.net (thanks to him) who reduced
the test case for a memory leak (bug 54460). I'm not talking about
bugs in modules but bugs in *core* which can be reproduced with few
lines of *core* PHP.
I am reading the list pretty closely and I don't remember any emails
from you raising the question of reproducible corruption bugs
recently, except indeed for 54460 which seems to be a memory leak,
though presence of xcache in the trace suggests it may not even be a
PHP bug. It talks about bug in a template engine containing thousands
of lines. This is pretty hard work to debug something starting with
huge unknown code, so no wonder nobody got to it yet. PHP is a
volunteer project, and it's not easy to find volunteers to dig into
thousand lines of unknown code to find a bug that may not even be
there. It's quite a hard work.
as I said earlier, test case was reduced to:
?php
class TempleetRedirect extends Exception {};
Function parseform($template) {
$txt = eval_list($templatecache[$template]['template']);
}
Function eval_list($array) {
throw new TempleetRedirect($file);
}
Function parsetemplate($template) {
$txt = parseform($template);
}
try
{
$output=parsetemplate($global_var['template']);
}
catch (TempleetRedirect $r)
{
exit();
}
?
as you can see there's nothing but PHP core instructions in that code.
I must have missed other ones. But if they are still reproducible in
5.4 and you have reproducing code, you're welcome to share on the
list. Unfortunately, bugs.php.net seems to be down, but once it gets
up we could look into it and see if we can fix any.
for memory leaks if the bug is fixed it will not happen again but
for memory corruption it's something totaly different. The fact that
a bug disapears doesn't mean in any way it has been fixed.
As I said, good
reproduction makes it better.
I've been debugging in lots of languages including assembly codes
for over 30 years so I know precisely what you mean. So when it's
possible to reproduce a bug in some known conditions, the wait-and-see
attitude is not a good option because it's very likely that the bug
will disapear. Memory coruptions are much like terrorist attacks:
you never know where and when it will happen.
In bug 614904 I submitted a TWO lines program which crashed PHP on
a absolutely standard i386 debian install. I got no answer.
Of course the bug disapeared in following versions of PHP but what is fixed ?
Not as far as I know.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
Pascal COURTOIS wrote: What I need is a very stable language on which I can rely and I'm very sad to to say PHP is getting worse and worse on that point of view versions after versions. I can not contradict your experience, it is what it is, but my experience for years working with PHP was exactly the opposite. To tell you the truth, I've been asked to rewrite the framework I did in Ruby because of these problems. I'm of course very reluctant to go that way but in the end I may have no choice:-( Pascal I am sure that many people here would be more than happy to hear about particular problems you are hitting. Like Stas I have never had problems with the stability of PHP5 in 10 years of running it. YES I can get it to crash, but it has always told me why and fixing the problem clears that up. I do have sites that become unstable, but I have yet to find a situation where PHP was the problem ... My grumble is with having to rewrite code simply because someone has decided that what I was doing is no longer acceptable ... if I can run my code with display_errors ON then I know I've got clean code :) -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
Le 16/06/2011 08:52, Lester Caine a écrit : Pascal I am sure that many people here would be more than happy to hear about particular problems you are hitting. Ok, then why when I signal a bug noone cares ? Like Stas I have never had problems with the stability of PHP5 in 10 years of running it. PHP5 did not exist 10 years ago ;-) Anyway, around 2001 it took me one year (not full time) to find out there was a memory corruption in PHP. At that time I was using mod_php. It crashed Apache. YES I can get it to crash, but it has always told me why and fixing the problem clears that up. I do have sites that become unstable, but I have yet to find a situation where PHP was the problem ... when you have a bug in PHP it should not ever ever crash PHP and unfortunately I encountered that case dozens of times. My grumble is with having to rewrite code simply because someone has decided that what I was doing is no longer acceptable ... if I can run my code with display_errors ON then I know I've got clean code :) I 1000% agree -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
Pascal COURTOIS wrote: Like Stas I have never had problems with the stability of PHP5 in 10 years of running it. PHP5 did not exist 10 years ago ;-) OK coming on 8 years ... seems longer :) I looked at PHP4, but PHP5 was at release candidate stage so I decided that I'd skip straight to that. But I still had to learn PHP4 as people expected backwards compatibility. My ISP 1and1 STILL list PHP4 as the default for virtual hosting :( Anyway, around 2001 it took me one year (not full time) to find out there was a memory corruption in PHP. At that time I was using mod_php. It crashed Apache. YES I can get it to crash, but it has always told me why and fixing the problem clears that up. I do have sites that become unstable, but I have yet to find a situation where PHP was the problem ... when you have a bug in PHP it should not ever ever crash PHP and unfortunately I encountered that case dozens of times. At least on Linux is just recovers and carries on The earlier windows stuff I had used to just crash the whole machine. PHP was something of a refreshing change ... I am behind you on getting what we have a lot better. Many thing have been pushed in and then forgotten ... like PDO! -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
On Jun 15, 2011, at 11:34 PM, dukeofgaming wrote: On Thu, Jun 16, 2011 at 1:12 AM, Pascal COURTOIS pascal.court...@nouvo.comwrote: Le 16/06/2011 08:01, dukeofgaming a écrit : Sorry if the question is dumb, but, how many core developers does PHP have?, how many in total (including non-core contributors)?. That's not the point. Whatever the project is, every developer should fix existing bugs before even thinking about improving. That's the way I do and that's why there is no bug I'm aware in my programs. I really mean the question, regardless. It's difficult to say, but there are a total of 1,568 php.net accounts. The karma[1] rules aren't straightforward to parse but quickly it shows at least 194 people with full php-src[2] karma, and 54 humans made 1,971 SVN commits to php-src within the last 365 days. Those numbers include tests, so the number of ~active core developers appears closer to 10-20. Of course this doesn't include other parts like PECL and documentation but enough hastily created and probably misleading statistics for today. As for the point of the question, php.net could certainly use more contributors and ideally we'd clone Felipe. A lot. [1] http://svn.php.net/viewvc/SVNROOT/global_avail?view=markup [2] http://svn.php.net/viewvc/php/php-src/ Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
Le 16/06/2011 09:19, Lester Caine a écrit : when you have a bug in PHP it should not ever ever crash PHP and unfortunately I encountered that case dozens of times. At least on Linux is just recovers and carries on If PHP crashes, yes, it recovers but it's VERY resource and time consumming. If PHP corrupts some memory, it does not crash fastcgi processes but the next request(s) behave erratically. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
On 6/15/11 11:38 PM, Pascal COURTOIS wrote: In bug 614904 I submitted a TWO lines program which crashed PHP on a absolutely standard i386 debian install. I got no answer. Of course the bug disapeared in following versions of PHP but what is fixed ? Not as far as I know. 614904 doesn't look like real bug number. Must be a typo. -- 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] Give the Language a Rest motion (fwd)
Le 16/06/2011 09:29, Stas Malyshev a écrit : On 6/15/11 11:38 PM, Pascal COURTOIS wrote: In bug 614904 I submitted a TWO lines program which crashed PHP on a absolutely standard i386 debian install. I got no answer. Of course the bug disapeared in following versions of PHP but what is fixed ? Not as far as I know. 614904 doesn't look like real bug number. Must be a typo. ooops, sorry. You're right. It's a bug I submitted to debian because of the way they work with releases having a version with no feature update but including security updates, which means the versions in debian distribution are not exactly the ones released. Since debian requires that bug submitted should not be submitted also to program developpers, I complied. May be it was a mistake... -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
On 6/15/11 11:38 PM, Pascal COURTOIS wrote: as I said earlier, test case was reduced to: The leaks you'll be seeing in this code is probably caused by the fact that main function (i.e. global context) is not destroyed when exit() is called, since . It can be argued as a bug, but very minor one and totally unlikely to cause any problems both because the leak is minuscule and the fact that memory manager will clean it up anyway on shutdown. I would have very hard time believing this very short-time leak can cause any problems in any production code. -- 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] Give the Language a Rest motion (fwd)
Le 16/06/2011 09:56, Stas Malyshev a écrit : On 6/15/11 11:38 PM, Pascal COURTOIS wrote: as I said earlier, test case was reduced to: The leaks you'll be seeing in this code is probably caused by the fact that main function (i.e. global context) is not destroyed when exit() is called, since . It can be argued as a bug, but very minor one and totally unlikely to cause any problems both because the leak is minuscule and the fact that memory manager will clean it up anyway on shutdown. If you call minuscule a leak that requires more than 128Mb as it normally requires about 4Mb, then it's minuscule but whatever you name it it just does not run. I would have very hard time believing this very short-time leak can cause any problems in any production code. It does -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
Hi! On 6/16/11 1:05 AM, Pascal COURTOIS wrote: If you call minuscule a leak that requires more than 128Mb as it normally requires about 4Mb, then it's minuscule but whatever you name it it just does not run. Sorry, if your example generates memory footprint of 128Mb, something is seriously wrong with your build. There's no way this code can produce 128Mb footprint. If it's another code, they we'd need to investigate what causes that leak, which must be different from the one this code produces. -- 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] Give the Language a Rest motion (fwd)
Le 16/06/2011 10:12, Stas Malyshev a écrit : Hi! On 6/16/11 1:05 AM, Pascal COURTOIS wrote: If you call minuscule a leak that requires more than 128Mb as it normally requires about 4Mb, then it's minuscule but whatever you name it it just does not run. Sorry, if your example generates memory footprint of 128Mb, something is seriously wrong with your build. There's no way this code can produce 128Mb footprint. If it's another code, they we'd need to investigate what causes that leak, that's a deal. I have no time right now but I will summerize on tuesday the whole thing that leaded to this code. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
On Thu, Jun 16, 2011 at 3:46 AM, Andi Gutmans a...@zend.com wrote: -Original Message- From: Pierre Joye [mailto:pierre@gmail.com] Sent: Wednesday, June 15, 2011 2:33 AM To: Andi Gutmans Cc: Derick Rethans; PHP Developers Mailing List Subject: Re: [PHP-DEV] Give the Language a Rest motion (fwd) On Wed, Jun 15, 2011 at 7:02 AM, Andi Gutmans a...@zend.com wrote: Hence my suggestion to bundle MongoDB extension and possibly work on additional extensions. Some of my suggestions probably rightfully didn't get much interest such as Thrift. See my comment in your other thread and below. Maybe we should consider making a list of extensions we think could be beneficial and the new mentorship program can actually help deliver some of them? I do not thnk it is a good thing to begin a discussion about this exact topic and then totally ignore it. I think it got lost in the very long and varying discussions. Will dig up and take a look. I had a couple of hectic weeks. It was not a long discussion and you began this thread :) http://news.php.net/php.internals/52898 I also think that it is somehow wrong to post something asking to do not propose new things when we finally have more people involved in proposals and discussions. Maybe that's just me me but I do think that the main problem we have (besides the ones we identified and try to fix right now) is the complete lack of open discussions about possible new features, in this list with new or existing contributors. I did not say we should not propose or have discussions (I am in favor of adding [] for arrays for example). But I am saying the bias should be not to include new language functionality unless it has very broad appeal serious upside impact. The bias should be against feature creep. Right, that's why we introduce a voting RFC in addition to the release RFC, with some large majority concept. However I still think that such posts are inappropriate, timely and generally, while being of freedom of speak ;-) Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
On Thu, 2011-06-16 at 08:12 +0200, Pascal COURTOIS wrote: Le 16/06/2011 08:01, dukeofgaming a écrit : Sorry if the question is dumb, but, how many core developers does PHP have?, how many in total (including non-core contributors)?. That's not the point. Whatever the project is, every developer should fix existing bugs before even thinking about improving. That's the way I do and that's why there is no bug I'm aware in my programs. Feel free to contribute. PHP is driven by volunteers spending their free time on it. For many it is more fun to implement new stuff they probably need than fixing bugs in some code which has some side effects which are not always easy to predict and which they actually don't use. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
Le 16/06/2011 11:36, Johannes Schlüter a écrit : On Thu, 2011-06-16 at 08:12 +0200, Pascal COURTOIS wrote: Le 16/06/2011 08:01, dukeofgaming a écrit : Sorry if the question is dumb, but, how many core developers does PHP have?, how many in total (including non-core contributors)?. That's not the point. Whatever the project is, every developer should fix existing bugs before even thinking about improving. That's the way I do and that's why there is no bug I'm aware in my programs. Feel free to contribute. PHP is driven by volunteers spending their free time on it. I know. I also have a GPL project. Nonetheless some societies use it, and some people rely on it to get paid. I have absolutely no legal contract with anyone but I have a moral contract and when I'm signaled a bug, it is mostly fixed within few hours. I just can't imagine replying to a bug submission Hey guy, its a free project. Why don't you fix it yourself ? My conscience tells me to not release a program if people using it can shoot themself in the foot. For many it is more fun to implement new stuff they probably need than fixing bugs in some code which has some side effects which are not always easy to predict and which they actually don't use. If you followed the thread you have seen the reduced test case is VERY short and the ONLY constructions involved are user functions and exceptions. FULL STOP. Not even a single addition nor a loop nor nothing. I can't imagine nobody uses user functions and exceptions. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
2011/6/16 Pascal COURTOIS pascal.court...@nouvo.com: I know. I also have a GPL project. Nonetheless some societies use it, and some people rely on it to get paid. I have absolutely no legal contract with anyone but I have a moral contract and when I'm signaled a bug, it is mostly fixed within few hours. I just can't imagine replying to a bug submission Hey guy, its a free project. Why don't you fix it yourself ? My conscience tells me to not release a program if people using it can shoot themself in the foot. It is not what Johannes said and we do fix bugs every single day. What Johannes said is that we can't force a volunteer to do something specific instead of what he wants to do. It is also totally off topic btw. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
Le 16/06/2011 12:12, Pierre Joye a écrit : It is not what Johannes said and we do fix bugs every single day. What Johannes said is that we can't force a volunteer to do something specific instead of what he wants to do. It is also totally off topic btw. It is really on topic since letting someone insert his wonderful clever feature in a project, whatever it is, and not maintain it is a project management problem. PHP makes me think of a ship with tens of stirring wheels. Of course no one can be forced to do what he doesn't want but a free project doesn't mean unmanaged project and a managed project means people with responsibilities. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
On 06/16/2011 11:03 AM, Pascal COURTOIS wrote: If you followed the thread you have seen the reduced test case is VERY short and the ONLY constructions involved are user functions and exceptions. FULL STOP. Not even a single addition nor a loop nor nothing. I can't imagine nobody uses user functions and exceptions. You might also consider that your particular case is rather unique. I tried your test case and saw no leak after the request. Everything is freed on request shutdown. That means that for pretty much everyone doing standard short web requests, this style of code would work perfectly for them. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
Le 16/06/2011 12:31, Rasmus a écrit : On 06/16/2011 11:03 AM, Pascal COURTOIS wrote: If you followed the thread you have seen the reduced test case is VERY short and the ONLY constructions involved are user functions and exceptions. FULL STOP. Not even a single addition nor a loop nor nothing. I can't imagine nobody uses user functions and exceptions. You might also consider that your particular case is rather unique. I since decoder-...@own-hero.net could reduce the case from my original program in the conditions I stated, he could obvously detect the leaks. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
On Thu, 2011-06-16 at 12:26 +0200, Pascal COURTOIS wrote: Le 16/06/2011 12:12, Pierre Joye a écrit : It is not what Johannes said and we do fix bugs every single day. What Johannes said is that we can't force a volunteer to do something specific instead of what he wants to do. It is also totally off topic btw. It is really on topic since letting someone insert his wonderful clever feature in a project, whatever it is, and not maintain it is a project management problem. PHP makes me think of a ship with tens of stirring wheels. Of course no one can be forced to do what he doesn't want but a free project doesn't mean unmanaged project and a managed project means people with responsibilities. We are fixing bugs. We don't accept any new feature. Sometimes we might accept features in order to motivate contributors hoping they also fix bugs in the future. And even if the reproduce case is short: Some things in the engine are hard to fix, need thought and verification. Some things even can't be fixed within a bug fix release (x.y.z+1) as they require API changes or such. And then there are cases where severity is valuated differently. There are things we (whomever that includes) don't consider a use case as a proper/important use case and focus on other issues while it might be critical for few users ... We're welcoming people providing bug fixes. We'd love having zero bugs. But life isn't easy. We also welcome people who go through the bug reports and verify them, simplify test cases etc. This is also work to be done. We receive quite a few bug reports per day (well not right now as the system is down :-/ ) most of them aren't bugs but wrong expectations, many are probably bugs, few are actual easy to verify bugs. Going through them also costs quite some time. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
On 06/16/2011 11:40 AM, Pascal COURTOIS wrote: Le 16/06/2011 12:31, Rasmus a écrit : On 06/16/2011 11:03 AM, Pascal COURTOIS wrote: If you followed the thread you have seen the reduced test case is VERY short and the ONLY constructions involved are user functions and exceptions. FULL STOP. Not even a single addition nor a loop nor nothing. I can't imagine nobody uses user functions and exceptions. You might also consider that your particular case is rather unique. I since decoder-...@own-hero.net could reduce the case from my original program in the conditions I stated, he could obvously detect the leaks. I'm not saying there aren't any. There are known leaks in compile_file() when you throw an exception like that, so if you call a huge amount of these within a single request, you are going to have problems. But that is not something the average person hits, and again, they are all free'ed on request shutdown, so it isn't like it is a persistent leak. eg. rasmus@x220:~/php-src/branches/PHP_5_3$ USE_ZEND_ALLOC=0 valgrind --leak-check=full sapi/cli/php pas.php ==17658== Memcheck, a memory error detector ==17658== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al. ==17658== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info ==17658== Command: sapi/cli/php pas.php ==17658== ==17658== ==17658== HEAP SUMMARY: ==17658== in use at exit: 3,376 bytes in 18 blocks ==17658== total heap usage: 25,077 allocs, 25,059 frees, 3,952,839 bytes allocated ==17658== ==17658== 9 bytes in 1 blocks are possibly lost in loss record 3 of 16 ==17658==at 0x4C28FAC: malloc (vg_replace_malloc.c:236) ==17658==by 0x78F2DF: _estrndup (zend_alloc.c:2503) ==17658==by 0x78477B: lex_scan (zend_language_scanner.l:1817) ==17658==by 0x7994DF: zendlex (zend_compile.c:4969) ==17658==by 0x77B9B4: zendparse (zend_language_parser.c:3291) ==17658==by 0x77F3BE: compile_file (zend_language_scanner.l:364) ==17658==by 0x601350: phar_compile_file (phar.c:3393) ==17658==by 0x7ACF48: zend_execute_scripts (zend.c:1187) ==17658==by 0x75AA52: php_execute_script (main.c:2284) ==17658==by 0x8406D3: main (php_cli.c:1193) ==17658== ==17658== 14 bytes in 1 blocks are possibly lost in loss record 4 of 16 ==17658==at 0x4C28FAC: malloc (vg_replace_malloc.c:236) ==17658==by 0x7A8D9A: zend_str_tolower_dup (zend_operators.c:1884) ==17658==by 0x79B36E: zend_do_begin_function_call (zend_compile.c:1571) ==17658==by 0x77E64B: zendparse (zend_language_parser.y:671) ==17658==by 0x77F3BE: compile_file (zend_language_scanner.l:364) ==17658==by 0x601350: phar_compile_file (phar.c:3393) ==17658==by 0x7ACF48: zend_execute_scripts (zend.c:1187) ==17658==by 0x75AA52: php_execute_script (main.c:2284) ==17658==by 0x8406D3: main (php_cli.c:1193) ==17658== ==17658== 17 bytes in 1 blocks are possibly lost in loss record 5 of 16 ==17658==at 0x4C28FAC: malloc (vg_replace_malloc.c:236) ==17658==by 0x78F2DF: _estrndup (zend_alloc.c:2503) ==17658==by 0x78059A: lex_scan (zend_language_scanner.l:1695) ==17658==by 0x7994DF: zendlex (zend_compile.c:4969) ==17658==by 0x77B9B4: zendparse (zend_language_parser.c:3291) ==17658==by 0x77F3BE: compile_file (zend_language_scanner.l:364) ==17658==by 0x601350: phar_compile_file (phar.c:3393) ==17658==by 0x7ACF48: zend_execute_scripts (zend.c:1187) ==17658==by 0x75AA52: php_execute_script (main.c:2284) ==17658==by 0x8406D3: main (php_cli.c:1193) ==17658== ==17658== 648 (232 direct, 416 indirect) bytes in 1 blocks are definitely lost in loss record 15 of 16 ==17658==at 0x4C28FAC: malloc (vg_replace_malloc.c:236) ==17658==by 0x77F344: compile_file (zend_language_scanner.l:334) ==17658==by 0x601350: phar_compile_file (phar.c:3393) ==17658==by 0x7ACF48: zend_execute_scripts (zend.c:1187) ==17658==by 0x75AA52: php_execute_script (main.c:2284) ==17658==by 0x8406D3: main (php_cli.c:1193) ==17658== ==17658== 1,680 bytes in 1 blocks are possibly lost in loss record 16 of 16 ==17658==at 0x4C290A4: realloc (vg_replace_malloc.c:525) ==17658==by 0x7A2273: pass_two (zend_opcode.c:380) ==17658==by 0x77F407: compile_file (zend_language_scanner.l:376) ==17658==by 0x601350: phar_compile_file (phar.c:3393) ==17658==by 0x7ACF48: zend_execute_scripts (zend.c:1187) ==17658==by 0x75AA52: php_execute_script (main.c:2284) ==17658==by 0x8406D3: main (php_cli.c:1193) ==17658== ==17658== LEAK SUMMARY: ==17658==definitely lost: 232 bytes in 1 blocks ==17658==indirectly lost: 416 bytes in 6 blocks ==17658== possibly lost: 1,720 bytes in 4 blocks ==17658==still reachable: 1,008 bytes in 7 blocks ==17658== suppressed: 0 bytes in 0 blocks ==17658== Reachable blocks (those to which a pointer was found) are not shown. ==17658== To see them, rerun with: --leak-check=full --show-reachable=yes ==17658== ==17658== For counts of detected and suppressed
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
On 06/16/2011 12:42 PM, Rasmus wrote: On 06/16/2011 11:40 AM, Pascal COURTOIS wrote: Le 16/06/2011 12:31, Rasmus a écrit : On 06/16/2011 11:03 AM, Pascal COURTOIS wrote: If you followed the thread you have seen the reduced test case is VERY short and the ONLY constructions involved are user functions and exceptions. FULL STOP. Not even a single addition nor a loop nor nothing. I can't imagine nobody uses user functions and exceptions. You might also consider that your particular case is rather unique. I since decoder-...@own-hero.net could reduce the case from my original program in the conditions I stated, he could obvously detect the leaks. I'm not saying there aren't any. There are known leaks in compile_file() when you throw an exception like that, so if you call a huge amount of these within a single request, you are going to have problems. But that is not something the average person hits, and again, they are all free'ed on request shutdown, so it isn't like it is a persistent leak. I was bit unclear there. The cause of the leaks is the exit() in your exception, not the exception itself. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
Le 16/06/2011 13:42, Rasmus a écrit : On 06/16/2011 11:40 AM, Pascal COURTOIS wrote: Le 16/06/2011 12:31, Rasmus a écrit : On 06/16/2011 11:03 AM, Pascal COURTOIS wrote: If you followed the thread you have seen the reduced test case is VERY short and the ONLY constructions involved are user functions and exceptions. FULL STOP. Not even a single addition nor a loop nor nothing. I can't imagine nobody uses user functions and exceptions. You might also consider that your particular case is rather unique. I since decoder-...@own-hero.net could reduce the case from my original program in the conditions I stated, he could obvously detect the leaks. I'm not saying there aren't any. There are known leaks in compile_file() when you throw an exception like that, so if you call a huge amount of these within a single request, which is not the case. At most I will have 3 or 4 exceptions per request. you are going to have problems. But that is not something the average person hits, and again, they are all free'ed on request shutdown, so it isn't like it is a persistent leak. Ok, as said before I will summerize the facts on tuesday. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Give the Language a Rest motion (fwd)
-Original Message- From: Pascal COURTOIS [mailto:pascal.court...@nouvo.com] Sent: Thursday, June 16, 2011 12:28 AM To: Lester Caine Cc: PHP internals Subject: Re: [PHP-DEV] Give the Language a Rest motion (fwd) Le 16/06/2011 09:19, Lester Caine a écrit : when you have a bug in PHP it should not ever ever crash PHP and unfortunately I encountered that case dozens of times. At least on Linux is just recovers and carries on If PHP crashes, yes, it recovers but it's VERY resource and time consumming. If PHP corrupts some memory, it does not crash fastcgi processes but the next request(s) behave erratically. I have some news for you. Ruby has crashes, Python has crashes, even Java has security issues and crashes (check out the Java bug database. It's bigger than ours). Of course our goal is to reduce this as much as possible for PHP and as was stated here, short concise reproducible scripts do get attention. Re: memory models, PHP actually has a memory model that is very robust and prevents leaks from happening. Every memory model has its pros and cons but leak-free Java is a great example of where the memory model more often than not bites you in your tush more than you'd think (and I can say that after having done quite a bit of Websphere development - yuck). So just help us with identifying root cause and you will see the internals@ group very much jumping on the issues and try to resolve them. Andi
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
Hi! I'm not saying there aren't any. There are known leaks in compile_file() when you throw an exception like that, so if you call a huge amount of these within a single request, you are going to have problems. But that You actually can't call huge amount of these in one request, as this particular leak is caused by bailing out from zend_execute_scripts, which causes main op array not be freed. zend_execute_scripts() is called only once, so you can't have this leak multiple times as far as I can see. Whatever caused the original problem, it's highly unlikely it is this leak. -- 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] Give the Language a Rest motion (fwd)
Le 16/06/2011 18:11, Andi Gutmans a écrit : I have some news for you. Ruby has crashes, Python has crashes, Probably. any references about that ? even Java has security issues and crashes (check out the Java bug database. It's bigger than ours). IMHO java is a big s**t but that's really out of topic -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
On 06/16/2011 05:32 PM, Stas Malyshev wrote: Hi! I'm not saying there aren't any. There are known leaks in compile_file() when you throw an exception like that, so if you call a huge amount of these within a single request, you are going to have problems. But that You actually can't call huge amount of these in one request, as this particular leak is caused by bailing out from zend_execute_scripts, which causes main op array not be freed. zend_execute_scripts() is called only once, so you can't have this leak multiple times as far as I can see. Whatever caused the original problem, it's highly unlikely it is this leak. I was thinking it was a bunch of nested eval()'s that might cause this. An exit from within an eval'ed op_array would cause this same leak I think. But yes, I agree, in order to leak 128M or whatever it was he said, it is unlikely that it is due to this. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: 5.4 alpha, was: [PHP-DEV] Give the Language a Rest motion (fwd)
Hi! Stas, on a different note, weren't we going to roll a 5.4 alpha? I was going to write about it soon, but since you asked: I was waiting for RFC/voting discussion and vote in hope that we could get it all ready before the alpha, but it looks like it is taking longer than expected. So I think maybe we can have the alpha before that - and the RFC says we should have alpha in June anyway, and June is already half-gone :) The original plan was this week, so maybe this Thursday? -- 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] Re: 5.4 alpha, was: [PHP-DEV] Give the Language a Rest motion (fwd)
+1, for Thursday :-) -邮件原件- 发件人: Stas Malyshev [mailto:smalys...@sugarcrm.com] 发送时间: 2011年6月15日 15:24 收件人: Andi Gutmans 抄送: PHP Developers Mailing List 主题: [PHP-DEV] Re: 5.4 alpha, was: [PHP-DEV] Give the Language a Rest motion (fwd) Hi! Stas, on a different note, weren't we going to roll a 5.4 alpha? I was going to write about it soon, but since you asked: I was waiting for RFC/voting discussion and vote in hope that we could get it all ready before the alpha, but it looks like it is taking longer than expected. So I think maybe we can have the alpha before that - and the RFC says we should have alpha in June anyway, and June is already half-gone :) The original plan was this week, so maybe this Thursday? -- 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 Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
On Wed, Jun 15, 2011 at 7:02 AM, Andi Gutmans a...@zend.com wrote: Hence my suggestion to bundle MongoDB extension and possibly work on additional extensions. Some of my suggestions probably rightfully didn't get much interest such as Thrift. See my comment in your other thread and below. Maybe we should consider making a list of extensions we think could be beneficial and the new mentorship program can actually help deliver some of them? I do not thnk it is a good thing to begin a discussion about this exact topic and then totally ignore it. I also think that it is somehow wrong to post something asking to do not propose new things when we finally have more people involved in proposals and discussions. Maybe that's just me me but I do think that the main problem we have (besides the ones we identified and try to fix right now) is the complete lack of open discussions about possible new features, in this list with new or existing contributors. -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: 5.4 alpha, was: [PHP-DEV] Give the Language a Rest motion (fwd)
On 2011-06-15, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! Stas, on a different note, weren't we going to roll a 5.4 alpha? I was going to write about it soon, but since you asked: I was waiting for RFC/voting discussion and vote in hope that we could get it all ready before the alpha, but it looks like it is taking longer than expected. So I think maybe we can have the alpha before that - and the RFC says we should have alpha in June anyway, and June is already half-gone :) The original plan was this week, so maybe this Thursday? Zeev edited it today. So I hope it's ready for voting within the next days, so we can move forward. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Give the Language a Rest motion (fwd)
-Original Message- From: Pierre Joye [mailto:pierre@gmail.com] Sent: Wednesday, June 15, 2011 2:33 AM To: Andi Gutmans Cc: Derick Rethans; PHP Developers Mailing List Subject: Re: [PHP-DEV] Give the Language a Rest motion (fwd) On Wed, Jun 15, 2011 at 7:02 AM, Andi Gutmans a...@zend.com wrote: Hence my suggestion to bundle MongoDB extension and possibly work on additional extensions. Some of my suggestions probably rightfully didn't get much interest such as Thrift. See my comment in your other thread and below. Maybe we should consider making a list of extensions we think could be beneficial and the new mentorship program can actually help deliver some of them? I do not thnk it is a good thing to begin a discussion about this exact topic and then totally ignore it. I think it got lost in the very long and varying discussions. Will dig up and take a look. I had a couple of hectic weeks. I also think that it is somehow wrong to post something asking to do not propose new things when we finally have more people involved in proposals and discussions. Maybe that's just me me but I do think that the main problem we have (besides the ones we identified and try to fix right now) is the complete lack of open discussions about possible new features, in this list with new or existing contributors. I did not say we should not propose or have discussions (I am in favor of adding [] for arrays for example). But I am saying the bias should be not to include new language functionality unless it has very broad appeal serious upside impact. The bias should be against feature creep. Andi -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
Hi, I think that —in any context— the if it aint broke don't fix it is a very depressing attitude to have, and a very wrong one in any open source community. If the signal to noise ratio is the problem, I think its better to focus on that problem, not shutting down the signal. If PHP is a resource crunched project, I think its better to focus on that problem, not rejecting feature requests. (I might appear as impertinent with what I'm going to say, but bear with me, I'm being well-intentioned and mean no offense; just want to be honest). Regarding the signal to noise ratio, I have one question: how did traits get accepted?, having seen the kind of conversations in the lists it makes almost no sense to me how something so radical and complex could make its way to PHP so quickly and a simple and convenient thing like a short array syntax cannot, and something so basic as annotations raises so much pointless (just not to say ignorant) debate. Was it the to-the-point RFC and solid patch?, was it that the conversations were just on another level so not anyone could just say —or troll— traits are no solution! *spit*, lets do aspects instead!. I know it took some time, but while lurking the lists IIRC I never saw any opposition to traits... could anyone tell me what was the magic behind this?, could it be repeated?. Regarding resources, I think this is one of the main things rendering the community unhealthy (at least it feels like that to me) and I even feel bitterness in the air. I think that the definite solution to this is a DVCS like git and hosting the code at github, or like mercurial and hosting the code at bitbucket, please don't be angered at this suggestion (as I know the switch to SVN is a fairly recent one), you can ask around SVN geeks that went the distributed way and they will tell you things, wonderful things of how they don't know how could they could endure that much with that in their project, and if its an open source one, how much the switch has done in favor of contributions. Regardless of everything, I like that the PHP community has so much passion and energy, sometimes in a not constructive way, but that is a good problem to have in my opinion, really, don't take it for granted, it just needs a little direction. Best regards, David Vega On Wed, Jun 15, 2011 at 8:46 PM, Andi Gutmans a...@zend.com wrote: -Original Message- From: Pierre Joye [mailto:pierre@gmail.com] Sent: Wednesday, June 15, 2011 2:33 AM To: Andi Gutmans Cc: Derick Rethans; PHP Developers Mailing List Subject: Re: [PHP-DEV] Give the Language a Rest motion (fwd) On Wed, Jun 15, 2011 at 7:02 AM, Andi Gutmans a...@zend.com wrote: Hence my suggestion to bundle MongoDB extension and possibly work on additional extensions. Some of my suggestions probably rightfully didn't get much interest such as Thrift. See my comment in your other thread and below. Maybe we should consider making a list of extensions we think could be beneficial and the new mentorship program can actually help deliver some of them? I do not thnk it is a good thing to begin a discussion about this exact topic and then totally ignore it. I think it got lost in the very long and varying discussions. Will dig up and take a look. I had a couple of hectic weeks. I also think that it is somehow wrong to post something asking to do not propose new things when we finally have more people involved in proposals and discussions. Maybe that's just me me but I do think that the main problem we have (besides the ones we identified and try to fix right now) is the complete lack of open discussions about possible new features, in this list with new or existing contributors. I did not say we should not propose or have discussions (I am in favor of adding [] for arrays for example). But I am saying the bias should be not to include new language functionality unless it has very broad appeal serious upside impact. The bias should be against feature creep. Andi -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Give the Language a Rest motion (fwd)
What I am saying is if we accepted even 50% of what people felt very passionate about because their favorite language of the day has it then PHP would become overly complex, bloated and very challenging for users to pick up. C++ for example was a good language but is a good example of trying to do too much and getting overly complex over time (at least in my opinion). I do think we should have new feature discussions and need to ensure PHP evolves with the market and its users but have to ensure that we still keep it simple, easy to adopt and maintainable. Also, I think we do not need 100 ways of doing the same thing. Choice is good but too much choice is not. As I said in my previous email, while I think there are areas we can and should innovate in and evolve the core language I believe a lot of the innovation also has to happen at the framework and extension-level. I do not think there's a resource issue at the language level. When a new feature does get slated to be included we always have plenty of resources deployed on it to harden it and make sure it gets into the core vm in the right way (it is almost never the same as the original patch). I do think having more people work on extensions for some of the up and coming technologies would be super valuable. Seems like everyone wants to try and get their favorite language feature in but less are stepping up to work on extensions. What can you contribute? Andi From: dukeofgaming [mailto:dukeofgam...@gmail.com] Sent: Wednesday, June 15, 2011 7:36 PM To: Andi Gutmans Cc: Pierre Joye; Derick Rethans; PHP Developers Mailing List Subject: Re: [PHP-DEV] Give the Language a Rest motion (fwd) Hi, I think that -in any context- the if it aint broke don't fix it is a very depressing attitude to have, and a very wrong one in any open source community. If the signal to noise ratio is the problem, I think its better to focus on that problem, not shutting down the signal. If PHP is a resource crunched project, I think its better to focus on that problem, not rejecting feature requests. (I might appear as impertinent with what I'm going to say, but bear with me, I'm being well-intentioned and mean no offense; just want to be honest). Regarding the signal to noise ratio, I have one question: how did traits get accepted?, having seen the kind of conversations in the lists it makes almost no sense to me how something so radical and complex could make its way to PHP so quickly and a simple and convenient thing like a short array syntax cannot, and something so basic as annotations raises so much pointless (just not to say ignorant) debate. Was it the to-the-point RFC and solid patch?, was it that the conversations were just on another level so not anyone could just say -or troll- traits are no solution! *spit*, lets do aspects instead!. I know it took some time, but while lurking the lists IIRC I never saw any opposition to traits... could anyone tell me what was the magic behind this?, could it be repeated?. Regarding resources, I think this is one of the main things rendering the community unhealthy (at least it feels like that to me) and I even feel bitterness in the air. I think that the definite solution to this is a DVCS like git and hosting the code at github, or like mercurial and hosting the code at bitbucket, please don't be angered at this suggestion (as I know the switch to SVN is a fairly recent one), you can ask around SVN geeks that went the distributed way and they will tell you things, wonderful things of how they don't know how could they could endure that much with that in their project, and if its an open source one, how much the switch has done in favor of contributions. Regardless of everything, I like that the PHP community has so much passion and energy, sometimes in a not constructive way, but that is a good problem to have in my opinion, really, don't take it for granted, it just needs a little direction. Best regards, David Vega On Wed, Jun 15, 2011 at 8:46 PM, Andi Gutmans a...@zend.com wrote: -Original Message- From: Pierre Joye [mailto:pierre@gmail.com] Sent: Wednesday, June 15, 2011 2:33 AM To: Andi Gutmans Cc: Derick Rethans; PHP Developers Mailing List Subject: Re: [PHP-DEV] Give the Language a Rest motion (fwd) On Wed, Jun 15, 2011 at 7:02 AM, Andi Gutmans a...@zend.com wrote: Hence my suggestion to bundle MongoDB extension and possibly work on additional extensions. Some of my suggestions probably rightfully didn't get much interest such as Thrift. See my comment in your other thread and below. Maybe we should consider making a list of extensions we think could be beneficial and the new mentorship program can actually help deliver some of them? I do not thnk it is a good thing to begin a discussion about this exact topic and then totally ignore it. I think it got lost in the very long and varying discussions. Will dig up and take a look. I had a couple
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
Le 16/06/2011 04:36, dukeofgaming a écrit : Hi, I think that —in any context— the if it aint broke don't fix it is a very depressing attitude to have, and a very wrong one in any open source community. What I feel depressing is the urge of the PHP core team to fix working features instead of focusing on the 1800 open bug tickets. On every PHP project I work on I had to find workarounds because PHP crashes. Behaviour bugs (feature not working as intented) are annoying but memory leaks and memory corruptions are just a no no no in production environnement. The only way to call PHP when its memory leaks and get corrupted is to call it via CGI which is much too slow for a production server. What I need is a very stable language on which I can rely and I'm very sad to to say PHP is getting worse and worse on that point of view versions after versions. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
Hi! On every PHP project I work on I had to find workarounds because PHP crashes. Behaviour bugs (feature not working as intended) are annoying but memory leaks and memory corruptions are just a no no no in production environment. The only way A key to fixing memory corruption is providing good bug reports - with backtraces, valgrind reports, etc. If you have such reports and nothing happens to them - you may want to try to raise the profile of bug reports that are bothering you by mentioning them on the list and calling for volonteers to fix them. Usually if bug is in frequently used module and reproduceable, there would be somebody who can fix it. What I need is a very stable language on which I can rely and I'm very sad to to say PHP is getting worse and worse on that point of view versions after versions. I can not contradict your experience, it is what it is, but my experience for years working with PHP was exactly the opposite. -- 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] Give the Language a Rest motion (fwd)
Le 16/06/2011 07:23, Stas Malyshev a écrit : Hi! On every PHP project I work on I had to find workarounds because PHP crashes. Behaviour bugs (feature not working as intended) are annoying but memory leaks and memory corruptions are just a no no no in production environment. The only way A key to fixing memory corruption is providing good bug reports - with backtraces, valgrind reports, etc. If you have such reports and nothing happens to them - you may want to try to raise the profile of bug reports that are bothering you by mentioning them on the list and calling for volonteers to fix them. Usually if bug is in frequently used module and reproduceable, there would be somebody who can fix it. what I did every single time. Among all my bug reports I had one answer from decoder-...@own-hero.net (thanks to him) who reduced the test case for a memory leak (bug 54460). I'm not talking about bugs in modules but bugs in *core* which can be reproduced with few lines of *core* PHP. What I need is a very stable language on which I can rely and I'm very sad to to say PHP is getting worse and worse on that point of view versions after versions. I can not contradict your experience, it is what it is, but my experience for years working with PHP was exactly the opposite. To tell you the truth, I've been asked to rewrite the framework I did in Ruby because of these problems. I'm of course very reluctant to go that way but in the end I may have no choice :-( -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Give the Language a Rest motion (fwd)
Hi Derick and all, I think we have had some reasonable additions to the language in PHP 5.3 + will have a couple of good ones in PHP 5.4. That said, I do agree we should have a strong bias against language feature creep unless there is a really strong compelling reason. I do think that an increase of focus on enriching the eco-system around the core language esp. PHP extensions will be a lot more valuable. This is especially so if we can target many of the up and coming technologies and get such extensions production ready to bundle in Core PHP (hence my previous email re: adding some modern extensions). We've benefited in the past from a lot of enhancements and innovation around extensions incl. SimpleXML, variety of database, json, datetime, etc... Having another wave of really strong core extensions would be very beneficial and consistent with our past bias to deliver everything Web developers need out-of-the-box. Hence my suggestion to bundle MongoDB extension and possibly work on additional extensions. Some of my suggestions probably rightfully didn't get much interest such as Thrift. Maybe we should consider making a list of extensions we think could be beneficial and the new mentorship program can actually help deliver some of them? Stas, on a different note, weren't we going to roll a 5.4 alpha? Andi -Original Message- From: Derick Rethans [mailto:der...@php.net] Sent: Tuesday, June 07, 2011 4:05 AM To: PHP Developers Mailing List Subject: [PHP-DEV] Give the Language a Rest motion (fwd) Hi, Short-array syntax, Native JSON, Currying. I can almost only say one thing: WHY?! And because of that, I'd like to forward a mail by Zeev from a few years ago. I think it applies now even more than then: -- Forwarded message -- Date: Thu, 09 Mar 2006 12:57:32 +0200 From: Zeev Suraski z...@zend.com To: internals@lists.php.net Subject: [PHP-DEV] Give the Language a Rest motion I'd like to raise a motion to 'Give the Language a Rest'. Almost a decade since we started with the 2nd iteration on the syntax (PHP 3), and 2 more major versions since then, and we're still heatedly debating on adding new syntactical, core level features. Is it really necessary? I'd say in almost all cases the answer's no, and a bunch of cases where a new feature could be useful does not constitute a good enough reason to add a syntax level feature. We might have to account for new technologies, or maybe new ways of thinking that might arise, but needless to say, most of the stuff we've been dealing with in recent times doesn't exactly fall in the category of cutting edge technology. My motion is to make it much, much more difficult to add new syntax-level features into PHP. Consider only features which have significant traction to a large chunk of our userbase, and not something that could be useful in some extremely specialized edge cases, usually of PHP being used for non web stuff. How do we do it? Unfortunately, I can't come up with a real mechanism to 'enforce' a due process and reasoning for new features. Instead, please take at least an hour to bounce this idea in the back of your mind, preferably more. Make sure you think about the full context, the huge audience out there, the consequences of making the learning curve steeper with every new feature, and the scope of the goodness that those new features bring. Consider how far we all come and how successful the PHP language is today, in implementing all sorts of applications most of us would have never even thought of when we created the language. Once you're done thinking, decide for yourself. Does it make sense to be discussing new language level features every other week? Or should we, perhaps, invest more in other fronts, which would be beneficial for a far bigger audience. The levels above - extensions to keep with the latest technologies, foundation classes, etc. Pretty much, the same direction other mature languages went to. To be clear, and to give this motion higher chances of success, I'm not talking about jump. PHP can live with jump, almost as well as it could live without it :) I'm talking about the general sentiment. Zeev -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug -- 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-DEV] Give the Language a Rest motion (fwd)
Hi, Short-array syntax, Native JSON, Currying. I can almost only say one thing: WHY?! And because of that, I'd like to forward a mail by Zeev from a few years ago. I think it applies now even more than then: -- Forwarded message -- Date: Thu, 09 Mar 2006 12:57:32 +0200 From: Zeev Suraski z...@zend.com To: internals@lists.php.net Subject: [PHP-DEV] Give the Language a Rest motion I'd like to raise a motion to 'Give the Language a Rest'. Almost a decade since we started with the 2nd iteration on the syntax (PHP 3), and 2 more major versions since then, and we're still heatedly debating on adding new syntactical, core level features. Is it really necessary? I'd say in almost all cases the answer's no, and a bunch of cases where a new feature could be useful does not constitute a good enough reason to add a syntax level feature. We might have to account for new technologies, or maybe new ways of thinking that might arise, but needless to say, most of the stuff we've been dealing with in recent times doesn't exactly fall in the category of cutting edge technology. My motion is to make it much, much more difficult to add new syntax-level features into PHP. Consider only features which have significant traction to a large chunk of our userbase, and not something that could be useful in some extremely specialized edge cases, usually of PHP being used for non web stuff. How do we do it? Unfortunately, I can't come up with a real mechanism to 'enforce' a due process and reasoning for new features. Instead, please take at least an hour to bounce this idea in the back of your mind, preferably more. Make sure you think about the full context, the huge audience out there, the consequences of making the learning curve steeper with every new feature, and the scope of the goodness that those new features bring. Consider how far we all come and how successful the PHP language is today, in implementing all sorts of applications most of us would have never even thought of when we created the language. Once you're done thinking, decide for yourself. Does it make sense to be discussing new language level features every other week? Or should we, perhaps, invest more in other fronts, which would be beneficial for a far bigger audience. The levels above - extensions to keep with the latest technologies, foundation classes, etc. Pretty much, the same direction other mature languages went to. To be clear, and to give this motion higher chances of success, I'm not talking about jump. PHP can live with jump, almost as well as it could live without it :) I'm talking about the general sentiment. Zeev -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
On Tue, Jun 7, 2011 at 1:04 PM, Derick Rethans der...@php.net wrote: Hi, Short-array syntax, Native JSON, Currying. I can almost only say one thing: WHY?! And because of that, I'd like to forward a mail by Zeev from a few years ago. I think it applies now even more than then: I'd to disagree. I love activities on the list, even for features I would never want to see implemented in php. It is how it works, it is how it should work, Getting constant new requests, discussing new possible features, moving forward. Even if it does not mean it has to be uncontrollable and that we should implement every 2nd request. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
On Tue, Jun 7, 2011 at 1:04 PM, Derick Rethans der...@php.net wrote: Hi, Short-array syntax, Native JSON, Currying. I can almost only say one thing: WHY?! And because of that, I'd like to forward a mail by Zeev from a few years ago. I think it applies now even more than then: snip I think that it is better to have healthy discussion about the language, than to stop accepting feature request at all. of course we have to carefully select which RFCs are good enough and worthy for inclusion, and properly introduce them into the language and for the users. I really like the current buzz, but maybe there are some people like you, who are more in favor for the previous flow of conversations(fewer participants, fewer discussions). Tyrael
