Re: [LyX/master] Fix the way the top and bottom selection are drawn
On 2022-01-27 15:52, Jean-Marc Lasgouttes wrote: Le 27/01/2022 à 14:59, Daniel a écrit : I guess in Scott's after.png the selection looks a bit confusing (as in unexpected because other applications don't highlight that way). Isn't there another way to select the "Chapter" label? Do you have examples of applications that show labels on top of layouts? What we do now is that there is a 'tight' selection (inside the paragraph) and when the selection is over several paragraphs, the space between the paragraphs is painter too. What would you expect exactly? The previous behavior was ugly. Now one sees clearly when the selection is over two paragraphs. I could also decide to _never_ fill the gaps between paragraphs, but it will not be nice IMO. Selection inside the paragraph was not very pleasant either. See also how the selection was over the document bottom margin. JMarc Indeed many applications seem to just *never* fill the gaps. I guess it indicates the selection where the cursor can be and hence where editing can happen. So that would be one option. But at least LibreOffice fills the gaps. They also have a border around selections. I don't know whether these two are somehow related. Sure, keep the "LibreOffice style" selections. I haven't used it much but apparently it survived the scrutiny of LibreOffice users and developers. So that is good. Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Failure to compile with gcc-12 (2.3.x)
On Thu, Jan 27, 2022 at 03:07:25PM +, José Abílio Matos wrote: > On Thursday, 27 January 2022 13.09.09 WET Scott Kostyshak wrote: > > Except for that issue does it build with -Werror ? > > > > Scott > > As Jean-Marc said the compilation has lots of warnings. Some of them are not > our fault, so I am not sure if it is possible to filter system warnings from - > Werror. :-) Does 2.4.0dev compile with -Werror? What are the system warnings? Do you mean things like hunspell that we bundle? Scott signature.asc Description: PGP signature -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: SIGSEGV on master regarding math completion
On Thu, Jan 27, 2022 at 05:26:33PM +0100, Jean-Marc Lasgouttes wrote: > Le 10/01/2022 à 03:49, Scott Kostyshak a écrit : > > To reproduce: > > > > 1. Start a new document. > > 2. Ctrl + m to start math inset. > > 3. Type \phantomx. Note that \phantomx is not a command so don't > > expect it to be recognized. > > 4. Press , , to delete the "x" and the "m". > > 5. Type "m" to finish "phantom". > > 6. Wait for the completion pop-down to appear (this takes a second). > > 7. Press . > > > > I tried to find a more simple recipe to reproduce but could not. > > So, on Ubuntu 20.04, valgrind is more useful. I attache the log below, but > here is the gist of it: > > 1/ the error > > ==2557222== Invalid read of size 8 > ==2557222==at 0xB3B5C1: lyx::Inset::isBufferValid() const > (Inset.cpp:230) > [...] > ==2557222==by 0xA1382F: lyx::RowPainter::paintInset(lyx::Row::Element > const&) const (RowPainter.cpp:116) > > Here one can see that the code in devel-mode that paints in red insets that > do not have a buffer looks at buffer methods. This does not work because... > > 2/ the culprit > > ==2557222== Address 0xf9e0708 is 8 bytes inside a block of size 32 free'd > ==2557222==at 0x483CFBF: operator delete(void*) (in > /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) > ==2557222==by 0xA23A6E: lyx::InsetMathChar::~InsetMathChar() > (InsetMathChar.h:22) > [...] > lyx::InsetMathMacro::insertCompletion(lyx::Cursor&, > std::__cxx11::basic_string, > std::allocator > const&, bool) (InsetMathMacro.cpp:1376) > > We are pointing to an inset that has been deleted at completion time. > > > 3/ the context > > ==2557222== Block was alloc'd at > ==2557222==at 0x483BE63: operator new(unsigned long) (in > /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) > ==2557222==by 0xA22447: lyx::InsetMathChar::clone() const > (InsetMathChar.cpp:104) > [...] > lyx::InsetMathMacro::setDisplayMode(lyx::InsetMathMacro::DisplayMode, int) > (InsetMathMacro.cpp:825) > > > > So finally, the MathRow object points to an inset that has been deleted at > the time of the completion. There should be code somewhere that should > regenerate the math row. I'll have a look. Thanks for walking this through! The only part you skipped over is what did you do during the 20 minutes of wait-time while running with Valgrind? :) I do hope to go back to trying Valgrind when I find bugs and I made a note to study this case when I do. Scott signature.asc Description: PGP signature -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] Fix the way the top and bottom selection are drawn
On Thu, Jan 27, 2022 at 03:52:14PM +0100, Jean-Marc Lasgouttes wrote: > > Le 27/01/2022 à 14:59, Daniel a écrit : > > I guess in Scott's after.png the selection looks a bit confusing (as in > > unexpected because other applications don't highlight that way). Isn't > > there another way to select the "Chapter" label? > > Do you have examples of applications that show labels on top of layouts? > > What we do now is that there is a 'tight' selection (inside the paragraph) > and when the selection is over several paragraphs, the space between the > paragraphs is painter too. > > What would you expect exactly? The previous behavior was ugly. Now one sees > clearly when the selection is over two paragraphs. I could also decide to > _never_ fill the gaps between paragraphs, but it will not be nice IMO. > > Selection inside the paragraph was not very pleasant either. See also how > the selection was over the document bottom margin. I remember thinking your change was nice and I tested it at the time. I agree that the fix is really nice for the situation that you took a screenshot of. I did not expect the behavior I saw in the itemize, but if I understand correctly you're saying that the new behavior contains information. I think I could get used to it; it just looked weird to me when I first saw it. Scott signature.asc Description: PGP signature -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] Fix compilation with gcc-12
Am Thu, 27 Jan 2022 16:27:26 + schrieb José Abílio Matos : > On Thursday, 27 January 2022 15.44.56 WET José Abílio Matos wrote: > > The previous patch was all that it was required to compile lyx-2.4 with > > gcc-12. :-) > > But then it does not run: > > $ src/lyx > src/lyx: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.30' not found (required > by src/lyx) > > it is not using the new library. Is there any flag that can be passed to > configure to account for this? > > I can always run it as: > > $ LD_LIBRARY_PATH=/ src/lyx > > and it works... Proposing to add file 'i686-linux-gnu-gcc-something.conf' to '/etc/ld.so.conf.d/' with content /opt/gcc-latest/lib64 and then use $ sudo ldconfig Kornel pgpoMzixBT_7v.pgp Description: Digitale Signatur von OpenPGP -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Failure to compile with gcc-12 (2.3.x)
Am Thu, 27 Jan 2022 16:22:18 + schrieb José Abílio Matos : > On Thursday, 27 January 2022 15.48.33 WET Kornel Benko wrote: > > This one may be needed for 2.4.0 version of lyxfind.cpp too. > > You are right but for some reason I got away without this fix, only the > cstring of the other thread. (BTW I am puzzled) The reason could be some > change in the code between 2.3 and 2.4 but for the moment I am leaving this > out. If you compare the 2 files, you will encounter MANY differences :) Kornel pgpukFl9Cm5lp.pgp Description: Digitale Signatur von OpenPGP -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] Fix compilation with gcc-12
On Thursday, 27 January 2022 15.44.56 WET José Abílio Matos wrote: > The previous patch was all that it was required to compile lyx-2.4 with > gcc-12. :-) But then it does not run: $ src/lyx src/lyx: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.30' not found (required by src/lyx) it is not using the new library. Is there any flag that can be passed to configure to account for this? I can always run it as: $ LD_LIBRARY_PATH=/opt/gcc-latest/lib64/ src/lyx and it works... -- José Abílio-- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: SIGSEGV on master regarding math completion
Le 10/01/2022 à 03:49, Scott Kostyshak a écrit : To reproduce: 1. Start a new document. 2. Ctrl + m to start math inset. 3. Type \phantomx. Note that \phantomx is not a command so don't expect it to be recognized. 4. Press , , to delete the "x" and the "m". 5. Type "m" to finish "phantom". 6. Wait for the completion pop-down to appear (this takes a second). 7. Press . I tried to find a more simple recipe to reproduce but could not. So, on Ubuntu 20.04, valgrind is more useful. I attache the log below, but here is the gist of it: 1/ the error ==2557222== Invalid read of size 8 ==2557222==at 0xB3B5C1: lyx::Inset::isBufferValid() const (Inset.cpp:230) [...] ==2557222==by 0xA1382F: lyx::RowPainter::paintInset(lyx::Row::Element const&) const (RowPainter.cpp:116) Here one can see that the code in devel-mode that paints in red insets that do not have a buffer looks at buffer methods. This does not work because... 2/ the culprit ==2557222== Address 0xf9e0708 is 8 bytes inside a block of size 32 free'd ==2557222==at 0x483CFBF: operator delete(void*) (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) ==2557222==by 0xA23A6E: lyx::InsetMathChar::~InsetMathChar() (InsetMathChar.h:22) [...] lyx::InsetMathMacro::insertCompletion(lyx::Cursor&, std::__cxx11::basic_string, std::allocator > const&, bool) (InsetMathMacro.cpp:1376) We are pointing to an inset that has been deleted at completion time. 3/ the context ==2557222== Block was alloc'd at ==2557222==at 0x483BE63: operator new(unsigned long) (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) ==2557222==by 0xA22447: lyx::InsetMathChar::clone() const (InsetMathChar.cpp:104) [...] lyx::InsetMathMacro::setDisplayMode(lyx::InsetMathMacro::DisplayMode, int) (InsetMathMacro.cpp:825) So finally, the MathRow object points to an inset that has been deleted at the time of the completion. There should be code somewhere that should regenerate the math row. I'll have a look. JMarc==2557222== Memcheck, a memory error detector ==2557222== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==2557222== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info ==2557222== Command: src/lyx ==2557222== --2557222-- WARNING: unhandled amd64-linux syscall: 315 --2557222-- You may be able to write your own handler. --2557222-- Read the file README_MISSING_SYSCALL_OR_IOCTL. --2557222-- Nevertheless we consider this a bug. Please report --2557222-- it at http://valgrind.org/support/bug_reports.html. ==2557222== Invalid read of size 8 ==2557222==at 0xB3B5C1: lyx::Inset::isBufferValid() const (Inset.cpp:230) ==2557222==by 0xAEDCB1: lyx::MathRow::draw(lyx::PainterInfo&, int, int) const (MathRow.cpp:327) ==2557222==by 0xAAEB8B: lyx::MathData::draw(lyx::PainterInfo&, int, int) const (MathData.cpp:356) ==2557222==by 0xA6ABA4: lyx::InsetMathMacro::draw(lyx::PainterInfo&, int, int) const (InsetMathMacro.cpp:756) ==2557222==by 0xAED744: lyx::MathRow::draw(lyx::PainterInfo&, int, int) const (MathRow.cpp:330) ==2557222==by 0xAAEB8B: lyx::MathData::draw(lyx::PainterInfo&, int, int) const (MathData.cpp:356) ==2557222==by 0xA30FAC: lyx::InsetMathGrid::draw(lyx::PainterInfo&, int, int) const (InsetMathGrid.cpp:601) ==2557222==by 0xA4E187: lyx::InsetMathHull::draw(lyx::PainterInfo&, int, int) const (InsetMathHull.cpp:667) ==2557222==by 0xA1382F: lyx::RowPainter::paintInset(lyx::Row::Element const&) const (RowPainter.cpp:116) ==2557222==by 0xA14BBF: lyx::RowPainter::paintText() (RowPainter.cpp:563) ==2557222==by 0x909ABF: lyx::TextMetrics::drawParagraph(lyx::PainterInfo&, long, int, int) const (TextMetrics.cpp:2074) ==2557222==by 0x90CE4C: lyx::TextMetrics::draw(lyx::PainterInfo&, int, int) const (TextMetrics.cpp:1919) ==2557222== Address 0xf9e0708 is 8 bytes inside a block of size 32 free'd ==2557222==at 0x483CFBF: operator delete(void*) (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) ==2557222==by 0xA23A6E: lyx::InsetMathChar::~InsetMathChar() (InsetMathChar.h:22) ==2557222==by 0xAA3866: operator() (unique_ptr.h:81) ==2557222==by 0xAA3866: reset (unique_ptr.h:402) ==2557222==by 0xAA3866: operator= (unique_ptr.h:307) ==2557222==by 0xAA3866: operator= (MathAtom.h:49) ==2557222==by 0xAA3866: lyx::MathAtom::operator=(lyx::MathAtom const&) (MathAtom.cpp:34) ==2557222==by 0xA1F520: __copy_m (stl_algobase.h:342) ==2557222==by 0xA1F520: __copy_move_a (stl_algobase.h:404) ==2557222==by 0xA1F520: __copy_move_a2 > >, __gnu_cxx::__normal_iterator > > > (stl_algobase.h:440) ==2557222==by 0xA1F520: copy<__gnu_cxx::__normal_iterator > >, __gnu_cxx::__normal_iterator > > > (stl_algobase.h:474) ==2557222==by 0xA1F520: std::__cxx1998::vector >::operator=(std::__cxx1998::vector > const&) (vector.tcc:238) ==2557222==by 0xAD7D7E:
Re: Failure to compile with gcc-12 (2.3.x)
On Thursday, 27 January 2022 15.48.33 WET Kornel Benko wrote: > This one may be needed for 2.4.0 version of lyxfind.cpp too. You are right but for some reason I got away without this fix, only the cstring of the other thread. (BTW I am puzzled) The reason could be some change in the code between 2.3 and 2.4 but for the moment I am leaving this out. -- José Abílio-- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Failure to compile with gcc-12 (2.3.x)
Am Thu, 27 Jan 2022 15:05:34 + schrieb José Abílio Matos : > lyxfind.cpp:55:1: note: 'std::ostream_iterator' is defined in header > ''; did > you forget to '#include '? > > 54 | #include "support/regex.h" > > +++ |+#include > > 55 | This one may be needed for 2.4.0 version of lyxfind.cpp too. Kornel pgpldx2tbTzwL.pgp Description: Digitale Signatur von OpenPGP -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] Fix compilation with gcc-12
On Thursday, 27 January 2022 15.06.43 WET José Matos wrote: > commit b73ab0256d113571174fed4b2a3405fe8c44d297 > Author: José Matos > Date: Thu Jan 27 15:37:45 2022 + > > Fix compilation with gcc-12 > --- > src/insets/InsetListings.cpp |1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/src/insets/InsetListings.cpp b/src/insets/InsetListings.cpp > index 57df06e..67a0462 100644 > --- a/src/insets/InsetListings.cpp > +++ b/src/insets/InsetListings.cpp > @@ -41,6 +41,7 @@ > #include "frontends/alert.h" > #include "frontends/Application.h" > > +#include > #include > #include @Riki (or any other Fedora user), in case you are interested, this is my work flow: Install gcc-latest from copr: https://copr.fedorainfracloud.org/coprs/jwakely/gcc-latest/ Configure lyx to use it: $ configure --with-version-suffix=-devel CC=/opt/gcc-latest/bin/gcc CXX=/opt/gcc-latest/bin/g++ And that is it. :-) The previous patch was all that it was required to compile lyx-2.4 with gcc-12. :-) -- José Abílio-- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Failure to compile with gcc-12 (2.3.x)
On Thursday, 27 January 2022 13.09.09 WET Scott Kostyshak wrote: > Except for that issue does it build with -Werror ? > > Scott As Jean-Marc said the compilation has lots of warnings. Some of them are not our fault, so I am not sure if it is possible to filter system warnings from - Werror. :-) -- José Abílio-- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Failure to compile with gcc-12 (2.3.x)
On Thursday, 27 January 2022 13.52.56 WET Jean-Marc Lasgouttes wrote:
> This one is a warning, but you cut part of it out.
For complete sake the complete diagnose (warnings and errors) is here:
make[4]: Entering directory '/builddir/build/BUILD/lyx-2.3.6.1/src'
g++ -DHAVE_CONFIG_H -I. -I.. -I../src-I/usr/include/enchant
-I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/sysprof-4
-pthread -I/usr/include/hunspell -DQT_NO_STL -DQT_NO_KEYWORDS -DQT_CORE_LIB
-I/usr/include/qt5/QtCore -I/usr/include/qt5 -fPIC -O2 -flto=auto
-ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall
-Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
-std=c++14 -std=c++14 -O2 -flto=auto -ffat-lto-objects -fexceptions -g
-grecord-gcc-switches -pipe -Wall -Werror=format-security
-Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -c -o
lyxfind.o lyxfind.cpp
lyxfind.cpp: warning: -D_FORTIFY_SOURCE not defined
annobin: lyxfind.cpp: Warning: -D_GLIBCXX_ASSERTIONS not defined
lyxfind.cpp:73:28: warning: 'template
struct std::binary_function' is deprecated [-Wdeprecated-declarations]
73 | class MatchString : public binary_function
|^~~
In file included from /usr/include/c++/12/string:48,
from support/strfwd.h:42,
from lyxfind.h:19,
from lyxfind.cpp:17:
/usr/include/c++/12/bits/stl_function.h:131:12: note: declared here
131 | struct binary_function
|^~~
lyxfind.cpp: In function 'bool lyx::{anonymous}::regex_replace(const
std::string&, std::string&, const std::string&, const std::string&)':
lyxfind.cpp:677:9: error: 'ostream_iterator' was not declared in this scope
677 | ostream_iterator it(oss);
| ^~~~
lyxfind.cpp:55:1: note: 'std::ostream_iterator' is defined in header
''; did you forget to '#include '?
54 | #include "support/regex.h"
+++ |+#include
55 |
lyxfind.cpp:677:26: error: expected primary-expression before 'char'
677 | ostream_iterator it(oss);
| ^~~~
lyxfind.cpp:678:28: error: 'it' was not declared in this scope; did you mean
't'?
678 | lyx::regex_replace(it, s.begin(), s.end(), e, replacestr);
|^~
|t
--
José Abílio--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] Fix the way the top and bottom selection are drawn
Le 27/01/2022 à 14:59, Daniel a écrit : I guess in Scott's after.png the selection looks a bit confusing (as in unexpected because other applications don't highlight that way). Isn't there another way to select the "Chapter" label? Do you have examples of applications that show labels on top of layouts? What we do now is that there is a 'tight' selection (inside the paragraph) and when the selection is over several paragraphs, the space between the paragraphs is painter too. What would you expect exactly? The previous behavior was ugly. Now one sees clearly when the selection is over two paragraphs. I could also decide to _never_ fill the gaps between paragraphs, but it will not be nice IMO. Selection inside the paragraph was not very pleasant either. See also how the selection was over the document bottom margin. JMarc-- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] Fix the way the top and bottom selection are drawn
On 27/01/2022 14:34, Jean-Marc Lasgouttes wrote: Le 27/01/2022 à 14:06, Scott Kostyshak a écrit : On Tue, Dec 07, 2021 at 05:50:09PM +0100, Jean-Marc Lasgouttes wrote: commit 2fd8b6fc2a402c00e78f71d7d6ad986270283a3e Author: Jean-Marc Lasgouttes Date: Tue Dec 7 18:15:01 2021 +0100 Fix the way the top and bottom selection are drawn When a selection extends on more than a row, the space between the two rows should always be painted in full. Otherwise, with layouts like Chapter, the "Chapter" label may seem selected in part. --- I think this changed behavior in the attached example. See the before/after screenshots as well. Yes, it did. It is done to avoid a situation as in attachment. Do you have issues with it? JMarc I guess in Scott's after.png the selection looks a bit confusing (as in unexpected because other applications don't highlight that way). Isn't there another way to select the "Chapter" label? Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Failure to compile with gcc-12 (2.3.x)
Le 27/01/2022 à 14:09, Scott Kostyshak a écrit :
On Thu, Jan 27, 2022 at 01:04:12PM +, José Abílio Matos wrote:
Hi,
we are at the time of year again. :-)
The gcc project will release version 12 and in Fedora we are rebuilding all
packages with it.
There is a failure to build 2.3.x (e.g. on x86-54):
https://kojipkgs.fedoraproject.org//work/tasks/4412/81984412/build.log
73 | class MatchString : public binary_function
This one is a warning, but you cut part of it out.
|^~~
In file included from /usr/include/c++/12/string:48,
from support/strfwd.h:42,
from lyxfind.h:19,
from lyxfind.cpp:17:
/usr/include/c++/12/bits/stl_function.h:131:12: note: declared here
131 | struct binary_function
|^~~
lyxfind.cpp: In function 'bool lyx::{anonymous}::regex_replace(const std::string&,
std::string&, const std::string&, const std::string&)':
lyxfind.cpp:677:9: error: 'ostream_iterator' was not declared in this scope
677 | ostream_iterator it(oss);
| ^~~~
lyxfind.cpp:55:1: note: 'std::ostream_iterator' is defined in header '';
did you forget to '#include '?
54 | #include "support/regex.h"
+++ |+#include
Yes, sure.
Except for that issue does it build with -Werror ?
2.3.6 has many deprecation errors. Many of them are fixed in branch
2.3.x, but not all.
And it seems there are some new warnings. Let's see what happens with
our current branches.
José, what can you tell me about these messages?
annobin: Timeout.cpp: Warning: -D_GLIBCXX_ASSERTIONS not defined
We use _GLIBCXX_DEBUG currently. Should we switch to
_GLIBCXX_ASSERTIONS? I have not found the gcc docs very useful in this
respect.
JMarc
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] Fix the way the top and bottom selection are drawn
Le 27/01/2022 à 14:06, Scott Kostyshak a écrit : On Tue, Dec 07, 2021 at 05:50:09PM +0100, Jean-Marc Lasgouttes wrote: commit 2fd8b6fc2a402c00e78f71d7d6ad986270283a3e Author: Jean-Marc Lasgouttes Date: Tue Dec 7 18:15:01 2021 +0100 Fix the way the top and bottom selection are drawn When a selection extends on more than a row, the space between the two rows should always be painted in full. Otherwise, with layouts like Chapter, the "Chapter" label may seem selected in part. --- I think this changed behavior in the attached example. See the before/after screenshots as well. Yes, it did. It is done to avoid a situation as in attachment. Do you have issues with it? JMarc-- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Failure to compile with gcc-12 (2.3.x)
On Thu, Jan 27, 2022 at 01:04:12PM +, José Abílio Matos wrote:
> Hi,
> we are at the time of year again. :-)
>
> The gcc project will release version 12 and in Fedora we are rebuilding all
> packages with it.
>
> There is a failure to build 2.3.x (e.g. on x86-54):
> https://kojipkgs.fedoraproject.org//work/tasks/4412/81984412/build.log
>
>73 | class MatchString : public binary_function
> |^~~
> In file included from /usr/include/c++/12/string:48,
> from support/strfwd.h:42,
> from lyxfind.h:19,
> from lyxfind.cpp:17:
> /usr/include/c++/12/bits/stl_function.h:131:12: note: declared here
> 131 | struct binary_function
> |^~~
> lyxfind.cpp: In function 'bool lyx::{anonymous}::regex_replace(const
> std::string&, std::string&, const std::string&, const std::string&)':
> lyxfind.cpp:677:9: error: 'ostream_iterator' was not declared in this scope
> 677 | ostream_iterator it(oss);
> | ^~~~
> lyxfind.cpp:55:1: note: 'std::ostream_iterator' is defined in header
> ''; did you forget to '#include '?
>54 | #include "support/regex.h"
> +++ |+#include
>55 |
> lyxfind.cpp:677:26: error: expected primary-expression before 'char'
> 677 | ostream_iterator it(oss);
> | ^~~~
> lyxfind.cpp:678:28: error: 'it' was not declared in this scope; did you mean
> 't'?
> 678 | lyx::regex_replace(it, s.begin(), s.end(), e, replacestr);
> |^~
> |t
> This seems an example of a missing include, and g++ even suggests to add:
> #include
>
> Is there are better fix or is this OK?
>
> I will start to build 2.4 with g++-12 as well FWIW.
Except for that issue does it build with -Werror ?
Scott
signature.asc
Description: PGP signature
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] Fix the way the top and bottom selection are drawn
On Tue, Dec 07, 2021 at 05:50:09PM +0100, Jean-Marc Lasgouttes wrote: > commit 2fd8b6fc2a402c00e78f71d7d6ad986270283a3e > Author: Jean-Marc Lasgouttes > Date: Tue Dec 7 18:15:01 2021 +0100 > > Fix the way the top and bottom selection are drawn > > When a selection extends on more than a row, the space between the two > rows should always be painted in full. Otherwise, with layouts like > Chapter, the "Chapter" label may seem selected in part. > --- I think this changed behavior in the attached example. See the before/after screenshots as well. Scott example.23.lyx Description: application/lyx signature.asc Description: PGP signature -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Failure to compile with gcc-12 (2.3.x)
Hi,
we are at the time of year again. :-)
The gcc project will release version 12 and in Fedora we are rebuilding all
packages with it.
There is a failure to build 2.3.x (e.g. on x86-54):
https://kojipkgs.fedoraproject.org//work/tasks/4412/81984412/build.log
73 | class MatchString : public binary_function
|^~~
In file included from /usr/include/c++/12/string:48,
from support/strfwd.h:42,
from lyxfind.h:19,
from lyxfind.cpp:17:
/usr/include/c++/12/bits/stl_function.h:131:12: note: declared here
131 | struct binary_function
|^~~
lyxfind.cpp: In function 'bool lyx::{anonymous}::regex_replace(const
std::string&, std::string&, const std::string&, const std::string&)':
lyxfind.cpp:677:9: error: 'ostream_iterator' was not declared in this scope
677 | ostream_iterator it(oss);
| ^~~~
lyxfind.cpp:55:1: note: 'std::ostream_iterator' is defined in header
''; did you forget to '#include '?
54 | #include "support/regex.h"
+++ |+#include
55 |
lyxfind.cpp:677:26: error: expected primary-expression before 'char'
677 | ostream_iterator it(oss);
| ^~~~
lyxfind.cpp:678:28: error: 'it' was not declared in this scope; did you mean
't'?
678 | lyx::regex_replace(it, s.begin(), s.end(), e, replacestr);
|^~
|t
This seems an example of a missing include, and g++ even suggests to add:
#include
Is there are better fix or is this OK?
I will start to build 2.4 with g++-12 as well FWIW.
Best regards,
--
José Abílio--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
