Re: [PHP-DEV] Re: [RFC] Deprecations for PHP 7.1

[Yasuo Ohgaki]

Hi,

On Wed, Feb 24, 2016 at 9:48 AM, Stanislav Malyshev  wrote:
>> foot, by discarding possibly important information when serialising - an
>> operation that's supposed to perfectly reproduce a value!
>
> I'm not sure this is correct. Also, for values that are not exactly
> representable in binary, I'm not sure you want to see
> 0.155511151231257827021181583404541015625 instead of
> 0.1. You certainly don't want var_dump to print that by default - this
> would make display cluttred and have very high WTF factor - why I
> entered 0.1 and get this enormous snake of a number? PHP must be broken!
> Moreover, when you do "$a = 8.2 - 0.2" and then print/send $a, do you
> want to see 8 or 7.99911182158029987476766109466552734375?
>
> In fact, when we represent 0.1 as 0.1 when serializing our outputting,
> we are not discarding information, on the contrary - we are preserving
> exactly the information that was given to us by user.
>
>> print floats to their full precision - including in var_dump(). This can
>> create unreasonable confusion when debugging (why are two numbers that
>> appear identical with var_dump() reported as inequal?), means
>
> You really think that displaying 8.2 - 0.2 as 8 is more confusing than
> displaying it as 7.99911182158029987476766109466552734375?
>
>> potentially important information is removed by default, and really
>> ought not to be a global setting anyway: if you want to format your
>> numbers with reduced precision, do so explicitly.
>
> That would mean optimizing for case that nobody wants, and de-optimizing
> case that pretty much everybody wants. Ask 100 people using PHP what
> they want as a result of 8.2 - 0.2 and count how many of them want to
> see full-precision monster of a number.
>
>> There might be others worth dealing with, too, these are just the first
>> three I thought of.
>
> I would very much advise not to mess with any options until we are
> definitely, 100%, without any doubt sure that nobody needs to use it for
> anything. Removing options earns us nothing in terms of functionality.
> If nobody uses them - ok, fine - drop them. If we need to remove them
> e.g. because component they address goes away or changes function in a
> way that makes it irrelevent - fine, drop them. But doing it just
> because very small number of people that we can engage in discussion on
> the list (and that's not going to ever change - PHP user community is
> vastly larger than people even reading this list, let alone actively
> participating in it) think it's not needed IMHO is a very wrong
> approach. Sometimes we have no choice but to take decisions with this
> incomplete knowledge - but here we have a perfectly good option of just
> leaving it alone. All other options should be weighted against it.

This discussion is related to

https://wiki.php.net/rfc/precise_float_value

If you have comment on this, I appreciate it.
Please search old thread for discussions.
I'll start final RFC discussion for this when session RFC is finished.

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC] Deprecations for PHP 7.1

[Yasuo Ohgaki]

Hi,

On Wed, Feb 24, 2016 at 11:37 AM, Net Mo  wrote:
> I'd also deprecate anything related to passing the session id in query
> strings in ext/session and have it only working with cookies.
>
> session.use_cookies
> session.use_only_cookies
> url_rewriter.tags
> and possibly also arg_separator.* if related

These settings are mandatory for session module to work correctly.

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: PRNG: Raise warning and/or provide better pseudorandom generator?

[Yasuo Ohgaki]

Hi Tom,

On Wed, Feb 24, 2016 at 9:57 AM, Tom Worster  wrote:
> On 2/23/16 7:13 PM, Yasuo Ohgaki wrote:
>
>>> >http://www.pcg-random.org/
>>
>> It's simple and supports 64bit int out of the box.
>> Looks great!
>
>
> PSG is very interesting. But it's new and hasn't been peer reviewed yet.
> It's in the "experimental" stage while others are more "well known".
>
> xorshift+ seems fairly popular.

It looks excellent.
We may be better to provide better repeatable pseudo random generators and
algorithm may be select-able like hash.

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: [RFC] Deprecations for PHP 7.1

[Net Mo]

I'd also deprecate anything related to passing the session id in query
strings in ext/session and have it only working with cookies.

