- Boost - lists.preview.boost.org

[Spirit] real_policies<> and 1.0#NAN
by Pete Bartlett 08 Jun '16

08 Jun '16

Hi, Boost.Spirit is not sure of itself when it comes to parsing representations of infs and nans such as “1.0#NAN”. The docs [1] for the default real_policies<T> for parsing numbers say: “[…] with the additional detection of NaN and Inf as mandated by the C99 Standard and proposed for inclusion into the C++0x Standard: nan, nan(...), inf and infinity (the matching is case-insensitive). This corresponds to the following grammar:” The first sentence suggests that 1.0#NAN etc will not be parsed. But the grammar itself then says: <quote> nan = -lit("1.0#") >> no_case["nan"] >> -('(' >> *(char_ - ')') >> ')') ; inf = no_case[lit("inf") >> -lit("inity")] ; </quote> suggesting that "#1.0NAN" is intended to parsed, but "#1.0INF" is not! Then the in-code docs [2] however suggest that both "1.0#NAN" and "1.0#INF" are intended to be parsed: <quote> // The second call allows to recognize representation formats starting // with a 1.0 (such as 1.0#NAN or 1.0#INF etc.). </quote> However, the actual code fails to parse either of these these. This is because in [3] the presence of the "0" causes frac_digits to be non-zero and so the "traits::is_equal_to_one(..)" condition is never tested. In the case "1.#NAN" (without a zero) frac_digits is zero so the condition is tested and we enter the traits::parse_nan code, but now the text parsed to this sub-parser is "#NAN" and the parser does not cater for the initial "#". Could the maintainers state which behaviour is intended...hopefully I may be able to supply a patch to docs/code/tests knowing that. Regards, Pete [1] http://www.boost.org/doc/libs/1_61_0/libs/spirit/doc/html/spirit/qi/referen… [2] <boost/spirit/home/qi/numeric/real_policies.hpp> [3]<boost/spirit/home/qi/numeric/detail/real_impl.hpp>

2 1

RFC : About forking a C++11 standard library and adapt it to C++98 compilers
by Vicente J. Botet Escriba 07 Jun '16

07 Jun '16

Hi, Some of us have to work yet with C++98 compiler at work (due to well know reasons) and this for a long time. This is a reality. I was wondering about forking a public domain C++11/14/17 standard library and adapt it to C++98 compilers. This library could be seen as another TR1, an extension of the C++03 standard library. Does this make any sens? Would this project be of interest for the Boost/C++ community? I have not a clear idea of the cost of doing this work, how it should be done, what would be the limitations, ... but I'm sure that this would be quite useful on the projects that are forced to use C++98 and an excellent bridge to those that will move from C++98 to C++11 compilers. There are some Boost libraries that could be used to reduce the limitations, as Boost.Config/Predef, Boost.Move, ...and others that could be used as inspiration on how to implement them using C++98. Anyway, if you find that this will be useful to you at your work we will need your participation. Would you be interested in working on it? as a Boost community project? outside Boost, as an independent project? Comments and suggestion welcome. Best, Vicente P.S. The same can be done for C++14 standard libraries and the future standard C++17 libraries P.S.S. The same can be done for C++14 libraries and the future C++17 libraries but this time adapting to C++11 compilers (this will be much easier but the concerned community will be quite different ).

5 7

Make libs/maintainers.txt a template file
by Daniel James 07 Jun '16

07 Jun '16

Hi, If you haven't noticed, on develop libs/libraries.htm is now a template which gets filled in as part of the documentation build. You can see the template and generated files at: https://github.com/boostorg/boost/blob/develop/libs/libraries.htm http://www.boost.org/doc/libs/develop/libs/libraries.htm This will be merged to master pretty soon. The only obstacle is updating the website automatically from the latest build, which should be happening very soon. The file libs/maintainers.txt is also automatically updated, but that's done in the repo itself, so that you have the full copy in you normal checkout. But I'm finding that people don't realise this, and we've had a few pull requests to update it manually. So instead, I think it might be a good idea to convert it to a template as well. This means you won't have a local copy, but will still be able to see a reasonably up to date copy online at: http://www.boost.org/doc/libs/develop/libs/maintainers.txt Any objections? I'm think of using similar templates for some other files, such as the root index.html (for the version number and new libraries). thanks, Daniel

2 2

Cxx dual library
by Edward Diener 06 Jun '16

06 Jun '16

