Re: changer

[Guillaume Munch]

Le 07/06/2016 15:05, Jean-Marc Lasgouttes a écrit :

Le 07/06/2016 à 09:04, Jean-Marc Lasgouttes a écrit :

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

12. This is a new helper class that I wrote because the Changer class
from MetricsInfo was too cumbersome (essentially a TeX \def with
shadowing). This commit entirely replaces the latter with a better
alternative. While I am not sure that the Changer mechanism itself is
the best practice, this is the best solution in the context it is used,
given the current architecture of painting (I have found uses outside of
painting as well too). Since this is used in all the metrics and
painting mechanism, comments are kindly requested before committing.


I would not pretend that I understand everything here, but having a
general Changer system is something I have been wanting to do for some
time. I think this is OK.


Now that I tried to compile, I can see clang complain:

My old clang 3.0 dies as follow, and clang 3.7 does approximately the same.

JMarc


Try changing 'return rc;' to 'return std::move(rc);' (twice).

I believe clang is right and gcc is wrong. gcc treats rc as an rvalue,
which makes the conversion into unique_ptr valid. But rc
should not be considered as an rvalue, because the standard only allows
the case when the return type matches the type of the expression (up
to cv-qualifiers).

You can test the following code:

  #include 
  struct D {};
  struct C {
C(D &&) { std::cout << "Wrong!\n"; }
C(D const &) { std::cout << "Correct!\n"; }
  };
  C f() { D x = D(); return x; }
  int main (int, char **) { C x = f(); return 0; }

gcc 5.3.1 gives "Wrong!" whereas clang 3.8 gives "Correct!".


(There's even worse. The following program:

  #include 
  struct D {
int i;
D(int i) : i(i) {};
  };
  struct C {
int i;
C(D && x) : i(x.i)  { std::cout << "Wrong!\n"; }
C(D x) : i(x.i) { std::cout << "Correct!\n"; }
  };
  C f() {
D x = D(14814);
return x;
std::cout << "What am I doing here?? ";
  }
  int main (int, char **)
  {
C x = f();
std::cout << x.i;
return 0;
  }

gives me: "What am I doing here?? 6295648")

Thanks for the tests.

Re: [LyX/2.2.x] Fix some problems with the preamble in th eKoma-script letter template.

[Richard Heck]

On 06/07/2016 04:38 PM, Georg Baum wrote:
> Richard Heck wrote:
>
>> diff --git a/lib/templates/koma-letter2.lyx
>> b/lib/templates/koma-letter2.lyx index 43cbdb0..7251ff3 100644
>> --- a/lib/templates/koma-letter2.lyx
>> +++ b/lib/templates/koma-letter2.lyx
>> @@ -1,5 +1,5 @@
>>  #LyX 2.2 created this file. For more info see http://www.lyx.org/
>> -\lyxformat 508
>> +\lyxformat 509
>>  \begin_document
>>  \begin_header
>>  \save_transient_properties true
> This does not look correct for 2.2.x

Right. Forgot: Don't cherry pick updates to docs.

rh

Re: [LyX/master] Require a C++11 compiler

[Scott Kostyshak]

On Tue, Jun 07, 2016 at 10:01:04PM +0200, Jean-Marc Lasgouttes wrote:
> Le 07/06/16 à 21:45, Scott Kostyshak a écrit :
> > On Tue, Jun 07, 2016 at 08:34:59PM +0200, Georg Baum wrote:
> > > commit 273c67d8aa34a724ca03e01ae8e1792949c23297
> > > Author: Georg Baum 
> > > Date:   Tue Jun 7 20:33:06 2016 +0200
> > > 
> > > Require a C++11 compiler
> > > 
> > > As discussed on the list. If no C++11 compiler is found configuration 
> > > stops
> > > with an error. There are now unneeded parts of boost, the will be 
> > > removed in
> > > a second commit.
> > 
> > How should we mention this in RELEASE-NOTES? Just "Building LyX now
> > requires a C++11 compiler" or should we add more details?
> 
> Rather in the INSTALL file.

Ah yes that is more important. I'm still wondering if it should go in
RELEASE-NOTES as well. In our ANNOUNCE we recommend that packagers read
the RELEASE-NOTES file. Don't we want packagers to be aware of this
significant change? Or do we just assume they'll read INSTALL or figure
it out if they get an error with an older compile?

Scott


signature.asc
Description: PGP signature

Re: [LyX/2.2.x] Fix some problems with the preamble in th eKoma-script letter template.

[Georg Baum]

Richard Heck wrote:

> diff --git a/lib/templates/koma-letter2.lyx
> b/lib/templates/koma-letter2.lyx index 43cbdb0..7251ff3 100644
> --- a/lib/templates/koma-letter2.lyx
> +++ b/lib/templates/koma-letter2.lyx
> @@ -1,5 +1,5 @@
>  #LyX 2.2 created this file. For more info see http://www.lyx.org/
> -\lyxformat 508
> +\lyxformat 509
>  \begin_document
>  \begin_header
>  \save_transient_properties true

This does not look correct for 2.2.x


Georg

Re: [LyX/master] Remove unneeded files from extract.sh

[Georg Baum]

Jean-Marc Lasgouttes wrote:

> Sure, but we have 4.3M in typeof/, which is only required because the
> bcopy decided that we needed the whole  directory bbecause we use the
> whole function directory.

I removed it. If we know that it is not needed it is one line in 
extract.sh:-)

> Actually, it seems that all we need is boost/function[0-9]*.hpp, but
> bcopy is not able to parse the following code in
> signals/signal_template.hpp:
> 
> #define BOOST_SIGNAL_FUNCTION_N_HEADER
> BOOST_JOIN()

and the stuff in detail (function[0-9]*.hpp are dummies including it). This 
is not too much. Actually we should get rid of signals, but it is not 
trivial: http://www.lyx.org/trac/ticket/9943

> mpl/ is the other 5.4M of code, but I am not sure that we can get rid of
> it.

It seems to be used at several places.

