[PHP-DEV] Re: Allow default parameters before non-default ones?

[Mark Randall]

On 09/12/2021 05:22, André Hänsel wrote:

This is very useful because I can add an optional parameter to a function
and prevent users of my function from using the parameter in a positional
way. This way I don't have to make a compatibility promise to never change
the position of this parameter.



I would much prefer we could find a way to give this proper support 
rather than a hack.


I frequently use large numbers of named arguments and would very much 
like to be able to knock out the ability to use positional arguments, 
thus ensuring I can change the order (e.g. inserting a new argument 
after a related one) without a BC break.



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

[PHP-DEV] Allow default parameters before non-default ones?

[André Hänsel]

PHP 8 has named parameters in function calls, Kotlin has named parameters in
function calls.

Kotlin has this handy feature that you can put parameters with defaults
before normal ones. Those parameters can then only be used by naming them.
See also: https://kotlinlang.org/docs/functions.html#default-arguments

This is very useful because I can add an optional parameter to a function
and prevent users of my function from using the parameter in a positional
way. This way I don't have to make a compatibility promise to never change
the position of this parameter.

If I try the same thing in PHP 8.0 I get a Deprecated warning and if I try
it in PHP 8.1 I get something that I don't understand:
https://3v4l.org/cg4DA

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

Re: [PHP-DEV] Why do PHP 8.1 extensions need PHP headers during make install (worked in <8.1)?

[David Zuelke via internals]

Yes, of course; it happens with any extension, because the Makefile
generated by 8.1's 'phpize' now lists those header dependencies even
for 'make install'.

Like I described, you can reproduce this by 'make'ing the extension,
then moving the PHP you used to build the extension, then running
'make install' (sample with your ext, on my build environment for
Heroku's PHP support):

root@8f6813d6dc88:/app# export PATH=/app/.heroku/php/bin:$PATH
root@8f6813d6dc88:/app# which php
/app/.heroku/php/bin/php
root@8f6813d6dc88:/app# php -v
PHP 8.1.0 (cli) (built: Dec  8 2021 20:43:30) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.1.0, Copyright (c) Zend Technologies
with Zend OPcache v8.1.0, Copyright (c), by Zend Technologies

root@8f6813d6dc88:/app# mkdir /tmp/build-ext-cairo
root@8f6813d6dc88:/app# cd /tmp/build-ext-cairo/
root@8f6813d6dc88:/tmp/build-ext-cairo# git clone
https://github.com/gtkphp/php-ext-cairo-src
Cloning into 'php-ext-cairo-src'...
…

root@8f6813d6dc88:/tmp/build-ext-cairo# cd php-ext-cairo-src/
root@8f6813d6dc88:/tmp/build-ext-cairo/php-ext-cairo-src# git checkout
origin/PHP-8.0
Note: checking out 'origin/PHP-8.0'.

You are in 'detached HEAD' state. You can look around, make experimental
…

HEAD is now at 2cd2ce9 Fix test( compatibility PHP-8)

root@8f6813d6dc88:/tmp/build-ext-cairo/php-ext-cairo-src# phpize
Configuring for:
PHP Api Version: 20210902
Zend Module Api No:  20210902
Zend Extension Api No:   420210902

root@8f6813d6dc88:/tmp/build-ext-cairo/php-ext-cairo-src# ./configure
--prefix=/app/.heroku/php
…

root@8f6813d6dc88:/tmp/build-ext-cairo/php-ext-cairo-src# make -j9
…
Build complete.
Don't forget to run 'make test'.

root@8f6813d6dc88:/tmp/build-ext-cairo/php-ext-cairo-src# mv
/app/.heroku/php{,_}

root@8f6813d6dc88:/tmp/build-ext-cairo/php-ext-cairo-src# make install
make: *** No rule to make target
'/app/.heroku/php/include/php/main/php.h', needed by 'cairo.lo'.
Stop.


On Thu, Dec 9, 2021 at 2:30 AM Glash Gnome  wrote:
>
> Thanks, I'll check it out.
>
> I'm confused. Can you tell me if you have this problem with this extension 
> (PHP8 / 7/5>):
> https://github.com/gtkphp/php-ext-cairo-src checkout PHP-8.0
>
> At the moment I need to check some dependency to try your extension.
> I'll keep you informed.
>
> Best Regards
>
> Le jeu. 9 déc. 2021 à 01:20, David Zuelke  a écrit :
>>
>> That's... sort of... irrelevant for this question; the problem appears
>> before that step. You could make a tarball of the built extension,
>> create a .deb archive, whatever; the point is that it should be
>> installable standalone (think e.g. 'apt-get install php81-imagick').
>>
>>
>>
>> On Thu, Dec 9, 2021 at 12:33 AM Glash Gnome  wrote:
>> >
>> > Hello,
>> >
>> > Can you tell me what the program is in step 7)
>> >
>> > > package up
>> >
>> > Thanks you,
>> >
>> >
>> > Le mer. 8 déc. 2021 à 16:25, David Zuelke via internals 
>> >  a écrit :
>> >>
>> >> Hi all,
>> >>
>> >> When building shared extensions for PHP for the purpose of packaging
>> >> and distributing the builds, the build environment obviously needs PHP
>> >> installed in the destination directory structure (for headers, phpize,
>> >> and so forth).
>> >>
>> >> But the resulting archive of the built extension should only contain
>> >> the shared object, and possibly the headers.
>> >>
>> >> A common pattern to do achieve is:
>> >>
>> >> 1) download/extract PHP to $installdir
>> >> 2) download/extract extension to $builddir
>> >> 3) phpize in $builddir
>> >> 4) make in $builddir
>> >> 5) rm -rf $installdir
>> >> 6) make install
>> >> 7) package up $installdir
>> >>
>> >> Step 6 installs the extension into $installdir - you end up with
>> >> /foo/bar/lib/php/extensions/no-debug-non-zts-20210902/something.so
>> >>
>> >> That doesn't work with PHP 8.1 anymore - the Makefile generated by
>> >> phpize now contains an include directive at the top level (near the
>> >> bottom), e.g.:
>> >>
>> >> -include src/php_raphf_api.dep
>> >>
>> >> Which lists not only the extension's headers, but also all of PHP's
>> >> (in include/main, include/Zend, and so forth):
>> >>
>> >> src/php_raphf_api.lo: /tmp/bob-2eBC7e/raphf-2.0.1/src/php_raphf_api.c \
>> >>  config.h /app/.heroku/php/include/php/main/php.h \
>> >>  /app/.heroku/php/include/php/main/php_version.h \
>> >>  /app/.heroku/php/include/php/Zend/zend_stream.h \
>> >>  /app/.heroku/php/include/php/main/streams/php_stream_context.h \
>> >> … (many more from main/ and Zend/ here)
>> >>  /app/.heroku/php/include/php/ext/standard/info.h php_raphf.h \
>> >>  php_raphf_api.h php_raphf.h
>> >>
>> >> This results in the 'make install' failing if, like in our step 5
>> >> above, PHP itself has been (re-)moved since the 'make' (output that
>> >> follows is from a 'make -d install'):
>> >>
>> >>   Considering target file 'src/php_raphf_api.lo'.
>> >> …
>> >> Considering target file '/app/.heroku/php/include/php/main/php.h'.
>> >>  File 

