August 2014 - Boost - lists.boost.org

[Serialization] link error in 1.56
by Tobias Loew 25 Aug '14

25 Aug '14

Hi, linking the serialization lib fails in version1.56 with unresolved symbols due to the missing implementation of boost::archive::detail::shared_ptr_helper::shared_ptr_helper(void) boost::archive::detail::shared_ptr_helper::~shared_ptr_helper(void) up to version 1.55 those symbols were defined in libs\serialization\src\shared_ptr_helper.cpp, but now this file is excluded from the build and contains the implementation of a nowhere defined class shared_ptr_helper_base. Is there a replacement for shared_ptr_helper, is it redundant or is serialization broken in 1.56? Tobias -- View this message in context: http://boost.2283326.n4.nabble.com/Serialization-link-error-in-1-56-tp46668… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 2

[container] New container: why is everybody silent?
by Alexander Kuprijanov 25 Aug '14

25 Aug '14

Hi boost community! Please tell me something about my container, don't be silent. I firmly intend to offer it to boost, because it's much faster than competitors (by a constant factor). It's intended to replace std::vector in cases, when an application requires multiple insertion/deletion. It takes O(log(N)) for insertion/deletion. Docs: http://alexkupri.github.com/array/ Code: https://github.com/alexkupri/array Best regards, Aleksandr Kupriianov

10 22

[move] const rvalue failure.
by Mostafa 25 Aug '14

25 Aug '14

The following fails to compile on both g++ 4.8.2 and VS2005 using Boost 1.56: #include <boost/move/core.hpp> #include <boost/move/utility.hpp> struct MOC { MOC() : value(121) {} MOC(BOOST_RV_REF(MOC) rhs) : value(rhs.value) {} int value; private: //Declared and purposefully not defined. MOC & operator=(MOC); private: BOOST_MOVABLE_BUT_NOT_COPYABLE(MOC) }; MOC moveonlyMutableRValue() { return MOC(); } MOC const moveonlyConstRValue() { return MOC(); } int main() { MOC m(moveonlyConstRValue()); return 0; } with g++, I get the following error messages: boost_move_const_rvalue.cc: In function ‘int main()’: boost_move_const_rvalue.cc:28:30: error: invalid user-defined conversion from ‘const MOC’ to ‘boost::rv<MOC>&’ [-fpermissive] MOC m(moveonlyConstRValue()); ^ In file included from boost_move_const_rvalue.cc:1:0: /home/HPC/boost_installed/v1_56_0/include/boost/move/core.hpp:219:7: note: candidate is: MOC::operator boost::rv<MOC>&() <near match> operator ::boost::rv<TYPE>&() \ ^ boost_move_const_rvalue.cc:13:3: note: in expansion of macro ‘BOOST_MOVABLE_BUT_NOT_COPYABLE’ BOOST_MOVABLE_BUT_NOT_COPYABLE(MOC) ^ /home/HPC/boost_installed/v1_56_0/include/boost/move/core.hpp:219:7: note: no known conversion for implicit ‘this’ parameter from ‘const MOC*’ to ‘MOC*’ operator ::boost::rv<TYPE>&() \ ^ boost_move_const_rvalue.cc:13:3: note: in expansion of macro ‘BOOST_MOVABLE_BUT_NOT_COPYABLE’ BOOST_MOVABLE_BUT_NOT_COPYABLE(MOC) ^ boost_move_const_rvalue.cc:28:30: error: passing ‘const MOC’ as ‘this’ argument of ‘MOC::operator boost::rv<MOC>&()’ discards qualifiers [-fpermissive] MOC m(moveonlyConstRValue());

1 2

[serialization] get_helper documentation
by Joaquin M Lopez Munoz 24 Aug '14

24 Aug '14

Hi, I see the Loading and Saving Archive concepts in Boost.Serialization have been augmented with helper support via get_helper<Helper>(). However, this is only explicitly documented for *Loading* Archives, http://www.boost.org/libs/serialization/doc/archives.html when indeed Saving Archives must and do also provide such a member function. Best, Joaquín M López Muñoz Telefónica

