June 2010 - Boost - lists.boost.org

[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

Bug sprint daily update for Friday, June 11th
by Marshall Clow 11 Jun '10

11 Jun '10

As of 0730 Pacific time today, we had 824 open trac tickets. That is down by 30 from yesterday, and 165 since the start of the bug sprint! There's only three 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 Thanks especially to Steven Watanabe, who has been a "bug fixing machine" this week ;-) (and thanks also to the rest of you who have been fixing bugs) 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: 2 Modified: 14 Closed: 33 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 -38 test -24 None -17 website -10 string_algo -9 variant -7 date_time -6 function -6 iterator -6 concept_check -5 multi_array -5 Getting Started Guide -4 asio -4 random -4 tuple -4 lambda -3 units -3 Building Boost -2 foreach -2 fusion -2 mpl -2 tokenizer -2 GIL -1 Regression Testing -1 assign -1 graph -1 io -1 lexical_cast -1 mpi -1 pool -1 regex -1 signals2 -1 spirit -1 trac / subversion -1 circular_buffer 1 exception 1 program_options 1 serialization 1 utility 1 Documentation 2 property_tree 2 build 4 Changed totals by author: anthonyw -37 rogeeff -24 <none> -20 dave -13 grafik -9 pavol_droba -9 dgregor -8 ebf -7 az_sw_dude -6 jsiek -6 no-maintainer -6 djowel -5 garcia -5 chris_kohlhoff -4 agurtovoy -2 dlwalker -2 eric_niebler -2 matthiasschabel -2 bschaeling -1 cnewbold -1 danieljames -1 fmhess -1 hkaiser -1 hljin -1 jefffaust -1 johnmaddock -1 nasonov -1 nesotto -1 speedsnail -1 steven_watanabe -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 -124 Patches -19 Feature Requests -14 Tasks -4 Support Requests -2 Library Submissions -1 -- Marshall

2 1

[gsoc] heaps
by Tim Blechmann 11 Jun '10

11 Jun '10

hi all, since the heaps/queues project is likely to be used by multiple people, i think it may be a good idea to share some ideas on the list ... for now, i have been implementing a (non-intrusive) d-ary heap, which was very useful to do some prototyping of the actual interface. all data structures support the following template arguments: typename T // value type bool stable // stability class Cmp // compare object class Alloc // allocator for internal data structures the interface matches the forward container requirement, except that it does not support iterators (only const_iterators) and container comparison. at the moment, i distinguish between immutable and mutable heaps. the interface for immutable heaps would look like this: class immutable_heap { public: // priority queue support value_type const & top(void) const; void push(value_type const & v); void pop(void); // merge support void merge (immutable_heap const & rhs); void merge_and_clear (immutable_heap & rhs); // moves all elements from rhs to *this }; for mutable heaps, i have been using a `handle' to refer to specific elements: class mutable_heap { public: typedef handle_type; // priority queue support value_type const & top(void) const; handle_type push(value_type const & v); void pop(void); // update via function void update(handle_type const & node, value_type const & v); void increase(handle_type const & node, value_type const & v); void decrease(handle_type const & node, value_type const & v); // force update after element has been changed via the handle void update(handle_type const & node); void increase(handle_type const & node); void decrease(handle_type const & node); // merge support void merge (mutable_heap const & rhs); void merge_and_clear (mutable_heap & rhs); }; the forced update api is rather dangerous, since the heap would enter an undefined state, of the node is changed, but the heap is not updated. otoh, it would help to update values using a different api than the assignment operator. also, i am unsure, whether by default the heaps should be min-heaps (like in most textbooks on data structures) or max-heaps (like std::priority_queue). so i'd be curious, what people think about it ... the code is available from my public git repository. i would be curious to hear some thoughts! http://tim.klingt.org/git?p=boost_heap.git cheers, tim -- tim(a)klingt.org http://tim.klingt.org A year ago, six months ago, I thought that I was an artist. I no longer think about it, I am. Henry Miller

3 5

[Filesystem] Dual V2 + V3 support progress report
by Beman Dawes 11 Jun '10

11 Jun '10

I've created a branch to develop dual V2 + V3 support via namespace hoisting, as suggested by Scott McMurray, Andrey Semashev, and others. See https://svn.boost.org/svn/boost/branches/filesystem3 Seems to work well, and is lots easier to use that the switching approach currently in trunk. I've tested only on Windows, but will give Linux and Mac OS X a try later today or tomorrow. Namespace hoisting will break some existing V2 code: * User specializations in namespace filesystem. This is presumably very unusual, breaks noisily, and the fix is trivial, so I don't see it as a show stopper. * Possible ADL problems. I don't fully understand when this might be a problem, but neither V2 or V3 hit it in any of the tests, so I doubt it is very serious. --Beman

1 0

[msm] Problems with no_message_queue and pseudo exit states
by Michael.Herchel＠rohde-schwarz.com 11 Jun '10

11 Jun '10

Hi Christophe, 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? Regards, Michael

1 0

Re: [boost] boost::asio 1.43 regression (canceling read operation doens't trigger operation_aborted)
by admin＠thefireflyproject.us 11 Jun '10

11 Jun '10

Philippe Vaucher <[1]philippe.vaucher(a)gmail.com> wrote: > The problem is that when BOOST_ASIO_ENABLE_CANCELIO is not defined, > asio\detail\win_iocp_handle_service.hpp makes it so > impl.safe_cancellation_thread_id_ is equal to 0 and then when cancelling the > following code is executed: This problem seems to be windows specific. I compiled and ran Philippes testcase ([2]http://codepad.org/yYrQEqSo) on Debian GNU/Linux with Boost 1.43. I got successful results with both and without BOOST_ASIO_ENABLE_CANCELIO defined. I compiled with g++-4.1, 4.2, 4.3 and 4.4 - system specs were: wash@Dortmunder:~/sandbox/concept_tests$ uname -a Linux Dortmunder 2.6.26-2-amd64 #1 SMP Tue Mar 9 22:29:32 UTC 2010 x86_64 GNU/Linux Bryce References 1. mailto://philippe.vaucher@gmail.com/ 2. http://codepad.org/yYrQEqSo

1 0