Re: fix math toolbars

[Enrico Forestieri]

On Tue, Sep 13, 2016 at 01:44:05AM +0100, Guillaume Munch wrote:

> Le 12/09/2016 à 19:35, Enrico Forestieri a écrit :
> > On Mon, Sep 12, 2016 at 05:01:33AM +0200, Enrico Forestieri wrote:
> > > 
> > > You can spare your time as I think I found the problem. The patch simply
> > > uncovered a latent bug. The crash only occurs when there is a user
> > > defined math macro. In this case, d->macro_->symbol() may return bogus
> > > values. For a user defined macro it should always return a null pointer,
> > > but for unknown reasons it sometimes returns strange values, which are
> > > clearly bogus and cause a crash when dereferenced.
> > > 
> > > I did not succeed in understanding why this occurs.
> > 
> > I have found that this occurs because of some missing metric updates.
> > The attached alternative patch covers all cases except one. This is the
> > case in which user defined math macros are present _and_ instant preview
> > is active. I did not find a solution for this case, so the previous patch
> > is better. However, there are other cases in the sources in which the
> > sym_ member of MacroData (the one returned by d->macro_->symbol()) is
> > used. In these cases it is accessed only after checking that it is not
> > null, but, as this case shows, this does not gaurantee that it is usable
> > and a crash would occur. However, these cases are mainly related to the
> > xhtml output, so they are not as frequent, possibly.
> > 
> 
> 
> Hi Enrico, thanks for looking into it. These macros truly look like a
> mine field. Unfortunately it still segfaults (though with a different
> backtrace). I did not have the time to build a test case today.

The symptom seems to be the same, so I am maybe missing some case.
Unfortunately, without a test case there is not much I can do.
In the mean time I will commit both patches, as the alternative one
will also help in the other cases mentioned above and then we can start
from there. However, from next week I will not have time anymore.

-- 
Enrico

Re: [LyX/master] partly Revert "fr/UserGuide: remove spurious language switch in an index inset."

[Scott Kostyshak]

On Mon, Sep 12, 2016 at 11:24:20PM +0200, Uwe Stöhr wrote:
> Hi Scott,
> 
> Yes, feel free to make obvious changes in branch. Please also update the 
> other language versions if possible. After branch you ca port to master. 
> Please keep the fileformat unless you document a new feature that‎ requires a 
> never fileformat. 

OK I will do my best to do this in the future. When I forget (and I
will), please remind me.

> This rule applies also to the templates and example files
>  I'll add this to Development.lyx as soon I have agian Internet at home.

Great! I will look forward to reading the Development.lyx additions. I
will try to read that document from time to time to refresh my memory.

Thanks,

Scott


signature.asc
Description: PGP signature

Re: fix math toolbars

[Guillaume Munch]

Le 12/09/2016 à 19:35, Enrico Forestieri a écrit :

On Mon, Sep 12, 2016 at 05:01:33AM +0200, Enrico Forestieri wrote:


You can spare your time as I think I found the problem. The patch simply
uncovered a latent bug. The crash only occurs when there is a user
defined math macro. In this case, d->macro_->symbol() may return bogus
values. For a user defined macro it should always return a null pointer,
but for unknown reasons it sometimes returns strange values, which are
clearly bogus and cause a crash when dereferenced.

I did not succeed in understanding why this occurs.


I have found that this occurs because of some missing metric updates.
The attached alternative patch covers all cases except one. This is the
case in which user defined math macros are present _and_ instant preview
is active. I did not find a solution for this case, so the previous patch
is better. However, there are other cases in the sources in which the
sym_ member of MacroData (the one returned by d->macro_->symbol()) is
used. In these cases it is accessed only after checking that it is not
null, but, as this case shows, this does not gaurantee that it is usable
and a crash would occur. However, these cases are mainly related to the
xhtml output, so they are not as frequent, possibly.




Hi Enrico, thanks for looking into it. These macros truly look like a
mine field. Unfortunately it still segfaults (though with a different
backtrace). I did not have the time to build a test case today.