1 0

[type_traits] is_character<T> trait
by Antony Polukhin 24 Aug '14

24 Aug '14

Hi, Boost.LexicalCast has a trait boost::detail::is_character<T>, that evaluates to true if T is char, char16_t, wchar_t, unsigned char or any other character type. If this trait looks useful, I can move it to TypeTraits library, add docs and tests. Is there any interest in such trait? -- Best regards, Antony Polukhin

3 2

Re: [boost] [Boost-users] [Chrono] The default BOOST_CHRONO_VERSION is still 1
by Vicente J. Botet Escriba 24 Aug '14

24 Aug '14

Le 24/08/14 01:49, DonM a écrit : > -------- Original Message -------- > Subject: Re: [Boost-users] [Chrono] The default BOOST_CHRONO_VERSION > is still 1 > From: "Vicente J. Botet Escriba" <vicente.botet(a)wanadoo.fr> > Date: 8/23/2014 6:28 AM > To: boost-users(a)lists.boost.org >> >> Le 23/08/14 01:41, DonM a écrit : >>> The docs (boost_1_56_0/doc/html/chrono/reference.html) say: >>> >>> "The default value for BOOST_CHRONO_VERSION will be changed to 2 >>> since Boost 1.55. " >>> >>> However, it still has the value 1 in both 1.55 and 1.56. >>> >>> Not a big deal, I just noticed and figured I'd mention it. >>> >> Hi, >> >> I must remove this comment as as there is a incompatibility this will >> break user code. I planned to do a smooth trarnsition, but there were >> some complains. >> >> Thanks for pointing this issue, >> Vicente > > Are you saying that you never intend to change the default value? That > would be a mistake, in my opinion. Version 2 is much better -- the I/O > stuff works. If users need backwards compatibility, they can define > version 1, but encourage people to use version 2. Just my $0.02. > What others think? Vicente

1 0

[math] pull request for boost::math::round bug in corner cases
by Robin Eckert 24 Aug '14

24 Aug '14

Hello, I found two corner cases in which boost::math::round doesn't round correctly. For double types, these are the numbers directly beneath 0.5: +/- 0.499999999999999944488848768742172978818416595458984375 (which get rounded to 1.0 although their aboslute value is smaller than 0.59) and odd integral numbers on the edge of the mantissa length: +/- 4503599627370497.0 +/- 4503599627370499.0 +/- 4503599627370501.0 ... +/- 9007199254740989.0 +/- 9007199254740991.0 +/- 9007199254740993.0 These get rounded to the next bigger/smaller integral value. For a detailed explanation and a fix, see the description of the pull request on https://github.com/boostorg/math/pull/8 Regards, Robin

1 0

[test] Using BOOST_CHECK_EQUAL with enum
by Edward Diener 23 Aug '14

23 Aug '14

