www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Futurism lib (futures in D)

reply Kevin Bealer <kevinbealer gmail.com> writes:
I posted my future implementation dsource.org.  It's called "Futurism".  Here
is a simple example of using it:

int main()
{
    // Create a pool of 5 threads
    ThreadPool P = new ThreadPool(5);
    scope(exit) P.stop;

    alias Future!(char[]) FVec;

    char[] a = args[1], b = args[2], c = args[3];

    // Starting reading two files at once:
    FVec f1 = new FVec({ return cast(char[]) read(a); });
    FVec f2 = new FVec({ return cast(char[]) read(b); });



    int total_length = f1.value.length + f2.value.length;

    writefln("total length is %s", f1.value.length + );

    return 0;
}
Jan 21 2007
next sibling parent reply Kevin Bealer <kevinbealer gmail.com> writes:
Sorry - the last post got posted early due to an errant keystroke.  The code
should look like this:

 int main()
 {
     // Create a pool of 5 threads
     ThreadPool P = new ThreadPool(5);
     scope(exit) P.stop;

     alias Future!(char[]) FVec;
     char[] a = args[1], b = args[2], c = args[3];

     // Starting reading two files at once:
     FVec f1 = new FVec({ return cast(char[]) read(a); });
     FVec f2 = new FVec({ return cast(char[]) read(b); });

     // You can do other stuff here if you like
     writefln("files are being read");

     // This line will wait for both files to be read.
     int total_length = f1.value.length + f2.value.length;
     writefln("total length is %s", f1.value.length + );

     return 0;
 }
It took me a bit longer than I expected, when I accidentally did this: dmd -of~/somefile ... And ended up with directory called "~". Naturally I did "rm -rvf ~". There wasn't much else in my home directory right now (new computer), but I was able to recover the source for this stuff using "strings < /dev/hda5" and some elaborate "grep" commands. Try it out if you like, let me know if it has bugs or missing features. Thanks, Kevin
Jan 21 2007
parent reply "Saaa" <empty needmail.com> writes:
I read wikipedia about future and it sounds interesting.
Do you have a bit more information, or some place where I can get it?

As I read it, futurism takes care of threading and synchronization of data 
(between threads). 
Jan 21 2007
next sibling parent "Saaa" <empty needmail.com> writes:
:)
http://www.dsource.org/projects/futurism/browser/trunk/futurism/readme.txt
Jan 21 2007
prev sibling next sibling parent Kevin Bealer <kevinbealer gmail.com> writes:
== Quote from Saaa (empty needmail.com)'s article
 I read wikipedia about future and it sounds interesting.
 Do you have a bit more information, or some place where I can get it?
 As I read it, futurism takes care of threading and synchronization of data
 (between threads).
