On 9/5/07, Marcus Boerger <[EMAIL PROTECTED]> wrote:
> What is the problem with those objects? Basically there are at least three
> seperated memory areas involved. First the zend_object container, the real
> object and one or several zvals. The gc would simply have to decrease
> refcount on zend_o
Dear Mr. BuildSmart
I'm not interested in filing a minimum of 100 bug reports when you don't
have the manpower to process them, I've resolved most of them already
(at least the ones related to the php base) and any that I haven't I've
noted as "Broken - DNU" so I don't pass anything unstable o
> -Original Message-
> From: Marcus Boerger [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, September 04, 2007 2:12 PM
> To: Andi Gutmans
> Cc: Derick Rethans; David Wang; Nuno Lopes; internals@lists.php.net;
> [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: [PHP-DEV] Patch for macros for tr
Hello Andi,
Tuesday, September 4, 2007, 9:46:22 PM, you wrote:
>> -Original Message-
>> From: Derick Rethans [mailto:[EMAIL PROTECTED]
>> Sent: Tuesday, September 04, 2007 11:57 AM
>> To: Andi Gutmans
>> Cc: David Wang; Nuno Lopes; internals@lists.php.net; [EMAIL PROTECTED];
>> [EMAIL PRO
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sep 4, 2007, at 14:07:35, Stut wrote:
Hello Dale,
I'm not experienced enough to comment on most of what you said, but
not reporting bugs in a piece of software because you're worried
that 1) the developers won't be able to deal with the vol
On Tue, 4 Sep 2007, Andi Gutmans wrote:
> On Tuesday, September 04, 2007 11:57 AM, Derick Rethans wrote:
> >
> > On Tue, 4 Sep 2007, Andi Gutmans wrote:
> >
> > > Btw, when can you make a PHP 5.2.x version of the patch available so
> > > that we can start playing around with it and test it?
> >
> -Original Message-
> From: Derick Rethans [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, September 04, 2007 11:57 AM
> To: Andi Gutmans
> Cc: David Wang; Nuno Lopes; internals@lists.php.net; [EMAIL PROTECTED];
> [EMAIL PROTECTED]
> Subject: RE: [PHP-DEV] Patch for macros for tracking refcount
Due to the nature of my work, I have encountered just about every
imaginable bug in the build process, if I were to submit bug reports on
each and every issue encountered, the number alone would swamp the
developers who spend their time validating and substantiating the
reported bugs because I
On Tue, 4 Sep 2007, Marcus Boerger wrote:
> Tuesday, September 4, 2007, 6:38:17 PM, you wrote:
>
> > If ever a version of this patch is committed, you'll be able to see
> > that the cycle collector touches the whole reference counting mess
> > extremely minimally, which is why it was relatively s
Hello David,
Tuesday, September 4, 2007, 6:38:17 PM, you wrote:
> On 9/4/07, Nuno Lopes <[EMAIL PROTECTED]> wrote:
>> It can also have some use if we
>> decide to investigate the usage of an off-the-shelf (conservative)
>> garbage collector such as Boehm's (maybe in next year's SoC).
>>
> As an
On Tue, 4 Sep 2007, Andi Gutmans wrote:
> Btw, when can you make a PHP 5.2.x version of the patch available so
> that we can start playing around with it and test it?
THis is the 5.2 version... it still needs to be ported to HEAD.
Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no
See below:
> -Original Message-
> From: Nuno Lopes [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, September 04, 2007 11:35 AM
> To: David Wang
> Cc: internals@lists.php.net; [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: Re: [PHP-DEV] Patch for macros for tracking refcount
> andis_ref
>
Btw, when can you make a PHP 5.2.x version of the patch available so
that we can start playing around with it and test it?
> -Original Message-
> From: David Wang [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, September 04, 2007 9:38 AM
> To: Nuno Lopes
> Cc: internals@lists.php.net; [EMAIL PR
Yes I agree that a more traditional mark-and-sweep collector would not
be suitable for PHP, and as many have experienced with Java it comes
with its own set of baggage. Actually I think the deterministic nature
of refcounting is more suitable to Web requests esp. for sites who want
to consistently
Off the shelf garbage collectors such as BDW would be inappropriate
because we use some weird kinds of "pointers" (such as object handles)
stored in weird kinds of ways (such as a zend_hash object). I think it
would be pretty inefficient, since those implementations just scan the
stack, registers
On 04.09.2007 21:48, BuildSmart wrote:
> Unlike many developers who do this in their spare time, I have the
> time, resources, energy and motivation to attack PHP with extreme
> aggression.
Please stop here, right now.
No need to attack anything or anyone.
If you want your job (or life, 'caus
I'm not interested in filing a minimum of 100 bug reports when you
don't have the manpower to process them, I've resolved most of them
already (at least the ones related to the php base) and any that I
haven't I've noted as "Broken - DNU" so I don't pass anything
unstable on to my clients.
Hello Dale,
I'm not experienced enough to comment on most of what you said, but not
reporting bugs in a piece of software because you're worried that 1) the
developers won't be able to deal with the volume and 2) you're worried
about damaging the reputation of said software has to be the most
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sep 4, 2007, at 09:02:23, Hartmut Holzgraefe wrote:
Dear Mr BuildSmart
BuildSmart wrote:
SInce I didn't consider it a bug but rather a minor error of
importance,
just out of curiosity: how do you define "bug" if not as "any error"?
I thoug
> currently you only have one statement in each of those functions..
> anyway it's not critical to have static inline functions.
I will need to have them (multiple statements) for the cycle
collection code, and I don't think there are many situations involving
changing the way reference counting i
On 9/4/07, Nuno Lopes <[EMAIL PROTECTED]> wrote:
> It can also have some use if we
> decide to investigate the usage of an off-the-shelf (conservative)
> garbage collector such as Boehm's (maybe in next year's SoC).
>
As an aside, I was also thinking about this throughout the course of
the project
About the patch, the zval_*_p() functions don't really need to exist..
they can be macros as well.
As I said, if those were macros, it would be very difficult to squeeze
more than one statement into them.
Having multiple statements in Z_DELREF_P will also break that code. It
seems to me inline
> About the patch, the zval_*_p() functions don't really need to exist..
> they can be macros as well.
As I said, if those were macros, it would be very difficult to squeeze
more than one statement into them.
Consider the usage in Zend/zend_execute.c:
if (!Z_DELREF_P(z)) {
I think this is a pretty good idea. It can also have some use if we
decide to investigate the usage of an off-the-shelf (conservative)
garbage collector such as Boehm's (maybe in next year's SoC).
About the patch, the zval_*_p() functions don't really need to exist..
they can be macros as w
> Shouldn't that be
>
> +#define always_inline inline
>
> ?
Yes, sorry, I just fixed that a moment ago (and the file the link is
pointing to should be correct).
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
W liście David Wang z dnia wtorek, 4 września 2007 16:24:
> http://zoo.cs.yale.edu/~yw226/macros.diff.txt
>
> Comments?
+#define always_inline inlinue
Shouldn't that be
+#define always_inline inline
?
(in zend.h)
--
Paweł Stradomski
--
PHP Internals - PHP Runtime Development Mailing List
To
Hi,
This is another shot at a patch to manage refcount and is_ref of zvals
with macros. The macros are implemented with inline functions that are
forcibly inlined (so they will behave the same as macros). This will
make it possible to put multiple statements in each macro later on for
garbage coll
Dear Mr BuildSmart
BuildSmart wrote:
SInce I didn't consider it a bug but rather a minor error of importance,
just out of curiosity: how do you define "bug" if not as "any error"?
I thought it would best be handled by making the maintainers aware of
the issue since the fix is relatively simp
> Actually, I'll simplify matters even more and save my time, I wont
> file any bug reports or provide any solutions,
It looks like there is a misunderstanding. My answers had no bad
meanings. It was only about telling you how we use to work. Most of us
work on this project (*.php.net) in our free
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I'd like to work on resolving as many of the bugs as possible in the
shortest amount of time because there are not enough PHP developers
to go around validating and fixing every reported bug, this means
that the person assigned many of the bugs
Hi Dale,
I'm not sure I was clear enough in my last four replies. We have two
important issues tracker (for your needs):
http://bugs.php.net for all you can have in php releases or snaps
http://pecl.php.net for all PECL packages
http://pear.php.net for all PEAR packages (pear installer included)
I'm getting very tired at this. Why don't you do the commits like
everyone else? First to HEAD then MFH to whatever branch is in question.
I find it extremely arrogant that you just commit to the stable branch.
Either you start behaving or don't commit anything anymore..
--Jani
On Mon, 2007-09-
32 matches
Mail list logo
