Re: State of master and release process

[Stephan Witt]

Am 17.02.2016 um 01:01 schrieb Uwe Stöhr :
> 
> Am 16.02.2016 um 20:06 schrieb Georg Baum:
> 
>> I would formulate it differently: There is a problem  with extracting the
>> tar with the tool Uwe used.
> 
> It is a simple path name length restriction. In the tar the path cannot be 
> longer than
> 
> lyx-2.2.0beta2\3rdparty\boost\boost\numeric\conversion\detail\preprocessed\numeric_cast_traits_long_
> 
> These are 100 characters. All paths longer than 100 chars are truncated. 
> Since Windows itself does not support tar, I use WinRar. Maybe this program 
> has a bug or the tar specs have a limitation on Windows.
> 
> However, the Zip is only 3 MB larger than the Tar. so why not using Zip in 
> future? I don't think that the 3 MB more are important.

Zip has another problem. The encoding of the file names is undefined.

Stephan

ANNOUNCE: LyX version 2.2.0 (beta 2)

[Scott Kostyshak]

Public release of LyX version 2.2.0beta2


We are proud to announce the second public beta release of the new LyX 2.2
series.

With this release, LyX celebrates 20 years of existence. The 2.2 series
has a rich set of new features compared to the current stable series.

LyX 2.2.0beta2 is the culmination of almost two years of hard work. An overview
of the new features can be found here:
  http://wiki.lyx.org/LyX/NewInLyX22

You can download LyX 2.2.0beta2 from ftp://ftp.lyx.org/pub/lyx/devel/.

We hope you will enjoy the result!

The file lib/RELEASE-NOTES lists some known issues and problems compared
to the current stable releases (LyX 2.1.x). We strongly recommend that
packagers of LyX on various platforms and distributions read this file.

As with any major release, this one comes with a lot of new features but
also some bugs. If you think you have found a bug in LyX 2.2.0, either
email the LyX developers' mailing list (lyx-devel at lists.lyx.org),
or open a bug report at http://www.lyx.org/trac/wiki/BugTrackerHome.

If you have trouble using LyX or have a question, consult the documentation
that comes with LyX (under Help) and the LyX wiki, which you will find at
http://wiki.lyx.org/. You can also send email to the LyX users'
list (lyx-users at lists.lyx.org).

NOTE 1 (for Autotools users):
"make distcheck" fails on some systems for this beta release. This means that
there will be difficulties to install on platforms that require this check to
pass before installing.

NOTE 2 (for Windows users):
There is a problem with extracting the tar with some Windows extraction
programs. Please extract from the zip, or use GNU tar to extract from the tar.
This note is only relevant if you are a Windows user and you would like to
compile from source.

The LyX team.
http://www.lyx.org


signature.asc
Description: PGP signature

Re: State of master and release process

[Scott Kostyshak]

On Wed, Feb 17, 2016 at 01:01:42AM +0100, Uwe Stöhr wrote:
> Am 16.02.2016 um 20:06 schrieb Georg Baum:
> 
> >I would formulate it differently: There is a problem  with extracting the
> >tar with the tool Uwe used.
> 
> It is a simple path name length restriction. In the tar the path cannot be
> longer than
> 
> lyx-2.2.0beta2\3rdparty\boost\boost\numeric\conversion\detail\preprocessed\numeric_cast_traits_long_
> 
> These are 100 characters. All paths longer than 100 chars are truncated.
> Since Windows itself does not support tar, I use WinRar. Maybe this program
> has a bug or the tar specs have a limitation on Windows.
> 
> However, the Zip is only 3 MB larger than the Tar. so why not using Zip in
> future? I don't think that the 3 MB more are important.

Hopefully the tar issue is fixed now. I think it would be nice to keep
using tar, since that is what we have been doing. If the tar does not
work for you though, then we should indeed consider using zip.

Scott


signature.asc
Description: PGP signature

Re: State of master and release process

