Re: [LyX/master] Improve build for FreeBSD.

[Richard Heck]

On 06/08/2016 10:35 PM, Pavel Sanda wrote:
> Pavel Sanda wrote:
>> commit 3f4901de9ce36866b75e56ec6864354e4119e647
>> Author: Pavel Sanda 
>> Date:   Wed Jun 8 19:33:08 2016 -0700
>>
>> Improve build for FreeBSD.
>> 
>> Patch from Shankar Giri Venkita Giri.
>>
>> diff --git a/configure.ac b/configure.ac
>> index 5d6fe77..3353df4 100644
>> --- a/configure.ac
>> +++ b/configure.ac
>> @@ -237,6 +237,7 @@ dnl AC_LANG_POP(C)
>>  lyx_win_res=false;
>>  case ${host} in
>>  *mingw*|*cygwin*) lyx_win_res=true;;
>> +*freebsd*) AC_SEARCH_LIBS(backtrace_symbols, [execinfo])
>>  esac
>>  if test "x$lyx_win_res" = "xtrue"; then
>>  AC_CHECK_TOOL(RC, windres,)
> Branch? P

I'm completely clueless about this kind of thing, so if you think it's a
good idea, it's fine for 2.2.x.

rh

Re: Tarballs for LyX 2.2.0 are on FTP

[Richard Heck]

On 06/08/2016 03:57 PM, Georg Baum wrote:
> Guillaume Munch wrote:
>
>> Le 07/06/2016 00:00, Richard Heck a écrit :
>>> Our use of git would make it very easy for us to have a branch in which
>>> new features not requiring format changes could also be put.
>>>
>> This solution would be fine by me too, if people agree to have three
>> branches.
> As long as I am allowed to ignore the third branch completely I am fine with 
> that.

Anyone can of course have as many branches as they like. It's fine with
me to have such a branch in the main git repo.

Richard

Re: #10206: Problem installing Lyx 2.2

[Paul McNelis]

Thanks for all your patience, apologies for my remarks, deeply appreciate
your service to all of us.
Still not working when I copy the two .dll files
msvcp100.dll
 msvcr100.dll
to the 2.2 bin file from 2.1.4.
Will stay with 2.1.4 till something develops.

What is odd is that I have a new laptop, an HP with wondows 7 on it, and it
works fine (2.2) but not on windows 8 on the laptop and on the desktop
windows 7.

Like to have consistent lyx so I can transfer files and edit them with the
same version.
Will update the windows on all platforms.  Maybe that is issue.
Sort of like detective work.
Paul

On Wed, Jun 8, 2016 at 7:45 PM, LyX Ticket Tracker  wrote:

> #10206: Problem installing Lyx 2.2
> +
>  Reporter:  Saint1106   |   Owner:  uwestoehr
>  Type:  defect  |  Status:  assigned
>  Priority:  highest |   Milestone:
> Component:  general | Version:  2.2.0
>  Severity:  major   |  Resolution:
>  Keywords:  os=windows  |
> +
>
> Comment (by uwestoehr):
>
>  Do you have LyX 2.1.4 installed? If so, please try if it works if you copy
>  the files
>  msvcp100.dll
>  msvcr100.dll
>  from the bin folder of 2.1.4 to the bin folder of 2.2.0
>
>  Please report back as soon as possible
>
> --
> Ticket URL: <
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.lyx.org_trac_ticket_10206-23comment-3A4=CwIGaQ=aqMfXOEvEJQh2iQMCb7Wy8l0sPnURkcqADc2guUW8IM=EY6tVRPmrpTy9NCyJc92YtNIUn4SO7xGD4ZBFeDVXpo=h_YiHnWTK_SNUIfAmILwMT0Sh_OPoEyz8ZBC6adaMpo=reR-oSm_hIznFVUxaP2nKBOcgOzTndZNt0KwAeZShWI=
> >
> The LyX Project <
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.lyx.org_=CwIGaQ=aqMfXOEvEJQh2iQMCb7Wy8l0sPnURkcqADc2guUW8IM=EY6tVRPmrpTy9NCyJc92YtNIUn4SO7xGD4ZBFeDVXpo=h_YiHnWTK_SNUIfAmILwMT0Sh_OPoEyz8ZBC6adaMpo=LIJxZvwVLBMgwIFb6Da6sAkjVA-FTAR3nVTGYyzM1PA=
> >
> LyX -- The Document Processor
>



