Re: Support for python 2 and 3 in lyx2lyx for 2.3

[Scott Kostyshak]

On Tue, Mar 28, 2017 at 11:43:10AM +0100, José Abílio Matos wrote:

> At the same time and do not expect pressure from the users who want to 
> convert 
> lyx-0.10 documents so I do no expect that Scott makes this a release blocker 
> for 2.3. :-D

Thanks for the investigation on this issue, José.

Scott


signature.asc
Description: PGP signature

LyX master still not ready for Python 3

[Uwe Stöhr]

As requested by José, I installed Python 3.6.1 and tested today's master 
with it. As result LyX cannot be started because the reconfiguration fails:


02:05:53.187: Checking whether TeX allows spaces in file names... yes
02:05:53.188: Traceback (most recent call last):
02:05:53.189:   File "D:/LyXGit/Master/lib/configure.py", line 1814, in 


02:05:53.192: windows_style_tex_paths = checkTeXPaths()
02:05:53.193:   File "D:/LyXGit/Master/lib/configure.py", line 206, in 
checkTeXPaths
02:05:53.194: inpname = shortPath(str(tmpfname, 
encoding)).replace('\\', '/')

02:05:53.196: TypeError: decoding str is not supported
02:05:53.198: configuration will be reloaded...
D:\LyXGit\Master\src\support\Systemcall.cpp (295): Systemcall: 'python 
-tt "D:/LyXGit/Master/lib/configure.py" 
--binary-dir="D:/LyXGit/Master/compile-2015/bin/Release/"' finished with 
exit code 1


regards Uwe

Re: Formal tables

[Joel Kulesza]

On Tue, Mar 28, 2017 at 3:28 PM, Andrew Parsloe 
wrote:

> The booktabs package produces much cleaner tables than "native" LaTeX
> ones, but I wonder why LyX only "half converts" a LaTeX table to formal
> style? In the attachment LyX produces the middle table from the left-hand
> one, but the right-hand one is what should be produced according to the
> booktabs documentation:
>
> 1. Never, ever use vertical rules.
> 2. Never use double rules.
> ...
> In the simplest of cases a table begins with a \toprule, has a single row
> of column headings, then a dividing rule called here a \midrule; after the
> columns of data we finish off with a \bottomrule.
>
> A user might wonder what the benefits of the Formal Style are when faced
> with the middle table. It takes significantly more space and is still fussy
> with horizontal rules.
>
> Why not convert according to the scheme:
>
> 1. the initial \hline -> \toprule
> 2. the final \hline -> \bottomrule
> 3. \hline \hline -> \midrule
> 4. any other \hline -> (nothing)
>
> Andrew
>

Andrew:

See also tickets for varying degrees of discussion/disposition:

https://www.lyx.org/trac/ticket/8360
https://www.lyx.org/trac/ticket/9901
https://www.lyx.org/trac/ticket/10105
https://www.lyx.org/trac/ticket/10106

- Joel

Re: Support for python 2 and 3 in lyx2lyx for 2.3

[José Abílio Matos]

On Tuesday, 28 March 2017 23.57.39 WEST José Abílio Matos wrote:
> FWIW the culprit seems to be normalize_font_whitespace in lyx_1_5.py, that
> is used for formats 259 and 274.

I found the reason.

In that function the is a variable called changes that is a dictionary. We 
access to the list of keys of that dictionary with list(changes.keys()) but 
this function does not guarantee the same order return between two different 
python versions. BTW this also applies to python 2 versions.

After reading the code I see that both versions are functionally equivalent. 
:-D

OK this means that we do not have a bug between the two versions, but 
something that we can improve by making the return order stable.

One possible option would be to use

from collections import OrderedDict

and then

changes = OrderedDict()

this guarantees a stable return order...

-- 
José Abílio

Re: LyX 2.2.3, Finally?

[Richard Heck]

On 03/28/2017 04:55 PM, Guenter Milde wrote:
> On 2017-03-28, Richard Heck wrote:
>> It looks as if we're now ready for 2.2.3, after some of the recent work.
>> Any reason not to freeze strings now?
> Yes:
>
> * Quote styles are missing the "catchy" names from 2.2 and hard to
>   discern on small screen or for the visually impaired.
>   
>   I like the "language" names back - preferably combined with
>   example using the correct Unicode characters, e.g.
>   
>   »›Danish‹ quotes«
>   „‚German‘ quotes“
>   «“Italian“ quotes»
>   ...
>   
> * As a stop-gap measure until a proper fix is ready, can we please change
>   the misleading font-encoding GUI name "Default" now?
>   
>   http://www.lyx.org/trac/ticket/9741#comment:6 
>
> * The special character for a "line break opportunity without hyphen"
>   needs translation of name and tooltip.
>   http://www.lyx.org/trac/ticket/10585

