- Boost-users - lists.preview.boost.org

Re: [Boost-users] [boost] Boost.DLL formal review is ongoing
by Ralf Globisch 03 Jul '15

03 Jul '15

Hi, Firstly, thanks Anthony for submitting this useful library to boost, and to Vladimir for managing the review. - Should the library be accepted? Yes. I had been meaning to test the library for some time, and with the review reminder finally made some time to do so. My vote of yes is based on my (limited) positive experience with the library, as well as having followed past related discussions on the mailing list, in which many questions are addressed. (http://lists.boost.org/Archives/boost/2014/09/216650.php) I think boost.DLL should be accepted unless someone has a serious/valid reservation as to why this library should not to be accepted. - How useful is it? Very useful. It enabled me to add a test-plugin mechanism to an existing application (Windows and Linux) in a matter of minutes. - What's your evaluation of - Design Looks good to me. Simple to use, with good integration into rest of boost (e.g. file_system). I like the fact that the library is header only and minimal effort was required to integrate plug-in like functionality into an existing application. - Implementation I'm not knowledgeable enough to comment on this. - Documentations Good, the tutorials made it fairly easy to get going and covered my common usage scenarios Code is well commented. - How much effort did you put into your evaluation? About three hours worth of effort, reading through documentation and source code, and using library to create a very simple plug-in mechanism in an existing application. Tested basic plug-in functionality on Windows and Linux. - Did you attempt to use the library? On what systems and compilers? Yes -Linux Ubuntu 14.10 with gcc 4.9.1 with boost 1.57 -Window 7 64-bit with VS 2013 community edition with boost 1.58. Initially made the mistake of not checking the boost version (which had been 1.53 and caused lots of compilation errors.) Minor typo in documentation: Just above the "Full Sources" for tutorial 4 "If we want o make a traditional" should be "If we want to make a traditional" Regards, Ralf >>> Vladimir Prus <vladimir.prus(a)gmail.com> 07/03/15 3:52 PM >>> The formal review of Boost.DLL library by Antony Polukhin is nearing the end of the first week. As of today, over 100 people read through the library's tutorial, suggesting quite some interest. However, no reviews were submitted yet. Please take the time to post your thoughts - even if you don't have time to do a full review, or try the library, comments on design and interfaces are still very valuable. The summary of the library features and review checklists are reproduced below. Boost.DLL is a C++98 library for comfortable work with DLL and DSO. Library provides a portable across platforms way to: - load libraries at runtime - import and export any native functions and variables - make alias names for C++ mangled functions and symbols - query libraries/objects and executables for sections and exported symbols - self loading and self querying - getting program and module location by exported symbol The documentation can be found at: http://apolukhin.github.io/Boost.DLL/index.html and the source can be obtained at: https://github.com/apolukhin/Boost.DLL Please post your reviews on the mailing list and if possible, answer the following questions: - Should the library be accepted? - How useful is it? - What's your evaluation of - Design - Implementation - Documentations - Tests - How much effort did you put into your evaluation? - Did you attempt to use the library? On what systems and compilers? Thanks, Volodya _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. Please consider the environment before printing this email. -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. Please consider the environment before printing this email.

1 0

[asio] async udp socket latency
by Andrew Hundt 03 Jul '15

03 Jul '15

I'm having difficulty with latency when running an async asio udp socket. I don't have the same problems with an identical application that uses synchronous udp. I'm communicating with a physical device which permits a maximum 5ms latency for each UDP packet, and I'm currently getting a latency of 8ms with a std dev of 0.065ms which is surprisingly precise. I'm on Mac OS X 10.10.4 with Xcode 6.3.2 (6D2105). Here are some of the key details about this problem: - Sync UDP test program - works, staying under 5ms latency 100% of the time for over an hour - Code - main file KukaFRIClientDataTest.cpp <https://github.com/ahundt/grl/blob/master/test/KukaFRIClientDataTest.cpp> - UDP socket communication class KukaFriClientData.hpp <https://github.com/ahundt/grl/blob/master/include/grl/KukaFriClientData.hpp> - Key lines - calls socket.receive_from() then socket.send() at the lowest level. - receive_from call <https://github.com/ahundt/grl/blob/master/include/grl/KukaFriClientData.hpp…> - send call <https://github.com/ahundt/grl/blob/master/include/grl/KukaFriClientData.hpp…> - Async UDP test program - buggy, 8ms w/ 0.065 ms std dev, continuously high latency - Code - main file KukaFRITest.cpp <https://github.com/ahundt/grl/blob/master/test/KukaFRITest.cpp> - High level wrapper class KukaFRIThreadSeparator.hpp <https://github.com/ahundt/grl/blob/master/include/grl/KukaFRIThreadSeparato…> - Low level wrapper class KukaFRI.hpp <https://github.com/ahundt/grl/blob/master/include/grl/KukaFRI.hpp> . - Key lines - calls socket_.async_receive_from() then that handler calls socket_.async_send_to(), which calls the final callback with the results. - async_receive_from call <https://github.com/ahundt/grl/blob/master/include/grl/KukaFRI.hpp#L374> - async_send_to_call <https://github.com/ahundt/grl/blob/master/include/grl/KukaFRI.hpp#L432> Does anyone have insight into why this latency issue may be occurring in the Async UDP version? Thanks. Cheers! Andrew Hundt

5 7

Re: [Boost-users] Boost-users Digest, Vol 4182, Issue 1
by Carl Wallace 02 Jul '15

02 Jul '15

>Date: Wed, 1 Jul 2015 15:04:34 +0900 >From: Kohei Takahashi <flast(a)flast.jp> >To: boost-users(a)lists.boost.org >Subject: Re: [Boost-users] Boost-users Digest, Vol 4181, Issue 1 > >>> Can I get (minimal) reproducible code or more detailed error log? >>> >>> Best, >>> Kihei >> This stripped down code snip is enough to trigger the error when the >>1.58 >> code is in place and compiles fine when the code from 1.54 is >>substituted >> in the place I indicating initially. This code is not intended to do >> anything and I have not run it. I can send the original error message if >> you like too. Will send that privately if you want it. >It should be fixed by https://github.com/boostorg/fusion/pull/87. It worked. Thanks.

1 0

Boost 1.58 and Intel Compiler 15
by Matthieu Brucher 02 Jul '15

02 Jul '15

Hi, Has any one worked with the latest Intel compiler on Linux? I'm hit with some Spirit/Fusion issues that don't arise with gcc 4.8.2 or clang 3.6.0. Quite difficult to diminish the number of lines in my example case, as the errors are different between in project and out of project... Cheers, Matthieu -- Information System Engineer, Ph.D. Blog: http://matt.eifelle.com LinkedIn: http://www.linkedin.com/in/matthieubrucher Music band: http://liliejay.com/

1 1

Re: [Boost-users] Boost-users Digest, Vol 4181, Issue 1
by Carl Wallace 01 Jul '15

01 Jul '15

> >Message: 7 >Date: Tue, 30 Jun 2015 11:08:50 +0900 >From: Kohei Takahashi <flast(a)flast.jp> >To: boost-users(a)lists.boost.org >Subject: Re: [Boost-users] fusion error when compiling graphviz code > using VC2010 >Message-ID: <5591FA32.6070802(a)flast.jp> >Content-Type: text/plain; charset="utf-8" > >Hi Carl, > >On 2015/06/29 20:36, Carl Wallace wrote: >> We have been using Boost's graphviz support for several years and have >> upgraded through a few versions of Boost with no issues in some long >> stable code. However, when we moved to 1.58 our Windows build broke. We >> are still using VC2010, with plans to move to 2015 in the >>not-too-distant >> future. We have not yet tried 1.58 in VC2015. The error message is very >> large but emanates from here: >Can I get (minimal) reproducible code or more detailed error log? > >Best, >Kihei This stripped down code snip is enough to trigger the error when the 1.58 code is in place and compiles fine when the code from 1.54 is substituted in the place I indicating initially. This code is not intended to do anything and I have not run it. I can send the original error message if you like too. Will send that privately if you want it. #include <boost/graph/breadth_first_search.hpp> #include <boost/graph/visitors.hpp> #include <boost/graph/graphviz.hpp> using namespace boost; template <class Name, class ColorMap> class label_writer2 { public: label_writer2(Name _name, ColorMap _color) : name(_name), color(_color) {} template <class VertexOrEdge> void operator()(std::ostream& out, const VertexOrEdge& v) const { } private: Name name; ColorMap color; }; struct VertexProps { }; typedef adjacency_list < vecS, vecS, bidirectionalS, VertexProps> graph_t; typedef property_map<graph_t, std::string VertexProps::*>::type name_map_t; int _tmain(int argc, char* argv[]) { std::ostringstream oss; graph_t m_graph; name_map_t m_nameMap; two_bit_color_map<property_map<graph_t, vertex_index_t>::const_type>color_map(num_vertices(m_graph), get(vertex_index, m_graph)); boost::write_graphviz(oss, m_graph, label_writer2<name_map_t, two_bit_color_map<property_map<graph_t, vertex_index_t>::const_type> >(m_nameMap, color_map)); return 0; }

2 1

boost log linking
by Lane 01 Jul '15

01 Jul '15

I'm working with boost log examples (v1.55) of trivial logging and having issues linking against these libraries. I'm receiving these errors. undefined reference to `boost::log::v2s_mt_posix::core::get()' undefined reference to `boost::log::v2s_mt_posix::core::set_filter(boost::log::v2s_mt_posix::filter const&)' In function `main': undefined reference to `boost::log::v2s_mt_posix::trivial::logger::get()' undefined reference to `boost::log::v2s_mt_posix::trivial::logger::get()' undefined reference to `boost::log::v2s_mt_posix::trivial::logger::get()' undefined reference to `boost::log::v2s_mt_posix::trivial::logger::get()' undefined reference to `boost::log::v2s_mt_posix::trivial::logger::get()' more undefined references to `boost::log::v2s_mt_posix::trivial::logger::get()' follow What I don't understand is that I have the correct paths to where the shared libs are located in my make file (-L/usr/lib64) and also included the libs (-lboost_log -lboost_setup). I have these boost libs on my system. /usr/lib64/libboost_log_setup-mt.so /usr/lib64/libboost_log-mt.so /usr/lib64/libboost_log_setup.so /usr/lib64/libboost_log.so /usr/lib64/libboost_log_setup.so.1.55.0 /usr/lib64/libboost_log.so.1.55.0 /usr/lib32/libboost_log_setup-mt.so /usr/lib32/libboost_log-mt.so /usr/lib32/libboost_log_setup.so /usr/lib32/libboost_log.so /usr/lib32/libboost_log_setup.so.1.55.0 /usr/lib32/libboost_log.so.1.55.0 Anyone see what I'm doing wrong?

1 0

Thinking in HDF5
by nitin chandra 30 Jun '15

30 Jun '15

Hello All, I have been on this for a long time and have done a lot of research / reading on this topic, HDF5. To use it for development of in-house software for design calculation of various alignments. A lot many time the basic alignment information is picked from a map / satellite imageries. Kilometre, ground level, geographic feature on the proposed route, etc. , in a csv file. Any where between 7-9 files are generated for each alignment. 1. How to read / write data into the HDF5 file ? What after creating root ? 2. In a regular situation, I have 2 input file with 3 column csv data, and 2 output files. How to do that within the same root ? Will be working in Python and c / c++. This is just the basic. If I can do this much, I can do the rest, hopefully :) Thanks to All Nitin PS :- Will post in scipy-user list too.

