date:20160222

This is the beta2 tar.gz. The versions are whatever Scott used Actually I 
think it was AC 2.69 and am 1.14.1.

JMarc

Le 23 février 2016 02:23:09 GMT+01:00, Pavel Sanda  a écrit :
>Jean-Marc Lasgouttes wrote:
>> Le 18/02/2016 04:45, Scott Kostyshak a écrit :
>>> make distcheck fails for some people and passes for others. It fails
>for
>>> me. I think it passes for Pavel now that Georg's fix was committed.
>>>
>>> We have not gotten to the root of why make distcheck fails for some.
>See
>>> this thread for previous efforts:
>>>
>https://www.mail-archive.com/search?l=mid=20151125075443.GA7491%40cotopaxi.hsd1.dc.comcast.net
>>
>> I downloaded beta2 and ran:
>> ./configure
>> make distcheck
>>
>> It worked without problem. Note that I did not use any -jX option, in
>case 
>> they create dependencies problems.
>
>We need to know your
>automake --version 
>   
>autoconf --version 
>
>Pavel

Re: blockers for 2.2.0?

Scott Kostyshak wrote:
> what issues others view as critical. Which issues do you view as
> blockers?

Do we track the issue recently reported by Jerry?
Signalized more general problem to me.

Pavel

Re: [patch] support Bosnian, Macedonian, Piedmontese and Romansh

Guillaume Munch wrote:
> I would not be shocked if an exception was made. Uwe's point is that it
> is low risk/high reward and that being delayed until 2.3 is quite
> significant. I do not remember seeing another patch in this situation.

String changes break finalized translations or harass workflow for people
who work on them meanwhile... P

Re: [PATCH] microtype

Guenter Milde wrote:
> I got the same impression after some tests with a *.tex file here.
> This is also what the documentation tells: it works for all three of
> pdflatex, xelatex, and lualatex but only pdflatex supports all features.
> There is no error with "plain" latex (DVI, PS, PDF (ps2pdf), PDF (dvipdfm)
> but no effect either.
> 
> A tooltip should hint to limited support (linking to the documentation)

Thanks for the report, I will add some hint.

> > People who use custom parameters are on their own. But is there an
> > advantage of letting users enter custom params via a line edit, instead
> > of letting them write it by hand in the preamble?  It does not seem to
> > me that the GUI helps here. Or do you have further plans for this
> > feature?

I do not have plan, just got some (unf.) private response to this thread.
I will ask on users list whether people tend to use some params.

> > Also, obviating the line edit, could the same not be accomplished by a
> > module?

If we dont need the param line, module is cheaper. .. except it's already coded 
;)

> > I haven't heard that microtype must be before font settings. My
> > experience is consistent with https://tex.stackexchange.com/a/162436
> 
> Maybe this was a previous limitation.
> Also, this should be in the documentation otherwise...

Again, thanks for feedback. Pavel

Re: Is "make distcheck" failure a blocker?

Jean-Marc Lasgouttes wrote:
> Le 18/02/2016 04:45, Scott Kostyshak a écrit :
>> make distcheck fails for some people and passes for others. It fails for
>> me. I think it passes for Pavel now that Georg's fix was committed.
>>
>> We have not gotten to the root of why make distcheck fails for some. See
>> this thread for previous efforts:
>> https://www.mail-archive.com/search?l=mid=20151125075443.GA7491%40cotopaxi.hsd1.dc.comcast.net
>
> I downloaded beta2 and ran:
> ./configure
> make distcheck
>
> It worked without problem. Note that I did not use any -jX option, in case 
> they create dependencies problems.

We need to know your
automake --version  

   
autoconf --version  

Pavel

Re: [patch] support Bosnian, Macedonian, Piedmontese and Romansh

2016-02-22 Thread Uwe Stöhr

Am 22.02.2016 um 20:23 schrieb Georg Baum:

Le 21/02/2016 20:52, Scott Kostyshak a écrit :

On Sun, Feb 21, 2016 at 06:06:14PM +0100, Uwe Stöhr wrote:

I also don't see a reason why this cannot be done now since otherwise
users of than languages would have to wait 2 more years until LyX 2.3.

Every LyX release in the past few years was further delayed by last-minute
requests like this one. If we stop these last-minute changes, and improve
the test coverage we can speed up the release process a lot.

Time is not important here. The question is if adding a feature makes 
sense. This change is of low risk but opens LyX for a wider audience. 
Ergo a big plus for the marketing. There is also nothing specially to 
test and nothing that can be broken. (all are LTR languages with either 
Latin or Cyrillic script). So the question is not the time a patch is 
sent but its benefit.
I cannot speak any of the languages of my patch so it would not help me 
personally. I see the obvious benefit and not yet a technical reason 
against this. As my goal is to spread LyX it makes sense to support as 
many languages as possible.

That LyX 2.2 is delayed because Qt 5.6 is still not our and I cannot 
perform my tests annoy me a lot. But that is life and we should use this 
unwanted extra time.

