Re: configure.py regression in RC1 compared to beta

2017-10-28 Thread Scott Kostyshak 
On Sat, Oct 28, 2017 at 05:25:46PM +, Jürgen Spitzmüller wrote:
> Am Samstag, den 28.10.2017, 18:49 +0200 schrieb Uwe Stöhr:
> > El 28.10.2017 a las 14:05, Jürgen Spitzmüller escribió:
> > 
> > > > How can we fix this?
> > > 
> > > If it turns out that Inkscape on Windows cannot deal with paths we
> > > need
> > > to introduce a function for configure.py that returns full path or
> > > only
> > > file name depending on the OS.
> > 
> > I think this is the problem as far as I investigated now.
> > OK, I was not yet able to check if the path behind $$p is quoted or 
> > note. If not this would explain why it fails on Windows.
> 
> It should be quoted. You can check via the messages pane.

So this issue breaks conversion of SVG, EMF, and WMF images for all
Windows users? That is concerning.

I think that many would be able to test without running into this issue
because most users do not have SVG, EMF, and WMF images in their
documents; but I think that many also do have them. Further, it is bad
that users will get errors when compiling the manuals.

I think that this is the type of issue that would not necessarily be a
beta-blocker but that should be an rc-blocker. Indeed, we prioritized
fixing SVG conversion on Mac before rc1, which we did; so I suppose we
should consider this as an rc1-blocker.

Any thoughts on whether this should be an rc1 blocker?

Scott


signature.asc
Description: PGP signature

Re: Go forward with 2.3.0rc1 despite potential data loss from changes to dashes?

2017-10-28 Thread Scott Kostyshak 
On Sat, Oct 28, 2017 at 10:09:32AM +, Guenter Milde wrote:
> On 2017-10-27, Scott Kostyshak wrote:
> 
> > [-- Type: text/plain, Encoding:  --]
> 
> > Dear all,
> 
> > Because of the dashes and ZWSP situation, we do not produce an
> > equivalent document in some cases (I'm still curious for a definition of
> > what an "equivalent" document specifically means). 
> 
> I would define "equivalent" as "produces the same output".
> (This leaves still some twiggle room like "latex output or pdf output?".)
> 
> We violated this "equivalence principle" in 2.3: while literal and ligature 
> dashes use the
> same charcter in PDF, the difference in latex resulted in different line
> breaks in some occasions.
> 
> We violate this "equivalence principle" again in 2.3rc1 not only because of
> ZWSP, but also because some 2.1 documents may have different line breaks.

Thanks for this information, Günter.

> I am fine with going forward with rc1, as the data loss is a rare case and
> only affects formatting (we loose an ivisible character).

OK good to know.

Scott


signature.asc
Description: PGP signature

Re: [LyX/2.3.x] Make math options loading automatic, see ticket 10661

2017-10-28 Thread Scott Kostyshak 
On Sat, Oct 28, 2017 at 02:57:02PM +, Jean-Pierre Chrétien wrote:
> Le 27/10/2017 à 19:53, Scott Kostyshak a écrit :
> > On Mon, Oct 23, 2017 at 07:24:05AM +, jpc wrote:
> > > commit 95f60915a73219e1fcf549b292b17f5307f94078
> > > Author: jpc 
> > > Date:   Mon Oct 23 09:18:56 2017 +0200
> > > 
> > >Make math options loading automatic, see ticket 10661
> > > 
> > >   lib/doc/LFUNs.lyx  |   12 ++--
> > 
> > This file is automatically generated. I'm about to push a commit that
> > will thus revert your changes (since the command I run before release
> > regenerates this file). We can look into fixing the root source after
> > rc1, but for now I checked that LFUNs.lyx compiled and I don't want to
> > look into changing the root source now.
> 
> I did not notice this change, sorry.
> You mean, reverting LFUNs.lyx,or the whole commit for math options ?

Just LFUNs.lyx. I didn't expect you to notice. Actually I would have
done the same thing as you did. The only reason I noticed it was
because of my commits related to the release process. I just wanted to
give an explanation for why the change was being reverted for that
particular file. It is only that file.

Scott


signature.asc
Description: PGP signature

Re: Tars for 2.3.0rc1

2017-10-28 Thread Scott Kostyshak 
On Sat, Oct 28, 2017 at 07:39:29AM +, Kornel Benko wrote:

> Needs a commit in 2.3.x too.

I will take care of that. I've already cherry-picked it locally.

Scott


signature.asc
Description: PGP signature

Re: configure.py regression in RC1 compared to beta