session.use_cookies
session.use_only_cookies
url_rewriter.tags
and possibly also arg_separator.* if related

Re: [PHP-DEV] Re: [RFC] Deprecations for PHP 7.1

[Andrea Faulds]

Hi Stas,

Stanislav Malyshev wrote:

Hi!


foot, by discarding possibly important information when serialising - an
operation that's supposed to perfectly reproduce a value!


I'm not sure this is correct. Also, for values that are not exactly
representable in binary, I'm not sure you want to see
0.155511151231257827021181583404541015625 instead of
0.1.


This assumes we would print an exact decimal representation, but that's 
far more than necessary. In order to get the same result when converted 
back to a float, we need at most 17 digits. In many cases we don't even 
need to show 17, because there are not that many digits in a 
full-precision decimal representation (e.g. 0.5). We could use less in 
many cases if PHP were to switch to the approach other languages use, 
where we output only the shortest sequence of digits producing the same 
value when converted back to a float (whereas currently we output in 
full precision, up to 17 significant figures).



You certainly don't want var_dump to print that by default - this
would make display cluttred and have very high WTF factor


Why would displaying at most three extra digits have a "high WTF factor"?


- why I
entered 0.1 and get this enormous snake of a number?

 PHP must be broken!

var_dump() is a debugging function. If it shows a value, it must 
represent it accurately. Otherwise:


$ php -r 'var_dump(1.02, 1.01, 1.01 
=== 1.02);'

float(1)
float(1)
bool(true)

Please explain to me why this is intuitive and reasonable behaviour for 
a debugging function.


Furthermore, if PHP developers find floating-point confusing and are 
genuinely surprised that 0.1 cannot be represented in binary exactly, 
then perhaps they should go and learn about what floating-point numbers 
do, rather than naïvely continuing on thinking they're decimals thanks 
to PHP lying to them! It is not the job of the language to try and hide 
that floats are imprecise from programmers.



Moreover, when you do "$a = 8.2 - 0.2" and then print/send $a, do you
want to see 8 or 7.99911182158029987476766109466552734375?


Let's look at what our contemporary programming languages do.

Python:

>>> 8.2 - 0.2
7.999

JavaScript:

8.2 - 0.2
7.999

That's much shorter than your suggestion.

Heck, let's look at what var_export() does:

$ php -r 'var_export(8.2 - 0.2);'
7.9991

Still a lot shorter.


In fact, when we represent 0.1 as 0.1 when serializing our outputting,


But we don't represent 0.1 as 0.1:

$ php -r 'var_export(0.1);'
0.10001


we are not discarding information, on the contrary - we are preserving
exactly the information that was given to us by user.


$ php -r 'var_dump(1.02);'
float(1)

That doesn't look very preserved to me.




print floats to their full precision - including in var_dump(). This can
create unreasonable confusion when debugging (why are two numbers that
appear identical with var_dump() reported as inequal?), means


You really think that displaying 8.2 - 0.2 as 8 is more confusing than
displaying it as 7.99911182158029987476766109466552734375?


It's more *honest*. If two values are different, they should not be 
displayed the same.


And, again, the result would not be that large:

$ php -r 'var_export(8.2 - 0.2);'
7.9991




potentially important information is removed by default, and really
ought not to be a global setting anyway: if you want to format your
numbers with reduced precision, do so explicitly.


That would mean optimizing for case that nobody wants, and de-optimizing
case that pretty much everybody wants.


Who wants to round numbers to the same precision in all situations, for 
all apps running on their server, for all code running within a given 
request, even in libraries?



Ask 100 people using PHP what
they want as a result of 8.2 - 0.2 and count how many of them want to
see full-precision monster of a number.


"7.9991" isn't that monstrous, and it could be even less so 
if PHP used a nicer float-to-string conversion approach.





There might be others worth dealing with, too, these are just the first
three I thought of.