> (I write that down before I forget).

Thanks, this helps (I never did that analysis).


Georg

Re: [LyX/master] Require a C++11 compiler

[Jean-Marc Lasgouttes]

Le 07/06/16 à 21:45, Scott Kostyshak a écrit :

On Tue, Jun 07, 2016 at 08:34:59PM +0200, Georg Baum wrote:

commit 273c67d8aa34a724ca03e01ae8e1792949c23297
Author: Georg Baum 
Date:   Tue Jun 7 20:33:06 2016 +0200

Require a C++11 compiler

As discussed on the list. If no C++11 compiler is found configuration stops
with an error. There are now unneeded parts of boost, the will be removed in
a second commit.


How should we mention this in RELEASE-NOTES? Just "Building LyX now
requires a C++11 compiler" or should we add more details?


Rather in the INSTALL file.

JMarc

Re: Annoying terminal messages: QXcbClipboard: SelectionRequest too old

[Scott Kostyshak]

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.

Scott


signature.asc
Description: PGP signature

Re: [LyX/master] Require a C++11 compiler

[Scott Kostyshak]

On Tue, Jun 07, 2016 at 08:34:59PM +0200, Georg Baum wrote:
> commit 273c67d8aa34a724ca03e01ae8e1792949c23297
> Author: Georg Baum 
> Date:   Tue Jun 7 20:33:06 2016 +0200
> 
> Require a C++11 compiler
> 
> As discussed on the list. If no C++11 compiler is found configuration 
> stops
> with an error. There are now unneeded parts of boost, the will be removed 
> in
> a second commit.

How should we mention this in RELEASE-NOTES? Just "Building LyX now
requires a C++11 compiler" or should we add more details?

Scott


signature.asc
Description: PGP signature

Re: boost:regex & gcc

[Jean-Marc Lasgouttes]

Le 07/06/16 à 21:19, Georg Baum a écrit :

Pavel Sanda wrote:


Guillaume Munch wrote:

Any reason to want to get rid of boost completely?


Well, that's a long term wish. It is not nice to pack boost lib together
with our sources and someone need to care updating boost within the source
tree.


Updating is simple. It took me half an hour including testing, and if I did
not recieve a phone call in the middle it would have been ten minutes less.


I can confirm that when I removed other boost dependencies a few weeks 
ago, it was super easy.


But it is not nice to ship 18Mb of boost when our own source is only 11Mb.

JMarc

Re: [LyX/master] Remove unneeded files from extract.sh

[Jean-Marc Lasgouttes]

Le 07/06/16 à 21:16, Georg Baum a écrit :

commit bdbe81be15b78d3edd658f9ce94fdf34ff825aea
Author: Georg Baum 
Date:   Tue Jun 7 21:10:19 2016 +0200

Remove unneeded files from extract.sh

We do require less files from boost now.


Sure, but we have 4.3M in typeof/, which is only required because the 
bcopy decided that we needed the whole  directory bbecause we use the 
whole function directory.


Actually, it seems that all we need is boost/function[0-9]*.hpp, but 
bcopy is not able to parse the following code in 
signals/signal_template.hpp:


#define BOOST_SIGNAL_FUNCTION_N_HEADER 
BOOST_JOIN()


mpl/ is the other 5.4M of code, but I am not sure that we can get rid of it.

(I write that down before I forget).

JMarc

Re: boost:regex & gcc

[Georg Baum]

Pavel Sanda wrote:

> Guillaume Munch wrote:
>> Any reason to want to get rid of boost completely?
> 
> Well, that's a long term wish. It is not nice to pack boost lib together
> with our sources and someone need to care updating boost within the source
> tree.

Updating is simple. It took me half an hour including testing, and if I did 
not recieve a phone call in the middle it would have been ten minutes less.

But of course it is a good thing in general to have not too many thirdparty 
dependencies.


Georg

Re: [PATCH] unique_ptr and some clean-up

[Georg Baum]

Jean-Marc Lasgouttes wrote:

> Le 06/06/2016 22:26, Georg Baum a écrit :
> 
> Why do you remove the code that checks for C++11? At some time my idea
> was to do
> 
> for arg in "" "-std c++11" "-std c++0x" ; do
>if $CXX $arg is a C++11 compiler then
>  break
> done
> if $CXX $arg is not C++11
>ERROR(C++11 compiler not found)

Probably because I do not speak autotools language as well as I pretend;-) I 
somehow missed that this was an actual check. I committed an improved 
version which left this check intact and does now give an error message if 
no C++11 compiler is found.


Georg

compilation for coverity fails

[Liviu Andronic]

Dear all,
I am trying to build LyX for analysis by coverity but compilation fails.
(Normal compilation completes fine.)

geek@liv-inspiron:~/Build/Devel/lyx$ cov-build --dir cov-int make -j 3
Coverity Build Capture (64-bit) version 7.6.0 on Linux 3.13.0-24-generic
x86_64
Internal version numbers: 9b77a50df0 p-harmony-push-21098.563

[...]