Yes. For every new language we need a native speaker to verify that the
result is correct. For example, support for urdu was added at
http://www.lyx.org/trac/changeset/7eca5d94/lyxgit, and later it turned out
that it was completely unusable, so that it was removed again at
http://www.lyx.org/trac/changeset/cf9c7ad108fbc/lyxgit.

You forget the other languages added by 
http://www.lyx.org/trac/changeset/7eca5d94/lyxgit that work fine.
Take for example Hindi. This language was enabled with this patch and 
people are using this (2 downloads a week of the dictionary for LyX). So 
do you reapply prefer to wait until a native speaker gives his OK? Then 
LyX would still not support Hindi. At first we need to attract users. If 
e.g. a Macedonian user find a problem he will report it. If we don't 
provide language support, we will most probably never have a Macedonian 
LyX user.
Just for interest Bosnian is almost the same as Serbocroatian (the 
language discussion in BiH is quite ridiculous, but OK as long as they 
have peace, every party gets his "language".)

That Urdu and Syriac did not work well has to do with RTL support. Btw., 
JMarc, what is the status of this, Could Urdu now be supported?

> Exactly. Such exceptions punish those who play by the rules and 
reward those

> who ignore the rules.

You are always arguing with rules and I did not even ask for an 
exception. Just focus on the pro and cons.

> This does not mean that I don't like the support for the new 
languages. It is a very good thing to have, just not right now.

So we are waiting another e.g. 2 years because a rule is more important? 
That reminds me of my Cuba trip where they have the rule that there are 
only 4 buses a day connecting the 2 biggest cities of the country. No 
matter if there are suddenly more people than for 4 buses, rule is rule 
(planned economy). Not nice if you are affected! In the rest of the 
world they would just organize some extra buses. They would be happy to 
get more money and you would be happy about the service. As you can see 
rules are a nice framework but one has to makes decisions for every 
certain cases despite the rules.

regards Uwe

Re: [LyX/master] Spanish modernCV.lyx: update the file and make it compilable

2016-02-22 Thread Kornel Benko

Am Montag, 22. Februar 2016 um 23:20:21, schrieb Kornel Benko 
> > Did you try? It fails here. (Cf. lyx test file below.)
> > 
> 
> I tried the lyx file you sent. Luatex has no problem with deactivated 1st 
> branch.
> I.e. if '${a}_{\mbox{a}}$' is active.
> 

Outch. I had overseen '\text' in the second branch. You are right.

Kornel

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

Re: [LyX/master] Spanish modernCV.lyx: update the file and make it compilable

2016-02-22 Thread Kornel Benko

Am Montag, 22. Februar 2016 um 21:17:44, schrieb Guenter Milde 

> On 2016-02-21, Kornel Benko wrote:
> > Am Sonntag, 21. Februar 2016 um 16:07:20, schrieb Guenter Milde 
> > 
> >> On 2016-02-21, Kornel Benko wrote:
> 
> >> >> I investigated a little. Trying to compile manually (export as luatex,
> >> >> use bibtex, use lualatex) I found what is causing lualatex/bibtex to
> >> >> misbehave.
> 
> >> >> 1.) bibtex does not like the string 'jacsat' (biblioExample.bib:61,
> >> >> entry Arduengo1994). Enclosing it in '{}' cures it. E.g. 'journal =
> >> >> {jacsat},'.
> 
> >> This is new. It worked fine here.
> 
> > You can it see only if manually calling bibtex. It is a warning
> > otherwise which lyx and luatex ignore.
> 
> However, did you also test that putting it into {} does not change the output?
> Is it the same for 8-bit tex vs. luatex and for {jacsat} vs. jacsat ?
> 
> I assume this is supposed to be a pre-defined string but the definition may
> be missing...
> 
> >> >> 2.) lualatex does not like the construct (biblioExample.bib:36, entry: 
> >> >> Eisenstein2005)
> >> >> $\mbox{IrH}_{\mbox{5}}(\mbox{PPh}_{\mbox{3}})_{\mbox{2}}$
> >> >> in title. Especially the last '_' is causing trouble. So for instance
> >> >> $\mbox{IrH}_{\mbox{5}}(\mbox{PPh}_{\mbox{3}}){\mbox{2}}$
> >> >> is OK.
> 
> >> This resembles the description in suspiciousTests (the result of my
> >> experiments):
> 
> >> # LuaTeX fails for an \mbox in an index, e.g. $a_{\mbox{a}}$.
> >> # This construct appears in the included bib file biblioExample.bib in
> >> # the entry Eisenstein2005. Error message is
> >> #   Missing character: There is no (U+6035) in font rm-lmr12!
> >> # (with system fonts: 602D and 6039)
> >> export/examples/(|es/)(europe|modern)CV_(dvi3|pdf5)_(texF|systemF)
> 
> > Ah, yes. Did not think of looking at the description.
> > But, using your example,  ${a}_{\mbox{a}}$ would work.
> 
> Did you try? It fails here. (Cf. lyx test file below.)
> 

