www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Please be more careful when changing the language behavior

reply Johan <j j.nl> writes:
Hi all,
   Please be more careful when changing the language behavior.

The change made by https://github.com/dlang/dmd/pull/9289 
silently breaks code in ways that can be very hard to detect. We 
were lucky to detect one case. There is no warning/deprecation 
whatsoever to warn me about any other potential breakages in a 
heavily templated 400kloc codebase with 212 instances of alias 
this.

The breakage introduced was very obvious, and warning about it is 
not difficult either. We need to raise the bar for accepting 
changes like this. The code on buildkite project tester is 
(fortunately) not the only D code in the world.

Again, please be more careful when changing language behavior.

Thanks,
   Johan
Jun 01
next sibling parent Stefan Koch <uplink.coder googlemail.com> writes:
On Monday, 1 June 2020 at 19:38:30 UTC, Johan wrote:
 Hi all,
   Please be more careful when changing the language behavior.

 The change made by https://github.com/dlang/dmd/pull/9289 
 silently breaks code in ways that can be very hard to detect. 
 We were lucky to detect one case. There is no 
 warning/deprecation whatsoever to warn me about any other 
 potential breakages in a heavily templated 400kloc codebase 
 with 212 instances of alias this.

 The breakage introduced was very obvious, and warning about it 
 is not difficult either. We need to raise the bar for accepting 
 changes like this. The code on buildkite project tester is 
 (fortunately) not the only D code in the world.

 Again, please be more careful when changing language behavior.

 Thanks,
   Johan
Wholeheartedly agree!
Jun 01
prev sibling next sibling parent Johan <j j.nl> writes:
On Monday, 1 June 2020 at 19:38:30 UTC, Johan wrote:
 Hi all,
   Please be more careful when changing the language behavior.

 The change made by https://github.com/dlang/dmd/pull/9289 
 silently breaks code in ways that can be very hard to detect.
An example in our standard lib: https://issues.dlang.org/show_bug.cgi?id=20892 -Johan
Jun 01
prev sibling next sibling parent Avrina <avrina12309412342 gmail.com> writes:
On Monday, 1 June 2020 at 19:38:30 UTC, Johan wrote:
 Hi all,
   Please be more careful when changing the language behavior.

 The change made by https://github.com/dlang/dmd/pull/9289 
 silently breaks code in ways that can be very hard to detect. 
 We were lucky to detect one case. There is no 
 warning/deprecation whatsoever to warn me about any other 
 potential breakages in a heavily templated 400kloc codebase 
 with 212 instances of alias this.

 The breakage introduced was very obvious, and warning about it 
 is not difficult either. We need to raise the bar for accepting 
 changes like this. The code on buildkite project tester is 
 (fortunately) not the only D code in the world.

 Again, please be more careful when changing language behavior.

 Thanks,
   Johan
It appears they tried to come to some sort of plan as to what should be done to notify the user. Not very inspiring that Walter was pinged and he didn't leave any feedback other than a ✔. I don't think a "simple" warning would have worked. That's a warning that would then have to be manually disabled all the time. It could have been put under the deprecation flag, but still then you'd be flooded with warnings that can't be "fixed" if someone treats deprecations as errors. This is where it would be nice to have a different versioning scheme than what we have now. You could put breaking changes like these where it's difficult to nicely notify the user. These change could have been deferred to a major version, where potentially breaking changes could be listed so that they can be checked. Then include a flag that does check if a code base uses that pattern anywhere so it can be fixed. A flag like that wouldn't work now as people expect their code to just work. There's only one version of D. They would most likely miss this breaking change, especially since it doesn't appear to have been added to any of the subsequent change logs. Which would help a user, if they did update up a few versions and don't have the time to read everything. There is a lot that could have been done better for sure.
Jun 01
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
All I can say is you're right, and we handled this badly.

alias this has a lot of problems, mainly because it tries to implement multiple 
inheritance without thinking it through. I've looked at fixing them, and 
essentially it is unfixable. We'll just have to live with the way it works, and 
shouldn't try to modify its behavior again.