Re: [PHP-DEV] Why do PHP 8.1 extensions need PHP headers during make install (worked in <8.1)?

[Glash Gnome]

Thanks, I'll check it out.

I'm confused. Can you tell me if you have this problem with this extension
(PHP8 / 7/5>):
https://github.com/gtkphp/php-ext-cairo-src checkout PHP-8.0

At the moment I need to check some dependency to try your extension.
I'll keep you informed.

Best Regards

Le jeu. 9 déc. 2021 à 01:20, David Zuelke  a écrit :

> That's... sort of... irrelevant for this question; the problem appears
> before that step. You could make a tarball of the built extension,
> create a .deb archive, whatever; the point is that it should be
> installable standalone (think e.g. 'apt-get install php81-imagick').
>
>
>
> On Thu, Dec 9, 2021 at 12:33 AM Glash Gnome  wrote:
> >
> > Hello,
> >
> > Can you tell me what the program is in step 7)
> >
> > > package up
> >
> > Thanks you,
> >
> >
> > Le mer. 8 déc. 2021 à 16:25, David Zuelke via internals <
> internals@lists.php.net> a écrit :
> >>
> >> Hi all,
> >>
> >> When building shared extensions for PHP for the purpose of packaging
> >> and distributing the builds, the build environment obviously needs PHP
> >> installed in the destination directory structure (for headers, phpize,
> >> and so forth).
> >>
> >> But the resulting archive of the built extension should only contain
> >> the shared object, and possibly the headers.
> >>
> >> A common pattern to do achieve is:
> >>
> >> 1) download/extract PHP to $installdir
> >> 2) download/extract extension to $builddir
> >> 3) phpize in $builddir
> >> 4) make in $builddir
> >> 5) rm -rf $installdir
> >> 6) make install
> >> 7) package up $installdir
> >>
> >> Step 6 installs the extension into $installdir - you end up with
> >> /foo/bar/lib/php/extensions/no-debug-non-zts-20210902/something.so
> >>
> >> That doesn't work with PHP 8.1 anymore - the Makefile generated by
> >> phpize now contains an include directive at the top level (near the
> >> bottom), e.g.:
> >>
> >> -include src/php_raphf_api.dep
> >>
> >> Which lists not only the extension's headers, but also all of PHP's
> >> (in include/main, include/Zend, and so forth):
> >>
> >> src/php_raphf_api.lo: /tmp/bob-2eBC7e/raphf-2.0.1/src/php_raphf_api.c \
> >>  config.h /app/.heroku/php/include/php/main/php.h \
> >>  /app/.heroku/php/include/php/main/php_version.h \
> >>  /app/.heroku/php/include/php/Zend/zend_stream.h \
> >>  /app/.heroku/php/include/php/main/streams/php_stream_context.h \
> >> … (many more from main/ and Zend/ here)
> >>  /app/.heroku/php/include/php/ext/standard/info.h php_raphf.h \
> >>  php_raphf_api.h php_raphf.h
> >>
> >> This results in the 'make install' failing if, like in our step 5
> >> above, PHP itself has been (re-)moved since the 'make' (output that
> >> follows is from a 'make -d install'):
> >>
> >>   Considering target file 'src/php_raphf_api.lo'.
> >> …
> >> Considering target file
> '/app/.heroku/php/include/php/main/php.h'.
> >>  File '/app/.heroku/php/include/php/main/php.h' does not exist.
> >>  Looking for an implicit rule for
> >> '/app/.heroku/php/include/php/main/php.h'.
> >>  Trying pattern rule with stem 'php'.
> >>  Trying implicit prerequisite
> >>
> '/app/.heroku/php/include/php/main//tmp/bob-1830jl/raphf-2.0.1/src/php.h'.
> >>  Trying pattern rule with stem 'php.h'.
> >>  Trying implicit prerequisite
> >> '/app/.heroku/php/include/php/main/php.h,v'.
> >>  Trying pattern rule with stem 'php.h'.
> >>  Trying implicit prerequisite
> >> '/app/.heroku/php/include/php/main/RCS/php.h,v'.
> >>  Trying pattern rule with stem 'php.h'.
> >>  Trying implicit prerequisite
> >> '/app/.heroku/php/include/php/main/RCS/php.h'.
> >>  Trying pattern rule with stem 'php.h'.
> >>  Trying implicit prerequisite
> >> '/app/.heroku/php/include/php/main/s.php.h'.
> >>  Trying pattern rule with stem 'php.h'.
> >>  Trying implicit prerequisite
> >> '/app/.heroku/php/include/php/main/SCCS/s.php.h'.
> >>  Trying pattern rule with stem 'php'.
> >>  Trying implicit prerequisite
> >>
> '/app/.heroku/php/include/php/main//tmp/bob-1830jl/raphf-2.0.1/src/php.h'.
> >>  Looking for a rule with intermediate file
> >>
> '/app/.heroku/php/include/php/main//tmp/bob-1830jl/raphf-2.0.1/src/php.h'.
> >>   Avoiding implicit rule recursion.
> >>   Trying pattern rule with stem 'php.h'.
> >>   Trying implicit prerequisite
> >>
> '/app/.heroku/php/include/php/main//tmp/bob-1830jl/raphf-2.0.1/src/php.h,v'.
> >>   Trying pattern rule with stem 'php.h'.
> >>   Trying implicit prerequisite
> >>
> '/app/.heroku/php/include/php/main//tmp/bob-1830jl/raphf-2.0.1/src/RCS/php.h,v'.
> >>   Trying pattern rule with stem 'php.h'.
> >>   Trying implicit prerequisite
> >>
> '/app/.heroku/php/include/php/main//tmp/bob-1830jl/raphf-2.0.1/src/RCS/php.h'.
> >>   Trying pattern rule with stem 'php.h'.
> >>   Trying implicit prerequisite
> >>
> 

