Re: Beta1 is slow on undo

[Scott Kostyshak]

On Sun, Oct 08, 2017 at 03:01:49PM +, Richard Heck wrote:
> On 10/08/2017 10:19 AM, racoon wrote:
> > On 08.10.2017 00:19, Scott Kostyshak wrote:
> >> On Sat, Oct 07, 2017 at 05:57:48PM +, Richard Heck wrote:
> >>> On 10/07/2017 12:09 PM, racoon wrote:
>  Hi,
> 
>  I noticed that beta1 shows some slowness when undoing with some of my
>  documents. While undoing is instantaneous in 2.2.3, 2.3 takes about a
>  second to respond to it.
> 
>  Did anyone notice this? I don't have a very fast computer though.
> >>>
> >>> Yes, I have also seen that, and my machines are pretty fast.
> >>
> >> I can't reproduce. My test case was to open the user guide, selected
> >> all, delete, and undo. Both were instantaneous for me. Do you have a
> >> better test case for me?
> >
> > Okay, I think I have narrowed it down to the inclusion of any
> > bibliography. Test case attached.
> 
> That would make sense, at least in so far as bibliography handling was
> changed a lot. But it's hard to imagine why it would affect undo. Do we
> re-read the bibliography or something now after an undo?

Bisect points to 02847641. I want to emphasize though that I only see a
very minor increase in slowness. I would not have realized it if it
weren't pointed out. It is certainly not a second delay for me. So
perhaps this is not the change that Richard and racoon are seeing.

Scott


signature.asc
Description: PGP signature

Re: Beta1 is slow on undo

[Scott Kostyshak]

On Sun, Oct 08, 2017 at 02:19:19PM +, racoon wrote:
> On 08.10.2017 00:19, Scott Kostyshak wrote:
> > On Sat, Oct 07, 2017 at 05:57:48PM +, Richard Heck wrote:
> > > On 10/07/2017 12:09 PM, racoon wrote:
> > > > Hi,
> > > > 
> > > > I noticed that beta1 shows some slowness when undoing with some of my
> > > > documents. While undoing is instantaneous in 2.2.3, 2.3 takes about a
> > > > second to respond to it.
> > > > 
> > > > Did anyone notice this? I don't have a very fast computer though.
> > > 
> > > Yes, I have also seen that, and my machines are pretty fast.
> > 
> > I can't reproduce. My test case was to open the user guide, selected
> > all, delete, and undo. Both were instantaneous for me. Do you have a
> > better test case for me?
> 
> Okay, I think I have narrowed it down to the inclusion of any bibliography.
> Test case attached.

For me it is very slightly slower. Definitely not 1 second, maybe .2
seconds slower? I have no idea if this is due to differences e.g. in
compiler. I will check and try to do a bisect.

Thanks,

Scott


signature.asc
Description: PGP signature

Re: Crash from feature of reloading file changed on disk

[Richard Heck]

On 10/08/2017 02:41 PM, Scott Kostyshak wrote:
> On Sun, Oct 08, 2017 at 02:56:32PM +, Richard Heck wrote:
>> On 10/07/2017 09:30 PM, Scott Kostyshak wrote:
>>> On Sat, Oct 07, 2017 at 10:39:37PM +, Richard Heck wrote:
 On 10/07/2017 06:15 PM, Scott Kostyshak wrote:
> On Sat, Oct 07, 2017 at 02:16:39PM +, Richard Heck wrote:
>
>> Probably more for master, as there is a simpler solution for 2.3.x. But
>> it would be good
>> to test it.
> Do you have a patch for the simpler solution that I can test for 2.3.x?
 Attached.
>>> Works well in brief testing. Can someone who understand the code +1 so
>>> Richard can push to 2.3.x?
>> For what it's worth, this is super-safe. The cursor will be reset after
>> the document reloads, anyway, and it will be invalid once reload starts.
>> So any attempt to use it would be fatal.
> Thanks, please go ahead for 2.3.x.

Done, and also for master.

Richard

Re: [LyX/master] Sort the language nesting mess with polyglossia

[Jean-Pierre Chrétien]

Le 08/10/2017 à 23:26, Scott Kostyshak a écrit :

On Sun, Oct 08, 2017 at 08:59:47PM +, Jean-Pierre Chrétien wrote:

Le 08/10/2017 à 05:39, Scott Kostyshak a écrit :

On Sat, Sep 24, 2016 at 01:25:42AM +, Enrico Forestieri wrote:

commit 3bc08a76c42cd350a3141f00f37082bc9fab8967
Author: Enrico Forestieri 
Date:   Sat Sep 24 03:15:02 2016 +0200

  Sort the language nesting mess with polyglossia
  When using polyglossia, lyx was making a real mess when changing
  language inside nested insets. The \begin{language} and
  \end{language} commands were not well paired such that they could
  easily occur just before and after the start or end of an
  environment. Of course this was causing latex errors such that
  "\begin{otherlanguage} ended by \end{environment}".
  There may still be some cases I did not take into account.


It seems that the Xetex error that I get with the lettre template is of that
kind. I was about to write to the class author about this, but it seems thus
that is is a LyX bug, right?


I don't know. From what I remember lettre started failing for me after a
TeX Live update. If it were a LyX bug, I wonder why it worked before. My
memory often fails me though (or perhaps I fail it?). I think I have a
VM with an older TeX Live installation. Would it helped if I tested
whether the lettre template, as of current 2.3.x, compiles fine with
the older TeX Live installation?


