Re: Compile-Time Sort in D
On Monday, 5 June 2017 at 21:35:54 UTC, Seb wrote: This is a great article, Mike! Thanks! At the end I expected a reference to D's great template constraints [1], maybe it's still worth adding sth. like this to show how amazingly useful CTFE is? It's a good idea! I don't think I'll and change it at this point, though. When I was rewriting the last section, I considered showing two versions of a templated function -- one that uses the validator in a constraint and one that uses it at runtime -- but I worried that would add more noise. The msg pragma and the writeln kept the focus more narrow (which is something that kept coming up in feedback). And at that point, I was ready to be done with it. I worked on that post for a significant chunk of two days.
Re: Compile-Time Sort in D
On Monday, 5 June 2017 at 17:54:05 UTC, Jon Degenhardt wrote: Very nice post! Thanks! If it gets half as many page views as yours did, I'll be happy. Yours is the most-viewed post on the blog -- over 1000 views more than #2 (my GC post), and 5,000 more than #3 (A New Import Idiom).
Re: Compile-Time Sort in D
On Monday, 5 June 2017 at 14:23:34 UTC, Mike Parker wrote: The crowd-edited (?) blog post exploring some of D's compile-time features is now live. Thanks again to everyone who helped out with it. The blog: https://dlang.org/blog/2017/06/05/compile-time-sort-in-d/ Reddit: https://www.reddit.com/r/programming/comments/6fefdg/compiletime_sort_in_d/ Ah Reddit... The article about the elegance of CTFE. Let's discuss the meaning of "enum" then...
Re: Release D 2.074.1
On Monday, 5 June 2017 at 18:25:19 UTC, Martin Nowak wrote: IMO the problem here is the usage of a VERSION file in the first place, which exists only b/c it's somewhat tricky to invoke git on Windows. Yup, my instinct is that if a VERSION file needs to exist at all it should be created during the build process out of `git describe` output. Apart from Windows, are there any other cases where it's still more convenient to have it up front? And what makes invoking git tricky on the Windows side? If your building a version, you know which one it is and can/should provide that version. Who's "you" in this scenario? :-) I think it's reasonable that e.g. an official source tarball should contain sufficient information that building it, without modification or the need for user input, will result in a compiler that reports correct version information. (Official here means the stuff available on the Downloads page, not the autogenerated tarballs that GitHub offers which are just a copy of a checkout of the git tree.) OTOH if one is building from within a git checkout, then git should be queried to provide the version info (with an option to disable/override this if the user wants to). I'd have thought those two options would cover almost all requirements out there, no ... ?
Re: Compile-Time Sort in D
On Monday, 5 June 2017 at 14:23:34 UTC, Mike Parker wrote:
The crowd-edited (?) blog post exploring some of D's
compile-time features is now live. Thanks again to everyone who
helped out with it.
The blog:
https://dlang.org/blog/2017/06/05/compile-time-sort-in-d/
Reddit:
https://www.reddit.com/r/programming/comments/6fefdg/compiletime_sort_in_d/
This is a great article, Mike!
At the end I expected a reference to D's great template
constraints [1], maybe it's still worth adding sth. like this to
show how amazingly useful CTFE is?
auto myRandomEngine(ulong m, ulong a, ulong c)(ulong seed)
if (properLinearCongruentialParameters!(m, a, c))
{
return seed;
}
void main()
{
static assert(!__traits(compiles, myRandomEngine!(1, 2,
3)(42)));
myRandomEngine!(1UL << 32, 1664525, 1013904223)(42);
}
Or alternatively if you don't want to rewrite
properLinearCongruentialParameters e.g.
auto myRandomEngine(ulong m, ulong a, ulong c)(ulong seed)
if (pLCP!(m, a, c))
{
return seed;
}
template pLCP(ulong m, ulong a, ulong c) {
enum pLCP = properLinearCongruentialParameters(m, a, c);
}
[1] https://dlang.org/spec/template.html#template_constraints
Re: Compile-Time Sort in D
On 6/5/2017 10:54 AM, Jon Degenhardt wrote: On Monday, 5 June 2017 at 14:23:34 UTC, Mike Parker wrote: The crowd-edited (?) blog post exploring some of D's compile-time features is now live. Thanks again to everyone who helped out with it. The blog: https://dlang.org/blog/2017/06/05/compile-time-sort-in-d/ Reddit: https://www.reddit.com/r/programming/comments/6fefdg/compiletime_sort_in_d/ Very nice post! It's also on Hacker News under "Compile-Time Sort in D".
Re: Release D 2.074.1
On Saturday, 3 June 2017 at 19:57:36 UTC, Joseph Rushton Wakeling wrote: The problem here is that anyone downstream wanting to build or package from source has to work around this issue, that without manual intervention, the version information of the compiler will be incorrect. If that's not fixed in how dmd itself is managed (NOT the dlang/installer scripts), this will continue to be an unnecessary burden on downstream packagers. IMO the problem here is the usage of a VERSION file in the first place, which exists only b/c it's somewhat tricky to invoke git on Windows. If your building a version, you know which one it is and can/should provide that version.
Re: Release D 2.074.1
On Saturday, 3 June 2017 at 18:08:40 UTC, Joseph Rushton Wakeling wrote: On Thursday, 1 June 2017 at 21:04:00 UTC, Martin Nowak wrote: This point release fixes a few issues over 2.074.0, see the changelog for more details. I'm afraid that the release has another fault: the VERSION file still gives 2.074.0. This means that unless it is edited during the build process, the compiler will report the wrong version number when `dmd --version` is invoked. All those VERSION files are a mess, in particular the dmd VERSION file currently gets updated at a different point than the dlang.org VERSION files. I'd like to get rid of them all and exclusively use git tags, but there are too many other use cases. Updated the release script to update the dmd VERSION file after a release. Guess it would help a bit if we bumped the dmd development version WITH the release instead of AFTER the release. Would also match what git describe does, which might be the saner version anyhow. Should we try to change that for 2.075.0?
Re: Compile-Time Sort in D
On Monday, 5 June 2017 at 14:23:34 UTC, Mike Parker wrote: The crowd-edited (?) blog post exploring some of D's compile-time features is now live. Thanks again to everyone who helped out with it. The blog: https://dlang.org/blog/2017/06/05/compile-time-sort-in-d/ Reddit: https://www.reddit.com/r/programming/comments/6fefdg/compiletime_sort_in_d/ Very nice post!
Compile-Time Sort in D
The crowd-edited (?) blog post exploring some of D's compile-time features is now live. Thanks again to everyone who helped out with it. The blog: https://dlang.org/blog/2017/06/05/compile-time-sort-in-d/ Reddit: https://www.reddit.com/r/programming/comments/6fefdg/compiletime_sort_in_d/
Boston D Meetup for 6/9
Hi fellow Boston D enthusiasts. We are going to have another meetup at the Street in Chestnut Hill this Friday. Andrei and I will be there, hope you can join us! Please RSVP on the eventbrite page: https://www.eventbrite.com/e/monthly-boston-d-get-together-tickets-35120523431 -Steve
Re: DIP 1003 (Remove body as a Keyword) Accepted!
On Friday, 2 June 2017 at 14:17:10 UTC, Mike Parker wrote: https://github.com/dlang/DIPs/blob/master/DIPs/DIP1003.md The "See the previous version" link at the end of the document is currently broken and leads to a 404. Thank you for your efforts and congratulations to Jared Hanson!
Re: DIP 1003 (Remove body as a Keyword) Accepted!
On Saturday, 3 June 2017 at 20:06:05 UTC, Walter Bright wrote: On 6/3/2017 12:28 AM, Petar Kirov [ZombineDev] wrote: Personally, making contracts less verbose and more powerful is much higher on my list We did discuss bouncing the DIP back with a request to revamp it as a complete overhaul of the contract syntax, but decided that this DIP was about resolving a simple and immediate problem, and it shouldn't be held up on that basis. Yes, keeping scope of DIP1003 was the right call. In order to for the process to be effective, we need to have good turnaround time. That said, I'm glad to hear that the idea of an overhaul the contract syntax is on your radar. Related to that, is the need to formally specify what exactly is the compiler allowed to assume via asserts. Currently the answer is offensive programming [0] which doesn't play well with domains that require defensive programming. But that's a topic for another day and another DIP. [0]: https://en.wikipedia.org/wiki/Defensive_programming#Offensive_programming
