Monorepo? (page 3)

February 06, 2023

Re: Monorepo?

Posted by Steven Schveighoffer
in reply to Walter Bright

Permalink

Steven Schveighoffer

Posted in reply to Walter Bright

Permalink

On 2/6/23 1:36 PM, Walter Bright wrote:

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:

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

This is probably unavoidable. druntime and the compiler are tightly coupled.

Potentially, you could run some tests before this? Off the top of my head, you could run fail-compilation tests before a valid druntime is available?

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

We should build checkwhitespace with the bootstrap compiler, not with the built compiler. You can rebuild checkwhitespace at the end as a further test. In any case, changing the compiler shouldn't break this part of the step.

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.

This should be done after the test suite, right?

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

Same here.

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

Yeah, we need to make sure phobos isn't needed to run the full test suite. possibly we could delay phobos-dependent tests until after the standalone tests finish.

Sometimes compiler bugs are only tickled with insanely convoluted conditions, which might include specific parts of phobos. Reducing them is ideal, but that takes hours too.

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.

All agreed. We should have a standing rule that any tests that are run based on code external to dmd/druntime need to happen after all the dmd/druntime tests are done. And tools should be built with a known good compiler. The "checkwhitespace" problem seems an incredibly foolish requirement to shove in front of making sure you have a sane compiler.

-Steve

On 07/02/2023 9:05 AM, Walter Bright wrote: > 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). Nah, its just the implementation is in the wrong place and its implementation needs revisiting. https://issues.dlang.org/show_bug.cgi?id=23538

On Tue, Feb 07, 2023 at 09:34:08AM +1300, Richard (Rikki) Andrew Cattermole via Digitalmars-d wrote: > On 07/02/2023 9:05 AM, Walter Bright wrote: > > 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). > > Nah, its just the implementation is in the wrong place and its implementation needs revisiting. > > https://issues.dlang.org/show_bug.cgi?id=23538 Since ^^ is a built-in operator in the language, the implementation (and its dependencies) really should be in druntime. Any dependent functions like exp() that's currently in std.math should be moved to druntime, and std.math should just alias the current symbol to the druntime implementation. T -- The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- Anonymous

On Monday, 6 February 2023 at 22:58:02 UTC, deadalnix wrote:

On Monday, 6 February 2023 at 15:04:24 UTC, Iain Buclaw wrote:

On Monday, 6 February 2023 at 14:28:45 UTC, max haughton wrote:

Things choosing and thus eventually disagreeing on which Phobos version they want to use is potentially not so great.

Phobos being pre-compiled with an unknown set of flags, and that mismatching every other project reliant on Phobos is not great either.

This is generally not a problem with C++, why should we expect this to be one for D?

Every kind of code generation flag can and will affect the signature of a function, whether a template gets codegen.

If we introduced flags that bifurcate the language, then it seems to me that these flags should be removed.

Goodbye -release, goodbye -dip1000, goodbye -checkaction=, goodbye -preview=, goodbye -debug=, goodbye -unittest, goodbye -version=, goodbye -allinst...

On Monday, 6 February 2023 at 23:42:01 UTC, Iain Buclaw wrote: > Goodbye -release, goodbye -dip1000, goodbye -checkaction=, goodbye -preview=, goodbye -debug=, goodbye -unittest, goodbye -version=, goodbye -allinst... i have a potential solution http://dpldocs.info/this-week-in-d/Blog.Posted_2022_11_14.html#redesign-for-template-emission-woes

Forums