www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Release D 2.079.0

reply Martin Nowak <code+news.digitalmars dawg.eu> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Glad to announce D 2.079.0.

This release comes with experimental ` nogc` exception throwing
(-dip1008), a lazily initialized GC, better support for minimal
runtimes, and an experimental Windows toolchain based on the lld
linker and MinGW import libraries. See the changelog for more details.

Thanks to everyone involved in this 👏
https://dlang.org/changelog/2.079.0.html#contributors.

http://dlang.org/download.html
http://dlang.org/changelog/2.079.0.html

- -Martin
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEpzRNrTw0HqEtE8TmsnOBFhK7GTkFAlqZ/1wACgkQsnOBFhK7
GTkF4hAAqIT7eDN5TpG3WwVQEWNtv1Z2P3/2j75TOq5UA+R93y0mzyrCvaGPhmnc
81DakDAsvf73Ed+Yr3xcVEuL6Uy9M3vCMOXT+maeOz7Ux+wQItUBvVs2CmMom9TU
7somFnXZ9+4rIlNePh2bIshleWaBmfbwxCla1FheY+geoQvsKuky9qOv3GJEK9dJ
RDM3Hc70m+88aKDxZ/4HtA0mctR49nwJxDg6OKS4A2V6QxiDN0e0TWxRoH/xCCZG
mnhvrYG2nhSEDVVehqJePm7p6dhsfBOv+8FtiaboRB72OB2D4Jl4PVJV61neihfj
uxJWY6gIGn2JIiav0wr0SsXy1bM58GvJ71e7YLdYjez5+IQ57ydaVMATRGoPgWi2
nvgkn+/izcHUiXm6srcJvkXMLcmUn3tpFyhZv/YC681Sulfe5UfxTDVPWFQn7AM6
etm7XbF74EpelWo0UUX/2pppxNpjkKcxjnmli8pR0eKL4LOTtZ3CJOnsiw/jUoyo
7XekHL1cFBD8r6txHEwkpVdokEeNNxvZoB0dZ07mJGGgr5fwWVA++W3Xkho1hAcm
+AgAAkmM7E2ZkH2vrz4jgO6N57L/LXoz8UsV8p2xqVKz2iWKi1C+UjKXFn/0wx9J
FqT3zQ791PeaEbBX+AgqTw4BQMjvbsxlENkZc8uKwJvLIdJRSuQ=
=4XFa
-----END PGP SIGNATURE-----
Mar 02
next sibling parent psychoticRabbit <meagain meagain.com> writes:
On Saturday, 3 March 2018 at 01:50:25 UTC, Martin Nowak wrote:
 Glad to announce D 2.079.0.

 This release comes with experimental ` nogc` exception throwing 
 (-dip1008), a lazily initialized GC, better support for minimal 
 runtimes, and an experimental Windows toolchain based on the 
 lld linker and MinGW import libraries. See the changelog for 
 more details.

 Thanks to everyone involved in this 👏 
 https://dlang.org/changelog/2.079.0.html#contributors.

 http://dlang.org/download.html 
 http://dlang.org/changelog/2.079.0.html

 - -Martin
Well done to all! (especially the work on the toolchain) I'm going to download it and test that import syntax thingo...just to make sure it really is gone ;-)
Mar 02
prev sibling next sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Saturday, 3 March 2018 at 01:50:25 UTC, Martin Nowak wrote:
 Glad to announce D 2.079.0.
I've got a blog post coming on this in a few hours, so I would ask anyone considering sharing this on /r/programming before then to please refrain :-)
Mar 02
parent reply Mike Parker <aldacron gmail.com> writes:
On Saturday, 3 March 2018 at 02:35:21 UTC, Mike Parker wrote:

 I've got a blog post coming on this in a few hours, so I would 
 ask anyone considering sharing this on /r/programming before 
 then to please refrain :-)
And it's live: The blog: https://dlang.org/blog/2018/03/03/dmd-2-079-0-released/ Reddit: https://www.reddit.com/r/programming/comments/81pqwb/dmdthe_d_reference_compiler20790_released/
Mar 03
parent reply Martin Nowak <code+news.digitalmars dawg.eu> writes:
On 03/03/2018 01:05 PM, Mike Parker wrote:
 The blog:
 https://dlang.org/blog/2018/03/03/dmd-2-079-0-released/
Could you please add a big visible "experimental" to the lld-link toolchain. It still has a lot of bugs and isn't ready for primetime.
Mar 03
parent Mike Parker <aldacron gmail.com> writes:
On Saturday, 3 March 2018 at 13:22:07 UTC, Martin Nowak wrote:
 On 03/03/2018 01:05 PM, Mike Parker wrote:
 The blog: 
 https://dlang.org/blog/2018/03/03/dmd-2-079-0-released/
Could you please add a big visible "experimental" to the lld-link toolchain. It still has a lot of bugs and isn't ready for primetime.
Done. Thanks! Maybe you or someone else could answer this reddit comment: https://www.reddit.com/r/programming/comments/81pqwb/dmdthe_d_reference_compiler20790_released/dv4ae2t/ I don't know what the plans are going forward.
Mar 03
prev sibling next sibling parent Mengu <mengukagan gmail.com> writes:
On Saturday, 3 March 2018 at 01:50:25 UTC, Martin Nowak wrote:
 Glad to announce D 2.079.0.

 This release comes with experimental ` nogc` exception throwing 
 (-dip1008), a lazily initialized GC, better support for minimal 
 runtimes, and an experimental Windows toolchain based on the 
 lld linker and MinGW import libraries. See the changelog for 
 more details.

 Thanks to everyone involved in this 👏 
 https://dlang.org/changelog/2.079.0.html#contributors.

 http://dlang.org/download.html 
 http://dlang.org/changelog/2.079.0.html

 - -Martin
