Re: [PHP-DEV] PHP 5.6 end of active support

[Alice Wonder]

On 12/14/2016 02:29 PM, Ferenc Kovacs wrote:

On Wed, Dec 14, 2016 at 2:05 PM, Niklas Keller  wrote:


2016-12-14 12:23 GMT+01:00 Christoph M. Becker :


Hi!

The end of active support for PHP 5.6 is documented to be on December,
31th[1].  Does that mean that there'll be no further release with
"normal" bug fixes (but only security fixes)?

[1] 



It has support until the end of the year, so I guess there will be one
more release with regular fixes in early January.

Regards, Niklas



yep, that's my plan, and the PHP-5.6 branch will be closed for regular
bugfixes after tagging 5.6.30RC1:
http://git.php.net/?p=karma.git;a=blob;f=hooks/pre-receive;h=fdff955c6b13c434aab40cb35cf002ab7c7eb146;hb=HEAD#l32
from that point on only RMs can push changes to the PHP-5.6 branch.
going into extended support also means that there won't be RCs as we don't
have regular bugfixes and we won't have a release each month, only when
there are security fixes ready to be released for 5.6



I want to say a huge thank you for doing this. When 5.6.0 was new I 
moved all sites I am responsible for to it, and I have started porting 
my other sites to 7.1 but haven't finished yet. This gives me a few 
months to make sure everything really does work as intended.


5.6.x IMHO was a fantastic branch throughout and I thank all the devs 
for it as I look forward to 7.1


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

Re: [PHP-DEV] PHP 5.6 end of active support

[Ferenc Kovacs]

On Wed, Dec 14, 2016 at 2:05 PM, Niklas Keller  wrote:

> 2016-12-14 12:23 GMT+01:00 Christoph M. Becker :
>
>> Hi!
>>
>> The end of active support for PHP 5.6 is documented to be on December,
>> 31th[1].  Does that mean that there'll be no further release with
>> "normal" bug fixes (but only security fixes)?
>>
>> [1] 
>>
>
> It has support until the end of the year, so I guess there will be one
> more release with regular fixes in early January.
>
> Regards, Niklas
>

yep, that's my plan, and the PHP-5.6 branch will be closed for regular
bugfixes after tagging 5.6.30RC1:
http://git.php.net/?p=karma.git;a=blob;f=hooks/pre-receive;h=fdff955c6b13c434aab40cb35cf002ab7c7eb146;hb=HEAD#l32
from that point on only RMs can push changes to the PHP-5.6 branch.
going into extended support also means that there won't be RCs as we don't
have regular bugfixes and we won't have a release each month, only when
there are security fixes ready to be released for 5.6

Re: [PHP-DEV] PHP 5.6 end of active support

[Dennis Clarke]

Perhaps the gcc compiler is an absolute
requirement and if that is true then the code isn't acceptable to any
other compiler regardless if it is C99 compliant or otherwise.


GCC is not a requirement. At the very least, PHP compiles on clang and
MSVC, and I believe it works with some other compilers also.



I have to test with a very strict POSIX system compliant to POSIX.1-2001
and Single UNIX Specification, Version 3 (SUSv3). There is also XNS4
sockets and XTI interfaces which really is XNS5 which is a superset
and LP64 clean derivative of XNS4. The XNS4 spec is 32-bit only and I
think nearly everything lately is targetted to 64-bit systems specs. Not
sure as I am sure there are a bucket of 32-bit embedded systems on the
market still with things like Motorola or Freescale system on a chip
embedded solutions for automobiles and mobile data access pads. Those
are almost always a custom 32-bit Linux kernel for touch screen apps and
other control solutions etc etc.

However within the strict confines of C99 there is the Oracle Developer
Studio which conforms to the ISO/IEC 9899:1999 and ISO/IEC 9899:1990. I
think that ISO/IEC 9899:2014 standards compliance is in progress. With
some feature test macros we can get access to extensions. From the very
long and pedantic man page :

 If the application is using interfaces and headers
 not  defined  by that standard, then in addition to defining
 the appropriate standard feature test macro,  it  must  also
 define  __EXTENSIONS__. Defining __EXTENSIONS__ provides the
 application with access to all interfaces and headers not in
 conflict  with  the specified standard. The application must
 define __EXTENSIONS__ either on the compile command line  or
 within the application source files.