I don't know, a new version of the class has been introduced in August with a 
lot of changes.


I think I will go on what I began to do here before contacting the author of the 
class: downsize to a minimal example using the examples indicated in the class 
manual to check if polyglossia simply works with lettre.cls (the LyX template 
includes a lot of preamble code to make the order of the elements in the LyX 
window irrelevant, and the error happens inside an added custom command). Last 
time I worked on this I was fighting with font encoding when I copy latex code 
from the lettre pdf manual.


--
Jean-Pierre

Re: [LyX/master] Sort the language nesting mess with polyglossia

[Scott Kostyshak]

On Sun, Oct 08, 2017 at 08:59:47PM +, Jean-Pierre Chrétien wrote:
> Le 08/10/2017 à 05:39, Scott Kostyshak a écrit :
> > On Sat, Sep 24, 2016 at 01:25:42AM +, Enrico Forestieri wrote:
> > > commit 3bc08a76c42cd350a3141f00f37082bc9fab8967
> > > Author: Enrico Forestieri 
> > > Date:   Sat Sep 24 03:15:02 2016 +0200
> > > 
> > >  Sort the language nesting mess with polyglossia
> > >  When using polyglossia, lyx was making a real mess when changing
> > >  language inside nested insets. The \begin{language} and
> > >  \end{language} commands were not well paired such that they could
> > >  easily occur just before and after the start or end of an
> > >  environment. Of course this was causing latex errors such that
> > >  "\begin{otherlanguage} ended by \end{environment}".
> > >  There may still be some cases I did not take into account.
> 
> It seems that the Xetex error that I get with the lettre template is of that
> kind. I was about to write to the class author about this, but it seems thus
> that is is a LyX bug, right?

I don't know. From what I remember lettre started failing for me after a
TeX Live update. If it were a LyX bug, I wonder why it worked before. My
memory often fails me though (or perhaps I fail it?). I think I have a
VM with an older TeX Live installation. Would it helped if I tested
whether the lettre template, as of current 2.3.x, compiles fine with
the older TeX Live installation?

Thanks for taking a look,

Scott


signature.asc
Description: PGP signature

Re: [LyX/master] Sort the language nesting mess with polyglossia

[Kornel Benko]

Am Sonntag, 8. Oktober 2017 um 22:59:47, schrieb Jean-Pierre Chrétien 

> Le 08/10/2017 à 05:39, Scott Kostyshak a écrit :
> > On Sat, Sep 24, 2016 at 01:25:42AM +, Enrico Forestieri wrote:
> >> commit 3bc08a76c42cd350a3141f00f37082bc9fab8967
> >> Author: Enrico Forestieri 
> >> Date:   Sat Sep 24 03:15:02 2016 +0200
> >>
> >>  Sort the language nesting mess with polyglossia
> >>  
> >>  When using polyglossia, lyx was making a real mess when changing
> >>  language inside nested insets. The \begin{language} and
> >>  \end{language} commands were not well paired such that they could
> >>  easily occur just before and after the start or end of an
> >>  environment. Of course this was causing latex errors such that
> >>  "\begin{otherlanguage} ended by \end{environment}".
> >>  There may still be some cases I did not take into account.
> 
> It seems that the Xetex error that I get with the lettre template is of that 
> kind. I was about to write to the class author about this, but it seems thus 
> that is is a LyX bug, right?
> 
> Here are the errors that I get;
>   LaTeX Error: \begin{otherlanguage} on input line 173 ended by \end{letter}.
>   LaTeX Error: \begin{letter} on input line 173 ended by \end{document}.
> 
> To trigger these, just load lib/templates/lettre.lyx, set 'use non-TeX fonts' 
> in 
> Document>Settings>Fonts and compile.
> 

Looks like the same as in commit 1d0794e for  es/Additional.lyx

Kornel

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

Re: [LyX/master] Sort the language nesting mess with polyglossia

[Jean-Pierre Chrétien]

Le 08/10/2017 à 05:39, Scott Kostyshak a écrit :

On Sat, Sep 24, 2016 at 01:25:42AM +, Enrico Forestieri wrote:

commit 3bc08a76c42cd350a3141f00f37082bc9fab8967
Author: Enrico Forestieri 
Date:   Sat Sep 24 03:15:02 2016 +0200

 Sort the language nesting mess with polyglossia
 
 When using polyglossia, lyx was making a real mess when changing

 language inside nested insets. The \begin{language} and
 \end{language} commands were not well paired such that they could
 easily occur just before and after the start or end of an
 environment. Of course this was causing latex errors such that
 "\begin{otherlanguage} ended by \end{environment}".
 There may still be some cases I did not take into account.


It seems that the Xetex error that I get with the lettre template is of that 
kind. I was about to write to the class author about this, but it seems thus 
that is is a LyX bug, right?


Here are the errors that I get;
 LaTeX Error: \begin{otherlanguage} on input line 173 ended by \end{letter}.
 LaTeX Error: \begin{letter} on input line 173 ended by \end{document}.

To trigger these, just load lib/templates/lettre.lyx, set 'use non-TeX fonts' in 
Document>Settings>Fonts and compile.


--
Jean-Pierre

Re: [LyX/master] Sort the language nesting mess with polyglossia

[Jean-Pierre Chrétien]

Le 08/10/2017 à 05:39, Scott Kostyshak a écrit :