Re: [PHP-DEV] Why do PHP 8.1 extensions need PHP headers during make install (worked in <8.1)?

[David Zuelke via internals]

That's... sort of... irrelevant for this question; the problem appears
before that step. You could make a tarball of the built extension,
create a .deb archive, whatever; the point is that it should be
installable standalone (think e.g. 'apt-get install php81-imagick').



On Thu, Dec 9, 2021 at 12:33 AM Glash Gnome  wrote:
>
> Hello,
>
> Can you tell me what the program is in step 7)
>
> > package up
>
> Thanks you,
>
>
> Le mer. 8 déc. 2021 à 16:25, David Zuelke via internals 
>  a écrit :
>>
>> Hi all,
>>
>> When building shared extensions for PHP for the purpose of packaging
>> and distributing the builds, the build environment obviously needs PHP
>> installed in the destination directory structure (for headers, phpize,
>> and so forth).
>>
>> But the resulting archive of the built extension should only contain
>> the shared object, and possibly the headers.
>>
>> A common pattern to do achieve is:
>>
>> 1) download/extract PHP to $installdir
>> 2) download/extract extension to $builddir
>> 3) phpize in $builddir
>> 4) make in $builddir
>> 5) rm -rf $installdir
>> 6) make install
>> 7) package up $installdir
>>
>> Step 6 installs the extension into $installdir - you end up with
>> /foo/bar/lib/php/extensions/no-debug-non-zts-20210902/something.so
>>
>> That doesn't work with PHP 8.1 anymore - the Makefile generated by
>> phpize now contains an include directive at the top level (near the
>> bottom), e.g.:
>>
>> -include src/php_raphf_api.dep
>>
>> Which lists not only the extension's headers, but also all of PHP's
>> (in include/main, include/Zend, and so forth):
>>
>> src/php_raphf_api.lo: /tmp/bob-2eBC7e/raphf-2.0.1/src/php_raphf_api.c \
>>  config.h /app/.heroku/php/include/php/main/php.h \
>>  /app/.heroku/php/include/php/main/php_version.h \
>>  /app/.heroku/php/include/php/Zend/zend_stream.h \
>>  /app/.heroku/php/include/php/main/streams/php_stream_context.h \
>> … (many more from main/ and Zend/ here)
>>  /app/.heroku/php/include/php/ext/standard/info.h php_raphf.h \
>>  php_raphf_api.h php_raphf.h
>>
>> This results in the 'make install' failing if, like in our step 5
>> above, PHP itself has been (re-)moved since the 'make' (output that
>> follows is from a 'make -d install'):
>>
>>   Considering target file 'src/php_raphf_api.lo'.
>> …
>> Considering target file '/app/.heroku/php/include/php/main/php.h'.
>>  File '/app/.heroku/php/include/php/main/php.h' does not exist.
>>  Looking for an implicit rule for
>> '/app/.heroku/php/include/php/main/php.h'.
>>  Trying pattern rule with stem 'php'.
>>  Trying implicit prerequisite
>> '/app/.heroku/php/include/php/main//tmp/bob-1830jl/raphf-2.0.1/src/php.h'.
>>  Trying pattern rule with stem 'php.h'.
>>  Trying implicit prerequisite
>> '/app/.heroku/php/include/php/main/php.h,v'.
>>  Trying pattern rule with stem 'php.h'.
>>  Trying implicit prerequisite
>> '/app/.heroku/php/include/php/main/RCS/php.h,v'.
>>  Trying pattern rule with stem 'php.h'.
>>  Trying implicit prerequisite
>> '/app/.heroku/php/include/php/main/RCS/php.h'.
>>  Trying pattern rule with stem 'php.h'.
>>  Trying implicit prerequisite
>> '/app/.heroku/php/include/php/main/s.php.h'.
>>  Trying pattern rule with stem 'php.h'.
>>  Trying implicit prerequisite
>> '/app/.heroku/php/include/php/main/SCCS/s.php.h'.
>>  Trying pattern rule with stem 'php'.
>>  Trying implicit prerequisite
>> '/app/.heroku/php/include/php/main//tmp/bob-1830jl/raphf-2.0.1/src/php.h'.
>>  Looking for a rule with intermediate file
>> '/app/.heroku/php/include/php/main//tmp/bob-1830jl/raphf-2.0.1/src/php.h'.
>>   Avoiding implicit rule recursion.
>>   Trying pattern rule with stem 'php.h'.
>>   Trying implicit prerequisite
>> '/app/.heroku/php/include/php/main//tmp/bob-1830jl/raphf-2.0.1/src/php.h,v'.
>>   Trying pattern rule with stem 'php.h'.
>>   Trying implicit prerequisite
>> '/app/.heroku/php/include/php/main//tmp/bob-1830jl/raphf-2.0.1/src/RCS/php.h,v'.
>>   Trying pattern rule with stem 'php.h'.
>>   Trying implicit prerequisite
>> '/app/.heroku/php/include/php/main//tmp/bob-1830jl/raphf-2.0.1/src/RCS/php.h'.
>>   Trying pattern rule with stem 'php.h'.
>>   Trying implicit prerequisite
>> '/app/.heroku/php/include/php/main//tmp/bob-1830jl/raphf-2.0.1/src/s.php.h'.
>>   Trying pattern rule with stem 'php.h'.
>>   Trying implicit prerequisite
>> '/app/.heroku/php/include/php/main//tmp/bob-1830jl/raphf-2.0.1/src/SCCS/s.php.h'.
>>  No implicit rule found for 
>> '/app/.heroku/php/include/php/main/php.h'.
>>  Finished prerequisites of target file
>> '/app/.heroku/php/include/php/main/php.h'.
>> Must remake target '/app/.heroku/php/include/php/main/php.h'.
>> make: *** No rule to make target
>> '/app/.heroku/php/include/php/main/php.h', needed by
>> 