[Scott Kostyshak]

On Tue, Feb 16, 2016 at 08:06:14PM +0100, Georg Baum wrote:
> Scott Kostyshak wrote:
> 
> > Just an update for those who have not been following the other
> > conversations, and also a question:
> > 
> > beta2 has been tagged, and the tars have been posted. We have not
> > formally released it because we are still trying to make it so that it
> > is possible to compile on Windows from the self-contained archive. There
> > is a problem with extracting the tar on Windows, so I have just sent Uwe
> > a zip file containing the same files that the tar contains.
> 
> I would formulate it differently: There is a problem  with extracting the 
> tar with the tool Uwe used. There are many utilities that support tar, and I 
> know that at least one (GNU tar on cygwin or from GnuWin32) can extract the 
> archive correctly. Maybe others understand it as well.

I see. I will put a note about this in the announcement email.

> > If the zip file extracts correctly and Uwe can compile for Windows, does
> > this mean that we should release beta2 as long as we post the zip file
> > and in the email announcement we recommend the zip file if compiling on
> > Windows?
> 
> I'd do that.

OK. I think Peter and Uwe support this so let's go forward with beta2. I
have uploaded the Windows and Mac binaries and will send the
announcement email soon.

> > Or because the tar has issues with being extracted on Windows,
> > we must move to beta3 which hopefully (still not confirmed) would
> > produce a tar that can be extracted correctly with the Windows build? A
> > separate question is does it matter that the 'make lyxdist' command for
> > beta2 did not produce the zip file that would be posted as beta2?
> 
> IMHO it does not matter. The important thing is that the files contained in 
> the zip and the tar are identical. How this is checked (manually or by 
> creating both with a Makefile rule) is not important. Also, I would consider 
> the tag in git the authorative source. I does not say anything about tar 
> packages. I think it is the jopb of the releases manager to ensure that the 
> published source archives are identical with the tagged git source.

Works for me.

> > It seems to me that although it is indicative of an inexperienced
> > release manager, the best thing would be to move to beta3, and confirm
> > with Uwe before posting the files that the archive can be extracted and
> > that the Windows build succeeds. I don't have a strong opinion on this
> > though.
> 
> I don't think it is needed. Using the better format for the next release (I 
> hope there will not be a beta 3) is good, but not required for beta2.

OK.

Scott


signature.asc
Description: PGP signature

Re: State of master and release process

[Scott Kostyshak]

On Tue, Feb 16, 2016 at 10:11:03AM +0100, Jean-Marc Lasgouttes wrote:
> Le 15/02/2016 22:33, Scott Kostyshak a écrit :
> >beta2 has been tagged, and the tars have been posted. We have not
> >formally released it because we are still trying to make it so that it
> >is possible to compile on Windows from the self-contained archive. There
> >is a problem with extracting the tar on Windows, so I have just sent Uwe
> >a zip file containing the same files that the tar contains.
> 
> Scott, Uwe, note that Peter changed the tar format at 1660e096c. It would be
> interesting to see whether Uwe can now open our regular tar files in
> windows.

Uwe I just sent you a link to test. Does it work for you?

Scott


signature.asc
Description: PGP signature

Re: Bug in Insert > Special Character > Symbols in beta1 & 2

[Scott Kostyshak]

