www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - std.parallelism: VOTE IN THIS THREAD

reply "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
As announced a week ago, the formal review process for David Simcha's 
std.parallelism module is now over, and it is time to vote over whether 
the module should be included in Phobos.  See below for more information 
on the module and on previous reviews.

Please vote in this thread, by replying with

  - "YES" if you think std.parallelism should be included in Phobos
    in its present form,

  - "NO" if you think it shouldn't.

Voting closes in one week, on 26 April, at 12:00 (noon) UTC.

Note that this thread is for voting only; please refrain from further 
discussion and reviews here.


THE MODULE AND THE REVIEW PROCESS

Code and documentation can be found here:

    https://github.com/dsimcha/std.parallelism/blob/master/parallelism.d
    http://cis.jhu.edu/~dsimcha/d/phobos/std_parallelism.html

The module has been through several review cycles.  We started a formal 
review some time ago, but a fair amount of criticism (constructive, that 
is) and suggestions for major changes came in during the last few days 
before the planned vote.  As a consequence, the review and the voting was 
postponed.  David has since gone about fixing the issues that were 
raised, and in his own words, "[the] suggestions have led to major 
improvements, especially in the documentation".

A week ago we restarted the formal review process, and in this last one 
no new suggestions, nor any further criticism, has been put on the 
table.  David has suggested some alternative names for the module, but I 
think we can treat that separately from this vote, or possibly leave it 
up to the Phobos team to decide, as it is more a question of the 
organisation of the library as a whole than of the quality and 
suitability of this specific module.

std.parallelism is already a quite mature piece of code (first announced 
in October 2009 as "parallelFuture"), and it has been used actively for 
some time by both David and yours truly.

For those who haven't followed the previous reviews, here are a few links 
to the most relevant discussions:

    http://www.digitalmars.com/d/archives/digitalmars/D/
std.parallelism_Final_review_131248.html

    http://www.digitalmars.com/d/archives/digitalmars/D/
review_of_std.parallelism_132291.html

    http://www.digitalmars.com/d/archives/digitalmars/D/
std.parallelism_changes_done_132607.html


-Lars
Apr 19 2011
next sibling parent Russel Winder <russel russel.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

YES

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel russel.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Apr 19 2011
prev sibling next sibling parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
YES

-- 
Dmitry Olshansky
Apr 19 2011
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Lars T. Kyllingstad:

 Please vote in this thread, by replying with
 
   - "YES" if you think std.parallelism should be included in Phobos
     in its present form,
 
   - "NO" if you think it shouldn't.

If my vote counts then Yes. Bye, bearophile
Apr 19 2011
next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
 Lars T. Kyllingstad:
 Please vote in this thread, by replying with
 
   - "YES" if you think std.parallelism should be included in Phobos
   
     in its present form,
   
   - "NO" if you think it shouldn't.

If my vote counts then Yes.

Everyone's vote on the newsgroup counts unless it becomes evident that we have a sock puppet problem or a ton of people that never post here start voting or some other problem occurs where it's evident that there's a problem which is skewing the votes. As long as things continue to go smoothly with the voting and people don't abuse it, anyone on the newsgroup can vote. - Jonathan M Davis
Apr 19 2011
prev sibling next sibling parent reply Caligo <iteronvexor gmail.com> writes:
On Tue, Apr 19, 2011 at 5:49 AM, Jonathan M Davis <jmdavisProg gmx.com> wro=
te:
 Lars T. Kyllingstad:
 Please vote in this thread, by replying with

 =A0 - "YES" if you think std.parallelism should be included in Phobos

 =A0 =A0 in its present form,

 =A0 - "NO" if you think it shouldn't.

If my vote counts then Yes.

Everyone's vote on the newsgroup counts unless it becomes evident that we=

 a sock puppet problem or a ton of people that never post here start votin=

 some other problem occurs where it's evident that there's a problem which=

 skewing the votes. As long as things continue to go smoothly with the vot=

 and people don't abuse it, anyone on the newsgroup can vote.

 - Jonathan M Davis