Changes to the compiler rely very heavily on the test suite. If cases aren't in 
the test suite, we don't know when break things.
Jun 01
next sibling parent Mathias LANG <geod24 gmail.com> writes:
On Tuesday, 2 June 2020 at 05:32:08 UTC, Walter Bright wrote:
 All I can say is you're right, and we handled this badly.

 alias this has a lot of problems, mainly because it tries to 
 implement multiple inheritance without thinking it through. 
 I've looked at fixing them, and essentially it is unfixable. 
 We'll just have to live with the way it works, and shouldn't 
 try to modify its behavior again.

 Changes to the compiler rely very heavily on the test suite. If 
 cases aren't in the test suite, we don't know when break things.
In this case, the test case *was* in the test suite, or more precisely in druntime (https://github.com/dlang/druntime/pull/2476). So druntime was changed and is was merged without a user-visible message. That's why I've been advocating to make *any* change that change user code's behavior, even if it disallow something that shouldn't have been allowed in the first place, to be deprecation first. Because of D unparalleled compile-time introspection capabilities, there is not a single change you can make to the language or any library that *cannot* result in code breakage. For example, adding any public function to a library will break code relying on the symbol not existing (e.g. `!is(typeof(SomeSymbol))`). Now it doesn't mean we should stop adding new things or changing / fixing things, but it shouldn't be done without consideration for the potential breakage. One thing that should be at the very top of the list of "absolutely not going to happen" is silently changing which user code is executed without notification, and that's what happened here. Having worked at companies that use D, we *had* to have "sync points" where we updated the compiler. From what I saw, Weka is doing the exact same thing. This is because experience have proved countless times that upstream cannot be trusted not to break stuff. I'm glad to say that things have gotten drastically better over the year, and I think Buildkite was a major factor in this. Nevertheless, it's still at a point where an update is rarely a no-op.
Jun 01
prev sibling parent reply mw <mingwu gmail.com> writes:
On Tuesday, 2 June 2020 at 05:32:08 UTC, Walter Bright wrote:
 All I can say is you're right, and we handled this badly.

 alias this has a lot of problems, mainly because it tries to 
 implement multiple inheritance without thinking it through. 
 I've looked at fixing them, and essentially it is unfixable. 
 We'll just have to live with the way it works, and shouldn't 
 try to modify its behavior again.

 Changes to the compiler rely very heavily on the test suite. If 
 cases aren't in the test suite, we don't know when break things.
I've read industry users complaining about unstable compiler breaking their existing code base in the past forum threads. I think we need to take this seriously, otherwise D's community will shrink over time. For the two issues you mentioned: 1) If we do not want to separate two compiler versions (production 2.x vs development 3.x), then we better add some client code base to the current compiler test suite: E.g. https://code.dlang.org/ has total 1808 packages. Given some packages are no longer maintained, let's add the top 500 (or 1000) most recently updated packages to the compiler test suite: make sure at least these top 500 can be compiled (weak guarantee), and their `dub test` all pass (strong guarantee), before making new compiler releases. 2) for the multiple inheritance problem you try to solve, it actually is solvable: as far as I know, only Eiffel language solved the diamond inheritance problem gracefully, with keywords `rename`, `export`, `undefine`, `redefine` and `select`. Simply put: by default the Eiffel compiler will join the features and only keep one copy, but allow the user *explicitly* using these keywords to define the correct behavior that the user want. (I mailed you a copy of Eiffel language manual many years ago at pre-D1-age, esp. about multiple inheritance. Maybe you still remember? :-) Here are some online material on Eiffel's multiple inheritance solution: https://en.wikipedia.org/wiki/Multiple_inheritance """ In Eiffel, the ancestors' features are chosen explicitly with select and rename directives. This allows the features of the base class to be shared between its descendants or to give each of them a separate copy of the base class. Eiffel allows explicit joining or separation of features inherited from ancestor classes. Eiffel will automatically join features together, if they have the same name and implementation. The class writer has the option to rename the inherited features to separate them. Multiple inheritance is a frequent occurrence in Eiffel development; most of the effective classes in the widely used EiffelBase library of data structures and algorithms, for example, have two or more parents.[7] """ more detail here: https://www.eiffel.org/doc/eiffel/ET-_Inheritance
Jun 01
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/1/2020 11:17 PM, mw wrote:
 2) for the multiple inheritance problem you try to solve, it actually is 
 solvable: as far as I know, only Eiffel language solved the diamond
inheritance 
 problem gracefully, with keywords `rename`, `export`, `undefine`, `redefine`
and 
 `select`. Simply put: by default the Eiffel compiler will join the features