Let's say I needed to find the sum of an array. int sum(int[] x) { int rv = 0; foreach(int y; x) { rv += y; } return rv; } On a multicpu machine, this operation will run on one CPU. With futures, I can write another routine that utilizes up to 4 CPUs: int sum_4(int[] x) { alias Future!(int) FInt; int part = x.length/4; // Each of these queues a work item to be done either on some // other thread, or by the main thread here. FInt x1 = new FInt({ return sum(x[0..part]); }); FInt x2 = new FInt({ return sum[part..part*2]); }); FInt x3 = new FInt({ return sum[part*2..part*3]); }); FInt x4 = new FInt({ return sum[part*3..$]; }); // The addition below waits for each results to complete // before adding it to the total. return x1.value + x2.value + x3.value + x4.value; } In this case, the four futures will split the array into four parts and queue each quarter as a work item. The four parts will be done in parallel. It should take about 1/4 as long, minus some overhead for building the future objects and so on. The idea is that any time a function needs to do several things that don't depend on each other, they can be represented as futures and the program will run in parallel. My motivation for writing this was a talk by Herb Sutter, its available on Google video here: http://video.google.com/videoplay?docid=7625918717318948700&q=sutter It's pretty long, but interesting I thought -- his basic argument is that computers have gotten faster up till now mostly because the CPU is higher megahertz with better pipelining. But from now on, computers will run faster mostly because they have a lot of CPUs or cores working together. We are seeing the first of this with the dual core and quad core CPUs they are producing now. But the *software* won't actually run any faster unless the programs can be written in a multithreaded way. You will have the same "Photoshop" running at the same speed on one CPU, with other CPUs idling away doing nothing. The problem is that it's hard to write good applications that take advantage of the extra CPUs. It's very hard to write good code with just Thread and Mutex semantics, and monitor/sleep is only a little better. Worse, if I write a library that uses mutexes to synchronize access, I can't really combine it with another library that does the same thing, because to design mutex-using code that doesn't deadlock, you need to know everything about the locking patterns for the whole application. If you combine two libraries that can't deadlock, the result often *will* have potential deadlocks. But, with the future idiom, you can write code that uses extra threads to do work whenever you have two calculations that don't depend on each other. In the example above, the sum of four arrays can be computed seperately. In the Futurism source code on dsource, there is a qsort algorithm that uses futures to do work in parallel. Kevin
Jan 21 2007
prev sibling parent reply Mikola Lysenko <mclysenk mtu.edu> writes:
Saaa wrote:
 
 As I read it, futurism takes care of threading and synchronization of data 
 (between threads). 
 
 
Futures are a powerful technique to increase the parallelism of an application without much extra programming effort. But as much as I like futures, it is Pollyannaish to claim that they solve all thread related problems. Proper use of futures prevents the future threads from communicating altogether eliminating concurrency. This is both good and bad; on the one hand concurrent programming is always risky business, yet in most situations involving threads concurrency is unavoidable. A classic example is the dining philosophers problem. Each philosopher must communicate in order to share common resources.
Jan 21 2007
parent Kevin Bealer <kevinbealer gmail.com> writes:
== Quote from Mikola Lysenko (mclysenk mtu.edu)'s article
 Saaa wrote:
 As I read it, futurism takes care of threading and synchronization of data
 (between threads).
Futures are a powerful technique to increase the parallelism of an application without much extra programming effort. But as much as I like futures, it is Pollyannaish to claim that they solve all thread related problems. Proper use of futures prevents the future threads from communicating altogether eliminating concurrency. This is both good and bad; on the one hand concurrent programming is always risky business, yet in most situations involving threads concurrency is unavoidable. A classic example is the dining philosophers problem. Each philosopher must communicate in order to share common resources.
I see some truth in this. I also think the dining philosopher problem would be less difficult if you have a controlling algorithm that can arbitrate between the three philosophers -- in other words, the problem is difficult because it is formulated as a peer-to-peer design. I think there are tasks that futures don't solve. For example, if you want a status report written to a disk file every N seconds, or you need to control access to a large central hash table, then futures are not the normal solution to those kinds of problems. But I don't see a conflict - I think you can have a status report thread, a mutex-serialized hash table, and still use futures to multithread the complex work loads. There are different uses for multithreaded designs. One of these is to break up complex work, and I think this is where mutexes are awkward and futures are elegant. Kevin Bealer
Jan 22 2007
prev sibling parent reply Daniel Keep <daniel.keep+lists gmail.com> writes:
Kevin Bealer wrote:
 I posted my future implementation dsource.org.  It's called "Futurism".  Here
 is a simple example of using it:
 
 int main()
 {
     // Create a pool of 5 threads
     ThreadPool P = new ThreadPool(5);
     scope(exit) P.stop;
 
     alias Future!(char[]) FVec;
 
     char[] a = args[1], b = args[2], c = args[3];
 
     // Starting reading two files at once:
     FVec f1 = new FVec({ return cast(char[]) read(a); });
     FVec f2 = new FVec({ return cast(char[]) read(b); });
 
 
 
     int total_length = f1.value.length + f2.value.length;
 
     writefln("total length is %s", f1.value.length + );
 
     return 0;
 }
 
