Re: make lyxdist fails: No rule to make target 'Change.h'

[Scott Kostyshak]

On Tue, Jun 14, 2016 at 01:37:37AM +0100, Guillaume Munch wrote:
> Le 14/06/2016 01:25, Scott Kostyshak a écrit :
> > On Mon, Jun 13, 2016 at 08:17:27PM -0400, Scott Kostyshak wrote:
> > > On Tue, Jun 14, 2016 at 12:22:21AM +0100, Guillaume Munch wrote:
> > > > Le 14/06/2016 00:12, Scott Kostyshak a écrit :
> > > > > To reproduce, on a clean repo do the following:
> > > > > 
> > > > > ./autogen.sh && ./configure && make lyxdist
> > > > > 
> > > > > I get:
> > > > > 
> > > > > $ ./autogen.sh && ./configure && make lyxdist
> > > > > make[3]: Entering directory 
> > > > > '/home/scott/lyxbuilds/master/repo/src/support'
> > > > > make[3]: *** No rule to make target 'Change.h', needed by 'distdir'.  
> > > > > Stop.
> > > > > make[3]: Leaving directory 
> > > > > '/home/scott/lyxbuilds/master/repo/src/support'
> > > > > Makefile:3124: recipe for target 'distdir' failed
> > > > > make[2]: *** [distdir] Error 1
> > > > > make[2]: Leaving directory '/home/scott/lyxbuilds/master/repo/src'
> > > > > Makefile:658: recipe for target 'distdir' failed
> > > > > make[1]: *** [distdir] Error 1
> > > > > make[1]: Leaving directory '/home/scott/lyxbuilds/master/repo'
> > > > > Makefile:756: recipe for target 'dist' failed
> > > > > make: *** [dist] Error 2
> > > > > $
> > > > > 
> > > > 
> > > > Thanks, fixed.
> > > 
> > > Works well after fix.
> > 
> > I spoke too soon. I no longer get that error, but now I get:
> > 
> > No rule to make target 'foreach.h', needed by 'distdir'.  Stop.
> > 
> 
> Sorry, I should know that by now. It's fixed now and I hope the
> turbulences are behind us.
> 
> 

Works well. Thanks for the quick fixes.

Scott


signature.asc
Description: PGP signature

Re: make lyxdist fails: No rule to make target 'Change.h'

[Guillaume Munch]

Le 14/06/2016 01:25, Scott Kostyshak a écrit :

On Mon, Jun 13, 2016 at 08:17:27PM -0400, Scott Kostyshak wrote:

On Tue, Jun 14, 2016 at 12:22:21AM +0100, Guillaume Munch wrote:

Le 14/06/2016 00:12, Scott Kostyshak a écrit :

To reproduce, on a clean repo do the following:

./autogen.sh && ./configure && make lyxdist

I get:

$ ./autogen.sh && ./configure && make lyxdist
make[3]: Entering directory '/home/scott/lyxbuilds/master/repo/src/support'
make[3]: *** No rule to make target 'Change.h', needed by 'distdir'.  Stop.
make[3]: Leaving directory '/home/scott/lyxbuilds/master/repo/src/support'
Makefile:3124: recipe for target 'distdir' failed
make[2]: *** [distdir] Error 1
make[2]: Leaving directory '/home/scott/lyxbuilds/master/repo/src'
Makefile:658: recipe for target 'distdir' failed
make[1]: *** [distdir] Error 1
make[1]: Leaving directory '/home/scott/lyxbuilds/master/repo'
Makefile:756: recipe for target 'dist' failed
make: *** [dist] Error 2
$



Thanks, fixed.


Works well after fix.


I spoke too soon. I no longer get that error, but now I get:

No rule to make target 'foreach.h', needed by 'distdir'.  Stop.



Sorry, I should know that by now. It's fixed now and I hope the
turbulences are behind us.

Re: make lyxdist fails: No rule to make target 'Change.h'

[Scott Kostyshak]

On Mon, Jun 13, 2016 at 08:17:27PM -0400, Scott Kostyshak wrote:
> On Tue, Jun 14, 2016 at 12:22:21AM +0100, Guillaume Munch wrote:
> > Le 14/06/2016 00:12, Scott Kostyshak a écrit :
> > > To reproduce, on a clean repo do the following:
> > > 
> > > ./autogen.sh && ./configure && make lyxdist
> > > 
> > > I get:
> > > 
> > > $ ./autogen.sh && ./configure && make lyxdist
> > > make[3]: Entering directory 
> > > '/home/scott/lyxbuilds/master/repo/src/support'
> > > make[3]: *** No rule to make target 'Change.h', needed by 'distdir'.  
> > > Stop.
> > > make[3]: Leaving directory '/home/scott/lyxbuilds/master/repo/src/support'
> > > Makefile:3124: recipe for target 'distdir' failed
> > > make[2]: *** [distdir] Error 1
> > > make[2]: Leaving directory '/home/scott/lyxbuilds/master/repo/src'
> > > Makefile:658: recipe for target 'distdir' failed
> > > make[1]: *** [distdir] Error 1
> > > make[1]: Leaving directory '/home/scott/lyxbuilds/master/repo'
> > > Makefile:756: recipe for target 'dist' failed
> > > make: *** [dist] Error 2
> > > $
> > > 
> > 
> > Thanks, fixed.
> 
> Works well after fix.

