December 2014 - Boost - lists.preview.boost.org

[compute] CL_QUEUE_OUT_OF_ORDER_EXEC_MODE_ENABLE
by Gruenke,Matt 31 Dec '14

31 Dec '14

I assumed there was some behind-the-scenes mechanism to maintain order of higher level operations, but I hadn't dug around to find them. I thought maybe there was an event object embedded in the device memory containers, used to track any pending writes to them, that could be added to the wait list of subsequent operations. But I don't see anything like this. So, will enabling out-of-order execution will break the higher level operations? Or am I missing something? Matt ________________________________ This e-mail contains privileged and confidential information intended for the use of the addressees named above. If you are not the intended recipient of this e-mail, you are hereby notified that you must not disseminate, copy or take any action in respect of any information contained in it. If you have received this e-mail in error, please notify the sender immediately by e-mail and immediately destroy this e-mail and its attachments.

3 6

[compute] Review period starts today December 15, 2014, ends on December 24, 2014
by Antony Polukhin 31 Dec '14

31 Dec '14

Dear All, Review of the Compute library starts today on Mon 25st of December 2014 and will last for ten days. The Compute library provides a C++ interface to multi-core GPGPU and CPU computing platforms based on OpenCL. The project is hosted on GitHub at https://github.com/kylelutz/compute. Docs are available at http://kylelutz.github.io/compute/ Sources could be downloaded as a ZIP archive via https://github.com/kylelutz/compute/archive/master.zip Some pre-official reviews could be found in Boost Library Incubator: http://rrsd.com/blincubator.com/reviews/?library_id=669 Please, answer the following questions in your review: 1. What is your evaluation of the design? 2. What is your evaluation of the implementation? 3. What is your evaluation of the documentation? 4. What is your evaluation of the potential usefulness of the library? 5. Did you try to use the library? With what compiler? Did you have any problems? 6. How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? 7. Are you knowledgeable about the problem domain? And finally, every review should answer this question: 8. Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. -- Best regards, Antony Polukhin

7 8

[compute] Review comments
by Asbjørn 30 Dec '14

30 Dec '14

Hi, not a proper review, just some comments from a library user based on studying documentation and writing a couple of simple programs using Boost.Compute on Intel's and NVIDIA's OpenCL implementations (i7 CPU and GTX970 GPU respectively). I used MSVC2013 for the tests. Some of these comments I've shared previously on this list, but I'm repeating them here for completeness. I have some background in heterogeneous development and OpenCL in particular, but I'm no expert. I found Boost.Compute easy to pick up and providing a nice C++ layer, with a nice mix of low and high level. Comments in no particular order: 1) As a library user and one who's not a C++ guru by any means, the error messages thrown up when passing incorrect parameters can be quite confusing. For example, first time I tried to use Boost.Compute I managed to not pass the ouput iterator parameter to transform(), so that the lambda expression ended up in that position instead. This resulted in several very confusing errors inside result_of.hpp, with no errors anywhere near my or Boost.Compute source code. It would be nice if the compilation could fail in more informative manners. 2) I did miss async versions of the algorithms, so it's possible to chain together multiple calls. Even though all the data sits on the compute device, the overhead of waiting for each operation to finish before queuing the next can make the compute gains completely irrelevant. 3) I think relevant calls should have a non-throwing form returning an error code, ala Boost.ASIO. 4) Threading has been mentioned in this list. At the very least the documentation should be updated to clearly state the thread safety of each call/class, ala Boost.ASIO. Beyond that I would like to be able to share a context between several threads, each which could contain their own queue and device. 5) If thread safety or similar important features requires a compiled part, I wouldn't mind Boost.Compute being non-header-only. Though if possible making it optional like other Boost libraries do would be great. 6) The tests, and preferably the performance tests as well, should have some way of testing all devices across all platforms. Currently they only test the default device on the default platform it seems. This is insufficient IMHO. 7) I'd like some way of defining user functions either as lambda expressions, raw OpenCL-C code via make_function_from_source or both, which can be used in lambda expressions for say transform(). Something like function<int (int)> sqr = _1 * _1; transform(inp.begin(), inp.end(), out.begin(), sqr(2 * _1 + 1)), queue); Overall I think Boost.Compute can be useful right now for some use-cases, and it has good potential to be significantly more useful with a bit more work. Just my 2 øre. Cheers - Asbjørn

4 5

[filesystem] imbue_utf8
by Peter Dimov 30 Dec '14

30 Dec '14