Re: [PHP-DEV] Why do PHP 8.1 extensions need PHP headers during make install (worked in <8.1)?

[Glash Gnome]

Hello,

Can you tell me what the program is in step 7)

> package up

Thanks you,


Le mer. 8 déc. 2021 à 16:25, David Zuelke via internals <
internals@lists.php.net> a écrit :

> Hi all,
>
> When building shared extensions for PHP for the purpose of packaging
> and distributing the builds, the build environment obviously needs PHP
> installed in the destination directory structure (for headers, phpize,
> and so forth).
>
> But the resulting archive of the built extension should only contain
> the shared object, and possibly the headers.
>
> A common pattern to do achieve is:
>
> 1) download/extract PHP to $installdir
> 2) download/extract extension to $builddir
> 3) phpize in $builddir
> 4) make in $builddir
> 5) rm -rf $installdir
> 6) make install
> 7) package up $installdir
>
> Step 6 installs the extension into $installdir - you end up with
> /foo/bar/lib/php/extensions/no-debug-non-zts-20210902/something.so
>
> That doesn't work with PHP 8.1 anymore - the Makefile generated by
> phpize now contains an include directive at the top level (near the
> bottom), e.g.:
>
> -include src/php_raphf_api.dep
>
> Which lists not only the extension's headers, but also all of PHP's
> (in include/main, include/Zend, and so forth):
>
> src/php_raphf_api.lo: /tmp/bob-2eBC7e/raphf-2.0.1/src/php_raphf_api.c \
>  config.h /app/.heroku/php/include/php/main/php.h \
>  /app/.heroku/php/include/php/main/php_version.h \
>  /app/.heroku/php/include/php/Zend/zend_stream.h \
>  /app/.heroku/php/include/php/main/streams/php_stream_context.h \
> … (many more from main/ and Zend/ here)
>  /app/.heroku/php/include/php/ext/standard/info.h php_raphf.h \
>  php_raphf_api.h php_raphf.h
>
> This results in the 'make install' failing if, like in our step 5
> above, PHP itself has been (re-)moved since the 'make' (output that
> follows is from a 'make -d install'):
>
>   Considering target file 'src/php_raphf_api.lo'.
> …
> Considering target file '/app/.heroku/php/include/php/main/php.h'.
>  File '/app/.heroku/php/include/php/main/php.h' does not exist.
>  Looking for an implicit rule for
> '/app/.heroku/php/include/php/main/php.h'.
>  Trying pattern rule with stem 'php'.
>  Trying implicit prerequisite
> '/app/.heroku/php/include/php/main//tmp/bob-1830jl/raphf-2.0.1/src/php.h'.
>  Trying pattern rule with stem 'php.h'.
>  Trying implicit prerequisite
> '/app/.heroku/php/include/php/main/php.h,v'.
>  Trying pattern rule with stem 'php.h'.
>  Trying implicit prerequisite
> '/app/.heroku/php/include/php/main/RCS/php.h,v'.
>  Trying pattern rule with stem 'php.h'.
>  Trying implicit prerequisite
> '/app/.heroku/php/include/php/main/RCS/php.h'.
>  Trying pattern rule with stem 'php.h'.
>  Trying implicit prerequisite
> '/app/.heroku/php/include/php/main/s.php.h'.
>  Trying pattern rule with stem 'php.h'.
>  Trying implicit prerequisite
> '/app/.heroku/php/include/php/main/SCCS/s.php.h'.
>  Trying pattern rule with stem 'php'.
>  Trying implicit prerequisite
> '/app/.heroku/php/include/php/main//tmp/bob-1830jl/raphf-2.0.1/src/php.h'.
>  Looking for a rule with intermediate file
> '/app/.heroku/php/include/php/main//tmp/bob-1830jl/raphf-2.0.1/src/php.h'.
>   Avoiding implicit rule recursion.
>   Trying pattern rule with stem 'php.h'.
>   Trying implicit prerequisite
>
> '/app/.heroku/php/include/php/main//tmp/bob-1830jl/raphf-2.0.1/src/php.h,v'.
>   Trying pattern rule with stem 'php.h'.
>   Trying implicit prerequisite
>
> '/app/.heroku/php/include/php/main//tmp/bob-1830jl/raphf-2.0.1/src/RCS/php.h,v'.
>   Trying pattern rule with stem 'php.h'.
>   Trying implicit prerequisite
>
> '/app/.heroku/php/include/php/main//tmp/bob-1830jl/raphf-2.0.1/src/RCS/php.h'.
>   Trying pattern rule with stem 'php.h'.
>   Trying implicit prerequisite
>
> '/app/.heroku/php/include/php/main//tmp/bob-1830jl/raphf-2.0.1/src/s.php.h'.
>   Trying pattern rule with stem 'php.h'.
>   Trying implicit prerequisite
>
> '/app/.heroku/php/include/php/main//tmp/bob-1830jl/raphf-2.0.1/src/SCCS/s.php.h'.
>  No implicit rule found for
> '/app/.heroku/php/include/php/main/php.h'.
>  Finished prerequisites of target file
> '/app/.heroku/php/include/php/main/php.h'.
> Must remake target '/app/.heroku/php/include/php/main/php.h'.
> make: *** No rule to make target
> '/app/.heroku/php/include/php/main/php.h', needed by
> 'src/php_raphf_api.lo'.  Stop.
>
> Building extensions for 8.0 or lower doesn't generate such a
> `src/php_EXTNAME_api.dep` file.
>
> Is this intentional? If so, could someone explain the purpose of the
> change? I couldn't find anything insightful when browsing the Git
> logs.
>
> The workaround is to
>
> make INSTALL_ROOT=$SOMETEMPDIR install
>
> and then move things into place for packaging, but I was still