I have finished all the main work on the Cxx dual library at https://github.com/eldiener/cxx_dual. The library is also in the Boost Library Incubator at http://rrsd.com/blincubator.com/bi_library/cxx_dual-2/?gform_post_id=1597. The Cxx dual library, or CXXD for short, is a C++ macro header-only library which chooses between using a Boost library or its C++ standard equivalent library for a number of different C++ implementations, while using the same code to program either choice. An 'implementation' is a Boost library which has a C++ standard library equivalent whose public interfaces are nearly the same in both cases. An 'implementation' is called a 'dual library' in this documentation, or 'CXXD-mod' for short. The library does this by defining object-like macros for including the appropriate header file and namespace or using either the Boost library version or the C++ standard library version of a particular dual library. CXXD currently supports twenty eight different dual libraries, where the Boost version and the C++ standard version is nearly interchangeable in some respects. CXXD also provides a macro-based solution for distinguishing between the Boost version and the C++ standard version of a dual library so that specific code for a particular dual library choice may be written in those cases where the public interfaces diverge. The library came out of my initial PR to add such a feature to Boost.Config, and then I decided to create a separate library and expand on the functionality. The gist of the library is to write a single set of code for a particular implementation and have it work whether or not that code targets a Boost implementation or its C++ standard equivalent. The default algorithm will choose the C++ standard implementation if it is available, otherwise it chooses the Boost implementation. The default can be overriden for any of the 28 different implementations which CXXD supports. With all the talk about supporting C++11 or C++14 in new code, the library offers a way of supporting C++11 or C++14 standard libraries if available whether one writes in C++03 dialect or uses the new language features of C++11 on up. The Cxx dual library itself, being macro based, should work with any C++ code at that code's language level. The library itself is NOT, repeat NOT, an attempt to enforce a C++ language level for anybody who wants to use it. I have a little more work I am doing on increasing the support for Boost Build in the library, but all the central implementation of the library is complete in my mind. Questions, comments, or bug reports are always welcome, either here in this mailing list, in the Boost Library Incubator, or as Github issues, by those who are interested in trying the library out or reading the documentation. I will be using CXXD in another library on which I am working but hopefully others will find a use for it in their own code.

5 30

[exception] Broken in master?
by John Maddock 06 Jun '16

06 Jun '16

Anything that includes Boost.Exception is currently broken on master for all compilers, for example: http://www.boost.org/development/tests/master/developer/output/teeks99-09j-… http://www.boost.org/development/tests/master/developer/output/Flast-FreeBS… The cause is the use of a partial-template specialization in info.hpp with no previous definition of class set_info_rv. Thanks, John.

2 1

Boost.Fiber mini-review May 23 - June 1: review report
by Nat Goodspeed 05 Jun '16

05 Jun '16

The Boost.Fiber mini-review is now closed. Results: Bjorn Reese: YES Niall Douglas (private): YES Agustín K-ballo Bergé: YES Niall Douglas reminds me that in a previous mini-review he already voted to accept the Fiber library. Unless he stated that he had changed his mind, it would be reasonable to carry forward that "yes" vote. However, he did reaffirm his previous stance. In that spirit, let me remind the community of another couple previous positive votes: Eugene Yakubovich Antony Polukhin Significantly, there were no remaining NO votes. I therefore conclude that the Boost community ACCEPTS the Fiber library into the Boost family of libraries. On behalf of the Boost community, I would like to congratulate Oliver Kowalke not only for his engineering work, but for considerable patience in working to improve the library and its documentation. Thank you, Oliver!

3 2

Re: [boost] Checking interest in std::get for PODs
by Bjorn Reese 04 Jun '16

04 Jun '16

On 06/03/2016 08:27 AM, Antony Polukhin wrote: > There's a C++14 library that is able to do basic reflections for PODs > without any macro magic or markup: https://github.com/apolukhin/magic_get Could the "Enums will be returned as their underlying type" limitation be partially worked around by allowing users to register their own enums?

3 2

Checking interest in std::get for PODs
by Antony Polukhin 04 Jun '16

04 Jun '16

Hi, There's a C++14 library that is able to do basic reflections for PODs without any macro magic or markup: https://github.com/apolukhin/magic_get Would it be interesting for Boost? Could it pass Boost review if it has a reinterpret_cast in it? -- Best regards, Antony Polukhin

8 16

Re: [boost] Cxx dual library
by Thomas Heller 04 Jun '16

04 Jun '16

