Re: compilation problems with Qt 5.5.1 and MSVC 2010

[Peter Kümmel]

Am 13. Januar 2016 05:27:22 MEZ, schrieb "Peter Kümmel" :
>Am 13. Januar 2016 05:19:09 MEZ, schrieb "Peter Kümmel"
>:
>>
 It is a warning only committed from me today to fix a linker error.
>>>You tried it with msvc 2010? And it worked?
>>>
>>>Yes. I can now compile with MSVC 2010 and Qt 5.5.1. The compilation
>of
>>
>>>Zlib and friends works here also with MSVC2013.
>>
>>
>>Ok, then you could build an installer again with MSVC2010 and 5.5.1. 
>>
>>But afaik Qt 5.6 will not support MSVC2010 any more. So maybe it is
>>worth now to start trying with mingw, because atm the new msvc
>>compilers have no real futute within lyx. I assume even clang would be
>>better.
>>
>>Is there a recipe how to procede after the successfull build of lyx?
>>How complicated is it to get an installer created?
>>
>>The mingw.bat works, so is it possible to add a second script which
>>produces the installer?i 
>>
>>>
>>>regards Uwe

If 5.6 is to buggy, we can also use 5.5.1 build with mingw.

But when we now decide to use only msvc2010, then I stop working on a mingw 
build. 

Re: compilation problems with Qt 5.5.1 and MSVC 2010

[Peter Kümmel]

Am 13. Januar 2016 05:19:09 MEZ, schrieb "Peter Kümmel" :
>
>>> It is a warning only committed from me today to fix a linker error.
>>You tried it with msvc 2010? And it worked?
>>
>>Yes. I can now compile with MSVC 2010 and Qt 5.5.1. The compilation of
>
>>Zlib and friends works here also with MSVC2013.
>
>
>Ok, then you could build an installer again with MSVC2010 and 5.5.1. 
>
>But afaik Qt 5.6 will not support MSVC2010 any more. So maybe it is
>worth now to start trying with mingw, because atm the new msvc
>compilers have no real futute within lyx. I assume even clang would be
>better.
>
>Is there a recipe how to procede after the successfull build of lyx?
>How complicated is it to get an installer created?
>
>The mingw.bat works, so is it possible to add a second script which
>produces the installer?i 
>
>>
>>regards Uwe

Re: Windows: release with Qt 5.5.1 or 5.6?

[Peter Kümmel]

Am 13. Januar 2016 01:46:35 MEZ, schrieb Scott Kostyshak :
>On Wed, Jan 13, 2016 at 01:31:59AM +0100, Peter Kümmel wrote:
>> Am 13. Januar 2016 00:32:11 MEZ, schrieb Scott Kostyshak
>:
>> >Dear all,
>> >
>> >There is a question of whether we should release our binary for
>Windows
>> >compiled against Qt 5.5.1 or 5.6.0.
>> >
>> 
>> It is not very complicated to switch between these two versions. So
>just let see how the timing becomes.
>
>Although I am very open since I am not knowledgeable on this topic, I
>would be quite hesitant to switch between 5.5.1 and 5.6.0 after beta. I
>am not worried about how easy it is to switch in terms of compiling
>(that is a separate set of concerns that I am not convinced are
>trivial). I'm worried about Qt bugs. I have seen many Qt bugs affect
>LyX. But I suppose we can have that discussion if the circumstances
>permit (e.g. LyX has not been released by the time Qt 5.6.0 final has
>been released, and the bug Enrico sees was fixed in Qt 5.6.0 final).


Yes, this bug looks like a show stopper for 5.6.
>
>Scott

Re: Windows: release with Qt 5.5.1 or 5.6?

[Richard Heck]

On 01/12/2016 06:32 PM, Scott Kostyshak wrote:
> Dear all,
>
> There is a question of whether we should release our binary for Windows
> compiled against Qt 5.5.1 or 5.6.0.
>
> My opinion is that we should release it with 5.5.1, unless there is a
> known, significant issue that affects LyX for 5.5.1 *on Windows* and
> that would be solved with 5.6.0.
>
> There are two reasons behind my opinion. In general, I trust a point
> release more and also I do not want to depend on there not being any
> delays in the final Qt 5.6 release. The current scheduled date is
> February 9th [1]. There have been many delays in the past (e.g. the beta
> was delayed by more than 2 months) so I would not be surprised if there
> were more in the future. Although it is true that LyX might be delayed
> also for other reasons, we should not plan on this because that would
> cause even further delays.
>
> One reason that is against my opinion though, is that Qt 5.6 is going to
> be a long-term release. It is not exactly clear how this will play out
> since it is the first long-term release by Qt, from what I understand.
> However, it would indeed (if there weren't the problems I mentioned
> above) be nice to have the whole LyX 2.2.x series compiled against
> 5.6.x. For example, we might be able to upgrade from 5.6.0 to 5.6.2 from
> e.g. LyX 2.2.4 to 2.2.5 with more confidence than e.g. 5.5.1 to 5.6.2.
> However, I still think the points above outweigh this benefit.
>
> What do others think?

Perhaps one relevant point here is that we have often released a new
minor version pretty quickly. Once 2.2.0 is out, we'll start to get bug
reports. 2.1.1 came out two and half months after 2.1.0, for example. So
we can always move to 5.6.x along the way. Obviously, we would want to
do some testing, but it would even be possible to release builds with
both 5.5.x and 5.6.x.

Richard

Re: "Splitting of consecutive environments has been reworked and enhanced"

[Richard Heck]

On 01/12/2016 06:53 PM, Enrico Forestieri wrote:
> On Tue, Jan 12, 2016 at 11:49:54PM +0100, Enrico Forestieri wrote:
>> On Mon, Jan 11, 2016 at 03:04:33AM +, Guillaume Munch wrote:
>>
>>> For the symbol itself, my suggestion was a very elongated version of ⌟,
>>> meant to recall the plain separator inset. But, a character that
>>> would match the meaning would be the pilcrow sign (¶). One would just
>>> have to make sure the a grey pilcrow sign (from end-of-paragraph marks)
>>> is not displayed after a red pilcrow sign because this would look weird
>>> (although could be allowed as a temporary measure). On the other hand,
>>> what was the idea behind your suggestion of ↔ ?
>> The symbol should not be too large, because it can also appear at the
>> end of a line when importing old documents, so that the appearance
>> would be ugly. The ↔ is simply a symbol that cannot be exchanged with
>> the newline one and also gives the idea of a separator, although it
>> probably fails to convey the concept that it introduces a blank line
>> in the latex output. 
> What about a symbol like the attached one? It resembles a pilcrow with a left 
> pointing arrow.

That looks good to me, and of course we don't want to rely upon color,
especially red.

Richard

Re: compilation problems with Qt 5.5.1 and MSVC 2010

[Uwe Stöhr]

Am 13.01.2016 um 01:38 schrieb Peter Kümmel:


It is a warning only committed from me today to fix a linker error. You tried 
it with msvc 2010? And it worked?


Yes. I can now compile with MSVC 2010 and Qt 5.5.1. The compilation of 
Zlib and friends works here also with MSVC2013.


regards Uwe

Re: Windows: release with Qt 5.5.1 or 5.6?

[Scott Kostyshak]

On Wed, Jan 13, 2016 at 01:31:59AM +0100, Peter Kümmel wrote:
> Am 13. Januar 2016 00:32:11 MEZ, schrieb Scott Kostyshak :
> >Dear all,
> >
> >There is a question of whether we should release our binary for Windows
> >compiled against Qt 5.5.1 or 5.6.0.
> >
> 
> It is not very complicated to switch between these two versions. So just let 
> see how the timing becomes.

Although I am very open since I am not knowledgeable on this topic, I
would be quite hesitant to switch between 5.5.1 and 5.6.0 after beta. I
am not worried about how easy it is to switch in terms of compiling
(that is a separate set of concerns that I am not convinced are
trivial). I'm worried about Qt bugs. I have seen many Qt bugs affect
LyX. But I suppose we can have that discussion if the circumstances
permit (e.g. LyX has not been released by the time Qt 5.6.0 final has
been released, and the bug Enrico sees was fixed in Qt 5.6.0 final).

Scott


signature.asc
Description: PGP signature

Re: compilation problems with Qt 5.5.1 and MSVC 2010

[Peter Kümmel]

Am 13. Januar 2016 01:18:12 MEZ, schrieb "Uwe Stöhr" :
>Am 12.01.2016 um 11:16 schrieb Peter Kümmel:
>
>> Yes, no Dlls any more (only the Qt related ones).
>
>OK.
>
>However I get now man times this warning:
>
>D:\LyXGit\Master\compile-2010\zconf.h(10): warning C4005: 'Z_PREFIX': 
>Makro-Neudefinition [D:\LyXGit\Master\compile-2010\src\LyX.vcxproj]
>   D:\LyXGit\Master\compile-2010\config.h(78): Siehe vorherige 
>Definition von 'Z_PREFIX'
>
>Can we do something against this (MSVC 2010)?
>
>>> thanks and regards
>>> Uwe

It is a warning only committed from me today to fix a linker error. You tried 
it with msvc 2010? And it worked?

Re: Windows: release with Qt 5.5.1 or 5.6?

[Peter Kümmel]

Am 13. Januar 2016 00:32:11 MEZ, schrieb Scott Kostyshak :
>Dear all,
>
>There is a question of whether we should release our binary for Windows
>compiled against Qt 5.5.1 or 5.6.0.
>

It is not very complicated to switch between these two versions. So just let 
see how the timing becomes.

