Usage of DDOC_KEYWORD and DDOC_TEMPLATE_PARAM macros

I'm working on a Ddoc theme and I have trouble figuring out when the DDOC_KEYWORD and DDOC_TEMPLATE_PARAM macros are used. Are the compiler outputting them or should the developer be using those directly? If the compiler is outputting them, then when is it doing that? -- /Jacob Carlborg

Re: Lazily evaluated property pointing to read only object

On Saturday, 24 September 2016 at 11:51:56 UTC, Basile B. wrote: On Saturday, 24 September 2016 at 10:59:50 UTC, mikey wrote: On Saturday, 24 September 2016 at 10:16:34 UTC, Basile B. wrote: You don't need to cast, from "mutable" to "const" is implicit:

Re: Is TDPL an accurate description of the D language today?

On 9/27/16 1:38 PM, Mark wrote: I've been going through Andrei's excellent book and I noticed that the latest printing is from 2010. Since D is still a very young language I can imagine it changing quite a bit within six years. So I wonder if there are any major inconsistincies between the

Is TDPL an accurate description of the D language today?

I've been going through Andrei's excellent book and I noticed that the latest printing is from 2010. Since D is still a very young language I can imagine it changing quite a bit within six years. So I wonder if there are any major inconsistincies between the current state of the language and

Re: Module Clarification

On Tuesday, 27 September 2016 at 13:48:39 UTC, Steven Schveighoffer wrote: On 9/22/16 4:16 PM, Jonathan Marler wrote: On Thursday, 22 September 2016 at 20:09:41 UTC, Steven Schveighoffer wrote: Before package.d support, you could not do any importing of packages. You could only import

Re: Problem parsing IPv4/IPv6 addresses with std.socket.parseAddress

On Tuesday, 27 September 2016 at 14:39:10 UTC, Dsciple wrote: On Tuesday, 27 September 2016 at 14:02:25 UTC, Marc Schütz wrote: On Tuesday, 27 September 2016 at 09:04:53 UTC, Dsciple wrote: As said, this works fine when tested in isolation, and the compiler only complains when using

Re: Problem parsing IPv4/IPv6 addresses with std.socket.parseAddress

On Tuesday, 27 September 2016 at 14:02:25 UTC, Marc Schütz wrote: On Tuesday, 27 September 2016 at 09:04:53 UTC, Dsciple wrote: As said, this works fine when tested in isolation, and the compiler only complains when using BindAddress as a member of ConfigParams. Any idea what the problem may

Re: Problem parsing IPv4/IPv6 addresses with std.socket.parseAddress

On Tuesday, 27 September 2016 at 09:04:53 UTC, Dsciple wrote: As said, this works fine when tested in isolation, and the compiler only complains when using BindAddress as a member of ConfigParams. Any idea what the problem may be? Or is there maybe a ready to use, high-level library for

Re: How to debug (potential) GC bugs?

On Sunday, 25 September 2016 at 16:23:11 UTC, Matthias Klumpp wrote: Hello! I am working together with others on the D-based appstream-generator[1] project, which is generating software metadata for "software centers" and other package-manager functionality on Linux distributions, and is used

Re: Proper way to work around `Invalid memory operation`?