So the POSIX.1-2001 standards compliance can be enforced with the simple
define -D_POSIX_C_SOURCE=200112L but going all the way up to SUSv3 will
require -D_XOPEN_SOURCE=600. This is getting a bit off topic but the
real idea here is that php 5.6.29 will compile perfectly in a 64-bit
strict environment with the allowance for extensions. There is no need
to resort to GCC which is not yet in full compliance. PHP 5.6.x then
runs its entire testsuite and the results are very positive. This can
not ( yet ) be done with PHP 7.x for any value x but I am certainly
going to try.

OKay .. so the long winded summary is that hoo ray PHP 5.6.x will be
around long enough for PHP 7.x to slowly become serious code clean and
it may compile within a very strict environment.

Dennis


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

Re: [PHP-DEV] PHP 5.6 end of active support

[Dennis Clarke]

On 12/14/2016 03:48 PM, Nikita Popov wrote:

On Wed, Dec 14, 2016 at 9:39 PM, Dennis Clarke 
wrote:


On 12/14/2016 03:31 PM, Marco Pivetta wrote:


See https://secure.php.net/supported-versions.php



I see.

I guess the question has to be "why is the 5.6.x codebase only to receive
security fixes for a very brief while into 2017" ?  Just
curious what the thinking is here.



PHP 5.6 receives security fixes for the entirety of 2017 and 2018, not "a
very brief while into 2017".



Sorry ... I was looking at the 5.5 line there. The 5.6.x line seems to
be very reasonable and safe.

Dennis


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

Re: [PHP-DEV] PHP 5.6 end of active support

[Andrea Faulds]

Hi,

Dennis Clarke wrote:

This is entirely too soon. At the present moment neither of the PHP 7.0
releases will compile clean on a strict POSIX environment. At all. The
version 5.6.x tree is perfectly stable and works out of the box without
an endless compile nightmare whereas 7.0.14 and 7.1.0 won't even
compile. I guess I need to file more bug reports and push through this
or the 5.6.x version will be dropped with no valid replacement that
works in a strict environment.  Perhaps the gcc compiler is an absolute
requirement and if that is true then the code isn't acceptable to any
other compiler regardless if it is C99 compliant or otherwise.


GCC is not a requirement. At the very least, PHP compiles on clang and 
MSVC, and I believe it works with some other compilers also.


--
Andrea Faulds
https://ajf.me/

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

Re: [PHP-DEV] PHP 5.6 end of active support

[Ryan Pallas]

On Wed, Dec 14, 2016 at 1:39 PM, Dennis Clarke 
wrote:

> On 12/14/2016 03:31 PM, Marco Pivetta wrote:
>
>> See https://secure.php.net/supported-versions.php
>>
>
> I see.
>
> I guess the question has to be "why is the 5.6.x codebase only to receive
> security fixes for a very brief while into 2017" ?  Just
> curious what the thinking is here.


It goes to 2018, see the RFC [1] that extended it.


[1] https://wiki.php.net/rfc/php56timeline

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

Re: [PHP-DEV] PHP 5.6 end of active support

[Nikita Popov]

On Wed, Dec 14, 2016 at 9:39 PM, Dennis Clarke 
wrote:

> On 12/14/2016 03:31 PM, Marco Pivetta wrote:
>
>> See https://secure.php.net/supported-versions.php
>>
>
> I see.
>
> I guess the question has to be "why is the 5.6.x codebase only to receive
> security fixes for a very brief while into 2017" ?  Just
> curious what the thinking is here.
>

PHP 5.6 receives security fixes for the entirety of 2017 and 2018, not "a
very brief while into 2017".

Re: [PHP-DEV] PHP 5.6 end of active support

[Dennis Clarke]

On 12/14/2016 03:31 PM, Marco Pivetta wrote:

See https://secure.php.net/supported-versions.php