Am 02.06.2016 8:56 nachm. schrieb "Edward Diener" <eldiener(a)tropicsoft.com>: > > I have finished all the main work on the Cxx dual library at https://github.com/eldiener/cxx_dual. The library is also in the Boost Library Incubator at > http://rrsd.com/blincubator.com/bi_library/cxx_dual-2/?gform_post_id=1597. > > The Cxx dual library, or CXXD for short, is a C++ macro header-only library which chooses between using a Boost library or its C++ standard equivalent library for a number of different C++ implementations, while using the same code to program either choice. An 'implementation' is a Boost library which has a C++ standard library equivalent whose public interfaces are nearly the same in both cases. An 'implementation' is called a 'dual library' in this documentation, or 'CXXD-mod' for short. > > The library does this by defining object-like macros for including the appropriate header file and namespace or using either the Boost library version or the C++ standard library version of a particular dual library. CXXD currently supports twenty eight different dual libraries, where the Boost version and the C++ standard version is nearly interchangeable in some respects. CXXD also provides a macro-based solution for distinguishing between the Boost version and the C++ standard version of a dual library so that specific code for a particular dual library choice may be written in those cases where the public interfaces diverge. Personally, I'm not a big fan of such a solution, especially when those macros "leak" into the public interface. We had a similar interface which would automatically switch between std and boost function. The result looked nice at first sight, however the subtle differences between the two led to various problems, one of which was that documenting the public interfaces containing this macro was very difficult, where does it point to know? Where should we send users to who look for more information about this function type? Should they be aware of both? Switching compilers or even boost version and now suddenly everything seems broken? The solution for us was to just decide which one to use and go with it, setting the requirements to the used standard library/boost version as needed.

4 9

A retrospect on 'CMakeLists.txt' policy review
by David Sankel 04 Jun '16

04 Jun '16

Hello all, I wanted to thank everyone who participated in the CMakeLists.txt and related threads. I'm sorry I wasn't able to participate all the way through, but I found the majority of the posts to be civil and constructive (some of my own heated posts being notable exceptions). Here is my take away. No one is arguing that the current guidelines disallow authors from placing a CMakeLists.txt in the root of their library's directory. Some pointed out drawbacks of placing them there and recommended 'build/' or 'CMake/' instead. Others saw value in having CMakeLists.txt in the root directory, but felt these should be short wrappers where the real work is done in the 'build/' directory. Louis and Paul, I know you felt it important for your gitHub distribution to have 'CMakeLists.txt' in the root directory as is typical for CMake projects. Does this result satisfy your concerns? -- David Sankel

9 18

[announcement] GitHub permission changes
by Daniel Pfeifer 03 Jun '16

03 Jun '16

Hi all, GitHub finally allows us to set permissions on the level of granularity that we always wanted. When we moved to GitHub, we received many request like "can I please get admin rights to my repository?" We wanted to do that, but it just was not possible. As a workaround, we have created a team per repository and many of those teams had just one member. That way, we could at least give you write access to individual repositories. Not quite what you requested, but at least something. Anyway, it is now possible to set permissions on a per repository level. I have started to delete the teams with a single member and added the member as the owner of the repository. How do those changes affect you? As the owner of a repository you have write access as before, but you can also add collaborators, modify the repository descriptions, enable/disable issue tracking and wiki, and so forth. I will continue this cleanup soon, but I need your input. For teams with multiple members, I don't know whether you want to share ownership or whether you prefer to have a single owner and additional contributors. Please create new issues for that matter: https://github.com/boostorg/admin/issues Cheers, Daniel

3 2

Boost.Fiber mini-review May 23 - June 1
by Nat Goodspeed 02 Jun '16

02 Jun '16

Hi all, The Boost.Fiber candidate library by Oliver Kowalke begins a mini-review today, Monday May 23, which will close Wednesday June 1. It was last reviewed in September 2015; the verdict at that time was "not yet." Oliver has been working steadily to address review comments and to improve the library in other ways, and has brought the library back for mini-review. The updated documentation is here: http://olk.github.io/libs/fiber/doc/html/index.html The code is on the master branch of this repository: https://github.com/olk/boost-fiber/tree/master I believe it is Oliver's intention to respond to review feedback on the develop branch, leaving the master branch stable during the review. I will monitor reviews and discussion on both the boost-users@ list and the boost@ developers' list. Please include at least "fiber" and "review" in the subject line of your mail, e.g. by replying to this message. (Please reply to only ONE list, however.) I will also check the Boost Library Incubator for Fiber reviews: http://rrsd.com/blincubator.com/bi_library/fiber/?gform_post_id=859 though I check that less frequently than email. Please do remember to state in your review whether you think the library should be accepted as a Boost library. Thank you for your interest and your feedback! ----------------------------------------------------- Here follows a synopsis of issues raised during the September 2015 review: Cross-thread fiber migration: Evidently the community strongly desires the ability to transfer a suspended fiber from one thread to another. Now supported, with documentation. Cross-thread migration support implies a requirement to document the thread safety requirements of the customization API. Addressed. Standard required timing specifications: meet (30.2.4 Timing specifications [thread.req.timing]). Addressed. Adapt one or more existing test suites for thread facilities to validate the correctness of the Fiber library's synchronization constructs. The requester clarified in private mail that I misstated his suggestion: he wanted Oliver to review one or more such test suites to discover the kinds of issues that can arise with thread synchronization constructs. He has professed himself satisfied with the current state of the Fiber library's synchronization constructs. std::chrono support: ensure that wait_until() can accept any supported time_point specialization. Addressed. C++11 compatibility. Addressed. Document that this_fiber::yield() (et al.) are valid from main(), or in general from a thread function, as well as from explicitly-launched fibers. Addressed. Make shared_state lock requirements explicit: for example, make mark_ready_and_notify_() accept a std::unique_lock<>& (or &&) to force its caller to provide one. Addressed. Avoid holding mutex during condition_variable::notify_*() calls. Addressed. packaged_task must not decay-copy its task arguments. Addressed. Align fibers::async() signature, result description and invoke_helper implementation with std::async(). Avoid returning std::move(...). Addressed. Wait list implementation: try an intrusive linked list of fiber_context objects. Addressed. Avoid sleeping thread when no fibers are ready -- block on external event. Better handling of waiting tasks (decentralized wait queues?). Addressed. Optimization to resume awakened fiber on the thread that awakens it. Hooks provided. Template redundancy: eliminate duplication between specializations for T, T& and void. The future, shared_future, shared_state, promise and task_object templates were specifically cited. Addressed. Leverage predicate-based condition::wait() overload internally. Addressed. Nested schedulers: make schedulers be schedulable entities themselves. Not implemented. Improve robustness of `promise' handling in Asynchronous Callbacks documentation. Avoid overconfident remarks about it. Addressed. Fix Note overstating the requirements on condition_variable::wait(). Addressed.