CXX mathed/MathSupport.o
CXX insets/ExternalSupport.o
CXX insets/ExternalTransforms.o
CXX insets/RenderButton.o
CXX insets/Inset.o
CXX insets/InsetArgument.o
CXX insets/InsetBibtex.o
CXX insets/InsetBox.o
CXX insets/InsetBranch.o
CXX insets/InsetCaption.o
CXX insets/InsetCitation.o
CXX insets/InsetCollapsable.o
CXX insets/InsetCommand.o
CXX insets/InsetCommandParams.o
CXX insets/InsetExternal.o
CXX insets/InsetFlex.o
CXX insets/InsetFloat.o
CXX insets/InsetFoot.o
CXX insets/InsetFootlike.o
CXX insets/InsetGraphicsParams.o
CXX insets/InsetGraphics.o
CXX insets/InsetInclude.o
CXX insets/InsetInfo.o
CXX insets/InsetIPA.o
CXX insets/InsetLabel.o
CXX insets/InsetLayout.o
CXX insets/InsetListings.o
CXX insets/InsetMarginal.o
CXX insets/InsetNewpage.o
CXX insets/InsetNote.o
CXX insets/InsetPhantom.o
CXX insets/InsetPreview.o
CXX insets/InsetRef.o
CXX insets/InsetScript.o
CXX insets/InsetSeparator.o
CXX insets/InsetSpace.o
CXX insets/InsetSpecialChar.o
CXX insets/InsetTabular.o
CXX insets/InsetText.o
CXX Compare.o
CXX HunspellChecker.o
CXX PrinterParams.o
AR liblyxcore.a
AR liblyxgraphics.a
AR liblyxmathed.a
AR liblyxinsets.a
CXXLD lyx
liblyxinsets.a(InsetERT.o):(.rodata._ZTVN3lyx8InsetERTE[_ZTVN3lyx8InsetERTE]+0x230):
undefined reference to `lyx::InsetCollapsable::clickable(int, int) const'
liblyxinsets.a(InsetIndex.o):(.rodata._ZTVN3lyx10InsetIndexE[_ZTVN3lyx10InsetIndexE]+0x230):
undefined reference to `lyx::InsetCollapsable::clickable(int, int) const'
liblyxinsets.a(InsetIPAMacro.o):(.rodata._ZTVN3lyx12InsetIPADecoE[_ZTVN3lyx12InsetIPADecoE]+0x230):
undefined reference to `lyx::InsetCollapsable::clickable(int, int) const'
liblyxinsets.a(InsetWrap.o):(.rodata._ZTVN3lyx9InsetWrapE[_ZTVN3lyx9InsetWrapE]+0x230):
undefined reference to `lyx::InsetCollapsable::clickable(int, int) const'
liblyxinsets.a(InsetCaptionable.o):(.rodata._ZTVN3lyx16InsetCaptionableE[_ZTVN3lyx16InsetCaptionableE]+0x230):
undefined reference to `lyx::InsetCollapsable::clickable(int, int) const'
collect2: error: ld returned 1 exit status
make[4]: *** [lyx] Error 1
make[4]: Leaving directory `/home/geek/Build/Devel/lyx/src'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/home/geek/Build/Devel/lyx/src'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/home/geek/Build/Devel/lyx/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/geek/Build/Devel/lyx'
make: *** [all] Error 2
[WARNING] Build command make -j 3 exited with code 2. Please verify that
the build completed successfully.
161 C/C++ compilation units (100%) are ready for analysis
For more details, please look at:
/home/geek/Build/Devel/lyx/cov-int/build-log.txt

Are the *undefined reference* messages above an issue? I'm surprised
because normal compilation (outside coverity) works fine.

Regards,
Liviu

Re: Wishlist for future LyX

[Richard Heck]

On 06/07/2016 12:27 PM, Edwin Leuven wrote:
> On 03 Jun 2016, at 18:35, Helge Hafting  wrote:
>> here are some wishes for the future:
> Hide changes (in lyx)

Some work was done on this a few years ago by me and Vincent. I think
all of it is in his features/HideChanges branch. If I remember right, we
weren't all that far from having it working. But I don't know how easy
it would be to remerge it now.

Richard

Re: [PATCH] unique_ptr and some clean-up

[Guillaume Munch]

Le 07/06/2016 15:23, Jean-Marc Lasgouttes a écrit :

Le 05/06/2016 à 01:01, Guillaume Munch a écrit :

Dear List,


I have recently started using c++11 features, and, one thing leading to
another, some cleaning of the tree happened. Apparently most of the
changes below are supported by old compilers (exceptions below), i.e.
MSVC 2012 and maybe MSVC 2010 (if lucky) since at least one developer
seemed to care about it.


Here is a patch I needed for my compilation.


Thanks, I'll add the missing headers.


The const & for
IconvProcessor is of course not needed, but it makes sense to me.


As a rule of thumb, it is better to pass an argument by value if all you 
are going to do is work on a copy of it.




With this; I am still blocked in unicode.cpp on g++ 4.6. I understand
that it might be because of incomplete C++11 support, but I'd
nevertheless appreciate any insight. These gcc errors messages are just
horrible (I replaced the basic_string template with string to get some
sanity).


It says that it picked the wrong constructor for the pair, that requires
a copyable object. Which precise version of g++ 4.6 do you have? In
4.6.3 pairs accept movable objects. Maybe it fails to generate the
default move constructor. Can you try adding to the declaration of
IconvProcessor?
  IconvProcessor(IconvProcessor &&) = default;
If that's the problem, then it's indeed an incomplete c++11 support,
which requires the move constructor to be implicitly defined in this
context.

Re: Wishlist for future LyX

[Edwin Leuven]

On 03 Jun 2016, at 18:35, Helge Hafting  wrote:
> 
> Now that we have 2.2.0,

I love the new shiny lyx on my retina screen

congrats on a great job!

> here are some wishes for the future:

Hide changes (in lyx)

...

Fwiw ;-)

Re: unique_ptr

[Guillaume Munch]

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

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

Dear List,


I have recently started using c++11 features, and, one thing leading to
another, some cleaning of the tree happened. Apparently most of the
changes below are supported by old compilers (exceptions below), i.e.
MSVC 2012 and maybe MSVC 2010 (if lucky) since at least one developer
seemed to care about it.

1-3. Introduce lyx::unique_ptr and lyx::make_unique and remove auto_ptr.
This is used by two other patches waiting to be committed. After the
first commit, the option --disable-cxx11 will fail.


As I see it, support/unique_ptr.h is only useful to introduce
make_unique. Why is it included at places where only unique_ptr is needed?



Technically, unique_ptr.h is also useful to include . When you
start using unique_ptr, you expect that you might use make_unique at
some point, so you want to just include a generic header.

Re: unique_ptr

[Jean-Marc Lasgouttes]

Le 07/06/2016 à 17:25, Guillaume Munch a écrit :

