Re: Commit 52eee8e5 not sent to lyx-cvs because too large?

[Richard Heck]

On 06/06/2017 05:04 PM, Richard Heck wrote:
> On 06/06/2017 03:35 PM, Scott Kostyshak wrote:
>> On Sun, Jun 04, 2017 at 10:58:52PM -0400, Richard Heck wrote:
>>> On 06/04/2017 09:02 PM, Scott Kostyshak wrote:
 Commit 52eee8e5 ("Fix .po files") was not sent to lyx-cvs. I imagine it
 is because the commit is 13MB. I think it is a good decision not to send
 patches that are too large, but it would be nice to receive at least the
 commit message and the stats (which files were changed), and possibly a
 message at the end that says the patch is too large to include.
>>> I'm guessing the SMTP server rejected the message. There's nothing in
>>> the email sending script, so far as I'm aware, that would stop its being
>>> sent. I'm not sure if there's some way to see how big the commit is and
>>> omit the diff in some cases. That'd maybe be a good feature anyway,
>>> since remerges are just annoying in that regard. If someone wants to
>>> look at this, I can provide some pointers.
>> Ah good to know. I agree it would be nice to have a limit anyway. I
>> would make the limit pretty small. 500K? It is so easy to just do a
>>
>> git fetch
>>
>> and I imagine most people subscribed to the list would prefer to keep
>> their mail folder small.
> I've managed to produce a working script that just sends a basic
> message, e.g.:
>
> commit 938e49171b8e2203154379d6a4dd2a6400141ab8
> Author: Enrico Forestieri 
> Date:   Mon Dec 5 02:51:47 2016 +0100
>
> Update it.po
>
>  po/it.gmo |  Bin 489376 -> 499301 bytes
>  po/it.po  | 3615 
> ++---
>  2 files changed, 2047 insertions(+), 1568 deletions(-)
>
>
> for 'long' commits. The question is: What should count as a long commit?
> Note that we are measuring here the size of the string returned by "git
> show --patch-with-stat". I've tried it with 32000, and that does get rid
> of the really huge ones, but it also leaves some pretty huge ones. Any
> thought? If you think about an 80 character line, that 32000 bytes would
> be minimum 4000 lines.

I checked the last 1000 commits to 2.2.x, and setting the limit to 32000
failed to send a complete commit log for only one commit for which you
might want it: 54248a6e, which was Jurgen's citation dialog redesign,
and which was 34281 bytes. That's a pretty unusual case, largely because
almost the whole CitationUi.ui file was changed. Raising the limit to
48000 to allow that one would also let in nine commits for which the
messages make little sense: po file and documentation updates. But
that's not too bad, either. Going up to 64000 lets in quite a lot of junk.

Richard

PS For anyone who wants to play with this, the testing script is:

for i in $(git rev-list --max-count=1000 2.2.x); do B=$(git show
--patch-with-stat $i | wc -c); if [ $B -gt 32000 -a $B -lt 48000 ]; then
echo $B; git show --stat $i | head -n 5 | tail -n 1; fi; done

Richard

>
> Richard
>

Re: Commit 52eee8e5 not sent to lyx-cvs because too large?

[Richard Heck]

On 06/06/2017 03:35 PM, Scott Kostyshak wrote:
> On Sun, Jun 04, 2017 at 10:58:52PM -0400, Richard Heck wrote:
>> On 06/04/2017 09:02 PM, Scott Kostyshak wrote:
>>> Commit 52eee8e5 ("Fix .po files") was not sent to lyx-cvs. I imagine it
>>> is because the commit is 13MB. I think it is a good decision not to send
>>> patches that are too large, but it would be nice to receive at least the
>>> commit message and the stats (which files were changed), and possibly a
>>> message at the end that says the patch is too large to include.
>> I'm guessing the SMTP server rejected the message. There's nothing in
>> the email sending script, so far as I'm aware, that would stop its being
>> sent. I'm not sure if there's some way to see how big the commit is and
>> omit the diff in some cases. That'd maybe be a good feature anyway,
>> since remerges are just annoying in that regard. If someone wants to
>> look at this, I can provide some pointers.
> Ah good to know. I agree it would be nice to have a limit anyway. I
> would make the limit pretty small. 500K? It is so easy to just do a
>
> git fetch
>
> and I imagine most people subscribed to the list would prefer to keep
> their mail folder small.