Since nowadays it's very common for programs to use UTF-8 for path encoding everywhere, I suggest that in addition to path::imbue( loc ), there should be path::imbue_utf8(), which imbues a UTF-8 codecvt facet. Since this is the default on Mac OS X, the implementation is already present, but the user has no way to get to it.

1 0

[config] Macro for detecting thread_local storage support
by Kyle Lutz 30 Dec '14

30 Dec '14

I have looked but been unable to find any macro in Boost.Config for detecting compiler support for the C++11 thread_local storage specifier. Does such functionality exist? I would like to use something like this to automatically detect compiler support for thread_local for use by the proposed Boost.Compute library. Currently I rely on the users defining BOOST_COMPUTE_HAVE_THREAD_LOCAL in order to enable support. Hopefully there is a better way? -kyle

2 1

Re: [boost] [test] boost.test owner unresponsive to persistent problems for multiple years
by Dave Gomboc 30 Dec '14

30 Dec '14

I get the digests, so I'm quoting from a number of different emails on this thread in this message. > > Both contain a fix for this. On stack overflow the proposed fix is > > literally a single line change. > > The issue is addressed in devel branch with somewhat better fix > long long time ago. It is important that tickets be updated to reflect such information. > > If there are issues fixed in develop branch, it would help a lot > > to inform users by updating the tickets accordingly. > > Here is a blanket update message: at this point all the issues with > Boost.Test are fixed on devel branch ;). This doesn't help people who filed a ticket (perhaps years ago) but don't happen to catch this email. > > This has been a problem for about 5 years and these simple fixes don't > > make it into the library. > > This is going to be released as part of the effort of merging devel into > master. Now, when this happens depends only on docs upgrade. It seems that in addition to documentation upgrades/improvements there is at least also the issue of identifying all Boost.Test-related tickets that are currently outstanding, verifying that the issue raised within them is indeed resolved within the development branch (rather than just assuming this is true), and updating the ticket to reflect that the problem has been resolved in the development branch (though it should not be closed yet until a new Boost release comes out with the fix in place). > All in all "devel to master upgrade" is one target I really want to reach > and is what I plan to concentrate my effort on. You are still welcome to > help with this if you are up to it. Excellent! If it has really been five years (or even if it has been only one full year) since this last happened, then may I suggest that this should be your sole target for Boost.Test until this task is accomplished, that your target should be prior to the next major release of Boost, and that obtaining assistance be an important part of your plan to accomplishing this task within this timeframe? To that end, could you please provide for the Boost community a detailed outline of exactly what remains to be done in order for the merge of the latest Boost.Test to master to be completed? Please be clear about exactly what others can help with, and in the cases where you think nobody else can help you, why that is so. Please do so here on the mailing list rather than ask people to contact you privately about it, so that more people will know what remains to be done and may be willing to lend a hand so it can get done. > > 1. What are the reason(s) why-list_content is not (yet) > > added to the release? Is there any schedule for its release? > > I need to document all these new features to release new Boost.Test Can you provide a list of these new features alphabetically by name with a one-sentence description? Boosters can sign up for writing documentation paragraphs, can contribute them here, and you can collect and use them. > > Yes. I fully agree with this statement. I hope to get back to this list > > with more concrete schedule soon. And if you are interested to push this > > even sooner - please feel free to help. > > That's great news. I know a vast amount of work has gone into develop > and we'll all benefit when it finally gets merged into master. Yes, I'm > happy to support this effort as best I can. Feel free to contact me > off-list. Rather than contact people off-list, I urge you to get all of the outstanding work into the open and use this mailing list for co-ordination not only so that people can contribute without overlapping their effort needlessly, but so that the current status is visible to all of us. That last point is rather important: I know of projects that have chosen alternative testing frameworks simply because of the lack of visibility re: Boost.Test. > Thanks for working hard to move this forward. Boost.Test has always been > a critical library and as a result somewhat of a thankless task to > maintain given the constant risk of breakage across Boost as a whole. > Thanks for persevering. I absolutely concur with this. Your efforts are appreciated, Gennady! You've been shouldering the entire burden for too long. I think that by publicly coordinating and leading the remaining effort to get the latest Boost.Test onto master, you'll be able to achieve this goal more quickly. Dave

3 3

[filesystem] Request for help with unresolved tickets
by Beman Dawes 29 Dec '14

29 Dec '14

