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:
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=


 have

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


g 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 vot=


ing

 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 reply 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
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=


 this topic, this is why I was not sure about voting. Feel free to ignore m=
y vote because of this.

 Regarding library development experience, alias problems, etc, they aren'=


t problems in this case.

 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 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 parent reply Russel Winder <russel russel.org.uk> writes:
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,
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,



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 reply Russel Winder <russel russel.org.uk> writes:
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=


=20

 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
parent reply 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
parent Russel Winder <russel russel.org.uk> writes:
On Sun, 2011-04-24 at 15:19 -0400, dsimcha wrote:
[ . . . ]

 I understand the points being made here, but I actually think votes from=


=20

 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=


=20

 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=


=20

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


=20

 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 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.




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 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
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
YES.
Apr 19 2011
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