Re: [PHP-DEV] bugsnet cleanup

Am 08.01.2017 um 07:46 schrieb Joe Watkins: > I think any bug report opened against 4 and not updated is useless. +1 > I think anything with a patch attached targeting 5 is useless, regardless > of age; they should be encouraged to open a pull request on github against > a supported branch. +1

Re: [PHP-DEV] bugsnet cleanup

On Jan 8, 2017 7:47 AM, "Joe Watkins" wrote: Morning internals, Some of you may have noticed that a few of us have put considerable effort into cleanup of pull requests on github, these are now manageable and I'm quite confident that we will be able to merge pull requests in a timely manner, and

Re: [PHP-DEV][RFC][VOTE] Throwable error code's type generalization

> > linking to the discussion thread http://externals.io/thread/573 because I > don't have much more to add. > > I think the throwable's code is almost never used regardless, but this > could give users more opportunities to do something useful with it as > Niklas stated in previous thread. > Hi W

Re: [PHP-DEV] bugsnet cleanup

Afternoon Nikita, ACK, we should of course use appropriate status ... I have only closed a few so far before I thought a discussion is probably in order, so no harm done. Cheers Joe On Sun, Jan 8, 2017 at 10:29 AM, Nikita Popov wrote: > On Jan 8, 2017 7:47 AM, "Joe Watkins" wrote: > > Morning

Re: [PHP-DEV] bugsnet cleanup

Hi all. Am 08.01.17 um 11:29 schrieb Nikita Popov: > On Jan 8, 2017 7:47 AM, "Joe Watkins" wrote: > > Morning internals, […] > > With normal support for 5 ended, now is the perfect time to cleanup > bugsnet. If we can get the numbers down to something manageable, we have a > reasonable expectat

[PHP-DEV] Re: bugsnet cleanup

On 08.01.2017 at 07:46, Joe Watkins wrote: > Some of you may have noticed that a few of us have put considerable effort > into cleanup of pull requests on github, these are now manageable and I'm > quite confident that we will be able to merge pull requests in a timely > manner, and stay on top of

[PHP-DEV] Re: bugsnet cleanup

Morning Christoph, > Just wiping those under the carpet wouldn't be an improvement, in my opinion. Remember that the bugs won't go anywhere, they just won't present themselves as important to new contributors, and old alike. It's very overwhelming to see a list of five thousand things that may n

Re: [PHP-DEV] [RFC] Deprecate and remove INTL_IDNA_VARIANT_2003

On 08.01.2017 at 01:38, Sara Golemon wrote: > On Sat, Jan 7, 2017 at 6:06 AM, Christoph M. Becker wrote: >> Following up on , I have >> written the RFC >> >> >> >> and hereby placing

[PHP-DEV] Re: bugsnet cleanup

On 08.01.2017 at 14:31, Joe Watkins wrote: > Leaving them open isn't helping anyone or anything, and if it overwhelms me > to see that many, you can be pretty sure it has scared a bunch of people > away. I have to agree. Since others already have expressed to be in favor of a "mass cleanup", I'm

[PHP-DEV] [RFC][VOTE] array_change_keys

Greetings all, It's been a while since we introduced the array_change_keys RFC . During the discussion period there was a healthy mix of interest and critique. It seems all the major discussion points were covered, so I'd like to put this RFC to a vote

Re: [PHP-DEV] [RFC][VOTE] array_change_keys

Hi Colin, Voting NO for the following reasons: * Can be a userland function/library, unless there are huge performance benefits that justify it being in core * Doesn't work with `iterable` * New warnings. No, please, we want `Throwable`: warnings are terrible * Semantics for merging duplicate

Re: [PHP-DEV][RFC][VOTE] Throwable error code's type generalization

I don't see how objects are less important than strings. Many of us have enum-ish kind of objects in their code, even if php doesn't support them natively. We could consider using them as error code if this was allowed.

Re: [PHP-DEV] [RFC][VOTE] array_change_keys

Hi Marco 2017-01-08 15:43 GMT+01:00 Marco Pivetta : > * New warnings. No, please, we want `Throwable`: warnings are terrible Only really chiming in for the warnings part; warnings should not be a blocker for a new feature, because it would create an inconsistency with that function and the rest.

Re: [PHP-DEV] Use decent entropy for uniqid($prefix, TRUE)

On 2017-01-07 03:15, Yasuo Ohgaki wrote: + php_random_int(10, 99, &rand, 1); This should be + php_random_int(0, 99, &rand, 1); No, it shouldn't. That fixes none of the reported problems. You still have too many numbers (integer overflow) an

Re: [PHP-DEV] Use decent entropy for uniqid($prefix, TRUE)

Hi, >>> + zend_long rand; >>> + php_random_int(10, 99, &rand, 1); >>> + uniqid = strpprintf(0, "%s%08x%05x%.8F", prefix, sec, >>> usec, (double)rand/100); >> >> Your code is broken. It produces 0.1000 - 0. when it should

