April 2013 - Boost - lists.preview.boost.org

'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

[log] Patch: rotating file collector (Was: Boost.Log: Any Comments?)
by Alexander Arhipenko 23 Apr '13

23 Apr '13

Hi, Just to remind the context, I'm pasting content from previous mail thread. On Tuesday 09 April 2013 18:43:05 Alexander Arhipenko wrote: >> ... >> [snip] >> ... >> >> It would be very nice to have rotation feature work the same way as in e.g. >> python logging library or Apache web server: >> * latest file has the name filename.log >> * previous file has the name filename.log.1 or filename.log.YYYY-MM-DD >> AFAIK, it's impossible to achieve in current implementation. >> >> Andrey, what do you think about this? >The library does not provide this behavior out of the box. But the file sink >uses a file collector object to collect rotated files. This collector can be >implemented by the user (it should derive from sinks::file::collector >interface) and it should be possible to implement it the way you describe. >Would you like to submit such implementation? I've added implementation of rotating file collector - the patch against boost log trunk attached. This is not the final version, I'm going at least to finish most of the TODOs. However, it would be nice to receive feedback and questions from library author as well as from people interested in this feature. Andrey, could you please find several minutes to review the attached patch? Also, I would like to discuss following question with you : rotate_file invocation in ~text_file_backend - I would prefer to have this call during text_file_backend construction phase. Regards

1 0

std::optional<T>
by Fernando Cacciola 23 Apr '13

23 Apr '13

Hi People, I'm pleased to announce that thanks to the outstanding effort of Andrzej Krzemienski who wrote the standard papers, and Ville Voutilainen who champion it during the meetings, we now have std::optional<T> in C++14! Cheers -- Fernando Cacciola www.scisoft-consulting.com

11 15

Plugin/Extension : DLL/so loading?
by Mathias Gaunard 23 Apr '13

23 Apr '13

I remember there were a couple of projects (Boost.Plugin or Boost.Extension) to support dynamic loading of a DLL/so plugin in a portable fashion in Boost. What has happened to these, and is there some code I can use somewhere?

3 4