hi Ryan,
On Tue, Jan 29, 2013 at 8:55 AM, Ryan McCue li...@rotorised.com wrote:
Larry Garfield wrote:
It's great to hear you say that, given that the messaging coming out of
WP at the time was rather hostile. :-)
As I noted, the dynamics have changed significantly. I'd say that core
hi Zeev!
On Tue, Jan 29, 2013 at 9:03 AM, Zeev Suraski z...@zend.com wrote:
All,
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
On Monday 28 January 2013 21:46:27 Stas Malyshev wrote:
I understand that there's a tendency to use OO as
a neat way to namespace global functions and autoload them, but that's
not how it is supposed to work.
I've seen that sentiment against using static methods several times now,
and it
Zeev Suraski wrote:
Following the discussion at the end of last week, I prepared a draft RFC
for the inclusion of Optimizer+ in PHP.
Hey Zeev,
I see in the Benchmarks you tested with WordPress 2.1.1, however this
release is roughly 5 years old. Is it possible to get an updated test
with 3.5.1
One important part missing is the actual compatibility/support of thread
safe
PHP. I know that Zend mostly care about NTS since quite some time and
that
worries me a lot to bundle something that is not working well in thread
safe
mode. I would consider that as a stopping point. I mean, not to
On Tue, Jan 29, 2013 at 4:03 PM, Zeev Suraski z...@zend.com wrote:
All,
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
On Tue, Jan 29, 2013 at 4:21 PM, Zeev Suraski z...@zend.com wrote:
One important part missing is the actual compatibility/support of thread
safe
PHP. I know that Zend mostly care about NTS since quite some time and
that
worries me a lot to bundle something that is not working well in thread
-Original Message-
From: Ryan McCue [mailto:li...@rotorised.com]
Sent: Tuesday, January 29, 2013 10:13 AM
To: Zeev Suraski
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP
distribution
Zeev Suraski wrote:
Following the discussion
On 29/01/13 09:30, Zeev Suraski wrote:
[snip]
(My guess is that it will show WP being slower and with a more dramatic
improvement.)
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
On Tue, Jan 29, 2013 at 4:33 PM, Ivan Enderlin @ Hoa
ivan.ender...@hoa-project.net wrote:
On 29/01/13 09:30, Zeev Suraski wrote:
[snip]
(My guess is that it will show WP being slower and with a more dramatic
improvement.)
By the way, I just realized the % gain wasn't all that
On 2013/1/29 16:38, Laruence wrote:
On Tue, Jan 29, 2013 at 4:33 PM, Ivan Enderlin @ Hoa
ivan.ender...@hoa-project.net wrote:
On 29/01/13 09:30, Zeev Suraski wrote:
[snip]
(My guess is that it will show WP being slower and with a more dramatic
improvement.)
By the way, I just realized the %
I didn’t want to hijack the Optimizer+ thread so I’m creating a new one,
based on the apparent level of interest in ZTS. This isn’t an RFC to
remove ZTS by any stretch, but I **am** a bit confused about why people are
still using ZTS.
A bit of background. I started the ZTS project (based on
On 2013/1/29 17:03, Zeev Suraski wrote:
I didn’t want to hijack the Optimizer+ thread so I’m creating a new one,
based on the apparent level of interest in ZTS. This isn’t an RFC to
remove ZTS by any stretch, but I **am** a bit confused about why people are
still using ZTS.
A bit of
On Tue, Jan 29, 2013 at 1:03 PM, Zeev Suraski z...@zend.com 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
On Tue, Jan 29, 2013 at 5:03 PM, Zeev Suraski z...@zend.com wrote:
I didn’t want to hijack the Optimizer+ thread so I’m creating a new one,
based on the apparent level of interest in ZTS. This isn’t an RFC to
remove ZTS by any stretch, but I **am** a bit confused about why people are
still
On Tue, Jan 29, 2013 at 5:28 PM, Laruence larue...@php.net wrote:
On Tue, Jan 29, 2013 at 5:03 PM, Zeev Suraski z...@zend.com wrote:
I didn’t want to hijack the Optimizer+ thread so I’m creating a new one,
based on the apparent level of interest in ZTS. This isn’t an RFC to
remove ZTS by any
Hey:
It's not we choose ZTS, it is there are many users run with them (IIS,
Apache+workers, and pthreads extension require it)
For pthreads I can understand it, but why would users be using it on
IIS/Apache instead of using FastCGI? FastCGI is both faster and more
robust. Is it a matter of
On Tue, Jan 29, 2013 at 5:35 PM, Zeev Suraski z...@zend.com wrote:
Hey:
It's not we choose ZTS, it is there are many users run with them (IIS,
Apache+workers, and pthreads extension require it)
For pthreads I can understand it, but why would users be using it on
IIS/Apache instead of using
hi Zeev,
On Tue, Jan 29, 2013 at 10:03 AM, Zeev Suraski z...@zend.com 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
Pierre Joye wrote:
It would be already very good if wp (strongly) suggests to use #php
5.3/4 instead of 5.2 on http://wordpress.org/about/requirements/ and
with a notice in the installer code.
That's a great idea, and it's something I'll definitely try and bring up
with the other developers.
On 01/29/2013 10: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.
Why should we break the PHP release process by 2 months+ to include O+ ?
There are alternatives (APC to name one) and O+ might
On Tue, Jan 29, 2013 at 10:56 AM, Pierre Joye pierre@gmail.com wrote:
The other main reason from my side to keep ZTS is Windows. Windows
cannot perform well using process based SAPI. It won't match linux as
long as it runs within a webserver using a process based
implementation (but CLI
Thank you for this great initiative!
As a user, I could definitely wait for 2-3 more months and get
a good implementation/integration of this rather that have to
wait for at least one year.
I think it would also be nice if this could come as default
enabled since this way people would be able to
This is really exciting!
As a user, I say allow a delay to get this into 5.5. I was kind of disappointed
that some cache wasn't bundled with 5.4. It's been too long that this very
important piece has been separate from the core.
Cheers
--
PHP Internals - PHP Runtime Development Mailing List
On Tue, 2013-01-29 at 11:03 +0200, Zeev Suraski wrote:
I didn’t want to hijack the Optimizer+ thread so I’m creating a new one,
based on the apparent level of interest in ZTS. This isn’t an RFC to
remove ZTS by any stretch, but I **am** a bit confused about why people are
still using ZTS.
I
hi Jan,
On Tue, Jan 29, 2013 at 11:55 AM, Jan Ehrhardt php...@ehrhardt.nl 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 we do not introduce
The other main reason from my side to keep ZTS is Windows. Windows
cannot
perform well using process based SAPI.
Windows actually works quite well with FastCGI. So well Microsoft even
created their own version for IIS. It's outperforming the ISAPI module by
a wide margin.
Other than
On Tue, 2013-01-29 at 12:05 +0100, Johannes Schlüter wrote:
exploit some of the bugs (?php new stdclass; ?, or any other internal
class, was all that was needed for one of the bugs) there were way too
few reports.
Ah, that specific bug was 5.4-only, back then 5.4 was quite new. But
there were
On Jan 29, 2013 12:10 PM, Zeev Suraski z...@zend.com wrote:
The other main reason from my side to keep ZTS is Windows. Windows
cannot
perform well using process based SAPI.
Windows actually works quite well with FastCGI. So well Microsoft even
created their own version for IIS. It's
Pierre Joye in php.internals (Tue, 29 Jan 2013 12:08:16 +0100):
What do you need to get D7 tested under 5.5? I mean once you have a CI
in place, it is not hard to setup one instance to test 5.5.
I do not need anything, except for 48 hours in a day and some disk space
on my Win7 laptop ;-)
Hi,
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.
- README.MAILINGLIST_RULES - this should be in the wiki or on
php.netsomewhere, this doesn't belong to
(*) Apache actually does have a good FastCGI implementation available in
Zend Server for Windows (including the free CE version). Using it is
faster and more reliable than using mod_php on Windows.
Absolute right. Zend Server works great on Windows with FastCGI.
Using it since 3 years and
Zeev,
First off, very nice job on the RFC. I definitely like what's happening
here.
As far as delaying 5.5, I have mixed feelings. I think we should definitely
consider the delay, but only in a time-boxed format. So if we say 1
month, then if it's not ready to be committed in that month, it
Am 29.01.2013 12:21, schrieb Ferenc Kovacs:
what do you think about this?
+1
--
Sebastian BergmannCo-Founder and Principal Consultant
http://sebastian-bergmann.de/ http://thePHP.cc/
--
PHP Internals - PHP Runtime Development Mailing List
To
On Tue, Jan 29, 2013 at 11:26 AM, Florin Razvan Patan florinpa...@gmail.com
wrote:
Thank you for this great initiative!
As a user, I could definitely wait for 2-3 more months and get
a good implementation/integration of this rather that have to
wait for at least one year.
I think it would
On Tue, 2013-01-29 at 12:15 +0100, Pierre Joye wrote:
Laziness and design mistake. Everything on windows (AD,IIS, asp.net,
etc)
uses thread.
Well, most other things don't create shared-nothing environments like
PHP does. ASP, not only due to the Application object, for instance
isn't
Zeev Suraski in php.internals (Tue, 29 Jan 2013 11:03:51 +0200):
Which brings me to the subject of this mail why are you using ZTS PHP
instead of single threaded PHP?
Quote from a Drupal status report:
|Upload progress: Not enabled
|Your server is not capable of displaying file upload
hi,
On Tue, Jan 29, 2013 at 12:45 PM, Johannes Schlüter
johan...@schlueters.de wrote:
On Tue, 2013-01-29 at 12:15 +0100, Pierre Joye wrote:
Laziness and design mistake. Everything on windows (AD,IIS, asp.net,
etc)
uses thread.
Well, most other things don't create shared-nothing
On Tue, Jan 29, 2013 at 12:36 PM, Zeev Suraski z...@zend.com wrote:
Laziness and design mistake. Everything on windows (AD,IIS, asp.net, etc)
uses thread.
And no, nuts is not faster. I am not talking about PHP zts, but in
general.
Of course everything that is Windows native uses threads,
On Tue, 2013-01-29 at 12:49 +0100, Pierre Joye wrote:
That is true. Many modern compilers and environments provide better
support for thread local storages
Exactly, or more exactly CRTs (libc, crt and the likes)
That's what I called environment - some of these things depend on
-Original Message-
From: Pierre Joye [mailto:pierre@gmail.com]
Sent: Tuesday, January 29, 2013 1:49 PM
To: Johannes Schlüter
Cc: Zeev Suraski; PHP internals
Subject: Re: [PHP-DEV] ZTS - why are you using it?
On Tue, Jan 29, 2013 at 12:45 PM, Johannes Schlüter
On Tue, Jan 29, 2013 at 1:15 PM, Pierre Joye pierre@gmail.com wrote:
On Jan 29, 2013 12:10 PM, Zeev Suraski z...@zend.com wrote:
The other main reason from my side to keep ZTS is Windows. Windows
cannot
perform well using process based SAPI.
Windows actually works quite well
On Tue, Jan 29, 2013 at 1:01 PM, Johannes Schlüter
johan...@schlueters.de 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/59353
Such bugs identified a year after the
On Tue, Jan 29, 2013 at 1:06 PM, Zeev Suraski z...@zend.com wrote:
It is inter process sharing and is very expensive, nothing to compare
with shared
memory within a single process, accross many threads.
What are you basing that assertion on? Shared memory should have
identical performance
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 in a different
way? Scheduling a data lookup on one thread while building
-Original Message-
From: Pierre Joye [mailto:pierre@gmail.com]
Sent: Tuesday, January 29, 2013 2: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:06 PM, Zeev Suraski z...@zend.com wrote:
On Tue, Jan 29, 2013 at 1:29 PM, Lester Caine les...@lsces.co.uk 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
I just saw this RFC:
https://wiki.php.net/rfc/foreach-non-scalar-keys
By non-scalar, presumably we're talking about objects? In the numbers
that e.g. resources typically get used, having a collection indexed by
resources would seem like an extremely exotic need.
Moreover, we already have this:
On 29 January 2013 11:23, Anthony Ferrara ircmax...@gmail.com wrote:
Zeev,
First off, very nice job on the RFC. I definitely like what's happening
here.
As far as delaying 5.5, I have mixed feelings. I think we should definitely
consider the delay, but only in a time-boxed format. So if we
As a developer I really enjoyed that discussion, it was very
informative for me. I'm always stuck with question which version of
PHP to use.
2013/1/29 Zeev Suraski z...@zend.com:
-Original Message-
From: Pierre Joye [mailto:pierre@gmail.com]
Sent: Tuesday, January 29, 2013 2:19 PM
Rasmus,
Relax. It hasn't even been proposed yet. Give the author some time to
finish the RFC before proposing it here, and then we can discuss it...
Anthony
On Tue, Jan 29, 2013 at 8:03 AM, Rasmus Schultz ras...@mindplay.dk wrote:
I just saw this RFC:
On Tue, Jan 29, 2013 at 1:52 PM, Zeev Suraski z...@zend.com wrote:
-Original Message-
From: Pierre Joye [mailto:pierre@gmail.com]
Sent: Tuesday, January 29, 2013 2:19 PM
To: Zeev Suraski
Cc: Johannes Schlüter; PHP internals
Subject: Re: [PHP-DEV] ZTS - why are you using it?
On
Vote in RFC
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi Zeev
2013/1/29 Zeev Suraski z...@zend.com:
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
On Tue, Jan 29, 2013 at 2:27 PM, Kalle Sommer Nielsen ka...@php.net wrote:
Hi Zeev
2013/1/29 Zeev Suraski z...@zend.com:
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
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
On Tue, Jan 29, 2013 at 2:31 PM, Ferenc Kovacs tyr...@gmail.com wrote:
On Tue, Jan 29, 2013 at 2:17 PM, Clint Priest cpri...@zerocue.com 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
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,
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
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
On Tue, Jan 29, 2013 at 2:33 PM, Rasmus Lerdorf ras...@lerdorf.com 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
-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
Hi
Hi Pierre
2013/1/29 Pierre Joye pierre@gmail.com:
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
2013/1/29 Zeev Suraski z...@zend.com:
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
-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
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: 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 Fri, Sep 14, 2012 at 12:47 PM, Pierre Joye pierre@gmail.com 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
On Tue, Jan 29, 2013 at 2:52 PM, Rasmus Lerdorf ras...@lerdorf.com 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
-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 z...@zend.com 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, 2013 at 2:33 PM, Rasmus Lerdorf ras...@lerdorf.com
wrote:
Those
On Tue, Jan 29, 2013 at 3:16 PM, Zeev Suraski z...@zend.com 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, 2013
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 issue.
2013/1/29 Zeev Suraski z...@zend.com:
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
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 the
Hi Zeev,
Am 29.01.2013 um 15:21 schrieb Rasmus Lerdorf ras...@lerdorf.com:
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
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 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, Jan 29, 2013 at 3:21 PM, Rasmus Lerdorf ras...@lerdorf.com 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
Kalle Sommer Nielsen wrote:
2013/1/29 Zeev Suraskiz...@zend.com:
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
2013/1/29 Lester Caine les...@lsces.co.uk:
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
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
this case I
Am 29.1.2013 um 15:58 schrieb Derick Rethans der...@php.net:
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
Kalle Sommer Nielsen wrote:
2013/1/29 Lester Caine les...@lsces.co.uk:
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
-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 see the
Ferenc Kovacs wrote:
On Tue, Jan 29, 2013 at 1:29 PM, Lester Caine les...@lsces.co.uk 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
On 29/01/13 15:21, Pierre Joye wrote:
On Tue, Jan 29, 2013 at 3:16 PM, Zeev Suraski z...@zend.com 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
On Tue, Jan 29, 2013 at 4:32 PM, Lester Caine les...@lsces.co.uk wrote:
Ferenc Kovacs wrote:
On Tue, Jan 29, 2013 at 1:29 PM, Lester Caine les...@lsces.co.uk wrote:
Can someone please fill in a little information here. When we start
looking at multiple threads doing for example database
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 by
On Tue, Jan 29, 2013 at 4:43 PM, Ángel González keis...@gmail.com wrote:
On 29/01/13 15:21, Pierre Joye wrote:
On Tue, Jan 29, 2013 at 3:16 PM, Zeev Suraski z...@zend.com wrote:
On Windows with impersonation you're actually in a better situation than
you are in Linux. You could hold a small
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+?
I
On 29 בינו 2013, at 17:45, Ángel González keis...@gmail.com wrote:
On 29/01/13 15:21, Pierre Joye wrote:
On Tue, Jan 29, 2013 at 3:16 PM, Zeev Suraski z...@zend.com wrote:
On Windows with impersonation you're actually in a better situation than
you are in Linux. You could hold a small pool
On Tue, 29 Jan 2013, Bob Weinand wrote:
Am 29.1.2013 um 15:58 schrieb Derick Rethans der...@php.net:
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
On 29 בינו 2013, at 17:54, Derick Rethans der...@php.net 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
On 1/29/13 5:08 AM, Pierre Joye wrote:
hi Jan,
On Tue, Jan 29, 2013 at 11:55 AM, Jan Ehrhardt php...@ehrhardt.nl 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
On Tue, Jan 29, 2013 at 5:54 PM, Zeev Suraski z...@zend.com wrote:
On 29 בינו 2013, at 17:54, Derick Rethans der...@php.net 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
-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
php...@ehrhardt.nl wrote:
Hi Pierre,
Pierre Joye in php.internals (Tue, 29 Jan 2013 05:55:27
+0100):
hi Larry,
On Tue, Jan 29, 2013 at 5:55 PM, Larry Garfield la...@garfieldtech.com wrote:
On 1/29/13 5:08 AM, Pierre Joye wrote:
hi Jan,
On Tue, Jan 29, 2013 at 11:55 AM, Jan Ehrhardt php...@ehrhardt.nl wrote:
Hi Pierre,
Pierre Joye in php.internals (Tue, 29 Jan 2013 05:55:27 +0100):
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
On Tue, Jan 29, 2013 at 6:24 PM, Attila Bukor attila.bu...@gmail.com 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
1 - 100 of 152 matches
Mail list logo
