# RFC: Move phpng to master

- Thread: https://externals.io/message/75741
- Original archive: https://news-web.php.net/php.internals/75741
- Started by Zeev Suraski on 2014-07-21T07:31:46+00:00
- Messages: 133
- Page 1 of 6: messages 1 to 25 (25 per page, add `?page=N` to the URL)
- Next page: https://externals.io/message/75741.md?page=2
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #75741 — Zeev Suraski — 2014-07-21T07:31:46+00:00

URL: https://externals.io/message/75741#75741

All,



As we’re getting closer to release 5.6.0, and given the very high level of
interest in phpng, I think it’s time for us to provide some clarity
regarding what happens post 5.6.0.



Dmitry and I wrote an RFC proposing that we merge phpng into master and
turn it into the basis of the next major version of PHP (name TBD).



The RFC is available at https://wiki.php.net/rfc/phpng



Some supporting links available down below.



Comments welcome!



Zeev







Performance evaluation & evolution of phpng:

https://wiki.php.net/phpng#performance_evaluation



phpng internals:

https://wiki.php.net/phpng-int



Benchmarking PHPNG (benchmark results of phpng vs 5.4, 5.5, 5.6 and hhvm):

http://zsuraski.blogspot.co.il/2014/07/benchmarking-phpng.html

---

## #75743 — Pierre Joye — 2014-07-21T07:52:13+00:00

URL: https://externals.io/message/75741#75743 · In reply to: #75741

hi Zeev,


> All,
>
>
>
> As we’re getting closer to release 5.6.0, and given the very high level of
> interest in phpng, I think it’s time for us to provide some clarity
> regarding what happens post 5.6.0.
>
>
>
> Dmitry and I wrote an RFC proposing that we merge phpng into master and
> turn it into the basis of the next major version of PHP (name TBD).
>
>
>
> The RFC is available at https://wiki.php.net/rfc/phpng
>
>
>
> Some supporting links available down below.
>
>
>
> Comments welcome!

Quoting Dmitry's mail from last week "phpng is an experimental
branch", as such, I see no appealing reasons to replace master with
phpng and use phpng as base for the next major version. I am not
really surprised by this request, despite contradictory comments about
this exact point in the past few weeks.

Despite the excellent performance improvements, it is by far not ready
to be used as base for the next major release, the release we will
have to maintain for the next decade. There is almost no
documentation, the APIs are not clean or inconsistent (just came back
home, will provide details later) but having two separate zpp, same
area's functions mixing use of zend_char and char (creating hard to
catch bugs, not always catch-able at compile time f.e.), no (known)
plan about when the experiments will stop and when or how deep the
cleanup will be done.

In other words, I cannot agree to replace master with phpng, not with
its current state and it is definitively not what I could imagine as a
base for php-next. A roadmap, undocumented and plan-less development
(sorry, but stacking up a couple of % performance improvement has
little to nothing to do with designing php-next)  is the best way to
fail to have what many of our users and developers could expect for
php-next.

Cheers,
-- 
Pierre

@pierrejoye | http://www.libgd.org

---

## #75745 — Julien Pauli — 2014-07-21T08:20:51+00:00

URL: https://externals.io/message/75741#75745 · In reply to: #75743

> hi Zeev,
>
> 
> > […]
>
> Quoting Dmitry's mail from last week "phpng is an experimental
> branch", as such, I see no appealing reasons to replace master with
> phpng and use phpng as base for the next major version. I am not
> really surprised by this request, despite contradictory comments about
> this exact point in the past few weeks.
>
> Despite the excellent performance improvements, it is by far not ready
> to be used as base for the next major release, the release we will
> have to maintain for the next decade. There is almost no
> documentation, the APIs are not clean or inconsistent (just came back
> home, will provide details later) but having two separate zpp, same
> area's functions mixing use of zend_char and char (creating hard to
> catch bugs, not always catch-able at compile time f.e.), no (known)
> plan about when the experiments will stop and when or how deep the
> cleanup will be done.
>
> In other words, I cannot agree to replace master with phpng, not with
> its current state and it is definitively not what I could imagine as a
> base for php-next. A roadmap, undocumented and plan-less development
> (sorry, but stacking up a couple of % performance improvement has
> little to nothing to do with designing php-next)  is the best way to
> fail to have what many of our users and developers could expect for
> php-next.
>
> Cheers,
> --
> Pierre