Attached also is the XeTeX code that LyX writes for this file. The
problem is here:

\begin{english}%
\item[\(\star\)}]  \textfrench{Agissez sur chaque entrée...}
\end{english}%

 From what I can tell, the problem is the curly brace after "(\star\)".

Current 2.3.x produces a different LaTeX file (I attach this .tex file
also). There are two notable differences compared to the .tex file
created from this commit. For one, the package xunicode is no longer
loaded in current 2.3.x. And second, there is no longer a
"\end{english}", which causes an error even if the curly brace
referenced above is removed.

I created the attached .lyx MWE from the 2.3.x branch fr/Additional.lyx.
ctests started failing recently on that file (probably after we copied
some new English into it to be translated?). I don't know how that part
of fr/Additional.lyx was created. Perhaps the problem is in the the
creation of the file, not the parsing?


It's me who copied this piece of code from original English Additional.lyx file.
If I look at the current version of fr/Additional.lyx in master I see this:


\selectlanguage{english}%
\item[\foreignlanguage{english}{\(\star\)}]  \foreignlanguage{french}{Agissez 
sur chaque entrée individuellement

en écrivant le motif de la puce }in a ``Custom Item'' inset (available
at \textsf{Insert\lyxarrow Custom Item})\foreignlanguage{french}{


Could that unclosed
\selectlanguage{english}%
command which could be responsible of the extra }?
--
Jean-Pierre

Re: additional manual - link correction for elyxer

[Pavel Sanda]

Uwe Stöhr wrote:
> Yes. Our HTML export is still not usable. I opened some bug reports:
> http://www.lyx.org/trac/query?status=accepted=assigned=new=reopened=~html=~uwestoehr=id=summary=reporter=status=type=severity=keywords=reporter

I see. So we will wait for a little more until elyxer chokes completely ;)
P

Re: [LyX/master] Add Qt-based fallback-converter for Mac to compensate missing ImageMagick convert utility

[Pavel Sanda]

Stephan Witt wrote:
> > Would you mind to put here couple lines wit description and syntax? Thanks, 
> > Pavel
> 
> I???ve changed it to match the style of all other c++ sources.
> 
> Did you have more in mind? If you did, please give me a hint
> what doxygen keywords I should use??? thanks.

Honestly I do not care about doxygen header.
I just meant if I bump into this code I would like to know what is it for
and how to use it, i.e. syntax for the output binary... Pavel

Re: Failures of seminar example file

[Scott Kostyshak]

On Sun, Oct 08, 2017 at 08:41:39AM +, Guenter Milde wrote:
> On 2017-10-08, Scott Kostyshak wrote:
> 
> > After at tlmgr update, I now get the following:
> 
> > $ ctest -R "seminar"
> 
> > I get "20 tests failed out of 33":
> 
> > 3631 - UNRELIABLE.WRONG_OUTPUT_export/examples/seminar_dvi (Failed)
> ...
> > 5025 - UNRELIABLE.WRONG_OUTPUT_export/examples/fr/seminar_pdf5_systemF 
> > (Failed)
> 
> > Before the tlmgr update, I did not have any failures. The tests are
> > marked as unreliable, so perhaps this change in behavior should not be a
> > surprise? I might not be so surprised if a few formats failed, but it
> > seems that all exports to PDF fail.
> 
> It seems that all exports using LaTeX fail (also DVI and Postscript).
> It would be interesting to see the reason (log) but I cannot reproduce with
> my Debian/stable texlive.

Kornel could reproduce and figured out it's because of an update to
pstricks.

> I added a new clause in unreliable:varying-versions.

> The comment is imprecise. While DVI and ps2pdf are the export formats with
> most problems, no export format works reliably in all use cases.
> On the other hand, all export formats have use cases that work if the
> correct settings are used. 
>   The Appendix in examples/seminar.lyx lists details for on-screen viewing
> vs. printing of landscape slides, portrait slides, and notes.
> 
> I changed the comment but we may also just remove the clause from
> unreliable:wrong-output.

Thanks,

Scott


signature.asc
Description: PGP signature

Re: Crash from feature of reloading file changed on disk

[Scott Kostyshak]

On Sun, Oct 08, 2017 at 02:56:32PM +, Richard Heck wrote:
> On 10/07/2017 09:30 PM, Scott Kostyshak wrote:
> > On Sat, Oct 07, 2017 at 10:39:37PM +, Richard Heck wrote:
> >> On 10/07/2017 06:15 PM, Scott Kostyshak wrote:
> >>> On Sat, Oct 07, 2017 at 02:16:39PM +, Richard Heck wrote:
> >>>
>  Probably more for master, as there is a simpler solution for 2.3.x. But
>  it would be good
>  to test it.
> >>> Do you have a patch for the simpler solution that I can test for 2.3.x?
> >> Attached.
> > Works well in brief testing. Can someone who understand the code +1 so
> > Richard can push to 2.3.x?
> 
> For what it's worth, this is super-safe. The cursor will be reset after
> the document reloads, anyway, and it will be invalid once reload starts.
> So any attempt to use it would be fatal.

Thanks, please go ahead for 2.3.x.

Scott


signature.asc
Description: PGP signature

Re: [LyX/master] Sort the language nesting mess with polyglossia

[Scott Kostyshak]

On Sun, Oct 08, 2017 at 12:48:36PM +, Enrico Forestieri wrote:

> Thanks Scott. I'll have a look when I find some time. This kind of bugs
> can be very time consuming.

