Re: [PHP-DEV] PHP 2^3

[Alice Wonder]

On 06/25/2018 07:13 AM, Johannes Schlüter wrote:

On Mo, 2018-06-25 at 12:30 +, Zeev Suraski wrote:

3. Foreign Function Interface support.


Related to this on a non-PHP-code and strategic matter I would like to
rethink PECL. Currently maintenance and installing extensions using it
is a pita. This should be doable in a nicer way.
(i.e. pecl pointing directly to Git(Hub) repos, similar to composer, a
way to install precompiled binaries, probably using a more narrow
stable API, better reporting of dependency issues, with the new
execution model of your point 2 also better integration with composer,
...)

johannes



As a packager github is a fracking nightmare.

Frequently what we do is include a hash of the release tarball in our 
build and require that it matches so that people rebuilding our package

(e.g. to add a patch they need) don't have to trust us, they can use our
build spec file but fetch the upstream source themselves, and the hash
matches lets them know that what they fetched from upstream is identical 
to what the initial packager used.


But with github getting the url to the actual download is tricky and 
often breaks and also I've seen the hash from the release tarball on 
github differ from the hash the release tarball on the project site 
numerous times.


git is for code management but when a release it tagged, creation of the 
source tarball should be done by the developer, and released by the 
developer, preferably with sha256 or sha512 sums posted in an easy to 
find location (which github doesn't do)


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

Re: [PHP-DEV] PHP 2^3

[Rowan Collins]

On 25/06/2018 21:42, Larry Garfield wrote:

What will definitely bring benefit to real world workloads is preloading,
which (if we manage to do it) will dramatically reduce the per-request
initialization stage.  It could bring us much of the benefit of async-IO
long running processes without sacrificing the isolation advantages of the
traditional PHP execution model.  It will likely also play nicely with
JIT.  But this is floors upon floors of speculation - we'll have to see...

This is more what I'm talking about.  A way to get a process up to "all my
service objects are created, my code is parsed, my events are registered,
etc.", and then save that state and do the usual shared-nothing after that
without having to repeat that part.  I agree that's likely several layers up
from where we're talking, but if it's a potential thing that could be done
then that's a good argument for doing this thing now.



I keep coming back recently to the idea of native support for "packages" 
or "modules":


- a bunch of classes edited as separate files, but loaded "in one hit", 
rather than autoloaded one class at a time

- a more "solid" namespace, e.g. visible in Reflection
- configuration of declare()-style directives that apply to the whole module
- "module private" visibility for classes (and maybe, later, methods, 
although the phrase "private protected" [1] makes my head hurt)


I think this would fit naturally with preloading, and making OpCache 
(and JIT) more central to the engine, and fits more naturally with where 
things like Composer and PHP-FIG have taken the language.


It might even link to FFI - maybe a module linking to C functions in a 
certain way could act as a light-weight, dynamically-loadable, extension.


I realise I'm dreaming now, and don't expect this to all suddenly appear 
in 8.0, but I wonder if it's worth exploring as a framework to build 
around / toward?



[1]: 
https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/access-modifiers


Regards,

--
Rowan Collins
[IMSoP]


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

RE: [PHP-DEV] PHP 2^3

[Zeev Suraski]

> -Original Message-
> From: Larry Garfield [mailto:la...@garfieldtech.com]
> Sent: Monday, June 25, 2018 11:43 PM
> To: internals@lists.php.net
> Subject: Re: [PHP-DEV] PHP 2^3
> 
> That's certainly a good argument for the people doing deep engine work to
> focus on that, but there's ample non-core-team people who would be totally
> useless in stabilizing a JIT that could have other things to add.  I'm
thinking of if,
> say, SammyK comes back with another trailing comma RFC again, or someone
> not already busy with async details manages to figure out a performant way
to
> do property accessors, etc.  Would those be actively blocked from 7.4?  Or
> would those be fine as long as it doesn't distract you and Dimitry from
figuring
> out async?

The reality of things is that very few patches make it into the engine
without the (very few) core engine developers closely reviewing them, and
sometimes greatly refactoring them.  It might feel like it's happening
automatically, but it doesn't - it's a lot of effort.
Separately, it wouldn't or at least shouldn't be "Dmitry figuring out
async".  It needs to be a group effort, which I'm sure Dmitry would greatly
contribute to - especially around the infrastructure - but then there'll
likely be the group effort of async-enabling our various extensions.
Letting the core devs do the heavy lifting while the rest are playing with
other things isn't a very nice or sustainable strategy.  And as unpopular as
this may be, this should (IMHO) be primarily up to the core devs who are in
fact doing the heavy lifting - we need to design the development schedule to
make their job the easiest, as it's already remarkably tough.

> If they're OK, then yay, we're on the same page.  If not, then we're
basically
> guaranteeing that no one is going to bother using 7.4 (thus rendering the
whole
> "deprecation release" useless) and losing a lot of momentum from people
> interested in improving the language in ways other than the core runtime/
> compiler logic.

As I mentioned elsewhere I do see value in it even if it's a
deprecation-only version, effectively a 7.3.(n+1) with deprecations, where
migration costs are no different than to any other 7.3.x (i.e. very low,
guaranteed), and you get a version that can ease you into PHP 8 around a
year ahead of time.  We could even just introduce a certain switch allowing
you to enable these deprecations in a real 7.3.x release, without calling it
7.4 now that I think of it. 

Note that it's not just about the raw amount of coding or discussion hours -
it's also about the state of mind.  If our top goal after 7.3 is to release
8.0 - I'm sure people can figure out ways to help this cause.  If we have
two concurrent projects, people would go for their comfort zones. 

Zeev



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

Re: [PHP-DEV] PHP 8 next?

[Rowan Collins]

On 25/06/2018 20:34, Michael Morris wrote:

So, about that Ternary operator?

My understanding is that major releases are the only ones allowed to have
breaking changes. Correcting the ternary operator to work like it does in
all other languages is a small example.



I don't think it's a good idea to turn this thread into a list of every 
possible change we might want in PHP 8, but there is a general point to 
be made here: the rule is that if you have a clear breaking change, it 
is definitely not allowed in a minor release; not that it automatically 
will be allowed in a major release.


Even a major release should maintain some compatibility - in particular, 
it should be possible to write code that runs correctly on both the 
previous and new versions. For instance: removing the old way of doing 
something because a new way is already available, or making something an 
error that was previously an avoidable warning.


In this example, changing the associativity directly would mean the same 
code would run in both versions, but with different results, and that is 
going to cause a lot of headaches. On the other hand, making it 
*non-associative*, so that it was an error to write ambiguous code, 
would probably save a lot of headaches.


Again, this feels less of a hardship if we plan major versions further 
ahead: we might pencil in the new behaviour for 9.0, and be able to put 
a date on that.


Regards,

--
Rowan Collins
[IMSoP]


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

Re: [PHP-DEV] PHP 2^3

[Larry Garfield]

On Monday, June 25, 2018 2:12:22 PM CDT Zeev Suraski wrote:


> > When we speak of "typical web loads" not getting much benefit here, are we
> > really talking about CGI-style "reboot every request" type loads rather
> > than
> > "IO-bound work"?  Because it's been observed many times in the past that
> > one
> > of the most expensive parts of a modern PHP app is simply booting up,
> > initializing all of the services, wiring everything together...  and then
> 
> throwing it away 100 ms later.  If a JIT would make it more viable to pre-
> 
> > start a web process (there are various all-user-space implementations in
> > the
> > wild already) so that an incoming request already had a fully booted
> > system
> > 
> > with container initialized and stuff, that could have a huge impact on web
> > 
> > loads, even without going all-in on Node-style async.
> 
> I thought I'd be given the benefit of doubt regarding having a clue about
> performance of PHP workloads... :)

Understanding it yourself, yes.  Clarifying what it is you're talking about in 
this particular context, no. :-P

> On point, the initialization cycle isn't radically different with JIT.
> Initializing the request is pretty similar, as is the stage of loading
> classes.  The current JIT implementation doesn't bring substantial
> performance gains with most real world apps we tested - as they simply
> don't seem to spend too much in pure PHP logic (discounting the loading of
> classes).  Of course - your mileage may vary, and it's not outside the
> realm of possibility that certain apps that are CPU-heavy in either their
> initilization or execution would benefit - perhaps even greatly - from
> JIT.  It may also depend on the specific CPU and a lot of other factors.
> When people start testing it in the wild I guess we'll have a better view.
> 
> What will definitely bring benefit to real world workloads is preloading,
> which (if we manage to do it) will dramatically reduce the per-request
> initialization stage.  It could bring us much of the benefit of async-IO
> long running processes without sacrificing the isolation advantages of the
> traditional PHP execution model.  It will likely also play nicely with
> JIT.  But this is floors upon floors of speculation - we'll have to see...