I've managed to produce a working script that just sends a basic
message, e.g.:

commit 938e49171b8e2203154379d6a4dd2a6400141ab8
Author: Enrico Forestieri 
Date:   Mon Dec 5 02:51:47 2016 +0100

Update it.po

 po/it.gmo |  Bin 489376 -> 499301 bytes
 po/it.po  | 3615 ++---
 2 files changed, 2047 insertions(+), 1568 deletions(-)


for 'long' commits. The question is: What should count as a long commit?
Note that we are measuring here the size of the string returned by "git
show --patch-with-stat". I've tried it with 32000, and that does get rid
of the really huge ones, but it also leaves some pretty huge ones. Any
thought? If you think about an 80 character line, that 32000 bytes would
be minimum 4000 lines.

Richard

Re: Re-organizing templates and examples folders (#8715)

[Guenter Milde]

On 2017-06-01, Scott Kostyshak wrote:

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

> On Wed, May 03, 2017 at 08:37:17PM +, Guenter Milde wrote:
>> Dear LyX developers,

>> with feature freeze nearing, I'd like to take up the discussion of
>> templates and examples folders:

> Does anyone else have comments regarding Günter's proposal? Günter, are
> you volunteering to do everything you proposed?

Unfortunately, I don't know how to set up symlink creation for
  $LYX_USERDIR/templates/stdtemplates -> $LYX_DIR/templates

Nor do I know where to change the default templates dir path from
$LYX_DIR/templates to $LYX_USERDIR/templates.

All I can do, is appending a patch moving the non-English templates into
"language subdirectories". I don't know whether it is complete, though,
maybe there some other listing of the templates (for cmake, say).

Günter



>From 36473d2dbdc7d623b3f21585540e417801808cfb Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?G=C3=BCnter=20Milde?= 
Date: Tue, 6 Jun 2017 22:25:24 +0200
Subject: [PATCH] Move non-English templates to language subdirectories.

---
 lib/Makefile.am| 24 --
 .../beamer-conference-ornate-20min.lyx}|  0
 lib/templates/{ => de}/dinbrief.lyx|  0
 .../beamer-conference-ornate-20min.lyx}|  0
 .../beamer-conference-ornate-20min.lyx}|  0
 lib/templates/{ => fr}/frletter.lyx|  0
 .../beamer-conference-ornate-20min.lyx}|  0
 lib/templates/{ => zh_CN}/ctex.lyx |  0
 8 files changed, 18 insertions(+), 6 deletions(-)
 rename lib/templates/{de_beamer-conference-ornate-20min.lyx => 
de/beamer-conference-ornate-20min.lyx} (100%)
 rename lib/templates/{ => de}/dinbrief.lyx (100%)
 rename lib/templates/{es_beamer-conference-ornate-20min.lyx => 
es/beamer-conference-ornate-20min.lyx} (100%)
 rename lib/templates/{fr_beamer-conference-ornate-20min.lyx => 
fr/beamer-conference-ornate-20min.lyx} (100%)
 rename lib/templates/{ => fr}/frletter.lyx (100%)
 rename lib/templates/{ja_beamer-conference-ornate-20min.lyx => 
ja/beamer-conference-ornate-20min.lyx} (100%)
 rename lib/templates/{ => zh_CN}/ctex.lyx (100%)

diff --git a/lib/Makefile.am b/lib/Makefile.am
index fc9b7752df..229dbd4346 100644
--- a/lib/Makefile.am
+++ b/lib/Makefile.am
@@ -2367,15 +2367,10 @@ dist_templates_DATA = \
templates/APA6.lyx \
templates/beamer-conference-ornate-20min.lyx \
templates/ctex.lyx \
-   templates/de_beamer-conference-ornate-20min.lyx \
-   templates/dinbrief.lyx \
templates/DocBook_article.lyx \
templates/ectaart.lyx \
templates/elsarticle.lyx \
templates/EPS-cropped.lyx \
-   templates/es_beamer-conference-ornate-20min.lyx \
-   templates/fr_beamer-conference-ornate-20min.lyx \
-   templates/frletter.lyx \
templates/g-brief2.lyx \
templates/hollywood.lyx \
templates/IEEEtran-CompSoc.lyx \
@@ -2386,7 +2381,6 @@ dist_templates_DATA = \
templates/IJMPD.lyx \
templates/IOP-article.lyx \
templates/IUCr-article.lyx \
-   templates/ja_beamer-conference-ornate-20min.lyx \
templates/JASA.lyx \
templates/JSS-article.lyx \
templates/kluwer.lyx \
@@ -2412,6 +2406,24 @@ dist_obsoletetemplates_DATA = \
templates/obsolete/g-brief-de.lyx \
templates/obsolete/g-brief-en.lyx
 
