- Boost - lists.boost.org

config with cygwin
by Robert Ramey 14 Jun '10

14 Jun '10

I've recently upgraded to the lastest version of Cygwin and found that this current version supports wchar_t, wstring, etc This section from config/platform/cygwin is now creating problems. // cygwin specific config options: #define BOOST_PLATFORM "Cygwin" #define BOOST_NO_CWCHAR #define BOOST_NO_CWCTYPE #define BOOST_NO_SWPRINTF #define BOOST_HAS_DIRENT_H #define BOOST_HAS_LOG1P #define BOOST_HAS_EXPM1 as it conflits with the following from config/stdlib/libstdcp3 #if !defined(_GLIBCPP_USE_WCHAR_T) && !defined(_GLIBCXX_USE_WCHAR_T) # define BOOST_NO_CWCHAR # define BOOST_NO_CWCTYPE # define BOOST_NO_STD_WSTRING # define BOOST_NO_STD_WSTREAMBUF #endif I've found that BOOST_NO_STD_WSTRING is NOT defined while BOOST_NO_CWCHAR IS defined. This is incorrect for the latest version of cygwin - version 1.7.5 and likely previous versions. I believe that config/platform/cygwin should be updated so that it looks like: #define BOOST_PLATFORM "Cygwin" #define BOOST_NO_SWPRINTF // ? don't know about the rest of these #define BOOST_HAS_DIRENT_H #define BOOST_HAS_LOG1P #define BOOST_HAS_EXPM1 according to the cygwin documentation - there is no place to retrieve a version # for cygwin itself - only for specific packages. So it would seem that that's all we can/should do. Robert Ramey

3 3

[program_options] Proposed feature to provide option namespace prefixing
by Monty Taylor 14 Jun '10

14 Jun '10