Technically, unique_ptr.h is also useful to include . When you
start using unique_ptr, you expect that you might use make_unique at
some point, so you want to just include a generic header.


I'd rather include only the standard headers to obtain unique_ptr, and 
then include support/make_unique.h when we explicitly need it.


JMarc

Re: changes (Re: [PATCH] unique_ptr and some clean-up)

[Guillaume Munch]

Le 07/06/2016 08:09, Jean-Marc Lasgouttes a écrit :

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

13. This one is more for Jean-Marc I think (but not exclusively). There
are three changes detailed in the log which are a bit less important
than the ones above, but for which I would nevertheless be happy to have
comments.


This one looks good, although I am not sure why moving code to
MetricsBase help. This is more a data struct to pass around than a real
object.


This is necessary to move the painting code to Changes.cpp. This is 
necessary for painting the change tracking cue on inset labels. More 
generally, there is no reason that only RowPainter should know about the 
appropriate width for lines (taking zoom and high-dpi into acocunt).




What are the changes that you want to strike diagonally?



Non-inline insets such as collapsible insets and displayed math.

Re: boost:regex & gcc

[Jean-Marc Lasgouttes]

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

Note that we have things that are not used in our tree, like for example
boost/typeof, which is selected because of a shortcoming of bcopy.



Am I altering extract.sh correctly?


Yes, I think so. What I am descrbing above is not related to your changes.

JMarc

Re: boost:regex & gcc

[Guillaume Munch]

Le 07/06/2016 07:46, Jean-Marc Lasgouttes a écrit :

Le 06/06/2016 22:43, Pavel Sanda a écrit :

Guillaume Munch wrote:

Any reason to want to get rid of boost completely?


Well, that's a long term wish. It is not nice to pack boost lib
together with
our sources and someone need to care updating boost within the source
tree.


Note that we have things that are not used in our tree, like for example
boost/typeof, which is selected because of a shortcoming of bcopy.



Am I altering extract.sh correctly?

Re: [PATCH] unique_ptr and some clean-up

[Jean-Marc Lasgouttes]

Le 05/06/2016 à 01:01, Guillaume Munch a écrit :

Dear List,


I have recently started using c++11 features, and, one thing leading to
another, some cleaning of the tree happened. Apparently most of the
changes below are supported by old compilers (exceptions below), i.e.
MSVC 2012 and maybe MSVC 2010 (if lucky) since at least one developer
seemed to care about it.


Here is a patch I needed for my compilation. The const & for 
IconvProcessor is of course not needed, but it makes sense to me.


With this; I am still blocked in unicode.cpp on g++ 4.6. I understand 
that it might be because of incomplete C++11 support, but I'd 
nevertheless appreciate any insight. These gcc errors messages are just 
horrible (I replaced the basic_string template with string to get some 
sanity).


The important part is probably

../../../master/src/support/../support/unicode.h:48:7: erreur: 
‘lyx::IconvProcessor::IconvProcessor(const lyx::IconvProcessor&)’ is 
implicitly deleted because the default definition would be ill-formed:


but then the cause of this problem is unclear to me.

JMarc


  CXXunicode.o
In file included from /usr/include/c++/4.6/bits/stl_algobase.h:65:0,
 from /usr/include/c++/4.6/memory:64,
 from 
../../../master/src/support/../support/unique_ptr.h:19,

 from ../../../master/src/support/../support/unicode.h:18,
 from ../../../master/src/support/unicode.cpp:15:
/usr/include/c++/4.6/bits/stl_pair.h: In constructor ‘constexpr 
std::pair<_T1, _T2>::pair(const _T1&, const _T2&) [with _T1 = 
std::string, _T2 = lyx::IconvProcessor]’:
/usr/include/c++/4.6/bits/stl_pair.h:267:72:   instantiated from 
‘std::pair::__type, typename 
std::__decay_and_strip<_T2>::__type> std::make_pair(_T1&&, _T2&&) [with 
_T1 = const std::string&, _T2 = lyx::IconvProcessor, typename 
std::__decay_and_strip<_T2>::__type = lyx::IconvProcessor, typename 
std::__decay_and_strip<_T1>::__type = std::string]’

../../../master/src/support/unicode.cpp:265:60:   instantiated from here
/usr/include/c++/4.6/bits/stl_pair.h:104:31: erreur: use of deleted 
function ‘lyx::IconvProcessor::IconvProcessor(const lyx::IconvProcessor&)’

In file included from ../../../master/src/support/unicode.cpp:15:0:
../../../master/src/support/../support/unicode.h:48:7: erreur: 
‘lyx::IconvProcessor::IconvProcessor(const lyx::IconvProcessor&)’ is 
implicitly deleted because the default definition would be ill-formed:
../../../master/src/support/../support/unicode.h:48:7: erreur: use of 
deleted function ‘std::unique_ptr<_Tp, _Dp>::unique_ptr(const 
std::unique_ptr<_Tp, _Dp>&) [with _Tp = lyx::IconvProcessor::Handler, 
_Dp = std::default_delete, 
std::unique_ptr<_Tp, _Dp> = std::unique_ptr]’

/usr/include/c++/4.6/bits/unique_ptr.h:256:7: erreur: declared here
In file included from /usr/include/c++/4.6/bits/stl_algobase.h:65:0,
 from /usr/include/c++/4.6/memory:64,
 from 
../../../master/src/support/../support/unique_ptr.h:19,

 from ../../../master/src/support/../support/unicode.h:18,
 from ../../../master/src/support/unicode.cpp:15:
/usr/include/c++/4.6/bits/stl_pair.h: In constructor ‘std::pair<_T1, 
_T2>::pair(std::pair<_U1, _U2>&&) [with _U1 = std::string, _U2 = 
lyx::IconvProcessor, _T1 = std::string, _T2 = lyx::IconvProcessor]’:
/usr/include/c++/4.6/bits/stl_pair.h:267:72:   instantiated from 
‘std::pair::__type, typename 
std::__decay_and_strip<_T2>::__type> std::make_pair(_T1&&, _T2&&) [with 
_T1 = const std::string&, _T2 = lyx::IconvProcessor, typename 
std::__decay_and_strip<_T2>::__type = lyx::IconvProcessor, typename 
std::__decay_and_strip<_T1>::__type = std::string]’