looks like huge work was done on this release. thank you all.
Mar 03
prev sibling next sibling parent reply Atila Neves <atila.neves gmail.com> writes:
On Saturday, 3 March 2018 at 01:50:25 UTC, Martin Nowak wrote:
 Glad to announce D 2.079.0.

 This release comes with experimental ` nogc` exception throwing 
 (-dip1008), a lazily initialized GC, better support for minimal 
 runtimes, and an experimental Windows toolchain based on the 
 lld linker and MinGW import libraries. See the changelog for 
 more details.

 Thanks to everyone involved in this 👏 
 https://dlang.org/changelog/2.079.0.html#contributors.

 http://dlang.org/download.html 
 http://dlang.org/changelog/2.079.0.html

 - -Martin
Is is just me or did this release just break the latest non-beta vibe.d? Is the Jenkins build testing the dub packages on master instead of the latest tag? Atila
Mar 05
next sibling parent reply Seb <seb wilzba.ch> writes:
On Monday, 5 March 2018 at 15:16:14 UTC, Atila Neves wrote:
 On Saturday, 3 March 2018 at 01:50:25 UTC, Martin Nowak wrote:
 Glad to announce D 2.079.0.

 This release comes with experimental ` nogc` exception 
 throwing (-dip1008), a lazily initialized GC, better support 
 for minimal runtimes, and an experimental Windows toolchain 
 based on the lld linker and MinGW import libraries. See the 
 changelog for more details.

 Thanks to everyone involved in this 👏 
 https://dlang.org/changelog/2.079.0.html#contributors.

 http://dlang.org/download.html 
 http://dlang.org/changelog/2.079.0.html

 - -Martin
Is is just me or did this release just break the latest non-beta vibe.d? Is the Jenkins build testing the dub packages on master instead of the latest tag? Atila
https://github.com/vibe-d/vibe.d/issues/2058
Mar 05
parent reply Atila Neves <atila.neves gmail.com> writes:
On Monday, 5 March 2018 at 17:47:13 UTC, Seb wrote:
 On Monday, 5 March 2018 at 15:16:14 UTC, Atila Neves wrote:
 On Saturday, 3 March 2018 at 01:50:25 UTC, Martin Nowak wrote:
 Glad to announce D 2.079.0.

 This release comes with experimental ` nogc` exception 
 throwing (-dip1008), a lazily initialized GC, better support 
 for minimal runtimes, and an experimental Windows toolchain 
 based on the lld linker and MinGW import libraries. See the 
 changelog for more details.

 Thanks to everyone involved in this 👏 
 https://dlang.org/changelog/2.079.0.html#contributors.

 http://dlang.org/download.html 
 http://dlang.org/changelog/2.079.0.html

 - -Martin
Is is just me or did this release just break the latest non-beta vibe.d? Is the Jenkins build testing the dub packages on master instead of the latest tag? Atila
https://github.com/vibe-d/vibe.d/issues/2058
It's great that there's an issue for vibe. This doesn't change the fact that right now, somebody trying D for the 1st time with the latest official compiler will get an error if they try out the most popular dub package that I know of if they follow the instructions on code.dlang.org. It also doesn't change that I can't upgrade dmd on our CI at work because it can't compile vibe unless I change dozens of dub.sdl files to use a beta version. This breaks semver! I found out about this after removing a dependency on stdx.data.json since dmd >= 2.078.0 broke it (by breaking taggedalgebraic. Yes, I filed a bug.). I can upgrade from 2.077.1 to 2.078.3,but not 2.079.0. I'd have a snowball's chance in hell convincing anyone at a "regular" company of adopting D if anyone there even imagined any of the above could happen. We have to do better than this. Atila
Mar 05
next sibling parent reply psychoticRabbit <meagain meagain.com> writes:
On Monday, 5 March 2018 at 23:40:35 UTC, Atila Neves wrote:
 I'd have a snowball's chance in hell convincing anyone at a 
 "regular" company of adopting D if anyone there even imagined 
 any of the above could happen.

 We have to do better than this.

 Atila
Fair enough. Doing better is always a good thing to aim for. But really, who use something 'just released' in production? As far as I'm concerned, every release is a beta... even if the beta tag is removed. The real problem is something you mentioned .. new comers downloading the latest release..which as I mentioned, is really a beta. But that's just the way software developement works these days - sadly - ship quickly, and ship often. As a result, we're all just testers for the latest release.
Mar 05
parent Atila Neves <atila.neves gmail.com> writes:
On Tuesday, 6 March 2018 at 00:08:33 UTC, psychoticRabbit wrote:
 On Monday, 5 March 2018 at 23:40:35 UTC, Atila Neves wrote:
 I'd have a snowball's chance in hell convincing anyone at a 
 "regular" company of adopting D if anyone there even imagined 
 any of the above could happen.

 We have to do better than this.

 Atila
Fair enough. Doing better is always a good thing to aim for. But really, who use something 'just released' in production?
This is beside the point. Anyone who hears about vibe.d and goes to download the compiler to try it out will fail to get it to compile with the official instructions on how to do so. It's hard enough to convince people to adopt a new programming language when everything works as intended. Atila
Mar 06
prev sibling next sibling parent reply =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig+d outerproduct.org> writes:
Am 06.03.2018 um 00:40 schrieb Atila Neves:
 (...)
 
 This doesn't change the fact that right now, somebody trying D for the 
 1st time with the latest official compiler will get an error if they try 
 out the most popular dub package that I know of if they follow the 
 instructions on code.dlang.org.
 
 It also doesn't change that I can't upgrade dmd on our CI at work 
 because it can't compile vibe unless I change dozens of dub.sdl files to 
 use a beta version. This breaks semver!
 
 I found out about this after removing a dependency on stdx.data.json 
 since dmd >= 2.078.0 broke it (by breaking taggedalgebraic. Yes, I filed 
 a bug.). I can upgrade from 2.077.1 to 2.078.3,but not 2.079.0.
 
 I'd have a snowball's chance in hell convincing anyone at a "regular" 
 company of adopting D if anyone there even imagined any of the above 
 could happen.
 
 We have to do better than this.
 
 Atila
 
