Re: Packagers, please upload binaries for 2.2.0alpha1

[Liviu Andronic]

On Mon, Nov 16, 2015 at 11:23 PM, Scott Kostyshak  wrote:
> Thanks for uploading to the PPA. I made a few changes to the
> description:
>
> "upcoming 2.1 release" -> "upcoming 2.2 release"
> and I added a new legend item:
> lyx2.2pre -- a pre-release (e.g. alpha, beta) of an upcoming
> (development) major release
>
Thanks, Scott. Looks good.

Liviu


-- 
Do you think you know what math is?
http://www.ideasroadshow.com/issues/ian-stewart-2013-08-02
Or what it means to be intelligent?
http://www.ideasroadshow.com/issues/john-duncan-2013-08-30
Think again:
http://www.ideasroadshow.com/library

Re: Printer in 2.2.0alpha1

[Scott Kostyshak]

On Tue, Nov 17, 2015 at 08:22:39AM +0100, Buenas Noticias wrote:
> Hi all :
> 
> I'm testing 2.2.0alpha1 and noted that don't appear the printer icon or
> menu. I have compiled the tarball to Mageia 5 Linux. It's a bug?
> 
> Greetings
> 
> Miguel

Hi Miguel,

Thanks for testing. Your feedback is important. We removed the print
functionality from LyX (and thus the icon). Please read the file
lib/RELEASE-NOTES for an explanation as well as instructions on how to
get the functionality back if you desire. Here is the relevant part:

* Support for printing from within LyX (File> Print) has been removed. LyX's
  printing support was very limited, and most users will want to print after
  reviewing an output document (e.g., a PDF), anyway, which can be done from the
  PDF viewer.
  Users who would like to restore this functionality can create a
  "printer" format from within LyX and then define, say, a
  pdf->printer converter that does nothing but call lpd, or a2ps, or
  whatever. The "printer" will then be available as an export option.

Scott


signature.asc
Description: PGP signature

Printer in 2.2.0alpha1

[Buenas Noticias]

Hi all :

I'm testing 2.2.0alpha1 and noted that don't appear the printer icon or 
menu. I have compiled the tarball to Mageia 5 Linux. It's a bug?


Greetings

Miguel

Re: [LyX/master] Cmake export tests: More tests to be reverted.

[Guenter Milde]

On 2015-11-16, Kornel Benko wrote:
> Am Montag, 16. November 2015 um 21:01:19, schrieb Guenter Milde 
> 
>> On 2015-11-16, Kornel Benko wrote:
>> > Am Montag, 16. November 2015 um 14:17:23, schrieb Scott Kostyshak 
>> > 

...

>> >> > ATM, the latex comments in user preamble are removed before
>> >> > export test.

...

> It is not the test script return failure. It is lyx itself interpreting
> latex result. If lyx exit != 0, then there is no choice for the test
> IMHO.

However, as the "non-ASCII in preamble" warning is a false positive and
LaTeX does not have a problem with "unencodable" characters in a comment, it
is no problem to leave these comments in the lyx-document and no wonder that
removing them does not solve any failure.


Test with de/Customization.lyx (where XeTeX-compilation works despite the
warnings):

lyx/lib/doc/de > lyx-svn -e pdf4 Customization.lyx 
BufferParams.cpp (1978): Uncodable character 'ä' in user preamble!
...
BufferParams.cpp (1978): Uncodable character 'ß' in user preamble!
Warning: Unkodierbares Zeichen im Benutzervorspann

Der LaTeX-Vorspann Ihres Dokuments enthält Zeichen,die in der aktuellen 
Kodierung nicht dargestellt werden können (nämlich: äääöüüüöüüäüöß).
Die betroffenen Zeichen werden in der LaTeX-Ausgabe weggelassen.

Wählen Sie eine passende Kodierung (bspw. utf8)
oder ändern Sie den LaTeX-Code im Vorspann.
This is XeTeX, Version 3.14159265-2.6-0.2 (TeX Live 2015/Debian) (preloaded 
format=xelatex)
 restricted \write18 enabled.
...


Could you log and post the error messages for failing tests?

Günter

Re: Packagers, please upload binaries for 2.2.0alpha1

[Scott Kostyshak]

On Tue, Nov 17, 2015 at 12:44:37AM +0100, Uwe Stöhr wrote:
> Am 14.11.2015 um 20:34 schrieb Scott Kostyshak:
> 
> >I would like to make the announcement for the alpha release on Monday.
> 
> Here is the installer for Windows:
> 
> http://ftp.lyx.de/LyX%202.2.0-alpha-1/

Also, what version of Qt do you use to build? 5.5.1?

Scott


signature.asc
Description: PGP signature

"releasing" alpha

[Scott Kostyshak]

From what I understand, we do not post news on our website for an alpha
release and we do not send to the announce list. What announcing should
I do?

Would it be reasonable to send an email to lyx-user (of course with the
disclaimer that they should not use alpha for serious work)? Can I tweet
the alpha release?

I have collected a list of users interested in testing (mostly for Mac).
I will email them privately to let them know about alpha.

Any other announcing to do for alpha1?

Scott


signature.asc
Description: PGP signature

Re: Packagers, please upload binaries for 2.2.0alpha1

[Scott Kostyshak]

On Tue, Nov 17, 2015 at 12:44:37AM +0100, Uwe Stöhr wrote:
> Am 14.11.2015 um 20:34 schrieb Scott Kostyshak:
> 
> >I would like to make the announcement for the alpha release on Monday.
> 
> Here is the installer for Windows:
> 
> http://ftp.lyx.de/LyX%202.2.0-alpha-1/

Thanks. What is LyXPackageComplete220-alpha1.zip and should it be
uploaded to the FTP?

In 2.1.0 final, it seems no such LyXPackageComplete*.zip was uploaded:
ftp://ftp.lyx.org/pub/lyx/bin/2.1.0/

For 2.1.0beta1, only the Installer and the Complete were uploaded, but not
the bundle:
ftp://ftp.lyx.org/pub/lyx/devel/lyx-2.1/lyx-2.1.0beta1/

For 2.1.0beta2, only the Installer was uploaded:
ftp://ftp.lyx.org/pub/lyx/devel/lyx-2.1/lyx-2.1.0beta2/

FOr 2.1.0rc1, only the Installer and Bundle were uploaded:
ftp://ftp.lyx.org/pub/lyx/devel/lyx-2.1/lyx-2.1.0rc1/

What is the reason for all these differences? What does it depend on for
whether we provide a Bundle and/or Complete?

Scott


signature.asc
Description: PGP signature

Re: Basic test of alpha1 tar

[Scott Kostyshak]

On Tue, Nov 17, 2015 at 12:49:02AM +0100, Uwe Stöhr wrote:
> Am 14.11.2015 um 20:24 schrieb Scott Kostyshak:
> 
> >If you have time, please download the LyX 2.2.0alpha1 tar and test that
> >it compiles/installs as expected.
> 
> It compiles but not as merged build. With
> 
> -DLYX_MERGE_REBUILD=1 -DLYX_MERGE_FILES=1
> 
> I get 40 errors, most of them due to a problem with apple script:

Thanks for testing. This is my fault for not testing compilation with
monolithic build. I will (hopefully) not make the same mistake again.
The monolithic build now succeeds for autotools. I think there might
still be an error for the CMake monolithic build that is being
investigated.

Scott

>   support.lib(_allinone_const.obj) : error LNK2019: link to unresolved
> external symbol ""class lyx::frontend::Application * __cdecl
> lyx::theApp(void)" (?theApp@lyx@@YAPAVApplication@frontend@1@XZ)" in
> Funktion "_applescript_execute_command".
> [D:\LyXGit\Master\compile-result\src\tests\check_ExternalTransforms.vcxproj]
>   support.lib(_allinone_const.obj) : error LNK2019: Verweis auf nicht
> aufgel÷stes externes Symbol ""public: __thiscall
> lyx::FuncRequest::FuncRequest(class lyx
> ::FuncRequest const &,class std::basic_string std::char_traits,class std::allocator > const &,enum
> lyx::FuncRequest::Origin)" (??0Func
> Request@lyx@@QAE@ABV01@ABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@
> 2@@std@@W4Origin@01@@Z)" in Funktion "_applescript_execute_command".
> [D:\LyXGit
> \Master\compile-result\src\tests\check_ExternalTransforms.vcxproj]
> 
> .
> 
> regards Uwe


signature.asc
Description: PGP signature

Re: Packagers, please upload binaries for 2.2.0alpha1

[Guillaume Munch]

Le 17/11/2015 00:47, Scott Kostyshak a écrit :

On Mon, Nov 16, 2015 at 11:07:26PM +, Guillaume Munch wrote:

Le 16/11/2015 22:23, Scott Kostyshak a écrit :

On Mon, Nov 16, 2015 at 01:00:09PM +0100, Liviu Andronic wrote:

On Mon, Nov 16, 2015 at 12:46 PM, Guillaume Munch  wrote:

Le 16/11/2015 11:33, Liviu Andronic a écrit :


The Ubuntu packages are built against Qt 4.8. Scott, is it a good or a
bad idea to build against Qt 5.4.1/5.4.2, where available?



With Qt 5.4.1 in Ubuntu I am affected by
 and
. On the other hand,
 is solved with Qt 5.4.1. But the
latter has workarounds.


So overall not a very good idea. Thanks,
Liviu


I agree with Guillaume.


I should have been more precise so as not to suggest that Guillaume
agrees with my next sentence (although I suppose purely logically, he
does agree that < 5.5 is not worth to build against, he just thinks 5.5
is also not worth to build against).


I would say it is not worth to build against any
Qt 5.x less than 5.5.


Well, I remember seeing a message on lyx-general reporting independently
some slowness that looked like the symptoms of 9731 so I would take it
into account. (Unless you mean "not ≤ 5.5" in which case I agree with you.)


I meant < 5.5. I do not think 9731 is a show-stopper for a pre-release.
I do think 5.4 has showstopper bugs for a pre-release. If Qt 5.5 were
available (in the Ubuntu repos) for Liviu to link against, I think it
would be interesting to discuss having a pre-release with it. We could
get good feedback on potential complications for if we decide to link to
5.6 (e.g. in Ubuntu 16.04) when it comes out. I don't think 9731 would
add so much noise to the feedback.



Haha thanks for the clarification.


For a final release, if the choice is between 4.8.x and 5.5 then I agree
with what I think you believe, that 4.8.x is the best choice.


Yes.

Re: Packagers, please upload binaries for 2.2.0alpha1

[Scott Kostyshak]

On Mon, Nov 16, 2015 at 11:07:26PM +, Guillaume Munch wrote:
> Le 16/11/2015 22:23, Scott Kostyshak a écrit :
> >On Mon, Nov 16, 2015 at 01:00:09PM +0100, Liviu Andronic wrote:
> >>On Mon, Nov 16, 2015 at 12:46 PM, Guillaume Munch  wrote:
> >>>Le 16/11/2015 11:33, Liviu Andronic a écrit :
> 
> The Ubuntu packages are built against Qt 4.8. Scott, is it a good or a
> bad idea to build against Qt 5.4.1/5.4.2, where available?
> 
> >>>
> >>>With Qt 5.4.1 in Ubuntu I am affected by
> >>> and
> >>>. On the other hand,
> >>> is solved with Qt 5.4.1. But the
> >>>latter has workarounds.
> >>>
> >>So overall not a very good idea. Thanks,
> >>Liviu
> >
> >I agree with Guillaume.

I should have been more precise so as not to suggest that Guillaume
agrees with my next sentence (although I suppose purely logically, he
does agree that < 5.5 is not worth to build against, he just thinks 5.5
is also not worth to build against).

> >I would say it is not worth to build against any
> >Qt 5.x less than 5.5.
> 
> Well, I remember seeing a message on lyx-general reporting independently
> some slowness that looked like the symptoms of 9731 so I would take it
> into account. (Unless you mean "not ≤ 5.5" in which case I agree with you.)

I meant < 5.5. I do not think 9731 is a show-stopper for a pre-release.
I do think 5.4 has showstopper bugs for a pre-release. If Qt 5.5 were
available (in the Ubuntu repos) for Liviu to link against, I think it
would be interesting to discuss having a pre-release with it. We could
get good feedback on potential complications for if we decide to link to
5.6 (e.g. in Ubuntu 16.04) when it comes out. I don't think 9731 would
add so much noise to the feedback.

For a final release, if the choice is between 4.8.x and 5.5 then I agree
with what I think you believe, that 4.8.x is the best choice.

Scott


signature.asc
Description: PGP signature

Re: master branch is open again

[Scott Kostyshak]

On Mon, Nov 16, 2015 at 01:20:11PM -0500, Richard Heck wrote:
> On 11/15/2015 05:27 PM, Scott Kostyshak wrote:
> >
> >The following is not a critique (so please push because of Richard's 
> >positive feedback), but if you have time I am curious about the following:
> >
> >strwidth_cache_(1 << 19)
> >
> >How did you decide on 19? And why the trick of 1 << 19 instead of just the 
> >following?
> >
> >strwidth_cache_(19)
> >
> >I'm guessing this is a C++ trick I should know.
> 
> 1 << 19 is a 1 with 19 zeros after it, in binary notation, so is equivalent
> to 2^19 = 512K but much faster to calculate. This trick is used extensively
> in debug.h.

Thanks for this explanation, Richard. Now I understand.

I'm still curious how 512K was chosen.

Scott


signature.asc
Description: PGP signature

Re: Basic test of alpha1 tar

[Scott Kostyshak]