../../../master/src/support/unicode.cpp:265:60:   instantiated from here
/usr/include/c++/4.6/bits/stl_pair.h:137:40: erreur: use of deleted 
function ‘lyx::IconvProcessor::IconvProcessor(const lyx::IconvProcessor&)’
/usr/include/c++/4.6/bits/stl_pair.h: In constructor ‘std::pair<_T1, 
_T2>::pair(std::pair<_U1, _U2>&&) [with _U1 = std::string, _U2 = 
lyx::IconvProcessor, _T1 = const std::string, _T2 = lyx::IconvProcessor]’:
/usr/include/c++/4.6/bits/stl_tree.h:139:49:   instantiated from 
‘std::_Rb_tree_node<_Val>::_Rb_tree_node(_Args&& ...) [with _Args = 
{std::pair}, _Val = std::pairstd::string, lyx::IconvProcessor>]’
/usr/include/c++/4.6/ext/new_allocator.h:114:4:   instantiated from 
‘void 
__gnu_cxx::new_allocator<_Tp>::construct(__gnu_cxx::new_allocator<_Tp>::pointer, 
_Args&& ...) [with _Args = {std::pair}, _Tp = std::_Rb_tree_node >, 
__gnu_cxx::new_allocator<_Tp>::pointer = 
std::_Rb_tree_node*]’
/usr/include/c++/4.6/bits/stl_tree.h:405:8:   instantiated from 
‘std::_Rb_tree_node<_Val>* std::_Rb_tree<_Key, _Val, _KeyOfValue, 
_Compare, _Alloc>::_M_create_node(_Args&& ...) [with _Args = 
{std::pair

Re: One official build system?

[Stephan Witt]

Am 07.06.2016 um 14:36 schrieb Kornel Benko :
> 
> Am Dienstag, 7. Juni 2016 um 13:57:30, schrieb Stephan Witt 
>> Am 07.06.2016 um 13:46 schrieb Stephan Witt :
>>> 
>>> Am 07.06.2016 um 12:39 schrieb Kornel Benko :
> 
> The complete list of the files the final LyX.app contains is attached as 
> text file.
 
 Looks like there are many more files in the list. Probably not from LyX?
>>> 
>>> Yes, that’s why I’ve added comments to the list to mark them.
>>> 
 E.g.
/Applications/LyX.app/Contents/Frameworks/
/Applications/LyX.app/Contents/Library/
/Applications/LyX.app/Contents/PlugIns/
/Applications/LyX.app/Contents/Resources/dicts/
/Applications/LyX.app/Contents/Resources/thes/
/Applications/LyX.app/Contents/translations/
>> 
>> Perhaps I misunderstood.
>> 
>> These files are required to run LyX but not part of the install target.
>> Basically the files are private frameworks (aka shared libraries) with
>> Qt5.6, hunspell, libmagic and aspell, the translations and plugins
>> from Qt and the dictionaries and thesauri used at runtime.
> 
> Shouldn't they be at a location where other programs could access them too?
> That is: outside of ${prefix}?

No. Because other programs don’t need to access them.

The concept of the application bundle on Mac makes it completely
relocatable. One may try LyX as application before „installing“
it. All the essential parts of LyX except the OS libraries are
located inside the bundle.

To have multiple versions of LyX on my system I only have to give
them different names like LyX.app or LyX-2.3.0dev.app.

Stephan

Re: Annoying terminal messages: QXcbClipboard: SelectionRequest too old

[Kornel Benko]

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?

Kornel

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

Re: changer

[Jean-Marc Lasgouttes]

Le 07/06/2016 à 09:04, Jean-Marc Lasgouttes a écrit :

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

12. This is a new helper class that I wrote because the Changer class
from MetricsInfo was too cumbersome (essentially a TeX \def with
shadowing). This commit entirely replaces the latter with a better
alternative. While I am not sure that the Changer mechanism itself is
the best practice, this is the best solution in the context it is used,
given the current architecture of painting (I have found uses outside of
painting as well too). Since this is used in all the metrics and
painting mechanism, comments are kindly requested before committing.


I would not pretend that I understand everything here, but having a
general Changer system is something I have been wanting to do for some
time. I think this is OK.


Now that I tried to compile, I can see clang complain:

My old clang 3.0 dies as follow, and clang 3.7 does approximately the same.

JMarc

  CXXMetricsInfo.o
../../master/src/MetricsInfo.cpp:86:9: error: no viable conversion from
  'RefChanger' (aka 
'std::unique_ptr >') to 
'Changer' (aka

  'unique_ptr')
return rc;
   ^~
/usr/include/c++/4.6/bits/unique_ptr.h:136:17: note: candidate 
constructor not viable: no known

  conversion from 'RefChanger' (aka
  'std::unique_ptr >') to 
'nullptr_t' for 1st argument;

  constexpr unique_ptr(nullptr_t)
^
/usr/include/c++/4.6/bits/unique_ptr.h:142:7: note: candidate 
constructor not viable: no known

  conversion from 'RefChanger' (aka
  'std::unique_ptr >') to
  'std::unique_ptr &&' for 1st argument;

  unique_ptr(unique_ptr&& __u)
  ^

Re: One official build system?

[Kornel Benko]

Am Dienstag, 7. Juni 2016 um 13:57:30, schrieb Stephan Witt 
> Am 07.06.2016 um 13:46 schrieb Stephan Witt :
> > 
> > Am 07.06.2016 um 12:39 schrieb Kornel Benko :
> >>> 
> >>> The complete list of the files the final LyX.app contains is attached as 
> >>> text file.
> >> 
> >> Looks like there are many more files in the list. Probably not from LyX?
> > 
> > Yes, that’s why I’ve added comments to the list to mark them.
> > 
> >> E.g.
> >>/Applications/LyX.app/Contents/Frameworks/
> >>/Applications/LyX.app/Contents/Library/
> >>/Applications/LyX.app/Contents/PlugIns/
> >>/Applications/LyX.app/Contents/Resources/dicts/
> >>/Applications/LyX.app/Contents/Resources/thes/
> >>/Applications/LyX.app/Contents/translations/
> 
> Perhaps I misunderstood.
> 
> These files are required to run LyX but not part of the install target.
> Basically the files are private frameworks (aka shared libraries) with
> Qt5.6, hunspell, libmagic and aspell, the translations and plugins
> from Qt and the dictionaries and thesauri used at runtime.

Shouldn't they be at a location where other programs could access them too?
That is: outside of ${prefix}?

> In Library is a tool to support meta-data-management of OSX for
> LyX files. This is not required but ATM installed by autotools.

OK
 
> Stephan

Kornel



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

Re: One official build system?

[Kornel Benko]

Am Dienstag, 7. Juni 2016 um 13:38:51, schrieb Stephan Witt 
> Am 07.06.2016 um 13:22 schrieb Kornel Benko :
> > 
> > Am Dienstag, 7. Juni 2016 um 12:39:12, schrieb Kornel Benko 
> >>> The complete list of the files the final LyX.app contains is attached as 
> >>> text file.
> > 
> > Can I get also a suffixed version of the list?
> 
> What is this?

Executables, manuals get the version suffix too.
So, under unix, I have
/usr/local/bin/lyx2.3
/usr/local/share/man/man1/lyxclient2.3.1
and so on.

> The LyX.app was built with „-with-version-suffix=-2.2“ - 
> probably this list is already what you’re want.

> Stephan

Kornel

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

Re: One official build system?

[Stephan Witt]

Am 07.06.2016 um 13:46 schrieb Stephan Witt :
> 
> Am 07.06.2016 um 12:39 schrieb Kornel Benko :
>>> 
>>> The complete list of the files the final LyX.app contains is attached as 
>>> text file.
>> 
>> Looks like there are many more files in the list. Probably not from LyX?
> 
> Yes, that’s why I’ve added comments to the list to mark them.
> 
>> E.g.
>>  /Applications/LyX.app/Contents/Frameworks/
>>  /Applications/LyX.app/Contents/Library/
>>  /Applications/LyX.app/Contents/PlugIns/
>>  /Applications/LyX.app/Contents/Resources/dicts/
>>  /Applications/LyX.app/Contents/Resources/thes/
>>  /Applications/LyX.app/Contents/translations/

Perhaps I misunderstood.

These files are required to run LyX but not part of the install target.
Basically the files are private frameworks (aka shared libraries) with
Qt5.6, hunspell, libmagic and aspell, the translations and plugins
from Qt and the dictionaries and thesauri used at runtime.

In Library is a tool to support meta-data-management of OSX for
LyX files. This is not required but ATM installed by autotools.

Stephan

Re: One official build system?

[Stephan Witt]

Am 07.06.2016 um 12:39 schrieb Kornel Benko :
> 
> Am Dienstag, 7. Juni 2016 um 08:31:53, schrieb Stephan Witt 
>> Am 06.06.2016 um 18:41 schrieb Kornel Benko :
>>> 
> ...
>>> Yes. Stephan could you send me the list of installed files if you install 
>>> with automake?
>>> I can try to use the same directories.
>> 
>> The same as with autotools :)
>> 
>> Some concrete values are:
>> 
>> bindir = ${prefix}/Contents/MacOS
> 
> Should lyx  (and tex2lyx etc) be installed there too?

Yes.

> If yes, shouldn’t be the the install command in src/CMakeLists.txt:158 be
> install(TARGETS ${_lyx} 
>BUNDLE DESTINATION . COMPONENT Runtime
>RUNTIME DESTINATION ${LYX_UTILITIES_INSTALL_PATH} COMPONENT Runtime)
> 
>> datadir = ${datarootdir}
>> datarootdir = ${prefix}/Contents/Resources
>> docdir = ${datarootdir}/doc/${PACKAGE_TARNAME}
>> infodir = ${datarootdir}/info
>> libdir = ${prefix}/Contents/Resources
>> localedir = ${datarootdir}/locale
>> mandir = ${datadir}/man
> 
> OK
> 
>> pkgpyexecdir = ${pyexecdir}/LyX-2.3
>> pkgpythondir = ${pythondir}/LyX-2.3
> 
> ???, missing in listing

Ignore it - it’s defined in Makefile and not used.

> 
>> prefix = /Users/stephan/git/lyx-build/LyX-2.3.0dev.app
> 
> Is this the same 'prefix' as used above, e.g. ${CMAKE_INSTALL_PREFIX}?

This is the directory where all parts should end up.

> 
>> real_pkgdatadir = 
>> /Users/stephan/git/lyx-build/LyX-2.3.0dev.app/Contents/Resources
>> 
>> The complete list of the files the final LyX.app contains is attached as 
>> text file.
> 
> Looks like there are many more files in the list. Probably not from LyX?

Yes, that’s why I’ve added comments to the list to mark them.

> E.g.
>   /Applications/LyX.app/Contents/Frameworks/
>   /Applications/LyX.app/Contents/Library/
>   /Applications/LyX.app/Contents/PlugIns/
>   /Applications/LyX.app/Contents/Resources/dicts/
>   /Applications/LyX.app/Contents/Resources/thes/
>   /Applications/LyX.app/Contents/translations/
> ...
> 
>>> 
>>> You mean from cmake? Have you tried "--debug-output" as cmake parameter?
>> 
>> I meant the output from build.
> 
> Don't know. What is the command to compile?

I’ve used
$ xcodebuild -project lyx-build/cmake/2.3.0dev/LyX.xcodeproj -target install

But that’s not important. I only wanted to say because of the missing log file
I copied the last lines of terminal output into the mail.

Stephan

Re: One official build system?

[Stephan Witt]

Am 07.06.2016 um 13:22 schrieb Kornel Benko :
> 
> Am Dienstag, 7. Juni 2016 um 12:39:12, schrieb Kornel Benko 
>>> The complete list of the files the final LyX.app contains is attached as 
>>> text file.
> 
> Can I get also a suffixed version of the list?

What is this?

The LyX.app was built with „-with-version-suffix=-2.2“ - 
probably this list is already what you’re want.

Stephan

Re: One official build system?

[Kornel Benko]

Am Dienstag, 7. Juni 2016 um 12:39:12, schrieb Kornel Benko 
> > The complete list of the files the final LyX.app contains is attached as 
> > text file.

Can I get also a suffixed version of the list?

Kornel

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

Re: One official build system?

[Kornel Benko]

Am Dienstag, 7. Juni 2016 um 08:31:53, schrieb Stephan Witt 
> Am 06.06.2016 um 18:41 schrieb Kornel Benko :
> > 
...
> > Yes. Stephan could you send me the list of installed files if you install 
> > with automake?
> > I can try to use the same directories.
> 
> The same as with autotools :)
> 
> Some concrete values are:
> 
> bindir = ${prefix}/Contents/MacOS