Hi

I can only agree here.

I'd like a clean API. We need to consider PHP-Next jump as an opportunity to
clean our API and finally have something understandable for a
newcomer, and documented. That's a move nobody dared to take in the
last decade, degrading more and more our codebase in term of
understandability and flexibility. This can't last

Old features and unused things should be cleaned up.
Quickly caught, impacting the engine :
- Resources are a hell, mixed with zend_lists etc... inconsitstent and
absolutely PITA to develop with.
- Streams need to be cleaned up and reworked to support full
asynchronous IOs, which could involve threads, thus engine tied
- Signals have been worked on starting with 5.4 (AFAIR), but never
activated by default. I guess the actual implementation lacks a bit
more reflection to be stable, and to finally propose signal managers
into userland. ext/pcntl should be somehow merged to core, and this as
well would involve engine work
- TSRM need to find love, or to find a better replacement, which would
involve a big engine work as well
- ... and so on

Macro hell should be reworked as inlined functions, and I'd like we
start supporting C99 as well.

Performance is a userland point.
API, doc, and clean things are developers points, and IMO, they are as
important.

What about merging OPCache to the branch ?
This was talked about at PHP5.5 release, has never happened yet, and
doesn't seem planed. This could have a big impact on the engine
codebase.

I just cant believe we won't rework our API , fully and deeply, for PHP-Next.

Julien

---

## #75746 — Zeev Suraski — 2014-07-21T08:33:50+00:00

URL: https://externals.io/message/75741#75746 · In reply to: #75745

> Hi
>
> We need to consider PHP-Next jump as an opportunity to
> clean our API and finally have something understandable for a newcomer,
> and
> documented. That's a move nobody dared to take in the last decade,
> degrading more and more our codebase in term of understandability and
> flexibility. This can't last

It's absolutely fine to have separate discussions on cleaning APIs, new
features and any other changes people think we should do, but it absolutely
has nothing to do with phpng moving into master.  We can take the
opportunity of a major version to do some cleanups, BUT:

1. It's independent from the phpng effort and RFC.  We should vote on it as
soon as possible to remove any doubts that do linger in people's minds
regarding whether at all we're going to use it.
2. We should set a due date for this version, so that we don't wait
indefinitely for things to happen.  We don't have the luxury of 'sitting' on
phpng for years, IMHO.  This too is an independent question from this RFC.


> I just cant believe we won't rework our API , fully and deeply, for
> PHP-Next.

You're more than welcome to make such proposals and either write patches or
rally others to write them.  This RFC doesn't preclude any other changes
happening in PHP.NEXT, it just removes the doubts about this being the basis
for the next version of PHP.

Regarding Dmitry saying that phpng is an experimental branch - that was a
couple of months ago.  It evolved, it runs apps in parity with 5.6, and it's
fine to move it to master right now.  The alternative - developing 5.7 on
master and creating a synchronization hell - sounds like a horrible course
of action.

Zeev

---

## #75748 — Sebastian Bergmann — 2014-07-21T09:13:31+00:00

URL: https://externals.io/message/75741#75748 · In reply to: #75746

Am 21.07.2014 10:33, schrieb Zeev Suraski:
> Regarding Dmitry saying that phpng is an experimental branch - that was a
> couple of months ago.  It evolved, it runs apps in parity with 5.6, and it's
> fine to move it to master right now.  The alternative - developing 5.7 on
> master and creating a synchronization hell - sounds like a horrible course
> of action.

 I was not able to run PHPUnit using PHPNG at all back when it was first
 announced.

 I was able to run PHPUnit 4.3 (master)'s test suite using PHPNG last
 week, btw. Only one test fails (due to a change in the output of
 `print_r()` for SplObjectStorage IIRC). This tells me that there was a lot
 of progress :-)

---

## #75750 — JoshyPHP — 2014-07-21T09:16:57+00:00

URL: https://externals.io/message/75741#75750 · In reply to: #75746