I tagged a RC today: https://forum.rejectedsoftware.com/groups/rejectedsoftware.vibed/thread/49899/ To avoid letting this sit broken I'll shorten the final testing phase, so that the release happens this Thursday. This is a bit unfortunate, because this release is a bit more disruptive than normal due to the switch to using vibe-core by default. So early testing with "dub upgrade --prerelease" in different projects is particularly valuable this time! BTW, the problems with this release are a strong hint that we should rethink the inclusion approach with std.experimental. Since breaking changes are tied to the DMD version, it makes those modules almost unusable outside of toy code. Having them as a DUB package (or in essence, in a separate repository) on the other hand nicely decouples them from the compiler release and makes it possible to properly version them individually.
Mar 05
parent jmh530 <john.michael.hall gmail.com> writes:
On Tuesday, 6 March 2018 at 00:10:52 UTC, Sönke Ludwig wrote:
 BTW, the problems with this release are a strong hint that we 
 should rethink the inclusion approach with std.experimental. 
 Since breaking changes are tied to the DMD version, it makes 
 those modules almost unusable outside of toy code. Having them 
 as a DUB package (or in essence, in a separate repository) on 
 the other hand nicely decouples them from the compiler release 
 and makes it possible to properly version them individually.
Additional evidence: std.experimental.ndslice -> libmir.
Mar 05
prev sibling next sibling parent reply Adam Wilson <flyboynw gmail.com> writes:
On 3/5/18 15:40, Atila Neves wrote:
 On Monday, 5 March 2018 at 17:47:13 UTC, Seb wrote:
 On Monday, 5 March 2018 at 15:16:14 UTC, Atila Neves wrote:
 On Saturday, 3 March 2018 at 01:50:25 UTC, Martin Nowak wrote:
 Glad to announce D 2.079.0.

 This release comes with experimental ` nogc` exception throwing
 (-dip1008), a lazily initialized GC, better support for minimal
 runtimes, and an experimental Windows toolchain based on the lld
 linker and MinGW import libraries. See the changelog for more details.

 Thanks to everyone involved in this 👏
 https://dlang.org/changelog/2.079.0.html#contributors.

 http://dlang.org/download.html http://dlang.org/changelog/2.079.0.html

 - -Martin
Is is just me or did this release just break the latest non-beta vibe.d? Is the Jenkins build testing the dub packages on master instead of the latest tag? Atila
https://github.com/vibe-d/vibe.d/issues/2058
It's great that there's an issue for vibe. This doesn't change the fact that right now, somebody trying D for the 1st time with the latest official compiler will get an error if they try out the most popular dub package that I know of if they follow the instructions on code.dlang.org. It also doesn't change that I can't upgrade dmd on our CI at work because it can't compile vibe unless I change dozens of dub.sdl files to use a beta version. This breaks semver! I found out about this after removing a dependency on stdx.data.json since dmd >= 2.078.0 broke it (by breaking taggedalgebraic. Yes, I filed a bug.). I can upgrade from 2.077.1 to 2.078.3,but not 2.079.0. I'd have a snowball's chance in hell convincing anyone at a "regular" company of adopting D if anyone there even imagined any of the above could happen. We have to do better than this. Atila
May I make a recommendation? Only upgrade to the 2.0xx.2[.3] releases. You'll have to wait a month or so for the latest features, but by then the important packages will have been upgraded and the regressions (mostly) worked out. It's kind of like the old saying about Microsoft software. "Never use the first version of anything". If we treat the .0 releases as "v1" then it fits. :) -- Adam Wilson IRC: LightBender import quiet.dlang.dev;
Mar 05
parent reply Atila Neves <atila.neves gmail.com> writes:
On Tuesday, 6 March 2018 at 06:53:30 UTC, Adam Wilson wrote:
 On 3/5/18 15:40, Atila Neves wrote:
 On Monday, 5 March 2018 at 17:47:13 UTC, Seb wrote:
 On Monday, 5 March 2018 at 15:16:14 UTC, Atila Neves wrote:
 On Saturday, 3 March 2018 at 01:50:25 UTC, Martin Nowak 
 wrote:
 [...]
Is is just me or did this release just break the latest non-beta vibe.d? Is the Jenkins build testing the dub packages on master instead of the latest tag? Atila
https://github.com/vibe-d/vibe.d/issues/2058
It's great that there's an issue for vibe. This doesn't change the fact that right now, somebody trying D for the 1st time with the latest official compiler will get an error if they try out the most popular dub package that I know of if they follow the instructions on code.dlang.org. It also doesn't change that I can't upgrade dmd on our CI at work because it can't compile vibe unless I change dozens of dub.sdl files to use a beta version. This breaks semver! I found out about this after removing a dependency on stdx.data.json since dmd >= 2.078.0 broke it (by breaking taggedalgebraic. Yes, I filed a bug.). I can upgrade from 2.077.1 to 2.078.3,but not 2.079.0. I'd have a snowball's chance in hell convincing anyone at a "regular" company of adopting D if anyone there even imagined any of the above could happen. We have to do better than this. Atila
May I make a recommendation? Only upgrade to the 2.0xx.2[.3] releases. You'll have to wait a month or so for the latest features, but by then the important packages will have been upgraded and the regressions (mostly) worked out. It's kind of like the old saying about Microsoft software. "Never use the first version of anything". If we treat the .0 releases as "v1" then it fits. :)
The problem with that is I was waiting for 2.079.0 since it fixes a bug that prevented me from upgrading to any of the 2.078.x releases on Windows. And then there's the fact that the last time I had issues upgrading gcc or clang was... never. I'm more than ok with compiler upgrades breaking my code when it was wrong in the 1st place, or with language updates breaking code but making the situation better as a whole. That's not what's been happening to me with the last few versions. Atila
Mar 06
parent Martin Nowak <code dawg.eu> writes:
On Tuesday, 6 March 2018 at 11:10:49 UTC, Atila Neves wrote:
 The problem with that is I was waiting for 2.079.0 since it 
 fixes a bug that prevented me from upgrading to any of the 
 2.078.x releases on Windows.
