[PHP-DEV] Subject Prefixes

[Derick Rethans]

Hi!

I've noticed that lately, people are adding a [Discussion] prefix to new 
threads to this list. That seems rather superfluous, as this is a 
*discussion* mailing list.

RFCs require us to use [RFC] and [Vote] to stand out, but please let us 
proliferate additional ones.

The normal subject text should be enough.

This is more useful where display space (like on phones) is small, so 
the subject is more easily seen.

cheers,
Derick

Re: [PHP-DEV] Stricter requirements for libxml

[Derick Rethans]

On Fri, 10 May 2024, Niels Dossche wrote:

> Hi internals
> 
> Libxml is used as the underlying library for many PHP extensions.
> Interestingly, libxml can be built with supports for various features 
> disabled.
> E.g. you can build libxml without XPath, Schemas, HTML, ... support.
> In that case, these features are unavailable in PHP. E.g. some classes may 
> not be defined or functions may emit a warning instead of performing an 
> action.
> 
> I'm thinking of proposing an RFC that puts stricter requirements on libxml at 
> build time.
> That would make such features a requirement during PHP's build process.
> This will simplify maintenance and will also make sure that users can rely on 
> these functionalities to always be available.
> 
> Please let me know what you think.

That seems sensible. Did you find any Linux distribution that actively 
disables these features, or is this a "just in case" kind of change?

cheers,
Derick

Re: [PHP-DEV] [RFC] [vote] Support object type in BCMath

[Derick Rethans]

On Tue, 7 May 2024, Gina P. Banyard wrote:

> On Tuesday, 7 May 2024 at 15:46, Saki Takamachi  wrote:
> 
> > On Tue, 7 May 2024, Gina P. Banyard wrote:
> >
> > > - Are the existing BCMath function going to be adapted to handle 
> > > the new Number object or not?
> > 
> > No, that is not considered at this time.
> 
> I am struggling to see a reason for not considering this.

I think that would cause confusion, as BCMath/Number objects do not work 
with the global define scale (for good reasons) and bcmath* functions 
do.

I think I am in favour of a clean "break" here.

cheers,
Derick

Re: [PHP-DEV] [RFC][Discussion] PDO driver specific parsers

[Derick Rethans]

On Thu, 9 May 2024, Matteo Beccati wrote:

> Il 03/05/2024 11:14, Matteo Beccati ha scritto:
> > 
> > I've updated once again the RFC and implemented most of the 3 major 
> > dialects (mysql, pgsql, sqlite) in the drivers.
> > 
> > https://wiki.php.net/rfc/pdo_driver_specific_parsers
> > 
> > https://github.com/php/php-src/pull/14035
> > 
> > I've tried to keep syntax changes we might not want as separate commits in
> > the PR.
> > 
> > For example:
> >   - the pdo_pgsql driver now also understands C-style escape strings and
> > dollar quoted strings.
> >   - pdo_sqlite supports Access-style [identifiers].
> >   - pdo_mysql will consider "--" a comment only when followed by whitespace.
> > 
> > The latter has been a particular challenge for me and I've been able to
> > overcome it by using the re2c:eof feature, which I then discovered being
> > available only in a later version compared to our requirements (1.2.1,
> > released Aug 2019). As is, the Windows build fails on GH because the sdk
> > ships with 1.1.1.
> > 
> > Perhaps someone with better re2c knowledge can get it working with re2c
> > 1.0.3+, or perhaps it's not really worth it.
> > 
> > Looking forward to hearing from you!
> 
> I didn't see this sparking up discussion, so it either went unnoticed, or
> everybody is fine with it (even the re2c version bump) ;-)

I left a comment about that:
https://github.com/php/php-src/pull/14035#pullrequestreview-2047992559

> In any case I'm planning to start the vote in about 2 weeks from now. 
> Next week I'll be organising phpday in Verona, so feel free to 
> approach me if you are around and have any questions.
> 
> I might even try go get out of my comfort zone and do a lightning talk 
> on the topic. That would be a first in 20+ years of conference 
> organisation... we'll see!

That'd be handy. I'll see you there :-)

cheers,
Derick

Re: [PHP-DEV] [RFC] Transform exit() from a language construct into a standard function

[Derick Rethans]

On Thu, 9 May 2024, Flávio Heleno wrote:

> On Thu, May 9, 2024 at 7:51 AM Niels Dossche 
> wrote:
> 
> > On 08/05/2024 15:40, Gina P. Banyard wrote:
> > > Hello Internals,
> > >
> > > I would like to formally propose my idea for exit() as a function 
> > > brought up to the list on 2024-02-24 [1] with the following RFC: 
> > > https://wiki.php.net/rfc/exit-as-function
> > >
> > > There have been some slight tweaks to the implementation, namely 
> > > that the transformation from a "constant" to a function is done at 
> > > compile time and we do not hook into the behaviour of constants 
> > > any longer.
> > >
> > > Let me know what you think.
> >
> > Thanks for proposing this, I'm in favor of this change because this 
> > creates more consistency.
> 
> Is there a list of other "functions" that are handled as "constants"?

I don't think there are any other "functions" like this.

That's why removing the special case for "exit" and "die" is a good 
idea.

cheers,
Derick

Re: [PHP-DEV] Inconsistencies between parameter number and index when reflecting a method/function

[Derick Rethans]

On Fri, 3 May 2024, Gina P. Banyard wrote:

> On Thursday, 2 May 2024 at 21:33, Derick Rethans  wrote:
> 
> > On 2 May 2024 13:48:36 BST, Ollie Read php@ollie.codes wrote:
> > 
> > > These methods accept an integer to retrieve a parameter by its 
> > > position, or a string to retrieve by its name. So far, I have 
> > > built this so that if you required the first parameter, it's 
> > > parameter 0. I treat it this way because the only other place 
> > > where we deal with parameter indexes, is 
> > > ReflectionFunctionAbstract::getParameters() which returns the 
> > > parameters zero-indexed.
> > > 
> > > The question that is holding this PR back is should these methods 
> > > be 1 indexed, so that the provided position is consistent with the 
> > > error messages, or how a person would typically count, or should 
> > > they be 0 indexed to remain consistent with the existing API.
> > 
> > 0-indexed, as that's what PHP does everywhere else.
> 
> Well not really, if you have an error (TypeError or ValueError) which 
> indicate what parameter is the problem, it will be 1-indexed.

Which *API* in PHP is 1-indexed?

cheers,
Derick

Re: [PHP-DEV] Inconsistencies between parameter number and index when reflecting a method/function

[Derick Rethans]

On 2 May 2024 13:48:36 BST, Ollie Read  wrote:

>These methods accept an integer to retrieve a parameter by its position, or a 
>string to retrieve by its name. So far, I have built this so that if you 
>required the first parameter, it's parameter 0. I treat it this way because 
>the only other place where we deal with parameter indexes, is 
>ReflectionFunctionAbstract::getParameters() which returns the parameters 
>zero-indexed.
>
>The question that is holding this PR back is should these methods be 1 
>indexed, so that the provided position is consistent with the error messages, 
>or how a person would typically count, or should they be 0 indexed to remain 
>consistent with the existing API.

0-indexed, as that's what PHP does everywhere else. 

cheers
Derick 

[PHP-DEV] [RFC] [VOTE] Release cycle update

[Derick Rethans]

Hi,

the voting for the "Release cycle update" RFC 
(https://wiki.php.net/rfc/release_cycle_update#proposed_voting_choices) 
has now ended.

Each provision has been accepted:

Allow features that do not require an RFC in the beta period:
34 yes - 0 no

Disallow New Features in Release Candidates and Bug Fix releases 
32 yes - 0 no

Reduce number of RCs to Four 
30 yes - 3 no

Extend Security Support by One Year
31 yes - 0 no

Allowing recent regression fixes during security support
30 yes - 0 no

Extend Releases Cycle to End of Year
33 yes - 0 no

Thanks for voting!

I'll update the relevant policy documents shortly.

cheers,
Derick

-- 
https://derickrethans.nl | https://xdebug.org | https://dram.io

Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support

mastodon: @derickr@phpc.social @xdebug@phpc.social

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

[Derick Rethans]

On Fri, 5 Apr 2024, Tim Düsterhus wrote:

> Hi
> 
> I've just written up the follow-up RFC to my previous “Casing of acronyms in
> class and method names” thread and I'm officially opening up the discussion
> period for it.

One example is the PCGOneseq128XSLRR64 mentioned above

That is probably not the best example of a "readable" class name, as no 
matter the casing, it's not readable :-)

None, yet. This RFC will result in changes to: 

The 
https://github.com/php/php-src/blob/536305436f44e91731bc5c86e06f137e44a01109/CODING_STANDARDS.md#L173-L211
 
document should probably be folded into 
https://github.com/php/policies/blob/main/coding-standards-and-naming.rst 
— having it in two places isn't great.

cheers,
Derick

-- 
https://derickrethans.nl | https://xdebug.org | https://dram.io

Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support

mastodon: @derickr@phpc.social @xdebug@phpc.social

Re: [PHP-DEV] Incorrect terminology usage for rounding modes of round()

[Derick Rethans]

On 14 April 2024 16:55:43 BST, Saki Takamachi  wrote:
>Hi Gina,
>
>> Hello internals,
>> 
>> While reviewing the PR for the "Adding bcround, bcfloor and bcceil to 
>> BCMath" RFC [1] with the different rounding modes,
>> I was made aware of the unfortunate wrong terminology usage of 
>> PHP_ROUND_HALF_UP and PHP_ROUND_HALF_DOWN.
>> 
>> Indeed, PHP_ROUND_HALF_UP is implemented as "rounding half away from zero" 
>> and not "rounding half up" (which is also called rounding toward positive 
>> infinity).
>> The behaviour for positive numbers is the same, however for negative numbers 
>> the rounding *is* different.
>> In the same vein, PHP_ROUND_HALD_DOWN is implemented as "rounding half 
>> toward zero" and not "rounding half down" (/round half toward negative 
>> infinity).
>> 
>> Taking -1.5 as our number:
>> - Rounding half-up: -1
>> - Rounding half away from zero: -2
>> - Rounding half-down: -2
>> - Rounding half towards zero: -1
>> 
>> For a detailed explanation about rounding, the Wikipedia page is of great 
>> use. [2]
>> And the following rounding calculator on Calculator Soup is useful to check 
>> the differences and behaviour of different rounding modes. [3]
>> 
>> It should be noted that PHP is in good company about being wrong about those 
>> two rounding modes, Java, Python, and Ruby (and probably others) are also 
>> wrong in this regard.
>> 
>> Considering that PHP 8.4 is also adding new rounding modes via the "Add 4 
>> new rounding modes to round() function" RFC [4] attempting to solve this 
>> issue in this next version of PHP seems like a good idea.
>> In my discussions with Saki about this issue, it seems that her and Tim have 
>> thought about creating a new enum for rounding modes, looking something like 
>> this:
>> 
>> enum RoundingMode {
>>case HalfAwayFromZero;
>>case HalfTowardsZero;
>>case HalfEven;
>>case HalfOdd;
>>case TowardsZero;
>>case AwayFromZero;
>>case NegativeInfinity; // or case Floor;
>>case PositiveInfinity; // or case Ceiling;
>> }
>> 
>> and change the signature of round from:
>> round(int|float $num, int $precision = 0, int $mode = PHP_ROUND_HALF_UP): 
>> float
>> to
>> round(int|float $num, int $precision = 0, RoundingMode $mode = 
>> RoundingMode::HalfAwayFromZero): float
>> 
>> and changing the definition of the existing constants to effectively be:
>> define('PHP_ROUND_HALF_UP', RoundingMode::HalfAwayFromZero);
>> define('PHP_ROUND_HALF_DOWN', RoundingMode::HalfTowardsZero);
>> define('PHP_ROUND_HALF_EVEN', RoundingMode::HalfEven);
>> define('PHP_ROUND_HALF_ODD', RoundingMode::HalfOdd);
>> 
>> This should not cause any BC breaks, while allowing us to potentially 
>> implement the half up/down rounding modes properly, and deprecate the 
>> existing rounding constants in the future to get rid of the confusing names.
>> 
>> I wanted to know if anyone has any object to introducing this new enum and 
>> signature change.
>> The only thing I could think of is if this enum should be in a new Maths (or 
>> Math or just Mathematics to not need to deal with regional difference in the 
>> short spelling of "Mathematics") namespace.
>> 
>> Best regards,
>> 
>> Gina P. Banyard
>> 
>> [1] https://wiki.php.net/rfc/adding_bcround_bcfloor_bcceil_to_bcmath
>> [2] https://en.wikipedia.org/wiki/Rounding
>> [3] 
>> https://www.calculatorsoup.com/calculators/math/rounding-methods-calculator.php
>> [4] https://wiki.php.net/rfc/new_rounding_modes_to_round_function
>
>In my discussions with Tim, I want to make it clear that all ideas derived are 
>Tim's. :)
>
>Now, of course I agree with this, and agree with using namespaces. However, if 
>didn't use namespaces, that's fine by me. For reference, we found 
>approximately 100 pieces of code using the namespace `Math` on Github Code 
>Search. There are only a few cases for `Maths` and 0 for `Mathematics`.
>
>Regards,
>
>Saki

Math is American English spelling, Maths/Mathematics the British English one.

As we also have color (and not the "correct" colour), going with the American 
spelling seems better. 

But I would query whether we actually need it in a namespace. 

cheers
Derick

Re: [PHP-DEV] Requiring GPG Commit Signing

[Derick Rethans]

On Tue, 2 Apr 2024, Derick Rethans wrote:

> What do y'all think about requiring GPG signed commits for the php-src 
> repository?
> 
> I had a look, and this is also something we can enforce through GitHub 
> as well (by using branch protections).

It seems that most of the reply to this was positive, although with the 
realisation that it wouldn't be a panacea.

I will therefore propose a minimalistic RFC to create this requirement 
to sign commits to all branches, in the next few days.

 I probably would have prefered requiring *GPG* signing (due to a web of 
trust), but GitHub's requirement isn't that granuar (it's either 
SSG+GPG, or nothing).

Any other opinions, I'd be delighted to hear them.

cheers,
Derick

-- 
https://derickrethans.nl | https://xdebug.org | https://dram.io

Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support

mastodon: @derickr@phpc.social @xdebug@phpc.social

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

[Derick Rethans]

On Wed, 3 Apr 2024, Jordan LeDoux wrote:

> On Mon, Mar 18, 2024 at 1:35 PM Rowan Tommins [IMSoP] 
> wrote:
> 
> >
> > Where things get more complicated is with *fixed-precision* decimals,
> > which is what is generally wanted for something like money. What is the
> > correct result of decimal(1.03, precision: 2) / 2 - decimal(0.515, 3)?
> > decimal(0.51, 2)? decimal (0.52, 2)? an error? And what about decimal(10) /
> > 3?
> >
> > If you stick to functions / methods, this is slightly less of an issue,
> > because you can have decimal(1.03, 2)->dividedBy(2, RoundingMode::DOWN) ==
> > decimal(0.51, 2); or decimal(1.03, 2)->split(2) == [ decimal(0.52, 2),
> > decimal(0.51, 2) ] Example names taken directly from the brick/money
> > package.
> >
> > At that point, backwards compatibility is less of an issue as well: make
> > the new functions convenient to use, but distinct from the existing ones
> >
> I came back to this discussion after my last reply on the BCMath as an
> object thread, because we went through a very similar discussion there with
> regard to operators.
> 
> I think that, roughly, the fixed precision should be defined on the scalar
> itself:
> 
> 1.234_d3
> 
> 1.234 is the value, _d makes it a decimal type, and 3 shows that this value
> has a precision of 3. (Actually, it has a SCALE of 3, since precision is
> significant digits, and also includes the integer portion). But when it
> comes to fixed-precision values, it should follow rules very similar to
> those we discussed in the BCMath thread:

Woound't it be much better to capture this complex information in an 
Object, and then allow operators on this? Like... Saki was pretty much 
suggesting with her BCMatch/Number class RFC?

I can't imagine people looking at code understanding a syntax like this 
right away, let alone of what it all means.

cheers,
Derick

-- 
https://derickrethans.nl | https://xdebug.org | https://dram.io

Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support

mastodon: @derickr@phpc.social @xdebug@phpc.social

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

[Derick Rethans]

On Thu, 7 Dec 2023, Alex Pravdin wrote:

> Accounting for all of the above, I suggest adding a native numeric 
> scalar arbitrary precision type called "decimal". Below are the 
> preliminary requirements for implementation.