> Regarding Dmitry saying that phpng is an experimental branch - that was a
> couple of months ago.  It evolved, it runs apps in parity with 5.6, and
> it's
> fine to move it to master right now.

Perhaps you could write a summary of what's changed since phpng was
uncovered a couple of months ago? (besides better performance and
greater compatibility with existing PHP) And also update the existing
RFC with the benefits of merging this branch to master, as opposed to
describing the inconvenience of not merging it.

I'm sure that would help keep the discussion on topic and grounded in fact.

---

## #75753 — Dmitry Stogov — 2014-07-21T09:27:57+00:00

URL: https://externals.io/message/75741#75753 · In reply to: #75745

Hi Julien,


> Hi
>
> I can only agree here.
>
> I'd like a clean API. We need to consider PHP-Next jump as an opportunity
> to
> clean our API and finally have something understandable for a
> newcomer, and documented. That's a move nobody dared to take in the
> last decade, degrading more and more our codebase in term of
> understandability and flexibility. This can't last
>

I'm more than agree about internal cleanup.
phpng benchmark results proved that we take the right direction and now we
implemented most the ideas we had.
Note that we tried not to change PHP behaviour in any way.
Now it's a good time to start the cleanup work.


> Old features and unused things should be cleaned up.
> Quickly caught, impacting the engine :
> - Resources are a hell, mixed with zend_lists etc... inconsitstent and
> absolutely PITA to develop with.
> - Streams need to be cleaned up and reworked to support full
> asynchronous IOs, which could involve threads, thus engine tied
> - Signals have been worked on starting with 5.4 (AFAIR), but never
> activated by default. I guess the actual implementation lacks a bit
> more reflection to be stable, and to finally propose signal managers
> into userland. ext/pcntl should be somehow merged to core, and this as
> well would involve engine work
> - TSRM need to find love, or to find a better replacement, which would
> involve a big engine work as well
> - ... and so on
>

Some of the topics above are really big... :)


>
> Macro hell should be reworked as inlined functions, and I'd like we
> start supporting C99 as well.
>
> Performance is a userland point.
> API, doc, and clean things are developers points, and IMO, they are as
> important.
>
> What about merging OPCache to the branch ?
> This was talked about at PHP5.5 release, has never happened yet, and
> doesn't seem planed. This could have a big impact on the engine
> codebase.
>

What do you mean? isn't it already there.
I'm also going to remove opcache code for old PHP versions in php-next.


> I just cant believe we won't rework our API , fully and deeply, for
> PHP-Next.
>

You and others are welcome. Once we merge phpng into master, we all may
cooperate better.

Thanks. Dmitry.


>
> Julien

---

## #75754 — Yasuo Ohgaki — 2014-07-21T09:31:40+00:00

URL: https://externals.io/message/75741#75754 · In reply to: #75741

Hi Zeev,



> As we’re getting closer to release 5.6.0, and given the very high level of
> interest in phpng, I think it’s time for us to provide some clarity
> regarding what happens post 5.6.0.
>

Are you willing to have 5.7 branch?
It gives us more time to develop/cleanup/test. It's especially important for
3rd party module developers.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

---

## #75755 — Michael Wallner — 2014-07-21T09:37:09+00:00

URL: https://externals.io/message/75741#75755 · In reply to: #75745

>
> 
> > […]
level of
> > […]
>
> Hi
>
> I can only agree here.
>
> I'd like a clean API. We need to consider PHP-Next jump as an opportunity
to
> clean our API and finally have something understandable for a
> newcomer, and documented. That's a move nobody dared to take in the
> last decade, degrading more and more our codebase in term of
> understandability and flexibility. This can't last
>
> Old features and unused things should be cleaned up.
> Quickly caught, impacting the engine :
> - Resources are a hell, mixed with zend_lists etc... inconsitstent and
> absolutely PITA to develop with.
> - Streams need to be cleaned up and reworked to support full
> asynchronous IOs, which could involve threads, thus engine tied
> - Signals have been worked on starting with 5.4 (AFAIR), but never
> activated by default. I guess the actual implementation lacks a bit
> more reflection to be stable, and to finally propose signal managers
> into userland. ext/pcntl should be somehow merged to core, and this as
> well would involve engine work
> - TSRM need to find love, or to find a better replacement, which would
> involve a big engine work as well
> - ... and so on
>
> Macro hell should be reworked as inlined functions, and I'd like we
> start supporting C99 as well.
>
> Performance is a userland point.
> API, doc, and clean things are developers points, and IMO, they are as
> important.
>
> What about merging OPCache to the branch ?
> This was talked about at PHP5.5 release, has never happened yet, and
> doesn't seem planed. This could have a big impact on the engine
> codebase.
>
> I just cant believe we won't rework our API , fully and deeply, for
PHP-Next.

