January 2015 - Boost - lists.boost.org

Re: [boost] [compute]/ Futures Some remarks
by Antonio Colino 15 Jan '15

15 Jan '15

I have a flawless implementation of this concept I am very proud of. Is any one willing to critique it?

2 1

Re: [boost] boost interval arithmetic
by Marc Glisse 15 Jan '15

15 Jan '15

(please keep the conversation on the list) On Wed, 14 Jan 2015, Павел Кудан wrote: > Dear Marc, > > Thank you for your answer, I also tried to contact Mr.Gubenko, have no information about other maintainers. Please, excuse my bad English, I will try to explain in more detail, please, ask if something will be uncertain. I thought the maintainers would be the 3 authors. > Boost interval library was planned as extension of mathematical functions on float/double/double long or other singe numeric values to operations on intervals. The problem is that intervals have some specific. For example, if float value can be either > either < or = some other float value (statement ! (a>b) == (a <= b) is always true), for intervals it is not correct. Intervals can also overlap. That means that it is not possible for pair of overlapping intervals to say certainly which of them are greater than other. It is the intermediate situation, which is impossible with original single float values. > > And boost interval class has comparison operators and user can expect that they will behave in similar way with usual float comparison operators. > > For that reason, the behaviour of that comparison operators was made changeable and depends on some kind of policy, defined by user. Default behaviour is to throw exception when such intermediate situation (not possible for single float values) takes place. > > That was very wise solution, especially useful in very probable case, when some programmer will try to adapt some existing code with float calculation just changing type of value to boost interval. He will get exception in than exceptional situation - when usual float comparison operator is not applicable any more. > > That is OK. > > > > But as well boost interval class defines mathematical functions and operators. And user can expect that they also will behave similarly to usual float comparison operators. But great disappointment and multiple possible errors which is hard to locate is waiting for him here. Because it is not so. Arithmetic operators behave in completely different manner. > > Let's look on of most basic operator =/ and see what it is doing. > > But before let's see what is division of intervals and what is it's result. > > Boost interval class has two function - division_part1() and division_part2(). It is correct as when you divide one interval with another, the result will be single interval or a pair of intervals. The last situation takes place when in statement A / B, interval B cross a zero. That is not normal for intervals to have a pair of intervals as a result of division, but it is exceptional for single float numeric division. > > Now let's get back to /= operator and watch what he will do in such case. > > Let A = [1,2] and B = [-1, 1] > > and let's see what we will get after A /= B and what we should get. > > The true result of division in that case will be a union of pair of intervals [-infinity, -1] and [2, -infinity] Actually, [-inf,-1][1,+inf] > Interval /= operator, naturally, must return one interval. It is, obviously, impossible in this case - to return one of two. Again intermediate situation, not applicable to single float calculations. Again, throwing exception must be a result to let user know that he does not know what he are really doing. The same behaviour, as comparison operators. But it is not so. > > Instead of such natural behaviour, /= operator of boost interval class are doing impossible thing. It silently decides for itself which one of two parts of whole result to return and kill another part of whole solution somewhere under the scene. > > The result of A /= B will be [-infinity, -1]. Not correct result - as it is not complete. One of to parts is missing. Did you really observe that? If so, it is a bug. [1,2]/[-1,1] is supposed to give [-inf,inf] (and it does indeed, in my tests), which certainly contains the right value ;-) If you have a testcase that shows differently, it would be good to open a bug report on trac. > Very very bad operator behaviour. User get not correct result and even does not know that it is so. It will be hard to find when this error is located, and when it will be done, library user will not think that he should know better what he are doing and learn some basics of interval arithmetic - no, he will accuse boost interval as part and boost as whole for bugs in libraries implementation. U nfairly , of course, but who cares. > > > > To correct it, at least, arithmetic operators and functions of interval class must behave similarly to comparison operators - throw exception in situations, not applicable for single float calculations. > > That is what I meant when said: "The difference in behaviour of comparison operators and basic arithmetic operators looks as probable misconception." > > > > I know, it is hard to understand, especially because bad English, but I hope it is important and hope it will help. -- Marc Glisse

2 2

Re: [boost] Futures (was: Re: [compute] Some remarks)
by Antonio Colino 14 Jan '15

14 Jan '15