This is more what I'm talking about.  A way to get a process up to "all my 
service objects are created, my code is parsed, my events are registered, 
etc.", and then save that state and do the usual shared-nothing after that 
without having to repeat that part.  I agree that's likely several layers up 
from where we're talking, but if it's a potential thing that could be done 
then that's a good argument for doing this thing now.

> Question from the peanut gallery: why would 7.4 need to be a deprecation-
> > mostly release?  Is the concern that it would make merging to the engine
> > changes in 8.0 harder?
> 
> Certainly, but even without it - it's going to be hard enough to release 8
> with its features within 2-2.5 years. It will be impossible to do it while
> spending most of that time working on other releases.  I don't think people
> realize just how ambitious these bulletpoints are - to pull off in ~24
> months (gross).  It took us, IIRC, approximately 18 months from the point
> we published phpng and until PHP 7.0 was ready - as we focused exclusively
> on it.  We're not in a very different stage with JIT right now, but we're
> throwing in several other radical improvements with far reaching
> implications - async and preloading (and that's before others pitched in
> their ideas).
> 
> We have finite resources, and honestly, the resources we have that can work
> on these deliverables are very scarce.  We need to choose are battles.
> 
> Zeev

That's certainly a good argument for the people doing deep engine work to 
focus on that, but there's ample non-core-team people who would be totally 
useless in stabilizing a JIT that could have other things to add.  I'm 
thinking of if, say, SammyK comes back with another trailing comma RFC again, 
or someone not already busy with async details manages to figure out a 
performant way to do property accessors, etc.  Would those be actively blocked 
from 7.4?  Or would those be fine as long as it doesn't distract you and 
Dimitry from figuring out async?

If they're OK, then yay, we're on the same page.  If not, then we're basically 
guaranteeing that no one is going to bother using 7.4 (thus rendering the 
whole "deprecation release" useless) and losing a lot of momentum from people 
interested in improving the language in ways other than the core runtime/
compiler logic.

--Larry Garfield

signature.asc
Description: This is a digitally signed message part.

Re: [PHP-DEV] PHP 8 next?

[Rowan Collins]

On 25/06/2018 19:54, Zeev Suraski wrote:

On Mon, Jun 25, 2018 at 8:40 PM Chase Peeler  wrote:


1.) Old code breaks during minor updates. We upgraded to 7.0 AFTER 7.1 was
released, because we had already made major updates to upgrade to 7.0, and
7.1 introduced a few things that would have broken our code - we didn't
have time to fix those by that point. "Throw on passing too few function
arguments" would actually break more stuff in our legacy code than all of
the 7.0 changes combined.


I agree.  It was a bad decision on our part to do it in 7.1 - this bit a
lot of users.


IIRC, one of the arguments given at the time was "we don't know when 8.0 
will be, so we might have to wait for a long time". I never liked that 
argument, because it sounds like the arrival of a major release is 
entirely out of our hands, when in fact the opposite is true.


My argument then, as now, was that we should plan further ahead when 
each major release will be, and build up a list of things that will be 
in it. If anything, I think we should bump the major version number 
*more* often; if after 3 years we have 10 things like the too_few_args 
RFC, get them implemented, bump the version number, and move forward.


On reflection, I think maybe that phrasing reveals a difference in 
viewpoint: a lot of people talk about "a major release", which implies 
there's something big and exciting, rather than just a number. I think 
of it more like the marks on a ruler: centimetres are not more exciting 
than millimetres, but they are less frequent, and have some significance.




It's tough enough for me to make a case for upgrading using the "increase 
performance" and "new
features" argument. There is no way I'd get the go-ahead to do an upgrade
that would just make additional features deprecated.



In an ideal world, there would be no reason *not* to upgrade to the next 
minor version, because you would know that your code ran on "7.x", so 
would just install the latest 7.x when it came out. I know reality is 
never quite that simple, but I think we can get pretty close with a bit 
of discipline and planning.


Regards,

--
Rowan Collins
[IMSoP]


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

Re: [PHP-DEV] PHP 2^3

[Aaron Piotrowski]

> On Jun 25, 2018, at 7:30 AM, Zeev Suraski  wrote:
> 
> 
> 2. Better support long-running, async-based, microservices-focused execution 
> model.  It's probably no secret that one of the key reasons Node is gaining 
> popularity is because it can handle a huge number of concurrent connections 
> issuing relatively lightweight requests very efficiently - which is a good 
> match for modern microservices based architectures.  There are already 
> several projects available for PHP that aim to provide similar functionality 
> - most notably ReactPHP and more recently Swoole.
> The main thing that is missing is that most of PHP's IO doesn't support async 
> execution.  What I think we should do is add as much support for async IO as 
> possible across the various extensions and streams - so that using something 
> like Swoole would become practical for more use cases.  More specifically - 
> the goal would be to provide extension authors with mechanisms that they can 
> use to make their extensions/functions optionally asynchronous, without 
> having to tackle the job entirely on their own.  While we've done some 
> research into this area, it requires a lot more research - but I'm cautiously 
> optimistic that it can be done.  We would potentially want to use libuv for 
> this task, and potentially rewrite or otherwise refactor parts of the PHP 
> streams system.
> 

Regarding async, are you referring to the Fiber extension? In my opinion, 
fibers would be the best approach for async in PHP. After using async/await in 
other languages, it doesn't offer a significant gain over what's already 
possible in PHP with generator-based coroutines in Amp. Using the fiber 
extension and a green-thread library that resumes fibers based on promise 
resolution [1], we've been able to write async code without the need for yield 
or await [2], with async functions having proper return types (i.e. not 
promise, but the type the promise would resolve to). Joel Wurtz has also put 
together a PoC of using Doctrine asynchronously using the fiber extension and 
Amp [3].

A new major may not be strictly necessary to introduce this feature, but it 
would ease introducing new keywords for awaiting IO and "promisifying" a 
function using fibers to allow simultaneous IO. These keywords could be async 
and await, though they would be used differently than JavaScript or other 
languages. See an example in the green-thread library [4], where the await() 
function uses Fiber::yield() to wait for promise resolution, and async() 
creates a promise from a function using await(). I would propose using keywords 
in place of these two functions.

I successfully am using Amp's http-server library with several other Amp 
libraries to run a website using long-running processes under PHP 7.2. I've 
seen no issues with memory leaks, crashing processes, or other unexpected 
behaviors. I think PHP is absolutely ready to shine in environments outside of 
per-request SAPIs. Core support for async is one of the few ingredients missing.

Aaron Piotrowski

[1] https://github.com/amphp/green-thread
[2] https://github.com/amphp/byte-stream/tree/ext-fiber
[3] https://github.com/joelwurtz/doctrine-async
[4] 
https://github.com/amphp/green-thread/blob/e13327a84be67d289aec87984f9d5c8e1fddd471/examples/simultaneous-async.php


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

Re: [PHP-DEV] PHP 8 next?

[Michael Morris]

On Mon, Jun 25, 2018 at 2:55 PM Zeev Suraski  wrote:

> On Mon, Jun 25, 2018 at 8:40 PM Chase Peeler 
> wrote:
>
> > 1.) Old code breaks during minor updates. We upgraded to 7.0 AFTER 7.1
> was
> > released, because we had already made major updates to upgrade to 7.0,
> and
> > 7.1 introduced a few things that would have broken our code - we didn't
> > have time to fix those by that point. "Throw on passing too few function
> > arguments" would actually break more stuff in our legacy code than all of
> > the 7.0 changes combined.
> >
>
> I agree.  It was a bad decision on our part to do it in 7.1 - this bit a
> lot of users.
>
>
> > Finally, I personally see the idea of a deprecation only release to be
> kind
> > of silly. I don't work for a software company. It's tough enough for me
> to
> > make a case for upgrading using the "increase performance" and "new
> > features" argument. There is no way I'd get the go-ahead to do an upgrade
> > that would just make additional features deprecated. It would be a better
> > use of my time to look for and fix the deprecated features as part of the
> > 8.0 upgrade prep, than to upgrade to 7.4. Maybe look at at backporting
> some
> > of the new 8.0 features that aren't really dependent on the major things
> > like JIT, async, etc., as part of the 7.4 release.
> >
> > Fair enough, and I think there'll likely be a lot of folks that would see
> no point in going through such a 7.4.  However, I think that folks working
> in more agile companies, or even developers that want to get a head start
> on preparing for 8.0 - will find value in such a release.  TBH, the vast
> majority of users don't upgrade to our minor versions even when they bring
> new features and capabilities.
>