I would very much advise not to mess with any options until we are
definitely, 100%, without any doubt sure that nobody needs to use it for
anything. Removing options earns us nothing in terms of functionality.
If nobody uses them - ok, fine - drop them. If we need to remove them
e.g. because component they address goes away or changes function in a
way that makes it irrelevent - fine, drop them. But doing it just
because very small number of people that we can engage in discussion on
the list (and that's not going to ever change - PHP user community is
vastly larger than people even reading this list, let alone actively
participating in it) think it's not needed IMHO is a very wrong
approach.


This might be a fine argument, but I'm not 

Re: [PHP-DEV] Re: PRNG: Raise warning and/or provide better pseudorandom generator?

[Tom Worster]

On 2/23/16 7:13 PM, Yasuo Ohgaki wrote:


>http://www.pcg-random.org/

It's simple and supports 64bit int out of the box.
Looks great!


PSG is very interesting. But it's new and hasn't been peer reviewed yet. 
It's in the "experimental" stage while others are more "well known".


xorshift+ seems fairly popular.

Tom

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC] Deprecations for PHP 7.1

[Stanislav Malyshev]

Hi!

> foot, by discarding possibly important information when serialising - an
> operation that's supposed to perfectly reproduce a value!

I'm not sure this is correct. Also, for values that are not exactly
representable in binary, I'm not sure you want to see
0.155511151231257827021181583404541015625 instead of
0.1. You certainly don't want var_dump to print that by default - this
would make display cluttred and have very high WTF factor - why I
entered 0.1 and get this enormous snake of a number? PHP must be broken!
Moreover, when you do "$a = 8.2 - 0.2" and then print/send $a, do you
want to see 8 or 7.99911182158029987476766109466552734375?

In fact, when we represent 0.1 as 0.1 when serializing our outputting,
we are not discarding information, on the contrary - we are preserving
exactly the information that was given to us by user.

> print floats to their full precision - including in var_dump(). This can
> create unreasonable confusion when debugging (why are two numbers that
> appear identical with var_dump() reported as inequal?), means

You really think that displaying 8.2 - 0.2 as 8 is more confusing than
displaying it as 7.99911182158029987476766109466552734375?

> potentially important information is removed by default, and really
> ought not to be a global setting anyway: if you want to format your
> numbers with reduced precision, do so explicitly.

That would mean optimizing for case that nobody wants, and de-optimizing
case that pretty much everybody wants. Ask 100 people using PHP what
they want as a result of 8.2 - 0.2 and count how many of them want to
see full-precision monster of a number.

> There might be others worth dealing with, too, these are just the first
> three I thought of.

I would very much advise not to mess with any options until we are
definitely, 100%, without any doubt sure that nobody needs to use it for
anything. Removing options earns us nothing in terms of functionality.
If nobody uses them - ok, fine - drop them. If we need to remove them
e.g. because component they address goes away or changes function in a
way that makes it irrelevent - fine, drop them. But doing it just
because very small number of people that we can engage in discussion on
the list (and that's not going to ever change - PHP user community is
vastly larger than people even reading this list, let alone actively
participating in it) think it's not needed IMHO is a very wrong
approach. Sometimes we have no choice but to take decisions with this
incomplete knowledge - but here we have a perfectly good option of just
leaving it alone. All other options should be weighted against it.

-- 
Stas Malyshev
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: PRNG: Raise warning and/or provide better pseudo random generator?

[Yasuo Ohgaki]

Hi all,

On Tue, Feb 23, 2016 at 7:41 PM, Yasuo Ohgaki  wrote:
> Any comments for adding out of range warnings to rand()/mt_rand()? If
> nobody has comment on this, I'll write RFC for additional warnings.
> Anyone prefer to extend rand()/mt_rand() for 64bit OSes?

I'll write RFC to raise errors for invalid range, hopefully this weekend.

Thank you for feedback!

--
Yasuo Ohgaki
yohg...@ohgaki.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: PRNG: Raise warning and/or provide better pseudo random generator?

[Yasuo Ohgaki]

Hi Scott,

On Tue, Feb 23, 2016 at 11:36 PM, Scott Arciszewski  wrote:
>
> If we're going to consider new non-cryptographic random number
> generators, PCG is worth considering. ;)
>
> http://www.pcg-random.org/