#0  lyx::operator== (
l=0x7fff0069>,
r=r@entry=0xd96a52 "textmode") at 
../../../src/support/docstring.cpp:175

#1  0x0085ae8b in lyx::MathMacro::write (this=0x319e6d0, os=...)
at ../../src/mathed/MathMacro.cpp:933
#2  0x00846850 in lyx::write (dat=..., wi=...)
at ../../src/mathed/MathExtern.cpp:1407
#3  0x008857a5 in lyx::operator<< (ws=..., ar=...)
at ../../src/mathed/MathStream.cpp:206
#4  0x0082dbcf in lyx::InsetMathScript::write (this=0x319e540, 
os=...)

at ../../src/mathed/InsetMathScript.cpp:508
#5  0x00846850 in lyx::write (dat=..., wi=...)
at ../../src/mathed/MathExtern.cpp:1407
#6  0x008857a5 in lyx::operator<< (ws=..., ar=...)
at ../../src/mathed/MathStream.cpp:206
#7  0x008aa82a in lyx::InsetMathGrid::write 
(this=this@entry=0x31a3590,

os=..., beg_row=beg_row@entry=0, beg_col=beg_col@entry=0,
end_row=, end_col=end_col@entry=4)
at ../../src/mathed/InsetMathGrid.cpp:1310
#8  0x008aace1 in lyx::InsetMathGrid::write 
(this=this@entry=0x31a3590,

os=...) at ../../src/mathed/InsetMathGrid.cpp:1263
#9  0x008d023b in lyx::InsetMathXYMatrix::write (this=0x31a3590, 
os=...)

at ../../src/mathed/InsetMathXYMatrix.cpp:88
#10 0x00846850 in lyx::write (dat=..., wi=...)
at ../../src/mathed/MathExtern.cpp:1407
#11 0x008857a5 in lyx::operator<< (ws=..., ar=...)
at ../../src/mathed/MathStream.cpp:206
#12 0x00807042 in lyx::InsetMathHull::plaintext (this=0x3197d80,
os=..., op=..., max_length=)
at ../../src/mathed/InsetMathHull.cpp:2236
#13 0x008056a0 in lyx::InsetMathHull::forOutliner (this=0x3197d80,
os=L"") at ../../src/mathed/InsetMathHull.cpp:2570
#14 0x006a890e in lyx::Paragraph::forOutliner (this=0x319d500, 
os=L"",

maxlen=maxlen@entry=121, shorten=shorten@entry=false)
at ../../src/Paragraph.cpp:3295
#15 0x006f0faa in lyx::Text::forOutliner 
(this=this@entry=0x319e108,

os=L"", maxlen=maxlen@entry=120, shorten=shorten@entry=true)
at ../../src/Text.cpp:2054
#16 0x009a9788 in lyx::InsetNote::addToToc (this=0x319e0f0, 
cpit=...,

output_active=, utype=lyx::InternalUpdate)

Re: [LyX/master] partly Revert "fr/UserGuide: remove spurious language switch in an index inset."

[Uwe Stöhr]

Hi Scott,

Yes, feel free to make obvious changes in branch. Please also update the other 
language versions if possible. After branch you ca port to master. Please keep 
the fileformat unless you document a new feature that‎ requires a never 
fileformat. 

This rule applies also to the templates and example files
 I'll add this to Development.lyx as soon I have agian Internet at home.

Regards Uwe

  Original Message  
From: Scott Kostyshak
Sent: Donnerstag, 8. September 2016 14:58
To: lyx-devel@lists.lyx.org
Cc: Uwe Stöhr
Subject: Re: [LyX/master] partly Revert "fr/UserGuide: remove spurious language 
switch in an index inset."

On Thu, Sep 08, 2016 at 12:52:51AM +0200, Uwe Stöhr wrote:
> commit 7d94afc4daf45d96965cd09a7003ec56b514c67f
> Author: Uwe Stöhr 
> Date: Thu Sep 8 00:52:45 2016 +0200
> 
> partly Revert "fr/UserGuide: remove spurious language switch in an index 
> inset."
> 
> Please fix at first the versions in branch since this is the working copy 
> delivered with LyX.
> Also please keep the fileformat unless you need to document a new feature 
> that requires a new fileformat.