I spoke too soon. I no longer get that error, but now I get:

No rule to make target 'foreach.h', needed by 'distdir'.  Stop.

Scott


signature.asc
Description: PGP signature

Re: make lyxdist fails: No rule to make target 'Change.h'

[Scott Kostyshak]

On Tue, Jun 14, 2016 at 12:22:21AM +0100, Guillaume Munch wrote:
> Le 14/06/2016 00:12, Scott Kostyshak a écrit :
> > To reproduce, on a clean repo do the following:
> > 
> > ./autogen.sh && ./configure && make lyxdist
> > 
> > I get:
> > 
> > $ ./autogen.sh && ./configure && make lyxdist
> > make[3]: Entering directory '/home/scott/lyxbuilds/master/repo/src/support'
> > make[3]: *** No rule to make target 'Change.h', needed by 'distdir'.  Stop.
> > make[3]: Leaving directory '/home/scott/lyxbuilds/master/repo/src/support'
> > Makefile:3124: recipe for target 'distdir' failed
> > make[2]: *** [distdir] Error 1
> > make[2]: Leaving directory '/home/scott/lyxbuilds/master/repo/src'
> > Makefile:658: recipe for target 'distdir' failed
> > make[1]: *** [distdir] Error 1
> > make[1]: Leaving directory '/home/scott/lyxbuilds/master/repo'
> > Makefile:756: recipe for target 'dist' failed
> > make: *** [dist] Error 2
> > $
> > 
> 
> Thanks, fixed.

Works well after fix.

Scott


signature.asc
Description: PGP signature

Re: make lyxdist fails: No rule to make target 'Change.h'

[Guillaume Munch]

Le 14/06/2016 00:12, Scott Kostyshak a écrit :

To reproduce, on a clean repo do the following:

./autogen.sh && ./configure && make lyxdist

I get:

$ ./autogen.sh && ./configure && make lyxdist
make[3]: Entering directory '/home/scott/lyxbuilds/master/repo/src/support'
make[3]: *** No rule to make target 'Change.h', needed by 'distdir'.  Stop.
make[3]: Leaving directory '/home/scott/lyxbuilds/master/repo/src/support'
Makefile:3124: recipe for target 'distdir' failed
make[2]: *** [distdir] Error 1
make[2]: Leaving directory '/home/scott/lyxbuilds/master/repo/src'
Makefile:658: recipe for target 'distdir' failed
make[1]: *** [distdir] Error 1
make[1]: Leaving directory '/home/scott/lyxbuilds/master/repo'
Makefile:756: recipe for target 'dist' failed
make: *** [dist] Error 2
$



Thanks, fixed.

make lyxdist fails: No rule to make target 'Change.h'

[Scott Kostyshak]

To reproduce, on a clean repo do the following:

./autogen.sh && ./configure && make lyxdist

I get:

$ ./autogen.sh && ./configure && make lyxdist
make[3]: Entering directory '/home/scott/lyxbuilds/master/repo/src/support'
make[3]: *** No rule to make target 'Change.h', needed by 'distdir'.  Stop.
make[3]: Leaving directory '/home/scott/lyxbuilds/master/repo/src/support'
Makefile:3124: recipe for target 'distdir' failed
make[2]: *** [distdir] Error 1
make[2]: Leaving directory '/home/scott/lyxbuilds/master/repo/src'
Makefile:658: recipe for target 'distdir' failed
make[1]: *** [distdir] Error 1
make[1]: Leaving directory '/home/scott/lyxbuilds/master/repo'
Makefile:756: recipe for target 'dist' failed
make: *** [dist] Error 2
$ 

Scott


signature.asc
Description: PGP signature

Re: One official build system?

[Scott Kostyshak]

On Wed, Jun 08, 2016 at 07:29:34PM -0700, Pavel Sanda wrote:
> Scott Kostyshak wrote:
> > By the way, I saw your comment just above the definition of the lyxdist
> > target, which you introduced in 2010 (d407a15c):
> > 
> > 
> > #Wait some time for bumping automake 1.11, which can use dist-xz
> > #directly without this code, which is to be removed.
> > #xz has low compression by default, but can be affected via
> > #export XZ_OPT=-9ev put somewhere in the makefile.
> > lyxdist: dist
> > bunzip2 $(PACKAGE)-$(VERSION).tar.bz2
> > xz -9 $(PACKAGE)-$(VERSION).tar
> > ls -hl $(PACKAGE)-$(VERSION).tar.*
> > 
> > 
> > Should we use dist-xz directly now?
> 
> That would make sense provided -9 level can be maintained.
> I don't have time for the patch though.

OK. I'm not planning to look at this now. Maybe we should come back to
it once we make a decision on whether to move to CMake or not.

Scott


signature.asc
Description: PGP signature

Re: One official build system?

[Scott Kostyshak]

