Re: Beta1 is slow on undo
Am Montag, den 16.10.2017, 14:58 -0400 schrieb Richard Heck: > Without profiling, it would be hard to know for sure, but I'd guess > it > was worth it. Certainly > re-reading huge files over a high-latency connection could slow > things down. By subjective measure, it is noticeable with several insets that include the same (big) BibTeX file. Jürgen > > Richard > > signature.asc Description: This is a digitally signed message part
Re: LyX very slow to end (master)
On Mon, Oct 16, 2017 at 03:07:28PM +, Jean-Marc Lasgouttes wrote: > Le 16/10/2017 à 16:08, Pavel Sanda a écrit : > > Just trying dirty patch for caching settings inside GuiToolbar::saveSession > > instead of creating new local var for each fun entry shows that I get quit > > time around 1s. > > Quick check shows that most of remaining time is spent in DialogPtr > > saveSession > > loop again in saveUISettings; likely the same issue. > > > > The cache idea might need some refinement because I do not know what all > > entry points to saveSession() are and if having single instance throughout > > the whole session is correct or needs refresh. I won't have time to > > investigate > > more ATM. > > Good catch. A solution is porbably to instantiate a QSettings in > saveUISettings and pass it as parameter of the various saveSession() > methods. I wonoder if this is related to #9734. Enrico noted there [1] that with Qt 5.5.0, LyX is slower to quit. Scott [1] http://www.lyx.org/trac/ticket/9734#comment:5 signature.asc Description: PGP signature
Re: Windows: bring window to front
On Mon, Oct 16, 2017 at 01:09:34PM +, racoon wrote: > Hi, > > Is the patch for http://www.lyx.org/trac/ticket/10469 already in beta1? If > so, it seems not to work. If not, maybe it can make it to rc1? The patch is in beta1. If the feature doesn't work, then that means the fix didn't work for you. Scott signature.asc Description: PGP signature
Build failed in Jenkins: Build branch "master" » ubuntu-latest-qt5-cmake #435
https://ci.inria.fr/lyx/job/build-master-head/job/ubuntu-latest-qt5-cmake/435/-- [...truncated 172 lines...] -- Looking for _getpid - not found -- Looking for gettext -- Looking for gettext - found -- Looking for getuid -- Looking for getuid - found -- Looking for lstat -- Looking for lstat - found -- Looking for lockf -- Looking for lockf - found -- Looking for mempcpy -- Looking for mempcpy - found -- Looking for mkdir -- Looking for mkdir - found -- Looking for _mkdir -- Looking for _mkdir - not found -- Looking for mkfifo -- Looking for mkfifo - found -- Looking for open -- Looking for open - found -- Looking for _open -- Looking for _open - not found -- Looking for pclose -- Looking for pclose - found -- Looking for _pclose -- Looking for _pclose - not found -- Looking for popen -- Looking for popen - found -- Looking for _popen -- Looking for _popen - not found -- Looking for putenv -- Looking for putenv - found -- Looking for readlink -- Looking for readlink - found -- Looking for setenv -- Looking for setenv - found -- Looking for setlocale -- Looking for setlocale - found -- Looking for strcasecmp -- Looking for strcasecmp - found -- Looking for stpcpy -- Looking for stpcpy - found -- Looking for strdup -- Looking for strdup - found -- Looking for strerror -- Looking for strerror - found -- Looking for strtoul -- Looking for strtoul - found -- Looking for tsearch -- Looking for tsearch - found -- Looking for unsetenv -- Looking for unsetenv - found -- Looking for wcslen -- Looking for wcslen - found -- Looking for alloca -- Looking for alloca - not found -- Looking for asprintf -- Looking for asprintf - not found -- Looking for wprintf -- Looking for wprintf - not found -- Looking for snprintf -- Looking for snprintf - found -- Looking for printf -- Looking for printf - found -- Looking for pid_t -- Looking for pid_t - not found -- Looking for intmax_t -- Looking for intmax_t - not found -- Looking for uintmax_t -- Looking for uintmax_t - not found -- Looking for LC_MESSAGES -- Looking for LC_MESSAGES - found -- Looking for PATH_MAX -- Looking for PATH_MAX - found -- Check size of intmax_t -- Check size of intmax_t - done -- Check size of long double -- Check size of long double - done -- Check size of long long -- Check size of long long - done -- Check size of wchar_t -- Check size of wchar_t - done -- Check size of wint_t -- Check size of wint_t - failed -- Performing Test HAVE_ICONV_CONST -- Performing Test HAVE_ICONV_CONST - Failed -- Performing Test SIZEOF_WCHAR_T_IS_2 -- Performing Test SIZEOF_WCHAR_T_IS_2 - Failed -- Performing Test SIZEOF_WCHAR_T_IS_4 -- Performing Test SIZEOF_WCHAR_T_IS_4 - Success -- Performing Test SIZEOF_LONG_LONG_GREATER_THAN_SIZEOF_LONG -- Performing Test SIZEOF_LONG_LONG_GREATER_THAN_SIZEOF_LONG - Failed -- Performing Test LYX_CALLSTACK_PRINTING -- Performing Test LYX_CALLSTACK_PRINTING - Success -- Performing Test lyx_cv_lib_stdcxx -- Performing Test lyx_cv_lib_stdcxx - Success -- Performing Test USE_GLIBCXX_CXX11_ABI -- Performing Test USE_GLIBCXX_CXX11_ABI - Success -- Performing Test lyx_cv_prog_clang -- Performing Test lyx_cv_prog_clang - Failed -- Performing Test HAVE_DEF_MAKE_UNIQUE -- Performing Test HAVE_DEF_MAKE_UNIQUE - Success -- Performing Test LYX_USE_STD_CALL_ONCE -- Performing Test LYX_USE_STD_CALL_ONCE - Success -- Looking for C++ include QtGui/qtgui-config.h -- Looking for C++ include QtGui/qtgui-config.h - not found -- Performing Test QT_USES_X11 -- Performing Test QT_USES_X11 - Success -- Looking for XOpenDisplay in /usr/lib/x86_64-linux-gnu/libX11.so;/usr/lib/x86_64-linux-gnu/libXext.so -- Looking for XOpenDisplay in /usr/lib/x86_64-linux-gnu/libX11.so;/usr/lib/x86_64-linux-gnu/libXext.so - found -- Looking for gethostbyname -- Looking for gethostbyname - found -- Looking for connect -- Looking for connect - found -- Looking for remove -- Looking for remove - found -- Looking for shmat -- Looking for shmat - found -- Found X11: /usr/lib/x86_64-linux-gnu/libX11.so -- doxygen not found, ==> no doxygen creation -- Could NOT find PkgConfig (missing: PKG_CONFIG_EXECUTABLE) -- Missing Libraries or programs to create xvkbd: pcregrep;wmctrl;Xaw7;Xmu;Xt;XTest -- cmake build is therefore omitting keytests -- Missing xvkbd, omitting keytests -- -- Build params, switch LYX_* options by -DLYX_*=ON or OFF, LYX_* combos by -DLYX_*=value: -- -- LYX_CPACK= ON : Use the CPack management (Implies LYX_INSTALL option) -- LYX_LOCALVERSIONING = OFF: Add version info to created package name (only used if LYX_CPACK option set) -- LYX_INSTALL = ON : Build install projects/rules (implies a bunch of other options) -- LYX_NLS = ON : Enable Native Language Support (NLS) -- LYX_REQUIRE_SPELLCHECK = OFF: Abort if no spellchecker available -- LYX_ASPELL = OFF: Require aspell -- LYX_ENCHANT = OFF: Require Enchant -- LYX_H
Re: compilation of LyX 2.3 fails with Python 3.6.2
El 16.10.2017 a las 23:38, Kornel Benko escribió: This leads to following output for e.g. Additional.lyx b'#LyX 2.3 created this file. For more info see http://www.lyx.org/' Hmm, but why do we need to modify the doc files? I mean why can't we just use them as they are and omit ReplaceValues.py with Python 3? When playing ping pong like testa = SubstituteDataInLine(line[:-1]).encode("utf-8") testb = testa.decode("utf-8") sys.stdout.write(testb) I get UnicodeEncodeError: 'charmap' codec can't encode character '\u014d' so the SubstituteDataInLine routine does actually not only replace but changes the encoding. I don't have ideas. regards Uwe
Re: compilation of LyX 2.3 fails with Python 3.6.2
Am Montag, 16. Oktober 2017 um 23:28:13, schrieb Uwe Stöhr > El 16.10.2017 a las 11:17, Kornel Benko escribió: > > > Please replace the print statement > > print(SubstituteDataInLine(line[:-1])) > > with > > sys.stdout.write(SubstituteDataInLine(line[:-1])+'\n') > > This lead to > "python UnicodeEncodeError: 'charmap' codec can't encode character" > > However, I found now the solution, see attached. I just put it into master. > > Please give it a +1 for 2.3.x if you agree. > > many thanks for all your help and best regards > Uwe This leads to following output for e.g. Additional.lyx b'#LyX 2.3 created this file. For more info see http://www.lyx.org/' b'\\lyxformat 544' b'\\begin_document' b'\\begin_header' b'\\save_transient_properties true' b'\\origin /systemlyxdir/doc/' b'\\textclass scrbook' b'\\begin_preamble' and so on. This is with python 3.4.3, so sorry, no +1. Kornel signature.asc Description: This is a digitally signed message part.
Re: compilation of LyX 2.3 fails with Python 3.6.2
El 16.10.2017 a las 11:17, Kornel Benko escribió: Please replace the print statement print(SubstituteDataInLine(line[:-1])) with sys.stdout.write(SubstituteDataInLine(line[:-1])+'\n') This lead to "python UnicodeEncodeError: 'charmap' codec can't encode character" However, I found now the solution, see attached. I just put it into master. Please give it a +1 for 2.3.x if you agree. many thanks for all your help and best regards Uwe diff --git "a/C:\\Users\\Usti\\AppData\\Local\\Temp\\TortoiseGit\\ReplaceValues-cd5e2d5.001.py" "b/D:\\LyXGit\\2.3.x\\development\\cmake\\doc\\ReplaceValues.py" index f07ce80bc9..41ed6e212c 100644 --- "a/C:\\Users\\Usti\\AppData\\Local\\Temp\\TortoiseGit\\ReplaceValues-cd5e2d5.001.py" +++ "b/D:\\LyXGit\\2.3.x\\development\\cmake\\doc\\ReplaceValues.py" @@ -13,6 +13,7 @@ from __future__ import print_function import sys import re +import codecs Subst = {} # map of desired substitutions prog = re.compile("") @@ -33,8 +34,8 @@ def SubstituteDataInLine(line): def SubstituteDataInFile(InFile): -for line in open(InFile): -print(SubstituteDataInLine(line[:-1])) +for line in codecs.open(InFile, 'r', 'utf-8'): +print(SubstituteDataInLine(line[:-1]).encode("utf-8")) ##
Re: Beta1 is slow on undo
On 10/16/2017 02:04 AM, Jürgen Spitzmüller wrote: > Am Sonntag, den 15.10.2017, 18:41 -0400 schrieb Richard Heck: >> No, it comes whenever a document contains a BibTeX inset. A better >> patch >> would make it happen >> only when a BibTeX inset was involved. Then the delay is no surprise: >> Of >> course we have to reread >> the files. > The attached patch does not address this very bug, but I have noted > that we unnecessarily read bibtex files multiple time (e.g. with > multiple bibtex insets in master/child constellations or with > subdivided bibliographies/chapterbib). > > The attached patch assures each file is only parsed once within a > single collectBibkey() process. It will slightly speed up the process > in some circumstances. > > Is it worth it? Without profiling, it would be hard to know for sure, but I'd guess it was worth it. Certainly re-reading huge files over a high-latency connection could slow things down. Richard
Re: LyX very slow to end (master)
Le 16/10/2017 à 16:08, Pavel Sanda a écrit : Just trying dirty patch for caching settings inside GuiToolbar::saveSession instead of creating new local var for each fun entry shows that I get quit time around 1s. Quick check shows that most of remaining time is spent in DialogPtr saveSession loop again in saveUISettings; likely the same issue. The cache idea might need some refinement because I do not know what all entry points to saveSession() are and if having single instance throughout the whole session is correct or needs refresh. I won't have time to investigate more ATM. Good catch. A solution is porbably to instantiate a QSettings in saveUISettings and pass it as parameter of the various saveSession() methods. JMarc
Re: Update on the 2.3.0rc1 situation
On 2017-10-14, Scott Kostyshak wrote: > On Mon, Oct 09, 2017 at 11:56:12AM +, Guenter Milde wrote: >> The current default behaviour for dash export is a regression on >> changeset 798ad9755a1ff43a06d2b from 16.06.2007 ... > Note that from what I understand, this is a different topic than the one > that was voted on [1], which focused on possible conversion options, not > on the default of the setting. > As for the potential patch to RELEASE-NOTES, do I understand correctly > that the reason that the text we currently have is incorrect is because > in some cases (e.g. the document uses non-TeX fonts) the change is not > "needed"? The intention is to warn users about the consequences of the changed dash export. The change also affects new documents: the new default allows undesired line-breaks (e.g. in range indications like "1975–78" or after the "opening" dash around French and Spanish incisions) that are prevented in 2.2 documents. I agree that mentioning the different handling of TeX- vs. no-TeX fonts in the caveats section distracts from the intention and propose a revised patch (see below). Thanks, Günter diff --git a/lib/RELEASE-NOTES b/lib/RELEASE-NOTES index c605cb4850..abc1002ca2 100644 --- a/lib/RELEASE-NOTES +++ b/lib/RELEASE-NOTES @@ -212,10 +212,12 @@ the external_templates file, you will have to move the modifications to the respective *.xtemplate file manually. -* If you used literal em- and en-dashes in pre-2.2 documents, - you must manually unselect - "Document->Settings->Fonts->Output em- and en-dash as ligatures" - to ensure unchanged behaviour. +* By default, LyX 2.3 forces output of all en and em dashes as -- and --- + when exporting to LaTeX. This can lead to incorrect line breaks, wrong + characters in typewriter fonts, and problems with some LaTeX packages. + Unselect "Document->Settings->Fonts->Output em- and en-dash as ligatures" + to ensure unchanged behaviour. See chapter 3.9.1.1 "Dashes and line + breaks" of the User Guide for details. * ZWSP characters (u200b) following literal em- and en-dashes are deleted by lyx2lyx when converting to 2.3 format. If you used them as optional line
Equation tracked changes and slight paint issues
Hi Open the attached file. First, it seems that the underline for tracked inserts on display equations is at the correct position now. However, the hook that marks the end of a paragraph did not move with it. Second, to the slight paint issues: - Select the z below the display equation. Now, part of the hook disappears. I guess this would be fixed by moving the hook to the right bottom corner as suggested above. - Press and hold behind the z and move up slightly with the mouse cursor without selecting anything. Now, not only disappears part of the hook but also the underline. Best, Daniel tracked changes paint issue.lyx Description: application/lyx
Re: LyX very slow to end (master)
Pavel Sanda wrote: > Single instance of QSettings in pimp might help this. Just trying dirty patch for caching settings inside GuiToolbar::saveSession instead of creating new local var for each fun entry shows that I get quit time around 1s. Quick check shows that most of remaining time is spent in DialogPtr saveSession loop again in saveUISettings; likely the same issue. The cache idea might need some refinement because I do not know what all entry points to saveSession() are and if having single instance throughout the whole session is correct or needs refresh. I won't have time to investigate more ATM. Pavel diff --git a/src/frontends/qt4/GuiToolbar.cpp b/src/frontends/qt4/GuiToolbar.cpp index d519548e07..50953576a8 100644 --- a/src/frontends/qt4/GuiToolbar.cpp +++ b/src/frontends/qt4/GuiToolbar.cpp @@ -350,12 +350,15 @@ QString GuiToolbar::sessionKey() const return "views/" + QString::number(owner_.id()) + "/" + objectName(); } +QSettings *exitsettings=0; void GuiToolbar::saveSession() const { - QSettings settings; - settings.setValue(sessionKey() + "/visibility", visibility_); - settings.setValue(sessionKey() + "/movability", isMovable()); + if (!exitsettings) + exitsettings=new QSettings; + + exitsettings->setValue(sessionKey() + "/visibility", visibility_); + exitsettings->setValue(sessionKey() + "/movability", isMovable()); }
Re: LyX very slow to end (master)
Pavel Sanda wrote: > with current master I have to wait ~3s before the window And the winner for almost all of 3s goes to saveUISettings and its ToolbarMap saveSession loop. Each GuiToolbar::saveSession() takes ~80ms, guess what happens when we call it 40x... This is qt5 so it might be that lyx 2.0 speed goes to qt4 qsettings implementation... When I launch strace on lyx binary I see gazilion of ERR access to various /home & /etc & ../xgd/ guesses where LyX.conf actually is, so most likely each QSettings init triggers repeated file search for LyX.conf, that's where we get high IO and 80ms per query. Single instance of QSettings in pimp might help this. Another funny observation, I see we(qt?) stat /etc/localtime about 60x times each sec when LyX just idles with no document open. Pavel
Re: LyX very slow to end (master)
Le 16/10/2017 à 14:49, Pavel Sanda a écrit : Hi, when I quit lyx 2.0 the app terminates instantaneously, with current master I have to wait ~3s before the window disappears (emarasingly slower than launching it - 0.5s). The time is spent on I/O, not cpu. Anyone can confirm? Qt4 or Qt5? master only or 2.3 too? JMarc
Windows: bring window to front
Hi, Is the patch for http://www.lyx.org/trac/ticket/10469 already in beta1? If so, it seems not to work. If not, maybe it can make it to rc1? Daniel
LyX very slow to end (master)
Hi, when I quit lyx 2.0 the app terminates instantaneously, with current master I have to wait ~3s before the window disappears (emarasingly slower than launching it - 0.5s). The time is spent on I/O, not cpu. Anyone can confirm? Pavel
Re: LyX-Workarea: Background not shown correctly
> On 16 Oct 2017, at 11:41, Jean-Marc Lasgouttes wrote: > > Le 13/10/2017 à 11:00, Patrick De Visschere a écrit : >> But I see your point; >> When I remove the line setting WA_OpaquePaintEvent the problem remains but >> (most of) the view turns white instead of black; >> When I set WA_NoSystemBackground instead the problem remains the same. >> When I insert viewport()->update(0,0,500,500) then everything outside this >> square remains untouched but the problem persists within that square. > > Did you try setting both WA_OpaquePaintEvent and WA_NoSystemBackground? It doesn’t make a difference. > > Does it make a difference to set them on GuiWorkarea too (additionally to the > viewport)? No. I didn’t try all combinations but adding WA_OpaquePaintEvent and then also WA_NoSystemBackground does not make a difference. pdv > > JMarc smime.p7s Description: S/MIME cryptographic signature
Re: Archaeology: LyX c.2000
Andrew Parsloe wrote: > its 'under the hood' machinery." Last updated, alas, in 2009. I wonder if > these links should be added? > > http://compsoc.man.ac.uk/~moz/www-user/news/archive.php3 (LyX Development > News archive, 2000/02/17 -- 2003/03/03) > > http://compsoc.man.ac.uk/~moz/www-user/news.php3 (LyX News 1999/02/01-- > 2002/12/03; the earliest ref. here is to the release of LyX 1.0) > > http://compsoc.man.ac.uk/~moz/www-user/about/lgt-1.0/lgt.html (A graphical > tour of LyX, 1999/02/02. It looks very different. The menu bar has three > items: File Options Help) Linking does not make much sense, because they will be dead sooner or later, but I can mirror the graphical tour. The news stuff still lives somewhere in our archives I think. Pavel
Re: LyX-Workarea: Background not shown correctly
Le 13/10/2017 à 11:00, Patrick De Visschere a écrit : But I see your point; When I remove the line setting WA_OpaquePaintEvent the problem remains but (most of) the view turns white instead of black; When I set WA_NoSystemBackground instead the problem remains the same. When I insert viewport()->update(0,0,500,500) then everything outside this square remains untouched but the problem persists within that square. Did you try setting both WA_OpaquePaintEvent and WA_NoSystemBackground? Does it make a difference to set them on GuiWorkarea too (additionally to the viewport)? JMarc
Re: LyX-Workarea: Background not shown correctly
Le 15/10/2017 à 10:30, Patrick De Visschere a écrit : I’ve done some more debugging and I believe I’ve found the Qt code that turns the background black or white. Om macos (and probably also on windows) Qt uses a QBackingStore for painting. I couldn’t find a QPlatformBackingStore for linux so I assume the implementation is different on linux, which would explain the different behaviour. When issuing an viewport()->update() the region (the complete viewport if no smaller area is specified) is marked as dirty and at paint time is then repainted, via QWidgetBackingStore::doSync(). In QRasterBackingStore::beginPaint() the region is initially filled with a color Qt::transparent which has alpha=r=g=b=0 which will leave the screen black if not overwritten. Very good finding Patrick! Where is the relevant code? What I would like to know now is: 1. when is invalidation triggered? There are paint events that manage to update the existing screen, so invalidation has to depend on something else 2. can we avoid invalidation by setting some flag? 3. if we cannot avoid it, cn we predict that it happened and do a full screen repaint in this case? When WA_OpaquePaintEvent is not set this is followed by a paintBackground() call which fills the region with the autoFillBrush-color which has all ones. This will leave the screen white if not overwritten. Depending on the update_strategy_ only a part of the screen is overwritten by lyx, leaving the rest black or white. I assume that in the tests I’ve described previously all actions restoring the normal view somehow trigger a FullScreenUpdate. I agree with this analysis. JMarc
Re: Bad Math Display Regression in 2.3.x
Le 13/10/2017 à 20:38, Richard Heck a écrit : On 10/12/2017 04:08 PM, Jean-Marc Lasgouttes wrote: Le 08/10/2017 à 08:56, Jean-Marc Lasgouttes a écrit : The bisect is probably enough for me to find the bug (he said confidently). Here is a tentative patch that I will not be able to test and push until Monday. I will be interesting by some feedback, though. I don't really know this part of the code, so I can't really comment on that. But I can confirm that the patch fixes the problem. I pushed an updated version (only documentation) to master and properpaint. JMarc
Re: compilation of LyX 2.3 fails with Python 3.6.2
Am Montag, 16. Oktober 2017 um 01:43:48, schrieb Uwe Stöhr > El 15.10.2017 a las 23:07, Kornel Benko escribió: > > > As I think I proposed in the attached part in other mail. > > > > Essentially, there is the change of > > open(file) > > to > > codecs.open(file, 'r', 'UTF-8') > > Thanks Kornel, > > unfortunately this does not work. Changing in ReplaceValues.py > > for line in open(InFile) > > into > > for line in codecs.open(InFile, 'r', 'UTF-8'): > > still gives me: > > File "C:\Program Files (x86)\Python35-32\lib\encodings\cp1252.py", > line 19, in encode return > codecs.charmap_encode(input,self.errors,encoding_table)[0] >UnicodeEncodeError: 'charmap' codec can't encode character '\u014d' > in position 1: character maps to > > regards Uwe > Ok, we are a step further. Input is now OK, but on output (the following print statement) the conversion from UTF-8 to cp1252 makes problems. Please replace the print statement print(SubstituteDataInLine(line[:-1])) with sys.stdout.write(SubstituteDataInLine(line[:-1])+'\n') Kornel signature.asc Description: This is a digitally signed message part.
Archaeology: LyX c.2000
As a side-effect of something else I stumbled across these links to LyX 1999--2003 including a graphical tour of LyX, 1999. Last year (I think) a binary for LyX 0.10.7 was found and Jean-Marc mentioned in relation to that the material at http://www.lyx.org/misc/archaeology/. I read there, "Goal: provide a single repository for information about LyX's evolution, enabling the archaeologist to examine changes to both its visual appearance and to its 'under the hood' machinery." Last updated, alas, in 2009. I wonder if these links should be added? http://compsoc.man.ac.uk/~moz/www-user/news/archive.php3 (LyX Development News archive, 2000/02/17 -- 2003/03/03) http://compsoc.man.ac.uk/~moz/www-user/news.php3 (LyX News 1999/02/01-- 2002/12/03; the earliest ref. here is to the release of LyX 1.0) http://compsoc.man.ac.uk/~moz/www-user/about/lgt-1.0/lgt.html (A graphical tour of LyX, 1999/02/02. It looks very different. The menu bar has three items: File Options Help) Andrew --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Fix How Buffers are Set After Undo/Redo
Le 16/10/2017 à 05:21, Richard Heck a écrit : OK, this one is better. I'm not sure I understand why I need to reset first this way, but it seems I do. I am not sure what is the difference between the two patches, but it looks fine. BTW, is ``setInsetBuffers'' really correct grammatically? Just asking. JMarc