Re: [PHP-DEV] Re: Finishing AVIF support in getimagesize()

[Christoph M. Becker]

On 08.12.2021 at 19:22, Yannis Guyon via internals wrote:

>> On a general principle, I understood that bundling libs should be avoided.
>
> libavifinfo was designed more as a copy-pastable snippet than a library.

Thanks for clarifying.

> Unfortunately AVIF is complex and avifinfo.c is lengthier than expected,
> although
> I believe 700 lines are still reasonable and way below a library's scale.
>
>> I am not totally sure aviinfo is stable enough to be bundle either way.
>
> What would you call "stable enough"?
> There is a test
> ,
> it is currently internally fuzzed
> 
> and
> was successfully run on more
> than 60k crawled AVIF images. I do not plan on modifying or testing it
> further
> until the AVIF format changes.
>
>> The format will  be widely used in a near future so i would rather allow it
>> if libavinfo js available rather than  bundling it.
>
> What would be the pros and cons of using a javascript version of libavifinfo
> rather than the C one?

I think that "js" is a typo, and should have actually been "is". :)

Anyhow, that is the point.  If there will be no (widely available)
libavifinfo, it makes sense to either bundle it, and have the full
getimagesize() functionality for AVIF, or to not bundle it, and have
only the most basic getimagesize() support for AVIF (as it is now).

