Re: [PATCH] Re: Update boost in 2.1 branch?
On Thu, Jan 21, 2016 at 04:53:34PM -0500, Scott Kostyshak wrote: > On Thu, Jan 21, 2016 at 04:40:56PM -0500, Richard Heck wrote: > > On 01/21/2016 04:07 PM, Pavel Sanda wrote: > > > Jean-Marc Lasgouttes wrote: > > >> So is it a problem that compiling in C++11 mode is broken with gcc 4.6? > > >> I > > >> would guess not. > > > I guess it also depends how much space for error we have... > > > Richard, do you plan to release one intermediate 2.1.x or you just > > > waiting for the final one? > > > > How far out do we realistically think 2.2.0 is? I am thinking end of > > February, but if it gets delayed any further we might think about an > > intermediate release. > > I think end of February is realistic. Beta should be soon, just need > Guillaume's set of patches to git a final review, and Georg also is > trying to look into an issue that Stephan has reported. After beta I do > not think developers are planning many non-trivial commits so whether we > achieve end of February for a final release will depend on what issues > our beta testers find and on how long it takes us to fix those issues. Richard, I just wanted to give an update that I no longer think the end of February is realistic for the final release. The good news is that soon it will be possible to compile on Windows from the tar ball, which is nice to have fixed. I think we will need to release a beta3 in order to fix one more set of these issues. Then, I will do some advertising of beta3 on various sites. I imagine we want at least a couple of weeks of testing, and I also imagine we will need to fix some issues that are revealed from that testing. Scott signature.asc Description: PGP signature
Re: [PATCH] Re: Update boost in 2.1 branch?
Le 25/01/2016 20:55, Georg Baum a écrit : Jean-Marc Lasgouttes wrote: Le 21/01/2016 15:42, Jean-Marc Lasgouttes a écrit : Sigh. Now that I can test it with an older compiler (gcc 4.6, Ubuntu 12.04) I find that it does not compile in C++98 mode because of boost::next/prior. This has been fixed already in master, so I cherry-picked the commits (see attached). So what shall I do with this patch? In my view it improves the situation. The only reason for not pushing it would be if we revert the boost update patch. I did not reply since the original code is from me, so I am obviously biased, but IMO this would be safe enough to apply. Richard? JMarc
Re: [PATCH] Re: Update boost in 2.1 branch?
Jean-Marc Lasgouttes wrote: > Le 21/01/2016 15:42, Jean-Marc Lasgouttes a écrit : >> >> Sigh. Now that I can test it with an older compiler (gcc 4.6, Ubuntu >> 12.04) I find that it does not compile in C++98 mode because of >> boost::next/prior. This has been fixed already in master, so I >> cherry-picked the commits (see attached). > > So what shall I do with this patch? In my view it improves the > situation. The only reason for not pushing it would be if we revert the > boost update patch. I did not reply since the original code is from me, so I am obviously biased, but IMO this would be safe enough to apply. Georg
Re: [PATCH] Re: Update boost in 2.1 branch?
Jean-Marc Lasgouttes wrote: > Le 25/01/2016 10:58, Kornel Benko a écrit : >> Am Montag, 25. Januar 2016 um 10:43:15, schrieb Jean-Marc Lasgouttes >> >>> Le 22/01/2016 17:15, Kornel Benko a écrit : >> Even with this patch, I could not compile src/support/ForkedCalls.cpp >> with gcc-4.8.4. > > This is in C++11 mode, right? Yes, it is set by checking if the compiler is able to use this mode. >>> >>> With autotools we let C++11 mode be disabled by default in 2.1 (and >>> enabled by default in 2.2). >>> I tried, and now it compiles. So what is the preferred solution? A.) Disable c++11 mode B.) Not set LYX_USE_TR1 >>> >>> I think TR1 should be limited to C++11 mode. >> >> But that is exactly the combination where the compilation fails. > > Yes, but we do not really care about C++11 mode in 2.1, it is only for > adventurous people. And it works for some compiler versions, in my > testing. In that case I would document the problem in NEWS and then forget about it. Georg
Re: [PATCH] Re: Update boost in 2.1 branch?
Le 21/01/2016 15:42, Jean-Marc Lasgouttes a écrit : Le 14/01/2016 19:12, Jean-Marc Lasgouttes a écrit : Le 09/01/2016 00:50, Richard Heck a écrit : On 01/08/2016 05:06 AM, Jean-Marc Lasgouttes wrote: Currently we use boost 1.53 in 2.1 branch. Would it be a good move to update it to 1.60? I am getting loads of warnings with gcc 5.1. Fine with me, and I see the same warnings. OK, I pushed it. Sigh. Now that I can test it with an older compiler (gcc 4.6, Ubuntu 12.04) I find that it does not compile in C++98 mode because of boost::next/prior. This has been fixed already in master, so I cherry-picked the commits (see attached). So what shall I do with this patch? In my view it improves the situation. The only reason for not pushing it would be if we revert the boost update patch. JMarc
Re: [PATCH] Re: Update boost in 2.1 branch?
Le 25/01/2016 10:58, Kornel Benko a écrit : Am Montag, 25. Januar 2016 um 10:43:15, schrieb Jean-Marc Lasgouttes Le 22/01/2016 17:15, Kornel Benko a écrit : Even with this patch, I could not compile src/support/ForkedCalls.cpp with gcc-4.8.4. This is in C++11 mode, right? Yes, it is set by checking if the compiler is able to use this mode. With autotools we let C++11 mode be disabled by default in 2.1 (and enabled by default in 2.2). I tried, and now it compiles. So what is the preferred solution? A.) Disable c++11 mode B.) Not set LYX_USE_TR1 I think TR1 should be limited to C++11 mode. But that is exactly the combination where the compilation fails. Yes, but we do not really care about C++11 mode in 2.1, it is only for adventurous people. And it works for some compiler versions, in my testing. JMarc
Re: [PATCH] Re: Update boost in 2.1 branch?
Am Montag, 25. Januar 2016 um 10:43:15, schrieb Jean-Marc Lasgouttes > Le 22/01/2016 17:15, Kornel Benko a écrit : > >>> Even with this patch, I could not compile src/support/ForkedCalls.cpp > >>> with gcc-4.8.4. > >> > >> This is in C++11 mode, right? > > > > Yes, it is set by checking if the compiler is able to use this mode. > > With autotools we let C++11 mode be disabled by default in 2.1 (and > enabled by default in 2.2). > > > I tried, and now it compiles. > > So what is the preferred solution? > > A.) Disable c++11 mode > > B.) Not set LYX_USE_TR1 > > I think TR1 should be limited to C++11 mode. But that is exactly the combination where the compilation fails. > JMarc Kornel signature.asc Description: This is a digitally signed message part.
Re: [PATCH] Re: Update boost in 2.1 branch?
Le 22/01/2016 17:15, Kornel Benko a écrit : Even with this patch, I could not compile src/support/ForkedCalls.cpp with gcc-4.8.4. This is in C++11 mode, right? Yes, it is set by checking if the compiler is able to use this mode. With autotools we let C++11 mode be disabled by default in 2.1 (and enabled by default in 2.2). I tried, and now it compiles. So what is the preferred solution? A.) Disable c++11 mode B.) Not set LYX_USE_TR1 I think TR1 should be limited to C++11 mode. JMarc
Re: [PATCH] Re: Update boost in 2.1 branch?
Le 22/01/2016 22:55, Georg Baum a écrit : C++11 does not matter for 2.1 IMHO. Compilers will support C++98 much longer than 2.1 will be relevant, and even if that means to enable it by special command line options users can pass them to configure. I guess the TR1 support is finally biting us back. We could let the code in, but remove the #define LYX_USE_TR1 in conifg.h. I would rather not touch it for gcc. Can we remove it just for clang? We would have to have a check for libc++ in configure since the detection requires loading a STL header file. Checking for clang is not enough since by default it uses libstdc++ with gcc. We could also decide to use TR1 only in C++11 mode, since these are std:: constructs that we want there after all. JMarc
Re: [PATCH] Re: Update boost in 2.1 branch?
Jean-Marc Lasgouttes wrote: > This is in C++11 mode, right? By default (c++98) it should just work > IMO. I do not think that we have firm plans of making lyx 2.1 compile in > C++11 mode. C++11 does not matter for 2.1 IMHO. Compilers will support C++98 much longer than 2.1 will be relevant, and even if that means to enable it by special command line options users can pass them to configure. > I guess the TR1 support is finally biting us back. We could let the code > in, but remove the #define LYX_USE_TR1 in conifg.h. I would rather not touch it for gcc. Can we remove it just for clang? Georg
Re: [PATCH] Re: Update boost in 2.1 branch?
Am Freitag, 22. Januar 2016 um 17:01:11, schrieb Jean-Marc Lasgouttes > Le 22/01/2016 16:15, Kornel Benko a écrit : > > Am Freitag, 22. Januar 2016 um 11:27:02, schrieb Jean-Marc Lasgouttes > > > >> Le 21/01/2016 22:40, Richard Heck a écrit : > >>> On 01/21/2016 04:07 PM, Pavel Sanda wrote: > I guess it also depends how much space for error we have... > Richard, do you plan to release one intermediate 2.1.x or you just > waiting for the final one? > >>> > >>> How far out do we realistically think 2.2.0 is? I am thinking end of > >>> February, but if it gets delayed any further we might think about an > >>> intermediate release. > >>> > >>> Really, I should have done 2.1.5 back at the end of November, but I > >>> thought 2.2 was closer. > >> > >> One solution would be to have a 2.1.5 together with 2.2beta with an > >> updated lyx2lyx that reads 2.2beta format. A good occasion to make > >> people exercise this code. > >> > >> And then 2.1.6 would just be the usual final version. > >> > >> JMarc > > > > Even with this patch, I could not compile src/support/ForkedCalls.cpp with > > gcc-4.8.4. > > This is in C++11 mode, right? Yes, it is set by checking if the compiler is able to use this mode. > By default (c++98) it should just work > IMO. I do not think that we have firm plans of making lyx 2.1 compile in > C++11 mode. Should we disable it? > I guess the TR1 support is finally biting us back. We could let the code > in, but remove the #define LYX_USE_TR1 in conifg.h. This setting depends ATM on gnu-cxx version >= 4.4 I tried, and now it compiles. So what is the preferred solution? A.) Disable c++11 mode B.) Not set LYX_USE_TR1 > JMarc Kornel signature.asc Description: This is a digitally signed message part.
Re: [PATCH] Re: Update boost in 2.1 branch?
Le 22/01/2016 16:15, Kornel Benko a écrit : Am Freitag, 22. Januar 2016 um 11:27:02, schrieb Jean-Marc Lasgouttes Le 21/01/2016 22:40, Richard Heck a écrit : On 01/21/2016 04:07 PM, Pavel Sanda wrote: I guess it also depends how much space for error we have... Richard, do you plan to release one intermediate 2.1.x or you just waiting for the final one? How far out do we realistically think 2.2.0 is? I am thinking end of February, but if it gets delayed any further we might think about an intermediate release. Really, I should have done 2.1.5 back at the end of November, but I thought 2.2 was closer. One solution would be to have a 2.1.5 together with 2.2beta with an updated lyx2lyx that reads 2.2beta format. A good occasion to make people exercise this code. And then 2.1.6 would just be the usual final version. JMarc Even with this patch, I could not compile src/support/ForkedCalls.cpp with gcc-4.8.4. This is in C++11 mode, right? By default (c++98) it should just work IMO. I do not think that we have firm plans of making lyx 2.1 compile in C++11 mode. I guess the TR1 support is finally biting us back. We could let the code in, but remove the #define LYX_USE_TR1 in conifg.h. JMarc
Re: [PATCH] Re: Update boost in 2.1 branch?
Am Freitag, 22. Januar 2016 um 11:27:02, schrieb Jean-Marc Lasgouttes > Le 21/01/2016 22:40, Richard Heck a écrit : > > On 01/21/2016 04:07 PM, Pavel Sanda wrote: > >> I guess it also depends how much space for error we have... > >> Richard, do you plan to release one intermediate 2.1.x or you just waiting > >> for the final one? > > > > How far out do we realistically think 2.2.0 is? I am thinking end of > > February, but if it gets delayed any further we might think about an > > intermediate release. > > > > Really, I should have done 2.1.5 back at the end of November, but I > > thought 2.2 was closer. > > One solution would be to have a 2.1.5 together with 2.2beta with an > updated lyx2lyx that reads 2.2beta format. A good occasion to make > people exercise this code. > > And then 2.1.6 would just be the usual final version. > > JMarc Even with this patch, I could not compile src/support/ForkedCalls.cpp with gcc-4.8.4. ... cd /usr/BUILD/BuildLyx2.1Git/src/support && /usr/bin/c++ -DLYX_CALLSTACK_PRINTING -DQT_CORE_LIB -I/usr/BUILD/BuildLyx2.1Git -I/usr/src/lyx/lyx-2.0.x-git/src -I/usr/include/enchant -I/usr/src/lyx/lyx-2.0.x-git/boost -I/usr/src/lyx/lyx-2.0.x-git/src/support -I/usr/BUILD/BuildLyx2.1Git/src/support -I/usr/src/lyx/lyx-2.0.x-git/src/support/mythes -isystem /usr/BUILD/BuildQt5/5.5/gcc_64/include -isystem /usr/BUILD/BuildQt5/5.5/gcc_64/include/QtCore -isystem /usr/BUILD/BuildQt5/5.5/gcc_64/./mkspecs/linux-g++ -Wall -Wunused-parameter --std=gnu++11 -fno-strict-aliasing -Wall -Wunused-parameter --std=gnu++11 -fno-strict-aliasing -O0 -g3 -D_DEBUG -DBOOST_USER_CONFIG="" -fPIC -o CMakeFiles/support.dir/ForkedCalls.cpp.o -c /usr/src/lyx/lyx-2.0.x-git/src/support/ForkedCalls.cpp In file included from /usr/src/lyx/lyx-2.0.x-git/src/support/ForkedCalls.h:19:0, from /usr/src/lyx/lyx-2.0.x-git/src/support/ForkedCalls.cpp:17: /usr/src/lyx/lyx-2.0.x-git/boost/boost/signal.hpp:17:4: warning: #warning "Boost.Signals is no longer being maintained and is now deprecated. Please switch to Boost.Signals2. To disable this warning message, define BOOST_SIGNALS_NO_DEPRECATION_WARNING." [-Wcpp] # warning "Boost.Signals is no longer being maintained and is now deprecated. Please switch to Boost.Signals2. To disable this warning message, define BOOST_SIGNALS_NO_DEPRECATION_WARNING." ^ In file included from /usr/src/lyx/lyx-2.0.x-git/boost/boost/function/detail/maybe_include.hpp:23:0, from /usr/src/lyx/lyx-2.0.x-git/boost/boost/function/function2.hpp:11, from /usr/src/lyx/lyx-2.0.x-git/boost/boost/signals/detail/named_slot_map.hpp:17, from /usr/src/lyx/lyx-2.0.x-git/boost/boost/signals/detail/signal_base.hpp:15, from /usr/src/lyx/lyx-2.0.x-git/boost/boost/signals/signal_template.hpp:22, from /usr/src/lyx/lyx-2.0.x-git/boost/boost/signals/signal0.hpp:24, from /usr/src/lyx/lyx-2.0.x-git/boost/boost/signal.hpp:27, from /usr/src/lyx/lyx-2.0.x-git/src/support/ForkedCalls.h:19, from /usr/src/lyx/lyx-2.0.x-git/src/support/ForkedCalls.cpp:17: /usr/src/lyx/lyx-2.0.x-git/boost/boost/function/function_template.hpp: In instantiation of ‘static void boost::detail::function::void_function_obj_invoker2::invoke(boost::detail::function::function_buffer&, T0, T1) [with FunctionObj = std::tr1::_Bind, std::tr1::_Placeholder<2>))(int, int)>; R = void; T0 = int; T1 = int]’: /usr/src/lyx/lyx-2.0.x-git/boost/boost/function/function_template.hpp:937:38: required from ‘void boost::function2::assign_to(Functor) [with Functor = std::tr1::_Bind, std::tr1::_Placeholder<2>))(int, int)>; R = void; T0 = int; T1 = int]’ /usr/src/lyx/lyx-2.0.x-git/boost/boost/function/function_template.hpp:727:7: required from ‘boost::function2::function2(Functor, typename boost::enable_if_c<(! boost::is_integral::value), int>::type) [with Functor = std::tr1::_Bind, std::tr1::_Placeholder<2>))(int, int)>; R = void; T0 = int; T1 = int; typename boost::enable_if_c<(! boost::is_integral::value), int>::type = int]’ /usr/src/lyx/lyx-2.0.x-git/boost/boost/function/function_template.hpp:1073:16: required from ‘boost::function::function(Functor, typename boost::enable_if_c<(! boost::is_integral::value), int>::type) [with Functor = std::tr1::_Bind, std::tr1::_Placeholder<2>))(int, int)>; R = void; T0 = int; T1 = int; typename boost::enable_if_c<(! boost::is_integral::value), int>::type = int]’ /usr/src/lyx/lyx-2.0.x-git/boost/boost/signals/slot.hpp:111:122: required from ‘boost::slot::slot(const F&) [with F = std::tr1::_Bind, std::tr1::_Placeholder<2>))(int, int)>; SlotFunction = boost::function]’ /usr/src/lyx/lyx-2.0.x-git/src/support/ForkedCalls.cpp:562:67: required from here /usr/src/lyx/lyx-2.0.x-git/boost/boost/function/function_template.hpp:159:57: error: no match for call to ‘(std::tr1::_Bind, std::tr1::_Placeholder<2>))(int, int)
Re: [PATCH] Re: Update boost in 2.1 branch?
Le 21/01/2016 22:40, Richard Heck a écrit : On 01/21/2016 04:07 PM, Pavel Sanda wrote: I guess it also depends how much space for error we have... Richard, do you plan to release one intermediate 2.1.x or you just waiting for the final one? How far out do we realistically think 2.2.0 is? I am thinking end of February, but if it gets delayed any further we might think about an intermediate release. Really, I should have done 2.1.5 back at the end of November, but I thought 2.2 was closer. One solution would be to have a 2.1.5 together with 2.2beta with an updated lyx2lyx that reads 2.2beta format. A good occasion to make people exercise this code. And then 2.1.6 would just be the usual final version. JMarc
Re: [PATCH] Re: Update boost in 2.1 branch?
On Thu, Jan 21, 2016 at 04:40:56PM -0500, Richard Heck wrote: > On 01/21/2016 04:07 PM, Pavel Sanda wrote: > > Jean-Marc Lasgouttes wrote: > >> So is it a problem that compiling in C++11 mode is broken with gcc 4.6? I > >> would guess not. > > I guess it also depends how much space for error we have... > > Richard, do you plan to release one intermediate 2.1.x or you just waiting > > for the final one? > > How far out do we realistically think 2.2.0 is? I am thinking end of > February, but if it gets delayed any further we might think about an > intermediate release. I think end of February is realistic. Beta should be soon, just need Guillaume's set of patches to git a final review, and Georg also is trying to look into an issue that Stephan has reported. After beta I do not think developers are planning many non-trivial commits so whether we achieve end of February for a final release will depend on what issues our beta testers find and on how long it takes us to fix those issues. Scott signature.asc Description: PGP signature
Re: [PATCH] Re: Update boost in 2.1 branch?
On 01/21/2016 04:07 PM, Pavel Sanda wrote: > Jean-Marc Lasgouttes wrote: >> So is it a problem that compiling in C++11 mode is broken with gcc 4.6? I >> would guess not. > I guess it also depends how much space for error we have... > Richard, do you plan to release one intermediate 2.1.x or you just waiting > for the final one? How far out do we realistically think 2.2.0 is? I am thinking end of February, but if it gets delayed any further we might think about an intermediate release. Really, I should have done 2.1.5 back at the end of November, but I thought 2.2 was closer. Richard
Re: [PATCH] Re: Update boost in 2.1 branch?
Jean-Marc Lasgouttes wrote: > So is it a problem that compiling in C++11 mode is broken with gcc 4.6? I > would guess not. I guess it also depends how much space for error we have... Richard, do you plan to release one intermediate 2.1.x or you just waiting for the final one? Pavel
[PATCH] Re: Update boost in 2.1 branch?
Le 14/01/2016 19:12, Jean-Marc Lasgouttes a écrit :
Le 09/01/2016 00:50, Richard Heck a écrit :
On 01/08/2016 05:06 AM, Jean-Marc Lasgouttes wrote:
Currently we use boost 1.53 in 2.1 branch. Would it be a good move to
update it to 1.60? I am getting loads of warnings with gcc 5.1.
Fine with me, and I see the same warnings.
OK, I pushed it.
Sigh. Now that I can test it with an older compiler (gcc 4.6, Ubuntu
12.04) I find that it does not compile in C++98 mode because of
boost::next/prior. This has been fixed already in master, so I
cherry-picked the commits (see attached).
Yet, if I compile in C++11 mode I have issues with some tr1 code in
ForkedCalls.cpp. We could cherry pick the code that removes tr1 support,
but this is getting a bit too much for my taste.
My analysis is that updating our local boost library makes sense because
at least Linux distribution want to compile with installed boost, and
this may be a new one. We want the final 2.1 version to compile as long
as possible.
So is it a problem that compiling in C++11 mode is broken with gcc 4.6?
I would guess not.
So with the patch the Linux summary is as below. I tried to compile
with/without c++11 and with/without included boost
gcc 4.6: OK except c++11 and included boost.
gcc 5.2: all OK
clang 3.6 with libstdc++: all OK
clang 3.6 with libc++: not OK because the code insists on using TR1,
which does not make sense.
Does this last case correspond to recent mac systems? What shall we do
from there?
JMarc
>From 6b5e887909e2422443449654e5aeca0221d27dd7 Mon Sep 17 00:00:00 2001
From: Georg Baum
Date: Sat, 16 May 2015 00:05:23 +0200
Subject: [PATCH] Fix compilation with boost 1.60
Newer boost versions use complicated type traits for boost::next and
boost::prior, which do not work with the RandomAccessList iterators.
The long term solution is to use std::next and std::prev, for now supply
simple replacements for compilers that do not support C++11 yet.
This is was cherry picked from b5963300 and 7e72c1d0d3.
---
boost/extract.sh|1 -
src/Compare.cpp |9 -
src/Cursor.cpp |2 +-
src/CutAndPaste.cpp | 10 +-
src/FontList.cpp|6 ++
src/Text.cpp| 13 ++---
src/Text2.cpp |9 -
src/Text3.cpp |9 -
src/lyxfind.cpp |1 -
src/mathed/MathData.cpp |4 ++--
src/output_docbook.cpp |7 +++
src/output_latex.cpp| 11 +--
src/support/lyxalgo.h | 26 ++
13 files changed, 62 insertions(+), 46 deletions(-)
diff --git a/boost/extract.sh b/boost/extract.sh
index dbe280b..297cbc5 100755
--- a/boost/extract.sh
+++ b/boost/extract.sh
@@ -29,7 +29,6 @@ bcp --boost=$1 \
boost/function.hpp \
boost/functional.hpp \
boost/lexical_cast.hpp \
- boost/next_prior.hpp \
boost/noncopyable.hpp \
boost/regex.hpp \
boost/scoped_array.hpp \
diff --git a/src/Compare.cpp b/src/Compare.cpp
index 1d72ebf..326eba2 100644
--- a/src/Compare.cpp
+++ b/src/Compare.cpp
@@ -19,11 +19,10 @@
#include "insets/InsetText.h"
-#include "support/lassert.h"
+#include "support/lassert.h"
+#include "support/lyxalgo.h"
#include "support/qstring_helpers.h"
-#include
-
using namespace std;
using namespace lyx::support;
@@ -420,8 +419,8 @@ static void getParagraphList(DocRange const & range,
pit_type startpit = range.from.pit();
pit_type endpit = range.to.pit();
ParagraphList const & ps_ = range.text()->paragraphs();
- ParagraphList tmp_pars(boost::next(ps_.begin(), startpit),
- boost::next(ps_.begin(), endpit + 1));
+ ParagraphList tmp_pars(lyx::next(ps_.begin(), startpit),
+ lyx::next(ps_.begin(), endpit + 1));
// Remove the end of the last paragraph; afterwards, remove the
// beginning of the first paragraph. Keep this order - there may only
diff --git a/src/Cursor.cpp b/src/Cursor.cpp
index aed1414..746f980 100644
--- a/src/Cursor.cpp
+++ b/src/Cursor.cpp
@@ -132,7 +132,7 @@ bool bruteFind(Cursor & cursor,
// Get an iterator after the last paragraph in the cache
DocIterator et(inset);
et.push_back(CursorSlice(inset));
- et.pit() = boost::prior(cache.end())->first;
+ et.pit() = lyx::prev(cache.end(), 1)->first;
if (et.pit() >= et.lastpit())
et = doc_iterator_end(inset);
else
diff --git a/src/CutAndPaste.cpp b/src/CutAndPaste.cpp
index e2ccf39..185cf79 100644
--- a/src/CutAndPaste.cpp
+++ b/src/CutAndPaste.cpp
@@ -60,13 +60,13 @@
#include "support/lassert.h"
#include "support/limited_stack.h"
#include "support/lstrings.h"
+#include "support/lyxalgo.h"
#include "frontends/alert.h"
#include "frontends/Clipboard.h"
#include "frontends/Selection.h"
#include
-#include
#include
@@ -383,7 +383,7 @@ pasteSelectionHelper(DocIterator const & cur, ParagraphList const & parlist,
// Paste it!
if (empty) {
- pars.insert(boost::next(pars.begin(), pit),
+ pars.insert(lyx::next(pars.beg
Re: Update boost in 2.1 branch?
Le 09/01/2016 00:50, Richard Heck a écrit : On 01/08/2016 05:06 AM, Jean-Marc Lasgouttes wrote: Currently we use boost 1.53 in 2.1 branch. Would it be a good move to update it to 1.60? I am getting loads of warnings with gcc 5.1. Fine with me, and I see the same warnings. OK, I pushed it. JMarc
Re: Update boost in 2.1 branch?
Le 11/01/2016 20:53, Georg Baum a écrit : The few times I did run that script it worked fine. If you look at a few files in the diff and see no peculiar change I'd say it is safe to commit. One thing we should keep in mind is that this would also produce a 3 MB 2.1.4->2.1.5 patch. Richard, is the 3MB patch a problem to you? I think it is a good idea to upgrade 2.1 boost version, so that we know that it compiles better in the future. JMarc
Re: Update boost in 2.1 branch?
Jean-Marc Lasgouttes wrote: > I ran the extract.sh script, and have a 3MB commit. Is that to be > expected? It compiles without warning (using a small additional fix). > > Shall I just push it? Does someone want to see it or have a go at it? The few times I did run that script it worked fine. If you look at a few files in the diff and see no peculiar change I'd say it is safe to commit. One thing we should keep in mind is that this would also produce a 3 MB 2.1.4->2.1.5 patch. Georg
Re: Update boost in 2.1 branch?
Le 09/01/2016 00:50, Richard Heck a écrit : On 01/08/2016 05:06 AM, Jean-Marc Lasgouttes wrote: Currently we use boost 1.53 in 2.1 branch. Would it be a good move to update it to 1.60? I am getting loads of warnings with gcc 5.1. Fine with me, and I see the same warnings. I ran the extract.sh script, and have a 3MB commit. Is that to be expected? It compiles without warning (using a small additional fix). Shall I just push it? Does someone want to see it or have a go at it? I attach just the stats below. JMarc commit 3ebe735cc32571c025e4c0ee4614761746c465ea Author: Jean-Marc Lasgouttes Date: Mon Jan 11 11:54:28 2016 +0100 Update to boost 1.60 Also fix a warning by backporting 43d75a07. boost/boost/align/align.hpp| 20 + boost/boost/align/detail/address.hpp | 29 + boost/boost/align/detail/align.hpp | 40 + boost/boost/align/detail/align_cxx11.hpp | 22 + boost/boost/align/detail/is_alignment.hpp | 29 + boost/boost/aligned_storage.hpp| 181 -- boost/boost/any.hpp| 184 +- boost/boost/assert.hpp | 112 +- boost/boost/bind.hpp | 19 +- boost/boost/bind/arg.hpp | 10 +- boost/boost/bind/bind.hpp | 509 +++- boost/boost/bind/bind_mf_cc.hpp| 214 ++ boost/boost/bind/placeholders.hpp | 65 +- boost/boost/call_traits.hpp|6 +- boost/boost/checked_delete.hpp | 78 +- boost/boost/concept/assert.hpp |3 +- boost/boost/concept/detail/concept_def.hpp | 17 - boost/boost/concept/detail/general.hpp |4 +- boost/boost/concept/detail/msvc.hpp|9 + boost/boost/concept/usage.hpp |8 - boost/boost/concept_check.hpp | 51 +- boost/boost/config.hpp | 21 +- boost/boost/config/auto_link.hpp | 18 +- boost/boost/config/compiler/borland.hpp| 43 +- boost/boost/config/compiler/clang.hpp | 147 +- boost/boost/config/compiler/codegear.hpp | 43 +- boost/boost/config/compiler/common_edg.hpp | 58 +- boost/boost/config/compiler/cray.hpp | 39 +- boost/boost/config/compiler/digitalmars.hpp| 53 +- boost/boost/config/compiler/gcc.hpp| 230 +- boost/boost/config/compiler/gcc_xml.hpp| 47 +- boost/boost/config/compiler/hp_acc.hpp | 23 +- boost/boost/config/compiler/intel.hpp | 391 ++- boost/boost/config/compiler/metrowerks.hpp | 55 +- boost/boost/config/compiler/mpw.hpp| 43 +- boost/boost/config/compiler/nvcc.hpp | 12 - boost/boost/config/compiler/pathscale.hpp | 40 +- boost/boost/config/compiler/pgi.hpp| 39 +- boost/boost/config/compiler/sunpro_cc.hpp | 87 +- boost/boost/config/compiler/vacpp.hpp | 62 +- boost/boost/config/compiler/visualc.hpp| 246 +- boost/boost/config/compiler/xlcpp.hpp | 258 ++ boost/boost/config/platform/cloudabi.hpp | 18 + boost/boost/config/platform/haiku.hpp | 31 + boost/boost/config/platform/linux.hpp |2 + boost/boost/config/platform/macos.hpp |2 +- boost/boost/config/platform/solaris.hpp|5 +- boost/boost/config/platform/vxworks.hpp| 368 ++- boost/boost/config/platform/win32.hpp | 31 +- boost/boost/config/select_compiler_config.hpp | 58 +- boost/boost/config/select_platform_config.hpp | 32 + boost/boost/config/select_stdlib_config.hpp| 36 +- boost/boost/config/stdlib/dinkumware.hpp | 73 +- boost/boost/config/stdlib/libcomo.hpp | 15 +- boost/boost/config/stdlib/libcpp.hpp | 43 + boost/boost/config/stdlib/libstdcpp3.hpp | 144 +- boost/boost/config/stdlib/modena.hpp | 13 + boost/boost/config/stdlib/msl.hpp | 22 +- boost/boost/config/stdlib/roguewave.hpp| 12 + boost/boost/config/stdlib/sgi.hpp | 18 +- boost/boost/config/stdlib/stlport.hpp | 21 +- boost/boost/config/stdlib/vacpp.hpp| 16 +- boost/boost/config/suffix.hpp | 243 +- boost/boost/config/user.hpp| 21 +- boost/boost/container/container_fwd.hpp| 246 +- boost/boost/container/detail/std_fwd.hpp | 56 + boost/boost/core/addressof.hpp | 162 ++ boost/boost/core/checked_delete.hpp| 69 + boost/boost/core/demangle.hpp | 128 + boost/b
Re: Update boost in 2.1 branch?
On 01/08/2016 05:06 AM, Jean-Marc Lasgouttes wrote: > > Currently we use boost 1.53 in 2.1 branch. Would it be a good move to > update it to 1.60? I am getting loads of warnings with gcc 5.1. Fine with me, and I see the same warnings. Richard
Update boost in 2.1 branch?
Currently we use boost 1.53 in 2.1 branch. Would it be a good move to update it to 1.60? I am getting loads of warnings with gcc 5.1. JMarc