Adding a new native type to PHP will create a large change. Not only is 
it "just" adding a new native type, it also means all of the conversions 
between types need to be added. This is not a small task.

> Decimal values can be created from literals by specifying a modifier or using
> the (decimal) typecast:
> 
> $v = 0.2d;
> $v = (decimal) 0.2; // Creates a decimal value without intermediary float
> 
> It uses the precision and scale defined in php.ini.

If you want to use arbitrary precision natives, then a precision and 
scale as defined in php.ini defeats the purpose. Every installation can 
then potentially calculate things in a different way.

The only way how to prevent that, is to have *actual* Decimal type, such 
as the Decimal type in MongoDB uses (the IEEE 754 decimal128 type):

- 
https://www.mongodb.com/docs/mongodb-shell/reference/data-types/#std-label-shell-type-decimal
- https://en.wikipedia.org/wiki/Decimal128_floating-point_format

cheers,
Derick

-- 
https://derickrethans.nl | https://xdebug.org | https://dram.io

Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support

mastodon: @derickr@phpc.social @xdebug@phpc.social

[PHP-DEV] [VOTE] [RFC] Release cycle update, take #2

[Derick Rethans]

Hi,

there have been no further comments on the release cycle update RFC 
thread, so I'm hereby opening the RFC for voting.

Voting will end on Monday April 29th, at noon UTC (20 days, instead of 
the required minimum of 14):

https://wiki.php.net/rfc/release_cycle_update#proposed_voting_choices

cheers,
Derick


-- 
https://derickrethans.nl | https://xdebug.org | https://dram.io

Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support

mastodon: @derickr@phpc.social @xdebug@phpc.social

Re: [PHP-DEV] Proposal: retrieve line, filename and if user defined for ReflectionAttribute

[Derick Rethans]

On 5 April 2024 15:09:42 CEST, Joel Wurtz  wrote:
>Hello everyone,
>
>Like a lot of libraries, we offer the possibility to configure behaviors
>with Attributes. However in some cases it's wrongly configured by the user
>and this wrong configuration cannot be detected on the attribute
>constructor but afterwards.
>
>In this case we may want to pinpoint which attribute (in which file and at
>which line) cause this bad configuration. Since there was no method to
>retrieve those information in the ReflectionAttribute I proposed a PR
>https://github.com/php/php-src/pull/13889 to add those informations.
>
>I do believe this will allow better DX for end user when correctly used,

Would it make sense to not only add this for ReflectionAttribute, but also 
Function and/or others?

Functions have a range of lines associate with them. Could Attributes have that 
too?

cheers
Derick

Re: [PHP-DEV] Requiring GPG Commit Signing

[Derick Rethans]

On Tue, 2 Apr 2024, John Coggeshall wrote:

> 
> > So if we want to make sure that something like XY doesn't happen, we
> > have to add some additional restrictions to those GPG keys.
> 
> Looks like all those geeky colleagues of ours back in the day having 
> key-signing parties at conferences were on to something, maybe..

> Let's be clear about something -- having GPG key requirements isn't 
> going to help a situation like XZ. The XZ attack was done by an active 
> maintainer of the project (who arguably manipulated the original 
> maintainer of the project to become a maintainer themselves). It was 
> as much a social engineering attack as anything.

> Having GPG key requirements is all fine and dandy I suppose, but my 
> tongue-in-cheek comment above has a real point behind it: GPG keys 
> don't mean jack if you can't trust who owns the key.

GitHub doesn't show the web of trust anyway, just "verified". Command 
line GIT doesn't either, just:

$ git verify-commit HEAD~1
gpg: Signature made Tue 02 Apr 2024 14:55:21 BST
gpg:using RSA key 5A52880781F755608BF815FC910DEB46F53EA312
…
gpg: aka "Derick Rethans (GitHub) " 
[ultimate]
gpg: aka "Derick Rethans (PHP) " [ultimate]


cheers,
Derick

Re: [PHP-DEV] Requiring GPG Commit Signing

[Derick Rethans]

On Tue, 2 Apr 2024, Ayesh Karunaratne wrote:

> > What do y'all think about requiring GPG signed commits for the 
> > php-src repository?
> >
> > I had a look, and this is also something we can enforce through 
> > GitHub as well (by using branch protections).
> 
> +1 from me as well, and quite good timing with all the xz fiasco just 
> last week.
> 
> Git can also sign with SSH keys now, so this is now merely a config 
> update

The issue with SSH keys is that they can not be signed by others to form 
a "web of trust". For example, my key has been signed by several other 
people:

https://keyserver.ubuntu.com/pks/lookup?search=derick%40php.net=on=index

cheers,
Derick

Re: [PHP-DEV] First time contributor (DateTime::setDate PR)

[Derick Rethans]

On Tue, 2 Apr 2024, Bilge wrote:

> On 02/04/2024 14:14, Derick Rethans wrote:
> > 
> > On Sun, 31 Mar 2024, Bilge wrote:
> > 
> > > About the PR: I sometimes find it would be useful to only update 
> > > part of the date. The PR makes all parameters to 
> > > DateTime(Immutable)::setDate 
> > > <https://www.php.net/manual/en/datetimeimmutable.setdate.php> 
> > > optional in a backwards-compatible manner such that we can elect 
> > > to update only the day, month, year or any combination of the 
> > > three (thanks, in part, to named parameters). Without this 
> > > modification, we must always specify all of the day, month and 
> > > year parameters to change the date.
> > As I mentioned to you in Room 11, I am not in favour of adhoc API 
> > changes to Date/Time classes. It has now been nearly 18 years since 
> > they were originally introduced, and they indeed could do with an 
> > overhaul.
> > 
> > I have been colllecting ideas in 
> > https://docs.google.com/document/d/1pxPSRbfATKE4TFWw72K3p7ir-02YQbTf3S3SIxOKWsk/edit#heading=h.2jol7kfhmijb
> > 
> > Having different/better modifiers would also be a good thing to talk 
> > about, albeit perhaps on the four mentioned new classes, instead of 
> > adding them to the already existing DateTime and DateTimeImmutable 
> > classes.
> > 
> > In any case, just allowing setDate to be able to just modify the 
> > month is going to introduce confusion, as this will be counter 
> > intuitive:
> > 
> > $dt = new DateTimeImmutable("2024-03-31");
> > $newDt = $dt->setDate( month: 2 );
> > 
> > It is now representing 2024-03-02.
> > 
> > This might be the right answer, but it might also be that the 
> > developer just cared about the month part (and not the 
> > day-of-month), in which case this is a WTF moment.
> > 
> > Picking mofication APIs is not as trivial as it seems, and I would 
> > like to do it *right*.
> > 
> > Feel free to add comments and wishes to the google doc document. In 
> > the near future, I will be writing up an RFC from this.
> 
> Thanks for your reply!
> 
> Indeed, as per your code snippet, this is a WTF moment I had not accounted for
> and confirm the same result with my patch applied. Generally, my expectation
> here would be the month *must* be set to 2, so if the day portion will be
> invalidated by that change, we should either throw an exception or implicitly
> coerce it into range, i.e. (new DateTime("2024-03-31"))->setDate(month: 2); ==
> 2024-02-29.

We can't do that, as it will be inconsistent with:

modify("+1 month")
// (also 2024-03-02)

> However, I suppose this is not the conversation we're having as
> you do not wish to change this API at all, which I respect.

I think what you're actually after here, is a "YearMonth" type, which 
doesn't concern itself with the day-of-month at all. Setting just the 
month should perhaps just reset the day-of-month to 1 instead. ANd 
setting just the year would result in January 1st, as well.

> Regarding your brainstorm document, I can't understand much of it in its
> current state, and as I am not a subject matter expert, I think you will
> receive much better feedback from others.

It isn't particularly organised yet, and... I also haven't made sense of 
all of it yet.

> In particular, I cannot glean which four classes you are referring to 
> in that document. Yet what I do find interesting is the notion of 
> adding setters to DateTimeImmutable. For my particular 
> use-case—producing a collection of dates incrementing by year in a 
> Twig template—a trivial year setter would do just fine, with the 
> significant caveat that it must implement fluent interface, because I 
> need to call it in an expression context (returning a value), not a 
> statement context (executing a void function separately). Not that 
> Twig cannot execute statements, but it just becomes more verbose, 
> cumbersome and less template-like.
> 
> If you were happy for me to add getters and fluent setters for year, 
> I'd be happy to work on that PR, but for month we're back to the same 
> problem outlined in the opening paragraph (and I suppose the same 
> problem occasionally applies to year, if the day happens to be set to 
> the leap day). Otherwise, I'll be happy to read over your RFC when 
> it's ready.

Feel free to add your suggestion (anywhere) in the document, preferrably 
at the bottom :-)

I can envision that we'll have some actual setters and getters, beyond 
just add, sub, and modify (which is really powerful).

But what is important to understand is rather *why* a specific method is 
useful, and perhaps even more important is what you're actual goal is.

cheers,
Derick

-- 
https://derickrethans.nl | https://xdebug.org | https://dram.io

Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support

mastodon: @derickr@phpc.social @xdebug@phpc.social

Re: [PHP-DEV] Requiring GPG Commit Signing

[Derick Rethans]

On Tue, 2 Apr 2024, Calvin Buckley wrote:

> On Apr 2, 2024, at 11:15 AM, Derick Rethans  wrote:
> > 
> > What do y'all think about requiring GPG signed commits for the php-src 
> > repository?
> > 
> > I had a look, and this is also something we can enforce through GitHub 
> > as well (by using branch protections).
> 
> Would this affect only direct pushes to master, or would it be required
> for pull requests too? I'd be worried the average drive-by contributor
> wouldn't have GPG signing set up.

As Ayesh said, you can also use SSH for this now:
https://docs.github.com/en/authentication/managing-commit-signature-verification/about-commit-signature-verification#ssh-commit-signature-verification

I think it would apply to people merging the commits. But, I am not 100% 
sure (until we try, I suppose).

cheers,
Derick



-- 
https://derickrethans.nl | https://xdebug.org | https://dram.io

Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support

mastodon: @derickr@phpc.social @xdebug@phpc.social

[PHP-DEV] Requiring GPG Commit Signing

[Derick Rethans]

Hi,

What do y'all think about requiring GPG signed commits for the php-src 
repository?

I had a look, and this is also something we can enforce through GitHub 
as well (by using branch protections).

cheers,
Derick


-- 
https://derickrethans.nl | https://xdebug.org | https://dram.io

Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support

mastodon: @derickr@phpc.social @xdebug@phpc.social

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

[Derick Rethans]

On Sat, 30 Mar 2024, Jakub Zelenka wrote:

> On Sat, Mar 30, 2024 at 7:08 AM Marco Pivetta  wrote:
> >
> > I understand that the XZ project had signed releases too: that still 
> > means that downstream consumers would need to trust the release 
> > managers anyway, and reproduce the whole chain themselves.
> >
> > I suppose that's part of OP's concern.
> >
> I agree that compromised RM is a problem that we should look into.
> 
> We have been actually already discussing something similar. I have 
> been thinking about it and it could be potentially used for all 
> builds. The idea is that we would setup worklfow on CI that would run 
> on tag push and it would call (authenticated https request) 
> downloads.php.net server that could do the actual build, sign them and 
> return the hashes to the CI job which would display them and do extra 
> verification (probably its own build to verify that download server 
> work as expected).

...

> It needs more thinking to iron out all details and make sure it is a 
> secure but I think it would be something worth to look at.

I don't mind coming up with an automated way, but we probably should not 
use the *downloads* server. All it does is serve files. It has no 
compiler or anything else. It's a storage optimised instance with little 
CPU.

On CI we already test the builds, what does stop us from also just 
having it make the tarball and attach it as an artefact? We can then 
setup somethin gon the downloads server to pull these artefacts. In 
fact, this is exactly what we're already hoping to do for Windows 
downloads too. Having it all in one place is probably even better (and 
easier).

Of course, having CI make the tarballs means we need to trust that CI 
isn't compromised ;-).

cheers,
Derick

-- 
https://derickrethans.nl | https://xdebug.org | https://dram.io

Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support

mastodon: @derickr@phpc.social @xdebug@phpc.social

Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath

[Derick Rethans]

On Fri, 29 Mar 2024, Jordan LeDoux wrote:

> On Wed, Mar 27, 2024 at 12:08 AM Aleksander Machniak  wrote:
> 
> > On 27.03.2024 01:03, Saki Takamachi wrote:
> > >> $num = new BcNum('1.23', 2);
> > >> $result = $num + '1.23456';
> > >> $result->value; // '2.46456'
> > >> $result->scale; // ??
> > >
> > > In this case, `$result->scale` will be `'5'`. I added this to the 
> > > RFC.
> >
> > I'm not sure I like this. Maybe we should be more strict here and 
> > treat the $scale in constructor (and later withScale()) as the 
> > actual scale for all operations.
> >
> >
> For addition, it absolutely should expand scale like this, unless the 
> constructor also defines a default rounding type that is used in that 
> situation. All numbers, while arbitrary, will be finite, so addition 
> will always be exact and known based on inputs prior to calculation.
> 
> Treating scale like this isn't more strict, it's confusing. For 
> instance:
> 
> ```
> $numA = new Number('1.23', 2);
> $numB = new Number('1.23456', 5);
> 
> $expandedScale1 = $numA + $numB; // 2.46456
> $expandedScale2 = $numB + $numA; // 2.46456
> 
> $strictScale1 = $numA + $numB; // 2.46 assuming truncation
> $strictScale2 = $numB + $numA; // 2.46456
> ```
> 
> I ran into this same issue with operand ordering when I was writing my 
> operator overload RFC.
> 
> There are ways you could do the overload implementation that would get 
> around this for object + object operations, but it's also 
> mathematically unsound and probably unexpected for anyone who is going 
> to the trouble of using an arbitrary precision library.
> 
> Addition and subtraction should automatically use the largest scale 
> from all operands. Division and multiplication should require a 
> specified scale.

I agree. I think add/subtract also should always take the largest scale 
here.

cheers,
Derick

Re: [PHP-DEV] First time contributor (DateTime::setDate PR)

[Derick Rethans]

Hi,

On Sun, 31 Mar 2024, Bilge wrote:

> About the PR: I sometimes find it would be useful to only update part of the
> date. The PR makes all parameters to DateTime(Immutable)::setDate
>  optional in a
> backwards-compatible manner such that we can elect to update only the day,
> month, year or any combination of the three (thanks, in part, to named
> parameters). Without this modification, we must always specify all of the day,
> month and year parameters to change the date.

As I mentioned to you in Room 11, I am not in favour of adhoc API 
changes to Date/Time classes. It has now been nearly 18 years since they 
were originally introduced, and they indeed could do with an overhaul.

I have been colllecting ideas in 
https://docs.google.com/document/d/1pxPSRbfATKE4TFWw72K3p7ir-02YQbTf3S3SIxOKWsk/edit#heading=h.2jol7kfhmijb

Having different/better modifiers would also be a good thing to talk 
about, albeit perhaps on the four mentioned new classes, instead of 
adding them to the already existing DateTime and DateTimeImmutable 
classes.

In any case, just allowing setDate to be able to just modify the month 
is going to introduce confusion, as this will be counter intuitive:

$dt = new DateTimeImmutable("2024-03-31");
$newDt = $dt->setDate( month: 2 );

It is now representing 2024-03-02.

This might be the right answer, but it might also be that the developer 
just cared about the month part (and not the day-of-month), in which 
case this is a WTF moment.

Picking mofication APIs is not as trivial as it seems, and I would like 
to do it *right*.

Feel free to add comments and wishes to the google doc document. In the 
near future, I will be writing up an RFC from this.

cheers,
Derick

-- 
https://derickrethans.nl | https://xdebug.org | https://dram.io

Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support

mastodon: @derickr@phpc.social @xdebug@phpc.social

Re: [PHP-DEV] [RFC] Release cycle update, take #2

[Derick Rethans]

On Fri, 22 Mar 2024, Morgan wrote:

> On 2024-03-22 08:19, Jim Winstead wrote:
> > On Thu, Mar 21, 2024, at 10:54 AM, Derick Rethans wrote:
> > > 
> > > The RFC is at https://wiki.php.net/rfc/release_cycle_update
> > 
> > Could this RFC also be a good time to clarify what sort of BC changes are
> > actually allowed in major and minor releases, or should we save that for a
> > different RFC? (Because it's already been acknowledged that the current
> > written policy doesn't align with the practiced policy, and I think it would
> > be nice to get those in sync.)
> > 
> If so, would it also good time/place to clarify how deprecation relates to
> future removal. Say, while deprecations could come in any minor release, they
> would be removed only after a full major version has elapsed (something
> deprecated in 8.x would be removed in 10.0; technically that would mean a
> deprecation in 9.0.0 would also mean removal in 10.0). It would allow using
> the overall release cycle to forecast when something you're currently relying
> on will go away and plan accordingly.