-- 
Robert Bendheim Chair
Department of Finance
Gabelli School of Business
Fordham University
45 Columbus Ave.
Room 602-A
New York, N.Y. 10023
www.bnet.fordham.edu/mcnelis

Re: [LyX/master] Improve build for FreeBSD.

[Pavel Sanda]

Pavel Sanda wrote:
> commit 3f4901de9ce36866b75e56ec6864354e4119e647
> Author: Pavel Sanda 
> Date:   Wed Jun 8 19:33:08 2016 -0700
> 
> Improve build for FreeBSD.
> 
> Patch from Shankar Giri Venkita Giri.
> 
> diff --git a/configure.ac b/configure.ac
> index 5d6fe77..3353df4 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -237,6 +237,7 @@ dnl AC_LANG_POP(C)
>  lyx_win_res=false;
>  case ${host} in
>  *mingw*|*cygwin*) lyx_win_res=true;;
> +*freebsd*) AC_SEARCH_LIBS(backtrace_symbols, [execinfo])
>  esac
>  if test "x$lyx_win_res" = "xtrue"; then
>  AC_CHECK_TOOL(RC, windres,)

Branch? P

Re: One official build system?

[Pavel Sanda]

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.

Pavel

Re: #10206: Problem installing Lyx 2.2

[Paul McNelis]

Getting the error
0xc07b
time and time again, after multiple installations,on two different laptops,
one with windows 8, another with windows 7.
Any ideas what is going wrong?
Paul

On Wed, Jun 8, 2016 at 8:30 PM, LyX Ticket Tracker  wrote:

> #10206: Problem installing Lyx 2.2
> ---+
>  Reporter:  Saint1106  |   Owner:  uwestoehr
>  Type:  defect |  Status:  assigned
>  Priority:  highest|   Milestone:
> Component:  windows-installer  | Version:  2.2.0
>  Severity:  major  |  Resolution:
>  Keywords:  os=windows,infoneeded  |
> ---+
>
> Comment (by aparsloe):
>
>  Just for the record, I have a Windows 7 laptop with LyX 2.2.0 working
>  well, as also did 2.1.4 which is still installed. In fact both Uwe's
>  Installer-1 and Installer-2 produced working versions of LyX 2.2.0. I see
>  that msvcp100.dll and msvcr100.dll are in the bin folder of 2.2.0. I
>  didn't put them there so the installation process did that.
>
> --
> Ticket URL: <
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.lyx.org_trac_ticket_10206-23comment-3A6=CwIGaQ=aqMfXOEvEJQh2iQMCb7Wy8l0sPnURkcqADc2guUW8IM=EY6tVRPmrpTy9NCyJc92YtNIUn4SO7xGD4ZBFeDVXpo=XKYAD92SXAqzWlZ0HsNf9vBzQhJyURv4GCtMl5SrHO0=pvOj0bXlHj-bpScv2NOOr26umz3XldGzI1or9veCJsI=
> >
> The LyX Project <
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.lyx.org_=CwIGaQ=aqMfXOEvEJQh2iQMCb7Wy8l0sPnURkcqADc2guUW8IM=EY6tVRPmrpTy9NCyJc92YtNIUn4SO7xGD4ZBFeDVXpo=XKYAD92SXAqzWlZ0HsNf9vBzQhJyURv4GCtMl5SrHO0=2JZM7VruaHZEq-N10lKhbO978b3N-naozVfkSFKqln8=
> >
> LyX -- The Document Processor
>



-- 
Robert Bendheim Chair
Department of Finance
Fordham University
45 Columbus Ave.
Room 602-A
New York, N.Y. 10023
www.bnet.fordham.edu/mcnelis

Re: #10206: Problem installing Lyx 2.2

[Uwe Stöhr]

Am 09.06.2016 um 01:41 schrieb Paul McNelis:


Please help, is this new version a joke?  Why cannot it work on windows?


I must admit that I don't like how you write. You are using free 
software developed by volunteers spending their spare time to give support.


Describe your problem properly and we will have a look.


