Re: [LyX/master] Cmake build: Check for QPA_XCB when QT_USES_X11 is known

[Scott Kostyshak]

On Sun, Jun 12, 2016 at 03:27:24PM +0200, Georg Baum wrote:
> Scott Kostyshak wrote:
> 
> > I tried xmingw-script on current master but it does not succeed for me.
> > 
> > I get the following:
> > 
> > error:
> > In file included from
> > 
> /home/scott/lyxbuilds/master/CMakeBuild/src/support/_allinone_const.C:118:0:
> > /home/scott/lyxbuilds/master/repo/src/support/convert.cpp:158:32: error:
> > specialization of ‘Target lyx::convert(Source) [with Target = int;
> > Source = s
> > td::__cxx11::basic_string]’ after instantiation
> >  int convert(string const s)
> 
> The compiler complains here that lyx::convert() was used 
> before the template was specialized. This does not look correct to me, since 
> the template specialization is correctly declared in the header. Either we 
> have a strange effect of the monolithic build (e.g. #define convert 
> somethingelse), or a compiler bug, or some new C++ standard does not allow 
> the way we declare the specializations anymore. I don't think the issue has 
> something to do with regex or other configuration stuff. Does it go away if 
> you switch off monolithic build?

Switching off monolithic, and doing a clean build, I get the following errors:

[  5%] Building CXX object src/insets/CMakeFiles/insets.dir/InsetFoot.cpp.obj
cd /home/scott/lyxbuilds/master_xmingw/CMakeBuild/src/insets && 
/usr/bin/i686-w64-mingw32-g++   -DHUNSPELL_STATIC -DQT_CORE_LIB -DQT_GUI_LIB 
-DQT_NO_D
EBUG -DWINVER=0x0500 @CMakeFiles/insets.dir/includes_CXX.rsp -Wall 
-Wunused-parameter --std=c++11 -fno-strict-aliasing  -Wall -Wunused-parameter 
--std
=c++11 -O2 -DNDEBUG   -DBOOST_USER_CONFIG="" -o 
CMakeFiles/insets.dir/InsetFoot.cpp.obj -c 
/home/scott/lyxbuilds/master_xmingw/repo/src/inse
ts/InsetFoot.cpp
In file included from 
/home/scott/lyxbuilds/master_xmingw/repo/src/graphics/PreviewLoader.cpp:892:0:
/home/scott/lyxbuilds/master_xmingw/repo/src/moc_PreviewLoader.cpp:13:2: error: 
#error "This file was generated using the moc from 4.8.7. It"
 #error "This file was generated using the moc from 4.8.7. It"
  ^
/home/scott/lyxbuilds/master_xmingw/repo/src/moc_PreviewLoader.cpp:14:2: error: 
#error "cannot be used with the include files from this version of Qt.
"
 #error "cannot be used with the include files from this version of Qt."
  ^
/home/scott/lyxbuilds/master_xmingw/repo/src/moc_PreviewLoader.cpp:15:2: error: 
#error "(The moc has changed too much.)"
 #error "(The moc has changed too much.)"
  ^
/home/scott/lyxbuilds/master_xmingw/repo/src/moc_PreviewLoader.cpp:56:7: error: 
‘QMetaObjectExtraData’ does not name a type
 const QMetaObjectExtraData 
lyx::graphics::PreviewLoader::staticMetaObjectExtraData = {
   ^
/home/scott/lyxbuilds/master_xmingw/repo/src/moc_PreviewLoader.cpp:62:51: 
error: ‘staticMetaObjectExtraData’ was not declared in this scope
   qt_meta_data_lyx__graphics__PreviewLoader,  }
   ^
/home/scott/lyxbuilds/master_xmingw/repo/src/moc_PreviewLoader.cpp: In member 
function ‘virtual const QMetaObject* lyx::graphics::PreviewLoader::metaO
bject() const’:
/home/scott/lyxbuilds/master_xmingw/repo/src/moc_PreviewLoader.cpp:71:71: 
error: conditional expression between distinct pointer types ‘QDynamicMetaOb
jectData*’ and ‘const QMetaObject*’ lacks a cast
 return QObject::d_ptr->metaObject ? QObject::d_ptr->metaObject : 

   ^
Scott


signature.asc
Description: PGP signature

Re: [LyX/master] Cmake build: Check for QPA_XCB when QT_USES_X11 is known

[Scott Kostyshak]