I see.

I guess the question has to be "why is the 5.6.x codebase only to 
receive security fixes for a very brief while into 2017" ?  Just

curious what the thinking is here.


Dennis


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

Re: [PHP-DEV] PHP 5.6 end of active support

[Dennis Clarke]

On 12/14/2016 01:29 PM, David Zuelke wrote:

On 14.12.2016, at 16:15, Dennis Clarke  wrote:


On 12/14/2016 06:35 AM, Kalle Sommer Nielsen wrote:

Hi

On Dec 14, 2016 12:23, "Christoph M. Becker"  wrote:


Hi!

The end of active support for PHP 5.6 is documented to be on December,
31th[1].  Does that mean that there'll be no further release with
"normal" bug fixes (but only security fixes)?


Yes, 5.6 was extended to compensate for 5->7 adoption afair from an rfc



This is entirely too soon. At the present moment neither of the PHP 7.0
releases will compile clean on a strict POSIX environment. At all. The
version 5.6.x tree is perfectly stable and works out of the box without
an endless compile nightmare whereas 7.0.14 and 7.1.0 won't even
compile. I guess I need to file more bug reports


Yes, you do. PHP 7.0.0 was released a year ago.


and push through this
or the 5.6.x version will be dropped with no valid replacement that


5.6 will receive security fixes for another 24 months.


works in a strict environment.  Perhaps the gcc compiler is an absolute
requirement and if that is true then the code isn't acceptable to any
other compiler regardless if it is C99 compliant or otherwise.


It appears to be, from looking at https://bugs.php.net/bug.php?id=67229, but 
that affects PHP 5 as well, not just 7.



Actually looking at that bug we see the problem again. This is a
Solaris 10 system, which is a very strict POSIX system, but the
compiler being used is gcc and the option --std=gnu99 makes reference
to a "defacto standard" that exists no where.  So this is exactly the
problem I see in many many places, code gets releases that compiles
with gcc on some systems but will not pass even a basic compile on a
strict system with a very tightly conforming compiler such as the
Oracle Studio 12.5 tool set. Some code is amazingly clean like libgmp
and we also have PHP 5.6.x which compiles with some extensions but the
7.x codebase won't compile. At all.  Yet. Very close however.[1]

So I need to dig into this as I am sure whatever things I can uncover
and perhaps patch will be of benefit across all systems everywhere. I
think that is what ( now I am just being pedantic ) standards are all
about. Total portability.

Dennis


[1] discussion happened last month in "[PHP-DEV] C89 vs. C99" thread


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

Re: [PHP-DEV] PHP 5.6 end of active support

[Marco Pivetta]

See https://secure.php.net/supported-versions.php

On 14 Dec 2016 9:29 p.m., "Dennis Clarke"  wrote:

>
>
>>
>> PHP 5.6 isn't EOL for a further two years, you should be fine.
>>
>>
> Thank you so much. I can only guess this is posted on a "lifetime" page
> somewhere on php.net but I didn't see it.
>
>
> Dennis
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] PHP 5.6 end of active support

[Dennis Clarke]

PHP 5.6 isn't EOL for a further two years, you should be fine.



Thank you so much. I can only guess this is posted on a "lifetime" page
somewhere on php.net but I didn't see it.


Dennis



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

RE: [PHP-DEV] PaX MPROTECT / W^X protection

[Anatol Belski]

Hi Christoph,

> -Original Message-
> From: Christoph M. Becker [mailto:cmbecke...@gmx.de]
> Sent: Friday, December 9, 2016 4:01 PM
> To: Joe Watkins ; Anatol Belski
> 
> Cc: PHP internals 
> Subject: Re: [PHP-DEV] PaX MPROTECT / W^X protection
> 
> An update regarding the PaX MPROTEXT / W^X protection issue: Zoltan Herczeg
> added a new compile flag which is supposed to avoid this issue, see
>  for details.
> 
> Perhaps something to consider for our builds?
> 
Thanks for keeping an eye on it. One could care about it, as an optional 
feature, yep. How it sounds, it could still improve performance on systems with 
strict configuration, while increasing memory usage. I'd see the urgency as 
low, as the functional part is now ensured by --with-pcre-jit=no.

