Re: [RFC][PATCH] Change to buffer lookup for given temporary files

[Enrico Forestieri]

On Wed, Feb 19, 2020 at 10:33:45PM +0100, Stephan Witt wrote:
> 
> > Am 18.02.2020 um 19:55 schrieb Enrico Forestieri :
> > 
> > On Tue, Feb 18, 2020 at 07:36:54PM +0100, Enrico Forestieri wrote:
> >> On Tue, Feb 18, 2020 at 09:43:07AM +0100, Stephan Witt wrote:
> >>> 
> >>> Because I’m unable to test it with other PDF viewers with SyncTeX
> >>> support and/or to test it on Linux and Windows I post the patch
> >>> and it would be nice if you can test if it breaks something used
> >>> to work.
> >> 
> >> It works for me on linux and cygwin, but does not on native windows.
> >> Inserting some debug statements just before file_name and realtmp are
> >> compared produces the following (I use C:/cygwin/tmp as the tempdir):
> >> 
> >> file_name: C:/cygwin/tmp/LYX_TM~1.VSQ/LYX_TM~1/MANUSC~1.TEX
> >> realtmp:   C:/cygwin/tmp/lyx_tmpdir.vsQUbXBjkoun
> >> 
> >> Seemingly, the real path of file_name is returned in the short form, while
> >> that of realtmp is not. I don't know why.
> > 
> > Replacing the following two lines:
> > 
> > file_name = os::internal_path(trim(argument.substr(0, i)));
> > file_name = FileName(file_name).realPath();
> > 
> > with
> > file_name = os::internal_path(FileName(trim(argument.substr(0, 
> > i))).realPath());
> > 
> > it works also on native windows.
> 
> So, with this modification the patch would be acceptable?

Yes, I think so.

> > Still, why realPath() returns a short path name in one case and not in the
> > other case remains a mystery.
> 
> A lookup of the implementation of it in os_win32.cpp shows the beauty
> of the Windows APIs. =8(
> 
> What I wonder: there are the Qt elements used. Why don’t we rely
> on the services of QFileInfo class? E.g. canonicalFilePath() and
> friends? Are there historical reasons only?

Yes, at the time it was not possible using Qt in src/support.

-- 
Enrico
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: lyx crashes while menu navigating to the left

[Richard Kimberly Heck]

On 2/19/20 5:23 PM, V K wrote:
>
>
>
>
>
>
> On Wednesday, February 19, 2020, 11:36:58 PM GMT+2, V K  
> wrote: 
>
>
>
>
>
> I did exactly the same as you described once more and Lyx disappeared.
> Using Qt version 5.14.1 in /usr/lib.
>
>
>
>
>
>
> On Wednesday, February 19, 2020, 10:06:32 PM GMT+2, Richard Kimberly Heck 
>  wrote: 
>
>
>
>
>
> On 2/19/20 12:22 PM, V K wrote:
>
>> Steps to reproduce: navigate through menus with keyboard (arrows), let's 
>> say, menu Navigate, go deeper into sub-menu (Bookmarks – Save Bookmark 1) 
>> and if there will be no more sub-menu in the left but you press left arrow 
>> Lyx crashes and after relaunching there is no documents from last session. 
>> If you go right with arrow, this opens right to the active menu. If you go 
>> to the left from menu item that hasn't sub menu (let's say, Navigate – Next 
>> Note), Lyx is not crashing and that opens next to the left menu.
>>
>>
>>
>>
>> Sorry for the lapsus lingua: not left, but right and vice versa in all my 
>> text.
>> My setup: Manjaro Linux, Lyx 2.3.4.
>
> Can you give more detailed instructions? Here's what I did (using
> English GUI):
>
> 1. Alt-N, to open the Navigate menu
>
> 2. Bookmarks is highlighted, so hit right arrow to open that menu.
>
> 3. Hit right arrow again. This takes me to the Document menu.
>
> What version of Qt is installed on your machine?
>
>
>
> I think, I narrowed the cause. I'm working in Wayland (Sway). There is no 
> crash when I'm launching Lyx with xwayland (as "QT_QPA_PLATFORM=xcb lyx") and 
> hitting right when I am in the Bookmarks sub-menu takes me to the Document 
> menu. But Lyx in Wayland crashes when I do the same.
> I just receive your mail. Yes, it's Wayland.

I'm forwarding this, then, to the devel list. As I said, we've seen some
issues with Wayland, though my sense is that these are Qt issues,
mostly, not LyX issues (though they become LyX issues, since we depend
upon Qt).

If you have an option to try other Qt versions, that also could be helpful.


>  One more small thing Alt-I (to open Insert menu) isn't working when you 
> press it first after launching program while other menus all are working. 
> After launching some other menu by Alt Alt-I is working. That is in Wayland 
> and X11.

This sounds like it could be a shortcut conflict. Some wm's capture
keystrokes and interfere with LyX's own capturing of keystrokes. There's
not much we an do about that---if we never see the keystroke, we can't
respond to it. Hard to know if that's your issue or not.

Riki



-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: [ANNOUNCE] LyX 2.3.4.2 'Emergency' Release

[Liviu Andronic]

