On 11/11/16 8:30 AM, Dicebot wrote:
> On Friday, 11 November 2016 at 13:21:40 UTC, Nick Sabalausky wrote:
>> Run the new dmd. If it fails, either fix your code or go temporarily
>> go back to the old dmd until you can fix your code.
>
> D will never be considered production ready as pong as this attiude
> remaind. Your described scenario in practice works like this:
>
> - You decide to delay fix until you have time to investigate
> - Half of users of your library you (or your colleagues) complain that
> they can't upgrade their projects because you areso slow
> - You desperately find time to do required fix which proves bavkwards
> incompatible
> - Now the other half of your users (colleagues) complain that your rush
> to upgrade forces them to switch to immature compiler
>

If you remove cycles in your code, it will not flag cycles in the old compiler ;)

> ... or one can spend one extra hour to implement deprecation path and
> the issue disappears completely.

There is a misunderstanding that the new cycle detection is an "upgrade" of some kind. It's a bug fix.

There is a path to use new DMD with your buggy code, just use --DRT-oncycle=ignore. It's just not the default.

-Steve

On 11/11/2016 03:46 PM, Steven Schveighoffer wrote:
>> ... or one can spend one extra hour to implement deprecation path and the issue disappears completely.
> 
> There is a misunderstanding that the new cycle detection is an "upgrade" of some kind. It's a bug fix.

There is no difference between a bug fix and "upgrade" in context of deprecation path expectations. It affects robustness of package ecosystem in the same way.

> There is a path to use new DMD with your buggy code, just use --DRT-oncycle=ignore. It's just not the default.

Well, this is the reason why I haven't filed it as a regression. It is bad, but being able to ignore detection if rt flag makes it tolerable.

I am still going to look into keeping both algorithms for this release but don't view it as blocking regression.

On 11.11.2016 14:42, Steven Schveighoffer wrote:
> On 11/11/16 8:21 AM, Nick Sabalausky wrote:
>> On 11/11/2016 04:54 AM, Kagamin wrote:
>>> On Thursday, 10 November 2016 at 13:58:56 UTC, Steven Schveighoffer
>>> wrote:
>>>> Only possibility is just to ignore ALL cycles, and print them if any
>>>> are detected.
>>>
>>> Run the new detector and if it fails, run the old one, if it succeeds,
>>> print a message.
>>
>> Or:
>>
>> Run the new dmd. If it fails, either fix your code or go temporarily go
>> back to the old dmd until you can fix your code.
>>
>
> The option to ignore the cycles is there, added to allow for people to
> use the new DMD even if cycles exist. However, it is a runtime switch,
> which means you have to run it that way.
>
> -Steve
>

You can also embed the option into the executable. See the bottom of https://dlang.org/spec/garbage.html#gc_config.

Is there another place where --DRT-options are listed?

On 11/11/16 9:06 AM, Rainer Schuetze wrote:
>
>
> On 11.11.2016 14:42, Steven Schveighoffer wrote:

>> The option to ignore the cycles is there, added to allow for people to
>> use the new DMD even if cycles exist. However, it is a runtime switch,
>> which means you have to run it that way.
>>
>
> You can also embed the option into the executable. See the bottom of
> https://dlang.org/spec/garbage.html#gc_config.

I didn't know that! Very nice, and a good mechanism to help those with deprecation issues -- if you put the oncycle=print in that list of options, then the new code will still run when a cycle is present, and old runtime will simply ignore that. No need to add the option when running.

> Is there another place where --DRT-options are listed?

I don't think so. Probably a good idea to list somewhere. As there is no central processing of options (they are parsed, but not handled until requested), it's less obvious where all the usages are. I only found the GC options and maybe one other.

-Steve

On 11/11/16 9:02 AM, Dicebot wrote:
> On 11/11/2016 03:46 PM, Steven Schveighoffer wrote:
>>> ... or one can spend one extra hour to implement deprecation path and
>>> the issue disappears completely.
>>
>> There is a misunderstanding that the new cycle detection is an "upgrade"
>> of some kind. It's a bug fix.
>
> There is no difference between a bug fix and "upgrade" in context of
> deprecation path expectations. It affects robustness of package
> ecosystem in the same way.

There is a subtle difference -- you weren't exactly "depending" on the buggy behavior, you didn't actually notice that the bug was there. In fact, you were depending on the cycle detection to find the cycles for you, and it was failing.

It would be like finding a flaw in the AA hashing behavior that allowed 2 identical keys to get stored. Fix that bug, and it necessarily changes behavior, it may even break some code. Should we go through deprecation cycle for that?

> I am still going to look into keeping both algorithms for this release
> but don't view it as blocking regression.

It's not going to be easy. The code had to be completely rewritten, since the flaw in the original code was a design problem. You will likely have to run both algorithms separately, and only fail if both do.

You can probably use the same cycle printing code, as I separated that out (and now use a shortest-path algorithm to minimize the cycle size).

-Steve