In code I have the expression: BOOST_CHECK_EQUAL(cnew,e_test_third); where 'cnew' is: test_enum cnew; and test_enum is: enum test_enum { e_test_default, e_test_first, e_test_second, e_test_third }; This is giving me the error: ..\..\../boost/test/test_tools.hpp:100:1: error: expected ')' before 'do' do { \ ^ ..\..\../boost/test/test_tools.hpp:169:5: note: in expansion of macro 'BOOST_CHECK_WITH_ARGS_IMPL' BOOST_CHECK_WITH_ARGS_IMPL( ::boost::test_tools::tt_detail::equal_impl_frwd(), "", CHECK, CHECK_EQUAL, (L)(R) ) ^ test_auto_value.cpp:64:4: note: in expansion of macro 'BOOST_CHECK_EQUAL' BOOST_CHECK_EQUAL(cnew,e_test_third); ^ Is Boost Test incapable of checking that an enumeration object equals an enumerated value ? Is this a known problem ? How do I work around it ?

1 1

[iterator] Merge pull request
by Andrey Semashev 23 Aug '14

23 Aug '14

Hi, Some time ago I made this pull request: https://github.com/boostorg/iterator/pull/6 It makes some of the implementation details of Boost.Iterator public. These components are already used in Boost.Range and Boost.Tokenizer and the intent is to further patch these libs to use public interfaces instead of the implementation details. Could this pull request be merged?

2 6

[filesystem] Epoch of trivial_clock
by Bjorn Reese 23 Aug '14

23 Aug '14

The filesystem::trivial_clock type is implementation-defined [1]. That means that the epoch is also implementation-defined. How do we determine the epoch of trivial_clock? For instance, we may need to represent the last_write_time() timestamp to the end-user, or transfer it to another node when we implement a network file system. PS: I am looking at the std::filesystem proposal, but I assume that boost::filesystem will be update accordingly. [1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4097.html#8

5 7

GSOC: Boost.Math: hypergeometric functions
by Anton Bikineev 22 Aug '14

22 Aug '14

Hi all, I'm glad to represent my GSoC project work about implementation of hypergeometric functions: https://github.com/BoostGSoC14/boost.math I would like to thank everybody who helped me, essentially my mentor Christopher Kormanyos, my advisors John Maddock, Paul Bristow and, of course, Niall Douglas. The concentration of the project was mostly confluent hypergeometric function 1f1. Some essential algorithms were implemented and research works were done. A few short articles may be read in my blog: http://antoha-bikineev.blogspot.com Of course, it's gonna be updated while researching. The most important thing for me is that this work opened new ideas, ways and approaches for development and investigation of new numerical algorithms. Some of them are intended to reduce probability of cancellation errors in power series and to reduce round-off errors for recurrence relations at unstable directions. So there are plenty of stuff to do and improve.

1 0

[graph] Faster strong_components-implementation
by Alexander Lauser 22 Aug '14

22 Aug '14

Hi all, reimplementing Tarjan's dfs-visitor used in Boost.Graph's algorithm to compute strong components yielded a performance gain of about 15 to 20% (for adjacency_list-graphs). The problem is that due to bug #10231 [1], this implementation does not work with a current vanilla version of Boost. (See below for some details explaining my changes and the reason it is affected by the bug.) Is there interest in the faster implementation? If so, what's the best way to proceed? Wait until the bug is fixed and then incorporate the changes in a pull request? Create a pull request and hope that is not merged before the bug is fixed? Btw, my feeling is that the bug's not too involved and I tried to fix it myself. It seems that it is not even in Boost.Graph itself, but in Boost.TTI (in the macro-depths of which I got lost). Should I file a separate bug for Boost.TTI? For the details: My implementation is a back-to-the-root-approach, following the classical formulations of Tarjan's algorithm more closely. The current implementation somewhat "simulates" edge events upon leaving a vertex by an additional loop over all edges incident to the vertex. This can be avoided by using finish_edge -- which suffers from the above mentioned bug. (In addition to the performance-boost, I think it is also more natural to implement Tarjan's algorithm using finish_edge.) Cheers, Alex [1] https://svn.boost.org/trac/boost/ticket/10231

1 0

ISO C++14 passes final ballot
by Beman Dawes 21 Aug '14

21 Aug '14

All 18 countries voting voted "yes". See http://isocpp.org/blog/2014/08/we-have-cpp14

7 7

[container] variadic template support in g++ 4.5.1
by Richard Hadsell 21 Aug '14

21 Aug '14

I am trying to compile some of our code with Boost 1.56.0 on a Linux (Fedora 14) platform with this compiler: gcc version 4.5.1 20100924 (Red Hat 4.5.1-4) I apologize for using this ancient version of g++, but we're stuck with it for a while longer. I get this error message: In file included from .../boost/circular_buffer/details.hpp:19:0, from .../boost/circular_buffer.hpp:56, from ...: /netDISKS/master/netmt/LINUX_INTF14/cgi/boost/1.56.0/Include/libboost/boost/container/allocator_traits.hpp: In static member function 'static void boost::container::allocator_traits<Alloc>::priv_construct(boost::false_type, Alloc&, T*, const Args& ...)': /netDISKS/master/netmt/LINUX_INTF14/cgi/boost/1.56.0/Include/libboost/boost/container/allocator_traits.hpp:324:43: sorry, unimplemented: cannot expand 'Args ...' into a fixed-length argument list /netDISKS/master/netmt/LINUX_INTF14/cgi/boost/1.56.0/Include/libboost/boost/container/allocator_traits.hpp:325:51: error: 'value' is not a valid template argument for type 'bool' because it is a non-constant expression /netDISKS/master/netmt/LINUX_INTF14/cgi/boost/1.56.0/Include/libboost/boost/container/allocator_traits.hpp:325:57: error: invalid type in declaration before ';' token Line 324 is in a block guarded by: #if !defined(BOOST_NO_CXX11_VARIADIC_TEMPLATES) config/compiler/gcc.hpp defines BOOST_NO_CXX11_VARIADIC_TEMPLATES for g++ earlier than 4.4, which means it believes the code should be valid for 4.5.1. Is there already a fix for this in development? Please, tell me what to do with my copy of 1.56.0. -- Dick Hadsell 203-992-6320 Fax: 203-992-6001 Reply-to: hadsell(a)blueskystudios.com Blue Sky Studios http://www.blueskystudios.com 1 American Lane, Greenwich, CT 06831-2560

2 4

intrusive_ptr wrapper for C++/CLI
by Stephen Channell 21 Aug '14

21 Aug '14

I do a lot of development using native C++ and managed C++/CLI, and have coded a simple smart pointer wrapper around intrusive_ptr to allow C++/CLI code to use reference counting objects without change. IntrusivePtr takes advantage of the template support engineered for gcroot<T> to implement the smart pointer. It’s a wrapper to support factory functions that return intrusive_ptr. Whilst many would object to putting C++/CLI conditional code into boost, the smart pointer is too small to stand alone and too boost specific for Microsoft. thoughts welcome https://ql.codeplex.com/SourceControl/latest#IntrusivePtr/boost/IntrusivePt…

3 3

Re: [boost] [units] Pull request and RFC: information unit definitions for Boost.Units
by Curdeius Curdeius 21 Aug '14

21 Aug '14

Hi all, From: Jürgen Hunold <jhunold(a)gmx.eu> > > > I'd like to have a definite response on "go/no go" for maintainership > > > before I invest some of my scarce time on this. > > > > Go for it. > > Thanks a lot. > > Done. See https://github.com/boostorg/admin/issues/83 for my request. > > Please bear with me as I want to check the current repository state first. > The > plan is to tackle the simple pull requests afterwards and then come back to > the features. > > Yours, > > Jürgen > Firstly, congratulations Jürgen! Secondly, a few days ago I have proposed myself to be a co-maintainer together with Jürgen (see the cite below), but have still no answer from the community. At least Jürgen is not against. So, I ask for a green light from the community to co-maintain Boost.Units. Hi all, > I considered proposing myself as a maintainer of Boost.Units for some > time, but considered too inexperienced to do it on my own. > Therefore I am happy that Jürgen proposed himself and I would like to help > him by being a co-maintainer if it is possible and needed. > As for me, I have been using the library for at least 3 years now and > would like to contribute to it. > For the moment, I mainly proposed small bug fixes to Boost libraries. > Regards, > Marek Kurdej > -- > Ph.D. candidate Best regards, Marek Kurdej -- Ph.D. candidate

3 2

Boost Hana comments
by Jeremy Maitin-Shepard 21 Aug '14

21 Aug '14

First off, while I haven't thoroughly reviewed the library, I am certainly impressed by a lot of what I see. It is obvious that this library represents a lot of excellent work. Here are my miscellaneous comments: Constant type class: -------------------- Why isn't std::integral_constant an instance? There is no documentation of what the value method actually returns, just that it returns something that is a constexpr. Does value(integral<int,3>)) return int, or does it return integral<int,3> ? Perhaps the Constant type class should be "parameterized" by a type specifying the return type of value. Integral data type: ------------------- It would be better not to duplicate std::integral_constant. However, I recognize that the overloaded operators are useful and you wouldn't be able to do this with std::integral_constant (well, I suppose you still could, but as they wouldn't be found by ADL, they wouldn't be terribly useful). This rationale (assuming it is correct) should be documented though. Logical type class: ------------------- What is really gained by making this a type class at all? It seems that and_ and or_ require that all arguments be of the same "hana datatype", though actually this isn't documented anywhere and this might not even be the precise requirement (but obviously it needs to be documented very explicitly, and this probably applies to almost every method in Hana). Really we really should be able to mix multiple data types in a call to or_ or and_, though. Otherwise the usability is unreasonably limited. Of course there is then the question of return type. However, I would assume most users would be happy getting back either a Hana Integral or a bool, depending on whether it is a compile-time or runtime condition. Certainly this would be better than getting back a compiler error. Another question: how does the performance of and_ and or_ compare to the optimized verions you showed in your MPL11 talk? Pair datatype: -------------- Why duplicate std::pair? Alternatively, why duplicate list? Perhaps list should just define first and second as well? Product type class: ---------------- Why isn't a 2-element List, a 2-element std::tuple, etc. an instance? List type class: ---------------- Just as for Logical, it would be useful to be able to mix datatypes in calls to concat, zip, zip_with. The list function itself shouldn't be documented as part of the type class, since it isn't logically part of it. What about get<N>, get<N,M> accessors? I understand these can be defined in terms of the other methods, but clearly they are useful on their own.

3 4

[Concepts] Definition. Was [GSoC] [Boost.Hana] Formal review request
by Mostafa 21 Aug '14

21 Aug '14

On Thu, 31 Jul 2014 10:54:59 -0700, Robert Ramey <ramey(a)rrsd.com> wrote: > Eric Niebler-4 wrote >> On 07/29/2014 05:14 PM, Niall Douglas wrote: >>> I'm all for Concepts as in compiler enforced ones, and I'll add them >>> to AFIO when and only when C++ gets them. But for documentation they >>> don't help. >> >> Wow, I couldn't disagree more. I can't imagine how the standard >> algorithms would be specified without the use of concepts like >> "RandomAccessIterator", for instance. Clustering requirements into >> meaningful abstractions and assigning them names makes it possible to >> document library interfaces without an explosion of verbosity and >> repetition. > > +10 > > Usage of concepts is greatly: > > a) misunderstood > b) misunderestimated as to their value in design AND documentation > d) The word "concepts" is a big contributor to the problem - substitute > "type requirements" or "type constraints" for concepts. -1 to the above term substitutions for concepts. Type requirements/type constrains are not concepts. The reason concepts are misunderstood is because they have not been well defined. FWIW, here's my take on how they should be defined: Concepts are sets of types whose membership are compile-time determinable. Precisely, a concept is any set expressible in the following form: { T | T is a type and p(T ...) } where p is a (n+1)-ary compile time computable boolean function (a function in the mathematical sense, not an actual C++ function). p is said to be (or to express) the type requirements or type constrains for its associated concept. (Note: just as a set membership predicate is not its set, a type requirement is not its concept. For example, the predicate "there exists a,b and a,b are integers and b != 0 and c = a/b" does not denote the set of rational numbers, the symbol Q does.) A type T is said to model a concept C if T is a member of C. In such a case we also say that "T is a C". A concept B is said to be a refinement of a concept A if B is a subset of A. Why use concepts? Because they are helpful in documenting generic code, especially template type parameter requirements. Examples: 1) DefaultConstructible := { T | T has the method "T()" defined and accessible. } // Requirements: // T is DefaultConstructible. template <typename T> struct FooBar { ... }; std::tuple<int> is DefaultConstructible, therefore FooBar< std::tuple<int> > is well formed. Mostafa