>My opinion is that we should release it with 5.5.1, unless there is a
>known, significant issue that affects LyX for 5.5.1 *on Windows* and
>that would be solved with 5.6.0.
>
>There are two reasons behind my opinion. In general, I trust a point
>release more and also I do not want to depend on there not being any
>delays in the final Qt 5.6 release. The current scheduled date is
>February 9th [1]. There have been many delays in the past (e.g. the
>beta
>was delayed by more than 2 months) so I would not be surprised if there
>were more in the future. Although it is true that LyX might be delayed
>also for other reasons, we should not plan on this because that would
>cause even further delays.
>
>One reason that is against my opinion though, is that Qt 5.6 is going
>to
>be a long-term release. It is not exactly clear how this will play out
>since it is the first long-term release by Qt, from what I understand.
>However, it would indeed (if there weren't the problems I mentioned
>above) be nice to have the whole LyX 2.2.x series compiled against
>5.6.x. For example, we might be able to upgrade from 5.6.0 to 5.6.2
>from
>e.g. LyX 2.2.4 to 2.2.5 with more confidence than e.g. 5.5.1 to 5.6.2.
>However, I still think the points above outweigh this benefit.
>
>What do others think?
>
>Scott
>
>[1]
>https://wiki.qt.io/Qt-5.6-release

Re: Questions for Uwe once you are back

[Peter Kümmel]

Am 13. Januar 2016 00:21:52 MEZ, schrieb "Uwe Stöhr" :
>Am 12.01.2016 um 19:43 schrieb Georg Baum:
>
>>> For now I also need the info about Qt 5. What is the expected build
>>> target for beta1? My time is limited and I have to focus on one Qt
>>> version. I installed Qt 5.6 beta for mingw and mingw itself. Is this
>the
>>> way I should go?
>>
>> That depends whether you want to learn mingw or not. Concerning qt
>5.6 I
>> belive the release dates Scott sent do pretty much rule it out (it
>will be
>> finished too late), so the question is whether qt 5.5 works wel
>enough on
>> windows.
>
>OK, I will test my 5.5.1 build with MSVC201 thoroughly and report back.
>
>For Qt 5.6 I will use MinGW and not MSVC. Since both are new programs
>to 
>me I think it makes sense to release beta1 with 5.5 if possible if
>Scott 
>agrees.
>
>> Sorry, I still do not understand. Which paths need to be setup? What
>takes
>> long (a manual step or some program that runs)?
>
>CMake. As soon as I create a new folder and copy there code, I need to 
>run CMake from scratch and specify about 40 paths (most of them to Qt).
>If I make a mistake there I get strange builds.

The mingw build collects all the qt files with the install rules. No path 
should be manually touched. All missimg should be written down into the cmake 
files.



>
>So I still think that creating a new git branch and copying the files 
>from the tar there is the quickest and also safest way - no need to 
>fiddle around with any path.
>
>regards Uwe

Re: Questions for Uwe once you are back

[Peter Kümmel]

My time is limited and I have to focus onone Qt
>>> version. I installed Qt 5.6 beta for mingw and mingw itself. Is this
>the way I should go?
>>
>> Yes, that would be great!
>
>Hi Peter,
>
>OK, I will try this. Since I never used MinGW I expect some obstacles 
>and will contact you. OK?

Sure! Plain building should work now. But i dont know what comes after that, to 
get a real installer. 

>
>> It looks like the paths will also not change after the release of
>5.6.0
>> (default is C:\Qt\Qt5.6.0) So I would like to add one .bat script
>> for the mingw build with most paths hardcoded. Maybe we could even
>> agree where to put the lyx sources/build dir.
>
>Sure. Make a proposal for a path.
>
>> Then lets release a lyx beta MinGW build with the Qt 5.6 beta and
>> when 5.6 is out just make the the final lyx with the 5.6.0.
>
>Would be fine with me but it seems that Qt 5.6 is delayed (just googled
>
>a bit around)
>Scott? What is your opinion?
>
>thanks and regards
>Uwe

Re: compilation problems with Qt 5.5.1 and MSVC 2010

[Uwe Stöhr]

Am 12.01.2016 um 11:16 schrieb Peter Kümmel:


Yes, no Dlls any more (only the Qt related ones).


OK.

However I get now man times this warning:

D:\LyXGit\Master\compile-2010\zconf.h(10): warning C4005: 'Z_PREFIX': 
Makro-Neudefinition [D:\LyXGit\Master\compile-2010\src\LyX.vcxproj]
  D:\LyXGit\Master\compile-2010\config.h(78): Siehe vorherige 
Definition von 'Z_PREFIX'


Can we do something against this (MSVC 2010)?


thanks and regards
Uwe

Re: compilation problems with Qt 5.5.1 and MSVC 2010

[Peter Kümmel]

Am 12. Januar 2016 20:24:38 MEZ, schrieb Georg Baum 
:
>Am 12.01.2016 um 00:37 schrieb Uwe Stöhr:
>> I did this now as I wrote in the
>> Questions for Uwe once you are back
>> thread.
>> I had to delete CMake's cache first and re-run it from scratch. The 
>> 3rd party programs are compiled (with 134 warnings) but I don't get a
>
>> DLL. Is this the plan - not to rely anymore on DLLs?
>>
>Almost. The libs are currently compiled as static libraries. But this
>is 
>not the most important aspect. The main goal of having these sources 
>included with LyX is that no externally compiled prerequisites are 
>needed anymore (except for qt). This has two advantages:
>
>1) It makes it more easy for other people to build LyX on windows, even
>
>if they have a different compiler than you. I hope that this will 
>attract other people who build on windows in the long term, so that you
>
>do not need to do everything alone.
>
>2) It eliminates all possibillities of errors that may occur because of
>
>different compilers. This makes it more easy for you to switch to a new
>
>MSVC version.


But Atm all msvc > 2010 versions are broken. So the only way to go is mingw or 
2010. 

>
>If it turns out that for some reason having one of these thirdparty 
>libraries as dll has advantages, we could also change the build 
>procedure to produce dlls from the same sources.
>
>
>Georg

Re: "Splitting of consecutive environments has been reworked and enhanced"

[Enrico Forestieri]

On Tue, Jan 12, 2016 at 11:49:54PM +0100, Enrico Forestieri wrote:
> On Mon, Jan 11, 2016 at 03:04:33AM +, Guillaume Munch wrote:
> 
> > For the symbol itself, my suggestion was a very elongated version of ⌟,
> > meant to recall the plain separator inset. But, a character that
> > would match the meaning would be the pilcrow sign (¶). One would just
> > have to make sure the a grey pilcrow sign (from end-of-paragraph marks)
> > is not displayed after a red pilcrow sign because this would look weird
> > (although could be allowed as a temporary measure). On the other hand,
> > what was the idea behind your suggestion of ↔ ?
> 
> The symbol should not be too large, because it can also appear at the
> end of a line when importing old documents, so that the appearance
> would be ugly. The ↔ is simply a symbol that cannot be exchanged with
> the newline one and also gives the idea of a separator, although it
> probably fails to convey the concept that it introduces a blank line
> in the latex output. 

What about a symbol like the attached one? It resembles a pilcrow with
a left pointing arrow.

-- 
Enrico

Re: "Splitting of consecutive environments has been reworked and enhanced"

[Guillaume Munch]

Le 12/01/2016 22:49, Enrico Forestieri a écrit :

On Mon, Jan 11, 2016 at 03:04:33AM +, Guillaume Munch wrote:


Dear Enrico,


Thank you for the recent patches that took into account some of my remarks.

I have been using master a lot recently and I noticed another issue
which annoyed me: In 2.1, the behaviour when typing Enter at the
beginning of a paragraph is consistently to start a new paragraph before
it. In 2.2, the behaviour changes and sometimes it introduces a parbreak
separator instead, after a non-standard paragraph. The behaviour is now
inconsistent. I think that the introduction of a parbreak separator
after a non-standard paragraph should only happen on an empty paragraph.
This does not change the amount of Enter required to introduce a
separator from a non-standard paragraph, but restores the consistency of
introducing a new paragraph with Enter at the start of a paragraph.


Please, can you try the attached patch and report back whether it does
what you expect?


It does, thank you. That was definitely the small issue that was the
most annoying in practice. Have my "+1" for the patch.

Now I noticed that the "after" position can still be accessed with mouse
clicks at the end of the line. I imagine that there can still be many
commands that can produce this "after" position.

A second issue I just noticed is when deleting the separator: the
paragraph after should not immediately be merged with the one that
contains the deleted separator, if none is empty, I think. Hitting Del
should just remove the separator. (To test this, start with two
non-empty enumerate environments with a par break separator at the end
of the first one, and then try to delete the separator.)



Then, please let me thank you for your reports aimed at improving the
overall user experience. I only regret that they are the only ones
after almost two years from the introduction of env separators and that
they come just before a release, when the time for testing is not so
much.


Still better than users complaining during beta! or after release...

You are welcome. What might have contributed to the lack of feedback is 
that it was a sum of many small details that take time and effort to 
disentangle. This sort of issues is very hard to report. Also in my 
case, although I wanted to report them, I first wanted to understand the 
rationale, so I was waiting for some documentation, since it was marked 
as undocumented on the wiki...





Also, I wanted to say that given that I did not follow the original
conversations, I have more of a user's view on this, so I do not think
that my comments are redundant. Users, new users, now, and in two years,
are not going to care about historic reasons for such interface choices...


Agreed.


For the symbol itself, my suggestion was a very elongated version of ⌟,
meant to recall the plain separator inset. But, a character that
would match the meaning would be the pilcrow sign (¶). One would just
have to make sure the a grey pilcrow sign (from end-of-paragraph marks)
is not displayed after a red pilcrow sign because this would look weird
(although could be allowed as a temporary measure). On the other hand,
what was the idea behind your suggestion of ↔ ?


The symbol should not be too large, because it can also appear at the
end of a line when importing old documents, so that the appearance
would be ugly. The ↔ is simply a symbol that cannot be exchanged with
the newline one and also gives the idea of a separator, although it
probably fails to convey the concept that it introduces a blank line
in the latex output.


Yes, this is what I think for ↔. So what about a red ¶ ? This now seems
the appropriate choice to me for a par break. The color distance with
the end-of-paragraph marks (light grey) is sufficient.