Looks good; more sophisticated than my own. A few initial thoughts: 1) Have you considered stealing my code and using the "future(...)" syntax I used? It seems a bit cleaner than having to alias the class, and then instantiating objects. 2) You say that ThreadPools must be stopped before being deleted. Maybe it would be good to have a ThreadPoolScope class that must be scoped, and will call stop for you. 3) Speaking of the thread pools, have you considered creating a default pool with (number of hardware threads) threads? I think std.cpuid can give you those numbers, but I don't know enough to say whether it would a good idea performance-wise. Again, it looks really good. Might have to start using it myself :) -- Daniel
Jan 21 2007
next sibling parent reply Kevin Bealer <kevinbealer gmail.com> writes:
== Quote from Daniel Keep (daniel.keep+lists gmail.com)'s article
 Kevin Bealer wrote:
...
 Looks good; more sophisticated than my own.  A few initial thoughts:

 1) Have you considered stealing my code and using the "future(...)"
 syntax I used?  It seems a bit cleaner than having to alias the class,
 and then instantiating objects.
I wanted the first checkin to be "stealing free" ;), but I was actually going to ask if you minded me adapting the tuples interface from yours. I guess not, so I'll look at doing that then.
 2) You say that ThreadPools must be stopped before being deleted.  Maybe
 it would be good to have a ThreadPoolScope class that must be scoped,
 and will call stop for you.
Couldn't hurt.
 3) Speaking of the thread pools, have you considered creating a default
 pool with (number of hardware threads) threads?  I think std.cpuid can
 give you those numbers, but I don't know enough to say whether it would
 a good idea performance-wise.
I'm not sure about the design. I originally had thread pools call stop() from its own destructor, but of course that doesn't work because the Thread object can be garbage collected first. What I'm not sure of is this: all objects are garbage collected at program termination, but static destructors (static ~this()) blocks are also called at program termination. Is there a guarantee that the GC runs after the ~this() blocks? I would also recommend using more thread pool threads that hardware threads, because some operations (like reading files) are IO bound, and the system benefits if it can switch to a CPU bound thread. So you always want at least the number of hardware threads, but I think its a matter of tuning how many more than that. If you think each task is about 50% CPU bound, you might want something like 2x the number of hardware threads.
 Again, it looks really good.  Might have to start using it myself :)
 	-- Daniel
Thanks - I appreciate the suggestions, too. Kevin
Jan 21 2007
parent reply "Kristian Kilpi" <kjkilpi gmail.com> writes:
On Mon, 22 Jan 2007 03:19:53 +0200, Kevin Bealer <kevinbealer gmail.com>=
  =

wrote:
[snip]
 I would also recommend using more thread pool threads that hardware  =
 threads,
 because some operations (like reading files) are IO bound, and the  =
 system benefits
 if it can switch to a CPU bound thread.  So you always want at least t=
he =
 number of
 hardware threads, but I think its a matter of tuning how many more tha=
n =
 that.  If
 you think each task is about 50% CPU bound, you might want something  =
 like 2x the
 number of hardware threads.
Nice job! I'm looking forward to use futures in the future. :) BTW, is there a way to know the number of hardware threads (and maybe th= e = number of CPUs)? IMHO it would be good to have something like this too: new ThreadPool(4); //pool of 4 threads re = threads new ThreadPool(1.5); //pool of 1.5 * X threads (>=3D 1, rounded up = perhaps) (I think one should, in general, always use thread counts relative to th= e = number of hardware threads.)
Jan 23 2007
next sibling parent reply =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= <jmjmak utu.fi.invalid> writes:
Kristian Kilpi kirjoitti:
 BTW, is there a way to know the number of hardware threads (and maybe
 the number of CPUs)?