I think 2.078 would make an excellent starting point for a LTS because of the important fixes that only made it to 2.079. If anyone is interested to backport fixes and maintain such a source-branch, please contact me.
Mar 06
prev sibling next sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 3/5/18 6:40 PM, Atila Neves wrote:
 On Monday, 5 March 2018 at 17:47:13 UTC, Seb wrote:
 On Monday, 5 March 2018 at 15:16:14 UTC, Atila Neves wrote:
 On Saturday, 3 March 2018 at 01:50:25 UTC, Martin Nowak wrote:
 Glad to announce D 2.079.0.

 This release comes with experimental ` nogc` exception throwing 
 (-dip1008), a lazily initialized GC, better support for minimal 
 runtimes, and an experimental Windows toolchain based on the lld 
 linker and MinGW import libraries. See the changelog for more details.

 Thanks to everyone involved in this 👏 
 https://dlang.org/changelog/2.079.0.html#contributors.

 http://dlang.org/download.html http://dlang.org/changelog/2.079.0.html

 - -Martin
Is is just me or did this release just break the latest non-beta vibe.d? Is the Jenkins build testing the dub packages on master instead of the latest tag? Atila
https://github.com/vibe-d/vibe.d/issues/2058
It's great that there's an issue for vibe. This doesn't change the fact that right now, somebody trying D for the 1st time with the latest official compiler will get an error if they try out the most popular dub package that I know of if they follow the instructions on code.dlang.org. It also doesn't change that I can't upgrade dmd on our CI at work because it can't compile vibe unless I change dozens of dub.sdl files to use a beta version. This breaks semver! I found out about this after removing a dependency on stdx.data.json since dmd >= 2.078.0 broke it (by breaking taggedalgebraic. Yes, I filed a bug.). I can upgrade from 2.077.1 to 2.078.3,but not 2.079.0. I'd have a snowball's chance in hell convincing anyone at a "regular" company of adopting D if anyone there even imagined any of the above could happen. We have to do better than this.
std.experimental is supposed to be allowed to be broken. That being said, I'm wondering if it wouldn't be better to have std.experimental be in its own repository. This allows selection of the dependency on std.experimental separate from phobos. It still would be an "official" dlang package, and might even be included in the distribution (the latest version anyway), and docs included on the website. But if needed, you could have your dub package depend on a prior version. -Steve
Mar 06
next sibling parent reply Martin Nowak <code dawg.eu> writes:
On Tuesday, 6 March 2018 at 12:21:41 UTC, Steven Schveighoffer 
wrote:
 That being said, I'm wondering if it wouldn't be better to have 
 std.experimental be in its own repository.
Just showing that phobos is not the right place to develop modules/packages, also mir. IMO std.experimental provides little benefit over dub, but comes with many downsides.
 This allows selection of the dependency on std.experimental 
 separate from phobos.
You cannot link against diamond dependencies of different versions though, so we'd have to exclude it from libphobos and put it separately.
 It still would be an "official" dlang package, and might even 
 be included in the distribution (the latest version anyway), 
 and docs included on the website.
Not sure why inclusion in distribution is often mentioned as such a thing. It's trivial and common to have separate libraries/dependencies in every language with a healthy ecosystem.
 But if needed, you could have your dub package depend on a 
 prior version.
http://code.dlang.org/packages/stdx-allocator ;)
Mar 06
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 3/6/18 2:30 PM, Martin Nowak wrote:
 On Tuesday, 6 March 2018 at 12:21:41 UTC, Steven Schveighoffer wrote:
 But if needed, you could have your dub package depend on a prior version.
http://code.dlang.org/packages/stdx-allocator ;)
This is the answer, vibe.d should depend on stdx-allocator. -Steve
Mar 06
parent reply Seb <seb wilzba.ch> writes:
On Tuesday, 6 March 2018 at 19:57:13 UTC, Steven Schveighoffer 
wrote:
 On 3/6/18 2:30 PM, Martin Nowak wrote:
 On Tuesday, 6 March 2018 at 12:21:41 UTC, Steven Schveighoffer 
 wrote:
 But if needed, you could have your dub package depend on a 
 prior version.
http://code.dlang.org/packages/stdx-allocator ;)
This is the answer, vibe.d should depend on stdx-allocator. -Steve
Vibe.d (and a lot of other projects) do depend on this package, see e.g. https://github.com/vibe-d/vibe.d/pull/1983 Also many packages already depend on vibe.d-0.8.3, but it's in rc1 atm and not released as the latest stable tag yet, which is the reason for Atila's justified complaint.
Mar 06
next sibling parent reply Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Wednesday, 7 March 2018 at 04:02:18 UTC, Seb wrote:
 On Tuesday, 6 March 2018 at 19:57:13 UTC, Steven Schveighoffer 
 wrote:
 On 3/6/18 2:30 PM, Martin Nowak wrote:
 On Tuesday, 6 March 2018 at 12:21:41 UTC, Steven 
 Schveighoffer wrote:
 But if needed, you could have your dub package depend on a 
 prior version.
http://code.dlang.org/packages/stdx-allocator ;)
This is the answer, vibe.d should depend on stdx-allocator. -Steve
Vibe.d (and a lot of other projects) do depend on this package, see e.g. https://github.com/vibe-d/vibe.d/pull/1983 Also many packages already depend on vibe.d-0.8.3, but it's in rc1 atm and not released as the latest stable tag yet, which is the reason for Atila's justified complaint.
The point is just to persuade Sonke to do his development in the minor version and increase it during every vibe-d release, and keep the patch version for fast fixes of the latest released vibe-d when a new version of the compiler is being released. The actual policy is just an ask for problems... It's not a big deal to fix the breakage on the latest released vibe-d code, it's a fast process. But it's a problem in just coordinating the next release of vibe-d with the release of the compiler, if you need to do this, like in this case. /Paolo
Mar 07
parent reply =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig+d outerproduct.org> writes:
Am 07.03.2018 um 10:17 schrieb Paolo Invernizzi:
 On Wednesday, 7 March 2018 at 04:02:18 UTC, Seb wrote:
 On Tuesday, 6 March 2018 at 19:57:13 UTC, Steven Schveighoffer wrote:
 On 3/6/18 2:30 PM, Martin Nowak wrote:
 On Tuesday, 6 March 2018 at 12:21:41 UTC, Steven Schveighoffer wrote:
 But if needed, you could have your dub package depend on a prior 
 version.
