Re: Compiling with Microsoft Visual C++

2016-10-09 Thread racoon
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

2016-10-09 Thread Scott Kostyshak
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 Kostyshak 
Date: 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

2016-10-09 Thread Scott Kostyshak
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

2016-10-09 Thread Uwe Stöhr

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

2016-10-09 Thread Scott Kostyshak
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?

2016-10-09 Thread Uwe Stöhr

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

2016-10-09 Thread Tommaso Cucinotta

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

2016-10-09 Thread Kornel Benko
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

2016-10-09 Thread Scott Kostyshak
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

2016-10-09 Thread Scott Kostyshak
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

2016-10-09 Thread 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.

Scott


signature.asc
Description: PGP signature


Re: [patch] Factor out magic zoom minimum to a const member

2016-10-09 Thread Guillaume Munch

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

2016-10-09 Thread Guenter Milde
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

2016-10-09 Thread Scott Kostyshak
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

2016-10-09 Thread Guenter Milde
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

2016-10-09 Thread Scott Kostyshak
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

2016-10-09 Thread Guenter Milde
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

2016-10-09 Thread Scott Kostyshak
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

2016-10-09 Thread Scott Kostyshak
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

2016-10-09 Thread Scott Kostyshak
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

2016-10-09 Thread Guillaume Munch

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!




Re: ctests: give output of LaTeX error

2016-10-09 Thread Kornel Benko
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

2016-10-09 Thread Enrico Forestieri
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

2016-10-09 Thread 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.

> Scott

Kornel

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


Re: LyX docs: cleaning up math options

2016-10-09 Thread Scott Kostyshak
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

2016-10-09 Thread Scott Kostyshak
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

2016-10-09 Thread Guenter Milde
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

2016-10-09 Thread Guenter Milde
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

2016-10-09 Thread 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

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

2016-10-09 Thread Scott Kostyshak
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

2016-10-09 Thread Guenter Milde
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

2016-10-09 Thread Guenter Milde
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

2016-10-09 Thread Scott Kostyshak
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

2016-10-09 Thread Scott Kostyshak
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

2016-10-09 Thread Scott Kostyshak
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

2016-10-09 Thread Jean-Pierre Chrétien

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

2016-10-09 Thread Jean-Pierre Chrétien

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

2016-10-09 Thread Tommaso Cucinotta

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.