Re: [PHP-DEV] PR #1325 - array_column() for array of objects

On Sat, Jun 13, 2015 at 11:46 AM, Rowan Collins wrote: > On 12 June 2015 02:31:18 BST, Tjerk Meesters > wrote: > >Hi, > > > >I've created a PR here: https://github.com/php/php-src/pull/1325 > > > >This enhancement allows for properties on objects to work in the same > >way > >as arrays for the i

Re: [PHP-DEV] [RFC] Default expression

> On Aug 24, 2024, at 11:49, Bilge wrote: > > Hi gang, > > New RFC just dropped: https://wiki.php.net/rfc/default_expression. I think > some of you might enjoy this one. Hit me with any feedback. > > This one already comes complete with working implementation that I've been > cooking for a li

Re: [PHP-DEV] Debug Build Container Image for GitHub Packages

> On Sep 2, 2024, at 08:11, Go Kudo wrote: > > Hi Internals. > > PHP currently does not provide official container images. Given that > DockerHub adequately maintains these and considering the maintenance costs, > we haven't felt the need to change the status quo. > > However, the official D

Re: [PHP-DEV] Debug Build Container Image for GitHub Packages

> On Sep 2, 2024, at 18:53, Bob Weinand wrote: > > On 3.9.2024 01:44:21, Ben Ramsey wrote: >>> On Sep 2, 2024, at 08:11, Go Kudo wrote: >>> >>> Hi Internals. >>> >>> PHP currently does not provide official container images. Given that &g

Re: [PHP-DEV] Debug Build Container Image for GitHub Packages

> On Sep 2, 2024, at 19:36, Bob Weinand wrote: > > On 3.9.2024 02:18:30, Ben Ramsey wrote: >>> On Sep 2, 2024, at 18:53, Bob Weinand wrote: >>> >>> On 3.9.2024 01:44:21, Ben Ramsey wrote: >>> >>>>> On Sep 2, 2024, at 08:11, Go Kudo

[PHP-DEV] [DRAFT] RFC - array_column() function

Hi all, I've written a draft version of an RFC for pull request 56 ( https://github.com/php/php-src/pull/56 ), to add array_column() to the core. Please take a look and provide feedback so that I can improve the patch/proposal. https://wiki.php.net/rfc/array_column Thanks, Ben -- PHP Inter

Re: [PHP-DEV] [DRAFT] RFC - array_column() function

On 6/22/12 5:32 AM, Léo Peltier wrote: Hi, Shouldn't this be called 'array_pluck'? This is the name people usually use when implementing it in PHP (see "array_pluck(" vs "array_column(" in Google) or in other languages/libs (see underscorejs, prototypejs and RoR). I'm open to changing or alia

Re: [PHP-DEV] [DRAFT] RFC - array_column() function

On 6/25/12 9:44 AM, Matthew Weier O'Phinney wrote: On 2012-06-23, Stas Malyshev wrote: I'm open to changing or aliasing the name to array_pluck(), if others are in agreement. I wouldn't know what "pluck" means here. "Column" is a clear word with established meaning. Let's not get too whimsica

[PHP-DEV] Deadlock with session handling code?

we're both somewhat stuck with no clue how to proceed with this. Thanks, Ben Ramsey I'm having a major problem with my PHP scripts getting stuck on one of our production servers. The system runs normally for a while, but after some time, certain httpd processed get wedged. This cause

Re: [PHP-DEV] Deadlock with session handling code?

(). For the second part, here's what my co-worker sent me: /usr/include$ grep F_SETFD `find . -type f` ./asm/fcntl.h:#define F_SETFD 2 /* set/clear close_on_exec */ ./bits/fcntl.h:#define F_SETFD 2 /* Set file descriptor flags. */ -- Ben Ramsey

Re: [PHP-DEV] Deadlock with session handling code?

8066c34 in ap_graceful_stop_signalled () #40 0x08066ed9 in ap_graceful_stop_signalled () #41 0x08067570 in ap_mpm_run () #42 0x0806da4f in main () (gdb) [/snip] -- Ben Ramsey http://benramsey.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Deadlock with session handling code?

