Re: [PHP-DEV] Updating bundled libs (specifially, oniguruma) on 7.1/7.2

[Levi Morrison]

On Fri, Mar 29, 2019 at 2:17 PM Stanislav Malyshev  wrote:
>
> Hi!
>
> > 7.1 have version 5.9.6
> > 7.2 have version 6.3.0
> > 7.3 have version 6.9.0 (latest is 6.9.1)
> > 7.4 only use system library
> >
> > As we encourage system library usage (default in 7.4), and if this raise
> > the minimal allowed version, this will create issue for 7.4
> >
> > Ex
> >   RHEL have 5.9
> >   Debian have 6.1
>
> Any reason why those are so far behind? 5.9 is from 2014!

Yes: Red Hat Enterprise Linux is intended to be *incredibly* stable.
It comes at the cost of always being a bit old.

> > I think we have to manage such change in a compatible way.
> > (feature availability tested in configure
>
> This creates a very bad situation, where we can not implement security
> improvements because we have to be compatible with a version of the
> library that has been released 4.5 years ago.

In many cases, Red Hat will backport security fixes to the old software.

> Is there any reason why we prefer system library if actual system
> library is not being properly maintained by packagers? I think if most
> packagers neglect to keep with latest versions so much, we should keep
> bundling it - otherwise, we are just exposing our users to security
> issues and give them slower and buggier and feature-impaired library
> despite being completely able to do better.

A lot of software will bundle unusual dependencies, and then have an
option to build using a given path, or to use the bundled extension. I
assume that's what we are doing with libonig? The person doing the
build should have the power to choose here.

> > P.S. from downstream PoV, as soname is different is it possible to have
> > compat package for library (v5.9 uses 2, v6.1 uses 4, v6.9 uses 5)
>
> Not sure what you mean here, could you explain?

I think Remi means that the .so files are versioned, so you end up
with libonig.so.2, libonig.so.4, and so on. Or alternatively they may
be named libonig2.so, libonig4.so, and so on. Either way, they can
coexist in the same library directory.

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

Re: [PHP-DEV] [RFC] Deprecate PHP's short open tags

[G. P. B.]

On Mon, 25 Mar 2019 at 20:42, Andrey Andreev  wrote:

> Hi,
>
> On Mon, Mar 25, 2019 at 8:02 PM G. P. B.  wrote:
> >
> > On Mon, 25 Mar 2019 at 16:38, Andrey Andreev  wrote:
> >>
> >> OK, so why not flip it and make it always available instead? I'm aware
> >> of the potential XML conflict, but I've personally never seen it, so
> >> to me that looks like the lesser evil compared to a massive BC break.
> >>
> >> Cheers,
> >> Andrey.
> >
> >
> > Technically this is already the case, the default in the engine is to
> enable PHP's short open tags, however both INI config templates provided
> > with PHP (php.ini-developement and php.ini-production) disable PHP's
> short open tags.
> > So if PHP's short open tags are to be considered "full class" open tags
> this should be represented in the INI templates. But I won't be the
> > one pushing for this change.
> >
>
> We're talking about removal of the INI setting ... Aside of saying you
> wouldn't be personally pushing for what I suggested, I don't get the
> point of what you wrote.
>
> Cheers,
> Andrey.
>

The point of what I wrote was to clarify what is the default value
in-engine of short open tags.

Also updated the RFC with the fact that using PHP's short open tags may
leaks source code if used when those aren't not enabled.

Best regards

George P. Banyard

Re: [PHP-DEV] Updating bundled libs (specifially, oniguruma) on 7.1/7.2

[Stanislav Malyshev]

Hi!

> 7.1 have version 5.9.6
> 7.2 have version 6.3.0
> 7.3 have version 6.9.0 (latest is 6.9.1)
> 7.4 only use system library
> 
> As we encourage system library usage (default in 7.4), and if this raise
> the minimal allowed version, this will create issue for 7.4
> 
> Ex
>   RHEL have 5.9
>   Debian have 6.1

Any reason why those are so far behind? 5.9 is from 2014!

> I think we have to manage such change in a compatible way.
> (feature availability tested in configure

This creates a very bad situation, where we can not implement security
improvements because we have to be compatible with a version of the
library that has been released 4.5 years ago.

Is there any reason why we prefer system library if actual system
library is not being properly maintained by packagers? I think if most
packagers neglect to keep with latest versions so much, we should keep
bundling it - otherwise, we are just exposing our users to security
issues and give them slower and buggier and feature-impaired library
despite being completely able to do better.

> P.S. from downstream PoV, as soname is different is it possible to have
> compat package for library (v5.9 uses 2, v6.1 uses 4, v6.9 uses 5)

Not sure what you mean here, could you explain?

-- 
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] Change the precedence of the concatenation operator

[David Rodrigues]

It makes sense to me. Can you perform some tests with big projects that
uses PHPUnit, at least? It will help to identify BC.

Em qui, 28 de mar de 2019 às 10:33, Bob Weinand 
escreveu:

> Hey,
>
> I feel like concatenation having the same precedence than addition and
> subtraction is promoting programmers to make mistakes. Albeit typically
> easy to catch ones, it is a quality of life change at least.
>
> Hence I'm proposing a RFC changing the precedences:
> https://wiki.php.net/rfc/concatenation_precedence
>
> Bob
>


-- 
David Rodrigues

Re: [PHP-DEV] [RFC] Change the precedence of the concatenation operator

[Stanislav Malyshev]

Hi!

> I feel like concatenation having the same precedence than addition
> and subtraction is promoting programmers to make mistakes. Albeit
> typically easy to catch ones, it is a quality of life change at
> least.

Changing operator precedence is usually a very bad idea, because it
tends to break code in random places that are very hard to detect.
Unless there's a huge reason to do it - and eliminating a couple of
parentheses is usually not - I'd stay away from such things. If you have
any doubts about precedence - just put the parentheses and forget about it.

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

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

Re: [PHP-DEV] Re: PHP 8 Preview Releases

[Alan Willms]

This could be a wonderful new feature for PHP 8:

https://github.com/nikic/scalar_objects

$string = "Hello world";
$string->toUpper()->replaceAll("world", "PHP 8");


On Fri, Mar 29, 2019 at 12:43 PM Sara Golemon  wrote:

> On Fri, Mar 29, 2019 at 7:40 AM Joe Watkins  wrote:
> > Since we now have a result for JIT and we know it will be included
> > in PHP 8, I think it's time to visit the idea brought up in discussion
> > to have preview releases of PHP 8.
> >
> > I'm interested in hearing what kind of schedules we think are going
> > to be useful - it's tempting to say let's track PHP-7.4 releases,
> > possibly with a bi-monthly interval, but I'm not sure if that may
> > be too soon, or too slow, or too fast.
> >
> IMO, preview releases should (for the time being) be largely driven by the
> progress of branch.  And by branch, let's be honest, I really mean the
> JIT.  So for the rest of 2019, this essentially (but not completely) means
> "When Dmitry wants something taken for a spin".  Maybe he rolls those, I
> don't mind rolling them for him if he's not inclined to do it.
>
> Coming into 2020, I think we should have monthly previews beginning one
> month after 7.4.0 GA until we reach the normal alpha period. (Preceding
> sentence is entirely provisional and subject to review as that time
> approaches)
>
> -Sara
>

[PHP-DEV] Re: PHP 8 Preview Releases

[Sara Golemon]

On Fri, Mar 29, 2019 at 7:40 AM Joe Watkins  wrote:
> Since we now have a result for JIT and we know it will be included
> in PHP 8, I think it's time to visit the idea brought up in discussion
> to have preview releases of PHP 8.
>
> I'm interested in hearing what kind of schedules we think are going
> to be useful - it's tempting to say let's track PHP-7.4 releases,
> possibly with a bi-monthly interval, but I'm not sure if that may
> be too soon, or too slow, or too fast.
>
IMO, preview releases should (for the time being) be largely driven by the
progress of branch.  And by branch, let's be honest, I really mean the
JIT.  So for the rest of 2019, this essentially (but not completely) means
"When Dmitry wants something taken for a spin".  Maybe he rolls those, I
don't mind rolling them for him if he's not inclined to do it.

Coming into 2020, I think we should have monthly previews beginning one
month after 7.4.0 GA until we reach the normal alpha period. (Preceding
sentence is entirely provisional and subject to review as that time
approaches)

-Sara

Re: [PHP-DEV] Re: PHP 8 Preview Releases

[Peter Kokot]

Hello,

On Fri, 29 Mar 2019 at 15:35, Dmitry Stogov  wrote:
>
> Hi Arvids,
>
>
> It's possible to test JIT with PHP-7.4 building PHP from 
> https://github.com/zendtech/php-src/tree/jit-dynasm-7.4
>
> But this branch is not going to be supported anymore.
>
>
> Thanks. Dmitry.
>
> 
> From: Arvids Godjuks 
> Sent: Friday, March 29, 2019 5:17:41 PM
> To: Joe Watkins
> Cc: Dmitry Stogov; release-manag...@php.net; PHP internals
> Subject: Re: [PHP-DEV] Re: PHP 8 Preview Releases
>
> Hello,
>
> I'd like to add that as the userland developer, it would be nice to be able 
> to build JIT against an active branch (a.k.a PHP 7.4), cause if PHP 8 brings 
> enough changes, it would not be realistic to fix our apps to be compatible 
> with PHP 8 months or years away from actual release.
>
> пт, 29 мар. 2019 г. в 15:58, Joe Watkins 
> mailto:krak...@gmail.com>>:
> Hi Dmitry,
>
> I'm not suggesting we do it right now, I'm suggesting we look at the
> planning of it right now as it deviates from our normal release cycle.
>
> At the moment we should just consider how we want it to work, including
> when it should start ...
>
> Cheers
> Joe
>
> On Fri, 29 Mar 2019 at 14:42, Dmitry Stogov 
> mailto:dmi...@zend.com>> wrote:
>
> > Hi Joe,
> >
> >
> > I think, PHP-8 preview is too early.
> >
> > We even didn't freeze PHP-7.4 yet, and PHP-8 didn't get any new major
> > features (may be I forgot something) only deprecations and some internal
> > improvements
> >
> > .
> >
> > According to JIT, it's probably going to be changed a lot in the nearest
> > future.
> >
> >
> > Thanks. Dmitry.
> > --
> > *From:* Joe Watkins mailto:krak...@php.net>>
> > *Sent:* Friday, March 29, 2019 3:40:04 PM
> > *To:* release-manag...@php.net; PHP 
> > internals; Dmitry Stogov
> > *Subject:* PHP 8 Preview Releases
> >
> > Morning internals,
> >
> > Since we now have a result for JIT and we know it will be included in PHP
> > 8, I think it's time to visit the idea brought up in discussion to have
> > preview releases of PHP 8.
> >
> > I'm interested in hearing what kind of schedules we think are going to be
> > useful - it's tempting to say let's track PHP-7.4 releases, possibly with a
> > bi-monthly interval, but I'm not sure if that may be too soon, or too slow,
> > or too fast.
> >
> > Thoughts please (especially from Dmitry) ?
> >
> > Cheers
> > Joe
> >
> >
> >
>
>
> --
> Arvīds Godjuks
>
> +371 26 851 664
> arvids.godj...@gmail.com
> Skype: psihius
> Telegram: @psihius https://t.me/psihius

PHP 8.0 is definitely tempting and wanted. First phase is definitely
for users to have option to install it manually from Git as is now.
The snapshot script:
https://github.com/php/php-src/blob/master/scripts/dev/snapshot
is on my list to improve a bit to have at least an option to get
archive package out of the current Git state. Between this and the
official downloadable release there isn't much difference in doing the
build manually.

What is more important for the end users is to have Docker image(s)
available or even some Linux packages.

Also, practice shows that the dev branch in state before the few
months prior to the releases contains really a lot of bugs and also
build system bugs that normal users will have serious issues setting
this up. If Linux packagers and 3rd party repository maintainers can
help here, that would be also one way to go since PHP seems to be very
far away from doing such steps on the php.net side...

But to have PHP 8.0.0alpha1 version available at this and this date
before the PHP 7.4 release is quite challenging for all, I think.

-- 
Peter Kokot

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

Re: [PHP-DEV] Re: PHP 8 Preview Releases

[Dmitry Stogov]

Hi Arvids,


It's possible to test JIT with PHP-7.4 building PHP from 
https://github.com/zendtech/php-src/tree/jit-dynasm-7.4

But this branch is not going to be supported anymore.


Thanks. Dmitry.


From: Arvids Godjuks 
Sent: Friday, March 29, 2019 5:17:41 PM
To: Joe Watkins
Cc: Dmitry Stogov; release-manag...@php.net; PHP internals
Subject: Re: [PHP-DEV] Re: PHP 8 Preview Releases

Hello,

I'd like to add that as the userland developer, it would be nice to be able to 
build JIT against an active branch (a.k.a PHP 7.4), cause if PHP 8 brings 
enough changes, it would not be realistic to fix our apps to be compatible with 
PHP 8 months or years away from actual release.

пт, 29 мар. 2019 г. в 15:58, Joe Watkins 
mailto:krak...@gmail.com>>:
Hi Dmitry,

I'm not suggesting we do it right now, I'm suggesting we look at the
planning of it right now as it deviates from our normal release cycle.

At the moment we should just consider how we want it to work, including
when it should start ...

Cheers
Joe

On Fri, 29 Mar 2019 at 14:42, Dmitry Stogov 
mailto:dmi...@zend.com>> wrote:

> Hi Joe,
>
>
> I think, PHP-8 preview is too early.
>
> We even didn't freeze PHP-7.4 yet, and PHP-8 didn't get any new major
> features (may be I forgot something) only deprecations and some internal
> improvements
>
> .
>
> According to JIT, it's probably going to be changed a lot in the nearest
> future.
>
>
> Thanks. Dmitry.
> --
> *From:* Joe Watkins mailto:krak...@php.net>>
> *Sent:* Friday, March 29, 2019 3:40:04 PM
> *To:* release-manag...@php.net; PHP 
> internals; Dmitry Stogov
> *Subject:* PHP 8 Preview Releases
>
> Morning internals,
>
> Since we now have a result for JIT and we know it will be included in PHP
> 8, I think it's time to visit the idea brought up in discussion to have
> preview releases of PHP 8.
>
> I'm interested in hearing what kind of schedules we think are going to be
> useful - it's tempting to say let's track PHP-7.4 releases, possibly with a
> bi-monthly interval, but I'm not sure if that may be too soon, or too slow,
> or too fast.
>
> Thoughts please (especially from Dmitry) ?
>
> Cheers
> Joe
>
>
>


--
Arvīds Godjuks

+371 26 851 664
arvids.godj...@gmail.com
Skype: psihius
Telegram: @psihius https://t.me/psihius

Re: [PHP-DEV] Re: PHP 8 Preview Releases

[Rowan Collins]

On Fri, 29 Mar 2019 at 14:18, Arvids Godjuks 
wrote:

> Hello,
>
> I'd like to add that as the userland developer, it would be nice to be able
> to build JIT against an active branch (a.k.a PHP 7.4), cause if PHP 8
> brings enough changes, it would not be realistic to fix our apps to be
> compatible with PHP 8 months or years away from actual release.
>


This was the purpose of the secondary vote on the RFC (
https://wiki.php.net/rfc/jit#proposed_voting_choices). The result was 18
Yes to 36 No, so JIT will be PHP 8 only.

I won't repeat the discussion here, see the original RFC thread for the
pros and cons, and why I suggested a "PHP 8 Preview" would be a better
target for people to test against.

Regards,
-- 
Rowan Collins
[IMSoP]

Re: [PHP-DEV] Re: PHP 8 Preview Releases

[Arvids Godjuks]

Hello,

I'd like to add that as the userland developer, it would be nice to be able
to build JIT against an active branch (a.k.a PHP 7.4), cause if PHP 8
brings enough changes, it would not be realistic to fix our apps to be
compatible with PHP 8 months or years away from actual release.

пт, 29 мар. 2019 г. в 15:58, Joe Watkins :

> Hi Dmitry,
>
> I'm not suggesting we do it right now, I'm suggesting we look at the
> planning of it right now as it deviates from our normal release cycle.
>
> At the moment we should just consider how we want it to work, including
> when it should start ...
>
> Cheers
> Joe
>
> On Fri, 29 Mar 2019 at 14:42, Dmitry Stogov  wrote:
>
> > Hi Joe,
> >
> >
> > I think, PHP-8 preview is too early.
> >
> > We even didn't freeze PHP-7.4 yet, and PHP-8 didn't get any new major
> > features (may be I forgot something) only deprecations and some internal
> > improvements
> >
> > .
> >
> > According to JIT, it's probably going to be changed a lot in the nearest
> > future.
> >
> >
> > Thanks. Dmitry.
> > --
> > *From:* Joe Watkins 
> > *Sent:* Friday, March 29, 2019 3:40:04 PM
> > *To:* release-manag...@php.net; PHP internals; Dmitry Stogov
> > *Subject:* PHP 8 Preview Releases
> >
> > Morning internals,
> >
> > Since we now have a result for JIT and we know it will be included in PHP
> > 8, I think it's time to visit the idea brought up in discussion to have
> > preview releases of PHP 8.
> >
> > I'm interested in hearing what kind of schedules we think are going to be
> > useful - it's tempting to say let's track PHP-7.4 releases, possibly
> with a
> > bi-monthly interval, but I'm not sure if that may be too soon, or too
> slow,
> > or too fast.
> >
> > Thoughts please (especially from Dmitry) ?
> >
> > Cheers
> > Joe
> >
> >
> >
>


-- 
Arvīds Godjuks

+371 26 851 664
arvids.godj...@gmail.com
Skype: psihius
Telegram: @psihius https://t.me/psihius

[PHP-DEV] Re: PHP 8 Preview Releases

[Joe Watkins]

Hi Dmitry,

I'm not suggesting we do it right now, I'm suggesting we look at the
planning of it right now as it deviates from our normal release cycle.

At the moment we should just consider how we want it to work, including
when it should start ...

Cheers
Joe

On Fri, 29 Mar 2019 at 14:42, Dmitry Stogov  wrote:

> Hi Joe,
>
>
> I think, PHP-8 preview is too early.
>
> We even didn't freeze PHP-7.4 yet, and PHP-8 didn't get any new major
> features (may be I forgot something) only deprecations and some internal
> improvements
>
> .
>
> According to JIT, it's probably going to be changed a lot in the nearest
> future.
>
>
> Thanks. Dmitry.
> --
> *From:* Joe Watkins 
> *Sent:* Friday, March 29, 2019 3:40:04 PM
> *To:* release-manag...@php.net; PHP internals; Dmitry Stogov
> *Subject:* PHP 8 Preview Releases
>
> Morning internals,
>
> Since we now have a result for JIT and we know it will be included in PHP
> 8, I think it's time to visit the idea brought up in discussion to have
> preview releases of PHP 8.
>
> I'm interested in hearing what kind of schedules we think are going to be
> useful - it's tempting to say let's track PHP-7.4 releases, possibly with a
> bi-monthly interval, but I'm not sure if that may be too soon, or too slow,
> or too fast.
>
> Thoughts please (especially from Dmitry) ?
>
> Cheers
> Joe
>
>
>

[PHP-DEV] Re: PHP 8 Preview Releases

[Dmitry Stogov]

Hi Joe,


I think, PHP-8 preview is too early.

We even didn't freeze PHP-7.4 yet, and PHP-8 didn't get any new major features 
(may be I forgot something) only deprecations and some internal improvements

.

According to JIT, it's probably going to be changed a lot in the nearest future.


Thanks. Dmitry.


From: Joe Watkins 
Sent: Friday, March 29, 2019 3:40:04 PM
To: release-manag...@php.net; PHP internals; Dmitry Stogov
Subject: PHP 8 Preview Releases

Morning internals,

Since we now have a result for JIT and we know it will be included in PHP 8, I 
think it's time to visit the idea brought up in discussion to have preview 
releases of PHP 8.

I'm interested in hearing what kind of schedules we think are going to be 
useful - it's tempting to say let's track PHP-7.4 releases, possibly with a 
bi-monthly interval, but I'm not sure if that may be too soon, or too slow, or 
too fast.

Thoughts please (especially from Dmitry) ?

Cheers
Joe

Re: [PHP-DEV] [RFC] Unbundle ext/interbase

[Dan Ackroyd]

On Mon, 25 Mar 2019 at 23:04, Stanislav Malyshev  wrote:
>
> In my opinion, deprecation warnings should be used for functionality
> that the used needs to remove from the code. That's not what we're doing
> here -

That's a good point.

Another thing that probably needs consideration is that if/when
someone from the Firebird community steps up to maintain the
extension, at some point it would probably be appropriate to fork the
extension to be named Firebird, rather than ibase, as it appears that
Interbase and Firebird have forked and are no longer fully compatible
with each other:

https://ib-aid.com/en/articles/differences-between-firebird-and-interbase/

> InterBase was created in 1985: it was the first commercial multi-versioning 
> database. In the end
> of 1999, Borland decided to close InterBase development and published its 
> source codes under
> InterBase Public License. This code was copied (it is permitted by the 
> license), and Firebird
> was born – from the version 1.0 Firebird is a production-ready database, 
> based on
> previous decades of InterBase development.
>
> 
>
> Since then, the difference between Firebird and InterBase became bigger.

It would be pretty reasonable for a maintainer from the Firebird
community to maintain the extension for Firebird compatibility, rather
than maintaining it to be Interbase compatible. But having it still be
named after Interbase would be quite confusing.

The exact details of that can be discussed after the vote, and when
someone applies to maintain it.

cheers
Dan
Ack

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

Re: [PHP-DEV] Firebird - Who are WE ...

[Lester Caine]

On 29/03/2019 12:05, Joe Watkins wrote:

No, it's broken in both modes.

In NTS mode, both the thread that handles events (which illegally calls 
user code) and the main thread are executing concurrently, they may both 
be calling functions that cause interaction with module globals, which 
are obviously shared between threads in NTS mode.


You cannot just start threads and execute user code from anywhere, it's 
not safe in NTS mode and is a horrible violation of share nothing in ZTS 
mode. It's much more likely to break ZTS mode than NTS, but illegal in both.


The main problem here is that Firebird events are not something one is 
likely to use when running a web service? Which is why simply disabling 
the events functions would be my own fix in the absence of anybody 
coming forward to say they ARE using them. Asynchronous access to third 
party services is an area that does require a much more cooperative code 
base? Simply asking for a query to run, going off to do other activity, 
and returning when the result is available is the sort of activity we 
are talking about here?


From the Firebird docs ...

The event notification is asynchronous and takes place at the end of the 
transaction in which the event was generated. A separate thread is created by 
TIBEvents to wait on the event notification. When the event occurs it calls the 
“OnEventAlert” event handler to report which event has been received. Note that 
the event handler is run in the context of the main thread and hence there is 
no need to worry about thread synchronisation.


So ibase_wait_event is sitting listening on the same connection that set 
the event handler and shares that connection which is where the current 
method of working comes from. But I have no idea if this can be changed. 
It is the firebird client which is actually holding the connection on 
which ibase_wait_event is listening. Using it depends very much on how 
PHP handles asynchronous events while I simply want to know that the 
read or write I've just done was successful or not ...


--
Lester Caine - G8HFL
-
Contact - https://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - https://lsces.co.uk
EnquirySolve - https://enquirysolve.com/
Model Engineers Digital Workshop - https://medw.co.uk
Rainbow Digital Media - https://rainbowdigitalmedia.co.uk

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

[PHP-DEV] PHP 8 Preview Releases

[Joe Watkins]

Morning internals,

Since we now have a result for JIT and we know it will be included in PHP
8, I think it's time to visit the idea brought up in discussion to have
preview releases of PHP 8.

I'm interested in hearing what kind of schedules we think are going to be
useful - it's tempting to say let's track PHP-7.4 releases, possibly with a
bi-monthly interval, but I'm not sure if that may be too soon, or too slow,
or too fast.

Thoughts please (especially from Dmitry) ?

Cheers
Joe

Re: [PHP-DEV] [RFC] [VOTE] [Result] JIT

[Peter Kokot]

On Fri, 29 Mar 2019 at 09:57, Dmitry Stogov  wrote:
>
> Hi @internals,
>
>
> The JIT RFC https://wiki.php.net/rfc/jit is accepted to be merged into PHP-8 
> only.
>
> I'm going to perform the actual merge on Monday morning and then start 
> working on deeper integration of JIT with VM.
>
>
> Thanks. Dmitry.

Great. No rush, we now have more than a year until Jit will be happening then :)

Otherwise, I'm really looking forward seeing this in action. Thank you
for the splendid work.

-- 
Peter Kokot

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

Re: [PHP-DEV] Firebird - Who are WE ...

[Joe Watkins]

No, it's broken in both modes.

In NTS mode, both the thread that handles events (which illegally calls
user code) and the main thread are executing concurrently, they may both be
calling functions that cause interaction with module globals, which are
obviously shared between threads in NTS mode.

You cannot just start threads and execute user code from anywhere, it's not
safe in NTS mode and is a horrible violation of share nothing in ZTS mode.
It's much more likely to break ZTS mode than NTS, but illegal in both.

Cheers
Joe

On Fri, 29 Mar 2019 at 12:22, Benjamin Eberlei  wrote:

>
>
> On Fri, Mar 29, 2019 at 10:59 AM Joe Watkins  wrote:
>
>> Specifically the events interface is broken all versions of PHP 7:
>>
>>   - In a non-zts build, it executes user code allocated in Thread A in
>> Thread B - that's not allowed.
>>   - In a zts build, it makes the same mistake as above, and uses a TSRM
>> API to set context which itself has been broken since PHP 7.0.
>>
>> It so happens that PHP 8 has broken the build, but specifically that part
>> of the extension has been broken since PHP 7.0.
>>
>
> But I am correct to understand the code still compiles and works in NTS
> mode, so its not completely broken, only on ZTS.
>
>>
>> Cheers
>> Joe
>>
>>
>>
>> On Fri, 29 Mar 2019 at 10:40, Christoph M. Becker 
>> wrote:
>>
>>> On 29.03.2019 at 10:29, Benjamin Eberlei wrote:
>>>
>>> > On Fri, Mar 29, 2019 at 10:20 AM Lester Caine 
>>> wrote:
>>> >
>>> >> Currently building 'interbase' extension has been turned off because
>>> >> it's failing to pass the changes in master for thread safe operation.
>>> I
>>> >> understand that it needs someone to work on it and I would love to be
>>> >> able to do that but it's development requirements have moved outside
>>> the
>>> >> area that I can cope with. And many people reliant on it are in the
>>> same
>>> >> boat, just as they would not be able to contribute to writing code for
>>> >> Firebird itself. While not perfect, what we have currently does it's
>>> job
>>> >> just as PHP5.2 still works on legacy hosting. PDO hopefully will
>>> remain
>>> >> available, but re-writing 20 years worth of code base for that
>>> different
>>> >> way of working has the same problem as finding resources to update the
>>> >> interbase extension.
>>> >
>>> > PHP needs to support thread safety in all its extensions, but that
>>> doesn't
>>> > mean its required for PECL extensions. You probably run PHP in NTS
>>> mode,
>>> > and if the interbase extension supports that, no need to add thread
>>> safety
>>> > support while in PECL. The problem is that every extension in php-src
>>> MUST
>>> > support it, because php supports it.
>>> >
>>> > To me it feels you are blowing this issue way out of proportion. Please
>>> > believe everyone trying to tell you over and over again that you have
>>> > nothing to fear from this unbundling.
>>>
>>> ext/interbase is indeed broken (i.e. uncompilable) in master (not PHP
>>> 7.4 though), since PR #3976[1] has been merged.  It will certainly be
>>> fixed, if the “Unbundle ext/interbase” RFC[2] will be declined; if it
>>> will be accepted it might never get fixed.
>>>
>>> [1] 
>>> [2] 
>>>
>>> --
>>> Christoph M. Becker
>>>
>>> --
>>> PHP Internals - PHP Runtime Development Mailing List
>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>
>>>

Re: [PHP-DEV] Firebird - Who are WE ...

[Benjamin Eberlei]

On Fri, Mar 29, 2019 at 10:59 AM Joe Watkins  wrote:

> Specifically the events interface is broken all versions of PHP 7:
>
>   - In a non-zts build, it executes user code allocated in Thread A in
> Thread B - that's not allowed.
>   - In a zts build, it makes the same mistake as above, and uses a TSRM
> API to set context which itself has been broken since PHP 7.0.
>
> It so happens that PHP 8 has broken the build, but specifically that part
> of the extension has been broken since PHP 7.0.
>

But I am correct to understand the code still compiles and works in NTS
mode, so its not completely broken, only on ZTS.

>
> Cheers
> Joe
>
>
>
> On Fri, 29 Mar 2019 at 10:40, Christoph M. Becker 
> wrote:
>
>> On 29.03.2019 at 10:29, Benjamin Eberlei wrote:
>>
>> > On Fri, Mar 29, 2019 at 10:20 AM Lester Caine 
>> wrote:
>> >
>> >> Currently building 'interbase' extension has been turned off because
>> >> it's failing to pass the changes in master for thread safe operation. I
>> >> understand that it needs someone to work on it and I would love to be
>> >> able to do that but it's development requirements have moved outside
>> the
>> >> area that I can cope with. And many people reliant on it are in the
>> same
>> >> boat, just as they would not be able to contribute to writing code for
>> >> Firebird itself. While not perfect, what we have currently does it's
>> job
>> >> just as PHP5.2 still works on legacy hosting. PDO hopefully will remain
>> >> available, but re-writing 20 years worth of code base for that
>> different
>> >> way of working has the same problem as finding resources to update the
>> >> interbase extension.
>> >
>> > PHP needs to support thread safety in all its extensions, but that
>> doesn't
>> > mean its required for PECL extensions. You probably run PHP in NTS mode,
>> > and if the interbase extension supports that, no need to add thread
>> safety
>> > support while in PECL. The problem is that every extension in php-src
>> MUST
>> > support it, because php supports it.
>> >
>> > To me it feels you are blowing this issue way out of proportion. Please
>> > believe everyone trying to tell you over and over again that you have
>> > nothing to fear from this unbundling.
>>
>> ext/interbase is indeed broken (i.e. uncompilable) in master (not PHP
>> 7.4 though), since PR #3976[1] has been merged.  It will certainly be
>> fixed, if the “Unbundle ext/interbase” RFC[2] will be declined; if it
>> will be accepted it might never get fixed.
>>
>> [1] 
>> [2] 
>>
>> --
>> Christoph M. Becker
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>

Re: [PHP-DEV] Firebird - Who are WE ...

[Joe Watkins]

Specifically the events interface is broken all versions of PHP 7:

  - In a non-zts build, it executes user code allocated in Thread A in
Thread B - that's not allowed.
  - In a zts build, it makes the same mistake as above, and uses a TSRM API
to set context which itself has been broken since PHP 7.0.

It so happens that PHP 8 has broken the build, but specifically that part
of the extension has been broken since PHP 7.0.

Cheers
Joe



On Fri, 29 Mar 2019 at 10:40, Christoph M. Becker  wrote:

> On 29.03.2019 at 10:29, Benjamin Eberlei wrote:
>
> > On Fri, Mar 29, 2019 at 10:20 AM Lester Caine 
> wrote:
> >
> >> Currently building 'interbase' extension has been turned off because
> >> it's failing to pass the changes in master for thread safe operation. I
> >> understand that it needs someone to work on it and I would love to be
> >> able to do that but it's development requirements have moved outside the
> >> area that I can cope with. And many people reliant on it are in the same
> >> boat, just as they would not be able to contribute to writing code for
> >> Firebird itself. While not perfect, what we have currently does it's job
> >> just as PHP5.2 still works on legacy hosting. PDO hopefully will remain
> >> available, but re-writing 20 years worth of code base for that different
> >> way of working has the same problem as finding resources to update the
> >> interbase extension.
> >
> > PHP needs to support thread safety in all its extensions, but that
> doesn't
> > mean its required for PECL extensions. You probably run PHP in NTS mode,
> > and if the interbase extension supports that, no need to add thread
> safety
> > support while in PECL. The problem is that every extension in php-src
> MUST
> > support it, because php supports it.
> >
> > To me it feels you are blowing this issue way out of proportion. Please
> > believe everyone trying to tell you over and over again that you have
> > nothing to fear from this unbundling.
>
> ext/interbase is indeed broken (i.e. uncompilable) in master (not PHP
> 7.4 though), since PR #3976[1] has been merged.  It will certainly be
> fixed, if the “Unbundle ext/interbase” RFC[2] will be declined; if it
> will be accepted it might never get fixed.
>
> [1] 
> [2] 
>
> --
> Christoph M. Becker
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Firebird - Who are WE ...

[Christoph M. Becker]

On 29.03.2019 at 10:29, Benjamin Eberlei wrote:

> On Fri, Mar 29, 2019 at 10:20 AM Lester Caine  wrote:
>
>> Currently building 'interbase' extension has been turned off because
>> it's failing to pass the changes in master for thread safe operation. I
>> understand that it needs someone to work on it and I would love to be
>> able to do that but it's development requirements have moved outside the
>> area that I can cope with. And many people reliant on it are in the same
>> boat, just as they would not be able to contribute to writing code for
>> Firebird itself. While not perfect, what we have currently does it's job
>> just as PHP5.2 still works on legacy hosting. PDO hopefully will remain
>> available, but re-writing 20 years worth of code base for that different
>> way of working has the same problem as finding resources to update the
>> interbase extension.
>
> PHP needs to support thread safety in all its extensions, but that doesn't
> mean its required for PECL extensions. You probably run PHP in NTS mode,
> and if the interbase extension supports that, no need to add thread safety
> support while in PECL. The problem is that every extension in php-src MUST
> support it, because php supports it.
>
> To me it feels you are blowing this issue way out of proportion. Please
> believe everyone trying to tell you over and over again that you have
> nothing to fear from this unbundling.

ext/interbase is indeed broken (i.e. uncompilable) in master (not PHP
7.4 though), since PR #3976[1] has been merged.  It will certainly be
fixed, if the “Unbundle ext/interbase” RFC[2] will be declined; if it
will be accepted it might never get fixed.

[1] 
[2] 

--
Christoph M. Becker

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

Re: [PHP-DEV] Firebird - Who are WE ...

[Benjamin Eberlei]

On Fri, Mar 29, 2019 at 10:20 AM Lester Caine  wrote:

> On 29/03/2019 08:50, Benjamin Eberlei wrote:
> > So it looks like I'm going to be stuck on PHP7.3 from now on ...
> >
> >
> > I think you misunderstand what is happening here.
> >
> > Many extensions are "just" in PECL and are still maintained there and
> > kept updated for newer versions. Distribution maintainers like Remi
> > package all the PECL extensions for every PHP version. Firebird support
> > will surely be updated to work with 7.4 and released by distributions.
> > It will *just* not be in php-src anymore.
>
> Currently building 'interbase' extension has been turned off because
> it's failing to pass the changes in master for thread safe operation. I
> understand that it needs someone to work on it and I would love to be
> able to do that but it's development requirements have moved outside the
> area that I can cope with. And many people reliant on it are in the same
> boat, just as they would not be able to contribute to writing code for
> Firebird itself. While not perfect, what we have currently does it's job
> just as PHP5.2 still works on legacy hosting. PDO hopefully will remain
> available, but re-writing 20 years worth of code base for that different
> way of working has the same problem as finding resources to update the
> interbase extension.
>

PHP needs to support thread safety in all its extensions, but that doesn't
mean its required for PECL extensions. You probably run PHP in NTS mode,
and if the interbase extension supports that, no need to add thread safety
support while in PECL. The problem is that every extension in php-src MUST
support it, because php supports it.

To me it feels you are blowing this issue way out of proportion. Please
believe everyone trying to tell you over and over again that you have
nothing to fear from this unbundling.


> --
> Lester Caine - G8HFL
> -
> Contact - https://lsces.co.uk/wiki/?page=contact
> L.S.Caine Electronic Services - https://lsces.co.uk
> EnquirySolve - https://enquirysolve.com/
> Model Engineers Digital Workshop - https://medw.co.uk
> Rainbow Digital Media - https://rainbowdigitalmedia.co.uk
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Firebird - Who are WE ...

[Lester Caine]

On 29/03/2019 08:50, Benjamin Eberlei wrote:

So it looks like I'm going to be stuck on PHP7.3 from now on ...


I think you misunderstand what is happening here.

Many extensions are "just" in PECL and are still maintained there and 
kept updated for newer versions. Distribution maintainers like Remi 
package all the PECL extensions for every PHP version. Firebird support 
will surely be updated to work with 7.4 and released by distributions. 
It will *just* not be in php-src anymore.


Currently building 'interbase' extension has been turned off because 
it's failing to pass the changes in master for thread safe operation. I 
understand that it needs someone to work on it and I would love to be 
able to do that but it's development requirements have moved outside the 
area that I can cope with. And many people reliant on it are in the same 
boat, just as they would not be able to contribute to writing code for 
Firebird itself. While not perfect, what we have currently does it's job 
just as PHP5.2 still works on legacy hosting. PDO hopefully will remain 
available, but re-writing 20 years worth of code base for that different 
way of working has the same problem as finding resources to update the 
interbase extension.


--
Lester Caine - G8HFL
-
Contact - https://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - https://lsces.co.uk
EnquirySolve - https://enquirysolve.com/
Model Engineers Digital Workshop - https://medw.co.uk
Rainbow Digital Media - https://rainbowdigitalmedia.co.uk

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

Re: [PHP-DEV] [RFC] [VOTE] [Result] JIT

[Sebastian Bergmann]

Am 29.03.2019 um 10:01 schrieb Joe Watkins:

Thanks for all your hard work on this, thanks also to Anatol for making
Windows and ZTS happen.


Hear, hear.

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

Re: [PHP-DEV] [RFC] [VOTE] [Result] JIT

[Joe Watkins]

Morning Dmitry,

Thanks for all your hard work on this, thanks also to Anatol for making
Windows and ZTS happen.

Thank you in advance for all the work to come :)