Hi! I'm a developer on the Drizzle project, and we're currently replacing the home-grown getopt wrapper we inherited from the MySQL codebase with Boost.Program_options. So far, we're thrilled and it's going great, so thanks! We've focused on the client utilities to start, but as we're coming up on the server, we have an issue that we have an internal solution for, but which seems like it might be something that could be more generally useful, so I thought I'd mention it here, and if there is any interest, I can work up a proper code submission. The situation has to do with plugin modules and option names. In our current system, we enforce an option name prefix that matches the module name. For instance, if you are the InnoDB plugin author, you would declare an option named "buffer_pool_size" which would be presented to the user as "--innodb_buffer_pool_size", and the server/plugin registration handles prepending the module name to the option name for you. (you cannot choose to not do this) For those following along at home, you'll notice the _ we're using for the concatenation - we're happy changing that to be a "." so that the program_options config file sections will work in a sensible way. Our approach to doing this with Boost.Program_options at the moment is to wrap options_description_easy_init in a class. Something like: class DRIZZLED_API options_context { const std::string &module_name; po::options_description_easy_init &po_options; std::string prepend_name(const char *name); public: options_context(const std::string &module_name_in, po::options_description_easy_init &po_options_in); options_context& operator()(const char* name, const char* description) { std::string new_name(module_name); new_name.push_back('.'); new_name.append(name); po_options(new_name.c_str(), description); return *this; } ... }; Then in server plugin registration, a context is created around the real program_options and is is handed to the plugin module: module.register_options(options_context(module.get_name(), commandline_options.add_options()); It seems like a possibly nicer or more integrated approach would be something that would look like this: module.register_options(commandline_options.add_options(module.get_name()); And given the mapping of config file sections to name-dotted prefixes, it seems like it wouldn't be a ridiculous addition. Is anybody interested in me reworking what we end up with to be usable or applicable back to the Boost core? Thanks! Monty

3 3

[GSoC][Phoenix3] Regarding mutability of arguments passed to phoenix expressions
by Thomas Heller 14 Jun '10

14 Jun '10

Regarding arguments to phoenix expressions there are two possibilities. The first is: Arguments are mutable. The current phoenix is implemented to be able to this. Example: int i( 1 ); ( ++phoenix::arg_names::arg1 )( i ); The result of ++phoenix::arg_names::arg1 will be 2, i will have the value 2 after the expression is evaluated. The other approach would follow a more functional programming style as the data will not be mutable int i( 1 ); [1] ( ++phoenix::arg_names::arg1 )( i ); [2] ( ++phoenix::arg_names::arg1 + phoenix::arg_names::arg1 )( i ); The result of [1] will be 2, however i does not get changed (it remains to be 1). The result of [2] will be 3. i still unchanged. This example would be working "out-of-the-box" with the current prototypes. To get the mutability back into phoenix i propose the use of phoenix::ref. I favor the second approach. However, this would break API compatibility between the existing implementation. The question i want to ask the current and prospective users if it feasible to break your existing code? Is there a lot of existing code depending on this behaviour? Does it make sense to break code in such a way? Regards, Thomas

10 28

[property_tree] handling of filesystem::path
by Johan Råde 13 Jun '10

13 Jun '10

property_tree::ptree does not handle filesystem::path values correctly if the path contains spaces. Here is a proposed fix and a test. The test succeeds, but if you comment out the patch, then the test fails. ---------------------------------------------------------------------------------- #include <boost/property_tree/ptree.hpp> // patch that fixes the problem namespace boost { namespace filesystem { template<class String, class PathTraits> class basic_path; }}; namespace boost { namespace property_tree { template<typename String, typename PathTraits> struct path_translator { typedef boost::filesystem::basic_path<String, PathTraits> Path; typedef String internal_type; typedef Path external_type; boost::optional<Path> get_value(const String& s) { return Path(s); } boost::optional<String> put_value(const Path &p) { return p.string(); } }; template <typename Char, typename StringTraits, typename Alloc, typename PathTraits> struct translator_between< std::basic_string<Char, StringTraits, Alloc>, boost::filesystem::basic_path<std::basic_string<Char, StringTraits, Alloc>, PathTraits> > { typedef std::basic_string<Char, StringTraits, Alloc> String; typedef path_translator<String, PathTraits> type; }; }} // a simple test #include <boost/filesystem/path.hpp> #include <boost/optional.hpp> using boost::filesystem::path; using boost::optional; using boost::property_tree::ptree; int main() { path p1("a b"); ptree t; t.put_value(p1); optional<path> p2 = t.get_value_optional<path>(); assert(p2); assert(p1 == *p2); }

3 3

Bug sprint daily update for Sunday, June 13th
by Marshall Clow 13 Jun '10

13 Jun '10

We're almost done! As of 0645 Pacific time today, we had 789 open trac tickets. That is down by 17 from yesterday, and 200 since the start of the bug sprint! <louder> Let me say that again: We have closed 200 tickets since the start of the bug sprint. </louder> Congratulations to everyone who has been helping. Today is the last day of the bug sprint. If you've been working on something, today is the day to finish it! Total ticket counts: Saturday 989 Sunday 988 Monday 958 Tuesday 938 Wednesday 894 Thursday 854 Friday 824 Saturday 806 Sunday 789 Activity summary for yesterday (I'm counting tickets by hand here, here so blame my crummy math if it doesn't add up) New tickets: 4 Modified: 7 Closed: 21 Reopened: 0 Today, rather than the summary totals for yesterday, I have deltas; changes in the totals. If you would like to see the totals, they are available online at: Open ticket count by owner: https://svn.boost.org/trac/boost/report/18 Open ticket count by component: https://svn.boost.org/trac/boost/report/19 Open ticket count by type https://svn.boost.org/trac/boost/report/20 (Overwhelmingly, these are 'bugs') Open ticket count by milestone: https://svn.boost.org/trac/boost/report/21 (All changes are since the start of the bug sprint; 0800 PDT Saturday June 5th) Changed totals by library: thread -39 test -27 None -17 fusion -14 website -10 string_algo -9 filesystem -8 variant -7 date_time -6 function -6 iterator -6 concept_check -5 multi_array -5 Getting Started Guide -4 Python -4 mpl -4 random -4 tuple -4 asio -3 lambda -3 units -3 Building Boost -2 dynamic_bitset-2 foreach -2 lexical_cast -2 tokenizer -2 GIL -1 Regression Testing -1 assign -1 function_types -1 graph -1 io -1 iostreams -1 mpi -1 parameter -1 pool -1 regex -1 signals2 -1 trac / subversion -1 circular_buffer 1 program_options 1 serialization 1 utility 1 Documentation 2 property_tree 2 build 4 Changed totals by author: anthonyw -38 rogeeff -27 <none> -20 djowel -17 dave -16 grafik -10 pavol_droba -9 bemandawew -8 dgregor -8 ebf -7 az_sw_dude -6 jsiek -6 no-maintainer -6 garcia -5 agurtovoy -4 chris_kohlhoff -3 dlwalker -2 eric_niebler -2 gennaro_prota -2 matthiasschabel -2 nasonov -2 bschaeling -1 cnewbold -1 danieljames -1 emildotchevski -1 fmhess -1 hljin -1 jefffaust -1 johnmaddock -1 nesotto -1 speedsnail -1 steven_watanabe -1 t_schwinger -1 turkanis -1 cornedbee 1 jano_gaspar 1 jewillco 1 matias 1 niels_dekker 1 ramey 1 witt 1 vladimir_prus 7 Changed totals by category: Bugs -147 Patches -27 Feature Requests -17 Tasks -5 Support Requests -2 Library Submissions -1 -- Marshall

2 1

[vault] Malware in the Boost Vault!
by Chad Nelson 13 Jun '10

13 Jun '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 "Sexy Live.zip", uploaded to the Vault on March 31st by "gr7ne2009", is apparently some kind of Trojan masquerading as a Windows screen saver, according to various antivirus programs (checked with both virusscan.jotti.org and www.virustotal.com) Who has access to remove it? - -- Chad Nelson Oak Circle Software, Inc. * * * -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwUA0YACgkQp9x9jeZ9/wRLTACg7MglGcYo8kHUW0542YvJexf6 N8cAoPgBzbA3zhZB064rsFMHLf/s8c9f =KL39 -----END PGP SIGNATURE-----

2 7

[spirit2] How to get encoding-specific parsers by character type
by Andrey Semashev 12 Jun '10

12 Jun '10

I was wondering if it was possible to get encoding-specific parsers by character type? Something like that: template< typename CharT > struct encoding_specific { ... }; typedef encoding_specific< char > narrow; narrow::char_; // equivalent to spirit::standard::char_ typedef encoding_specific< wchar_t > wide; wide::char_; // equivalent to spirit::standard_wide::char_ This would help a lot in generic programming, when the character type is not known. Is there a tool like that already? If not, could it be added?

4 9

Bug sprint daily update for Saturday, June 12th
by Marshall Clow 12 Jun '10

12 Jun '10

Another good day in the code mines! As of 0800 Pacific time today, we had 806 open trac tickets. That is down by 18 from yesterday, and 183 since the start of the bug sprint! There's only two days left in the bug sprint (Friday, Saturday, Sunday) Keep up the great work! Total ticket counts: Saturday 989 Sunday 988 Monday 958 Tuesday 938 Wednesday 894 Thursday 854 Friday 824 Saturday 806 Activity summary for yesterday (I'm counting tickets by hand here, here so blame my crummy math if it doesn't add up) New tickets: 1 Modified: 10 Closed: 20 Reopened: 1 Today, rather than the summary totals for yesterday, I have deltas; changes in the totals. If you'ld like to see the totals, they are available online at: Open ticket count by owner: https://svn.boost.org/trac/boost/report/18 Open ticket count by component: https://svn.boost.org/trac/boost/report/19 Open ticket count by type https://svn.boost.org/trac/boost/report/20 (Overwhelmingly, these are 'bugs') Open ticket count by milestone: https://svn.boost.org/trac/boost/report/21 (All changes are since the start of the bug sprint; 0800 PDT Saturday June 5th) Changed totals by library: thread -39 test -27 None -17 website -10 string_algo -9 variant -7 date_time -6 function -6 iterator -6 concept_check -5 filesystem -5 fusion -5 multi_array -5 Getting Started Guide -4 asio -4 mpl -4 random -4 tuple -4 lambda -3 units -3 Building Boost -2 foreach -2 lexical_cast -2 tokenizer -2 GIL -1 Python -1 Regression Testing -1 assign -1 function_types -1 graph -1 io -1 mpi -1 pool -1 regex -1 signals2 -1 spirit -1 trac / subversion -1 circular_buffer 1 program_options 1 serialization 1 utility 1 Documentation 2 property_tree 2 build 4 Changed totals by author: anthonyw -38 rogeeff -27 <none> -20 dave -14 grafik -9 pavol_droba -9 dgregor -8 djowel -8 ebf -7 az_sw_dude -6 jsiek -6 no-maintainer -6 bemandawes -5 garcia -5 agurtovoy -4 chris_kohlhoff -4 dlwalker -2 eric_niebler -2 matthiasschabel -2 nasonov -2 bschaeling -1 cnewbold -1 danieljames -1 emildotchevski -1 fmhess -1 hkaiser -1 hljin -1 jefffaust -1 johnmaddock -1 nesotto -1 speedsnail -1 steven_watanabe -1 t_schwinger -1 cornedbee 1 danielw 1 jano_gaspar 1 jewillco 1 matias 1 niels_dekker 1 ramey 1 witt 1 vladimir_prus 7 Changed totals by category: Bugs -134 Patches -24 Feature Requests -16 Tasks -5 Support Requests -2 Library Submissions -1 -- Marshall

2 1

Re: [boost] [msm] Problems with no_message_queue and pseudo exit states
by Christophe Henry 12 Jun '10

12 Jun '10

> I know your are quiet bussy releasing msm but we found something and we do > not know whether it is the intended behaviour or a bug. > > We implemented a little state machine with a submachine. The submachine > has an pseudo exit state. > If we use "typedef no_message_queue" in the state machine as well as in > the submachine, then the state machines get somehow mixed up and do not > act normally once you leave the submachine via the pseudo exit state. > In that case msm does not exit the pseudo exit state. > > We followed almost your example that you provide in the documentation. > > Is that known to you? Does it make sense to fix that or are there serious > reasons why msm behaves like that? It's clearly a doc bug, I thought I had written it, but looks like I didn't :( Pseudo exit states are implemented by generating a new event (convertible from the original one) upon entering the pseudo entry, in order to get the UML priority right (deepest-level transitions tried first for a given event). This effectively makes pseudo exit states and no_message_queue incompatible, at least for the containing machine. I'm not completely happy with this implementation so this one also is on my radar. Thanks for reporting this. I wanted to add during the WE the points you already reported into the doc so I will add this restriction too. If I forget nothing: - pseudo exit points / no_message_queue - no explicit entry to submachines at the moment - references in the forwarding constructor with ref/cref - add some explanations for the entry state / explicit entry syntax If I forgot something, we still have some time before the release. Regards, Christophe

1 0

[iterator adaptor] requires default constructor?
by Neal Becker 12 Jun '10

12 Jun '10

It seems an iterator requires a default constructor in order to be adapted by iterator adaptor. This is due to (iterator_adaptor.hpp):279 iterator_adaptor() {} Is this really necessary?

4 6