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

[Ben Ramsey]

> 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

[Christoph M. Becker]

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 Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Ben Ramsey]

> 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 `pecl` command to install an extension for 
>> testing. When I ran `make install`, I got a nasty failure on the 
>> `install-pear` target. It’s getting a 404 on the PHAR file.
>> 
>> Take a look at https://bugs.php.net/bug.php?id=77604
>> 
>> Additionally, it looks like all the PEAR manual files are gone, so maybe the 
>> site went down and didn’t come back up properly?
> 
> See .


I saw that after posting here. :-)

In the meantime, is there a copy of the PEAR installation Phar file somewhere 
else, so I can install PEAR?

Cheers,
Ben



signature.asc
Description: Message signed with OpenPGP

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

[Christoph M. Becker]

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 `make install`, I got a nasty failure on the `install-pear` 
> target. It’s getting a 404 on the PHAR file.
> 
> Take a look at https://bugs.php.net/bug.php?id=77604
> 
> Additionally, it looks like all the PEAR manual files are gone, so maybe the 
> site went down and didn’t come back up properly?

See .

-- 
Christoph M. Becker

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

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

[Ben Ramsey]

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 `install-pear` target. It’s 
getting a 404 on the PHAR file.

Take a look at https://bugs.php.net/bug.php?id=77604

Additionally, it looks like all the PEAR manual files are gone, so maybe the 
site went down and didn’t come back up properly?

Cheers,
Ben


signature.asc
Description: Message signed with OpenPGP

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

[Stanislav Malyshev]

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 intermediate TLS termination there?

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

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

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

[Christoph M. Becker]

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, despite the documentation, which I'm
>> going to fix right away).  If a typelib is implicitly loaded,
>> com.autoregister_casesensitive[2] controls whether constants are
>> registered case-sensitively or not.  It seems to me com_load_typelib()
>> should trigger a deprecation warning, if FALSE is passed as second
>> argument, and also disabling com.autoregister_casesensitive should.
>>
>> Can this be amemded for PHP 7.3.3, or are there any objections?
>>
>> [1] 
>> [2]
>> <
>> http://php.net/manual/en/com.configuration.php#ini.com.autoregister-casesensitive
> 
> Thanks for pointing this out! Agree that both of those should be deprecated
>  in fact the necessary for code handling case-insensitive constants is
> already gone in master, so they'll definitely have to go as well.
> 
> Personally I think it would be best to add the deprecations in 7.4, as
> there's no particular rush and we usually don't add deprecations in patch
> releases. I don't have a problem with them being added in 7.3.3 either
> though, this is not exactly prime functionality and we're early in the
> release cycle...

Postponing this to 7.4 is fine for me.  I'll provide a respective PR
within the next days.

-- 
Christoph M. Becker

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

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

[Christoph M. Becker]

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 move it to PECL.  Thanks to all voters!
> 
> I'll provide a patch regarding the deprecation as soon as possible.

The deprecation patch has been committed[1].

Could someone with sufficient karma please move ext/wddx (PHP-7.4+) to
PECL/wddx?  (Also the respective info in README.RELEASE_PROCESS[2] could
need some update.)

[1]

[2]


-- 
Christoph M. Becker

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

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

[Sara Golemon]

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
topic) some pushback on isset() even having behavior like this.  That it
should be considered a mistake.  Not saying I agree with going so far as to
call it a mistake, but it does seem to have been an less than ideal choice.

> I would rather see more
> descriptive function names, such as `all_of` or `any_of`:
>
The feels like your C++ experience talking. :D
I do agree though, I think this model gives much more power and
flexibility, I'd also favor such functions taking iterables (as you show in
your examples) over variadic signatures (as shown in some replies) because
this allows the short-circuiting to halt generators early as well.

> These do not need to be part of PHP core, but perhaps they could be.
>
My preference is for the community to build what they want in userspace,
then worry about teaching the engine to optimize the pattern when it sees
it.

-Sara

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

[Legale Legage]

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 question.
> > What do you think?
>
> Opening separate pull requests for separate changes is good as it
> allows them to be discussed separately. That change is bundled with
> the mb_str_split() changes, so it's quite hard to see what is
> optimisation and what is part of the approved RFC.
>
> Although memory is cheap, the change appears to increase the static
> allocation of memory by 128KB for something that >95% of PHP
> programmers will never use, which is not a good idea.
>
> > show a more than 2 times speed increase.
>
> Lies, damn lies and statistics.
>
> If it takes the time to parse a megabyte string from 0.02 to
> 0.01, no one cares.
> If it takes the time to parse a megabyte string from 2 seconds to 1
> second, wow that's great!
>
> i.e. Saying a two times speed increase without context doesn't give
> people enough information to evaluate it.
>
> But this would be easier to discuss as a separate PR.
>
> cheers
> Dan
>

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