I would like to make a comment if that's okay. If a person is not an expert on parallelism, library development, or we can't verify his or her background and such, I don't see why their vote should count. I'm not voting because I'm just an ordinary D user, and I have no expertise in parallelism. And since this a public vote, if would be great if people who are voting did not hide behind an alias, such as bearophile. P.S. I can't wait for std.parallelism to become part of Phobos.
Apr 19 2011
parent bearophile <bearophileHUGS lycos.com> writes:
Caligo:

 I would like to make a comment if that's okay.  If a person is not an
 expert on parallelism, library development, or we can't verify his or
 her background and such, I don't see why their vote should count.  I'm
 not voting because I'm just an ordinary D user, and I have no
 expertise in parallelism.  And since this a public vote, if would be
 great if people who are voting did not hide behind an alias, such as
 bearophile.

You are right regarding parallelism experience, I don't know enough about this topic, this is why I was not sure about voting. Feel free to ignore my vote because of this. Regarding library development experience, alias problems, etc, they aren't problems in this case. Bye, bearophile
Apr 19 2011
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
He's not hiding behind an alias, he made numerous blog posts here:
http://leonardo-m.livejournal.com/

My vote is YES.
Apr 19 2011
prev sibling next sibling parent Caligo <iteronvexor gmail.com> writes:
On Tue, Apr 19, 2011 at 7:11 AM, bearophile <bearophileHUGS lycos.com> wrot=
e:
 Caligo:

 I would like to make a comment if that's okay. =A0If a person is not an
 expert on parallelism, library development, or we can't verify his or
 her background and such, I don't see why their vote should count. =A0I'm
 not voting because I'm just an ordinary D user, and I have no
 expertise in parallelism. =A0And since this a public vote, if would be
 great if people who are voting did not hide behind an alias, such as
 bearophile.

You are right regarding parallelism experience, I don't know enough about=

y vote because of this.
 Regarding library development experience, alias problems, etc, they aren'=

 Bye,
 bearophile

Sorry Leonardo, I didn't mean to pick on you. It's just that I don't believe in voting, and I really care about D.
Apr 19 2011
prev sibling next sibling parent reply Russel Winder <russel russel.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 2011-04-19 at 06:13 -0500, Caligo wrote:
[ . . . ]
 I would like to make a comment if that's okay.  If a person is not an
 expert on parallelism, library development, or we can't verify his or
 her background and such, I don't see why their vote should count.  I'm
 not voting because I'm just an ordinary D user, and I have no
 expertise in parallelism.  And since this a public vote, if would be
 great if people who are voting did not hide behind an alias, such as
 bearophile.

I think there is an very interesting and important issue here. There are really four (or more/less) roles of people who might vote: Has detailed knowledge of implementation and usage. Has some knowledge of implementation and/or usage. Perhaps just using the API. No actual interest.=20 And then there are: Sock puppet aka shill Troll but let's ignore them. Although the general belief is "one person, one vote", some decisions are best influenced by considering the weighting to a vote provided by annotating with role. Two cases perhaps highlight this: If a person using the library but having no knowledge of the implementation finds a problematic API issue then this should count as much as any view of people more knowledgeable about the internals. If a person without knowledge of the theory and practice votes yes where the domain experts are able to argue there is a blocking problem, then the person leading the vote should have the option of cancelling and re-entering review even if there was a clear majority vote for. I think the issue here is not to be bound too rigidly by votes and statistics, this is not after all politics, but instead to ensure that everyone has the right sort of say about these things and that the majority of people always feel the right decisions are getting made. Consider the system not being one of the review leader managing the votes, but of the review leader having a single golden vote which then has to be justified by argumentation.
 P.S.
 I can't wait for std.parallelism to become part of Phobos.

Me too. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Apr 19 2011
parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 19/04/2011 14:47, Russel Winder wrote:
 On Tue, 2011-04-19 at 06:13 -0500, Caligo wrote:
 [ . . . ]
 I would like to make a comment if that's okay.  If a person is not an
 expert on parallelism, library development, or we can't verify his or
 her background and such, I don't see why their vote should count.  I'm
 not voting because I'm just an ordinary D user, and I have no
 expertise in parallelism.  And since this a public vote, if would be
 great if people who are voting did not hide behind an alias, such as
 bearophile.

