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
I don't see why it has to be a fatal error. If there's an instanceof
relationship we can keep $this. If not, we should not pass $this
(which I believe we already do in PHP 5), in which case the author
would have to pass $this if he wants to change public properties.
Andi
At 12:49 PM 5/15/2006
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
Would a method be able to return a writable reference of this
readonly property? If not it'd actually be PITA to prevent this. This
is one of those questions which can turn a two second patch by
Marcus, to an ongoing patch where we continue to fix various places
and continue to bloat the langua
Marcus Boerger wrote:
To rephrase Andi "So people screw up. I prefer having the occasional
screw up then less people helping out." We are a community [...]
What we need is more helping hands and less comlaining notes. Actually
we are constantly working on increasing or QA efforts. And from my
po
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
Interesting, what os is this one and can they provide more info in
regard to what "does not work" ?
On 15-May-06, at 4:26 PM, Wez Furlong wrote:
One of our customers reports that 5.1.4 fastcgi does not work, but
that 5.2 does.
It sounds like this needs to be addressed and a 5.1.5 released
Derick,
The case we're talking about here is where a Unicode string containing
only ASCII characters is passed to an extension, not a binary string
with the same characters.
-Andrei
On May 15, 2006, at 2:53 PM, Derick Rethans wrote:
Yeah, but that doesnt mean you need to throw a hard error
On Mon, May 15, 2006 2:47 pm, Marcus Boerger wrote:
>> [...] Is there a significant performance
>> enhancement in the engine that depends on eliminating semi-static
>> or somesuch?
>
> Security. We might as well enable the crash function in non debug
> builds.
> Or just drop 'static' again and go
On Mon, May 15, 2006 4:19 pm, Andrei Zmievski wrote:
> That assumes there are a hundred places where you want to receive an
> ASCII string. Are they really that prevalent?
How many of the extension libraries are Unicode-ready?
You see an awful lot of users with quasi-Unicode data that gets into
t
On Mon, 15 May 2006, Nuno Lopes wrote:
I was not refering to the html/xhtml/xml input. I was talking about the
charset parameter, for example. I don't want a chinese string passed as
the
charset name (the libtidy API isn't localized yet :) ). The same applies
for
the other functions.
Yeah,
Hartmut Holzgraefe wrote:
Zeev Suraski wrote:
What does that give you that class constants don't?
i on the other hand fail to see how it is related to class constants
at all?
hm ... this was not supposed to get out as i had seen your reply
to yourself ...
--
Hartmut Holzgraefe, Senior Suppo
On Mon, May 15, 2006 3:17 pm, Sebastian Bergmann wrote:
> Edin Kadribasic wrote:
>> OO purity/strictness do now work well with PHP's main strength --
>> its
>> dynamicity.
>
> You make it sound like OO and dynamicity were mutually exclusive;
> they
> are not. Take a look at Smalltalk or CLOS to s
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, 15 May 2006, Nuno Lopes wrote:
> I was not refering to the html/xhtml/xml input. I was talking about the
> charset parameter, for example. I don't want a chinese string passed as the
> charset name (the libtidy API isn't localized yet :) ). The same applies for
> the other functions.
Yeah
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
I was not refering to the html/xhtml/xml input. I was talking about the
charset parameter, for example. I don't want a chinese string passed as the
charset name (the libtidy API isn't localized yet :) ). The same applies for
the other functions.
Nuno
Are you sure want to generate a hard error
Hello Zeev,
In the same way that public readonly properties would be useful
from the global scope, protected readonly properties would be just
as useful to those of us who spend their php-lives writing base
classes (like me) for others to extend and use.
I would imagine that the Zend Fr
Are you sure want to generate a hard error if tidy_parse_string()
doesn't get an ASCII string?
-Andrei
On May 15, 2006, at 2:30 PM, Nuno Lopes wrote:
Looking only to the tidy extension:
tidy_parse_string
tidy_parse_file
tidy_repair_string
tidy_repair_file
tidy_getopt
tidy::__constructor
tidy:
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
Looking only to the tidy extension:
tidy_parse_string
tidy_parse_file
tidy_repair_string
tidy_repair_file
tidy_getopt
tidy::__constructor
tidy::parseFile
tidy::parseString
I would say that others extensions will need too. Think in charset names,
options names, options values, etc..
Nuno
That
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Zeev Suraski wrote:
> I have to say that in second thought (after realizing what you really
> meant) it sounds like a very useful feature.
[snip]
> In order to push complexity down I'd avoid making this yet another
> modifier, and in fact make thi
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
That assumes there are a hundred places where you want to receive an
ASCII string. Are they really that prevalent?
-Andrei
On May 15, 2006, at 12:42 PM, Nuno Lopes wrote:
Sorry for the delay.
But I think that a new type specifier could be introduced. If not you
are saying to extensions write
-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
Zeev Suraski wrote:
What does that give you that class constants don't?
i on the other hand fail to see how it is related to class constants
at all?
--
Hartmut Holzgraefe, Senior Support Engineer.
MySQL AB, www.mysql.com
Are you certified? http://www.mysql.com/tra
One of our customers reports that 5.1.4 fastcgi does not work, but
that 5.2 does.
It sounds like this needs to be addressed and a 5.1.5 released quickly.
--Wez.
On 5/15/06, Dmitry Stogov <[EMAIL PROTECTED]> wrote:
Hi Edin,
Most bugs were fixed before 5.1.4 release.
I tested PHP with isapi_fcgi
Sebastian Bergmann wrote:
Edin Kadribasic wrote:
OO purity/strictness do now work well with PHP's main strength -- its
dynamicity.
You make it sound like OO and dynamicity were mutually exclusive; they
are not. Take a look at Smalltalk or CLOS to see what I mean.
I know, but often the ar
Edin Kadribasic wrote:
> OO purity/strictness do now work well with PHP's main strength -- its
> dynamicity.
You make it sound like OO and dynamicity were mutually exclusive; they
are not. Take a look at Smalltalk or CLOS to see what I mean.
--
Sebastian Bergmann http://ww
Todd Ruth wrote:
I don't see benefits of making semi-static fatal that make it
worth keeping those of us with large apps that depend on semi-
static from upgrading to php6.
My sentiments exactly. OO purity/strictness do now work well with PHP's
main strength -- its dynamicity.
Edin
--
PHP I
Hello Todd,
Monday, May 15, 2006, 9:32:21 PM, you wrote:
> On Mon, 2006-05-15 at 20:27 +0200, Marcus Boerger wrote:
>> Monday, May 15, 2006, 6:03:14 PM, you wrote:
>> > On Mon, 2006-05-15 at 06:51 -0400, Greg Beaver wrote:
>> > ...
>> >> Side note: calling functions statically that do not have a
Sorry for the delay.
But I think that a new type specifier could be introduced. If not you are
saying to extensions writers to duplicate the code below a hundred times:
if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "t", &name, &name_len,
&name_type) == FAILURE) {
return;
}
if (name
On Mon, 2006-05-15 at 20:27 +0200, Marcus Boerger wrote:
> Monday, May 15, 2006, 6:03:14 PM, you wrote:
> > On Mon, 2006-05-15 at 06:51 -0400, Greg Beaver wrote:
> > ...
> >> Side note: calling functions statically that do not have a static
> >> modifier causes E_STRICT. Hello PEAR::isError()
> >>
At 21:29 15/05/2006, Stefan Esser wrote:
Zeev,
> Instead of discussing the points, we're discussing these pointless
> topics of who contributes more. I suggest we stop here, I think it's
> absurd to question the level of contribution from any of you three.
You are right. The discussion can stop
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 Stefan,
Monday, May 15, 2006, 6:32:25 PM, you wrote:
> Hello Andi,
>> I don't see why this attack is directed at Zend people working on PHP,
>> where the release process is completely a community driven effort (and
>> last time I checked, no enterprise was involved in that process either).
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
Zeev,
> Instead of discussing the points, we're discussing these pointless
> topics of who contributes more. I suggest we stop here, I think it's
> absurd to question the level of contribution from any of you three.
You are right. The discussion can stop here. Antony once again proved
every single
Hello Todd,
Monday, May 15, 2006, 6:03:14 PM, you wrote:
> On Mon, 2006-05-15 at 06:51 -0400, Greg Beaver wrote:
> ...
>> Side note: calling functions statically that do not have a static
>> modifier causes E_STRICT. Hello PEAR::isError()
>>
>> This is of course going to be a fatal in PHP 6, bu
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
Sebastian Bergmann wrote:
Now this is an unfair argument as Stefan cannot (for whatever reasons)
commit his work to cvs.php.net.
Strike that, I was educated about this on IRC just now. My initial
point is still valid to some degree, IMHO: just because Stefan's work
does not go into cvs.php.net
Stefan,
If anything, that was a good drill on why it's not a good idea to
write sarcastic, negative emails to people. Unless of course, your
aim is to annoy them into starting a heated threads. You've raised
some good points in your original email, and it's a shame you diluted
your message
Sebastian Bergmann wrote:
> Now this is an unfair argument as Stefan cannot (for whatever reasons)
> commit his work to cvs.php.net.
Strike that, I was educated about this on IRC just now. My initial
point is still valid to some degree, IMHO: just because Stefan's work
does not go into cvs.php.
I have to say that in second thought (after realizing what you really
meant) it sounds like a very useful feature.
The main thing that worries me is the complexity to the end user,
which is already in a pretty bad shape as it is today, and many
people here care very little about it, because th
> So it makes me a bit angry when someone who did nothing (except for a
> couple of mails to internals@) for PHP since December starts treating
> me and Dmitry (who's one of the most active PHP contributors) like a
> millionaires who earned their millions from poor PHP community.
Tony, you have ob
Antony Dovgal wrote:
> So it makes me a bit angry when someone who did nothing (except for a
> couple of mails to internals@) for PHP since December starts treating me
> and Dmitry (who's one of the most active PHP contributors) like a
> millionaires who earned their millions from poor PHP communit
Strike that, I was smoking something strong :) Class constants are
not really relevant for this use case.
At 20:57 15/05/2006, Zeev Suraski wrote:
I agree with Andi on that (surprise surprise :)
What does that give you that class constants don't?
Zeev
At 18:34 12/05/2006, Andi Gutmans wrot
I agree with Andi on that (surprise surprise :)
What does that give you that class constants don't?
Zeev
At 18:34 12/05/2006, Andi Gutmans wrote:
I can see where it could come in handy but I honestly think it'd be bloat.
We have to relax with the OO features because the increased code
size h
On 15.05.2006 21:17, Stefan Esser wrote:
Hello Dmitry,
It was my bug.
I am writing a lot of code for PHP and as result do some bugs.
I don't know a man who never does bugs.
Exactly. I (we) appreciate your work and the point was not that you
broke it. Like I replied to Andi, I also broke unse
On 15.05.2006 21:10, Stefan Esser wrote:
Hey Andi
My point was that this has nothing to do with Zend or not Zend.
My point is not that someone from Zend broke it, but that someone from
Zend blamed the community that THEY failed to find the problem. I
thought Zend is enough into PHP to test thei
Jared Williams wrote:
http://us3.php.net/manual/en/function.xmlwriter-write-raw.php
Anyone know the status of this function, if it does what I
want, and what version I can start using it?
I originally requested it. http://pecl.php.net/bugs/bug.php?id=6267 . I think
it'll appear in 5.2,
http:/
Hello Dmitry,
> It was my bug.
> I am writing a lot of code for PHP and as result do some bugs.
> I don't know a man who never does bugs.
>
Exactly. I (we) appreciate your work and the point was not that you
broke it. Like I replied to Andi, I also broke unserialize() in one of
the 4.3 releases
Hey Andi
> My point was that this has nothing to do with Zend or not Zend.
My point is not that someone from Zend broke it, but that someone from
Zend blamed the community that THEY failed to find the problem. I
thought Zend is enough into PHP to test their own products against RC's,
too. It makes
> -Original Message-
> From: Stefan Esser [mailto:[EMAIL PROTECTED]
> Sent: Monday, May 15, 2006 8:32 PM
> To: Andi Gutmans
> Cc: PHP internals
> Subject: Re: [PHP-DEV] PHP Release Process Sucks
>
>
> Hello Andi,
> > I don't see why this attack is directed at Zend people
> working on PH
At 09:32 AM 5/15/2006, Stefan Esser wrote:
Hello Andi,
> I don't see why this attack is directed at Zend people working on PHP,
> where the release process is completely a community driven effort (and
> last time I checked, no enterprise was involved in that process either).
Well I don't see why
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
>
> I'm on the latest and greatest PHP 5.1.4. I can see the
> function I think I want in the manual:
>
>http://us3.php.net/manual/en/function.xmlwriter-write-raw.php
>
> But the manual says it's only in CVS. I confirmed that I
> don't have it:
>
> * Fatal error: Call to undefined
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
Hello Andi,
> I don't see why this attack is directed at Zend people working on PHP,
> where the release process is completely a community driven effort (and
> last time I checked, no enterprise was involved in that process either).
Well I don't see why Zend people commit code that obviously broke
I'm on the latest and greatest PHP 5.1.4. I can see the function I
think I want in the manual:
http://us3.php.net/manual/en/function.xmlwriter-write-raw.php
But the manual says it's only in CVS. I confirmed that I don't have it:
* Fatal error: Call to undefined function xmlwriter_write_
On 15-May-06, at 11:50 AM, Stefan Esser wrote:
Hey,
The code in the release did not change on bit, the only change was
the
inclusion of the missing phar file, this hardly warrants 5.1.5 or
even
5.1.4pl1. This will have no impact of people who have already
downloaded and installed PHP, no
Stefan,
I don't see why this attack is directed at Zend people working on
PHP, where the release process is completely a community driven
effort (and last time I checked, no enterprise was involved in that
process either).
I agree the release process isn't perfect yet, and it becomes
increasi
Stefan,
Ironically
after that incident another Zend man came forward and dares to say "I
don't trust our core testers anymore"
He dared to say it because there's a QA mechanism in place that isn't
working - AKA a bunch of application developers testing Release Candidates
on their real-world
Ilia Alshanetsky wrote:
> The code in the release did not change on bit, the only change was the
> inclusion of the missing phar file, this hardly warrants 5.1.5 or even
> 5.1.4pl1. This will have no impact of people who have already downloaded
> and installed PHP, nor will this impact people who h
On Mon, 2006-05-15 at 06:51 -0400, Greg Beaver wrote:
...
> Side note: calling functions statically that do not have a static
> modifier causes E_STRICT. Hello PEAR::isError()
>
> This is of course going to be a fatal in PHP 6, but it is now the most
> common E_STRICT I see in PHP4-based code.
Y
Hey,
>
> The code in the release did not change on bit, the only change was the
> inclusion of the missing phar file, this hardly warrants 5.1.5 or even
> 5.1.4pl1. This will have no impact of people who have already
> downloaded and installed PHP, nor will this impact people who have yet
> to down
On 15-May-06, at 9:39 AM, Stefan Esser wrote:
Hello,
okay, mistakes happen everyday but it really sucks that PHP.net
continues trying to hide mistakes.
1) PHP 5.1.4 was released with a nonsense announcement claiming that
there was only a problem with POST arrays or POST fileuploads.
-> In
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
Hello,
okay, mistakes happen everyday but it really sucks that PHP.net
continues trying to hide mistakes.
1) PHP 5.1.4 was released with a nonsense announcement claiming that
there was only a problem with POST arrays or POST fileuploads.
-> In reality a paid Zend developer had destroyed the h
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
Hi Edin,
Most bugs were fixed before 5.1.4 release.
I tested PHP with isapi_fcgi.dll, mod_fastcgi and zend_enabler.
Seems all work fine, but I cannot be sure that it works in all cases.
Thanks. Dmitry.
> -Original Message-
> From: Edin Kadribasic [mailto:[EMAIL PROTECTED]
> Sent: Saturd
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 Pierre,
Monday, May 15, 2006, 2:39:02 AM, you wrote:
> On Sun, 14 May 2006 20:59:03 +0200
> [EMAIL PROTECTED] (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
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
88 matches
Mail list logo