2 2

fusion error when compiling graphviz code using VC2010
by Carl Wallace 30 Jun '15

30 Jun '15

We have been using Boost's graphviz support for several years and have upgraded through a few versions of Boost with no issues in some long stable code. However, when we moved to 1.58 our Windows build broke. We are still using VC2010, with plans to move to 2015 in the not-too-distant future. We have not yet tried 1.58 in VC2015. The error message is very large but emanates from here: boost/include/boost-1_58\boost/fusion/container/list/cons.hpp(86): error C2664: 'boost::xpressive::detail::alternates_list<Head,Tail>::alternates_list(cons t Head &,const boost::fusion::nil &)' : cannot convert parameter 1 from 'const boost::fusion::cons_iterator<Cons>' to 'const boost::xpressive::detail::static_xpression<Matcher,Next> &’ I am not familiar with the fusion or xpressive libraries, but after picking through the error messages and review of diff of changes since 1.54 (the version we are moving from), this looks like a template specialization problem. The problem is rooted in a regex that uses xpressive in the escape_dot_string function in the graphviz library. In 1.58 the function at the line identified in the error snip above is defined as follows: template <typename Sequence> BOOST_CONSTEXPR BOOST_FUSION_GPU_ENABLED cons( Sequence const& seq, typename boost::enable_if< mpl::and_< traits::is_sequence<Sequence>, mpl::not_<is_convertible<Sequence, Car> > > // use copy to car instead >::type* /*dummy*/ = 0 ) : car(*fusion::begin(seq)), cdr(fusion::next(fusion::begin(seq)), mpl::true_()) {} When we replace this with the following implementation from 1.54 the build works and it appears the desired functionality is working (though more testing is required). template <typename Sequence> BOOST_CONSTEXPR BOOST_FUSION_GPU_ENABLED cons( Sequence const& seq, typename boost::disable_if< mpl::or_< is_convertible<Sequence, cons>, // use copy ctor instead is_convertible<Sequence, Car> // use copy to car instead > >::type* /*dummy*/ = 0 ) : car(*fusion::begin(seq)), cdr(fusion::next(fusion::begin(seq)), mpl::true_()) {} Any thoughts? The new code in 1.58 builds and runs fine with no mods on OS X. We have not tried Linux yet.

2 1

[msm] is that correct behavior?
by Sam Fisher 29 Jun '15

29 Jun '15

Hi Christophe, For an fsm with orthogonal regions if any region rejects an event (guard returns false), the library blocks all anonymous transitions. for example, an fsm has two regions. Region 0 returns HANDLED_TRUE, region 1 returns HANDLED_GUARD_REJECT for the same event. region_processing_helper combines it into a single "HANDLED_TRUE | HANDLED_GUARD_REJECT" value. However function process_event_internal<> (state_machine.hpp) creates handle_eventless_transitions_helper that takes (handled == HANDLED_TRUE) as a condition for allowing transitions. should it be (handled & HANDLED_TRUE)? as a result, fsm is stuck in event that has an anonymous transition to another event. PS. I've seen the same condition (handled == HANDLED_TRUE) in do_post_handle_deferred function, but I do not use deferred events so I did not check that part.

2 1

[PBGL] Creating graph on multiple processes
by Alexander Frolov 29 Jun '15

29 Jun '15

Hi! I am trying to create undirected weighted graph on two mpi-processes. I use add_edge function to add edges (master (pid=0) process is responsible for this). For small graphs everything is ok. But when I create larger graphs (for instance, number of vertices is 2^20 and number of edges is 2^28) the program hangs supposedly in add_edge. For mpirun -np 1 there is no such problem. What can cause this issue? Thanks for any help! Best, Alex

1 1