2 3

[optional] using name boost::in_place -- need your opinion/advice
by Andrzej Krzemienski 30 May '16

30 May '16

Hi Everyone, I have stumbled upon a problem that I do not know how to address. I would like to seek an advice from the people in this list. I am trying to make boost::optional resemble std::optional (where it is reasonably easy to achieve). std::optional has this nice and useful "placement" constructor: std::optional<std::mutex> m {std::in_place}; std::in_place is a tag type, that instructs std::optional to create an object using placement-new syntax, from the provided arguments (zero in the example), without incurring any move construction. I cannot easily copy 1-to-1 this solution, because in namespace boost name in_place is reserved for the in-place factories: http://www.boost.org/doc/libs/1_61_0/libs/utility/in_place_factories.html I could simply go with a different name for a tag, but something tells me it would introduce an unnecessary complications for users that want to migrate from one optional to another. I could hack in-place factories so that they can also be used as a tag, although, I am not sure it is doable in a type-safe manner, and if it would not confuse people to have this boost::in_place do a number of different things. I could use a different namespace, but again, this might look surprising.I am a bit torn. I wonder if anyone here needed to face a similar problem, and if you can think of an elegant solution. Thanks, &rzej

4 12

[Boost.Test][Boot.Timer v2] header only boost.test conflicts with Boot.Timer V2
by Tan, Tom (Shanghai) 30 May '16

30 May '16

This following simple snippet would yield an error with visual studio 2015 for both boost1.60.61: boost/timer/timer.hpp(32): error C2757: 'timer': a symbol with this name already exists and therefore this name cannot be used as a namespace name // compiled with cl.exe /EHsc #define BOOST_TEST_MODULE test #include <boost/test/included/unit_test.hpp> #include <boost/timer/timer.hpp> The following variants are ok // compiled with cl.exe /EHsc #define BOOST_TEST_MODULE test #include <boost/test/unit_test.hpp> #include <boost/timer/timer.hpp> Or // compiled with cl.exe /EHsc #define BOOST_TEST_MODULE test #include <boost/test/included/unit_test.hpp> #include <boost/timer.hpp> It looks like Boost.Test is relying on boost.timer v1, which is deprecated in documentation and conflict with V2.

3 2

[boost.timer v2] auto_cpu_timer does not compile
by Tan, Tom (Shanghai) 29 May '16

29 May '16

This following snippet generates an error with VS2015 both fo 1.60&1.61: libboost_timer-vc140-mt-s-1_61.lib(cpu_timer.obj) : error LNK2019: unresolved external symbol "public: static class boost::chrono::time_point<class boost::chrono::steady_clock,class boost::chrono::duration<__int64,class boost::ratio<1,1000000000> > > __cdecl boost::chrono::steady_clock::now(void)" (?now@steady_clock@chrono@boost@@SA?AV?$time_point@Vsteady_clock@chrono@boost@@V?$duration@_JV?$ratio@$00$0DLJKMKAA@@boost@@@23@@23@XZ) referenced in function "public: struct boost::timer::cpu_times __cdecl boost::timer::cpu_timer::elapsed(void)const " (?elapsed@cpu_timer@timer@boost@@QEBA?AUcpu_times@23@XZ) // compile with cl.exe /EHSc #include <boost/timer/timer.hpp> int main() { boost::timer::auto_cpu_timer t; } What's interesting is that uncommenting line #14 in file boost/timer/timer.hpp would get rid of this error. - Why is there such a line but commented out there? - Is there a better way to get it through without modifying this file - the binary is downloaded from sourceforge, not a custom build. - Thanks.