http://code.dlang.org/packages/stdx-allocator ;)
This is the answer, vibe.d should depend on stdx-allocator. -Steve
Vibe.d (and a lot of other projects) do depend on this package, see e.g. https://github.com/vibe-d/vibe.d/pull/1983 Also many packages already depend on vibe.d-0.8.3, but it's in rc1 atm and not released as the latest stable tag yet, which is the reason for Atila's justified complaint.
The point is just to persuade Sonke to do his development in the minor version and increase it during every vibe-d release, and keep the patch version for fast fixes of the latest released vibe-d when a new version of the compiler is being released. The actual policy is just an ask for problems... It's not a big deal to fix the breakage on the latest released vibe-d code, it's a fast process. But it's a problem in just coordinating the next release of vibe-d with the release of the compiler, if you need to do this, like in this case. /Paolo
Well, for all of the recent releases we made sure that there was no breakage for new compiler versions. This release was an exception, because I didn't manage to put out the fixed release in time. The plan is to have all future releases go back to the normal mode where the new compiler version always works. Since std.experimental isn't involved from now on, it shouldn't even be necessary anymore to put out new vibe.d releases for new DMD versions, because DMD/Phobos already checks for regressions against vibe.d and all breaking changes should simply result in a deprecation warning. As for the versioning scheme, currently almost all new releases have some small breaking change or deprecation. If I'd use the "minor" version for that, then there would be no way to signal that a release makes broad and more disruptive changes, such as the 0.8.0 release. But all of this will change, as the remaining parts get pushed to separate repositories one-by-one, with their own version starting at 1.0.0.
Mar 07
parent reply Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Wednesday, 7 March 2018 at 10:13:29 UTC, Sönke Ludwig wrote:

 Well, for all of the recent releases we made sure that there 
 was no breakage for new compiler versions. This release was an 
 exception, because I didn't manage to put out the fixed release 
 in time. The plan is to have all future releases go back to the 
 normal mode where the new compiler version always works.

 Since std.experimental isn't involved from now on, it shouldn't 
 even be necessary anymore to put out new vibe.d releases for 
 new DMD versions, because DMD/Phobos already checks for 
 regressions against vibe.d and all breaking changes should 
 simply result in a deprecation warning.
That's fine, thanks.
 As for the versioning scheme, currently almost all new releases 
 have some small breaking change or deprecation. If I'd use the 
 "minor" version for that, then there would be no way to signal 
 that a release makes broad and more disruptive changes, such as 
 the 0.8.0 release. But all of this will change, as the 
 remaining parts get pushed to separate repositories one-by-one, 
 with their own version starting at 1.0.0.
I understand your reasoning, but there's value in being able to just rapidly fix something with a new release, or just port some master bug-fixes into a released version branch. DMD is experiencing a very enjoyable release process of patch versions, thanks to Martin and the team. It your concern is only related to the best way to inform the users about a broad and disruptive change in vibe-d, I suggest to simply use the usual channels for that, change logs and announce forum. My impression is that there's a lot of value in using patch for patch, instead of using patch for development, also in a zero major, so I maybe you should consider that change, or at least, investigate a little about that opportunity. /Paolo
Mar 07
parent reply =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig+d outerproduct.org> writes:
Am 07.03.2018 um 13:57 schrieb Paolo Invernizzi:
 On Wednesday, 7 March 2018 at 10:13:29 UTC, Sönke Ludwig wrote:
 
 Well, for all of the recent releases we made sure that there was no 
 breakage for new compiler versions. This release was an exception, 
 because I didn't manage to put out the fixed release in time. The plan 
 is to have all future releases go back to the normal mode where the 
 new compiler version always works.

 Since std.experimental isn't involved from now on, it shouldn't even 
 be necessary anymore to put out new vibe.d releases for new DMD 
 versions, because DMD/Phobos already checks for regressions against 
 vibe.d and all breaking changes should simply result in a deprecation 
 warning.
That's fine, thanks.
 As for the versioning scheme, currently almost all new releases have 
 some small breaking change or deprecation. If I'd use the "minor" 
 version for that, then there would be no way to signal that a release 
 makes broad and more disruptive changes, such as the 0.8.0 release. 
 But all of this will change, as the remaining parts get pushed to 
 separate repositories one-by-one, with their own version starting at 
 1.0.0.
I understand your reasoning, but there's value in being able to just rapidly fix something with a new release, or just port some master bug-fixes into a released version branch. DMD is experiencing a very enjoyable release process of patch versions, thanks to Martin and the team. It your concern is only related to the best way to inform the users about a broad and disruptive change in vibe-d, I suggest to simply use the usual channels for that, change logs and announce forum. My impression is that there's a lot of value in using patch for patch, instead of using patch for development, also in a zero major, so I maybe you should consider that change, or at least, investigate a little about that opportunity. /Paolo
But why wouldn't it be possible to make a quick bugfix release with the current scheme? It has happened in the past. Granted, if a 0.8.5-beta.1 is already tagged, then using 0.8.5 for a quick intermediate release would be bad, but at that point the beta could likely also be turned into a full release pretty quickly. But the point is that the development mode is currently still happening in a linear fashion. Starting to have (a) stable branch(es) with additional point releases would increase the overhead to a point where there wouldn't be any meaningful progress anymore, at least at this time. Then there is the fact that 0.8.0 was developed in a parallel branch for quite a while. If the minor version would have been used to denote regular small updates, it would not have been possible to tag alpha/beta releases on the 0.8.x branch at all.
Mar 07
parent reply Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Wednesday, 7 March 2018 at 14:53:09 UTC, Sönke Ludwig wrote:

 But why wouldn't it be possible to make a quick bugfix release 
 with the current scheme? It has happened in the past. Granted, 
 if a 0.8.5-beta.1 is already tagged, then using 0.8.5 for a 
 quick intermediate release would be bad, but at that point the 
 beta could likely also be turned into a full release pretty 
 quickly.