and 
 only keep one copy, but allow the user *explicitly* using these keywords to 
 define the correct behavior that the user want. (I mailed you a copy of Eiffel 
 language manual many years ago at pre-D1-age, esp. about multiple inheritance. 
 Maybe you still remember? :-)
I meant it is unsolvable without breaking everything. The trouble was, it was inserted without realizing it was multiple inheritance, meaning its behaviors are ad-hoc and don't make a whole lot of sense when examined carefully. I know I have that Eiffel manual around here somewhere :-) I also have Meyers' tome "Object Oriented Software Construction".
Jun 01
parent reply mw <mingwu gmail.com> writes:
On Tuesday, 2 June 2020 at 06:43:40 UTC, Walter Bright wrote:
 I meant it is unsolvable without breaking everything.

 The trouble was, it was inserted without realizing it was 
 multiple inheritance, meaning its behaviors are ad-hoc and 
 don't make a whole lot of sense when examined carefully.
Right, if it's done in pre-D1-age ...
 I know I have that Eiffel manual around here somewhere :-)

 I also have Meyers' tome "Object Oriented Software 
 Construction".
I'm so glad. If you seriously want to fix the multiple inheritance problem: freeze D2 prod, and make D3 dev, I also mean it seriously.
Jun 01
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/1/2020 11:53 PM, mw wrote:
 If you seriously want to fix the multiple inheritance problem: freeze D2 prod, 
 and make D3 dev, I also mean it seriously.
Yeah, well, even more breakage :-/
Jun 02
parent reply mw <mingwu gmail.com> writes:
On Wednesday, 3 June 2020 at 02:25:23 UTC, Walter Bright wrote:
 On 6/1/2020 11:53 PM, mw wrote:
 If you seriously want to fix the multiple inheritance problem: 
 freeze D2 prod, and make D3 dev, I also mean it seriously.
Yeah, well, even more breakage :-/
The difference is: for a new *major* version release, breakage are more acceptable and tolerable by the users. Python 3 doesn’t have backward compatibility with Python 2, and there’s even a tool called ‘2to3’ coming with Python 3 to help people migrate. It’s a hard decision, but in the long run, it helps Python to be a more consistent language. With minor version release, it’s difficult to get things fixed, both for you and for the language users. Just as both parties have expressed in this very thread. In my view, D2 has already been feature rich enough for people to do their work. What they want most is compiler stability, not any more new language features. By freezing D2, they will have a more stable platform to get their work done without worrying about breakage. And for you, it will buy you more time, e.g. a few years, to design carefully the next major features / fixes you want introduce in D3. Currently, https://dlang.org/changelog/release-schedule.html — New release are published every two months, on the first day of every uneven month. — Two weeks before a new release master is merged into stable and a first beta is released. I think this release schedule is too frequent for a mature v2 language, it’s not application software, but language compiler! No wonder kinke said:
 Master is waaay too unstable IMHO. I definitely wouldn't use it 
 for projects of mine, regardless how small.
I hope you can think about this D2 / D3 suggestion.
Jun 02
next sibling parent Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Wednesday, 3 June 2020 at 04:21:08 UTC, mw wrote:

 I think this release schedule is too frequent for a mature v2 
 language, it’s not application software, but language compiler!
+1
Jun 03
prev sibling next sibling parent reply Atwork <fwafwa fwfafa.com> writes:
On Wednesday, 3 June 2020 at 04:21:08 UTC, mw wrote:
 On Wednesday, 3 June 2020 at 02:25:23 UTC, Walter Bright wrote:
 On 6/1/2020 11:53 PM, mw wrote:
 If you seriously want to fix the multiple inheritance 
 problem: freeze D2 prod, and make D3 dev, I also mean it 
 seriously.
Yeah, well, even more breakage :-/
The difference is: for a new *major* version release, breakage are more acceptable and tolerable by the users. Python 3 doesn’t have backward compatibility with Python 2, and there’s even a tool called ‘2to3’ coming with Python 3 to help people migrate. It’s a hard decision, but in the long run, it helps Python to be a more consistent language. With minor version release, it’s difficult to get things fixed, both for you and for the language users. Just as both parties have expressed in this very thread. In my view, D2 has already been feature rich enough for people to do their work. What they want most is compiler stability, not any more new language features. By freezing D2, they will have a more stable platform to get their work done without worrying about breakage. And for you, it will buy you more time, e.g. a few years, to design carefully the next major features / fixes you want introduce in D3. Currently, https://dlang.org/changelog/release-schedule.html — New release are published every two months, on the first day of every uneven month. — Two weeks before a new release master is merged into stable and a first beta is released. I think this release schedule is too frequent for a mature v2 language, it’s not application software, but language compiler! No wonder kinke said:
 Master is waaay too unstable IMHO. I definitely wouldn't use 
 it for projects of mine, regardless how small.