1 0

Re: [boost] Boost.Fiber mini-review May 23 - June 1
by Bjorn Reese 28 May '16

28 May '16

On 05/23/2016 06:20 PM, Nat Goodspeed wrote: > Please do remember to state in your review whether you think the > library should be accepted as a Boost library. Yes, I vote for unconditional acceptance of Boost.Fiber. I did not participate in the formal review (due to time constraints), so I am not going to address the individual issues. I happened to have studied Boost.Fiber recently because I came across limitations of the inter-coroutine interaction in Boost.Coroutine, and Boost.Fiber addresses these limitations rather nicely. I especially like the message passing channels, which makes Boost.Fiber an obvious choice for building a coroutine-based actor framework. The only finding I have is that several Boost.Fiber headers include detail headers from Boost.Context. While this is not a problem per se (because Oliver is the maintainer of both libraries), it may be an idea to consider if these detail headers should be made public.

1 0

[iterator] strided, recursive variants
by Jeremy Murphy 28 May '16

28 May '16

Dear Boosters, I was wondering why a strided iterator has not made it into the Boost.Iterator library? There is a strided range in Boost.Range based on a private implementation of such an iterator, and Boost.Compute has their own implementation too. Just an untied loose end? On a related note, what about variants of such iterators that work in recursive algorithms? That is, if you stride a strided iterator, existing implementations will keep nesting the stride type, which the compiler fails to do recursively because there is no stopping criterion. So I wrote a variant of strided iterator that when you stride a strided iterator, it just multiplies the two strides together and takes the base pointer type from the original strided iterator. I assume some of the other iterator adaptors are limited in the same way. Anyway, it's no big deal to me, but I just thought I'd canvas whether that's something people (especially the maintainers) are interested in? Cheers. Jeremy

1 0

compiling mysql-5.7.12, cannot use DTRACE
by Mariano Apilado 26 May '16

26 May '16

Hi, I get the following error when compiling mysql-5.7.12 on Nexenta 4.0.4 OS ( Formerly known as Open Solaris / Illumos ). To temporarily bypass this problem, I chose not to use DTRACE with the compiler options. However, it should be fixed to use DTRACE. # cmake -DENABLE_DTRACE=0 Thanks and Regards,Mariano [ 15%] Linking CXX static library libmysys_ssl.a cd /usr/local/mysql-5.7.12/mysys_ssl && /usr/local/bin/cmake -P CMakeFiles/mysys_ssl.dir/cmake_clean_target.cmake cd /usr/local/mysql-5.7.12/mysys_ssl/CMakeFiles/mysys_ssl.dir && /usr/local/bin/cmake -DDTRACE=/usr/sbin/dtrace -DOUTFILE=/usr/local/mysql-5.7.12/mysys_ssl/CMakeFiles/mysys_ssl.dir/mysys_ssl_dtrace.o -DDFILE=/usr/local/mysql-5.7.12/include/probes_mysql.d -DDTRACE_FLAGS=-64 -DDIRS=. -DTYPE=STATIC_LIBRARY -P /usr/local/mysql-5.7.12/cmake/dtrace_prelink.cmake dtrace: failed to link script /usr/local/mysql-5.7.12/include/probes_mysql.d: No probe sites found for declared provider cd /usr/local/mysql-5.7.12/mysys_ssl && /usr/local/bin/cmake -E cmake_link_script CMakeFiles/mysys_ssl.dir/link.txt --verbose=1 /usr/bin/ar qc libmysys_ssl.a CMakeFiles/mysys_ssl.dir/crypt_genhash_impl.cc.o CMakeFiles/mysys_ssl.dir/mf_tempdir.cc.o CMakeFiles/mysys_ssl.dir/my_default.cc.o CMakeFiles/mysys_ssl.dir/my_getopt.cc.o CMakeFiles/mysys_ssl.dir/my_aes.cc.o CMakeFiles/mysys_ssl.dir/my_sha1.cc.o CMakeFiles/mysys_ssl.dir/my_sha2.cc.o CMakeFiles/mysys_ssl.dir/my_md5.cc.o CMakeFiles/mysys_ssl.dir/my_rnd.cc.o CMakeFiles/mysys_ssl.dir/my_murmur3.cc.o CMakeFiles/mysys_ssl.dir/my_aes_yassl.cc.o /usr/bin/ranlib libmysys_ssl.a cd /usr/local/mysql-5.7.12/mysys_ssl && /usr/bin/ar r /usr/local/mysql-5.7.12/mysys_ssl/libmysys_ssl.a /usr/local/mysql-5.7.12/mysys_ssl/CMakeFiles/mysys_ssl.dir/mysys_ssl_dtrace.o ar: cannot open /usr/local/mysql-5.7.12/mysys_ssl/CMakeFiles/mysys_ssl.dir/mysys_ssl_dtrace.o: No such file or directory ar: /usr/local/mysql-5.7.12/mysys_ssl/CMakeFiles/mysys_ssl.dir/mysys_ssl_dtrace.o not found gmake[2]: *** [mysys_ssl/libmysys_ssl.a] Error 1 gmake[2]: *** Deleting file `mysys_ssl/libmysys_ssl.a' gmake[2]: Leaving directory `/usr/local/mysql-5.7.12' gmake[1]: *** [mysys_ssl/CMakeFiles/mysys_ssl.dir/all] Error 2 gmake[1]: Leaving directory `/usr/local/mysql-5.7.12’ gmake: *** [all] Error 2