Well, I don't know why, but quick is more than 30 days right now using the current release procedure... https://github.com/vibe-d/vibe.d/issues/2058 https://github.com/vibe-d/vibe.d/releases Anyway, never mind! /Paolo
Mar 07
parent =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig+d outerproduct.org> writes:
Am 07.03.2018 um 17:01 schrieb Paolo Invernizzi:
 On Wednesday, 7 March 2018 at 14:53:09 UTC, Sönke Ludwig wrote:
 
 But why wouldn't it be possible to make a quick bugfix release with 
 the current scheme? It has happened in the past. Granted, if a 
 0.8.5-beta.1 is already tagged, then using 0.8.5 for a quick 
 intermediate release would be bad, but at that point the beta could 
 likely also be turned into a full release pretty quickly.
Well, I don't know why, but quick is more than 30 days right now using the current release procedure... https://github.com/vibe-d/vibe.d/issues/2058 https://github.com/vibe-d/vibe.d/releases Anyway, never mind! /Paolo
What I mean are releases like these: https://vibed.org/blog/posts/vibe-release-0.7.11 (3 days) https://vibed.org/blog/posts/vibe-release-0.7.28 (16 days) There are also releases such as 0.7.29 that actually got branched out and was stabilized while 0.7.30 was already pushed further along on master. But such releases were only done if really necessary, because a release, despite many things being automated, always has quite some overhead, just like maintaining parallel branches has. Depending on the work force and the general development speed that may be okay, but currently development time unfortunately is a premium.
Mar 07
prev sibling parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 3/6/18 11:02 PM, Seb wrote:
 On Tuesday, 6 March 2018 at 19:57:13 UTC, Steven Schveighoffer wrote:
 On 3/6/18 2:30 PM, Martin Nowak wrote:
 On Tuesday, 6 March 2018 at 12:21:41 UTC, Steven Schveighoffer wrote:
 But if needed, you could have your dub package depend on a prior 
 version.
http://code.dlang.org/packages/stdx-allocator ;)
This is the answer, vibe.d should depend on stdx-allocator. -Steve
Vibe.d (and a lot of other projects) do depend on this package, see e.g. https://github.com/vibe-d/vibe.d/pull/1983 Also many packages already depend on vibe.d-0.8.3, but it's in rc1 atm and not released as the latest stable tag yet, which is the reason for Atila's justified complaint.
Hm... so basically this was fixed back in December, but just hadn't been released? I think then this seems like an unfortunate, but temporary problem that should be OK for the future. In any case, I think this shows we need to move our proving grounds to an external package. Much better to do it that way than to couple breaking changes on an experimental package with dmd/phobos fixes. -Steve
Mar 07
prev sibling parent reply Jack Stouffer <jack jackstouffer.com> writes:
On Tuesday, 6 March 2018 at 12:21:41 UTC, Steven Schveighoffer 
wrote:
 That being said, I'm wondering if it wouldn't be better to have 
 std.experimental be in its own repository. This allows 
 selection of the dependency on std.experimental separate from 
 phobos. It still would be an "official" dlang package, and 
 might even be included in the distribution (the latest version 
 anyway), and docs included on the website. But if needed, you 
 could have your dub package depend on a prior version.
The entire concept needs a reexamination IMO. I just checked the git history, and not one module has graduated from std.experimental to mainline Phobos since the idea's inception in 2014. While it's possible that none of the modules are ready, logger has been there for four years now. I was against changing how experimental is handled in the past, but I recently have started to rethink how we promote modules. Also, if you'll allow me to have crazy ideas for a moment, one wonders why we shouldn't just release Phobos itself through dub? Rust makes people use their build tool, why not us?
Mar 06
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Mar 06, 2018 at 08:50:37PM +0000, Jack Stouffer via
Digitalmars-d-announce wrote:
[...]
 Also, if you'll allow me to have crazy ideas for a moment, one wonders
 why we shouldn't just release Phobos itself through dub? Rust makes
 people use their build tool, why not us?
Please don't. I dread the day my daily dmd toolchain update script will have to depend on dub just to be able to build a working compiler. But personal preferences aside, one blocker to this is that dmd and phobos (as well as druntime) development often go in lockstep, and sometimes breaking transitions must be coordinated between them so that git master is always buildable. If dmd and phobos were separate repos, it would make this coordination much, much, more difficult. (Though, on second thoughts, that's not necessarily a bad thing, as it will force us to actually face these issues and make Phobos buildable with multiple compiler versions, which currently is not well supported, if it works at all, because of said interdependence. This would also force us to dogfood our release / deprecation processeses, which will allow us to notice problems early and to experience what end users would experience when transitioning between compiler versions. It *will* add more workload to an already thin Phobos dev team, though. So there's that.) T -- Why are you blatanly misspelling "blatant"? -- Branden Robinson
Mar 06
prev sibling next sibling parent reply psychoticRabbit <meagain meagain.com> writes:
On Tuesday, 6 March 2018 at 20:50:37 UTC, Jack Stouffer wrote:
 Also, if you'll allow me to have crazy ideas for a moment, one 
 wonders why we shouldn't just release Phobos itself through 
 dub? Rust makes people use their build tool, why not us?
That's the day I stop using D. I do not, and will not, use dub. Full stop. Same goes for Rust ;-)
Mar 06
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 07/03/2018 2:54 PM, psychoticRabbit wrote:
 On Tuesday, 6 March 2018 at 20:50:37 UTC, Jack Stouffer wrote:
 Also, if you'll allow me to have crazy ideas for a moment, one wonders 
 why we shouldn't just release Phobos itself through dub? Rust makes 
 people use their build tool, why not us?