Thanks, there is no rush and I don't consider this a blocker for 2.3.0.

Scott


signature.asc
Description: PGP signature

Re: Failures of seminar example file

[Scott Kostyshak]

On Sun, Oct 08, 2017 at 10:59:45AM +, Kornel Benko wrote:
> Am Sonntag, 8. Oktober 2017 um 12:03:14, schrieb Kornel Benko 
> > Am Sonntag, 8. Oktober 2017 um 08:41:39, schrieb Guenter Milde 
> > 
> > > On 2017-10-08, Scott Kostyshak wrote:
> > > 
> > > > After at tlmgr update, I now get the following:
> > > 
> > > > $ ctest -R "seminar"
> > > 
> > > > I get "20 tests failed out of 33":
> 
> ...
> 
> Restoring previous version of pstricks made the tests OK.
>   # tlmgr restore pstricks 45127

Good to know! Thanks for checking that.

Scott


signature.asc
Description: PGP signature

Re: Uninvert tests fixed by #8823 fix

[Scott Kostyshak]

On Sun, Oct 08, 2017 at 06:49:14AM +, Kornel Benko wrote:

> After the commit 9f5f4e2, I see the same behaviour as you. The strange error 
> I saw was with
> having LANG set to 'en' and LC_ALL to 'C'.
> The list of valid LANG values on my system (output of 'locale -a') did not 
> include 'en'. This _may_ have been the root
> of the different behaviour.

Ah that's good that the mystery seems possibly figured out. Thanks,

Scott


signature.asc
Description: PGP signature

Re: LyX-Workarea: Background not shown correctly

[pdv]

On 17/09/2017 19:48, Stephan Witt wrote:

Hi JMarc,

another problem I’ve seen: after running view-pdflatex e.g.
the work area doesn’t show correct background color.

Stephan


The new code contains twice a viewport()->update() without specification 
of a rectangle. Since > Qt normally erases the widget's area before the 
paintEvent() call
I guess that the whole viewport is erased. Subsequently only part of it 
is redrawn except for the case FullScreenUpdate and in that case there 
is no problem.


P. De Visschere

Re: [LyX/master] Add Qt-based fallback-converter for Mac to compensate missing ImageMagick convert utility

[Stephan Witt]

Am 05.10.2017 um 13:40 schrieb Pavel Sanda :
> 
> Stephan Witt wrote:
>> commit f93ec4a1f41b70a4607ff355e19f4721f9338028
>> Author: Stephan Witt 
>> Date:   Sat Sep 30 18:13:21 2017 +0200
>> 
>>Add Qt-based fallback-converter for Mac to compensate missing ImageMagick 
>> convert utility
>> ---
>> Makefile.am   |2 +-
>> configure.ac  |1 +
>> development/LyX-Mac-binary-release.sh |4 +-
>> lib/scripts/convertDefault.py |   16 +++-
>> src/Makefile.am   |2 +-
>> src/convert/Makefile.am   |   32 +++
>> src/convert/lyxconvert.cpp|  145 
>> +
>> 7 files changed, 195 insertions(+), 7 deletions(-)
>> 
>> --- /dev/null
>> +++ b/src/convert/lyxconvert.cpp
>> @@ -0,0 +1,145 @@
>> +/*
>> +set cflags=`env PKG_CONFIG_PATH=/usr/local/qt5/lib/pkgconfig pkg-config 
>> --cflags Qt5Widgets`
>> +set libs=`env PKG_CONFIG_PATH=/usr/local/qt5/lib/pkgconfig pkg-config 
>> --libs --static Qt5Widgets`
>> +g++ -std=gnu++11 $cflags lyxconvert.cpp -o lyxconvert $libs
>> +*/
> 
> Would you mind to put here couple lines wit description and syntax? Thanks, 
> Pavel

I’ve changed it to match the style of all other c++ sources.

Did you have more in mind? If you did, please give me a hint
what doxygen keywords I should use… thanks.

Stephan

[PATCH] to avoid crash in misspelled marker painting while deleting table rows fast

[Stephan Witt]

Hi,

these days I’ve got a crash while deleting multiple rows from a table with 
bottom table toolbar quickly.
This happened with LyX 2.2. - I can reproduce it with master.

I’m attaching the crash report and a patch to avoid the crash. I’d like to put 
it in and if possible backport it to 2.3.x at least. Ok?

Stephan



crash-in-table-redraw.patch
Description: Binary data
Process:   lyx [88991]
Path:  /Applications/LyX.app/Contents/MacOS/lyx
Identifier:org.lyx.lyx
Version:   2.2.2 (???)
Code Type: X86-64 (Native)
Parent Process:??? [1]
Responsible:   lyx [88991]
User ID:   501

Date/Time: 2017-10-05 21:48:29.913 +0200
OS Version:Mac OS X 10.11.6 (15G1611)
Report Version:11
Anonymous UUID:EDBFDA39-668B-1773-9AF4-1A076C7F386B

Sleep/Wake UUID:   8B20952D-358E-46BB-A1FF-E6EBDCF13EB8

Time Awake Since Boot: 32 seconds
Time Since Wake:   3300 seconds

System Integrity Protection: enabled

Crashed Thread:0  Dispatch queue: com.apple.main-thread

Exception Type:EXC_BAD_ACCESS (SIGABRT)
Exception Codes:   KERN_INVALID_ADDRESS at 0x0020
Exception Note:EXC_CORPSE_NOTIFY