2 1

Call for Papers for Meeting C++ 2016 ends on Friday night!
by Jens Weller 25 May '16

25 May '16

Hello Boost Community! a short reminder, that the deadline is coming up for submitting your talk to this years Meeting C++ conference! Meeting C++ 2016 Page: http://meetingcpp.com/index.php/mcpp2016.html Talk submission page: https://meetingcpp.com/mcpp/submittalk/ thanks, Jens Weller

1 0

Error while compiling mysql-5.7.12 /usr/xpg4/include/term.h:596: error: conflicting types for ‘tgoto’
by Mariano Apilado 25 May '16

25 May '16

Hi, I get the following error when compiling mysql-5.7.12 on Nexenta 4.0.4 OS ( Formerly known as Open Solaris / Illumos ). In order to temporarily bypass this problem, I commented out. However, this is not the solution. /usr/local/mysql-5.7.12/cmd-line-utils/libedit/terminal.c:60: /* *#ifdef HAVE_CURSES_H *#include <curses.h> *#elif HAVE_NCURSES_H *#include <ncurses.h> *#endif */ Thanks and Regards,Mariano Error: [ 4%] Building C object cmd-line-utils/libedit/CMakeFiles/edit.dir/terminal.c.o cd /usr/local/mysql-5.7.12/cmd-line-utils/libedit && /usr/bin/gcc -DHAVE_CONFIG_H -D_FILE_OFFSET_BITS=64 -D_POSIX_PTHREAD_SEMANTICS -D_PTHREADS -D_REENTRANT -D__EXTENSIONS__ -I/usr/local/mysql-5.7.12/cmd-line-utils/libedit -I/usr/local/mysql-5.7.12/include -I/usr/local/mysql-5.7.12/extra/rapidjson/include -I/usr/local/mysql-5.7.12/libbinlogevents/include -I/usr/local/mysql-5.7.12/libbinlogevents/export -I/usr/xpg4/include -m64 -O3 -g -fabi-version=2 -fno-omit-frame-pointer -fno-strict-aliasing -DDBUG_OFF -fPIC -m64 -lstdc++ -R'RIGIN/../lib' -R/usr/lib/amd64 -o CMakeFiles/edit.dir/terminal.c.o -c /usr/local/mysql-5.7.12/cmd-line-utils/libedit/terminal.c In file included from /usr/xpg4/include/curses.h:43, from /usr/local/mysql-5.7.12/cmd-line-utils/libedit/terminal.c:60: /usr/xpg4/include/term.h:596: error: conflicting types for ‘tgoto’ /usr/local/mysql-5.7.12/cmd-line-utils/libedit/sys.h:137: note: previous declaration of ‘tgoto’ was here gmake[2]: *** [cmd-line-utils/libedit/CMakeFiles/edit.dir/terminal.c.o] Error 1 gmake[2]: Leaving directory `/usr/local/mysql-5.7.12' gmake[1]: *** [cmd-line-utils/libedit/CMakeFiles/edit.dir/all] Error 2 gmake[1]: Leaving directory `/usr/local/mysql-5.7.12’ gmake: *** [all] Error 2

1 0

Having problems installing mysql 5.7.12 with boost ELF 32 bit, wrong ELF Class
by Mariano Apilado 25 May '16

25 May '16