That's the day I stop using D. I do not, and will not, use dub. Full stop. Same goes for Rust ;-)
Under such arrangement nobody is forcing you to use dub. We wouldn't break distribution or usage of dmd just because of changing a make file to dub. That's just silly.
Mar 06
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Mar 07, 2018 at 03:58:38PM +1300, rikki cattermole via
Digitalmars-d-announce wrote:
 On 07/03/2018 2:54 PM, psychoticRabbit wrote:
 On Tuesday, 6 March 2018 at 20:50:37 UTC, Jack Stouffer wrote:
 
 Also, if you'll allow me to have crazy ideas for a moment, one
 wonders why we shouldn't just release Phobos itself through dub?
 Rust makes people use their build tool, why not us?
That's the day I stop using D. I do not, and will not, use dub. Full stop. Same goes for Rust ;-)
Under such arrangement nobody is forcing you to use dub. We wouldn't break distribution or usage of dmd just because of changing a make file to dub. That's just silly.
It will force everyone who compiles dmd from source to use dub. It's not the end of the world, but I for one will not be too happy about it. Not to mention, it will introduce bootstrapping issues to Phobos, since dub itself depends on Phobos (again, solvable, but can be a potential source of trouble). T -- Don't get stuck in a closet---wear yourself out.
Mar 07
parent reply Mike Parker <aldacron gmail.com> writes:
On Wednesday, 7 March 2018 at 14:20:54 UTC, H. S. Teoh wrote:

 It will force everyone who compiles dmd from source to use dub. 
 It's not the end of the world, but I for one will not be too 
 happy about it.
IMO, much better than forcing everyone to compile with make, which I'm not too happy about :-)
Mar 07
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Mar 07, 2018 at 02:53:17PM +0000, Mike Parker via
Digitalmars-d-announce wrote:
 On Wednesday, 7 March 2018 at 14:20:54 UTC, H. S. Teoh wrote:
 It will force everyone who compiles dmd from source to use dub. It's
 not the end of the world, but I for one will not be too happy about
 it.
IMO, much better than forcing everyone to compile with make, which I'm not too happy about :-)
parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 3/7/18 12:02 PM, H. S. Teoh wrote:
 On Wed, Mar 07, 2018 at 02:53:17PM +0000, Mike Parker via
Digitalmars-d-announce wrote:
 On Wednesday, 7 March 2018 at 14:20:54 UTC, H. S. Teoh wrote:
 It will force everyone who compiles dmd from source to use dub. It's
 not the end of the world, but I for one will not be too happy about
 it.
IMO, much better than forcing everyone to compile with make, which I'm not too happy about :-)
Touché. :-D The good thing is that make is pretty much guaranteed to exist in all OS installations (except Windows perhaps? But pretty much anywhere a compiler toolchain is installed), whereas dub isn't.
You need a D compiler to build D. So dub is probably there too. Note that I'm against having phobos being a separate dependency from the compiler, but I'm not against switching to dub for the build. -Steve
Mar 07
prev sibling parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 3/6/18 3:50 PM, Jack Stouffer wrote:
 On Tuesday, 6 March 2018 at 12:21:41 UTC, Steven Schveighoffer wrote:
 That being said, I'm wondering if it wouldn't be better to have 
 std.experimental be in its own repository. This allows selection of 
 the dependency on std.experimental separate from phobos. It still 
 would be an "official" dlang package, and might even be included in 
 the distribution (the latest version anyway), and docs included on the 
 website. But if needed, you could have your dub package depend on a 
 prior version.
The entire concept needs a reexamination IMO. I just checked the git history, and not one module has graduated from std.experimental to mainline Phobos since the idea's inception in 2014. While it's possible that none of the modules are ready, logger has been there for four years now. I was against changing how experimental is handled in the past, but I recently have started to rethink how we promote modules.
Promotion of modules is a different discussion. I think std.experimental is fine as a project, but just needs to be decoupled with needed compiler and stable library fixes. To put it in terms of Atila's reference, it's like we coupled the breaking changes of boost-experimental with critical clang fixes.
 Also, if you'll allow me to have crazy ideas for a moment, one wonders 
 why we shouldn't just release Phobos itself through dub? Rust makes 
 people use their build tool, why not us?
No. Phobos has a reasonably stable API, and we need to keep it that way. There are too many coupled changes with Phobos and DMD that I think we would be asking for a mountain of "Why is this version of Phobos not compatible with this version of DMD?" bugs. -Steve
Mar 07
prev sibling parent Random D user <no email.com> writes:
On Monday, 5 March 2018 at 23:40:35 UTC, Atila Neves wrote:
 I'd have a snowball's chance in hell convincing anyone at a 
 "regular" company of adopting D if anyone there even imagined 
 any of the above could happen.

 We have to do better than this.

 Atila
I don't think this is unusual even outside of D. At least Microsoft seems to be willing to break your build if it moves things forward. For example, there are projects that worked fine on MSVC 15.4 (VS2017), but broke if you installed the update to 15.5 (or auto-updated in Visual Studio). You can't test everything. A lot of the "regular" companies, that desire high stability, typically use very old compilers and just workaround the bugs they know. For a D example, I think Sociomantic was using D1 for a long time just because it was stable for them. And if you need stability, why would you update the compiler without local testing and reserving time to fix any issues?
Mar 06
prev sibling parent reply Martin Nowak <code dawg.eu> writes:
On Monday, 5 March 2018 at 15:16:14 UTC, Atila Neves wrote:
 Is is just me or did this release just break the latest 
 non-beta vibe.d? Is the Jenkins build testing the dub packages 
 on master instead of the latest tag?
Also this offer still stands https://forum.dlang.org/post/drcekmxvfszpwifbukzk forum.dlang.org
Mar 08
parent Jacob Carlborg <doob me.com> writes:
On 2018-03-08 19:21, Martin Nowak wrote:

 Also this offer still stands
 https://forum.dlang.org/post/drcekmxvfszpwifbukzk forum.dlang.org