Should lyx  (and tex2lyx etc) be installed there too?
If yes, shouldn’t be the the install command in src/CMakeLists.txt:158 be
install(TARGETS ${_lyx} 
BUNDLE DESTINATION . COMPONENT Runtime
RUNTIME DESTINATION ${LYX_UTILITIES_INSTALL_PATH} COMPONENT Runtime)

> datadir = ${datarootdir}
> datarootdir = ${prefix}/Contents/Resources
> docdir = ${datarootdir}/doc/${PACKAGE_TARNAME}
> infodir = ${datarootdir}/info
> libdir = ${prefix}/Contents/Resources
> localedir = ${datarootdir}/locale
> mandir = ${datadir}/man

OK

> pkgpyexecdir = ${pyexecdir}/LyX-2.3
> pkgpythondir = ${pythondir}/LyX-2.3

???, missing in listing

> prefix = /Users/stephan/git/lyx-build/LyX-2.3.0dev.app

Is this the same 'prefix' as used above, e.g. ${CMAKE_INSTALL_PREFIX}?

> real_pkgdatadir = 
> /Users/stephan/git/lyx-build/LyX-2.3.0dev.app/Contents/Resources
> 
> The complete list of the files the final LyX.app contains is attached as text 
> file.

Looks like there are many more files in the list. Probably not from LyX?
E.g.
/Applications/LyX.app/Contents/Frameworks/
/Applications/LyX.app/Contents/Library/
/Applications/LyX.app/Contents/PlugIns/
/Applications/LyX.app/Contents/Resources/dicts/
/Applications/LyX.app/Contents/Resources/thes/
/Applications/LyX.app/Contents/translations/
...

