- Boost - lists.boost.org

[asio] intergrate with message loop how to
by microcai 05 May '14

05 May '14

on platform windows, asio is using IOCP. and IOCP handel got signaled when there is pending events thus we can use MsgWaitForMultipleObjectsEx to wait on both the message queue and the IOCP. when we get a message, call PeekMessage and then DispatchMessage just like the mornal message loop. when we get IOCP singaled, call boost::asio::io_service::pull_one() and we processed the IO events ! by this way, we can have a thread that does both GUI and IO. that's very handy for non-performance critical applications. but, we can't access to the IOCP HANDLE used by asio. that's said. very said. on platform Linux, asio is using epoll. we can get X11 socket, and use asio to monitor that socket, and again calls X11 functions when the socket gets ready. thus, we can intergrate X11 message loop with asio, that's fine. if we are using gtk, it is more convinent to have epoll fd monitored by glib first, and then goes to run asio::io_service::pull_one(). again, that required access to epoll fd used by asio. if asio can expose these internal HANDLE or fd , that'll going to be more powefull !

2 1

[TypeIndex 3.0] Review Manager's Report
by Niall Douglas 04 May '14

04 May '14

Dear Boost, The second round of peer review of proposed Boost.TypeIndex finished on Wed 30th, and here is the review manager's report. My thanks to the five reviewers who took the time and trouble to submit full reviews, plus to everyone else who commented. Votes regarding acceptance: 4 voted to accept TypeIndex into Boost immediately. 1 voted to accept into Boost with conditions. Overall: I recommend immediate acceptance into Boost. Conditions: 1. No one liked the present boost::typeind namespace, almost anything else would be better. I see the namespace has already changed in the develop branch to boost::typeindex, so I think this is already solved. Other common comments: * More than one reviewer mentioned how they liked the docs. * More than one reviewer expressed a desire for an ability to programmatically parse through type specifier strings. I agree with Antony that that is another library which isn't TypeIndex (something Boost.Spirit based which works directly with mangled symbol string representations, representing them as a partial AST - preferably also with a libclang compatible backend - would be great, but that is a totally different library and TypeIndex 3.x provides extensibility for such an additional function). * More than one reviewer sought some method of preventing link if you mix up incompatible uses of TypeIndex and/or with RTTI. Niall -- Currently unemployed and looking for work in Ireland. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/

1 0

when can a trac ticket be considered closed
by Andrzej Krzemienski 04 May '14

04 May '14

Hi Everyone, Sorry for the silly question; at which point in Modular Boost Library workflow should I close a Trac ticket? Is it when I commit the relevant changes to branch master? Regards, &rzej

4 6

[GSoC, MPL11] Community probe
by Louis Dionne 04 May '14

04 May '14

Dear Boost, As a follow-up to [1], I am probing the community to help clarify what are your needs/expectations with respect to a new TMP library. Your involvement is important as it will help direct my work on an eventual successor to the MPL (in consultation with my mentor, Joel Falcou). I expect this to be the first of a series of probes to the community. This one focuses on backward compatibility with the MPL. COMMUNITY PROBE --------------- Please comment on how you would like to see the following points addressed by a new TMP library: (1) Backward compatibility with the MPL. Should it be a swap-in replacement? Is it enough to have an easy way to interoperate between both libraries (think Fusion/MPL interoperation)?. (2) Learning curve for users coming from the MPL. How important is it for you to be able to reuse your knowledge of the MPL (not of TMP, but of the MPL itself)?. Please get involved by posting constructive material. Regards, Louis Dionne PS: As I expect this to be the first of a couple of community-wide probes, is there a preferred way to do these (on the ML or elsewhere)? PPS: If the thread gets very active, I might be slow to answer. I'm spread between this and my finals. [1]: http://article.gmane.org/gmane.comp.lib.boost.devel/250424

8 21

[thread] shared_spinlock_t idea or faster shared_lock
by Antony Polukhin 02 May '14

02 May '14