Thanks

Anatol

> Cheers,
> Christoph
> 
> On 13.11.2016 at 15:00, Christoph M. Becker wrote:
> 
> > Thanks, Anatol and Joe!  So I'm going to document these issues, and
> > close the respective reports.
> >
> > Cheers,
> > Christoph
> >
> > On 13.11.2016 at 07:36, Joe Watkins wrote:
> >
> >> Morning,
> >>
> >> Just wanted to give a thumbs up to documenting the issue ...
> >>
> >> Trying to work around it with platform/distro/kernel specific
> >> solutions, sounds quite horrible, and is bound to be fragile.
> >>
> >> Cheers
> >> Joe
> >>
> >> On Sat, Nov 12, 2016 at 8:25 PM, Anatol Belski
> >> 
> >> wrote:
> >>
> >>> Hi Christoph,
> >>>
>  -Original Message-
>  From: Christoph M. Becker [mailto:cmbecke...@gmx.de]
>  Sent: Friday, November 11, 2016 7:40 PM
>  To: internals@lists.php.net
>  Subject: [PHP-DEV] PaX MPROTECT / W^X protection
> 
>  Hi!
> 
>  There are currently at least two unresolved tickets[1][2] in our
>  bug
> >>> tracker
>  regarding PaX MPROTECT / W^X protection issues with regard to PCRE JIT.
> >>> The
>  problem is that PCRE JIT mmaps W|X pages[3], what is no longer
>  allowed on several platforms, such as OpenBSD, FreeBSD and SELinux.
>  It seems that
> >>> there
>  are workarounds (e.g. using paxctl to allow W|X mapping[1], or
>  mounting
> >>> with
>  wxallowed[4]), but these appear to be very system specific.
> 
>  My best idea to resolve the reports is to document this issue.
>  Maybe
> >>> somebody
>  has a better idea?
> 
> >>> AFM, the linked tickets are not about an issue in PHP. There are
> >>> just systems, or system configurations, that are very security
> >>> oriented. If some feature is disabled on the system level, there's
> >>> not much PHP can do. To compare - it were wrong same way to say
> >>> atime doesn't work in PHP, if indeed a volume is mounted with atime
> >>> disabled. Any issue, that is only to be solved by the system
> >>> configuration, is a configuration issue in the most case. So the
> documentation is probably the only what we can do in the case.
> >>>
> >>> Regrads
> >>>
> >>> 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] PHP 5.6 end of active support

[David Zuelke]

On 14.12.2016, at 16:15, Dennis Clarke  wrote:
> 
> On 12/14/2016 06:35 AM, Kalle Sommer Nielsen wrote:
>> Hi
>> 
>> On Dec 14, 2016 12:23, "Christoph M. Becker"  wrote:
>>> 
>>> Hi!
>>> 
>>> The end of active support for PHP 5.6 is documented to be on December,
>>> 31th[1].  Does that mean that there'll be no further release with
>>> "normal" bug fixes (but only security fixes)?
>> 
>> Yes, 5.6 was extended to compensate for 5->7 adoption afair from an rfc
>> 
> 
> This is entirely too soon. At the present moment neither of the PHP 7.0
> releases will compile clean on a strict POSIX environment. At all. The
> version 5.6.x tree is perfectly stable and works out of the box without
> an endless compile nightmare whereas 7.0.14 and 7.1.0 won't even
> compile. I guess I need to file more bug reports

Yes, you do. PHP 7.0.0 was released a year ago.

> and push through this
> or the 5.6.x version will be dropped with no valid replacement that

5.6 will receive security fixes for another 24 months.

> works in a strict environment.  Perhaps the gcc compiler is an absolute
> requirement and if that is true then the code isn't acceptable to any
> other compiler regardless if it is C99 compliant or otherwise.

It appears to be, from looking at https://bugs.php.net/bug.php?id=67229, but 
that affects PHP 5 as well, not just 7.

David


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

RE: [PHP-DEV] Looking for Z_TYPE_PP in all the wrong places.

