Re: [patch] Fix color when branch name has a space

[Scott Kostyshak]

On Tue, Nov 01, 2016 at 08:29:10PM +0100, Jean-Marc Lasgouttes wrote:

> I am surprised that addArg does not need to add a space to the current
> argument.

It appears I got away with this because splitArg() handles double-quotes:

  // Extracts arguments from str into args. Arguments are delimted by
  // whitespace or by double quotes.

I've changed addArg() to add a space between arguments.

> I assume that one should also escape double quptes in the string.
> If I am not mistaken, they are handled when parsing the arguments.

Attached are two patches. The first allows for spaces in branch names.
The second allows for double-quotes.

For the first patch, I changed the write() routine to add quotes around
the branch name. Otherwise, read() gets confused. But should I instead
have changed the read routine()?

I'm not sure the second patch is correct. The branch name won't work
with a backslash at the end. I don't know how to fix this, because we
don't store how many arguments there are. Ideally, we would have an
argument class, right?

Scott
From ab3400821f8b01fcf78128352ff33d525f447199 Mon Sep 17 00:00:00 2001
From: Scott Kostyshak 
Date: Thu, 20 Oct 2016 22:41:31 -0400
Subject: [PATCH 1/2] Fix color when branch name has a space

The arguments are now double-quoted. This is handled by a new helper
function, FuncRequest::addArg().
---
 src/Buffer.cpp   |  6 --
 src/FuncRequest.cpp  | 11 +++
 src/FuncRequest.h|  2 ++
 src/frontends/qt4/GuiApplication.cpp |  4 ++--
 src/frontends/qt4/GuiDocument.cpp| 12 
 src/insets/InsetBranch.cpp   |  3 ++-
 6 files changed, 29 insertions(+), 9 deletions(-)

diff --git a/src/Buffer.cpp b/src/Buffer.cpp
index 86da237..fc68d30 100644
--- a/src/Buffer.cpp
+++ b/src/Buffer.cpp
@@ -2776,10 +2776,12 @@ void Buffer::dispatch(FuncRequest const & func, 
DispatchResult & dr)
} else {
undo().recordUndoBufferParams(CursorData());
branch_list.add(branch_name);
+   FuncRequest fr(LFUN_SET_COLOR);
branch = branch_list.find(branch_name);
+   fr.addArg(branch_name);
string const x11hexname = 
X11hexname(branch->color());
-   docstring const str = branch_name + ' ' + 
from_ascii(x11hexname);
-   lyx::dispatch(FuncRequest(LFUN_SET_COLOR, str));
+   fr.addArg(from_ascii(x11hexname));
+   lyx::dispatch(fr);
dr.setError(false);
dr.screenUpdate(Update::Force);
}
diff --git a/src/FuncRequest.cpp b/src/FuncRequest.cpp
index 224ba27..db1b940 100644
--- a/src/FuncRequest.cpp
+++ b/src/FuncRequest.cpp
@@ -119,6 +119,17 @@ string FuncRequest::getLongArg(unsigned int i) const
 }
 
 
+void FuncRequest::addArg(docstring const & str)
+{
+   // adding spaces between arguments is not necessary if arguments have
+   // double-quotes (see splitArg()). But even in this case it makes the
+   // argument more readable.
+   if (!argument_.empty())
+   argument_ = argument_ + ' ';
+   argument_ = argument_ + '"' + str + '"';
+}
+
+
 bool operator==(FuncRequest const & lhs, FuncRequest const & rhs)
 {
return lhs.action() == rhs.action() && lhs.argument() == rhs.argument();
diff --git a/src/FuncRequest.h b/src/FuncRequest.h
index a5822f4..dc5895e 100644
--- a/src/FuncRequest.h
+++ b/src/FuncRequest.h
@@ -85,6 +85,8 @@ public:
/// argument parsing, extract argument i as std::string,
/// eating all characters up to the end of the command line
std::string getLongArg(unsigned int i) const;
+   /// Adds an argument
+   void addArg(docstring const &);
 
/// 
static FuncRequest const unknown;
diff --git a/src/frontends/qt4/GuiApplication.cpp 
b/src/frontends/qt4/GuiApplication.cpp
index 0eb55ba..048ce0f 100644
--- a/src/frontends/qt4/GuiApplication.cpp
+++ b/src/frontends/qt4/GuiApplication.cpp
@@ -1738,8 +1738,8 @@ void GuiApplication::dispatch(FuncRequest const & cmd, 
DispatchResult & dr)
}
 
