- Boost - lists.preview.boost.org

GSoC: Student application deadline in less than 24 hours
by Boris Schaeling 02 May '13

02 May '13

Students interested in applying for a GSoC project should submit their application as soon as possible. The deadline is in less than 24 hours. Click here to apply: <https://google-melange.appspot.com/gsoc/homepage/google/gsoc2013> Boris

1 0

[gsoc-2013] Boost.Expected
by Pierre T. 02 May '13

02 May '13

Hello, My name is Pierre Talbot, I participated to GSoC 2011 and began the implementation of the Boost.Check library (for checking the validity of any number having a check digit — credit card number, ISBN, …). It was two years ago and the design is still evolving due to many variation points in the code. One of the function looks like : template <typename check_algo, typename range> boost::optional<typename check_algo::checkdigit_type> compute_checkdigit(const range &x); Using boost::optional tell us that: "A check digit should be computed if 'x' is a valid sequence". Since 'x' has many reasons to be incorrect, many errors could be raised. Based on a policy template class, it launches exception or returns with an empty optional . Then I though a lot about a better way to do it, allowing the user to get an exception or an error code. But it was quite complex for a so little part of my library… I decided that the policy "throw exception or nothing" should be enough. Yesterday, I watched the video of Mr. Alexandrescu on Boost.Expected and I think it would be a very useful library. It could mainly be useful in system programming (where many error codes can arise from a single call), but in any code where many exception errors can be thrown (like in Boost.Check). As you suspected, I'm interested in coding Boost.Expected during the summer as a GSoC student. Firstly, it could be very useful to list the resources on the subject (aside the talk), I have several articles that I will talk about later. Secondly, and hoping you'll debate, I would like to ask your opinion about several ideas and facts: 1) In the Boost project description, we can read: "adding a class expected-or-error_code". Obviously, the main design decision made by Alexandrescu is to consider that error code are exception. Do we need an abstraction of exception/error code ? Why do you think a "expected-or-error_code" class is interesting ? 2) Consider this code (from Alexandrescu slides) : // Caller string s = readline(); auto x = parseInt(s).get(); // throw on error auto y = parseInt(s); // won’t throw if (!y.valid()) { // handle locally if (y.hasException<std::invalid_argument>()) { // ------------------ < The flagged line. // no digits ... } y.get(); // just "re"throw } The flagged line has some tastes of "return to the past" flavor. Back to the C procedural language, the basic error code handling system was a lot criticized because: * Readability of the code decrease ; * Error handling occurs in the middle of the execution flow ; * <Add your favourite reason here>. Several links on the subjects (if you have others, I'm interested) http://www.joelonsoftware.com/articles/Wrong.html http://www.joelonsoftware.com/items/2003/10/13.html http://blogs.msdn.com/b/oldnewthing/archive/2005/01/14/352949.aspx http://nedbatchelder.com/text/exceptions-vs-status.html Basically, only the last one is clearly for exception. The main argument against the procedural approach is the readability. I would say that the Expected approach just differ by allowing to rethrow exception. But if you want to handle it, you must code multiple if-than-else statements. So I considered a complementary approach working with Expected to handle multiple error cases: string visa_number = readline(); expected<char> expected_checkdigit = compute_checkdigit<visa>(visa_number); if(expected_checkdigit.valid(visa_error_resolver)) { visa_number += expected_checkdigit.get(); std::cout << visa_number << std::endl; } With this code, there is only a if statement, and no more multiple error cases handles. But what is this error_resolver ? It may be declared as : // Somewhere in visa.hpp. A type list. typedef error_list<size_error_exception, unknown_character_exception, checkdigit_encoding_exception, …> visa_errors; // Somewhere in the user code. error_resolver<visa_errors, expected_type> visa_error_resolver; // in this case, expected_type is a char. // Initialize error handler on specific exception/errors. visa_error_resolver.on<size_error_exception>(size_error_handler) .on<unknown_character_exception>(unknown_character_exception) ... Now we are agree that visa_error_resolver can be reused everywhere we want to resolve an error on a visa number. What are the handlers ? There are [Function|Functor|Lambda] (pick up your favourite) with this form : expected<ExpectedType> size_error_handler(const size_error_exception&) expected<ExpectedType> unknown_character_exception(const unknown_character_exception&) Now you can understand for what the type list "error_list" stands for, we can store these handlers into the error_resolver and call them without any virtual cost. Why the return type of error handler is expected<ExpectedType> ? Consider this size_error_handler code : expected<ReturnType> size_error_handler(const size_error_exception& e) { std::cout << "The number you gave has a bad size." << std::endl; std::cout << "Enter it again : " << std::endl; return read_visa_checkdigit(); } read_visa_checkdigit can call recursively valid() until it's valid. Though there are some ways to make this treatment iterative. A basic treatment could be to print an warning message and just returns (in this case, valid returns false): expected<ReturnType> size_error_handler(const size_error_exception& e) { std::cout << "Warning: the VISA field is incorrect." << std::endl; return expected<ReturnType>::fromException(e); } Results: * The error code handling is delegated to specific functions ; * The readability is still excellent ; * You can easily re-use your error handler function ; * If you don't like it, you can still throw exception on failure with "get()". I can code a "proof of concept" if you think this is a good idea. Do not hesitate to comment it, point out programming pitfalls, request further clarification, or anything you judge useful. Thank you for reading it ! Pierre Talbot

