[PHP-DEV] Error/Exception handlers chaining (Was: [PHP-DEV] Include XDebug and Suhosin Patch in Core for 5.5)
2013/2/28 Derick Rethans der...@php.net: On Thu, 28 Feb 2013, Anthony Ferrara wrote: It appears that xdebug is borking generator exception handling. Without xdebug the following two tests pass, but with it they fail: Generator::throw() where the exception is caught in the generator [Zend/tests/generators/throw_caught.phpt] Generator::throw() where the generator throws a different exception [Zend/tests/generators/throw_rethrow.phpt] I guess that's because something hijacks the throw exception handler, it's the samething with SOAP. This should be addressed so that there is a chain/set of handlers instead. I'm all for it since I have the same problem with APM as well. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Include XDebug and Suhosin Patch in Core for 5.5
On 01/03/2013, at 7:00 AM, Anthony Ferrara ircmax...@gmail.com wrote: Hey all, Based off of the recent discussion around pulling in ZO+ into core, I've come to the conclusion that we should also pull in XDebug and Suhosin into core at the same time. 1. It has integration issues with ZO+ in that it has to be included in a specific order (specifically around ini declarations). If it was included into core, this could be accounted for allowing for more robust behavior. 2. Both to be maintained for each new language feature as well as opcode-caches. This will have the same benefit as integrating ZO+, as it can be maintained inline with the engine. 3. Both stand as a barrier to adoption as many will not run PHP in development without XDebug, and they won't run it in production without the Suhosin patch. Since both of these are vital to PHP's uptake and adoption of new versions, I feel it's important to delay 5.5 until we can get both in. I can draft up the RFC if necessary... Anthony Nice :-P Seriously though, what's the deal with the Suhosin patch? I use it because it's included by default on Ubuntu... Didn't know about the huge performance impact. Their website seems to imply that PHP has security holes that have never been patched, and are only closed by using Suhosin. I find that hard to believe. Is PHP really *that* vulnerable without it? The site (http://www.hardened-php.net/suhosin/) is somewhat light on details. Cheers, David
Re: [PHP-DEV] Include XDebug and Suhosin Patch in Core for 5.5
On Fri, Mar 1, 2013 at 11:39 AM, David Muir davidkm...@gmail.com wrote: On 01/03/2013, at 7:00 AM, Anthony Ferrara ircmax...@gmail.com wrote: Hey all, Based off of the recent discussion around pulling in ZO+ into core, I've come to the conclusion that we should also pull in XDebug and Suhosin into core at the same time. 1. It has integration issues with ZO+ in that it has to be included in a specific order (specifically around ini declarations). If it was included into core, this could be accounted for allowing for more robust behavior. 2. Both to be maintained for each new language feature as well as opcode-caches. This will have the same benefit as integrating ZO+, as it can be maintained inline with the engine. 3. Both stand as a barrier to adoption as many will not run PHP in development without XDebug, and they won't run it in production without the Suhosin patch. Since both of these are vital to PHP's uptake and adoption of new versions, I feel it's important to delay 5.5 until we can get both in. I can draft up the RFC if necessary... Anthony Nice :-P Seriously though, what's the deal with the Suhosin patch? I use it because it's included by default on Ubuntu... Didn't know about the huge performance impact. Their website seems to imply that PHP has security holes that have never been patched, and are only closed by using Suhosin. I find that hard to believe. Is PHP really *that* vulnerable without it? The site (http://www.hardened-php.net/suhosin/) is somewhat light on details. Any computer system is vulnerable as far as you press the start button and plug in the network cable ;-) Julien
Re: [PHP-DEV] Include XDebug and Suhosin Patch in Core for 5.5
On Thu, Feb 28, 2013 at 9:13 PM, Stas Malyshev smalys...@sugarcrm.comwrote: Hi! Based off of the recent discussion around pulling in ZO+ into core, I've come to the conclusion that we should also pull in XDebug and Suhosin into core at the same time. Suhosin has multiple BC-incompatible and performance-problematic changes and limits and the author refused many times to work with PHP team. I'm not sure how we could pull extension that the author of it isn't interested in working with PHP group. +1 1. It has integration issues with ZO+ in that it has to be included in a specific order (specifically around ini declarations). If it was included into core, this could be accounted for allowing for more robust behavior. I'm not sure what you mean about ini declarations, could you expand on this or refer me to the place where it is explained? I guess the ini declaration order and then the order the modules get loaded in the engine. Julien
Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution
On 02/28/2013 02:34 PM, Anthony Ferrara wrote: example, XDebug has no compatibility with ZendOptimizer+ right now (at least that I could find, feel free to correct me if I'm wrong here). I tested PHPUnit with both Xdebug and ZO+ enabled and got a correct code coverage report. So at least that part of Xdebug is compatible with ZO+. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I would like to write an RFC for the addition of an internal keyword
On Thu, Feb 28, 2013 at 12:40 PM, Lazare Inepologlou linep...@gmail.comwrote: Hello, please read my comment inline... 2013/2/28 Sebastian Krebs krebs@gmail.com 2013/2/28 Jens Riisom Schultz ibmu...@me.com Hi everyone, (I got hooked off this discussion, so I have tried to keep up by reading the digest... This makes it impossible for me to correctly interleave my comments, so I'll just top post or whatever the term is) (I'm sure this has been mentioned before but a forum would be so much more accesible than this mailing list concept...) * In response to the argument that you want to be able to modify a framework or use it in an unintended manner: This would be possible by explicitly stating namespace Framework; in a given php file. * In response to the argument that php has no assembly concept: I know this, but namespaces are as close as we get, and would effectively solve this. No. A namespace is in fact more or less just a prefix, that groups the containing elements together. Beside the semantic meaning of grouping they don't have any further abilities, or meaning. Without knowing exact details I guess, that internal in C# is primary a technical thing, that allows a compiler further optimizations, because he definitely knows, that the function/method is only used within the assembly and is not required to do anything to expose it to the outside? Regardless of the technical details, it is still a fine way of applying encaptulation so you can't say that it is only a technical thing. * In response to the argument that php already has accessibility restrictions with private and protected: This is true, but it does not solve all problems. Often you need classes to interoperate in a way that can only be facilitated by making functionality public. Also, there is no way to make a private or protected class (since php has no assembly concept), though what I propose would likely birth the concept of private and protected classes as well. Maybe it's just me, but no: I've never had the need of what you describe and where a public method wasn't apropriate anway... At least for a very long time :D * In response to the argument that PHP does not restrict anyone from adding to a namespace: That is true, but say you were using Doctrine2. Would you ever make a php file with namespace Doctrine2; in it, unless you wanted to modify Doctrine2, and hence you knew what you were doing, or accepted the risks? Well, yes. But extending/overriding a components method _always_ requires, that you know what you do, so why enforcing/encouraging hacks, instead of the good old protected? Protected is used for extending classes. There is no mechanism to inherit and extend a namespace so protected is irrelevant here. * In response to the concept of solving this through documentation: First off, this is not possible with the current phpdoc and phpdoc2 standards. Second off, problems like these should not be solved by documentation, imho, or of course I would not propose this. The C# designers seem to agree with me. And the Java designers, too (though they have no internal keyword they do have a way of hiding framework specific classes). Actually Java has a concept that is identical to your proposal. The default access modifier (when no access modifier is written) is the package modifier (=accessible from within the same package). Ha, it's been years since I'm asking for such a feature to come to PHP. I would love to see a package visibility in PHP, restricting access to 'package'ed members (methods or attributes) to an object born from a class of the same namespace. Would really help some cases in frameworks or so :-) Just my2cents Julien
Re: [PHP-DEV] Include XDebug and Suhosin Patch in Core for 5.5
Hi 2013/3/1 Julien Pauli jpa...@php.net: I guess the ini declaration order and then the order the modules get loaded in the engine. We could also look at implementing a module-load-order internally in the zend_module struct, as in some extensions like EXIF relies on mbstring, while the ZEND_MODULE_DEP()s works fine for checking for mbstring, it does not work if mbstring is loaded after. So what I'm saying is that mbstring have a higher load order, meaning even though we have this in php.ini[1], PHP will load mbstring first because it has the lowest value (requiring it to start first), or giving exif a higher than 'normal' value (causing it to load after, as it is after all, exif that depends on mbstring, not the other way around). The same thing can be done with engine level extensions (zend_extension), where it probably would make more sense than for 90% of all 'php' extensions. [1]: extension=php_exif.dll extension=php_mbstring.dll -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Include XDebug and Suhosin Patch in Core for 5.5
On Fri, Mar 1, 2013 at 12:49 PM, Kalle Sommer Nielsen ka...@php.net wrote: Hi 2013/3/1 Julien Pauli jpa...@php.net: I guess the ini declaration order and then the order the modules get loaded in the engine. We could also look at implementing a module-load-order internally in the zend_module struct, as in some extensions like EXIF relies on mbstring, while the ZEND_MODULE_DEP()s works fine for checking for mbstring, it does not work if mbstring is loaded after. So what I'm saying is that mbstring have a higher load order, meaning even though we have this in php.ini[1], PHP will load mbstring first because it has the lowest value (requiring it to start first), or giving exif a higher than 'normal' value (causing it to load after, as it is after all, exif that depends on mbstring, not the other way around). The same thing can be done with engine level extensions (zend_extension), where it probably would make more sense than for 90% of all 'php' extensions. [1]: extension=php_exif.dll extension=php_mbstring.dll +1 , Some time ago when I first designed my first extensions studying the Zend extension loading mechanism I thought about such a system and was surprised not to find one into the engine. It shouldn't be too hard to develop, except if you start thinking about versions dependencies of the modules as well. In the same pipe, I was thinking at some dlunload() function which would enable unoloading modules at runtime, but that's another task, not very trivial though. Julien -- regards, Kalle Sommer Nielsen ka...@php.net
Re: [PHP-DEV] Include XDebug and Suhosin Patch in Core for 5.5
I agree with adding XDebug to core distribution but it must be disabled by default. On Fri, Mar 1, 2013 at 8:28 AM, Julien Pauli jpa...@php.net wrote: On Fri, Mar 1, 2013 at 12:49 PM, Kalle Sommer Nielsen ka...@php.net wrote: Hi 2013/3/1 Julien Pauli jpa...@php.net: I guess the ini declaration order and then the order the modules get loaded in the engine. We could also look at implementing a module-load-order internally in the zend_module struct, as in some extensions like EXIF relies on mbstring, while the ZEND_MODULE_DEP()s works fine for checking for mbstring, it does not work if mbstring is loaded after. So what I'm saying is that mbstring have a higher load order, meaning even though we have this in php.ini[1], PHP will load mbstring first because it has the lowest value (requiring it to start first), or giving exif a higher than 'normal' value (causing it to load after, as it is after all, exif that depends on mbstring, not the other way around). The same thing can be done with engine level extensions (zend_extension), where it probably would make more sense than for 90% of all 'php' extensions. [1]: extension=php_exif.dll extension=php_mbstring.dll +1 , Some time ago when I first designed my first extensions studying the Zend extension loading mechanism I thought about such a system and was surprised not to find one into the engine. It shouldn't be too hard to develop, except if you start thinking about versions dependencies of the modules as well. In the same pipe, I was thinking at some dlunload() function which would enable unoloading modules at runtime, but that's another task, not very trivial though. Julien -- regards, Kalle Sommer Nielsen ka...@php.net
[PHP-DEV] Re: [PHP-WEBMASTER] Re: [PHP Wiki] new user: fabpot
On Thu, Feb 28, 2013 at 11:10 PM, Fabien Potencier fabien.potenc...@gmail.com wrote: On 2/28/13 10:32 AM, Peter Cowburn wrote: cc Fabien On 28 February 2013 09:25, Hannes Magnusson hannes.magnus...@gmail.com wrote: Simply registering for an wiki account doesn't give you any karma to edit anything... Are you planning on modifying or creating content on the wiki, and if so - which namespace? I just wanted to vote on some RFCs (as the project leader for Symfony). I truly don't know how that works. Never understood who are allowed to vote. Can someone on internals@ please explain that part to me so I can give Fabien karma (or not)? -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-WEBMASTER] Re: [PHP Wiki] new user: fabpot
On Fri, Mar 1, 2013 at 8:03 PM, Hannes Magnusson hannes.magnus...@gmail.com wrote: On Thu, Feb 28, 2013 at 11:10 PM, Fabien Potencier fabien.potenc...@gmail.com wrote: On 2/28/13 10:32 AM, Peter Cowburn wrote: cc Fabien On 28 February 2013 09:25, Hannes Magnusson hannes.magnus...@gmail.com wrote: Simply registering for an wiki account doesn't give you any karma to edit anything... Are you planning on modifying or creating content on the wiki, and if so - which namespace? I just wanted to vote on some RFCs (as the project leader for Symfony). I truly don't know how that works. Never understood who are allowed to vote. Can someone on internals@ please explain that part to me so I can give Fabien karma (or not)? Fabien wants to write a RFC. Anyone can do, simply give him the 'RFC' karma, done now. Cheers, -- Pierre @pierrejoye -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-WEBMASTER] Re: [PHP Wiki] new user: fabpot
On Fri, 1 Mar 2013, Pierre Joye wrote: On Fri, Mar 1, 2013 at 8:03 PM, Hannes Magnusson hannes.magnus...@gmail.com wrote: On Thu, Feb 28, 2013 at 11:10 PM, Fabien Potencier fabien.potenc...@gmail.com wrote: I just wanted to vote on some RFCs (as the project leader for Symfony). I truly don't know how that works. Never understood who are allowed to vote. Can someone on internals@ please explain that part to me so I can give Fabien karma (or not)? Fabien wants to write a RFC. Anyone can do, simply give him the 'RFC' karma, done now. He wanted to *vote*, not to write an RFC. cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I would like to write an RFC for the addition of an internal keyword
My thoughts are that no additional keyword is necessary - allow protected
and private to be used in this scopes. A protected element of a namespace
can be accessed within that namespace or any sub-namespaces, and a private
element would only be visible by code in the same namespace. Hence
namespace A {
protected class Bar(){}
}
namespace B {
new \A\Bar(); // fails, protected.
}
namespace A\C {
new \A\Bar(); // works, C is A's child.
private class Foo();
}
namespace A\C\D {
new \A\C\Foo(); // fails, private and only reachable from \A\C
}
This accomplishes the same as the proposed keyword, and then some, and
doesn't introduce the BC break of a new keyword.
On Fri, Mar 1, 2013 at 6:11 AM, Julien Pauli jpa...@php.net wrote:
On Thu, Feb 28, 2013 at 12:40 PM, Lazare Inepologlou linep...@gmail.com
wrote:
Hello,
please read my comment inline...
2013/2/28 Sebastian Krebs krebs@gmail.com
2013/2/28 Jens Riisom Schultz ibmu...@me.com
Hi everyone,
(I got hooked off this discussion, so I have tried to keep up by
reading
the digest... This makes it impossible for me to correctly interleave
my
comments, so I'll just top post or whatever the term is) (I'm sure
this
has been mentioned before but a forum would be so much more accesible
than
this mailing list concept...)
* In response to the argument that you want to be able to modify a
framework or use it in an unintended manner:
This would be possible by explicitly stating namespace Framework;
in
a
given php file.
* In response to the argument that php has no assembly concept:
I know this, but namespaces are as close as we get, and would
effectively
solve this.
No. A namespace is in fact more or less just a prefix, that groups the
containing elements together. Beside the semantic meaning of grouping
they
don't have any further abilities, or meaning.
Without knowing exact details I guess, that internal in C# is
primary a
technical thing, that allows a compiler further optimizations, because
he
definitely knows, that the function/method is only used within the
assembly
and is not required to do anything to expose it to the outside?
Regardless of the technical details, it is still a fine way of applying
encaptulation so you can't say that it is only a technical thing.
* In response to the argument that php already has accessibility
restrictions with private and protected:
This is true, but it does not solve all problems. Often you need
classes
to interoperate in a way that can only be facilitated by making
functionality public. Also, there is no way to make a private or
protected
class (since php has no assembly concept), though what I propose
would
likely birth the concept of private and protected classes as well.
Maybe it's just me, but no: I've never had the need of what you
describe
and where a public method wasn't apropriate anway... At least for a
very
long time :D
* In response to the argument that PHP does not restrict anyone from
adding to a namespace:
That is true, but say you were using Doctrine2. Would you ever make a
php
file with namespace Doctrine2; in it, unless you wanted to modify
Doctrine2, and hence you knew what you were doing, or accepted the
risks?
Well, yes. But extending/overriding a components method _always_
requires,
that you know what you do, so why enforcing/encouraging hacks, instead
of
the good old protected?
Protected is used for extending classes. There is no mechanism to
inherit
and extend a namespace so protected is irrelevant here.
* In response to the concept of solving this through documentation:
First off, this is not possible with the current phpdoc and phpdoc2
standards. Second off, problems like these should not be solved by
documentation, imho, or of course I would not propose this. The C#
designers seem to agree with me. And the Java designers, too (though
they
have no internal keyword they do have a way of hiding framework
specific
classes).
Actually Java has a concept that is identical to your proposal. The
default
access modifier (when no access modifier is written) is the package
modifier (=accessible from within the same package).
Ha, it's been years since I'm asking for such a feature to come to PHP.
I would love to see a package visibility in PHP, restricting access to
'package'ed members (methods or attributes) to an object born from a class
of the same namespace.
Would really help some cases in frameworks or so :-)
Just my2cents
Julien
[PHP-DEV] Re: [PHP-WEBMASTER] Re: [PHP Wiki] new user: fabpot
On Fri, Mar 1, 2013 at 11:20 AM, Pierre Joye pierre@gmail.com wrote: On Fri, Mar 1, 2013 at 8:03 PM, Hannes Magnusson hannes.magnus...@gmail.com wrote: On Thu, Feb 28, 2013 at 11:10 PM, Fabien Potencier fabien.potenc...@gmail.com wrote: On 2/28/13 10:32 AM, Peter Cowburn wrote: cc Fabien On 28 February 2013 09:25, Hannes Magnusson hannes.magnus...@gmail.com wrote: Simply registering for an wiki account doesn't give you any karma to edit anything... Are you planning on modifying or creating content on the wiki, and if so - which namespace? I just wanted to vote on some RFCs (as the project leader for Symfony). I truly don't know how that works. Never understood who are allowed to vote. Can someone on internals@ please explain that part to me so I can give Fabien karma (or not)? Fabien wants to write a RFC. Anyone can do, simply give him the 'RFC' karma, done now. I am well aware of that as I am the onlyone who is monitoring user requests to update the wiki. However when a request comes in, like this one, about the ability to *vote* I am lost. I don't understand those voting rules and therefore am asking for clarification, again. If anyone understand them, please let me know. The previous guys asking for vote karma are still in the queue as I never got any response on the rules. -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-WEBMASTER] Re: [PHP Wiki] new user: fabpot
On Fri, Mar 1, 2013 at 8:44 PM, Hannes Magnusson hannes.magnus...@gmail.com wrote: I am well aware of that as I am the onlyone who is monitoring user requests to update the wiki. However when a request comes in, like this one, about the ability to *vote* I am lost. Project lead can vote yes. Also in the case of Fabien it is even more easy, he provided so many tests (directly or via his teams), he is a contributor per se. I don't understand those voting rules and therefore am asking for clarification, again. php.net contributors, project leaders (verified, not random ppl). And sorry to have misread Fabien's post. @Fabien, can you try to vote please? I don't remember if RFC is enough or if more is needed. Ideally simply request a php.net account, easier. Cheers, -- Pierre @pierrejoye -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-WEBMASTER] Re: [PHP Wiki] new user: fabpot
On Fri, Mar 1, 2013 at 11:56 AM, Pierre Joye pierre@gmail.com wrote: On Fri, Mar 1, 2013 at 8:44 PM, Hannes Magnusson hannes.magnus...@gmail.com wrote: I am well aware of that as I am the onlyone who is monitoring user requests to update the wiki. However when a request comes in, like this one, about the ability to *vote* I am lost. Project lead can vote yes. Also in the case of Fabien it is even more easy, he provided so many tests (directly or via his teams), he is a contributor per se. I don't understand those voting rules and therefore am asking for clarification, again. php.net contributors, project leaders (verified, not random ppl). How do I verify it, and which projects are applicable? Does it depend on how many contributors it has? Users? How long it has been around? Commercial? OSS? Library? Framework? Applications? Websites? -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-WEBMASTER] Re: [PHP Wiki] new user: fabpot
On Mar 1, 2013 9:00 PM, Hannes Magnusson hannes.magnus...@gmail.com wrote: On Fri, Mar 1, 2013 at 11:56 AM, Pierre Joye pierre@gmail.com wrote: On Fri, Mar 1, 2013 at 8:44 PM, Hannes Magnusson hannes.magnus...@gmail.com wrote: I am well aware of that as I am the onlyone who is monitoring user requests to update the wiki. However when a request comes in, like this one, about the ability to *vote* I am lost. Project lead can vote yes. Also in the case of Fabien it is even more easy, he provided so many tests (directly or via his teams), he is a contributor per se. I don't understand those voting rules and therefore am asking for clarification, again. php.net contributors, project leaders (verified, not random ppl). How do I verify it, and which projects are applicable? Does it depend on how many contributors it has? Users? How long it has been around? Commercial? OSS? Library? Framework? Applications? Websites? Common sense, in case of Fabien there is no doubt. Other like Benjamin (doctrine) neither. In doubt ask. Cheers,
[PHP-DEV] Re: [PHP-WEBMASTER] Re: [PHP Wiki] new user: fabpot
On Fri, 1 Mar 2013, Hannes Magnusson wrote: On Fri, Mar 1, 2013 at 11:56 AM, Pierre Joye pierre@gmail.com wrote: On Fri, Mar 1, 2013 at 8:44 PM, Hannes Magnusson hannes.magnus...@gmail.com wrote: I am well aware of that as I am the onlyone who is monitoring user requests to update the wiki. However when a request comes in, like this one, about the ability to *vote* I am lost. Project lead can vote yes. Also in the case of Fabien it is even more easy, he provided so many tests (directly or via his teams), he is a contributor per se. I don't understand those voting rules and therefore am asking for clarification, again. php.net contributors, project leaders (verified, not random ppl). How do I verify it, and which projects are applicable? Does it depend on how many contributors it has? Users? How long it has been around? Commercial? OSS? Library? Framework? Applications? Websites? Exactly, this random apply rules nonsense needs to stop. I have nothing against Fabien voting but there is nowhere written who can vote or not (no, the voting RFC is too vague as well). I for one, would like to see a much stricter list of people who can vote. cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-WEBMASTER] Re: [PHP Wiki] new user: fabpot
How do I verify it, and which projects are applicable? Does it depend on how many contributors it has? Users? How long it has been around? Commercial? OSS? Library? Framework? Applications? Websites? I've long had the same question. Not that I think I've earned such honor, believe me, but if you have a running commercial concern (i.e. web app) yet have never open-sourced your application code, can you ever be considered to have a project? Are there set boundaries for this? Thinking of Facebook, HipHop was obviously a huge donation on the OSS side, but what if Sara (and whoever else) weren't there? Does Facebook itself as an 800-pound PHP-based gorilla qualify as a project even if if it never open-sourced anything? Or would the worldwide PHP-based brand be like 99% of the way there, but they'd still need a non-frivolous OSS project? On the flip, several small-adoption, high-quality, stable OSS frameworks are out there that I think show great loyalty to PHP as a language (Konstrukt is one). But when do they become projects as such? Seriously curious. Having a karma-certified project might be an exciting carrot for people. -- S. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-WEBMASTER] Re: [PHP Wiki] new user: fabpot
Derick Rethans der...@php.net wrote: Exactly, this random apply rules nonsense needs to stop. I have nothing against Fabien voting but there is nowhere written who can vote or not (no, the voting RFC is too vague as well). I for one, would like to see a much stricter list of people who can vote. I often wonder about many names on the list of voters, there are names I have never seen ... which is really weird in my opinion. Either make it open for everybody and his dog or make a clear restriction. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-WEBMASTER] Re: [PHP Wiki] new user: fabpot
On Fri, Mar 1, 2013 at 1:19 PM, Johannes Schlüter johan...@schlueters.de wrote: Derick Rethans der...@php.net wrote: Exactly, this random apply rules nonsense needs to stop. I have nothing against Fabien voting but there is nowhere written who can vote or not (no, the voting RFC is too vague as well). I for one, would like to see a much stricter list of people who can vote. I often wonder about many names on the list of voters, there are names I have never seen ... which is really weird in my opinion. Either make it open for everybody and his dog or make a clear restriction. Currently the easiest way to get voting karma is to say you'll be creating an RFC, as anyone with karma in that namespace can automatically vote because votes happen in that namespace. Anyones mother can create a RFC (and therefore vote on anything), but if you just want to vote then you need to get approval from internals@. That voting RFC is btw really weird, I don't know how it got accepted. People with php.net SVN accounts that have contributed code to PHP is particularly funny as it disqualifies everyone working on docs, websites, infrastructure and whatnot (we don't however have separate roles for your karma level, so anyone with VCS account has full wiki privileges and can therefore vote). And considering the next part: Representatives from the PHP community, that will be chosen by those with php.net SVN accounts Is even more awesome, as the people working on docs, websites and infrastructure can choose those community representatives - without being able to vote themselves. All they have to do is I now pronounce you community representative. Hurray! I like the old approach better. When no clear consensus were reached, we would vote. Anyone in the world could vote on the mailinglist, and votes were creatively interpreted grouping people with karma vs community. Doing the same with polling is however difficult. Its a whole lot easier to spot fraud emails then it is to spot people signing up with multiple wiki accounts with the intentions of skewing the results. -Hannes
Re: [PHP-DEV] Re: [PHP-WEBMASTER] Re: [PHP Wiki] new user: fabpot
Hannes Magnusson hannes.magnus...@gmail.com wrote: I like the old approach better. When no clear consensus were reached, we would vote. Anyone in the world could vote on the mailinglist, and votes were creatively interpreted grouping people with karma vs community. Doing the same with polling is however difficult. Its a whole lot easier to spot fraud emails then it is to spot people signing up with multiple wiki accounts with the intentions of skewing the results. It shouldn't be a secret that I never liked the voting idea. Votes leave proposers with further information but a rejection. It easily happens that in the discussion phase before no clear guidance approaches (people ot argueing, people waiting just for the vote, specific people being pulled in to vote correctly, ...) which can be massively unconstructive for future contributions. (There's some nice articel from the Subversion authors, I think, on community work) Yes, a consensus driven decision process can be tough, but can produce better results than a vote. (Not mentioning all the confusion around votes, is a vote about concept or a solution or ...) johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Current Status of O+ on Windows
I am testing O+ on Windows with php 5.3, 5.4, and 5.5. I have uploaded my O+ test results here: http://windows.php.net/downloads/snaps/ostc/pftt/ Crashes have increased with 5.3, 5.4 and 5.5 TS builds with Apache. TS or NTS on CLI seem fine. See http://windows.php.net/downloads/snaps/ostc/pftt/PHP_5_3/r61099f8/PHPT_CMP_PHP_5_3-r61099f8-TS-X86-VC9_Local-FileSystem_Apache-ModPHP_v_PHP_5_3-r61099f8-TS-X86-VC9_OptimizerPlus_Local-FileSystem_Apache-ModPHP.html and http://windows.php.net/downloads/snaps/ostc/pftt/PHP_5_4/r7c08232/PHPT_CMP_PHP_5_4-r7c08232-TS-X86-VC9_Local-FileSystem_Apache-ModPHP_v_PHP_5_4-r7c08232-TS-X86-VC9_OptimizerPlus_Local-FileSystem_Apache-ModPHP.html and http://windows.php.net/downloads/snaps/ostc/pftt/PHP_5_4/r7c08232/PHPT_CMP_PHP_5_4-r7c08232-TS-X86-VC9_Local-FileSystem_CLI_v_PHP_5_4-r7c08232-TS-X86-VC9_OptimizerPlus_Local-FileSystem_CLI.html Crashes are up to 6 or 7 (in addition to the same 2 or 3) on 5.3 and 5.4. And with 5.5, crashes are up to 17 on CLI and 22 on Apache. 5.5 is compiled using VC11 whereas 5.4 and 5.3 are compiled using VC9 so that may be part of the issue with 5.5. See http://windows.php.net/downloads/snaps/ostc/pftt/PHP_5_5/r0d65a85/PHPT_CMP_PHP_5_5-r0d65a85-TS-X86-VC11_Local-FileSystem_Apache-ModPHP_v_PHP_5_5-r0d65a85-TS-X86-VC11_OptimizerPlus_Local-FileSystem_Apache-ModPHP.html and http://windows.php.net/downloads/snaps/ostc/pftt/PHP_5_5/r0d65a85/PHPT_CMP_PHP_5_5-r0d65a85-TS-X86-VC11_Local-FileSystem_CLI_v_PHP_5_5-r0d65a85-TS-X86-VC11_OptimizerPlus_Local-FileSystem_CLI.html Secondly, Reflection may be affected when running on Apache. PhpUnit uses reflection to run the actual test method. On Apache, all tests pass with O+ whereas on CLI or Apache without O+, I get ~38 errors and failures and some crashes (validated): Reflection seems broken only on Apache only with O+. See http://windows.php.net/downloads/snaps/ostc/pftt/PHP_5_5/r0d65a85/PhpUnit_CMP_Symfony-Standard-2.1.8_PHP_5_5-r0d65a85-TS-X86-VC11_Local-FileSystem_Apache-ModPHP_v_PHP_5_5-r0d65a85-TS-X86-VC11_OptimizerPlus_Local-FileSystem_Apache-ModPHP.html and http://windows.php.net/downloads/snaps/ostc/pftt/PHP_5_5/r0d65a85/PhpUnit_CMP_Symfony-Standard-2.1.8_PHP_5_5-r0d65a85-TS-X86-VC11_Local-FileSystem_CLI_v_PHP_5_5-r0d65a85-TS-X86-VC11_OptimizerPlus_Local-FileSystem_CLI.html PhpUnit uses ReflectionMethod::invokeArgs to actually invoke the test method to run the test, and if no exceptions are thrown, it assumes the test passes. I think at least some of the test methods aren't getting invoked (optimized out?) but no exception is thrown, so PhpUnit assumes the test passes. I am still studying this Reflection issue. I will try to create a PHPT test for this reflection+O+ issue. Regards -M
[PHP-DEV] Re: [PHP-WEBMASTER] Re: [PHP-DEV] Re: [PHP-WEBMASTER] Re: [PHP Wiki] new user: fabpot
2013.03.01. 22:52, Hannes Magnusson hannes.magnus...@gmail.com ezt írta: On Fri, Mar 1, 2013 at 1:19 PM, Johannes Schlüter johan...@schlueters.de wrote: Derick Rethans der...@php.net wrote: Exactly, this random apply rules nonsense needs to stop. I have nothing against Fabien voting but there is nowhere written who can vote or not (no, the voting RFC is too vague as well). I for one, would like to see a much stricter list of people who can vote. I often wonder about many names on the list of voters, there are names I have never seen ... which is really weird in my opinion. Either make it open for everybody and his dog or make a clear restriction. Currently the easiest way to get voting karma is to say you'll be creating an RFC, as anyone with karma in that namespace can automatically vote because votes happen in that namespace. Anyones mother can create a RFC (and therefore vote on anything), but if you just want to vote then you need to get approval from internals@. That voting RFC is btw really weird, I don't know how it got accepted. People with php.net SVN accounts that have contributed code to PHP is particularly funny as it disqualifies everyone working on docs, websites, infrastructure and whatnot (we don't however have separate roles for your karma level, so anyone with VCS account has full wiki privileges and can therefore vote). And considering the next part: Representatives from the PHP community, that will be chosen by those with php.net SVN accounts Is even more awesome, as the people working on docs, websites and infrastructure can choose those community representatives - without being able to vote themselves. All they have to do is I now pronounce you community representative. Hurray! I like the old approach better. When no clear consensus were reached, we would vote. Anyone in the world could vote on the mailinglist, and votes were creatively interpreted grouping people with karma vs community. Doing the same with polling is however difficult. Its a whole lot easier to spot fraud emails then it is to spot people signing up with multiple wiki accounts with the intentions of skewing the results. -Hannes only people with people with php.net accounts or with manually granted voting wiki group membership can vote. I have no idea who or on what ground can hand out voting ground membership, last time when somebody requested that (William, lead of propel) went unanswered. this is how currently the wiki voting works.
Re: [PHP-DEV] Current Status of O+ on Windows
On 03/01/2013 04:15 PM, Matt Ficken wrote: I am testing O+ on Windows with php 5.3, 5.4, and 5.5. I have uploaded my O+ test results here: http://windows.php.net/downloads/snaps/ostc/pftt/ Can you put your O+ php.ini settings up there as well? Did you experiment with any options? Putting the date of your O+ snapshot would also be handy. Chris -- christopher.jo...@oracle.com http://twitter.com/ghrd Newly updated, free PHP Oracle book: http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Current Status of O+ on Windows
On Sat, Mar 2, 2013 at 1:30 AM, Christopher Jones christopher.jo...@oracle.com wrote: Can you put your O+ php.ini settings up there as well? All default, especially for symfony tests, which must have the comment setting enabled (while some tests still fail even if the settings are enabled). Did you experiment with any options? Putting the date of your O+ snapshot would also be handy. Latest from here are used: http://windows.php.net/downloads/pecl/snaps/Optimizer/7.0.0-dev/ Dates are included. It would be nice to have it in the report as well, but we always use latest revision. It would however be much easier if there were PECL releases. Cheers, -- Pierre @pierrejoye -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-WEBMASTER] Re: [PHP-DEV] Re: [PHP-WEBMASTER] Re: [PHP Wiki] new user: fabpot
On Mar 2, 2013 12:26 AM, Ferenc Kovacs tyr...@gmail.com wrote: only people with people with php.net accounts or with manually granted voting wiki group membership can vote. I have no idea who or on what ground can hand out voting ground membership, last time when somebody requested that (William, lead of propel) went unanswered. this is how currently the wiki voting works. I personally couldn't care less if someone is working on insert popular framework. It bothers me slightly that people who never/rarely participate in RFC discussions, fix bugs or otherwise contribute to internals should get a say on what happens to the language by hiding in the shadows and just voting when they feel like it. This isn't a personal attack on anyone in particular, just a general statement. I (like many others here, I'm sure) work on projects that dwarf a lot of open source projects in terms of size and complexity, but I wouldn't dream of asking for vote karma until I felt like I'd committed a substantial amount back to core. I personally think getting userland project leads involved in voting just for the sake of it, when they never get their hands dirty in the guts of the language, will lead to more syntactic sugar style improvements and less actual language improvements. My 2c
[PHP-DEV] Re: [PHP-WEBMASTER] Re: [PHP-DEV] Re: [PHP-WEBMASTER] Re: [PHP Wiki] new user: fabpot
On Sat, Mar 2, 2013 at 1:26 AM, Ferenc Kovacs tyr...@gmail.com wrote: only people with people with php.net accounts or with manually granted voting wiki group membership can vote. I have no idea who or on what ground can hand out voting ground membership, last time when somebody requested that (William, lead of propel) went unanswered. this is how currently the wiki voting works. Before we try to create a storm in a teapot, it would be also very nice to actually look at the votes, who voted and check which of them are from @php.net. 99.9% are. And I myself wondered who is one or another voter. I even saw some legacy core contributors with no commit for 5 years+, not even bugs management activities. They worry me dramatically more than PHP project leaders, who actively contribute to PHP by reporting bugs, test cases, etc. and are much more in line with our users needs. Cheers, -- Pierre @pierrejoye -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