On Tue, Nov 17, 2015 at 01:03:21AM +0100, Stephan Witt wrote:
> Am 17.11.2015 um 00:50 schrieb Stephan Witt :
> 
> > Am 17.11.2015 um 00:06 schrieb Scott Kostyshak :
> > 
> >> On Tue, Nov 17, 2015 at 12:01:16AM +0100, Stephan Witt wrote:
> >>> Am 16.11.2015 um 23:50 schrieb Scott Kostyshak :
> >>> 
>  On Mon, Nov 16, 2015 at 05:48:03PM -0500, Richard Heck wrote:
> > On 11/16/2015 05:39 PM, Scott Kostyshak wrote:
> >> On Mon, Nov 16, 2015 at 10:59:09AM +0100, Stephan Witt wrote: >> Am 
> >> 14.11.2015 um 20:24 schrieb Scott Kostyshak :
> >> Dear all, >>> >>> If you have time, please download the LyX
> > 2.2.0alpha1 tar and test that >>> it compiles/installs as expected. It
> > is located here: >>> >>>
> > ftp://ftp.lyx.org/pub/lyx/devel/lyx-2.2/lyx-2.2.0alpha1/ >>> >>> Also if
> > you can, please check that it verifies correctly. This is my >>> first
> > time signing a tar ball. >> >> The signature is ok. The build on Mac OS
> > X works. > > Thanks for checking these. > >> I've uploaded the result
> > here: >> >>
> > https://dl.dropboxusercontent.com/u/27842660/LyX-2.2.0alpha1%2Bqt5-x86_64-cocoa.dmg
> >>> 
> > https://dl.dropboxusercontent.com/u/27842660/LyX-2.2.0alpha1%2Bqt5-x86_64-cocoa.dmg.sig
> > I've used Qt 5.5.1 to build it. > > Good choice. > > The key you
> > used to sign expired a year and a half ago: > > $ gpg --verify *sig >
> > gpg: assuming signed data in `LyX-2.2.0alpha1+qt5-x86_64-cocoa.dmg' >
> > gpg: Signature made Mon 16 Nov 2015 04:09:30 AM EST using RSA key ID >
> > EE614DC4 > gpg: Good signature from "LyX on Mac OS X (Signing LyX disk
> > images) > " > gpg: Note: This key has expired! > Primary
> > key fingerprint: 4154 4A61 DBB7 7561 47C1  DD4F A149 7996 EE61 > 4DC4 >
> > $ > > Is this a problem? > I imagine it is not a problem for alpha, and
> > that I should go ahead and > upload your .dmg but I wanted to check 
> > first.
> > 
> > Just to be clear: You should resign this with the LyX key. Stephan's
> > signature is only to guarantee to you that the binary is valid and from 
> > him.
>  
>  Ah thanks for pointing this out. I actually did not know that. I will
>  resign.
> >>> 
> >>> Yes, please. At the time I made the key I gave it a time limit. Then I've
> >>> published it. Later - after the expiration, I made a new one and Vincent
> >>> "complained" that this key isn't published. I realized then that I can 
> >>> extend
> >>> the period of validity and did that. But now the key servers don't accept 
> >>> this.
> >>> I don't know how to deal with that, sorry :(
> >> 
> >> Not a problem at all for me. I just wanted to double-check.
> >> 
> >> Indeed, it is nice if the key is published. This should be easy with the
> >> command
> >> 
> >> gpg --send-keys B6470BEB
> >> 
> >> where B6470BEB is the ID you want to publish. It seems you have tried
> >> something like that and the keyserver gave an error? What is the error
> >> from that command?
> > 
> > 
> > I've sent it already anno 2011.
> > 
> > This is my current attempt to follow your advice:
> > $ gpg --send-keys EE614DC4
> > gpg: sende Schlüssel EE614DC4 auf den hkp-Server keys.gnupg.net
> > gpg: Schlüsselserver-Zeitüberschreitung
> > gpg: Senden an Schlüsselserver fehlgeschlagen: Schlüsselserverfehler
> > $ LANG=C gpg --send-keys EE614DC4
> > gpg: sending key EE614DC4 to hkp server keys.gnupg.net
> > $ LANG=C gpg --search-keys sw...@lyx.org
> > gpg: searching for "sw...@lyx.org" from hkp server keys.gnupg.net
> > (1) LyX on Mac OS X (Signing LyX disk images) 
> >   2048 bit RSA key EE614DC4, created: 2011-03-09, expires: 2014-03-08 
> > (expired)
> > (2) Stephan Witt 
> > LyX on Mac OS X (Signing LyX disk images) 
> >   2048 bit RSA key F7BCC31C, created: 2011-03-09
> > Keys 1-2 of 2 for "sw...@lyx.org".  Enter number(s), N)ext, or Q)uit > q
> > $
> > 
> > Note the missing error message while trying to send the key with LANG=C.
> 
> Wow, now it's updated! Another example of giving preference to english :)

Sorry :)

> $ LANG=C gpg --search-keys sw...@lyx.org
> gpg: searching for "sw...@lyx.org" from hkp server keys.gnupg.net
> (1)   LyX on Mac OS X (Signing LyX disk images) 
> 2048 bit RSA key EE614DC4, created: 2011-03-09, expires: 2017-03-25
> (2)   Stephan Witt 
>   LyX on Mac OS X (Signing LyX disk images) 
> 2048 bit RSA key F7BCC31C, created: 2011-03-09
> Keys 1-2 of 2 for "sw...@lyx.org".  Enter number(s), N)ext, or Q)uit > q

Just did a 'gpg --recv-keys' and it looks good.

Scott


signature.asc
Description: PGP signature

Re: [patch] RFC: better submenu for tables

[Uwe Stöhr]

Am 13.11.2015 um 14:16 schrieb Jean-Marc Lasgouttes:


Like the patch below?


Yes, exactly, thanks. Please put this in. (and also the update of 
LFUNs.lyx in our doc folder.)



Note that I renamed Dialog Settings to Settings...

like everywhere else.


OK.

> And what should be done with the Edit>Table menu? Shall it directly 
use the table contextual menu?


Yes.

many thanks and regards
Uwe

[patch] support for 'solution' in theorems

[Uwe Stöhr]

The attached patch would fix the longstanding bug

http://www.lyx.org/trac/ticket/6363

This would be a fileformat change and that is why Scott wanted to have 
this in after alpha 1.


OK to proceed or do I have to add special tex2lyx things?

thanks and regards
Uwe
 lib/layouts/theorems-bytype.inc| 20 +
 lib/layouts/theorems-bytype.module |  2 ++
 lib/layouts/theorems.inc   | 18 +++
 lib/lyx2lyx/lyx_2_2.py | 46 +-
 4 files changed, 85 insertions(+), 1 deletion(-)

diff --git a/lib/layouts/theorems-bytype.inc b/lib/layouts/theorems-bytype.inc
index fb8992d..951b3fd 100644
--- a/lib/layouts/theorems-bytype.inc
+++ b/lib/layouts/theorems-bytype.inc
@@ -16,6 +16,7 @@
 # - Example
 # - Problem
 # - Exercise
+# - Solution
 # - Remark
 # - Claim
 # - Proof
@@ -240,6 +241,25 @@ Style Exercise
 End
 
 
+Style Solution
+   CopyStyle Definition
+   LatexName sol
+   LabelString   "Solution \thesolution."
+   Preamble
+ \theoremstyle{definition}
+ \newtheorem{sol}{\protect\solutionname}
+   EndPreamble
+   Requires  amsthm
+   LangPreamble
+   \providecommand{\solutionname}{_(Solution)}
+   EndLangPreamble
+   BabelPreamble
+   \addto\captions$$lang{\renewcommand{\solutionname}{_(Solution)}}
+   EndBabelPreamble
+   LabelCounter  solution
+End
+
+
 Style Remark
CopyStyle Theorem
LatexName rem
diff --git a/lib/layouts/theorems-bytype.module 
b/lib/layouts/theorems-bytype.module
index a73b8d7..c53ea17 100644
--- a/lib/layouts/theorems-bytype.module
+++ b/lib/layouts/theorems-bytype.module
@@ -34,6 +34,8 @@ Counter problem
 End
 Counter exercise
 End
+Counter solution
+End
 Counter remark
 End
 Counter claim
diff --git a/lib/layouts/theorems.inc b/lib/layouts/theorems.inc
index 0538daf..c82d3e7 100644
--- a/lib/layouts/theorems.inc
+++ b/lib/layouts/theorems.inc
@@ -15,6 +15,7 @@
 # - Example
 # - Problem
 # - Exercise
+# - Solution
 # - Remark
 # - Claim
 # - Case (by inclusion)
@@ -232,6 +233,23 @@ Style Exercise
 End
 
 
+Style Solution
+   CopyStyle Definition
+   LatexName sol
+   LabelString   "Solution \thetheorem."
+   Preamble
+   \theoremstyle{definition}
+   \newtheorem{sol}[thm]{\protect\solutionname}
+   EndPreamble
+   LangPreamble
+   \providecommand{\solutionname}{_(Solution)}
+   EndLangPreamble
+   BabelPreamble
+   \addto\captions$$lang{\renewcommand{\solutionname}{_(Solution)}}
+   EndBabelPreamble
+End
+
+
 Style Remark
CopyStyle Theorem
DependsOn Theorem
diff --git a/lib/lyx2lyx/lyx_2_2.py b/lib/lyx2lyx/lyx_2_2.py
index 6bed08e..11f38b1 100644
--- a/lib/lyx2lyx/lyx_2_2.py
+++ b/lib/lyx2lyx/lyx_2_2.py
@@ -2092,6 +2092,50 @@ def revert_fontsettings(document):
 j = j + 1
 
 
+def revert_solution(document):
+" Reverts the solution environmen of the theorem module to TeX code "
+
+# Do we use theorems-std module?
+have_mod = False
+mods = document.get_module_list()
+for mod in mods:
+if mod == "theorems-std" or mod == "theorems-bytype":
+have_mod = True
+continue
+if not have_mod:
+return
+consecutive = False
+i = 0
+while True:
+i = find_token(document.body, "\\begin_layout Solution", i)
+if i == -1:
+return
+j = find_end_of_layout(document.body, i)
+if j == -1:
+document.warning("Malformed LyX document: Can't find end of 
Solution layout")
+i += 1
+continue
+# if this is not a consecutive env, add start command
+begcmd = []
+if not consecutive:
+begcmd = put_cmd_in_ert("\\begin{sol}")
+# has this a consecutive theorem of same type?
+consecutive = False
+consecutive = document.body[j + 2] == "\\begin_layout Solution"
+# if this is not followed by a consecutive env, add end command
+if not consecutive:
+document.body[j : j + 1] = put_cmd_in_ert("\\end{sol}") + 
["\\end_layout"]
+document.body[i : i + 1] = ["\\begin_layout Standard", ""] + begcmd
+add_to_preamble(document, "\\providecommand{\solutionname}{Solution}")
+if mod == "theorems-std":
+add_to_preamble(document, "\\theoremstyle{plain}\n" \
+  
"\\newtheorem{sol}[thm]{\\protect\\solutionname}")
+if mod == "theorems-bytype":
+add_to_preamble(document, "\\theoremstyle{definition}\n" \
+  
"\\newtheorem{sol}{\\protect\\solutionname}")
+i = j
+
+
 ##
 # Conversion hub
 #
@@ -2131,7 +2175,7 @@ convert = [
   ]
 
 revert =  [
-   [500, [revert_

Re: Basic test of alpha1 tar

[Stephan Witt]

Am 17.11.2015 um 00:50 schrieb Stephan Witt :

> Am 17.11.2015 um 00:06 schrieb Scott Kostyshak :
> 
>> On Tue, Nov 17, 2015 at 12:01:16AM +0100, Stephan Witt wrote:
>>> Am 16.11.2015 um 23:50 schrieb Scott Kostyshak :
>>> 
 On Mon, Nov 16, 2015 at 05:48:03PM -0500, Richard Heck wrote:
> On 11/16/2015 05:39 PM, Scott Kostyshak wrote:
>> On Mon, Nov 16, 2015 at 10:59:09AM +0100, Stephan Witt wrote: >> Am 
>> 14.11.2015 um 20:24 schrieb Scott Kostyshak :
>> Dear all, >>> >>> If you have time, please download the LyX
> 2.2.0alpha1 tar and test that >>> it compiles/installs as expected. It
> is located here: >>> >>>
> ftp://ftp.lyx.org/pub/lyx/devel/lyx-2.2/lyx-2.2.0alpha1/ >>> >>> Also if
> you can, please check that it verifies correctly. This is my >>> first
> time signing a tar ball. >> >> The signature is ok. The build on Mac OS
> X works. > > Thanks for checking these. > >> I've uploaded the result
> here: >> >>
> https://dl.dropboxusercontent.com/u/27842660/LyX-2.2.0alpha1%2Bqt5-x86_64-cocoa.dmg
>>> 
> https://dl.dropboxusercontent.com/u/27842660/LyX-2.2.0alpha1%2Bqt5-x86_64-cocoa.dmg.sig
> I've used Qt 5.5.1 to build it. > > Good choice. > > The key you
> used to sign expired a year and a half ago: > > $ gpg --verify *sig >
> gpg: assuming signed data in `LyX-2.2.0alpha1+qt5-x86_64-cocoa.dmg' >
> gpg: Signature made Mon 16 Nov 2015 04:09:30 AM EST using RSA key ID >
> EE614DC4 > gpg: Good signature from "LyX on Mac OS X (Signing LyX disk
> images) > " > gpg: Note: This key has expired! > Primary
> key fingerprint: 4154 4A61 DBB7 7561 47C1  DD4F A149 7996 EE61 > 4DC4 >
> $ > > Is this a problem? > I imagine it is not a problem for alpha, and
> that I should go ahead and > upload your .dmg but I wanted to check first.
> 
> Just to be clear: You should resign this with the LyX key. Stephan's
> signature is only to guarantee to you that the binary is valid and from 
> him.
 
 Ah thanks for pointing this out. I actually did not know that. I will
 resign.
>>> 
>>> Yes, please. At the time I made the key I gave it a time limit. Then I've
>>> published it. Later - after the expiration, I made a new one and Vincent
>>> "complained" that this key isn't published. I realized then that I can 
>>> extend
>>> the period of validity and did that. But now the key servers don't accept 
>>> this.
>>> I don't know how to deal with that, sorry :(
>> 
>> Not a problem at all for me. I just wanted to double-check.
>> 
>> Indeed, it is nice if the key is published. This should be easy with the
>> command
>> 
>> gpg --send-keys B6470BEB
>> 
>> where B6470BEB is the ID you want to publish. It seems you have tried
>> something like that and the keyserver gave an error? What is the error
>> from that command?
> 
> 
> I've sent it already anno 2011.
> 
> This is my current attempt to follow your advice:
> $ gpg --send-keys EE614DC4
> gpg: sende Schlüssel EE614DC4 auf den hkp-Server keys.gnupg.net
> gpg: Schlüsselserver-Zeitüberschreitung
> gpg: Senden an Schlüsselserver fehlgeschlagen: Schlüsselserverfehler
> $ LANG=C gpg --send-keys EE614DC4
> gpg: sending key EE614DC4 to hkp server keys.gnupg.net
> $ LANG=C gpg --search-keys sw...@lyx.org
> gpg: searching for "sw...@lyx.org" from hkp server keys.gnupg.net
> (1)   LyX on Mac OS X (Signing LyX disk images) 
> 2048 bit RSA key EE614DC4, created: 2011-03-09, expires: 2014-03-08 
> (expired)
> (2)   Stephan Witt 
>   LyX on Mac OS X (Signing LyX disk images) 
> 2048 bit RSA key F7BCC31C, created: 2011-03-09
> Keys 1-2 of 2 for "sw...@lyx.org".  Enter number(s), N)ext, or Q)uit > q
> $
> 
> Note the missing error message while trying to send the key with LANG=C.

Wow, now it's updated! Another example of giving preference to english :)

$ LANG=C gpg --search-keys sw...@lyx.org
gpg: searching for "sw...@lyx.org" from hkp server keys.gnupg.net
(1) LyX on Mac OS X (Signing LyX disk images) 
  2048 bit RSA key EE614DC4, created: 2011-03-09, expires: 2017-03-25
(2) Stephan Witt 
LyX on Mac OS X (Signing LyX disk images) 
  2048 bit RSA key F7BCC31C, created: 2011-03-09
Keys 1-2 of 2 for "sw...@lyx.org".  Enter number(s), N)ext, or Q)uit > q

Stephan

Re: Basic test of alpha1 tar

[Stephan Witt]

Am 17.11.2015 um 00:06 schrieb Scott Kostyshak :

> On Tue, Nov 17, 2015 at 12:01:16AM +0100, Stephan Witt wrote:
>> Am 16.11.2015 um 23:50 schrieb Scott Kostyshak :
>> 
>>> On Mon, Nov 16, 2015 at 05:48:03PM -0500, Richard Heck wrote:
 On 11/16/2015 05:39 PM, Scott Kostyshak wrote:
> On Mon, Nov 16, 2015 at 10:59:09AM +0100, Stephan Witt wrote: >> Am 
> 14.11.2015 um 20:24 schrieb Scott Kostyshak :
> Dear all, >>> >>> If you have time, please download the LyX
 2.2.0alpha1 tar and test that >>> it compiles/installs as expected. It
 is located here: >>> >>>
 ftp://ftp.lyx.org/pub/lyx/devel/lyx-2.2/lyx-2.2.0alpha1/ >>> >>> Also if
 you can, please check that it verifies correctly. This is my >>> first
 time signing a tar ball. >> >> The signature is ok. The build on Mac OS
 X works. > > Thanks for checking these. > >> I've uploaded the result
 here: >> >>
 https://dl.dropboxusercontent.com/u/27842660/LyX-2.2.0alpha1%2Bqt5-x86_64-cocoa.dmg
>> 
 https://dl.dropboxusercontent.com/u/27842660/LyX-2.2.0alpha1%2Bqt5-x86_64-cocoa.dmg.sig
 I've used Qt 5.5.1 to build it. > > Good choice. > > The key you
 used to sign expired a year and a half ago: > > $ gpg --verify *sig >
 gpg: assuming signed data in `LyX-2.2.0alpha1+qt5-x86_64-cocoa.dmg' >
 gpg: Signature made Mon 16 Nov 2015 04:09:30 AM EST using RSA key ID >
 EE614DC4 > gpg: Good signature from "LyX on Mac OS X (Signing LyX disk
 images) > " > gpg: Note: This key has expired! > Primary
 key fingerprint: 4154 4A61 DBB7 7561 47C1  DD4F A149 7996 EE61 > 4DC4 >
 $ > > Is this a problem? > I imagine it is not a problem for alpha, and
 that I should go ahead and > upload your .dmg but I wanted to check first.
 
 Just to be clear: You should resign this with the LyX key. Stephan's
 signature is only to guarantee to you that the binary is valid and from 
 him.
>>> 
>>> Ah thanks for pointing this out. I actually did not know that. I will
>>> resign.
>> 
>> Yes, please. At the time I made the key I gave it a time limit. Then I've
>> published it. Later - after the expiration, I made a new one and Vincent
>> "complained" that this key isn't published. I realized then that I can extend
>> the period of validity and did that. But now the key servers don't accept 
>> this.
>> I don't know how to deal with that, sorry :(
> 
> Not a problem at all for me. I just wanted to double-check.
> 
> Indeed, it is nice if the key is published. This should be easy with the
> command
> 
>  gpg --send-keys B6470BEB
> 
> where B6470BEB is the ID you want to publish. It seems you have tried
> something like that and the keyserver gave an error? What is the error
> from that command?


I've sent it already anno 2011.

This is my current attempt to follow your advice:
$ gpg --send-keys EE614DC4
gpg: sende Schlüssel EE614DC4 auf den hkp-Server keys.gnupg.net
gpg: Schlüsselserver-Zeitüberschreitung
gpg: Senden an Schlüsselserver fehlgeschlagen: Schlüsselserverfehler
$ LANG=C gpg --send-keys EE614DC4
gpg: sending key EE614DC4 to hkp server keys.gnupg.net
$ LANG=C gpg --search-keys sw...@lyx.org
gpg: searching for "sw...@lyx.org" from hkp server keys.gnupg.net
(1) LyX on Mac OS X (Signing LyX disk images) 
  2048 bit RSA key EE614DC4, created: 2011-03-09, expires: 2014-03-08 
(expired)
(2) Stephan Witt 
LyX on Mac OS X (Signing LyX disk images) 
  2048 bit RSA key F7BCC31C, created: 2011-03-09
Keys 1-2 of 2 for "sw...@lyx.org".  Enter number(s), N)ext, or Q)uit > q
$

Note the missing error message while trying to send the key with LANG=C.

Stephan

Re: Basic test of alpha1 tar

[Uwe Stöhr]

Am 14.11.2015 um 20:24 schrieb Scott Kostyshak:


If you have time, please download the LyX 2.2.0alpha1 tar and test that
it compiles/installs as expected.


It compiles but not as merged build. With

-DLYX_MERGE_REBUILD=1 -DLYX_MERGE_FILES=1

I get 40 errors, most of them due to a problem with apple script:

  support.lib(_allinone_const.obj) : error LNK2019: link to unresolved 
external symbol ""class lyx::frontend::Application * __cdecl 
lyx::theApp(void)" (?theApp@lyx@@YAPAVApplication@frontend@1@XZ)" in 
Funktion "_applescript_execute_command". 
[D:\LyXGit\Master\compile-result\src\tests\check_ExternalTransforms.vcxproj]
  support.lib(_allinone_const.obj) : error LNK2019: Verweis auf nicht 
aufgel÷stes externes Symbol ""public: __thiscall 
lyx::FuncRequest::FuncRequest(class lyx
::FuncRequest const &,class std::basic_stringstd::char_traits,class std::allocator > const &,enum 
lyx::FuncRequest::Origin)" (??0Func

Request@lyx@@QAE@ABV01@ABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@
2@@std@@W4Origin@01@@Z)" in Funktion "_applescript_execute_command". 
[D:\LyXGit

\Master\compile-result\src\tests\check_ExternalTransforms.vcxproj]

.

regards Uwe

Re: Packagers, please upload binaries for 2.2.0alpha1

[Uwe Stöhr]

Am 14.11.2015 um 20:34 schrieb Scott Kostyshak:


I would like to make the announcement for the alpha release on Monday.


Here is the installer for Windows:

http://ftp.lyx.de/LyX%202.2.0-alpha-1/

regards Uwe

Re: Bad Exception Crash in Master

[Guillaume Munch]

Le 16/11/2015 23:00, Scott Kostyshak a écrit :

Thanks for making a summary of this, Guillaume.


You are welcome, Scott.


Should we add this piece of advice (once confirmed) to Development.lyx?
It is still not exactly clear to me what that document is for, but I
personally would like guidelines like this in there.


If I am correct, support/regex.h is going to disappear soon with the
switch to c++11 and we are all going to rely on the same standard, so
this warning is not going to be necessary.

Guillaume

Re: Packagers, please upload binaries for 2.2.0alpha1

[Guillaume Munch]

Le 16/11/2015 22:23, Scott Kostyshak a écrit :

On Mon, Nov 16, 2015 at 01:00:09PM +0100, Liviu Andronic wrote:

On Mon, Nov 16, 2015 at 12:46 PM, Guillaume Munch  wrote:

Le 16/11/2015 11:33, Liviu Andronic a écrit :


The Ubuntu packages are built against Qt 4.8. Scott, is it a good or a
bad idea to build against Qt 5.4.1/5.4.2, where available?



With Qt 5.4.1 in Ubuntu I am affected by
 and
. On the other hand,
 is solved with Qt 5.4.1. But the
latter has workarounds.


So overall not a very good idea. Thanks,
Liviu


I agree with Guillaume. I would say it is not worth to build against any
Qt 5.x less than 5.5.


Well, I remember seeing a message on lyx-general reporting independently
some slowness that looked like the symptoms of 9731 so I would take it
into account. (Unless you mean "not ≤ 5.5" in which case I agree with you.)

Re: Basic test of alpha1 tar

[Scott Kostyshak]

On Tue, Nov 17, 2015 at 12:01:16AM +0100, Stephan Witt wrote:
> Am 16.11.2015 um 23:50 schrieb Scott Kostyshak :
> 
> > On Mon, Nov 16, 2015 at 05:48:03PM -0500, Richard Heck wrote:
> >> On 11/16/2015 05:39 PM, Scott Kostyshak wrote:
> >>> On Mon, Nov 16, 2015 at 10:59:09AM +0100, Stephan Witt wrote: >> Am 
> >>> 14.11.2015 um 20:24 schrieb Scott Kostyshak :
> >>> Dear all, >>> >>> If you have time, please download the LyX
> >> 2.2.0alpha1 tar and test that >>> it compiles/installs as expected. It
> >> is located here: >>> >>>
> >> ftp://ftp.lyx.org/pub/lyx/devel/lyx-2.2/lyx-2.2.0alpha1/ >>> >>> Also if
> >> you can, please check that it verifies correctly. This is my >>> first
> >> time signing a tar ball. >> >> The signature is ok. The build on Mac OS
> >> X works. > > Thanks for checking these. > >> I've uploaded the result
> >> here: >> >>
> >> https://dl.dropboxusercontent.com/u/27842660/LyX-2.2.0alpha1%2Bqt5-x86_64-cocoa.dmg
>  
> >> https://dl.dropboxusercontent.com/u/27842660/LyX-2.2.0alpha1%2Bqt5-x86_64-cocoa.dmg.sig
> >> I've used Qt 5.5.1 to build it. > > Good choice. > > The key you
> >> used to sign expired a year and a half ago: > > $ gpg --verify *sig >
> >> gpg: assuming signed data in `LyX-2.2.0alpha1+qt5-x86_64-cocoa.dmg' >
> >> gpg: Signature made Mon 16 Nov 2015 04:09:30 AM EST using RSA key ID >
> >> EE614DC4 > gpg: Good signature from "LyX on Mac OS X (Signing LyX disk
> >> images) > " > gpg: Note: This key has expired! > Primary
> >> key fingerprint: 4154 4A61 DBB7 7561 47C1  DD4F A149 7996 EE61 > 4DC4 >
> >> $ > > Is this a problem? > I imagine it is not a problem for alpha, and
> >> that I should go ahead and > upload your .dmg but I wanted to check first.
> >> 
> >> Just to be clear: You should resign this with the LyX key. Stephan's
> >> signature is only to guarantee to you that the binary is valid and from 
> >> him.
> > 
> > Ah thanks for pointing this out. I actually did not know that. I will
> > resign.
> 
> Yes, please. At the time I made the key I gave it a time limit. Then I've
> published it. Later - after the expiration, I made a new one and Vincent
> "complained" that this key isn't published. I realized then that I can extend
> the period of validity and did that. But now the key servers don't accept 
> this.
> I don't know how to deal with that, sorry :(

Not a problem at all for me. I just wanted to double-check.

Indeed, it is nice if the key is published. This should be easy with the
command

  gpg --send-keys B6470BEB

where B6470BEB is the ID you want to publish. It seems you have tried
something like that and the keyserver gave an error? What is the error
from that command?

Scott


signature.asc
Description: PGP signature

Re: [LyX/master] Fix wrong forward declaration

[Kornel Benko]

Am Montag, 16. November 2015 um 23:58:20, schrieb Kornel Benko 
> Am Montag, 16. November 2015 um 21:54:14, schrieb Georg Baum 
> > commit 0c97d6edc009a968277bda26d2352e7a0868ae33
> > Author: Georg Baum 
> > Date:   Mon Nov 16 21:51:30 2015 +0100
> > 
> > Fix wrong forward declaration
> > 
> > This popped up in cmake monolithic build once. It looks like BufferView 
> > is
> > included indirectly by some of the other headers (otherwise we would 
> > have seen
> > compile errors for other build configurations as well), bu I'll keep the
> > forward declaration since we don't want to depend on this indirect 
> > header
> > inclusion.
> > 
> 
> And again one step further. Cmake claims that 88% compilation went OK with 
> this
> commit before error.
> 
> This last is a link error, not compilation.
> Apparently some file missing in merged source.
> ...
> 
> Hm, why the hell needs check_convert binary `lyx::theApp()'?
> All other executables  were built.
> 

Forgot to say, that I am using 'make package'.
No problems in creating target lyx, tex2lyx etc.

Kornel

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

Re: Bad Exception Crash in Master

[Scott Kostyshak]

On Mon, Nov 16, 2015 at 10:53:17PM +, Guillaume Munch wrote:
> Le 16/11/2015 20:22, Georg Baum a écrit :
> >Richard Heck wrote:
> >
> >>
> >>Recipe:
> >>
> >>1. Open the User Guide.
> >>2. Click somewhere in the main text.
> >>3. Insert > Citation
> >>4. Enter the search field and type "cap"
> >>5. Hit search button.
> >>
> >>Error: Software exception Detected
> >>
> >>LyX has caught an exception, it will now attempt to save all unsaved
> >>documents and exit.
> >>
> >>Exception: regex_error
> >>
> >>This is on Fedora 22, gcc 5.1.1, with configuration as:
> >>--enable-build-type=dev.
> >>
> >>The offending code is this assignment
> >>
> >>  static const lyx::regex reg("[].|*?+(){}^$\\[]");
> >>
> >>in escape_special_characters in GuiCitation.cpp. I would guess that this
> >>is a consequence of changes to the regex engine.
> >
> >I can reproduce with gcc 5.1 in C++11-mode. This is most likely the same
> >problem as http://www.lyx.org/trac/ticket/9799, since the test fails as well
> >for the same compiler, so I guess it happens with gcc4 in C++11 mode as
> >well. Nice to see that the unit test worked! Now we only need to learn not
> >to ignore failing unit tests.
> >
> >Some regex expert needs to find out whether the regex syntax we are using is
> >only valid for boost::regex or for C++11 std::regex as well, and depending
> >on the outcome we either need to change our regex, or file a gcc bug. Or
> >maybe it is some multithreading issue? The 'static' rings some alarm
> >bells...
> >
> >
> 
> If I may try to explain with my own words (because I really didn't get your
> reasoning at first, being far from being a C++ regex expert). Std::regex and
> boost::regex do not set the same regex style by default (perl vs ECMAScript)
> but both support other styles by passing the appropriate flag. The commit
> 4620034e already had fixed a crash a while ago due the use of (what is now)
> std::regex in MSVC, by passing automatically the flag to set the "grep"
> regex style instead of ECMAScript.
> 
> But, in 394e1bf9 you did without passing this flag. The reason, if I
> reconstruct correctly, is that std's ECMAScript style is only supposed to be
> boost's perl style minus a few perl-isms; we shouldn't have to set a style
> "grep" (that may even change the meaning of regexes!). The most sensible
> cross-platform solution is to conform to the ECMAScript subset, and if I
> infer correctly this is what you mean.

Thanks for making a summary of this, Guillaume.

> Once this is understood, we go to the ECMAScript standard and realize that
> "[]" is interpreted as the empty class in ECMAScript. "[]…]" is a perl-ism,
> and ] should be escaped.
> 
> Lesson for everybody apart from Georg: please write regexes according to the
> ECMAScript standard in the future, even if boost is happy with your
> perl-isms.

Should we add this piece of advice (once confirmed) to Development.lyx?
It is still not exactly clear to me what that document is for, but I
personally would like guidelines like this in there.

> Here's a patch that locates a similar issue elsewhere. I did my fair share
> of the exercise, can I please let other people test it and commit the
> appropriate solution?

I can test compilation and 'make check' for different compilation
settings (with/without monolithic build, with/without NLS, clang/gcc). I
am still working on a script to automate that though so I would prefer
first to wait for someone else to check your patch logically.

Scott


signature.asc
Description: PGP signature

Re: Basic test of alpha1 tar

[Stephan Witt]

Am 16.11.2015 um 23:50 schrieb Scott Kostyshak :

> On Mon, Nov 16, 2015 at 05:48:03PM -0500, Richard Heck wrote:
>> On 11/16/2015 05:39 PM, Scott Kostyshak wrote:
>>> On Mon, Nov 16, 2015 at 10:59:09AM +0100, Stephan Witt wrote: >> Am 
>>> 14.11.2015 um 20:24 schrieb Scott Kostyshak :
>>> Dear all, >>> >>> If you have time, please download the LyX
>> 2.2.0alpha1 tar and test that >>> it compiles/installs as expected. It
>> is located here: >>> >>>
>> ftp://ftp.lyx.org/pub/lyx/devel/lyx-2.2/lyx-2.2.0alpha1/ >>> >>> Also if
>> you can, please check that it verifies correctly. This is my >>> first
>> time signing a tar ball. >> >> The signature is ok. The build on Mac OS
>> X works. > > Thanks for checking these. > >> I've uploaded the result
>> here: >> >>
>> https://dl.dropboxusercontent.com/u/27842660/LyX-2.2.0alpha1%2Bqt5-x86_64-cocoa.dmg
 
>> https://dl.dropboxusercontent.com/u/27842660/LyX-2.2.0alpha1%2Bqt5-x86_64-cocoa.dmg.sig
>> I've used Qt 5.5.1 to build it. > > Good choice. > > The key you
>> used to sign expired a year and a half ago: > > $ gpg --verify *sig >
>> gpg: assuming signed data in `LyX-2.2.0alpha1+qt5-x86_64-cocoa.dmg' >
>> gpg: Signature made Mon 16 Nov 2015 04:09:30 AM EST using RSA key ID >
>> EE614DC4 > gpg: Good signature from "LyX on Mac OS X (Signing LyX disk
>> images) > " > gpg: Note: This key has expired! > Primary
>> key fingerprint: 4154 4A61 DBB7 7561 47C1  DD4F A149 7996 EE61 > 4DC4 >
>> $ > > Is this a problem? > I imagine it is not a problem for alpha, and
>> that I should go ahead and > upload your .dmg but I wanted to check first.
>> 
>> Just to be clear: You should resign this with the LyX key. Stephan's
>> signature is only to guarantee to you that the binary is valid and from him.
> 
> Ah thanks for pointing this out. I actually did not know that. I will
> resign.