10 63

Re: [boost] [gsoc-2013] Boost.Thread/ThreadPool project
by Niall Douglas 02 May '13

02 May '13

> > I have just read N3388 - Using Asio with C++11 and a think I start to > > understand the ASIO design. > > Could we say the completion handlers are continuations? > > And that the user use to master which thread executes the continuation by > > calling the io_service::run() function? > > Pretty much, except that multiple threads can call io_service::run > concurrently. Basically Boost.Asio is a work sharing queue plus a > collection of waitqueues to wait for specific events. Far clearer than my explanation. Thanks. > That's orthogonal. Boost.Asio provides the funding blocks. A nicer > interface that doesn't require an explicit continuation passing style > transformation can be built with Boost.Context or a similar library. > But it probably needs a future implementation that integrates with > ASIO, which is one of the point of Niall Douglas. Spot on. Especially as parts of ASIO are due to enter with TR2. I worry that a thread pool designed without ASIO in mind would become an orphan isolate. Niall --- Opinions expressed here are my own and do not necessarily represent those of BlackBerry Inc.

2 1

[testing] run.py and cross compilation
by Antony Polukhin 02 May '13

02 May '13

Hi, Is there some possibility to compile sources on one platform (x86) and then run compiled tests on other platform (ARM/Android) using run.py script? This is required, because Android SDK exists only for x86 so there is no way to compile tests on ARM Android device. -- Best regards, Antony Polukhin

2 3

[GSoC2013] My updated proposal to the XML library project
by Amos Ji 02 May '13

02 May '13

Hi, I have updated my proposal to the XML library project. If you're interested in it, you can review it at http://www.google-melange.com/gsoc/proposal/review/google/gsoc2013/amosji/3… And there is also a pdf version: https://www.dropbox.com/s/3zgxkpb9bx45auo/Boost_XML_library.pdf Any comments are appreciated. Thanks a lot. Regards, Mingchao

1 0

[reference_wrapper] Overloading operator() in reference_wrapper
by Nathan Crookston 02 May '13

02 May '13

Hi all, std::reference_wrapper includes an overload of operator()[1] which allows a wrapped function object to be called without needing to first unwrap: #include <boost/ref.hpp> #include <functional> #include <iostream> int main() { auto f = [](int i) { std::cout << i * 2 << std::endl; }; std::ref(f)(5);//change this to boost::ref and it will not compile. } I think it would be valuable to update boost::ref to match the standard version. On compilers which support variadic templates and rvalue references the code is obvious. Those which support one or neither could still have overloads for some number of arguments. This would be handy in a few places, notably boost::gil::for_each_pixel[2]. I know that boost::bind + reference wrapper could be used instead (boost::bind(boost::ref(f), 5)). Given that implementing operator() is relatively simple, and that the standard object based on boost::reference_wrapper has it (rather than requiring std::bind), I'd argue that this change is desirable. Thanks, Nate [1] http://en.cppreference.com/w/cpp/utility/functional/reference_wrapper/opera… [2]http://comments.gmane.org/gmane.comp.lang.c%2B%2B.isocpp.general/513

