FORMAL review of "Output Formatters" - results
Dear all, We got a lot of feedback relating the "Output Formatters" library [1]. "Yes" votes : 4 "No" votes: 2 "Abstain" votes: 2 Conclusions: - The docs and naming of the classes/functions could certainly be improved. - Seems a lot of people want this for pretty output, testing, debugging. - People don't need this library to provide ANY input facilities - quite a few people wanted a redesign. Thus, I wil consider this library "Pending Acceptation". In other words, it's considered Accepted by default, but since it will be redesigned, a new short review will take place. Reece will redesign the library, and a new formal review will take place within 3 months from now. This review will take less time - I assume 7 days. I will talk to Tom and Reece and schedule a next review date. Best, John [1] Just in case you still want a peek at the old code: http://www.torjo.com/code/outfmt.zip (153Kb) -- John Torjo, Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/ -- v1.5 - tooltips at your fingertips (work for menus too!) + bitmap buttons (work for MessageBox too!) + tab dialogs, hyper links, lite html
John Torjo <john.lists@torjo.com> writes:
Dear all,
We got a lot of feedback relating the "Output Formatters" library [1].
"Yes" votes : 4 "No" votes: 2 "Abstain" votes: 2
Conclusions: - The docs and naming of the classes/functions could certainly be improved. - Seems a lot of people want this for pretty output, testing, debugging. - People don't need this library to provide ANY input facilities - quite a few people wanted a redesign.
Thus, I wil consider this library "Pending Acceptation". In other words, it's considered Accepted by default, but since it will be redesigned, a new short review will take place.
I have no opinion whatsoever about the library's merits (I didn't look), but what you're describing here surprises me. The group's reception to the library seems from the vote to have been lukewarm at best and the library is going to be redesigned. Of course review managers have the perogative to render any verdict they like, and I don't know what "Accepted by default" is supposed to mean exactly, but it doesn't seem like an appropriate result given what was written above. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams wrote:
John Torjo <john.lists@torjo.com> writes:
Dear all,
We got a lot of feedback relating the "Output Formatters" library [1].
"Yes" votes : 4 "No" votes: 2 "Abstain" votes: 2
Conclusions: - The docs and naming of the classes/functions could certainly be improved. - Seems a lot of people want this for pretty output, testing, debugging. - People don't need this library to provide ANY input facilities - quite a few people wanted a redesign.
Thus, I wil consider this library "Pending Acceptation". In other words, it's considered Accepted by default, but since it will be redesigned, a new short review will take place.
I have no opinion whatsoever about the library's merits (I didn't look), but what you're describing here surprises me. The group's reception to the library seems from the vote to have been lukewarm at best and the library is going to be redesigned. Of course review managers have the perogative to render any verdict they like, and I don't know what "Accepted by default" is supposed to mean exactly, but it doesn't seem like an appropriate result given what was written above.
I take back "Accepted by default", since is a bit confusing, sorry for that. Here's what I mean: it's clear that people want such a library, and a lot of positive feedback was received. I know the library cannot be accepted at this time. Reece will redesign it, given the feedback and a new formal review will take place in about 3 months. Best, John -- John Torjo, Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/ -- v1.5 - tooltips at your fingertips (work for menus too!) + bitmap buttons (work for MessageBox too!) + tab dialogs, hyper links, lite html
John Torjo <john.lists@torjo.com> writes:
I take back "Accepted by default", since is a bit confusing, sorry for that.
Here's what I mean: it's clear that people want such a library, and a lot of positive feedback was received. I know the library cannot be accepted at this time.
I think the review process is close to as good as it can practically expected to be. In this particular case, I think that to small things sort of clouded the issue. a) The reference to the "vote" which over emphasizes the "voting" aspect. In the future I think it would be better to use the term "recommend" b) the "Accepted by default", I think this particular situation could have been handled better with "the library is not accepted at this time" reasons.... Robert Ramey
Sorry for quoting so much -- it all seems relevant. My suggestion for how to proceed is at the end. "John Torjo" <john.lists@torjo.com> wrote in message news:4178C5A6.4010703@torjo.com...
David Abrahams wrote:
John Torjo <john.lists@torjo.com> writes:
Dear all,
We got a lot of feedback relating the "Output Formatters" library [1].
"Yes" votes : 4 "No" votes: 2 "Abstain" votes: 2
Conclusions: - The docs and naming of the classes/functions could certainly be improved. - Seems a lot of people want this for pretty output, testing, debugging. - People don't need this library to provide ANY input facilities - quite a few people wanted a redesign.
Thus, I wil consider this library "Pending Acceptation". In other words, it's considered Accepted by default, but since it will be redesigned, a new short review will take place.
I have no opinion whatsoever about the library's merits (I didn't look), but what you're describing here surprises me. The group's reception to the library seems from the vote to have been lukewarm at best and the library is going to be redesigned. Of course review managers have the perogative to render any verdict they like, and I don't know what "Accepted by default" is supposed to mean exactly, but it doesn't seem like an appropriate result given what was written above.
I take back "Accepted by default", since is a bit confusing, sorry for that.
Here's what I mean: it's clear that people want such a library, and a lot of positive feedback was received. I know the library cannot be accepted at this time.
Reece will redesign it, given the feedback and a new formal review will take place in about 3 months.
Are you also taking back your suggestion that the 2nd review be abbreviated? It seems to me that the only reason to have a short 2nd review would be if some preliminary conclusions had been reached in the first review. If I recall correctly, there were at least 4 distinct ideas about how the library should be redsigned, with no clear preference for one alternative among participants in the review. If, as review manager, you believe there was enough consensus on certain issues or you decide independently that certain solutions are technically best, you should state this in the review result. Here are some of the open issues: - Since renaming is required, what should the new names be? - Should the library use locales and/or iword/qword? - Should the library be a lightweight facility for debugging or a full-flegded formatting facility which allows an object to be output in almost any possible way? "Gennadiy Rozental" <gennadiy.rozental@thomson.com> wrote:
I would like it on record that I disagree with this decision.<snip> I still not sure that problem domain doesn't warrant library at all.
At the just completed Redmond meeting, the library working group voted to remove tuple i/o from TR1, partly because of some difficulties with the specification. But there was unanimous agreement that some standard i/o facility is needed for all STL containers, and substantial support for a certain degree of customizability. Therefore, I think the best way to procede would be to develop two proposals, which might be combined into one library: 1. An ultra-lightweight version which could be a candidate for standardization, providing both input and output and minimal support for user customization. This version should work by overloading operator<< in namespace std, and be implementable with very little metaprogramming. 2. A highly-customizable framework for formatting more-or-less arbitrary types. This proposal might be seen as an inverse to Spirit. IMO, it's worth pursuing several of the ideas brought up during the review, to see how they compare. As much as I'd like to see this happen soon, I think three months is unrealistic. Best Regards, Jonathan
Reece will redesign it, given the feedback and a new formal review will take place in about 3 months.
Are you also taking back your suggestion that the 2nd review be abbreviated? It seems to me that the only reason to have a short 2nd review would be if some preliminary conclusions had been reached in the first review. If I recall
I will prefer an abbreviated review. Depending on how much feedback is received, I might choose to extend it.
correctly, there were at least 4 distinct ideas about how the library should be redsigned, with no clear preference for one alternative among participants in the review. If, as review manager, you believe there was enough consensus on certain issues or you decide independently that certain solutions are technically best, you should state this in the review result.
Here are some of the open issues: - Since renaming is required, what should the new names be?
Renaming can happen at a later time (not now, that is). It can also happen during the review. It's happened before. Also, this is relevant if the library is accepted.
- Should the library use locales and/or iword/qword? ^ pword, that is This is an implementation detail.
- Should the library be a lightweight facility for debugging or a full-flegded formatting facility which allows an object to be output in almost any possible way?
It should be an in-between.
I would like it on record that I disagree with this decision.<snip> I still not sure that problem domain doesn't warrant library at all.
At the just completed Redmond meeting, the library working group voted to remove tuple i/o from TR1, partly because of some difficulties with the specification. But there was unanimous agreement that some standard i/o facility is needed for all STL containers, and substantial support for a certain degree of customizability.
Therefore, I think the best way to procede would be to develop two proposals, which might be combined into one library:
1. An ultra-lightweight version which could be a candidate for standardization, providing both input and output and minimal support for user customization. This version should work by overloading operator<< in namespace std, and be implementable with very little metaprogramming.
For starters, I thinkg you should be able to use boost.serialize. Otherwise, I think something very trivial could be: - provide support to write an array, with delimeters (open, in-between, close). - provide support for writing a collection, with delimeters (open, in-between, close). This is very lightweight, and a constraint is that open != in-between and close != in-between (so that you can read back an array). You'll write things like: std::vector<int> v; v.push_back(1); v.push_back(3); v.push_back(4); std::cout << write(v, "[ %, % ]"); // [ 1, 3, 4 ] std::cin >> read(v, "[ %, % ]"); // read back std::cout << write(v, "[ %\n% ]"); // [ 1\n3\n4 ] A facility for escaping strings will also be needed. I will make some time later this week, and come up with a very lightweight version of this. (in the meanwhile, I'll also look at Rozental's implementation - maybe that's all we need) And just to make it clear once again: The "Output Formatters" library *should not* provide Input facilities (Reece, please take note!)
2. A highly-customizable framework for formatting more-or-less arbitrary types. This proposal might be seen as an inverse to Spirit. IMO, it's worth pursuing several of the ideas brought up during the review, to see how they compare. As much as I'd like to see this happen soon, I think three months is unrealistic.
It's so funny, during reviews, everyone comes up with his own better version of the reviewed library. Reece's lib has been in the sand-box for so long, and nobody said anything. I will talk to Reece, so that he'll update the docs showing how he wants to redesign his lib. If there's (negative) feedback, he'll update. If I were Reece, I'd go with a semi-highly-customizable lib at first, and once it's accepted, add more to it. And if 3 months is unrealistic, we'll postpone. Best, John -- John Torjo, Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/ -- v1.5 - tooltips at your fingertips (work for menus too!) + bitmap buttons (work for MessageBox too!) + tab dialogs, hyper links, lite html
John Torjo wrote:
Renaming can happen at a later time (not now, that is). It can also happen during the review. It's happened before. Also, this is relevant if the library is accepted.
- Should the library use locales and/or iword/qword? ^ pword, that is This is an implementation detail.
How? The difference between: locale::global(locale(), new vector_io_facet(.......)) and cout << vector_io_format(......) is in interface, not implementation.
I would like it on record that I disagree with this decision.<snip> I still not sure that problem domain doesn't warrant library at all.
At the just completed Redmond meeting, the library working group voted to remove tuple i/o from TR1, partly because of some difficulties with the specification. But there was unanimous agreement that some standard i/o facility is needed for all STL containers, and substantial support for a certain degree of customizability.
Therefore, I think the best way to procede would be to develop two proposals, which might be combined into one library:
1. An ultra-lightweight version which could be a candidate for standardization, providing both input and output and minimal support for user customization. This version should work by overloading operator<< in namespace std, and be implementable with very little metaprogramming.
For starters, I thinkg you should be able to use boost.serialize.
It's too large, for starters.
Otherwise, I think something very trivial could be: - provide support to write an array, with delimeters (open, in-between, close). - provide support for writing a collection, with delimeters (open, in-between, close).
This is very lightweight, and a constraint is that open != in-between and close != in-between (so that you can read back an array).
You'll write things like:
std::vector<int> v; v.push_back(1); v.push_back(3); v.push_back(4);
std::cout << write(v, "[ %, % ]"); // [ 1, 3, 4 ] std::cin >> read(v, "[ %, % ]"); // read back std::cout << write(v, "[ %\n% ]"); // [ 1\n3\n4 ]
A facility for escaping strings will also be needed.
I will make some time later this week, and come up with a very lightweight version of this. (in the meanwhile, I'll also look at Rozental's implementation - maybe that's all we need)
Hmm... are you about to write some code? Isn't this a bit contrary to review manager role -- he's supposed to be non involved in the development of the library that's being reviewed.
And just to make it clear once again: The "Output Formatters" library *should not* provide Input facilities (Reece, please take note!)
Now, I don't want to start a revolution, and I don't have anything against you in personal, but there are some points: 1. The library is rejected. Only another review can make it enter Boost. 2. We don't have a rule that re-review must be managed by the same person who managed the first review. We don't have any "library won't be re-reviewed unless do change this and that" resolution. So I don't think it's OK to require Reece to remove input facilities. I don't think input facilities caused any big problems, and we can't be sure they cause problems in a redesigned library. 3. It's a bit problematic that you start to take part in design discussion/development. And just for a record: I count 4 "no" votes for input (including yours) and 2 "yes", which means that 1/3 of all the users want this.
2. A highly-customizable framework for formatting more-or-less arbitrary types. This proposal might be seen as an inverse to Spirit. IMO, it's worth pursuing several of the ideas brought up during the review, to see how they compare. As much as I'd like to see this happen soon, I think three months is unrealistic.
It's so funny, during reviews, everyone comes up with his own better version of the reviewed library.
Reece's lib has been in the sand-box for so long, and nobody said anything.
I was using an alternative library from the same sandbox, for example. I'm not sure if Reece used to post a periodic preliminary versions.
I will talk to Reece, so that he'll update the docs showing how he wants to redesign his lib. If there's (negative) feedback, he'll update.
If I were Reece, I'd go with a semi-highly-customizable lib at first,
Ohh... what's "semi-highly-customizable"? The "highly-customizable" is vague itself, not to mention "semi" ;-) - Volodya
- Should the library use locales and/or iword/qword?
^ pword, that is This is an implementation detail.
How? The difference between:
locale::global(locale(), new vector_io_facet(.......))
and
cout << vector_io_format(......)
is in interface, not implementation.
What I meant was that you can have an interface similar to: set_format( std::cout, "[%,%]" /* or whatever */); In this case, whether the implementation uses locales or not can be an implementation detail. Of course, you can choose to make it part of the interface as well.
Hmm... are you about to write some code? Isn't this a bit contrary to review manager role -- he's supposed to be non involved in the development of the library that's being reviewed.
I assumed this to be a *different* lib (as Jonathan proposed). Certainly if you think it should be part of OutFmt lib, then I will _not_ write anything. In fact, I will step back, and _not_ write anything - period. The above was supposed to handle IO, while Reece's lib should handle Output-only.
And just to make it clear once again: The "Output Formatters" library *should not* provide Input facilities (Reece, please take note!)
Now, I don't want to start a revolution, and I don't have anything against you in personal, but there are some points:
1. The library is rejected. Only another review can make it enter Boost.
Yes
2. We don't have a rule that re-review must be managed by the same person who managed the first review. We don't have any "library won't be
True, sorry about that.
re-reviewed unless do change this and that" resolution. So I don't think
True.
it's OK to require Reece to remove input facilities. I don't think input
Fine, anyway, if he wants to provide them, it's his decision. Doing a recount of who whether input facilities are wanted or not - there were 4 votes for "No", 1 in-between (Paul Bristow), and 1 for "Yes"
3. It's a bit problematic that you start to take part in design discussion/development.
Fine, I will step back. Best, John -- John Torjo, Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/ -- v1.5 - tooltips at your fingertips (work for menus too!) + bitmap buttons (work for MessageBox too!) + tab dialogs, hyper links, lite html
John Torjo wrote:
How? The difference between:
locale::global(locale(), new vector_io_facet(.......))
and
cout << vector_io_format(......)
is in interface, not implementation.
What I meant was that you can have an interface similar to:
set_format( std::cout, "[%,%]" /* or whatever */);
In this case, whether the implementation uses locales or not can be an implementation detail.
You can't hide it completely -- you'll either have per-stream setting or global setting. - Volodya
What I meant was that you can have an interface similar to:
set_format( std::cout, "[%,%]" /* or whatever */);
In this case, whether the implementation uses locales or not can be an implementation detail.
You can't hide it completely -- you'll either have per-stream setting or global setting.
In the case I outlined, it would be per-stream. Best, John -- John Torjo, Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/ -- v1.5 - tooltips at your fingertips (work for menus too!) + bitmap buttons (work for MessageBox too!) + tab dialogs, hyper links, lite html
Ohh... what's "semi-highly-customizable"? The "highly-customizable" is vague itself, not to mention "semi" ;-)
This should be semi-vague ;) Best, John -- John Torjo, Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/ -- v1.5 - tooltips at your fingertips (work for menus too!) + bitmap buttons (work for MessageBox too!) + tab dialogs, hyper links, lite html
| -----Original Message----- | From: boost-bounces@lists.boost.org | [mailto:boost-bounces@lists.boost.org] On Behalf Of Peter Dimov | Sent: 25 October 2004 11:14 | To: boost@lists.boost.org | Subject: | | John Torjo wrote: | > | > It's so funny, during reviews, everyone comes up with his own better | > version of the reviewed library. For the proposer who has put in much work, it is not so funny ;-( | That's one of the reasons we have reviews, is it not? Better ideas are Boost's strength, but IMO review is the wrong time for radically better ideas - for they are often shooting from the hip, half-baked and in need of much more refinement. It seems wrong to me to have work which has been discussed and refined and tacitly used and accepted over a long time (necessarily waiting in the review queue) to be suddenly turned upside down at review, often by people who did not participate in the original discussions - a natural consquence of the quite rapid Boost membership turnover leading to 'Not Invented Here' syndrome. My impression is that many much needed things like formatting, big_integer, logging, units are not entering the library because of a search for perfection - largely unattainable as the invaluable filesystem library shows. (The Standard shows similar symptoms - there has been a desparate need for a 'typeof' since templates use started, for example, but there are no Standards, let alone implementations yet). For many problems, the Irishman's reply when asked for directions "Well I wouldn't start from here" applies: but we are committed to start from C++, multiple character sets, and a mishmash of incompatible operating systems - we have to find some one way, even if none are ideal. I agree with other would-be reviewers, that the time available and notice is too short, unless all we are to do is to finally dot is and cross the ts, and vote. Would a longer period of formally 'working on a proposal' be better? We would need to have a separate place for these 'under consideration' proposals (not files, not sandbox). So I foresee the process being: 1 Asking for interest. 2 Floating ideas and working on code. 3 Getting to a point where the submitter(s) feels that he(they) has something worth considering. 4 A 'Working on a definite proposal' period - a month perhaps. 5 Digesting input and revising, re-grouping, or abandoning, or going back to the drawing board. 5 Final formal review (a week) and vote. Paul Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539 561830 +44 7714 330204 mailto: pbristow@hetp.u-net.com
| John Torjo wrote: | > | > It's so funny, during reviews, everyone comes up with his own better | > version of the reviewed library.
For the proposer who has put in much work, it is not so funny ;-(
| That's one of the reasons we have reviews, is it not?
Better ideas are Boost's strength, but
IMO review is the wrong time for radically better ideas - for they are often shooting from the hip, half-baked and in need of much more refinement.
That's what I meant myself. Thanks Paul, I was beginning to think I was alone... Best, John -- John Torjo, Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/ -- v1.5 - tooltips at your fingertips (work for menus too!) + bitmap buttons (work for MessageBox too!) + tab dialogs, hyper links, lite html
John Torjo wrote:
John Torjo wrote:
It's so funny, during reviews, everyone comes up with his own better version of the reviewed library.
For the proposer who has put in much work, it is not so funny ;-(
That's one of the reasons we have reviews, is it not?
Better ideas are Boost's strength, but
IMO review is the wrong time for radically better ideas - for they are often shooting from the hip, half-baked and in need of much more refinement.
That's what I meant myself. Thanks Paul, I was beginning to think I was alone...
This shouldn't be a problem for a carefully designed and refined library. The submitter's typical response should be "Yes, I considered this, and rejected it because of X, Y, and Z."
Peter Dimov wrote:
John Torjo wrote:
John Torjo wrote: [...] IMO review is the wrong time for radically better ideas - for they are often shooting from the hip, half-baked and in need of much more refinement.
That's what I meant myself. Thanks Paul, I was beginning to think I was alone...
This shouldn't be a problem for a carefully designed and refined library. The submitter's typical response should be "Yes, I considered this, and rejected it because of X, Y, and Z."
I have to agree with Peter on this one. If there is a radically better idea for a library, it seems to me that a mature library would have a good reason for not taking that direction, or else the library author needs to go back to the drawing board and consider it. Dave
"Paul A Bristow" <pbristow@hetp.u-net.com> wrote in message news:E1CMlP9-0001xF-00@he200war.uk.vianw.net...
[snip]
IMO review is the wrong time for radically better ideas - for they are often shooting from the hip, half-baked and in need of much more refinement.
It's not the most ideal time, but isn't it always better late than never - at least for the truly radically better ideas ;-) Apart from that there might also be people who actually missed the original discussion.
It seems wrong to me to have work which has been discussed and refined and tacitly used and accepted over a long time (necessarily waiting in the review queue) to be suddenly turned upside down at review, often by people who did not participate in the original discussions - a natural consquence of the quite rapid Boost membership turnover leading to 'Not Invented Here' syndrome.
Could the NIH syndrome be diminished by easier accepting more people into the actual development process for a particular library? Ok, so I'm mostly a lurker here, but even so I believe I've seen people from time to time declaring their willingness to participate in developing a new library, without getting some real response. Take them in, let them be a part of the effort, and maybe the NIH problem will be lessened. I acknowledge that cooperating can be difficult, cooperating globally even more difficult, and that there will always be people that are in some ways "better" than other at developing software; be it due to talent, experience, intelligence, a feeling for the craft or whatever. Still I think that software developed by more than one person will generally be of better quality than the opposite (exceptions exist, of course). Reviews (formal or not) are good, but I think that it's hard to review the code to the same extension that you do while you're actually implementing the stuff.
[snip good ideas]
So I foresee the process being:
1 Asking for interest. 2 Floating ideas and working on code. 3 Getting to a point where the submitter(s) feels that he(they) has something worth considering. 4 A 'Working on a definite proposal' period - a month perhaps. 5 Digesting input and revising, re-grouping, or abandoning, or going back to the drawing board. 5 Final formal review (a week) and vote.
I'd like to explicitly add "Collect and document functional requirements" to the list, maybe at 1 1/2 above. Just my 0.02EUR. // Johan
Johan Nilsson wrote:
Could the NIH syndrome be diminished by easier accepting more people into the actual development process for a particular library? Ok, so
For me the NIH syndrome always implies a good amount of non-technical arguments, which are almost absent here. So, I don't think that the boost community actually suffers from NIH. It might suffer from over-perfectionism. However, I believe this is exactly the reason for the exceptional quality of the libraries and would therefore not want to change anything.
I'm mostly a lurker here, but even so I believe I've seen people from time to time declaring their willingness to participate in developing a new library, without getting some real response. Take them in, let them be a part of the effort, and maybe the NIH problem will be lessened.
I'm rather skeptical about that approach. Groups of similarly capable people are usually not very good at *designing* a library (unless there's a boss who has the last word on all the decisions). However, I think groups are unbeatable at uncovering design-flaws. So the best designs are initially often invented by an individual and the input later given by a group (users, boost-members, etc.) should then be used to refine until both sides are satisfied. Unfortunately, this puts most of the burden on the library submitter but I think it is the best process if you aim for high quality. Regards, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.
"Andreas Huber" <ahd6974-spamgroupstrap@yahoo.com> wrote in message news:cluamk$sa6$1@sea.gmane.org...
Johan Nilsson wrote:
Could the NIH syndrome be diminished by easier accepting more people into the actual development process for a particular library? Ok, so
For me the NIH syndrome always implies a good amount of non-technical arguments, which are almost absent here. So, I don't think that the boost community actually suffers from NIH. It might suffer from over-perfectionism. However, I believe this is exactly the reason for the exceptional quality of the libraries and would therefore not want to change anything.
I'm mostly a lurker here, but even so I believe I've seen people from time to time declaring their willingness to participate in developing a new library, without getting some real response. Take them in, let them be a part of the effort, and maybe the NIH problem will be lessened.
I'm rather skeptical about that approach. Groups of similarly capable people are usually not very good at *designing* a library (unless there's a boss who has the last word on all the decisions). However, I think groups are unbeatable at uncovering design-flaws. So the best designs are initially often invented by an individual and the input later given by a group (users, boost-members, etc.) should then be used to refine until both sides are satisfied. Unfortunately, this puts most of the burden on the library submitter but I think it is the best process if you aim for high quality.
Amen Robert Ramey
Robert Ramey wrote:
Amen
I don't think my post qualifies as a prayer or a sermon, so could you please enlighten me what you mean? Regards, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.
"Andreas Huber" <ahd6974-spamgroupstrap@yahoo.com> wrote in message news:cm0pft$odt$1@sea.gmane.org...
Robert Ramey wrote:
Amen
I don't think my post qualifies as a prayer or a sermon, so could you please enlighten me what you mean?
I am expressing agreement with your post just as I would for a sermon.
Regards,
-- Andreas Huber
When replying by private email, please remove the words spam and trap from the address shown in the header.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
"Andreas Huber" <ahd6974-spamgroupstrap@yahoo.com> writes:
I'm rather skeptical about that approach. Groups of similarly capable people are usually not very good at *designing* a library (unless there's a boss who has the last word on all the decisions). However, I think groups are unbeatable at uncovering design-flaws. So the best designs are initially often invented by an individual and the input later given by a group (users, boost-members, etc.) should then be used to refine until both sides are satisfied. Unfortunately, this puts most of the burden on the library submitter but I think it is the best process if you aim for high quality.
Yes. Boost emphasizes ownership by design, for that reason among others. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
"Andreas Huber" <ahd6974-spamgroupstrap@yahoo.com> wrote in message news:cluamk$sa6$1@sea.gmane.org...
Johan Nilsson wrote:
Could the NIH syndrome be diminished by easier accepting more people into the actual development process for a particular library? Ok, so
For me the NIH syndrome always implies a good amount of non-technical arguments, which are almost absent here. So, I don't think that the boost community actually suffers from NIH. It might suffer from over-perfectionism. However, I believe this is exactly the reason for the exceptional quality of the libraries and would therefore not want to change anything.
I'm mostly a lurker here, but even so I believe I've seen people from time to time declaring their willingness to participate in developing a new library, without getting some real response. Take them in, let them be a part of the effort, and maybe the NIH problem will be lessened.
I'm rather skeptical about that approach. Groups of similarly capable people are usually not very good at *designing* a library (unless there's a boss who has the last word on all the decisions).
So you mean that a single capable person beats a group of capable people? I realize that having a group of people trying to work out a design across the internet might not be feasible, but generally I still think that having a group of people together in the same room, preferrably at a white board, beats a single person. Having someone responsible that has the last word might be necessary anyway, but preferably only as a last resort. That should be possible here as well. It is much too easy locking yourself into a single mindset when you work alone at the drawing board. This is why I heartily supports the idea of discussing the design openly, collecting the feedback and ideas - before putting so much time into developing and refining the library that it feels like so much work has gone into the library that one doesn't wan't to give up the design. Just so that you don't misunderstand me, I know I discussed with you quite a lot about the fsm library but I'm definitely not pointing fingers anywhere specifically here. People must be allowed to defend their design decisions as well as people must be allowed to challenge them, IMHO.
However, I think groups are unbeatable at uncovering design-flaws.
True, OTOH it is much easier to find a design flaw than to generate a good, solid design.
So the best designs are initially often invented by an individual and the input later given by a group (users, boost-members, etc.) should then be used to refine until both sides are satisfied. Unfortunately, this puts most of the burden on the library submitter but I think it is the best process if you aim for high quality.
Perhaps. I recognize that my point of view is being out-numbered here. The process of taking the idea as early as possible to the newsgroup to collect requirements and implementation ideas still feels like a good idea. After this the "submitter" would stand a better chance of generating a good, perhaps easier accepted design and implementation. Best regards // Johan
Johan Nilsson wrote:
I'm mostly a lurker here, but even so I believe I've seen people from time to time declaring their willingness to participate in developing a new library, without getting some real response. Take them in, let them be a part of the effort, and maybe the NIH problem will be lessened.
I'm rather skeptical about that approach. Groups of similarly capable people are usually not very good at *designing* a library (unless there's a boss who has the last word on all the decisions).
So you mean that a single capable person beats a group of capable people?
No, not in general. I just think that intuition, IMO the primary ingredient in the initial design phase, isn't something that can easily be spread over multiple brains. You can surely collect requirements, opinions, etc. from a group, but I've never seen a coherent design spring from more than one mind at the same time.
I realize that having a group of people trying to work out a design across the internet might not be feasible, but generally I still think that having a group of people together in the same room, preferrably at a white board, beats a single person.
I've worked quite some time in so-called "architecture teams", where multiple people sitting in one room try to design something. In almost all cases, it was an individual who had a good idea and then convinced the rest of us. Sometimes, a good idea of one inidividual sparked an even better idea in another individual, but I've only seen that happening a couple of times. It is questionable whether the initial inventor wouldn't have had the better idea himself, only a little later, e.g. while working out the details.
It is much too easy locking yourself into a single mindset when you work alone at the drawing board. This is why I heartily supports the idea of discussing the design openly, collecting the feedback and ideas - before putting so much time into developing and refining the library that it feels like so much work has gone into the library that one doesn't wan't to give up the design.
I agree, that's why I think that an individual should work out a draft design all by himself and then present it to the group. After the group has responded she can go back and resolve the raised issues and refine the design. Depending on the complexity of the library, it usually takes several such rounds before the design is reasonably complete.
Just so that you don't misunderstand me, I know I discussed with you quite a lot about the fsm library but I'm definitely not pointing fingers anywhere specifically here. People must be allowed to defend their design decisions as well as people must be allowed to challenge them, IMHO.
Definitely, I hope my post did not make the opposite impression.
However, I think groups are unbeatable at uncovering design-flaws.
True, OTOH it is much easier to find a design flaw than to generate a good, solid design.
Agreed. Regards, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.
At Sunday 2004-10-31 04:36, you wrote:
[deleted]
However, I think groups are unbeatable at uncovering design-flaws.
True, OTOH it is much easier to find a design flaw than to generate a good, solid design.
Agreed.
if it's so much easier to find flaws, how come so many thing are released w/ so many flaws?
Regards,
Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"
"Victor A. Wagner Jr." <vawjr@rudbek.com> wrote in message news:6.1.2.0.2.20041031093821.048ac038@mail.rudbek.com...
At Sunday 2004-10-31 04:36, you wrote:
[deleted]
However, I think groups are unbeatable at uncovering design-flaws.
True, OTOH it is much easier to find a design flaw than to generate a good, solid design.
Agreed.
if it's so much easier to find flaws, how come so many thing are released w/ so many flaws?
Design or implementation flaws? // Johan
Victor A. Wagner Jr. wrote:
True, OTOH it is much easier to find a design flaw than to generate a good, solid design.
Agreed.
if it's so much easier to find flaws, how come so many thing are released w/ so many flaws?
I don't know, but I guess one factor is that it is much easier to identify a design flaw than to actually fix it. Also, there doesn't seem to be a consensus on what qualifies as a design flaw and what not. For example, despite the success of the STL a lot of people still seem to be happy with libraries that offer only runtime type safety (and require lots of casting), even if it is clear that an approach offering compile-time type safety is feasible. Regards, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.
"Andreas Huber" <ahd6974-spamgroupstrap@yahoo.com> wrote in message news:cm2io7$i7v$1@sea.gmane.org...
Johan Nilsson wrote:
I'm mostly a lurker here, but even so I believe I've seen people from time to time declaring their willingness to participate in developing a new library, without getting some real response. Take them in, let them be a part of the effort, and maybe the NIH problem will be lessened.
I'm rather skeptical about that approach. Groups of similarly capable people are usually not very good at *designing* a library (unless there's a boss who has the last word on all the decisions).
So you mean that a single capable person beats a group of capable people?
No, not in general. I just think that intuition, IMO the primary ingredient in the initial design phase, isn't something that can easily be spread over multiple brains. You can surely collect requirements, opinions, etc. from a group, but I've never seen a coherent design spring from more than one mind at the same time.
I must agree on the coherency stuff. Perhaps our definition of what should go into a *draft* design is what makes our opinions differ.
I realize that having a group of people trying to work out a design across the internet might not be feasible, but generally I still think that having a group of people together in the same room, preferrably at a white board, beats a single person.
I've worked quite some time in so-called "architecture teams", where multiple people sitting in one room try to design something.
(as a side-note: I'm not too fond of the term "architecture teams". Everyone should be allowed to be an architect, if they like to and can add some value to the process.) In almost
all cases, it was an individual who had a good idea and then convinced the rest of us. Sometimes, a good idea of one inidividual sparked an even better idea in another individual, but I've only seen that happening a couple of times. It is questionable whether the initial inventor wouldn't have had the better idea himself, only a little later, e.g. while working out the details.
It is much too easy locking yourself into a single mindset when you work alone at the drawing board. This is why I heartily supports the idea of discussing the design openly, collecting the feedback and ideas - before putting so much time into developing and refining the library that it feels like so much work has gone into the library that one doesn't wan't to give up the design.
I agree, that's why I think that an individual should work out a draft design all by himself and then present it to the group. After the group has responded she can go back and resolve the raised issues and refine the design. Depending on the complexity of the library, it usually takes several such rounds before the design is reasonably complete.
Again - what goes into a "design"? Must a draft design really include a fully compilable, usable library? Couldn't it just definition of concepts, overall design and suggestions for detailed implementation (perhaps proof-of-concept code where deemed necessary)? // Johan
Johan Nilsson wrote:
So you mean that a single capable person beats a group of capable people?
No, not in general. I just think that intuition, IMO the primary ingredient in the initial design phase, isn't something that can easily be spread over multiple brains. You can surely collect requirements, opinions, etc. from a group, but I've never seen a coherent design spring from more than one mind at the same time.
I must agree on the coherency stuff. Perhaps our definition of what should go into a *draft* design is what makes our opinions differ.
That could well be, see below.
I've worked quite some time in so-called "architecture teams", where multiple people sitting in one room try to design something.
(as a side-note: I'm not too fond of the term "architecture teams". Everyone should be allowed to be an architect, if they like to and can add some value to the process.)
Perhaps I need to clarify that those meetings took place only in the early stages of the project and all people that were involved in the project at that time were always invited (at those stages usually only a fraction of the later manpower was available). Later the architecture team existed only to take decisions on usually small stuff that cropped up or to review redesigns (because of requirements shift or because a particular design was found to scale badly).
I agree, that's why I think that an individual should work out a draft design all by himself and then present it to the group. After the group has responded she can go back and resolve the raised issues and refine the design. Depending on the complexity of the library, it usually takes several such rounds before the design is reasonably complete.
Again - what goes into a "design"? Must a draft design really include a fully compilable, usable library? Couldn't it just definition of concepts, overall design and suggestions for detailed implementation (perhaps proof-of-concept code where deemed necessary)?
That really depends on a number of factors. If the design involves stuff (details of the problem domain, programming techniques, etc.) that is not very well understood by most members of the reviewing group and/or the design will likely have an impact on a lot of code of the project then I usually insist on a proof-of-concept implementation complete with an implementation of a small real-world use-case. For a library where the focus, the implementation and the impact is much smaller there can well be a decision before a single line of code is written. Regards, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.
Personally I've a lot experience with the review process. The trick is to see the review process not as the beginning but the end of of the process. a) make available a useful package in the vault, sandbox and you're personal website b) make your package useful - even though it may be incomplete c) make sure it includes enough documentation so that its idiot - proof to use. This documentation has to include tutorial and examples so that an interested party can get utility from it right away. This also includes having it ready to paste into the users boost tree d) when related issues come up on the list - respond with postings to direct interested parties to your package This will give you certain benefits. i) You will get lots of feedback before the review ii) You will get lots more testing. iii) If you keep your documentation upto date you will already have a lot of questions/objections pre-answered before a formal review. This saves lots of time. My personal experience in a nutshell a) make library and post as above b) keep updated based on feed back from users c) draft #9 - reviewed by boost - and soundly rejected. d) after licking my wounds - reviewed the review and re-did the package according to he "new spec" e) draft #18 - reviewed by boost - accepted without dissent. The serializaton package was large than most (maybe than any other?) so this is sort of a worst case scenario. The main point is that the review is the culmination of a process. Most of the issues that come up should have come up earlier. The object of the above suggestion is to try to get as much as possible done in the pre-review stage. Also this addresses the issue of time available for a review. Review dates are announced well in advance so review time shouldn't be an issue. Robert Ramey (P.S.) I've not addresses post review acceptance issues even though they are non-trivial. RR "Peter Dimov" <pdimov@mmltd.net> wrote in message news:003c01c4ba7b$55765a60$6501a8c0@pdimov2...
John Torjo wrote:
It's so funny, during reviews, everyone comes up with his own better version of the reviewed library.
That's one of the reasons we have reviews, is it not? _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
"Robert Ramey" <ramey@rrsd.com> writes:
Personally I've a lot experience with the review process.
Yes; when and where is your excellent article about the experience going to come out? <good advice snipped> -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
I was wondering myself. I proposed the article around May, I got a response from the editor saying they were interested and would like to see it. I submitted the article around the end of august - I got no acknowledgememt. I sent an email message asking for acknknowledgement that it had been received. Still nothing. Finally I sent an email to an assistent and finally did get an acknowledgment that the article was received but have heard nothing since. If nothing happens soon we can put it somewhere in the boost web site. This would be sort of a pity as it was really targeted to a wider audience that might not be in the habit it tracking this kind of stuff on the net. We'll see what happens. Robert Ramey "David Abrahams" <dave@boost-consulting.com> wrote in message news:u8y9rjq1b.fsf@boost-consulting.com...
"Robert Ramey" <ramey@rrsd.com> writes:
Personally I've a lot experience with the review process.
Yes; when and where is your excellent article about the experience going to come out?
<good advice snipped>
-- Dave Abrahams Boost Consulting http://www.boost-consulting.com
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
"John Torjo" <john.lists@torjo.com> wrote in message news:417CD1ED.604@torjo.com...
Reece will redesign it, given the feedback and a new formal review will take place in about 3 months.
Are you also taking back your suggestion that the 2nd review be abbreviated? It seems to me that the only reason to have a short 2nd review would be if some preliminary conclusions had been reached in the first review. If I recall
I will prefer an abbreviated review. Depending on how much feedback is received, I might choose to extend it.
Okay.
correctly, there were at least 4 distinct ideas about how the library should be redsigned, with no clear preference for one alternative among participants in the review. If, as review manager, you believe there was enough consensus on certain issues or you decide independently that certain solutions are technically best, you should state this in the review result.
Here are some of the open issues: - Since renaming is required, what should the new names be?
Renaming can happen at a later time (not now, that is). It can also happen during the review. It's happened before. Also, this is relevant if the library is accepted.
I agree. I'm just pointing out that this issue was not resolved and therefore might be expected to take up some time during the second review.
- Should the library use locales and/or iword/qword? ^ pword, that is
Yes, pword ;-)
This is an implementation detail.
- Should the library be a lightweight facility for debugging or a full-flegded formatting facility which allows an object to be output in almost any
Agreed. But implementation details are an important subject for review discussions. possible
way?
It should be an in-between.
I would like it on record that I disagree with this decision.<snip> I still not sure that problem domain doesn't warrant library at all.
At the just completed Redmond meeting, the library working group voted to remove tuple i/o from TR1, partly because of some difficulties with the specification. But there was unanimous agreement that some standard i/o facility is needed for all STL containers, and substantial support for a certain degree of customizability.
Therefore, I think the best way to procede would be to develop two proposals, which might be combined into one library:
1. An ultra-lightweight version which could be a candidate for standardization, providing both input and output and minimal support for user customization. This version should work by overloading operator<< in namespace std, and be implementable with very little metaprogramming.
For starters, I thinkg you should be able to use boost.serialize.
As I stated in my review, I conceive of the output formatters library as an inverse to Spirit. I'n many cases loss of information is desirable, so there is no natural way to support input. However, I'm now proposing *in addition* a lightweight facility that could become part of the standard library. My impression from sitting in with the library working group is that both input and output would be desired for such a facility. While I admire Boost.Serialize very much, and might like to see it standardized, it's obviously not what is needed to fix the embarrassing lack of stream inserters and extractors for standard containers.
Otherwise, I think something very trivial could be: - provide support to write an array, with delimeters (open, in-between, close). - provide support for writing a collection, with delimeters (open, in-between, close).
This is very lightweight, and a constraint is that open != in-between and close != in-between (so that you can read back an array).
You'll write things like:
std::vector<int> v; v.push_back(1); v.push_back(3); v.push_back(4);
std::cout << write(v, "[ %, % ]"); // [ 1, 3, 4 ] std::cin >> read(v, "[ %, % ]"); // read back std::cout << write(v, "[ %\n% ]"); // [ 1\n3\n4 ]
A facility for escaping strings will also be needed.
I will make some time later this week, and come up with a very lightweight version of this. (in the meanwhile, I'll also look at Rozental's implementation - maybe that's all we need)
And just to make it clear once again: The "Output Formatters" library *should not* provide Input facilities (Reece, please take note!)
2. A highly-customizable framework for formatting more-or-less arbitrary types. This proposal might be seen as an inverse to Spirit. IMO, it's worth
I've written a sample implementation over the weekend which I'll post as soon as I have time to document it. Sample use: // pseudo code initialization: vector< list< pair<string, string> > > v = { { make_pair("hello", "goodbye"), make_pair("morning", "evening"), make_pair("cold", "hot") }, { make_pair("hello", "goodbye"), make_pair("morning", "evening"), make_pair("cold", "hot") } }; int flags = punc::indent_after_open | punc::break_after_sep; cout << punctuate< vector<_> >("[", ",", "]", flags) << punctuate< list<_> >("{", ",", "}", flags) << punctuate< pair<_, _> >("(", ":", ")") << v << "\n"; Output: [ { (hello:goodbye), (morning:evening), (cold:hot) }, { (hello:goodbye), (morning:evening), (cold:hot) } ] It provides input and output, but no string-escaping (yet). Right now, a string is regarded to be complete as soon as an appropriate punctuaion sequence is encountered. pursuing
several of the ideas brought up during the review, to see how they compare. As much as I'd like to see this happen soon, I think three months is unrealistic.
It's so funny, during reviews, everyone comes up with his own better version of the reviewed library.
Reece's lib has been in the sand-box for so long, and nobody said anything.
I hope you're not directing this remark at me. I've worked with Reece on his library since before it was in the sandbox. Early on I sent him some sketches of my ideas for his library, and was hoping to produce a sample implementation. Unfortunately, I got too busy.
Best, John
Jonathan
As I stated in my review, I conceive of the output formatters library as an inverse to Spirit. I'n many cases loss of information is desirable, so there is
Yes, I agree.
no natural way to support input. However, I'm now proposing *in addition* a lightweight facility that could become part of the standard library. My impression from sitting in with the library working group is that both input and output would be desired for such a facility. While I admire Boost.Serialize very
I agree with you, but since this should be a very lightweight facility, it is my impression that it should be a different lib altogether.
I've written a sample implementation over the weekend which I'll post as soon as I have time to document it. Sample use:
// pseudo code initialization: vector< list< pair<string, string> > > v = { { make_pair("hello", "goodbye"), make_pair("morning", "evening"), make_pair("cold", "hot") }, { make_pair("hello", "goodbye"), make_pair("morning", "evening"), make_pair("cold", "hot") } };
int flags = punc::indent_after_open | punc::break_after_sep;
cout << punctuate< vector<_> >("[", ",", "]", flags) << punctuate< list<_> >("{", ",", "}", flags) << punctuate< pair<_, _> >("(", ":", ")") << v << "\n";
Output:
[ { (hello:goodbye), (morning:evening), (cold:hot) }, { (hello:goodbye), (morning:evening), (cold:hot) } ]
It provides input and output, but no string-escaping (yet). Right now, a string is regarded to be complete as soon as an appropriate punctuaion sequence is encountered.
It's a good start ;)
I hope you're not directing this remark at me. I've worked with Reece on his library since before it was in the sandbox. Early on I sent him some sketches of my ideas for his library, and was hoping to produce a sample implementation. Unfortunately, I got too busy.
no, it was not directed at you Best, John -- John Torjo, Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/ -- v1.5 - tooltips at your fingertips (work for menus too!) + bitmap buttons (work for MessageBox too!) + tab dialogs, hyper links, lite html
John Torjo wrote:
David Abrahams wrote:
John Torjo <john.lists@torjo.com> writes: Here's what I mean: it's clear that people want such a library, and a lot of positive feedback was received. I know the library cannot be accepted at this time.
Reece will redesign it, given the feedback and a new formal review will take place in about 3 months.
I have been working on the library and have got a local reimplementation of it based on the review comments. There are still a few issues that need to be resolved and I would like to expand stream state support. I have created a preliminary evolution document available at: http://uk.geocities.com/msclrhd/iocoll/evolution.html that outlines what the new functionality looks like. This redesign addresses several of the issues brought up during the review. Regards, Reece
Somewhere in the E.U., le 28/10/2004 Bonjour In article <417FDD22.2030507@hotmail.com>, Reece Dunn <msclrhd@hotmail.com> wrote:
John Torjo wrote:
David Abrahams wrote:
John Torjo <john.lists@torjo.com> writes: Here's what I mean: it's clear that people want such a library, and a lot of positive feedback was received. I know the library cannot be accepted at this time.
Reece will redesign it, given the feedback and a new formal review will take place in about 3 months.
I have been working on the library and have got a local reimplementation of it based on the review comments. There are still a few issues that need to be resolved and I would like to expand stream state support.
I have created a preliminary evolution document available at: http://uk.geocities.com/msclrhd/iocoll/evolution.html that outlines what the new functionality looks like. This redesign addresses several of the issues brought up during the review.
Regards, Reece
Looks good. One point perhaps: introduce "decorate" (say what it does) before using it. Merci Hubert Holin
| -----Original Message----- | From: boost-bounces@lists.boost.org | [mailto:boost-bounces@lists.boost.org] On Behalf Of David Abrahams | Sent: 21 October 2004 19:40 | To: boost@lists.boost.org | Subject: [boost] Re: FORMAL review of "Output Formatters" - results | | > We got a lot of feedback relating the "Output Formatters" library [1]. | > "Yes" votes : 4 | > "No" votes: 2 | > "Abstain" votes: 2 | > Thus, I wil consider this library "Pending Acceptation". In other | > words, it's considered Accepted by default, but since it will be | > redesigned, a new short review will take place. | | I have no opinion whatsoever about the library's merits (I didn't | look), but what you're describing here surprises me. The group's | reception to the library seems from the vote to have been lukewarm at | best and the library is going to be redesigned. Of course review | managers have the perogative to render any verdict they like, and I | don't know what "Accepted by default" is supposed to mean exactly, but | it doesn't seem like an appropriate result given what was written | above. I am concerned that this shows again that the review process is not working well. We are not getting enough reviewers and we are getting Boosters input far too late. The number of reviewers is often, as here, far too small for the votes to be statistically significant, and IMO a negative impression is often caused by a few vociferous objectors, whose views I doubt are representative. We need far more input from the 'lurkers'. As a group we are only really getting to grips with submissions at the review stage. This is the stage when we should only be concerned with a few final details, but in too many cases major re-designs are proposed, even when previously there had been general agreement about the desirability and overall structure. I see a chicken and egg problem here. Stuff is not subjected to the real review - widespread user acceptance - until it is in the Boost library. But much useful stuff isn't getting that far. (The poor accessibility of both the 'files area' and 'CVS area' doesn't help - I note that much stuff is now being made visible on assorted private web sites). It is most unreasonable to expect submitters to perfect both code, and especially documentation, unless they are confident of ultimate acceptance. In practice, many submissions are not really refined until after acceptance. For example, Jeff Garland's invaluable date-time system. Much of the refinement has come from user use-in-anger experience, not from the review process itself: that only established that it was a good starting point. Most reviews recommending acceptance end with provisos. Can suggest again that we split the process into two stages: 1 Acceptance in principle - as suggested by the review leader in this case. 2 Final acceptance for the next release. Paul Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539 561830 +44 7714 330204 mailto: pbristow@hetp.u-net.com
"Paul A Bristow" <pbristow@hetp.u-net.com> writes:
We need far more input from the 'lurkers'.
As a group we are only really getting to grips with submissions at the review stage. This is the stage when we should only be concerned with a few final details, but in too many cases major re-designs are proposed, even when previously there had been general agreement about the desirability and overall structure.
I see a chicken and egg problem here. Stuff is not subjected to the real review - widespread user acceptance - until it is in the Boost library. But much useful stuff isn't getting that far. (The poor accessibility of both the 'files area' and 'CVS area' doesn't help - I note that much stuff is now being made visible on assorted private web sites).
It is most unreasonable to expect submitters to perfect both code, and especially documentation, unless they are confident of ultimate acceptance.
In practice, many submissions are not really refined until after acceptance. For example, Jeff Garland's invaluable date-time system. Much of the refinement has come from user use-in-anger experience, not from the review process itself: that only established that it was a good starting point.
I agree with your analysis of many of the problems...
Most reviews recommending acceptance end with provisos.
Can suggest again that we split the process into two stages:
1 Acceptance in principle - as suggested by the review leader in this case.
2 Final acceptance for the next release.
...but I don't see how this will help. Quite the opposite in fact. It seems as though we'll be likely to "accept in principle" a library that needs a redesign, and that will set up the expectation that the as-yet-unknown library design should be accepted with little scrutiny. I don't think I want to have any kind of even semi-official stamp of approval on a library that we shouldn't actually accept. The preliminary review process, if people actually go through it, is self-selecting for formal reviews. If only a very small group is interested in the design, it is likely not to be pursued further. If many are interested but the design is controversial, it's likely to be redesigned. It's my sense that too many people are reaching for the "glory" (such as it is) of an accepted library without going through the earlier stages. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams <dave@boost-consulting.com> writes:
...but I don't see how this will help. Quite the opposite in fact. It seems as though we'll be likely to "accept in principle" a library that needs a redesign, and that will set up the expectation that the as-yet-unknown library design should be accepted with little scrutiny. I don't think I want to have any kind of even semi-official stamp of approval on a library that we shouldn't actually accept.
The preliminary review process, if people actually go through it, is self-selecting for formal reviews. If only a very small group is interested in the design, it is likely not to be pursued further. If many are interested but the design is controversial, it's likely to be redesigned. It's my sense that too many people are reaching for the "glory" (such as it is) of an accepted library without going through the earlier stages.
Perhaps part of the answer is to give the reviewers more glory. One way to give the reviewers more glory is to create a "Boost Reviewers" page similar to the "Boost people" page. Another is to add the list of reviewers to the documentation for each library after it is accepted (some documentation does this, but some does not). Robert Zeh http://home.earthlink.net/~rzeh
Robert Zeh wrote:
[...] Perhaps part of the answer is to give the reviewers more glory. One way to give the reviewers more glory is to create a "Boost Reviewers" page similar to the "Boost people" page. Another is to add the list of reviewers to the documentation for each library after it is accepted (some documentation does this, but some does not).
Or maybe the review manager should set a number of required reviews before the review period starts, based on the size and complexity of the library. If there are not enough reviews, then the library is automatically rejected. Dave
$0.02 on formal reviews, from someone who has been on the list for a little while, but has not contributed anything to the evolution of the library. The biggest obstacle for me in participating in the formal review process is time. I think the review timeframe is too small. I would much rather have two or three reviews overlap by a week or so, with each review having an extended time period. I doubt many of us have the time or expertise to participate in all reviews. However, there are occasions where we may have significant input. I believe I could have contributed in a non trivial manner to several reviews. However, by the time I see the announcement, download the materials, go through them, and try to keep up with the current comments, the review is over. I am so busy with work, family, coaching (American) football, and other activities, that the review periods usually seem too short (for me, at least). As a result, by the time I am ready to give input, the review is over. I do not care about the recognition aspect, as that would have no bearing on my contributions. For me, time is the critical component, and I just do not think the current timeframes are sufficient.
Jody Hagins wrote:
I believe I could have contributed in a non trivial manner to several reviews. However, by the time I see the announcement, download the materials, go through them, and try to keep up with the current comments, the review is over. I am so busy with work, family, coaching (American) football, and other activities, that the review periods usually seem too short (for me, at least).
This is also true for me. However, I think the review periods do not necessarily have to be extended. What has to be extended is the timeframe in which there will be no significant changes (interface & docs) to a candidate library. Libraries sometimes go through extensive changes right before the reviews start, which is probably the reason why people don't have a look beforehand. Maybe the review process should mandate a no-interface-and-docs-changes period of one month before the actual formal review starts, with announcements when this period begins? Regards, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.
reviews. However, by the time I see the announcement, download the materials, go through them, and try to keep up with the current comments, the review is over. I am so busy with work...
This is also true for me. However, I think the review periods do not necessarily have to be extended. What has to be extended is the timeframe in which there will be no significant changes (interface & docs) to a candidate library.
I have the same issues (work getting busy just at the time of an interesting review), and I think this is a good solution. It still keeps the good concentrated discussion during the review period, but gives more people time to take a proper look. I'd also like to see a policy where the docs are on the web somewhere so I can click-and-skim the tutorial or examples to see if the library solves a problem I have and is therefore worth downloading and trying out. Darren
From: "Andreas Huber" <ahd6974-spamgroupstrap@yahoo.com>
Jody Hagins wrote:
I believe I could have contributed in a non trivial manner to several reviews. However, by the time I see the announcement, download the materials, go through them, and try to keep up with the current comments, the review is over. I am so busy with work, family, coaching (American) football, and other activities, that the review periods usually seem too short (for me, at least).
This is also true for me. However, I think the review periods do not necessarily have to be extended. What has to be extended is the timeframe in which there will be no significant changes (interface & docs) to a candidate library. Libraries sometimes go through extensive changes right before the reviews start, which is probably the reason why people don't have a look beforehand. Maybe the review process should mandate a no-interface-and-docs-changes period of one month before the actual formal review starts, with announcements when this period begins?
Time is always a problem, and we most definitely need time to evaluate new libraries. The question is, when should the time be invested? I first notice new libraries when their formal review is announced. I may well have been part of design discussions along the way, but I won't have stopped to read through the documentation or code before the formal review. Thus, one or two weeks to do that and be part of an ongoing, often raging, discussion about the new library is demanding. To require N favorable reviews of a library before it can be submitted for list-wide review is questionable only because so much time will have elapsed between those reviews (due to the current backlog). Granted, you want to know that more than just the author think the library is good before putting it before the list, so such reviews seem obligatory. Perhaps the answer is that N reviews must be garnered for a library to be reviewed, and the formal review period can begin almost immediately thereafter -- subject to throttling. Then, there could be a review period of, say, a month, following which, the review manager can summarize the activity and determine subsequent actions. Yes, reviews can be really long that way and, as has been said, the code and documentation must not change during that period (though the author can, of course, maintain a separate development version as the review progresses). However, it would enable more people to review the libraries and would enable deeper reviews when warranted. The obvious problem is the number of simultaneous reviews that could be ongoing at a given point. I think that will only prove to be a problem initially as there are many libraries queued to be reviewed. Once the backlog is gone, there won't be so many new libraries to come on the scene as to make the review task onerous. Having more simultaneous reviews might be easier for some, too, as they might have a particular day available to conduct reviews, so several could be hammered out that day. With the current state, one can only conduct a single review on such an occasion. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
Yep, I second that too - too little time to familiarize oneself with a proposal, the work, and associated postings to contribute meanigfully within the alloted timeframes. my $0.02, Manfred Doudar MetOcean Engineers Jody Hagins wrote:
$0.02 on formal reviews, from someone who has been on the list for a little while, but has not contributed anything to the evolution of the library.
The biggest obstacle for me in participating in the formal review process is time. I think the review timeframe is too small. I would much rather have two or three reviews overlap by a week or so, with each review having an extended time period. I doubt many of us have the time or expertise to participate in all reviews. However, there are occasions where we may have significant input.
I believe I could have contributed in a non trivial manner to several reviews. However, by the time I see the announcement, download the materials, go through them, and try to keep up with the current comments, the review is over. I am so busy with work, family, coaching (American) football, and other activities, that the review periods usually seem too short (for me, at least).
As a result, by the time I am ready to give input, the review is over. I do not care about the recognition aspect, as that would have no bearing on my contributions. For me, time is the critical component, and I just do not think the current timeframes are sufficient.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Jody Hagins wrote:
I believe I could have contributed in a non trivial manner to several reviews. However, by the time I see the announcement, download the materials, go through them, and try to keep up with the current comments, the review is over. I am so busy with work, family, coaching (American) football, and other activities, that the review periods usually seem too short (for me, at least).
For me, its something of a personal investment to take the time to get to know a new library, one that isn't always easy. I think it would help if, as part of the beginning of the review process, there was a document that offered a quick tour of everything I'd need to know to review the library, interfaces to source code to rationale. The blurb that comes in the review notice isn't enough, and the tutorials in the documentation aren't really the same information I'd like to see as a reviewer. Aaron W. LaFramboise
Conclusions: - The docs and naming of the classes/functions could certainly be improved. - Seems a lot of people want this for pretty output, testing, debugging. - People don't need this library to provide ANY input facilities - quite a few people wanted a redesign.
Thus, I wil consider this library "Pending Acceptation". In other words, it's considered Accepted by default, but since it will be redesigned, a new short review will take place.
Reece will redesign the library, and a new formal review will take place within 3 months from now. This review will take less time - I assume 7 days.
I will talk to Tom and Reece and schedule a next review date.
I would like it on record that I disagree with this decision. I believe this submission not only did not show boost level design and implementation, I still not sure that problem domain doesn't warrant library at all. Regards, Gennadiy.
Somewhere in the E.U., le 22/10/2004 Bonjour In article <41779260.6020709@torjo.com>, John Torjo <john.lists@torjo.com> wrote:
Dear all,
We got a lot of feedback relating the "Output Formatters" library [1].
"Yes" votes : 4 "No" votes: 2 "Abstain" votes: 2
Conclusions: - The docs and naming of the classes/functions could certainly be improved. - Seems a lot of people want this for pretty output, testing, debugging. - People don't need this library to provide ANY input facilities - quite a few people wanted a redesign.
I had intended to provide feedback on that library, but once again and unfortunately did not have time to do so. I just wanted to point out that the reason I was interested in it is that I had been told (when it was in the sandbox, quite some time before the review) it had the potential to help me simplify tremendously my quaternion and, especially, octonion libraries, by providing a better handling of input operators. So I would say (better late than never, though perhaps it is now *too* late) that there actually *is* an interest in input facilities.
Thus, I wil consider this library "Pending Acceptation". In other words, it's considered Accepted by default, but since it will be redesigned, a new short review will take place.
Reece will redesign the library, and a new formal review will take place within 3 months from now. This review will take less time - I assume 7 days.
I will talk to Tom and Reece and schedule a next review date.
Best, John
[1] Just in case you still want a peek at the old code: http://www.torjo.com/code/outfmt.zip (153Kb)
Merci Hubert Holin
I just wanted to point out that the reason I was interested in it is that I had been told (when it was in the sandbox, quite some time before the review) it had the potential to help me simplify tremendously my quaternion and, especially, octonion libraries, by providing a better handling of input operators. So I would say (better late than never, though perhaps it is now *too* late) that there actually *is* an interest in input facilities.
can't [serialize] do that? Best, John -- John Torjo, Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/ -- v1.5 - tooltips at your fingertips (work for menus too!) + bitmap buttons (work for MessageBox too!) + tab dialogs, hyper links, lite html
Somewhere in the E.U., le 25/10/2004 Bonjour In article <41795193.2000906@torjo.com>, John Torjo <john.lists@torjo.com> wrote:
I just wanted to point out that the reason I was interested in it is that I had been told (when it was in the sandbox, quite some time before the review) it had the potential to help me simplify tremendously my quaternion and, especially, octonion libraries, by providing a better handling of input operators. So I would say (better late than never, though perhaps it is now *too* late) that there actually *is* an interest in input facilities.
can't [serialize] do that?
Best, John
It is not immediately clear if [serialize] can do that in any way which is simpler to implement than what I already do for these classes (i.e. it would likely be as disgusting and unmaintainable, however necessary). The "out"put Formatter library, however, seemed to be able to process a structured list (with possible shortened forms) with minimal hassle. For instance, I want to accept "(1, 2)", "(1, 2, 3, 4)" and "((1, 2), (3, 4))" as valid quaternions but not "((1, 2), 3, 4)" (quotes to help in the reading of the text, not part of the syntax). My initial idea was to use Spririt to build a formal description of the format, but that would have been overkill if a more lightweight library such as "out"put Formatters had been available (and provided it did actually fit the bill, which I *still* did not manage to find the time to test :-< ). Cordialement Hubert Holin
"Hubert Holin" <Hubert.Holin@meteo.fr> wrote in message news:Hubert.Holin-89E7B0.14253525102004@sea.gmane.org...
It is not immediately clear if [serialize] can do that in any way which is simpler to implement than what I already do for these classes (i.e. it would likely be as disgusting and unmaintainable, however necessary).
I don't think there is any factual support for that statement. As a counter example, The following code includes implementation of serialization for the quaternion class template (17 lines of code) and a test of its serialization. I only spent an hour on it ( most of which was perusing the quaternion docs and code so it might benefit from more effort and testing than I am in a position to invest. But I would hope that it does illustrate how easy it is to serialize what might seem to be an otherwise complex type. I would hope it also will help to refute the perception that the serialization library is "too big". I don't believe that serialization adds any more code (source and/or object) to an project than any comparable alternative method. For example, the i/o code built into the the quaternion class contains 329 lines of templated code. And, it doesn't include any facilities that come for free with serialization libary such as the ability to create archives of different types included XML, binary etc. It is also pure template code that doesn't factor out commonality into a separart module so I would expect to to be more "too big" than the equivalent of the serializaition library. Robert Ramey begin 666 test_quaternion.cpp M+R\O+R\O+R\O,2\O+R\O+R\O+S(O+R\O+R\O+R\S+R\O+R\O+R\O-"\O+R\O M+R\O+S4O+R\O+R\O+R\V+R\O+R\O+R\O-R\O+R\O+R\O+S@-"B\O('1E<W1? M<75A=&5R;FEO;BYC<' -"@T*+R\@*$,I($-O<'ER:6=H=" R,# R(%)O8F5R M="!286UE>2 M(&AT=' Z+R]W=W<N<G)S9"YC;VT@+B -"B\O(%5S92P@;6]D M:69I8V%T:6]N(&%N9"!D:7-T<FEB=71I;VX@:7,@<W5B:F5C="!T;R!T:&4@ M0F]O<W0@4V]F='=A<F4-"B\O($QI8V5N<V4L(%9E<G-I;VX@,2XP+B H4V5E M(&%C8V]M<&%N>6EN9R!F:6QE($Q)0T5.4T5?,5\P+G1X="!O<B!C;W!Y(&%T M#0HO+R!H='1P.B\O=W=W+F)O;W-T+F]R9R],24-%3E-%7S%?,"YT>'0I#0H- M"B\O(&EM<&QE;65N=&%T:6]N(&%N9"!T97-T(&]F('-E<FEA;&EZ871I;VX@ M9F]R('%U871E<FYI;VX@;&EB87)Y+@T*#0HC:6YC;'5D92 \9G-T<F5A;3X- M"@T*(VEN8VQU9&4@/&-S=&1I;SX@+R\@<F5M;W9E#0HC:6YC;'5D92 \8F]O M<W0O8V]N9FEG+FAP<#X-"B-I9B!D969I;F5D*$)/3U-47TY/7U-41$-?3D%- M15-004-%*0T*;F%M97-P86-E('-T9'L@#0H@(" @=7-I;F<@.CIR96UO=F4[ M#0I]#0HC96YD:68-"@T*(VEN8VQU9&4@/&)O;W-T+W-E<FEA;&EZ871I;VXO M;G9P+FAP<#X-"@T*+R\O+R\O+R\O,2\O+R\O+R\O+S(O+R\O+R\O+R\S+R\O M+R\O+R\O-"\O+R\O+R\O+S4O+R\O+R\O+R\V+R\O+R\O+R\O-R\O+R\O+R\O M+S@-"B\O('-T87)T(&]F(&EM<&QE;65N=&%T:6]N(&]F('-E<FEA;&EZ871I M;VX@;V8@<75A=&5R;FEO;B!L:6)R87)Y#0HO+R!N;W1E.B @:68@=&AI<R!W M97)E('!A<G0@;V8@=&AE('%U871E<FYI;VX@;&EB<F%R>2P@=&AI<R!W;W5L M9"!E>&ES="!A<PT*+R\@<V5P87)T('-O=7)C92!F:6QE("T@<75A=&5R;FEO M;B]S97)I86QI>F%T:6]N+FAP<"X-"@T*+R\@;F]T92!H86-K('1O(&=A:6X@ M86-C97-S('1O(&]T:&5R=VES92!I;F%C8V5S<V%B;&4@=F%R:6%B;&5S+@T* M+R\@=&AI<R!C;W5L9"!B92!R96UO=F5D('=H97)E('1H92!Q=6%T97)N97)I M;VX@;&EB<F%R>2!A9&IU<W1E9 T*+R\@=&\@86-C;VUO9&%T92!S97)I86QI M>F%T:6]N+@T*(V1E9FEN92!P<F]T96-T960@<'5B;&EC#0HC:6YC;'5D92 \ M8F]O<W0O;6%T:"]Q=6%T97)N:6]N+FAP<#X-"B-U;F1E9B!P<F]T96-T960- M"@T*+R\@9G5N8W1I;VX@<W!E8VEA;&EZ871I;VYS(&UU<W0@8F4@9&5F:6YE M9"!I;B!T:&4@87!P<F]P<FEA=&4-"B\O(&YA;65S<&%C92 M(&)O;W-T.CIS M97)I86QI>F%T:6]N#0IN86UE<W!A8V4@8F]O<W0@>R -"B-I9B!D969I;F5D M*$)/3U-47TY/7T%21U5-14Y47T1%4$5.1$5.5%],3T]+55 I#0IN86UE<W!A M8V4@<V5R:6%L:7IA=&EO;B![#0HC96QS90T*;F%M97-P86-E(&UA=&@@>PT* M(V5N9&EF#0H-"G1E;7!L871E(#QC;&%S<R!!<F-H:79E+"!T>7!E;F%M92!4 M/@T*=F]I9"!S97)I86QI>F4H#0H@(" @07)C:&EV92 F87(L( T*(" @(&)O M;W-T.CIM871H.CIQ=6%T97)N:6]N/%0^("8@="P@#0H@(" @8V]N<W0@=6YS M:6=N960@:6YT(&9I;&5?=F5R<VEO;@T**7L-"B @("!A<B F('0N83L-"B @ M("!A<B F('0N8CL-"B @("!A<B F('0N8SL-"B @("!A<B F('0N9#L-"GT- M"@T*(VEF("$@9&5F:6YE9"A"3T]35%].3U]!4D=5345.5%]$15!%3D1%3E1? M3$]/2U50*0T*?2 O+R!N86UE<W!A8V4@;6%T: T*(V5L<V4-"GT@+R\@;F%M M97-P86-E('-E<FEA;&EZ871I;VX-"B-E;F1I9@T*?2 O+R!N86UE<W!A8V4@ M8F]O<W0-"@T*+R\@96YD(&]F(&EM<&QE;65N=&%T:6]N('-E<FEA;&EZ871I M;VX@;V8@<75A=&5R;FEO;B!L:6)R87)Y#0HO+R\O+R\O+R\Q+R\O+R\O+R\O M,B\O+R\O+R\O+S,O+R\O+R\O+R\T+R\O+R\O+R\O-2\O+R\O+R\O+S8O+R\O M+R\O+R\W+R\O+R\O+R\O. T*#0HC:6YC;'5D92 B=&5S=%]T;V]L<RYH<' B M#0H-"FEN=" -"G1E<W1?;6%I;B@@:6YT("\J(&%R9V,@*B\L(&-H87(J("\J M(&%R9W8@*B];72 I#0I[#0H@(" @8V]N<W0@8VAA<B J('1E<W1F:6QE(#T@ M8F]O<W0Z.F%R8VAI=F4Z.G1M<&YA;2A.54Q,*3L-"B @("!"3T]35%]215%5 M25)%*$Y53$P@(3T@=&5S=&9I;&4I.PT*#0H@(" @+R\@=7-I;F<@9&5F875L M="!C;VYS=')U8W1O<@T*(" @(#HZ8F]O<W0Z.FUA=&@Z.G%U871E<FYI;VX\ M9FQO870^(" @(" @("!Q,#L-"B @(" Z.F)O;W-T.CIM871H.CIQ=6%T97)N M:6]N/&9L;V%T/B @(" @(" @<6%;,ET[#0H@(" @+R\@=7-I;F<@8V]N<W1R M=6-T;W(@(D@@<V5E;B!A<R!27C0B#0H@(" @.CIB;V]S=#HZ;6%T:#HZ<75A M=&5R;FEO;CQD;W5B;&4^(" @(" @('$Q*#$L,BPS+#0I.PT*(" @('L@(" - M"B @(" @(" @=&5S=%]O<W1R96%M(&]S*'1E<W1F:6QE+"!415-47U-44D5! M35]&3$%'4RD[#0H@(" @(" @('1E<W1?;V%R8VAI=F4@;V$H;W,I.PT*(" @ M(" @("!O82 \/"!"3T]35%]315))04Q)6D%424].7TY64"AQ,"D[#0H@(" @ M(" @(&]A(#P\($)/3U-47U-%4DE!3$E:051)3TY?3E90*'%A*3L-"B @(" @ M(" @;V$@/#P@0D]/4U1?4T5224%,25I!5$E/3E].5E H<3$I.PT*(" @('T- M"B @(" O+R!U<VEN9R!D969A=6QT(&-O;G-T<G5C=&]R#0H@(" @.CIB;V]S M=#HZ;6%T:#HZ<75A=&5R;FEO;CQF;&]A=#X@(" @(" @('$P,3L-"B @(" Z M.F)O;W-T.CIM871H.CIQ=6%T97)N:6]N/&9L;V%T/B @(" @(" @<6$Q6S)= M.PT*(" @("\O('5S:6YG(&-O;G-T<G5C=&]R(")(('-E96X@87,@4EXT(@T* M(" @(#HZ8F]O<W0Z.FUA=&@Z.G%U871E<FYI;VX\9&]U8FQE/B @(" @("!Q M,3$H,2PR+#,L-"D[#0H@(" @>PT*(" @(" @("!T97-T7VES=')E86T@:7,H M=&5S=&9I;&4L(%1%4U1?4U1214%-7T9,04=3*3L-"B @(" @(" @=&5S=%]I M87)C:&EV92!I82AI<RD[#0H@(" @(" @(&EA(#X^($)/3U-47U-%4DE!3$E: M051)3TY?3E90*'$P,2D[#0H@(" @(" @(&EA(#X^($)/3U-47U-%4DE!3$E: M051)3TY?3E90*'%A,2D[#0H@(" @(" @(&EA(#X^($)/3U-47U-%4DE!3$E: M051)3TY?3E90*'$Q,2D[#0H@(" @?0T*(" @('-T9#HZ<F5M;W9E*'1E<W1F M:6QE*3L-"@T*(" @($)/3U-47T-(14-+*'$P(#T]('$P,2D[#0H@(" @0D]/ M4U1?0TA%0TLH<6%;,%T@/3T@<6$Q6S!=*3L-"B @("!"3T]35%]#2$5#2RAQ M85LQ72 ]/2!Q83%;,5TI.PT*(" @($)/3U-47T-(14-+*'$Q(#T]('$Q,2D[ H#0H-"B @("!R971U<FX@8F]O<W0Z.F5X:71?<W5C8V5S<SL-"GT-"@`` ` end
somewhere in the E.U., le 26/10/2004 Bonjour In article <cljp56$68k$1@sea.gmane.org>, "Robert Ramey" <ramey@rrsd.com> wrote:
"Hubert Holin" <Hubert.Holin@meteo.fr> wrote in message news:Hubert.Holin-89E7B0.14253525102004@sea.gmane.org...
It is not immediately clear if [serialize] can do that in any way which is simpler to implement than what I already do for these classes (i.e. it would likely be as disgusting and unmaintainable, however necessary).
I don't think there is any factual support for that statement.
My claim simply is that I can't see how to do it, not that nobody can do it :-) !
As a counter example, The following code includes implementation of serialization for the quaternion class template (17 lines of code) and a
I could not get your code to compile (either using MWCWPro8.x or Xcode 1.5), so I could not test it. From what I understand (I may be wrong, of course), the output should works more or less like the non-fancy one already in place. However, its the input that's the core of the problem. Granted, you code will most likely read a quaternion which would be in a text file in the form (excluding the quotes written here for clarity) "(1.0, 2.0, 3.0, 4.0)". But will it also accept "1.0", "(2.0, 3.0)" and "((1.0, 2.0), (3.0, 4.0))" while refusing "((1.0, 2.0), 3.0, 4.0)"?
test of its serialization. I only spent an hour on it ( most of which was perusing the quaternion docs and code so it might benefit from more effort and testing than I am in a position to invest. But I would hope that it does illustrate how easy it is to serialize what might seem to be an otherwise complex type. I would hope it also will help to refute the
It is not the type which is complicated here, it is the format of legal inputs.
perception that the serialization library is "too big". I don't believe
I will not comment on that, as I have frankly no idea about it. If a library is useful, I will use it, no matter how big (I do not do embedded :-) ). The only problem with "big" libraries is that they are more difficult to maintain, and thus more error-prone. They may also prove to be more difficult to port.
that serialization adds any more code (source and/or object) to an project than any comparable alternative method.
For example, the i/o code built into the the quaternion class contains 329
That's why I really want to improve on that, even at the cost of an additional dependency. The octonion library is far, far, worse...
lines of templated code. And, it doesn't include any facilities that come for free with serialization libary such as the ability to create archives of different types included XML, binary etc. It is also pure template code
True. I am not against serialization for quaternions and octonions (heck, if anybody wants it, and it can be done in a way which will not preclude a simplification of the input operator whilst maintaining its current flexibility, I'll add it after the Boost 1.32 release!), it is just I do not see how it can simplify the horrible (but remarkably flexible) wart.
that doesn't factor out commonality into a separart module so I would expect to to be more "too big" than the equivalent of the serializaition library.
Robert Ramey
Merci Hubert Holin
"Hubert Holin" <Hubert.Holin@meteo.fr> wrote in message news:Hubert.Holin-086F76.14230626102004@sea.gmane.org...
somewhere in the E.U., le 26/10/2004
I could not get your code to compile (either using MWCWPro8.x or Xcode 1.5), so I could not test it. From what I understand (I may be wrong, of course), the output should works more or less like the non-fancy one already in place. However, its the input that's the core of the problem.
Serialization of arrays fails with CW 8.3. Also serialization of pointers fails with all CW compilers at runtime. So far we have been unable to resolve these issues with this particular compiler.
Granted, you code will most likely read a quaternion which would be in a text file in the form (excluding the quotes written here for clarity) "(1.0, 2.0, 3.0, 4.0)". But will it also accept "1.0", "(2.0, 3.0)" and "((1.0, 2.0), (3.0, 4.0))" while refusing "((1.0, 2.0), 3.0, 4.0)"?
With the serialization library is intended to be used to save and restore the state of an arbitrary set of C++ data structures. The particular format used to store the data is implemented as and "archive class". The archive class can be selected independently of the data to be serialized. Some archives have readable or semi-readable formats. E.g XML or plain text, while others or opaque to human perception - binary. The data stored in an archive is designed to capture all the information required to restore it to its original state and is driven by the structure of the data saved. Serialization is not intended for and generally not suitable for reading and parsing some other input format. Here is where I believe the confusion lies. a) If one wan't to display something for human consumption such as a report, debug log or what ever, An output format library might be useful. b) If one wants to save and restore something to its original state, the serialization libary will be useful. c) If one wants to read some input text in some specified format, parse it and generate some data instances - spirit may be helpful. Serialization does include one "user friendly" archive format - XML but it may not be what one wants. It might be possible to generate an archive which displays data in a way different than XML but is still suitable for human consumption - but no one has shown any interest in this idea. Generally, I would think that concentrating on using the above tools for the above purposes rather than trying to extend them too far beyound thier original motivation and design goals will lead to more complexity and overlapp than necessary or desirable. Robert Ramey
Somewhere in the E.U., le 28/10/2004 Bonjour In article <cllsnh$eb3$1@sea.gmane.org>, "Robert Ramey" <ramey@rrsd.com> wrote: [SNIP problems between serialize and my current toolsets, which in the short term prevent me from adding serialization to quaternions and octonions]
With the serialization library is intended to be used to save and restore the state of an arbitrary set of C++ data structures. The particular format used to store the data is implemented as and "archive class". The archive class can be selected independently of the data to be serialized. Some archives have readable or semi-readable formats. E.g XML or plain text, while others or opaque to human perception - binary. The data stored in an archive is designed to capture all the information required to restore it to its original state and is driven by the structure of the data saved. Serialization is not intended for and generally not suitable for reading and parsing some other input format.
OK. So while this is indeed important, it does not solve my problem (simplification of input operators, due to the complexity of legal input syntax).
Here is where I believe the confusion lies.
a) If one wan't to display something for human consumption such as a report, debug log or what ever, An output format library might be useful. b) If one wants to save and restore something to its original state, the serialization libary will be useful. c) If one wants to read some input text in some specified format, parse it and generate some data instances - spirit may be helpful.
[SNIP]
Generally, I would think that concentrating on using the above tools for the above purposes rather than trying to extend them too far beyound thier original motivation and design goals will lead to more complexity and overlapp than necessary or desirable.
Robert Ramey
Precisely. But the scope of sprit is very wide, so a dedicated library (solving efficiently a class of problems) would be welcome. Nothing prevents that dedicated library being based on a more general framework (such as spirit, in the case of "out"put iterators), of course. Cordialement Hubert Holin
Bonjour! Hubert Holin wrote:
Somewhere in the E.U., le 22/10/2004 I just wanted to point out that the reason I was interested in it is that I had been told (when it was in the sandbox, quite some time before the review) it had the potential to help me simplify tremendously my quaternion and, especially, octonion libraries, by providing a better handling of input operators. So I would say (better late than never, though perhaps it is now *too* late) that there actually *is* an interest in input facilities.
I haven't yet removed the input facilities from the library. To me, these are the reasons to keep the input in the library: [1] The library provides stream operations on STL containers, so why only provide output of a list/vector/...? This would mean that you'd need to implement the input operations using some other library, adding a further dependency on that library. [2] Symmetry and completeness. I know my library during the review was called "Output Formatters" (I would like it to be in the mini/second-review as "I/O Collection Framework" or something similar), but not providing input would be, IMHO, an oversight. [3] There have been people in the for input facilities camp as well as those against. For example, Roland Richter is using my library in conjunction with lexical_cast to convert between strings and containers. Therefore, I would prefer to keep the input facilities (at least until the end of the mini/second-review). I will commit the updated library once I have finished revising it, based on the review feedback. Regards, Reece
participants (3)
-
Aaron W. LaFramboise -
Andreas Huber -
Darren Cook -
David Abrahams -
David B. Held -
Gennadiy Rozental -
Hubert Holin -
Jody Hagins -
Johan Nilsson -
John Torjo -
Jonathan Turkanis -
Manfred Doudar -
Paul A Bristow -
Peter Dimov -
Reece Dunn -
Rob Stewart -
Robert Ramey -
Robert Zeh -
Victor A. Wagner Jr. -
Vladimir Prus