On 06/20/2010 10:21 PM, Ilia Alshanetsky wrote:
I for one think it is a really good idea, there is no compelling
reason not to include APC, I would even go as far as say we should
enable it by default.
+1 on adding into the distro
-1 on enabling by default
--
Wbr,
Antony Dovgal
---
Ilia Alshanetsky wrote:
The test was done on Windows... I never said it was IIS only, it is however
win32 only.
Sorry - Most people using it will no have bought win64 yet was the point and the
test was done on win32 as far as I can tell. Anyway Pierre keeps saying that 64
bit is slower anyway
On Jun 20, 2010, at 10:06 PM, Rasmus Lerdorf wrote:
On 6/20/10 7:55 PM, Scott MacVicar wrote:
On Jun 20, 2010, at 11:21 AM, Ilia Alshanetsky wrote:
I for one think it is a really good idea, there is no compelling
reason not to include APC, I would even go as far as say we should
enable
Am 20.06.2010 20:21, schrieb Ilia Alshanetsky:
I for one think it is a really good idea, there is no compelling
reason not to include APC, I would even go as far as say we should
enable it by default.
+1 for bundling
+1 for removing the layer of checks for macros for PHP = 5.4
+1 for
Am 20.06.2010 23:07, schrieb Rasmus Lerdorf:
No, it is not enough to just have source code. The developers need to
play along as well.
Which reminds me: does anybody actually know who develops xcache? Last
time I checked the answer I found was: moo.
--
Sebastian Bergmann
On 21.06.2010, at 05:32, Stas Malyshev wrote:
Hi!
This is an unfixed PHP bug. There have been a number of threads about
the object destruction order on internals. It isn't just APC that is
affected by this. Other extensions are affected as well.
I understand that this effect is
Am 21.06.2010 09:33, schrieb Ferenc Kovacs:
What's the problem with moo?
You are not seriously asking that question, are you?
--
Sebastian BergmannCo-Founder and Principal Consultant
http://sebastian-bergmann.de/ http://thePHP.cc/
--
PHP
2010/6/21 Sebastian Bergmann s...@sebastian-bergmann.de:
Am 20.06.2010 20:21, schrieb Ilia Alshanetsky:
I for one think it is a really good idea, there is no compelling
reason not to include APC, I would even go as far as say we should
enable it by default.
+1 for bundling
+1 for removing
Ilia Alshanetsky i...@prohost.org wrote in message
news:aanlktilzlbbfucuv-jtmkm-qljl1il7wsqy0fyhn3...@mail.gmail.com...
Including into core of PHP has no impact on other opcode caches, if
they do a better job then APC, people can definitely (and should) use
them. The main purpose of
Rasmus Lerdorf ras...@lerdorf.com wrote in message
news:4c1ed90d.2030...@lerdorf.com...
On 6/20/10 7:44 PM, Stas Malyshev wrote:
Hi!
Can you elaborate? What average user-facing features are non-obvious?
We should document them if nothing else.
This recently caught my attention:
hi,
On Mon, Jun 21, 2010 at 10:58 AM, jvlad d...@yandex.ru wrote:
Rasmus Lerdorf ras...@lerdorf.com wrote in message
news:4c1ed90d.2030...@lerdorf.com...
On 6/20/10 7:44 PM, Stas Malyshev wrote:
Hi!
Can you elaborate? What average user-facing features are non-obvious?
We should document
This is an unfixed PHP bug. There have been a number of threads about
the object destruction order on internals. It isn't just APC that is
affected by this. Other extensions are affected as well.
I understand that this effect is caused by the fact that APC destroys PHP
classes earlier
By the way, including APC in the core is actually likely to fix this
problem because it has to do with the order the rshutdown functions are
called. Read Christian's excellent description of the problem here:
http://news.php.net/php.internals/46999
-Rasmus
concerting
On Mon, Jun 21, 2010 at 11:31 AM, jvlad d...@yandex.ru wrote:
keep on the topic pls, which is the inclusion of potentially buggy and
poorly maintained APC.
I'm on topic. You seem to be able to fix this bug very easily, I only
told you how to provide patches.
APC is well maintained but all I
keep on the topic pls, which is the inclusion of potentially buggy and
poorly maintained APC.
I'm on topic. You seem to be able to fix this bug very easily, I only
told you how to provide patches.
I do not care of bugs in APC unless this module is NOT in php core.
If they appear in php core,
On Mon, Jun 21, 2010 at 11:55 AM, jvlad d...@yandex.ru wrote:
keep on the topic pls, which is the inclusion of potentially buggy and
poorly maintained APC.
I'm on topic. You seem to be able to fix this bug very easily, I only
told you how to provide patches.
I do not care of bugs in APC
This bug is not APC specific.
In this case you can easily point out to another module suffering from this
bug, don't you?
License argument does not work at all.
It does, more than ever.
Then is there any reason not to add all code compatible in php license terms
into php core?
If not,
hi,
On Mon, Jun 21, 2010 at 12:30 PM, jvlad d...@yandex.ru wrote:
This bug is not APC specific.
In this case you can easily point out to another module suffering from this
bug, don't you?
License argument does not work at all.
It does, more than ever.
Then is there any reason not to
On windows it is even easier, just don't load the dll file, most
extensions other then PCRE (?) are compiled as modules anyway... APC
would be no different, and I would go as far as saying that on Win32
Wincache is probably a better choice.
On Mon, Jun 21, 2010 at 2:15 AM, Lester Caine
Ilia Alshanetsky wrote:
I for one think it is a really good idea, there is no compelling
reason not to include APC, I would even go as far as say we should
enable it by default.
+1
+1 for including APC
-1 for enabling by default
It was already agreed to include it into 6 before so why the
Then is there any reason not to add all code compatible in php license
terms
into php core?
What are you talking about? Who said that we have to add any php
licensed code to the core? I only said that the license is a critical
part of the decision. Nothing else.
APC can be added, this
Same here.
+1 to bundle
-1 to enable it by default
On 21 Jun 2010 13:05, Rob Richards rricha...@php.net wrote:
Ilia Alshanetsky wrote:
I for one think it is a really good idea, there is no compelling
reaso...
+1 for including APC
-1 for enabling by default
It was already agreed to include
On 2010-06-19, Kalle Sommer Nielsen ka...@php.net wrote:
Greetings
What are your views on including APC in the core, or reasons not to?
+1 moving it into core
-1 enabling by default
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 21.06.2010, at 13:07, jvlad wrote:
Competition between opcode caches for php will definitely be reduced by
adding APC into the core,
so the market will shrink, of course.
i think this is a likely outcome indeed. it might also be phrased in a more
positive tone in that likely efforts
On 19 June 2010 14:23, Kalle Sommer Nielsen ka...@php.net wrote:
What are your views on including APC in the core, or reasons not to?
+1 Added to core
-1 Enabled by default
If APC is not as stable on Windows as required _AND_ licensing issues
are resolvable, could WinCache for Windows be an
Ilia Alshanetsky wrote:
On windows it is even easier, just don't load the dll file, most
extensions other then PCRE (?) are compiled as modules anyway... APC
would be no different, and I would go as far as saying that on Win32
Wincache is probably a better choice.
As long as these are added as
Competition between opcode caches for php will definitely be reduced by
adding APC into the core,
so the market will shrink, of course.
i think this is a likely outcome indeed. it might also be phrased in a
more
positive tone in that likely efforts will be joined. for example maybe
zend
On Sun, Jun 20, 2010 at 11:39:30PM -0400, Ilia Alshanetsky wrote:
Stas,
If there is a better alternative to APC we can bundle with PHP, I am
definitely open to exploring that idea. However the alternatives I am
familiar either are closed source or have licences incompatible with
PHP, and
On 06/21/2010 04:32 PM, Jim Jagielski wrote:
As a PHP user, when moving to PHP 5.3, from 5.2 I had the question
regarding which accel to use (I had been using APC). From most
of what I read, APC was not compatible and looking at the APC site,
the last 'stable' release was ~2years ago with a
Hello Oliver,
looking at php.ini configuration I don't see any suhosin entry, so I think
no.
do you know if there is another way to understand if it is installed?
On Sun, Jun 20, 2010 at 12:06 PM, Olivier B. php-dev.l...@daevel.fr wrote:
Hi,
are you using the suhosin patch for PHP ? I can
Check the output of phpinfo()
should see
This server is protected with the Suhosin Patch
and/or
This server is protected with the Suhosin Extension
Tyrael
On Mon, Jun 21, 2010 at 4:48 PM, Vincenzo D'Amore v.dam...@gmail.comwrote:
Hello Oliver,
looking at php.ini configuration I don't see any
I would like to know why a third party can develop a better (or more agile?)
cache than the core php devs. I would think that if anyone can align it nicely
especially when writing the core code itself and could also think about this
is a great place for apc to hook in or something. It's
Thanks Rasmus,
we are using wordpress. Looking at code:
find . -type f -exec grep realpath {} \;
I see a lot of:
if ( function_exists('realpath') )
$path = realpath($path);
if ( function_exists('realpath') )
$path = realpath($path);
if ( function_exists('realpath') )
$path = realpath($path);
Thanks Ferenc,
there is non Suhosin patch/extension installed.
On Mon, Jun 21, 2010 at 4:52 PM, Ferenc Kovacs i...@tyrael.hu wrote:
Check the output of phpinfo()
should see
This server is protected with the Suhosin Patch
and/or
This server is protected with the Suhosin Extension
Tyrael
Rasmus,
I have disabled realpath from php.ini,
disable_functions =
passthru,proc_close,proc_get_status,proc_nice,proc,exec,shell_exec,system,proc_open,popen,curl_multi_exec,parse_ini_file,show_source,set_time_limit,error_reporting,mail,fsockopen,ini_set,
*realpath*
And stop and start of apache
Hello All,
could anybody tell me why also for every single php file engine must lstat
all path?
Why php engine don't simply try to open directly the file?
[pid 13792] lstat(/usr, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
[pid 13792] lstat(/usr/local, {st_mode=S_IFDIR|0755, st_size=4096,
hi,
On Mon, Jun 21, 2010 at 7:23 PM, Vincenzo D'Amore v.dam...@gmail.com wrote:
Hello All,
could anybody tell me why also for every single php file engine must lstat
all path?
It is done once per paths set and then cached.
Why php engine don't simply try to open directly the file?
Many
On 6/21/10 9:35 AM, Vincenzo D'Amore wrote:
Thanks Rasmus,
we are using wordpress. Looking at code:
find . -type f -exec grep realpath {} \;
I see a lot of:
if ( function_exists('realpath') )
$path = realpath($path);
if ( function_exists('realpath') )
$path = realpath($path);
if (
From my point-of-view as a developer (and occasional sysadmin) this is
something which I have been looking forward too for some time so
+1 for including in core
+1 for compiling but not enabling
Marco
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
yes
Tyrael
On Mon, Jun 21, 2010 at 9:09 PM, Sufficool, Stanley
ssuffic...@rov.sbcounty.gov wrote:
Trunk no longer contains main/safe_mode.c
Is this being removed?
make: *** No rule to make target `/php-src/main/safe_mode.c', needed by
`main/safe_mode.lo'. Stop.
--
PHP Internals - PHP
OK, order of operations problem. Remove references, then remove file or no one
can build. ;-)
When will this be complete?
-Original Message-
From: tyr...@gmail.com [mailto:tyr...@gmail.com] On Behalf Of Ferenc Kovacs
Sent: Monday, June 21, 2010 12:12 PM
To: Sufficool, Stanley
Cc:
On Mon, Jun 21, 2010 at 9:16 PM, Sufficool, Stanley
ssuffic...@rov.sbcounty.gov wrote:
OK, order of operations problem. Remove references, then remove file or no
one can build. ;-)
When will this be complete?
It builds just fine. Be sure to:
- make clean
- buildconf
before trying again :)
-Original Message-
From: Pierre Joye [mailto:pierre@gmail.com]
Sent: Monday, June 21, 2010 12:18 PM
To: Sufficool, Stanley
Cc: Ferenc Kovacs; internals@lists.php.net
Subject: Re: [PHP-DEV] Safemode Missing?
On Mon, Jun 21, 2010 at 9:16 PM, Sufficool, Stanley
Hi!
could anybody tell me why also for every single php file engine must lstat
all path?
Why php engine don't simply try to open directly the file?
There are some places where PHP engine has to know true name of the
file - i.e. filename that would be the same for each file regardless of
how
On Tue, 22 Jun 2010, Kalle Sommer Nielsen wrote:
It seems like theres been enough votes for moving it to the core, is
there anyone willing to make that change? Rasmus or Derick? We can
always decide whether to enable it by default afterwards.
I can do it; but the question is whether we want
Hi
It seems like theres been enough votes for moving it to the core, is
there anyone willing to make that change? Rasmus or Derick? We can
always decide whether to enable it by default afterwards.
As for enabled it by default, I think it should be okay to atleast
enable it as a shared extension
hi,
On Tue, Jun 22, 2010 at 12:21 AM, Derick Rethans der...@php.net wrote:
On Tue, 22 Jun 2010, Kalle Sommer Nielsen wrote:
It seems like theres been enough votes for moving it to the core, is
there anyone willing to make that change? Rasmus or Derick? We can
always decide whether to enable
On Jun 21, 2010, at 10:02 PM, Zeev Suraski wrote:
At 14:09 21/06/2010, Pierre Joye wrote:
Same here.
+1 to bundle
-1 to enable it by default
Slightly late to the game but my view is the same, +1 to bundle, -1 to enable
by default.
Is it too late to discuss the topic of leaving
48 matches
Mail list logo
