digitalmars.D - std.parallelism: VOTE IN THIS THREAD
- "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> Apr 19 2011
- Russel Winder <russel russel.org.uk> Apr 19 2011
- Dmitry Olshansky <dmitry.olsh gmail.com> Apr 19 2011
- bearophile <bearophileHUGS lycos.com> Apr 19 2011
- Jonathan M Davis <jmdavisProg gmx.com> Apr 19 2011
- Caligo <iteronvexor gmail.com> Apr 19 2011
- bearophile <bearophileHUGS lycos.com> Apr 19 2011
- Andrej Mitrovic <andrej.mitrovich gmail.com> Apr 19 2011
- Caligo <iteronvexor gmail.com> Apr 19 2011
- Russel Winder <russel russel.org.uk> Apr 19 2011
- Bruno Medeiros <brunodomedeiros+spam com.gmail> Apr 21 2011
- lurker <lurk lurking.org> Apr 24 2011
- dsimcha <dsimcha yahoo.com> Apr 24 2011
- dsimcha <dsimcha yahoo.com> Apr 24 2011
- Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> Apr 24 2011
- Russel Winder <russel russel.org.uk> Apr 24 2011
- Russel Winder <russel russel.org.uk> Apr 24 2011
- Stephan <spam extrawurst.org> Apr 19 2011
- Michel Fortin <michel.fortin michelf.com> Apr 19 2011
- dsimcha <dsimcha yahoo.com> Apr 19 2011
- dsimcha <dsimcha yahoo.com> Apr 19 2011
- bearophile <bearophileHUGS lycos.com> Apr 19 2011
- Jesse Phillips <jessekphillips+D gmail.com> Apr 19 2011
- "Steven Schveighoffer" <schveiguy yahoo.com> Apr 19 2011
- "Robert Jacques" <sandford jhu.edu> Apr 19 2011
- Jonas Drewsen <jdrewsen nospam.com> Apr 19 2011
- Mike Parker <aldacron gmail.com> Apr 19 2011
- Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> Apr 19 2011
- Sean Kelly <sean invisibleduck.org> Apr 19 2011
- Mike Wey <mike-wey example.com> Apr 19 2011
- Rainer Schuetze <r.sagitario gmx.de> Apr 19 2011
- Timon Gehr <timon.gehr gmx.ch> Apr 19 2011
- Fawzi Mohamed <fawzi gmx.ch> Apr 22 2011
- Hamad Mohammad <h.battel hotmail.com> Apr 19 2011
- =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <ludwig informatik.uni-luebeck.de> Apr 20 2011
- Graham Fawcett <fawcett uwindsor.ca> Apr 21 2011
- Jonathan Crapuchettes <jcrapuchettes gmail.com> Apr 21 2011
- "Simen kjaeraas" <simen.kjaras gmail.com> Apr 25 2011
- "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> Apr 25 2011
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
== Quote from Michel Fortin (michel.fortin michelf.com)'s articleI 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
== Quote from Michel Fortin (michel.fortin michelf.com)'s articleI 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
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
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
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
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
YES it is a step in the right direction, I have ome comments, but I will put them in another thread
Apr 22 2011
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
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









Russel Winder <russel russel.org.uk> 