On 7/3/24 6:55 AM, Enrico Forestieri wrote:
On Tue, Jun 18, 2024 at 09:29:58PM +0100, José Matos wrote:
On Tue, 2024-06-18 at 20:04 +, Enrico Forestieri wrote:
Avoid bogus warnings when configuring for Qt6
Thank you. It works. :-)
Riki, Ok for stable?
Yes, thanks.
Riki
--
lyx
On Tue, Jun 18, 2024 at 09:29:58PM +0100, José Matos wrote:
On Tue, 2024-06-18 at 20:04 +, Enrico Forestieri wrote:
Avoid bogus warnings when configuring for Qt6
Thank you. It works. :-)
Riki, Ok for stable?
--
Enrico
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http
On Tue, 2024-06-18 at 20:04 +, Enrico Forestieri wrote:
> Avoid bogus warnings when configuring for Qt6
Thank you. It works. :-)
--
José Abílio
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
On Wed, Aug 16, 2023 at 05:23:55PM -0400, Richard Kimberly Heck wrote:
>
> On 8/16/23 14:30, Scott Kostyshak wrote:
> > On Wed, Aug 16, 2023 at 05:48:57PM +0200, Pavel Sanda wrote:
> > > > ../../2.3.x/src/LyXRC.cpp:3077:42: warning: comparison between two
> > > > arrays
> > > > [-Warray-compare]
On 8/16/23 14:30, Scott Kostyshak wrote:
On Wed, Aug 16, 2023 at 05:48:57PM +0200, Pavel Sanda wrote:
../../2.3.x/src/LyXRC.cpp:3077:42: warning: comparison between two arrays
[-Warray-compare]
3077 | || lyxrc_orig.font_sizes != lyxrc_new.font_sizes
This one is a real bug thou
On Wed, Aug 16, 2023 at 05:48:57PM +0200, Pavel Sanda wrote:
>
> > ../../2.3.x/src/LyXRC.cpp:3077:42: warning: comparison between two arrays
> > [-Warray-compare]
> > 3077 | || lyxrc_orig.font_sizes != lyxrc_new.font_sizes
>
> This one is a real bug though, fixed at master by eae
<_Ret, _Tp> std::mem_fun_ref(_Ret (_Tp::*)()
> const) [with _Ret = bool; _Tp = lyx::ParamInfo::ParamData]??? is deprecated:
I wouldn't worry about deprecaction warnings with new gcc. 2.4 will be long out
before
we might get hit by this
> ../../2.3.x/src/LyXRC.cpp:3077:42: warnin
Dear developers,
I had to recompile 2.3.8dev becaus the then enchant bug (see
https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg219915.html)
With :
Configuration
Host type: x86_64-pc-linux-gnu
Special build flags: build=development std-regex warnings assertions
Am Sonntag, dem 02.04.2023 um 13:21 +0200 schrieb Jürgen Spitzmüller:
> This needs some effort. For the time being, I think we will be better
> off with this rather harmless info message.
Possible approach attached.
--
Jürgen
diff --git a/src/Paragraph.cpp b/src/Paragraph.cpp
index c43421b376..4
Am Mittwoch, dem 22.03.2023 um 23:21 + schrieb Udicoudco:
> > > I attached a possible patch, it only fix the lstlisting case when
> > > polyglossia is used, since babel-hebrew does not have an
> > > equivalent
> > > to \begin{RTL}...\end{RTL} (or there is one?) and babel with
> > > luatex
> > >
On Wed, Mar 22, 2023 at 10:28 PM Udicoudco wrote:
>
> > I attached a possible patch, it only fix the lstlisting case when
> > polyglossia is used, since babel-hebrew does not have an equivalent
> > to \begin{RTL}...\end{RTL} (or there is one?) and babel with luatex
> > does not need this kind of w
> I attached a possible patch, it only fix the lstlisting case when
> polyglossia is used, since babel-hebrew does not have an equivalent
> to \begin{RTL}...\end{RTL} (or there is one?) and babel with luatex
> does not need this kind of wrappers.
I've added line breaks to the LaTeX code for
readabi
On Wed, Mar 22, 2023 at 2:22 PM Scott Kostyshak wrote:
>
> On Wed, Mar 22, 2023 at 01:13:27PM +0100, Jürgen Spitzmüller wrote:
> > Am Mittwoch, dem 22.03.2023 um 12:54 +0200 schrieb Udicoudco:
> > > I think in the case of where forceLTR insets will have multiple
> > > paragraphs, it is better to u
On Wed, Mar 22, 2023 at 01:13:27PM +0100, Jürgen Spitzmüller wrote:
> Am Mittwoch, dem 22.03.2023 um 12:54 +0200 schrieb Udicoudco:
> > I think in the case of where forceLTR insets will have multiple
> > paragraphs, it is better to use
> > \begin{RTL}...\end{RTL}, which basically only issues \par a
Am Mittwoch, dem 22.03.2023 um 12:54 +0200 schrieb Udicoudco:
> I think in the case of where forceLTR insets will have multiple
> paragraphs, it is better to use
> \begin{RTL}...\end{RTL}, which basically only issues \par and sets
> the
> RTL related conditionals
> to be false.
Thanks for the deta
Slight correction, the lines
>
> \@RTLfalse\beginL{
> \begin{lstlisting}
> Hello
> \end{lstlisting}
> }\endL
>
should be
{\@RTLfalse\beginL
\begin{lstlisting}
Hello
\end{lstlisting}
}\endL
and the lines
>
> \@RTLfalse\beginL{
> \par
> Hello
> \par
> }\endL
>
should be
{\@RTLfalse\beginL
On Tue, Mar 21, 2023 at 9:40 PM Scott Kostyshak wrote:
>
> On Tue, Mar 21, 2023 at 12:50:06PM +0100, Jürgen Spitzmüller wrote:
> > Am Dienstag, dem 21.03.2023 um 11:27 + schrieb Udicoudco:
> > > Hello all,
> > >
> > > Attached a LyX file and its export to LaTeX code.
> > > When compiling with
On Tue, Mar 21, 2023 at 12:50:06PM +0100, Jürgen Spitzmüller wrote:
> Am Dienstag, dem 21.03.2023 um 11:27 + schrieb Udicoudco:
> > Hello all,
> >
> > Attached a LyX file and its export to LaTeX code.
> > When compiling with XeLaTeX the exported code
> > I get the warning:
> >
> > \endL o
Am Dienstag, dem 21.03.2023 um 11:27 + schrieb Udicoudco:
> Hello all,
>
> Attached a LyX file and its export to LaTeX code.
> When compiling with XeLaTeX the exported code
> I get the warning:
>
> \endL or \endR problem (0 missing, 1 extra) in paragraph at lines
> 26--27
Interestingly,
Hello all,
Attached a LyX file and its export to LaTeX code.
When compiling with XeLaTeX the exported code
I get the warning:
\endL or \endR problem (0 missing, 1 extra) in paragraph at lines 26--27
If I replace
\LRE{
\begin{lstlisting}
Hello
\end{lstlisting}
}
With
\begin{LTR}
\begin{ls
Am Donnerstag, dem 24.11.2022 um 11:42 -0500 schrieb Richard Kimberly
Heck:
> Yes, go ahead.
Thanks, done.
--
Jürgen
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
2022 +0200
GuiLog: don't miss package warnings for packages with dashes
(e.g. scrlayer-scrpage)
Candidate for stable, Riki.
Riki?
Yes, go ahead.
Riki
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
0200
> >
> > GuiLog: don't miss package warnings for packages with dashes
> >
> > (e.g. scrlayer-scrpage)
>
> Candidate for stable, Riki.
Riki?
--
Jürgen
signature.asc
Description: This is a digitally signed message part
--
lyx-devel mailin
Am Sonntag, dem 16.10.2022 um 11:18 +0200 schrieb Juergen Spitzmueller:
> commit 647c7b1ac383f00030bd2da32dfa39070c87ed96
> Author: Juergen Spitzmueller
> Date: Sun Oct 16 12:08:21 2022 +0200
>
> GuiLog: don't miss package warnings for packages with dashes
>
baut Cuvelier :
> > >
> > > > Hi Kornel,
> > > >
> > > > Thanks for pointing these out, they didn't show on my side. I could
> quite
> > > > easily fix the one about the unused argument in the constructor (it's
> > > > already pushed:
ese out, they didn't show on my side. I could quite
> > > easily fix the one about the unused argument in the constructor (it's
> > > already pushed: dca39815), but I don't know what to do for the others.
> > > Maybe the attached patch so
used argument in the constructor (it's
> > already pushed: dca39815), but I don't know what to do for the others.
> > Maybe the attached patch solves the rest of the warnings?
> >
> > On Fri, 24 Sept 2021 at 00:55, Kornel Benko wrote:
> >
> > >
> &g
know what to do for the others.
> Maybe the attached patch solves the rest of the warnings?
>
> On Fri, 24 Sept 2021 at 00:55, Kornel Benko wrote:
>
> >
> > See attached.
> >
> > Kornel
> > --
> > lyx-devel mailing list
> > lyx-deve
Hi Kornel,
Thanks for pointing these out, they didn't show on my side. I could quite
easily fix the one about the unused argument in the constructor (it's
already pushed: dca39815), but I don't know what to do for the others.
Maybe the attached patch solves the rest of the warnin
See attached.
Kornel
Warnings
Description: Binary data
pgpvNNTRcQ84O.pgp
Description: Digitale Signatur von OpenPGP
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Am 16.07.2021 um 18:37 schrieb Jean-Marc Lasgouttes :
>
> Le 16/07/2021 à 18:24, Stephan Witt a écrit :
>> Hi Thibaut,
>> the Apple clang compiler spits warnings for InsetMathScript.cpp:
>
> Hi Stephan,
>
> I was about to push the following patch :) I'll let
Le 16/07/2021 à 18:24, Stephan Witt a écrit :
Hi Thibaut,
the Apple clang compiler spits warnings for InsetMathScript.cpp:
Hi Stephan,
I was about to push the following patch :) I'll let you decide what to do.
JMarc
/Users/lyx/Development/lyx/src/mathed/InsetMathScript.cpp:6
Hi Thibaut,
the Apple clang compiler spits warnings for InsetMathScript.cpp:
/Users/lyx/Development/lyx/src/mathed/InsetMathScript.cpp:619:11: warning:
variable 'tag' is used uninitialized whenever 'if' condition is false
[-Wsometimes-uninitialized
On Fri, Feb 19, 2021 at 09:05:38AM +0100, JP wrote:
> Hello Scott
>
> Thanks for the fix.
Sure! This type of error slips in every now and again, and only triggers
a "warning", not an "error", so it is easy to miss it. To catch it, I
have the following as part of my build script:
if grep "warning
Hello Scott
Thanks for the fix.
--
Jean-Pierre
Le 19 février 2021 06:46:08 Scott Kostyshak a écrit :
commit 99f7d7fa743d1a787e7eabcc85b364a96eaa2197
Author: Scott Kostyshak
Date: Fri Feb 19 00:42:38 2021 -0500
Fix warnings in fr.po
Escaping \alpha addresses the following
Le 20/12/2020 à 11:37, Kornel Benko a écrit :
This works, but I just wondered why cmake did not need to compile any sources in
hunspell/1.7.0/src/parsers.
Do we need only the header files there?
Because we do not need this directory! I removed it.
Thanks,
JMarc
--
lyx-devel mailing list
lyx-d
Am Sat, 19 Dec 2020 20:57:24 +0100
schrieb Jean-Marc Lasgouttes :
> Le 17/12/2020 à 11:46, Kornel Benko a écrit :
> > Am Thu, 17 Dec 2020 11:40:36 +0100
> > schrieb Jean-Marc Lasgouttes :
> I guess it can wait for 2.3.7. Looking at "git log" for
> 3rdparty/hunspell, there is one main c
Le 17/12/2020 à 11:46, Kornel Benko a écrit :
Am Thu, 17 Dec 2020 11:40:36 +0100
schrieb Jean-Marc Lasgouttes :
I guess it can wait for 2.3.7. Looking at "git log" for
3rdparty/hunspell, there is one main commit (c3484fa6c), 2 fixups
(91c58d9a68ca2 and cf980435b), plus a fistful of commits by Ko
Am Thu, 17 Dec 2020 11:40:36 +0100
schrieb Jean-Marc Lasgouttes :
> Le 02/11/2020 à 19:44, Richard Kimberly Heck a écrit :
> > On 11/2/20 12:16 PM, Jean-Marc Lasgouttes wrote:
> >> Le 02/11/2020 à 16:59, Richard Kimberly Heck a écrit :
> Yes, hunspell has been updated in master to 1.7.0,
Le 02/11/2020 à 19:44, Richard Kimberly Heck a écrit :
On 11/2/20 12:16 PM, Jean-Marc Lasgouttes wrote:
Le 02/11/2020 à 16:59, Richard Kimberly Heck a écrit :
Yes, hunspell has been updated in master to 1.7.0, but not in
branch. Riki, would it make sense to do that, given that we want to
leave
r :
> >
> > > commit 0c5e10f36b0b42eefa41806cac12790a2b49c043
> > > Author: Thibaut Cuvelier
> > > Date: Sat Dec 5 22:51:56 2020 +0100
> > >
> > > This should fix a few type-conversion warnings.
> > > ---
> > > src/output_docbook.
t;
> > This should fix a few type-conversion warnings.
> > ---
> > src/output_docbook.cpp |5 +++--
> > 1 files changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/src/output_docbook.cpp b/src/output_docbook.cpp
> > index aaa3860..ce6b7
Am Sat, 5 Dec 2020 22:22:34 +0100 (CET)
schrieb Thibaut Cuvelier :
> commit 0c5e10f36b0b42eefa41806cac12790a2b49c043
> Author: Thibaut Cuvelier
> Date: Sat Dec 5 22:51:56 2020 +0100
>
> This should fix a few type-conversion warnings.
> ---
> src/output_docbook.
On Mon, Nov 30, 2020 at 11:16:27AM -0500, Richard Kimberly Heck wrote:
> On 11/29/20 11:24 PM, Scott Kostyshak wrote:
> > I get the following warnings:
> >
> > /home/scott/lyxbuilds/master/repo/src/output_docbook.cpp: In function ‘void
> > lyx::{anonymous}::makeParagr
On 11/29/20 11:24 PM, Scott Kostyshak wrote:
> I get the following warnings:
>
> /home/scott/lyxbuilds/master/repo/src/output_docbook.cpp: In function ‘void
> lyx::{anonymous}::makeParagraph(const lyx::Text&, const lyx::Buffer&,
> lyx::XMLStream&, const lyx::OutputPa
I get the following warnings:
/home/scott/lyxbuilds/master/repo/src/output_docbook.cpp: In function ‘void
lyx::{anonymous}::makeParagraph(const lyx::Text&, const lyx::Buffer&,
lyx::XMLStream&, const lyx::OutputParams&, const const_iterator&)’:
/home/scott/lyxbu
Le 02/11/2020 à 15:39, Jean-Pierre Chrétien a écrit :
Dear developers
While compiling the latest branch with this config
I see this :
../../../2.3.x/3rdparty/hunspell/1.6.2/src/hunspell/hunspell.cxx: In
member function ‘bool HunspellImpl::spell(const string&, int*,
std::__cxx11::string*)’:
Dear developers
While compiling the latest branch with this config
Configuration
Host type: x86_64-pc-linux-gnu
Special build flags: build=development std-regex warnings assertions
stdlib-debug use-hunspell
Bundled libraries:boost hunspell mythes
C
;-- currently this is used
> > #define VOID
> > #define FILE_BEGIN 0
> > #endif /* NOT STDC */
> >
> > so the functions which don't return anything actually end up as
> > "int fun(...)" not "void fun(...)" and Warnings are produced.
> &
> #define VOID void
> #define FILE_BEGIN SEEK_SET
> #else /* NOT STDC */
> #define Void int<-- currently this is used
> #define VOID
> #define FILE_BEGIN 0
> #endif /* NOT STDC */
>
> so the functions which don't return anything actually end up as
>
define FILE_BEGIN 0
#endif /* NOT STDC */
so the functions which don't return anything actually end up as
"int fun(...)" not "void fun(...)" and Warnings are produced.
Can also enclose it in a "if (WIN32)" block if not wanted on other
platforms.
--
Eugene
f
9fed52f
>>>> Author: Jean-Marc Lasgouttes
>>>> Date: Thu Apr 30 12:09:17 2020 +0200
>>>>
>>>> Avoid warnings about deprecated copy in gcc 10 too
>>>
>>> Riki, do you want all the warning-related fixes in branch too?
>>
>&g
warnings about deprecated copy in gcc 10 too
Riki, do you want all the warning-related fixes in branch too?
I haven't been doing that myself. But it's not harm.
So it is a 'yes'?
JMarc
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
On 4/30/20 6:28 AM, Jean-Marc Lasgouttes wrote:
> Le 30/04/2020 à 11:48, Jean-Marc Lasgouttes a écrit :
>> commit db5021c42eb5828c3fa0fd786b14eafcf9fed52f
>> Author: Jean-Marc Lasgouttes
>> Date: Thu Apr 30 12:09:17 2020 +0200
>>
>> Avoid warnings ab
On 4/19/20 2:22 PM, Jean-Marc Lasgouttes wrote:
> Le 19/04/2020 à 19:23, Richard Kimberly Heck a écrit :
>> Yes, that could be re-written in a variety of ways, I would suppose. But
>> checking that we don't break any such loops? That sounds difficult.
>
> grepping for all tests ">=0" and "<0" shoul
Le 19/04/2020 à 19:23, Richard Kimberly Heck a écrit :
Yes, that could be re-written in a variety of ways, I would suppose. But
checking that we don't break any such loops? That sounds difficult.
grepping for all tests ">=0" and "<0" should be enough, isn't it? (for
the snippet above, I greppe
On 4/19/20 1:08 PM, Jean-Marc Lasgouttes wrote:
> Le 19/04/2020 à 17:39, Richard Kimberly Heck a écrit :
>> /cvs/lyx/lyx-devel/src/insets/InsetText.cpp:526: warning: implicit
>> conversion changes signedness:
>> 'lyx::RandomAccessList::size_type' (aka 'unsigned long')
>> to 'lyx::pit_type' (aka 'lo
Le 19/04/2020 à 17:39, Richard Kimberly Heck a écrit :
/cvs/lyx/lyx-devel/src/insets/InsetText.cpp:526: warning: implicit
conversion changes signedness:
'lyx::RandomAccessList::size_type' (aka 'unsigned long')
to 'lyx::pit_type' (aka 'long')
It would be nice if pit_type could be unsigned instea
/cvs/lyx/lyx-devel/src/insets/InsetText.cpp:526: warning: implicit
conversion changes signedness:
'lyx::RandomAccessList::size_type' (aka 'unsigned long')
to 'lyx::pit_type' (aka 'long')
The code here is:
rp.par_end = paragraphs().size();
and the fix would be
rp.par_end = static_cast(paragraphs
On Thu, Jan 03, 2019 at 11:55:43AM -0500, Scott Kostyshak wrote:
> On Thu, Jan 03, 2019 at 10:43:12AM +0100, Jean-Marc Lasgouttes wrote:
> > Le 02/01/2019 à 20:46, Scott Kostyshak a écrit :
> > > Thanks. Just checked and almost all of them are gone. I still get the
> > > following:
> > >
> > > In
On Thu, Feb 13, 2020 at 06:28:05PM +0100, Jean-Marc Lasgouttes wrote:
> >I can replace asserts with explicit checks if you agree.
> >Or completely delete those checks because for most of them getStatus won't
> >let
> >you in without buffer anyway.
>
> Either solution will be OK. And do not forget
Am 15.02.2020 um 09:28 schrieb Kornel Benko :
>
> Am Sat, 15 Feb 2020 09:17:53 +0100
> schrieb Kornel Benko :
>
>> Am Sat, 15 Feb 2020 09:02:45 +0100
>> schrieb Stephan Witt :
>>
>>> Am 15.02.2020 um 08:32 schrieb Kornel Benko :
Am Fri, 14 Feb 2020 17:37:28 +0100
schrieb Steph
Am Sat, 15 Feb 2020 09:17:53 +0100
schrieb Kornel Benko :
> Am Sat, 15 Feb 2020 09:02:45 +0100
> schrieb Stephan Witt :
>
> > Am 15.02.2020 um 08:32 schrieb Kornel Benko :
> > >
> > > Am Fri, 14 Feb 2020 17:37:28 +0100
> > > schrieb Stephan Witt :
> > >
> > >> Changes not staged for comm
Am Sat, 15 Feb 2020 09:02:45 +0100
schrieb Stephan Witt :
> Am 15.02.2020 um 08:32 schrieb Kornel Benko :
> >
> > Am Fri, 14 Feb 2020 17:37:28 +0100
> > schrieb Stephan Witt :
> >
> >> Changes not staged for commit:
> >> (use "git add ..." to update what will be committed)
> >> (use "git ch
Am 15.02.2020 um 08:32 schrieb Kornel Benko :
>
> Am Fri, 14 Feb 2020 17:37:28 +0100
> schrieb Stephan Witt :
>
>> Changes not staged for commit:
>> (use "git add ..." to update what will be committed)
>> (use "git checkout -- ..." to discard changes in working directory)
>>
>>modified:
Am Fri, 14 Feb 2020 17:37:28 +0100
schrieb Stephan Witt :
> Changes not staged for commit:
> (use "git add ..." to update what will be committed)
> (use "git checkout -- ..." to discard changes in working directory)
>
> modified: development/cmake/modules/FindHUNSPELL.cmake
>
> no ch
it a47dec6b4a91ca59a8d9d4431ecedd77f8ffc7e7
>>>> Author: Kornel Benko
>>>> Date: Mon Jan 27 10:44:14 2020 +0100
>>>>
>>>> Cmake build: Remove cmake warnings about mismatched values of
>>>> FindPackageHandleS
o
>>> Date: Mon Jan 27 10:44:14 2020 +0100
>>>
>>> Cmake build: Remove cmake warnings about mismatched values of
>>> FindPackageHandleStandardArgs()
>>>
>>> (cherry picked from commit 9fdc00fe2a2b2db752ca244eac3d14e708d5caba)
>>> --
Am Fri, 14 Feb 2020 15:57:45 +0100
schrieb Stephan Witt :
> Am 08.02.2020 um 21:55 schrieb Kornel Benko :
> >
> > commit a47dec6b4a91ca59a8d9d4431ecedd77f8ffc7e7
> > Author: Kornel Benko
> > Date: Mon Jan 27 10:44:14 2020 +0100
> >
> >Cmake build:
Am 08.02.2020 um 21:55 schrieb Kornel Benko :
>
> commit a47dec6b4a91ca59a8d9d4431ecedd77f8ffc7e7
> Author: Kornel Benko
> Date: Mon Jan 27 10:44:14 2020 +0100
>
>Cmake build: Remove cmake warnings about mismatched values of
> FindPackageHandleStandardArgs()
>
On Thu, Feb 13, 2020 at 10:39:29PM +0100, Stephan Witt wrote:
> Am 13.02.2020 um 19:05 schrieb Scott Kostyshak :
> >
> > On Wed, Feb 12, 2020 at 08:45:56PM +0100, Stephan Witt wrote:
> >
> >> See the attached nice picture…
> >
> > This picture is great! Did you create it manually or is there som
Am 13.02.2020 um 19:05 schrieb Scott Kostyshak :
>
> On Wed, Feb 12, 2020 at 08:45:56PM +0100, Stephan Witt wrote:
>
>> See the attached nice picture…
>
> This picture is great! Did you create it manually or is there some sort
> of magical static analysis tool that does this?
It’s the result of
On Wed, Feb 12, 2020 at 08:45:56PM +0100, Stephan Witt wrote:
> See the attached nice picture…
This picture is great! Did you create it manually or is there some sort
of magical static analysis tool that does this?
Scott
signature.asc
Description: PGP signature
--
lyx-devel mailing list
lyx-d
Le 13/02/2020 à 18:16, Pavel Sanda a écrit :
On Wed, Feb 12, 2020 at 08:53:14PM +0100, Jean-Marc Lasgouttes wrote:
3. NULL pointer usage
In GuiView::dispatchVC are different buffer pointer variables used.
Sometimes there is an explicit check for NULL value.
Sometimes there is an assertion with
On Wed, Feb 12, 2020 at 08:53:14PM +0100, Jean-Marc Lasgouttes wrote:
> >3. NULL pointer usage
> >
> >In GuiView::dispatchVC are different buffer pointer variables used.
> >Sometimes there is an explicit check for NULL value.
> >Sometimes there is an assertion with break or return for release build
warnings
E.g. in GuiDocument::updateAvailableModules() -
src/frontends/qt/GuiDocument.cpp, line 4474
There is an allocation here:
QStandardItem * catItem = new QStandardItem();
and later an assignment here:
catItem = fcats.first();
See the attached nice picture…
Should this be changed with the
Am 12.02.2020 um 20:53 schrieb Jean-Marc Lasgouttes :
>
> Le 12/02/2020 à 20:45, Stephan Witt a écrit :
>> Hi all,
>> I've recently upgraded some parts of my tool box. I’m seeing new warnings
>> now.
>> 1. deprecated warning (removed with C++17?)
>> ly
Le 12/02/2020 à 20:45, Stephan Witt a écrit :
Hi all,
I've recently upgraded some parts of my tool box. I’m seeing new warnings now.
1. deprecated warning (removed with C++17?)
lyx/src/insets/InsetCommandParams.cpp:596:9: warning: 'mem_fun_ref' is deprecated
I already an
Le 27/07/2019 à 15:51, Kornel Benko a écrit :
Here are some examples used in Additional.lyx (to be seen in Additional.tex)
features of \LaTeX .
You ought to remove spaces in front of punctuation.
heavily on \LyX 's interaction
Use ` to begin quotati
ent\shadowbox{\begin{minipage}[t]{1\columnwidth - 2\fboxsep -
2\fboxrule - \shadowsize}%
Wrong length of dash may have been used.
This is of course only a subset of warnings, omitting following similar
messages.
Kornel
signature.asc
Description: This is a digitally signed message part.
On Wednesday, 12 June 2019 21.40.39 WEST Jean-Marc Lasgouttes wrote:
> Note that we still have to fix the warnings, I just disabled them.
>
> JMarc
I know. And as you stated the problem is mainly related with the qt code
warnings. We get overwhelmed by them.
If it were just the l
Le 12 juin 2019 21:52:09 GMT+02:00, "José Abílio Matos" a
écrit :
>On Wednesday, 12 June 2019 17.42.46 WEST Jean-Marc Lasgouttes wrote:
>> commit 134f3aedaf4150367cdc2f6855d695d3791a5353
>> Author: Jean-Marc Lasgouttes
>> Date: Wed Jun 12 18:49:29 2019 +0200
>
On Wednesday, 12 June 2019 17.42.46 WEST Jean-Marc Lasgouttes wrote:
> commit 134f3aedaf4150367cdc2f6855d695d3791a5353
> Author: Jean-Marc Lasgouttes
> Date: Wed Jun 12 18:49:29 2019 +0200
>
> Avoid warnings with gcc 9
Bah...
Now we get again a boring compile output.
When importing a large (e.g., corresponding PDF is 30 pages) .tex file, I get
the
following terminal output:
Bug: Ignoring par-level extra stuff '\noindent
'
catcode [_,8] illegal in text mode
catcode [_,8] illegal in text mode
dropping extra hline
unexpected dummy size: 2 content: \h
Am Mittwoch, 24. April 2019, 16:29:16 CEST schrieb Jean-Marc Lasgouttes:
> Le 22/04/2019 à 20:07, Kornel Benko a écrit :
> > /usr2/src/lyx/lyx-git/src/support/tests/dummy_functions.cpp:12:8: warning:
> > type 'struct LyXRC' violates the C++ One Definition Rule [-Wodr]
> > /usr2/src/lyx/lyx-git/src
Le 22/04/2019 à 20:07, Kornel Benko a écrit :
/usr2/src/lyx/lyx-git/src/support/tests/dummy_functions.cpp:12:8: warning: type
'struct LyXRC' violates the C++ One Definition Rule [-Wodr]
/usr2/src/lyx/lyx-git/src/LyXRC.h:547:14: warning: 'lyxrc' violates the C++ One
Definition Rule [-Wodr]
...
/usr2/src/lyx/lyx-git/src/support/tests/dummy_functions.cpp:12:8: warning: type
'struct LyXRC' violates the C++ One Definition Rule [-Wodr]
/usr2/src/lyx/lyx-git/src/LyXRC.h:547:14: warning: 'lyxrc' violates the C++ One
Definition Rule [-Wodr]
...
/usr2/src/lyx/lyx-git/src/LayoutEnums.h:48:6: wa
On Thursday, 3 January 2019 21.17.01 WET Jean-Marc Lasgouttes wrote:
> Le 3 janvier 2019 20:28:44 GMT+01:00, "José Abílio Matos"
a écrit :
> >As Riki said you will notice that there are several enchant related
> >packages
> >there, in particular enchant2:
> >https://src.fedoraproject.org/rpms/enc
Le 3 janvier 2019 20:28:44 GMT+01:00, "José Abílio Matos" a
écrit :
>As Riki said you will notice that there are several enchant related
>packages
>there, in particular enchant2:
>https://src.fedoraproject.org/rpms/enchant2
And do we support it currently?
JMarc
On Thu, Jan 03, 2019 at 07:28:44PM +, José Abílio Matos wrote:
> On Thursday, 3 January 2019 18.15.13 WET Scott Kostyshak wrote:
> > Looks like 1.6:
> >
> > https://rpms.remirepo.net/rpmphp/zoom.php?rpm=enchant
> >
> > Scott
>
> FWIW the canonical url if you want to search fedora is:
> htt
On Thursday, 3 January 2019 18.15.13 WET Scott Kostyshak wrote:
> Looks like 1.6:
>
> https://rpms.remirepo.net/rpmphp/zoom.php?rpm=enchant
>
> Scott
FWIW the canonical url if you want to search fedora is:
https://src.fedoraproject.org/rpms/enchant
If you want to search for packages in Fedora
On Thu, Jan 03, 2019 at 01:13:12PM -0500, Richard Kimberly Heck wrote:
> On 1/3/19 1:00 PM, Jean-Marc Lasgouttes wrote:
> > Le 3 janvier 2019 17:55:43 GMT+01:00, Scott Kostyshak a
> > écrit :
> >>> It has however been fixed in 2.x versions, but this is not (yet?) packaged
> >>> for ubuntu.
> >> L
On Thu, Jan 03, 2019 at 07:00:05PM +0100, Jean-Marc Lasgouttes wrote:
> Le 3 janvier 2019 17:55:43 GMT+01:00, Scott Kostyshak a
> écrit :
> >
> >> It has however been fixed in 2.x versions, but this is not (yet?) packaged
> >> for ubuntu.
> >
> >Looks like not even for Ubuntu 18.10:
> >
> > http
On 1/3/19 1:00 PM, Jean-Marc Lasgouttes wrote:
> Le 3 janvier 2019 17:55:43 GMT+01:00, Scott Kostyshak a
> écrit :
>>> It has however been fixed in 2.x versions, but this is not (yet?) packaged
>>> for ubuntu.
>> Looks like not even for Ubuntu 18.10:
>>
>> https://packages.ubuntu.com/search?keyw
Le 3 janvier 2019 17:55:43 GMT+01:00, Scott Kostyshak a
écrit :
>
>> It has however been fixed in 2.x versions, but this is not (yet?) packaged
>> for ubuntu.
>
>Looks like not even for Ubuntu 18.10:
>
> https://packages.ubuntu.com/search?keywords=enchant
>
>Scott
I found one libenchant2 in Deb
On Thu, Jan 03, 2019 at 10:43:12AM +0100, Jean-Marc Lasgouttes wrote:
> Le 02/01/2019 à 20:46, Scott Kostyshak a écrit :
> > Thanks. Just checked and almost all of them are gone. I still get the
> > following:
> >
> > In file included from
> > /home/scott/lyxbuilds/master_clang/repo/src/EnchantCh
Le 02/01/2019 à 20:46, Scott Kostyshak a écrit :
Thanks. Just checked and almost all of them are gone. I still get the
following:
In file included from
/home/scott/lyxbuilds/master_clang/repo/src/EnchantChecker.cpp:14:
/usr/include/enchant/enchant++.h:55:25: error: 'enchant::Exception::what' hi
On Wed, Jan 02, 2019 at 09:15:22PM +0100, Kornel Benko wrote:
> Am Mittwoch, 2. Januar 2019 14:10:49 CET schrieb Scott Kostyshak
> :
> > > Oh, I missed that. That explains it.
> >
> > Should I apply the attached patch?
>
> +1
>
> > Note the last part of the commit
> > message:
> >
> > The co
Am Mittwoch, 2. Januar 2019 14:10:49 CET schrieb Scott Kostyshak
:
> > Oh, I missed that. That explains it.
>
> Should I apply the attached patch?
+1
> Note the last part of the commit
> message:
>
> The consequence of ignoring this warning is that we will not catch
> any future regression
On Wed, Jan 02, 2019 at 06:53:09PM +0100, Jean-Marc Lasgouttes wrote:
> Le 01/01/2019 à 05:22, Scott Kostyshak a écrit :
> > When compiling master with clang, I get a lot of warnings. Almost all of
> > them are from -Winconsistent-missing-override. Are these worth
> > addressi
1 - 100 of 800 matches
Mail list logo