I think there is an very interesting and important issue here. There are really four (or more/less) roles of people who might vote: Has detailed knowledge of implementation and usage. Has some knowledge of implementation and/or usage. Perhaps just using the API. No actual interest. And then there are: Sock puppet aka shill Troll but let's ignore them. Although the general belief is "one person, one vote", some decisions are best influenced by considering the weighting to a vote provided by annotating with role. Two cases perhaps highlight this: If a person using the library but having no knowledge of the implementation finds a problematic API issue then this should count as much as any view of people more knowledgeable about the internals. If a person without knowledge of the theory and practice votes yes where the domain experts are able to argue there is a blocking problem, then the person leading the vote should have the option of cancelling and re-entering review even if there was a clear majority vote for. I think the issue here is not to be bound too rigidly by votes and statistics, this is not after all politics, but instead to ensure that everyone has the right sort of say about these things and that the majority of people always feel the right decisions are getting made. Consider the system not being one of the review leader managing the votes, but of the review leader having a single golden vote which then has to be justified by argumentation.
 P.S.
 I can't wait for std.parallelism to become part of Phobos.

Me too.

I generally agree with this perspective, being aware of this issue, and not making the voting completely democratic (that's why I'm not voting on this one). On the other hand, one would also hope that those with D's best interest in mind will also be mindful of this, and not vote if they feel they have insuficient knowledge to evaluate the proposal. In other words, one would hope the community would self-regulate to avoid this problem, and no formal additional rules should be needed. Let's see. In any case it seems this won't matter for this proposal, everyone is voting yes :) . But it's worthwhile to keep in mind for the future. -- Bruno Medeiros - Software Engineer
Apr 21 2011
parent reply lurker <lurk lurking.org> writes:
Bruno Medeiros Wrote:

 On 19/04/2011 14:47, Russel Winder wrote:
 On Tue, 2011-04-19 at 06:13 -0500, Caligo wrote:
 [ . . . ]
 I would like to make a comment if that's okay.  If a person is not an
 expert on parallelism, library development, or we can't verify his or
 her background and such, I don't see why their vote should count.  I'm
 not voting because I'm just an ordinary D user, and I have no
 expertise in parallelism.  And since this a public vote, if would be
 great if people who are voting did not hide behind an alias, such as
 bearophile.

I think there is an very interesting and important issue here. There are really four (or more/less) roles of people who might vote: Has detailed knowledge of implementation and usage. Has some knowledge of implementation and/or usage. Perhaps just using the API. No actual interest. And then there are: Sock puppet aka shill Troll but let's ignore them. Although the general belief is "one person, one vote", some decisions are best influenced by considering the weighting to a vote provided by annotating with role. Two cases perhaps highlight this: If a person using the library but having no knowledge of the implementation finds a problematic API issue then this should count as much as any view of people more knowledgeable about the internals. If a person without knowledge of the theory and practice votes yes where the domain experts are able to argue there is a blocking problem, then the person leading the vote should have the option of cancelling and re-entering review even if there was a clear majority vote for. I think the issue here is not to be bound too rigidly by votes and statistics, this is not after all politics, but instead to ensure that everyone has the right sort of say about these things and that the majority of people always feel the right decisions are getting made. Consider the system not being one of the review leader managing the votes, but of the review leader having a single golden vote which then has to be justified by argumentation.
 P.S.
 I can't wait for std.parallelism to become part of Phobos.

Me too.

I generally agree with this perspective, being aware of this issue, and not making the voting completely democratic (that's why I'm not voting on this one). On the other hand, one would also hope that those with D's best interest in mind will also be mindful of this, and not vote if they feel they have insuficient knowledge to evaluate the proposal. In other words, one would hope the community would self-regulate to avoid this problem, and no formal additional rules should be needed. Let's see. In any case it seems this won't matter for this proposal, everyone is voting yes :) . But it's worthwhile to keep in mind for the future.