I tried the lyx file you sent. Luatex has no problem with deactivated 1st 
branch.
I.e. if '${a}_{\mbox{a}}$' is active.

> >> >> So, what to do with this biblio entry?
> 
> >> Mailing the patch to the upstream author?
> 
> >> Reporting the "mbox in index" problem to the LuaTeX authors?
> 
> > This is not about \mbox I think. 
> 
> > This patch fixes the luatex testcase for me. (But not xelatex)
> 
> There is still the mystery, why xelatex works here but not at your site.

Sure.

> The error report (missing character with some "strange" Unicode point) seems
> to point to a similar problem.

Unfortunately not similar. In case of xetex there is a problem to display the 
glyph used for phone type.
Changing the phone type to e.g. 'mobile' or 'fixed' ==> no problem with xelatex.
Luatex has no problems here.

> Günter

Kornel



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

Re: [PATCH] microtype

2016-02-22 Thread Guenter Milde

On 2016-02-21, Guillaume Munch wrote:
> Le 21/02/2016 08:33, Pavel Sanda a écrit :
 is there some obstacle I should be aware of before implementing microtype
 support via simple checkbox in document setting (plus maybe edit box for
 params) which would result into simple \usepackage[...]{microtype} in 
 header?
 Is there any opposition to add it into lyx? (I dont mean 2.2 obviously.)

> Good idea.

>>> Please make sure whether this works with "plain" LaTeX (dvi), XeTeX,
>>> and/or LuaTeX.

> In my experience, microtype works out of the box and the default values
> are safe, including with xetex/luatex.

I got the same impression after some tests with a *.tex file here.
This is also what the documentation tells: it works for all three of
pdflatex, xelatex, and lualatex but only pdflatex supports all features.
There is no error with "plain" latex (DVI, PS, PDF (ps2pdf), PDF (dvipdfm)
but no effect either.

A tooltip should hint to limited support (linking to the documentation)

> People who use custom parameters are on their own. But is there an
> advantage of letting users enter custom params via a line edit, instead
> of letting them write it by hand in the preamble?  It does not seem to
> me that the GUI helps here. Or do you have further plans for this
> feature?

Again, tooltips may be an advantage.

> Also, obviating the line edit, could the same not be accomplished by a
> module?

Yes. 

+1 no file format change
-1 bundling the microtype activation with other layout settings
   makes better user experience

>> 2. I am aware that it should be put before various font settings in preamble
>> so it's spitted just in the beginning. Are you aware of any catch for the
>> currently produced ordering?

> I haven't heard that microtype must be before font settings. My
> experience is consistent with https://tex.stackexchange.com/a/162436

Maybe this was a previous limitation.
Also, this should be in the documentation otherwise...

Günter

Re: [LyX/master] Spanish modernCV.lyx: update the file and make it compilable

2016-02-22 Thread Guenter Milde

On 2016-02-21, Kornel Benko wrote:
> Am Sonntag, 21. Februar 2016 um 16:07:20, schrieb Guenter Milde 
> 
>> On 2016-02-21, Kornel Benko wrote:

>> >> I investigated a little. Trying to compile manually (export as luatex,
>> >> use bibtex, use lualatex) I found what is causing lualatex/bibtex to
>> >> misbehave.

>> >> 1.) bibtex does not like the string 'jacsat' (biblioExample.bib:61,
>> >> entry Arduengo1994). Enclosing it in '{}' cures it. E.g. 'journal =
>> >> {jacsat},'.

>> This is new. It worked fine here.

> You can it see only if manually calling bibtex. It is a warning
> otherwise which lyx and luatex ignore.

However, did you also test that putting it into {} does not change the output?
Is it the same for 8-bit tex vs. luatex and for {jacsat} vs. jacsat ?

I assume this is supposed to be a pre-defined string but the definition may
be missing...

>> >> 2.) lualatex does not like the construct (biblioExample.bib:36, entry: 
>> >> Eisenstein2005)
>> >>   $\mbox{IrH}_{\mbox{5}}(\mbox{PPh}_{\mbox{3}})_{\mbox{2}}$
>> >> in title. Especially the last '_' is causing trouble. So for instance
>> >>   $\mbox{IrH}_{\mbox{5}}(\mbox{PPh}_{\mbox{3}}){\mbox{2}}$
>> >> is OK.

>> This resembles the description in suspiciousTests (the result of my
>> experiments):

>> # LuaTeX fails for an \mbox in an index, e.g. $a_{\mbox{a}}$.
>> # This construct appears in the included bib file biblioExample.bib in
>> # the entry Eisenstein2005. Error message is
>> #   Missing character: There is no (U+6035) in font rm-lmr12!
>> # (with system fonts: 602D and 6039)
>> export/examples/(|es/)(europe|modern)CV_(dvi3|pdf5)_(texF|systemF)

> Ah, yes. Did not think of looking at the description.
> But, using your example,  ${a}_{\mbox{a}}$ would work.

Did you try? It fails here. (Cf. lyx test file below.)