On Tue, Feb 16, 2016 at 10:11:54AM +0100, Liviu Andronic wrote:
> On Tue, Feb 16, 2016 at 9:45 AM, Andrew Parsloe  wrote:
> > Insert > Special Character > Symbols displays the Basic Latin selection of
> > symbols on my system. I can choose other selections as expected, but
> > choosing the blank line at the head of the list (to display all symbols)
> > freezes LyX. This doesn't happen in 2.1.4,  but does in 2.2.0 beta1 and
> > beta2 (Uwe's installer of Friday, 12 February 2016) on windows 7.
> >
> I cannot confirm this with beta1 on Ubuntu - selecting the blank line
> in the combobox works fine and doesn't freeze LyX. This may be
> platform-specific.

Thanks for testing, Andrew. I can't reproduce this either, which is not
surprising because I have a similar setup to Liviu.

Uwe can you reproduce this?

Scott


signature.asc
Description: PGP signature

Re: State of master and release process

[Uwe Stöhr]

Am 16.02.2016 um 20:06 schrieb Georg Baum:


I would formulate it differently: There is a problem  with extracting the
tar with the tool Uwe used.


It is a simple path name length restriction. In the tar the path cannot 
be longer than


lyx-2.2.0beta2\3rdparty\boost\boost\numeric\conversion\detail\preprocessed\numeric_cast_traits_long_

These are 100 characters. All paths longer than 100 chars are truncated. 
Since Windows itself does not support tar, I use WinRar. Maybe this 
program has a bug or the tar specs have a limitation on Windows.


However, the Zip is only 3 MB larger than the Tar. so why not using Zip 
in future? I don't think that the 3 MB more are important.


regards Uwe

Re: 2.2.0beta1 tar balls are available

[Georg Baum]

Pavel Sanda wrote:

> Georg Baum wrote:
>> No, but I believe I know the reason: self made rounding in combination
>> with optimization (I created the test reference with a debug build).
>> Which compiler switches do you use?
> 
> -Wall -Wextra -std=c++11 -g -O2 -Wno-deprecated-declarations

I cannot reproduce using these flags with gcc 4.9.2.

>> I will have a look at this after the beta. My usual procedure is to use
>> the standard C99 function lround() for rounding, but MSVC10 does not have
>> it. Does it work with the attached patch?
> 
> The attached patch fixed the problem.

Good. I reworked it a little bit, since we have the same problem at other 
places as well. Apart from that, the patch does also fix the rounding in 
Length::inBP() for negative lengths.

Pavel, does it still fix the test for you? If yes, is it OK to go in?


Georgdiff --git a/src/Length.cpp b/src/Length.cpp
index 44c3c81..d862f40 100644
--- a/src/Length.cpp
+++ b/src/Length.cpp
@@ -23,6 +23,7 @@
 
 #include "support/docstream.h"
 #include "support/lstrings.h"
+#include "support/lyxlib.h"
 
 #include 
 #include 
@@ -215,7 +216,7 @@ int Length::inPixels(int text_width, int em_width_base) const
 
 	double const text_width_in = text_width / (zoom * dpi);
 	double const result = zoom * dpi * inInch(text_width_in, em_width_in);
-	return static_cast(result + ((result >= 0) ? 0.5 : -0.5));
+	return support::iround(result);
 }
 
 
@@ -311,7 +312,7 @@ int Length::inBP() const
 	double const text_width_in = 210.0 / 2.54; // assume A4
 	double const em_width_in = 10.0 / 72.27;
 	double result = 72.0 * inInch(text_width_in, em_width_in);
-	return static_cast(result + 0.5);
+	return support::iround(result);
 }
 
 