Concerning std::futures and promises, my thought is wrapping an immutable state in a task, nither future or promise, but with elements of both. Creating a mutex from an asm lock cmpxchg wrapped in c ( available most platforms ) to a shared_ptr gives you a copyable mutex. Not that it matters, but if the state manager ensures a swap every time the arguments are updated, and the state has a ref count destructor, a value storage, function/lambda/member func/functor storage, the effect is an immutable state. once the args are set nothing can change but the execute function or function brackets, a flag in the state ensures that the func will only execute once ( all flags set by single asm instruction xchg, wrapped in c ). this task , or promise if you like, is now copyable, and doesn't require an allocator as the internal state is set by setting the arguments and the state ptr and can be created then. Every time the task/ promise gets copied the shell only exists to point to the state. Having a generic function that wraps any func call in a std::function<void()> using a lambda , works nicely for a basic way to fill a queue generically. In the end you only have two exposed objects. A task and a scheduler. No mutexes, futures, promises, or any locking mechanisms of any kind. The task implementation I'm speaking of also accepts lambdas, and can reset there arguments. The thought is creating the shell (task , promise, whatever) once. Then setting the arguments many times. Each time it would internally create a new state, the user still has to take care of the memory, less the ref count get to zero, but a simple vector does nicely. Since it is all wrapped in the copyable task/promise, it is transparent to the user. So... task(any function in with or without args), task.set_args, scheduler.queTask, and go. The scheduler is just a thread grouping dictated by the user or by the hardware concurrency as a default. The result can be retrieved directly through the task or it can create a future as well or fill an existing one with the original future ref in the state. Don't really need it but... if it must be future/promise. Biggest problem i had was dealing with the lambda and functor case intuitively and cross platform. Functions and member functions were a snap.

1 0

PDF versions of Quickbook generated documentation - Do you like the serif font?
by Paul A. Bristow 14 Jan '15

14 Jan '15

I've noted that for documentation using the Quickbook toolchain, we use a serif font (Times Roman?) for the PDF, but a sans serif for the equivalent HTML version. Is there a reason for this? Should they not be the same font? (So that they look the same?) Which do we prefer? Should we change either or both? Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830

2 2

BOOST_ASIO_SEPARATE_COMPILATION linker error
by Arun.Ramasamy＠high5games.com 14 Jan '15

14 Jan '15

HI, I'm trying to build boost 1.47's asio library with the BOOST_ASIO_SEPARATE_COMPILATION macro in windows 7, 32-bit, VS 2010. With this macro, the asio library can be included and built easily without building all of boost or using bjam. However, I get the following linker error: unresolved external symbol "class boost::system::error_category const & __cdecl boost::system::system_category(void)" (?system_category@system@boost@@YAABVerror_category@12@XZ) referenced in function "public: __thiscall boost::system::error_code::error_code(void)" (??0error_code@system@boost@@QAE@XZ) unresolved external symbol "class boost::system::error_category const & __cdecl boost::system::generic_category(void)" (?generic_category@system@boost@@YAABVerror_category@12@XZ) referenced in function "void __cdecl boost::system::`dynamic initializer for 'posix_category''(void)" (??__Eposix_category@system@boost@@YAXXZ) 1> Basically the functions boost::system::system_category and boost::system::generic_category aren't defined anywhere. I can't find the implementation of these functions in boost source when I tried grepping it. Should I just use bjam to build the asio library. Thanks arun

3 2

Re: [boost] [build] Test marked as compile-fail is now reported as a failure.
by Adam Wulkiewicz 13 Jan '15

13 Jan '15

Hi Vladimir 2015-01-12 7:26 GMT+01:00 Vladimir Prus <vladimir(a)codesourcery.com>: > > Hi Adam, > > On 01/11/2015 10:38 PM, Adam Wulkiewicz wrote: > >> Hi, >> >> Since yesterday one test marked as compile-fail is now reported as a >> failure on the regression tests page. >> >> It's the test: rtree_values_invalid >> on the page: http://www.boost.org/development/tests/develop/ >> developer/geometry-index.html >> >> Surprisingly other tests aren't. >> see e.g.: geographic_custom_point_with_wrong_units >> on the page: http://www.boost.org/development/tests/develop/ >> developer/geometry.html >> > > Why is it surprising that test A fails while test B does not? Are these > exactly identical > tests? > They're both expected to fail to compile. > > They seem to be defined the same way in the Jamfile: >> https://github.com/boostorg/geometry/blob/develop/index/ >> test/rtree/Jamfile.v2 >> https://github.com/boostorg/geometry/blob/develop/test/ >> point_concept/Jamfile.v2 >> > > Could it be that the problem with the actual tested functionality. > AFAIU no because the test is reported as a fail only if it's expected to compile/link/run but it fails to compile/link/run. If the situation is the opposite (expected to fail but doesn't fail) the test is reported as a pass (with dark green background). Otherwise the test should be reported as a "regular" pass. > > AFAIS the oldest run when it failed was of the runner: >> teeks99-03c-Ubuntu12.04-64 on Sat, 10 Jan 2015 02:05:44. >> On Fri, 09 Jan 2015 18:36:55 (teeks99-08b-win2012R2-64on64) everything >> was ok. >> >> Furthermore when run locally it's also reported as a failure. Some time >> ago of course "(failed-as-expected)" message was printed instead. >> Do you have any idea what may be wrong? >> > > Looking at > > http://www.boost.org/development/tests/develop/ > developer/output/BP%20x86_64%20C++11-boost-bin-v2-libs- > geometry-index-test-rtree- rtree_values_invalid-test- > clang-linux-3-5~c14_libc++-debug-debug-symbols-off.html > > It does look indeed that complication is successfull, while it should fail > for the test to pass. If by successful you mean "the compiler output is present" then indeed it isn't. However it's not always the case, see: http://www.boost.org/development/tests/develop/developer/output/BP%20x86_64… http://www.boost.org/development/tests/develop/developer/output/trippels_gc… Though I can't see any error message there, only warnings. But this is not the first time I see something like this on the regression tests page. However the message about trimming of the output is displayed only for the first of the tests mentioned above. > Locally for me, with gcc, the > compilation fails, and the test is deemed passing, so I can't see any > Boost.Build malfunction here. > Yes, the cause may be located elsewhere, in Geometry, Regression, Test, etc. For a clean run I'm now unable to build the tests due to some undefined references but the problem is most likely located elsewhere. > Am I missing something? Or am I? Regards, Adam