I don't think that a cleanup is nearly as important as php-ng is as we
stand currently.

The will be no mercy from the competition.

We can start reworking the API when it hit master.

---

## #75759 — Derick Rethans — 2014-07-21T10:04:53+00:00

URL: https://externals.io/message/75741#75759 · In reply to: #75741

> As we’re getting closer to release 5.6.0, and given the very high level of
> interest in phpng, I think it’s time for us to provide some clarity
> regarding what happens post 5.6.0.
> 
> Dmitry and I wrote an RFC proposing that we merge phpng into master and
> turn it into the basis of the next major version of PHP (name TBD).
> 
> The RFC is available at https://wiki.php.net/rfc/phpng

I was wondering whether there is an extension upgrading guide somewhere? 
I saw that https://wiki.php.net/phpng-int lists the changes to zvals, 
but it's not a guide and/or checklist on what to do for upgrading an 
extension. This, IMO, should include things such as:

- which things needs changing
- how object instanciation is now different
- common pitfalls and errors. 
- etc.

If there isn't such a thing, it's going to be quite necessary for 3rd 
party extension developers I'd say.

cheers,
Derick

---

## #75760 — Matteo Beccati — 2014-07-21T10:07:37+00:00

URL: https://externals.io/message/75741#75760 · In reply to: #75748

> Am 21.07.2014 10:33, schrieb Zeev Suraski:
> > […]
> 
>  I was not able to run PHPUnit using PHPNG at all back when it was first
>  announced.
> 
>  I was able to run PHPUnit 4.3 (master)'s test suite using PHPNG last
>  week, btw. Only one test fails (due to a change in the output of
>  `print_r()` for SplObjectStorage IIRC). This tells me that there was a lot
>  of progress :-)

I have temporarily re-enabled the phpng jobs on my CI server to assess
the current situation.

I can confirm that just one test is failing with PHPUnit master. It
seems that print_r is not displaying StdClass properties as it used to:

https://revive.beccati.com/bamboo/browse/PHP-PHPUN-PHPNG-55/test/case/11800493


On the other hand Doctrine master can't even run the entire test suite
due to:

Fatal error: Call to a member function getConfiguration() on null in
/home/atlassian/bamboo/xml-data/build-dir/PHP-DOCTR-PHPNG/tests/Doctrine/Tests/OrmFunctionalTestCase.php
on line 482