diff --git a/src/insets/InsetGraphics.cpp b/src/insets/InsetGraphics.cpp
index 555ece1..323eaac 100644
--- a/src/insets/InsetGraphics.cpp
+++ b/src/insets/InsetGraphics.cpp
@@ -438,7 +438,7 @@ docstring InsetGraphics::createDocBookAttributes() const
 	if (!params().scale.empty() && !float_equal(scl, 0.0, 0.05)) {
 		if (!float_equal(scl, 100.0, 0.05))
 			options << " scale=\""
-<< static_cast( (scl) + 0.5 )
+<< support::iround(scl)
 << "\" ";
 	} else {
 		if (!params().width.zero()) {
diff --git a/src/mathed/InsetMathChar.cpp b/src/mathed/InsetMathChar.cpp
index 558bcd1..713e135 100644
--- a/src/mathed/InsetMathChar.cpp
+++ b/src/mathed/InsetMathChar.cpp
@@ -26,6 +26,7 @@
 
 #include "support/debug.h"
 #include "support/lstrings.h"
+#include "support/lyxlib.h"
 #include "support/textutils.h"
 
 
@@ -77,9 +78,9 @@ void InsetMathChar::metrics(MetricsInfo & mi, Dimension & dim) const
 	}
 	int const em = mathed_font_em(mi.base.font);
 	if (isBinaryOp(char_))
-		dim.wid += static_cast(0.5*em+0.5);
+		dim.wid += support::iround(0.5 * em);
 	else if (char_ == '\'')
-		dim.wid += static_cast(0.1667*em+0.5);
+		dim.wid += support::iround(0.1667 * em);
 #else
 	whichFont(font_, code_, mi);
 	dim = theFontMetrics(font_).dimension(char_);
@@ -95,9 +96,9 @@ void InsetMathChar::draw(PainterInfo & pi, int x, int y) const
 	//lyxerr << "drawing '" << char_ << "' font: " << pi.base.fontname << std::endl;
 	int const em = mathed_font_em(pi.base.font);
 	if (isBinaryOp(char_))
-		x += static_cast(0.25*em+0.5);
+		x += support::iround(0.25 * em);
 	else if (char_ == '\'')
-		x += static_cast(0.0833*em+0.5);
+		x += support::iround(0.0833 * em);
 #if 1
 	if (char_ == '=' && has_math_fonts) {
 		FontSetChanger dummy(pi.base, "cmr");
diff --git a/src/mathed/InsetMathSymbol.cpp b/src/mathed/InsetMathSymbol.cpp
index 352352b..a160dec 100644
--- a/src/mathed/InsetMathSymbol.cpp
+++ b/src/mathed/InsetMathSymbol.cpp
@@ -21,6 +21,7 @@
 
 #include "support/debug.h"
 #include "support/docstream.h"
+#include "support/lyxlib.h"
 #include "support/textutils.h"
 
 #include 
@@ -80,9 +81,9 @@ void InsetMathSymbol::metrics(MetricsInfo & mi, Dimension & dim) const
 	}
 	// seperate things a bit
 	if (isRelOp())
-		dim.wid += static_cast(0.5 * em + 0.5);
+		dim.wid += support::iround(0.5 * em);
 	else
-		dim.wid += static_cast(0.1667 * em + 0.5);
+		dim.wid += support::iround(0.1667 * em);
 
 	scriptable_ = false;
 	if (mi.base.style == LM_ST_DISPLAY)
@@ -106,9 +107,9 @@ void InsetMathSymbol::draw(PainterInfo & pi, int x, int y) const
 	std::string const font = italic_upcase_greek ? "cmm" : sym_->inset;
 	int const em = mathed_font_em(pi.base.font);
 	if (isRelOp())
-		x += static_cast(0.25*em+0.5);
+		x += support::iround(0.25 * em);
 	else
-		x += static_cast(0.0833*em+0.5);
+		x += support::iround(0.0833 * em);
 
 	FontSetChanger dummy(pi.base, from_ascii(font));
 	pi.draw(x, y - h_, sym_->draw);
diff --git a/src/support/lstrings.cpp b/src/support/lstrings.cpp
index d06458b..f4aba23 100644
--- a/src/support/lstrings.cpp
+++ b/src/support/lstrings.cpp
@@ -16,13 +16,13 @@
 
 #include "support/convert.h"
 #include "support/debug.h"
+#include "support/lyxlib.h"
 #include "support/qstring_helpers.h"
 
 #include "support/lassert.h"
 
 #include 
 
-#include 
 

Re: 2.2.0beta1 tar balls are available

[Georg Baum]

Jean-Marc Lasgouttes wrote:

> Looks like there is an extra pair of parenthesis.

Thanks, I noticed that meanwhile as well. Update patch follows soon.


Georg

Re: [LyX/master] Add missing boost files to source package

[Georg Baum]

Peter Kümmel wrote:

> Am 15.02.2016 um 22:06 schrieb Georg Baum:
>>
> 
> Done .

Thanks.

>> What about the unused files libs/regex/regex.vcproj,
>> libs/signals/signals.vcproj, libs/regex/src/icu.cpp,
>> libs/regex/src/usinstances.cpp and libs/regex/src/wc_regex_traits.cpp?
>> I'd like to remove them from git.
> 
> I would not fiddle around with files distributed by boost.
> Just use all the files created by bcp/extract.sh.

Then we need to add them to the make rules. Currently they are not built, 
and having them in git, but not in the source packages, and not in the build 
does not make sense.


Georg

Re: State of master and release process

[Georg Baum]

Scott Kostyshak wrote:

> Just an update for those who have not been following the other
> conversations, and also a question:
> 
> beta2 has been tagged, and the tars have been posted. We have not
> formally released it because we are still trying to make it so that it
> is possible to compile on Windows from the self-contained archive. There
> is a problem with extracting the tar on Windows, so I have just sent Uwe
> a zip file containing the same files that the tar contains.

I would formulate it differently: There is a problem  with extracting the 
tar with the tool Uwe used. There are many utilities that support tar, and I 
know that at least one (GNU tar on cygwin or from GnuWin32) can extract the 
archive correctly. Maybe others understand it as well.

> If the zip file extracts correctly and Uwe can compile for Windows, does
> this mean that we should release beta2 as long as we post the zip file
> and in the email announcement we recommend the zip file if compiling on
> Windows?

I'd do that.

> Or because the tar has issues with being extracted on Windows,
> we must move to beta3 which hopefully (still not confirmed) would
> produce a tar that can be extracted correctly with the Windows build? A
> separate question is does it matter that the 'make lyxdist' command for
> beta2 did not produce the zip file that would be posted as beta2?

IMHO it does not matter. The important thing is that the files contained in 
the zip and the tar are identical. How this is checked (manually or by 
creating both with a Makefile rule) is not important. Also, I would consider 
the tag in git the authorative source. I does not say anything about tar 
packages. I think it is the jopb of the releases manager to ensure that the 
published source archives are identical with the tagged git source.

> It seems to me that although it is indicative of an inexperienced
> release manager, the best thing would be to move to beta3, and confirm
> with Uwe before posting the files that the archive can be extracted and
> that the Windows build succeeds. I don't have a strong opinion on this
> though.

I don't think it is needed. Using the better format for the next release (I 
hope there will not be a beta 3) is good, but not required for beta2.