On Sat, Jun 04, 2016 at 09:48:28PM +0200, Kornel Benko wrote:
> Am Samstag, 4. Juni 2016 um 15:36:37, schrieb Scott Kostyshak 
> 
> > On Fri, Jun 03, 2016 at 03:40:59PM -0700, Pavel Sanda wrote:
> > > Scott Kostyshak wrote:
> > > > I'm still not sure what the implications of moving to CMake as our
> > > > official build system are (I should have made this more clear in my
> > > 
> > > To start with: If you make tarball with autotools and cmake is there
> > > difference between those two, do we get the same files/and their contets?
> > 
> > Good question. I don't know. There is no 'lyxdist' target for CMake and
> > no 'dist' target so I stopped there.
> 
>   # make package_source
>   --> LyX-2.3.tar.xz
> or
>   # make git_archive
>   --> LyX-2.3.0-47674git-Linux.tgz

Thanks. There are many differences compared to the .tar from autotools.
I can list the difference if you want, but since there are so many it
might be easier for you to take a look yourself.

You can make the tar with autotools as follows:
./autogen.sh && ./configure && make lyxdist

I did the comparison with a git checkout of 2.2.0, partly because make
lyxdist does not work for me now (I'll send a separate email about
this).

Note also that for me make package_source produces a tar.gz, not a
tar.xz as you suggested above. I don't think this difference is
important but I mention it in case it signals a fundamental difference
between our systems that explains why I get such a different tar from
the autotools tar.

Scott

> 
> > By the way, I saw your comment just above the definition of the lyxdist
> > target, which you introduced in 2010 (d407a15c):
> > 
> > 
> > #Wait some time for bumping automake 1.11, which can use dist-xz
> > #directly without this code, which is to be removed.
> > #xz has low compression by default, but can be affected via
> > #export XZ_OPT=-9ev put somewhere in the makefile.
> > lyxdist: dist
> > bunzip2 $(PACKAGE)-$(VERSION).tar.bz2
> > xz -9 $(PACKAGE)-$(VERSION).tar
> > ls -hl $(PACKAGE)-$(VERSION).tar.*
> > 
> > 
> > Should we use dist-xz directly now?
> > 
> > Scott
> 
>   Kornel




signature.asc
Description: PGP signature

Re: [PATCH] unique_ptr and some clean-up

[Guillaume Munch]

Le 13/06/2016 21:54, Pavel Sanda a écrit :

Guillaume Munch wrote:

Starting from 2.3, LyX will require a C++11 compiler, and g++ 4.6 fails
(it seems) at a feature as elementary as generating a default move
constructor, even when told so explicitly (which we cannot really blame
it for, given that it does not claim C++11 compliance in the first
place). Moreover, the only distribution release that is currently stuck
with g++ 4.6 is (to my knowledge) Ubuntu 12.04LTS, which will no longer
be around by the time 2.3 ships (unless a miracle happens), and which
offers another compiler more respectful of C++11. On the other hand,
what reasons do we have for supporting g++ 4.6?

If you really need a temporary workaround until you get to migrate your
work environment, (and you do not want to/can use clang,) you could keep
a local series of fixes. I imagine that for your current sort of problem
(as far as I understand, because I do not have access to g++ 4.6 to test
my theory), you just need manual definitions of move constructors and
assignment operators. For e87febd0 in particular, however, it is easier,
because it should be safe to just revert it locally, given that this is
an isolated change.


Thanks for summarizing.
I can confirm that reverting e87febd0 makes master compilable again with 4.6.

I am not in charge for the machines around me and given 12.04 LTS ends up
2017-04 I don't expect any migration happening soon :)

So I guess the bad news is I can't quickly bisect what's going on 32 cores
anymore, the good news is I'll get more real work done :)



Thank you Pavel for your understanding. I hope the inconvenience is
temporary.

So is there a consensus that g++ 4.8 is a reasonable minimum version to
support?

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

[Scott Kostyshak]

On Mon, Jun 13, 2016 at 11:09:18AM +0200, Kornel Benko wrote:
> Am Montag, 13. Juni 2016 um 01:57:30, schrieb 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 : 
> > 
> 
> Did you have the correct 'moc' in PATH while compiling?
> E.g. probably /home/scott/lyx-dependencies/Qt-5.5.1-i686-w64-mingw32/bin

The lyx-dependencies directory is actually
here:
/home/scott/lyxbuilds/master/lyx-dependencies
Thanks to your comment, I realized that when I copy the master directory
to e.g. master-mingw, the lyx-dependencies folder came with the copy. I
removed that directory, and then removed the monolithic build option,
and now it works for me.

With the monolithic build option, it still fails for me.

Does that give us a clue for how to fix the build for me with the
monolithic build option? Note that the monolithic build works fine for
me when building normally (with both autotools and CMake)

I would like to add mingw to the list of compilations that I test on a
regular basis so that we know quickly if it starts failing.

Scott


signature.asc
Description: PGP signature

Re: [PATCH] unique_ptr and some clean-up

[Guillaume Munch]

Le 13/06/2016 21:40, Stephan Witt a écrit :

gcc-Version 4.4.7 20120313 (Red Hat 4.4.7-17) (GCC)

IMO it’s not dead and end of life is 2020-11-30



I do not know what can be done at the LyX level for CentOS 6. It seems
that it is very easy to obtain gcc 4.8 on CentOS 6 provided one has
access to 3rd party repositories (e.g.
https://www.softwarecollections.org/en/scls/rhscl/devtoolset-3/); on the
other hand if the user is stuck for institutional reasons, then they
appear to be hopeless getting a C++11 compiler.

Re: [PATCH] unique_ptr and some clean-up

[Pavel Sanda]

Stephan Witt wrote:
> IMO it?s not dead and end of life is 2020-11-30

CentOs/Redhat has extremely long LTS (e.g. clusters around here
still have gcc 4.4). On the other hand no one sane would
use it for GUI development, it's more for server/clusters
deployment. So we shouldn't really strive to support it.

Whether it makes sense to support Ubuntu 12.04 I am not sure,
if I am the only one using it, might not be worth effort given
how little I contribute these days anyway.

Pavel

Re: [PATCH] unique_ptr and some clean-up

[Pavel Sanda]

Guillaume Munch wrote:
> Starting from 2.3, LyX will require a C++11 compiler, and g++ 4.6 fails
> (it seems) at a feature as elementary as generating a default move
> constructor, even when told so explicitly (which we cannot really blame
> it for, given that it does not claim C++11 compliance in the first
> place). Moreover, the only distribution release that is currently stuck
> with g++ 4.6 is (to my knowledge) Ubuntu 12.04LTS, which will no longer
> be around by the time 2.3 ships (unless a miracle happens), and which
> offers another compiler more respectful of C++11. On the other hand,
> what reasons do we have for supporting g++ 4.6?
>
> If you really need a temporary workaround until you get to migrate your
> work environment, (and you do not want to/can use clang,) you could keep
> a local series of fixes. I imagine that for your current sort of problem
> (as far as I understand, because I do not have access to g++ 4.6 to test
> my theory), you just need manual definitions of move constructors and
> assignment operators. For e87febd0 in particular, however, it is easier,
> because it should be safe to just revert it locally, given that this is
> an isolated change.

Thanks for summarizing.
I can confirm that reverting e87febd0 makes master compilable again with 4.6.

I am not in charge for the machines around me and given 12.04 LTS ends up
2017-04 I don't expect any migration happening soon :)

So I guess the bad news is I can't quickly bisect what's going on 32 cores
anymore, the good news is I'll get more real work done :)

Pavel

Re: [PATCH] unique_ptr and some clean-up

[Stephan Witt]

Am 13.06.2016 um 22:26 schrieb Guillaume Munch :
> 
> Le 13/06/2016 20:50, Pavel Sanda a écrit :
>> Guillaume Munch wrote:
>>> Then if we are dropping g++ 4.6, does anyone know whether it makes
>>> sense
>> 
>> Sorry I might got lost somewhere in the threads around. What reasons
>> do we have for dropping gcc 4.6?
>> 
> 
> Starting from 2.3, LyX will require a C++11 compiler, and g++ 4.6 fails
> (it seems) at a feature as elementary as generating a default move
> constructor, even when told so explicitly (which we cannot really blame
> it for, given that it does not claim C++11 compliance in the first
> place). Moreover, the only distribution release that is currently stuck
> with g++ 4.6 is (to my knowledge) Ubuntu 12.04LTS, which will no longer
> be around by the time 2.3 ships (unless a miracle happens), and which
> offers another compiler more respectful of C++11. On the other hand,
> what reasons do we have for supporting g++ 4.6?

This is CentOS 6.8:

$ cc -v
Es werden eingebaute Spezifikationen verwendet.
Ziel: x86_64-redhat-linux
Konfiguriert mit: ../configure --prefix=/usr --mandir=/usr/share/man 
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla 
--enable-bootstrap --enable-shared --enable-threads=posix 
--enable-checking=release --with-system-zlib --enable-__cxa_atexit 
--disable-libunwind-exceptions --enable-gnu-unique-object 
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk 
--disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre 
--enable-libgcj-multifile --enable-java-maintainer-mode 
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib 
--with-ppl --with-cloog --with-tune=generic --with-arch_32=i686 
--build=x86_64-redhat-linux
Thread-Modell: posix
gcc-Version 4.4.7 20120313 (Red Hat 4.4.7-17) (GCC) 

IMO it’s not dead and end of life is 2020-11-30

Stephan

> 
> If you really need a temporary workaround until you get to migrate your
> work environment, (and you do not want to/can use clang,) you could keep
> a local series of fixes. I imagine that for your current sort of problem
> (as far as I understand, because I do not have access to g++ 4.6 to test
> my theory), you just need manual definitions of move constructors and
> assignment operators. For e87febd0 in particular, however, it is easier,
> because it should be safe to just revert it locally, given that this is
> an isolated change.
> 
> 
> Guillaume
> 

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

[Enrico Forestieri]

On Mon, Jun 13, 2016 at 09:38:07PM +0200, Georg Baum wrote:
> Enrico Forestieri wrote:
> 
> > 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.
> 
> Thanks for the explanation. That means that my workaround for python3 is not 
> worse than the previous situation.
> 
> Unfortunately I fear that we have to adjust the encoding nevertheless:
> http://www.lyx.org/trac/ticket/10218
> http://www.lyx.org/trac/ticket/10220

I cannot reproduce both issues. Or, better, I can reproduce only if the
cygwin version of python comes first in the PATH. So, maybe it is due
to the fact that a wrong python is used for the conversion.

-- 
Enrico

Re: [PATCH] unique_ptr and some clean-up

[Guillaume Munch]

Le 13/06/2016 20:50, Pavel Sanda a écrit :

Guillaume Munch wrote:

Then if we are dropping g++ 4.6, does anyone know whether it makes
sense


Sorry I might got lost somewhere in the threads around. What reasons
do we have for dropping gcc 4.6?



Starting from 2.3, LyX will require a C++11 compiler, and g++ 4.6 fails
(it seems) at a feature as elementary as generating a default move
constructor, even when told so explicitly (which we cannot really blame
it for, given that it does not claim C++11 compliance in the first
place). Moreover, the only distribution release that is currently stuck
with g++ 4.6 is (to my knowledge) Ubuntu 12.04LTS, which will no longer
be around by the time 2.3 ships (unless a miracle happens), and which
offers another compiler more respectful of C++11. On the other hand,
what reasons do we have for supporting g++ 4.6?

If you really need a temporary workaround until you get to migrate your
work environment, (and you do not want to/can use clang,) you could keep
a local series of fixes. I imagine that for your current sort of problem
(as far as I understand, because I do not have access to g++ 4.6 to test
my theory), you just need manual definitions of move constructors and
assignment operators. For e87febd0 in particular, however, it is easier,
because it should be safe to just revert it locally, given that this is
an isolated change.


Guillaume

Re: [PATCH] unique_ptr and some clean-up

[Pavel Sanda]

Guillaume Munch wrote:
> Then if we are dropping g++ 4.6, does anyone know whether it makes sense

Sorry I might got lost somewhere in the threads around.
What reasons do we have for dropping gcc 4.6?

Pavel

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

[Georg Baum]

Enrico Forestieri wrote:

> 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.

Thanks for the explanation. That means that my workaround for python3 is not 
worse than the previous situation.

Unfortunately I fear that we have to adjust the encoding nevertheless:
http://www.lyx.org/trac/ticket/10218
http://www.lyx.org/trac/ticket/10220


Georg

Re: [PATCH] unique_ptr and some clean-up

[Guillaume Munch]

Le 13/06/2016 12:53, Jean-Marc Lasgouttes a écrit :

Le 13/06/2016 à 10:14, Guillaume Munch a écrit :

Le 12/06/2016 09:29, Pavel Sanda a écrit :

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



It is still good to know whether clang compiles. If you do not
want/can try, let's see if Jean-Marc succeeds with it (as he
offered to try in another message).


I have clang 3.3 on my ubuntu 12.04 machine and it compiles
perfectly, although there are lots of annoying warnings. I have
added to autoconf the possibility to detect clang version, and I use
that to adapt warnings.




Thanks for the test Jean-Marc. This is good news.

Then if we are dropping g++ 4.6, does anyone know whether it makes sense
to keep g++ 4.7? I have not found any long-term support release of a
distribution (Ubuntu, RHEL, CentOS) that had 4.7 but not 4.8.

Re: [PATCH] unique_ptr and some clean-up

[Jean-Marc Lasgouttes]

Le 13/06/2016 à 18:01, Kornel Benko a écrit :


I don't understand, why _my_ clang 3.6 accepts parameter '-std=c++14'.


I am not sure that I understand your question.


Here example (without source file)
gcc4.8
# g++ -std=c++14
g++: error: unrecognized command line option ‘-std=c++14’
g++: fatal error: no input files
compilation terminated.


try -std=c++1y


So, clang accepts this parameter, but does not define std::make_unique.


No, because it is the standard library that shall define make_unique. If 
you use a gcc 4.8 libstdc++ library, you won't have it, since it came 
with gcc 4.9:

https://isocpp.org/blog/2014/04/gcc-4.9.0

JMarc

Re: [PATCH] unique_ptr and some clean-up

[Kornel Benko]

Am Montag, 13. Juni 2016 um 17:49:07, schrieb Jean-Marc Lasgouttes 

> Le 13/06/2016 à 17:34, Kornel Benko a écrit :
> >> The posting you refer to seems to imply that it is a C++14 problem. What
> >> about enforcing C++11 mode instead?
> >
> > Hm, yes. But if we want to support 'std::make_unique' we need C++14 test.
> > At least, that was my impression while working with 4.8 and 5.3.1 g++ 
> > versions.
> >
> > I tried to enforce c++11, everything compiled. Apparently you are right.
> 
> At least we have a usable test for whether we can turn on c++14 mode. 
> Does it work with gcc 4.8? It might be that clang can only do c++14 when 
> using its own libc++.
> 
> > I don't understand, why _my_ clang 3.6 accepts parameter '-std=c++14'.
> 
> I am not sure that I understand your question.

Here example (without source file)
gcc4.8
# g++ -std=c++14
g++: error: unrecognized command line option ‘-std=c++14’
g++: fatal error: no input files
compilation terminated.
gcc 5.3.1
# /usr/local/gcc5.3/bin/g++ -std=c++14
g++: fatal error: no input files
compilation terminated.
clang 3.6
# /usr/lib/llvm-3.6/bin/clang++  -std=c++14
clang: error: no input files

> JMarc

So, clang accepts this parameter, but does not define std::make_unique.

Kornel

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

Re: [PATCH] unique_ptr and some clean-up

[Jean-Marc Lasgouttes]

Le 13/06/2016 à 17:34, Kornel Benko a écrit :

The posting you refer to seems to imply that it is a C++14 problem. What
about enforcing C++11 mode instead?


Hm, yes. But if we want to support 'std::make_unique' we need C++14 test.
At least, that was my impression while working with 4.8 and 5.3.1 g++ versions.

I tried to enforce c++11, everything compiled. Apparently you are right.


At least we have a usable test for whether we can turn on c++14 mode. 
Does it work with gcc 4.8? It might be that clang can only do c++14 when 
using its own libc++.



I don't understand, why _my_ clang 3.6 accepts parameter '-std=c++14'.


I am not sure that I understand your question.

JMarc

Re: [PATCH] unique_ptr and some clean-up

[Kornel Benko]

Am Montag, 13. Juni 2016 um 16:22:56, schrieb Jean-Marc Lasgouttes 

> Le 13/06/2016 à 14:11, Kornel Benko a écrit :
> > I had no problems with clang 3.3. But using clang 3.6 with installed libs 
> > from gcc4.8
> > has problems while compiling cstdio.
> > According to page 
> > http://stackoverflow.com/questions/17775390/clang-3-3-in-c1y-mode-cannot-parse-cstdio-header
> > this snipped solved it for me
> > #if !_ISOC11_SOURCE
> > using ::gets;
> > #endif
> > at line 120 of file /usr/include/c++/4.8/cstdio
> >
> > I doubt we can do anything about that in lyx-sources.
> 
> The posting you refer to seems to imply that it is a C++14 problem. What 
> about enforcing C++11 mode instead?
> 
> JMarc

Hm, yes. But if we want to support 'std::make_unique' we need C++14 test.
At least, that was my impression while working with 4.8 and 5.3.1 g++ versions.

I tried to enforce c++11, everything compiled. Apparently you are right.

I don't understand, why _my_ clang 3.6 accepts parameter '-std=c++14'.

Kornel



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

LyX 2.1.5 Tarballs

[Richard Heck]

The tarballs for the release of LyX 2.1.5 can be found here:
ftp://ftp.lyx.org/pub/lyx/devel/lyx-2.1/2.1.5/
Please prepare binaries.

I will be at a conference all week. I'll have email access, of course,
but I won't be at the right IP address for uploading files to
ftp.lyx.org. So I will plan to do the actual release next weekend.

Richard

Re: [PATCH] unique_ptr and some clean-up

[Jean-Marc Lasgouttes]

Le 13/06/2016 à 16:50, Stephan Witt a écrit :

Am 13.06.2016 um 16:25 schrieb Jean-Marc Lasgouttes :


Le 13/06/2016 à 14:27, Stephan Witt a écrit :

Stephan, I'd be interested to know what clang version is returned by the Apple 
version. I hope it does not return the XCode version.


Why not?

checking whether the compiler is clang... yes
checking for clang version... 7.3.0


Because I'd like to know what warnings exist for a given version. I do explicit 
testing for version <=3.3, it will not catch the Apple case. I am not sure why 
they want to be so creative about it. Is there a way to get the underlying clang 
version?



IMHO not, because of:
http://clang-developers.42468.n3.nabble.com/FYI-Version-number-change-td922629.html


And the numbering used by apple is just some monotonic random process:
https://gist.github.com/yamaya/2924292

Sigh. How do we know that a given clang version is the apple one? Just 
to know, I do not need this information yet.


It might be that we have to add explicit tests for supported warning 
classes.


JMarc

Re: [PATCH] unique_ptr and some clean-up

[Stephan Witt]

Am 13.06.2016 um 16:25 schrieb Jean-Marc Lasgouttes :
> 
> Le 13/06/2016 à 14:27, Stephan Witt a écrit :
>>> Stephan, I'd be interested to know what clang version is returned by the 
>>> Apple version. I hope it does not return the XCode version.
>> 
>> Why not?
>> 
>> checking whether the compiler is clang... yes
>> checking for clang version... 7.3.0
> 
> Because I'd like to know what warnings exist for a given version. I do 
> explicit testing for version <=3.3, it will not catch the Apple case. I am 
> not sure why they want to be so creative about it. Is there a way to get the 
> underlying clang version?
> 

IMHO not, because of:
http://clang-developers.42468.n3.nabble.com/FYI-Version-number-change-td922629.html

$ clang -v
Apple LLVM version 7.3.0 (clang-703.0.29)
Target: x86_64-apple-darwin15.5.0
Thread model: posix
InstalledDir: 
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

Stephan

Re: [PATCH] unique_ptr and some clean-up

[Jean-Marc Lasgouttes]

Le 13/06/2016 à 14:27, Stephan Witt a écrit :

Stephan, I'd be interested to know what clang version is returned by the Apple 
version. I hope it does not return the XCode version.


Why not?

checking whether the compiler is clang... yes
checking for clang version... 7.3.0


Because I'd like to know what warnings exist for a given version. I do 
explicit testing for version <=3.3, it will not catch the Apple case. I 
am not sure why they want to be so creative about it. Is there a way to 
get the underlying clang version?


JMarc

Re: [PATCH] unique_ptr and some clean-up

[Jean-Marc Lasgouttes]

Le 13/06/2016 à 14:11, Kornel Benko a écrit :

I had no problems with clang 3.3. But using clang 3.6 with installed libs from 
gcc4.8
has problems while compiling cstdio.
According to page 
http://stackoverflow.com/questions/17775390/clang-3-3-in-c1y-mode-cannot-parse-cstdio-header
this snipped solved it for me
#if !_ISOC11_SOURCE
using ::gets;
#endif
at line 120 of file /usr/include/c++/4.8/cstdio

I doubt we can do anything about that in lyx-sources.


The posting you refer to seems to imply that it is a C++14 problem. What 
about enforcing C++11 mode instead?


JMarc

Re: [PATCH] unique_ptr and some clean-up

[Stephan Witt]

Am 13.06.2016 um 13:53 schrieb Jean-Marc Lasgouttes :
> 
> Le 13/06/2016 à 10:14, Guillaume Munch a écrit :
>> Le 12/06/2016 09:29, Pavel Sanda a écrit :
>>> 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
>>> 
>> 
>> It is still good to know whether clang compiles. If you do not want/can
>> try, let's see if Jean-Marc succeeds with it (as he offered to try in
>> another message).
> 
> I have clang 3.3 on my ubuntu 12.04 machine and it compiles perfectly, 
> although there are lots of annoying warnings. I have added to autoconf the 
> possibility to detect clang version, and I use that to adapt warnings.
> 
> Stephan, I'd be interested to know what clang version is returned by the 
> Apple version. I hope it does not return the XCode version.