VM Regions Near 0x20:
--> 
__TEXT 0001082cc000-000108ef9000 [ 12.2M] r-x/rwx 
SM=COW  /Applications/LyX.app/Contents/MacOS/lyx

Application Specific Information:
abort() called

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib  0x7fff9438af06 __pthread_kill + 10
1   libsystem_pthread.dylib 0x7fff945714ec pthread_kill + 90
2   libsystem_c.dylib   0x7fff902716df abort + 129
3   org.lyx.lyx 0x0001083df96e 
lyx::error_handler(int) + 866
4   libsystem_platform.dylib0x7fff990cd52a _sigtramp + 26
5   ??? 0x0022 0 + 34
6   org.lyx.lyx 0x00010837a0c0 
lyx::DocIterator::paragraph() const + 166
7   org.lyx.lyx 0x00010843f9d2 
lyx::RowPainter::paintMisspelledMark(double, lyx::Row::Element const&) const + 
218
8   org.lyx.lyx 0x00010844127c 
lyx::RowPainter::paintText() + 316
9   org.lyx.lyx 0x00010848768e 
lyx::TextMetrics::drawParagraph(lyx::PainterInfo&, long, int, int) const + 2382
10  org.lyx.lyx 0x000108486d05 
lyx::TextMetrics::draw(lyx::PainterInfo&, int, int) const + 121
11  org.lyx.lyx 0x00010861dc54 
lyx::InsetText::draw(lyx::PainterInfo&, int, int) const + 326
12  org.lyx.lyx 0x00010860d21b 
lyx::InsetTabular::draw(lyx::PainterInfo&, int, int) const + 567
13  org.lyx.lyx 0x00010843f745 
lyx::RowPainter::paintInset(lyx::Inset const*, lyx::Font const&, lyx::Change 
const&, long) + 541
14  org.lyx.lyx 0x0001084412dd 
lyx::RowPainter::paintText() + 413
15  org.lyx.lyx 0x00010848768e 
lyx::TextMetrics::drawParagraph(lyx::PainterInfo&, long, int, int) const + 2382
16  org.lyx.lyx 0x000108486d05 
lyx::TextMetrics::draw(lyx::PainterInfo&, int, int) const + 121
17  org.lyx.lyx 0x0001083483be 
lyx::BufferView::draw(lyx::frontend::Painter&) + 678
18  org.lyx.lyx 0x00010880afd6 
lyx::frontend::GuiWorkArea::Private::updateScreen() + 76
19  org.lyx.lyx 0x00010880aed9 
lyx::frontend::GuiWorkArea::redraw(bool) + 275
20  org.lyx.lyx 0x000108629933 
lyx::frontend::WorkAreaManager::redrawAll(bool) + 39
21  org.lyx.lyx 0x00010833af41 
lyx::BufferView::processUpdateFlags(lyx::Update::flags) + 385
22  org.lyx.lyx 0x00010864ede9 
lyx::frontend::GuiApplication::updateCurrentView(lyx::FuncRequest const&, 
lyx::DispatchResult&) + 147
23  org.lyx.lyx 0x00010864ecc2 
lyx::frontend::GuiApplication::dispatch(lyx::FuncRequest const&) + 198
24  org.lyx.lyx 0x00010864f463 non-virtual thunk to 
lyx::frontend::GuiApplication::dispatch(lyx::FuncRequest const&) + 13
25  org.lyx.lyx 0x0001083df393 
lyx::dispatch(lyx::FuncRequest const&) + 86
26  org.lyx.lyx 0x00010862c692 
lyx::frontend::Action::qt_static_metacall(QObject*, QMetaObject::Call, int, 
void**) + 154
27  org.qt-project.QtCore   0x000109838b4c 
QMetaObject::activate(QObject*, int, int, void**) + 3020
28  org.qt-project.QtWidgets0x000109ccc3d7 
QAction::activate(QAction::ActionEvent) + 263
29  org.qt-project.QtWidgets0x000109dc3d29 
QAbstractButtonPrivate::click() + 137
30  org.qt-project.QtWidgets

Re: Beta1 is slow on undo

[racoon]

On 08.10.2017 16:19, racoon wrote:

On 08.10.2017 00:19, Scott Kostyshak wrote:

On Sat, Oct 07, 2017 at 05:57:48PM +, Richard Heck wrote:

On 10/07/2017 12:09 PM, racoon wrote:

Hi,

I noticed that beta1 shows some slowness when undoing with some of my
documents. While undoing is instantaneous in 2.2.3, 2.3 takes about a
second to respond to it.

Did anyone notice this? I don't have a very fast computer though.


Yes, I have also seen that, and my machines are pretty fast.


I can't reproduce. My test case was to open the user guide, selected
all, delete, and undo. Both were instantaneous for me. Do you have a
better test case for me?


Okay, I think I have narrowed it down to the inclusion of any 
bibliography. Test case attached.


I just wanted to add that, at least on my slow machine, this delay is a 
bit annoying since sometimes I am not sure whether the undo was done and 
execute it again leaving me with uncertainty what exactly was undone. So 
I have to go back and forth in the undo sequence to figure out where I 
am in it.

Re: Beta1 is slow on undo

[Richard Heck]

