- Boost - lists.boost.org

Graph properties and GraphML
by Arthur Castonguay 21 Mar '12

21 Mar '12

I'm using 1.49.0 and am attempting to read a GraphML file that has graph attributes on it (example file below). My test program is below too. I've run into two issues. 1. The GraphML reader didn't quite handle them. There was some facilities put in place but it was never glued together. I added some code (patch below) and now it appears that that will do what I want... I'm getting "property not found" exception now. Great... onto item 2. 2. I cannot seem to wire the graph property into the dynamic properties. I've used the same syntax used for node and edge properties: props.property("gattr", get(&GraphProperty::gattr, g)); I've search examples and cannot find an instance of this to see if graph properties are handled differently. It's possible I've just written bad code for #2. I'm still working through the adjacency_list code to see if I can grok what's going on. Figured maybe someone more familiar with this could find the issue quickly. Once functionaly, I'll report a bug regarding item #1 but I want to ensure the writing of the GraphML works as well before doing that (the code appears to write graph attributes.. can't test yet due to item #2). For those that don't want to bother, this is the compile error I'm getting: boost/graph/adjacency_list.hpp: In function ‘typename boost::property_map<boost::adjacency_list<OutEdgeListS, VertexListS, DirectedS, VertexProperty, EdgeProperty, GraphProperty, EdgeListS>, T Bundle::*>::type boost::get(T Bundle::*, boost::adjacency_list<OutEdgeListS, VertexListS, DirectedS, VertexProperty, EdgeProperty, GraphProperty, EdgeListS>&) [with OutEdgeListS = boost::vecS, VertexListS = boost::vecS, DirectedS = boost::bidirectionalS, VertexProperty = NodeProperty, EdgeProperty = EdgeProperty, GraphProperty = GraphProperty, EdgeListS = boost::listS, T = std::string, Bundle = GraphProperty]’: ex.cpp:37: instantiated from here boost/boost/graph/adjacency_list.hpp:561: error: no matching function for call to ‘boost::bundle_property_map<boost::adjacency_list<boost::vecS, boost::vecS, boost::bidirectionalS, NodeProperty, EdgeProperty, GraphProperty, boost::listS>, boost::detail::edge_desc_impl<boost::bidirectional_tag, long unsigned int>, EdgeProperty, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >::bundle_property_map(boost::adjacency_list<boost::vecS, boost::vecS, boost::bidirectionalS, NodeProperty, EdgeProperty, GraphProperty, boost::listS>*, std::string GraphProperty::*&)’ boost/boost/graph/properties.hpp:397: note: candidates are: boost::bundle_property_map<Graph, Descriptor, Bundle, T>::bundle_property_map(Graph*, T Bundle::*) [with Graph = boost::adjacency_list<boost::vecS, boost::vecS, boost::bidirectionalS, NodeProperty, EdgeProperty, GraphProperty, boost::listS>, Descriptor = boost::detail::edge_desc_impl<boost::bidirectional_tag, long unsigned int>, Bundle = EdgeProperty, T = std::basic_string<char, std::char_traits<char>, std::allocator<char> >] boost/boost/graph/properties.hpp:396: note: boost::bundle_property_map<Graph, Descriptor, Bundle, T>::bundle_property_map() [with Graph = boost::adjacency_list<boost::vecS, boost::vecS, boost::bidirectionalS, NodeProperty, EdgeProperty, GraphProperty, boost::listS>, Descriptor = boost::detail::edge_desc_impl<boost::bidirectional_tag, long unsigned int>, Bundle = EdgeProperty, T = std::basic_string<char, std::char_traits<char>, std::allocator<char> >] boost/boost/graph/properties.hpp:390: note: boost::bundle_property_map<boost::adjacency_list<boost::vecS, boost::vecS, boost::bidirectionalS, NodeProperty, EdgeProperty, GraphProperty, boost::listS>, boost::detail::edge_desc_impl<boost::bidirectional_tag, long unsigned int>, EdgeProperty, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >::bundle_property_map(const boost::bundle_property_map<boost::adjacency_list<boost::vecS, boost::vecS, boost::bidirectionalS, NodeProperty, EdgeProperty, GraphProperty, boost::listS>, boost::detail::edge_desc_impl<boost::bidirectional_tag, long unsigned int>, EdgeProperty, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >&) Here's my compiler version: $ cc --version i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.1.00) Copyright (C) 2007 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Any ideas? Is item #2 a bug or dumbass programmer (aka me)? Regards, Arthur --- 8< Start ex.graphml 8< --- <?xml version="1.0" encoding="UTF-8"?> <graphml xmlns="http://graphml.graphdrawing.org/xmlns" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://graphml.graphdrawing.org/xmlns http://graphml.graphdrawing.org/xmlns/1.0/graphml.xsd"> <key id="key0" for="graph" attr.name="gattr" attr.type="string"/> <key id="key1" for="node" attr.name="nattr" attr.type="string"/> <key id="key2" for="edge" attr.name="eattr" attr.type="string"/> <graph id="G" edgedefault="directed"> <data key="key0">graphval</data> <node id="n0"> <data key="key1">nodeval0</data> </node> <node id="n1"> <data key="key1">nodeval1</data> </node> <edge source="n0" target="n1"> <data key="key2">edgeval</data> </edge> </graph> </graphml> --- 8< End ex.graphml 8< --- --- 8< Start ex.cpp 8< --- #include <iostream> #include <string> #include <boost/graph/adjacency_list.hpp> #include <boost/graph/graphml.hpp> #include <boost/property_map/dynamic_property_map.hpp> struct GraphProperty { std::string gattr; }; struct NodeProperty { std::string nattr; }; struct EdgeProperty { std::string eattr; }; typedef boost::adjacency_list<boost::vecS, boost::vecS, boost::bidirectionalS, NodeProperty, EdgeProperty, GraphProperty> Graph; using namespace std; using namespace boost; int main() { Graph g; dynamic_properties props; props.property("nattr", get(&NodeProperty::nattr, g)); props.property("eattr", get(&EdgeProperty::eattr, g)); props.property("gattr", get(&GraphProperty::gattr, g)); // Fails to compile try { read_graphml(cin, g, props); write_graphml(cout, g, props); } catch (parse_error e) { cerr << e.what() << endl; } catch (bad_parallel_edge e) { cerr << e.what() << endl; } catch (directed_graph_error e) { cerr << e.what() << endl; } catch (property_not_found e) { cerr << e.what() << endl; } catch (...) { cerr << "Caught unhandled excption" << endl; } return EXIT_SUCCESS; } --- 8< Start ex.cpp 8< --- Patch to enable graph properties on GraphML files. Using 1.49.0. Index: libs/graph/src/graphml.cpp =================================================================== --- libs/graph/src/graphml.cpp (revision 1) +++ libs/graph/src/graphml.cpp (working copy) @@ -74,6 +74,15 @@ std::vector<const ptree*> graphs; get_graphs(gml, graphs); BOOST_FOREACH(const ptree* gr, graphs) { + // Search for graph attributes + BOOST_FOREACH(const ptree::value_type& attr, *gr) { + if (attr.first != "data") continue; + std::string key = attr.second.get<std::string>(path("<xmlattr>/key")); + std::string value = attr.second.get_value(""); + handle_graph_property(key, value); + } + } + BOOST_FOREACH(const ptree* gr, graphs) { // Search for nodes BOOST_FOREACH(const ptree::value_type& node, *gr) { if (node.first != "node") continue; @@ -183,6 +192,11 @@ } } + void handle_graph_property(const std::string& key_id, const std::string& value) + { + m_g.set_graph_property(m_key_name[key_id], value, m_key_type[key_id]); + } + void handle_node_property(const std::string& key_id, const std::string& descriptor, const std::string& value) { m_g.set_vertex_property(m_key_name[key_id], m_vertex[descriptor], value, m_key_type[key_id]);