Please fix this, or cancel the new version, it is not ready for
distribution.  Do not waste our time.  Either property beta-test it or not.
We are busy people.


Are you joking, you are at a university. When you will leave it for a 
job you will find out what busy means.


regards Uwe

Re: #10206: Problem installing Lyx 2.2

[Paul McNelis]

The beta version worked well, that is the problem, no reason to give
feedback when it worked.
Please, either the product works or it does not.  I will stay with 2.1.4.
I am a professor, I want to give a good product to my students.

On Wed, Jun 8, 2016 at 7:45 PM, LyX Ticket Tracker  wrote:

> #10206: Problem installing Lyx 2.2
> +
>  Reporter:  Saint1106   |   Owner:  uwestoehr
>  Type:  defect  |  Status:  assigned
>  Priority:  highest |   Milestone:
> Component:  general | Version:  2.2.0
>  Severity:  major   |  Resolution:
>  Keywords:  os=windows  |
> +
>
> Comment (by uwestoehr):
>
>  Do you have LyX 2.1.4 installed? If so, please try if it works if you copy
>  the files
>  msvcp100.dll
>  msvcr100.dll
>  from the bin folder of 2.1.4 to the bin folder of 2.2.0
>
>  Please report back as soon as possible
>
> --
> Ticket URL: <
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.lyx.org_trac_ticket_10206-23comment-3A4=CwIGaQ=aqMfXOEvEJQh2iQMCb7Wy8l0sPnURkcqADc2guUW8IM=EY6tVRPmrpTy9NCyJc92YtNIUn4SO7xGD4ZBFeDVXpo=h_YiHnWTK_SNUIfAmILwMT0Sh_OPoEyz8ZBC6adaMpo=reR-oSm_hIznFVUxaP2nKBOcgOzTndZNt0KwAeZShWI=
> >
> The LyX Project <
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.lyx.org_=CwIGaQ=aqMfXOEvEJQh2iQMCb7Wy8l0sPnURkcqADc2guUW8IM=EY6tVRPmrpTy9NCyJc92YtNIUn4SO7xGD4ZBFeDVXpo=h_YiHnWTK_SNUIfAmILwMT0Sh_OPoEyz8ZBC6adaMpo=LIJxZvwVLBMgwIFb6Da6sAkjVA-FTAR3nVTGYyzM1PA=
> >
> LyX -- The Document Processor
>



-- 
Robert Bendheim Chair
Department of Finance
Fordham University
45 Columbus Ave.
Room 602-A
New York, N.Y. 10023
www.bnet.fordham.edu/mcnelis

Re: [patch] Fix lyx-2.3dev build failure in FreeBSD

[Shankar Giri Venkita Giri]

Thanks Pavel.

 

I'll try to produce a patch for #1. Then both #1 and #2, after review, can go into master/branch. I play around in FreeBSD frequently, so I can help with build issues/regressions in future as well.

 

Shankar

 

Sent: Monday, June 06, 2016 at 12:48 PM
From: "Pavel Sanda" 
To: lyx-devel@lists.lyx.org
Subject: Re: [patch] Fix lyx-2.3dev build failure in FreeBSD

On Sat, May 07, 2016 at 06:45:26AM +0200, Shankar Giri Venkita Giri wrote:
> There are basically two issues on FreeBSD.
>
> Issue #1. Standard Includes and Libs are in /usr/local/include and /
> usr/local/lib unline Linux variants. --with-extra-prefix=/usr/local
> solves this problem. FreeBSD Ports build system exports LOCALBASE to
> /usr/local and so this problem does not occur when building from
> ports. When building from source directly, --with-extra-prefix is
> necessary
> Issue #2. -lexecinfo is needed for backtrace() on FreeBSD (https://
> github.com/pelegm/google-glog/issues/214) - Patch attached.

Since you tested it, I think patch for #2 should go in to both master/branch.

> 1. Other BSDs certainly should have Issue #1, but probably need to
> check with other NetBSD, OpenBSD, DragonflyBSD users for Issue #2.
> Then the patch can be generalized to *BSD*.

Agreed, but this is really their call, I don't think any active
dev is currently running NetBSD, OpenBSD, DragonflyBSD to test that.

> 2. Do we patch code for Issue #1 or just add README.BSD and document
> the --with-extra-prefix=/usr/local argument?

