Re: [PHP-DEV] [RFC][Under discussion] RFC1867 for non-POST HTTP verbs
Hi Marco, sob., 7 paź 2023 o 00:55 Marco Aurélio Deleu napisał(a): > Just wanted to mention that maybe this is a great opportunity to create a > request_ family and start with request_parse_post_data > My first thought was why the word `_post_` and not for instance instead a`_form_` which better expresses the purpose then? I'd avoid using the "post" word if we tend to provide functionality that is common for other HTTP methods which in fact was the preliminary cause of this discussion. Cheers, Michał Marcin Brzuchalski
Re: [PHP-DEV] [RFC][Under discussion] RFC1867 for non-POST HTTP verbs
Marco Deleu > On 6 Oct 2023, at 19:39, Ben Ramsey wrote: > > On 10/6/23 11:18, Jakub Zelenka wrote: >> Hi, >>> On Fri, Oct 6, 2023 at 2:44 PM Ilija Tovilo wrote: >>> https://wiki.php.net/rfc/rfc1867-non-post >>> >>> >> It should probably explicitly mention that it uses the same inis like >> max_input_vars, max_file_uploads and max_multipart_body_parts. >> It's kind of strange function as I can't decide where it should be placed. >> I think it might be better as a stream function if it accepts only stream. >> It means it could go to stream funcs and be called stream_parse_post_data >> instead but not sure about. But not 100% sure about it as it doesn't >> exactly fit there. But seems better than html functions (where it's placed >> in the current PR) as it has nothing to do with html IMHO. > > > Maybe it should go in main/rfc1867.c? That's where the php_rfc1867_callback > lives, and this seems somewhat related to that. > > Cheers, > Ben > Just wanted to mention that maybe this is a great opportunity to create a request_ family and start with request_parse_post_data -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Under discussion] RFC1867 for non-POST HTTP verbs
On 10/6/23 11:18, Jakub Zelenka wrote: Hi, On Fri, Oct 6, 2023 at 2:44 PM Ilija Tovilo wrote: https://wiki.php.net/rfc/rfc1867-non-post It should probably explicitly mention that it uses the same inis like max_input_vars, max_file_uploads and max_multipart_body_parts. It's kind of strange function as I can't decide where it should be placed. I think it might be better as a stream function if it accepts only stream. It means it could go to stream funcs and be called stream_parse_post_data instead but not sure about. But not 100% sure about it as it doesn't exactly fit there. But seems better than html functions (where it's placed in the current PR) as it has nothing to do with html IMHO. Maybe it should go in main/rfc1867.c? That's where the php_rfc1867_callback lives, and this seems somewhat related to that. Cheers, Ben OpenPGP_signature Description: OpenPGP digital signature
[PHP-DEV] Re: [RFC] [Discussion] XML_OPTION_PARSE_HUGE
On 9/21/23 23:26, Niels Dossche wrote: > Hi internals > > I'd like to put a new RFC under discussion: > https://wiki.php.net/rfc/xml_option_parse_huge > > Kind regards > Niels Hi internals It's been two weeks, I'd like to start the vote tomorrow evening. Please raise any last complaints now. Thanks Niels -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [PHP-DEF][RFC][VOTE] A new JIT implementation based on IR Framework
On Thu, Oct 5, 2023 at 1:52 PM Dmitry Stogov wrote: > > Hi internals, > > The vote on "A new JIT implementation based on IR Framework" RFC is started. > > https://wiki.php.net/rfc/jit-ir > > Thanks. Dmitry. >From the RFC: > The details of the IR framework are complex. This [presentation][1] explains > design ideas and makes overview of the most important implementaion details. Was this presentation recorded and is it watchable somewhere? It looks to have answers to many questions I had. [1]: https://www.researchgate.net/publication/374470404_IR_JIT_Framework_a_base_for_the_next_generation_JIT_for_PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] [Discussion] Add 4 new rounding modes to round() function
Hi On 10/5/23 23:37, Jorg Sowa wrote: I will also echo Tim's idea of using an enum instead and a union type. For the namespace, I think it would make sense to use Maths\RoundingMode Doesn't Math/Maths namespace introduce BC break? Why do you think a namespace would introduce a BC break? However I'd argue in favor of an enum, but within the global namespace. i.e. just \RoundingMode. https://github.com/search?q=%22class+RoundingMode%22+language%3Aphp&type=code only finds namespaced versions, so this should not be a break. If you prefer not to introduce an enum, then you should at least add PHP_ROUND_HALF_AWAY_FROM_ZERO as an alias for PHP_ROUND_HALF_UP (and likewise for HALF_DOWN) to make the constants internally consistent. Best regards Tim Düsterhus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Re: Is there any CLA document? Who has the copyright of contributed codes?
On 10/6/23 05:24, 丸山雅裕 wrote: Dear The PHP Group Hello. I'm thinking of contributing to PHP within my working hours. Is there any CLA document? My company has some legal check processes before contribution. The legal department cares of "who has the copyright of contributed codes". I suppose The PHP Group has the copyright, is it correct? I've read the following documents, but I'm not sure about it. https://www.php.net/license/index.php https://www.php.net/license/contrib-guidelines-code.php https://github.com/php/php-src/blob/master/CONTRIBUTING.md Regards, Masahiro Maruyama Masahiro, Thanks for wanting to contribute, and I'm glad to hear your company is interested in letting you contributing during working hours. First off, a disclaimer: I am not a lawyer, and this is not legal advice. PHP does not have a CLA. When you contribute code to any open source project, unless you sign a CLA or other document that specifies assignment of copyright, all copyright on the code contributed (if it is copyrightable) remains with the contributor. Depending on the laws in your country, since you're performing the work during work hours, this may mean that your company owns the copyright. While the contributor owns the copyright on their contributions, they are implicitly granting the project (and users of the project) use of their code under the same terms as the main license on the project (unless otherwise stated). I mentioned "if it is copyrightable" because very small changes (i.e., typo fixes and other insignificant, minor changes) may not be copyrightable. Cheers, Ben OpenPGP_signature Description: OpenPGP digital signature
Re: [PHP-DEV] [RFC][Under discussion] RFC1867 for non-POST HTTP verbs
Hi, On Fri, Oct 6, 2023 at 2:44 PM Ilija Tovilo wrote: > https://wiki.php.net/rfc/rfc1867-non-post > > It should probably explicitly mention that it uses the same inis like max_input_vars, max_file_uploads and max_multipart_body_parts. It's kind of strange function as I can't decide where it should be placed. I think it might be better as a stream function if it accepts only stream. It means it could go to stream funcs and be called stream_parse_post_data instead but not sure about. But not 100% sure about it as it doesn't exactly fit there. But seems better than html functions (where it's placed in the current PR) as it has nothing to do with html IMHO. Cheers Jakub Regards Jakub
Re: [PHP-DEV] [RFC][Under discussion] RFC1867 for non-POST HTTP verbs
Hi On 10/6/23 15:44, Ilija Tovilo wrote: https://wiki.php.net/rfc/rfc1867-non-post Regarding the cleanup of the files, perhaps the files could be read into a `php://temp` stream (https://www.php.net/manual/en/wrappers.php.php#wrappers.php.memory)? While this would cause the function to be incompatible with $_FILES, I think it would make for a much nicer API and it would also automatically solve the cleanup problem. Best regards Tim Düsterhus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Is there any CLA document? Who has the copyright of contributed codes?
2023年10月6日(金) 19:24 丸山雅裕 : > > Dear The PHP Group > > Hello. > > I'm thinking of contributing to PHP within my working hours. > Is there any CLA document? > > My company has some legal check processes before contribution. > The legal department cares of "who has the copyright of contributed codes". > > I suppose The PHP Group has the copyright, is it correct? > > I've read the following documents, but I'm not sure about it. > https://www.php.net/license/index.php > https://www.php.net/license/contrib-guidelines-code.php > https://github.com/php/php-src/blob/master/CONTRIBUTING.md > > Regards, > > Masahiro Maruyama > Hi, I don't know about CLA, but probably this mail is judged to spam. Therefore, I would like send message to welcome that contribute to you. Regards Yuya -- --- Yuya Hamada (tekimen) - https://tekitoh-memdhoi.info - https://github.com/youkidearitai - -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [Discussion] Rounding Integers as int
Hi Tim, On 05.10.23 21:57, Tim Düsterhus wrote: Hi On 10/4/23 08:35, Marc Bennewitz wrote: As far as I understand you are in favor of option 1. (considering it a bugfix) but how do you make sure this will not lead to different application behavior overlooked on upgrading? Also there is no way to opt-in new behavior. Yes, I would be in favor of option 1 and I don't even see a reason not to do this in PHP 8.4 right away. As I mentioned before, this effectively can be considered a bug fix: PHP does not correctly round integers > 2^53. While this is not a bug fix that is appropriate for the current stable branches, I don't see why it would not be appropriate for PHP 8.4 if there's an RFC for it. In fact there is already a rounding bugfix (no RFC for that) in PHP 8.4: https://github.com/php/php-src/blob/65a8c70f93ccb7e008de147cd4c357681c653bd0/UPGRADING#L75-L82 While PHP tries hard to keep backwards compatibility within a given major, keeping full compatibility is effectively impossible for the huge API surface PHP exposes. Every version includes *some* changes that are technically breaking for one reason or another. Fixing edge cases like having 0.49994 rounded down correctly is a different story than having something simple like "round(10 / 2) === 5.0" to return false instead. Best regards Tim Düsterhus Best, Marc OpenPGP_0x3936ABF753BC88CE.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] [RFC] [Discussion] Rounding Integers as int
Hi George,
On 05.10.23 14:12, G. P. B. wrote:
On Thu, 5 Oct 2023 at 07:40, Marc Bennewitz wrote:
I don't see a bug or broken behavior here as these functions were
processing floating point numbers since forever.
https://3v4l.org/PrrmO
That's not my point, the point is about the function being broken for large
64bit integers, which your RFC is fixing.
I would also expect most people that actually use ceil/floor/round to dump
the return value of it into a property/value that is expected to be an int.
Which is also compatible for floats that fit in an int (and since 8.2 for
those that have a fractional part a warning is emitted).
I see no benefit in doing this weird approach instead of just changing the
behaviour.
Yes this is a theoretical BC break [1], but unless you can show me an
actual use case that breaks (and even then) I don't think the approach of
this RFC is good.
Running a quick code search /round\([^\(]+\)\s===/ language:PHP on
GitHub finds possible breakages based on strict comparison:
// if width and height are ints
$x = ( $height1 / $width1 ) * $width2;
if ( round( $x ) === round( $height2 ) ) {
// if number is int
public static function isZero($number, $precission = 2)
{
return round($number, $precission) === 0.0;
}
// where ecb is int
return $ecb && round(5000 / $ecb) === 2.0;
George P. Banyard
[1] And this is coming from me, who does love finding weird edge cases and
remove them from the language, just look at the 8.3 range() RFC
OpenPGP_0x3936ABF753BC88CE.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
[PHP-DEV] [RFC][Under discussion] RFC1867 for non-POST HTTP verbs
Hi everyone A while ago I wrote an e-mail about RFC1867 (multipart/form-data) not being parsed by PHP for non-POST requests. https://externals.io/message/120641 I'd like to announce an RFC that proposes adding a new function called parse_post_data() to expose the existing functionality to userland, so that the mechanism can be used for other HTTP verbs. https://wiki.php.net/rfc/rfc1867-non-post As opposed to the semantics I suggested in the previous thread, this proposal returns the parsed result instead of populating it directly to the superglobals, and it accepts an optional input stream. Let me know if you have any feedback. Ilija -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [Discussion] Adding bcround, bcfloor and bcceil to BCMath
Hi, Claude I'm very sorry, I'm not a native English speaker and I couldn't quite understand whether you think BCMath should be integrated into GMP. I understand your use case well, so if you don't mind, can I ask if it should or should not be integrated? Regards. Saki -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [Discussion] Adding bcround, bcfloor and bcceil to BCMath
Hi, Jeff Thanks for letting me know your use case. This is important information when discussing this issue. Saki -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Is there any CLA document? Who has the copyright of contributed codes?
Dear The PHP Group Hello. I'm thinking of contributing to PHP within my working hours. Is there any CLA document? My company has some legal check processes before contribution. The legal department cares of "who has the copyright of contributed codes". I suppose The PHP Group has the copyright, is it correct? I've read the following documents, but I'm not sure about it. https://www.php.net/license/index.php https://www.php.net/license/contrib-guidelines-code.php https://github.com/php/php-src/blob/master/CONTRIBUTING.md Regards, Masahiro Maruyama
Re: [PHP-DEV] [RFC] [Discussion] Adding bcround, bcfloor and bcceil to BCMath
Hi, > Le 5 oct. 2023 à 14:26, Saki Takamachi a écrit : > > In fact, I predict that many use cases will be covered by GMP. > > Still, I think that there may be cases where calculation functions like > mainframe BCD are required, such as when calculating money. > > I am unable to decide whether it is correct to deprecate BCMath and only use > GMP. > > I'd like to hear other people's opinions as well. > We use bcmath in particular for money calculation indeed, and some other things, most of them have in common to work with decimal numbers. For those purposes, gmp (in its current state) is pointless, because it supports only integers. I could multiply my numbers with an appropriate power of ten and work with integers; but in that case I could just use native 64-bits integers: even if you work on Apple’s accounting, they won’t overflow. > Le 4 oct. 2023 à 13:39, Saki Takamachi a écrit : > > > After all, I feel that BCMath and GMP have different roles. > > Arbitrary precision mathematics and very high precision mathematics are > similar but distinctly different. > > If PHP has already started integrating these things, then of course I'll > follow suit, but if not, I'm against these integrations. > > If I missed something important, could you please let me know? > None of the above. As noted, my main use of bcmath is neither arbitrary precision, nor very high precision, it is decimal numbers. Of course, bcmath works equally well for manipulation of big integers, which is my second use case of the library. Because I already use bcmath for other things and I don’t need Legendre symbols, I have not much incentive to switch to gmp for big integers. —Claude -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
