www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Release D 2.072.0

reply Martin Nowak <code+news.digitalmars dawg.eu> writes:
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
Oct 30 2016
next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
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?
Oct 30 2016
prev sibling next sibling parent reply =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig+d outerproduct.org> writes:
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?
Oct 31 2016
next sibling parent =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig+d outerproduct.org> writes:
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.
Oct 31 2016
prev sibling next sibling parent reply =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig+d outerproduct.org> writes:
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.
Oct 31 2016
parent reply Martin Nowak <code+news.digitalmars dawg.eu> writes:
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
Oct 31 2016
next sibling parent ag0aep6g <anonymous example.com> writes:
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
Oct 31 2016
prev sibling parent Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
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.
Nov 04 2016
prev sibling next sibling parent John Colvin <john.loughran.colvin gmail.com> writes:
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.
Oct 31 2016
prev sibling parent Martin Nowak <code+news.digitalmars dawg.eu> writes:
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.
Oct 31 2016
prev sibling next sibling parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
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
Oct 31 2016
parent Nick Treleaven <nick geany.org> writes:
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.
Nov 01 2016
prev sibling next sibling parent Basile B. <b2.temp gmx.com> writes:
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.
Oct 31 2016
prev sibling next sibling parent reply Johan Engelen <j j.nl> writes:
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
Nov 01 2016
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Nov 01 2016
parent reply Johan Engelen <j j.nl> writes:
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.
Nov 02 2016
next sibling parent reply anonymous <anon anon.au> writes:
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...
Nov 02 2016
parent reply anonymous <anon anon.au> writes:
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.
Nov 02 2016
parent reply Johan Engelen <j j.nl> writes:
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 :)
Nov 03 2016
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
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
Nov 03 2016
next sibling parent reply Johan Engelen <j j.nl> writes:
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
Nov 03 2016
parent reply Johan Engelen <j j.nl> writes:
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
Nov 03 2016
parent Jonathan M Davis via Digitalmars-d-announce writes:
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
Nov 05 2016
prev sibling parent reply Dicebot <public dicebot.lv> writes:
 protected-headers="v1"
From: Dicebot <public dicebot.lv>
Newsgroups: d,i,g,i,t,a,l,m,a,r,s,.,D,.,a,n,n,o,u,n,c,e
Subject: Re: Release D 2.072.0
References: <nv66le$hdi$1 digitalmars.com>
 <htekbzxibabyhbvxqavn forum.dlang.org> <nvagia$11as$1 digitalmars.com>
 <esbpwkinvxajrvddtqcb forum.dlang.org> <pogbwakstgkyyzwwdyaz forum.dlang.org>
 <mghfwvpvigbjaftlmocz forum.dlang.org> <gkvpmjlfjygatnlvataz forum.dlang.org>
 <nvfmdr$eb8$1 digitalmars.com>
In-Reply-To: <nvfmdr$eb8$1 digitalmars.com>

--bJ8AGPUK1JWsb3xg107r38L2BhFMN1vDj
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

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/1d0ab8b9c136e46bf449c506ca25d2c8a=
784f7b9#diff-b4674e7b5d3a44178526afdefc9aa368
 ddmd.attribs was removed

 https://github.com/dlang/dmd/commit/1d0ab8b9c136e46bf449c506ca25d2c8a=
784f7b9#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 :)
=20 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? --bJ8AGPUK1JWsb3xg107r38L2BhFMN1vDj--
Nov 10 2016
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
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
Nov 10 2016
next sibling parent Dicebot <public dicebot.lv> writes:
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 :)
Nov 10 2016
prev sibling parent reply Kagamin <spam here.lot> writes:
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.
Nov 11 2016
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
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.
Nov 11 2016
next sibling parent reply Dicebot <public dicebot.lv> writes:
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.
Nov 11 2016
next sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
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
Nov 11 2016
parent reply Dicebot <public dicebot.lv> writes:
 protected-headers="v1"