I hope you can think about this D2 / D3 suggestion.
Completely agree with your statements. I am often about a year behind with compilers just so I can avoid being bit by breakage.
Jun 03
parent Walter Bright <newshound2 digitalmars.com> writes:
On 6/3/2020 12:52 AM, Atwork wrote:
 I am often about a year behind with compilers just so I can avoid being bit by 
 breakage.
And there's nothing wrong with operating that way. If it's working for you, by all means.
Jun 03
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/2/2020 9:21 PM, mw wrote:
 In my view, D2 has already been feature rich enough for people to do their
work. 
 What they want most is compiler stability, not any more new language features. 
 By freezing D2, they will have a more stable platform to get their work done 
 without worrying about breakage. And for you, it will buy you more time, e.g.
a 
 few years, to design carefully the next major features / fixes you want 
 introduce in D3.
We simply don't have the resources to support a fork of the language.
Jun 03
next sibling parent reply Panke <tobias pankrath.net> writes:
On Wednesday, 3 June 2020 at 07:56:54 UTC, Walter Bright wrote:
 On 6/2/2020 9:21 PM, mw wrote:
 In my view, D2 has already been feature rich enough for people 
 to do their work. What they want most is compiler stability, 
 not any more new language features. By freezing D2, they will 
 have a more stable platform to get their work done without 
 worrying about breakage. And for you, it will buy you more 
 time, e.g. a few years, to design carefully the next major 
 features / fixes you want introduce in D3.
We simply don't have the resources to support a fork of the language.
Would be a schema as described here [1] be possible? In a nutshell each breaking change is introduced with a switch named --incompatible_<name> that activates it. The default is to be turned off and this is quite similar to what we have with -preview=. After some time the default becomes on and you have to explicitly disable it, if you want to keep using your old code. The crucial difference to what we do is: Every breaking change is guaranteed to have an migration path that allows you to change your code in a way that it works with both --incompatible_<name>=on and --incompatible_<name>=off. So you do not have to update your complete codebase on every breaking change and the recommendation is to never use --incompatible in your production setup. [1] https://docs.bazel.build/versions/master/backward-compatibility.html
Jun 03
parent reply mw <mingwu gmail.com> writes:
On Wednesday, 3 June 2020 at 08:11:12 UTC, Panke wrote:
 Would be a schema as described here [1] be possible?

 In a nutshell each breaking change is introduced with a switch 
 named --incompatible_<name> that activates it. The default is 
 to be turned off and this is quite similar to what we have with 
 -preview=. After some time the default becomes on and you have 
 to explicitly disable it, if you want to keep using your old 
 code.

 The crucial difference to what we do is: Every breaking change 
 is guaranteed to have an migration path that allows you to 
 change your code in a way that it works with both 
 --incompatible_<name>=on and --incompatible_<name>=off. So you 
 do not have to update your complete codebase on every breaking 
 change and the recommendation is to never use --incompatible in 
 your production setup.


 [1] 
 https://docs.bazel.build/versions/master/backward-compatibility.html
Yes, I think that's another option we can consider. Let the user explicitly choose on the command-line, for each feature s/he want to use. And quite interesting, this method (way of thinking) is exactly the key idea how Eiffel solved the multiple inheritance difficulty, while other language didn't: i.e. deal with each feature individually (in Eiffel), instead of all-or-nothing approach (in other languages). (This is a bit off-topic on this thread, I will start a new thread about multiple inheritance in Eiffel).
Jun 03
parent Panke <tobias pankrath.net> writes:
On Thursday, 4 June 2020 at 06:47:16 UTC, mw wrote:
 Yes, I think that's another option we can consider.

 Let the user explicitly choose on the command-line, for each 
 feature s/he want to use.


 And quite interesting, this method (way of thinking) is exactly 
 the key idea how Eiffel solved the multiple inheritance 
 difficulty, while other language didn't: i.e. deal with each 
 feature individually (in Eiffel), instead of all-or-nothing 
 approach (in other languages).  (This is a bit off-topic on 
 this thread, I will start a new thread about multiple 
 inheritance in Eiffel).