On Sun, Jun 12, 2016 at 10:15:53AM +0200, Kornel Benko wrote:
> Am Samstag, 11. Juni 2016 um 20:50:43, schrieb Scott Kostyshak 
> 
> > On Sat, Jun 11, 2016 at 07:30:55PM -0400, Scott Kostyshak wrote:
> > > On Sun, Jun 12, 2016 at 12:23:18AM +0200, Kornel Benko wrote:
> > > > Am Samstag, 11. Juni 2016 um 18:12:20, schrieb Scott Kostyshak 
> > > > 
> > > > > > Attached is the diff to my config.h
> > > > > > There are clearly differences.
> > > > > > For instance the dest directory has to be "LYX_INSTALLED", not 
> > > > > > "/usr/local/lyx-master".
> > > > > > I would check (with message(STATUS ...)) where this value is set.
> > > > > 
> > > > > Sorry, I think I sent the wrong config.h. Attached is the correct one.
> > > > > It seems to be like yours.
> > > > > 
> > > > > I get the same error as I reported above.
> > > > > 
> > > > > Any other ideas?
> > > > 
> > > > Yes, try to set
> > > > set(LYX_USE_STD_REGEX 0)
> > > > at CMakeLists.txt:268
> > > > 
> > > > Probably is the test for std::regex not good enough.
> > > 
> > > I changed it and I still get the same error. The change did seem to
> > > affect the REGEX setting correctly:
> > > $ diff config.h config_old.h
> > > 57c57
> > > < /* #undef LYX_USE_STD_REGEX */
> > > ---
> > > > #define LYX_USE_STD_REGEX 1
> > > 
> > > Scott
> > 
> > I get the same error with git ref 6e3a4ecf (from January) so I think the
> > issue could be with my version of mingw.
> > 
> > $ /usr/bin/i686-w64-mingw32-g++ --version
> > i686-w64-mingw32-g++ (GCC) 5.3.1 20160211
> > Copyright (C) 2015 Free Software Foundation, Inc.
> > This is free software; see the source for copying conditions.  There is NO
> > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> > $ 
> > 
> > Scott
> 
> Possibly. Version here is: i686-w64-mingw32-g++ (GCC) 4.8.2.
> 
> What is the value of CXX_STD_REGEX_DETECTED (in CMakeCache.txt)?

The following is listed:

//Test CXX_STD_REGEX_DETECTED
CXX_STD_REGEX_DETECTED:INTERNAL=

Scott


signature.asc
Description: PGP signature

Re: [LyX/2.2.x] * Math.lyx : add few maxima examples to ch. 23.1.

[Pavel Sanda]

Uwe Stöhr wrote:
>> commit 8a1578e40543edfa5a23b22058753298e58bdfbb
>> Author: Pavel Sanda 
>> Date:   Sat Jun 11 11:23:39 2016 -0700
>>
>> * Math.lyx : add few maxima examples to ch. 23.1.
>
> Pavel,
>
> please don't commit things to the branch doc files without discussion.

Sure, but I asked you about those changes long time ago and you never replied.

> In general, please use change tracking.
> Moreover, and also on general, it is important to keep all language 
> versions in sync. There is no reason that new info is not in e.g. the 
> Spanish version.
>
> Since I am currently in your country and cannot have a look, could you 
> please revert and/or recommit using change tracking?

That's easy, the responsibility of accepting those so they don't make it 
in CT mode to 2.2.1 is yours, I don't want to see this patch ever again ;)

Pavel

Re: compilation for coverity fails

[Guillaume Munch]

Le 12/06/2016 19:59, Jean-Marc Lasgouttes a écrit :

Le 12/06/2016 20:53, Richard Heck a écrit :

I don't think we have a definite policy, but it would be a good sort of
comment to have.

Coverity seems to want the comment right before the code it complains
about, though, so I'm not sure this can be done ahead of time.


We can also provide models to coverity, which are skeleton versions of
the functions we use in which some properties can be given.

Hmm, How vague is that? As you can tell, I am not sure how we can use
this feature.



At least for what I was thinking about, it seems that Coverity does not 
raise a false positive, so no special annotation needed.

Re: [LyX/2.2.x] * Math.lyx : add few maxima examples to ch. 23.1.

[Uwe Stöhr]

commit 8a1578e40543edfa5a23b22058753298e58bdfbb
Author: Pavel Sanda 
Date:   Sat Jun 11 11:23:39 2016 -0700

* Math.lyx : add few maxima examples to ch. 23.1.


Pavel,

please don't commit things to the branch doc files without discussion.
In general, please use change tracking.
Moreover, and also on general, it is important to keep all language 
versions in sync. There is no reason that new info is not in e.g. the 
Spanish version.


Since I am currently in your country and cannot have a look, could you 
please revert and/or recommit using change tracking?


thanks and regards
Uwe

Re: [LyX/2.2.x] Fix compilation with Qt < 4.7

[Guillaume Munch]

Le 12/06/2016 23:23, Richard Heck a écrit :

On 06/12/2016 06:13 PM, Guillaume Munch wrote:

commit e6d28aad0a6f267c5ce51c5205fdb60343a7fc90
Author: Guillaume Munch 
Date:   Sat Jun 11 05:41:48 2016 +0100

 Fix compilation with Qt < 4.7


Probably this should go to 2.2.x, as well.



You mean staging?

Guillaume

Re: [LyX/2.2.x] Fix compilation with Qt < 4.7

[Richard Heck]

On 06/12/2016 06:13 PM, Guillaume Munch wrote:
> commit e6d28aad0a6f267c5ce51c5205fdb60343a7fc90
> Author: Guillaume Munch 
> Date:   Sat Jun 11 05:41:48 2016 +0100
>
> Fix compilation with Qt < 4.7

Probably this should go to 2.2.x, as well.

Richard

Re: compilation for coverity fails

[Richard Heck]