Boost.Filesystem has roughly 140 unresolved tickets, and far too many are more that a year old. Some are up to four years old. That's horrible, and entirely my fault. I really dislike processing most bug reports, so leave them until I have nothing else to do, which is roughly never. But a few bug reports are actually fun to process. These are the ones that provide a little test program that unambiguously illustrates the problem and includes full information about the compiler, platform, version of boost, etc. To encourage more such dream tickets, I've added a little bug reporting framework with docs to filesystem's develop branch. It depends on a new header (boost/detail/lightweight_test_report.hpp) that's been added to the detail library's develop branch. The hope is that this will lead to more test programs that make it easy to reproduce bugs to (1) speed my processing of tickets and (2) ease handing off tickets to other developers for fixes. There are several ways boosters can help: * Review and try out the instructions at http://boostorg.github.io/filesystem/issue_reporting.html. (Don't expect all links to work.) Were you able to easily follow these instructions? What would you like to see added or removed? * Look through the bugs in https://svn.boost.org/trac/boost/report/53, pick one you think would benefit from a test program, and add a test program as described in http://boostorg.github.io/filesystem/issue_reporting.html. (Do a git pull on develop branch of detail and filesystem libraries first.) Were you able to easily follow these instructions? What would you like to see added or removed? Thanks, --Beman

3 2

[multiprecision] [detail] [number_base.hpp] Ambiguous partial specialization for canonical_imp
by Sergey Sprogis 29 Dec '14

29 Dec '14

It looks like boost/multiprecision/detail/number_base.hpp header in one of the later trunk versions has ambiguous partial specialization problem which Oracle Studio 12.4 C++ compiler detects. It can be also detected by gcc-4.8.2 as small 35 lines independent test case below made from this header shows. gcc -c -std=c++11 t.cc # gcc-4.8.2 compilation t.cc:17:62: error: ambiguous class template instantiation for 'struct canonical_imp<number<cpp_dec_float<50u>, (expression_template_option)1u>, cpp_dec_float<50u>, int_<3> >' CC -c -std=c++11 t.cc # Oracle Studio 12.4 C++ compilation "t.cc", line 17: Error: Ambiguous partial specialization for canonical_imp<Val, Backend, Tag><number<cpp_dec_float<50, int, void>, 1>, cpp_dec_float<50, int, void>, int_<3>>, canonical_imp<Val, Backend, int_<3>> and canonical_imp<number<B, 1>, Backend, Tag>. t.cc ================================== template< bool B> struct enable_if_c{ typedef bool type; }; template< int N > struct int_{}; enum expression_template_option {et_on=1}; template <class Backend, expression_template_option ExpressionTemplates> class number; template <class Val, class Backend, class Tag> struct canonical_imp { typedef int type; }; template <class B,class Backend,class Tag> struct canonical_imp<number<B,et_on>,Backend,Tag> { typedef B type; }; template <class Val, class Backend> struct canonical_imp<Val,Backend,int_<3>>{ typedef Val type; }; template <class Val, class Backend> struct canonical { typedef typename canonical_imp<Val, Backend, int_<3>>::type type; }; template<typename From, typename To> struct is_restricted_conversion { typedef bool type; }; template <class Backend, expression_template_option ExpressionTemplates> class number { public: number() {} template <class V> number(const V& v,typename enable_if_c<!is_restricted_conversion<typename canonical<V,Backend>::type,Backend>::value>::type * =0){} }; template <unsigned Digits10, class ExponentType = int, class Allocator = void> class cpp_dec_float; template <unsigned Digits10, class ExponentType, class Allocator> class cpp_dec_float { public: cpp_dec_float() {} }; template <class RealType> void instantiate(RealType) {} typedef number<cpp_dec_float<50>, et_on> test_type; void foo() { instantiate(test_type()); } =============================== Any suggestions how to fix this? Thanks, Sergey

2 2

[githelp] Pulling to arbitrary branch?
by Rene Rivera 29 Dec '14

29 Dec '14

I have a pull request against one branch (master). But I want to pull it into a different branch (develop). Is that possible? And if so, how? -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

2 5

[filesystem] ISO TS 18822, Technical Specification - File System
by Beman Dawes 29 Dec '14

29 Dec '14

The filesystem TS has been unanimously approved by ISO. 32 countries voted. The document has been forwarded to the ISO Central Secretariat for publication. The current working draft, which is technically the same as the TS but may have editorial corrections, is available at http://cplusplus.github.io/filesystem-ts/working-draft.html Many thanks to all the Boost folks who contributed so much to the Boost library that became the ISO TS! The C++ standards committee Filesystem Study Group will continue to operate, and will issue further TSes as further proposals dictate, and will continue to publish a working paper as issues for the TS are corrected. Happy Boost New Year, --Beman

1 0