- Boost - lists.boost.org

[Bug Sprint] Status for Sunday, December 5th
by Marshall Clow 05 Dec '10

05 Dec '10

There were only 13 changes to the trac database yesterday - mixed in with a lot of spam [ I'd like to say "13 tickets were changed", but some tickets were changed more than once. ] It's time to ramp it up - today is the last day of the Bug Sprint! In the last bug sprint, we closed almost 200 tickets (not 100 - I misremembered). So far this time, we're down a (net) 13 tickets from the start of the sprint! If you think it's too late to get involved - you're wrong! A couple of notes: 1) Please log into the Trac system before you add/modify a ticket. "Anonymous said:" is hard to follow up. 2) It is perfectly OK to add a comment to a ticket that says "I tested this patch on my system (foo, gcc 1.2.3.4, etc) and it worked fine/didn't work/etc" General information about the bug sprint is here: https://svn.boost.org/trac/boost/wiki/BugSprintNov2010 General information about how the Trac system works is here: https://svn.boost.org/trac/boost/wiki/TicketWorkflow Overall bug count: November 26: 946 November 27: 939 November 28: 930 November 29: 934 (whoops, that's the wrong direction!) November 30: 931 (better, but the delta is too small) December 1: 929 December 2: 930 December 3: 933 (ouch!) December 4: 931 December 5: 934 (ouch, again!) Activities on the trac system yesterday: New tickets 4 Tickets closed 2 Tickets changed 7 bemandawes 3 rleigh@ 2 --others-- 8 Useful reports: https://svn.boost.org/trac/boost/report/1 -- full list of tickets https://svn.boost.org/trac/boost/report/18 -- ticket counts by owner https://svn.boost.org/trac/boost/report/19 -- ticket counts by component https://svn.boost.org/trac/boost/report/20 -- ticket counts by ticket type https://svn.boost.org/trac/boost/report/21 -- ticket counts by milestone -- Marshall

1 0

Re: [boost] [build] bjam in boost/tools/build/v2/test doesn't work
by Jim Bell 04 Dec '10

04 Dec '10

I'm re-posting this (from 11/22). I'd really like to reconcile command-line vs run.py... On 1:59 PM, Vladimir Prus wrote: > > Jim Bell wrote: >> >> Running bjam in boost/tools/build/v2/test doesn't (seem to) run build's >> >> regressions. Instead, I get: >> >> >> >> jamfile.jam:8: in modules.load >> >> rule project-root unknown in module > > You should be using 'python test_all.py'. Running 'bjam' there is not really > > supposed to do anything. Thanks! This works and gives me results like this... unit_tests : FAILED module_actions : PASSED startup_v1 : PASSED ... I see, too, that '--verbose' enables detailed output, from BoostBuild.Tester's docstring (and from trying it). But it says "Note that it does not also enable more verbose build system output like the --verbose command line option does." What does that mean? If I run "python test_all.py --verbose verbose" it doesn't seem to like that (attempts to run verbose.init). Also, I'm seeing a different pass/fail pattern between when I run it like this and when it runs from run.py. I'm running it with mingw-4.4.3 on the same trunk revision that the "MinGW-32 jc-bell.com" regression has reported. Picking "absolute_sources", for example, I see absolute_sources : PASSED But the regression shows it failed. How do I reconcile these?

1 0

[Bug Sprint] Status for Saturday, December 4th
by Marshall Clow 04 Dec '10

04 Dec '10

There were only 6 changes to the trac database yesterday - mixed in with a lot of spam [ I'd like to say "6 tickets were changed", but some tickets were changed more than once. ] The decrease in activity continues. It's time to ramp it up - there are only three more days in the Bug Sprint. In the last bug sprint, we closed almost 200 tickets (not 100 - I misremembered). So far this time, we're down a (net) 15 tickets from the start of the sprint! If you think it's too late to get involved - you're wrong! A couple of notes: 1) Please log into the Trac system before you add/modify a ticket. "Anonymous said:" is hard to follow up. 2) It is perfectly OK to add a comment to a ticket that says "I tested this patch on my system (foo, gcc 1.2.3.4, etc) and it worked fine/didn't work/etc" General information about the bug sprint is here: https://svn.boost.org/trac/boost/wiki/BugSprintNov2010 General information about how the Trac system works is here: https://svn.boost.org/trac/boost/wiki/TicketWorkflow Overall bug count: November 26: 946 November 27: 939 November 28: 930 November 29: 934 (whoops, that's the wrong direction!) November 30: 931 (better, but the delta is too small) December 1: 929 December 2: 930 December 3: 933 (ouch!) December 4: 931 Activities on the trac system yesterday: bemandawes 2 anonymous 1 ramey 1 degtyariov.a@ 1 m_fedyszyn 1 --others-- 0 Useful reports: https://svn.boost.org/trac/boost/report/1 -- full list of tickets https://svn.boost.org/trac/boost/report/18 -- ticket counts by owner https://svn.boost.org/trac/boost/report/19 -- ticket counts by component https://svn.boost.org/trac/boost/report/20 -- ticket counts by ticket type https://svn.boost.org/trac/boost/report/21 -- ticket counts by milestone

2 1

[trac] WARNING: Anonymous ticket creation disabled..
by Rene Rivera 04 Dec '10

04 Dec '10

Because of the current influx of SPAM tickets in trac, I've temporarily disabled creating tickets by "anonymous" users. So if you get hit by this either: *** Make sure you are logged in before creating a ticket. *** Or.. *** Fill some information for the user in trac. *** Hopefully after the holidays the SPAM traffic will die down, it usually does, and perhaps I'll turn the anon tickets back on. And sorry for the abrupt change.. But I was getting really tired of deleting tickets all day yesterday and today. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail

2 2

Re: [boost] Library for configuration file parsing
by Pierre Morcello 04 Dec '10

04 Dec '10

Hello Denis, >>> - I can not imagine a more simple interface... :-) If you want to go 'macro', it is certainly possible : Example 1.1 : BOOST_CONFIGURATOR_OPTION( UdpHost , "System::Server::UdpHost" ); BOOST_CONFIGURATOR_OPTION( UdpPort , "System::Server::UdpHost" ); Example 1.2 : class SomeConfigOptions { public: int updport; Ip updhost; }; BOOST_CONFIGURATOR_OPTION( SomeConfigOptions, (updport, "System::UdpServer::Port") (udphost, "System::UdpServer::Host") ); then, after parsing all wanted files : SomeConfigOptions myConfig; if( !conf.get(myConfig) ) { return error; } >>> What do you think about it? This need real life experience, to check what works and what does not. If you have 4 levels in the parse tree, and 250 values, you will have to rewrite many times the types, to declare them and to access them at the same level. After such tests, you can see what works and what does not work. The user will also have to create lots of types in a namespace with the macro you provide. I consider that configuration files often reflect the c++ tree of classes. I doubt you will want to use something like System::UdpServer::Host in the config file, when you only have 1 int in your program. I consider it is easier to have a c++ classes tree like : Example 1.3 struct SoundConfiguration { int option1; double option2; }; // here a macro to declare SoundConfiguration & its attributes... BOOST_CONFIGURATOR_OPTION( SoundConfiguration, (option1) (option2) ); struct SoundConfigurations { double volume; std::vector<SoundConfiguration> sounds; }; // here a macro to declare SoundConfigurations & its attributes... BOOST_CONFIGURATOR_OPTION( SoundConfigurations, (volume) (sounds) ); to describe the design of your config file. That way : a/ you can manipulate compiler-checked information, without creating many types. b/ You don't need to repeat the "System::Sound" thing everywhere. c/ The 'designation string' could be optional though (ex: ((sounds)("sons")) for a french guy). d/ If I want the configurator to check the Ip, I create a "Ip myIp" attribute. If I want to check the Ip myself, I create a "std::string myIp" attribute. I suppose the best 'configurator' system would support both ways. 1/ allow to serialize and deserialise from a human-readable/editable subsection of the file (like a deferred boost.serialize) 2/ allow to use a specific identifier like "System::Udp::Server" to retrieve some other values. Either from the config line or a file. Boost.PP/boost.spirit/'boost.serialization + boost.xpressiv' offer means to do that easily. This is at least what comes to me when I read the rationnale you wrote : " 1. obtaining options from configuration file, 2. check correctness (in all senses of this word) of obtained options, 3. storing options, 4. issuance of the options values on demand. " > <System> > <UdpServer> > Host = 127.0.0.1 > Port = 100 > </UdpServer> > </System> I think writing the tag name twice is harder for humans. Example 2.1 System { UpdServer { Host = 127.0.0.1 Port = 127.0.0.1 } } Or even python-like : Example 2.2 System UpdServer Host = 127.0.0.1 Port = 127.0.0.1 Anyway, this need real life experience, to see what works and what does not(and more tests & examples ! Good that you have already added some in the sandbox!). Just my point of view. Best regards, Pierre Morcello

1 0

Library for configuration file parsing
by Denis Shevchenko 04 Dec '10

04 Dec '10

Hi all! Is there any interest in a library for configuration file parsing? I know there is a good library Program_options, but it supports (asit is written in the documentation) "parsing of simple INI-like configuration files". If all you need for configure your programs is INI-like files - use Program_options and forget about this letter. But if you want to use a more complex configuration files, you may be interested in my library, Configurator. simplest.conf: Host = 127.0.0.1 Code for work with this config: cf::configurator configurator; configurator.add_option( "Host" ); configurator.parse( "/some/path/to/simplest.conf" ); std::cout << "Value of host: " << configurator.get_value( "Host" )<< std::endl; Features - Header-only - Allows to set option's default value or/and necessity. - Allows to use arbitrary nesting of sections. - Provides "standard" checks of value's semantic, like correct path, IP validity, email correctness, etc. - Provides "extended" checks of value's semantic, like time period and file size. - Provides common checks of options and sections, like duplication, incorrection, etc. - Supports single-line and multi-line comments (in C++ style). - Allow to register values with multi-values. - Allows to set another "name-value" separator (including space symbol), instead default '='.

23 72

[website] [filesystem] How to update HTML page on website?
by Beman Dawes 04 Dec '10

04 Dec '10

I'd like to fix a very misleading documentation bug in Boost.Filesystem. How do I update a single HTML page on the server? Were is this documented? Thanks, --Beman

3 4

[Bug Sprint] Status for Friday, December 3rd
by Marshall Clow 03 Dec '10

03 Dec '10

There were only 13 changes to the trac database yesterday. [ I'd like to say "13 tickets were changed", but some tickets were changed more than once. ] The decrease in activity continues. It's time to ramp it up - there are only three more days in the Bug Sprint. In the last bug sprint, we closed almost 200 tickets (not 100 - I misremembered). So far this time, we're down a (net) 13 tickets from the start of the sprint! If you think it's too late to get involved - you're wrong! If you're looking for things to do, there are several patches for Date-Time waiting to be reviewed (thx to ktchan): #2956 is very old and need review #3651 is simple documentation changes #4057 appears at a glance simple changes #4411 & #4754 is simple update to time zone data file #4475 #4798 is a simple change #4845 is simple documentation changes #4870 #4920 is simple update to date_time examples and there are a bunch of program-options bugs that can be looked at: #850 program_options strips off escaped quotes in some situations #1132 zero_tokens doesn't work #3813 program_options::options_description.add() permits duplicate options #3909 parse_command_line has bad declaration #3992 Example in documentation for program_options doesn't compil #4040 Program Options has issues with options that support multiple tokens when using multiple parsers #4133 std::logic_error as a base class for program_options::error #4137 boost::program_options::value_semantic missing 's' at the end #4149 exceptions thrown by typed_value::default_value() are not documented #4150 bool_switch() is exception-unsafe #4151 option_description::option_description(3 args) is exception-unsafe #4267 validation_error documentation #4469 Bugs in program_options implementation #4510 [program_options]: implicit_value and positional options conflict #4597 options_description should be defined as noncopyable #4656 program_options parse_config_file() set iostream failbit even if the parse result is ok #4858 Documentation error - Responsefile example code can crash (You all know the drill: develop a fix, test it locally, make a patch, attach it to the ticket) A couple of notes: 1) Please log into the Trac system before you add/modify a ticket. "Anonymous said:" is hard to follow up. 2) It is perfectly OK to add a comment to a ticket that says "I tested this patch on my system (foo, gcc 1.2.3.4, etc) and it worked fine/didn't work/etc" General information about the bug sprint is here: https://svn.boost.org/trac/boost/wiki/BugSprintNov2010 General information about how the Trac system works is here: https://svn.boost.org/trac/boost/wiki/TicketWorkflow Overall bug count: November 26: 946 November 27: 939 November 28: 930 November 29: 934 (whoops, that's the wrong direction!) November 30: 931 (better, but the delta is too small) December 1: 929 December 2: 930 December 3: 933 (ouch!) Activities on the trac system yesterday: jim.bell@ 4 viboes 2 jaredgrubb@ 2 --others-- 5 Useful reports: https://svn.boost.org/trac/boost/report/1 -- full list of tickets https://svn.boost.org/trac/boost/report/18 -- ticket counts by owner https://svn.boost.org/trac/boost/report/19 -- ticket counts by component https://svn.boost.org/trac/boost/report/20 -- ticket counts by ticket type https://svn.boost.org/trac/boost/report/21 -- ticket counts by milestone

2 2

Boost development calendar
by David Bellot 03 Dec '10

03 Dec '10

Hi developers, is it my configuration or the Boost Developer Google Calendar is not updated anymore ? As this calendar is shared, it would be nice to have the next important events (like closing 1.46, 1.47, 1.48...) in it. (but if I misconfigured something, then forget about my email :-D ). Cheers, David *____________________ David Bellot, PhD **http://david.bellot.free.fr http://ai-owl.blogspot.com*

4 3

pimpl library proposal
by Michael Bailey 03 Dec '10

03 Dec '10

I have created a pimpl library that I use on a regular basis which sits on top of boost and was wondering if there was any interest in my providing it to the community. It is quite simple, but has been extremely useful personally. The library has two basic components. For starters, it uses a boost::shared_ptr to hide the implementation in the cpp file. The forwarding of the public interface is accomplished through some simple macros. The macros declare each public method, with an appropriate signature, and forward the call onto the implementation class. It would be easier to show an example of it in action: my_object.hpp class my_object : public boost::pimpl<class my_object_impl> { public: my_object() {} void do_something(); int do_other_thing( double ) const; void lots_of_args( int, int, int, int ); }; my_object.cpp class my_object_impl { public: void do_something() {...} int do_other_thing( double a1 ) const {...} void lots_of_args( int, int, int, int ) {...} private: ... }; BOOST_PIMPL_CTOR( my_object ); BOOST_PIMPL_METHOD( 0, my_object, do_something ); BOOST_PIMPL_METHOD( 1, my_object, do_other_thing, const ); BOOST_PIMPL_METHOD( 4, my_object, lots_of_args ); If this seems like it would be of any use to others, let me know. I'd be happy to share.

3 2