14 57

[Container] Provide more guarantees for flat_multimap
by Vinícius dos Santos Oliveira 21 Aug '14

21 Aug '14

Currently, flat_multimap mirrors C++98's multimap concept. I'd like to propose an update to flat_multimap fulfil the C++11's multimap concept. The part I'm particularly interested are guarantees about preserving the insertion ordering for elements with equivalent keys. On ISO/IEC 14882-2011, 23.2.4 - associative container requirements, pages 741 and 742, you can see the effects for a_eq.emplace and a_eq.insert ends with "If a range containing elements equivalent to t exists in a_eq, t is inserted at the end of that range". I see no similar guarantees on the Boost's flat_multimap documentation[1]. This feature is useful, for instance, in HTTP messages, where field reordering is illegal[2] if the keys are equivalent. I did a few tests and it looks to me that flat_multimap already provides these guarantees, but before I go check the source and possibly provide patches, I need to know if there is interest in turning this accidental behaviour into intentional behaviour through documented guarantees. [1] http://www.boost.org/doc/libs/1_56_0/doc/html/boost/container/flat_multimap… [2] http://tools.ietf.org/html/rfc7230#section-3.2.2 -- Vinícius dos Santos Oliveira https://about.me/vinipsmaker

7 17

Metadata pull requests
by Daniel James 21 Aug '14

