On Thu, 18 Dec 2003 17:55:41 -0800 (PST)
Eduardo R. Maciel [EMAIL PROTECTED] wrote:
Just checked out and compiled.
make install-pear-packages is OK for me now.
Same here. And the Stig's commit fixed the E_STRICT problem too.
Thanks for your work,
pierre
--
PHP Internals - PHP Runtime
On 18 December 2003 23:38, Andi Gutmans wrote:
At 10:17 PM 12/18/2003 +0100, Christian Schneider wrote:
I agree wholeheartedly, especially since one can set
reporting to E_ALL and
then ignore whatever one likes but with the way it is now
there is no way
of not being called for everything.
Mike Ford wrote:
How about a new optional 2nd argument to set_error_handler?
Sounds like a good idea to me. Could be the mask of errors one wants to
get in the error handler.
So one could do
set_error_handler(handler, E_ALL); # Default, current mode
set_error_handler(handler,
Did the problem end up being due to zend_execute.c 1.566 patch?
Within the zend_assign_to_object function, the temp variable needs to be
free'd, otherwise it needs to be handled within the extensions themselves.
Not sure about the other functions in that patch as I only ran into issues
with this
At 10:38 AM 12/19/2003 +, Ford, Mike [LSS] wrote:
On 18 December 2003 23:38, Andi Gutmans wrote:
At 10:17 PM 12/18/2003 +0100, Christian Schneider wrote:
I agree wholeheartedly, especially since one can set
reporting to E_ALL and
then ignore whatever one likes but with the
At 12:00 PM 12/19/2003 +0100, Christian Schneider wrote:
Mike Ford wrote:
How about a new optional 2nd argument to set_error_handler?
Sounds like a good idea to me. Could be the mask of errors one wants to
get in the error handler.
So one could do
set_error_handler(handler, E_ALL);# Default,
At 06:44 AM 12/19/2003 -0500, Rob Richards wrote:
Did the problem end up being due to zend_execute.c 1.566 patch?
Within the zend_assign_to_object function, the temp variable needs to be
free'd, otherwise it needs to be handled within the extensions themselves.
Not sure about the other functions
On Fri, Dec 19, 2003 at 10:38:00AM -, Ford, Mike [LSS] wrote:
How about a new optional 2nd argument to set_error_handler?
But then scripts written with the proposed second argument will not be
backwards compatable.
I like the idea put forth earlier about only calling custom
On Fri, 19 Dec 2003, Daniel Convissor wrote:
On Fri, Dec 19, 2003 at 10:38:00AM -, Ford, Mike [LSS] wrote:
How about a new optional 2nd argument to set_error_handler?
But then scripts written with the proposed second argument will not be
backwards compatable.
It is when
On Fri, Dec 19, 2003 at 03:20:17PM +0100, Derick Rethans wrote:
On Fri, 19 Dec 2003, Daniel Convissor wrote:
But then scripts written with the proposed second argument will not be
backwards compatable.
It is when it's optional and the default is the current behavior.
Pardon me. Looks
Daniel Convissor wrote:
On Fri, Dec 19, 2003 at 03:20:17PM +0100, Derick Rethans wrote:
It is when it's optional and the default is the current behavior.
Pardon me. Looks like PHP 3 behavior is still stuck in my brain...
No, you were right. A script using
set_error_handler(handler,
On Fri, 19 Dec 2003, Christian Schneider wrote:
Daniel Convissor wrote:
On Fri, Dec 19, 2003 at 03:20:17PM +0100, Derick Rethans wrote:
It is when it's optional and the default is the current behavior.
Pardon me. Looks like PHP 3 behavior is still stuck in my brain...
No, you were
On Fri, Dec 19, 2003 at 04:00:34PM +0100, Derick Rethans wrote:
Don't worry about this, as PHP wasnever really forwards compatible
anyway.
I, and lots of people, need to worry about it. I write code that uses
PHP. Much of it is for general public consumption. Some is for sale at
Daniel Convissor wrote:
I, and lots of people, need to worry about it. I write code that uses
I second that.
Adding an optional argument has the worst of both worlds. In order to
take advantage of it, one must lock your code into PHP 5.
In this specific case I can live with an optional
On 2003/12/20, at 0:21, Dmitry Stogov wrote:
Hi Moriyoshi,
Yes I am sure. Andi approved this patch today.
I didn't know about your patch.
May be you know some situations when my patch will not work properly?
As far as I looked over the patch, your patch appears the right fix for
the problem. I
Christian Schneider wrote:
Daniel Convissor wrote:
Adding an optional argument has the worst of both worlds. In order to
take advantage of it, one must lock your code into PHP 5.
It doesn't work this way in PHP4 anyway. So if you really must use this
feature (I think I would) you can live
On Fri, Dec 19, 2003 at 06:06:40PM +0200, Lenar Lõhmus wrote:
It doesn't work this way in PHP4 anyway. So if you really must use this
feature (I think I would) you can live with being locked to PHP5.
But then in order to have an error handler work in both PHP 5 and PHP 4
while avoiding the
On Fri, 19 Dec 2003, Lenar [ISO-8859-1] Lõhmus wrote:
Christian Schneider wrote:
Daniel Convissor wrote:
Adding an optional argument has the worst of both worlds. In order to
take advantage of it, one must lock your code into PHP 5.
It doesn't work this way in PHP4 anyway. So if you
Lenar Lõhmus wrote:
But it's not good either stopping my error_handler from being called in PHP5
accordingly to error_reporting() value. This way I might not notice my
error handler isn't getting all calls it used to (depends on conf). So IMHO
silent behavior change is still worse.
Ok, now
On 2003/12/20, at 1:36, Dmitry Stogov wrote:
I do GC after error_handler execution, because GC stack has limited
size
and if I will try to link old garbage with garbage from error_handler I
can overflow it.
Okay, so it seems my patch was not sufficient as it's still possible
GC stack will
Christian Schneider wrote:
Ok, now realistically, how many people use error handlers, have
error_reporting != E_ALL *AND* expect their handler to be called for
E_ALL *AND* aren't savvy enough to simple set error_reporting to E_ALL?
Even though I'm not one of them I'm told there are people who
Lenar Lõhmus wrote:
by their creators waiting to be downloaded. That script/project could use
custom error handlers and could somehow depend on PHP4's behaviour. You
never know.
My guess of the chance that this happens? I'd say about 1:2^42. This
script working without changes with PHP5? About
On Fri, 19 Dec 2003, Christian Schneider wrote:
Why make life harder for 99.99% of the PHP users for this one
hypothetical case? I think we're doing mental masturbation instead of
simply fixing broken behaviour.
What in your world is broken behavior might be a feature for somebody
else.
On Fri, 19 Dec 2003, Christian Schneider wrote:
My guess of the chance that this happens? I'd say about 1:2^42. This
script working without changes with PHP5? About 1:2^64738. And a web
hosting company with customers like that upgrading to PHP5 anytime soon?
About 1:2^64.
Do you have any
At 17:13 19/12/2003, Daniel Convissor wrote:
On Fri, Dec 19, 2003 at 04:00:34PM +0100, Derick Rethans wrote:
Don't worry about this, as PHP wasnever really forwards compatible
anyway.
I, and lots of people, need to worry about it. I write code that uses
PHP. Much of it is for general public
Derick Rethans wrote:
What in your world is broken behavior might be a feature for somebody
else.
I do *not* want to remove a feature, I want to add one which is missing
badly!
Do you actually _read_ what people write? *sigh*
Do you have any hard data to back those numbers up?
My sentence
Zeev Suraski wrote:
argument makes a great deal of sense. As a matter of fact, in practice
- you can easily get forward-compatibility. Just supply it in both PHP
4 and 5 - extra arguments are ignored anyway (just provide @ to make
sure of that).
Just checked it and no: set_error_handler does
Hello internals,
The following code produces segfault using snapshot php5-200312191230.
?php
class A implements ArrayAccess
{
private $array = array();
public function offsetExists( $offset )
{
return isset( $this-array[ $offset ] );
}
public function
Christian Schneider wrote:
Just checked it and no: set_error_handler does _not_ ignore the
additional parameter, it fails and does _not_ install the handler on
PHP4. Leave out E_ALL and it works like a charm. Am I missing something
here?
Script used to test:
function handler()
{
On Fri, Dec 19, 2003 at 08:15:15PM +0200, Zeev Suraski wrote:
You may very well shut all errors off in
production code, and rely on everything going through your error
handler.
That already happens in ALL code which utilizes user defined error
processing. Once a custom error handler is
I am the genral manager of AA GrouP.
and I want to do something the arab nobody else in the arabian world did it
and Developing the PHP runtime
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Fri, Dec 19, 2003 at 08:49:10PM +0100, Andrey Hristov wrote:
So the code with @ is working. The set_error_handler() is bailing out
and everything is ok
No, the erorr handler isn't being called and that's not okay.
--Dan
--
T H E A N A L Y S I S A N D S O L U T I O N S C O M P A
On Fri, Dec 19, 2003 at 03:48:23PM -0500, John Coggeshall wrote:
I don't really see the issue with PHP 5 code not being able to be ran in
PHP4. If that's the case, let's throw out all of the ZE2 OO stuff too
because that's not PHP 4 compatible either.
:)
In the LONG term, rewriting
On Fri, Dec 19, 2003 at 03:50:42PM -0500, John Coggeshall wrote:
I think trying to stop an improvement because it's not PHP 4 compatible
is a mistake.
We're not trying to stop an improvement, we're trying to define exactly
how to improve it.
--Dan
--
T H E A N A L Y S I S A N D S
Daniel Convissor wrote:
On Fri, Dec 19, 2003 at 08:49:10PM +0100, Andrey Hristov wrote:
So the code with @ is working. The set_error_handler() is bailing out
and everything is ok
No, the erorr handler isn't being called and that's not okay.
--Dan
Well, you could simply do like
On Fri, Dec 19, 2003 at 09:55:22PM +0100, Michael Walter wrote:
set_error_handler('foo');
@set_error_handler('foo', E_ALL);
Nice!
None the less, this wouldn't resolve the situation where loads of object
oriented code all of a sudden starts spewing var depricated messages.
Not fun.
--Dan
At 12:54 AM 12/20/2003 +0900, Moriyoshi Koizumi wrote:
On 2003/12/20, at 0:21, Dmitry Stogov wrote:
Hi Moriyoshi,
Yes I am sure. Andi approved this patch today.
I didn't know about your patch.
May be you know some situations when my patch will not work properly?
As far as I looked over the
At 03:59 PM 12/19/2003 -0500, Daniel Convissor wrote:
On Fri, Dec 19, 2003 at 09:55:22PM +0100, Michael Walter wrote:
set_error_handler('foo');
@set_error_handler('foo', E_ALL);
Nice!
None the less, this wouldn't resolve the situation where loads of object
oriented code all of a sudden starts
On Sat, Dec 20, 2003 at 12:13:45AM +0200, Andi Gutmans wrote:
At 03:59 PM 12/19/2003 -0500, Daniel Convissor wrote:
None the less, this wouldn't resolve the situation where loads of object
oriented code all of a sudden starts spewing var depricated messages.
Not fun.
Those messages don't
At 05:29 PM 12/19/2003 -0500, Daniel Convissor wrote:
On Sat, Dec 20, 2003 at 12:13:45AM +0200, Andi Gutmans wrote:
At 03:59 PM 12/19/2003 -0500, Daniel Convissor wrote:
None the less, this wouldn't resolve the situation where loads of object
oriented code all of a sudden starts spewing var
On Sat, Dec 20, 2003 at 12:31:31AM +0200, Andi Gutmans wrote:
Yeah but in PHP 5 you have the extra argument. It's no problem to make the
PHP 4 script use this.
This and your last post are rehasing points I've already debunked a few
times in this thread.
--Dan
--
T H E A N A L Y S I S
At 20:28 19/12/2003, Christian Schneider wrote:
Zeev Suraski wrote:
argument makes a great deal of sense. As a matter of fact, in practice -
you can easily get forward-compatibility. Just supply it in both PHP 4
and 5 - extra arguments are ignored anyway (just provide @ to make sure
of that).
At 21:02 19/12/2003, Daniel Convissor wrote:
On Fri, Dec 19, 2003 at 08:15:15PM +0200, Zeev Suraski wrote:
You may very well shut all errors off in
production code, and rely on everything going through your error
handler.
That already happens in ALL code which utilizes user defined error
On Fri, 19 Dec 2003, Daniel Convissor wrote:
On Sat, Dec 20, 2003 at 12:31:31AM +0200, Andi Gutmans wrote:
Yeah but in PHP 5 you have the extra argument. It's no problem to make the
PHP 4 script use this.
This and your last post are rehasing points I've already debunked a few
times in
Andi Gutmans wrote:
Anyway, I very strongly feel that an additional optional argument to
set_error_handler() is the right way to go.
Let's go this way!
A patch for PHP5 accomplishing this can be found at:
http://cschneid.com/php/php5/set_error_handler_reporting_parameter.patch
- Chris
--
PHP
On Sat, Dec 20, 2003 at 12:51:15AM +0100, Derick Rethans wrote:
As another guy said lets nominate him as the mlemos of the quarter
Derick, I guess this inside joke comparing me to Manuel is meant as some
sort of insult. Doesn't reflect well on you, or the PHP development
community.
--Dan
--
On Sat, Dec 20, 2003 at 01:06:25AM +0200, Zeev Suraski wrote:
Sure there is. You may shut off (or otherwise configure) error reporting
site-wide, or application-wide, whereas you'd use the error handler only in
parts of the app/site.
Oh, I see what you mean. Yeah, problems would be caused
FYI, if you put the word premier in front of the URL, you will get
much faster download speeds. Anytime you see a URL with
download.microsoft.com you can almost always change it to
premierdownload.microsoft.com and get much faster speeds.
-Jeremy
On Tue, 2003-12-16 at 22:40, Daniel Convissor
48 matches
Mail list logo