support. As I understand it, the "RedHat" version of PHP they are using may have an old version number, but it contains all security patches up to the current version of PHP (though I'm unclear whether those patches include any new features, etc.). -- Ben Ramsey http://benramsey.com/

Re: [PHP-DEV] Re: Syntax in PHP 6

n the past? -- Ben Ramsey http://benramsey.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] filter extension

on as experimental? -- Ben Ramsey http://benramsey.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] [PATCH] Generate warning when using PDO::setAttribute() and ATTR_PERSISTENT

t;It’d be nice if PDO::setAttribute() raised a warning if you try to set PDO::ATTR_PERSISTENT, by the way." I'm submitting the attached patch to do just that. :-) -- Ben Ramsey http://benramsey.com/ Index: ext/pdo/pdo_dbh.c === RCS fi

Re: [PHP-DEV] [PATCH] Generate warning when using PDO::setAttribute() and ATTR_PERSISTENT

On 10/26/07 2:44 PM, Andi Gutmans wrote: > Why is it not an if() statement? It can be an if() statement. I added it as a switch in the expectation that other attributes might be added to it in the future. -- Ben Ramsey http://benramsey.com/ -- PHP Internals - PHP Runtime Development Mail

Re: [PHP-DEV] Re: [RFC] Namespace syntax decision

econd that emotion. I'm aware that there's already been a lot of discussion on this already, but as one who's already begun programming prototype code with namespaces, I agree with Johannes and Sebastian here. +1 -- Ben Ramsey http://benramsey.com/ -- PHP Internals - PHP Runtime

Re: [PHP-DEV] Return type hints

regular function declarations would be like: Itest function testing($instance) { return $instance; } Would this present a problem? -- Ben Ramsey http://benramsey.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: my last attempt at sanity with namespaces

stupid-ass reason to remove namespaces? +1 for #3 -- Ben Ramsey http://benramsey.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP Language Specification

On Jul 22, 2014, at 5:41 PM, Andrea Faulds wrote: > On 22 Jul 2014, at 23:37, Larry Garfield wrote: > >> The big question here, though, is whether, going forward, we'll be able to >> mentally switch to a "spec first" mentality. If not, the spec will get out >> of date and become less than us

Re: [PHP-DEV] PHP Language Specification

On Jul 23, 2014, at 1:59 PM, Rowan Collins wrote: > On the flip side, there is definitely value in representatives from other > implementations having a voice in changes that affect them, but that could > just mean ensuring that members of those projects are involved within the > current framew

Re: [PHP-DEV] New globals for PUT and DELETE

On Oct 14, 2014, at 7:47 AM, Kris Craig wrote: > Hey guys, > > Does anybody know why we have $_GET and $_POST, but not $_PUT and > $_DELETE? As far as I can tell, the only way to get these out currently is > to parse their values by reading the incoming stream directly. > > Is there a reason w

Re: [PHP-DEV] New globals for PUT and DELETE

On Oct 14, 2014, at 8:09 AM, Kris Craig wrote: > On Tue, Oct 14, 2014 at 5:54 AM, Andrea Faulds wrote: > >> >> On 14 Oct 2014, at 13:47, Kris Craig wrote: >> >>> Hey guys, >>> >>> Does anybody know why we have $_GET and $_POST, but not $_PUT and >>> $_DELETE? As far as I can tell, the onl

Re: [PHP-DEV] New globals for PUT and DELETE

On Oct 14, 2014, at 8:25 AM, Andrea Faulds wrote: > Let’s add $_REQUEST_BODY and $_QUERY_STRING and make them aliases of $_GET > and $_POST then. Because they’re aliases (by-reference superglobals), there’s > no additional memory consumption, but we finally have saner names. But they are neit

Re: [PHP-DEV] New globals for PUT and DELETE

On Oct 14, 2014, at 8:30 AM, Chris Wright wrote: > I suggested this a while ago, people didn't like the idea, and I'm not > sure I do any more, either. We'd do much better focusing on creating a > standard native request *object* which provides clean access to this > data, and other things that a

Re: [PHP-DEV] New globals for PUT and DELETE

On Oct 14, 2014, at 8:42 AM, Kris Craig wrote: > Removing or renaming $_GET and $_POST would also create confusion and > almost certainly cause widespread BC breakage on a pretty massive scale. > And there's really no gain to offset that. So that just leaves us with > either continuing to have

Re: [PHP-DEV] New globals for PUT and DELETE

On Oct 14, 2014, at 9:08 AM, Mike Dugan wrote: > On October 14, 2014 at 10:04:00 AM, Andrea Faulds (a...@ajf.me) wrote: >> >> >> So $_QUERY and $_FORM, then. That sounds about right. >> > > Did I just name a global variable? W00t! > > Anyhow, yeah neither one is technically 100% correct, b

Re: [PHP-DEV] New globals for PUT and DELETE

On Oct 14, 2014, at 9:20 AM, Park Framework wrote: > 2014-10-14 17:09 GMT+03:00 Mike Dugan : >> If no one else is already working on it, I can write one up this >> morning/early this afternoon and submit it. > > Ok > The RFC In this topic will be included support Rquest - Content-Type: > appli

Re: [PHP-DEV] New globals for PUT and DELETE

> On Oct 26, 2014, at 4:30 PM, Will Fitch wrote: > > 100% agree. Perhaps focusing on getting pecl/http v2 added as ext or core > should be the real discussion: https://wiki.php.net/rfc/pecl_http > . I would be supportive of this, and I’ll even volunteer to

[PHP-DEV] [VOTE] array_column() function

I've opened voting for the array_column() function RFC. You can vote at https://wiki.php.net/rfc/array_column#voting Regards, Ben -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] array_column() function

On 1/12/13 9:14 AM, Peter Cowburn wrote: The "Status" for this RFC is still "Under discussion" and on the RFC listing page it is the same. Is not changing those two things simply an oversight? It was an oversight. I have corrected it in both places. -- PHP Internals - PHP Runtime Development

Re: [PHP-DEV] [VOTE] array_column() function

On 1/12/13 9:19 AM, Derick Rethans wrote: I'm liking this, why start with an function alias already when introducing a new feature? I figured this would be a frequent question, and I was right. :-) In earlier discussions (June 2012), when I first introduced array_column(), much of the discuss

Re: [PHP-DEV] [VOTE] array_column() function

On 1/12/13 10:17 AM, Levi Morrison wrote: 1. Why is this branch based on 5.3, rather than 5.4 or 5.5? Do you want this to be part of 5.3? The RFC (in particular the vote question) does not make it clear where/when you want this to be added. Please, this is not a bug or security fix. It does not

Re: [PHP-DEV] [VOTE] array_column() function

On 1/12/13 10:13 AM, Peter Cowburn wrote: 1. Why is this branch based on 5.3, rather than 5.4 or 5.5? Do you want this to be part of 5.3? The RFC (in particular the vote question) does not make it clear where/when you want this to be added. I mentioned this in another response on this thread. I

[PHP-DEV] Re: [VOTE] array_column() function

On 1/11/13 6:17 PM, Ben Ramsey wrote: I've opened voting for the array_column() function RFC. You can vote at https://wiki.php.net/rfc/array_column#voting I have updated the pull request by removing the array_pluck() alias. I favor the array_column() alias, as it is more in keeping

Re: [PHP-DEV] Re: [VOTE] array_column() function

On 1/14/13 11:54 AM, Scott MacVicar wrote: On 14 Jan 2013, at 11:37, Ben Ramsey wrote: On 1/11/13 6:17 PM, Ben Ramsey wrote: I've opened voting for the array_column() function RFC. You can vote at https://wiki.php.net/rfc/array_column#voting I have updated the pull request by removin

Re: [PHP-DEV] [VOTE] array_column() function

On 1/14/13 3:49 PM, Pierre Joye wrote: hi! Btw, really willing to have this function but I agree with other here, the alias must go. It makes no sense to introduce a function and an alias to it at the same time. Maybe restart the vote and let choose function name. Options: 1. array_column 2. a

Re: [PHP-DEV] [VOTE] array_column() function

> On 12 January 2013 00:17, Ben Ramsey wrote: >> > I've opened voting for the array_column() function RFC. >> > >> > You can vote at https://wiki.php.net/rfc/array_column#voting >> > >> > Regards, >> > Ben >> > >> >>

Re: [PHP-DEV] [VOTE] array_column() function

> Please kill that alias. It is pointless to introduce a new function > with an alias for it. > > I killed the alias in this commit: https://github.com/ramsey/php-src/commit/3439a098a0b646ff05d4da9748996214cac39d12 -Ben

[PHP-DEV] Functionality updates to array_column()

I've just submitted the following pull request for updates to the array_column() function: https://github.com/php/php-src/pull/331 I asked about these changes on the #php.pecl IRC channel a few weeks ago, and others on the channel agreed that it was best to go ahead and submit these changes w

[PHP-DEV] [PATCH] Addition of setcookie2() to support RFC 2965

in the same response.) -- Ben Ramsey http://benramsey.com/ Index: ext/standard/basic_functions.c === RCS file: /repository/php-src/ext/standard/basic_functions.c,v retrieving revision 1.725.2.31.2.53 diff -u -w -r1.725.2.31.2.53 basic