(pretty sure it's not a null there: a var_dump before the call tells me
it's an object)

https://revive.beccati.com/bamboo/browse/PHP-DOCTR-PHPNG-52/log


The Revive Adserver test suite fails miserably (86+ out of 274 test
files), mostly due to errors like:

/home/atlassian/bamboo/xml-data/build-dir/PHP-SRC3-BUIL/Zend/zend_hash.c(1369)
: ht=0x29c7aa8 is already destroyed

and some "Call to a member function" errors on object variables that are
mysteriously seen as null.

https://revive.beccati.com/bamboo/browse/REV-LP-PNGP-64

There's lots of legacy code in there and it has proved to be useful in
past to catch a few uncommon segmentation faults. I'm pretty sure that
there are plenty other applications that can't work with phpng as it is now.

To be honest I don't think we're anywhere near the point where it's safe
to merge phpng to master.

Also, one thing that might have been overlooked is that merging phpng to
master would completely bypass the voting phase on
https://wiki.php.net/rfc/fast_zpp


Cheers
-- 
Matteo Beccati

Development & Consulting - http://www.beccati.com/

---

## #75761 — Zeev Suraski — 2014-07-21T10:16:16+00:00

URL: https://externals.io/message/75741#75761 · In reply to: #75760

> -----Original Message-----
> From: Matteo Beccati [mailto:php@beccati.com]
> Sent: Monday, July 21, 2014 1:08 PM
> To: internals@lists.php.net
> Cc: Sebastian Bergmann
> Subject: Re: [PHP-DEV] RFC: Move phpng to master
>
> To be honest I don't think we're anywhere near the point where it's safe
> to
> merge phpng to master.

Why?  People aren't supposed to run production or even development code
initially from master.

I don't know how many people here were around when PHP 5, 4 and 3 came to
be - but when you're dealing with a major version with such massive code
changes, you don't get everything right in day one.  It will require a
community effort - which is exactly what we're trying to achieve here.  I
don't think that community effort will happen if we don't move it to master
and give developers the needed clarity and motivation to work on this.

> Also, one thing that might have been overlooked is that merging phpng to
> master would completely bypass the voting phase on
> https://wiki.php.net/rfc/fast_zpp

Our thinking is to use this only for performance sensitive functions that
actually move the needle, as opposed to using it across the board - which
was the original thinking behind the fast_zpp API.  Fast_zpp for this
limited set of functions is now a part of phpng;  We can decide whether or
not we revisit the proposal for using fast_zpp more widely, although as I
said in the past, I'm not too fond of the new macro-based APIs myself.  For
performance sensitive functions that are used a lot, though, I think it
makes perfect sense.

Zeev

---

## #75762 — Zeev Suraski — 2014-07-21T10:18:02+00:00

URL: https://externals.io/message/75741#75762 · In reply to: #75754

*From:* yohgaki@gmail.com [mailto:yohgaki@gmail.com] *On Behalf Of *Yasuo
Ohgaki
*Sent:* Monday, July 21, 2014 12:32 PM
*To:* Zeev Suraski
*Cc:* PHP internals
*Subject:* Re: [PHP-DEV] RFC: Move phpng to master



Hi Zeev,





As we’re getting closer to release 5.6.0, and given the very high level of
interest in phpng, I think it’s time for us to provide some clarity
regarding what happens post 5.6.0.



Are you willing to have 5.7 branch?

It gives us more time to develop/cleanup/test. It's especially important for

3rd party module developers.

Can you explain a bit more what you mean by that?  I generally don’t think
we should invest in another feature release before this next phpng-based
major version (that’s my personal thinking).  It’ll spread our limited
resources too thin;  But maybe I didn’t quite understand what you had in
mind for putting in the 5.7 branch.



Zeev

---

## #75763 — Pierre Joye — 2014-07-21T10:18:58+00:00

URL: https://externals.io/message/75741#75763 · In reply to: #75746

> It's absolutely fine to have separate discussions on cleaning APIs, new
> features and any other changes people think we should do, but it absolutely
> has nothing to do with phpng moving into master.  We can take the
> opportunity of a major version to do some cleanups, BUT:

It is obviously not only absolutely fine, it is a requirement. It
should have done before anything else, for obvious reasons.


> 1. It's independent from the phpng effort and RFC.  We should vote on it as
> soon as possible to remove any doubts that do linger in people's minds
> regarding whether at all we're going to use it.

If it is independent from phpng then phpng is nothing more than a (set
of) patches that should be proposed independently and not as a
replacement for master or as base for php-next.

> 2. We should set a due date for this version, so that we don't wait
> indefinitely for things to happen.  We don't have the luxury of 'sitting' on
> phpng for years, IMHO.  This too is an independent question from this RFC.

I wonder when you have been while we were talking about what we
actually like to do and have in php-next. Maybe it was a better
strategic choice to participate in the various efforts to get a clear,
well discussed and designed roadmap rather than doing this massive set
of patches in your corner. And yes, I already said that many times.

> > […]
>
> You're more than welcome to make such proposals and either write patches or
> rally others to write them.  This RFC doesn't preclude any other changes
> happening in PHP.NEXT, it just removes the doubts about this being the basis
> for the next version of PHP.

As a matter of facts, and despite your (team) numerous posts saying
that you had no plan to do what you are proposing here, the efforts
for php-next has simply being stopped to avoid the pain that was the
64bit RFC because of phpng. A RFC that you totally agreed to have in
next as it was earlier this year after having rejecting it for 5.x.
>
> Regarding Dmitry saying that phpng is an experimental branch - that was a
> couple of months ago.

That was last week or at the end of the previous week. Amazingly
enough, at the same time you were saying that phpng was pretty stable
and no more huge changes will happen, many huge changes reached this
branch, and these changes were not bugs fixes. It tells me a lot about
the visibility you have on phpng. I do not mean to offend anyone here
but for what I see here is what we had with opcache, power 20. I do
not want to see that for php-next, or we can just begin to vote for
what will be the next major version once we borked 6 and 7.

> It evolved, it runs apps in parity with 5.6, and it's
> fine to move it to master right now.  The alternative - developing 5.7 on
> master and creating a synchronization hell - sounds like a horrible course
> of action.

Welcome to the world you created for us since you rejected a 200%
stable branch and then killing it by introducing an experimental one,
with a clear goal, from the very beginning, to replace master for the
next major version. This world is not the one I want or wish for the
PHP core.

Now, enough bashing.

What I wish to even consider reviewing or discussing phpng any further:

- clear documentation of the changes and migration plans
- clear roadmap of upcoming changes, even work in progress
- how open you are to changes (cleanup, APIs consistency
"improvements",etc.) in phpng before it is merged, no matter how
- integration of existing patches, blocked now since months by phpng,
and how you plan to support us to merge them in phpng, if it ever
happens.
- actual discussions about what we want for php-next, as performance
is only  very tiny part of the work for php-next


Cheers,
-- 
Pierre

@pierrejoye | http://www.libgd.org

---

## #75764 — Pierre Joye — 2014-07-21T10:22:07+00:00

URL: https://externals.io/message/75741#75764 · In reply to: #75755

>

> I don't think that a cleanup is nearly as important as php-ng is as we stand
> currently.
>
> The will be no mercy from the competition.
>
> We can start reworking the API when it hit master.

Cleanup reduces the work, not increase it. Cleanup eases testing,
review and maintenance. I am sorry but I totally fail to understand
why it is not the absolute top goal for next.


-- 
Pierre

@pierrejoye | http://www.libgd.org

---

## #75765 — Ferenc Kovacs — 2014-07-21T10:24:01+00:00

URL: https://externals.io/message/75741#75765 · In reply to: #75762

> *From:* yohgaki@gmail.com [mailto:yohgaki@gmail.com] *On Behalf Of *Yasuo
> Ohgaki
> *Sent:* Monday, July 21, 2014 12:32 PM
> *To:* Zeev Suraski
> *Cc:* PHP internals
> *Subject:* Re: [PHP-DEV] RFC: Move phpng to master
>
>
>
> Hi Zeev,
>
>
>
> 
>
> As we’re getting closer to release 5.6.0, and given the very high level of
> interest in phpng, I think it’s time for us to provide some clarity
> regarding what happens post 5.6.0.
>
>
>
> Are you willing to have 5.7 branch?
>
> It gives us more time to develop/cleanup/test. It's especially important
> for
>
> 3rd party module developers.
>
> Can you explain a bit more what you mean by that?  I generally don’t think
> we should invest in another feature release before this next phpng-based
> major version (that’s my personal thinking).  It’ll spread our limited
> resources too thin;  But maybe I didn’t quite understand what you had in
> mind for putting in the 5.7 branch.
>
>
>
> Zeev
>

He just asks if we will have a 5.7 release while working on the next major
in master.
I don't think that we can release the php-next under a years, so I think
that an 5.7 could be warranted (to keep up with our roadmap), but depends
on wether or not we have enough new (BC-safe) features.


-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

---

## #75766 — Marco Pivetta — 2014-07-21T10:24:25+00:00

URL: https://externals.io/message/75741#75766 · In reply to: #75761

Hi Zeev,



> > […]
>
> Why?  People aren't supposed to run production or even development code
> initially from master.
>

I don't know how things are driven here, but I assume that OSS projects
don't merge stuff into master until tests pass: it's as simple as that.
That's your blocker right there, regardless of voting or any other
discussion going on.

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

---

## #75767 — Julien Pauli — 2014-07-21T10:24:30+00:00

URL: https://externals.io/message/75741#75767 · In reply to: #75753

> Hi Julien,
>
> > […]
>
>
> I'm more than agree about internal cleanup.
> phpng benchmark results proved that we take the right direction and now we
> implemented most the ideas we had.
> Note that we tried not to change PHP behaviour in any way.
> Now it's a good time to start the cleanup work.

Not changing behavior is nice and very hard work to do, so congrats on that one.

If cleaning the API receives "no-go" because the cleanups would
involve swaping some parameters in functions, or turning macros to
inline functions , which drops some little percentage in performance
on some rare compilers, then there will be a problem to me.

We need a trade-off here. We can't leave unreadable code in, should
this code be written in a specific way for performances. We can afford
a little 1% or 2 IMO.

>
> > […]
>
>
> Some of the topics above are really big... :)
>
> > […]
>
>
> What do you mean? isn't it already there.
> I'm also going to remove opcache code for old PHP versions in php-next.

