Re: [PHP-DEV] 5.4a2 trait attribute name conflict resolution
Hi:
On Fri, Jul 22, 2011 at 5:17 PM, Alex Howansky alex.howan...@gmail.com wrote:
Hello folks,
I've just grabbed 5.4a2 to play with traits. I've found some behaviour which
I'm not sure is a bug, an inconsistency, or a design decision.
Consider a trait and a class that implements it but also overrides both a
trait method and a trait attribute:
trait foo
{
public $zoo = 'foo::zoo';
public function bar()
{
echo in foo::bar\n;
}
}
class baz
{
use foo;
public $zoo = 'baz::zoo';
public function bar()
{
echo in baz::bar\n;
}
}
$obj = new baz();
$obj-bar();
echo $obj-zoo, \n;
We get:
in baz::bar
foo::zoo
It seems this is not correct and that it should be:
in baz::bar
baz::zoo
After some more thought, my take on this is that those properties are
not compatible, and we do the only simple thing possible and raise an
error as soon as possible, because the trait might have changed to
something that is not compatible with the class and the developer has
to be made aware of that.
While traits do not support state per se, we defined a minimal set of
rules so that the use of properties which conflict in their semantics
breaks as early as possible and noticeable to the developer.
Please refer to
https://wiki.php.net/rfc/horizontalreuse?#handling_of_propertiesstate
for the exact set of rules defined currently.
These rules (rule 1) define that properties are considered
incompatible if they differ in their initial value.
Thus, the case you see here is, according to the rules defined in the
RFC, a bug.
And after looking at the implementation, it turns out that I just
forgot to check one of the return values of the compare function.
Thus, this is fixed as per
http://svn.php.net/viewvc?view=revisionrevision=313632
Best regards
Stefan
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4a2 trait attribute name conflict resolution
Hi Alex: On Fri, Jul 22, 2011 at 7:46 PM, Alex Howansky alex.howan...@gmail.com wrote: Best practice, always choose trait property names carefully/~unique so that you don't run into conflicts. Sure, but in this case, I created the conflict intentionally because I *want* to override it, and I'm not allowed to like I am with methods. Don't you think that's inconsistent? The short answer is it's not a bug but maybe an implementation issue... should it be an E_WARNING instead of E_STRICT? At least. Consider the situation where I'm using classes/traits from somebody else's library that I may not be intimately familiar with. I'll have to know what every one of their properties is named so I can plan my code accordingly -- else I'll silently start getting their values in what I think are my variables. If their trait grows that complex, with its own set of invariants, it is a clear sign that it should be a class instead. Traits are supposed to be a very light-weight mechanism for reuse of behavior. Classes already provide you with the necessary means of encapsulation you are asking for here: but traits do not do that. If you want to reuse a trait that is that complex, consider to use it in a separate class, which is then used in a composition in the class were you originally were going to use the trait directly. Traits do not allow to be reused without knowing their internals. The metaphor of a compiler-assisted copy'n'past mechanism hints at that. At least that is my interpretation of the topic. Best regards Stefan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4a2 trait attribute name conflict resolution
On Fri, Jul 22, 2011 at 8:41 PM, Jonathan Bond-Caron jbo...@openmv.com wrote: On Fri Jul 22 01:46 PM, Alex Howansky wrote: Sure, but in this case, I created the conflict intentionally because I *want* to override it, and I'm not allowed to like I am with methods. Don't you think that's inconsistent? Agree I do not agree, because for methods there is for most cases a way around. You can introduce a new alias for the same behavior and use that from the method which is overriding the original method name of the trait. Thus, there is a flexible way to compose behavior, and that is what we do everyday. State how ever, does not come with that property, and the last time we discussed different ideas in that direction they were deemed to be complex. So that traits can keep their own private state (Ben Schmidt's idea) One of those ideas should definitely be reconsidered for a later version of PHP, but for the moment, I would prefer to concentrate on getting bug-free what we have already and gather some experience on how it is actually used in real-world scenarios. In the end, if you trait is to complex and can 'break' easily, I think that shows that it is worth to be implemented as a class, and you might use instead a trait that provides you with the necessary delegation functions. Best regards Stefan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] new gcov.php.net machine is up
Hi, Thanks to Nexcess, we have a new wonderful machine for http://gcov.php.net up and running. This new machine is running linux 64 bits, so expect a few differences in the test results. I believe most things are ported from the old machine, including all daemon's configurations. I fired an experimental run of the cron job. Please help me by reporting extensions that are not enabled, daemons that are misconfigured and why (and therefore some tests are failing or skiping), missing valgrind suppressions, and so on. Thanks to Nexcess for offering a new machine to replace the old one. Nuno -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] new gcov.php.net machine is up
2011/7/23 Nuno Lopes nlop...@php.net: Hi, Thanks to Nexcess, we have a new wonderful machine for http://gcov.php.net up and running. This new machine is running linux 64 bits, so expect a few differences in the test results. I believe most things are ported from the old machine, including all daemon's configurations. I fired an experimental run of the cron job. Please help me by reporting extensions that are not enabled, daemons that are misconfigured and why (and therefore some tests are failing or skiping), missing valgrind suppressions, and so on. Thanks to Nexcess for offering a new machine to replace the old one. Nuno Nice! I see the mail now works too. :) Thanks Nuno++ -- Regards, Felipe Pena -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] new gcov.php.net machine is up
Thanks Nuno, great job! On 07/23/2011 08:03 PM, Nuno Lopes wrote: Hi, Thanks to Nexcess, we have a new wonderful machine for http://gcov.php.net up and running. This new machine is running linux 64 bits, so expect a few differences in the test results. I believe most things are ported from the old machine, including all daemon's configurations. I fired an experimental run of the cron job. Please help me by reporting extensions that are not enabled, daemons that are misconfigured and why (and therefore some tests are failing or skiping), missing valgrind suppressions, and so on. Thanks to Nexcess for offering a new machine to replace the old one. Nuno -- Wbr, Antony Dovgal --- http://pinba.org - realtime profiling for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4a2 trait attribute name conflict resolution
So am I understanding correctly that the initial properties must be identical both in type and value, otherwise it would throw an error. To me that would make the most sense as they could be overridden in a construct or other method. If they are allowed to be different with one overriding the other- than for usability the class should override the trait properties as it does with methods. This way it remains consistent, which I think would be the general expectation. The trait should likewise override the parent class properties as it does with the parent methods (unless I misread that). But essentially if they're allowed to be different the overriding pattern IMHO should be the same as that used for methods. - Mike :o) Sent from my iPhone On Jul 23, 2011, at 8:58 AM, Stefan Marr p...@stefan-marr.de wrote: On Fri, Jul 22, 2011 at 8:41 PM, Jonathan Bond-Caron jbo...@openmv.com wrote: On Fri Jul 22 01:46 PM, Alex Howansky wrote: Sure, but in this case, I created the conflict intentionally because I *want* to override it, and I'm not allowed to like I am with methods. Don't you think that's inconsistent? Agree I do not agree, because for methods there is for most cases a way around. You can introduce a new alias for the same behavior and use that from the method which is overriding the original method name of the trait. Thus, there is a flexible way to compose behavior, and that is what we do everyday. State how ever, does not come with that property, and the last time we discussed different ideas in that direction they were deemed to be complex. So that traits can keep their own private state (Ben Schmidt's idea) One of those ideas should definitely be reconsidered for a later version of PHP, but for the moment, I would prefer to concentrate on getting bug-free what we have already and gather some experience on how it is actually used in real-world scenarios. In the end, if you trait is to complex and can 'break' easily, I think that shows that it is worth to be implemented as a class, and you might use instead a trait that provides you with the necessary delegation functions. Best regards Stefan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4a2 trait attribute name conflict resolution
Hi Mike: On Sat, Jul 23, 2011 at 6:49 PM, Mike Stowe mikegst...@gmail.com wrote: So am I understanding correctly that the initial properties must be identical both in type and value, otherwise it would throw an error. To me that would make the most sense as they could be overridden in a construct or other method. Yes, they have to be perfectly identical. Any difference indicates, in this strict model, a potential conflict and different semantics of that particular property i.e. the state. Since we do not provide any means to manage such conflicts, we bail out as early as possible and ask the programmer to fix his code by ensuring everything is compatible. Best regards Stefan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] CLI: input password without showing it
hi is there any way to request a password from a user without showing the input in the terminal? $input_pwd = trim(fgets(STDIN)); works nice as long no foreigner is in the room :-( signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] CLI: input password without showing it
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/23/2011 12:07 PM, Reindl Harald wrote: hi is there any way to request a password from a user without showing the input in the terminal? $input_pwd = trim(fgets(STDIN)); works nice as long no foreigner is in the room :-( Really not an internals question. This is more a StackOverflow type of question, where in fact this has been asked and answered a couple of times: http://stackoverflow.com/questions/187736/command-line-password-prompt-in-php - -Rasmus -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4rHhQACgkQlxayKTuqOuDJTgCfc8gHHXqc2hioxYqA5aOGmhpk OeAAnArlpmj+jbeyAmxbsHtxRIwNwN+o =nU1k -END PGP SIGNATURE- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CLI: input password without showing it
Check the password method here: https://github.com/kohana-minion/core/blob/develop/classes/minion/cli.php It should do what you want on windows+linux.. Kiall On Sat, Jul 23, 2011 at 8:07 PM, Reindl Harald h.rei...@thelounge.netwrote: hi is there any way to request a password from a user without showing the input in the terminal? $input_pwd = trim(fgets(STDIN)); works nice as long no foreigner is in the room :-(
Re: [PHP-DEV] new gcov.php.net machine is up
On 23 July 2011 17:16, Antony Dovgal t...@daylessday.org wrote: Thanks Nuno, great job! On 07/23/2011 08:03 PM, Nuno Lopes wrote: Hi, Thanks to Nexcess, we have a new wonderful machine for http://gcov.php.net up and running. This new machine is running linux 64 bits, so expect a few differences in the test results. I believe most things are ported from the old machine, including all daemon's configurations. I fired an experimental run of the cron job. Please help me by reporting extensions that are not enabled, daemons that are misconfigured and why (and therefore some tests are failing or skiping), missing valgrind suppressions, and so on. Thanks to Nexcess for offering a new machine to replace the old one. Nuno Excellent work. I see from the recent report that there are a LOT of similar warnings. I'm guessing that those warnings, whilst they are generated on a linux x64 box, would be the same for win32 (and anything else). What sort of policy is needed in addressing casting warnings like this. I get a LOT of warnings about casting of doubles/floats to ints/longs, along with the potential for potential data loss. How feasible is it to aim for a 100% warning free build? I'm not meaning that we should suppress the warnings. -- 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
[PHP-DEV] E_STRICT in production
Hi! Now that we've decided to add E_STRICT to E_ALL error mask, the question is - what should we put in recommended production INI - should we include E_STRICT or not? Development has E_STRICT anyway, so no question there. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-WEBMASTER] New web server
sure I've just cc-ed the internals mailing list. On Sat, Jul 23, 2011 at 11:54 PM, IraQue IraQue iraq...@live.com wrote: Ah, alright. However, is it possible i could get in contact with any of the developers who made PHP? Date: Sat, 23 Jul 2011 22:32:42 +0200 Subject: Re: [PHP-WEBMASTER] New web server From: tyr...@gmail.com To: iraq...@live.com CC: php-webmas...@lists.php.net On Sat, Jul 23, 2011 at 10:02 PM, IraQue IraQue iraq...@live.com wrote: Hi there PHP! I am developing a new web server, and i would like to make it possible to include PHP in it. However i am not that good at C, to figure out how to include it. Maybe we could work together in some way? I'm not the most competent person in this topic, but imo you should look into http://en.wikipedia.org/wiki/Fastcgi -- Ferenc Kovács @Tyr43l - http://tyrael.hu -- Ferenc Kovács @Tyr43l - http://tyrael.hu -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] E_STRICT in production
On Jul 23, 2011 2:51 PM, Stas Malyshev smalys...@sugarcrm.com wrote: Now that we've decided to add E_STRICT to E_ALL error mask, the question is - what should we put in recommended production INI - should we include E_STRICT or not? Development has E_STRICT anyway, so no question there. I can't look it up easily at the moment, but assuming display_errors is off on the production configuration, I'd be inclined to make the error_reporting levels the same: that is, include E_STRICT. Adam
Re: [PHP-DEV] E_STRICT in production
On Sat, Jul 23, 2011 at 11:50 PM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! Now that we've decided to add E_STRICT to E_ALL error mask, the question is - what should we put in recommended production INI - should we include E_STRICT or not? Development has E_STRICT anyway, so no question there. I think no. first of all, 1 think it would be better to change only one thing at a time (add E_STRICT to E_ALL), and we also exclude E_DEPRECATED for production, which would imo much more important for most apps than fixing the E_STRICT problems. -- Ferenc Kovács @Tyr43l - http://tyrael.hu -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] E_STRICT in production
hi Stas, The idea of E_STRICT when we introduced it was to help developers. So I tend to think that we should not enable it in php.ini-production. On Sat, Jul 23, 2011 at 11:50 PM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! Now that we've decided to add E_STRICT to E_ALL error mask, the question is - what should we put in recommended production INI - should we include E_STRICT or not? Development has E_STRICT anyway, so no question there. -- 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 -- 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] E_STRICT in production
2011/7/23 Pierre Joye pierre@gmail.com: hi Stas, The idea of E_STRICT when we introduced it was to help developers. So I tend to think that we should not enable it in php.ini-production. Agreed. -- Regards, Felipe Pena -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] set the PHP_INI_ENTRY_* values the same as for php.ini-production
hi. We had a discussion about the magic_quotes removal that it is weird that even though that mq was deprecated in 5.3, we still have/had that enabled by default (if you didn't set it from the command line or through a php.ini, the default value which is set from the source by the PHP_INI_ENTRY_* macros). I would propose that the defaul values(PHP_INI_ENTRY_*) and the php.ini-production should be keep in sync as much as possible. for one thing, this would be less confusing (what do we mean by default? PHP_INI_ENTRY_* or the php.ini? why are they different? etc.), the second thing would be the principle of the fail-secure principle: usually the production settings are more secure and less verbose(display_errors for example). what do you think? of course, if this keeps traction, a proper RFC would be needed, but for now, I'm just throwing ideas. -- Ferenc Kovács @Tyr43l - http://tyrael.hu -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] new gcov.php.net machine is up
In my experience, 100% warnings free is only practical in two cases: 1) When the project is built with that policy from day one. 2) When someone takes the (I'd estimate) two weeks solid work necessary to eliminate every existing warning from the current trunk, AND a strict policy of maintaining zero warnings is put in place. (Believe me, the policy doesn't work if there are any warnings in the build; people inevitably get lazy.) Given the variety of warnings that pop up in a PHP build (and don't even start me on the list thrown up by Clang's static analyzer!), it's a major undertaking to eliminate all the warnings, and it'll get ugly. -- Gwynne On Sat, Jul 23, 2011 at 16:06, Richard Quadling rquadl...@gmail.com wrote: On 23 July 2011 17:16, Antony Dovgal t...@daylessday.org wrote: Thanks Nuno, great job! On 07/23/2011 08:03 PM, Nuno Lopes wrote: Hi, Thanks to Nexcess, we have a new wonderful machine for http://gcov.php.net up and running. This new machine is running linux 64 bits, so expect a few differences in the test results. I believe most things are ported from the old machine, including all daemon's configurations. I fired an experimental run of the cron job. Please help me by reporting extensions that are not enabled, daemons that are misconfigured and why (and therefore some tests are failing or skiping), missing valgrind suppressions, and so on. Thanks to Nexcess for offering a new machine to replace the old one. Nuno Excellent work. I see from the recent report that there are a LOT of similar warnings. I'm guessing that those warnings, whilst they are generated on a linux x64 box, would be the same for win32 (and anything else). What sort of policy is needed in addressing casting warnings like this. I get a LOT of warnings about casting of doubles/floats to ints/longs, along with the potential for potential data loss. How feasible is it to aim for a 100% warning free build? I'm not meaning that we should suppress the warnings. -- 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] new gcov.php.net machine is up
On Sat, Jul 23, 2011 at 22:06, Richard Quadling rquadl...@gmail.com wrote: On 23 July 2011 17:16, Antony Dovgal t...@daylessday.org wrote: Thanks Nuno, great job! On 07/23/2011 08:03 PM, Nuno Lopes wrote: Hi, Thanks to Nexcess, we have a new wonderful machine for http://gcov.php.net up and running. This new machine is running linux 64 bits, so expect a few differences in the test results. I believe most things are ported from the old machine, including all daemon's configurations. I fired an experimental run of the cron job. Please help me by reporting extensions that are not enabled, daemons that are misconfigured and why (and therefore some tests are failing or skiping), missing valgrind suppressions, and so on. Thanks to Nexcess for offering a new machine to replace the old one. Nuno Excellent work. I see from the recent report that there are a LOT of similar warnings. I'm guessing that those warnings, whilst they are generated on a linux x64 box, would be the same for win32 (and anything else). What sort of policy is needed in addressing casting warnings like this. I get a LOT of warnings about casting of doubles/floats to ints/longs, along with the potential for potential data loss. How feasible is it to aim for a 100% warning free build? I'm not meaning that we should suppress the warnings. I have vague memories from last year when a person tried to offer a patch to initialize all structs properly.. It was semi-rejected, but if a person with karma to commit would take it upon herself to commit such patch, I doubt it will be rejected. A person without a proven repletion for karma to php-src posting such patch posting it, is however massive work to review (read; _major_ work to review all edge cases) and will probably be ignored/rejected. -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] new gcov.php.net machine is up
I would add: 2.1 fix the new ones That's what I try to do using a delta between two revisions. At some point these delta will be available online so anyone can fix them as well, including the author of these new warnings. On Sun, Jul 24, 2011 at 12:36 AM, Gwynne Raskind gwy...@darkrainfall.org wrote: In my experience, 100% warnings free is only practical in two cases: 1) When the project is built with that policy from day one. 2) When someone takes the (I'd estimate) two weeks solid work necessary to eliminate every existing warning from the current trunk, AND a strict policy of maintaining zero warnings is put in place. (Believe me, the policy doesn't work if there are any warnings in the build; people inevitably get lazy.) Given the variety of warnings that pop up in a PHP build (and don't even start me on the list thrown up by Clang's static analyzer!), it's a major undertaking to eliminate all the warnings, and it'll get ugly. -- Gwynne On Sat, Jul 23, 2011 at 16:06, Richard Quadling rquadl...@gmail.com wrote: On 23 July 2011 17:16, Antony Dovgal t...@daylessday.org wrote: Thanks Nuno, great job! On 07/23/2011 08:03 PM, Nuno Lopes wrote: Hi, Thanks to Nexcess, we have a new wonderful machine for http://gcov.php.net up and running. This new machine is running linux 64 bits, so expect a few differences in the test results. I believe most things are ported from the old machine, including all daemon's configurations. I fired an experimental run of the cron job. Please help me by reporting extensions that are not enabled, daemons that are misconfigured and why (and therefore some tests are failing or skiping), missing valgrind suppressions, and so on. Thanks to Nexcess for offering a new machine to replace the old one. Nuno Excellent work. I see from the recent report that there are a LOT of similar warnings. I'm guessing that those warnings, whilst they are generated on a linux x64 box, would be the same for win32 (and anything else). What sort of policy is needed in addressing casting warnings like this. I get a LOT of warnings about casting of doubles/floats to ints/longs, along with the potential for potential data loss. How feasible is it to aim for a 100% warning free build? I'm not meaning that we should suppress the warnings. -- 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- 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] new gcov.php.net machine is up
On Sun, Jul 24, 2011 at 00:36, Gwynne Raskind gwy...@darkrainfall.org wrote: Given the variety of warnings that pop up in a PHP build (and don't even start me on the list thrown up by Clang's static analyzer!), it's a major undertaking to eliminate all the warnings, and it'll get ugly. Exactly. And given the nature of PHP, using several dozen bucketloads of external libraries... it is isn't realistic to eliminate all random [irrelevant] compiler warnings. Couple of years ago I have vague memories of homeland security [usa] project, and several projects after that, offering various analyzes of php-src. I believe secur...@php.net receives such reports automatically (they had login credentials at least). Removing compiler warnings is (in a project like PHP) generally not a high priority, but again, if a trusted person commits such a patch.. I highly doubt it would get reverted. -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] new gcov.php.net machine is up
On Sun, Jul 24, 2011 at 00:45, Pierre Joye pierre@gmail.com wrote: I would add: 2.1 fix the new ones That's what I try to do using a delta between two revisions. At some point these delta will be available online so anyone can fix them as well, including the author of these new warnings. That is an excellent point. We have a Windows buildbox and I noticed gcov has started notifying about broken builds.. We also have 5+ others servers (various BSD and Linux versions). Is anyone working on a unified buildbot to run on these servers? We also have the `make test` statistics on http://qa.php.net/reports/ by Oivier.. Would it be possible to coordinate all these efforts? -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] new gcov.php.net machine is up
Here's my question - if I made some smaller commits here and there to fix warnings in core, would that be accepted? I don't have time to do sweeping changes, but fixing one file today, a couple the next day, etc., is within my abilities (including making sure no regressions are introduced, of course). -- Gwynne On Sat, Jul 23, 2011 at 18:54, Hannes Magnusson hannes.magnus...@gmail.com wrote: On Sun, Jul 24, 2011 at 00:45, Pierre Joye pierre@gmail.com wrote: I would add: 2.1 fix the new ones That's what I try to do using a delta between two revisions. At some point these delta will be available online so anyone can fix them as well, including the author of these new warnings. That is an excellent point. We have a Windows buildbox and I noticed gcov has started notifying about broken builds.. We also have 5+ others servers (various BSD and Linux versions). Is anyone working on a unified buildbot to run on these servers? We also have the `make test` statistics on http://qa.php.net/reports/ by Oivier.. Would it be possible to coordinate all these efforts? -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] new gcov.php.net machine is up
On Sun, Jul 24, 2011 at 01:07, Gwynne Raskind gwy...@darkrainfall.org wrote: Here's my question - if I made some smaller commits here and there to fix warnings in core, would that be accepted? I don't have time to do sweeping changes, but fixing one file today, a couple the next day, etc., is within my abilities (including making sure no regressions are introduced, of course). Why on earth would anyone complain about such commit from an already-trusted-person-with-karma? If you start flooding the commit list with one-liners, people will probably complain. But if you are willing to do the extensive work needed to fix several warnings per commit.. I personally wouldn't commit such patch from 3rd party. Reverting such commit from a person I trust however wouldn't come to mind. Cursory review would be all *I* would do. Can't speak for anyone else... Fixing these sort of warnings in existing stable releases however IMO causes more risk then necessary. -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] new gcov.php.net machine is up
On 07/23/2011 04:07 PM, Gwynne Raskind wrote: Here's my question - if I made some smaller commits here and there to fix warnings in core, would that be accepted? I don't have time to do sweeping changes, but fixing one file today, a couple the next day, etc., is within my abilities (including making sure no regressions are introduced, of course). That's fine if it is done carefully. Note that the code needs to compile on many different platforms, on many different compilers and versions of compilers. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/ branches/PHP_5_4/ext/openssl/openssl.c trunk/ext/openssl/openssl.c
On 7/19/2011 5:09 PM, Pierre Joye wrote: On Wed, Jul 20, 2011 at 1:50 AM, Scott MacVicarsc...@macvicar.net wrote: OpenSSL has been FIPS certified, your change has changed this contract and it's calling back into a Windows API. Has it been reviewed for correctness? And by the way, the CryptoAPI for the windows versions we support is certified as well. Just in case you did not check yourself in the 1st place. Furter ref, http://technet.microsoft.com/en-us/library/cc750357.aspx Cheers, I'm jumping on this one rather late. I have no idea if you can *mix* two different FIPS-validated crypto/SSL libraries and still be able to claim FIPS validation of those libraries. I'm pretty sure you would have to go through the whole FIPS validation process with the combination of the two. To the best of my knowledge, no one has ever done that before. That all said, I have NEVER thought of PHP as a project that would ever care about claiming FIPS compliance. To use FIPS with OpenSSL, FIPS first has to be compiled into OpenSSL using a special build process almost no one goes through. Then the library has to be switched into FIPS mode within the application code itself using either FIPS_mode_set() or a configuration file and then checking for FIPS with a call to FIPS_mode() from within the application. You're supposed to exit if you are expecting FIPS and it failed to initialize for whatever reason. -- Thomas Hruska CubicleSoft President Barebones CMS is a high-performance, open source content management system for web developers operating in a team environment. An open source CubicleSoft initiative. Your choice of a MIT or LGPL license. http://barebonescms.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] E_STRICT in production
-Original Message- From: Pierre Joye [mailto:pierre@gmail.com] Sent: Saturday, July 23, 2011 3:22 PM To: Stas Malyshev Cc: PHP Internals Subject: Re: [PHP-DEV] E_STRICT in production hi Stas, The idea of E_STRICT when we introduced it was to help developers. So I tend to think that we should not enable it in php.ini-production. Agree. Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
