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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020