I think the crucial thing is that you can put your code in a state where it works both with '--incompatible_<name>=off' and '--incompatible_<name>=on. Thus you can migrate one feature, one part of your code base at a time. So it's not a all-or-nothing approach as it is when migrating to the next mayor compiler version that may contain multiple breaking changes at once.
Jun 04
prev sibling next sibling parent reply aberba <karabutaworld gmail.com> writes:
On Wednesday, 3 June 2020 at 07:56:54 UTC, Walter Bright wrote:
 On 6/2/2020 9:21 PM, mw wrote:
 In my view, D2 has already been feature rich enough for people 
 to do their work. What they want most is compiler stability, 
 not any more new language features. By freezing D2, they will 
 have a more stable platform to get their work done without 
 worrying about breakage. And for you, it will buy you more 
 time, e.g. a few years, to design carefully the next major 
 features / fixes you want introduce in D3.
We simply don't have the resources to support a fork of the language.
I wish people who asks for D3 were more ready to do the work or finance it. We're barely figuring out issues with D2.
Jun 03
parent mw <mingwu gmail.com> writes:
On Wednesday, 3 June 2020 at 10:57:54 UTC, aberba wrote:
 On Wednesday, 3 June 2020 at 07:56:54 UTC, Walter Bright wrote:
 On 6/2/2020 9:21 PM, mw wrote:
 In my view, D2 has already been feature rich enough for 
 people to do their work. What they want most is compiler 
 stability, not any more new language features. By freezing 
 D2, they will have a more stable platform to get their work 
 done without worrying about breakage. And for you, it will 
 buy you more time, e.g. a few years, to design carefully the 
 next major features / fixes you want introduce in D3.
We simply don't have the resources to support a fork of the language.
I wish people who asks for D3 were more ready to do the work or finance it. We're barely figuring out issues with D2.
I just joined the dlang-community on github, thanks Seb for the invitation.
Jun 03
prev sibling parent mw <mingwu gmail.com> writes:
On Wednesday, 3 June 2020 at 07:56:54 UTC, Walter Bright wrote:
 On 6/2/2020 9:21 PM, mw wrote:
 In my view, D2 has already been feature rich enough for people 
 to do their work. What they want most is compiler stability, 
 not any more new language features. By freezing D2, they will 
 have a more stable platform to get their work done without 
 worrying about breakage. And for you, it will buy you more 
 time, e.g. a few years, to design carefully the next major 
 features / fixes you want introduce in D3.
We simply don't have the resources to support a fork of the language.
I won't call that a fork: I mean freeze D2 into maintenance mode: just bug fix, no new features. https://github.com/dlang/dmd shows: 198 contributors let them help you with the D2 maintenance, so you can concentrate on D3.
Jun 03
prev sibling next sibling parent reply Seb <seb wilzba.ch> writes:
On Tuesday, 2 June 2020 at 06:17:50 UTC, mw wrote:
 On Tuesday, 2 June 2020 at 05:32:08 UTC, Walter Bright wrote:
 All I can say is you're right, and we handled this badly.

 alias this has a lot of problems, mainly because it tries to 
 implement multiple inheritance without thinking it through. 
 I've looked at fixing them, and essentially it is unfixable. 
 We'll just have to live with the way it works, and shouldn't 
 try to modify its behavior again.

 Changes to the compiler rely very heavily on the test suite. 
 If cases aren't in the test suite, we don't know when break 
 things.
I've read industry users complaining about unstable compiler breaking their existing code base in the past forum threads. I think we need to take this seriously, otherwise D's community will shrink over time. For the two issues you mentioned: 1) If we do not want to separate two compiler versions (production 2.x vs development 3.x), then we better add some client code base to the current compiler test suite: E.g. https://code.dlang.org/ has total 1808 packages. Given some packages are no longer maintained, let's add the top 500 (or 1000) most recently updated packages to the compiler test suite: make sure at least these top 500 can be compiled (weak guarantee), and their `dub test` all pass (strong guarantee), before making new compiler releases.
We're already doing the strong guarantee (dub test) continuously ;-) Check the buildkite.com/dlang or a buildkite link on any of the main D repos. At the moment it's about 50 projects, but that's already a huge pain to maintain as some of these projects are hard to build, relied on network to test, had spurious failures due to randomness in the testsuite, rely on very specific OS features (or versions) and every now and then a new version is released which either introduces some of the above or just has an outright problem with the testsuite.
Jun 02
next sibling parent reply Jon Degenhardt <jond noreply.com> writes:
On Tuesday, 2 June 2020 at 08:22:03 UTC, Seb wrote:
 On Tuesday, 2 June 2020 at 06:17:50 UTC, mw wrote:
 E.g. https://code.dlang.org/ has total 1808 packages. Given 
 some packages are no longer maintained, let's add the top 500 
 (or 1000) most recently updated packages to the compiler test 
 suite: make sure at least these top 500 can be compiled (weak 
 guarantee), and their `dub test` all pass (strong guarantee), 
 before making new compiler releases.