Yes, everyone is voting yes. And half of the voters haven't ever used parallelism or know anything about its library level design issues. This voting process seemed like a joke. I know this kind of voting is popular in other projects, but D community's infrastructure isn't ready for this. It just shows how UNagile and clumsy the design process is and merely a meat puppet theatre for hiding a dictatorship with uninformed "democracy". You could just add stuff until someone starts complaining and begin hardcore technical discussion when real problems arise. Cheers, sock puppet #2347
Apr 24 2011
next sibling parent reply dsimcha <dsimcha yahoo.com> writes:
On 4/24/2011 12:18 PM, lurker wrote:
 Yes, everyone is voting yes. And half of the voters haven't ever used
parallelism or know anything about its library level design issues. This voting
process seemed like a joke. I know this kind of voting is popular in other
projects, but D community's infrastructure isn't ready for this. It just shows
how UNagile and clumsy the design process is and merely a meat puppet theatre
for hiding a dictatorship with uninformed "democracy". You could just add stuff
until someone starts complaining and begin hardcore technical discussion when
real problems arise.

 Cheers,
 sock puppet #2347

The review process leading up to the voting was not, however, a joke or unanimous or anything similar. I received plenty of tough-but-fair criticism and it led to substantial improvements in the library and especially the documentation.
Apr 24 2011
parent dsimcha <dsimcha yahoo.com> writes:
On 4/24/2011 3:09 PM, Russel Winder wrote:
 On Sun, 2011-04-24 at 13:41 -0400, dsimcha wrote:
 [ . . . ]
 The review process leading up to the voting was not, however, a joke or
 unanimous or anything similar.  I received plenty of tough-but-fair
 criticism and it led to substantial improvements in the library and
 especially the documentation.

Which is perhaps why the review process itself is incredibly valuable but the vote process is a bit fatuous as a decision making system.

I understand the points being made here, but I actually think votes from people who know little about topic X are valuable when evaluating API design for a topic X library. People who would only use a topic X library occasionally are probably in the best position to judge whether simple things are sufficiently simple. People who would use such a library all the time are probably so well versed in the topic and would use the advanced features so often that they're likely to overlook this aspect.
Apr 24 2011
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 04/24/2011 11:18 AM, lurker wrote:
 Yes, everyone is voting yes. And half of the voters haven't ever used
 parallelism or know anything about its library level design issues.
 This voting process seemed like a joke. I know this kind of voting is
 popular in other projects, but D community's infrastructure isn't
 ready for this. It just shows how UNagile and clumsy the design
 process is and merely a meat puppet theatre for hiding a dictatorship
 with uninformed "democracy". You could just add stuff until someone
 starts complaining and begin hardcore technical discussion when real
 problems arise.

 Cheers, sock puppet #2347

There are a couple of issues that reflect quite ironically on the author of this. First, well, it's a sock puppet - meaning that the statement is something the author would be ashamed to put their name under. But the funniest thing is the _choice_ of criticism. If the point is to demean the D programming language's community, I'm sure there are much better cherries to pick than this one! The proposal on std.parallelism is at its second incarnation after having been practically demolished in its first instance. It's quite obvious to anyone who paid attention that the good consensus this time around is a direct consequence of the extensive improvements prompted by strong scrutiny. Regarding the expertise level of the voters, I agree with what others said - a non-expert reviewer and voter is a valuable resource. I presume that people who don't give a crap about a domain won't bother to vote. Then, if an interested non-expert looks over the documentation and thinks "well this is something that I see myself using if the need arises" then that's good signal too. It was in fact one criticism I made about the first version of std.parallelism - its documentation was written for specialists. Last but not least, associating David Simcha with an allegation of a dictatorship - that literally put a smile on my face. David would be probably the worst example of a dictatorship's camarilla ever. The only thing about David that anyone in the dictator's inner circle knows is his work. Andrei
Apr 24 2011
prev sibling next sibling parent Russel Winder <russel russel.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sun, 2011-04-24 at 13:41 -0400, dsimcha wrote:
[ . . . ]
 The review process leading up to the voting was not, however, a joke or=

 unanimous or anything similar.  I received plenty of tough-but-fair=20
 criticism and it led to substantial improvements in the library and=20
 especially the documentation.