So, about that Ternary operator?

My understanding is that major releases are the only ones allowed to have
breaking changes. Correcting the ternary operator to work like it does in
all other languages is a small example. Merging the symbol tables is
another.

5.3 had namespaces - 5.4 made APC core - these were major changes but not
breaking ones.

Breaking changes need significant notice as Levi points out.

>
>

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

[Sara Golemon]

On Sun, Jun 24, 2018 at 11:47 AM, Nikita Popov  wrote:
> https://wiki.php.net/rfc/deprecations_php_7_3
>
> Undocumented mbstring function aliases
>
Yeah, if they're just dumb aliases, then it's a slight gain to narrow
the symbol table by removing duplicates.  A modest composer package
(nay, include file) would be sufficient to provide a bridge for
existing projects which use the removed aliases once they're gone.
This deprecation isn't *needed*, but it's also fairly low impact. 路

> String search functions with integer needle
>
Agree with stas, the wtf quotient on this one is high.  Mitigating
this is the availability of strict types, but even still I think
deprecating the behavior altogether is a wise move.  Callers can
easily insert a call to chr() (or IntlChar::chr() ) to maintain the
old behavior in a version agnostic way. 

> fgetss() function and string.strip_tags filter
>
"...these functions seem to be of very little utility..." [citation needed]
Anecdotally I struggle to imagine the use-case, but my imagination
isn't what it once was.  There's not a trivial workaround for someone
who's dealing with a large/streaming data source from which they want
to strip tags.  Deprecating this should come at a higher standard of:
proving that it is used, providing a userspace replacement, or both.


> Defining a free-standing assert() function
>
Eww, yeah. I can see that problem.  I'm not a huge fan of banning all
namespaced assert() function declarations, but it's certainly the most
direct "solution" to the problem.  A very quick scan of github only
shows one effected usage in a repo with no followers/stars apart from
the owner.  Given the lack of whole-program analysis, it's either ban
the declarations, or abandon elision.  Frankly, the number of people
taking advantage of the free dev-only check is probably way higher
than the number trying to define a function called 'assert' so 

-Sara

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

Re: [PHP-DEV] PHP 2^3

[Zeev Suraski]

On Mon, Jun 25, 2018 at 8:52 PM Larry Garfield 
wrote:

> On Monday, June 25, 2018 11:16:31 AM CDT Sara Golemon wrote:
>
> > > First, I'll admit that there's definitely some of that happening.  But
> to
> > > paraphrase my daughters - "I didn't start it!".  In other words -
> people
> > > are very actively looking for ways to run PHP in a Node-like manner,
> and
> > > with the shift towards micro-services - I don't think it's a fad.  I
> > > think we need to go there if we are to stay relevant.
> >
> > Fair point.  I've certainly had discussions with Liz Smith and even
> > been on Zend sponsored podcasts discussing ways we might "appify" PHP.
> > But, and perhaps I'm just a bit more skeptical of the microservices
> > train, I think we should be judicious in our pursuit of the new
> > hotness. That's all.  Most of my response was centered on what felt
> > like a rush.  Factoring in that entire paragraph about having a thin
> > 7.4 release with a subsequent 8.0 GA alleviates my concerns a great
> > deal.
>
> When we speak of "typical web loads" not getting much benefit here, are we
> really talking about CGI-style "reboot every request" type loads rather
> than
> "IO-bound work"?  Because it's been observed many times in the past that
> one
> of the most expensive parts of a modern PHP app is simply booting up,
> initializing all of the services, wiring everything together...  and then

throwing it away 100 ms later.  If a JIT would make it more viable to pre-
> start a web process (there are various all-user-space implementations in
> the
> wild already) so that an incoming request already had a fully booted system
>
> with container initialized and stuff, that could have a huge impact on web
>
> loads, even without going all-in on Node-style async.
>


I thought I'd be given the benefit of doubt regarding having a clue about
performance of PHP workloads... :)

On point, the initialization cycle isn't radically different with JIT.
Initializing the request is pretty similar, as is the stage of loading
classes.  The current JIT implementation doesn't bring substantial
performance gains with most real world apps we tested - as they simply
don't seem to spend too much in pure PHP logic (discounting the loading of
classes).  Of course - your mileage may vary, and it's not outside the
realm of possibility that certain apps that are CPU-heavy in either their
initilization or execution would benefit - perhaps even greatly - from
JIT.  It may also depend on the specific CPU and a lot of other factors.
When people start testing it in the wild I guess we'll have a better view.

What will definitely bring benefit to real world workloads is preloading,
which (if we manage to do it) will dramatically reduce the per-request
initialization stage.  It could bring us much of the benefit of async-IO
long running processes without sacrificing the isolation advantages of the
traditional PHP execution model.  It will likely also play nicely with
JIT.  But this is floors upon floors of speculation - we'll have to see...


Question from the peanut gallery: why would 7.4 need to be a deprecation-
> mostly release?  Is the concern that it would make merging to the engine
> changes in 8.0 harder?


Certainly, but even without it - it's going to be hard enough to release 8
with its features within 2-2.5 years. It will be impossible to do it while
spending most of that time working on other releases.  I don't think people
realize just how ambitious these bulletpoints are - to pull off in ~24
months (gross).  It took us, IIRC, approximately 18 months from the point
we published phpng and until PHP 7.0 was ready - as we focused exclusively
on it.  We're not in a very different stage with JIT right now, but we're
throwing in several other radical improvements with far reaching
implications - async and preloading (and that's before others pitched in
their ideas).

We have finite resources, and honestly, the resources we have that can work
on these deliverables are very scarce.  We need to choose are battles.

Zeev

Re: [PHP-DEV] PHP 8 next?

[Zeev Suraski]

On Mon, Jun 25, 2018 at 8:40 PM Chase Peeler  wrote:

> 1.) Old code breaks during minor updates. We upgraded to 7.0 AFTER 7.1 was
> released, because we had already made major updates to upgrade to 7.0, and
> 7.1 introduced a few things that would have broken our code - we didn't
> have time to fix those by that point. "Throw on passing too few function
> arguments" would actually break more stuff in our legacy code than all of
> the 7.0 changes combined.
>

I agree.  It was a bad decision on our part to do it in 7.1 - this bit a
lot of users.


> Finally, I personally see the idea of a deprecation only release to be kind
> of silly. I don't work for a software company. It's tough enough for me to
> make a case for upgrading using the "increase performance" and "new
> features" argument. There is no way I'd get the go-ahead to do an upgrade
> that would just make additional features deprecated. It would be a better
> use of my time to look for and fix the deprecated features as part of the
> 8.0 upgrade prep, than to upgrade to 7.4. Maybe look at at backporting some
> of the new 8.0 features that aren't really dependent on the major things
> like JIT, async, etc., as part of the 7.4 release.
>
> Fair enough, and I think there'll likely be a lot of folks that would see
no point in going through such a 7.4.  However, I think that folks working
in more agile companies, or even developers that want to get a head start
on preparing for 8.0 - will find value in such a release.  TBH, the vast
majority of users don't upgrade to our minor versions even when they bring
new features and capabilities.

Zeev

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

[Stanislav Malyshev]

Hi!

> There are multiple bug reports regarding strip_tags()'s broken behavior
> on (slightly) malformed HTML, e.g. ,
>  and , which
> renders the function unusable on arbitrary user supplied input.

I see a very corner-case issues that don't really make it "unusable" -
in fact, in these examples it looks like it chooses the most safe
approach. Which means it can't be used to fix broken HTML or parse
Javascript scripts, but that's not the point of this function anyway.

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

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

Re: [PHP-DEV] PHP 2^3

[Larry Garfield]

On Monday, June 25, 2018 11:16:31 AM CDT Sara Golemon wrote:

> > First, I'll admit that there's definitely some of that happening.  But to
> > paraphrase my daughters - "I didn't start it!".  In other words - people
> > are very actively looking for ways to run PHP in a Node-like manner, and
> > with the shift towards micro-services - I don't think it's a fad.  I
> > think we need to go there if we are to stay relevant.
> 
> Fair point.  I've certainly had discussions with Liz Smith and even
> been on Zend sponsored podcasts discussing ways we might "appify" PHP.
> But, and perhaps I'm just a bit more skeptical of the microservices
> train, I think we should be judicious in our pursuit of the new
> hotness. That's all.  Most of my response was centered on what felt
> like a rush.  Factoring in that entire paragraph about having a thin
> 7.4 release with a subsequent 8.0 GA alleviates my concerns a great
> deal.