We're already doing the strong guarantee (dub test) continuously ;-) Check the buildkite.com/dlang or a buildkite link on any of the main D repos. At the moment it's about 50 projects, but that's already a huge pain to maintain as some of these projects are hard to build, relied on network to test, had spurious failures due to randomness in the testsuite, rely on very specific OS features (or versions) and every now and then a new version is released which either introduces some of the above or just has an outright problem with the testsuite.
Package owners can help out by setting up weekly or nightly cron jobs that run the package test suite on different platform and compiler combinations, including nightly and beta builds. For some packages this can generate a broader set of tests than are run in the project tester.
Jun 02
parent reply Mathias LANG <geod24 gmail.com> writes:
On Tuesday, 2 June 2020 at 08:44:56 UTC, Jon Degenhardt wrote:
 On Tuesday, 2 June 2020 at 08:22:03 UTC, Seb wrote:
 On Tuesday, 2 June 2020 at 06:17:50 UTC, mw wrote:
 E.g. https://code.dlang.org/ has total 1808 packages. Given 
 some packages are no longer maintained, let's add the top 500 
 (or 1000) most recently updated packages to the compiler test 
 suite: make sure at least these top 500 can be compiled (weak 
 guarantee), and their `dub test` all pass (strong guarantee), 
 before making new compiler releases.
We're already doing the strong guarantee (dub test) continuously ;-) Check the buildkite.com/dlang or a buildkite link on any of the main D repos. At the moment it's about 50 projects, but that's already a huge pain to maintain as some of these projects are hard to build, relied on network to test, had spurious failures due to randomness in the testsuite, rely on very specific OS features (or versions) and every now and then a new version is released which either introduces some of the above or just has an outright problem with the testsuite.
Package owners can help out by setting up weekly or nightly cron jobs that run the package test suite on different platform and compiler combinations, including nightly and beta builds. For some packages this can generate a broader set of tests than are run in the project tester.
The main problem is replicating Travis' infrastructure. Anything that doesn't rely on the CI of the project is bound to get outdated. And for the moment we rely on the parsing the testsuite from the `.travis.yml`. But the runners have their own environment (provisioned) and there's no way for a project to install its dependencies / specific tools (e.g. the lack of meson have led to countless issues). You also have to pin package versions to a single one. Personally I'd like to have support for Github CI and explore having the test-suite run cross-platform when possible (for the moment we only test Linux).
Jun 02
parent reply kinke <kinke gmx.net> writes:
On Tuesday, 2 June 2020 at 09:56:41 UTC, Mathias LANG wrote:
 On Tuesday, 2 June 2020 at 08:44:56 UTC, Jon Degenhardt wrote:
 Package owners can help out by setting up weekly or nightly 
 cron jobs that run the package test suite on different 
 platform and compiler combinations, including nightly and beta 
 builds. For some packages this can generate a broader set of 
 tests than are run in the project tester.