Yes, please. At the time I made the key I gave it a time limit. Then I've
published it. Later - after the expiration, I made a new one and Vincent
"complained" that this key isn't published. I realized then that I can extend
the period of validity and did that. But now the key servers don't accept this.
I don't know how to deal with that, sorry :(

Stephan

Re: [LyX/master] Fix wrong forward declaration

[Kornel Benko]

Am Montag, 16. November 2015 um 21:54:14, schrieb Georg Baum 
> commit 0c97d6edc009a968277bda26d2352e7a0868ae33
> Author: Georg Baum 
> Date:   Mon Nov 16 21:51:30 2015 +0100
>
> Fix wrong forward declaration
>
> This popped up in cmake monolithic build once. It looks like BufferView is
> included indirectly by some of the other headers (otherwise we would have 
> seen
> compile errors for other build configurations as well), bu I'll keep the
> forward declaration since we don't want to depend on this indirect header
> inclusion.
>

And again one step further. Cmake claims that 88% compilation went OK with this
commit before error.

This last is a link error, not compilation.
Apparently some file missing in merged source.
...

Hm, why the hell needs check_convert binary `lyx::theApp()'?
All other executables  were built.

Kornel

signature.asc
Description: This is a digitally signed message part.
[ 88%] Linking CXX executable ../../../bin/check_convert
cd /usr/BUILD/BuildLyxGitQtlocal/src/support/tests && /usr/bin/cmake -E 
cmake_link_script CMakeFiles/check_convert.dir/link.txt --verbose=1
/usr/bin/c++   -Wall -Wunused-parameter --std=c++11 -fno-strict-aliasing  -Wall 
-Wunused-parameter --std=c++11 -fno-strict-aliasing -O0 -g3 -D_DEBUG   
CMakeFiles/check_convert.dir/check_convert.cpp.o 
CMakeFiles/check_convert.dir/dummy_functions.cpp.o 
CMakeFiles/check_convert.dir/boost.cpp.o  -o ../../../bin/check_convert 
-rdynamic ../../../lib/libsupport.a ../../../lib/libboost_signals.a 
../../../lib/libboost_regex.a -lz -lmagic 
/usr/lib/x86_64-linux-gnu/libQt5Gui.so.5.2.1 
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5.2.1 
../../../lib/libsupport.a(_allinone_const.C.o): In function 
`applescript_execute_command':
/usr/src/lyx/lyx-git/src/support/AppleScriptProxy.cpp:30: undefined reference 
to `lyx::lyxaction'
/usr/src/lyx/lyx-git/src/support/AppleScriptProxy.cpp:30: undefined reference 
to `lyx::LyXAction::lookupFunc(std::string const&) const'
/usr/src/lyx/lyx-git/src/support/AppleScriptProxy.cpp:30: undefined reference 
to `lyx::FuncRequest::FuncRequest(lyx::FuncRequest const&, std::string const&, 
lyx::FuncRequest::Origin)'
/usr/src/lyx/lyx-git/src/support/AppleScriptProxy.cpp:33: undefined reference 
to `lyx::theApp()'
collect2: error: ld returned 1 exit status
make[2]: *** [bin/check_convert] Chyba 1
make[2]: Leaving directory `/usr/BUILD/BuildLyxGitQtlocal'
make[1]: *** [src/support/tests/CMakeFiles/check_convert.dir/all] Chyba 2
make[1]: Leaving directory `/usr/BUILD/BuildLyxGitQtlocal'

Re: Bad Exception Crash in Master

[Guillaume Munch]

Le 16/11/2015 20:22, Georg Baum a écrit :

Richard Heck wrote:



Recipe:

1. Open the User Guide.
2. Click somewhere in the main text.
3. Insert > Citation
4. Enter the search field and type "cap"
5. Hit search button.

Error: Software exception Detected

LyX has caught an exception, it will now attempt to save all unsaved
documents and exit.

Exception: regex_error

This is on Fedora 22, gcc 5.1.1, with configuration as:
--enable-build-type=dev.

The offending code is this assignment

  static const lyx::regex reg("[].|*?+(){}^$\\[]");

in escape_special_characters in GuiCitation.cpp. I would guess that this
is a consequence of changes to the regex engine.


I can reproduce with gcc 5.1 in C++11-mode. This is most likely the same
problem as http://www.lyx.org/trac/ticket/9799, since the test fails as well
for the same compiler, so I guess it happens with gcc4 in C++11 mode as
well. Nice to see that the unit test worked! Now we only need to learn not
to ignore failing unit tests.

Some regex expert needs to find out whether the regex syntax we are using is
only valid for boost::regex or for C++11 std::regex as well, and depending
on the outcome we either need to change our regex, or file a gcc bug. Or
maybe it is some multithreading issue? The 'static' rings some alarm
bells...




If I may try to explain with my own words (because I really didn't get 
your reasoning at first, being far from being a C++ regex expert). 
Std::regex and boost::regex do not set the same regex style by default 
(perl vs ECMAScript) but both support other styles by passing the 
appropriate flag. The commit 4620034e already had fixed a crash a while 
ago due the use of (what is now) std::regex in MSVC, by passing 
automatically the flag to set the "grep" regex style instead of ECMAScript.


But, in 394e1bf9 you did without passing this flag. The reason, if I 
reconstruct correctly, is that std's ECMAScript style is only supposed 
to be boost's perl style minus a few perl-isms; we shouldn't have to set 
a style "grep" (that may even change the meaning of regexes!). The most 
sensible cross-platform solution is to conform to the ECMAScript subset, 
and if I infer correctly this is what you mean.


Once this is understood, we go to the ECMAScript standard and realize 
that "[]" is interpreted as the empty class in ECMAScript. "[]…]" is a 
perl-ism, and ] should be escaped.


Lesson for everybody apart from Georg: please write regexes according to 
the ECMAScript standard in the future, even if boost is happy with your 
perl-isms.


Here's a patch that locates a similar issue elsewhere. I did my fair 
share of the exercise, can I please let other people test it and commit 
the appropriate solution?



Guillaume
diff --git a/src/frontends/qt4/GuiCitation.cpp b/src/frontends/qt4/GuiCitation.cpp
index 052d700..eadff4f 100644
--- a/src/frontends/qt4/GuiCitation.cpp
+++ b/src/frontends/qt4/GuiCitation.cpp
@@ -665,12 +665,12 @@ void GuiCitation::filterByEntryType(BiblioInfo const & bi,
 static docstring escape_special_chars(docstring const & expr)
 {
 	// Search for all chars '.|*?+(){}[^$]\'
-	// Note that '[' and '\' must be escaped.
+	// Note that '[', ']', and '\' must be escaped.
 	// This is a limitation of lyx::regex, but all other chars in BREs
 	// are assumed literal.
-	static const lyx::regex reg("[].|*?+(){}^$\\[]");
+	static const lyx::regex reg("[.|*?+(){}^$\\[\\]]");
 
-	// $& is a perl-like expression that expands to all
+	// $& is an ECMAScript format expression that expands to all
 	// of the current match
 	// The '$' must be prefixed with the escape character '\' for
 	// boost to treat it as a literal.
diff --git a/src/frontends/tests/biblio.cpp b/src/frontends/tests/biblio.cpp
index 933c87a..ae5858d 100644
--- a/src/frontends/tests/biblio.cpp
+++ b/src/frontends/tests/biblio.cpp
@@ -15,12 +15,12 @@ using namespace std;
 string const escape_special_chars(string const & expr)
 {
 	// Search for all chars '.|*?+(){}[^$]\'
-	// Note that '[' and '\' must be escaped.
+	// Note that '[', ']', and '\' must be escaped.
 	// This is a limitation of lyx::regex, but all other chars in BREs
 	// are assumed literal.
-	lyx::regex reg("[].|*?+(){}^$\\[]");
+	lyx::regex reg("[.|*?+(){}^$\\[\\]]");
 
-	// $& is a perl-like expression that expands to all
+	// $& is a ECMAScript format expression that expands to all
 	// of the current match
 	// The '$' must be prefixed with the escape character '\' for
 	// boost to treat it as a literal.
diff --git a/src/insets/ExternalTransforms.cpp b/src/insets/ExternalTransforms.cpp
index f8ce18d..a3bf82d 100644
--- a/src/insets/ExternalTransforms.cpp
+++ b/src/insets/ExternalTransforms.cpp
@@ -283,7 +283,7 @@ string const sanitizeLatexOption(string const & input)
 	// "[foo..." -> "foo..." ("foo..." may be empty)
 	string output;
 	lyx::smatch what;
-	static lyx::regex const front("^( *[[],*)(.*)$");
+	static lyx::regex co

Re: Basic test of alpha1 tar

[Scott Kostyshak]

On Mon, Nov 16, 2015 at 05:48:03PM -0500, Richard Heck wrote:
> On 11/16/2015 05:39 PM, Scott Kostyshak wrote:
> > On Mon, Nov 16, 2015 at 10:59:09AM +0100, Stephan Witt wrote: >> Am 
> > 14.11.2015 um 20:24 schrieb Scott Kostyshak :
> >> >>> Dear all, >>> >>> If you have time, please download the LyX
> 2.2.0alpha1 tar and test that >>> it compiles/installs as expected. It
> is located here: >>> >>>
> ftp://ftp.lyx.org/pub/lyx/devel/lyx-2.2/lyx-2.2.0alpha1/ >>> >>> Also if
> you can, please check that it verifies correctly. This is my >>> first
> time signing a tar ball. >> >> The signature is ok. The build on Mac OS
> X works. > > Thanks for checking these. > >> I've uploaded the result
> here: >> >>
> https://dl.dropboxusercontent.com/u/27842660/LyX-2.2.0alpha1%2Bqt5-x86_64-cocoa.dmg
> >>
> https://dl.dropboxusercontent.com/u/27842660/LyX-2.2.0alpha1%2Bqt5-x86_64-cocoa.dmg.sig
> >> >> I've used Qt 5.5.1 to build it. > > Good choice. > > The key you
> used to sign expired a year and a half ago: > > $ gpg --verify *sig >
> gpg: assuming signed data in `LyX-2.2.0alpha1+qt5-x86_64-cocoa.dmg' >
> gpg: Signature made Mon 16 Nov 2015 04:09:30 AM EST using RSA key ID >
> EE614DC4 > gpg: Good signature from "LyX on Mac OS X (Signing LyX disk
> images) > " > gpg: Note: This key has expired! > Primary
> key fingerprint: 4154 4A61 DBB7 7561 47C1  DD4F A149 7996 EE61 > 4DC4 >
> $ > > Is this a problem? > I imagine it is not a problem for alpha, and
> that I should go ahead and > upload your .dmg but I wanted to check first.
> 
> Just to be clear: You should resign this with the LyX key. Stephan's
> signature is only to guarantee to you that the binary is valid and from him.

Ah thanks for pointing this out. I actually did not know that. I will
resign.

Scott


signature.asc
Description: PGP signature

Re: Basic test of alpha1 tar

[Richard Heck]

On 11/16/2015 05:39 PM, Scott Kostyshak wrote:
> On Mon, Nov 16, 2015 at 10:59:09AM +0100, Stephan Witt wrote: >> Am 
> 14.11.2015 um 20:24 schrieb Scott Kostyshak :
>> >>> Dear all, >>> >>> If you have time, please download the LyX
2.2.0alpha1 tar and test that >>> it compiles/installs as expected. It
is located here: >>> >>>
ftp://ftp.lyx.org/pub/lyx/devel/lyx-2.2/lyx-2.2.0alpha1/ >>> >>> Also if
you can, please check that it verifies correctly. This is my >>> first
time signing a tar ball. >> >> The signature is ok. The build on Mac OS
X works. > > Thanks for checking these. > >> I've uploaded the result
here: >> >>
https://dl.dropboxusercontent.com/u/27842660/LyX-2.2.0alpha1%2Bqt5-x86_64-cocoa.dmg
>>
https://dl.dropboxusercontent.com/u/27842660/LyX-2.2.0alpha1%2Bqt5-x86_64-cocoa.dmg.sig
>> >> I've used Qt 5.5.1 to build it. > > Good choice. > > The key you
used to sign expired a year and a half ago: > > $ gpg --verify *sig >
gpg: assuming signed data in `LyX-2.2.0alpha1+qt5-x86_64-cocoa.dmg' >
gpg: Signature made Mon 16 Nov 2015 04:09:30 AM EST using RSA key ID >
EE614DC4 > gpg: Good signature from "LyX on Mac OS X (Signing LyX disk
images) > " > gpg: Note: This key has expired! > Primary
key fingerprint: 4154 4A61 DBB7 7561 47C1  DD4F A149 7996 EE61 > 4DC4 >
$ > > Is this a problem? > I imagine it is not a problem for alpha, and
that I should go ahead and > upload your .dmg but I wanted to check first.

Just to be clear: You should resign this with the LyX key. Stephan's
signature is only to guarantee to you that the binary is valid and from him.

Richard

Re: [patch] proof of concept for bug 9744: allow parallel configuration of TeX and non-TeX fonts

[Georg Baum]

Guenter Milde wrote:

> On 2015-11-12, Georg Baum wrote:
> 
>> (and the most important reason for me personally is that you can set an
>> explicit default format per document: an automatic choice of non-TeX
>> would eliminate uncompilable documents if such a default format is
>> set).
> 
> This is also already possible, however it is non-intuitive.
> You have to do this at two places: besides Settings>Output you also have
> to make sure there is a matching Settings>Fonts>useNonTeXFonts.

Well, this is exactly what I meant: By changing the default output format 
(and nothing else) you can currently make a document non-compilable for the 
default output format. A non-working default format is (IMHO) more important 
than the existence of any other menu entry that produces an output format 
that does not work.

>> What I want is a solution for the "double automatic" problem: What is the
>> default output format if it is set to automatic in the document, and
>> non-TeX fonts are set to automatic as well?
> 
> Generic rule: every automatic choice should use the "current best
> practice". (CBP) We do this for many cases, e.g. font encoding, language
> package, inputenc (where IMO the current choice is "past best practice"),

What is wrong with our inputenc usage (assuming that xetex or luatex cannot 
be used)? Is the utf8 inputenc mess finally fixed?

> The problem is to agree on the CBP, as there are many different use cases
> and work-flows. But I don't see the "double automatic" as more of a
> problem than the other automatic choices. It is just that the
> "useNonTeXFonts == auto" setting would free us to select a sensible
> default output format.

The problem is also to find out what the CBP is for a particular document. 
Simply using latex (independent of the document contents) is not CPB for all 
documents IMO.

>> None of the discussed solutions was convincing so far for me:
> 
>> 1) Use latex as engine for the default output format and automatic fonts
>> as in my initial patch. This is an arbitrary choice and intransparent for
>> the user.
> 
> This is the backwards compatible choice: no change in LyX-behaviour if you
> change the standard template to have "useNonTeXFonts = auto".

I don't think that 'backwards compatible' is the best term to use here. I 
know what you mean (same behaviour of LyX when switching from TeX fonts to 
auto), but 'backwards compatible' is better used for files IMHO. Otherwise 
it implies that setting "use TeX fonts" always on is the 'old' setting, but 
this is not true. It is the setting to use if you have ERT that requires to 
use TeX fonts.

> No surprises to the user are a strong argument, therefore, this is my
> favourite.

It is no surprise if you compare automatic with TeX fonts. If you compare it 
with non-TeX fonts, then the behaviour may change, and there is no other 
explanation for it than "we had to make a choice, so we assumed using TeX 
fonts is better". I would want a choice that does not depend on assumptions 
on our side, but that depends on the document.

> However, there is now a choice that we have to communicate:
> 
> Possible actions for using fontspec (i.e. Unicode fonts)
> would be:
> 
> a) export/view with XeTeX or LuaTeX via the "other formats" button/menu
> 
> b) set XeTeX/LuaTeX in Document>Settings>Output Default output format
> 
> c) set Document>Settings>Fonts>useNonTeXFonts
> 
> with the differences
> 
> a) is a one-of choice at export time (by the author or a reader).
> 
> b) is the authors choice for a preference for this document not preventing
>export with TeX fonts.
>
> c) is the authors choice, indicating that this document must be "latexed"
>with fontspec. This prevents compilation with 8-bit TeX.
> 
> Currently, the only choice is c).