On 2/11/20, Richard Kimberly Heck  wrote:
>
> This is an emergency release that fixes four bugs in 2.3.4. Only the
> first two really warrant an emergency release, but while we're at it...
>
Ubuntu packages are now available on the PPA:
https://launchpad.net/~lyx-devel/+archive/ubuntu/release


Liviu


> The first, bug #11728, caused a five-second delay when attempting
> to save files on Windows. This was a side effect of the fix for #10091
> and reminds us why it would be good to have more testing on Windows.
>
> The second bug is discussed in this thread
> https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg210294.html
> and concerns a crash related to the math toolbar. This was due to an
> uninitialize buffer_ member revealed by the fix for #11586.
>
> The third, bug #11724, affects Beamer presentations and causes bad output
> when page geometry is set in certain ways. LyX should and how does ignore
> such settings.
>
> The last, bug #11579, is an old one, but a serious one, that prevents
> the use of CJKUtf8 in ERT. It's a straightforward fix for a bug that is
> pretty serious for people who encounter it.
>
> All LyX users are encouraged to upgrade to 2.3.4.2.
>
> --
> lyx-users mailing list
> lyx-us...@lists.lyx.org
> http://lists.lyx.org/mailman/listinfo/lyx-users
>
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: clang Warning: Padding Class...

[Richard Kimberly Heck]

On 2/19/20 9:56 PM, Scott Kostyshak wrote:
> On Wed, Feb 19, 2020 at 05:08:47PM -0500, Richard Kimberly Heck wrote:
>
>> On 2/19/20 4:48 PM, Jean-Marc Lasgouttes wrote:
>>> It is a good idea to have correct padding by reordering members, even if 
>>> the memory gains are minimal for buffer::impl . Do you have that for other 
>>> classes ?
>> I have seen it elsewhere, but I can't remember where. There are so many
>> different warnings (a lot of them '0 used as nullptr', which Stephan
>> also mentioned), so it can be hard to sort through them. I'm going to
>> try to fix these as I have time. It's mindless...
> How do you see the warnings? I've only used QtCreator when working with
> .ui files.

I don't do anything unexpected. Basically:

Start up QtCreator.

Choose "New Project". Then choose LYX/CMakeLists.txt, where LYX is the
path to where your git repo lives. (This is not well documented. Hey,
Andre, are you seeing this!?)

You'll be asked now about lots of build options under the "Desktop" kit.
I basically choose just one of those (default), and fix the path for it
so that it lives under the LYX directory, but you can do as you wish.
You can adjust the build options later, if you want, as well.

Now, if I open, e.g., Buffer.cpp, it automatically gets run through
clang and the warnings are reported in the "issues" tab.

Riki


-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: clang Warning: Padding Class...

[Scott Kostyshak]

On Wed, Feb 19, 2020 at 05:08:47PM -0500, Richard Kimberly Heck wrote:

> On 2/19/20 4:48 PM, Jean-Marc Lasgouttes wrote:
> > It is a good idea to have correct padding by reordering members, even if 
> > the memory gains are minimal for buffer::impl . Do you have that for other 
> > classes ?
> 
> I have seen it elsewhere, but I can't remember where. There are so many
> different warnings (a lot of them '0 used as nullptr', which Stephan
> also mentioned), so it can be hard to sort through them. I'm going to
> try to fix these as I have time. It's mindless...

How do you see the warnings? I've only used QtCreator when working with
.ui files.

Scott


signature.asc
Description: PGP signature
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: LaTeX3 Error: Backend request inconsistent with engine: using 'pdfmode'

[Scott Kostyshak]