> > 
> > You mean from cmake? Have you tried "--debug-output" as cmake parameter?
> 
> I meant the output from build.

Don't know. What is the command to compile? Is there a manual?
For instance for 'make' it should be:
# make VERBOSE=1 ...

> Stephan

Kornel

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

Re: remove boost stuff

[Jean-Marc Lasgouttes]

Le 07/06/2016 08:54, Jean-Marc Lasgouttes a écrit :

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

4-11. Replace Boost features with std equivalents when possible. The
result is more consistency across plaforms and fewer dependencies on
Boost. More details down below. For your reading convenience, patches
1-11 are also attached together in batch0.diff.


This is OK for me (if the extra srd:: are removed).


I was a bit fast here.


4-6. Straightforward and without risk.


Indeed. When this is over, we shall update our boost source tree to 
remove unused stuff.



7-8. These are essentially examples. While there is no hurry to apply
these patches, they are a good example of how the unique_ptr introduced
in the first commit let us simplify the class definitions. I believe in
"do not fix the unbroken", but I also believe that the whole source
would benefit from being less convoluted.


Sure, it is good to use modern C++11 constructs. I may complain at some 
time that it breaks my oldish gcc 4.6 setup, but we will see what to do 
if/when this happens.


Actually, I will try to apply and compile your whole patchset with my 
ancient compiler.



9. There should be no bad surprise with  itself, however since
the purpose of everything in strfwd.h is not clear to me, I would rather
have a second opinion.


I do not know much about that either. I suspect we will have to abandon 
strfwd.h at some time.



10. boost::bind and boost::function. For this one it would be preferable
to have a confirmation that it is safe. In particular, some files used
the boost version explicitly even when lyx::function was already defined
from the standard library. Is there a particular reason?


I think there is no real reason.


11. boost:regex. We have learnt the pitfalls of having two regex
libraries at the same time. However, according to a comment in the
source, gcc < 4.9.0 supports std::regex badly. Do we still care about
gcc < 4.9.0 ? (no hurry, and the patch is trivial)


As was written by others already, it is too early. Ubuntu 14.04 still 
has 4.8.2.


JMarc

changes (Re: [PATCH] unique_ptr and some clean-up)

[Jean-Marc Lasgouttes]

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

13. This one is more for Jean-Marc I think (but not exclusively). There
are three changes detailed in the log which are a bit less important
than the ones above, but for which I would nevertheless be happy to have
comments.


This one looks good, although I am not sure why moving code to 
MetricsBase help. This is more a data struct to pass around than a real 
object.


What are the changes that you want to strike diagonally?


JMarc

changer (was: Re: [PATCH] unique_ptr and some clean-up)

[Jean-Marc Lasgouttes]

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

12. This is a new helper class that I wrote because the Changer class
from MetricsInfo was too cumbersome (essentially a TeX \def with
shadowing). This commit entirely replaces the latter with a better
alternative. While I am not sure that the Changer mechanism itself is
the best practice, this is the best solution in the context it is used,
given the current architecture of painting (I have found uses outside of
painting as well too). Since this is used in all the metrics and
painting mechanism, comments are kindly requested before committing.