Why not?

checking whether the compiler is clang... yes
checking for clang version... 7.3.0

Stephan

Re: [PATCH] unique_ptr and some clean-up

[Kornel Benko]

Am Montag, 13. Juni 2016 um 13:53:43, schrieb Jean-Marc Lasgouttes 

> Le 13/06/2016 à 10:14, Guillaume Munch a écrit :
> > Le 12/06/2016 09:29, Pavel Sanda a écrit :
> >> 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
> >>
> >
> > It is still good to know whether clang compiles. If you do not want/can
> > try, let's see if Jean-Marc succeeds with it (as he offered to try in
> > another message).
> 
> I have clang 3.3 on my ubuntu 12.04 machine and it compiles perfectly, 
> although there are lots of annoying warnings. I have added to autoconf 
> the possibility to detect clang version, and I use that to adapt warnings.
> 
> Stephan, I'd be interested to know what clang version is returned by the 
> Apple version. I hope it does not return the XCode version.
> 
> JMarc

I had no problems with clang 3.3. But using clang 3.6 with installed libs from 
gcc4.8
has problems while compiling cstdio.
According to page 
http://stackoverflow.com/questions/17775390/clang-3-3-in-c1y-mode-cannot-parse-cstdio-header
this snipped solved it for me
#if !_ISOC11_SOURCE
using ::gets;
#endif
at line 120 of file /usr/include/c++/4.8/cstdio