[Anatol Belski]

> -Original Message-
> From: Michael Wallner [mailto:mike.php@gmail.com] On Behalf Of Michael
> Wallner
> Sent: Wednesday, December 14, 2016 2:33 PM
> To: rquadl...@gmail.com; PHP internals 
> Subject: Re: [PHP-DEV] Looking for Z_TYPE_PP in all the wrong places.
> 
> On 14/12/16 14:17, Richard Quadling wrote:
> > Hi.
> >
> > I'm trying to find the replacement for Z_TYPE_PP (and several other
> > Z_xxx_PP).
> >
> > It seems these are no longer present in PHP7.
> 
> In PHP-7, you usually do not encounter zval**, so the _PP macros were gone.
> Try _P(*zval) instead.
> 
> >
> > But, according to
> > http://lxr.php.net/source/search?q===Z_TYPE_PP==
> > ype==PHP-MASTER, there is still 1 use case of this particular
> > macro.
> 
> This just means that nobody ever built ext/odbc with the birdstep driver.
> Unfortunate.
> 
Yeah, birdstep was even not ported to 7.0, and monkey patching were anyway 
erroneous. Seems it was a commercial driver, but either it was rebranded or 
discontinued, anyway I never found the driver SDK. It might make sense to 
remove the birdstep part from the ext/odbc, except there's someone with driver 
and maintanence will - it's a dead code.

Regards

Anatol



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

Re: [PHP-DEV] PHP 5.6 end of active support

[Christoph M. Becker]

On 14.12.2016 at 14:05, Niklas Keller wrote:

> 2016-12-14 12:23 GMT+01:00 Christoph M. Becker :
>
>> The end of active support for PHP 5.6 is documented to be on December,
>> 31th[1].  Does that mean that there'll be no further release with
>> "normal" bug fixes (but only security fixes)?
>>
>> [1] 
> 
> It has support until the end of the year, so I guess there will be one more
> release with regular fixes in early January.

Indeed, that is what I'm asking for: will PHP 5.6.30 contain "normal"
bugfixes, or security fixes only?

I'm asking because it's not clear to me whether "normal" bugfixes now
should go to PHP-5.6+ or PHP-7.0+.

-- 
Christoph M. Becker


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

Re: [PHP-DEV] PHP 5.6 end of active support

[Davey Shafik]

On Wed, Dec 14, 2016 at 7:15 AM, Dennis Clarke 
wrote:

> On 12/14/2016 06:35 AM, Kalle Sommer Nielsen wrote:
>
>> Hi
>>
>> On Dec 14, 2016 12:23, "Christoph M. Becker"  wrote:
>>
>>>
>>> Hi!
>>>
>>> The end of active support for PHP 5.6 is documented to be on December,
>>> 31th[1].  Does that mean that there'll be no further release with
>>> "normal" bug fixes (but only security fixes)?
>>>
>>
>> Yes, 5.6 was extended to compensate for 5->7 adoption afair from an rfc
>>
>>
> This is entirely too soon. At the present moment neither of the PHP 7.0
> releases will compile clean on a strict POSIX environment. At all. The
> version 5.6.x tree is perfectly stable and works out of the box without
> an endless compile nightmare whereas 7.0.14 and 7.1.0 won't even
> compile. I guess I need to file more bug reports and push through this
> or the 5.6.x version will be dropped with no valid replacement that
> works in a strict environment.  Perhaps the gcc compiler is an absolute
> requirement and if that is true then the code isn't acceptable to any
> other compiler regardless if it is C99 compliant or otherwise.


PHP 5.6 isn't EOL for a further two years, you should be fine.

- Davey

Re: [PHP-DEV] Looking for Z_TYPE_PP in all the wrong places.

[Richard Quadling]

On 14 December 2016 at 14:37, Christoph M. Becker  wrote:

> On 14.12.2016 at 14:32, Michael Wallner wrote:
>
> > On 14/12/16 14:17, Richard Quadling wrote:
> >> Hi.
> >>
> >> I'm trying to find the replacement for Z_TYPE_PP (and several other
> >> Z_xxx_PP).
> >>
> >> It seems these are no longer present in PHP7.
> >
> > In PHP-7, you usually do not encounter zval**, so the _PP macros were
> > gone. Try _P(*zval) instead.
>
> See also  for further information.
>
> --
> Christoph M. Becker
>
>
Thank you for that. I wasn't sure where to look for the answer.


-- 
Richard Quadling

Re: [PHP-DEV][RFC][DISCUSSION] - Immutable classes and properties

[Andrea Faulds]

Hi,

Paul Jones wrote:



On Dec 12, 2016, at 13:36, Andrea Faulds  wrote:

Consider that some popular applications of immutability ultimately contain a 
reference to something mutable: PSR-7's immutable HTTP message objects point to 
mutable streams


Which subverts its overall promise of immutability (and the streams are not the 
only place where the promise of immutability is subverted).


Indeed. It's not necessarily a good feature, don't get me wrong.

--
Andrea Faulds
https://ajf.me/

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

Re: [PHP-DEV] PHP 5.6 end of active support

[Dennis Clarke]

On 12/14/2016 06:35 AM, Kalle Sommer Nielsen wrote:

Hi

On Dec 14, 2016 12:23, "Christoph M. Becker"  wrote:


Hi!

The end of active support for PHP 5.6 is documented to be on December,
31th[1].  Does that mean that there'll be no further release with
"normal" bug fixes (but only security fixes)?


Yes, 5.6 was extended to compensate for 5->7 adoption afair from an rfc



This is entirely too soon. At the present moment neither of the PHP 7.0
releases will compile clean on a strict POSIX environment. At all. The
version 5.6.x tree is perfectly stable and works out of the box without
an endless compile nightmare whereas 7.0.14 and 7.1.0 won't even
compile. I guess I need to file more bug reports and push through this
or the 5.6.x version will be dropped with no valid replacement that
works in a strict environment.  Perhaps the gcc compiler is an absolute
requirement and if that is true then the code isn't acceptable to any
other compiler regardless if it is C99 compliant or otherwise.

Dennis Clarke



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

[PHP-DEV] UGLY Benchmark Results for PHP Master 2016-12-13

[lp_benchmark_robot]

Results for project PHP master, build date 2016-12-13 20:29:05-08:00
commit: 9bcd2bc
previous commit:675fc9e
revision date:  2016-12-14 03:12:46+01:00
environment:Haswell-EP
cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores, 
stepping 2, LLC 45 MB
mem:128 GB
os: CentOS 7.1
kernel: Linux 3.10.0-229.4.2.el7.x86_64

Baseline results were generated using release php-7.0.0, with hash 60fffd2 from
2015-12-01 04:16:47+00:00

---
benchmark   relative   change since   change since  
current rev run
std_dev*   last run   baseline  
   with PGO
---
:-|   Wordpress 4.2.2 cgi -T1  0.28% -0.35% -0.63%  
  7.96%
:-|   Drupal 7.36 cgi -T1  0.19%  0.22% -0.61%  
  4.14%
:-|   MediaWiki 1.23.9 cgi -T5000  0.13%  0.19%  0.66%  
  3.28%
:-|   bench.php cgi -T100  0.05% -0.34% 37.18%  
 -8.79%
:-(  micro_bench.php cgi -T10  0.02% -2.31% 13.72%  
  3.86%
:-)  mandelbrot.php cgi -T100  1.61% 17.56% 30.56%  
  1.75%
---

* Relative Standard Deviation (Standard Deviation/Average)

If this is not displayed properly please visit our results page here: 
http://languagesperformance.intel.com/ugly-benchmark-results-for-php-master-2016-12-13/

Note: Benchmark results for Wordpress, Drupal, MediaWiki are measured in
fetches/second while all others are measured in seconds.
More details on measurements methodology at: 
https://01.org/lp/documentation/php-environment-setup.