3 6

Re: [boost] [Boost-testing] Linux regression test runners - What do devs want?
by Blower, Melanie 13 Jan '15

13 Jan '15

Niklas, How do you compare the results of running the same compiler on Linux and QNX? Do you just eyeball the report on the website, or do you use a script to compare the test results on the filesystem? Thanks and regards, Melanie -----Original Message----- From: Boost-Testing [mailto:boost-testing-bounces@lists.boost.org] On Behalf Of Niklas Angare Sent: Tuesday, January 13, 2015 7:09 AM To: boost-testing(a)lists.boost.org Cc: boost(a)lists.boost.org Subject: Re: [Boost-testing] Linux regression test runners - What do devs want? "Tom Kent" <lists(a)teeks99.com> wrote: > Instead of running lots of different versions, I was thinking about > running various compatibility options of the two main compilers...I've > seen some other test runners with things like libc++, c++11, c++14, > etc. My real question, would developers be better served by these > options than different versions? Would they prefer both with longer > revisit times between each test type? Other thoughts? My runners use gcc 4.4(.2) (in gnu++0x mode) on QNX, and it's useful to be able to compare to the same compiler running on Linux. I'm sure it's the same for other non-Linux environments such as MinGW. Currently there are other runners that match my compiler configuration better than yours do, but you get the idea. Regards, Niklas Angare _______________________________________________ Boost-Testing mailing list Boost-Testing(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-testing

1 0

TravisCI and Coveralls integration instructions
by Antony Polukhin 12 Jan '15

12 Jan '15

Hi all, The following step by step instruction https://svn.boost.org/trac/boost/wiki/TravisCoverals may be useful for those of you who want to: * make sure that tests cover all the code lines * make the README.md more colorful and useful * use additional testing infrastructure Here are some examples of how the results looks like: * https://github.com/boostorg/variant#test-results * https://github.com/boostorg/type_index#test-results P.S.: Shall I add this tutorial to "Guidelines" or to the "Infrastructure" section of the Wiki? -- Best regards, Antony Polukhin

2 1

[boost.fiber] regarding to migration of fibers between threads?!
by Oliver Kowalke 12 Jan '15

12 Jan '15

Hello, boost.fiber was reviewed in January 2014 and now I've finished the requested changes. Unfortunately the migration of fibers between threads is not stable yet, but synchronizing fibers running in different threads works. I'd like to know if fiber migration is absolute necessary to pass the next review or might it be acceptable to finish this feature later. so long, Oliver

2 1

[mixin] Library name
by Matus Chochlik 12 Jan '15

12 Jan '15

On Mon, Jan 12, 2015 at 1:32 PM, Klaim - Joël Lamotte <mjklaim(a)gmail.com> wrote: > On Mon, Jan 12, 2015 at 1:21 PM, Borislav Stanimirov <b.stanimirov(a)abv.bg> > wrote: > > > > > * EntityComponent - not great since it doesn't exactly follow the > > entity-component-system pattern, although it can be said that it allows > the > > construction of entities from components. > > > > > As long as you consider that it is not implementing the ECS pattern, it > shouldn't use this name indeed. > > +1 If the `Mixin` name is 'bad' because it is used to describe something different in C++ then `EntityComponent` is 'bad' for the same reason

1 0