Re: [LyX/master] Introduce "inverted" branch insets: These are branches whose content is output when a branch is NOT activated. Fixes bug #7698.

[Scott Kostyshak]

On Sun, Aug 07, 2016 at 09:29:31PM -0400, Richard Heck wrote:
> On 08/07/2016 03:24 PM, Scott Kostyshak wrote:
> > On Tue, Jul 12, 2016 at 05:57:41AM +0200, Richard Heck wrote:
> >> commit 5df323a0dd564f00c5ab085a3570957ad76b21d3
> >> Author: Richard Heck 
> >> Date:   Mon Jul 11 23:56:32 2016 -0400
> >>
> >> Introduce "inverted" branch insets: These are branches whose content
> >> is output when a branch is NOT activated. Fixes bug #7698.
> >> 
> >> At the moment, inversion is controlled through the branch settings
> >> dialog. There is no provision for inserting inverted insets directly,
> >> or for changing them from the context menu. Both of these could be
> >> done, of course. The latter would need LFUN_BRANCH_TOGGLE_INVERTED.
> > This commit broke tex2lyx tests.
> 
> I'm not sure why this would be.
> 
> > If the lyx2lyx conversion from the old to the new format is empty, or
> > if tex2lyx does not yet output the changed feature, you do not need
> > any further tex2lyx changes. LyX Document 
> 
> Surely tex2lyx does not know about branches?

No but it does not know that it does not need to know about branches :)

I don't know much about these tests, but from what I understand the
tests compare .lyx files created from tex2lyx to reference .lyx files.
These reference .lyx files are files that we know to be correct. Thus we
compare .lyx files created from tex2lyx to .lyx files that we know
tex2lyx used to produce. If there is any file format change (such as
this one), the .lyx files will not be equal. Thus, the format of the
reference .lyx files needs to be updated. This must be done with care
and manual inspection is required (that is why it is not automated).

I'm not sure if I got that right. To be sure take a look at "Section
4.2.2 Updating test references" in Development.lyx for a detailed
explanation by Georg. Note that this section is referenced by Section
2.3 (the "How to update the file format" section).

Scott


signature.asc
Description: PGP signature

Re: Should the author of a file format change update the file format of docs in master?

[Richard Heck]

On 08/07/2016 08:00 PM, Scott Kostyshak wrote:
> When making a file format change, we currently have instructions for the 
> author of the file format change to update the file format of the docs.
>
> [snip]
>
> Also, I wonder if updating the file format is annoying to document
> maintainers because they sometimes will need to compile the latest
> version of master in order to work on the documentation.

I'd like to hear from Uwe about this.

Richard

Re: [LyX/master] Introduce "inverted" branch insets: These are branches whose content is output when a branch is NOT activated. Fixes bug #7698.

[Richard Heck]

On 08/07/2016 03:24 PM, Scott Kostyshak wrote:
> On Tue, Jul 12, 2016 at 05:57:41AM +0200, Richard Heck wrote:
>> commit 5df323a0dd564f00c5ab085a3570957ad76b21d3
>> Author: Richard Heck 
>> Date:   Mon Jul 11 23:56:32 2016 -0400
>>
>> Introduce "inverted" branch insets: These are branches whose content
>> is output when a branch is NOT activated. Fixes bug #7698.
>> 
>> At the moment, inversion is controlled through the branch settings
>> dialog. There is no provision for inserting inverted insets directly,
>> or for changing them from the context menu. Both of these could be
>> done, of course. The latter would need LFUN_BRANCH_TOGGLE_INVERTED.
> This commit broke tex2lyx tests.

I'm not sure why this would be.

> If the lyx2lyx conversion from the old to the new format is empty, or
> if tex2lyx does not yet output the changed feature, you do not need
> any further tex2lyx changes. LyX Document 

Surely tex2lyx does not know about branches?

Richard

Should the author of a file format change update the file format of docs in master?

[Scott Kostyshak]

When making a file format change, we currently have instructions for the
author of the file format change to update the file format of the docs.
The following excerpt is in Development.lyx in Section 2.3:

  Update LyX's .lyx documentation files to the new format. The developer
  who makes the change knows best what changes to expect when inspecting
  the resulting diff. Because of this, you might be able to catch a bug
  in the lyx2lyx code that updates the format just by taking a quick
  scan through the large diff that is the result. Another advantage is
  that if later we suspect a bug in lyx2lyx we can easily see which
  layout update made an unexpected change by looking at the git log of a
  .lyx file that suffers the problem. To do this, first make sure that
  there are no changes to the git repository that you will not want to
  commit (this is needed because it will be convenient to commit with
  the command git commit -a). Then run the following command in the root
  folder of the source: python development/tools/updatedocs.py. Look at
  the resulting changes using the command git diff. If anything looks
  surprising, please investigate. Keep in mind that the case of
  LFUNs.lyx is special, because it is first generated with gen_lfuns.py
  before being converted to the latest format. Finally, commit using git
  commit -a.