1 0

[lambda] Can't get simple lambda working...
by Robert Dailey 21 Mar '12

21 Mar '12

Here is a basic function I have: bool MimeDocument::GetExistingAttachment( std::string const& filename, std::vector<MessageAttachment> const& attachments, MessageAttachment& attachment ) { using namespace boost::lambda; using boost::lambda::_1; std::vector<MessageAttachment>::const_iterator it = std::find_if( attachments.begin(), attachments.end(), bind( &MessageAttachment::name, _1 ) == filename ); if( it != attachments.end() ) { attachment = *it; return true; } return false; } MessageAttachment::name() has 2 overloads, one that takes 1 parameter and the other that takes no parameter. I'm attempting to call the version that accepts no parameters and returns a "char const*". I want to then compare this value to the local variable "filename". This should happen for each object in the vector (_1). I get various types of compiler errors on MSVC9. They all have to do with C2780: 1>c:\code\work\cmake-mds\server\gmmserver\domino\server\interface\dimime.cpp(287) : error C2780: 'const boost::lambda::lambda_functor<boost::lambda::lambda_functor_base<boost::lambda::action<10,boost::lambda::function_action<10,T>>,detail::bind_tuple_mapper<const Arg1,const Arg2,const Arg3,const Arg4,const Arg5,const Arg6,const Arg7,const Arg8,const Arg9,const Arg10>::type>> boost::lambda::bind(const Arg1 &,const Arg2 &,const Arg3 &,const Arg4 &,const Arg5 &,const Arg6 &,const Arg7 &,const Arg8 &,const Arg9 &,const Arg10 &)' : expects 10 arguments - 2 provided 1> c:\code\work\cmake-mds\build-vc9\third_party\boost\1.48.0\include\boost\lambda\detail\bind_functions.hpp(1743) : see declaration of 'boost::lambda::bind' Anyone have any idea what I'm doing wrong? --------- Robert Dailey