Hi, I get the following error when compiling mysql-5.7.12 on Nexenta 4.0.4 OS ( Formerly known as Open Solaris / Illumos ). How do I fix the compile options or get the necessary files required to make the compile successful? Thanks and Regards, Mariano The files libboost_system.so and libboost_chrono.so are the wrong ELF class: ELFCLASS32. root@nex-01-test:/volumes# file /root/boost_1_59_0/stage/lib/libboost_system.so /root/boost_1_59_0/stage/lib/libboost_system.so: ELF 32-bit LSB dynamic lib 80386 Version 1, dynamically linked, not stripped, no debugging information available root@nex-01-test:/volumes# file /root/boost_1_59_0/stage/lib/libboost_system.so /root/boost_1_59_0/stage/lib/libboost_system.so: ELF 32-bit LSB dynamic lib 80386 Version 1, dynamically linked, not stripped, no debugging information available Error Message: [ 95%] Linking CXX executable ../mysqlpump cd /root/mysql-5.7.12/client/dump && /usr/local/bin/cmake -E cmake_link_script CMakeFiles/mysqlpump.dir/link.txt --verbose=1 /usr/bin/g++ -w -fpermissive -m64 -Wall -Wextra -Wformat-security -Wvla -Woverloaded-virtual -Wno-unused-parameter -O3 -g -fabi-version=2 -fno-omit-frame-pointer -fno-strict-aliasing -DDBUG_OFF -R'$ORIGIN/../lib' -R/usr/lib/amd64 CMakeFiles/mysqlpump.dir/program.cc.o -o ../mysqlpump libmysqlpump_lib.a -lboost_system -lboost_chrono ../base/libclient_base.a ../../libmysql/libmysqlclient.a -lsocket -lnsl -lm ../../extra/liblz4_lib.a ld: fatal: file /root/boost_1_59_0/stage/lib/libboost_system.so: wrong ELF class: ELFCLASS32 ld: fatal: file /root/boost_1_59_0/stage/lib/libboost_chrono.so: wrong ELF class: ELFCLASS32 ld: fatal: file processing errors. No output written to ../mysqlpump collect2: ld returned 1 exit status gmake[2]: *** [client/mysqlpump] Error 1 gmake[2]: Leaving directory `/root/mysql-5.7.12' gmake[1]: *** [client/dump/CMakeFiles/mysqlpump.dir/all] Error 2 gmake[1]: Leaving directory `/root/mysql-5.7.12’ gmake: *** [all] Error 2

2 1

[compute] [OS X 10.11.5] [GeForce GT 750M] Segmentation fault
by Prashant 25 May '16

25 May '16

Hi, Am trying to sort a vector on GPU (GeForce GT 750M) using example code which generates SEGV. However, it runs fine on Iris Pro (Intel(R) Core(TM) i7-4850HQ CPU). We observe SEGV when size is 10 million. When the size is 5 million, following exception is thrown: boost/1_61_0/include/boost/compute/command_queue.hpp(453): Throw in function boost::compute::event boost::compute::command_queue::enqueue_write_buffer(const boost::compute::buffer &, size_t, size_t, const void *, const boost::compute::wait_list &) Dynamic exception type: boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector< boost::compute::opencl_error> > std::exception::what: Invalid Value Another observation: if the size of vector is 50 million the sorting works fine, though the timings are worse than Iris Pro. Also, when is size is 100 million, the binary causes the OS to crash. Compiler details: clang++ --version Apple LLVM version 7.3.0 (clang-703.0.31) Target: x86_64-apple-darwin15.5.0 Thread model: posix OS: System Version: OS X 10.11.5 (15F34) Kernel Version: Darwin 15.5.0 Regards, Prashant ----------------------------Cut here------------------------------------- #include <iostream> #include <vector> #include <algorithm> #include <boost/foreach.hpp> #include <boost/compute/core.hpp> #include <boost/compute/platform.hpp> #include <boost/compute/algorithm.hpp> #include <boost/compute/container/vector.hpp> #include <boost/compute/functional/math.hpp> #include <boost/compute/types/builtin.hpp> #include <boost/compute/function.hpp> #include <boost/chrono/include.hpp> #include <boost/exception/all.hpp> namespace compute = boost::compute; int main(int argc, char* argv[]) { if (argc != 2) { std::cout << "Usage: " << argv[0] << " <size> " << std::endl; return 0; } // generate random data on the host std::vector<float> host_vector(atoi(argv[1])); std::generate(host_vector.begin(), host_vector.end(), rand); std::cout << "===============CPU==================\n"; for (size_t k=0; k<5; k++) { std::vector<float> host_copy_vector(host_vector); auto start = std::chrono::high_resolution_clock::now(); std::sort(host_copy_vector.begin(), host_copy_vector.end()); auto duration = std::chrono::duration_cast<std::chrono::milliseconds> (std::chrono::high_resolution_clock::now() - start); std::cout << "time: iteration ("<< k << ") : " << duration.count() << " ms" << std::endl; } std::vector<compute::platform> platforms = compute::system::platforms(); for(size_t i = 0; i < platforms.size(); i++){ const compute::platform &platform = platforms[i]; std::cout << "Platform '" << platform.name() << "'" << std::endl; std::vector<compute::device> devices = platform.devices(); for(size_t j = 0; j < devices.size(); j++){ const compute::device &device = devices[j]; std::string type; if(device.type() & compute::device::gpu) type = "GPU Device"; else if(device.type() & compute::device::cpu) type = "CPU Device"; else if(device.type() & compute::device::accelerator) type = "Accelerator Device"; else type = "Unknown Device"; if (type != "GPU Device") { std::cout << "Ignoring non GPU devices.\n"; continue; } std::cout << "====\n"; std::cout << " " << type << ": " << device.name() << std::endl; std::cout << "====\n"; compute::context context(device); compute::command_queue queue(context, device); for (size_t k=0; k<5; k++) { compute::vector<float> device_vector(host_vector.size(), context); // copy data from the host to the device compute::copy( host_vector.begin(), host_vector.end(), device_vector.begin(), queue ); auto start = std::chrono::high_resolution_clock::now(); try { compute::sort(device_vector.begin(), device_vector.end(), queue); } catch (boost::exception & e) { std::cerr << diagnostic_information(e); break; } auto duration = std::chrono::duration_cast<std::chrono::milliseconds> (std::chrono::high_resolution_clock::now() - start); std::cout << "time: iteration ("<< k << ") : " << duration.count() << " ms" << std::endl; } std::cout << "====\n"; } } return 0; }