If you can produce nice enough patch, we will include it.
Otherwise I would include it into RELEASE-NOTES, section with Known issues.

> 3. We can either patch in LyX or just ignore it and file a ticket in
> the FreeBSD ports system so that they add the patch in their build
> process. I prefer LyX to compile independent of build systems
> applying patches during building (that allows working and compiling
> git code directly), but its the community's call.

Agreed, but we rely on you to helps us with it.

Pavel

Re: #10206: Problem installing Lyx 2.2

[Guillaume Munch]

Le 09/06/2016 00:41, Paul McNelis a écrit :

Please help, is this new version a joke?  Why cannot it work on
windows?  Please fix this, or cancel the new version, it is not ready
for distribution.  Do not waste our time.  Either property beta-test it
or not. We are busy people.


--
Robert Bendheim Chair
Department of Finance
Fordham University
45 Columbus Ave.
Room 602-A
New York, N.Y. 10023
www.bnet.fordham.edu/mcnelis 



Dear Mr Paul McNelis

I do not remember that the LyX team has heard any of your feedback
during the beta-test. You seem to believe that you can use the product
of the work of dozens of people without giving anything back, and then
come complaining when it stops working for you. The only person
ungratefully wasting other people's time appears to be you. After your
message, I am surely not going to look into this issue for you.

Guillaume Munch

Re: #10206: Problem installing Lyx 2.2

[Paul McNelis]

Please help, is this new version a joke?  Why cannot it work on windows?
Please fix this, or cancel the new version, it is not ready for
distribution.  Do not waste our time.  Either property beta-test it or not.
We are busy people.

On Wed, Jun 8, 2016 at 6:33 PM, LyX Ticket Tracker  wrote:

> #10206: Problem installing Lyx 2.2
> +
>  Reporter:  Saint1106   |   Owner:  uwestoehr
>  Type:  defect  |  Status:  assigned
>  Priority:  highest |   Milestone:
> Component:  general | Version:  2.2.0
>  Severity:  major   |  Resolution:
>  Keywords:  os=windows  |
> +
>
> Comment (by skostysh):
>
>  Also reported [
> https://urldefense.proofpoint.com/v2/url?u=http-3A__latex-2Dcommunity.org_forum_viewtopic.php-3Ff-3D19-26t-3D27439=CwIGaQ=aqMfXOEvEJQh2iQMCb7Wy8l0sPnURkcqADc2guUW8IM=EY6tVRPmrpTy9NCyJc92YtNIUn4SO7xGD4ZBFeDVXpo=SIZ6_JcTw_VLEeCPFHrnwvQ2XDgabuhx5fOjx-XBVSA=qqgTDNA2PVKVbglGea8KksATd-l6xEYvK0OY4biPses=
>  here].
>
> --
> Ticket URL: <
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.lyx.org_trac_ticket_10206-23comment-3A3=CwIGaQ=aqMfXOEvEJQh2iQMCb7Wy8l0sPnURkcqADc2guUW8IM=EY6tVRPmrpTy9NCyJc92YtNIUn4SO7xGD4ZBFeDVXpo=SIZ6_JcTw_VLEeCPFHrnwvQ2XDgabuhx5fOjx-XBVSA=fUAeHa6sNgKpp4yo_y3ct3N9MKnW4gM-6wuLnV6zA58=
> >
> The LyX Project <
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.lyx.org_=CwIGaQ=aqMfXOEvEJQh2iQMCb7Wy8l0sPnURkcqADc2guUW8IM=EY6tVRPmrpTy9NCyJc92YtNIUn4SO7xGD4ZBFeDVXpo=SIZ6_JcTw_VLEeCPFHrnwvQ2XDgabuhx5fOjx-XBVSA=_n0gdkp0rkdwGYrFIiNYjImJH3NXdUJ7-tRqz3_T7VM=
> >
> LyX -- The Document Processor
>



-- 
Robert Bendheim Chair
Department of Finance
Fordham University
45 Columbus Ave.
Room 602-A
New York, N.Y. 10023
www.bnet.fordham.edu/mcnelis

Re: Upgrading to Lyx 2.2

[Scott Kostyshak]