On Mon, Feb 03, 2020 at 04:44:07PM +0100, Kornel Benko wrote:
> Am Mon, 3 Feb 2020 10:42:06 -0500
> schrieb Scott Kostyshak :
> 
> > On Mon, Feb 03, 2020 at 04:29:34PM +0100, Kornel Benko wrote:
> > > 
> > > This is for instance with examples/Presentations/Foils.lyx trying to use 
> > > pdflatex.
> > > Same error witth lualatex.
> > > OTOH, if compiled first to dvi, also pdflatex and lualatex compile fine.  
> > 
> > For me the compilation with pdflatex works fine on master, but I have an
> > outdated TeX Live version (and I don't want to update right now since I
> > don't want to break compilations I need for work).
> > 
> > Remind me in a week or so if there is still a mystery and I can test on
> > an updated TL once I get my Virtual Box setup working again.
> > 
> > Scott
> 
> I hope, I don't forget. :)

I tested on an updated TL. Removing the custom class option dvips fixes
it. However, I'm not sure this is the right thing to do. In the inverted
tests, we have the following:

  # Comment by Jürgen Spitzmüller
  # The document requests the dvips graphics driver,
  # and of course this fails with any other backend.
  #
  # The document compiles if one sets the graphics driver to "Automatic"
  # and remove the dvips class option. But then, the output is not correct
  # (rotation of foils does not work).
  export/examples/(|fr/)Presentations/Foils_pdf[45]_systemF

The output does not seem to change with or without the option for pdf2
format, but the above comment suggests it does for other formats.

I don't know if the change in latex3 was intended. For example, here's a
related issue:

  https://github.com/latex3/latex3/issues/677
  
https://tex.stackexchange.com/questions/529129/backend-inconsistent-error-when-using-xelatex-with-dvisvgm-backend

Does anyone know whether the change is intended or should we file a bug
report?

Scott


signature.asc
Description: PGP signature
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Perl and Indexing? [Re: Building windows installer questions]

[Richard Kimberly Heck]

On 2/19/20 4:42 PM, Jean-Marc Lasgouttes wrote:
>
> Le 19 février 2020 21:11:43 GMT+01:00, Richard Kimberly Heck 
>  a écrit :
>> Actually, just saw in the change log: "install a stripped-down version
>> of Perl to be able to use LyX's feature to have several indexes also
>> when LyX is installed without admin privileges". I guess this must be
>> because one of the indexing things uses Perl? Jürgen, do you know about
>> this?
> The Perl scripts for indexing have been converted to python a long time ago. 
> What is the change log entry date ?

It's from LyX 2.0.7, March 2014. But I had in mind stuff installed by
LaTeX, not our own scripts. E.g., is xindy written in Perl? What tools
do we actually require here?

Riki


-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: clang Warning: Padding Class...

[Richard Kimberly Heck]

>
> Le 19 février 2020 21:24:15 GMT+01:00, Richard Kimberly Heck
 a écrit :
>> I'm seeing a lot of warnings in QtCreator of the form:
>>
>> Buffer.cpp:219:11: warning: padding class 'lyx::Buffer::Impl' with 3
>> bytes to align 'filename'
>>
>> I take it that this is because there were five bools right before this
>> declaration. Do we care about this?
>

On 2/19/20 4:48 PM, Jean-Marc Lasgouttes wrote:
> It is a good idea to have correct padding by reordering members, even if the 
> memory gains are minimal for buffer::impl . Do you have that for other 
> classes ?

I have seen it elsewhere, but I can't remember where. There are so many
different warnings (a lot of them '0 used as nullptr', which Stephan
also mentioned), so it can be hard to sort through them. I'm going to
try to fix these as I have time. It's mindless...


> Note that padding needs are not the same for 32bist and 64bits, and probably 
> not the same for Linux and windows.

Mostly these seem like 8-bit boundaries, but who knows. Putting bools at
the end seems an easy way to deal with it. Probably means re-ordering
initialization code, but not much else.

Riki


-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: clang Warning: Padding Class...

[Jean-Marc Lasgouttes]

It is a good idea to have correct padding by reordering members, even if the 
memory gains are minimal for buffer::impl . Do you have that for other classes ?

Note that padding needs are not the same for 32bist and 64bits, and probably 
not the same for Linux and windows.

JMarc

Le 19 février 2020 21:24:15 GMT+01:00, Richard Kimberly Heck  
a écrit :
>I'm seeing a lot of warnings in QtCreator of the form:
>
>Buffer.cpp:219:11: warning: padding class 'lyx::Buffer::Impl' with 3
>bytes to align 'filename'
>
>I take it that this is because there were five bools right before this
>declaration. Do we care about this?

-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: [PATCH] Fix write to uninitialized bytes for XCB event

[Jean-Marc Lasgouttes]

Le 19 février 2020 22:25:31 GMT+01:00, Pavel Sanda  a écrit :
>So the oldest distro on which I regularly compile lyx master has gcc
>4.8.
>Because I suspect no one around is using even older config we can't
>really
>guarantee 4.7 (stand up if I am wrong) so we should change INSTALL
>instructions
>to 4.8 and freely use the suggested alignas(32).

I was not aware that 4.7 did not have full c++11 support. We should definitely 
require 4.8, or add whatever does not work with 4.7 to our test code for c++11.

Jmarc
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Perl and Indexing? [Re: Building windows installer questions]

[Jean-Marc Lasgouttes]

Le 19 février 2020 21:11:43 GMT+01:00, Richard Kimberly Heck  
a écrit :
>Actually, just saw in the change log: "install a stripped-down version
>of Perl to be able to use LyX's feature to have several indexes also
>when LyX is installed without admin privileges". I guess this must be
>because one of the indexing things uses Perl? Jürgen, do you know about
>this?

The Perl scripts for indexing have been converted to python a long time ago. 
What is the change log entry date ?

JMarc
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Perl and Indexing? [Re: Building windows installer questions]

[Jean-Marc Lasgouttes]

Le 19 février 2020 21:47:05 GMT+01:00, Kornel Benko  a écrit :
>> I'm trying to remember why LyX needs Perl on Windows. If it were
>> possible to avoid it, that would be worth doing.
>
>Texlive has many perl scripts (in TL19 ~ 237).

If it does, I guess it provides the relevant interpreter, doesn't it ?

JMarc
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: [RFC][PATCH] Change to buffer lookup for given temporary files

[Stephan Witt]

> Am 18.02.2020 um 19:55 schrieb Enrico Forestieri :
> 
> On Tue, Feb 18, 2020 at 07:36:54PM +0100, Enrico Forestieri wrote:
>> On Tue, Feb 18, 2020 at 09:43:07AM +0100, Stephan Witt wrote:
>>> 
>>> Because I’m unable to test it with other PDF viewers with SyncTeX
>>> support and/or to test it on Linux and Windows I post the patch
>>> and it would be nice if you can test if it breaks something used
>>> to work.
>> 
>> It works for me on linux and cygwin, but does not on native windows.
>> Inserting some debug statements just before file_name and realtmp are
>> compared produces the following (I use C:/cygwin/tmp as the tempdir):
>> 
>> file_name: C:/cygwin/tmp/LYX_TM~1.VSQ/LYX_TM~1/MANUSC~1.TEX
>> realtmp:   C:/cygwin/tmp/lyx_tmpdir.vsQUbXBjkoun
>> 
>> Seemingly, the real path of file_name is returned in the short form, while
>> that of realtmp is not. I don't know why.
> 
> Replacing the following two lines:
> 
>   file_name = os::internal_path(trim(argument.substr(0, i)));
>   file_name = FileName(file_name).realPath();
> 
> with
>   file_name = os::internal_path(FileName(trim(argument.substr(0, 
> i))).realPath());
> 
> it works also on native windows.

So, with this modification the patch would be acceptable?

I’ve attached it with your modification.

> Apparently, the only purpose of
> internal_path() on windows is returning the long form of the path
> (other than converting backslashes into slashes).

Yes, indeed. The implementation of internal_path() on windows uses the
GetLongPathNameW() function.

https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-getlongpathnamew

> Still, why realPath() returns a short path name in one case and not in the
> other case remains a mystery.

A lookup of the implementation of it in os_win32.cpp shows the beauty
of the Windows APIs. =8(

What I wonder: there are the Qt elements used. Why don’t we rely
on the services of QFileInfo class? E.g. canonicalFilePath() and
friends? Are there historical reasons only?

Stephan



goToFileRow-6.patch
Description: Binary data
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: [PATCH] Fix write to uninitialized bytes for XCB event

[Pavel Sanda]

On Wed, Feb 19, 2020 at 06:13:08PM +0100, Pavel Sanda wrote:
> > We are requiring C++11 these days, right?
> 
> Can't remember, notions of gcc 4.7 in INSTALL is not strongly indicative of 
> that ;)
> Need to check whether one of my antique system still compiles with 4.7 or 4.8,
> maybe we can bump to 4.8.

So the oldest distro on which I regularly compile lyx master has gcc 4.8.
Because I suspect no one around is using even older config we can't really
guarantee 4.7 (stand up if I am wrong) so we should change INSTALL instructions
to 4.8 and freely use the suggested alignas(32).

Pavel
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Perl and Indexing? [Re: Building windows installer questions]

[Kornel Benko]

Am Wed, 19 Feb 2020 15:11:43 -0500
schrieb Richard Kimberly Heck :

> On 2/19/20 1:01 PM, Yu Jin wrote:
> >  
> > Am Mi., 19. Feb. 2020 um 17:04 Uhr schrieb Richard Kimberly Heck
> > mailto:rikih...@lyx.org>>:
> >
> > If you do update these other tools, please send me a zip of the
> > dependencies package, so I can use it as well. (It'll be best to
> > put that somewhere on the web I can download it, if possible, as
> > it would make for a BIG mail attachment.)
> >
> > Ok, sounds good. I have found newer versions of most of the stuff.
> > Could not find the small Perl version though. If I download it from
> > here: http://strawberryperl.com/ , I get a huge version with a lot of
> > files in there. How do you usually stripp it down?
> 
> I never have done that. What's there now is left over from when Uwe was
> responsible.
> 
> I'm trying to remember why LyX needs Perl on Windows. If it were
> possible to avoid it, that would be worth doing.

Texlive has many perl scripts (in TL19 ~ 237).

> Actually, just saw in the change log: "install a stripped-down version
> of Perl to be able to use LyX's feature to have several indexes also
> when LyX is installed without admin privileges". I guess this must be
> because one of the indexing things uses Perl? Jürgen, do you know about
> this?
> 
> Riki
> 

Kornel


pgpdtnY6u8Mx2.pgp
Description: Digitale Signatur von OpenPGP
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Assertion

[Richard Kimberly Heck]

On 2/19/20 11:38 AM, Daniel wrote:
> I just navigated between child documents using the outliner's Table of
> Contents as a dialog appeared (attached). Any idea what this might be
> about?

No, that's an obscure one. The DocIterator is invalid, but why? No clue
without a backtrace or a way to reproduce.

Riki


-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

clang Warning: Padding Class...

[Richard Kimberly Heck]

I'm seeing a lot of warnings in QtCreator of the form:

Buffer.cpp:219:11: warning: padding class 'lyx::Buffer::Impl' with 3
bytes to align 'filename'

I take it that this is because there were five bools right before this
declaration. Do we care about this?

Riki


-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Perl and Indexing? [Re: Building windows installer questions]

[Richard Kimberly Heck]

On 2/19/20 1:01 PM, Yu Jin wrote:
>  
> Am Mi., 19. Feb. 2020 um 17:04 Uhr schrieb Richard Kimberly Heck
> mailto:rikih...@lyx.org>>:
>
> If you do update these other tools, please send me a zip of the
> dependencies package, so I can use it as well. (It'll be best to
> put that somewhere on the web I can download it, if possible, as
> it would make for a BIG mail attachment.)
>
> Ok, sounds good. I have found newer versions of most of the stuff.
> Could not find the small Perl version though. If I download it from
> here: http://strawberryperl.com/ , I get a huge version with a lot of
> files in there. How do you usually stripp it down?

I never have done that. What's there now is left over from when Uwe was
responsible.

I'm trying to remember why LyX needs Perl on Windows. If it were
possible to avoid it, that would be worth doing.

Actually, just saw in the change log: "install a stripped-down version
of Perl to be able to use LyX's feature to have several indexes also
when LyX is installed without admin privileges". I guess this must be
because one of the indexing things uses Perl? Jürgen, do you know about
this?

Riki


-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: [PATCH] Fix write to uninitialized bytes for XCB event

[Enrico Forestieri]

On Wed, Feb 19, 2020 at 01:19:54PM -0500, Scott Kostyshak wrote:
> 
> It seems I committed too soon. Sorry for not waiting. Both the macro
> approach and Enrico's proposal are cleaner than my approach. I was
> planning to pursue the macro approach in a follow-up commit.

Apparently, the macro approach was abandoned by the Qt folks.

> Regarding
> C++11, don't we already use range-based for loops? Or is the question
> about if we require *all* of C++11?

The latter. As shown by Pavel in the other post gcc 4.7 is lacking
something. As we use xcb_selection_notify_event_t only in one place,
I think defining a macro is overkill. In order to avoid many calls
to calloc() (I don't know how memory fragmentation is dealt with by
modern compilers), we could anyway use that idea as follows:

union {
xcb_selection_notify_event_t event;
char padding[32];
} padded_event;
auto & nev = padded_event.event;

-- 
Enrico
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: [PATCH] Fix write to uninitialized bytes for XCB event

[Scott Kostyshak]

On Wed, Feb 19, 2020 at 07:22:36PM +0100, Pavel Sanda wrote:
> On Wed, Feb 19, 2020 at 06:28:51PM +0100, Enrico Forestieri wrote:
> > Uh? In the Requirements section I read:
> > 
> >   First of all, you will need a C++11 standard conforming compiler, like gcc
> >   (at least 4.7) or clang.
> 
> My undesrtanding was that only 4.8 is C++11 complete, especially wrt 
> alignment support:
> https://gcc.gnu.org/gcc-4.7/cxx0x_status.html
> 
> > I could not find the macro you mention in the current Qt sources (5.14.1),
> > but I found the following in src/plugins/platforms/xcb/xcbconnection.h
> > 
> > template 
> > struct alignas(32) q_padded_xcb_event : T { };
> > 
> > which is then used as
> > q_padded_xcb_event event = {};
> 
> Indeed, and now I know why:
> 
> https://github.com/qt/qtbase/commit/41705529d9995291324e1d06d45861ce63b1c72e#diff-5ee6702ad3813956cbebf9e7be8859d8
> 
> So we are at your solution anyway :)