std.cpuid has threadsPerCPU(). See http://www.digitalmars.com/d/phobos/std_cpuid.html. How does one know how many hw threads there are available, if two multi-threaded programs are running?
Jan 23 2007
parent reply Kevin Bealer <kevinbealer gmail.com> writes:
== Quote from Jari-Matti_Mäkelä (jmjmak utu.fi.invalid)'s article
 Kristian Kilpi kirjoitti:
 BTW, is there a way to know the number of hardware threads (and maybe
 the number of CPUs)?
std.cpuid has threadsPerCPU(). See http://www.digitalmars.com/d/phobos/std_cpuid.html. How does one know how many hw threads there are available, if two multi-threaded programs are running?
My tendency would be for each program to use enough threads to utilize all the hardware threads. This means that there will be more threads running than CPUs exist, but I don't see extra threads as especially harmful. This is even more true if one or the other application is sometimes idle. For example, if a multithreaded web browser is running, it might use all the CPUs when the user surfing, but after each page loads, the threads will all stop while the user reads the page. I think this is the case for most programs on a desktop machine. For server farms, more tuning is required, and most workloads are already pretty well optimized for the specific hardware. (But see also the latest changes to futurism.) Kevin
Jan 24 2007
parent =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= <jmjmak utu.fi.invalid> writes:
Kevin Bealer kirjoitti:
 == Quote from Jari-Matti_Mäkelä (jmjmak utu.fi.invalid)'s article
 Kristian Kilpi kirjoitti:
 BTW, is there a way to know the number of hardware threads (and maybe
 the number of CPUs)?
std.cpuid has threadsPerCPU(). See http://www.digitalmars.com/d/phobos/std_cpuid.html. How does one know how many hw threads there are available, if two multi-threaded programs are running?
My tendency would be for each program to use enough threads to utilize all the hardware threads. This means that there will be more threads running than CPUs exist, but I don't see extra threads as especially harmful. This is even more true if one or the other application is sometimes idle.
Yeah, this is probably the best for desktop use, where the machine is idle or running just one CPU intensive program (e.g. a game) most of the time.
 I think this is the case for most programs on a desktop machine.  For server
 farms, more tuning is required, and most workloads are already pretty well
 optimized for the specific hardware.
Yup.
 
 (But see also the latest changes to futurism.)
Very nice. This is now much better than creating verbose worker constructs for every parallel operation (Java) or overly complex FSM's using interrupts and timers like in the good old times (DOS games).
Jan 24 2007
prev sibling next sibling parent Kevin Bealer <kevinbealer gmail.com> writes:
== Quote from Kristian Kilpi (kjkilpi gmail.com)'s article
 On Mon, 22 Jan 2007 03:19:53 +0200, Kevin Bealer <kevinbealer gmail.com>=
...
 Nice job! I'm looking forward to use futures in the future. :)
 BTW, is there a way to know the number of hardware threads (and maybe the
 number of CPUs)?

 IMHO it would be good to have something like this too:
    new ThreadPool(4);    //pool of 4 threads

 re  =
 threads
    new ThreadPool(1.5);  //pool of 1.5 * X threads (>=3D 1, rounded up  =
 perhaps)
 (I think one should, in general, always use thread counts relative to th=
 e  =
 number of hardware threads.)
I added something like this to Futurism; it uses five criteria to pick the number of threads to use, in this order: 1. Value passed to constructor (if any). 2. Number from envar FUTURISM_DEFAULT_THREADS (if any). 3. On linux, use #cores * overlap from /proc/cpuinfo. 4. On other x86, use std.cpuid.threadsPerCore * overlap. 5. If all else fails, assume 2 cpus * overlap. Here, overlap is defined as 4, so typically you will see 4 threads on a single CPU machine or 8 on a dual core. The envar is there so that people with several multithreaded apps can balance their own system load if they like. All because the library is designed so that the main thread pulls some of the weight. Kevin
Jan 24 2007
prev sibling parent reply Walter Bright <newshound digitalmars.com> writes:
Kristian Kilpi wrote:
 (I think one should, in general, always use thread counts relative to 
 the number of hardware threads.)
