Re: [PHP-DEV] dl() shutdown bug fix
It is/was attached to the mail I sent out; maybe gmail isn't so smart with text attachments. I've attached it to this mail, so you should get it this time. --Wez. On Sun, 06 Mar 2005 08:41:53 +0200, Zeev Suraski <[EMAIL PROTECTED]> wrote: > At 08:18 06/03/2005, Wez Furlong wrote: > >Any objections to me applying this fix for the > >unload-module-before-calling-object-dtors bug that I periodically > >whine about? > > Is the diff available anywhere? > > Zeev > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] dl() shutdown bug fix
Wez Furlong wrote: Hi Wez, The diff is not attached. I think the mailling lists strip attachments? Regards --jm It is/was attached to the mail I sent out; maybe gmail isn't so smart with text attachments. I've attached it to this mail, so you should get it this time. --Wez. On Sun, 06 Mar 2005 08:41:53 +0200, Zeev Suraski <[EMAIL PROTECTED]> wrote: At 08:18 06/03/2005, Wez Furlong wrote: Any objections to me applying this fix for the unload-module-before-calling-object-dtors bug that I periodically whine about? Is the diff available anywhere? Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] dl() shutdown bug fix
Jacques Marneweck wrote: I think the mailling lists strip attachments? Attaching a file to this message to test the theory. For the list of people who've put work into PHP, please see http://www.php.net/credits.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] (s|g)etStaticPropertyValue
Hello,
I saw there are two new ReflectionClass methods:
* getStaticPropertyValue()
* getStaticPropertyValue()
How do these differ (excepting being one method call) from:
$value= $reflectionClass->getProperty('instance')->getValue();
and
$reflectionClass->getProperty('instance')->setValue($value);
?
Instead of adding all kinds of feature bloat to the Reflection API,
couldn't this be left to people who extend it?
And if we must have these methods because of performance reasons, why
restrict them to static properties? Just because I can write
$instance->{$variable} and not Classname::$variable?
--
Timm
If it ain't broken, it doesn't have enough features yet
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] (s|g)etStaticPropertyValue
I think for me, it is the most comfortable way to refelect the properties.
When it is refelecting
it should follow a std. pattern
- Original Message -
From: "Timm Friebe" <[EMAIL PROTECTED]>
To: "internals"
Sent: Sunday, March 06, 2005 5:11 PM
Subject: [PHP-DEV] (s|g)etStaticPropertyValue
> Hello,
> I saw there are two new ReflectionClass methods:
>
> * getStaticPropertyValue()
> * getStaticPropertyValue()
>
> How do these differ (excepting being one method call) from:
>
> $value= $reflectionClass->getProperty('instance')->getValue();
>
> and
>
> $reflectionClass->getProperty('instance')->setValue($value);
>
> ?
>
> Instead of adding all kinds of feature bloat to the Reflection API,
> couldn't this be left to people who extend it?
>
> And if we must have these methods because of performance reasons, why
> restrict them to static properties? Just because I can write
> $instance->{$variable} and not Classname::$variable?
>
> --
> Timm
> If it ain't broken, it doesn't have enough features yet
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] ReflectionProperty::getValue() -> UNKNOWN:0
Hi,
the following script:
getProperty('instance')->getValue());
?>
prints "UNKNOWN:0" - expected behaviour would be to print "NULL".
Attached is a diff against zend_reflection_api.c which fixes this.
--
Timm
If it ain't broken, it doesn't have enough features yet
Index: Zend/zend_reflection_api.c
===
RCS file: /repository/ZendEngine2/zend_reflection_api.c,v
retrieving revision 1.149
diff -u -r1.149 zend_reflection_api.c
--- Zend/zend_reflection_api.c 27 Feb 2005 22:21:17 - 1.149
+++ Zend/zend_reflection_api.c 6 Mar 2005 12:15:51 -
@@ -3358,6 +3358,7 @@
}
if ((ref->prop->flags & ZEND_ACC_STATIC)) {
+ zend_update_class_constants(intern->ce TSRMLS_CC);
if (zend_hash_quick_find(intern->ce->static_members, ref->prop->name, ref->prop->name_length + 1, ref->prop->h, (void **) &member) == FAILURE) {
zend_error(E_ERROR, "Internal error: Could not find the property %s", ref->prop->name);
/* Bails out */
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] (s|g)etStaticPropertyValue
At 13:26 06/03/2005, Timm Friebe wrote:
Hello,
I saw there are two new ReflectionClass methods:
* getStaticPropertyValue()
* getStaticPropertyValue()
How do these differ (excepting being one method call) from:
$value= $reflectionClass->getProperty('instance')->getValue();
and
$reflectionClass->getProperty('instance')->setValue($value);
?
Instead of adding all kinds of feature bloat to the Reflection API,
couldn't this be left to people who extend it?
I very much agree.
Zeev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.0.3 E_STRICT question - returning NULL from reference returning function
On Sun, 6 Mar 2005, Zeev Suraski wrote:
> At 06:47 06/03/2005, Yermo Lamers wrote:
>
> >What is the proper way to return a NULL condition from a method that
> >returns a reference?
> >
> >function &testfunc()
> >{
> >return NULL;
> >}
> >
> >generates:
> >
> >"Strict Standards: Only variable references should be returned by
> >reference in ..."
> >
> >Is the correct approach to do something like:
> >
> >function &testfunc()
> >{
> >$nullVar = NULL;
> >return $nullVar;
> >}
>
> That'd work, yep.
Wrong ;-) It causes problems with reference counting - and will segfault
PHP after some time.
Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Web graphics designer needed (this is spam :)
Hey, Someone I know is looking for an experienced web graphics designer (including HTML editing) who will do some occasional work for a (very) large company. If you know anyone please let me know directly. It's quite urgent... Sorry for spaming the list. Thanks, Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] assistance with segfaults in debug_backtrace()
Hi, We're getting quite a few reports of PEAR segfaulting on a debug_backtrace() call found in the constructor of PEAR_Error. Jan Schneider reported that it seemed to occur when one of the methods in the trace happened in a file that the uid did not have write access to (i.e. a PEAR file installed by root), but Davey Shafik posted a report that it happened to him while running "pear upgrade PEAR" as root. He also posted a backtrace that might be useful at: http://pear.php.net/bugs/bug.php?id=3683 Any tips on how to proceed in isolating this? I can't reproduce the problem on any of my systems (windows xp, gentoo). Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] assistance with segfaults in debug_backtrace()
On Sun, 6 Mar 2005, Greg Beaver wrote: > We're getting quite a few reports of PEAR segfaulting on a > debug_backtrace() call found in the constructor of PEAR_Error. Jan > Schneider reported that it seemed to occur when one of the methods in > the trace happened in a file that the uid did not have write access to > (i.e. a PEAR file installed by root), but Davey Shafik posted a report > that it happened to him while running "pear upgrade PEAR" as root. He > also posted a backtrace that might be useful at: > > http://pear.php.net/bugs/bug.php?id=3683 > > Any tips on how to proceed in isolating this? I can't reproduce the > problem on any of my systems (windows xp, gentoo). Disable the memory manager in zend_alloc.h (it's a define "ZEND_ALLOC" afaik). Then use valgrind to run PHP and see whether it shows errors... regards, Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.0.3 E_STRICT question - returning NULL fromreference returning function
>> >Is the correct approach to do something like:
>> >
>> >function &testfunc()
>> >{
>> >$nullVar = NULL;
>> >return $nullVar;
>> >}
>>
>> That'd work, yep.
>
> Wrong ;-) It causes problems with reference counting - and will segfault
> PHP after some time.
>
> Derick
Then what is the correct approach to handling this?
-- Yermo
DTLink Software http://www.dtlink.com
Desktop Software and Web Applications
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.0.3 E_STRICT question - returning NULL from reference returning function
At 17:06 06/03/2005, Derick Rethans wrote:
On Sun, 6 Mar 2005, Zeev Suraski wrote:
> At 06:47 06/03/2005, Yermo Lamers wrote:
>
> >What is the proper way to return a NULL condition from a method that
> >returns a reference?
> >
> >function &testfunc()
> >{
> >return NULL;
> >}
> >
> >generates:
> >
> >"Strict Standards: Only variable references should be returned by
> >reference in ..."
> >
> >Is the correct approach to do something like:
> >
> >function &testfunc()
> >{
> >$nullVar = NULL;
> >return $nullVar;
> >}
>
> That'd work, yep.
Wrong ;-) It causes problems with reference counting - and will segfault
PHP after some time.
Hmm, that in itself shouldn't cause any problems unless it's coupled with
something else that's causing problems... Not that it helps you any if you
end up bumping into problems :)
Zeev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.0.3 E_STRICT question - returning NULL from reference returning function
>> > >function &testfunc()
>> > >{
>> > >$nullVar = NULL;
>> > >return $nullVar;
>> > >}
>> >
>> > That'd work, yep.
>>
>>Wrong ;-) It causes problems with reference counting - and will segfault
>>PHP after some time.
>
> Hmm, that in itself shouldn't cause any problems unless it's coupled with
> something else that's causing problems... Not that it helps you any if
> you end up bumping into problems :)
True; but it's good to know what the "correct" thing to do is; even if
there is an underlying bug.
-- Yermo
DTLink Software http://www.dtlink.com
Desktop Software and Web Applications
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] dl() shutdown bug fix
The patch looks good. The only thing I'd add is getting rid of the code that became redundant, for clarity (the switch() is not needed in module_registry_cleanup(), and the switch() in module_registry_unload_temp() can be an if()). Did you intend to also commit it to the 5.0 branch or only 5.1? The reason I'm asking is that changing the shutdown order almost always bundles one surprise or another, even though I'm pretty certain it should be pretty safe. Zeev At 10:23 06/03/2005, Wez Furlong wrote: It is/was attached to the mail I sent out; maybe gmail isn't so smart with text attachments. I've attached it to this mail, so you should get it this time. --Wez. On Sun, 06 Mar 2005 08:41:53 +0200, Zeev Suraski <[EMAIL PROTECTED]> wrote: > At 08:18 06/03/2005, Wez Furlong wrote: > >Any objections to me applying this fix for the > >unload-module-before-calling-object-dtors bug that I periodically > >whine about? > > Is the diff available anywhere? > > Zeev > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Extension or API bug?
I've been writing some extensions with great success however, I have one that I'm working on (rewriting an existing extension that has never functioned properly to the best of my knowledge) that is causing me headaches. This problem seems to occur regardless of the version of PHP being utilized. By using a simple and basic config.m4 file that substantiates the required files, building PHP with the module as a shared extension complains with the following error message in the log: [Sun Mar 6 17:03:09 2005] [error] PHP Warning: rrdtool: Unable to register functions, unable to load in Unknown on line 0 however, the module functions appears to work properly. If I build the extension embedded into PHP, I still get the same message in the log however the modules functions don't work properly (doesn't work as intended) and for those who say they don't understand what "doesn't works properly" or "work as intended" and are looking for more clarity, all I can say is this, it does not do what it is supposed to do and if you need more clarity than that you will have to examine the source code and the environment and provide me with a better answer because I can't explain it other than "it doesn't do what it's supposed to do" for the lack of better words. Now, by utilizing a very elaborate and complex config.m4 file and building in either manor I do not receive this error message in the log but the module still functions properly as a shared extension but refuses to function properly when it is embedded into PHP. I've been seeking assistance with the problem for several weeks now and while I have received some responses, I have made little progress in solving this matter or gaining a better insight to the cause/solution to this problem. I've examined the source carefully as well as a couple of other people and nothing appears to be outside the normal extension API, I can only verify that this problem occurs with this particular module under Mac OSX 10.2.x - 10.3.x and any version of PHP from 4.3.4 and newer (never tested on earlier versions than 4.3.4). If you want to duplicate the problem it's simple and easy, I can send you the source, you will require access to a Macintosh computer (which I can provide since I have 14 of them) with OSXS 10.3.x installed that are accessible and all you have to do is add is build it. While there is nothing outside of normal programming occurring and the API seems to be adhered to I cannot for the life of me figure out what is going on and can only assume that the problem is a bug in the API being the culprit. Anyone willing to take a stab at it? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Extension or API bug? correction
I've been writing some extensions with great success however, I have one that I'm working on (rewriting an existing extension that has never functioned properly to the best of my knowledge) that is causing me headaches. This problem seems to occur regardless of the version of PHP being utilized. By using a simple and basic config.m4 file that substantiates the required files, building PHP with the module as a shared extension complains with the following error message in the log: [Sun Mar 6 17:03:09 2005] [error] PHP Warning: rrdtool: Unable to register functions, unable to load in Unknown on line 0 however, the module functions appears to work properly. If I build the extension embedded into PHP, I still get the same message in the log however the modules functions don't work properly (doesn't work as intended) and for those who say they don't understand what "doesn't works properly" or "work as intended" and are looking for more clarity, all I can say is this, it does not do what it is supposed to do and if you need more clarity than that you will have to examine the source code and the environment and provide me with a better answer because I can't explain it other than "it doesn't do what it's supposed to do" for the lack of better words. Now, by utilizing a very elaborate and complex config.m4 file and building in either manor I still receive this error message in the log but the module still functions properly as a shared extension but refuses to function properly when it is embedded into PHP. I've been seeking assistance with the problem for several weeks now and while I have received some responses, I have made little progress in solving this matter or gaining a better insight to the cause/solution to this problem. I would like to note that making it a shared extension and not loading it via a php.ini entry, it does not display the error message in the log but the module functions work properly. I've examined the source carefully as well as a couple of other people and nothing appears to be outside the normal extension API, I can only verify that this problem occurs with this particular module under Mac OSX 10.2.x - 10.3.x and any version of PHP from 4.3.4 and newer (never tested on earlier versions than 4.3.4). If you want to duplicate the problem it's simple and easy, I can send you the source, you will require access to a Macintosh computer (which I can provide since I have 14 of them) with OSXS 10.3.x installed that are accessible and all you have to do is add is build it. While there is nothing outside of normal programming occurring and the API seems to be adhered to, I cannot for the life of me figure out what is going on and can only assume that the problem is a bug in the API being the culprit. Anyone willing to take a stab at it? -- Dale -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
