Re: [boost] Proposal: Library to manage processes
I'm not replying to any particular reply to my original message because I want to address them all at once. First of all, I have started to write a little document listing all the requirements for the library. I'm focusing on my initial ideas and on all the interesting comments you've made. Then I need to learn more about Boost.Thread (mainly to see if its design could be appropriate to the process management library) and Boost.Iostreams (which should be used to ease handling input and output). Also it'll be worth to look at all the existing libraries you've mentioned. In fact, what I had in mind is quite simpler than what some people would like to see in the lib. But after reading your comments, I realize that it'd be worth to add the features you request. WRT my existing code... well, better forget about it (somebody asked for it, or at least some documentation regarding its interface). It is not worth using (I was going to refactor it anyway). Better to start the design from scratch, get it powerful and correct, and then implement it (which should be the easiest part). I'll let you know when I have a somewhat decent document that lists all the required features in detail as well as some design ideas to get some feedback. (Dunno when that'll be though; my time is probably going to be limited from now on...) Anyway, thanks for all your great comments! -- Julio M. Merino Vidal <jmmv84@gmail.com> http://www.livejournal.com/users/jmmv/ The NetBSD Project - http://www.NetBSD.org/
Julio M. Merino Vidal wrote:
I'll let you know when I have a somewhat decent document that lists all the required features in detail as well as some design ideas to get some feedback. (Dunno when that'll be though; my time is probably going to be limited from now on...)
Keep in mind that you only need to submit a very preliminary document to geneate further discussion. It's best to keep the discussion going while there are a number of people interested.
Anyway, thanks for all your great comments!
Jonathan
Jonathan Turkanis wrote:
Julio M. Merino Vidal wrote:
I'll let you know when I have a somewhat decent document that lists all the required features in detail as well as some design ideas to get some feedback. (Dunno when that'll be though; my time is probably going to be limited from now on...)
Keep in mind that you only need to submit a very preliminary document to geneate further discussion. It's best to keep the discussion going while there are a number of people interested.
Is there some way we have in this community to indicate a list of people interested in a certain topic? What I'd really like to do is say 'CC me whenever you post about this topic' but then thats sort of an unreasonable request. I get so much mail that I miss half of the stuff I'm interested in. Speaking of CC working correctly, it really annoys me how Reply-To partially altering neutralizes the usefulness of CC'ing. Aaron W. LaFramboise
----- Original Message ----- From: "Aaron W. LaFramboise" <aaronrabiddog51@aaronwl.com> To: <boost@lists.boost.org> Sent: Monday, February 21, 2005 11:31 PM Subject: Re: [boost] Re: Proposal: Library to manage processes
Jonathan Turkanis wrote:
Julio M. Merino Vidal wrote:
I'll let you know when I have a somewhat decent document that lists all the required features in detail as well as some design ideas to get some feedback. (Dunno when that'll be though; my time is probably going to be limited from now on...)
Keep in mind that you only need to submit a very preliminary document to geneate further discussion. It's best to keep the discussion going while there are a number of people interested.
Is there some way we have in this community to indicate a list of people interested in a certain topic?
What I'd really like to do is say 'CC me whenever you post about this topic' but then thats sort of an unreasonable request. I get so much mail that I miss half of the stuff I'm interested in.
I agree. Here are a few ideas I have: 1. One approach is to use the wiki. We could ask that new library proposals create a wiki page, and ask that those interested just add their name (or nickname) to a list on the wiki page. However, the wiki I find is hard to use and is aggressive with blocking (I am currently blocked!), so I don't love this approach 2. Another option is to set up a new mailing list for each new library discussions. This would help reduce noise on the main mailing list. This can be done relatively quickly and easily using google groups. 3. Have the mailing list enforce some kind of subject naming convention. For instance all future profiling library topics would arrive with the subject tagged with [boost][new][profiling] and all existing libraries would be tagged like [boost][old][mpl]. Clearly this is extra work for the moderators to assure that the naming convention is followed but it could really help eliminate noise, track topics, find messages, avoid redundancy, etc. There could also be web services created which sort the topics into RSS feeds. The third option is my favourite, but we would need to probably recruit more moderators. Which is not neccessarily a bad idea. I would be willing to volunteer to help if need be. -- Christopher Diggins Object Oriented Template Library (OOTL) http://www.ootl.org
christopher diggins wrote:
----- Original Message ----- From: "Aaron W. LaFramboise" <aaronrabiddog51@aaronwl.com>
I agree. Here are a few ideas I have:
1. One approach is to use the wiki. We could ask that new library proposals create a wiki page, and ask that those interested just add their name (or nickname) to a list on the wiki page. However, the wiki I find is hard to use and is aggressive with blocking (I am currently blocked!), so I don't love this approach
2. Another option is to set up a new mailing list for each new library discussions. This would help reduce noise on the main mailing list. This can be done relatively quickly and easily using google groups.
3. Have the mailing list enforce some kind of subject naming convention.
The third option is my favourite, but we would need to probably recruit more moderators. Which is not neccessarily a bad idea. I would be willing to volunteer to help if need be.
I think starting a mailing list with no moderators is the way to go. However, I think a bit more progress should be made here before the new list is started. Jonathan
On Tue, 22 Feb 2005 10:56:40 -0500, christopher diggins wrote
I agree. Here are a few ideas I have:
1. One approach is to use the wiki. We could ask that new library proposals create a wiki page, and ask that those interested just add their name (or nickname) to a list on the wiki page.
We discussed this at OOPSLA what I took away was that we should try to use the Wiki for this purpose. See: http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?OOPSLA2004/Wo... There has been a page on the Wiki to group these discussions for years, but since it isn't really maintained it doesn't help... http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?LibrariesUnde... I'd rather see a little effort from a group of people to improve what we have already done in the past.
However, the wiki I find is hard to use
The suggestion at OOPSLA was to remove the 'unofficial' labels and have more direct links from the main web site into the Wiki. For example, the Boost main page could have a direct link to the LibrariesUnderDiscussion.
and is aggressive with blocking (I am currently blocked!), so I don't love this approach
Sorry about that -- we've had a fairly active spammer community to combat. I administer the banned list -- it's possible that you got accidently included or you are on a dialup/internet provider that has been spamming the Wiki. In general the only way you get banned is if your IP address is responsible for posting SPAM on the Wiki. Please send me your primary IP address (Go to http://www.ipchicken.com/ and send me the name address) privately (jeff at crystalclearsoftware.com) and I'll update the banned list so you can access.
2. Another option is to set up a new mailing list for each new library discussions. This would help reduce noise on the main mailing list. This can be done relatively quickly and easily using google groups.
Sorry I can't agree with this approach. I'm already subscribed to 5 boost mailing lists and I can't imagine adding more everytime someone wants to add a new library. Also, part of the reason boost works is that all these libraries get floated and discussed on the main list. I can agree that some big libraries like sockets, etc might want to go off-list with a smaller sub-group. And really, there's nothing to stop you from just talking offlist with other boosters or setting up a list, but I would hate to see that for every new library that is discussed.
3. Have the mailing list enforce some kind of subject naming convention. For instance all future profiling library topics would arrive with the subject tagged with [boost][new][profiling] and all existing libraries would be tagged like [boost][old][mpl]. Clearly this is extra work for the moderators to assure that the naming convention is followed but it could really help eliminate noise, track topics, find messages, avoid redundancy, etc.
I see pretty good discipline already here. Most of the time I can spot and delete uninteresting threads without much trouble.
There could also be web services created which sort the topics into RSS feeds.
The third option is my favourite, but we would need to probably recruit more moderators. Which is not neccessarily a bad idea. I would be willing to volunteer to help if need be.
I don't want to wait for moderators to approve all the posts -- that would take forever even if we added a whole bunch. Also, I'd like to see us focus the majority of our time making C++ libraries better not enforcing list policies. Also, I think the current moderators do a good job of informing folks that don't post the library name in bug reports and such... Jeff
On Mon, 2005-02-21 at 13:43 -0700, Jonathan Turkanis wrote:
Julio M. Merino Vidal wrote:
I'll let you know when I have a somewhat decent document that lists all the required features in detail as well as some design ideas to get some feedback. (Dunno when that'll be though; my time is probably going to be limited from now on...)
Keep in mind that you only need to submit a very preliminary document to geneate further discussion. It's best to keep the discussion going while there are a number of people interested.
Ok, I've just created a section in the Boost Wiki to collect ideas for the library. http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostProcess It is quite preliminary, even though I've already included several of the suggestions made in this thread. Please feel free to add whatever you find missing or comment on the actual stuff. (Specially about the "stream merging stuff".) Cheers, PS: I started this using BoostBook to create this documentation, but it seems to be very difficult to use outside the boost build tree. Plus the wiki page is much more dynamic, easy to use and better to share comments. -- Julio M. Merino Vidal <jmmv84@gmail.com> http://www.livejournal.com/users/jmmv/ The NetBSD Project - http://www.NetBSD.org/
----- Original Message ----- From: "Julio M. Merino Vidal" <jmmv84@gmail.com> To: "Boost Development" <boost@lists.boost.org> Sent: Wednesday, February 23, 2005 2:14 PM Subject: Re: [boost] Re: Proposal: Library to manage processes
Julio M. Merino Vidal wrote: Ok, I've just created a section in the Boost Wiki to collect ideas for
On Mon, 2005-02-21 at 13:43 -0700, Jonathan Turkanis wrote: the library.
Great!
Please feel free to add whatever you find missing or comment on the actual stuff. (Specially about the "stream merging stuff".)
Well I am still on the fence whether I even want to use the wiki (I don't like the possibility of my comments being moved or erased), so I'll still make some comments here on the mailing list. I have some more comment operator overloading: I can sympathize with the desire to keep with tradition of shell notation, but in a programming language we have types which completely negates the need for three separate operators. In a shell, the three separate operators ( >, <, | ) are used by the shell to decide how to interpret the different arguments. However this is not needed in a (mostly) typed programming language like C++ because the type indicates how each symbol should behave in an expression. Writing code like: b | c > d < a; IMO just looks weird in C++ and is going to surprise everyone who is unfamiliar with traditional shell syntax, which is a very fast growing group of relatively young programmers who can't really be ignored. I see absolutely no reason to not move to something which is inherently more logical like: a > b > c > d Anyway, I am very pleased to see you taking the initiative on this project Julio. Christopher Diggins Object Oriented Template Library (OOTL) http://www.ootl.org
On Wed, 2005-02-23 at 14:52 -0500, christopher diggins wrote:
Well I am still on the fence whether I even want to use the wiki (I don't like the possibility of my comments being moved or erased), so I'll still make some comments here on the mailing list.
Ok; I'll summarize and add them to the page, as I did with the other mails. Hope it's ok with you. In fact, I think that it'd be good to keep it as a document rather than a repository for emails. That way, most of it could easily end up in the final BoostBook documentation.
I have some more comment operator overloading: I can sympathize with the desire to keep with tradition of shell notation, but in a programming language we have types which completely negates the need for three separate operators. In a shell, the three separate operators ( >, <, | ) are used by the shell to decide how to interpret the different arguments. However this is not needed in a (mostly) typed programming language like C++ because the type indicates how each symbol should behave in an expression.
Writing code like:
b | c > d < a;
IMO just looks weird in C++ and is going to surprise everyone who is unfamiliar with traditional shell syntax, which is a very fast growing group of relatively young programmers who can't really be ignored.
I see absolutely no reason to not move to something which is inherently more logical like:
a > b > c > d
Hmm indeed, much clearer. Any special reason about why you used the '>' operator in the example? I'm wondering if '|' could make sense (from the shell), although it doesn't implicitly reflect a "direction". Or what about '>>'? One could think of a process' pipeline as a stream (I think that would make sense if one considers the concepts of Source, Sink and Filter from Boost.Iostreams).
Anyway, I am very pleased to see you taking the initiative on this project Julio.
You're welcome. I'm quite motivated to work on this ATM, although my free time has radically decreased (got back to university this week). Anyway, I'll try to do what I can, but no promises. Cheers, -- Julio M. Merino Vidal <jmmv84@gmail.com> http://www.livejournal.com/users/jmmv/ The NetBSD Project - http://www.NetBSD.org/
On Wed, Feb 23, 2005 at 10:33:07PM +0100, Julio M. Merino Vidal wrote:
I see absolutely no reason to not move to something which is inherently more logical like:
a > b > c > d
Hmm indeed, much clearer. Any special reason about why you used the '>' operator in the example? I'm wondering if '|' could make sense (from the shell), although it doesn't implicitly reflect a "direction". Or what about '>>'? One could think of a process' pipeline as a stream (I think that would make sense if one considers the concepts of Source, Sink and Filter from Boost.Iostreams).
Except that writing to an ostream like this is not very intuitable: istream >> filter >> ostream I am used to writing to an ostream using operator<< not operator>> and expect the syntax above to extract something into "filter", then extract _something_else_ to "ostream", NOT the output of filter. I think '|' is the best choice: istream | filter | ostream This is consistent with shell syntax and not inconsistent with IOStreams. (that would be a valid shell command if "istream" == "cat < infile" and "ostream" == "cat > outfile" You don't need to duplicate the < and > shell redirections IMHO, they are simply adornments. "cat < infile" is identical to "cat infile" and "cat > outfile" could be written "cat -o outfile" if cat had a -o switch. jon
participants (6)
-
Aaron W. LaFramboise -
christopher diggins -
Jeff Garland -
Jonathan Turkanis -
Jonathan Wakely -
Julio M. Merino Vidal