Re: [PHP-DEV] [PATCH] Addition of setcookie2() to support RFC 2965

that you may not use all of them. Maybe it's better to have them as an array of secondary parameters? Yep. Sara already suggested this to me, so I'm working on a new patch for this. Thanks! -- Ben Ramsey http://benramsey.com/ -- PHP Internals - PHP Runtime Development Maili

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

> On Jan 4, 2016, at 10:29 PM, Paul M. Jones wrote: > > If there's an accusation, then *due process* needs to be applied. If it rises > to the level of needing *due process* then the police should be involved. > There's no need, *none at all*, for a star chamber *or* a mob to be an > amenable

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

> On Jan 5, 2016, at 10:03 AM, Paul M. Jones wrote: > > >> On Jan 5, 2016, at 09:55, Ben Ramsey wrote: >> >> >>> On Jan 4, 2016, at 10:29 PM, Paul M. Jones wrote: >>> >>> If there's an accusation, then *due process* needs t

[PHP-DEV] PHP 8.1.18 Released!

8.php#8.1.18> Release Manifest: <https://gist.github.com/ramsey/88952942b627ce96e02d500a8be0582b> Many thanks to all the contributors and supporters! Ben Ramsey, Patrick Allaert, & Joe Watkins php-8.1.18.tar.bz2 SHA256 hash: d2ac30d6b574fca594fe0cc01c0693e23585b27443e342b0aab07274cde44