Christoph

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

Re: [PHP-DEV] Re: Finishing AVIF support in getimagesize()

[Yannis Guyon via internals]

>
> On a general principle, I understood that bundling libs should be avoided.
>

libavifinfo was designed more as a copy-pastable snippet than a library.
Unfortunately AVIF is complex and avifinfo.c is lengthier than expected,
although
I believe 700 lines are still reasonable and way below a library's scale.

I am not totally sure aviinfo is stable enough to be bundle either way.
>

What would you call "stable enough"?
There is a test
,
it is currently internally fuzzed

and
was successfully run on more
than 60k crawled AVIF images. I do not plan on modifying or testing it
further
until the AVIF format changes.

The format will  be widely used in a near future so i would rather allow it
> if libavinfo js available rather than  bundling it.


What would be the pros and cons of using a javascript version of libavifinfo
rather than the C one?

Thanks,
Yannis

Re: [PHP-DEV] Re: Finishing AVIF support in getimagesize()

[Pierre Joye]

Good evening,

On Wed, Dec 8, 2021, 6:40 PM Christoph M. Becker  wrote:

> On 01.12.2021 at 00:52, Ben Morss via internals wrote:
>
> l
>
> Thanks for your and your colleague's work!  It's highly appreciated.
>
> Anyhow, a respective PR[1] has been submitted now, and I'm in favor of
> bundling libavifinfo.  I'm not too concerned regarding the additional
> size of the PHP binaries which would result by linking it in, but if
> others are, we could still introduce a configuration option (e.g.
> `--with-libavifinfo`).
>
> Thoughts?  Objections to bundling libavifinfo at all?
>
> [1] 
>

On a general principle, I understood that bundling libs should be avoided.

I am not totally sure aviinfo is stable enough to be bundle either way.

The format will  be widely used in a near future so i would rather allow it
if libavinfo js available rather than  bundling it.

best,
Pierre

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

Re: [PHP-DEV] Automatic implementation of Stringable may conflict with old, untyped arginfo declarations

[Jeremy Mikola]

On Fri, Nov 12, 2021 at 7:00 AM Nikita Popov  wrote:

>
> With the introduction of Stringable PHP also started automatically adding
> the string result type to __toString(), specifically for compatibility with
> the interface. As such, it should be safe to add the string return type
> everywhere for PHP >= 8.0. (If you use stubs with legacy arginfo, that
> would automatically give you the right behavior: types on PHP 8, no types
> on old versions.)
>

We haven't explored using stubs, but I'll keep that in mind. Andreas has
definitely mentioned that in the past and I believe it's on the list of
ideas to implement once we revisit typing across the board for the
extension (which we plan to do since we finally dropped support for PHP
7.1).

I previously added explicit string return types to all of our toString
methods (including interfaces), which I understand is a small BC break for
any userland classes implementing those interfaces (as rare as that is).

Just yesterday, I had an idea to use tentative return type info on the
interface toString methods ([mongodb/mongo-php-driver#1283](
https://github.com/mongodb/mongo-php-driver/pull/1283)), which seems to
require no changes at all to userland classes. ReturnTypeWillChange
attributes are not even required on PHP 8.1+ since the Stringable behavior
will automatically add the return type info if it's omitted. For PHP 8.0
and earlier, we map the ZEND_BEGIN_ARG_WITH_TENTATIVE_RETURN_TYPE_INFO_EX
macro to ZEND_BEGIN_ARG_INFO_EX -- so these methods will continue to have
no return types there (also avoiding a BC break).

I tested the change (i.e. tentative return type info for interfaces) with
PHP's master branch to cover the warning you added in [86379b6](
https://github.com/php/php-src/commit/86379b6710f972e0d4a11c89ce28d5768d9824d3).
There seems to be no conflict, which seems reasonable considering that
return type is only "tentative" from the context of userland (and only
until PHP 9.0, when it becomes enforced). Tentative return types are still
considered the actual return type for internal purposes and satisfies the
check for Stringable compatibility.

Are we likely to run into issues with this approach? If so, I'll consider
your last suggestion to define non-tentative return type info for
interfaces on PHP 8.0+ (where Stringable will add it to userland classes
automatically), and leave return type info absent for PHP 7.x. But if both
are viable solutions, I think I prefer the tentative return type info
approach.

-- 
jeremy mikola

[PHP-DEV] Why do PHP 8.1 extensions need PHP headers during make install (worked in <8.1)?

[David Zuelke via internals]

Hi all,

When building shared extensions for PHP for the purpose of packaging
and distributing the builds, the build environment obviously needs PHP
installed in the destination directory structure (for headers, phpize,
and so forth).

But the resulting archive of the built extension should only contain
the shared object, and possibly the headers.

A common pattern to do achieve is:

1) download/extract PHP to $installdir
2) download/extract extension to $builddir
3) phpize in $builddir
4) make in $builddir
5) rm -rf $installdir
6) make install
7) package up $installdir

