3 (or tweak) if/when needed.
Andi
> -Original Message-
> From: Johannes Schlüter [mailto:[EMAIL PROTECTED]
> Sent: Thursday, January 03, 2008 5:11 AM
> To: Andi Gutmans
> Cc: Derick Rethans; Dmitry Stogov; PHP Developers Mailing List
> Subject: RE: [PHP-DEV] Garbage col
D]
> > Sent: Tuesday, December 18, 2007 9:20 AM
> > To: Andi Gutmans
> > Cc: Dmitry Stogov; PHP Developers Mailing List
> > Subject: RE: [PHP-DEV] Garbage collector patch
> >
> > On Tue, 18 Dec 2007, Andi Gutmans wrote:
> >
> > > Derick Rethan
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ok, I got the message :-)
Sorry for interruption, thanks, works as expected.
- - Markus
Dmitry Stogov wrote:
> ./buildconf --force
> ./config.nice
> make clean
> make
>
> Dmtiry.
>
> Markus Fischer wrote:
> Hi,
>
> it would really be gre
On 25.12.2007 11:51, Markus Fischer wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi,
>
> it would really be great if this could be part of CVS alredy. The patch
> doesn't compile currently, I get zillions of
You didn't read 3 last messages in the thread, did you?
You have to run
./buildconf --force
./config.nice
make clean
make
Dmtiry.
Markus Fischer wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
it would really be great if this could be part of CVS alredy. The patch
doesn't compile currently, I get zillions of
Zend/zend_execute.o: In function `gc_zval_che
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
it would really be great if this could be part of CVS alredy. The patch
doesn't compile currently, I get zillions of
Zend/zend_execute.o: In function `gc_zval_check_possible_root':
php5.3-200712250730/Zend/zend_gc.h:175: undefined reference to
`g
On 12/19/07, Dmitry Stogov <[EMAIL PROTECTED]> wrote:
> updated patch.
Great! I managed to compile it.
Works for me.
The problem mentioned here is gone: http://blog.milkfarmsoft.com/?p=52
It is now possible to continue my appserver implementation ;)
--
Alexey Zakhlestin
http://blog.milkfarmsoft
On Wed, 19 Dec 2007, Alexey Zakhlestin wrote:
> On 12/19/07, Dmitry Stogov <[EMAIL PROTECTED]> wrote:
> > updated patch.
>
> got an error during linking phase
>
> /usr/bin/ld: Undefined symbols:
> _gc_globals_id
> _gc_globals_ctor
> _gc_zval_possible_root
> _gc_collect_cycles
> _gc_init
> _gc_re
On 19.12.2007 13:20, Alexey Zakhlestin wrote:
> On 12/19/07, Dmitry Stogov <[EMAIL PROTECTED]> wrote:
>> updated patch.
>
> got an error during linking phase
You have to run this first:
./cvsclean && ./buildconf
--
Wbr,
Antony Dovgal
--
PHP Internals - PHP Runtime Development Mailing List
On 12/19/07, Dmitry Stogov <[EMAIL PROTECTED]> wrote:
> updated patch.
got an error during linking phase
/usr/bin/ld: Undefined symbols:
_gc_globals_id
_gc_globals_ctor
_gc_zval_possible_root
_gc_collect_cycles
_gc_init
_gc_reset
_gc_zobj_possible_root
collect2: ld returned 1 exit status
make: **
On Wed, 19 Dec 2007, Dmitry Stogov wrote:
> Derick Rethans wrote:
> > On Mon, 17 Dec 2007, Dmitry Stogov wrote:
> >
> > > Didn't I send it to you?
> >
> > Maybe, maybe not :) I couldn't find it atleast.
> > I just tried to apply this to PHP 5.3, but it gives lots of failed chucks...
> > Are you
On Tue, 18 Dec 2007, Rasmus Lerdorf wrote:
> Ilia Alshanetsky wrote:
> > Putting it into CVS into a good idea, but lets create a revert point via
> > a tag, so we can always easily "undo" the patch if need be.
>
> Making sure it is ifdef'ed nicely would let us leave it in CVS until we
> get it rig
Making sure it is ifdef'ed nicely would let us leave it in CVS until we
get it right and if it causes problems for some people they have a way
Why we need non-working code in main CVS ifdef'ed if we can use
perfectly good CVS branch functionality? Just to make life harder to
ourselves and the
Putting it into CVS into a good idea, but lets create a revert point via
a tag, so we can always easily "undo" the patch if need be.
Along with undoing all patches on the way done by other people for othe
reasones. People, what's going on? Branches function in CVS is created
EXACTLY for this u
Making sure it is ifdef'ed nicely would let us leave it in CVS until we
get it right and if it causes problems for some people they have a way
to build PHP without it. And yes, that means their build won't be
binary compatible, which is fine and no different from them trying to
revert the patch th
Putting it into CVS into a good idea, but lets create a revert point
via a tag, so we can always easily "undo" the patch if need be.
On 18-Dec-07, at 10:05 AM, Derick Rethans wrote:
On Tue, 18 Dec 2007, Dmitry Stogov wrote:
Derick Rethans wrote:
On Mon, 17 Dec 2007, Dmitry Stogov wrote:
Uhm I meant 5.3. I guess we can commit it but as you know, reverting
this kind of stuff later is a headache people don't like doing.
Life's not always easy ;-)
So why again life should be not easy for all PHP tree users and not only
for 3 people that work on the specific patch? CVS has branch
On Tue, 18 Dec 2007, Andi Gutmans wrote:
> Derick Rethans wrote:
> >
> > On Tue, 18 Dec 2007, Andi Gutmans wrote:
> >
> > > Derick Rethans wrote:
> > > >
> > > > Maybe we just should put it in cvs then? Then we won't have this
> > > > issue and other people can test it more easily as well.
> >
ethans [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, December 18, 2007 9:20 AM
> To: Andi Gutmans
> Cc: Dmitry Stogov; PHP Developers Mailing List
> Subject: RE: [PHP-DEV] Garbage collector patch
>
> On Tue, 18 Dec 2007, Andi Gutmans wrote:
>
> > Derick Rethans wrote:
> > &g
On Tue, 18 Dec 2007, Andi Gutmans wrote:
> Derick Rethans wrote:
> >
> > Maybe we just should put it in cvs then? Then we won't have this issue
> > and other people can test it more easily as well.
>
> The only problem with that is what if people get bad
> benchmarks/results and we want to pull
> -Original Message-
> From: Derick Rethans [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, December 18, 2007 7:06 AM
> To: Dmitry Stogov
> Cc: PHP Developers Mailing List
> Subject: Re: [PHP-DEV] Garbage collector patch
>
> Maybe we just should put it in cvs then?
On 12/18/07, Derick Rethans <[EMAIL PROTECTED]> wrote:
> Maybe we just should put it in cvs then? Then we won't have this issue
> and other people can test it more easily as well.
+1
I want to test it, but, usually, messing with large patches is too
time-consuming :-(
having it in CVS will give m
On Tue, 18 Dec 2007, Dmitry Stogov wrote:
> Derick Rethans wrote:
> > On Mon, 17 Dec 2007, Dmitry Stogov wrote:
> >
> > > Didn't I send it to you?
> >
> > Maybe, maybe not :) I couldn't find it atleast.
> > I just tried to apply this to PHP 5.3, but it gives lots of failed chucks...
> > Are you
Probably I've changed ZE after the patch was done :(
I'll rebuild it, but not today.
Dmitry.
Derick Rethans wrote:
On Mon, 17 Dec 2007, Dmitry Stogov wrote:
Didn't I send it to you?
Maybe, maybe not :) I couldn't find it atleast.
I just tried to apply this to PHP 5.3, but it gives lots of f
On Mon, 17 Dec 2007, Dmitry Stogov wrote:
> Didn't I send it to you?
Maybe, maybe not :) I couldn't find it atleast.
I just tried to apply this to PHP 5.3, but it gives lots of failed
chucks... Are you sure this is the one against 5.3?
regards,
Derick
--
Derick Rethans
http://derickrethans.nl
On Thu, 13 Dec 2007, Derick Rethans wrote:
> On Thu, 13 Dec 2007, Dmitry Stogov wrote:
>
> > You test are enormous, but than you anyway. :)
> > I've found and fixed the problem.
> >
> > Now your test suite is passed with the following results:
> >
> > PHP_5_3: Tests: 7706, Failures: 45, Errors:
BTW the interesting fact that during Derick's test GC cycle collector
was automatically run 124 times and it collected 2,388,399 zvals.
So it really works! :)
Dmitry.
Dmitry Stogov wrote:
Hi Derick,
You test are enormous, but than you anyway. :)
I've found and fixed the problem.
Now your te
On Thu, 13 Dec 2007, Dmitry Stogov wrote:
> You test are enormous, but than you anyway. :)
> I've found and fixed the problem.
>
> Now your test suite is passed with the following results:
>
> PHP_5_3: Tests: 7706, Failures: 45, Errors: 807, Skipped: 347
>
> With GC: Tests: 7706, Failures: 45,
Hi Derick,
You test are enormous, but than you anyway. :)
I've found and fixed the problem.
Now your test suite is passed with the following results:
PHP_5_3: Tests: 7706, Failures: 45, Errors: 807, Skipped: 347
With GC: Tests: 7706, Failures: 45, Errors: 804, Skipped: 347
I've no idea why GC
On Fri, 7 Dec 2007, Dmitry Stogov wrote:
> all your tests passed for me yesterday with memory_limit=1G.
> May be it's some fresh non GC related bug :)
> Try the same test with -dzend.enable_gc=0 and with unpatched PHP.
>
> I would very interested in this "bad" test case, if it's really related to
aturday, December 08, 2007 9:35 AM
To: [EMAIL PROTECTED]
Cc: Rasmus Lerdorf; Stas Malyshev; [EMAIL PROTECTED];
'Antony
Dovgal'; Andi Gutmans; 'Cristian Rodriguez'; internals@lists.php.net
Subject: Re: [PHP-DEV] Garbage collector patch
Richard,
zval is such a common PHP struct
PROTECTED];
'Antony
> Dovgal'; Andi Gutmans; 'Cristian Rodriguez'; internals@lists.php.net
> Subject: Re: [PHP-DEV] Garbage collector patch
>
> Richard,
>
> zval is such a common PHP structure that in a scope of a single script
> (even a trivial one) you'
Richard,
zval is such a common PHP structure that in a scope of a single script
(even a trivial one) you'd have thousands of them. Therefor even an
extra 4 bytes matter, and for people with large application it would
matter even more. I wish the patch was such that it had no impact on
the
On Tue, December 4, 2007 2:18 pm, Rasmus Lerdorf wrote:
> Stanislav Malyshev wrote:
>>> 1. Always compile it in but leave undocumented #ifdefs in place for
>>> performance freaks. Those same performance freaks aren't going to
>>> care
>>> about the binary compatibility issue since they are the sam
hi Derick,
all your tests passed for me yesterday with memory_limit=1G.
May be it's some fresh non GC related bug :)
Try the same test with -dzend.enable_gc=0 and with unpatched PHP.
I would very interested in this "bad" test case, if it's really related
to GC.
Thanks. Dmitry.
Derick Rethans
On Tue, 4 Dec 2007, Rasmus Lerdorf wrote:
> 1. Always compile it in but leave undocumented #ifdefs in place for
> performance freaks. Those same performance freaks aren't going to care
> about the binary compatibility issue since they are the same people who
> build all their own stuff.
I am all
On Thu, 6 Dec 2007, Dmitry Stogov wrote:
> Derick Rethans wrote:
> >
> > That doesn't mean it works better for me than the old one either, where I
> > couldn't get it to crash at all ;-) Anyway, did you try to reproduce it with
> > the instructions that I provided?
>
> Yes I did. I'm looking into
On Thu, 6 Dec 2007, Dmitry Stogov wrote:
> Derick Rethans wrote:
> > On Wed, 5 Dec 2007, Andi Gutmans wrote:
> >
> > > Yes that's basically true although Dmitry can probably elaborate.
> > > I believe if the collector kicks in there'll also be a bit of a
> > > slowdown but my main concern is to
The GC patch passes the whole php test-suite with the same bugs.
The fact that it crashes on some script doesn't mean that "the patch
doesn't actually work".
Thanks. Dmitry.
Derick Rethans wrote:
On Wed, 5 Dec 2007, Andi Gutmans wrote:
Yes that's basically true although Dmitry can probably
Derick Rethans wrote:
On Tue, 4 Dec 2007, Andi Gutmans wrote:
To clarify I meant there's a tri-state (not compiled in, compiled in
but collection turned off, compiled in but collection turned on). My
recommendation was to always compile it in but to keep collection
turned off by default.
On Thu, 6 Dec 2007, Antony Dovgal wrote:
> On 06.12.2007 11:21, Derick Rethans wrote:
> > On Wed, 5 Dec 2007, Andi Gutmans wrote:
> >
> >> Yes that's basically true although Dmitry can probably elaborate. I
> >> believe if the collector kicks in there'll also be a bit of a slowdown
> >> but my
Antony Dovgal schrieb:
> To be honest, I can't see any crashes using standard PHP test suite.
Does the standard PHP test suite contain PHP code with reference cycles?
--
Sebastian Bergmann http://sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E
On 06.12.2007 11:21, Derick Rethans wrote:
> On Wed, 5 Dec 2007, Andi Gutmans wrote:
>
>> Yes that's basically true although Dmitry can probably elaborate. I
>> believe if the collector kicks in there'll also be a bit of a slowdown
>> but my main concern is to be able to turn it off because of s
On Wed, 5 Dec 2007, Andi Gutmans wrote:
> Yes that's basically true although Dmitry can probably elaborate. I
> believe if the collector kicks in there'll also be a bit of a slowdown
> but my main concern is to be able to turn it off because of stability.
> As you can see with the update patch
y Dovgal; Cristian Rodriguez; internals@lists.php.net
> Subject: Re: [PHP-DEV] Garbage collector patch
>
> On Wed, 5 Dec 2007, Stanislav Malyshev wrote:
>
> > > > To clarify I meant there's a tri-state (not compiled in, compiled
> in but
> > &g
On Wed, 5 Dec 2007, Stanislav Malyshev wrote:
> > > To clarify I meant there's a tri-state (not compiled in, compiled in but
> > > collection turned off, compiled in but collection turned on). My
> > > recommendation was to always compile it in but to keep collection turned
> > > off by default.
>
To clarify I meant there's a tri-state (not compiled in, compiled in
but collection turned off, compiled in but collection turned on). My
recommendation was to always compile it in but to keep collection
turned off by default.
Do I understand it right that being compiled in, "turned on" and "t
On Tue, 4 Dec 2007, Andi Gutmans wrote:
> To clarify I meant there's a tri-state (not compiled in, compiled in
> but collection turned off, compiled in but collection turned on). My
> recommendation was to always compile it in but to keep collection
> turned off by default.
That's totally fine
On Wed, 2007-12-05 at 10:01 -0600, Brian Moon wrote:
> Dmitry Stogov wrote:
> > In general this patch will use more memory.
> > (4 bytes more for each heap allocated zval).
> >
> > The only advantage is automatic cycle collection, but most web
> > applications doesn't make cycles.
>
> Could it b
Dmitry Stogov wrote:
In general this patch will use more memory.
(4 bytes more for each heap allocated zval).
The only advantage is automatic cycle collection, but most web
applications doesn't make cycles.
Could it be that this code should only be enabled for the CLI sapi?
That is where I w
On Mon, 3 Dec 2007, Andi Gutmans wrote:
> The revised patch has the following advantages:
> - It fixes several crash bugs
So far, my tests only see new crash bugs... :/
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x2ba1140c6930 (LWP 21108)]
0x008be4fe in zen
ssage-
From: Rasmus Lerdorf [mailto:[EMAIL PROTECTED]
Sent: Wednesday, 5 December 2007 5:17 AM
To: Antony Dovgal
Cc: Andi Gutmans; Cristian Rodriguez; internals@lists.php.net
Subject: Re: [PHP-DEV] Garbage collector patch
Antony Dovgal wrote:
On 04.12.2007 18:31, Andi Gutmans wrote:
You may b
gt;
> >
> > SCOTT MCNAUGHT
> > Software Developer
> >
> > Synergy 8 / +617 3397 5212
> > [EMAIL PROTECTED]
> >
> >
> > -Original Message-
> > From: Rasmus Lerdorf [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, 5 December 2007
Stanislav Malyshev wrote:
>> 1. Always compile it in but leave undocumented #ifdefs in place for
>> performance freaks. Those same performance freaks aren't going to care
>> about the binary compatibility issue since they are the same people who
>> build all their own stuff.
>
> Note that breakin
1. Always compile it in but leave undocumented #ifdefs in place for
performance freaks. Those same performance freaks aren't going to care
about the binary compatibility issue since they are the same people who
build all their own stuff.
Note that breaking BC is not only about performance - one
[EMAIL PROTECTED] wrote:
> I think having it configurable is a must. Turning it on / off via a compile
> flag will not suit everyone.
Looking at the code, that isn't really possible. You could have a
switch to turn off the collection, but that won't get you your
performance back. To avoid the p
o enabling it by default for CLI?
>
>
> SCOTT MCNAUGHT
> Software Developer
>
> Synergy 8 / +617 3397 5212
> [EMAIL PROTECTED]
>
>
> -Original Message-
> From: Rasmus Lerdorf [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, 5 December 2007 5:17 AM
> To: Antony
MCNAUGHT
Software Developer
Synergy 8 / +617 3397 5212
[EMAIL PROTECTED]
-Original Message-
From: Rasmus Lerdorf [mailto:[EMAIL PROTECTED]
Sent: Wednesday, 5 December 2007 5:17 AM
To: Antony Dovgal
Cc: Andi Gutmans; Cristian Rodriguez; internals@lists.php.net
Subject: Re: [PHP-DEV] Garbage
Antony Dovgal wrote:
> On 04.12.2007 18:31, Andi Gutmans wrote:
>> You may be right longer term but shorter term I still believe there may be
>> stability issues with this patch some of which we haven't figured out.
>> Although we did testing and found crash bugs I wouldn't trust our level of
>>
I could be wrong, of course, but my guess is that the ~3% speed decrease
a) is not really significant to 95% of the users (I mean _really_
significant; of course, everyone is going to whine about it first) and
GC is not really useful to 95% of the users either, so is 5% of the
users important
that could see some real benefits from this code. My suggestion is that
we make this feature a compile time flag, that's off by default and
What about binary compatibility?
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTE
On 04.12.2007 18:31, Andi Gutmans wrote:
> You may be right longer term but shorter term I still believe there may be
> stability issues with this patch some of which we haven't figured out.
> Although we did testing and found crash bugs I wouldn't trust our level of
> testing to deem it stable.
ilto:[EMAIL PROTECTED]
> Sent: Tuesday, December 04, 2007 12:28 AM
> To: Cristian Rodriguez
> Cc: internals@lists.php.net
> Subject: Re: [PHP-DEV] Garbage collector patch
>
> On 04.12.2007 06:00, Cristian Rodriguez wrote:
> > such switches only add more complexity, con
On Dec 4, 2007 2:46 AM, Ronald Chmara <[EMAIL PROTECTED]> wrote:
> I'd have to (sadly) ask that anything that slows down PHP by 5%, to
> improve performance for programmers that, uhm, "leak" or otherwise
> gobble RAM, that they, uhm, refactor their code as professional
> programmers.
In the ge
I could be wrong, of course, but my guess is that the ~3% speed decrease
a) is not really significant to 95% of the users (I mean _really_
significant; of course, everyone is going to whine about it first) and
b) is going to be eliminated over time
david
Am 04.12.2007 um 03:43 schrieb Ilia
On Tue, 2007-12-04 at 00:00 -0300, Cristian Rodriguez wrote:
> 2007/12/3, Ilia Alshanetsky <[EMAIL PROTECTED]>:
> > I think the patch does have a value,
>
> yes, it does, what worries me is the introduction of yet another
> non-sense ini setting that modified the very engine behaviuor.. I
> think
I believe this has to be done and it should be always on.
Having less headache is good. I will find other ways to speed up my projects
On 12/4/07, Antony Dovgal <[EMAIL PROTECTED]> wrote:
> On 04.12.2007 06:00, Cristian Rodriguez wrote:
> > such switches only add more complexity, confusion for use
On 04.12.2007 06:00, Cristian Rodriguez wrote:
> such switches only add more complexity, confusion for users and
> addtional trouble to distributors.
... which I believe are going to enable this flag by default anyway,
because they don't care about performance too much.
So I agree, either do it
On Dec 3, 2007, at 10:30 PM, Andi Gutmans wrote:
-Original Message-
From: Ronald Chmara [mailto:[EMAIL PROTECTED]
What is the *actual cost and complexity* involved in implementing
(possibly many) different user-selectable memory management systems,
and what other future benefits/drawbacks
> -Original Message-
> From: Ronald Chmara [mailto:[EMAIL PROTECTED]
> Sent: Monday, December 03, 2007 10:06 PM
> To: Andi Gutmans
> Cc: internals@lists.php.net
> Subject: Re: [PHP-DEV] Garbage collector patch
> I'm really hesitant to even *mention* this idea, but
On Dec 3, 2007, at 1:01 PM, Andi Gutmans wrote:
Hi all,
Was hoping to send this off earlier but I was travelling for the past
week and had very limited email access.
As promised in the past few weeks we have spent a significant
amount of
time in reviewing the garbage collector work and tes
such switches only add more complexity, confusion for users and
addtional trouble to distributors.
FWIW, amen to that.
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
2007/12/3, Ilia Alshanetsky <[EMAIL PROTECTED]>:
> I think the patch does have a value,
yes, it does, what worries me is the introduction of yet another
non-sense ini setting that modified the very engine behaviuor.. I
think we all agree that there are way too many of those do we ?
. My
> sugges
First of all big thanks for Dmitry and David for spending time on this
project and continuing to improve the original patch. Based on the
results so far, I think the patch does have a value, but certainly not
in a general case. Relative simple scripts have little to gain from it
and only to
On Dec 3, 2007 4:49 PM, Derick Rethans <[EMAIL PROTECTED]> wrote:
> On Mon, 3 Dec 2007, Andi Gutmans wrote:
>
> > Sorry about that. Does the attached PDFed screenshot work for you?
>
> No, as you can't attach files here
>
> Derick
>
> --
> Derick Rethans
> http://derickrethans.nl | http://ez.no
On Mon, 3 Dec 2007, Andi Gutmans wrote:
> Sorry about that. Does the attached PDFed screenshot work for you?
No, as you can't attach files here
Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
--
PHP Internals - PHP Runtime Development Mailing List
To u
Sorry about that. Does the attached PDFed screenshot work for you?
If only we knew how to publish documents on that 'web thing.
(-:
S
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Argh. Here you go: http://cvs.php.net/~andi/GC_email.pdf
> -Original Message-
> From: Edward Z. Yang [mailto:[EMAIL PROTECTED]
> Sent: Monday, December 03, 2007 1:43 PM
> To: internals@lists.php.net
> Subject: Re: [PHP-DEV] Garbage collector patch
>
> Daniel Brown w
007 4:38 PM, Andi Gutmans <[EMAIL PROTECTED]> wrote:
>>> Sorry about that. Does the attached PDFed screenshot work for you?
>>>
>>> Andi
>>>
>>>
>>>> -Original Message-
>>>> From: Daniel Brown [mailto:[EMAIL PROTECTE
Daniel Brown wrote:
> If for some reason the PDF attachment didn't come through to you
> on the list, let me know and I'll upload it to one of my servers for
> you to download and use, as well.
The PDF didn't make it through for me. Can you upload it?
--
Edward Z. YangGn
l Brown [mailto:[EMAIL PROTECTED]
> > > Sent: Monday, December 03, 2007 1:21 PM
> > > To: Andi Gutmans
> > > Cc: internals@lists.php.net
> > > Subject: Re: [PHP-DEV] Garbage collector patch
> > >
> > > On Dec 3, 2007 4:01 PM, Andi Gutmans <[E
ED]
> > Sent: Monday, December 03, 2007 1:21 PM
> > To: Andi Gutmans
> > Cc: internals@lists.php.net
> > Subject: Re: [PHP-DEV] Garbage collector patch
> >
> > On Dec 3, 2007 4:01 PM, Andi Gutmans <[EMAIL PROTECTED]> wrote:
> > > Hi all,
> > &
That'd be great.
Dmitry, David, can you please send the updated patch to the list?
Andi
> -Original Message-
> From: Markus Fischer [mailto:[EMAIL PROTECTED]
> Sent: Monday, December 03, 2007 1:31 PM
> To: Daniel Brown
> Cc: Andi Gutmans; internals@lists.php.net
>
Sorry about that. Does the attached PDFed screenshot work for you?
Andi
> -Original Message-
> From: Daniel Brown [mailto:[EMAIL PROTECTED]
> Sent: Monday, December 03, 2007 1:21 PM
> To: Andi Gutmans
> Cc: internals@lists.php.net
> Subject: Re: [PHP-DEV] Garbage colle
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Daniel Brown wrote:
> I don't know about how it worked for anyone else, but the tables
> didn't display properly on Gmail, so I had a hard time keeping up with
> the performance differences. If you have this in a separate file,
> could you se
On Dec 3, 2007 4:01 PM, Andi Gutmans <[EMAIL PROTECTED]> wrote:
> Hi all,
>
>
>
> Was hoping to send this off earlier but I was travelling for the past
> week and had very limited email access.
>
> As promised in the past few weeks we have spent a significant amount of
> time in reviewing the garba
86 matches
Mail list logo