I wrote that after what I recall being a discussion in a sub-thread. I
wonder now if I should have made a separate discussion on the list, so
I'm doing that now. Do others agree with the above paragraph? I have not
actually authored many file format changes myself, so perhaps my
intuition is off here.

Also, I wonder if updating the file format is annoying to document
maintainers because they sometimes will need to compile the latest
version of master in order to work on the documentation.

Please feel free to edit the above paragraph in Development.lyx.

Scott


signature.asc
Description: PGP signature

Re: QFile::remove: Empty or null file name

[Scott Kostyshak]

On Sun, Aug 07, 2016 at 08:42:30AM +0100, Jean-Pierre Chrétien wrote:
> Le 06/08/2016 à 16:36, Scott Kostyshak a écrit :
> > To reproduce, open the Embedded Objects manual and compile to PDF. I get
> > the following warnings in the terminal:
> > 
> >   QFile::remove: Empty or null file name
> >   QFile::remove: Empty or null file name
> >   QFile::remove: Empty or null file name
> > 
> 
> Did you notice that new occurrences of this message appear even if you do
> not do anything in the LyX window ?
> 
> -- 
> Jean-Pierre

I did not notice that. I just tried and I don't get occurences after
those three. To make sure I understand, what you are saying is you go to
Help > Embedded Objects, compile, see the three messages, and then you
see more of the same message after those three without doing anything?

Scott


signature.asc
Description: PGP signature

Re: [LyX/master] Use call_once to ensure something is only called once

[Enrico Forestieri]

On Sun, Aug 07, 2016 at 05:37:25PM +0100, Guillaume Munch wrote:
> 
> Then I tried the cygwin one, and it reported "thread model: win32". And
> I could not manage to activate the posix threading model. I also found
> that mingw itself relies on winpthreads internally whatever the version,
> so this would explain the dependency.
> 
> The LLVM people had a similar discussion regarding dropping win32 threads:
> https://groups.google.com/d/msg/llvm-dev/DuTQT0vU8MA/leb8hjfWBgQJ

I see. Thanks for the info.

-- 
Enrico

Re: [LyX/master] Introduce "inverted" branch insets: These are branches whose content is output when a branch is NOT activated. Fixes bug #7698.

[Scott Kostyshak]

On Tue, Jul 12, 2016 at 05:57:41AM +0200, Richard Heck wrote:
> commit 5df323a0dd564f00c5ab085a3570957ad76b21d3
> Author: Richard Heck 
> Date:   Mon Jul 11 23:56:32 2016 -0400
> 
> Introduce "inverted" branch insets: These are branches whose content
> is output when a branch is NOT activated. Fixes bug #7698.
> 
> At the moment, inversion is controlled through the branch settings
> dialog. There is no provision for inserting inverted insets directly,
> or for changing them from the context menu. Both of these could be
> done, of course. The latter would need LFUN_BRANCH_TOGGLE_INVERTED.

This commit broke tex2lyx tests. For more information, see the
Development manual, Section 2.3.

Scott


signature.asc
Description: PGP signature

Re: [LyX/master] Use call_once to ensure something is only called once

[Guillaume Munch]

Le 07/08/2016 à 17:05, Enrico Forestieri a écrit :

On Sun, Aug 07, 2016 at 04:18:13PM +0200, Enrico Forestieri wrote:


On Sun, Aug 07, 2016 at 01:10:49PM +0100, Guillaume Munch wrote:


That being said, if we want to make any use of the  and 
headers in the future we need the posix version (in the current state of
MinGW). The better thing to do would be to ask the cygwin people to
distribute it.


I am not sure. The cross-compiler had no problems with the thread_local
thingie, for example, and the SO answer I cited previously suggests
that using libwinpthread means that the posix model is in use.


As also reaffirmed here:
https://sourceforge.net/p/mingw-w64/mailman/message/31213279/



But here they are speaking of the official mingw-w64 distribution, which
I tried before the cygwin one. It comes with two different executables,
one of which indeed gives you "thread model: posix" when you pass the
option -v. This is the only one to successfully compile call_once. (Of
course there is also threading support in the other version, which is
why thread_local works, but the C++ library support seems incomplete for
now.)