Step 6 installs the extension into $installdir - you end up with
/foo/bar/lib/php/extensions/no-debug-non-zts-20210902/something.so

That doesn't work with PHP 8.1 anymore - the Makefile generated by
phpize now contains an include directive at the top level (near the
bottom), e.g.:

-include src/php_raphf_api.dep

Which lists not only the extension's headers, but also all of PHP's
(in include/main, include/Zend, and so forth):

src/php_raphf_api.lo: /tmp/bob-2eBC7e/raphf-2.0.1/src/php_raphf_api.c \
 config.h /app/.heroku/php/include/php/main/php.h \
 /app/.heroku/php/include/php/main/php_version.h \
 /app/.heroku/php/include/php/Zend/zend_stream.h \
 /app/.heroku/php/include/php/main/streams/php_stream_context.h \
… (many more from main/ and Zend/ here)
 /app/.heroku/php/include/php/ext/standard/info.h php_raphf.h \
 php_raphf_api.h php_raphf.h

This results in the 'make install' failing if, like in our step 5
above, PHP itself has been (re-)moved since the 'make' (output that
follows is from a 'make -d install'):

  Considering target file 'src/php_raphf_api.lo'.
…
Considering target file '/app/.heroku/php/include/php/main/php.h'.
 File '/app/.heroku/php/include/php/main/php.h' does not exist.
 Looking for an implicit rule for
'/app/.heroku/php/include/php/main/php.h'.
 Trying pattern rule with stem 'php'.
 Trying implicit prerequisite
'/app/.heroku/php/include/php/main//tmp/bob-1830jl/raphf-2.0.1/src/php.h'.
 Trying pattern rule with stem 'php.h'.
 Trying implicit prerequisite
'/app/.heroku/php/include/php/main/php.h,v'.
 Trying pattern rule with stem 'php.h'.
 Trying implicit prerequisite
'/app/.heroku/php/include/php/main/RCS/php.h,v'.
 Trying pattern rule with stem 'php.h'.
 Trying implicit prerequisite
'/app/.heroku/php/include/php/main/RCS/php.h'.
 Trying pattern rule with stem 'php.h'.
 Trying implicit prerequisite
'/app/.heroku/php/include/php/main/s.php.h'.
 Trying pattern rule with stem 'php.h'.
 Trying implicit prerequisite
'/app/.heroku/php/include/php/main/SCCS/s.php.h'.
 Trying pattern rule with stem 'php'.
 Trying implicit prerequisite
'/app/.heroku/php/include/php/main//tmp/bob-1830jl/raphf-2.0.1/src/php.h'.
 Looking for a rule with intermediate file
'/app/.heroku/php/include/php/main//tmp/bob-1830jl/raphf-2.0.1/src/php.h'.
  Avoiding implicit rule recursion.
  Trying pattern rule with stem 'php.h'.
  Trying implicit prerequisite
'/app/.heroku/php/include/php/main//tmp/bob-1830jl/raphf-2.0.1/src/php.h,v'.
  Trying pattern rule with stem 'php.h'.
  Trying implicit prerequisite
'/app/.heroku/php/include/php/main//tmp/bob-1830jl/raphf-2.0.1/src/RCS/php.h,v'.
  Trying pattern rule with stem 'php.h'.
  Trying implicit prerequisite
'/app/.heroku/php/include/php/main//tmp/bob-1830jl/raphf-2.0.1/src/RCS/php.h'.
  Trying pattern rule with stem 'php.h'.
  Trying implicit prerequisite
'/app/.heroku/php/include/php/main//tmp/bob-1830jl/raphf-2.0.1/src/s.php.h'.
  Trying pattern rule with stem 'php.h'.
  Trying implicit prerequisite
'/app/.heroku/php/include/php/main//tmp/bob-1830jl/raphf-2.0.1/src/SCCS/s.php.h'.
 No implicit rule found for '/app/.heroku/php/include/php/main/php.h'.
 Finished prerequisites of target file
'/app/.heroku/php/include/php/main/php.h'.
Must remake target '/app/.heroku/php/include/php/main/php.h'.
make: *** No rule to make target
'/app/.heroku/php/include/php/main/php.h', needed by
'src/php_raphf_api.lo'.  Stop.