Sorry, think there is some confusion. I was talking about 2.2.3, NOT
2.3.0. Correct me if I'm wrong, but those all look like issues for 2.3.0.

Richard

Re: Support for python 2 and 3 in lyx2lyx for 2.3

[José Abílio Matos]

On Tuesday, 28 March 2017 15.07.17 WEST Jean-Marc Lasgouttes wrote:
> It looks like something that can be handled by a bisect, either a real
> one or a hand-made one where a dichotomy is done on the intermediate
> commits.

Nah... I prefer to follow Ken Thompson's advice:
"When in doubt, use brute force."

Just in case I remember this quote from Brian W. Kernighan and P. J. Plauger 
in "The Elements of Programming Style".

:-)

FWIW the culprit seems to be normalize_font_whitespace in lyx_1_5.py, that is 
used for formats 259 and 274.

> Looks good!

I agree. :-)

I have noticed that python 3 fails to correctly detect the version used to 
produce the original document. In any case this information is redundant since 
it correctly gets the file format and so the conversion works as expected.

My purpose is to get all the different behaviours between the two versions to 
get any possible error. Just like your work with coverity reports. :-)

> JMarc

Regards,
-- 
José Abílio

Formal tables

[Andrew Parsloe]

The booktabs package produces much cleaner tables than "native" LaTeX 
ones, but I wonder why LyX only "half converts" a LaTeX table to formal 
style? In the attachment LyX produces the middle table from the 
left-hand one, but the right-hand one is what should be produced 
according to the booktabs documentation:


1. Never, ever use vertical rules.
2. Never use double rules.
...
In the simplest of cases a table begins with a \toprule, has a single 
row of column headings, then a dividing rule called here a \midrule; 
after the columns of data we finish off with a \bottomrule.


A user might wonder what the benefits of the Formal Style are when faced 
with the middle table. It takes significantly more space and is still 
fussy with horizontal rules.


Why not convert according to the scheme:

1. the initial \hline -> \toprule
2. the final \hline -> \bottomrule
3. \hline \hline -> \midrule
4. any other \hline -> (nothing)

Andrew


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


formaltables.pdf
Description: Adobe PDF document

Re: cmake failed (solved)

[Guenter Milde]

On 2017-03-24, Kornel Benko wrote:
> Am Freitag, 24. März 2017 um 16:17:21, schrieb Guenter Milde 
> 
>> On 2017-03-24, Kornel Benko wrote:
>> > Am Freitag, 24. März 2017 um 11:28:41, schrieb Guenter Milde 
>> > 

>> >> CMake Error at development/cmake/modules/LyXMacros.cmake:250 (list):
>> >>   list sub-command FIND requires three arguments.
>> >> Call Stack (most recent call first):
>> >>   CMakeLists.txt:149 (LYX_COMBO)

We managed to fix the problem in private conversation:

The cache-variable LYX_EXTERNAL_MYTHES was changed from BOOL (ON OFF)
to STRING to allow the value AUTO.

2 alternative fixes:

A.) Edit CMakeCache.txt
delete all lines with EXTERNAL_MYTHES
B.) Delete CMakeCache.txt

That did it.

Günter

Re: LyX 2.2.3, Finally?

[Guenter Milde]

On 2017-03-28, Richard Heck wrote:
> It looks as if we're now ready for 2.2.3, after some of the recent work.
> Any reason not to freeze strings now?

Yes:

* Quote styles are missing the "catchy" names from 2.2 and hard to
  discern on small screen or for the visually impaired.
  
  I like the "language" names back - preferably combined with
  example using the correct Unicode characters, e.g.
  
  »›Danish‹ quotes«
  „‚German‘ quotes“
  «“Italian“ quotes»
  ...
  
* As a stop-gap measure until a proper fix is ready, can we please change
  the misleading font-encoding GUI name "Default" now?
  
  http://www.lyx.org/trac/ticket/9741#comment:6 

* The special character for a "line break opportunity without hyphen"
  needs translation of name and tooltip.
  http://www.lyx.org/trac/ticket/10585
  
Thanks,
  
Günter

Re: LyX 2.2.3, Finally?

[Jean-Marc Lasgouttes]

Go ahead.

JMarc

Le 28 mars 2017 21:00:50 GMT+02:00, Richard Heck  a écrit :
>It looks as if we're now ready for 2.2.3, after some of the recent
>work.
>Any reason not to freeze strings now?
>
>Richard

LyX 2.2.3, Finally?

[Richard Heck]