It's simple and supports 64bit int out of the box.
Looks great!

--
Yasuo Ohgaki
yohg...@ohgaki.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: [RFC] Deprecations for PHP 7.1

[Andrea Faulds]

Hi Nikita,

Nikita Popov wrote:

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.


I think this would be a good opportunity to look at our existing php.ini 
directives, with view to getting rid of some more of them eventually.


Three in particular spring to mind:

* `precision` and `serialize_precision` - These determine how many 
digits are printed when outputting floating-point numbers.
  - `serialize_precision` is used when serialising or exporting 
numbers, and would seem to exist solely to allow you to shoot yourself 
in the foot, by discarding possibly important information when 
serialising - an operation that's supposed to perfectly reproduce a value!
  - `precision` is used in other contexts, and is more problematic, 
because its default value is 14 which is less than the maximum number of 
decimal digits in a PHP float. This means that, by default, PHP doesn't 
print floats to their full precision - including in var_dump(). This can 
create unreasonable confusion when debugging (why are two numbers that 
appear identical with var_dump() reported as inequal?), means 
potentially important information is removed by default, and really 
ought not to be a global setting anyway: if you want to format your 
numbers with reduced precision, do so explicitly.
  - Both of these are settings which code may implicitly depend on and 
break when they are changed. The manual is unhelpful here, because it 
doesn't warn you that `precision` is used when floats on any page except 
that for php.ini!
* `mbstring.func_overload` - This piece of magic replaces the standard 
string functions with their mb_* equivalents. It is the character 
encodings equivalent of magic quotes: it simply assumes that all string 
operations on binary strings, if replaced by "multi-byte" versions, will 
suddenly handle character encodings properly. They won't necessarily, so 
this is quite a reckless setting. Worse, this setting prevents you from 
using the normal, non-"multi-byte" string functions when you need them 
for binary data, so PHP packages which deal with binary data are broken 
when this php.ini setting is turned on. Luckily, apps which rely on this 
setting being on could be easily fixed: by using find/replace.


There might be others worth dealing with, too, these are just the first 
three I thought of.


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-23

[lp_benchmark_robot]

Results for project PHP master, build date 2016-02-23 06:31:31+02:00
commit: 2d1559f
previous commit:6ae4c11
revision date:  2016-02-22 19:40:32+01: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.21%  0.57%  1.32%  
  5.86%
:-|   Drupal 7.36 cgi -T1  0.17%  0.38%  0.33%  
  3.95%
:-|   MediaWiki 1.23.9 cgi -T5000  0.13%  0.22%  1.75%  
  2.69%
:-|   bench.php cgi -T100  0.01% -0.19%  3.40%  
  5.11%
:-|  micro_bench.php cgi -T10  0.00%  0.05%  2.91%  
  3.11%
:-|  mandelbrot.php cgi -T100  0.02% -0.09%-14.19%  
  4.31%
---
* 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-23/

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] Re: PRNG: Raise warning and/or provide better pseudorandom generator?

[Tom Worster]

I agree that mt_rand() should warn before delivering bogus outputs. But 
when it works, it works ok:


https://gist.github.com/tom--/a12175047578b3ae9ef8

Given that it hasn't been MT19937 or many years, it probably doesn't 
need to be.


If there is really a need for fast repeatable RNGs (the kind popular in 
monte-carlo sims) then MT is no longer the most likely candidate. A new 
API could allow the user to select a generator -- there are a lot to 
chose from (see below)!


Tom


These are the built-in generators in dieharder 3.31.1. Note the xorshift 
family isn't present. Melissa O’'Neill's new PCG family is interesting too.