+detemplatesdir = $(pkgdatadir)/examples/de
+dist_detemplates_DATA = \
+   templates/de/beamer-conference-ornate-20min.lyx \
+   templates/de/dinbrief.lyx
+
+estemplatesdir = $(pkgdatadir)/examples/es
+dist_estemplates_DATA = \
+   templates/es/beamer-conference-ornate-20min.lyx
+
+frtemplatesdir = $(pkgdatadir)/examples/fr
+dist_frtemplates_DATA = \
+   templates/fr/beamer-conference-ornate-20min.lyx \
+   templates/fr/frletter.lyx
+
+jatemplatesdir = $(pkgdatadir)/examples/ja
+dist_jatemplates_DATA = \
+   templates/ja/beamer-conference-ornate-20min.lyx
+
 springertemplatesdir = $(pkgdatadir)/templates/springer
 dist_springertemplates_DATA = \
templates/springer/svjour3.lyx
diff --git a/lib/templates/de_beamer-conference-ornate-20min.lyx 
b/lib/templates/de/beamer-conference-ornate-20min.lyx
similarity index 100%
rename from lib/templates/de_beamer-conference-ornate-20min.lyx
rename to lib/templates/de/beamer-conference-ornate-20min.lyx
diff --git a/lib/templates/dinbrief.lyx b/lib/templates/de/dinbrief.lyx
similarity index 100%
rename from lib/templates/dinbrief.lyx
rename to lib/templates/de/dinbrief.lyx
diff --git a/lib/templates/es_beamer-conference-ornate-20min.lyx 
b/lib/templates/es/beamer-conference-ornate-20min.lyx
similarity index 100%
rename from lib/templates/es_beamer-conference-ornate-20min.lyx
rename to lib/templates/es/beamer-conference-ornate-20min.lyx
diff --git a/lib/templates/fr_beamer-conference-ornate-20min.lyx 

Re: beta will be delayed for translations

[Scott Kostyshak]

On Mon, May 29, 2017 at 11:09:59PM -0400, Scott Kostyshak wrote:

> I hope to have a revised date for beta1 by this

I'm stuck on how to update our translations in master from our 2.2.x
branch (see [1]), which means I can't send out an email to the
translators, which means I don't have a new date for beta1 yet.

Scott

[1]
https://www.mail-archive.com/search?l=mid=20170530030955.mj32j736mgxhvzk7%40steph


signature.asc
Description: PGP signature

Re: Copying translations from 2.2.x to master?

[Scott Kostyshak]

On Sat, Jun 03, 2017 at 08:07:39PM -0400, Scott Kostyshak wrote:

> Unless someone has a different idea, I will replace the Windows
> linebreaks with non-Windows linebreaks, update the strings on master,
> and try the mergepo.py call above again.

After Kornel's fixes to the Windows linebreaks, I tried mergepo.py again
but it did not update any translations.

Any other ideas?

Scott


signature.asc
Description: PGP signature

Re: [LyX/master] Add an external template for minted

[Scott Kostyshak]

On Mon, May 29, 2017 at 05:54:32PM -0400, Scott Kostyshak wrote:
> On Mon, May 29, 2017 at 01:38:16PM +0200, Kornel Benko wrote:
> 
> > Ehm, my mistake. I inserted "-shel-escape" instead of "-shell-escape" in 
> > the converter.
> 
> I suppose for these tests to pass, we need to use a special preference
> file that changes the converters. I forget, do we currently allow for a
> test to use a different preference file?

I guess we have the following options:

1. Ignore the tests for now.