Multithreaded code can speed up computation even on a machine with only one CPU, because of how I/O blocking works.
Jan 26 2007
parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Walter Bright wrote:
 Kristian Kilpi wrote:
 (I think one should, in general, always use thread counts relative to 
 the number of hardware threads.)
Multithreaded code can speed up computation even on a machine with only one CPU, because of how I/O blocking works.
So? You may still want twice as many threads if you've got twice the hardware threads, which is what Kristian was saying. "relative to" != "equal to" :p.
Jan 26 2007
parent Walter Bright <newshound digitalmars.com> writes:
Frits van Bommel wrote:
 Walter Bright wrote:
 Kristian Kilpi wrote:
 (I think one should, in general, always use thread counts relative to 
 the number of hardware threads.)
Multithreaded code can speed up computation even on a machine with only one CPU, because of how I/O blocking works.
So? You may still want twice as many threads if you've got twice the hardware threads, which is what Kristian was saying. "relative to" != "equal to" :p.
Ok.
Jan 26 2007
prev sibling parent reply Kevin Bealer <kevinbealer gmail.com> writes:
== Quote from Daniel Keep (daniel.keep+lists gmail.com)'s article
 Kevin Bealer wrote:
...
 int main()
 {
     // Create a pool of 5 threads
     ThreadPool P = new ThreadPool(5);
     scope(exit) P.stop;

     alias Future!(char[]) FVec;

     char[] a = args[1], b = args[2], c = args[3];

     // Starting reading two files at once:
     FVec f1 = new FVec({ return cast(char[]) read(a); });
     FVec f2 = new FVec({ return cast(char[]) read(b); });



     int total_length = f1.value.length + f2.value.length;

     writefln("total length is %s", f1.value.length + );

     return 0;
 }
Looks good; more sophisticated than my own. A few initial thoughts: 1) Have you considered stealing my code and using the "future(...)" syntax I used? It seems a bit cleaner than having to alias the class, and then instantiating objects.
By the way, I've done this part -- I wrote a function called make_future, (can't use "future" since thats the module name) and modified the templates in future.d to store the argument tuples. There is still things I'm not sure about: 1. Why is a foreach() loop needed to copy a tuple value to another tuple of the same type? 2. You can't pass a char[10] (for example) to a function that uses a char[] input -- instead, you need to ask for the slice, for example, using syntax like: make_future(& work, 1234, "some string"[]); ^^ I could probably fix this if I knew how to use static if or "is" to find out whether something is a static array or not. For now, the above syntax is a not-too-painful workaround. Kevin
Jan 22 2007
next sibling parent reply Daniel Keep <daniel.keep+lists gmail.com> writes:
Kevin Bealer wrote:
 == Quote from Daniel Keep (daniel.keep+lists gmail.com)'s article
 
Kevin Bealer wrote:
Daniel Keep wrote a whole buncha junk, *yoink!*
Looks good; more sophisticated than my own. A few initial thoughts: 1) Have you considered stealing my code and using the "future(...)" syntax I used? It seems a bit cleaner than having to alias the class, and then instantiating objects.
P.S. Of course I don't mind; I'm happy to be able to contribute!
 By the way, I've done this part -- I wrote a function called make_future,
 (can't use "future" since thats the module name) and modified the templates
 in future.d to store the argument tuples.
 
 There is still things I'm not sure about:
 
 1. Why is a foreach() loop needed to copy a tuple value to another tuple of
    the same type?
I tried assigning directly, and it didn't like that, hence the foreach loop. Since it's working on template arguments, it *should* unroll at compile time.
 2. You can't pass a char[10] (for example) to a function that uses a char[]
    input -- instead, you need to ask for the slice, for example, using
    syntax like:
 
      make_future(& work, 1234, "some string"[]);
                                             ^^
 
    I could probably fix this if I knew how to use static if or "is" to find
    out whether something is a static array or not.  For now, the above syntax
    is a not-too-painful workaround.
 
 Kevin
Ah yes, I've had a few problems with this myself (in other things). The trick here is that instead of specialising on the type of the function, I'm specialising on the type of the arguments supplied. In most cases, this isn't a problem, but it does cause problems for arrays (and possibly a few other cases). (I think that) what you need to do is to check to see if an argument is an array, and then check the corresponding type in the function call, and make any necessary casts/conversions. Of course, the alternative is to move the function out to the template argument as an alias, and THEN specialise on the argument type of that (which I've done in my OGL/SDL safety templates), which would make it look like this: make_future!(work)(1234, "some string"); At least, I think it would :P This is one of the reasons I love D: programming in it is like opening up a shiny russian doll: every time you think you know what's going on, there's a whole 'nother layer to play with. Oh hang on, that was supposed to be the "peeling an onion" metaphor, wasn't it? Oh well... -- Daniel "No, ogres are NOT like cake!"
Jan 22 2007
next sibling parent Kevin Bealer <kevinbealer gmail.com> writes:
== Quote from Daniel Keep (daniel.keep+lists gmail.com)'s article
 Kevin Bealer wrote:
