At 01:00 AM 2/5/2004 +0100, Marcus Boerger wrote:
> If it's a PHP-style object, then you can use zend_objects_destroy_object as
> your destructor callback (when calling zend_objects_store_put()), in which
> case __destruct() will be called. That's how the regular PHP objects
do it.
So my guess i
maintaining opendirectory extension
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hello Zeev,
Thursday, February 5, 2004, 12:24:47 AM, you wrote:
> At 23:45 04/02/2004, Andrei Zmievski wrote:
>>On Wed, 04 Feb 2004, Andi Gutmans wrote:
>> > 3. The APIs have changed to allow for this new mechanism. Instead of the
>> > previous dtor callback, which was supposed to both call the
I submitted a fix for this (as I suspected, it appears to be more of a bug
in zend_call_function() than a bug in the new exceptions mechanism)... I'm
not 100% sure about this fix as I didn't have time to investigate it too
much, but it appears to be correct, and I wanted to allow you to go on
At 00:29 05/02/2004, Marcus Boerger wrote:
The new exception implementation looks a bit nicer but needs some
tweaks. Try this code:
A bit? It's a helluva lot nicer :)
php -r 'reflection_class::export("xyz");'
which dirctly segfaults. What happens is that the class xyz does not exist
and reflectio
At 23:45 04/02/2004, Andrei Zmievski wrote:
On Wed, 04 Feb 2004, Andi Gutmans wrote:
> 3. The APIs have changed to allow for this new mechanism. Instead of the
> previous dtor callback, which was supposed to both call the destructor and
> free the object's storage, there are now two separate call
In our SAPI cgi we have a check along these lines:
if (getenv("SERVER_SOFTWARE")
|| getenv("SERVER_NAME")
|| getenv("GATEWAY_INTERFACE")
|| getenv("REQUEST_METHOD")) {
cgi = 1;
}
if(!cgi) getopt(...)
As in, we do not parse command line args for the cgi
Marcus Boerger wrote:
> helly Wed Feb 4 17:19:00 2004 EDT
>
> Modified files:
> /ZendEngine2 zend_reflection_api.c
> Log:
> Fix reflection
That commit makes PHPUnit work again as it fixes the segfault I reported
earlier.
Thank you!
--
Sebastian Bergmann
http://seba
Hello Andi,
Tuesday, February 3, 2004, 2:01:12 PM, you wrote:
> Hi,
> We rewrote the exception support. It fixes a few limitations and bugs in
> the old implementation, and allows exceptions to 'fire' much earlier than
> before.
> Generally, with the new mechanism, you're not supposed to touc
On 2/4/2004 4:13 PM, Rasmus Lerdorf wrote:
On Wed, 4 Feb 2004, Joe Estock wrote:
On 2/4/2004 3:12 PM, Rasmus Lerdorf wrote:
Is it me or does -d no longer work in 4.3? To test:
php -d "track_errors=1" -i | grep track
(assuming you have it off in your php.ini)
Works fine for me in 4.3.2 but
On Wed, Feb 04, 2004 at 02:13:59PM -0800, Rasmus Lerdorf wrote:
> On Wed, 4 Feb 2004, Joe Estock wrote:
>
> > On 2/4/2004 3:12 PM, Rasmus Lerdorf wrote:
> > > Is it me or does -d no longer work in 4.3? To test:
> > >
> > > php -d "track_errors=1" -i | grep track
> > >
> > > (assuming you have
On Wed, 4 Feb 2004, Joe Estock wrote:
> On 2/4/2004 3:12 PM, Rasmus Lerdorf wrote:
> > Is it me or does -d no longer work in 4.3? To test:
> >
> > php -d "track_errors=1" -i | grep track
> >
> > (assuming you have it off in your php.ini)
> >
> > Works fine for me in 4.3.2 but looks quite bro
Hello Joe,
Wednesday, February 4, 2004, 10:40:10 PM, you wrote:
> On 2/4/2004 3:12 PM, Rasmus Lerdorf wrote:
>> Is it me or does -d no longer work in 4.3? To test:
>>
>> php -d "track_errors=1" -i | grep track
>>
>> (assuming you have it off in your php.ini)
>>
>> Works fine for me in 4.3.2
On 2/4/2004 3:12 PM, Rasmus Lerdorf wrote:
Is it me or does -d no longer work in 4.3? To test:
php -d "track_errors=1" -i | grep track
(assuming you have it off in your php.ini)
Works fine for me in 4.3.2 but looks quite broken in 4.3.4. Anybody play
around in that code?
-Rasmus
Works fine
At 01:37 PM 2/4/2004 -0800, Andrei Zmievski wrote:
On Wed, 04 Feb 2004, Zeev Suraski wrote:
> (a) Failure return value of FETCH_RESOURCE and the default return value -
> should we change it to be FALSE? Today it's NULL, which is inconsistent
> with most of the functions in PHP which return FALSE o
Hi Andi,
Andi Gutmans wrote:
> [...]
>
> This has several implications:
>
> [...]
>
> 2. A *VERY* important implication is that you cannot, and must not
rely in any way on the order of destruction during shutdown. It runs in
no particular order. That means that by the time the destructor for
On Wed, 04 Feb 2004, Andi Gutmans wrote:
> 3. The APIs have changed to allow for this new mechanism. Instead of the
> previous dtor callback, which was supposed to both call the destructor and
> free the object's storage, there are now two separate callbacks - dtor
> (call the destructor) and
On Wed, 04 Feb 2004, Zeev Suraski wrote:
> (a) Failure return value of FETCH_RESOURCE and the default return value -
> should we change it to be FALSE? Today it's NULL, which is inconsistent
> with most of the functions in PHP which return FALSE on failure. The
> downside is that changing it m
Hello Andi,
Wednesday, February 4, 2004, 10:15:35 PM, you wrote:
> At 09:53 PM 2/4/2004 +0100, Marcus Boerger wrote:
>>Hello Zeev,
>>
>>Wednesday, February 4, 2004, 7:20:47 PM, you wrote:
>>
>> > Hey,
>>
>> > As you must have realized Andi and I have resolved some of the key
>> > remaining issues
At 09:53 PM 2/4/2004 +0100, Marcus Boerger wrote:
Hello Zeev,
Wednesday, February 4, 2004, 7:20:47 PM, you wrote:
> Hey,
> As you must have realized Andi and I have resolved some of the key
> remaining issues for PHP 5 (and we still are).
> Due to fact that some of these changes have been pretty
Is it me or does -d no longer work in 4.3? To test:
php -d "track_errors=1" -i | grep track
(assuming you have it off in your php.ini)
Works fine for me in 4.3.2 but looks quite broken in 4.3.4. Anybody play
around in that code?
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing
Hello Zeev,
Wednesday, February 4, 2004, 7:20:47 PM, you wrote:
> Hey,
> As you must have realized Andi and I have resolved some of the key
> remaining issues for PHP 5 (and we still are).
> Due to fact that some of these changes have been pretty big changes we
> suggest to turn the RC1 we wan
On Wed, 2004-02-04 at 15:11, Zeev Suraski wrote:
> At 22:12 04/02/2004, Steph wrote:
>
> > > (b) Default inclusion of the SOAP extension
> >
> >That word 'default' kinda muddies the issue - are you suggesting that SOAP
> >is included in distributions, or are you suggesting that it should be
> >ena
On February 04, 2004 03:28 pm, Sterling Hughes wrote:
> > So today you have places that require you to do:
> > $ret = func_call();
> > if ($ret !== NULL && $ret !== false)
>
> or
>
> if ($ret)
That's not always possible since the function could return 0 or "" and trigger
an error conditi
> Hello Andi,
>
> i brought the fact up nearly a year ago and i very much appreciate
> the simple solution of changing the return value. Since the old way
> is bork anyways i am all fine (+1). One of the most annoying problems is
> that several function force you to test against NULL and FALSE.
>
Zeev Suraski wrote:
At 22:12 04/02/2004, Steph wrote:
> (b) Default inclusion of the SOAP extension
That word 'default' kinda muddies the issue - are you suggesting that
SOAP
is included in distributions, or are you suggesting that it should be
enabled by default?
I think we should consider b
Zeev Suraski wrote:
> At 22:12 04/02/2004, Steph wrote:
>
>> > (b) Default inclusion of the SOAP extension
>>
>> That word 'default' kinda muddies the issue - are you suggesting that
>> SOAP
>> is included in distributions, or are you suggesting that it should be
>> enabled by default?
>
> I think
Hello Andi,
i brought the fact up nearly a year ago and i very much appreciate
the simple solution of changing the return value. Since the old way
is bork anyways i am all fine (+1). One of the most annoying problems is
that several function force you to test against NULL and FALSE.
NULL for all t
At 22:12 04/02/2004, Steph wrote:
> (b) Default inclusion of the SOAP extension
That word 'default' kinda muddies the issue - are you suggesting that SOAP
is included in distributions, or are you suggesting that it should be
enabled by default?
I think we should consider both.
Zeev
--
PHP Inter
On Wed, 4 Feb 2004 13:45:50 -0500
[EMAIL PROTECTED] (Ilia Alshanetsky) wrote:
> > (b) Default inclusion of the SOAP extension
>
> +0. Overall it seems like a good idea. However, I am not sure how
> stable is SOAP extension after massive revisions Dmitry did and the
> TODO list still has quite a f
> (b) Default inclusion of the SOAP extension
That word 'default' kinda muddies the issue - are you suggesting that SOAP
is included in distributions, or are you suggesting that it should be
enabled by default?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http:
On 2/4/2004 12:20 PM, Zeev Suraski wrote:
Hey,
As you must have realized Andi and I have resolved some of the key
remaining issues for PHP 5 (and we still are).
Due to fact that some of these changes have been pretty big changes we
suggest to turn the RC1 we wanted to release at the end of Janu
On Wed, 4 Feb 2004 20:46:57 +0100
[EMAIL PROTECTED] (Pierre-Alain Joye) wrote:
> It is a problem (afaics) for:
> - foreach
> - reflection
> - dump functions
>
> Btw, in the same topic, are the $foo->bar++; bug is solved too?
are the $foo->bar++; and friends (+=, -=, ...) solved too?
pierre
--
On Wed, 04 Feb 2004 21:37:11 +0200
[EMAIL PROTECTED] (Andi Gutmans) wrote:
> Quite a problem, no doubt. The question is, should we expect every
> overloaded object to be able to give its properties as a hash? (I
> guess it could return an empty one).
> Pierre, is the problem only with foreach()?
> > (a) Failure return value of FETCH_RESOURCE and the default return
value -
> > should we change it to be FALSE? Today it's NULL, which is inconsistent
> > with most of the functions in PHP which return FALSE on failure. The
> > downside is that changing it may break scripts that check the retu
At 02:33 PM 2/4/2004 -0500, Sterling Hughes wrote:
> >http://marc.theaimsgroup.com/?l=php-dev&m=107367078904900&w=2
> >
> >The main problem with a too early beta/rc release is we (well you ;) )
> >have to be sure that the ZE2 apis works the way it should. And not only
> >from the php side. For the
> >http://marc.theaimsgroup.com/?l=php-dev&m=107367078904900&w=2
> >
> >The main problem with a too early beta/rc release is we (well you ;) )
> >have to be sure that the ZE2 apis works the way it should. And not only
> >from the php side. For the good all php extensions that are not bundled
> >wit
At 07:55 PM 2/4/2004 +0100, Pierre-Alain Joye wrote:
> A couple of issues we'd like to decide onbefore we go out with beta 4
> are:
One "issue" I would like to put in the light again. The internal ZE
2 APIs. One "issue" here:
http://marc.theaimsgroup.com/?l=php-dev&m=107367078904900&w=2
The main p
> Due to fact that some of these changes have been pretty big changes we
> suggest to turn the RC1 we wanted to release at the end of January to a
> beta 4 by the end of next week.
> If everything goes smoothly after that, we think RC1 should follow two
> weeks later.
+1 on beta 4.
2 weeks from
On Wed, 04 Feb 2004 20:20:47 +0200
Zeev Suraski <[EMAIL PROTECTED]> wrote:
> Hey,
>
> As you must have realized Andi and I have resolved some of the key
> remaining issues for PHP 5 (and we still are).
> Due to fact that some of these changes have been pretty big changes we
>
> suggest to turn
The snippet you sent works fine here (errors out with Fatal error: Class
'gdObject' not found in C:\Projects\php5\tests\testcase.php on line 2).
Judging by your trace, either it's a bigger piece of code that really
throws an exception (in which case, please send me a reproducing test
case), or
Zeev Suraski wrote:
> Try now.
Yes, it's back to segfaulting now ;-)
--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://phpOpenTracker.de/
Das Buch zu PHP 5: http://professionelle-softwareentwicklung-mit-php5.de/
--
PHP Internals - PHP Runtime Development Mailing L
> (a) Failure return value of FETCH_RESOURCE and the default return value -
> should we change it to be FALSE? Today it's NULL, which is inconsistent
> with most of the functions in PHP which return FALSE on failure. The
> downside is that changing it may break scripts that check the return value
On Wed, 2004-02-04 at 13:36, Adam Maccabee Trachtenberg wrote:
> > (b) Default inclusion of the SOAP extension
> +1, Definitely.
Ditto on that and B4... However I do question the 2 week timeline
between the two, seems a bit short..
John
--
-=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~
On Wed, 4 Feb 2004, Zeev Suraski wrote:
> Due to fact that some of these changes have been pretty big changes we
> suggest to turn the RC1 we wanted to release at the end of January to a
> beta 4 by the end of next week.
I am glad we're doing another beta. There's still more than enough
outstandi
Not quite... if it did, something else broke because now I get a
Segfault:
#0 0x403247cc in zend_throw_exception_internal (exception=0x0,
tsrm_ls=0x81aa958)
at /home/john/working/php-src/Zend/zend_execute_API.c:1205
#1 0x403236e3 in zend_call_function (fci=0xbfffe9f0,
fci_cache=0xbfffe9
On Feb 4, 2004, at 1:20 PM, Zeev Suraski wrote:
(b) Default inclusion of the SOAP extension
I'm +1 for this. It seems to have been making rapid progression and
it's an important technology to make easy to access.
George
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, vi
Fixed.
Zeev
At 20:02 04/02/2004, John Coggeshall wrote:
I'm still getting that for an abstract class:
Fatal error: Invalid binding type in
/web/php5/sandbox/adv_gd/classes/gdFontObject.class.php on line 12
abstract class gdFontObject extends gdObject implements
gdFontInterface {
/* C
> Hey,
>
> (a) Failure return value of FETCH_RESOURCE and the default return value -
> should we change it to be FALSE? Today it's NULL, which is inconsistent
> with most of the functions in PHP which return FALSE on failure. The
> downside is that changing it may break scripts that check the
Hey,
As you must have realized Andi and I have resolved some of the key
remaining issues for PHP 5 (and we still are).
Due to fact that some of these changes have been pretty big changes we
suggest to turn the RC1 we wanted to release at the end of January to a
beta 4 by the end of next week.
I
I'm still getting that for an abstract class:
Fatal error: Invalid binding type in
/web/php5/sandbox/adv_gd/classes/gdFontObject.class.php on line 12
abstract class gdFontObject extends gdObject implements
gdFontInterface {
/* Catch API differences for methods beyond the int
Hello,
Can you please confirm the behaviour of PHP in caching results of
file_exists and similar functions, please?
Related with bug #27134 (http://bugs.php.net/?id=27134)
Thanks,
Nuno
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
The new implementation of exception mechanism solves the problem with __get and
__toString, but throwing an exception within __set results in a segmentation fault.
Stephane
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Try now.
Zeev
At 18:55 04/02/2004, Sebastian Bergmann wrote:
Zeev Suraski wrote:
> zeev Wed Feb 4 11:30:17 2004 EDT
>
> Modified files:
> /ZendEngine2 zend_compile.c zend_compile.h zend_execute.c
> zend_execute.h zend_execute_API.c
>
At 18:55 04/02/2004, Sebastian Bergmann wrote:
Zeev Suraski wrote:
> zeev Wed Feb 4 11:30:17 2004 EDT
>
> Modified files:
> /ZendEngine2 zend_compile.c zend_compile.h zend_execute.c
> zend_execute.h zend_execute_API.c
> zend_language_
Zeev Suraski wrote:
> zeev Wed Feb 4 11:30:17 2004 EDT
>
> Modified files:
> /ZendEngine2 zend_compile.c zend_compile.h zend_execute.c
> zend_execute.h zend_execute_API.c
> zend_language_parser.y
> Log:
> Reinstate early-binding f
LOL! :) "... Zeev Suraski wrote..."
On Wed, 2004-02-04 at 09:26, Zeev Suraski wrote:
> Forgot we were in Frankfurt together in 2002? :)
>
> Andi
--
-=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=-
John Coggeshall http://www.coggeshall.org/
The PHP Developer's Handb
Sorry, no time to work on a short, reproducing script -- PHPUnit is
quite complex:
()
zend_objects_store_del_ref(_zval_struct * 0x00fca118, void * * *
0x00db4330) line 139 + 18 bytes
_zval_dtor(_zval_struct * 0x00fca118, char * 0x104fa6d0 `string', unsigned
int 360) line 61 + 19 bytes
Adam's pretty much correct with his statements on this.
The children() method's real purpose is for using namespaces within the
document.
Without an argument, it retrieves child elements within the default
namespace, otherwise it will retrieve elements within the namespace passed
in. It also sets
Zeev Suraski wrote:
At 16:25 04/02/2004, Marco Tabini wrote:
Zeev Suraski wrote:
Wez,
You're going to see Zeev on the PHP Cruise and me in Manchester at
PawsCon :)
Yeah, but what about both of you *together*? :-)
Forgot we were in Frankfurt together in 2002? :)
for 1 day .. not enough time t
At 16:25 04/02/2004, Marco Tabini wrote:
Zeev Suraski wrote:
Wez,
You're going to see Zeev on the PHP Cruise and me in Manchester at PawsCon :)
Yeah, but what about both of you *together*? :-)
Forgot we were in Frankfurt together in 2002? :)
Andi
--
PHP Internals - PHP Runtime Development Mailing
Zeev Suraski wrote:
Wez,
You're going to see Zeev on the PHP Cruise and me in Manchester at
PawsCon :)
Yeah, but what about both of you *together*? :-)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Wez,
You're going to see Zeev on the PHP Cruise and me in Manchester at PawsCon :)
I expect internals@ will want you to report back afterwards :)
Andi
At 16:13 04/02/2004, Pierre-Alain Joye wrote:
On Wed, 4 Feb 2004 14:09:56 -
"Wez Furlong" <[EMAIL PROTECTED]> wrote:
> Woah, real proof that Z
Is there any reason that zend_assign_to_object always converts the property to a
string when it's a variable?
Looking at simpexml, there is no way to distinguish between writing to an element or
to an attribute when using variables.
$sxe[0] = "a"; works fine, but $i=0; $sxe[$i] = "a"; doesnt as
On Wed, 4 Feb 2004 14:09:56 -
"Wez Furlong" <[EMAIL PROTECTED]> wrote:
> Woah, real proof that Zeev really is Andi ;-)
We got already another proof earlier :-D :
From: Andi Gutmans <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
Aka "I'm messed with my clones..." ;-)
p
Woah, real proof that Zeev really is Andi ;-)
--Wez.
- Original Message -
From: "Zeev Suraski" <[EMAIL PROTECTED]>
To: "Jan Lehnardt" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Wednesday, February 04, 2004 1:57 PM
Subject: Re: [PHP-DEV] Assigning to $this
> Good idea. I added a
Good idea. I added a fatal error. The reason is that there's pretty much
no chance that someone was doing this and his script will continue working.
This is definitely something which needs to be fixed by the app developer.
Andi
At 15:16 04/02/2004, Jan Lehnardt wrote:
Hi,
I was just wondering
Hi,
I was just wondering. An assignment to $this is not longer possible
in PHP 5. This was agreed upon and everything is fine with that.
However, when trying to assign to $this in PHP 5, this assignment
is silently ignored. I thought it might be useful, or even needed
to issue a notice there. I fir
On Tue, 3 Feb 2004 15:44:17 -0800 (PST)
[EMAIL PROTECTED] (David Giffin) wrote:
>
> Hi there,
>
> I've been using the unserialize and serialize methods in php5 on some
> rather large objects it seems that the larger object get the following
> errors:
>
> Notice: unserialize(): Error at of
Andi Gutmans wrote:
> The real question is, do we change the default return_value to FALSE
> and change ZEND_FETCH_RESOURCE() to return FALSE and try and
> standardize for PHP 5 (and risk breaking people's scripts, mainly
> people using === and !==) or do we stick to the status quo?
+1 for consi
Hey guys,
Ilia raises a valid point here. We are quite inconsistent today when it
comes to return values. In ext, for example, most functions return FALSE
and not NULL (roughly about 2910 vs. 47), however, by default (before the
function is called) the return_value is set to the NULL value (so
We've changed the way that objects are destroyed during shutdown to a
2-phase mechanism. First, destructors are called for all of the objects in
the store (in no particular order). Afterwards - the object storage and
the various symbol tables are destroyed&freed.
This has several implications
I'll take a look into the problem.
Thanks.
Moriyoshi
On 2004/02/04, at 11:26, John Coggeshall wrote:
Looks like someone who touched the UTF8 stuff recently broke something,
as I am getting a SEGV trying to run a fairly simple Smarty script:
See bug #27137
John
--
PHP Internals - PHP Runtime De
73 matches
Mail list logo
