Re: Patches

On Thu, Jun 15, 2023 at 08:07:33AM +0200, Daniel wrote: > > On 2023-06-14 12:33, Scott Kostyshak wrote: > > On Wed, Jun 14, 2023 at 07:15:27AM +0200, Daniel wrote: > > > > > > Dear developers, > > > > > > I have decided to try to make fewer (if any) patches and rather only > > > suggest > > > i

Re: Patches

On 2023-06-14 12:33, Scott Kostyshak wrote: On Wed, Jun 14, 2023 at 07:15:27AM +0200, Daniel wrote: Dear developers, I have decided to try to make fewer (if any) patches and rather only suggest improvements at least for now. This is driven by a number of personal factors. But also that I have

Re: Patches

On Wed, Jun 14, 2023 at 07:15:27AM +0200, Daniel wrote: > > Dear developers, > > I have decided to try to make fewer (if any) patches and rather only suggest > improvements at least for now. > > This is driven by a number of personal factors. But also that I have made > the experience that most

Re: Patches for Python scripts

On Mon, 1 Feb 2021 at 15:31, José Abílio Matos wrote: > On Monday, February 1, 2021 2:42:43 AM WET Thibaut Cuvelier wrote: > > > More generally, what about the other patches? Are formatting changes > > > considered risky? What about Joel's suggestions? > > My issue is not about the formatting cha

Re: Patches for Python scripts

On Monday, February 1, 2021 2:42:43 AM WET Thibaut Cuvelier wrote: > More generally, what about the other patches? Are formatting changes > considered risky? What about Joel's suggestions? My issue is not about the formatting changes, I can live with them even if in some cases I think that it is

Re: Patches for Python scripts

On Mon, Feb 01, 2021 at 03:42:43AM +0100, Thibaut Cuvelier wrote: > Thank you for testing on your side :)! What's frustrating with your report > is that this bug can only appear on Python 2, and that it will very likely > be dropped for the next release (I remember seeing people wanting to keep > i

Re: Patches for Python scripts

On Sun, 31 Jan 2021 at 12:39, Enrico Forestieri wrote: > On Sun, Jan 31, 2021 at 04:22:39AM +0100, Thibaut Cuvelier wrote: > > On Sat, 30 Jan 2021 at 12:26, Enrico Forestieri wrote: > > > On Sat, Jan 30, 2021 at 05:31:05AM +0100, Thibaut Cuvelier wrote: > > > > On Sat, 30 Jan 2021 at 02:31, Enri

Re: Patches for Python scripts

On Sun, Jan 31, 2021 at 04:22:39AM +0100, Thibaut Cuvelier wrote: > On Sat, 30 Jan 2021 at 12:26, Enrico Forestieri wrote: > > On Sat, Jan 30, 2021 at 05:31:05AM +0100, Thibaut Cuvelier wrote: > > > On Sat, 30 Jan 2021 at 02:31, Enrico Forestieri wrote: > > > > > > > > So, it seems that you have

Re: Patches for Python scripts

On Sat, 30 Jan 2021 at 12:26, Enrico Forestieri wrote: > On Sat, Jan 30, 2021 at 05:31:05AM +0100, Thibaut Cuvelier wrote: > > On Sat, 30 Jan 2021 at 02:31, Enrico Forestieri wrote: > > > > > > So, it seems that you have to check also for the 32-bit version. > > > > > Indeed. Would the attached

Re: Patches for Python scripts

On Sat, Jan 30, 2021 at 05:31:05AM +0100, Thibaut Cuvelier wrote: > On Sat, 30 Jan 2021 at 02:31, Enrico Forestieri wrote: > > > > So, it seems that you have to check also for the 32-bit version. > > > Indeed. Would the attached patch solve the problem? I first look for a > 64-bit version before a

Re: Patches for Python scripts