On Sunday, 25 September 2016 at 16:07:12 UTC, Matthias Klumpp wrote: Hello! I have a class similar to this one: ``` class Dummy { private: string tmpDir; public: this (string fname) { tmpDir = buildPath ("/tmp", fname.baseName); std.file.mkdirRecurse (tmpDir);

Re: Module Clarification

On 9/22/16 4:16 PM, Jonathan Marler wrote: On Thursday, 22 September 2016 at 20:09:41 UTC, Steven Schveighoffer wrote: Before package.d support, you could not do any importing of packages. You could only import modules. package.d was how the compiler allowed importing packages. I don't know

Re: How to debug (potential) GC bugs?

On Sunday, 25 September 2016 at 16:23:11 UTC, Matthias Klumpp wrote: Hello! I am working together with others on the D-based appstream-generator[1] project, which is generating software metadata for "software centers" and other package-manager functionality on Linux distributions, and is used

Re: Is there any way to have [] overloads use compile-time indexes as is currently done for Tuples?

On Tuesday, 27 September 2016 at 09:21:04 UTC, pineapple wrote: I'd really like to define my own types that accept indexes for opIndex and opSlice as template arguments. Is there any way to do this? If not, this seems like an obvious thing to add to the language - what's been holding it back?

Re: JSON decode?

On Tuesday, 27 September 2016 at 10:45:45 UTC, Andre Pany wrote: Hi, from a rest call I get a JSON with a strange format: {"DEPLOY_ATTRIBUTES":"{\n \"dependency-type\": \"soft\"\n}","MTA_METADATA":"{\n \"id\":... The sub objects are enclosed with quotes and there are a lot of line break

Re: Easy sockets - don't exist yet?

On Tuesday, 27 September 2016 at 11:16:00 UTC, Russel Winder wrote: On Tue, 2016-09-27 at 10:16 +, JN via Digitalmars-d-learn wrote: On Tuesday, 27 September 2016 at 09:23:35 UTC, Russel Winder wrote: > > Why not just create a binding to 0MQ and get much, much more > than asked for? >

Re: Easy sockets - don't exist yet?

On Tue, 2016-09-27 at 10:16 +, JN via Digitalmars-d-learn wrote: > On Tuesday, 27 September 2016 at 09:23:35 UTC, Russel Winder  > wrote: > > > > Why not just create a binding to 0MQ and get much, much more  > > than asked for? > > > > http://code.dlang.org/packages/zmqd >

JSON decode?

Hi, from a rest call I get a JSON with a strange format: {"DEPLOY_ATTRIBUTES":"{\n \"dependency-type\": \"soft\"\n}","MTA_METADATA":"{\n \"id\":... The sub objects are enclosed with quotes and there are a lot of line break characters. Also the quotes are escaped. I try to translate a

Re: Easy sockets - don't exist yet?

On Tuesday, 27 September 2016 at 09:23:35 UTC, Russel Winder wrote: Why not just create a binding to 0MQ and get much, much more than asked for? http://code.dlang.org/packages/zmqd http://code.dlang.org/packages/zeromq http://code.dlang.org/packages/dzmq or use existing ones :)

Is there any way to have [] overloads use compile-time indexes as is currently done for Tuples?

I'd really like to define my own types that accept indexes for opIndex and opSlice as template arguments. Is there any way to do this? If not, this seems like an obvious thing to add to the language - what's been holding it back?

Re: Easy sockets - don't exist yet?

Why not just create a binding to 0MQ and get much, much more than asked for? On Mon, 2016-09-26 at 23:40 +, Vincent via Digitalmars-d-learn wrote: > Hello, guys! > > I was very surprised that module 'socketstream' was deprecated.  > Usually if something become obsolete, there is some perfect 

Problem parsing IPv4/IPv6 addresses with std.socket.parseAddress

Hi there! I wrote a small utility library to read configuration parameters from both command-line arguments (using std.getopt) and SDLang files (using sdlang-d package). The main library defines a struct ConfigParams whose fields are themselves structs defined in sub-libraries (set as

Re: Easy sockets - don't exist yet?

Just in case, here are the relevant docs: http://dlang.org/phobos/std_net_curl.html

Re: Easy sockets - don't exist yet?

Am Mon, 26 Sep 2016 23:40:10 + schrieb Vincent : > 1. Easy to use. No more stupid "UNIX sockets", "TCP types" and so > on. Just simple as this: > > // Client side > auto sock = new ClientSocket("google.com", 80); > sock.WriteLine("GET / HTTP/1.0"); > sock.WriteLine("Host:

Re: How to debug (potential) GC bugs?

Am Sun, 25 Sep 2016 16:23:11 + schrieb Matthias Klumpp : > So, I would like to know the following things: > > 1) Is there any caveat when linking to C libraries and using the > GC in a project? So far, it seems to be working well, but there > have been a few cases

Re: Easy sockets - don't exist yet?

On Monday, 26 September 2016 at 23:40:10 UTC, Vincent wrote: Hello, guys! I was very surprised that module 'socketstream' was deprecated. Usually if something become obsolete, there is some perfect replacement! But my digging in Inet and forums gave nothing, but "outdated" examples with