From: Dicebot <public dicebot.lv>
Newsgroups: d,i,g,i,t,a,l,m,a,r,s,.,D,.,a,n,n,o,u,n,c,e
Subject: Re: Release D 2.072.0
References: <nv66le$hdi$1 digitalmars.com>
 <htekbzxibabyhbvxqavn forum.dlang.org> <nvagia$11as$1 digitalmars.com>
 <esbpwkinvxajrvddtqcb forum.dlang.org> <pogbwakstgkyyzwwdyaz forum.dlang.org>
 <mghfwvpvigbjaftlmocz forum.dlang.org> <gkvpmjlfjygatnlvataz forum.dlang.org>
 <nvfmdr$eb8$1 digitalmars.com> <o01sil$2h6e$1 digitalmars.com>
 <o01ueu$1jee$1 digitalmars.com> <lzkfbbkfkinoutraaqbi forum.dlang.org>
 <o04gl4$26of$1 digitalmars.com> <jmesuauuaynomcjuyrzt forum.dlang.org>
 <o04i2o$28tn$1 digitalmars.com>
In-Reply-To: <o04i2o$28tn$1 digitalmars.com>

--Ixa4N8k2hruOXHUUKTmSo9bsvCuW75osN
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

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.
=20 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=3Dignore. 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. --Ixa4N8k2hruOXHUUKTmSo9bsvCuW75osN--
Nov 11 2016
parent Steven Schveighoffer <schveiguy yahoo.com> writes:
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
Nov 11 2016
prev sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
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.
Nov 11 2016
next sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
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.
Nov 11 2016
parent Steven Schveighoffer <schveiguy yahoo.com> writes:
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
Nov 11 2016
prev sibling next sibling parent Jonathan M Davis via Digitalmars-d-announce writes:
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
Nov 11 2016
prev sibling parent Dicebot <public dicebot.lv> writes:
 protected-headers="v1"
From: Dicebot <public dicebot.lv>
Newsgroups: d,i,g,i,t,a,l,m,a,r,s,.,D,.,a,n,n,o,u,n,c,e
Subject: Re: Release D 2.072.0
References: <nv66le$hdi$1 digitalmars.com>
 <htekbzxibabyhbvxqavn forum.dlang.org> <nvagia$11as$1 digitalmars.com>
 <esbpwkinvxajrvddtqcb forum.dlang.org> <pogbwakstgkyyzwwdyaz forum.dlang.org>
 <mghfwvpvigbjaftlmocz forum.dlang.org> <gkvpmjlfjygatnlvataz forum.dlang.org>
 <nvfmdr$eb8$1 digitalmars.com> <o01sil$2h6e$1 digitalmars.com>
 <o01ueu$1jee$1 digitalmars.com> <lzkfbbkfkinoutraaqbi forum.dlang.org>
 <o04gl4$26of$1 digitalmars.com> <jmesuauuaynomcjuyrzt forum.dlang.org>
 <o056ks$19r3$1 digitalmars.com>
In-Reply-To: <o056ks$19r3$1 digitalmars.com>

--j3RTTfW1xMCpCF3nN0Gxifp3mB6WorA9n
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

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
=20 I've gone through a lot of compiler upgrades on a lot of D projects, an=
d
 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.
=20
 - 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
=20 AFAICT, That's not the case with this particular cycle detection matter=
=2E 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. --j3RTTfW1xMCpCF3nN0Gxifp3mB6WorA9n--
Nov 15 2016
prev sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
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
Nov 11 2016
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
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?
Nov 11 2016
parent Steven Schveighoffer <schveiguy yahoo.com> writes:
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
Nov 11 2016
prev sibling parent Steven Schveighoffer <schveiguy yahoo.com> writes:
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
Nov 03 2016
prev sibling next sibling parent Jack Stouffer <jack jackstouffer.com> writes:
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/
Nov 02 2016
prev sibling next sibling parent reply Andre Pany <andre s-e-a-p.de> writes:
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é
Nov 02 2016
parent reply =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig outerproduct.org> writes:
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 <program args"). Building with "dub --single file.d" should build normally. This was the case within the thread, too. Has anything changed since then?
Nov 03 2016
parent reply Andre Pany <andre s-e-a-p.de> writes:
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 <program args"). 
 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é
Nov 03 2016
parent reply =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig+d outerproduct.org> writes:
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 <program args"). 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é
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.
Nov 05 2016
parent reply Daniel Kozak via Digitalmars-d-announce writes:
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 <program args"). 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-A4FA96FDE8C9353FB025
86E4835F2E0\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?
Nov 06 2016
parent =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig outerproduct.org> writes:
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.
Nov 06 2016
prev sibling next sibling parent Dicebot <public dicebot.lv> writes:
 protected-headers="v1"