Which is perhaps why the review process itself is incredibly valuable but the vote process is a bit fatuous as a decision making system. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Apr 24 2011
prev sibling parent Russel Winder <russel russel.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sun, 2011-04-24 at 15:19 -0400, dsimcha wrote:
[ . . . ]
 I understand the points being made here, but I actually think votes from=

 people who know little about topic X are valuable when evaluating API=20
 design for a topic X library.  People who would only use a topic X=20
 library occasionally are probably in the best position to judge whether=

 simple things are sufficiently simple.  People who would use such a=20
 library all the time are probably so well versed in the topic and would=

 use the advanced features so often that they're likely to overlook this=

 aspect.

I don't disagree, which is why I earlier suggested that categorizing people voting so as to know their role as a voter would be good, and for the review leader to have the only actual yes/no vote but based on input from the general populace. The point here, which I think we are all agreed on, is that there are people who have knowledge of the internals and therefore may have blind spots about the API; people who have tried the API; and people who have not tried the API but perhaps ought to and need to be convinced to try it. "One person, one vote" is great in some ways, but not really a good way of deciding the sort of thing we have here, at least not per se. The review leader taking a public poll is a good idea, but in the end they should make the decision based on the votes and comments as input. They should then report back to the general populace explaining the decision. Having used this approach elsewhere, I have found this quasi benign dictatorship, quasi democracy to be the best way of handling these processes. For all the reasons we are commenting on in this thread! --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Apr 24 2011
prev sibling next sibling parent Stephan <spam extrawurst.org> writes:
YES
Apr 19 2011
prev sibling next sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
I say yes.

I want to mention that I am a left a little skeptical about the lack of 
low-level race safety in this module, but I understand that this is 
more a language- or compiler-level problem than one with the module 
itself. I hope these problem will be addressed eventually and that 
std.parallelism can become safe that day.

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Apr 19 2011
next sibling parent dsimcha <dsimcha yahoo.com> writes:
== Quote from Michel Fortin (michel.fortin michelf.com)'s article
 I say yes.
 I want to mention that I am a left a little skeptical about the lack of
 low-level race safety in this module, but I understand that this is
 more a language- or compiler-level problem than one with the module
 itself. I hope these problem will be addressed eventually and that
 std.parallelism can become safe that day.

I **hope** so, too. I'm just more skeptical than you that it can be done, even in principle, without major sacrifices in terms of efficiency, expressiveness or flexibility.
Apr 19 2011
prev sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Michel Fortin (michel.fortin michelf.com)'s article
 I say yes.
 I want to mention that I am a left a little skeptical about the lack of
 low-level race safety in this module, but I understand that this is
 more a language- or compiler-level problem than one with the module
 itself. I hope these problem will be addressed eventually and that
 std.parallelism can become safe that day.