The current "rule" is that we can remove deprecated features in any 
x.0.0 release 
(https://github.com/php/policies/blob/main/release-process.rst#releases-cycle).

I am not proposing to change that with this RFC.

cheers,
Derick

-- 
https://derickrethans.nl | https://xdebug.org | https://dram.io

Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support

mastodon: @derickr@phpc.social @xdebug@phpc.social

Re: [PHP-DEV] [RFC] Release cycle update, take #2

[Derick Rethans]

On Thu, 21 Mar 2024, Jim Winstead wrote:

> On Thu, Mar 21, 2024, at 10:54 AM, Derick Rethans wrote:
> > Hi!
> >
> > On Fri, 10 Nov 2023, Jakub Zelenka wrote:
> >
> >> I would like to propose a new process RFC for updates to PHP release 
> >> cycle:
> >> 
> >> https://wiki.php.net/rfc/release_cycle_update
> >
> > I have just published version 0.2 of this proposal — I am taken this 
> > over from Jakub by agreement.
> >
> > I've slightly reordered it, addressed some comments from this thread, 
> > and added one new item: aligning the end of releases until Dec 31st, 
> > 20xx.
> >
> > Now that we have policy documents, my next step is to prepare PRs to 
> > https://github.com/php/policies/blob/main/feature-proposals.rst for each 
> > item, after a more general reset of the document to reflect current 
> > practises.
> >
> > The RFC is at https://wiki.php.net/rfc/release_cycle_update
> 
> Could this RFC also be a good time to clarify what sort of BC changes 
> are actually allowed in major and minor releases, or should we save 
> that for a different RFC? (Because it's already been acknowledged that 
> the current written policy doesn't align with the practiced policy, 
> and I think it would be nice to get those in sync.)

I'm planning in doing a rewrite of the whole policy document on releases 
(https://github.com/php/policies/blob/main/release-process.rst) and then 
RFCing the changes. That document also contains as to what a bug fix is.

cheers,
Derick

-- 
https://derickrethans.nl | https://xdebug.org | https://dram.io

Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support

mastodon: @derickr@phpc.social @xdebug@phpc.social

Re: [PHP-DEV] [RFC] Release cycle update, take #2

[Derick Rethans]

On Thu, 21 Mar 2024, Daniil Gentili wrote:

> >> I would like to propose a new process RFC for updates to PHP release
> >> cycle:
> >>
> >> https://wiki.php.net/rfc/release_cycle_update
> 
> I would also like to propose an addition, allowing patch releases to 
> be made outside of the normal release schedule if a major core feature 
> is broken by a fix in the previous patch release.
> 
> These out-of-schedule releases should only contain a clean revert of 
> the fix that broke the major core feature.
> 
> I believe the "major core feature" set should include at least the 
> garbage collector and string functions, it may be extended if needed.
> 
> I'm advocating for this change due to the fact that critical garbage 
> collector bugs were introduced and released at least twice in the last 
> year:
> 
> - First with a GC patch that completely broke garbage collection 
>   causing segfaults if fibers are used 
>   (https://github.com/php/php-src/pull/9810)
> - And then with a GC patch 
>   that broke garbage collection causing segfaults when using weakmaps 
>   (https://github.com/php/php-src/pull/10932)
> 
> Specifically regarding the first bug, the fix for it was actually 
> delayed by 30 days, instead of 15 (the time left until the next 
> release, when the fix PR was merged), as a security release was made 
> the day after the fix was merged, delaying the entire release cycle by 
> 30 days.

Security releases have no impact on this.

> I believe that bugs in major core features, introduced by fix PRs 
> should be reverted ASAP, especially if they aren't noticed until a 
> release, instead of breaking a core feature of the language for one 
> month (or more if a security release delays the normal release cycle).

I find this out of the scope of this RFC. I also believe that this is 
not a common occurence.

 
> Also in general, I find it wrong that security releases should delay 
> the normal cycle.

They don't? A security release is just a label in addition to a "normal" 
release, in case there are bug fixes that warrant us calling them 
security issues.

cheers,
Derick

-- 
https://derickrethans.nl | https://xdebug.org | https://dram.io

Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support

mastodon: @derickr@phpc.social @xdebug@phpc.social

Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath

[Derick Rethans]

On Wed, 27 Mar 2024, Saki Takamachi wrote:

> > - You've picked as class name "BcNum". Following
> >  our naming guidelines, that probably should be \BCMath\Num (or 
> >  \BC\Num, but that is less descriptive): 
> >  
> > https://github.com/php/policies/blob/main/coding-standards-and-naming.rst#namespaces-in-extensions
> > 
> >  The reason it *should* have "BC" is that it comes from "Basic 
> >  Calculator" (https://www.php.net/manual/en/book.bc.php#118203)
> 
> 
> I re-read the namespace RFC again. I also re-read the RFC regarding 
> class naming conventions. 
> https://wiki.php.net/rfc/namespaces_in_bundled_extensions 
> https://wiki.php.net/rfc/class-naming
> 
> There's no need for the namespace to follow class naming conventions, 
> but the acronym doesn't seem to need to be pascal-case anyway (I 
> remembered it incorrectly). However, the RFC states that the 
> extension's namespace must match the extension name, so it seems 
> correct in this case for the namespace to be `BCMath`.
> 
> And indeed, looking at the example in the namespace RFC, 
> `BCMath\Number` might be appropriate in this case (I think I was 
> sleepy yesterday).
> 
> I changed `BcNum` to `BCMath\Number` in my RFC.

That works fine as well. Especially as most people would add:

use BCMath\Number as Number;

and then just use "Number" everywhere.

> > - Should ->value rather be ->toString() ? ->value alone doesn't 
> > really
> >  say much. I'm on the fence here though, as there is already 
> >  (internally) a ->__toString() method to make the (string) cast 
> >  work.
> 
> What is the main difference between getting a read-only property with 
> `->value` and getting the value using a method?

Feeling :-) Do we have precedence with other extension's objects 
perhaps already?

> > - Would it make sense to have "floor" and "ceil" to also have a scale, 
> >  or precision? Or would developers instead have to use "round" in 
> >  that case?
> 
> > - Which rounding modes are supported with "round", the same ones as 
> > the
> >  normal round() function?
> 
> `bcfloor` and `bcceil` originally have no scale specification. This is 
> because the result is always a string representing an integer value. 
> And since the supported round-mode is the same as standard-round, 
> `ROUND_FLOOR` and `ROUND_CEILING` are also supported. Therefore, if 
> want to obtain floor or ceil behavior with a specified scale, I 
> recommend specifying the mode as round.

OK. That makes sense.

> > - In this example, what would $result->scale show? (Perhaps add that to 
> >  the example?):
> > 
> >  > $num = new BcNum('1.23', 2);
> > $result = $num + '1.23456';
> > $result->value; // '2.46456'
> > $result->scale; // ??
> 
> In this case, `$result->scale` will be `'5'`. I added this to the RFC.

Great. 

> > - Exceptions
> > 
> >  The RFC does not mention which exceptions can be thrown. Is it just 
> >  the one? It might be beneficial to *do* have a new exception 
> >  hierarchy.
> 
> 
> As far as I know right now, following exceptions can be thrown:
> 
> - Value error when a string that is invalid as a number is used in a 
>   constructor, calculation method, or operation
> - Divide by 0 error (include Modulo by zero)
> 
> I was thinking that it would be a bad idea to increase the number of 
> classes without thinking, and was planning to use general exceptions, 
> but would it be better to use dedicated exceptions?

It's what we did for the Date extension, and the Random extension, but 
in this case, it's probably not needed as you say.

> By the way, generally when implementing such exceptions in userland, 
> value errors and divide-by-zero errors are probably defined as 
> separate classes, but should they be separated in this case?

For that, yes. ValueErrors should be distinct from DivideByZeroError — I 
think we do have both of those already:

php -r 'echo 8/0;'

Fatal error: Uncaught DivisionByZeroError: Division by zero in Command 
line code on line 1

From the docs for ValueError:

"A ValueError is thrown when the type of an argument is correct but the 
value of it is incorrect."

From the docs for DivisionByZeroError:

" DivisionByZeroError is thrown when an attempt is made to divide a 
number by zero. "

Subclassing these for BCMath objects seems unnecessary therefore.

cheers,
Derick

-- 
https://derickrethans.nl | https://xdebug.org | https://dram.io

Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support

mastodon: @derickr@phpc.social @xdebug@phpc.social

Re: [PHP-DEV][RFC] grapheme cluster for str_split, grapheme_str_split function

[Derick Rethans]

On 27 March 2024 23:18:21 GMT, "Rowan Tommins [IMSoP]"  
wrote:
>On 26/03/2024 21:14, Casper Langemeijer wrote:
>> If you need someone to help for the grapheme_ marketing team, let me know.
>
>I think a big part of the problem is that very few people dig into the 
>complexities of text encoding, and so don't know that a "grapheme" is what 
>they're looking for.
>
>Unicode documentation is, generally, very careful with its terminology - 
>distinguishing between "code points", "code units" "graphemes" , "grapheme 
>clusters", "glyphs", etc. Pretty much everyone else just says "character", and 
>assumes that everyone knows what they mean.

That's why I have been working on 


Takes all the (or most) terminology out of it. 

It's time to resurrect it. 

cheers 
Derick 

Re: [PHP-DEV][RFC] grapheme cluster for str_split, grapheme_str_split function

[Derick Rethans]

On 26 March 2024 17:04:18 GMT, Casper Langemeijer  wrote:
>I'd like to address an issue I have with this RFC.

Please don't top reply. 

>I'm not sure is solves a problem by itself. If I understand all of this 
>correctly this only does what already can be accomplished with 
>preg_match_all('/\X/u', ...). The result of this method in my opinion is not 
>very usefull by itself. I've done some searching on various code platforms 
>where I mostly find the use-case for counting the number of grapheme's. I've 
>used it to implement strrev() that correctly works multibyte. 
>
>I'm very sad that mbstring works on codepoints instead of grapheme's and I 
>would very much like to see something happening in that area, but I think 
>expanding a simple string to an array of as many elements to give developers a 
>tool to do this in PHP-space is not good enough. Especially since it can 
>already be achieved with a regexp that already works.
>
>In my opinion: This adds nothing, and tells the PHP developer that is ok to do 
>count(grapheme_str_split()) for a more accurate mb_strlen().
>
>I would like to see a family of functions that can do multibyte str_split(), 
>strrev(), substr(). Ideally as bugfix in mb_* functions, because the edge-case 
>of wanting to know the length in codepoints of a string is a weird edge-case. 
>No developer wants to know that. mb_strlen() should have returned the number 
>of graphemes from the start.

Many of these already exist, such as grapheme_substr. We can't simply change 
the behaviour of the already existing functions due to BC reasons. 

The intl extension is also built on ICU, an actual unicode text processing 
library. 

The grapheme_str_split function, as well as other intl extension functions is 
what should replace mbstring really. 

cheers 
Derick 

Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath

[Derick Rethans]

On Sun, 24 Mar 2024, Saki Takamachi wrote:

> Hi internals,
> 
> I want to start the discussion on the PHP RFC: Support object type in BCMath.
> 
> https://wiki.php.net/rfc/support_object_type_in_bcmath

I have some comments:

- You've picked as class name "BcNum". Following 
  our naming guidelines, that probably should be \BCMath\Num (or 
  \BC\Num, but that is less descriptive): 
  
https://github.com/php/policies/blob/main/coding-standards-and-naming.rst#namespaces-in-extensions

  The reason it *should* have "BC" is that it comes from "Basic 
  Calculator" (https://www.php.net/manual/en/book.bc.php#118203)

- Should ->value rather be ->toString() ? ->value alone doesn't really 
  say much. I'm on the fence here though, as there is already 
  (internally) a ->__toString() method to make the (string) cast work.

- Would it make sense to have "floor" and "ceil" to also have a scale, 
  or precision? Or would developers instead have to use "round" in that 
  case?

- Which rounding modes are supported with "round", the same ones as the 
  normal round() function?

- In this example, what would $result->scale show? (Perhaps add that to 
  the example?):

value; // '2.46456'
$result->scale; // ??

- Exceptions

  The RFC does not mention which exceptions can be thrown. Is it just 
  the one? It might be beneficial to *do* have a new exception 
  hierarchy.



cheers,
Derick

-- 
https://derickrethans.nl | https://xdebug.org | https://dram.io

Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support

mastodon: @derickr@phpc.social @xdebug@phpc.social

[PHP-DEV] [RFC] Release cycle update, take #2

[Derick Rethans]

Hi!

On Fri, 10 Nov 2023, Jakub Zelenka wrote:

> I would like to propose a new process RFC for updates to PHP release 
> cycle:
> 
> https://wiki.php.net/rfc/release_cycle_update

I have just published version 0.2 of this proposal — I am taken this 
over from Jakub by agreement.

I've slightly reordered it, addressed some comments from this thread, 
and added one new item: aligning the end of releases until Dec 31st, 
20xx.

Now that we have policy documents, my next step is to prepare PRs to 
https://github.com/php/policies/blob/main/feature-proposals.rst for each 
item, after a more general reset of the document to reflect current 
practises.

The RFC is at https://wiki.php.net/rfc/release_cycle_update

cheers,
Derick

[PHP-DEV] System Upgrades / Rsync Server Swapover

[Derick Rethans]

Hi!

TL,DR:

1. I have just pushed a DNS change to use our new rsync server.
2. I have upgraded main.php.net from Debian 10 to 12
3. I have installed all the latest updates on most machines


Long Form

1. In the beginning of the year, Deft (formerly Server Central), reached 
out to us that the current rsync server is old, and they would like to 
continue sponsoring us with a replacement (faster) machine.

I set up this new server in February, but then the mailing list stuff 
happened and life got in the way, so I have only just switched DNS over 
after testing each property.

Except that I could not test rsync and rmtools, as I don't know where 
they live. Nor PEAR, as I don't have access, and I also don't know 
whether it uses our rsync service.

This change should not cause any issues, but let me know if some 
websites don't update after committing code through Git.

2. main.php.net still ran Debian 10, and now Debian 12. This does come 
with a new PHP version (8.2), and I have changed it to use the system 
PHP instead of using Sury's repostory. Again, I also don't expect this 
to cause issues.

3. It is good to install system update onces in a while, and I've done 
that.

Let me know if anything broke!

cheers,
Derick
-- 
https://derickrethans.nl | https://xdebug.org | https://dram.io

Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support

mastodon: @derickr@phpc.social @xdebug@phpc.social

Re: [PHP-DEV] Windows PECL build machine died

[Derick Rethans]

Hi,

To revive this ancient thread. We have made some progress getting these 
builds made for Windows again.

Shivam has been working on an extension builder for Windows 
(https://github.com/php/php-windows-builder?tab=readme-ov-file#build-a-php-extension)
 
— GHA actions to build your DLLs on release.

He's tried that on Xdebug: 
https://github.com/shivammathur/xdebug/blob/master/.github/workflows/release.yml

This is still pre-release, so please don't rely on this yet!

We are also looking at buliding some specific PECL extensions for 
Windows, and uploading them to the downloads server.

PECL DLLs are no longer served from the windows.php.net server either, 
but instead from downloads.php.net/~windows : 
https://pecl.php.net/package/ssh2/1.3.1/windows

Uploading built DLLs to this server can not be done automatically due to 
2FA requirements, but we'll think on how to improve that.

cheers,
Derick



On Sun, 23 Apr 2023, Casper Langemeijer wrote:

> Nothing seems to happen on this front, and our Windows users like to move to 
> PHP 8.2 too.
> 
> The windows.php.net site states: "This is because the Windows PECL build 
> machine died, and the team is still working on the long term plan of building 
> DLLs for PECL extensions with a new CI process."
> 
> We are 1 year since the machine died. 6 month since the statement on the 
> website. From the point of view of our users nothing has changed, and are 
> questioning if the windows project is still alive.
> 
> I'd like to ask: Is re-inventing the building process really a smart thing to 
> do if it means we'll be out-of-service for more than a year?
> 
> "We're doing our best to finish that as soon as possible, and keep you up to 
> date."
> 
> I'm not questioning intentions, but I hate to think this is 'our best'. We 
> should at least have and share a more concrete plan, possibly share a rough 
> timeframe and share if we hit a blocking problem. If help is needed, we 
> should ask.
> 
> Greetings, Casper

-- 
https://derickrethans.nl | https://xdebug.org | https://dram.io

Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support
Host of PHP Internals News: https://phpinternals.news

mastodon: @derickr@phpc.social @xdebug@phpc.social
twitter: @derickr and @xdebug

Re: [PHP-DEV] [RFC[ Property accessor hooks, take 2

[Derick Rethans]

On Fri, 8 Mar 2024, Larry Garfield wrote:

> Hi folks.  Based on earlier discussions, we've made a number of 
> changes to the RFC that should address some of the concerns people 
> raised.  We also had some very fruitful discussions off-list with 
> several developers from the Foundation, which led to what we feel are 
> some solid improvements.
> 
> https://wiki.php.net/rfc/property-hooks

Some comments and questions:

Be aware, the detection logic works on $this->[propertyName] directly 
at 
compile time, not on dynamic forms of it like $prop = 'beep'; 
$this->$prop. That will not trigger a backing value. 

How can that not cause issues?


 The set hook's return type is unspecified, and will silently be 
treated as void. 

What happens if you *do* specify a return type? Will it Error?


Implicit ''set'' parameter

If the write-type of a property is the same as its defined type 
(this is the common case), then the argument may be omitted 
entirely. 

…

If the parameter is not specified, it defaults to $value.

I am not a fan of this "magical" behaviour. Do we *need* this short cut, 
and the following "Short-set"?


With asymmetric visibility that was previously proposed, the 
example can be further simplified. 

But it isn't here, so why is this example (and the next one) in the RFC? 
:-)


Interaction with constructor property promotion

… In particular, the shorthand version of hook bodies and the 
ability to call out to private methods if they get complicated 
partially obviate the concern about syntactic complexity. 

Although that is true, it *does* add more complexity in tools that needs 
to parse PHP, as there is now another piece of new syntax that needs to 
be added (and tested with).


ReflectionProperty has several new methods to work with hooks.

getHooks(): array returns an array of \ReflectionMethod objects  
keyed by the hook they are for.

What will the name for the  hook be? And shouldn't there be an enum 
case for that as well?

cheers,
Derick

Re: [PHP-DEV] is this thing on?

[Derick Rethans]

On 4 March 2024 22:26:37 GMT, dan...@daniil.it wrote:
>> Has Microsoft made a commitment to support open source forever? I mean MS 
>> owns Github, what ensures that it will stay free?
>
>This is a silly argument, if that were the case, maybe the VCS should move 
>back to a self-hosted instance too?

The VSC part from github (hosting our code), can very easily be ported. Issues, 
discussions etc can not. 

>Jokes aside, if Microsoft suddenly decides to throw away or to charge for 
>github, one of their biggest assets after Windows and OpenAI, PHP would have 
>bigger problems than RFCs being managed on the github issue tracker.

With the ongoing enshittification of most of the Internet due to advertising 
and tracking, we'd be negligent not hosting and owning our own content 
(including our issue tracker, but that ship has sailed now). 

Email has been around for half a century. Will things like Slack, Discord, and 
the like still be operational and allow access to our archives in another 25 
years? I'm almost certain it won't be. 

cheers 
Derick 

Re: [PHP-DEV] is this thing on?

[Derick Rethans]

On 26 February 2024 11:03:05 GMT, "Rowan Tommins [IMSoP]" 
 wrote:
>On Sun, 25 Feb 2024, at 20:02, Rob Landers wrote:
>> Before I get to the meat of this email, first of all, IMHO, anyone should be 
>> able to email the list, even if they are not a 
>> member of the list. I've had to email ubuntu lists about bugs before and I 
>> really have no desire to join those lists, but
>> I was always able to just send the email to the list just fine.

That's not true. There was a complex pre-auth system in use that you had to do 
once (the "confirmed list"). 

>The biggest problem with an open list is how to manage spam

Exactly. See the results of that on the php-announce list which was open for a 
few hours. 

We can't make this an open list. 

>Exactly the same way you subscribed, I believe: via the web form, or using 
>+unsubscribe in the to address.

Correct. 

cheers 
Derick 

Re: [PHP-DEV] What's up with emails?

[Derick Rethans]

On Thu, 22 Feb 2024, mjec wrote:


On Thu, 2024-02-22 at 10:29 -05:00, Alain D D Williams  
wrote:

On Thu, Feb 22, 2024 at 09:05:22AM -0500, Derick Rethans wrote:

Gmail is rejecting emails after we moved the servers without telling 
us why, in enough detail to do anything about it.


I run other mail lists and have had similar problems with gmail 
recently.


Gmail explicitly tightened their requirements for senders this month, 
so while it's likely the server change is related, it may not be the 
entire cause.


Specifically, they require:

- valid spf, with specific rules for quarantining email that has @gmail.com 
From but doesn't pass spf
- valid dkim
- dmarc configured if the server sends more than 5k emails to Gmail


We should have all of that though?



They also equivocally indicate a requirement for ARC and a List-Id header.


We have a List-Id header, but I've not even heard of ARC. It is on our 
list to investigate though. Our SMTP logs definitely don't say anything 
about this though.



This is all at https://support.google.com/a/answer/81126.

I think ARC is a must; without it we'll never get to passing dkim at 
least, even if we rewrite from so spf passes.


But SPF is now passing? The postmaster tools show this:

Date	DKIM success rate	SPF success rate	DMARC success 
rate

15 Feb 2024 100.0%  100.0%  0.0%
16 Feb 2024 100.0%  100.0%  0.0%
17 Feb 2024 100.0%  100.0%  0.0%
18 Feb 2024 100.0%  100.0%  0.0%
19 Feb 2024 100.0%  100.0%  100.0%
20 Feb 2024 100.0%  100.0%  100.0%

I'm happy to pitch in to help getting this configured if that's 
helpful, though I'm also very conscious that too many cooks is often a 
greater harm than good when it comes to administration. But reach out 
if you think I can be helpful.


We could definitely use some people that now email delivery.

cheers,
Derick

Re: [PHP-DEV] What's up with emails?

[Derick Rethans]

On Thu, 22 Feb 2024, Alain D D Williams wrote:


On Thu, Feb 22, 2024 at 09:05:22AM -0500, Derick Rethans wrote:


Gmail is rejecting emails after we moved the servers without telling us why, in 
enough detail to do anything about it.


I run other mail lists and have had similar problems with gmail recently.

The problem seems to be SPF. This says which IP addresses can be used for
sending email for particular domains. gmail has recently become much stricter.

List emails are sent from php-smtp4.php.net (45.112.84.5).

However the 'From' address is still that of the original sender -- which is OK
for the email that I am replying to as it is
From: Derick Rethans 

and the MX for php.net is php-smtp4-ip4.php.net. which has address 45.112.84.5

However I suspect that *this* email (the one that I am typing now) will get
bounced by gmail as my address is: a...@phcomp.co.uk and 45.112.84.5 is not
allowed (by SPF) to send email for phcomp.co.uk.

So: how to fix ?

Make the From: address internals@lists.php.net


We don't want to change the From address, as that means that replies go 
to the list, rather than the original sender. We never had to do any of 
that before.



The envelope address is already, something like
internals+bounces-122457-addw=phcomp.co...@lists.php.net

This means a fix to whatever list processor that you are using.

Other recommendations:

• MX for lists.php.net is php-smtp4-ip4.php.net.
Change to php-smtp4.php.net.


Done


• SPF for lists.php.net is "v=spf1 a mx a:osu1php.osuosl.org. ip4:45.112.84.5 
ip6:2a02:cb43:8000::1102"
Change to "v=spf1 a mx -all"


Done, but I kept it as ~all.


•• osu1php.osuosl.org. does not seem to exist - so zap it


Done


•• If you make the MX change that I suggest then the
following are redundant: ip4:45.112.84.5 ip6:2a02:cb43:8000::1102


Done


•• -all means no other addresses accepted. gmail started making that implicit in
the last few months, it is this that is causing the current problems.


I've added ~all instead.

Once that has settled down you should enable sending email from (& 
thus to) IPv6 addresses. This is the way that the world is moving. It 
is not hard.


Done that now too.

Fingers crossed to see if any of this is helping.

cheers,
Derick

Re: [PHP-DEV] What's up with emails?

[Derick Rethans]

On 22 February 2024 08:52:49 GMT-05:00, Robert Landers 
 wrote:
>I have noticed quite a number of emails appearing on externals but not
>appearing in my inbox. I randomly get an email saying:
>
>Hi, this is the Mlmmj program managing the 
>mailing list.
>
>Some messages to you could not be delivered. If you're seeing this
>message it means things are back to normal, and it's merely for your
>information.
>
>Here is the list of the bounced messages:
>- 122446
>- 122448
>
>But I can clearly see far more than that in externals that are never received.
>
>IIRC from the email spec and internet customs, soft-bounces should be
>retried for a number of days (though I have no idea why gmail
>soft-bounced the messages, maybe rate-limiting?).
>
>If I'm using gmail and not getting emails, how many other people are
>also not getting emails on this list?


Lots.

Gmail is rejecting emails after we moved the servers without telling us why, in 
enough detail to do anything about it.

We can put a delay in delivering to Gmail, but that means mails get delayed for 
days.

So my advice would for now to not rely on Gmail while we figure out how to 
improve this.

cheers
Derick

Re: [PHP-DEV] Requesting RFC karma

[Derick Rethans]

On 20 February 2024 10:05:25 CET, Marc Bennewitz  wrote:
>
>On 20.02.24 09:58, Derick Rethans wrote:
>> On 20 February 2024 08:41:19 GMT, Marc Bennewitz  wrote:
>>> Hi Hans,
>>> 
>>> On 16.02.24 13:05, Hans Henrik Bergan wrote:
>>>> My name is "Hans Henrik Bergan", usually go by the nickname
>>>> "divinity76", I've contributed to OSS (including PHP) for years, and
>>>> am currently involved in 3 things that might require an RFC, and
>>>> requesting RFC karma for wiki account "divinity76".
>>>> 
>>>> 3/3: int|float for DateTime::setTimestamp, setTimestamp(0.123456) =>
>>>> 1970-01-01 00:00:00.123456 :https://github.com/php/php-src/pull/13383
>>> Actually I also want to work on this if I find time ... but as this is a BC 
>>> break I think it makes sense to revisit DateTime (and friends) to bundle BC 
>>> breaks to a single PHP version - probably PHP 9 and more sure there is a 
>>> way for users to make it work in PHP (7+)8+9.
>>> 
>>> Personal and incomplete list I think needs improvements:
>>> 
>>> * allow float for `setTimestamp`
>>> * option to return timestamp as float to simplify passing it to JS
>>> * Missing getter/setter for most of the date/time parts like 
>>> `get/setSecond`, `get/setHour` etc.
>>>    * For now I only added `get/setMicroseconds` together with 
>>> `createFromTimestamp` because 
>>> `DateTime::createFromTimestamp(123456789)->setMicroseconds(123987)`
>>>    * After thinking about naming - I think this should be renamed to 
>>> singular 
>>> * Add missing methods to DateTimeInterface
>>> * Allow userland implements DateTimeInterface
>>>    * Define how `createFromInterface` behaves on userland implementations
>>> * fixing ISO 8601 format
>>> * fixing some return type definitions from self to static
>>> * strict mode
>>>    * `DateTime::createFromFormat('Y-m-d', '2023-02-29')`
>>>    * `DateTime::createFromFormat('Y-m-d H:i', '2024-03-31 02:30', new 
>>> DateTimeZone('Europe/Berlin'))`
>>> * Missing current microseconds on `createFromFormat` but other non defined 
>>> parts needs to be explicitly reset using `|!`
>>> * leap seconds support on UTC TZ
>>>    * As of leap seconds ... wouldn't it be better to default to +00:00 
>>> instead of UTC ?
>>> * Support nanoseconds
>>> 
>>> 
>>> I'm for sure not able to work on all these points and that's why I only 
>>> started very small close to no BC improvements without RFC.
>>> 
>> IMO, doing tweaks to this base functionality isn't the way forwards. I've 
>> been having on and off conversations with Florian over the last couple of 
>> months to see if we can design a better higher level API instead of patching 
>> the nits.
>
>Do you mean adding an additional API in C or userland? Is there a way to 
>participate on the discussion?


A bit of both, I suppose. But mainly for a user facing API. I've nothing 
concrete yet, and will soon start collecting thoughts. I'll make sure to email 
this list.

cheers
Derick

Re: [PHP-DEV] Requesting RFC karma

[Derick Rethans]

On 20 February 2024 08:41:19 GMT, Marc Bennewitz  wrote:
>Hi Hans,
>
>On 16.02.24 13:05, Hans Henrik Bergan wrote:
>> My name is "Hans Henrik Bergan", usually go by the nickname
>> "divinity76", I've contributed to OSS (including PHP) for years, and
>> am currently involved in 3 things that might require an RFC, and
>> requesting RFC karma for wiki account "divinity76".
>> 
>> 3/3: int|float for DateTime::setTimestamp, setTimestamp(0.123456) =>
>> 1970-01-01 00:00:00.123456 : https://github.com/php/php-src/pull/13383
>
>Actually I also want to work on this if I find time ... but as this is a BC 
>break I think it makes sense to revisit DateTime (and friends) to bundle BC 
>breaks to a single PHP version - probably PHP 9 and more sure there is a way 
>for users to make it work in PHP (7+)8+9.
>
>Personal and incomplete list I think needs improvements:
>
>* allow float for `setTimestamp`
>* option to return timestamp as float to simplify passing it to JS
>* Missing getter/setter for most of the date/time parts like `get/setSecond`, 
>`get/setHour` etc.
>  * For now I only added `get/setMicroseconds` together with 
>`createFromTimestamp` because 
>`DateTime::createFromTimestamp(123456789)->setMicroseconds(123987)`
>  * After thinking about naming - I think this should be renamed to singular 
>* Add missing methods to DateTimeInterface
>* Allow userland implements DateTimeInterface
>  * Define how `createFromInterface` behaves on userland implementations
>* fixing ISO 8601 format
>* fixing some return type definitions from self to static
>* strict mode
>  * `DateTime::createFromFormat('Y-m-d', '2023-02-29')`
>  * `DateTime::createFromFormat('Y-m-d H:i', '2024-03-31 02:30', new 
>DateTimeZone('Europe/Berlin'))`
>* Missing current microseconds on `createFromFormat` but other non defined 
>parts needs to be explicitly reset using `|!`
>* leap seconds support on UTC TZ
>  * As of leap seconds ... wouldn't it be better to default to +00:00 instead 
>of UTC ?
>* Support nanoseconds
>
>
>I'm for sure not able to work on all these points and that's why I only 
>started very small close to no BC improvements without RFC.
>
>
>Marc
>

IMO, doing tweaks to this base functionality isn't the way forwards. I've been 
having on and off conversations with Florian over the last couple of months to 
see if we can design a better higher level API instead of patching the nits.

cheers
Derick

Re: [PHP-DEV] RE: Testing new list server

[Derick Rethans]

On 18 February 2024 12:08:46 GMT, Frederik Bosch  wrote:
>
>On 18-02-2024 11:47, Derick Rethans wrote:
>> On 18 February 2024 10:23:59 GMT, Matthew Sewell  wrote:
>>> Hi,
>>> 
>>> I'm using Gmail too but with a custom domain. I did get those three
>>> messages but significantly delayed from when they were on externals.
>> That sounds about right. The queue was backed up due to rate limiting for 
>> 10+ hours. This should no longer be the case, and all messages should now 
>> have been delivered.
>> 
>> cheers
>> Derick
>> 
>> 
>>> On Sat, Feb 17, 2024 at 4:15 PM tag Knife  wrote:
>>> 
>>>> On Fri, 16 Feb 2024 at 23:50, Jorg Sowa  wrote:
>>>> 
>>>>> Hello Derick,
>>>>> there is something wrong. I don't get all of the emails from the new
>>>>> setup, only part. Examples of emails I didn't receive:
>>>>> - https://externals.io/message/122391
>>>>> - https://externals.io/message/122390
>>>>> - https://externals.io/message/122388
>>>>> 
>>>>> I'm using Gmail and Spam doesn't contain any of them.
>>>>> 
>>>>> Kind regards,
>>>>> Jorg
>>>>> 
>>>> Same, I did not receive messages
>>>> - 122402
>>>> - 122372
>>>> - 122376
>>>> 
>>>> 
>Hi Derick,
>
>I tried to unsubscribe but I get a 550 from php-smtp4.php.net.
>
>550 5.1.1 : Recipient address
>    rejected: User unknown in local recipient table (in reply to RCPT TO
>    command)
>
>Is that also due to the new server, or is that perhaps my own mistake?
>
>Regards,
>Frederik

A bit of both. The separator changed from - to + with the server change, but 
I've only more recently updated that change in the headers that the lists add.

Cheers
Derick

Re: [PHP-DEV] RE: Testing new list server

[Derick Rethans]

On 18 February 2024 10:23:59 GMT, Matthew Sewell  wrote:
>Hi,
>
>I'm using Gmail too but with a custom domain. I did get those three
>messages but significantly delayed from when they were on externals.

That sounds about right. The queue was backed up due to rate limiting for 10+ 
hours. This should no longer be the case, and all messages should now have been 
delivered. 

cheers 
Derick 


>On Sat, Feb 17, 2024 at 4:15 PM tag Knife  wrote:
>
>>
>> On Fri, 16 Feb 2024 at 23:50, Jorg Sowa  wrote:
>>
>>> Hello Derick,
>>> there is something wrong. I don't get all of the emails from the new
>>> setup, only part. Examples of emails I didn't receive:
>>> - https://externals.io/message/122391
>>> - https://externals.io/message/122390
>>> - https://externals.io/message/122388
>>>
>>> I'm using Gmail and Spam doesn't contain any of them.
>>>
>>> Kind regards,
>>> Jorg
>>>
>>
>> Same, I did not receive messages
>> - 122402
>> - 122372
>> - 122376
>>
>>

Re: [PHP-DEV] automatic formatting checks for pull requests?

[Derick Rethans]

On 17 February 2024 22:18:05 GMT, Ilija Tovilo  wrote:
>Hi Hans
>
>On Sat, Feb 17, 2024 at 3:31 PM Gina P. Banyard  wrote:
>>
>> On Saturday, 17 February 2024 at 11:24, Hans Henrik Bergan  
>> wrote:
>>
>> > Can we add automatic formatting checks for pull requests?
>> > Made a PR: https://github.com/php/php-src/pull/13417
>>
>> It would be nice to have some formatting rules to harmonize the codebase as 
>> it is somewhat the wild west,
>> but as far as my understanding goes is that Clang format struggles to 
>> understand our codebase (namely macros) and is difficult to set-up for 
>> php-src.
>
>Right. Consistent code style is nice, but what we have now is really
>not that bad. There are a couple things I'd want if we enforce code
>style:
>
>* Fixing the style should be easy, running a single command without
>first pushing to CI.
>* It should be fast too, so that I can easily run it for every commit,
>preferably even on-save in my editor.
>* The new code style should be applied only to newly added sections or
>changed code, not entire files. Otherwise, we'll have many changes in
>large files, with endless merge conflicts when merging up from lower
>branches.
>* The formatting tool should work for all php-src code, not just plain
>C code. We don't want to be forced to refactor old macros just because
>we need to add a single line to some long-standing code. Last time I
>tried clang-format, it utterly failed with our macros.
>
>I haven't looked at your PR in detail, so I'm not sure which of these
>points it satisfies. It would be great if you could quickly describe
>how it works, and what the goals are.
>
>Essentially, I'm just sceptical that this isn't more trouble than it's worth.
>
>Ilija

IMO, clang-format isn't really suitable. Its untunable style is often far from 
the coding style that we currently have, and it makes some really odd choices 
as to when and how to wrap lines, making code definitely less readable.

cheers
Derick

Testing new list server

[Derick Rethans]

Please don't be alarmed, we're moving the lists over to a new machine.

[PHP-DEV] Test Email — Ignore

[Derick Rethans]

(We're going to need to move the lists servers, and just trying to 
figure out how email gets currently delivered)

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

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

[Derick Rethans]

I've added Chris (as maintainer) , and also Michael Vorisek (as writer) - he's 
worked on testing the Oracle extensions on CI. 

cheers 
Derick 

On 5 February 2024 12:54:19 GMT, Sharad Chandran R  
wrote:
>Thanks, Derick. I will create a PECL account.
>
>The GitHub username for Christopher Jones is @cjbj. Please add him to the repo 
>as well.
>
>Warm Regards,
>Sharad Chandran R, Principal Product Manager
>Oracle Database Server Technologies
>India Bangalore 
>
>
>-Original Message-
>From: Derick Rethans  
>Sent: 05 February 2024 17:05
>To: Sharad Chandran R ; s...@php.net
>Cc: internals@lists.php.net
>Subject: RE: [External] : Re: [PHP-DEV] VCS Account Request: sharadchan87
>
>Hi Sharad,
>
>I've just created the new repositories for the OCI8 and PDO_OCI extensions, 
>which we have moved out of the PHP core source distribution as per a recent 
>RFC: 
>https://urldefense.com/v3/__https://wiki.php.net/rfc/unbundle_imap_pspell_oci8__;!!ACWV5N9M2RV99hQ!NwgLwG1wPwUlDPMriZRj1XxFl6Gk7UkMeO8d7Cc9oGPqBLGhhW0N0WuKb55jKg-OrAdBGoX4aqDl8A$
> 
>
>I have invited you as a collaborator on these two new repositories:
>
>https://urldefense.com/v3/__https://github.com/php/pecl-database-pdo_oci__;!!ACWV5N9M2RV99hQ!NwgLwG1wPwUlDPMriZRj1XxFl6Gk7UkMeO8d7Cc9oGPqBLGhhW0N0WuKb55jKg-OrAdBGoWVFsJHQg$
>https://urldefense.com/v3/__https://github.com/php/pecl-database-oci8__;!!ACWV5N9M2RV99hQ!NwgLwG1wPwUlDPMriZRj1XxFl6Gk7UkMeO8d7Cc9oGPqBLGhhW0N0WuKb55jKg-OrAdBGoU5wk3siA$
> 
>
>I wanted to invite Christopher too (cc-ed), but I don't have his GitHub 
>username, and I can't find it anywhere.
>
>Since we moved to GitHub, the need for an VCS account also no longer exists, 
>but you might need a PECL account to release versions of this
>package: 
>https://urldefense.com/v3/__https://pecl.php.net/account-request.php__;!!ACWV5N9M2RV99hQ!NwgLwG1wPwUlDPMriZRj1XxFl6Gk7UkMeO8d7Cc9oGPqBLGhhW0N0WuKb55jKg-OrAdBGoUjSAH4AA$
> 
>
>Christopher should know how to do this, as he's done so before for at least 
>oci8.
>
>Let me know if you have further questions.
>
>cheers,
>Derick
>
>On Mon, 5 Feb 2024, Sharad Chandran R wrote:
>
>> Hi Derick,
>> Hope you are doing well!
>> 
>> Can you let me know if my account is approved?
>> 
>> Warm Regards,
>> Sharad Chandran R, Principal Product Manager Oracle Database Server 
>> Technologies India Bangalore
>> 
>> -Original Message-
>> From: Sharad Chandran R
>> Sent: 18 January 2024 21:02
>> To: Derick Rethans ; internals@lists.php.net
>> Subject: RE: [External] : Re: [PHP-DEV] VCS Account Request: 
>> sharadchan87
>> 
>> Hi Derick,
>> Thanks for responding so quickly.
>> 
>> My GitHub account name is sharadraju.
>> 
>> Warm Regards,
>> Sharad Chandran R, Principal Product Manager Oracle Database Server 
>> Technologies India Bangalore
>> 
>> 
>> -Original Message-
>> From: Derick Rethans 
>> Sent: 18 January 2024 20:51
>> To: internals@lists.php.net; Sharad Chandran R 
>> 
>> Subject: [External] : Re: [PHP-DEV] VCS Account Request: sharadchan87
>> 
>> On 18 January 2024 09:42:50 GMT, Sharad Chandran R  
>> wrote:
>> >As part of Oracle, I work with @cjones and would like to contribute to oci8 
>> >php extension.
>> >
>> 
>> Hi Sharad,
>> 
>> As you might be aware, we've recently decided to move the oci8 and Oracle 
>> extensions away from the PHP core distribution. I'm in the process of 
>> setting up a new Git repository where then work can be done, and from where 
>> releases on PECL can be made. 
>> 
>> It would probably best to wait until that's done (today / tomorrow), and 
>> then I can add you as maintainer of the repository.
>> 
>> For that, I'd need to know your GitHub account name.
>> 
>> cheers
>> Derick
>> 
>

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

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

[Derick Rethans]

Hi Sharad,

I've just created the new repositories for the OCI8 and PDO_OCI 
extensions, which we have moved out of the PHP core source distribution 
as per a recent RFC: https://wiki.php.net/rfc/unbundle_imap_pspell_oci8

I have invited you as a collaborator on these two new repositories:

https://github.com/php/pecl-database-pdo_oci
https://github.com/php/pecl-database-oci8

I wanted to invite Christopher too (cc-ed), but I don't have his GitHub 
username, and I can't find it anywhere.

Since we moved to GitHub, the need for an VCS account also no longer 
exists, but you might need a PECL account to release versions of this 
package: https://pecl.php.net/account-request.php

Christopher should know how to do this, as he's done so before for at 
least oci8.

Let me know if you have further questions.

cheers,
Derick

On Mon, 5 Feb 2024, Sharad Chandran R wrote:

> Hi Derick,
> Hope you are doing well!
> 
> Can you let me know if my account is approved?
> 
> Warm Regards, 
> Sharad Chandran R, Principal Product Manager
> Oracle Database Server Technologies
> India Bangalore 
> 
> -Original Message-
> From: Sharad Chandran R 
> Sent: 18 January 2024 21:02
> To: Derick Rethans ; internals@lists.php.net
> Subject: RE: [External] : Re: [PHP-DEV] VCS Account Request: sharadchan87
> 
> Hi Derick,
> Thanks for responding so quickly.
> 
> My GitHub account name is sharadraju.
> 
> Warm Regards,
> Sharad Chandran R, Principal Product Manager Oracle Database Server 
> Technologies India Bangalore 
> 
> 
> -Original Message-
> From: Derick Rethans 
> Sent: 18 January 2024 20:51
> To: internals@lists.php.net; Sharad Chandran R 
> Subject: [External] : Re: [PHP-DEV] VCS Account Request: sharadchan87
> 
> On 18 January 2024 09:42:50 GMT, Sharad Chandran R  
> wrote:
> >As part of Oracle, I work with @cjones and would like to contribute to oci8 
> >php extension.
> >
> 
> Hi Sharad,
> 
> As you might be aware, we've recently decided to move the oci8 and Oracle 
> extensions away from the PHP core distribution. I'm in the process of setting 
> up a new Git repository where then work can be done, and from where releases 
> on PECL can be made. 
> 
> It would probably best to wait until that's done (today / tomorrow), and then 
> I can add you as maintainer of the repository.
> 
> For that, I'd need to know your GitHub account name.
> 
> cheers
> Derick 
> 

-- 
https://derickrethans.nl | https://xdebug.org | https://dram.io

Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support
Host of PHP Internals News: https://phpinternals.news

mastodon: @derickr@phpc.social @xdebug@phpc.social
twitter: @derickr and @xdebug

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

Re: [PHP-DEV] [VOTE] [RFC] Collecting All Policies Into One Repository

[Derick Rethans]

On Fri, 5 Jan 2024, Derick Rethans wrote:

> I have just opened the voting on the "Policy Repository" RFC. It will 
> run until January 22nd, 2024 at 08:00 UTC:
> 
> https://wiki.php.net/rfc/policy-repository#voting_choices

Voting is now closed, and the RFC was accepted unanimously, with 28 for 
and 0 against.

I will add a link to all affected RFC's wiki pages, and other related 
pages, that the canonical version now lives in the new repository, at: 
https://github.com/php/policies

cheers,
Derick

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

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

[Derick Rethans]

On 18 January 2024 09:42:50 GMT, Sharad Chandran R  
wrote:
>As part of Oracle, I work with @cjones and would like to contribute to oci8 
>php extension.
>

Hi Sharad,

As you might be aware, we've recently decided to move the oci8 and Oracle 
extensions away from the PHP core distribution. I'm in the process of setting 
up a new Git repository where then work can be done, and from where releases on 
PECL can be made. 

It would probably best to wait until that's done (today / tomorrow), and then I 
can add you as maintainer of the repository.

For that, I'd need to know your GitHub account name.

cheers
Derick

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

[PHP-DEV] [VOTE] [RFC] Collecting All Policies Into One Repository

[Derick Rethans]

Hi,

I have just opened the voting on the "Policy Repository" RFC. It will 
run until January 22nd, 2024 at 08:00 UTC:

https://wiki.php.net/rfc/policy-repository#voting_choices

cheers,
Derick

-- 
https://derickrethans.nl | https://xdebug.org | https://dram.io

Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support
Host of PHP Internals News: https://phpinternals.news

mastodon: @derickr@phpc.social @xdebug@phpc.social
twitter: @derickr and @xdebug

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

Re: [PHP-DEV] security email address broken?

[Derick Rethans]

On 28 December 2023 18:36:22 GMT, Robert Landers  
wrote:
>Hello internals,
>
>I sent an email to secur...@php.net (which I got from this page:
>https://wiki.php.net/security#:~:text=Please%20report%20it,security/advisories/new)
>and got back:
>
>I'm sorry to have to inform you that your message could not
>be delivered to one or more recipients. It's attached below.

It definitely arrived (as did Sebastian's). Can you tell me which ones the 
warning was for?

cheers
Derick 

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

Re: [PHP-DEV] Partitioned cookies

[Derick Rethans]

On 24 December 2023 12:46:40 CET, Niels Dossche  wrote:
>Hi internals
>
>I opened a PR [1] to implement Partitioned cookie support, as requested on the 
>bugtracker [2], into the setcookie() PHP function. This is done by adding an 
>option to the $options array, not via an additional argument to the function. 
>The amount of code to support this is tiny.
>
>This cookie option is being pushed by browser vendors (primarily by Google it 
>seems) to eliminate third-party cookies [3, 4]. One of the impacts here is 
>that cookies marked with "SameSite=None; Secured" without "Partitioned" will 
>stop working eventually during 2024.
>
>Although the Partitioned cookie proposal is still a draft, Chrome will apply 
>the change starting in January 2024 for a tiny percentage of users (as a form 
>of A/B testing it seems). Symfony has already implemented support for this 
>option as well [5].
>The SameSite option was also added in PHP when it was still in a draft.
>
>Let me know what you think and if you are okay / objecting to merging this PR.


I've two concerns (none with the PR, as I haven't checked):

- Compatibility: 
https://developer.mozilla.org/en-US/docs/Web/Privacy/Partitioned_cookies#browser_compatibility
- What happens if it just stays a draft, or doesn't get accepted, or with a 
different name?

And also, would/should the PHP function enforce that this should only be set if 
for example Secure is set too? And if so, with a warning or TypeError?

cheers
Derick

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

Re: [PHP-DEV] [RFC] Collecting All Policies Into One Repository

[Derick Rethans]

On Mon, 18 Dec 2023, Jorg Sowa wrote:

> I have one question regarding the future changes. Do you see it would 
> be possible to make amendment to the accepted RFCs by the Pull 
> Requests (and formal RFC approach) making changes the existing 
> policies or adding the new policy replacing the old ones? In other 
> words, this repository would server as the collection of all ever 
> accepted policies or it would contain the unified policy 
> documentation?

It should contain the consolidated unified policy documentation that is 
"currently" active.

The other option is what we currently have, and I am proposing to go 
away from. So the idea is that this repository is not a 
collection of the accepted policy *amendments* (or *replacements*), 
as that's what the RFCs / PRs are still for.

> I'm asking because I saw the directory `archive`, and it contains 
> expired RFC. I don't think this would help new contributors. For the 
> history purposes it would be nice to have it in the git history, but 
> for the PHP development process is not relevant anymore and is little 
> overhead.

I didn't really know what to do with these documents in archive, as 
they were sortof related to the release process/timeline document. I 
suppose we don't need them, but they are not *wrong* or *outdated*. 
Simply no longer needed as the time frame has passed.

cheers,
Derick

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

Re: [PHP-DEV] [RFC] Collecting All Policies Into One Repository

[Derick Rethans]

Hi,

On Tue, 5 Dec 2023, Derick Rethans wrote:

> A while ago I started looking into all the documents (RFCs etc) that we 
> have that relate to all sort of policies. From RFCs, to who can vote, 
> naming, and security classifications as a result of a discussion with 
> the foundations folk.

A heads-up, as I posted this just over two weeks ago, and there was 
little discussion.

I am intending to open the voting on this in the next few days. With the 
intention of running it until January 5th due to the holiday season.

cheers,
Derick

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

Re: [PHP-DEV] New "PECL"

[Derick Rethans]

On Thu, 7 Dec 2023, Remi Collet wrote:

> Le 05/12/2023 à 14:45, Derick Rethans a écrit :
> > https://docs.google.com/document/d/1_N0E9xo3jn9aKrIZHIbTYaY5lXw71BpSO6-it4cRpDo
> > 
> > In this first stage, we would like to invite you in commenting on the
> > document (either inline, or here).
> 
> As inline requires a Google account...
> 
> > priority (optional): The installation "priority".
> 
> 1/ I don't like this name which is ambiguous
> 
> higher value seems to give higher priority
> which lower are loaded first
> 
> This prefix, used in various linux distro,
> is really a "load order", needed when using --enable-rtld-now
> 
> So I proprose "load order" instead

We can quibble over the name :-)

I picked something short. Debian calls it 
'priority' too in their ini files. For example:

; configuration for php common module
; priority=20
extension=calendar.so

> 2/ values
> 
> Default value can be 40 or max(requirement) + 10
> 
> In Fedora where we use this for years we have
> (IIRC debian have different practice)
> 
> 0-19 for zend_extension
>   10 for opcache
>   15 for xdebug

That's not really a good default. At least Xdebug should be 
near the end of the loading order.

> 20-39 for php-src extension
>   20 for most
>   30 if requirement (ex: pdo drivers)
> 40-99 for other (pecl...)
>   40 for igbinary, msgpack
>   50 for redis which use igbinary, msgpack

I am happy to pick a different default. I had picked what Debian seemed 
to have (20).

I don't think it matters much though, as distribitions can decide to 
change them in their binary packages regardless.

cheers,
Derick

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

Re: [PHP-DEV] New "PECL"

[Derick Rethans]

On Wed, 6 Dec 2023, Tim Starling wrote:

> On 6/12/23 00:45, Derick Rethans wrote:
> > The code is old, and hard to maintain. And the database is full of 
> > mojibake. It is also an outdated method of installing things, 
> > especially because userland code is so much easier to handle through 
> > Composer.
> 
> Thanks for working on this.
> 
> I would say that one of the reasons userland code is easier is because 
> composer packages are local and unprivileged, whereas extensions are 
> global and are typically require root to install. That problem is not 
> going to go away. For community-supplied packages we're mostly using 
> Ondrej Sury's Debian packages. For our own packages (LuaSandbox, 
> Excimer) we're building debs from git tags without reference to PECL. 
> So PECL for us is part of the release procedure just as a courtesy to 
> the downstream community.

>From what I can see, once you drop a "new-pecl.json" file (or whatever 
we'll end up calling it) into the repo at 
https://github.com/wikimedia/mediawiki-php-luasandbox it should 
automatically become compatible with the new PECL. You shouldn't have to 
deal with making actual packages and uploading them to the PECL website. 
I'm going to hope that that is an improvement for you?

> In terms of security, there should be no way to get root by uploading 
> a malicious PECL package. With debs, I'm not sure if that separation 
> is rock-solid, but at least it exists aspirationally. During build, we 
> run code from the package as non-root. During installation, as root we 
> install generated files into locations which hopefully won't be 
> executed as root. To achieve this separation with PECL, there would 
> need to be some sort of system-aware privilege separation inside the 
> PECL installer. At least it should fork and drop root privileges.

Yes, that is a good recommendation, and something that should definitely 
go into the design document.

> Signed tags only help if you trust the package developer. I don't want 
> to have to trust anyone.

That's true. I think signatures make more sense when a package is 
authored by a known organisation, such as wikimedia or MongoDB. Where 
the signatures therefore include these organisation's domain names.

> The PHP version dependency is a tricky part of the spec. When we make 
> a release, we have no way to know how forwards-compatible it is. At 
> some point, a PHP core change will break the extension. The proposed 
> structure suggests that we would have to release a new version of the 
> extension just to say that it's broken. Then later when we make a fix, 
> we would release again with that information.

I don't think you'll have to make a new *release*, as I was hoping to 
access the meta data file in the main/master branch.

I solve this for Xdebug by always setting a hard upper limit. Better 
safe than sorry.

> My motivation to maintain a historical list of supported version 
> ranges is very limited. I just want to declare, for the code I'm 
> actually releasing, the earliest supported PHP version and maybe the 
> latest confirmed PHP version.
>
> Have you considered keeping the support matrix in the registry 
> database, instead of in pecl.json? Then it can be updated with new 
> build/test information after release.

Yeah, I understand. And I feel the same. But if there is no registry (a 
goal), then there is no way to find out which of your extension version 
support a specific PHP version, without checking every tag in your 
repository. That's not going to be fast.

cheers,
Derick

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

Re: [PHP-DEV] [RFC] Collecting All Policies Into One Repository

[Derick Rethans]

On Tue, 5 Dec 2023, Larry Garfield wrote:

> On Tue, Dec 5, 2023, at 11:06 AM, Derick Rethans wrote:
> > Hi!
> >
> > A while ago I started looking into all the documents (RFCs etc) that we 
> > have that relate to all sort of policies. From RFCs, to who can vote, 
> > naming, and security classifications as a result of a discussion with 
> > the foundations folk.
> >
> > Now there was another small confusion during a recent vote, we came up 
> > with the idea to actually go forwards with this, and make all our lives 
> > easier by having one place where all these documents are located.
> >
> > Hence I have created a (beta) repository and collected that information:
> > https://github.com/php/policies
> >
> > The contents are copied verbitim from RFCs, without any editing. Some 
> > RFCs made it into a single file as IMO they belonged together.
> >
> > I have also created an RFC to establish this location, as changing 
> > policies and RFCs require an RFC:
> > https://wiki.php.net/rfc/policy-repository
> >
> > The contents are probably not exhaustive, and it is entirely possible 
> > that it does not include all information. I would therefore be greatful 
> > if you could have a look at the RFC, the collated documents, and let me 
> > know whether I missed anything, or whether you are missing something we 
> > might not even have written down yet.
> >
> > I am hoping that the discussion to establish this repository is 
> > straightforwards. Further steps will include: editing the documents so 
> > that they read as documents, and not copy-pasted content with RFC 
> > language, and including our existing coding standards.
> 
> Thank you for this, Derick!  I very much support this initiative and 
> look forward to it.
> 
> > Should the historical information in “release process” be moved out 
> > of release-process to a dedicated file?
> 
> I would say yes.  The ideal structure of the document (once edited 
> down) would be a snapshot of "how things work right now."  Historical 
> alternatives should either be just git history or a separate 
> non-normaitive set of files.

Fair enough. I also tended to go that way.

> I would also ask, does this mean future changes to process would be 
> submitted and reviewed as a PR against this repo, with the RFC for it 
> being mostly a placeholder for "vote on this PR", with explanation?  
> I would assume so, but it would be good to make that explicit.

The RFC currently has "RFCs to add or amend to policy would then target 
additions or modification of the documents in this repository, instead 
of having them just as RFC text." so that was my intention. I've updated 
the text to make this a little clearer though.

cheers,
Derick

-- 
https://derickrethans.nl | https://xdebug.org | https://dram.io

Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support
Host of PHP Internals News: https://phpinternals.news

mastodon: @derickr@phpc.social @xdebug@phpc.social
twitter: @derickr and @xdebug

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

Re: [PHP-DEV] bugs.php.net still active?

[Derick Rethans]

On Thu, 7 Dec 2023, Aleksander Machniak wrote:

> I was under impression that bugs.php.net was supposed to be phased 
> out. I.e. made read-only or something.
> 
> https://bugs.php.net/bug.php?id=78628=1 proves that it's not the 
> case and I'm receiving annoying spam recently.

It's closed for new tickets, but not for updating tickets (or adding 
comments).

cheers,
Derick

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

[PHP-DEV] New "PECL"

[Derick Rethans]

Hi there!

Within the PHP Foundation, we have been talking for a while as what to 
do with PECL, and its website.

The code is old, and hard to maintain. And the database is full of 
mojibake. It is also an outdated method of installing things, especially 
because userland code is so much easier to handle through Composer.

Through the Sovereign Tech Fund (https://www.sovereigntechfund.de/) the 
Foundation has acquired some funding to improve this situation.

Hence, to start of replacing PECL with something applicable for this 
decade, we started working on a requirements document:

https://docs.google.com/document/d/1_N0E9xo3jn9aKrIZHIbTYaY5lXw71BpSO6-it4cRpDo

In this first stage, we would like to invite you in commenting on the 
document (either inline, or here).

Please keep in mind that this is a requirements document, and should not 
contain either design or implementation details. Once we have thought 
about these details as well, this will be turned into an RFC.

cheers,
Derick

-- 
https://derickrethans.nl | https://xdebug.org | https://dram.io

Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support
Host of PHP Internals News: https://phpinternals.news

mastodon: @derickr@phpc.social @xdebug@phpc.social
twitter: @derickr and @xdebug

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

[PHP-DEV] [RFC] Collecting All Policies Into One Repository

[Derick Rethans]

Hi!

A while ago I started looking into all the documents (RFCs etc) that we 
have that relate to all sort of policies. From RFCs, to who can vote, 
naming, and security classifications as a result of a discussion with 
the foundations folk.

Now there was another small confusion during a recent vote, we came up 
with the idea to actually go forwards with this, and make all our lives 
easier by having one place where all these documents are located.

Hence I have created a (beta) repository and collected that information:
https://github.com/php/policies

The contents are copied verbitim from RFCs, without any editing. Some 
RFCs made it into a single file as IMO they belonged together.

I have also created an RFC to establish this location, as changing 
policies and RFCs require an RFC:
https://wiki.php.net/rfc/policy-repository

The contents are probably not exhaustive, and it is entirely possible 
that it does not include all information. I would therefore be greatful 
if you could have a look at the RFC, the collated documents, and let me 
know whether I missed anything, or whether you are missing something we 
might not even have written down yet.

I am hoping that the discussion to establish this repository is 
straightforwards. Further steps will include: editing the documents so 
that they read as documents, and not copy-pasted content with RFC 
language, and including our existing coding standards.


cheers,
Derick


-- 
https://derickrethans.nl | https://xdebug.org | https://dram.io

Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support
Host of PHP Internals News: https://phpinternals.news

mastodon: @derickr@phpc.social @xdebug@phpc.social
twitter: @derickr and @xdebug

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

Re: [PHP-DEV] [VOTE] [RFC] Final anonymous classes

[Derick Rethans]

On 3 December 2023 14:49:12 GMT, Nikita Popov  wrote:
>On Sun, Dec 3, 2023, at 11:40, Daniil Gentili wrote:
>> Hi all,
>> 
>> I've just opened voting for the final anonymous classes RFC @ 
>> https://wiki.php.net/rfc/final_anonymous_classes.
>> 
>> Voting started now, and will run until December 18th 2023, 00:00 GMT.
>
>For the record, I've voted against this proposal because I believe it should 
>have gone with option 2, that is to *always* make anonymous classes final.
>
>It makes very little sense to me that everyone needs to explicitly mark their 
>anonymous classes as final just because there is a class_alias loophole that 
>could, in theory, have been used to extend anonymous classes in the past. 
>Especially given that there is no evidence of this "feature" being used in the 
>wild (or if there is such evidence, it was not presented in the proposal).
>
>Regards,
>Nikita
I agree with this, and would also say that this RFC is the most thin one I've 
seen.

There is no reasoning, or examples, or pretty much anything else in it. 

cheers
Derick

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

Re: [PHP-DEV] [RFC] [VOTE] Change the edge case of round()

[Derick Rethans]

On 24 November 2023 00:31:16 GMT, Saki Takamachi  wrote:
>Hi internals,
>
>I started voting on my RFC "Change the edge case of round()”.
>
>Voting will end December 8th, 00:00 GMT.
>
>https://wiki.php.net/rfc/change_the_edge_case_of_round
>
>Regards.
>
>Saki
>--
>PHP Internals - PHP Runtime Development Mailing List
>To unsubscribe, visit: https://www.php.net/unsub.php

I've voted no, but only because I think that because this is technically a 
documented (through RFC) BC break, it should wait for PHP 9, and not for any 
8.*.

cheers
Derick

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

Re: [PHP-DEV] Reproducible Builds

[Derick Rethans]

On 29 November 2023 00:48:28 GMT, Matthew Weier O'Phinney 
 wrote:
>On Tue, Nov 28, 2023, 5:28 PM Derick Rethans  wrote:
>
>> On 28 November 2023 17:28:18 GMT, Sebastian Bergmann 
>> wrote:
>>
>> >While we could probably replace __DATE__ and __TIME__ with
>> SOURCE_DATE_EPOCH [3] [4], I cannot help but wonder whether having the date
>> and time when the executable was built in the executable is actually
>> useful. How attached are we to having the date and time of the build in the
>> output of phpinfo(), "php -i", etc.?
>>
>> It is really useful for the development versions of PHP. Knowing whether
>> your are running a PHP-dev from last week or last month is important.
>
>
>Would Marco's suggestion of using a git hash solve that? You'd then get
>both a reproducible build AND know when/what it was generated from.
>
>>
>>
>>
>>

Not really, as a hash doesn't directly tell me the date/time, and neither would 
it help in dev branches / checkouts where the latest changes haven't been 
comiited yet.

cheers
Derick

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

Re: [PHP-DEV] Reproducible Builds

[Derick Rethans]

On 28 November 2023 17:28:18 GMT, Sebastian Bergmann  wrote:

>While we could probably replace __DATE__ and __TIME__ with SOURCE_DATE_EPOCH 
>[3] [4], I cannot help but wonder whether having the date and time when the 
>executable was built in the executable is actually useful. How attached are we 
>to having the date and time of the build in the output of phpinfo(), "php -i", 
>etc.?

It is really useful for the development versions of PHP. Knowing whether your 
are running a PHP-dev from last week or last month is important. 

For released versions, not so much. 

cheers
Derick 

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

Re: [PHP-DEV] Debian Upgrade

[Derick Rethans]

On Mon, 20 Nov 2023, Derick Rethans wrote:

> On 20 November 2023 21:37:55 GMT, Rowan Tommins  
> wrote:
> >On 15/11/2023 16:59, Derick Rethans wrote:
> >> In the last few days, I have upgrade all our Digital Ocean droplets from
> >> Debian 10 (or 9!) to 12. That also means they now run PHP 8.2.
> >
> >Thanks for getting things current! System maintenance is such an 
> >essential but often underappreciated task.
> >
> >I notice news.php.net (and therefore externals.io, which feeds from 
> >it) hasn't copied any message from the list since the day after you 
> >posted this (last timestamp is 16 Nov 2023 22:14:19 -). Could 
> >that be related somehow?
> >
> >Or if it's just coincidence, maybe you or someone else here knows 
> >which service might need prodding to bring it back to life?
> 
> Yes, this could be related. Somebody on the foundation slack raised it 
> too, so I'll have a look ASAP.

I have fixed this now.

It turned out to be a bug in *bugs.php.net*, which I had fixed 
yesterday:
https://github.com/php/web-bugs/commit/9ed00f752fb1f82a93ed08a13f45219e5723c0d0

Without this fix, emails sent to the bugs (and docs-bugs) mailinglists 
had very long "From" addresses.

Colobus, the tool that parses the mailinglists and creates the news 
interface and NNTP server, had a MySQL column defined for this to 
varchar(255). Usually enough, but it was now bailing out.

The "fix" was to change that column to "text" — not pretty, but better 
than hacking the mailinglist software's index.

cheers,
Derick

-- 
https://derickrethans.nl | https://xdebug.org | https://dram.io

Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support
Host of PHP Internals News: https://phpinternals.news

mastodon: @derickr@phpc.social @xdebug@phpc.social
twitter: @derickr and @xdebug

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

Re: [PHP-DEV] Debian Upgrade

[Derick Rethans]

On 20 November 2023 21:37:55 GMT, Rowan Tommins  wrote:
>On 15/11/2023 16:59, Derick Rethans wrote:
>> In the last few days, I have upgrade all our Digital Ocean droplets from
>> Debian 10 (or 9!) to 12. That also means they now run PHP 8.2.
>
>
>Hi Derick,
>
>Thanks for getting things current! System maintenance is such an essential but 
>often underappreciated task.
>
>I notice news.php.net (and therefore externals.io, which feeds from it) hasn't 
>copied any message from the list since the day after you posted this (last 
>timestamp is 16 Nov 2023 22:14:19 -). Could that be related somehow?
>
>Or if it's just coincidence, maybe you or someone else here knows which 
>service might need prodding to bring it back to life?
>
>Regards,
>

Yes, this could be related. Somebody on the foundation slack raised it too, so 
I'll have a look ASAP.

cheers
Derick

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

Re: [PHP-DEV] [VOTE] [RFC] Unbundle ext/imap, ext/pspell, ext/oci8, and ext/PDO_OCI

[Derick Rethans]

On Wed, 1 Nov 2023, Derick Rethans wrote:

> I have just opened voting on the RFC to unbundle imap, pspell, and 
> oracle integrations.
> 
> Each extension can be voted on separately. Voting started now, and 
> will run until November 15th, 24:00 GMT.
> 
> Link: https://wiki.php.net/rfc/unbundle_imap_pspell_oci8#voting

Voting is now closed, with unbundling imap and pspell passing 
unanimously (27:0) and unbundling oracle integrations passing with 
(26:1).

I will soon start making PRs to implement this result.

cheers,
Derick

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

[PHP-DEV] Debian Upgrade

[Derick Rethans]

Hi!

In the last few days, I have upgrade all our Digital Ocean droplets from 
Debian 10 (or 9!) to 12. That also means they now run PHP 8.2.

I have not encountered any problems, but if you do, please let me know!

cheers,
Derick

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

Re: [PHP-DEV] [RFC] [Discussion] Resource to object conversion

[Derick Rethans]

On 12 November 2023 16:47:37 GMT, "Máté Kocsis"  wrote:
>Hi Internals,
>
>Following my straw poll about the Process resource name, I would like to
>present an RFC which clarifies the rough timeline and the BC promises of
>the "resource to object conversion" project.
>
>Link: https://wiki.php.net/rfc/resource_to_object_conversion
>
>I'm looking forward to your feedback!




I don't really have any comments beyond that everything stream related should 
happen at the same time.

I think I would prefer ProcessHandle and all streams related change to happen 
with 9.0.

As to COM, I dont think many people at going to notice this, as I doubt it'd be 
in much use.

Did you do an analyses as to how much either of these changes could break 
anything?

cheers
Derick

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

Re: [PHP-DEV] [RFC] [Discussion] Release cycle update

[Derick Rethans]

On 10 November 2023 23:27:35 GMT, Rowan Tommins  wrote:
>On 10 November 2023 16:51:57 GMT, Jakub Zelenka  wrote:
>>Hello,
>>
>>I would like to propose a new process RFC for updates to PHP release cycle:
>>
>>https://wiki.php.net/rfc/release_cycle_update
>
>Hi,
>
>I started writing a suggestion that you add details to your RFC of what text 
>we would remove or change in the existing policy if approved - what you've 
>presented so far is like a good commit message, but we probably want a diff to 
>go with it.
>
>However, looking at the existing "policy", most of the things you want to 
>change aren't actually in it - it doesn't even contain the word "beta". It 
>also has parts that are obviously outdated ("Features can use branch(es) if 
>necessary" - because the project was using SVN, where branches are costly to 
>maintain), parts in the future tense, and even open questions (about who can 
>vote for RMs).
>
>So maybe what's really needed is to draft a new copy of the policy document, 
>updating or removing those parts that are no longer relevant, and adding a 
>timeline for the pre-release phases?
>
>Or possibly there's a different document I should be looking at, and the RFC 
>could contain proposed edits to that?
>
>Regards,
>

I already have been collecting most of the policy things together in one 
document:

https://docs.google.com/document/d/1Wc84ZxHHamvWsZl-U2kFOrbJDEXyXFv1laePN4ijJGQ/edit?usp=drivesdk

For the same reasons really. The info was spread out a lot.

cheers
Derick

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

Re: [PHP-DEV] [RFC] [Discussion] Release cycle update

[Derick Rethans]

On 10 November 2023 20:22:27 GMT, Jakub Zelenka  wrote:
>Hi,
>
>On Fri, Nov 10, 2023 at 5:56 PM Ilija Tovilo  wrote:
>
>I think there should be a clear cut when the RFC can be implemented and
>there should be probably still time to apply ABI breaking changes after
>that time. So we could potentially decrease the time for the RFC
>implementation needs to be merged. Maybe something like this:
>
>- 2 alphas - think 2 are enough as each RM can try one release.
>- 4 betas and require that all RFC has to be merged before beta3 is
>released. It means we would have 2 extra betas to iron out all RFC issues
>and still be able to introduce ABI breaks
>- 4 RC - real feature freeze without any ABI or API breaks
>
>What do you think?



I think that makes sense. 

cheers
Derick

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

[PHP-DEV] [VOTE] [RFC] Unbundle ext/imap, ext/pspell, ext/oci8, and ext/PDO_OCI

[Derick Rethans]

Hi,

I have just opened voting on the RFC to unbundle imap, pspell, and 
oracle integrations.

Each extension can be voted on separately. Voting started now, and will 
run until November 15th, 24:00 GMT. 

Link:
https://wiki.php.net/rfc/unbundle_imap_pspell_oci8#voting

cheers,
Derick

-- 
https://derickrethans.nl | https://xdebug.org | https://dram.io

Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support
Host of PHP Internals News: https://phpinternals.news

mastodon: @derickr@phpc.social @xdebug@phpc.social
twitter: @derickr and @xdebug

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

Re: [PHP-DEV] Re: [RFC][Under discussion] RFC1867 for non-POST HTTP verbs

[Derick Rethans]

On Fri, 13 Oct 2023, Ilija Tovilo wrote:

> On Fri, Oct 6, 2023 at 3:44 PM Ilija Tovilo  wrote:
> > https://wiki.php.net/rfc/rfc1867-non-post
> 
> Thank you for the feedback so far. I made a handful of changes to the RFC.

…

> Let me know if you have any more feedback.

The only comment I would have is that I probably would be in favour of 
not leaving the "config" argument (to over ride per call the 
post_max_size settings etc) to a future scope.

Having to do ini_get/ini_set/ini_set(old) to override these settings 
seems clunky.

cheers,
Derick

-- 
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

[Derick Rethans]

On Fri, 6 Oct 2023, Tim Düsterhus wrote:

> 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)?

I don't think that reading potentially large files into memory is a 
great idea. It is precisely because of the memory issue that PHP's 
existing POST handler writes files to disk, instead of leaving their 
content available through an entry in $_FILES.

cheers,
Derick

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

Re: [PHP-DEV] Proposal to unbundle imap/pspell/oci8 extensions for PHP 8.4

[Derick Rethans]

On Thu, 28 Sep 2023, Jakub Zelenka wrote:

> On Wed, Sep 27, 2023, 14:14 Derick Rethans  wrote:
> 
> > The ext/imap extension isn't going to disappear, it is going be 
> > unbundled as we can not guarantee the underlaying library is 
> > maintained. Not only is it no longer maintained, the original 
> > purveyors have removed any mention of it from their website.
> >
> > For most people, there will be little change here. On Debian for 
> > example, "php-" is used for both bundled and PECL'ed 
> > extensions.
> >
> 
> Although it's unlikely that it gets any maintainer so it will most 
> likely stop building and won't be available in the future PHP 
> versions. I think we should be clear about this and note that those 
> extensions will no longer be supported by PHP core dev team which 
> likely means their end at some point in the future unless someone 
> steps in to maintain them.

I have added words describing that to the RFC.

cheers,
Derick

-- 
https://derickrethans.nl | https://xdebug.org | https://dram.io

Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support
Host of PHP Internals News: https://phpinternals.news

mastodon: @derickr@phpc.social @xdebug@phpc.social
twitter: @derickr and @xdebug

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

Re: [PHP-DEV] Re: [External] : [RFC} Unbundle ext/imap, ext/pspell, and ext/oci8

[Derick Rethans]

On Thu, 28 Sep 2023, Christopher Jones wrote:

> 
> On 27/9/2023 11:27 pm, Derick Rethans wrote:
> > Hi,
> > 
> > after the initial introduction, here is the formal RFC to unbundle the
> > imap, pspell, and oci8 extensions and move them to PECL, for PHP 8.4.
> > 
> > https://wiki.php.net/rfc/unbundle_imap_pspell_oci8
> 
> A small point: the bug URL for OCI8 in the RFC includes issues for 
> PDO_OCI - which is not part of the RFC.

Sorry, that was an oversight on my side, as I had intended (for similar 
reasons as ext/oci8), to also unbundle it.

cheers,
Derick

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

Re: [PHP-DEV] proc_open() resource to opaque object migration

[Derick Rethans]

On 28 September 2023 21:19:47 BST, "Máté Kocsis"  wrote:
>Hi Everyone,
>
>I'm writing in connection with a question coming up lately during the
>"resource to opaque object migration" project (
>https://github.com/php/php-tasks/issues/6) which we have been working on
>for quite a long while.
>
>During the review of my PR migrating the resource returned by proc_open()
>to an object (https://github.com/php/php-src/pull/12098), it quickly became
>evident that there was no consensus about the new class name, since the
>originally proposed "Process" name has a non-negligible BC break likelihood.
>
>That's why we should find the best class name in accordance with Nikita's
>namespace naming convention RFC (
>https://wiki.php.net/rfc/namespaces_in_bundled_extensions). Even though my
>PR currently implements "Standard\Process", this name is not a good
>candidate according to the policy:
>
>Because these extensions combine a lot of unrelated or only tangentially
>> related functionality, symbols should not be namespaced under the Core,
>> Standard or Spl namespaces. Instead, these extensions should be considered
>> as a collection of different components, and should be namespaced according
>> to these.
>
>
>Does anyone have a good suggestion?
>
>Thanks,
>Máté

Yes, lacking evidence that the name is actually being used: Process

PHP "owns" the top level namespace. This has been documented for decades, too. 

cheers
Derick

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

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

[Derick Rethans]

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 time) be the
>   one to digitally sign this file after making changes.

Please document how to do that. 

cheers 
Derick 

--
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

[Derick Rethans]

On Tue, 26 Sep 2023, Larry Garfield wrote:

>  ceil and floor should 
> always return ints, unconditionally, because that's literally what 
> their purpose is.  But that RFC doesn't say that, which makes me quite 
> confused.

They can't do that. ceil(2.4e102) can't be repesented as an integer.

> Similarly, the BC shim would therefore be (float)ceil($x), not 
> ceil((float)$x), which... I don't think that would even do anything, 
> would it?

(float) $int *could* also do something:

$ php -dprecision=20 -r 'echo (float) 1152921504606846974;'

1152921504606846976

$ php -dprecision=20 -r 'var_dump(ceil((float) 1152921504606846974));'

double(1152921504606846976)

(see how the 74 changes into 76 at the end).

Integers in the ranges LONG_MAX to 2^53, and -2^53 to LONG_MIN can't be 
represented as whole numbers as float, and some precision is lost.

cheers,
Derick

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

[PHP-DEV] [RFC} Unbundle ext/imap, ext/pspell, and ext/oci8

[Derick Rethans]

Hi,

after the initial introduction, here is the formal RFC to unbundle the 
imap, pspell, and oci8 extensions and move them to PECL, for PHP 8.4.

https://wiki.php.net/rfc/unbundle_imap_pspell_oci8

cheers,
Derick

-- 
https://derickrethans.nl | https://xdebug.org | https://dram.io

Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support
Host of PHP Internals News: https://phpinternals.news

mastodon: @derickr@phpc.social @xdebug@phpc.social
twitter: @derickr and @xdebug

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

Re: [PHP-DEV] Proposal to unbundle imap/pspell/oci8 extensions for PHP 8.4

[Derick Rethans]

On Fri, 15 Sep 2023, BohwaZ wrote:

> > Considering the lack of updates from upstream as Derick mentioned, 
> > lack of OAuth support (which webklex/php-imap supports), and a 
> > somewhat lackluster documentation for ext-imap in php.net, I think 
> > unbundling ext-imap (along with the other extensions in the 
> > proposal) makes sense.
> 
> I don't think that OAuth support is an argument, as most providers 
> don't support OAuth, so the imap package might still be relevant for 
> people who are not using Google.
> 
> Also, the package currently works, IMAP is a stable protocol, maybe 
> this library is just stable?
> 
> I'm not against the removal, but having to rely on user-space 
> libraries probably means we'll lose some performance over using the C 
> library.
> 
> Also, some widely-used libraries like php-imap use it: 
> https://packagist.org/packages/php-imap/php-imap

The ext/imap extension isn't going to disappear, it is not going be 
unbundled as we can not guarantee the underlaying library is maintained. 
Not only is it no longer maintained, the original purveyors have removed 
any mention of it from their website.

For most people, there will be little change here. On Debian for 
example, "php-" is used for both bundled and PECL'ed 
extensions.

> Personally I'm using curl for IMAP, as it is more widely available, 
> but I think removing php-imap might be a bit too early, except if 
> keeping it does require a lot of time / effort?

Using Curl seems like a bad alternative, as it would likely have to open 
a connection for each action that you do.

cheers,
Derick

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

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

[Derick Rethans]

On Sat, 23 Sep 2023, Niels Dossche wrote:

> On 9/2/23 21: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
> 
> Some minor changes after a discussion with Tim:
> 
> * The old class names are now written with a leading backslash to
>   emphasize they are in the global namespace. Hopefully this will resolve
>   confusion around them.
>
> * Fixed unclear wording, i.e. "type hint" -> "type declaration"
>
> * The alias for DOMException will be DOM\DOMException. Because that's the
>   official name per DOM spec, and otherwise importing it and using it
>   would be confusing with the global namespace Exception class
>   (see also
>   https://github.com/php/php-src/pull/9071#issuecomment-1193162754 for
>   precedent).

I have just read the RFC, and I find it both well written and compelling 
to accept. +1 from me.

cheers,
Derick

-- 
https://derickrethans.nl | https://xdebug.org | https://dram.io

Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support
Host of PHP Internals News: https://phpinternals.news

mastodon: @derickr@phpc.social @xdebug@phpc.social
twitter: @derickr and @xdebug

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

[PHP-DEV] Security Audit Priorities

[Derick Rethans]

Hi,

The Foundation is organising an external audit/security check of the PHP 
source code. As part of that, we would like to identify the places in 
the PHP source code where checking this will have the most impact.

Typical areas would be where user input can be (automatically read) remotely, 
such as 
our RFC 1867 HTTP header parser. But we are sure there are other 
important areas as well, and we would like your input.

So, if you can suggest an area where doing an external review would have 
high impact, please reply to this email.

cheers,
Derick

-- 
https://derickrethans.nl | https://xdebug.org | https://dram.io

Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support
Host of PHP Internals News: https://phpinternals.news

mastodon: @derickr@phpc.social @xdebug@phpc.social
twitter: @derickr and @xdebug

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

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

[Derick Rethans]

Hi Dmitry,

On Fri, 15 Sep 2023, Dmitry Stogov wrote:

> After the code-review feedback, one of the most questionable decisions 
> was changed.
>
> Instead of including IR Framework as a git submodule, now its part is 
> embedded into php-src.
>
> This will complicate the IR/JIT development a bit, but will simplify 
> things for everyone else.
> 
> I'm going to merge https://github.com/php/php-src/pull/12079 into 
> master next week.

I think this is great work. It looks like the new JIT-IR approach is 
more suitable. I have however concerns with a few things here.

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 its continued development.

As such, I don't think this should just be merged, without a 
comprehensive document explaining what it is, how it works, what pitfalls 
there are, etc. The natural process that we have for PHP would be to 
create an RFC.

An RFC should also include a user-facing API on how to configure, and 
enable, the JIT and its optimisations, as our current implementation 
it is not the most convenient for users.

I understand that working on an RFC for such a complex issue is going to 
take time, but that also gives to opportunity to pair with somebody, 
who, while writing it, will also learn how it works. That would also 
ready improve the debugging/contributing issues.

Separately, I am not sure why your PR couldn't just replace the JIT that 
we already have? It would IMO not make sense to have two different ones 
at the same time.

Furthermore, I am curious as if you have already done some benchmarks. I 
am curious to learn how well it makes non-benchmark code run faster.

cheers,
Derick

-- 
https://derickrethans.nl | https://xdebug.org | https://dram.io

Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support
Host of PHP Internals News: https://phpinternals.news

mastodon: @derickr@phpc.social @xdebug@phpc.social
twitter: @derickr and @xdebug

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

[PHP-DEV] Proposal to unbundle imap/pspell/oci8 extensions for PHP 8.4

[Derick Rethans]

Hi,

In a recent chat between the PHP Foundation developers, we discussed 
unbundling several extensions.


ext/imap

The library that provides the functionality in this extension, c-client, 
is no longer updated. The last release from 2007 is no longer available 
on the original distributor's (University of Washington) website, but 
there is an unofficial GitHub repository that hasn't been updated for 5 
years either (https://github.com/uw-imap/imap).

You can't also use this any more with G Suite due to authentication 
changes (https://github.com/uw-imap/imap/issues/4).

There are several user-land packages that are still maintained, and 
provide superior functionality:

- https://github.com/PHPMailer/PHPMailer
- https://github.com/zetacomponents/Mail/
- https://github.com/symfony/mailer
- https://github.com/laminas/laminas-mail


ext/pspell

The original underlying library hasn't been updated since 2001 
(https://en.wikipedia.org/wiki/Pspell) and it's replacement, aspell not 
since 2019 (https://ftp.gnu.org/gnu/aspell/).

There are other replacements, ispell, and hunspell, but they don't seem 
to be compatible API-wise. The PECL extension "enchant" was supposed 
to be able to use with all of these, but is also no longer maintained 
(last release in 2009, https://pecl.php.net/package/enchant).

Again, there are several user land composer packages 
(https://packagist.org/?query=spell) that can be used instead.


ext/oci8

Requires a proprietary library from large commercial enterprise
(https://www.oracle.com/database/technologies/instant-client.html) and 
has many outstanding bugs:
https://bugs.php.net/search.php?cmd=display_name[]=PDO+OCI_name[]=OCI8+related_name[]=Oracle+related_by=ts1=ASC=30=Open_by=ts1
https://github.com/php/php-src/labels/Extension%3A%20oci8

Most of the recent changes were all to skip tests.

It is also one of the larger extensions left that had not had their 
resource type converted to objects. This is a major effort, and frankly, 
probably something that should be done by the corporate sponsor of the 
oracle extensions.


Please remember, that unbundling extensions does not mean that they 
disappear. They will be moved to PECL with a release made.

An RFC will of course be forthcoming, but we thought it best to email 
the list first.


cheers,
Derick

-- 
https://derickrethans.nl | https://xdebug.org | https://dram.io

Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support
Host of PHP Internals News: https://phpinternals.news

mastodon: @derickr@phpc.social @xdebug@phpc.social
twitter: @derickr and @xdebug

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

[PHP-DEV] Re: [PECL-DEV] PHP Servers SSL Certificate Expiry

[Derick Rethans]

Hi,

I (and Rasmus) have now updated TLS certificates on all the servers that 
I am aware off (and have access to). They are now automated with Let's 
Encrypt. I also have a todo item every month to check whether the certs 
actually renewed.

If there are currently still *.php.net sites that have HTTPS errors, 
please do let me know.

cheers,
Derick

On Mon, 11 Sep 2023, Derick Rethans wrote:

> Hi All,
> 
> We're aware that this has happened. The process that we set-up a three 
> months ago with Let's Encrypt was not fully implemented. 
> 
> There is no need to report this again, and I will update these lists 
> when it is addressed.
> 
> It does not affect www.php.net, but it does affect:
> 
>  pecl.php.net
>  pear.php.net
>  talks.php.net
>  master.php.net (which effects many other integrations as well)
>  bugs.php.net
>  and likely others.
> 
> cheers,
> Derick
> 
> 

-- 
https://derickrethans.nl | https://xdebug.org | https://dram.io

Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support
Host of PHP Internals News: https://phpinternals.news

mastodon: @derickr@phpc.social @xdebug@phpc.social
twitter: @derickr and @xdebug

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

Re: [PHP-DEV] PHP Servers SSL Certificate Expiry

[Derick Rethans]

On 11 September 2023 16:16:45 BST, tag Knife  wrote:
>Hi Derick,
>
>Is there any reason why PHP does not use an automated certificate renewal
>for lets encrypt?
>Such as EFF-ACME-Certbot? [https://certbot.eff.org/]

We do, but we need to coordinate the same cert onto multiple servers, which is 
the process that isn't set up correctly yet. 

cheers 
Derick 


>On Mon, 11 Sept 2023 at 15:55, Derick Rethans  wrote:
>
>> Dear All,
>>
>> pecl.php.net now has a valid SSL/TLS certificate again. And it turns out
>> that pear.php.net was not affected.
>>
>> The other services do not have an updated certificate yet, but this
>> should be rolled out in the next few days.
>>
>> with kind regards,
>> Derick Rethans
>>
>> On Mon, 11 Sep 2023, Derick Rethans wrote:
>>
>> > Hi All,
>> >
>> > We're aware that this has happened. The process that we set-up a three
>> > months ago with Let's Encrypt was not fully implemented.
>> >
>> > There is no need to report this again, and I will update these lists
>> > when it is addressed.
>> >
>> > It does not affect www.php.net, but it does affect:
>> >
>> >  pecl.php.net
>> >  pear.php.net
>> >  talks.php.net
>> >  master.php.net (which effects many other integrations as well)
>> >  bugs.php.net
>> >  and likely others.
>> >
>> > cheers,
>> > Derick
>> >
>> >
>>
>> --
>> https://derickrethans.nl | https://xdebug.org | https://dram.io
>>
>> Author of Xdebug. Like it? Consider supporting me:
>> https://xdebug.org/support
>> Host of PHP Internals News: https://phpinternals.news
>>
>> mastodon: @derickr@phpc.social @xdebug@phpc.social
>> twitter: @derickr and @xdebug
>>
>> --
>> 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

Re: [PHP-DEV] PHP Servers SSL Certificate Expiry

[Derick Rethans]

Dear All,

pecl.php.net now has a valid SSL/TLS certificate again. And it turns out 
that pear.php.net was not affected. 

The other services do not have an updated certificate yet, but this 
should be rolled out in the next few days.

with kind regards,
Derick Rethans

On Mon, 11 Sep 2023, Derick Rethans wrote:

> Hi All,
> 
> We're aware that this has happened. The process that we set-up a three 
> months ago with Let's Encrypt was not fully implemented. 
> 
> There is no need to report this again, and I will update these lists 
> when it is addressed.
> 
> It does not affect www.php.net, but it does affect:
> 
>  pecl.php.net
>  pear.php.net
>  talks.php.net
>  master.php.net (which effects many other integrations as well)
>  bugs.php.net
>  and likely others.
> 
> cheers,
> Derick
> 
> 

-- 
https://derickrethans.nl | https://xdebug.org | https://dram.io

Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support
Host of PHP Internals News: https://phpinternals.news

mastodon: @derickr@phpc.social @xdebug@phpc.social
twitter: @derickr and @xdebug

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

[PHP-DEV] PHP Servers SSL Certificate Expiry

[Derick Rethans]

Hi All,

We're aware that this has happened. The process that we set-up a three 
months ago with Let's Encrypt was not fully implemented. 

There is no need to report this again, and I will update these lists 
when it is addressed.

It does not affect www.php.net, but it does affect:

 pecl.php.net
 pear.php.net
 talks.php.net
 master.php.net (which effects many other integrations as well)
 bugs.php.net
 and likely others.

cheers,
Derick

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

Re: [PHP-DEV] Security Bugs on GitHub

[Derick Rethans]

On Wed, 30 Aug 2023, Tim Düsterhus wrote:

> Hi
> 
> On 8/30/23 11:05, Derick Rethans wrote:
> > However, our old bug system still accepts them. I have just created a
> > PR to change that: https://github.com/php/web-bugs/pull/116/files
> > 
> > Pending reviews and/or comments, I am wanting to merge this in the next
> > week or so.
> > 
> 
> There's already https://github.com/php/web-bugs/pull/115. See also:
> https://news-web.php.net/php.internals/120672

I wasn't aware, so I will merge that one!

cheers,
Derick

-- 
https://derickrethans.nl | https://xdebug.org | https://dram.io

Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support
Host of PHP Internals News: https://phpinternals.news

mastodon: @derickr@phpc.social @xdebug@phpc.social
twitter: @derickr and @xdebug

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

[PHP-DEV] Security Bugs on GitHub

[Derick Rethans]

Hi,

In the past few months we have been trialing using GitHub security 
advisories for security issues:
https://github.com/php/php-src/security/advisories?state=published

However, our old bug system still accepts them. I have just created a 
PR to change that: https://github.com/php/web-bugs/pull/116/files

Pending reviews and/or comments, I am wanting to merge this in the next 
week or so.

cheers,
Derick

-- 
https://derickrethans.nl | https://xdebug.org | https://dram.io

Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support
Host of PHP Internals News: https://phpinternals.news

mastodon: @derickr@phpc.social @xdebug@phpc.social
twitter: @derickr and @xdebug

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

Re: [PHP-DEV] PHP-8.3 branch creation

[Derick Rethans]

On 24 August 2023 13:27:47 BST, Jakub Zelenka  wrote:
>Hello,
>
>This is just a reminder that the PHP-8.3 git branch will be created on
>Tuesday 29th Aug 2023. It means that the fixes for 8.3 will need to target
>PHP-8.3 branch and master will be essentially for PHP 8.4. Also don't
>forget to merge PHP-8.2 into PHP-8.3 and then PHP-8.3 to master for all
>fixes after the branch is created.
>
>Regards
>
>Jakub

Please make sure update all the version numbers and zend/php/zend extension API 
numbers.

Also I noticed that the master branch still uses 8.3.0-dev, where it ought to 
have been 8.3.0RC1-dev by now (always the next one with -dev).

cheers
Derick

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

[PHP-DEV] Upgraded Debian on people.php.net

[Derick Rethans]

Hi,

I have just upgraded the Debian version on svn2 (people, talks, gtk) to 
Buster — solving the problem with people not working due to SSL 
certificate issues.

I also had to upgrade PHP — it was running PHP 5.6 (now 7.3, as that 
comes with Debian Buster). Which also meant I had to upgrade the 
globally installed PEAR packages (notably XML_Parser) as that was using 
PHP 4 syntax (yes, really) in the form of:

$x =  …

The sites should all work now, but please let me know if there are still 
issues with gkt.php.net, talks.php.net, or people.php.net!

cheers,
Derick

-- 
https://derickrethans.nl | https://xdebug.org | https://dram.io

Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support
Host of PHP Internals News: https://phpinternals.news

mastodon: @derickr@phpc.social @xdebug@phpc.social
twitter: @derickr and @xdebug

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

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

[Derick Rethans]

On 17 July 2023 17:40:06 BST, Ben Ramsey  wrote:
>> 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 them.
>>> 
>>> Cheers,
>>> Gabriel
>> Aa it seems nobody objected and feature freeze is this week, I'm going to 
>> merge this PR.
>
>
>Did you see this other thread that somehow got created separate from this 
>thread?
>
>https://externals.io/message/120811



I did. But that deals with an issue that is already present in the current 
implementation. This PR does not effect that at all.

cheers
Derick

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

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

[Derick Rethans]

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 them.
>
>Cheers,
>Gabriel
Aa it seems nobody objected and feature freeze is this week, I'm going to merge 
this PR.

cheers
Derick

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

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

[Derick Rethans]

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_request = ${PHP_XDEBUG_START_WITH_REQUEST:-default}

This is a syntax that bash also supports.

Ilija pointed out an already existing PR 
(https://github.com/php/php-src/pull/11351) which had been extensively 
reviewed. Its author never seem to have emailed the list, so here I am. 
I would like to see this in PHP 8.3, and don't see the need for an RFC.

If there are no objects, I'll merge this in the next few days.

cheers,
Derick

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

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

[Derick Rethans]

On Mon, 19 Jun 2023, Nicolas Grekas wrote:

> > > On my side, I'd very much prefer keeping the constructor of 
> > > DatePeriod and thus making it non-overloaded with this signature:
> > >
> > > public function __construct(DateTimeInterface $start, DateInterval 
> > > $interval, DateTimeInterface|int $end, int $options = 0) {}
> >
> > That still has an overloaded third argument — DateTimeInterface|int.
> >
> > Where you trying to suggest to change the current existing 
> > __construct() to:
> >
> > public function __construct(DateTimeInterface $start, DateInterval
> > $interval, DateTimeInterface $end, int $options = 0)
> >
> > and then add these two new factory methods?
> >
> > createFromRecurrences(DateTimeInterface $start, DateInterval $interval,
> > int $recurrences, int $options = 0)
> >
> > createFromISO8601String(string $specification, int $options = 0)
> >
> 
> I really meant DateTimeInterface|int, not an overloaded signature but a
> union type.

You may call it a union type, but that's still an overloaded signature :-)

> My concern is about providing the best path forward. Both deprecating 
> and providing the alternative in the same version creates a lot of 
> friction for end users.
>
> After a quick chat with Mate, I think we should do this union type *in 
> addition* to adding the new static constructors.
>
> Then, later on, if future us think it's worth it, we might want to 
> consider deprecating passing an integer.
>
> This would provide a path for BC/FC I would fully support.

In any case, I don't mind this — I'm actually going to suggest to change 
the constructor to:

public function __construct(DateTimeInterface $start, DateInterval $interval, 
DateTimeInterface|int $end, int $options = 0) {}

And then *only* add:

public static function createFromISO8601String(string $specification, int 
$options = 0): static {}

This solves the original problem of not being able to define the 
signatures in stubs, and also extracts the most problematic of methods 
into a factory method where it should always have belonged.

There would be no additional benefit in creating the other two factory 
methods.

cheers,
Derick

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

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

[Derick Rethans]

On Tue, 13 Jun 2023, Nicolas Grekas wrote:

> > I'm going to nitpick on the newly suggested names and argument order for
> > the
> > DatePeriod factory methods — althoughI do agree that they need to get
> > created:
> >
> > createFromInterval(DateTimeInterface $start, DateInterval $interval,
> > DateTimeInterface $end, int $options = 0)
> > → createWithRange(DateTimeInterface $begin, DateTimeInterface $end,
> > DateTimeInterface $int, int $options = 0)
> >
> > createFromRecurrences(DateTimeInterface $start, DateInterval $interval,
> > int $recurrences, int $options = 0)
> > → createWithRecurrences(DateInterval $begin, int $recurrences,
> > DateInterval $interval, int $options = 0)
> >
> > We also should fix the argument names. Either $start/$finish, or
> > $begin/$end. I
> > prefer the latter.
> >
> > createFromIso8601(string $specification, int $options = 0)
> > -> createFromISO8601String
> >
> > I am open to bike shedding about this :-)
> >
> 
> On my side, I'd very much prefer keeping the constructor of DatePeriod and
> thus making it non-overloaded with this signature:
> 
> public function __construct(DateTimeInterface $start, DateInterval
> $interval, DateTimeInterface|int $end, int $options = 0) {}

That still has an overloaded third argument — DateTimeInterface|int.

Where you trying to suggest to change the current existing __construct() 
to:

public function __construct(DateTimeInterface $start, DateInterval $interval, 
DateTimeInterface $end, int $options = 0)

and then add these two new factory methods?

createFromRecurrences(DateTimeInterface $start, DateInterval $interval, int 
$recurrences, int $options = 0)

createFromISO8601String(string $specification, int $options = 0)

That works for me.

cheers,
Derick

-- 
https://derickrethans.nl | https://xdebug.org | https://dram.io

Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support
Host of PHP Internals News: https://phpinternals.news

mastodon: @derickr@phpc.social @xdebug@phpc.social
twitter: @derickr and @xdebug

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

Re: [PHP-DEV] Deprecation of the formats DATE_ISO8601 and DATE_RFC7231

[Derick Rethans]

On Fri, 19 May 2023, Jorg Sowa wrote:

> I would like to propose the deprecation of the constants DATE_ISO8601,
> DateTimeInterface::ISO8601 and DateTimeInterface::RFC7231, DATE_RFC7231.

…

> In my opinion the question is not whether this constant should be
> deprecated, but when. I know that the problem was discussed in the past,
> but I hope enough time has passed already to touch this topic again
> although of the BC nature. [6] 
> [7]

In my opinion, deprecating this does not do anything besides annoying 
users.

> 
> Arguments for deprecating DATE_RFC7231:
> - error prone nature, the format never really supported timezone. I'm not
> sure how it appeared in the code, but tests clearly lack cases for this
> format. I'm not sure if it was missed on purpose, but with tests it would
> be obvious that the format shouldn't ever appear in the core. [8]
>  [9]
> 

This should instead be fixed of being deprecated. It is a recent 
addition after all.

cheers,
Derick

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