I often forget the rules on documentation. I know they are simple, but I
have a bad memory. Are these guidelines in Development.lyx? If they are
not, I can try to write them down after I understand more so that it
will be easier for newcommers and bad memoryiers. Do they apply to only
lib/doc or also lib/examples and lib/templates?

If we make changes in branch, can we make changes in master at the same
time? For example, for this commit, would it have been OK if we had
changed both branch and master in the same way or is there a reason why
that would not be a good idea?

Scott

Anything I should test with Qt 5.7 or 5.8dev?

[Scott Kostyshak]

I compile Qt inside a virtual box to test the dev version. Do we have
any bugs with reproducible steps where we wonder if something is a Qt
bug and are not sure if it was fixed in 5.7? If so I can test.

Note that if you are interested in testing, make a fresh install of
Ubuntu 16.04, install git, do a git clone of
https://github.com/scottkosty/lyx-tester

and run
"sudo ./lyx-tester" --qt-from "git"

if you do not use the --qt-from option, it will just compile LyX against
Ubuntu's repo version.

Leave it running over night. It takes a while to dl the git repos of Qt
and LyX and to install TeX Live. Note that by default the full ctest
suite is run. You can omit this with the option --no-test option.

All options (not many) are described with
./lyx-tester --help

I *only* recommend running the script in a virtual box. If using the
--qt-from "git" option, you will need a virtual box with a total size of
about 37G or 38G.

Scott


signature.asc
Description: PGP signature

Re: Intro with PDF(luatex)

[Scott Kostyshak]

On Mon, Sep 12, 2016 at 04:06:41PM +, Guenter Milde wrote:

> Thanks a lot for your diff.
> 
> It helped me to find some old cruft in
> /usr/local/share/texmf/tex/latex/graphics/
> that was there from times Debian's TeXLive lagged behind development...

Glad we figured out the root cause. I'm actually surprised that didn't
cause bigger differences in our test results.

> After removing this, the tests run fine. I will remove the
> entry in unreliableTests.

OK let's both run the full tests after that and compare again to see if
we have any differences.

At least for the normal (e.g. not the suspicious or unreliable) tests we
are approaching zero. Once we get there, I think it will be easy to
maintain.

Scott


signature.asc
Description: PGP signature

Re: fix math toolbars

[Enrico Forestieri]

On Mon, Sep 12, 2016 at 05:01:33AM +0200, Enrico Forestieri wrote:
> On Sun, Sep 11, 2016 at 09:04:56PM +0100, Guillaume Munch wrote:
> > Le 11/09/2016 à 11:05, Enrico Forestieri a écrit :
> > 
> > >Please give
> > >steps or test cases for reproducing the crash and I will have a look.
> > >
> > 
> > It usually takes some effort. I'll try to find the time.
> 
> You can spare your time as I think I found the problem. The patch simply
> uncovered a latent bug. The crash only occurs when there is a user
> defined math macro. In this case, d->macro_->symbol() may return bogus
> values. For a user defined macro it should always return a null pointer,
> but for unknown reasons it sometimes returns strange values, which are
> clearly bogus and cause a crash when dereferenced.
> 
> I did not succeed in understanding why this occurs.

I have found that this occurs because of some missing metric updates.
The attached alternative patch covers all cases except one. This is the
case in which user defined math macros are present _and_ instant preview
is active. I did not find a solution for this case, so the previous patch
is better. However, there are other cases in the sources in which the
sym_ member of MacroData (the one returned by d->macro_->symbol()) is
used. In these cases it is accessed only after checking that it is not
null, but, as this case shows, this does not gaurantee that it is usable
and a crash would occur. However, these cases are mainly related to the
xhtml output, so they are not as frequent, possibly.

-- 
Enrico
diff --git a/src/BufferView.cpp b/src/BufferView.cpp
index 0212b16..b4564b4 100644
--- a/src/BufferView.cpp
+++ b/src/BufferView.cpp
@@ -495,7 +495,7 @@ void BufferView::processUpdateFlags(Update::flags flags)
 