I would not pretend that I understand everything here, but having a 
general Changer system is something I have been wanting to do for some 
time. I think this is OK.


JMarc

remove boost stuff (was: Re: [PATCH] unique_ptr and some clean-up)

[Jean-Marc Lasgouttes]

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

4-11. Replace Boost features with std equivalents when possible. The
result is more consistency across plaforms and fewer dependencies on
Boost. More details down below. For your reading convenience, patches
1-11 are also attached together in batch0.diff.


This is OK for me (if the extra srd:: are removed).



12. This is a new helper class that I wrote because the Changer class
from MetricsInfo was too cumbersome (essentially a TeX \def with
shadowing). This commit entirely replaces the latter with a better
alternative. While I am not sure that the Changer mechanism itself is
the best practice, this is the best solution in the context it is used,
given the current architecture of painting (I have found uses outside of
painting as well too). Since this is used in all the metrics and
painting mechanism, comments are kindly requested before committing.

13. This one is more for Jean-Marc I think (but not exclusively). There
are three changes detailed in the log which are a bit less important
than the ones above, but for which I would nevertheless be happy to have
comments.


More details about std replacing boost:


4-6. Straightforward and without risk.

7-8. These are essentially examples. While there is no hurry to apply
these patches, they are a good example of how the unique_ptr introduced
in the first commit let us simplify the class definitions. I believe in
"do not fix the unbroken", but I also believe that the whole source
would benefit from being less convoluted.

9. There should be no bad surprise with  itself, however since
the purpose of everything in strfwd.h is not clear to me, I would rather
have a second opinion.

10. boost::bind and boost::function. For this one it would be preferable
to have a confirmation that it is safe. In particular, some files used
the boost version explicitly even when lyx::function was already defined
from the standard library. Is there a particular reason?

11. boost:regex. We have learnt the pitfalls of having two regex
libraries at the same time. However, according to a comment in the
source, gcc < 4.9.0 supports std::regex badly. Do we still care about
gcc < 4.9.0 ? (no hurry, and the patch is trivial)

More details are in the commit logs. I would also run the tests before
committing, if simple enough now to do.


Guillaume

unique_ptr (was: Re: [PATCH] unique_ptr and some clean-up)

[Jean-Marc Lasgouttes]

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

Dear List,


I have recently started using c++11 features, and, one thing leading to
another, some cleaning of the tree happened. Apparently most of the
changes below are supported by old compilers (exceptions below), i.e.
MSVC 2012 and maybe MSVC 2010 (if lucky) since at least one developer
seemed to care about it.

1-3. Introduce lyx::unique_ptr and lyx::make_unique and remove auto_ptr.
This is used by two other patches waiting to be committed. After the
first commit, the option --disable-cxx11 will fail.


As I see it, support/unique_ptr.h is only useful to introduce 
make_unique. Why is it included at places where only unique_ptr is needed?


JMarc

Re: [PATCH] unique_ptr and some clean-up

[Jean-Marc Lasgouttes]

Le 06/06/2016 22:26, Georg Baum a écrit :

It turned out that it was too difficult to retain the stuff for some
hypothetical future C++14 checks. I will commit the attached unless nobody
objects. This is simply the unconditional use of C++11. After this patch it
would be possible to get rid of parts of the included boost already.


Why do you remove the code that checks for C++11? At some time my idea 
was to do


for arg in "" "-std c++11" "-std c++0x" ; do
  if $CXX $arg is a C++11 compiler then
break
done
if $CXX $arg is not C++11
  ERROR(C++11 compiler not found)

JMarc

Re: boost:regex & gcc

[Jean-Marc Lasgouttes]

Le 06/06/2016 22:43, Pavel Sanda a écrit :

Guillaume Munch wrote:

Any reason to want to get rid of boost completely?


Well, that's a long term wish. It is not nice to pack boost lib together with
our sources and someone need to care updating boost within the source tree.


Note that we have things that are not used in our tree, like for example 
boost/typeof, which is selected because of a shortcoming of bcopy.


JMarc

Re: Tarballs for LyX 2.2.0 are on FTP

[Liviu Andronic]

On Tue, Jun 7, 2016 at 12:10 AM, Andrew Parsloe  wrote:
> On 7/06/2016 9:50 a.m., Richard Heck wrote:
>>
>> On 06/06/2016 03:33 PM, Georg Baum wrote:
>>>
>>> Jean-Marc Lasgouttes wrote:
>>>
 Le 05/06/2016 à 21:05, Guillaume Munch a écrit :
>
> Yet, most of the file format changes are very simple. I wonder whether
> one could introduce a single compilation variable to disable them,
> and ask developers to enclose file-format-specific code between the
> corresponding #ifdefs. (For instance in my last file format change all
> that was needed to be enclosed was the parsing code.) This would allow
> the release of "master versions without file format changes", either as
> nightlies or as official "x.5" versions as Pavel suggested by Pavel in
> another message (without having to maintain three branches in
> parallel).

 This looks too complicated to me. And eventually there will be changes
 that cannot be treated like that, and all the previous work on small 
 changes
 will be useless.

 Note that that stable nightlies could be updated with lyx2lyx code for
 new master versions in parallel with master.
>>>
>>> Or we could add a mode that calls lyx2lyx automatically after saving, so
>>> that effectively the master version would use the old file format. This
>>> would probably work fine as long as no new features are used.
>>
>> Yes, but do we want to warn people then not to use new features? I think
>> it would just confuse people for us to tell them to test master but not
>> to use some new features if they want to be able to go back to stable.
>>
>> Richard
>>
> As a potential user-tester I've followed this discussion with interest. I
> can't imagine downloading and installing LyX daily, but I can imagine doing
> this each month and using the resulting installation as my working LyX (as I
> did for the alphas and betas of 2.2.0), therefore with all features turned
> on and potential unreadability in earlier versions.
>
This is how I often use the devel builds as well --- switch to a devel
build and work with it for some time. I think other testers broadly do
the same when there is some new killer feature in master, but it isn't
clear when a new release is due.

Liviu


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