RE: [PHP-DEV] PCRE jit bug with UTF-8 and lookbehind assertion
Hi Christian,
> -Original Message-
> From: Anatol Belski [mailto:anatol@belski.net]
> Sent: Thursday, February 18, 2016 9:16 AM
> To: 'Christian Schneider' ; 'PHP internals'
>
> Subject: RE: [PHP-DEV] PCRE jit bug with UTF-8 and lookbehind assertion
>
> Hi Christian,
>
> > -Original Message-
> > From: Christian Schneider [mailto:cschn...@cschneid.com]
> > Sent: Wednesday, February 17, 2016 2:07 PM
> > To: PHP internals
> > Subject: [PHP-DEV] PCRE jit bug with UTF-8 and lookbehind assertion
> >
> > Hi there,
> > we just ran into a version of the bug "JIT bug with lookbehind assertion":
> > https://bugs.exim.org/show_bug.cgi?id=1189
> >
> > To reproduce it you can use
> > php -n -r 'ini_set("pcre.jit", 0); echo
> > preg_replace("/\b(11|21|41)\b/u", "z", "x°11\n");'
> > vs.
> > php -n -r 'ini_set("pcre.jit", 1); echo
> > preg_replace("/\b(11|21|41)\b/u", "z", "x°11\n");'
> >
> Seems valgrind doesn't detect any issues with this code. Using latest
> 7.0.4-dev
> code with PCRE 8.38, valgrind 3.10.0 on Jessie. Is there something else I
> could
> miss?
>
Could you please write back, what is the out difference between those two
commands?
Thanks.
Anatol
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC Proposal] var keyword deprecation/removal
"Walter Parker" wrote in message news:CAMPTd_AHyV2d0_Saq=kpvhdzkkcmgkxav8tnt4hk9sdngkc...@mail.gmail.com... On Thu, Feb 18, 2016 at 11:30 AM, Sebastian Bergmann wrote: On 02/18/2016 02:10 PM, Colin O'Dell wrote: I'd like to propose an RFC to deprecate and eventually remove the "var" keyword. +1 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php What are your reasons for this proposal? I can think of multiple reasons why this might not be a good idea, but the only reason that pops to mind for getting rid of it is to make PHP work like a different style of language. Walter Your reason "make PHP work like a different style of language" is meaningless. The removal of the "var" keyword does not change any functionality. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] PCRE jit bug with UTF-8 and lookbehind assertion
Christian,
> -Original Message-
> From: Anatol Belski [mailto:anatol@belski.net]
> Sent: Friday, February 19, 2016 9:20 AM
> To: 'Christian Schneider' ; 'PHP internals'
>
> Subject: RE: [PHP-DEV] PCRE jit bug with UTF-8 and lookbehind assertion
>
> Hi Christian,
>
> > -Original Message-
> > From: Anatol Belski [mailto:anatol@belski.net]
> > Sent: Thursday, February 18, 2016 9:16 AM
> > To: 'Christian Schneider' ; 'PHP internals'
> >
> > Subject: RE: [PHP-DEV] PCRE jit bug with UTF-8 and lookbehind
> > assertion
> >
> > Hi Christian,
> >
> > > -Original Message-
> > > From: Christian Schneider [mailto:cschn...@cschneid.com]
> > > Sent: Wednesday, February 17, 2016 2:07 PM
> > > To: PHP internals
> > > Subject: [PHP-DEV] PCRE jit bug with UTF-8 and lookbehind assertion
> > >
> > > Hi there,
> > > we just ran into a version of the bug "JIT bug with lookbehind assertion":
> > > https://bugs.exim.org/show_bug.cgi?id=1189
> > >
> > > To reproduce it you can use
> > > php -n -r 'ini_set("pcre.jit", 0); echo
> > > preg_replace("/\b(11|21|41)\b/u", "z", "x°11\n");'
> > > vs.
> > > php -n -r 'ini_set("pcre.jit", 1); echo
> > > preg_replace("/\b(11|21|41)\b/u", "z", "x°11\n");'
> > >
> > Seems valgrind doesn't detect any issues with this code. Using latest
> > 7.0.4-dev code with PCRE 8.38, valgrind 3.10.0 on Jessie. Is there
> > something else I could miss?
> >
> Could you please write back, what is the out difference between those two
> commands?
>
One more question - are you using (the bundled or external) PCRE 8.38?
Thanks
Anatol
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC Proposal] var keyword deprecation/removal
""Colin O'Dell"" wrote in message news:cajarsptqpkz9xsp6jf3gpm7hn39kdqpxcx4r5yn8hsohwo1...@mail.gmail.com... What are your reasons for this proposal? I can think of multiple reasons why this might not be a good idea, but the only reason that pops to mind for getting rid of it is to make PHP work like a different style of language. I'm proposing this change because it will remove duplicate functionality from the language. This reason is not good enough. Leaving the "var" keyword in does not do any any harm, so what be benefit is gained by expending the effort of removing it? To be consistent you ought then to remove ALL other instances where there is more than one way of achieving the same thing, but how many of those are there? If the various duplications are still being used, then who decides which one is to be deprecated? For example, the short array syntax was introduced in version 5.4, so according your logic the original (and well used) long array syntax is now a duplicate and should be deprecated. How much effort would this require? What benefit would be achieved? Class properties must be defined as public, private, or protected. If declared using var, the property will be defined as public. This is great for backwards compatibility from PHP 4, but it ultimately results in having two different keywords which do exactly the same thing. Does PHP 7 really need two keywords for declaring public class members? The PHP language is littered with more than one way of doing the same thing, so do you propose the removal of ALL duplications? We're already removing PHP 4 style constructors in favor of the PHP 5 style ones, so why not also remove the PHP 4 "var" keyword in favor of the PHP 5 style keywords which explicitly state the visibility? For the small percentage of projects which still use "var", upgrading their code would be dead simple: just replace "var" with "public" everywhere you see it. I'm sure somebody can easily whip up a tool to automate that process. Why should long standing projects have to change their code just because you personally don't use and don't like the "var" keyword? Instead of tinkering with the language to achieve nothing but perceived "purity" why don't you stick to proposing genuine improvements? -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC][VOTE] Generalize support of negative string offsets
On Fri, Feb 19, 2016 at 7:33 AM, François Laupretre wrote: > Le 19/02/2016 00:48, Andrea Faulds a écrit : >> >> >> You might have to make yet another post. This last one had a new >> subject, but it still was marked as a reply, so my news client threads >> it in with the original thread. >> > > Just posted the message once again. Still appears in the same thread. It > seems Thunderbird is too smart for me :). Anyway, I'll post a reminder next > week. new mail, internals@ That should do it :) Also a reminder is nice, a correct and visible vote start announce is a must. Please do it accordingly and the voting period will start when the mail announce is sent to the list :) Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP 5.6.19 RC1 is available for testing
Hello everyone, PHP 5.6.19 RC1 was just released and can be downloaded from: http://downloads.php.net/~tyrael/ The Windows binaries are available at http://windows.php.net/qa/ This release contains a number of bugfixes. For the list of bugfixes that you can target in your testing, please refer to the NEWS file: https://github.com/php/php-src/blob/php-5.6.19RC1/NEWS Please test it carefully, and report any bugs in the bug system. The stable release is planned for March 3rd, if no critical issues will be discovered in the RC. In case you think that other projects should also receive this kind of emails, please let us know privately, and we will add them to the list of projects to contact. To verify the downloads, you can use the following information: php-5.6.19RC1.tar.bz2 SHA256 hash: 54db8746e1b6ba995b685a877b8d4d2fe8b90e90fdc08e1f4cbba6475afd0bcb PGP signature: -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAABAgAGBQJWxwa6AAoJEMK/C8Qzz8izj1IIAOnmGH5gCrElArh8kwxTYpXB lR47m/UZRsjRTASAqToNvug+YJe8OdjefdgBlSbeFdj9Uyn7D3vks/TApXctbnE7 sPBIT37t3hcbixPrOm52nfMaaSHCs/jPP85gcwSAeNLKZea1M+Sztof74bY6/HzE BvYnc3FOCKfl55Mt+++UEQv0ZZRhNPmzh9UquOWfGlmh7usbZfEEpkHK18O/1NkN PF6nAVqAxteBH14EgQ3YswtGgr19mq6EMIYO6UPkpsXLHWgnDvM0U9DUZQ6gtrgq FG5MmutF0c3QvD3RqD3vtjODjTPWYNUJ1ejmGERgRR6MvJFY1zq6ApIoI+ni3jA= =QPIc -END PGP SIGNATURE- php-5.6.19RC1.tar.gz SHA256 hash: a43db1a23a00a4987eba559c762facbad4bef702c65a94238ba493a3f4780bad PGP signature: -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAABAgAGBQJWxwa/AAoJEMK/C8Qzz8izyuAH/0t0RZvOVKD06sFGgWoHTMoV 14kuywrrP4NK4C/6qJqklmr/JIHUwcyn/JZRoJDbKmB+YtvvtTSY7KiKAcVj8GQq bWCOiOoaI7kBdWi5H6JvvX+/wkhIxsjXPA2obT7I0f/YQ+KON5HZFj2YO3DkVi0E 0Got/KyPjRzGJQXR9BNQsjcZrVVHOceW0CanCIlmyQjXBOEMyN95vPlZqNfRIAuE JvhRMyNFmv1VCzFfyrofl5P51SxqqwY346doU4yDWCDzi2PmnIoiYzi/5bl6vezq lPj7DBJ92r2yWJhMXfPCEpOUu9HbM3CjjnQsbdoqkdLGW7y22gfmoh7QMYiRL+Q= =uDGd -END PGP SIGNATURE- php-5.6.19RC1.tar.xz SHA256 hash: f931625da53c22bad779e5f30ac8cbf421999f0da1c4ae4c0b15cab96f2bdc86 PGP signature: -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAABAgAGBQJWxwbEAAoJEMK/C8Qzz8izngAIAN5s3QQKGUjvzdOHU31nOqH+ zj9xJamYW9C8yZQgwAs+Q1OyGi7mIkz1gzh5N3LlNjIYzuYr+RQubjOfuEsYGO5L EROjjSArp5ORLZ+gkRogopToOMz9mehOY2IA44ytavcqn+aS++mMzlIRjhdj6mF3 Bsgf8WUUiCZNf6BgQIu0ch0RkiYv7KrF3HtO+wB/0eC+nSeyvEz6GNvyVcn3FmNc vfADWD8cDUpeZxrOV5CilvO6j8KLR1HW9thRlPzJmvQdQtS6xg8cPrH2On3TMgVm +zRpsHmyt5PFIlxoiwn6AoLywCRzpnjWP/6oWoG4n3t172U17Dp0rK/jEWB5sSI= =ZeAl -END PGP SIGNATURE- Thank you for your support. Ferenc Kovacs & Julien Pauli
[PHP-DEV] [RFC][VOTE] Generalize support of negative string offsets
Hi,
(sorry, posting again to force new thread)
Starting vote about : https://wiki.php.net/rfc/negative-string-offsets
Voting period ends in 2 weeks : Monday, March 7th 00:00 UTC.
As, during the discussion, we talked about many related but off-topic
subjects, please remember that the subjects below remain *out of scope
of this RFC* and deserve their own thread :
- Support '{}/[]' (empty braces) on string offset assignments,
- Reserve/recommand '{}' syntax for string offsets and '[]' for arrays,
- Auto-conversion of empty string to array on string offset assignment,
- the same with true/false,
- support '++/--' on string offsets...
If you want to go further discussing one of these subjects, please
create a new thread for this.
Regards
François
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Adopt Ruby Code of Conduct
> > The Ruby Community Conduct Guideline > We have picked the following conduct guideline based on an early draft of > the PostgreSQL CoC, for Ruby developers community for safe, productive > collaboration. Each Ruby related community (conference etc.) may pick their > own Code of Conduct. > This document provides community guidelines for a safe, respectful, > productive, and collaborative place for any person who is willing to > contribute to the Ruby community. It applies to all “collaborative space”, > which is defined as community communications channels (such as mailing > lists, submitted patches, commit comments, etc.). > >- Participants will be tolerant of opposing views. > > >- Participants must ensure that their language and actions are free of >personal attacks and disparaging personal remarks. > > >- When interpreting the words and actions of others, participants >should always assume good intentions. > > >- Behaviour which can be reasonably considered harassment will not be >tolerated. > > This is good because it doesn't try to legally redefine harassment, and doesn't support blacklisting based on ideological views, which is something considered illegal many US states (like California, Oregon, Washington). More importantly it doesn't create a inquisition to police people's politics, they are free to be a Men's rights activist or feminist, they can support equal rights or affirmative action, and it wont effect their code or work abilities. Most importantly it doesn't allow a persons feelings, to override the technical merits of a persons arguments, as critics of the SystemD have been labeled as violating the code of conduct. https://lists.fedoraproject.org/pipermail/users/2014-July/451692.html
Re: [PHP-DEV] [RFC] Deprecations for PHP 7.1
Hi, Le 18/02/2016 13:41, Nikita Popov a écrit : This RFC is incomplete -- I'm posting it now so people can suggest other things that should be deprecated. I expect it to grow over time and don't plan to vote on it in the immediate future. May I suggest to remove the second argument of spl_autoload() ? spl_autoload() is typically called from the PHP core only, and the core never sets this argument. File extensions to consider are set using spl_autoload_extensions(). So, the 2nd argument of spl_autoload() is useless and probably never used anywhere. The problem with this argument is that it creates an annoying issue when thinking about a way to extend autoloading to other symbol types (namely functions and constants). The easiest way to extend autoloading to other types is to add an optional second argument to autoloaders. For a perfect BC, the core would call an autoloader for non-class symbols only if the function accepts 2 arguments. This way, we can achieve full backwards and forward compatibility with existing autoloaders. The pre-requisite is that currently existing autoloaders take only one arg, hence my suggestion to remove the second argument of spl_autoload() (spl_autoload() will remain a class-only autoloader). Regards François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Deprecations for PHP 7.1
Hi Nikita, Nikita Popov wrote: On Thu, Feb 18, 2016 at 11:45 PM, Zeev Suraski wrote: * rand(), the first function anyone will try, uses a potentially horrible libc RNG The manual could really be better here. It mentions that rand()'s maximum output might be quite small on platforms like Windows, whereas it ought to recommend mt_rand() in most cases. * It was recently noticed that the mt_rand() implementation contains a typo and our output differs from the original well-researched algorithm. As yet it is unclear what that typo does to the quality of the output. I'm not a statistician, so take what I say with a grain of salt. But from an amateur analysis, it seems to have fairly uniform output: https://www.reddit.com/r/lolphp/comments/46fxi8/typofixing_commit_in_mersenne_twister_rng_code_is/d0552tb * mt_getrandmax() is 2^31-1 even on 64-bit machines and numbers are scaled using floating point multiplication. That means if you tell mt_rand() to generate a 64-bit random numbers by specifying the range, only a tiny fraction of numbers can actually be hit. I also strongly suspect that the floating point scaling is inherently non-uniform even for smaller ranges. Perhaps we could produce an E_NOTICE if you give a range that's too large? * Functions like array_rand() or shuffle() use rand() and not mt_rand(), so if you're on Windows and your array is larger than some 30k elements the output will likely be severely biased. If we fix this, we should do it at the same time as we fix mt_rand()'s typo, since both could potentially break code (realistically just unit tests) relying on deterministic output. Even though changing our PRNG implementations will break seed sequences, I think the time has come to clean up this mess for 7.1. (We might also want to consider to alias rand and mt_rand to an entirely new algorithm, not MT19937. Nowadays PRNGs are available that have both better statistical properties and are faster than MT.) If we did that, we could change it to always use a 64-bit value internally (including on 32-bit systems through emulation). That way some of our scaling woes would disappear. On a different note, I don't think that philosophical discussions on the topic of how much we ought to be deprecating will be very productive -- this is one of those topics people tend to be very stubborn about ;) Some people value stability above everything else, and for others the number one evil in PHP is our reluctance to get rid of old ---crap--- cruft. It would be nice if we could let voting decide that question, and keep this thread focused on specific issues and suggestion. I.e. on one hand suggestions for things that we may want to deprecate, together with reasoning for why we should do it. I do think we should at least have a good case made for deprecating each item. If something is merely a redundant alias or not very useful, then there's not much case for getting rid of it, because there's little benefit and the large disadvantage of breaking existing code. On the other hand, if it's harmful in some way, then there's a greater case for deprecation. Thanks! -- Andrea Faulds https://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] NEUTRAL Benchmark Results for PHP Master 2016-02-19
Results for project PHP master, build date 2016-02-19 06:31:49+02:00 commit: 8b410c5 previous commit:030b7ba revision date: 2016-02-18 22:37:51+00:00 environment:Haswell-EP cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores, stepping 2, LLC 45 MB mem:128 GB os: CentOS 7.1 kernel: Linux 3.10.0-229.4.2.el7.x86_64 Baseline results were generated using release php-7.0.0, with hash 60fffd2 from 2015-12-01 04:16:47+00:00 --- benchmark relative change since change since current rev run std_dev* last run baseline with PGO --- :-| Wordpress 4.2.2 cgi -T1 0.28% 0.09% 0.62% 7.77% :-| Drupal 7.36 cgi -T1 0.18% -0.01% -0.48% 5.10% :-| MediaWiki 1.23.9 cgi -T5000 0.19% 0.00% 1.47% 3.42% :-| bench.php cgi -T100 0.02% 0.27% 2.19% 5.12% :-| micro_bench.php cgi -T10 0.48% -0.52% 1.41% 4.84% :-| mandelbrot.php cgi -T100 0.01% 0.00%-12.39% 3.51% --- * Relative Standard Deviation (Standard Deviation/Average) If this is not displayed properly please visit our results page here: http://languagesperformance.intel.com/neutral-benchmark-results-for-php-master-2016-02-19/ Note: Benchmark results for Wordpress, Drupal, MediaWiki are measured in fetches/second while all others are measured in seconds. More details on measurements methodology at: https://01.org/lp/documentation/php-environment-setup. Subject Label Legend: Attributes are determined based on the performance evolution of the workloads compared to the previous measurement iteration. NEUTRAL: performance did not change by more than 1% for any workload GOOD: performance improved by more than 1% for at least one workload and there is no regression greater than 1% BAD: performance dropped by more than 1% for at least one workload and there is no improvement greater than 1% UGLY: performance improved by more than 1% for at least one workload and also dropped by more than 1% for at least one workload Our lab does a nightly source pull and build of the PHP project and measures performance changes against the previous stable version and the previous nightly measurement. This is provided as a service to the community so that quality issues with current hardware can be identified quickly. Intel technologies' features and benefits depend on system configuration and may require enabled hardware, software or service activation. Performance varies depending on system configuration. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC Proposal] var keyword deprecation/removal
On Fri, Feb 19, 2016 at 1:10 AM, Tony Marston wrote: > "Walter Parker" wrote in message > news:CAMPTd_AHyV2d0_Saq=kpvhdzkkcmgkxav8tnt4hk9sdngkc...@mail.gmail.com... > >> >> On Thu, Feb 18, 2016 at 11:30 AM, Sebastian Bergmann >> wrote: >> >> On 02/18/2016 02:10 PM, Colin O'Dell wrote: >>> >>> I'd like to propose an RFC to deprecate and eventually remove the "var" keyword. >>> +1 >>> >>> -- >>> PHP Internals - PHP Runtime Development Mailing List >>> To unsubscribe, visit: http://www.php.net/unsub.php >>> >>> >>> What are your reasons for this proposal? >> >> I can think of multiple reasons why this might not be a good idea, but the >> only reason that pops to mind for getting rid of it is to make PHP work >> like a different style of language. >> >> >> Walter >> > > Your reason "make PHP work like a different style of language" is > meaningless. The removal of the "var" keyword does not change any > functionality. > > -- > Tony Marston > > > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > I've been doing too much C# lately, mixing up the definitions of var (C# now uses var very frequently in coding). -- The greatest dangers to liberty lurk in insidious encroachment by men of zeal, well-meaning but without understanding. -- Justice Louis D. Brandeis
Re: [PHP-DEV] [RFC] Traits with interfaces
On Thu, Feb 18, 2016 at 2:16 PM, Chase Peeler wrote:
>
>
> On Thu, Feb 18, 2016 at 1:29 PM Nikita Popov wrote:
>
>> HHVM already supports "trait Foo implements Iface" with the semantics that
>> the interface is also implemented by the using class.
>>
>> Additionally HHVM supports a notion of "require implements Iface" which
>> means that the using class must implement this interface.
>>
>
This was mentioned in the original traits RFC, but never got voted or
implemented:
https://wiki.php.net/rfc/horizontalreuse#requiring_composing_class_to_implement_interface
It's orthogonal to this RFC.
>
>> Why should it matter if the class using the trait actually implements the
> interface? If the person just wants the functionality, but, for whatever
> reason, doesn't want to actually implement the interface, why should it
> matter?
>
> I think the trait should HELP the person implementing an interface. The
> trait should be able to say (whether via comments or an engine enforceable
> construct) "Hey, I've done everything needed for you to implement this
> interface" but, at no time, should the trait force the class utilizing it
> to interact (via extend or implement or use) a 3rd artifact.
>
> trait foo implements myinterface {}
> class bar { use foo;}
> class baz implements myinterface { use foo;}
>
> Both of the above should be legal, and $myBar instanceof myinterface
> should return false;
>
This is Proposal 1 in the new draft of my RFC:
https://wiki.php.net/rfc/traits-with-interfaces
Does that proposal sound like what you'd want?
Cheers
-- Kevin
>
Re: [PHP-DEV] [RFC] Traits with interfaces
On Fri, Feb 19, 2016 at 2:13 PM Kevin Gessner wrote:
> On Thu, Feb 18, 2016 at 2:16 PM, Chase Peeler
> wrote:
>
>> On Thu, Feb 18, 2016 at 1:29 PM Nikita Popov
>> wrote:
>>
> HHVM already supports "trait Foo implements Iface" with the semantics that
>>> the interface is also implemented by the using class.
>>>
>>> Additionally HHVM supports a notion of "require implements Iface" which
>>> means that the using class must implement this interface.
>>>
>>
> This was mentioned in the original traits RFC, but never got voted or
> implemented:
> https://wiki.php.net/rfc/horizontalreuse#requiring_composing_class_to_implement_interface
>
> It's orthogonal to this RFC.
>
>
>>
>>> Why should it matter if the class using the trait actually implements
>> the interface? If the person just wants the functionality, but, for
>> whatever reason, doesn't want to actually implement the interface, why
>> should it matter?
>>
>> I think the trait should HELP the person implementing an interface. The
>> trait should be able to say (whether via comments or an engine enforceable
>> construct) "Hey, I've done everything needed for you to implement this
>> interface" but, at no time, should the trait force the class utilizing it
>> to interact (via extend or implement or use) a 3rd artifact.
>>
>> trait foo implements myinterface {}
>> class bar { use foo;}
>> class baz implements myinterface { use foo;}
>>
>> Both of the above should be legal, and $myBar instanceof myinterface
>> should return false;
>>
>
> This is Proposal 1 in the new draft of my RFC:
> https://wiki.php.net/rfc/traits-with-interfaces
>
> Does that proposal sound like what you'd want?
>
> I don't really have any objections to proposal 1. Part of me would still
like to see a different keyword used, but I don't think that's a huge deal.
I think the important part is not propagating the implementation (proposal
2).
My comments above, however, were more in relation to the HHVM notion of
"requires implement interface" which I don't think either proposal does.
> Cheers
> -- Kevin
>
>> --
-- Chase
chasepee...@gmail.com
Re: [PHP-DEV] [RFC] Traits with interfaces
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2/19/2016 8:34 PM, Chase Peeler wrote: > My comments above, however, were more in relation to the HHVM > notion of "requires implement interface" which I don't think either > proposal does. > I cannot vote but I would like to repeat that the HHVM approach solves all desires. - -- Richard "Fleshgrinder" Fussenegger -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJWx3ANAAoJEOKkKcqFPVVrnUoP/jEjDHkxDuGVagUvkIqaGXbL NQqrgXvSuv5kjsLXNMsQcYL7NVdfRK18PpZ8V0rVi6bzph4azOWC/Y01NyuW+CAN T+eccL5yiI7UPCh/Iiif4d9nGu6gCBEXgvu4ADtK5Z8lQx+P+UhXahCksTeNXPl5 5x3kNBEHKI4HrnKeDZpRyLg+waJxkIzn7Ulrd4OPta8zJvhOF2r0SSwugbE703nt d9n9XKrp8xdji3uoNeLD95FLEjWi85U0ANO2iFKgawGAHnKRXeLOaTL8Jzygjmsy YegO7OQzKR+SqCTivTSejsTKcMJQKJi3Uj1zHu4j+P8hIuGvHBA/LcfP030jj/vH 3L4XZnv0/gogX4EwJ4K3BjzKyWKwMxtzRoQttClGbVn/3qO7y5cpUe6W9WhetMh5 Z+VnuuyEGLE0wvjVnXOHA7ZC/mykNFUIgEv6nvoCIdLWXtST16ozP/FYK9o1hQyl jSlC66JPIqD2kvJxAR7lEJfIv0pz8qfptt45zMitapd0cr2r63FJW7usg1T7VIpI oUKKGIKX8PUnYAYqPfsK6zIENqZwQQ6FkmWVYKF2gSE5zcOpt4P2J23AMnGZe70/ wpJoo37MKmnOrVk99FisHFpIOCqQ3YS8kocDC390g1LsGDv++aapfAWUo073JpuR ySxOW97em8OevmKFtMcb =nzH/ -END PGP SIGNATURE- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Traits with interfaces
On Fri, Feb 19, 2016 at 2:42 PM Fleshgrinder wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On 2/19/2016 8:34 PM, Chase Peeler wrote: > > My comments above, however, were more in relation to the HHVM > > notion of "requires implement interface" which I don't think either > > proposal does. > > > > I cannot vote but I would like to repeat that the HHVM approach solves > all desires. > > I can't vote either :-) I don't agree. The HHVM approach of allowing a trait to indicate the a utilizing class MUST implement an interface is, in my opinion, not a good thing. It allows the trait to force a utilizing class to interact with a third entity, which I don't think a trait should be able to do. The trait can say "hey, if you want to use me, you have to implement my abstract methods" but the trait shouldn't be able to force you to include his friends. Again, that part of the HHVM approach isn't being proposed, so it's really a moo point anyway. > - -- > Richard "Fleshgrinder" Fussenegger > -BEGIN PGP SIGNATURE- > Version: GnuPG v2 > > iQIcBAEBCAAGBQJWx3ANAAoJEOKkKcqFPVVrnUoP/jEjDHkxDuGVagUvkIqaGXbL > NQqrgXvSuv5kjsLXNMsQcYL7NVdfRK18PpZ8V0rVi6bzph4azOWC/Y01NyuW+CAN > T+eccL5yiI7UPCh/Iiif4d9nGu6gCBEXgvu4ADtK5Z8lQx+P+UhXahCksTeNXPl5 > 5x3kNBEHKI4HrnKeDZpRyLg+waJxkIzn7Ulrd4OPta8zJvhOF2r0SSwugbE703nt > d9n9XKrp8xdji3uoNeLD95FLEjWi85U0ANO2iFKgawGAHnKRXeLOaTL8Jzygjmsy > YegO7OQzKR+SqCTivTSejsTKcMJQKJi3Uj1zHu4j+P8hIuGvHBA/LcfP030jj/vH > 3L4XZnv0/gogX4EwJ4K3BjzKyWKwMxtzRoQttClGbVn/3qO7y5cpUe6W9WhetMh5 > Z+VnuuyEGLE0wvjVnXOHA7ZC/mykNFUIgEv6nvoCIdLWXtST16ozP/FYK9o1hQyl > jSlC66JPIqD2kvJxAR7lEJfIv0pz8qfptt45zMitapd0cr2r63FJW7usg1T7VIpI > oUKKGIKX8PUnYAYqPfsK6zIENqZwQQ6FkmWVYKF2gSE5zcOpt4P2J23AMnGZe70/ > wpJoo37MKmnOrVk99FisHFpIOCqQ3YS8kocDC390g1LsGDv++aapfAWUo073JpuR > ySxOW97em8OevmKFtMcb > =nzH/ > -END PGP SIGNATURE- > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- -- Chase chasepee...@gmail.com
Re: [PHP-DEV] [RFC] Traits with interfaces
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2/19/2016 8:47 PM, Chase Peeler wrote: > I don't agree. The HHVM approach of allowing a trait to indicate > the a utilizing class MUST implement an interface is, in my > opinion, not a good thing. It allows the trait to force a utilizing > class to interact with a third entity, which I don't think a trait > should be able to do. The trait can say "hey, if you want to use > me, you have to implement my abstract methods" but the trait > shouldn't be able to force you to include his friends. > > Again, that part of the HHVM approach isn't being proposed, so it's > really a moo point anyway. > My argumentation from the very beginning, however, I understood that some people would love to see exactly this possibility: to force using classes. I am all for compromises to make everyone happy. However, if we agree that we do not want to see the "require" then I am totally happy to see support for "implements" in they way that it is not inherited by the using class at all for the reasons I explained earlier. - -- Richard "Fleshgrinder" Fussenegger -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJWx3KEAAoJEOKkKcqFPVVrZcoQAMTX8EiwtvtYlL8SJc030qUP t8u/L6TlJt/euaWFCnvuWcqe0gg674/cqC7uPoSz1y/Zql2YD52Hj9VDBMlg3FWT 5D/uS3KUgjEFUGnn45fUpEZSl08qWNKMqYQcr3HmK3oMTHISPxfLv9xw3PdLtnIt iQBlSM/PVFsC5nxdbClxMnEBr3TSVk7nehSCkneEs1Ew8hCEs/Q/dArj0nwjDJYX AoO0qsbTV9PUt0OiHMgGQ8MtubKVTdPd8WgsUT1wN3bXtxBHAQOHsMav8ZY5PbDM Atq1dMnmKP5wNmpMXNc/01TYJHws2MxWeTdFF9pedd6u6jz1D7eNuea7uX9OQG5U r9KRBjeeIsthY+ertt1jVzJ43ufaclal4bvwbiS2/KkKfPOprGu42DrZDNtJZNdJ iOuWiZKAbhg9YA/NcoVx8YxwH2rbpdSJjyc84W5MCYjAofM4eEaYtj79gnZbd1Hj d/wqnKk4H6tRt1HjQLfoqBlFn27R6xNMe+1j5gRftNZkK0ZmHIMVt/I+aId/iFgK ultn1JFsk8E75Tj6XzD5r3KPa38B4WTQYp919Jrf6dY66RIZ3L9yRViBmoqxUml2 WOhZYLPQTUBLtxCAXLQYcp1UntbAEa9f89oLkhH6iekmCxcplfG7ka2fVoc+XqLk xgub9X1NTtsK7HYty6nf =2oRB -END PGP SIGNATURE- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC Proposal] var keyword deprecation/removal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2/18/2016 10:53 PM, Stanislav Malyshev wrote: > This is all generic advice which is nice and well if we would be > designing language anew. As it is, we are not - we already have > lots of code using var. For code not using var, removing var does > not do anything. For code using var, removing var means no upgrade. > It is unnecessary breakage for the sake of feeling that we follow > the advice somebody put on the website. That feeling is not worth > very real work that people would have to do to achieve what they > already have now. I would not say that the information that the Nielsen Norman Group puts on their website falls in the category of "somebody putting something on a website". https://www.nngroup.com/about/ https://en.wikipedia.org/wiki/Nielsen_Norman_Group Additionally there is other scientific work that supports what I stated, e.g.: http://www.eecs.yorku.ca/research/techreports/1999/CS-1999-08.pdf On 2/18/2016 10:53 PM, Stanislav Malyshev wrote: > Yes, PHP has aliases. Nothing wrong with that, provided you bother > to look in the manual once, and then you are enlightened forever. > [...] It only wastes their time if they don't read the manual but > instead chat on Stackoverflow :) Which I have nothing against, it's > just not the reason to introduce BC breaks because somebody asked a > question about it. A lot of things are wrong with this (see above reasons) and the RTFM argument is a thought-terminating cliché. Duplication harms the overall design of a language, it results in a maintainability burden for the developers, hell, even this discussion is only happening and wasting our time due to these duplications. I am not saying that your arguments about breaking changes and more complicated upgrades for a small user base are wrong; I am saying that these are weak arguments compared to the scientific facts and the overall progress for the PHP programming language. After all, we are talking about an upgrade path of several years. Anyone should be able to adopt by that time and they probably have other problems until then with their old systems. - -- Richard "Fleshgrinder" Fussenegger -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJWx3V1AAoJEOKkKcqFPVVrc4cQAINj1zV9lXZAaMGCHrTWjtK8 RC04cjsYzG0XMUa+8wexxmQCkgMSBkRLOWaDa8VyCTbUabHSHi70Zf2mj0qyFQcM rv6DxYVorWDx5ty0odnv+8vgnBra2LHc4OntRGe0GWsM0Z4aQ2QfriMzaAt+diBn gSCC5yPxfE3jjqi4TYuT7eshQ3Kz0SeTAarY19fApi7f80JDwChHeerUiGFMZE3x GUUJi02NeKUnfqliAM0k9VGgAP4qGjmPiVFWjoQKZ9rYPvGRqztLO7c2V+65DlY7 He/vibZDsmvbQZXVcszi2cWNhhzn43XXTwF+jiFuKhlXNLwJJDcJbanfJtQJpEiI MB5adPIROxTtgJdrOBTZ8PMT0IKk4P1i19IUqL6sne4AJtcn3UYEoNUiUiO2TJfP 1zgNfTOAnlmf14jtij2g1wj8XPscjA38zo/2QWzGxadqgsQX6m2NgqlzMV+D6WbH C5KToC5EiF/WNWd/vsViYLCEPusuFzHDx8qWFH0ZiNBdhsMTX6yB+Rt5mKZ2hauY o4+5z4308JPrI8Ao6oroVJ3TqiGN7R8nWUlE3J5/v9psgYVdFMyIe1vXmhtROBo9 N382klHxZHVISis0290HnmdlP8t/g6AevdF3uGHbLEUA8Jzs9LwzrAlUtSBkCNlx 3Yeby46U03XVb3zCZzm3 =1iGy -END PGP SIGNATURE- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC Proposal] var keyword deprecation/removal
Hi! > I would not say that the information that the Nielsen Norman Group > puts on their website falls in the category of "somebody putting > something on a website". I think you are trying for an argument of "I agree with some guys that I consider being an authority so you should agree with me". It works only if these guys are established as unerring God-like authority _and_ they spoke on the particular case we are discussing. I don't think either of this is true. So let's dispense with authority appeals for now. > A lot of things are wrong with this (see above reasons) and the RTFM > argument is a thought-terminating cliché. Duplication harms the It is cliche because it's true. You do not need any deep thought to know what aliases are, there is no deep insight to be had there, there is just a thing to know - these two things are two ways of saying the same. It's not really hard or "confusing". > overall design of a language, it results in a maintainability burden > for the developers, hell, even this discussion is only happening and > wasting our time due to these duplications. Wait, so the fact of you arguing for removal of aliases is the proof of you being right? That's neat. -- 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 Proposal] var keyword deprecation/removal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2/19/2016 9:49 PM, Stanislav Malyshev wrote: > I think you are trying for an argument of "I agree with some guys > that I consider being an authority so you should agree with me". It > works only if these guys are established as unerring God-like > authority _and_ they spoke on the particular case we are > discussing. I don't think either of this is true. So let's dispense > with authority appeals for now. No, I just wanted to remark that it is not just an opinion based blog post that I was referring to and that the link points to a _valid_ argument. > It is cliche because it's true. You do not need any deep thought to > know what aliases are, there is no deep insight to be had there, > there is just a thing to know - these two things are two ways of > saying the same. It's not really hard or "confusing". Old cellphones were shipped with a user manual that contained precise instructions on how to deal with the installed OS. New smartphones do not contain a user manual because the OS is so intuitive that nobody has a need for them. I never read the manual for any of those old cellphones and was still able to achieve my goals. However, other people apparently had problems and that is why a manual was shipped along with them. Do not apply your intelligence and knowledge on others and approach topics by weighting pros and cons and not opinions. > Wait, so the fact of you arguing for removal of aliases is the > proof of you being right? That's neat. No and I did not imply this, again, we are collecting arguments and I am on the pro side so I contribute pro arguments. Your comments on the other hand are passive aggressive and do not contribute to the overall discussion because you simply say no and do not even allow a discussion. I received your actual arguments and I acknowledge them but _I personally_ consider them weak (if that is true cannot be judged by either of us) and _I personally_ think that the arguments others and me brought to the table are more extensive and thus add more to the pro side even if your arguments count fully on the con side. - -- Richard "Fleshgrinder" Fussenegger -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJWx4SWAAoJEOKkKcqFPVVraPcQAJ7h/R4qmB/BhIgsVIWUVdYY TrMffjrO1Mz8DaFhVsjjDhjj2oQ9OHvcGOTZ/WRVsMRxO6wh1C3QCuQFrE/uCO4z 2oLV54MRcs4DyNUzIflS/iPrpfLI1aplQZDlDhB1Q470rr7sj3p69dqAhnHEIQdE jD4DePDIRIe4b7tfOYfC4HF3mGXyufisiLPGXrYxAEKNmy+4DewnhnN7nnP2Zst4 gXxzDtzNlQbQS/R3TFu8xPZZ4S8e71wn0KdNhSULgM5m4rDQBGFisgHuJe8eLTxJ 9Y0XLNZh4L7uUcAyfi6yqZ61krhvZcm2J234xxgS6425NKyQ+qAI7kWshv2dNZdi Xwm2asgOOmwmNpXhO2JOJpf+1K459nL8k7Po2qckdFqD332iEkEKirNZp/YpDuzx gClz4oriS3ygH9AVgvy+EtZ+dUkzdLxXFWtN6MX1UzQ1zYRc1gIIgiTvLuoraupJ d2Qp4ZbiFEtS3YQm+lInpDgarIKGqNQ1zXMEnRogENy8UC0FtzYP3n0Sx+J08Sxd CeQ7/9aLneONFOTKYK/Ea+3YyXVjBWtq7JJqVZdwearkqaUn5+TTNSczAyfV968I GB96lk2R4voTfrD9nTmrPot5FPZA/acGKPFpvSQNFjNi/AG/UNR+WTsK4JnWpq2I gUE4PXwx3AFxZBHCh5Zg =HMPP -END PGP SIGNATURE- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC Proposal] var keyword deprecation/removal
Hi! 2016-02-18 15:10 GMT-04:00 Colin O'Dell : > Hello everyone, > > I'd like to propose an RFC to deprecate and eventually remove the "var" > keyword. > > My understanding is that this keyword was kept in PHP 5 for > backwards-compatibility with PHP 4. However, it's been 9 years since PHP 4 > was discontinued, so I'd like to bring this topic up for review. > > Usage of "var" doesn't seem to be as widespread recently. I've done a quick > search of several major projects and libraries and found that only a couple > are using it. I personally haven't seen it used in any PHP 5.3+ project > I've worked on in recent memory. > > Because "var" simply acts as an alias for "public", removing it should not > cause any loss of functionality. Yes, it's a BC break, but developers can > easily replace it with "public" to maintain the same functionality. > > PHP 7 deprecated PHP 4 style constructors in favor of the PHP 5 > __construct() method. I'd like to propose doing the same for the "var" > keyword - deprecate it in PHP 7.1 and remove it in a future version (7.2 or > 8.0?) > > I'd appreciate any thoughts or feedback you may have, especially if you > have any objections to me creating an RFC for this proposal. > > Best regards, > > Colin O'Dell I'm +1 on this for all the reasons mentioned above. There is plenty of time for people to update and, additionally, an automated patch script could be provided along with the RFC. Thank your for taking the time discuss on this mailing list. Márcio Almada. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC Proposal] var keyword deprecation/removal
On Fri, Feb 19, 2016 at 7:59 AM, Zeev Suraski wrote: >> On 18 בפבר׳ 2016, at 23:23, Yasuo Ohgaki wrote: >> >> Hi all, >> >>> On Fri, Feb 19, 2016 at 4:33 AM, Andrea Faulds wrote: >>> >>> Colin O'Dell wrote: I'd like to propose an RFC to deprecate and eventually remove the "var" keyword. >>> >>> >>> I don't have a strong opinion on that, I guess I'm in favour. It seems like >>> a fairly harmless deprecation. >>> >>> Though if we do get rid of the var syntax, I'd like it if we kept the >>> reserved word, because it still might be useful in future for typed >>> variables or different variable scoping. >> >> Same opinion. >> Keeping various syntax makes language more complex. > > I think it's a drop in the bucket compare to new features we're adding plenty > of on every version. These make the language a lot more complex than var > being an alias to public (not even different syntax). > > To me, var falls squarely in the bucket of "no strong reason to remove". I agree. There is no strong reason to remove. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] com php-src: Revert "Fix #71152: mt_rand() returns the different values from original mt19937ar.c": ext/standard/rand.c ext/standard/tests/math/mt_rand_value.phpt
Hi all,
There is discussion for this commit in github comments.
https://github.com/php/php-src/commit/a0724d30817600540946b41e40f4cfc2a0c30f80#commitcomment-16174204
This should be discussed in internals.
MT rand being not MT rand is unacceptable.
This fix must included in released versions. IMHO.
In any case we should provide broken MT rand, we must use INI switch
or other options.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
On Thu, Feb 18, 2016 at 8:09 PM, Leigh wrote:
> Commit:a0724d30817600540946b41e40f4cfc2a0c30f80
> Author:Leigh Thu, 18 Feb 2016 11:09:01 +
> Parents: aa383d633e72d7c9f5e9b0cb4fa75757558cad55
> Branches: PHP-7.0
>
> Link:
> http://git.php.net/?p=php-src.git;a=commitdiff;h=a0724d30817600540946b41e40f4cfc2a0c30f80
>
> Log:
> Revert "Fix #71152: mt_rand() returns the different values from original
> mt19937ar.c"
>
> This reverts commit 6f6bd8ce531636134efd5f669a4e8373fb2e9e51.
>
> `mt_rand()` is seedable with `mt_srand()` which means it can be used to
> (re)produce specific streams of numbers. All code (no matter how few
> instances that may be) that previously depended on this behaviour will no
> longer produce the same results.
>
> This kind of change needs to be discussed before being committed.
>
> Bugs:
> https://bugs.php.net/71152
>
> Changed paths:
> M ext/standard/rand.c
> D ext/standard/tests/math/mt_rand_value.phpt
>
>
> Diff:
> diff --git a/ext/standard/rand.c b/ext/standard/rand.c
> index bc32f24..2dd05e7 100644
> --- a/ext/standard/rand.c
> +++ b/ext/standard/rand.c
> @@ -146,7 +146,7 @@ PHPAPI zend_long php_rand(void)
> #define loBits(u) ((u) & 0x7FFFU) /* mask the highest bit of
> u */
> #define mixBits(u, v) (hiBit(u)|loBits(v)) /* move hi bit of u to hi bit of
> v */
>
> -#define twist(m,u,v) (m ^ (mixBits(u,v)>>1) ^
> ((php_uint32)(-(php_int32)(loBit(v))) & 0x9908b0dfU))
> +#define twist(m,u,v) (m ^ (mixBits(u,v)>>1) ^
> ((php_uint32)(-(php_int32)(loBit(u))) & 0x9908b0dfU))
>
> /* {{{ php_mt_initialize
> */
> diff --git a/ext/standard/tests/math/mt_rand_value.phpt
> b/ext/standard/tests/math/mt_rand_value.phpt
> deleted file mode 100644
> index eeb009e..000
> --- a/ext/standard/tests/math/mt_rand_value.phpt
> +++ /dev/null
> @@ -1,53 +0,0 @@
> ---TEST--
> -Test mt_rand() - returns the exact same values as mt19937ar.c
> ---FILE--
> - -
> -mt_srand(12345678);
> -
> -for ($i=0; $i<16; $i++) {
> -echo mt_rand().PHP_EOL;
> -}
> -echo PHP_EOL;
> -
> -$x = 0;
> -for ($i=0; $i<1024; $i++) {
> -$x ^= mt_rand();
> -}
> -echo $x.PHP_EOL;
> -
> -/*
> -excpect values are obtained from original mt19937ar.c as follows:
> -
> -int i, x;
> -init_genrand(12345678);
> -for (i=0; i<16; i++) {
> -printf("%d\n", genrand_int31());
> -}
> -printf("\n");
> -x = 0;
> -for (i=0; i<1024; i++) {
> -x ^= genrand_int31();
> -}
> -printf("%d\n", x);
> -*/
> -?>
> ---EXPECTF--
> -527860569
> -1711027313
> -1280820687
> -688176834
> -770499160
> -412773096
> -813703253
> -898651287
> -52508912
> -757323740
> -511765911
> -274407457
> -833082629
> -1923803667
> -1461450755
> -1301698200
> -
> -1612214270
>
>
> --
> PHP CVS Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] com php-src: Revert "Fix #71152: mt_rand() returns thedifferent values from original mt19937ar.c": ext/standard/rand.c ext/standard/tests/math/mt_rand_value.phpt
Hi Yasuo, Yasuo Ohgaki wrote: This should be discussed in internals. MT rand being not MT rand is unacceptable. This fix must included in released versions. IMHO. In any case we should provide broken MT rand, we must use INI switch or other options. PHP's implementation of the Mersenne Twister algorithm is buggy, so it doesn't produce the same output as in other languages. But the buggy algorithm produces sufficiently random sequences of apparently the same quality as the proper algorithm. So we *could* simply consider this as a documentation issue if we wanted to. I'm not saying that's the right course of action, though. Thanks. -- Andrea Faulds https://ajf.me/ -- 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: Revert "Fix #71152: mt_rand() returns thedifferent values from original mt19937ar.c": ext/standard/rand.c ext/standard/tests/math/mt_rand_value.phpt
Hi all,
On Sat, Feb 20, 2016 at 10:39 AM, Andrea Faulds wrote:
>
> Yasuo Ohgaki wrote:
>>
>> This should be discussed in internals.
>> MT rand being not MT rand is unacceptable.
>> This fix must included in released versions. IMHO.
>>
>> In any case we should provide broken MT rand, we must use INI switch
>> or other options.
>
>
> PHP's implementation of the Mersenne Twister algorithm is buggy, so it
> doesn't produce the same output as in other languages. But the buggy
> algorithm produces sufficiently random sequences of apparently the same
> quality as the proper algorithm. So we *could* simply consider this as a
> documentation issue if we wanted to. I'm not saying that's the right course
> of action, though.
It seems good enough for quick analysis via ent.
Note: Ent tests per "byte", not php_uint32.
http://www.fourmilab.ch/random/
WITH FIX
[yohgaki@dev rand]$ ~/git/oss/php.net/php-src/php-bin -r '$i =
100;while($i--) echo pack("I", mt_rand());' | ./ent
Entropy = 7.954269 bits per byte.
Optimum compression would reduce the size
of this 400 byte file by 0 percent.
Chi square distribution for 400 samples is 250901.85, and randomly
would exceed this value less than 0.01 percent of the times.
Arithmetic mean value of data bytes is 111.4725 (127.5 = random).
Monte Carlo value for Pi is 3.486975487 (error 10.99 percent).
Serial correlation coefficient is -0.049294 (totally uncorrelated = 0.0).
WITHOUT FIX
[yohgaki@dev rand]$ php -r '$i = 100;while($i--) echo pack("I",
mt_rand());' | ./ent
Entropy = 7.954382 bits per byte.
Optimum compression would reduce the size
of this 400 byte file by 0 percent.
Chi square distribution for 400 samples is 250280.94, and randomly
would exceed this value less than 0.01 percent of the times.
Arithmetic mean value of data bytes is 111.5000 (127.5 = random).
Monte Carlo value for Pi is 3.483663484 (error 10.89 percent).
Serial correlation coefficient is -0.049192 (totally uncorrelated = 0.0).
I'm not sure if this result is good enough to say "It's ok".
MT rand has very long cycle and this quick test does not prove it.
Did anyone do better analysis?
Otherwise, I'm uncomfortable with basic algorithm change.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