2. Implement different preferences for different tests.

3. Make a new format, make a new converter for that format that is
basically the same as our current converter but hasa the shell-escape
option, and then use that converter for the new format.

Scott

Re: Update: polyglossia in 2.2.3

[Scott Kostyshak]

On Mon, Jun 05, 2017 at 03:16:07PM +0200, N. Andrew Walsh wrote:

> > > Could you also post the LaTeX export (to LaTeX (XeTeX)) of this MWE?
> >
> > Andrew, I just wanted to make sure you saw the above message.
> >
> Yes, I saw. I'm copied on the bug report, and have since submitted several
> updates. There's a patch on the bug report that should resolve the issue
> (and is going into 2.3.0) that resolves it for other users.

Ah great! Thanks for your response,

Scott

Re: Gnuplot format & converter script

[Scott Kostyshak]

On Tue, Jun 06, 2017 at 12:51:33AM +0200, Tommaso Cucinotta wrote:
> from the help message this sounds interesting, I also thought
> we could have had various terminal types, and get .gp to .pdf,
> to .eps, etc, albeit it's sufficient to convert to one
> vectorial format, and LyX knows how to get to the others.
> Perhaps among the most useful things, is that 1) you can use this
> script to render on screen through the .gp interactive capabilities,
> using the same unmodified .gp script that is included in .lyx;
> 2) the terminal options, but theburden is that each document
> (even each use of .gp scripts) might need slightly different options...
> 
> not really much time in these days, but this script might easily
> replace the gnuplot2pdf.py one, with proper invokation in configure.py.
> (-t pdf). However, I can't get at a glance the why of all of this
> lines' parsing & mangling. guess it's a try to be robust w.r.t. various
> different contents of the .gp script.

Thanks for taking a look, Tommaso. I CC the author of the script, Koji.
He might be able to answer any specific questions whenever you have
time.

Scott

Re: Commit 52eee8e5 not sent to lyx-cvs because too large?

[Scott Kostyshak]

On Sun, Jun 04, 2017 at 10:58:52PM -0400, Richard Heck wrote:
> On 06/04/2017 09:02 PM, Scott Kostyshak wrote:
> > Commit 52eee8e5 ("Fix .po files") was not sent to lyx-cvs. I imagine it
> > is because the commit is 13MB. I think it is a good decision not to send
> > patches that are too large, but it would be nice to receive at least the
> > commit message and the stats (which files were changed), and possibly a
> > message at the end that says the patch is too large to include.
> 
> I'm guessing the SMTP server rejected the message. There's nothing in
> the email sending script, so far as I'm aware, that would stop its being
> sent. I'm not sure if there's some way to see how big the commit is and
> omit the diff in some cases. That'd maybe be a good feature anyway,
> since remerges are just annoying in that regard. If someone wants to
> look at this, I can provide some pointers.

Ah good to know. I agree it would be nice to have a limit anyway. I
would make the limit pretty small. 500K? It is so easy to just do a

git fetch

and I imagine most people subscribed to the list would prefer to keep
their mail folder small.

Scott

Re: ext_copy.py

[Scott Kostyshak]

On Sun, May 28, 2017 at 01:23:14PM -0400, Scott Kostyshak wrote:
> On Thu, May 25, 2017 at 12:31:05PM +1200, Andrew Parsloe wrote:
> > 
> > On 24/05/2017 9:24 p.m., José Abílio Matos wrote:
> > > On Wednesday, 24 May 2017 03.51.55 WEST Scott Kostyshak wrote:
> > > 
> > > > Any objection from anyone else?
> > > 
> > > 
> > > > Scott
> > > 
> > > Honestly the use of the plus sign as a special character seems unnatural
> > > to me. :-)
> > > 
> > > My suggestion would be to pass an option that specify just that, say -d.
> > > The advantage of this approach it that it does not add new special
> > > characters.
> > > 
> > > A patch follows attached. I have not updated the documentation.
> > > Regards,
> > > 
> > > José Abílio
> > > 
> > Thank you José. I was the person requesting this, and yes, -d is better than
> > using +.
> 
> José do you think the patch should go in for 2.3.0? If so go ahead.

José I just wanted to make sure you saw the above message.

Scott


signature.asc
Description: PGP signature