From: Dicebot <public dicebot.lv>
Newsgroups: d,i,g,i,t,a,l,m,a,r,s,.,D,.,a,n,n,o,u,n,c,e
Subject: Re: Release D 2.072.0
References: <nv66le$hdi$1 digitalmars.com>
In-Reply-To: <nv66le$hdi$1 digitalmars.com>

--DwRrNuhiQT0mIa7kLLnid87g9OAloLEtw
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

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=3Dsafe` 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. --DwRrNuhiQT0mIa7kLLnid87g9OAloLEtw--
Nov 03 2016
prev sibling next sibling parent reply Soulsbane <paul acheronsoft.com> writes:
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<key>.*):\s*(?P<value>.*)`; 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!
Nov 04 2016
next sibling parent reply John Colvin <john.loughran.colvin gmail.com> writes:
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/
Nov 05 2016
parent ikod <geller.garry gmail.com> writes:
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.
Nov 07 2016
prev sibling parent reply Dicebot <public dicebot.lv> writes:
 protected-headers="v1"
From: Dicebot <public dicebot.lv>
Newsgroups: d,i,g,i,t,a,l,m,a,r,s,.,D,.,a,n,n,o,u,n,c,e
Subject: Re: Release D 2.072.0
References: <nv66le$hdi$1 digitalmars.com>
 <snikzsuexntmeuseqwwi forum.dlang.org>
In-Reply-To: <snikzsuexntmeuseqwwi forum.dlang.org>

--hPfn3Mh3xCdqxfC3ol7xGfts28p7w9WKB
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

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
=20 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 =3D `#{1,}\s*(?P<key>.*):\s*(?P<value>.*)`; auto linePattern =3D ctRegex!(TOC_LINE_PATTERN); } $ dmd-dev -release -O -inline -unittest -main -run sample.d Can you provide more details? --hPfn3Mh3xCdqxfC3ol7xGfts28p7w9WKB--
Nov 10 2016
parent reply Soulsbane <paul acheronsoft.com> writes:
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<key>.*):\s*(?P<value>.*)`; 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.
Nov 10 2016
parent Soulsbane <paul acheronsoft.com> writes:
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<key>.*):\s*(?P<value>.*)`; 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/ uaaddon/tocparser.d is the correct one.
Nov 10 2016
prev sibling next sibling parent reply Anonymous <anon anon.hu> writes:
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
Nov 07 2016
parent reply Anonymous <anon anon.hu> writes:
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.
Nov 07 2016
parent thedeemon <dlang thedeemon.com> writes:
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.
Nov 07 2016
prev sibling next sibling parent reply Dicebot <public dicebot.lv> writes:
 protected-headers="v1"
From: Dicebot <public dicebot.lv>
Newsgroups: d,i,g,i,t,a,l,m,a,r,s,.,D,.,a,n,n,o,u,n,c,e
Subject: Re: Release D 2.072.0
References: <nv66le$hdi$1 digitalmars.com>
In-Reply-To: <nv66le$hdi$1 digitalmars.com>

--LMopEdtgdwVf4VTLbalksJ3RU63SuGIQR
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

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.


--LMopEdtgdwVf4VTLbalksJ3RU63SuGIQR--
Nov 09 2016
parent Daniel Kozak via Digitalmars-d-announce writes:
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
Nov 09 2016
prev sibling parent reply Basile B. <b2.temp gmx.com> writes:
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.
Nov 12 2016
parent Dicebot <public dicebot.lv> writes:
 protected-headers="v1"
From: Dicebot <public dicebot.lv>
Newsgroups: d,i,g,i,t,a,l,m,a,r,s,.,D,.,a,n,n,o,u,n,c,e
Subject: Re: Release D 2.072.0
References: <nv66le$hdi$1 digitalmars.com>
 <phqwfwfrmqocltalidee forum.dlang.org>
In-Reply-To: <phqwfwfrmqocltalidee forum.dlang.org>

--2socSqTmlC9RH1208oWVjMsjP1gCDjxAw
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

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), com=
es
 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
=20 Sorry another regression: =20 https://issues.dlang.org/show_bug.cgi?id=3D16682 =20 I don't know if it's a real regression, maybe the PR that breaks dfmt i=
s
 legit but at least
 - you (you =3D=3D dlang team as an entity) could start a deprecation pe=
riod.
 - 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. --2socSqTmlC9RH1208oWVjMsjP1gCDjxAw--
Nov 15 2016