Well, did we try to run/compile it with 3.3? I would state only things
we positively know to work. But we could note on which minimal clang version
it was tested without claiming it's the minimal required version.
Pavel
Sorry, but I have no access to machine with such old Clang to test. So I
Le 16/11/2020 à 13:40, Pavel Sanda a écrit :
On Mon, Nov 16, 2020 at 09:26:58AM +0200, Yuriy Skalko wrote:
I'm not sure about section to add this. Please amend the attached patch.
Please commit your version, IMHO the requirements belong to
INSTALL/README. Pavel
What about specifying also
Le 16/11/2020 à 13:40, Pavel Sanda a écrit :
On Mon, Nov 16, 2020 at 09:26:58AM +0200, Yuriy Skalko wrote:
I'm not sure about section to add this. Please amend the attached patch.
Please commit your version, IMHO the requirements belong to
INSTALL/README. Pavel
What about specifying also
On Mon, Nov 16, 2020 at 09:26:58AM +0200, Yuriy Skalko wrote:
> >>I'm not sure about section to add this. Please amend the attached patch.
> >
> >Please commit your version, IMHO the requirements belong to
> >INSTALL/README. Pavel
>
> What about specifying also version for Clang? Minimal version
I'm not sure about section to add this. Please amend the attached patch.
Please commit your version, IMHO the requirements belong to INSTALL/README.
Pavel
What about specifying also version for Clang? Minimal version with full
C++11 support is 3.3 (https://clang.llvm.org/cxx_status.html).
On Sun, Nov 15, 2020 at 10:55:17PM +0100, Pavel Sanda wrote:
> On Sun, Nov 15, 2020 at 10:49:43PM +0200, Yuriy Skalko wrote:
> > I'm not sure about section to add this. Please amend the attached patch.
>
> Please commit your version, IMHO the requirements belong to INSTALL/README.
> Pavel
OK
On Sun, Nov 15, 2020 at 10:49:43PM +0200, Yuriy Skalko wrote:
> I'm not sure about section to add this. Please amend the attached patch.
Please commit your version, IMHO the requirements belong to INSTALL/README.
Pavel
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
On Sun, Nov 15, 2020 at 09:59:57PM +0100, Jean-Marc Lasgouttes wrote:
> to work in older gcc versions, I can add them to the autoconf test. I am not
> sure that it is worth blocking gcc 4.7 in autoconf.
I don't see any need for that. Pavel
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
Le 15/11/2020 à 20:53, Scott Kostyshak a écrit :
I think that for LyX 2.4 is reasonable to bump at least to gcc 4.8, because
4.7 does not have full support for C++11 yet. I am personally compiling
with 4.9, so unless someone trumps me with lower version we should state
4.9 in README.
+1
we
I cannot reproduce this in my GCC 7.3 even in C++11 mode (by default it
compiles in C++17 with CMake build). Please check if this helps:
This helps indeed.
Committed.
By the way, what is the oldest supported GCC? README says it is GCC 4.7. Is
it right?
I think that for LyX 2.4 is
On Sun, Nov 15, 2020 at 08:41:24PM +0100, Pavel Sanda wrote:
> On Sun, Nov 15, 2020 at 06:00:14PM +0200, Yuriy Skalko wrote:
> > >Yuriy,
> > >this fails on older gccs, could you have a look?
> >
> > I cannot reproduce this in my GCC 7.3 even in C++11 mode (by default it
> > compiles in C++17 with
On Sun, Nov 15, 2020 at 06:00:14PM +0200, Yuriy Skalko wrote:
> >Yuriy,
> >this fails on older gccs, could you have a look?
>
> I cannot reproduce this in my GCC 7.3 even in C++11 mode (by default it
> compiles in C++17 with CMake build). Please check if this helps:
This helps indeed.
> By the
On Sun, Nov 15, 2020 at 06:00:14PM +0200, Yuriy Skalko wrote:
> > Yuriy,
> > this fails on older gccs, could you have a look?
>
> I cannot reproduce this in my GCC 7.3 even in C++11 mode (by default it
> compiles in C++17 with CMake build). Please check if this helps:
Just adding another data
Yuriy,
this fails on older gccs, could you have a look?
I cannot reproduce this in my GCC 7.3 even in C++11 mode (by default it
compiles in C++17 with CMake build). Please check if this helps:
diff --git a/src/support/Changer.h b/src/support/Changer.h
index 19a6b9a0cb..4c79052665 100644
---
On Thu, Nov 12, 2020 at 02:21:21PM +0200, Yuriy Skalko wrote:
> >I still prefer noChange() or nullChange() to changeNone(), but we would have
> >to ask a native English speaker.
>
> I proposed `changeNone` to have consistent naming for all change`Something`
> functions. But noChange is also
Le 12/11/2020 à 13:21, Yuriy Skalko a écrit :
Not a problem. Good naming can make code really intuitive and easy to
understand. It is worth to spend some time on this.
I've committed the updated patch.
Thanks.
JMarc
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
I still prefer noChange() or nullChange() to changeNone(), but we would have to
ask a native English speaker.
I proposed `changeNone` to have consistent naming for all
change`Something` functions. But noChange is also good. If there will be
any comments from native speakers, it can be
Le 12/11/2020 à 00:33, Yuriy Skalko a écrit :
Since LyX uses primarily camelCase names, I renamed it to changeNone()
and make_change(ref, val) to changeRef(ref, val). Is it good enough?
I still prefer noChange() or nullChange() to changeNone(), but we would
have to ask a native English
2020 01:16:33 +0200
Subject: [PATCH] Simplify Changers
---
src/FontInfo.cpp| 9 ++--
src/MetricsInfo.cpp | 20 -
src/TextMetrics.cpp | 6 +--
src/insets/InsetCollapsible.cpp | 8 ++--
src/insets/InsetText.cpp| 6 +--
src/mathed
in
client code for no-change cases.
I've tried to simplify and make Changers implementation more consistent
and located in one place. Please check the attached patch.
Why not, I like the idea of having everything in the same header. Then I
would rename make_change() to no_change() and even
to simplify and make Changers implementation more consistent
and located in one place. Please check the attached patch.
Yuriy
From f106663644174b924f0782ef99aac992bbd8f933 Mon Sep 17 00:00:00 2001
From: Yuriy Skalko
Date: Wed, 11 Nov 2020 12:10:41 +0200
Subject: [PATCH 1/2] Simplify
21 matches
Mail list logo
