Re: ctests: ignore these warnings for the lyx2lyx tests?

2019-01-01 Thread Scott Kostyshak
On Wed, Jan 02, 2019 at 08:14:23AM +0100, Kornel Benko wrote:
> Am Mittwoch, 2. Januar 2019 02:10:19 CET schrieb Scott Kostyshak 
> :
> > On Wed, Jan 02, 2019 at 06:45:51AM +0100, Kornel Benko wrote:
> > > Am Dienstag, 1. Januar 2019 18:09:51 CET schrieb Scott Kostyshak 
> > > :
> > > > The following ctest fails on 2.3.x and on master:
> > > > 
> > > >   ctest -R "export/examples/thesis/Bibliography_lyx21"
> > > > 
> > > > It seems that the warning comes because Bibliography.lyx is included in
> > > > more than one document that is loaded. That is, I guess that at least
> > > > two of these .lyx files are opened (because of dependencies) when
> > > > exporting Bibliography.lyx:
> > > > 
> > > >   Appendix.lyx
> > > >   chapter-1.lyx
> > > >   chapter-2.lyx
> > > >   thesis.lyx
> > > > 
> > > > This does not seem like a bug to me. My guess is that this test never
> > > > passed (although I'm not sure). The following warnings occur:
> > > > 
> > > >   Buffer.cpp (361): Warning: a buffer should not have two parents!
> > > > 
> > > > And, on the second iteration (that is, exporting the created 2.1.x file
> > > > again to 2.1.x format to create a .21.21.lyx file):
> > > > 
> > > >   Buffer.cpp (1062): The master 'thesis.lyx' assigned to this document 
> > > > (/home/scott/lyxbuilds/master/repo/lib/examples/thesis/Bibliography.21.lyx)
> > > >  does not include this document. Ignoring the master assignment.
> > > > 
> > > > I guess this is because for the second iteration, the file has 21.lyx 
> > > > instead
> > > > of .lyx.
> > > > 
> > > > Kornel, do you think we should ignore both of these warnings for all
> > > > lyx2lyx tests? I attempted to do that (see attached), but the test still
> > > > fails and I'm not sure if it's because I did not ignore the warnings
> > > > correctly or if there's another issue.
> > > 
> > > No, it is a child-documents. Other child are already removed from test.
> > 
> > Ah I see.
> > 
> > >   $ egrep thesis *Tests
> > > ignoredTests:export/examples/thesis/(Acknowledgments|Appendix|Summary|chapter-[12])_lyx[0-9][0-9]
> > > 
> > > > An alternative I suppose would be
> > > > to just not run these tests (by "ignoring" them). Any thoughts?
> > > 
> > > Yes, please do also for master.
> > 
> > Makes sense. Feel free to go ahead, or I will get to this tomorrow.
> > 
> > We also have the following test failing (at least for me) on master:
> > 
> >   ctest -R "export/examples/thesis/thesis_lyx21"
> > 
> > Adding
> > 
> >   Warning: a buffer should not have two parents!
> > 
> > to filterCheckWarnings fixes it for me. Is that the right thing to do?
> 
> I think yes, OTOH, for thesis.lyx we should _not_ get this warning.

Why not? From what I understand, the master (implicitly) loads the
children, which triggers the warning.

Scott


signature.asc
Description: PGP signature


Re: ctests: ignore these warnings for the lyx2lyx tests?

2019-01-01 Thread Kornel Benko
Am Mittwoch, 2. Januar 2019 02:10:19 CET schrieb Scott Kostyshak 
:
> On Wed, Jan 02, 2019 at 06:45:51AM +0100, Kornel Benko wrote:
> > Am Dienstag, 1. Januar 2019 18:09:51 CET schrieb Scott Kostyshak 
> > :
> > > The following ctest fails on 2.3.x and on master:
> > > 
> > >   ctest -R "export/examples/thesis/Bibliography_lyx21"
> > > 
> > > It seems that the warning comes because Bibliography.lyx is included in
> > > more than one document that is loaded. That is, I guess that at least
> > > two of these .lyx files are opened (because of dependencies) when
> > > exporting Bibliography.lyx:
> > > 
> > >   Appendix.lyx
> > >   chapter-1.lyx
> > >   chapter-2.lyx
> > >   thesis.lyx
> > > 
> > > This does not seem like a bug to me. My guess is that this test never
> > > passed (although I'm not sure). The following warnings occur:
> > > 
> > >   Buffer.cpp (361): Warning: a buffer should not have two parents!
> > > 
> > > And, on the second iteration (that is, exporting the created 2.1.x file
> > > again to 2.1.x format to create a .21.21.lyx file):
> > > 
> > >   Buffer.cpp (1062): The master 'thesis.lyx' assigned to this document 
> > > (/home/scott/lyxbuilds/master/repo/lib/examples/thesis/Bibliography.21.lyx)
> > >  does not include this document. Ignoring the master assignment.
> > > 
> > > I guess this is because for the second iteration, the file has 21.lyx 
> > > instead
> > > of .lyx.
> > > 
> > > Kornel, do you think we should ignore both of these warnings for all
> > > lyx2lyx tests? I attempted to do that (see attached), but the test still
> > > fails and I'm not sure if it's because I did not ignore the warnings
> > > correctly or if there's another issue.
> > 
> > No, it is a child-documents. Other child are already removed from test.
> 
> Ah I see.
> 
> > $ egrep thesis *Tests
> > ignoredTests:export/examples/thesis/(Acknowledgments|Appendix|Summary|chapter-[12])_lyx[0-9][0-9]
> > 
> > > An alternative I suppose would be
> > > to just not run these tests (by "ignoring" them). Any thoughts?
> > 
> > Yes, please do also for master.
> 
> Makes sense. Feel free to go ahead, or I will get to this tomorrow.
> 
> We also have the following test failing (at least for me) on master:
> 
>   ctest -R "export/examples/thesis/thesis_lyx21"
> 
> Adding
> 
>   Warning: a buffer should not have two parents!
> 
> to filterCheckWarnings fixes it for me. Is that the right thing to do?

I think yes, OTOH, for thesis.lyx we should _not_ get this warning.

> Scott

Kornel



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


Re: ctests: ignore these warnings for the lyx2lyx tests?

2019-01-01 Thread Scott Kostyshak
On Wed, Jan 02, 2019 at 06:45:51AM +0100, Kornel Benko wrote:
> Am Dienstag, 1. Januar 2019 18:09:51 CET schrieb Scott Kostyshak 
> :
> > The following ctest fails on 2.3.x and on master:
> > 
> >   ctest -R "export/examples/thesis/Bibliography_lyx21"
> > 
> > It seems that the warning comes because Bibliography.lyx is included in
> > more than one document that is loaded. That is, I guess that at least
> > two of these .lyx files are opened (because of dependencies) when
> > exporting Bibliography.lyx:
> > 
> >   Appendix.lyx
> >   chapter-1.lyx
> >   chapter-2.lyx
> >   thesis.lyx
> > 
> > This does not seem like a bug to me. My guess is that this test never
> > passed (although I'm not sure). The following warnings occur:
> > 
> >   Buffer.cpp (361): Warning: a buffer should not have two parents!
> > 
> > And, on the second iteration (that is, exporting the created 2.1.x file
> > again to 2.1.x format to create a .21.21.lyx file):
> > 
> >   Buffer.cpp (1062): The master 'thesis.lyx' assigned to this document 
> > (/home/scott/lyxbuilds/master/repo/lib/examples/thesis/Bibliography.21.lyx) 
> > does not include this document. Ignoring the master assignment.
> > 
> > I guess this is because for the second iteration, the file has 21.lyx 
> > instead
> > of .lyx.
> > 
> > Kornel, do you think we should ignore both of these warnings for all
> > lyx2lyx tests? I attempted to do that (see attached), but the test still
> > fails and I'm not sure if it's because I did not ignore the warnings
> > correctly or if there's another issue.
> 
> No, it is a child-documents. Other child are already removed from test.

Ah I see.

>   $ egrep thesis *Tests
> ignoredTests:export/examples/thesis/(Acknowledgments|Appendix|Summary|chapter-[12])_lyx[0-9][0-9]
> 
> > An alternative I suppose would be
> > to just not run these tests (by "ignoring" them). Any thoughts?
> 
> Yes, please do also for master.

Makes sense. Feel free to go ahead, or I will get to this tomorrow.

We also have the following test failing (at least for me) on master:

  ctest -R "export/examples/thesis/thesis_lyx21"

Adding

  Warning: a buffer should not have two parents!

to filterCheckWarnings fixes it for me. Is that the right thing to do?

Scott


signature.asc
Description: PGP signature


Re: ctests: ignore these warnings for the lyx2lyx tests?

2019-01-01 Thread Kornel Benko
Am Dienstag, 1. Januar 2019 18:09:51 CET schrieb Scott Kostyshak 
:
> The following ctest fails on 2.3.x and on master:
> 
>   ctest -R "export/examples/thesis/Bibliography_lyx21"
> 
> It seems that the warning comes because Bibliography.lyx is included in
> more than one document that is loaded. That is, I guess that at least
> two of these .lyx files are opened (because of dependencies) when
> exporting Bibliography.lyx:
> 
>   Appendix.lyx
>   chapter-1.lyx
>   chapter-2.lyx
>   thesis.lyx
> 
> This does not seem like a bug to me. My guess is that this test never
> passed (although I'm not sure). The following warnings occur:
> 
>   Buffer.cpp (361): Warning: a buffer should not have two parents!
> 
> And, on the second iteration (that is, exporting the created 2.1.x file
> again to 2.1.x format to create a .21.21.lyx file):
> 
>   Buffer.cpp (1062): The master 'thesis.lyx' assigned to this document 
> (/home/scott/lyxbuilds/master/repo/lib/examples/thesis/Bibliography.21.lyx) 
> does not include this document. Ignoring the master assignment.
> 
> I guess this is because for the second iteration, the file has 21.lyx instead
> of .lyx.
> 
> Kornel, do you think we should ignore both of these warnings for all
> lyx2lyx tests? I attempted to do that (see attached), but the test still
> fails and I'm not sure if it's because I did not ignore the warnings
> correctly or if there's another issue.

No, it is a child-documents. Other child are already removed from test.

$ egrep thesis *Tests
ignoredTests:export/examples/thesis/(Acknowledgments|Appendix|Summary|chapter-[12])_lyx[0-9][0-9]

> An alternative I suppose would be
> to just not run these tests (by "ignoring" them). Any thoughts?

Yes, please do also for master.

> Scott

Kornel



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


tex2lyx roundtrip tests failing on master

2019-01-01 Thread Scott Kostyshak
There are many tex2lyx roundtrip tests failing on master.

Scott


signature.asc
Description: PGP signature


Re: New Windows Installer For Testing

2019-01-01 Thread Richard Kimberly Heck
On 1/1/19 9:29 PM, Andrew Parsloe wrote:
> On 2/01/2019 12:35 PM, Richard Kimberly Heck wrote:
>>
>> A Windows installer that should fix the previously reported issue has
>> been uploaded for testing here:
>>
>>     http://ftp.lyx.org/pub/lyx/devel/lyx-2.3/
>>
>> The issue was that citations could not be added in documents that
>> used the bibliography environment, rather than BibTeX files. I have
>> tested myself but would like verification that this actually does fix
>> the problem before releasing.
>>
>> Riki
>>
> Installed successfully on a windows 7 system. Citations are
> successfully inserted using the bibliography environment, and for that
> matter using a .bib file. (And no kpsewhich slowness either.)
>
Thanks for the confirmation.

Riki




Re: check_Length test fails on 2.3.x but passes on master on updated system

2019-01-01 Thread Scott Kostyshak
On Wed, Jan 02, 2019 at 05:28:05AM +0100, Kornel Benko wrote:

> I would try to get a backtrace under gdb.
> Here, I don't get a core dump.

Backtrace attached.

Scott
Program received signal SIGSEGV, Segmentation fault.
0x77199170 in __gnu_debug::_Safe_sequence_base::_M_detach_all() () from 
/usr/lib/x86_64-linux-gnu/libstdc++.so.6
(gdb) bt
#0  0x77199170 in __gnu_debug::_Safe_sequence_base::_M_detach_all() () 
from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#1  0x5564ebe4 in 
__gnu_debug::_Safe_sequence_base::~_Safe_sequence_base (this=0x55933e20 
, 
__in_chrg=) at /usr/include/c++/7/debug/safe_base.h:221
#2  0x556801f2 in 
__gnu_debug::_Safe_sequence, std::allocator >, 
std::less, 
std::allocator > >, std::allocator, std::allocator > > > >::~_Safe_sequence 
(this=0x55933e20 , __in_chrg=)
at /usr/include/c++/7/debug/safe_sequence.h:108
#3  0x5568022a in 
__gnu_debug::_Safe_node_sequence, std::allocator >, 
std::less, 
std::allocator > >, std::allocator, std::allocator > > > >::~_Safe_node_sequence 
(this=0x55933e20 , 
__in_chrg=) at /usr/include/c++/7/debug/safe_sequence.h:131
#4  0x55680262 in 
__gnu_debug::_Safe_container, std::allocator >, 
std::less, 
std::allocator > >, std::allocator, std::allocator > > >, 
std::allocator, 
std::allocator > >, __gnu_debug::_Safe_node_sequence, 
true>::~_Safe_container (this=0x55933e20 , 
__in_chrg=)
at /usr/include/c++/7/debug/safe_container.h:41
#5  0x5568792e in std::__debug::set, std::allocator >, 
std::less, 
std::allocator > >, std::allocator, std::allocator > > >::~set (this=0x55933e20 
, __in_chrg=) at 
/usr/include/c++/7/debug/set.h:120
#6  0x7677b041 in __run_exit_handlers (status=0, listp=0x76b23718 
<__exit_funcs>, run_list_atexit=run_list_atexit@entry=true, 
run_dtors=run_dtors@entry=true) at exit.c:108
#7  0x7677b13a in __GI_exit (status=) at exit.c:139
#8  0x76759b9e in __libc_start_main (main=0x5564e8cb , argc=1, argv=0x7fffdb08, init=, 
fini=, rtld_fini=, stack_end=0x7fffdaf8) 
at ../csu/libc-start.c:344
#9  0x5564914a in _start ()
(gdb) 



signature.asc
Description: PGP signature


Re: check_Length test fails on 2.3.x but passes on master on updated system

2019-01-01 Thread Kornel Benko
Am Dienstag, 1. Januar 2019 17:03:55 CET schrieb Scott Kostyshak 
:
> On Tue, Jan 01, 2019 at 07:43:02AM +0100, Kornel Benko wrote:
> > Am Montag, 31. Dezember 2018 15:05:27 CET schrieb Scott Kostyshak 
> > :
> > > The following fails for me on 2.3.x but passes on master:
> > > 
> > >   ctest -R 'check_Length'
> > > 
> > > This is on my updated system (Ubuntu 18.04 with an updated TL 2018).
> > > What does this test actually test and how can I reproduce it manually?
> > > Does it fail for anyone else on 2.3.x? On my old system, it passes on
> > > 2.3.x.
> > > 
> > > Scott
> > > 
> > 
> > If I understand correctly, it should check if the length conversions work 
> > as the should.
> > Compare the output of the command
> > "check_Length"
> > with expected data in "src/tests/regfiles/Length"
> 
> Thanks. When I execute the file directly, I get a bunch of length output
> (which I guess is expected) and then I get
> 
>   "Segmentation fault (core dumped)"
> 
> at the end.
> 
> I do not get a segmentation fault with master's version. The .cpp files
> are identical. There is a difference in an included file:
> 
>   --- /home/scott/lyxbuilds/2.3.x/repo/src/Length.h   2018-08-08 
> 18:22:27.482962193 -0400
>   +++ src/Length.h2018-07-30 17:28:33.680910801 -0400
>   @@ -20,8 +20,6 @@
>
>namespace lyx {
>
>   -class MetricsBase;
>   -
>// Solaris/x86 version 9 and earlier define these
>#undef PC
>#undef SP
>   @@ -98,12 +96,6 @@
>*/
>   int inPixels(int text_width, int em_width = 0) const;
>
>   -   /** return the on-screen size of this length
>   -*
>   -*  This version of the function uses the current inset width as
>   -*  width and the EM value of the current font.
>   -*/
>   -   int inPixels(MetricsBase const &) const;
>   /// return the value in Big Postscript points.
>   /// Caution: Inaccurate for em, ex, mu and percent units.
>   int inBP() const;
>   $ 
> 
> I'm not sure if this is worth spending time on, since it works in
> master, and I don't know if it causes any real issue to the user in
> 2.3.x. Let me know if you disagree, and I will spend time to try to fix
> the issue in 2.3.x.
> 
> Scott

I would try to get a backtrace under gdb.
Here, I don't get a core dump.

Kornel



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


Re: New Windows Installer For Testing

2019-01-01 Thread Andrew Parsloe

On 2/01/2019 12:35 PM, Richard Kimberly Heck wrote:


A Windows installer that should fix the previously reported issue has 
been uploaded for testing here:


http://ftp.lyx.org/pub/lyx/devel/lyx-2.3/

The issue was that citations could not be added in documents that used 
the bibliography environment, rather than BibTeX files. I have tested 
myself but would like verification that this actually does fix the 
problem before releasing.


Riki

Installed successfully on a windows 7 system. Citations are successfully 
inserted using the bibliography environment, and for that matter using a 
.bib file. (And no kpsewhich slowness either.)


Andrew



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


Two layout questions

2019-01-01 Thread Paul A. Rubin

Hi,

I've got two questions about layouts. Attached is an MWE, which contains 
a local layout defining two environments. (Do not try to compile it, as 
the LaTeX names do not correspond to anything.)


Question 1: When I nest the Function inside the Algorithm, I get an 
empty line between the "Begin algorithm" label and the "Function" label. 
Any attempt to delete it screws things up royally. Is there an error in 
the Algorithm style definition causing that?


Question 2: The "End algorithm" label aligns horizontally with the 
"Begin algorithm" label, but the "End function" label is indented (by 
the width of the word "Function") relative to the "Function" label. I 
have no idea why that is happening. Can it be cured?


Thanks,
Paul



mwe.lyx
Description: application/lyx


New Windows Installer For Testing

2019-01-01 Thread Richard Kimberly Heck
A Windows installer that should fix the previously reported issue has
been uploaded for testing here:

    http://ftp.lyx.org/pub/lyx/devel/lyx-2.3/

The issue was that citations could not be added in documents that used
the bibliography environment, rather than BibTeX files. I have tested
myself but would like verification that this actually does fix the
problem before releasing.

Riki




ctests: ignore these warnings for the lyx2lyx tests?

2019-01-01 Thread Scott Kostyshak
The following ctest fails on 2.3.x and on master:

  ctest -R "export/examples/thesis/Bibliography_lyx21"

It seems that the warning comes because Bibliography.lyx is included in
more than one document that is loaded. That is, I guess that at least
two of these .lyx files are opened (because of dependencies) when
exporting Bibliography.lyx:

  Appendix.lyx
  chapter-1.lyx
  chapter-2.lyx
  thesis.lyx

This does not seem like a bug to me. My guess is that this test never
passed (although I'm not sure). The following warnings occur:

  Buffer.cpp (361): Warning: a buffer should not have two parents!

And, on the second iteration (that is, exporting the created 2.1.x file
again to 2.1.x format to create a .21.21.lyx file):

  Buffer.cpp (1062): The master 'thesis.lyx' assigned to this document 
(/home/scott/lyxbuilds/master/repo/lib/examples/thesis/Bibliography.21.lyx) 
does not include this document. Ignoring the master assignment.

I guess this is because for the second iteration, the file has 21.lyx instead
of .lyx.

Kornel, do you think we should ignore both of these warnings for all
lyx2lyx tests? I attempted to do that (see attached), but the test still
fails and I'm not sure if it's because I did not ignore the warnings
correctly or if there's another issue. An alternative I suppose would be
to just not run these tests (by "ignoring" them). Any thoughts?

Scott
diff --git a/development/autotests/filterCheckWarnings b/development/autotests/filterCheckWarnings
index fc6925d928..c2a5d69d2e 100644
--- a/development/autotests/filterCheckWarnings
+++ b/development/autotests/filterCheckWarnings
@@ -1,3 +1,5 @@
 Cannot find translation for language
 Warning: Lyx2lyx knows nothing about (textclass|module) 
 Warning: sfval: [0-9]+ [0-9]+
+Warning: a buffer should not have two parents!
+does not include this document. Ignoring the master assignment.


signature.asc
Description: PGP signature


Re: Many warnings when compiling master with Clang

2019-01-01 Thread Scott Kostyshak
On Tue, Jan 01, 2019 at 11:27:32PM +0100, Jean-Marc Lasgouttes wrote:
> Le 01/01/2019 à 22:30, Scott Kostyshak a écrit :
> > Good to know. Once we get rid of the warnings, we can compile with
> > -Werror on Clang once in a while, and try to preserve the compilation,
> > if it agreed this is a worthwhile goal. Perhaps someone can modify our
> > continuous integration script to also compile with Clang.
> 
> I compile with clang at least every time I upgrade the compiler to see what
> new warnings appear. I am not sure it is worth doing that in a more formal
> manner.

OK that sounds good.

Scott


signature.asc
Description: PGP signature


Re: Many warnings when compiling master with Clang

2019-01-01 Thread Jean-Marc Lasgouttes

Le 01/01/2019 à 22:30, Scott Kostyshak a écrit :

Good to know. Once we get rid of the warnings, we can compile with
-Werror on Clang once in a while, and try to preserve the compilation,
if it agreed this is a worthwhile goal. Perhaps someone can modify our
continuous integration script to also compile with Clang.


I compile with clang at least every time I upgrade the compiler to see 
what new warnings appear. I am not sure it is worth doing that in a more 
formal manner.


JMarc



Re: check_Length test fails on 2.3.x but passes on master on updated system

2019-01-01 Thread Scott Kostyshak
On Tue, Jan 01, 2019 at 07:43:02AM +0100, Kornel Benko wrote:
> Am Montag, 31. Dezember 2018 15:05:27 CET schrieb Scott Kostyshak 
> :
> > The following fails for me on 2.3.x but passes on master:
> > 
> >   ctest -R 'check_Length'
> > 
> > This is on my updated system (Ubuntu 18.04 with an updated TL 2018).
> > What does this test actually test and how can I reproduce it manually?
> > Does it fail for anyone else on 2.3.x? On my old system, it passes on
> > 2.3.x.
> > 
> > Scott
> > 
> 
> If I understand correctly, it should check if the length conversions work as 
> the should.
> Compare the output of the command
>   "check_Length"
> with expected data in "src/tests/regfiles/Length"

Thanks. When I execute the file directly, I get a bunch of length output
(which I guess is expected) and then I get

  "Segmentation fault (core dumped)"

at the end.

I do not get a segmentation fault with master's version. The .cpp files
are identical. There is a difference in an included file:

  --- /home/scott/lyxbuilds/2.3.x/repo/src/Length.h 2018-08-08 
18:22:27.482962193 -0400
  +++ src/Length.h  2018-07-30 17:28:33.680910801 -0400
  @@ -20,8 +20,6 @@
   
   namespace lyx {
   
  -class MetricsBase;
  -
   // Solaris/x86 version 9 and earlier define these
   #undef PC
   #undef SP
  @@ -98,12 +96,6 @@
 */
int inPixels(int text_width, int em_width = 0) const;
   
  - /** return the on-screen size of this length
  -  *
  -  *  This version of the function uses the current inset width as
  -  *  width and the EM value of the current font.
  -  */
  - int inPixels(MetricsBase const &) const;
/// return the value in Big Postscript points.
/// Caution: Inaccurate for em, ex, mu and percent units.
int inBP() const;
  $ 

I'm not sure if this is worth spending time on, since it works in
master, and I don't know if it causes any real issue to the user in
2.3.x. Let me know if you disagree, and I will spend time to try to fix
the issue in 2.3.x.

Scott


signature.asc
Description: PGP signature


Re: [LyX/master] Use symbols file to lookup entities for delimiters. Fixes bug #8280.

2019-01-01 Thread Scott Kostyshak
On Tue, Jan 01, 2019 at 07:59:39PM +0100, Enrico Forestieri wrote:

> What about the attached patch?

Thanks for taking a look. That fixes the issue for me.

Scott


signature.asc
Description: PGP signature


Re: lyx2lyx regression on master (corrupted lyx21x export)

2019-01-01 Thread Scott Kostyshak
On Tue, Jan 01, 2019 at 04:35:04PM +0100, Jürgen Spitzmüller wrote:
> Am Montag, den 31.12.2018, 17:48 -0500 schrieb Scott Kostyshak:
> > There are several lyx2lyx tests failing in master. Here are the
> > manual
> > steps to reproduce one of them:
> > 
> > 1. Go to lib/examples
> > 2. Use master to export PDF-form.lyx to 2.1.x format.
> > 3. Open the exported .lyx file (in master or any other LyX version >=
> >2.1.0)
> > 
> > I get the following messages in the terminal:
> > 
> >   Lexer.cpp (933): Missing 'status'-tag in InsetCollapsible::read.
> > Got framecolor instead. Line: 2064
> >   Text.cpp (1885): Handling unknown body token: `"black"'
> >   Text.cpp (1885): Handling unknown body token: `backgroundcolor
> > "none"'
> >   Text.cpp (1885): Handling unknown body token: `status open'
> >   Lexer.cpp (933): Missing 'status'-tag in InsetCollapsible::read.
> > Got \begin_inset instead. Line: 2527
> >   Text.cpp (1885): Handling unknown body token: `ERT'
> >   Text.cpp (1885): Handling unknown body token: `status collapsed'
> >   Paragraph ended in line 2538
> >   Missing \end_layout.
> >   Error: Document format failure
> 
> This one should be fixed in master.

Thanks, the corresponding ctest for that file now passes.

A similar issue seems to exist for the colored-boxes.lyx example file.

For JSS-article, opening the exported JSS-article.21.lyx in master, I
get several messages like the following:

  Text.cpp (1885): Handling unknown body token: `\end_layout'
  Paragraph ended in line 586
  Missing \end_layout.

Attempting to export the file autotests/mathmacros/testcases_basic.lyx
to format 2.1.x gives an assertion. Can anyone else reproduce?

Scott


signature.asc
Description: PGP signature


Re: europassCV (both en and de) fail to compile on updated system

2019-01-01 Thread Scott Kostyshak
On Tue, Jan 01, 2019 at 02:38:34PM +0100, Jürgen Spitzmüller wrote:
> Am Dienstag, den 01.01.2019, 01:44 +0100 schrieb Kornel Benko:
> > Am Montag, 31. Dezember 2018 16:07:32 CET schrieb Scott Kostyshak <
> > skost...@lyx.org>:
> > > On both 2.3.x and master, with my updated system, our europassCV
> > > example
> > > file fails to compile for me.
> > > 
> > > The corresponding ctests fail:
> > > 
> > >   ctest -R "europassCV_pdf2"
> > > 
> > > The first error is:
> > > 
> > >   ! Extra \or.
> > > 
> > > Does compilation succeed for anyone with an updated TL 2018?
> > > 
> > > Scott
> > > 
> > 
> > Compiles with TL2017, fails with TL2018 here.
> 
> Seems to be an issue caused by an update of the array package. I
> propose you submit a bug report to either array (via LaTeX bug tracker
> [1]) or the europassCV maintainer [2]

Thanks for taking a look. I opened an issue on the europassCV GitHub
here:

  https://github.com/gmazzamuto/europasscv/issues/36

Scott


signature.asc
Description: PGP signature


Re: Many warnings when compiling master with Clang

2019-01-01 Thread Scott Kostyshak
On Tue, Jan 01, 2019 at 07:05:04PM +0100, Jean-Marc Lasgouttes wrote:
> Le 1 janvier 2019 05:22:08 GMT+01:00, Scott Kostyshak  a 
> écrit :
> >When compiling master with clang, I get a lot of warnings. Almost all
> >of
> >them are from -Winconsistent-missing-override. Are these worth
> >addressing? There is also one warning from -Woverloaded-virtual.
> >
> >My build long is attached.
> >
> >Scott
> 
> Yes, we should fix them. Luckily, this mostly happens with GuiApplication, 
> because it derived from QApplication, because it already uses override.
> 
> On the long term, all our virtual functions reimplementation should use 
> override, although it is only of declarative value, like const.

Good to know. Once we get rid of the warnings, we can compile with
-Werror on Clang once in a while, and try to preserve the compilation,
if it agreed this is a worthwhile goal. Perhaps someone can modify our
continuous integration script to also compile with Clang.

Scott


signature.asc
Description: PGP signature


Re: [LyX/master] Use symbols file to lookup entities for delimiters. Fixes bug #8280.

2019-01-01 Thread Enrico Forestieri
On Mon, Dec 24, 2018 at 10:19:56PM -0500, Scott Kostyshak wrote:
> On Fri, Jun 08, 2018 at 11:16:21PM -0400, Scott Kostyshak wrote:
> > On Sat, Apr 28, 2018 at 09:19:41PM +, Scott Kostyshak wrote:
> > > On Thu, Jun 30, 2016 at 02:40:30AM +, Richard Heck wrote:
> > > > commit 04b8f5cdc4b26105ea855fb9ec5b23227dfd55cb
> > > > Author: Richard Heck 
> > > > Date:   Wed Jun 29 22:39:42 2016 -0400
> > > > 
> > > > Use symbols file to lookup entities for delimiters. Fixes bug #8280.
> > > > 
> > > > Based upon work by Josh Hieronymus.
> > > > ---
> > > 
> > > > +docstring convertDelimToXMLEscape(docstring const & name)
> > > > +{
> > > > +   if (name.size() == 1) {
> > > > +   char_type const c = name[0];
> > > > +   if (c == '<')
> > > > +   return from_ascii("");
> > > > +   else if (c == '>')
> > > > +   return from_ascii("");
> > > > +   else
> > > > +   return name;
> > > > +   }
> > > > +   MathWordList const & words = mathedWordList();
> > > > +   MathWordList::const_iterator it = words.find(name);
> > > > +   if (it != words.end()) {
> > > > +   docstring const escape = it->second.xmlname;
> > > > +   return escape;
> > > > +   }
> > > > +   LYXERR0("Unable to find `" << name <<"' in the mathWordList.");
> > > > +   return name;
> > > > +}
> > > 
> > > If I open Math.lyx, select all, and copy, I get the following messages:
> > > 
> > >   mathed/MathStream.cpp (715): Unable to find `\{' in the mathWordList.
> > >   mathed/MathStream.cpp (715): Unable to find `\}' in the mathWordList.
> > > 
> > > I can reproduce to soon after this commit, so I'm guessing it has always
> > > been here.
> > > 
> > > Any ideas how to fix it?
> > 
> > Bump. Any ideas?
> 
> I can still reproduce on master. Is this worth opening a trac ticket?

What about the attached patch?

-- 
Enrico
diff --git a/src/mathed/MathStream.cpp b/src/mathed/MathStream.cpp
index b2d01cfb68..774e964a8d 100644
--- a/src/mathed/MathStream.cpp
+++ b/src/mathed/MathStream.cpp
@@ -708,6 +708,12 @@ docstring convertDelimToXMLEscape(docstring const & name)
return from_ascii("");
else
return name;
+   } else if (name.size() == 2 && name[0] == '\\') {
+   char_type const c = name[1];
+   if (c == '{')
+   return from_ascii("");
+   else if (c == '}')
+   return from_ascii("");
}
MathWordList const & words = mathedWordList();
MathWordList::const_iterator it = words.find(name);


Re: Lyx V2.3.2 - Issues with svgs snippets on Mac OS X

2019-01-01 Thread Enrico Forestieri
On Tue, Jan 01, 2019 at 02:10:37PM +0100, Stephan Witt wrote:
> Hi all,
> 
> first I wish all of you a Happy New Year.
> 
> I investigated the cause of the issue with displaying SVG (including our own
> icons in Users Guide) on-screen.
> 
> IMO the root cause is the existence of two ways to use the configured
> converters:
> 1. the conversion process to load external material to present it on-screen
> (build_script in GraphicsConverter.cpp) and
> 2. the conversion process to prepare external material for use by external
> programs like LaTeX (Converters::convert)
> 
> Both are using the utilities detected by lib/configure.py. But the meaning of
> the „$$i“ and „$$o“ placeholders is different. (1) is passing the complete
> absolute path of input and output file. (2) is operating in the temporary
> directory and uses relative path names only. On Mac the inkscape binary is a
> shell script itself and it’s not working with relative path names for input
> and output files. Therefore I added the prefix „$$p“ in front of the names to
> get absolute path names. Unfortunately this breaks the conversion (1).
> 
> One possible solution for the current issue is it to change (1) to replace
> „$$p“ with an empty string. Is this a good idea or is some more fundamental
> change to unify the converters to prefer? Any other ideas?

What about changing (1) to use relative path names for "$$i" and "$$o"
and then adding "$$p" to obtain absolute ones? In this way "$$p" maintains
its meaning in both cases.

Happy New Year to all.

-- 
Enrico


Re: Many warnings when compiling master with Clang

2019-01-01 Thread Jean-Marc Lasgouttes
Le 1 janvier 2019 05:22:08 GMT+01:00, Scott Kostyshak  a 
écrit :
>When compiling master with clang, I get a lot of warnings. Almost all
>of
>them are from -Winconsistent-missing-override. Are these worth
>addressing? There is also one warning from -Woverloaded-virtual.
>
>My build long is attached.
>
>Scott

Yes, we should fix them. Luckily, this mostly happens with GuiApplication, 
because it derived from QApplication, because it already uses override.

On the long term, all our virtual functions reimplementation should use 
override, although it is only of declarative value, like const.

JMarc

Re: lyx2lyx regression on master (corrupted lyx21x export)

2019-01-01 Thread Jürgen Spitzmüller
Am Montag, den 31.12.2018, 17:48 -0500 schrieb Scott Kostyshak:
> There are several lyx2lyx tests failing in master. Here are the
> manual
> steps to reproduce one of them:
> 
> 1. Go to lib/examples
> 2. Use master to export PDF-form.lyx to 2.1.x format.
> 3. Open the exported .lyx file (in master or any other LyX version >=
>2.1.0)
> 
> I get the following messages in the terminal:
> 
>   Lexer.cpp (933): Missing 'status'-tag in InsetCollapsible::read.
> Got framecolor instead. Line: 2064
>   Text.cpp (1885): Handling unknown body token: `"black"'
>   Text.cpp (1885): Handling unknown body token: `backgroundcolor
> "none"'
>   Text.cpp (1885): Handling unknown body token: `status open'
>   Lexer.cpp (933): Missing 'status'-tag in InsetCollapsible::read.
> Got \begin_inset instead. Line: 2527
>   Text.cpp (1885): Handling unknown body token: `ERT'
>   Text.cpp (1885): Handling unknown body token: `status collapsed'
>   Paragraph ended in line 2538
>   Missing \end_layout.
>   Error: Document format failure

This one should be fixed in master.

Jürgen

> 
> Scott


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


Re: europassCV (both en and de) fail to compile on updated system

2019-01-01 Thread Jürgen Spitzmüller
Am Dienstag, den 01.01.2019, 01:44 +0100 schrieb Kornel Benko:
> Am Montag, 31. Dezember 2018 16:07:32 CET schrieb Scott Kostyshak <
> skost...@lyx.org>:
> > On both 2.3.x and master, with my updated system, our europassCV
> > example
> > file fails to compile for me.
> > 
> > The corresponding ctests fail:
> > 
> >   ctest -R "europassCV_pdf2"
> > 
> > The first error is:
> > 
> >   ! Extra \or.
> > 
> > Does compilation succeed for anyone with an updated TL 2018?
> > 
> > Scott
> > 
> 
> Compiles with TL2017, fails with TL2018 here.

Seems to be an issue caused by an update of the array package. I
propose you submit a bug report to either array (via LaTeX bug tracker
[1]) or the europassCV maintainer [2]

Jürgen

[1] https://www.latex-project.org/bugs/
[2] https://github.com/gmazzamuto/europasscv/issues

> 
>   Kornel


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


Re: Lyx V2.3.2 - Issues with svgs snippets on Mac OS X

2019-01-01 Thread Stephan Witt
Hi all,

first I wish all of you a Happy New Year.

I investigated the cause of the issue with displaying SVG (including our own 
icons in Users Guide) on-screen.

IMO the root cause is the existence of two ways to use the configured 
converters:
1. the conversion process to load external material to present it on-screen 
(build_script in GraphicsConverter.cpp) and
2. the conversion process to prepare external material for use by external 
programs like LaTeX (Converters::convert)

Both are using the utilities detected by lib/configure.py. But the meaning of 
the „$$i“ and „$$o“ placeholders is different. (1) is passing the complete 
absolute path of input and output file. (2) is operating in the temporary 
directory and uses relative path names only. On Mac the inkscape binary is a 
shell script itself and it’s not working with relative path names for input and 
output files. Therefore I added the prefix „$$p“ in front of the names to get 
absolute path names. Unfortunately this breaks the conversion (1).

One possible solution for the current issue is it to change (1) to replace 
„$$p“ with an empty string. Is this a good idea or is some more fundamental 
change to unify the converters to prefer? Any other ideas?

Best regards,
Stephan


> Am 24.12.2018 um 11:02 schrieb Stephan Witt :
> 
> Am 23.12.2018 um 23:03 schrieb Stephan Witt :
>> 
>> Am 23.12.2018 um 19:28 schrieb Robert Betz :
>>> 
>>> Anders,
>>> 
>>> Stephen Witt mentioned that he was using RSVG-convert.  So I installed, 
>>> using macports librsvg.  I did a reconfigure on Lyx, and now the svgz 
>>> snippets show up.
>>> 
>>> Don’t know why it is required to have this package, as Lyx should supply 
>>> everything it needs to make all these conversions work.
>> 
>> It’s a little bit more convoluted than you think.
>> 
>> I’ve tried to disable rsvg-convert by making it a non-executable and the 
>> shell didn’t find it - but LyX detected it and couldn’t run it. So, it was 
>> not right to say, I’m having the same problem as you. My problem was to have 
>> a non-working rsvg-convert. Then I renamed rsvg-convert and the preview of 
>> SVG graphics snippets worked out-of-the-box again. Next I’ve installed 
>> inkscape 0.91 and immediately had your problem after reconfiguring LyX. LyX 
>> was able to find end execute inkscape but the converter script used contains 
>> a strange command line and the conversion failed because of it.
>> 
>> The python script generated on the fly by LyX has two superfluous „$$p“ in 
>> front of the real path names of in and out files.
>> 
>> # if os.system(r'inkscape --without-gui --file=$$p' + '"' + infile + '"' + ' 
>> --export-png=$$p' + '"' + outfile + '"' + '') != 0:
>> 
>> This is a consequence of the auto detected converter configuration line in 
>> ~/Library/Application\ Support/LyX-2.3/lyxrc.defaults
>> 
>> \converter svgpng"inkscape --without-gui --file=$$p$$i 
>> --export-png=$$p$$o""",
>> 
>> I’m not sure how this should work - obviously it doesn’t work.
> 
> To be more explicit: it doesn’t work on Mac with inkscape installed. One 
> possible work around for you would be to change the converter definitions for 
> SVG to PNG and SVGZ to PNG.
> 
> Remove the $$p from the converter parameters (see attached screen shot).
> 
> Stephan
> 
> 



Re: Patch for bug in elsarticle.cls

2019-01-01 Thread Jürgen Spitzmüller
Am Donnerstag, den 06.09.2018, 14:18 +0530 schrieb Rishikesan Nair T:
> On Thu, Sep 6, 2018 at 1:55 PM, Jürgen Spitzmüller 
> wrote:
> > Dear colleagues
> > 
> > Please find attached a patch that fixes an issue in recent
> > elsarticle.cls (3.0). The problem is that you forgot to check the
> > existence of the titlefootnote (tnote) label (\X@t) in
> > \tnotemark (as opposed to the other labels in other contexts, where
> > you check with \elsRef). As a consequence, you get a "missing
> > number" LaTeX error on the first LaTeX run (before the labels are
> > written to the aux file). This is a problem with editors that break
> > compilations on LaTeX errors (such as LyX, which currently cannot
> > process elsarticle documents with title footnotes).
> > 
> > Please consider this patch for the next release of the class.
> > 
> > 
> 
>  
> Dear Jürgen,
> 
> Thank you for the patch. Next week we will release an updated version
> to CTAN. We will include this patch as well.

Dear Rishi

Happy New Year!

Is it possible that the updated version didn't make it to CTAN yet?

Best
Jürgen

> 
> thank you
> -- 
> Rishi T.
> LaTeX Support at STMDOCS
> 


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