On 10/08/2017 10:19 AM, racoon wrote:
> On 08.10.2017 00:19, Scott Kostyshak wrote:
>> On Sat, Oct 07, 2017 at 05:57:48PM +, Richard Heck wrote:
>>> On 10/07/2017 12:09 PM, racoon wrote:
 Hi,

 I noticed that beta1 shows some slowness when undoing with some of my
 documents. While undoing is instantaneous in 2.2.3, 2.3 takes about a
 second to respond to it.

 Did anyone notice this? I don't have a very fast computer though.
>>>
>>> Yes, I have also seen that, and my machines are pretty fast.
>>
>> I can't reproduce. My test case was to open the user guide, selected
>> all, delete, and undo. Both were instantaneous for me. Do you have a
>> better test case for me?
>
> Okay, I think I have narrowed it down to the inclusion of any
> bibliography. Test case attached.

That would make sense, at least in so far as bibliography handling was
changed a lot. But it's hard to imagine why it would affect undo. Do we
re-read the bibliography or something now after an undo?

Richard

Re: Crash from feature of reloading file changed on disk

[Richard Heck]

On 10/07/2017 09:30 PM, Scott Kostyshak wrote:
> On Sat, Oct 07, 2017 at 10:39:37PM +, Richard Heck wrote:
>> On 10/07/2017 06:15 PM, Scott Kostyshak wrote:
>>> On Sat, Oct 07, 2017 at 02:16:39PM +, Richard Heck wrote:
>>>
 Probably more for master, as there is a simpler solution for 2.3.x. But
 it would be good
 to test it.
>>> Do you have a patch for the simpler solution that I can test for 2.3.x?
>> Attached.
> Works well in brief testing. Can someone who understand the code +1 so
> Richard can push to 2.3.x?

For what it's worth, this is super-safe. The cursor will be reset after
the document reloads, anyway, and it will be invalid once reload starts.
So any attempt to use it would be fatal.

For that reason, I think we should probably do this here even if we also
commit the other patch. Any other cursors that might be attached to
other BufferViews will also be invalid, but I'm not sure how to find
them, and presumably they won't matter so much.

Richard

Re: Beta1 is slow on undo

[racoon]

On 08.10.2017 00:19, Scott Kostyshak wrote:

On Sat, Oct 07, 2017 at 05:57:48PM +, Richard Heck wrote:

On 10/07/2017 12:09 PM, racoon wrote:

Hi,

I noticed that beta1 shows some slowness when undoing with some of my
documents. While undoing is instantaneous in 2.2.3, 2.3 takes about a
second to respond to it.

Did anyone notice this? I don't have a very fast computer though.


Yes, I have also seen that, and my machines are pretty fast.


I can't reproduce. My test case was to open the user guide, selected
all, delete, and undo. Both were instantaneous for me. Do you have a
better test case for me?


Okay, I think I have narrowed it down to the inclusion of any 
bibliography. Test case attached.




test_undo_2.3.lyx
Description: application/lyx

Re: Beta1 is slow on undo

[racoon]

On 08.10.2017 00:19, Scott Kostyshak wrote:

On Sat, Oct 07, 2017 at 05:57:48PM +, Richard Heck wrote:

On 10/07/2017 12:09 PM, racoon wrote:

Hi,

I noticed that beta1 shows some slowness when undoing with some of my
documents. While undoing is instantaneous in 2.2.3, 2.3 takes about a
second to respond to it.

Did anyone notice this? I don't have a very fast computer though.


Yes, I have also seen that, and my machines are pretty fast.


I can't reproduce. My test case was to open the user guide, selected
all, delete, and undo. Both were instantaneous for me. Do you have a
better test case for me?


Yes, those documents are fine at my side as well. I'll try to send a 
test case soon.

Re: [LyX/master] Sort the language nesting mess with polyglossia

[Enrico Forestieri]

On Sat, Oct 07, 2017 at 11:39:39PM -0400, Scott Kostyshak wrote:

> On Sat, Sep 24, 2016 at 01:25:42AM +, Enrico Forestieri wrote:
> > commit 3bc08a76c42cd350a3141f00f37082bc9fab8967
> > Author: Enrico Forestieri 
> > Date:   Sat Sep 24 03:15:02 2016 +0200
> > 
> > Sort the language nesting mess with polyglossia
> > 
> > When using polyglossia, lyx was making a real mess when changing
> > language inside nested insets. The \begin{language} and
> > \end{language} commands were not well paired such that they could
> > easily occur just before and after the start or end of an
> > environment. Of course this was causing latex errors such that
> > "\begin{otherlanguage} ended by \end{environment}".
> > There may still be some cases I did not take into account.
> 
> A git bisect suggests this caused a change in behavior. The attached
> .lyx file fails to compile to XeTeX or LuaTeX starting with this commit.
> 
> Attached also is the XeTeX code that LyX writes for this file. The
> problem is here:
> 
> \begin{english}%
> \item[\(\star\)}]  \textfrench{Agissez sur chaque entrée...}
> \end{english}%
> 
> From what I can tell, the problem is the curly brace after "(\star\)".
> 
> Current 2.3.x produces a different LaTeX file (I attach this .tex file
> also). There are two notable differences compared to the .tex file
> created from this commit. For one, the package xunicode is no longer
> loaded in current 2.3.x. And second, there is no longer a
> "\end{english}", which causes an error even if the curly brace
> referenced above is removed.
> 
> I created the attached .lyx MWE from the 2.3.x branch fr/Additional.lyx.
> ctests started failing recently on that file (probably after we copied
> some new English into it to be translated?). I don't know how that part
> of fr/Additional.lyx was created. Perhaps the problem is in the the
> creation of the file, not the parsing?
> 
> Enrico, thanks a lot for tackling these language nesting issues. The
> only thing I understand from this code is that it is very complex and
> fragile. Let me know if you want me to run the ctests on a potential
> patch.
> 
> I'm open to whatever you suggest for 2.3.0. If this code is so fragile
> that you suggest we leave it as it is, that's fine with me. 2.3.x is
> already in a much better state as far as language nesting, compared to
> 2.2.0, thanks to your work.

