>-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 th
On 7/19/2011 5:09 PM, Pierre Joye wrote:
On Wed, Jul 20, 2011 at 1:50 AM, Scott MacVicar 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
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 (includi
On Sun, Jul 24, 2011 at 01:07, 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
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 cours
On Sun, Jul 24, 2011 at 00:45, Pierre Joye 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
On Sun, Jul 24, 2011 at 00:36, Gwynne Raskind 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 natur
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
wrote:
> In my experienc
On Sat, Jul 23, 2011 at 22:06, Richard Quadling wrote:
> On 23 July 2011 17:16, Antony Dovgal 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.
>>> Th
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 ze
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_*
2011/7/23 Pierre Joye :
> 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: ht
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 wrote:
> Hi!
>
> Now that we've decided to add E_STRICT to E_ALL error mask, the question is
> - what
On Sat, Jul 23, 2011 at 11:50 PM, Stas Malyshev 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
On Jul 23, 2011 2:51 PM, "Stas Malyshev" 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
sure
I've just cc-ed the internals mailing list.
On Sat, Jul 23, 2011 at 11:54 PM, IraQue IraQue 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 ser
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
On 23 July 2011 17:16, Antony Dovgal 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 difference
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 wrote:
> hi
>
> is there any way to request a password from a user without
> showing the
-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
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
Hi Mike:
On Sat, Jul 23, 2011 at 6:49 PM, Mike Stowe 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
>
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 o
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
2011/7/23 Nuno Lopes :
> 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
> da
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
On Fri, Jul 22, 2011 at 8:41 PM, Jonathan Bond-Caron 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?
>
Hi Alex:
On Fri, Jul 22, 2011 at 7:46 PM, Alex Howansky 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
Hi:
On Fri, Jul 22, 2011 at 5:17 PM, Alex Howansky 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
29 matches
Mail list logo