I doubt we can do anything about that in lyx-sources.

Kornel

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

Re: [PATCH] unique_ptr and some clean-up

[Jean-Marc Lasgouttes]

Le 13/06/2016 à 10:14, Guillaume Munch a écrit :

Le 12/06/2016 09:29, Pavel Sanda a écrit :

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



It is still good to know whether clang compiles. If you do not want/can
try, let's see if Jean-Marc succeeds with it (as he offered to try in
another message).


I have clang 3.3 on my ubuntu 12.04 machine and it compiles perfectly, 
although there are lots of annoying warnings. I have added to autoconf 
the possibility to detect clang version, and I use that to adapt warnings.


Stephan, I'd be interested to know what clang version is returned by the 
Apple version. I hope it does not return the XCode version.


JMarc

Re: Shorcut clashing Menu vs dialog in Qt5.6

[Kornel Benko]

Am Montag, 13. Juni 2016 um 10:11:04, schrieb Jean-Pierre Chrétien 

> Le 11/06/2016 22:27, Kornel Benko a écrit :
> > Am Samstag, 11. Juni 2016 um 22:08:41, schrieb Jean-Pierre Chrétien 
> > 
> 
> >> But does this mean that shortcuts will be different between Qt5 and Qt4, 
> >> unless
> >> LyX 2.3 comes with Qt5 only ?
> >
> > No, the shortcuts do not depend on QT. Only the interpretation is.
> > But you mean probably mean: between
> > lyx2.2 with QT4 (old shortcuts)
> > and
> > lyx2.3 with QT5 (new shortcuts)
> > ?
> 
> I run lyx-2.2.0 with Qt4, but it is published also with Qt5 (e.g. for 
> Windows).
> So it seems to me that I should compile 2.2.x against Qt5 to test shortcuts 
> conflicts and forget about Qt4.
> 

