Re: [boost] Re: Date iterators in Boost Date-Time
En réponse à Jeff Garland <[EMAIL PROTECTED]>: > On Sat, 16 Aug 2003 23:31:05 -0400, Jeremy B. Maitin-Shepard wrote > > > > Yes, of course, it is not really a union either. I think > > > merge_inclusive is fine. > > > > How about "maximize" or "maximize_duration" or just "max" or > > "max_duration"? > > Thx for the ideas, but... > > I'm leary of these b/c this is an operation on a period not a duration. > max is way too overloaded; and still not sure it explains the operation. I > still haven't heard a name that really strikes me as really good. > > Jeff I just wanted to mention that the interval library names this operation "hull". It is a mathematically defined term since the operation is indeed a convex hull. Just my two eurocents, Guillaume ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Date iterators in Boost Date-Time
On Sat, 16 Aug 2003 23:31:05 -0400, Jeremy B. Maitin-Shepard wrote > > Yes, of course, it is not really a union either. I think > > merge_inclusive is fine. > > How about "maximize" or "maximize_duration" or just "max" or > "max_duration"? Thx for the ideas, but... I'm leary of these b/c this is an operation on a period not a duration. max is way too overloaded; and still not sure it explains the operation. I still haven't heard a name that really strikes me as really good. Jeff ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: XMLUI (was Re: Re: UI++)
>>> May I come with a bit of scepticism? There's already XUL (see http://xulplanet.com for a start, and http://www.mozilla.org/catalog/architecture/xul/ for more details). I think Mozilla folks put some effort into it, so I wonder if XMLUI offers something new/better? <<< The main implementation of XMLUI predates XUL, just not in an open source form. But since then I've taken a look at XUL, and had a go at building some applications with it. There are a number of ways in which XMLUI is superior to XUL. Although XUL has had a lot of development work on it, there are some things that make it unattractive (at least for myself) as a tool for developing UI's for applications. Although it's great as a tool for creating "Browser like" applications, especially ones that integrate Mozilla. One of the major problems with it is it's lack of "independence" from it's primary application that it is based on - Mozilla. This is natural from a tool that "grew" out of the side of another program. I don't think there is any problems with having multiple XML based UI toolkits anyway. Diversity is a good thing :-) Paul. - Paul Hamilton pHamtec P/L - Software Makers http://www.phamtec.com/ mailto:[EMAIL PROTECTED] The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. - ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Date iterators in Boost Date-Time
On Sat, 16 Aug 2003 12:28:57 +1000 "Chris Trengove" <[EMAIL PROTECTED]> wrote: > "Jeff Garland" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > > I don't think the it is technically a union because the result draws > > in points in the time period that aren't part of either of the > > initial > periods. > > Anyway I wrote the code as merge_inclusive so unless you have a > > major objection I'll leave it that way pending a better idea... > > Yes, of course, it is not really a union either. I think > merge_inclusive is fine. How about "maximize" or "maximize_duration" or just "max" or "max_duration"? -- Jeremy B. Maitin-Shepard [EMAIL PROTECTED] ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] RE: 1.30.2 ready for release?
Misha Bergal wrote: > * there are still some failures on meta-intel-7.1-stlport I remember I have recompiled the STLPort without wchat_t support for RC_1_30_0. One of the failure will be resolved if I recompile STLPort with wchar_t support. What I don't understand is why other tests pass. -- Misha Bergal MetaCommunications Engineering ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] RE: 1.30.2 ready for release?
David Abrahams wrote: > Okay, I fixed that one. Nobody breathe... I'm going to tag it for > release. Our results are available now. Looking at it: * "static_assert" library name got somehow replaced with "libs". * there are still some failures on meta-intel-7.1-stlport -- Misha Bergal MetaCommunications Engineering ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] RE: 1.30.2 ready for release?
David Abrahams wrote: > I believe I have now eliminated all the regressions in the > RC_1_30_0 branch, though recent test updates at > > Would testers for the 1.30.2 release please be sure they're updating to > RC_1_30_0 and post new results? Dave, I believe our results will be ready by 6:00pm Central. We are doing the clean rebuild, so it takes time. -- Dave Abrahams Boost Consulting www.boost-consulting.com -- Misha Bergal MetaCommunications Engineering ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] boost::filesystem file restrictions
> >"Peter Dimov" <[EMAIL PROTECTED]> wrote: >> I am not sure that it should be the responsibility of the path class to >> enforce some notion of portability. I haven't been following this whole discussion, but I'll chime in here b/c I believe some of this might be partially due to comments I made during initial development. The basic scenario for this is: 1) I'm developing a script-like application that manipulates files. In particular it generates a bunch of file and pathnames. 2) I'd like to develop this on one platform and expect that it will port to others without modification. Therefore, I want the library to help me with this by helping me aviod non- portable paths. Of course if I'm developing for a single platform then I don't need this. I think the current design does this pretty nicely. Jeff ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: 1.30.2 ready for release?
[EMAIL PROTECTED] wrote: Daniel Frey <[EMAIL PROTECTED]> writes: David Abrahams wrote: http://tinyurl.com/k7vl and http://tinyurl.com/jtpd seem to contradict that. I find that very strange because I specifically Also the latter run (Win32) stops after "type_traits". The "utility"-section seems to have disappeared. Misha, can you have a look, please? This is because of std::facet-support.test problem which Martin has reported and David has fixed. Ah, I see. I also saw from Beman's results for the main trunk that the fix for checked_delete works as expected. One nit: Beman, you added annotations that explain why a test failed. Now the test passes, but the annotation is still there... Regards, Daniel -- Daniel Frey aixigo AG - financial training, research and technology Schloß-Rahe-Straße 15, 52072 Aachen, Germany fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99 eMail: [EMAIL PROTECTED], web: http://www.aixigo.de ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [PATCH] libs/integer/cstdint_test.cpp should define __STDC_CONSTANT_MACROSearlier
At 02:10 PM 8/15/2003, Douglas Paul Gregor wrote: >The test case libs/integer/cstdint_test.cpp includes and > _before_ it defines __STDC_CONSTANT_MACROS. This means that on >a platform that (a) supports defining the C99 macros in when >__STDC_CONSTANT_MACROS is defined and (b) uses somewhere in >, the test fails, because __STDC_CONSTANT_MACROS has been >defined too late for header to react (because it presumably has >include guards). > >I believe the test case is wrong, and we should apply the patch below. Ok? Doug, I'm not sure there is anyone at the helm of cstdint_test.cpp to answer you. John Maddock, maybe. So it seems to me you should go ahead and apply the patch. Just keep an eye on regression results for several platforms to make sure it doesn't break anything. My two cents, --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: 1.30.2 ready for release?
[EMAIL PROTECTED] writes: > Daniel Frey <[EMAIL PROTECTED]> writes: > >> David Abrahams wrote: >> > http://tinyurl.com/k7vl and http://tinyurl.com/jtpd seem to >> > contradict that. I find that very strange because I specifically >> >> Also the latter run (Win32) stops after "type_traits". The >> "utility"-section seems to have disappeared. Misha, can you have a >> look, please? > > > This is because of std::facet-support.test problem which Martin has > reported and David has fixed. Misha, when will we see a new report from meta-comm? -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: 1.30.2 ready for release?
Martin Wille <[EMAIL PROTECTED]> writes: > David Abrahams wrote: >> I believe I have now eliminated all the regressions in the RC_1_30_0 >> branch, though recent test updates at >> http://tinyurl.com/k7vl and http://tinyurl.com/jtpd seem to >> contradict that. I find that very strange because I specifically >> reproduced those problems and addressed them on my machine, and the >> results *are* checked in to CVS. Unless the RC_1_30_0 tag has somehow >> magically been made non-sticky, or there's something wrong with the >> testers' CVS update procedure, I don't see how it's possible. >> Would testers for the 1.30.2 release please be sure they're updating >> to RC_1_30_0 and post new results? > > Done. Unfortunately there are new regressions for > optional_test on gcc-2.95.3/Linux. Okay, I fixed that one. Nobody breathe... I'm going to tag it for release. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: 1.30.2 ready for release?
Daniel Frey <[EMAIL PROTECTED]> writes: > David Abrahams wrote: > > http://tinyurl.com/k7vl and http://tinyurl.com/jtpd seem to > > contradict that. I find that very strange because I specifically > > Also the latter run (Win32) stops after "type_traits". The > "utility"-section seems to have disappeared. Misha, can you have a > look, please? This is because of std::facet-support.test problem which Martin has reported and David has fixed. -- Misha Bergal MetaCommunications Engineering ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: 1.30.2 ready for release?
David Abrahams wrote: I believe I have now eliminated all the regressions in the RC_1_30_0 branch, though recent test updates at http://tinyurl.com/k7vl and http://tinyurl.com/jtpd seem to contradict that. I find that very strange because I specifically reproduced those problems and addressed them on my machine, and the results *are* checked in to CVS. Unless the RC_1_30_0 tag has somehow magically been made non-sticky, or there's something wrong with the testers' CVS update procedure, I don't see how it's possible. Would testers for the 1.30.2 release please be sure they're updating to RC_1_30_0 and post new results? Done. Unfortunately there are new regressions for optional_test on gcc-2.95.3/Linux. Regards, m ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: 1.30.2 ready for release?
David Abrahams wrote: http://tinyurl.com/k7vl and http://tinyurl.com/jtpd seem to contradict that. I find that very strange because I specifically Also the latter run (Win32) stops after "type_traits". The "utility"-section seems to have disappeared. Misha, can you have a look, please? Regards, Daniel -- Daniel Frey aixigo AG - financial training, research and technology Schloß-Rahe-Straße 15, 52072 Aachen, Germany fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99 eMail: [EMAIL PROTECTED], web: http://www.aixigo.de ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] 1.30.2 ready for release?
I believe I have now eliminated all the regressions in the RC_1_30_0 branch, though recent test updates at http://tinyurl.com/k7vl and http://tinyurl.com/jtpd seem to contradict that. I find that very strange because I specifically reproduced those problems and addressed them on my machine, and the results *are* checked in to CVS. Unless the RC_1_30_0 tag has somehow magically been made non-sticky, or there's something wrong with the testers' CVS update procedure, I don't see how it's possible. Would testers for the 1.30.2 release please be sure they're updating to RC_1_30_0 and post new results? Thanks, Dave -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] boost::filesystem file restrictions
At 04:23 PM 8/15/2003, Peter Dimov wrote: >Beman Dawes wrote: >> At 01:40 PM 8/14/2003, Peter Dimov wrote: >> > >> >I am not sure that it should be the responsibility of the path >> class to >enforce some notion of portability. Wouldn't it be more >> appropriate to >defer the portability check, if any, to the point >> where the path is >actually used in a filesystem operation? >> >> That's too late. A real path is often made up of some native elements >> (which the portability check doesn't apply to) and some portable >> elements (which the portability check should be applied to). >> >> The earlier the error can be detected, the better. Also, a path is >> only constructed once, but may be use multiple times. > >[...] > >> That would be easy if we accepted the native platform as the default, >> and portable cases had to be specially coded. But my interest is in >> portable semantics as the default. > >I must be missing something. What is a "portable" path useful for? A >portable path _grammar_ (element sequence separated by '/') is certainly >useful, it allows me to write portable _code_ that deals with paths. Yes, to the extent the elements (the names) are portable. >Portable path _data_ is a different story. For sure. But we have been talking only about names which are elements of paths and how to string them together via a portable grammar. We haven't been talking about file data content at all. --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] boost::filesystem file restrictions
At 08:46 PM 8/14/2003, Walter Landry wrote: >"Peter Dimov" <[EMAIL PROTECTED]> wrote: >> I am not sure that it should be the responsibility of the path class to >> enforce some notion of portability. Wouldn't it be more appropriate to >> defer the portability check, if any, to the point where the path is >> actually used in a filesystem operation? > >I agree, if only because I could imagine manipulating a bunch of >non-legal paths before actually using a legal one. I gave that some thought during the initial design. Let's say you want to do some manipulation of an element (that is, a name representing a node in the tree). Perhaps you have a home grown runtime macro expansion scheme. You are probably better off holding the data in a std::string until your manipulations (say macro expansion) have progressed to the point it is a valid native or portable name or path. At that point, assign the string to a boost::filesystem::path. > We still have to >solve the problem, but at a different place. Yes, exactly. > Beman's singleton stack >seems like a reasonable solution. We can argue over what the default >portability policy should be, but it almost becomes irrelevant because >it is easy to change and forget about it. I've been turning that solution over and over in my mind, and while it has some mild blemishes, it seems clearly a big improvement over the current design. Among side advantages, it doesn't break any current code. So unless someone comes up with a killer argument against the stack approach, I'll implement it within a day or two. Part of the difficulty with the current approach is documentation; I'll try to rectify that in the process. --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: checked_delete / CW8
Howard Hinnant <[EMAIL PROTECTED]> writes: > On Saturday, August 16, 2003, at 8:06 AM, David Abrahams wrote: > >>> Thanks. I'll keep my fingers crossed... >> >> Still no joy :( > > Could you elaborate? Perhaps I could help. Oh, just miscellaneous other regressions which are stopping the release. If you'd like to help, that'd be great ;-> i-really-hope-i've-nailed-them-now-though-ly y'rs, dave -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: checked_delete / CW8
On Saturday, August 16, 2003, at 8:06 AM, David Abrahams wrote: Thanks. I'll keep my fingers crossed... Still no joy :( Could you elaborate? Perhaps I could help. -Howard ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Release of 1.30.2 imminent
"Mohamed Iqbal" <[EMAIL PROTECTED]> writes: > Hi... > > Instead of downloading the complete Boost every time something has changed, > why don't you consider 1.30.0 as a standard from subsequent releases until > you reach 1.4.0 and so that we can only download only the modified > libraries? You can use CVS if you want to minimize the amount of downloading when upgrading. I don't think anyone wants the extra responsibility of preparing patchsets from 1.30.0 to whatever the next version is. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: boost::filesystem file restrictions
Dave Gomboc wrote: > For example, while it is possible to think of all drives on an MS > Windows machine as being part of a single filesystem, an individual > using NTFS on > C:, FAT32 on D:, FAT16 on E:, and FAT12 on A: reasonably would not. Not only do I think of these drives as a single conceptual filesystem, but I don't even think of 'c:/' as conceptually top level. c:\ should map to '/My Computer/c:/', '/drives/c:/' or something similar, not '/c:/'. -- Rainer Deyke - [EMAIL PROTECTED] - http://eldwood.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Release of 1.30.2 imminent
Martin Wille <[EMAIL PROTECTED]> writes: > David Abrahams wrote: > >> I have fixed the last regression (the one with crc_test) in CVS, so >> as soon as you've made your patch and we've had one more round of >> testing, I'm going to tag it for release. Please let me know the >> instant you're finished. > > Bad news, there is a new problem: One test uses > an unportable filename: std::facet-support.test. > Consequently, process_jam_log crashes due to an > exception thrown by boost::filesystem::path. Now fixed. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: checked_delete / CW8
Daniel Frey <[EMAIL PROTECTED]> writes: > On Sat, 16 Aug 2003 04:11:09 +0200, David Abrahams wrote: > >> David Abrahams <[EMAIL PROTECTED]> writes: >> >>> Daniel Frey <[EMAIL PROTECTED]> writes: >>> Hi Dave, I checked in a fix for checked_delete.hpp for the Metrowerks CW8 to CVS HEAD. It was created in cooperation with Howard and I'm positiv that it's a good one-size-fits-all solution. I don't know about your shedule for 1.30.2, but you might want to consider merging it to RC_1_30_0. I will not push this as I don't want to delay 1.30.2, having it in 1.31.0 is fine, too. >>> >>> Hmm, I use Pro8.3 all the time and have never seen a need for a patch >>> to checked_delete. Ah, the regressions were in expected-failure > tests? > > The regression depends on the compiler flags. It occurs with "-iso_templates > on" which - according to Howard - is a good idea to use. Personally, I > have no clue what it's good for... :) It enables conformance ;-) Of course all of my compiles and the Boost regression tests are run using -iso_templates on. >> OK, I like your patch and I've applied it in the branch. I'm going to >> release tomorrow morning after the meta-comm regressions have run again. > > Thanks. I'll keep my fingers crossed... Still no joy :( -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Release of 1.30.2 imminent
Martin Wille <[EMAIL PROTECTED]> writes: > David Abrahams wrote: > >> I have fixed the last regression (the one with crc_test) in CVS, so >> as soon as you've made your patch and we've had one more round of >> testing, I'm going to tag it for release. Please let me know the >> instant you're finished. > > Bad news, there is a new problem: One test uses > an unportable filename: std::facet-support.test. Whaa?? There's not supposed to be a file with that name! It should be showing up in the test's requirements! > Consequently, process_jam_log crashes due to an > exception thrown by boost::filesystem::path. Will fix. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Release of 1.30.2 imminent
Hi... Instead of downloading the complete Boost every time something has changed, why don't you consider 1.30.0 as a standard from subsequent releases until you reach 1.4.0 and so that we can only download only the modified libraries? Mohammed ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Release of 1.30.2 imminent
Martin Wille <[EMAIL PROTECTED]> writes: > David Abrahams wrote: > > > I have fixed the last regression (the one with crc_test) in CVS, so > > as soon as you've made your patch and we've had one more round of > > testing, I'm going to tag it for release. Please let me know the > > instant you're finished. > > Bad news, there is a new problem: One test uses > an unportable filename: std::facet-support.test. > Consequently, process_jam_log crashes due to an > exception thrown by boost::filesystem::path. The same here. The relevant lines from bjam.log are MkDir1 D:\boost2\rc_1_30_0\results\status\bin\std::facet-support.test mkdir D:\boost2\rc_1_30_0\results\status\bin\std::facet-support.test The parameter is incorrect. ...failed MkDir1 D:\boost2\rc_1_30_0\results\status\bin\std::facet-support.test... ...skipped D:\boost2\rc_1_30_0\results\status\bin\std::facet-support.test\meta-intel-7.1-stlport for lack of D:\boost2\rc_1_30_0\results\status\bin\std::facet-support.test... ...skipped D:\boost2\rc_1_30_0\results\status\bin\std::facet-support.test\meta-intel-7.1-stlport\debug for lack of D:\boost2\rc_1_30_0\results\status\bin\std::facet-support.test\meta-intel-7.1-stlport... ...skipped D:\boost2\rc_1_30_0\results\status\bin\std::facet-support.test\meta-intel-7.1-stlport\debug\runtime-link-dynamic for lack of D:\boost2\rc_1_30_0\results\status\bin\std::facet-support.test\meta-intel-7.1-stlport\debug... ...skipped D:\boost2\rc_1_30_0\results\status\bin\std::facet-support.test\meta-intel-7.1-stlport\debug\runtime-link-dynamic\stlport-cstd-namespace-std for lack of D:\boost2\rc_1_30_0\results\status\bin\std::facet-support.test\meta-intel-7.1-stlport\debug\runtime-link-dynamic... -- Misha Bergal MetaCommunications Engineering ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Release of 1.30.2 imminent
David Abrahams wrote: I have fixed the last regression (the one with crc_test) in CVS, so as soon as you've made your patch and we've had one more round of testing, I'm going to tag it for release. Please let me know the instant you're finished. Bad news, there is a new problem: One test uses an unportable filename: std::facet-support.test. Consequently, process_jam_log crashes due to an exception thrown by boost::filesystem::path. Regards, m ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: checked_delete / CW8
On Sat, 16 Aug 2003 04:11:09 +0200, David Abrahams wrote: > David Abrahams <[EMAIL PROTECTED]> writes: > >> Daniel Frey <[EMAIL PROTECTED]> writes: >> >>> Hi Dave, >>> >>> I checked in a fix for checked_delete.hpp for the Metrowerks CW8 to >>> CVS HEAD. It was created in cooperation with Howard and I'm positiv >>> that it's a good one-size-fits-all solution. I don't know about your >>> shedule for 1.30.2, but you might want to consider merging it to >>> RC_1_30_0. I will not push this as I don't want to delay 1.30.2, >>> having it in 1.31.0 is fine, too. >> >> Hmm, I use Pro8.3 all the time and have never seen a need for a patch >> to checked_delete. Ah, the regressions were in expected-failure tests? The regression depends on the compiler flags. It occurs with "-iso_templates on" which - according to Howard - is a good idea to use. Personally, I have no clue what it's good for... :) > OK, I like your patch and I've applied it in the branch. I'm going to > release tomorrow morning after the meta-comm regressions have run again. Thanks. I'll keep my fingers crossed... Regards, Daniel ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: XMLUI (was Re: Re: UI++)
Hi Paul, Paul Hamilton wrote: >> Is there a URL available for samples we could look at? Talking about >> an XML >> user interface description isn't something I can do in the abstract. > > No URL yet. I'll setup a SourceForge project for it and post the > whitepaper. It's really not in a state where it can be used right now, > since it's all proprietary C++ code. > > I'll let you know when I get the SF stuff done. May I come with a bit of scepticism? There's already XUL (see http://xulplanet.com for a start, and http://www.mozilla.org/catalog/architecture/xul/ for more details). I think Mozilla folks put some effort into it, so I wonder if XMLUI offers something new/better? - Volodya ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: program_options multiple source question
Hi Neal,
Neal D. Becker wrote:
> I'm lost with trying to use the (unreleased) program_options lib.
>
> I have no problem to use with just command line, but I'd like to have both
> command line and config file.
>
> Here's what I tried:
>
> try {
> options_description desc("Allowed options");
> desc.add_options()
> ("help", "", "produce help message")
> ("esNodB,e", parameter ("value", &esnodB), "Es/No(dB)")
> ("maxBursts,m", parameter ("value", &maxBursts), "stop after
> #bursts")
> ("maxErrors,M", parameter ("value", &maxErrors), "stop after
> #errors")
> ;
>
> options_and_arguments opts = parse_command_line(argc, argv, desc);
> variables_map vm;
> store(opts, vm, desc);
>
> ifstream ifs("TestUWP.cfg");
> options_and_arguments opts2 = parse_config_file(ifs, desc);
> variables_map cfg_file_vm;
> store(opts2, cfg_file_vm, desc);
>
> vm.next(&cfg_file_vm);
>
> if (vm.count("help")) {
> std::clog << desc << "\n";
> return 1;
> }
>
> }
> catch(std::exception& e) {
> std::cerr << "error: " << e.what() << "\n";
> return 1;
> }
>
> I get this message:
> error: config file options should have required parameter
>
> I tried various variations, and also referred to the multiple_sources
> example,
> but I still can't find out what's wrong. Any clues?
The "help" option has no parameter. The program_options library does not
allow only (name,values) pairs in config file, so it complains about such a
option. One solution is to greate to option_descriptions instances: one for
command line only and one for general parameters. You can then combine
instances for command line parsing and pass only one to config file parser.
Of course, I'm open for other suggestions.
- Volodya
- Volodya
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: program_options defect
Neal D. Becker wrote: > I just found that program_options (from yahoo "files") has a serious > defect. The value of an option cannot start with the character '-', or it > will be interpreted as an option. > > Obviously, this makes it difficult to enter a negative number as the > option value. Hi Neal, as Dave already mentioned, I'm not really in position to hack on anything right now ;-) I do recall, though, that the behaviour you describe was intended only for optional values, so if "-f" has optional value, then "-f" "-1" is interpreted as option "-f" followed by "-1". If that's the behaviour you don't like, we can discuss what can be improved. If there's some other case, then it's a bug. Since I'm not likely to have CVS access where I go, this issue might have to wait till I'm back. - Volodya ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