Should I revert then? Or Enrico do you want to just commit your solution
on top of what I committed?

Scott


signature.asc
Description: PGP signature
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: [PATCH] Fix write to uninitialized bytes for XCB event

[Pavel Sanda]

On Wed, Feb 19, 2020 at 06:28:51PM +0100, Enrico Forestieri wrote:
> Uh? In the Requirements section I read:
> 
>   First of all, you will need a C++11 standard conforming compiler, like gcc
>   (at least 4.7) or clang.

My undesrtanding was that only 4.8 is C++11 complete, especially wrt alignment 
support:
https://gcc.gnu.org/gcc-4.7/cxx0x_status.html

> I could not find the macro you mention in the current Qt sources (5.14.1),
> but I found the following in src/plugins/platforms/xcb/xcbconnection.h
> 
> template 
> struct alignas(32) q_padded_xcb_event : T { };
> 
> which is then used as
>   q_padded_xcb_event event = {};

Indeed, and now I know why:

https://github.com/qt/qtbase/commit/41705529d9995291324e1d06d45861ce63b1c72e#diff-5ee6702ad3813956cbebf9e7be8859d8

So we are at your solution anyway :)
Pavel
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: [PATCH] Fix write to uninitialized bytes for XCB event

[Scott Kostyshak]

On Wed, Feb 19, 2020 at 06:28:51PM +0100, Enrico Forestieri wrote:
> On Wed, Feb 19, 2020 at 06:13:08PM +0100, Pavel Sanda wrote:
> > On Wed, Feb 19, 2020 at 05:24:46PM +0100, Enrico Forestieri wrote:
> > > > Did not try, but I am afraid generally it won't, because 
> > > > xcb_selection_notify_event_t is not enforced to have 32 bits,
> > > > while that's requested by underlying X routines. That's why
> > > > the padding by 0s.
> > > 
> > > Ok, then probably a simple
> > >   alignas(32) xcb_selection_notify_event_t nev;
> > > would have worked.
> > 
> > Nice.
> > 
> > > We are requiring C++11 these days, right?
> > 
> > Can't remember, notions of gcc 4.7 in INSTALL is not strongly indicative of 
> > that ;)
> 
> Uh? In the Requirements section I read:
> 
>   First of all, you will need a C++11 standard conforming compiler, like gcc
>   (at least 4.7) or clang.
> 
> > Need to check whether one of my antique system still compiles with 4.7 or 
> > 4.8,
> > maybe we can bump to 4.8.
> > 
> > In any case I still tend to prefer using Qt macro (not because of technical
> > superiority but because if API changes then Qt folks will probably hit and
> > fix it sooner than we will).
> 
> I could not find the macro you mention in the current Qt sources (5.14.1),
> but I found the following in src/plugins/platforms/xcb/xcbconnection.h
> 
> template 
> struct alignas(32) q_padded_xcb_event : T { };
> 
> which is then used as
>   q_padded_xcb_event event = {};

