Re: std.parallelism: VOTE IN THIS THREAD
YES -- Simen
Re: std.parallelism: VOTE IN THIS THREAD
On Tue, 19 Apr 2011 07:25:06 +, 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
Re: std.parallelism: VOTE IN THIS THREAD
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
Re: std.parallelism: VOTE IN THIS THREAD
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.
Re: std.parallelism: VOTE IN THIS THREAD
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. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: std.parallelism: VOTE IN THIS THREAD
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.
Re: std.parallelism: VOTE IN THIS THREAD
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 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. 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! -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: std.parallelism: VOTE IN THIS THREAD
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
Re: std.parallelism: VOTE IN THIS THREAD
YES it is a step in the right direction, I have ome comments, but I will put them in another thread
Re: std.parallelism: VOTE IN THIS THREAD
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
Re: std.parallelism: VOTE IN THIS THREAD
On Tue, 19 Apr 2011 07:25:06 +, 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
Re: std.parallelism: VOTE IN THIS THREAD
Yes JC
std.parallelism: VOTE IN THIS THREAD
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
Re: std.parallelism: VOTE IN THIS THREAD
YES -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: std.parallelism: VOTE IN THIS THREAD
YES -- Dmitry Olshansky
Re: std.parallelism: VOTE IN THIS THREAD
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
Re: std.parallelism: VOTE IN THIS THREAD
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
Re: std.parallelism: VOTE IN THIS THREAD
On Tue, Apr 19, 2011 at 5:49 AM, Jonathan M Davis jmdavisp...@gmx.com wrote: 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 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.
Re: std.parallelism: VOTE IN THIS THREAD
He's not hiding behind an alias, he made numerous blog posts here: http://leonardo-m.livejournal.com/ My vote is YES.
Re: std.parallelism: VOTE IN THIS THREAD
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
Re: std.parallelism: VOTE IN THIS THREAD
On Tue, Apr 19, 2011 at 7:11 AM, bearophile bearophileh...@lycos.com wrote: 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 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.
Re: std.parallelism: VOTE IN THIS THREAD
YES
Re: std.parallelism: VOTE IN THIS THREAD
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. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: std.parallelism: VOTE IN THIS THREAD
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.for...@michelf.com http://michelf.com/
Re: std.parallelism: VOTE IN THIS THREAD
== Quote from Michel Fortin (michel.for...@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.
Re: std.parallelism: VOTE IN THIS THREAD
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.
Re: std.parallelism: VOTE IN THIS THREAD
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
Re: std.parallelism: VOTE IN THIS THREAD
== Quote from Michel Fortin (michel.for...@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.
Re: std.parallelism: VOTE IN THIS THREAD
YES
Re: std.parallelism: VOTE IN THIS THREAD
YES
Re: std.parallelism: VOTE IN THIS THREAD
YES
Re: std.parallelism: VOTE IN THIS THREAD
YES
Re: std.parallelism: VOTE IN THIS THREAD
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
Re: std.parallelism: VOTE IN THIS THREAD
YES
Re: std.parallelism: VOTE IN THIS THREAD
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.
Re: std.parallelism: VOTE IN THIS THREAD
YES -- Mike Wey
Re: std.parallelism: VOTE IN THIS THREAD
YES
Re: std.parallelism: VOTE IN THIS THREAD
YES.