2017-10-28 Thread Jürgen Spitzmüller 
Am Samstag, den 28.10.2017, 18:49 +0200 schrieb Uwe Stöhr:
> El 28.10.2017 a las 14:05, Jürgen Spitzmüller escribió:
> 
> > > How can we fix this?
> > 
> > If it turns out that Inkscape on Windows cannot deal with paths we
> > need
> > to introduce a function for configure.py that returns full path or
> > only
> > file name depending on the OS.
> 
> I think this is the problem as far as I investigated now.
> OK, I was not yet able to check if the path behind $$p is quoted or 
> note. If not this would explain why it fails on Windows.

It should be quoted. You can check via the messages pane.

Jürgen

> 
> regards Uwe

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

Re: configure.py regression in RC1 compared to beta

2017-10-28 Thread Uwe Stöhr 

El 28.10.2017 a las 14:05, Jürgen Spitzmüller escribió:


How can we fix this?


If it turns out that Inkscape on Windows cannot deal with paths we need
to introduce a function for configure.py that returns full path or only
file name depending on the OS.


I think this is the problem as far as I investigated now.
OK, I was not yet able to check if the path behind $$p is quoted or 
note. If not this would explain why it fails on Windows.


regards Uwe

Re: [LyX/2.3.x] Make math options loading automatic, see ticket 10661

2017-10-28 Thread Jean-Pierre Chrétien 

Le 27/10/2017 à 19:53, Scott Kostyshak a écrit :

On Mon, Oct 23, 2017 at 07:24:05AM +, jpc wrote:

commit 95f60915a73219e1fcf549b292b17f5307f94078
Author: jpc 
Date:   Mon Oct 23 09:18:56 2017 +0200

   Make math options loading automatic, see ticket 10661

  lib/doc/LFUNs.lyx  |   12 ++--


This file is automatically generated. I'm about to push a commit that
will thus revert your changes (since the command I run before release
regenerates this file). We can look into fixing the root source after
rc1, but for now I checked that LFUNs.lyx compiled and I don't want to
look into changing the root source now.


I did not notice this change, sorry.
You mean, reverting LFUNs.lyx,or the whole commit for math options ?

Anyway do the best for the release process.

--
Jean-Pierre

Re: configure.py regression in RC1 compared to beta

2017-10-28 Thread Jürgen Spitzmüller 
Am Samstag, den 28.10.2017, 13:08 +0200 schrieb Uwe Stöhr:
> Hi Stephan,
> 
> With LyX 2.3.0beta1 I can convert EMF images in LyX file while this 
> fails in RC1.

Can you please elaborate what exactly fails?

> The reason is commit
> http://www.lyx.org/trac/changeset/350ef993/lyxgit
> 
> The bug is that the path must not be output for inkscape on Win and 
> apparently also not on Linux. 

Yes, the path is not necessary on Linux, but it also does not harm
here.

> As this seems to be a special thing for 
> MacOS, we must only do this on Mac.
> 
> Attached is a patch to restore the working behavior before your
> commit.
> 
> 
> Note that you did not make your change in line
> 'a SVG -> PNG converter'
> To be consistent also this inkscape call should have the $$p call.
> 
> How can we fix this?

If it turns out that Inkscape on Windows cannot deal with paths we need
to introduce a function for configure.py that returns full path or only
file name depending on the OS.

But first, I'd like to know what actually is the problem.

Jürgen

> 
> thanks and regards
> Uwe
> 

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

Re: Go forward with 2.3.0rc1 despite potential data loss from changes to dashes?

2017-10-28 Thread Enrico Forestieri 
On Fri, Oct 27, 2017 at 07:41:24PM -0400, Scott Kostyshak wrote:

> Dear all,
> 
> Because of the dashes and ZWSP situation, we do not produce an
> equivalent document in some cases (I'm still curious for a definition of
> what an "equivalent" document specifically means). For more information,
> see:
> 
> https://www.mail-archive.com/search?l=mid=osunpo%249f%241%40blaine.gmane.org
> 
> This issue could be interpreted as data loss, and in the past we have
> had a rule of not releasing an rc if there is known data loss.
> 
> My current opinion is that we should make an exception and just go
> forward with rc1 to get it out of the door. This way, we can get more
> testing while we debate more about the best way to resolve this issue
> after rc1.
> 
> Do you support going forward with rc1 despite this data loss issue? I
> would need some explicit support before going forward, since we would be
> making an exception to an important rule.
> 
> If instead you prefer to address the data loss issue before rc1 is
> released, please let me know if you suppport delaying rc1 until we at
> least provide a minimum fix for the issue.

