[PHP-DEV] SipHash
I recently came across SipHash [1] (which is a family of pseudorandom functions (a.k.a. keyed hash functions) optimized for speed on short messages) and am wondering whether it would make sense to add support for it to PHP. Thoughts? -- [1] https://131002.net/siphash/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SipHash
On Thu, Aug 28, 2014 at 10:00 AM, Sebastian Bergmann sebast...@php.net wrote: I recently came across SipHash [1] (which is a family of pseudorandom functions (a.k.a. keyed hash functions) optimized for speed on short messages) and am wondering whether it would make sense to add support for it to PHP. Thoughts? ext/hash can have it anyway. I did not look at it if it makes sense to use it in other parts. -- 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] SipHash
Am 28.08.2014 um 10:04 schrieb Pierre Joye: ext/hash can have it anyway. I did not look at it if it makes sense to use it in other parts. Sorry for not bein more clear: yes, I was thinking about adding it to ext/hash, of course. It might make sense, though, to evaluate whether it can also be used internally. Other languages seem to have switched their hashtable implementation to SipHash. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP 5.6.0 final has been released!
Hello! The PHP Development Team would like to announce the immediate release of PHP 5.6.0. This release includes a large number of new features and bug fixes. A separate release announcement is also available. For changes in PHP 5.6.0 since PHP 5.5, please consult the PHP 5 ChangeLog. Release Announcement: http://php.net/releases/5_6_0.php Downloads:http://www.php.net/downloads.php#v5.6 Changelog:http://www.php.net/ChangeLog-5.php#5.6.0 Thanks to all contributors that made this new version available. regards, Julien Pauli Ferenc Kovacs
Re: [PHP-DEV] Merges between PHP5 and PHP7
On Fri, 22 Aug 2014, Derick Rethans wrote: On Fri, 22 Aug 2014, Anatol Belski wrote: as there are many data type changes, here's an idea on how to simplify the merges. Git supports custom merge drivers which attracted my attention, so I've ended up with the following trick: As there are that many differences, does it still make sense to GIT merge PHP 5 changes up to 7 at all? Shouldn't we just do it by hand. I would expect that to have a much greater rate of success. Really, no comments about this at all? cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Merges between PHP5 and PHP7
Just implement and show it working, then i'd say the guys will react. 28 авг. 2014 г. 18:24 пользователь Derick Rethans der...@php.net написал: On Fri, 22 Aug 2014, Derick Rethans wrote: On Fri, 22 Aug 2014, Anatol Belski wrote: as there are many data type changes, here's an idea on how to simplify the merges. Git supports custom merge drivers which attracted my attention, so I've ended up with the following trick: As there are that many differences, does it still make sense to GIT merge PHP 5 changes up to 7 at all? Shouldn't we just do it by hand. I would expect that to have a much greater rate of success. Really, no comments about this at all? cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Integer Semantics
On 22 Aug 2014, at 12:36, Derick Rethans der...@php.net wrote: Although I think it is good to make it work the same on every platform, I do think that changing it to *match* what the most used compiler (GCC) on our most used platform (Linux/AMD64) is what the new behaviour should be like — not something that looks best. I think that's what Laruence was trying to say as well. It causes the least amount of BC breaks for our users. That would also be a possibility. It’s not my favourite behaviour, but it’d at least be consistent. However, I wonder how many applications rely on the current behaviour on AMD64. It’s not terribly intuitive. For example, a shift by a negative number works like this on AMD64: $op1 ((PHP_INT_MAX + $op2) % 64) So, for example, were I to make $op2 be -1: $op1 ((PHP_INT_MAX + $op2) % 64) $op1 ((PHP_INT_MAX - 1) % 64) $op1 (9223372036854775806 % 64) $op1 62 Which is probably not what the user was expecting. Actually, I kinda lied, that’s just what *sane* compilers would do on AMD64. Negative bit shifts are undefined behaviour in the C standard, which gives the compiler an unlimited license to do absolutely anything it wants, including, for example, to not execute the shift altogether and assume it is dead code. In practise this is unlikely, however that is the standard. You make a good point that this is a BC break, though. This RFC in itself doesn’t make a super-compelling case, given it doesn’t really introduce any benefits (aside from the fact you can rely on $x $y, where $y = 64, equalling zero). It might be better if I retracted this RFC and kept these changes to the bigint RFC. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SipHash
On Thu, 2014-08-28 at 10:07 +0200, Sebastian Bergmann wrote: Am 28.08.2014 um 10:04 schrieb Pierre Joye: ext/hash can have it anyway. I did not look at it if it makes sense to use it in other parts. Sorry for not bein more clear: yes, I was thinking about adding it to ext/hash, of course. It might make sense, though, to evaluate whether it can also be used internally. Other languages seem to have switched their hashtable implementation to SipHash. Try it out. Mind that we are doing quite few more hash operations than other languages. I doubt barely anybody here has the maths background to predict impact on hash calculation performance and conflict ratio and even then only a test and analysis of different benchmarks will tell the truth. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Cleaning 5.3 git branches ?
Hello, We all know 5.3 is now EOL. Looking at git branches, 5.0, 5.1 and 5.2 still have their respective main branches (which is all right and good). However, they dont have their release branch references (5.1.1 , 5.1.2 etc...) , however they still show their own release tags, which is also all right. As a reminder, release *branches* (not the tags) are used by the RMs to actually release the version. RMs branch from the main repo into a release branch, and apply their RM-managing-stuff commits as well as backport eventual commits from the main branch, for CVEs, for example. Those release branches are here just for the release, and are no longer needed at all after the release has been released, because every release owns its own final git tag. The tag is written lowercased (php-5.5.4) and the branch is written uppercased (PHP-5.5.4). What I suggest, is removing those branch references from our git, for EOL versions of PHP. This is done for PHP=5.2 (but that was before the move to git) , but PHP5.3 release branches are still referenced. Of course references in git are very light things, but they tend to pollute the references. For example , browsing our branches in the github mirror select box is a pain nowadays. Same for git command line autocompletion that shows every remote branches, or the git branch --all command , and its friends. I already sent a mail, few months ago, to clean the branches we dont use any more. Some argued that for history, they should be kept referenced. But, thoughts to clean *release branches* from our git for *EOL PHP versions*, like 5.3 ? Tag references should be enough for history, IMHO Julien.P -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Cleaning 5.3 git branches ?
On 28 Aug 2014, at 19:55, Julien Pauli jpa...@php.net wrote: But, thoughts to clean *release branches* from our git for *EOL PHP versions*, like 5.3 ? Tag references should be enough for history, IMHO It’s my understanding that a tag is merely an immutable branch (or a branch is merely a mutable tag), so I’d be completely in favour of this. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Merges between PHP5 and PHP7
On Aug 22, 2014 1:39 PM, Derick Rethans der...@php.net wrote: On Fri, 22 Aug 2014, Anatol Belski wrote: as there are many data type changes, here's an idea on how to simplify the merges. Git supports custom merge drivers which attracted my attention, so I've ended up with the following trick: As there are that many differences, does it still make sense to GIT merge PHP 5 changes up to 7 at all? Shouldn't we just do it by hand. I would expect that to have a much greater rate of success. I brought this topic a while back too. The same issue happens for pecl extensions. The more exts I do the more I think about either using separate branches or separate source files, respectively separate realeses or common release for both 5.x and 7.x. For the core, I have the feeling than manual merges will be far less painful. Cheers, Pierre
Re: [PHP-DEV] Cleaning 5.3 git branches ?
On Thu, Aug 28, 2014 at 8:55 PM, Julien Pauli jpa...@php.net wrote: Hello, We all know 5.3 is now EOL. Looking at git branches, 5.0, 5.1 and 5.2 still have their respective main branches (which is all right and good). However, they dont have their release branch references (5.1.1 , 5.1.2 etc...) , however they still show their own release tags, which is also all right. As a reminder, release *branches* (not the tags) are used by the RMs to actually release the version. RMs branch from the main repo into a release branch, and apply their RM-managing-stuff commits as well as backport eventual commits from the main branch, for CVEs, for example. Those release branches are here just for the release, and are no longer needed at all after the release has been released, because every release owns its own final git tag. The tag is written lowercased (php-5.5.4) and the branch is written uppercased (PHP-5.5.4). What I suggest, is removing those branch references from our git, for EOL versions of PHP. This is done for PHP=5.2 (but that was before the move to git) , but PHP5.3 release branches are still referenced. Of course references in git are very light things, but they tend to pollute the references. For example , browsing our branches in the github mirror select box is a pain nowadays. Same for git command line autocompletion that shows every remote branches, or the git branch --all command , and its friends. I already sent a mail, few months ago, to clean the branches we dont use any more. Some argued that for history, they should be kept referenced. But, thoughts to clean *release branches* from our git for *EOL PHP versions*, like 5.3 ? Tag references should be enough for history, IMHO Julien.P -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Hi, just my two cents: I think RMs should remove the PHP-X.Y.Z branches after a release is made (as you mentioned we already have a tag, and after a release is made, we will never continue development/re-tag, so there is no reason to preserve the branch). I also think that feature/work branches should be deleted after they are merged (we still have phpng and str_size_and_int64 for example). But I don't see much point in deleting the release branches (PHP-X.Y) even for eol'ed version. The number of those branches are pretty small, sometimes we leave some commits in the release branch, which doesn't made into the last release tag (https://github.com/php/php-src/compare/PHP-5.3.29...PHP-5.3), plus in the past we had precedence(PHP-5.2), when we had to make additional releases after the originally planned EOL release, which if using this policy would be a bit messy(you either don't merge those commits upward, or you have to recreate the previously deleted PHP-X.Y branch first, or create a PHP-X.Y.Z branch from the last tag, push there, and merge and tag from that branch). -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] Cleaning 5.3 git branches ?
On 28 August 2014 19:55, Julien Pauli jpa...@php.net wrote: Hello, We all know 5.3 is now EOL. Looking at git branches, 5.0, 5.1 and 5.2 still have their respective main branches (which is all right and good). However, they dont have their release branch references (5.1.1 , 5.1.2 etc...) , however they still show their own release tags, which is also all right. As a reminder, release *branches* (not the tags) are used by the RMs to actually release the version. RMs branch from the main repo into a release branch, and apply their RM-managing-stuff commits as well as backport eventual commits from the main branch, for CVEs, for example. Those release branches are here just for the release, and are no longer needed at all after the release has been released, because every release owns its own final git tag. Based on this, it doesn't seem like there's any point in keeping the branches at all after the tag is created. I would take this proposal a step further and suggest a policy of deleting the previous release branch when a new release is made (i.e. when 5.6.1 is tagged, the 5.6.0 branch would be deleted). The workflow described dictates that no changes should be made to a branch after its corresponding tag is created, and github provides a decent, universally accessible and familiar UI for browsing the code of a particular tag. I would be in favour of keeping hold of a branch until the following release is created (rather than deleting it when that release is made) as emergency releases - for example when a major security flaw is discovered after a release - could be facilitated by keeping hold of the old branch, although even this reasoning is highly questionable. I really don't see the need to keep any release branches hanging around cluttering up the place. Thanks, Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Merges between PHP5 and PHP7
Hi Derick, On Thu, August 28, 2014 17:23, Derick Rethans wrote: On Fri, 22 Aug 2014, Derick Rethans wrote: On Fri, 22 Aug 2014, Anatol Belski wrote: as there are many data type changes, here's an idea on how to simplify the merges. Git supports custom merge drivers which attracted my attention, so I've ended up with the following trick: As there are that many differences, does it still make sense to GIT merge PHP 5 changes up to 7 at all? Shouldn't we just do it by hand. I would expect that to have a much greater rate of success. Really, no comments about this at all? Since there was just a little interest, I thought it's rather this topic died. Now after working more than a week on master I do share your opinion as well - manual merge is probably the success strategy. The most pain will come from new APIs, just to name some - zend_string vs char*, arrays and changed macro/function signatures. However, once 5 is converted to 7, the pain should decrease. Of course sometimes it'll get complicated, but that's also not the case for automatic. I think also, when we do the further work and see some systematic cases which can be automated, good to know such a mechanism does exist. Regards Anatol -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] 5.4 non-security issues - last call
Hi! 5.6.0 has been released, and first thing I'd like to congratulate all who participated in it with this great milestone. Second thing, that means 5.4.33 would be the last release including non-security fixes. With RC1 planned next Tuesday, this means if you've got any non-security issues that should be in 5.4 they should be in by Tuesday or chance of getting them in would be very low. So far I know about these things, which are being taken care of: 1. fpm patches, pulls 694 and 765 2. pull 770 about zend_shutdown If there are any more issues that need to be in 5.4.33 RC1 please tell me ASAP. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 non-security issues - last call
Hi, If https://bugs.php.net/bug.php?id=67644 could be fixed in 5.4.33 (and 5.5 as well) it would be really great ! Thanks, Jocelyn Le 28/08/2014 23:13, Stas Malyshev a écrit : Hi! 5.6.0 has been released, and first thing I'd like to congratulate all who participated in it with this great milestone. Second thing, that means 5.4.33 would be the last release including non-security fixes. With RC1 planned next Tuesday, this means if you've got any non-security issues that should be in 5.4 they should be in by Tuesday or chance of getting them in would be very low. So far I know about these things, which are being taken care of: 1. fpm patches, pulls 694 and 765 2. pull 770 about zend_shutdown If there are any more issues that need to be in 5.4.33 RC1 please tell me ASAP. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 non-security issues - last call
Hi! If https://bugs.php.net/bug.php?id=67644 could be fixed in 5.4.33 (and 5.5 as well) it would be really great ! Thank you, I will take a look. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Cleaning 5.3 git branches ?
On Thu, 2014-08-28 at 20:55 +0200, Julien Pauli wrote: Looking at git branches, 5.0, 5.1 and 5.2 still have their respective main branches (which is all right and good). However, they dont have their release branch references (5.1.1 , 5.1.2 etc...) , however they still show their own release tags, which is also all right. For those branches we never had release branches, so there is no wonder they don't exist. I would favor to create a php-src-historic.git repo (or similar) which receives all old branches. With PHP 4 and 5.=3 there this also might make the initial clone a tiny bit smaller while keeping all history for archeologists. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Cleaning 5.3 git branches ?
Hi, On Fri, Aug 29, 2014 at 1:14 AM, Johannes Schlüter johan...@schlueters.de wrote: On Thu, 2014-08-28 at 20:55 +0200, Julien Pauli wrote: Looking at git branches, 5.0, 5.1 and 5.2 still have their respective main branches (which is all right and good). However, they dont have their release branch references (5.1.1 , 5.1.2 etc...) , however they still show their own release tags, which is also all right. For those branches we never had release branches, so there is no wonder they don't exist. I would favor to create a php-src-historic.git repo (or similar) which receives all old branches. With PHP 4 and 5.=3 there this also might make the initial clone a tiny bit smaller while keeping all history for archeologists. johannes Tags preserve history well enough, as previously noted - they are basically immutable branches. This looks like a no-brainer to me. Cheers, Andrey. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Cleaning 5.3 git branches ?
On Fri, 2014-08-29 at 01:34 +0300, Andrey Andreev wrote: Tags preserve history well enough, as previously noted - they are basically immutable branches. This looks like a no-brainer to me. This is not exactly true - we have cases where where, for whatever reason, commits were made after the tag. i.e. I recently got the request to add some CVE IDs to the NEWS file in 5.3 just for having them documented in VCS. I'd say it's trivial to create the historic repo and that will certainly keep all history. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Cleaning 5.3 git branches ?
On Fri, 2014-08-29 at 00:12 +0100, Andrea Faulds wrote: I don’t see the need, though. For cases where we added stuff after release, just make an extra tag. $ git tag | wc -l 937 $ git branch -r | grep origin | wc -l 128 Not sure creating more tags makes things really cleaner, I made a proposal which can easily be implemented. If you don't like it, ok. If you want to do more complex things: Fine with me. Last message by me in this thread, there are way better things for wasting time ... johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Documentation error
I notice that in the precedence chart the new **= operator is missing: http://uk1.php.net/manual/en/language.operators.precedence.php The announcement (below) says that it is right associative, but the precedent chart above says that it is left associative. From the example it seems to be right associative. http://php.net/migration56.new-features -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php #include std_disclaimer.h -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Documentation error
On 29 Aug 2014, at 01:43, Alain Williams a...@phcomp.co.uk wrote: I notice that in the precedence chart the new **= operator is missing: http://uk1.php.net/manual/en/language.operators.precedence.php It’s not on docs.php.net either, so the manual must just be out-of-date. The announcement (below) says that it is right associative, but the precedent chart above says that it is left associative. From the example it seems to be right associative. http://php.net/migration56.new-features Yeah, that’s weird. If we check the actual PHP source, we see it is right-associative: https://github.com/php/php-src/blob/a8b97086d7c5bd5df5243d11bb8b5e9406a2b6c2/Zend/zend_language_parser.y#L112 And I distinctly recall the RFC saying it was right-associative. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Documentation error
Hi Alain, On 29 Aug, 2014, at 8:43 am, Alain Williams a...@phcomp.co.uk wrote: I notice that in the precedence chart the new **= operator is missing: http://uk1.php.net/manual/en/language.operators.precedence.php The announcement (below) says that it is right associative, but the precedent chart above says that it is left associative. From the example it seems to be right associative. Thanks for spotting that; I’ll fix that later today if nobody beats me to it. http://php.net/migration56.new-features -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php #include std_disclaimer.h -- 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