When we speak of "typical web loads" not getting much benefit here, are we 
really talking about CGI-style "reboot every request" type loads rather than 
"IO-bound work"?  Because it's been observed many times in the past that one 
of the most expensive parts of a modern PHP app is simply booting up, 
initializing all of the services, wiring everything together... and then 
throwing it away 100 ms later.  If a JIT would make it more viable to pre-
start a web process (there are various all-user-space implementations in the 
wild already) so that an incoming request already had a fully booted system 
with container initialized and stuff, that could have a huge impact on web 
loads, even without going all-in on Node-style async.

(I am, of course, possibly talking out of my butt here.  Please advise if so.)

> > I still think that Dmitry's idea that we have a deprecation-only 7.4
> > sometime in 2019 makes sense.  If we really wanted to we could make it a
> > deprecation+some extras version, but I'm concerned about fragmenting our
> > scarce resources.  I don't think the sky will fall in case we take 18-24
> > months between our last 7.x feature release and 8.0.  We've had that
> > between 5.6 and 7.0 and I think it worked pretty well.
> 
> I'm not against some features for 7.4.  I'd even say Niki's typed
> properties (which isn't a minor change) can slot in there happily
> enough.  But we can dig in deeper over time on that.  Maybe he gets it
> into 7.3? ¯\_(ツ)_/¯
> 
> -Sara

Question from the peanut gallery: why would 7.4 need to be a deprecation-
mostly release?  Is the concern that it would make merging to the engine 
changes in 8.0 harder?  Something else?  I guess I'm missing why a 7.4 that 
adds warnings about "stop doing this now so your code works in 8" would 
conflict with a 7.4 that also adds whatever routine functionality or 
improvements get developed in the meantime.  (Typed properties or otherwise.)

Historical note: If we view PHP 5.3 as PHP 6 (which it was in any meaningful 
sense), then PHP's had a remarkably consistent ~5 year run for each major 
version for quite some time now.  That would put November 2020 as the natural, 
expected release date for 8.0, which especially if it's signaled now would 
give everyone ample time to prepare and expect it right on schedule.

Also, while uptake of new PHP versions is still way slower than the release of 
new PHP versions, at least based on the Composer data that Jordi releases it's 
getting steadily better over time.  The reasons for that are likely complex 
but we're a long long way from the days when the GoPHP5 project was needed. 
:-)  (And good riddance to those days.)

--Larry Garfield

signature.asc
Description: This is a digitally signed message part.

Re: [PHP-DEV] PHP 8 next?

[Chase Peeler]

On Mon, Jun 25, 2018 at 1:16 PM Mark Baker  wrote:

> On 24/06/2018 18:23, Rowan Collins wrote:
> > I've argued before that there should be a roadmap and a cycle for major
> releases, and if not, then some agreement on what triggers one, but we've
> so far not managed to agree either.
>
> I do believe a road map and a cycle is a good idea. I'm hearing some
> complaints from on the ground that releases are currently too frequent,
> making it difficult for larger organisations to keep up when they have
> to retest all their own apps/libraries/plugins with the new versions.
>
> A fixed cycle and schedule could help plan for change.
>
> --
> Mark Baker
>
>   _
> |.  \ \-3
> |_J_/ PHP |
> || |  __  |
> || |m|  |m|
>
>   I LOVE PHP
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
> I'd like to put in my two cents as someone in userland that isn't really
involved with the development lifecycle of PHP. I'm aware that my opinions
might not be shared by others, so I'm not claiming to speak for anyone else.

I've always viewed major releases as "This has MAJOR changes to the
backbone of PHP" - Old code is more likely to break during a major update,
but, doesn't have too. Minor releases, on the other hand, are more about
fixing the bigger bugs and introducing some new functionality, but nothing
ground-breaking. While still possible, the chances of old code breaking
should be pretty small. Changing that third number is just about security
and bug fixes.

Let me expand on two of those points:
1.) Old code breaks during minor updates. We upgraded to 7.0 AFTER 7.1 was
released, because we had already made major updates to upgrade to 7.0, and
7.1 introduced a few things that would have broken our code - we didn't
have time to fix those by that point. "Throw on passing too few function
arguments" would actually break more stuff in our legacy code than all of
the 7.0 changes combined.
2.) JIT, FFI, and Async are things I'd consider "major changes to the
backbone of PHP" just like the overhauled engine in PHP 7.

Finally, I personally see the idea of a deprecation only release to be kind
of silly. I don't work for a software company. It's tough enough for me to
make a case for upgrading using the "increase performance" and "new
features" argument. There is no way I'd get the go-ahead to do an upgrade
that would just make additional features deprecated. It would be a better
use of my time to look for and fix the deprecated features as part of the
8.0 upgrade prep, than to upgrade to 7.4. Maybe look at at backporting some
of the new 8.0 features that aren't really dependent on the major things
like JIT, async, etc., as part of the 7.4 release.

-- 
-- Chase
chasepee...@gmail.com

Re: [PHP-DEV] PHP 2^3

[Zeev Suraski]

On Mon, Jun 25, 2018 at 7:16 PM Sara Golemon  wrote:

> Yeah, like I said, I must have completely missed that entire
> paragraph.  Mid-2020, following a late-2019 release of a "light" 7.4
> with deprecations is reasonable, though I don't think it'd be such a
> bad idea if we kept it on schedule to GA 8.0 with all the goodies in
> Nov 2020.  As alluded, I kind of like that FF happens in the summer
> when things *should* be relatively slow otherwise.
>

Well, my guesstimate for the timeline was actually 2-2.5yrs from now, so
that's ranging from mid 2020 to late 2020.  You have a point that releasing
in summer isn't the smartest thing to do, so planning to hit later in that
year probably makes sense.  I think we should probably keep ourselves some
flexibility on the final date as we see how the different projects progress
- perhaps September through December 2020.

And based on the timetable that I realize I should have seen but
> missed, you've got my vote.
>

Awesome!


> > I still think that Dmitry's idea that we have a deprecation-only 7.4
> > sometime in 2019 makes sense.  If we really wanted to we could make it a
> > deprecation+some extras version, but I'm concerned about fragmenting our
> > scarce resources.  I don't think the sky will fall in case we take 18-24
> > months between our last 7.x feature release and 8.0.  We've had that
> between
> > 5.6 and 7.0 and I think it worked pretty well.
> >
> I'm not against some features for 7.4.  I'd even say Niki's typed
> properties (which isn't a minor change) can slot in there happily
> enough.  But we can dig in deeper over time on that.  Maybe he gets it
> into 7.3? ¯\_(ツ)_/¯
>
> Personally I don't think that's 7.3 material, even when factoring out my
dislike for scalar properties in the way they're currently implemented, and
I think there's value in putting something as substantial as that in the
major version as another 'attraction point' for people to migrate.  I'm
sure we'll discuss it thoroughly...

By the way, perhaps weak STH are another thing we can revisit for 8 - looks
like there were quite a few surprised folks out there regarding their
current behavior, and that implementing them closer to the old Coercive STH
RFC might be useful (without affecting the strict STH).  Not sure I have
the mental strength for that though :)

Zeev

Re: [PHP-DEV] PHP 8 next?

[Mark Baker]

On 24/06/2018 18:23, Rowan Collins wrote:

I've argued before that there should be a roadmap and a cycle for major 
releases, and if not, then some agreement on what triggers one, but we've so 
far not managed to agree either.


I do believe a road map and a cycle is a good idea. I'm hearing some 
complaints from on the ground that releases are currently too frequent, 
making it difficult for larger organisations to keep up when they have 
to retest all their own apps/libraries/plugins with the new versions.


A fixed cycle and schedule could help plan for change.

--
Mark Baker

 _
|.  \ \-3
|_J_/ PHP |
|| |  __  |
|| |m|  |m|

 I LOVE PHP


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

Re: [PHP-DEV] PHP 8 next?

[Mark Baker]

On 24/06/2018 01:58, Levi Morrison wrote:

Neither JIT nor FFI require backwards compatibility breaks in
language. I don't think either of those particular features would
substantially break the C API either. If these are the motivations for
PHP 8 then I strongly object.