21 Aug '14

Hi, I just created about 100 pull requests to add library metadata to modules that don't already have it. Apart from them all containing the same typo, I think it went okay. I forgot to mention that the file format is documented at: http://www.boost.org/development/library_metadata.html I'll spend a bit of time improving that soon, so let me know if there's anything missing. Also, if it wasn't clear, the idea is that you can update this file if you need to change the library details. It might take a little while for the website to update, as it only happens when I run the appropriate script. thanks, Daniel

5 11

[units] Pull request and RFC: information unit definitions for Boost.Units
by Erik Erlandson 20 Aug '14

20 Aug '14

Link to PR: https://github.com/boostorg/units/pull/3 Description: Adds unit definitions for standard units of information: bit, byte, nat, hartley, shannon. Defines a new unit system boost::units::information for convenient manipulation. Also includes IEC binary prefixes: kibi, mebi, gibi, tebi, pebi, exbi Example code: https://github.com/erikerlandson/units/blob/info_units/example/information.… Unit testing code: https://github.com/erikerlandson/units/blob/info_units/test/test_informatio…

7 14

[type_traits] Interest in is_iterator type trait?
by Beman Dawes 20 Aug '14

20 Aug '14

Back in 2011, Howard Hinnant and I put together an is_iterator type trait based on code Howard had developed and used over a period of time. See http://beman.github.io/is_iterator/is_iterator.hpp for the actual code See http://beman.github.io/is_iterator/is_iterator_test.cpp for a test program. The intent was always to submit is_iterator to Boost, but we never got around to it. Now I need it in Boost.Filesystem, so I'd rather see it go in type traits than just sticking it into boost/filesystem/detail. If there is interest, and John Maddock gives the OK, I'll write docs and integrate into type_traits, then submit a pull request. --Beman

