February 14, 2023
On 14/02/2023 3:21 PM, deadalnix wrote:
> On Tuesday, 14 February 2023 at 01:57:43 UTC, Richard (Rikki) Andrew Cattermole wrote:
>> Same goes for things like GC's, it is its own specialty. We should be moving things out of dmd's repository, not moving them in!
> 
> What practical problem would moving the GC out of the DMD repo solve?

Not just the GC, almost all of the druntime shouldn't be in there.

There are three things directly tied to the compiler that do need to be in there:

1. Attributes
2. Intrinsics (*sigh* atomics not picking that battle with dmd right now)
3. Hooks, must be templated (has its own benefits in simplifying the compiler quite significantly)

Everything else is library code like bindings which super doesn't need a compiler developer to look at them. And that is the point, its different groups that should be maintaining it, merging it will not encourage it, it will only mean people step on each others toes more.
February 14, 2023
On Tuesday, 14 February 2023 at 02:27:42 UTC, Richard (Rikki) Andrew Cattermole wrote:
> On 14/02/2023 3:21 PM, deadalnix wrote:
>> On Tuesday, 14 February 2023 at 01:57:43 UTC, Richard (Rikki) Andrew Cattermole wrote:
>>> Same goes for things like GC's, it is its own specialty. We should be moving things out of dmd's repository, not moving them in!
>> 
>> What practical problem would moving the GC out of the DMD repo solve?
>
> Not just the GC, almost all of the druntime shouldn't be in there.
>
> There are three things directly tied to the compiler that do need to be in there:
>
> 1. Attributes
> 2. Intrinsics (*sigh* atomics not picking that battle with dmd right now)
> 3. Hooks, must be templated (has its own benefits in simplifying the compiler quite significantly)
>
> Everything else is library code like bindings which super doesn't need a compiler developer to look at them. And that is the point, its different groups that should be maintaining it, merging it will not encourage it, it will only mean people step on each others toes more.

Ok, so I gather that no practical problem is being solved by said maneuver.
February 14, 2023
On Tuesday, 14 February 2023 at 02:27:42 UTC, Richard (Rikki) Andrew Cattermole wrote:
> On 14/02/2023 3:21 PM, deadalnix wrote:
>> On Tuesday, 14 February 2023 at 01:57:43 UTC, Richard (Rikki) Andrew Cattermole wrote:
>>> Same goes for things like GC's, it is its own specialty. We should be moving things out of dmd's repository, not moving them in!
>> 
>> What practical problem would moving the GC out of the DMD repo solve?
>
> Not just the GC, almost all of the druntime shouldn't be in there.
>
> There are three things directly tied to the compiler that do need to be in there:
>
> 1. Attributes
> 2. Intrinsics (*sigh* atomics not picking that battle with dmd right now)
> 3. Hooks, must be templated (has its own benefits in simplifying the compiler quite significantly)
>
> Everything else is library code like bindings which super doesn't need a compiler developer to look at them. And that is the point, its different groups that should be maintaining it, merging it will not encourage it, it will only mean people step on each others toes more.

In what way would they step on each others toes (more than they do separately)? A single repo solves a real problem, which is all the PITA caused when doing cross-cutting changes and an overly complex developer experience full of silly pitfalls and careful juggling (oh, right, I need to git pull on the other repo as well, maybe? Which dmd is this building with again? Oh damn I forgot to switch branches in 3 places at once). Putting aside status quo bias, any separation should also solve something comparable.
February 14, 2023

On Tuesday, 14 February 2023 at 06:55:50 UTC, John Colvin wrote:

>

In what way would they step on each others toes (more than they do separately)? A single repo solves a real problem, which is all the PITA caused when doing cross-cutting changes and an overly complex developer experience full of silly pitfalls and careful juggling (oh, right, I need to git pull on the other repo as well, maybe? Which dmd is this building with again? Oh damn I forgot to switch branches in 3 places at once). Putting aside status quo bias, any separation should also solve something comparable.

Agreed that the developer experience is currently sub-par.

The way I see the monorepo reasoning, it is attempting to solve systemic problems that surface when a few dimensions (at least projects & members, perhaps others) reach a very large scale. When you have more than 10k developers, employing someone to save them 10 minutes each per day is actually a 10x improvement.

What we will mostly loose by having a monorepo is a visible interface between core language and standard library. The interface will be less apparent, and easier to break. We have very concrete evidence that this is something that leads to problems (Tango/Phobos), and the separation exists today because of this.

In recent meetings, Walter complained that the DMD test suite depends on Phobos, and he's right. Fixing this problem would alleviate some of the issues you're describing it. LDC fixed that issue, and I think GDC did too, but DMD didn't yet.