The main problem is replicating Travis' infrastructure. Anything that doesn't rely on the CI of the project is bound to get outdated. And for the moment we rely on the parsing the testsuite from the `.travis.yml`. But the runners have their own environment (provisioned) and there's no way for a project to install its dependencies / specific tools (e.g. the lack of meson have led to countless issues). You also have to pin package versions to a single one.
BuildKite certainly improved the overall situation, but it's obviously not scalable and can already be a problem if compiler changes require a new version of one of the tested projects. E.g., I've been waiting for months for a new Ocean release to be finally published with a tiny adaptation, and now that Sociomantic isn't anymore, I'm not sure I'll see that release happen this year at all. Anyway, projects contributing themselves to regression testing via regularly triggered builds using the latest beta would be very much appreciated. But that doesn't work for DMD, where the final release usually happens 1-2 weeks after the 1st beta - that won't be enough for people to adapt their projects to language/library changes and investigate any apparent regressions.
Jun 02
parent reply Mathias LANG <geod24 gmail.com> writes:
On Tuesday, 2 June 2020 at 13:40:08 UTC, kinke wrote:
 Anyway, projects contributing themselves to regression testing 
 via regularly triggered builds using the latest beta would be 
 very much appreciated. But that doesn't work for DMD, where the 
 final release usually happens 1-2 weeks after the 1st beta - 
 that won't be enough for people to adapt their projects to 
 language/library changes and investigate any apparent 
 regressions.
Instead of betas, which I think are more useful for manual testing before a release, I'd recommend to set up a dimension / a cron with nightly builds. Github CI and the install script support them (hence so does travis-ci), by using `dmd-master` / `ldc-master` and `ldc-latest-ci` / `dmd-nightly`, respectively.
Jun 02
parent reply kinke <kinke gmx.net> writes:
On Tuesday, 2 June 2020 at 14:13:20 UTC, Mathias LANG wrote:
 Instead of betas, which I think are more useful for manual 
 testing before a release, I'd recommend to set up a dimension / 
 a cron with nightly builds.
 Github CI and the install script support them (hence so does 
 travis-ci), by using `dmd-master` / `ldc-master` and 
 `ldc-latest-ci` / `dmd-nightly`, respectively.
Master is waaay too unstable IMHO. I definitely wouldn't use it for projects of mine, regardless how small.
Jun 02
next sibling parent Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
On Tuesday, 2 June 2020 at 14:50:41 UTC, kinke wrote:
 On Tuesday, 2 June 2020 at 14:13:20 UTC, Mathias LANG wrote:
 Instead of betas, which I think are more useful for manual 
 testing before a release, I'd recommend to set up a dimension 
 / a cron with nightly builds.
 Github CI and the install script support them (hence so does 
 travis-ci), by using `dmd-master` / `ldc-master` and 
 `ldc-latest-ci` / `dmd-nightly`, respectively.
Master is waaay too unstable IMHO. I definitely wouldn't use it for projects of mine, regardless how small.
If the project is already on BuildKite then nightly is actually a pretty solid option, since upstream developers are forced to either not break BuildKite projects, or adapt them, before introducing a breaking change (which can even be a just a new warning). Even for a few of the projects that I maintain that are not on BuildKite I have used nightly builds without much issues. I think it mainly depends on how much one is willing to be on the bleeding edge. Of course, projects of the scale of Weka, are a different matter all together.
Jun 02
prev sibling parent Mathias LANG <geod24 gmail.com> writes:
On Tuesday, 2 June 2020 at 14:50:41 UTC, kinke wrote:
 On Tuesday, 2 June 2020 at 14:13:20 UTC, Mathias LANG wrote:
 Instead of betas, which I think are more useful for manual 
 testing before a release, I'd recommend to set up a dimension 
 / a cron with nightly builds.
 Github CI and the install script support them (hence so does 
 travis-ci), by using `dmd-master` / `ldc-master` and 
 `ldc-latest-ci` / `dmd-nightly`, respectively.
Master is waaay too unstable IMHO. I definitely wouldn't use it for projects of mine, regardless how small.
Any decent CI has the ability to mark some failures as non-fatal. So if master is unstable, well, it won't affect your project, but if you want to report it you can. Also my mileage vary quite a bit. We've had LDC master enabled (and not allowing failure) for months now and everything's fine. Before we dropped DMD support, we also had DMD master, which sometimes had minor issues, but never was a huge burden to maintain either, since failures would be ignored.
Jun 02
prev sibling parent Stefan Koch <uplink.coder googlemail.com> writes:
On Tuesday, 2 June 2020 at 08:22:03 UTC, Seb wrote:
 On Tuesday, 2 June 2020 at 06:17:50 UTC, mw wrote:
 [...]
