hi!
On Wed, Oct 24, 2012 at 10:47 PM, Eric Stenson erics...@microsoft.com wrote:
From: Anthony Ferrara [mailto:ircmax...@gmail.com]
[Pierre said:]
It is still the case.
I for one would like to kill all the legacy features or too specific
features which are really unusable by any
From: Anthony Ferrara [mailto:ircmax...@gmail.com]
[Pierre said:]
It is still the case.
I for one would like to kill all the legacy features or too specific
features which are really unusable by any common developers.
Other developers may disagree but it makes very hard to maintain
hi Tom,
On Wed, Jul 4, 2012 at 4:37 PM, Tom Boutell t...@punkave.com wrote:
Hmm, but the stat=0 optimization is a major one; a cache that didn't
offer it would be significantly slower in production for those who
know what they're doing, yes?
yes and no, really depends on the codes.
However
hi Rasmus,
On Tue, Jul 3, 2012 at 6:35 PM, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 07/03/2012 08:17 AM, Pierre Joye wrote:
I for one would like to kill all the legacy features or too specific
features which are really unusable by any common developers.
Other developers may disagree but
On 2012-07-03 20:49, Arvids Godjuks wrote:
One one side it's good to know i'm not wrong, on the other hand it's sad in
this case.
Sure about one thing - xcache is worth looking at and may be a better
choise than APC and has better potential.
One thing sure - I haven't heard anyone complaining
Hmm, but the stat=0 optimization is a major one; a cache that didn't
offer it would be significantly slower in production for those who
know what they're doing, yes?
(I haven't actually tried the stat=0 trick myself yet and don't have
performance numbers on its impact. I really ought to though,
On 07/04/2012 07:37 AM, Tom Boutell wrote:
Hmm, but the stat=0 optimization is a major one; a cache that didn't
offer it would be significantly slower in production for those who
know what they're doing, yes?
Depends on your code. For people who write code that needs to include
hundreds, or
Heh... passing a little judgment there on the design of frameworks,
ORMs, etc. are we?
On Wed, Jul 4, 2012 at 10:41 AM, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 07/04/2012 07:37 AM, Tom Boutell wrote:
Hmm, but the stat=0 optimization is a major one; a cache that didn't
offer it would be
This one:
*** glibc detected *** /usr/local/bin/php-cgi: double free or
corruption (out): 0x7f9d6ce2c080 ***
=== Backtrace: =
/lib/libc.so.6(+0x77806)[0x7f9d679be806]
/lib/libc.so.6(cfree+0x73)[0x7f9d679c50d3]
/usr/local/bin/php-cgi(destroy_zend_class+0x23d)[0x749f5d]
On 07/03/2012 07:13 AM, Tom Boutell wrote:
This one:
*** glibc detected *** /usr/local/bin/php-cgi: double free or
corruption (out): 0x7f9d6ce2c080 ***
=== Backtrace: =
/lib/libc.so.6(+0x77806)[0x7f9d679be806]
/lib/libc.so.6(cfree+0x73)[0x7f9d679c50d3]
Given the impracticality of using PHP without APC, it would be nice if
it were part of the main if these fail, it's not ready test suite.
But I suppose that's just administering beatings until morale improves
(:
On Tue, Jul 3, 2012 at 10:20 AM, Rasmus Lerdorf ras...@lerdorf.com wrote:
On
hi Tom,
On Tue, Jul 3, 2012 at 4:49 PM, Tom Boutell t...@punkave.com wrote:
Given the impracticality of using PHP without APC, it would be nice if
it were part of the main if these fail, it's not ready test suite.
But I suppose that's just administering beatings until morale improves
(:
hi,
On Tue, Jul 3, 2012 at 5:12 PM, Arvids Godjuks arvids.godj...@gmail.com wrote:
There are alternative opcode cachers besides APC. For example xcache, for
me, just works when APC is still catching up.
I remember someone writing about APC that it is overly compex internally
and due to that
There are alternative opcode cachers besides APC. For example xcache, for
me, just works when APC is still catching up.
I remember someone writing about APC that it is overly compex internally
and due to that hard to keep up with the changes in the PHP, maybe that is
not the case now.
But looking
Pierre,
It is still the case.
I for one would like to kill all the legacy features or too specific
features which are really unusable by any common developers.
Other developers may disagree but it makes very hard to maintain APC.
Perhaps that indicates it's time to pull the core of APC
It is still the case.
I for one would like to kill all the legacy features or too specific
features which are really unusable by any common developers.
Other developers may disagree but it makes very hard to maintain APC.
Perhaps that indicates it's time to pull the core of APC
The ability to store your own data in the APC cache is a feature that
does get used a lot in the Symfony framework world because of the
availability of the sfAPCCache and whatever its Symfony 2 equivalent
is. It's popular with folks who haven't felt the need to set up Redis
or some other external
On 07/03/2012 08:17 AM, Pierre Joye wrote:
I for one would like to kill all the legacy features or too specific
features which are really unusable by any common developers.
Other developers may disagree but it makes very hard to maintain APC.
There are really just two big features in APC.
One one side it's good to know i'm not wrong, on the other hand it's sad in
this case.
Sure about one thing - xcache is worth looking at and may be a better
choise than APC and has better potential.
One thing sure - I haven't heard anyone complaining about xcache. And
heard many complains about
On 07/03/2012 09:49 AM, Arvids Godjuks wrote:
One one side it's good to know i'm not wrong, on the other hand it's sad
in this case.
Sure about one thing - xcache is worth looking at and may be a better
choise than APC and has better potential.
One thing sure - I haven't heard anyone
Just to be clear - all 3 major opcode cachers i know (zend optimizer
excluded - have no idea what he has) have that shared memory cache with
almost identical API. Some have extended functionality (xcache has
xcache_isset(), haven't seen that in others, but have to confess i haven't
been looking
Could be, xcache is definetly dummer in features and it is its feature. I
guess it helps it to keep up with releases. I will investigate this today,
maybe get some interesting results worth to share here.
03.07.2012 16:54 пользователь Rasmus Lerdorf ras...@lerdorf.com написал:
On 07/03/2012
22 matches
Mail list logo