6 9

Re: [boost] [gsoc-2013] Boost.Thread/ThreadPool project
by Niall Douglas 02 May '13

02 May '13

> Le 01/05/13 20:39, Niall Douglas a ?crit : > >> I don't see the term "central asynchronous dispatcher" used in any of > >> the links. Could you clarify what it is? > > I have to admit I'm struggling to see where your block is, but Dave Abrahams > > often found the same with me, so it must be me. > It is just that I don't know the term. > As I don't know the domain (the words) you are talking about we can stop > the exchange here if you prefer, or you could continue to explaining me > the things I don't know/understand. Don't worry, it's almost certainly me as native English speakers rarely understand me either. Besides when I lived in Spain I remember only too well the problem with domain terminology, like when a dentist told me I had a "del gasto" which I took to him wanting money because he had high rent :). I'll keep going as long as you need. We'll get there eventually. > > The central means one execution context does the dispatch. The asynchronous > > means that callbacks are processed by recipients asynchronous to the > > dispatcher. And dispatcher, well that dispatches. > In order to be sure I understand what you say could you tell me how a > decentralized asynchronous dispatcher behaves? What are the differences? A centralized dispatcher dispatches from one execution context to many. A decentralized dispatcher dispatches from many execution contexts to one or more contexts. An example of the latter is cloud apps actually, where millions of apps will dispatch events to a load balanced core cluster of servers i.e. many => few. By execution context I mean a thread, a fibre, a coroutine, a handler or even a closure. Generally if it's got its own distinct stack separate from other stacks, it's an execution context. > > I'd take a reasonable guess that MCAS will benefit centralized kernel-based > > threading primitives architectures such as Windows NT more than > > decentralized threading primitive architectures such as POSIX. That said, I > > could see Linux using TM for batch multi-kernel-futex ops, though I'd have > > to say implementing that without breakage would be daunting. > > > Are you saying that current TM technology should be much more useful for > centralized than decentralized asynchronous dispatchers? I'm saying my suspicion is that. Others on SG5 may disagree (they disagree with me about most of my opinions). It's still very early days for TM in C++. > Does this means that the whole application would improve its > performances using always centralized asynchronous dispatchers? I'm saying it's a likely optimization case. Other than a recompile, application need not know the difference. > > You may find N3562 Executors and schedulers coproposed March 2013 for > > Bristol by Google and Microsoft of use to you in understanding the relation > > between thread pools and Boost.ASIO > > (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3562.pdf) > I know this proposal. Could you explain me how it is related to > Boost.Asio? Could you point me where in the Asio documentation could I > find related information? I think your other post is more relevant, so I'll answer there. But agreed that Asio's documentation assumes the user already understands how it works. If you come from a NT kernel or VMS or libuv programming background, it's obvious. But much less so for everyone else. > > My > > proposed Boost.AFIO library is an implementation of that same N3562 idea, > > albeit I extend Boost.ASIO which is IMHO more C++-y whereas Google and > > Microsoft have gone with proprietary implementations. Also, they include > > timing and many other more general purpose features, and mine does not > > (currently) as it's mainly aimed at maximising input/ouput with highly > > jittery random latency storage. > > > Thanks Niall for all the explanations and sorry if all this is trivial > for you. These types of discussion always add to the collective good. Niall --- Opinions expressed here are my own and do not necessarily represent those of BlackBerry Inc.

1 0

[testing] run.py and cross compilation
by Niall Douglas 02 May '13

02 May '13

> Is there some possibility to compile sources on one platform (x86) and > then run compiled tests on other platform (ARM/Android) using run.py > script? > > This is required, because Android SDK exists only for x86 so there is > no way to compile tests on ARM Android device. I believe we have a related or similar problem with unit testing Boost on BB10. Niall --- Opinions expressed here are my own and do not necessarily represent those of BlackBerry Inc.

