- Boost - lists.boost.org

tools/regression/compiler_status.cpp: possible status bug for compile-only tests
by Phil Richards 19 Jun '05

19 Jun '05

Thought I would try and track down the reason for the "Fail" being shown in the HTML regression report generated by compiler_status. (Is there a better mailing list/forum for reporting problems with these tools?) The following logic is used to determine whether a test passed or failed: xml::element_ptr dbp = xml::parse( file, pth.string() ); const xml::element & db( *dbp ); const xml::element & run_element( find_element( db, "run" ) ); pass = !run_element.name.empty() && attribute_value( run_element, "result" ) != "fail"; So, for a test to be shown as "Pass", !run_element.name.empty() must be true - which requires that the XML test result blob contains a "run" element. Tests which are aimed purely at testing expected compile-time fails (e.g., function/function_30) get the following XML generated by process_jam_log: <test-log library="function" test-name="function_30" test-type="compile" test-program="libs/function/test/function_30.cpp" target-directory="bin/boost/libs/function/test/function_30.test/gcc/debug" toolset="gcc" show-run-output="false"> <compile result="succeed" timestamp="2005-06-17 10:25:10 UTC"> </compile> </test-log> So, the test passed, but compiler_status will show a fail due to the lack of a "run" element. The "pass" assignment should take account of the "test-type". (I can put a patch together, but I might not cover all the cases since I don't know the system too well yet.) phil -- change name before "@" to "phil" for email

3 8

Boost.Iostreams breaks due to ::codecvt usage
by Julio M. Merino Vidal 19 Jun '05

19 Jun '05

Hi all, while developing some code for Boost, I've had to add some more tests to the configuration headers so that BOOST_NO_STDC_NAMESPACE gets defined when some functions cannot be found (e.g., std::strdup, which is missing under NetBSD). This is irrelevant, because this symbol could get defined in a future by other changes in Boost. The problem is that when BOOST_NO_STDC_NAMESPACE is defined under NetBSD, Boost.Iostreams does not work any more and breaks the build of programs using it. Consider the following code example: ----- #define BOOST_NO_STDC_NAMESPACE #include <boost/iostreams/device/file_descriptor.hpp> int main(void) { return 0; } ----- When building it, I get: ----- $ g++ -I/home/jmmv/opt/include test.cc In file included from /home/jmmv/opt/include/boost/iostreams/positioning.hpp:19, from /home/jmmv/opt/include/boost/iostreams/device/file_descriptor.hpp:24, from test.cc:2: /home/jmmv/opt/include/boost/iostreams/detail/config/codecvt.hpp:70: error: ` codecvt' not declared ----- The problem arises because codecvt does not exist in the global namespace under NetBSD, although it does inside std::. Therefore, the 'using ::codecvt' line (the one that triggers the error) breaks the build. I don't know how this should be fixed, so I'm just sending a bug report. Maybe the BOOST_NO_STDC_NAMESPACE definition should be made more fine grained, so that defining it due to the lack of a function does not affect others that may exist? Should I file a bug report or is this message enough? Thanks, -- Julio M. Merino Vidal <jmmv84(a)gmail.com> http://www.livejournal.com/users/jmmv/ The NetBSD Project - http://www.NetBSD.org/

2 3

Boost.Test, lexical_cast and gcc-2.95.3
by John Maddock 19 Jun '05

19 Jun '05

Anything that uses Boost.Test is currently failing with gcc-2.95.3, see for example: http://tinyurl.com/dkreq I'm not sure if this is a lexical_cast or test lib change that's broken things? John.

3 2

Re: [boost] lexical_cast update + Boost.Test question
by Joaquín Mª López Muñoz 19 Jun '05

19 Jun '05

The latest update of lexical_cat introduced a trivial bug, shown for instance at http://tinyurl.com/c9b8s. I'll be commiting the attached patch later today, if no one objects (or commits it first.) Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo 16a17 > #include <cstddef> 196c197 < template<class T, size_t N> --- > template<class T, std::size_t N>

2 1

[Boost-bugs] [ boost-Bugs-1223654 ] Pickle support for BGL Python bindings
by SourceForge.net 19 Jun '05

19 Jun '05

Bugs item #1223654, was opened at 2005-06-19 11:48 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1223654&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: graph Group: None Status: Open Resolution: None Priority: 5 Submitted By: Douglas Gregor (dgregor) Assigned to: Douglas Gregor (dgregor) Summary: Pickle support for BGL Python bindings Initial Comment: Doesn't look too hard... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1223654&group_… ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Re: [boost] [Ann]: Dox - a C++ documentation tool
by Brian Braatz 19 Jun '05

19 Jun '05

> -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Eric Goebelbecker > Sent: Saturday, June 18, 2005 10:03 AM > To: boost(a)lists.boost.org > Subject: Re: [boost] [Ann]: Dox - a C++ documentation tool > > The docs are up at http://www.ominor.net/boost/dox . > > I'm hoping to set up a method for automatically updating them in the > next few weeks. > [Brian Braatz Writes:] I like it, looks like it would come in handy when one is trying to figure out how something is implemented :)

1 0

Re: [boost] MPL: set<> not fully supporting compile time iteration?
by Brian Braatz 19 Jun '05

19 Jun '05

> -----Original Message----- > > Brian Braatz <brianb <at> rmtg.com> writes: > > > > > CLOSER (see below) > > > > > On Behalf Of Ryan > > > [snip] > > > Try: > > > > > > typedef mpl::copy > > > < > > > mpl::begin<myset> > > > , mpl::back_inserter<vec> > > > >::type result_vec; > > > > > > HTH > > > > > > -Ryan > > > > > > > [Brian Braatz Writes:] > > THANK YOU RYAN- I am compiling now (one step closer) > > But I am still not getting the expected (??) behavior > > here is the current code > > ... > [Ryan Writes:] > Sorry about the leading you down the wrong path Brian. I was really > thinking > about: > > typedef mpl::copy > < > mpl::iterator_range<mpl::begin<myset>::type, mpl::end<myset>::type > > , mpl::back_inserter< vec > > >::type result_vec; > > which would only be a work around but IMO is more similar to the runtime > equivalent. I am a little suprised the mpl::begin<> compiled, but I need > to > review Dave's and Alesky's MPL book again and will hopefully come to > understand. > > I was actually on the newsgroup yesterday to see the answer to your great > remove_duplicate_types question. I had just written the equivalent > runtime function using std::vector, std::sort, and std::unique and was > wondering > about how to handle std::sort in the compile_time world. I stopped on > this > thread because I saw that it could likely lead to the answer. > > Thanks for the great question; I'll try to test a little better before > answering > any in the future. Cheers, [Brian Braatz Writes:] Hey, when one is sitting there staring at code going "why doesn't this work?!?!?!?!?!"", ANY Thoughts are appreciated. (the more thoughts that are thrown out there the better:) :) Brian