6 10

Re: [boost] [git] Mercurial?
by Steve Ramsey 21 Mar '12

21 Mar '12

On Mar 20, 2012, at 8:40 PM, Edward Diener <eldiener(a)tropicsoft.com> wrote: > I have never heard a single technical argument, in all the endless > mentions of Git among the people riding that bandwagon, why Git is > better than SVN, or even why any DVCS is better than a centralized SCCS. > I consider this whole move to Git and/or DVCS among "hip" programmers > little more than a move to conform with what others are doing and feel > "cool". > > I am perfectly willing to read well-chosen technical arguments but not > from people already sold on one side or the other. But I really despair > of anyone being able to present such arguments in the atmosphere created > by Git fanatics and DVCS fanatics. The only thing I have gotten from all > this is "I've tried it, I like it, and therefore its superior". > > Feel free, anyone, to point me to a purely technical discussion, > article, whatnot, explaining the practical reasons why using a DVCS, or > Git, is more productive and more pleasurable than using a centralized > SCCS like Subversion. For what it’s worth, here is a series of articles that sold me on DVCS (and Mercurial in particular, though that’s neither here nor there) after spending quite some time wondering whether to bother: <http://hginit.com/> It’s a typically breezy Joel Spolsky piece, but it does cover use cases nicely. Steve

2 1

[CRC][VC++] Can someone debug this?
by Daryle Walker 20 Mar '12

20 Mar '12

Are we still preparing for a release? If not (or afterwards), could someone check why the trunk's version of Boost.CRC, with more Boost.MPL usage, is choking on all versions of Visual C++. Only the latest version gives a specific error; previous versions just dump out. Daryle W.

3 3

BOOST_PP_ITERATE for huge mpl and fusion
by Hite, Christopher 20 Mar '12

20 Mar '12

"Not to 50!!!" - Princess Bride Things like mpl::vector and fusion::map have a configured limit like BOOST_MPL_LIMIT_VECTOR_SIZE. The documentation is dodgy and doesn't mention that while it is configurable you can't really configure it to be more than 50. Many people have stumbled here: http://boost.2283326.n4.nabble.com/msm-Boost-MPL-vector-limit-size-exceeded… http://lists.boost.org/Archives/boost/2004/08/70900.php http://comments.gmane.org/gmane.comp.lib.boost.user/55679 http://lists.boost.org/Archives/boost/2010/09/170443.php Appearantly there are some scripts to generate these headers, but they may not work anymore. I had to rush hack things in my code to make several containers go over 50 in one compilation scope. #define ULTIMATE_N 70 #include <boost/mpl/vector/vector50.hpp> namespace boost { namespace mpl { # define BOOST_PP_ITERATION_PARAMS_1 \ (3,(51, ULTIMATE_N, <boost/mpl/vector/aux_/numbered.hpp>)) # include BOOST_PP_ITERATE() }} I'd really like to fix this in boost. AFAICT all I have to do is find all *50.hpp files and replace the 50 with the appropriate config limit. I count 74 instances of this stuff going on! Mostly it's phoenix, mpl, and fusion. So to wrap it up my questions are: 1) Do the scripts still work? Does anyone use them? Are they regularly tested? 2) Does anyone see a problem with my simple fix? Chris