1 0

[gsoc2013] Proposal for Boost.Math Bernoulli numbers and special functions project
by Artemy Margaritov 02 May '13

02 May '13

Hi folks! I want to provide my proposal for Boost.Math Bernoulli numbers and special functions poject to the Boost community. Please, lets discuss it! I will be grateful for your advices. -- Best regards, Artemy Margaritov

2 6

Re: [boost] [gsoc-13][proposal] Boost.uBLAS
by Aditya Avinash 02 May '13

02 May '13

On Thu, May 2, 2013 at 1:24 AM, Aditya Avinash <adityaavinash143(a)gmail.com>wrote: > I have updated the proposal. Here it is. > > > On Thu, May 2, 2013 at 1:21 AM, Aditya Avinash <adityaavinash143(a)gmail.com > > wrote: > >> Hi, this is my GSOC 13 proposal on Boost uBLAS. >> >> >> On Wed, May 1, 2013 at 3:15 PM, David Bellot <david.bellot(a)gmail.com>wrote: >> >>> Great. I'm looking forward to it. >>> >>> Best, >>> David >>> >>> >>> On Tue, Apr 30, 2013 at 11:06 PM, Aditya Avinash < >>> adityaavinash143(a)gmail.com >>> > wrote: >>> >>> > I'll upload in 16 hrs. >>> > >>> > On Wed, May 1, 2013 at 2:55 AM, David Bellot <david.bellot(a)gmail.com> >>> > wrote: >>> > >>> > > Hi Aditya, >>> > > >>> > > yes, please send me a written proposal, so that I can help you on >>> that. >>> > > It's definitively something we want to do for ublas. >>> > > >>> > > Best, >>> > > David >>> > > >>> > > >>> > > On Mon, Apr 29, 2013 at 6:56 PM, Aditya Avinash >>> > > <adityaavinash143(a)gmail.com>wrote: >>> > > >>> > > > Hi, I have a proposal for boost in gsoc-13 under boost.ublas >>> > > > >>> > > > *Proposal: SIMD abstraction for uBlas.* >>> > > > >>> > > > >>> > > > - I want to develop SIMD abstraction for uBlas. >>> > > > >>> > > > >>> > > > Goal 1: Develop the Intel SSE & AVX backend for SIMD abstraction in >>> > > uBLAS. >>> > > > >>> > > > Goal 2: Develop AMD SSE backend for SIMD abstraction in uBLAS. >>> > > > >>> > > > Goal 3: Develop frontend for SIMD abstraction in C++. >>> > > > >>> > > > Goal 4: Joining of frontend and backend, so the the code is >>> flexible to >>> > > > implement on both AMD and INTEL. >>> > > > >>> > > > Goal 5: Develop the ARM-NEON backend for SIMD abstraction in >>> uBLAS. >>> > (if >>> > > > time permits). >>> > > > >>> > > > -- >>> > > > ---------------- >>> > > > Atluri Aditya Avinash, >>> > > > India. >>> > > > >>> > > > _______________________________________________ >>> > > > Unsubscribe & other changes: >>> > > > http://lists.boost.org/mailman/listinfo.cgi/boost >>> > > > >>> > > >>> > > _______________________________________________ >>> > > Unsubscribe & other changes: >>> > > http://lists.boost.org/mailman/listinfo.cgi/boost >>> > > >>> > >>> > >>> > >>> > -- >>> > ---------------- >>> > Atluri Aditya Avinash, >>> > India. >>> > >>> > _______________________________________________ >>> > Unsubscribe & other changes: >>> > http://lists.boost.org/mailman/listinfo.cgi/boost >>> > >>> >>> _______________________________________________ >>> Unsubscribe & other changes: >>> http://lists.boost.org/mailman/listinfo.cgi/boost >>> >> >> >> >> -- >> ---------------- >> Atluri Aditya Avinash, >> India. >> > > > > -- > ---------------- > Atluri Aditya Avinash, > India. > -- ---------------- Atluri Aditya Avinash, India.

1 0