- Boost - lists.boost.org

[gsoc-2013]Boost.multiprecision project
by Sagar Massand 24 Apr '13

24 Apr '13

Hi, I wanted to submit a proposal for the boost.multiprecision project. Please find attached the files:1)Proposal for the project 2)Naive code for karatsuba multiplcation in C. It would be very kind of you if you could give me suggestions, point out flaws etc. in this. Regards, Sagar Massand

1 0

Going forward with Boost.SIMD
by Mathias Gaunard 24 Apr '13

24 Apr '13

Hi, This week I presented a proposal to the C++ standards committee to provide a standard library component for SIMD computation based on the library in development Boost.SIMD (not yet a Boost library). I was hoping to get feedback on the interface and establish an API that would satisfy hardware and compiler vendors. Unfortunately the concurrency/parallelism group has decided that they do not want C++ to provide types representing SIMD registers. I'm afraid I don't quite understand the rationale for such a refusal; proposing more high-level constructs similar to valarray (or to our own library NT2) was suggested, but that's obviously a more complex and limited API, not a basic building block to program portably a specific processor unit. Development of Boost.SIMD will still proceed, aiming for integration in Boost, but standardization appears to be definitely out of the question. Any feedback of the API presented in the proposal is welcome. <http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3571.pdf>

7 19

[Runtime parameters reference]Regarding Call Stack Trace
by Hemanth Choudary M V (RBEI/ETA1) 24 Apr '13

24 Apr '13

Hello, We are running a boost unit test using command line (cmd). The command is: C:\> /c "D:\MyExecutable.exe" --run_test=testcase1,testcase2,testcase3, --report_format=xml --report_level=detailed --log_format=xml --log_level=all >test_log.xml 2>test_report.xml The output format is in XML. I would like to have the call stack for the failed test cases. Is it possible to write the call stack trace in test_report.xml or test_log.xml ? Is there any macro or Boost API can help me achieve this? Mit freundlichen Grüßen / Best Regards, Hemanth Choudary MV RBEI/ETA1

1 0

'XPath error : Undefined namespace prefix' when building boost.test docs
by legalize+jeeves＠mail.xmission.com 24 Apr '13

24 Apr '13

[Please do not mail me a copy of your followup] I get this error when I try to build the boost.test documentation and I'm not sure where it's coming from or what to do about it. Since the HTML files are commmitted to the repository, I can't tell if the documentation was actually generated or not. D:\Code\boost\svn-boost-trunk\libs\test\doc>b2 standalone ...found 39 targets... ...updating 1 target... xslt-xsltproc-dir.windows html\standalone_HTML.manifest XPath error : Undefined namespace prefix set XML_CATALOG_FILES=../../../bin.v2/boostbook_catalog.xml "d:/code/boost/boost-tools/bin/xsltproc.exe" --stringparam boost.defaults "Boos t" --stringparam chunk.toc "/D:/Code/boost/svn-boost-trunk/libs/test/doc/src/btl -toc.xml" --stringparam example.dir "file:///D:/Code/boost/svn-boost-trunk/libs/ test/doc/src/examples" --stringparam manifest "standalone_HTML.manifest" --strin gparam manual.toc "/D:/Code/boost/svn-boost-trunk/libs/test/doc/src/btl-toc.xml" --stringparam snippet.dir "file:///D:/Code/boost/svn-boost-trunk/libs/test/doc/ src/snippet" --path "D:\Code\boost\svn-boost-trunk\libs\test\doc/src" --xinclude -o "html/" "D:\Code\boost\svn-boost-trunk\libs\test\doc\src\xsl\html.xsl" "..\. .\..\bin.v2\libs\test\doc\msvc-11.0\debug\utf-boostbook-on\src\btl.docbook" ...failed xslt-xsltproc-dir.windows html\standalone_HTML.manifest... ...failed updating 1 target... D:\Code\boost\svn-boost-trunk\libs\test\doc> Any suggestions? -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Computer Graphics Museum <http://computergraphicsmuseum.org> The Terminals Wiki <http://terminals.classiccmp.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

2 7

Re: [boost] GSOC - Boost.SQL and Boost.Thread interest
by Guillaume Nuel 23 Apr '13

