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 = 


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

    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 =

     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 =

     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