Re: Release D 2.079.0
On 2018-03-08 19:21, Martin Nowak wrote: Also this offer still stands https://forum.dlang.org/post/drcekmxvfszpwifbu...@forum.dlang.org Who will decide if semver can/will be used? -- /Jacob Carlborg
Re: Release D 2.079.0
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/drcekmxvfszpwifbu...@forum.dlang.org
Re: Release D 2.079.0
On 3/7/18 12:02 PM, H. S. Teoh wrote: On Wed, Mar 07, 2018 at 02:53:17PM +, 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
Re: Release D 2.079.0
On Wed, Mar 07, 2018 at 02:53:17PM +, 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. Seriously, I would be much happier with a D build tool. Dub is not a bad package manager, though it could be better, but IMO it does a poor job at being a general build system. If it were only made more configurable and less insistent about everything being required to be done its way or the highway, having Phobos distributed as a dub package wouldn't be so bad. But who knows. Maybe being forced to use dub to build Phobos would finally provide the motivation for people to improve dub as a build tool. But AIUI there are some fundamental design assumptions built into dub that basically makes it impossible to fix some of these issues without pretty much rewriting it from ground up. Because of this, I have not found myself particularly inclined to actually look at its code. T -- What is Matter, what is Mind? Never Mind, it doesn't Matter.
Re: Release D 2.079.0
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.
Re: Release D 2.079.0
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
Re: Release D 2.079.0
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 :-)
Re: Release D 2.079.0
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.
Re: Release D 2.079.0
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.
Re: Release D 2.079.0
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
Re: Release D 2.079.0
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
Re: Release D 2.079.0
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
Re: Release D 2.079.0
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.
Re: Release D 2.079.0
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
Re: Release D 2.079.0
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.
Re: Release D 2.079.0
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.
Re: Release D 2.079.0
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 ;-)
Re: Release D 2.079.0
On Tue, Mar 06, 2018 at 08:50:37PM +, 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
Re: Release D 2.079.0
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?
Re: Release D 2.079.0
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?
Re: Release D 2.079.0
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
Re: Release D 2.079.0
On Tuesday, 6 March 2018 at 05:22:58 UTC, Void-995 wrote: Can somebody explain how [0] is more safe than array.ptr? Just want to understand why second statement isn't allowed in safe anymore. [0] is runtime bounds-checked array.ptr is unchecked and might return an out-of-bounds pointer (to the first element)
Re: Release D 2.079.0
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.
Re: Release D 2.079.0
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.
Re: Release D 2.079.0
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 ;)
Re: Release D 2.079.0
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
Re: Release D 2.079.0
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)
Re: Release D 2.079.0
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 [0] is more safe than array.ptr?
Just want to understand why second statement isn't allowed in
safe anymore.
int[] a;
writeln([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 = [0]; // would throw range error
auto p = arr.ptr; // this now points at bad
*p = 0xdeadbeef;
*s.bad = 5; // oops
}
-Steve
Re: Release D 2.079.0
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
Re: Release D 2.079.0
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
Re: Release D 2.079.0
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 [0] is more safe than array.ptr? > > Just want to understand why second statement isn't allowed in > > safe anymore. > > int[] a; > writeln([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 [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
Re: Release D 2.079.0
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;
Re: Release D 2.079.0
On Tuesday, 6 March 2018 at 05:22:58 UTC, Void-995 wrote: Can somebody explain how [0] is more safe than array.ptr? Just want to understand why second statement isn't allowed in safe anymore. int[] a; writeln([0]); // good - runtime produces a core.exception.RangeError //writeln(arr.ptr); // what do you think will happen here?
Re: Release D 2.079.0
Can somebody explain how [0] is more safe than array.ptr? Just want to understand why second statement isn't allowed in safe anymore.
Re: Release D 2.079.0
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.
Re: Release D 2.079.0
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.
Re: Release D 2.079.0
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.
Re: Release D 2.079.0
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
Re: Release D 2.079.0
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
Re: Release D 2.079.0
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.
Re: Release D 2.079.0
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
Re: Release D 2.079.0
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.
Re: Release D 2.079.0
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.
Re: Release D 2.079.0
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.
Re: Release D 2.079.0
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/
Re: Release D 2.079.0
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 :-)
Re: Release D 2.079.0
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 ;-)
Release D 2.079.0
-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-
