As commented yesterday on one of the PRs, I strongly agree with the
cleanups. Our code has implicit dependencies and if you reorder the
includes in the same file, you can break builds. That shouldn't ever
happen.
I also agree that dtrace breaking is a failure of CI and testing, not
necessarily the
On 2023/01/16 17:44, Tim Düsterhus wrote:
> Sorry for the duplicate mail, but it just came to my mind checking the CI
> build logs from before and after the revert:
I wish that were true numbers, but they're not - that's just (extreme)
noise. Later CI builds are back to shorter build times. I g
Hi
On 1/16/23 17:36, Tim Düsterhus wrote:
From my experience contributing to another C project (HAProxy),
cleaning up the the includes can have a measurable impact on build
times. See this commit for example:
Sorry for the duplicate mail, but it just came to my mind checking the
CI build lo
On 2023/01/16 17:25, Kamil Tekiela wrote:
> Have you done any benchmarking in terms of build time? Is there any
> tangible difference or is it only theoretical?
I did, but in this early stage, there is no measurable speedup yet,
because there are still too many "fat" headers left that need to be
Hi
On 1/16/23 17:25, Kamil Tekiela wrote:
Have you done any benchmarking in terms of build time? Is there any
tangible difference or is it only theoretical?
From my experience contributing to another C project (HAProxy),
cleaning up the the includes can have a measurable impact on build
tim
Have you done any benchmarking in terms of build time? Is there any
tangible difference or is it only theoretical?
On 2023/01/16 17:14, Chase Peeler wrote:
> will that have any impact on the final product such as reduced binary sizes
> or better performance?
No, this kind of code cleanup must not affect the resulting binary at
all, therefore no change to runtime behavior/performance.
Though the build will be
On Mon, Jan 16, 2023 at 7:54 AM Max Kellermann wrote:
> On 2023/01/16 13:38, Kamil Tekiela wrote:
> > Did you create an RFC already? Or is this RFC-like discussion?
>
> No. I followed https://wiki.php.net/rfc/howto and this is step 1.
> Creating the actual RFC is step 3.
>
> (I'm new to PHP and
On 16.01.2023 at 16:01, G. P. B. wrote:
> I would like to start the discussion about the "Add file_descriptor()
> function" RFC:
> https://wiki.php.net/rfc/file-descriptor-function
>
> This RFC proposes the addition of the file_descriptor() function to
> retrieve the underlying file descriptor of
Am 16.01.2023 um 14:39 schrieb G. P. B. :
> On Sun, 15 Jan 2023 at 20:58, Christian Schneider
> wrote:
> Some comments:
> - I am not convinced that we should introduce a third way of providing
> parameters to setcookie(). I don't think this function is used often enough
> in common code to add
> Am 16.01.2023 um 16:01 schrieb G. P. B. :
>
> Hello internals,
>
> I would like to start the discussion about the "Add file_descriptor()
> function" RFC:
> https://wiki.php.net/rfc/file-descriptor-function
>
> This RFC proposes the addition of the file_descriptor() function to
> retrieve the
Hello internals,
I would like to start the discussion about the "Add file_descriptor()
function" RFC:
https://wiki.php.net/rfc/file-descriptor-function
This RFC proposes the addition of the file_descriptor() function to
retrieve the underlying file descriptor of stream if it exists. This is
usefu
On Sun, 15 Jan 2023 at 16:40, Nicolas Grekas
wrote:
> Hi George,
>
> There's quite some activity on the HTTP cookies side.
> I read about SameParty and Partitioned attributes recently, see:
> - https://developer.chrome.com/docs/privacy-sandbox/chips/
> - https://github.com/cfredric/sameparty
>
>
On 2023/01/16 13:38, Kamil Tekiela wrote:
> Did you create an RFC already? Or is this RFC-like discussion?
No. I followed https://wiki.php.net/rfc/howto and this is step 1.
Creating the actual RFC is step 3.
(I'm new to PHP and this process - so far, I've only contributed PHP
code through GitHu
On Mon, 16 Jan 2023 at 12:03, Max Kellermann wrote:
> Hi,
>
> in the past weeks, I submitted four PRs for cleaning up the #includes
> in the PHP code base:
>
> https://github.com/php/php-src/pull/10216
> https://github.com/php/php-src/pull/10220
> https://github.com/php/php-src/pull/10279
> h
Hi Max,
Thanks for describing the situation.
We do not often vote on implementation changes that don't affect PHP
language itself.
At first, I even considered these changes as "I don't care".
However, they are turned up into huge patches that make troubles for PHP
maintenance.
As we didn't come t
Hi,
Did you create an RFC already? Or is this RFC-like discussion?
In either case, if you are asking community to come to a decision, we need
to see some background. Why do you want to change this? What's the benefit?
What's the impact on other maintainers, especially extension maintainers?
Do you
Hi,
in the past weeks, I submitted four PRs for cleaning up the #includes
in the PHP code base:
https://github.com/php/php-src/pull/10216
https://github.com/php/php-src/pull/10220
https://github.com/php/php-src/pull/10279
https://github.com/php/php-src/pull/10300
I saw that the existing #inc
18 matches
Mail list logo