It seems I committed too soon. Sorry for not waiting. Both the macro
approach and Enrico's proposal are cleaner than my approach. I was
planning to pursue the macro approach in a follow-up commit. Regarding
C++11, don't we already use range-based for loops? Or is the question
about if we require *all* of C++11?

Scott


signature.asc
Description: PGP signature
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Building windows installer questions

[Yu Jin]

Am Mi., 19. Feb. 2020 um 17:04 Uhr schrieb Richard Kimberly Heck <
rikih...@lyx.org>:

> If you do update these other tools, please send me a zip of the
> dependencies package, so I can use it as well. (It'll be best to put that
> somewhere on the web I can download it, if possible, as it would make for a
> BIG mail attachment.)
>
Ok, sounds good. I have found newer versions of most of the stuff. Could
not find the small Perl version though. If I download it from here:
http://strawberryperl.com/ , I get a huge version with a lot of files in
there. How do you usually stripp it down?

Eugene
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: [PATCH] Fix write to uninitialized bytes for XCB event

[Enrico Forestieri]

On Wed, Feb 19, 2020 at 06:13:08PM +0100, Pavel Sanda wrote:
> On Wed, Feb 19, 2020 at 05:24:46PM +0100, Enrico Forestieri wrote:
> > > Did not try, but I am afraid generally it won't, because 
> > > xcb_selection_notify_event_t is not enforced to have 32 bits,
> > > while that's requested by underlying X routines. That's why
> > > the padding by 0s.
> > 
> > Ok, then probably a simple
> > alignas(32) xcb_selection_notify_event_t nev;
> > would have worked.
> 
> Nice.
> 
> > We are requiring C++11 these days, right?
> 
> Can't remember, notions of gcc 4.7 in INSTALL is not strongly indicative of 
> that ;)