On Mon, Jun 06, 2016 at 01:57:11PM -0400, Scott Kostyshak wrote:
> On Mon, May 30, 2016 at 12:21:47PM -0400, Scott Kostyshak wrote:
> > On Mon, May 30, 2016 at 02:43:57PM +0200, Charles de Miramon wrote:
> > > Kornel Benko wrote:
> > > 
> > > > Knowing what went wrong, why are you doing it again?
> > > > Simply remove your local copy of cua.bind. Lyx will use the system
> > > > version.
> > > > 
> > > 
> > > Of course.
> > 
> > Glad the issue is solved.
> > 
> > Can you please send your old cua.bind? If it had an older format it
> > should have been updated automatically.
> 
> Hi Charles,
> 
> Would you mind sharing your old cua.bind file? There might be a bug in
> LyX that we should fix.

Charles kindly sent me the file. The problem was that there was a bind
definition before the Format line:

\bind "M-l" "flex-insert Latin"

We could consider moving the Format line to the first line of the file
to avoid future confusion, but I'm not sure it is worth it.

I'm moving this discussion to lyx-devel (if indeed there is future
discussion).

Scott


signature.asc
Description: PGP signature

Re: compilation for coverity fails

[Liviu Andronic]

On Tue, Jun 7, 2016 at 8:08 PM, Liviu Andronic  wrote:

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

Does anyone know if these error messages point to a problem in our code?

Regards,
Liviu

Re: Tarballs for LyX 2.2.0 are on FTP

[Liviu Andronic]

On Wed, Jun 8, 2016 at 10:14 PM, Guillaume Munch  wrote:
>
> Le 08/06/2016 20:48, Pavel Sanda a écrit :
>>
>> Guillaume Munch wrote:
>>>
>>> Here's what I suggest. Let's do, on a trial basis for the duration of
>>> 2.3dev, a branch that mirrors master but inserts patches to disable the
>>> input and output of new file-format features (as well as layout changes,
>>> etc.) after each file-format change. We would see if the idea works out.
>>>
>>> I was going to do something like this anyway for myself, so I propose to
>>> take care of it until it gains some momentum. At first we could just
>>> make nightlies out of it for Ubuntu.
>>>
>>> One roadblock that I am expecting is that the author of the original
>>> file format change knows better than me how to block it, but in case of
>>> trouble I can ask for advice. I plan to include the patches responsible
>>> for file format changes and patch them afterwards, because otherwise I
>>> expect the code to diverge too much. If at some point it no longer works
>>> then I will stop.
>>>
>>> I will call the branch ?unstable?.
>>>
>>> Agreement? Suggestions?
>>
>>
>> So what is the goal here. Jut to get aditional testing from interested
>> parties or to make release from this branch at the end?
>
>
> In a first time the goal would be to have nightlies, if Liviu agrees that we 
> reuse his infrastructure.
>
Generally I'm not convinced that spreading testing over two types of
master builds is a good idea, especially since we do not have such
testing manpower anyway. The problem with bleeding edge master is not
confined to fileformat changes (and in any case as it had been
suggested you can still export to 2.prev anyway) --- master will
always contain regressions and other nastiness, which is more likely
to keep testers at bay, at least those who use LyX for production.
And, for me at least, it feels strange to test neutered bleeding edge
code --- seems like a way to keep testers from trying out latest
fileformat changes and associated complications. (Imagine for instance
if the radical 2.2.0dev beamer modifications hadn't gotten the
attention they deserved...)

We can of course set up daily builds using this third branch, but I
wouldn't put them in the lyx-devel PPAs. Given that the packaging
arrangements are already ready for daily builds (though I still have
to prepare the 2.3 builds, probably towards the end of the month),
setting up a new recipe/PPA should be very easy and I'll gladly walk
you through it.

Regards,
Liviu


> If the experience is positive, then we can discuss again your idea of having 
> official intermediate releases of master without file format changes, after 
> 2.3 is released.
>
>

Re: unique_ptr

[Guillaume Munch]

Le 08/06/2016 21:58, Jean-Marc Lasgouttes a écrit :

Le 08/06/16 à 20:21, Guillaume Munch a écrit :

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



When you have unique_ptr, you also want to have make_unique without
hassle. The reason is that apart from some corner cases, make_unique is
never really necessary, more of a convenience.