>> >> So, what to do with this biblio entry?

>> Mailing the patch to the upstream author?

>> Reporting the "mbox in index" problem to the LuaTeX authors?

> This is not about \mbox I think. 

> This patch fixes the luatex testcase for me. (But not xelatex)

There is still the mystery, why xelatex works here but not at your site.
The error report (missing character with some "strange" Unicode point) seems
to point to a similar problem.

Günter

#LyX 2.2 created this file. For more info see http://www.lyx.org/
\lyxformat 506
\begin_document
\begin_header
\save_transient_properties true
\origin unavailable
\textclass article
\use_default_options true
\maintain_unincluded_children false
\language english
\language_package default
\inputencoding auto
\fontencoding global
\font_roman "default" "default"
\font_sans "default" "default"
\font_typewriter "default" "default"
\font_math "auto" "auto"
\font_default_family default
\use_non_tex_fonts true
\font_sc false
\font_osf false
\font_sf_scale 100 100
\font_tt_scale 100 100
\graphics default
\default_output_format pdf5
\output_sync 0
\bibtex_command default
\index_command default
\paperfontsize default
\spacing single
\use_hyperref false
\papersize default
\use_geometry false
\use_package amsmath 1
\use_package amssymb 1
\use_package cancel 1
\use_package esint 1
\use_package mathdots 1
\use_package mathtools 1
\use_package mhchem 1
\use_package stackrel 1
\use_package stmaryrd 1
\use_package undertilde 1
\cite_engine basic
\cite_engine_type default
\biblio_style plain
\use_bibtopic false
\use_indices false
\paperorientation portrait
\suppress_date false
\justification true
\use_refstyle 1
\branch with mbox
\selected 1
\filename_suffix 0
\color #faf0e6
\end_branch
\branch with \text
\selected 0
\filename_suffix 0
\color #faf0e6
\end_branch
\branch with \mbox
\selected 1
\filename_suffix 0
\color #faf0e6
\end_branch
\index Index
\shortcut idx
\color #008000
\end_index
\secnumdepth 3
\tocdepth 3
\paragraph_separation indent
\paragraph_indentation default
\quotes_language english
\papercolumns 1
\papersides 1
\paperpagestyle default
\tracking_changes false
\output_changes false
\html_math_output 0
\html_css_as_file 0
\html_be_strict false
\end_header

\begin_body

\begin_layout Standard
Ah, yes.
 Did not think of looking at the description.
\end_layout

\begin_layout Standard
But, using your example, 
\begin_inset Branch with \mbox
status open

\begin_layout Standard
\begin_inset Formula ${a}_{\mbox{a}}$
\end_inset

\end_layout

\end_inset

\begin_inset Branch with \text
status open

\begin_layout Standard
\begin_inset Formula ${a}_{\text{a}}$
\end_inset

\end_layout

\end_inset

would work.
\end_layout

\end_body
\end_document

Re: Bug in Insert > Special Character > Symbols in beta1 & 2

Liviu Andronic wrote:

> This I can replicate. However, it's not a permanent freeze. I can see
> the CPU spiking, and LyX takes something like 10-15sec to settle, but
> then the dialog appears and scrolls fine. I would imagine LyX attempts
> to load quite a number of symbols, including hard to render things
> like Chinese characters...

I see this as well. In 9968-QList1.txt you can find the (shortened) output 
of gprof for creating a new LyX document, changing the encoding to utf8 and 
trying to view the complete symbols list in the dialog by choosing the blank 
line. What puzzles me is that gprof only covers a fraction of a second, 
although the dialog did freze for more than 10 seconds. My guess would be 
that there is some lock between threads. What I do not understand at all is 
why the document encoding makes a difference. If anybody has access to Intel 
VTune Amplifier or some other tool which can do profiling of multithreaded 
code we might get a better picture of what is happening here.

A very quick optimizing (see patch) improves the gprof numbers and also the 
dialog seems to be a little bit faster. I do not know whether the container 
change did help or not, I was too lazy to try with only the change of order 
in GuiSymbols::Model::data(). BTW, for details about qt containers I'd 
recommend Marc Mutz: https://marcmutz.wordpress.com/effective-qt/containers/

I do not see a crash. This is not a blocker for 2.2.0 IMHO, I can see the 
bug in 2.1 as well.


Georgdiff --git a/src/frontends/qt4/GuiSymbols.cpp b/src/frontends/qt4/GuiSymbols.cpp
index dad0211..d5c1638 100644
--- a/src/frontends/qt4/GuiSymbols.cpp
+++ b/src/frontends/qt4/GuiSymbols.cpp
@@ -25,6 +25,7 @@
 
 #include "support/debug.h"
 #include "support/gettext.h"
+#include "support/lassert.h"
 
 #include 
 #include 
@@ -186,6 +187,8 @@ QString getBlock(char_type c)
 }
 
 
+typedef std::vector SymbolVector;
+
 } // namespace anon
 
 
