[PHP-DEV] Re: Make target install-pear is failing

> On Feb 11, 2019, at 18:21, Christoph M. Becker wrote: > > You can get the installers from > . Perfect! Thanks! Cheers, Ben signature.asc Description: Message signed with OpenPGP

[PHP-DEV] Re: Make target install-pear is failing

On 12.02.2019 at 01:08, Ben Ramsey wrote: > In the meantime, is there a copy of the PEAR installation Phar file somewhere > else, so I can install PEAR? You can get the installers from . -- Christoph M. Becker -- PHP Internals - PHP Runtime

[PHP-DEV] Re: Make target install-pear is failing

> On Feb 11, 2019, at 18:04, Christoph M. Becker wrote: > > On 12.02.2019 at 00:42, Ben Ramsey wrote: > >> Earlier today, someone reported pear.php.net as being down. I checked, and >> it’s loading, so I sent it back to them for Feedback. Later, I built PHP >> with PEAR so I could use the

[PHP-DEV] Re: Make target install-pear is failing

On 12.02.2019 at 00:42, Ben Ramsey wrote: > Earlier today, someone reported pear.php.net as being down. I checked, and > it’s loading, so I sent it back to them for Feedback. Later, I built PHP with > PEAR so I could use the `pecl` command to install an extension for testing. > When I ran

[PHP-DEV] Make target install-pear is failing

Earlier today, someone reported pear.php.net as being down. I checked, and it’s loading, so I sent it back to them for Feedback. Later, I built PHP with PEAR so I could use the `pecl` command to install an extension for testing. When I ran `make install`, I got a nasty failure on the

Re: [PHP-DEV] bugs.php.net problems?

Hi! > Are you still seeing this? It is a Digital Ocean VM in NYC1 and I don't > see anything odd aboout it. Are you hitting it over ipv4 or ipv6? Seems to be ok now. Given that TLS handshake always worked fine, I suspect it's something server-side, not network-side, unless we have some kind of

[PHP-DEV] Re: [VOTE] Deprecate and remove case-insensitive constants