Finally, for the entry method, you are already changing the meaning of
"Alt+M P" from "parbreak separator" to "plain separator", so in any case
you are already making a choice. I wanted to say that if the one who
implements a new feature does not think about what is the best default,
who does? I had to configure LyX for several co-authors and already have
too much settings to remember to change (enabling paragraph marks,
setting forward-search, some shortcuts...).


If you think that hitting enter should introduce a plain separator
instead of a parbreak one, this would be accomplished in the sources
with a really trivial change. I choose a parbreak simply because it
is completely equivalent to the old Separator layout.
However, note that when importing old documents, the old Separator
layout has still to be converted to a parbreak separator, otherwise
the output might be changed.



I did not think of it this way but, yes, this would be a convenient
solution. The main advantage, I find, is the overall consistency in
the chosen solution, in particular with Alt+M P.


Guillaume

Re: Windows: release with Qt 5.5.1 or 5.6?

[Enrico Forestieri]

On Tue, Jan 12, 2016 at 06:32:11PM -0500, Scott Kostyshak wrote:
> Dear all,
> 
> There is a question of whether we should release our binary for Windows
> compiled against Qt 5.5.1 or 5.6.0.
> 
> My opinion is that we should release it with 5.5.1, unless there is a
> known, significant issue that affects LyX for 5.5.1 *on Windows* and
> that would be solved with 5.6.0.

I am not aware of any significant issues with 5.5.1 on Windows, while
5.6.0beta introduces a new issue on all platforms. Namely, one cannot
change shortcuts through the gui in Preferences->Editing->Shortcuts.

-- 
Enrico

Re: Questions for Uwe once you are back

[Uwe Stöhr]

Am 12.01.2016 um 00:55 schrieb Kornel Benko:


* for hunspell_include_dir I get this path:
D:/LyXGit/Master/3rdparty/hunspell/1.3.3/src
* for iconv_include_dir I get this path:
D:/LyXGit/Master/compile-2010/libiconv/include

This seems wrong to me. I expect that in both cases the files from
D:/LyXGit/Master/3rdparty are taken. and indeed when generating CMake it
tells me that it cannot find iconv.


You are right. Looks like somehow the variable 'UNIX' is set, because for 
windows
the package ICONV should no be searched.
Please try attached patch.


many thanks.
I tried this but I cannot see a difference:

- still
 D:/LyXGit/Master/compile-2010/libiconv/include
 is found by CMake when running it from scratch (which does not exist) 
and not

 D:\LyXGit\Master\3rdparty\libiconv\1.14\include

- in the CMake GUI (CMake 3.4.1) I still cannot click in the path of
  iconv_include_dir
  to change it via a button (with 3 dots) that appears on the right
  side of the path
  (This works for all other paths in CMake.)

2 other CMake issues:

- I think that -LYX_3RDPARTY_BUILD=1 should by default be set in CMake 
when running it from scratch for a new build.


- The LYX_MAN_DIR defaults on Windows to
  /usr/local/man/man1
  which is not a valid path


thanks and regards
Uwe

Re: Questions for Uwe once you are back

[Scott Kostyshak]

On Wed, Jan 13, 2016 at 12:21:52AM +0100, Uwe Stöhr wrote:

> For Qt 5.6 I will use MinGW and not MSVC. Since both are new programs to me
> I think it makes sense to release beta1 with 5.5 if possible if Scott
> agrees.

I do agree with 5.5.1. I just started a new thread for this:
https://www.mail-archive.com/search?l=mid&q=20160112233211.GA16403%40OptiPlex-9020.ad.ufl.edu

I remember Peter mentioning a preference for 5.6, so I hope to hear
feedback from him on that thread (and hopefully others) before we make a
decision.

Scott


signature.asc
Description: PGP signature

Windows: release with Qt 5.5.1 or 5.6?

[Scott Kostyshak]

Dear all,

There is a question of whether we should release our binary for Windows
compiled against Qt 5.5.1 or 5.6.0.

My opinion is that we should release it with 5.5.1, unless there is a
known, significant issue that affects LyX for 5.5.1 *on Windows* and
that would be solved with 5.6.0.

There are two reasons behind my opinion. In general, I trust a point
release more and also I do not want to depend on there not being any
delays in the final Qt 5.6 release. The current scheduled date is
February 9th [1]. There have been many delays in the past (e.g. the beta
was delayed by more than 2 months) so I would not be surprised if there
were more in the future. Although it is true that LyX might be delayed
also for other reasons, we should not plan on this because that would
cause even further delays.

One reason that is against my opinion though, is that Qt 5.6 is going to
be a long-term release. It is not exactly clear how this will play out
since it is the first long-term release by Qt, from what I understand.
However, it would indeed (if there weren't the problems I mentioned
above) be nice to have the whole LyX 2.2.x series compiled against
5.6.x. For example, we might be able to upgrade from 5.6.0 to 5.6.2 from
e.g. LyX 2.2.4 to 2.2.5 with more confidence than e.g. 5.5.1 to 5.6.2.
However, I still think the points above outweigh this benefit.

What do others think?

Scott

[1]
https://wiki.qt.io/Qt-5.6-release


signature.asc
Description: PGP signature

Re: Questions for Uwe once you are back

[Uwe Stöhr]

Am 12.01.2016 um 19:43 schrieb Georg Baum:


For now I also need the info about Qt 5. What is the expected build
target for beta1? My time is limited and I have to focus on one Qt
version. I installed Qt 5.6 beta for mingw and mingw itself. Is this the
way I should go?


That depends whether you want to learn mingw or not. Concerning qt 5.6 I
belive the release dates Scott sent do pretty much rule it out (it will be
finished too late), so the question is whether qt 5.5 works wel enough on
windows.


OK, I will test my 5.5.1 build with MSVC201 thoroughly and report back.

For Qt 5.6 I will use MinGW and not MSVC. Since both are new programs to 
me I think it makes sense to release beta1 with 5.5 if possible if Scott 
agrees.



Sorry, I still do not understand. Which paths need to be setup? What takes
long (a manual step or some program that runs)?


CMake. As soon as I create a new folder and copy there code, I need to 
run CMake from scratch and specify about 40 paths (most of them to Qt).

If I make a mistake there I get strange builds.

So I still think that creating a new git branch and copying the files 
from the tar there is the quickest and also safest way - no need to 
fiddle around with any path.


regards Uwe

Re: Questions for Uwe once you are back

[Uwe Stöhr]

Am 12.01.2016 um 11:23 schrieb Peter Kümmel:


For now I also need the info about Qt 5. What is the expected build
target for beta1? My time is limited and I have to focus on one Qt
version. I installed Qt 5.6 beta for mingw and mingw itself. Is this the
way I should go?


Yes, that would be great!


Hi Peter,

OK, I will try this. Since I never used MinGW I expect some obstacles 
and will contact you. OK?



It looks like the paths will also not change after the release of 5.6.0
(default is C:\Qt\Qt5.6.0) So I would like to add one .bat script
for the mingw build with most paths hardcoded. Maybe we could even
agree where to put the lyx sources/build dir.


Sure. Make a proposal for a path.


Then lets release a lyx beta MinGW build with the Qt 5.6 beta and
when 5.6 is out just make the the final lyx with the 5.6.0.


Would be fine with me but it seems that Qt 5.6 is delayed (just googled 
a bit around)

Scott? What is your opinion?

thanks and regards
Uwe

Re: "Splitting of consecutive environments has been reworked and enhanced"

[Enrico Forestieri]

On Mon, Jan 11, 2016 at 03:04:33AM +, Guillaume Munch wrote:
> 
> Dear Enrico,
> 
> 
> Thank you for the recent patches that took into account some of my remarks.
> 
> I have been using master a lot recently and I noticed another issue
> which annoyed me: In 2.1, the behaviour when typing Enter at the
> beginning of a paragraph is consistently to start a new paragraph before
> it. In 2.2, the behaviour changes and sometimes it introduces a parbreak
> separator instead, after a non-standard paragraph. The behaviour is now
> inconsistent. I think that the introduction of a parbreak separator
> after a non-standard paragraph should only happen on an empty paragraph.
> This does not change the amount of Enter required to introduce a
> separator from a non-standard paragraph, but restores the consistency of
> introducing a new paragraph with Enter at the start of a paragraph.

Please, can you try the attached patch and report back whether it does
what you expect?

Then, please let me thank you for your reports aimed at improving the
overall user experience. I only regret that they are the only ones
after almost two years from the introduction of env separators and that
they come just before a release, when the time for testing is not so
much.

> Also, I wanted to say that given that I did not follow the original
> conversations, I have more of a user's view on this, so I do not think
> that my comments are redundant. Users, new users, now, and in two years,
> are not going to care about historic reasons for such interface choices...

Agreed.

> For the symbol itself, my suggestion was a very elongated version of ⌟,
> meant to recall the plain separator inset. But, a character that
> would match the meaning would be the pilcrow sign (¶). One would just
> have to make sure the a grey pilcrow sign (from end-of-paragraph marks)
> is not displayed after a red pilcrow sign because this would look weird
> (although could be allowed as a temporary measure). On the other hand,
> what was the idea behind your suggestion of ↔ ?

The symbol should not be too large, because it can also appear at the
end of a line when importing old documents, so that the appearance
would be ugly. The ↔ is simply a symbol that cannot be exchanged with
the newline one and also gives the idea of a separator, although it
probably fails to convey the concept that it introduces a blank line
in the latex output. 

> Finally, for the entry method, you are already changing the meaning of
> "Alt+M P" from "parbreak separator" to "plain separator", so in any case
> you are already making a choice. I wanted to say that if the one who
> implements a new feature does not think about what is the best default,
> who does? I had to configure LyX for several co-authors and already have
> too much settings to remember to change (enabling paragraph marks,
> setting forward-search, some shortcuts...).