Thanks Scott. I'll have a look when I find some time. This kind of bugs
can be very time consuming.

-- 
Enrico

Re: Failures of seminar example file

[Kornel Benko]

Am Sonntag, 8. Oktober 2017 um 12:03:14, schrieb Kornel Benko 
> Am Sonntag, 8. Oktober 2017 um 08:41:39, schrieb Guenter Milde 
> 
> > On 2017-10-08, Scott Kostyshak wrote:
> > 
> > > After at tlmgr update, I now get the following:
> > 
> > > $ ctest -R "seminar"
> > 
> > > I get "20 tests failed out of 33":

...

Restoring previous version of pstricks made the tests OK.
# tlmgr restore pstricks 45127

Kornel

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

Re: Failures of seminar example file

[Kornel Benko]

Am Sonntag, 8. Oktober 2017 um 08:41:39, schrieb Guenter Milde 

> On 2017-10-08, Scott Kostyshak wrote:
> 
> > After at tlmgr update, I now get the following:
> 
> > $ ctest -R "seminar"
> 
> > I get "20 tests failed out of 33":
> 
> > 3631 - UNRELIABLE.WRONG_OUTPUT_export/examples/seminar_dvi (Failed)
> ...
> > 5025 - UNRELIABLE.WRONG_OUTPUT_export/examples/fr/seminar_pdf5_systemF 
> > (Failed)
> 
> > Before the tlmgr update, I did not have any failures. The tests are
> > marked as unreliable, so perhaps this change in behavior should not be a
> > surprise? I might not be so surprised if a few formats failed, but it
> > seems that all exports to PDF fail.
> 
> It seems that all exports using LaTeX fail (also DVI and Postscript).
> It would be interesting to see the reason (log) but I cannot reproduce with
> my Debian/stable texlive.

I see the same as Scott; Tested first with non-updated TL, everything pass.
Updated, now all 'seminar_[pd]' tests fail.

I see many messages in the log (creating pdf2)
Missing character: There is no 0 in font nullfont!
but also the following:
! Undefined control sequence.
l.2805 \ifpst@psfonts
 
