On Mon, Dec 28, 2020 at 09:12:05PM +0200, Yuriy Skalko wrote:
> > Tried at ab7ac800. At least it should be compilable with any c++ compiler.
> >
> > Kornel
>
> Now LyX can be successfully compiled with C++20 compiler. The attached patch
> fixes C++20-specific deprecation warning (`this`
Am Tue, 29 Dec 2020 00:44:25 +0100
schrieb Jean-Marc Lasgouttes :
> Le 28 décembre 2020 19:04:35 GMT+01:00, "Jürgen Spitzmüller"
> a écrit :
> >Am Montag, dem 28.12.2020 um 19:00 +0100 schrieb Pavel Sanda:
> >> But this position gets weaker as we do not seem to get closer to the
> >> actual
Le 28 décembre 2020 21:29:02 GMT+01:00, Pavel Sanda a écrit :
>It's hard to believe, but looking back at the archives we had the 2.4
>release-manager decision in May 2019 and first alpha1 thread in June 2019 :)
>
>JMarc, what is your situation nowadays? Is it still feasible for you
>to do the
Le 28 décembre 2020 19:04:35 GMT+01:00, "Jürgen Spitzmüller" a
écrit :
>Am Montag, dem 28.12.2020 um 19:00 +0100 schrieb Pavel Sanda:
>> But this position gets weaker as we do not seem to get closer to the
>> actual release, I know.
>
>This is what we should really aim at, actually (independent
On 12/28/20 2:12 PM, Yuriy Skalko wrote:
>> Tried at ab7ac800. At least it should be compilable with any c++
>> compiler.
>>
>> Kornel
>
> Now LyX can be successfully compiled with C++20 compiler. The attached
> patch fixes C++20-specific deprecation warning (`this` in lambdas must
> be
On Mon, Dec 28, 2020 at 09:20:26PM +0200, Yuriy Skalko wrote:
> As I see we already have latest 1.2.11 in master branch. So I'm committing
> the patch.
Indeed, oversight on my side... P
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
On Mon, Dec 28, 2020 at 07:04:35PM +0100, Jürgen Spitzmüller wrote:
> Am Montag, dem 28.12.2020 um 19:00 +0100 schrieb Pavel Sanda:
> > But this position gets weaker as we do not seem to get closer to the
> > actual release, I know.
>
> This is what we should really aim at, actually (independent
On Mon, 28 Dec 2020 at 19:04, Jürgen Spitzmüller wrote:
> Am Montag, dem 28.12.2020 um 19:00 +0100 schrieb Pavel Sanda:
> > But this position gets weaker as we do not seem to get closer to the
> > actual release, I know.
>
> This is what we should really aim at, actually (independent of the qt
>
Looks like a good idea. Note that we have in our tree zlib 1.2.8; dunno
what part of the code is using it, but there have been several bugfix
releases since then (currently 1.2.11).
Pavel
As I see we already have latest 1.2.11 in master branch. So I'm
committing the patch.
Yuriy
--
On Mon, 28 Dec 2020 at 19:33, Jean-Marc Lasgouttes
wrote:
> Le 26 décembre 2020 20:07:19 GMT+01:00, Thibaut Cuvelier <
> tcuvel...@lyx.org> a écrit :
>>
>> Dear list,
>>
>> In https://www.lyx.org/trac/ticket/12055, there was some confusion about
>> the name of the streams used to output math:
Tried at ab7ac800. At least it should be compilable with any c++ compiler.
Kornel
Now LyX can be successfully compiled with C++20 compiler. The attached
patch fixes C++20-specific deprecation warning (`this` in lambdas must
be captured explicitly), it should not affect earlier C++
Le 26 décembre 2020 20:07:19 GMT+01:00, Thibaut Cuvelier a
écrit :
>Dear list,
>
>In https://www.lyx.org/trac/ticket/12055, there was some confusion about
>the name of the streams used to output math: there is OctaveStream for
>Octave, MathematicaStream for Mathematica, etc., but MathStream for
Le 27 décembre 2020 22:44:28 GMT+01:00, Pavel Sanda a écrit :
>On Sat, Dec 19, 2020 at 11:08:40PM +0200, Yuriy Skalko wrote:
>> Yes, boost's `assert` is not encapsulated, but `crc` and `any` are.
>>
>> I've moved all into `lyx` namespace. Really separate namespace for only 3
>> names is not
Am Montag, dem 28.12.2020 um 19:00 +0100 schrieb Pavel Sanda:
> But this position gets weaker as we do not seem to get closer to the
> actual release, I know.
This is what we should really aim at, actually (independent of the qt
question).
Also, I seemed to remember that there was reluctance
On Mon, Dec 28, 2020 at 06:51:42PM +0100, Thibaut Cuvelier wrote:
> > So the question is: Can we drop support for QT4 in master?
> > Or has someone a better sollution?
> >
>
> Given that Qt 6 is now out, and that Qt 4 has been unmaintained for roughly
> five years (
>
On Mon, 28 Dec 2020 at 18:48, Kornel Benko wrote:
> We use utf-8 encoded strings.
> In order to fully use regular expressions in FindAdv, we need the created
> regex be case
> sensitive. This works good for ascii charaters, but fails on
>
> The try to use docstring works better on unix systems.
We use utf-8 encoded strings.
In order to fully use regular expressions in FindAdv, we need the created regex
be case
sensitive. This works good for ascii charaters, but fails on
The try to use docstring works better on unix systems. But there are some
problems.
1.) regexes are still unable to
On 12/28/20 12:03 PM, Pavel Sanda wrote:
> On Mon, Dec 28, 2020 at 04:16:36PM +0200, Yuriy Skalko wrote:
>> zlib has implementation of crc32 algorithm, I've used it instead of Boost's
>> one.
>> Now another part of Boost can be thrown away :)
> Looks like a good idea. Note that we have in our tree
Am Mon, 28 Dec 2020 12:08:00 +0200
schrieb Yuriy Skalko :
> Recently I've had necessity to install latest stable GCC version 10.2
> that has C++20 support. So I didn't miss the opportunity to try
> compiling LyX in C++20 mode too.
>
> The only compilation error is due to recent commit
On Mon, Dec 28, 2020 at 04:16:36PM +0200, Yuriy Skalko wrote:
> zlib has implementation of crc32 algorithm, I've used it instead of Boost's
> one.
> Now another part of Boost can be thrown away :)
Looks like a good idea. Note that we have in our tree zlib 1.2.8; dunno
what part of the code is
On Mon, Dec 28, 2020 at 04:20:16PM +0200, Yuriy Skalko wrote:
> From 4f38e801eb930ca70b6a086f0aa553e1d19b21a3 Mon Sep 17 00:00:00 2001
> From: Yuriy Skalko
> Date: Tue, 22 Dec 2020 12:14:00 +0200
> Subject: [PATCH 6/7] Update Doxygen options to have more dependency graphs
>
> Now many graphs are
From 4f38e801eb930ca70b6a086f0aa553e1d19b21a3 Mon Sep 17 00:00:00 2001
From: Yuriy Skalko
Date: Tue, 22 Dec 2020 12:14:00 +0200
Subject: [PATCH 6/7] Update Doxygen options to have more dependency graphs
Now many graphs are not generated due to excessive dependencies
(default node limit for one
zlib has implementation of crc32 algorithm, I've used it instead of
Boost's one.
Now another part of Boost can be thrown away :)
Yuriy
From ec7563f53dc84f80bef4ba067a61d7ec5a9d4bac Mon Sep 17 00:00:00 2001
From: Yuriy Skalko
Date: Sat, 26 Dec 2020 21:23:44 +0200
Subject: [PATCH 7/7] Use crc32
Here is an update to my previous patch. I've separated it into several
patches. The next step will be moving `string2params` into InsetParams.
Please review these patches.
Yuriy
From f8a2c8a143bd54cec1da51b611e0a66c4af3305e Mon Sep 17 00:00:00 2001
From: Yuriy Skalko
Date: Sun, 6 Dec 2020
> I am sorry not to have a time to follow this thoroughly, but is this
> cvs log / git log used only inh "register" case as initially discussed
> or you want to use it on every file load?
> Calling log could but pretty expensive operation for large archives.
The -n0 flag that Yuriy proposed
Le 09/12/2020 à 10:00, Yuriy Skalko a écrit :
But now Trac works without any server maintainer, right? As I understand
Gitea don't require much maintenance. Upgrading it is just replacing one binary
and restarting (I have done this several times without any issues) If there is
interest
Recently I've had necessity to install latest stable GCC version 10.2
that has C++20 support. So I didn't miss the opportunity to try
compiling LyX in C++20 mode too.
The only compilation error is due to recent commit 2d2e2f1c6d. These u8
string literals have incompatible type:
27 matches
Mail list logo