case LFUN_SET_COLOR: {
-   string lyx_name;
-   string const x11_name = split(to_utf8(cmd.argument()), 
lyx_name, ' ');
+   string lyx_name = cmd.getArg(0);
+   string x11_name = cmd.getArg(1);
if (lyx_name.empty() || x11_name.empty()) {
if (current_view_)
current_view_->message(
diff --git a/src/frontends/qt4/GuiDocument.cpp 
b/src/frontends/qt4/GuiDocument.cpp
index 2293ce3..25594cd 100644
--- a/src/frontends/qt4/GuiDocument.cpp
+++ b/src/frontends/qt4/GuiDocument.cpp
@@ -4129,8 +4129,10 @@ void 

Build failed in Jenkins: Build branch "master" » ubuntu-xenial-qt4-autotools-extended #91

[ci-lyx]

https://ci.inria.fr/lyx/job/build-master-head/job/ubuntu-xenial-qt4-autotools-extended/91/Changes:

[kornel] Amend 0e50ad8 'move mythes sources to 3rdparty' for cmake build.

--
[...truncated 1202 lines...]
make[3]: Leaving directory '/build/workspace/lib/doc'
Making all in lyx2lyx
make[3]: Entering directory '/build/workspace/lib/lyx2lyx'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory '/build/workspace/lib/lyx2lyx'
make[3]: Entering directory '/build/workspace/lib'
  GEN  lyx.desktop
  GEN  lyx.png
  GEN  lyx.svg
make[3]: Leaving directory '/build/workspace/lib'
make[2]: Leaving directory '/build/workspace/lib'
Making all in src/client
make[2]: Entering directory '/build/workspace/src/client'
make  all-am
make[3]: Entering directory '/build/workspace/src/client'
make[3]: Nothing to be done for 'all-am'.
make[3]: Leaving directory '/build/workspace/src/client'
make[2]: Leaving directory '/build/workspace/src/client'
Making all in src/tex2lyx
make[2]: Entering directory '/build/workspace/src/tex2lyx'
make[2]: Nothing to be done for 'all'.
make[2]: Leaving directory '/build/workspace/src/tex2lyx'
make[2]: Entering directory '/build/workspace'
make[2]: Leaving directory '/build/workspace'
make[1]: Leaving directory '/build/workspace'
# Executing: make check
Making check in autotests
make[1]: Entering directory '/build/workspace/autotests'
make[1]: Nothing to be done for 'check'.
make[1]: Leaving directory '/build/workspace/autotests'
Making check in config
make[1]: Entering directory '/build/workspace/config'
make[1]: Nothing to be done for 'check'.
make[1]: Leaving directory '/build/workspace/config'
Making check in development
make[1]: Entering directory '/build/workspace/development'
make[2]: Entering directory '/build/workspace/development'
make[2]: Nothing to be done for 'check-am'.
make[2]: Leaving directory '/build/workspace/development'
make[1]: Leaving directory '/build/workspace/development'
Making check in po
make[1]: Entering directory '/build/workspace/po'
make[1]: Nothing to be done for 'check'.
make[1]: Leaving directory '/build/workspace/po'
Making check in 3rdparty
make[1]: Entering directory '/build/workspace/3rdparty'
make[2]: Entering directory '/build/workspace/3rdparty'
make[2]: Nothing to be done for 'check-am'.
make[2]: Leaving directory '/build/workspace/3rdparty'
make[1]: Leaving directory '/build/workspace/3rdparty'
Making check in src
make[1]: Entering directory '/build/workspace/src'
rm -f hash-temp \
@echo "  GEN  lyx_commit_hash.h";hash=`cd ".." && git log -1 
--pretty=format:%H 2>/dev/null || echo none` ; \
sed s/@LYX_GIT_COMMIT_HASH@/$hash/ "."/lyx_commit_hash.h.in >hash-temp ; \
cmp -s lyx_commit_hash.h hash-temp || cp hash-temp lyx_commit_hash.h ; \
rm -f hash-temp
make  check-recursive
make[2]: Entering directory '/build/workspace/src'
Making check in support
make[3]: Entering directory '/build/workspace/src/support'
make  check-am
make[4]: Entering directory '/build/workspace/src/support'
make  check_convert check_filetools check_lstrings check_trivstring
make[5]: Entering directory '/build/workspace/src/support'
  CXX  tests/check_convert.o
  CXX  tests/dummy_functions.o
  CXX  tests/boost.o
  CXXLDcheck_convert
  CXX  tests/check_filetools.o
  CXXLDcheck_filetools
  CXX  tests/check_lstrings.o
  CXXLDcheck_lstrings
  CXX  tests/check_trivstring.o
  CXXLDcheck_trivstring
make[5]: Leaving directory '/build/workspace/src/support'
make  check-TESTS
make[5]: Entering directory '/build/workspace/src/support'
make[6]: Entering directory '/build/workspace/src/support'
PASS: tests/test_convert
PASS: tests/test_filetools
PASS: tests/test_lstrings
PASS: tests/test_trivstring

Testsuite summary for LyX 2.3.0dev

# TOTAL: 4
# PASS:  4
# SKIP:  0
# XFAIL: 0
# FAIL:  0
# XPASS: 0
# ERROR: 0

make[6]: Leaving directory '/build/workspace/src/support'
make[5]: Leaving directory '/build/workspace/src/support'
make[4]: Leaving directory '/build/workspace/src/support'
make[3]: Leaving directory '/build/workspace/src/support'
Making check in frontends
make[3]: Entering directory '/build/workspace/src/frontends'
Making check in qt4
make[4]: Entering directory '/build/workspace/src/frontends/qt4'
make  check-am
make[5]: Entering directory '/build/workspace/src/frontends/qt4'
make[5]: Nothing to be done for 'check-am'.
make[5]: Leaving directory '/build/workspace/src/frontends/qt4'
make[4]: Leaving directory '/build/workspace/src/frontends/qt4'
Making check in .
make[4]: Entering directory '/build/workspace/src/frontends'
make  biblio
make[5]: Entering directory '/build/workspace/src/frontends'
  CXX  tests/biblio.o
  CXX  tests/boost.o
  CXXLD

Jenkins build is back to normal : Build branch "master" » ubuntu-latest-qt5-cmake #78

[ci-lyx]

https://ci.inria.fr/lyx/job/build-master-head/job/ubuntu-latest-qt5-cmake/78/

Re: Crash in File-Open

[Scott Kostyshak]

On Mon, Mar 06, 2017 at 12:19:48PM +0100, Kornel Benko wrote:

> Looks like nobody seems to to be interested.

I'm interested and will test in a week when I'm home and have access to
the computer where I have Qt 5.8 installed.

Scott


signature.asc
Description: PGP signature

Re: LyX 2.2 cannot read a document from LyX 2.1?

[José Abílio Matos]

On Monday, 6 March 2017 22.27.25 WET Enrico Forestieri wrote:
> The problem is that the file starts with a U+FEFF BOM mark, and most
> probably lyx2lyx doesn't expect to deal with BOM marks. Actually, the
> conversion succeeds, but the BOM mark is left in place (it now appears
> on the second line, though). Consequently, lyx then chokes on reading it.
> It suffices removing the bogus second line of the converted file to make
> it perfectly readable by lyx 2.2.
> LyX 2.1 is able to read it because no conversion is necessary and the BOM
> mark is skipped because it is dealt with by the lexer when it is at the
> beginning of the file.

Thank you for noticing that. :-)

The next question is how it got there. I assume of course that somewhere 
windows was involved. :-)

Is this a valid process that we should support?

If so the following patch fixes this for me, for both python 2 and 3.

-- 
José Abíliodiff --git a/lib/lyx2lyx/LyX.py b/lib/lyx2lyx/LyX.py
index 77ccdd0..b70fa3f 100644
--- a/lib/lyx2lyx/LyX.py
+++ b/lib/lyx2lyx/LyX.py
@@ -29,6 +29,7 @@ import sys
 import re
 import time
 import io
+import codecs
 
 try:
 import lyx2lyx_version
@@ -525,6 +526,11 @@ class LyX_base:
 initial_comment = " ".join(["#LyX %s created this file." % version__,
 "For more info see http://www.lyx.org/;])
 
+# Remove UTF8 BOM marker if present
+text = unicode if PY2 else str
+if text(self.header[0]).encode("utf-8").startswith(codecs.BOM_UTF8):
+self.header[0] = self.header[0][1:]
+
 # Simple heuristic to determine the comment that always starts
 # a lyx file
 if self.header[0].startswith("#"):
@@ -547,7 +553,7 @@ class LyX_base:
 if PY2:
 result = fileformat.match(line)
 else:
-result = fileformat.match(line.decode('ascii'))
+result = fileformat.match(line.decode('ascii','ignore'))
 if result:
 return self.lyxformat(result.group(1))
 else:

Re: How far is 2.3.0?

[Scott Kostyshak]

On Sat, Mar 04, 2017 at 09:53:08PM +0100, Guillaume Munch wrote:

> But the most important to me is if 2.3 could please be branched at
> feature freeze so that I don't have a backlog of patches to rebase six
> months later.

This is a good discussion to have early. My poor decision regarding
branching for the 2.2.0 cycle caused a lot of frustration for everyone.

When we branch 2.3, this branch would be named "2.3.x", right? The
slightly weird thing would be that the release manager would be in
charge of the 2.3.x branch until 2.3.0 and then the stable branch
maintainer would be in charge of the branch after 2.3.0. Before, it was
more clear because the stable branch maintainer was always in charge of
2.y.x branches because they were branched on release. Did I get that
difference correct? I suppose an alternative would be to call the branch
"2.3.0" and then after 2.3.0 is released, branch 2.3.x from 2.3.0. But I
think that is more complicated.

From what I understand, the only reason not to branch early is to avoid
work duplication (e.g. if automatic merge is not correct) on master
branch and 2.3.x branch. Are there any other disadvantages to branching
early? Perhaps there is a small probability that we forget a backport
(because we have to backport from master to both 2.3.x anad 2.2.x). For
the sake of argument, what would be the disadvantage to branching even
before the feature freeze?

This discussion gets more complex once we talk about our opinions
regarding 2.3.1 and 2.3.2 releases. When we get close to releasing
2.3.0, there will be bug fixes that might be viewed as desirable for
eventual inclusion in 2.3.x, but too risky for 2.3.0. If I remember
correctly, this was a point of debate. On the one hand, I think some
people thought "if a patch fixes a bug, and if it is viewed to be safe
enough to consider for stable branch, it should be included in 2.3.0 if
2.3.0 has not been released." On the other hand, some (including me)
thought "even if a patch fixes a bug and even if it looks safe, if the
bug is not important and if the patch didn't get testing, it might be
viewed as too risky to include the patch in 2.3.0 a week before
release". Note that "too risky" here does not mean risky on an absolute
level, it just means that the benefit-to-risk ratio is low.

Depending on which argument one prefers in the above paragraph, that is
what decides whether we should have e.g. 2.3.1-staging and 2.3.2-staging
branches or not. Why both 2.3.1-staging and 2.3.2-staging? Because 2.3.1
might be released very quickly after 2.3.0 is released, so it should not
be expected that a patch in there will get much additional testing. I
think there is a view that we should keep the possibility of doing a 2.3.1
release soon after the 2.3.0 release. The alternative might be to do a
2.3.0.1 release if there is real urgency, and otherwise proceed with
2.3.1 as a normal minor release.

Actually, now that I think about it, it seems that we could reduce the
number of branches by one by not having 2.3.1-staging. I wonder if the
following would be a clean way of proceeding: instead of 2.3.1-staging
and 2.3.2-staging, we just have 2.3.x-staging, and once 2.3.0 is tagged
(which is on the 2.3.x branch), 2.3.x-staging is immediately merged into
2.3.x. In the case that we need to do a quick release (e.g. a couple of
weeks after 2.3.0 is released), we branch 2.3.1 (or 2.3.0.1 if
preferred) from 2.3.0 (which will be behind 2.3.x at this point), and
just include the critical patches.  For the case where we do not need to
do an emergency release, we branch 2.3.1 from 2.3.x, as normal.

In case anyone is curious, here are some relevant discussions regarding
branching for the 2.2.0 cycle. If I understand correctly, most of the
problems and confusion would have been solved if I had branched 2.2.0
early.

https://www.mail-archive.com/search?l=mid=20160411230555.GA9496%40OptiPlex-9020.ad.ufl.edu
https://www.mail-archive.com/search?l=mid=57123167.2040904%40lyx.org
https://www.mail-archive.com/search?l=mid=57129605.6090806%40lyx.org

In case someone is craving wants more complexity, we can also discuss
our view for the last point release of 2.2.x. For example, should all
commits to the 2.3.x branch be backported to the 2.2.x branch? Or only
critical patches and the lyx2lyx patch?

> If you create a 2.4 milestone then I can already re-target the bugs that
> I care about so as to have a better picture of 2.3.

+1

We should also perhaps discuss how trac should be handled more
generally, but I think it makes sense to figure out our git branching
strategy first. For a disucssion on how we handled trac for the 2.2.0
cycle, see:
https://www.mail-archive.com/search?l=mid=57129763.9060007%40lyx.org

Scott


signature.asc
Description: PGP signature

Re: LyX 2.2 cannot read a document from LyX 2.1?

[Enrico Forestieri]

On Mon, Mar 06, 2017 at 05:53:58PM +, José Abílio Matos wrote:
> On Monday, 6 March 2017 12.35.47 WET Kornel Benko wrote:
> > Am Montag, 6. März 2017 um 13:13:58, schrieb Matěj Cepl 
> > 
> > > Yes, this is not a minimal example, but I am hesitant to touch this
> > > document from LyX 2.1 so that I wouldn’t accidentally fixed it. When
> > > trying to open it with lyx-2.2.2-1.fc25.x86_64 I get this:
> > > 
> > > matej@mitmanek: marketa$ lyx Ph.D.project-Brno1.lyx
> > > Error: Document format failure
> > > 
> > > /tmp/lyx_tmpdir.CLmZrzV11492/Buffer_convertLyXFormatk11492.lyx is not a
> > > readable LyX document.
> > > matej@mitmanek: marketa$
> > > 
> > > Any ideas, what's wrong?
> > > 
> > > Best,
> > > 
> > > Matěj
> > 
> > The document language is English. But there are 4 entries in the document
> > stating '\lang english'.
> > 
> > Removing this 4 lines, the document is readable.
> > 
> > OTOH, reading directly with lyx2.1, there is no problem.
> > 
> > For me it looks like lyx-deficiency.
> > 
> > Kornel
> 
> I agree. A brief look into development/FORMAT does not give any clue about a 
> file format that could be responsible for this change.
> 
> The next step is then to pinpoint what is the problem, is this a problem of 
> lyx-2.1, of lyx2lyx or of the lyx-2.2 lexer?
> 
> If the problem is lyx-2.1 or lyx2lyx the change is simple we can add a last 
> change in the lyx-2.1 converter that removes this instances: \lang that match 
> the document language. The patch is easy enough but I would like to understand
> the disease before proposing a cure. ;-)

The problem is that the file starts with a U+FEFF BOM mark, and most
probably lyx2lyx doesn't expect to deal with BOM marks. Actually, the
conversion succeeds, but the BOM mark is left in place (it now appears
on the second line, though). Consequently, lyx then chokes on reading it.
It suffices removing the bogus second line of the converted file to make
it perfectly readable by lyx 2.2.
LyX 2.1 is able to read it because no conversion is necessary and the BOM
mark is skipped because it is dealt with by the lexer when it is at the
beginning of the file.

-- 
Enrico

Re: Crash in File-Open

[Kornel Benko]

Am Montag, 6. März 2017 um 23:14:34, schrieb Kornel Benko 
> Am Montag, 6. März 2017 um 22:02:11, schrieb Enrico Forestieri 
> 
> > On Mon, Mar 06, 2017 at 09:11:08PM +0100, Kornel Benko wrote:
> > > 
> > > Nice, what is the version of your debian? Which desktop?
> > 
> > Debian jessie, gnome.
> > 
> > > Googling implies that this may be important.
> > > But nothing I tried helped here.
> > 
> > I only found this:
> > https://www.qcad.org/bugtracker/index.php?do=details_id=1545
> > but they actually state that Qt 5.8 fixes it...
> > 
> 
> Apparently not completely. The article is about Mint18.1, my machine is Mint 
> 17.3.
> But one point may be important. Switching to QT5.8, I never restarted the 
> session.
> 
> Will try.
> 

OK, it does not help. Maybe with the mentioned new snapshot in this bugtracker 
for QT5.8 things will
improve.

Kornel

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

Re: Crash in File-Open

[Kornel Benko]

Am Montag, 6. März 2017 um 22:02:11, schrieb Enrico Forestieri 
> On Mon, Mar 06, 2017 at 09:11:08PM +0100, Kornel Benko wrote:
> > 
> > Nice, what is the version of your debian? Which desktop?
> 
> Debian jessie, gnome.
> 
> > Googling implies that this may be important.
> > But nothing I tried helped here.
> 
> I only found this:
> https://www.qcad.org/bugtracker/index.php?do=details_id=1545
> but they actually state that Qt 5.8 fixes it...
> 

Apparently not completely. The article is about Mint18.1, my machine is Mint 
17.3.
But one point may be important. Switching to QT5.8, I never restarted the 
session.

Will try.

Kornel

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

Re: Crash in File-Open

[Enrico Forestieri]

On Mon, Mar 06, 2017 at 09:11:08PM +0100, Kornel Benko wrote:
> 
> Nice, what is the version of your debian? Which desktop?

Debian jessie, gnome.

> Googling implies that this may be important.
> But nothing I tried helped here.

I only found this:
https://www.qcad.org/bugtracker/index.php?do=details_id=1545
but they actually state that Qt 5.8 fixes it...

-- 
Enrico

Re: Crash in File-Open

[Kornel Benko]

Am Montag, 6. März 2017 um 18:27:36, schrieb Enrico Forestieri 
> On Mon, Mar 06, 2017 at 11:45:00AM -0500, Richard Heck wrote:
> > On 03/06/2017 06:19 AM, Kornel Benko wrote:
> > > Ping ...
> > >
> > > Am Donnerstag, 23. Februar 2017 um 13:52:41, schrieb Kornel Benko 
> > > 
> > >> OS: Linux =~ ubuntu 14.04, 64bit
> > >>
> > >> I gave a try to QT5.8. But now I am getting crashes any time I try to 
> > >> open a file with File->Open.
> > >> This does not happen with 'open recent' or if lyx is called with a file 
> > >> parameter.
> > >>
> > >> The backtrace shows that the crash in call to dmg.exec() 
> > >> src/frontends/qt4/FileDialog.cpp:161
> > >>
> > >> The enclosing routine, FileDialog::open(path, filters suggested)
> > >>  path = toqstr(".")
> > >>  filters = filter(qt_("LyX Documents (*.lyx)")
> > >> so nothing special.
> > >>
> > >> If I try to use lyx compiled with QT5.7, so the crash is there too as 
> > >> long as QT5.8 is selected by ldconfig.
> > >> If I try to use lyx compiled with QT5.8 ans select QT5.7 with ldconfig, 
> > >> lyx does not start because
> > >> `Qt_5.8' is not found.
> > >>
> > >> Someone interested in backtrace?
> > >>
> > >> I try to compile with automake ...
> > >> Compilation went smoothly.
> > >> But I have the same effect. So at least it does not depend on 
> > >> build-system.
> > >>
> > > Looks like nobody seems to to be interested.
> > > For me, the only workaround is to use USE_NATIVE_FILEDIALOG=1.
> > > I don't like it because the native dialog is not so nice as that from LyX,
> > > but at least the so compiled lyx is usable.
> > >
> > > Attached patch is for cmake build.
> > >
> > > The same change is needed here for branch2.2.
> > 
> > OK for stable.
> 
> I think that this needs some investigation. I cannot reproduce the
> behavior on debian with Qt 5.8.
> 

Nice, what is the version of your debian? Which desktop? Googling implies that 
this may be important.
But nothing I tried helped here.

Kornel

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

Build failed in Jenkins: Build branch "master" » ubuntu-xenial-qt4-autotools-extended #90

[ci-lyx]

https://ci.inria.fr/lyx/job/build-master-head/job/ubuntu-xenial-qt4-autotools-extended/90/--
[...truncated 1202 lines...]
make[3]: Leaving directory '/build/workspace/lib/doc'
Making all in lyx2lyx
make[3]: Entering directory '/build/workspace/lib/lyx2lyx'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory '/build/workspace/lib/lyx2lyx'
make[3]: Entering directory '/build/workspace/lib'
  GEN  lyx.desktop
  GEN  lyx.png
  GEN  lyx.svg
make[3]: Leaving directory '/build/workspace/lib'
make[2]: Leaving directory '/build/workspace/lib'
Making all in src/client
make[2]: Entering directory '/build/workspace/src/client'
make  all-am
make[3]: Entering directory '/build/workspace/src/client'
make[3]: Nothing to be done for 'all-am'.
make[3]: Leaving directory '/build/workspace/src/client'
make[2]: Leaving directory '/build/workspace/src/client'
Making all in src/tex2lyx
make[2]: Entering directory '/build/workspace/src/tex2lyx'
make[2]: Nothing to be done for 'all'.
make[2]: Leaving directory '/build/workspace/src/tex2lyx'
make[2]: Entering directory '/build/workspace'
make[2]: Leaving directory '/build/workspace'
make[1]: Leaving directory '/build/workspace'
# Executing: make check
Making check in autotests
make[1]: Entering directory '/build/workspace/autotests'
make[1]: Nothing to be done for 'check'.
make[1]: Leaving directory '/build/workspace/autotests'
Making check in config
make[1]: Entering directory '/build/workspace/config'
make[1]: Nothing to be done for 'check'.
make[1]: Leaving directory '/build/workspace/config'
Making check in development
make[1]: Entering directory '/build/workspace/development'
make[2]: Entering directory '/build/workspace/development'
make[2]: Nothing to be done for 'check-am'.
make[2]: Leaving directory '/build/workspace/development'
make[1]: Leaving directory '/build/workspace/development'
Making check in po
make[1]: Entering directory '/build/workspace/po'
make[1]: Nothing to be done for 'check'.
make[1]: Leaving directory '/build/workspace/po'
Making check in 3rdparty
make[1]: Entering directory '/build/workspace/3rdparty'
make[2]: Entering directory '/build/workspace/3rdparty'
make[2]: Nothing to be done for 'check-am'.
make[2]: Leaving directory '/build/workspace/3rdparty'
make[1]: Leaving directory '/build/workspace/3rdparty'
Making check in src
make[1]: Entering directory '/build/workspace/src'
rm -f hash-temp \
@echo "  GEN  lyx_commit_hash.h";hash=`cd ".." && git log -1 
--pretty=format:%H 2>/dev/null || echo none` ; \
sed s/@LYX_GIT_COMMIT_HASH@/$hash/ "."/lyx_commit_hash.h.in >hash-temp ; \
cmp -s lyx_commit_hash.h hash-temp || cp hash-temp lyx_commit_hash.h ; \
rm -f hash-temp
make  check-recursive
make[2]: Entering directory '/build/workspace/src'
Making check in support
make[3]: Entering directory '/build/workspace/src/support'
make  check-am
make[4]: Entering directory '/build/workspace/src/support'
make  check_convert check_filetools check_lstrings check_trivstring
make[5]: Entering directory '/build/workspace/src/support'
  CXX  tests/check_convert.o
  CXX  tests/dummy_functions.o
  CXX  tests/boost.o
  CXXLDcheck_convert
  CXX  tests/check_filetools.o
  CXXLDcheck_filetools
  CXX  tests/check_lstrings.o
  CXXLDcheck_lstrings
  CXX  tests/check_trivstring.o
  CXXLDcheck_trivstring
make[5]: Leaving directory '/build/workspace/src/support'
make  check-TESTS
make[5]: Entering directory '/build/workspace/src/support'
make[6]: Entering directory '/build/workspace/src/support'
PASS: tests/test_convert
PASS: tests/test_filetools
PASS: tests/test_lstrings
PASS: tests/test_trivstring

Testsuite summary for LyX 2.3.0dev

# TOTAL: 4
# PASS:  4
# SKIP:  0
# XFAIL: 0
# FAIL:  0
# XPASS: 0
# ERROR: 0

make[6]: Leaving directory '/build/workspace/src/support'
make[5]: Leaving directory '/build/workspace/src/support'
make[4]: Leaving directory '/build/workspace/src/support'
make[3]: Leaving directory '/build/workspace/src/support'
Making check in frontends
make[3]: Entering directory '/build/workspace/src/frontends'
Making check in qt4
make[4]: Entering directory '/build/workspace/src/frontends/qt4'
make  check-am
make[5]: Entering directory '/build/workspace/src/frontends/qt4'
make[5]: Nothing to be done for 'check-am'.
make[5]: Leaving directory '/build/workspace/src/frontends/qt4'
make[4]: Leaving directory '/build/workspace/src/frontends/qt4'
Making check in .
make[4]: Entering directory '/build/workspace/src/frontends'
make  biblio
make[5]: Entering directory '/build/workspace/src/frontends'
  CXX  tests/biblio.o
  CXX  tests/boost.o
  CXXLDbiblio
make[5]: Leaving directory '/build/workspace/src/frontends'
make  check-TESTS

Re: Build failed in Jenkins: Build branch "master" » ubuntu-latest-qt5-cmake #77

[Kornel Benko]

Am Montag, 6. März 2017 um 19:24:16, schrieb ci-...@inria.fr
> https://ci.inria.fr/lyx/job/build-master-head/job/ubuntu-latest-qt5-cmake/77/--
> [...truncated 1572 lines...]
std=c++14 -fno-strict-aliasing  -Wall -Wunused-parameter --std=c++14 -O3 
-DNDEBUG   -DBOOST_USER_CONFIG="" -fPIC -std=gnu++14 -o 
CMakeFiles/lyx2.3.dir/Font.cpp.o -c /build/lyx/src/Font.cpp
> [ 81%] Building CXX object src/CMakeFiles/lyx2.3.dir/Thesaurus.cpp.o
> cd /build/lyx/build/src && /usr/bin/c++   -DQT_CONCURRENT_LIB -DQT_CORE_LIB 
> -DQT_GUI_LIB -DQT_NO_DEBUG -DQT_SVG_LIB -DQT_WIDGETS_LIB -I/build/lyx/build 
> -I/build/lyx/src -I/build/lyx/3rdparty/boost -I/build/lyx/build/src -isystem 
> /usr/include/x86_64-linux-gnu/qt5 -isystem 
> /usr/include/x86_64-linux-gnu/qt5/QtCore -isystem 
> /usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++-64 -isystem 
> /usr/include/x86_64-linux-gnu/qt5/QtGui -isystem 
> /usr/include/x86_64-linux-gnu/qt5/QtWidgets -isystem 
> /usr/include/x86_64-linux-gnu/qt5/QtConcurrent -isystem 
> /usr/include/x86_64-linux-gnu/qt5/QtSvg  -Wall -Wunused-parameter --std=c++14 
> -fno-strict-aliasing  -Wall -Wunused-parameter --std=c++14 -O3 -DNDEBUG   
> -DBOOST_USER_CONFIG="" -fPIC -std=gnu++14 -o 
> CMakeFiles/lyx2.3.dir/Thesaurus.cpp.o -c /build/lyx/src/Thesaurus.cpp
> /build/lyx/src/Thesaurus.cpp:31:10: error: #include expects "FILENAME" or 
> 
>  #include MYTHES_H_LOCATION

Please wait a moment longer. I am on the matter.

Kornel

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

Build failed in Jenkins: Build branch "master" » ubuntu-latest-qt5-cmake #77

[ci-lyx]

https://ci.inria.fr/lyx/job/build-master-head/job/ubuntu-latest-qt5-cmake/77/--
[...truncated 1572 lines...]
[ 73%] Building CXX object src/mathed/CMakeFiles/mathed.dir/MathAtom.cpp.o
cd /build/lyx/build/src/mathed && /usr/bin/c++   -DQT_CORE_LIB -DQT_NO_DEBUG 
-I/build/lyx/build -I/build/lyx/src -I/build/lyx/3rdparty/boost 
-I/build/lyx/src/mathed -isystem /usr/include/x86_64-linux-gnu/qt5 -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtCore -isystem 
/usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++-64  -Wall -Wunused-parameter 
--std=c++14 -fno-strict-aliasing  -Wall -Wunused-parameter --std=c++14 -O3 
-DNDEBUG   -DBOOST_USER_CONFIG="" -fPIC -std=gnu++14 -o 
CMakeFiles/mathed.dir/MathAtom.cpp.o -c /build/lyx/src/mathed/MathAtom.cpp
[ 73%] Building CXX object src/mathed/CMakeFiles/mathed.dir/InsetMathExInt.cpp.o
cd /build/lyx/build/src/mathed && /usr/bin/c++   -DQT_CORE_LIB -DQT_NO_DEBUG 
-I/build/lyx/build -I/build/lyx/src -I/build/lyx/3rdparty/boost 
-I/build/lyx/src/mathed -isystem /usr/include/x86_64-linux-gnu/qt5 -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtCore -isystem 
/usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++-64  -Wall -Wunused-parameter 
--std=c++14 -fno-strict-aliasing  -Wall -Wunused-parameter --std=c++14 -O3 
-DNDEBUG   -DBOOST_USER_CONFIG="" -fPIC -std=gnu++14 -o 
CMakeFiles/mathed.dir/InsetMathExInt.cpp.o -c 
/build/lyx/src/mathed/InsetMathExInt.cpp
[ 73%] Building CXX object src/mathed/CMakeFiles/mathed.dir/InsetMathFrac.cpp.o
cd /build/lyx/build/src/mathed && /usr/bin/c++   -DQT_CORE_LIB -DQT_NO_DEBUG 
-I/build/lyx/build -I/build/lyx/src -I/build/lyx/3rdparty/boost 
-I/build/lyx/src/mathed -isystem /usr/include/x86_64-linux-gnu/qt5 -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtCore -isystem 
/usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++-64  -Wall -Wunused-parameter 
--std=c++14 -fno-strict-aliasing  -Wall -Wunused-parameter --std=c++14 -O3 
-DNDEBUG   -DBOOST_USER_CONFIG="" -fPIC -std=gnu++14 -o 
CMakeFiles/mathed.dir/InsetMathFrac.cpp.o -c 
/build/lyx/src/mathed/InsetMathFrac.cpp
[ 73%] Building CXX object src/mathed/CMakeFiles/mathed.dir/InsetMathSqrt.cpp.o
cd /build/lyx/build/src/mathed && /usr/bin/c++   -DQT_CORE_LIB -DQT_NO_DEBUG 
-I/build/lyx/build -I/build/lyx/src -I/build/lyx/3rdparty/boost 
-I/build/lyx/src/mathed -isystem /usr/include/x86_64-linux-gnu/qt5 -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtCore -isystem 
/usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++-64  -Wall -Wunused-parameter 
--std=c++14 -fno-strict-aliasing  -Wall -Wunused-parameter --std=c++14 -O3 
-DNDEBUG   -DBOOST_USER_CONFIG="" -fPIC -std=gnu++14 -o 
CMakeFiles/mathed.dir/InsetMathSqrt.cpp.o -c 
/build/lyx/src/mathed/InsetMathSqrt.cpp
[ 73%] Building CXX object src/mathed/CMakeFiles/mathed.dir/InsetMathDiff.cpp.o
cd /build/lyx/build/src/mathed && /usr/bin/c++   -DQT_CORE_LIB -DQT_NO_DEBUG 
-I/build/lyx/build -I/build/lyx/src -I/build/lyx/3rdparty/boost 
-I/build/lyx/src/mathed -isystem /usr/include/x86_64-linux-gnu/qt5 -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtCore -isystem 
/usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++-64  -Wall -Wunused-parameter 
--std=c++14 -fno-strict-aliasing  -Wall -Wunused-parameter --std=c++14 -O3 
-DNDEBUG   -DBOOST_USER_CONFIG="" -fPIC -std=gnu++14 -o 
CMakeFiles/mathed.dir/InsetMathDiff.cpp.o -c 
/build/lyx/src/mathed/InsetMathDiff.cpp
[ 74%] Building CXX object 
src/mathed/CMakeFiles/mathed.dir/InsetMathFontOld.cpp.o
cd /build/lyx/build/src/mathed && /usr/bin/c++   -DQT_CORE_LIB -DQT_NO_DEBUG 
-I/build/lyx/build -I/build/lyx/src -I/build/lyx/3rdparty/boost 
-I/build/lyx/src/mathed -isystem /usr/include/x86_64-linux-gnu/qt5 -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtCore -isystem 
/usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++-64  -Wall -Wunused-parameter 
--std=c++14 -fno-strict-aliasing  -Wall -Wunused-parameter --std=c++14 -O3 
-DNDEBUG   -DBOOST_USER_CONFIG="" -fPIC -std=gnu++14 -o 
CMakeFiles/mathed.dir/InsetMathFontOld.cpp.o -c 
/build/lyx/src/mathed/InsetMathFontOld.cpp
[ 74%] Building CXX object 
src/mathed/CMakeFiles/mathed.dir/InsetMathComment.cpp.o
cd /build/lyx/build/src/mathed && /usr/bin/c++   -DQT_CORE_LIB -DQT_NO_DEBUG 
-I/build/lyx/build -I/build/lyx/src -I/build/lyx/3rdparty/boost 
-I/build/lyx/src/mathed -isystem /usr/include/x86_64-linux-gnu/qt5 -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtCore -isystem 
/usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++-64  -Wall -Wunused-parameter 
--std=c++14 -fno-strict-aliasing  -Wall -Wunused-parameter --std=c++14 -O3 
-DNDEBUG   -DBOOST_USER_CONFIG="" -fPIC -std=gnu++14 -o 
CMakeFiles/mathed.dir/InsetMathComment.cpp.o -c 
/build/lyx/src/mathed/InsetMathComment.cpp
[ 74%] Building CXX object 
src/mathed/CMakeFiles/mathed.dir/InsetMathDecoration.cpp.o
cd /build/lyx/build/src/mathed && /usr/bin/c++   -DQT_CORE_LIB -DQT_NO_DEBUG 
-I/build/lyx/build -I/build/lyx/src -I/build/lyx/3rdparty/boost 
-I/build/lyx/src/mathed -isystem /usr/include/x86_64-linux-gnu/qt5 -isystem 

Re: LyX 2.2 cannot read a document from LyX 2.1?

[José Abílio Matos]

On Monday, 6 March 2017 12.35.47 WET Kornel Benko wrote:
> Am Montag, 6. März 2017 um 13:13:58, schrieb Matěj Cepl 
> 
> > Yes, this is not a minimal example, but I am hesitant to touch this
> > document from LyX 2.1 so that I wouldn’t accidentally fixed it. When
> > trying to open it with lyx-2.2.2-1.fc25.x86_64 I get this:
> > 
> > matej@mitmanek: marketa$ lyx Ph.D.project-Brno1.lyx
> > Error: Document format failure
> > 
> > /tmp/lyx_tmpdir.CLmZrzV11492/Buffer_convertLyXFormatk11492.lyx is not a
> > readable LyX document.
> > matej@mitmanek: marketa$
> > 
> > Any ideas, what's wrong?
> > 
> > Best,
> > 
> > Matěj
> 
> The document language is English. But there are 4 entries in the document
> stating '\lang english'.
> 
> Removing this 4 lines, the document is readable.
> 
> OTOH, reading directly with lyx2.1, there is no problem.
> 
> For me it looks like lyx-deficiency.
> 
>   Kornel

I agree. A brief look into development/FORMAT does not give any clue about a 
file format that could be responsible for this change.

The next step is then to pinpoint what is the problem, is this a problem of 
lyx-2.1, of lyx2lyx or of the lyx-2.2 lexer?

If the problem is lyx-2.1 or lyx2lyx the change is simple we can add a last 
change in the lyx-2.1 converter that removes this instances: \lang that match 
the document language. The patch is easy enough but I would like to understand 
the disease before proposing a cure. ;-)

Regards,
-- 
José Abílio

Re: Crash in File-Open

[Enrico Forestieri]

On Mon, Mar 06, 2017 at 11:45:00AM -0500, Richard Heck wrote:
> On 03/06/2017 06:19 AM, Kornel Benko wrote:
> > Ping ...
> >
> > Am Donnerstag, 23. Februar 2017 um 13:52:41, schrieb Kornel Benko 
> > 
> >> OS: Linux =~ ubuntu 14.04, 64bit
> >>
> >> I gave a try to QT5.8. But now I am getting crashes any time I try to open 
> >> a file with File->Open.
> >> This does not happen with 'open recent' or if lyx is called with a file 
> >> parameter.
> >>
> >> The backtrace shows that the crash in call to dmg.exec() 
> >> src/frontends/qt4/FileDialog.cpp:161
> >>
> >> The enclosing routine, FileDialog::open(path, filters suggested)
> >>path = toqstr(".")
> >>filters = filter(qt_("LyX Documents (*.lyx)")
> >> so nothing special.
> >>
> >> If I try to use lyx compiled with QT5.7, so the crash is there too as long 
> >> as QT5.8 is selected by ldconfig.
> >> If I try to use lyx compiled with QT5.8 ans select QT5.7 with ldconfig, 
> >> lyx does not start because
> >> `Qt_5.8' is not found.
> >>
> >> Someone interested in backtrace?
> >>
> >> I try to compile with automake ...
> >> Compilation went smoothly.
> >> But I have the same effect. So at least it does not depend on build-system.
> >>
> > Looks like nobody seems to to be interested.
> > For me, the only workaround is to use USE_NATIVE_FILEDIALOG=1.
> > I don't like it because the native dialog is not so nice as that from LyX,
> > but at least the so compiled lyx is usable.
> >
> > Attached patch is for cmake build.
> >
> > The same change is needed here for branch2.2.
> 
> OK for stable.

I think that this needs some investigation. I cannot reproduce the
behavior on debian with Qt 5.8.

-- 
Enrico

Re: [LyX/master] Rewrite detection of MyThes library

[Jean-Marc Lasgouttes]

Le 06/03/2017 à 17:35, Kornel Benko a écrit :

Hm, cmake only uses included version. No problems so far.
How important is it to add the system-installed?


I do not think it makes a big difference. Linux packagers tend to 
require to use system libraries as far as possible, though.


Note that in the next commit, I have moved mythes to 3rdparty/. I did 
not do the cmake stuff, because I was 90% sure I would mess it up.


What I am trying to do with autoconf is: use the system lib by default 
and fallback to bundled one. When --with-included-* is used, then always 
use the bundled version. Only boost is different for now, because it is 
more comfortable for developers to use the bundled version (this is 
debatable, of course).


JMarc

Re: Crash in File-Open

[Richard Heck]

On 03/06/2017 06:19 AM, Kornel Benko wrote:
> Ping ...
>
> Am Donnerstag, 23. Februar 2017 um 13:52:41, schrieb Kornel Benko 
> 
>> OS: Linux =~ ubuntu 14.04, 64bit
>>
>> I gave a try to QT5.8. But now I am getting crashes any time I try to open a 
>> file with File->Open.
>> This does not happen with 'open recent' or if lyx is called with a file 
>> parameter.
>>
>> The backtrace shows that the crash in call to dmg.exec() 
>> src/frontends/qt4/FileDialog.cpp:161
>>
>> The enclosing routine, FileDialog::open(path, filters suggested)
>>  path = toqstr(".")
>>  filters = filter(qt_("LyX Documents (*.lyx)")
>> so nothing special.
>>
>> If I try to use lyx compiled with QT5.7, so the crash is there too as long 
>> as QT5.8 is selected by ldconfig.
>> If I try to use lyx compiled with QT5.8 ans select QT5.7 with ldconfig, lyx 
>> does not start because
>> `Qt_5.8' is not found.
>>
>> Someone interested in backtrace?
>>
>> I try to compile with automake ...
>> Compilation went smoothly.
>> But I have the same effect. So at least it does not depend on build-system.
>>
> Looks like nobody seems to to be interested.
> For me, the only workaround is to use USE_NATIVE_FILEDIALOG=1.
> I don't like it because the native dialog is not so nice as that from LyX,
> but at least the so compiled lyx is usable.
>
> Attached patch is for cmake build.
>
> The same change is needed here for branch2.2.

OK for stable.

rh

Re: [LyX/master] Rewrite detection of MyThes library

[Kornel Benko]

Am Montag, 6. März 2017 um 16:11:40, schrieb Jean-Marc Lasgouttes 

> commit 8cb021b32fffb92003da7cef9ef3cb711f5901eb
> Author: Jean-Marc Lasgouttes 
> Date:   Mon Mar 6 16:03:32 2017 +0100
> 
> Rewrite detection of MyThes library
> 
> Now configure searches in this order
> 1. system-installed library
> 2. code bundled with LyX
> 
> If --with-included-mythes or if no mythes library is installed, then
> the script selects the bundled version. There should be no cases
> leading to error message.

Hm, cmake only uses included version. No problems so far.
How important is it to add the system-installed?

Kornel

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

Re: Crash in File-Open

[Kornel Benko]

Ping ...

Am Donnerstag, 23. Februar 2017 um 13:52:41, schrieb Kornel Benko 

> OS: Linux =~ ubuntu 14.04, 64bit
>
> I gave a try to QT5.8. But now I am getting crashes any time I try to open a 
> file with File->Open.
> This does not happen with 'open recent' or if lyx is called with a file 
> parameter.
>
> The backtrace shows that the crash in call to dmg.exec() 
> src/frontends/qt4/FileDialog.cpp:161
>
> The enclosing routine, FileDialog::open(path, filters suggested)
>   path = toqstr(".")
>   filters = filter(qt_("LyX Documents (*.lyx)")
> so nothing special.
>
> If I try to use lyx compiled with QT5.7, so the crash is there too as long as 
> QT5.8 is selected by ldconfig.
> If I try to use lyx compiled with QT5.8 ans select QT5.7 with ldconfig, lyx 
> does not start because
> `Qt_5.8' is not found.
>
> Someone interested in backtrace?
>
> I try to compile with automake ...
> Compilation went smoothly.
> But I have the same effect. So at least it does not depend on build-system.
>

Looks like nobody seems to to be interested.
For me, the only workaround is to use USE_NATIVE_FILEDIALOG=1.
I don't like it because the native dialog is not so nice as that from LyX,
but at least the so compiled lyx is usable.

Attached patch is for cmake build.

The same change is needed here for branch2.2.

Korneldiff --git a/src/frontends/qt4/CMakeLists.txt b/src/frontends/qt4/CMakeLists.txt
index 833e92a..4a3331d 100644
--- a/src/frontends/qt4/CMakeLists.txt
+++ b/src/frontends/qt4/CMakeLists.txt
@@ -7,6 +7,9 @@
 project(frontend_qt)

 file(GLOB frontends_qt_sources ${TOP_SRC_DIR}/src/frontends/qt4/${LYX_CPP_FILES})
+if (QTVERSION VERSION_GREATER_EQUAL "5.8.0")
+  set_property(SOURCE "${TOP_SRC_DIR}/src/frontends/qt4/FileDialog.cpp" PROPERTY COMPILE_FLAGS -DUSE_NATIVE_FILEDIALOG=1)
+endif()
 file(GLOB moc_files ${TOP_SRC_DIR}/src/frontends/qt4/${LYX_MOC_FILES})

 list(REMOVE_ITEM frontends_qt_sources ${moc_files} .)


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