# Give the Language a Rest motion (fwd) - Thread: https://externals.io/message/53127 - Original archive: https://news-web.php.net/php.internals/53127 - Started by Derick Rethans on 2011-06-07T11:04:43+00:00 - Messages: 54 - Page 1 of 3: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/53127.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #53127 — Derick Rethans — 2011-06-07T11:04:43+00:00 URL: https://externals.io/message/53127#53127 Hi, Short-array syntax, Native JSON, "Currying". I can almost only say one thing: WHY?! And because of that, I'd like to forward a mail by Zeev from a few years ago. I think it applies now even more than then: ---------- Forwarded message ---------- Date: Thu, 09 Mar 2006 12:57:32 +0200 From: Zeev Suraski To: internals@lists.php.net Subject: [PHP-DEV] Give the Language a Rest motion I'd like to raise a motion to 'Give the Language a Rest'. Almost a decade since we started with the 2nd iteration on the syntax (PHP 3), and 2 more major versions since then, and we're still heatedly debating on adding new syntactical, core level features. Is it really necessary? I'd say in almost all cases the answer's no, and a bunch of cases where a new feature could be useful does not constitute a good enough reason to add a syntax level feature. We might have to account for new technologies, or maybe new ways of thinking that might arise, but needless to say, most of the stuff we've been dealing with in recent times doesn't exactly fall in the category of cutting edge technology. My motion is to make it much, much more difficult to add new syntax-level features into PHP. Consider only features which have significant traction to a large chunk of our userbase, and not something that could be useful in some extremely specialized edge cases, usually of PHP being used for non web stuff. How do we do it? Unfortunately, I can't come up with a real mechanism to 'enforce' a due process and reasoning for new features. Instead, please take at least an hour to bounce this idea in the back of your mind, preferably more. Make sure you think about the full context, the huge audience out there, the consequences of making the learning curve steeper with every new feature, and the scope of the goodness that those new features bring. Consider how far we all come and how successful the PHP language is today, in implementing all sorts of applications most of us would have never even thought of when we created the language. Once you're done thinking, decide for yourself. Does it make sense to be discussing new language level features every other week? Or should we, perhaps, invest more in other fronts, which would be beneficial for a far bigger audience. The levels above - extensions to keep with the latest technologies, foundation classes, etc. Pretty much, the same direction other mature languages went to. To be clear, and to give this motion higher chances of success, I'm not talking about jump. PHP can live with jump, almost as well as it could live without it :) I'm talking about the general sentiment. Zeev -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug --- ## #53128 — Pierre Joye — 2011-06-07T11:12:48+00:00 URL: https://externals.io/message/53127#53128 · In reply to: #53127 > Hi, > > Short-array syntax, Native JSON, "Currying". I can > almost only say one thing: WHY?! > > And because of that, I'd like to forward a mail by Zeev from a few years > ago. I think it applies now even more than then: I'd to disagree. I love activities on the list, even for features I would never want to see implemented in php. It is how it works, it is how it should work, Getting constant new requests, discussing new possible features, moving forward. Even if it does not mean it has to be uncontrollable and that we should implement every 2nd request. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #53129 — Ferenc Kovacs — 2011-06-07T11:15:17+00:00 URL: https://externals.io/message/53127#53129 · In reply to: #53127 > Hi, > > Short-array syntax, Native JSON, "Currying". I can > almost only say one thing: WHY?! > > And because of that, I'd like to forward a mail by Zeev from a few years > ago. I think it applies now even more than then: > > snip I think that it is better to have healthy discussion about the language, than to stop accepting feature request at all. of course we have to carefully select which RFCs are good enough and worthy for inclusion, and properly introduce them into the language and for the users. I really like the current buzz, but maybe there are some people like you, who are more in favor for the previous flow of conversations(fewer participants, fewer discussions). Tyrael --- ## #53289 — Andi Gutmans — 2011-06-15T05:02:27+00:00 URL: https://externals.io/message/53127#53289 · In reply to: #53127 Hi Derick and all, I think we have had some reasonable additions to the language in PHP 5.3 + will have a couple of good ones in PHP 5.4. That said, I do agree we should have a strong bias against language feature creep unless there is a really strong compelling reason. I do think that an increase of focus on enriching the eco-system around the core language esp. PHP extensions will be a lot more valuable. This is especially so if we can target many of the up and coming technologies and get such extensions production ready to bundle in Core PHP (hence my previous email re: adding some modern extensions). We've benefited in the past from a lot of enhancements and innovation around extensions incl. SimpleXML, variety of database, json, datetime, etc... Having another wave of really strong core extensions would be very beneficial and consistent with our past bias to deliver everything Web developers need out-of-the-box. Hence my suggestion to bundle MongoDB extension and possibly work on additional extensions. Some of my suggestions probably rightfully didn't get much interest such as Thrift. Maybe we should consider making a list of extensions we think could be beneficial and the new mentorship program can actually help deliver some of them? Stas, on a different note, weren't we going to roll a 5.4 alpha? Andi >-----Original Message----- >From: Derick Rethans [mailto:derick@php.net] >Sent: Tuesday, June 07, 2011 4:05 AM >To: PHP Developers Mailing List >Subject: [PHP-DEV] Give the Language a Rest motion (fwd) > >Hi, > >Short-array syntax, Native JSON, "Currying". I can almost only say one thing: >WHY?! > >And because of that, I'd like to forward a mail by Zeev from a few years ago. I >think it applies now even more than then: > >---------- Forwarded message ---------- >Date: Thu, 09 Mar 2006 12:57:32 +0200 >From: Zeev Suraski >To: internals@lists.php.net >Subject: [PHP-DEV] Give the Language a Rest motion > >I'd like to raise a motion to 'Give the Language a Rest'. > >Almost a decade since we started with the 2nd iteration on the syntax (PHP 3), >and 2 more major versions since then, and we're still heatedly debating on >adding new syntactical, core level features. > >Is it really necessary? I'd say in almost all cases the answer's no, and a bunch of >cases where a new feature could be useful does not constitute a good enough >reason to add a syntax level feature. We might have to account for new >technologies, or maybe new ways of thinking that might arise, but needless to >say, most of the stuff we've been dealing with in recent times doesn't exactly >fall in the category of cutting edge technology. > >My motion is to make it much, much more difficult to add new syntax-level >features into PHP. Consider only features which have significant traction to a >large chunk of our userbase, and not something that could be useful in some >extremely specialized edge cases, usually of PHP being used for non web stuff. > >How do we do it? Unfortunately, I can't come up with a real mechanism to >'enforce' a due process and reasoning for new features. > >Instead, please take at least an hour to bounce this idea in the back of your >mind, preferably more. Make sure you think about the full context, the huge >audience out there, the consequences of making the learning curve steeper with >every new feature, and the scope of the goodness that those new features bring. >Consider how far we all come and how successful the PHP language is today, in >implementing all sorts of applications most of us would have never even thought >of when we created the language. > >Once you're done thinking, decide for yourself. Does it make sense to be >discussing new language level features every other week? Or should we, >perhaps, invest more in other fronts, which would be beneficial for a far bigger >audience. The levels above - extensions to keep with the latest technologies, >foundation classes, etc. Pretty much, the same direction other mature >languages went to. > >To be clear, and to give this motion higher chances of success, I'm not talking >about jump. PHP can live with jump, almost as well as it could live without it >:) I'm talking about the general sentiment. > >Zeev > >-- >http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: >http://xdebug.org/donate.php >twitter: @derickr and @xdebug > >-- > To unsubscribe, visit: >http://www.php.net/unsub.php --- ## #53290 — Stas Malyshev — 2011-06-15T07:24:07+00:00 URL: https://externals.io/message/53127#53290 · In reply to: #53289 Hi! > Stas, on a different note, weren't we going to roll a 5.4 alpha? I was going to write about it soon, but since you asked: I was waiting for RFC/voting discussion and vote in hope that we could get it all ready before the alpha, but it looks like it is taking longer than expected. So I think maybe we can have the alpha before that - and the RFC says we should have alpha in June anyway, and June is already half-gone :) The original plan was this week, so maybe this Thursday? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #53291 — gaochunhui@gmail.com — 2011-06-15T08:27:50+00:00 URL: https://externals.io/message/53127#53291 · In reply to: #53290 +1, for Thursday :-) -----邮件原件----- 发件人: Stas Malyshev [mailto:smalyshev@sugarcrm.com] 发送时间: 2011年6月15日 15:24 收件人: Andi Gutmans 抄送: PHP Developers Mailing List 主题: [PHP-DEV] Re: 5.4 alpha, was: [PHP-DEV] Give the Language a Rest motion (fwd) Hi! > Stas, on a different note, weren't we going to roll a 5.4 alpha? I was going to write about it soon, but since you asked: I was waiting for RFC/voting discussion and vote in hope that we could get it all ready before the alpha, but it looks like it is taking longer than expected. So I think maybe we can have the alpha before that - and the RFC says we should have alpha in June anyway, and June is already half-gone :) The original plan was this week, so maybe this Thursday? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- To unsubscribe, visit: http://www.php.net/unsub.php --- ## #53292 — Pierre Joye — 2011-06-15T09:33:07+00:00 URL: https://externals.io/message/53127#53292 · In reply to: #53289 > Hence my suggestion to bundle MongoDB extension and possibly work on additional extensions. Some of my suggestions probably rightfully didn't get much interest such as Thrift. See my comment in your other thread and below. > Maybe we should consider making a list of extensions we think could be beneficial and the new mentorship program can actually help deliver some of them? I do not thnk it is a good thing to begin a discussion about this exact topic and then totally ignore it. I also think that it is somehow wrong to post something asking to do not propose new things when we finally have more people involved in proposals and discussions. Maybe that's just me me but I do think that the main problem we have (besides the ones we identified and try to fix right now) is the complete lack of open discussions about possible new features, in this list with new or existing contributors. -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #53296 — Stas Malyshev — 2011-06-15T16:54:01+00:00 URL: https://externals.io/message/53127#53296 · In reply to: #53290 Hi! > The original plan was this week, so maybe this Thursday? After some consideration, we decided to do it on next Monday, the 20th. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #53297 — David Soria Parra — 2011-06-16T01:23:24+00:00 URL: https://externals.io/message/53127#53297 · In reply to: #53290 > Hi! > > > […] > > I was going to write about it soon, but since you asked: I was waiting > for RFC/voting discussion and vote in hope that we could get it all > ready before the alpha, but it looks like it is taking longer than > expected. So I think maybe we can have the alpha before that - and the > RFC says we should have alpha in June anyway, and June is already > half-gone :) > The original plan was this week, so maybe this Thursday? Zeev edited it today. So I hope it's ready for voting within the next days, so we can move forward. --- ## #53298 — Andi Gutmans — 2011-06-16T01:46:07+00:00 URL: https://externals.io/message/53127#53298 · In reply to: #53292 >-----Original Message----- >From: Pierre Joye [mailto:pierre.php@gmail.com] >Sent: Wednesday, June 15, 2011 2:33 AM >To: Andi Gutmans >Cc: Derick Rethans; PHP Developers Mailing List >Subject: Re: [PHP-DEV] Give the Language a Rest motion (fwd) > > > > > […] >additional extensions. Some of my suggestions probably rightfully didn't get >much interest such as Thrift. > >See my comment in your other thread and below. > > > […] >beneficial and the new mentorship program can actually help deliver some of >them? > >I do not thnk it is a good thing to begin a discussion about this exact topic and >then totally ignore it. > I think it got lost in the very long and varying discussions. Will dig up and take a look. I had a couple of hectic weeks. >I also think that it is somehow wrong to post something asking to do not propose >new things when we finally have more people involved in proposals and >discussions. Maybe that's just me me but I do think that the main problem we >have (besides the ones we identified and try to fix right now) is the complete >lack of open discussions about possible new features, in this list with new or >existing contributors. I did not say we should not propose or have discussions (I am in favor of adding [] for arrays for example). But I am saying the bias should be not to include new language functionality unless it has very broad appeal & serious upside impact. The bias should be against feature creep. Andi > >-- >Pierre > >@pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #53299 — dukeofgaming — 2011-06-16T02:36:03+00:00 URL: https://externals.io/message/53127#53299 · In reply to: #53298 Hi, I think that —in any context— the "if it aint broke don't fix it" is a very depressing attitude to have, and a very wrong one in any open source community. If the signal to noise ratio is the problem, I think its better to focus on that problem, not shutting down the signal. If PHP is a resource crunched project, I think its better to focus on that problem, not rejecting feature requests. (I might appear as impertinent with what I'm going to say, but bear with me, I'm being well-intentioned and mean no offense; just want to be honest). Regarding the signal to noise ratio, I have one question: how did traits get accepted?, having seen the kind of conversations in the lists it makes almost no sense to me how something so "radical" and complex could make its way to PHP so quickly and a simple and convenient thing like a short array syntax cannot, and something so basic as annotations raises so much pointless (just not to say ignorant) debate. Was it the to-the-point RFC and solid patch?, was it that the conversations were just on another level so not anyone could just say —or troll— "traits are no solution! *spit*, lets do aspects instead!". I know it took some time, but while lurking the lists IIRC I never saw any opposition to traits... could anyone tell me what was the magic behind this?, could it be repeated?. Regarding resources, I think this is one of the main things rendering the community unhealthy (at least it feels like that to me) and I even feel bitterness in the air. I think that the definite solution to this is a DVCS like git and hosting the code at github, or like mercurial and hosting the code at bitbucket, please don't be angered at this suggestion (as I know the switch to SVN is a fairly recent one), you can ask around SVN geeks that went the distributed way and they will tell you things, wonderful things of how they don't know how could they could endure that much with that in their project, and if its an open source one, how much the switch has done in favor of contributions. Regardless of everything, I like that the PHP community has so much passion and energy, sometimes in a not constructive way, but that is a good problem to have in my opinion, really, don't take it for granted, it just needs a little direction. Best regards, David Vega > > […] > get > > […] > of > > […] > topic and > > […] > > I think it got lost in the very long and varying discussions. Will dig up > and take a look. I had a couple of hectic weeks. > > > […] > propose > > […] > we > > […] > complete > > […] > new or > > […] > > I did not say we should not propose or have discussions (I am in favor of > adding [] for arrays for example). But I am saying the bias should be not to > include new language functionality unless it has very broad appeal & serious > upside impact. The bias should be against feature creep. > > Andi > > > […] --- ## #53300 — Andi Gutmans — 2011-06-16T03:10:30+00:00 URL: https://externals.io/message/53127#53300 · In reply to: #53299 What I am saying is if we accepted even 50% of what people felt very passionate about because their "favorite language of the day" has it then PHP would become overly complex, bloated and very challenging for users to pick up. C++ for example was a good language but is a good example of trying to do too much and getting overly complex over time (at least in my opinion). I do think we should have new feature discussions and need to ensure PHP evolves with the market and its users but have to ensure that we still keep it simple, easy to adopt and maintainable. Also, I think we do not need 100 ways of doing the same thing. Choice is good but too much choice is not. As I said in my previous email, while I think there are areas we can and should innovate in and evolve the core language I believe a lot of the innovation also has to happen at the framework and extension-level. I do not think there's a resource issue at the language level. When a new feature does get slated to be included we always have plenty of resources deployed on it to harden it and make sure it gets into the core vm in the right way (it is almost never the same as the original patch). I do think having more people work on extensions for some of the up and coming technologies would be super valuable. Seems like everyone wants to try and get their favorite language feature in but less are stepping up to work on extensions. What can you contribute? Andi From: dukeofgaming [mailto:dukeofgaming@gmail.com] Sent: Wednesday, June 15, 2011 7:36 PM To: Andi Gutmans Cc: Pierre Joye; Derick Rethans; PHP Developers Mailing List Subject: Re: [PHP-DEV] Give the Language a Rest motion (fwd) Hi, I think that -in any context- the "if it aint broke don't fix it" is a very depressing attitude to have, and a very wrong one in any open source community. If the signal to noise ratio is the problem, I think its better to focus on that problem, not shutting down the signal. If PHP is a resource crunched project, I think its better to focus on that problem, not rejecting feature requests. (I might appear as impertinent with what I'm going to say, but bear with me, I'm being well-intentioned and mean no offense; just want to be honest). Regarding the signal to noise ratio, I have one question: how did traits get accepted?, having seen the kind of conversations in the lists it makes almost no sense to me how something so "radical" and complex could make its way to PHP so quickly and a simple and convenient thing like a short array syntax cannot, and something so basic as annotations raises so much pointless (just not to say ignorant) debate. Was it the to-the-point RFC and solid patch?, was it that the conversations were just on another level so not anyone could just say -or troll- "traits are no solution! *spit*, lets do aspects instead!". I know it took some time, but while lurking the lists IIRC I never saw any opposition to traits... could anyone tell me what was the magic behind this?, could it be repeated?. Regarding resources, I think this is one of the main things rendering the community unhealthy (at least it feels like that to me) and I even feel bitterness in the air. I think that the definite solution to this is a DVCS like git and hosting the code at github, or like mercurial and hosting the code at bitbucket, please don't be angered at this suggestion (as I know the switch to SVN is a fairly recent one), you can ask around SVN geeks that went the distributed way and they will tell you things, wonderful things of how they don't know how could they could endure that much with that in their project, and if its an open source one, how much the switch has done in favor of contributions. Regardless of everything, I like that the PHP community has so much passion and energy, sometimes in a not constructive way, but that is a good problem to have in my opinion, really, don't take it for granted, it just needs a little direction. Best regards, David Vega >-----Original Message----- >From: Pierre Joye [mailto:pierre.php@gmail.com] >Sent: Wednesday, June 15, 2011 2:33 AM >To: Andi Gutmans >Cc: Derick Rethans; PHP Developers Mailing List >Subject: Re: [PHP-DEV] Give the Language a Rest motion (fwd) > > > > > […] >additional extensions. Some of my suggestions probably rightfully didn't get >much interest such as Thrift. > >See my comment in your other thread and below. > > > […] >beneficial and the new mentorship program can actually help deliver some of >them? > >I do not thnk it is a good thing to begin a discussion about this exact topic and >then totally ignore it. > I think it got lost in the very long and varying discussions. Will dig up and take a look. I had a couple of hectic weeks. >I also think that it is somehow wrong to post something asking to do not propose >new things when we finally have more people involved in proposals and >discussions. Maybe that's just me me but I do think that the main problem we >have (besides the ones we identified and try to fix right now) is the complete >lack of open discussions about possible new features, in this list with new or >existing contributors. I did not say we should not propose or have discussions (I am in favor of adding [] for arrays for example). But I am saying the bias should be not to include new language functionality unless it has very broad appeal & serious upside impact. The bias should be against feature creep. Andi > >-- >Pierre > >@pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #53301 — Pascal COURTOIS — 2011-06-16T05:14:35+00:00 URL: https://externals.io/message/53127#53301 · In reply to: #53299 Le 16/06/2011 04:36, dukeofgaming a écrit : > Hi, > > I think that —in any context— the "if it aint broke don't fix it" is a very > depressing attitude to have, and a very wrong one in any open source > community. What I feel depressing is the urge of the PHP core team to fix working features instead of focusing on the 1800 open bug tickets. On every PHP project I work on I had to find workarounds because PHP crashes. Behaviour bugs (feature not working as intented) are annoying but memory leaks and memory corruptions are just a no no no in production environnement. The only way to call PHP when its memory leaks and get corrupted is to call it via CGI which is much too slow for a production server. What I need is a very stable language on which I can rely and I'm very sad to to say PHP is getting worse and worse on that point of view versions after versions. --- ## #53302 — Stas Malyshev — 2011-06-16T05:23:52+00:00 URL: https://externals.io/message/53127#53302 · In reply to: #53301 Hi! > On every PHP project I work on I had to find workarounds because PHP crashes. > Behaviour bugs (feature not working as intended) are annoying but memory leaks and > memory corruptions are just a no no no in production environment. The only way A key to fixing memory corruption is providing good bug reports - with backtraces, valgrind reports, etc. If you have such reports and nothing happens to them - you may want to try to raise the profile of bug reports that are bothering you by mentioning them on the list and calling for volonteers to fix them. Usually if bug is in frequently used module and reproduceable, there would be somebody who can fix it. > What I need is a very stable language on which I can rely and I'm very sad to > to say PHP is getting worse and worse on that point of view versions after versions. I can not contradict your experience, it is what it is, but my experience for years working with PHP was exactly the opposite. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #53303 — Pascal COURTOIS — 2011-06-16T05:48:57+00:00 URL: https://externals.io/message/53127#53303 · In reply to: #53302 Le 16/06/2011 07:23, Stas Malyshev a écrit : > Hi! > > > […] > > A key to fixing memory corruption is providing good bug reports - > with backtraces, valgrind reports, etc. If you have such reports and > nothing happens to them - you may want to try to raise the profile of > bug reports that are bothering you by mentioning them on the list and > calling for volonteers to fix them. Usually if bug is in frequently > used module and reproduceable, there would be somebody who can fix > it. what I did every single time. Among all my bug reports I had one answer from decoder-php@own-hero.net (thanks to him) who reduced the test case for a memory leak (bug 54460). I'm not talking about bugs in modules but bugs in *core* which can be reproduced with few lines of *core* PHP. > > […] > > I can not contradict your experience, it is what it is, but my > experience for years working with PHP was exactly the opposite. To tell you the truth, I've been asked to rewrite the framework I did in Ruby because of these problems. I'm of course very reluctant to go that way but in the end I may have no choice :-( --- ## #53304 — dukeofgaming — 2011-06-16T06:01:20+00:00 URL: https://externals.io/message/53127#53304 · In reply to: #53301 On Thu, Jun 16, 2011 at 12:14 AM, Pascal COURTOIS wrote: > Le 16/06/2011 04:36, dukeofgaming a écrit : > > […] > very > > […] > > What I feel depressing is the urge of the PHP core team to fix working > features > instead of focusing on the 1800 open bug tickets. > Sorry if the question is dumb, but, how many core developers does PHP have?, how many in total (including non-core contributors)?. Regards, David --- ## #53305 — Stas Malyshev — 2011-06-16T06:10:24+00:00 URL: https://externals.io/message/53127#53305 · In reply to: #53303 Hi! > what I did every single time. Among all my bug reports I had one answer > from decoder-php@own-hero.net (thanks to him) who reduced the test case > for a memory leak (bug 54460). I'm not talking about bugs in modules > but bugs in *core* which can be reproduced with few lines of *core* PHP. I am reading the list pretty closely and I don't remember any emails from you raising the question of reproducible corruption bugs recently, except indeed for 54460 which seems to be a memory leak, though presence of xcache in the trace suggests it may not even be a PHP bug. It talks about bug in a template engine containing thousands of lines. This is pretty hard work to debug something starting with huge unknown code, so no wonder nobody got to it yet. PHP is a volunteer project, and it's not easy to find volunteers to dig into thousand lines of unknown code to find a bug that may not even be there. It's quite a hard work. I must have missed other ones. But if they are still reproducible in 5.4 and you have reproducing code, you're welcome to share on the list. Unfortunately, bugs.php.net seems to be down, but once it gets up we could look into it and see if we can fix any. As I said, good reproduction makes it better. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #53306 — Pascal COURTOIS — 2011-06-16T06:12:56+00:00 URL: https://externals.io/message/53127#53306 · In reply to: #53304 Le 16/06/2011 08:01, dukeofgaming a écrit : > Sorry if the question is dumb, but, how many core developers does PHP have?, > how many in total (including non-core contributors)?. That's not the point. Whatever the project is, every developer should fix existing bugs before even thinking about improving. That's the way I do and that's why there is no bug I'm aware in my programs. --- ## #53307 — Michael Wallner — 2011-06-16T06:29:43+00:00 URL: https://externals.io/message/53127#53307 · In reply to: #53305 > Hi! > > > […] Stas, how I can i finally persuade you to quote the name of the people you're replying to? :) I find it very hard to follow any discussion you're involved in. Thanks, Mike --- ## #53308 — dukeofgaming — 2011-06-16T06:34:38+00:00 URL: https://externals.io/message/53127#53308 · In reply to: #53306 On Thu, Jun 16, 2011 at 1:12 AM, Pascal COURTOIS wrote: > Le 16/06/2011 08:01, dukeofgaming a écrit : > > > […] > have?, > > […] > > That's not the point. Whatever the project is, every developer should fix > existing bugs before even thinking about improving. That's the way I do and > that's why there is no bug I'm aware in my programs. > > I really mean the question, regardless. --- ## #53309 — Pascal COURTOIS — 2011-06-16T06:38:31+00:00 URL: https://externals.io/message/53127#53309 · In reply to: #53305 Le 16/06/2011 08:10, Stas Malyshev a écrit : > Hi! > > > […] > > I am reading the list pretty closely and I don't remember any emails > from you raising the question of reproducible corruption bugs > recently, except indeed for 54460 which seems to be a memory leak, > though presence of xcache in the trace suggests it may not even be a > PHP bug. It talks about bug in a template engine containing thousands > of lines. This is pretty hard work to debug something starting with > huge unknown code, so no wonder nobody got to it yet. PHP is a > volunteer project, and it's not easy to find volunteers to dig into > thousand lines of unknown code to find a bug that may not even be > there. It's quite a hard work. as I said earlier, test case was reduced to: as you can see there's nothing but PHP core instructions in that code. > I must have missed other ones. But if they are still reproducible in > 5.4 and you have reproducing code, you're welcome to share on the > list. Unfortunately, bugs.php.net seems to be down, but once it gets > up we could look into it and see if we can fix any. for memory leaks if the bug is fixed it will not happen again but for memory corruption it's something totaly different. The fact that a bug disapears doesn't mean in any way it has been fixed. > As I said, good > reproduction makes it better. I've been debugging in lots of languages including assembly codes for over 30 years so I know precisely what you mean. So when it's possible to reproduce a bug in some known conditions, the wait-and-see attitude is not a good option because it's very likely that the bug will disapear. Memory coruptions are much like terrorist attacks: you never know where and when it will happen. In bug 614904 I submitted a TWO lines program which crashed PHP on a absolutely standard i386 debian install. I got no answer. Of course the bug disapeared in following versions of PHP but what is fixed ? Not as far as I know. --- ## #53310 — Lester Caine — 2011-06-16T06:52:16+00:00 URL: https://externals.io/message/53127#53310 · In reply to: #53303 Pascal COURTOIS wrote: > > […] > > To tell you the truth, I've been asked to rewrite the framework I > did in Ruby because of these problems. I'm of course very reluctant > to go that way but in the end I may have no choice:-( Pascal I am sure that many people here would be more than happy to hear about particular problems you are hitting. Like Stas I have never had problems with the stability of PHP5 in 10 years of running it. YES I can get it to crash, but it has always told me why and fixing the problem clears that up. I do have sites that become unstable, but I have yet to find a situation where PHP was the problem ... My grumble is with having to rewrite code simply because someone has decided that what I was doing is no longer acceptable ... if I can run my code with display_errors ON then I know I've got clean code :) -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php --- ## #53311 — Pascal COURTOIS — 2011-06-16T07:04:47+00:00 URL: https://externals.io/message/53127#53311 · In reply to: #53310 Le 16/06/2011 08:52, Lester Caine a écrit : > Pascal I am sure that many people here would be more than happy to > hear about particular problems you are hitting. Ok, then why when I signal a bug noone cares ? > Like Stas I have > never had problems with the stability of PHP5 in 10 years of running > it. PHP5 did not exist 10 years ago ;-) Anyway, around 2001 it took me one year (not full time) to find out there was a memory corruption in PHP. At that time I was using mod_php. It crashed Apache. > YES I can get it to crash, but it has always told me why and > fixing the problem clears that up. I do have sites that become > unstable, but I have yet to find a situation where PHP was the > problem ... when you have a bug in PHP it should not ever ever crash PHP and unfortunately I encountered that case dozens of times. > My grumble is with having to rewrite code simply because someone has > decided that what I was doing is no longer acceptable ... if I can > run my code with display_errors ON then I know I've got clean code > :) I 1000% agree --- ## #53312 — Lester Caine — 2011-06-16T07:19:45+00:00 URL: https://externals.io/message/53127#53312 · In reply to: #53311 Pascal COURTOIS wrote: > > […] > > PHP5 did not exist 10 years ago ;-) OK coming on 8 years ... seems longer :) I looked at PHP4, but PHP5 was at release candidate stage so I decided that I'd skip straight to that. But I still had to learn PHP4 as people expected backwards compatibility. My ISP 1and1 STILL list PHP4 as the default for virtual hosting :( > Anyway, around 2001 it took me one year (not full time) to find out > there was a memory corruption in PHP. At that time I was using mod_php. > It crashed Apache. > > > […] > > when you have a bug in PHP it should not ever ever crash PHP and > unfortunately I encountered that case dozens of times. At least on Linux is just recovers and carries on The earlier windows stuff I had used to just crash the whole machine. PHP was something of a refreshing change ... I am behind you on getting what we have a lot better. Many thing have been pushed in and then forgotten ... like PDO! -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php --- ## #53313 — Philip Olson — 2011-06-16T07:23:41+00:00 URL: https://externals.io/message/53127#53313 · In reply to: #53308 > On Thu, Jun 16, 2011 at 1:12 AM, Pascal COURTOIS > wrote: > > > […] > I really mean the question, regardless. It's difficult to say, but there are a total of 1,568 php.net accounts. The karma[1] rules aren't straightforward to parse but quickly it shows at least 194 people with full php-src[2] karma, and 54 humans made 1,971 SVN commits to php-src within the last 365 days. Those numbers include tests, so the number of ~active core developers appears closer to 10-20. Of course this doesn't include other parts like PECL and documentation but enough hastily created and probably misleading statistics for today. As for the point of the question, php.net could certainly use more contributors and ideally we'd clone Felipe. A lot. [1] http://svn.php.net/viewvc/SVNROOT/global_avail?view=markup [2] http://svn.php.net/viewvc/php/php-src/ Regards, Philip --- Next page: https://externals.io/message/53127.md?page=2