>-Original Message-
>From: Anthony Ferrara [mailto:ircmax...@gmail.com]
>Sent: Thursday, March 07, 2013 1:58 PM
>To: Philip Olson
>Cc: David Soria Parra; internals@lists.php.net
>Subject: Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP
>distribution
>
>Philip,
>
>Shouldn't we
David Soria Parra in php.internals (Thu, 07 Mar 2013 16:21:35 -0500):
>Please test the release carefully and report any bugs. We will begin
>with the beta stage in two weeks.
Please add alpha6 to bugs.php.net. There is a BC break in compiling
pecl_http, that I had to report under alpha5. It is som
On Mar 7, 2013, at 1:58 PM, Anthony Ferrara wrote:
> Philip,
>
> Shouldn't we be focusing on how this makes PHP better? And not nitpick
>> about a percentage point or two?
>>
>
> Well, this passed with 62.8%. Property accessors failed with 60.7%. The
> target for acceptance is 66.6%. So 3.8%
On Thu, Mar 7, 2013 at 9:58 PM, Anthony Ferrara wrote:
> Well, this passed with 62.8%. Property accessors failed with 60.7%. The
> target for acceptance is 66.6%. So 3.8% is enough to throw away, but 5.9%
> isn't?
>
94% voted to integrate ZO+.
> Either we stick to the rules, or we throw them o
Philip,
Shouldn't we be focusing on how this makes PHP better? And not nitpick
> about a percentage point or two?
>
Well, this passed with 62.8%. Property accessors failed with 60.7%. The
target for acceptance is 66.6%. So 3.8% is enough to throw away, but 5.9%
isn't?
I think the point of this d
On 03/07/2013 10:33 PM, Philip Olson wrote:
>> I think the only thing requiring a 2/3 vote would be the decision on
>> wheather to enable it by default or not. As long as it's in ext/
>> and not enabled a 50% should be sufficient.
>
> Shouldn't we be focusing on how this makes PHP better? And not
On 7 במרץ 2013, at 23:00, David Soria Parra wrote:
> On 2013-03-07, Rasmus Lerdorf wrote:
>> On 03/07/2013 09:01 AM, Anthony Ferrara wrote:
>>
>>> So my proposal is to slow down for a minute and not call this RFC
>>> accepted or not until we can come to some consensus as to if it
>>> classifies
On Mar 7, 2013, at 1:00 PM, David Soria Parra wrote:
> On 2013-03-07, Rasmus Lerdorf wrote:
>> On 03/07/2013 09:01 AM, Anthony Ferrara wrote:
>>
>>> So my proposal is to slow down for a minute and not call this RFC
>>> accepted or not until we can come to some consensus as to if it
>>> classif
Hi Internals,
PHP 5.5.0 Alpha 6 has been released for testing. As you know we were
supposed to release a first beta but due to the current voting on ZO+
we went for yet another alpha. This time, it's the last one.
The packages can be found at:
http://downloads.php.net/dsp
and windows packages
On 2013-03-07, Rasmus Lerdorf wrote:
> On 03/07/2013 09:01 AM, Anthony Ferrara wrote:
>
>> So my proposal is to slow down for a minute and not call this RFC
>> accepted or not until we can come to some consensus as to if it
>> classifies as a language change or not... Better to clarify for the
>>
Yay!
Am 07.03.2013 um 17:48 schrieb Zeev Suraski :
> The voting period ended, and the option selected with 44 out of 70 votes
> was integrating Optimizer+ into PHP 5.5.0, even at the cost of a minor
> delay. An overwhelming majority (66 out of the 70 votes) was in favor of
> going with the integ
cc'ing the internals
__
Am 07.03.2013 um 20:57 schrieb "Stas Malyshev" :
> Hi!
>
>> The main practical value is in the __unset magic method. You can now
>> communicate through the "proper" way of a language construct with an
>> __unset method. (success or failure)
>
> I'm not sure how useful i
On Thu, Mar 7, 2013 at 7:10 AM, Bob Weinand wrote:
> Am 7.3.2013 um 00:32 schrieb Stas Malyshev :
>
> > Hi!
> >
> >> RFC updated.
> >>
> >> Any other comments about this RFC?
> >
> > Could you provide a use case for this - which practical value this has?
> >
> > It also still contains factually i
Hi!
> The main practical value is in the __unset magic method. You can now
> communicate through the "proper" way of a language construct with an
> __unset method. (success or failure)
I'm not sure how useful is that based on your example - unset could
throw the exception as well... And the whole
On Thu, Mar 7, 2013 at 6:18 PM, Zeev Suraski wrote:
> 94% of the votes voted in favor of integrating O+ into PHP, which is well
> above 2/3, it’s almost 3/3.
44 for 5.5 + delay
22 for no delay (aka 5.6)
4 for not at all in the current sate
Sorry but don't use numbers badly to cover your goal
Anthony,
94% of the votes voted in favor of integrating O+ into PHP, which is well
above 2/3, it’s almost 3/3. The only open question was about timeline.
And no matter how we twist it, whether it happens now or in a year has
ABSOLUTELY nothing to do with whether or not it’s a language change.
On 03/07/2013 09:01 AM, Anthony Ferrara wrote:
> So my proposal is to slow down for a minute and not call this RFC
> accepted or not until we can come to some consensus as to if it
> classifies as a language change or not... Better to clarify for the
> health of the project than to plow through an
Zeev,
As a rule of thumb, if the language syntax doesn’t change, it doesn’t need
> a 2/3 vote.
>
> How do I know? I asked for this special majority in the first place. It
> was designed to protect the language from becoming the kitchen sink of
> programming languages, not from making architectur
On Thu, Mar 7, 2013 at 5:46 PM, Pierre Joye wrote:
> On Thu, Mar 7, 2013 at 5:31 PM, Rasmus Lerdorf wrote:
> > On 03/07/2013 08:26 AM, Pierre Joye wrote:
> >
> >> That being said, if o+ would have 2/3 of the votes, I think it is
> >> possible to get it stable until 5.5 final, not easy but possib
On Thu, Mar 7, 2013 at 5:26 PM, Pierre Joye wrote:
> what takes longer is to stabilize it, there is no integration work
> being done right now, as far as I can tell. Latest issues spotted in
> our tests are visible in the report #63472.
I mean #64372
--
Pierre
@pierrejoye
--
PHP Internals -
Anthony,
As a rule of thumb, if the language syntax doesn’t change, it doesn’t need
a 2/3 vote.
How do I know? I asked for this special majority in the first place. It
was designed to protect the language from becoming the kitchen sink of
programming languages, not from making architectural p
The voting period ended, and the option selected with 44 out of 70 votes
was integrating Optimizer+ into PHP 5.5.0, even at the cost of a minor
delay. An overwhelming majority (66 out of the 70 votes) was in favor of
going with the integration in general.
We’ll work on moving the repository as
On Thu, Mar 7, 2013 at 5:31 PM, Rasmus Lerdorf wrote:
> On 03/07/2013 08:26 AM, Pierre Joye wrote:
>
>> That being said, if o+ would have 2/3 of the votes, I think it is
>> possible to get it stable until 5.5 final, not easy but possible.
>
> We already covered that. An opcode cache doesn't affect
Rasmus,
We already covered that. An opcode cache doesn't affect the language
> itself. There is no new syntax and no BC issues. Much like a performance
> improvement patch that has no effect on the language syntax doesn't need
> 2/3. Whether it is "major" or not, doesn't matter per the established
On Thu, Mar 7, 2013 at 5:31 PM, Rasmus Lerdorf wrote:
> On 03/07/2013 08:26 AM, Pierre Joye wrote:
>
>> That being said, if o+ would have 2/3 of the votes, I think it is
>> possible to get it stable until 5.5 final, not easy but possible.
>
> We already covered that. An opcode cache doesn't affect
On 03/07/2013 08:26 AM, Pierre Joye wrote:
> That being said, if o+ would have 2/3 of the votes, I think it is
> possible to get it stable until 5.5 final, not easy but possible.
We already covered that. An opcode cache doesn't affect the language
itself. There is no new syntax and no BC issues.
On Thu, Mar 7, 2013 at 5:06 PM, Zeev Suraski wrote:
> Nikita,
>
>
>
> The 1-2 month estimation, is taken from about 50cm behind the fingers typing
> this email, aka my gut J. It’s quite possible it’ll take much less, or no
> time at all; But it’s possible that once we include it, a lot more peop
hi,
On Thu, Mar 7, 2013 at 5:01 PM, Nikita Popov wrote:
> "The majority" yes. The accessors proposal also had "the majority" in favor,
> but that did not suffice. As of now this RFC does *not* have a 2/3 majority
> for the delay. And, as I already pointed out, I really think that this RFC
> shou
On Thu, Mar 7, 2013 at 5:06 PM, Zeev Suraski wrote:
> Nikita,
>
>
>
> The 1-2 month estimation, is taken from about 50cm behind the fingers
> typing this email, aka my gut J. It’s quite possible it’ll take much
> less, or no time at all; But it’s possible that once we include it, a lot
> more p
Nikita,
The 1-2 month estimation, is taken from about 50cm behind the fingers
typing this email, aka my gut J. It’s quite possible it’ll take much less,
or no time at all; But it’s possible that once we include it, a lot more
people test it, and we’ll get some feedback/requests/bugs that requi
On Sun, Mar 3, 2013 at 10:23 AM, Rasmus Lerdorf wrote:
> On 03/03/2013 12:43 AM, Pierre Joye wrote:
> > On Sun, Mar 3, 2013 at 8:41 AM, Rasmus Lerdorf
> wrote:
> >> The
> >> first step towards integration is getting it in.
> >
> > That does not guarantee that further steps can be done, from a ti
On 5 March 2013 15:13, Paul Reinheimer wrote:
> How many servers do you deploy code to
>
Does this need a dev/test/prod split? I think this question should
specifically address production servers only.
(I'm not sure how this answer steers PHP as a language, but it might be
> useful for trends o
>
> > When do you upgrade to a new release of php e.g. 5.3 -> 5.4
> > - As soon as released
> > - wait for the x.1 release
> > - Once our OpCode cache supports it
> > - When previous version hits EOL
> > - When a new feature warrants the upgrade
> > - When my Framework (Zend/Symfony/ca
Am 7.3.2013 um 00:32 schrieb Stas Malyshev :
> Hi!
>
>> RFC updated.
>>
>> Any other comments about this RFC?
>
> Could you provide a use case for this - which practical value this has?
>
> It also still contains factually incorrect claim that unset() is a
> function and that there's some "inc
On 7 March 2013 09:45, Sebastian Krebs wrote:
>
> So I guess this is the only useful behaviour. However, I have no idea, what
> this information should tell me. If I call unset() then I want to ensure,
> that the variable is not set anymore, but for what reason I should need to
> know, whether it
Hi!
> Shouldn't this fail a little bit more obvious (-> "loud")? And how is
> this even possible?
Well, for example - __unset is required to do X before unsetting
variable but X fails for one reason or another and the logic dictates
that you can not unset unless X is done (for a real life example
2013/3/7 Stas Malyshev
> Hi!
>
> > RFC updated.
> >
> > Any other comments about this RFC?
>
> Could you provide a use case for this - which practical value this has?
>
> It also still contains factually incorrect claim that unset() is a
> function and that there's some "inconsistency" in the fac
Hi!
> so I stumbled upon this bug report: https://bugs.php.net/bug.php?id=64357
>
> It's fairly easily fixable, but I don't know if it's even a bug... The
Well, the result in the bug is obviously wrong - it should have one
date, or another date, but not both! I'd say if you explicitly set the
38 matches
Mail list logo