Georg

Re: 2.2.0beta1 tar balls are available

[José Matos]

On Tuesday, February 09, 2016 10:18:10 PM Scott Kostyshak wrote:
> The tar balls and sig files are here:
> 
> https://www.dropbox.com/sh/y57gkjh8xo89ct4/AACbDGN83b4eq0cjkgR8tsq9a?dl=0
> 
> Packagers, please prepare your binaries.
> 
> Non-packagers, please do a quick test of compilation (from the tar ball) and
> basic functionality on your platform, and let us know how it goes.
> 
> Thank you all for your help,
> 
> Scott

Packages for Fedora are available at 
https://copr.fedorainfracloud.org/coprs/jamatos/lyx-next/

-- 
José Abílio

Re: clang doesn't like -std=c++11 for Objective C files

[Jean-Marc Lasgouttes]

Le 30/01/2016 09:55, pdv a écrit :

Hi,

Build under OS X fails with:

   CXX  userinfo.o
   CXX  unicode.o
   OBJC AppleSpeller.o
error: invalid argument '-std=c++11' not allowed with 'C/ObjC'

I moved the '-std=c++11' from the CPPFLAGS to the CXXFLAGS and defined
OBJCFLAGS.

(patch included)


Dear Patrick, dear Stephan,

Could you try the attached patch in C++11 mode?