...
 I tried assigning directly, and it didn't like that, hence the foreach
 loop.  Since it's working on template arguments, it *should* unroll at
 compile time.
I went through the same thing - but probably quicker because I could look at your example. It's not a problem; maybe its just a temporary limitation.
 2. You can't pass a char[10] (for example) to a function that uses a char[]
    input -- instead, you need to ask for the slice, for example, using
    syntax like:

      make_future(& work, 1234, "some string"[]);
                                             ^^

    I could probably fix this if I knew how to use static if or "is" to find
    out whether something is a static array or not.  For now, the above syntax
    is a not-too-painful workaround.

 Kevin
Ah yes, I've had a few problems with this myself (in other things). The trick here is that instead of specialising on the type of the function, I'm specialising on the type of the arguments supplied. In most cases, this isn't a problem, but it does cause problems for arrays (and possibly a few other cases). (I think that) what you need to do is to check to see if an argument is an array, and then check the corresponding type in the function call, and make any necessary casts/conversions.
I'll look into this angle. I imagine it will require some type-list style tuple recursion.
 Of course, the alternative is to move the function out to the template
 argument as an alias, and THEN specialise on the argument type of that
 (which I've done in my OGL/SDL safety templates), which would make it
 look like this:

      make_future!(work)(1234, "some string");

 At least, I think it would :P
I'm going to try to get the other one smoothed out - it looks a little cleaner to me right now.
 This is one of the reasons I love D: programming in it is like opening
 up a shiny russian doll: every time you think you know what's going on,
 there's a whole 'nother layer to play with.
"Learning is fun!" -- Bender
 Oh hang on, that was supposed to be the "peeling an onion" metaphor,
 wasn't it?  Oh well...

 	-- Daniel "No, ogres are NOT like cake!"
Thanks, Kevin
Jan 22 2007
prev sibling parent reply Kevin Bealer <kevinbealer gmail.com> writes:
== Quote from Daniel Keep (daniel.keep+lists gmail.com)'s article
 Kevin Bealer wrote:
...
 2. You can't pass a char[10] (for example) to a function that uses a char[]
    input -- instead, you need to ask for the slice, for example, using
    syntax like:

      make_future(& work, 1234, "some string"[]);
                                             ^^

    I could probably fix this if I knew how to use static if or "is" to find
    out whether something is a static array or not.  For now, the above syntax
    is a not-too-painful workaround.

 Kevin
Of course, the alternative is to move the function out to the template argument as an alias, and THEN specialise on the argument type of that (which I've done in my OGL/SDL safety templates), which would make it look like this: make_future!(work)(1234, "some string"); At least, I think it would :P This is one of the reasons I love D: programming in it is like opening up a shiny russian doll: every time you think you know what's going on, there's a whole 'nother layer to play with.
I didn't fully appreciate this statement until I got the solution working. Now my head hurt like back when I was learning recursion for the first time, which is a sign that my mental software is getting a refactoring. ;) Template metaprogramming requires another layer of meta-thinking. Practice helps too (with the syntax especially). I think I'm finally starting to "absorb" what tuples are doing and why variadic stuff works the way it does. The requirement for "[]" is gone now, but more fundamentally, conversions between arguments and parameters should happen in the 'right direction'. This is accomplished by extracting the parameters from the delegate inside of make_future() (using a helper template). The changes are in SVN but for those of you just reading along, these are the modified lines: template FutureTypeGroup(Delegate, Args...) { alias ReturnType!(Delegate) Return; alias ParameterTypeTuple!(Delegate) Params; alias Future!(Return, Params) TFuture; } FutureTypeGroup!(Delegate, Args).TFuture make_future(Delegate, Args...)(Delegate cmd, Args args) { return new FutureTypeGroup!(Delegate, Args).TFuture(cmd, args); } I think the fact that this change affects so few lines is a testament to the increasing expressiveness of D. Kevin
Jan 22 2007
parent Daniel Keep <daniel.keep+lists gmail.com> writes:
Kevin Bealer wrote:
 == Quote from Daniel Keep (daniel.keep+lists gmail.com)'s article
 
Of course, the alternative is to move the function out to the template
argument as an alias, and THEN specialise on the argument type of that
(which I've done in my OGL/SDL safety templates), which would make it
look like this:

     make_future!(work)(1234, "some string");

At least, I think it would :P

This is one of the reasons I love D: programming in it is like opening
up a shiny russian doll: every time you think you know what's going on,
there's a whole 'nother layer to play with.
I didn't fully appreciate this statement until I got the solution working. Now my head hurt like back when I was learning recursion for the first time, which is a sign that my mental software is getting a refactoring. ;) Template metaprogramming requires another layer of meta-thinking. Practice helps too (with the syntax especially). I think I'm finally starting to "absorb" what tuples are doing and why variadic stuff works the way it does.
I know the feeling. There's nothing quite like the moment when something new finally clicks into place.
 The requirement for "[]" is gone now, but more fundamentally, conversions
 between arguments and parameters should happen in the 'right direction'.
 
 This is accomplished by extracting the parameters from the delegate inside
 of make_future() (using a helper template).  The changes are in SVN but for
 those of you just reading along, these are the modified lines:
 
 template FutureTypeGroup(Delegate, Args...) {
     alias ReturnType!(Delegate)          Return;
     alias ParameterTypeTuple!(Delegate)  Params;
     alias Future!(Return, Params)        TFuture;
 }
 
 FutureTypeGroup!(Delegate, Args).TFuture
 make_future(Delegate, Args...)(Delegate cmd, Args args)
 {
     return new FutureTypeGroup!(Delegate, Args).TFuture(cmd, args);
 }
Now, see, I hadn't thought of trying that: using another level of indirection to coax the compiler into handling the conversions itself. Very nice.
 I think the fact that this change affects so few lines is a testament
 to the increasing expressiveness of D.
 
 Kevin
That, and our ability to abuse^Hmake use of some of D's advanced features :) -- Daniel
Jan 23 2007
prev sibling parent reply Lutger <lutger.blijdestijn gmail.com> writes:
Kevin Bealer wrote:
    I could probably fix this if I knew how to use static if or "is" to find
    out whether something is a static array or not.
Phobos has an isStaticArray template in std.traits. Nice work btw.
Jan 22 2007
parent Kevin Bealer <kevinbealer gmail.com> writes:
== Quote from Lutger (lutger.blijdestijn gmail.com)'s article
 Kevin Bealer wrote:
    I could probably fix this if I knew how to use static if or "is" to find
    out whether something is a static array or not.
Phobos has an isStaticArray template in std.traits. Nice work btw.
Thanks. I didn't end up using the static array test but I managed to get a solution using other tools from that module -- thanks for reminding me of it. Kevin
Jan 22 2007