Re: Visual Studio Code code-d serve-d beta release

[Dmitry via Digitalmars-d-announce]

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

[bachmeier via Digitalmars-d-announce]

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

[Joakim via Digitalmars-d-announce]

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

[Martin Nowak via Digitalmars-d-announce]

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

[Nordlöw via Digitalmars-d-announce]

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

[Nordlöw via Digitalmars-d-announce]

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

[Arjan via Digitalmars-d-announce]

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

[Johannes Pfau via Digitalmars-d-announce]

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

[WebFreak001 via Digitalmars-d-announce]

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

[Moritz Maxeiner via Digitalmars-d-announce]

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

[Vladimir Panteleev via Digitalmars-d-announce]

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

[Daniel Kozak via Digitalmars-d-announce]

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

[Vladimir Panteleev via Digitalmars-d-announce]

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

[Biotronic via Digitalmars-d-announce]

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

[Martin Nowak via Digitalmars-d-announce]

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

[Arjan via Digitalmars-d-announce]

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!