Re: Exporting compressed files

[Andrew Parsloe]

On 6/07/2016 2:16 a.m., José Abílio Matos wrote:


Could you, please, test the following (independent) tests:

1) take the compressed ".21.lyx" created with 2.2 use an
external program to decompress that file and see if lyx 2.1 opens that file?

2) use lyx 2.1 to create a compressed file, save it, close lyx and try to open
it again with lyx 2.1

Regards,


LyX 2.1.5 has no trouble saving and reading its own compressed files.

If I save a compressed file in 2.2.0, LyX 2.1.5 can read it. If I export 
a compressed file from 2.2.0 to 2.1.x, LyX 2.1.5 cannot read it.


I've attached four files:

test.lyx  The original 2.2.0 file ("A quick brown fox jumps over the 
lazy dog.") *saved* as a compressed file.


test.21.lyx  This is test.lyx *exported* as a compressed file to 2.1.x 
format.


test  This is test.lyx as extracted by 7zip. After adding the .lyx 
extension it can be read in LyX 2.1.5.


_stdout_  This is what 7zip produces when attempting to extract 
test.21.lyx. A dialog pops up with the message "CRC failed: ". 
Looked at in a text editor, some extraction has occurred, but obviously 
not to completion.


Windows' builtin zip mechanism is unable to extract either test.lyx or 
test.21.lyx. I have to change the extensions to .zip for it to recognize 
them as zipped, but it claims both zipped folders are empty.


Andrew



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
#LyX 2.2 created this file. For more info see http://www.lyx.org/
\lyxformat 474
\begin_document
\begin_header
\textclass book
\begin_preamble

\end_preamble
\use_default_options false
\maintain_unincluded_children false
\language english
\language_package default
\inputencoding auto
\fontencoding global
\font_roman lmodern
\font_sans lmss
\font_typewriter lmtt
\font_math auto
\font_default_family default
\use_non_tex_fonts false
\font_sc false
\font_osf false
\font_sf_scale 100
\font_tt_scale 100
\graphics default
\default_output_format default
\output_sync 0
\bibtex_command default
\index_command default
\paperfontsize default
\spacing single
\use_hyperref false
\papersize default
\use_geometry true
\use_package amsmath 1
\use_package amssymb 1
\use_package cancel 1
\use_package esint 2
\use_package mathdots 1
\use_package mathtools 1
\use_package mhchem 1
\use_package stackrel 1
\use_package stmaryrd 1
\use_package undertilde 1
\cite_engine basic
\cite_engine_type default
\biblio_style plain
\use_bibtopic false
\use_indices false
\paperorientation portrait
\suppress_date false
\justification true
\use_refstyle 0
\boxbg_o dadate false/ffaa7fommand  Iand s_dhsupcut id s_ false/0080ics ble
iand s_lef
\us de 4cm
\righ
\us de 3.5cm
\secnumdep_packatocdep_pa1ientradefau_sentra
\useiandntientradefau_iandnta
\usebiblio_stquotes_english
\language_ntati faumnsa1ientefauld\pa2ientefapsh
boxbg_biblio_stpprcke_h fangl\paperorienc 0
\bfangl\paperorieh
\lo
\foormat d_o dh
\localsas_ mor_o dh
\lobeainrictaperorieble
extclasreamble
bodysreamble
layrma Stlt
ard
A quick browlanox jumps ovfonthe laz
\uog.ieble
layrmaeamble
bodysmble
\begin_he
#LyX 2.2 created this file. For more info see http://www.lyx.org/
\lyxformat 508
\begin_document
\begin_header
\save_transient_properties true
\origin unavailable
\textclass book
\begin_preamble

\end_preamble
\use_default_options false
\maintain_unincluded_children false
\language english
\language_package default
\inputencoding auto
\fontencoding global
\font_roman "lmodern" "default"
\font_sans "lmss" "default"
\font_typewriter "lmtt" "default"
\font_math "auto" "auto"
\font_default_family default
\use_non_tex_fonts false
\font_sc false
\font_osf false
\font_sf_scale 100 100
\font_tt_scale 100 100
\graphics default
\default_output_format default
\output_sync 0
\bibtex_command default
\index_command default
\paperfontsize default
\spacing single
\use_hyperref false
\papersize default
\use_geometry true
\use_package amsmath 1
\use_package amssymb 1
\use_package cancel 1
\use_package esint 2
\use_package mathdots 1
\use_package mathtools 1
\use_package mhchem 1
\use_package stackrel 1
\use_package stmaryrd 1
\use_package undertilde 1
\cite_engine basic
\cite_engine_type default
\biblio_style plain
\use_bibtopic false
\use_indices false
\paperorientation portrait
\suppress_date false
\justification true
\use_refstyle 0
\boxbgcolor #ffaa7f
\index Index
\shortcut idx
\color #008000
\end_index
\leftmargin 4cm
\rightmargin 3.5cm
\secnumdepth 2
\tocdepth 1
\paragraph_separation indent
\paragraph_indentation default
\quotes_language english
\papercolumns 1
\papersides 2
\paperpagestyle default
\tracking_changes false
\output_changes false
\html_math_output 0
\html_css_as_file 0
\html_be_strict false
\end_header

\begin_body

\begin_layout Standard
A quick brown fox jumps over the lazy dog.
\end_layout

\end_body
\end_document


test.21.lyx
Description: application/lyx


test.lyx
Description: application/lyx

Re: [LyX/master] Ensure that iconv and zlib are always found

[Kornel Benko]

Am Dienstag, 5. Juli 2016 um 21:53:49, schrieb Georg Baum 

> Kornel Benko wrote:
> 
> > Did it at a51847f.
> > 
> > By the way, I get these linkage error independently if I select both (z +
> > iconv) as local or only one of them. Tested each time on empty build build
> > tree.
> 
> Thank you very much. I am sorry for the trouble and might have a look with a 
> more recent gcc later, but currently I am too busy with RL.
> 
> 
> Georg

In the meantime I found a reason for soem (or maybe all?) error messages like
/usr2/src/lyx/lyx-git/src/insets/InsetLayout.cpp:47: undefined 
reference to `std::__cxx11::basic_string::basic_string()'

It is because we have also c-source-files. For this cmake uses the c-compiler. 
But I defined only
the path to c++ compiler in the command line.

Will try tomorrow to check the creation of local libz and libiconv.

Kornel

signature.asc
Description: This is a digitally signed message part.

Re: Weird KDE Bug in LyX

[Guillaume Munch]

Le 02/07/2016 23:43, Guillaume Munch a écrit :



On the other hand, it is possible to prioritise LyX shortcuts by using
the shortcut override mechanism. This would solve both bugs
http://www.lyx.org/trac/ticket/10261 and
http://www.lyx.org/trac/ticket/10119 (probably),
and alleviate the occasional developer's or translator's mistake in
assigning accelerators.




Please try the attached.
>From e1a330df038c7f89e17e94e4338d005507b657c2 Mon Sep 17 00:00:00 2001
From: Guillaume Munch 
Date: Mon, 4 Jul 2016 04:23:32 +0200
Subject: [PATCH] Prioritize the shortcuts from the work areas

* Fix bug #10261 : KDE smartly adds conflicting accelerators.

* Maybe fix #10119?

* Prevent bugs like #9495 in the future.

This patch adds a conflicting accelerator in the source view panel (M) for
demonstration purposes.

Issues:

* It does not appear possible to prevent Ubuntu's Unity from grabbing the
  accelerators for the menus. For instance Alt+A always opens _Affichage in the
  French localization.
---
 src/frontends/qt4/GuiApplication.cpp | 42 +---
 src/frontends/qt4/GuiApplication.h   |  3 +++
 src/frontends/qt4/GuiKeySymbol.cpp   |  2 +-
 src/frontends/qt4/GuiKeySymbol.h |  2 +-
 src/frontends/qt4/GuiPrefs.cpp   |  3 +++
 src/frontends/qt4/GuiWorkArea.cpp| 41 +++
 src/frontends/qt4/GuiWorkArea.h  |  5 -
 src/frontends/qt4/ui/ViewSourceUi.ui |  2 +-
 8 files changed, 79 insertions(+), 21 deletions(-)

diff --git a/src/frontends/qt4/GuiApplication.cpp b/src/frontends/qt4/GuiApplication.cpp
index 6586207..3ddcdbd 100644
--- a/src/frontends/qt4/GuiApplication.cpp
+++ b/src/frontends/qt4/GuiApplication.cpp
@@ -2115,19 +2115,43 @@ void GuiApplication::handleKeyFunc(FuncCode action)
 }
 
 
+//Keep this in sync with GuiApplication::processKeySym below
+bool GuiApplication::queryKeySym(KeySymbol const & keysym,
+ KeyModifier state) const
+{
+	// Do nothing if we have nothing
+	if (!keysym.isOK() || keysym.isModifier())
+		return false;
+	// Do a one-deep top-level lookup for cancel and meta-fake keys.
+	KeySequence seq;
+	FuncRequest func = seq.addkey(keysym, state);
+	// When not cancel or meta-fake, do the normal lookup.
+	if ((func.action() != LFUN_CANCEL) && (func.action() != LFUN_META_PREFIX)) {
+		seq = d->keyseq;
+		func = seq.addkey(keysym, (state | d->meta_fake_bit));
+	}
+	// Maybe user can only reach the key via holding down shift.
+	// Let's see. But only if shift is the only modifier
+	if (func.action() == LFUN_UNKNOWN_ACTION && state == ShiftModifier)
+		// If addkey looked up a command and did not find further commands then
+		// seq has been reset at this point
+		func = seq.addkey(keysym, NoModifier);
+
+	LYXERR(Debug::KEY, " Key (queried) [action=" << func.action() << "]["
+	   << seq.print(KeySequence::Portable) << ']');
+	return func.action() != LFUN_UNKNOWN_ACTION;
+}
+
+
+//Keep this in sync with GuiApplication::queryKeySym above
 void GuiApplication::processKeySym(KeySymbol const & keysym, KeyModifier state)
 {
 	LYXERR(Debug::KEY, "KeySym is " << keysym.getSymbolName());
 
 	// Do nothing if we have nothing (JMarc)
-	if (!keysym.isOK()) {
-		LYXERR(Debug::KEY, "Empty kbd action (probably composing)");
-		if (current_view_)
-			current_view_->restartCursor();
-		return;
-	}
-
-	if (keysym.isModifier()) {
+	if (!keysym.isOK() || keysym.isModifier()) {
+		if (!keysym.isOK())
+			LYXERR(Debug::KEY, "Empty kbd action (probably composing)");
 		if (current_view_)
 			current_view_->restartCursor();
 		return;
@@ -2173,6 +2197,8 @@ void GuiApplication::processKeySym(KeySymbol const & keysym, KeyModifier state)
 	// Let's see. But only if shift is the only modifier
 	if (func.action() == LFUN_UNKNOWN_ACTION && state == ShiftModifier) {
 		LYXERR(Debug::KEY, "Trying without shift");
+		// If addkey looked up a command and did not find further commands then
+		// seq has been reset at this point
 		func = d->keyseq.addkey(keysym, NoModifier);
 		LYXERR(Debug::KEY, "Action now " << func.action());
 	}
diff --git a/src/frontends/qt4/GuiApplication.h b/src/frontends/qt4/GuiApplication.h
index 861810d..de6013d 100644
--- a/src/frontends/qt4/GuiApplication.h
+++ b/src/frontends/qt4/GuiApplication.h
@@ -165,6 +165,9 @@ public:
 #endif
 	}
 
+	/// return true if the key is part of a shortcut
+	bool queryKeySym(KeySymbol const & key, KeyModifier state) const;
+	///
 	void processKeySym(KeySymbol const & key, KeyModifier state);
 	/// return the status bar state string
 	docstring viewStatusMessage();
diff --git a/src/frontends/qt4/GuiKeySymbol.cpp b/src/frontends/qt4/GuiKeySymbol.cpp
index d058bce..ef9425d 100644
--- a/src/frontends/qt4/GuiKeySymbol.cpp
+++ b/src/frontends/qt4/GuiKeySymbol.cpp
@@ -612,7 +612,7 @@ static char encode(string const & encoding, QString const & str)
 #endif
 
 
-void setKeySymbol(KeySymbol * sym, QKeyEvent * ev)
+void setKeySymbol(KeySymbol * sym, QKeyEvent 

Re: Why does LyX not accept empty list items?

[Richard Heck]

On 07/05/2016 03:36 PM, Daniel wrote:
> On 05.07.2016 16:22, Richard Heck wrote:
>> On 07/04/2016 02:42 PM, racoon wrote:
>>> On 04.07.2016 16:16, Jean-Marc Lasgouttes wrote:
 Le 04/07/2016 à 15:38, racoon a écrit :
> Thanks. Still I am wondering a bit why anything special at all is
> necessary.

 Well, I am glad I do not have dangling list items like Word gladly
 creates.
>>>
>>> Thanks. Not sure what you mean exactly by "dangling list items". Is
>>> the worry that there could be a list item, say from a description,
>>> that are easily overlooked? I guess list items and indentations are
>>> more visible in LyX than in word. But still I see the point somewhat.
>>
>> Note that these sorts of things are customizable. If you really want to
>> allow empty items, do:
>>
>> Style Itemize
>> KeepEmpty 0
>> End
>>
>> Put that in local layout, or in a module you can reuse.
>
> Thanks Richard. Yes, I would like to test it in order to see what
> suits me better. However, it seems not to work as expected. I have
> added it to my local layout but empty items are still removed.
>
> And I guess it would not apply to other environments like quote, right?

Sorry, stupid typo. It should be:

Style Itemize
KeepEmpty 1
End

I.e., 1 for true.

And it should also work for quotations and any other environment,
really. Just change the name of the style. (This needs to be LyX's name
for it, not the translated name in the GUI, if you have that.)

Richard

Re: [LyX/master] Ensure that iconv and zlib are always found

[Georg Baum]

Kornel Benko wrote:

> Did it at a51847f.
> 
> By the way, I get these linkage error independently if I select both (z +
> iconv) as local or only one of them. Tested each time on empty build build
> tree.

Thank you very much. I am sorry for the trouble and might have a look with a 
more recent gcc later, but currently I am too busy with RL.


Georg

Re: Compiling with Microsoft Visual C++

[Georg Baum]

racoon wrote:

> On 04.07.2016 09:11, racoon wrote:
>> "Compile the INSTALL project to get a LyX installation in
>> C:\LyX\lyx-23-install"
>>
>> I guess it means opening "INSTALL.vcxproj" and STRG-F5. Getting
>>
>> "Build: 14 succeeded, 12 failed, 0 up-to-date, 0 skipped"

Congratulations! You are almost there!

>> Can't run because of errors.
> 
> ... And here are the errors from Visual Studio:
> 
> 
> 
> 1>-- Build started: Project: lyx_version, Configuration: Debug Win32
> --
> 2>-- Build started: Project: translations, Configuration: Debug
> Win32 --
> 3>-- Build started: Project: check_ExternalTransforms,
> Configuration: Debug Win32 --
> 1>  -- Git-hash = 6dfc255
> 1>  -- Created C:/LyX/lyx-23-build/lyx_date.tmp
> 1>  -- Created C:/LyX/lyx-23-build/lyx_commit_hash.tmp
> 4>-- Build started: Project: LyX (applications\LyX\LyX),
> Configuration: Debug Win32 --
> 3>Qt5Cored.lib(Qt5Cored.dll) : fatal error LNK1112: module machine type
> 'x64' conflicts with target machine type 'X86'

You have a 64bit qt, but told cmake to create a 32bit target. You can either 
download a 32bit qt, or use the "Visual Studio 14 2015 Win64" generator in 
cmake instead of "Visual Studio 14 2015".

I am currently very busy, but I will look at your other reports in a few 
days, update the build instructions and may come back to you with questions.


Georg

Re: Anonymous functions: replace bind with lambdas

[Georg Baum]

Guillaume Munch wrote:

> I have split the patch in two for you, and already committed the part
> that does not introduce lambda expressions. Attached is the remainder of
> the patch that replaces all remaining std::bind with lambda expressions.

Thanks. I am currently swamped with work, and this deserves a thorough look 
so please be patient for a few days for my answer.


Georg

Re: make distcheck: cannot remove '../../po/lyx.pot'

[Georg Baum]

Pavel Sanda wrote:

> This was a tough one. distcheck was broken for a while (while showing it's
> famous lyx.pot message) and bisecting nowadays master is like walking
> through the minefield where bunch of commits do not compile at all or git
> gets crazy due to cr-lf mismanagement.

I still do not understand this 100%, but I believe I made a mistake when 
introducing the .gitattributes file: I should have done 

$ echo "* text=auto" >>.gitattributes
$ rm .git/index # Remove the index to force Git to
$ git reset # re-scan the working directory
$ git status# Show files that will be normalized
$ git add -u
$ git add .gitattributes
$ git commit -m "Introduce end-of-line normalization"

according to https://git-scm.com/docs/gitattributes, but I only did the 
equivalent of the first and the last two steps. Unfortunately this cannot be 
fixed now anymore, andybody doing a bisect spanning the time between 
.gitattributes creation and the fix should probably first remove 
.gitattributes.

> But try again now.

You are a hero! Some months ago I tried to find the cause, but failed to 
find the missing file.


Georg

Re: [LyX/master] Move duplicated symbols to the macro section

[Georg Baum]

Enrico Forestieri wrote:

> On Sun, Jul 03, 2016 at 08:07:46PM +0200, Enrico Forestieri wrote:
> 
>> On Sun, Jun 26, 2016 at 08:36:48PM +0200, Georg Baum wrote:
>> 
>> > commit 343a379b88e35778f358742e134c61b552bcabb3
>> > Author: Georg Baum 
>> > Date:   Sun Jun 26 20:23:46 2016 +0200
>> > 
>> > Move duplicated symbols to the macro section
>> > 
>> > This helps to find them via unicodesymbols as I do for some STIX
>> > experiments
>> 
>> Georg, after this commit \leq, \geq, and \lnot are shown as blanks in
>> mathed.
> 
> Fixed at 7c82ab32.

Thank you very much, I wanted to fix this myself but am currently swamped 
with work. I tested this by looking at -dbg mathed output with a patch 
making use of STIX fonts, and did not realize that it did indeed find a STIX 
symbol, but that it was space.


Georg

Re: [LyX/master] Gcc 6+ use C++14 as default, so there is no need to enforce C++11

[Kornel Benko]

Am Dienstag, 5. Juli 2016 um 18:17:40, schrieb Jean-Marc Lasgouttes 

> Le 05/07/2016 à 17:47, Kornel Benko a écrit :
> > Cmake tries to use  -std=c++14 first, then c++11, gnu++11, gnu++0x
> >
> > See development/cmake/modules/FindCXX11Compiler.cmake:50
> 
> Very interesting code, thanks. Concerning the regex code, I saw the 
> stackexchange question already, but it did not occur to me that it was a 
> good configure test. Are you positive that compilation fails with gcc < 4.9?

It fails here with gcc4.8.4, so I'd say yes.

> I will probably rework autoconf detection code to follow cmake.
> 
> JMarc

Kornel

signature.asc
Description: This is a digitally signed message part.

Re: compile err

[Pavel Sanda]

Guillaume Munch wrote:
> Le 05/07/2016 18:37, Pavel Sanda a écrit :
>>
>> I figured out that the linking problem disappears when building from clean 
>> tree.
>> unistd.h is still needed (configure --enable-build-type=rel , automake 
>> 1.15, autoconf 2.69).
>>
>
> This unistd.h problem is very strange. I could compile without errors or 
> warnings even with --enable-build-type=rel.

yeah this is not ubuntu system so the structure of headers can be slightly 
different.
p

Re: compile err

[Guillaume Munch]

Le 05/07/2016 18:37, Pavel Sanda a écrit :


I figured out that the linking problem disappears when building from clean tree.
unistd.h is still needed (configure --enable-build-type=rel , automake 1.15, 
autoconf 2.69).



This unistd.h problem is very strange. I could compile without errors or 
warnings even with --enable-build-type=rel.

Re: [LyX/master] Rationalise includes

[Guillaume Munch]

Le 05/07/2016 18:40, Pavel Sanda a écrit :


wrote in the other mail, but to be clear i don't expect you to test
all possible gcc or auttools variants before commiting stuff, we have
to live with bugs like that. p




Thank you for your patience.

Re: [LyX/master] Rationalise includes

[Pavel Sanda]

Guillaume Munch wrote:
> I am really curious to know Pavel's configure line given that he uses
> gcc. If I could reproduce the problems then I would be able to test
> beforehand more thoroughly when useful.

wrote in the other mail, but to be clear i don't expect you to test
all possible gcc or auttools variants before commiting stuff, we have
to live with bugs like that. p

Re: compile err

[Pavel Sanda]

Pavel Sanda wrote:
> Pavel Sanda wrote:
> > Guillaume Munch wrote:
> > > Le 04/07/2016 02:20, Pavel Sanda a écrit :
> > >> anyone can reproduce this (gcc 4.9.3):
> > >
> > > Not with 4.6 nor with 5.3 but there are probably configure switches
> > > involved.
> > 
> > Indeed, the bug s triggered when I use --enable-build-type=rel.
> > 
> > > You can try adding:
> > >
> > > #ifdef HAVE_UNISTD_H
> > > # include 
> > > #endif
> > >
> > > to src/ServerSocket.cpp. 
> > 
> > This fixes it.
> 
> and leads to linkage problems

I figured out that the linking problem disappears when building from clean tree.
unistd.h is still needed (configure --enable-build-type=rel , automake 1.15, 
autoconf 2.69).

Pavel

Re: [PATCH] make string breaking faster

[Pavel Sanda]

Jean-Marc Lasgouttes wrote:
> Comments welcome. My plan is to use that for both Qt4 and Qt5 (for 
> simplicity). Seeing the different behavior of Qt 4.8.1 and 4.8.7 (albeit 
> different machines), I suspect that the problem is elsewhere in the 
> configuration.
>
> I would be glad to have numbers from your on systems.

Tested to see the impact on the speed of moving cursor throughout
first page of user manual (slowness reported while ago).

lyx 2.0.8 - ~14s
master(86c33c96a) - ~29s
master(86c33c96a)+your patch(no prof in config options) - ~23s 

#pmprof# breakAt: 6.88usec, count=862, total=5.93msec
   hit: 97%, 5.12usec, count=842, total=4.31msec
   miss: 2%, 81.00usec, count=20, total=1.62msec

(qt 4.8.5)
Pavel

Re: [LyX/master] Gcc 6+ use C++14 as default, so there is no need to enforce C++11

[Jean-Marc Lasgouttes]

Le 05/07/2016 à 17:52, Guillaume Munch a écrit :

Le 05/07/2016 17:23, Jean-Marc Lasgouttes a écrit :


We have compiled for ages in gnu++98 mode forever when not using C++11.
And currently gcc 6 uses gnu++14 by default. Do you want me to force
c++14 instead?



If this brings the behaviour of gcc closer to that of other compilers,
then why not? But you might have looked at the issue closer than I did,
so I am not voicing an opinion strongly.


Anyway, the approach used in cmake seems just fine to me. I will try to 
implement that.


JMarc

Re: [LyX/master] Gcc 6+ use C++14 as default, so there is no need to enforce C++11

[Jean-Marc Lasgouttes]

Le 05/07/2016 à 17:47, Kornel Benko a écrit :

Cmake tries to use  -std=c++14 first, then c++11, gnu++11, gnu++0x

See development/cmake/modules/FindCXX11Compiler.cmake:50


Very interesting code, thanks. Concerning the regex code, I saw the 
stackexchange question already, but it did not occur to me that it was a 
good configure test. Are you positive that compilation fails with gcc < 4.9?


I will probably rework autoconf detection code to follow cmake.

JMarc

Re: [LyX/master] Gcc 6+ use C++14 as default, so there is no need to enforce C++11

[Guillaume Munch]

Le 05/07/2016 17:23, Jean-Marc Lasgouttes a écrit :


We have compiled for ages in gnu++98 mode forever when not using C++11.
And currently gcc 6 uses gnu++14 by default. Do you want me to force
c++14 instead?



If this brings the behaviour of gcc closer to that of other compilers,
then why not? But you might have looked at the issue closer than I did,
so I am not voicing an opinion strongly.

Re: [LyX/master] Gcc 6+ use C++14 as default, so there is no need to enforce C++11

[Kornel Benko]

Am Dienstag, 5. Juli 2016 um 17:23:40, schrieb Jean-Marc Lasgouttes 

> Le 05/07/2016 à 12:23, Guillaume Munch a écrit :
> >> I figured that the difference were minimal, but if I am wrong I can
> >> revert this part of course. Only cygwin requires gnu++11.
> >
> > As far as I understand, the difference is precisely to enable
> > non-standard extensions. I do see the point of disabling non-standard
> > extensions for a cross-platform software.
> 
> We have compiled for ages in gnu++98 mode forever when not using C++11. 
> And currently gcc 6 uses gnu++14 by default. Do you want me to force 
> c++14 instead?
> 
> I do not know what cmake does BTW, but we will eventually synchronize 
> these kind of choices.

Cmake tries to use  -std=c++14 first, then c++11, gnu++11, gnu++0x

See development/cmake/modules/FindCXX11Compiler.cmake:50

> JMarc

Kornel

signature.asc
Description: This is a digitally signed message part.

Re: [LyX/master] Gcc 6+ use C++14 as default, so there is no need to enforce C++11

[Jean-Marc Lasgouttes]

Le 05/07/2016 à 12:23, Guillaume Munch a écrit :

I figured that the difference were minimal, but if I am wrong I can
revert this part of course. Only cygwin requires gnu++11.


As far as I understand, the difference is precisely to enable
non-standard extensions. I do see the point of disabling non-standard
extensions for a cross-platform software.


We have compiled for ages in gnu++98 mode forever when not using C++11. 
And currently gcc 6 uses gnu++14 by default. Do you want me to force 
c++14 instead?


I do not know what cmake does BTW, but we will eventually synchronize 
these kind of choices.


JMarc

Re: LyX 2.2.0 Linux Compilation Error

[Joel Kulesza]

Developers:

By way of update:

   - I was able to compile against Qt 5.3 and Qt 5.5 using configure but
   with neither using cmake
   - With both configure and cmake, my PATH and LD_LIBRARY_PATHs were
  identical.  Cmake would begin compiling, but a series of errors
would occur
  in the Qt files, starting with preprocessor directives that
would suggest a
  header file conflict somewhere (e.g., limits.h or so Google claims).  Let
  me know if you want more details regarding this.
  - When compiled against Qt 5.3 or 5.5, upon launching LyX, I get:
   1127 jkulesza@machine[~/SRC/lyx220/build/src]> ./lyx
   This application failed to start because it could not find or load the
   Qt platform plugin "xcb".

   Reinstalling the application may fix this problem.
   Aborted (core dumped)
   - Per the above, when I run `ldd lyx` I get:
   1128 jkulesza@machine[~/SRC/lyx220/build/src]> ldd lyx
   linux-vdso.so.1 =>  (0x7ffe76bdb000)
   libhunspell-1.2.so.0 => /usr/lib64/libhunspell-1.2.so.0
   (0x2b21963e4000)
   libaspell.so.15 => /usr/lib64/libaspell.so.15 (0x2b2196626000)
   libz.so.1 => /lib64/libz.so.1 (0x2b21968e7000)
   libmagic.so.1 => /usr/lib64/libmagic.so.1 (0x2b2196afd000)
   libQt5Concurrent.so.5 =>
   /path/to/vendors/qt-5.5/Tools/QtCreator/lib/qtcreator/libQt5Concurrent.so.5
   (0x2b2196d1d000)
   libQt5Svg.so.5 =>
   /path/to/vendors/qt-5.5/Tools/QtCreator/lib/qtcreator/libQt5Svg.so.5
   (0x2b2196f23000)
   libQt5Widgets.so.5 =>
   /path/to/vendors/qt-5.5/Tools/QtCreator/lib/qtcreator/libQt5Widgets.so.5
   (0x2b2197177000)
   libQt5Gui.so.5 =>
   /path/to/vendors/qt-5.5/Tools/QtCreator/lib/qtcreator/libQt5Gui.so.5
   (0x2b21979f6000)
   libQt5Core.so.5 =>
   /path/to/vendors/qt-5.5/Tools/QtCreator/lib/qtcreator/libQt5Core.so.5
   (0x2b2198209000)
   libstdc++.so.6 =>
   /usr/projects/hpcsoft/toss2/common/gcc/5.3.0/lib64/libstdc++.so.6
   (0x2b219894e000)
   libm.so.6 => /lib64/libm.so.6 (0x2b2198cdd000)
   libgcc_s.so.1 =>
   /usr/projects/hpcsoft/toss2/common/gcc/5.3.0/lib64/libgcc_s.so.1
   (0x2b2198f61000)
   libc.so.6 => /lib64/libc.so.6 (0x2b2199177000)
   libpthread.so.0 => /lib64/libpthread.so.0 (0x2b219950c000)
   libdl.so.2 => /lib64/libdl.so.2 (0x2b2199729000)
   librt.so.1 => /lib64/librt.so.1 (0x2b219992e000)
   libGL.so.1 => /usr/lib64/nvidia/libGL.so.1 (0x2b2199b36000)
   libgobject-2.0.so.0 => /lib64/libgobject-2.0.so.0
   (0x2b2199e67000)
   libgthread-2.0.so.0 => /lib64/libgthread-2.0.so.0
   (0x2b219a0b3000)
   libglib-2.0.so.0 => /lib64/libglib-2.0.so.0 (0x2b219a2b7000)
   libXext.so.6 => /usr/lib64/libXext.so.6 (0x2b219a5cf000)
   libX11.so.6 => /usr/lib64/libX11.so.6 (0x2b219a7e1000)
   libicui18n.so.54 =>
   /path/to/vendors/qt-5.5/Tools/QtCreator/lib/qtcreator/libicui18n.so.54
   (0x2b219ab1f000)
   libicuuc.so.54 =>
   /path/to/vendors/qt-5.5/Tools/QtCreator/lib/qtcreator/libicuuc.so.54
   (0x2b219af8d000)
   libicudata.so.54 =>
   /path/to/vendors/qt-5.5/Tools/QtCreator/lib/qtcreator/libicudata.so.54
   (0x2b219b33b000)
   /lib64/ld-linux-x86-64.so.2 (0x2b21961c2000)
   libnvidia-tls.so.352.93 =>
   /usr/lib64/nvidia/tls/libnvidia-tls.so.352.93 (0x2b219cd66000)
   libnvidia-glcore.so.352.93 =>
   /usr/lib64/nvidia/libnvidia-glcore.so.352.93 (0x2b219cf69000)
   libxcb.so.1 => /usr/lib64/libxcb.so.1 (0x2b219f9fe000)
   libXau.so.6 => /usr/lib64/libXau.so.6 (0x2b219fc1c000)
   - None of the libraries indicate that they cannot be found.
   Furthermore, when I pursue the path of /usr/lib64/libxcb.so.1 I can find
   it (symlinked eventually to libxcb.so.1.1.0).

Is there something else I need to add to my PATH?  Is there a flag I can
pass to configure to disable XCB or force its location to be recognized?

Thank you,

Joel

Re: LyX 2.2.1

[Richard Heck]

On 07/05/2016 06:00 PM, Uwe Stöhr wrote:
> Am 04.07.2016 um 12:05 schrieb Jean-Marc Lasgouttes:
>
>> I'd say that only regressions could be important. Other than that, it is
>> always better to let a good release out than to wait for a perfect one.
>
> +1
>
> it seems that only http://www.lyx.org/trac/ticket/10199 should be
> fixed. Günter?

There are some others

   
http://www.lyx.org/trac/query?status=fixedinmaster=!2.3.0=0=id=summary=changetime=status=milestone=keywords=id

that are fixedinmaster and are worth a peek.

Richard

Re: [PATCH] make string breaking faster

[Jean-Marc Lasgouttes]

Le 05/07/2016 à 16:28, Richard Heck a écrit :

Can you give a receipe for producing them? I'm ignorant about profiling.
(In my case, this would be on Linux.)


Actually, the patch is already instrumented (see below). So all you need 
to do is produce a build without run-time debugging. A good way to do 
that with autoconf is to configure with --enable-build-type=prof.


The rune LyX, move around the document or do whatever leads to a slow 
display and when you quit LyX, you will see the result on console.


As for the "how is it done" part, it uses the poor man's profiler in our 
source. The relevant code looks like:


+#include "support/pmprof.h"

+bool GuiFontMetrics::breakAt(docstring & s, int & x, bool const rtl, 
bool const force) const

+{
+   PROFILE_THIS_BLOCK(breakAt)

[...]

+   if (pp)

This is the cache hit branch

+   tie(len, newx) = *pp;
+   else {

This is the cache miss branch

+   PROFILE_CACHE_MISS(breakAt)
+   tie(len, newx) = breakAt_helper(s, x, rtl, force);
+   breakat_cache_.insert(qba, new pair(len, 
newx), qba.size());

+   }

[...]


The first macro PROFILE_THIS_BLOCK (with an arbitrary identifier) will 
give profiling results for the function. If additionally you have some 
PROFILE_CACHE_MISS calls, then the system will turn into "cache 
profiling" mode and output further information in terms of cache hit/miss.


You should not trust the numbers too much, but it is a very convenient 
way to assess a speedup.


JMarc

Re: Why does LyX not accept empty list items?

[Jean-Marc Lasgouttes]

Le 04/07/2016 à 20:42, racoon a écrit :

On 04.07.2016 16:16, Jean-Marc Lasgouttes wrote:

Le 04/07/2016 à 15:38, racoon a écrit :

Thanks. Still I am wondering a bit why anything special at all is
necessary.


Well, I am glad I do not have dangling list items like Word gladly
creates.


Thanks. Not sure what you mean exactly by "dangling list items". Is the
worry that there could be a list item, say from a description, that are
easily overlooked? I guess list items and indentations are more visible
in LyX than in word. But still I see the point somewhat.


Just yesterday I received a libreoffice document from an admittedly not 
very computer literate student with text like


 * first itemize element
 * second itemize element
 *

The empty item at the end does not look very good.


Yes, the example I gave isn't very practical. But then consider

\begin{quote}
\begin{enumerate}
\item Enumerated stuff
\end{enumerate}
\end{quote}

That seems to be very understandable typography.


Sure this example is much more interesting. It would be nice to find an 
interface for that that would be intuitive. I do not think that allowing 
empty elements is intuitive.


JMarc

Re: [PATCH] make string breaking faster

[Richard Heck]

On 07/05/2016 10:06 AM, Jean-Marc Lasgouttes wrote:
> The attached patch implements a cache around the function
> GuiFontMetrics::breakAt, which has been identified as very slow by
> Guillaume. To this end, I use a plain QCache object.
>
> This patch is also instrumented using pmprof.h. When I load the
> UserGuide, and move along the document using Cursor-Down, I get the
> following results:
>
> * Intel(R) Xeon(R) CPU E5-1620 v3 @ 3.50GHz, ubuntu 12.04, Qt 4.8.1
>
> #pmprof# breakAt: 20.69usec, count=1651, total=34.16msec
>hit: 63%, 3.54usec, count=1052, total=3.72msec
>   miss: 36%, 50.82usec, count=599, total=30.44msec
>
>
> * Intel(R) Core(TM) i7-4600U CPU @ 2.10GHz, ubuntu 16.04, Qt 4.8.7
>
> #pmprof# breakAt: 221.85usec, count=4884, total=1083.54msec
>hit: 83%, 2.29usec, count=4063, total=9.31msec
>   miss: 16%, 1308.43usec, count=821, total=1074.22msec
>
>
> * Intel(R) Core(TM) i7-4600U CPU @ 2.10GHz, ubuntu 16.04, Qt 5.5.1
>
> #pmprof# breakAt: 4.20usec, count=16820, total=70.56msec
>hit: 96%, 1.44usec, count=16267, total=23.43msec
>   miss: 3%, 85.23usec, count=553, total=47.13msec
>
>
> One can see that the improvement between the hit and miss branches is
> x500 with Qt 4.8.7, but only x14 with Qt 4.8.1 and x60 with Qt 5.5.1.
> Note however that the miss path is much faster with Qt5 in the last
> two examples (same machine).
>
> Comments welcome. My plan is to use that for both Qt4 and Qt5 (for
> simplicity). Seeing the different behavior of Qt 4.8.1 and 4.8.7
> (albeit different machines), I suspect that the problem is elsewhere
> in the configuration.
>
> I would be glad to have numbers from your on systems.

Can you give a receipe for producing them? I'm ignorant about profiling.
(In my case, this would be on Linux.)

Richard

Re: [LyX/master] Autoconf : Try to select the correct Qt tools by using the -qt option

[Jean-Marc Lasgouttes]

Le 05/07/2016 à 16:26, Richard Heck a écrit :

If this proves to work correctly (i.e. if --enable-qt5 is all it takes
to switch from Qt4 to Qt5), then this should eventually go to 2.2.x
(no hurry).


Can you plan to commit it right after 2.2.1 is released?


Sure, I will.

JMarc

Re: [LyX/master] Autoconf : Try to select the correct Qt tools by using the -qt option

[Richard Heck]

On 07/05/2016 06:12 AM, Jean-Marc Lasgouttes wrote:
> Le 05/07/2016 à 12:02, Jean-Marc Lasgouttes a écrit :
>> commit d044986724e98921510c95adecb61d2688b1f598
>> Author: Jean-Marc Lasgouttes 
>> Date:   Mon Jul 4 16:22:57 2016 +0200
>>
>> Autoconf : Try to select the correct Qt tools by using the -qt
>> option
>>
>> With this change, it is now possible to configure with --enable-qt5
>> and have make use "moc -qt=qt5" automatically.
>>
>> This is done when the command qtchooser is available nd the
>> desired Qt
>> version (qt4/qt5) is available.
>>
>> This means that it is now possible to have qt4 and qt5 builds easily
>> on a same linux system.
>
> If this proves to work correctly (i.e. if --enable-qt5 is all it takes
> to switch from Qt4 to Qt5), then this should eventually go to 2.2.x
> (no hurry).

Can you plan to commit it right after 2.2.1 is released?

Richard

Re: Why does LyX not accept empty list items?

[Richard Heck]

On 07/04/2016 02:42 PM, racoon wrote:
> On 04.07.2016 16:16, Jean-Marc Lasgouttes wrote:
>> Le 04/07/2016 à 15:38, racoon a écrit :
>>> Thanks. Still I am wondering a bit why anything special at all is
>>> necessary.
>>
>> Well, I am glad I do not have dangling list items like Word gladly
>> creates.
>
> Thanks. Not sure what you mean exactly by "dangling list items". Is
> the worry that there could be a list item, say from a description,
> that are easily overlooked? I guess list items and indentations are
> more visible in LyX than in word. But still I see the point somewhat.

Note that these sorts of things are customizable. If you really want to
allow empty items, do:

Style Itemize
KeepEmpty 0
End

Put that in local layout, or in a module you can reuse.

Richard

Re: How to prevent a paragraph spanning pages?

[Richard Heck]

On 07/04/2016 06:47 PM, Steve Litt wrote:
> Hi all,
>
> I have a specific paragraph style (environment) that has TeX "Large"
> print and is used only on single sentences. I'd like to incorporate
> something in this environment's LaTeX code to prevent it breaking in
> the middle. Anyone know how to do that?

This same question was asked a couple weeks ago. Should be in the archives.

Richard

Re: Exporting compressed files

[José Abílio Matos]

On Tuesday, July 5, 2016 10:36:51 PM WEST Andrew Parsloe wrote:
> The problem is just with compressed files. Uncompressed they export 
> fine, and can be read in 2.1.5. With the compressed file when I try to 
> open it in 2.1.5 I get the message: ".21.lyx is not a 
> readable LyX document." Perhaps this is a Windows only problem?

Could you, please, test the following (independent) tests:

1) take the compressed ".21.lyx" created with 2.2 use an 
external program to decompress that file and see if lyx 2.1 opens that file?

2) use lyx 2.1 to create a compressed file, save it, close lyx and try to open 
it again with lyx 2.1

Regards,
-- 
José Abílio

Re: [LyX/master] Ensure that iconv and zlib are always found

[Kornel Benko]

Am Sonntag, 3. Juli 2016 um 19:00:15, schrieb Georg Baum 

> Kornel Benko wrote:
> 
> > I cannot compile anymore with this change with cmake.
> > Previously selecting LYX_3RDPARTY_BUILD, I was able to compile and bind
> > with our hunspell sources.
> > Now the compilation is OK too, but if it comes to bind I have many
> > unsatisfied  references.
> > 
> > Will try to find out whats wrong, but I remember having problems before.
> > That's why hunspel and iconv/zlib were separated. (I mean
> > 'if(LYX_3RDPARTY_BUILD)' on separate places in CMakeLists.txt)
> 
> If you want to use the included hunspell and not the included zlib and 
> libiconv then there should be separate configuration options. Having a 
> LYX_3RDPARTY_BUILD option that enables all three libs on windows but only 
> hunspell on unix is too confusing IMHO.

Did it at a51847f.

By the way, I get these linkage error independently if I select both (z + 
iconv) as local or only one of them.
Tested each time on empty build build tree.

Kornel

signature.asc
Description: This is a digitally signed message part.

[PATCH] make string breaking faster

[Jean-Marc Lasgouttes]

The attached patch implements a cache around the function 
GuiFontMetrics::breakAt, which has been identified as very slow by 
Guillaume. To this end, I use a plain QCache object.


This patch is also instrumented using pmprof.h. When I load the 
UserGuide, and move along the document using Cursor-Down, I get the 
following results:


* Intel(R) Xeon(R) CPU E5-1620 v3 @ 3.50GHz, ubuntu 12.04, Qt 4.8.1

#pmprof# breakAt: 20.69usec, count=1651, total=34.16msec
   hit: 63%, 3.54usec, count=1052, total=3.72msec
  miss: 36%, 50.82usec, count=599, total=30.44msec


* Intel(R) Core(TM) i7-4600U CPU @ 2.10GHz, ubuntu 16.04, Qt 4.8.7

#pmprof# breakAt: 221.85usec, count=4884, total=1083.54msec
   hit: 83%, 2.29usec, count=4063, total=9.31msec
  miss: 16%, 1308.43usec, count=821, total=1074.22msec


* Intel(R) Core(TM) i7-4600U CPU @ 2.10GHz, ubuntu 16.04, Qt 5.5.1

#pmprof# breakAt: 4.20usec, count=16820, total=70.56msec
   hit: 96%, 1.44usec, count=16267, total=23.43msec
  miss: 3%, 85.23usec, count=553, total=47.13msec


One can see that the improvement between the hit and miss branches is 
x500 with Qt 4.8.7, but only x14 with Qt 4.8.1 and x60 with Qt 5.5.1. 
Note however that the miss path is much faster with Qt5 in the last two 
examples (same machine).


Comments welcome. My plan is to use that for both Qt4 and Qt5 (for 
simplicity). Seeing the different behavior of Qt 4.8.1 and 4.8.7 (albeit 
different machines), I suspect that the problem is elsewhere in the 
configuration.


I would be glad to have numbers from your on systems.

JMarc
>From 6953f4c7d95f27d6bf7869bbdc7d94f4b6c4cb66 Mon Sep 17 00:00:00 2001
From: Jean-Marc Lasgouttes 
Date: Tue, 5 Jul 2016 14:06:22 +0200
Subject: [PATCH] Add a cache for GuiFontMetrics::breakAt

The QTextLayout handling is terribly slow on Qt 4.8.7, but some
caching has been added in Qt5 that makes it much faster. For some
reason, it is not that slow with Qt 4.8.1.

This patch adds some caching in the breakAt method, the only user of
QTextLayout which did not have some kind of caching already. It should
probably only be active for Qt 4.
---
 src/frontends/qt4/GuiFontMetrics.cpp |   46 ++
 src/frontends/qt4/GuiFontMetrics.h   |6 +
 2 files changed, 41 insertions(+), 11 deletions(-)

diff --git a/src/frontends/qt4/GuiFontMetrics.cpp b/src/frontends/qt4/GuiFontMetrics.cpp
index eade8cc..2368e8c 100644
--- a/src/frontends/qt4/GuiFontMetrics.cpp
+++ b/src/frontends/qt4/GuiFontMetrics.cpp
@@ -22,6 +22,7 @@
 #include "insets/Inset.h"
 
 #include "support/lassert.h"
+#include "support/pmprof.h"
 
 using namespace std;
 using namespace lyx::support;
@@ -51,10 +52,10 @@ inline QChar const ucs4_to_qchar(char_type const ucs4)
 } // anon namespace
 
 
-// Limit strwidth_cache_ size to 512kB of string data
+// Limit (strwidth|breakat)_cache_ size to 512kB of string data
 GuiFontMetrics::GuiFontMetrics(QFont const & font)
 	: font_(font), metrics_(font, 0),
-	  strwidth_cache_(1 << 19),
+	  strwidth_cache_(1 << 19), breakat_cache_(1 << 19),
 	  tl_cache_rtl_(false), tl_cache_wordspacing_(-1.0)
 {
 }
@@ -214,10 +215,9 @@ int GuiFontMetrics::x2pos(docstring const & s, int & x, bool const rtl,
 }
 
 
-bool GuiFontMetrics::breakAt(docstring & s, int & x, bool const rtl, bool const force) const
+pair GuiFontMetrics::breakAt_helper(docstring const & s, int const x,
+  bool const rtl, bool const force) const
 {
-	if (s.empty())
-		return false;
 	QTextLayout tl;
 	/* Qt will not break at a leading or trailing space, and we need
 	 * that sometimes, see http://www.lyx.org/trac/ticket/9921.
@@ -225,7 +225,7 @@ bool GuiFontMetrics::breakAt(docstring & s, int & x, bool const rtl, bool const
 	 * To work around the problem, we enclose the string between
 	 * zero-width characters so that the QTextLayout algorithm will
 	 * agree to break the text at these extremal spaces.
-	*/
+	 */
 	// Unicode character ZERO WIDTH NO-BREAK SPACE
 	QChar const zerow_nbsp(0xfeff);
 	tl.setText(zerow_nbsp + toqstr(s) + zerow_nbsp);
@@ -240,11 +240,36 @@ bool GuiFontMetrics::breakAt(docstring & s, int & x, bool const rtl, bool const
 	line.setLineWidth(x);
 	tl.createLine();
 	tl.endLayout();
-	if ((force && line.textLength() == 1) || int(line.naturalTextWidth()) > x)
-		return false;
-	x = int(line.naturalTextWidth());
 	// The -1 is here to account for the leading zerow_nbsp.
-	s = s.substr(0, line.textLength() - 1);
+	return make_pair(line.textLength() - 1, int(line.naturalTextWidth()));
+}
+
+
+bool GuiFontMetrics::breakAt(docstring & s, int & x, bool const rtl, bool const force) const
+{
+	PROFILE_THIS_BLOCK(breakAt)
+	if (s.empty())
+		return false;
+	docstring s_cache = s + (rtl ? "r" : "l") + (force ? "f" : "w");
+
+	QByteArray qba =
+		QByteArray(reinterpret_cast(s_cache.data()),
+		   s.size() * sizeof(docstring::value_type));
+	pair * pp = breakat_cache_[qba];
+	int len = 0;
+	

Re: [LyX/master] Fix missing TexRow.h include after change 670efa8f646218f2a378f0cc614c4c37a9f6b89a

[Guillaume Munch]

Le 05/07/2016 00:31, Stephan Witt a écrit :



Am 04.07.2016 um 23:55 schrieb Guillaume Munch :

What errors do you get with the attached?


Guillaume




That works too.



Thanks for testing.

Guillaume

Re: Exporting compressed files

[Andrew Parsloe]

On 5/07/2016 8:40 p.m., José Abílio Matos wrote:

On Saturday, May 28, 2016 3:00:09 PM WEST Andrew Parsloe wrote:

I inadvertently tried exporting a compressed 2.2 file to 2.1.4. It was
not recognised by 2.1.4. When I try exporting an empty 2.2 compressed
file, it too isn't recognized by 2.1.4, so clearly this is not an
allowed mode of export. However I can't see anything saying that this
won't work in the documentation, and I wonder if it *should* be possible
-- uncompress in the background and then export that? (I have a number
of older files saved in compressed format which I'm looking at in 2.2
and saving, but also exporting to 2.1 format to retain a copy I can work
on in 2.1.4.)

Andrew


Hi Andrew,
are you having problems just with compressed files or with any type of
files?

I ask this because I tried several examples here and it worked. So I am
not able to replicate your findings. :-(

Could you try to uncompress the files firt and the export to 2.1.x and 
see
if the problem persists?

A priori there is no reason for this not to work.

Regards,

The problem is just with compressed files. Uncompressed they export 
fine, and can be read in 2.1.5. With the compressed file when I try to 
open it in 2.1.5 I get the message: ".21.lyx is not a 
readable LyX document." Perhaps this is a Windows only problem?


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Re: [LyX/master] Gcc 6+ use C++14 as default, so there is no need to enforce C++11

[Guillaume Munch]

Le 05/07/2016 12:11, Jean-Marc Lasgouttes a écrit :

Le 04/07/2016 à 23:34, Guillaume Munch a écrit :

Le 04/07/2016 12:25, Jean-Marc Lasgouttes a écrit :

commit 67ac031a33b1621fdadb903422de598595cc08d2

 Also, use gnu++11 unconditionnally with gcc as we used to do
before 67385e69.



Does this mean more problems that go unnoticed until people on OSX or
Windows try to compile?


No, because we use clang too :)


What do you mean? I would have to use clang if I want to compile without
gnu extensions?



I figured that the difference were minimal, but if I am wrong I can
revert this part of course. Only cygwin requires gnu++11.


As far as I understand, the difference is precisely to enable
non-standard extensions. I do see the point of disabling non-standard
extensions for a cross-platform software.

Re: [LyX/master] Autoconf : Try to select the correct Qt tools by using the -qt option

[Jean-Marc Lasgouttes]

Le 05/07/2016 à 12:02, Jean-Marc Lasgouttes a écrit :

commit d044986724e98921510c95adecb61d2688b1f598
Author: Jean-Marc Lasgouttes 
Date:   Mon Jul 4 16:22:57 2016 +0200

Autoconf : Try to select the correct Qt tools by using the -qt option

With this change, it is now possible to configure with --enable-qt5
and have make use "moc -qt=qt5" automatically.

This is done when the command qtchooser is available nd the desired Qt
version (qt4/qt5) is available.

This means that it is now possible to have qt4 and qt5 builds easily
on a same linux system.


If this proves to work correctly (i.e. if --enable-qt5 is all it takes 
to switch from Qt4 to Qt5), then this should eventually go to 2.2.x (no 
hurry).


JMarc

Re: [LyX/master] Gcc 6+ use C++14 as default, so there is no need to enforce C++11

[Jean-Marc Lasgouttes]

Le 04/07/2016 à 23:34, Guillaume Munch a écrit :

Le 04/07/2016 12:25, Jean-Marc Lasgouttes a écrit :

commit 67ac031a33b1621fdadb903422de598595cc08d2

 Also, use gnu++11 unconditionnally with gcc as we used to do
before 67385e69.



Does this mean more problems that go unnoticed until people on OSX or
Windows try to compile?


No, because we use clang too :)

I figured that the difference were minimal, but if I am wrong I can 
revert this part of course. Only cygwin requires gnu++11.


JMarc

Re: Compilation problems

[Jean-Marc Lasgouttes]

Le 04/07/2016 à 23:47, Guillaume Munch a écrit :

But doing so I noticed the following warning with clang, in case someone
fancies fixing it:

In file included from ../../src/EnchantChecker.cpp:14:
/usr/include/enchant/enchant++.h:55:25: warning:
'enchant::Exception::what' hides
  overloaded virtual function [-Woverloaded-virtual]
virtual const char * what () throw() {
 ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/5.3.1/../../../../include/c++/5.3.1/exception:68:25:
note:
  hidden overloaded virtual function 'std::exception::what' declared
here:
  different qualifiers (const vs none)
virtual const char* what() const _GLIBCXX_USE_NOEXCEPT;
^


I have reported it upstream (it is an obvious mistake), but it was 
decided not to fix it as it would break ABI.

https://github.com/AbiWord/enchant/issues/5

JMarc

Re: [LyX/master] Rationalise includes

[Guillaume Munch]

Le 05/07/2016 00:33, Stephan Witt a écrit :



Am 05.07.2016 um 00:24 schrieb Guillaume Munch :

Le 04/07/2016 12:06, Stephan Witt a écrit :

Hi Guillaume,

now I’m getting: …



Where are we after Pavel's and your changes?


I’m able to build LyX again.

But as Pavel said already: a git bisect was nearly impossible :(



Sorry for the inconveniences. Then thanks for testing and fixing quickly
so that there can still be some value in doing git bisect skip.

I am really curious to know Pavel's configure line given that he uses
gcc. If I could reproduce the problems then I would be able to test
beforehand more thoroughly when useful.

Guillaume

Re: Compilation problems

[Guillaume Munch]

Le 05/07/2016 00:55, Stephan Witt a écrit :


The enchant C++ header has more serious errors than this one.
Look at the method is_added …

I’m really surprised it’s so common on Linux.



Sorry, I missed the fact that it is not in the LyX source tree.

Re: Compiling with Microsoft Visual C++

[racoon]

On 04.07.2016 09:11, racoon wrote:

"Compile the INSTALL project to get a LyX installation in
C:\LyX\lyx-23-install"

I guess it means opening "INSTALL.vcxproj" and STRG-F5. Getting

"Build: 14 succeeded, 12 failed, 0 up-to-date, 0 skipped"

Can't run because of errors.


... And here are the errors from Visual Studio:



1>-- Build started: Project: lyx_version, Configuration: Debug Win32 
--
2>-- Build started: Project: translations, Configuration: Debug 
Win32 --
3>-- Build started: Project: check_ExternalTransforms, 
Configuration: Debug Win32 --

1>  -- Git-hash = 6dfc255
1>  -- Created C:/LyX/lyx-23-build/lyx_date.tmp
1>  -- Created C:/LyX/lyx-23-build/lyx_commit_hash.tmp
4>-- Build started: Project: LyX (applications\LyX\LyX), 
Configuration: Debug Win32 --
3>Qt5Cored.lib(Qt5Cored.dll) : fatal error LNK1112: module machine type 
'x64' conflicts with target machine type 'X86'
5>-- Build started: Project: check_Length, Configuration: Debug 
Win32 --
5>Qt5Cored.lib(Qt5Cored.dll) : fatal error LNK1112: module machine type 
'x64' conflicts with target machine type 'X86'
6>-- Build started: Project: check_ListingsCaption, Configuration: 
Debug Win32 --
6>Qt5Cored.lib(Qt5Cored.dll) : fatal error LNK1112: module machine type 
'x64' conflicts with target machine type 'X86'
7>-- Build started: Project: check_filetools, Configuration: Debug 
Win32 --
7>Qt5Cored.lib(Qt5Cored.dll) : fatal error LNK1112: module machine type 
'x64' conflicts with target machine type 'X86'
8>-- Build started: Project: check_layout, Configuration: Debug 
Win32 --
8>Qt5Cored.lib(Qt5Cored.dll) : fatal error LNK1112: module machine type 
'x64' conflicts with target machine type 'X86'
9>-- Build started: Project: check_lstrings, Configuration: Debug 
Win32 --
9>Qt5Cored.lib(Qt5Cored.dll) : fatal error LNK1112: module machine type 
'x64' conflicts with target machine type 'X86'
10>-- Build started: Project: check_trivstring, Configuration: Debug 
Win32 --
10>Qt5Cored.lib(Qt5Cored.dll) : fatal error LNK1112: module machine type 
'x64' conflicts with target machine type 'X86'
11>-- Build started: Project: doc (doc\doc), Configuration: Debug 
Win32 --
12>-- Build started: Project: check_convert, Configuration: Debug 
Win32 --
12>Qt5Cored.lib(Qt5Cored.dll) : fatal error LNK1112: module machine type 
'x64' conflicts with target machine type 'X86'
13>-- Build started: Project: tex2lyx 
(applications\TeX2LyX\tex2lyx), Configuration: Debug Win32 --
13>Qt5Cored.lib(Qt5Cored.dll) : fatal error LNK1112: module machine type 
'x64' conflicts with target machine type 'X86'
4>Qt5Widgetsd.lib(Qt5Widgetsd.dll) : fatal error LNK1112: module machine 
type 'x64' conflicts with target machine type 'X86'
== Build: 3 succeeded, 10 failed, 13 up-to-date, 0 skipped 
==

Re: Exporting compressed files

[José Abílio Matos]

On Saturday, May 28, 2016 3:00:09 PM WEST Andrew Parsloe wrote:
> I inadvertently tried exporting a compressed 2.2 file to 2.1.4. It was 
> not recognised by 2.1.4. When I try exporting an empty 2.2 compressed 
> file, it too isn't recognized by 2.1.4, so clearly this is not an 
> allowed mode of export. However I can't see anything saying that this 
> won't work in the documentation, and I wonder if it *should* be possible 
> -- uncompress in the background and then export that? (I have a number 
> of older files saved in compressed format which I'm looking at in 2.2 
> and saving, but also exporting to 2.1 format to retain a copy I can work 
> on in 2.1.4.)
> 
> Andrew

Hi Andrew,
are you having problems just with compressed files or with any type of 
files?

I ask this because I tried several examples here and it worked. So I am 
not able to replicate your findings. :-(

Could you try to uncompress the files firt and the export to 2.1.x and 
see 
if the problem persists?

A priori there is no reason for this not to work.

Regards,
-- 
José Abílio