000 borosh13
001 cmrg
002 coveyou
003 fishman18
004 fishman20
005 fishman2x
006 gfsr4
007 knuthran
008 knuthran2
009 knuthran2002
010 lecuyer21
011 minstd
012 mrg
013 mt19937
014 mt19937_1999
015 mt19937_1998
016 r250
017 ran0
018 ran1
019 ran2
020 ran3
021 rand
022 rand48
023 random128-bsd
024 random128-glibc2
025 random128-libc5
026 random256-bsd
027 random256-glibc2
028 random256-libc5
029 random32-bsd
030 random32-glibc2
031 random32-libc5
032 random64-bsd
033 random64-glibc2
034 random64-libc5
035 random8-bsd
036 random8-glibc2
037 random8-libc5
038 random-bsd
039 random-glibc2
040 random-libc5
041 randu
042 ranf
043 ranlux
044 ranlux389
045 ranlxd1
046 ranlxd2
047 ranlxs0
048 ranlxs1
049 ranlxs2
050 ranmar
051 slatec
052 taus
053 taus2
054 taus113
055 transputer
056 tt800
057 uni
058 uni32
059 vax
060 waterman14
061 zuf
203 ca
204 uvag
205 AES_OFB
206 Threefish_OFB
207 XOR (supergenerator)
208 kiss
209 superkiss
400 R_wichmann_hill
401 R_marsaglia_multic.
402 R_super_duper
403 R_mersenne_twister
404 R_knuth_taocp
405 R_knuth_taocp2


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: PRNG: Raise warning and/or provide better pseudo random generator?

[Scott Arciszewski]

On Tue, Feb 23, 2016 at 7:46 AM, Pierre Joye  wrote:
> hi,
>
> On Tue, Feb 23, 2016 at 5:41 PM, Yasuo Ohgaki  wrote:
>> Hi all,
>>
>> On Tue, Feb 23, 2016 at 6:30 AM, Yasuo Ohgaki  wrote:
>>>
>>> We have issue on pseudo random generators generates only odd/even
>>> numbers.
>>>
>>> https://bugs.php.net/bug.php?id=63174
>>> https://news.ycombinator.com/item?id=9941364
>>>
>>> We should raise E_WARNING/E_NOTICE if user supplies random number
>>> range that generated random number cannot be random at least.
>>> Patch for rand/mt_rand.
>>> https://gist.github.com/yohgaki/1519f65dffd66735bafe
>>>
>>> It seems we need more reliable(fool proof) pseudo random generator.
>>> Anyone working on this?
>>>
>>> We may extends rand()/mt_rand() so that they work with larger range by
>>> calling random generators multiple times. If this is implemented, the
>>> patch raises errors is not required. mt_rand() extension breaks 
>>> compatibility
>>> with other MT rand implementations, but we already broke it. Therefore, it
>>> should not matter. (This was the reason why mt_rand() wasn't made to support
>>> 64bit int, IIRC)
>>>
>>> IMO, we should provide better pseudo random generators than now.
>>>
>>> Any comments?
>>
>> This is edge case that produces odd/even numbers only.
>> https://3v4l.org/kYpAF
>> This is the worst case. Current implementation uses 32bit int for
>> generating random numbers and any number exceeds the range could be
>> biased because the result is computed by RAND_RANGE() which uses
>> double for arithmetic. PHP allows huge min/max without any
>> warning/error under 64bit OS.
>>
>> Limiting range can prevent this and we can be sure rand()/mt_rand()
>> produce the same random numbers on both 32/64 bit platform. (If rand()
>> uses the same algorithm, of course)
>> https://gist.github.com/yohgaki/1519f65dffd66735bafe
>> Valid range is limited to 2^31 according to current implementation.
>>
>> Actual range could be determined by PHP_RAND_MAX/PHP_MT_RAND_MAX, but
>> I heard Windows' PHP_RAND_MAX is only 2^15. Is this correct? I don't
>> prefer to have strict range error for these systems. I'll write patch
>> that does not raise warning for smaller PHP_RAND_MAX. It's unreliable
>> pseudo random generator anyway. It should not matter much.
>>
>>
>> Any comments for adding out of range warnings to rand()/mt_rand()? If
>> nobody has comment on this, I'll write RFC for additional warnings.
>> Anyone prefer to extend rand()/mt_rand() for 64bit OSes?
>
> Thing is the MT algorithm may not be design to do that, at all but was
> designed for 32-bit integers. I won't be in favor of changing (again)
> the implementation without any safety about the results (safety means
> compliance or be even more different from the MT algorithms).
>
> Adding warning when the given ranges are out of bounds sound good, and
> reduce them within the maximum range.
>
> I joined the other person proposing not to change anything else in our
> MT implementation as there is little to no benefit.
>
> If we need pure implementation of one pseudo RNG or another, we can
> provide new implementations. But changing again this one may bring
> more troubles than what we are trying to solve.
>
>
> Cheers,
> --
> Pierre
>
> @pierrejoye | http://www.libgd.org
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