I think we should go forward and only address the feared problems
if they actually materialize during the testing phase.

Please, note that I am not going to participate in discussions about
this particular issue anymore. I think it can stay as it is now but
if the majority decides otherwise, that's also fine.

-- 
Enrico

Re: [LyX/master] New layout tags for better counter handling

2017-10-28 Thread Enrico Forestieri 
On Fri, Oct 27, 2017 at 11:23:14PM -0400, Richard Heck wrote:
> On 10/27/2017 01:54 PM, Scott Kostyshak wrote:
> >
> >> Note that this commit would cause a lot of runs of layout2layout, since
> >> the formats of the layout files themselves had not yet been updated.
> > Perhaps this is what made it slow for me. So a 2 to 3 second delay
> > compared to the previous commit is not surprising?
> 
> I've heard of that sort of thing. E.g., people upgrade to some new major
> version and their documents open slowly. It turns out that layout2layout
> can be quite slow. Just reading article.layout can require opening and
> converting several files. If a number of modules are used, then it is
> even more files.

I think that using the new --verbose option helps catching those cases
in which layout2layout has to be run.

-- 
Enrico

configure.py regression in RC1 compared to beta

2017-10-28 Thread Uwe Stöhr 

Hi Stephan,

With LyX 2.3.0beta1 I can convert EMF images in LyX file while this 
fails in RC1.

The reason is commit
http://www.lyx.org/trac/changeset/350ef993/lyxgit

The bug is that the path must not be output for inkscape on Win and 
apparently also not on Linux. As this seems to be a special thing for 
MacOS, we must only do this on Mac.


Attached is a patch to restore the working behavior before your commit.


Note that you did not make your change in line
'a SVG -> PNG converter'
To be consistent also this inkscape call should have the $$p call.

How can we fix this?

thanks and regards
Uwe

diff --git 
"a/C:\\Users\\Usti\\AppData\\Local\\Temp\\TortoiseGit\\configure-5383b67.003.py"
 "b/D:\\LyXGit\\Master\\lib\\configure.py"
index f13dcbe711..9c4c78dc44 100644
--- 
"a/C:\\Users\\Usti\\AppData\\Local\\Temp\\TortoiseGit\\configure-5383b67.003.py"
+++ "b/D:\\LyXGit\\Master\\lib\\configure.py"
@@ -1014,16 +1014,16 @@ def checkConverterEntries():
 \converter tgif   png"tgif -print -color -png -o $$d $$i"  ""
 \converter tgif   pdf6   "tgif -print -color -pdf -stdout $$i > $$o"   