I don't understand. a) and b) are currently possible as well, they would 
only be made easier to use.

>> 2) Have only one Default Output Format under
>> Tools>Preferences>File>Handling instead of two. Then the default output
>> format of a document with automatic TeX/non-TeX fonts would be the one
>> defined in preferences. Depending on the document contents the default
>> output format may not work at all.
> 
>> 3) Like 2), but with a hard coded substitution list for the cases that
>> the selected format does not work. This would be heavily intransparent
>> for the user: You would need to know a lot of the internals to understand
>> why the default output format would use pdflatex, although you set
>> non-TeX fonts to automatic, and chose XeTeX as default output format in
>> the preferences.
> 
>> 4) Like 3), but with a user configurable substitution list. This would
>> not be intransparent anymore, but still quite difficult to understand.
> 
> We could make the current choices a "two line substitution list":
> 
> The key and tooltip in Tools>Preferences>File>Handling should state that
> the first setting is tried first and the second one is a substitute (for
> the case the first fails).

I do

Re: [LyX/master] Cmake export tests: More tests to be reverted.

[Kornel Benko]

Am Montag, 16. November 2015 um 21:01:19, schrieb Guenter Milde 

> On 2015-11-16, Kornel Benko wrote:
> > Am Montag, 16. November 2015 um 14:17:23, schrieb Scott Kostyshak 
> > 
> >> On Mon, Nov 16, 2015 at 06:51:08PM +0100, Kornel Benko wrote:
> >> > commit b835c454ece6f1f8984664bf07974f4341bfd30c
> >> > Author: Kornel Benko 
> >> > Date:   Mon Nov 16 18:47:34 2015 +0100
> >> > 
> >> > ATM, the latex comments in user preamble are removed before
> >> > export test.
> 
> >> This is just meant to be temporary right?
> 
> > Yes temporary, until we handle non-ascii characters in comments gracefully.
> 
> I don't think we need to remove LaTeX comments nor remove non-ASCII chars
> from the documents. Also, I don't think this is worth fixing in LyX.
> Remember, that this is just a warning that normally only affects
> characters not encodable in the chosen "inputencoding". 
> 
> Problematic is only the case "XeTeX with TeX fonts", because here we need
> inputenc==ASCII even if the setting in the doc is different.
> 
> For documents that explicitly set inputenc==ASCII (a use case would be
> 7-bit safe use/transfer of the exported LaTeX file) we can expect that
> the author avoids non-ASCII characters in the user preamble (and fix
> documents that ship with LyX with this setting).
> 
> 
> > I tested also the suspended cases, but no improvement either.
> 
> Probably, there are other reasons for failure that "kick in" once the
> first obstacle is removed. |: Remember, XeTeX with TeX fonts is fragile :|
> 
> > Commit or not commit, that’s the question ...
> 
> IMO, the test-script should somehow differentiate between LyX warning and
> LyX error and not treat a warning as test failure. Maybe it already does?
> 

It is not the test script return failure. It is lyx itself interpreting latex 
result.
If lyx exit != 0, then there is no choice for the test IMHO.

> Günter

Kornel

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

Re: Basic test of alpha1 tar

[Scott Kostyshak]

On Mon, Nov 16, 2015 at 10:59:09AM +0100, Stephan Witt wrote:
> Am 14.11.2015 um 20:24 schrieb Scott Kostyshak :
> 
> > Dear all,
> > 
> > If you have time, please download the LyX 2.2.0alpha1 tar and test that
> > it compiles/installs as expected. It is located here:
> > 
> > ftp://ftp.lyx.org/pub/lyx/devel/lyx-2.2/lyx-2.2.0alpha1/
> > 
> > Also if you can, please check that it verifies correctly. This is my
> > first time signing a tar ball.
> 
> The signature is ok. The build on Mac OS X works.

Thanks for checking these.

> I've uploaded the result here:
> 
> https://dl.dropboxusercontent.com/u/27842660/LyX-2.2.0alpha1%2Bqt5-x86_64-cocoa.dmg
> https://dl.dropboxusercontent.com/u/27842660/LyX-2.2.0alpha1%2Bqt5-x86_64-cocoa.dmg.sig
> 
> I've used Qt 5.5.1 to build it.

Good choice.

The key you used to sign expired a year and a half ago:

$ gpg --verify *sig
gpg: assuming signed data in `LyX-2.2.0alpha1+qt5-x86_64-cocoa.dmg'
gpg: Signature made Mon 16 Nov 2015 04:09:30 AM EST using RSA key ID
EE614DC4
gpg: Good signature from "LyX on Mac OS X (Signing LyX disk images)
"
gpg: Note: This key has expired!
Primary key fingerprint: 4154 4A61 DBB7 7561 47C1  DD4F A149 7996 EE61
4DC4
$

Is this a problem?
I imagine it is not a problem for alpha, and that I should go ahead and
upload your .dmg but I wanted to check first.

Scott


signature.asc
Description: PGP signature

Re: Packagers, please upload binaries for 2.2.0alpha1

[Scott Kostyshak]

On Mon, Nov 16, 2015 at 01:00:09PM +0100, Liviu Andronic wrote:
> On Mon, Nov 16, 2015 at 12:46 PM, Guillaume Munch  wrote:
> > Le 16/11/2015 11:33, Liviu Andronic a écrit :
> >>
> >> The Ubuntu packages are built against Qt 4.8. Scott, is it a good or a
> >> bad idea to build against Qt 5.4.1/5.4.2, where available?
> >>
> >
> > With Qt 5.4.1 in Ubuntu I am affected by
> >  and
> > . On the other hand,
> >  is solved with Qt 5.4.1. But the
> > latter has workarounds.
> >
> So overall not a very good idea. Thanks,
> Liviu

I agree with Guillaume. I would say it is not worth to build against any
Qt 5.x less than 5.5.

Thanks for uploading to the PPA. I made a few changes to the
description:

"upcoming 2.1 release" -> "upcoming 2.2 release"
and I added a new legend item:
lyx2.2pre -- a pre-release (e.g. alpha, beta) of an upcoming
(development) major release

Scott


signature.asc
Description: PGP signature

Re: synchronizing po file of branch and trunk

[Georg Baum]

Kornel Benko wrote:

> Am Sonntag, 15. November 2015 um 19:03:01, schrieb Georg Baum
> 
>> Kornel Benko wrote:
>
>> Nice, but a pity that it is not python;-( Many years ago it was decided
>> that all scripts should be python, and everything was converted.
> 
> We do not provide perl scripts, but developer should be free to use.

For personal use yes, but I think for tools included in the LyX git repo we 
should stick to python. reLyX (the predecessor of tex2lyx written in perl) 
was ditched because nobody did understand enough perl to maintain it after 
the original author left.

>> > It has to be adapted to ones local paths. Also one has to specify which
>> > languages to are to be handled.
>> 
>> I did it a bit different. If you put the attached file into
>> development/tools, and run it (the single argument is the po directory
>> you want to take the translations from), you'll get this:
> 
> You do not check changed translations, if I read the script correctly?

Yes, this is on purpose, because only the translator knows which version is 
better. However it would be easy to make this behaviour configurable by a 
command line switch, so if I know that the translations of the language xx 
has not been touched in master, but has been updated in branch, then changes 
translations should be overtaken of course.


Georg

Re: [LyX/master] Assure we use docstring.

[Georg Baum]

Kornel Benko wrote:

> Monolithic build on Cmake has still errors.  Don't know if it is worth the
> effort.

I fixed the one from your log. However, I do now get others for each unit 
test:


Linking CXX executable ../../../bin/check_convert
cd lyx-2-2-build/src/support/tests && /usr/bin/cmake -E cmake_link_script 
CMakeFiles/check_convert.dir/link.txt --verbose=1
c++   -Wall -Wunused-parameter --std=c++11 -fno-strict-aliasing  -Wall -
Wunused-parameter --std=c++11 -fno-strict-aliasing -O0 -g3 -D_DEBUG
CMakeFiles/check_convert.dir/check_convert.cpp.o 
CMakeFiles/check_convert.dir/dummy_functions.cpp.o 
CMakeFiles/check_convert.dir/boost.cpp.o  -o ../../../bin/check_convert -
rdynamic ../../../lib/libsupport.a ../../../lib/libboost_signals.a 
../../../lib/libboost_regex.a -lz -lmagic /usr/lib/x86_64-linux-
gnu/libQt5Core.so.5.3.2 /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5.3.2 
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5.3.2 
../../../lib/libsupport.a(_allinone_const.C.o): In function 
`applescript_execute_command':
lyx-2-2/src/support/AppleScriptProxy.cpp:30: undefined reference to 
`lyx::lyxaction'
lyx-2-2/src/support/AppleScriptProxy.cpp:30: undefined reference to 
`lyx::LyXAction::lookupFunc(std::string const&) const'
lyx-2-2/src/support/AppleScriptProxy.cpp:30: undefined reference to 
`lyx::FuncRequest::FuncRequest(lyx::FuncRequest const&, std::string const&, 
lyx::FuncRequest::Origin)' 
lyx-2-2/src/support/AppleScriptProxy.cpp:33: undefined reference to 
`lyx::theApp()'
collect2: error: ld returned 1 exit status
src/support/tests/CMakeFiles/check_convert.dir/build.make:146: recipe for 
target 'bin/check_convert' failed
make[2]: *** [bin/check_convert] Error 1
make[2]: Leaving directory 'lyx-2-2-build'
CMakeFiles/Makefile2:880: recipe for target 
'src/support/tests/CMakeFiles/check_convert.dir/all' failed
make[1]: *** [src/support/tests/CMakeFiles/check_convert.dir/all] Error 2
make[1]: Leaving directory 'lyx-2-2-build'
Makefile:130: recipe for target 'all' failed
make: *** [all] Error 2


This looks like a bug in the cmake setup to me. It should not build 
AppleScriptProxy.cpp on linux.


Georg

Re: [PATCH] Bug #9854 "Dataloss after git merge with change tracking"

[Georg Baum]

Guillaume Munch wrote:

> That would be a nice enhancement and would be a proper way to solve the
> problem of missing \author lines. Independently from this, the latest
> version of my patch solves every critical aspect of the problem (that
> can be blamed on LyX rather than version control), and it now keeps the
> behaviour on valid files unchanged. Somebody please let me commit it.

The patch is fine with me.


Georg

Re: [LyX/master] Cmake export tests: More tests to be reverted.

[Guenter Milde]

On 2015-11-16, Kornel Benko wrote:
> Am Montag, 16. November 2015 um 14:17:23, schrieb Scott Kostyshak 
> 
>> On Mon, Nov 16, 2015 at 06:51:08PM +0100, Kornel Benko wrote:
>> > commit b835c454ece6f1f8984664bf07974f4341bfd30c
>> > Author: Kornel Benko 
>> > Date:   Mon Nov 16 18:47:34 2015 +0100
>> > 
>> > ATM, the latex comments in user preamble are removed before
>> > export test.

>> This is just meant to be temporary right?

> Yes temporary, until we handle non-ascii characters in comments gracefully.

I don't think we need to remove LaTeX comments nor remove non-ASCII chars
from the documents. Also, I don't think this is worth fixing in LyX.
Remember, that this is just a warning that normally only affects
characters not encodable in the chosen "inputencoding". 

Problematic is only the case "XeTeX with TeX fonts", because here we need
inputenc==ASCII even if the setting in the doc is different.

For documents that explicitly set inputenc==ASCII (a use case would be
7-bit safe use/transfer of the exported LaTeX file) we can expect that
the author avoids non-ASCII characters in the user preamble (and fix
documents that ship with LyX with this setting).


> I tested also the suspended cases, but no improvement either.

Probably, there are other reasons for failure that "kick in" once the
first obstacle is removed. |: Remember, XeTeX with TeX fonts is fragile :|

> Commit or not commit, that’s the question ...

IMO, the test-script should somehow differentiate between LyX warning and
LyX error and not treat a warning as test failure. Maybe it already does?


Günter

Re: Bad Exception Crash in Master

[Georg Baum]

Richard Heck wrote:

> 
> Recipe:
> 
> 1. Open the User Guide.
> 2. Click somewhere in the main text.
> 3. Insert > Citation
> 4. Enter the search field and type "cap"
> 5. Hit search button.
> 
> Error: Software exception Detected
> 
> LyX has caught an exception, it will now attempt to save all unsaved
> documents and exit.
> 
> Exception: regex_error
> 
> This is on Fedora 22, gcc 5.1.1, with configuration as:
> --enable-build-type=dev.
> 
> The offending code is this assignment
> 
>  static const lyx::regex reg("[].|*?+(){}^$\\[]");
> 
> in escape_special_characters in GuiCitation.cpp. I would guess that this
> is a consequence of changes to the regex engine.