On 08.02.2019 at 09:59, Nikita Popov wrote: > On Thu, Feb 7, 2019 at 11:31 PM Christoph M. Becker > wrote: > >> I just learned that com_load_typelib()[1] automatically registers enum >> members as constants, and allows to register them as case-insensitive >> (the default is case-sensitive,

[PHP-DEV] Re: [VOTE] RFC: Unbundle ext/wddx

On 31.01.2019 at 23:19, Christoph M. Becker wrote: > The voting on > > > > has ended, and it has unanimously been decided (30:0) to remove (aka. > unbundle) ext/wddx; it has also been decided (19:4:3:2) to deprecate the > extension and

Re: [PHP-DEV] Variadic is_*() functions

On Mon, Feb 11, 2019 at 9:59 AM Levi Morrison wrote: > My position is the same: pushing the variadic behavior into the > functions means that each function needs to pick `||` or `&&` > behavior, both of which are useful. > Additionally, I recall from that thread (or a similar one on the same

Re: [PHP-DEV] reasonability of change the mbfl library

Got it. Thanks. On Mon, Feb 11, 2019, 18:00 Dan Ackroyd On Sun, 10 Feb 2019 at 12:29, Legale Legage > wrote: > > > > > > > https://github.com/php/php-src/pull/3715/commits/d868059626290b7ba773b957045e08c3efb1d603#diff-22d593ced03b2cb94450d9f9990865c8R38 > > > > To do, or not to do: that is the

Re: [PHP-DEV] reasonability of change the mbfl library

On Sun, 10 Feb 2019 at 12:29, Legale Legage wrote: > > > https://github.com/php/php-src/pull/3715/commits/d868059626290b7ba773b957045e08c3efb1d603#diff-22d593ced03b2cb94450d9f9990865c8R38 > > To do, or not to do: that is the question. > What do you think? Opening separate pull requests for

Re: [PHP-DEV] Variadic is_*() functions

On Mon, Feb 11, 2019 at 11:35 AM Levi Morrison wrote: > >> I recognize that there is one downside, which is that lazy evaluation > >> is lost, but generally don't see it to be an issue in these specific > >> cases. > >> > > Lazy evaluation doesn't have to be lost if the all_of and any_of >

Re: [PHP-DEV] Variadic is_*() functions

On 11.02.2019 at 16:59, Levi Morrison wrote: > My position is the same: pushing the variadic behavior into the > functions means that each function needs to pick `||` or `&&` > behavior, both of which are useful. I would rather see more > descriptive function names, such as `all_of` or `any_of`:

Re: [PHP-DEV] Variadic is_*() functions

>> I recognize that there is one downside, which is that lazy evaluation >> is lost, but generally don't see it to be an issue in these specific >> cases. >> > Lazy evaluation doesn't have to be lost if the all_of and any_of functions > are written correctly. all_of will return false as soon as

Re: [PHP-DEV] Variadic is_*() functions

On Mon, Feb 11, 2019 at 10:59 AM Levi Morrison wrote: > On Mon, Feb 11, 2019 at 8:39 AM Woortmann, Enno > wrote: > > > > Hi internals, > > > > as I reviewed a bunch of code for handling data from different sources > > (eg. json) in the last days I stumbled over code like this multiple > times:

Re: [PHP-DEV] Variadic is_*() functions

On Mon, Feb 11, 2019 at 8:39 AM Woortmann, Enno wrote: > > Hi internals, > > as I reviewed a bunch of code for handling data from different sources > (eg. json) in the last days I stumbled over code like this multiple times: > > > if (!(is_numeric($input['example1']) &&

[PHP-DEV] Variadic is_*() functions

Hi internals, as I reviewed a bunch of code for handling data from different sources (eg. json) in the last days I stumbled over code like this multiple times: if (!(is_numeric($input['example1']) && is_numeric($input['example2']))) { if (!is_numeric($input['example1'] ||

Re: [PHP-DEV] Re: Don't silence fatal errors

On Wed, Feb 6, 2019 at 10:45 PM Christoph M. Becker wrote: > On 06.02.2019 at 05:42, Zeev Suraski wrote: > > > As long as we have a prominent warning about this in our migration guide > > alerting people to the associated risk in setups where display errors is > on > > - I can live with the

Re: [PHP-DEV] bugs.php.net problems?

On Mon, Feb 11, 2019 at 7:04 AM Rasmus Lerdorf wrote: > On Sat, Feb 9, 2019 at 4:17 PM Ben Ramsey wrote: > > > > On Feb 9, 2019, at 18:15, Stanislav Malyshev > > wrote: > > > > > > Hi! > > > > > > I am trying to access bugs.php.net and I am getting timeouts all the > > > time today (TLS

Re: [PHP-DEV] bugs.php.net problems?

> On Feb 11, 2019, at 00:03, Rasmus Lerdorf wrote: > > Are you still seeing this? It is a Digital Ocean VM in NYC1 and I don't see > anything odd aboout it. Are you hitting it over ipv4 or ipv6? I was on bugs.php.net a bit yesterday, and I didn’t notice it anymore. I was hitting it over

[PHP-DEV] Re: Disable PEAR by default

On Fri, Feb 1, 2019 at 12:27 PM Nikita Popov wrote: > Hi internals, > > I would like to suggest that installation of PEAR is disabled by default > in PHP 7.4. PR: https://github.com/php/php-src/pull/3781 > > I think the reasons for this should be obvious. It's not really the recent > security

Re: [PHP-DEV] Don't silence fatal errors

Le dimanche 10 février 2019, 09:34:16 CET Pierre Joye a écrit : > However I think you are right as well in your other replies. While I wrote > @ free code since years and I rarely see some in modern code, removing it > may bring some BC issues that could delay 8 adoptions. Not sure where in this