Re: [PHP-DEV] (corrected) Fix for bug #53437

[Anatol Belski]

Hi,

I wanted just remind about that bug and the patches hanging there. If
there are no objections, I'd commit first to 5.5+ next week. 5.3/5.4 were
also debatable.

Regards

Anatol

On Tue, March 5, 2013 12:46, Anatol Belski wrote:
> Sorry, the correct one is bug #53437 ...
>
>
> On Tue, March 5, 2013 12:42, Anatol Belski wrote:
>
>> Hi,
>>
>>
>>
>> I've reworked the patch from
>> http://nebm.ist.utl.pt/~glopes/misc/date_period_interval_ser.diff
>> (mentioned by tony2001) for bug #63437, that seems to fix the issue.
>> That
>> patch was ported back to 5.3 and adapted to the current 5.4+. Both
>> variants are posted to the ticket.
>>
>> Also the test for bug #52113 delivers more plausible results and should
>>  be fixed when the patch is applied.
>>
>> Regards
>>
>>
>>
>> Anatol
>>
>>
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
>>
>>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
>


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Optimizer+ bugreps

[Hannes Magnusson]

On Fri, Mar 8, 2013 at 12:56 PM, Christopher Jones
 wrote:
>
>
> On 03/02/2013 09:42 AM, Christopher Jones wrote:
>>
>>
>>
>> On 3/2/13 3:19 AM, Terry Ellison wrote:
>>>
>>> On 02/03/13 09:34, Pierre Joye wrote:


 Having it in peck right now allows that. But as of now it is not a
 PHP.net project so it makes little sense to have it listed there.

 On Mar 2, 2013 10:33 AM, "Terry Ellison" >>> > wrote:

 At what point is O+ reporting going to be possible through
 https://bugs.php.net/ ?

 I realize that this is a bit of a catch-22, but surely it would be
 better to allow properly tracked open bug reporting sooner rather
 later?

>>>
>>> Thanks Pierre, I understand and that's why I mentioned catch-22. AFAIK,
>>> there's no open bug and issue reporting available prior to its formal
>>> adoption, event though we all realize that it's going to be pretty much
>>> inevitable -- for compelling reasons -- and by the time it is adopted the
>>> first release will be a fait accompli.
>>>
>>
>> Bugs can (and have been) reported via
>> https://github.com/zend-dev/ZendOptimizerPlus/issues
>> I'm sure email reports will also do fine in the interim.
>>
>> Chris
>>
>
> Felipe added ZO+ to the bugs.php.net "Package affected" drop-down today.
>

Hmmh.. That shouldn't be there as the current official issue tracker
for it is on github, and is linked from the pecl page..

Once it gets merged into php-src then that package should be created though.

-Hannes

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Optimizer+ bugreps

[Christopher Jones]

On 03/02/2013 09:42 AM, Christopher Jones wrote:



On 3/2/13 3:19 AM, Terry Ellison wrote:

On 02/03/13 09:34, Pierre Joye wrote:


Having it in peck right now allows that. But as of now it is not a PHP.net 
project so it makes little sense to have it listed there.

On Mar 2, 2013 10:33 AM, "Terry Ellison" mailto:te...@ellisons.org.uk>> wrote:

At what point is O+ reporting going to be possible through
https://bugs.php.net/ ?

I realize that this is a bit of a catch-22, but surely it would be
better to allow properly tracked open bug reporting sooner rather
later?



Thanks Pierre, I understand and that's why I mentioned catch-22. AFAIK, there's 
no open bug and issue reporting available prior to its formal
adoption, event though we all realize that it's going to be pretty much 
inevitable -- for compelling reasons -- and by the time it is adopted the
first release will be a fait accompli.



Bugs can (and have been) reported via 
https://github.com/zend-dev/ZendOptimizerPlus/issues
I'm sure email reports will also do fine in the interim.

Chris



Felipe added ZO+ to the bugs.php.net "Package affected" drop-down today.

Chris