Re: [PHP-DEV][RFC][VOTE] Throwable error code's type generalization

2017-01-08 16:20 GMT+01:00 Wes : > I don't see how objects are less important than strings. Many of us have > enum-ish kind of objects in their code, even if php doesn't support them > natively. We could consider using them as error code if this was allowed. > An object is nothing I can really st

Re: [PHP-DEV][RFC][VOTE] Throwable error code's type generalization

Yes, you can. http://php.net/manual/en/language.oop5.magic.php#object.tostring :P

Re: [PHP-DEV] Use decent entropy for uniqid($prefix, TRUE)

On Mon, Jan 9, 2017 at 2:29 AM, Lauri Kenttä wrote: > On 2017-01-07 03:15, Yasuo Ohgaki wrote: > >> + php_random_int(10, 99, &rand, 1); >> >> This should be >> >> + php_random_int(0, 99, &rand, 1); >> > > No, it shouldn't. That fixes none of the

Re: [PHP-DEV][RFC][VOTE] Throwable error code's type generalization

Hi Wes, 2017-01-08 15:44 GMT-04:00 Wes : > Yes, you can. > http://php.net/manual/en/language.oop5.magic.php#object.tostring :P > It's still not guaranteed that the returned value is "stringifiable" as it was before. Logging code would now need is_object + method_exist checks and so on. I'm cons

Re: [PHP-DEV] Use decent entropy for uniqid($prefix, TRUE)

Hi Kazuo, On Mon, Jan 9, 2017 at 3:15 AM, Kazuo Oishi wrote: > No. Lauri's version is better. > > Your php_random_bytes_throw() version is significantly slow. Lauri's > version is faster and cleaner. > > [original uniqid() using php_combined_lcg] > $ time ./php_uniqid_orig -r 'for($i=0; $i<100

Re: [PHP-DEV] Use decent entropy for uniqid($prefix, TRUE)

On Mon, Jan 9, 2017 at 5:31 AM, Yasuo Ohgaki wrote: > On Mon, Jan 9, 2017 at 3:15 AM, Kazuo Oishi wrote: > >> No. Lauri's version is better. >> >> Your php_random_bytes_throw() version is significantly slow. Lauri's >> version is faster and cleaner. >> >> [original uniqid() using php_combined_

Re: [PHP-DEV] Use decent entropy for uniqid($prefix, TRUE)

On Mon, Jan 9, 2017 at 5:07 AM, Yasuo Ohgaki wrote: > On Mon, Jan 9, 2017 at 2:29 AM, Lauri Kenttä > wrote: > >> On 2017-01-07 03:15, Yasuo Ohgaki wrote: >> >>> + php_random_int(10, 99, &rand, 1); >>> >>> This should be >>> >>> + php_random_int(0,

Re: [PHP-DEV] bugsnet cleanup

Hi! > I'd even go as far as saying that any bug reported for PHP < 5.6 can be > marked as "Won't fix". The bugs targeting 5.6 need to be checked whether > they have a security implication and if not they should be also marked > as "Won't fix" Lots of people run 5.5 now. I'd say at least about 2/3

Re: [PHP-DEV] bugsnet cleanup

Hi! > Some of you may have noticed that a few of us have put considerable effort > into cleanup of pull requests on github, these are now manageable and I'm > quite confident that we will be able to merge pull requests in a timely > manner, and stay on top of it. I would like to start with a big

[PHP-DEV] Re: Improving mail() 5th parameter handling

Hi all, On Sun, Jan 8, 2017 at 6:57 AM, Yasuo Ohgaki wrote: > All of us knew details of PHPMailer and Swift Mailer issues with mail()'s > 5th (additional_parameters) parameter by now, I suppose. Current behavior > (applying php_escape_shell_cmd to addtional_parameters) is not nice and > similar

Re: [PHP-DEV] Re: Improving mail() 5th parameter handling

On Sun, Jan 8, 2017 at 11:19 PM, Yasuo Ohgaki wrote: > Hi all, > > On Sun, Jan 8, 2017 at 6:57 AM, Yasuo Ohgaki wrote: > > > All of us knew details of PHPMailer and Swift Mailer issues with mail()'s > > 5th (additional_parameters) parameter by now, I suppose. Current behavior > > (applying php_e

Re: [PHP-DEV] Re: Improving mail() 5th parameter handling

Hi Nikita and all, On Mon, Jan 9, 2017 at 7:31 AM, Nikita Popov wrote: > Without this option, how do you specify the envelope sender? That seems to > be the primary use-case. Indeed, it seems it is. It could be set by mail.force_extra_parameters. I agree this isn't a great way to do, but the o

[PHP-DEV] ext/xml: libexpat support still useful?

Hi! Due to I've noticed: $ ./configure --help | grep expat | grep XML: --with-libexpat-dir=DIR XML: libexpat install prefix (deprecated) This deprecation note is apparently present as of PHP 5.0.0 at least. So I wonder whether there's a good reason to still sup

Re: [PHP-DEV] Re: Improving mail() 5th parameter handling

On Mon, Jan 9, 2017 at 7:56 AM, Yasuo Ohgaki wrote: > it will help in most cases I meant "arrayed 'addtional_parameters'" will help. -- Yasuo Ohgaki yohg...@ohgaki.net

[PHP-DEV] http://php.net/usage.php

Hi! With all this wonderful new year's work going on, should we also update (or remove, if we don't want to update it anymore) http://php.net/usage.php ? With data from 2013 it looks kind of pathetic :) -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List

[PHP-DEV] ext/gd: support creation of animated GIFs

Hi! A while ago I've grabbed up and submitted PR #2024[1]. This lay dormant until recently when Joe had a look at so many PRs (thanks!), so I'm bringing this issue to your attention. I presume nobody is opposed that ext/gd should support the creation of animated GIFs

Re: [PHP-DEV] http://php.net/usage.php

On 01/08/2017 03:51 PM, Stanislav Malyshev wrote: Hi! With all this wonderful new year's work going on, should we also update (or remove, if we don't want to update it anymore) http://php.net/usage.php ? With data from 2013 it looks kind of pathetic :) Oh wow yeah, that IMHO needs to go. I'v

