At 01:20 14/01/2004, Andrei Zmievski wrote:
On Wed, 14 Jan 2004, Zeev Suraski wrote:
> Yes, it works, the 'problem' is that it's really very very simple. 99% of
> the work is upto the implementor of the particular proxy object... It
just
> gives you a very general framework.
You mean the implem
I want to contribute to the PHP documentation on russian. Iam a student. And I have a
little free time to do this. I hope that I can help to translate information about
many PHP functions...
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.
reading, writing and offer support
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Looks like a circular reference to me. It's supposed to leak :)
Andi
At 06:42 PM 1/13/2004 -0500, Sterling Hughes wrote:
Hey,
The attached script gives 10 leaks when PHP5 is compiled with
--enable-debug. These problems are also related to Bug #26765, I'll be
taking a look at it, unless someone
Andi Gutmans wrote:
Looks like a circular reference to me. It's supposed to leak :)
Andi
Hi Andy,
not sure if I understood this right but thats supposed to be that way?
Anyone CAN create memory-leaks in php if he just wants?
I'm not sure if hosters will like that behaviour with their
apache proc
I know that this issue to some extent or another has been brought up
before, but I just wanted to make sure that this is really how things
are supposed to work... Apparently the statements setting B C and D
are all equivalent.
This could be absolutely bogus, but I thought maybe someone could
expla
On Wed, Jan 14, 2004 at 04:33:13AM -0500, John Coggeshall wrote:
> I know that this issue to some extent or another has been brought up
> before, but I just wanted to make sure that this is really how things
> are supposed to work... Apparently the statements setting B C and D
> are all equivalent.
At 11:33 14/01/2004, John Coggeshall wrote:
I know that this issue to some extent or another has been brought up
before, but I just wanted to make sure that this is really how things
are supposed to work... Apparently the statements setting B C and D
are all equivalent.
This could be absolutely bog
Hi,
so PHP5 (currenlty HEAD) is feature freezed and therefore new code goes nowhere,
only bugfixes go to php-src module since PHP_4_3 is also feature freezed. Is it ok, to
branch PHP5_0 from HEAD so new developments to go to HEAD and bugfixes will go to
PHP5_0 and HEAD. I know that this way we will
At 10:29 AM 1/14/2004 +0100, Thomas Seifert wrote:
Andi Gutmans wrote:
Looks like a circular reference to me. It's supposed to leak :)
Andi
Hi Andy,
not sure if I understood this right but thats supposed to be that way?
Anyone CAN create memory-leaks in php if he just wants?
I'm not sure if hoster
I think its way too early for that. PHP_5_0 branch should IMHO be created
after php-5.0.0 has been released at the earliest.
Edin
- Original Message -
From: "Andrey Hristov" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, January 14, 2004 1:18 PM
Subject: [PHP-DEV] Brachning
At 01:18 PM 1/14/2004 +0100, Andrey Hristov wrote:
Hi,
so PHP5 (currenlty HEAD) is feature freezed and therefore new code goes
nowhere,
only bugfixes go to php-src module since PHP_4_3 is also feature freezed.
Is it ok, to
branch PHP5_0 from HEAD so new developments to go to HEAD and bugfixes
wi
> I don't see anything odd in here. All of the assignments, except for the
> first one ('A'), assign to $this->"" (because $myvar, ${'myvar'} (which is
> the same as $myvar) and ${'$myvar'} (which is basically $"") are all non
> existent variables which implicitly evaluate to "". Try to turn o
At 01:30 PM 1/14/2004 +0100, Edin Kadribasic wrote:
I think its way too early for that. PHP_5_0 branch should IMHO be created
after php-5.0.0 has been released at the earliest.
Even better, but RC1 is a bare minimum IMO.
Andi
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe,
Hi,
Andi Gutmans wrote:
At 01:18 PM 1/14/2004 +0100, Andrey Hristov wrote:
I prefer waiting for RC1 to start a new-features branch. At least we
then know that we're on the right track. There are still some minor
changes going on (besides bug fixes) in tidy and SimpleXML.
What change do you want
Andi Gutmans ([EMAIL PROTECTED]) schrieb:
>
> These are not *real* memory leaks because they are cleaned up at the end of
> the request.
>
Hi Andy,
thanks a lot for making this clear.
Thats why I told that I'm not sure if I understand this right ;-).
Thomas
--
PHP Internals - PHP Runtime De
On Wed, 14 Jan 2004, Andi Gutmans wrote:
> I prefer waiting for RC1 to start a new-features branch.
That's how we usually do it too, and I agree that that would be the best
point to branch.
Derick
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net
Zeev Suraski wrote:
> zeev Wed Jan 14 09:00:12 2004 EDT
>
> Modified files:
> /ZendEngine2 zend_compile.c
> Log:
> Don't allow interfaces to implement anything
Could you please add support for
interface Lifecycle extends Startable, Stoppable, Disposable {
//
> Looks like a circular reference to me. It's supposed to leak :)
>
Yep - but shouldn't object destruction be forced before the memory
manager cleans it up. The example could rather be put as:
value = new GenericObject($this);
}
function __destruct() {
print "Cal
On Wed, 14 Jan 2004, Zeev Suraski wrote:
> Pretty much everything, yes.
All the handlers? Or just get and set?
- Andrei
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Wed, 14 Jan 2004, Andi Gutmans wrote:
> I prefer waiting for RC1 to start a new-features branch. At least we then
> know that we're on the right track. There are still some minor changes
> going on (besides bug fixes) in tidy and SimpleXML.
> What change do you want to make. If it's minor I th
On Wed, 14 Jan 2004, Andrei Zmievski wrote:
> On Wed, 14 Jan 2004, Andi Gutmans wrote:
> > I prefer waiting for RC1 to start a new-features branch. At least we then
> > know that we're on the right track. There are still some minor changes
> > going on (besides bug fixes) in tidy and SimpleXML.
At 18:26 14/01/2004, Andrei Zmievski wrote:
On Wed, 14 Jan 2004, Zeev Suraski wrote:
> Pretty much everything, yes.
All the handlers? Or just get and set?
Whatever you want to support. Basically, the thing with the proxy object
interface is that there's really no big secret as to how it works. I
At 08:34 AM 1/14/2004 -0800, Rasmus Lerdorf wrote:
On Wed, 14 Jan 2004, Andrei Zmievski wrote:
> On Wed, 14 Jan 2004, Andi Gutmans wrote:
> > I prefer waiting for RC1 to start a new-features branch. At least we
then
> > know that we're on the right track. There are still some minor changes
> > go
On Wed, 14 Jan 2004, Andi Gutmans wrote:
> I agree too. I meant we shouldn't branch before RC1 or later.
Of course not. Branch right after PHP 5.0.0 golden goes out the door.
- Andrei
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi !
Just forwarding here in case it was interesting. Have a look here :
http://news.php.net/article.php?group=php.notes&article=63539
Mehdi Achour
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi internals,
follows a message (note from the php.net site which was rejected)
It contains a patch to add SNMP v2c support. I have no knowledge of
SNMP but I think someone can review and say whether it's good or not,
or maybe it can be applied if it's ok.
Original URL : http://news.php.net/article
Wouldn't it be much more better idea to make this an ini-option..?
(or add some kind of 'snmp_set_option()' func to set this and other
similar options..?)
--Jani
On Wed, 14 Jan 2004, Andrey Hristov wrote:
>Hi internals,
>follows a message (note from the php.net site whi
Hello Internals,
Apache keeps segfaulting when serving certain perl scripts (namely the WebGUI CMS).
I've found through experimentation that removing PHP from apache makes the problem go
away. I've tried compiling PHP statically and as a DSO with same result. (Mod_SSL,
and Mod_Perl are compi
At 10:03 AM 1/14/2004 -0500, Sterling Hughes wrote:
> Looks like a circular reference to me. It's supposed to leak :)
>
Yep - but shouldn't object destruction be forced before the memory
manager cleans it up. The example could rather be put as:
function __construct() {
$th
Hi Andi:
On Mon, Jan 12, 2004 at 06:31:03PM +0200, Andi Gutmans wrote:
> That should be fine. The following isn't:
>
> function foo() {
> $x = 1;
> return $x;
> }
>
> function &bar() {
> return foo();
> }
>
> Note: foo isn't returning by reference.
Good. Can I ask one final clarif
Hi,
I just tried a test parse of phpDocumentor CVS using a fresh compile of
HEAD on windows xp. It went bananas with warnings and a fatal error.
Tracking down the error turned up get_class() returning "parserDesc"
instead of "parserdesc", which ruins every time I test whether
get_class($a) ==
Hello Greg,
Wednesday, January 14, 2004, 10:18:01 PM, you wrote:
> Hi,
> I just tried a test parse of phpDocumentor CVS using a fresh compile of
> HEAD on windows xp. It went bananas with warnings and a fatal error.
> Tracking down the error turned up get_class() returning "parserDesc"
> ins
> > I just tried a test parse of phpDocumentor CVS using a fresh compile of
> > HEAD on windows xp. It went bananas with warnings and a fatal error.
> > Tracking down the error turned up get_class() returning "parserDesc"
> > instead of "parserdesc", which ruins every time I test whether
> > get_c
On Wed, 14 Jan 2004, Marcus Boerger wrote:
> > This is such a huge BC break with php 4.x, I would have to fork the
> > package just because of the numerous get_class() statements.
You could always strtolower() them.
> > Is case-sensitive get_class() here to stay?
>
> Yes. We now report classes,
Hello Adam,
Thanks for moving backward. Since iterating is now worthless i am all for
removing it completley. I mean it isn't even in the spirit of the extension.
I will sleep over this tonight and probably remove the work of another full
week too. Just because it is too complex and doesn't fit in
Hello!
I just fixed my alpha (running Tru64 UNIX 5.1) so I could compile PHP on it
again and checked for ptrmismatch'es in PHP_4_3 and found these.. Maybe they
are safe to ignore or maybe not.
Configure line:
./configure --disable-all
I'll check HEAD too in a few and report my findings for it
It seems to me the certain amounts of case insensitivity which are still
part of PHP start making less and less sense.
Cheers,
Michael
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
38 matches
Mail list logo
