Re: [PHP-DEV] Vote process change proposal
On Mar 18, 2015 10:52 AM, Stanislav Malyshev smalys...@gmail.com wrote: Hi! Private emails, pressure and what many, including myself, consider as harassment is a big issue in many OSS projects, and for PHP too. I am What exactly you are calling harassment? Repeatedly, explicitly, strongly asking to shut down a RFC or general proposal is what I consider as harassment. Even more if prominent figures do it. I have a feeling we are talking about different things, so it would be nice to explain what exactly is harassment ans some specific examples of when that happened in PHP would be nice. E.g., if I email you and explain you my POV on certain topic, is it harassment? What is I ask your opinion on certain topic? What if I ask you to vote on certain RFC? What if I ask you for explanation of your vote? not sure what can be done to solve that but private discussions should be avoided at any price to avoid such bad things to happen. And this Sorry, but I completely disagree. Not only you have absolutely no right and no business to tell me who I choose to talk in private (and, of course, to anybody else as well), but there's absolutely no reason to avoid it. You are totally right. I have no right to tell you what to do, or to anybody else for what matters. But I have the damn right to say that most of the times private, extensive, and long discussions to finalize damage OSS projects. And recent events here tell me that I am right to think so. Now, you can convince me by actually me explaining cases where private, extensive long discussions are actually good and I will proudly change my mind. I've had hours of very productive private discussions about various technical topics, both in PHP and outside, and there's absolutely nothing wrong with it. I'm not sure which such bad things you mean but I'd like to see some bad things that actually happened because of it. Of course, that doesn't mean people should not discuss important things in public, especially if they are of public (understood either as PHP devs or PHP users or wider) concern. Both modes have their uses. And of course it doesn't mean people should not follow the RFC process and provide the necessary explanations and support for their opinions and proposals. But I don't think we lack that, in most cases. There are outliers and bad RFCs from time to time, but we can deal with them when they come. Now, I do agree as well that discussions can be affiliated to lobbying. But the key difference is that a discussion on the list is open and should be backed with technical argument (or principles when it comes to design). Lobbying, and you know that perfectly, is totally different story. Let be straight about what is happening and do not hide our head in the sand for the sake of ignoring a growing and devastating problem. OK, let us be super-straight. *What* is, on your opinion, happening? While you call us to be straight and claim there is a devastating problem, you seemingly forgot to straightly say what is actually happening and which devastating problem it is? Please do so. We cannot afford to loose more new contributors, no matter the reason. Sorry, but we will lose contributors, no matter what. People change, circumstances change, availability changes, people burn out, people get busy, people lose interest, people lose patience with other people disagreeing with them... Tons of reasons why people move on. So giving out such blanket statements no matter what doesn't seem very useful to me. I agree the community here is not ideal, and could benefit from more kindness and supportiveness, and the processes could be improved. I don't think anybody is against putting forward specific thoughts on how to do it (though not all thoughts would be good ideas, naturally). But however hard we try, for some people it would prove not to be to their taste, and we can not say we can not let that happen no matter the reason. -- Stas Malyshev smalys...@gmail.com
Re: [PHP-DEV] Vote process change proposal
Hi! Private emails, pressure and what many, including myself, consider as harassment is a big issue in many OSS projects, and for PHP too. I am What exactly you are calling harassment? I have a feeling we are talking about different things, so it would be nice to explain what exactly is harassment ans some specific examples of when that happened in PHP would be nice. E.g., if I email you and explain you my POV on certain topic, is it harassment? What is I ask your opinion on certain topic? What if I ask you to vote on certain RFC? What if I ask you for explanation of your vote? not sure what can be done to solve that but private discussions should be avoided at any price to avoid such bad things to happen. And this Sorry, but I completely disagree. Not only you have absolutely no right and no business to tell me who I choose to talk in private (and, of course, to anybody else as well), but there's absolutely no reason to avoid it. I've had hours of very productive private discussions about various technical topics, both in PHP and outside, and there's absolutely nothing wrong with it. I'm not sure which such bad things you mean but I'd like to see some bad things that actually happened because of it. Of course, that doesn't mean people should not discuss important things in public, especially if they are of public (understood either as PHP devs or PHP users or wider) concern. Both modes have their uses. And of course it doesn't mean people should not follow the RFC process and provide the necessary explanations and support for their opinions and proposals. But I don't think we lack that, in most cases. There are outliers and bad RFCs from time to time, but we can deal with them when they come. Now, I do agree as well that discussions can be affiliated to lobbying. But the key difference is that a discussion on the list is open and should be backed with technical argument (or principles when it comes to design). Lobbying, and you know that perfectly, is totally different story. Let be straight about what is happening and do not hide our head in the sand for the sake of ignoring a growing and devastating problem. OK, let us be super-straight. *What* is, on your opinion, happening? While you call us to be straight and claim there is a devastating problem, you seemingly forgot to straightly say what is actually happening and which devastating problem it is? Please do so. We cannot afford to loose more new contributors, no matter the reason. Sorry, but we will lose contributors, no matter what. People change, circumstances change, availability changes, people burn out, people get busy, people lose interest, people lose patience with other people disagreeing with them... Tons of reasons why people move on. So giving out such blanket statements no matter what doesn't seem very useful to me. I agree the community here is not ideal, and could benefit from more kindness and supportiveness, and the processes could be improved. I don't think anybody is against putting forward specific thoughts on how to do it (though not all thoughts would be good ideas, naturally). But however hard we try, for some people it would prove not to be to their taste, and we can not say we can not let that happen no matter the reason. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5
Hi Andre,
On Wed, Mar 18, 2015 at 8:53 AM, André Rømcke andre.rom...@ez.no wrote:
TL;DR; weak mode is for api consumers, aka normal php users, while strict
is
for the actual target users of this features: api (library/framework)
creators.
How could it possible?
On Mon, Mar 16, 2015 at 2:49 PM, Dennis Birkholz den...@birkholz.biz
wrote:
Am 16.03.2015 um 06:28 schrieb Xinchen Hui:
lib.php
?php
declare(strict_types = 1);
function add(int $a, int $b) {
}
?php
add($_GET['a'], $_GET['b']);
that means, I need to add a lots of (int) while I try to call a
function in a library which is not written by myself.
that is not right and has been discussed a thousand times over.
The declare changes the rules only for function calls in the file it is
declared in.
so:
lib.php:
?php
declare(strict_types = 1);
function foo(int $a) {
// no function call here
}
?
The declare here does just nothing.
?php
require lib.php;
foo(123); // will work
?
?php
declare(strict_types = 1);
require lib.php;
foo(123); // will give an error
?
Very easy, explained a thousand times over. Bringing up the same false
arguments up again and again does really not help the discussion.
I didn't have my time to spent for the patch. So I don't verify this
by myself, but it seems common sense for this RFC.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5
On Mar 18, 2015 11:26 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote: I didn't have my time to spent for the patch. So I don't verify this by myself, but it seems common sense for this RFC. So you voted against it without knowing how it actually works or aims to work? I suggest you to do it now then, before going further with this discussion :)
Re: [PHP-DEV] [VOTE] Reserve even more type hints
On 16 March 2015 at 23:37, Dan Ackroyd dan...@basereality.com wrote: In particular the keywords 'Resource' and 'mixed' seem to have limited need to be reserved. I don't believe there has been any suggestion that either of these would actually be used as types for PHP 7.x. So making them be unusable seems to be a large BC hit for no gain for people who currently have classes that use them I agree, mixed seems to serve no purpose (just don't hint the parameter, same result). Resource is something we're hopefully going to phase out over time as they get replaced with objects (like Nikita already did with GMP, and hopefully will happen to streams some time between now and 7.1 :)). It's possible that people are voting yes to reserve these two words, without fully considering whether they should be reserved or not. I can see that all of 'object', 'scalar', and 'numeric' have been proposed as part of future improvements to PHP's type system. I don't really like scalar or numeric (but I'm in the strict types camp and I think if union types ever make it in, they should be user definable). Object makes sense to me though, apart from resource it's the only one that represents a single underlying type.
Re: [PHP-DEV] [VOTE] Reserve even more type hints
rather than having a single untyped parameter amongst typed ones Yes, when experimenting with strict types, I'd rather move things in and out of 'mixed' than remove the notation completely. Like you said, 'mixed' means, I've reviewed this area and concluded it needs to be dynamic. Also, maybe I missed this upthread, but are the docs still going to refer to 'mixed'? -- Sandy
Re: [PHP-DEV][RFC][VOTE] Strict Argument Count On Function Calls
Hi, all At first, Thanks for all your work put in here, Marcio. It gave me a new hint for a possible code-failure. FYI: PhpStorm lately added an inspector for that. Glad to see that move after I heard that the RFC won't pass. https://youtrack.jetbrains.com/issue/WI-14692 Bye, Simon On Mon, Mar 16, 2015 at 6:04 PM, Marcio Almada marcio.w...@gmail.com wrote: Hi, I had no time to reply all emails since yesterday, but right now we are having a voting with 2 yes votes vs 16 no votes. I think we all agree that the RFC won't pass and I'm withdrawing the RFC for the following reasons: 1. The sooner we end the voting period the better for the PHP time line. Since there is no motives to think the voting will flip, the best attitude seems to be a withdraw. 2. We are having a lot of simultaneous voting right now and some voters care to read all the RFCs. The proposed RFC is long, requires testing etc. As it was already rejected, removing it from the list of RFCs in voting phase might be beneficial to the voting process as it reduces the RFC overload we are having because of the feature freeze. 3. Looking at the ML, there are many controversial points that were raised, a lot of them since yesterday. Weather they are debatable or not, all this controversy during voting phases is a bad thing (look at the scalar type hints drama we had). So it's better to just put this to end and move on. Thanks for the votes, I'll try to reply to the emails anyway whenever necessary :) PS: I don't intend to propose this RFC again in the future as I already have other more important RFCs planned for PHP 7.1 Thanks, Márcio
Re: [PHP-DEV] [VOTE] Reserve even more type hints
On 17 March 2015 at 07:08, Leigh lei...@gmail.com wrote: I agree, mixed seems to serve no purpose (just don't hint the parameter, same result). Resource is something we're hopefully going to phase out over time as they get replaced with objects (like Nikita already did with GMP, and hopefully will happen to streams some time between now and 7.1 :)). It has been pointed out to me, that mixed is useful for being explicit, rather than having a single untyped parameter amongst typed ones, you know that it was designed to accept anything rather than being an oversight. Completely valid point.
Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5
On 17/03/15 02:50, Stanislav Malyshev wrote: Let's get on the road for PHP 7 GA and make it the best PHP release ever. To help towards that end, can someone who understands what is wanted from the weak type hint mode actually produce a summary of that as it is very difficult to extract just what has now been agreed for that area of type hinting. A base that can be used to review some of the other discussions to put that to bed. Others might appreciate a similar summary of the 'type_error' mode as well? As a base for the documentation on the user manual updates? -- 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] [VOTE] Reserve even more type hints
On 17 March 2015 at 08:02, Sanford Whiteman figureone...@gmail.com wrote: rather than having a single untyped parameter amongst typed ones Yes, when experimenting with strict types, I'd rather move things in and out of 'mixed' than remove the notation completely. Like you said, 'mixed' means, I've reviewed this area and concluded it needs to be dynamic. Also, maybe I missed this upthread, but are the docs still going to refer to 'mixed'? Yes. -- Sandy
[PHP-DEV] VCS Account Request: cmb
helping to maintain the wiki (php/web-wiki and php/web-shared) as suggested by bjori -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Vote process change proposal
Hi, 2015-03-17 21:35 GMT+01:00 Stanislav Malyshev smalys...@gmail.com: Or, even worse, given current tendencies, somebody submits a proposal, couple of people say yeah good idea, then vote happens and somehow there's 30 no votes without any explanation - and without possibility to fix it since by the time the proposer knows it the proposal is already declined. It wouldn't be very encouraging to submit RFCs with such process. Unrelated to the suggestion of hiding votes: How about adding an *optional* field next to the vote, where a voter can link to his reasoning (a link to a mail to the list preferably). This might make picking up older rfcs (,that were declined for earlier versions easier if the general idea of the rfc isn't flawed) and collects reasons for the outcome of an rfc without searching through months of discussions. This change might also make it easier for the author to chase down, why a vote failed, even if the prior discussion didn't point into that direction. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: [PHP-CVS] com php-src: Enable GCC global register variables if available: Zend/Zend.m4 Zend/zend_execute.c
On Tue, Mar 17, 2015 at 10:39 PM, Stanislav Malyshev smalys...@gmail.com wrote: Hi! Dmitry, the perf boost of this is awesome, but is it completely safe? Won't a signal potentially overwrite a register variable here? Like on a timeout, for example? The docs say (http://gcc.gnu.org/onlinedocs/gcc/Global-Reg-Vars.html): It is not safe to access the global register variables from signal handlers, or from more than one thread of control, because the system library routines may temporarily use the register for other things (unless you recompile them specially for the task at hand). I don't see any problems to reuse the same registers outside executor. Also: It is not safe for one function that uses a global register variable to call another such function foo by way of a third function lose that is compiled without knowledge of this variable (i.e. in a different source file in which the variable isn't declared). This is because lose might save the register and put some other value there. For example, you can't expect a global register variable to be available in the comparison-function that you pass to qsort, since qsort might have put something else in that register. (If you are prepared to recompile qsort with the same global register variable, you can solve this problem.) preserved registers are saved and restored as usually. So, I wonder how that would work with loadable modules and external libraries that could use PHP callbacks. It works and I didn't see any problems yet :) Thanks. Dmitry. -- Stas Malyshev smalys...@gmail.com
Re: [PHP-DEV] Vote process change proposal
Hi! While I agree with discussing an ongoing vote, I do not find it ok for people to be able to see the current status of an ongoing vote. This might lead to harassing people into voting just to change the outcome. Clear example: You frame trying to change people's mind as something negative (harassing), but that's exactly what we're doing during discussion period. If not that, we wouldn't need it - just publish RFC and go directly to vote, nobody harasses anybody with discussion. I hope you don't think it is a good idea. I think we are all adult enough to be able to handle discussion on the merits of the proposals, and if someone has enough of it, it's ok too - nobody is forced to participate. But I think openness is an important condition of participation. The vote score is 21-7 so I know I need another vote to pass, so I call in an acquaintance or friend to vote my way. So, what's bad in it? Either you friend genuinely thinks your RFC is good, and then there's no harm in having him vote so, or he just mindlessly votes yes without reading, in which case he should not vote at all, whether it's open or closed. All the democratic votes I have in mind are hidden until the vote closes, The votes in political elections are hidden forever, not until the vote closes. The reason is twofold: 1) it prevents voter intimidation and retaliation and 2) it makes bribing the voter harder, since you can not ensure somebody you bribed actually voted the way you wanted. However, neither your proposal proposes secret ballots nor any of the problems really shown to be exist for RFCs - I don't know anybody who was intimidated or retaliated against because of PHP RFC vote, and I never heard of anybody being afraid to vote on an RFC. Also, I haven't heard about anybody trying to bribe RFC vote. You misunderstood me or I did not formulate that clear enough. What I meant to say is that there are already people that go in the existing opened voting thread and explain their vote, e.g. I voted no on this because I think That's fine. However, a stream of +1/-1 comments is usually not necessary because the vote shows it. However, with vote closed, for the RFC author to be sure they're not wasting their time, it'd be necessary to solicit pre-vote votes, otherwise there's no chance to fix RFC before it fails. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] phar_rename_archive() bug fix for PHP7
I recently stumbled over that issue, too; thanks for looking into it. Looking at the patch, it seems, that some handling for bzip2 archives is missing; I think if there are special cases for .tar, .tgz and .zip, there should also be a case for .tbz2 (.tar.bz2). Yep, I discussed this with a friend and did a quick search this morning. It is missing, mostly because I didn't know how popular .tbz2 was as a file extension - it is very rare. In most cases I see .tar.bz2 (a case already handled by .tar). I can add .tbz2 as a handled file extension, and restructure the code accordingly. Additionally, I've found that phar_detect_phar_fname_ext() also needs some suffix validation, which I will also add. I will have a new commit for this in place tonight. (Which will also trigger Travis to run again, I think it failed b/c I force pushed my last commit). Thanks for taking the time, I'll let you know when there are more commits to review. -ralph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Voting irregularities
On Tue, Mar 17, 2015 at 2:15 PM, Sebastian B.-Hagensen sbj.ml.r...@gmail.com wrote: Hi, 2015-03-17 20:55 GMT+01:00 Hannes Magnusson hannes.magnus...@gmail.com: If you need to confirm the statistics, or gather more background data, then feel free to contact me privately, off the list, and I'll get you the account approval dates (karma and/or wiki). While I agree that the issue at hand was not presented in the way it should have been may still become a valid issue in the future. If you want to prevent situations or even (wrong) ideas and accusations like these the dates of account creations have to be public and easily accessible by everyone involved (publicly listed on people.php.net for example). people.php.net are php.net karma holders. We have no responsibility to disclose any information about our contributors to anyone. It is however fun to do so, so I created people.php.net listing random info about our contributors. If you can think of other fun things to do with that website, I'd love feedback and contributions! The wiki account system is different. php.net karma holders have access out-of-the-box using their vcs credentials. Then there is a special case where you have to register to the wiki itself. Having a wiki account does nothing out-of-the-box. You have to ask for specific access. Since the inception of the wiki I have been the only one giving out wiki credentials. This has mostly been to outsiders wanting to write RFCs. I have vague memories having given 2-3 people access to https://wiki.php.net/usergroups and similar to docs and so on. These people still cannot vote. A person who maintains popular pecl extension cannot vote either, unless the extension is maintained on the php.net infrastructure (and therefore requiring php.net account) btw. There have been several members from the community that have asked for voting privileges, as per the voting rfc. I have arbitrary approved maybe 3 or 4 over the years. The other 5-10 did not get voting privileges because the authors of the voting rfc didn't care. I have absolutely no interest this voting business and and strongly disagree with the entire voting rfc idea. I would love to get back to http://producingoss.com/en/consensus-democracy.html Now. Please go on and become famous by blogging about conspiracy theories (I've got plenty if you are short of ideas!) or whatever tickles your fancy - but please don't be dragging this onto the list. -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP apache2handler virtual() function
Hi! i.e. when it works at all. With Apache 2.4 the ap_rflush() in zif_virtual() terminates the currently running main request, in my testing, resulting in a completely crashing apache. This might be remedied, though. At the moment, as part of my efforts to fix bug 68486, I have modified things to that the PHP interpreter is NEVER reentered. virtual() continues to work, but only with URIs that do not again enter the apache2handler. First question here: would this be an acceptable bugfix? Do you mean that you can call virtual() only on non-php URLs but on PHP urls it would fail? I'd assume that is a pretty big BC break then so it'd be better if we could avoid it. But if it's not avoidable then I guess we should do what we need to avoid crashing. Furthermore, I have a working prototype of changing the behaviour of virtual() in the following way: _remember_ which subrequest should be made, but then only really make it when the current request ends (php_handler() in the That's probably useful but not the case for virtual(), as virtual() is meant to be replacement for SSI #include, i.e. work in-place, and if it's deferred till the end of the request the output will be broken. I'm not sure how many people actually use virtual() (it's pretty limited use case) but ones that do probably need it to work in place. Not sure PHP support in it is required though (since you could include PHP code directly I presume). -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Voting irregularities
Hi, 2015-03-17 20:55 GMT+01:00 Hannes Magnusson hannes.magnus...@gmail.com: If you need to confirm the statistics, or gather more background data, then feel free to contact me privately, off the list, and I'll get you the account approval dates (karma and/or wiki). While I agree that the issue at hand was not presented in the way it should have been may still become a valid issue in the future. If you want to prevent situations or even (wrong) ideas and accusations like these the dates of account creations have to be public and easily accessible by everyone involved (publicly listed on people.php.net for example). -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Vote process change proposal
Why we want to block it? What's wrong in convincing people that your idea is OK (or that it's not OK, for that matter)? Isn't it kind of the whole point of discussing it? While I agree with discussing an ongoing vote, I do not find it ok for people to be able to see the current status of an ongoing vote. This might lead to harassing people into voting just to change the outcome. Clear example: The vote score is 21-7 so I know I need another vote to pass, so I call in an acquaintance or friend to vote my way. All the democratic votes I have in mind are hidden until the vote closes, and here I am referring to any election out there, or even referendum. So now parallel to voting we get threads announcing everybody's votes. Yay, more noise! Or, even worse, given current tendencies, somebody submits a proposal, couple of people say yeah good idea, then vote happens and somehow there's 30 no votes without any explanation - and without possibility to fix it since by the time the proposer knows it the proposal is already declined. It wouldn't be very encouraging to submit RFCs with such process. You misunderstood me or I did not formulate that clear enough. What I meant to say is that there are already people that go in the existing opened voting thread and explain their vote, e.g. I voted no on this because I think that won't work. I was not referring here to each one opening a thread, sorry for explaining it poorly. Stelian On Tue, Mar 17, 2015 at 9:44 PM, johnc...@gmail.com wrote: I see absolutely no issues with the visibility of votes, or the act of “lobbying” for someone’s vote. On Tue, Mar 17, 2015 at 4:36 PM, Stanislav Malyshev smalys...@gmail.com wrote: Hi! This would block voting lobbying in various social channels based on possible outcomes, and would allow voting to run its course unaltered. The people Why we want to block it? What's wrong in convincing people that your idea is OK (or that it's not OK, for that matter)? Isn't it kind of the whole point of discussing it? want to share their vote option, can still do that in the mailing list where some already justify their votes. So now parallel to voting we get threads announcing everybody's votes. Yay, more noise! Or, even worse, given current tendencies, somebody submits a proposal, couple of people say yeah good idea, then vote happens and somehow there's 30 no votes without any explanation - and without possibility to fix it since by the time the proposer knows it the proposal is already declined. It wouldn't be very encouraging to submit RFCs with such process. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: [PHP-CVS] com php-src: Enable GCC global register variables if available: Zend/Zend.m4 Zend/zend_execute.c
We use preserved CPU registers.
According to ABI called functions have to keep them unchanged. Of course
they may save and then restore them back.
I didn't see any problems yet, however I know that some old GCC may
generate invalid code when using global registers.
Most probably we will have to limit GCC versions.
Thanks. Dmitry.
On Tue, Mar 17, 2015 at 10:25 PM, Rasmus Lerdorf ras...@lerdorf.com wrote:
Diff:
diff --git a/Zend/Zend.m4 b/Zend/Zend.m4
index 16f2d5f..e12b00d 100644
--- a/Zend/Zend.m4
+++ b/Zend/Zend.m4
@@ -409,3 +409,48 @@ else
AC_MSG_RESULT(no)
fi
fi
+
+AC_ARG_ENABLE(gcc-global-regs,
+[ --disable-gcc-global-regs
+ whether to enable GCC global register
variables],[
+ ZEND_GCC_GLOBAL_REGS=$enableval
+],[
+ ZEND_GCC_GLOBAL_REGS=yes
+])
+AC_MSG_CHECKING(for global register variables support)
+if test $ZEND_GCC_GLOBAL_REGS != no; then
+ AC_TRY_COMPILE([
+ ],[
+#if defined(__GNUC__) defined(i386)
+# define ZEND_VM_FP_GLOBAL_REG %esi
+# define ZEND_VM_IP_GLOBAL_REG %edi
+#elif defined(__GNUC__) defined(__x86_64__)
+# define ZEND_VM_FP_GLOBAL_REG %r14
+# define ZEND_VM_IP_GLOBAL_REG %r15
+#else
+# error global register variables are not supported
+#endif
+typedef int (*opcode_handler_t)(void);
+register void *FP __asm__(ZEND_VM_FP_GLOBAL_REG);
+register const opcode_handler_t *IP __asm__(ZEND_VM_IP_GLOBAL_REG);
+int emu(const opcode_handler_t *ip, void *fp) {
+ const opcode_handler_t *orig_ip = IP;
+ void *orig_fp = FP;
+ IP = ip;
+ FP = fp;
+ while ((*ip)());
+ FP = orig_fp;
+ IP = orig_ip;
+}
+ ], [
+ZEND_GCC_GLOBAL_REGS=yes
+ ], [
+ZEND_GCC_GLOBAL_REGS=no
+ ])
+fi
+if test $ZEND_GCC_GLOBAL_REGS = yes; then
+ AC_DEFINE([HAVE_GCC_GLOBAL_REGS], 1, [Define if the target system has
support for global register variables])
+else
+ HAVE_GCC_GLOBAL_REGS=no
+fi
+AC_MSG_RESULT(ZEND_GCC_GLOBAL_REGS)
Dmitry, the perf boost of this is awesome, but is it completely safe?
Won't a signal potentially overwrite a register variable here? Like on a
timeout, for example?
-Rasmus
Re: [PHP-DEV] RE: [PHP-CVS] com php-src: Enable GCC global register variables if available: Zend/Zend.m4 Zend/zend_execute.c
Hi Caio,
Could you please run make test with and without the patch and compare the
failed tests.
The patch must not add new failures.
Thanks. Dmitry.
On Tue, Mar 17, 2015 at 10:15 PM, Caio Souza Oliveira
caio.olive...@eldorado.org.br wrote:
Hello guys!
I’ve included the optimization proposed in [1] on ppc64le machines and I
could get an outstanding performance improvement of about 69% when running
bench.php (from 2.394 sec to 1.640 sec in average). I’ve tested this on
POWER 8 machines. My patch can be seen at [2]
Thank you!
Caio Souza Oliveira
[1]
https://github.com/php/php-src/commit/fb4b7069842491eb66272587422a1f61d41eb869
[2] https://github.com/php/php-src/pull/1181
--
From: Albert Casademont Filella [mailto:albertcasadem...@gmail.com]
Sent: terça-feira, 17 de março de 2015 13:23
To: Gustavo Frederico Temple Pedrosa
Cc: Dmitry Stogov; Ard Biesheuvel; PHP Internals; Leonardo Bianconi; Caio
Souza Oliveira
Subject: Re: [PHP-DEV] RE: [PHP-CVS] com php-src: Enable GCC global
register variables if available: Zend/Zend.m4 Zend/zend_execute.c
Hi Dmitry,
I can confirm a ~10-11% reduction in execution time of the bench.php from
last month build (x64) to today's commit (from 1.154 sec to 1.010). Amazing
job!
Albert
On Tue, Mar 17, 2015 at 1:39 PM, Gustavo Frederico Temple Pedrosa
gustavo.pedr...@eldorado.org.br wrote:
Hi, Dmitry.
Thank you for contacting us.
Leonardo and Caio (in CC), they will verify.
Thank you very much. Temple.
From: Dmitry Stogov [mailto:dmi...@zend.com]
Sent: terça-feira, 17 de março de 2015 08:01
To: Ard Biesheuvel; Gustavo Frederico Temple Pedrosa
Cc: PHP Internals
Subject: Fwd: [PHP-CVS] com php-src: Enable GCC global register variables
if available: Zend/Zend.m4 Zend/zend_execute.c
Hi,
Please consider possibility of using the same optimization for ARM, PPC
and may be other platforms.
On x86(_84) it makes 2-7% speedup.
Only the similar changes in zend_execute.c and Zend.m4 are required to
enable it.
Thanks. Dmitry.
-- Forwarded message --
From: Dmitry Stogov dmi...@php.net
Date: Tue, Mar 17, 2015 at 1:51 PM
Subject: [PHP-CVS] com php-src: Enable GCC global register variables if
available: Zend/Zend.m4 Zend/zend_execute.c
To: php-...@lists.php.net
Commit:fb4b7069842491eb66272587422a1f61d41eb869
Author:Dmitry Stogov dmi...@zend.com Tue, 17 Mar 2015
13:51:02 +0300
Parents: 92bf4566ea65042b8f84cae7840298ed151a4f7a
Branches: master
Link:
http://git.php.net/?p=php-src.git;a=commitdiff;h=fb4b7069842491eb66272587422a1f61d41eb869
Log:
Enable GCC global register variables if available
Changed paths:
M Zend/Zend.m4
M Zend/zend_execute.c
Diff:
diff --git a/Zend/Zend.m4 b/Zend/Zend.m4
index 16f2d5f..e12b00d 100644
--- a/Zend/Zend.m4
+++ b/Zend/Zend.m4
@@ -409,3 +409,48 @@ else
AC_MSG_RESULT(no)
fi
fi
+
+AC_ARG_ENABLE(gcc-global-regs,
+[ --disable-gcc-global-regs
+ whether to enable GCC global register
variables],[
+ ZEND_GCC_GLOBAL_REGS=$enableval
+],[
+ ZEND_GCC_GLOBAL_REGS=yes
+])
+AC_MSG_CHECKING(for global register variables support)
+if test $ZEND_GCC_GLOBAL_REGS != no; then
+ AC_TRY_COMPILE([
+ ],[
+#if defined(__GNUC__) defined(i386)
+# define ZEND_VM_FP_GLOBAL_REG %esi
+# define ZEND_VM_IP_GLOBAL_REG %edi
+#elif defined(__GNUC__) defined(__x86_64__)
+# define ZEND_VM_FP_GLOBAL_REG %r14
+# define ZEND_VM_IP_GLOBAL_REG %r15
+#else
+# error global register variables are not supported
+#endif
+typedef int (*opcode_handler_t)(void);
+register void *FP __asm__(ZEND_VM_FP_GLOBAL_REG);
+register const opcode_handler_t *IP __asm__(ZEND_VM_IP_GLOBAL_REG);
+int emu(const opcode_handler_t *ip, void *fp) {
+ const opcode_handler_t *orig_ip = IP;
+ void *orig_fp = FP;
+ IP = ip;
+ FP = fp;
+ while ((*ip)());
+ FP = orig_fp;
+ IP = orig_ip;
+}
+ ], [
+ZEND_GCC_GLOBAL_REGS=yes
+ ], [
+ZEND_GCC_GLOBAL_REGS=no
+ ])
+fi
+if test $ZEND_GCC_GLOBAL_REGS = yes; then
+ AC_DEFINE([HAVE_GCC_GLOBAL_REGS], 1, [Define if the target system has
support for global register variables])
+else
+ HAVE_GCC_GLOBAL_REGS=no
+fi
+AC_MSG_RESULT(ZEND_GCC_GLOBAL_REGS)
diff --git a/Zend/zend_execute.c b/Zend/zend_execute.c
index b24218a..17e68dc 100644
--- a/Zend/zend_execute.c
+++ b/Zend/zend_execute.c
@@ -2049,7 +2049,7 @@ static zend_always_inline void
zend_vm_stack_extend_call_frame(zend_execute_data
}
/* }}} */
-#if HAVE_GCC_GLOBAL_REGS
+#ifdef HAVE_GCC_GLOBAL_REGS
# if defined(__GNUC__) defined(i386)
# define ZEND_VM_FP_GLOBAL_REG %esi
# define ZEND_VM_IP_GLOBAL_REG %edi
--
PHP CVS Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] About declare(strict_types = 1)
On March 16, 2015 11:10:41 PM GMT+01:00, Pierre Joye pierre@gmail.com wrote: On Mar 17, 2015 7:05 AM, Peter Petermann ppeterman...@gmail.com wrote: On March 16, 2015 2:32:39 PM GMT+01:00, Pascal Chevrel pascal.chev...@free.fr wrote: It's too late, Bob's Basic STH missed the schedule for PHP 7, it was proposed way too late and the coercive STH RFC has just zero chance to pass, it's too much of a BC break for everybody. The dual mode STH is the only chance to have something for PHP 7 and remain competitive with Rushing through with an controversial solution, because others didn't make a date seems like such a good plan. No one is dying if STH doesn't make it into 7.0.0. No one will die if php dies. Your point here is totally irrelevant. PHP isn't dying without it. At least it hasn't in the last few years since it exists. HHVM, Node.js… that we see people switch to. Baidu switched to HHVM, Wikipedia too, in my country big names switched from PHP to node.js and that was not just for performance reasons, it was also for the features. hhvm offers an alternative php implementation that tries to be compatible, hack(lang) is where you find the differences you are looking for. That said, I don't see the sky falling if people who need a specific feature use another tool. The adoption rate of hack is tiny. As for nodejs, nodejs is a framework, not a language. Javascript does not offer type hints. And if you look at how to compete with nodejs, then what you should be looking at is what needs to be improved with php to allow frameworks like reactphp to work better. How to improve support for non-blocking io. And I dunno, but I don't think that per file settings make the callback-heavy code that's typical for non-blocking stuff better, in fact I'm convinced it will add an additional layer of headache. Zeev himself admitted that we need something for PHP 7. If it is THAT important for PHP 7 (and IMHO it's not) then maybe the timeline for PHP 7 needs to be reevaluated, to make sure all dependencies are the best option and not something rushed in because of ::conflict::. I think you may talk to more developers. I have talked to many, at many confs and UGs (and way too many in the last few weeks, across the pacific), I can count users not looking for STH with one hand. As I said, if you take it for THAT important, it should be in your own interest to get it right instead of rushing through a controversial compromise. Regards, PP. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Fwd: [PHP-CVS] com php-src: Enable GCC global register variables if available: Zend/Zend.m4 Zend/zend_execute.c
Hi,
Please consider possibility of using the same optimization for ARM, PPC and
may be other platforms.
On x86(_84) it makes 2-7% speedup.
Only the similar changes in zend_execute.c and Zend.m4 are required to
enable it.
Thanks. Dmitry.
-- Forwarded message --
From: Dmitry Stogov dmi...@php.net
Date: Tue, Mar 17, 2015 at 1:51 PM
Subject: [PHP-CVS] com php-src: Enable GCC global register variables if
available: Zend/Zend.m4 Zend/zend_execute.c
To: php-...@lists.php.net
Commit:fb4b7069842491eb66272587422a1f61d41eb869
Author:Dmitry Stogov dmi...@zend.com Tue, 17 Mar 2015
13:51:02 +0300
Parents: 92bf4566ea65042b8f84cae7840298ed151a4f7a
Branches: master
Link:
http://git.php.net/?p=php-src.git;a=commitdiff;h=fb4b7069842491eb66272587422a1f61d41eb869
Log:
Enable GCC global register variables if available
Changed paths:
M Zend/Zend.m4
M Zend/zend_execute.c
Diff:
diff --git a/Zend/Zend.m4 b/Zend/Zend.m4
index 16f2d5f..e12b00d 100644
--- a/Zend/Zend.m4
+++ b/Zend/Zend.m4
@@ -409,3 +409,48 @@ else
AC_MSG_RESULT(no)
fi
fi
+
+AC_ARG_ENABLE(gcc-global-regs,
+[ --disable-gcc-global-regs
+ whether to enable GCC global register
variables],[
+ ZEND_GCC_GLOBAL_REGS=$enableval
+],[
+ ZEND_GCC_GLOBAL_REGS=yes
+])
+AC_MSG_CHECKING(for global register variables support)
+if test $ZEND_GCC_GLOBAL_REGS != no; then
+ AC_TRY_COMPILE([
+ ],[
+#if defined(__GNUC__) defined(i386)
+# define ZEND_VM_FP_GLOBAL_REG %esi
+# define ZEND_VM_IP_GLOBAL_REG %edi
+#elif defined(__GNUC__) defined(__x86_64__)
+# define ZEND_VM_FP_GLOBAL_REG %r14
+# define ZEND_VM_IP_GLOBAL_REG %r15
+#else
+# error global register variables are not supported
+#endif
+typedef int (*opcode_handler_t)(void);
+register void *FP __asm__(ZEND_VM_FP_GLOBAL_REG);
+register const opcode_handler_t *IP __asm__(ZEND_VM_IP_GLOBAL_REG);
+int emu(const opcode_handler_t *ip, void *fp) {
+ const opcode_handler_t *orig_ip = IP;
+ void *orig_fp = FP;
+ IP = ip;
+ FP = fp;
+ while ((*ip)());
+ FP = orig_fp;
+ IP = orig_ip;
+}
+ ], [
+ZEND_GCC_GLOBAL_REGS=yes
+ ], [
+ZEND_GCC_GLOBAL_REGS=no
+ ])
+fi
+if test $ZEND_GCC_GLOBAL_REGS = yes; then
+ AC_DEFINE([HAVE_GCC_GLOBAL_REGS], 1, [Define if the target system has
support for global register variables])
+else
+ HAVE_GCC_GLOBAL_REGS=no
+fi
+AC_MSG_RESULT(ZEND_GCC_GLOBAL_REGS)
diff --git a/Zend/zend_execute.c b/Zend/zend_execute.c
index b24218a..17e68dc 100644
--- a/Zend/zend_execute.c
+++ b/Zend/zend_execute.c
@@ -2049,7 +2049,7 @@ static zend_always_inline void
zend_vm_stack_extend_call_frame(zend_execute_data
}
/* }}} */
-#if HAVE_GCC_GLOBAL_REGS
+#ifdef HAVE_GCC_GLOBAL_REGS
# if defined(__GNUC__) defined(i386)
# define ZEND_VM_FP_GLOBAL_REG %esi
# define ZEND_VM_IP_GLOBAL_REG %edi
--
PHP CVS Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] phar_rename_archive() bug fix for PHP7
On 17/03/15 15:55, Ralph Schindler wrote: hi all, Phar::convertTo*() methods have a design flaw such that phar files can't be successfully converted and retain the proper file suffix at the same time when the base name contains dots. An expression of this is attempting to convert something-v3.0.0.phar to say a tar.gz via convertToExecutable(Phar::TAR, Phar::GZ); My original patch respected BC when it was destined for PHP5, but now I've cleaned it up and removed the retention of BC behavior, and I intend it to be merged to PHP7 only. As such, existing tests also needed modification. I'd like some discussion, code review ... and if no objections, some karma to commit this to master. The PR is here: https://github.com/php/php-src/pull/297 Hi Ralph! I recently stumbled over that issue, too; thanks for looking into it. Looking at the patch, it seems, that some handling for bzip2 archives is missing; I think if there are special cases for .tar, .tgz and .zip, there should also be a case for .tbz2 (.tar.bz2). -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: RFC proposal, deprecate String conversion for undefined constants.
Thanks after seeing a PR with the correct wording, I finally understood what I needed to put in that last field. I feel like a robot. Also my wiki username for the internals list is: cminick Thanks for your help! On Tue, Mar 17, 2015 at 5:21 PM, Christoph Becker cmbecke...@gmx.de wrote: Admin Admin wrote: You have to enter the email address of this mailing list into the fourth field of the form. Just gave that a try, no error message. still goes back to the form. Indeed there is a bug with regard to the messages. I have submitted a PR (https://github.com/php/web-wiki/pull/4). -- Christoph M. Becker
Re: [PHP-DEV] Vote process change proposal
On Wed, Mar 18, 2015 at 10:24 AM, Stanislav Malyshev smalys...@gmail.com wrote: Hi! I think having clearer rules about what lobbying is permitted, and introducing some rules on who can vote on what would be a better way of limiting the effect of lobbying. And pretty soon we'll have 100-page law codex about rules of campaigning and campaign expenditures and what can be said to whom in which place in whose presence. All of which of course would be completely unenforceable but breed more and more allegations of violations and mistrust and gamesmanship. And this is to limit the mythical effect of lobbying the existence of which is absolutely without proof. I think this is a solution is desperate search of a non-existing problem. Let's just recognize lobbying in our case is called discussion and try to make it productive instead of disabling it. Private emails, pressure and what many, including myself, consider as harassment is a big issue in many OSS projects, and for PHP too. I am not sure what can be done to solve that but private discussions should be avoided at any price to avoid such bad things to happen. And this is the very first basic step to ensure a open, clear and fair discussion about RFC. Now, I do agree as well that discussions can be affiliated to lobbying. But the key difference is that a discussion on the list is open and should be backed with technical argument (or principles when it comes to design). Lobbying, and you know that perfectly, is totally different story. Let be straight about what is happening and do not hide our head in the sand for the sake of ignoring a growing and devastating problem. We cannot afford to loose more new contributors, no matter the reason. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Voting irregularities
hi, On Wed, Mar 18, 2015 at 9:00 AM, Hannes Magnusson hannes.magnus...@gmail.com wrote: On Tue, Mar 17, 2015 at 2:15 PM, Sebastian B.-Hagensen sbj.ml.r...@gmail.com wrote: Hi, 2015-03-17 20:55 GMT+01:00 Hannes Magnusson hannes.magnus...@gmail.com: If you need to confirm the statistics, or gather more background data, then feel free to contact me privately, off the list, and I'll get you the account approval dates (karma and/or wiki). While I agree that the issue at hand was not presented in the way it should have been may still become a valid issue in the future. If you want to prevent situations or even (wrong) ideas and accusations like these the dates of account creations have to be public and easily accessible by everyone involved (publicly listed on people.php.net for example). people.php.net are php.net karma holders. We have no responsibility to disclose any information about our contributors to anyone. It is however fun to do so, so I created people.php.net listing random info about our contributors. If you can think of other fun things to do with that website, I'd love feedback and contributions! The wiki account system is different. php.net karma holders have access out-of-the-box using their vcs credentials. Then there is a special case where you have to register to the wiki itself. Having a wiki account does nothing out-of-the-box. You have to ask for specific access. Since the inception of the wiki I have been the only one giving out wiki credentials. This has mostly been to outsiders wanting to write RFCs. I have vague memories having given 2-3 people access to https://wiki.php.net/usergroups and similar to docs and so on. These people still cannot vote. A person who maintains popular pecl extension cannot vote either, unless the extension is maintained on the php.net infrastructure (and therefore requiring php.net account) btw. There have been several members from the community that have asked for voting privileges, as per the voting rfc. I have arbitrary approved maybe 3 or 4 over the years. The other 5-10 did not get voting privileges because the authors of the voting rfc didn't care. I have absolutely no interest this voting business and and strongly disagree with the entire voting rfc idea. I would love to get back to http://producingoss.com/en/consensus-democracy.html that's your good right to disagree and I respect your opinion in that regard. However, as of today, you are the blocking point when it comes to improve the wiki RFCs, registration and voting areas.And this is really becoming a problem. I am not talking about irregularities and the likes and I agree that it may not be fair to start bitching about one or another vote, especially for some 1st time voters but oldest contributors. While I do see an issue with inactive developers suddenly jumping in but not using or contributing to PHP in any form since quite long. But this is a totally different issues and I really have no idea how to solve that, I do not see it as a big issue either so... However, the RFCs have been abused in many possible ways where I thought common sense will make people act fairly and correctly. I was wrong. Having simple technical measures to ensure fairness in discussions, voting and end of voting periods will prevent some of these abuses to happen again. It is possible to achieve that without going down a more drastic road (anonymous votes or other more deep changes) but will make things work the same way for everyone. The other problem I see, which becomes a habit for a couple of RFC authors, is the quality of the RFC. On one hand we have detailed high quality RFC, clear communications and flows and on the other hand, incomplete, confusing, lack of communications (aka missing the points of a Request for Comments completely). And this is a much more bigger worry than anything else. We have to fix that and such RFCs must be discarded or simply not accepted to vote unless they actually reach a certain quality and will to discuss. I will start another separate thread about that. Now, to be able to actually implement the little technical measure to ensure that everyone follows the same rules, I ask you one more time to provide the data of the current wiki so patches, changes etc can be implemented in a safer way. You know where to reach me to provide it. Thanks for your cooperation. 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 process change proposal
On Tue, Mar 17, 2015 at 4:24 PM, Stanislav Malyshev smalys...@gmail.com wrote: Hi! I think having clearer rules about what lobbying is permitted, and introducing some rules on who can vote on what would be a better way of limiting the effect of lobbying. And pretty soon we'll have 100-page law codex about rules of campaigning and campaign expenditures and what can be said to whom in which place in whose presence. All of which of course would be completely unenforceable but breed more and more allegations of violations and mistrust and gamesmanship. And this is to limit the mythical effect of lobbying the existence of which is absolutely without proof. I think this is a solution is desperate search of a non-existing problem. Let's just recognize lobbying in our case is called discussion and try to make it productive instead of disabling it. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php I agree that the voting process needs various improvements, censoring who voted for what is not one of them. There's nothing wrong with lobbying and trying to sway voters. In fact, that's what you're *supposed* to do if you really care about the given topic. I wouldn't want to in any way discourage that. Transparency is a greater concern, in my view. If people are just voting based on how a certain person or people voted every time, or were actually selling their votes in some fashion, that would be a concern if it were sufficiently widespread, but I'm not aware of any evidence of that. But people voting because someone persuaded them to change their mind, that's not a problem. It's a sign that the system works as intended. This particular proposal seems to me to be a solution in search of a problem. I suggest we instead focus on making improvements that would actually be beneficial. --Kris
[PHP-DEV] Re: VCS Account Request: cmb
VCS Account Approved: cmb approved by bjori \o/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Vote process change proposal
On 17.03.2015 22:37, Stanislav Malyshev wrote: While I agree with discussing an ongoing vote, I do not find it ok for people to be able to see the current status of an ongoing vote. This might lead to harassing people into voting just to change the outcome. Clear example: You frame trying to change people's mind as something negative (harassing), but that's exactly what we're doing during discussion period. If not that, we wouldn't need it - just publish RFC and go directly to vote, nobody harasses anybody with discussion. I hope you don't think it is a good idea. I think we are all adult enough to be able to handle discussion on the merits of the proposals, and if someone has enough of it, it's ok too - nobody is forced to participate. But I think openness is an important condition of participation. Sadly you're ignoring inertia/laziness/life is what happens while you're busy making other plans. Just compare the minimum number of votes/median number/(average if you must)/maximum number of votes (I bet STH got the crown now) - I don't think there was a real *need* to even alert someones friends and acquaintainces for 95% of votes. Yes, STH was exceptional now, but I bet (and maybe know?) a much smaller amount of lobbying is always in place, and still - unless you *make* people vote to appear/be active I don't see any way to avoid it - people with a strong opinion might still try to win over, others might just go this route if they think something really, really bad is happening - we'll never know unless they publicly post this call to action. TL;DR: I'd prefer no one actively trying to lobby anyone else to vote in their favor, but prodding people with a neutral hey, check out this vote you might have missed is fine, although sometimes even then you can gauge their vote, but the most active voters will probably not have overlooked it. ~Florian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Vote process change proposal
Hi! I think having clearer rules about what lobbying is permitted, and introducing some rules on who can vote on what would be a better way of limiting the effect of lobbying. And pretty soon we'll have 100-page law codex about rules of campaigning and campaign expenditures and what can be said to whom in which place in whose presence. All of which of course would be completely unenforceable but breed more and more allegations of violations and mistrust and gamesmanship. And this is to limit the mythical effect of lobbying the existence of which is absolutely without proof. I think this is a solution is desperate search of a non-existing problem. Let's just recognize lobbying in our case is called discussion and try to make it productive instead of disabling it. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Vote process change proposal
All, I wholeheartedly recommend that we don't discuss any proposals to change the voting process at this point in time. There are definitely flaws in the voting RFC and its implementation, and I think we should address them - but not right now. With the exception of the few RFCs still up for a vote - we should move our focus exclusively on getting PHP 7 out the door on time. We have at least a few months before this becomes relevant again if not more. We've also just went through a very intense vote, and we need to take some time for things to settle down dealing with complicated issues like that. Zeev -Original Message- From: Stelian Mocanita [mailto:stelian.mocan...@gmail.com] Sent: Tuesday, March 17, 2015 10:02 PM To: PHP Internals List Subject: [PHP-DEV] Vote process change proposal Hello internals, In the light of recent events, I would like to propose a change to the way we vote. The change would be switching from visible casted votes to private / hidden votes until the date/time the vote closes, at which time everything will be made visible once again. This would block voting lobbying in various social channels based on possible outcomes, and would allow voting to run its course unaltered. The people that do want to share their vote option, can still do that in the mailing list where some already justify their votes. Looking forward for your thoughts on this, Stelian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] VCS Account Request: dustin
On Mon, Mar 16, 2015 at 4:17 AM, Dustin Whtitle dustin.whit...@gmail.com wrote: Maintaining the documentation Have you seen https://edit.php.net ? I'd recommend getting involved there and or checkout php...@lists.php.net -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Vote process change proposal
Hi! people vote to appear/be active I don't see any way to avoid it - people with a strong opinion might still try to win over, others might just go this route if they think something really, really bad is happening - we'll never know unless they publicly post this call to action. So, essentially you say that people that participate have better chance of getting their way than people that are too busy to care. And that's supposed to be a bad thing? TL;DR: I'd prefer no one actively trying to lobby anyone else to vote in their favor, but prodding people with a neutral hey, check out this I'd prefer people to express their opinions and try to convince others freely, without any allegation that doing so is somehow bad and should be prohibited. If somebody feels that he/she can not objectively vote and is easily swayed by lobbying, they could recuse themselves from voting, there's no problem with that and it is easy to do. OTOH, if they think their friends do not have informed opinions and are easily swayed by lobbying, they can refrain from calling such friends to vote. But I don't see why they should prohibit normal discussion behavior for others. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: RFC proposal, deprecate String conversion for undefined constants.
Admin Admin wrote: You have to enter the email address of this mailing list into the fourth field of the form. Just gave that a try, no error message. still goes back to the form. Indeed there is a bug with regard to the messages. I have submitted a PR (https://github.com/php/web-wiki/pull/4). -- Christoph M. Becker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Vote process change proposal
I dislike the lobbying, and think some of the allgeged abusive back-channel communications are wildly out of order, but I would be against this change. There have been a couple of instances in the past few weeks where someone has voted in a particular way. When asked why they voted like that, they've explained themselves which has lead to other people realising the actual implications of an RFC, and for those people to either vote no, or switch their vote from yes to no. Aka allowing people to see votes has prevented some RFCs being approved that would have otherwise been approved. I think having clearer rules about what lobbying is permitted, and introducing some rules on who can vote on what would be a better way of limiting the effect of lobbying. cheers Dan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Vote process change proposal
On Tue, Mar 17, 2015 at 10:10 PM, Stelian Mocanita stelian.mocan...@gmail.com wrote: Why we want to block it? What's wrong in convincing people that your idea is OK (or that it's not OK, for that matter)? Isn't it kind of the whole point of discussing it? While I agree with discussing an ongoing vote, I do not find it ok for people to be able to see the current status of an ongoing vote. This might lead to harassing people into voting just to change the outcome. Clear example: The vote score is 21-7 so I know I need another vote to pass, so I call in an acquaintance or friend to vote my way. All the democratic votes I have in mind are hidden until the vote closes, and here I am referring to any election out there, or even referendum. So now parallel to voting we get threads announcing everybody's votes. Yay, more noise! Or, even worse, given current tendencies, somebody submits a proposal, couple of people say yeah good idea, then vote happens and somehow there's 30 no votes without any explanation - and without possibility to fix it since by the time the proposer knows it the proposal is already declined. It wouldn't be very encouraging to submit RFCs with such process. You misunderstood me or I did not formulate that clear enough. What I meant to say is that there are already people that go in the existing opened voting thread and explain their vote, e.g. I voted no on this because I think that won't work. I was not referring here to each one opening a thread, sorry for explaining it poorly. Stelian On Tue, Mar 17, 2015 at 9:44 PM, johnc...@gmail.com wrote: I like the current open voting better for the following reasons: 1, if we hide the votes until the vote is closed, there is also possible that some votes will pass, because people are lazy, and they will think, oh, this will surely pass/fail, no reason for me to care, then they will be surprised/disappointed. 2, similarly, if somebody is lobbying on private channels, it would be much more easier for that to go unnoticed (the usual amount of votes for an RFC to pass is something like 20-30, so if you can reach that many voters you can just keep your rfc low profile and then won. 3, there are a couple of people (mostly from the oldtimers) who can or could be able to see the votes anyways (with the current doodle voting plugin), so it could cause some accusations which we have no way to prove/refute that somebody peeked. I'm fairly sure that we could man up to not misuse those options, but I think that the risk and potential drama coming from the hidden votes would cost us more than what's it worth. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] RE: [PHP-CVS] com php-src: Enable GCC global register variables if available: Zend/Zend.m4 Zend/zend_execute.c
Please also tell your GCC version.
We had problems with 4.6.3 and 4.7.0, so we disabled global variables for
GCC prior 4.8.0.
Thanks. Dmitry.
On Wed, Mar 18, 2015 at 12:36 AM, Dmitry Stogov dmi...@zend.com wrote:
Hi Caio,
Could you please run make test with and without the patch and compare
the failed tests.
The patch must not add new failures.
Thanks. Dmitry.
On Tue, Mar 17, 2015 at 10:15 PM, Caio Souza Oliveira
caio.olive...@eldorado.org.br wrote:
Hello guys!
I’ve included the optimization proposed in [1] on ppc64le machines and I
could get an outstanding performance improvement of about 69% when running
bench.php (from 2.394 sec to 1.640 sec in average). I’ve tested this on
POWER 8 machines. My patch can be seen at [2]
Thank you!
Caio Souza Oliveira
[1]
https://github.com/php/php-src/commit/fb4b7069842491eb66272587422a1f61d41eb869
[2] https://github.com/php/php-src/pull/1181
--
From: Albert Casademont Filella [mailto:albertcasadem...@gmail.com]
Sent: terça-feira, 17 de março de 2015 13:23
To: Gustavo Frederico Temple Pedrosa
Cc: Dmitry Stogov; Ard Biesheuvel; PHP Internals; Leonardo Bianconi; Caio
Souza Oliveira
Subject: Re: [PHP-DEV] RE: [PHP-CVS] com php-src: Enable GCC global
register variables if available: Zend/Zend.m4 Zend/zend_execute.c
Hi Dmitry,
I can confirm a ~10-11% reduction in execution time of the bench.php from
last month build (x64) to today's commit (from 1.154 sec to 1.010). Amazing
job!
Albert
On Tue, Mar 17, 2015 at 1:39 PM, Gustavo Frederico Temple Pedrosa
gustavo.pedr...@eldorado.org.br wrote:
Hi, Dmitry.
Thank you for contacting us.
Leonardo and Caio (in CC), they will verify.
Thank you very much. Temple.
From: Dmitry Stogov [mailto:dmi...@zend.com]
Sent: terça-feira, 17 de março de 2015 08:01
To: Ard Biesheuvel; Gustavo Frederico Temple Pedrosa
Cc: PHP Internals
Subject: Fwd: [PHP-CVS] com php-src: Enable GCC global register variables
if available: Zend/Zend.m4 Zend/zend_execute.c
Hi,
Please consider possibility of using the same optimization for ARM, PPC
and may be other platforms.
On x86(_84) it makes 2-7% speedup.
Only the similar changes in zend_execute.c and Zend.m4 are required to
enable it.
Thanks. Dmitry.
-- Forwarded message --
From: Dmitry Stogov dmi...@php.net
Date: Tue, Mar 17, 2015 at 1:51 PM
Subject: [PHP-CVS] com php-src: Enable GCC global register variables if
available: Zend/Zend.m4 Zend/zend_execute.c
To: php-...@lists.php.net
Commit:fb4b7069842491eb66272587422a1f61d41eb869
Author:Dmitry Stogov dmi...@zend.com Tue, 17 Mar 2015
13:51:02 +0300
Parents: 92bf4566ea65042b8f84cae7840298ed151a4f7a
Branches: master
Link:
http://git.php.net/?p=php-src.git;a=commitdiff;h=fb4b7069842491eb66272587422a1f61d41eb869
Log:
Enable GCC global register variables if available
Changed paths:
M Zend/Zend.m4
M Zend/zend_execute.c
Diff:
diff --git a/Zend/Zend.m4 b/Zend/Zend.m4
index 16f2d5f..e12b00d 100644
--- a/Zend/Zend.m4
+++ b/Zend/Zend.m4
@@ -409,3 +409,48 @@ else
AC_MSG_RESULT(no)
fi
fi
+
+AC_ARG_ENABLE(gcc-global-regs,
+[ --disable-gcc-global-regs
+ whether to enable GCC global register
variables],[
+ ZEND_GCC_GLOBAL_REGS=$enableval
+],[
+ ZEND_GCC_GLOBAL_REGS=yes
+])
+AC_MSG_CHECKING(for global register variables support)
+if test $ZEND_GCC_GLOBAL_REGS != no; then
+ AC_TRY_COMPILE([
+ ],[
+#if defined(__GNUC__) defined(i386)
+# define ZEND_VM_FP_GLOBAL_REG %esi
+# define ZEND_VM_IP_GLOBAL_REG %edi
+#elif defined(__GNUC__) defined(__x86_64__)
+# define ZEND_VM_FP_GLOBAL_REG %r14
+# define ZEND_VM_IP_GLOBAL_REG %r15
+#else
+# error global register variables are not supported
+#endif
+typedef int (*opcode_handler_t)(void);
+register void *FP __asm__(ZEND_VM_FP_GLOBAL_REG);
+register const opcode_handler_t *IP __asm__(ZEND_VM_IP_GLOBAL_REG);
+int emu(const opcode_handler_t *ip, void *fp) {
+ const opcode_handler_t *orig_ip = IP;
+ void *orig_fp = FP;
+ IP = ip;
+ FP = fp;
+ while ((*ip)());
+ FP = orig_fp;
+ IP = orig_ip;
+}
+ ], [
+ZEND_GCC_GLOBAL_REGS=yes
+ ], [
+ZEND_GCC_GLOBAL_REGS=no
+ ])
+fi
+if test $ZEND_GCC_GLOBAL_REGS = yes; then
+ AC_DEFINE([HAVE_GCC_GLOBAL_REGS], 1, [Define if the target system has
support for global register variables])
+else
+ HAVE_GCC_GLOBAL_REGS=no
+fi
+AC_MSG_RESULT(ZEND_GCC_GLOBAL_REGS)
diff --git a/Zend/zend_execute.c b/Zend/zend_execute.c
index b24218a..17e68dc 100644
--- a/Zend/zend_execute.c
+++ b/Zend/zend_execute.c
@@ -2049,7 +2049,7 @@ static zend_always_inline void
zend_vm_stack_extend_call_frame(zend_execute_data
}
/* }}} */
-#if HAVE_GCC_GLOBAL_REGS
+#ifdef HAVE_GCC_GLOBAL_REGS
# if defined(__GNUC__) defined(i386)
# define ZEND_VM_FP_GLOBAL_REG %esi
# define ZEND_VM_IP_GLOBAL_REG %edi
--
PHP CVS Mailing List
Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5
On Mar 17, 2015, at 18:04 , Leigh lei...@gmail.com wrote: On 17 March 2015 at 08:37, Lester Caine les...@lsces.co.uk wrote: To help towards that end, can someone who understands what is wanted from the weak type hint mode actually produce a summary of that as it is very difficult to extract just what has now been agreed for that area of type hinting. A base that can be used to review some of the other discussions to put that to bed. Others might appreciate a similar summary of the 'type_error' mode as well? As a base for the documentation on the user manual updates? Not sure what is difficult to extract https://wiki.php.net/rfc/scalar_type_hints_v5#behaviour_of_weak_type_checks It's all right there... That part answers what has been agreed (or rather accepted), but not who the weak mode is for, and why. Tried to sum that up last week when there was still discussions on this: http://share.ez.no/blogs/core-development-team/php-7-sth-from-user-perspective TL;DR; weak mode is for api consumers, aka normal php users, while strict is for the actual target users of this features: api (library/framework) creators. Post also argues for why Zeev's adjustments to weak sth handling should still be done, as well as arguing for disallowing/fixing closure hint in strict mode. ar -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Vote process change proposal
Hello Stelian, just FYI: it was proposed in the past and even implemenented [1], but then reverted [2]. However, I don't remember reasoning back then. Regards, Maciej. [1]: https://github.com/php/web-wiki/pull/1 [2]: https://github.com/php/web-wiki/commit/19ca75aa1e06b3c5ad9a61204bbc34189368f02b W dniu 2015-03-17 o 21:02, Stelian Mocanita pisze: Hello internals, In the light of recent events, I would like to propose a change to the way we vote. The change would be switching from visible casted votes to private / hidden votes until the date/time the vote closes, at which time everything will be made visible once again. This would block voting lobbying in various social channels based on possible outcomes, and would allow voting to run its course unaltered. The people that do want to share their vote option, can still do that in the mailing list where some already justify their votes. Looking forward for your thoughts on this, Stelian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Voting irregularities
On Sun, Mar 15, 2015 at 7:19 AM, Anthony Ferrara ircmax...@gmail.com wrote: All, I ran some numbers on the current votes of the dual-mode vote right now. There were a number of voters that I didn't recognize. So I decided to pull some stats. The following voters never voted before the dual-mode RFC went up: To minimize noise on this list I would appreciate if you stay on topic, your blog is a better venue then this list. If you need to confirm the statistics, or gather more background data, then feel free to contact me privately, off the list, and I'll get you the account approval dates (karma and/or wiki). Thanks! -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: [PHP-CVS] com php-src: Enable GCC global register variables if available: Zend/Zend.m4 Zend/zend_execute.c
Hi! Dmitry, the perf boost of this is awesome, but is it completely safe? Won't a signal potentially overwrite a register variable here? Like on a timeout, for example? The docs say (http://gcc.gnu.org/onlinedocs/gcc/Global-Reg-Vars.html): It is not safe to access the global register variables from signal handlers, or from more than one thread of control, because the system library routines may temporarily use the register for other things (unless you recompile them specially for the task at hand). Also: It is not safe for one function that uses a global register variable to call another such function foo by way of a third function lose that is compiled without knowledge of this variable (i.e. in a different source file in which the variable isn't declared). This is because lose might save the register and put some other value there. For example, you can't expect a global register variable to be available in the comparison-function that you pass to qsort, since qsort might have put something else in that register. (If you are prepared to recompile qsort with the same global register variable, you can solve this problem.) So, I wonder how that would work with loadable modules and external libraries that could use PHP callbacks. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Vote process change proposal
Hello internals, In the light of recent events, I would like to propose a change to the way we vote. The change would be switching from visible casted votes to private / hidden votes until the date/time the vote closes, at which time everything will be made visible once again. This would block voting lobbying in various social channels based on possible outcomes, and would allow voting to run its course unaltered. The people that do want to share their vote option, can still do that in the mailing list where some already justify their votes. Looking forward for your thoughts on this, Stelian
Re: [PHP-DEV] RE: [PHP-CVS] com php-src: Enable GCC global register variables if available: Zend/Zend.m4 Zend/zend_execute.c
Diff:
diff --git a/Zend/Zend.m4 b/Zend/Zend.m4
index 16f2d5f..e12b00d 100644
--- a/Zend/Zend.m4
+++ b/Zend/Zend.m4
@@ -409,3 +409,48 @@ else
AC_MSG_RESULT(no)
fi
fi
+
+AC_ARG_ENABLE(gcc-global-regs,
+[ --disable-gcc-global-regs
+ whether to enable GCC global register
variables],[
+ ZEND_GCC_GLOBAL_REGS=$enableval
+],[
+ ZEND_GCC_GLOBAL_REGS=yes
+])
+AC_MSG_CHECKING(for global register variables support)
+if test $ZEND_GCC_GLOBAL_REGS != no; then
+ AC_TRY_COMPILE([
+ ],[
+#if defined(__GNUC__) defined(i386)
+# define ZEND_VM_FP_GLOBAL_REG %esi
+# define ZEND_VM_IP_GLOBAL_REG %edi
+#elif defined(__GNUC__) defined(__x86_64__)
+# define ZEND_VM_FP_GLOBAL_REG %r14
+# define ZEND_VM_IP_GLOBAL_REG %r15
+#else
+# error global register variables are not supported
+#endif
+typedef int (*opcode_handler_t)(void);
+register void *FP __asm__(ZEND_VM_FP_GLOBAL_REG);
+register const opcode_handler_t *IP __asm__(ZEND_VM_IP_GLOBAL_REG);
+int emu(const opcode_handler_t *ip, void *fp) {
+ const opcode_handler_t *orig_ip = IP;
+ void *orig_fp = FP;
+ IP = ip;
+ FP = fp;
+ while ((*ip)());
+ FP = orig_fp;
+ IP = orig_ip;
+}
+ ], [
+ZEND_GCC_GLOBAL_REGS=yes
+ ], [
+ZEND_GCC_GLOBAL_REGS=no
+ ])
+fi
+if test $ZEND_GCC_GLOBAL_REGS = yes; then
+ AC_DEFINE([HAVE_GCC_GLOBAL_REGS], 1, [Define if the target system has
support for global register variables])
+else
+ HAVE_GCC_GLOBAL_REGS=no
+fi
+AC_MSG_RESULT(ZEND_GCC_GLOBAL_REGS)
Dmitry, the perf boost of this is awesome, but is it completely safe?
Won't a signal potentially overwrite a register variable here? Like on a
timeout, for example?
-Rasmus
signature.asc
Description: OpenPGP digital signature
Re: [PHP-DEV] Vote process change proposal
Hi! This would block voting lobbying in various social channels based on possible outcomes, and would allow voting to run its course unaltered. The people Why we want to block it? What's wrong in convincing people that your idea is OK (or that it's not OK, for that matter)? Isn't it kind of the whole point of discussing it? want to share their vote option, can still do that in the mailing list where some already justify their votes. So now parallel to voting we get threads announcing everybody's votes. Yay, more noise! Or, even worse, given current tendencies, somebody submits a proposal, couple of people say yeah good idea, then vote happens and somehow there's 30 no votes without any explanation - and without possibility to fix it since by the time the proposer knows it the proposal is already declined. It wouldn't be very encouraging to submit RFCs with such process. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Vote process change proposal
I see absolutely no issues with the visibility of votes, or the act of “lobbying” for someone’s vote. On Tue, Mar 17, 2015 at 4:36 PM, Stanislav Malyshev smalys...@gmail.com wrote: Hi! This would block voting lobbying in various social channels based on possible outcomes, and would allow voting to run its course unaltered. The people Why we want to block it? What's wrong in convincing people that your idea is OK (or that it's not OK, for that matter)? Isn't it kind of the whole point of discussing it? want to share their vote option, can still do that in the mailing list where some already justify their votes. So now parallel to voting we get threads announcing everybody's votes. Yay, more noise! Or, even worse, given current tendencies, somebody submits a proposal, couple of people say yeah good idea, then vote happens and somehow there's 30 no votes without any explanation - and without possibility to fix it since by the time the proposer knows it the proposal is already declined. It wouldn't be very encouraging to submit RFCs with such process. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RE: [PHP-CVS] com php-src: Enable GCC global register variables if available: Zend/Zend.m4 Zend/zend_execute.c
Hi, Dmitry.
Thank you for contacting us.
Leonardo and Caio (in CC), they will verify.
Thank you very much. Temple.
From: Dmitry Stogov [mailto:dmi...@zend.com]
Sent: terça-feira, 17 de março de 2015 08:01
To: Ard Biesheuvel; Gustavo Frederico Temple Pedrosa
Cc: PHP Internals
Subject: Fwd: [PHP-CVS] com php-src: Enable GCC global register variables if
available: Zend/Zend.m4 Zend/zend_execute.c
Hi,
Please consider possibility of using the same optimization for ARM, PPC and may
be other platforms.
On x86(_84) it makes 2-7% speedup.
Only the similar changes in zend_execute.c and Zend.m4 are required to enable
it.
Thanks. Dmitry.
-- Forwarded message --
From: Dmitry Stogov dmi...@php.net
Date: Tue, Mar 17, 2015 at 1:51 PM
Subject: [PHP-CVS] com php-src: Enable GCC global register variables if
available: Zend/Zend.m4 Zend/zend_execute.c
To: php-...@lists.php.net
Commit: fb4b7069842491eb66272587422a1f61d41eb869
Author: Dmitry Stogov dmi...@zend.com Tue, 17 Mar 2015 13:51:02
+0300
Parents: 92bf4566ea65042b8f84cae7840298ed151a4f7a
Branches: master
Link:
http://git.php.net/?p=php-src.git;a=commitdiff;h=fb4b7069842491eb66272587422a1f61d41eb869
Log:
Enable GCC global register variables if available
Changed paths:
M Zend/Zend.m4
M Zend/zend_execute.c
Diff:
diff --git a/Zend/Zend.m4 b/Zend/Zend.m4
index 16f2d5f..e12b00d 100644
--- a/Zend/Zend.m4
+++ b/Zend/Zend.m4
@@ -409,3 +409,48 @@ else
AC_MSG_RESULT(no)
fi
fi
+
+AC_ARG_ENABLE(gcc-global-regs,
+[ --disable-gcc-global-regs
+ whether to enable GCC global register variables],[
+ ZEND_GCC_GLOBAL_REGS=$enableval
+],[
+ ZEND_GCC_GLOBAL_REGS=yes
+])
+AC_MSG_CHECKING(for global register variables support)
+if test $ZEND_GCC_GLOBAL_REGS != no; then
+ AC_TRY_COMPILE([
+ ],[
+#if defined(__GNUC__) defined(i386)
+# define ZEND_VM_FP_GLOBAL_REG %esi
+# define ZEND_VM_IP_GLOBAL_REG %edi
+#elif defined(__GNUC__) defined(__x86_64__)
+# define ZEND_VM_FP_GLOBAL_REG %r14
+# define ZEND_VM_IP_GLOBAL_REG %r15
+#else
+# error global register variables are not supported
+#endif
+typedef int (*opcode_handler_t)(void);
+register void *FP __asm__(ZEND_VM_FP_GLOBAL_REG);
+register const opcode_handler_t *IP __asm__(ZEND_VM_IP_GLOBAL_REG);
+int emu(const opcode_handler_t *ip, void *fp) {
+ const opcode_handler_t *orig_ip = IP;
+ void *orig_fp = FP;
+ IP = ip;
+ FP = fp;
+ while ((*ip)());
+ FP = orig_fp;
+ IP = orig_ip;
+}
+ ], [
+ ZEND_GCC_GLOBAL_REGS=yes
+ ], [
+ ZEND_GCC_GLOBAL_REGS=no
+ ])
+fi
+if test $ZEND_GCC_GLOBAL_REGS = yes; then
+ AC_DEFINE([HAVE_GCC_GLOBAL_REGS], 1, [Define if the target system has
support for global register variables])
+else
+ HAVE_GCC_GLOBAL_REGS=no
+fi
+AC_MSG_RESULT(ZEND_GCC_GLOBAL_REGS)
diff --git a/Zend/zend_execute.c b/Zend/zend_execute.c
index b24218a..17e68dc 100644
--- a/Zend/zend_execute.c
+++ b/Zend/zend_execute.c
@@ -2049,7 +2049,7 @@ static zend_always_inline void
zend_vm_stack_extend_call_frame(zend_execute_data
}
/* }}} */
-#if HAVE_GCC_GLOBAL_REGS
+#ifdef HAVE_GCC_GLOBAL_REGS
# if defined(__GNUC__) defined(i386)
# define ZEND_VM_FP_GLOBAL_REG %esi
# define ZEND_VM_IP_GLOBAL_REG %edi
--
PHP CVS Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Streams BC break unfixed since 5.6.5
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 17/03/2015 14:12, Jan Schneider a écrit : Hello, now that RFCing has settled down a bit, and things should get back to more development and less politics, can someone please take a look at this regression: https://bugs.php.net/bug.php?id=68948 that has a PR here: https://github.com/php/php-src/pull/1153 This BC breaking regression is breaking real world applications since two 5.5 and 5.6 releases (http://3v4l.org/YJRWQ) and the fix is ready to merge, at least to the master branch. For memory, this have been detected during 5.5.21RC on Jan 11th and reported to internal http://news.php.net/php.internals/80363 http://news.php.net/php.internals/80410 And also reported to affected projects, i.e. Guzzle and Horde (Jan 10th) Answer from horde developer (slusarz): I think the current (fixed) behavior is correct. My implementation of the filter was actually wrong in that it assumed that the filter would only be called once with a single bucket. From a practical standpoint, this didn't make a difference because strings that we need to quote, at least in Horde_Imap_Client, are so short ( 50 characters) that the filter never saw more than 1 bucket in everyday usage. But theoretically, if someone was using the filter to quote a long string, the previous Horde_Imap_Client_Data_Format_Filter_Quote would have been broken before my fix. I'm very disappointed by this, by the lack of interested by my initial heads-up message, by lack of reaction from upstream project, and this very late request for revert. Remi. Thanks for looking into this, Jan. -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlUILFAACgkQYUppBSnxahhtqQCg525E7cZvIPB6XIv0ux/YRkst 9TAAoPU2qLdlyNo98EKK8EkuHrPZ7d+r =BSgH -END PGP SIGNATURE- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Streams BC break unfixed since 5.6.5
Hello, now that RFCing has settled down a bit, and things should get back to more development and less politics, can someone please take a look at this regression: https://bugs.php.net/bug.php?id=68948 that has a PR here: https://github.com/php/php-src/pull/1153 This BC breaking regression is breaking real world applications since two 5.5 and 5.6 releases (http://3v4l.org/YJRWQ) and the fix is ready to merge, at least to the master branch. Thanks for looking into this, Jan. -- Jan Schneider The Horde Project http://www.horde.org/ https://www.facebook.com/hordeproject -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [RFC RESULT] Generator Return Expressions
The Generator Return Expressions RFC vote has concluded with the following results: YES: 32 NO: 0 https://wiki.php.net/rfc/generator-return-expressions#vote Thank you again to everyone who took time to read and consider the proposal. The associated patch will be merged into master in the coming days. Regards, Daniel
[PHP-DEV] phar_rename_archive() bug fix for PHP7
hi all, Phar::convertTo*() methods have a design flaw such that phar files can't be successfully converted and retain the proper file suffix at the same time when the base name contains dots. An expression of this is attempting to convert something-v3.0.0.phar to say a tar.gz via convertToExecutable(Phar::TAR, Phar::GZ); My original patch respected BC when it was destined for PHP5, but now I've cleaned it up and removed the retention of BC behavior, and I intend it to be merged to PHP7 only. As such, existing tests also needed modification. I'd like some discussion, code review ... and if no objections, some karma to commit this to master. The PR is here: https://github.com/php/php-src/pull/297 Thanks, Ralph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: [PHP-CVS] com php-src: Enable GCC global register variables if available: Zend/Zend.m4 Zend/zend_execute.c
Hi Dmitry,
I can confirm a ~10-11% reduction in execution time of the bench.php from
last month build (x64) to today's commit (from 1.154 sec to 1.010). Amazing
job!
Albert
On Tue, Mar 17, 2015 at 1:39 PM, Gustavo Frederico Temple Pedrosa
gustavo.pedr...@eldorado.org.br wrote:
Hi, Dmitry.
Thank you for contacting us.
Leonardo and Caio (in CC), they will verify.
Thank you very much. Temple.
From: Dmitry Stogov [mailto:dmi...@zend.com]
Sent: terça-feira, 17 de março de 2015 08:01
To: Ard Biesheuvel; Gustavo Frederico Temple Pedrosa
Cc: PHP Internals
Subject: Fwd: [PHP-CVS] com php-src: Enable GCC global register variables
if available: Zend/Zend.m4 Zend/zend_execute.c
Hi,
Please consider possibility of using the same optimization for ARM, PPC
and may be other platforms.
On x86(_84) it makes 2-7% speedup.
Only the similar changes in zend_execute.c and Zend.m4 are required to
enable it.
Thanks. Dmitry.
-- Forwarded message --
From: Dmitry Stogov dmi...@php.net
Date: Tue, Mar 17, 2015 at 1:51 PM
Subject: [PHP-CVS] com php-src: Enable GCC global register variables if
available: Zend/Zend.m4 Zend/zend_execute.c
To: php-...@lists.php.net
Commit:fb4b7069842491eb66272587422a1f61d41eb869
Author:Dmitry Stogov dmi...@zend.com Tue, 17 Mar 2015
13:51:02 +0300
Parents: 92bf4566ea65042b8f84cae7840298ed151a4f7a
Branches: master
Link:
http://git.php.net/?p=php-src.git;a=commitdiff;h=fb4b7069842491eb66272587422a1f61d41eb869
Log:
Enable GCC global register variables if available
Changed paths:
M Zend/Zend.m4
M Zend/zend_execute.c
Diff:
diff --git a/Zend/Zend.m4 b/Zend/Zend.m4
index 16f2d5f..e12b00d 100644
--- a/Zend/Zend.m4
+++ b/Zend/Zend.m4
@@ -409,3 +409,48 @@ else
AC_MSG_RESULT(no)
fi
fi
+
+AC_ARG_ENABLE(gcc-global-regs,
+[ --disable-gcc-global-regs
+ whether to enable GCC global register
variables],[
+ ZEND_GCC_GLOBAL_REGS=$enableval
+],[
+ ZEND_GCC_GLOBAL_REGS=yes
+])
+AC_MSG_CHECKING(for global register variables support)
+if test $ZEND_GCC_GLOBAL_REGS != no; then
+ AC_TRY_COMPILE([
+ ],[
+#if defined(__GNUC__) defined(i386)
+# define ZEND_VM_FP_GLOBAL_REG %esi
+# define ZEND_VM_IP_GLOBAL_REG %edi
+#elif defined(__GNUC__) defined(__x86_64__)
+# define ZEND_VM_FP_GLOBAL_REG %r14
+# define ZEND_VM_IP_GLOBAL_REG %r15
+#else
+# error global register variables are not supported
+#endif
+typedef int (*opcode_handler_t)(void);
+register void *FP __asm__(ZEND_VM_FP_GLOBAL_REG);
+register const opcode_handler_t *IP __asm__(ZEND_VM_IP_GLOBAL_REG);
+int emu(const opcode_handler_t *ip, void *fp) {
+ const opcode_handler_t *orig_ip = IP;
+ void *orig_fp = FP;
+ IP = ip;
+ FP = fp;
+ while ((*ip)());
+ FP = orig_fp;
+ IP = orig_ip;
+}
+ ], [
+ZEND_GCC_GLOBAL_REGS=yes
+ ], [
+ZEND_GCC_GLOBAL_REGS=no
+ ])
+fi
+if test $ZEND_GCC_GLOBAL_REGS = yes; then
+ AC_DEFINE([HAVE_GCC_GLOBAL_REGS], 1, [Define if the target system has
support for global register variables])
+else
+ HAVE_GCC_GLOBAL_REGS=no
+fi
+AC_MSG_RESULT(ZEND_GCC_GLOBAL_REGS)
diff --git a/Zend/zend_execute.c b/Zend/zend_execute.c
index b24218a..17e68dc 100644
--- a/Zend/zend_execute.c
+++ b/Zend/zend_execute.c
@@ -2049,7 +2049,7 @@ static zend_always_inline void
zend_vm_stack_extend_call_frame(zend_execute_data
}
/* }}} */
-#if HAVE_GCC_GLOBAL_REGS
+#ifdef HAVE_GCC_GLOBAL_REGS
# if defined(__GNUC__) defined(i386)
# define ZEND_VM_FP_GLOBAL_REG %esi
# define ZEND_VM_IP_GLOBAL_REG %edi
--
PHP CVS Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5
On 17 March 2015 at 08:37, Lester Caine les...@lsces.co.uk wrote: To help towards that end, can someone who understands what is wanted from the weak type hint mode actually produce a summary of that as it is very difficult to extract just what has now been agreed for that area of type hinting. A base that can be used to review some of the other discussions to put that to bed. Others might appreciate a similar summary of the 'type_error' mode as well? As a base for the documentation on the user manual updates? Not sure what is difficult to extract https://wiki.php.net/rfc/scalar_type_hints_v5#behaviour_of_weak_type_checks It's all right there...
Re: [PHP-DEV] Vote process change proposal
Hi! Repeatedly, explicitly, strongly asking to shut down a RFC or general proposal is what I consider as harassment. Even more if prominent figures do it. As I suspected, your definition of harassment is very different from mine. If someone would ask me to shutdown RFC without explanation, I'd just ignore it, with explanation - I may discuss it, but I don't see how it qualifies as harassment. But I have the damn right to say that most of the times private, extensive, and long discussions to finalize damage OSS projects. And recent events here tell me that I am right to think so. You have full right to say it, but if you expect this to be believed, you'd need some proof. I must note despite my pleas, no substantiation of ominous but vague statements about what is happening and devastating problem has been provided. Now, you can convince me by actually me explaining cases where private, extensive long discussions are actually good and I will proudly change my mind. I can only base on my own experience, but in PHP world when I participated in namespaces work, I've held both public and private discussions with a lot of people. Both kinds were very useful. When we started 5.4, I remember private discussion with one very active and prominent project participant, who I'm sure you know too. I am not sure if you consider that one good or not, and probably doesn't qualify as extensive long, but on my side I think it helped to move the project further. I'm sure I could remember more examples, but given the lack of proof so far that there is any damage from occasional private discussion, I think that's enough for now. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