Uh? In the Requirements section I read:

  First of all, you will need a C++11 standard conforming compiler, like gcc
  (at least 4.7) or clang.

> Need to check whether one of my antique system still compiles with 4.7 or 4.8,
> maybe we can bump to 4.8.
> 
> In any case I still tend to prefer using Qt macro (not because of technical
> superiority but because if API changes then Qt folks will probably hit and
> fix it sooner than we will).

I could not find the macro you mention in the current Qt sources (5.14.1),
but I found the following in src/plugins/platforms/xcb/xcbconnection.h

template 
struct alignas(32) q_padded_xcb_event : T { };

which is then used as
q_padded_xcb_event event = {};

-- 
Enrico
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: [PATCH] Fix write to uninitialized bytes for XCB event

[Pavel Sanda]

On Wed, Feb 19, 2020 at 05:24:46PM +0100, Enrico Forestieri wrote:
> > Did not try, but I am afraid generally it won't, because 
> > xcb_selection_notify_event_t is not enforced to have 32 bits,
> > while that's requested by underlying X routines. That's why
> > the padding by 0s.
> 
> Ok, then probably a simple
>   alignas(32) xcb_selection_notify_event_t nev;
> would have worked.

Nice.

> We are requiring C++11 these days, right?

Can't remember, notions of gcc 4.7 in INSTALL is not strongly indicative of 
that ;)
Need to check whether one of my antique system still compiles with 4.7 or 4.8,
maybe we can bump to 4.8.

In any case I still tend to prefer using Qt macro (not because of technical
superiority but because if API changes then Qt folks will probably hit and
fix it sooner than we will).

Pavel
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Assertion

[Daniel]

I just navigated between child documents using the outliner's Table of 
Contents as a dialog appeared (attached). Any idea what this might be about?


Daniel
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: [PATCH] Fix write to uninitialized bytes for XCB event

[Enrico Forestieri]

On Wed, Feb 19, 2020 at 08:42:57AM +0100, Pavel Sanda wrote:
> On Wed, Feb 19, 2020 at 08:24:43AM +0100, Enrico Forestieri wrote:
> > On Tue, Feb 18, 2020 at 09:49:08PM -0500, Scott Kostyshak wrote:
> > > 
> > > Attached is a patch. I really don't know what I'm doing. The use of
> > > calloc scares me. I just used the xcb_send_event man page and
> > > experimented until compilation and valgrind did not complain.
> > > 
> > > Could anyone take a close look at this? If there is a better fix, please
> > > go ahead.
> > 
> > Does simply replacing
> > xcb_selection_notify_event_t nev;
> > with
> > xcb_selection_notify_event_t nev = {0};
> > help?
> 
> Did not try, but I am afraid generally it won't, because 
> xcb_selection_notify_event_t is not enforced to have 32 bits,
> while that's requested by underlying X routines. That's why
> the padding by 0s.

Ok, then probably a simple
alignas(32) xcb_selection_notify_event_t nev;
would have worked. We are requiring C++11 these days, right?

-- 
Enrico
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Building windows installer questions

[Richard Kimberly Heck]