One other point about safety: D's flagship concurrency model doesn't hold your hand on high-level invariants, only low-level data races. Probably nothing will ever be able to hold your hand about high level invariants. With std.parallelism getting the high-level invariants (i.e. what has data dependencies and what doesn't) wrong can lead to low-level races, but as long as you get the high-level invariants right (only parallelize stuff without data dependencies) all the low level concurrency issues are taken care of and there can be no low-level data races.
Apr 19 2011
parent bearophile <bearophileHUGS lycos.com> writes:
dsimcha:

 Probably nothing will ever be able to hold your hand about high level
invariants.

Who knows? Probably there are papers with ideas about such problems. Bye, bearophile
Apr 19 2011
prev sibling next sibling parent Jesse Phillips <jessekphillips+D gmail.com> writes:
Lars T. Kyllingstad Wrote:

 As announced a week ago, the formal review process for David Simcha's 
 std.parallelism module is now over, and it is time to vote over whether 
 the module should be included in Phobos.  See below for more information 
 on the module and on previous reviews.
 
 Please vote in this thread, by replying with
 
   - "YES" if you think std.parallelism should be included in Phobos
     in its present form,
 
   - "NO" if you think it shouldn't.

Yes.
Apr 19 2011
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 19 Apr 2011 03:25:06 -0400, Lars T. Kyllingstad  
<public kyllingen.nospamnet> wrote:

 As announced a week ago, the formal review process for David Simcha's
 std.parallelism module is now over, and it is time to vote over whether
 the module should be included in Phobos.  See below for more information
 on the module and on previous reviews.

 Please vote in this thread, by replying with

   - "YES" if you think std.parallelism should be included in Phobos
     in its present form,

   - "NO" if you think it shouldn't.

YES. Note that I have no practical experience with the library or the concepts, but the docs look good enough and I trust David's abilities. -Steve
Apr 19 2011
prev sibling next sibling parent "Robert Jacques" <sandford jhu.edu> writes:
YES
Apr 19 2011
prev sibling next sibling parent Jonas Drewsen <jdrewsen nospam.com> writes:
YES
Apr 19 2011
prev sibling next sibling parent Mike Parker <aldacron gmail.com> writes:
YES
Apr 19 2011
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
YES
Apr 19 2011
prev sibling next sibling parent Sean Kelly <sean invisibleduck.org> writes:
YES
Apr 19 2011
prev sibling next sibling parent Mike Wey <mike-wey example.com> writes:
YES

-- 
Mike Wey
Apr 19 2011
prev sibling next sibling parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
Yes.

This module is a great example of the expressive powers of D.

Maybe it's too late for comments, but skipping over the documentation 
again, I think parallel foreach is the flagship of the module and the 
simplest concept to understand, so I would expect the example from 
parallel(R) to be shown in the synopsis.
Apr 19 2011
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
YES.
Apr 19 2011
prev sibling parent Fawzi Mohamed <fawzi gmx.ch> writes:
YES

it is a step in the right direction, I have ome comments, but I will  
put them in another thread
Apr 22 2011
prev sibling next sibling parent Hamad Mohammad <h.battel hotmail.com> writes:
YES
Apr 19 2011
prev sibling next sibling parent =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <ludwig informatik.uni-luebeck.de> writes:
YES
Apr 20 2011
prev sibling next sibling parent Graham Fawcett <fawcett uwindsor.ca> writes:
On Tue, 19 Apr 2011 07:25:06 +0000, Lars T. Kyllingstad wrote:

 As announced a week ago, the formal review process for David Simcha's
 std.parallelism module is now over, and it is time to vote over whether
 the module should be included in Phobos.  See below for more information
 on the module and on previous reviews.
 
 Please vote in this thread, by replying with
 
   - "YES" if you think std.parallelism should be included in Phobos
     in its present form,
 
   - "NO" if you think it shouldn't.

YES --Graham
Apr 21 2011
prev sibling next sibling parent Jonathan Crapuchettes <jcrapuchettes gmail.com> writes:
Yes
JC
Apr 21 2011
prev sibling next sibling parent "Simen kjaeraas" <simen.kjaras gmail.com> writes:
"YES"

-- 
Simen
Apr 25 2011
prev sibling parent "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
On Tue, 19 Apr 2011 07:25:06 +0000, Lars T. Kyllingstad wrote:

 As announced a week ago, the formal review process for David Simcha's
 std.parallelism module is now over, and it is time to vote over whether
 the module should be included in Phobos.  See below for more information
 on the module and on previous reviews.
 
 Please vote in this thread, by replying with
 
   - "YES" if you think std.parallelism should be included in Phobos
     in its present form,
 
   - "NO" if you think it shouldn't.
 
 Voting closes in one week, on 26 April, at 12:00 (noon) UTC.

I vote YES too, and use this opportunity to remind everyone that voting ends in less than 24 hours. -Lars
Apr 25 2011