Then I tried the cygwin one, and it reported "thread model: win32". And
I could not manage to activate the posix threading model. I also found
that mingw itself relies on winpthreads internally whatever the version,
so this would explain the dependency.

The LLVM people had a similar discussion regarding dropping win32 
threads: https://groups.google.com/d/msg/llvm-dev/DuTQT0vU8MA/leb8hjfWBgQJ

Re: [LyX/master] Use call_once to ensure something is only called once

[Enrico Forestieri]

On Sun, Aug 07, 2016 at 04:18:13PM +0200, Enrico Forestieri wrote:

> On Sun, Aug 07, 2016 at 01:10:49PM +0100, Guillaume Munch wrote:
> > 
> > That being said, if we want to make any use of the  and 
> > headers in the future we need the posix version (in the current state of
> > MinGW). The better thing to do would be to ask the cygwin people to
> > distribute it.
> 
> I am not sure. The cross-compiler had no problems with the thread_local
> thingie, for example, and the SO answer I cited previously suggests
> that using libwinpthread means that the posix model is in use.

As also reaffirmed here:
https://sourceforge.net/p/mingw-w64/mailman/message/31213279/

-- 
Enrico

Re: [LyX/master] Use call_once to ensure something is only called once

[Enrico Forestieri]

On Sun, Aug 07, 2016 at 01:10:49PM +0100, Guillaume Munch wrote:
> 
> That being said, if we want to make any use of the  and 
> headers in the future we need the posix version (in the current state of
> MinGW). The better thing to do would be to ask the cygwin people to
> distribute it.

I am not sure. The cross-compiler had no problems with the thread_local
thingie, for example, and the SO answer I cited previously suggests
that using libwinpthread means that the posix model is in use.

-- 
Enrico

Re: [LyX/master] Use call_once to ensure something is only called once

[Guillaume Munch]

Le 07/08/2016 à 04:01, Enrico Forestieri a écrit :

On Sat, Aug 06, 2016 at 03:39:19PM +0100, Guillaume Munch wrote:


call_once.cpp:

#include 
static std::once_flag flag;
int main() {
  std::call_once(flag, [](){ return; });
  return 0;
}


Thanks for the test case. I used it to fix this issue at 41e409f8.



Many thanks. In the meanwhile, I installed cygwin and tried myself.
  i696-w64-mingw32-c++ -v
reports "Thread model: win32". The problem seems to be that the
cygwin distribution does not include the posix version. So I do not
think that there is another solution than the fix you made in the short
term.

That being said, if we want to make any use of the  and 
headers in the future we need the posix version (in the current state of
MinGW). The better thing to do would be to ask the cygwin people to
distribute it.

Re: C++ "good practices" regarding constifying a function parameter?

[Abdelrazak Younes]

On 06/08/2016 21:58, Guillaume Munch wrote:

But I agree that new move functionality in C++11 is really nice and I

know that I have to unlearn the good practice I learned so many years
ago in order to use them efficiently.


The issue with c++11 move semantics is that it is an addition of a big
layer of complexity on top of the rest for backward-compatibility
reasons and that makes everything very complicated. We want to avoid
needlessly writing complicated code that few people understand.


Agreed. Indeed I've seen code with lots of lambda that is very hard to read.

I think one should think about c++11 as a new language if you really 
want to take advantage of it. auto, range loop, new algorithm, etc are 
very nice but mixing old style c++ and c++11 leads to confusing source code.



The most important thing to remember is the conclusion in part 3: pass
by const reference, unless the function needs a copy "conceptually". In
this case, you should pass by value. Pros:
* Simple and generic rule.
* Not a big change compared to what developers are used to.
* Exposes in the interface the knowledge of when passing an argument is
going to be expensive.
* In the latter case, offers to the caller the opportunity to move the
argument instead of copying it.


Sounds good.




***


In addition, now, what if we want to design a bulky class that relies on
being moved more often than being copied? It is possible to simply make
the copy explicit in the class declaration (say TexRow), as follows:

explicit TexRow(TexRow const & other) = default;
TexRow(TexRow && other) = default;
TexRow & operator=(TexRow const & other) = default;
TexRow & operator=(TexRow && other) = default;

(this defines respectively the copy and move constructors, and the 
copy and move operators, as default.)

Making the copy constructor explicit prevents implicit copies when
passing an argument. One has to explicitly move or copy. Pros:

* It forces to think about it.
* It also prevents every cases of move(obj) unexpectedly performing a
copy instead of a move.

I still have to see whether this particular use case is not redundant
with encapsulating in a unique_ptr. But I would like to suggest that
copy constructors should be made explicit when a class is designed to be
moved, if only to avoid reading code containing move(obj) and not
knowing whether it's really a move.


Sounds good as well :-)

Abdel.

Insert->Special Character->Protected Hyphen requires amsmath package

[Jean-Pierre Chrétien]

(sorry for the mistyping of the subject line in my previous post)

Hello,

I happened to check that splash.lyx compiled correctly in French.
As I found a wrongly justified line, I tried to correct this by inserting a 
Insert->Special Character->Protected Hyphen, which is not the correct solution 
of course as I should have inserted Insert->Formatting->Hyphenation Point.


My error stems for the fact that I have made a wrong translation in French, 
mixing up things between "Hyphen" and "Hyphenation" (I will correct this next 
time I update fr.po). Anyway as inserting hyphenation points is not a good idea 
IMHO in documents presented to new users, I will rephrase the line to eliminate 
the justification issue instead of inserting an hyphenation point.


But the main point is that splash.lyx did not compile anymore, as amsmath is not 
loaded at all in Document->Settings->Math Options.


Currently I see
  in lib/doc
Customization.lyx:\use_package amsmath 0
LaTeXConfig.lyx:\use_package amsmath 0
Tutorial.lyx:\use_package amsmath 0

  in lib/examples
aa_sample.lyx:\use_package amsmath 0
aas_sample.lyx:\use_package amsmath 0
achemso.lyx:\use_package amsmath 0
amsart-test.lyx:\use_package amsmath 0
amsbook-test.lyx:\use_package amsmath 0
chess-article.lyx:\use_package amsmath 0
chessgame.lyx:\use_package amsmath 0
docbook_article.lyx:\use_package amsmath 0
example_lyxified.lyx:\use_package amsmath 0
example_raw.lyx:\use_package amsmath 0
landslide.lyx:\use_package amsmath 0
listerrors.lyx:\use_package amsmath 0
Literate.lyx:\use_package amsmath 0
noweb2lyx.lyx:\use_package amsmath 0
script_form.lyx:\use_package amsmath 0
serial_letter1.lyx:\use_package amsmath 0
serial_letter2.lyx:\use_package amsmath 0
serial_letter3.lyx:\use_package amsmath 0
splash.lyx:\use_package amsmath 0

   in lib/templates
aa.lyx:\use_package amsmath 0
aastex6.lyx:\use_package amsmath 0
ACM-siggraph.lyx:\use_package amsmath 0
AGUTeX.lyx:\use_package amsmath 0
DocBook_article.lyx:\use_package amsmath 0
elsarticle.lyx:\use_package amsmath 0
frletter.lyx:\use_package amsmath 0
g-brief-de.lyx:\use_package amsmath 0
g-brief-en.lyx:\use_package amsmath 0
hollywood.lyx:\use_package amsmath 0
IJMPC.lyx:\use_package amsmath 0
IJMPD.lyx:\use_package amsmath 0
IOP-article.lyx:\use_package amsmath 0
kluwer.lyx:\use_package amsmath 0
koma-letter2.lyx:\use_package amsmath 0
letter.lyx:\use_package amsmath 0
poster-a0poster-colored.lyx:\use_package amsmath 0
poster-a0poster-simple.lyx:\use_package amsmath 0
slides.lyx:\use_package amsmath 0

So I suggest to turn on automatic loading of amsmath
(that would be "\use_package amsmath 1" everywhere it is currently set to 0).
It's not vital for the doc as only experienced users will modify the files, but 
it may be critical for those using the examples or templates files and falling 
on a cryptic message about \nobreakdash being an undefined command if they 
happen to use a protected hyphen. I think that a hint in the UserGuide, section 
A.4.2 would be welcome as well.


I can take these changes in charge if you find them appropriate.

--
Jean-Pierre

Re: QFile::remove: Empty or null file name

[Jean-Pierre Chrétien]

Le 06/08/2016 à 16:36, Scott Kostyshak a écrit :

To reproduce, open the Embedded Objects manual and compile to PDF. I get
the following warnings in the terminal:

  QFile::remove: Empty or null file name
  QFile::remove: Empty or null file name
  QFile::remove: Empty or null file name



Did you notice that new occurrences of this message appear even if you do not do 
anything in the LyX window ?


--
Jean-Pierre