--
christopher.jo...@oracle.com  http://twitter.com/ghrd
Newly updated, free PHP & Oracle book:
http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Proposed changes to PHP language

[Martin Jansen]

On 06.03.13 13:48, Max Romanovsky wrote:
>4. Add handling of DateTime objects to SoapServer and SoapClient. It
>will help in using this build-in datatype without typemap.

This is (at least partially) covered by the patch in
https://bugs.php.net/44383. Have you tried that one to see if its good?

- Martin

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Optimizer+ bugreps

[Jan Ehrhardt]

Christopher Jones in php.internals (Sat, 02 Mar 2013 09:42:30 -0800):
>Bugs can (and have been) reported via 
>https://github.com/zend-dev/ZendOptimizerPlus/issues

Just to draw the attention on the list:
https://github.com/zend-dev/ZendOptimizerPlus/issues/57

O+ is not stable yet, it does not even pass some tests reliably:
https://github.com/zend-dev/ZendOptimizerPlus/issues/59

The latter one is by a co-worker of Pierre, #57 by me. I am getting the
impression serious testing by users has yet to begin.

Jan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution

[jbo...@openmv.com]

> I'm right now oblivious to what is being voted or not in this case, 
> but ignoring a defined 2/3 rule is clearly wrong. Either remove rules or 
> follow them otherwise they become useless noise.

As far as I understand the RFC is a process to accept or reject features. 

The question that falls in the cracks is if a new feature can delay the release 
process. 
https://wiki.php.net/rfc/releaseprocess

In this case, I think it should. Every law/rule has exceptions, PHP probably 
needs a dictator or appointed judge(s).



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] disable zend_always_inline in debug mode

[Julien Pauli]

I ran some benchs, on my current machine (wasnt isolated to run tests). I
ran micro_bench.php on master branch today :

debug on, inline enabled :
Total 30.688

debug on, inline disabled :
Total 35.377

debug off, inline enabled :
Total 10.130

debug off, inline disabled :
Total 10.678

Julien.Pauli

On Fri, Mar 8, 2013 at 4:32 PM, Julien Pauli  wrote:

