OK having jumped through several hoops trying to get a stable installation of
Apache2.4.1 with PHP5.4 and Firebird 2.5.1 I now have a machine running and
while I've not been able to do a speed comparison as yet performance does seem
to be improved on what a simple comparison of machine speed improvement would
suggest.
Being a 6 core processor, on does wonder if better threaded performance of PHP
with Apache would be an advantage? But the main problem now is handling an array
of 'nanny' messages telling me that the code is badly written. Since the code
base has been developed form an environment where it was still PHP4 compatible,
many of the 'incremental improvements' of PHP5.2 and PHP5.3 have yet to be
addressed, so I suspect that while the code runs clean with 'display_errors' ON
in 5.3.10 I suspect every one of several hundred files now needs to be modified
to include things like 'private/protected/static' correctly in every base and
descendent class? Of cause things are not helped when PEAR packages add their
own array of warnings, but the main problem is where the heck to start on this.
I think what I am probably looking for is a clean guide as to how code SHOULD be
written nowadays in order to avoid the nanny messages since it's certainly not
my normal practice after 10 years of coding in PHP5 ...
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
Am 18.03.2012 10:14, schrieb Lester Caine:
I think what I am probably looking for is a clean guide as to how code SHOULD be written nowadays in order to avoid
the nanny messages since it's certainly not my normal practice after 10 years of coding in PHP5 ...
usually it would have been enough if you had used full error-reporting
from very first start and fixed deprecated warnings long ago
this way i am maintaining a CMS with around 250000 LOC since 2003
and did every major PHP-upgrade wgere it is used and distributed on
some hundret domains without any problem
any code which does not run with E_STRICT is not allowed to
run on our sevrvers and so the are no compromises needed
yes, so easy is life if someone decides not support any crap
Reindl Harald wrote:
Am 18.03.2012 10:14, schrieb Lester Caine:
I think what I am probably looking for is a clean guide as to how code SHOULD be written nowadays in order to avoid
the nanny messages since it's certainly not my normal practice after 10 years of coding in PHP5 ...
usually it would have been enough if you had used full error-reporting
from very first start and fixed deprecated warnings long ago
The code IS running clean in PHP5.3 and we had this same discussion back when
all the deprecated warnings came in ... it took some months to get to a point
where the error log was clean again ...
this way i am maintaining a CMS with around 250000 LOC since 2003
and did every major PHP-upgrade wgere it is used and distributed on
some hundret domains without any problemany code which does not run with
E_STRICTis not allowed to
run on our sevrvers and so the are no compromises needed
yes, so easy is life if someone decides not support any crap
Ditto ... which is why the reams of new messages are what is somewhat confusing.
The code runs fine and switching off the warnings prevents the logs growing at a
rapid rate,
I'm happy to run with display_errors = on because if an error does crop up we
prefer to know about it fast.
So I need to work out why with PHP5.4 we have such an overload of warning
messages ... so I CAN fix them ... which is why I'm asking here for advise on
migration information to a clean code base in PHP5.4 ...
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
Reindl Harald wrote:
Am 18.03.2012 10:14, schrieb Lester Caine:
I think what I am probably looking for is a clean guide as to how
code SHOULD be written nowadays in order to avoid
the nanny messages since it's certainly not my normal practice after
10 years of coding in PHP5 ...usually it would have been enough if you had used full error-reporting
from very first start and fixed deprecated warnings long agoThe code IS running clean in PHP5.3 and we had this same discussion back
when all the deprecated warnings came in ... it took some months to get to
a point where the error log was clean again ...this way i am maintaining a CMS with around 250000 LOC since 2003
and did every major PHP-upgrade wgere it is used and distributed on
some hundret domains without any problemany code which does not run with
E_STRICTis not allowed to
run on our sevrvers and so the are no compromises needed
yes, so easy is life if someone decides not support any crapDitto ... which is why the reams of new messages are what is somewhat
confusing. The code runs fine and switching off the warnings prevents the
logs growing at a rapid rate,
I'm happy to run with display_errors = on because if an error does crop up
we prefer to know about it fast.So I need to work out why with PHP5.4 we have such an overload of warning
messages ... so I CAN fix them ... which is why I'm asking here for advise
on migration information to a clean code base in PHP5.4 ...
http://docs.php.net/manual/en/migration54.other.php
-
E_ALL now includes E_STRICT level errors in the
error_reportinghttp://docs.php.net/manual/en/errorfunc.configuration.php#ini.error-reporting
configuration
directive.
I would guess your code was running clean, because you didn't have E_STRICT
in your error_reporting, now in php 5.4, E_ALL includes that by default,
and if you don't explicitly mask it, you will see those messages.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Ferenc Kovacs wrote:
- |E_ALL| now includes |E_STRICT| level errors in the error_reporting
http://docs.php.net/manual/en/errorfunc.configuration.php#ini.error-reporting configuration
directive.I would guess your code was running clean, because you didn't have
E_STRICTin
your error_reporting, now in php 5.4,E_ALLincludes that by default, and if you
don't explicitly mask it, you will see those messages.
This yet another example of subtle problems being created by not understanding
when settings get overriden without it being obvious! My 5.3 servers are set up
to ( E_ALL | E_STRICT ), and I was checking THAT in phpinfo, but a 'fix' for the
strict errors had been applied elsewhere in the codebase which simply over-rid
error_reporting so I was miss-led into thinking that these problems had been
fixed some years back. The error_reporting 'fix' for E_STRICT errors was added
back in 2009, and that was adding to my confusion this time around because my
settings did not make sense because of the 5.4 change. A short term fix is to
further bodge that override but I WOULD prefer to ACTUALLY fix the problems
rather than just hide it again. SO my original question still applies, but for
different reasons ... is there a crib sheet to help eliminate strict code errors
in legacy code bases?
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
[...] SO my original question still applies, but for different
reasons ... is there a crib sheet to help eliminate strict code errors in
legacy code bases?
Uhm, I'm not sure whether I am completely stupid and miss something
obvious: But what exactly is the problem with just reading the error
messages and fixing the errors they report? I mean, you get the reason
for the error and the line which causes it, so what is the problem
with going to that line and fixing that error?
Nikita
Forgot the pigging reply all :(
Nikita Popov wrote:
[...] SO my original question still applies, but for different
reasons ... is there a crib sheet to help eliminate strict code errors in
legacy code bases?
Uhm, I'm not sure whether I am completely stupid and miss something
obvious: But what exactly is the problem with just reading the error
messages and fixing the errors they report? I mean, you get the reason
for the error and the line which causes it, so what is the problem
with going to that line and fixing that error?
Nikita and others ...
Yes I can quite happily go through and fix each error as it appears and over a
few weeks the errors will have reduced, but that is not fixing the problem that
'modern' strict rules on coding style is somewhat different to how code WAS
written 10 years ago. I'd rather FIX the code base so that it follows how
E_STRICT expects the code to be written which I think needs a fairly major
rewrite of some of the core code base. I think ADOdb needs a rework as well as
other major libraries I am using which just adds to the hassle.
The alternative is simply to bury my head again as has been suggested and force
E_STRICT off in 5.4. But if I can't simply write code that IS 'complaint' in the
first place because I don't have any guide to work to how do we expect newcomers
to get their heads around the subtleties. They simply follow samples from old
tutorials which have exactly the same problems I'm trying to solve myself :(
( I'll move the problem of how the heck one fixes the dozens of "Array to string
conversion in" notices to the general list ... I'm seeing hundreds of reports of
these on the net now that 5.4 is rolling out .. )
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
Am 18.03.2012 18:53, schrieb Lester Caine:
Ferenc Kovacs wrote:
- |E_ALL| now includes |E_STRICT| level errors in the error_reporting
http://docs.php.net/manual/en/errorfunc.configuration.php#ini.error-reporting configuration
directive.I would guess your code was running clean, because you didn't have
E_STRICTin
your error_reporting, now in php 5.4,E_ALLincludes that by default, and if you
don't explicitly mask it, you will see those messages.This yet another example of subtle problems being created by not understanding when
settings get overriden without it being obvious!
for you, yes
My 5.3 servers are set up to (
E_ALL|E_STRICT), and I was checking THAT in phpinfo, but a
'fix' for the strict errors had been applied elsewhere in the codebase which simply
over-rid error_reporting
one of the big DO NOT
therefore exists <Directory> in httpd
SO my original question still applies, but for different reasons ...
is there a crib sheet to help eliminate strict code errors in legacy code bases?
damned DISABLE display_errors what should NEVER be enabled in
prdouction and start reading your error-log - why the hell do you
need any generic sheet if your logfile tells you existing problems?
So I need to work out why with PHP5.4 we have such an overload of warning
messages ... so I CAN fix them ... which is why I'm asking here for advise on
migration information to a clean code base in PHP5.4 ...
See http://php.net/migration54 if that doesn't help please check with a
user forum (like php-generals list), if something is missing please file
a bug and/or provide a patch.
This list is not for user support. This list is for future development.
Please help all here to keep it productive. Thanks.
johannes
Johannes Schlüter wrote:
This list is not for user support. This list is for future development.
Please help all here to keep it productive. Thanks.
And hopefully to educate developers to understand some of the problems that they
are creating by their actions?
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
Am 18.03.2012 10:14, schrieb Lester Caine:
I think what I am probably looking for is a clean guide as to how
code SHOULD be written nowadays in order to avoid
the nanny messages since it's certainly not my normal practice after
10 years of coding in PHP5 ...
I once worked with a team that didn't believe in E_NOTICE...
I turned it on, and flooded the logs on a shard DEV.
I turned it off. Copied the source to my own box, ran it with
E_NOTICE, did some grep/sed/awk mumbo-jumbo to find the most common
messages, fixed those, and committed them.
And found, corrected, and closed about 5 long-standing bugs in the
process.
They started to think maybe I was on to something here... :-)
We turned E_NOTICE back on at that point, as it was only an odd script
once in a while that went to the logs. Or new code from that one guy
who still didn't quite "get" it for awhile... He came around after we
fixed a couple of his newly-introduced bugs that were triggering
E_NOTICE...
--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE
May I suggest changing the error reporting value, that way we can stop
hearing about your damn code ;)
Seriously though, I doubt anyone has a guide like that.
I know I've always had E_STRICT enabled and honestly don't have the
slightest clue how to trigger a strict warning. When you develop with it
on.. you just don't make those mistakes and identify new issues as they
happen. Not 10 years of mistakes and depreciations at once.
Your best bet is to disable strict warnings in production, and chip away at
them as they show up on your development server.
Thanks,
Kiall
Sent from my phone.
OK having jumped through several hoops trying to get a stable installation
of Apache2.4.1 with PHP5.4 and Firebird 2.5.1 I now have a machine running
and while I've not been able to do a speed comparison as yet performance
does seem to be improved on what a simple comparison of machine speed
improvement would suggest.Being a 6 core processor, on does wonder if better threaded performance of
PHP with Apache would be an advantage? But the main problem now is handling
an array of 'nanny' messages telling me that the code is badly written.
Since the code base has been developed form an environment where it was
still PHP4 compatible, many of the 'incremental improvements' of PHP5.2 and
PHP5.3 have yet to be addressed, so I suspect that while the code runs
clean with 'display_errors' ON in 5.3.10 I suspect every one of several
hundred files now needs to be modified to include things like
'private/protected/static' correctly in every base and descendent class? Of
cause things are not helped when PEAR packages add their own array of
warnings, but the main problem is where the heck to start on this.I think what I am probably looking for is a clean guide as to how code
SHOULD be written nowadays in order to avoid the nanny messages since it's
certainly not my normal practice after 10 years of coding in PHP5 ...--
Lester Caine - G8HFLContact - http://lsces.co.uk/wiki/?page=**contacthttp://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/**index.php<http://www.firebirdsql.org/index.php
hi Lester,
Discussing periodically about the introduction of new notices or
warnings in releases is not very fun and interesting. Good habits and
related topics can be discussed on the php general mailing list or any
other support channels.
Thanks for your understanding,
OK having jumped through several hoops trying to get a stable installation
of Apache2.4.1 with PHP5.4 and Firebird 2.5.1 I now have a machine running
and while I've not been able to do a speed comparison as yet performance
does seem to be improved on what a simple comparison of machine speed
improvement would suggest.Being a 6 core processor, on does wonder if better threaded performance of
PHP with Apache would be an advantage? But the main problem now is handling
an array of 'nanny' messages telling me that the code is badly written.
Since the code base has been developed form an environment where it was
still PHP4 compatible, many of the 'incremental improvements' of PHP5.2 and
PHP5.3 have yet to be addressed, so I suspect that while the code runs clean
with 'display_errors' ON in 5.3.10 I suspect every one of several hundred
files now needs to be modified to include things like
'private/protected/static' correctly in every base and descendent class? Of
cause things are not helped when PEAR packages add their own array of
warnings, but the main problem is where the heck to start on this.I think what I am probably looking for is a clean guide as to how code
SHOULD be written nowadays in order to avoid the nanny messages since it's
certainly not my normal practice after 10 years of coding in PHP5 ...--
Lester Caine - G8HFLContact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php--
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org