[boost] Interval library merge
Hi, I think the Interval Arithmetic library is ready to be merged from the boost-sandbox cvs into the main boost cvs. So cvs write rights will be needed; but before that, something must be decided: where to put the library? This question was already discussed on this mailing-list some times ago, but no clear answer was given at that time. The library directory is actually directly under boost. To avoid cluttering the root, it would probably be better to put it somewhere else; for example, boost/math or boost/numeric. Unfortunately, the library has some good reasons to be put in each of these directories. So I suggest it is put in boost/numeric (heads or tails). Subsidiary question: should the namespace tree follow the directory tree? I think it should; but since I will need a few hours to correct the whole source and documentation (it isn't as easy as changing the #include at the top of the files), I prefer to ask beforehand. Regards, Guillaume ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Preliminary submission: command line & config fil e library
Rozental, Gennadiy wrote: It is not necessary. You program will be given *string* "(0,1) (1,3)" and can parse it using more powerfull means. I guess Spirit is quite appropriate. I provide a way to parse it with very simple means. I don't see that yet, but see below. Unfortunately I will be really busy till the middle of February. So may not be able to work on this further meanwhile. It's a pity, because I've only one more or less serious interface change left in my library, and would prefer to ask for review after that. Do you have any idea when your library will have documentation, examples and tests? Not before the date I mention. If you feel that your design could stand in review go ahead. I will submit my once it's done. Hopefully really soon, cause Boost.Test changes will rely on it. OK. I've looked at the code you've uploaded. I have some questions already, but to form final opinion, I would very much like to see other lookup policies. You've announced double_key_polycy, getopt_polycy, positional_policy, but I do not see any of them in the archive. They would really be important to understand how policies are used. Also, did you uploaded your config file library, too? - Volodya ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Preliminary submission: command line & config file library
Thomas Wenisch wrote: Hi all, I have not followed this discussion closely, but I did want to add on one point: [...] For example: my_program /roll trace file? = "yes" CLA is basic facility that is used by many people with different habits. You could not afford to incur too many restrictions. Some programs might support a command line like this: my_program ? To print out help information (ie same as my_program --help). Therefore, allowing ? as a command line argument is an important use case. I am not sure whether or not Vladimir's proposal would support a question mark by itself. It does. The question mark is a simple way to tell: "the argument is optional". I believe it's extremely usefull and it does not interfere with having "?" as part of option name, or option value, or argument. For example, you might take a look at http://zigzag.cs.msu.su:7813/program_options/html/classboost_1_1program__options_1_1cmdline.html#a3 you can use '?' as value of 'properties' parameter, but no special handling of '?' character in the command line will be done. Also note that this notation (in context of command line parsing) was not invented by me. Instead, it's borrowed from Brad Appleton: http://www.enteract.com/~bradapp/ftp/src/libs/C++/Options.html - Volodya ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Preliminary submission: command line & config fil e library
Rozental, Gennadiy wrote:
As my example above shows, you can use simple syntax for two
arguments and
explicit/named for all others. Take a look at Boost.Graph: it
uses named
arguments, but mostly for numerous details such as
"color_map". You don't have
to write
transitive_closure(graph_param(g));
Unfortunately I am not familiar with Boost.Graph, but I believe that in
specific case of CLA I would prefer one style for all parameter's modifiers.
I do not see how description is more important that optional/required for
example. Looking on your example I already confused:
desc3.add_options()
("output,o", "file", "where to send output")
("magic", "value", "magic value for the program")
.default_value("43")
What is "file", "value"? Why do I need to supply default value as a string
and not 43 itself?
What is ,o? Do I need to remember everything that you will reply?
You still need to remember something. For example, your library uses ","
to separate elements of std::list<...> parameter. Can I guess that from the
options declaration? Can I guess what "multiplicable" is?
The non 100% obvious notation in the above example is ",o" for short option
and naming the value for option.
With yout proposal it would look something like
parser << named_parameter<>("output") << short_name<>("o") <<
value_name("file") << description("where to send output")
And it should be repeated for each option.
options_description desc;
desc.add_options()
("roll_trace_file?", "arg?", "roll trace file)
;
What id "arg" then? Keyword? Would you remember difference between first
question mark and second?
I don't see much problems. "arg?" is "parameter_name", as documentation says.
If you hack on command line parsing right now, it's easy to remember the
syntax convention. Few month later, you'd at most have to briefly look
at docs.
And what those operator<< will do?
Feed option definitions to the cla::parser.
Eeh.. that's only possible if program_options,
config::parser, and cla::parser
have the same interface for declaring options. If you add
custom modifier to
cla::parser, you have to add it to program_options, and the
to config::parser
and then to registry::parser, if you have it.
Not at all. program_option may support only common superset on all
What's "common superset"? Assuming you meant "common subset".
configuration components features. It does not need to know about all
supported features of all components. In my understanding program_options is
only helper facility for one very useful case.
Does key_lookup_policy support short options? No. Therefore program_options
cannot support them either. So, if I want to handle both command line
and config file I have to give up something very handy.
- Volodya
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Live summary of regression tests.
On Monday 20 January 2003 03:14, Rene Rivera wrote: > In order to make regression test browsing more pleasant for all of us. I > decided to work up a little script to gather up all the test results that > get posted to the boost.sourceforge.net site. So browse on over to: > > http://boost.sourceforge.net/regression-logs > > ..and take a look. > > And for those doing regression testing, this a zero maintenance page. Just > put up the cs-PLATFORM*.html files in there and they'll automatically show How come it picked up cs-aix.html and not cs-vacpp6.html. The latter is the one generated by the new regression test system, the former is still the old one. I can however rename the latter to cs-.html but since the same link is used in the 1.29 release, the status does not correspond with the code at that time anymore ? toon ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Live summary of regression tests.
On Monday 20 January 2003 03:14, Rene Rivera wrote: > In order to make regression test browsing more pleasant for all of us. I > decided to work up a little script to gather up all the test results that > get posted to the boost.sourceforge.net site. So browse on over to: > > http://boost.sourceforge.net/regression-logs > > ..and take a look. Very very handy ! Did you put the link also in the doc in CVS somewhere ? t ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Preliminary submission: command line & config file li brary
Rob Stewart wrote: Since this discussion has been mostly between two folks, I thought I'd add my take on command line and configuration file handling. It's good! The purpose of command line parsing is to decode the arguments list into pieces of information, abstracting the syntax of the command line away from the program. Thus, the library should be able to understand any of various encoding schemes. That's syntantic level. I believe it should be as independent from meaning of options as possible: command line, preferrable, should be immediately parsable by humans. The question then becomes how the library should provide the values from the command line. There are a number of fundamental types that could be exposed by the library: bool, long, double, and string. The question is whether the library should support any others. I selected those types because Boolean and string parameters are obviously important, and long and double would handle pretty much all numeric arguments one would put in a command line. The level 2 of my library provides only syntantic representation of the read options. See http://zigzag.cs.msu.su:7813/program_options/html/ for the list of layers. You could use std::istream-based input mechanisms to allow types to parse an input string, thus making the argument to variable conversion extensible. Beyond that, I don't think anything is needed. That's layer 4. You can specify how to interpret values, and by default stream operations are used. You can easily add something smarter. As for configuration files, there are myriad formats available and I don't think parsing them has anything to do with command lines. Parsing -- no. However, as an application programmer I'm interested if my code should produce some warnings at runtime or not. Command line and config file are two places where warnings can be enabled/disabled. I think this similarity should be exploited. I can see a special redirection mechanism in which you tell the command line library that all or some of the arguments that would otherwise be on the command line will appear in a file, but the format of such a file should be confined to a series of lines that conform to what could otherwise have been on the command line. Some configuration files include CPP-like preprocessing symbols and directives. Some are section based (like Windows INI files). Some are just free form lines of text. Some use special symbols to delimit required columns of data. I don't think there's a good way to standardize this. And there's no need. You're welcome to write your own parser and hook it to the rest of library. Sure, you could provide a means to read a file line by line and pass each line to a parser of some sort. However, given all of the ways to parse the text one might find in such a file, I don't see how that could be done so it is sufficiently flexible and yet actually provides value. IOW, the parsing would be little more than read a line, give it to the parser, read another line, give it to the parser, etc. That certainly doesn't justify a special library. What "special library"? Perhaps I've missed some valuable service that should be included in the proposed library, but I can't see that it should do more than what I've outlined herein. If you do, please enlighten me! It looks like you don't need some of the extra features that both Gennadiy and myself are after. For example, custom value interpreration or automatic help message? Could you please tell which features in both designs are unnecessary and should be removed? - Volodya ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Live summary of regression tests.
Rene Rivera wrote: > In order to make regression test browsing more pleasant for all of us. I > decided to work up a little script to gather up all the test results that > get posted to the boost.sourceforge.net site. So browse on over to: > > http://boost.sourceforge.net/regression-logs > > ..and take a look. Cool! I find it rather surpsing that there are no warnings at all on the Windows platform though. Borland in particular can be quite chatty. -- AlisdairM ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: compile-time binary constants
On Sun, 19 Jan 2003 20:50:02 -0500, Beman Dawes <[EMAIL PROTECTED]> wrote: >If you have a reasonable, useful, proposal then don't worry about getting >it presented to the committee. Sure, it helps to be there in person, but >there are plenty of existence proof's that attendance isn't a requirement. Thanks for the clear information. I have to say, then, that we should acknowledge some communication problem between the committee and the "public": though I'm one that tries to keep abreast of the committee work and follow the main C++ newsgroups I can't sometimes do without thinking that the criteria used to reject/approve some proposal are inexplicable. Just to give you some examples, introduction of "new features" (i.e. things that are not established practice) is usually not even considered; this is because the purpose of standardization should not be to "invent" but, exactly, to "standardize"; now who implemented "export" before standardization? What about exception specifications? What about Koenig lookup (and "extended" Koenig lookup)? Also think e.g. to B. Stroustrup's recent articles in CUJ, where he proposes, among other things, to introduce a new wchar keyword and to allow implicit void* -> pointer-to-object conversion. Call me mischievous, but would such ideas have been taken into serious consideration if they didn't came from a person of the calibre and authority of Bjarne Stroustrup?. The impression we get, from this other side of the "fence", is that a lot of "criteria" used for acceptance (is useful, is implemented by some major compiler, doesn't break backward compatibility, etc.) are often just used as excuses to reject proposal on an opinion basis. I'm not saying this is the truth, but this is definitely the impression I get from outside. If this just a communication problem as I said, then something should be done I think, because the situation is discouraging for people who want to propose new ideas. Genny. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] HP regression tests
From: "John Maddock" <[EMAIL PROTECTED]> [...] > The compiler seems not to support template templates according to the > config_test failure. We currently have: > > #if (__HP_aCC <= 33900) > #define BOOST_NO_TEMPLATE_TEMPLATES > #define BOOST_NO_MEMBER_TEMPLATE_KEYWORD > #define BOOST_NO_UNREACHABLE_RETURN_DETECTION > #endif > > which I presume needs updating? What is the latest __HP_aCC version number? There is also #if (__HP_aCC <= 33300) || !defined(BOOST_STRICT_CONFIG) // member templates are sufficiently broken that we disable them for now #define BOOST_NO_MEMBER_TEMPLATES #define BOOST_NO_DEPENDENT_NESTED_DERIVATIONS #define BOOST_NO_DEPENDENT_TYPES_IN_TEMPLATE_VALUE_PARAMETERS #endif where the !defined(BOOST_STRICT_CONFIG) causes BOOST_NO_MEMBER_TEMPLATES to be defined unconditionally AFAICS. This causes a number of shared_ptr tests to fail as shared_ptr.hpp uses a simplified version when no member templates are available. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Boost as charity-ware
On Sun, 19 Jan 2003 16:06:10 -0600, Rene Rivera <[EMAIL PROTECTED]> wrote: >[2003-01-19] Gennaro Prota wrote: > >>What a question! Because that would mean making good deeds. > >You shouldn't need Boost to do good deeds ;-) Indeed. The idea is that we choose a list of associations and bodies, and set up a mechanism, through the boost site or another site, where download is possible only by making a donation to one of the associations. That would be the only condition and the software would be of course free to use, copy and modify. >>> >>>If it's "free to use, copy and modify" isn't requiring payment >>>contradictory? >> >>Shrug. Ok, maybe I should be contented with just "encouraging" a >>donation :-/ > >The best donation, would be that of time and effort towards Boost itself. >For that matter hire Dave, his sig... Uh? Rene, the idea was not to donate to boost or to boost's authors. The idea is that a donation would be a pleasant "side effect" of using boost, just that. Companies spend thousand dollars in software. Even for a 2-people company, like one I've worked with, spending -say- 10 dollars for a whole boost distribution is a peanuts. I guess it would be the smallest entry in the annual balance, or maybe the one immediately higher than the new mouse pad for the boss. The argument about contradicting the boost purpose, raised by someone else, is totally unwarranted as well. Boost would remain exactly the same it is now: donation would be a "side effect". However this is not to convince anyone, I had this idea and thought to propose it. If nobody likes it, then it won't be adopted. Genny. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Problems with boost on Cray C++ release 3.6
On Saturday, January 18, 2003, at 12:55 PM, John Maddock wrote: If you can test and supply patches they would be much appreciated, come to that, I don't suppose you would like to volunteer to regularly run the regression tests on that platform would you (no problem if you can't though)? Testing on Cray would be useful if only because the architecture is so different from the usual 32-bit platforms we test on. I tried to run the regression test but the first problem I encountered is that jam does not seem to work on a Cray machine: athos:> sh ./build.sh cc ### ### Using 'cc' toolset. ### rm -rf bootstrap.cc mkdir bootstrap.cc cc -o bootstrap.cc/jam0 command.c compile.c execnt.c execunix.c execvms.c expand.c filent.c fileos2.c fileunix.c filevms.c glob.c hash.c hdrmacro.c headers.c jam.c jambase.c jamgram.c lists.c make.c make1.c newstr.c option.c parse.c pathunix.c pathvms.c regexp.c rules.c scan.c search.c subst.c timestamp.c variable.c modules.c strings.c filesys.c builtins.c pwd.c ./bootstrap.cc/jam0 -f build.jam --toolset=cc --toolset-root= ./build.sh[3]: 48150 Floating exception(coredump) Can one run the regression tests without jam? Matthias ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Boost as charity-ware
Gennaro Prota wrote: > The argument about contradicting the boost purpose, raised by someone > else, is totally unwarranted as well. Boost would remain exactly the > same it is now: donation would be a "side effect". My point (being someone else) is that side effect is to fund something entirely separate to boost. If someone has an issue with that other organisation, that could lead on to rejecting boost. Also in hindsight, does exchanging money for the code have commercial implications with respect to implied contracts, liabilities and so forth in some countries? IANAL, but I have vague recollections of implied contracts being different if money changes hands. Considering the problems some people have with the corporate lawyers sneaking a license for the free code, do we want to complicate matters further? Also note: If a charity wants to set up a boost distribution there is nothing stopping it doing so. Potentially boost could offer links to anyone supporting a boost distribution separate from the main site, but that is another matter. -- AlisdairM Team Thai Kingdom ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Policy-based smart pointers revisisted
> [mailto:[EMAIL PROTECTED]]On Behalf Of Paul Mensonides > I don't buy this argument about the "complexity of many pointer > types." I'm > not going to make a judgement on whether a few distinct smart pointers are > better than a single super pointer. I think we should have both and let > users use whichever the like better. I think the problem with offering too many solutions to the same problem is that many users simply get baffled by the choice and use none. Take some of the people I work with, it has taken me many months just to get them to the point where they use shared_ptr. Just occasionally I see one of them write boost::noncopyable, or even boost/operator.hpp. If they had to decide whether to use shared_ptr, or slightly_faster_ptr, I think they would simply not bother. Simply, they won't make use of something unless they see quick and obvious benefits from it. And I don't think this attitude is at all unusual amongst programmers. Also, I can't see any future standard having more than one new pointer, and I can't see anything but the already widely used shared_ptr being it. > However, all smart pointers provide > basically the same interface, so keeping track of that is not that big an > issue, as the differences in interface exist because of the > various purposes > of different smart pointers. Also, because smart pointers are templates, > you already have a different smart pointer every time that you instantiate > it with a different type. The compatibility issues between smart_ptr_A > and smart_ptr_B can be handled without significantly more > difficulty than > smart_ptr and smart_ptr. There seems to me to be a very significant difference between smart_ptr -> smart_ptr, smart_ptr_A -> smart_ptr_B. The first is simply a cast and an attachment to the reference count. But the second requires that every strategy policy understands how to make use of every other strategy policy. i.e. for the following to work: smart_ptr f(); ... smart_ptr a = f(); my_own_counting_policy needs to understand what my_own_cloning_policy does, and how to safely attach to it. The problem becomes exponential with each policy added. Not to mention heavily dependent. The other option, of simply not making such conversions possible makes for incompaible libraries, and lots of fix-up code to get around such problems. My vote is to keep things simple, and to keep shared_ptr and scoped_ptr as the only smart pointers. That said, I do like the way shared_ptr can improve itself if you give it something derived from counted_base, perhaps to compromise this method of adding variety of implementation could be extended. e.g. perhaps something derived from clonable_base could have cloning characteristics? As we've mentioned loki, is there any update on Loki -> boost integration? A quick check of the archives and nothing seems to have been mentioned since may or so. Sam ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Policy-based smart pointers revisisted
> [mailto:[EMAIL PROTECTED]]On Behalf Of Sam Partington > That said, I do like the way shared_ptr can improve itself if you give it > something derived from counted_base, perhaps to compromise this method of > adding variety of implementation could be extended. e.g. perhaps > something > derived from clonable_base could have cloning characteristics? Oops, typing faster than I think as usual. I was just trying to come up with some example of other extensions to shared_ptr through the same method of counted_base. This was a poor example. Obviously a shared_ptr with cloning characteristics would confuse everybody, myself more than most I suspect. Sorry! Sam ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Preliminary submission: command line & config file li brary
Title: RE: [boost] Preliminary submission: command line & config file li brary
-Original Message-
From: Vladimir Prus [mailto:[EMAIL PROTECTED]]
>
> > As for configuration files, there are myriad formats available
> > and I don't think parsing them has anything to do with command
> > lines.
>
> Parsing -- no. However, as an application programmer I'm interested
> if my code should produce some warnings at runtime or not. Command line
> and config file are two places where warnings can be enabled/disabled.
> I think this similarity should be exploited.
>
In our case, we created such a system. And for the ease of use, it was very important to define any application parameter in a single step. These application parameters can be set either from command line options, configuration file, or have their default value.
Having two lines to get the value (as we did initialy), first from config file, and then overloading from cmd line options, proved to be error prone. Adding a new parameter went to copy paste these two lines. And often the changes in one line were not replicated exactly on the second. Thus resulting in a flag meaning true on cmd line and meaning false in config file.
We ended up by using a system where the definition of a parameter were done all at once, as in the following:
Parameter verbose( // use verbose as a bool in code
false, "verbose output", // default value & help string
Option("verbose", "v"), // for cmd line --verbose or -v
Config("section", "key")); // config file [section] key =
Leaving the syntax away from the sample above, the rationale was to keep the Option and Config uses at one single place. We also kept the use for the Parameter<> variable as if it was not one.
Following this, new Config classes can be defined to accomodate every config file format. Of course, Option and Config are not mandatory, as in the example above the verbose config option may not be lots usefull. We also added some Arguments classes, used like Option, to specify mandatory arguments.
But maybe this is one level above the purpose of this library.
Regards,
Didier
Re: [boost] Interval library merge
Guillaume Melquiond <[EMAIL PROTECTED]> writes: > Hi, > > I think the Interval Arithmetic library is ready to be merged from the > boost-sandbox cvs into the main boost cvs. So cvs write rights will be > needed; Send your sourceforge user name to [EMAIL PROTECTED], and someone will set it up. If you don't have one already, I suggest "guillaume_melquiond". > but before that, something must be decided: where to put the > library? > > This question was already discussed on this mailing-list some times ago, > but no clear answer was given at that time. The library directory is > actually directly under boost. To avoid cluttering the root, it would > probably be better to put it somewhere else; for example, boost/math or > boost/numeric. Unfortunately, the library has some good reasons to be put > in each of these directories. So I suggest it is put in boost/numeric > (heads or tails). > > Subsidiary question: should the namespace tree follow the directory tree? > I think it should; but since I will need a few hours to correct the whole > source and documentation (it isn't as easy as changing the #include at the > top of the files), I prefer to ask beforehand. I'll have to leave these questions to someone more familiar with the library. -Dave -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost as charity-ware
Rene Rivera said: > [2003-01-19] Gennaro Prota wrote: > >>On Sun, 19 Jan 2003 15:19:15 -0600, Rene Rivera >><[EMAIL PROTECTED]> wrote: >> >>>[2003-01-19] Gennaro Prota wrote: >>> I would *love* to see boost becoming a charity-ware collection of libraries. >>> >>>Why? >> >>What a question! Because that would mean making good deeds. > > You shouldn't need Boost to do good deeds ;-) Not to mention that a "forced" or "required" deed can't really be considered a "good" deed. The idea is that we choose a list of associations and bodies, and set up a mechanism, through the boost site or another site, where download is possible only by making a donation to one of the associations. That would be the only condition and the software would be of course free to use, copy and modify. >>> >>>If it's "free to use, copy and modify" isn't requiring payment >>>contradictory? >> >>Shrug. Ok, maybe I should be contented with just "encouraging" a >>donation :-/ > > The best donation, would be that of time and effort towards Boost > itself. For that matter hire Dave, his sig... Who else should benefit from the Boost efforts, but it's members? And I think we do benefit. William E. Kempf [EMAIL PROTECTED] ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Preliminary submission: command line & config fil elibrary
Vladimir Prus <[EMAIL PROTECTED]> writes:
> Rozental, Gennadiy wrote:
>>> As my example above shows, you can use simple syntax
>>> for two arguments and explicit/named for all
>>> others. Take a look at Boost.Graph: it uses named
>>> arguments, but mostly for numerous details such as
>>> "color_map". You don't have to write
>>>
>>>transitive_closure(graph_param(g));
>> Unfortunately I am not familiar with Boost.Graph, but
>> I believe that in
>> specific case of CLA I would prefer one style for all parameter's modifiers.
>> I do not see how description is more important that optional/required for
>> example. Looking on your example I already confused:
>>
>>>desc3.add_options()
>>>("output,o", "file", "where to send output")
>>>("magic", "value", "magic value for the program")
>>>.default_value("43")
>> What is "file", "value"? Why do I need to supply
>> default value as a string
>> and not 43 itself?
>> What is ,o? Do I need to remember everything that you will reply?
>
> You still need to remember something. For example, your library uses ","
> to separate elements of std::list<...> parameter. Can I
> guess that from the options declaration? Can I guess
> what "multiplicable" is?
>
> The non 100% obvious notation in the above example is
> ",o" for short option and naming the value for option.
>
> With yout proposal it would look something like
>
> parser << named_parameter<>("output") <<
> short_name<>("o") << value_name("file") <<
> description("where to send output")
>
> And it should be repeated for each option.
I don't have very much of use to say, but I like Vladimir's syntax
much better, FWIW.
--
David Abrahams
[EMAIL PROTECTED] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost as charity-ware
Alisdair Meredith <[EMAIL PROTECTED]> writes: > Gennaro Prota wrote: > >> I would *love* to see boost becoming a charity-ware collection of >> libraries. The idea is that we choose a list of associations and >> bodies, and set up a mechanism, through the boost site or another >> site, where download is possible only by making a donation to one of >> the associations. That would be the only condition and the software >> would be of course free to use, copy and modify. > > I am unreservedly opposed, no matter which charities are selected. > It is not that I am anti-charity. Quite the contrary. But I believe > mixing the two contradicts boost purpose. > I feel like the Grinch stealing Christmas coming out so strongly against > something that is doubtless well motivated, and proposed by someone far > more active in the community than myself, but see to much potential harm > for it to pass without comment. I feel basically the same way about this suggestion, but on even more pragmatic grounds. Getting Boost participants to agree on a list of worthy charities sounds like a bureaucratic and political nightmare that would be completely off-topic for the list and would probably never be resolved. All of that wasted energy could be divided between library development *and* more-effective (individual) approaches to raising money for charities. -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Whom to send this?
Hi, I found out what to edit in gcc-tools.jam in order to get BOOST compiled with regex and threads under NetBSD 1.6. Anybody out there familiar with boost build process I can send this short tutorial for having a look at it (telling me what can be achieved easier)? Perhaps I can send it also to NetBSD-FAQ. Thx Flo ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Problems with boost on Cray C++ release 3.6
On Monday 20 January 2003 14:03, Matthias Troyer wrote: > On Saturday, January 18, 2003, at 12:55 PM, John Maddock wrote: > > If you can test and supply patches they would be much appreciated, > > come to > > that, I don't suppose you would like to volunteer to regularly run the > > regression tests on that platform would you (no problem if you can't > > though)? Testing on Cray would be useful if only because the > > architecture > > is so different from the usual 32-bit platforms we test on. > > I tried to run the regression test but the first problem I encountered > is that jam does not seem to work on a Cray machine: > And what happens if you use make directly ? ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Problems with boost on Cray C++ release 3.6
On Monday, January 20, 2003, at 04:27 PM, Toon Knapen wrote: I tried to run the regression test but the first problem I encountered is that jam does not seem to work on a Cray machine: And what happens if you use make directly ? Same problem if I use make, jam compiles but then crashes Matthias ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Whom to send this?
Florian Stöhr <[EMAIL PROTECTED]> writes: > Hi, > > I found out what to edit in gcc-tools.jam in order to get BOOST compiled > with regex and threads under NetBSD 1.6. > > Anybody out there familiar with boost build process I can send this short > tutorial for having a look at it (telling me what > can be achieved easier)? > > Perhaps I can send it also to NetBSD-FAQ. The most appropriate place to post it is to the jamboost list: [EMAIL PROTECTED] A less-appropriate but still acceptable choice would be to post it here. There's no need to make a tutorial out of it; if you tell us what you changed in gcc-tools.jam, we'll take your work and set it up so that NetBSD builds work automatically. Thanks, Dave -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Problems with boost on Cray C++ release 3.6
Matthias Troyer <[EMAIL PROTECTED]> writes: > On Saturday, January 18, 2003, at 12:55 PM, John Maddock wrote: >> If you can test and supply patches they would be much >> appreciated, come to >> that, I don't suppose you would like to volunteer to regularly run the >> regression tests on that platform would you (no problem if you can't >> though)? Testing on Cray would be useful if only >> because the architecture >> is so different from the usual 32-bit platforms we test on. > > I tried to run the regression test but the first > problem I encountered is that jam does not seem to work > on a Cray machine: > > athos:> sh ./build.sh cc > ### > ### Using 'cc' toolset. > ### > rm -rf bootstrap.cc > mkdir bootstrap.cc > cc -o bootstrap.cc/jam0 command.c compile.c execnt.c > execunix.c execvms.c expand.c filent.c fileos2.c > fileunix.c filevms.c glob.c hash.c hdrmacro.c headers.c > jam.c jambase.c jamgram.c lists.c make.c make1.c > newstr.c option.c parse.c pathunix.c pathvms.c regexp.c > rules.c scan.c search.c subst.c timestamp.c variable.c > modules.c strings.c filesys.c builtins.c pwd.c > ./bootstrap.cc/jam0 -f build.jam --toolset=cc --toolset-root= > ./build.sh[3]: 48150 Floating exception(coredump) One other thing worth checking if you can't get a stack trace easily: ./bootstrap.cc/jam0 -d12 You may get enough useful output for us to track down the problem. -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Preliminary submission: command line & config file li brary
Trosset Didier wrote:
> > As for configuration files, there are myriad formats available
> > and I don't think parsing them has anything to do with command
> > lines.
>
> Parsing -- no. However, as an application programmer I'm interested
> if my code should produce some warnings at runtime or not. Command line
> and config file are two places where warnings can be enabled/disabled.
> I think this similarity should be exploited.
>
In our case, we created such a system. And for the ease of use, it was
very important to define any application parameter in a single step.
These application parameters can be set either from command line
options, configuration file, or have their default value.
Having two lines to get the value (as we did initialy), first from
config file, and then overloading from cmd line options, proved to be
error prone. Adding a new parameter went to copy paste these two lines.
And often the changes in one line were not replicated exactly on the
second. Thus resulting in a flag meaning true on cmd line and meaning
false in config file.
You are right.
We ended up by using a system where the definition of a parameter were
done all at once, as in the following:
Parameter verbose( // use verbose as a bool in code
false, "verbose output", // default value & help string
Option("verbose", "v"),// for cmd line --verbose or -v
Config("section", "key")); // config file [section] key =
Leaving the syntax away from the sample above, the rationale was to keep
the Option and Config uses at one single place. We also kept the use for
the Parameter<> variable as if it was not one.
The approach I've taken now differs in two points:
1. I don't require to use classes provided by library for value access.
You can store "bool" value into a regular variable, if you like.
The need to change type of variable is one aspect in which I
don't like Brad Appleton's library.
2. There's only one name that should be used both on command line an
config file. I'm not sure this is a problem in practice. It if is,
I'll think about a solution. The most obvious one would be to extend
the library via derivation from some classes, but maybe there's a better
way.
Following this, new Config classes can be defined to accomodate every
config file format. Of course, Option and Config are not mandatory, as
in the example above the verbose config option may not be lots usefull.
We also added some Arguments classes, used like Option, to specify
mandatory arguments.
But maybe this is one level above the purpose of this library.
No, that's quite in the scope. Hope you'll be able to comment in more
detail once the library reaches formal review.
Thanks,
Volodya
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Live summary of regression tests.
[2003-01-20] Toon Knapen wrote: >On Monday 20 January 2003 03:14, Rene Rivera wrote: >> In order to make regression test browsing more pleasant for all of us. I >> decided to work up a little script to gather up all the test results that >> get posted to the boost.sourceforge.net site. So browse on over to: >> >> http://boost.sourceforge.net/regression-logs >> >> ..and take a look. >> >> And for those doing regression testing, this a zero maintenance page. Just >> put up the cs-PLATFORM*.html files in there and they'll automatically show > >How come it picked up cs-aix.html and not cs-vacpp6.html. The latter is the >one generated by the new regression test system, the former is still the old >one. I can however rename the latter to cs-.html but since the same >link is used in the 1.29 release, the status does not correspond with the >code at that time anymore ? It picked "cs-vacpp-links.html", there is no "cs-aix-links.html" ;-) What it did not pick was the "cs-vacpp-links_6.html", and that's because of the extra "_6". If those where "cs-vacpp6-links.html" and "cs-vacpp6.html" it would parse those. I'll see if I can change the detection to handle those types of cases. But I have to fix, again, the OpenBSD regression tests firsts. :-( -- grafik - Don't Assume Anything -- [EMAIL PROTECTED] - [EMAIL PROTECTED] -- 102708583@icq ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Problems with boost on Cray C++ release 3.6
On Monday, January 20, 2003, at 04:51 PM, David Abrahams wrote: One other thing worth checking if you can't get a stack trace easily: ./bootstrap.cc/jam0 -d12 You may get enough useful output for us to track down the problem. Here is is. I will send a stack trace as soon as I can get it. I hope this information helps. I already know that the crash is inside var_defines( use_environ ) ./jam0 -sJAMBASE= -sBOOST_ROOT= -sBOOST_BUILD_PATH= -d12 list > axb < list > ayb < list > x < list > y < set xy = x y list > xy < set z = xy expand 'a$(xy)b' expand 'xy' list > xy < expand 'b' list > b < get xy = x y list > axb < list > ayb < expanded to axb ayb expand 'a$($(z))b' expand '$(z)' expand 'z' list > z < get z = xy list > xy < expanded to xy expand 'b' list > b < get xy = x y list > axb < list > ayb < expanded to axb ayb list > Mon Jan 20 16:58:58 2003 < set JAMDATE = Mon Jan 20 16:58:58 2003 list > 03 < list > 01 < list > 03 < set JAM_VERSION = 03 01 03 list > sn9626 < list > athos < list > 10.0.1.1 < list > eth.0 < list > CRAY SV1 < set JAMUNAME = sn9626 athos 10.0.1.1 eth.0 CRAY SV1 list > true < set UNIX = true list > UNICOS < set OS = UNICOS list > 3.1 < set JAMVERSION = 3.1 list > troyer < set USER = troyer list > troyer < set LOGNAME = troyer list > /u/ph/troyer < set HOME = /u/ph/troyer list > /opt/ctl/craylibs/3.6.0.0/bin < list > /opt/ctl/bin < list > /opt/craysoft/nqe/bin < list > /opt/ctl/mpt/mpt/bin < list > /opt/open/open/bin < list > . < list > /bin < list > /usr/bin < list > /usr/ucb < list > /usr/lbin < set PATH = /opt/ctl/craylibs/3.6.0.0/bin /opt/ctl/bin /opt/craysoft/nqe/bin /opt/ctl/mpt/mpt/bin /opt/open/open/bin . /bin /usr/bin /usr/ucb /usr/lbin list > /usr/mail/troyer < set MAIL = /usr/mail/troyer list > /bin/csh < set SHELL = /bin/csh list > MET-1MST,M3.5.0/02:00,M10.5.0/03:00 < set TZ = MET-1MST,M3.5.0/02:00,M10.5.0/03:00 list > 129.132.61.33 < list > 56156 < list > 22 < set SSH_CLIENT = 129.132.61.33 56156 22 list > /dev/ttyp001 < set SSH_TTY = /dev/ttyp001 list > vt100 < set TERM = vt100 list > /tmp/jtmp.000129a < set TMPDIR = /tmp/jtmp.000129a list > csh < set _LOGINSH = csh list > 1 < set NCPUS = 1 list > /opt/modules/modules < set MODULESHOME = /opt/modules/modules list > /opt/modulefiles < list > /opt/modules/modules/modulefiles < set MODULEPATH = /opt/modulefiles /opt/modules/modules/modulefiles list > modules:cf90:cal:CC:CCmathlib:CCtoollib:open:biolib:PrgEnv:mpt:nqe:CC_sv 1.3.6.0.1:cf90_sv1.3.6.0.1:craylibs.3.6.0.0:craytools.3.6.0.0 < set LOADEDMODULES = modules:cf90:cal:CC:CCmathlib:CCtoollib:open:biolib:PrgEnv:mpt:nqe:CC_sv 1.3.6.0.1:cf90_sv1.3.6.0.1:craylibs.3.6.0.0:craytools.3.6.0.0 list > /opt/ctl/biolib/biolib < set BIOLIBDIR = /opt/ctl/biolib/biolib list > /opt/ctl/mpt/mpt/lib:/opt/ctl/biolib/biolib/lib:/opt/ctl/CCtoollib/ CCtoollib/lib:/opt/ctl/CCmathlib/CCmathlib/lib < set LD_LIBRARY_PATH_SV1 = /opt/ctl/mpt/mpt/lib:/opt/ctl/biolib/biolib/lib:/opt/ctl/CCtoollib/ CCtoollib/lib:/opt/ctl/CCmathlib/CCmathlib/lib list > /opt/ctl/mpt/mpt/include:/opt/ctl/biolib/biolib/include:/opt/ctl/ CCtoollib/CCtoollib/CC:/opt/ctl/CCmathlib/CCmathlib/CC < set INCLUDE_PATH_SV1 = /opt/ctl/mpt/mpt/include:/opt/ctl/biolib/biolib/include:/opt/ctl/ CCtoollib/CCtoollib/CC:/opt/ctl/CCmathlib/CCmathlib/CC list > /opt/ctl/craytools/3.6.0.0/man < list > /opt/ctl/craylibs/3.6.0.0/man < list > /opt/ctl/cf90_sv1/3.6.0.1/man < list > /opt/ctl/CC_sv1/3.6.0.1/man < list > /opt/craysoft/nqe/man < list > /opt/ctl/mpt/mpt/man < list > /opt/open/open/man < list > /opt/ctl/CC/CC/man < list > /opt/ctl/cal/cal/man < list > /opt/ctl/cf90/cf90/man < list > /usr/man < list > /opt/modules/modules/man < list > /opt/open/open/man < set MANPATH = /opt/ctl/craytools/3.6.0.0/man /opt/ctl/craylibs/3.6.0.0/man /opt/ctl/cf90_sv1/3.6.0.1/man /opt/ctl/CC_sv1/3.6.0.1/man /opt/craysoft/nqe/man /opt/ctl/mpt/mpt/man /opt/open/open/man /opt/ctl/CC/CC/man /opt/ctl/cal/cal/man /opt/ctl/cf90/cf90/man /usr/man /opt/modules/modules/man /opt/open/open/man Floating exception (core dumped) ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Live summary of regression tests.
[2003-01-20] Rene Rivera wrote: >[2003-01-20] Toon Knapen wrote: > >> >>How come it picked up cs-aix.html and not cs-vacpp6.html. The latter is the > >What it did not pick was the "cs-vacpp-links_6.html", and that's because of >the extra "_6". If those where "cs-vacpp6-links.html" and "cs-vacpp6.html" >it would parse those. > >I'll see if I can change the detection to handle those types of cases. OK, now you can see those test cases also :-) -- grafik - Don't Assume Anything -- [EMAIL PROTECTED] - [EMAIL PROTECTED] -- 102708583@icq ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [jamboost] Re: [boost] Problems with boost on Cray C++ release3.6
Matthias Troyer <[EMAIL PROTECTED]> writes: > Floating exception (core dumped) Can you post a printout of your environment variables, starting with MANPATH? -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: regression tests on Aix
> It picked "cs-vacpp-links.html", there is no "cs-aix-links.html" ;-) > > What it did not pick was the "cs-vacpp-links_6.html", and that's because of > the extra "_6". If those where "cs-vacpp6-links.html" and "cs-vacpp6.html" > it would parse those. Oops I noticed in serious problem in the updates of the Aix status pages. The cs-vacpp-6-full.html has been updated almost every week but cs-vacpp_6.html was not updated (last update in octobre ;-( > > I'll see if I can change the detection to handle those types of cases. No need to. I have to correct some stuff anyway. Just tell me how I need to name my files. I also added the trailing '6' but I'm not sure the status pages for 5 will be updated and thus the '6' may become irrelevant. toon ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Live summary of regression tests.
At 09:53 PM 1/19/2003, Jeff Garland wrote: >Nice! Any explanation why so many more tests on Win32 and BSD (300+) than >on say Linux (~200)? The date is important; since the subinclude feature became available recently people have been adding tests. Thus the December linux tests reported 203 tests but the January 20 run reported 285. Not sure why that is still 20-some less than Win32 and OpenBSD. Could some libraries may be suppressing tests that don't apply? --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [jamboost] Re: [boost] Problems with boost on Cray C++ release3.6
Matthias Troyer <[EMAIL PROTECTED]> writes:
> On Monday, January 20, 2003, at 04:51 PM, David Abrahams wrote:
>> One other thing worth checking if you can't get a stack trace easily:
>>
>> ./bootstrap.cc/jam0 -d12
>>
>> You may get enough useful output for us to track down the problem.
>
> Here is is. I will send a stack trace as soon as I can get it. I hope
> this information helps. I already know that the crash is inside
> var_defines( use_environ )
I think I found a bug. Could you try commenting out this section of
tools/build/jam_src/var.c and trying again? Lines 121-127:
if ( val[1] == '"' && val[len] == '"')
{
string_append_range( buf, val + 2, val + len );
l = list_new( l, newstr( buf->value ) );
string_truncate( buf, 0 );
}
Thanks,
Dave
--
David Abrahams
[EMAIL PROTECTED] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [jamboost] Re: [boost] Problems with boost on Cray C++ release3.6
On Monday, January 20, 2003, at 05:38 PM, David Abrahams wrote: Matthias Troyer <[EMAIL PROTECTED]> writes: Floating exception (core dumped) Can you post a printout of your environment variables, starting with MANPATH? Here are all the variables: USER=troyer LOGNAME=troyer HOME=/u/ph/troyer PATH=/opt/ctl/craylibs/3.6.0.0/bin:/opt/ctl/bin:/opt/craysoft/nqe/bin:/ opt/ctl/mpt/mpt/bin:/opt/open/open/bin:.:/bin:/usr/bin:/usr/ucb:/usr/ lbin MAIL=/usr/mail/troyer SHELL=/bin/csh TZ=MET-1MST,M3.5.0/02:00,M10.5.0/03:00 SSH_CLIENT=129.132.61.33 56156 22 SSH_TTY=/dev/ttyp001 TERM=vt100 TMPDIR=/tmp/jtmp.000129a _LOGINSH=csh NCPUS=1 MODULESHOME=/opt/modules/modules MODULEPATH=/opt/modulefiles:/opt/modules/modules/modulefiles LOADEDMODULES=modules:cf90:cal:CC:CCmathlib:CCtoollib:open:biolib:PrgEnv :mpt:nqe:CC_sv1.3.6.0.1:cf90_sv1.3.6.0.1:craylibs.3.6.0.0:craytools.3.6. 0.0 BIOLIBDIR=/opt/ctl/biolib/biolib LD_LIBRARY_PATH_SV1=/opt/ctl/mpt/mpt/lib:/opt/ctl/biolib/biolib/lib:/ opt/ctl/CCtoollib/CCtoollib/lib:/opt/ctl/CCmathlib/CCmathlib/lib INCLUDE_PATH_SV1=/opt/ctl/mpt/mpt/include:/opt/ctl/biolib/biolib/ include:/opt/ctl/CCtoollib/CCtoollib/CC:/opt/ctl/CCmathlib/CCmathlib/CC MANPATH=/opt/ctl/craytools/3.6.0.0/man:/opt/ctl/craylibs/3.6.0.0/man:/ opt/ctl/cf90_sv1/3.6.0.1/man:/opt/ctl/CC_sv1/3.6.0.1/man:/opt/craysoft/ nqe/man:/opt/ctl/mpt/mpt/man:/opt/open/open/man:/opt/ctl/CC/CC/man:/ opt/ctl/cal/cal/man:/opt/ctl/cf90/cf90/man:/usr/man:/opt/modules/ modules/man:/opt/open/open/man _LMFILES_=/opt/modulefiles/modules:/opt/modulefiles/cf90:/opt/ modulefiles/cal:/opt/modulefiles/CC:/opt/modulefiles/CCmathlib:/opt/ modulefiles/CCtoollib:/opt/modulefiles/open:/opt/modulefiles/biolib:/ opt/modulefiles/PrgEnv:/opt/modulefiles/mpt:/opt/modulefiles/nqe:/opt/ modulefiles/CC_sv1.3.6.0.1:/opt/modulefiles/cf90_sv1.3.6.0.1:/opt/ modulefiles/craylibs.3.6.0.0:/opt/modulefiles/craytools.3.6.0.0 LD_LIBRARY_PATH_YMP=/opt/ctl/mpt/mpt/lib:/opt/ctl/biolib/biolib/lib INCLUDE_PATH_YMP=/opt/ctl/mpt/mpt/include:/opt/ctl/biolib/biolib/include CAL_PVP=/opt/ctl/cal/cal NLSPATH=/opt/ctl/craytools/3.6.0.0/nls/En/%N.cat:/opt/ctl/craytools/ 3.6.0.0/nls/%l/%N.cat:/opt/ctl/craylibs/3.6.0.0/nls/En/%N.cat:/opt/ctl/ cf90_sv1/3.6.0.1/nls/En/%N.cat:/opt/ctl/CC_sv1/3.6.0.1/nls/En/%N.cat:/ opt/ctl/mpt/mpt/nls/En/%N.cat:/opt/ctl/CC/CC/nls/En/%N.cat:/opt/ctl/ cal/cal/nls/En/%N.cat:/opt/ctl/cf90/cf90/nls/En/%N.cat:/opt/ctl/nls/%l/ %N.cat:/opt/ctl/nls/En/%N.cat CC_PVP=/opt/ctl/CC/CC _MODULESBEGINENV_=/u/ph/troyer/.modulesbeginenv MPTDIR=/opt/ctl/mpt/mpt PVM_ROOT=/opt/ctl/mpt/mpt/pvm3 LIBCM=-D_MULTIP_ -L/opt/ctl/mpt/mpt/lib/multi PVM_ARCH=CRAY NQE_DIR=/opt/craysoft/nqe VNI_ARCH=cray-sv1 LIB_ARCH=cray-sv1 CRAY_MPI_DIR=/opt/ctl/mpt/mpt CTT_DIR=/usr/lbin/IMSL CTT_EXAMPLES=/usr/lbin/IMSL/examples/cray-sv1 F90FLAGS=-O 2,nofastint -I/opt/ctl/mpt/mpt/include FFLAGS=-O 2,nofastint FC=f90 F90=f90 MPIF90=f90 VNI_F90_MSG=/usr/lbin/IMSL/bin/cray-sv1 LINK_F90=-p /usr/lbin/IMSL/lib/lib.cray-sv1 -L/usr/lbin/IMSL/lib/lib.cray-sv1 -limsl -limsls_err -limslblas -limslmpistub LINK_F90_CRAY=-p /usr/lbin/IMSL/lib/lib.cray-sv1 -L/usr/lbin/IMSL/lib/lib.cray-sv1 -limsl -limsls_err -limslmpistub /opt/ctl/craylibs/craylibs/libsci.a LINK_MPI=/usr/lbin/IMSL/lib/lib.cray-sv1/mpi_initialized.o -p /usr/lbin/IMSL/lib/lib.cray-sv1 -L/usr/lbin/IMSL/lib/lib.cray-sv1 -limsl -limslp_err -limslblas -limsl -L/opt/ctl/mpt/mpt/lib -lmpi -lmp LINK_MPI_CRAY=/usr/lbin/IMSL/lib/lib.cray-sv1/mpi_initialized.o -p /usr/lbin/IMSL/lib/lib.cray-sv1 -L/usr/lbin/IMSL/lib/lib.cray-sv1 -limsl -limslp_err /opt/ctl/craylibs/craylibs/libsci.a -L/opt/ctl/mpt/mpt/lib -lmpi -lmp LINK_MPIS=/usr/lbin/IMSL/lib/lib.cray-sv1/mpi_initialized.o -p /usr/lbin/IMSL/lib/lib.cray-sv1 -L/usr/lbin/IMSL/lib/lib.cray-sv1 -limsl -limsls_err -limslblas LINK_MPIS_CRAY=/usr/lbin/IMSL/lib/lib.cray-sv1/mpi_initialized.o -p /usr/lbin/IMSL/lib/lib.cray-sv1 -L/usr/lbin/IMSL/lib/lib.cray-sv1 -limsl -limsls_err /opt/ctl/craylibs/craylibs/libsci.a -L/opt/ctl/mpt/mpt/lib -lmpi -lmp LINK_FNL=-p /usr/lbin/IMSL/lib/lib.cray-sv1 -L/usr/lbin/IMSL/lib/lib.cray-sv1 -limsl -limsls_err -limslblas -limslmpistub LINK_FNL_CRAY=-p /usr/lbin/IMSL/lib/lib.cray-sv1 -L/usr/lbin/IMSL/lib/lib.cray-sv1 -limsl -limsls_err -limslmpistub /opt/ctl/craylibs/craylibs/libsci.a SEGDIR=DUPENTRY=IGNORE;MSGLEVEL=167:NOTE CC_SV1=/opt/ctl/CC_sv1/3.6.0.1 CF90_SV1=/opt/ctl/cf90_sv1/3.6.0.1 CRAYLIBS_SV1=/opt/ctl/craylibs/3.6.0.0 CRAYLIBS_YMP=/opt/ctl/craylibs/3.6.0.0/ylib CTOOLSDIR=/opt/ctl/craytools/3.6.0.0 CVS_RSH=ssh CVSROOT=:ext:[EMAIL PROTECTED]:/home/troyer/cvsroot DISPLAY=ogdoad.ethz.ch:0. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: regression tests on Aix
[2003-01-20] Toon Knapen wrote: >> It picked "cs-vacpp-links.html", there is no "cs-aix-links.html" ;-) >> >> What it did not pick was the "cs-vacpp-links_6.html", and that's because of >> the extra "_6". If those where "cs-vacpp6-links.html" and "cs-vacpp6.html" >> it would parse those. > >Oops I noticed in serious problem in the updates of the Aix status pages. The >cs-vacpp-6-full.html has been updated almost every week but cs-vacpp_6.html >was not updated (last update in octobre ;-( > >> >> I'll see if I can change the detection to handle those types of cases. >No need to. I have to correct some stuff anyway. Just tell me how I need to >name my files. I also added the trailing '6' but I'm not sure the status >pages for 5 will be updated and thus the '6' may become irrelevant. Sure, the matching is now very simple it looks for a file of the form: "*links*.html". Which it matches to its correponding "**.html". As long as it matches that it will attempt to display the summary. -- grafik - Don't Assume Anything -- [EMAIL PROTECTED] - [EMAIL PROTECTED] -- 102708583@icq ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: regression tests on Aix
On Monday 20 January 2003 18:16, Rene Rivera wrote: > >No need to. I have to correct some stuff anyway. Just tell me how I need > > to name my files. I also added the trailing '6' but I'm not sure the > > status pages for 5 will be updated and thus the '6' may become > > irrelevant. > > Sure, the matching is now very simple it looks for a file of the form: > "*links*.html". Which it matches to its correponding "**.html". As long as > it matches that it will attempt to display the summary. OK. Now my question is (mostly to Beman) : Are status-pages also supposed to be versioned ? toon ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Preliminary submission: command line & config fil e library
> You still need to remember something. For example, your library uses ","
> to separate elements of std::list<...> parameter. Can I guess that from
the
> options declaration?
It has almost nothing to do with parameter definition. It's details of
argument parsing format. You may though specify it explicitly by naming the
interpreter for your parameter, like this:
cla::named_parameter, space_separated_list>
> Can I guess what "multiplicable" is?
I think it's pretty obvious. If not I may change name to more
expressive/clear if you know one.
> With your proposal it would look something like
>
> parser << named_parameter<>("output") << short_name<>("o") <<
> value_name("file") << description("where to send output")
>
> And it should be repeated for each option.
in fact:
parser
<< dual_named_parameter<>( "output", "o" )
<< format_descr( "file" )
<< description( "where to send output" );
In your case:
desc3.add_options()
("output,o", "file", "where to send output")
The only differences are is that I explicitly specify what does these
strings mean and I allow different kinds of parameters (positional for
example).
> Does key_lookup_policy support short options? No.
But dual_lookup_policy does. program_options may use this policy. I
personally prefer to use key_lookup_policy with guessing_key_policy. I do
not need to remember 2 independent names and could specify long or short
name.
> Therefore program_options cannot support them either. So, if I want to
handle both command line
> and config file I have to give up something very handy.
That is not correct as it follows from above.
>
>
> - Volodya
Gennadiy.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Live summary of regression tests.
On Sunday 19 January 2003 07:14 pm, Rene Rivera wrote: > The Linux tests don't use the new regression programs? Now they do :-) -- Alkis ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Live summary of regression tests.
>The date is important; since the subinclude feature became available >recently people have been adding tests. What is the subinclude feature and where is it documented? Jeff ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost as charity-ware
Just a reminder that Boost is freely licensed, so that nothing stops anyone from putting together a Boost distribution and exchanging copies of it for donations to whatever charity they want, or to their own pockets. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: A question about static_log2
On Mon, 20 Jan 2003 00:08:33 +0200, "Vesa Karvonen"
<[EMAIL PROTECTED]> wrote:
>Gennaro Prota:
>>Can someone who was subscribed when the Integer library was approved
>>explain me what were the reasons to choose the current implementation
>>of static_log2 against e.g.
>
>I can't help in that, but
>
>> template
>> struct log2 {
>> BOOST_STATIC_CONSTANT(unsigned long,
>> value = 1 + (log2::value));
>> };
>>
>> template <>
>> struct log2<1> {
>> BOOST_STATIC_CONSTANT(unsigned long, value = 0);
>> };
>
>the above algorithm is inefficient
> and should not be used. Consider the
>following algorithm instead:
>
>#include
>#include
>
>template int n = sizeof(unsigned long) * CHAR_BIT / 2>
>struct log2 {
>private:
> enum {c = (1 << n) <= x};
Wrong. The left-shift may give undefined behavior, because n can be
greater than or equal to the number of value bits in an unsigned long
(The C++ standard isn't clear about this, and I have a DR ready in the
oven since a long time)
>public:
> enum {value = c*n + log2<(x>>(c*n)),(n/2)>::value};
Same as above.
The value you want here is not
sizeof(unsigned long) * CHAR_BIT / 2
but
std::numeric_limits::digits / 2
Alternatively you could use my width<> or my precision<> template, if
it wasn't that they in turn use log2. The problem is that the C
standard (and so C++) provides a xx_BIT macro only for the type char.
You don't have e.g. INT_BIT or LONG_BIT, and you can't use
CHAR_BIT*sizeof(int) and CHAR_BIT*sizeof(long) in their place, at
least not portably, because those expressions give you the number of
bits in the object representation, and that's not necessarily the same
as the number of bits used to represent values. One way to remain
portable is to compute such a number by calculating, for a given
integer type, 1 + the integral part of the log2 of its maximum value
(this in turn relies on other properties guaranteed by the C language
but I don't think I have to explain such basics here).
PS: Another problem with your implementation I'll leave it as an
exercise ;-) This is a hint:
log2 (511)
| 4 + log2<31, 2>
|--- 2 + log2<7, 1>
|--- 1 + log2<3, 0> // oops...
Genny.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Interval library merge
At 09:55 AM 1/20/2003, David Abrahams wrote: >Guillaume Melquiond <[EMAIL PROTECTED]> writes: >> but before that, something must be decided: where to put the >> library? >> >> This question was already discussed on this mailing-list some times ago, >> but no clear answer was given at that time. The library directory is >> actually directly under boost. To avoid cluttering the root, it would >> probably be better to put it somewhere else; for example, boost/math or >> boost/numeric. Unfortunately, the library has some good reasons to be >> put >> in each of these directories. So I suggest it is put in boost/numeric >> (heads or tails). >> >> Subsidiary question: should the namespace tree follow the directory tree? >> I think it should; but since I will need a few hours to correct the whole >> source and documentation (it isn't as easy as changing the #include at >> the top of the files), I prefer to ask beforehand. I don't have a strong opinion, but mildly favor boost/numeric with namespace tree following directory tree. --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Live summary of regression tests.
At 04:08 AM 1/20/2003, Toon Knapen wrote: >On Monday 20 January 2003 03:14, Rene Rivera wrote: >> In order to make regression test browsing more pleasant for all of us. I >> decided to work up a little script to gather up all the test results that >> get posted to the boost.sourceforge.net site. So browse on over to: >> >> http://boost.sourceforge.net/regression-logs >> >> ..and take a look. > >Very very handy ! Did you put the link also in the doc in CVS somewhere >? Done. --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Live summary of regression tests.
At 05:42 AM 1/20/2003, Alisdair Meredith wrote: >Rene Rivera wrote: > >> In order to make regression test browsing more pleasant for all of us. I >> decided to work up a little script to gather up all the test results that >> get posted to the boost.sourceforge.net site. So browse on over to: >> >> http://boost.sourceforge.net/regression-logs >> >> ..and take a look. > >Cool! > >I find it rather surpsing that there are no warnings at all on the >Windows platform though. Borland in particular can be quite chatty. Hum... That's happening because the summary is being driven by a version of the Win32 reports which has warnings suppressed. We'll need to do some coordination on that. Need to think about the difference between tests to be reported with a release, and daily CVS tests (which clearly do need warnings enabled.) --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Policy-based smart pointers revisisted
"Sam Partington" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > If they had to decide > whether to use shared_ptr, or slightly_faster_ptr, I think they would simply > not bother. But it's not just "slightly faster". This is a misconception. For example, COM or CORBA pointers are not (or at least were not) usable with shared_ptr. > Also, I can't see any future standard having more than one new pointer, and > I can't see anything but the already widely used shared_ptr being it. It turns out that they would so much more prefer a truly extensible solution. If I remember correctly, it was all about policy-based smart pointers at the last two standards meetings. For them it's all the more appealing because they can package it with template typedefs, feature that would change the slate completely. However, if the boost community does not support, or openly opposes, pbsp's, then the committee's opinion might change. > There seems to me to be a very significant difference between > smart_ptr -> smart_ptr, smart_ptr_A -> smart_ptr_B. > The first is simply a cast and an attachment to the reference count. But > the second requires that every strategy policy understands how to make use > of every other strategy policy. i.e. for the following to work: > > smart_ptr f(); > ... > smart_ptr a = f(); > > my_own_counting_policy needs to understand what my_own_cloning_policy does, > and how to safely attach to it. The problem becomes exponential with each > policy added. I love a good argument, but when it is based. Pbsp's don't have exponential problems, they /solve/ exponential problems with linear effort. There are coherent ways to convert from one policy to another, some explained in mc++d, and some more refined ones developed later. > As we've mentioned loki, is there any update on Loki -> boost integration? > A quick check of the archives and nothing seems to have been mentioned since > may or so. My feeling is that the boost community would of course be interested in looking over a related submission, but most of its members are not interested in actively working on such a port. And let's face it, I'm not popular with boost, and that doesn't help generating enthusiasm inside boost :o). I don't have the time to work on a port, and the way things are shaping up, it seems like I'll never have. In the meantime, there is of course some cross-polination going on. I am personally a bit more into KISS than I probably should, which is funny given that pbsp's are rejected on grounds of not being KISSed enough :o). Andrei ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: A question about static_log2
I've done some tests with gcc, which has an option to show the time
taken by each subprocess in the compilation sequence. Results and test
program are below. The file log2_impl.hpp contained either the trivial
implementation I've posted before, or Vesa's one, or a simple #include
"boost/static_log2.hpp". In the case of Vesa's implementation I
avoided inclusion of by simple replacing
sizeof(unsigned long) * CHAR_BIT / 2
with the literal 16.
Results are:
- trivial
$ g++ -I"...boost_1_29_0" -time log.cpp
# cc1plus 0.49 0.61
# as 0.04 0.09
# collect2 0.36 1.24
-vesa
$ g++ -I"...boost_1_29_0" -time log.cpp
# cc1plus 0.71 0.71
# as 0.05 0.07
# collect2 0.37 1.43
- boost::static_log2
$ g++ -I"...boost_1_29_0" -time log.cpp
# cc1plus 3.14 0.91
# as 0.05 0.07
# collect2 0.41 1.29
-- Test program
#include "log2_impl.hpp"
#include "boost/static_assert.hpp"
//#define log2 boost::static_log2
#define BOOST_INT_CONST_LOG2_TEST(val, result) \
BOOST_STATIC_ASSERT( log2::value == result)
#ifdef BOOST_INT_CONST_LOG2_TEST_FOR_ZERO
enum { dummy = log2<0>::value }; // should give an error
#endif
int main()
{
// Test on 2**n and 2**n - 1
BOOST_INT_CONST_LOG2_TEST(1, 0);
BOOST_INT_CONST_LOG2_TEST(2, 1);
BOOST_INT_CONST_LOG2_TEST(3, 1);
BOOST_INT_CONST_LOG2_TEST(4, 2);
BOOST_INT_CONST_LOG2_TEST(7, 2);
BOOST_INT_CONST_LOG2_TEST(8, 3);
BOOST_INT_CONST_LOG2_TEST(15, 3);
BOOST_INT_CONST_LOG2_TEST(16, 4);
BOOST_INT_CONST_LOG2_TEST(31, 4);
BOOST_INT_CONST_LOG2_TEST(32, 5);
BOOST_INT_CONST_LOG2_TEST(63, 5);
BOOST_INT_CONST_LOG2_TEST(64, 6);
BOOST_INT_CONST_LOG2_TEST(127, 6);
BOOST_INT_CONST_LOG2_TEST(128, 7);
BOOST_INT_CONST_LOG2_TEST(255, 7);
BOOST_INT_CONST_LOG2_TEST(256, 8);
BOOST_INT_CONST_LOG2_TEST(511, 8);
BOOST_INT_CONST_LOG2_TEST(512, 9);
BOOST_INT_CONST_LOG2_TEST(1023, 9);
BOOST_INT_CONST_LOG2_TEST(1024, 10);
BOOST_INT_CONST_LOG2_TEST(2047, 10);
BOOST_INT_CONST_LOG2_TEST(2048, 11);
BOOST_INT_CONST_LOG2_TEST(4095, 11);
BOOST_INT_CONST_LOG2_TEST(4096, 12);
BOOST_INT_CONST_LOG2_TEST(8191, 12);
BOOST_INT_CONST_LOG2_TEST(8192, 13);
BOOST_INT_CONST_LOG2_TEST(16383, 13);
BOOST_INT_CONST_LOG2_TEST(16384, 14);
BOOST_INT_CONST_LOG2_TEST(32767, 14);
BOOST_INT_CONST_LOG2_TEST(32768, 15);
BOOST_INT_CONST_LOG2_TEST(65535, 15);
BOOST_INT_CONST_LOG2_TEST(65536, 16);
BOOST_INT_CONST_LOG2_TEST(131071, 16);
BOOST_INT_CONST_LOG2_TEST(131072, 17);
BOOST_INT_CONST_LOG2_TEST(262143, 17);
BOOST_INT_CONST_LOG2_TEST(262144, 18);
BOOST_INT_CONST_LOG2_TEST(524287, 18);
BOOST_INT_CONST_LOG2_TEST(524288, 19);
BOOST_INT_CONST_LOG2_TEST(1048575, 19);
BOOST_INT_CONST_LOG2_TEST(1048576, 20);
BOOST_INT_CONST_LOG2_TEST(2097151, 20);
BOOST_INT_CONST_LOG2_TEST(2097152, 21);
BOOST_INT_CONST_LOG2_TEST(4194303, 21);
BOOST_INT_CONST_LOG2_TEST(4194304, 22);
BOOST_INT_CONST_LOG2_TEST(8388607, 22);
BOOST_INT_CONST_LOG2_TEST(8388608, 23);
BOOST_INT_CONST_LOG2_TEST(16777215, 23);
BOOST_INT_CONST_LOG2_TEST(16777216, 24);
BOOST_INT_CONST_LOG2_TEST(33554431, 24);
BOOST_INT_CONST_LOG2_TEST(33554432, 25);
BOOST_INT_CONST_LOG2_TEST(67108863, 25);
BOOST_INT_CONST_LOG2_TEST(67108864, 26);
BOOST_INT_CONST_LOG2_TEST(134217727, 26);
BOOST_INT_CONST_LOG2_TEST(134217728, 27);
BOOST_INT_CONST_LOG2_TEST(268435455, 27);
BOOST_INT_CONST_LOG2_TEST(268435456, 28);
BOOST_INT_CONST_LOG2_TEST(536870911, 28);
BOOST_INT_CONST_LOG2_TEST(536870912, 29);
BOOST_INT_CONST_LOG2_TEST(1073741823, 29);
BOOST_INT_CONST_LOG2_TEST(1073741824, 30);
BOOST_INT_CONST_LOG2_TEST(2147483647, 30);
BOOST_INT_CONST_LOG2_TEST(2147483648u, 31);
BOOST_INT_CONST_LOG2_TEST(4294967295u, 31);
// Ok, now test again
BOOST_INT_CONST_LOG2_TEST(1, 0);
BOOST_INT_CONST_LOG2_TEST(2, 1);
BOOST_INT_CONST_LOG2_TEST(3, 1);
BOOST_INT_CONST_LOG2_TEST(4, 2);
BOOST_INT_CONST_LOG2_TEST(7, 2);
BOOST_INT_CONST_LOG2_TEST(8, 3);
BOOST_INT_CONST_LOG2_TEST(15, 3);
BOOST_INT_CONST_LOG2_TEST(16, 4);
BOOST_INT_CONST_LOG2_TEST(31, 4);
BOOST_INT_CONST_LOG2_TEST(32, 5);
BOOST_INT_CONST_LOG2_TEST(63, 5);
BOOST_INT_CONST_LOG2_TEST(64, 6);
BOOST_INT_CONST_LOG2_TEST(127, 6);
BOOST_INT_CONST_LOG2_TEST(128, 7);
BOOST_INT_CONST_LOG2_TEST(255, 7);
BOOST_INT_CONST_LOG2_TEST(256, 8);
BOOST_INT_CONST_LOG2_TEST(511, 8);
BOOST_INT_CONST_LOG2_TEST(512, 9);
BOOST_INT_CONST_LOG2_TEST(1023, 9);
BOOST_INT_CONST_LOG2_TEST(1024, 10);
BOOST_INT_CONST_LOG2_TEST(2047, 10);
BOOST_INT_CONST_LOG2_TEST(2048, 11);
BOOST_INT_CONST_LOG2_TEST(4095, 11);
BOOST_INT_CONST_LOG2_TEST(4096, 12);
BOOST_INT_CONST_LOG2_TEST(8191, 12);
BOOST_INT_CONST_LOG2_TEST(8192, 13);
BOOST_INT_CONST_LOG2_TEST(16383, 13);
BOOST_INT_CONST_LOG2_TEST
RE: [boost] Live summary of regression tests.
At 12:38 PM 1/20/2003, Jeff Garland wrote: > >>The date is important; since the subinclude feature became available >>recently people have been adding tests. > >What is the subinclude feature and where is it documented? I've just updated the regression docs in CVS. See http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/boost/boost/more/regression.html?rev=1.8 --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Policy-based smart pointers revisisted
"Andrei Alexandrescu" <[EMAIL PROTECTED]> writes:
> "Sam Partington" <[EMAIL PROTECTED]> wrote in message
> [EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
>> If they had to decide
>> whether to use shared_ptr, or slightly_faster_ptr, I think they would
> simply
>> not bother.
>
> But it's not just "slightly faster". This is a misconception. For example,
> COM or CORBA pointers are not (or at least were not) usable with shared_ptr.
Using a shared_ptr to Hold a Pointer to a COM Object
[COM objects have an embedded reference count, AddRef() and Release(),
Release() self-destroys when reference count drops to zero.]
shared_ptr make_shared_from_COM(IWhatever * p)
{
p->AddRef();
shared_ptr pw(p, mem_fn(&IWhatever::Release));
return pw;
}
[All pw copies will share a single reference.]
Or did you mean something else?
>> Also, I can't see any future standard having more than one new
>> pointer, and I can't see anything but the already widely used
>> shared_ptr being it.
>
> It turns out that they would so much more prefer a truly extensible
> solution. If I remember correctly, it was all about policy-based
> smart pointers at the last two standards meetings. For them it's all
> the more appealing because they can package it with template
> typedefs, feature that would change the slate completely. However,
> if the boost community does not support, or openly opposes, pbsp's,
> then the committee's opinion might change.
Andrei, I really wish you would stop framing it that way; it just adds
a lot of unneccessary political static to the discussion. Nobody has
even brought forward a formal proposal for a pbsp for boost, or AFAIK
for the standard. It's not as though there is some conspiracy of
unjust and closed-minded refusal to consider such a design around
either community. It's premature to be injecting that implication,
and frankly, it doesn't help your case.
If you really care about this, why don't you work on making a boost
submission or bringing a proposal to the committee for the next
meeting?
>> As we've mentioned loki, is there any update on Loki -> boost
>> integration? A quick check of the archives and nothing seems to
>> have been mentioned since may or so.
>
> My feeling is that the boost community would of course be interested
> in looking over a related submission, but most of its members are
> not interested in actively working on such a port. And let's face
> it, I'm not popular with boost, and that doesn't help generating
> enthusiasm inside boost :o).
I think your perception that your unpopular with boost does more to
hurt your ability to generate enthusiasm than any actual
unpopularity. You seem to have the attitude that the cards are
stacked against you, and to approach boost with a kind of resentment
and resignation that you won't get a fair hearing.
You have made real contributions to the work of many people here; I
know the iterator adaptors library would never have arisen as it did
without ideas you sparked years ago about policy-based design. Why
not apply your great intelligence, humour, and ability to communicate
as productively around here as you do elsewhere?
--
David Abrahams
[EMAIL PROTECTED] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [jamboost] Re: [boost] Problems with boost on Cray C++ release3.6
Matthias Troyer <[EMAIL PROTECTED]> writes: > On Monday, January 20, 2003, at 05:38 PM, David Abrahams wrote: > >> Matthias Troyer <[EMAIL PROTECTED]> writes: >> >>> Floating exception (core dumped) >> >> Can you post a printout of your environment variables, starting with >> MANPATH? > > Here are all the variables: Well, I don't have a clue. We'll have to look at the stack trace. -Dave -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: regression tests on Aix
At 12:33 PM 1/20/2003, Toon Knapen wrote: >On Monday 20 January 2003 18:16, Rene Rivera wrote: >> >No need to. I have to correct some stuff anyway. Just tell me how I need >> > to name my files. I also added the trailing '6' but I'm not sure the >> > status pages for 5 will be updated and thus the '6' may become >> > irrelevant. >> >> Sure, the matching is now very simple it looks for a file of the form: >> "*links*.html". Which it matches to its correponding "**.html". As long >as >> it matches that it will attempt to display the summary. > >OK. > >Now my question is (mostly to Beman) : Are status-pages also supposed to be >versioned ? By "versioned" do you mean committed to CVS? Not on a daily basis, because of the space implications. OTHO, it is nice to have a set in CVS at the time of each release. We probably need to discuss these issues. It is only fairly recently we began running tests daily, so we haven't really come to grips with all the issues that raises. --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] shifted_ptr<> -> gc_ptr<> + doc
Greeting, I have renamed shifted_ptr<> to gc_ptr<> so that its name becomes more descriptive. You can see its main documentation in Class Hierarchy -> boost::gc_ptr< T, U > (in doc/index.html): http://groups.yahoo.com/group/boost/files/gc_ptr.zip I hope it helps introducing the concept. Thanks, Philippe A. Bouchard ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Policy-based smart pointers revisisted
- Original Message - From: "David Abrahams" <[EMAIL PROTECTED]> > If you really care about this, why don't you work on making a boost > submission or bringing a proposal to the committee for the next > meeting? By all means. A policy-based smart pointer doesn't mandate the inclusion of all of Loki--even though there is much in Loki that is worth looking at. > > My feeling is that the boost community would of course be interested > > in looking over a related submission, but most of its members are > > not interested in actively working on such a port. And let's face > > it, I'm not popular with boost, and that doesn't help generating > > enthusiasm inside boost :o). > > I think your perception that your unpopular with boost does more to > hurt your ability to generate enthusiasm than any actual > unpopularity. You seem to have the attitude that the cards are > stacked against you, and to approach boost with a kind of resentment > and resignation that you won't get a fair hearing. I don't want to propagate a war here, but Andrei's perception (of his perception) is not entirely unfounded either. In the past, Andrei has raised some practical concerns with certain design strategies. At that time, his opinion was derided based entirely on, from my perspective, religious devotion to an unproven concept. Andrei asked for practical examples of the utility of those design strategies, and he was effectively told, "If you don't like it, don't use it." I don't want to get into that old argument again, and that is not my intention. I'm merely pointing out that Andrei got flack for presenting an opinion counter to many Boost developers' and standing by that opinion. The fact is that there are many things that various Boost developers will argue over with religious fervor (i.e. another way of saying "political"), and I simply don't believe that people are entirely objective. Their preferences influence their beliefs, and people typically don't take criticism well. That is to be expected. Such is life. The same thing looks like it is happening here with policy-based smart pointers. It seems to me that arguments are being manufactured to preclude the concept of a policy-based smart pointer (such as incompatibilities and the supposed complexity of interface--neither of which I personally think is significant) precisely because it isn't 'shared_ptr' or that it would subsume 'shared_ptr'. That may or may not be the case, but that is how it comes off to me, and I can see how it would come off that way to others. This is precisely why I think that we need both forms. When experts disagree fundamentally on such a concept, both forms should be supported--and there is no question that both Dave and Andrei (and many others here) are experts. If one or the other rarely gets used, then we can revisit that decision at a later date. > You have made real contributions to the work of many people here; I > know the iterator adaptors library would never have arisen as it did > without ideas you sparked years ago about policy-based design. Why > not apply your great intelligence, humour, and ability to communicate > as productively around here as you do elsewhere? Yes, definitely, and there is plenty of credit to go around. I purposefully read every post that Andrei submits to this list--often times because he is humorous as well as intelligent. It is also obvious that Andrei makes an effort to be civil when he disagrees (as do many others), but I think that sometimes he gets frustrated when people don't understand (or even see) his point of view. Actually, that goes for everyone here, and everyone needs to keep that in mind and take disagreement with a grain of salt. Paul Mensonides ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] is_convertible corner case
It seems to me that the current implementation of is_convertible will conclude that int* is convertible to int[10]. That's because when a function parameter is of array type, it is treated just like a pointer. But according to 4/3 of the standard: "An expression e can be _implicitly converted_ to a type T if an only if the declaration "T t=e;" is well-formed for some invented variable t (8.5)." By this definition, int* is not implicitly convertible to int[10]. So it seems is_convertible is broken in this regard. IMO, is_convertible should always return false when B is an array type. Eric ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: A question about static_log2
On Mon, 20 Jan 2003 19:40:42 +0100, Gennaro Prota
<[EMAIL PROTECTED]> wrote:
>> enum {c = (1 << n) <= x};
>
>
>Wrong. The left-shift may give undefined behavior, because n can be
>greater than or equal to the number of value bits in an unsigned long
^
In an int, sorry. I was thinking to the case below
>> enum {value = c*n + log2<(x>>(c*n)),(n/2)>::value};
where the left operand of >> has, of course, type unsigned long.
Genny.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] another is_convertible corner case
By the same reasoning, is_convertible should evaluate to true, since a function type is implicitly convertible to its pointer type. But given the current implementation (1.29.0), is_convertible doesn't compile. Opinions? Is this just too nit-picky? Eric ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [jamboost] Re: [boost] Problems with boost on Cray C++ release3.6
This did not help but I'm getting closer. I don't have a full trace
back but the debugger tells me that it happens in line 99 of file
hash.c:
char *b = (*data)->key;
Since the problem vanishes when I turn off optimization (-O0), I'm not
sure whether it is a compiler or jam bug. I will forward the problem to
our local Cray analyst tomorrow. All I can think of right now is that
maybe somewhere a variable does maybe not get initialized properly when
optimization is turned on.
On Monday, January 20, 2003, at 06:01 PM, David Abrahams wrote:
I think I found a bug. Could you try commenting out this section of
tools/build/jam_src/var.c and trying again? Lines 121-127:
if ( val[1] == '"' && val[len] == '"')
{
string_append_range( buf, val + 2, val + len );
l = list_new( l, newstr( buf->value ) );
string_truncate( buf, 0 );
}
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Policy-based smart pointers revisisted
"Paul Mensonides" <[EMAIL PROTECTED]> writes: > - Original Message - > From: "David Abrahams" <[EMAIL PROTECTED]> > >> If you really care about this, why don't you work on making a boost >> submission or bringing a proposal to the committee for the next >> meeting? > > By all means. A policy-based smart pointer doesn't mandate the inclusion of > all of Loki--even though there is much in Loki that is worth looking at. > >> > My feeling is that the boost community would of course be interested >> > in looking over a related submission, but most of its members are >> > not interested in actively working on such a port. And let's face >> > it, I'm not popular with boost, and that doesn't help generating >> > enthusiasm inside boost :o). >> >> I think your perception that your unpopular with boost does more to >> hurt your ability to generate enthusiasm than any actual >> unpopularity. You seem to have the attitude that the cards are >> stacked against you, and to approach boost with a kind of resentment >> and resignation that you won't get a fair hearing. > > I don't want to propagate a war here, but Andrei's perception (of > his perception) is not entirely unfounded either. In the past, > Andrei has raised some practical concerns with certain design > strategies. At that time, his opinion was derided based entirely > on, from my perspective, religious devotion to an unproven concept. Argument is very different from derision. I think it would be very foolish to deride Andrei's opinions, which usually have something very incisive behind them. > Andrei asked for practical examples of the utility of those design > strategies, and he was effectively told, "If you don't like it, > don't use it." I don't want to get into that old argument again, > and that is not my intention. I'm merely pointing out that Andrei > got flack for presenting an opinion counter to many Boost > developers' and standing by that opinion. I think there's a big difference between flack and disagreement. The fact that some people weren't convinced by Andrei's argument, and that you were, doesn't mean that there's a political bias. A lot more goes into making a particular design appealing to people than logic. People just seem to have different ideas about what's going to work out. To make this concrete, what I think you're referring to is that Andrei made the argument that nobody needs different kinds of compile-time data structures, while other people, drawing on their experience in related domains, thought it was either incorrect or premature to make that conclusion. Even if that was a completely wrong, unfounded, and unreasonable conclusion, there's no reason to think that it was based on anything personal. > The fact is that there are many things that various Boost developers > will argue over with religious fervor (i.e. another way of saying > "political"), and I simply don't believe that people are entirely > objective. Of course they're not. > Their preferences influence their beliefs, and people typically > don't take criticism well. That is to be expected. Such is life. ^^ Well, yes. If you want your arguments to be convincing, it helps to consider how to best deliver them so they can be heard. > The same thing looks like it is happening here with policy-based > smart pointers. It seems to me that arguments are being > manufactured to preclude the concept of a policy-based smart pointer > (such as incompatibilities and the supposed complexity of > interface--neither of which I personally think is significant) Despite the fact that there's some available evidence that it has been significant to some people. Who knows whether or not it's "significant"? It's pure speculation. What we do here is to consider the arguments. > precisely because it isn't 'shared_ptr' or that it would subsume > 'shared_ptr'. As far as I can tell, that's *precisely* how it's been presented historically: "here's a design which can replace shared_ptr and auto_ptr and all the rest". I don't have a strong opinion about whether a PBSP design should subsume shared_ptr or not, BTW. I somehow think that the more I say so, the less I'm believed. > That may or may not be the case, but that is how it comes off to me, > and I can see how it would come off that way to others. With all due respect, that sounds like a knee-jerk reaction to the fact that there's any discussion or disagreement with your point-of-view. Most of the discussion about this particular issue has been very detached AFAICT. > This is precisely why I think that we need both forms. When experts > disagree fundamentally on such a concept, both forms should be > supported--and there is no question that both Dave and Andrei (and > many others here) are experts. But I don't think I have a fundamental disagreement with Andrei on this. Really! How can I convince you? Andrei will tell you that I wrote to hi
[boost] Re: Re: Policy-based smart pointers revisisted
> My feeling is that the boost community would of course be interested in > looking over a related submission, but most of its members are not > interested in actively working on such a port. And let's face it, I'm not > popular with boost, and that doesn't help generating enthusiasm inside boost > :o). I don't have the time to work on a port, and the way things are shaping > up, it seems like I'll never have. In the meantime, there is of course some > cross-polination going on. Unfortunately I am very bust at the moment and was not able to participate in the discussion (even though I initiated it by presenting policy based solution for different task), I would like to remind that exist at least 2 attempts (my and Dave) out there for boostified pbsp. Both are pretty close to complete state. Including suport for boost::shared_ptr functionality. I really want to complete this work and will try to do so in a couple month. I know that Dave also working more or less actively on his version. So I don't think we too far from real submission to boost. Gennadiy. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: Policy-based smart pointers revisisted
"Paul Mensonides" <[EMAIL PROTECTED]> wrote in message 004f01c2c0d5$da16f5a0$4900a8c0@c161550b">news:004f01c2c0d5$da16f5a0$4900a8c0@c161550b... > - Original Message - > From: "David Abrahams" <[EMAIL PROTECTED]> > > > > My feeling is that the boost community would of course be interested > > > in looking over a related submission, but most of its members are > > > not interested in actively working on such a port. And let's face > > > it, I'm not popular with boost, and that doesn't help generating > > > enthusiasm inside boost :o). > > > > I think your perception that your unpopular with boost does more to > > hurt your ability to generate enthusiasm than any actual > > unpopularity. You seem to have the attitude that the cards are > > stacked against you, and to approach boost with a kind of resentment > > and resignation that you won't get a fair hearing. > > I don't want to propagate a war here, but Andrei's perception (of his > perception) is not entirely unfounded either. In the past, Andrei has > raised some practical concerns with certain design strategies. At that > time, his opinion was derided based entirely on, from my perspective, > religious devotion to an unproven concept. Andrei asked for practical > examples of the utility of those design strategies, and he was effectively > told, "If you don't like it, don't use it." I don't want to get into that > old argument again, and that is not my intention. I'm merely pointing out > that Andrei got flack for presenting an opinion counter to many Boost > developers' and standing by that opinion. The fact is that there are many > things that various Boost developers will argue over with religious fervor > (i.e. another way of saying "political"), and I simply don't believe that > people are entirely objective. Their preferences influence their beliefs, > and people typically don't take criticism well. That is to be expected. > Such is life. People disagree with others all the time based on their technical understanding. No one's opinion is exempt from reasonable discussions or arguments over what someone else perceives as the correct solution to a technical problem. I'd argue with William Shakespeare ( or his ghost ) on poetical drama if I though I had an intelligent comment to make or, more to the point, with Bjarne Stroustrup on C++. I am a great admirer of "Modern C++ Design" as I would guess many other C++ programmers also are. That doesn't make Andrei exempt from other's opinions, as I am sure he knows, nor do I believe he really thinks it should be so. But it is strange that he really thinks he is unpopular with Boost, meaning people who use or create Boost libraries. I would guess exactly the opposite since the spur he gave to creative template programming in his book must certainly have influenced many Boost developers. > > The same thing looks like it is happening here with policy-based smart > pointers. It seems to me that arguments are being manufactured to preclude > the concept of a policy-based smart pointer (such as incompatibilities and > the supposed complexity of interface--neither of which I personally think is > significant) precisely because it isn't 'shared_ptr' or that it would > subsume 'shared_ptr'. That may or may not be the case, but that is how it > comes off to me, and I can see how it would come off that way to others. I don't think people are "manufacturing" arguments. They are just bringing up issues, seeking to discuss them, and make intelligent comments about ideas which they care. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Policy-based smart pointers revisisted
- Original Message - From: "David Abrahams" <[EMAIL PROTECTED]> > > I don't want to propagate a war here, but Andrei's perception (of > > his perception) is not entirely unfounded either. In the past, > > Andrei has raised some practical concerns with certain design > > strategies. At that time, his opinion was derided based entirely > > on, from my perspective, religious devotion to an unproven concept. > > Argument is very different from derision. I think it would be very > foolish to deride Andrei's opinions, which usually have something very > incisive behind them. Agreed, but that is more-or-less what happened. Andrei asked for an example that justified the design. No one could produce one. The best anyone could do was say "it's like the STL, so that must be good," and "we might need the generality if the future." Once again, I don't want to get into an argument about this particular issue, I'm only pointing out that people tend to respond harshly when their designs (or favored designs) are questioned. Simple as that. I'm not immune and neither are you. > > Andrei asked for practical examples of the utility of those design > > strategies, and he was effectively told, "If you don't like it, > > don't use it." I don't want to get into that old argument again, > > and that is not my intention. I'm merely pointing out that Andrei > > got flack for presenting an opinion counter to many Boost > > developers' and standing by that opinion. > > I think there's a big difference between flack and disagreement. The > fact that some people weren't convinced by Andrei's argument, and that > you were, doesn't mean that there's a political bias. It isn't completely based on political bias, but it is there nonetheless. It is *always* there in some form or another. Incidently, Andrei was flat out told "if you don't like it, don't use it." That wasn't exactly addressing Andrei's concerns about the design or attempting to reach any sort of consensus. It was a flatout dismissal of Andrei's arguments. Boost is great at making people's opinions feel unwelcome if they don't conform in certain areas. > A lot more goes > into making a particular design appealing to people than logic. > People just seem to have different ideas about what's going to work > out. > > To make this concrete, what I think you're referring to is that Andrei > made the argument that nobody needs different kinds of compile-time > data structures, while other people, drawing on their experience in > related domains, thought it was either incorrect or premature to make > that conclusion. Even if that was a completely wrong, unfounded, and > unreasonable conclusion, there's no reason to think that it was based > on anything personal. I'm not saying that it was based on some type of personal vendetta. I'm saying that people don't like it when someone steps up and calls it like they see it. It is to the point that at various times, opinions are suppressed to keep from getting into a big controversy. That is self-defeating. > > The fact is that there are many things that various Boost developers > > will argue over with religious fervor (i.e. another way of saying > > "political"), and I simply don't believe that people are entirely > > objective. > > Of course they're not. > > > Their preferences influence their beliefs, and people typically > > don't take criticism well. That is to be expected. Such is life. > ^^ > Well, yes. If you want your arguments to be convincing, it helps to > consider how to best deliver them so they can be heard. Case in point then. Which was the original reason that I posted. Andrei, IMO, has not been treated very nicely here at one time or another. Take that as you like, but that is how I have interpreted various posts. > > The same thing looks like it is happening here with policy-based > > smart pointers. It seems to me that arguments are being > > manufactured to preclude the concept of a policy-based smart pointer > > (such as incompatibilities and the supposed complexity of > > interface--neither of which I personally think is significant) > > Despite the fact that there's some available evidence that it has been > significant to some people. Who knows whether or not it's > "significant"? It's pure speculation. No it isn't. It is my personal opinion, which is exactly what I said. People actually use Loki's smart pointer, so it isn't speculation. > What we do here is to consider > the arguments. Yes, and also engage in little "political wars." It doesn't matter what anyone intended. That is the way things come off sometimes. > > precisely because it isn't 'shared_ptr' or that it would subsume > > 'shared_ptr'. > > As far as I can tell, that's *precisely* how it's been presented > historically: "here's a design which can replace shared_ptr and > auto_ptr and all the rest". > > I don't have a strong opinion about whether a PBSP
Re: [boost] Re: Re: Re: Policy-based smart pointers revisisted
- Original Message - From: "Edward Diener" <[EMAIL PROTECTED]> > People disagree with others all the time based on their technical > understanding. No one's opinion is exempt from reasonable discussions or > arguments over what someone else perceives as the correct solution to a > technical problem. In the example I mention, which was the sequence abstraction design of the MPL, there was a massive debate on the pros and cons of that design. Ultimately, I consensus was never reached because everybody got tired of arguing. That said, the design was (and probably still is) untested in real code, whereas the simpler design was. To that end, Andrei asked anyone to convince him with a practical code sample that justified the design. It never happened. We had a severe case of several experts fundamentally disagreeing. The only possible resolution was to display the validity of the design with an example, but instead, Andrei's concerns where disregarded altogether, and he was basically told to "deal with it." > I'd argue with William Shakespeare ( or his ghost ) > on poetical drama if I though I had an intelligent comment to make or, more > to the point, with Bjarne Stroustrup on C++. ;) > I am a great admirer of "Modern C++ Design" as I would guess many other C++ > programmers also are. That doesn't make Andrei exempt from other's opinions, > as I am sure he knows, nor do I believe he really thinks it should be so. Yes, I know, and that is not my point at all. > But it is strange that he really thinks he is unpopular with Boost, meaning > people who use or create Boost libraries. I would guess exactly the opposite > since the spur he gave to creative template programming in his book must > certainly have influenced many Boost developers. I'm only calling it like I see it, and I'm not trying to offend anyone. Rather, I'm saying I understand exactly why Andrei feels the way he does. > > > > The same thing looks like it is happening here with policy-based smart > > pointers. It seems to me that arguments are being manufactured to > preclude > > the concept of a policy-based smart pointer (such as incompatibilities and > > the supposed complexity of interface--neither of which I personally think > is > > significant) precisely because it isn't 'shared_ptr' or that it would > > subsume 'shared_ptr'. That may or may not be the case, but that is how it > > comes off to me, and I can see how it would come off that way to others. > > I don't think people are "manufacturing" arguments. They are just bringing > up issues, seeking to discuss them, and make intelligent comments about > ideas which they care. My major point with what I said is that it is sometimes difficult to distinguish religious defense of an argument from practical defense of an argument--and both exist. Paul Mensonides ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [Boost-docs] Integrating BoostBook documentation withHTMLdocumentation
At 09:48 PM 1/19/2003, Douglas Gregor wrote: >> -- Footer should have a "revised" date. I like the horizon rule, too. > >A "generated" date would be easy; a "revised" date isn't so easy, because >it's not trivial to figure out when something used in the list changed. For this page it probably isn't a problem, but for regular doc pages I personally like to know the revision date. >> Have you check to verify there won't be any CVS "churn" once this becomes >> something that is checked into CVS? (Unless, of course, there is a real >> change on the page.) > >I'm not expecting this page to go into CVS, but to be autogenerated nightly >along with the rest of the documentation. I guess I'm still unsure how the generated HTML docs are going to be integrated with the rest of the web site and CVS. My understanding was that the docs in formats other than HTML would go on a separate web site, but that the source and HTML would be on the regular site. I assumed that also meant they would be in the regular CVS. --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [Boost-docs] Integrating BoostBook documentation withHTMLdocumentation
On Monday 20 January 2003 01:44 pm, Beman Dawes wrote: > I guess I'm still unsure how the generated HTML docs are going to be > integrated with the rest of the web site and CVS. > > My understanding was that the docs in formats other than HTML would go on a > separate web site, but that the source and HTML would be on the regular > site. I assumed that also meant they would be in the regular CVS. > > --Beman I'm going to assume that library documentation for a particular release is not changed after the release. This is the way we do things now---www.boost.org has the library documentation for 1.29.0. When we release 1.30.0, it will have the 1.30.0 documentation and won't change until we release another version. So here is the suggestion: The documentation source (BoostBook format) will be in CVS. Whatever the stable documentation from the last release is, it will be on the regular site (www.boost.org). On another site (currently www.cs.rpi.edu), there will be a nightly script that keeps an up-to-date CVS tree and regenerates documentation in various formats (including HTML) from CVS. The main page at www.boost.org would look something like this: http://www.cs.rpi.edu/~gregod/boost/index.htm Instead of a single "Documentation" link, we have a link to the documentaiton for the most recently released Boost version, which will be to a local copy of the documentation (e.g., doc/html/libraries.html or libs/libraries.htm). The documentation is static---it may have been generated for the release, but it won't change after that. The second link, "CVS", will always go to www.cs.rpi.edu/~gregod/boost/doc/html/libraries.html (or wherever the nightly documentation generation puts the result). If a user is using Boost from CVS and wants a local copy of the HTML documentation, they should download boost-doc-html.tar.gz and extract it in the same place they checkout Boost CVS. Then the first link under documentation (for the current version) will reference the documentation they download. Doug ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] database library?
I don't recall discussion of a rdbms access library on this list. Have there been any candidates in the past? Oracle OCCI seems pretty modern and might make a good starting point - http://www.csis.gvsu.edu/GeneralInfo/Oracle/appdev.920/a96583/toc.htm Steve ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: Policy-based smart pointers revisisted
On Monday 20 January 2003 09:25 pm, Paul Mensonides wrote: > - Original Message - > From: "Edward Diener" <[EMAIL PROTECTED]> > > > People disagree with others all the time based on their technical > > understanding. No one's opinion is exempt from reasonable discussions or > > arguments over what someone else perceives as the correct solution to a > > technical problem. > > In the example I mention, which was the sequence abstraction design of the > MPL, there was a massive debate on the pros and cons of that design. > Ultimately, I consensus was never reached because everybody got tired of > arguing. That said, the design was (and probably still is) untested in > real code, whereas the simpler design was. To that end, Andrei asked > anyone to convince him with a practical code sample that justified the > design. It never happened. We had a severe case of several experts > fundamentally disagreeing. The only possible resolution was to display the > validity of the design with an example, but instead, Andrei's concerns > where disregarded altogether, and he was basically told to "deal with it." Andrei's concerns were not disregarded. I acted as review manager for MPL when this discussion occurred, and I considered Andrei's comments along with the comments of every other reviewer prior to rendering a decision. In the review results, I commented that the usefulness of the iterator abstraction was not proven, and that only additional experience with the library would tell whether or not the abstraction is useful. You may read my comments here, if you would like: http://aspn.activestate.com/ASPN/Mail/Message/1341450 Andrei's opinion was in the minority, but it was not dismissed. Doug ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Live summary of regression tests.
> >What is the subinclude feature and where is it documented? > >I've just updated the regression docs in CVS. See >http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/boost/boost/more/regression. >html?rev=1.8 Hey this is great, no more 'singleton' jam files for tests! Fortunately I just checked in a test/Jamfile for date_time :-) Jeff ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] database library?
At Tuesday, 21 January 2003, you wrote: >I don't recall discussion of a rdbms access >library on this list. Have there been any >candidates in the past? There have been some discussions in the past, but nothing too serious. >Oracle OCCI seems pretty modern and might >make a good starting point - >http://www.csis.gvsu.edu/GeneralInfo/Oracle/appdev.920/a96583/toc.htm You might have a look at DTL (Database Template Library) and OTL (Oracle/ODBC Template Library). -- http://dtemplatelib.sourceforge.net/index.htm -- http://otl.sourceforge.net/ Jeff ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Policy-based smart pointers revisisted
From: David Abrahams <[EMAIL PROTECTED]>
Date: Mon, 20 Jan 2003 23:34:06 -0500
In-Reply-To: <001a01c2c0f1$a7395940$4900a8c0@c161550b> ("Paul Mensonides"'s
message of "Mon, 20 Jan 2003 18:06:03 -0800")
Message-ID: <[EMAIL PROTECTED]>
Lines: 164
User-Agent: Gnus/5.090007 (Oort Gnus v0.07) Emacs/21.2
(i386-msvc-nt5.1.2600)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
--text follows this line--
"Paul Mensonides" <[EMAIL PROTECTED]> writes:
> From: "David Abrahams" <[EMAIL PROTECTED]>
>
>> Argument is very different from derision. I think it would be very
>> foolish to deride Andrei's opinions, which usually have something very
>> incisive behind them.
>
> Agreed, but that is more-or-less what happened. Andrei asked for an
> example that justified the design. No one could produce one. The
> best anyone could do was say "it's like the STL, so that must be
> good," and "we might need the generality if the future."
That's *not* derision, Paul.
> Once again, I don't want to get into an argument about this
> particular issue, I'm only pointing out that people tend to respond
> harshly when their designs (or favored designs) are questioned.
> Simple as that. I'm not immune and neither are you.
Agreed, but there's no example of harshness here AFAICT.
>> > Andrei asked for practical examples of the utility of those design
>> > strategies, and he was effectively told, "If you don't like it,
>> > don't use it." I don't want to get into that old argument again,
>> > and that is not my intention. I'm merely pointing out that Andrei
>> > got flack for presenting an opinion counter to many Boost
>> > developers' and standing by that opinion.
>>
>> I think there's a big difference between flack and disagreement.
>> The fact that some people weren't convinced by Andrei's argument,
>> and that you were, doesn't mean that there's a political bias.
>
> It isn't completely based on political bias, but it is there
> nonetheless. It is *always* there in some form or another.
> Incidently, Andrei was flat out told "if you don't like it, don't
> use it."
You're claiming somebody said that; fine, I believe you. That's not
"how boost treats Andrei", it's just what somebody said. It's not
particularly sympathetic, I'll grant you that. It could also be
interpreted as a form of the reasonable argument "you don't pay for
this if you don't use it, so what's the harm?"
> That wasn't exactly addressing Andrei's concerns about the design or
> attempting to reach any sort of consensus. It was a flatout
> dismissal of Andrei's arguments. Boost is great at making people's
> opinions feel unwelcome if they don't conform in certain areas.
Probably true; people don't tend to feel their opinions are being
well-received when the majority disagrees with them.
>> > The same thing looks like it is happening here with policy-based
>> > smart pointers. It seems to me that arguments are being
>> > manufactured to preclude the concept of a policy-based smart pointer
>> > (such as incompatibilities and the supposed complexity of
>> > interface--neither of which I personally think is significant)
>>
>> Despite the fact that there's some available evidence that it has been
>> significant to some people. Who knows whether or not it's
>> "significant"? It's pure speculation.
>
> No it isn't. It is my personal opinion, which is exactly what I
> said. People actually use Loki's smart pointer, so it isn't
> speculation.
Sorry, I didn't mean that. What I meant to say was that the best we
can do about determining the overall significance at this point is to
speculate (based on anecdotal evidence or whatever).
>> What we do here is to consider the arguments.
>
> Yes, and also engage in little "political wars." It doesn't matter
> what anyone intended. That is the way things come off sometimes.
My experience is that the more people think of it in political terms,
the more political it in fact gets. I'm just trying to discourage
that kind of spiral.
>> With all due respect, that sounds like a knee-jerk reaction to the
>> fact that there's any discussion or disagreement with your
>> point-of-view. Most of the discussion about this particular issue has
>> been very detached AFAICT.
>
> Your response in whole seems like a knee-jerk reaction to justify
> behavior.
What behavior do you think I'm justifying?
> That is the way it goes. You have preconceived ideas, as do I. I'm
> telling you how I interpret it, not whether I think it is absolute
> fact. Nor am I overly concerned about the pointer issue. I'm only
> defending that which I think needs to be defended.
>
>> > This is precisely why I think that we need both forms. When experts
>> > disagree fundamentally on such a concept, both forms should be
>> > supported--and there is no question that both Dave and Andrei (and
>> > many others here) are experts.
>>
>> But I don't think I have a fundamental disagreement with Andrei on
>> this. Really! How can I con
Re: [boost] Re: Preliminary submission: command line & config filelibrary
Vladimir Prus wrote:
I have one policy that I forgot to mention: chain_lookup_policy. It's
work
is based on Chain of responcibilities Design pattern. In this case Every
parameter knows how to parse itelf out of input. And this
identification may
not be the name at all.
I would say that it's a big question how much flexibility is needed. My
position is that the command line should not go beyond existing styles.
Can you suggest some style which require chain_lookup_policy and still
legible for users?
If I understand what Gennadiy is saying, then I have a possible example.
Our compiler has options that look something like this:
-fcopyPropagation={--maxTransforms=32 --keepStats}
Nobody but the CopyPropagation module should care about what's in
the braces. "-f" knows enough to parse a filter name ("copyPropagation"
in this case). These constructs can be arbitrarily nested. One of our
modules goes three deep, IIRC.
-Dave
--
"Some little people have music in them, but Fats, he was all music,
and you know how big he was." -- James P. Johnson
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Policy-based smart pointers revisisted
- Original Message - From: "David Abrahams" <[EMAIL PROTECTED]> > >> Argument is very different from derision. I think it would be very > >> foolish to deride Andrei's opinions, which usually have something very > >> incisive behind them. > > > > Agreed, but that is more-or-less what happened. Andrei asked for an > > example that justified the design. No one could produce one. The > > best anyone could do was say "it's like the STL, so that must be > > good," and "we might need the generality if the future." > > That's *not* derision, Paul. No, it isn't. That was just the arguments that were made in favor of the sequence abstraction. It came off more like "if you think its a bad design, prove it" and "who are you to say whether or not someone might need it?" which I consider to be a derisive and inflammatory remarks designed to belittle an opinion. > > Once again, I don't want to get into an argument about this > > particular issue, I'm only pointing out that people tend to respond > > harshly when their designs (or favored designs) are questioned. > > Simple as that. I'm not immune and neither are you. > > Agreed, but there's no example of harshness here AFAICT. I know. My only point was that I can see where Andrei is coming from when he says that he's not popular at Boost. MPL and smart pointers aside, I'm saying that it comes off that way to me as well. > > It isn't completely based on political bias, but it is there > > nonetheless. It is *always* there in some form or another. > > Incidently, Andrei was flat out told "if you don't like it, don't > > use it." > > You're claiming somebody said that; fine, I believe you. That's not > "how boost treats Andrei", it's just what somebody said. It's not > particularly sympathetic, I'll grant you that. It was said by Aleksey, I believe, but that I'm not trying to point fingers here--everybody gets frustrated. I'm simply saying that periodically things escalate to the point where expressing an opinion is considered inflammatory if it isn't the "right" opinion, and that seems to have happened to Andrei more than most. I'm not worried about myself here. When I make comments about design, I usually only consider them to be token responses, because I am not an expert, while you, Aleksey, Andrei, etc., are. > > That wasn't exactly addressing Andrei's concerns about the design or > > attempting to reach any sort of consensus. It was a flatout > > dismissal of Andrei's arguments. Boost is great at making people's > > opinions feel unwelcome if they don't conform in certain areas. > > Probably true; people don't tend to feel their opinions are being > well-received when the majority disagrees with them. That is part of it, yes. The difference is when certain issues don't get addressed in a reasonable manner. A.k.a. the "justifying example." It was not Andrei's job to disprove the validity of the design, it was the people promoting the design's job to show the viability of it. (In any case, the sequence abstraction is not all of the MPL, and, in general, I like the library.) > >> Despite the fact that there's some available evidence that it has been > >> significant to some people. Who knows whether or not it's > >> "significant"? It's pure speculation. > > > > No it isn't. It is my personal opinion, which is exactly what I > > said. People actually use Loki's smart pointer, so it isn't > > speculation. > > Sorry, I didn't mean that. What I meant to say was that the best we > can do about determining the overall significance at this point is to > speculate (based on anecdotal evidence or whatever). Okay. ;) > >> What we do here is to consider the arguments. > > > > Yes, and also engage in little "political wars." It doesn't matter > > what anyone intended. That is the way things come off sometimes. > > My experience is that the more people think of it in political terms, > the more political it in fact gets. I'm just trying to discourage > that kind of spiral. I definitely agree with that. The problem is that any major disagreement seems to escalate into a political battle with both sides taking the hard-line. At that point, the argument ceases to be about design or practicality, but more about "winning the argument." I agree, that is not a good thing, but it does happen from time to time. > >> With all due respect, that sounds like a knee-jerk reaction to the > >> fact that there's any discussion or disagreement with your > >> point-of-view. Most of the discussion about this particular issue has > >> been very detached AFAICT. > > > > Your response in whole seems like a knee-jerk reaction to justify > > behavior. > > What behavior do you think I'm justifying? There are times when you are "less than diplomatic." :) At some point or another, everybody does this (including me), so I'm not specifically targetting you here. Sometimes, when that happens, things are taken alot worse or in a slightly different context by t
Re: [boost] Re: Preliminary submission: command line & config filelibrary
[2003-01-21] David A. Greene wrote:
>Vladimir Prus wrote:
>
>>> I have one policy that I forgot to mention: chain_lookup_policy. It's
>>> work
>>> is based on Chain of responcibilities Design pattern. In this case Every
>>> parameter knows how to parse itelf out of input. And this
>>> identification may
>>> not be the name at all.
>>
>> I would say that it's a big question how much flexibility is needed. My
>> position is that the command line should not go beyond existing styles.
>> Can you suggest some style which require chain_lookup_policy and still
>> legible for users?
>
>If I understand what Gennadiy is saying, then I have a possible example.
>Our compiler has options that look something like this:
>
>-fcopyPropagation={--maxTransforms=32 --keepStats}
>
>Nobody but the CopyPropagation module should care about what's in
>the braces. "-f" knows enough to parse a filter name ("copyPropagation"
>in this case). These constructs can be arbitrarily nested. One of our
>modules goes three deep, IIRC.
Not totally sure if this is in context, haven't really followed this thread.
But my command lines are rather complex and context dependent. For example
here are some of them...
registerCommand(L"copy")(L"[from]")(L"")(L"[revision=]")(L"here")(L"[preserve|overwrite]")
registerCommand(L"copy")(L"[from]")(L"")(L"[revision=]")(L"[to]")(L"")(L"[preserve|overwrite]")
registerCommand(L"edit")(L"[label=]")(L"[set]")(L"comment=")
registerCommand(L"edit")(L"[label=]")(L"[add]")(L"{}")(L"[last|published]")
... [] = 0 or 1, {} = >1, <> = replacement, | = alternates, everything is
literals.
In other words, not everyone uses GNU style CLI. Some of us like AmigaOS
style CLI ;-)
-- grafik - Don't Assume Anything
-- [EMAIL PROTECTED] - [EMAIL PROTECTED]
-- 102708583@icq
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