I can reproduce with gcc 5.1 in C++11-mode. This is most likely the same 
problem as http://www.lyx.org/trac/ticket/9799, since the test fails as well 
for the same compiler, so I guess it happens with gcc4 in C++11 mode as 
well. Nice to see that the unit test worked! Now we only need to learn not 
to ignore failing unit tests.

Some regex expert needs to find out whether the regex syntax we are using is 
only valid for boost::regex or for C++11 std::regex as well, and depending 
on the outcome we either need to change our regex, or file a gcc bug. Or 
maybe it is some multithreading issue? The 'static' rings some alarm 
bells...


Georg

Re: Bad Exception Crash in Master

[Richard Heck]

On 11/16/2015 02:14 PM, Scott Kostyshak wrote:

On Mon, Nov 16, 2015 at 01:55:30PM -0500, Richard Heck wrote:

Recipe:

1. Open the User Guide.
2. Click somewhere in the main text.
3. Insert > Citation
4. Enter the search field and type "cap"
5. Hit search button.

Error: Software exception Detected

LyX has caught an exception, it will now attempt to save all unsaved
documents and exit.

Exception: regex_error

This is on Fedora 22, gcc 5.1.1, with configuration as:
--enable-build-type=dev.

The offending code is this assignment

 static const lyx::regex reg("[].|*?+(){}^$\\[]");

in escape_special_characters in GuiCitation.cpp. I would guess that this is
a consequence of changes to the regex engine.

Richard


I cannot reproduce on Ubuntu 15.04, built with 5.6dev and the following CMake 
flags:

-DCMAKE_INSTALL_PREFIX=/usr/local/lyx-master \
-DLYX_DEBUG=ON -DLYX_RELEASE=OFF -DLYX_CPACK=ON \
-DLYX_PROGRAM_SUFFIX=ON -DLYX_LOCALVERSIONING=ON \
-DCPACK_BINARY_RPM:BOOL=OFF -DCPACK_BINARY_DEB:BOOL=ON \
-DCPACK_BINARY_NSIS:BOOL=OFF -DCPACK_BINARY_STGZ:BOOL=OFF \
-DCPACK_BINARY_TGZ:BOOL=OFF -DCPACK_BINARY_TBZ2:BOOL=OFF \
-DCPACK_BINARY_TZ:BOOL=OFF -DCPACK_SOURCE_TBZ2:BOOL=OFF \
-DCPACK_SOURCE_TGZ:BOOL=ON -DCPACK_SOURCE_TZ:BOOL=OFF \
-DCPACK_SOURCE_ZIP:BOOL=OFF -DLYX_EXTERNAL_BOOST=OFF \
-DLYX_HUNSPELL=ON -DLYX_ENCHANT=ON -DLYX_NLS=ON \
-DLYX_ENABLE_CXX11=ON \
-DLYX_ENABLE_URLTESTS=ON \
-DLYX_ENABLE_EXPORT_TESTS=ON \
-DLYX_USE_QT=QT5 \


The choice of the regex engine in regex.h seems dependent upon a variety 
of factors. I'm not sure which one I'm getting.


I'll check this on other machines.

Richard

Re: [PATCH] Bug #9854 "Dataloss after git merge with change tracking"

[Guillaume Munch]

Le 13/11/2015 10:56, Vincent van Ravesteijn a écrit :


I believe that 'git' can have custom merge filter/script for certain
file types. Maybe the community would like a special LyX-merger script
that can be used by the vcs to reduce merge errors as much as
possible.


That would be a nice enhancement and would be a proper way to solve the
problem of missing \author lines. Independently from this, the latest
version of my patch solves every critical aspect of the problem (that
can be blamed on LyX rather than version control), and it now keeps the
behaviour on valid files unchanged. Somebody please let me commit it.

(As for the issues with \tracking_change and \output_changes,
unfortunately such a script is not sufficient to turn a per-document
setting into a per-user-per-document setting, so we need (a) new LyX
setting(s) not to store certain user settings in the files in any case.)


Guillaume

Re: [PATCH] Bug #9854 "Dataloss after git merge with change tracking"

[Guillaume Munch]

Le 13/11/2015 03:18, Pavel Sanda a écrit :

Georg Baum wrote:

Unfortunately there is a good
reason for this behaviour: If LyX would not do that, then unused \author
lines could easily accumulate: If I accept all changes of my co-author, and
he never edits the file again, then his \author line will remain in the file
forever. This should be prevented IMHO.


Agreed. We have perhaps new item in the list of version control settings
we (/don't) keep track of as discussed in the other thread.



Thanks for the idea. While I like the idea of having a VCS compatibility
mode, I also would like that its purpose remains focused and is not used
to make LyX adopt two fundamentally different behaviours. For instance,
I do not see how arguments in favour of removing the author line would
not be appealing to VCS users too. The difference is the feature itself 
is not undesirable, we are only trying to mitigate its side-effects.



Guillaume

Re: Bad Exception Crash in Master

[Kornel Benko]

Am Montag, 16. November 2015 um 14:14:51, schrieb Scott Kostyshak 

> On Mon, Nov 16, 2015 at 01:55:30PM -0500, Richard Heck wrote:
> > 
> > Recipe:
> > 
> > 1. Open the User Guide.
> > 2. Click somewhere in the main text.
> > 3. Insert > Citation
> > 4. Enter the search field and type "cap"
> > 5. Hit search button.
> > 
> > Error: Software exception Detected
> > 
> > LyX has caught an exception, it will now attempt to save all unsaved
> > documents and exit.
> > 
> > Exception: regex_error
> > 
> > This is on Fedora 22, gcc 5.1.1, with configuration as:
> > --enable-build-type=dev.
> > 
> > The offending code is this assignment
> > 
> > static const lyx::regex reg("[].|*?+(){}^$\\[]");
> > 
> > in escape_special_characters in GuiCitation.cpp. I would guess that this is
> > a consequence of changes to the regex engine.
> > 
> > Richard
> > 
> 
> I cannot reproduce on Ubuntu 15.04, built with 5.6dev and the following
> CMake flags:
> 
> -DCMAKE_INSTALL_PREFIX=/usr/local/lyx-master \
> -DLYX_DEBUG=ON -DLYX_RELEASE=OFF -DLYX_CPACK=ON \
> -DLYX_PROGRAM_SUFFIX=ON -DLYX_LOCALVERSIONING=ON \
> -DCPACK_BINARY_RPM:BOOL=OFF -DCPACK_BINARY_DEB:BOOL=ON \
> -DCPACK_BINARY_NSIS:BOOL=OFF -DCPACK_BINARY_STGZ:BOOL=OFF \
> -DCPACK_BINARY_TGZ:BOOL=OFF -DCPACK_BINARY_TBZ2:BOOL=OFF \
> -DCPACK_BINARY_TZ:BOOL=OFF -DCPACK_SOURCE_TBZ2:BOOL=OFF \
> -DCPACK_SOURCE_TGZ:BOOL=ON -DCPACK_SOURCE_TZ:BOOL=OFF \
> -DCPACK_SOURCE_ZIP:BOOL=OFF -DLYX_EXTERNAL_BOOST=OFF \
> -DLYX_HUNSPELL=ON -DLYX_ENCHANT=ON -DLYX_NLS=ON \
> -DLYX_ENABLE_CXX11=ON \
> -DLYX_ENABLE_URLTESTS=ON \
> -DLYX_ENABLE_EXPORT_TESTS=ON \
> -DLYX_USE_QT=QT5 \

Same here with QT5.4. Same cmake settings. (No crash, search finds 'caption')

> Scott

Kornel

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

Re: [LyX/master] Cmake export tests: More tests to be reverted.

[Kornel Benko]

Am Montag, 16. November 2015 um 14:17:23, schrieb Scott Kostyshak 

> On Mon, Nov 16, 2015 at 06:51:08PM +0100, Kornel Benko wrote:
> > commit b835c454ece6f1f8984664bf07974f4341bfd30c
> > Author: Kornel Benko 
> > Date:   Mon Nov 16 18:47:34 2015 +0100
> >
> > Cmake export tests: More tests to be reverted.
> >
> > Again, thanks to Günter Milde.
> > ATM, the latex comments in user preamble are removed before export test.
> >
> > diff --git a/development/autotests/lyxStatus.pm 
> > b/development/autotests/lyxStatus.pm
> > index ef18c89..cfdeceb 100644
> > --- a/development/autotests/lyxStatus.pm
> > +++ b/development/autotests/lyxStatus.pm
> > @@ -242,6 +242,12 @@ sub checkForPreamble($)
> >   "search" => '^(photo|ecvpicture)(.*\{)(.*)\}',
> >   "fileidx" => 3,
> >   "result" => ["\\", "1", "2", "3", "}"]);
> > +#
> > +# Remove comments from preamble
> > +my $comments = newMatch("search" => '^([^%]*)([%]+)([^%]*)$',
> > +   "filetype" => "replace_only",
> > +   "result" => ["1", "2"]);
> > +#setMatching([$rElem, $comments]);
> >  setMatching([$rElem]);
> >  return(1);
>
> This is just meant to be temporary right?

Yes temporary, until we handle non-ascii characters in comments gracefully.

> Should we (I can volunteer)
> add a note explaining why we remove comments from preamble (this is only
> clear to me from following the thread on lyx-devel) and also put a FIXME
> to remove it once we fix the root causes?

OK.

But the committed change does not do anything useful. While I was testing, I 
left the 'correct'
statement 'setMatching([$rElem, $comments]);' commented.
(Correction attached.)

In the mean time I checked again, this time really with removing comments, but 
the tests did not
improve.

I tested also the suspended cases, but no improvement either.
Commit or not commit, that’s the question ...

> Scott

Korneldiff --git a/development/autotests/lyxStatus.pm b/development/autotests/lyxStatus.pm
index cfdeceb..f67451c 100644
--- a/development/autotests/lyxStatus.pm
+++ b/development/autotests/lyxStatus.pm
@@ -247,8 +247,7 @@ sub checkForPreamble($)
 my $comments = newMatch("search" => '^([^%]*)([%]+)([^%]*)$',
 	"filetype" => "replace_only",
 			"result" => ["1", "2"]);
-#setMatching([$rElem, $comments]);
-setMatching([$rElem]);
+setMatching([$rElem, $comments]);
 return(1);
   }
   return(0);


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

Re: [LyX/master] Cmake export tests: More tests to be reverted.

[Scott Kostyshak]

On Mon, Nov 16, 2015 at 06:51:08PM +0100, Kornel Benko wrote:
> commit b835c454ece6f1f8984664bf07974f4341bfd30c
> Author: Kornel Benko 
> Date:   Mon Nov 16 18:47:34 2015 +0100
> 
> Cmake export tests: More tests to be reverted.
> 
> Again, thanks to Günter Milde.
> ATM, the latex comments in user preamble are removed before export test.
> 
> diff --git a/development/autotests/lyxStatus.pm 
> b/development/autotests/lyxStatus.pm
> index ef18c89..cfdeceb 100644
> --- a/development/autotests/lyxStatus.pm
> +++ b/development/autotests/lyxStatus.pm
> @@ -242,6 +242,12 @@ sub checkForPreamble($)
> "search" => '^(photo|ecvpicture)(.*\{)(.*)\}',
> "fileidx" => 3,
> "result" => ["\\", "1", "2", "3", "}"]);
> +#
> +# Remove comments from preamble
> +my $comments = newMatch("search" => '^([^%]*)([%]+)([^%]*)$',
> + "filetype" => "replace_only",
> + "result" => ["1", "2"]);
> +#setMatching([$rElem, $comments]);
>  setMatching([$rElem]);
>  return(1);

This is just meant to be temporary right? Should we (I can volunteer)
add a note explaining why we remove comments from preamble (this is only
clear to me from following the thread on lyx-devel) and also put a FIXME
to remove it once we fix the root causes?

Scott


signature.asc
Description: PGP signature

Re: Bad Exception Crash in Master

[Scott Kostyshak]

On Mon, Nov 16, 2015 at 01:55:30PM -0500, Richard Heck wrote:
> 
> Recipe:
> 
> 1. Open the User Guide.
> 2. Click somewhere in the main text.
> 3. Insert > Citation
> 4. Enter the search field and type "cap"
> 5. Hit search button.
> 
> Error: Software exception Detected
> 
> LyX has caught an exception, it will now attempt to save all unsaved
> documents and exit.
> 
> Exception: regex_error
> 
> This is on Fedora 22, gcc 5.1.1, with configuration as:
> --enable-build-type=dev.
> 
> The offending code is this assignment
> 
> static const lyx::regex reg("[].|*?+(){}^$\\[]");
> 
> in escape_special_characters in GuiCitation.cpp. I would guess that this is
> a consequence of changes to the regex engine.
> 
> Richard
> 

I cannot reproduce on Ubuntu 15.04, built with 5.6dev and the following
CMake flags:

-DCMAKE_INSTALL_PREFIX=/usr/local/lyx-master \
-DLYX_DEBUG=ON -DLYX_RELEASE=OFF -DLYX_CPACK=ON \
-DLYX_PROGRAM_SUFFIX=ON -DLYX_LOCALVERSIONING=ON \
-DCPACK_BINARY_RPM:BOOL=OFF -DCPACK_BINARY_DEB:BOOL=ON \
-DCPACK_BINARY_NSIS:BOOL=OFF -DCPACK_BINARY_STGZ:BOOL=OFF \
-DCPACK_BINARY_TGZ:BOOL=OFF -DCPACK_BINARY_TBZ2:BOOL=OFF \
-DCPACK_BINARY_TZ:BOOL=OFF -DCPACK_SOURCE_TBZ2:BOOL=OFF \
-DCPACK_SOURCE_TGZ:BOOL=ON -DCPACK_SOURCE_TZ:BOOL=OFF \
-DCPACK_SOURCE_ZIP:BOOL=OFF -DLYX_EXTERNAL_BOOST=OFF \
-DLYX_HUNSPELL=ON -DLYX_ENCHANT=ON -DLYX_NLS=ON \
-DLYX_ENABLE_CXX11=ON \
-DLYX_ENABLE_URLTESTS=ON \
-DLYX_ENABLE_EXPORT_TESTS=ON \
-DLYX_USE_QT=QT5 \

Scott


signature.asc
Description: PGP signature

Bad Exception Crash in Master

[Richard Heck]

Recipe:

1. Open the User Guide.
2. Click somewhere in the main text.
3. Insert > Citation
4. Enter the search field and type "cap"
5. Hit search button.

Error: Software exception Detected

LyX has caught an exception, it will now attempt to save all unsaved 
documents and exit.


Exception: regex_error

This is on Fedora 22, gcc 5.1.1, with configuration as: 
--enable-build-type=dev.


The offending code is this assignment

static const lyx::regex reg("[].|*?+(){}^$\\[]");

in escape_special_characters in GuiCitation.cpp. I would guess that this 
is a consequence of changes to the regex engine.


Richard

Re: master branch is open again

[Richard Heck]

On 11/15/2015 05:27 PM, Scott Kostyshak wrote:


The following is not a critique (so please push because of Richard's positive 
feedback), but if you have time I am curious about the following:

strwidth_cache_(1 << 19)