@@ -214,7 +217,7 @@ public:
 
 	int rowCount(QModelIndex const &) const
 	{
-		return symbols_.count();
+		return static_cast(symbols_.size());
 	}
 
 	int columnCount(QModelIndex const &) const
@@ -227,11 +230,12 @@ public:
 		static QString const strCharacter = qt_("Character: ");
 		static QString const strCodePoint = qt_("Code Point: ");
 
-		char_type c = symbols_.at(index.row()); 
-
 		if (role == Qt::TextAlignmentRole)
 			return QVariant(Qt::AlignCenter);
 
+		LASSERT(index.row() < static_cast(symbols_.size()), return QVariant());
+		char_type c = symbols_[index.row()];
+
 		if (role == Qt::DisplayRole)
 			return toqstr(c);
 
@@ -248,17 +252,18 @@ public:
 		return QVariant();
 	}
 
-	void setSymbols(QList const & symbols)
+	void setSymbols(SymbolVector & symbols)
 	{
+		// symbols is non-const for performance reasons (bug 9968)
 		QAbstractItemModel::beginResetModel();
-		symbols_ = symbols;
+		symbols_.swap(symbols);
 		QAbstractItemModel::endResetModel();
 	}
 
 private:
 	friend class GuiSymbols;
 
-	QList symbols_;
+	SymbolVector symbols_;
 };
 
 
@@ -407,7 +412,7 @@ void GuiSymbols::updateSymbolList(bool update_combo)
 	bool const nocategory = category.isEmpty();
 	char_type range_start = 0x;
 	char_type range_end = 0x11;