[PHP-DEV] Re: [VOTE] PHP 8.3 Release Managers

On 4/17/23 16:01, Sergey Panteleev wrote: Hi all, The polls have closed, and Derick’s scripts have tallied the votes [1], Our “rookie" PHP 8.3 release managers are: - Jakub Zelenka - Eric Mann Our "veteran” is the PHP 8.2 release manager Pierrick Charron. Jakub and Eric you are in a good hands

[PHP-DEV] PHP 8.1.20RC1 Available for testing

. Hash values and PGP signatures can be found below or at: https://gist.github.com/ramsey/75308c3efecf8f7370a514e7d7782ba1 8.1.20 should be expected in 2 weeks, i.e. on Jun 8th 2023. Thank you, and happy testing! Regards, Ben Ramsey, Patrick Allaert, & Joe Watkins php-8.1.20RC1.tar.bz2 SHA256

[PHP-DEV] PHP 8.1.20 Released!

8.php#8.1.20> Release Manifest: <https://gist.github.com/ramsey/477cc13346819dffae656ccb948182bf> Many thanks to all the contributors and supporters! Ben Ramsey, Patrick Allaert, & Joe Watkins php-8.1.20.tar.bz2 SHA256 hash: 55578587514a2707500f85319e57c0d4df9b8803cdb26566595ac4bf459dc

Re: [PHP-DEV] [RFC] [Vote] Deprecate functions with overloaded signatures

> On Jun 26, 2023, at 08:36, Máté Kocsis wrote: > > Hi Everyone, > > As previously announced on the list, I have just started the vote about the > "Deprecate functions with overloaded signatures". > > Link to the RFC: > https://wiki.php.net/rfc/deprecate_functions_with_overloaded_signatures > L

Re: [PHP-DEV] RFC1867 (multipart/form-data) PUT requests

> On Jun 20, 2023, at 06:06, Rowan Tommins wrote: > > On Tue, 20 Jun 2023 at 10:25, Ilija Tovilo wrote: > >> Introduce a new function (currently named populate_post_data()) to >> read the input stream and populate the $_POST and $_FILES >> superglobals. >> > > > My initial instinct was to di

Re: [PHP-DEV] RFC1867 (multipart/form-data) PUT requests

> On Jun 27, 2023, at 04:01, Ilija Tovilo wrote: > > Hi Ben, Hi Rowan > > On Mon, Jun 26, 2023 at 8:55 PM Ben Ramsey wrote: >> >>> On Jun 20, 2023, at 06:06, Rowan Tommins wrote: >>> >>> On Tue, 20 Jun 2023 at 10:25, Ilija Tovilo wrote: >

Re: [PHP-DEV] [VOTE] Interface Default Methods

> On Jul 2, 2023, at 19:11, Levi Morrison wrote: > > Chatter on the [Interface Default Methods RFC][1] has been quiet for > the past 6 days, and the feature freeze deadline is fast approaching > for PHP 8.3, so I'm moving this to vote. It'll be open for two weeks > as usual. > > Thanks to every

Re: [PHP-DEV] [VOTE] Interface Default Methods

