Re: Compiling with Microsoft Visual C++
After having fully removed all registry and preference files it suddenly works. On 05.08.2016 20:02, racoon wrote: Finally, I need to get LaTeX running for my compilations. At the moment the "View", etc. is grayed out. I figured that I need to run Reconfigure. The log is below. I guess a culprit is that LyX can't find MiKTex? --- below --- 19:56:28.633: Running configure... 19:56:28.674: python -tt "C:/LyX/LyX2.3.0/lib/configure.py" --binary-dir="C:/LyX/LyX2.3.0-build/LYX_INSTALLED/bin/" 19:56:28.843: checking for DVI to DTL converter... 19:56:28.854: +checking for "dv2dt"... no 19:56:28.862: checking for a Latex2e program... 19:56:28.871: +checking for "latex"... yes 19:56:28.877: checking for a DVI postprocessing program... 19:56:28.894: +checking for "pplatex"... no 19:56:28.948: checking for pLaTeX, the Japanese LaTeX... 19:56:28.955: +checking for "platex"... yes 19:56:32.093: checking for a java interpreter... 19:56:32.100: +checking for "java"... yes 19:56:32.107: checking for a perl interpreter... 19:56:32.115: +checking for "perl"... yes 19:56:32.121: checking for a Tgif viewer and editor... 19:56:32.135: +checking for "tgif"... no 19:56:32.144: checking for a FIG viewer and editor... 19:56:32.154: +checking for "xfig"... no 19:56:32.164: +checking for "jfig3-itext.jar"... no 19:56:32.181: +checking for "jfig3.jar"... no 19:56:32.189: checking for a Dia viewer and editor... 19:56:32.198: +checking for "dia"... no 19:56:32.205: checking for an OpenDocument drawing viewer and editor... 19:56:32.215: +checking for "libreoffice"... no 19:56:32.224: +checking for "lodraw"... no 19:56:32.233: +checking for "ooffice"... no 19:56:32.243: +checking for "oodraw"... no 19:56:32.259: +checking for "soffice"... no 19:56:32.268: checking for a Grace viewer and editor... 19:56:32.275: +checking for "xmgrace"... no 19:56:32.282: checking for a FEN viewer and editor... 19:56:32.289: +checking for "xboard"... no 19:56:32.295: checking for a SVG viewer and editor... 19:56:32.315: +checking for "inkscape"... yes 19:56:32.322: checking for a raster image viewer... 19:56:32.332: +checking for "xv"... no 19:56:32.338: +checking for "kview"... no 19:56:32.344: +checking for "gimp-remote"... no 19:56:32.352: +checking for "gimp"... no 19:56:32.358: checking for a raster image editor... 19:56:32.365: +checking for "gimp-remote"... no 19:56:32.379: +checking for "gimp"... no 19:56:32.386: checking for a text editor... 19:56:32.403: +checking for "xemacs"... no 19:56:32.411: +checking for "gvim"... no 19:56:32.418: +checking for "kedit"... no 19:56:32.434: +checking for "kwrite"... no 19:56:32.442: +checking for "kate"... no 19:56:32.464: +checking for "nedit"... no 19:56:32.501: +checking for "gedit"... no 19:56:32.508: +checking for "notepad"... yes 19:56:32.525: +checking for "geany"... no 19:56:32.561: +checking for "leafpad"... no 19:56:32.578: +checking for "mousepad"... no 19:56:32.587: checking for gnumeric spreadsheet software... 19:56:32.625: +checking for "gnumeric"... no 19:56:32.634: checking for an HTML previewer... 19:56:32.658: +checking for "firefox"... no 19:56:32.677: +checking for "mozilla"... no 19:56:32.697: +checking for "netscape"... no 19:56:32.704: checking for a BibTeX editor... 19:56:32.727: +checking for "jabref"... no 19:56:32.764: +checking for "JabRef"... no 19:56:32.783: +checking for "pybliographic"... no 19:56:32.822: +checking for "bibdesk"... no 19:56:32.847: +checking for "gbib"... no 19:56:32.865: +checking for "kbib"... no 19:56:32.903: +checking for "kbibtex"... no 19:56:32.921: +checking for "sixpack"... no 19:56:32.941: +checking for "bibedit"... no 19:56:32.987: +checking for "tkbibtexxemacs"... no 19:56:33.007: +checking for "gvim"... no 19:56:33.025: +checking for "kedit"... no 19:56:33.064: +checking for "kwrite"... no 19:56:33.083: +checking for "kate"... no 19:56:33.120: +checking for "jedit"... no 19:56:33.137: +checking for "TeXnicCenter"... no 19:56:33.182: +checking for "WinEdt"... no 19:56:33.202: +checking for "WinShell"... no 19:56:33.250: +checking for "PSPad"... no 19:56:33.268: +checking for "nedit"... no 19:56:33.310: +checking for "gedit"... no 19:56:33.319: +checking for "notepad"... yes 19:56:33.336: +checking for "geany"... no 19:56:33.374: +checking for "leafpad"... no 19:56:33.411: +checking for "mousepad"... no 19:56:33.419: checking for a Postscript previewer... 19:56:33.437: +checking for "kghostview"... no 19:56:33.456: +checking for "okular"... no 19:56:33.486: +checking for "qpdfview"... no 19:56:33.540: +checking for "evince"... no 19:56:33.549: +checking for "gv"... no 19:56:33.567: +checking for "ghostview"... no 19:56:33.612: +checking for "gsview64"... no 19:56:33.632: +checking for "gsview32"... no 19:56:33.640: checking for a PDF previewer... 19:56:33.659: +checking for "pdfview"... no 19:56:33.696: +checking for "kpdf"... no 19:56:33.713: +checking for "okular"...
Re: default dir when save for first time is not cwd
On Fri, Jul 29, 2016 at 01:30:25PM -0400, Scott Kostyshak wrote: > I plan to soon propose to change the default of the working directory to > '.', as this thread originally started out as. I would like to test a > bit and take a look at where else that path is used besides creating a > new file. Patch attached. Scott From 22ee499acedca55a94b326e2422ef79022bdc32f Mon Sep 17 00:00:00 2001 From: Scott KostyshakDate: Sat, 8 Oct 2016 20:59:54 -0400 Subject: [PATCH] Change default working directory from ~/ to "." Note that the lyxrc.document_path variable corresponds to what we call the "Working directory" in the GUI preferences dialog. Setting document_path to "." makes it so when LyX is started from a directory, that directory is the default path for many of LyX's operations, such as the following: - new file, new from template - adding a custom BibTeX file - GUI compare dialog - local layout button in document settings - external material file browser - graphics browser, include browser The best guess for where the user wants to save or find files is the directory the user started LyX from. Before, the default was always the home directory. If desired, the old behavior can be restored by changing the default path in Preferences > "Working directory". This commit takes advantage of 9b64d7bd, which allows the use of a relative path for path preferences. --- src/LyX.cpp | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/LyX.cpp b/src/LyX.cpp index fec8281..047e265 100644 --- a/src/LyX.cpp +++ b/src/LyX.cpp @@ -831,7 +831,7 @@ bool LyX::init() #endif lyxrc.tempdir_path = package().temp_dir().absFileName(); - lyxrc.document_path = package().document_dir().absFileName(); + lyxrc.document_path = "."; if (lyxrc.example_path.empty()) { lyxrc.example_path = addPath(package().system_support().absFileName(), -- 2.7.4 signature.asc Description: PGP signature
Re: Proposal for minor change to documentation policy
On Mon, Oct 10, 2016 at 02:46:46AM +0200, Uwe Stöhr wrote: > Am 24.09.2016 um 17:49 schrieb Scott Kostyshak: > > > I propose to change the rule to: > > > > 4. You MUST assure that the document is compilable as "PDF (pdflatex)" > > or the document's default output format. > > Sure, makes obviously sense. > > I put this in. Thanks. Scott signature.asc Description: PGP signature
Re: Proposal for minor change to documentation policy
Am 24.09.2016 um 17:49 schrieb Scott Kostyshak: I propose to change the rule to: 4. You MUST assure that the document is compilable as "PDF (pdflatex)" or the document's default output format. Sure, makes obviously sense. I put this in. regards Uwe
Re: #7964: LyX-Enhanced Chat
On Mon, Oct 10, 2016 at 01:00:50AM +0200, Tommaso Cucinotta wrote: > On 09/10/2016 17:12, Scott Kostyshak wrote: > > Great, thanks! It might be nice to have a Wiki page for this. > > now we have > http://wiki.lyx.org/Devel/LyXChat#sDevel.LyXChat_8 > > I also merged the proposal into this page on ideas for collaborative > extensions: > http://wiki.lyx.org/Devel/Collaboration#toc2 This is good. Thanks. > along with the other related Interactive LyX idea (way more difficult). > > This should now be more visible than merely TT #7964, and more easily found > with a search engine. Agreed. > > kind of popped up here: > > http://tex.stackexchange.com/questions/330934/is-there-any-lyx-online-editor/331034#331034 > > just replied to that thread with the new pointer... (they were actually > looking for the collaborative/interactive patch, the one that was badly > crashing and had been discussed in GSoC 2013 :-), but that's more involved > than just the chat). Nice. Scott signature.asc Description: PGP signature
When will 2.2.2 be released?
Hi Richard, I remember that you wanted to release it end of September? What is the new plan? thanks and regards Uwe
Re: #7964: LyX-Enhanced Chat
On 09/10/2016 17:12, Scott Kostyshak wrote: Great, thanks! It might be nice to have a Wiki page for this. now we have http://wiki.lyx.org/Devel/LyXChat#sDevel.LyXChat_8 I also merged the proposal into this page on ideas for collaborative extensions: http://wiki.lyx.org/Devel/Collaboration#toc2 along with the other related Interactive LyX idea (way more difficult). This should now be more visible than merely TT #7964, and more easily found with a search engine. kind of popped up here: http://tex.stackexchange.com/questions/330934/is-there-any-lyx-online-editor/331034#331034 just replied to that thread with the new pointer... (they were actually looking for the collaborative/interactive patch, the one that was badly crashing and had been discussed in GSoC 2013 :-), but that's more involved than just the chat). Thanks for pointing this out, T.
Re: ctests: give output of LaTeX error
Am Sonntag, 9. Oktober 2016 um 17:55:49, schrieb Scott Kostyshak> On Sun, Oct 09, 2016 at 09:28:47PM +, Guenter Milde wrote: > > On 2016-10-09, Scott Kostyshak wrote: > > > > Good idea. Assuming we do not have many inverted tests that would keep > > > the file size of the log down. Günter, do you want the log output for > > > the non-inverted tests also? > > > > Preferabely yes, because then I know if inversion is required if a test > > fails. > > Otherwise, a new failure would require > > * inversion (as TODO) > > * rerunning cmake > > * inspection of the log > > * sort of the inversion-pattern or fix of the installation or ignoring ... > > * rerunning cmake > > Makes sense. > > > > > Maybe the dbg could be collected and only appended to the log if there was > > an error... > > I'm not sure this is possible. Maybe Kornel is aware of some magic to > make it happen though. Difficult. We would 1.) call lyx with '-dbg latex' 2.) collect output in cmake variable 3a.) In case of error, output the the log 3b.) else strip the log of latex messages. 4.) print the stripped output Unfortunately the lyx-latex debug messages are not easy to filter Normally they start with SomeFile.cpp (xxx): Log line: some latex log but if the log is multi-line, we are lost. > Scott Kornel signature.asc Description: This is a digitally signed message part.
Re: [patch] Factor out magic zoom minimum to a const member
On Sun, Oct 09, 2016 at 11:35:26PM +0200, Guillaume Munch wrote: > I now get the following with gcc 4.6: > > ../../../../src/frontends/qt4/GuiView.h:467:33: sorry, unimplemented: > non-static data member initializers > > Your code is fine, this is just gcc 4.6 not supporting a C++11 feature. > Though, here you could make your variable static without loss of intent > or purpose. Thank you for catching this and for the explanation. I made the change at f411040a. In the future, please always feel free to amend my commits if it takes you less time to do so directly than to explain to me. To be clear, I don't mind at all doing it myself (perhaps it makes more of an imprint on my memory so that I would be less likely to make the same mistake next time), so it is up to you. I'm a little confused by the error message. From what I understand, what is not supported is initializing non-static data members inside the class definition. But initializing data members inside a constructor is of course supported. How does the error message not contradict this situation? Scott signature.asc Description: PGP signature
Re: ctest seminar
On Sun, Oct 09, 2016 at 09:33:42PM +, Guenter Milde wrote: > On 2016-10-09, Scott Kostyshak wrote: > > On Sun, Oct 09, 2016 at 04:45:11PM +, Guenter Milde wrote: > >> On 2016-10-09, Scott Kostyshak wrote: > > ... > > >> Yes. It is good to make the documents "robust", but not if this stands in > >> the way with the main purpose: documentation. > > > +1 > > >> Example: > >> * ERT that only works with pdflatex is OK, if it explains ERT, its > >> limits and benefits. > > > In this case, I would think that we could use ERT that works more > > generally than only with pdflatex and I think that would be a better > > lesson to the user. Teaching general LaTeX knowledge I think is better > > than knowledge specific to one engine. > > The use case for ERT is special tricks to get things done. > Normally, one output format suffices to get things done. > The best ERT code in this case is a simple one, that works with this format, > not a generic with \ifpfd \ifxetex ... tests for engines and variants. > > Changing existing documents (giving other examples) just to have ERT that > works also in other engines is "stands in the way" in my view -- I'd rather > keep the pattern in the inverted:ERT. I see what you mean now. I think we both would agree with the following: "if by using ERT that works with pdflatex, xelatex, and luatex we achieve the same level of clarity in the document, then that should be preferred over ERT that works for only pdflatex. Otherwise (if we cannot achieve the same level of clarity), the clarity of the document is most important and thus the ERT that works only with pdflatex should be preferred." Scott signature.asc Description: PGP signature
Re: ctests: give output of LaTeX error
On Sun, Oct 09, 2016 at 09:28:47PM +, Guenter Milde wrote: > On 2016-10-09, Scott Kostyshak wrote: > > Good idea. Assuming we do not have many inverted tests that would keep > > the file size of the log down. Günter, do you want the log output for > > the non-inverted tests also? > > Preferabely yes, because then I know if inversion is required if a test fails. > Otherwise, a new failure would require > * inversion (as TODO) > * rerunning cmake > * inspection of the log > * sort of the inversion-pattern or fix of the installation or ignoring ... > * rerunning cmake Makes sense. > > Maybe the dbg could be collected and only appended to the log if there was > an error... I'm not sure this is possible. Maybe Kornel is aware of some magic to make it happen though. Scott signature.asc Description: PGP signature
Re: [patch] Factor out magic zoom minimum to a const member
Le 09/10/2016 à 23:26, Scott Kostyshak a écrit : On Sun, Oct 09, 2016 at 05:21:03PM -0400, Scott Kostyshak wrote: I just pushed a commit but I forgot to append the underscore. I'll fix that now. Committed at 168d3557 and amended at 5fd21db9. Scott I now get the following with gcc 4.6: ../../../../src/frontends/qt4/GuiView.h:467:33: sorry, unimplemented: non-static data member initializers Your code is fine, this is just gcc 4.6 not supporting a C++11 feature. Though, here you could make your variable static without loss of intent or purpose.
Re: ctest seminar
On 2016-10-09, Scott Kostyshak wrote: > On Sun, Oct 09, 2016 at 04:45:11PM +, Guenter Milde wrote: >> On 2016-10-09, Scott Kostyshak wrote: ... >> Yes. It is good to make the documents "robust", but not if this stands in >> the way with the main purpose: documentation. > +1 >> Example: >> * ERT that only works with pdflatex is OK, if it explains ERT, its >> limits and benefits. > In this case, I would think that we could use ERT that works more > generally than only with pdflatex and I think that would be a better > lesson to the user. Teaching general LaTeX knowledge I think is better > than knowledge specific to one engine. The use case for ERT is special tricks to get things done. Normally, one output format suffices to get things done. The best ERT code in this case is a simple one, that works with this format, not a generic with \ifpfd \ifxetex ... tests for engines and variants. Changing existing documents (giving other examples) just to have ERT that works also in other engines is "stands in the way" in my view -- I'd rather keep the pattern in the inverted:ERT. Günter
Re: LyX docs: cleaning up math options
On Sun, Oct 09, 2016 at 09:24:11PM +, Guenter Milde wrote: > On 2016-10-09, Scott Kostyshak wrote: > > I don't think I would want to spend the time to manually inspect the > > output of all of the exports. > > There is no need to test *all* exports, just the default (i.e. pdf2) and > only for changes that may change the output. OK. > > Perhaps there is some automatic way to do it, using a tool that looks > > for diffs in PDFs. diffpdf is useful, for example. > > If you understand the consequences of a change, manual testing may be > confined to one (or none for simple changes) document (not all > translations, say). I see. I do not understand all of the possible consequences of this change. Let's first see what Uwe says. If he is in favor, then let's continue the discussion about whether to make the change and check manually or not make the change. If Uwe's not in favor, then spending time on that discussion is not worth it yet. Thanks for the feedback. Scott signature.asc Description: PGP signature
Re: ctests: give output of LaTeX error
On 2016-10-09, Scott Kostyshak wrote: > [-- Type: text/plain, Encoding: quoted-printable --] > On Sun, Oct 09, 2016 at 07:46:24PM +0200, Kornel Benko wrote: >> Am Sonntag, 9. Oktober 2016 um 19:21:57, schrieb Kornel Benko >>>> > Am Sonntag, 9. Oktober 2016 um 12:38:44, schrieb Scott Kostyshak >> > >> > > Is it possible to show the -dbg output only when there was an error? I >> > > don't know if our ctest framework allows us to do that. >> > >> > It is possible, but we have to know that there is an error prior to ctest >> > call. >> > >> Like attached? > Good idea. Assuming we do not have many inverted tests that would keep > the file size of the log down. Günter, do you want the log output for > the non-inverted tests also? Preferabely yes, because then I know if inversion is required if a test fails. Otherwise, a new failure would require * inversion (as TODO) * rerunning cmake * inspection of the log * sort of the inversion-pattern or fix of the installation or ignoring ... * rerunning cmake Maybe the dbg could be collected and only appended to the log if there was an error... Günter
Re: [patch] Factor out magic zoom minimum to a const member
On Sun, Oct 09, 2016 at 05:21:03PM -0400, Scott Kostyshak wrote: > I just pushed a commit but I forgot to append the underscore. I'll fix > that now. Committed at 168d3557 and amended at 5fd21db9. Scott signature.asc Description: PGP signature
Re: LyX docs: cleaning up math options
On 2016-10-09, Scott Kostyshak wrote: > [-- Type: text/plain, Encoding: --] > On Sun, Oct 09, 2016 at 04:50:35PM +, Guenter Milde wrote: >> * Changes must not only tested for compilation success but also for correct >> output. > I don't think I would want to spend the time to manually inspect the > output of all of the exports. There is no need to test *all* exports, just the default (i.e. pdf2) and only for changes that may change the output. >> That said, I am not against the proposed changes (but Uwe is the one to >> decide). > Because of what I said above, I think you would be against the proposed > changes. Correct? > Perhaps there is some automatic way to do it, using a tool that looks > for diffs in PDFs. diffpdf is useful, for example. If you understand the consequences of a change, manual testing may be confined to one (or none for simple changes) document (not all translations, say). Günter
Re: [patch] Factor out magic zoom minimum to a const member
On Sun, Oct 09, 2016 at 07:24:25PM +0200, Enrico Forestieri wrote: > On Sat, Oct 08, 2016 at 10:09:54AM -0400, Scott Kostyshak wrote: > > > On Sat, Oct 08, 2016 at 11:02:17AM +0200, Enrico Forestieri wrote: > > > On Fri, Oct 07, 2016 at 11:41:25PM -0400, Scott Kostyshak wrote: > > > > > > > The attached patch is simple but I have not made a change like this > > > > before so I wanted to check on the list. > > > > > > In general, all capitals is used for preprocessor macros and in LyX > > > private mambers have a trailing underscore. So, I suggest changing > > > ZOOM_MIN to zoom_min_. > > > > Ah yes I should have remembered that. Thanks for catching it. > > > > I originally had it in capitals because in Server.h we have > > enum { MAX_CLIENTS = 10 }; > > > > so I first used an enum. > > > > Is there any advantage/preference for using an enum over a const int in > > this situation? > > I don't think so. If you like all capitals, go for it. Lowercase is fine, and I like using an int instead of an enum because this approach generalizes to other situations (e.g. if I wanted a const string) that I don't think an enum does. I just pushed a commit but I forgot to append the underscore. I'll fix that now. Thanks for the feedback. Scott signature.asc Description: PGP signature
Re: [LyX/master] Remove question marks from Windows dialogs
On Sun, Oct 09, 2016 at 08:18:37PM +0200, Guillaume Munch wrote: > Le 09/10/2016 à 19:51, Guillaume Munch a écrit : > > commit cf26d53e037cf59b5816cdb2f5c7d835b83d480a > > Author: Daniel Ramöller> > Date: Mon Oct 3 20:20:16 2016 +0200 > > > > Remove question marks from Windows dialogs > > Welcome to the project! Yes thank you and welcome! Scott signature.asc Description: PGP signature
Re: ctests: give output of LaTeX error
On Sun, Oct 09, 2016 at 07:46:24PM +0200, Kornel Benko wrote: > Am Sonntag, 9. Oktober 2016 um 19:21:57, schrieb Kornel Benko> > Am Sonntag, 9. Oktober 2016 um 12:38:44, schrieb Scott Kostyshak > > > > > Is it possible to show the -dbg output only when there was an error? I > > > don't know if our ctest framework allows us to do that. > > > > It is possible, but we have to know that there is an error prior to ctest > > call. > > > > Like attached? Good idea. Assuming we do not have many inverted tests that would keep the file size of the log down. Günter, do you want the log output for the non-inverted tests also? Scott signature.asc Description: PGP signature
Re: [LyX/master] Remove question marks from Windows dialogs
Le 09/10/2016 à 19:51, Guillaume Munch a écrit : commit cf26d53e037cf59b5816cdb2f5c7d835b83d480a Author: Daniel RamöllerDate: Mon Oct 3 20:20:16 2016 +0200 Remove question marks from Windows dialogs Welcome to the project!
Re: ctests: give output of LaTeX error
Am Sonntag, 9. Oktober 2016 um 19:21:57, schrieb Kornel Benko> Am Sonntag, 9. Oktober 2016 um 12:38:44, schrieb Scott Kostyshak > > > When encountering a ctest failure, we must run the test manually to see > > what the LaTeX error. It would be nice to be able to see the LaTeX error > > from the ctest logs. The following tickets are related: > > http://www.lyx.org/trac/ticket/9931 > > http://www.lyx.org/trac/ticket/9866 > > > > One possibility would be for the ctests to call LyX with > > > > -dbg latex > > Yes, will do. > > > which does indeed show the error. > > > > I don't think this is a good idea though, because The LastTest.log file > > already has 1653656 lines and is 110M. With this command, I think the > > file will get much larger. > > > > Is it possible to show the -dbg output only when there was an error? I > > don't know if our ctest framework allows us to do that. > > It is possible, but we have to know that there is an error prior to ctest > call. > Like attached? Kornel diff --git a/development/autotests/export.cmake b/development/autotests/export.cmake index 09e7ec7..6c02750 100755 --- a/development/autotests/export.cmake +++ b/development/autotests/export.cmake @@ -126,10 +126,15 @@ if (extension MATCHES "\\.lyx$") set(LYX_SOURCE ${result_file_name}) endforeach() else() - message(STATUS "Executing ${lyx} -userdir \"${LYX_TESTS_USERDIR}\" -E ${format} ${result_file_name} \"${LYX_SOURCE}\"") + if (inverted) +set(LatexDebugParam "-dbg latex") + else() +set(LatexDebugParam "") + endif() + message(STATUS "Executing ${lyx} ${LatexDebugParam} -userdir \"${LYX_TESTS_USERDIR}\" -E ${format} ${result_file_name} \"${LYX_SOURCE}\"") file(REMOVE ${result_file_name}) execute_process( -COMMAND ${lyx} -userdir "${LYX_TESTS_USERDIR}" -E ${format} ${result_file_name} "${LYX_SOURCE}" +COMMAND ${lyx} ${LatexDebugParam} -userdir "${LYX_TESTS_USERDIR}" -E ${format} ${result_file_name} "${LYX_SOURCE}" RESULT_VARIABLE _err) #check if result file created signature.asc Description: This is a digitally signed message part.
Re: [patch] Factor out magic zoom minimum to a const member
On Sat, Oct 08, 2016 at 10:09:54AM -0400, Scott Kostyshak wrote: > On Sat, Oct 08, 2016 at 11:02:17AM +0200, Enrico Forestieri wrote: > > On Fri, Oct 07, 2016 at 11:41:25PM -0400, Scott Kostyshak wrote: > > > > > The attached patch is simple but I have not made a change like this > > > before so I wanted to check on the list. > > > > In general, all capitals is used for preprocessor macros and in LyX > > private mambers have a trailing underscore. So, I suggest changing > > ZOOM_MIN to zoom_min_. > > Ah yes I should have remembered that. Thanks for catching it. > > I originally had it in capitals because in Server.h we have > enum { MAX_CLIENTS = 10 }; > > so I first used an enum. > > Is there any advantage/preference for using an enum over a const int in > this situation? I don't think so. If you like all capitals, go for it. -- Enrico
Re: ctests: give output of LaTeX error
Am Sonntag, 9. Oktober 2016 um 12:38:44, schrieb Scott Kostyshak> When encountering a ctest failure, we must run the test manually to see > what the LaTeX error. It would be nice to be able to see the LaTeX error > from the ctest logs. The following tickets are related: > http://www.lyx.org/trac/ticket/9931 > http://www.lyx.org/trac/ticket/9866 > > One possibility would be for the ctests to call LyX with > > -dbg latex Yes, will do. > which does indeed show the error. > > I don't think this is a good idea though, because The LastTest.log file > already has 1653656 lines and is 110M. With this command, I think the > file will get much larger. > > Is it possible to show the -dbg output only when there was an error? I > don't know if our ctest framework allows us to do that. It is possible, but we have to know that there is an error prior to ctest call. > Scott Kornel signature.asc Description: This is a digitally signed message part.
Re: LyX docs: cleaning up math options
On Sun, Oct 09, 2016 at 04:50:35PM +, Guenter Milde wrote: > * Changes must not only tested for compilation success but also for correct > output. I don't think I would want to spend the time to manually inspect the output of all of the exports. > That said, I am not against the proposed changes (but Uwe is the one to > decide). Because of what I said above, I think you would be against the proposed changes. Correct? Perhaps there is some automatic way to do it, using a tool that looks for diffs in PDFs. diffpdf is useful, for example. Scott signature.asc Description: PGP signature
Re: ctest seminar
On Sun, Oct 09, 2016 at 04:45:11PM +, Guenter Milde wrote: > On 2016-10-09, Scott Kostyshak wrote: > Two points that were agreed with Uwe: > > * The manuals in lib/doc are designed for output with pdflatex and TeX > fonts and only this export is secure. > > To make this clear, the default output format is set to pdf2. > > * The manuals in lib/doc/ are c-tested with other exports despite the > default output format setting. > > For this, the ctest scripts were modified to respect the default format > *except for documents in lib/doc/*. Thanks for this reminder. > > But we shouldn't modify the documents for the purpose of > > the ctests. We should only do that if it makes sense for the documents. > > Yes. It is good to make the documents "robust", but not if this stands in > the way with the main purpose: documentation. +1 > Example: > * ERT that only works with pdflatex is OK, if it explains ERT, its > limits and benefits. In this case, I would think that we could use ERT that works more generally than only with pdflatex and I think that would be a better lesson to the user. Teaching general LaTeX knowledge I think is better than knowledge specific to one engine. > * ERT for other purposes is bad, if it can be replaced with a better > working LyX construct. > > e.g.: ERT for accents in Russian should be replaced by composite Unicode > characters. > > > > And in my opinion it makes sense for the documents if pdflatex, xelatex, > > and lualatex all work on the document. I'm not sure what others think > > though. > > Xe/LuaTeX with TeX fonts are not usefull and we should not make much effort > to support them. > > I would like it very much if the Xe/LuaTeX buttons would also > select Unicode fonts by default. There is already a track issue for this > (parallel configuration of tex and non-tex fonts) but I don't remember the > number. +1 Scott signature.asc Description: PGP signature
Re: LyX docs: cleaning up math options
On 2016-10-08, Scott Kostyshak wrote: > [-- Type: text/plain, Encoding: --] > On Sat, Oct 08, 2016 at 08:17:04AM +, Guenter Milde wrote: >> I don't know whether this is the intention here, but I would give Uwe as >> maintainer the say about the correct settings. > OK, I CC'ed Uwe. I won't make any changes until we hear from him. In > fact, if you are very against the proposed changes, then I will just not > pursue it. I do not have a strong opinion on it. General points: * LyX defaults are not suited for every document, (e.g. no font package but T1 font encoding is always bad, mixed, language-dependent input encodings is in most cases bad) so non-default settings are not bad per-se. * Changes must not only tested for compilation success but also for correct output. That said, I am not against the proposed changes (but Uwe is the one to decide). Günter
Re: ctest seminar
On 2016-10-09, Scott Kostyshak wrote: > On Sun, Oct 09, 2016 at 04:36:47PM +0100, Jean-Pierre Chrétien wrote: >> Le 08/10/2016 à 19:10, Scott Kostyshak a écrit : >> Right, now I get onle the three systemF failures due to the >> Missing character: There is no ✗ in font >> [lmroman10-regular]:mapping=tex-text! > I'm not sure why. Because this document is not fit for export with Unicode fonts and it tells so by setting the default output. (LatinModern is the default for fonspec but a quite limited font with many missing characters.) We can change this by defining other Unicodefonts (I recommend DejaVu) in the LyX-source. >> BTW, the text of the manuals (which have all pdf2 as default output) are >> never tested again other exports ? > Unfortunately I think that is correct. It would be nice to improve > this and test more exports. One way to do this would be to remove the > default output. Two points that were agreed with Uwe: * The manuals in lib/doc are designed for output with pdflatex and TeX fonts and only this export is secure. To make this clear, the default output format is set to pdf2. * The manuals in lib/doc/ are c-tested with other exports despite the default output format setting. For this, the ctest scripts were modified to respect the default format *except for documents in lib/doc/*. > But we shouldn't modify the documents for the purpose of > the ctests. We should only do that if it makes sense for the documents. Yes. It is good to make the documents "robust", but not if this stands in the way with the main purpose: documentation. Example: * ERT that only works with pdflatex is OK, if it explains ERT, its limits and benefits. * ERT for other purposes is bad, if it can be replaced with a better working LyX construct. e.g.: ERT for accents in Russian should be replaced by composite Unicode characters. > And in my opinion it makes sense for the documents if pdflatex, xelatex, > and lualatex all work on the document. I'm not sure what others think > though. Xe/LuaTeX with TeX fonts are not usefull and we should not make much effort to support them. I would like it very much if the Xe/LuaTeX buttons would also select Unicode fonts by default. There is already a track issue for this (parallel configuration of tex and non-tex fonts) but I don't remember the number. > The other way to add tests would be to remove the ctest mechanism that > tests only the default format if it is set. We had a discussion on this > but I forgot why we decided to do this. See above. Günter
ctests: give output of LaTeX error
When encountering a ctest failure, we must run the test manually to see what the LaTeX error. It would be nice to be able to see the LaTeX error from the ctest logs. The following tickets are related: http://www.lyx.org/trac/ticket/9931 http://www.lyx.org/trac/ticket/9866 One possibility would be for the ctests to call LyX with -dbg latex which does indeed show the error. I don't think this is a good idea though, because The LastTest.log file already has 1653656 lines and is 110M. With this command, I think the file will get much larger. Is it possible to show the -dbg output only when there was an error? I don't know if our ctest framework allows us to do that. Scott signature.asc Description: PGP signature
Re: ctests: 4 failing "Unicode-characters" tests
On Sun, Oct 09, 2016 at 04:04:15PM +, Guenter Milde wrote: > BTW: if "--debug latex" prints the latex error, shouldn't the test script > make the latex export calls with this setting? I will start a new email thread for this. Scott signature.asc Description: PGP signature
Re: ctest seminar
On 2016-10-08, Scott Kostyshak wrote: > [-- Type: text/plain, Encoding: quoted-printable --] > On Sat, Oct 08, 2016 at 06:37:53PM +0100, Jean-Pierre Chrétien wrote: >> Hello, >> I've setup the test machinery on my Debian Jessie, TeXLive 2016: >> * ran automake in /ext/lyx/master >> * ran cmake on Debian Jessie in /ext/lyx/cbuildmaster as >> /ext/lyx/cbuildmaster$ cmake -DLYX_ENABLE_EXPORT_TESTS=ON -DLYX_RELEASE=ON >> -DLYX_PROGRAM_SUFFIX=ON -DLYX_ENABLE_CXX11=AUTO -DLYX_USE_QT=QT5 >> -DLYX_INSTALL_PREFIX="git-" ../master >> * ran make >> For a first try, I ran cmake -R 'seminar*' to check recent improvements with >> the seminar example file, and I get the attached result. >> What surprises me is that >> - the English version of seminar.lyx is not tested for all output formats; >> - the French one fails for dvi3, pdf4 and pdf5, that is for dvi (LuaTeX), >> pdf (XeTeX) and pdf (LuaTeX), for both fonts. > This has to do with whether the "Default output format" is set. > If I set it back to "default", and rerun cmake and then rerun the tests, > then all of the tests pass. This makes me think we should change the > format back to default. Günter do you have an opinion on this? The default output format setting is intended. Seminar does not work sensibly with DVI (except for landscape slides) and requires different settings for different output formats, thus * it is advisable to set an output format in the document (and therefore a good to do this in the example). * it does not make sense to test for formats we know to result in wrong output. >> Running exports manually, I find that >> - there is no failure for the texF tests (TeX fonts) >> - the compilation with systemF tests fails with message: >> Missing character: There is no ✗ in font >> [lmroman10-regular]:mapping=tex-text! >> The manual export of the original English seminar.lyx file (not tested by >> ctest, as said) fails also with the same message, so this looks like a >> missing font in my installation. This is expected: with TeX fonts, the ✗ is taken from a symbols package loaded by request from "unicodesymbols". With Unicode fonts, we would need to change the font to e.g. FreeSerif etc. >> So manually there are 3 false alarms, but I must say also that the texF >> tests did fail once in a weird manner which I cannot reproduce: I got and >> error looking like polyglossia language change error, but with no error >> showing in the log window. (however, there cannot be a polyglossia error with texF, as polyglossia requires fontspec (i.e. Unicode fonts)). >> This is a bit mysterious but could explain the ctest failures. Is >> there somwhere a log of the test compilation (or an option to activate >> it?). Unfortunately not (yet). Günter
Re: ctests: 4 failing "Unicode-characters" tests
On 2016-10-09, Jean-Pierre Chrétien wrote: > Le 09/10/2016 à 02:17, Scott Kostyshak a écrit : >> On Sat, Oct 08, 2016 at 01:53:06PM -0400, Scott Kostyshak wrote: >>> I still get an error for >>> export/export/latex/Unicode-characters/084-misc-symbols-utf8_pdf2 (Failed) >>> Does it pass for you? >>> The error I get is: >>> ! Package inputenc Error: Unicode char ⚀ (U+2680) >>> (inputenc)not set up for use with LaTeX. >> Günter fixed this issue at 52fbe6ea. >> Now all -R "character" tests pass for me. > Not for me (with an up to date master executable): > The following tests FAILED: > 257 - export/export/latex/Unicode-characters/001-4-latin-utf8_pdf2 > (Failed) ... > 274 - > export/export/latex/Unicode-characters/074-76-letterlike-numberforms-arrows_pdf2 > > (Failed) > Is it correct just ta make in the cbuildmaster dir after git pull ? > Should I do something about my fonts installation ? There are no special font requirements for these tests but some (pretty standard) packages like textcomp, wasysym, ifsym, ... I don't think this is the problem. Could you rerun the cmake call (e.g. cmake -DLYX_ENABLE_EXPORT_TESTS=ON -DLYX_RELEASE=ON -DLYX_INSTALL_PREFIX="git-" ../lyx ) and try again. If this still fails, please run one of the tests "by hand" and post the error message. BTW: if "--debug latex" prints the latex error, shouldn't the test script make the latex export calls with this setting? Günter
Re: #7964: LyX-Enhanced Chat
On Sun, Oct 09, 2016 at 12:20:44PM +0200, Tommaso Cucinotta wrote: > On 09/10/2016 01:37, Scott Kostyshak wrote: > > Is there any documentation for it? > > for now, it's all here: > > http://www.lyx.org/trac/ticket/7964 > > quick start guide, compile: > > 1. recompile qxmpp from sources available at: > http://retis.sssup.it/~tommaso/qxmpp > (or install straight the .deb available there) > 2. compile LyX with the chat patch configuring with '--enable-qt5' > '--with-extra-inc=/usr/include/x86_64-linux-gnu/qt5/QtNetwork:/usr/include/x86_64-linux-gnu/qt5/QtGui' > > use: > 1. start LyX, choose Tools->LyX Chat > 2. in the "Buddies" pane, put your Id (username@domain) of an existing XMPP > account > (e.g., create one for free on Jabber) > 3. click "Connect", enter your access password > (these will be cached in your $HOME/.lyx/ as \user_chat_id etc... > 4. add/connect to a new buddy by using the "Add" button (enter the > username@domain of the buddy) > 5. double-click on a buddy, and have fun chat :-)! > (your buddy can connect either with LyX or a regular text client, e.g., > Pidgin, in such case they would see > LaTeX text segments rather than enjoying the beautifully rendered LyX) > > Notes: > 1. no networking is ever started by LyX, unless you start the "LyX Chat" > 2. if you close the chat dialogs, the XMPP client keeps running and will show > the chat back if anyone writes you > 3. an option to shut down any chat / network might be useful, due to 2, as > well as a statusbar indication that the chat is still connected > 4. your XMPP password is stored cleartext in your .lyx/ directory (an option > could be useful to never store the password if wanted) > > Videos of the LyX chat in action: > -) http://www.youtube.com/watch?v=lQnVxbX8A3w > -) http://www.youtube.com/watch?v=n0Xfi8Ohx7Y(+Irish intro) > > Please write, should anything be unclear, thanks :-)! Great, thanks! It might be nice to have a Wiki page for this. I won't test this for a while (perhaps summer?), but I will be sure to forward this information to anyone who is interested. For example, this topic kind of popped up here: http://tex.stackexchange.com/questions/330934/is-there-any-lyx-online-editor/331034#331034 although I'm not sure if they were interested in a collaborative aspect or just the cloud aspect. Scott signature.asc Description: PGP signature
Re: ctest seminar
On Sun, Oct 09, 2016 at 04:36:47PM +0100, Jean-Pierre Chrétien wrote: > Le 08/10/2016 à 19:10, Scott Kostyshak a écrit : > > > > > This has to do with whether the "Default output format" is set. > > If I set it back to "default", and rerun cmake and then rerun the tests, > > then all of the tests pass. This makes me think we should change the > > format back to default. Günter do you have an opinion on this? > > Right, now I get onle the three systemF failures due to the > > Missing character: There is no ✗ in font [lmroman10-regular]:mapping=tex-text! I'm not sure why. > BTW, the text of the manuals (which have all pdf2 as default output) are > never tested again other exports ? Unfortunately I think that is correct. It would be nice to improve this and test more exports. One way to do this would be to remove the default output. But we shouldn't modify the documents for the purpose of the ctests. We should only do that if it makes sense for the documents. And in my opinion it makes sense for the documents if pdflatex, xelatex, and lualatex all work on the document. I'm not sure what others think though. The other way to add tests would be to remove the ctest mechanism that tests only the default format if it is set. We had a discussion on this but I forgot why we decided to do this. Scott signature.asc Description: PGP signature
Re: ctests: 4 failing "Unicode-characters" tests
On Sun, Oct 09, 2016 at 04:27:33PM +0100, Jean-Pierre Chrétien wrote: > Is it correct just ta make in the cbuildmaster dir after git pull ? It depends. In many cases that is enough. But if something changed in e.g. ignoredTests or invertedTests, then you need to run cmake again. You don't have to do a fresh build. Just rerun the cmake command and then make and then ctest. > Should I do something about my fonts installation ? I don't know. Scott signature.asc Description: PGP signature
Re: ctest seminar
Le 08/10/2016 à 19:10, Scott Kostyshak a écrit : This has to do with whether the "Default output format" is set. If I set it back to "default", and rerun cmake and then rerun the tests, then all of the tests pass. This makes me think we should change the format back to default. Günter do you have an opinion on this? Right, now I get onle the three systemF failures due to the Missing character: There is no ✗ in font [lmroman10-regular]:mapping=tex-text! BTW, the text of the manuals (which have all pdf2 as default output) are never tested again other exports ? -- Jean-Pierre
Re: ctests: 4 failing "Unicode-characters" tests
Le 09/10/2016 à 02:17, Scott Kostyshak a écrit : On Sat, Oct 08, 2016 at 01:53:06PM -0400, Scott Kostyshak wrote: I still get an error for export/export/latex/Unicode-characters/084-misc-symbols-utf8_pdf2 (Failed) Does it pass for you? The error I get is: ! Package inputenc Error: Unicode char ⚀ (U+2680) (inputenc)not set up for use with LaTeX. Günter fixed this issue at 52fbe6ea. Now all -R "character" tests pass for me. Not for me (with an up to date master executable): The following tests FAILED: 257 - export/export/latex/Unicode-characters/001-4-latin-utf8_pdf2 (Failed) 258 - export/export/latex/Unicode-characters/001-4-latin_pdf2 (Failed) 259 - export/export/latex/Unicode-characters/005-8-ipa-modifiers-combining-utf8_pdf2 (Failed) 260 - export/export/latex/Unicode-characters/005-8-ipa-modifiers-combining_pdf2 (Failed) 261 - export/export/latex/Unicode-characters/008-greek-and-coptic-utf8_pdf2 (Failed) 262 - export/export/latex/Unicode-characters/008-greek-and-coptic_pdf2 (Failed) 263 - export/export/latex/Unicode-characters/009-cyrillic-utf8_pdf2 (Failed) 264 - export/export/latex/Unicode-characters/009-cyrillic_pdf2 (Failed) 265 - export/export/latex/Unicode-characters/065-67-phonetic-extensions-utf8_pdf2 (Failed) 266 - export/export/latex/Unicode-characters/065-67-phonetic-extensions_pdf2 (Failed) 269 - export/export/latex/Unicode-characters/069-greek-extended-utf8_pdf2 (Failed) 270 - export/export/latex/Unicode-characters/069-greek-extended_pdf2 (Failed) 273 - export/export/latex/Unicode-characters/074-76-letterlike-numberforms-arrows-utf8_pdf2 (Failed) 274 - export/export/latex/Unicode-characters/074-76-letterlike-numberforms-arrows_pdf2 (Failed) Is it correct just ta make in the cbuildmaster dir after git pull ? Should I do something about my fonts installation ? -- Jean-Pierre
Re: #7964: LyX-Enhanced Chat
On 09/10/2016 01:37, Scott Kostyshak wrote: Is there any documentation for it? for now, it's all here: http://www.lyx.org/trac/ticket/7964 quick start guide, compile: 1. recompile qxmpp from sources available at: http://retis.sssup.it/~tommaso/qxmpp (or install straight the .deb available there) 2. compile LyX with the chat patch configuring with '--enable-qt5' '--with-extra-inc=/usr/include/x86_64-linux-gnu/qt5/QtNetwork:/usr/include/x86_64-linux-gnu/qt5/QtGui' use: 1. start LyX, choose Tools->LyX Chat 2. in the "Buddies" pane, put your Id (username@domain) of an existing XMPP account (e.g., create one for free on Jabber) 3. click "Connect", enter your access password (these will be cached in your $HOME/.lyx/ as \user_chat_id etc... 4. add/connect to a new buddy by using the "Add" button (enter the username@domain of the buddy) 5. double-click on a buddy, and have fun chat :-)! (your buddy can connect either with LyX or a regular text client, e.g., Pidgin, in such case they would see LaTeX text segments rather than enjoying the beautifully rendered LyX) Notes: 1. no networking is ever started by LyX, unless you start the "LyX Chat" 2. if you close the chat dialogs, the XMPP client keeps running and will show the chat back if anyone writes you 3. an option to shut down any chat / network might be useful, due to 2, as well as a statusbar indication that the chat is still connected 4. your XMPP password is stored cleartext in your .lyx/ directory (an option could be useful to never store the password if wanted) Videos of the LyX chat in action: -) http://www.youtube.com/watch?v=lQnVxbX8A3w -) http://www.youtube.com/watch?v=n0Xfi8Ohx7Y(+Irish intro) Please write, should anything be unclear, thanks :-)! T.