Re: Visual Studio Code code-d serve-d beta release
On Tuesday, 8 August 2017 at 17:13:18 UTC, WebFreak001 wrote: Use my other extension `code-debug` (or `Native Debug`) for that Is there somebody who used it successfully on Windows?
Re: Faster Command Line Tools in D
On Tuesday, 8 August 2017 at 21:51:30 UTC, Joakim wrote: On Wednesday, 24 May 2017 at 13:39:57 UTC, Mike Parker wrote: Some of you may remember Jon Degenhardt's talk from one of the Silicon Valley D meetups, where he described the performance improvements he saw when he rewrote some of eBay's command line tools in D. He has now put the effort into crafting a blog post on the same topic, where he takes D version of a command-line tool written in Python and incrementally improves its performance. The blog: https://dlang.org/blog/2017/05/24/faster-command-line-tools-in-d/ Reddit: https://www.reddit.com/r/programming/comments/6d25mg/faster_command_line_tools_in_d/ Heh, happened to notice that this blog post now has 21 comments, with people posting links to versions in Go, C++, and Kotlin up till this week, months after the post went up! :D There was also a Haskell version on Reddit.
Re: Faster Command Line Tools in D
On Wednesday, 24 May 2017 at 13:39:57 UTC, Mike Parker wrote: Some of you may remember Jon Degenhardt's talk from one of the Silicon Valley D meetups, where he described the performance improvements he saw when he rewrote some of eBay's command line tools in D. He has now put the effort into crafting a blog post on the same topic, where he takes D version of a command-line tool written in Python and incrementally improves its performance. The blog: https://dlang.org/blog/2017/05/24/faster-command-line-tools-in-d/ Reddit: https://www.reddit.com/r/programming/comments/6d25mg/faster_command_line_tools_in_d/ Heh, happened to notice that this blog post now has 21 comments, with people posting links to versions in Go, C++, and Kotlin up till this week, months after the post went up! :D
Re: Beta D 2.075.1
On Tuesday, 8 August 2017 at 15:45:45 UTC, Vladimir Panteleev wrote: On Tuesday, 8 August 2017 at 14:57:58 UTC, Daniel Kozak wrote: https://issues.dlang.org/show_bug.cgi?id=17731 Thanks. I've submitted a fix. Thanks, considering https://issues.dlang.org/show_bug.cgi?id=17569 I'd still say we should evaluate whether we want to continue maintaining and shipping a tool with unclear usefulness and userbase.
Re: Netflix opensources its first D library: Vectorflow
On Tuesday, 8 August 2017 at 18:40:08 UTC, Nordlöw wrote: On Thursday, 3 August 2017 at 04:40:05 UTC, Matt wrote: Also note, one of the main advantages of Eigen is the whole lazy evaluation of expressions for compound operations. I haven't dug in the source, but it's my understanding it's done through a lot of compile time C++ template hacking Note that D provides __traits(isRef, Symbol) To clarify here's an incomplete snippet that should clarify: auto add(A, B)(A a, B b) if (isSomeArithmeticType!A && isSomeArithmeticType!B) { static if (__traits(isRef, a) && __traits(isRef, b)) // both `a` and `b` are l-values { return a + b; // fully eager evaluation } else static if (__traits(isRef, a)) // `b` is an r-value { // `b` can incremented by `a` and returned by move (reused) } else static if (__traits(isRef, b)) // `a` is an r-value { // `a` can incremented by `b` and returned by move (reused) } else // both `a` and `b` are r-values { return Add(a,b); // delay evaluation } }
Re: Netflix opensources its first D library: Vectorflow
On Thursday, 3 August 2017 at 04:40:05 UTC, Matt wrote: Also note, one of the main advantages of Eigen is the whole lazy evaluation of expressions for compound operations. I haven't dug in the source, but it's my understanding it's done through a lot of compile time C++ template hacking Note that D provides __traits(isRef, Symbol) which can be used to convenient implement lazy-evaluated expressions with free functions. Note that it cannot currently be used to check whether `this` was passed as an l-value or r-value which prevents the C++-expression-template-pattern from being used in operator overloading. For details see: https://issues.dlang.org/show_bug.cgi?id=17734
Re: Visual Studio Code code-d serve-d beta release
On Tuesday, 8 August 2017 at 17:27:30 UTC, Johannes Pfau wrote: Am Tue, 08 Aug 2017 17:13:18 + schrieb WebFreak001 : On Tuesday, 8 August 2017 at 08:03:05 UTC, Arjan wrote: > Small request: could the setting "d.stdlibPath" be inferred > from the compiler in use? DMD and LDC both have a conf file > in which the paths are already set. oh cool I didn't know that, is there a standard path to where these conf files are though? The D frontend (and therefore all compilers) already has code to print the import paths. Unfortunately this code is only used when an import is not found: -- test.d:1:8: Fehler: module a is in file 'a.d' which cannot be read import a; ^ import path[0] = /usr/include/d import path[1] = /opt/gdc/lib/gcc/x86_64-unknown-linux-gnu/4.9.4/include/d -- It should be trivial though to refactor this code and add a command-line switch to dump the import path. See Module::read in dmodule.c. If Walter opposes adding this to DMD (one more command line switch!) we could probably still add it to GDC glue. This code is all you need: if (global.path) { for (size_t i = 0; i < global.path->dim; i++) { const char *p = (*global.path)[i]; fprintf(stderr, "import path[%llu] = %s\n", (ulonglong)i, p); } } -- Johannes Even better! But when this is rejected, one could also trigger it by feeding a deliberate wrong file to the compiler... Another option is to build a simple hello.d with the -v flag which will reveal the location of the binary the location of the config file used and also the import paths and lib paths so it seems.
Re: Visual Studio Code code-d serve-d beta release
Am Tue, 08 Aug 2017 17:13:18 + schrieb WebFreak001 : > On Tuesday, 8 August 2017 at 08:03:05 UTC, Arjan wrote: > > Small request: could the setting "d.stdlibPath" be inferred > > from the compiler in use? DMD and LDC both have a conf file in > > which the paths are already set. > > oh cool I didn't know that, is there a standard path to where > these conf files are though? The D frontend (and therefore all compilers) already has code to print the import paths. Unfortunately this code is only used when an import is not found: -- test.d:1:8: Fehler: module a is in file 'a.d' which cannot be read import a; ^ import path[0] = /usr/include/d import path[1] = /opt/gdc/lib/gcc/x86_64-unknown-linux-gnu/4.9.4/include/d -- It should be trivial though to refactor this code and add a command-line switch to dump the import path. See Module::read in dmodule.c. If Walter opposes adding this to DMD (one more command line switch!) we could probably still add it to GDC glue. This code is all you need: if (global.path) { for (size_t i = 0; i < global.path->dim; i++) { const char *p = (*global.path)[i]; fprintf(stderr, "import path[%llu] = %s\n", (ulonglong)i, p); } } -- Johannes
Re: Visual Studio Code code-d serve-d beta release
On Tuesday, 8 August 2017 at 08:03:05 UTC, Arjan wrote: Small request: could the setting "d.stdlibPath" be inferred from the compiler in use? DMD and LDC both have a conf file in which the paths are already set. oh cool I didn't know that, is there a standard path to where these conf files are though? What about the debugging experience? Plans to integrate that as well? Use my other extension `code-debug` (or `Native Debug`) for that
Re: Release D 2.075.0
On Wednesday, 19 July 2017 at 15:36:22 UTC, Martin Nowak wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Glad to announce D 2.075.0. This release comes with various phobos additions, a repackaged std.datetime, configurable Fiber stack guard pages (now also on Posix), and optional precise GC scanning for the DATA/TLS segment (static data) on Windows. http://dlang.org/download.html http://dlang.org/changelog/2.075.0.html Sorry for replying so late, but the changelog for 2.075.0[1] incorrectly list issue 14246[2] as solved, when the fix was, in fact, reverted [3]. [1] http://dlang.org/changelog/2.075.0.html#bugfix-list [2] https://issues.dlang.org/show_bug.cgi?id=14246 [3] https://github.com/dlang/dmd/pull/6913
Re: Beta D 2.075.1
On Tuesday, 8 August 2017 at 14:57:58 UTC, Daniel Kozak wrote: https://issues.dlang.org/show_bug.cgi?id=17731 Thanks. I've submitted a fix.
Re: Beta D 2.075.1
https://issues.dlang.org/show_bug.cgi?id=17731 On Tue, Aug 8, 2017 at 4:45 PM, Vladimir Panteleev via Digitalmars-d-announce wrote: > On Tuesday, 8 August 2017 at 08:41:15 UTC, Martin Nowak wrote: > >> This release does not ship with the dman tool due to an unresolved issue. >> > > What's the problem with dman? > >
Re: Beta D 2.075.1
On Tuesday, 8 August 2017 at 08:41:15 UTC, Martin Nowak wrote: This release does not ship with the dman tool due to an unresolved issue. What's the problem with dman?
Re: d_to_html.d
On Sunday, 6 August 2017 at 15:18:29 UTC, Jacob Carlborg wrote: [snip] Wow, that's pretty cool :). One downside I see is that all tags are currently hard coded. This won't work for XML or if using new/custom tags that the library doesn't know about yet. That's easily amendable: struct ElementBuilder { auto opDispatch(string name, Args...)(Args args) const { return Element(name)(args); } } enum xml = ElementBuilder(); unittest { enum a = xml.foo(xml.bar("baz"), xml.qux(123)); assert(a.toString == "baz123"); } -- Biotronic
Beta D 2.075.1
First beta for the 2.075.1 point release. This version resolves a few regressions and bugs in the 2.075.0 release. This release does not ship with the dman tool due to an unresolved issue. Let us know whether and how you use that tool, so we can evaluate whether it's worth fixing. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.075.1.html Please report any bugs at https://issues.dlang.org -Martin
Re: Visual Studio Code code-d serve-d beta release
On Saturday, 5 August 2017 at 22:43:31 UTC, WebFreak001 wrote: ... Thanks a lot! Will give it a try. Small request: could the setting "d.stdlibPath" be inferred from the compiler in use? DMD and LDC both have a conf file in which the paths are already set. What about the debugging experience? Plans to integrate that as well? Keep up the good work!