Subject Label Legend:
Attributes are determined based on the performance evolution of the workloads
compared to the previous measurement iteration.
NEUTRAL: performance did not change by more than 1% for any workload
GOOD: performance improved by more than 1% for at least one workload and there
is no regression greater than 1%
BAD: performance dropped by more than 1% for at least one workload and there is
no improvement greater than 1%
UGLY: performance improved by more than 1% for at least one workload and also
dropped by more than 1% for at least one workload


Our lab does a nightly source pull and build of the PHP project and measures
performance changes against the previous stable version and the previous nightly
measurement. This is provided as a service to the community so that quality
issues with current hardware can be identified quickly.

Intel technologies' features and benefits depend on system configuration and may
require enabled hardware, software or service activation. Performance varies
depending on system configuration.


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

Re: [PHP-DEV] Looking for Z_TYPE_PP in all the wrong places.

[Christoph M. Becker]

On 14.12.2016 at 14:32, Michael Wallner wrote:

> On 14/12/16 14:17, Richard Quadling wrote:
>> Hi.
>>
>> I'm trying to find the replacement for Z_TYPE_PP (and several other
>> Z_xxx_PP).
>>
>> It seems these are no longer present in PHP7.
> 
> In PHP-7, you usually do not encounter zval**, so the _PP macros were
> gone. Try _P(*zval) instead.

See also  for further information.

-- 
Christoph M. Becker


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

Re: [PHP-DEV] Looking for Z_TYPE_PP in all the wrong places.

[Michael Wallner]

On 14/12/16 14:17, Richard Quadling wrote:
> Hi.
> 
> I'm trying to find the replacement for Z_TYPE_PP (and several other
> Z_xxx_PP).
> 
> It seems these are no longer present in PHP7.

In PHP-7, you usually do not encounter zval**, so the _PP macros were
gone. Try _P(*zval) instead.

> 
> But, according to
> http://lxr.php.net/source/search?q===Z_TYPE_PPPHP-MASTER,
> there is still 1 use case of this particular macro.

This just means that nobody ever built ext/odbc with the birdstep
driver. Unfortunate.

-- 
Regards,
Mike



signature.asc
Description: OpenPGP digital signature

[PHP-DEV] Looking for Z_TYPE_PP in all the wrong places.

[Richard Quadling]

Hi.

I'm trying to find the replacement for Z_TYPE_PP (and several other
Z_xxx_PP).

It seems these are no longer present in PHP7.

But, according to
http://lxr.php.net/source/search?q===Z_TYPE_PPPHP-MASTER,
there is still 1 use case of this particular macro.

So. I'm hoping to see what the change for this is as it can't currently
compile under PHP7?

I'm not a hardcode C / PHP core developer, but I'm getting asked to provide
support for the win32service extension. Currently it fails to compile :
https://bugs.php.net/bug.php?id=73733

Just looking for some pointers. Literally! Ha ha!

Regards,

Richard Quadling.

Re: [PHP-DEV] PHP 5.6 end of active support

[Niklas Keller]

2016-12-14 12:23 GMT+01:00 Christoph M. Becker :

> Hi!
>
> The end of active support for PHP 5.6 is documented to be on December,
> 31th[1].  Does that mean that there'll be no further release with
> "normal" bug fixes (but only security fixes)?
>
> [1] 
>

It has support until the end of the year, so I guess there will be one more
release with regular fixes in early January.

Regards, Niklas

Re: [PHP-DEV] PHP 5.6 end of active support

[Kalle Sommer Nielsen]

Hi

On Dec 14, 2016 12:23, "Christoph M. Becker"  wrote:
>
> Hi!
>
> The end of active support for PHP 5.6 is documented to be on December,
> 31th[1].  Does that mean that there'll be no further release with
> "normal" bug fixes (but only security fixes)?

Yes, 5.6 was extended to compensate for 5->7 adoption afair from an rfc

>
> [1] 
>
> --
> Christoph M. Becker
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

[PHP-DEV] PHP 5.6 end of active support

[Christoph M. Becker]

Hi!

The end of active support for PHP 5.6 is documented to be on December,
31th[1].  Does that mean that there'll be no further release with
"normal" bug fixes (but only security fixes)?

[1] 

-- 
Christoph M. Becker

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