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 Conviss
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 caus
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
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 Int
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
> t
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
pr
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).
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 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 v
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 message
Hey,
Please grab RC2 from http://snaps.php.net/~andi.
I hope the critical problem we were having is solved now.
There are still some open engine bugs which need to be fixed but they
aren't critical.
Please let me know if there are any showstoppers. If not I'll post it tomorrow.
Also, please don'
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 start
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 patc
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
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
set_error_ha
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
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 appl
On Fri, 2003-12-19 at 10:13, Daniel Convissor wrote:
> 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
> significant cost. I have to write stuff once and have it work anywhere.
If you are concerned a
On Fri, 2003-12-19 at 09:43, Christian Schneider wrote:
> No, you were right. A script using
> set_error_handler("handler", error_reporting());
> will get "Wrong parameter count for set_error_handler()" for PHP4.
I don't really see the issue with PHP 5 code not being able to be ran in
PHP4. If tha
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
Daniel Convissor wrote:
Just supply it in both PHP 4 and 5 - extra arguments are ignored anyway
Nope...
CODE
echo phpversion();
set_error_handler('error_handler', 0);
function error_handler($code, $text) {
echo "Handled... $text";
}
$x;
OUTPUT
--
4.3.4
Warning: Wrong parameter
I am the genral manager of A&A 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: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
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()
> {
>
Hello internals,
The following code produces segfault using snapshot php5-200312191230.
array[ $offset ] );
}
public function offsetGet( $offset )
{
return $this->array[ $offset ];
}
public function offsetSet( $offset, $data )
{
$this->array[ $offset
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 _
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 star
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
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
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.
De
On Fri, Dec 19, 2003 at 07:02:49PM +0200, Lenar Lõhmus wrote:
> Now there
> are plenty of PHP scripts and projects just sitting somewhere but abandoned
> by their creators waiting to be downloaded. That script/project could use
> custom error handlers and could somehow depend on PHP4's behaviour.
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 1:2
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 w
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 overflo
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 realisti
> Please provide a real world example of why you would need version compare.
I wouldn't :)
> Error handlers written for PHP 4 (expecting that all errors will go to the
> handler) will operate just fine under the new system (where only errors
> meeting the error reporting mask get sent to the handl
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. S
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
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 liv
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 a
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 argument
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
signific
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
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", error_report
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.
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
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
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 i
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 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 th
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 f
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", error_reporting
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 everythi
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 Runtim
54 matches
Mail list logo
