[PHP-DEV] RFC: Move phpng to master
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
Re: [PHP-DEV] [VOTE][RFC] Name of Next Release of PHP
See below in red. > It was not accidental and I said so almost immediately after Andrea sent > the note to the list about the paragraphs being removed. > I didn't see that, my bad. The point I was trying to make is that, whatever the explanation, I think you should be given the benefit of the doubt as far as your intentions were concerned. > Now, if you move away from your biased point of view, perhaps you’d notice > some issues elsewhere too: > I am biased in favor of PHP 6, just as you're biased in favor of PHP 7. However, I've done my best to be fair without allowing that bias to affect that. That's why, for example, I urged Andrea to give you access to the RFC so you could expand the section in favor of PHP 7. It's also why I urged her to grant the delay you requested. Please believe me, I would have been just as troubled if Andrea or someone else had gutted the section in support of your argument. > 1. The vote started with no real case for PHP 7 in there. I made > it clear in past weeks I intended to write one, and said it would take > time. The supposed ‘case for PHP 7’ that was added there by PHP 6 > proponents, is now turning out to be a further case for PHP 6. > Agreed. You should have been the one to write that section. Ultimately, you were. I haven't been following this very closely (though I am now). If I'd known when it came to a vote that you still hadn't had a chance to write your section, I would have asked that the vote be cancelled to give you more time. > 2. When I asked the vote to be canceled, it was rejected – even > though 20 people voted on a 100.0% one sided RFC before I put in a real > case for 7. Let’s say it was wrong for me to edit these two paragraphs > into a real case for 7 – why was it suddenly appropriate to cancel the vote > immediately? How is it different from the situation on the ground when the > RFC went for a vote with a one sided 6 position? > You're right that the vote should've been cancelled-- or, more to the point, it never should've been initiated in the first place. I still don't like how you gutted the 6 paragraph. However, I'm also not happy that the vote was called before you'd had a chance to finish your section of the RFC. I don't think that either one justifies the other. They were both mistakes that we should learn from. And again, if I'd been paying closer attention and realized you hadn't completed your section yet, I would've been just as critical of Andrea for starting the vote before the RFC was ready. I can understand her eagerness to settle this issue and we certainly wouldn't want to have the vote delayed for months over this, but there was no need for it to be rushed like this. I don't think there would've been any harm in giving you an extra few weeks to get your section written, especially considering what you're dealing with over there right now with those missiles. > 3. Fact it that when the vote was canceled, it was 25/15 in favor > of 7 and with 7 gaining rapidly (it was 7 to 13 ~12hrs earlier). Another > fact is that even once these paragraphs were restored, Andrea didn’t feel > they were doing a good job representing the case for 6. > The entire vote was tainted. It was first tainted by your section not being completed and further tainted by Andrea's section being gutted. At that point, I don't care what the results were; it had to be cancelled. > On my side, I don’t feel I did **anything** wrong. > I think you did, though it's now clear there's more than enough blame to go around here. Andrea shouldn't have rushed the vote and I wasn't paying close enough attention to realize you hadn't finished your section when the voting started. We all have our reasons and explanations, but that doesn't make it right. It's important to learn from our mistakes in times like these so that we don't repeat them in the future. I asked for an extended discussion time which would have immediately turn > out the missing paragraphs had people thought they were in fact necessary > for the PHP 6 case; > And you should have been given that time. I agree with you 100% on that. > And, last but absolutely not least, I’m fine with Andrea canceling the > vote, as my goal from the get go (weeks ago) was that the best case would > be made for 6, the best case would be made for 7, and people will vote > accordingly. > >From this moment on, let's agree that anyone who supports PHP 6 should keep their hands off of the PHP 7 section and anyone who supports PHP 7 should keep their hands off of the PHP 6 section. That way, each side will be responsible for making its best arguments without interference. When everyone is satisfied with the draft, *then* the vote can be initiated. If you and Andrea could agree to that, I think we'll be able to avoid any further drama. > > > Given Zeev's current situation, I think we should grant his request for a > delay in voting, especially since we had to start over, anyw
Re: [PHP-DEV] RFC: Move phpng to master
hi Zeev, On Mon, Jul 21, 2014 at 9:31 AM, Zeev Suraski wrote: > 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE][RFC] Name of Next Release of PHP
On 21/07/14 08:41, Kris Craig wrote: >> 1. The vote started with no real case for PHP 7 in there. I made >> > it clear in past weeks I intended to write one, and said it would take >> > time. The supposed ‘case for PHP 7’ that was added there by PHP 6 >> > proponents, is now turning out to be a further case for PHP 6. >> > > Agreed. You should have been the one to write that section. Ultimately, > you were. I haven't been following this very closely (though I am now). > If I'd known when it came to a vote that you still hadn't had a chance to > write your section, I would have asked that the vote be cancelled to give > you more time. Since the ORIGINAL RFC was for 'PHP6' or 'Not PHP6' without any particular proposed alternative it was basically already floored. Many of the reasons for not using PHP6 were all about breaking the versioning system. Currently the debate has changed and the question left is a simple one. Did PHP6 ever exist as a version? Since even the case for using PHP6 states the fact that PHP6 was abandoned in 2010 it does acknowledge that PHP6 has already been used as a version, so weakens it's own case. Removing that statement now would be inappropriate? So the discussion is not so much PHP6 or PHP7, but rather do we reopen the PHP6 branch again ... or honour the previous closing of that branch. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Move phpng to master
On Mon, Jul 21, 2014 at 9:52 AM, Pierre Joye wrote: > hi Zeev, > > On Mon, Jul 21, 2014 at 9:31 AM, Zeev Suraski wrote: >> 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 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] RFC: Move phpng to master
> 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] php interactive shell: save history on SIGINT exit
Php interactive shell saves commands history when you exit it using 'quit'. But it throws all you history away when you exit using Ctrl+C. It is common practice to save history on SIGINT exit (mysql, mongo, etc.) I would like to implement SIGINT handler for interactive shell to save history on Ctrl+C exit. Threre is request on bugs.php.net for this feature https://bugs.php.net/bug.php?id=67496. I have created pull request https://github.com/php/php-src/pull/727 but was advised to create RFC to discuss this change. So could you provide some feedback. Kind regards, Dmitry Saprykin
Re: [PHP-DEV] RFC: Move phpng to master
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 :-) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE][RFC] Name of Next Release of PHP
On Mon, Jul 21, 2014 at 7:56 AM, Zeev Suraski wrote: > The removed paragraphs were actually the RFC’s ‘case for PHP 7’. As the > champion for the PHP 7 case, I was 100.0% entitled to remove it as I > thought it wasn’t doing a good job at presenting that case, and replace it > with some real pro-7 content. > The original RFC had only one section where the advantages and disadvantages of PHP 6 vs PHP 7 were outlined in a back-and-forth discussion. Arguments for PHP 6 and PHP 7 were mixed. When you created the separate section for PHP 7, you removed some of those mixed paragraphs and added the pro-7 arguments to the new section. The pro-6 arguments however were simply dropped. That is what I was referring to in my mail. An example of text that was simply removed from the RFC: > Another point that has been made is that due to online reviews, it would quickly become clear that these old "PHP 6" books do not cover the new PHP 6; people would likely try them, find the code in the book did not work, and rate the book "1 star", deterring other customers. Furthermore, the PHP community would likely try to dissuade people from buying these old "PHP 6" books. Some also question how many of the old "PHP 6" books are still in print, for that matter. To me this sounds quite clearly like an argument being made in favor of PHP 6 and it was dropped during your revisions. I'm not saying that you did this on purpose, quite likely you just dropped some PHP 7 related paragraphs without looking at them too closely, but the result is the same: An RFC that is very biased towards one side. I am also not denying that the RFC before your changes was biased to the other side. I think we all agree that this vote was somewhat rushed ;) Nikita
Re: [PHP-DEV] RFC: Move phpng to master
On 21/07/2014, Zeev Suraski wrote: > 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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE][RFC] Name of Next Release of PHP
On 20 Jul 2014 23:32, "Andrea Faulds" wrote: > > > On 20 Jul 2014, at 22:28, Nikita Popov wrote: > > > After the vote has been started the RFC was edited by Zeev in order to strengthen the case for PHP 7. There is nothing wrong with that, adding additional arguments to an RFC is perfectly fine by me. > > > > However at the same time a number of paragraphs were removed that were arguing for PHP 6, at least in part. The only thing that was left in "The case for PHP 6" was a single paragraph, of which half was really just an explanation of the general situation. > > > > Effectively the edits made the RFC text heavily biased. It's okay to edit an RFC to add arguments for your side, but I find it discourteous and disingenuous to remove arguments from the opposing side at the same time. > > > > As such I can understand Andrea's decision to close this vote until tempers had time to cool down and both sides had a chance to be fairly represented. > > It also wasn’t really fair of me to start a vote when there wasn’t really a case for 7, now that I think about it. I suppose that makes my later decision hypocritical, but it does mean we’re in a better place now when we have a second vote, as we have two cases. To sum it up: 6 would be the logical number for the next major version, that's just a fact. I would go with it. But I and probably most others who would go with 6 wouldn't really be hurt if we went with 7. On the other hand there would be quite some people hurt if we went with 6. So, maybe it's just me, but there seems to only be a "case" for 7. Let's think about the people, not only numbers and facts. We often forget about that when "just" answering mails. Cheers, Mike
Re: [PHP-DEV] php interactive shell: save history on SIGINT exit
Hi all, On Mon, Jul 21, 2014 at 6:12 PM, Dmitry Saprykin wrote: > Php interactive shell saves commands history when you exit it using 'quit'. > But it throws all you history away when you exit using Ctrl+C. It is common > practice to save history on SIGINT exit (mysql, mongo, etc.) > > I would like to implement SIGINT handler for interactive shell to save > history on Ctrl+C exit. > > Threre is request on bugs.php.net for this feature > https://bugs.php.net/bug.php?id=67496. > I have created pull request https://github.com/php/php-src/pull/727 but > was advised to create RFC to discuss this change. > > So could you provide some feedback. > Isn't it nicer to treat this kind of change as simple bug fix/feature implementation? It's common behavior and there is no compatibility issue at all. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] RFC: Move phpng to master
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 > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
Re: [PHP-DEV] RFC: Move phpng to master
Hi Zeev, On Mon, Jul 21, 2014 at 4:31 PM, Zeev Suraski wrote: > 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 yohg...@ohgaki.net
Re: [PHP-DEV] RFC: Move phpng to master
On 21 Jul 2014 10:21, "Julien Pauli" wrote: > > On Mon, Jul 21, 2014 at 9:52 AM, Pierre Joye wrote: > > hi Zeev, > > > > On Mon, Jul 21, 2014 at 9:31 AM, Zeev Suraski wrote: > >> 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 > > 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.
Re: [PHP-DEV] crypt() BC issue
Hi all,
On Mon, Jul 21, 2014 at 3:17 PM, Yasuo Ohgaki wrote:
> In old days, crypt() was unusable securely. There are many
> users/developers that
> are used to have static slat. Code like below disables authentication
> completely.
>
> password_hash(hash('sha512', SOME_SECRET_SALT).$password, DEFAULT);
>
> This should be prevented. (I would like to prevent it by raising E_NOTICE
> error)
>
E_NOTICE for password larger than 72 is mandatory. Current password_hash()
works without any sign of problem even if it may not be working as
authentication.
I'll add E_NOTICE as bug fix if there aren't any more comments.
If we would like to recommend "Just use it", we may consider adding SHA512
> to password_hash().
>
This one needs RFC, but I'm OK with prehashing in userland.
Please write RFC and implement it if you are willing to have this.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
Re: [PHP-DEV] php interactive shell: save history on SIGINT exit
On 21 Jul 2014 11:24, "Yasuo Ohgaki" wrote: > > Hi all, > > On Mon, Jul 21, 2014 at 6:12 PM, Dmitry Saprykin < saprykin.dmi...@gmail.com> > wrote: > > > Php interactive shell saves commands history when you exit it using 'quit'. > > But it throws all you history away when you exit using Ctrl+C. It is common > > practice to save history on SIGINT exit (mysql, mongo, etc.) > > > > I would like to implement SIGINT handler for interactive shell to save > > history on Ctrl+C exit. > > > > Threre is request on bugs.php.net for this feature > > https://bugs.php.net/bug.php?id=67496. > > I have created pull request https://github.com/php/php-src/pull/727 but > > was advised to create RFC to discuss this change. > > > > So could you provide some feedback. > > > > Isn't it nicer to treat this kind of change as simple bug fix/feature > implementation? > It's common behavior and there is no compatibility issue at all. > Yes, please do NOT create a RFC for each and every tiny feature. Just find someone to review and eventually merge your patch!
Re: [PHP-DEV] php interactive shell: save history on SIGINT exit
Ok, I will NOT )) God saves us from bureaucracy On 21 July 2014 13:46, Michael Wallner wrote: > > On 21 Jul 2014 11:24, "Yasuo Ohgaki" wrote: > > > > Hi all, > > > > On Mon, Jul 21, 2014 at 6:12 PM, Dmitry Saprykin < > saprykin.dmi...@gmail.com> > > wrote: > > > > > Php interactive shell saves commands history when you exit it using > 'quit'. > > > But it throws all you history away when you exit using Ctrl+C. It is > common > > > practice to save history on SIGINT exit (mysql, mongo, etc.) > > > > > > I would like to implement SIGINT handler for interactive shell to save > > > history on Ctrl+C exit. > > > > > > Threre is request on bugs.php.net for this feature > > > https://bugs.php.net/bug.php?id=67496. > > > I have created pull request https://github.com/php/php-src/pull/727 > but > > > was advised to create RFC to discuss this change. > > > > > > So could you provide some feedback. > > > > > > > Isn't it nicer to treat this kind of change as simple bug fix/feature > > implementation? > > It's common behavior and there is no compatibility issue at all. > > > > Yes, please do NOT create a RFC for each and every tiny feature. Just find > someone to review and eventually merge your patch! >
Re: [PHP-DEV] RFC: Move phpng to master
On Mon, 21 Jul 2014, Zeev Suraski wrote: > 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Move phpng to master
On 21/07/2014 11:13, Sebastian Bergmann wrote: > 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 :-) 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/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] RFC: Move phpng to master
> -Original Message- > From: Matteo Beccati [mailto:p...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] RFC: Move phpng to master
*From:* yohg...@gmail.com [mailto:yohg...@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, On Mon, Jul 21, 2014 at 4:31 PM, Zeev Suraski wrote: 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
Re: [PHP-DEV] RFC: Move phpng to master
On Mon, Jul 21, 2014 at 10:33 AM, Zeev Suraski wrote: > 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. >> 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. 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Move phpng to master
On Mon, Jul 21, 2014 at 11:37 AM, Michael Wallner wrote: > > 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Move phpng to master
On Mon, Jul 21, 2014 at 12:18 PM, Zeev Suraski wrote: > *From:* yohg...@gmail.com [mailto:yohg...@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, > > > > On Mon, Jul 21, 2014 at 4:31 PM, Zeev Suraski wrote: > > 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
Re: [PHP-DEV] RFC: Move phpng to master
Hi Zeev, On Mon, Jul 21, 2014 at 12:16 PM, Zeev Suraski wrote: > > -Original Message- > > From: Matteo Beccati [mailto:p...@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 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/
Re: [PHP-DEV] RFC: Move phpng to master
On Mon, Jul 21, 2014 at 11:27 AM, Dmitry Stogov wrote: > 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. 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. > >> >> 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 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] RFC: Move phpng to 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. 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
Re: [PHP-DEV] RFC: Move phpng to master
On Mon, Jul 21, 2014 at 12:24 PM, Ferenc Kovacs wrote: > > 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] RFC: Move phpng to master
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
Re: [PHP-DEV] RFC: Move phpng to master
On Mon, Jul 21, 2014 at 12:30 PM, Zeev Suraski wrote: > > 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/
Re: [PHP-DEV] RFC: Move phpng to master
On Mon, 21 Jul 2014, Dmitry Stogov wrote: > > 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. 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Move phpng to master
On Mon, Jul 21, 2014 at 12:31 PM, Zeev Suraski wrote: > 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Move phpng to master
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. On Mon, Jul 21, 2014 at 2:07 PM, Matteo Beccati wrote: > On 21/07/2014 11:13, Sebastian Bergmann wrote: > > 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 :-) > > 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/ > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
Re: [PHP-DEV] RFC: Move phpng to master
On Mon, Jul 21, 2014 at 12:41 PM, Derick Rethans wrote: > On Mon, 21 Jul 2014, Dmitry Stogov wrote: > >> > 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. > > 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. Review and changes in the feature(s) branch, then propose when ready. This is also why I asked to do so in the 1st days when phpng was proposed: Stop adding new changes, cleanup, stabilize, propose, continue the work. They refused it and now we should do it in the most ugly way? Merging into master or even worst replace master with something we have no idea about? Seriously? -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Move phpng to master
On Mon, Jul 21, 2014 at 12:41 PM, Dmitry Stogov wrote: > 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. According to what happened in recent RFCs, rejected because a tiny part of the patch did not represent what is actually proposed, removing parts must be done before voting then, proposed as separated RFCs, at the same time or later. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Move phpng to master
On Mon, Jul 21, 2014 at 2:24 PM, Julien Pauli wrote: > On Mon, Jul 21, 2014 at 11:27 AM, Dmitry Stogov wrote: > > 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. > > 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. > 1-2% is not a huge step back :) but in case of few such steps we may discard a lot. > > > > >> > >> 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 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 > We thought about it many time, but didn't have time to do it. Thanks. Dmitry. > > Julien >
Re: [PHP-DEV] php interactive shell: save history on SIGINT exit
On Mon, Jul 21, 2014 at 11:50 AM, Dmitry Saprykin wrote: > Ok, I will NOT )) > God saves us from bureaucracy Well, Michael's view is known. However let me explain what RFCs bring, besides bureaucracy. - clear identification of use cases, incl. edge cases - better design and design reviews - documentation, ready to be used by the doc team I do not know how big such changes will be but I can already see a couple of things that may require more than "works for me on my fav linux distros" edge cases. :) >> Yes, please do NOT create a RFC for each and every tiny feature. Just find >> someone to review and eventually merge your patch! >> -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Move phpng to master
On Mon, Jul 21, 2014 at 12:50 PM, Dmitry Stogov wrote: > We thought about it many time, but didn't have time to do it. cleanup makes code bases smaller, more maintainable, easier to change. The time spent to port dead parts of PHP should have been better spent. It is too late to do that :) -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Move phpng to master
On Mon, Jul 21, 2014 at 12:31 PM, Zeev Suraski wrote: > > > 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 > > > because there is so much stuff which we want to do in the next major version, but we can't even start because there is no stable base to target the other php-next features. based on the history of php versions, any feature which misses php-next will have to wait for the next decade, so I don't think that we should rush it (to meet our yearly release cycle defined in https://wiki.php.net/rfc/releaseprocess). -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] RFC: Move phpng to master
On Mon, Jul 21, 2014 at 9:31 AM, Zeev Suraski wrote: > 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 > There are actually two questions here: 1. Do we want to base the next major version on phpng? 2. Do we want to merge phpng into master? The latter is tied to the question whether or not we want to have a PHP 5.7 release in the meantime. I'm not really sure whether or not that would be good, I would recommend opening a separate thread about that question. Regarding the first question, I fully support basing the next major on phpng. Several people in this thread have raised concerns regarding the quality of phpng's API. As someone who has ported a number of extensions to be compatible with phpng and is currently in the process of writing a >10kloc patch based on phpng, I can without any doubt say that the new APIs are a good bit more friendly to internals developers. Some of the reasons why that is so: * The removal of one level of zval indirection in many places, as well as the need to allocate zvals. * Changing the zend_hash APIs to directly return zvals/pointers and generally integrate better with zvals. * Changing the zend_hash APIs to handle lengths like everything else does. * The introduction of zend_string. >From my perspective phpng's APIs are an improvement over the current state, however there is still a lot of room for improvement. E.g. there is still a huge number of macros, which should probably be moved to inline functions, etc. I don't think anyone has a problem with doing these kinds of improvements, but I don't think they are really relevant to the question at hand (as these cleanups can happen regardless of which branch is used as the basis). I'd also love it if we could drop TSRMLS_* - iirc joe has a partial patch for better TLS handling, which couldn't be used previously due to concerns over internal API breaks. For a new majors those concerns shouldn't be a problem anymore :) Regarding the stability of the phpng branch: phpng definitely still contains bugs (which is quite obvious given the amount of code it changes) and I'm aware that it currently fails with many large testsuites. Obviously this will have to be resolved by the time we get anywhere close to a release. However we cannot wait until all bugs have been fixed before continuing other development for php next. We need a basis for php next and we need it now, so people know what they should develop against. This way stabilization of phpng will happen in parallel to other changes. Nikita
Re: [PHP-DEV] RFC: Move phpng to master
On Mon, Jul 21, 2014 at 1:01 PM, Ferenc Kovacs wrote: > On Mon, Jul 21, 2014 at 12:31 PM, Zeev Suraski wrote: > >> >> >> 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 >> >> >> > > because there is so much stuff which we want to do in the next major > version, but we can't even start because there is no stable base to target > the other php-next features. > based on the history of php versions, any feature which misses php-next > will have to wait for the next decade, so I don't think that we should rush > it (to meet our yearly release cycle defined in > https://wiki.php.net/rfc/releaseprocess). Exactly. And https://wiki.php.net/ideas/php6 and the related discussions (where @Zend and phpng's team were totally absent, go figure). -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Move phpng to master
On Mon, Jul 21, 2014 at 1:10 PM, Nikita Popov wrote: > On Mon, Jul 21, 2014 at 9:31 AM, Zeev Suraski wrote: > > > 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 > > > > There are actually two questions here: > 1. Do we want to base the next major version on phpng? > 2. Do we want to merge phpng into master? > > The latter is tied to the question whether or not we want to have a PHP 5.7 > release in the meantime. I'm not really sure whether or not that would be > good, I would recommend opening a separate thread about that question. > either way, master should/will contain the changes from phpng, otherwise we would go against to our current merge everything upwards git workflow. but that doesn't really a problem for 5.7, we should just branch it from 5.6 (we wanted to do this for 5.6 and 5.5, but most of the changes in master at that time was ok for a minor, so we branches from master instead of cherrypicking everything.), as anything we want to backport from master to 5.7 would require manual work to make it compatible with 5.7. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] RFC: Move phpng to master
On Mon, Jul 21, 2014 at 1:10 PM, Nikita Popov wrote: > There are actually two questions here: > 1. Do we want to base the next major version on phpng? > 2. Do we want to merge phpng into master? As of now, I am against both. But as I said earlier I am open as long as the minimal requirements are met for an informed review and proposal. > The latter is tied to the question whether or not we want to have a PHP 5.7 > release in the meantime. I'm not really sure whether or not that would be > good, I would recommend opening a separate thread about that question. In the discussions about the actual roadmap for php-next, we discussed the idea of using 5.6 as base for 5.x. It leaves the door open for 5.7 and 5.8, as perfectly valid options given my slightly more realistic time plan (2-3 years instead of 10 months). Master can then be phpnext. > Regarding the first question, I fully support basing the next major on > phpng. Several people in this thread have raised concerns regarding the > quality of phpng's API. As someone who has ported a number of extensions to > be compatible with phpng and is currently in the process of writing a >>10kloc patch based on phpng, I can without any doubt say that the new APIs > are a good bit more friendly to internals developers. Some of the reasons > why that is so: I used it, reviewed it (minus the additions done in the last couple of weeks) and I disagree. The APIs are more confusing, dangerous and far less consistent. Let alone the addition of countless macros, I doubt most of them are needed. ZPP is another one but Dmitry's last post say that it will be a separate RFC (hopefully). > From my perspective phpng's APIs are an improvement over the current state, > however there is still a lot of room for improvement. E.g. there is still a > huge number of macros, which should probably be moved to inline functions, > etc. I don't think anyone has a problem with doing these kinds of > improvements, but I don't think they are really relevant to the question at > hand (as these cleanups can happen regardless of which branch is used as > the basis). It is, as it was for all the past RFCs, and to quote you: "I vote on what I see". > I'd also love it if we could drop TSRMLS_* - iirc joe has a > partial patch for better TLS handling, which couldn't be used previously > due to concerns over internal API breaks. For a new majors those concerns > shouldn't be a problem anymore :) Yes, TLS is definitively something I like to see in next. > Regarding the stability of the phpng branch: phpng definitely still > contains bugs (which is quite obvious given the amount of code it changes) > and I'm aware that it currently fails with many large testsuites. Obviously > this will have to be resolved by the time we get anywhere close to a > release. We stopped testing it a couple of weeks as it was impossible to actually do it. It was a fast moving target until 2 weeks ago. > However we cannot wait until all bugs have been fixed before continuing > other development for php next. We did not wait phpng to do so. But for you, phpng was the prioritiy for the last months. And now you are telling us that you cannot wait to continue the developments? After having literally blocked us for months? Seriously, no. Now is the time to do one step back, look at the global picture and re start the discussions we began about next. And I serioulsly hope you guys will participate. > We need a basis for php next and we need it > now, so people know what they should develop against. This way > stabilization of phpng will happen in parallel to other changes. We have one, it is called master. We have one with one cleanup being done already already, it is the 64bit branch. We can have even more, and in a much more stable state as phpng will ever be in the next 6 months. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Use of php_mt_rand() rather than php_rand()
Hi Yasuo,
Some times ago I mailed my idea about refactoring random number
generator API with min BC breaks but I didn't create an RFC right now.
see http://marc.info/?l=php-internals&m=137772363015217
Marc
On 16.07.2014 07:13, Yasuo Ohgaki wrote:
Hi all,
There are few places that uses php_rand() currently.
https://bugs.php.net/bug.php?id=66718
http://lxr.php.net/search?q=php_rand&defs=&refs=&path=&hist=&project=PHP_5_5
These functions could use php_mt_rand() instead of php_rand().
php_rand() uses several rand functions
62PHPAPI long php_rand(TSRMLS_D)
63{
64long ret;
65
66if (!BG(rand_is_seeded)) {
67php_srand(GENERATE_SEED() TSRMLS_CC);
68}
69
70#ifdef ZTS
71ret = php_rand_r(&BG(rand_seed));
72#else
73# if defined(HAVE_RANDOM)
74ret = random();
75# elif defined(HAVE_LRAND48)
76ret = lrand48();
77# else
78ret = rand();
79# endif
80#endif
81
82return ret;
83}
Most systems use random() which has cycle of 16 * ((2^31) - 1),
while MT rand has 2^19937-1.
php_mt_rand() could be used where php_rand() is used. Unlike php_rand(),
php_mt_rand() does not check if it is seeded or not. It should be changed
to check seed status.
The only BC issue I can think of is game that expects the same pseudo
random sequences. These apps may use mt_srand() to get fixed random
sequences and adjust their apps if it is needed. This is acceptable BC
for new releases. IMO.
It would be good idea to support 64bit version of MT on 64bit platforms,
too.
http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/emt64.html
Any comments?
--
Yasuo Ohgaki
yohg...@ohgaki.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Move phpng to master
On 21 ביול 2014, at 14:20, Ferenc Kovacs wrote: > On Mon, Jul 21, 2014 at 1:10 PM, Nikita Popov wrote: > On Mon, Jul 21, 2014 at 9:31 AM, Zeev Suraski wrote: > > > 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 > > > > There are actually two questions here: > 1. Do we want to base the next major version on phpng? > 2. Do we want to merge phpng into master? > > The latter is tied to the question whether or not we want to have a PHP 5.7 > release in the meantime. I'm not really sure whether or not that would be > good, I would recommend opening a separate thread about that question. > > either way, master should/will contain the changes from phpng, otherwise we > would go against to our current merge everything upwards git workflow. Agreed. > but that doesn't really a problem for 5.7, we should just branch it from 5.6 > (we wanted to do this for 5.6 and 5.5, but most of the changes in master at > that time was ok for a minor, so we branches from master instead of > cherrypicking everything.), as anything we want to backport from master to > 5.7 would require manual work to make it compatible with 5.7. Agreed too - I just think we should first focus on getting .NEXT released as soon as possible - and only branch away a 5.7 if we see it's taking too long. It's not a decision we need to take today, but if we were to do it, branching it from 5.6 sounds like the right way to do it. Zeev
Re: [PHP-DEV] php interactive shell: save history on SIGINT exit
Am 21.7.2014 um 12:52 schrieb Pierre Joye : > On Mon, Jul 21, 2014 at 11:50 AM, Dmitry Saprykin > wrote: >> Ok, I will NOT )) >> God saves us from bureaucracy > > Well, Michael's view is known. > > However let me explain what RFCs bring, besides bureaucracy. > > - clear identification of use cases, incl. edge cases > - better design and design reviews > - documentation, ready to be used by the doc team > > I do not know how big such changes will be but I can already see a > couple of things that may require more than "works for me on my fav > linux distros" edge cases. :) > >>> Yes, please do NOT create a RFC for each and every tiny feature. Just find >>> someone to review and eventually merge your patch! > > -- > Pierre > > @pierrejoye | http://www.libgd.org - Here the use case is very obvious, I don't see what a RFC would make clearer here. - That it was posted to the mailing list should usually attract enough attention to quickly review such a small patch. - Here nothing needs to be documented. People just should feel free to post it on the mailing list; if it gets controversial, then, why not, create a RFC. Bob
Re: [PHP-DEV] RFC: Move phpng to master
On 21 Jul 2014, at 12:10, Nikita Popov wrote: > The latter is tied to the question whether or not we want to have a PHP 5.7 > release in the meantime. I'm not really sure whether or not that would be > good, I would recommend opening a separate thread about that question. The way I see it, we should branch master to a new PHP-5.7 branch, and then merge phpng into master. I think we should have a PHP 5.7. There are plenty of things we can still do in the 5.x series and it would be better to get them into PHP next year with 5.7 rather than in two or three years with NEXT. On the other hand, keeping all the new features for PHP NEXT only provides more of an incentive to upgrade to 6. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] RFC: Move phpng to master
> -Original Message- > From: Andrea Faulds [mailto:a...@ajf.me] > Sent: Monday, July 21, 2014 3:55 PM > To: Nikita Popov > Cc: Zeev Suraski; PHP internals > Subject: Re: [PHP-DEV] RFC: Move phpng to master > > > I think we should have a PHP 5.7. There are plenty of things we can still do in > the 5.x series and it would be better to get them into PHP next year with 5.7 > rather than in two or three years with NEXT. I'm not sure where the 2-3 years is coming from, but again, I see no reason why we wouldn't be able to push .NEXT out within a year (if it's just phpng along then actually a lot less, but I'm allowing time for extra features we may want to put in). As a matter of fact, I don't think we can even entertain a 2-3 cycle, it will be way too late to market if we linger for so long. This is the assumption we should take IMHO, and only branch 5.7 (and more importantly, invest time in it) if it proves wrong. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php interactive shell: save history on SIGINT exit
Thank you for clarification. I'm agree with all points. But I think in this particular case (1 file, <20 lines of code) simple review could be enough. I'm new in php development and may be I am missing some workflow steps. If RFC is absolutely necessary I will be happy to create it but I have no enough wiki karma. On 21 July 2014 14:52, Pierre Joye wrote: > On Mon, Jul 21, 2014 at 11:50 AM, Dmitry Saprykin > wrote: > > Ok, I will NOT )) > > God saves us from bureaucracy > > Well, Michael's view is known. > > However let me explain what RFCs bring, besides bureaucracy. > > - clear identification of use cases, incl. edge cases > - better design and design reviews > - documentation, ready to be used by the doc team > > I do not know how big such changes will be but I can already see a > couple of things that may require more than "works for me on my fav > linux distros" edge cases. :) > > >> Yes, please do NOT create a RFC for each and every tiny feature. Just > find > >> someone to review and eventually merge your patch! > >> > > > > -- > Pierre > > @pierrejoye | http://www.libgd.org >
Re: [PHP-DEV] RFC: Move phpng to master
On 21 Jul 2014, at 14:06, Zeev Suraski wrote: > I'm not sure where the 2-3 years is coming from, but again, I see no > reason why we wouldn't be able to push .NEXT out within a year (if it's > just phpng along then actually a lot less, but I'm allowing time for extra > features we may want to put in). As a matter of fact, I don't think we > can even entertain a 2-3 cycle, it will be way too late to market if we > linger for so long. We *could* make PHP NEXT in a year, sure, but it won’t be worthwhile being called PHP NEXT. There are a lot of big changes we can and should make and that would necessitate delaying it. Three years might be a bit long. However, I am confident that we need more than a year to make this major worth it. > This is the assumption we should take IMHO, and only branch 5.7 (and more > importantly, invest time in it) if it proves wrong. Branching 5.7 wouldn’t be a big effort. Master is fairly stable, and if some RFCs pass, we can merge them into 5.7. It also gives us a fallback. If PHP NEXT doesn’t happen next year (and I expect that it won’t), we’ll still have 5.7. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Move phpng to master
On Mon, Jul 21, 2014 at 3:06 PM, Zeev Suraski wrote: > I'm not sure where the 2-3 years is coming from, but again, I see no > reason why we wouldn't be able to push .NEXT out within a year (if it's > just phpng along then actually a lot less, but I'm allowing time for extra > features we may want to put in). As a matter of fact, I don't think we > can even entertain a 2-3 cycle, it will be way too late to market if we > linger for so long. > > This is the assumption we should take IMHO, and only branch 5.7 (and more > importantly, invest time in it) if it proves wrong. This is the assumption we should not take. It is disturbing to see you pushing again something so hard that it will hurt the whole project. And this time much harder than in the last times. It is time to step back and take a realistic view of what is going, outside your book, which is barely based on your one and only prioritiy, performance (and only one platform too). This is not PHP, not what many want. And even I am pretty sure you will make it through with this totally incomplete RFC based on disputable benchmarks and no matter how much performance improvements happen with phpng, this is not the only thing what we should do in next. Even if it was, to think about being ready in less than a year is a sweet dream, to say it nicely. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] RFC: Move phpng to master
> -Original Message- > From: Andrea Faulds [mailto:a...@ajf.me] > Sent: Monday, July 21, 2014 4:10 PM > To: Zeev Suraski > Cc: Nikita Popov; PHP internals > Subject: Re: [PHP-DEV] RFC: Move phpng to master > > > We *could* make PHP NEXT in a year, sure, but it won't be worthwhile being > called PHP NEXT. Everything I know about the PHP community, combined with the amazing level of interest that the recent PHPNG benchmarks garnered, tells me that it wrong. People would love to get it even if it was just the performance & memory footprint gains alone. And we're not even talking about that - we'd still have ample time to put in additional features into it. > There are a lot of big changes we can and should make and > that would necessitate delaying it. Three years might be a bit long. Three years is a lifetime in our world of software... > However, I > am confident that we need more than a year to make this major worth it. Even if it's going to be 18 months (which is on the upper limit of what I think we should allow for .NEXT), I don't see a need for 5.7 in between. When we created the release process RFC, from the get go, I thought that releasing every 12 months is too frequent. I was told not to worry and that we'll "see how it goes" and "change if we need to". Now, suddenly this became a God-given commandment, that we must have a mini version every year and on time - and it's not. Reality is that the userbase is embracing versions a lot slower than we crank them up - releasing 5.7 to be followed shortly by 6/7 doesn't make a lot of sense, I think. Still, I think we're much better off delivering .NEXT as soon as we can as. > > This is the assumption we should take IMHO, and only branch 5.7 (and > > more importantly, invest time in it) if it proves wrong. > > Branching 5.7 wouldn't be a big effort. Master is fairly stable, and if some RFCs > pass, we can merge them into 5.7. It also gives us a fallback. If PHP NEXT > doesn't happen next year (and I expect that it won't), we'll still have 5.7. I can live with that, as long as we treat 5.7 as a secondary project where we backport stuff rom master, and as long as it's clear to everyone that it may be (or IMHO may very well be) throw-away code that we'll never actually use. Personally I think it makes more sense to focus on getting .NEXT out the door quickly so that we don't have to get into the headache of working on two active trees, though. I'd like to see what others are thinking... Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Move phpng to master
On 21 Jul 2014, at 14:47, Zeev Suraski wrote: > Everything I know about the PHP community, combined with the amazing level > of interest that the recent PHPNG benchmarks garnered, tells me that it > wrong. > People would love to get it even if it was just the performance & memory > footprint gains alone. And we're not even talking about that - we'd still > have ample time to put in additional features into it. Yes, “additional” features. Not big ones. That is my point of contention: if the only major engine-level thing we have time to add is phpng’s performance improvements, I’m not sure it’s worthy of being PHP NEXT. >>> This is the assumption we should take IMHO, and only branch 5.7 (and >>> more importantly, invest time in it) if it proves wrong. >> >> Branching 5.7 wouldn't be a big effort. Master is fairly stable, and if > some RFCs >> pass, we can merge them into 5.7. It also gives us a fallback. If PHP > NEXT >> doesn't happen next year (and I expect that it won't), we'll still have > 5.7. > > I can live with that, as long as we treat 5.7 as a secondary project where > we backport stuff rom master, and as long as it's clear to everyone that > it may be (or IMHO may very well be) throw-away code that we'll never > actually use. Personally I think it makes more sense to focus on getting > .NEXT out the door quickly so that we don't have to get into the headache > of working on two active trees, though. I'd like to see what others are > thinking… Well, I don’t think that, realistically, introducing PHP NEXT will immediately kill the 5.x line. We should have at least one more release after NEXT comes out. That release will probably be 5.7, and who knows, perhaps it might actually come out *after* NEXT. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php interactive shell: save history on SIGINT exit
On Mon, 2014-07-21 at 13:12 +0400, Dmitry Saprykin wrote: > Php interactive shell saves commands history when you exit it using 'quit'. > But it throws all you history away when you exit using Ctrl+C. It is common > practice to save history on SIGINT exit (mysql, mongo, etc.) > > I would like to implement SIGINT handler for interactive shell to save > history on Ctrl+C exit. > > Threre is request on bugs.php.net for this feature > https://bugs.php.net/bug.php?id=67496. > I have created pull request https://github.com/php/php-src/pull/727 but > was advised to create RFC to discuss this change. > > So could you provide some feedback. I think messing with signals is not good - a script might try to catch them, too. What we can do is to save the file each time we execute something. (between the is valid code chack and zend_eval) johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Move phpng to master
On Mon, Jul 21, 2014 at 3:47 PM, Zeev Suraski wrote: d PHP NEXT. > > Everything I know about the PHP community, combined with the amazing level > of interest that the recent PHPNG benchmarks garnered, tells me that it > wrong. You needed one year+ to stabilize opcache, how long will you need for something as huge as phpng? Along with giving the chance to other to actually do what we expect in the next major version? In my book it is more than a year, and between two and three years is a reasonable timeframe. > People would love to get it even if it was just the performance & memory > footprint gains alone. And we're not even talking about that - we'd still > have ample time to put in additional features into it. People tells me something else. But we surely speak to totally different people. >> There are a lot of big changes we can and should make and >> that would necessitate delaying it. Three years might be a bit long. > > Three years is a lifetime in our world of software... Are nothing. > Even if it's going to be 18 months (which is on the upper limit of what I > think we should allow for .NEXT), I don't see a need for 5.7 in between. It is per se defined to have a 5.7 next year. I do not see how it could be remotely possible to have php-next ready by June 2015, except if you release something not ready and did the same that we did before "we will fix/clean that later", which indeed never happened. > When we created the release process RFC, from the get go, I thought that > releasing every 12 months is too frequent. I was told not to worry and > that we'll "see how it goes" and "change if we need to". We can adapt the RFC, not let a company adapts it as they wish as you seems to like to do. > Now, suddenly > this became a God-given commandment, that we must have a mini version > every year and on time - and it's not. Reality is that the userbase is > embracing versions a lot slower than we crank them up - releasing 5.7 to > be followed shortly by 6/7 doesn't make a lot of sense, I think. Adoption of new versions is increasing, drastically, because of the release process RFC. That is what many major big companies using PHP tell me as well as what the numbers I can see tell me. > Still, I think we're much better off delivering .NEXT as soon as we can > as. As soon as we can? Hell yeah. I cannot agree more here. And as soon as we can is not as soon as you wish or as soon as you consider phpng release ready (in theory). >> > This is the assumption we should take IMHO, and only branch 5.7 (and >> > more importantly, invest time in it) if it proves wrong. >> >> Branching 5.7 wouldn't be a big effort. Master is fairly stable, and if > some RFCs >> pass, we can merge them into 5.7. It also gives us a fallback. If PHP > NEXT >> doesn't happen next year (and I expect that it won't), we'll still have > 5.7. > > I can live with that, as long as we treat 5.7 as a secondary project where > we backport stuff rom master, and as long as it's clear to everyone that > it may be (or IMHO may very well be) throw-away code that we'll never > actually use. Personally I think it makes more sense to focus on getting > .NEXT out the door quickly so that we don't have to get into the headache > of working on two active trees, though. I'd like to see what others are > thinking... I have no issue working with many trees, CIs get better every day, testing PRs are now automated, travis support for more platforms is coming, everything coming together to increase php and related projects quality. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Move phpng to master
On 21/07/2014 12:41, Dmitry Stogov wrote: > 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. I've been trying to help with testing and reporting on IRC the results. I think I've mentioned Doctrine a few times already too (on bugs.php.net phpng is missing in the version field). What's the best way to report issues, especially if they show up when running large test suites and it's not possible to create small self-contained snippets? Cheers -- Matteo Beccati Development & Consulting - http://www.beccati.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] RFC: Move phpng to master
On Mon, 21 Jul 2014, Zeev Suraski wrote: > From: Andrea Faulds [mailto:a...@ajf.me] > > > > We *could* make PHP NEXT in a year, sure, but it won't be worthwhile > > being called PHP NEXT. > > Everything I know about the PHP community, combined with the amazing > level of interest that the recent PHPNG benchmarks garnered, tells me > that it wrong. > People would love to get it even if it was just the performance & > memory footprint gains alone. And we're not even talking about that - > we'd still have ample time to put in additional features into it. > > > There are a lot of big changes we can and should make and that would > > necessitate delaying it. Three years might be a bit long. > > Three years is a lifetime in our world of software... > > > However, I am confident that we need more than a year to make this > > major worth it. > > Even if it's going to be 18 months (which is on the upper limit of > what I think we should allow for .NEXT), I don't see a need for 5.7 in > between. When we created the release process RFC, from the get go, I > thought that releasing every 12 months is too frequent. I was told > not to worry and that we'll "see how it goes" and "change if we need > to". Now, suddenly this became a God-given commandment, that we must > have a mini version every year and on time - and it's not. Reality is > that the userbase is embracing versions a lot slower than we crank > them up - releasing 5.7 to be followed shortly by 6/7 doesn't make a > lot of sense, I think. > > Still, I think we're much better off delivering .NEXT as soon as we > can as. I think that's the cru - and very important. I would totally be in favour with PHP 7 be "just" PHPNG - as long of course it's finished. Whether this takes slightly more than a year, I don't really care. > > > This is the assumption we should take IMHO, and only branch 5.7 > > > (and more importantly, invest time in it) if it proves wrong. > > > > Branching 5.7 wouldn't be a big effort. Master is fairly stable, and > > if some RFCs pass, we can merge them into 5.7. It also gives us a > > fallback. If PHP NEXT doesn't happen next year (and I expect that it > > won't), we'll still have 5.7. > > I can live with that, as long as we treat 5.7 as a secondary project > where we backport stuff rom master, and as long as it's clear to > everyone that it may be (or IMHO may very well be) throw-away code > that we'll never actually use. Personally I think it makes more sense > to focus on getting .NEXT out the door quickly so that we don't have > to get into the headache of working on two active trees, though. I'd > like to see what others are thinking... I agree. We should not focus on two active trees. cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php interactive shell: save history on SIGINT exit
changed "write_history" at the end to "append_history" after each cli_is_valid_code. Now it is -1 line, +1 line commit and completely looks like bug fix. ) On 21 July 2014 18:00, Johannes Schlüter wrote: > On Mon, 2014-07-21 at 13:12 +0400, Dmitry Saprykin wrote: > > Php interactive shell saves commands history when you exit it using > 'quit'. > > But it throws all you history away when you exit using Ctrl+C. It is > common > > practice to save history on SIGINT exit (mysql, mongo, etc.) > > > > I would like to implement SIGINT handler for interactive shell to save > > history on Ctrl+C exit. > > > > Threre is request on bugs.php.net for this feature > > https://bugs.php.net/bug.php?id=67496. > > I have created pull request https://github.com/php/php-src/pull/727 but > > was advised to create RFC to discuss this change. > > > > So could you provide some feedback. > > I think messing with signals is not good - a script might try to catch > them, too. What we can do is to save the file each time we execute > something. (between the is valid code chack and zend_eval) > > johannes > > >
Re: [PHP-DEV] RFC: Move phpng to master
On Mon, Jul 21, 2014 at 12:41 PM, Dmitry Stogov wrote: > 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. > Wouldn't it be super easy to use the HHVM team infrastructure to test a version against various PHP projects testsuites? I can't imagine it would take longer than a few hours to adjust this to PHPs needs. > > Thanks. Dmitry. > > > On Mon, Jul 21, 2014 at 2:07 PM, Matteo Beccati wrote: > > > On 21/07/2014 11:13, Sebastian Bergmann wrote: > > > 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 :-) > > > > 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/ > > > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > >
Re: [PHP-DEV] RFC: Move phpng to master
On Mon, Jul 21, 2014 at 4:19 PM, Benjamin Eberlei wrote: > On Mon, Jul 21, 2014 at 12:41 PM, Dmitry Stogov wrote: > >> 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. >> > > Wouldn't it be super easy to use the HHVM team infrastructure to test a > version against various PHP projects testsuites? I can't imagine it would > take longer than a few hours to adjust this to PHPs needs. Exactly, and we do have a good one too. But if nobody reads it or nobody cares, we can add as much CI as we want, that won't change anything. -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] crypt() BC issue
Yasuo,
> E_NOTICE for password larger than 72 is mandatory. Current password_hash()
> works without any sign of problem even if it may not be working as
> authentication.
> I'll add E_NOTICE as bug fix if there aren't any more comments.
Could you please not.
I have asked you to draft an RFC to justify what you intend to do
(documentation, errors, etc) so that we may discuss it better. There
is not a single person in this thread who has said "I think a notice
is a good idea" except you. Yet you insist on just adding it as a "bug
fix". Could you please just slow down, and write out the explanations
so that we can have a meangingful discussion instead of just rushing
through to commit ignoring what everyone is saying?
> However, Using multiple hashes for better security is common technique.
> An example is SSL. So I would not say one should not. Especially when there
> is a limitation.
TLS 1.0 (SSL) used a very specific construction of PRF(secret1,
label + seed) XOR PRF(secret2, label + seed). This is very much
not "using multiple hashes", but using 2 different PRF (pseudo-random
functions) and xoring them together. The end result should be
resistent to cryptoanalysis or attacks that only target one of the
hash functions.
However, TLS 1.2 removed that construction and uses the PRF based on
SHA-256 alone. Why?
As it turns out, it's not based in science at all, and can be proven
faulty. Here's a quick proof:
HASH_FUNC_A - A secure cryptographic hash function (resistent to
collisions, pre-image attacks and 2nd pre-image attacks, ex: SHA-256)
HASH_FUNC_B - Defined as HASH_FUNC_A XOR C (for some arbitrary constant C).
Since HASH_FUNC_A is secure, HASH_FUNC_B is secure as well (since
xoring with an arbitrary constant changes none of its properties).
However, HASH_FUNC_A XOR HASH_FUNC_B will always produce C. Proving
that XOR of two arbitrary hash functions isn't necessarily secure.
More information: http://tuprints.ulb.tu-darmstadt.de/2094/1/thesis.lehmann.pdf
Now, if all you care about is pre-image resistance, then H1(H2(x))
appears to be secure. And if we assume that H1() and H2() are secure
functions, it is.
However, that's a tricky assumption to make. For example, any
collisions in H2() automatically become collisions in H1()
(incidentally, this was the reason PBKDF2 replaced PBKDF1). So that
effectively means that the collision resistance of H1(H2(x)) is at
least as weak as the weakest hash function (potentially weaker). But
we said that all we care about is pre-image resistance, so why does
that matter? Because in the end, we don't just care about pre-image
resistance. We also do care about collision resistance (though to a
lesser degree for password storage). Because with the hash, if an
attacker can generate a collision, they can use that to login to your
system. Yes, that didn't leak the original password (and hence other
systems may be safe), but it did let him compromise you.
In practice, this isn't very likely (as SHA-512 is a strong function
with no known collisions, nor decent attack against it). But in terms
of recommending crypto to the general public, "isn't very likely" is
the wrong way to make recommendations.
> In old days, crypt() was unusable securely. There are many users/developers
> that
No, crypt() was perfectly able to be used securely. The password_hash
apis prove that. Many didn't use it securely, but that didn't mean it
isn't secure.
> are used to have static slat. Code like below disables authentication
> completely.
>
> password_hash(hash('sha512', SOME_SECRET_SALT).$password, DEFAULT);
>
> This should be prevented. (I would like to prevent it by raising E_NOTICE
> error)
And a E_NOTICE will prevent nothing. If you *really* want to prevent
it, raise a warning and return false from the hash function. But
that's not possible without a MASSIVE BC break. Hence why I'm
recommending that you open an RFC on it.
> If we would like to recommend "Just use it", we may consider adding SHA512
> to password_hash().
As I pointed out above, no.
> I wrote
>
> "Use of crypt is deprecated."
>
> not
>
> "crypt() is deprecated". I didn't mean crypt() function deprecation. If it's
> confusing, I don't mind at all to rewrite it.
> BTW, what part is wrong?
"use of crypt is deprecated" is the same as saying "crypt() is
deprecated". That word has very specific and special meaning.
> Adding fixed salt was
> common since crypt() was not good enough used to be. In addition, maximum
> password length
> is not decided by us, but decided by app developers. Therefore, we are
> better to provide/explain
> workaround for password_hash() limitation.
And as I've said before, the way to combat that is with education.
> I'm not closely following doc commit. It seems my commit was modified.
It wasn't modified. It was reverted. That warning that you cite has
existed for 6 months: https://bugs.php.net/bug.php?id=66564
Anthony
--
PHP Internals - PHP Runtime Development Mailing List
Re: [PHP-DEV] RFC: Move phpng to master
Hey： > 在 2014年7月21日，18:56，Pierre Joye 写道： > >> On Mon, Jul 21, 2014 at 12:50 PM, Dmitry Stogov wrote: >> >> We thought about it many time, but didn't have time to do it. > > cleanup makes code bases smaller, more maintainable, easier to change. > The time spent to port dead parts of PHP should have been better > spent. It is too late to do that :) > I don't know what kind of cleanup are you talking? I have spent months to do that, convert exts, cleanup dead codes, refactor ugly hacks If that still not enough, I think we should merge phpng to master ASAP, then people can help me to do such things. Thanks > -- > Pierre > > @pierrejoye | http://www.libgd.org > > -- > 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] RFC: Move phpng to master
Hey: > 在 2014年7月21日，19:02，Ferenc Kovacs 写道： > >> On Mon, Jul 21, 2014 at 12:31 PM, Zeev Suraski wrote: >> >> >> >> 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 > > because there is so much stuff which we want to do in the next major > version, but we can't even start because there is no stable base to target > the other php-next features. What they are? Please come with RFC and Patches. Or you suggest we stop the current work to waiting them come their self? Thanks > based on the history of php versions, any feature which misses php-next > will have to wait for the next decade, so I don't think that we should rush > it (to meet our yearly release cycle defined in > https://wiki.php.net/rfc/releaseprocess). > > -- > Ferenc Kovács > @Tyr43l - http://tyrael.hu -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Move phpng to master
On Mon, Jul 21, 2014 at 5:36 PM, Xinchen Hui wrote: > > > 发自我的 iPad > > 在 2014年7月21日，23:30，Pierre Joye 写道： > > > On Jul 21, 2014 5:28 PM, "Xinchen Hui" wrote: > >> Or you suggest we stop the current work to waiting them come their self? > > This is exactly what you have done. So what? > > But no, talking for me (and a couple of other), I have listed what I would > like to see before I even consider something else than -1. > > With all respects, I think you are too strict on phpng I am not strict but I am realistic, to avoid a total failure with php-next. > We all hope php to get better, for now I really care about performance Right, we all care about php. The question is more about how we care about its future and how to get everyone involved and get PHP cleaner, better and easier to maintain. > We are loosing users who switch to hhvm for performance. Phpng will change > the current embarrasse situation to us That's not what I see but for very few users. Visibility, cleaner (or less ugly) code base, better communication with the developers, etc. are more the points why some moves to hhvm. Some features we rejected in the past (strict hinting for method/function signature f.e., hack) are other reasons mentioned very often. Also keep in mind that I do love the performance improvements brought by phpng. It is really awesome. And again, thanks you guys for this effort. However it is critical, I repeat, critical, to keep other goals in mind for php-next. You forgot them for the last six months but it is too late. However if things go like Zend plans, it will be too late, and we will fail, miserably. I also talked to many very large PHP users in the last two months. As they all care about performance, it is not really their issue right now with php. One reason is that PHP rarely causes actual bottlenecks in their apps. But they have other worries, one of them is the code quality of the PHP core, which is by far not as good as it should be for the leading web programming language. And they expect the next major version to fix that. Not only to be more confident about the PHP implementation but also to ease contributions or extensions implementations. PHPNG solves none of these issues, in contrary. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Move phpng to master
On Mon, Jul 21, 2014 at 5:28 PM, Xinchen Hui wrote: > Hey: > > > 在 2014年7月21日，19:02，Ferenc Kovacs 写道： > > > >> On Mon, Jul 21, 2014 at 12:31 PM, Zeev Suraski wrote: > >> > >> > >> > >> 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 > > > > because there is so much stuff which we want to do in the next major > > version, but we can't even start because there is no stable base to > target > > the other php-next features. > What they are? Please come with RFC and Patches. > https://wiki.php.net/rfc/uniform_variable_syntax https://wiki.php.net/rfc/size_t_and_int64_next > Or you suggest we stop the current work to waiting them come their self? > I'm saying that we should resolve the current situation where people can't work on stuff which would target php-next, because it is still a moving target. I'm saying that it is nice that you(the phpng main devs) are confident that you can stabilize your changes so making a php-next release in less than a year, but other people have other ideas which can only happen in a major version, and you shouldn't rush an early release which would mean that the next window of opportunity for major refactor is in the next decade. I'm saying that it is pretty unfortunate that we have to decide to between reviewing/accepting a huuuge chunk of changes or rejecting a significant performance boost and some api cleanup. I'm saying that we should stop pushing our own agendas, and figure out the best possible solution for the current situation, so that we can go forward with the development with the normal workflow, where everybody is on the same page, controversial changes are done through RFCs and we don't block each other from the work. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] Wired constant expression syntax and bug
Am 2.7.2014 um 15:43 schrieb Dmitry Stogov : > I don't have good ideas out of the box and I probably won't be able to look > into this before next week. Hey, I still have no real idea how to solve it without breaking opcache. This one seems to be considered like a blocking bug for 5.6. Could you please try to fix this in a sane manner? Bob
Re: [PHP-DEV] RFC: Move phpng to master
Hey: I really don't like arguing in english, so this will be my last reply in this thread. On Tue, Jul 22, 2014 at 12:10 AM, Ferenc Kovacs wrote: > > > > On Mon, Jul 21, 2014 at 5:28 PM, Xinchen Hui wrote: >> >> Hey: >> >> > 在 2014年7月21日，19:02，Ferenc Kovacs 写道： >> > >> >> On Mon, Jul 21, 2014 at 12:31 PM, Zeev Suraski wrote: >> >> >> >> >> >> >> >> 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 >> > >> > because there is so much stuff which we want to do in the next major >> > version, but we can't even start because there is no stable base to >> > target >> > the other php-next features. >> What they are? Please come with RFC and Patches. > > > https://wiki.php.net/rfc/uniform_variable_syntax > https://wiki.php.net/rfc/size_t_and_int64_next aren't they discussed and voted? what do you mean by we can't even start in previous comment? > >> >> Or you suggest we stop the current work to waiting them come their self? > > > I'm saying that we should resolve the current situation where people can't > work on stuff which would target php-next, because it is still a moving > target. why Nikita could work on it? why me can work on it? > I'm saying that it is nice that you(the phpng main devs) are confident that > you can stabilize your changes so making a php-next release in less than a > year, but other people have other ideas which can only happen in a major > version, and you shouldn't rush an early release which would mean that the > next window of opportunity for major refactor is in the next decade. I am not sure about you attitude here, from these words, seems you agree to merge phpng to master asap, then people can start work on it? > I'm saying that it is pretty unfortunate that we have to decide to between > reviewing/accepting a huuuge chunk of changes or rejecting a significant > performance boost and some api cleanup. we shouldn't, at least most people here shouldn't, only the guys who need to maintain them should. > I'm saying that we should stop pushing our own agendas, and figure out the > best possible solution for the current situation, so that we can go forward > with the development with the normal workflow, where everybody is on the > same page, controversial changes are done through RFCs and we don't block > each other from the work. you know what? I really don't like "we should; we must", they means nothing.. I have spent lots of my time to work on PHP/PHPNG, more than 80 hours per month. I treat it like a regular work, dmitry spends more than me(8 hours per day). you ask me to stop to wait somebody who even can not work hours a month here? with all my respects: I really upset by people who always told you, hey man, don't be rush... because I am rushing, I have be rushing for months to make the work done.. last of all : "all above is my personal comments, has nothing to do with Zend"... thanks > > -- > Ferenc Kovács > @Tyr43l - http://tyrael.hu -- 惠新宸laruence Senior PHP Engineer http://www.laruence.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Move phpng to master
hi, On Tue, Jul 22, 2014 at 3:42 AM, Xinchen Hui wrote: >> https://wiki.php.net/rfc/uniform_variable_syntax >> https://wiki.php.net/rfc/size_t_and_int64_next > > aren't they discussed and voted? what do you mean by we can't even > start in previous comment? The int64 yes, that means and it is/was not possible given the status of phpng in the last weeks, way too many huge changes. >>> >>> Or you suggest we stop the current work to waiting them come their self? >> >> >> I'm saying that we should resolve the current situation where people can't >> work on stuff which would target php-next, because it is still a moving >> target. > > why Nikita could work on it? why me can work on it? Who is asking you to work on that? >> I'm saying that it is pretty unfortunate that we have to decide to between >> reviewing/accepting a huuuge chunk of changes or rejecting a significant >> performance boost and some api cleanup. > > we shouldn't, at least most people here shouldn't, only the guys who > need to maintain them should. Yes and no. phpng, as a whole, as it was done, as it is done, and as it is proposed forces us to this choice. I have asked very "early" (later on that) about your plans, and it was told it will not be the base for php-next and its aim is not to replace master. I expressed doubts, I see now that I was right. >> I'm saying that we should stop pushing our own agendas, and figure out the >> best possible solution for the current situation, so that we can go forward >> with the development with the normal workflow, where everybody is on the >> same page, controversial changes are done through RFCs and we don't block >> each other from the work. > > you know what? I really don't like "we should; we must", they means nothing.. They mean a lot, really a lot. > I have spent lots of my time to work on PHP/PHPNG, more than 80 hours > per month. Oh very nice. Now what do you think we spend on the int64 patch? While you were saying that it is fine for master but rejecting it later on because of your secret work on phpng? I really do not like that. > I treat it like a regular work, dmitry spends more than me(8 hours per day). > > you ask me to stop to wait somebody who even can not work hours a month here? It is called team work, with full time developers (very few) and other contributors, doing work on php in their free time (the waste majority). We have to respect the latter much more, much much more. > with all my respects: I really upset by people who always told you, > hey man, don't be rush... Nobody tells you not to rush to work on a given feature. However many did, and I'd to tell it again: do not to rush on pushing the next major release. The version we (all) have to maintain for the next decade. And by maintain it is not only about the core, it is about its extensions, be in core extensions and in PECL or other areas. A bad, unclean or broken APIs affect everyone, not only the few maintaining only one part of PHP, and only on one single platform. It will also affects end users projects, the health of a project affects everyone using it. > because I am rushing, I have be rushing for months to make the work done.. Most part of this work has been done in secret, without discussing with anyone but between you guys. While we were talking about our plans for php-next, even began the work, you were "rushing" to get phpng ready for the announce or release. You did not participate to any discussions nor proposed anything, not even mentioning your work on phpng. This is not the PHP I want to work with, it never was. Also rushing does not mean the work get done correctly. It is often the contrary. We can see that with phpng, you guys have worked very hard, but you worked in a bubble and now you come out of this bubble and tell us that it is all you want for next and that we should do it within a year. No, sorry, I can't and won't accept that. > last of all : "all above is my personal comments, has nothing to do > with Zend"... It has a lot to do with Zend given that Zend funds you to work on phpng and disallows you to communicate about it until it is announced (NDA). It is a shame to have NDAs to work on the core. It is a shame to come now and say things like "why should we wait for next if we (zend) are ready?" while having literally blocked everything since the announce of phpng. PHP-next is about a lot of things, way behind performance issues. You care only about that, but I, f.e., do care about performance only for 20% of my priorities. Large PHP users told me the same. The needs, goals etc for php-next have been discussed and listed. Some of these todos have been worked on, publically, with periodic communications about the status, what has been done, etc. Discussing with many contributors, publicly, openly. This is how it should be. Yes, you do not like the "should" usage, but I repeat, it must be like that. If we can work on PHP openly, I fail to understand why Zend tot
Re: [PHP-DEV] crypt() BC issue
Hi Anthony,
On Mon, Jul 21, 2014 at 11:32 PM, Anthony Ferrara
wrote:
> > E_NOTICE for password larger than 72 is mandatory. Current
> password_hash()
> > works without any sign of problem even if it may not be working as
> > authentication.
> > I'll add E_NOTICE as bug fix if there aren't any more comments.
>
> Could you please not.
>
> I have asked you to draft an RFC to justify what you intend to do
> (documentation, errors, etc) so that we may discuss it better. There
> is not a single person in this thread who has said "I think a notice
> is a good idea" except you. Yet you insist on just adding it as a "bug
> fix". Could you please just slow down, and write out the explanations
> so that we can have a meangingful discussion instead of just rushing
> through to commit ignoring what everyone is saying?
>
I see you and Andrey against to have E_NOTICE for password_hash().
There are only 2 persons to be correct. I don't know about IRC since I
don't it at all.
However, I don't mind at all to write RFC raising E_NOTICE for
password_hash() with
PASSWORD_BCRYPT.
> However, Using multiple hashes for better security is common technique.
> > An example is SSL. So I would not say one should not. Especially when
> there
> > is a limitation.
>
> TLS 1.0 (SSL) used a very specific construction of PRF(secret1,
> label + seed) XOR PRF(secret2, label + seed). This is very much
> not "using multiple hashes", but using 2 different PRF (pseudo-random
> functions) and xoring them together. The end result should be
> resistent to cryptoanalysis or attacks that only target one of the
> hash functions.
>
> However, TLS 1.2 removed that construction and uses the PRF based on
> SHA-256 alone. Why?
>
> As it turns out, it's not based in science at all, and can be proven
> faulty. Here's a quick proof:
>
> HASH_FUNC_A - A secure cryptographic hash function (resistent to
> collisions, pre-image attacks and 2nd pre-image attacks, ex: SHA-256)
> HASH_FUNC_B - Defined as HASH_FUNC_A XOR C (for some arbitrary constant C).
>
> Since HASH_FUNC_A is secure, HASH_FUNC_B is secure as well (since
> xoring with an arbitrary constant changes none of its properties).
>
> However, HASH_FUNC_A XOR HASH_FUNC_B will always produce C. Proving
> that XOR of two arbitrary hash functions isn't necessarily secure.
>
> More information:
> http://tuprints.ulb.tu-darmstadt.de/2094/1/thesis.lehmann.pdf
Although cryptgraphic hash functions are supposed work cryptgraphic way, but
many of them are failing. It was not in real world and I aware of the risk.
Now, if all you care about is pre-image resistance, then H1(H2(x))
> appears to be secure. And if we assume that H1() and H2() are secure
> functions, it is.
>
> However, that's a tricky assumption to make. For example, any
> collisions in H2() automatically become collisions in H1()
> (incidentally, this was the reason PBKDF2 replaced PBKDF1). So that
> effectively means that the collision resistance of H1(H2(x)) is at
> least as weak as the weakest hash function (potentially weaker). But
> we said that all we care about is pre-image resistance, so why does
> that matter? Because in the end, we don't just care about pre-image
> resistance. We also do care about collision resistance (though to a
> lesser degree for password storage). Because with the hash, if an
> attacker can generate a collision, they can use that to login to your
> system. Yes, that didn't leak the original password (and hence other
> systems may be safe), but it did let him compromise you.
>
> In practice, this isn't very likely (as SHA-512 is a strong function
> with no known collisions, nor decent attack against it). But in terms
> of recommending crypto to the general public, "isn't very likely" is
> the wrong way to make recommendations.
>
I agree with you discussion and have no objection. I understand it's
correct in theory
and real world.
Even if I understand the risk, it's acceptable for me to use SHA512 to
workaround
password length limit as long as SHA512 and/or blowfish is considered safe.
As I
wrote, password length limit is decided by app developers and we are not
the app
developer.
> In old days, crypt() was unusable securely. There are many
> users/developers
> > that
>
> No, crypt() was perfectly able to be used securely. The password_hash
> apis prove that. Many didn't use it securely, but that didn't mean it
> isn't secure.
>
I agree that recent crypt() can be used securely(reliably). I'm pointing it
out that it was
not, especially with pre 5.3 as you know. We know that there are many users
out
there still using pre 5.3.
http://w3techs.com/technologies/details/pl-php/5/all
> are used to have static slat. Code like below disables authentication
> > completely.
> >
> > password_hash(hash('sha512', SOME_SECRET_SALT).$password, DEFAULT);
> >
> > This should be prevented. (I would like to prevent it by raising E_NOTICE
> > error)
>
> And a E_NOTICE will prevent nothing. If you *really* want to prevent
> it,
Re: [PHP-DEV] crypt() BC issue
Hi Yasuo, On Tue, Jul 22, 2014 at 5:00 AM, Yasuo Ohgaki wrote: > Hi Anthony, > > On Mon, Jul 21, 2014 at 11:32 PM, Anthony Ferrara > wrote: > >> > E_NOTICE for password larger than 72 is mandatory. Current >> password_hash() >> > works without any sign of problem even if it may not be working as >> > authentication. >> > I'll add E_NOTICE as bug fix if there aren't any more comments. >> >> Could you please not. >> >> I have asked you to draft an RFC to justify what you intend to do >> (documentation, errors, etc) so that we may discuss it better. There >> is not a single person in this thread who has said "I think a notice >> is a good idea" except you. Yet you insist on just adding it as a "bug >> fix". Could you please just slow down, and write out the explanations >> so that we can have a meangingful discussion instead of just rushing >> through to commit ignoring what everyone is saying? >> > > I see you and Andrey against to have E_NOTICE for password_hash(). > There are only 2 persons to be correct. I don't know about IRC since I > don't it at all. I do not see any discussion about that on IRC, but I would rather not add it either. It brings little but more confusions. I would suggest to do what Anthony suggested and we will see the outcome. Cheers, -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Move phpng to master
Hi Zeev, On Mon, Jul 21, 2014 at 7:18 PM, Zeev Suraski wrote: > Hi Zeev, > > > > On Mon, Jul 21, 2014 at 4:31 PM, Zeev Suraski wrote: > > 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. > Sorry that my mail is not precise enough. I'm not sure your intention if we are going to have master branch as successor of PHP 5.6 or not. If it is PHP 5.6 successor, then we have less than a year before feature freeze. If there is PHP 5.7 branch, I suppose we have more than a year before feature freeze. I feel less than a year for new major version is too short, so I would like to have PHP 5.7, then a year later PHP 6/7. There are too many things that I would like to cleanup. I'm mainly interested in userland API cleanups/additions as well as mbstring/session internal. Developing 5.7 and 6/7 at the same is beneficial to us, too. We may implement migration features in 5.7. 3rd party module developers will have enough time to migrate before release also. We may have long alpha period for 6/7. I suppose having 5.7 branch does not waste yours and your people's time much if phpng became master. BTW, I'm in favor of PHP 7. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] RFC: Move phpng to master
On 2014-07-21, Michael Wallner wrote: > --001a11345984e013cd04feb0d9a1 > Content-Type: text/plain; charset=UTF-8 > Content-Transfer-Encoding: quoted-printable > > On 21 Jul 2014 10:21, "Julien Pauli" wrote: > 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. > > --001a11345984e013cd04feb0d9a1-- I want to remind that the last attempt of PHP 6 died because it was mostly unmaintained as "master" for a long time and we continued to postpone it. We should try to not again make a "big move" but take "babysteps" and focus on phpng and 64bit as the major features and not maintain a branch while we are doing 5.7. This will undoubtful lead to a similar "abundance" of the master branch as we just don't have the ressources to maintain more branches (a point already made when we discussed the release plan). I think we should consider steps to make phpng the major development branch within the year and if stabelizing it within the year possible, make it the next release. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Move phpng to master
Hi David, On Tue, Jul 22, 2014 at 2:08 PM, David Soria Parra wrote: > On 2014-07-21, Michael Wallner wrote: > > --001a11345984e013cd04feb0d9a1 > > Content-Type: text/plain; charset=UTF-8 > > Content-Transfer-Encoding: quoted-printable > > > > On 21 Jul 2014 10:21, "Julien Pauli" wrote: > > 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. > > > > --001a11345984e013cd04feb0d9a1-- > > I want to remind that the last attempt of PHP 6 died because it was mostly > unmaintained as "master" for a long time and we continued to postpone > it. We should try to not again make a "big move" but take "babysteps" > and focus on phpng and 64bit as the major features and not maintain a > branch while we are doing 5.7. This will undoubtful lead to a similar > "abundance" of the master branch as we just don't have the ressources > to maintain more branches (a point already made when we discussed the > release plan). > > I think we should consider steps to make phpng the major development > branch within the year and if stabelizing it within the year possible, > make it the next release. > Even if we have PHP-5.7 branch, we have merge up policy. Therefore, any new feature will end up with master, I suppose. If a new feature is only available to PHP-5.7 branch, it's a merge bug, isn't it? Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] RFC: Move phpng to master
Am 7/21/14, 10:21 PM, schrieb Yasuo Ohgaki: > > Even if we have PHP-5.7 branch, we have merge up policy. Therefore, > any new feature will end up with master, I suppose. If a new feature is > only available to PHP-5.7 branch, it's a merge bug, isn't it? > > Regards, We had this policy before and it didn't help us. The problem is maintiaining all the branches and keeping people interested in the next branch because people tend to focus on the currently release branch. When we decided upon the release RFC we talked a lot about the overhead of maintaing multiple branches and tried to reduce the amount of branches. In particular with API changes it becomes tidious if we try to maintain a feature across branches and that implicit divergence has to be resolved better sooner or later, or otherwise it would be just like the old php6 again. David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE][RFC] Name of Next Release of PHP
On Mon, Jul 21, 2014 at 2:21 AM, Michael Wallner wrote: > On 20 Jul 2014 23:32, "Andrea Faulds" wrote: > > > > > > On 20 Jul 2014, at 22:28, Nikita Popov wrote: > > > > > After the vote has been started the RFC was edited by Zeev in order to > strengthen the case for PHP 7. There is nothing wrong with that, adding > additional arguments to an RFC is perfectly fine by me. > > > > > > However at the same time a number of paragraphs were removed that were > arguing for PHP 6, at least in part. The only thing that was left in "The > case for PHP 6" was a single paragraph, of which half was really just an > explanation of the general situation. > > > > > > Effectively the edits made the RFC text heavily biased. It's okay to > edit an RFC to add arguments for your side, but I find it discourteous and > disingenuous to remove arguments from the opposing side at the same time. > > > > > > As such I can understand Andrea's decision to close this vote until > tempers had time to cool down and both sides had a chance to be fairly > represented. > > > > It also wasn’t really fair of me to start a vote when there wasn’t really > a case for 7, now that I think about it. I suppose that makes my later > decision hypocritical, but it does mean we’re in a better place now when we > have a second vote, as we have two cases. > > To sum it up: > > 6 would be the logical number for the next major version, that's just a > fact. > I would go with it. But I and probably most others who would go with 6 > wouldn't really be hurt if we went with 7. > > On the other hand there would be quite some people hurt if we went with 6. > So, maybe it's just me, but there seems to only be a "case" for 7. > > Let's think about the people, not only numbers and facts. We often forget > about that when "just" answering mails. > > Cheers, > Mike > Andrea and Zeev, If it's not too much trouble, could you both keep us updated on this thread with regard to your progress (or lack thereof) in getting the RFC to a state that both of you are in agreement on? I think part of the problem last time was that the discussion fizzled, people forgot about it and moved on to other things, then suddenly it sprang back up to a vote. I know that added to the initial confusion on my part, at least. So even if you've made no progress, please take a moment at least once a week or so to update this thread with your status. It's kinda an accountability booster, as well. And Andrea, though according to the bylaws you can start the vote whenever you want, please do me a favor and refrain from doing so until Zeev says his part is ready. We can always put pressure on him and ultimately find someone else to do it if he takes *too* long, but as he pointed out and I think rightly so, there's no urgency at the moment so we can afford a little bit of foot-dragging if need be. Oh and please feel free to tell me to butt-out at any time. =) --Kris
Re: [PHP-DEV] Wired constant expression syntax and bug
Hi Bob, Now I think it's not fixable by design :( I'll try to think about it later today. Could you please collect all related issues. Thanks. Dmitry. On Mon, Jul 21, 2014 at 8:36 PM, Bob Weinand wrote: > Am 2.7.2014 um 15:43 schrieb Dmitry Stogov : > > I don't have good ideas out of the box and I probably won't be able to > look into this before next week. > > > Hey, I still have no real idea how to solve it without breaking opcache. > > This one seems to be considered like a blocking bug for 5.6. > > Could you please try to fix this in a sane manner? > > Bob >
Re: [PHP-DEV] RFC: Move phpng to master
Pierre, I don't replay to you, because it's bad for my health. Many people here would agree with me. I prefer to do things instead of endlessly repeated words. According to PHPNG - we set one big goal (performance), and worked on it really hard. Now everyone may see the result. It's just not possible to solve all the goals at once and we didn't try to do it. Big PHP users just can't not to care about performance, because it's money. I know most of them already experimented with HHVM. If we don't provide adequate replay, we may turn back into the language for home pages. Thanks. Dmitry. On Tue, Jul 22, 2014 at 6:58 AM, Pierre Joye wrote: > hi, > > > On Tue, Jul 22, 2014 at 3:42 AM, Xinchen Hui wrote: > > >> https://wiki.php.net/rfc/uniform_variable_syntax > >> https://wiki.php.net/rfc/size_t_and_int64_next > > > > aren't they discussed and voted? what do you mean by we can't even > > start in previous comment? > > The int64 yes, that means and it is/was not possible given the status > of phpng in the last weeks, way too many huge changes. > > >>> > >>> Or you suggest we stop the current work to waiting them come their > self? > >> > >> > >> I'm saying that we should resolve the current situation where people > can't > >> work on stuff which would target php-next, because it is still a moving > >> target. > > > > why Nikita could work on it? why me can work on it? > > Who is asking you to work on that? > > > >> I'm saying that it is pretty unfortunate that we have to decide to > between > >> reviewing/accepting a huuuge chunk of changes or rejecting a > significant > >> performance boost and some api cleanup. > > > > we shouldn't, at least most people here shouldn't, only the guys who > > need to maintain them should. > > Yes and no. phpng, as a whole, as it was done, as it is done, and as > it is proposed forces us to this choice. > > I have asked very "early" (later on that) about your plans, and it was > told it will not be the base for php-next and its aim is not to > replace master. I expressed doubts, I see now that I was right. > > >> I'm saying that we should stop pushing our own agendas, and figure out > the > >> best possible solution for the current situation, so that we can go > forward > >> with the development with the normal workflow, where everybody is on the > >> same page, controversial changes are done through RFCs and we don't > block > >> each other from the work. > > > > you know what? I really don't like "we should; we must", they means > nothing.. > > > They mean a lot, really a lot. > > > I have spent lots of my time to work on PHP/PHPNG, more than 80 hours > > per month. > > Oh very nice. Now what do you think we spend on the int64 patch? While > you were saying that it is fine for master but rejecting it later on > because of your secret work on phpng? I really do not like that. > > > I treat it like a regular work, dmitry spends more than me(8 hours per > day). > > > > you ask me to stop to wait somebody who even can not work hours a month > here? > > It is called team work, with full time developers (very few) and other > contributors, doing work on php in their free time (the waste > majority). We have to respect the latter much more, much much more. > > > with all my respects: I really upset by people who always told you, > > hey man, don't be rush... > > Nobody tells you not to rush to work on a given feature. However many > did, and I'd to tell it again: do not to rush on pushing the next > major release. The version we (all) have to maintain for the next > decade. And by maintain it is not only about the core, it is about its > extensions, be in core extensions and in PECL or other areas. A bad, > unclean or broken APIs affect everyone, not only the few maintaining > only one part of PHP, and only on one single platform. It will also > affects end users projects, the health of a project affects everyone > using it. > > > because I am rushing, I have be rushing for months to make the work > done.. > > Most part of this work has been done in secret, without discussing > with anyone but between you guys. While we were talking about our > plans for php-next, even began the work, you were "rushing" to get > phpng ready for the announce or release. You did not participate to > any discussions nor proposed anything, not even mentioning your work > on phpng. This is not the PHP I want to work with, it never was. > > Also rushing does not mean the work get done correctly. It is often > the contrary. We can see that with phpng, you guys have worked very > hard, but you worked in a bubble and now you come out of this bubble > and tell us that it is all you want for next and that we should do it > within a year. No, sorry, I can't and won't accept that. > > > last of all : "all above is my personal comments, has nothing to do > > with Zend"... > > It has a lot to do with Zend given that Zend funds you to work on > phpng and disallows you to communicate about it un