Personally, I think that the big jump in performance that JIT warrants 
is enough to justify a major version change, and it makes for a strong 
selling point, even if there are no BC breaks


--
Mark Baker

 _
|.  \ \-3
|_J_/ PHP |
|| |  __  |
|| |m|  |m|

 I LOVE PHP


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

Re: [PHP-DEV] PHP 2^3

[Johannes Schlüter]

On Mo, 2018-06-25 at 09:58 -0500, Ralph Schindler wrote:
> On 6/25/18 9:13 AM, Johannes Schlüter wrote:
> > 
> > On Mo, 2018-06-25 at 12:30 +, Zeev Suraski wrote:
> > > 
> > > 3. Foreign Function Interface support.
> > Related to this on a non-PHP-code and strategic matter I would like
> > to rethink PECL. Currently maintenance and installing extensions
> > using it is a pita. This should be doable in a nicer way.
> Is it worthwhile to also consider some form of safe runtime
> registration  of extensions (or extension-like whatever that looks
> like in a JIT model).. A la dl()?
> 
> I realize in today's age of containerized projects (1 php install per
> project, everything owned by root per-se) makes PHP with esoteric 
> extensions much easier, it still would be nice if I could composer 
> install a specific version of an extension; like xdebug in a 
> require-dev, or require one of the new kafka extensions at the
> project level.
> 

For a goal I agree, I however see hurdles on the way (need to avoid
startup costs on each request, eventually need to handle use of
different versions of the extension on subsequent requests) I believe a
more narrow and stable extension API might be a start for that.

johannes


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

Re: [PHP-DEV] PHP 2^3

[Sara Golemon]