We're already doing the strong guarantee (dub test) continuously ;-) Check the buildkite.com/dlang or a buildkite link on any of the main D repos. At the moment it's about 50 projects, but that's already a huge pain to maintain as some of these projects are hard to build, relied on network to test, had spurious failures due to randomness in the testsuite, rely on very specific OS features (or versions) and every now and then a new version is released which either introduces some of the above or just has an outright problem with the testsuite.
The problem with this is that. People submit fix-up pr's for the projects that fail with their change.
Jun 04
prev sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Tuesday, 2 June 2020 at 06:17:50 UTC, mw wrote:
 [snip]
Thanks for that some interesting materials there about Eiffel. As it says on the wikipedia page, the select & rename together drives their solution. Combining select and rename in one class is like an alias in D. However, D does not have the ability to prevent calling a member function of an inherited class. Using opDispatch doesn't work because it comes after calling member functions. I think the most D-like way to incorporate this behavior is to allow disable in a derived class for a base member function. Right now (see code below), you get a message about a depreciation (I think this one [1]) and not being able to disable an overridden (you have to throw in an override) base class member function. Probably would require a DIP, there is likely code out there that depends on always being able to call the base class member functions. Ideally, it would also handle base members, but this would likely require an even bigger change. [1] https://dlang.org/deprecate.html#Overriding%20without%20override import std.stdio: writeln; class A { int x; void foo(int x){ writeln("A"); } } class B : A { alias val = A.foo; // disable this.x; disable override void foo(int){} } void main() { A a = new A; B b = new B; b.val(1); }
Jun 03
parent mw <mingwu gmail.com> writes:
On Wednesday, 3 June 2020 at 19:40:10 UTC, jmh530 wrote:
 On Tuesday, 2 June 2020 at 06:17:50 UTC, mw wrote:
 [snip]
Thanks for that some interesting materials there about Eiffel. As it says on the wikipedia page, the select & rename together drives their solution. Combining select and rename in one class is like an alias in D. However, D does not have the ability to prevent calling a member function of an inherited class. Using opDispatch doesn't work because it comes after calling member functions. I think the most D-like way to incorporate this behavior is to allow disable in a derived class for a base member function. Right now (see code below), you get a message about a depreciation (I think this one [1]) and not being able to disable an overridden (you have to throw in an override) base class member function. Probably would require a DIP, there is likely code out there that depends on always being able to call the base class member functions. Ideally, it would also handle base members, but this would likely require an even bigger change. [1] https://dlang.org/deprecate.html#Overriding%20without%20override import std.stdio: writeln; class A { int x; void foo(int x){ writeln("A"); } } class B : A { alias val = A.foo; // disable this.x; disable override void foo(int){} } void main() { A a = new A; B b = new B; b.val(1); }
This is a bit off-topic in this thread, I started a new one: https://forum.dlang.org/thread/obqthozmxwzhvrafothw forum.dlang.org will discuss the topic there.
Jun 04
prev sibling next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 01.06.20 21:38, Johan wrote:
 Hi all,
    Please be more careful when changing the language behavior.
 
 The change made by https://github.com/dlang/dmd/pull/9289 silently 
 breaks code in ways that can be very hard to detect. We were lucky to 
 detect one case. There is no warning/deprecation whatsoever to warn me 
 about any other potential breakages in a heavily templated 400kloc 
 codebase with 212 instances of alias this.
 
 The breakage introduced was very obvious, and warning about it is not 
 difficult either. We need to raise the bar for accepting changes like 
 this. The code on buildkite project tester is (fortunately) not the only 
 D code in the world.
 
 Again, please be more careful when changing language behavior.
 
 Thanks,
    Johan
 
Another example: https://github.com/dlang/dmd/commit/0f2889c3aa9fba5534e754dade0cae574b636d55#r36465193
Jun 02
prev sibling parent basile b <b2.temp gmx.com> writes:
On Monday, 1 June 2020 at 19:38:30 UTC, Johan wrote:
 Hi all,
   Please be more careful when changing the language behavior.

 The change made by https://github.com/dlang/dmd/pull/9289 
 silently breaks code in ways that can be very hard to detect. 
 We were lucky to detect one case. There is no 
 warning/deprecation whatsoever to warn me about any other 
 potential breakages in a heavily templated 400kloc codebase 
 with 212 instances of alias this.

 The breakage introduced was very obvious, and warning about it 
 is not difficult either. We need to raise the bar for accepting 
 changes like this. The code on buildkite project tester is 
 (fortunately) not the only D code in the world.

 Again, please be more careful when changing language behavior.

 Thanks,
   Johan
is it that impossible to have a guy that works on regression ?
Jun 02