If we're going to consider new non-cryptographic random number
generators, PCG is worth considering. ;)

http://www.pcg-random.org/

Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises 

-- 
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 Schneider]

Am 21.02.2016 um 11:42 schrieb Anatol Belski :
>> -Original Message-
>> From: Ángel González [mailto:keis...@gmail.com]
>> Sent: Sunday, February 21, 2016 1:27 AM
>> To: Anatol Belski 
>> Cc: 'Christian Schneider' ; 'PHP internals'
>> 
>> Subject: Re: [PHP-DEV] PCRE jit bug with UTF-8 and lookbehind assertion
>> 
>> On 19/02/16 09:20, Anatol Belski wrote:
>>> Could you please write back, what is the out difference between those
>>> two commands? Thanks. Anatol
>> In the first case, it correctly outputs «x°11» (78 c2 b0 7a). With jit 
>> enabled it
>> produces «x z» (78 c2 7a). That is, it is only outputting the lower byte of 
>> the utf-8
>> encoding of the U+00B0 character Tested on PHP 7.0.3 using the system libpcre
>> 8.38
>> 
> Were you putting the snippets into a file or testing on the console? I had an 
> issue while testing this on the console, that some chars was partially 
> swallowed by terminal (which was a utf-8 terminal). When putting into a file, 
> the output is same for both - "x°z". Please see also the continued discussion 
> in the original ticket https://bugs.exim.org/show_bug.cgi?id=1189 . The 
> offsets delivered by PCRE also seem to be correct,  and valgrind doesn't find 
> anything. It were great if you could confirm these insights.

I can reproduce it in a console and in a file.

PCRE Library Version => 8.38 2015-11-23

I also reproduced it with a C program directly using the system PCRE library, 
no PHP involved.
I attached the C source to https://bugs.exim.org/show_bug.cgi?id=1189

Regards,
- Chris


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: PRNG: Raise warning and/or provide better pseudo random generator?

[Pierre Joye]

hi,

On Tue, Feb 23, 2016 at 5:41 PM, Yasuo Ohgaki  wrote:
> Hi all,
>
> On Tue, Feb 23, 2016 at 6:30 AM, Yasuo Ohgaki  wrote:
>>
>> We have issue on pseudo random generators generates only odd/even
>> numbers.
>>
>> https://bugs.php.net/bug.php?id=63174
>> https://news.ycombinator.com/item?id=9941364
>>
>> We should raise E_WARNING/E_NOTICE if user supplies random number
>> range that generated random number cannot be random at least.
>> Patch for rand/mt_rand.
>> https://gist.github.com/yohgaki/1519f65dffd66735bafe
>>
>> It seems we need more reliable(fool proof) pseudo random generator.
>> Anyone working on this?
>>
>> We may extends rand()/mt_rand() so that they work with larger range by
>> calling random generators multiple times. If this is implemented, the
>> patch raises errors is not required. mt_rand() extension breaks compatibility
>> with other MT rand implementations, but we already broke it. Therefore, it
>> should not matter. (This was the reason why mt_rand() wasn't made to support
>> 64bit int, IIRC)
>>
>> IMO, we should provide better pseudo random generators than now.
>>
>> Any comments?
>
> This is edge case that produces odd/even numbers only.
> https://3v4l.org/kYpAF
> This is the worst case. Current implementation uses 32bit int for
> generating random numbers and any number exceeds the range could be
> biased because the result is computed by RAND_RANGE() which uses
> double for arithmetic. PHP allows huge min/max without any
> warning/error under 64bit OS.
>
> Limiting range can prevent this and we can be sure rand()/mt_rand()
> produce the same random numbers on both 32/64 bit platform. (If rand()
> uses the same algorithm, of course)
> https://gist.github.com/yohgaki/1519f65dffd66735bafe
> Valid range is limited to 2^31 according to current implementation.
>
> Actual range could be determined by PHP_RAND_MAX/PHP_MT_RAND_MAX, but
> I heard Windows' PHP_RAND_MAX is only 2^15. Is this correct? I don't
> prefer to have strict range error for these systems. I'll write patch
> that does not raise warning for smaller PHP_RAND_MAX. It's unreliable
> pseudo random generator anyway. It should not matter much.
>
>
> Any comments for adding out of range warnings to rand()/mt_rand()? If
> nobody has comment on this, I'll write RFC for additional warnings.
> Anyone prefer to extend rand()/mt_rand() for 64bit OSes?