1 0

Re: [boost] MPL: set<> not fully supporting compile time iteration?
by Brian Braatz 19 Jun '05

19 Jun '05

IT WORKS! (See below) > >> -----Original Message----- [Dave Abrahams Writes:] > I have checked in a fix for this problem. I even figured out how to > preprocess the right headers. Yay me! > > Well, maybe you should tell me if the fix works for you before I > strut and celebrate ;-) [Brian Braatz Writes:] YES THANK YOU! THANK YOU! THANK YOU! THANK YOU! THANK YOU! here is the original code: (note to reader from the future, this will NOT work on boost1.32- it should work on any version following) // Code sample for how to copy from a mpl::set<> to a mpl::vector<> // prints the names of the resulting vector struct print_type { template <typename T> void operator()(T const& v) const { std::cout << "[ " << typeid(v).name() << " ] "; } }; struct A {}; struct B {}; struct C {}; struct D {}; typedef mpl::set3<A,B,C> myset; typedef mpl::vector<> vec; // copy a set to a vector typedef mpl::copy < myset , back_inserter< vec::type > >::type result_vec; // Prints "3" cout << "result_vec size " << mpl::size<result_vec>::value << endl; // prints "[ struct C ] [ struct B ] [ struct A ] " mpl::for_each<result_vec::type>( print_type()); THANK YOU DAVID- This is a huge help. :)

1 0

Re: [boost] Wiki MPL FAQ Idea -was [RE: MPL: clever way to remove*all* duplicates in a(nonintegral) sequence?]
by Brian Braatz 19 Jun '05

19 Jun '05

[Brian Braatz Writes:] > > The basic idea is that the Question is listed, then the answer is > > listed. Then references to follow up information is listed. (i.e point > > them back to the MPL reference manual or the MPL book) > > > > what do you guys think? > [Dave Abrahams Writes:] > These all sound like great ideas to me. The great thing about a Wiki > is that you _don't_ need to ask permission in order to get started :) > [Brian Braatz Writes:] Ok- I have never 'added' anything to a wiki, and wasn't sure if Jeff Garland or someone had to allow the page to be created first. I think it would be extremely valuable though to have a Metaprogramming FAQ to collect common questions. I will (sometime this coming week) try to get something going for people to comment on. If someone knows of one that already exists, please say so (if its not boost, it still would be valuable to supply a link to it) Thanks Brian :)

1 0

RE: [boost] [Ann]: Dox - a C++ documentation tool
by Brian Braatz 19 Jun '05

19 Jun '05

Thanks for the response. Are you going to submit this as a boost tool? I am not extremely familiar with the whole documentation generation aspect of boost, so I am not sure how this would fit in. If you are planning to submit this, I suggest you: * Pay careful attention to anyone who responds to this mail who knows more about how the doc gen stuff works * "Go the last mile"- i.e. do whatever extra work needed to fully integrate this tool based on the feedback and thoughts you get (i.e. don't expect someone to do it for you) Maybe if you ran doxygen on boost, and then ran your tool on that and put it up on a web server somewhere, you could post a link here and people could see "the big picture". hope that helps in some way Brian :) > -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Narech Koumar > Sent: Thursday, June 09, 2005 1:57 PM > To: boost(a)lists.boost.org > Subject: Re: [boost] [Ann]: Dox - a C++ documentation tool > > Hi, > > > disadvantage: > > long emails trying to decide which theme to standardize on (grin) > > :) > > > > > Advantage- looks cleaner than doxygen. > > Glad you like it! > > > > > QUESTION: > > > > What tools do you depend on for the program to work? I.e. tcl, perl etc. > > What are the external dependancies? > > > > The only external dependency is Doxygen, which is included within the > distros. Naturally, under unix you need a shell (ie bash), under NT > cmd.exe . Finally a web browser is required in order to be able to read > the generated docs :) . That's all. > > > Sincerely, > > - NK > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost

4 10