The control sequence at the end of the top line
of your error message was never \def'ed. If you have
misspelled it (e.g., `\hobx'), type `I' and the correct
spelling (e.g., `I\hbox'). Otherwise just continue,
and I'll forget about whatever was undefined.

! Extra \else.
l.2807 \else

I'm ignoring this; it doesn't match any \if.

\everypsbox=\toks27
\psframesep=\dimen135
\pslabelsep=\dimen136
\sh@wgridXunit=\dimen137
\sh@wgridYunit=\dimen138
\pst@shift=\dimen139
)
! Extra \fi.

This line is in 
/usr/local/texlive/2017/texmf-dist/tex/generic/pstricks/pstricks.tex
The command \ifpst@psfonts is defined in pstricks/pricks-tex.def with comment 
that
it is defined in pstricks.sty, but there it is not defined.
Could not find the use or the definition of this command in TL16.

> I added a new clause in unreliable:varying-versions.
> 
> > Also, our entry in unreliableTests is:
> 
> > # seminar.sty uses Postscript specials or PGF
> > # -> wrong output with DVI and PDF (ps2pdf) (de-placed landscape
> > # slides).
> > export/examples/(|fr/)seminar_(dvi|pdf).*
> 
> > The comment makes me think that we only expect wrong output with DVI and
> > PDF (ps2pdf). Am I interpreting that wrong or should we remove the ".*"
> > at the end of that pattern?
> 
> The comment is imprecise. While DVI and ps2pdf are the export formats with
> most problems, no export format works reliably in all use cases.
> On the other hand, all export formats have use cases that work if the
> correct settings are used. 
>   The Appendix in examples/seminar.lyx lists details for on-screen viewing
> vs. printing of landscape slides, portrait slides, and notes.
> 
> I changed the comment but we may also just remove the clause from
> unreliable:wrong-output.
> 
> Günter

Kornel

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

Re: additional manual - link correction for elyxer

[Uwe Stöhr]

Am 07.10.2017 um 14:19 schrieb Pavel Sanda:

Uwe, do we still ship elyxer by default in windows > If yes, is there still some major bug why we can't use our internal 

HTML export?

Yes. Our HTML export is still not usable. I opened some bug reports:
http://www.lyx.org/trac/query?status=accepted=assigned=new=reopened=~html=~uwestoehr=id=summary=reporter=status=type=severity=keywords=reporter

The major issue is the handling of floats.
I also wrote in my bug reports that we should use eLyXers's code for the 
float, table and image handling etc. because this code is the result of 
a joint work of dozens of people.

Our HTML has also issues with footnotes, colors etc, that eLyXer has not:
http://www.lyx.org/trac/query?status=accepted=assigned=new=reopened=~=~html=id=summary=reporter=status=type=severity=keywords=id

As it is eLyXer delivers still a much nicer and readable HTML output. 
(Personally, I therefore still use only eLyXer for my private 
documents.) I see that eLyXer falls a bit behind with special features 
but I miss progress in our own HTML handling for basic things like 
floats, images and tables.


regards Uwe

Re: Failures of seminar example file

[Guenter Milde]

On 2017-10-08, Scott Kostyshak wrote:

> After at tlmgr update, I now get the following:

> $ ctest -R "seminar"

> I get "20 tests failed out of 33":

> 3631 - UNRELIABLE.WRONG_OUTPUT_export/examples/seminar_dvi (Failed)
...
> 5025 - UNRELIABLE.WRONG_OUTPUT_export/examples/fr/seminar_pdf5_systemF 
> (Failed)

> Before the tlmgr update, I did not have any failures. The tests are
> marked as unreliable, so perhaps this change in behavior should not be a
> surprise? I might not be so surprised if a few formats failed, but it
> seems that all exports to PDF fail.

It seems that all exports using LaTeX fail (also DVI and Postscript).
It would be interesting to see the reason (log) but I cannot reproduce with
my Debian/stable texlive.

I added a new clause in unreliable:varying-versions.

> Also, our entry in unreliableTests is:

> # seminar.sty uses Postscript specials or PGF
> # -> wrong output with DVI and PDF (ps2pdf) (de-placed landscape
> # slides).
> export/examples/(|fr/)seminar_(dvi|pdf).*

> The comment makes me think that we only expect wrong output with DVI and
> PDF (ps2pdf). Am I interpreting that wrong or should we remove the ".*"
> at the end of that pattern?

The comment is imprecise. While DVI and ps2pdf are the export formats with
most problems, no export format works reliably in all use cases.
On the other hand, all export formats have use cases that work if the
correct settings are used. 
  The Appendix in examples/seminar.lyx lists details for on-screen viewing
vs. printing of landscape slides, portrait slides, and notes.

I changed the comment but we may also just remove the clause from
unreliable:wrong-output.

Günter

Re: Bad Math Display Regression in 2.3.x

[Jean-Marc Lasgouttes]

Le 8 octobre 2017 03:31:18 GMT+02:00, Scott Kostyshak  a 
écrit :
>On Sat, Oct 07, 2017 at 10:14:26PM +, Scott Kostyshak wrote:
>
>> I will compile newest master later.
>
>Tested latest master and I still see the issue.
>
>Scott

The bisect is probably enough for me to find the bug (he said confidently).

JMarc

Re: [LyX/master] Cmake build: Needed variable for creation of debian package

[Kornel Benko]

Am Samstag, 7. Oktober 2017 um 18:15:51, schrieb Scott Kostyshak 

> On Sat, Oct 07, 2017 at 09:31:01AM +, Kornel Benko wrote:
> > Am Samstag, 7. Oktober 2017 um 10:56:27, schrieb Kornel Benko 
> > 
> > > commit 847c68960a8227c344ec6c0d66034d012bb9de5c
> > > Author: Kornel Benko 
> > > Date:   Sat Oct 7 10:47:17 2017 +0200
> > > 
> > > Cmake build: Needed variable for creation of debian package
> > > 
> > > The variable CPACK_DEBIAN_PACKAGE_RELEASE has to be in the form
> > > of "^[A-Za-z0-9.+~]+$". We will use the abbreviated commit revision 
> > > for now.
> > > Without this change cmake 3.10 emits error.
> > 
> > Candidate for 2.3.x.
> 
> Go ahead (unless you prefer to wait). Thanks,
> 
> Scott

Done at 11386f4.

Kornel

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

Re: Uninvert tests fixed by #8823 fix

[Kornel Benko]

Am Samstag, 7. Oktober 2017 um 22:42:43, schrieb Scott Kostyshak 

> On Sat, Oct 07, 2017 at 07:57:10AM +, Kornel Benko wrote:
> > Am Samstag, 7. Oktober 2017 um 01:09:23, schrieb Scott Kostyshak 
> > 
> > > On Mon, Oct 02, 2017 at 08:07:49AM +, Kornel Benko wrote:
> > > 
> > > > 
> > > > Actually, there is a difference in environment. While running ctest, we 
> > > > set "LC_ALL=C". With this setting
> > > > I get the error also on manual call.
> > > > E.g.
> > > > 1. set in preferences
> > > > \use_converter_needauth_forbidden false
> > > > \use_converter_needauth false
> > > > 2. cd $top_src_dir
> > > > 3. setenv LC_ALL C
> > > > 4. lyx2.4 -e pdf lib/examples/ja/sweave.lyx
> > > > 
> > > > Kornel
> > > 
> > > Should I push the patch at the beginning of this thread? We can then
> > > figure out what to do with this one particular test (e.g. whether to
> > > mark it as unreliable).
> > 
> > Yes please.
> 
> Done in master at 0c7e5c11 and in 2.3.x at 7ea92108.
> 
> Let me know if you want me to test something (e.g. changing local) for
> the sweave test.
> 
> Thanks,
> 
> Scott

After the commit 9f5f4e2, I see the same behaviour as you. The strange error I 
saw was with
having LANG set to 'en' and LC_ALL to 'C'.
The list of valid LANG values on my system (output of 'locale -a') did not 
include 'en'. This _may_ have been the root
of the different behaviour.

(ATM, we don't set LC_ALL, and LANG is set to 'en_US.UTF-8')

Kornel

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