2 1

[multiprecision] compilation failure
by Raffi Enficiaud 24 May '16

24 May '16

Hi, I have the following failure on develop from multiprecision (unit tests of boost.test): In file included from writing-test-ts/fp-multiprecision-comparison-test.cpp:23:0: ../../../boost/multiprecision/cpp_dec_float.hpp: In member function ?std::size_t boost::multiprecision::backends::cpp_dec_float<Digits10, ExponentType, Allocator>::hash() const?: ../../../boost/multiprecision/cpp_dec_float.hpp:264:10: error: ?hash_combine? is not a member of ?boost? boost::hash_combine(result, data[i]); Thanks, Raffi

3 2

Request for a "Policy Review" regarding 'CMakeLists.txt'
by David Sankel 24 May '16

24 May '16

A question has been brought up regarding whether or not a Boost library author is permitted to include a 'CMakeLists.txt' file in the root of the directory. This stemmed from a discussion at C++Now 2016 which included several members of the Boost Steering Committee and a sampling of the Boost community. We recommend and propose that the Boost Guidelines are modified to allow library authors, at their own discretion, to include a 'CMakeLists.txt' file in their library's top-level directory. * Several libraries, such as Boost.Hana and Boost.Spirit, have two distribution mechanisms: one as distributed with Boost and the other as an independent package. The requirement that these libraries not include a 'CMakeLists.txt' as part of their Boost distribution creates a maintenance burden for authors or otherwise hurts usability of the independent distribution. * Several companies have revealed that they are building Boost with their own custom CMake scripts. The suggested policy change would enable authors to relieve the infrastructure cost of their CMake users and unify how their library is built. * CMake is, by far, the most popular build system for C++. Allowing authors to support CMake users in addition to BJam will help the Boost ecosystem to grow and thrive by lowering the barriers to access. -- David Sankel

51 224

Boost.Fit review Mars 3-20 result
by Vicente J. Botet Escriba 24 May '16

24 May '16

Hi, I will be out for two weeks and I wanted to at least give the result of the Boost.Fit library review even if I would need more time to have a complete report. Summary ======= The review of the proposed Boost.Fit library ended on Mars 20, 2016. The verdict is: Conditional acceptance (a new review is needed) There were too much concerns about the documentation and what exactly this library is proposing and not enough reviews commenting the design, code and test for each one of the proposed functions. From the review discussion I deduce that there is some interest in the library, and that some people don't understand yet what the library is proposing. Paul has started already to take in account some if the issues raised during the review and a lot of them must be resolved before we re-try a new review. There were some discussion about the name of the library, but there were no consensus. Paul is free to change the name of his library and see how people react. On behalf of the Boost community, I would like to thank Paul Fultz for the work he has put into the Fit library so far. I encourage him to continue to evolve this library and to bring it back for a new review. We had seven 6 formal votes, and 2 more votes without a complete review abbreviated here: Steaven Watanabe: No in his current state Zach Laine : Conditinal acceptance Krzysztof Jusiak: Accepted Artyom Beilis : Rejected Peter Dimov : Accepted (no review) Manuel Sancher : Accepted (no review) Rob Stewart : Conditinal acceptance ??? Louis Dionne : Conditinal acceptance There were other people that participated on the review giving their advice respect to a specific issue. I thank each of these reviewers, and indeed everyone who invested some time participating in the discussions. If you feel that I have misrepresented your position, or have omitted or garbled an important point, please respond: the archived mail thread should accurately reflect the will of the community, even if this message does not. Detailed Report =============== You will need to wait yet for a month before I will be able to do it. On the mean time there are a lot of issues that must be addressed and that are part of the github issues. For more information see: Github:https://github.com/pfultz2/Fit/tree/boost Issues:https://github.com/pfultz2/Fit/issues Documentation:http://pfultz2.github.io/Fit/doc/html/ Hopping this helps, Vicente Botet Escriba

11 26