Re: [PHP-DEV] Give the Language a Rest motion (fwd)
On Thu, Jun 16, 2011 at 12:14 AM, Pascal COURTOIS pascal.court...@nouvo.com wrote: Le 16/06/2011 04:36, dukeofgaming a écrit : Hi, I think that —in any context— the if it aint broke don't fix it is a very depressing attitude to have, and a very wrong one in any open source community. What I feel depressing is the urge of the PHP core team to fix working features instead of focusing on the 1800 open bug tickets. Sorry if the question is dumb, but, how many core developers does PHP have?, how many in total (including non-core contributors)?. Regards, David
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
Hi! what I did every single time. Among all my bug reports I had one answer from decoder-...@own-hero.net (thanks to him) who reduced the test case for a memory leak (bug 54460). I'm not talking about bugs in modules but bugs in *core* which can be reproduced with few lines of *core* PHP. I am reading the list pretty closely and I don't remember any emails from you raising the question of reproducible corruption bugs recently, except indeed for 54460 which seems to be a memory leak, though presence of xcache in the trace suggests it may not even be a PHP bug. It talks about bug in a template engine containing thousands of lines. This is pretty hard work to debug something starting with huge unknown code, so no wonder nobody got to it yet. PHP is a volunteer project, and it's not easy to find volunteers to dig into thousand lines of unknown code to find a bug that may not even be there. It's quite a hard work. I must have missed other ones. But if they are still reproducible in 5.4 and you have reproducing code, you're welcome to share on the list. Unfortunately, bugs.php.net seems to be down, but once it gets up we could look into it and see if we can fix any. As I said, good reproduction makes it better. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
Le 16/06/2011 08:01, dukeofgaming a écrit : Sorry if the question is dumb, but, how many core developers does PHP have?, how many in total (including non-core contributors)?. That's not the point. Whatever the project is, every developer should fix existing bugs before even thinking about improving. That's the way I do and that's why there is no bug I'm aware in my programs. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
On Wed, 15 Jun 2011 23:10:24 -0700, Stas Malyshev wrote: Hi! what I did every single time. Among all my bug reports I had one answer Stas, how I can i finally persuade you to quote the name of the people you're replying to? :) I find it very hard to follow any discussion you're involved in. Thanks, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
On Thu, Jun 16, 2011 at 1:12 AM, Pascal COURTOIS pascal.court...@nouvo.comwrote: Le 16/06/2011 08:01, dukeofgaming a écrit : Sorry if the question is dumb, but, how many core developers does PHP have?, how many in total (including non-core contributors)?. That's not the point. Whatever the project is, every developer should fix existing bugs before even thinking about improving. That's the way I do and that's why there is no bug I'm aware in my programs. I really mean the question, regardless.
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
Le 16/06/2011 08:10, Stas Malyshev a écrit :
Hi!
what I did every single time. Among all my bug reports I had one
answer from decoder-...@own-hero.net (thanks to him) who reduced
the test case for a memory leak (bug 54460). I'm not talking about
bugs in modules but bugs in *core* which can be reproduced with few
lines of *core* PHP.
I am reading the list pretty closely and I don't remember any emails
from you raising the question of reproducible corruption bugs
recently, except indeed for 54460 which seems to be a memory leak,
though presence of xcache in the trace suggests it may not even be a
PHP bug. It talks about bug in a template engine containing thousands
of lines. This is pretty hard work to debug something starting with
huge unknown code, so no wonder nobody got to it yet. PHP is a
volunteer project, and it's not easy to find volunteers to dig into
thousand lines of unknown code to find a bug that may not even be
there. It's quite a hard work.
as I said earlier, test case was reduced to:
?php
class TempleetRedirect extends Exception {};
Function parseform($template) {
$txt = eval_list($templatecache[$template]['template']);
}
Function eval_list($array) {
throw new TempleetRedirect($file);
}
Function parsetemplate($template) {
$txt = parseform($template);
}
try
{
$output=parsetemplate($global_var['template']);
}
catch (TempleetRedirect $r)
{
exit();
}
?
as you can see there's nothing but PHP core instructions in that code.
I must have missed other ones. But if they are still reproducible in
5.4 and you have reproducing code, you're welcome to share on the
list. Unfortunately, bugs.php.net seems to be down, but once it gets
up we could look into it and see if we can fix any.
for memory leaks if the bug is fixed it will not happen again but
for memory corruption it's something totaly different. The fact that
a bug disapears doesn't mean in any way it has been fixed.
As I said, good
reproduction makes it better.
I've been debugging in lots of languages including assembly codes
for over 30 years so I know precisely what you mean. So when it's
possible to reproduce a bug in some known conditions, the wait-and-see
attitude is not a good option because it's very likely that the bug
will disapear. Memory coruptions are much like terrorist attacks:
you never know where and when it will happen.
In bug 614904 I submitted a TWO lines program which crashed PHP on
a absolutely standard i386 debian install. I got no answer.
Of course the bug disapeared in following versions of PHP but what is fixed ?
Not as far as I know.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
Pascal COURTOIS wrote: What I need is a very stable language on which I can rely and I'm very sad to to say PHP is getting worse and worse on that point of view versions after versions. I can not contradict your experience, it is what it is, but my experience for years working with PHP was exactly the opposite. To tell you the truth, I've been asked to rewrite the framework I did in Ruby because of these problems. I'm of course very reluctant to go that way but in the end I may have no choice:-( Pascal I am sure that many people here would be more than happy to hear about particular problems you are hitting. Like Stas I have never had problems with the stability of PHP5 in 10 years of running it. YES I can get it to crash, but it has always told me why and fixing the problem clears that up. I do have sites that become unstable, but I have yet to find a situation where PHP was the problem ... My grumble is with having to rewrite code simply because someone has decided that what I was doing is no longer acceptable ... if I can run my code with display_errors ON then I know I've got clean code :) -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
Le 16/06/2011 08:52, Lester Caine a écrit : Pascal I am sure that many people here would be more than happy to hear about particular problems you are hitting. Ok, then why when I signal a bug noone cares ? Like Stas I have never had problems with the stability of PHP5 in 10 years of running it. PHP5 did not exist 10 years ago ;-) Anyway, around 2001 it took me one year (not full time) to find out there was a memory corruption in PHP. At that time I was using mod_php. It crashed Apache. YES I can get it to crash, but it has always told me why and fixing the problem clears that up. I do have sites that become unstable, but I have yet to find a situation where PHP was the problem ... when you have a bug in PHP it should not ever ever crash PHP and unfortunately I encountered that case dozens of times. My grumble is with having to rewrite code simply because someone has decided that what I was doing is no longer acceptable ... if I can run my code with display_errors ON then I know I've got clean code :) I 1000% agree -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
Pascal COURTOIS wrote: Like Stas I have never had problems with the stability of PHP5 in 10 years of running it. PHP5 did not exist 10 years ago ;-) OK coming on 8 years ... seems longer :) I looked at PHP4, but PHP5 was at release candidate stage so I decided that I'd skip straight to that. But I still had to learn PHP4 as people expected backwards compatibility. My ISP 1and1 STILL list PHP4 as the default for virtual hosting :( Anyway, around 2001 it took me one year (not full time) to find out there was a memory corruption in PHP. At that time I was using mod_php. It crashed Apache. YES I can get it to crash, but it has always told me why and fixing the problem clears that up. I do have sites that become unstable, but I have yet to find a situation where PHP was the problem ... when you have a bug in PHP it should not ever ever crash PHP and unfortunately I encountered that case dozens of times. At least on Linux is just recovers and carries on The earlier windows stuff I had used to just crash the whole machine. PHP was something of a refreshing change ... I am behind you on getting what we have a lot better. Many thing have been pushed in and then forgotten ... like PDO! -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
On Jun 15, 2011, at 11:34 PM, dukeofgaming wrote: On Thu, Jun 16, 2011 at 1:12 AM, Pascal COURTOIS pascal.court...@nouvo.comwrote: Le 16/06/2011 08:01, dukeofgaming a écrit : Sorry if the question is dumb, but, how many core developers does PHP have?, how many in total (including non-core contributors)?. That's not the point. Whatever the project is, every developer should fix existing bugs before even thinking about improving. That's the way I do and that's why there is no bug I'm aware in my programs. I really mean the question, regardless. It's difficult to say, but there are a total of 1,568 php.net accounts. The karma[1] rules aren't straightforward to parse but quickly it shows at least 194 people with full php-src[2] karma, and 54 humans made 1,971 SVN commits to php-src within the last 365 days. Those numbers include tests, so the number of ~active core developers appears closer to 10-20. Of course this doesn't include other parts like PECL and documentation but enough hastily created and probably misleading statistics for today. As for the point of the question, php.net could certainly use more contributors and ideally we'd clone Felipe. A lot. [1] http://svn.php.net/viewvc/SVNROOT/global_avail?view=markup [2] http://svn.php.net/viewvc/php/php-src/ Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
Le 16/06/2011 09:19, Lester Caine a écrit : when you have a bug in PHP it should not ever ever crash PHP and unfortunately I encountered that case dozens of times. At least on Linux is just recovers and carries on If PHP crashes, yes, it recovers but it's VERY resource and time consumming. If PHP corrupts some memory, it does not crash fastcgi processes but the next request(s) behave erratically. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
On 6/15/11 11:38 PM, Pascal COURTOIS wrote: In bug 614904 I submitted a TWO lines program which crashed PHP on a absolutely standard i386 debian install. I got no answer. Of course the bug disapeared in following versions of PHP but what is fixed ? Not as far as I know. 614904 doesn't look like real bug number. Must be a typo. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
Le 16/06/2011 09:29, Stas Malyshev a écrit : On 6/15/11 11:38 PM, Pascal COURTOIS wrote: In bug 614904 I submitted a TWO lines program which crashed PHP on a absolutely standard i386 debian install. I got no answer. Of course the bug disapeared in following versions of PHP but what is fixed ? Not as far as I know. 614904 doesn't look like real bug number. Must be a typo. ooops, sorry. You're right. It's a bug I submitted to debian because of the way they work with releases having a version with no feature update but including security updates, which means the versions in debian distribution are not exactly the ones released. Since debian requires that bug submitted should not be submitted also to program developpers, I complied. May be it was a mistake... -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
On 6/15/11 11:38 PM, Pascal COURTOIS wrote: as I said earlier, test case was reduced to: The leaks you'll be seeing in this code is probably caused by the fact that main function (i.e. global context) is not destroyed when exit() is called, since . It can be argued as a bug, but very minor one and totally unlikely to cause any problems both because the leak is minuscule and the fact that memory manager will clean it up anyway on shutdown. I would have very hard time believing this very short-time leak can cause any problems in any production code. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
Le 16/06/2011 09:56, Stas Malyshev a écrit : On 6/15/11 11:38 PM, Pascal COURTOIS wrote: as I said earlier, test case was reduced to: The leaks you'll be seeing in this code is probably caused by the fact that main function (i.e. global context) is not destroyed when exit() is called, since . It can be argued as a bug, but very minor one and totally unlikely to cause any problems both because the leak is minuscule and the fact that memory manager will clean it up anyway on shutdown. If you call minuscule a leak that requires more than 128Mb as it normally requires about 4Mb, then it's minuscule but whatever you name it it just does not run. I would have very hard time believing this very short-time leak can cause any problems in any production code. It does -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
Hi! On 6/16/11 1:05 AM, Pascal COURTOIS wrote: If you call minuscule a leak that requires more than 128Mb as it normally requires about 4Mb, then it's minuscule but whatever you name it it just does not run. Sorry, if your example generates memory footprint of 128Mb, something is seriously wrong with your build. There's no way this code can produce 128Mb footprint. If it's another code, they we'd need to investigate what causes that leak, which must be different from the one this code produces. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
Le 16/06/2011 10:12, Stas Malyshev a écrit : Hi! On 6/16/11 1:05 AM, Pascal COURTOIS wrote: If you call minuscule a leak that requires more than 128Mb as it normally requires about 4Mb, then it's minuscule but whatever you name it it just does not run. Sorry, if your example generates memory footprint of 128Mb, something is seriously wrong with your build. There's no way this code can produce 128Mb footprint. If it's another code, they we'd need to investigate what causes that leak, that's a deal. I have no time right now but I will summerize on tuesday the whole thing that leaded to this code. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
On Thu, Jun 16, 2011 at 3:46 AM, Andi Gutmans a...@zend.com wrote: -Original Message- From: Pierre Joye [mailto:pierre@gmail.com] Sent: Wednesday, June 15, 2011 2:33 AM To: Andi Gutmans Cc: Derick Rethans; PHP Developers Mailing List Subject: Re: [PHP-DEV] Give the Language a Rest motion (fwd) On Wed, Jun 15, 2011 at 7:02 AM, Andi Gutmans a...@zend.com wrote: Hence my suggestion to bundle MongoDB extension and possibly work on additional extensions. Some of my suggestions probably rightfully didn't get much interest such as Thrift. See my comment in your other thread and below. Maybe we should consider making a list of extensions we think could be beneficial and the new mentorship program can actually help deliver some of them? I do not thnk it is a good thing to begin a discussion about this exact topic and then totally ignore it. I think it got lost in the very long and varying discussions. Will dig up and take a look. I had a couple of hectic weeks. It was not a long discussion and you began this thread :) http://news.php.net/php.internals/52898 I also think that it is somehow wrong to post something asking to do not propose new things when we finally have more people involved in proposals and discussions. Maybe that's just me me but I do think that the main problem we have (besides the ones we identified and try to fix right now) is the complete lack of open discussions about possible new features, in this list with new or existing contributors. I did not say we should not propose or have discussions (I am in favor of adding [] for arrays for example). But I am saying the bias should be not to include new language functionality unless it has very broad appeal serious upside impact. The bias should be against feature creep. Right, that's why we introduce a voting RFC in addition to the release RFC, with some large majority concept. However I still think that such posts are inappropriate, timely and generally, while being of freedom of speak ;-) Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
On Thu, 2011-06-16 at 08:12 +0200, Pascal COURTOIS wrote: Le 16/06/2011 08:01, dukeofgaming a écrit : Sorry if the question is dumb, but, how many core developers does PHP have?, how many in total (including non-core contributors)?. That's not the point. Whatever the project is, every developer should fix existing bugs before even thinking about improving. That's the way I do and that's why there is no bug I'm aware in my programs. Feel free to contribute. PHP is driven by volunteers spending their free time on it. For many it is more fun to implement new stuff they probably need than fixing bugs in some code which has some side effects which are not always easy to predict and which they actually don't use. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
Le 16/06/2011 11:36, Johannes Schlüter a écrit : On Thu, 2011-06-16 at 08:12 +0200, Pascal COURTOIS wrote: Le 16/06/2011 08:01, dukeofgaming a écrit : Sorry if the question is dumb, but, how many core developers does PHP have?, how many in total (including non-core contributors)?. That's not the point. Whatever the project is, every developer should fix existing bugs before even thinking about improving. That's the way I do and that's why there is no bug I'm aware in my programs. Feel free to contribute. PHP is driven by volunteers spending their free time on it. I know. I also have a GPL project. Nonetheless some societies use it, and some people rely on it to get paid. I have absolutely no legal contract with anyone but I have a moral contract and when I'm signaled a bug, it is mostly fixed within few hours. I just can't imagine replying to a bug submission Hey guy, its a free project. Why don't you fix it yourself ? My conscience tells me to not release a program if people using it can shoot themself in the foot. For many it is more fun to implement new stuff they probably need than fixing bugs in some code which has some side effects which are not always easy to predict and which they actually don't use. If you followed the thread you have seen the reduced test case is VERY short and the ONLY constructions involved are user functions and exceptions. FULL STOP. Not even a single addition nor a loop nor nothing. I can't imagine nobody uses user functions and exceptions. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
2011/6/16 Pascal COURTOIS pascal.court...@nouvo.com: I know. I also have a GPL project. Nonetheless some societies use it, and some people rely on it to get paid. I have absolutely no legal contract with anyone but I have a moral contract and when I'm signaled a bug, it is mostly fixed within few hours. I just can't imagine replying to a bug submission Hey guy, its a free project. Why don't you fix it yourself ? My conscience tells me to not release a program if people using it can shoot themself in the foot. It is not what Johannes said and we do fix bugs every single day. What Johannes said is that we can't force a volunteer to do something specific instead of what he wants to do. It is also totally off topic btw. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
Le 16/06/2011 12:12, Pierre Joye a écrit : It is not what Johannes said and we do fix bugs every single day. What Johannes said is that we can't force a volunteer to do something specific instead of what he wants to do. It is also totally off topic btw. It is really on topic since letting someone insert his wonderful clever feature in a project, whatever it is, and not maintain it is a project management problem. PHP makes me think of a ship with tens of stirring wheels. Of course no one can be forced to do what he doesn't want but a free project doesn't mean unmanaged project and a managed project means people with responsibilities. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
On 06/16/2011 11:03 AM, Pascal COURTOIS wrote: If you followed the thread you have seen the reduced test case is VERY short and the ONLY constructions involved are user functions and exceptions. FULL STOP. Not even a single addition nor a loop nor nothing. I can't imagine nobody uses user functions and exceptions. You might also consider that your particular case is rather unique. I tried your test case and saw no leak after the request. Everything is freed on request shutdown. That means that for pretty much everyone doing standard short web requests, this style of code would work perfectly for them. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
Le 16/06/2011 12:31, Rasmus a écrit : On 06/16/2011 11:03 AM, Pascal COURTOIS wrote: If you followed the thread you have seen the reduced test case is VERY short and the ONLY constructions involved are user functions and exceptions. FULL STOP. Not even a single addition nor a loop nor nothing. I can't imagine nobody uses user functions and exceptions. You might also consider that your particular case is rather unique. I since decoder-...@own-hero.net could reduce the case from my original program in the conditions I stated, he could obvously detect the leaks. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
On Thu, 2011-06-16 at 12:26 +0200, Pascal COURTOIS wrote: Le 16/06/2011 12:12, Pierre Joye a écrit : It is not what Johannes said and we do fix bugs every single day. What Johannes said is that we can't force a volunteer to do something specific instead of what he wants to do. It is also totally off topic btw. It is really on topic since letting someone insert his wonderful clever feature in a project, whatever it is, and not maintain it is a project management problem. PHP makes me think of a ship with tens of stirring wheels. Of course no one can be forced to do what he doesn't want but a free project doesn't mean unmanaged project and a managed project means people with responsibilities. We are fixing bugs. We don't accept any new feature. Sometimes we might accept features in order to motivate contributors hoping they also fix bugs in the future. And even if the reproduce case is short: Some things in the engine are hard to fix, need thought and verification. Some things even can't be fixed within a bug fix release (x.y.z+1) as they require API changes or such. And then there are cases where severity is valuated differently. There are things we (whomever that includes) don't consider a use case as a proper/important use case and focus on other issues while it might be critical for few users ... We're welcoming people providing bug fixes. We'd love having zero bugs. But life isn't easy. We also welcome people who go through the bug reports and verify them, simplify test cases etc. This is also work to be done. We receive quite a few bug reports per day (well not right now as the system is down :-/ ) most of them aren't bugs but wrong expectations, many are probably bugs, few are actual easy to verify bugs. Going through them also costs quite some time. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
On 06/16/2011 11:40 AM, Pascal COURTOIS wrote: Le 16/06/2011 12:31, Rasmus a écrit : On 06/16/2011 11:03 AM, Pascal COURTOIS wrote: If you followed the thread you have seen the reduced test case is VERY short and the ONLY constructions involved are user functions and exceptions. FULL STOP. Not even a single addition nor a loop nor nothing. I can't imagine nobody uses user functions and exceptions. You might also consider that your particular case is rather unique. I since decoder-...@own-hero.net could reduce the case from my original program in the conditions I stated, he could obvously detect the leaks. I'm not saying there aren't any. There are known leaks in compile_file() when you throw an exception like that, so if you call a huge amount of these within a single request, you are going to have problems. But that is not something the average person hits, and again, they are all free'ed on request shutdown, so it isn't like it is a persistent leak. eg. rasmus@x220:~/php-src/branches/PHP_5_3$ USE_ZEND_ALLOC=0 valgrind --leak-check=full sapi/cli/php pas.php ==17658== Memcheck, a memory error detector ==17658== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al. ==17658== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info ==17658== Command: sapi/cli/php pas.php ==17658== ==17658== ==17658== HEAP SUMMARY: ==17658== in use at exit: 3,376 bytes in 18 blocks ==17658== total heap usage: 25,077 allocs, 25,059 frees, 3,952,839 bytes allocated ==17658== ==17658== 9 bytes in 1 blocks are possibly lost in loss record 3 of 16 ==17658==at 0x4C28FAC: malloc (vg_replace_malloc.c:236) ==17658==by 0x78F2DF: _estrndup (zend_alloc.c:2503) ==17658==by 0x78477B: lex_scan (zend_language_scanner.l:1817) ==17658==by 0x7994DF: zendlex (zend_compile.c:4969) ==17658==by 0x77B9B4: zendparse (zend_language_parser.c:3291) ==17658==by 0x77F3BE: compile_file (zend_language_scanner.l:364) ==17658==by 0x601350: phar_compile_file (phar.c:3393) ==17658==by 0x7ACF48: zend_execute_scripts (zend.c:1187) ==17658==by 0x75AA52: php_execute_script (main.c:2284) ==17658==by 0x8406D3: main (php_cli.c:1193) ==17658== ==17658== 14 bytes in 1 blocks are possibly lost in loss record 4 of 16 ==17658==at 0x4C28FAC: malloc (vg_replace_malloc.c:236) ==17658==by 0x7A8D9A: zend_str_tolower_dup (zend_operators.c:1884) ==17658==by 0x79B36E: zend_do_begin_function_call (zend_compile.c:1571) ==17658==by 0x77E64B: zendparse (zend_language_parser.y:671) ==17658==by 0x77F3BE: compile_file (zend_language_scanner.l:364) ==17658==by 0x601350: phar_compile_file (phar.c:3393) ==17658==by 0x7ACF48: zend_execute_scripts (zend.c:1187) ==17658==by 0x75AA52: php_execute_script (main.c:2284) ==17658==by 0x8406D3: main (php_cli.c:1193) ==17658== ==17658== 17 bytes in 1 blocks are possibly lost in loss record 5 of 16 ==17658==at 0x4C28FAC: malloc (vg_replace_malloc.c:236) ==17658==by 0x78F2DF: _estrndup (zend_alloc.c:2503) ==17658==by 0x78059A: lex_scan (zend_language_scanner.l:1695) ==17658==by 0x7994DF: zendlex (zend_compile.c:4969) ==17658==by 0x77B9B4: zendparse (zend_language_parser.c:3291) ==17658==by 0x77F3BE: compile_file (zend_language_scanner.l:364) ==17658==by 0x601350: phar_compile_file (phar.c:3393) ==17658==by 0x7ACF48: zend_execute_scripts (zend.c:1187) ==17658==by 0x75AA52: php_execute_script (main.c:2284) ==17658==by 0x8406D3: main (php_cli.c:1193) ==17658== ==17658== 648 (232 direct, 416 indirect) bytes in 1 blocks are definitely lost in loss record 15 of 16 ==17658==at 0x4C28FAC: malloc (vg_replace_malloc.c:236) ==17658==by 0x77F344: compile_file (zend_language_scanner.l:334) ==17658==by 0x601350: phar_compile_file (phar.c:3393) ==17658==by 0x7ACF48: zend_execute_scripts (zend.c:1187) ==17658==by 0x75AA52: php_execute_script (main.c:2284) ==17658==by 0x8406D3: main (php_cli.c:1193) ==17658== ==17658== 1,680 bytes in 1 blocks are possibly lost in loss record 16 of 16 ==17658==at 0x4C290A4: realloc (vg_replace_malloc.c:525) ==17658==by 0x7A2273: pass_two (zend_opcode.c:380) ==17658==by 0x77F407: compile_file (zend_language_scanner.l:376) ==17658==by 0x601350: phar_compile_file (phar.c:3393) ==17658==by 0x7ACF48: zend_execute_scripts (zend.c:1187) ==17658==by 0x75AA52: php_execute_script (main.c:2284) ==17658==by 0x8406D3: main (php_cli.c:1193) ==17658== ==17658== LEAK SUMMARY: ==17658==definitely lost: 232 bytes in 1 blocks ==17658==indirectly lost: 416 bytes in 6 blocks ==17658== possibly lost: 1,720 bytes in 4 blocks ==17658==still reachable: 1,008 bytes in 7 blocks ==17658== suppressed: 0 bytes in 0 blocks ==17658== Reachable blocks (those to which a pointer was found) are not shown. ==17658== To see them, rerun with: --leak-check=full --show-reachable=yes ==17658== ==17658== For counts of detected and suppressed
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
On 06/16/2011 12:42 PM, Rasmus wrote: On 06/16/2011 11:40 AM, Pascal COURTOIS wrote: Le 16/06/2011 12:31, Rasmus a écrit : On 06/16/2011 11:03 AM, Pascal COURTOIS wrote: If you followed the thread you have seen the reduced test case is VERY short and the ONLY constructions involved are user functions and exceptions. FULL STOP. Not even a single addition nor a loop nor nothing. I can't imagine nobody uses user functions and exceptions. You might also consider that your particular case is rather unique. I since decoder-...@own-hero.net could reduce the case from my original program in the conditions I stated, he could obvously detect the leaks. I'm not saying there aren't any. There are known leaks in compile_file() when you throw an exception like that, so if you call a huge amount of these within a single request, you are going to have problems. But that is not something the average person hits, and again, they are all free'ed on request shutdown, so it isn't like it is a persistent leak. I was bit unclear there. The cause of the leaks is the exit() in your exception, not the exception itself. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
Le 16/06/2011 13:42, Rasmus a écrit : On 06/16/2011 11:40 AM, Pascal COURTOIS wrote: Le 16/06/2011 12:31, Rasmus a écrit : On 06/16/2011 11:03 AM, Pascal COURTOIS wrote: If you followed the thread you have seen the reduced test case is VERY short and the ONLY constructions involved are user functions and exceptions. FULL STOP. Not even a single addition nor a loop nor nothing. I can't imagine nobody uses user functions and exceptions. You might also consider that your particular case is rather unique. I since decoder-...@own-hero.net could reduce the case from my original program in the conditions I stated, he could obvously detect the leaks. I'm not saying there aren't any. There are known leaks in compile_file() when you throw an exception like that, so if you call a huge amount of these within a single request, which is not the case. At most I will have 3 or 4 exceptions per request. you are going to have problems. But that is not something the average person hits, and again, they are all free'ed on request shutdown, so it isn't like it is a persistent leak. Ok, as said before I will summerize the facts on tuesday. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Getting a list of registered namespaces.
On 15 June 2011 17:23, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! With pecl/http (DEV-2 branch) and the Functional extension (on github) both creating namespaces within the extension, I think there is a requirement for a mechanism to allow an extension to record the namespace(s) that it has, in a similar fashion to how functions and classes are known to core. There's no such thing as registered namespaces, at least in the engine. Namespace is just a part of class/function name. You could enumerate classes/functions and split their names, but I'm not sure for what such list will be useful. Could you explain? But, trawling all the classes and functions, extracting and aggregating the namespace would really not seem to be the way to go. And that wouldn't take into account the user defined namespaces. Again, there's no such thing as list of user defined namespaces, at runtime. You'd have to go through all classes/functions and split their names. Again, I'm not sure what would be the use of it. Currently, I can find the names of functions, classes and interfaces - be they from an extension or userland code. But I can't get namespaces, or their aliases. I'm not totally sure of any other use. That's why I was asking. As (or if) more extensions start to use namespaces to protect their contents from name collision, we are probably going to have namespace collision before long. -- Richard Quadling Twitter : EE : Zend : PHPDoc @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Getting a list of registered namespaces.
On 16 June 2011 14:03, Martin Scotta martinsco...@gmail.com wrote: Martin Scotta On Thu, Jun 16, 2011 at 9:40 AM, Richard Quadling rquadl...@gmail.com wrote: On 15 June 2011 17:23, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! With pecl/http (DEV-2 branch) and the Functional extension (on github) both creating namespaces within the extension, I think there is a requirement for a mechanism to allow an extension to record the namespace(s) that it has, in a similar fashion to how functions and classes are known to core. There's no such thing as registered namespaces, at least in the engine. Namespace is just a part of class/function name. You could enumerate classes/functions and split their names, but I'm not sure for what such list will be useful. Could you explain? But, trawling all the classes and functions, extracting and aggregating the namespace would really not seem to be the way to go. And that wouldn't take into account the user defined namespaces. Again, there's no such thing as list of user defined namespaces, at runtime. You'd have to go through all classes/functions and split their names. Again, I'm not sure what would be the use of it. Currently, I can find the names of functions, classes and interfaces - be they from an extension or userland code. But I can't get namespaces, or their aliases. I'm not totally sure of any other use. That's why I was asking. As (or if) more extensions start to use namespaces to protect their contents from name collision, we are probably going to have namespace collision before long. that's why naming convention are meant for? Maybe, but because of a lack of convention on naming, we have namespaces. It people named their classes/functions/etc with sensible long names, containing something that was unique to their project, after doing plenty of research for similar sounding names, we wouldn't need namespaces. When/if github/functional and/or pecl/http-DEV2 go live, these will be the first 2 namespaces provided by PHP extensions (that could be in general use). Are you all saying that the potential for a naming-collision is negligible? It seems so. As I see it, a namespace is a container. Like a class acts as a container for methods and properties, so a namespaces acts as a container for classes, interfaces and functions, ring-fencing them to avoid name collisions. So it would seem appropriate to have the ability to investigate a namespace to see what it contains and/or if it exists. Why? For exactly the same reasons you have class_exists(), interface_exists(), function_exists(). -- Richard Quadling Twitter : EE : Zend : PHPDoc @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Give the Language a Rest motion (fwd)
-Original Message- From: Pascal COURTOIS [mailto:pascal.court...@nouvo.com] Sent: Thursday, June 16, 2011 12:28 AM To: Lester Caine Cc: PHP internals Subject: Re: [PHP-DEV] Give the Language a Rest motion (fwd) Le 16/06/2011 09:19, Lester Caine a écrit : when you have a bug in PHP it should not ever ever crash PHP and unfortunately I encountered that case dozens of times. At least on Linux is just recovers and carries on If PHP crashes, yes, it recovers but it's VERY resource and time consumming. If PHP corrupts some memory, it does not crash fastcgi processes but the next request(s) behave erratically. I have some news for you. Ruby has crashes, Python has crashes, even Java has security issues and crashes (check out the Java bug database. It's bigger than ours). Of course our goal is to reduce this as much as possible for PHP and as was stated here, short concise reproducible scripts do get attention. Re: memory models, PHP actually has a memory model that is very robust and prevents leaks from happening. Every memory model has its pros and cons but leak-free Java is a great example of where the memory model more often than not bites you in your tush more than you'd think (and I can say that after having done quite a bit of Websphere development - yuck). So just help us with identifying root cause and you will see the internals@ group very much jumping on the issues and try to resolve them. Andi
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
Hi! I'm not saying there aren't any. There are known leaks in compile_file() when you throw an exception like that, so if you call a huge amount of these within a single request, you are going to have problems. But that You actually can't call huge amount of these in one request, as this particular leak is caused by bailing out from zend_execute_scripts, which causes main op array not be freed. zend_execute_scripts() is called only once, so you can't have this leak multiple times as far as I can see. Whatever caused the original problem, it's highly unlikely it is this leak. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Getting a list of registered namespaces.
Hi! On 6/16/11 8:37 AM, Richard Quadling wrote: Maybe, but because of a lack of convention on naming, we have namespaces. No, we have namespaces not because we couldn't agree on naming convention, but because any naming convention without namespaces would lead to ugly code (which you call sensible long names but which rapidly stop being sensible if you actually try to do it). So it would seem appropriate to have the ability to investigate a namespace to see what it contains and/or if it exists. Why? For exactly the same reasons you have class_exists(), interface_exists(), function_exists(). Classes and functions actually exist as objects in the engine. Namespaces do not. They are just parts of names. You can not instantiate a namespace, you can not call a namespace. So these reasons do not apply. -- 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] Getting a list of registered namespaces.
Hi! Currently, I can find the names of functions, classes and interfaces - be they from an extension or userland code. But I can't get namespaces, or their aliases. Names of functions and classes _are_ namespaces. As for aliases, these are purely compile-time concepts, so there's nothing to get in runtime. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
Le 16/06/2011 18:11, Andi Gutmans a écrit : I have some news for you. Ruby has crashes, Python has crashes, Probably. any references about that ? even Java has security issues and crashes (check out the Java bug database. It's bigger than ours). IMHO java is a big s**t but that's really out of topic -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
On 06/16/2011 05:32 PM, Stas Malyshev wrote: Hi! I'm not saying there aren't any. There are known leaks in compile_file() when you throw an exception like that, so if you call a huge amount of these within a single request, you are going to have problems. But that You actually can't call huge amount of these in one request, as this particular leak is caused by bailing out from zend_execute_scripts, which causes main op array not be freed. zend_execute_scripts() is called only once, so you can't have this leak multiple times as far as I can see. Whatever caused the original problem, it's highly unlikely it is this leak. I was thinking it was a bunch of nested eval()'s that might cause this. An exit from within an eval'ed op_array would cause this same leak I think. But yes, I agree, in order to leak 128M or whatever it was he said, it is unlikely that it is due to this. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Getting a list of registered namespaces.
On 16 June 2011 17:40, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! On 6/16/11 8:37 AM, Richard Quadling wrote: Maybe, but because of a lack of convention on naming, we have namespaces. No, we have namespaces not because we couldn't agree on naming convention, but because any naming convention without namespaces would lead to ugly code (which you call sensible long names but which rapidly stop being sensible if you actually try to do it). I was joking. So it would seem appropriate to have the ability to investigate a namespace to see what it contains and/or if it exists. Why? For exactly the same reasons you have class_exists(), interface_exists(), function_exists(). Classes and functions actually exist as objects in the engine. Namespaces do not. They are just parts of names. You can not instantiate a namespace, you can not call a namespace. So these reasons do not apply. And now I understand. Thanks for that. -- Richard Quadling Twitter : EE : Zend : PHPDoc @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Getting a list of registered namespaces.
On Thu, Jun 16, 2011 at 7:48 PM, Richard Quadling rquadl...@gmail.comwrote: On 16 June 2011 17:40, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! On 6/16/11 8:37 AM, Richard Quadling wrote: Maybe, but because of a lack of convention on naming, we have namespaces. No, we have namespaces not because we couldn't agree on naming convention, but because any naming convention without namespaces would lead to ugly code (which you call sensible long names but which rapidly stop being sensible if you actually try to do it). I was joking. So it would seem appropriate to have the ability to investigate a namespace to see what it contains and/or if it exists. Why? For exactly the same reasons you have class_exists(), interface_exists(), function_exists(). Classes and functions actually exist as objects in the engine. Namespaces do not. They are just parts of names. You can not instantiate a namespace, you can not call a namespace. So these reasons do not apply. And now I understand. Thanks for that. Okay, so namespaces doesn't exists for the engine, because they are added to the classnames in compile-time, but we could add some --rX argument for the php binary, which would iterate over the classes and functions and so for a given extension, and fetch and list the introduced namespaces. what do you think? Tyrael
Re: [PHP-DEV] Getting a list of registered namespaces.
On Thu, 2011-06-16 at 19:54 +0200, Ferenc Kovacs wrote:
Okay, so namespaces doesn't exists for the engine, because they are added to
the classnames in compile-time, but we could add some --rX argument for the
php binary, which would iterate over the classes and functions and so for a
given extension, and fetch and list the introduced namespaces.
what do you think?
The --rX things are reflection shortcuts, while we have one exception
(--ri) I actually don't want to pollute the options list. I don't see
the need for this. I don't really know when I need to know this
information. What is the worth?
For the one time this is needed one can use a trivial (g)awk command or
such ..
$ php --re http | awk '/Class \[.+ class .+\\/ { print gensub(/(.*)\\[^\\]+/,
\\1, 1, $5); }'
should be simple to extend for functions, too. For some maybe more
readable as PHP script. But I still don't get when I'd need that
information.
johannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Getting a list of registered namespaces.
Hi! Okay, so namespaces doesn't exists for the engine, because they are added to the classnames in compile-time, but we could add some --rX argument for the php binary, which would iterate over the classes and functions and so for a given extension, and fetch and list the introduced namespaces. what do you think? Well, we could - you could actually do it right now with list of classes and some simple regexp-ing. The question is a value of it. -- 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] Getting a list of registered namespaces.
Am 16.06.2011 20:12, schrieb Stas Malyshev: Well, we could - you could actually do it right now with list of classes and some simple regexp-ing. The question is a value of it. I think get_declared_classes works as well, if you create a script that loads all your classes you could then extract all namespaces...(btw. I love the way the autoloader plays in concert with the /-Separator, thanks for that;) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP 5.3.7RC1 Released for Testing
The first release candidates of 5.3.7 was just released for testing and can be downloaded here: http://downloads.php.net/johannes/php-5.3.7RC1.tar.bz2 (md5sum: 295a457505049cc75d723560715be5d6) http://downloads.php.net/johannes/php-5.3.7RC1.tar.gz (md5sum: 4fd555292ea0a1bc3acd1d3ad4c98c27) The Windows binaries are available at: http://windows.php.net/qa/ This is the first step in the release process of this versions and the goal is to have an additional RC within two weeks. PHP 5.3.7 is focused on improving the stability and security. To ensure that the release is solid, please test this RC against your code base and report any problems that you encounter. To find out what was changed since the last release please refer to the NEWS file found within the archive or on http://svn.php.net/viewvc/php/php-src/tags/php_5_3_4RC1/NEWS?revision=HEADview=markup PLEASE NOTE: The PHP Bug tracker is currently not available. In case you find a critical issue don't hesitate to send me a note. If the issue can't wait till bugs.php.net is operational again you can also inform mailto:internals@lists.php.net. In case your report is security related please contact mailto:secur...@php.net. Windows users please mind that we don't provide VS6 builds anymore since PHP 5.3.6. When using the openssl extension please mind a known regression which might lead to a performance degression. This regression will be fixed with RC2 and the final release. Johannes Schlüter PHP 5.3 Release Master -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.3.7RC1 Released for Testing
Hello ! Le 16 juin 2011 à 23:42, Johannes Schlüter a écrit : To find out what was changed since the last release please refer to the NEWS file found within the archive or on http://svn.php.net/viewvc/php/php-src/tags/php_5_3_4RC1/NEWS?revision=HEADview=markup Valid NEWS file for 5.3.7RC1 is http://svn.php.net/viewvc/php/php-src/tags/php_5_3_7RC1/NEWS?revision=HEADview=markup. The previous link is about 5.3.4RC1. Best regards, Fred. -- Frédéric Hardy : Architecte d'application/Admin. système/Ergonome CV : http://blog.mageekbox.net/public/cv.frederic.hardy.pdf Blog : http://blog.mageekbox.net Twitter : http://twitter.com/mageekguy -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.3.7RC1 Released for Testing
On Thu, 2011-06-16 at 23:42 +0200, Johannes Schlüter wrote: To find out what was changed since the last release please refer to the NEWS file found within the archive or on http://svn.php.net/viewvc/php/php-src/tags/php_5_3_4RC1/NEWS?revision=HEADview=markup This should - obviously - have been http://svn.php.net/viewvc/php/php-src/tags/php_5_3_7RC1/NEWS?revision=HEADview=markup johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [RFC] 5.4 features for vote (long)
Hi!
Below is the list of the features proposed for inclusion in 5.4, as
outlined in https://wiki.php.net/todo/php54. Please read the TODO page
and the RFCs linked there for details.
This mail is not a vote call but rather description of things that will
be put to vote soon. For each one, I'd like to see that:
a. It is clear to everybody what is being proposed. If you have any
doubts or see that it needs further discussion, please tell.
b. We didn't miss something. If you have a proposal that has RFC in good
shape, patch (or can have patch within 1 month from now) and you think
has to be in 5.4 and has good chance for community support, please tell.
c. For proposals that have assigned developers, I'd like for them to
ensure they still want these proposals in and commit to doing the work
in time for 5.4 beta (~end of July). It's no point to vote on a feature
if the developer responsible for it won't have time or desire to
implement it.
If the proposal doesn't have anybody assigned, that means I can do it if
needed - though of course I'd be glad if somebody else would do it too.
So here goes the big list:
1. Declare PHP/php reserved namespace name, not to be used in any user
code. Does not require any code change, only documentation changes.
2. Make primitive type names reserved words (in case we ever want some
form of scalar typing or anything else with scalar types). Using them as
identifiers would return parse error for now. May have BC implications.
3. Add E_STRICT to E_ALL. Nuff said. We did it in 6.0/unicode branch but
didn't backport it.
4. Drop magic quotes. We've deprecated them in 5.3, we can kill them in
5.4. See the RFC for fine details.
5. Binary notation for ints (0b10101). Same as 0x, but in binary. Python
has it, we could too :)
6. Array shortcuts. Make [ 'blah', 'blah' ] work same as array('blah',
'blah'), etc. Does not include any new JSON-like syntax, etc. - just
making '[' be 'array(' and ']' be ')' in that context.
7. Disable POST data processing INI option.
Assigned: Gustavo Lopes
8. Cli web server. Built-in mini-HTTP server run directly from PHP binary.
Assigned: Moriyoshi Koizumi
9. Session Handlers class. A class that implements current session
handler and can be extended with user code, fully or partially.
Assigned: Arpad Ray
10. Callback type check in arguments. Type check in method calls same as
'array' or 'MyClass' type checks but would match valid callbacks.
Assigned: Hannes Magnusson
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] date_diff broken?
Hi!
I've been looking into various tests and discovered something strange in
date_diff. Example code:
?php
$start = new DateTime('2010-10-04 02:18:48 EDT');
$end = new DateTime('2010-11-06 18:38:28 EDT');
$int = $start-diff($end);
var_dump($start);
As a result of this I'm getting this:
object(DateTime)#1 (3) {
[date]=
string(19) 2010-10-04 06:18:48
[timezone_type]=
int(2)
[timezone]=
string(3) EDT
}
As you can see, the date in $start changed, even though it shouldn't
happen. Looks like it's because of timelib_diff() which has this:
timelib_apply_localtime(one, 0);
timelib_apply_localtime(two, 0);
which converts times in diff arguments to localtime. It then does:
timelib_apply_localtime(one, 1);
timelib_apply_localtime(two, 1);
which is supposed to convert them back, but in fact it does not, since
first conversion seems to have killed TZ information. I'd propose to fix
it by making time_diff operate on copies of one and two instead of real
structures, but maybe somebody has a better idea?
--
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
