[PHP-DEV] Feature request: ini setting for http 500 on fatal errors

2006-10-19 Thread Evert | Rooftop
Excuse me if this has been discussed before, but I would like to know the stance on this issue, it's hard to search the buglist or mailing archives on stuff like http, 500 and fatal. Would it be hard to implement an ini setting for throwing a http 500 error on a fatal error? It's hard to make

Re: [PHP-DEV] Feature request: ini setting for http 500 on fatal errors

2006-10-19 Thread Rasmus Lerdorf
Evert | Rooftop wrote: Excuse me if this has been discussed before, but I would like to know the stance on this issue, it's hard to search the buglist or mailing archives on stuff like http, 500 and fatal. Would it be hard to implement an ini setting for throwing a http 500 error on a fatal e

Re: [PHP-DEV] Feature request: ini setting for http 500 on fatal errors

2006-10-19 Thread Evert | Rooftop
Thats a smart idea.. I like that As for letting PHP do the 500, I tend to use output buffering everywhere (i think most people do, supposed to be faster too) so I'm used to setting header()'s wherever I need them.. Besides, in most of my script the business logic gets executed first, and thi

Re: [PHP-DEV] Feature request: ini setting for http 500 on fatal errors

2006-10-19 Thread Brian Moon
Evert | Rooftop wrote: Thats a smart idea.. I like that As for letting PHP do the 500, I tend to use output buffering everywhere (i think most people do, supposed to be faster too) so I'm used to setting header()'s wherever I need them.. You think wrong. There are very good reasons not to u

Re: [PHP-DEV] Feature request: ini setting for http 500 on fatal errors

2006-10-19 Thread Evert | Rooftop
Brian Moon wrote: Evert | Rooftop wrote: Thats a smart idea.. I like that As for letting PHP do the 500, I tend to use output buffering everywhere (i think most people do, supposed to be faster too) so I'm used to setting header()'s wherever I need them.. You think wrong. There are very go

[PHP-DEV] a last plead

2006-10-19 Thread Lukas Kahwe Smith
Hi, I just want to say once again that all hell is going to break loose once we release 5.2.0 as stable thanks to the various fatal errors we are adding for perfectly working code that breaks OO theory. I am talking about this change: http://marc.theaimsgroup.com/?l=php-dev&m=114734977430980&

[PHP-DEV] Re: a last plead

2006-10-19 Thread Pierre
On Thu, 19 Oct 2006 23:26:42 +0200 [EMAIL PROTECTED] (Lukas Kahwe Smith) wrote: > Hi, > > I just want to say once again that all hell is going to break loose > once we release 5.2.0 as stable thanks to the various fatal errors we > are adding for perfectly working code that breaks OO theory. > >

[PHP-DEV] Cannot login to CVS Server.

2006-10-19 Thread sakamoto
I proposed PEAR package, and accepted by PEPr. The following links are the packages accepted: http://pear.php.net/pepr/pepr-proposal-show.php?id=441 And, I send "CVS Account Request: kouichi66" at 2006/10/12. But, I cannot login to CVS Server. I want to know why cannot login. - I yet do not get

[PHP-DEV] Random PHP crash in erealloc()

2006-10-19 Thread Gwynne
I'm experiencing a strange random crash in PHP 5.1.4 and 5.1.6 triggered by several separate sections of code under a number of circumstances. I can't narrow it down much, but the backtrace always ends with: (gdb) bt #0 0x081f80fe in _erealloc (ptr=0x8531b44, size=2, allow_failure=0) at

Re: [PHP-DEV] Cannot login to CVS Server.

2006-10-19 Thread Pierre
Hello, On 10/20/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: I proposed PEAR package, and accepted by PEPr. The following links are the packages accepted: http://pear.php.net/pepr/pepr-proposal-show.php?id=441 And, I send "CVS Account Request: kouichi66" at 2006/10/12. But, I cannot login t

[PHP-DEV] PHP 5.2.0RC6 Released!

2006-10-19 Thread Ilia Alshanetsky
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 One more RC, of PHP 5.2.0 is out, hopefully it'll be the last, but past experience is not proving to be promising. The RC can be downloaded from here: http://downloads.php.net/ilia/ php-5.2.0RC6.tar.bz2 (md5: 5a146c08f85d8535c76fe6219281a06e).

[PHP-DEV] Memcache session handler

2006-10-19 Thread Glenn Richmond
Hi all, I've just been implementing a memcache session handler that allows for multiple servers in a cluster to store their session data in a central place. I had to make the changes in the PHP source as the user session handler doesn't quite work properly (it wipes the references to the PHP funct

Re: [PHP-DEV] a last plead

2006-10-19 Thread Christian Stocker
On 19.10.2006 23:26 Uhr, Lukas Kahwe Smith wrote: > Hi, > > I just want to say once again that all hell is going to break loose once > we release 5.2.0 as stable thanks to the various fatal errors we are > adding for perfectly working code that breaks OO theory. > > Now is the time to fix this

Re: [PHP-DEV] a last plead

2006-10-19 Thread Glenn Richmond
Hmm, this is interesting - I just joined the mailing list, but I can relate to this. I've come across a piece of code in that has the following line in a function within a class: return $this; It seems to cause an over-allocation of memory and ultimately a seg fault in both 5.1.4 and 5.2rc4, but

Re: [PHP-DEV] a last plead

2006-10-19 Thread Jasper Bryant-Greene
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Glenn, 'return $this' is perfectly acceptable and indeed very common code. It works fine for me in 5.1.4 - you might like to report a bug if you can reproduce a segfault... What is being referred to here is things like 'abstract static' functions t

Re: [PHP-DEV] a last plead

2006-10-19 Thread Glenn Richmond
ok, sure. I'll be working to get more information on this one. I should have said that the line of code where it crashes is called constantly. It's part of a parent class and is almost the most called code in the system. It's only when it's called via the SOAP interface for a particular SOAP functi