Re: Compile-Time Sort in D
On Tuesday, 6 June 2017 at 01:08:45 UTC, Mike Parker wrote: 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). Seems like this crowd-editing stuff really works!
Re: Compile-Time Sort in D
On Thursday, June 08, 2017 01:08:42 Jon Degenhardt via Digitalmars-d-
announce wrote:
> I was surprised as well, pleasantly of course. Using a simple
> example may have helped. Personally, I'm not bothered by the
> specific instances of negative feedback on Reddit. It's hard to
> write a post that manages to avoid that sort of thing entirely.
> It was also nice to see related follow-up in the D forums ("how
> to count lines fast" and "std.csv Performance Review"). It's less
> if the case for how well suited D's facilities are for the type
> of problem came across. It's much more clear in the Compile-Time
> Sort post.
And even the reddit discussion on the compile-time sort post devolved a bit
into arguments over stuff like enums as manifest constants. Using reddit to
get information out there is useful, but from what I've seen, the comments
usually devolve into a fairly negative discussion. I don't spend much time
on reddit though.
- Jonathan M Davis
Re: Compile-Time Sort in D
On Wednesday, 7 June 2017 at 20:59:50 UTC, Joakim wrote:
On Tuesday, 6 June 2017 at 01:08:45 UTC, Mike Parker wrote:
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).
I was surprised it's so popular, as the proggit thread didn't
do that great, but it did well on HN and I now see it inspired
more posts for Rust (written by bearophile, I think) and Go, in
addition to the Nim post linked here before:
https://users.rust-lang.org/t/faster-command-line-tools-in-d-rust/10992
https://aadrake.com/posts/2017-05-29-faster-command-line-tools-with-go.html
I was surprised as well, pleasantly of course. Using a simple
example may have helped. Personally, I'm not bothered by the
specific instances of negative feedback on Reddit. It's hard to
write a post that manages to avoid that sort of thing entirely.
It was also nice to see related follow-up in the D forums ("how
to count lines fast" and "std.csv Performance Review"). It's less
if the case for how well suited D's facilities are for the type
of problem came across. It's much more clear in the Compile-Time
Sort post.
--Jon
Re: Compile-Time Sort in D
On Wednesday, 7 June 2017 at 21:47:58 UTC, John Carter wrote: On Monday, 5 June 2017 at 14:23:34 UTC, Mike Parker wrote: https://dlang.org/blog/2017/06/05/compile-time-sort-in-d/ Seems like you have inspired people... http://blog.zdsmith.com/posts/compiletime-sort-in-nim.html We should make another post showing the string import feature.
Re: Black Duck: DMD license corrected
Thanks for taking care of this.
Re: Compile-Time Sort in D
On Monday, 5 June 2017 at 14:23:34 UTC, Mike Parker wrote: https://dlang.org/blog/2017/06/05/compile-time-sort-in-d/ Seems like you have inspired people... http://blog.zdsmith.com/posts/compiletime-sort-in-nim.html
Re: Compile-Time Sort in D
On Tuesday, 6 June 2017 at 01:08:45 UTC, Mike Parker wrote: 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). I was surprised it's so popular, as the proggit thread didn't do that great, but it did well on HN and I now see it inspired more posts for Rust (written by bearophile, I think) and Go, in addition to the Nim post linked here before: https://users.rust-lang.org/t/faster-command-line-tools-in-d-rust/10992 https://aadrake.com/posts/2017-05-29-faster-command-line-tools-with-go.html
Black Duck: DMD license corrected
Hi, Black duck is a software and a service for enterprises to evaluate the usage of OSS in their products to avoid legal risks. DMD license type is now corrected. There is also a non commercial public available service of Black duck called OpenHub. Here is DMD still listed with the old license, but that will change in the next weeks with the next knowledge base update. https://www.openhub.net/p/dmd Kind regards André
Re: DIP 1003 (Remove body as a Keyword) Accepted!
On Friday, 2 June 2017 at 14:17:10 UTC, Mike Parker wrote: Congratulations are in order for Jared Hanson. Walter and Andrei have approved his proposal to remove body as a keyword. I've added a summary of their decision to the end of the DIP for anyone who cares to read it. In short: * body temporarily becomes a contextual keyword and is deprecated * do is immediately allowed in its place * body is removed and do replaces it fully Congratulations, Jared! https://github.com/dlang/DIPs/blob/master/DIPs/DIP1003.md Well, guess I'm a bit late to the party but I just wanted to echo the sentiment that Mike has done a great job stepping up to oversee the DIP process. All I had to do was write it, and he did the rest. I'm very pleased with how smoothly things went and how easy Mike made the whole process. Thanks Mike!
fluent-asserts 0.5.0 released
Hi, I just released a new version of fluent-asserts: https://github.com/gedaiu/fluent-asserts Since the previous announce, I improved the error messages and I added a new function `.because()` that allows you to add custom messages. If you are interested in writing better asserts in your unit tests you should check this out. Thanks, Bogdan
DIP 1007--"future symbol"--Formal Review Has Begun
The the formal review for DIP 1007, "'future symbol' Compiler Concept", is now underway. Please provide all feedback in the review thread: http://forum.dlang.org/post/ldjlsobcdevxiitqy...@forum.dlang.org
Re: Dynamic binding to the Mono runtime API
On 6/4/17 04:15, Jakub Szewczyk wrote: On Sunday, 4 June 2017 at 09:43:23 UTC, Adam Wilson wrote: On 6/4/17 01:18, Jakub Szewczyk wrote: This is an interface to the Mono libraries, D/CLI would [...] My interest is less in code ports than bindings to the actual code. My experience with code ports or translations is that often subtle bugs creep in during translation due to the fact that each language has different idioms. What I am thinking about is a tool that loads an assembly, examines it's types and methods via this API and emits D code that directly interfaces into the .NET types via this API. The tricky part here is mapping the .NET dependencies into D. The moment the library exposes a type from a dependency, that dependency ALSO needs to be included somehow. All libraries reference "mscorlib", AKA the BCL, so we'd have to provide a "mono-bcl" package on DUB. That's what I actually meant, "porting" was a misused term on my part, "binding" would be a better word, sorry for that. As for the dependency problem - I think that a linking layer generator would accept a list of input assemblies (and optionally, specific classes) to which it should generate bindings, the core Mono types could be automatically translated to D equivalents, and the rest could be left as an opaque reference, like MonoObject* in C, also providing support for very basic reflection through the Mono methods if it turned out to be useful for anyone. Mono actually supports some kind of GC bridging as far as I understand, [...] On the GC side I was mostly thinking about GC Handles so that the objects don't get collected out from underneath us. That is something is trivial to code-gen. As for exceptions, I like the catch->translate->rethrow mechanism. And if the exception is unknown we could simply throw a generic exception. The important thing is to get close to the D experience, not try to map it perfectly. Yes, GCHandles to keep Mono objects in D and a wrapper based on that GC bridge to keep D references from being collected by Mono. I have previously implemented a very similar mechanism for Lua in a small wrapper layer, and it worked perfectly. I can make a static library version, [...] Thank you for this! I find static libraries easier to deal with. I'm sure other people have differing opinions, so having both would make everyone happy. It's now public as v1.1.0, I've tested that it works with the tiny sample, the only important part is that the library to link must be specified by the project using this binding, because those paths may vary across systems, and they cannot be specified in code like the dynamic link ones. However, a simple "libs":["mono-2.0"] entry in dub.json should be enough for most use cases. Thank you for this, I've tried it and it works! I did some in depth research and prototyping in D, and it looks like the only way to enumerate the types in an assembly is to use the Metadata Table API's map everything that way. That's a little beyond the scope of my free time so I'll have to shelve the idea from now. :( -- Adam Wilson IRC: LightBender import quiet.dlang.dev;