Thing is the MT algorithm may not be design to do that, at all but was
designed for 32-bit integers. I won't be in favor of changing (again)
the implementation without any safety about the results (safety means
compliance or be even more different from the MT algorithms).

Adding warning when the given ranges are out of bounds sound good, and
reduce them within the maximum range.

I joined the other person proposing not to change anything else in our
MT implementation as there is little to no benefit.

If we need pure implementation of one pseudo RNG or another, we can
provide new implementations. But changing again this one may bring
more troubles than what we are trying to solve.


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] Adopt Ruby Code of Conduct

[Matt Prelude]

Hi,

On 19/02/16 13:08, benjamin barber wrote:

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



What can 'reasonably' be considered harassment differs from person to 
person.


What does 'will not be tolerated' mean? Does this CoC come with a set of
teeth? Where is it enforceable?

I support the intention to avoid creating a way to police peoples' politics,
but there is ambiguity here.

- Matt.

Re: [PHP-DEV] Adopt Ruby Code of Conduct

[Rowan Collins]

benjamin barber wrote on 19/02/2016 13:08:

The Ruby Community Conduct Guideline
We have picked the following conduct guideline based on an early draft of
the PostgreSQL CoC


It's interesting to know what other communities are doing. I understand 
Postgres are in a similar position to us - they have some initial 
principles, and are discussing what if any formal Code of Conduct to 
build on top of them. It sounds like Ruby have picked up those principles.




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


I'm not sure what this link is intended to demonstrate. Without reading 
every message on the referenced thread, I can't tell whether the warning 
was valid; and without knowing anything about the CoC in question, or 
the structure of that particular community, I have no idea what 
authority that poster had to give the warning, and what the implications 
of doing so are. I certainly don't see any individuals being "labeled" 
in that post, or any suggestion that the technical merit of their 
arguments should be ignored.


Regards,
--
Rowan Collins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: PRNG: Raise warning and/or provide better pseudo random generator?

[Christoph Becker]

On 23.02.2016 at 11:41, Yasuo Ohgaki wrote:

> Actual range could be determined by PHP_RAND_MAX/PHP_MT_RAND_MAX, but
> I heard Windows' PHP_RAND_MAX is only 2^15. Is this correct? 

Yes, see .

> Any comments for adding out of range warnings to rand()/mt_rand()? If
> nobody has comment on this, I'll write RFC for additional warnings.
> Anyone prefer to extend rand()/mt_rand() for 64bit OSes?

See also the discussion for ;
it might make sense to disallow such ranges in the long run (i.e. for
PHP 8), in which case we might want to raise deprecated notices instead
of warnings now.

-- 
Christoph M. Becker

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: PRNG: Raise warning and/or provide better pseudo random generator?

[Yasuo Ohgaki]

Hi all,

