February 06, 2023
On Monday, 6 February 2023 at 16:57:13 UTC, H. S. Teoh wrote:
> On Mon, Feb 06, 2023 at 04:48:51PM +0000, Mathias LANG via Digitalmars-d wrote:
>> [...]
>
> OTOH there have been a good number of occasions in the past where changes in DMD/druntime had to be coordinated with Phobos. Even today, I'm almost certain that you can only use a specific version of Phobos with a specific version of DMD; it's likely to fail compilation or behave incorrectly otherwise.
>
>
> T

That's happened more times than I can count to me, so I'm surprised at the comment that we don't have that requirement for Phobos.
February 06, 2023

On Monday, 6 February 2023 at 17:09:36 UTC, user1234 wrote:

>

On Monday, 6 February 2023 at 10:22:32 UTC, Atila Neves wrote:

>

Now that dmd/druntime is in one repo, is there a good reason to not include Phobos?

This could lead to more breaking changes. Monorepo means that only BuildKite will be able to detect them, unless it is specified that it's not allowed to commit changes in phobos just because required by a change in dmd/druntime.

The need for this rule says it all.

I don't understand, could you please explain how there'd be more breaking changes?

February 06, 2023

On Monday, 6 February 2023 at 17:56:33 UTC, Atila Neves wrote:

>

On Monday, 6 February 2023 at 17:09:36 UTC, user1234 wrote:

>

On Monday, 6 February 2023 at 10:22:32 UTC, Atila Neves wrote:

>

Now that dmd/druntime is in one repo, is there a good reason to not include Phobos?

This could lead to more breaking changes. Monorepo means that only BuildKite will be able to detect them, unless it is specified that it's not allowed to commit changes in phobos just because required by a change in dmd/druntime.

The need for this rule says it all.

I don't understand, could you please explain how there'd be more breaking changes?

I'll try to reword a bit:

In case of an unexpected breaking change that would manifest itself only in the Phobos test suite and not in the BuildKite CI, and without "the rule", authors will be tempted to fix the problem in phobos in the same PR as the one initially only supposed to change DMD.

As special rule is required, then why put phobos in the main D repo ?
The fact that a special rule is required is a sign that a monorepo is a bad idea.

February 06, 2023
On 2/6/2023 8:48 AM, Mathias LANG wrote:
> On Monday, 6 February 2023 at 10:22:32 UTC, Atila Neves wrote:
>> Now that dmd/druntime is in one repo, is there a good reason to not include Phobos?
> 
> Because it will inevitably lead to circular dependencies, something Walter is already complaining about.

More specifically, I complained about the order in which things were built and tested.

There is a test suite designed to test the compiler. There are many hundreds of these tests. Each is standalone, only a few lines long. I.e. they are already reduced and isolated. (The source of most of these were bugs that were fixed.) When something in that test suite fails, one can usually go directly to the problem.

But what happens with the way the test suite is run is:

1. the compiler gets built

2. then the compiler is used to compile druntime. Boom, the compiler crashes. Now you've got hours of work to reduce the problem.

3. or the compiler is used to build checkwhitespace. Boom, the compiler crashes, or checkwhitespace crashes. Hours of work ahead.

4. or the compiler is used to bootstrap itself. Boom, it creates a compiler that crashes, or the created compiler compiles code badly. Hours of work ahead.

5. or the compiler is used to build build.d. build itself then crashes. Hours of work ahead.

6. or the compiler is used to build Phobos. It crashes building Phobos, or the Phobos unittests fail. Hours of work ahead.

--- OR ---

the freshly built compiler is used to run the compiler test suite. test1234.d fails. A few minutes of work identifying what went wrong, because you've only got 6 lines of code to look at rather than 100,000 lines.

2,3,4,5,6 have all routinely happened.

At least (mostly) the compiler test suite does not depend on a functioning Phobos. Myself (and others) have removed nearly all of those dependencies.

Another advantage of running the compiler test suite first is it is relatively small and runs fast. Hence, you get quick turnaround.

February 07, 2023
I am very much not a fan of horror movies. Let alone at 8am.

Let's not explore such horror topics such as mixing two sets of teams code bases which absolutely needs to be completely isolated from one another in such early hours.

But seriously, WHY ARE THERE COMPILER HOOKS IN PHOBOS (std.math)!

February 06, 2023
On Monday, 6 February 2023 at 19:13:35 UTC, Richard (Rikki) Andrew Cattermole wrote:
> I am very much not a fan of horror movies. Let alone at 8am.
>
> Let's not explore such horror topics such as mixing two sets of teams code bases which absolutely needs to be completely isolated from one another in such early hours.
>
> But seriously, WHY ARE THERE COMPILER HOOKS IN PHOBOS (std.math)!

I'd say that they should be moved in druntime.
February 06, 2023
On Monday, 6 February 2023 at 18:36:56 UTC, Walter Bright wrote:
> There is a test suite designed to test the compiler. There are many hundreds of these tests. Each is standalone, only a few lines long. I.e. they are already reduced and isolated. (The source of most of these were bugs that were fixed.) When something in that test suite fails, one can usually go directly to the problem.

I wish this were true, but actually there are a bunch of tests in the compiler's test suite that rely on Phobos. I know this because every now and then I will attempt to run the test suite without compiling Phobos first, and it will flood my terminal with error messages.

Perhaps some housekeeping is in order.
February 06, 2023
On Monday, 6 February 2023 at 19:13:35 UTC, Richard (Rikki) Andrew Cattermole wrote:
> I am very much not a fan of horror movies. Let alone at 8am.
>
> Let's not explore such horror topics such as mixing two sets of teams code bases which absolutely needs to be completely isolated from one another in such early hours.
>
> But seriously, WHY ARE THERE COMPILER HOOKS IN PHOBOS (std.math)!

Because somebody wanted a power operator.

Also, WIP: https://github.com/dlang/dmd/pull/14297
February 06, 2023
On 2/6/2023 11:36 AM, Paul Backus wrote:
> I wish this were true, but actually there are a bunch of tests in the compiler's test suite that rely on Phobos. I know this because every now and then I will attempt to run the test suite without compiling Phobos first, and it will flood my terminal with error messages.

I removed some. If there are any left, name and shame!


February 06, 2023
On 2/6/2023 11:38 AM, Iain Buclaw wrote:
> Because somebody wanted a power operator.

Maybe that should be revisited (i.e. use a function rather than an operator).