Building extensions for 8.0 or lower doesn't generate such a
`src/php_EXTNAME_api.dep` file.

Is this intentional? If so, could someone explain the purpose of the
change? I couldn't find anything insightful when browsing the Git
logs.

The workaround is to

make INSTALL_ROOT=$SOMETEMPDIR install

and then move things into place for packaging, but I was still
wondering why this change was made in the first place.

Thanks and greetings,

David

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

[PHP-DEV] Re: Finishing AVIF support in getimagesize()

[Christoph M. Becker]

On 01.12.2021 at 00:52, Ben Morss via internals wrote:

> Earlier this year, I added support for AVIF images
>  to libgd
> . My ultimate goal was to bring support for
> this new image format to PHP, so that the world's top CMSs could let sites
> serve AVIFs. A few of you kindly guided me as I made my first contributions
> to the PHP codebase, propagating libgd's new AVIF support
>  into PHP's bundled gd fork,
> and adding
> AVIF awareness  to non-gd
> functions like getimagesize() and imagecreatefromstring().
>
> Unfortunately, when I worked on getimagesize(), AVIF experts advised that
> there was no compact, reliable way to determine the size of an AVIF image
> without relying on an external library like libavif. We decided
>  that it
> was useful to return the information that a given image was an AVIF, but
> simply to return 0 for the actual dimensions and other details. The user
> would simply need to decode the image to determine this information.
>
> Of course, users would really like
>  to use
> getimagesize() to return the actual size. So a colleague has kindly
> created standalone
> code  (that
> doesn't depend on libavif) to do this, with the goal of adding it to PHP.
>
> The code comprises several hundred lines. But - it works, and it works well.
>
> Would it be ok to submit a PR containing this code to add this
> functionality? Or does someone have a superior approach?

Thanks for your and your colleague's work!  It's highly appreciated.

Anyhow, a respective PR[1] has been submitted now, and I'm in favor of
bundling libavifinfo.  I'm not too concerned regarding the additional
size of the PHP binaries which would result by linking it in, but if
others are, we could still introduce a configuration option (e.g.
`--with-libavifinfo`).

Thoughts?  Objections to bundling libavifinfo at all?

[1] 

--
Christoph M. Becker

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

Re: [PHP-DEV] RFC [Discussion] array_column results grouping

[Hassan Ahmed]

Hendra Gunawan IMHO your suggestions is not related to
`array_group()`, you are talking about a great change in PHP as
mentioned by Larry, since we can have `Array($input, group(),
reducer(), mapper(), filter() . and so forth);` or even any other
way to handle the list comprehensions. but for array_group I think
that we should keep it to the minimal, to only group array.

~Hassan Ahmed

On Wed, Dec 8, 2021 at 1:26 AM Hendra Gunawan
 wrote:
>
> >
> > And if you want to map, reduce, or filter without grouping? Then you can't
> > really use this function. And as noted, the order in which you apply those
> > operations may matter, and no order is necessarily more obvious or 
> > beneficial
>
> You can modify it slightly if you eager to:
>
> array_group(
> ...
> null|int|string|array $index_key,
> ...
> ): array
>
> If You provide `null`, it will operate on a bare array, no grouping involved.
> As a consequence, users have to provide `reducer` or `mapper`. So virtually,
> You design `array_group` to swallow `array_reduce` and `array_map`. Though,
> `array_map` is actually a different API compared to `array_reduce` or
> `array_group`.
>
> Interestingly, you will get a better quality of code if you include `reducer: 
> `
> and `mapper: ` consistently, whatever array level you work with.
>
> // `array_reduce` and `array_map` alternative
> array_group($array, null, reducer: $fnReducer);
> array_group($array, null, mapper: $fnMapper);
>
> array_group($array, "level1", reducer: $fnReducer);
> array_group($array, "level1", mapper: $fnMapper);
> array_group($array, ["level1", "level2"], reducer: $fnReducer);
> array_group($array, ["level1", "level2"], mapper: $fnMapper);
>
> I hope there is no bias between the proposed name (`array_group`) and its
> functionality.
>
> >
> > Either of these approaches would be superior to cramming more functionality
> > into a single-purpose function to turn it into a single-function swiss army
> > knife:
>
> Not a swiss army knife, just a penknife. AS i wrote before, it is just a
> shortcut. If you really mind about that, we can cancel `filter` and `sorter`,
> leaving only `reducer` and `mapper`. Thought, we can filtering and sorting
> before `array_group`, but i don't know whether it is as accurate as embedding
> them into `array_group` or not. If not, we have to iterate manually, do
> filtering and/or sorting, then reducing/mapping.
>
> >
> > https://wiki.php.net/rfc/comprehensions
> > https://wiki.php.net/rfc/pipe-operator-v2
>
> Of course these are wonderful proposals. Yes, they are superior. To be honest,
> I really hope they are landed in PHP. I already imagine what part of my code
> will be replaced by them. Since I am not a C coder and totally blind about the
> engine, I don't have my own opinion whether we lost good things or not, by not
> adding them to PHP.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>

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