I was talking about merging the code bases.
For example, shared memory model from OPCache could be merged into
Zend/ and expose an API one could reuse in extensions needing SHM.
Also, accelerator's code could be merged into Zend/zend_execute and Zend/ZendVM

Julien

---

## #75768 — Zeev Suraski — 2014-07-21T10:30:11+00:00

URL: https://externals.io/message/75741#75768 · In reply to: #75766

I don't know how things are driven here, but I assume that OSS projects
don't merge stuff into master until tests pass: it's as simple as that.

That's your blocker right there, regardless of voting or any other
discussion going on.



There’s a huge difference between a major code changes as we line up for a
new major version – one that requires widespread testing and community
support – and the relatively minor changes we’ve had here ever since PHP 5.

So from my POV at least, that assumption is incorrect.


Zeev

---

## #75769 — Pierre Joye — 2014-07-21T10:31:07+00:00

URL: https://externals.io/message/75741#75769 · In reply to: #75765

>
> He just asks if we will have a 5.7 release while working on the next major
> in master.
> I don't think that we can release the php-next under a years, so I think
> that an 5.7 could be warranted (to keep up with our roadmap), but depends
> on wether or not we have enough new (BC-safe) features.

Clearly yes, for two reasons:

- we do one x.y+1 every year
- php-next will take 2-3 years, ideally (while I have doubts when I
see what is going on now)