6 20

Ticket system getting spamed
by Mateusz cerkiewny 20 Aug '14

20 Aug '14

#10352 <https://svn.boost.org/trac/boost/ticket/10352> #10351 <https://svn.boost.org/trac/boost/ticket/10351> #10342 <https://svn.boost.org/trac/boost/ticket/10342> #10339 <https://svn.boost.org/trac/boost/ticket/10339> #10335 <https://svn.boost.org/trac/boost/ticket/10335> #10331 <https://svn.boost.org/trac/boost/ticket/10331> #10334 <https://svn.boost.org/trac/boost/ticket/10335> Are spamms

2 1

[log] Problem Building Boost 1.55 With GCC Using C++11 Mode Due to AVX2 Support
by Stewart, Robert 20 Aug '14

20 Aug '14

We've run into a problem building log. It doesn't appear to be a known issue and we're not sure how to work around it. We found a hack to make our builds succeed, but there may well be a better workaround and we're not certain whether there are any issues with what we've done. We tried to build Boost 1.55 with GCC 4.8.1, 4.8.3, and 4.9.1 with the following commands: ./bootstrap.sh --prefix=<prefix> --libdir=<prefix>/lib --with-toolset=gcc ./b2 --build-type=complete --layout=versioned 'cxxflags=-m64 -O2 -g -pipe' 'cflags=-m64 -O2 -g -pipe' 'linkflags=-Wl,-rpath -Wl,<prefix>/lib -L<gcc_dir>/lib64 -Wl,-rpath -Wl,<gcc_dir>/lib64 -m64' -d+2 -j3 ./b2 --build-type=complete --layout=versioned 'cxxflags=-m64 -O2 -g -pipe' 'cflags=-m64 -O2 -g -pipe' 'linkflags=-Wl,-rpath -Wl,<prefix>/lib -L<gcc_dir>/lib64 -Wl,-rpath -Wl,<gcc_dir>/lib64 -m64' -d+2 -j3 install The errors we get come from this command during the build: gcc.compile.c++ bin.v2/libs/log/build/gcc-4.9/release/link-static/log-api-unix/threading-multi/dump_avx2.o "g++11" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -pthread -fno-strict-aliasing -ftemplate-depth-1024 -m64 -O2 -g -pipe -march=core-avx2 -mavx -mavx2 -fabi-version=0 -m64 -O2 -g -pipe -DBOOST_ALL_NO_LIB=1 -DBOOST_CHRONO_STATIC_LINK=1 -DBOOST_FILESYSTEM_STATIC_LINK=1 -DBOOST_LOG_BUILDING_THE_LIB=1 -DBOOST_LOG_USE_NATIVE_SYSLOG -DBOOST_LOG_WITHOUT_EVENT_LOG -DBOOST_SPIRIT_USE_PHOENIX_V3=1 -DBOOST_SYSTEM_NO_DEPRECATED -DBOOST_SYSTEM_STATIC_LINK=1 -DBOOST_THREAD_BUILD_LIB=1 -DBOOST_THREAD_DONT_USE_CHRONO=1 -DBOOST_THREAD_POSIX -DBOOST_THREAD_USE_LIB=1 -DDATE_TIME_INLINE -DNDEBUG -I"." -c -o "bin.v2/libs/log/build/gcc-4.9/release/link-static/log-api-unix/threading-multi/dump_avx2.o" "libs/log/src/dump_avx2.cpp" There are many lines of output; I've elided similar messages to highlight the unique ones: {standard input}: Assembler messages: {standard input}:611: Error: operand type mismatch for `vpsrldq' ... {standard input}:819: Error: no such instruction: `vextracti128 $0x1,%ymm2,%xmm2' ... {standard input}:1087: Error: no such instruction: `vextracti128 $0x1,%ymm3,48(%r15)' ... {standard input}:1312: Error: operand type mismatch for `vpaddb' While there might be a way to actually get b2 to disable AVX2 support, we hacked libs/log/build/Jamfile.v2 with these commands: sed -i 's:dump_avx2::g' libs/log/build/Jamfile.v2 sed -i 's:<define>BOOST_LOG_USE_AVX2::g' libs/log/build/Jamfile.v2 Those remove dump_avx2 from BOOST_LOG_COMMON_AVX2_SRC and remove the definition of BOOST_LOG_USE_AVX2, which prevents compiling enable_avx2(). Is there a better way to solve or work around this problem? _____ Rob Stewart robert.stewart(a)sig.com Software Engineer, Middleware using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com ________________________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

2 2

[git] Pushing commit(s) after pulling
by Edward Diener 20 Aug '14

20 Aug '14

I share a library with others and make some commit to a branch of that library. Then I try to 'push' the commit, only to be told that there are changes that have been made which I need to 'pull'. So I 'pull' the latest changes for that branch, and luckily there is no conflict(s) with my local commit(s). What do I do now ? I can 'push' my changes successfully but then the history of my particular changes appears to be lost. Am I supposed to revert my changes to the local repository by doing a 'reset' and then reapply those changes ? That seems onerous. What is the right way to 'push' my changes and still preserve the history of each one of them on the remote repository ?

5 9