Re: std.parallelism: How to wait all tasks finished?
It seems to me that worker threads will continue as long as the queue isn't empty. So if a task adds another task to the pool, some worker will process the newly enqueued task. No. After taskPool.finish() no way to add new tasks to the queue. taskPool.put will not add new tasks. Then perhaps you need to create a new TaskPool (and make sure that workers add their tasks to the correct task pool), so that you can wait on the first task pool, then wait on the second task pool, etc. auto phase1 = new TaskPool(); //make sure all new tasks are added to phase1 phase1.finish(true); auto phase2 = new TaskPool(); //make sure all new tasks are added to phase2 phase2.finish(true);
Re: std.parallelism: How to wait all tasks finished?
// Next line will block execution until all tasks already in queue finished. // Almost all what I need, but new tasks will not be started. taskPool.finish(true); } Are you sure TaskPool.finish isn't what you're looking for? "Signals worker threads to terminate when the queue becomes empty." It seems to me that worker threads will continue as long as the queue isn't empty. So if a task adds another task to the pool, some worker will process the newly enqueued task.
Re: mixin template
On Friday, 31 January 2014 at 06:24:27 UTC, Dan Killebrew wrote: mixin template Foo(alias a){ alias Foo=a; } pragma(msg, Foo!2); // error template Bar(alias a){ alias Bar=a; } pragma(msg, Bar!2); // ok As far as I can tell, 'mixin template' does nothing new; (besides fail to compile in Timon's reply). I should have said "it does nothing helpful."
Re: mixin template
mixin template Foo(alias a){ alias Foo=a; } pragma(msg, Foo!2); // error template Bar(alias a){ alias Bar=a; } pragma(msg, Bar!2); // ok Perhaps I was unclear. What I meant: What does 'mixin template' do that 'template' does not? Where would I use 'mixin template'? As far as I can tell, 'mixin template' does nothing new; 'template' is sufficient. Thus, 'mixin template' seems like pointless extra syntax. As I said before, this page http://dlang.org/template-mixin.html could have replaced all instances of 'mixin template' with 'template' and it would compile (I tested all examples) and run the same (perhaps not true? I tested about half). Even the example in TDPL on page 284 works the same when I replace 'mixin template' with 'template': (this is my slightly modified version) http://dpaste.dzfl.pl/b582c899fc3f
Re: mixin template
Found this: http://forum.dlang.org/thread/ntuysfcivhbphnhnn...@forum.dlang.org#post-mailman.1409.1339356130.24740.digitalmars-d-learn:40puremagic.com If what Jonathan says is true, then http://dlang.org/template-mixin.html should be updated: s/mixin template/template/
Re: std.json tree navigation help
Check out the json module in vibe.d. Maybe copy it into your own application (since it can't be used as a library, yet). http://vibed.org/api/vibe.data.json/ https://github.com/rejectedsoftware/vibe.d
mixin template
What is the difference between: A --- template Foo() { int x = 5; } B - mixin template Foo() { int x = 5; } The full example is from the first code sample on http://dlang.org/template-mixin.html Both A and B compile and when run, have the exact same output. So how is 'mixin template' different from 'template'? Full example, slightly modified to actually run: import std.stdio; template Foo() { //mixin template Foo() { int x = 5; } mixin Foo; struct Bar { mixin Foo; } void main() { writefln("x = %d", x); // prints 5 { Bar b; int x = 3; writefln("b.x = %d", b.x); // prints 5 writefln("x = %d", x); // prints 3 { mixin Foo; writefln("x = %d", x); // prints 5 x = 4; writefln("x = %d", x); // prints 4 } writefln("x = %d", x); // prints 3 } writefln("x = %d", x); // prints 5 }
Re: Idiomatic way to share mutable data?
On Sunday, 22 December 2013 at 21:07:11 UTC, Charles McAnany wrote: Friends, I'm writing a little molecular simulator. Without boring you with the details, here's the gist of it: struct Atom{ double x, vx; double interaction(Atom a2){ return (a2.x-this.x)^^2; //more complicated in reality } } main(){ Atom[] atoms = (a bunch of atoms in random positions); foreach(timestep; 1..1000){ //L0 foreach(atom; atoms){ //L1 foreach(partner; atoms){ //L2 atom.vx += atom.interaction(partner)/mass; //F=ma } } foreach(atom; atoms){ //L3 atom.x += atom.vx * deltaT; } } } So here's the conundrum: How do I parallelize this efficiently? The first loop, L0, is not parallelizable at all, and I think the best speedup will be in parallelizing L1. But I immediately run into trouble: all the threads need access to all of atoms, and every atom's position is changed on every pass through L0. So to do this purely with message passing would involve copying the entirety of atoms to every thread every L0 pass. Clearly, shared state is desirable. But I don't need to be careful about the shared state at all; L1 only reads Atom.x, and only writes Atom.vx. L3 only reads Atom.vx and only writes Atom.x There's no data dependency at all inside L1 and L3. Is there a way to inform the compiler of this without just aggressively casting things to shared and immutable? On that note, how do you pass a reference to a thread (via send) without the compiler yelling at you? Do you cast(immutable Atom[]) on send and cast(Atom[]) on receive? If you're doing a range limited interaction, partition the atoms spatially and have each core handle a fixed 3D volume. Check out the NT method http://www.cs.cmu.edu/afs/cs/academic/class/15869-f11/www/readings/shaw05_ntmethod.pdf When the core that owns an atom detects that it may be in interaction range for atom(s) owned by another core, send updates to that other core.
Re: sending an Exception and print it
I just wanted to add that the "can't format immutable Exception" also prevents me from doing this: auto exception = receiveOnly!(immutable Exception)(); because receiveOnly creates a tuple which implements a toString that uses indirectly uses formatObject. So I'm forced to use the slightly more clunky recieve() as seen on DPaste.
sending an Exception and print it
I'm sending an exception from a worker thread to the owner thread to be logged/printed. Using DMD64 D Compiler v2.064 http://dpaste.dzfl.pl/7c8b68bd Using std.concurrency prevents me from passing a naked Exception. So the owner receives either a shared or immutable Exception. I can't format a shared Exception: /usr/include/dmd/phobos/std/format.d(2602): Error: static assert "unable to format shared objects" I can't format an immutable Exception: /usr/include/dmd/phobos/std/format.d(2610): Error: template instance formatObject!(Appender!string, immutable(Exception), char) does not match template declaration formatObject(Writer, T, Char)(ref Writer w, ref T val, ref FormatSpec!Char f) if (hasToString!(T, Char)) What gives? I expected the immutable Exception to be formattable. My current workaround is to cast to const Exception. Is there something else I should be doing here?