On Mon, Jun 25, 2018 at 9:58 AM, Zeev Suraski  wrote:
> Note that I did propose that we actually have a thin depredations-only PHP
> 7.4 (to give credit where credit's due, that's Dmitry's idea).  This gives
> us ample time without having to rush deprecations into 7.3
>
I apologize. I had missed that in my initial reading, but you
certainly did propose that (or rather, Dimitry did, I suppose).
I agree with this tack.

> I think it's entirely unreaslitic (or remarkably optimistic if you prefer)
> to think we'd have this done in under 18 months.  There's still tons of work
> we'd want to do in the JIT front, the work is entirely ahead of us as far as
> async and preloading are concerned - and that's without even factoring in
> the amount of time that discussions would take nor the fact we're likely to
> still be busy with 7.3 for quite some time.  Releasing it at the end of 2019
> effectively means we can squeeze such a huge version in the same timeline we
> took for incredibly smaller versions like 7.1, 7.2 or 7.3.  I think we're
> good, but we're not THAT good :)  I also don't think there's anything
> 'sacred' about releasing at the end of a particular year.
>
Yeah, like I said, I must have completely missed that entire
paragraph.  Mid-2020, following a late-2019 release of a "light" 7.4
with deprecations is reasonable, though I don't think it'd be such a
bad idea if we kept it on schedule to GA 8.0 with all the goodies in
Nov 2020.  As alluded, I kind of like that FF happens in the summer
when things *should* be relatively slow otherwise.

> First, I'll admit that there's definitely some of that happening.  But to
> paraphrase my daughters - "I didn't start it!".  In other words - people are
> very actively looking for ways to run PHP in a Node-like manner, and with
> the shift towards micro-services - I don't think it's a fad.  I think we
> need to go there if we are to stay relevant.
>
Fair point.  I've certainly had discussions with Liz Smith and even
been on Zend sponsored podcasts discussing ways we might "appify" PHP.
But, and perhaps I'm just a bit more skeptical of the microservices
train, I think we should be judicious in our pursuit of the new
hotness. That's all.  Most of my response was centered on what felt
like a rush.  Factoring in that entire paragraph about having a thin
7.4 release with a subsequent 8.0 GA alleviates my concerns a great
deal.

> With JIT - it's bit of a mixed bag.  After so many efforts went into it and
> we managed to get something pretty nice going - it was also a bit of a
> solution looking for a problem.  That's where the idea of expanding PHP to
> other areas came from.  And to be perfectly honest - it's not that I
> invented this approach either - people have been using PHP for non-Web
> workloads since forever.  Plus, we're still hopeful that it would show
> benefits for the Web world, especially in conjunction with preloading and
> the fact it'll enable PHP-based built-in functions (which is another thing
> we've wanted for a long time).
>
Right.  And I'll add that although this same thing is true of HHVM's
JIT (that it's actually kind of naff on common web workloads), it's
also true that taking the wider view which includes things like whole
program analysis (a factor of which is the pre-loading you mentioned)
does make the usability of the JIT more impactful.  I would also be
the last to argue against the ability to deliver some of PHP's
standard library in script form.  There are even places where this can
provide a marginal, but non-zero gain over C implementations since
marshaling between internals and user-space code can be avoided, or
branches within the implementation can be elided by the optimizer.  Ya
can't optimize what you can't see, and the optimizer can't see AoT
compiled C code.

Again, not arguing against any of these things in their own right.  I
certainly appreciate the work that Dimitry and you and putting into
making this happen.  My only concern (and I'll admit it's slightly
spurred by Niki's last minute proposal for typed properties) is timing
and our proximity to PHP-7.3's branch point.

> Again, the main goal here is to
> gauge the level of willingness of people to say that PHP 8 is going to be
> the next feature release of PHP after 7.3, and to allocate a longer timeline
> for us to successfully deliver it than the standard yearly cadence (as was
> pretty much always the case with major versions).
>
And based on the timetable that I realize I should have seen but
missed, you've got my vote.

> I still think that Dmitry's idea that we have a deprecation-only 7.4
> sometime in 2019 makes sense.  If we really wanted to we could make it a
> deprecation+some extras version, but I'm concerned about fragmenting our
> scarce resources.  I don't think the sky will fall in case we take 18-24
> months between our last 7.x feature release and 8.0.  We've had that between
> 5.6 and 7.0 and I think it worked pretty well.
>
I'm not against some 

Re: [PHP-DEV] Re: PHP 2^3

[Zeev Suraski]

On Mon, Jun 25, 2018 at 5:57 PM Christoph M. Becker 
wrote:

> On 25.06.2018 at 14:30, Zeev Suraski wrote:
>
> > What this list is - a collection of directions around which we've
> performed varying amounts of research (some of them quite a lot, like JIT),
> that I think is strong grounds for us to start discussing a PHP 8 timeline,
> and making PHP 7.3 the last feature release in the PHP 7.x family.  If we
> had to come up with an educated guess as to when PHP 8 could be ready to be
> released based on the abovementioned featureset, we're probably talking
> about 2-2.5yrs away (i.e. mid/late 2020).  We can also consider having a
> very slim PHP 7.4 release sometime in 2019 that wouldn't add any
> functionality, but that would give us an opportunity to deprecate anything
> that we missed in 7.3 that truly requires deprecation - while still
> allowing folks to prepare for 8.0 ahead of time.
>
> Why not stick with our yearly release cycle, and ship 7.4.0 in Dec 2019
> and 8.0.0 in Dec 2020?
>

We could and I think we should, but I don't think 7.4 should be a feature
release - but rather another release where we can deprecate things without
rushing them into 7.3, and at the same time provide people with a smoother
upgrade path to 8.0 (even though as you know, I'm not the biggest fan of
compatibility breakages...).  We've never been successful at working on two
active-development branches at the same time, and with the resource levels
we have - I don't think it's practical.

To be perfectly honest, I don't think our userbase for the most part is
actually consuming the feature releases at nearly the frequency that we're
producing them.  It's a healthy release cycle, but I really don't think
that there would be any meaningful downside to have two years between the
last feature-release 7.x and 8.0.

Zeev

Re: [PHP-DEV] PHP 2^3

[Zeev Suraski]

Thanks for taking the time to respond!

On Mon, Jun 25, 2018 at 5:27 PM Sara Golemon  wrote:

> 1/ Pushing 8.0 as 7.3 + 1 means we're going to rush deprecations into
> 7.3 which is already in fire-hose mode of last-minute, under-planned
> "hey I want this toy" requests.  Yes, deprecations are a little bit
> more sweaty ice cube in terms of late deprecations being lower risk
> that late additions, but it's still turning into a rushed thing during
> a season when some folks are off on holiday break.  The FF is in
> Summer in part *because* this is a bad time to introduce RFCs.
>

Note that I did propose that we actually have a thin depredations-only PHP
7.4 (to give credit where credit's due, that's Dmitry's idea).  This gives
us ample time without having to rush deprecations into 7.3

2/ In several of theses cases we're talking about something that's not
> even fully scoped out yet.  Async, for example, "requires a lot more
> research".  Yes, that research can probably be completed and turned
> into an implementation in the 1.5 years we have till the Nov 2019 GA
> (whatever version that ends up being), but there are multiple items on
> this list which are not (seemingly) fully fleshed out.
>

I think it's entirely unreaslitic (or remarkably optimistic if you prefer)
to think we'd have this done in under 18 months.  There's still tons of
work we'd want to do in the JIT front, the work is entirely ahead of us as
far as async and preloading are concerned - and that's without even
factoring in the amount of time that discussions would take nor the fact
we're likely to still be busy with 7.3 for quite some time.  Releasing it
at the end of 2019 effectively means we can squeeze such a huge version in
the same timeline we took for incredibly smaller versions like 7.1, 7.2 or
7.3.  I think we're good, but we're not THAT good :)  I also don't think
there's anything 'sacred' about releasing at the end of a particular year.


> 3/ When I read phrases like "open the door for new types of workloads
> for PHP (non Web)", and "one of the key reasons Node is gaining
> popularity", and " 'bleeding edge' technologies, such as AI and
> Machine Learning" I smell a trend of chasing the new hotness and
> worrying about factors other than making PHP the best language for the
> Web.  Growing PHP is great, and evolving it into new areas is also
> potentially quite good, but we *have* history showing what happens
> when we come up with something new to chase after that then turns out
> to be underwhelming, undermaintained, and underutilized.  I've also
> seen what a JIT does in terms of additional complexity, it's not
> pretty.
>

First, I'll admit that there's definitely some of that happening.  But to
paraphrase my daughters - "I didn't start it!".  In other words - people
are very actively looking for ways to run PHP in a Node-like manner, and
with the shift towards micro-services - I don't think it's a fad.  I think
we need to go there if we are to stay relevant.

With JIT - it's bit of a mixed bag.  After so many efforts went into it and
we managed to get something pretty nice going - it was also a bit of a
solution looking for a problem.  That's where the idea of expanding PHP to
other areas came from.  And to be perfectly honest - it's not that I
invented this approach either - people have been using PHP for non-Web
workloads since forever.  Plus, we're still hopeful that it would show
benefits for the Web world, especially in conjunction with preloading and
the fact it'll enable PHP-based built-in functions (which is another thing
we've wanted for a long time).

With FFI, I think the risks are low and the potential benefits are
substantial.  Out of the major ideas, this is probably the one I'm mentally
least attached to - but here too, I see few downsides to doing it.

4/ When the $(%* did we body swap, because it's not quite full
> turnabout, but I'm suddenly having flashbacks of "give the language a
> rest". :)


People evolve :)


>
> Please don't construe this response as entirely negative.  As I said
> in other replies, I'm actually quite excited about these new things
> and the directions they open up, and it may be that you and Dimitri
> have been spending quite a lot of time thinking about them and their
> implications to the language going forward.  However, like the NG
> branch prior to 7.0, most of this appears to lack any sort of plan for
> those of us not in your private email threads.  Yes, we've discussed
> all of them at one point or another, but apart from the JIT, there's
> been no obvious signs of work on any of them, which brings me back to
> being concerned about 7.3 suddenly being flagged as the last 7.x
> release within mere DAYS of its planned feature freeze branch date
> without warning.
>

I'm not taking your comments negatively at all!  I do want to point out
that this time around everything we did was done in public as much as we
could - including both JIT and FFI.  There hasn't been any 

Re: [PHP-DEV] PHP 2^3

[Ralph Schindler]

On 6/25/18 9:13 AM, Johannes Schlüter wrote:

On Mo, 2018-06-25 at 12:30 +, Zeev Suraski wrote:

3. Foreign Function Interface support.


Related to this on a non-PHP-code and strategic matter I would like to
rethink PECL. Currently maintenance and installing extensions using it
is a pita. This should be doable in a nicer way.


Is it worthwhile to also consider some form of safe runtime registration 
of extensions (or extension-like whatever that looks like in a JIT 
model).. A la dl()?


I realize in today's age of containerized projects (1 php install per 
project, everything owned by root per-se) makes PHP with esoteric 
extensions much easier, it still would be nice if I could composer 
install a specific version of an extension; like xdebug in a 
require-dev, or require one of the new kafka extensions at the project 
level.


-ralph

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

[PHP-DEV] Re: PHP 2^3

[Christoph M. Becker]

On 25.06.2018 at 14:30, Zeev Suraski wrote:

> What this list is - a collection of directions around which we've performed 
> varying amounts of research (some of them quite a lot, like JIT), that I 
> think is strong grounds for us to start discussing a PHP 8 timeline, and 
> making PHP 7.3 the last feature release in the PHP 7.x family.  If we had to 
> come up with an educated guess as to when PHP 8 could be ready to be released 
> based on the abovementioned featureset, we're probably talking about 2-2.5yrs 
> away (i.e. mid/late 2020).  We can also consider having a very slim PHP 7.4 
> release sometime in 2019 that wouldn't add any functionality, but that would 
> give us an opportunity to deprecate anything that we missed in 7.3 that truly 
> requires deprecation - while still allowing folks to prepare for 8.0 ahead of 
> time.

Why not stick with our yearly release cycle, and ship 7.4.0 in Dec 2019
and 8.0.0 in Dec 2020?

-- 
Christoph M. Becker

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

Re: [PHP-DEV] PHP 7.1.19 - where are the gpg signatures?

[Sara Golemon]

On Mon, Jun 25, 2018 at 9:53 AM, Christoph M. Becker  wrote:
>  appears to work
> as well.
>
Yeah, because Joe and I already fixed it. :D
Snooze ya lose, brother.

-Sara

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

Re: [PHP-DEV] PHP 7.1.19 - where are the gpg signatures?

[Christoph M. Becker]

On 25.06.2018 at 16:48, Helmut K. C. Tessarek wrote:

> On 2018-06-25 16:34, Sara Golemon wrote:
>
>> Looks like Joe accidentally generated unarmored .sig files instead of
>> the usual .asc file.
> 
> Ah, ok. .sig files are perfectly fine, too.
> I just didn't see the links, nor the .sig files, since no servers with
> php sources seem to allow directory listing.
> 
> The .sig files were synced to the mirrors, so only the links on the web
> site are missing.
> (http://php.net/get/php-7.1.19.tar.xz.sig/from/a/mirror works)

 appears to work
as well.

-- 
Christoph M. Becker

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

Re: [PHP-DEV] PHP 7.1.19 - where are the gpg signatures?

[Sara Golemon]

On Mon, Jun 25, 2018 at 9:48 AM, Helmut K. C. Tessarek
 wrote:
> On 2018-06-25 16:34, Sara Golemon wrote:
> Ah, ok. .sig files are perfectly fine, too.
> I just didn't see the links, nor the .sig files, since no servers with
> php sources seem to allow directory listing.
>
Yeah, we don't normally publish unarmored signatures 'cause the base64
versions tend to be more portable.  He literally just missed a switch
on a command line.
Anyway, he's pushed new ASC signatures and they should be syncing to
the mirrors now.

-Sara

P.S. - You sort of can do directory listing, just not from the main
webservers: http://git.php.net/?p=web/php-distributions.git;a=tree

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

Re: [PHP-DEV] PHP 7.1.19 - where are the gpg signatures?

[Helmut K. C. Tessarek]

On 2018-06-25 16:34, Sara Golemon wrote:
> Looks like Joe accidentally generated unarmored .sig files instead of
> the usual .asc file.

Ah, ok. .sig files are perfectly fine, too.
I just didn't see the links, nor the .sig files, since no servers with
php sources seem to allow directory listing.

The .sig files were synced to the mirrors, so only the links on the web
site are missing.
(http://php.net/get/php-7.1.19.tar.xz.sig/from/a/mirror works)

Thanks for looking into this.

Cheers,
  K. C.

-- 
regards Helmut K. C. Tessarek  KeyID 0x172380A011EF4944
Key fingerprint = 8A55 70C1 BD85 D34E ADBC 386C 1723 80A0 11EF 4944

/*
   Thou shalt not follow the NULL pointer for chaos and madness
   await thee at its end.
*/



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] PHP 7.1.19 - where are the gpg signatures?

[Sara Golemon]

On Mon, Jun 25, 2018 at 6:53 AM, Helmut K. C. Tessarek
 wrote:
> The gpg signatures for the PHP 7.1.19 source tarballs are missing.
>
Looks like Joe accidentally generated unarmored .sig files instead of
the usual .asc file.

Joe, could you re-issue the signatures as .asc files?  I could
probably convert these (it's mostly just base64 and a little CRC32
magic), but it'd be better done using the proper tooling.

Thanks for checking the signatures, Helmut, and double-thanks for
letting us know!

-Sara

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

Re: [PHP-DEV] PHP 2^3

[Sara Golemon]

On Mon, Jun 25, 2018 at 7:30 AM, Zeev Suraski  wrote:
> As I mentioned a few days ago I intended to send it slightly later - but as 
> Nikita brought up the topic of PHP 8, this is probably as good a time as any 
> to start the discussion.
>
> Please note:  The goal of this email isn't to discuss in detail each and 
> every topic that's mentioned, but rather to establish whether we want to move 
> to focus on PHP 8 as we go beyond PHP 7.3, based on some of the research 
> projects and PoCs we've been working on.
>
With the above paragraph in mind, I would say yes; This laundry list
sounds like major bump worthy items.  However I'm going to throw some
negatives in here and probably start longer threads separately on my
concerns with specific items.

1/ Pushing 8.0 as 7.3 + 1 means we're going to rush deprecations into
7.3 which is already in fire-hose mode of last-minute, under-planned
"hey I want this toy" requests.  Yes, deprecations are a little bit
more sweaty ice cube in terms of late deprecations being lower risk
that late additions, but it's still turning into a rushed thing during
a season when some folks are off on holiday break.  The FF is in
Summer in part *because* this is a bad time to introduce RFCs.

2/ In several of theses cases we're talking about something that's not
even fully scoped out yet.  Async, for example, "requires a lot more
research".  Yes, that research can probably be completed and turned
into an implementation in the 1.5 years we have till the Nov 2019 GA
(whatever version that ends up being), but there are multiple items on
this list which are not (seemingly) fully fleshed out.

3/ When I read phrases like "open the door for new types of workloads
for PHP (non Web)", and "one of the key reasons Node is gaining
popularity", and " 'bleeding edge' technologies, such as AI and
Machine Learning" I smell a trend of chasing the new hotness and
worrying about factors other than making PHP the best language for the
Web.  Growing PHP is great, and evolving it into new areas is also
potentially quite good, but we *have* history showing what happens
when we come up with something new to chase after that then turns out
to be underwhelming, undermaintained, and underutilized.  I've also
seen what a JIT does in terms of additional complexity, it's not
pretty.

4/ When the $(%* did we body swap, because it's not quite full
turnabout, but I'm suddenly having flashbacks of "give the language a
rest". :)


Please don't construe this response as entirely negative.  As I said
in other replies, I'm actually quite excited about these new things
and the directions they open up, and it may be that you and Dimitri
have been spending quite a lot of time thinking about them and their
implications to the language going forward.  However, like the NG
branch prior to 7.0, most of this appears to lack any sort of plan for
those of us not in your private email threads.  Yes, we've discussed
all of them at one point or another, but apart from the JIT, there's
been no obvious signs of work on any of them, which brings me back to
being concerned about 7.3 suddenly being flagged as the last 7.x
release within mere DAYS of its planned feature freeze branch date
without warning.

Possible alternative.  Still aim for Nov 2019 GA of 8.0, but have a
7.4 in parallel with it.  This (sort of) happened with 4.4 being
released between 5.0 and 5.1 (I know, not quite the same).  This would
give us a couple advantages:

1/ Take our time with these last-minute "deprecate all the things"
RFCs that have suddenly popped up.
2/ Have an escape hatch to delay 8.0 till Nov 2020 if implementations
for the big stuff aren't quite ready for whatever reason rather than
being forced to push them to 9.0

Downsides, obvious: More merges for bugfixes and RM overhead, plus
Remi and Stephen's time with Fedora/Win32 builds.  We did this for the
5.x-7.x jump, I say we can do it here.

-Sara

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

Re: [PHP-DEV] PHP 2^3

[Zeev Suraski]

On Mon, Jun 25, 2018 at 3:31 PM Zeev Suraski  wrote:

> 1. JIT.  As most of you probably know, we've invested heavily in re-doing
> JIT on top of the PHP 7 infrastructure.  There are good news and bad news.
> The good news is that - like the JIT POC we did back in 2014 - the results
> for CPU intensive workloads are remarkable.  The bad news is that it
> doesn't significantly move the needle for typical Web workloads.
> That said, unlike 2014 - where we had another avenue to go after, this
> time we believe that JIT doesn't improve the performance of typical Web
> workloads simply because the bottleneck there is no longer PHP code
> execution.
> However, I still think we should still include JIT in the next major
> version of PHP for at least 2 reasons:
>   - It will open the door for new types of workloads for PHP (non Web)
>   - It may open the door for new built-in functionality being written in
> PHP - for more secure code (e.g. a PHP unserialize() implementation,
> instead of one in C)
> In addition, it's always possible that we're missing something in our
> benchmarks and that there are real world Web workloads that would actually
> benefit from the speedup.
> One thing worth noting is that in all likelihood, we'd want to make
> OPcache (or at least large parts of it) a part of the core engine (and no
> longer a separate extension) as a part of the JIT effort.
> - (bonus) Combined with other things we're experimenting with, the
> compound effect may still result in better performance for Web apps.
> To get a feel for the performance gains we're talking about here, I
> recorded a benchmark comparing PHP 7.0 and the JIT PoC, available here:
> https://www.youtube.com/watch?v=dWH65pmnsr
>
> Argh - the URL was trimmed - that's the correct one:

https://www.youtube.com/watch?v=dWH65pmnsrI

Zeev

Re: [PHP-DEV] PHP 2^3

[Johannes Schlüter]

On Mo, 2018-06-25 at 12:30 +, Zeev Suraski wrote:
> 3. Foreign Function Interface support. 

Related to this on a non-PHP-code and strategic matter I would like to
rethink PECL. Currently maintenance and installing extensions using it
is a pita. This should be doable in a nicer way. 
(i.e. pecl pointing directly to Git(Hub) repos, similar to composer, a
way to install precompiled binaries, probably using a more narrow
stable API, better reporting of dependency issues, with the new
execution model of your point 2 also better integration with composer,
...)

johannes

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

Re: [PHP-DEV] PHP 8 next?

[Rowan Collins]

Hi Levi,

On 24 June 2018 22:26:24 BST, Levi Morrison  wrote:
>> Are there particular breaking changes that you think would be ready
>in 2 years time that wouldn't be ready in 1?
>
>Certainly. Large breaks require multi-year planning and multiple
>releases to add migration paths, documentation and training,
>deprecations, etc, before the change itself happens. If PHP 8 is the
>next release then we've missed the window for deprecations and
>warnings (mostly; feature freeze is imminent).

That makes sense. :)

What do you think about planning 8.0 for 2020, which gives us a year
to build those plans into 7.4?

I think it would be good to set a specific target, even if only
approximately, so that we don't just have the same discussion in a
year's time.


>I wish our symbol tables were merged. If they were they we could
>nicely solve some issues...

I'm not entirely sure what deprecation would look like for this, but I
guess that makes it a perfect example of something that needs time to
plan. :)


Regards,
-- 
Rowan Collins
[IMSoP]

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

[PHP-DEV] PHP 2^3

[Zeev Suraski]

As I mentioned a few days ago I intended to send it slightly later - but as 
Nikita brought up the topic of PHP 8, this is probably as good a time as any to 
start the discussion.

Please note:  The goal of this email isn't to discuss in detail each and every 
topic that's mentioned, but rather to establish whether we want to move to 
focus on PHP 8 as we go beyond PHP 7.3, based on some of the research projects 
and PoCs we've been working on.

There are several areas that I think we should invest in in the next major 
version:

1. JIT.  As most of you probably know, we've invested heavily in re-doing JIT 
on top of the PHP 7 infrastructure.  There are good news and bad news.  The 
good news is that - like the JIT POC we did back in 2014 - the results for CPU 
intensive workloads are remarkable.  The bad news is that it doesn't 
significantly move the needle for typical Web workloads.
That said, unlike 2014 - where we had another avenue to go after, this time we 
believe that JIT doesn't improve the performance of typical Web workloads 
simply because the bottleneck there is no longer PHP code execution.
However, I still think we should still include JIT in the next major version of 
PHP for at least 2 reasons:
  - It will open the door for new types of workloads for PHP (non Web)
  - It may open the door for new built-in functionality being written in PHP - 
for more secure code (e.g. a PHP unserialize() implementation, instead of one 
in C)
In addition, it's always possible that we're missing something in our 
benchmarks and that there are real world Web workloads that would actually 
benefit from the speedup.
One thing worth noting is that in all likelihood, we'd want to make OPcache (or 
at least large parts of it) a part of the core engine (and no longer a separate 
extension) as a part of the JIT effort.
- (bonus) Combined with other things we're experimenting with, the compound 
effect may still result in better performance for Web apps.
To get a feel for the performance gains we're talking about here, I recorded a 
benchmark comparing PHP 7.0 and the JIT PoC, available here:
https://www.youtube.com/watch?v=dWH65pmnsr

2. Better support long-running, async-based, microservices-focused execution 
model.  It's probably no secret that one of the key reasons Node is gaining 
popularity is because it can handle a huge number of concurrent connections 
issuing relatively lightweight requests very efficiently - which is a good 
match for modern microservices based architectures.  There are already several 
projects available for PHP that aim to provide similar functionality - most 
notably ReactPHP and more recently Swoole.
The main thing that is missing is that most of PHP's IO doesn't support async 
execution.  What I think we should do is add as much support for async IO as 
possible across the various extensions and streams - so that using something 
like Swoole would become practical for more use cases.  More specifically - the 
goal would be to provide extension authors with mechanisms that they can use to 
make their extensions/functions optionally asynchronous, without having to 
tackle the job entirely on their own.  While we've done some research into this 
area, it requires a lot more research - but I'm cautiously optimistic that it 
can be done.  We would potentially want to use libuv for this task, and 
potentially rewrite or otherwise refactor parts of the PHP streams system.

3. Foreign Function Interface support.  Essentially, make it very easy to 
connect PHP to native code libraries written in C or C++ without having to 
write an extension.  Now, I realize this may not sound like much more than an 
extension - however, I think that if we look at the potential impact and not 
just the complexity of implementation - this is actually quite strategic.  This 
can open the door for PHP to be used a lot more often in conjunction with 
'bleeding edge' technologies, such as AI and Machine Learning, and not just 
ones existing today - but kind of 'future proof' it for whatever technologies 
emerge down the road.  Dmitry brought that up on the mailing list already, and 
he's made quite a bit of progress there.  He actually spent the last couple of 
weeks writing TensorFlow bindings for PHP, and wrote what's probably the first 
Neural Network in PHP - recognizing handwritten digits with 98% precision 
(https://github.com/dstogov/php-tensorflow/blob/master/test_nmist_01.php).  I 
think that especially combined with JIT - this can make PHP a real powerhouse 
for executing CPU intensive apps, while not compromising on developer 
productivity.  By the way, to make it go truly fast (especially in conjunction 
with JIT), we'll likely want this to actually be merged into the core engine as 
well, and not as a separate extension.

4. Preloading support.  We've discussed this at a high level numerous times, 
but if we end up introducing JIT into PHP 8 as I hope we will, preloading 
support can very nicely 

Re: [PHP-DEV] Equality and relative ordering of objects

[Rudi Theunissen]

The part I found difficult was in the handlers - we only have `compare`, no
equals.
The only way we can have the handler differentiate between equality and
ordering
is if we pass a parameter to the handler, which means we'd have to change
the header.

From:

`typedef int (*zend_object_compare_zvals_t)(zval *result, zval *op1, zval
*op2);`

To:

`typedef int (*zend_object_compare_zvals_t)(zval *result, zval *op1, zval
*op2, int mode);`

Or we could introduce a new handler? Not sure if that's something we can do
easily.

[PHP-DEV] PHP 7.1.19 - where are the gpg signatures?

[Helmut K. C. Tessarek]

Hello,

The gpg signatures for the PHP 7.1.19 source tarballs are missing.

Cheers,
  K. C.

-- 
regards Helmut K. C. Tessarek  KeyID 0x172380A011EF4944
Key fingerprint = 8A55 70C1 BD85 D34E ADBC 386C 1723 80A0 11EF 4944

/*
   Thou shalt not follow the NULL pointer for chaos and madness
   await thee at its end.
*/



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] Equality and relative ordering of objects

[Rudi Theunissen]

>
> Java has .equals and .compareTo; these operations are separate. In
> Java neither integrates with operators.


Yeah that's right. I was just pointing out that Java's == always checks
against
the reference and you can't override it (so it's like PHP's ===). Their
.equals()
method is like PHP's ==.

I agree that it's better to separate the two operations, which is why the
first message
in this thread talked about __equals and __compareTo. However, when I
started
implementing it, I couldn't see a nice way to separate them internally as
everything
goes through `compare_function`.

On Sun, 24 Jun 2018 at 23:31, Levi Morrison  wrote:

> On Sun, Jun 24, 2018 at 2:31 PM Rudi Theunissen 
> wrote:
> >>
> >> Other languages (most? all?) separate equality and ordering for this
> reason.
> >
> >
> > Java doesn't really separate them. Their `==` always checks object
> reference so is like PHP's ===.
> > But they do have the .equals() method on all objects (our ==) and the
> collections use that for equality.
>
> Java has .equals and .compareTo; these operations are separate. In
> Java neither integrates with operators.
>

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

[Christoph M. Becker]

On 25.06.2018 at 08:12, Stanislav Malyshev wrote:

>> fgetss() function and string.strip_tags filter
> 
> I think I disagree with "strip_tags() itself, due to its limitations and
> known bugs, already has very few legitimate applications" and certainly
> the manual does not have any notice to that effect. I am not sure what
> is the reason to remove this functionality, would like to hear more
> about it - and it doesn't seem so minor as to be 1/4 of the RFC. If I
> had to vote today, I'd probably vote no just on this point.
> It may be true that strip_tags() alone without streaming part could be
> implemented easier. However, that is not a reason to drop functionality
> by itself, unless it's already completely broken. If it is, I'd like to
> hear more about it.

There are multiple bug reports regarding strip_tags()'s broken behavior
on (slightly) malformed HTML, e.g. ,
 and , which
renders the function unusable on arbitrary user supplied input.

-- 
Christoph M. Becker

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

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

[Stanislav Malyshev]

Hi!

> This RFC collects a number of deprecations for PHP 7.3 which I consider to
> be too minor to warrant a separate proposal. However, each deprecation will
> still be voted separately.
> 
> https://wiki.php.net/rfc/deprecations_php_7_3

> Undocumented mbstring function aliases

Not sure what this would give us. Yes, they are undocumented, but do
they hurt anything?

> String search functions with integer needle

That is definitely weird. However, I am not sure what should happen in
non-integer cases - i.e. what happens if I pass a double? Or a boolean?

> fgetss() function and string.strip_tags filter

I think I disagree with "strip_tags() itself, due to its limitations and
known bugs, already has very few legitimate applications" and certainly
the manual does not have any notice to that effect. I am not sure what
is the reason to remove this functionality, would like to hear more
about it - and it doesn't seem so minor as to be 1/4 of the RFC. If I
had to vote today, I'd probably vote no just on this point.
It may be true that strip_tags() alone without streaming part could be
implemented easier. However, that is not a reason to drop functionality
by itself, unless it's already completely broken. If it is, I'd like to
hear more about it.

> Defining a free-standing assert() function

Sounds good.

-- 
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] Deprecate and remove case-insensitive constants

[Stanislav Malyshev]

Hi!

> https://wiki.php.net/rfc/case_insensitive_constant_deprecation
> 
> This was already discussed some time ago on the list, though that
> discussion degenerated into unfortunate directions. I'd very much
> appreciate if we could keep discussions on making PHP fully case-sensitive
> or fully case-insensitive outside of this thread. (Feel free to open a new
> one though.)
> 
> The main point I'd like to have feedback on is the handling of true, false
> and null, as I'm not sure what the best approach regarding that is.

I think the must is to keep true/false/null working in all cases. I
don't think messing with this would be acceptable due to amount of code
it'd break.

Now, I think breaking constant("null") could be acceptable in PHP 8, if
necessary, as use case for this seems to be very narrow. However, I
wonder if we can't just special-case those three in constant() function
and write "for historical raisins, this is weird" and be done with it.
Not ideal, but practically might be good enough.

Converting them to keywords should be fine - am I wrong to think the
impact would not be that big with new parser, as we now have less places
where keywords are banned?

As for the rest, I think we should get rid of case-insensitive constants
(including defined by extensions) and all the weirdness that follows.
Deprecating them would be a good first step.

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

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