Who will decide if semver can/will be used? -- /Jacob Carlborg
Mar 09
prev sibling next sibling parent reply Chris M. <chrismohrfeld comcast.net> writes:
On Saturday, 3 March 2018 at 01:50:25 UTC, Martin Nowak wrote:
 Glad to announce D 2.079.0.

 This release comes with experimental ` nogc` exception throwing 
 (-dip1008), a lazily initialized GC, better support for minimal 
 runtimes, and an experimental Windows toolchain based on the 
 lld linker and MinGW import libraries. See the changelog for 
 more details.

 Thanks to everyone involved in this 👏 
 https://dlang.org/changelog/2.079.0.html#contributors.

 http://dlang.org/download.html 
 http://dlang.org/changelog/2.079.0.html

 - -Martin
Good stuff. Still bothers me that we had to special case "throw new Exception();" in order to make it nogc. I can't think of any better ways right now, but I wish it was more explicit.
Mar 05
parent Martin Nowak <code dawg.eu> writes:
On Monday, 5 March 2018 at 16:18:11 UTC, Chris M. wrote:
 Good stuff. Still bothers me that we had to special case "throw 
 new Exception();" in order to make it nogc. I can't think of 
 any better ways right now
Implementing EH for values (instead of class references) would have been a lot more complex.
 but I wish it was more explicit.
Initially people always want more explicitness for new, not yet too well known, features, while later opting for terser syntax for commonly used things. Exceptions are supposed to be rare and deleting them directly after being catched seemed like a reasonable enough default to go with the specialization. After all it solves a huge problem, error handling in nogc code. Maybe we'll find a better/cleaner solution when more of the language has been transitioned to safe nogc.
Mar 06
prev sibling parent reply Void-995 <void995 gmail.com> writes:
Can somebody explain how &array[0] is more safe than array.ptr? 
Just want to understand why second statement isn't allowed in 
safe anymore.
Mar 05
next sibling parent reply psychoticRabbit <meagain meagain.com> writes:
On Tuesday, 6 March 2018 at 05:22:58 UTC, Void-995 wrote:
 Can somebody explain how &array[0] is more safe than array.ptr? 
 Just want to understand why second statement isn't allowed in 
 safe anymore.
int[] a; writeln(&arr[0]); // good - runtime produces a core.exception.RangeError //writeln(arr.ptr); // what do you think will happen here?
Mar 05
parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Tuesday, March 06, 2018 05:34:39 psychoticRabbit via Digitalmars-d-
announce wrote:
 On Tuesday, 6 March 2018 at 05:22:58 UTC, Void-995 wrote:
 Can somebody explain how &array[0] is more safe than array.ptr?
 Just want to understand why second statement isn't allowed in
 safe anymore.
int[] a; writeln(&arr[0]); // good - runtime produces a core.exception.RangeError //writeln(arr.ptr); // what do you think will happen here?
That example actually should be perfectly safe, because the array is null, and it's using writeln. Dereferencing null is safe, because it segfaults and thus can't corrupt memory or access invalid memory. You obviously don't want it to happen, but it's safe. Also, passing a pointer to writeln is fine, because it's just going to print the value, so that's safe too, even if the pointer value is garbage. The problem is when the dynamic array's ptr points to something other than null, and its length is 0. a[0] does bounds checking, so &a[0] is only valid if the dynamic array's length is greater than 0, whereas a.ptr would happily give you a value even if the array's length is 0, and in that case, it's not valid to dereference that pointer. And depending on what that pointer points to, it could corrupt memory or access invalid memory if you dereference it. So, in _most_ cases, using ptr is actually fine, but because it's not _always_ safe, the compiler has to treat it as system. It was previously thought to be fine, because the case where a dynamic array is empty but non-null had not been considered when deciding whether ptr could be used in safe code. - Jonathan m Davis
Mar 05
next sibling parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 3/6/18 2:11 AM, Jonathan M Davis wrote:
 On Tuesday, March 06, 2018 05:34:39 psychoticRabbit via Digitalmars-d-
 announce wrote:
 On Tuesday, 6 March 2018 at 05:22:58 UTC, Void-995 wrote:
 Can somebody explain how &array[0] is more safe than array.ptr?
 Just want to understand why second statement isn't allowed in
 safe anymore.
int[] a; writeln(&arr[0]); // good - runtime produces a core.exception.RangeError //writeln(arr.ptr); // what do you think will happen here?
That example actually should be perfectly safe, because the array is null, and it's using writeln. Dereferencing null is safe, because it segfaults and thus can't corrupt memory or access invalid memory. You obviously don't want it to happen, but it's safe. Also, passing a pointer to writeln is fine, because it's just going to print the value, so that's safe too, even if the pointer value is garbage.
Yeah, a better example: struct S { size_t[1] x; int *bad; } void foo() safe { S s; auto arr = s.x[$ .. $]; // int *p = &arr[0]; // would throw range error auto p = arr.ptr; // this now points at bad *p = 0xdeadbeef; *s.bad = 5; // oops } -Steve
Mar 06
prev sibling parent reply psychoticRabbit <meagain meagain.com> writes:
On Tuesday, 6 March 2018 at 07:11:24 UTC, Jonathan M Davis wrote:
 That example actually should be perfectly  safe, because the 
 array is null, and it's using writeln. Dereferencing null is 
  safe, because it segfaults and thus can't corrupt memory or 
 access invalid memory. You obviously don't want it to happen, 
 but it's  safe. Also, passing a pointer to writeln is fine, 
 because it's just going to print the value, so that's  safe 
 too, even if the pointer value is garbage.
my point had nothing to do with writeln. my point was, that a RangeError exception may help save the day, but not when you use .ptr thankfully Steven gave a much better example to make the point clearer ;-) (I assume that int is meant to be size_t)
Mar 06
parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 3/6/18 11:13 AM, psychoticRabbit wrote:

 (I assume that int is meant to be size_t)
Yes, I changed the uncommented one to auto after I realized, but not the commented one ;) -Steve
Mar 06
prev sibling parent Martin Nowak <code dawg.eu> writes:
On Tuesday, 6 March 2018 at 05:22:58 UTC, Void-995 wrote:
 Can somebody explain how &array[0] is more safe than array.ptr? 
 Just want to understand why second statement isn't allowed in 
 safe anymore.
&array[0] is runtime bounds-checked array.ptr is unchecked and might return an out-of-bounds pointer (to the first element)
Mar 06