On 06/12/2016 02:59 PM, Jean-Marc Lasgouttes wrote:
> Le 12/06/2016 20:53, Richard Heck a écrit :
>> I don't think we have a definite policy, but it would be a good sort of
>> comment to have.
>>
>> Coverity seems to want the comment right before the code it complains
>> about, though, so I'm not sure this can be done ahead of time.
>
> We can also provide models to coverity, which are skeleton versions of
> the functions we use in which some properties can be given.
>
> Hmm, How vague is that? As you can tell, I am not sure how we can use
> this feature.

I'm not sure how useful this is to us, but:
*https://scan.coverity.com/tune

Richard
*

Re: Why is the filesystemencoding needed for \origin lyx2lyx?

[Enrico Forestieri]

On Sun, Jun 12, 2016 at 07:21:48PM +0200, Georg Baum wrote:

> Hi Enrico,
> 
> you added an encoding conversion in lyx2lyx here:
> http://www.lyx.org/trac/changeset/a0afd345/lyxgit
> 
> Can you please explain why this is needed, but not on windows?

According to my recollection, because on windows document.dir is
already in unicode format.

-- 
Enrico

Re: [LyX/master] Make lyx2lyx infrastructure python3 ready

[Georg Baum]

Georg Baum wrote:

> commit 166420d02ccb073dc32ab5cd0bc466de54aa36bb
> Author: Georg Baum 
> Date:   Sun Jun 12 21:21:15 2016 +0200
> 
> Make lyx2lyx infrastructure python3 ready
> 
> The LyX class works now with python 3. Certain file format conversions
> may still fail (convert_multiencoding() is a hot candidate), but this
> will need to be fixed in the individual modules.