Cheers,
-- 
Pierre

@pierrejoye | http://www.libgd.org

---

## #75770 — Zeev Suraski — 2014-07-21T10:31:47+00:00

URL: https://externals.io/message/75741#75770 · In reply to: #75765

He just asks if we will have a 5.7 release while working on the next major
in master.

I don't think that we can release the php-next under a years, so I think
that an 5.7 could be warranted (to keep up with our roadmap), but depends
on wether or not we have enough new (BC-safe) features.

I don’t see a reason of why we can’t have this major version ready by or
even sooner than the current yearly rhythm we have.  In fact, if we do aim
to work in parallel on both 5.7 and .NEXT – we’re likely to needlessly
delay .NEXT…



Zeev

---

## #75771 — Marco Pivetta — 2014-07-21T10:35:57+00:00

URL: https://externals.io/message/75741#75771 · In reply to: #75768

>
> There’s a huge difference between a major code changes as we line up for a
> new major version – one that requires widespread testing and community
> support – and the relatively minor changes we’ve had here ever since PHP 5.
>
> So from my POV at least, that assumption is incorrect.
>

We provide an extensive test suite (for every project) which can be run by
anyone, and you are getting my feedback for it right now ;-)
Matteo was also nice to set up a PHPNG environment where D2 tests are run,
so you can have continuous feedback as well.

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

---

## #75772 — Derick Rethans — 2014-07-21T10:41:07+00:00

URL: https://externals.io/message/75741#75772 · In reply to: #75753