How did you decide on 19? And why the trick of 1 << 19 instead of just the 
following?

strwidth_cache_(19)

I'm guessing this is a C++ trick I should know.


1 << 19 is a 1 with 19 zeros after it, in binary notation, so is 
equivalent to 2^19 = 512K but much faster to calculate. This trick is 
used extensively in debug.h.


Richard

Re: export test failures (was: Fix 480937a103708a651/lyxgit...)

[Kornel Benko]

Am Montag, 16. November 2015 um 15:53:04, schrieb Kornel Benko 
> Am Montag, 16. November 2015 um 13:28:10, schrieb Guenter Milde 
> 

...
> > But it seems the export test treats this waring as a failure.
> > Maybe this could be changed. Otherwise, invert the affected tests.
> >
>
> The other possibility (for tests) is removing comments from preamble.

I modified the tests to remove latex comments from the preamble.

With this modification and some more cases in 'revertedTests' we have now
107 failed testcases left.

> > Günter
>
Kornel469:export/doc/attic/it_Customization_pdf5_systemF
474:export/doc/attic/it_UserGuide_dvi3_systemF
479:export/doc/attic/it_UserGuide_pdf4_systemF
502:export/doc/attic/sk_UserGuide_pdf4_texF
737:export/doc/es/EmbeddedObjects_dvi3_texF
742:export/doc/es/EmbeddedObjects_pdf4_texF
743:export/doc/es/EmbeddedObjects_pdf4_systemF
744:export/doc/es/EmbeddedObjects_pdf5_texF
809:export/doc/es/UserGuide_dvi3_texF
814:export/doc/es/UserGuide_pdf4_texF
816:export/doc/es/UserGuide_pdf5_texF
817:export/doc/es/UserGuide_pdf5_systemF
850:export/doc/fr/Additional_pdf4_texF
853:export/doc/fr/Additional_pdf5_systemF
865:export/doc/fr/Customization_pdf5_systemF
899:export/doc/fr/EmbeddedObjects_pdf4_systemF
970:export/doc/fr/UserGuide_pdf4_texF
973:export/doc/fr/UserGuide_pdf5_systemF
1245:export/doc/nb/Intro_pdf5_systemF
1333:export/doc/ru/Intro_dvi3_texF
1338:export/doc/ru/Intro_pdf4_texF
1340:export/doc/ru/Intro_pdf5_texF
1345:export/doc/ru/Tutorial_dvi3_texF
1350:export/doc/ru/Tutorial_pdf4_texF
1352:export/doc/ru/Tutorial_pdf5_texF
1365:export/doc/sk/Intro_pdf5_systemF
1568:export/examples/PDF-comment_pdf5_texF
1609:export/examples/aas_sample_dvi3_texF
1610:export/examples/aas_sample_dvi3_systemF
1616:export/examples/aas_sample_pdf5_texF
1617:export/examples/aas_sample_pdf5_systemF
1621:export/examples/achemso_dvi3_texF
1628:export/examples/achemso_pdf5_texF
1726:export/examples/europeCV_dvi3_texF
1727:export/examples/europeCV_dvi3_systemF
1733:export/examples/europeCV_pdf5_texF
1734:export/examples/europeCV_pdf5_systemF
1808:export/examples/linguistics_dvi3_systemF
1813:export/examples/linguistics_pdf4_systemF
1815:export/examples/linguistics_pdf5_systemF
1840:export/examples/modernCV_dvi3_texF
1841:export/examples/modernCV_dvi3_systemF
1845:export/examples/modernCV_pdf4_texF
1846:export/examples/modernCV_pdf4_systemF
1847:export/examples/modernCV_pdf5_texF
1848:export/examples/modernCV_pdf5_systemF
1896:export/examples/seminar_pdf
1897:export/examples/seminar_pdf2
1898:export/examples/seminar_pdf3
1899:export/examples/seminar_pdf4_texF
1902:export/examples/seminar_pdf5_systemF
2548:export/examples/de/PDF-comment_dvi3_texF
2549:export/examples/de/PDF-comment_dvi3_systemF
2555:export/examples/de/PDF-comment_pdf5_texF
2725:export/examples/es/europeCV_dvi3_texF
2726:export/examples/es/europeCV_dvi3_systemF
2732:export/examples/es/europeCV_pdf5_texF
2733:export/examples/es/europeCV_pdf5_systemF
2742:export/examples/es/linguistics_pdf4_texF
2749:export/examples/es/modernCV_dvi3_texF
2750:export/examples/es/modernCV_dvi3_systemF
2756:export/examples/es/modernCV_pdf5_texF
2757:export/examples/es/modernCV_pdf5_systemF
2814:export/examples/fa/splash_dvi
2817:export/examples/fa/splash_pdf
2818:export/examples/fa/splash_pdf2
2819:export/examples/fa/splash_pdf3
2820:export/examples/fa/splash_pdf4_texF
2821:export/examples/fa/splash_pdf4_systemF
2871:export/examples/fr/Foils_pdf5_systemF
2899:export/examples/fr/PDF-comment_dvi3_texF
2900:export/examples/fr/PDF-comment_dvi3_systemF
2906:export/examples/fr/PDF-comment_pdf5_texF
2955:export/examples/fr/seminar_dvi
2958:export/examples/fr/seminar_pdf
2959:export/examples/fr/seminar_pdf2
2960:export/examples/fr/seminar_pdf3
2961:export/examples/fr/seminar_pdf4_texF
2964:export/examples/fr/seminar_pdf5_systemF
3072:export/examples/he/splash_pdf5_systemF
3247:export/examples/ko/splash_dvi3_texF
3252:export/examples/ko/splash_pdf4_texF
3254:export/examples/ko/splash_pdf5_texF
3343:export/examples/ru/splash_dvi3_texF
3348:export/examples/ru/splash_pdf4_texF
3350:export/examples/ru/splash_pdf5_texF
3439:export/examples/uk/splash_dvi3_texF
3444:export/examples/uk/splash_pdf4_texF
3446:export/examples/uk/splash_pdf5_texF
3500:export/templates/AGUTeX_dvi3_systemF
3505:export/templates/AGUTeX_pdf4_systemF
3507:export/templates/AGUTeX_pdf5_systemF
3559:export/templates/IEEEtran-Conference_dvi3_texF
3566:export/templates/IEEEtran-Conference_pdf5_texF
3583:export/templates/IEEEtran-TransMag_dvi3_texF
3590:export/templates/IEEEtran-TransMag_pdf5_texF
3630:export/templates/IUCr-article_dvi
3631:export/templates/IUCr-article_dvi3_texF
3632:export/templates/IUCr-article_dvi3_systemF
3633:export/templates/IUCr-article_pdf
3634:export/templates/IUCr-article_pdf2
3635:export/templates/IUCr-article_pdf3
3636:export/templates/IUCr-article_pdf4_texF
3638:export/templates/IUCr-article_pdf5_texF
3639:export/templates/IUCr-article_pdf5_systemF
3784:export/templates/es_beame

Re: We now include both png and svgz?

[Enrico Forestieri]

On Sun, Nov 15, 2015 at 05:31:28PM -0500, Scott Kostyshak wrote:
> 
> Is the only disadvantage of including the .pngs bloat in the sense that
> we are increasing the size of our tars and of the repos?

Yep.

> Or is there a
> concern that shipping .pngs could lead to different issues also (because
> our code could get confused)?

This should not be the case. What may happen is that someone places a
png in ~/.lyx/images, in which case this png will be picked up instead
of the svg version. But this is expected. The rule is that when LyX
searches for icons, the user directory is first looked up, then the
system directory and lastly the resource system. For each directory, a
svg image has precedence. Failing to find svgz or png images, what was
stored in the resource system is used.

This also reminds me that the resource system has to be updated for
storing the svgs instead of the pngs.

-- 
Enrico

Re: We now include both png and svgz?

[Enrico Forestieri]

On Sun, Nov 15, 2015 at 05:57:00PM +0100, Georg Baum wrote:

> Enrico Forestieri wrote:
> 
> > It is not intended to work that way. If the svgz image is there, it is
> > not expected that Qt is not able to show it. The double entry are there
> > only to assure that if there is no svgz then the png can be used instead.
> > In this way, you are able to override the default icons by placing your
> > own in the ~/.lyx/images directory, even if they are pngs.
> 
> OK, if it is assumed that qt can show svg images, then it does not make 
> sense to ship or own .pngs. If we want to stick with this, we should remove 
> the .pngs now and require qtsvg at configure time.

Sure, all pngs which have a svg counterpart can be removed as they will
never be used. BTW, isn't QtSvg already required at configure time?

> For me personally the svgs work fine both with qt 4.8 and 5.3, so I would 
> not have a problem with that. I only thought there might by exotic systems 
> where it does not work, and therefore I thought it might be a good idea to 
> ship both png and svg for one release, instead of switching from only png 
> directly to only svg.

I also use "exotic" systems that are not officially supported by Qt
(which doesn't even compile cleanly without patching the sources) and
never had a problem with svgs. The only problem that I can foresee is
that Qt is built without zlib support (and this has to be done
also deliberately excluding the zlib version that Qt would include in
the absence of a system version), in which case compressed svgs cannot
be read, or that Qt is statically built, in which case the qsvg plugin
must be explicitly included when compiling. Note that this is not the
QtSvg library, but the plugin in the plugins/imageformats directory.

-- 
Enrico

Re: export test failures (was: Fix 480937a103708a651/lyxgit...)

[Kornel Benko]

Am Montag, 16. November 2015 um 13:28:10, schrieb Guenter Milde 

> IMO, LyX should just leave ERT and user preamble to the user. However, this
> is not agreed by others, see e.g. http://www.lyx.org/trac/ticket/9012
> (and the follow-up problems with Cyrillic in listings etc).
> 
> Similarily, the user preamble is checked for encoding problems (since
> 4c0e99ac/lyxgit). As only a warning is output, this does not prevent
> compilation (if the user is smarter than LyX (e.g. if the offending
> character is in a comment). Special casing for comments would make the
> encoding-check code overly complicated.  
> 
> But it seems the export test treats this waring as a failure. 
> Maybe this could be changed. Otherwise, invert the affected tests.
> 

The other possibility (for tests) is removing comments from preamble.

> 
> 
> >> > 737:export/doc/es/EmbeddedObjects_dvi3_texF
> >> > 744:export/doc/es/EmbeddedObjects_pdf5_texF
> >> > 743:export/doc/es/EmbeddedObjects_pdf4_systemF
> 
> ...
> 
> Actually, for me even doc/EmbeddedObjects.lyx fails to
> compile, and even for default output.

Here the test passes.

> The error is
> 
>   (/usr/share/texlive/texmf-dist/tex/latex/listings/lstlang1.sty
>   File: lstlang1.sty 2015/06/04 1.6 listings language file
>   )
>   ! Undefined control sequence.
>   \lst@label ->\2
>   
>   l.6110 ...ption={\1\3},label={\2},language=Python]
> 
> I don't know whether this is a LyX- or LaTeX problem.
> 
> My TeXLive is 2015 and listings.sty is
> 
>   \def\filedate{2015/06/04}
>   \def\fileversion{1.6}

I have the same date and version.

> Günter

Kornel

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

Re: [LyX/master] Assure we use docstring.

[Jürgen Spitzmüller]

2015-11-16 10:43 GMT+01:00 Kornel Benko:

> Monolithic build on Cmake has still errors.  Don't know if it is worth the
> effort.
>

I think it is (also the warnings should be considered).

However, these are outside my scope of knowledge.

Jürgen


>
> Kornel

export test failures (was: Fix 480937a103708a651/lyxgit...)

[Guenter Milde]

Dear Kornel,

thanks for the fast response and implementing.

On 2015-11-16, Kornel Benko wrote:
> Am Montag, 16. November 2015 um 00:30:08, schrieb Guenter Milde
>> On 2015-11-12, Kornel Benko wrote:

...

>> > 550:export/doc/de/Additional_pdf4_texF
>> > 565:export/doc/de/Customization_pdf5_systemF
>> > 599:export/doc/de/EmbeddedObjects_pdf4_systemF
>> > 670:export/doc/de/UserGuide_pdf4_texF

>> Non-ASCII characters in a comment in the user-preamble.
>> Warning with inputenc == ASCII or XeTeX


Wrong reson (and hence wrong comment in 5060b5b76eb88a98/lyxgit)

+# Non-ASCII characters in a comment in the user-preamble.
+# Warning with inputenc == ASCII or XeTeX
+export/doc/de/(Additional|UserGuide)_pdf4_texF
+export/doc/de/(Customization_pdf5|EmbeddedObjects_pdf4)_systemF

Export with "systemF" uses UTF8, a non-ASCII char in the preamble is no
problem here.  
We need to determine the correct reason for failure (most probably
incompatible packages, maybe also loading of lmodern.sty in the user
preamble) or state that we don't know it.



>> > 694:export/doc/es/Additional_pdf4_texF

>> ERT (tabular) with non-ASCII chars, fails with inputenc == ASCII and XeTeX

>> -> convert ERT to LyX, invert, or ignore.

I'd say invert for now (with a TODO or FIXME in the comment).


Making documents that currently require inverting with non-standard
export more robust should be postponed until the next release is out.  

We want to avoid hacks or controversial changes just to please the
current test setup. This requires careful consideration, so that we do
what is right for the documentation/examples. It may also mean to
invert/ignore some tests on a permantent basis.


>> > 709:export/doc/es/Customization_pdf5_systemF

>> cannot reproduce

> I get plenty of
>   ! LaTeX Error: \begin{otherlanguage} on input line 1901 ended by 
> \end{description}.
>   ! LaTeX Error: \begin{english} on input line 1900 ended by 
> \end{description}.

Sorry, I tried export with texF. Now I see: 

The common reasons:

a) loading lmodern.sty in the preamble 

   The Quick hack is 
   
   +\@ifpackageloaded{fontspec}{}{
\usepackage{lmodern}
   +}
   
   This could be done for all documents loading lmodern.sty in the preamble.
   But a proper solution to the documentation font problem is still not found!

b) babel-specific preamble code:

\@ifpackageloaded{babel}{
 % increase link area for cross-references and autoname them,
 \AtBeginDocument{\renewcommand{\ref}[1]{\mbox{\autoref{#1
 \addto\extrasspanish{%
\renewcommand*{\equationautorefname}[1]{}%
...

   The fix for the French documents is better (direct change of 
   the "auto strings") for document using just one language.
   
c) Seems to be a case of the polyglossia + language-nesting problem.

   The same happens with XeTeX (export/doc/es/Customization_pdf4_systemF)

   -> invert   
  







>> > 550:export/doc/de/Additional_pdf4_texF
>> > 670:export/doc/de/UserGuide_pdf4_texF
...
>> > 742:export/doc/es/EmbeddedObjects_pdf4_texF

>> non-ASCII character in user preamble comment


> Should we handle comments in the preamble?


IMO, LyX should just leave ERT and user preamble to the user. However, this
is not agreed by others, see e.g. http://www.lyx.org/trac/ticket/9012
(and the follow-up problems with Cyrillic in listings etc).

Similarily, the user preamble is checked for encoding problems (since
4c0e99ac/lyxgit). As only a warning is output, this does not prevent
compilation (if the user is smarter than LyX (e.g. if the offending
character is in a comment). Special casing for comments would make the
encoding-check code overly complicated.  

But it seems the export test treats this waring as a failure. 
Maybe this could be changed. Otherwise, invert the affected tests.




>> > 737:export/doc/es/EmbeddedObjects_dvi3_texF
>> > 744:export/doc/es/EmbeddedObjects_pdf5_texF
>> > 743:export/doc/es/EmbeddedObjects_pdf4_systemF
...

Actually, for me even doc/EmbeddedObjects.lyx fails to
compile, and even for default output.

The error is


  (/usr/share/texlive/texmf-dist/tex/latex/listings/lstlang1.sty
  File: lstlang1.sty 2015/06/04 1.6 listings language file
  )
  ! Undefined control sequence.
  \lst@label ->\2
 
  l.6110 ...ption={\1\3},label={\2},language=Python]

I don't know whether this is a LyX- or LaTeX problem.

My TeXLive is 2015 and listings.sty is
  \def\filedate{2015/06/04}
  \def\fileversion{1.6}



Günter

Re: Basic test of alpha1 tar

[Jean-Marc Lasgouttes]

Le 15/11/2015 03:14, Pavel Sanda a écrit :

Pavel Sanda wrote:

non harmful, but warnings:


Apart from that I was able to build and run it on gentoo system.

Sadly, moving cursor in paragraph is considerably slower than
in my current 2.0 build :(



Could it be related to the following ticket?
http://www.lyx.org/trac/ticket/9783

JMarc

Re: Packagers, please upload binaries for 2.2.0alpha1

[Liviu Andronic]

On Mon, Nov 16, 2015 at 12:46 PM, Guillaume Munch  wrote:
> Le 16/11/2015 11:33, Liviu Andronic a écrit :
>>
>> The Ubuntu packages are built against Qt 4.8. Scott, is it a good or a
>> bad idea to build against Qt 5.4.1/5.4.2, where available?
>>
>
> With Qt 5.4.1 in Ubuntu I am affected by
>  and
> . On the other hand,
>  is solved with Qt 5.4.1. But the
> latter has workarounds.
>
So overall not a very good idea. Thanks,
Liviu


>
> Guillaume
>



-- 
Do you think you know what math is?
http://www.ideasroadshow.com/issues/ian-stewart-2013-08-02
Or what it means to be intelligent?
http://www.ideasroadshow.com/issues/john-duncan-2013-08-30
Think again:
http://www.ideasroadshow.com/library

Re: Packagers, please upload binaries for 2.2.0alpha1

[Guillaume Munch]

Le 16/11/2015 11:33, Liviu Andronic a écrit :

The Ubuntu packages are built against Qt 4.8. Scott, is it a good or a
bad idea to build against Qt 5.4.1/5.4.2, where available?



With Qt 5.4.1 in Ubuntu I am affected by 
 and 
. On the other hand, 
 is solved with Qt 5.4.1. But the 
latter has workarounds.



Guillaume

Re: Packagers, please upload binaries for 2.2.0alpha1

[Liviu Andronic]

On Sat, Nov 14, 2015 at 8:34 PM, Scott Kostyshak  wrote:
> The tar balls are here:
>
> ftp://ftp.lyx.org/pub/lyx/devel/lyx-2.2/lyx-2.2.0alpha1/
>
I've uploaded Ubuntu packages to the development PPA:
https://launchpad.net/~lyx-devel/+archive/ubuntu/daily

Testers should install the lyx2.2pre package, and this installation is
independent of the stable LyX installation that you might have.


> I would like to make the announcement for the alpha release on Monday.
> From what I understand in the past it is OK if the announcement comes
> before binaries are uploaded (please let me know if I am incorrect).
>
> As for which version of Qt to use, I propose that each packager decides
> what is the best choice for the platform. Qt 5.6 Beta has been delayed
> again until 19th November 2015. I did not bother looking at the reason
> this time.
>
The Ubuntu packages are built against Qt 4.8. Scott, is it a good or a
bad idea to build against Qt 5.4.1/5.4.2, where available?

Liviu


> Thanks,
>
> Scott



-- 
Do you think you know what math is?
http://www.ideasroadshow.com/issues/ian-stewart-2013-08-02
Or what it means to be intelligent?
http://www.ideasroadshow.com/issues/john-duncan-2013-08-30
Think again:
http://www.ideasroadshow.com/library

Re: [LyX/master] Fix 480937a103708a651/lyxgit. See also #9740.

[Kornel Benko]

Am Montag, 16. November 2015 um 00:30:08, schrieb Guenter Milde 

> On 2015-11-12, Kornel Benko wrote:
> 
> > The actual failed export tests.
> > 117 failed, that is 9 less than previously. We are advancing. 
> 
> 
> > 309:export/doc/EmbeddedObjects_pdf4_systemF
> 
> Example of "high bit" chars in listings. Fails with XeTeX due ot 
> limiation to ASCII (no LICR in listings possible). Gives correct warning.
> -> invert or ignore.

Done, inverted

> > 351:export/doc/LaTeXConfig_dvi3_texF
> > 358:export/doc/LaTeXConfig_pdf5_texF
>
> This generated has inputenc = "default" (i.e. language default encoding
> without inputenc calls). Fails for non-ASCII character (Komödie) with LuaTeX.
> 
> Correct the template to include \usepackage[latin9]{inputenc}.

Done

> > 406:export/doc/UserGuide_pdf4_texF
> 
> Non-ASCII char in verbatim environment.
> Fails with ASCII (and hence also with XeTeX).
> 
> -> invert or ignore.

Done, inverted ( ==> suspended)

> > 550:export/doc/de/Additional_pdf4_texF
> > 565:export/doc/de/Customization_pdf5_systemF
> > 599:export/doc/de/EmbeddedObjects_pdf4_systemF
> > 670:export/doc/de/UserGuide_pdf4_texF
> 
> Non-ASCII characters in a comment in the user-preamble.
> Warning with inputenc == ASCII or XeTeX
> 
> -> change preamble, invert, or ignore.
> 

Done, inverted

> > 694:export/doc/es/Additional_pdf4_texF
> 
> ERT (tabular) with non-ASCII chars, fails with inputenc == ASCII and XeTeX
> 
> -> convert ERT to LyX, invert, or ignore.
> 
> > 709:export/doc/es/Customization_pdf5_systemF
> 
> cannot reproduce

I get plenty of
! LaTeX Error: \begin{otherlanguage} on input line 1901 ended by 
\end{description}.
! LaTeX Error: \begin{english} on input line 1900 ended by 
\end{description}.

> > 737:export/doc/es/EmbeddedObjects_dvi3_texF
> > 742:export/doc/es/EmbeddedObjects_pdf4_texF
> > 744:export/doc/es/EmbeddedObjects_pdf5_texF
> 
> non-ASCII character in user preamble comment
> undefined control sequence in listings

Should we handle comments in the preamble?

> > 743:export/doc/es/EmbeddedObjects_pdf4_systemF
> 
> \usepackage{lmodern} in preamble.
> 
> 
> Enough for today,
> 
> 
> Günter

Kornel

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

Re: Basic test of alpha1 tar

[Stephan Witt]

Am 14.11.2015 um 20:24 schrieb Scott Kostyshak :

> Dear all,
> 
> If you have time, please download the LyX 2.2.0alpha1 tar and test that
> it compiles/installs as expected. It is located here:
> 
> ftp://ftp.lyx.org/pub/lyx/devel/lyx-2.2/lyx-2.2.0alpha1/
> 
> Also if you can, please check that it verifies correctly. This is my
> first time signing a tar ball.

The signature is ok. The build on Mac OS X works.

I've uploaded the result here:

https://dl.dropboxusercontent.com/u/27842660/LyX-2.2.0alpha1%2Bqt5-x86_64-cocoa.dmg
https://dl.dropboxusercontent.com/u/27842660/LyX-2.2.0alpha1%2Bqt5-x86_64-cocoa.dmg.sig

I've used Qt 5.5.1 to build it.

Stephan

Re: [LyX/master] Assure we use docstring.

[Kornel Benko]

Am Montag, 16. November 2015 um 08:22:58, schrieb Juergen Spitzmueller 

> commit 78c706e02d065301d895af5551937638921a0f97
> Author: Juergen Spitzmueller 
> Date:   Mon Nov 16 08:21:53 2015 +0100
>
> Assure we use docstring.
>
> Cures another monolithic build error with CMake.
>

Monolithic build on Cmake has still errors.  Don't know if it is worth the 
effort.

Kornel

signature.asc
Description: This is a digitally signed message part.
make[2]: Entering directory `/usr/BUILD/BuildLyxGitQtlocal'
[ 87%] Building CXX object src/CMakeFiles/lyx2.2.dir/_allinone_const.C.o
cd /usr/BUILD/BuildLyxGitQtlocal/src && /usr/bin/c++   
-DBOOST_SIGNALS_NO_DEPRECATION_WARNING=1 -DQT_CONCURRENT_LIB -DQT_CORE_LIB 
-DQT_GUI_LIB -DQT_SVG_LIB -DQT_WIDGETS_LIB -I/usr/BUILD/BuildLyxGitQtlocal 
-I/usr/src/lyx/lyx-git/src -I/usr/include/enchant -I/usr/src/lyx/lyx-git/boost 
-I/usr/BUILD/BuildLyxGitQtlocal/src -isystem /usr/include/qt5 -isystem 
/usr/include/qt5/QtCore -isystem 
/usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++-64 -isystem 
/usr/include/qt5/QtGui -isystem /usr/include/qt5/QtWidgets -isystem 
/usr/include/qt5/QtConcurrent -isystem /usr/include/qt5/QtSvg  -Wall 
-Wunused-parameter --std=c++11 -fno-strict-aliasing  -Wall -Wunused-parameter 
--std=c++11 -fno-strict-aliasing -O0 -g3 -D_DEBUG -fPIE   
-DBOOST_USER_CONFIG="" -o CMakeFiles/lyx2.2.dir/_allinone_const.C.o 
-c /usr/BUILD/BuildLyxGitQtlocal/src/_allinone_const.C
In file included from /usr/BUILD/BuildLyxGitQtlocal/src/_allinone_const.C:43:0:
/usr/src/lyx/lyx-git/src/BufferView.cpp:228:20: warning: 
‘lyx::BufferView::Private’ has a field 
‘lyx::BufferView::Private::update_strategy_’ whose type uses the anonymous 
namespace [enabled by default]
 struct BufferView::Private
^
In file included from /usr/src/lyx/lyx-git/src/LyX.cpp:59:0,
 from /usr/BUILD/BuildLyxGitQtlocal/src/_allinone_const.C:8:
/usr/src/lyx/lyx-git/src/Compare.cpp: In constructor 
‘lyx::Compare::Impl::Impl(const lyx::Compare&)’:
/usr/src/lyx/lyx-git/src/support/gettext.h:66:19: error: anachronistic 
old-style base class initializer [-fpermissive]
 #  define N_(str) (str)  // for detecting static strings
   ^
/usr/src/lyx/lyx-git/src/Compare.cpp:231:20: note: in expansion of macro ‘N_’
   : abort_(false), N_(0), M_(0), offset_reverse_diagonal_(0),
^
In file included from /usr/BUILD/BuildLyxGitQtlocal/src/_allinone_const.C:158:0:
/usr/src/lyx/lyx-git/src/Compare.cpp:231:18: error: unnamed initializer for 
‘lyx::Compare::Impl’, which has no base classes
   : abort_(false), N_(0), M_(0), offset_reverse_diagonal_(0),
  ^
In file included from /usr/BUILD/BuildLyxGitQtlocal/src/_allinone_const.C:203:0:
/usr/src/lyx/lyx-git/src/ConverterCache.cpp: At global scope:
/usr/src/lyx/lyx-git/src/ConverterCache.cpp:86:7: warning: ‘lyx::FormatCache’ 
has a field ‘lyx::FormatCache::cache’ whose type uses the anonymous namespace 
[enabled by default]
 class FormatCache {
   ^
In file included from /usr/BUILD/BuildLyxGitQtlocal/src/_allinone_const.C:338:0:
/usr/src/lyx/lyx-git/src/Text.cpp: In member function ‘void 
lyx::Text::readParToken(lyx::Paragraph&, lyx::Lexer&, const string&, 
lyx::Font&, lyx::Change&, lyx::ErrorList&)’:
/usr/src/lyx/lyx-git/src/Text.cpp:490:19: warning: ‘auto_ptr’ is deprecated 
(declared at /usr/include/c++/4.8/backward/auto_ptr.h:87) 
[-Wdeprecated-declarations]
   auto_ptr inset;
   ^
/usr/src/lyx/lyx-git/src/Text.cpp:500:19: warning: ‘auto_ptr’ is deprecated 
(declared at /usr/include/c++/4.8/backward/auto_ptr.h:87) 
[-Wdeprecated-declarations]
   auto_ptr inset;
   ^
/usr/src/lyx/lyx-git/src/Text.cpp:526:24: warning: ‘auto_ptr’ is deprecated 
(declared at /usr/include/c++/4.8/backward/auto_ptr.h:87) 
[-Wdeprecated-declarations]
   auto_ptr inset(new InsetTabular(buf));
^
In file included from /usr/BUILD/BuildLyxGitQtlocal/src/_allinone_const.C:483:0:
/usr/src/lyx/lyx-git/src/Buffer.cpp: In member function 
‘std::auto_ptr lyx::Buffer::getSourceCode(lyx::odocstream&, const 
string&, lyx::pit_type, lyx::pit_type, lyx::Buffer::OutputWhat, bool) const’:
/usr/src/lyx/lyx-git/src/Buffer.cpp:3636:25: warning: ‘auto_ptr’ is deprecated 
(declared at /usr/include/c++/4.8/backward/auto_ptr.h:87) 
[-Wdeprecated-declarations]
  auto_ptr texrow(NULL);
 ^
make[2]: *** [src/CMakeFiles/lyx2.2.dir/_allinone_const.C.o] Chyba 1
make[2]: Leaving directory `/usr/BUILD/BuildLyxGitQtlocal'
make[1]: *** [src/CMakeFiles/lyx2.2.dir/all] Chyba 2
make[1]: Leaving directory `/usr/BUILD/BuildLyxGitQtlocal'

Re: [patch] RFC: better submenu for tables

[Kornel Benko]

Am Sonntag, 15. November 2015 um 14:30:05, schrieb Jürgen Spitzmüller 

> Am Sonntag 15 November 2015, 14:10:07 schrieb Kornel Benko:
> > Am Sonntag, 15. November 2015 um 13:36:50, schrieb Jürgen Spitzmüller
> > 
> > > Am Freitag 13 November 2015, 13:15:05 schrieb Kornel Benko:
> > > > What about multipage table?
> > > 
> > > Yes, why not.
> > 
> > There are 5 strings which would need new wordings:
> > 1 "&Use long table"
> > 2 "Horizontal alignment of the longtable"
> > 3 "Longtable alignment"
> > 4 "Breakable Table|g"
> > 5 "A spreadsheet made with Gnumeric, LibreOffice, OpenOffice or 
> > Excel.\n"
> > "It imports as a long table, so any length\n"
> > "is ok. Excessive width could be a problem.\n"
> > "The gnumeric software is necessary for conversion,\n"
> > "both for gnumeric and excel files.\n"
> > 
> > May I adapt them?
> 
> Fine with me.
> 
> I think the correct spelling would be "multi-page table".
> 
> Jürgen
> 

Done at 5c79673.

Kornel

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