But none of your patches use it, AFAIK.


Yes, RefChanger.h. There's another clean-up patch that uses it that I'm
waiting to commit. And I don't make a big use of unique_ptr in these
patches anyway. Then there are all the substitutions of scoped_ptr and
auto_ptr. But the first thing they do is release the pointer in the
wild, so it was breaking my heart to use make_unique for that (and they
do a cast at the same time so one had to write the full type anyway).




So I prefer to have
unique_ptr.h open unique_ptr in the lyx namespace for me and only have
to include one header. But, you are always free to just include .


I thought that that the idea was to use C++11 natively instead of our
homegrown headers. So I would put only things that we define ourselves
in support headers. Having one more header to include make it clear of
what we have to do when the feature is natively supported.


Yes, this is the case of a C++14 feature, and we can remove the header 
once decided to drop support for C++11. BTW the definition is the one 
recommended by the standard. And it's free, I made it for you.




But then I am not really a C++(11) expert.



Neither am I ;)

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

[Scott Kostyshak]

On Wed, Jun 08, 2016 at 06:35:21PM +0200, Georg Baum wrote:
> Scott Kostyshak wrote:
> 
> > 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?
> 
> They don't need to do anything. Both with cmake and autotools you will get 
> the message "A C++11 compatible compiler is required" if you try to build 
> with a compiler which is too old. This is clear enough IMHO (and packagers 
> will most likely not run into this problem anyway, all default compilers of 
> all current linux distros are new enough).

OK makes sense. Thanks for explaining this.

Scott


signature.asc
Description: PGP signature

Re: unique_ptr

[Jean-Marc Lasgouttes]

Le 08/06/16 à 20:21, Guillaume Munch a écrit :

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



When you have unique_ptr, you also want to have make_unique without
hassle. The reason is that apart from some corner cases, make_unique is
never really necessary, more of a convenience.


But none of your patches use it, AFAIK.


So I prefer to have
unique_ptr.h open unique_ptr in the lyx namespace for me and only have
to include one header. But, you are always free to just include .


I thought that that the idea was to use C++11 natively instead of our 
homegrown headers. So I would put only things that we define ourselves 
in support headers. Having one more header to include make it clear of 
what we have to do when the feature is natively supported.


But then I am not really a C++(11) expert.

JMarc

Re: Tarballs for LyX 2.2.0 are on FTP

[Jean-Marc Lasgouttes]

Le 08/06/16 à 22:14, Guillaume Munch a écrit :

As long as I am allowed to ignore the third branch completely I am
fine with that.


I think this is the idea.


So why not, indeed.

JMarc

Re: Tarballs for LyX 2.2.0 are on FTP

[Guillaume Munch]

Le 08/06/2016 20:57, Georg Baum a écrit :

Guillaume Munch wrote:


Le 07/06/2016 00:00, Richard Heck a écrit :


Our use of git would make it very easy for us to have a branch in which
new features not requiring format changes could also be put.



This solution would be fine by me too, if people agree to have three
branches.


As long as I am allowed to ignore the third branch completely I am fine with
that.



I think this is the idea.

Re: Tarballs for LyX 2.2.0 are on FTP

[Guillaume Munch]

Le 08/06/2016 20:48, Pavel Sanda a écrit :

Guillaume Munch wrote:

Here's what I suggest. Let's do, on a trial basis for the duration of
2.3dev, a branch that mirrors master but inserts patches to disable the
input and output of new file-format features (as well as layout changes,
etc.) after each file-format change. We would see if the idea works out.

I was going to do something like this anyway for myself, so I propose to
take care of it until it gains some momentum. At first we could just
make nightlies out of it for Ubuntu.

One roadblock that I am expecting is that the author of the original
file format change knows better than me how to block it, but in case of
trouble I can ask for advice. I plan to include the patches responsible
for file format changes and patch them afterwards, because otherwise I
expect the code to diverge too much. If at some point it no longer works
then I will stop.

I will call the branch ?unstable?.

Agreement? Suggestions?


So what is the goal here. Jut to get aditional testing from interested
parties or to make release from this branch at the end?