February 14, 2023

On Tuesday, 14 February 2023 at 10:24:36 UTC, Mathias LANG wrote:

>

What we will mostly loose by having a monorepo is a visible interface between core language and standard library. The interface will be less apparent, and easier to break. We have very concrete evidence that this is something that leads to problems (Tango/Phobos), and the separation exists today because of this.

[1]

>

In recent meetings, Walter complained that the DMD test suite depends on Phobos, and he's right. Fixing this problem would alleviate some of the issues you're describing it. LDC fixed that issue, and I think GDC did too, but DMD didn't yet.

[2]

I would like to point our that [2] is concrete evidence that [1] clearly is not solved by the use of separate repos.

February 20, 2023

On Tuesday, 14 February 2023 at 12:46:33 UTC, deadalnix wrote:

>

On Tuesday, 14 February 2023 at 10:24:36 UTC, Mathias LANG wrote:

>

What we will mostly loose by having a monorepo is a visible interface between core language and standard library. The interface will be less apparent, and easier to break. We have very concrete evidence that this is something that leads to problems (Tango/Phobos), and the separation exists today because of this.

[1]

>

In recent meetings, Walter complained that the DMD test suite depends on Phobos, and he's right. Fixing this problem would alleviate some of the issues you're describing it. LDC fixed that issue, and I think GDC did too, but DMD didn't yet.

[2]

I would like to point our that [2] is concrete evidence that [1] clearly is not solved by the use of separate repos.

They are not in any way related. Having phobos in the same repo as dmd does not make [2] go away. The lament being made is that Phobos is being built before running the testsuite, not that Phobos is in a separate repo.

Regarding [1], I know the reference, however it's not clearly spelled out. D used to be maintained in one repository, it nearly killed the language. In the most pessimistic outlook, the split took the wind out of D's sails, and left the language permanently on the horizon. The end result of the fallout being druntime got removed from phobos, severing any ties between core and standard runtime libraries so that the likes of Tango or Ocean could co-exist with D compiler/core.

February 21, 2023

On Monday, 20 February 2023 at 23:58:44 UTC, Iain Buclaw wrote:

>

They are not in any way related. Having phobos in the same repo as dmd does not make [2] go away. The lament being made is that Phobos is being built before running the testsuite, not that Phobos is in a separate repo.

The claim never was that having phobos in the same repo makes the problem go away. In fact there is no such claim. However, it was claimed that using separate repos prevent this types of issues, which is a self detonating claim.

>

Regarding [1], I know the reference, however it's not clearly spelled out. D used to be maintained in one repository, it nearly killed the language. In the most pessimistic outlook, the split took the wind out of D's sails, and left the language permanently on the horizon. The end result of the fallout being druntime got removed from phobos, severing any ties between core and standard runtime libraries so that the likes of Tango or Ocean could co-exist with D compiler/core.

While I was already a D user back then, I wasn't involved in the way I am now, so I do not have this much background. However, it is relatively obvious that a language ending up with 2 standard library is the byproduct of some severe problem and I would be very surprised if the explaination was as simple as a repository organisation question. In fact, if I had to bet, I would bet against this hypothesis even without the full knwoledge of the background.

February 21, 2023

On Tuesday, 14 February 2023 at 10:24:36 UTC, Mathias LANG wrote:

>

What we will mostly loose by having a monorepo is a visible interface between core language and standard library. The interface will be less apparent, and easier to break.

Although the original question was about Phobos, the scope doesn't stop there. Don't forget there's also dlang/tools, dlang/installer, dlang/dlang.org, dlang/dub, and dlang/downloads.dlang.org. There would be absolutely zero point or gain in merging dlang/phobos into dlang/dmd unless everything else goes in too.

February 21, 2023

On Tuesday, 21 February 2023 at 00:18:51 UTC, Iain Buclaw wrote:

>

On Tuesday, 14 February 2023 at 10:24:36 UTC, Mathias LANG wrote:

>

What we will mostly loose by having a monorepo is a visible interface between core language and standard library. The interface will be less apparent, and easier to break.

Although the original question was about Phobos, the scope doesn't stop there. Don't forget there's also dlang/tools, dlang/installer, dlang/dlang.org, dlang/dub, and dlang/downloads.dlang.org. There would be absolutely zero point or gain in merging dlang/phobos into dlang/dmd unless everything else goes in too.

The spec probably could be in the with the implementation. They're modified in lockstep only with the barrier of an additional PR being required for the spec.

I also think it's hyperbolic to claim there is "zero" utility to it regardless of how you are calculating it.

1 2 3 4 5 6
Next ›   Last »