October 23, 2015
On 10/22/2015 9:29 PM, Joakim wrote:
> The main D forum is as good a place as any.  Just start a thread there.

No, articles should be more than postings.
October 23, 2015
On 10/22/2015 1:53 PM, Marco Leise wrote:
> There is at least one hurdle. I don't have a place to publish
> articles, no personal blog or site I contribute articles to
> and I don't feel like creating a one-shot one right now. :)

You can publish it on my site:

    http://digitalmars.com/articles/index.html

But I highly recommend that you create your own web site. It's great for your professional career.
October 23, 2015
On 2015-10-22 22:53, Marco Leise wrote:

> There is at least one hurdle. I don't have a place to publish
> articles, no personal blog or site I contribute articles to
> and I don't feel like creating a one-shot one right now. :)

You could have a look at this blog implementation by Dicebot [1]. You still need to host it though.

[1] https://github.com/Dicebot/mood

-- 
/Jacob Carlborg
October 23, 2015
On Friday, 23 October 2015 at 19:48:31 UTC, Jacob Carlborg wrote:
> On 2015-10-22 22:53, Marco Leise wrote:
>
>> There is at least one hurdle. I don't have a place to publish
>> articles, no personal blog or site I contribute articles to
>> and I don't feel like creating a one-shot one right now. :)
>
> You could have a look at this blog implementation by Dicebot [1]. You still need to host it though.
>
> [1] https://github.com/Dicebot/mood

Mood is very nice, and I plan on using it in the medium term (made a pull request so it would compile using gdc or ldc).  But you might want to wait a little while as you want a blog to be stable, and I think there is a problem with segfaulting right now - perhaps to do with the caching of posts, although it shouldn't be hard either to fix that or rewrite it your own way (as I started doing).

It's worth setting one up though - what you use doesn't matter (look at Nikola or one of the other static site generators) - and Walter is right.

October 24, 2015
On Thursday, 22 October 2015 at 20:10:36 UTC, rsw0x wrote:
> On Thursday, 22 October 2015 at 19:16:00 UTC, Laeeth Isharc wrote:
>> On Thursday, 22 October 2015 at 18:23:08 UTC, Andrei Alexandrescu wrote:
>>> On 10/22/2015 09:08 AM, Walter Bright wrote:
>>>> [...]
>>>
>>> This has been a homerun. Congratulations for this work and also for publicizing it! (Consider it might have remained just one forum discussion read by all of 80 persons...) -- Andrei
>>
>> We really do need to stop hiding our light under a bushel.  Thinking in marketing terms doesn't always come easy to technically minded people, and I understand why, but ultimately the community benefits a great deal from people becoming aware of the very real benefits D has to offer (alas people won't just get it, even if you think they should), and there are personal career benefits too from helping communicate how you have applied D to do useful work.  It's hard to find great programmers and showing what you can do will pay off over time.
>
> D has no well defined area to be used in. Everyone knows D, when written in a very specific C-mimicking way, is performant. But nobody is using C# or Scala or Python for performance.

You reply to my post, but I don't entirely see how it relates.  D is very flexible, and that's its virtue.  Because splitting a codebase across multiple languages does have a cost, even if it's often worth paying the cost in order to use the right till for the job when those tools are by their nature specialised.  I don't think everyone knows D is performant, and I wouldn't say fast JSON is written in a C mimicking way, taken as a whole.

Choices are based on making trade-offs, and the relevant data are not static, but constantly shifting.  When an SSD in 2015 that isn't especially pricey gives 2.1 Gig a sec throughput and one has many terabytes of text data a month to get through, and that's today and datasets keep growing and what I write today may be in use for years then the right decision will be a very different one to that five years ago.   That's not just my perception, but those in other fields where the problems are similar - bioinformatics and advertising data being some of the many others.  AdRoll is known for their Python work, but their data scientists use D.

And my point, which you didn't really reply to, is that as a community we should do a bit more to share our experiences on how D can be useful in doing real work.  As Walter observes, that's also something that pays off personally too.