JMarc





>From 399fbd5080bc23b5503491491f7643d9e15e9828 Mon Sep 17 00:00:00 2001
From: Jean-Marc Lasgouttes 
Date: Tue, 16 Feb 2016 15:31:08 +0100
Subject: [PATCH] Do not add -std=c++11 to CPPFLAGS (because objc does not
 like it)

Since at least gcc 4.6 requires it, -std=c++11 has been passed to CPPFLAGS at 39717adfd. This was deemed necessary so that tests that use the preprocessor directly (AC_CHECK_HEADER) can have the right information.

It turns out that CPPFLAGS gets passed to objc compilation too (on Mac OS X) and this create compile-time errors.

Therefore we remove the -std flag from CPPFLAGS and re-add it to a separate variable cxx11_flags that is passed to LYX_CXX_USE_REGEX.
---
 config/lyxinclude.m4 |   21 +++--
 1 file changed, 15 insertions(+), 6 deletions(-)

diff --git a/config/lyxinclude.m4 b/config/lyxinclude.m4
index 81e91ca..8decd37 100644
--- a/config/lyxinclude.m4
+++ b/config/lyxinclude.m4
@@ -168,13 +168,19 @@ AC_DEFUN([LYX_CXX_CXX11],
  lyx_use_cxx11=$lyx_cv_cxx_cxx11
 ])
 
+
+dnl Usage: LYX_CXX_USE_REGEX(cxx11_flags)
 dnl decide whether we want to use std::regex and set the
 dnl LYX_USE_STD_REGEX accordingly.
+dnl the extra cxx11 flags have to be passed to the preprocessor. They are
+dnl not plainly added to AM_CPPFLAGS because then the objc compiler (mac)
+dnl would fail.
 AC_DEFUN([LYX_CXX_USE_REGEX],
 [lyx_std_regex=no
  if test $lyx_use_cxx11 = yes; then
save_CPPFLAGS=$CPPFLAGS
-   CPPFLAGS="$AM_CPPFLAGS $CPPFLAGS"
+   # we want to pass -std=c++11 to clang/cpp if necessary
+   CPPFLAGS="$AM_CPPFLAGS $1 $CPPFLAGS"
save_CXXFLAGS=$CXXFLAGS
CXXFLAGS="$AM_CXXFLAGS $CXXFLAGS"
AC_LANG_PUSH(C++)
@@ -362,17 +368,20 @@ if test x$GXX = xyes; then
   4.3*|4.4*|4.5*|4.6*)
 dnl Note that this will define __GXX_EXPERIMENTAL_CXX0X__.
 dnl The source code relies on that.
-AM_CPPFLAGS="$AM_CPPFLAGS -std=c++0x";;
+cxx11_flags="-std=c++0x";;
   clang)
 dnl presumably all clang versions support c++11.
 	dnl the deprecated-register warning is very annoying with Qt4.x right now.
-AM_CPPFLAGS="$AM_CPPFLAGS -std=c++11"
+cxx11_flags="-std=c++11"
 AM_CXXFLAGS="$AM_CXXFLAGS -Wno-deprecated-register";;
   *)
 AS_CASE([$host], [*cygwin*],
-[AM_CPPFLAGS="$AM_CPPFLAGS -std=gnu++11"],
-[AM_CPPFLAGS="$AM_CPPFLAGS -std=c++11"]);;
+[cxx11_flags="-std=gnu++11"],
+[cxx11_flags="-std=c++11"]);;
 esac
+# cxx11_flags is useful when running preprocessor alone 
+# (see detection of regex).
+AM_CXXFLAGS="$cxx11_flags $AM_CXXFLAGS"
   fi
 fi
 
@@ -383,7 +392,7 @@ if test $lyx_use_cxx11 = yes; then
 AM_CXXFLAGS="$AM_CXXFLAGS -Wno-deprecated-declarations"
   fi
 fi