// updateMetrics() does not update paragraph position
// This is done at draw() time. So we need a redraw!
-   buffer_.changed(false);
+   buffer_.changed(true);
 
if (needsFitCursor()) {
// The cursor is off screen so ensure it is visible.
@@ -2181,7 +2181,7 @@ void BufferView::updateHoveredInset() const
 
// This event (moving without mouse click) is not passed 
further.
// This should be changed if it is further utilized.
-   buffer_.changed(false);
+   buffer_.changed(true);
}
 }
 

Re: Do we have a webmaster?

[Pavel Sanda]

Richard Heck wrote:
> On 09/11/2016 09:32 PM, Pavel Sanda wrote:
> > Paul A. Rubin wrote:
> >> I can perhaps step in and do some interim 
> >> maintenance (once I get the keys to the castle).
> > Can you be more specific what changes you have in mind?
> 
> One: Apparently, gmane is dead, so we need to remove references to it
> from the site.

I was following that story a bit, there is a good chance it will be restored 
again,
commmunity got screaming that this service shouldn't die a people offered help 
to
rescue it again.

> I realize, finally, that since the entire website is really a wiki, the only
> thing Paul needs is the password to edit pages. Any objection?

Depends what part of web you talk about, that's why I asked.
I am all for giving Paul the wiki access.

Pavel

Re: Intro with PDF(luatex)

[Guenter Milde]

On 2016-09-11, Scott Kostyshak wrote:
> On Sat, Sep 10, 2016 at 07:19:27AM +, Guenter Milde wrote:
>> On 2016-09-10, Scott Kostyshak wrote:
>> > On Fri, Sep 09, 2016 at 06:24:02PM +, Guenter Milde wrote:
>> >> On 2016-09-09, Scott Kostyshak wrote:

>> >> ...

>> >> > INVERTED.TODO_export/doc/nb/Intro_pdf5_texF

...

>> > Is this with an updated TL 2016? 

>> Yes, this happened after updating TL 2016 to the version in Debian/testing
>> about a week ago.

...

> Thanks for sending that. Below I note some important differences.