> > […]
> 
> I'm more than agree about internal cleanup. phpng benchmark results 
> proved that we take the right direction and now we implemented most 
> the ideas we had. Note that we tried not to change PHP behaviour in 
> any way. Now it's a good time to start the cleanup work.

Actually, I think that should be done after merging / changing it to 
master. Right now, the phpng vs master branch differences are ... rather 
large. It'd be good to do additional cleanup in smaller chunks later on 
as it makes it a lot easier to review those changes.

cheers,
Derick

---

## #75773 — Pierre Joye — 2014-07-21T10:41:42+00:00

URL: https://externals.io/message/75741#75773 · In reply to: #75770

> He just asks if we will have a 5.7 release while working on the next major
> in master.
>
> I don't think that we can release the php-next under a years, so I think
> that an 5.7 could be warranted (to keep up with our roadmap), but depends
> on wether or not we have enough new (BC-safe) features.
>
> I don’t see a reason of why we can’t have this major version ready by or
> even sooner than the current yearly rhythm we have.  In fact, if we do aim
> to work in parallel on both 5.7 and .NEXT – we’re likely to needlessly
> delay .NEXT…

Please, Zeev, please. You are again doing a major time and planning
estimation mistake, which will affect all of us.

It is impossible to get php-next ready by next year, simply
impossible. Even if all we will have is phpng, we won't make it.

And really, I rather prefer to do not any php-next now if your only
plans are in phpng.

And as of getting stable before merging, I totally agree with Marco
and you did too when we were talking about the 64bit RFC, which is by
an order of magnitude much smaller and complex than phpng.

-- 
Pierre

@pierrejoye | http://www.libgd.org

---

## #75774 — Dmitry Stogov — 2014-07-21T10:41:57+00:00

URL: https://externals.io/message/75741#75774 · In reply to: #75760

Hi Matteo,

We have very limited forces to test everything. Once we we have bug reports
we may look into the problems and fix them.

According to FAST_ZPP part, the commit message and comments in the code
clearly say that this part may be changed in the future.
We should vote for it separately and then change or remove it according to
agreement.

Thanks. Dmitry.




> 
> > […]
> a
> > […]
> it's
> > […]
> on
> > […]
> course
> > […]
>
> I have temporarily re-enabled the phpng jobs on my CI server to assess
> the current situation.
>
> I can confirm that just one test is failing with PHPUnit master. It
> seems that print_r is not displaying StdClass properties as it used to:
>
>
> https://revive.beccati.com/bamboo/browse/PHP-PHPUN-PHPNG-55/test/case/11800493
>
>
> On the other hand Doctrine master can't even run the entire test suite
> due to:
>
> Fatal error: Call to a member function getConfiguration() on null in
>
> /home/atlassian/bamboo/xml-data/build-dir/PHP-DOCTR-PHPNG/tests/Doctrine/Tests/OrmFunctionalTestCase.php
> on line 482
>
> (pretty sure it's not a null there: a var_dump before the call tells me
> it's an object)
>
> https://revive.beccati.com/bamboo/browse/PHP-DOCTR-PHPNG-52/log
>
>
> The Revive Adserver test suite fails miserably (86+ out of 274 test
> files), mostly due to errors like:
>
>
> /home/atlassian/bamboo/xml-data/build-dir/PHP-SRC3-BUIL/Zend/zend_hash.c(1369)
> : ht=0x29c7aa8 is already destroyed
>
> and some "Call to a member function" errors on object variables that are
> mysteriously seen as null.
>
> https://revive.beccati.com/bamboo/browse/REV-LP-PNGP-64
>
> There's lots of legacy code in there and it has proved to be useful in
> past to catch a few uncommon segmentation faults. I'm pretty sure that
> there are plenty other applications that can't work with phpng as it is
> now.
>
> To be honest I don't think we're anywhere near the point where it's safe
> to merge phpng to master.
>
> Also, one thing that might have been overlooked is that merging phpng to
> master would completely bypass the voting phase on
> https://wiki.php.net/rfc/fast_zpp
>
>
> Cheers
> --
> Matteo Beccati
>
> Development & Consulting - http://www.beccati.com/

---

Next page: https://externals.io/message/75741.md?page=2