Re: [PHP-DEV] Refactor

[Kalle Sommer Nielsen]

Hi

Den søn. 6. jun. 2021 kl. 18.39 skrev Mail :
>
> As I was browsing through php source Ive noticed EVERY file has comments 
> related to this shitty zend framework.
>
> Make php pure pleasure. Currently its fucking PAIN.

Thank you very much for your interest in PHP, it's always great to
hear from our many great developers!

To answer your question; I too have been feeling the same regarding
our backend. I had a discussion with some our other Core Developers
and we have decided that coming PHP 8.1.0, we will be switching to
using Laminas. I hope this will be to your satisfactory! Thanks again
for the feedback and for helping us make PHP even greater.

-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

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

[PHP-DEV] Refactor

[Mail]

As I was browsing through php source Ive noticed EVERY file has comments 
related to this shitty zend framework.

Make php pure pleasure. Currently its fucking PAIN.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Propagating AVIF support from libgd into PHP's bundled gd

[Mark Randall]

On 06/06/2021 14:00, Ben Morss via internals wrote:

Thank you for these comments!

Perhaps it would make sense to, at some point, create a followup proposal
to namespace the entire gd extension - so that all gd functions would be in
the namespace? I'd leave it to others to determine whether this would be
desirable, or whether it wouldn't be worth making developers update
existing code.


When we de-resourcified Gd we considered making the Gd class be useful 
as something more than an storage type.


If doing a full remap it may be worth putting the functions into the 
class itself.


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

[PHP-DEV] PHP 8.1 and PECL ext builds for Windows

[Christoph M. Becker]

Hi all,

on Tuesday, PHP 8.1.0alpha1 is supposed to be tagged, and since I don't
have the capacity to do these builds manually (as currently done with
the PHP 8.0 builds), I've set up an automation which does the builds on
GH action runners[1].  This should likely be integrated into php-src or
php-sdk, whereyby the latter needs to be forked into a php organization
repo as soon as possible, since there is a pending commit regarding the
exclusion of yet unsupported PGO training scenarios, and we also should
roll a new SDK release, and update some of the bundled tools.

Anyhow, if these PHP 8.1 builds turn out to be good, I'd also like to do
the PHP 8.0 builds this way; this would free required capacities on the
current build machine (plus save a bit of my time), which is actually
supposed to do the PECL extension builds.  While these builds are
automated, and mostly work well, there are sometimes issues with new
releases and the dependency libraries are rarely updated (a lot of
these[2] are ancient versions).  And although I'm planning to enable
snapshot builds when PHP 8.1 enters the beta release cycle (as usual),
and to do the mass rebuild after PHP 8.1.0 is released, I won't be able
to spend much time to help with resolving issues.  In my opinion, it
would be beneficial to push the burden of providing Windows builds to
the extension maintainers.  There are already AppVeyor integrations for
several PECL extensions, some of them producing binaries which are
basically identical to the PECL builds, and generally Windows CI should
be helpful for package maintainers to detect potential issues before new
releases.  Furthermore, extensions maintainers would be more flexible
regarding the supported PHP version (currently, the PECL builds are done
for PHP 7.3, 7.4 and 8.0 only).

So yes, I'm proposing to stop centralized builds of PECL extensions for
Windows in the long run, and also to stop providing prebuilt dependency
libraries for PECL extensions.  If we do that, we can also sunset the
rmtools[3], which are used to provide snapshot builds of php-src (no
longer the case for PHP 8.0 due to lack of a dedicated build machine;
nightly snapshots are made available by Shivam[4]), and to provide
builds of the PECL extensions.

Thoughts?

[1] 
[2] 
[3] 
[4] 

--
Christoph M. Becker

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

Re: [PHP-DEV] Propagating AVIF support from libgd into PHP's bundled gd

[Ben Morss via internals]

Thank you for these comments!

Perhaps it would make sense to, at some point, create a followup proposal
to namespace the entire gd extension - so that all gd functions would be in
the namespace? I'd leave it to others to determine whether this would be
desirable, or whether it wouldn't be worth making developers update
existing code.

On Sun, Jun 6, 2021 at 6:08 AM Ayesh Karunaratne  wrote:

> >
> > Den søn. 6. jun. 2021 kl. 00.09 skrev Ayesh Karunaratne  >:
> > >
> > > Hi Ben,
> > > Thank you for opening this PR and the discussion. With the wide
> > > availability of AVIF/AV1 support in browsers, I think this will fit
> > > nicely.
> > >
> > > We have the Namespaces in Bundled Extensions RFC
> > > (https://wiki.php.net/rfc/namespaces_in_bundled_extensions) passed, so
> > > perhaps, the new functions are probably better in the `Gd` namespace?
> > > This would mean the new functions would be `\Gd\imagecreatefromavif`
> > > and `\Gd\imageavif`. They are inconsistent with the existing functions
> > > of course, but I thought to mention it because it's a recent proposal
> > > and I don't think we added new functions after that RFC. Some examples
> > > are recently renamed PHP classes in IMAP, Pgsql, LDAP, and FTP
> > > extensions to follow this new proposal.
> >
> > I don't think it makes much sense to do that for a single function,
> > because it makes the API cluttered, as why would I call
> > `\Gd\imagecreatefromavif` when everything else is in the global
> > namespace? That is a poor design, while I understand the intentions
> > behind it is good.
> >
> > I think this needs to be well thoughtout in a topic on its own rather
> > than off topicing it here, so I will leave it at that.
> >
> >
> > Overall, +1 for adding this
> > --
> > regards,
> >
> > Kalle Sommer Nielsen
> > ka...@php.net
>
> I also think going with `imagecreatefromavif`/`imageavif` is good for
> consistency. I brought that RFC up because it was recent and this is
> the first new function we are adding.
>
> Thank you.
>

Re: [PHP-DEV] Propagating AVIF support from libgd into PHP's bundled gd

[Ayesh Karunaratne]

>
> Den søn. 6. jun. 2021 kl. 00.09 skrev Ayesh Karunaratne :
> >
> > Hi Ben,
> > Thank you for opening this PR and the discussion. With the wide
> > availability of AVIF/AV1 support in browsers, I think this will fit
> > nicely.
> >
> > We have the Namespaces in Bundled Extensions RFC
> > (https://wiki.php.net/rfc/namespaces_in_bundled_extensions) passed, so
> > perhaps, the new functions are probably better in the `Gd` namespace?
> > This would mean the new functions would be `\Gd\imagecreatefromavif`
> > and `\Gd\imageavif`. They are inconsistent with the existing functions
> > of course, but I thought to mention it because it's a recent proposal
> > and I don't think we added new functions after that RFC. Some examples
> > are recently renamed PHP classes in IMAP, Pgsql, LDAP, and FTP
> > extensions to follow this new proposal.
>
> I don't think it makes much sense to do that for a single function,
> because it makes the API cluttered, as why would I call
> `\Gd\imagecreatefromavif` when everything else is in the global
> namespace? That is a poor design, while I understand the intentions
> behind it is good.
>
> I think this needs to be well thoughtout in a topic on its own rather
> than off topicing it here, so I will leave it at that.
>
>
> Overall, +1 for adding this
> --
> regards,
>
> Kalle Sommer Nielsen
> ka...@php.net

I also think going with `imagecreatefromavif`/`imageavif` is good for
consistency. I brought that RFC up because it was recent and this is
the first new function we are adding.

Thank you.

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