PHP 8 is going to be quite special, I think, I look forward to it ..

Cheers
Joe

On Fri, 29 Mar 2019 at 09:58, Dmitry Stogov  wrote:

> Hi @internals,
>
>
> The JIT RFC https://wiki.php.net/rfc/jit is accepted to be merged into
> PHP-8 only.
>
> I'm going to perform the actual merge on Monday morning and then start
> working on deeper integration of JIT with VM.
>
>
> Thanks. Dmitry.
>

[PHP-DEV] [RFC] [VOTE] [Result] JIT

[Dmitry Stogov]

Hi @internals,


The JIT RFC https://wiki.php.net/rfc/jit is accepted to be merged into PHP-8 
only.

I'm going to perform the actual merge on Monday morning and then start working 
on deeper integration of JIT with VM.


Thanks. Dmitry.

Re: [PHP-DEV] Firebird - Who are WE ...

[Benjamin Eberlei]

On Fri, Mar 29, 2019 at 9:41 AM Lester Caine  wrote:

> On 29/03/2019 06:05, Stanislav Malyshev wrote:
> >> News to me is
> >> https://firebirdsql.org/en/news/revival-of-php-driver-development/, but
> >> then many Firebird user groups do not have English as a first language
> >> and just get on with things locally.
> > Well, this sounds good, but are these people going to develop it outside
> > PHP project? Or are they going to maintain the existing extension? So
> > far, it's not clear to me.
>
> As I said 'News to me' ... they certainly have not made any contact on
> the Firebird php list or responded to any requests to help :( I'm not
> totally surprised though as other firebird user groups don't engage
> directly with the 'English' groups.
>
> So it looks like I'm going to be stuck on PHP7.3 from now on ...
>

I think you misunderstand what is happening here.

Many extensions are "just" in PECL and are still maintained there and kept
updated for newer versions. Distribution maintainers like Remi package all
the PECL extensions for every PHP version. Firebird support will surely be
updated to work with 7.4 and released by distributions. It will *just* not
be in php-src anymore.

For example, extensions that are not in php-src and are still widely
available in distributions

Memcache
Memcached
APCu
Imagick
Redis

Also Microsoft maintains all its drivres outside of the php-src tree.


> --
> Lester Caine - G8HFL
> -
> Contact - https://lsces.co.uk/wiki/?page=contact
> L.S.Caine Electronic Services - https://lsces.co.uk
> EnquirySolve - https://enquirysolve.com/
> Model Engineers Digital Workshop - https://medw.co.uk
> Rainbow Digital Media - https://rainbowdigitalmedia.co.uk
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Firebird - Who are WE ...

[Lester Caine]

On 29/03/2019 06:05, Stanislav Malyshev wrote:

News to me is
https://firebirdsql.org/en/news/revival-of-php-driver-development/, but
then many Firebird user groups do not have English as a first language
and just get on with things locally.

Well, this sounds good, but are these people going to develop it outside
PHP project? Or are they going to maintain the existing extension? So
far, it's not clear to me.


As I said 'News to me' ... they certainly have not made any contact on 
the Firebird php list or responded to any requests to help :( I'm not 
totally surprised though as other firebird user groups don't engage 
directly with the 'English' groups.


So it looks like I'm going to be stuck on PHP7.3 from now on ...

--
Lester Caine - G8HFL
-
Contact - https://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - https://lsces.co.uk
EnquirySolve - https://enquirysolve.com/
Model Engineers Digital Workshop - https://medw.co.uk
Rainbow Digital Media - https://rainbowdigitalmedia.co.uk

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

Re: [PHP-DEV] Updating bundled libs (specifially, oniguruma) on 7.1/7.2

[Remi Collet]

Le 28/03/2019 à 22:50, Stanislav Malyshev a écrit :
> Hi!
> 
> I wonder if there's any reason not to update bundled oniguruma library
> for 7.1/7.2. 7.1 one is ancient, 7.2 one is more recent but still
> behind. There are numerous fixes, I am sure, and one functionality
> improvement that allows to implement proper stack depth limiting
> (https://github.com/php/php-src/pull/3997). Which also makes it kinda
> security-relevant, which is why I am considering 7.1 too. The risk of
> course is that there's some kind of BC break, but I haven't heard about
> something like that. Did anybody?
> Another risk is that newer library requires some new code to handle some
> of the new options, and if we plug it into old code it may expose new
> bugs (e.g. if you use some regex feature but our code can't handle it).
> Quick scan through the release notes does not show anything like that,
> but in theory it's possible.
> 
> Anybody has any thoughts on this?


7.1 have version 5.9.6
7.2 have version 6.3.0
7.3 have version 6.9.0 (latest is 6.9.1)
7.4 only use system library

As we encourage system library usage (default in 7.4), and if this raise
the minimal allowed version, this will create issue for 7.4

Ex
RHEL have 5.9
Debian have 6.1

I think we have to manage such change in a compatible way.
(feature availability tested in configure)

So, I don't think the bundled library (especially in 7.1) should be updated.

Remi


P.S. from downstream PoV, as soname is different is it possible to have
compat package for library (v5.9 uses 2, v6.1 uses 4, v6.9 uses 5)



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] Firebird - Who are WE ...

[Stanislav Malyshev]

Hi!

> News to me is
> https://firebirdsql.org/en/news/revival-of-php-driver-development/, but
> then many Firebird user groups do not have English as a first language
> and just get on with things locally.

Well, this sounds good, but are these people going to develop it outside
PHP project? Or are they going to maintain the existing extension? So
far, it's not clear to me.

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

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