Re: Release D 2.072.0
On 11/11/2016 09:36 PM, Nick Sabalausky 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). Speaking of Sociomantic experience, practice has shown that any breaking change that requires 5 min fix for any given project can easily take from weeks to months (!) before all maintained interdependent projects are updated. With deprecations it is not a problem at all because everyone moves on using own schedule caring only about hard time limit. With _any_ sort of immediate breakage it is pain because now upgrade both becomes urgent and needs to be explicitly synced between all developers. It is simply another side of "nine women can't make a baby in one month" thing. Best way to scale large teams is to split them so that amount of people involved in any specific process is minimal, otherwise even trivialities escalate exponentially under weight of communications. And with software development "large" starts pretty small. > 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. Yes, but this is mentality I am talking about. In vast majority of cases providing smooth deprecation path is trivial - replacing `error` call with `deprecation` call in DMD patch, marking symbol as deprecated before removing in Phobos. In some of PRs I have found while checking last breakage, amount of time spent on discussion if it is OK to make a change was 10x more than amount of time that adding deprecations would take. It is waste of everyone's time! We need to establish attitude were doing deprecations is a no-brainer, like providing unittests for new functionality already is. Not because some weird corporate ass demands it but because it is simple and benefits the whole dub ecosystem. signature.asc Description: OpenPGP digital signature
Re: Release D 2.072.0
On 11/12/2016 02:20 PM, Basile B. wrote: > 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. Thank you for the report! Will add that to required reverts in a moment. Both points you have mentioned indeed can and should be addressed. signature.asc Description: OpenPGP digital signature
Re: Release D 2.072.0
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.
Re: Release D 2.072.0
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
Re: Release D 2.072.0
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
Re: Release D 2.072.0
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.
Re: Release D 2.072.0
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.
Re: Release D 2.072.0
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
Re: Release D 2.072.0
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
Re: Release D 2.072.0
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?
Re: Release D 2.072.0
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. signature.asc Description: OpenPGP digital signature
Re: Release D 2.072.0
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
Re: Release D 2.072.0
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
Re: Release D 2.072.0
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 .. or one can spend one extra hour to implement deprecation path and the issue disappears completely.
Re: Release D 2.072.0
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.
Re: Release D 2.072.0
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.
Re: Release D 2.072.0
On Thursday, 10 November 2016 at 23:02:09 UTC, Soulsbane wrote:
On Thursday, 10 November 2016 at 15:38:08 UTC, Dicebot wrote:
On 11/05/2016 06:04 AM, Soulsbane wrote:
[...]
Can't reproduce:
$ cat sample.d
unittest
{
import std.regex;
static immutable TOC_LINE_PATTERN =
`#{1,}\s*(?P.*):\s*(?P.*)`;
auto linePattern = ctRegex!(TOC_LINE_PATTERN);
}
$ dmd-dev -release -O -inline -unittest -main -run sample.d
Can you provide more details?
Sorry I hadn't gotten back on this. Isolating the code like you
did doesn't produce the error. It only fails in my larger
project(same code). It's strange.
The code is in
https://github.com/Soulsbane/luaaddon/blob/master/source/luaaddon/tocparser.d
Using struct TocParser in an empty project(just main) works
just fine. But as part of my later project(skeletor) it fails
to compile.
Thanks.
Linked wrong file.
https://github.com/Soulsbane/luaaddon/blob/7d60711b7b733144f3925a57380e58eb2aab997e/source/luaaddon/tocparser.d is the correct one.
Re: Release D 2.072.0
On Thursday, 10 November 2016 at 15:38:08 UTC, Dicebot wrote:
On 11/05/2016 06:04 AM, Soulsbane wrote:
On Monday, 31 October 2016 at 01:27:08 UTC, Martin Nowak wrote:
Glad to announce D 2.072.0.
http://dlang.org/changelog/2.072.0.html
-Martin
I've run into a problem with code using ctRegex that fails to
compile only in release build.
Can't reproduce:
$ cat sample.d
unittest
{
import std.regex;
static immutable TOC_LINE_PATTERN =
`#{1,}\s*(?P.*):\s*(?P.*)`;
auto linePattern = ctRegex!(TOC_LINE_PATTERN);
}
$ dmd-dev -release -O -inline -unittest -main -run sample.d
Can you provide more details?
Sorry I hadn't gotten back on this. Isolating the code like you
did doesn't produce the error. It only fails in my larger
project(same code). It's strange.
The code is in
https://github.com/Soulsbane/luaaddon/blob/master/source/luaaddon/tocparser.d
Using struct TocParser in an empty project(just main) works just
fine. But as part of my later project(skeletor) it fails to
compile.
Thanks.
Re: Release D 2.072.0
On 11/05/2016 06:04 AM, Soulsbane wrote:
> On Monday, 31 October 2016 at 01:27:08 UTC, Martin Nowak wrote:
>> Glad to announce D 2.072.0.
>>
>> http://dlang.org/changelog/2.072.0.html
>>
>> -Martin
>
> I've run into a problem with code using ctRegex that fails to compile
> only in release build.
Can't reproduce:
$ cat sample.d
unittest
{
import std.regex;
static immutable TOC_LINE_PATTERN =
`#{1,}\s*(?P.*):\s*(?P.*)`;
auto linePattern = ctRegex!(TOC_LINE_PATTERN);
}
$ dmd-dev -release -O -inline -unittest -main -run sample.d
Can you provide more details?
signature.asc
Description: OpenPGP digital signature
Re: Release D 2.072.0
On Thursday, 10 November 2016 at 13:58:56 UTC, Steven Schveighoffer wrote: This is not possible. Old behavior DID detect some cycles. The new algorithm detects ALL cycles, and handles them all in the same way. What you are asking is for cycles detected by old algorithm to fail, but ones that wouldn't have been detected to pass. Not to mention that the order of ctor execution is not guaranteed to be the same (i.e. some latent bug may be hiding there). Only possibility is just to ignore ALL cycles, and print them if any are detected. I presume I have to look for commits that implement http://dlang.org/changelog/2.072.0.html#drt-oncycle to fixup this? The PR for this was here: https://github.com/dlang/druntime/pull/1668 Thanks! I'll have to check the code first :)
Re: Release D 2.072.0
On 11/10/16 8:26 AM, Dicebot wrote: On 11/03/2016 05:51 PM, Steven Schveighoffer wrote: On 11/3/16 10:49 AM, Johan Engelen wrote: On Wednesday, 2 November 2016 at 15:13:43 UTC, anonymous wrote: On Wednesday, 2 November 2016 at 15:08:26 UTC, anonymous wrote: I confirm, dmd 2.072 can't build dmd 2.071.2, same error, but boot since master straping works there's probably something that's been fixed in one or two of these ddmd modules, likely a static ctor... Maybe after this: https://github.com/dlang/dmd/commit/1d0ab8b9c136e46bf449c506ca25d2c8a784f7b9#diff-b4674e7b5d3a44178526afdefc9aa368 ddmd.attribs was removed https://github.com/dlang/dmd/commit/1d0ab8b9c136e46bf449c506ca25d2c8a784f7b9#diff-b4674e7b5d3a44178526afdefc9aa368L15 and it was also part of the cycle. Thanks for the detective work. I wonder where the bug is: in 2.071 or in 2.072 :) Any cycles that are "newly discovered" were already there. What was happening is that the runtime did not detect the cycle, and was arbitrarily choosing an order for initializing these modules. It does not justify immediate breaking change. What should have been done instead: - Keep old behavior by default by default but print non-fatal runtime message that cycles are detected. This is not possible. Old behavior DID detect some cycles. The new algorithm detects ALL cycles, and handles them all in the same way. What you are asking is for cycles detected by old algorithm to fail, but ones that wouldn't have been detected to pass. Not to mention that the order of ctor execution is not guaranteed to be the same (i.e. some latent bug may be hiding there). Only possibility is just to ignore ALL cycles, and print them if any are detected. I presume I have to look for commits that implement http://dlang.org/changelog/2.072.0.html#drt-oncycle to fixup this? The PR for this was here: https://github.com/dlang/druntime/pull/1668 -Steve
Re: Release D 2.072.0
On 11/03/2016 05:51 PM, Steven Schveighoffer wrote: > On 11/3/16 10:49 AM, Johan Engelen wrote: >> On Wednesday, 2 November 2016 at 15:13:43 UTC, anonymous wrote: >>> On Wednesday, 2 November 2016 at 15:08:26 UTC, anonymous wrote: I confirm, dmd 2.072 can't build dmd 2.071.2, same error, but boot since master straping works there's probably something that's been fixed in one or two of these ddmd modules, likely a static ctor... >>> >>> Maybe after this: >>> >>> https://github.com/dlang/dmd/commit/1d0ab8b9c136e46bf449c506ca25d2c8a784f7b9#diff-b4674e7b5d3a44178526afdefc9aa368 >>> >>> >>> >>> ddmd.attribs was removed >>> >>> https://github.com/dlang/dmd/commit/1d0ab8b9c136e46bf449c506ca25d2c8a784f7b9#diff-b4674e7b5d3a44178526afdefc9aa368L15 >>> >>> >>> >>> and it was also part of the cycle. >> >> Thanks for the detective work. >> I wonder where the bug is: in 2.071 or in 2.072 :) > > Any cycles that are "newly discovered" were already there. What was > happening is that the runtime did not detect the cycle, and was > arbitrarily choosing an order for initializing these modules. It does not justify immediate breaking change. What should have been done instead: - Keep old behavior by default by default but print non-fatal runtime message that cycles are detected. - Provide options both to make cycle detection fatal and to suppress message completely. - Make fatal one the default one release later I presume I have to look for commits that implement http://dlang.org/changelog/2.072.0.html#drt-oncycle to fixup this? signature.asc Description: OpenPGP digital signature
Re: Release D 2.072.0
Dne 9.11.2016 v 15:17 Dicebot via Digitalmars-d-announce napsal(a): Sadly, because of overwhelming project breakage I have to revert Arch Linux dmd package version back to 2.071.2 until 2.072.1 is out :( Going to look into known regressions later this week, at least some of them look easily fixable to become deprecations. Thank you
Re: Release D 2.072.0
Sadly, because of overwhelming project breakage I have to revert Arch Linux dmd package version back to 2.071.2 until 2.072.1 is out :( Going to look into known regressions later this week, at least some of them look easily fixable to become deprecations. signature.asc Description: OpenPGP digital signature
Re: Release D 2.072.0
On Monday, 7 November 2016 at 18:55:29 UTC, Anonymous wrote: To be honest, I know that the D world existed before me, and I know that it'll still exist if I leave. Between, 2.072 is the worst release I've ever seen. Yep. I tried 2.072 on a current DLangUI project under Win32. Compiled fine, but at runtime - exception, exception, exception, crash, crash, crash. Nothing works (what worked ok with previous dmd). Ran away screaming, back to 2.071. Sorry. I might try exploring the issues a bit later, can't do right now.
Re: Release D 2.072.0
On Monday, 7 November 2016 at 18:26:44 UTC, Anonymous wrote: 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 It seems that there was another regression that nobody detected, because nobody has build one of the major tool used by most of the D enthusiastic: https://github.com/Hackerpilot/DCD/issues/352 https://issues.dlang.org/show_bug.cgi?id=16663 To be honest, I know that the D world existed before me, and I know that it'll still exist if I leave. Between, 2.072 is the worst release I've ever seen.
Re: Release D 2.072.0
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 It seems that there was another regression that nobody detected, because nobody has build one of the major tool used by most of the D enthusiastic: https://github.com/Hackerpilot/DCD/issues/352 https://issues.dlang.org/show_bug.cgi?id=16663
Re: Release D 2.072.0
Hello, Here is another bug: https://issues.dlang.org/show_bug.cgi?id=16667 app unit tests start to fail on std.conv internal unit tests.
Re: Release D 2.072.0
Am 06.11.2016 um 09:22 schrieb Daniel Kozak via Digitalmars-d-announce: Dne 6.11.2016 v 07:58 Sönke Ludwig via Digitalmars-d-announce napsal(a): I checked now and the version included in the (Windows) DMD bundle indeed reports as 1.0.0, so the fix is not present. But the next DMD point release will include 1.1.1, which includes all changes to date. I'll also put binaries of 1.1.0 on code.dlang.org in a few minutes. Is there a place when one can check this? I mean in which repository this is placed? The version is reported with "dub --version", the change log is here: https://github.com/dlang/dub/blob/master/CHANGELOG.md The actual version in the bundle is not stored in a repository as far as I know, but is just an artifact of the build process.
Re: Release D 2.072.0
Dne 6.11.2016 v 07:58 Sönke Ludwig via Digitalmars-d-announce napsal(a):
Am 03.11.2016 um 14:18 schrieb Andre Pany:
On Thursday, 3 November 2016 at 12:17:29 UTC, Sönke Ludwig wrote:
Am 03.11.2016 um 06:58 schrieb Andre Pany:
Temp-folder builds are only done if the special shebang invocation
syntax is used (i.e. "dub file.d
Unfortunately yes, the behavior of dub included in dmd 2.072 is not as
expected (windows & linux).
/+ dub.sdl:
name "app"
+/
void main(){}
dub --single app.d
Running
..\..\..\..\..\Users\abcdef\AppData\Local\Temp\.dub\build\app-~master\application-debug-windows-x86-dmd_2072-A4FA96FDE8C9353FB025486E4835F2E0\app.exe
Same behavior for dub build --single app.d
Kind regards
André
I checked now and the version included in the (Windows) DMD bundle
indeed reports as 1.0.0, so the fix is not present. But the next DMD
point release will include 1.1.1, which includes all changes to date.
I'll also put binaries of 1.1.0 on code.dlang.org in a few minutes.
Is there a place when one can check this? I mean in which repository
this is placed?
Re: Release D 2.072.0
Am 03.11.2016 um 14:18 schrieb Andre Pany:
On Thursday, 3 November 2016 at 12:17:29 UTC, Sönke Ludwig wrote:
Am 03.11.2016 um 06:58 schrieb Andre Pany:
Temp-folder builds are only done if the special shebang invocation
syntax is used (i.e. "dub file.d
Unfortunately yes, the behavior of dub included in dmd 2.072 is not as
expected (windows & linux).
/+ dub.sdl:
name "app"
+/
void main(){}
dub --single app.d
Running
..\..\..\..\..\Users\abcdef\AppData\Local\Temp\.dub\build\app-~master\application-debug-windows-x86-dmd_2072-A4FA96FDE8C9353FB025486E4835F2E0\app.exe
Same behavior for dub build --single app.d
Kind regards
André
I checked now and the version included in the (Windows) DMD bundle
indeed reports as 1.0.0, so the fix is not present. But the next DMD
point release will include 1.1.1, which includes all changes to date.
I'll also put binaries of 1.1.0 on code.dlang.org in a few minutes.
Re: Release D 2.072.0
On Saturday, 5 November 2016 at 04:04:12 UTC, Soulsbane wrote: On Monday, 31 October 2016 at 01:27:08 UTC, Martin Nowak wrote: [...] I've run into a problem with code using ctRegex that fails to compile only in release build. [...] please report at https://issues.dlang.org/
Re: Release D 2.072.0
On Friday, November 04, 2016 00:45:18 Johan Engelen via Digitalmars-d- announce wrote: > On Friday, 4 November 2016 at 00:42:48 UTC, Johan Engelen wrote: > > On Thursday, 3 November 2016 at 15:51:22 UTC, Steven > > > > Schveighoffer wrote: > >> Any cycles that are "newly discovered" were already there. > >> What was happening is that the runtime did not detect the > >> cycle, and was arbitrarily choosing an order for initializing > >> these modules. Either a) the arbitrary order happened to be > >> right, or b) the order didn't matter. Most of the time it's b, > >> because most static ctors don't depend on externally > >> initialized items. > > > > My question is: any cycle is invalid? > > nevermind, I found this: > https://dlang.org/spec/module.html#order_of_static_ctor Yeah, that's why we avoid static constructors in Phobos if we can. In theory, they're great, but in practice, they have a tendency to cause problems. Modules which don't import much of anything else from within the same library tend to be fine, but once a library or application has modules which import other modules within that library, you can get circular imports surprisingly easily, and Phobos is rife with them. There are cases where we actually have other modules specifically to do the static constructors for another module in order to avoid having static constructors in the import cycle (e.g. std.stdiobase does that for std.stdio) - but that doesn't play well with stuff like immutable, just mutable stuff that needs to be initialized at runtime. - Jonathan M Davis
Re: Release D 2.072.0
On Monday, 31 October 2016 at 20:35:24 UTC, Martin Nowak wrote: and I did take care of that forward reference bug (Issue 16607). Thanks again for that. That one would've actually kept me from upgrading for my current project.
Re: Release D 2.072.0
On Monday, 31 October 2016 at 01:27:08 UTC, Martin Nowak wrote:
Glad to announce D 2.072.0.
http://dlang.org/changelog/2.072.0.html
-Martin
I've run into a problem with code using ctRegex that fails to
compile only in release build.
private immutable string TOC_LINE_PATTERN =
`#{1,}\s*(?P.*):\s*(?P.*)`;
auto linePattern = ctRegex!(TOC_LINE_PATTERN);
Error:
/usr/include/dmd/phobos/std/uni.d(3133,13): Error: integral
constant must be scalar type, not void
/usr/include/dmd/phobos/std/functional.d-mixin-200(200,1): Error:
__a.data is not yet implemented at compile time
/usr/include/dmd/phobos/std/algorithm/searching.d(894,34):
called from here: pred2(((InversionList!(GcPolicy) __copytmp4412
= (ref InversionList!(GcPolicy) this = __copytmp4412 =
haystack[cast(ulong)i];) , ((ref CowArray!(GcPolicy) this =
this.data;) , !((ref CowArray!(GcPolicy) this = this;) ,
this.data.length == 0LU) && ((ref CowArray!(GcPolicy) this =
this;) , ((uint cnt = ((ref CowArray!(GcPolicy) this = this;) ,
this.data[__dollar - 1LU]) + 1u;)) , this.data[__dollar - 1LU] =
cnt));) , __copytmp4412))
/usr/include/dmd/phobos/std/algorithm/searching.d(816,28):
called from here: countUntil(haystack)
/usr/include/dmd/phobos/std/regex/internal/parser.d(327,46):
called from here: countUntil(this.charsets,
((InversionList!(GcPolicy) __copytmp4413 = (__copytmp4413 =
set).__fieldPostblit();) , __copytmp4413))
/usr/include/dmd/phobos/std/regex/internal/parser.d(946,30):
called from here: this.g.charsetToIr(set.add(10u, 11u).add(13u,
14u).inverted())
/usr/include/dmd/phobos/std/regex/internal/parser.d(858,26):
called from here: this.parseAtom()
/usr/include/dmd/phobos/std/regex/internal/parser.d(636,23):
called from here: this.parseRegex()
/usr/include/dmd/phobos/std/regex/package.d(378,61):
called from here: parser.this(pattern, flags)
/usr/include/dmd/phobos/std/regex/package.d(349,25):
called from here: regexImpl(pat, flags)
/usr/include/dmd/phobos/std/regex/package.d(357,17):
called from here: regex([pattern], flags)
/usr/include/dmd/phobos/std/regex/package.d(387,19):
called from here: regex(TOC_LINE_PATTERN, [])
/usr/include/dmd/phobos/std/regex/package.d(409,54): Error:
template instance
luaaddon.tocparser.TocParser.ctRegexImpl!(TOC_LINE_PATTERN, [])
error instantiating
../libs/luaaddon/source/luaaddon/tocparser.d(31,22):
instantiated from here: ctRegex!(TOC_LINE_PATTERN, [])
It compiles just fine in debug build.
Thanks!
Re: Release D 2.072.0
On Friday, 4 November 2016 at 00:42:48 UTC, Johan Engelen wrote: On Thursday, 3 November 2016 at 15:51:22 UTC, Steven Schveighoffer wrote: Any cycles that are "newly discovered" were already there. What was happening is that the runtime did not detect the cycle, and was arbitrarily choosing an order for initializing these modules. Either a) the arbitrary order happened to be right, or b) the order didn't matter. Most of the time it's b, because most static ctors don't depend on externally initialized items. My question is: any cycle is invalid? nevermind, I found this: https://dlang.org/spec/module.html#order_of_static_ctor
Re: Release D 2.072.0
On Thursday, 3 November 2016 at 15:51:22 UTC, Steven Schveighoffer wrote: Any cycles that are "newly discovered" were already there. What was happening is that the runtime did not detect the cycle, and was arbitrarily choosing an order for initializing these modules. Either a) the arbitrary order happened to be right, or b) the order didn't matter. Most of the time it's b, because most static ctors don't depend on externally initialized items. My question is: any cycle is invalid? -Johan
Re: Release D 2.072.0
On 11/3/16 10:49 AM, Johan Engelen wrote: On Wednesday, 2 November 2016 at 15:13:43 UTC, anonymous wrote: On Wednesday, 2 November 2016 at 15:08:26 UTC, anonymous wrote: I confirm, dmd 2.072 can't build dmd 2.071.2, same error, but boot since master straping works there's probably something that's been fixed in one or two of these ddmd modules, likely a static ctor... Maybe after this: https://github.com/dlang/dmd/commit/1d0ab8b9c136e46bf449c506ca25d2c8a784f7b9#diff-b4674e7b5d3a44178526afdefc9aa368 ddmd.attribs was removed https://github.com/dlang/dmd/commit/1d0ab8b9c136e46bf449c506ca25d2c8a784f7b9#diff-b4674e7b5d3a44178526afdefc9aa368L15 and it was also part of the cycle. Thanks for the detective work. I wonder where the bug is: in 2.071 or in 2.072 :) Any cycles that are "newly discovered" were already there. What was happening is that the runtime did not detect the cycle, and was arbitrarily choosing an order for initializing these modules. Either a) the arbitrary order happened to be right, or b) the order didn't matter. Most of the time it's b, because most static ctors don't depend on externally initialized items. Note that the push to remove imports to packages and instead import more specific submodules (i.e. import std.range.primitives instead of std.range) also plays a factor (it's how I discovered the cycles were broken). I doubt there was much of that in dmd front end. -Steve
Re: Release D 2.072.0
On 10/31/2016 03:27 AM, Martin Nowak wrote: > Glad to announce D 2.072.0. NB: Current release notes are outdated and wrong about `-transition=safe` flag. It was completely repurposed in stable branch (https://github.com/dlang/dmd/pull/6183) but somehow changes to release notes there do not propagate to released changelog. signature.asc Description: OpenPGP digital signature
Re: Release D 2.072.0
On Wednesday, 2 November 2016 at 15:13:43 UTC, anonymous wrote: On Wednesday, 2 November 2016 at 15:08:26 UTC, anonymous wrote: I confirm, dmd 2.072 can't build dmd 2.071.2, same error, but boot since master straping works there's probably something that's been fixed in one or two of these ddmd modules, likely a static ctor... Maybe after this: https://github.com/dlang/dmd/commit/1d0ab8b9c136e46bf449c506ca25d2c8a784f7b9#diff-b4674e7b5d3a44178526afdefc9aa368 ddmd.attribs was removed https://github.com/dlang/dmd/commit/1d0ab8b9c136e46bf449c506ca25d2c8a784f7b9#diff-b4674e7b5d3a44178526afdefc9aa368L15 and it was also part of the cycle. Thanks for the detective work. I wonder where the bug is: in 2.071 or in 2.072 :)
Re: Release D 2.072.0
On 11/2/16 8:36 AM, Johan Engelen wrote: On Tuesday, 1 November 2016 at 16:40:42 UTC, Andrei Alexandrescu wrote: On 11/01/2016 11:41 AM, Johan Engelen wrote: On Monday, 31 October 2016 at 01:27:08 UTC, Martin Nowak wrote: Glad to announce D 2.072.0. DMD 2.072.0 miscompiles/uncovers a bug in LDC, so I switched back to DMD 2.071.2 for CI testing. :( Is there somebody working on that bug? Thanks. -- Andrei LDC built with DMD 2.072.0 gives the following error when run: object.Error@src/rt/minfo.d(356): Cyclic dependency between module ddmd.traits and ddmd.cond ddmd.traits* -> ddmd.attrib -> ddmd.cond* -> ddmd.expression -> ddmd.traits* The issue is that DDMD has cycles, always has. But the cycle detection was broken. This is now fixed in 2.072. An unfortunate side effect from having broken cycle detection since 2011 is that many projects will now detect cycles. 2.072 is going to break a lot of code that was already "broken". I use scare quotes because likely the code is just fine, but the cycle detection is so broad that it's easy to get caught in the net. The best answer is to somehow do better cycle detection (e.g. determine if there really are dependencies that break with cycles). We have some ideas, but nothing has been fleshed out yet. -Steve
Re: Release D 2.072.0
On Thursday, 3 November 2016 at 12:17:29 UTC, Sönke Ludwig wrote:
Am 03.11.2016 um 06:58 schrieb Andre Pany:
Temp-folder builds are only done if the special shebang
invocation syntax is used (i.e. "dub file.d Building with "dub --single file.d" should build normally. This
was the case within the thread, too. Has anything changed since
then?
Unfortunately yes, the behavior of dub included in dmd 2.072 is
not as expected (windows & linux).
/+ dub.sdl:
name "app"
+/
void main(){}
dub --single app.d
Running
..\..\..\..\..\Users\abcdef\AppData\Local\Temp\.dub\build\app-~master\application-debug-windows-x86-dmd_2072-A4FA96FDE8C9353FB025486E4835F2E0\app.exe
Same behavior for dub build --single app.d
Kind regards
André
Re: Release D 2.072.0
Am 03.11.2016 um 06:58 schrieb Andre Pany: 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 Thanks for the new release. There is an issue with this Dub version, which is as far as I understand a bug. While building/running a single source file project (dub information included in D source file) the artifacts are created in a temporary folder instead of the source file folder. This makes the single file functionality in dub more or less not usable for me, as you cannot influence the behavior. http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/13012/ Kind regards André Temp-folder builds are only done if the special shebang invocation syntax is used (i.e. "dub file.d --single file.d" should build normally. This was the case within the thread, too. Has anything changed since then?
Re: Release D 2.072.0
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 Thanks for the new release. There is an issue with this Dub version, which is as far as I understand a bug. While building/running a single source file project (dub information included in D source file) the artifacts are created in a temporary folder instead of the source file folder. This makes the single file functionality in dub more or less not usable for me, as you cannot influence the behavior. http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/13012/ Kind regards André
Re: Release D 2.072.0
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 https://www.reddit.com/r/programming/comments/5aru4f/d_version_2072_released_over_200_bugs_fixed/
Re: Release D 2.072.0
On Wednesday, 2 November 2016 at 15:08:26 UTC, anonymous wrote: On Wednesday, 2 November 2016 at 12:36:45 UTC, Johan Engelen wrote: LDC built with DMD 2.072.0 gives the following error when run: object.Error@src/rt/minfo.d(356): Cyclic dependency between module ddmd.traits and ddmd.cond ddmd.traits* -> ddmd.attrib -> ddmd.cond* -> ddmd.expression -> ddmd.traits* Pretty much all of LDC's D code is DDMD front-end code, master is at front-end version 2.071.2. I hope someone can try to build DMD 2.071.2 using 2.072.0 and see if a similar issue is found. I confirm, dmd 2.072 can't build dmd 2.071.2, same error, but boot since master straping works there's probably something that's been fixed in one or two of these ddmd modules, likely a static ctor... Maybe after this: https://github.com/dlang/dmd/commit/1d0ab8b9c136e46bf449c506ca25d2c8a784f7b9#diff-b4674e7b5d3a44178526afdefc9aa368 ddmd.attribs was removed https://github.com/dlang/dmd/commit/1d0ab8b9c136e46bf449c506ca25d2c8a784f7b9#diff-b4674e7b5d3a44178526afdefc9aa368L15 and it was also part of the cycle.
Re: Release D 2.072.0
On Wednesday, 2 November 2016 at 12:36:45 UTC, Johan Engelen wrote: LDC built with DMD 2.072.0 gives the following error when run: object.Error@src/rt/minfo.d(356): Cyclic dependency between module ddmd.traits and ddmd.cond ddmd.traits* -> ddmd.attrib -> ddmd.cond* -> ddmd.expression -> ddmd.traits* Pretty much all of LDC's D code is DDMD front-end code, master is at front-end version 2.071.2. I hope someone can try to build DMD 2.071.2 using 2.072.0 and see if a similar issue is found. I confirm, dmd 2.072 can't build dmd 2.071.2, same error, but boot since master straping works there's probably something that's been fixed in one or two of these ddmd modules, likely a static ctor...
Re: Release D 2.072.0
On Tuesday, 1 November 2016 at 16:40:42 UTC, Andrei Alexandrescu wrote: On 11/01/2016 11:41 AM, Johan Engelen wrote: On Monday, 31 October 2016 at 01:27:08 UTC, Martin Nowak wrote: Glad to announce D 2.072.0. DMD 2.072.0 miscompiles/uncovers a bug in LDC, so I switched back to DMD 2.071.2 for CI testing. :( Is there somebody working on that bug? Thanks. -- Andrei LDC built with DMD 2.072.0 gives the following error when run: object.Error@src/rt/minfo.d(356): Cyclic dependency between module ddmd.traits and ddmd.cond ddmd.traits* -> ddmd.attrib -> ddmd.cond* -> ddmd.expression -> ddmd.traits* Pretty much all of LDC's D code is DDMD front-end code, master is at front-end version 2.071.2. I hope someone can try to build DMD 2.071.2 using 2.072.0 and see if a similar issue is found.
Re: Release D 2.072.0
On 11/01/2016 11:41 AM, Johan Engelen wrote: On Monday, 31 October 2016 at 01:27:08 UTC, Martin Nowak wrote: Glad to announce D 2.072.0. DMD 2.072.0 miscompiles/uncovers a bug in LDC, so I switched back to DMD 2.071.2 for CI testing. :( Is there somebody working on that bug? Thanks. -- Andrei
Re: Release D 2.072.0
On Monday, 31 October 2016 at 01:27:08 UTC, Martin Nowak wrote: Glad to announce D 2.072.0. DMD 2.072.0 miscompiles/uncovers a bug in LDC, so I switched back to DMD 2.071.2 for CI testing. :( -Johan
Re: Release D 2.072.0
On Monday, 31 October 2016 at 07:27:50 UTC, Ali Çehreli wrote:
Is the only valid remaining use for the comma operator the
'for' loop iteration?
for ( ; ; ++i, ++j) {
// ...
}
Are there other uses?
The changelog shows it can be used for an expression statement:
// This is okay, the result is not used.
if (!mc)
mc = new MyContainerClass, mc.append(new Entry);
I've made a pull to improve the comma examples, e.g. adding
brackets (mc = ...), mc.append and removing unnecessary
statements:
https://github.com/dlang/dlang.org/pull/1502
Would be good if someone could review and merge.
Re: Release D 2.072.0
On 10/31/2016 09:35 PM, Martin Nowak wrote: There weren't any open regressions left in Bugzilla blocking this release, What makes a regression blocking? There are three open regressions in 2.072: https://issues.dlang.org/show_bug.cgi?id=16013 https://issues.dlang.org/show_bug.cgi?id=16273 https://issues.dlang.org/show_bug.cgi?id=16574
Re: Release D 2.072.0
On 10/31/2016 08:45 AM, Sönke Ludwig wrote: > BTW, I was really surprised that there was not at least one release > candidate. There is a forward reference regression that happened after > the last beta and affects vibe.d. I'll see if I can find a workaround. There weren't any open regressions left in Bugzilla blocking this release, and I did take care of that forward reference bug (Issue 16607). I did not want to delay the release any further. We can always follow up with point releases if more fixes come in. I hope https://ci.dawg.eu/ helps to avoid accumulating so many issues in the first place. -Martin
Re: Release D 2.072.0
On 10/31/2016 08:24 AM, Sönke Ludwig wrote: > Hm, looks like DUB 1.1.0 was tagged on master instead of stable, which > means that some fixes are missing and some changes haven't gone through > a testing phase. Can we still fix this for this release? Shoot, sorry for that. We still need to integrate dub into http://wiki.dlang.org/DMD_Release_Building.
Re: Release D 2.072.0
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 Thanks, About http://dlang.org/changelog/2.072.0.html#drt-oncycle I'll maybe propose this: https://issues.dlang.org/show_bug.cgi?id=16583 The ability to solve conflicts with selective/global imports as a language spec.
Re: Release D 2.072.0
On Monday, 31 October 2016 at 07:24:23 UTC, Sönke Ludwig wrote: Am 31.10.2016 um 02:27 schrieb Martin Nowak: 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 Hm, looks like DUB 1.1.0 was tagged on master instead of stable, which means that some fixes are missing and some changes haven't gone through a testing phase. Can we still fix this for this release? Martin, have you considered posting each release* here on the newsgroup 24 hours before the actual release, marked "pre-release sanity check" so mistakes like this are more likely to be caught? * and I mean the actual bit-for-bit identical release packages here; this is test-firing the actual rocket that's going to space.
Re: Release D 2.072.0
Am 31.10.2016 um 08:24 schrieb Sönke Ludwig: Am 31.10.2016 um 02:27 schrieb Martin Nowak: 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 Hm, looks like DUB 1.1.0 was tagged on master instead of stable, which means that some fixes are missing and some changes haven't gone through a testing phase. Can we still fix this for this release? BTW, I was really surprised that there was not at least one release candidate. There is a forward reference regression that happened after the last beta and affects vibe.d. I'll see if I can find a workaround.
Re: Release D 2.072.0
Am 31.10.2016 um 08:24 schrieb Sönke Ludwig: Am 31.10.2016 um 02:27 schrieb Martin Nowak: 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 Hm, looks like DUB 1.1.0 was tagged on master instead of stable, which means that some fixes are missing and some changes haven't gone through a testing phase. Can we still fix this for this release? 2a90bd1c0d18d5a706723757cf01aeffc179ee1f is the right commit hash.
Re: Release D 2.072.0
On 10/30/2016 06:27 PM, 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
Thanks!
Is the only valid remaining use for the comma operator the 'for' loop
iteration?
for ( ; ; ++i, ++j) {
// ...
}
Are there other uses?
Ali
Re: Release D 2.072.0
Am 31.10.2016 um 02:27 schrieb Martin Nowak: 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 Hm, looks like DUB 1.1.0 was tagged on master instead of stable, which means that some fixes are missing and some changes haven't gone through a testing phase. Can we still fix this for this release?
Re: Release D 2.072.0
On 10/30/2016 09:27 PM, Martin Nowak wrote: This is the release ships with the latest version of dub (v1.1.0), Changelog for dub 1.1.0?
Release D 2.072.0
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