Yes please.

Kornel

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

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

[Uwe Stöhr]

  Original Message  
From: Pavel Sanda
Sent: Montag, 13. Juni 2016 04:01

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

I apologize. In such cases, please resend an email directly to me. Sometimes 
the amount of Lyx messages is too large so that some slip through‎

> 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 ;)

Every info is welcome! I only have the duty to keep all languages un sync and 
to check the compilability. With change tracking I am always perfectly informed 
( and our translators too, sometimes they are faster in having a look than me).

Regards Uwe

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

[Kornel Benko]

Am Montag, 13. Juni 2016 um 01:57:30, schrieb 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 : 
> 

Did you have the correct 'moc' in PATH while compiling?
E.g. probably /home/scott/lyx-dependencies/Qt-5.5.1-i686-w64-mingw32/bin
^
> Scott

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 Montag, 13. Juni 2016 um 01:55:28, schrieb 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 
> > > > > 

...

> > 
> > 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=

Thanks. I sort of expected this already, same as here.

> Scott

Kornel

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

Re: Annoying terminal messages: QXcbClipboard: SelectionRequest too old

[Enrico Forestieri]

On Mon, Jun 13, 2016 at 02:06:34AM -0400, Scott Kostyshak wrote:

> On Tue, Jun 07, 2016 at 03:48:18PM -0400, Scott Kostyshak wrote:
> > On Tue, Jun 07, 2016 at 04:20:49PM +0200, Kornel Benko wrote:
> > > Am Sonntag, 5. Juni 2016 um 21:28:06, schrieb Scott Kostyshak 
> > > 
> > > > Does anyone else often get these annoying messages when running LyX from
> > > > a terminal?
> > > > 
> > > > QXcbClipboard: SelectionRequest too old
> > > > 
> > > > I've been getting them for a while. I wonder if it is something
> > > > particular to my system (e.g. because of the clipboard manager I use,
> > > > CopyQ).
> > > > 
> > > > Scott
> > > 
> > > How do you trigger this output?
> > 
> > I cannot find a reproducible way to trigger it. I have not looked at it
> > in detail actually. When it does appear, it often comes in bunches. I
> > first wanted to check to see if others see it. It sounds like I am the
> > only one, which makes me suspect it is indeed my clipboard manager.
> 
> To reproduce with CopyQ running:
> start LyX, start a new document, type "abc" then press shift+left to
> highlight "c". Upon release of shift, the messages come.
> 
> If I remove the code
> 
> #ifdef QPA_XCB
>// Enable reception of XCB events.
>installNativeEventFilter(this);
> #endif
> 
> in GuiApplication.cpp, I no longer get the messages.
> The event filter was introduced at 52fee355.
> 
> Enrico or Jürgen, do you have any idea?