Re: [PHP-DEV] Use decent entropy for uniqid($prefix, TRUE)

Hi, >>> [original uniqid() using php_combined_lcg] >>> $ time ./php_uniqid_orig -r 'for($i=0; $i<100;$i++) uniqid("",true);' >>> real0m0.366s >>> user0m0.350s >>> sys 0m0.010s >>> >>> [your php_random_bytes_throw version (commit >>> 48f1a17886d874dc90867c669481804de90509e8)] >>> $

[PHP-DEV] Re: http://php.net/usage.php

On 09.01.2017 at 00:51, Stanislav Malyshev wrote: > With all this wonderful new year's work going on, should we also update > (or remove, if we don't want to update it anymore) > http://php.net/usage.php ? With data from 2013 it looks kind of pathetic :) I can't see any particular value in this p

Re: [PHP-DEV] Re: http://php.net/usage.php

2017-01-09 2:18 GMT+01:00 Christoph M. Becker : > On 09.01.2017 at 00:51, Stanislav Malyshev wrote: > >> With all this wonderful new year's work going on, should we also update >> (or remove, if we don't want to update it anymore) >> http://php.net/usage.php ? With data from 2013 it looks kind of p

Re: [PHP-DEV] Use decent entropy for uniqid($prefix, TRUE)

Hi Kazuo, On Mon, Jan 9, 2017 at 9:27 AM, Kazuo Oishi wrote: > >>> [original uniqid() using php_combined_lcg] > >>> $ time ./php_uniqid_orig -r 'for($i=0; $i<100;$i++) > uniqid("",true);' > >>> real0m0.366s > >>> user0m0.350s > >>> sys 0m0.010s > >>> > >>> [your php_random_bytes_

Re: [PHP-DEV] bugsnet cleanup

Morning Stas, > I think we have to separate FRs and bugs. Bugs filed against older > versions (especially ones before 5.5) I'd put into feedback with request > to retest with more recent version. Feedback bugs would automatically > expire if no feedback was provided. This sounds reasonable. > FR

Re: [PHP-DEV] ext/gd: support creation of animated GIFs

Morning Christoph, We have to face facts: Resources are still a thing. While there is talk of switching resources to use opaque objects, I'm worried about introducing a mixture of objects and resources in random places throughout core exts, and having exts with both seems very strange to me. I k

Re: [PHP-DEV] bugsnet cleanup

Morning Joe 2017-01-09 7:13 GMT+01:00 Joe Watkins : > The problem with accepting feature requests on bugsnet is that, most of the > time, nobody can implement them because of modern processes. > > It's not harmful to us, but it is harmful to the person requesting the > feature, who is probably ign

Re: [PHP-DEV] bugsnet cleanup

Morning Kalle, > I would like some more statuses for the bug tracker +1 go for it Cleanup of code/statuses is also desirable ... and you have volunteered to do it :D Cheers Joe On Mon, Jan 9, 2017 at 6:40 AM, Kalle Sommer Nielsen wrote: > Morning Joe > > 2017-01-09 7:13 GMT+01:00 Joe Watkins

Re: [PHP-DEV] bugsnet cleanup

Hi, Le 08/01/2017 à 07:46, Joe Watkins a écrit : > I'd like to hear what others think about cleaning up bugsnet, what criteria > we might use for a mass cleanup. Big +1 for a mass cleanup. IMHO all bugs reported against PHP < 5.6 could be cleaned. Perhaps something close to the Fedora bugs pro

Re: [PHP-DEV] bugsnet cleanup

Morning Remi, +1 on those criteria and ideas about commenting then closing ... How long between commenting and closing do you think there should be ? Kalle is going to get access to the bugsnet box, maybe he could get you access (if you've time to get directly involved, I super hope you have) ?