-LYX_CXX_USE_REGEX
+LYX_CXX_USE_REGEX([$cxx11_flags])
 ])
 
 dnl Usage: LYX_USE_INCLUDED_BOOST : select if the included boost should
-- 
1.7.9.5

Re: [LyX/master] Add missing boost files to source package

[Peter Kümmel]

Am 15.02.2016 um 22:06 schrieb Georg Baum:

Peter Kümmel wrote:


commit 6de524e6cf2d13636b04b9bb850d0a8b1eaa398b
Author: Peter Kümmel 
Date:   Sat Feb 13 18:34:08 2016 +0100

 Add missing boost files to source package

 and remove Visual Studio files, we build with CMake on Windows.

diff --git a/3rdparty/boost/Makefile.am b/3rdparty/boost/Makefile.am
index cfac86b..fcb9ff7 100644
--- a/3rdparty/boost/Makefile.am
+++ b/3rdparty/boost/Makefile.am
@@ -4,13 +4,14 @@ noinst_LIBRARIES = liblyxboost.a

  EXTRA_DIST = boost \
  CMakeLists.txt \
+   LICENSE_1_0.txt \
  libs/CMakeLists.txt \
  libs/regex/CMakeLists.txt \
-   libs/regex/regex.vcproj \
  libs/regex/src/CMakeLists.txt \
  libs/signals/CMakeLists.txt \
-   libs/signals/signals.vcproj \
-   libs/signals/src/CMakeLists.txt
+   libs/signals/src/CMakeLists.txt \
+


boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_common.hpp

\
+


boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp



Done .


These two additions are not needed, right? At least the files appear in the
tar also before this changes.

What about the unused files libs/regex/regex.vcproj,
libs/signals/signals.vcproj, libs/regex/src/icu.cpp,
libs/regex/src/usinstances.cpp and libs/regex/src/wc_regex_traits.cpp? I'd
like to remove them from git.


I would not fiddle around with files distributed by boost.
Just use all the files created by bcp/extract.sh.

Peter




Georg

Re: State of master and release process

[Peter Kümmel]

Am 15.02.2016 um 22:33 schrieb Scott Kostyshak:

Just an update for those who have not been following the other
conversations, and also a question:

beta2 has been tagged, and the tars have been posted. We have not
formally released it because we are still trying to make it so that it
is possible to compile on Windows from the self-contained archive. There
is a problem with extracting the tar on Windows, so I have just sent Uwe
a zip file containing the same files that the tar contains.

If the zip file extracts correctly and Uwe can compile for Windows, does
this mean that we should release beta2 as long as we post the zip file
and in the email announcement we recommend the zip file if compiling on
Windows? Or because the tar has issues with being extracted on Windows,
we must move to beta3 which hopefully (still not confirmed) would
produce a tar that can be extracted correctly with the Windows build? A
separate question is does it matter that the 'make lyxdist' command for
beta2 did not produce the zip file that would be posted as beta2?

It seems to me that although it is indicative of an inexperienced
release manager, the best thing would be to move to beta3, and confirm
with Uwe before posting the files that the archive can be extracted and
that the Windows build succeeds. I don't have a strong opinion on this
though.

On a separate note, master branch is open. Depending on the above
discussion we might move very soon to beta3, so please nothing
non-trivial.

Scott



I would say: release tag 2.2.0beta2.
There is only the problem with untaring on Windows

For beta3:

- add zip to lyxdist
- some cleanup in boost

Peter

Referencing subnumbered equations

[Andrew Parsloe]

Hullo Uwe,