Sorry, but I have no idea.

-- 
Enrico

Re: [PATCH] unique_ptr and some clean-up

[Guillaume Munch]

Le 12/06/2016 09:29, Pavel Sanda a écrit :

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



It is still good to know whether clang compiles. If you do not want/can 
try, let's see if Jean-Marc succeeds with it (as he offered to try in 
another message).

Re: Shorcut clashing Menu vs dialog in Qt5.6

[Jean-Pierre Chrétien]

Le 11/06/2016 22:27, Kornel Benko a écrit :

Am Samstag, 11. Juni 2016 um 22:08:41, schrieb Jean-Pierre Chrétien 




But does this mean that shortcuts will be different between Qt5 and Qt4, unless
LyX 2.3 comes with Qt5 only ?


No, the shortcuts do not depend on QT. Only the interpretation is.
But you mean probably mean: between
lyx2.2 with QT4 (old shortcuts)
and
lyx2.3 with QT5 (new shortcuts)
?


I run lyx-2.2.0 with Qt4, but it is published also with Qt5 (e.g. for Windows).
So it seems to me that I should compile 2.2.x against Qt5 to test shortcuts 
conflicts and forget about Qt4.


--
Jean-Pierre

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

[Jean-Pierre Chrétien]

Le 13/06/2016 00:06, Uwe Stöhr a écrit :


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.