On 11/11/2016 08:30 AM, Dicebot wrote:
> On Friday, 11 November 2016 at 13:21:40 UTC, Nick Sabalausky wrote:
>> Run the new dmd. If it fails, either fix your code or go temporarily
>> go back to the old dmd until you can fix your code.
>
> D will never be considered production ready as pong as this attiude
> remaind. Your described scenario in practice works like this:
>
> - You decide to delay fix until you have time to investigate

I've gone through a lot of compiler upgrades on a lot of D projects, and in my experience, this "investigate and fix for the new dmd" has always been trivial (aside from one instance where Phobos's standard function deprecation policy wasn't followed).

Some things should certainly have a smooth transition path (like above, when replacing a Phobos function with a different one), but really, not everything needs to be.

> - Half of users of your library you (or your colleagues) complain that
> they can't upgrade their projects because you areso slow
> - You desperately find time to do required fix which proves bavkwards
> incompatible

AFAICT, That's not the case with this particular cycle detection matter.

On Friday, 11 November 2016 at 19:36:59 UTC, Nick Sabalausky wrote:
>
> I've gone through a lot of compiler upgrades on a lot of D projects, and in my experience, this "investigate and fix for the new dmd" has always been trivial (aside from one instance where Phobos's standard function deprecation policy wasn't followed).
>
> Some things should certainly have a smooth transition path (like above, when replacing a Phobos function with a different one), but really, not everything needs to be.
>

They've talked about an auto-checker for dub packages. I suspect that will go a long way to reducing regressions.

On 11/11/16 3:02 PM, jmh530 wrote:
> On Friday, 11 November 2016 at 19:36:59 UTC, Nick Sabalausky wrote:
>>
>> I've gone through a lot of compiler upgrades on a lot of D projects,
>> and in my experience, this "investigate and fix for the new dmd" has
>> always been trivial (aside from one instance where Phobos's standard
>> function deprecation policy wasn't followed).
>>
>> Some things should certainly have a smooth transition path (like
>> above, when replacing a Phobos function with a different one), but
>> really, not everything needs to be.
>>
>
> They've talked about an auto-checker for dub packages. I suspect that
> will go a long way to reducing regressions.

Actually, in this case, we knew this was going to break builds, and also in this case, the fix for user code is not trivial. Breaking a cycle involves breaking a module into multiple pieces, or putting the initialization code elsewhere.

Unfortunately, there's not much ways to do this fix in a graceful manner. This is a tougher one to swallow, and I don't think it's a normal case. The DRT options were added to ease transition.

-Steve

On Friday, November 11, 2016 14:36:59 Nick Sabalausky via Digitalmars-d- announce wrote:
> On 11/11/2016 08:30 AM, Dicebot wrote:
> > On Friday, 11 November 2016 at 13:21:40 UTC, Nick Sabalausky wrote:
> >> Run the new dmd. If it fails, either fix your code or go temporarily go back to the old dmd until you can fix your code.
> >
> > D will never be considered production ready as pong as this attiude remaind. Your described scenario in practice works like this:
> >
> > - You decide to delay fix until you have time to investigate
>
> I've gone through a lot of compiler upgrades on a lot of D projects, and in my experience, this "investigate and fix for the new dmd" has always been trivial (aside from one instance where Phobos's standard function deprecation policy wasn't followed).
>
> Some things should certainly have a smooth transition path (like above, when replacing a Phobos function with a different one), but really, not everything needs to be.

In general, I agree, but it can cause problems when something works with the last release and not the master branch (you can't always avoid that, but it's far better to if you can), and even when just considering releases, having stuff work with one release and not the next can cause serious problems when you're providing a library for someone else or dealing with multiple programs where you can't just upgrade everything at once. Dicebot talked about problems along those lines at Sociomantic in his talk at dconf 2015:

http://dconf.org/2015/talks/strasuns.html

It's a sucky scenario to be in, but you don't always have a choice - especially in a corporate environment.

Another fun problem is when you try and support multiple versions of
dmd/druntime/phobos with the same project (like vibe.d does). Hard breakage
can make that difficult (though not impossible).

I don't think that it's always possible or reasonable to provide some kind of deprecation path or to smoothly transitition from one behavior to another (particularly when dealing with certain types of bugs), but if we don't at least try and mitigate those types of problems, we're going to have problems with folks who do not have the luxury of being able to simply update their code base for the new release, even if the changes themselves are trivial.

- Jonathan M Davis

On Monday, 31 October 2016 at 01:27:08 UTC, Martin Nowak wrote:
> Glad to announce D 2.072.0.
>
> http://dlang.org/download.html
>
> This is the release ships with the latest version of dub (v1.1.0), comes
> with lots of phobos additions and native TLS on OSX.
> See the changelog for more details.
>
> http://dlang.org/changelog/2.072.0.html
>
> -Martin

Sorry another regression:

https://issues.dlang.org/show_bug.cgi?id=16682

I don't know if it's a real regression, maybe the PR that breaks dfmt is legit but at least
- you (you == dlang team as an entity) could start a deprecation period.
- the community could detect that before.