Steph Fox schrieb:
Marcus,
FWIW I'm with you (unusually) over E_STRICT. Why would anyone have E_ALL
switched on anywhere but a dev box?
at least i, as no one on this mailing list is interested in me, but i
have it on and it is logged only and not displayed.
some bugs are really hard to fin
If your production PHP code is generating so many entires in a log
file that it's a problem for the log file size, then, really, you've
got much bigger problems than the log file size...
At dealnews, we have been using PHP since PHP/FI. We have written A LOT
of code that never expected E_NOTIC
At 11:49 AM 5/15/2006, Brian Moon wrote:
Perhaps there should be an ini-development and an ini-production.
"recommended" was born after "dist" because we wanted to show how to run
PHP correctly (esp. BC breaking INI parameters such as
register_globals=off which are recommended). It's a bit di
At 11:49 AM 5/15/2006, Brian Moon wrote:
Steph Fox wrote:
ini-dist is set at E_ALL & ~E_NOTICE
ini-recommended is set at E_ALL
I'd guess that's why Brian reports seeing E_ALL enabled on web
hosts; they're advised to use the settings in ini-recommended, after all.
Perhaps there should be an in
Erhm... I meant, add E_STRICT warning message to the code to the
deprecated oo code.
On 15-May-06, at 2:35 PM, Marcus Boerger wrote:
Hello Ilia,
Monday, May 15, 2006, 3:23:18 PM, you wrote:
I suggest that we add E_STRICT now, but not include E_STRICT into
E_ALL,
We added E_STRICT in wha
On Mon, May 15, 2006 2:19 pm, Marcus Boerger wrote:
> This is very true, yet i don't see a reason to include E_NOTICE and
> E_STRICT
> on a production machine.
You've got 100% code coverage with all possible inputs and boundary
conditions in your QA process?...
Cuz, if not, I really don't see why
On Mon, May 15, 2006 1:59 pm, Marcus Boerger wrote:
> yeah we should simply rename the two files we have right now to
> that.
> I never knew which one to take since their names are not helpful.
> In production we would set something like E_ALL & ~E_STRICT &
> ~E_NOTICE.
> While in development we
A quick Google for common PHP error messages will almost for sure find
you a zillion sites with E_ALL in production servers.
2.1 million in fact.
http://www.google.com/search?q=notice+undefined+php
--
Brian Moon
-
http://dealnews.com/
Its good to be cheap =)
--
PHP Internals - PH
On Mon, May 15, 2006 9:41 am, Brian Moon wrote:
>> Why would anyone have E_ALL
>> switched on anywhere but a dev box?
>
> Working with Phorum, I get to peer into lots of different hosting
> companies setups when helping my users. I have seen many hosts that
> do
> have E_ALL enabled and do not log
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Steph Fox wrote:
>> Ones again E_ALL is for development. For example to move PEAR code to
>> PHP 5.
>> It is not for running legacy apps. IF you guys want i'd be ok with
>> adding a
>> new mode say "E_RUN"...
>
> You think that - I think that. A
Hello Markus,
Monday, May 15, 2006, 9:04:20 PM, you wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> Marcus Burger wrote:
>> Ones again E_ALL is for development.
> Is this the statement of all developers or only yours?
Probably mine, I mean i can only speak for myself here.
> I have
Marcus Boerger wrote:
Hello Brian,
yeah we should simply rename the two files we have right now to that.
I never knew which one to take since their names are not helpful.
In production we would set something like E_ALL & ~E_STRICT & ~E_NOTICE.
While in development we would do E_ALL as in all.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Marcus Burger wrote:
> Ones again E_ALL is for development.
Is this the statement of all developers or only yours?
I have to enable E_ALL on live servers (display_errors to 0), because
whatever resource you have at your hand, you just can't make sure
Hello Brian,
yeah we should simply rename the two files we have right now to that.
I never knew which one to take since their names are not helpful.
In production we would set something like E_ALL & ~E_STRICT & ~E_NOTICE.
While in development we would do E_ALL as in all.
Nice idea!
best regard
On 5/14/06, Steph Fox <[EMAIL PROTECTED]> wrote:
> Ones again E_ALL is for development. For example to move PEAR code to PHP
> 5.
> It is not for running legacy apps. IF you guys want i'd be ok with adding
> a
> new mode say "E_RUN"...
You think that - I think that. After Brian Moon's response
Steph Fox wrote:
ini-dist is set at E_ALL & ~E_NOTICE
ini-recommended is set at E_ALL
I'd guess that's why Brian reports seeing E_ALL enabled on web hosts;
they're advised to use the settings in ini-recommended, after all.
Perhaps there should be an ini-development and an ini-production.
--
Ones again E_ALL is for development. For example to move PEAR code to PHP
5.
It is not for running legacy apps. IF you guys want i'd be ok with adding
a
new mode say "E_RUN"...
You think that - I think that. After Brian Moon's response I went and
checked what the INI files distributed with P
Hello Greg,
Monday, May 15, 2006, 12:51:16 PM, you wrote:
> Steph Fox wrote:
>> Marcus,
>>
>> FWIW I'm with you (unusually) over E_STRICT. Why would anyone have E_ALL
>> switched on anywhere but a dev box? - and when there is the option to
>> switch on E_ALL without E_STRICT, it makes it much e
Hello Ilia,
Monday, May 15, 2006, 3:23:18 PM, you wrote:
> I suggest that we add E_STRICT now, but not include E_STRICT into
> E_ALL,
We added E_STRICT in what 5.0 or or 5.1? Guess i checked it:
[EMAIL PROTECTED] /usr/src/php-cvs $ cvs annotate Zend/zend_errors.h|grep
E_STRICT
Annotations fo
Hello Brian,
Monday, May 15, 2006, 6:40:58 PM, you wrote:
>> I find it hard to believe that anyone
>> involved - host or user - isn't aware that E_STRICT is on its way.
> Honestly, I only heard about it in the last few weeks. And I run an
> open source project based on PHP. I do PHP for a li
I find it hard to believe that anyone
involved - host or user - isn't aware that E_STRICT is on its way.
Honestly, I only heard about it in the last few weeks. And I run an
open source project based on PHP. I do PHP for a living. The average
web host and/or webmaster does not keep up with t
Why would anyone have E_ALL switched on anywhere but a dev box?
Working with Phorum, I get to peer into lots of different hosting
companies setups when helping my users. I have seen many hosts that do
have E_ALL enabled and do not log errors because they have no way to
provide that log back
Why would anyone have E_ALL
switched on anywhere but a dev box?
Working with Phorum, I get to peer into lots of different hosting
companies setups when helping my users. I have seen many hosts that do
have E_ALL enabled and do not log errors because they have no way to
provide that log back
I suggest that we add E_STRICT now, but not include E_STRICT into
E_ALL, so people who are not using E_STRICT error reporting level
don't have their applications start spewing strict messages.
We cannot force people to change their code, all we can reasonably do
is provide notification mechan
On Mon, 15 May 2006, Ilia Alshanetsky wrote:
> My opinion is that if we intend to make something stop working (give fatal
> error) in future releases we need to provide some form of notice be it
> E_STRICT or E_NOTICE to our users now, so they can anticipate the change. As
> far as inclusion of E_
My opinion is that if we intend to make something stop working (give
fatal error) in future releases we need to provide some form of
notice be it E_STRICT or E_NOTICE to our users now, so they can
anticipate the change. As far as inclusion of E_STRICT into E_ALL, I
think this is a good idea
Steph Fox wrote:
> Marcus,
>
> FWIW I'm with you (unusually) over E_STRICT. Why would anyone have E_ALL
> switched on anywhere but a dev box? - and when there is the option to
> switch on E_ALL without E_STRICT, it makes it much easier to miss
> useful information about the direction PHP is going
On 5/15/06, Marcus Boerger <[EMAIL PROTECTED]> wrote:
Sorry i have to say that but PEAR is no argument here as still after
years of PHP 5 there is no PHP 5 compatible PEAR. Yet we are discussing
a PHP 5 version here.
This is a pointless argument. First there is php5 only packages.
Second you
Ron Korving wrote:
Wouldn't it be nice to start a PEAR2 (or 5) then, with PHP5-ready code,
where PHP5 features will actually be used and backwards compatibility for
PHP4 is lacking. The current PEAR could gradually be ported into this, and
PHP4-users can continue to use PEAR (version 1, if you
Wouldn't it be nice to start a PEAR2 (or 5) then, with PHP5-ready code,
where PHP5 features will actually be used and backwards compatibility for
PHP4 is lacking. The current PEAR could gradually be ported into this, and
PHP4-users can continue to use PEAR (version 1, if you will).
Ron
"Lukas
Marcus Boerger wrote:
Sorry i have to say that but PEAR is no argument here as still after
years of PHP 5 there is no PHP 5 compatible PEAR. Yet we are discussing
a PHP 5 version here.
PEAR is PHP5 compatible. But you probably meant E_STRICT compatible.
Yes, I agree that PEAR needs to become
Hello Lukas,
Monday, May 15, 2006, 8:43:41 AM, you wrote:
> Derick Rethans wrote:
>> On Sun, 14 May 2006, Marcus Boerger wrote:
>>
>>> That said i am about to not remove E_STRICT from E_ALL and MFH the php
>>> 6.0 to item just now.
>>> See: http://oss.backendmedia.com/PhP60 (add E_STRICT to E_A
Derick Rethans wrote:
On Sun, 14 May 2006, Marcus Boerger wrote:
That said i am about to not remove E_STRICT from E_ALL and MFH the php
6.0 to item just now.
See: http://oss.backendmedia.com/PhP60 (add E_STRICT to E_ALL DONE (dmitry))
Since this is for the benefit of the users to prevent issu
On Sun, 14 May 2006, Marcus Boerger wrote:
> That said i am about to not remove E_STRICT from E_ALL and MFH the php
> 6.0 to item just now.
> See: http://oss.backendmedia.com/PhP60 (add E_STRICT to E_ALL DONE (dmitry))
>
> Since this is for the benefit of the users to prevent issues with
> chang
Marcus,
FWIW I'm with you (unusually) over E_STRICT. Why would anyone have E_ALL
switched on anywhere but a dev box? - and when there is the option to switch
on E_ALL without E_STRICT, it makes it much easier to miss useful
information about the direction PHP is going in.
Pierre: the bigges
Hello internals,
by accident i added both E_STRICT and E_RECOVERABLE_ERROR to E_ALL
while MFHing new features as discussed beforehand while decision was
only to MFH E_RECOVERABLE_ERROR and not to put E_STRICT into E_ALL.
See: http://oss.backendmedia.com/PhP52
Now the idea of E_STRICT is that core
36 matches
Mail list logo