> On Jul 2, 2023, at 21:43, Levi Morrison wrote: > > On Sun, Jul 2, 2023 at 7:08 PM Ben Ramsey wrote: >> >> I’m probably going to vote “yes” on this, but since the property accessors >> RFC won’t be ready for 8.3,[1] and that RFC covers use of properties in >

Re: [PHP-DEV] PHP 8.1 and OpenSSL

> On Jun 13, 2023, at 15:06, Jan Ehrhardt wrote: > > Hi Christoph, > > "Christoph M. Becker" in php.internals (Wed, 18 Jan 2023 13:20:41 +0100): >> While the official builds for PHP 8.2 already use OpenSSL 3.0, the PHP >> 8.1 builds are still using OpenSSL 1.1.1. However, OpenSSL 1.1.1 is >> on

[PHP-DEV] Re: Default values for php.ini environment variables

> On Jul 13, 2023, at 08:26, Derick Rethans wrote: > > Hi, > > coming forth out of an Xdebug issue > (https://bugs.xdebug.org/view.php?id=2174) I made a pull request so that > it is possible to use a fallback value in environment variables in INI > files, such as in: > > xdebug.start_with_reque

Re: [PHP-DEV] Default values for php.ini environment variables

> On Jul 17, 2023, at 09:25, Derick Rethans wrote: > > On 13 July 2023 18:35:44 BST, Gabriel Fontes wrote: >> Hi everyone, >> >> PR author here. Thanks a lot for pushing this forward, Derick. >> Do let me know if you folks have any feedback or concerns about the PR, I'll >> be happy to address

Re: [PHP-DEV] PHP 8.1 and OpenSSL

> On Jul 5, 2023, at 10:44, Ben Ramsey wrote: > >> On Jun 13, 2023, at 15:06, Jan Ehrhardt wrote: >> >> Hi Christoph, >> >> "Christoph M. Becker" in php.internals (Wed, 18 Jan 2023 13:20:41 +0100): >>> While the official builds for PHP

[PHP-DEV] PHP 8.1.22RC1 Available for testing

. Hash values and PGP signatures can be found below or at: https://gist.github.com/ramsey/465842fbdbbee799a03bc671aeae0eac 8.1.22 should be expected in 2 weeks, i.e. on Aug 3rd 2023. Thank you, and happy testing! Regards, Ben Ramsey, Patrick Allaert, & Joe Watkins php-8.1.22RC1.tar.bz2 SHA256

[PHP-DEV] PHP 8.1.22 Released!

8.php#8.1.22> Release Manifest: <https://gist.github.com/ramsey/a8352c884d47d61f8a32f1bcf9ae8aa4> Many thanks to all the contributors and supporters! Ben Ramsey, Patrick Allaert, & Joe Watkins php-8.1.22.tar.bz2 SHA256 hash: 992354e382c6c618d01ed4be06beea8dec3178b14153df64d3c8c48b85e9f

[PHP-DEV] Re: ICU - NumberFormatter::ROUNDING_MODE default ROUND_HALFEVEN

On 8/3/23 13:55, Hans Krentel via internals wrote: This is a proposal to consider to discuss/change the default value of     NumberFormatter::ROUNDING_MODE from current     NumberFormatter::ROUND_HALFEVEN to     NumberFormatter::ROUND_HALFUP . I got the attention of this from an unrelat

[PHP-DEV] PHP 8.0.30 Released!

hangeLog-8.php#8.0.30> Release Manifest: <https://gist.github.com/ramsey/a22b08609b32d3b85f4139f348bb7019> Many thanks to all the contributors and supporters! Gabriel Caruso & Sara Golemon (with Ben Ramsey filling in) php-8.0.30.tar.bz2 SHA256 hash: 98a9cb6a0e27a6950cdf4b26dcac48f2be2

[PHP-DEV] Re: [RFC] [Discussion] DOM HTML5 parsing and serialization support

On 9/2/23 14:41, Niels Dossche wrote: I'm opening the discussion for my RFC "DOM HTML5 parsing and serialization support". https://wiki.php.net/rfc/domdocument_html5_parser Thanks, Niels. This is much needed. This proposal introduces the DOM\HTML5Document class that extends the DOMDocumen

Re: [PHP-DEV] Casing of acronyms in class and method names

On 8/31/23 13:34, Niels Dossche wrote: Hi Tim On 30/08/2023 13:43, Tim Düsterhus wrote: Hi after suggesting the use of ucfirst(strtolower(...)) casing for acronyms within a classname of a draft RFC, I was made aware of previous class naming RFC (June 2017) that required the use of PascalCase

Re: [PHP-DEV] Casing of acronyms in class and method names

On 9/10/23 20:59, Juliette Reinders Folmer wrote: With the above in mind, I wonder how much confusion/code churn renaming existing classes will cause and if that's worth it, especially as the suggested case for the PHP native class will likely be determined by the version on which the tooling i

Re: [PHP-DEV] PHP 8.1 and OpenSSL

On 7/5/23 10:44, Ben Ramsey wrote: On Jun 13, 2023, at 15:06, Jan Ehrhardt wrote: Hi Christoph, "Christoph M. Becker" in php.internals (Wed, 18 Jan 2023 13:20:41 +0100): While the official builds for PHP 8.2 already use OpenSSL 3.0, the PHP 8.1 builds are still using OpenSSL 1.1.1

[PHP-DEV] PHP 8.1.24RC1 Available for testing

://github.com/php/php-src/issues Hash values and PGP signatures can be found below or at: https://gist.github.com/ramsey/9cb0a7846f848827ed4503b494ffc692 8.1.24 should be expected in 2 weeks, i.e., on September 28, 2023. Thank you, and happy testing! Regards, Ben Ramsey, Patrick Allaert, & Joe Wat

[PHP-DEV] Re: Bugfix backport for bundled pcre2lib

On 9/14/23 12:55, Niels Dossche wrote: Hi internals I currently have a PR open to fix bug https://github.com/php/php-src/issues/11956. PR link: https://github.com/php/php-src/pull/12108 To give some context: OP's code worked fine in PHP 8.0 but not in 8.1. That's because pcre2lib got updated

Re: [PHP-DEV] A new JIT engine for PHP-8.4/9

On 9/15/23 09:35, Derick Rethans wrote: This is a lot of new code, that very few other people understand in great detail. I think it is unwise if we have another large part of the engine that does not have enough people understanding enough of it, to be able to debug issues, and contribute to it

[PHP-DEV] PHP 8.1.24 Released!

8.php#8.1.24> Release Manifest: <https://gist.github.com/ramsey/0ad05a7bffcb630cc3cea31aecbbec5f> Many thanks to all the contributors and supporters! Ben Ramsey, Patrick Allaert, & Joe Watkins php-8.1.24.tar.bz2 SHA256 hash: b0ae5804a9ad53a7e28d0a32629495f816f935b10830c71f4ec15827185a7

[PHP-DEV] Add security.txt file to php.net

I've just opened a PR on web-php to add a security.txt file to php.net[1]. Since there's currently some discussion around security audit priorities[2], I decided to notify this list first and see if there are any questions or concerns about adding a security.txt file. This file implements the

Re: [PHP-DEV] Add security.txt file to php.net

On 9/28/23 16:14, Derick Rethans wrote: On 28 September 2023 20:15:34 BST, Ben Ramsey wrote: 2. I have signed it with my php.net release manager key. Since we publish our release manager keys, I'm recommending that a release manager for a currently supported version of PHP (at the

Re: [PHP-DEV] Add security.txt file to php.net

On 9/29/23 08:42, Sara Golemon wrote: On Thu, Sep 28, 2023 at 5:20 PM Ben Ramsey wrote: I've added documentation inline in the security.txt file To add some nitpicky bikeshedding, I'd put those instructions elsewhere (maybe php-src:docs/release-process.md ?) and only have a sing

[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".

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

[PHP-DEV] PHP 8.1.25RC1 Available for testing

://github.com/php/php-src/issues Hash values and PGP signatures can be found below or at: https://gist.github.com/patrickallaert/a4789e0470ef96b0c383955357fdc4c8 8.1.25 should be expected in 2 weeks, i.e., on October 26, 2023. Thank you, and happy testing! Regards, Patrick Allaert, Ben Ramsey, &

Re: [PHP-DEV] Two new functions array_first() and array_last()

> On Oct 14, 2023, at 16:30, Nikita Popov wrote: > > On Sat, Oct 14, 2023, at 20:00, David Grudl wrote: >> PHP lacks two very basic functions for working with arrays: >> >> - array_first() returning the first element of an array (or null) >> - array_last() returning the last element of the arra

[PHP-DEV] PHP 8.1.26RC1 Available for testing

://github.com/php/php-src/issues Hash values and PGP signatures can be found below or at: https://gist.github.com/ramsey/7e9bd236653d018fa49c9fe4a72b7ff5 8.1.26 should be expected in 2 weeks, i.e., on November 23, 2023. Thank you, and happy testing! Regards, Ben Ramsey, Patrick Allaert, & Joe Watkins

[PHP-DEV] PHP-8.1 closed for bug fixes, security fixes only

Hi, all! According to the supported versions page[^1] (and our release process documentation), active support for PHP-8.1 ends on 25 Nov 2023. Since our release cycle has a release falling on 23 Nov, this means PHP 8.1.26 is the last bug-fix release for the 8.1 series. Following PHP 8.1.26, PHP

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

> On Nov 15, 2023, at 11:25, Jorg Sowa wrote: > > Hello internals! > I have just opened voting on the RFC to add 4 new rounding modes to round() > function. > > Voting will end November 30th, 00:00 GMT. > > Link: > https://wiki.php.net/rfc/new_rounding_modes_to_round_function > > Kind regards,

[PHP-DEV] PHP-8.1 open for bug fixes UNTIL 25 Nov

NB: this is a reply to the other thread, with the subject changed. On 11/10/23 13:57, Ben Ramsey wrote: Hi, all! According to the supported versions page[^1] (and our release process documentation), active support for PHP-8.1 ends on 25 Nov 2023. Since our release cycle has a release

Re: [PHP-DEV] PHP-8.1 open for bug fixes UNTIL 25 Nov

> On Nov 21, 2023, at 18:22, G. P. B. wrote: > > On Tue, 21 Nov 2023 at 21:10, Ben Ramsey <mailto:ram...@php.net>> wrote: >> We’ve discussed this among release managers, and I’m updating this >> thread to clarify that I was mistaken about what the dates for supp

Re: [PHP-DEV] PHP-8.1 open for bug fixes UNTIL 25 Nov

On 11/21/23 20:17, Ben Ramsey wrote: On Nov 21, 2023, at 18:22, G. P. B. wrote: On Tue, 21 Nov 2023 at 21:10, Ben Ramsey mailto:ram...@php.net>> wrote: We’ve discussed this among release managers, and I’m updating this thread to clarify that I was mistaken about what the dates for sup

[PHP-DEV] PHP 8.1.26 Released!

8.php#8.1.26> Release Manifest: <https://gist.github.com/ramsey/0e2c93a8e68def20566632bd9d721ac7> Many thanks to all the contributors and supporters! Ben Ramsey, Patrick Allaert, & Joe Watkins php-8.1.26.tar.bz2 SHA256 hash: 83bde249c84aa1a043a8c8d0eea09345c2cae69b9784cdf02229fc916fbb9

Re: [PHP-DEV] Adding a donate link to the PHP website

> On Nov 30, 2023, at 02:45, Andreas Heigl wrote: > > On 30.11.23 09:39, James Titcumb wrote: >> On Thu, 30 Nov 2023 at 07:28, Andreas Heigl > > wrote: > [...snip...] >>I suppose that is actually nothing that an RFC can do as I imagine that >>everyone from the PH

Re: [PHP-DEV] Proposal: Arbitrary precision native scalar type

> On Dec 7, 2023, at 00:36, Alex Pravdin wrote: > > Hello internals, > > > This is the second round of the discussion regarding arbitrary precision > scalar type integration into PHP. The previous part: > https://marc.info/?l=php-internals&m=168250492216838&w=2 was initiated by me > before d

[PHP-DEV] Re: PHP-8.0 End of Life

On 1/8/24 05:16, Gabriel Caruso wrote: Hi, all! According to the Supported Versions page (https://php.net/supported-versions) (and our release process documentation), active support for PHP-8.0 ended on Jan 1st 2024. This means PHP 8.0.30 was the last security-fix release for the 8.0 series. A

[PHP-DEV] Re: [RFC][Discussion] Raising zero to the power of negative number

On 1/11/24 15:29, Jorg Sowa wrote: Hello everyone! I want to start the discussion on the RFC: Raising zero to the power of negative number Link: https://wiki.php.net/rfc/raising_zero_to_power_of_negative_number Kind regards, Jorg In Python, the error message for `0 ** -1` is: ZeroDivis

Re: [PHP-DEV] [RFC][Discussion] Raising zero to the power of negative number

On 1/11/24 15:47, tag Knife wrote: On Thu, 11 Jan 2024 at 21:29, Jorg Sowa wrote: Hello everyone! I want to start the discussion on the RFC: Raising zero to the power of negative number Link: https://wiki.php.net/rfc/raising_zero_to_power_of_negative_number Kind regards, Jorg IEEE 754

Re: [PHP-DEV] [External] : Re: [PHP-DEV] VCS Account Request: sharadchan87

> I wanted to invite Christopher too (cc-ed), but I don't have his GitHub > username, and I can't find it anywhere. This is Christopher: https://github.com/cjbj Cheers, Ben signature.asc Description: Message signed with OpenPGP

Re: [PHP-DEV] Consider removing autogenerated files from tarballs

On Mar 29, 2024, at 20:20, Bob Weinand wrote: On 29.3.2024 23:31:26, Daniil Gentili wrote: In light of the recent supply chain attack in xz/lzma, leading to a backdoor in openSSH (https://www.openwall.com/lists/oss-security/20

Re: [PHP-DEV] Consider removing autogenerated files from tarballs

On Mar 30, 2024, at 07:03, Jakub Zelenka wrote:Hi,On Sat, Mar 30, 2024 at 7:08 AM Marco Pivetta <ocram...@gmail.com> wrote:On Sat, 30 Mar 2024, 05:19 Ben Ramsey, <b...@benramsey.com> wrote:On Mar 29, 2024, at 20:20, Bob Weinand <bobw...@hotmail.com> wrote: On

Re: [PHP-DEV] Consider removing autogenerated files from tarballs

> On Mar 31, 2024, at 11:08, Robert Landers wrote: > > There are probably multiple parties that require trust: the people > hosting the CI servers, the people with access to the CI servers, the > RM, and maybe more that I can't think of right now. > > One option would be to have > > - CI push t

[PHP-DEV] PHP 8.1.28 Released!

-8.1> Changelog:<https://php.net/ChangeLog-8.php#8.1.28> Release Manifest: <https://gist.github.com/ramsey/7fd8a20ab29953016bc790f0a9622d72> Many thanks to all the contributors and supporters! Ben Ramsey, Patrick Allaert, & Joe Watkins

Re: [PHP-DEV] Revisiting case-sensitivity in PHP

> On Jun 10, 2024, at 20:35, Valentin Udaltsov > wrote: > > Hi, internals! > > 9 years have passed since the last discussions of case sensitive PHP: > https://externals.io/message/79824 and https://externals.io/message/83640. > Here I would like to revisit this topic. > > What is case-sensiti

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

> On Jun 28, 2024, at 15:09, Máté Kocsis wrote: > >  > Hi Everyone, > > I've been working on a new RFC for a while now, and time has come to present > it to a wider audience. > > Last year, I learnt that PHP doesn't have built-in support for parsing URLs > according to any well established s

Re: [PHP-DEV] [RFC] Make the GMP class final

> On Jun 28, 2024, at 18:53, Gina P. Banyard wrote: > > Hello internals, > > I would like to present an RFC to make the GMP class final: > https://wiki.php.net/rfc/gmp-final > > This is short and to the point, and I intend to open voting for this after > the mandatory discussion period of 2 we

Re: [PHP-DEV] [RFC] Operator Overrides -- Lite Edition

> On Jun 29, 2024, at 10:16, Larry Garfield wrote: > > For clarity (since I know from experience it's helpful to RFC authors to have > a concrete sense of votes in advance): I will be voting No on this RFC. As > both Jordan and Saki have explained, it's a hideous hack that doesn't look > like

Re: [PHP-DEV] [RFC] Make the GMP class final

> On Jun 29, 2024, at 03:11, Rob Landers wrote: > > On Sat, Jun 29, 2024, at 03:05, Ben Ramsey wrote: >> > On Jun 28, 2024, at 18:53, Gina P. Banyard wrote: >> > >> > Hello internals, >> > >> > I would like to present an RFC to make the GM

Re: [PHP-DEV] [RFC] Make the GMP class final

> On Jun 29, 2024, at 12:01, Barney Laurance wrote: > > On 29/06/2024 16:55, Ben Ramsey wrote: >> If this RFC passes to make the \GMP class final, and your RFC passes to >> allow extending the \GMP class, then I think we’re in a sort of weird >> limbo state. > Pre

Re: [PHP-DEV] [RFC] Make the GMP class final

> On Jun 29, 2024, at 12:25, Saki Takamachi wrote: > > Hi, > >> Sure, it’s allowed to change its mind, but if we bring this for a vote in >> two weeks, and then we vote a week later for the other (or even at the same >> time), I would see the results of those votes as conflicting viewpoints an

  1   2   3   4   >