On 2/18/20 5:08 AM, Yu Jin wrote:
>
> Am Sa., 15. Feb. 2020 um 18:38 Uhr schrieb Richard Kimberly Heck
> mailto:rikih...@lyx.org>>:
>
> FYI, I updated ImageMagick in the most recent installers. I
> haven't uploaded the new stuff yet to the dependencies file online.
>
> I see, I have also looked into the files of the dependencies folder,
> where to find them, in case I wanted to update them, just to
> understand what is actually in that installer. I have found the other
> tools, like netpbm, DTL and rsvg-convert. I could also update those,
> what do you think? Is it worth doing?

It is probably worth our keeping these updated, though of course we also
would want some testing with the new versions before releasing with
them. I've been meaning for a while to provide 'testing' installers for
Windows, say every month or so, but just haven't had time. There are
enough sophisticated Windows users who follow the lists that we'd
presumably get some feedback, and maybe avoid problems like the ones
that led to 2.3.4.x.

If you do update these other tools, please send me a zip of the
dependencies package, so I can use it as well. (It'll be best to put
that somewhere on the web I can download it, if possible, as it would
make for a BIG mail attachment.)

Riki



-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: bug in "view" option

[Richard Kimberly Heck]

On 2/19/20 3:11 AM, Sivan Frenkel wrote:
> Hi,
>
> Oddly, I have not been experiencing today the bug that I have reported
> yesterday, and the "view" button works fine. I will be in touch if I
> could figure out when and how this bug appears.
>
> Sorry for the mess.

No problem, but I'll add that it is difficult to see how this could vary
from 2.3.4 to 2.3.4.3, given what the differences between the versions are.

At least it works for you now!

Riki



> On Tuesday, February 18, 2020, 10:52:36 AM GMT+2, Sivan Frenkel
>  wrote:
>
>
> Hi,
>
> I am using Win10 and have just updated from version 2.3.4 to 2.3.4.3.
> The update did solve the delay in saving, but seems to have created a
> new bug.
>
> The bug interferes with the use of "view" command. I am using Adobe
> Reader to views PDF files (I am using Adobe Reader DC version
> 2020.006.20034). When pressing the view button, just after a
> "successful preview", instead of opening the PDF file I get an error
> "The instruction at 0x7787C19E referenced memory at
> 0x. The memory could not be read". See below a picture
> of the error message. It is not clear to me whether its an OS error or
> an Acrobat error.
>
> When I use "File>Export>PDF (pdflatex)" the pdf is created and is
> opened using the Acrobat Reader without a problem. Nevertheless, this
> is clearly less convenient than the single button option.
>
> This must be a new bug, as it never happened before, and didn't happen
> in ver 2.3.4.
>
> Thank you very much for all your help. LyX is fantastic.
>
> Best,
> Sivan
>
> *
> *Sivan Frenkel
> Lecturer in Finance (Assistant Professor)
> Coller School of Management
> Tel Aviv University
> https://sites.google.com/site/siv
> anfrenkel/
> 
>
> Inline image
>
>

-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: [PATCH] Fix write to uninitialized bytes for XCB event

[Pavel Sanda]

On Wed, Feb 19, 2020 at 09:56:20AM -0500, Scott Kostyshak wrote:
> If there is interest, I can work on a patch for using the macro.

It would reduce the work of relearning the topic for someone
stumbling upon this TODO in 5 years.

> Should I condition on the Qt version and if it is less than 5.6.3 define the
> macro?

Yes, that was the idea.
Pavel
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Memory leak from list

[Scott Kostyshak]

On Wed, Feb 19, 2020 at 08:52:18AM +, Neven Sajko wrote:
> > Well, actually the hardest part is waiting because LyX is very slow when 
> > run under valgrind.
> 
> Try sanitizers instead. They are instrumentation that GCC or Clang can
> include in executables. They do basically the same thing as Valgrind,
> but should be much faster and since you are already compiling your own
> Lyx and Qt, the sanitizers should be a more appropriate tool. There

I do not always compile Qt. On my last attempt to compile Qt I came
across an error and just used the pre-built libraries (and I think the
corresponding -dbg packages). I did not initially realize that compiling
Qt with the address sanitizers would make a big difference, but now I
think I see the intuition: LyX might be responsible for a sanitizer
error at the Qt level, and we would only catch that if we compile Qt
with the address sanitizers.

> are four sanitizers that you may want to compile with: asan, tsan,
> msan, ubsan; each for a different class of bugs.
> 
> Instructions: include -fsanitize=asan (replace asan with wanted
> sanitizer if you want another one) to both compilation and linking
> commands (GCC or Clang) of all libraries and code. It is also a good
> idea to disable some compiler optimizations, in particular one should
> use -fno-omit-frame-pointer. See
> https://github.com/google/sanitizers/wiki for more information.
> 
> By default the error reports will be output to stderr, but it is
> possible to output them to a file by setting an environment variable
> (search for log_path in
> https://github.com/google/sanitizers/wiki/AddressSanitizerFlags if in
> need of that option).
> 
> I hope that was helpful.

Thanks, Neven! This is helpful. I've been meaning to look into tools
like this for a while, and this might be just the push I needed.
Eventually I would like to add these options to the building and testing
scripts at https://github.com/scottkosty/lyx-tester. It would be
interesting to build with a sanitizer and then run our big suite of
automated tests. I made an issue to remind me to look into this,
although I probably won't look into it soon (just because of time
reasons and other pending tasks):

  https://github.com/scottkosty/lyx-tester/issues/1