> On Fri, Mar 8, 2013 at 4:27 PM, Laruence  wrote:
>
>> Hey:
>>
>>I propose to disable zend_alwasy_inline while build PHP in debug mode.
>>
>>that could be easier for debuging some bugs..
>>
>>what do you think?
>>
>>
>> thanks
>>
>>
>>simple patch:
>>
>> diff --git a/Zend/zend.h b/Zend/zend.h
>> index 40515fb..03bd4e7 100644
>> --- a/Zend/zend.h
>> +++ b/Zend/zend.h
>> @@ -365,7 +365,7 @@ struct _zval_struct {
>>  #define Z_UNSET_ISREF(z)   Z_UNSET_ISREF_P(&(z))
>>  #define Z_SET_ISREF_TO(z, isref)   Z_SET_ISREF_TO_P(&(z), isref)
>>
>> -#if defined(__GNUC__)
>> +#if defined(__GNUC__) && !ZEND_DEBUG
>>  #if __GNUC__ >= 3
>>  #define zend_always_inline inline __attribute__((always_inline))
>>  #define zend_never_inline __attribute__((noinline))
>> @@ -374,7 +374,7 @@ struct _zval_struct {
>>  #define zend_never_inline
>>  #endif
>>
>> -#elif defined(_MSC_VER)
>> +#elif defined(_MSC_VER) && !ZEND_DEBUG
>>  #define zend_always_inline __forceinline
>>  #define zend_never_inline
>>  #else
>>
>>
>>
>
> I'm +1 with that.
>
> Julien.Pauli
>

Re: [PHP-DEV] disable zend_always_inline in debug mode

[Julien Pauli]

On Fri, Mar 8, 2013 at 4:27 PM, Laruence  wrote:

> Hey:
>
>I propose to disable zend_alwasy_inline while build PHP in debug mode.
>
>that could be easier for debuging some bugs..
>
>what do you think?
>
>
> thanks
>
>
>simple patch:
>
> diff --git a/Zend/zend.h b/Zend/zend.h
> index 40515fb..03bd4e7 100644
> --- a/Zend/zend.h
> +++ b/Zend/zend.h
> @@ -365,7 +365,7 @@ struct _zval_struct {
>  #define Z_UNSET_ISREF(z)   Z_UNSET_ISREF_P(&(z))
>  #define Z_SET_ISREF_TO(z, isref)   Z_SET_ISREF_TO_P(&(z), isref)
>
> -#if defined(__GNUC__)
> +#if defined(__GNUC__) && !ZEND_DEBUG
>  #if __GNUC__ >= 3
>  #define zend_always_inline inline __attribute__((always_inline))
>  #define zend_never_inline __attribute__((noinline))
> @@ -374,7 +374,7 @@ struct _zval_struct {
>  #define zend_never_inline
>  #endif
>
> -#elif defined(_MSC_VER)
> +#elif defined(_MSC_VER) && !ZEND_DEBUG
>  #define zend_always_inline __forceinline
>  #define zend_never_inline
>  #else
>
>
>

I'm +1 with that.

Julien.Pauli

[PHP-DEV] disable zend_always_inline in debug mode

[Laruence]

Hey:

   I propose to disable zend_alwasy_inline while build PHP in debug mode.

   that could be easier for debuging some bugs..

   what do you think?


thanks


   simple patch:

diff --git a/Zend/zend.h b/Zend/zend.h
index 40515fb..03bd4e7 100644
--- a/Zend/zend.h
+++ b/Zend/zend.h
@@ -365,7 +365,7 @@ struct _zval_struct {
 #define Z_UNSET_ISREF(z)   Z_UNSET_ISREF_P(&(z))
 #define Z_SET_ISREF_TO(z, isref)   Z_SET_ISREF_TO_P(&(z), isref)

-#if defined(__GNUC__)
+#if defined(__GNUC__) && !ZEND_DEBUG
 #if __GNUC__ >= 3
 #define zend_always_inline inline __attribute__((always_inline))
 #define zend_never_inline __attribute__((noinline))
@@ -374,7 +374,7 @@ struct _zval_struct {
 #define zend_never_inline
 #endif

-#elif defined(_MSC_VER)
+#elif defined(_MSC_VER) && !ZEND_DEBUG
 #define zend_always_inline __forceinline
 #define zend_never_inline
 #else



-- 
Laruence  Xinchen Hui
http://www.laruence.com/

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution

[Zeev Suraski]

> -Original Message-
> From: Rafael Dohms [mailto:lis...@rafaeldohms.com.br]
> Sent: Friday, March 08, 2013 2:52 PM
> To: Andi Gutmans
> Cc: Anthony Ferrara; Philip Olson; David Soria Parra; PHP internals
> Subject: Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP
> distribution
>
> On Fri, Mar 8, 2013 at 6:55 AM, Andi Gutmans  wrote:
>
> >
> > The 62.8% comparison to 60.7% is the most out of touch thing I've read
> > on this mailing list in a long time. If you're talking about pure
> > feature yay/nay then 94% have given a yay to this "feature". The split
> > is the timing.
> >
> >
> Sorry, but math is not liable to what is being measured by a percentage.
So to
> this point if there is something being done without 2/3 approval, then
its wrong.

Rafael,

You seem to be a bit misinformed here.  RFCs actually do NOT require 2/3
majority by default, it's left for special cases only.  The default is
50%+1.  See for yourself - https://wiki.php.net/rfc/voting

There was a bit of discussion on whether or not including Optimizer+ in
PHP is an RFC that falls in the special 2/3 requirement or not.  We'll
talk about that in a sec, but it's not really important at all as for this
particular question - 94%, 66 out of 70 voters, voted in favor.

There's absolutely no question that changing PHP's release cycle does
*not* require a 2/3 vote.  Let's look for a second what the voting RFC has
to say about it:

--
=== Required Majority ===

Given that changes to languages (as opposed to changes to apps or even
frameworks) are for the most part irreversible - the purpose of the vote
is to ensure that there's strong support for the proposed feature. It
needs to be clear that there are a lot more people actively supporting the
proposal, vs. people actively opposing it. We also need to ensure, as much
as possible, that the decision isn't based on some arbitrary circumstances
(such as a temporary marginal majority for a certain school of thought).
For these reasons, a feature affecting the language itself (new syntax for
example) will be considered as 'accepted' if it wins a 2/3 of the votes.
Other RFCs require 50% + 1 votes to get 'accepted'.
--

I know the text pretty well, I wrote it, and when I wrote it - I meant
what I said.  It's there to protect against *changes to the language*
which are irreversible.  The one thing I regret is that the phrasing
around what constitutes 'a feature affecting the language itself' was left
a bit vague, but one could definitely argue that language syntax and
language behavior are what we're talking about here.  Implementation
details, release timelines, included or excluded extensions - are most
certainly not.  There's nothing irreversible about them.

Zeev

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution

[Rafael Dohms]

On Fri, Mar 8, 2013 at 6:55 AM, Andi Gutmans  wrote:

>
> The 62.8% comparison to 60.7% is the most out of touch thing I've read on
> this mailing list in a long time. If you're talking about pure feature
> yay/nay then 94% have given a yay to this "feature". The split is the
> timing.
>
>
Sorry, but math is not liable to what is being measured by a percentage. So
to this point if there is something being done without 2/3 approval, then
its wrong.
Does not matter what it is, who is proposing and who likes it or not.


> And as far as timing is concerned I do not see how this whole thing falls
> into the 2/3 vote for "new language syntax/prevent feature creep rule".
>



> Many times in the past have we aligned new PHP versions with runtime
> improvements esp. as they are often exciting and beneficial to most of our
> audience. I don't see why we wouldn't do that given that the cost is
> pretty minimal and the benefit to our audience is high.
>
>
I'm sorry, but Anthony's example is spot on for this. Property accessors
matter a lot to me and will benefit all frameworks and people who use them
there was no special treatment there and there should be no special
treatment here.

I'm right now oblivious to what is being voted or not in this case, but
ignoring
a defined 2/3 rule is clearly wrong. Either remove rules or follow them
otherwise they
become useless noise.

-- 
Rafael Dohms
PHP Evangelist and Community Leader
http://doh.ms
http://wwwamsterdamphp.nl

RE: [PHP-DEV] PHP User Survey

[Christian Stoller]

> > > 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/cake) or Software (Wordpress, Gallery,
> > > etc) requires it
> > 
> > You should add:
> > When my distro/hosting company upgrades.
>
> Also 'When my Framework supports it', as opposed to requires it.
> --
> Niel Archer

And: "When my favourite stable Linux Distribution (Debian, Ubuntu, etc.) 
supports it."


Christian Stoller

Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution

[Pierre Joye]

On Thu, Mar 7, 2013 at 10:00 PM, David Soria Parra  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.

I disagree that it is the only point requiring 2/3, but yes, enabling
it by default must have 2/3.

Cheers,
-- 
Pierre

@pierrejoye

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution

[Pierre Joye]

On Fri, Mar 8, 2013 at 6:55 AM, Andi Gutmans  wrote:

> The 62.8% comparison to 60.7% is the most out of touch thing I've read on
> this mailing list in a long time. If you're talking about pure feature
> yay/nay then 94% have given a yay to this "feature". The split is the
> timing.

Right, the split is timing, how it is and was done, etc. But now it is
just pushing hard to get in 5.5 misusing both the RFC and the voting
process. And that is what is really bad in this whole thing. As you
hopefully know that I am a huge fan of getting o+ in the core, and
pushed most of our resources to make that possible asap, but not under
all conditions (IIIRC: remember why some well known engine devs left
us some years ago?).

Cheers,
-- 
Pierre

@pierrejoye

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php