It turned out that even multiple encoding files work fine (see 
http://www.lyx.org/trac/attachment/ticket/9006/multiencoding_246.lyx), so we 
are now python3 ready.

In order to give this more testing I would propose the attached patch. OK?


Georgdiff --git a/src/support/os.cpp b/src/support/os.cpp
index b1537e3..8afb96c 100644
--- a/src/support/os.cpp
+++ b/src/support/os.cpp
@@ -38,14 +38,16 @@ namespace lyx {
 namespace support {
 namespace os {
 
-static string const python2(string const & binary, bool verbose = false)
+static string const python23(string const & binary, bool verbose = false)
 {
 	if (verbose)
 		lyxerr << "Examining " << binary << "\n";
 
-	// Check whether this is a python 2 binary.
+	// Check whether this is a python 2 or 3 binary.
 	cmd_ret const out = runCommand(binary + " -V 2>&1");
-	if (out.first < 0 || !prefixIs(out.second, "Python 2"))
+	if (out.first < 0 ||
+	(!prefixIs(out.second, "Python 2") &&
+	 !prefixIs(out.second, "Python 3")))
 		return string();
 
 	if (verbose)
@@ -64,9 +66,9 @@ string const python(bool reset)
 {
 	// FIXME THREAD
 	// Check whether the first python in PATH is the right one.
-	static string command = python2("python -tt");
+	static string command = python23("python -tt");
 	if (reset) {
-		command = python2("python -tt");
+		command = python23("python -tt");
 	}
 
 	if (command.empty()) {
@@ -85,13 +87,13 @@ string const python(bool reset)
 			for (int i = 0; i < list.size() && command.empty(); ++i) {
 string const binary = addName(localdir,
 	list.at(i).toLocal8Bit().constData());
-command = python2(binary, true);
+command = python23(binary, true);
 			}
 		}
 
 		// Default to "python" if no usable binary was found.
 		if (command.empty()) {
-			lyxerr << "Warning: No python v2.x binary found.\n";
+			lyxerr << "Warning: No python v2.x or 3.x binary found.\n";
 			command = "python";
 		}
 

Re: compilation for coverity fails

[Jean-Marc Lasgouttes]

Le 12/06/2016 20:53, Richard Heck a écrit :

I don't think we have a definite policy, but it would be a good sort of
comment to have.

Coverity seems to want the comment right before the code it complains
about, though, so I'm not sure this can be done ahead of time.


We can also provide models to coverity, which are skeleton versions of 
the functions we use in which some properties can be given.


Hmm, How vague is that? As you can tell, I am not sure how we can use 
this feature.


JMatc

Re: compilation for coverity fails

[Richard Heck]

On 06/12/2016 02:45 PM, Guillaume Munch wrote:
> Le 12/06/2016 19:39, Richard Heck a écrit :
>> On 06/12/2016 09:17 AM, Jean-Marc Lasgouttes wrote:
>>> Le 12/06/2016 15:05, Georg Baum a écrit :
 If others want to join the effort please keep in mind that the goal
 is not
 to get zero coverity errors, but to fix dangerous code. So if you
 do not
 understand an issue 100%, or understand it but do not know how to fix
 it,
 please keep it open. I did that for some of the errors reported by
 cppcheck,
 for example there is a NULL-pointer dereference at the end of
 copySelectionHelper() (which works in practice since it is only used
 to set
 a reference which is usually implemented as a pointer), but fixing
 this
 properly would be a big refactoring.
>>>
>>> Coverity allows to annotate false positives, which is a nice thing to
>>> do. At least we get to see that it is marked and may disagree.
>>
>> Yes, I marked quite a few of these. Coverity can't always tell, for
>> example, whether a pointer may be null. We may have our own reasons to
>> know it can't be if, say, we are in an LFUN that can only be issued when
>> we have a document view. But these are all worth checking, it seems to
>> me, and annotating, if only so that no-one else will have to check.
>>
>
> Interesting. What comment should I add to a function declaration to
> inform that a returned pointer cannot be null, by design?

I don't think we have a definite policy, but it would be a good sort of
comment to have.

Coverity seems to want the comment right before the code it complains
about, though, so I'm not sure this can be done ahead of time.

Richard

Re: compilation for coverity fails

[Guillaume Munch]

Le 12/06/2016 19:39, Richard Heck a écrit :

On 06/12/2016 09:17 AM, Jean-Marc Lasgouttes wrote:

Le 12/06/2016 15:05, Georg Baum a écrit :

If others want to join the effort please keep in mind that the goal
is not
to get zero coverity errors, but to fix dangerous code. So if you do not
understand an issue 100%, or understand it but do not know how to fix
it,
please keep it open. I did that for some of the errors reported by
cppcheck,
for example there is a NULL-pointer dereference at the end of
copySelectionHelper() (which works in practice since it is only used
to set
a reference which is usually implemented as a pointer), but fixing this
properly would be a big refactoring.


Coverity allows to annotate false positives, which is a nice thing to
do. At least we get to see that it is marked and may disagree.


Yes, I marked quite a few of these. Coverity can't always tell, for
example, whether a pointer may be null. We may have our own reasons to
know it can't be if, say, we are in an LFUN that can only be issued when
we have a document view. But these are all worth checking, it seems to
me, and annotating, if only so that no-one else will have to check.



Interesting. What comment should I add to a function declaration to
inform that a returned pointer cannot be null, by design?

Re: compilation for coverity fails

[Richard Heck]

On 06/12/2016 09:17 AM, Jean-Marc Lasgouttes wrote:
> Le 12/06/2016 15:05, Georg Baum a écrit :
>> If others want to join the effort please keep in mind that the goal
>> is not
>> to get zero coverity errors, but to fix dangerous code. So if you do not
>> understand an issue 100%, or understand it but do not know how to fix
>> it,
>> please keep it open. I did that for some of the errors reported by
>> cppcheck,
>> for example there is a NULL-pointer dereference at the end of
>> copySelectionHelper() (which works in practice since it is only used
>> to set
>> a reference which is usually implemented as a pointer), but fixing this
>> properly would be a big refactoring.
>
> Coverity allows to annotate false positives, which is a nice thing to
> do. At least we get to see that it is marked and may disagree.

Yes, I marked quite a few of these. Coverity can't always tell, for
example, whether a pointer may be null. We may have our own reasons to
know it can't be if, say, we are in an LFUN that can only be issued when
we have a document view. But these are all worth checking, it seems to
me, and annotating, if only so that no-one else will have to check.

Richard

Re: [LyX/master] Make the non-drawing cases faster in TextMetrics::drawParagraph

[Jean-Marc Lasgouttes]

Le 12/06/2016 19:05, Guillaume Munch a écrit :

In some situations, LyX does not recognize that an inset is hovered with
the mouse: does not change cursor icon, does not paint the label in a
different color, and does not show tooltip. Bisect leads to the commit
above. If you would like to have a reproducer I can make one (however
later).


I'd appreciate a way to reproduce indeed. I would not know where to start.

JMarc

Re: [LyX/master] unique_ptr and make_unique

[Kornel Benko]

Am Sonntag, 12. Juni 2016 um 18:35:56, schrieb Guillaume Munch 
> Le 12/06/2016 10:23, Kornel Benko a écrit :
> > Am Sonntag, 12. Juni 2016 um 10:25:30, schrieb Kornel Benko 
> >> Am Sonntag, 12. Juni 2016 um 03:25:38, schrieb Guillaume Munch 
> >> 
> >>> Le 09/06/2016 15:23, Guillaume Munch a écrit :
>  diff --git a/configure.ac b/configure.ac
>  index 3353df4..52da6ce 100644
>  --- a/configure.ac
>  +++ b/configure.ac
>  @@ -130,6 +130,9 @@ AC_C_BIGENDIAN
> # Nice to have when an assertion triggers
> LYX_CHECK_CALLSTACK_PRINTING
> 
>  +# C++14 only
>  +LYX_CHECK_DEF(make_unique, memory, [using std::make_unique;])
>  +
> # Needed for our char_type
> AC_CHECK_SIZEOF(wchar_t)
> 
> >>>
> >>> I looked quickly at CMakefile.txt but I could not guess how to update it
> >>> accordingly. This defines LYX_DEF_MAKE_UNIQUE when make_unique exists in
> >>> .
> >>
> >> I will try to create this macro for cmake.
> >>
> >>Kornel
> >
> > Something like attached seems to work
> >
> 
> Looks good, thanks Kornel.
> 

In that context I've seen also the creation of "HAVE_DEF_PATH_MAX" define. So I 
will add this one to cmake too. (It was missing)

Kornel

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

Re: [LyX/master] unique_ptr and make_unique

[Guillaume Munch]

Le 12/06/2016 10:23, Kornel Benko a écrit :

Am Sonntag, 12. Juni 2016 um 10:25:30, schrieb Kornel Benko 

Am Sonntag, 12. Juni 2016 um 03:25:38, schrieb Guillaume Munch 

Le 09/06/2016 15:23, Guillaume Munch a écrit :

diff --git a/configure.ac b/configure.ac
index 3353df4..52da6ce 100644
--- a/configure.ac
+++ b/configure.ac
@@ -130,6 +130,9 @@ AC_C_BIGENDIAN
   # Nice to have when an assertion triggers
   LYX_CHECK_CALLSTACK_PRINTING

+# C++14 only
+LYX_CHECK_DEF(make_unique, memory, [using std::make_unique;])
+
   # Needed for our char_type
   AC_CHECK_SIZEOF(wchar_t)



I looked quickly at CMakefile.txt but I could not guess how to update it
accordingly. This defines LYX_DEF_MAKE_UNIQUE when make_unique exists in
.


I will try to create this macro for cmake.

Kornel


Something like attached seems to work



Looks good, thanks Kornel.

Why is the filesystemencoding needed for \origin lyx2lyx?

[Georg Baum]

Hi Enrico,

you added an encoding conversion in lyx2lyx here: 
http://www.lyx.org/trac/changeset/a0afd345/lyxgit


Can you please explain why this is needed, but not on windows? I ask 
because this conversion does not work with python 3: All strings, also 
the ones returned by os.path, are unicode strings in python 3, so if any 
conversion is needed we have to do it when filling the different members 
of the LyX class.


Georg

Re: [LyX/master] Make the non-drawing cases faster in TextMetrics::drawParagraph

[Guillaume Munch]

Le 30/05/2016 13:56, Jean-Marc Lasgouttes a écrit :

commit fc73ebc16c4f0aca76360415a94eca57f283e44e
Author: Jean-Marc Lasgouttes 
Date:   Mon Feb 29 16:07:35 2016 +0100

 Make the non-drawing cases faster in TextMetrics::drawParagraph

 There are two main cases:
 * when drawing is disabled from the start, use a simplified code that only 
paints insets (in order to cache positions).
 * when the row is not visible, do the same.

 The goal of this optimization is to be able to always run a no-drawing 
draw after the metrics have been computed.




In some situations, LyX does not recognize that an inset is hovered with
the mouse: does not change cursor icon, does not paint the label in a
different color, and does not show tooltip. Bisect leads to the commit
above. If you would like to have a reproducer I can make one (however
later).

Guillaume

Re: [LyX/master] Cmake build: Check for QPA_XCB when QT_USES_X11 is known

[Georg Baum]

Scott Kostyshak wrote:

> I tried xmingw-script on current master but it does not succeed for me.
> 
> I get the following:
> 
> error:
> In file included from
> 
/home/scott/lyxbuilds/master/CMakeBuild/src/support/_allinone_const.C:118:0:
> /home/scott/lyxbuilds/master/repo/src/support/convert.cpp:158:32: error:
> specialization of ‘Target lyx::convert(Source) [with Target = int;
> Source = s
> td::__cxx11::basic_string]’ after instantiation
>  int convert(string const s)

The compiler complains here that lyx::convert() was used 
before the template was specialized. This does not look correct to me, since 
the template specialization is correctly declared in the header. Either we 
have a strange effect of the monolithic build (e.g. #define convert 
somethingelse), or a compiler bug, or some new C++ standard does not allow 
the way we declare the specializations anymore. I don't think the issue has 
something to do with regex or other configuration stuff. Does it go away if 
you switch off monolithic build?


Georg

Re: compilation for coverity fails

[Jean-Marc Lasgouttes]

Le 12/06/2016 15:05, Georg Baum a écrit :

If others want to join the effort please keep in mind that the goal is not
to get zero coverity errors, but to fix dangerous code. So if you do not
understand an issue 100%, or understand it but do not know how to fix it,
please keep it open. I did that for some of the errors reported by cppcheck,
for example there is a NULL-pointer dereference at the end of
copySelectionHelper() (which works in practice since it is only used to set
a reference which is usually implemented as a pointer), but fixing this
properly would be a big refactoring.


Coverity allows to annotate false positives, which is a nice thing to 
do. At least we get to see that it is marked and may disagree.


JMarc

Re: "Reconfigure" gives an error

[Georg Baum]

Andrew Parsloe wrote:

> What puzzled (& puzzles) me is that the warning doesn't arise with
> 2.1.4, nor when 2.2.0 is installed.

This is strange. If you want you could try out whether the error happens as 
well if you start platex.exe manually. If yes, then it is definitely a 
MikTeX problwem, if not, then there must be some interaction with LyX which 
I do not understand.


Georg

Re: [LyX/master] Add missing includes after change to boost signals2

[Georg Baum]

Jean-Marc Lasgouttes wrote:

> Le 12/06/2016 12:14, Stephan Witt a écrit :
>>> Different structure of headers, just switching between different gcc
>>> versions and their accompanied libs is enough to trigger such errors on
>>> the same system.
>>
>> I’m not used to this behavior with other development environment.

But I am. I have seen it when switching from one MSVC version to another, 
and with Intel compilers as well. My impression is that compiler vendors try 
to remove more and more of these unwanted dependencies from version to 
version. Especially gcc was known to pull in many unneeded includes, so it 
is good that they reduce them.

> For example, the docs say that the  header is required for
> std::count. However, on some sustems, it may happen that some other
> header does include  already, so that an explicit loading is
> not necessary.
> 
> This is a weakness of C-style headers IMO. They do not allow to specify
> these kind of things correctly.

Indeed.


Georg

Re: Errors in lib/lyx2lyx/LyX.py with python3

[Georg Baum]

Kornel Benko wrote:

> All tests with lyx2lyx fail with:
> -- Executing /usr/bin/python3 /usr2/src/lyx/lyx-git/lib/lyx2lyx/lyx2lyx -e
> qwbwf -o 8dqNDg /usr2/src/lyx/lyx-git/lib/doc/Math.lyx Traceback (most
> recent call last):
>   File "/usr2/src/lyx/lyx-git/lib/lyx2lyx/lyx2lyx", line 88, in 
> main()
>   File "/usr2/src/lyx/lyx-git/lib/lyx2lyx/lyx2lyx", line 81, in main
> doc = LyX.File(**options.__dict__)
>   File "/usr2/src/lyx/lyx-git/lib/lyx2lyx/LyX.py", line 749, in __init__
> self.read()
>   File "/usr2/src/lyx/lyx-git/lib/lyx2lyx/LyX.py", line 346, in read
> self.textclass = self.textclass.decode(self.encoding)
> AttributeError: 'str' object has no attribute 'decode'
> -- Error output of lyx2lyx = 1
> -- Created file empty
> CMake Error at
> /usr2/src/lyx/lyx-git/development/autotests/lyx2lyxtest.cmake:49
> (message):
>   lyx2lyx failed
> 
> 
> Changing back to python2.7, tests are passing.

This is expected. Up to now I submitted stuff found by 2to3, but it is not 
possible to detect all incompatibilities automatically. I have a prototype 
running with python3 locally, but this needs more thinking, testing and 
adaption to all 4 combinations of compressed/uncompressed files and using 
stdin or a file for reading (and the corresponding combinations for writing, 
but fortunately these are independent from reading).

After the encoding stuff has been fixed the infrastructure of lyx2lyx will 
be python3 ready, but it could still happen that some of the individual 
conversions do not work with python3, but this is very difficult to check.


Georg

Re: [LyX/master] Add missing includes after change to boost signals2

[Jean-Marc Lasgouttes]

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

Different structure of headers, just switching between different gcc versions
and their accompanied libs is enough to trigger such errors on the same system.


I’m not used to this behavior with other development environment.


For example, the docs say that the  header is required for 
std::count. However, on some sustems, it may happen that some other 
header does include  already, so that an explicit loading is 
not necessary.


This is a weakness of C-style headers IMO. They do not allow to specify 
these kind of things correctly.


JMarc

Re: [LyX/master] Add missing includes after change to boost signals2

[Stephan Witt]

Am 12.06.2016 um 10:39 schrieb Pavel Sanda :
> 
> Stephan Witt wrote:
>> sstream or iostream (as JMarc wrote) because of std::endl.
> 
> But where in the _header_ do you need that?

Ok, I misunderstood then.

It should go to Server.cpp of course.

Stephan

> 
>> I have to admit that I start to mistrust the GCC-compilers.
>> I don???t understand why our sources compile on some systems
>> and not on some other systems. Why do I need to add this
>> includes and on your system all is fine?
> 
> Different structure of headers, just switching between different gcc versions
> and their accompanied libs is enough to trigger such errors on the same 
> system.

I’m not used to this behavior with other development environment.

Stephan

Re: [LyX/master] unique_ptr and make_unique

[Kornel Benko]

Am Sonntag, 12. Juni 2016 um 10:25:30, schrieb Kornel Benko 
> Am Sonntag, 12. Juni 2016 um 03:25:38, schrieb Guillaume Munch 
> > Le 09/06/2016 15:23, Guillaume Munch a écrit :
> > > diff --git a/configure.ac b/configure.ac
> > > index 3353df4..52da6ce 100644
> > > --- a/configure.ac
> > > +++ b/configure.ac
> > > @@ -130,6 +130,9 @@ AC_C_BIGENDIAN
> > >   # Nice to have when an assertion triggers
> > >   LYX_CHECK_CALLSTACK_PRINTING
> > >
> > > +# C++14 only
> > > +LYX_CHECK_DEF(make_unique, memory, [using std::make_unique;])
> > > +
> > >   # Needed for our char_type
> > >   AC_CHECK_SIZEOF(wchar_t)
> > >
> >
> > I looked quickly at CMakefile.txt but I could not guess how to update it
> > accordingly. This defines LYX_DEF_MAKE_UNIQUE when make_unique exists in
> > .
>
> I will try to create this macro for cmake.
>
>   Kornel

Something like attached seems to work

Kornel



diff --git a/development/cmake/ConfigureChecks.cmake b/development/cmake/ConfigureChecks.cmake
index 2de915f..e7f8454 100644
--- a/development/cmake/ConfigureChecks.cmake
+++ b/development/cmake/ConfigureChecks.cmake
@@ -172,6 +172,16 @@ check_cxx_source_compiles(
 	"
 lyx_cv_prog_clang)

+check_cxx_source_compiles(
+  "
+  #include 
+  using std::make_unique;
+  int main() {
+return(0);
+  }
+  "
+HAVE_DEF_MAKE_UNIQUE)
+
 set(USE_LLVM_LIBCPP)
 set(STD_STRING_USES_COW)
 set(USE_GLIBCXX_CXX11_ABI)
@@ -230,4 +240,3 @@ elseif(LYX_USE_QT MATCHES "QT4")
 else()
   message(FATAL_ERROR "Check for QT_USES_X11: Not handled LYX_USE_QT (= ${LYX_USE_QT})")
 endif()
-
diff --git a/development/cmake/config.h.cmake b/development/cmake/config.h.cmake
index a032545..b0d6ab0e 100644
--- a/development/cmake/config.h.cmake
+++ b/development/cmake/config.h.cmake
@@ -86,6 +86,7 @@ ${Include_used_spellchecker}
 #define ENABLE_NLS 1
 #endif

+#cmakedefine HAVE_DEF_MAKE_UNIQUE 1

 #endif // config.h guard

diff --git a/development/cmake/modules/FindCXX11Compiler.cmake b/development/cmake/modules/FindCXX11Compiler.cmake
index 5d127cf..ddd4713 100644
--- a/development/cmake/modules/FindCXX11Compiler.cmake
+++ b/development/cmake/modules/FindCXX11Compiler.cmake
@@ -41,6 +41,7 @@ else()
 set(CXX11_FLAG_CANDIDATES "--std=gnu++11")
   else()
 set(CXX11_FLAG_CANDIDATES
+  "--std=c++14"
   "--std=c++11"
   "--std=gnu++11"
   "--std=gnu++0x"


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

Re: compilation for coverity fails

[Liviu Andronic]

On Thu, Jun 9, 2016 at 4:14 PM, Jean-Marc Lasgouttes  wrote:
> Le 09/06/2016 à 12:22, Liviu Andronic a écrit :
>>>
>>> Are you currently updating the analysis on coverity site?
>>>
>> Yes, uploading build now. Should be up within an hour or so.
>
>
> They are there indeed, thanks. There two new defects, but these are false
> positive. I have changed to code to avoid them.
>
> We are now down to 67 outstanding defects.
> https://scan.coverity.com/projects/4164
>
> Tere are many trivial defects (uninitialized members), and a few tricky ones
> (like loop that only does one iteration :).
>
> To work on it, ask Liviu about access.
>
Following JMarc's and Richard's furious hunting, we're now down to 22
outstanding defects, down from about 200 we had originally during the
first scan in 2015. At least as far as Coverity's checks go, we're
starting to look pretty --- though I understand there are a couple of
problematic cases left that require a close look at the code base.

Liviu


> JMarc

Re: [LyX/master] Add missing includes after change to boost signals2

[Pavel Sanda]

Stephan Witt wrote:
> sstream or iostream (as JMarc wrote) because of std::endl.

But where in the _header_ do you need that?

> I have to admit that I start to mistrust the GCC-compilers.
> I don???t understand why our sources compile on some systems
> and not on some other systems. Why do I need to add this
> includes and on your system all is fine?

Different structure of headers, just switching between different gcc versions
and their accompanied libs is enough to trigger such errors on the same system.

Pavel

Re: [PATCH] unique_ptr and some clean-up

[Pavel Sanda]

Guillaume Munch wrote:
>>> I do not clearly see the situation wrt gcc 4.6. Which are the
>>> distributions that currently lack gcc > 4.6 ?
>>
>> this is ubuntu 12.04.p
>>
>
> I see. I has assumed g++-4.7 was there since there is gcc-4.7. How does 
> clang fare?

it has gcc 4.6.3. clang is not and won't be installed. p

Re: [LyX/master] unique_ptr and make_unique

[Kornel Benko]

Am Sonntag, 12. Juni 2016 um 03:25:38, schrieb Guillaume Munch 
> Le 09/06/2016 15:23, Guillaume Munch a écrit :
> > diff --git a/configure.ac b/configure.ac
> > index 3353df4..52da6ce 100644
> > --- a/configure.ac
> > +++ b/configure.ac
> > @@ -130,6 +130,9 @@ AC_C_BIGENDIAN
> >   # Nice to have when an assertion triggers
> >   LYX_CHECK_CALLSTACK_PRINTING
> >
> > +# C++14 only
> > +LYX_CHECK_DEF(make_unique, memory, [using std::make_unique;])
> > +
> >   # Needed for our char_type
> >   AC_CHECK_SIZEOF(wchar_t)
> >
> 
> I looked quickly at CMakefile.txt but I could not guess how to update it
> accordingly. This defines LYX_DEF_MAKE_UNIQUE when make_unique exists in 
> .

I will try to create this macro for cmake.

Kornel

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

Re: [LyX/master] Cmake build: Check for QPA_XCB when QT_USES_X11 is known

[Kornel Benko]

Am Samstag, 11. Juni 2016 um 20:50:43, schrieb Scott Kostyshak 

> On Sat, Jun 11, 2016 at 07:30:55PM -0400, Scott Kostyshak wrote:
> > On Sun, Jun 12, 2016 at 12:23:18AM +0200, Kornel Benko wrote:
> > > Am Samstag, 11. Juni 2016 um 18:12:20, schrieb Scott Kostyshak 
> > > 
> > > > > Attached is the diff to my config.h
> > > > > There are clearly differences.
> > > > > For instance the dest directory has to be "LYX_INSTALLED", not 
> > > > > "/usr/local/lyx-master".
> > > > > I would check (with message(STATUS ...)) where this value is set.
> > > > 
> > > > Sorry, I think I sent the wrong config.h. Attached is the correct one.
> > > > It seems to be like yours.
> > > > 
> > > > I get the same error as I reported above.
> > > > 
> > > > Any other ideas?
> > > 
> > > Yes, try to set
> > >   set(LYX_USE_STD_REGEX 0)
> > > at CMakeLists.txt:268
> > > 
> > > Probably is the test for std::regex not good enough.
> > 
> > I changed it and I still get the same error. The change did seem to
> > affect the REGEX setting correctly:
> > $ diff config.h config_old.h
> > 57c57
> > < /* #undef LYX_USE_STD_REGEX */
> > ---
> > > #define LYX_USE_STD_REGEX 1
> > 
> > Scott
> 
> I get the same error with git ref 6e3a4ecf (from January) so I think the
> issue could be with my version of mingw.
> 
> $ /usr/bin/i686-w64-mingw32-g++ --version
> i686-w64-mingw32-g++ (GCC) 5.3.1 20160211
> Copyright (C) 2015 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> $ 
> 
> Scott

Possibly. Version here is: i686-w64-mingw32-g++ (GCC) 4.8.2.

What is the value of CXX_STD_REGEX_DETECTED (in CMakeCache.txt)?

Kornel


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

Re: "Reconfigure" gives an error

[CarLaTeX]

2016-06-12 9:41 GMT+02:00 Andrew Parsloe :

> On 11/06/2016 8:53 p.m., Georg Baum wrote:
>
>> Andrew Parsloe wrote:
>>
>> On 11/06/2016 5:32 p.m., CarLaTeX wrote:
>>>
 Hi LyX developers,

 I've installed LyX 2.2.0 on Windows 10 (distribution for LaTeX: MiKTeX
 2.9).
 When I use "Tools > Reconfigure" I get this error:
 Immagine incorporata 2
 I try to translate in English: "platex.exe - Impossible to find an
 entry point ... omissis ... of the process in the dynamic link
 library C:\Program Files\MikTeX 2.9\miktex\bin\x64\platex.exe".

 LyX 2.1.4. doesn't show this error.

 Attached you find the configure.log of the both versions.

 Ciao!
 Carla

 P.S. = I don't write in Japanese.

>>> The LyX configuration script does not know that:-) It checks for many
>> converters and adds them to the configuration. Fortunately the message box
>> is only annyoing, it is correctly detected that platex is not usable, and
>> the rest of the configuration looks fine from the log.
>>
>> I get this warning too and have for the last month or so -- most
>>> reconfigures, but not all. I find if I click OK, the message vanishes
>>> and reconfigure proceeds successfully. The warning appeared after a
>>> flurry of MiKTeX updates.
>>>
>> This warning means a broken miktex installation. Please report that to
>> miktex, if it installs platex.exe then it should also install the needed
>> dependencies (most likely a dll is missing).
>>
>>
>> Georg
>>
>> What puzzled (& puzzles) me is that the warning doesn't arise with 2.1.4,
> nor when 2.2.0 is installed.
>
> Andrew
>
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
>
>

I've run a MikTeX update meanwhile.

The exact sequence of what i've done is:
- install LyX 2.2.0
(after some days)
- run MiKTeX update
- reconfigure LyX 2.2.0

Re: "Reconfigure" gives an error

[Andrew Parsloe]

On 11/06/2016 8:53 p.m., Georg Baum wrote:

Andrew Parsloe wrote:


On 11/06/2016 5:32 p.m., CarLaTeX wrote:

Hi LyX developers,

I've installed LyX 2.2.0 on Windows 10 (distribution for LaTeX: MiKTeX
2.9).
When I use "Tools > Reconfigure" I get this error:
Immagine incorporata 2
I try to translate in English: "platex.exe - Impossible to find an
entry point ... omissis ... of the process in the dynamic link
library C:\Program Files\MikTeX 2.9\miktex\bin\x64\platex.exe".

LyX 2.1.4. doesn't show this error.

Attached you find the configure.log of the both versions.

Ciao!
Carla

P.S. = I don't write in Japanese.

The LyX configuration script does not know that:-) It checks for many
converters and adds them to the configuration. Fortunately the message box
is only annyoing, it is correctly detected that platex is not usable, and
the rest of the configuration looks fine from the log.


I get this warning too and have for the last month or so -- most
reconfigures, but not all. I find if I click OK, the message vanishes
and reconfigure proceeds successfully. The warning appeared after a
flurry of MiKTeX updates.

This warning means a broken miktex installation. Please report that to
miktex, if it installs platex.exe then it should also install the needed
dependencies (most likely a dll is missing).


Georg

What puzzled (& puzzles) me is that the warning doesn't arise with 
2.1.4, nor when 2.2.0 is installed.


Andrew

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