Scott


signature.asc
Description: PGP signature
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Memory leak from list

[Neven Sajko]

My instructions for the C compiler and linker command line were wrong:
instead of -fsanitize=asan , use -fsanitize=address or
-fsanitize=thread or -fsanitize=undefined or -fsanitize=memory .

And, of course, include debugging symbols with "-g".

Regards,
Neven Sajko
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: [PATCH] Fix write to uninitialized bytes for XCB event

[Scott Kostyshak]

On Wed, Feb 19, 2020 at 09:53:35AM -0500, Scott Kostyshak wrote:
> On Wed, Feb 19, 2020 at 11:51:58AM +0100, Jean-Marc Lasgouttes wrote:
> > Stealing the definition of the macro when we do not have it is the best 
> > solution IMO.
> 
> I put in the patch with comments addressing both yours and Pavel's ideas
> (to either wait until Qt 5.6.3 is required, or to copy the macro). It's
> in at 19c41bd0.

If there is interest, I can work on a patch for using the macro. Should
I condition on the Qt version and if it is less than 5.6.3 define the
macro?

Scott


signature.asc
Description: PGP signature
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: [PATCH] Fix write to uninitialized bytes for XCB event

[Scott Kostyshak]

On Wed, Feb 19, 2020 at 11:51:58AM +0100, Jean-Marc Lasgouttes wrote:
> Stealing the definition of the macro when we do not have it is the best 
> solution IMO.

I put in the patch with comments addressing both yours and Pavel's ideas
(to either wait until Qt 5.6.3 is required, or to copy the macro). It's
in at 19c41bd0.

Thanks for taking a look.

Scott


signature.asc
Description: PGP signature
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: [PATCH] Fix write to uninitialized bytes for XCB event

[Jean-Marc Lasgouttes]

Stealing the definition of the macro when we do not have it is the best 
solution IMO.

JMarc

Le 19 février 2020 08:39:35 GMT+01:00, Pavel Sanda  a écrit :
>On Tue, Feb 18, 2020 at 09:49:08PM -0500, Scott Kostyshak wrote:
>> Could anyone take a close look at this? If there is a better fix,
>please
>> go ahead.
>
>Looks OK to me. 
>I would just put into comments TODO to switch to
>Q_DECLARE_XCB_EVENT(event, xcb_selection_notify_event_t); once we
>require qt >= 5.6.3.
>We could even import ifdefed macro, but that's probably overkill.

-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Memory leak from list

[Neven Sajko]

> Well, actually the hardest part is waiting because LyX is very slow when run 
> under valgrind.

Try sanitizers instead. They are instrumentation that GCC or Clang can
include in executables. They do basically the same thing as Valgrind,
but should be much faster and since you are already compiling your own
Lyx and Qt, the sanitizers should be a more appropriate tool. There
are four sanitizers that you may want to compile with: asan, tsan,
msan, ubsan; each for a different class of bugs.

Instructions: include -fsanitize=asan (replace asan with wanted
sanitizer if you want another one) to both compilation and linking
commands (GCC or Clang) of all libraries and code. It is also a good
idea to disable some compiler optimizations, in particular one should
use -fno-omit-frame-pointer. See
https://github.com/google/sanitizers/wiki for more information.

By default the error reports will be output to stderr, but it is
possible to output them to a file by setting an environment variable
(search for log_path in
https://github.com/google/sanitizers/wiki/AddressSanitizerFlags if in
need of that option).

I hope that was helpful.

Regards,
Neven Sajko
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: bug in "view" option

[Sivan Frenkel]

Hi,
Oddly, I have not been experiencing today the bug that I have reported 
yesterday, and the "view" button works fine. I will be in touch if I could 
figure out when and how this bug appears.
Sorry for the mess.
Best, Sivan


Sivan Frenkel
Lecturer in Finance (Assistant Professor)
Coller School of Management
Tel Aviv University
https://sites.google.com/site/sivanfrenkel/ 

On Tuesday, February 18, 2020, 10:52:36 AM GMT+2, Sivan Frenkel 
 wrote:  
 
 Hi,
I am using Win10 and have just updated from version 2.3.4 to 2.3.4.3. The 
update did solve the delay in saving, but seems to have created a new bug.
The bug interferes with the use of "view" command. I am using Adobe Reader to 
views PDF files (I am using Adobe Reader DC version 2020.006.20034). When 
pressing the view button, just after a "successful preview", instead of opening 
the PDF file I get an error "The instruction at 0x7787C19E referenced 
memory at 0x. The memory could not be read". See below a 
picture of the error message. It is not clear to me whether its an OS error or 
an Acrobat error. 

When I use "File>Export>PDF (pdflatex)" the pdf is created and is opened using 
the Acrobat Reader without a problem. Nevertheless, this is clearly less 
convenient than the single button option.
This must be a new bug, as it never happened before, and didn't happen in ver 
2.3.4.
Thank you very much for all your help. LyX is fantastic.
Best,Sivan


Sivan Frenkel
Lecturer in Finance (Assistant Professor)
Coller School of Management
Tel Aviv University
https://sites.google.com/site/sivanfrenkel/



  -- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel