Re: [PHP-DEV] Pull request for array_filter() improvement
2013/2/21 Tjerk Anne Meesters datib...@php.net
Hi,
I found myself wanting a feature of array_filter() with which I can perform
filtering based on the array key instead of the value.
To scratch this itch, I decided to dive into C again and just add the
feature. My proposal is to add a third argument to array_filter() that will
send the array keys to the callback.
Hi,
Why not simply _always_ push the key to the callback?
Regards,
Sebastian
function myfilter($value, $key)
{
return $key 4;
}
array_filter([1, 2, 3, 4, 5, 6, 7], 'myfilter', true);
// returns: [6, 7]
The pull request can be found here:
https://github.com/php/php-src/pull/287
If this is useful for the language as a whole, do let me know what else I
should do to champion it.
Thanks!
--
--
Tjerk
--
github.com/KingCrunch
Re: [PHP-DEV] Pull request for array_filter() improvement
Hi Sebastian,
I would be fine with that too, but this might break existing code that uses
internal functions which behave differently when a second argument is
passed.
One might also make the argument that creating an additional ZVAL that's
never used in a callback is a waste of cpu.
I'm not sure about either of those counter arguments, but I added them for
anyone else to pick up :)
On Thu, Feb 21, 2013 at 4:02 PM, Sebastian Krebs krebs@gmail.comwrote:
2013/2/21 Tjerk Anne Meesters datib...@php.net
Hi,
I found myself wanting a feature of array_filter() with which I can
perform
filtering based on the array key instead of the value.
To scratch this itch, I decided to dive into C again and just add the
feature. My proposal is to add a third argument to array_filter() that
will
send the array keys to the callback.
Hi,
Why not simply _always_ push the key to the callback?
Regards,
Sebastian
function myfilter($value, $key)
{
return $key 4;
}
array_filter([1, 2, 3, 4, 5, 6, 7], 'myfilter', true);
// returns: [6, 7]
The pull request can be found here:
https://github.com/php/php-src/pull/287
If this is useful for the language as a whole, do let me know what else I
should do to champion it.
Thanks!
--
--
Tjerk
--
github.com/KingCrunch
--
--
Tjerk
Re: [PHP-DEV] [RFC] send/recvmsg() wrappers in ext/socket
Em 2013-02-21 4:06, Ferenc Kovacs escreveu: On Tue, Jan 22, 2013 at 6:23 PM, Gustavo Lopes glo...@nebm.ist.utl.ptwrote: https://wiki.php.net/rfc/**sendrecvmsghttps://wiki.php.net/rfc/sendrecvmsg The module ext/sockets, a wrapper around the sockets API, does not include support to recvmsg() and sendmsg(). This RFC addresses this shortcoming by support introducing limited (only a few types of messages are supported) support for these functions. Could you update the status of the RFC and list it on https://wiki.php.net/rfc/ ? Done. P.S.: Trim the quoted text -- at the every least, take the signature off. -- Gustavo Lopes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Pull request for array_filter() improvement
On 21 February 2013 07:08, Tjerk Anne Meesters datib...@php.net wrote: Hi, I found myself wanting a feature of array_filter() with which I can perform filtering based on the array key instead of the value. With the operative word here being *instead*, keeping in line with the numerous other array functions, would a new function called array_filter_key() with the same signature as array_filter() be more or less appropriate? The callback still being a single parameter function that receives the key *instead* of the value. Is there a big use case for having the key and value both passed to the callback at the same time? (I can't think of anything off the top of my head, but I'm sure someone would use it)
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] Pull request for array_filter() improvement
On Thu, Feb 21, 2013 at 5:31 PM, Leigh lei...@gmail.com wrote: On 21 February 2013 07:08, Tjerk Anne Meesters datib...@php.net wrote: Hi, I found myself wanting a feature of array_filter() with which I can perform filtering based on the array key instead of the value. With the operative word here being *instead*, keeping in line with the numerous other array functions, would a new function called array_filter_key() with the same signature as array_filter() be more or less appropriate? My use-case is as follows. Imagine you have this array: [ns.oauth = http://specs.openid.net/extensions/oauth/1.0;, ns.alias3 = http://openid.net/srv/ax/1.0;, oauth.consumer = xxx, ...] It's basically a bag of openid parameters. Now I'm tasked to find which alias belongs to http://specs.openid.net/extensions/oauth/1.0;. For this I need two pieces of information: 1. I need to match the value for the namespace 2. I need to make sure only keys that start with ns. are chosen Currently I use array_keys() to find the keys whose values match the namespace and then iterate over the results to find a key that matches the second requirement. The callback still being a single parameter function that receives the key *instead* of the value. Is there a big use case for having the key and value both passed to the callback at the same time? (I can't think of anything off the top of my head, but I'm sure someone would use it) -- -- Tjerk
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] PHP User Survey
On 02/21/2013 08:14 AM, Pierre Joye wrote: I do not have a single doubt. Why? Surveys are one of many ways to get feedback. They have no contracting values but give us some numbers about one rfc or another. That may help us to focus on one feature instead of another if we see a large number of users looking forward to it. You'll never get perfect results, but I prefer results at all over none :) There have been a lot of those for other languages: - http://cemerick.com/2012/08/06/results-of-the-2012-state-of-clojure-survey/ - http://survey.perlfoundation.org/ - http://survey.hamptoncatlin.com/ Looking forward to this, especially if we could get a few thousand people to vote. Greetings, Florian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Short syntax for anonymous functions
On 21/02/2013, at 6:12 AM, Lazare Inepologlou linep...@gmail.com wrote:
2013/2/20 Sanford Whiteman swhitemanlistens-softw...@cypressintegrated.com
It still looks like some random characters bashed together by a monkey
with a keyboard.
+1, I am a fiend for ternary expressions and crazy one-liners, but
this makes me want to go back and unroll everything I've ever done
into readable code. :)
-- S.
Long code is not always equivalent to readable code. A shorter syntax could
improve readability in *some* cases.
Long:
$users-OrderBy( function( $x ){ return $x-Surname; } );
Short:
$users-OrderBy( $x == $x-Surname );
Lazare INEPOLOGLOU
Ingénieur Logiciel
I think your example proves the opposite. The fist example was much easier to
read and understand than the second.
Cheers,
David
--
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
[PHP-DEV] Re: [PHP-CVS] com php-src: Fixed external entity loading: ext/libxml/libxml.c ext/libxml/php_libxml.h ext/soap/php_xml.c
It seems ZTS bulid is broken /builddir/build/BUILD/php5.5-201302211230/ext/soap/php_xml.c: In function 'soap_xmlParseFile': /builddir/build/BUILD/php5.5-201302211230/ext/soap/php_xml.c:103:3: error: too few arguments to function 'php_libxml_disable_entity_loader' In file included from /builddir/build/BUILD/php5.5-201302211230/ext/soap/php_xml.c:23:0: /builddir/build/BUILD/php5.5-201302211230/ext/libxml/php_libxml.h:101:51: note: declared here /builddir/build/BUILD/php5.5-201302211230/ext/soap/php_xml.c:105:3: error: too few arguments to function 'php_libxml_disable_entity_loader' In file included from /builddir/build/BUILD/php5.5-201302211230/ext/soap/php_xml.c:23:0: /builddir/build/BUILD/php5.5-201302211230/ext/libxml/php_libxml.h:101:51: note: declared here /builddir/build/BUILD/php5.5-201302211230/ext/soap/php_xml.c: In function 'soap_xmlParseMemory': /builddir/build/BUILD/php5.5-201302211230/ext/soap/php_xml.c:151:3: error: too few arguments to function 'php_libxml_disable_entity_loader' In file included from /builddir/build/BUILD/php5.5-201302211230/ext/soap/php_xml.c:23:0: /builddir/build/BUILD/php5.5-201302211230/ext/libxml/php_libxml.h:101:51: note: declared here /builddir/build/BUILD/php5.5-201302211230/ext/soap/php_xml.c:153:3: error: too few arguments to function 'php_libxml_disable_entity_loader' In file included from /builddir/build/BUILD/php5.5-201302211230/ext/soap/php_xml.c:23:0: /builddir/build/BUILD/php5.5-201302211230/ext/libxml/php_libxml.h:101:51: note: declared here Remi. Le 20/02/2013 19:14, Dmitry Stogov a écrit : Commit:8e76d0404b7f664ee6719fd98f0483f0ac4669d6 Author:Dmitry Stogov dmi...@zend.com Wed, 20 Feb 2013 22:14:59 +0400 Parents: afc1debb2f48938e98ec35dbc6545b331b1c3096 Branches: PHP-5.3 PHP-5.4 PHP-5.5 master Link: http://git.php.net/?p=php-src.git;a=commitdiff;h=8e76d0404b7f664ee6719fd98f0483f0ac4669d6 -- 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] Re: [PHP-CVS] com php-src: Fixed external entity loading: ext/libxml/libxml.c ext/libxml/php_libxml.h ext/soap/php_xml.c
On Thu, 2013-02-21 at 14:37 +0100, Remi Collet wrote: It seems ZTS bulid is broken Fixed in fcd4b53 (and merge commits) 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)
-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] [RFC] Short syntax for anonymous functions
On Thu, Feb 21, 2013 at 4:17 AM, David Muir davidkm...@gmail.com wrote:
On 21/02/2013, at 6:12 AM, Lazare Inepologlou linep...@gmail.com wrote:
2013/2/20 Sanford Whiteman swhitemanlistens-softw...@cypressintegrated.com
It still looks like some random characters bashed together by a monkey
with a keyboard.
+1, I am a fiend for ternary expressions and crazy one-liners, but
this makes me want to go back and unroll everything I've ever done
into readable code. :)
Long code is not always equivalent to readable code. A shorter syntax could
improve readability in *some* cases.
Long:
$users-OrderBy( function( $x ){ return $x-Surname; } );
Short:
$users-OrderBy( $x == $x-Surname );
I think your example proves the opposite. The fist example was much easier to
read and understand than the second.
Obviously that's up to interpretation; I think the second is better
though I don't understand why `==` is there instead of something
simpler.
--
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] [RFC] Short syntax for anonymous functions
2013/2/21 Levi Morrison morrison.l...@gmail.com
On Thu, Feb 21, 2013 at 4:17 AM, David Muir davidkm...@gmail.com wrote:
On 21/02/2013, at 6:12 AM, Lazare Inepologlou linep...@gmail.com
wrote:
2013/2/20 Sanford Whiteman
swhitemanlistens-softw...@cypressintegrated.com
It still looks like some random characters bashed together by a monkey
with a keyboard.
+1, I am a fiend for ternary expressions and crazy one-liners, but
this makes me want to go back and unroll everything I've ever done
into readable code. :)
Long code is not always equivalent to readable code. A shorter syntax
could
improve readability in *some* cases.
Long:
$users-OrderBy( function( $x ){ return $x-Surname; } );
Short:
$users-OrderBy( $x == $x-Surname );
I think your example proves the opposite. The fist example was much
easier to read and understand than the second.
Obviously that's up to interpretation; I think the second is better
though I don't understand why `==` is there instead of something
simpler.
It's just an example, and it's not important. I wanted to use something
that is similar to the key-value mapping operator, but not the same.
What is important is that the short version is declarative: emphasis is put
to what to do, not how to do it. The mechanics are not exposed, and this is
why some may find it harder to understand at first sight.
Lazare INEPOLOGLOU
Ingénieur Logiciel
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.
[PHP-DEV] Re: VCS Account Request: gabrielwu84
VCS Account Approved: gabrielwu84 approved by rasmus \o/ -- 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 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] PHP User Survey
On 02/21/2013 03:02 AM, Florian Anderiasch wrote: On 02/21/2013 08:14 AM, Pierre Joye wrote: I do not have a single doubt. Why? Surveys are one of many ways to get feedback. They have no contracting values but give us some numbers about one rfc or another. That may help us to focus on one feature instead of another if we see a large number of users looking forward to it. You'll never get perfect results, but I prefer results at all over none :) There have been a lot of those for other languages: - http://cemerick.com/2012/08/06/results-of-the-2012-state-of-clojure-survey/ - http://survey.perlfoundation.org/ - http://survey.hamptoncatlin.com/ For the mail archives, there are also these (more focused) reports: http://static.zend.com/topics/zend-developer-pulse-survey-report-Q2-2012-0612-EN.pdf http://downloads.zend.com/guides/whitepapers/State_of_PHP_in_the_Enterprise_061212.pdf Chris -- christopher.jo...@oracle.com http://twitter.com/ghrd Newly updated, free PHP Oracle book: http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.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)
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] PHP 6 : a new API ?
On Feb 20, 2013, at 11:19 , Sebastian Krebs krebs@gmail.com wrote: 2013/2/20 Klaus Ufo klaus...@yahoo.fr Hi there ! We all know that the current PHP API has flaws. Maybe we could use namespaces to build a new coherent PHP API ? Like : - \arr - \num - \str and so on. Advantages : - no more global functions Just to throw that in: Even if you pack them into namespaces they will still remain global functions. They simply don't live in the root-namespace anymore. +1 So why not avoiding this by adding it as methods of the scalar variable instead, aka autoboxing. This would allow the new api to be closer to what people are used to from other languages, needs far less typing and IDE autocomplete of available functions pr type with -. More recent example by Nikita Popov, see unit tests of the project for examples: https://github.com/nikic/scalar_objects/blob/master/tests/string.phpt#L17 - separation of concerns - backward compatibility - work can be done progressively - easy to add user-defined functions (using php namespaces) - we could provide a \str\utf8 namespace This is just an idea. I don't know what is your vision for a next PHP 6. KH -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- github.com/KingCrunch -- 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] APC 3.1.14 disappeared from PECL
Ferenc Kovacs in php.internals (Mon, 4 Feb 2013 09:47:11 +0100): It was done by Rasmus on purpose, as there were memory issues with this release what we couldn't track down/fix yet. Should not these be removed or replaced as well? http://windows.php.net/downloads/pecl/snaps/apc/3.1.14-dev/ And did you track down the memory issues yet? Jan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP causing high number of NFS getattr operations?
On Mon, Feb 18, 2013 at 3:35 PM, Rasmus Lerdorf ras...@lerdorf.com wrote: Wow, people are still serving web files over NFS? Sounds painful. On Mon, Feb 18, 2013 at 9:32 PM, Rasmus Lerdorf ras...@lerdorf.com wrote: So they are serving up all their PHP over NFS for some reason. I've been thinking about this and wanted to make a few final points. I think this is potentially a pretty major issue and not something to be dismissed. We've invested a great deal of money in a high performance shared storage system, so of course we want to use this system for absolutely everything we can within reason, including sharing 1500+ PHP files to our many web servers. I don't think most systems administrators would find this unreasonable. Why would we want to split our architecture up so just our PHP files are being synced from local disk and everything else is shared via NFS? Doing this seems far more unreasonable to me and just doesn't make any sense. NFS is so common for sharing files that saying Wow, people are still serving web files over NFS? is like saying Wow, people are still using the ls command to list directory contents on Linux? I think NFS is still very widely used, even for sharing web files. This being said, you stated in bug #59372 that PHP by default does open+fstat for performance reasons and while doing an open+fstat might result in better performance on local file systems, doing so is not optimal when using NFS. NFS close-to-open cache consistency is designed such that opening a file stored on an NFS server causes an automatic getattr or access request. This could also be true for other shared file systems as others have mentioned. All of these open+fstats are definitely causing a measurable impact to our systems. Right now, for example, 50% of the 6-8K+ ops/s being processed by our filer are getattr operations, and a majority of these getattr calls are coming from our Apache/PHP servers. Doing open+fstat bypasses the NFS attribute cache similar to disabling it altogether, where a simple stat would likely utilize the attribute cache. Disabling the attribute cache is generally not recommended due to the performance impact this has on the filer (and the application). I don't think the appropriate answer is don't use NFS because this is ridiculous as a long term solution (NFS is common, and people are going to use it or something similar). I think the appropriate answer is to update PHP to use stat vs. open+fstat or doing something similar that would be optimized for both local AND shared file systems (I would be writing a patch instead of this email if I could). Until then, I think it's important that people know that PHP is NOT optimized for use with NFS (and possilby other shared file systems) even when using an opcode cache like APC. I think this is a very important piece of information that people need to know. Up until this week, I wouldn't have thought twice about sharing PHP files over NFS, and I've been a Unix admin for over twelve years (only new to this environment). Brendon -- 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] PHP causing high number of NFS getattr operations?
On 02/21/2013 03:15 PM, Brendon Colby wrote: NFS is so common for sharing files that saying Wow, people are still serving web files over NFS? is like saying Wow, people are still using the ls command to list directory contents on Linux? I think NFS is still very widely used, even for sharing web files. This is simply not true. I do have a fair bit of experience in this field, and I don't know of any major sites that do this and I have worked with a good chunk of the largest sites out there. I don't think the appropriate answer is don't use NFS because this is ridiculous as a long term solution (NFS is common, and people are going to use it or something similar). I think the appropriate answer is to update PHP to use stat vs. open+fstat or doing something similar that would be optimized for both local AND shared file systems (I would be writing a patch instead of this email if I could). If it is of such importance to you and you are not able to do it yourself, then hire someone to do it. We may or may not get around to it, but like most things in PHP, we work on what we need ourselves and I don't think anybody here would even consider putting all their PHP files on an NFS share when performance was important. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP causing high number of NFS getattr operations?
Quoting Brendon Colby bren...@newgrounds.com: We've invested a great deal of money in a high performance shared storage system, so of course we want to use this system for absolutely everything we can within reason, including sharing 1500+ PHP files to our many web servers. I don't think most systems administrators would find this unreasonable. Great points Brendon! We have a similar architectural to your setup running NetApp filers, Apache/PHP web servers performing shared hosting for over 40,000+ websites. We pull over 35k IOPS and 80% are from PHP stats and getattr's. Someone earlier mentioned that people now use GlusterFS as an alternative. GlusterFS native client runs like absolute crap with Apache/PHP applications in order to get reasonable performance you must use the GlusterFS NFS implementation and mount the GlusterFS using NFS. You end up in the same performance issues using GlusterFS and PHP. More and more clustered PHP applications are using GlusterFS via NFS. Due to the getattr and stat issues in PHP it doesn't scale well in these sorts of deployments. In order to recover some of the performance on our NetApp's we have invested in 1TB of Flash Cache which caches the majority of getattr and stat requests on the filer however there is still a performance hit as the requests still go via the network and not cached on the local client. It would be great to see the PHP devs address this issue. Regards, Dan Zoltak -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP causing high number of NFS getattr operations?
Quoting dan...@zoltak.com: Great points Brendon! We have a similar architectural to your setup running NetApp filers, Apache/PHP web servers performing shared hosting for over 40,000+ websites. We pull over 35k IOPS and 80% are from PHP stats and getattr's. Someone earlier mentioned that people now use GlusterFS as an alternative. GlusterFS native client runs like absolute crap with Apache/PHP applications in order to get reasonable performance you must use the GlusterFS NFS implementation and mount the GlusterFS using NFS. You end up in the same performance issues using GlusterFS and PHP. More and more clustered PHP applications are using GlusterFS via NFS. Due to the getattr and stat issues in PHP it doesn't scale well in these sorts of deployments. I would also like to add that newer Cloud concentric application are developed so that they do not persistent data to local storage. This then negates the use of NFS i.e. we can deploy code via git to the nodes running on local storage. All dynamically generated user data is persisted to object storage and sessions are persisted using the memcache session handler. However in order to support legacy applications that are not Cloud centric then a network file system is the only viable option in shared hosting environments. Regards, Dan Zoltak -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP causing high number of NFS getattr operations?
On 21/02/13 23:38, Rasmus Lerdorf wrote: On 02/21/2013 03:15 PM, Brendon Colby wrote: NFS is so common for sharing files that saying Wow, people are still serving web files over NFS? is like saying Wow, people are still using the ls command to list directory contents on Linux? I think NFS is still very widely used, even for sharing web files. This is simply not true. I do have a fair bit of experience in this field, and I don't know of any major sites that do this and I have worked with a good chunk of the largest sites out there. Eh??? Fortune 500 enterprises and governmental departments are pretty conservative. NAS and SAN based iSCSI and FCoE based elastic block storage give great performance for server-specific file-systems, but Brendon is right: for distributed file systems, NFS and CIFS still dominate. I don't think the appropriate answer is don't use NFS because this is ridiculous as a long term solution (NFS is common, and people are going to use it or something similar). I think the appropriate answer is to update PHP to use stat vs. open+fstat or doing something similar that would be optimized for both local AND shared file systems (I would be writing a patch instead of this email if I could). If it is of such importance to you and you are not able to do it yourself, then hire someone to do it. We may or may not get around to it, but like most things in PHP, we work on what we need ourselves and I don't think anybody here would even consider putting all their PHP files on an NFS share when performance was important. Again wrong. Apps developers don't do this because that want to; they do it because the IT services group that runs the production infrastructure has mandated standard templates for live deployment to keep the through-life cost of providing the application infrastructure manageable, with all sorts of bureaucratic exception processes if you think that your app is a special case. If you are lucky then they offer a range of EC2-like standard VM templates so that you can deploy an EBS-based approach, but most are still in catch-up mode compared to Amazons offerings. If you are a GM or a American Airlines, or the NIH for example then you will have 1,000s of applications customer facing and internal and you've got to adopt this approach for 90+% of these applications. What Brendon is asking for is reasonable, sensible and in relative terms easy to implement. However, I agree that it may be more sensible to use community effort to achieve this.
Re: [PHP-DEV] PHP causing high number of NFS getattr operations?
On 02/21/2013 04:41 PM, Terry Ellison wrote: On 21/02/13 23:38, Rasmus Lerdorf wrote: On 02/21/2013 03:15 PM, Brendon Colby wrote: NFS is so common for sharing files that saying Wow, people are still serving web files over NFS? is like saying Wow, people are still using the ls command to list directory contents on Linux? I think NFS is still very widely used, even for sharing web files. This is simply not true. I do have a fair bit of experience in this field, and I don't know of any major sites that do this and I have worked with a good chunk of the largest sites out there. Eh??? Fortune 500 enterprises and governmental departments are pretty conservative. NAS and SAN based iSCSI and FCoE based elastic block storage give great performance for server-specific file-systems, but Brendon is right: for distributed file systems, NFS and CIFS still dominate. By major I meant traffic-wise, not Fortune-500, although there are some of those on the list too. I mostly work with medium-to-large scale Internet companies. Think Yahoo, Facebook, Flickr, Digg, Etsy, WePay, Room77. These types of companies would never consider serving all their Web traffic from NFS. Yes, Yahoo had a ton of Netapp filers as well, but this was for shared data storage, they would never consider putting their application logic on them. This is also something that has been like this for 10+ years and nobody has stepped up to fix it so far. It shouldn't be news to anyone that stats and opens over NFS are slow. I am not sure why it should suddenly be an urgent problem for us at this point. But like I said, we may get to it. If the integrated opcode cache happens it becomes easier to manage the flow between the compiler, the cache and the executor and we can probably optimize some things there. And as I mentioned in another thread, let's see some RFCs proposing how to fix some of these things rather than simply posting I wish the PHP devs would do this.. type of messages. These go over really badly with most of the longtime contributors here and they even tend to have the opposite of the desired effect. -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)
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!