Uwe, if the changes are inserted via change tracking so I can found them easily, 
I can take care of the transfer to French doc files when I see commits to the 
English docs, that will relax a bit your task. But in that case change tracking 
acceptation shiould wait for that transfer to be done.


I can test with Pavel's improvement to Math.lyx if you want.

--
Jean-Pierre

Re: Annoying terminal messages: QXcbClipboard: SelectionRequest too old

[Scott Kostyshak]

On Tue, Jun 07, 2016 at 03:48:18PM -0400, Scott Kostyshak wrote:
> On Tue, Jun 07, 2016 at 04:20:49PM +0200, Kornel Benko wrote:
> > Am Sonntag, 5. Juni 2016 um 21:28:06, schrieb Scott Kostyshak 
> > 
> > > Does anyone else often get these annoying messages when running LyX from
> > > a terminal?
> > > 
> > > QXcbClipboard: SelectionRequest too old
> > > 
> > > I've been getting them for a while. I wonder if it is something
> > > particular to my system (e.g. because of the clipboard manager I use,
> > > CopyQ).
> > > 
> > > Scott
> > 
> > How do you trigger this output?
> 
> I cannot find a reproducible way to trigger it. I have not looked at it
> in detail actually. When it does appear, it often comes in bunches. I
> first wanted to check to see if others see it. It sounds like I am the
> only one, which makes me suspect it is indeed my clipboard manager.

To reproduce with CopyQ running:
start LyX, start a new document, type "abc" then press shift+left to
highlight "c". Upon release of shift, the messages come.

If I remove the code

#ifdef QPA_XCB
   // Enable reception of XCB events.
   installNativeEventFilter(this);
#endif

in GuiApplication.cpp, I no longer get the messages.
The event filter was introduced at 52fee355.

Enrico or Jürgen, do you have any idea?

Scott


signature.asc
Description: PGP signature