>> (/usr/local/share/texmf/tex/latex/graphics/color.cfg
>> File: color.cfg 2007/01/18 v1.5 color configuration of teTeX/TeXLive

> This seems quite old compared to TL 2016 version. I have the following:

...

> I stopped looking after those diffs. My full log (with paths changed to
> match yours so the diff is easier) is attached.

Thanks a lot for your diff.

It helped me to find some old cruft in
/usr/local/share/texmf/tex/latex/graphics/
that was there from times Debian's TeXLive lagged behind development...

After removing this, the tests run fine. I will remove the
entry in unreliableTests.

Günter

Re: [LyX/master] Set window title according to platform UI

[Jean-Marc Lasgouttes]

Le 11/09/2016 à 04:49, Guillaume Munch a écrit :

Le 08/09/2016 à 14:59, Jean-Marc Lasgouttes a écrit :

commit 82808fea04315fd323ec074e8ad7865d190987d4
Author: Jean-Marc Lasgouttes 
Date:   Tue Sep 6 11:17:10 2016 +0200

Set window title according to platform UI

+// Tell Qt whether the current document is changed
+setWindowModified(!buf.isClean());



LyX produces the following message on the console in current master:

QWidget::setWindowModified: The window title does not contain a '[*]'
placeholder


Can you describe when this happens? I do not see it.

JMarc

Re: [LyX/master] Test and fix lib/unicodesymbols for Letterlike Symbols, Number Forms and Arrows blocks.

[Scott Kostyshak]

On Mon, Sep 12, 2016 at 09:50:54AM +, Guenter Milde wrote:
> On 2016-09-11, Scott Kostyshak wrote:
> 
> > [-- Type: text/plain, Encoding:  --]
> 
> > On Sun, Sep 11, 2016 at 06:46:47PM +, Guenter Milde wrote:
> 
> >> Could you please change the test reference accordingly?
> 
> > Done at d3c63f97.
> 
> Thank you.
> 
> I changed this in 99eeb29e5863516220eb823c2bcc276761107c41 to make the input
> sample "box-color*.tex" compilable without errors and give a clean import to
> LyX:
> 
> Load required package textcomp.
> Replace call to non-existent packages textcyr and textgreek with the backup 
> definition of the commands as done by LyX export.
> Do not load marvosym (clash with pifont) (LyX does not load the package 
> either).
> Remove invalid command \\ascii.

Sounds good. I just ran the tex2lyx tests on current master and they all
pass so since you confirm that the changes to the reference tests are
correct, I think we proceeded correctly.

I'm guessing you already know, but I had forgotten that to update the
tests (e.g. after you confirm that the changes are indeed correct), with
CMake we can run "make updatetex2lyxtests" in the root of the build
directory. I had to reread Development.lyx to realize this.

Scott


signature.asc
Description: PGP signature

Re: fix math toolbars

[Enrico Forestieri]

On Mon, Sep 12, 2016 at 05:01:33AM +0200, Enrico Forestieri wrote:

> On Sun, Sep 11, 2016 at 09:04:56PM +0100, Guillaume Munch wrote:
> > Le 11/09/2016 à 11:05, Enrico Forestieri a écrit :
> > 
> > >Please give
> > >steps or test cases for reproducing the crash and I will have a look.
> > >
> > 
> > It usually takes some effort. I'll try to find the time.
> 
> You can spare your time as I think I found the problem. The patch simply
> uncovered a latent bug. The crash only occurs when there is a user
> defined math macro. In this case, d->macro_->symbol() may return bogus
> values. For a user defined macro it should always return a null pointer,
> but for unknown reasons it sometimes returns strange values, which are
> clearly bogus and cause a crash when dereferenced.
> 
> I did not succeed in understanding why this occurs. Simply left clicking
> here and there can trigger the crash. Not always, but insisting long
> enough it eventually occurs.
> 
> The attached patch solves the issue for me. It is not ideal because it
> simply covers the real bug. When a user defined macro is detected, the
> value returned by d->macro_->symbol() is simply not used, as in this
> case we know what to do.
> 
> Please test if you find the time.

Please, attached find an updated patch that also accounts for latex
macros defined in ERT.

-- 
Enrico
diff --git a/src/mathed/MathMacro.cpp b/src/mathed/MathMacro.cpp
index 4529cf9..cb853a3 100644
--- a/src/mathed/MathMacro.cpp
+++ b/src/mathed/MathMacro.cpp
@@ -614,7 +614,8 @@ void MathMacro::draw(PainterInfo & pi, int x, int y) const
drawMarkers2(pi, expx, expy);
} else {
bool drawBox = lyxrc.macro_edit_style == 
LyXRC::MACRO_EDIT_INLINE_BOX;
-   bool upshape = d->macro_ && d->macro_->symbol()
+   bool user_macro = mathedWordList().find(name()) == 
mathedWordList().end();
+   bool upshape = user_macro ? false : d->macro_ && 
d->macro_->symbol()
&& d->macro_->symbol()->extra == "textmode";
Changer dummy = pi.base.font.changeShape(upshape ? UP_SHAPE
: pi.base.font.shape());
@@ -929,9 +930,10 @@ bool MathMacro::folded() const
 
 void MathMacro::write(WriteStream & os) const
 {
-   bool const textmode_macro = d->macro_ && d->macro_->symbol()
+   bool user_macro = mathedWordList().find(name()) == 
mathedWordList().end();
+   bool textmode_macro = user_macro ? false : d->macro_ && 
d->macro_->symbol()
&& d->macro_->symbol()->extra == "textmode";
-   bool const needs_mathmode = d->macro_ && (!d->macro_->symbol()
+   bool needs_mathmode = user_macro ? bool(d->macro_) : d->macro_ && 
(!d->macro_->symbol()
|| d->macro_->symbol()->extra != "textmode");
 
MathEnsurer ensurer(os, needs_mathmode, true, textmode_macro);

Track changes: copy and paste of elements with tracked changes keeps changes

[racoon]

Hi,

I'd like to hear what you think about the suggestion in 
https://www.lyx.org/trac/ticket/10278.


Today I ran into another use case. I have a document with a lot of 
tracked changes. Since it also grew over time I wanted to copy parts 
into child documents. However, this is currently not possible without 
loosing the tracked changes.


Of course rather than copy, I can remove the parts not needed and save 
the resulting document as a new child. However, this seems a bit 
cumbersome to me.


Also this is impossible if I want sometimes to go the other way around. 
If I have two different documents both of which have tracked changes and 
want to combine them (or parts of them) into one document that cannot be 
done with LyX currently.


Therefore, I suggest the enhancement according to the suggestion.

Daniel

ctests (was: Intro with PDF(luatex))

[Guenter Milde]

On 2016-09-10, Kornel Benko wrote:
> Am Samstag, 10. September 2016 um 08:03:37, schrieb Guenter Milde 
> 
>> On 2016-09-09, Kornel Benko wrote:

Dear Kornel,

>> * Can we rename "suspiciousTests" to "invertedTests", please?

> Sure. Almost alike the original name has been (revertedTests)

Fine (especially, as ctests calls the process "inversion").


>> * Do you still need the "suspendeTests"? What for?

> Yes, we need them. This tests will not be executed with the call 'ctest
> -L export'.

suspendeTests were introduced for the "less urgent" test cases like files in
the attic and export with Xe/LuaTeX and 8-bit TeX fonts when there were >100
test errors.

In the meantime, we know the particular problem for most of the suspended
tests.
Some were fixed. Others require inversion (we know the problem is a
wontfix or a bug on trac).

How many of the suspendedTests are still failing?
Do we really still need the suspension or could we lift it?

If we want to keep it, it would be important to have a way to clearly define
tests that are "suspended" AND "inverted".

Thanks
Günter

Re: Do we have a webmaster?

[Jean-Marc Lasgouttes]

Le 12/09/2016 à 05:46, Richard Heck a écrit :

On 09/11/2016 09:32 PM, Pavel Sanda wrote:

Paul A. Rubin wrote:

I can perhaps step in and do some interim
maintenance (once I get the keys to the castle).

Can you be more specific what changes you have in mind?


One: Apparently, gmane is dead, so we need to remove references to it
from the site.

I realize, finally, that since the entire website is really a wiki, the
only thing Paul
needs is the password to edit pages. Any objection?


Not from me.

JMarc

Re: Do we have a webmaster?

[Jean-Marc Lasgouttes]

Le 11/09/2016 à 19:57, Paul A. Rubin a écrit :

If Christian has been kidnapped by extraterrestrials (or, equivalently
bad, has switched to Windows 10), I can perhaps step in and do some
interim maintenance (once I get the keys to the castle). The server
seems to be a for use by students of U. Bonn (based on my extremely
limited German vocabulary), and since I don't fit that demographic, I'm
not sure if I ought to be mucking around on their systems (or how long
I'd get away with it before an diplomatic incident occurred).


Actually, the server is a virtual machine (running CentOS 6.7) hosted in 
their server. This means that we are at home there. Unfortunately our 
sysadmin (Lars) and our webmaster (Christian) are busy with other things.


JMarc

Re: [LyX/master] Test and fix lib/unicodesymbols for Letterlike Symbols, Number Forms and Arrows blocks.

[Guenter Milde]

On 2016-09-11, Scott Kostyshak wrote:

> [-- Type: text/plain, Encoding:  --]

> On Sun, Sep 11, 2016 at 06:46:47PM +, Guenter Milde wrote:

>> Could you please change the test reference accordingly?

> Done at d3c63f97.

Thank you.

I changed this in 99eeb29e5863516220eb823c2bcc276761107c41 to make the input
sample "box-color*.tex" compilable without errors and give a clean import to
LyX:

Load required package textcomp.
Replace call to non-existent packages textcyr and textgreek with the backup 
definition of the commands as done by LyX export.
Do not load marvosym (clash with pifont) (LyX does not load the package either).
Remove invalid command \\ascii.

Günter