But if even that is too hard, how about making something like spec file
for RPM and a script that d/ls a snapshot and then builds a RPM from it?
Installing RPM shouldn't be too hard?
Why reinvent the wheel? The open build service already exists and does
just that. No need for hundreds of laymen
2013.01.30. 0:01, "Stas Malyshev" ezt írta:
>
> Hi!
>
> > Can somebody shed some light why:
> >
> > >
> > echo new SplFileObject(__FILE__);
>
> __toString is mapped to current() for SplFileObject:
> http://www.php.net/manual/en/splfileobject.current.php
>
> it's not documented for some re
hi,
On Wed, Jan 30, 2013 at 7:42 AM, Stas Malyshev wrote:
> Hi!
>
>> I did not check latest ICU code base but we never had any issues in
>> intl in ZTS. However you are right, since 5.3.0 most TS issues were in
>
> One of them has to do with number formatting, so if you have a number of
> apps th
Hi!
> Right, but they do not give up thread safety. See "Thread State and
> the Global Interpreter Lock" in:
>
> http://docs.python.org/2/c-api/init.html
That's whole different concept of thread safety. It's basically saying
"you can do anything you want outside of Python engine but only one
thr
Hi!
> I did not check latest ICU code base but we never had any issues in
> intl in ZTS. However you are right, since 5.3.0 most TS issues were in
One of them has to do with number formatting, so if you have a number of
apps that use different locale settings on the same server, which have
differ
On 01/30/2013 07:09 AM, Pierre Joye wrote:
> On Wed, Jan 30, 2013 at 2:15 AM, Stas Malyshev
wrote:
>> Hi!
>>
>>> Python, for example, is thread safe by default. Extensions developers
>>
>> Doesn't Python have global engine lock?
>
> Right, but they do not give up thread safety. See "Thread State a
On Wed, Jan 30, 2013 at 2:15 AM, Stas Malyshev wrote:
> Hi!
>
>> Python, for example, is thread safe by default. Extensions developers
>
> Doesn't Python have global engine lock?
Right, but they do not give up thread safety. See "Thread State and
the Global Interpreter Lock" in:
http://docs.pyth
On Wed, Jan 30, 2013 at 12:49 AM, Stas Malyshev wrote:
> Hi!
>
>> There are situations where FPM/FCGI are not appropriate, or the server
>> used does not support NTS (Apache windows for example, when fcgi is
>> not an option).
>
> Why Apache can't use FCGI? There's no proper driver os something in
Hi!
> down. Right or wrong, good or bad, the gulf between PHP developer and C
> developer is *huge*, and doing anything at all with the PHP engine,
We're not talking here writing code in C. We're talking here typing
"configure" in shell, hitting enter, then typing "make" in shell, then
hitting
hi,
On Wed, Jan 30, 2013 at 6:51 AM, Jan Ehrhardt wrote:
> Pierre Joye in php.internals (Wed, 30 Jan 2013 06:42:51 +0100):
>>On Jan 30, 2013 1:30 AM, "Jan Ehrhardt" wrote:
>>>
>>http://windows.php.net/downloads/snaps/ostc/pftt/perf/results-20130125-5.5.0alpha4-5.5rd86e14b.html
>>>
>>> I am a lit
On Wed, Jan 30, 2013 at 1:17 AM, Christopher Jones
wrote:
> The RFC still mentions Pierre helping with ZTS, which I believe is a
> left-over comment??
No, it is on purpose and a pro for those worrying about ZTS.
Cheers,
--
Pierre
@pierrejoye
--
PHP Internals - PHP Runtime Development Mailing
Pierre Joye in php.internals (Wed, 30 Jan 2013 06:42:51 +0100):
>On Jan 30, 2013 1:30 AM, "Jan Ehrhardt" wrote:
>>
>http://windows.php.net/downloads/snaps/ostc/pftt/perf/results-20130125-5.5.0alpha4-5.5rd86e14b.html
>>
>> I am a little surprised you are still using Apache 2.2 as test
>> environmen
On Jan 30, 2013 1:30 AM, "Jan Ehrhardt" wrote:
>
> Pierre Joye in php.internals (Tue, 29 Jan 2013 18:23:59 +0100):
> >Zero skills are required to setup a PHP. But a bit more clue is
> >required to test Drupal. I can help the PHP setup automation but would
> >need your help to setup D7+ setup with
On 01/29/2013 08:45 PM, Larry Garfield wrote:
> On 01/29/2013 03:12 PM, Rasmus Lerdorf wrote:
>>
>>> If I could run my own VM (that much I can do) and periodically just do
>>> apt-get update php-head, that would lower the barrier to testing new
>>> versions by several orders of magnitude. (Yeah ye
Larry Garfield in php.internals (Tue, 29 Jan 2013 22:45:17 -0600):
>On 01/29/2013 03:12 PM, Rasmus Lerdorf wrote:
>>
>> Is building from git really that much harder? Yes, it takes a little bit
>> of tweaking to get your configure flags right and getting all the right
>> dev versions of the dependen
On 01/29/2013 03:12 PM, Rasmus Lerdorf wrote:
If I could run my own VM (that much I can do) and periodically just do
apt-get update php-head, that would lower the barrier to testing new
versions by several orders of magnitude. (Yeah yeah insert RPM vs. Apt
debate here; both are good to have.)
On 01/29/2013 04:27 PM, Rasmus Lerdorf wrote:
On 01/29/2013 04:17 PM, Christopher Jones wrote:
It would be useful to link to the current Optimizer+ doc from the RFC.
I believe the link is
http://static.zend.com/topics/Zend-Optimizer-User-Guide-v330-new.pdf
Different beast. Something like thi
Hi!
> Python, for example, is thread safe by default. Extensions developers
Doesn't Python have global engine lock?
> It was and still is a lazy and design mistake to have focused on
> FastCGI to support PHP on IIS more easily, while everything else in
> this stack uses what the whole OS stack d
On 01/29/2013 04:47 PM, Stas Malyshev wrote:
> Hi!
>
>> which shows the dreaded zend_optimizerplus.inherited_hack which mimics
>> APC's autofilter hack. I'd love to get rid of this particular bit of
>> confusion/code complexity on the integration.
>
> Ohh, this one. IIRC that has to do with condi
Hi!
I think having stuff on the wiki is nice, but for things related to the
code - e.g., APIs, builds descriptions, etc. - they should stay in the
code. They are easier to find there and easier to keep up-to-date, and
also ensure they have the content relevant to specific version. We could
have a
Hi!
> which shows the dreaded zend_optimizerplus.inherited_hack which mimics
> APC's autofilter hack. I'd love to get rid of this particular bit of
> confusion/code complexity on the integration.
Ohh, this one. IIRC that has to do with conditional definition of
classes and the fact that script ma
Hi!
> I like it. It would be totally awesome if it came with a webinar or
> something where Dmitry/Stas explain how it works though. Understanding
> how APC works has always been a contentious point. I'd be awesome if we
> could turn that around with O+?
Once the code is out there, I think it'
Hi!
> I don't doubt any of your abilities, what I do doubt is that how we
> can consider an outside project directly into the core. APC would
How it's more "outside product" than any of the other extensions we
brought to the core?
> without a doubt be up to pair if there was more people willingl
Pierre Joye in php.internals (Tue, 29 Jan 2013 18:23:59 +0100):
>Zero skills are required to setup a PHP. But a bit more clue is
>required to test Drupal. I can help the PHP setup automation but would
>need your help to setup D7+ setup with major plugins to automate the
>tests. By the way, we alrea
On 01/29/2013 04:17 PM, Christopher Jones wrote:
> It would be useful to link to the current Optimizer+ doc from the RFC.
> I believe the link is
> http://static.zend.com/topics/Zend-Optimizer-User-Guide-v330-new.pdf
Different beast. Something like this is more apt:
http://files.zend.com/help/pre
On 01/29/2013 12:30 AM, Zeev Suraski wrote:
By the way, I just realized the % gain wasn't all that self-explanatory -
it's vs. APC, not vs. plain PHP. I improved the doc to reflect both gains
vs. plain PHP and vs. APC.
Thanks for the feedback!
Zeev
Zeev,
It would be useful to link to th
Hi!
> Of course an opcode cache isn't shred-nothing either, and maybe sharing
> opcodes within a process is faster than doing this in shared memory.
I don't think so. IIRC main time is spent of two things: building
runtime structures from storage formats (because we mess with our
structures in r
Hi!
> There are situations where FPM/FCGI are not appropriate, or the server
> used does not support NTS (Apache windows for example, when fcgi is
> not an option).
Why Apache can't use FCGI? There's no proper driver os something in
Apache architecture prevents it from using FCGI?
> No. My idea
On Tue, Jan 29, 2013 at 11:49 PM, Ralf Lang wrote:
> The one thing apt-get/zypper saves is time. You eliminate the commit
> states which won't build at all, at least for the end users. Now they
> have more time to figure how they make their legacy code work with the
> newest git PHP and why their
Hi!
> Can somebody shed some light why:
>
>
> echo new SplFileObject(__FILE__);
__toString is mapped to current() for SplFileObject:
http://www.php.net/manual/en/splfileobject.current.php
it's not documented for some reason, I think it makes sense to file a
docs bug on that.
--
Stan
This feels like a bug to me. Why would SplFileObject::__toString return the
current line while SplFileInfo::__toString returns file path?
On Tue, Jan 29, 2013 at 5:51 PM, Ferenc Kovacs wrote:
> On Tue, Jan 29, 2013 at 11:29 PM, hakre wrote:
>
> > Can somebody shed some light why:
> >
> >
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/29/2013 02:49 PM, Ralf Lang wrote:
> The one thing apt-get/zypper saves is time. You eliminate the
> commit states which won't build at all, at least for the end users.
> Now they have more time to figure how they make their legacy code
> work wi
This is why I think the best way to deal with the situation is
distributing nightly builds. First of all, we could use the
distributions' make-package files to build the package. And what if it
returns with an error code? Big deal, either no new nightly build on
that day (and report a failure to a
On Tue, Jan 29, 2013 at 11:29 PM, hakre wrote:
> Can somebody shed some light why:
>
>
> echo new SplFileObject(__FILE__);
>
> returns the first line of the file (in that case `
> SplFileInfo has the path and SplFileObject extends from it but it will
> return the current line. I do not r
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> Is building from git really that much harder? Yes, it takes a
> little bit of tweaking to get your configure flags right and
> getting all the right dev versions of the dependencies installed,
> but at least on Debian/Ubuntu (since you mentioned apt)
Can somebody shed some light why:
http://www.php.net/unsub.php
On 1/29/13 3:47 AM, Martin Keckeis wrote:
From the perspective of the end-user this would be really great!
If it could really be done in 2 months -> wait for it.
best regards.
Considering the importance of opcode caches to any serious project these
days, I'd say a 2 month delay to get an int
Pierre Joye in php.internals (Tue, 29 Jan 2013 05:55:27 +0100):
>Question: Did you test D7/8 and their respective plugins with php 5.5?
OK. A part of that challenge I took: compile PHP 5.5 Alpha 4 ZTS for
Windows with as many extensions as I could. The result:
http://dl.dropbox.com/u/8954372/php-
On 2013-01-29, Zeev Suraski wrote:
> --e89a8fb1f5b0f501b204d468d53f
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: quoted-printable
>
> All,
>
>
>
> Following the discussion at the end of last week, I prepared a draft RFC
> for the inclusion of Optimizer+ in PHP.
>
> In par
On 2013-01-28, Zeev Suraski wrote:
> --e89a8fb1fbd85c066a04d455d2d7
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: quoted-printable
>
>
> The specific case in point is
> https://wiki.php.net/rfc/propertygetsetsyntax-v1.2 - which while has more
> supporters than opposers, co
On 01/29/2013 01:12 PM, Rasmus Lerdorf wrote:
> I realize this is slightly more complicated than an apt-get, but
> pre-building packages that will work with all the combinations of
> libraries and things out there is a PITA. By building your own you get
> to choose everything by editing your cn scr
On Jan 29, 2013 9:42 PM, "Johannes Schlüter" wrote:
>
> On Tue, 2013-01-29 at 13:13 +0100, Pierre Joye wrote:
> > On Tue, Jan 29, 2013 at 1:01 PM, Johannes Schlüter
>
> So at least on my Linux box there is an issue around the usage of
> setlocale(). Gues this won't show on Windows as Windows loca
On 01/29/2013 12:43 PM, Larry Garfield wrote:
> On 1/29/13 11:46 AM, Ralf Lang wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Am 29.01.2013 18:38, schrieb Pierre Joye:
>>> On Tue, Jan 29, 2013 at 6:24 PM, Attila Bukor
>>> wrote:
I think Ralf's idea is great. A lot of other p
On 1/29/13 11:46 AM, Ralf Lang wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 29.01.2013 18:38, schrieb Pierre Joye:
On Tue, Jan 29, 2013 at 6:24 PM, Attila Bukor
wrote:
I think Ralf's idea is great. A lot of other projects use nightly
builds successfully. I don't think a vbox image
On Tue, 2013-01-29 at 13:13 +0100, Pierre Joye wrote:
> On Tue, Jan 29, 2013 at 1:01 PM, Johannes Schlüter
> wrote:
>
> > There were mysqli threading bugs, the last one of those actually had
> > been engine bugs which affected other extensions, too. See i.e.
> > http://news.php.net/php.internals/
On 1/29/13 12:31 PM, Steve Clay wrote:
On 1/29/13 11:55 AM, Larry Garfield wrote:
[3] We have a CI system in place but it's home grown, doesn't have
enough human resources
maintaining it, and I don't think it supports multiple variants of the
PHP environment
Dunno if this was mentioned here, b
Hi!
> Also can I obtain some information on the current state of new function
> extending regarding acceptance of a patch for bug #38917? (bug
> report/feature request at https://bugs.php.net/bug.php?id=38917)
The patch in this pull: https://github.com/php/php-src/pull/37 has some
memory leaks an
On 1/29/13 2:17 PM, Jordi Boggiano wrote:
Travis is still running 5.5.0-alpha1 that segfaults under some
conditions when using composer which makes a lot of builds fails for
nothing.
How Symfony deals with this:
matrix:
allow_failures:
- php: 5.5
Steve Clay
--
http://www.mrclay.org/
-
Heya,
> Dunno if this was mentioned here, but Travis CI added a 5.5 environment
> a few weeks ago. Spreading the word to projects to add 5.5 to their
> config files (or just sending a PR) would be a quick way to get a lot of
> code hitting 5.5.
Travis is still running 5.5.0-alpha1 that segfaults
Sent from my iPhone 6 Beta [Confidential use only]
On 29 jan. 2013, at 18:02, Pierre Joye wrote:
> On Tue, Jan 29, 2013 at 5:54 PM, Zeev Suraski wrote:
>> On 29 בינו 2013, at 17:54, Derick Rethans wrote:
>>
>>> On Tue, 29 Jan 2013, Zeev Suraski wrote:
>>>
Following the discussion at th
On 1/29/13 11:55 AM, Larry Garfield wrote:
[3] We have a CI system in place but it's home grown, doesn't have enough human
resources
maintaining it, and I don't think it supports multiple variants of the PHP
environment
Dunno if this was mentioned here, but Travis CI added a 5.5 environment a
On Tue, Jan 29, 2013 at 6:46 PM, Ralf Lang wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Am 29.01.2013 18:38, schrieb Pierre Joye:
> > On Tue, Jan 29, 2013 at 6:24 PM, Attila Bukor
> > wrote:
> >> I think Ralf's idea is great. A lot of other projects use nightly
> >> builds succes
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 29.01.2013 18:38, schrieb Pierre Joye:
> On Tue, Jan 29, 2013 at 6:24 PM, Attila Bukor
> wrote:
>> I think Ralf's idea is great. A lot of other projects use nightly
>> builds successfully. I don't think a vbox image would be
>> necessary as no-one
On Tue, Jan 29, 2013 at 6:24 PM, Attila Bukor wrote:
> I think Ralf's idea is great. A lot of other projects use nightly builds
> successfully. I don't think a vbox image would be necessary as no-one
> would use nightly builds on a production environment,
It is not about using anything in prod bu
I think Ralf's idea is great. A lot of other projects use nightly builds
successfully. I don't think a vbox image would be necessary as no-one
would use nightly builds on a production environment, but if web developers
who feel a little adventurous could add an official PHP nightly-build
repository
hi Larry,
On Tue, Jan 29, 2013 at 5:55 PM, Larry Garfield wrote:
> On 1/29/13 5:08 AM, Pierre Joye wrote:
>>
>> hi Jan,
>>
>> On Tue, Jan 29, 2013 at 11:55 AM, Jan Ehrhardt wrote:
>>>
>>> Hi Pierre,
>>>
>>> Pierre Joye in php.internals (Tue, 29 Jan 2013 05:55:27 +0100):
This is one of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 29.01.2013 17:55, schrieb Larry Garfield:
> On 1/29/13 5:08 AM, Pierre Joye wrote:
>> hi Jan,
>>
>> On Tue, Jan 29, 2013 at 11:55 AM, Jan Ehrhardt
>> wrote:
>>> Hi Pierre,
>>>
>>> Pierre Joye in php.internals (Tue, 29 Jan 2013 05:55:27
>>> +0100)
On Tue, Jan 29, 2013 at 5:54 PM, Zeev Suraski wrote:
> On 29 בינו 2013, at 17:54, Derick Rethans wrote:
>
>> On Tue, 29 Jan 2013, Zeev Suraski wrote:
>>
>>> Following the discussion at the end of last week, I prepared a draft
>>> RFC for the inclusion of Optimizer+ in PHP.
>>>
>>> In parallel we’
On 1/29/13 5:08 AM, Pierre Joye wrote:
hi Jan,
On Tue, Jan 29, 2013 at 11:55 AM, Jan Ehrhardt wrote:
Hi Pierre,
Pierre Joye in php.internals (Tue, 29 Jan 2013 05:55:27 +0100):
This is one of the reason why the 'new' release process RFC does not
allow BC breaks. But we can't be 100% sure that
On 29 בינו 2013, at 17:54, Derick Rethans wrote:
> On Tue, 29 Jan 2013, Zeev Suraski wrote:
>
>> Following the discussion at the end of last week, I prepared a draft
>> RFC for the inclusion of Optimizer+ in PHP.
>>
>> In parallel we’re in the process of prepping the source code for
>> independen
On Tue, 29 Jan 2013, Bob Weinand wrote:
> Am 29.1.2013 um 15:58 schrieb Derick Rethans :
>
> > I wouldn't bother making it work with ZTS. If you want performance,
> > you shouldn't be using it, and the other case I heard was "pthreads"
> > in which case it plays no role,as all of the script is
On 29 בינו 2013, at 17:45, "Ángel González" wrote:
> On 29/01/13 15:21, Pierre Joye wrote:
>> On Tue, Jan 29, 2013 at 3:16 PM, Zeev Suraski wrote:
>>> On Windows with impersonation you're actually in a better situation than
>>> you are in Linux. You could hold a small pool of processes and hand
Am 29.01.2013 16:54, schrieb Derick Rethans:
> I like it. It would be totally awesome if it came with a webinar or
> something where Dmitry/Stas explain how it works though. Understanding
> how APC works has always been a contentious point. I'd be awesome if we
> could turn that around with O+?
On Tue, Jan 29, 2013 at 4:43 PM, Ángel González wrote:
> On 29/01/13 15:21, Pierre Joye wrote:
>> On Tue, Jan 29, 2013 at 3:16 PM, Zeev Suraski wrote:
>>> On Windows with impersonation you're actually in a better situation than
>>> you are in Linux. You could hold a small pool of processes and h
On Tue, 29 Jan 2013, Zeev Suraski wrote:
> Following the discussion at the end of last week, I prepared a draft
> RFC for the inclusion of Optimizer+ in PHP.
>
> In parallel we’re in the process of prepping the source code for
> independent public consumption, which I hope we can be done with b
On Tue, Jan 29, 2013 at 4:32 PM, Lester Caine wrote:
> Ferenc Kovacs wrote:
>
>> On Tue, Jan 29, 2013 at 1:29 PM, Lester Caine wrote:
>>
>> Can someone please fill in a little information here. When we start
>>> looking at multiple threads doing for example database lookups in
>>> parallel
>>>
On 29/01/13 15:21, Pierre Joye wrote:
> On Tue, Jan 29, 2013 at 3:16 PM, Zeev Suraski wrote:
>> On Windows with impersonation you're actually in a better situation than
>> you are in Linux. You could hold a small pool of processes and handle as
>> many different users as you'd like.
> Works fine
Ferenc Kovacs wrote:
On Tue, Jan 29, 2013 at 1:29 PM, Lester Caine wrote:
Can someone please fill in a little information here. When we start
looking at multiple threads doing for example database lookups in parallel
with the main page generation. Does that involve 'thread safe' or is it
done
> -Original Message-
> From: Lars Strojny [mailto:l...@strojny.net]
> Sent: Tuesday, January 29, 2013 4:33 PM
> To: Rasmus Lerdorf
> Cc: Nikita Popov; internals@lists.php.net
> Subject: Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP
> distribution
>To get more practical, I se
Kalle Sommer Nielsen wrote:
2013/1/29 Lester Caine :
I'll get my head chewed off again, but can we no consider doing that as PHP6
given that 6.0.x could be a development stage. I would perhaps then strongly
lobby for 'only' having E_STRICT mode so things like 'static $this' go by
the by anyway?
Am 29.1.2013 um 15:58 schrieb Derick Rethans :
> I wouldn't bother making it work with ZTS. If you want performance, you
> shouldn't be using it, and the other case I heard was "pthreads" in
> which case it plays no role,as all of the script is in memory anyway
> for the duration of the process
On Tue, 29 Jan 2013, Zeev Suraski wrote:
> From: Clint Priest [mailto:cpri...@zerocue.com]:
>
> > On 1/29/2013 5:23 AM, Anthony Ferrara wrote:
> >
> > > Additionally, I don't like the precedent that this sets for future
> > > releases. That it's ok to break the timebox for some feature. In
> > >
2013/1/29 Lester Caine :
> I'll get my head chewed off again, but can we no consider doing that as PHP6
> given that 6.0.x could be a development stage. I would perhaps then strongly
> lobby for 'only' having E_STRICT mode so things like 'static $this' go by
> the by anyway? This would not rule out
Kalle Sommer Nielsen wrote:
2013/1/29 Zeev Suraski:
>The RFC explains the pros and cons of doing that, I don't really have any
>additional reasons to add beyond what I already put there. I believe the
>pros outweigh the cons by a good considerable margin, but that's what the
>vote would be abou
On Tue, Jan 29, 2013 at 3:21 PM, Rasmus Lerdorf wrote:
> On 01/29/2013 06:13 AM, Nikita Popov wrote:
>
> > I'm not sure I fully understand this. The RFC claims that Optimizer+ is
> > already *now* fully compatible with PHP 5.5. And that it was also
> > compatible when PHP 5.4 was released. So the
On Tue, 29 Jan 2013, Ferenc Kovacs wrote:
> I think some of the README files currently present in the php-src repo
> would be better kept in the wiki and some of them are already
> duplicated/made redundant by our existing wiki pages.
Please leave them in the source tree. They describe how APIs
On Tue, 29 Jan 2013, Zeev Suraski wrote:
> Which brings me to the subject of this mail – why are you using ZTS
> PHP instead of single threaded PHP? The reasons not to use it are few
> but fairly major – it’s significantly slower than the non-ZTS PHP, and
> it’s significantly less robust in th
Hi Zeev,
Am 29.01.2013 um 15:21 schrieb Rasmus Lerdorf :
> On 01/29/2013 06:13 AM, Nikita Popov wrote:
>
>> I'm not sure I fully understand this. The RFC claims that Optimizer+ is
>> already *now* fully compatible with PHP 5.5. And that it was also
>> compatible when PHP 5.4 was released. So the
On Tue, 2013-01-29 at 14:18 +0100, Pierre Joye wrote:
>
>
> As far as I remember, we already do that for a couple of web servers.
> And in the long run, I will rather tell not to use FastCGI for
> dedicated hosting and the likes. That being said, I also met many ISPs
> which are not happy with th
2013/1/29 Zeev Suraski :
> I'd would of course prefer that we evaluate the proposal based on the
> substance and not on other factors, but that said, I fully respect your
> position and wouldn't hold it against you if you vote 'no'...
My vote will ofcourse also take the RFC into consideration, els
On 01/29/2013 06:13 AM, Nikita Popov wrote:
> I'm not sure I fully understand this. The RFC claims that Optimizer+ is
> already *now* fully compatible with PHP 5.5. And that it was also
> compatible when PHP 5.4 was released. So they lack of a working and free
> opcode cache clearly wasn't the iss
On Tue, Jan 29, 2013 at 3:16 PM, Zeev Suraski wrote:
>> -Original Message-
>> From: Pierre Joye [mailto:pierre@gmail.com]
>> Sent: Tuesday, January 29, 2013 3:37 PM
>> To: Rasmus Lerdorf
>> Cc: PHP internals
>> Subject: Re: [PHP-DEV] ZTS - why are you using it?
>>
>> On Tue, Jan 29, 20
> -Original Message-
> From: Pierre Joye [mailto:pierre@gmail.com]
> Sent: Tuesday, January 29, 2013 3:37 PM
> To: Rasmus Lerdorf
> Cc: PHP internals
> Subject: Re: [PHP-DEV] ZTS - why are you using it?
>
> On Tue, Jan 29, 2013 at 2:33 PM, Rasmus Lerdorf
> wrote:
>
> > Those ISPs are p
> -Original Message-
> From: Pierre Joye [mailto:pierre@gmail.com]
> Sent: Tuesday, January 29, 2013 3:19 PM
> To: Zeev Suraski
> Cc: Johannes Schlüter; PHP internals
> Subject: Re: [PHP-DEV] ZTS - why are you using it?
>
> On Tue, Jan 29, 2013 at 1:52 PM, Zeev Suraski wrote:
> >>
On Tue, Jan 29, 2013 at 2:52 PM, Rasmus Lerdorf wrote:
> On 01/29/2013 05:30 AM, Clint Priest wrote:
>
> > 2) Isn't APC the standard? Is it in such bad shape it is not even being
> > considered any longer?
>
> As it currently stands from a developer participation standpoint it is
> not viable. I
On Fri, Sep 14, 2012 at 12:47 PM, Pierre Joye wrote:
> hi Ferenc,
>
> Can you put that in the wiki too instead? So it can be clarified there
> directly if necessary.
>
> Thanks,
>
>
I've put it up under https://wiki.php.net/rfc/howto feel free to extend or
improve the wording/formatting.
--
Fer
> -Original Message-
> From: kalle@gmail.com [mailto:kalle@gmail.com] On Behalf Of
Kalle
> Sommer Nielsen
> Sent: Tuesday, January 29, 2013 3:45 PM
> To: Zeev Suraski
> Cc: internals@lists.php.net
> Subject: Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP
> distribution
On 01/29/2013 05:30 AM, Clint Priest wrote:
> 2) Isn't APC the standard? Is it in such bad shape it is not even being
> considered any longer?
As it currently stands from a developer participation standpoint it is
not viable. I outlined the issues in a previous post.
You also have to take into
> -Original Message-
> From: Clint Priest [mailto:cpri...@zerocue.com]
> Sent: Tuesday, January 29, 2013 3:30 PM
> To: Anthony Ferrara
> Cc: Tyler Sommer; Zeev Suraski; internals@lists.php.net
> Subject: Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP
> distribution
>
> On 1/29
2013/1/29 Zeev Suraski :
> The RFC explains the pros and cons of doing that, I don't really have any
> additional reasons to add beyond what I already put there. I believe the
> pros outweigh the cons by a good considerable margin, but that's what the
> vote would be about. Perhaps the one thing
Hi Pierre
2013/1/29 Pierre Joye :
> It is not done yet. But given that the code is clean and easily
> maintainable, it could be much more efficient for us to focus on one
> extension and make it rock instead of trying to get each of them work
> well. As Rasmus stated, between the opcode/engine and
> -Original Message-
> From: kalle@gmail.com [mailto:kalle@gmail.com] On Behalf Of
Kalle
> Sommer Nielsen
> Sent: Tuesday, January 29, 2013 3:28 PM
> To: Zeev Suraski
> Cc: internals@lists.php.net
> Subject: Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP
> distribution
On Tue, Jan 29, 2013 at 2:33 PM, Rasmus Lerdorf wrote:
> Those ISPs are probably stuck in old fastcgi-land and haven't figured
> out FPM's ondemand pooling. If you idle out the ondemand children
> somewhat quickly you can support a lot of vhosts without using much
> memory since each one doesn't
Is there a procedure to take regarding removal of a push to the github repo
or do you simply close it. I would like to re-submit a push request against
the 5.5 branch while removing the old push request.
Also can I obtain some information on the current state of new function
extending regarding ac
This RFC is not about arrays.
The proposed change is to allow Iterator::key() to return things other than
int/strings. Consequently, it would mean foreach($iterable as $key=>$foo) {
$key can be an object here }.
SplObjectStorage "solves" it by returning an array() of
object-key/object-data as *va
On 01/29/2013 05:18 AM, Pierre Joye wrote:
> As far as I remember, we already do that for a couple of web servers.
> And in the long run, I will rather tell not to use FastCGI for
> dedicated hosting and the likes. That being said, I also met many ISPs
> which are not happy with the all-fastcgi, me
On Tue, Jan 29, 2013 at 2:31 PM, Ferenc Kovacs wrote:
>
>
>
> On Tue, Jan 29, 2013 at 2:17 PM, Clint Priest wrote:
>
>>
>> On 1/29/2013 5:21 AM, Ferenc Kovacs wrote:
>>
>> Hi,
>>
>> I think some of the README files currently present in the php-src repo
>> would be better kept in the wiki and som
On 1/29/2013 5:23 AM, Anthony Ferrara wrote:
Additionally, I don't like the precedent that this sets for future
releases. That it's ok to break the timebox for some feature. In this case
I think we can justify it, but future cases may use this to justify waiting
when it's not completely justified
On Tue, Jan 29, 2013 at 2:27 PM, Kalle Sommer Nielsen wrote:
> Hi Zeev
>
> 2013/1/29 Zeev Suraski :
>> In parallel we’re in the process of prepping the source code for
>> independent public consumption, which I hope we can be done with by the end
>> of next week, hopefully sooner.
>
> I'm sorry, b
Hi Zeev
2013/1/29 Zeev Suraski :
> In parallel we’re in the process of prepping the source code for
> independent public consumption, which I hope we can be done with by the end
> of next week, hopefully sooner.
I'm sorry, but I don't see why we out of a sudden should consider
adding a Zend produ
1 - 100 of 155 matches
Mail list logo