23 Apr '13

Hi Vicente ! > if you are interested on one of these projects, please send as soon as possible to this ML a concrete proposal.> If both subject interest you, you can make two proposals. My main choice for Thread is: Thread.Pool (Proposal n°2 on my homepage: http://immortal-pc.info/Boost.html )General idea: ( Syntax highlighting at: http://immortal-pc.info/Boost.html#threadPool_idea ) int f1( const char* i ) { std::cout << i << ':'; // ... return 'f'+1; } int f2( const char* i ) { //... return 'f'+2; } int f3( const char* i ) { //... return 'f'+3; } int f4() { //... return 20+20+2;// 42 Power ! ^^ } int f5() { //... return 'f'+5; } int main() { // I want 5 threads for my job. Boost::Pool bp(5); // Note: A great option would be to use the "main thread" for calculations. (OpenMP like) // With this idea, 5 threads needed => 4 new theads + the main thread // // Another interesting option would be to provide switch between thread and process (fork) // I love Python multiprocessing: // http://docs.python.org/2/library/multiprocessing.html#using-a-pool-of-worke… // Note: Using, C++11 Brace-Initialization => std::initializer_list // Map function will call f1("Data1"), f1("Data2"), ... // >> ONE CALL PER parameter bp.map(f1, {"Data1","Data2","Data3","Data4","Data5","Data6","Data7"} );//!< WAITING function // "apply_async" will call {f1} with the parameter "Test" five times. // >> 1 CALL for f1 ! // >> 1 CALL for f2 ! // >> 1 CALL for f3 ! // >> f1 // f2 // f3 // -> // = paralell bp.apply_async(f1, "Test"); bp.apply_async(f2, "Test"); bp.apply_async(f3, "Test"); bp.execute();//!< WAINTING function // Or maybe a function who provide a result list for each function // Like this: std::array<int> functionsReturns = bp.get_result<int>();//!< WAITING function // And another great things from https://svn.boost.org/svn/boost/sandbox/async/libs/async/doc/html/toward_bo… // Multi-function without parameter // >> 1 CALL for f4 // >> 1 CALL for f5 // >> f4 // f5 // -> // = paralell // NOTE: same as: // bp.apply_async(f4); // bp.apply_async(f5); // bp.execute();//!< WAITING function bp.call_all(f4, f5);//!< WAITING function // Maybe a function who provide a result list for each function // Like this: std::array<int> functionsReturns = bp.get_result<int>(); return 0; } > The link doesn't worksOups. Sorry for the typo. http://immortal-pc.info/Boost.html Do you keep my proposal for Boost.SQL? Best,Guillaume

2 1

GSoC: Student applications can now be submitted
by Boris Schaeling 23 Apr '13

23 Apr '13

Student applications can now be submitted to <https://google-melange.appspot.com/gsoc/homepage/google/gsoc2013>. The deadline is 3 May. Boris

3 3

[iterator] Code/documentation mismatch in iterator_facade
by Gabriel Redner 23 Apr '13

23 Apr '13

Hi folks, I've stumbled upon an issue with iterator_facade. When creating a random access facade, one must implement the distance_to member function in order for std::distance to work. However, it looks like the arguments passed to this method are reversed from what the documentation states. Specifically, the docs [1] say (paraphrased): a.distance_to(b) is equivalent to distance(a, b). However, when I call std::distance(a, b), I find that b.distance_to(a) is invoked in the facade - the mirror image of what the docs say! This is not a problem if just wrapping some other random access iterator, but in my case the calculation of distance is nontrivial and this issue led to a rather tiresome debugging session and the solution (negating before returning from distance_to, knowing that iterator_facade will re-negate my response) is annoying to explain. Should I file a bug? A test case is appended to this message. -Gabe [1] http://www.boost.org/doc/libs/1_53_0/libs/iterator/doc/iterator_facade.html… ==================== #include <boost/iterator/iterator_facade.hpp> #include <vector> #include <iterator> #include <iostream> class vector_iterator : public boost::iterator_facade< vector_iterator, int, boost::random_access_traversal_tag> { public: vector_iterator(char tag, std::vector<int>::iterator it) : _tag(tag), _it(it) {} private: friend class boost::iterator_core_access; int& dereference() const { return *_it; } bool equal(vector_iterator const& other) const { return _it == other._it; } void increment() { ++_it; } void decrement() { --_it; } void advance(int n) { std::advance(_it, n); } std::vector<int>::iterator::difference_type distance_to(const vector_iterator& other) const { std::cerr << _tag << ".distance_to(" << other._tag << ")\n"; std::vector<int>::iterator::difference_type result = std::distance(_it, other._it); std::cerr << "result = " << result << '\n'; return result; } private: const char _tag; std::vector<int>::iterator _it; }; int main() { std::vector<int> v; v.push_back(1); v.push_back(2); vector_iterator a('a', v.begin()); vector_iterator b('b', v.end()); std::cerr << std::distance(a, b) << '\n'; } ====================

2 2

[REVIEW] Boost.Predef
by Joel Falcou 23 Apr '13

23 Apr '13

Hi all, first, I want to apologize for the delay in getting this review results out. Looks like my last email get lost at some point. Anyway, after the initial review of Rene Riviera Boost.Predef, my decision was to Conditionnally Accept Boost.Predef under the request that the comments raised during the review period were addressed. Since then, Rene worked hard on actually making those changes so I now feel confident to announce that Boost.Predef is ACCEPTED as a Boost library. Regards

1 0

GSOC 2013
by Computer Vision 23 Apr '13

23 Apr '13

Hello, I was very busy with my studies, am I late? Are there any free projects left? Kind Regards

3 2

Going forward with Boost.SIMD
by Niall Douglas 23 Apr '13

23 Apr '13

> Unfortunately the concurrency/parallelism group has decided that they do > not want C++ to provide types representing SIMD registers. > I'm afraid I don't quite understand the rationale for such a refusal; > proposing more high-level constructs similar to valarray (or to our own > library NT2) was suggested, but that's obviously a more complex and > limited API, not a basic building block to program portably a specific > processor unit. As much as a refusal can be heartbreaking, trust me when I say that indecision or indifference is worse. The fact they gave you a definite refusal is actually one of the least worst outcomes from an ISO standards proposal, because you can now move on without uncertainty. > Development of Boost.SIMD will still proceed, aiming for integration in > Boost, but standardization appears to be definitely out of the question. > Any feedback of the API presented in the proposal is welcome. > <http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3571.pdf> If I were still part of ISO standards, I'd observe the following: 1. GPU and CPU stream computation technologies are still merging. In other words, it's too soon to standardize this technology lest we accidentally break some novel form of new convergence. Happy to reconsider post-C++14. 2. It's hard to standardize current CPU SIMD implementations due to extremely irritating inconsistencies between vendors. For example, a generic straight port of SSE2 to NEON will have awful performance because SSE2 code does a lot of flipping between SIMD and non-SIMD, and because NEON is a coprocessor on ARM that generates poor performance. Another bug bear of mine on NEON is the lack of an equivalent to _mm_movemask_epi8(), which can be emulated in about eight NEON instructions, but in so doing you'll make code which was very speedy on SSE2 pretty slow in most cases on NEON. My point here is you cannot standardize such non-uniform behavior in a universally performant way, because you'll just get lowest common denominator performance across all SIMD implementations which kinda defeats its purpose. If all vendors were like NEON, or like SSE2, then we still have to see how CUDA and OpenCL pan out long run. 3. I am unsure if C++ is the appropriate language for SIMD standardization when perhaps a meta-form of JIT compiled C++ would be much superior (i.e. you supply LLVM bytecode, and it gets delivered to a GPU/CPU/whatever). We'll have those on the table with LLVM-type compilers. In other words, I would vote to wait and see what the market throws up. I appreciate that none of these three rationale are what you want to hear. Still, I hope my observations are useful to you. None of them suggests you shouldn't proceed with Boost.SIMD. Boost has a much wider remit than just as a testing ground for future C++ standard library features. But I suspect that if SIMD ever does get standardized, it won't look like your library or proposal because it will be based on technologies which don't exist yet. Hope that helps, Niall

3 2