The math manual, section 19.3, gives a method for numbering and 
referencing subnumbered equations so that although the equations are 
numbered, e.g., (1a), (1b), (1c), it is possible to reference them 
collectively, e.g. as the equations (1) (without the a, b, c).  The 
method seems "messy". After a lot of bumbling about, I've discovered a 
much simpler (and in hindsight obvious) way of doing this. One inserts 
in ERT \begin{subequations} as before, exits the ERT inset and 
immediately inserts a label (using the toolbar button) and after that 
inserts the subnumbered equations, numbers them (Alt+M N), finishing 
with \end{subequations} in ERT. The label doesn't have the "eq:" prefix, 
you have to write that yourself, but when you reference it, it gives (1) 
(or whatever the equation number is) without the a, b, c, etc. of the 
subequations.


In fact by adding

Format 59


Style Subequations

LatexType Environment

LatexName subequations

RefPrefix eq

Align right

End


in the local layout window I get the "eq" prefix on the label and remove 
the need for any ERT at all. I think it would be worth building this 
into LyX (like the other AMS environments).



Andrew

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

Re: 2.2.0beta1 tar balls are available

[Jean-Marc Lasgouttes]

Le 11/02/2016 21:54, Georg Baum a écrit :

I will have a look at this after the beta. My usual procedure is to use the
standard C99 function lround() for rounding, but MSVC10 does not have it.
Does it work with the attached patch?


-   return static_cast(result + ((result >= 0) ? 0.5 : -0.5));
+   return static_cast((round(result)));

Looks like there is an extra pair of parenthesis.

JMarc

Re: beta2?

[Jean-Marc Lasgouttes]

Le 15/02/2016 21:20, Uwe Stöhr a écrit :

Am 15.02.2016 um 11:18 schrieb Jean-Marc Lasgouttes:


BTW, why don't you use lzma for the compression of the installer?


I do. Otherwise the installer for the betas would be 69 MB large.


Does it mean that it is the
  SetCompressor /SOLID lzma
in include/declarations.nsh.cmake (but not in include/declarations.nsh, 
why?) that sets compression?


In this case the explicit setting (active and commented out) in the 3 
nsi files should be removed for clarity.


JMarc

Re: Bug in Insert > Special Character > Symbols in beta1 & 2

[Liviu Andronic]

On Tue, Feb 16, 2016 at 9:45 AM, Andrew Parsloe  wrote:
> Insert > Special Character > Symbols displays the Basic Latin selection of
> symbols on my system. I can choose other selections as expected, but
> choosing the blank line at the head of the list (to display all symbols)
> freezes LyX. This doesn't happen in 2.1.4,  but does in 2.2.0 beta1 and
> beta2 (Uwe's installer of Friday, 12 February 2016) on windows 7.
>
I cannot confirm this with beta1 on Ubuntu - selecting the blank line
in the combobox works fine and doesn't freeze LyX. This may be
platform-specific.

Liviu


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



-- 
Do you think you know what math is?
http://www.ideasroadshow.com/issues/ian-stewart-2013-08-02
Or what it means to be intelligent?
http://www.ideasroadshow.com/issues/john-duncan-2013-08-30
Think again:
http://www.ideasroadshow.com/library

Re: State of master and release process

[Jean-Marc Lasgouttes]

Le 15/02/2016 22:33, Scott Kostyshak a écrit :

beta2 has been tagged, and the tars have been posted. We have not
formally released it because we are still trying to make it so that it
is possible to compile on Windows from the self-contained archive. There
is a problem with extracting the tar on Windows, so I have just sent Uwe
a zip file containing the same files that the tar contains.


Scott, Uwe, note that Peter changed the tar format at 1660e096c. It 
would be interesting to see whether Uwe can now open our regular tar 
files in windows.


JMarc

Bug in Insert > Special Character > Symbols in beta1 & 2

[Andrew Parsloe]

Insert > Special Character > Symbols displays the Basic Latin selection 
of symbols on my system. I can choose other selections as expected, but 
choosing the blank line at the head of the list (to display all symbols) 
freezes LyX. This doesn't happen in 2.1.4,  but does in 2.2.0 beta1 and 
beta2 (Uwe's installer of Friday, 12 February 2016) on windows 7.


Andrew

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