In a first time the goal would be to have nightlies, if Liviu agrees 
that we reuse his infrastructure. If the experience is positive, then we 
can discuss again your idea of having official intermediate releases of 
master without file format changes, after 2.3 is released.

Re: Tarballs for LyX 2.2.0 are on FTP

[Georg Baum]

Guillaume Munch wrote:

> Le 07/06/2016 00:00, Richard Heck a écrit :
>>
>> Our use of git would make it very easy for us to have a branch in which
>> new features not requiring format changes could also be put.
>>
> 
> This solution would be fine by me too, if people agree to have three
> branches.

As long as I am allowed to ignore the third branch completely I am fine with 
that.


Georg

Re: Tarballs for LyX 2.2.0 are on FTP

[Pavel Sanda]

Guillaume Munch wrote:
> Here's what I suggest. Let's do, on a trial basis for the duration of
> 2.3dev, a branch that mirrors master but inserts patches to disable the
> input and output of new file-format features (as well as layout changes,
> etc.) after each file-format change. We would see if the idea works out.
>
> I was going to do something like this anyway for myself, so I propose to
> take care of it until it gains some momentum. At first we could just
> make nightlies out of it for Ubuntu.
>
> One roadblock that I am expecting is that the author of the original
> file format change knows better than me how to block it, but in case of
> trouble I can ask for advice. I plan to include the patches responsible
> for file format changes and patch them afterwards, because otherwise I
> expect the code to diverge too much. If at some point it no longer works
> then I will stop.
>
> I will call the branch ?unstable?.
>
> Agreement? Suggestions?

So what is the goal here. Jut to get aditional testing from interested
parties or to make release from this branch at the end?

Pavel

Re: unique_ptr

[Guillaume Munch]

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

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.



When you have unique_ptr, you also want to have make_unique without
hassle. The reason is that apart from some corner cases, make_unique is
never really necessary, more of a convenience. So I prefer to have
unique_ptr.h open unique_ptr in the lyx namespace for me and only have
to include one header. But, you are always free to just include .

Re: Tarballs for LyX 2.2.0 are on FTP

[Guillaume Munch]

Le 07/06/2016 00:35, Guillaume Munch a écrit :

Le 07/06/2016 00:00, Richard Heck a écrit :

On 06/06/2016 06:40 PM, Guillaume Munch wrote:


The point of the proposal is to enabling the early testing and release
of *non-file-format* changes. Then for a proper master release only
file-format changes remain to be fully tested.


This assumes these aspects do not interact. Oftentimes, they do.

Our use of git would make it very easy for us to have a branch in which
new features not requiring format changes could also be put.



This solution would be fine by me too, if people agree to have three
branches.



Here's what I suggest. Let's do, on a trial basis for the duration of
2.3dev, a branch that mirrors master but inserts patches to disable the
input and output of new file-format features (as well as layout changes,
etc.) after each file-format change. We would see if the idea works out.

I was going to do something like this anyway for myself, so I propose to
take care of it until it gains some momentum. At first we could just
make nightlies out of it for Ubuntu.

One roadblock that I am expecting is that the author of the original
file format change knows better than me how to block it, but in case of
trouble I can ask for advice. I plan to include the patches responsible
for file format changes and patch them afterwards, because otherwise I
expect the code to diverge too much. If at some point it no longer works
then I will stop.

I will call the branch “unstable”.

Agreement? Suggestions?

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

[Georg Baum]

Scott Kostyshak wrote:

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

They don't need to do anything. Both with cmake and autotools you will get 
the message "A C++11 compatible compiler is required" if you try to build 
with a compiler which is too old. This is clear enough IMHO (and packagers 
will most likely not run into this problem anyway, all default compilers of 
all current linux distros are new enough).


Georg

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

[Kornel Benko]

Am Mittwoch, 8. Juni 2016 um 09:36:05, schrieb Kornel Benko 
> commit 8019732b395faa9fafe3b4c644cb72143bdd5dd1
> Author: Kornel Benko 
> Date:   Wed Jun 8 09:21:48 2016 +0200
> 
> Cmake build: Check for QPA_XCB when QT_USES_X11 is known
> 
> Since QT_USES_X11 is determined in ConfigureChecks
> we have to check after this call

This makes xmingw-script successful again. The fix should go to 2.2.x too IMHO.

Kornel

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