[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 question.
> What do you think?

Opening separate pull requests for separate changes is good as it
allows them to be discussed separately. That change is bundled with
the mb_str_split() changes, so it's quite hard to see what is
optimisation and what is part of the approved RFC.

Although memory is cheap, the change appears to increase the static
allocation of memory by 128KB for something that >95% of PHP
programmers will never use, which is not a good idea.

> show a more than 2 times speed increase.

Lies, damn lies and statistics.

If it takes the time to parse a megabyte string from 0.02 to
0.01, no one cares.
If it takes the time to parse a megabyte string from 2 seconds to 1
second, wow that's great!

i.e. Saying a two times speed increase without context doesn't give
people enough information to evaluate it.

But this would be easier to discuss as a separate PR.

cheers
Dan

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

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

[Chase Peeler]

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
> functions are written correctly. all_of will return false as soon as one of
> them fails, and any_of will return true as soon as one of them passes.
> >
> > Unless you are talking about cases like this:
> > if(is_numeric(reallyFastFunc($foo)) || is_numeric(reallySlowFunc($bar)))
> > In that case, you might be able to short circuit the evaluation of
> reallySlowFunc($bar), which wouldn't be the case with
> > if(any_of('is_numeric',reallyFastFunc($foo),reallySlowFunc($bar))){}
>
> Yes, this is what I was referring to. As previously stated, I don't
> think it's likely to be an issue. If it is, then as you stated the
> normal boolean logic can be used in such places.
>
> -
>
> In other words, nothing needs to be done in PHP itself. Just write or
> use someone else's `all_of`, `any_of`, `none_of`, etc, functions.
>
> I'm sure there would be performance enhancement by having it handled with
C vs PHP. I would guess you'd probably need to implement separate functions
for each is_* variant though: any_numeric, all_numeric, none_numeric,
any_boolean, all_boolean, none_boolean, etc. You could probably still have
the any_of, all_of, none_of versions as a shortcut though. I'm speaking
from a point of some ignorance though in terms of what is and isn't faster
when done in C.

Whether it needs to be in core/bundled extension is another debate though.
Seems like it might be a good thing for someone wanting to learn to write
extensions to get their feet wet with, though. I did something similar when
I wanted to try out writing an extension. I implemented a left($str,$len)
and right($str,$len) method... which are basically just shortcuts for
substr*.. but gave me some experience with all of the boiler plate needed,
as well as utilizing existing functions.

*left($str,$len) => substr($str,0,$len)
right($str,$len) => substr($str,-$len);



> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
> --
-- Chase
chasepee...@gmail.com

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

[Christoph M. Becker]

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`:
> 
> if (!all_of('is_numeric', [$input['example1'],
> $input['example2']])) {/*...*/}
> 
> These do not need to be part of PHP core, but perhaps they could be.
> 
> 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.

See , which has been abanoned,
though.

-- 
Christoph M. Becker

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

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

[Levi Morrison]

>> 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 one of them fails, 
> and any_of will return true as soon as one of them passes.
>
> Unless you are talking about cases like this:
> if(is_numeric(reallyFastFunc($foo)) || is_numeric(reallySlowFunc($bar)))
> In that case, you might be able to short circuit the evaluation of 
> reallySlowFunc($bar), which wouldn't be the case with
> if(any_of('is_numeric',reallyFastFunc($foo),reallySlowFunc($bar))){}

Yes, this is what I was referring to. As previously stated, I don't
think it's likely to be an issue. If it is, then as you stated the
normal boolean logic can be used in such places.

-

In other words, nothing needs to be done in PHP itself. Just write or
use someone else's `all_of`, `any_of`, `none_of`, etc, functions.

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

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

[Chase Peeler]

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:
> >
> >
> > if (!(is_numeric($input['example1']) && is_numeric($input['example2'])))
> {
> >
> >
> > if (!is_numeric($input['example1'] || !is_numeric($input['example2'])) {
> >
> >
> > and I had multiple problems with this.
> >
> > * it's kinda hard to read
> >
> > * multiple writings for the same logic
> >
> > * ends up in complex conditionals
> >
> >
> > I searched for discussions regarding this topic and found it was
> > mentioned in a 'side thread' of the RFC for changing empty() to a
> > variadic a few years ago (https://externals.io/message/82549#82641) and
> > I'd like to collect some feedback if it's wothy to revisit the topic to
> > write the above example as:
> >
> >
> > if (!is_numeric($input['example1'], $input['example2'])) {
> >
> >
> > Except the is_callable() method all is_*() methods could be extended
> > with a variadic behaviour which would check the given values from the
> > left to the right and abort if a value doesn't match the condition (in
> > the example if a given value is not numeric). So all in all there are
> > some points to talk about: Revisit the discussion? Which functions are
> > reasonable to be extended? If all functions are reasonable: what to do
> > with is_callable()?
> >
> > regards,
> > Enno
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
>
> 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`:
>
> if (!all_of('is_numeric', [$input['example1'],
> $input['example2']])) {/*...*/}
>
> These do not need to be part of PHP core, but perhaps they could be.
>
> 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 one of them
fails, and any_of will return true as soon as one of them passes.
 --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
> --
-- Chase
chasepee...@gmail.com

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

[Levi Morrison]

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']) && is_numeric($input['example2']))) {
>
>
> if (!is_numeric($input['example1'] || !is_numeric($input['example2'])) {
>
>
> and I had multiple problems with this.
>
> * it's kinda hard to read
>
> * multiple writings for the same logic
>
> * ends up in complex conditionals
>
>
> I searched for discussions regarding this topic and found it was
> mentioned in a 'side thread' of the RFC for changing empty() to a
> variadic a few years ago (https://externals.io/message/82549#82641) and
> I'd like to collect some feedback if it's wothy to revisit the topic to
> write the above example as:
>
>
> if (!is_numeric($input['example1'], $input['example2'])) {
>
>
> Except the is_callable() method all is_*() methods could be extended
> with a variadic behaviour which would check the given values from the
> left to the right and abort if a value doesn't match the condition (in
> the example if a given value is not numeric). So all in all there are
> some points to talk about: Revisit the discussion? Which functions are
> reasonable to be extended? If all functions are reasonable: what to do
> with is_callable()?
>
> regards,
> Enno
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php

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`:

if (!all_of('is_numeric', [$input['example1'],
$input['example2']])) {/*...*/}

These do not need to be part of PHP core, but perhaps they could be.

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.

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

[PHP-DEV] Variadic is_*() functions

[Woortmann, Enno]

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'] || !is_numeric($input['example2'])) {


and I had multiple problems with this.

* it's kinda hard to read

* multiple writings for the same logic

* ends up in complex conditionals


I searched for discussions regarding this topic and found it was
mentioned in a 'side thread' of the RFC for changing empty() to a
variadic a few years ago (https://externals.io/message/82549#82641) and
I'd like to collect some feedback if it's wothy to revisit the topic to
write the above example as:


if (!is_numeric($input['example1'], $input['example2'])) {


Except the is_callable() method all is_*() methods could be extended
with a variadic behaviour which would check the given values from the
left to the right and abort if a value doesn't match the condition (in
the example if a given value is not numeric). So all in all there are
some points to talk about: Revisit the discussion? Which functions are
reasonable to be extended? If all functions are reasonable: what to do
with is_callable()?

regards,
Enno

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

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

[Nikita Popov]

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 change as-is.  How do we ensure that it doesn't get
> > lost in the clutter given that it has no RFC?
>
> Generally, *everything* that needs to be mentionend in the migration
> guide, should have a respective entry in UPGRADING.  That makes creating
> the migration guide straight forward for the doc team, and worked quite
> well for PHP 7.3 at least.
>

As the discussion here has drifted off towards error handling in general
and there hasn't been any further input on the change itself, I've gone
ahead and committed this:
https://github.com/php/php-src/commit/a302d1161036988fe220ecd8ecd73e6af1a116fc
I've also included a few UPGRADING notes.

Nikita

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

[Nikita Popov]

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 handshake passes, but no content is delivered). Seems
> to
> > > be something wrong with the site? Could somebody check it?
> >
> >
> > I’ve been experiencing the same thing today and yesterday. Traceroute and
> > ping returns fine, but anything over port 443 is very slow and times out
> > sometimes. At other times, the website loads fast.
> >
>
> 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?
>
> -Rasmus
>

bugs.php.net has regularly been unavailable in the last few weeks, but
always seems to recover after a while. So it's down for just an hour or
something, not long periods of time. I haven't kept track of when exactly
it happens, but maybe a cronjob is messing something up?

Nikita

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

[Ben Ramsey]

> 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 ipv4.

Cheers,
Ben


signature.asc
Description: Message signed with OpenPGP

[PHP-DEV] Re: Disable PEAR by default

[Nikita Popov]

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 breach itself, but rather the underlying issue that PEAR simply
> isn't actively maintained anymore.
>
> Currently PEAR is broken on master due to the removal of each(), which was
> deprecated in PHP 7.2. Apparently, since that time nobody noticed that PEAR
> is throwing deprecation errors, or at least nobody bothered to fix them.
> (I've submitted https://github.com/pear/Console_Getopt/pull/3 to fix at
> least this particular issue.)
>
> It's somewhat unfortunate that PEAR and PECL are coupled projects, but I
> don't think that should prevent us from changing this default.
>
> Regards,
> Nikita
>

I've gone ahead and merged this change. PEAR is no longer installed by
default, instead --with-pear must be specified. Additionally the option
generates a deprecation warning during ./configure now.

Nikita

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

[Côme Chilliet]

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 thread is the right place to answer, but I felt like I 
had to report that the php-ldap module triggers warning for about all errors 
and is almost impossible to use without @ because of this.
I did not attempt at fixing this for now since it would be huge BC breaks and 
if we’re going for BC breaks a lot of the ldap module API could be redesigned.

The other case where error handling through warning is a big problem is fopen, 
for which I usually use the same kind of wrapper (setting error handler) as 
posted by someone else.

Côme

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