October 26, 2015
On Wednesday, 14 October 2015 at 07:35:49 UTC, Marco Leise wrote:
> Example:
>
>     double x = 0, y = 0, z = 0;
>     auto json = parseTrustedJSON(`{ "coordinates": [ { "x": 1, "y": 2, "z": 3 }, … ] }`);
>
>     foreach (idx; json.coordinates)
>     {
>         // Provide one function for each key you are interested in
>         json.keySwitch!("x", "y", "z")(
>                 { x += json.read!double; },
>                 { y += json.read!double; },
>                 { z += json.read!double; }
>             );
>     }

How can `coordinates` member be known at compile-time when the input argument is a run-time string?
October 27, 2015
On Monday, 26 October 2015 at 20:04:33 UTC, Nordlöw wrote:
> On Wednesday, 14 October 2015 at 07:35:49 UTC, Marco Leise wrote:
>> Example:
>>
>>     double x = 0, y = 0, z = 0;
>>     auto json = parseTrustedJSON(`{ "coordinates": [ { "x": 1, "y": 2, "z": 3 }, … ] }`);
>>
>>     foreach (idx; json.coordinates)
>>     {
>>         // Provide one function for each key you are interested in
>>         json.keySwitch!("x", "y", "z")(
>>                 { x += json.read!double; },
>>                 { y += json.read!double; },
>>                 { z += json.read!double; }
>>             );
>>     }
>
> How can `coordinates` member be known at compile-time when the input argument is a run-time string?

I suspect through the opDispatch operator overload.

http://dlang.org/operatoroverloading.html#dispatch
October 27, 2015
On Tuesday, 27 October 2015 at 13:14:36 UTC, wobbles wrote:
>> How can `coordinates` member be known at compile-time when the input argument is a run-time string?
>
> I suspect through the opDispatch operator overload.
>
> http://dlang.org/operatoroverloading.html#dispatch

Yikes, this is such an anti-pattern.
https://github.com/rejectedsoftware/vibe.d/issues/634
October 28, 2015
On Tuesday, 27 October 2015 at 14:00:07 UTC, Martin Nowak wrote:
> On Tuesday, 27 October 2015 at 13:14:36 UTC, wobbles wrote:
>>> How can `coordinates` member be known at compile-time when the input argument is a run-time string?
>>
>> I suspect through the opDispatch operator overload.
>>
>> http://dlang.org/operatoroverloading.html#dispatch
>
> Yikes, this is such an anti-pattern.
> https://github.com/rejectedsoftware/vibe.d/issues/634

Heh - yeah it is quite problematic.

The only time I've needed to use it was when I was reading in Json with some structure like
{
  [
    {  "timestamp" : { ... timestamp info ... },
       "info1" : { ... info ...},
       "info2" : { ... info ...},
        .
        .
       "info 23" : { ... info  ...}
    },
    { < more of the above >}
  ]
}

and I wanted to be able get a Json[timestamp] map, where the Json is either a info1, info2 etc etc.
I didn't want to write 23 different functions "hash_info1", "hash_info2" etc etc.
So, opDispatch!

Basically I wanted to hash the timestamp and some data. My opDispatch became:

	@ignore auto opDispatch(string name)(){
		static assert(name.startsWith("hash_"), "Error, use StatHosts.hash_XYZ to gather XYZ[timestamp] info");
		static assert(name.length > 5);
		enum dataName = name[5..$];
		typeof(mixin("StatDetail."~dataName))[StatTimestampDetail] data;

		foreach(stat; statistics){
			data[stat.timestamp] = mixin("stat."~dataName);
		}
		return data;
	}

23 functions merged into 1...

The static assert reduces the number of places it can break things at least, still some weird things can happen but for the most part it's ok.

So yes - opDispatch is cool but should be used VERY sparingly.
October 28, 2015
On Wednesday, 28 October 2015 at 11:26:59 UTC, wobbles wrote:
>
> So yes - opDispatch is cool but should be used VERY sparingly.

I just had a thought, I could check if dataName is in [__traits(allMembers ... )]. That would at least ensure I'm referencing something that exists. Maybe that'd be useful in vibes Bson/Json code. (Except the opposite, you want to check you're referencing something that DOESN'T exist, so you can be sure it's not 'remove' for example).