On Tue, Feb 23, 2016 at 6:30 AM, Yasuo Ohgaki  wrote:
>
> We have issue on pseudo random generators generates only odd/even
> numbers.
>
> https://bugs.php.net/bug.php?id=63174
> https://news.ycombinator.com/item?id=9941364
>
> We should raise E_WARNING/E_NOTICE if user supplies random number
> range that generated random number cannot be random at least.
> Patch for rand/mt_rand.
> https://gist.github.com/yohgaki/1519f65dffd66735bafe
>
> It seems we need more reliable(fool proof) pseudo random generator.
> Anyone working on this?
>
> We may extends rand()/mt_rand() so that they work with larger range by
> calling random generators multiple times. If this is implemented, the
> patch raises errors is not required. mt_rand() extension breaks compatibility
> with other MT rand implementations, but we already broke it. Therefore, it
> should not matter. (This was the reason why mt_rand() wasn't made to support
> 64bit int, IIRC)
>
> IMO, we should provide better pseudo random generators than now.
>
> Any comments?

This is edge case that produces odd/even numbers only.
https://3v4l.org/kYpAF
This is the worst case. Current implementation uses 32bit int for
generating random numbers and any number exceeds the range could be
biased because the result is computed by RAND_RANGE() which uses
double for arithmetic. PHP allows huge min/max without any
warning/error under 64bit OS.

Limiting range can prevent this and we can be sure rand()/mt_rand()
produce the same random numbers on both 32/64 bit platform. (If rand()
uses the same algorithm, of course)
https://gist.github.com/yohgaki/1519f65dffd66735bafe
Valid range is limited to 2^31 according to current implementation.

Actual range could be determined by PHP_RAND_MAX/PHP_MT_RAND_MAX, but
I heard Windows' PHP_RAND_MAX is only 2^15. Is this correct? I don't
prefer to have strict range error for these systems. I'll write patch
that does not raise warning for smaller PHP_RAND_MAX. It's unreliable
pseudo random generator anyway. It should not matter much.

Any comments for adding out of range warnings to rand()/mt_rand()? If
nobody has comment on this, I'll write RFC for additional warnings.
Anyone prefer to extend rand()/mt_rand() for 64bit OSes?

Regards

--
Yasuo Ohgaki
yohg...@ohgaki.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC] Traits with interfaces

[Chris Riley]

On 23 February 2016 at 00:37, Alex Bowers  wrote:

> Would a fair solution to this be having the using class define whether to
> inherit the implementations? Perhaps a new keyword akin to 'propagated', so
> the code will read
>
> Class Foo {
>Use propagated TraitName;
> }
>
> Only then will the implementations from that trait bubble through. If it
> isn't declared then the implementations are not visible. This should keep
> all backwards compatibility and keep code readable since now we can
> immediately tell which traits being used do we want the implementations for
> in the main class.
> On 22 Feb 2016 20:19, "Kevin Gessner"  wrote:
>
> > On Thu, Feb 18, 2016 at 4:13 PM, Kevin Gessner 
> wrote:
> >
> > > On Wed, Feb 17, 2016 at 2:05 PM, Kevin Gessner 
> > wrote:
> > >
> > >> I've created a proper RFC wiki page here with the draft:
> > >> https://wiki.php.net/rfc/traits-with-interfaces
> > >>
> > >> It includes more detail and several example code snippets.  Thanks all
> > >> for your feedback so far.
> > >>
> > >
> > > I've just updated the RFC to v0.2, presenting two proposals to be voted
> > > separately: one to allow traits to declare and implement interfaces,
> and
> > a
> > > second (dependent on the first) to propagate interface declarations
> from
> > > traits to classes.
> > >
> >
> > I've created a php-src pull request for Proposal 1 of the RFC, allowing
> > traits to declare and implement interfaces:
> > https://github.com/php/php-src/pull/1773
> >
> > Reviews and feedback welcome!
> >
> > I haven't yet started on an implementation for Proposal 2.
> >
> > Cheers
> > -- Kevin
> >
>

This isn't such a great idea as it will cause some of traits functionality
to be broken: I can currently use a trait and alias its methods and change
their visibility. If a trait implements an interface which is copied onto
my class I can no longer do this as the compiler will throw a fatal error
for the class not correctly implementing the interface that got copied from
the trait.

If you decide to continue pursuing this RFC, I'd like to see some thought
given to the above; perhaps it could be as simple as not copying the
interface if aliases/visibility changes are made in the use or perhaps
something more complex which allows specifying which interfaces should be
copied into the class from the trait.

~C