Re: beta2?
Peter Kümmel wrote: Uwe still gets the following errors from the tar I sent to him: D:\LyXGit\LyX22beta3\3rdparty\boost\boost/numeric/conversion/detail/numeric_cast_traits.hpp(12): fatal error C1083: File (Include) cannot be opened: "boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_common.hpp": No such file or directory [D:\LyXGit\LyX22beta3\compile-2010\src\support\support.vcxproj] > > I only tested with "build5-2010-installer.bat" Is this script now used to build official installer? In case of yes, would be our cmake gurus able to add routine which spits out md5sum of installer binaries which could Uwe posts in his email when publishing the binaries? Pavel
Re: beta2?
Uwe Stöhr wrote: > Yes, a zip would be fine. I don't think that we need to save a few kB by > using special formats like .xz. For the record .xz is pretty standard in open source releases and it saves 9mb from 20mb gzips (and 21mb from 31 .zip I just experimentally tried). This is not few kb. But this is most probably offtopic anyway, because the problem is with tar, not zip. I seem to remember that we fixed this problem by deleting boost files which were not by acident needed, the current approach looks much better. Pavel
Re: 2.2.0beta1 tar balls are available
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 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. Pavel
Re: [LyX/master] Partial fix for #9740 "XeTeX/LuaTeX with TeX fonts problems".
On Sun, Feb 14, 2016 at 08:49:26PM +, Guenter Milde wrote: > However, I can confirm that the changes are intended. Thanks for checking. Scott signature.asc Description: PGP signature
Re: beta2?
On Mon, Feb 15, 2016 at 12:55:47AM +0100, Uwe Stöhr wrote: > Am 14.02.2016 um 19:44 schrieb Peter Kümmel: > > >So the unzip tool has a problem, maybe because of the long path length. > > > >Maybe we should also distribute a zip file. > > Yes, a zip would be fine. I don't think that we need to save a few kB by > using special formats like .xz. > > Scott, could you please upload a zip file so that I can see if this fixes te > problems. OK I sent it you. Scott signature.asc Description: PGP signature
Re: beta2?
Am 14.02.2016 um 19:44 schrieb Peter Kümmel: So the unzip tool has a problem, maybe because of the long path length. Maybe we should also distribute a zip file. Yes, a zip would be fine. I don't think that we need to save a few kB by using special formats like .xz. Scott, could you please upload a zip file so that I can see if this fixes te problems. thanks and regards Uwe
Re: beta2?
Am 14.02.2016 um 21:27 schrieb Jean-Marc Lasgouttes: Le 14/02/16 19:54, Georg Baum a écrit : Peter Kümmel wrote: Am 14.02.2016 um 19:03 schrieb Scott Kostyshak: Why is numeric_cast_traits_common.hpp not being found? Have you checked if it's part of the tar you send to Uwe? The files I listed above are part of the tar. I will send the tar to you privately. That explains why they did not show up in my comparison of the beta1 tar and the git tree. I did not really understand why I could have missed them. Probably related to this commit: commit 5287f1c8b6a9e719492cf7350c304efb978c664c Author: Peter Kümmel Date: Sun Dec 20 13:32:33 2015 +0100 default tar-v7 format supports only 99 character pathes We use tar-pax now, and it might not be handled very well by some old utilities. From what is said here https://www.gnu.org/software/automake/manual/html_node/List-of-Automake-options.html I believe that "ustar" would have been a better alternative. Thanks for this hint! I've tested it with ustar and it is indeed the better choice. I've committed the change to ustar. Peter JMarc
Re: [LyX/master] Partial fix for #9740 "XeTeX/LuaTeX with TeX fonts problems".
On 2016-02-14, Georg Baum wrote:
> Scott Kostyshak wrote:
>> On Sat, Feb 13, 2016 at 08:54:57PM +, Guenter Milde wrote:
>>> On 2016-02-13, Scott Kostyshak wrote:
>>> > After this commit, when I run the command
>>> > lyx -e luatex lib/doc/he/Intro.lyx
>>> > it either fails to produce Intro.tex or (on current master) it produces
>>> > a Intro.tex with gibberish where there should be Hebrew (at least this
>>> > is what Vim shows me).
> It is not gibberish. vim fails to detect the encoding cp1255. If you open
> the file with kate it correctly detects the encoding and displays hebrew
> text.
Thanks for finding this out.
>> Do you think it is OK that we now produce splash_bad.tex and before we
>> produced splash_good.tex? If you tell me this is fine and that there
>> is no encoding issue, then I trust your judgment since I know nothing
>> about encoding.
> Attached is a diff that was produced after converting the utf8 encoded file
> to cp1255:
> recode utf8..cp1255 < heb1.tex > heb1-cp1255.tex
> diff -ub heb2.tex heb1-cp1255.tex > x.diff
I assume, heb1.tex is "splash_good.tex" and heb2.tex is "splash_bad.tex",
right?
> So, the real diferences of this change are:
> 1) LyX writes cp1255 encoding instead of utf8
Yes. This is intended -- if document source is set to use 8-bit TeX fonts,
the input encoding should be the same for pdftex and luatex.
(Before, it was forced to be utf8-plain with luatex and xetex, which led to
many errors (or wrong output).)
> 2) LyX adds a \cyrtext command
If I read the diff correctly, the \cyrtext was added before (heb1) but is
now only added if required.
> I don't know if 1) is wanted, but the way it is done is correct: The file is
> written in cp1255 encoding, and luainputenc is loaded with the same
> encoding.
> 2) looks unnneeded to me.
This is fixed sice some months now.
> Obviously, luatex+hebrew is not completely broken, since the utf8 version
> worked.
Did the utf8 version actually compile and give the correct result?
> What is the advantage of using cp1255 instead of utf8 now?
Less surprise for the user: if the document is set to use "language
default", is uses "language default" (which is cp1255 for Hebrew).
If the document is set to use utf8, it uses utf8.
The advantage might not be visible in this example, but, e.g. with external
files (bibtex, ...) the encoding of the generated latex source can be
important.
> --- heb2.tex 2016-02-14 10:35:23.083348413 +0100
> +++ heb1-cp1255.tex 2016-02-14 10:51:29.859358650 +0100
> @@ -2,7 +2,7 @@
> %% Do not edit unless you really know what you are doing.
> \documentclass[english,hebrew]{article}
> \usepackage[T1]{fontenc}
> -\usepackage[cp1255]{luainputenc}
> +\usepackage[utf8]{luainputenc}
> \usepackage{url}
> \usepackage{amssymb}
> @@ -10,6 +10,10 @@
> %% LyX specific LaTeX commands.
> \providecommand{\LyX}{L\kern-.1667em\lower.25em\hbox{Y}\kern-.125emX\@}
> +\DeclareRobustCommand{\cyrtext}{%
> + \fontencoding{T2A}\selectfont\def\encodingdefault{T2A}}
> +\DeclareRobustCommand{\textcyr}[1]{\leavevmode{\cyrtext #1}}
> +
> %% Textclass specific LaTeX commands.
> \usepackage{theorem}
This does not solve the case of not-working LaTeX export.
However, I can confirm that the changes are intended.
(The disadvantages of the current input encoding default are a different
topic that are handled in a different bug report ...)
Thanks,
Günter
Re: beta2?
Le 14/02/16 19:54, Georg Baum a écrit : Peter Kümmel wrote: Am 14.02.2016 um 19:03 schrieb Scott Kostyshak: Why is numeric_cast_traits_common.hpp not being found? Have you checked if it's part of the tar you send to Uwe? The files I listed above are part of the tar. I will send the tar to you privately. That explains why they did not show up in my comparison of the beta1 tar and the git tree. I did not really understand why I could have missed them. Probably related to this commit: commit 5287f1c8b6a9e719492cf7350c304efb978c664c Author: Peter Kümmel Date: Sun Dec 20 13:32:33 2015 +0100 default tar-v7 format supports only 99 character pathes We use tar-pax now, and it might not be handled very well by some old utilities. From what is said here https://www.gnu.org/software/automake/manual/html_node/List-of-Automake-options.html I believe that "ustar" would have been a better alternative. JMarc
Re: beta2?
Peter Kümmel wrote: > Am 14.02.2016 um 19:03 schrieb Scott Kostyshak: Why is numeric_cast_traits_common.hpp not being found? >>> >>> Have you checked if it's part of the tar you send to Uwe? >> >> The files I listed above are part of the tar. I will send the tar to you >> privately. That explains why they did not show up in my comparison of the beta1 tar and the git tree. I did not really understand why I could have missed them. > When I unpack with WinRAR it looks like this > > $ ls -l 3rdparty/boost/boost/numeric/conversion/detail/preprocessed/ > total 56 > -rw-r--r-- 1 numeric_cast_traits_commo > -rw-r--r-- 1 numeric_cast_traits_long_ > > and when I run "tar vxf lyx-2.2.0beta3.tar.gz" from the git console it is > ok. > > So the unzip tool has a problem, maybe because of the long path length. Probably. The good news is that we do not need a beta3, simply unpacking beta2 with a different method should be OK. Georg
Re: beta2?
Am 14.02.2016 um 19:03 schrieb Scott Kostyshak: Why is numeric_cast_traits_common.hpp not being found? Have you checked if it's part of the tar you send to Uwe? The files I listed above are part of the tar. I will send the tar to you privately. When I unpack with WinRAR it looks like this $ ls -l 3rdparty/boost/boost/numeric/conversion/detail/preprocessed/ total 56 -rw-r--r-- 1 numeric_cast_traits_commo -rw-r--r-- 1 numeric_cast_traits_long_ and when I run "tar vxf lyx-2.2.0beta3.tar.gz" from the git console it is ok. So the unzip tool has a problem, maybe because of the long path length. Maybe we should also distribute a zip file. Scott
Re: beta2?
Am 14.02.2016 um 19:03 schrieb Scott Kostyshak: On Sun, Feb 14, 2016 at 06:36:15PM +0100, Peter Kümmel wrote: Am 14.02.2016 um 17:17 schrieb Scott Kostyshak: On Sat, Feb 13, 2016 at 01:44:30PM -0500, Scott Kostyshak wrote: On Sat, Feb 13, 2016 at 01:24:20PM -0500, Scott Kostyshak wrote: On Sat, Feb 13, 2016 at 07:11:48PM +0100, Uwe Stöhr wrote: Am 13.02.2016 um 18:01 schrieb Scott Kostyshak: Thanks for testing, Peter. I'll wait for a fix, and then I suppose we move to beta3? Sorry, but why do we act like beginners? I wrote what is missing in the tarball. So why not add these files, send me the tarball by private mail to check and then announce a new beta You are right that this is what I should have done for beta2. I will do this now before releasing beta3. I'll build the tar and send it to you privately. After you confirm that you can compile the Windows build from only the tar, I will post the tar and push the git tag and git commits. I've sent the tars to you privately. Can you do a fresh build from them? Uwe still gets the following errors from the tar I sent to him: D:\LyXGit\LyX22beta3\3rdparty\boost\boost/numeric/conversion/detail/numeric_cast_traits.hpp(12): fatal error C1083: File (Include) cannot be opened: "boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_common.hpp": No such file or directory [D:\LyXGit\LyX22beta3\compile-2010\src\support\support.vcxproj] I only tested with "build5-2010-installer.bat" I was hoping that 6de524e6 fixed these. Is there still something we need to do? Looking in the tar, I see ./3rdparty/boost/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp ./3rdparty/boost/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_common.hpp ./3rdparty/boost/boost/numeric/conversion/detail/numeric_cast_traits.hpp ./3rdparty/boost/boost/numeric/conversion/numeric_cast_traits.hpp Why is numeric_cast_traits_common.hpp not being found? Have you checked if it's part of the tar you send to Uwe? The files I listed above are part of the tar. I will send the tar to you privately. Scott
Re: beta2?
On Sun, Feb 14, 2016 at 06:36:15PM +0100, Peter Kümmel wrote: > > > Am 14.02.2016 um 17:17 schrieb Scott Kostyshak: > >On Sat, Feb 13, 2016 at 01:44:30PM -0500, Scott Kostyshak wrote: > >>On Sat, Feb 13, 2016 at 01:24:20PM -0500, Scott Kostyshak wrote: > >>>On Sat, Feb 13, 2016 at 07:11:48PM +0100, Uwe Stöhr wrote: > Am 13.02.2016 um 18:01 schrieb Scott Kostyshak: > > >Thanks for testing, Peter. I'll wait for a fix, and then I suppose we > >move to beta3? > > Sorry, but why do we act like beginners? > > I wrote what is missing in the tarball. So why not add these files, send > me > the tarball by private mail to check and then announce a new beta > >>> > >>>You are right that this is what I should have done for beta2. I will do > >>>this now before releasing beta3. I'll build the tar and send it to you > >>>privately. After you confirm that you can compile the Windows build from > >>>only the tar, I will post the tar and push the git tag and git commits. > >> > >>I've sent the tars to you privately. Can you do a fresh build from them? > > > >Uwe still gets the following errors from the tar I sent to him: > > > >D:\LyXGit\LyX22beta3\3rdparty\boost\boost/numeric/conversion/detail/numeric_cast_traits.hpp(12): > >fatal error C1083: File (Include) cannot be opened: > >"boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_common.hpp": > >No such file or directory > >[D:\LyXGit\LyX22beta3\compile-2010\src\support\support.vcxproj] > > > >I was hoping that 6de524e6 fixed these. Is there still something we > >need to do? Looking in the tar, I see > > > >./3rdparty/boost/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp > >./3rdparty/boost/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_common.hpp > >./3rdparty/boost/boost/numeric/conversion/detail/numeric_cast_traits.hpp > >./3rdparty/boost/boost/numeric/conversion/numeric_cast_traits.hpp > > > >Why is numeric_cast_traits_common.hpp not being found? > > Have you checked if it's part of the tar you send to Uwe? The files I listed above are part of the tar. I will send the tar to you privately. Scott signature.asc Description: PGP signature
Re: beta2?
Am 14.02.2016 um 17:17 schrieb Scott Kostyshak: On Sat, Feb 13, 2016 at 01:44:30PM -0500, Scott Kostyshak wrote: On Sat, Feb 13, 2016 at 01:24:20PM -0500, Scott Kostyshak wrote: On Sat, Feb 13, 2016 at 07:11:48PM +0100, Uwe Stöhr wrote: Am 13.02.2016 um 18:01 schrieb Scott Kostyshak: Thanks for testing, Peter. I'll wait for a fix, and then I suppose we move to beta3? Sorry, but why do we act like beginners? I wrote what is missing in the tarball. So why not add these files, send me the tarball by private mail to check and then announce a new beta You are right that this is what I should have done for beta2. I will do this now before releasing beta3. I'll build the tar and send it to you privately. After you confirm that you can compile the Windows build from only the tar, I will post the tar and push the git tag and git commits. I've sent the tars to you privately. Can you do a fresh build from them? Uwe still gets the following errors from the tar I sent to him: D:\LyXGit\LyX22beta3\3rdparty\boost\boost/numeric/conversion/detail/numeric_cast_traits.hpp(12): fatal error C1083: File (Include) cannot be opened: "boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_common.hpp": No such file or directory [D:\LyXGit\LyX22beta3\compile-2010\src\support\support.vcxproj] I was hoping that 6de524e6 fixed these. Is there still something we need to do? Looking in the tar, I see ./3rdparty/boost/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp ./3rdparty/boost/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_common.hpp ./3rdparty/boost/boost/numeric/conversion/detail/numeric_cast_traits.hpp ./3rdparty/boost/boost/numeric/conversion/numeric_cast_traits.hpp Why is numeric_cast_traits_common.hpp not being found? Have you checked if it's part of the tar you send to Uwe? Here make lyxdist adds it to the tar. Scott
Re: [LyX/master] Partial fix for #9740 "XeTeX/LuaTeX with TeX fonts problems".
On Sun, Feb 14, 2016 at 11:01:06AM +0100, Georg Baum wrote: > Scott Kostyshak wrote: > > > On Sat, Feb 13, 2016 at 08:54:57PM +, Guenter Milde wrote: > >> On 2016-02-13, Scott Kostyshak wrote: > >> > >> > After this commit, when I run the command > >> > >> > lyx -e luatex lib/doc/he/Intro.lyx > >> > >> > it either fails to produce Intro.tex or (on current master) it produces > >> > a Intro.tex with gibberish where there should be Hebrew (at least this > >> > is what Vim shows me). > > It is not gibberish. vim fails to detect the encoding cp1255. If you open > the file with kate it correctly detects the encoding and displays hebrew > text. OK I see. > >> No, as Luatex+Hebrew failing is an upstream bug. > > > > But I am just talking about exporting to .tex and opening in a text > > editor. LuaTeX does not even have a chance if our export to .tex > > corrupts the Hebrew. To be clear, attached are splash_good.tex and > > splash_bad.tex. Do you think it is OK that we now produce splash_bad.tex > > and before we produced splash_good.tex? If you tell me this is fine and > > that there is no encoding issue, then I trust your judgment since I > > know nothing about encoding. > > Attached is a diff that was produced after converting the utf8 encoded file > to cp1255: > > recode utf8..cp1255 < heb1.tex > heb1-cp1255.tex > diff -ub heb2.tex heb1-cp1255.tex > x.diff > > (recode adds windows line ends, therefore the -b argument for diff) Thanks for walking me through this. I did not know about recode. > So, the real diferences of this change are: > > 1) LyX writes cp1255 encoding instead of utf8 > > 2) LyX adds a \cyrtext command > > I don't know if 1) is wanted, but the way it is done is correct: The file is > written in cp1255 encoding, and luainputenc is loaded with the same > encoding. 2) looks unnneeded to me. > > Obviously, luatex+hebrew is not completely broken, since the utf8 version > worked. What is the advantage of using cp1255 instead of utf8 now? Thanks for looking into this. Scott signature.asc Description: PGP signature
Re: beta2?
On Sat, Feb 13, 2016 at 01:44:30PM -0500, Scott Kostyshak wrote: > On Sat, Feb 13, 2016 at 01:24:20PM -0500, Scott Kostyshak wrote: > > On Sat, Feb 13, 2016 at 07:11:48PM +0100, Uwe Stöhr wrote: > > > Am 13.02.2016 um 18:01 schrieb Scott Kostyshak: > > > > > > >Thanks for testing, Peter. I'll wait for a fix, and then I suppose we > > > >move to beta3? > > > > > > Sorry, but why do we act like beginners? > > > > > > I wrote what is missing in the tarball. So why not add these files, send > > > me > > > the tarball by private mail to check and then announce a new beta > > > > You are right that this is what I should have done for beta2. I will do > > this now before releasing beta3. I'll build the tar and send it to you > > privately. After you confirm that you can compile the Windows build from > > only the tar, I will post the tar and push the git tag and git commits. > > I've sent the tars to you privately. Can you do a fresh build from them? Uwe still gets the following errors from the tar I sent to him: D:\LyXGit\LyX22beta3\3rdparty\boost\boost/numeric/conversion/detail/numeric_cast_traits.hpp(12): fatal error C1083: File (Include) cannot be opened: "boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_common.hpp": No such file or directory [D:\LyXGit\LyX22beta3\compile-2010\src\support\support.vcxproj] I was hoping that 6de524e6 fixed these. Is there still something we need to do? Looking in the tar, I see ./3rdparty/boost/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp ./3rdparty/boost/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_common.hpp ./3rdparty/boost/boost/numeric/conversion/detail/numeric_cast_traits.hpp ./3rdparty/boost/boost/numeric/conversion/numeric_cast_traits.hpp Why is numeric_cast_traits_common.hpp not being found? Scott signature.asc Description: PGP signature
Re: [LyX/master] Partial fix for #9740 "XeTeX/LuaTeX with TeX fonts problems".
Scott Kostyshak wrote:
> On Sat, Feb 13, 2016 at 08:54:57PM +, Guenter Milde wrote:
>> On 2016-02-13, Scott Kostyshak wrote:
>>
>> > After this commit, when I run the command
>>
>> > lyx -e luatex lib/doc/he/Intro.lyx
>>
>> > it either fails to produce Intro.tex or (on current master) it produces
>> > a Intro.tex with gibberish where there should be Hebrew (at least this
>> > is what Vim shows me).
It is not gibberish. vim fails to detect the encoding cp1255. If you open
the file with kate it correctly detects the encoding and displays hebrew
text.
>> No, as Luatex+Hebrew failing is an upstream bug.
>
> But I am just talking about exporting to .tex and opening in a text
> editor. LuaTeX does not even have a chance if our export to .tex
> corrupts the Hebrew. To be clear, attached are splash_good.tex and
> splash_bad.tex. Do you think it is OK that we now produce splash_bad.tex
> and before we produced splash_good.tex? If you tell me this is fine and
> that there is no encoding issue, then I trust your judgment since I
> know nothing about encoding.
Attached is a diff that was produced after converting the utf8 encoded file
to cp1255:
recode utf8..cp1255 < heb1.tex > heb1-cp1255.tex
diff -ub heb2.tex heb1-cp1255.tex > x.diff
(recode adds windows line ends, therefore the -b argument for diff)
So, the real diferences of this change are:
1) LyX writes cp1255 encoding instead of utf8
2) LyX adds a \cyrtext command
I don't know if 1) is wanted, but the way it is done is correct: The file is
written in cp1255 encoding, and luainputenc is loaded with the same
encoding. 2) looks unnneeded to me.
Obviously, luatex+hebrew is not completely broken, since the utf8 version
worked. What is the advantage of using cp1255 instead of utf8 now?
Georg
--- heb2.tex 2016-02-14 10:35:23.083348413 +0100
+++ heb1-cp1255.tex 2016-02-14 10:51:29.859358650 +0100
@@ -2,7 +2,7 @@
%% Do not edit unless you really know what you are doing.
\documentclass[english,hebrew]{article}
\usepackage[T1]{fontenc}
-\usepackage[cp1255]{luainputenc}
+\usepackage[utf8]{luainputenc}
\usepackage{url}
\usepackage{amssymb}
@@ -10,6 +10,10 @@
%% LyX specific LaTeX commands.
\providecommand{\LyX}{L\kern-.1667em\lower.25em\hbox{Y}\kern-.125emX\@}
+\DeclareRobustCommand{\cyrtext}{%
+ \fontencoding{T2A}\selectfont\def\encodingdefault{T2A}}
+\DeclareRobustCommand{\textcyr}[1]{\leavevmode{\cyrtext #1}}
+
%% Textclass specific LaTeX commands.
\usepackage{theorem}