If you think that hitting enter should introduce a plain separator
instead of a parbreak one, this would be accomplished in the sources
with a really trivial change. I choose a parbreak simply because it
is completely equivalent to the old Separator layout.
However, note that when importing old documents, the old Separator
layout has still to be converted to a parbreak separator, otherwise
the output might be changed.

-- 
Enrico
diff --git a/src/Text3.cpp b/src/Text3.cpp
index ee0902a..0933000 100644
--- a/src/Text3.cpp
+++ b/src/Text3.cpp
@@ -1107,13 +1107,11 @@ void Text::dispatch(Cursor & cur, FuncRequest & cmd)
prev = pit - 1;
}
if (prev < pit && cur.pos() == par.beginOfBody()
-   && !par.isEnvSeparator(par.size() ? par.size() - 1 : 0)
+   && !par.size() && !par.isEnvSeparator(cur.pos())
&& !par.layout().isCommand()
&& pars_[prev].layout() != par.layout()
&& pars_[prev].layout().isEnvironment()
-   && (!nextpar.isEnvSeparator(nextpar.size() ? nextpar.size() 
- 1 : 0)
-   || nextpar.layout().isCommand()
-   || nextpar.layout().isEnvironment())) {
+   && !nextpar.isEnvSeparator(nextpar.beginOfBody())) {
if (par.layout().isEnvironment()
&& pars_[prev].getDepth() == par.getDepth()) {
docstring const layout = par.layout().name();

Re: ctests and default output

[Kornel Benko]

Am Dienstag, 12. Januar 2016 um 22:07:59, schrieb Guenter Milde 

> Dear Kornel,
> 
> in order to optimize the autotests, I tried setting the default output of
> the dedicated test sample TableErrorIfSlovakTextInserted.lyx to "dvi".
> 
> (Rationale: the error is an incompatiblity of Babel Czech/Slovak with some
> table code. It does not show up with Polyglossia - no need for *systemF.
> It shows up with every export route using Babel - no need to check all. DVI
> is the least ressource hungry.)
> 
> However, after this change and reconfiguring I get:
> 
> > ctest -N -R Slovak
> Test project /usr/local/src/lyxtest
>   Test #218: AUTOTESTS_export/export/TableErrorIfSlovakTextInserted_lyx16
>   Test #219: AUTOTESTS_export/export/TableErrorIfSlovakTextInserted_lyx21
>   Test #220: lyx2lyx/export/TableErrorIfSlovakTextInserted
>   Test #221: check_load/export/TableErrorIfSlovakTextInserted
>   Test #222: AUTOTESTS_export/export/TableErrorIfSlovakTextInserted_xhtml
>   Test #223: 
> INVERTED.AUTOTESTS.MULTILINGUAL_export/export/TableErrorIfSlovakTextInserted_dvi
>   Test #224: 
> SUSPENDED.AUTOTESTS.MULTILINGUAL_export/export/TableErrorIfSlovakTextInserted_dvi3_texF
>   Test #225: 
> AUTOTESTS_export/export/TableErrorIfSlovakTextInserted_dvi3_systemF
> 
> Total Tests: 8
> 
> I cannot tell about the sensibility or not of xhtml or lyx..

Xhtml and lyx* formats are tested independently of default output.

> with
> "default-output=DVI". However, the still listed tests with LuaTeX (dvi3) seem
> like an oversight in the test-creation scripts.

Yes, if output is set to dvi, then all dvi formats are tested.
The same is valid for pdf, ==> test all pdf formats

Ergo, not oversight but intent.

> Günter

Kornel

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

Re: beta release

[Guillaume Munch]

Le 12/01/2016 22:06, Enrico Forestieri a écrit :

On Tue, Jan 12, 2016 at 04:51:34PM -0500, Scott Kostyshak wrote:

On Tue, Jan 12, 2016 at 10:45:53PM +0100, Enrico Forestieri wrote:


I hope both of you are not serious.


I was completely serious. I did not follow the issue and did not want to
invest the time when I know there were other developers who are familiar
with the issue and thus understand its importance. I think that every
developer should be allowed to propose an issue as a beta blocker and I
would prefer for a separate developer to +1 that proposal.


Then, please don't be surprised that I am scared by the fact that a
stupid thing can be tacken as a blocker.


In any case, Guillaume has withdrawn his proposal that it be a beta
blocker after a discussion on what I view a beta blocker to be (I'm
still interested in feedback on other opinions on that thread if there
are any).


If things like that are blockers, lyx 2.2 would never be released.



Dear Enrico,

Do not worry. With my original message I only meant to inquire about
what was considered a beta blocker, and also I wanted to incite people
to give their opinion about the symbol. Then Scott interpreted it as me
voting for beta blocker status. Also, now I understand that between beta
and release, more things can happen than what I thought. Sorry for the 
scare!


Guillaume

Re: beta release

[Scott Kostyshak]

On Tue, Jan 12, 2016 at 11:06:25PM +0100, Enrico Forestieri wrote:
> On Tue, Jan 12, 2016 at 04:51:34PM -0500, Scott Kostyshak wrote:
> > On Tue, Jan 12, 2016 at 10:45:53PM +0100, Enrico Forestieri wrote:
> > > 
> > > I hope both of you are not serious.
> > 
> > I was completely serious. I did not follow the issue and did not want to
> > invest the time when I know there were other developers who are familiar
> > with the issue and thus understand its importance. I think that every
> > developer should be allowed to propose an issue as a beta blocker and I
> > would prefer for a separate developer to +1 that proposal.
> 
> Then, please don't be surprised that I am scared by the fact that a
> stupid thing can be tacken as a blocker.

You are familiar with the topic and you are against it being a beta
blocker. This is exactly the feedback that I wanted.

> > In any case, Guillaume has withdrawn his proposal that it be a beta
> > blocker after a discussion on what I view a beta blocker to be (I'm
> > still interested in feedback on other opinions on that thread if there
> > are any).
> 
> If things like that are blockers, lyx 2.2 would never be released.

I still have not looked at the issue, but I'm guessing I would agree
with you.

Scott


signature.asc
Description: PGP signature

ctests and default output

[Guenter Milde]

Dear Kornel,

in order to optimize the autotests, I tried setting the default output of
the dedicated test sample TableErrorIfSlovakTextInserted.lyx to "dvi".

(Rationale: the error is an incompatiblity of Babel Czech/Slovak with some
table code. It does not show up with Polyglossia - no need for *systemF.
It shows up with every export route using Babel - no need to check all. DVI
is the least ressource hungry.)

However, after this change and reconfiguring I get:

> ctest -N -R Slovak
Test project /usr/local/src/lyxtest
  Test #218: AUTOTESTS_export/export/TableErrorIfSlovakTextInserted_lyx16
  Test #219: AUTOTESTS_export/export/TableErrorIfSlovakTextInserted_lyx21
  Test #220: lyx2lyx/export/TableErrorIfSlovakTextInserted
  Test #221: check_load/export/TableErrorIfSlovakTextInserted
  Test #222: AUTOTESTS_export/export/TableErrorIfSlovakTextInserted_xhtml
  Test #223: 
INVERTED.AUTOTESTS.MULTILINGUAL_export/export/TableErrorIfSlovakTextInserted_dvi
  Test #224: 
SUSPENDED.AUTOTESTS.MULTILINGUAL_export/export/TableErrorIfSlovakTextInserted_dvi3_texF
  Test #225: AUTOTESTS_export/export/TableErrorIfSlovakTextInserted_dvi3_systemF

Total Tests: 8

I cannot tell about the sensibility or not of xhtml or lyx.. with
"default-output=DVI". However, the still listed tests with LuaTeX (dvi3) seem
like an oversight in the test-creation scripts.

Günter

Re: beta release

[Enrico Forestieri]

On Tue, Jan 12, 2016 at 04:51:34PM -0500, Scott Kostyshak wrote:
> On Tue, Jan 12, 2016 at 10:45:53PM +0100, Enrico Forestieri wrote:
> > 
> > I hope both of you are not serious.
> 
> I was completely serious. I did not follow the issue and did not want to
> invest the time when I know there were other developers who are familiar
> with the issue and thus understand its importance. I think that every
> developer should be allowed to propose an issue as a beta blocker and I
> would prefer for a separate developer to +1 that proposal.

Then, please don't be surprised that I am scared by the fact that a
stupid thing can be tacken as a blocker.

> In any case, Guillaume has withdrawn his proposal that it be a beta
> blocker after a discussion on what I view a beta blocker to be (I'm
> still interested in feedback on other opinions on that thread if there
> are any).

If things like that are blockers, lyx 2.2 would never be released.

-- 
Enrico

Re: beta release

[Scott Kostyshak]

On Tue, Jan 12, 2016 at 10:45:53PM +0100, Enrico Forestieri wrote:
> On Mon, Jan 11, 2016 at 07:30:30PM -0500, Scott Kostyshak wrote:
> > 
> > I looked at the thread (actually it timed out for me but I could search
> > the MID and found it on mail-archive here [1]). From what I see, there
> > is no response to that message.
> 
> Eh, you got a bronze contract service and that only allows for a
> "when time permits" response time. You may get a silver or a gold
> one, but that will increase the price :)

I did not look at the time of the message (silly of me but I had just
assumed it was sent a while ago. Yes, assumptions are bad).

> > Can anyone +1 this issue as a beta blocker? I did not follow the
> > discussion closely.
> 
> I hope both of you are not serious.

I was completely serious. I did not follow the issue and did not want to
invest the time when I know there were other developers who are familiar
with the issue and thus understand its importance. I think that every
developer should be allowed to propose an issue as a beta blocker and I
would prefer for a separate developer to +1 that proposal.

In any case, Guillaume has withdrawn his proposal that it be a beta
blocker after a discussion on what I view a beta blocker to be (I'm
still interested in feedback on other opinions on that thread if there
are any).

Scott


signature.asc
Description: PGP signature

Re: beta release

[Enrico Forestieri]

On Mon, Jan 11, 2016 at 07:30:30PM -0500, Scott Kostyshak wrote:
> 
> I looked at the thread (actually it timed out for me but I could search
> the MID and found it on mail-archive here [1]). From what I see, there
> is no response to that message.

Eh, you got a bronze contract service and that only allows for a
"when time permits" response time. You may get a silver or a gold
one, but that will increase the price :)