5 9

Possible bug in libs/context/src/asm/fcontext_ppc64_sysv_elf_gas.S
by Jeremiah Willcock 20 Mar '12

20 Mar '12

This code refers to registers r40 and r41 in several places; I think those should be r30 and r31. There are also many typos in the comments in that source file. -- Jeremiah Willcock

1 0

[mpl] +[fusion] + [phoenix] undocumented hard-coded limit=50
by Hite, Christopher 20 Mar '12

20 Mar '12

This is a re-post of " [boost] BOOST_PP_ITERATE for huge mpl and fusion". I think problem may be that I didn't target a particular library because it happens in three. There is an undocumented hard-coded limit of 50 in MPL, Fusion, and Phoenix. I count two impls 1) has 20 elements all generated boost_1_49_0/boost/mpl/aux_/preprocessed/gcc/vector.hpp 2) stops at 50 boost_1_49_0/boost/mpl/vector/vector50.hpp I don't know if there's a way to generate more. Probably you need python. If that's the case, IMHO this should be documented so users can do it. This doesn't work: #define BOOST_MPL_CFG_NO_PREPROCESSED_HEADERS #define BOOST_MPL_LIMIT_VECTOR_SIZE 60 #include <boost/mpl/vector.hpp> boost_1_49_0/boost/mpl/vector.hpp:36:73: fatal error: boost/mpl/vector/vector60.hpp: No such file or directory Can someone please help. I've upgraded my copy of boost. I've tried figuring out how these headers work. I'm pretty sure I could fix it if I really had to by replacing the 50 in the last file with the *_SIZE. I have this ugly hack in my code to keep things working. Would someone please help?!? Acknowledging the problem would be a start. Chris

4 3

[xpressive] Does '_' match newlines?
by Robert Dailey 19 Mar '12

19 Mar '12

I have the following static regex: sregex filename_re = icase("Content-Disposition:") >> -*_ >> "filename=" >> (s2=-+_) >> ';' ; I want the "*_" part to also match newline characters. I didn't see any flag to turn this on or off. Is this on by default? I see boost::xpressive::regex_constants::syntax_option_type::not_dot_newline, but not sure where you would (or wouldn't) specify this. I only recall the ability to specify flags for a regex when you compile a dynamic regex, not a static one. Help is appreciated! --------- Robert Dailey

2 1

new Overload library version
by Marco Cecchetti 19 Mar '12

19 Mar '12

Hi everyone! I noticed that an overloaded function utility has appeared under boost/functional as a spin-off of Camiti's Boost.Local library. Indeed on 2007 I had begun implementing something similar. All started from a Joel de Guzman's post where he showed a proof of concept of a thin-wrapper of several Boost.Functions. See: http://lists.boost.org/Archives/boost/2007/09/127906.php On that code base, I designed Overload, a small library whose interface matches as much as possible Boost.Function interface. Some documentation was written down thanks to the help and support of Dean M. Berris. Due to lack of time and the small amount of use cases I stopped spending my time on such a project. Anyway lately I have been working on the Overload library again. I have performed a light re-design of the interface, added a few new features and a lot of more testing, finally I've got to improve documentation. I uploaded the new version on the sandbox. In case you are interested these are the links: - library: http://svn.boost.org/svn/boost/sandbox/overload/trunk/ - documentation: http://svn.boost.org/svn/boost/sandbox/overload/trunk/libs/overload/docs/ht… Please don't reply to me about the not so proper library name, I could change it but it is a secondary issue. Regards, -- Marco -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

1 0

[chrono] [thread] Test names too long
by Steven Watanabe 19 Mar '12

19 Mar '12

AMDG When I try to run the tests for Boost.Thread or Boost.Chrono I get an error like: failed to write output file '..\bin.v2\libs\chrono\test\basic_stopwatch_reporter _laps_accumulator_set_pass_shared.test\msvc-10.0express\debug\asynch-exceptions- on\threading-multi\stopwatch\basic_stopwatch_reporter_laps_accumulator_set_pass. obj.rsp'! Could the names possibly be made shorter? I can get it to build using --hash, but they're still rather long. In Christ, Steven Watanabe

4 5