-	QList s;
+	SymbolVector s;
 	if (update_combo) {
 		used_blocks.clear();
 		categoryCO->clear();
@@ -438,7 +443,7 @@ void GuiSymbols::updateSymbolList(bool update_combo)
 			continue;
 		++numItem;
 		if (show_all || (c >= range_start && c <= range_end))
-			s.append(c);
+			s.push_back(c);
 		if (update_combo) {
 			QString block = getBlock(c);
 			if (category.isEmpty())

Flat profile:

Each sample counts as 0.01 seconds.
  %   cumulative   self  self total   
 time   seconds   secondscalls  ms/call  ms/call  name
 53.13  0.17 0.17 
lyx::frontend::GuiSymbols::Model::data(QModelIndex const&, int) const
  9.38  0.20 0.03215.0044.69  
lyx::frontend::GuiSymbols::updateSymbolList(bool)
  6.25  0.22 0.02  2232430 0.00 0.00  lyx::frontend::(anonymous 
namespace)::getBlock(wchar_t)
  6.25  0.24 0.02   467714 0.00 0.00  
lyx::Messages::get(std::string const&) const
  6.25  0.26 0.02 non-virtual thunk to 
lyx::frontend::GuiSymbols::getLfun() const
  3.13  0.27 0.01  2232430 0.00 0.00  std::_Rb_tree, 
std::less, std::allocator 
>::find(QString const&)
  3.13  0.28 0.01   467723 0.00 0.00  
lyx::LyX::messages(std::string const&)
  3.13  0.29 0.0132953 0.00 0.00  
lyx::Lexer::Pimpl::next(bool)
  3.13  0.30 0.01 
lyx::frontend::GuiSymbols::Model::columnCount(QModelIndex const&) const
  3.13  0.31 0.01 non-virtual thunk to 
lyx::frontend::GuiSpellchecker::initialiseParams(std::string const&)
  1.56  0.32 0.01   274280 0.00

Re: Fwd: Warnings in preview PS lyx-2.2.0beta2

2016-02-22 Thread Guenter Milde

On 2016-02-22, Buenas Noticias wrote:
> Hi all:

> Note that you can still view the PDF despite the reported errors, with
> the "Show Output" button in the LaTeX Errors dialog.

> Show Output is disabled in my lyx-2.2.0. The missing glyphs blocked the 
> output. Stop.

Normally, missing glyphs don't block the output. There may be another error
in addition that prevented creation of a PDF/PS/DVI.

Try exporting to LaTeX and compiling "by hand".

Günter

Re: clang doesn't like -std=c++11 for Objective C files

2016-02-22 Thread Stephan Witt

Am 22.02.2016 um 15:06 schrieb Jean-Marc Lasgouttes :
> 
> Le 22/02/2016 14:37, Stephan Witt a écrit :
>>> So, could you tell me what happens when you do (with my first patch)
>>> cd src/support && make AppleSpeller.o
>> 
>> With first patch applied compiling AppleSpeller.o succeeds.
> 
> Great. So I have your +1 to apply this first patch? I prefer to go step by 
> step.

Yes, +1.

> 
>> $ grep USE_LLVM_LIBCPP lyx-build/LyX-2.2.0dev.build/config.h
>> /* #undef USE_LLVM_LIBCPP */
>> 
>> The config log was already attached at last answer.
> 
> I missed it, sorry. Are you sure that you did run ./autogen.sh after adding 
> the '-stdlib=libc++' part? I do not see libc++ being used anywhere.

No problem.

> 
>>> That's the whole point. If C++11 is the default, it is because we expect
>>> it to work. In 2.3, it will be mandatory.
>> 
>> Ok, in theory current clang should has working C+11 support. How good it is
>> in practise we’ll see.
> 
> Probably not worse than g++ 4.6, that I use here in ubuntu 12.04.

Maybe. What I don’t understand, why it isn’t simply working then?
Is it a problem to use different compilers for building Qt frameworks
and later building LyX? IOW, is it a problem I’ve caused myself?

Stephan

Re: Remove date external template for 2.2.0?

Jean-Marc Lasgouttes wrote:

> Le 18/02/2016 04:50, Scott Kostyshak a écrit :
>> There have been various discussions about how the date external material
>> template is useless. I think it was kept around mostly just to be an
>> example of what could be done.
>>
>> Two questions:
>> 1. Do we want to remove it?
>> 2. Do we want to remove it for 2.2.0?
>>
>> Note that this is #9948.
> 
> I think it is too late now. Let us try to release 2.2.0 as soon as
> possible and get on with our lives.

+1


Georg

Re: lyx-cvs messages: show file names changed

Jean-Marc Lasgouttes wrote:

> Le 18/02/2016 02:58, Scott Kostyshak a écrit :
>> Would anyone else find it useful if the lyx-cvs messages showed the file
>> names that were changed at the beginning of a message? One example is
>> that I would often like to know if a commit is documentation only or if
>> there is another change that I would like to take a look at.
> 
> Yes, it would be useful, but probably after the log message.

+1

Georg

Re: [patch] support Bosnian, Macedonian, Piedmontese and Romansh

Guillaume Munch wrote:

> Le 21/02/2016 20:52, Scott Kostyshak a écrit :
>> On Sun, Feb 21, 2016 at 06:06:14PM +0100, Uwe Stöhr wrote:
>>> I also don't see a reason why this cannot be done now since otherwise
>>> users of than languages would have to wait 2 more years until LyX 2.3.

Every LyX release in the past few years was further delayed by last-minute 
requests like this one. If we stop these last-minute changes, and improve 
the test coverage we can speed up the release process a lot.

Besides that, every LyX release misses some features that are important for 
some users. The only way to avoid this is to throw a massive amount of 
developer man power upon LyX, and we all know that this won't happen.

>> I agree that this is unfortunate. But the same is true for any feature.
>> The feature freeze was over two months ago. Now we are focusing only on
>> bug fixes. I do not think it would be fair to make an exception for this
>> patch.

Exactly. Such exceptions punish those who play by the rules and reward those 
who ignore the rules. This does not mean that I don't like the support for 
the new languages. It is a very good thing to have, just not right now.

> I would not be shocked if an exception was made. Uwe's point is that it
> is low risk/high reward and that being delayed until 2.3 is quite
> significant. I do not remember seeing another patch in this situation.

Because they have not been proposed. I have several easy features or bug 
fixes I'd like to put in (e.g. http://www.lyx.org/trac/ticket/7404), but I 
did not propose them after the freeze because I assumed that the freeze was 
a freeze. Instead, I used my time for reviewing needed changes, and for 
fixing show stopper bugs.

> * Is the lack of these languages easy to work around if the patch is
> postponed?

Yes. Load babel manually in the preamble, and disable the automatic loading 
via preferences (language settings->language package=none)

> * Is there any risk that the settings might be wrong (especially in ways
> that cannot be fixed without another file format increase)?

Yes. For every new language we need a native speaker to verify that the 
result is correct. For example, support for urdu was added at 
http://www.lyx.org/trac/changeset/7eca5d94/lyxgit, and later it turned out 
that it was completely unusable, so that it was removed again at 
http://www.lyx.org/trac/changeset/cf9c7ad108fbc/lyxgit. 

Georg

Re: blockers for 2.2.0?


Le 22/02/2016 17:03, Jean-Marc Lasgouttes a écrit :

Le 22/02/2016 16:54, Guillaume Munch a écrit :

Before Jean-Marc's message, I moved the milestone to 2.2.x because the
results of proper testing will not be known in time. But I
agree with Jean-Marc that it could be applied right now without being
sure that it fixes the bug. (Unfortunately I am not familiar enough with
cursor & selection myself.) Here's a direct link to the patch:

http://www.lyx.org/trac/attachment/ticket/9917/0001-Reset-anchor-after-having-modified-the-cursor-not-be.patch



oops! Seeing the patch again makes me relaize that the logic is wrong. I
update it ASAP.


Pfff, actually I see now that if I do the resetAnchor before (or after) 
the clearSelection() call, nothing will happen any way, since 
clearSelection does a resetAnchor of its own.


Therefore this patch is not good even in fixed form. I guess that this part
-   if (!do_selection)
-   d->cursor_.resetAnchor();
is correct, but removing this code will not fix anything, the code is 
useless.


Sigh.

JMarc

Re: blockers for 2.2.0?


Le 22/02/2016 17:13, Jean-Marc Lasgouttes a écrit :

Pfff, actually I see now that if I do the resetAnchor before (or after)
the clearSelection() call, nothing will happen any way, since
clearSelection does a resetAnchor of its own.

Therefore this patch is not good even in fixed form. I guess that this part
-   if (!do_selection)
-   d->cursor_.resetAnchor();
is correct, but removing this code will not fix anything, the code is
useless.


So, to make things clear, I do not have any fix for this bug, but since 
it is an auto-fixing assertion and not a real crash, it is not a 2.2.0 
blocker IMO.


JMarc

Re: blockers for 2.2.0?


Le 22/02/2016 16:54, Guillaume Munch a écrit :

Before Jean-Marc's message, I moved the milestone to 2.2.x because the
results of proper testing will not be known in time. But I
agree with Jean-Marc that it could be applied right now without being
sure that it fixes the bug. (Unfortunately I am not familiar enough with
cursor & selection myself.) Here's a direct link to the patch:

http://www.lyx.org/trac/attachment/ticket/9917/0001-Reset-anchor-after-having-modified-the-cursor-not-be.patch


oops! Seeing the patch again makes me relaize that the logic is wrong. I 
update it ASAP.


JMarc

Re: blockers for 2.2.0?

2016-02-22 Thread Guillaume Munch


Le 22/02/2016 10:16, Jean-Marc Lasgouttes a écrit :

Le 21/02/2016 22:04, Scott Kostyshak a écrit :

We have 11 trac tickets with a 2.2.0 milestone. Any help with reducing
those 11 would be appreciated:

http://www.lyx.org/trac/query?status=accepted=reopened=assigned=new=status=2.2.0



A few comments:

  * regarding #9917, I'd appreciate if some other developers who know
about cursor and selection could look at the patch that I posted there
and give a +1 on code soundness. Then I would propose to apply it. At
worst it would not fix the bug, I think.



Before Jean-Marc's message, I moved the milestone to 2.2.x because the
results of proper testing will not be known in time. But I
agree with Jean-Marc that it could be applied right now without being
sure that it fixes the bug. (Unfortunately I am not familiar enough with
cursor & selection myself.) Here's a direct link to the patch:

http://www.lyx.org/trac/attachment/ticket/9917/0001-Reset-anchor-after-having-modified-the-cursor-not-be.patch




I am not sure that #9968, #9979, #9869 and #9633 are 2.2.0 blockers per
se, since they exist in 2.1.x too.



There is now a patch for #9869.

Re: Fwd: Warnings in preview PS lyx-2.2.0beta2

2016-02-22 Thread Buenas Noticias


Hi all:

Note that you can still view the PDF despite the reported errors, with
the "Show Output" button in the LaTeX Errors dialog.

Show Output is disabled in my lyx-2.2.0. The missing glyphs blocked the 
output. Stop.


Miguel




On 19/02/16 17:32, Scott Kostyshak wrote:

On Fri, Feb 19, 2016 at 12:00:39PM +0100, Buenas Noticias wrote:




 Forwarded Message 
Subject: Warnings in preview PS lyx-2.2.0beta2
Date: Thu, 18 Feb 2016 10:26:54 +0100
From: Buenas Noticias 
To: LyX Developers 

Hi all:

When I want to see the article I'm writing in PS, do not open and I get
the following warnings:

- Missing glyphs!

- Missing character: There is no  in font LinBiolinumT-tlf-ts1!

Can you help me?

Miguel



Hi Miguel,

I responded to your message here:

https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg192741.html

Thanks for testing beta2. you are receiving an error the LyX simply did
not detect before. This is documented in the release notes (Help > About
LyX > Release Notes) as follows:

* Missing characters in the output are now reported as errors. This leads
   to error reports for documents that compiled without error before.
   However, the error was always present but went undetected!

What this means is that in LyX 2.1.x there was probably a character that
did not show up correctly in your PDF output. You should find out which
character that is.

Note that you can still view the PDF despite the reported errors, with
the "Show Output" button in the LaTeX Errors dialog.

Scott

Re: clang doesn't like -std=c++11 for Objective C files


Le 22/02/2016 14:37, Stephan Witt a écrit :

So, could you tell me what happens when you do (with my first patch)
cd src/support && make AppleSpeller.o


With first patch applied compiling AppleSpeller.o succeeds.


Great. So I have your +1 to apply this first patch? I prefer to go step 
by step.



$ grep USE_LLVM_LIBCPP lyx-build/LyX-2.2.0dev.build/config.h
/* #undef USE_LLVM_LIBCPP */

The config log was already attached at last answer.


I missed it, sorry. Are you sure that you did run ./autogen.sh after 
adding the '-stdlib=libc++' part? I do not see libc++ being used anywhere.



That's the whole point. If C++11 is the default, it is because we expect
it to work. In 2.3, it will be mandatory.


Ok, in theory current clang should has working C+11 support. How good it is
in practise we’ll see.


Probably not worse than g++ 4.6, that I use here in ubuntu 12.04.

JMarc

Re: Is "make distcheck" failure a blocker?


Le 18/02/2016 04:45, Scott Kostyshak a écrit :

make distcheck fails for some people and passes for others. It fails for
me. I think it passes for Pavel now that Georg's fix was committed.

We have not gotten to the root of why make distcheck fails for some. See
this thread for previous efforts:
https://www.mail-archive.com/search?l=mid=20151125075443.GA7491%40cotopaxi.hsd1.dc.comcast.net


I downloaded beta2 and ran:
./configure
make distcheck

It worked without problem. Note that I did not use any -jX option, in 
case they create dependencies problems.


JMarc

Re: Replacement of "long table" by "multi-pages table" in the manuals


Le 10/02/2016 00:32, Scott Kostyshak a écrit :

I mean, if there is string freeze, I, as a translator, can be sure that all 
needed strings are available.


OK I think we are on the same page.


What is the status of this?

JMarc

Re: beta2?

2016-02-22 Thread Peter Kümmel

Am 21.02.2016 um 17:59 schrieb Scott Kostyshak:

On Mon, Feb 15, 2016 at 05:06:19PM +0100, Kornel Benko wrote:

Am Sonntag, 14. Februar 2016 um 23:39:00, schrieb Pavel Sanda

Peter Kümmel wrote:

Uwe still gets the following errors from the tar I sent to him:

D:\LyXGit\LyX22beta3\3rdparty\boost\boost/numeric/conversion/detail/numeric_cast_traits.hpp(12):
fatal error C1083: File (Include) cannot be opened:
"boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_common.hpp":
No such file or directory
[D:\LyXGit\LyX22beta3\compile-2010\src\support\support.vcxproj]

I only tested with "build5-2010-installer.bat"

Is this script now used to build official installer?
In case of yes, would be our cmake gurus able to add routine
which spits out md5sum of installer binaries which could Uwe
posts in his email when publishing the binaries?

Pavel

For me it is not clear, how the binary zip-file is created on windows.
If I would know, I could create a new target to compute md5sum for this
zip-file.
I created and committed a cmake-script to be used for this task.

It would be really nice to get this working. Peter, do you have an idea
of how to accomplish this?

AFAIK the installer is build in two steps,
1. build LyX and install locally
2. point the install file creater (NSIS) to the local LyX installation and
start NSIS manually

So I don't know were we can calculate any sensible md5sum with cmake.

Peter

Note that this just came up on the news today:
http://blog.linuxmint.com/?p=2994

Scott

Re: lyx-cvs messages: show file names changed


Le 18/02/2016 02:58, Scott Kostyshak a écrit :

Would anyone else find it useful if the lyx-cvs messages showed the file
names that were changed at the beginning of a message? One example is
that I would often like to know if a commit is documentation only or if
there is another change that I would like to take a look at.


Yes, it would be useful, but probably after the log message.

JMarc

Re: clang doesn't like -std=c++11 for Objective C files

Le 17/02/2016 11:41, Stephan Witt a écrit :

You are not answering my question :) The question was "does it
allow to compile .m files in C++11 mode?“

It looks like I didn’t know the answer. Perhaps I shouldn’t have give
an answer :)