> In any case, can you make a trac ticket?
> This would help me because with a trac ticket I can know (1) exactly
> what is the bug (2) when it is determined to be "solved" (because it
> will be marked as fixedinmaster or fixed) and (3) it will be easier for
> me to keep track of as a beta blocker because I review all of the issues
> with a 2.2 milestone tag before releasing.
> 
> Can anyone +1 this issue as a beta blocker? I did not follow the
> discussion closely.

I hope both of you are not serious.

-- 
Enrico

Re: Compilation fails with Mac OS 10.7 (autotools)

[Stephan Witt]

Am 12.01.2016 um 22:24 schrieb Jean-Marc Lasgouttes :
> 
> 
> After boost has been moved to 3rdparty, I notice that linking fails on Mac OS 
> 10.7.
> 
> Stephan, is it the same as what you see? Can it be a config.h problem?

I had this with cmake build when external boost headers come in front of 
../3rdparty/boost/include.
Perhaps you get this with pkg-config because of the detection of libiconv.dylib 
or libz.dylib?
IMO, you have to check the compiler switches of g++ for LayoutFile.cpp => 
LayoutFile.o.

Stephan

PS. I’m trying to avoid every reference to macports libraries and call 
configure with PKG_CONFIG= 
to disable pkg-config from macports.

> 
> JMarc
> 
> Making all in .
> g++ -g -O2 -fno-omit-frame-pointer  -framework AppKit -framework 
> ApplicationServices -Wl,-rpath,@loader_path/../Frameworks 
> -Wl,-rpath,@executable_path/../Frameworks  -o lyx main.o AppleSpellChecker.o 
> AspellChecker.o BiblioInfo.o Box.o Compare.o Dimension.o   PersonalWordList.o 
> LaTeXFonts.o PrinterParams.o Thesaurus.o  liblyxcore.a liblyxmathed.a 
> liblyxinsets.a frontends/liblyxfrontends.a frontends/qt4/liblyxqt4.a 
> liblyxgraphics.a support/liblyxsupport.a ../3rdparty/boost/liblyxboost.a
> -laspell -liconv -lz -F/usr/local/Trolltech/Qt-4.8.6/lib -framework QtSvg 
> -F/usr/local/Trolltech/Qt-4.8.6/lib -framework QtGui 
> -F/usr/local/Trolltech/Qt-4.8.6/lib -framework QtCore
> Undefined symbols for architecture x86_64:
>  "boost::re_detail::raw_storage::insert(unsigned long, unsigned long)", 
> referenced from:
>  boost::re_detail::basic_regex_parser boost::cpp_regex_traits > >::parse_alt()in liblyxcore.a(LayoutFile.o)
>  boost::re_detail::basic_regex_parser boost::cpp_regex_traits > >::parse_repeat(unsigned long, unsigned 
> long)in liblyxcore.a(LayoutFile.o)
>  boost::re_detail::basic_regex_parser boost::cpp_regex_traits > >::parse_perl_extension()in 
> liblyxcore.a(LayoutFile.o)

Compilation fails with Mac OS 10.7 (autotools)

[Jean-Marc Lasgouttes]

After boost has been moved to 3rdparty, I notice that linking fails on 
Mac OS 10.7.


Stephan, is it the same as what you see? Can it be a config.h problem?

JMarc

Making all in .
g++ -g -O2 -fno-omit-frame-pointer  -framework AppKit -framework 
ApplicationServices -Wl,-rpath,@loader_path/../Frameworks 
-Wl,-rpath,@executable_path/../Frameworks  -o lyx main.o 
AppleSpellChecker.o AspellChecker.o BiblioInfo.o Box.o Compare.o 
Dimension.o   PersonalWordList.o LaTeXFonts.o PrinterParams.o 
Thesaurus.o  liblyxcore.a liblyxmathed.a liblyxinsets.a 
frontends/liblyxfrontends.a frontends/qt4/liblyxqt4.a liblyxgraphics.a 
support/liblyxsupport.a ../3rdparty/boost/liblyxboost.a-laspell 
-liconv -lz -F/usr/local/Trolltech/Qt-4.8.6/lib -framework QtSvg 
-F/usr/local/Trolltech/Qt-4.8.6/lib -framework QtGui 
-F/usr/local/Trolltech/Qt-4.8.6/lib -framework QtCore

Undefined symbols for architecture x86_64:
  "boost::re_detail::raw_storage::insert(unsigned long, unsigned 
long)", referenced from:
  boost::re_detail::basic_regex_parserboost::regex_traits > 
>::parse_alt()in liblyxcore.a(LayoutFile.o)
  boost::re_detail::basic_regex_parserboost::regex_traits > 
>::parse_repeat(unsigned long, unsigned long)in liblyxcore.a(LayoutFile.o)
  boost::re_detail::basic_regex_parserboost::regex_traits > 
>::parse_perl_extension()in liblyxcore.a(LayoutFile.o)

Re: User pref parameters

[Guillaume Munch]

Le 12/01/2016 19:36, Georg Baum a écrit :

Pavel Sanda wrote:


Guillaume Munch wrote:

I am not convinced by the naming vcs_simplify_format but maybe there are
other suggestions? What about save_transient_properties or save_state ?


I am fine with save_transient_properties as well. P


me too (and I do not like vcs_simplify_format, since this is really not
limited to using a vcs).





Yet transient is not entirely accurate either.

For instance, \origin is going to cause problems if any collaborator
through a VCS decides to store his own local path (which is a setting
global to lyx!). Should we not set \origin unavailable when
store_user_preferences is false? (I am seriously asking)

Re: beta release

[Scott Kostyshak]

On Tue, Jan 12, 2016 at 08:46:04PM +, Guillaume Munch wrote:

> >>Also, what is this timeout issue? Some people do not get new messages sent
> >>to old threads?
> >
> >I don't understand. Did I bring up the timeout issue? Which quoted text
> >are you referring to?
> 
> below
> 
> >>>I looked at the thread (actually it timed out for me but I could
> >>>search the MID and found it on mail-archive here [1]).

Ah yes. This should show you how poor my memory is. Note that I did
search for emails sent by me with the phrase "timeout" but this did not
return the email because of the space.

By timeout I meant that I opened it in both Chromium and Firefox and it
timed out (i.e. after 1 minute the browsers stopped trying) while other
webpages worked for me. I waited 5 minutes and tried again and had the
same problem. Then I took the MID from the URL (thank you for using a
URL where one can recover the MID!) and used an alternative mail
archiver to find the message thread.

Scott


signature.asc
Description: PGP signature

Re: beta release

[Guillaume Munch]

Le 12/01/2016 20:28, Scott Kostyshak a écrit :


Can anyone +1 this issue as a beta blocker? I did not follow the
discussion closely.



I think this should be done before release. Does it mean that I have to make
it a beta blocker?


No. In my opinion, a beta blocker is something that falls into one of
the following categories:

(1) a fix for a bug that would be so annoying for the user that they
would not give beta1 a good test, and it might even scare them from
testing future pre-release versions of LyX.

(2) a fix that us developers can't test completely ourselves and we
would need a wider test base to be confident in a change before a
release with it. In this category I put Windows-specific and
Mac-specific bugs, for example. Also bugs that we weren't able to
reproduce ourselves (and thus we cannot check whether a fix really does
fix anything). I think removing the PNGs was a good example of this. I
would not have wanted to do that after beta. Thankfully one of our
alpha-testers, Andrew, caught a problem that occurs on Windows. I'm now
confident in the change and I'm glad we have it for 2.2.0.

(3) a bug fix that represents a big change and we are unsure of
possible unwanted consequences. We would not want to put this in a final
release directly.

Note that I just made up the above three categories. I would be
interested in your thoughts and the thoughts of others and would add
these to the release manager notes that I am collecting.


Not a beta blocker then.



Also, what is this timeout issue? Some people do not get new messages sent
to old threads?


I don't understand. Did I bring up the timeout issue? Which quoted text
are you referring to?


below


I looked at the thread (actually it timed out for me but I could
search the MID and found it on mail-archive here [1]).

Re: beta release

[Scott Kostyshak]

On Tue, Jan 12, 2016 at 03:28:28PM -0500, Scott Kostyshak wrote:

> > I think this should be done before release. Does it mean that I have to make
> > it a beta blocker?
> 
> No. In my opinion, a beta blocker is something that falls into one of
> the following categories:
> 
> (1) a fix for a bug that would be so annoying for the user that they
> would not give beta1 a good test, and it might even scare them from
> testing future pre-release versions of LyX.
> 
> (2) a fix that us developers can't test completely ourselves and we
> would need a wider test base to be confident in a change before a
> release with it. In this category I put Windows-specific and
> Mac-specific bugs, for example. Also bugs that we weren't able to
> reproduce ourselves (and thus we cannot check whether a fix really does
> fix anything). I think removing the PNGs was a good example of this. I
> would not have wanted to do that after beta. Thankfully one of our
> alpha-testers, Andrew, caught a problem that occurs on Windows. I'm now
> confident in the change and I'm glad we have it for 2.2.0.
> 
> (3) a bug fix that represents a big change and we are unsure of
> possible unwanted consequences. We would not want to put this in a final
> release directly.
> 
> Note that I just made up the above three categories. I would be
> interested in your thoughts and the thoughts of others and would add
> these to the release manager notes that I am collecting.