It looks as if we're now ready for 2.2.3, after some of the recent work.
Any reason not to freeze strings now?

Richard

Re: Support for python 2 and 3 in lyx2lyx for 2.3

[Jean-Marc Lasgouttes]

Le 28/03/2017 à 12:43, José Abílio Matos a écrit :

Using the 0.12.0 User Guide as the starting point the only differences between
the two conversions is that python 2 way gets at some points:

\bar default
\family default

while the python 3 gets

\family default
\bar default

This happens in 12 places.

This is good because it means that the difference comes likely from a single
place and with so many conversions being done this is better than OK.


It looks like something that can be handled by a bisect, either a real 
one or a hand-made one where a dichotomy is done on the intermediate 
commits.


Looks good!

JMarc

Support for python 2 and 3 in lyx2lyx for 2.3

[José Abílio Matos]

First the good news: after Georg's work we are almost there (99.999%). :-)

And now the fine details.

I have fixed #9006 that results in lyx2lyx working with python 3 for systems 
where the system default encoding is not UTF-8.

Using the 0.12.0 User Guide as the starting point the only differences between 
the two conversions is that python 2 way gets at some points:

\bar default
\family default

while the python 3 gets

\family default
\bar default

This happens in 12 places.

This is good because it means that the difference comes likely from a single 
place and with so many conversions being done this is better than OK.

On the other hand the resulting file when read by lyx is immediately modified 
and saving it has a bigger diff. In particular there one case where it looks 
like that we have a missing conversion in lyx2lyx:

- Compared to common word processors, \SpecialChar LyX$
+ Compared to common word processors, \SpecialCharNoPassThru LyX$

It looks like \SpecialChar should have been converted to 
\SpecialCharNoPassThru but it is not.

Where I would like help would be in setting some testing framework to compare 
the conversions when using python 2 and python 3 to ensure that the code does 
the same when using the two python versions.

In another interesting twist when testing the conversion of 0.10.7 User Gude 
(the i is really missing from the title :-) ) only the python 3 version 
applies the conversion of the 0.10 stage while the python 2 way ignores it and 
goes directly to 0.12. That puzzled me a lot, it took me a while to understand 
the problem. I tested this with lyx2lyx in 2.2 and problem is already there so 
this was not the result of making lyx2lyx work with python 3. :-)

At the same time and do not expect pressure from the users who want to convert 
lyx-0.10 documents so I do no expect that Scott makes this a release blocker 
for 2.3. :-D

This is something that I would like to fix naturally.

Regards,
-- 
José Abílio

[coverity again] missing move constructors

[Jean-Marc Lasgouttes]

This one is probably for Guillaume.

Coverity complains about missing move constructors for Inset, MathAtom, 
Mover, SpecializedMover, FileName, InsetMathNest, InsetMathHull.


The help text says: "This class does not have a user-written move 
assignment operator and its copy assignment operator is found to be 
applied to rvalue(s), which can be moved to possibly enhance program 
performance had the move assignment operator been in place."


At least I would guess that FileName would benefit from it, but what 
about the others?


JMarc

Re: [LyX/master] Handle properly exception that can be thrown by to_local8bit

[Enrico Forestieri]

On Tue, Mar 28, 2017 at 11:51:23AM +0200, Jean-Marc Lasgouttes wrote:

> Le 28/03/2017 à 11:01, Enrico Forestieri a écrit :
> > Hmm. I must have done something wrong because toSafeFilesystemEncoding()
> > actually works. The attached patch is required on native windows when
> > the tempdir path has unicode characters. The change in Buffer.cpp is
> > required for lyx2lyx.
> 
> Thanks for taking care of this Enrico.

And I discovered what I was doing wrong. I was forgetting the argument
os::CREATE for toSafeFilesystemEncoding() in doOpenFileWrite(). 

-- 
Enrico

Re: Jenkins build is back to normal : Build branch "master" » ubuntu-xenial-qt4-autotools-extended #118

[Jean-Marc Lasgouttes]

Le 25/03/2017 à 14:07, ci-...@inria.fr a écrit :

https://ci.inria.fr/lyx/job/build-master-head/job/ubuntu-xenial-qt4-autotools-extended/118/



Christian, did you do something to have it back to normal ?

JMarc

Re: [LyX/master] Handle properly exception that can be thrown by to_local8bit

[Jean-Marc Lasgouttes]

Le 28/03/2017 à 11:01, Enrico Forestieri a écrit :

Hmm. I must have done something wrong because toSafeFilesystemEncoding()
actually works. The attached patch is required on native windows when
the tempdir path has unicode characters. The change in Buffer.cpp is
required for lyx2lyx.


Thanks for taking care of this Enrico.

JMarc