Hi, This is just a refining of idea that was once implemented and worked well. The idea was to make shared spin lock. Here is some pseudo-code: class shared_spin_lock { atomic_max_uint_t state_; lock_shared() { do { // CAS loop auto snapshot = state_.load(); if (snapshot.has_writer_bit_set()) { reader_wait(); // waiting for writer to finish continue; } auto new_state = snapshot + 1; } while(!CAS(state, new_state)); } unlock_shared() { --state; } lock() { do { // CAS loop auto snapshot = state_.load(); if (snapshot.has_writer_bit_set()) { writer_wait(); // waiting for other writer to finish continue; } auto new_state = snapshot.set_writer_bit(); } while(!CAS(state, new_state)); // we have set the writer bit, now waiting for readers to finish while (state_.readers_count) ; // busy loop, can we do better? writer_started(); } unlock() { auto snapshot = state_.reset_writer_bit(); writer_finished(); ASSERT (snapshot.has_writer_bit_set()); } }; When all the *_wait() and writer_*() functions do nothing we get a shared spinlock. Now if we add helper mutex and make all the *_wait() functions to lock and unlock mutex; writer_start() - lock the mutex; writer finished() - unlock the mutex... we get a simplified shared_mutex that is faster (in theory) than current implementation. Is there an interest in such shared_spinlock_t? Any comments, suggestions? -- Best regards, Antony Polukhin

6 6

Misuse of warnings-as-errors?
by Chris Cooper 02 May '14

02 May '14

I’m pretty new to boost, but I’m sensing a desire to have cake and eat it too … correct me if I’m wrong of course! I see several places in the bug tracking system where people complain about compiler warnings and are told that fixing that sort of thing is completely ridiculous and the bugs are closed as “won't fix”. But then warnings-as-errors is enabled in several places – libs/pool/test, libs/type_traits/test, libs/units/test, etc. Shouldn’t boost have one or the other? Either warnings are important enough to treat them as errors in the unit tests (in which case they should get fixed) or else they’re not that important and warnings-as-errors shouldn’t be enabled by default anywhere? Thanks, Chris

7 6

[typeindex v3.0] Peer review begins Mon 21st ends Wed 30th
by Niall Douglas 02 May '14

02 May '14

Dear Boost, A second round of community review begins for proposed Boost.TypeIndex on Mon 21st, lasting ten days. I should apologise as it's my fault for starting another peer review straight after Boost.Align ends, however I was busy as Google Summer of Code admin until today, and I will be preparing to talk at C++ Now straight after this review ends. I hope that this doesn't affect the community's willingness to contribute to the review. Reminder of the report from the last TypeIndex v2.1 review: https://groups.google.com/forum/#!topic/boost-list/TeiSdkRkUF0 Reminder of the original peer review announcement: http://boost.2283326.n4.nabble.com/TypeIndex-Peer-review-period-for-li brary-acceptance-begins-ending-Thurs-21st-Nov-td4654788.html Source code: https://github.com/apolukhin/type_index/zipball/master Github: https://github.com/apolukhin/type_index Documentation: http://apolukhin.github.com/type_index/index.html Changes in TypeIndex v3.0 since v2.1 (from my own review of it): 1. Documentation is hugely improved over v2.1, lots of side by side examples illustrating the differences and similarities. 2. You can now create your own custom type indices using an extensible framework. 3. boost::typeind::type_info now exports raw_name() and pretty_name() to maximise MSVC-GCC compatibility, and to solve point 1 but not point 2 in the v2.1 report. 4. The undefined behaviour trick used in v2.1 has been replaced with a cast via the placeholder type boost::typeind::detail::ctti_data which can be viewed in https://github.com/apolukhin/type_index/blob/master/include/boost/type _index/ctti_type_index.hpp. There is an explanation in the comments there about this technique's compatibility with the C++ standard. 5. TypeIndex now defines everything in the boost::typeind namespace instead of the boost namespace. So: 1. What is your evaluation of the design? 2. What is your evaluation of the implementation? 3. What is your evaluation of the documentation? 4. What is your evaluation of the potential usefulness of the library? 5. Did you try to use the library? With what compiler? Did you have any problems? 6. How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? 7. Are you knowledgeable about the problem domain? And finally, every review should answer this question: 8. Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Thanks, Niall -- Currently unemployed and looking for work in Ireland. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/

7 29

Spam in tickets
by Antony Polukhin 02 May '14

02 May '14

Hi, Could some one see what can be done with this spam https://svn.boost.org/trac/boost/ticket/9963<https://svn.boost.org/trac/boost/ticket/7108> ? -- Best regards, Antony Polukhin

4 3

[graph] dijkstra algorithm object
by alex 30 Apr '14

30 Apr '14

Dear Jeremiah and Boost list, I'd like to suggest for inclusion in Boost Graph Library an algorithm object version of dijkstra shortest path algorithm. The following is an example how it can be used, assuming some graph, source node(s) and threshold distance: auto dijkstra make_dijkstra_object(graph, source_range); while(dijkstra()) { auto v = dijkstra.get_vertex(); auto distance_map = dijkstra.get<vertex_distance_t>(); if(get(distance_map, v) > threshold) break; } It is very close to what Jeremiah suggested 2 years ago: http://lists.boost.org/Archives/boost/2012/07/195300.php The main advantage for me is the possibility to interweave several shortest path searches. The algorithm object makes use of the stackless coroutine in Boost ASIO, which means it is relatively lightweight. However, on a large graph the algorithm object still takes about 20% more time than the normal dijkstra_shortest_path. The operator() progresses the algorithm to the next control point. Control points can correspond to all places where breadth_first_search invokes its visitor, but it is specified in compile time at which potential control points the algorithm actually yields. The default is to halt at the finish_vertex control point only. The make_dijkstra_object function can take all parameters through bgl_named_parameters, including the priority queue and the color map, which the existing dijkstra_shortest_path does not support. The code is part of the following project: http://code.google.com/p/resumable-dijkstra The algorithm object is defined here: http://code.google.com/p/resumable-dijkstra/source/browse/trunk/resumable-di jkstra/blink/graph/dijkstra_object.hpp I look forward to hear if there are any takers this time. Best wishes, Alex

1 0

[MPI] Fix can be merge to master
by Ben Pope 30 Apr '14

30 Apr '14

Please merge https://github.com/boostorg/mpi/commit/a7a2501242e78c65df9ff82c67dcad1f016b… to master. Should fix mpi and graph_parallel Ben

1 2