I want to add that I think our situation is special because we are
really hoping that there is only one beta release (we have not said this
explicitly but I think it is easy to pick up on this sentiment from
almost every developer). If we were open to multiple betas and time was
not so much a concern, then I would say that only category (1) issues
above are blockers for beta1 and the other two categories could be
blockers for e.g. beta2. This also assumes though that we have a wide
enough test base of users. For example, I'm not sure that those who test
beta1 would also be willing to invest the time and risk to test beta2. I
will announce beta1 widely and get some publicity for it (on various
sites that cover LaTeX and software and open source). I kind of view it
as a one-time shot that we have to get it right. If we mess something
up, then we waste publicity and also lose reputation for future testers.
Of course, beta is beta and if there is a big problem it is not so
unexpected so I don't think that *so* much is at stake, but I think it
is good to pretend that it is :)

Scott


signature.asc
Description: PGP signature

Re: beta release

[Scott Kostyshak]

On Tue, Jan 12, 2016 at 05:30:14PM +, Guillaume Munch wrote:
> Le 12/01/2016 00:30, Scott Kostyshak a écrit :
> >On Mon, Jan 11, 2016 at 06:28:02PM +, Guillaume Munch wrote:
> >>Le 09/01/2016 00:15, Scott Kostyshak a écrit :
> >>>
> >>>Does any one view an issue as a beta blocker?
> >>
> >>The situation with the parbreak separator is not good and I would see
> >>changing its symbol and fixing the insertion of an empty environment
> >>before with Enter (described at the beginning of
> >>) as blocker for 2.2;
> >>thus it would be good if it is fixed for beta.
> >>
> >>Fortunately Enrico has already addressed a few issues and the fix for
> >>empty environment insertion should be easy. In addition, there have been
> >>suggestions for replacing the parbreak symbol. If anybody has an opinion
> >>on the symbol do not hesitate to share it.
> >
> >I looked at the thread (actually it timed out for me but I could search
> >the MID and found it on mail-archive here [1]). From what I see, there
> >is no response to that message. In any case, can you make a trac ticket?
> >This would help me because with a trac ticket I can know (1) exactly
> >what is the bug (2) when it is determined to be "solved" (because it
> >will be marked as fixedinmaster or fixed) and (3) it will be easier for
> >me to keep track of as a beta blocker because I review all of the issues
> >with a 2.2 milestone tag before releasing.
> >
> >Can anyone +1 this issue as a beta blocker? I did not follow the
> >discussion closely.
> 
> 
> I think this should be done before release. Does it mean that I have to make
> it a beta blocker?

No. In my opinion, a beta blocker is something that falls into one of
the following categories:

(1) a fix for a bug that would be so annoying for the user that they
would not give beta1 a good test, and it might even scare them from
testing future pre-release versions of LyX.

(2) a fix that us developers can't test completely ourselves and we
would need a wider test base to be confident in a change before a
release with it. In this category I put Windows-specific and
Mac-specific bugs, for example. Also bugs that we weren't able to
reproduce ourselves (and thus we cannot check whether a fix really does
fix anything). I think removing the PNGs was a good example of this. I
would not have wanted to do that after beta. Thankfully one of our
alpha-testers, Andrew, caught a problem that occurs on Windows. I'm now
confident in the change and I'm glad we have it for 2.2.0.

(3) a bug fix that represents a big change and we are unsure of
possible unwanted consequences. We would not want to put this in a final
release directly.

Note that I just made up the above three categories. I would be
interested in your thoughts and the thoughts of others and would add
these to the release manager notes that I am collecting.

> I just posted the message on Sunday. I will open a bug report shortly but
> will first wait a bit for an reply from Enrico (this already helped reduce
> the number of bugs to report on the tracker).

Makes sense. Keep us updated.

> Also, what is this timeout issue? Some people do not get new messages sent
> to old threads?

I don't understand. Did I bring up the timeout issue? Which quoted text
are you referring to?

Scott


signature.asc
Description: PGP signature

Re: User pref parameters

[Scott Kostyshak]

On Tue, Jan 12, 2016 at 05:18:40PM +, Guillaume Munch wrote:
> Le 12/01/2016 02:23, Pavel Sanda a écrit :
> >Guillaume Munch wrote:

> Scott, do you sum up all these messages as a "+1", as you say?

After a quick look, I do think there is a +1.

Scott


signature.asc
Description: PGP signature

Re: User pref parameters

[Georg Baum]

Pavel Sanda wrote:

> Guillaume Munch wrote:
>> I am not convinced by the naming vcs_simplify_format but maybe there are
>> other suggestions? What about save_transient_properties or save_state ?
> 
> I am fine with save_transient_properties as well. P

me too (and I do not like vcs_simplify_format, since this is really not 
limited to using a vcs).


Georg

Re: why Babel with dvi3 (LuTeX)?

[Georg Baum]

Scott Kostyshak wrote:

> I strongly agree with Georg as for the good unit tests that we have. But
> for our export tests and specifically our export tests known to be
> unreliable, I understand Günter's objection that it could be just a lot
> of wasted time.

I should clarify that a prerequisite of my recommendation is that all tests 
that are used in this workflow are always green and do not take ages. This 
does rule out all unreliable tests and all tests that depend on very up to 
date TeXLive or special packages. IMHO it does not rule out all export ests 
(especially not the dedicated ones in autotests/export/, and it would also 
be nice if we had a smaller subset of the export tests that run on the doc 
files which could be used.

> However, as for the statement "the test suite is cleaned up in a couple
> of days whenever new test failures are noticed", I want to caution that
> in a couple of days, sometimes there are many changes that are committed
> and it might not be clear which commit caused a change and why. Doing a
> bisect and figuring out the change and then asking the author of the
> commit that caused the change and then waiting for that author's
> response and then running the tests after applying whatever patch that
> author implies should be made can in the end take up 5x more time than
> if the author had just run the tests and incorporated the changes with
> explanations into his commit.

Yes, such a workflow does not work. I understood Günters comment a little 
bit different, namely that the author of a commit would check himself the 
test failures, just not before submitting the change, but sometimes a few 
days later.


Georg

Re: compilation problems with Qt 5.5.1 and MSVC 2010

[Georg Baum]

Am 12.01.2016 um 00:37 schrieb Uwe Stöhr:

I did this now as I wrote in the
Questions for Uwe once you are back
thread.
I had to delete CMake's cache first and re-run it from scratch. The 
3rd party programs are compiled (with 134 warnings) but I don't get a 
DLL. Is this the plan - not to rely anymore on DLLs?


Almost. The libs are currently compiled as static libraries. But this is 
not the most important aspect. The main goal of having these sources 
included with LyX is that no externally compiled prerequisites are 
needed anymore (except for qt). This has two advantages:


1) It makes it more easy for other people to build LyX on windows, even 
if they have a different compiler than you. I hope that this will 
attract other people who build on windows in the long term, so that you 
do not need to do everything alone.


2) It eliminates all possibillities of errors that may occur because of 
different compilers. This makes it more easy for you to switch to a new 
MSVC version.


If it turns out that for some reason having one of these thirdparty 
libraries as dll has advantages, we could also change the build 
procedure to produce dlls from the same sources.



Georg

MinGW: development/cmake/mingw.bat

[Peter Kümmel]

Hi Uwe, could you try development/cmake/mingw.bat.

Call it from any path. The script creates the build folder
"compile-mingw". Only requirement is that msvc2010-deps
is on the same level as the lyx source dir (and the C:\Qt
installation)

After the build there is a LYX_INSTALLED dir with the
files which you should pass to NSIS. If any file is
missing in LYX_INSTALLED we should fix cmake.

I really hope this simplifies the Windows build.

Peter

Re: Questions for Uwe once you are back

[Peter Kümmel]

The cache needs to be deleted (as you discovered already).


I'll push a script which deletes the complete build dir, cleanest way.




For now I also need the info about Qt 5. What is the expected build
target for beta1? My time is limited and I have to focus on one Qt
version. I installed Qt 5.6 beta for mingw and mingw itself. Is this the
way I should go?


That depends whether you want to learn mingw or not. Concerning qt 5.6 I


Nothing really to learn, just install Qt and use the default paths.



belive the release dates Scott sent do pretty much rule it out (it will be
finished too late), so the question is whether qt 5.5 works wel enough on
windows.


As usual LyX would be late anyway, just lets wait for 5.6.0 when 
releasing the Windows installer.





Can you please explain which errors you see (or fear to see) if not
building from the tar ball only?


I need to run CMake again spending half an hour to setup all the many
paths there. This sucks. With a new branch I work in the same directory
as always.


Don't touch the committed build batch file ever. All dirs should be
fixed, and the rest should be relative. I'll prepare a script, which
produces a running LyX version which should be uses by NSIS.

The scripts will only require a dir where the deps saved.



Sorry, I still do not understand. Which paths need to be setup? What takes


He talks about the development/cmake/build* scripts, full with pathes.


long (a manual step or some program that runs)? When I run cmake on linux on
a freshly unpacked source tree I do not need to setup any path, and running
cmake is very fast. It should be possible to do the same on windows. For
reference, here is my procedure as pseudocode:

- unpack source in srcdir
- make build directory builddir
- copy build script to srcdir (this is the equivalent of your build.bat. I
can only think of one path that might need to be adjusted in this script:
The path to the cmake installation (if cmake is not in the system PATH
anyway).
- go to builddir
- call build script

No path adjustments are needed. Which step of this procedure would look
different in your case?


This is very important, because building from the
unpacked tar ball is the only way to ensure that the built executable is
built from the correct sources and without any possible local change. Do
you remember the problem with one of the alphas where much time was
wasted because the installer was not built from unmodified alpha sources?


As I wrote, I make mistakes. I did not had much time to test the alpha
installer. Normally I have at least a day and can check on 4 different
PCs and the buggy installer would have been uncovered.


Everybody makes mistakes. Therefore it is so important to design the
workflow in such a way that the chances for making mistakes are minimized.
If you mix parts from git and parts from a source archive, the chances for
making mistakes are much higher.


Georg

Re: Questions for Uwe once you are back

[Georg Baum]

Uwe Stöhr wrote:

> Am 11.01.2016 um 21:22 schrieb Georg Baum:
> 
>> I don't know whether he got them from you or directly from the original
>> download pages, but this does not matter. What matters is that you get a
>> consistent build and eliminate possible errors if you use these sources
>> (by enabling the 3RDPARTY_BUILD swithc as I wrote in the other message).
> 
> I need a pointer here. There are too many posts I cannot read them all.
> What do I have to do? Adding
> -LYX_3RDPARTY_BUILD=ON
> to my build script does not work:
> 
> CMake Error: The source directory
> "D:/LyXGit/Master/compile-2010/-LYX_3RDPARTY_BUILD=ON" does not exist.
> Specify --help for usage, or press the help button on the CMake GUI.
> 
> Maybe I will have to delete the CMake cache before and then re-run
> Cmake. I'll check this now.

The cache needs to be deleted (as you discovered already).
 
> For now I also need the info about Qt 5. What is the expected build
> target for beta1? My time is limited and I have to focus on one Qt
> version. I installed Qt 5.6 beta for mingw and mingw itself. Is this the
> way I should go?

That depends whether you want to learn mingw or not. Concerning qt 5.6 I 
belive the release dates Scott sent do pretty much rule it out (it will be 
finished too late), so the question is whether qt 5.5 works wel enough on 
windows.

>> Can you please explain which errors you see (or fear to see) if not
>> building from the tar ball only?
> 
> I need to run CMake again spending half an hour to setup all the many
> paths there. This sucks. With a new branch I work in the same directory
> as always.

Sorry, I still do not understand. Which paths need to be setup? What takes 
long (a manual step or some program that runs)? When I run cmake on linux on 
a freshly unpacked source tree I do not need to setup any path, and running 
cmake is very fast. It should be possible to do the same on windows. For 
reference, here is my procedure as pseudocode:

- unpack source in srcdir
- make build directory builddir
- copy build script to srcdir (this is the equivalent of your build.bat. I 
can only think of one path that might need to be adjusted in this script: 
The path to the cmake installation (if cmake is not in the system PATH 
anyway).
- go to builddir
- call build script

No path adjustments are needed. Which step of this procedure would look 
different in your case?

>> This is very important, because building from the
>> unpacked tar ball is the only way to ensure that the built executable is
>> built from the correct sources and without any possible local change. Do
>> you remember the problem with one of the alphas where much time was
>> wasted because the installer was not built from unmodified alpha sources?
> 
> As I wrote, I make mistakes. I did not had much time to test the alpha
> installer. Normally I have at least a day and can check on 4 different
> PCs and the buggy installer would have been uncovered.

Everybody makes mistakes. Therefore it is so important to design the 
workflow in such a way that the chances for making mistakes are minimized. 
If you mix parts from git and parts from a source archive, the chances for 
making mistakes are much higher.


Georg

Re: User pref parameters

[Pavel Sanda]

Guillaume Munch wrote:
> I am not convinced by the naming vcs_simplify_format but maybe there are
> other suggestions? What about save_transient_properties or save_state ?

I am fine with save_transient_properties as well. P

Re: Basic test of alpha1 tar

[Pavel Sanda]

Jean-Marc Lasgouttes wrote:
> Le 12/01/2016 10:15, Pavel Sanda a écrit :
>> Jean-Marc Lasgouttes wrote:
 More important is - can you reproduce the behaviour? It's pretty clear 
 on my
 machine without trying any special conditions, just high repeat rate of 
 the
 keyboard is needed.
>
> I only tried 2.2, so I did not really compare. I do not have 2.0 here. I 
> can try to have a look at 2.1 vs 2.2 later.

Please try, we should see whether the problem is reproducible at all...
Pavel

Re: beta release

[Guillaume Munch]

Le 12/01/2016 00:30, Scott Kostyshak a écrit :

On Mon, Jan 11, 2016 at 06:28:02PM +, Guillaume Munch wrote:

Le 09/01/2016 00:15, Scott Kostyshak a écrit :


Does any one view an issue as a beta blocker?


The situation with the parbreak separator is not good and I would see
changing its symbol and fixing the insertion of an empty environment
before with Enter (described at the beginning of
) as blocker for 2.2;
thus it would be good if it is fixed for beta.

Fortunately Enrico has already addressed a few issues and the fix for
empty environment insertion should be easy. In addition, there have been
suggestions for replacing the parbreak symbol. If anybody has an opinion
on the symbol do not hesitate to share it.


I looked at the thread (actually it timed out for me but I could search
the MID and found it on mail-archive here [1]). From what I see, there
is no response to that message. In any case, can you make a trac ticket?
This would help me because with a trac ticket I can know (1) exactly
what is the bug (2) when it is determined to be "solved" (because it
will be marked as fixedinmaster or fixed) and (3) it will be easier for
me to keep track of as a beta blocker because I review all of the issues
with a 2.2 milestone tag before releasing.

Can anyone +1 this issue as a beta blocker? I did not follow the
discussion closely.



I think this should be done before release. Does it mean that I have to 
make it a beta blocker?


I just posted the message on Sunday. I will open a bug report shortly 
but will first wait a bit for an reply from Enrico (this already helped 
reduce the number of bugs to report on the tracker).


Also, what is this timeout issue? Some people do not get new messages 
sent to old threads?

Re: #9794: inset-modify tabular commands are incorrectly disabled

[Guillaume Munch]

Le 12/01/2016 01:42, Pavel Sanda a écrit :

Guillaume Munch wrote:

Actually yes I am documenting a new rule, but it isn't mine. The new
rule requires a LFUN format increment and a LyX format increment


Do you have by chance link to LFUN format increment discussion at hand?
(I have no clue what is meant by LFUN format number). P



I think it started on the list but moved over to
http://www.lyx.org/trac/ticket/9794 during the ML shortage.

The LFUN format number is found in LyXAction.cpp and
prefs2prefs_lfuns.py, and is used for bind and ui files.


Here's the new text in Development.lyx:

“A change to the functionality of existing LFUNs can require a 
conversion of .bind and .ui files, and therefore an increment of the 
LFUN format, as well as a conversion of Info insets in .lyx files for 
manuals. The latter cannot be done automatically and requires also a LyX 
format increase (think of e.g. someone who might have made a set of LyX 
teaching manuals for use in their own 
group)[http://www.lyx.org/trac/ticket/9794].


1. Increment the LFUN file format number in src/LyXAction.h.

2. Implement the LFUN conversion in lib/scripts/prefs2prefs_lfuns.py

3. See step [enu:updatefiles] in section [subsec:update_lyx_files] but 
instead of the updatedocs.py command, use this command: bash 
development/tools/updatelfuns.sh.


4. Update Info insets in .lyx files. To do so, increment the LyX format 
and proceed as in [subsec:update_lyx_files], steps 
[enu:Describe_format]-[enu:updatefiles]. In the lyx2lyx implementation 
([enu:Add-an-entry]th step), implement a conversion similar to the one 
in prefs2prefs_lfuns.py above, as well as a corresponding reversion; for 
this one can use convert_info_insets from lib/lyx2lyx/lyx2lyx_tools.py.”

Re: User pref parameters

[Guillaume Munch]

Le 12/01/2016 02:23, Pavel Sanda a écrit :

Guillaume Munch wrote:

I understand this idea of "freezing" the setting, in order to set a
custom value on opening. The current approach I have in mind is to read
and save to a per-user-per-document (cursor-location-like) setting when
save_user_preferences is false, so that the value on opening corresponds
to the user's previous session. The two approaches are in conflict, so
one has to choose between the two.


Yep, that's basically the same conflict which started the whole issue
("choosing a setting for everybody else"). You know my opinion about the
issue, but since you are the one who implements it and there is indeed
partial overlap with "\save_user_preferences true" go ahead :)

Cosmetic thing - the naming "save_user_preferences" is confusing precisely
because there are diverging opinions what user vs document pref is
so maybe using for file format something like vcs_simplify_format
or similar would be better.




Thanks.

I am not convinced by the naming vcs_simplify_format but maybe there are
other suggestions? What about save_transient_properties or save_state ?
I would rather avoid a name that refers to a particular purpose rather
than the actual effect.


Scott, do you sum up all these messages as a "+1", as you say?

Re: [patch] Display the correct horizontal alignment in AMS environments

[Guillaume Munch]

Le 11/01/2016 21:41, Georg Baum a écrit :

Guillaume Munch wrote:


I replace stored alignment and spacing values with computed values, only
in the case of specific grids under discussion (Eqnarray, AMS...). Thus,
defaultColAlign() can still make sense in the future for grids that rely
on stored alignment and spacing, and I do not see what makes it useful
to remove it entirely.


OK, I see. My argument for removing defaultColAlign() was that we do not
want to have dead code, but I overlooked that it is still used in the base
class, so the only thing which could be removed is the "virtual" keyword
(but I don't have a strong opinion on that).


About "defaultColAlign() is not only used for display": you mean that it
is risky to change the behaviour of stored values. Let us admit that
there is still a risk despite all my checks. Then, I proposed to keep
the default values to be extra safe just above your remark which makes
me think that you may have missed it.


I believe that I understood the intention of your patch. However, I found
surprising behaviour in mathed in the past, and the motivation for my
comments was to ensure that you do not trap into this pitfall as well.


(But in any case these stored values are necessarily wrong since they
are not saved to the file for the environments under consideration. I am
highly sceptical that a bug could remain open for so long if it caused
more than a display bug to which users got accustomed.)


There are some hidden parts of mathed which have no user interface. I would
not bet that these settings are not written under any circumstances (but I
agree that a bug in the usual cases would have been found earlier, so we can
assume they work).


Again this misses the point. There is nothing to "repair" about
defaultColSpace(). If there is still any buggy behaviour regarding the
spacing or alignment then they should be changed to read the computed
values that I introduce. Same remark about keeping defaultColSpace in
order to be extra safe.


I am sorry, you are right, I was not careful anymore at the end of the
message.


If anything, please continue! Also, this is a software that many people
(including me) depend on professionally, so I do not understand this
notion that developing LyX is supposed to be "Spaß".


Well, in total it is supposed to make fun (at least for me, otherwise I
would stop contributing).


See the attached for two "safe" (and easy to read) patches, if you agree
that a safe patch that we have been discussing for a month can still get
in for 2.2.


I started to review the patch, but stopped when I found a difference between
the old and new behaviour of InsetMathHull::defaultColAlign() for
hullRegexp, since I don't have so much time at the moment. Again, this
combination is most likely not used, but "most likely" is not enough IMHO
for a beta.

Why is it so important to fix this bug before 2.2.0 when it is known for so
many years already? BTW, it did annoy me a lot when I wrote my thesis
(therefore my attempt to fix it many vears ago), but since I did not find a
proper solution at that time I simply got used to the wrong display (which
was not too difficult).

If you were proposing to fix the bug at the beginning of the 2.3 development
cycle then we could skip most parts of this discussion and you could simply
submit it. As I understand it, we do all agree that the proposed change is
good, the only differences are in judging the risk.





As you have noticed, this hull is constrained to a single cell. It
gets right-aligned because the commit that added hullRegexp after
hullAlign in the HullType enum did not change anything to
defaultColAlign() which reads:
if (type_ >= hullAlign)
return "rl"[col & 1];
This hull is only ever used in the Advanced Search & Replace panel. It
is not used for output and not meant to appear in a lyx file (in fact if
you try to save it in a file using copy/paste, then the parsing on
opening is broken, in a way that makes me confident that it has never
been used in a lyx document). So it is not about the alignment being
"most likely" not used. It is about the fact that this hull serves a
limited purpose that obviously has nothing to do with this
right-alignment (and that can be tested in a straightforward manner).

However, if you do not have the time, this is a sufficient reason by
itself. I am not forcing you to read these patches, and you do not need
an excuse.

I am confident in the two patches and I will wait and see if somebody
else is ready to vouch for it.



Also, I find that the fact that the issue matters and that the patch is
straightforward and risk-free have been good enough reasons to solve it
at this stage.

Maybe one more thing we are in disagreement about is your implication
that this is a secondary issue just because you (and other people)
"simply got used to the wrong display". Currently, new users not only
have to learn lyx ways but also have to get accustomed to its many
quirks 

Re: make distcheck: cannot remove '../../po/lyx.pot'

[Kornel Benko]

Am Dienstag, 12. Januar 2016 um 14:47:35, schrieb Jean-Marc Lasgouttes 

> Le 12/01/2016 03:51, Scott Kostyshak a écrit :
> > I wonder if the difference in behavior is due to:
> > http://lists.gnu.org/archive/html/automake/2012-07/msg00023.html
> >
> > That thread is linked to on the main page:
> > https://www.gnu.org/software/automake/
> 
> It is interesting but I fail to see how this could make a problem for 
> us. The only difference in the fix is giving write permission to user 
> instead of world. However, when we run distcheck, only one the current 
> user counts.
> 
> > It would be nice to know what happens with 1.15. Ubuntu 15.10 has 1.15
> > so I will try to do a fresh install and check it out. Not sure when
> > though.
> 
> I just tried it and it worked without problem. Actually, I suspect that 
> there is some timing problem that creates wrong dependencies between files.
> 
> JMarc

I fail to see the problem there.
In _my_ am/distdir.am, there already are the correct statements.
They read as follows (from distdir.am:429)
## this case.  However, make the top-level directory writable so we
## can make our new subdirs.
chmod -R a-w $(distdir)
chmod u+w $(distdir)
mkdir $(distdir)/_build $(distdir)/_inst
## Undo the write access.
chmod a-w $(distdir)

Still, 'make distcheck' fails.

Kornel

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

Re: make distcheck: cannot remove '../../po/lyx.pot'

[Jean-Marc Lasgouttes]

Le 12/01/2016 03:51, Scott Kostyshak a écrit :

I wonder if the difference in behavior is due to:
http://lists.gnu.org/archive/html/automake/2012-07/msg00023.html

That thread is linked to on the main page:
https://www.gnu.org/software/automake/


It is interesting but I fail to see how this could make a problem for 
us. The only difference in the fix is giving write permission to user 
instead of world. However, when we run distcheck, only one the current 
user counts.



It would be nice to know what happens with 1.15. Ubuntu 15.10 has 1.15
so I will try to do a fresh install and check it out. Not sure when
though.


I just tried it and it worked without problem. Actually, I suspect that 
there is some timing problem that creates wrong dependencies between files.


JMarc

Re: Questions for Uwe once you are back

[Peter Kümmel]

For now I also need the info about Qt 5. What is the expected build
target for beta1? My time is limited and I have to focus on one Qt
version. I installed Qt 5.6 beta for mingw and mingw itself. Is this the
way I should go?


Yes, that would be great!
It looks like the paths will also not change after the release of 5.6.0
(default is C:\Qt\Qt5.6.0) So I would like to add one .bat script
for the mingw build with most paths hardcoded. Maybe we could even
agree where to put the lyx sources/build dir.

Then lets release a lyx beta MinGW build with the Qt 5.6 beta and
when 5.6 is out just make the the final lyx with the 5.6.0.





Sure. I try to do this but I am a human making mistakes. And the path
handling stuff for the compiler is error-prone as hell. Thus I simply
create a new branch in my git putting there the files from the tar. This
assures that the compilation paths are correct.


Can you please explain which errors you see (or fear to see) if not
building
from the tar ball only?


I need to run CMake again spending half an hour to setup all the many
paths there. This sucks. With a new branch I work in the same directory
as always.


This is very important, because building from the
unpacked tar ball is the only way to ensure that the built executable is
built from the correct sources and without any possible local change.
Do you
remember the problem with one of the alphas where much time was wasted
because the installer was not built from unmodified alpha sources?


As I wrote, I make mistakes. I did not had much time to test the alpha
installer. Normally I have at least a day and can check on 4 different
PCs and the buggy installer would have been uncovered.

regards Uwe

Re: compilation problems with Qt 5.5.1 and MSVC 2010

[Peter Kümmel]

Am 12.01.2016 um 00:37 schrieb Uwe Stöhr:

I had to delete CMake's cache first and re-run it from scratch. The 3rd
party programs are compiled (with 134 warnings) but I don't get a DLL.
Is this the plan - not to rely anymore on DLLs?


Yes, no Dlls any more (only the Qt related ones).



thanks and regards
Uwe

Re: Basic test of alpha1 tar

[Jean-Marc Lasgouttes]

Le 12/01/2016 10:15, Pavel Sanda a écrit :

Jean-Marc Lasgouttes wrote:

More important is - can you reproduce the behaviour? It's pretty clear on my
machine without trying any special conditions, just high repeat rate of the
keyboard is needed.


I only tried 2.2, so I did not really compare. I do not have 2.0 here. I 
can try to have a look at 2.1 vs 2.2 later.



I think sysprof is better choice because gprof will hide calls to 3rd
party libs which matter.


Yes, sysprof is better and I used to rely on it, but my luck is running 
out in amd64. Looks like google-perftools may be a good thing to try.



I was quite surprised how much took macro updates, but I think it's both
cases, thus not culprit of our problem.


Yes, macro updates are a big pain, especially since they also happen for 
documents that do not contain any macro :(


JMarc

Re: Basic test of alpha1 tar

[Pavel Sanda]

Jean-Marc Lasgouttes wrote:
> Le 11/01/2016 10:59, Pavel Sanda a écrit :
>> Jean-Marc Lasgouttes wrote:
>>> I reproduce the svg you sent for 2.2, since it is not so large either :)
>>
>> More important is - can you reproduce the behaviour? It's pretty clear on my
>> machine without trying any special conditions, just high repeat rate of the
>> keyboard is needed.
>
> I tried to play with different profilers at the time.

Sorry, by reproducing I meant just seeing the problem visually without
really trying any profiling stuff. I'm just fearing I observe my graphic
card issue, it wouldn't be the first time...

> * I cannot get sysprof to give nice trees anymore. Are you on a 64bit 
> target? It seems to me that life was simpler when I was in 32 bits linux.

That was 32 bit. For trees you need to save file and then run:
gprof2dot  -f sysprof saved_file |dot -Tsvg -o sysprof.svg

Any better now?

> * I tried perf, but I am not sure what to do with it. Again, I do not get 
> nice trees.

IIRC I needed to compile with --enable-build-type=gprof, gmon.out is created
while running lyx, then you need to run
gprof src/lyx gmon.out > gprof.txt

For visualizing trees:
gprof2dot gmon.out |dot -Tsvg -o full.svg

I think sysprof is better choice because gprof will hide calls to 3rd
party libs which matter.

Not so long ago Guilliame added Callgrind section into wiki. I didn't
have time to try it but it look really cool on screenshots, you might
want to try that.

> At some time, I convinced my self that there is as much time spent in 
> toolbar updates than in painting itself. The reason is (would be) that it 
> uses BufferParams::isExportable which does a full graph search in 
> converters for each icon that we might want to enable.

I was quite surprised how much took macro updates, but I think it's both
cases, thus not culprit of our problem.

> I did not spend more time to investigate this, especially since we are 
> moving office to Paris center next Thursday.

>>> * is this a 2.2 built in release mode?
>>
>> 2.2 was build with O2 & enabled debug symbols, 2.0 was release mode (i.e.
>> including O2) but the completely stripped off the symbols after 
>> compilation.
>
> Yes, but did you use --disable-stdlib-debug? This slows down LyX quite a 
> bit. Using --enable_build-type=prof is nice because it uses the right flags 
> for profiling.

disable-stdlib-debug should have been off for both cases.

Pavel