""'''])
 #
-checkProg('a WMF -> EPS converter', ['metafile2eps $$i $$o', 'wmf2eps -o 
$$o $$i', inkscape_name + ' --file=$$p$$i --export-area-drawing --without-gui 
--export-eps=$$p$$o'],
+checkProg('a WMF -> EPS converter', ['metafile2eps $$i $$o', 'wmf2eps -o 
$$o $$i', inkscape_name + ' --file=$$i --export-area-drawing --without-gui 
--export-eps=$$o'],
 rc_entry = [ r'\converter wmfeps"%%"   ""'])
 #
-checkProg('an EMF -> EPS converter', ['metafile2eps $$i $$o', 'wmf2eps -o 
$$o $$i', inkscape_name + ' --file=$$p$$i --export-area-drawing --without-gui 
--export-eps=$$p$$o'],
+checkProg('an EMF -> EPS converter', ['metafile2eps $$i $$o', 'wmf2eps -o 
$$o $$i', inkscape_name + ' --file=$$i --export-area-drawing --without-gui 
--export-eps=$$o'],
 rc_entry = [ r'\converter emfeps"%%"   ""'])
 #
-checkProg('a WMF -> PDF converter', [inkscape_name + ' --file=$$p$$i 
--export-area-drawing --without-gui --export-pdf=$$p$$o'],
+checkProg('a WMF -> PDF converter', [inkscape_name + ' --file=$$i 
--export-area-drawing --without-gui --export-pdf=$$o'],
 rc_entry = [ r'\converter wmfpdf6"%%"  ""'])
 #
-checkProg('an EMF -> PDF converter', [inkscape_name + ' --file=$$p$$i 
--export-area-drawing --without-gui --export-pdf=$$p$$o'],
+checkProg('an EMF -> PDF converter', [inkscape_name + ' --file=$$i 
--export-area-drawing --without-gui --export-pdf=$$o'],
 rc_entry = [ r'\converter emfpdf6"%%"  ""'])
 # Only define a converter to pdf6 for graphics
 checkProg('an EPS -> PDF converter', ['epstopdf'],
@@ -1069,12 +1069,12 @@ def checkConverterEntries():
 rc_entry = [ r'\converter svgsvgz   "%%"   ""'])
 # Only define a converter to pdf6 for graphics
 # Prefer rsvg-convert over inkscape since it is faster (see 
http://www.lyx.org/trac/ticket/9891)
-checkProg('a SVG -> PDF converter', ['rsvg-convert -f pdf -o $$o $$i', 
inkscape_name + ' --file=$$p$$i --export-area-drawing --without-gui 
--export-pdf=$$p$$o'],
+checkProg('a SVG -> PDF converter', ['rsvg-convert -f pdf -o $$o $$i', 
inkscape_name + ' --file=$$i --export-area-drawing --without-gui 
--export-pdf=$$p$$o'],
 rc_entry = [ r'''\converter svgpdf6   "%%"""
 \converter svgz   pdf6   "%%"""'''],
 path = ['', inkscape_path])
 #
-checkProg('a SVG -> EPS converter', ['rsvg-convert -f ps -o $$o $$i', 
inkscape_name + ' --file=$$p$$i --export-area-drawing --without-gui 
--export-eps=$$p$$o'],
+checkProg('a SVG -> EPS converter', ['rsvg-convert -f ps -o $$o $$i', 
inkscape_name + ' --file=$$i --export-area-drawing --without-gui 
--export-eps=$$p$$o'],
 rc_entry = [ r'''\converter svgeps"%%"""
 \converter svgz   eps"%%"""'''],
 path = ['', inkscape_path])

Re: Go forward with 2.3.0rc1 despite potential data loss from changes to dashes?

2017-10-28 Thread Guenter Milde 
On 2017-10-27, Scott Kostyshak wrote:

> [-- Type: text/plain, Encoding:  --]

> Dear all,

> Because of the dashes and ZWSP situation, we do not produce an
> equivalent document in some cases (I'm still curious for a definition of
> what an "equivalent" document specifically means). 

I would define "equivalent" as "produces the same output".
(This leaves still some twiggle room like "latex output or pdf output?".)

We violated this "equivalence principle" in 2.3: while literal and ligature 
dashes use the
same charcter in PDF, the difference in latex resulted in different line
breaks in some occasions.

We violate this "equivalence principle" again in 2.3rc1 not only because of
ZWSP, but also because some 2.1 documents may have different line breaks.


> This issue could be interpreted as data loss, and in the past we have
> had a rule of not releasing an rc if there is known data loss.

> My current opinion is that we should make an exception and just go
> forward with rc1 to get it out of the door. This way, we can get more
> testing while we debate more about the best way to resolve this issue
> after rc1.

> Do you support going forward with rc1 despite this data loss issue? I
> would need some explicit support before going forward, since we would be
> making an exception to an important rule.

I am fine with going forward with rc1, as the data loss is a rare case and
only affects formatting (we loose an ivisible character).

I hope we can resolve the issue before releasing 2.3 proper, though.

Thanks,

Günter

Re: Initial view of document (master)

2017-10-28 Thread Kornel Benko 
Am Mittwoch, 25. Oktober 2017 um 15:24:33, schrieb Richard Heck 
> On 10/25/2017 02:35 PM, Kornel Benko wrote:
> > Am Dienstag, 24. Oktober 2017 um 19:51:41, schrieb Jean-Marc Lasgouttes 
> > 
> >> Le 23/10/2017 à 22:26, Pavel Sanda a écrit :
> >>> And I have reproducible crash:
> >>> 1. start new document
> >>> 2. write "ambititious ", spellcheck correctly underlies text.
> >>> 3. try to fix spelling via context menu, choose "ambitious"
> >>> 4. kaboom
> >> I can't reproduce. Qt4 or Qt5?
> >>
> >> JMarc
> > I can reproduce with continuous spellcheck enabled. Qt5.
> >
> > It crashes on LASSERT(LASSERT(end > start && end <= size() + 1, return 
> > false);
> >  at src/Paragraph.cpp:612
> > (gdb) p start
> > $1 = 0
> > (gdb) p end
> > $2 = 11
> > (gdb) p size()
> > $1 = 9
> >
> > Without this assert, everything works OK. Richard, why is it there needed?
> 
> "git blame" will blame me, but I only added the "return false". That
> way, in release mode, we just say "no change" and continue, hopefully
> safely. The assertion itself goes back to d53d4a5c, in 2006.
> 
> Presumably, the end variable does not really make sense here. Position
> 11 is past the end of the paragraph (and past the end of paragraph
> marker at pos=10). We're lucky, because Changes::isChanged isn't
> affected by this. Something is definitely wrong, though, and that's what
> the assertion is telling us.
> 
> Richard

The same assertion in 2.3.x does not trigger here.

(gdb) p start
$1 = 0
(gdb) p end
$2 = 10
(gdb) p size()
$3 = 9
.
(gdb) up
#1  0x00dfaae6 in lyx::RowPainter::paintChangeBar (this=0x7fffb290)
at /usr2/src/lyx/lyx-2.0.x-git/src/RowPainter.cpp:259
259 if (start == end || !par_.isChanged(start, end))
(gdb) p end
$4 = 10
(gdb) p par_.size()
$5 = 9


In lyx2.4, it is totally impossible to debug. One has to wait for crash first.

(gdb) up
#6  0x00dd94dc in lyx::Paragraph::isChanged (this=0x27ec370, start=0, 
end=11)
at /usr2/src/lyx/lyx-git/src/Paragraph.cpp:612
612 LASSERT(end > start && end <= size() + 1, return false);
(gdb) up
#7  0x00dfde10 in lyx::RowPainter::paintChangeBar (this=0x7fff5330)
at /usr2/src/lyx/lyx-git/src/RowPainter.cpp:259
259 if (start == end || !par_.isChanged(start, end))
(gdb) p par_.size()
$1 = 9
(gdb) p end
$2 = 11
(gdb) p row_.endpos()
$3 = 11

So the endpos() is different here.

Kornel
Kornel



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

Re: Tars for 2.3.0rc1

2017-10-28 Thread Kornel Benko 
Am Samstag, 28. Oktober 2017 um 03:18:12, schrieb Scott Kostyshak 

> On Sat, Oct 28, 2017 at 12:22:33AM +, Uwe Stöhr wrote:
> > El 28.10.2017 a las 02:18, Uwe Stöhr escribió:
> > 
> > > I found it: the file
> > > 
> > > ReplaceValues.cmake
> > > 
> > > is missing in your tar.
> > 
> > the reason is a missing entry in a Makefile. I fixed this now in master:
> > 
> > http://www.lyx.org/trac/changeset/3d4358f1/lyxgit
> 
> Thanks for the fix, Uwe. I'm sending new tars now.
> 
> Scott

Yes, thanks. I missed to correct the makefile when creating this file.

Needs a commit in 2.3.x too.

Kornel

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

Re: [LyX/master] Makefile.am: add missing cmake file

2017-10-28 Thread Kornel Benko 
Am Samstag, 28. Oktober 2017 um 02:21:16, schrieb Uwe Stöhr 
> commit 3d4358f101dc3111993a3c34d9495c8b0c28b566
> Author: Uwe Stöhr 
> Date:   Sat Oct 28 02:21:09 2017 +0200
> 
> Makefile.am: add missing cmake file
> ---
>  development/Makefile.am |1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
> 
> diff --git a/development/Makefile.am b/development/Makefile.am
> index ff332aa..d160469 100644
> --- a/development/Makefile.am
> +++ b/development/Makefile.am
> @@ -130,6 +130,7 @@ cmake/configCompiler.h.msvc \
>  cmake/configFunctions.cmake \
>  cmake/configIncludes.cmake \
>  cmake/doc/CMakeLists.txt \
> +cmake/doc/ReplaceValues.cmake \
>  cmake/doc/ReplaceValues.pl \
>  cmake/doc/ReplaceValues.py \
>  cmake/lyx_date.h.cmake \


Thanks Uwe. Scott, it should go to 2.3.x too.

Kornel

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

Re: Tars for 2.3.0rc1

2017-10-28 Thread Scott Kostyshak 
On Sat, Oct 28, 2017 at 12:22:33AM +, Uwe Stöhr wrote:
> El 28.10.2017 a las 02:18, Uwe Stöhr escribió:
> 
> > I found it: the file
> > 
> > ReplaceValues.cmake
> > 
> > is missing in your tar.
> 
> the reason is a missing entry in a Makefile. I fixed this now in master:
> 
> http://www.lyx.org/trac/changeset/3d4358f1/lyxgit

Thanks for the fix, Uwe. I'm sending new tars now.

Scott


signature.asc
Description: PGP signature