On Sat, 30 Jan 2021 at 02:31, Enrico Forestieri wrote: > On Fri, Jan 29, 2021 at 11:40:29PM +0100, Thibaut Cuvelier wrote: > > Hi Thibaut, > > > - This way to find Java is quite common on Windows platforms (actually, > > it's a lot like a port of JavaCall.jl's relevant portion of code: > > https:

Re: Patches for Python scripts

On Fri, Jan 29, 2021 at 3:40 PM Thibaut Cuvelier wrote: > - The cosmetic changes are based on PEP8, which is the only style guide > for Python. Highly similar patches already went into the code base less > than a year ago ( > http://lists.lyx.org/pipermail/lyx-devel/2020-May/001464.html). Other >

Re: Patches for Python scripts

On Fri, Jan 29, 2021 at 11:40:29PM +0100, Thibaut Cuvelier wrote: Hi Thibaut, > - This way to find Java is quite common on Windows platforms (actually, > it's a lot like a port of JavaCall.jl's relevant portion of code: > https://github.com/JuliaInterop/JavaCall.jl). It looks like Oracle's JVM >

Re: Patches for Python scripts

On 1/29/21 7:39 AM, Pavel Sanda wrote: > On Fri, Jan 29, 2021 at 11:07:43AM +, José Abílio Matos wrote: >> With the extent of the patches I fear that there could be bugs (unintended >> changes) lurking specially in relation to python 2. > Riki's call, but I don't think this is the best time fo

Re: Patches for Python scripts

I will be answering most concerns here, in no particular order. I think it will simplify the next messages. - This is far from an overhaul of the script. The logic did not really change, neither the code structure. I have ideas on how to do it, and I could do it if you are OK with it, but I comple

Re: Patches for Python scripts

Am Fri, 29 Jan 2021 13:39:19 +0100 schrieb Pavel Sanda : > On Fri, Jan 29, 2021 at 11:07:43AM +, José Abílio Matos wrote: > > With the extent of the patches I fear that there could be bugs (unintended > > changes) lurking specially in relation to python 2. > > Riki's call, but I don't thin

Re: Patches for Python scripts

On Fri, Jan 29, 2021 at 11:07:43AM +, José Abílio Matos wrote: > With the extent of the patches I fear that there could be bugs (unintended > changes) lurking specially in relation to python 2. Riki's call, but I don't think this is the best time for python scripts overhaul. Except the chang

Re: Patches for Python scripts

On Friday, January 29, 2021 11:48:40 AM WET Kornel Benko wrote: > Right, the last one should be escaped. > Given the line > # \DeclareLaTeXClass[revtex,revtex.sty]{REVTeX (Obsolete Version)} > and the original regex > > '\\s*#\\s*DeclareLaTeXClass\\s*(\[([^,]*)(,.*)*\])*\\s*{(.

Re: Patches for Python scripts

Am Fri, 29 Jan 2021 11:07:43 + schrieb José Abílio Matos : > On Friday, January 29, 2021 5:05:19 AM WET Richard Kimberly Heck wrote: > > José, can you look at these please? > > > > Riki > > I think that Thibaut wants to impose black[1] on us. :-D > > Most of the changes are cosmetic, e.g. o

Re: Patches for Python scripts

On Friday, January 29, 2021 3:51:12 AM WET Thibaut Cuvelier wrote: > Dear list, > > While working on the ePub output, I ran through many Python scripts. I > corrected a few bgs and a lot of formatting, plus one feature (find Java in > the Windows registry in configure.py), here are the patches. Ma

Re: Patches for Python scripts

On Friday, January 29, 2021 5:05:19 AM WET Richard Kimberly Heck wrote: > José, can you look at these please? > > Riki I think that Thibaut wants to impose black[1] on us. :-D Most of the changes are cosmetic, e.g. one import per line, or to use the same indentation for documentation. The only

Re: Patches for Python scripts

On 1/29/21 4:41 AM, Enrico Forestieri wrote: > On Fri, Jan 29, 2021 at 04:51:12AM +0100, Thibaut Cuvelier wrote: >> While working on the ePub output, I ran through many Python scripts. I >> corrected a few bgs and a lot of formatting, plus one feature (find Java in >> the Windows registry in config

Re: Patches for Python scripts

On Fri, Jan 29, 2021 at 04:51:12AM +0100, Thibaut Cuvelier wrote: > > While working on the ePub output, I ran through many Python scripts. I > corrected a few bgs and a lot of formatting, plus one feature (find Java in > the Windows registry in configure.py), here are the patches. May I push > the

Re: Patches for Python scripts

On 1/28/21 10:51 PM, Thibaut Cuvelier wrote: > Dear list, > > While working on the ePub output, I ran through many Python scripts. I > corrected a few bgs and a lot of formatting, plus one feature (find > Java in the Windows registry in configure.py), here are the patches. > May I push them on the

Re: Patches for Python scripts

On 1/28/21 10:51 PM, Thibaut Cuvelier wrote: > Dear list, > > While working on the ePub output, I ran through many Python scripts. I > corrected a few bgs and a lot of formatting, plus one feature (find > Java in the Windows registry in configure.py), here are the patches. > May I push them on the

Re: Patches to review

Please review next 2 patches. First one is fine. In second one, can this: @@ -1849,16 +1845,14 @@ docstring const LaTeXFeatures::getTClassPreamble() const -cit = usedInsetLayouts_.begin(); -end = usedInsetLayouts_.end(); +list::const_iterator cit = usedInsetLayouts_.begin(); +

Re: Patches to review

On 12/6/20 6:01 AM, Yuriy Skalko wrote: > Please review next 2 patches. First one is fine. In second one, can this: @@ -1849,16 +1845,14 @@ docstring const LaTeXFeatures::getTClassPreamble() const -    cit = usedInsetLayouts_.begin(); -    end = usedInsetLayouts_.end(); +    list::const_iterator

Re: Patches to review

Le 05/12/2020 à 18:05, Richard Kimberly Heck a écrit : I just wanted to leave types of the pair as visible. Probably this is not really important and the code should be shortened to your variant. I tend to agree with Yuriy here. The code is a bit longer, but you do get an explicit indication of

Re: Patches to review

On 12/5/20 11:31 AM, Yuriy Skalko wrote: >> I see they are in now, but I have a proposal (of style). I code like >> below, >> -   for (; qq != end; ++qq) { >> -   docstring const style = from_ascii(qq->first); >> -   bool langdef = (style[0] == langqs); >> - 

Re: Patches to review

I see they are in now, but I have a proposal (of style). I code like below, - for (; qq != end; ++qq) { - docstring const style = from_ascii(qq->first); - bool langdef = (style[0] == langqs); - bool globaldef = (style[0] == globalqsc); + map st

Re: Patches to review

Le 02/12/2020 à 16:32, Yuriy Skalko a écrit : Next refactoring patches. I see they are in now, but I have a proposal (of style). I code like below, - for (; qq != end; ++qq) { - docstring const style = from_ascii(qq->first); - bool langdef = (style[0] == langq

Re: Patches to review

On Wed, Dec 02, 2020 at 12:01:15PM -0500, Richard Kimberly Heck wrote: > On 12/2/20 10:32 AM, Yuriy Skalko wrote: > > Next refactoring patches. > > #1 and #3 are fine. I'll leave #4 again to Pavel and others. All patches look fine to me. Pavel -- lyx-devel mailing list lyx-devel@lists.lyx.org ht

Re: Patches to review

#1 and #3 are fine. I'll leave #4 again to Pavel and others. Thanks Riki. I'll wait to commit all at once. In #2, we have: /// who initiated the action -Origin origin_; +Origin origin_ = INTERNAL; It doesn't look as if there was a default before. It is set as defau

Re: Patches to review

On 12/2/20 10:32 AM, Yuriy Skalko wrote: Next refactoring patches. #1 and #3 are fine. I'll leave #4 again to Pavel and others. In #2, we have:      /// who initiated the action -    Origin origin_; +    Origin origin_ = INTERNAL; It doesn't look as if there was a default before. I often w

Re: Patches to review

Next refactoring patches. From 884c8270bc31208d150b444140b116374e78a479 Mon Sep 17 00:00:00 2001 From: Yuriy Skalko Date: Wed, 2 Dec 2020 00:16:55 +0200 Subject: [PATCH 1/4] Fix warnings and use range-based loop --- src/frontends/qt/Menus.cpp | 14 ++ 1 file changed, 6 insertions(+)

Re: Patches to review

They look good. JMarc Thanks, committed. Yuriy -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Patches to review

Le 30/11/2020 à 23:33, Yuriy Skalko a écrit : And here are next 4 patches. They look good. JMarc -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Patches to review

And here are next 4 patches. Yuriy From e89abcf0654343ec6090ace2bfe243809b64cabc Mon Sep 17 00:00:00 2001 From: Yuriy Skalko Date: Mon, 30 Nov 2020 18:06:12 +0200 Subject: [PATCH 1/4] Remove useless breaks --- src/insets/InsetNewpage.cpp | 8 1 file changed, 8 deletions(-) diff --git

Re: Patches to review

Looks good to me. Pavel Thanks, committed. Yuriy -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Patches to review

On Mon, Nov 30, 2020 at 12:38:36PM +0200, Yuriy Skalko wrote: > Next patches Looks good to me. Pavel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Patches to review

#1, #4, and #5 are all fine. I think #3 is fine, too, but someone who knows more about that code than I do should have a look, too. I suspect #2 is fine, as well, but Pavel may want to weigh in. 2 looks fine, 3 looks fine in principle :) Pavel Thanks for reviewing, all committed. Yuriy --

Re: Patches to review

On Fri, Nov 27, 2020 at 05:53:00PM -0500, Richard Kimberly Heck wrote: > On 11/27/20 4:43 PM, Yuriy Skalko wrote: > >>If it really isn't used, then go ahead. > >> > >>Riki > > > >Here is patch to remove it + another patches to review. > > #1, #4, and #5 are all fine. > > I think #3 is fine, too,

Re: Patches to review

On 11/27/20 4:43 PM, Yuriy Skalko wrote: If it really isn't used, then go ahead. Riki Here is patch to remove it + another patches to review. #1, #4, and #5 are all fine. I think #3 is fine, too, but someone who knows more about that code than I do should have a look, too. I suspect #2 i

Re: Patches to review

If it really isn't used, then go ahead. Riki Here is patch to remove it + another patches to review. Yuriy From a164646e24e8271950d51ccc6d889f860cddff5b Mon Sep 17 00:00:00 2001 From: Yuriy Skalko Date: Fri, 27 Nov 2020 11:09:16 +0200 Subject: [PATCH 1/5] Use range-based loops --- src/graph

Re: Patches to review

On 11/27/20 5:35 AM, Yuriy Skalko wrote: >> All the patches are fine. I have only one remark concerning >> Counters::copy. I do not understand why this is a Counters method >> _and_ it receives two Counters instances as parameters. This looks >> like a badly specified method. >> >> >> OTOH, it look

Re: Patches to review

All the patches are fine. I have only one remark concerning Counters::copy. I do not understand why this is a Counters method _and_ it receives two Counters instances as parameters. This looks like a badly specified method. OTOH, it looks like it is not used. What about removing it ? JMarc

Re: Patches to review

Le 26/11/2020 à 22:07, Yuriy Skalko a écrit : Here are next 5 patches. All the patches are fine. I have only one remark concerning Counters::copy. I do not understand why this is a Counters method _and_ it receives two Counters instances as parameters. This looks like a badly specified metho

Re: Patches to review

I do not like the removal of debug.h. It's very handy to be able to simply lyxerr while debuging without playing with includes... Pavel OK. I restored debug.h includes in headers and committed the patch. Yuriy -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listi

Re: Patches to review

This one comes from the same place. I'll adopt the same solution there. Riki Thanks for fixes. Yuriy -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Patches to review

On Tue, Nov 24, 2020 at 10:55:41PM +0100, Pavel Sanda wrote: > On Tue, Nov 24, 2020 at 04:49:59PM -0500, Richard Kimberly Heck wrote: > > On 11/24/20 4:29 PM, Yuriy Skalko wrote: > > >As for the patch 5, these null pointer dereferences happen even on opening > > >LyX manuals. It is undefined behavi

Re: Patches to review

On 11/24/20 4:55 PM, Pavel Sanda wrote: On Tue, Nov 24, 2020 at 04:49:59PM -0500, Richard Kimberly Heck wrote: On 11/24/20 4:29 PM, Yuriy Skalko wrote: As for the patch 5, these null pointer dereferences happen even on opening LyX manuals. It is undefined behavior even if it doesn't crash LyX.

Re: Patches to review

On 11/24/20 4:59 PM, Richard Kimberly Heck wrote: On 11/24/20 4:29 PM, Yuriy Skalko wrote: As for the patch 5, these null pointer dereferences happen even on opening LyX manuals. It is undefined behavior even if it doesn't crash LyX. Most likely should be fixed somewhere instead of just checki

Re: Patches to review

On 11/24/20 4:29 PM, Yuriy Skalko wrote: As for the patch 5, these null pointer dereferences happen even on opening LyX manuals. It is undefined behavior even if it doesn't crash LyX. Most likely should be fixed somewhere instead of just checking. From 234bfe70c1e2766d856257aebe7eaad8836f5976 M

Re: Patches to review

On Tue, Nov 24, 2020 at 04:49:59PM -0500, Richard Kimberly Heck wrote: > On 11/24/20 4:29 PM, Yuriy Skalko wrote: > >As for the patch 5, these null pointer dereferences happen even on opening > >LyX manuals. It is undefined behavior even if it doesn't crash LyX. Most > >likely should be fixed somew

Re: Patches to review

On 11/24/20 4:29 PM, Yuriy Skalko wrote: As for the patch 5, these null pointer dereferences happen even on opening LyX manuals. It is undefined behavior even if it doesn't crash LyX. Most likely should be fixed somewhere instead of just checking. 1-4 are fine. I'll have a look at the null poi

Re: Patches

Concerning gprof: please note that it does not take into account the code that is not instrumented, like Qt, the kernel and maybe parts of the c++ standard library. I tend to use perf on linux instead (especially through hotspot, with its awesome flamegraph feature). Often I only use my cru

Re: Patches

Le 11/11/2020 à 19:06, Richard Kimberly Heck a écrit : On 11/11/20 7:00 AM, Yuriy Skalko wrote:     My profiling results are in attached SVG. I've done scrolling through some of the manuals during profiled run. What profiler did you use? I tried to look again at the code, but could not find t

Re: Patches

On 11/11/20 7:00 AM, Yuriy Skalko wrote:     My profiling results are in attached SVG. I've done scrolling through some of the manuals during profiled run. What profiler did you use? I tried to look again at the code, but could not find the code that I believed to create a nested loop and thu

Re: Patches

I see that you've tried this, but reverted in 9e7832915f. What were the problems due to this removal? I do not remember, sorry. Looking at the mail archive did not ring a bell either. I've found some info in the ticket you referenced in recent reply to Riki: https://www.lyx.org/trac/tic

Re: Patches

Le 05/11/2020 à 11:43, Yuriy Skalko a écrit : Yes, macros implementation is really tangled. Maybe at first we can try to minimize calling updateMacros? I see that you've tried this, but reverted in 9e7832915f. What were the problems due to this removal? I do not remember, sorry. Looking at t

Re: Patches

Should I commit my recent patches into this branch? Sure. What is the way LyX project uses for updating feature branches: rebasing on master, merging master or cherry-picking needed commits? When it comes time to commit, I think people usually just rebase on master, then merge. But we have

Re: Patches

On 11/7/20 10:06 AM, Yuriy Skalko wrote: >> Toward that end, I've created a features/cleanup/updateMacros branch >> and committed a very small piece. The first step, for me, is to >> figure out how this stuff works! >> >> Riki > > Should I commit my recent patches into this branch? Sure. > What

Re: Patches

Toward that end, I've created a features/cleanup/updateMacros branch and committed a very small piece. The first step, for me, is to figure out how this stuff works! Riki Should I commit my recent patches into this branch? What is the way LyX project uses for updating feature branches: rebas

Re: Patches

On 11/6/20 11:13 AM, Richard Kimberly Heck wrote: On 11/5/20 5:43 AM, Yuriy Skalko wrote: Yes, updateMacros is a pain, it is actually a O(n^2) algorithm which kills performance for big documents. But it is a bit scary and I never dared changing it :) JMarc Yes, macros implementation is real

Re: Patches

On 11/5/20 5:43 AM, Yuriy Skalko wrote: Yes, updateMacros is a pain, it is actually a O(n^2) algorithm which kills performance for big documents. But it is a bit scary and I never dared changing it :) JMarc Yes, macros implementation is really tangled. Maybe at first we can try to minimize

Re: Patches

On 11/2/20 7:05 PM, Jean-Marc Lasgouttes wrote: > Le 02/11/2020 à 22:56, Richard Kimberly Heck a écrit : >> I have been thinking just a bit about this and wonder how plausible >> it is to separate out those elements of the Counter class that are >> per-Buffer (or, at least, document set) and those

Re: Patches

Le 02/11/2020 à 22:56, Richard Kimberly Heck a écrit : I have been thinking just a bit about this and wonder how plausible it is to separate out those elements of the Counter class that are per-Buffer (or, at least, document set) and those that are not. Basically: ALL of the members of Counter

Re: Patches

On 11/2/20 2:33 PM, Jean-Marc Lasgouttes wrote: Le 02/11/2020 à 19:50, Yuriy Skalko a écrit : I'll check this stuff. By the way, is it related to numbered layouts that Daniel is now implementing on the bugtracker (https://www.lyx.org/trac/ticket/12010)? I don't inadvertently want to break his

Re: Patches

On Monday, November 2, 2020 7:33:41 PM WET Jean-Marc Lasgouttes wrote: > Yes, updateMacros is a pain, it is actually a O(n^2) algorithm which > kills performance for big documents. But it is a bit scary and I never > dared changing it I had a PhD student last year showing a lyx document full of m

Re: Patches

Le 02/11/2020 à 19:50, Yuriy Skalko a écrit : I'll check this stuff. By the way, is it related to numbered layouts that Daniel is now implementing on the bugtracker (https://www.lyx.org/trac/ticket/12010)? I don't inadvertently want to break his results. Yes it is related, but it should not

Re: Patches

I am very impressed :) If you feel like factoring more, you could have a look at splitting Counters/Counter into 3 classes: 1/2) the definitions, which belong to the textclass, and which should basically be accessed as const 3) the values of the counters, which can be a much more compact objec

Re: Patches

Le 01/11/2020 à 17:08, Yuriy Skalko a écrit : And the last 10 refactoring patches from me. I am very impressed :) If you feel like factoring more, you could have a look at splitting Counters/Counter into 3 classes: 1/2) the definitions, which belong to the textclass, and which should basica

Re: Patches

On Sun, Nov 01, 2020 at 06:08:47PM +0200, Yuriy Skalko wrote: > And the last 10 refactoring patches from me. Apart from patches 5 & 10 these seem ok to me. I am not sure we want to ditch that bformat version, just because its not currently used, someone might have opinion. I do not understand yet

Re: Patches

On Thu, Oct 29, 2020 at 08:47:23AM +0200, Yuriy Skalko wrote: > Next 3 patches. Looks good. Pavel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Patches

On 10/8/20 9:54, Richard Kimberly Heck wrote: On 8/10/20 3:49 AM, racoon wrote: On 2020-08-10 09:19, Richard Kimberly Heck wrote: On 8/10/20 12:23 AM, Daniel wrote: On 2020-08-09 19:41, Richard Kimberly Heck wrote: On 8/9/20 1:04 PM, Richard Kimberly Heck wrote: On 8/9/20 5:45 AM, Daniel wro

Re: Patches

On 8/10/20 3:49 AM, racoon wrote: > On 2020-08-10 09:19, Richard Kimberly Heck wrote: >> On 8/10/20 12:23 AM, Daniel wrote: >>> On 2020-08-09 19:41, Richard Kimberly Heck wrote: On 8/9/20 1:04 PM, Richard Kimberly Heck wrote: > On 8/9/20 5:45 AM, Daniel wrote: >> I have produced a numb

Re: Patches

On 2020-08-10 09:19, Richard Kimberly Heck wrote: On 8/10/20 12:23 AM, Daniel wrote: On 2020-08-09 19:41, Richard Kimberly Heck wrote: On 8/9/20 1:04 PM, Richard Kimberly Heck wrote: On 8/9/20 5:45 AM, Daniel wrote: I have produced a number of (unsolicited) patches. I will stop doing so for n

Re: Patches

On 8/10/20 12:23 AM, Daniel wrote: > On 2020-08-09 19:41, Richard Kimberly Heck wrote: >> On 8/9/20 1:04 PM, Richard Kimberly Heck wrote: >>> On 8/9/20 5:45 AM, Daniel wrote: I have produced a number of (unsolicited) patches. I will stop doing so for now until some of them are either reje

Re: Patches

On 2020-08-09 19:41, Richard Kimberly Heck wrote: On 8/9/20 1:04 PM, Richard Kimberly Heck wrote: On 8/9/20 5:45 AM, Daniel wrote: I have produced a number of (unsolicited) patches. I will stop doing so for now until some of them are either rejected or commited to master. Otherwise, I fear that

Re: Patches

On 2020-08-09 21:20, Yu Jin wrote: Am So., 9. Aug. 2020 um 11:45 Uhr schrieb Daniel >: I have produced a number of (unsolicited) patches. I will stop doing so for now until some of them are either rejected or commited to master. Otherwise, I fear that I will h

Re: Patches

Am So., 9. Aug. 2020 um 11:45 Uhr schrieb Daniel : > I have produced a number of (unsolicited) patches. I will stop doing so > for now until some of them are either rejected or commited to master. > Otherwise, I fear that I will have to redo them (partly), like this one > https://www.lyx.org/trac/

Re: Patches

On 8/9/20 1:04 PM, Richard Kimberly Heck wrote: > On 8/9/20 5:45 AM, Daniel wrote: >> I have produced a number of (unsolicited) patches. I will stop doing >> so for now until some of them are either rejected or commited to >> master. Otherwise, I fear that I will have to redo them (partly), like >>

Re: Patches

On 8/9/20 5:45 AM, Daniel wrote: > I have produced a number of (unsolicited) patches. I will stop doing > so for now until some of them are either rejected or commited to > master. Otherwise, I fear that I will have to redo them (partly), like > this one https://www.lyx.org/trac/ticket/10328, or in

Re: Patches

On 2020-08-09 11:45, Daniel wrote: I have produced a number of (unsolicited) patches. I will stop doing so for now until some of them are either rejected or commited to master. Otherwise, I fear that I will have to redo them (partly), like this one https://www.lyx.org/trac/ticket/10328, or inco

Re: Patches to improve compatibility with modern C++ standard

Am Do., 4. Juni 2020 um 15:22 Uhr schrieb Kornel Benko : > Am Thu, 4 Jun 2020 15:03:28 +0200 > schrieb Yu Jin : > > > Sorry for the trouble, I just updated Visual Studio to version 16.6.1 > > (always try to work with the latest software). My MVSC version according > to > > CMake is now 1926, and n

Re: Patches to improve compatibility with modern C++ standard

Am Thu, 4 Jun 2020 15:03:28 +0200 schrieb Yu Jin : > Am Di., 5. Mai 2020 um 13:49 Uhr schrieb Kornel Benko : > > > Am Tue, 5 May 2020 13:39:35 +0200 > > schrieb Yu Jin : > > > > > Am Di., 5. Mai 2020 um 13:10 Uhr schrieb Kornel Benko : > > > > > > > Am Tue, 5 May 2020 12:36:03 +0200 > > > > schri

Re: Patches to improve compatibility with modern C++ standard

Am Di., 5. Mai 2020 um 13:49 Uhr schrieb Kornel Benko : > Am Tue, 5 May 2020 13:39:35 +0200 > schrieb Yu Jin : > > > Am Di., 5. Mai 2020 um 13:10 Uhr schrieb Kornel Benko : > > > > > Am Tue, 5 May 2020 12:36:03 +0200 > > > schrieb Yu Jin : > > > > > > > Am Di., 5. Mai 2020 um 09:16 Uhr schrieb Kor

Re: Patches to improve compatibility with modern C++ standard

On Wed, 6 May 2020 at 11:42, Kornel Benko wrote: > Am Tue, 5 May 2020 20:35:30 +0200 > schrieb Thibaut Cuvelier : > > > Well, it has a couple of different versions… > > The compiler itself: 19.2x., like 19.25.28614 > > The toolchain: 16.x.x, like 16.5.4 > > The _MSC_VER macro: 192x, like 1925

Re: Patches to improve compatibility with modern C++ standard

Am Tue, 5 May 2020 20:35:30 +0200 schrieb Thibaut Cuvelier : > Well, it has a couple of different versions… > The compiler itself: 19.2x., like 19.25.28614 > The toolchain: 16.x.x, like 16.5.4 > The _MSC_VER macro: 192x, like 1925 (it looks like the one used by CMake for > MSVC_VERSION) The _M

Re: Patches to improve compatibility with modern C++ standard

At the very least, Boost 1.70 seems to do the job (unlike 1.68). So 1.72 is more than likely enough. Thibaut Cuvelier On Tue, 5 May 2020 at 22:19, Thibaut Cuvelier wrote: > I don't have access to master: the Git server is too slow for me to > download it (working at most at 10 kb/s); plus, my

Re: Patches to improve compatibility with modern C++ standard

On Tue, May 05, 2020 at 10:37:34PM +0200, Jean-Marc Lasgouttes wrote: > Le 05/05/2020 ?? 22:19, Thibaut Cuvelier a écrit : > >I don't have access to master: the Git server is too slow for me to > >download it (working at most at 10 kb/s); plus, my Internet access is > >disrupted (/tout le départeme

Re: Patches to improve compatibility with modern C++ standard

Le 05/05/2020 à 22:19, Thibaut Cuvelier a écrit : I don't have access to master: the Git server is too slow for me to download it (working at most at 10 kb/s); plus, my Internet access is disrupted (/tout le département du Val de Marne, apparemment…/), so my only access is 4G, like many people

Re: Patches to improve compatibility with modern C++ standard

I don't have access to master: the Git server is too slow for me to download it (working at most at 10 kb/s); plus, my Internet access is disrupted (*tout le département du Val de Marne, apparemment…*), so my only access is 4G, like many people in the area… I highly suspect that this version is goo

Re: Patches to improve compatibility with modern C++ standard

Le 05/05/2020 à 21:22, Thibaut Cuvelier a écrit : No, nothing requires C++20, it's just that VC19 is not C++11-compliant enough when set in C++11 mode to build LyX, you have to enable C++17 to enable some features like designated initialiser, if my memory serves me right. Thanks, I understand

Re: Patches to improve compatibility with modern C++ standard

No, nothing requires C++20, it's just that VC19 is not C++11-compliant enough when set in C++11 mode to build LyX, you have to enable C++17 to enable some features like designated initialiser, if my memory serves me right. Thibaut Cuvelier On Tue, 5 May 2020 at 21:07, Jean-Marc Lasgouttes wrote

Re: Patches to improve compatibility with modern C++ standard

Le 05/05/2020 à 13:02, Kornel Benko a écrit : As Thibaut needs /std:c++20, we have to check if it is valid flag. This is where our interpretation diverges. Thibaut, could you clarify the situation about C++20 again? If your code requires C++20 we will sooner or later be in a bad position, won

Re: Patches to improve compatibility with modern C++ standard

Well, it has a couple of different versions… The compiler itself: 19.2x., like 19.25.28614 The toolchain: 16.x.x, like 16.5.4 The _MSC_VER macro: 192x, like 1925 (it looks like the one used by CMake for MSVC_VERSION) The _MSC_FULL_VER: 192xx, like 192027508 Thibaut Cuvelier On Tue, 5 May

Re: Patches to improve compatibility with modern C++ standard

Am Tue, 5 May 2020 13:39:35 +0200 schrieb Yu Jin : > Am Di., 5. Mai 2020 um 13:10 Uhr schrieb Kornel Benko : > > > Am Tue, 5 May 2020 12:36:03 +0200 > > schrieb Yu Jin : > > > > > Am Di., 5. Mai 2020 um 09:16 Uhr schrieb Kornel Benko : > > > > > > > Am Tue, 5 May 2020 09:15:50 +0200 > > > > schri

Re: Patches to improve compatibility with modern C++ standard

Am Di., 5. Mai 2020 um 13:10 Uhr schrieb Kornel Benko : > Am Tue, 5 May 2020 12:36:03 +0200 > schrieb Yu Jin : > > > Am Di., 5. Mai 2020 um 09:16 Uhr schrieb Kornel Benko : > > > > > Am Tue, 5 May 2020 09:15:50 +0200 > > > schrieb Kornel Benko : > > > > Thanks Eugene. Please try the next patch. >

Re: Patches to improve compatibility with modern C++ standard

Am Tue, 5 May 2020 12:36:03 +0200 schrieb Yu Jin : > Am Di., 5. Mai 2020 um 09:16 Uhr schrieb Kornel Benko : > > > Am Tue, 5 May 2020 09:15:50 +0200 > > schrieb Kornel Benko : > > > Thanks Eugene. Please try the next patch. > > > If it also does not work, we have to decide on the msvc version > >

  1   2   3   4   5   6   >