So, could you tell me what happens when you do (with my first patch)
cd src/support && make AppleSpeller.o

I'd like to apply it if it does what it is supposed to do: fix
compilation of .m files in C++11 mode.

Patrick, did you try it?

As far as your other compile problems are concerned, let's start
from the end : the errors in LyX headers.

First idea: look at the Update 4 here:
http://stackoverflow.com/questions/17849154/where-is-definition-of-stdfunction-in-clang-3-3-xcode

Do you suffer from the same issue (an extra version of llvm installed
via hombrew?)

No I don’t have installed homebrew. I don’t like beer - I’m having a
preference for wine.

If it does not work, second idea: pass the flag " -stdlib=libc++"
to select the libc++ library instead of the old gcc lisbstdc++ that
Apple is shipping
http://stackoverflow.com/questions/9345271/xcode-4-3-and-c11-include-paths

With the attached patch I have this error and many more errors:

In file included from
/Users/stephan/git/lyx/src/support/debug.cpp:17: In file included
from /Users/stephan/git/lyx/src/support/../support/FileName.h:19: In
file included from
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/set:387:

In file included from
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/__tree:17:

/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/stdexcept:70:32:
error: reference to 'string' is ambiguous explicit logic_error(const
string&);

What does your config.h look like? Do you have USE_LLVM_LIBCPP defined?
Can I see the corresponding config.log?

(I have extended this line: cxx11_flags="-std=c++11 -stdlib=libc++“)

I am not 100% sure that it works.

What exactly is the bug I did work around? Is it correct to expect
working C++11 support?

That's the whole point. If C++11 is the default, it is because we expect
it to work. In 2.3, it will be mandatory.

PS. The indentation of lyxinclude.m4 is not nice. This makes it hard
to read with my favorite editor vi.

This file is indeed a mess.

JMarc

Re: blockers for 2.2.0?