Re: blah (issue 320290043 by pkx1...@gmail.com)

[paulwmorris]

On 2017/03/05 13:44:00, pkx166h wrote:

more fixes to Hungarian to make this bloody thing compile.


LGTM. Thank you James for working this out and making the necessary
changes.

-Paul

https://codereview.appspot.com/320290043/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: can't upload a patch

[Federico Bruni]

Il giorno lun 6 mar 2017 alle 17:49, David Nalesnik 
 ha scritto:

On Mon, Mar 6, 2017 at 8:56 AM, David Kastrup  wrote:

 David Nalesnik  writes:

 On Mon, Mar 6, 2017 at 8:29 AM, Federico Bruni 
 wrote:



 Il giorno lun 6 mar 2017 alle 14:50, David Nalesnik
  ha scritto:


 Hi Federico,

 On Mon, Mar 6, 2017 at 1:15 AM, Federico Bruni 
 wrote:


  Do you have ca-certificates installed?



 Yes, the newest version:

 ca-certificates/now 20141019+deb8u1 all [installed,local]


 Ok. Even though it seems an out-of-date package. Shouldn't it be 
version

 20160104 as shown here?
 http://packages.ubuntu.com/yakkety/ca-certificates


 Strange.  The package did strike me as old, but running

 sudo apt-get install ca-certificates

 gets me

 Reading package lists... Done
 Building dependency tree
 Reading state information... Done
 ca-certificates is already the newest version.
 0 upgraded, 0 newly installed, 0 to remove and 69 not upgraded.


 Maybe it's pinned or the version number is spelled in a manner 
where it

 is considered newer.

 Try removing and reinstalling it if possible without having other
 packages removed.  Otherwise, try forcing the update.



The version in Ubuntu is the one from 2016; the one in the Debian
machine is the older one, from 2014.  I'm not sure what to install to
bring the Debian version more up-to-date, without screwing the system
up.



Before doing so, I wonder if any other developer using LilyDev 4.1 
(maybe Harm?) can confirm if git-cl is working or not.

I don't have LilyDev 4.1 at hands to test git-cl.


I managed to upload the patch successfully
(https://sourceforge.net/p/testlilyissues/issues/5084/) by installing
git-cl in Ubuntu -- thanks Federico!

So, I haven't verified whether the problem is the ca-certificates
version or the VM's network interface.  I'll try an Ethernet cable
instead of the wireless adapter next.




I've seen also reports about proxy settings causing this sort of 
troubles.

So you may check it on your Ubuntu host:

env | grep -i proxy





___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Website upload

[Urs Liska]

Am 07.03.2017 um 15:57 schrieb Urs Liska:
> So ideally someone (as said I can't build currently) could grep through
> the whole built website, taking the attached file (produced by a
> combination of grep and sed) as the basis and this line:
>
> for f in $(cat to-be-deleted.txt); do git grep -n $f; done

Ah, of course that should not be git grep (because the built stuff
shouldn't be tracked) but probably

for f in $(cat to-be-deleted.txt); do grep -n -r $f *; done



-- 
u...@openlilylib.org
https://openlilylib.org
http://lilypondblog.org


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Website upload

[Phil Holmes]

- Original Message - 
From: "David Kastrup" 

To: "Phil Holmes" 
Cc: "Urs Liska" ; 
Sent: Tuesday, March 07, 2017 2:44 PM
Subject: Re: Website upload



"Phil Holmes"  writes:


I did run it to start with without the ---no-r and without redirecting
the output.  The output I got on my terminal was a load of lines like:

.f...p. pictures/ties-scoring-example.png

and I was concerned that this meant that those files would be deleted,
so I thought it better to restrict it to the root directory.  I now
understand the output a bit better.  I've since repeated it with the
recurse option with the result attached.  As you see, it would delete
a lot of files we want to keep (examples) but it could be possible to
use its output as a guide for manual deletion?


I'm still surprised at the small size of the list: what's with the
gazillion of image files?


I assume they're created by GUB and rsynced during upload to a different 
part of the server.



And is there some possibility of assembling the example files into the
prepared web page before doing the rsync call?  It seems awkward and
error-prone to have two different sync operations.


http://lilypond.org/doc/v2.19/Documentation/contributor/uploading-and-security 
shows the current way it's done.  Probably lost in the mists of time why 
this is.  See ### make-website.sh on that page.


--
Phil Holmes 



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Website upload

[Urs Liska]

Am 07.03.2017 um 15:34 schrieb Phil Holmes:
> - Original Message - From: "David Kastrup" 
> To: "Phil Holmes" 
> Cc: "Urs Liska" ; 
> Sent: Tuesday, March 07, 2017 1:56 PM
> Subject: Re: Website upload
>
>
>> "Phil Holmes"  writes:
>>
>>> Sorry for top post - as you see my email client doesn't properly
>>> indent your reply.
>>>
>>> Anyway, I've now done the following command:
>>>
>>> rsync -n -aO -d --no-r --delete -i $BUILD/out-website/website/
>>> $DEST/website/ &>rs.txt
>>>
>>> Which gives the output in the attached file.  I guess this means it
>>> would only delete the filenames preceded by "*deleting" - I assume the
>>> other files named are just for information?
>>
>> Or update.  But I am afraid that for looking at a dry-run, I'd leave off
>> the --no-r (no recursive directory descent) option.  The output will be
>> humongous but complete.
>>
>> -- 
>> David Kastrup
>
>
> I did run it to start with without the ---no-r and without redirecting
> the output.  The output I got on my terminal was a load of lines like:
>
> .f...p. pictures/ties-scoring-example.png
>
> and I was concerned that this meant that those files would be deleted,
> so I thought it better to restrict it to the root directory.  I now
> understand the output a bit better.  I've since repeated it with the
> recurse option with the result attached.  As you see, it would delete
> a lot of files we want to keep (examples) but it could be possible to
> use its output as a guide for manual deletion?

I did *some* random checks by searching the source text of
http://lilypond.org/examples.html for links to those files listed as
to-be-deleted, and it seems none of them is actually used anymore in the
page. I did *not* try to download the whole thing and grep for it, but I
have the strong suspicion that files like
ly-examples/tab-example.preview.eps actually *are* the kind of orphaned
files we are talking about (victims of the latest review of the examples
page?)

So ideally someone (as said I can't build currently) could grep through
the whole built website, taking the attached file (produced by a
combination of grep and sed) as the basis and this line:

for f in $(cat to-be-deleted.txt); do git grep -n $f; done

This should return all places in the website where the to-be-deleted
files are referenced - and my hypothesis it would return nothing.

Urs

>
> -- 
> Phil Holmes 

-- 
u...@openlilylib.org
https://openlilylib.org
http://lilypondblog.org

text-to-speech.css
testimonials.nl.html
testimonials.it.html
testimonials.hu.html
testimonials.html
testimonials.fr.html
testimonials.es.html
testimonials.en.html
miscellaneous.fr.html
lilypond.css
lilypond-website.css
lilypond-web.css
lilypond-web-alt2.css
lilypond-web-alt1.css
lilypond-mccarty.css
lilypond-manuals.css
lilypond-ie-fixes.css
lilypond-blue.css
interested-developers.fr.html
index.html~
index-orig.html
index-g+.html
gsoc.nl.html
gsoc.ja.html
gsoc.it.html
gsoc.html
gsoc.fr.html
gsoc.es.html
gsoc.en.html
gsoc.de.html
extend.hu.html
extend.es.html
extend.de.html
extend.cs.html
discussions-and-help.fr.html
ly-examples/theory.preview.pdf
ly-examples/theory.preview.eps
ly-examples/theory.pdf
ly-examples/tab-example.preview.pdf
ly-examples/tab-example.preview.eps
ly-examples/tab-example.pdf
ly-examples/sesto-violin.preview.pdf
ly-examples/sesto-violin.preview.eps
ly-examples/sesto-violin.pdf
ly-examples/sesto-piano.preview.pdf
ly-examples/sesto-piano.preview.eps
ly-examples/sesto-piano.pdf
ly-examples/sesto-full.preview.pdf
ly-examples/sesto-full.preview.eps
ly-examples/sesto-full.pdf
ly-examples/orchestra.preview.pdf
ly-examples/orchestra.preview.eps
ly-examples/orchestra.pdf
ly-examples/granados.preview.pdf
ly-examples/granados.preview.eps
ly-examples/granados.pdf
ly-examples/dummy.dep
ly-examples/chart.preview.pdf
ly-examples/chart.preview.eps
ly-examples/chart.pdf
ly-examples/cary.preview.pdf
ly-examples/cary.preview.eps
ly-examples/cary.pdf
ly-examples/bach-schenker.preview.pdf
ly-examples/bach-schenker.preview.eps
ly-examples/bach-schenker.pdf
ly-examples/bach-bwv610.preview.pdf
ly-examples/bach-bwv610.preview.eps
ly-examples/bach-bwv610.pdf
ly-examples/aucun-snippet.preview.pdf
ly-examples/aucun-snippet.preview.eps
ly-examples/aucun-snippet.pdf
ly-examples/ancient-headword.preview.pdf
ly-examples/ancient-headword.preview.eps
ly-examples/ancient-headword.pdf
pdf/25.pdf
pictures/pictures
pictures/dummy.dep
pictures/context-example.pdf
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Website upload

[David Kastrup]

"Phil Holmes"  writes:

> I did run it to start with without the ---no-r and without redirecting
> the output.  The output I got on my terminal was a load of lines like:
>
> .f...p. pictures/ties-scoring-example.png
>
> and I was concerned that this meant that those files would be deleted,
> so I thought it better to restrict it to the root directory.  I now
> understand the output a bit better.  I've since repeated it with the
> recurse option with the result attached.  As you see, it would delete
> a lot of files we want to keep (examples) but it could be possible to
> use its output as a guide for manual deletion?

I'm still surprised at the small size of the list: what's with the
gazillion of image files?

And is there some possibility of assembling the example files into the
prepared web page before doing the rsync call?  It seems awkward and
error-prone to have two different sync operations.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Website upload

[Davide Liessi]

2017-03-07 15:35 GMT+01:00 Phil Holmes :
> Could this be done as part of the website build process (e.g. adding a gsoc
> source file back in and configuring the system to make it into a redirect),
> or would it have to be done manually?

Assuming the web server is Apache, it is just a matter of adding lines
to .htaccess.
Other web servers have similar ways to add redirects.

So if .htaccess (or the appropriate server configuration file) is
generated when building the website, the answer is yes.

Best wishes.
Davide

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Website upload

[Phil Holmes]

- Original Message - 
From: "Paul" 

To: 
Sent: Tuesday, March 07, 2017 2:09 PM
Subject: Re: Website upload



On 03/07/2017 05:47 AM, Davide Liessi wrote:

Maybe an HTTP permanent redirect (308) should be added instead of a 
symlink, see

https://en.wikipedia.org/wiki/List_of_HTTP_status_codes#3xx_Redirection


+1

Best policy would be whenever a page changes its file name we should 
create a permanent redirect to the new page/file/name.  Search engines can 
then follow these redirects and transfer their ranking data for the old 
page to the new page.


(The old GSOC page is likely still at the top of the search results 
because there are links to it out on the web and the search engines use 
those to rank that page relative to others.)


Cheers,
-Paul



Could this be done as part of the website build process (e.g. adding a gsoc 
source file back in and configuring the system to make it into a redirect), 
or would it have to be done manually?


--
Phil Holmes 



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Website upload

[Phil Holmes]

- Original Message - 
From: "David Kastrup" 

To: "Phil Holmes" 
Cc: "Urs Liska" ; 
Sent: Tuesday, March 07, 2017 1:56 PM
Subject: Re: Website upload



"Phil Holmes"  writes:


Sorry for top post - as you see my email client doesn't properly
indent your reply.

Anyway, I've now done the following command:

rsync -n -aO -d --no-r --delete -i $BUILD/out-website/website/
$DEST/website/ &>rs.txt

Which gives the output in the attached file.  I guess this means it
would only delete the filenames preceded by "*deleting" - I assume the
other files named are just for information?


Or update.  But I am afraid that for looking at a dry-run, I'd leave off
the --no-r (no recursive directory descent) option.  The output will be
humongous but complete.

--
David Kastrup



I did run it to start with without the ---no-r and without redirecting the 
output.  The output I got on my terminal was a load of lines like:


.f...p. pictures/ties-scoring-example.png

and I was concerned that this meant that those files would be deleted, so I 
thought it better to restrict it to the root directory.  I now understand 
the output a bit better.  I've since repeated it with the recurse option 
with the result attached.  As you see, it would delete a lot of files we 
want to keep (examples) but it could be possible to use its output as a 
guide for manual deletion?


--
Phil Holmes 

*deleting   text-to-speech.css
*deleting   testimonials.nl.html
*deleting   testimonials.it.html
*deleting   testimonials.hu.html
*deleting   testimonials.html
*deleting   testimonials.fr.html
*deleting   testimonials.es.html
*deleting   testimonials.en.html
*deleting   miscellaneous.fr.html
*deleting   lilypond.css
*deleting   lilypond-website.css
*deleting   lilypond-web.css
*deleting   lilypond-web-alt2.css
*deleting   lilypond-web-alt1.css
*deleting   lilypond-mccarty.css
*deleting   lilypond-manuals.css
*deleting   lilypond-ie-fixes.css
*deleting   lilypond-blue.css
*deleting   interested-developers.fr.html
*deleting   index.html~
*deleting   index-orig.html
*deleting   index-g+.html
*deleting   gsoc.nl.html
*deleting   gsoc.ja.html
*deleting   gsoc.it.html
*deleting   gsoc.html
*deleting   gsoc.fr.html
*deleting   gsoc.es.html
*deleting   gsoc.en.html
*deleting   gsoc.de.html
*deleting   extend.hu.html
*deleting   extend.es.html
*deleting   extend.de.html
*deleting   extend.cs.html
*deleting   discussions-and-help.fr.html
.f...p. .htaccess

f..tp. acknowledgements.ca.html
f..t.. acknowledgements.de.html
f..t.. acknowledgements.es.html
f..t.. acknowledgements.html
f..t.. acknowledgements.it.html
f..t.. acknowledgements.ja.html
f..t.. acknowledgements.nl.html
f..tp. all.ca.html
f..t.. all.cs.html
f..t.. all.de.html

.L..t.. all.en.html -> all.html

f..t.. all.es.html
f..t.. all.fr.html
f..t.. all.html
f..t.. all.hu.html
f..t.. all.it.html
f..t.. all.ja.html
f..t.. all.nl.html
f..t.. all.zh.html
f..tp. attic.ca.html
f..t.. attic.de.html

.L..t.. attic.en.html -> attic.html

f..t.. attic.es.html
f..t.. attic.fr.html
f..t.. attic.html
f..t.. attic.hu.html
f..t.. attic.it.html
f..t.. attic.ja.html
f..t.. attic.nl.html
f..t.. attic.zh.html
f..tp. authors.ca.html
f..t.. authors.cs.html
f..t.. authors.de.html

.L..t.. authors.en.html -> authors.html

f..t.. authors.es.html
f..t.. authors.fr.html
f..t.. authors.html
f..t.. authors.hu.html
f..t.. authors.it.html
f..t.. authors.ja.html
f..t.. authors.nl.html
f..t.. authors.zh.html
f..tp. background.ca.html
f..t.. background.cs.html
f..t.. background.de.html

.L..t.. background.en.html -> background.html

f..t.. background.es.html
f..t.. background.fr.html
f..t.. background.html
f..t.. background.hu.html
f..t.. background.it.html
f..t.. background.ja.html
f..t.. background.nl.html
f..t.. background.zh.html
f..tp. bug-reports.ca.html
f..t.. bug-reports.cs.html
f..t.. bug-reports.de.html

.L..t.. bug-reports.en.html -> bug-reports.html

f..t.. bug-reports.es.html
f..t.. bug-reports.fr.html
f..t.. bug-reports.html
f..t.. bug-reports.hu.html
f..t.. bug-reports.it.html
f..t.. bug-reports.ja.html
f..t.. bug-reports.nl.html
f..t.. bug-reports.zh.html
f..tp. changes.ca.html
f..t.. changes.cs.html
f..t.. changes.de.html

.L..t.. changes.en.html -> changes.html

f..t.. changes.es.html
f..t.. changes.fr.html
f..t.. changes.html
f..t.. changes.hu.html
f..t.. changes.it.html
f..t.. changes.ja.html
f..t.. changes.nl.html
f..t.. changes.zh.html
f..tp. community.ca.html
f..t.. community.cs.html
f..t.. community.de.html

.L..t.. community.en.html -> community.html

f..t.. 

Re: Website upload

[Paul]

On 03/07/2017 05:47 AM, Davide Liessi wrote:


Maybe an HTTP permanent redirect (308) should be added instead of a symlink, see
https://en.wikipedia.org/wiki/List_of_HTTP_status_codes#3xx_Redirection


+1

Best policy would be whenever a page changes its file name we should 
create a permanent redirect to the new page/file/name.  Search engines 
can then follow these redirects and transfer their ranking data for the 
old page to the new page.


(The old GSOC page is likely still at the top of the search results 
because there are links to it out on the web and the search engines use 
those to rank that page relative to others.)


Cheers,
-Paul

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Website upload

[David Kastrup]

"Phil Holmes"  writes:

> Sorry for top post - as you see my email client doesn't properly
> indent your reply.
>
> Anyway, I've now done the following command:
>
> rsync -n -aO -d --no-r --delete -i $BUILD/out-website/website/
> $DEST/website/ &>rs.txt
>
> Which gives the output in the attached file.  I guess this means it
> would only delete the filenames preceded by "*deleting" - I assume the
> other files named are just for information?

Or update.  But I am afraid that for looking at a dry-run, I'd leave off
the --no-r (no recursive directory descent) option.  The output will be
humongous but complete.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Website upload

[Urs Liska]

Am 07.03.2017 um 14:51 schrieb Phil Holmes:
> Sorry for top post - as you see my email client doesn't properly
> indent your reply.
>
> Anyway, I've now done the following command:
>
> rsync -n -aO -d --no-r --delete -i $BUILD/out-website/website/
> $DEST/website/ &>rs.txt
>
> Which gives the output in the attached file.  I guess this means it
> would only delete the filenames preceded by "*deleting" - 

Looks like it.

> I assume the other files named are just for information?

No, it states what it would do with them, i.e. probably uploading (or
maybe it also states equality, I don't know).

So probably it should be safe to do the same *without* the -n option,
but probably *after* doing a backup, just in case.
And *after* someone else has confirmed that too.

Then we should probably have a redirect, if that's possible for all
http://lilypond.org/gsoc.* URLs pointing to the English version of
google-summer-of-code.html until April 3.

Urs

>
> -- 
> Phil Holmes
>
>
> - Original Message - From: "David Kastrup" 
> To: "Phil Holmes" 
> Cc: "Urs Liska" ; 
> Sent: Tuesday, March 07, 2017 12:32 PM
> Subject: Re: Website upload
>
>
> "Phil Holmes"  writes:
>
>> - Original Message - From: "Phil Holmes" 
>> To: "David Kastrup" ; "Urs Liska" 
>> Cc: 
>> Sent: Tuesday, March 07, 2017 11:31 AM
>> Subject: Re: Website upload
>>
>>
>>> - Original Message - From: "Urs Liska" 
>>> To: "David Kastrup" 
>>> Cc: "Phil Holmes" ; 
>>> Sent: Tuesday, March 07, 2017 11:08 AM
>>> Subject: Re: Website upload
>>>
>>>
 Maybe someone with privileges on the server could manually run rsync
 with the --delete and the -n (dry run) option and presenting us
 with the
 list of files that would be deleted remotely. Probably this would
 quickly tell us if we have legitimate "orphaned" files.

 Urs
>>>
>>>
>>> That sounds like a good plan.  AFAICS I would need to run the line
>>> from make-website.sh, but with those added options:
>>>
>>> rsync -raO -n --delete $BUILD/out-website/website/ $DEST/website/
>>>
>>> ??
>>
>>
>> Hmm.  Tried that.  No output.
>
> -n, --dry-run
> This makes rsync perform a  trial run that doesn’t make
> any changes (and  produces mostly the same  output as a
> real  run).  It  is most  commonly used  in combination
> with  the -v,  --verbose  and/or -i,  --itemize-changes
> options to  see what  an rsync command  is going  to do
> before one actually runs it.
>
> The  output  of  --itemize-changes is  supposed  to  be
> exactly the same on a dry run and a subsequent real run
> (barring   intentional   trickery   and   system   call
> failures);  if it  isn’t, that’s  a bug.   Other output
> should  be mostly  unchanged,  but may  differ in  some
> areas.  Notably,  a dry  run does  not send  the actual
> data for  file transfers, so --progress  has no effect,
> the  bytes  sent,  bytes received,  literal  data,  and
> matched data statistics are  too small, and the speedup
> value is  equivalent to a  run where no  file transfers
> were needed.
>
> Maybe add -i to the options?
>
> How did you catch the output?  On a terminal or via redirection?  Maybe
> you need to redirect stderr as well?
>

-- 
u...@openlilylib.org
https://openlilylib.org
http://lilypondblog.org


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Website upload

[Phil Holmes]

Sorry for top post - as you see my email client doesn't properly indent your 
reply.


Anyway, I've now done the following command:

rsync -n -aO -d --no-r --delete -i $BUILD/out-website/website/ 
$DEST/website/ &>rs.txt


Which gives the output in the attached file.  I guess this means it would 
only delete the filenames preceded by "*deleting" - I assume the other files 
named are just for information?


--
Phil Holmes


- Original Message - 
From: "David Kastrup" 

To: "Phil Holmes" 
Cc: "Urs Liska" ; 
Sent: Tuesday, March 07, 2017 12:32 PM
Subject: Re: Website upload


"Phil Holmes"  writes:

- Original Message - 
From: "Phil Holmes" 

To: "David Kastrup" ; "Urs Liska" 
Cc: 
Sent: Tuesday, March 07, 2017 11:31 AM
Subject: Re: Website upload


- Original Message - 
From: "Urs Liska" 

To: "David Kastrup" 
Cc: "Phil Holmes" ; 
Sent: Tuesday, March 07, 2017 11:08 AM
Subject: Re: Website upload



Maybe someone with privileges on the server could manually run rsync
with the --delete and the -n (dry run) option and presenting us with the
list of files that would be deleted remotely. Probably this would
quickly tell us if we have legitimate "orphaned" files.

Urs



That sounds like a good plan.  AFAICS I would need to run the line
from make-website.sh, but with those added options:

rsync -raO -n --delete $BUILD/out-website/website/ $DEST/website/

??



Hmm.  Tried that.  No output.


-n, --dry-run
This makes rsync perform a  trial run that doesn’t make
any changes (and  produces mostly the same  output as a
real  run).  It  is most  commonly used  in combination
with  the -v,  --verbose  and/or -i,  --itemize-changes
options to  see what  an rsync command  is going  to do
before one actually runs it.

The  output  of  --itemize-changes is  supposed  to  be
exactly the same on a dry run and a subsequent real run
(barring   intentional   trickery   and   system   call
failures);  if it  isn’t, that’s  a bug.   Other output
should  be mostly  unchanged,  but may  differ in  some
areas.  Notably,  a dry  run does  not send  the actual
data for  file transfers, so --progress  has no effect,
the  bytes  sent,  bytes received,  literal  data,  and
matched data statistics are  too small, and the speedup
value is  equivalent to a  run where no  file transfers
were needed.

Maybe add -i to the options?

How did you catch the output?  On a terminal or via redirection?  Maybe
you need to redirect stderr as well?

--
David Kastrup 

*deleting   text-to-speech.css
*deleting   testimonials.nl.html
*deleting   testimonials.it.html
*deleting   testimonials.hu.html
*deleting   testimonials.html
*deleting   testimonials.fr.html
*deleting   testimonials.es.html
*deleting   testimonials.en.html
*deleting   miscellaneous.fr.html
*deleting   lilypond.css
*deleting   lilypond-website.css
*deleting   lilypond-web.css
*deleting   lilypond-web-alt2.css
*deleting   lilypond-web-alt1.css
*deleting   lilypond-mccarty.css
*deleting   lilypond-manuals.css
*deleting   lilypond-ie-fixes.css
*deleting   lilypond-blue.css
*deleting   interested-developers.fr.html
*deleting   index.html~
*deleting   index-orig.html
*deleting   index-g+.html
*deleting   gsoc.nl.html
*deleting   gsoc.ja.html
*deleting   gsoc.it.html
*deleting   gsoc.html
*deleting   gsoc.fr.html
*deleting   gsoc.es.html
*deleting   gsoc.en.html
*deleting   gsoc.de.html
*deleting   extend.hu.html
*deleting   extend.es.html
*deleting   extend.de.html
*deleting   extend.cs.html
*deleting   discussions-and-help.fr.html
.f...p. .htaccess

f..tp. acknowledgements.ca.html
f..t.. acknowledgements.de.html
f..t.. acknowledgements.es.html
f..t.. acknowledgements.html
f..t.. acknowledgements.it.html
f..t.. acknowledgements.ja.html
f..t.. acknowledgements.nl.html
f..tp. all.ca.html
f..t.. all.cs.html
f..t.. all.de.html

.L..t.. all.en.html -> all.html

f..t.. all.es.html
f..t.. all.fr.html
f..t.. all.html
f..t.. all.hu.html
f..t.. all.it.html
f..t.. all.ja.html
f..t.. all.nl.html
f..t.. all.zh.html
f..tp. attic.ca.html
f..t.. attic.de.html

.L..t.. attic.en.html -> attic.html

f..t.. attic.es.html
f..t.. attic.fr.html
f..t.. attic.html
f..t.. attic.hu.html
f..t.. attic.it.html
f..t.. attic.ja.html
f..t.. attic.nl.html
f..t.. attic.zh.html
f..tp. authors.ca.html
f..t.. authors.cs.html
f..t.. authors.de.html

.L..t.. authors.en.html -> authors.html

f..t.. authors.es.html
f..t.. authors.fr.html
f..t.. authors.html
f..t.. authors.hu.html
f..t.. authors.it.html
f..t.. authors.ja.html
f..t.. authors.nl.html
f..t.. authors.zh.html
f..tp. 

Re: Fix dashed line errors (issue 320320043 by david.nales...@gmail.com)

[lemzwerg]

LGTM.

https://codereview.appspot.com/320320043/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

PATCHES - Countdown for March 7th.

[James]

Hello,

Here is the current patch countdown list. The next countdown will be on
March 10th.

A quick synopsis of all patches currently in the review process can be
found here:

http://philholmes.net/lilypond/allura/





Push:


5079 Let \afterGrace start a Bottom context - David Kastrup
https://sourceforge.net/p/testlilyissues/issues/5079
http://codereview.appspot.com/314590043


Countdown:


5078 Web: Move older news to the attic page - Paul Morris
https://sourceforge.net/p/testlilyissues/issues/5078
http://codereview.appspot.com/320290043


5033 LyricHyphen whiteout - knupero
https://sourceforge.net/p/testlilyissues/issues/5033
http://codereview.appspot.com/312530043


4966 the font name is Emmentaler, while Feta and Parmesan are two 
subsets of glyphs - James Lowe

https://sourceforge.net/p/testlilyissues/issues/4966
http://codereview.appspot.com/320310043


Review:


5083 Add making web.$(ISOLANG).pdf - Masamichi Hosoda
https://sourceforge.net/p/testlilyissues/issues/5083
http://codereview.appspot.com/319450043


5082 Add capability to build Japanese PDF documents - Masamichi Hosoda
https://sourceforge.net/p/testlilyissues/issues/5082
http://codereview.appspot.com/316340043


5080 Gracenotes at the start of a volta alternative now breaks 
autobeaming in the same way as in multipart music. - David Kastrup

https://sourceforge.net/p/testlilyissues/issues/5080
http://codereview.appspot.com/320270043


New:


5086 Fix dashed line errors - David Nalesnik
https://sourceforge.net/p/testlilyissues/issues/5086
http://codereview.appspot.com/320320043



5085 Web-GSoC: Update MusicXML project description - Urs Liska
https://sourceforge.net/p/testlilyissues/issues/5085
http://codereview.appspot.com/314620043



5084 Create Bracket class - David Nalesnik
https://sourceforge.net/p/testlilyissues/issues/5084
http://codereview.appspot.com/314610043



Regards

James


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Website upload

[David Kastrup]

"Phil Holmes"  writes:

> - Original Message - 
> From: "Phil Holmes" 
> To: "David Kastrup" ; "Urs Liska" 
> Cc: 
> Sent: Tuesday, March 07, 2017 11:31 AM
> Subject: Re: Website upload
>
>
>> - Original Message - 
>> From: "Urs Liska" 
>> To: "David Kastrup" 
>> Cc: "Phil Holmes" ; 
>> Sent: Tuesday, March 07, 2017 11:08 AM
>> Subject: Re: Website upload
>>
>>
>>> Maybe someone with privileges on the server could manually run rsync
>>> with the --delete and the -n (dry run) option and presenting us with the
>>> list of files that would be deleted remotely. Probably this would
>>> quickly tell us if we have legitimate "orphaned" files.
>>>
>>> Urs
>>
>>
>> That sounds like a good plan.  AFAICS I would need to run the line
>> from make-website.sh, but with those added options:
>>
>> rsync -raO -n --delete $BUILD/out-website/website/ $DEST/website/
>>
>> ??
>
>
> Hmm.  Tried that.  No output.

-n, --dry-run
This makes rsync perform a  trial run that doesn’t make
any changes (and  produces mostly the same  output as a
real  run).  It  is most  commonly used  in combination
with  the -v,  --verbose  and/or -i,  --itemize-changes
options to  see what  an rsync command  is going  to do
before one actually runs it.

The  output  of  --itemize-changes is  supposed  to  be
exactly the same on a dry run and a subsequent real run
(barring   intentional   trickery   and   system   call
failures);  if it  isn’t, that’s  a bug.   Other output
should  be mostly  unchanged,  but may  differ in  some
areas.  Notably,  a dry  run does  not send  the actual
data for  file transfers, so --progress  has no effect,
the  bytes  sent,  bytes received,  literal  data,  and
matched data statistics are  too small, and the speedup
value is  equivalent to a  run where no  file transfers
were needed.

Maybe add -i to the options?

How did you catch the output?  On a terminal or via redirection?  Maybe
you need to redirect stderr as well?

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Website upload

[Phil Holmes]

- Original Message - 
From: "Phil Holmes" 

To: "David Kastrup" ; "Urs Liska" 
Cc: 
Sent: Tuesday, March 07, 2017 11:31 AM
Subject: Re: Website upload


- Original Message - 
From: "Urs Liska" 

To: "David Kastrup" 
Cc: "Phil Holmes" ; 
Sent: Tuesday, March 07, 2017 11:08 AM
Subject: Re: Website upload



Maybe someone with privileges on the server could manually run rsync
with the --delete and the -n (dry run) option and presenting us with the
list of files that would be deleted remotely. Probably this would
quickly tell us if we have legitimate "orphaned" files.

Urs



That sounds like a good plan.  AFAICS I would need to run the line from 
make-website.sh, but with those added options:


rsync -raO -n --delete $BUILD/out-website/website/ $DEST/website/

??



Hmm.  Tried that.  No output.

--
Phil Holmes

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Website upload

[Phil Holmes]

- Original Message - 
From: "Urs Liska" 

To: "David Kastrup" 
Cc: "Phil Holmes" ; 
Sent: Tuesday, March 07, 2017 11:08 AM
Subject: Re: Website upload



Maybe someone with privileges on the server could manually run rsync
with the --delete and the -n (dry run) option and presenting us with the
list of files that would be deleted remotely. Probably this would
quickly tell us if we have legitimate "orphaned" files.

Urs



That sounds like a good plan.  AFAICS I would need to run the line from 
make-website.sh, but with those added options:


rsync -raO -n --delete $BUILD/out-website/website/ $DEST/website/

??

--
Phil Holmes 



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Website upload

[David Kastrup]

Urs Liska  writes:

> Am 07.03.2017 um 12:05 schrieb David Kastrup:
>
>> The alternative is someone going through all the files by hand on a
>> backup/image/copy.  I think, however, that reviewing the top-level
>> directories should be enough: server-specific stuff is rarely found in
>> lower parts of the hierarchy only: so if we are missing something, this
>> is likely obvious in higher layers already.
>
> Maybe someone with privileges on the server could manually run rsync
> with the --delete and the -n (dry run) option and presenting us with
> the list of files that would be deleted remotely. Probably this would
> quickly tell us if we have legitimate "orphaned" files.

Good idea.  I expect lots of outdated image files, but then one can
filter such a list.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Website upload

[Urs Liska]

Am 07.03.2017 um 12:05 schrieb David Kastrup:
> Urs Liska  writes:
>
>> Am 07.03.2017 um 11:45 schrieb David Kastrup:
>>> Urs Liska  writes:
>>>
 Am 07.03.2017 um 11:24 schrieb Phil Holmes:

> Again - this needs answering with a bit of care, because the website
> and the docs are closely linked.  It appears to me that putting any of
> the documentation (which includes part of the webite) is doen with
> rsync without the delete option.  See
> https://github.com/gperciva/gub/blob/master/test-lily/upload.py line 175. 
 OK, there's some general discussion in here.

 Basically I think such an upload should definitely include the
 --delete option because we don't want an arbitrary number of orphaned
 files on the server, isn't it?
>>> We don't want orphaned files, no, but one better make a complete backup
>>> first because not all files might be orphaned copies but may have been
>>> added on the server only for some purpose.  Symlinks, referal files,
>>> permission/login files and similar stuff.
>> OK, that makes sense.
>> But how would we find out about such items? I don't think it's a very
>> clean strategy to make a backup, then remove them and deal with any bug
>> report about missing files ...
> The alternative is someone going through all the files by hand on a
> backup/image/copy.  I think, however, that reviewing the top-level
> directories should be enough: server-specific stuff is rarely found in
> lower parts of the hierarchy only: so if we are missing something, this
> is likely obvious in higher layers already.

Maybe someone with privileges on the server could manually run rsync
with the --delete and the -n (dry run) option and presenting us with the
list of files that would be deleted remotely. Probably this would
quickly tell us if we have legitimate "orphaned" files.

Urs


-- 
u...@openlilylib.org
https://openlilylib.org
http://lilypondblog.org


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Website upload

[Urs Liska]

Am 07.03.2017 um 11:58 schrieb Phil Holmes:
> - Original Message - From: "Urs Liska" 
> To: "Phil Holmes" ; 
> Cc: "Graham Percival" 
> Sent: Tuesday, March 07, 2017 10:38 AM
> Subject: Re: Website upload
>
>
>>
>> Could we also see that cron job script please?
>>
>
> It's here:
> http://lilypond.org/doc/v2.19/Documentation/contributor/uploading-and-security
> (after ### make-website.sh).
>

OK, so this doesn't include --delete either.

Urs

> -- 
> Phil Holmes

-- 
u...@openlilylib.org
https://openlilylib.org
http://lilypondblog.org


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Website upload

[David Kastrup]

Urs Liska  writes:

> Am 07.03.2017 um 11:45 schrieb David Kastrup:
>> Urs Liska  writes:
>>
>>> Am 07.03.2017 um 11:24 schrieb Phil Holmes:
>>>
 Again - this needs answering with a bit of care, because the website
 and the docs are closely linked.  It appears to me that putting any of
 the documentation (which includes part of the webite) is doen with
 rsync without the delete option.  See
 https://github.com/gperciva/gub/blob/master/test-lily/upload.py line 175. 
>>> OK, there's some general discussion in here.
>>>
>>> Basically I think such an upload should definitely include the
>>> --delete option because we don't want an arbitrary number of orphaned
>>> files on the server, isn't it?
>> We don't want orphaned files, no, but one better make a complete backup
>> first because not all files might be orphaned copies but may have been
>> added on the server only for some purpose.  Symlinks, referal files,
>> permission/login files and similar stuff.
>
> OK, that makes sense.
> But how would we find out about such items? I don't think it's a very
> clean strategy to make a backup, then remove them and deal with any bug
> report about missing files ...

The alternative is someone going through all the files by hand on a
backup/image/copy.  I think, however, that reviewing the top-level
directories should be enough: server-specific stuff is rarely found in
lower parts of the hierarchy only: so if we are missing something, this
is likely obvious in higher layers already.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Website upload

[Phil Holmes]

- Original Message - 
From: "Urs Liska" 

To: "Phil Holmes" ; 
Cc: "Graham Percival" 
Sent: Tuesday, March 07, 2017 10:38 AM
Subject: Re: Website upload




Could we also see that cron job script please?



It's here: 
http://lilypond.org/doc/v2.19/Documentation/contributor/uploading-and-security 
(after ### make-website.sh).


--
Phil Holmes 



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Website upload

[Urs Liska]

Am 07.03.2017 um 11:45 schrieb David Kastrup:
> Urs Liska  writes:
>
>> Am 07.03.2017 um 11:24 schrieb Phil Holmes:
>>
>>> Again - this needs answering with a bit of care, because the website
>>> and the docs are closely linked.  It appears to me that putting any of
>>> the documentation (which includes part of the webite) is doen with
>>> rsync without the delete option.  See
>>> https://github.com/gperciva/gub/blob/master/test-lily/upload.py line 175. 
>> OK, there's some general discussion in here.
>>
>> Basically I think such an upload should definitely include the
>> --delete option because we don't want an arbitrary number of orphaned
>> files on the server, isn't it?
> We don't want orphaned files, no, but one better make a complete backup
> first because not all files might be orphaned copies but may have been
> added on the server only for some purpose.  Symlinks, referal files,
> permission/login files and similar stuff.

OK, that makes sense.
But how would we find out about such items? I don't think it's a very
clean strategy to make a backup, then remove them and deal with any bug
report about missing files ...

Urs

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Website upload

[Davide Liessi]

2017-03-07 11:38 GMT+01:00 Urs Liska :
> However, in the current specific case I would vote for having a symlink
> or redirect for http://lilypond.org/gsoc.html pointing to
> http://lilypond.org/google-summer-of-code.html, at least unitl the
> application stage is over.

Maybe an HTTP permanent redirect (308) should be added instead of a symlink, see
https://en.wikipedia.org/wiki/List_of_HTTP_status_codes#3xx_Redirection

Best wishes.
Davide

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Website upload

[David Kastrup]

Urs Liska  writes:

> Am 07.03.2017 um 11:24 schrieb Phil Holmes:
>
>> Again - this needs answering with a bit of care, because the website
>> and the docs are closely linked.  It appears to me that putting any of
>> the documentation (which includes part of the webite) is doen with
>> rsync without the delete option.  See
>> https://github.com/gperciva/gub/blob/master/test-lily/upload.py line 175. 
>
> OK, there's some general discussion in here.
>
> Basically I think such an upload should definitely include the
> --delete option because we don't want an arbitrary number of orphaned
> files on the server, isn't it?

We don't want orphaned files, no, but one better make a complete backup
first because not all files might be orphaned copies but may have been
added on the server only for some purpose.  Symlinks, referal files,
permission/login files and similar stuff.

> But OTOH, as the current issue demonstrates, Google may point to these
> files, and I'm not fully sure about the implications of these files
> being removed.

They'll eventually get to removing their pointers.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Website upload

[Urs Liska]

Am 07.03.2017 um 11:24 schrieb Phil Holmes:
> Am 06.03.2017 um 23:43 schrieb Phil Holmes:
>> > Simple answer - I run the GUB uploader.
>> >
>> > Slightly more useful one: there are two aspects to the "website": the
>> > one that is created with "make website". This is a fairly simple
>> > step, and any change to any file that is part of "website" is
>> > automatically picked up by the website - it has a pair of cron jobs
>> > that pull git and run "make website" every hour. The more complex
>> > parts of the site (e.g. the docs) are created by GUB with a "make
>> > lilypond" and then uploaded with a GUB command that rsynch's my disk
>> > with lilypond.org.
>> >
>> > I suspect this won't answer your question, but does move the issue
>> > forward. Please ask more - if I can answer, I will.
>>
>> OK. The concrete question (already raised by Federico) is:
>> Whenever the *website* is uploaded (I don't talk about the manuals) does
>> this involve rsync (seems so)? And if it does is the --delete option
>> used? Because otherwise remainders of renamed nodes will be kept on the
>> website (without being properly linked).
>
> Again - this needs answering with a bit of care, because the website
> and the docs are closely linked.  It appears to me that putting any of
> the documentation (which includes part of the webite) is doen with
> rsync without the delete option.  See
> https://github.com/gperciva/gub/blob/master/test-lily/upload.py line 175. 

OK, there's some general discussion in here.

Basically I think such an upload should definitely include the --delete
option because we don't want an arbitrary number of orphaned files on
the server, isn't it?
But OTOH, as the current issue demonstrates, Google may point to these
files, and I'm not fully sure about the implications of these files
being removed. OTOH (again) there's no use in having unmaintained plain
HTML files lying around, and therefore the search engines should
presumably "forget" about these files, isn't it?

So my suggestion would be to add the --delete option to this rsync command.
In order to have a better place for discussing this specifically I've
created a pull request at
https://github.com/gperciva/gub/compare/master...uliska:patch-1

> However, as I touched on earler, the website itself is created by a
> pull from git and then "make website".  The website itself is built
> into an offline directory and most of the files are then automatically
> rsynced to the live website - the cron job does this after make
> website has completed. 

Could we also see that cron job script please?

> Looking at the live website directory, it's apparent that there are a
> number of old files that haven't been built recently - including
> gsoc.html, which hasn't been touched since August 2012.
>
> I've added Graham to the cc list to see if he thinks the best bet is
> simply to manually delete the old files, or create symlinks or
> something else.

As said, my suggestion is to add the --delete option to both upload.py
and the website cron job.
However, in the current specific case I would vote for having a symlink
or redirect for http://lilypond.org/gsoc.html pointing to
http://lilypond.org/google-summer-of-code.html, at least unitl the
application stage is over.

Urs

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Website upload

[Phil Holmes]

Am 06.03.2017 um 23:43 schrieb Phil Holmes:

> Simple answer - I run the GUB uploader.
>
> Slightly more useful one: there are two aspects to the "website": the
> one that is created with "make website". This is a fairly simple
> step, and any change to any file that is part of "website" is
> automatically picked up by the website - it has a pair of cron jobs
> that pull git and run "make website" every hour. The more complex
> parts of the site (e.g. the docs) are created by GUB with a "make
> lilypond" and then uploaded with a GUB command that rsynch's my disk
> with lilypond.org.
>
> I suspect this won't answer your question, but does move the issue
> forward. Please ask more - if I can answer, I will.

OK. The concrete question (already raised by Federico) is:
Whenever the *website* is uploaded (I don't talk about the manuals) does
this involve rsync (seems so)? And if it does is the --delete option
used? Because otherwise remainders of renamed nodes will be kept on the
website (without being properly linked).


Again - this needs answering with a bit of care, because the website and the 
docs are closely linked.  It appears to me that putting any of the 
documentation (which includes part of the webite) is doen with rsync without 
the delete option.  See 
https://github.com/gperciva/gub/blob/master/test-lily/upload.py line 175. 
However, as I touched on earler, the website itself is created by a pull 
from git and then "make website".  The website itself is built into an 
offline directory and most of the files are then automatically rsynced to 
the live website - the cron job does this after make website has completed. 
Looking at the live website directory, it's apparent that there are a number 
of old files that haven't been built recently - including gsoc.html, which 
hasn't been touched since August 2012.


I've added Graham to the cc list to see if he thinks the best bet is simply 
to manually delete the old files, or create symlinks or something else.



@node GSoC 2012
will result in gsoc-2012.html, gsoc-2012.de.html etc.

When that is renamed to
@node Google Summer of Code
the generated files are google-summer-of-code.html,
google-summer-of-code.de.html etc.

In that case the gsoc-2012... files have to be purged from the website.
and somehow it looks this isn't the case, presumably leading to a huge
amount of such orphaned files on the server.

A special case (as brought up by Werner) is the fact that
http://lilypond.org/gsoc.html is completely outdated but at the same
time a prominent search result at Google. So if our assumption is
correct and there are numeorus obsolete files on the server *this* one
should note simply be deleted but redirected to
http://lilypond.org/google-summer-of-code.html.

Urs




--
Phil Holmes


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Fix dashed line errors (issue 320320043 by david.nales...@gmail.com)

[Urs Liska]

I currently can't compile so I can't test the patch, and I can only
assess (1) from reading the code.

But it's good to fix this. It's a glitch but nevertheless "feels"
awkward when tweaking a score.
Urs


Am 07.03.2017 um 05:46 schrieb david.nales...@gmail.com:
> Reviewers: ,
>
> Message:
> Please review.  Thanks!
>
> Description:
> Fix dashed line errors
>
> There are two errors in lily/line-interface.cc which cause
> dashed lines to be drawn inaccurately.
>
> (1) Line-thickness is improperly subtracted from the "off"
> value in Line_interface::make_dashed_line.  This was done,
> presumably, to account for the line cap of each dash.  In fact,
> PostScript discounts the line cap when constructing the pattern.
>
> (2) Dashed lines are constructed so that they begin and end
> with a dash.  Thus, a dashed line is built of dash + whitespace
> units and a last lone dash.  Period is not adjusted in
> Line_interface::line for this last dash, which can lead to a
> noticeable difference in its length compared to other dashes.
>
> Correcting these flaws ensures that dashed lines end with a
> dash rather than whitespace, and that terminating dashes are
> not clipped.  Also, the number of dashes drawn reflects the
> number calculated.
>
> Please review this at https://codereview.appspot.com/320320043/
>
> Affected files (+13, -8 lines):
>   M lily/line-interface.cc
>
>
> Index: lily/line-interface.cc
> diff --git a/lily/line-interface.cc b/lily/line-interface.cc
> index
> bc0895339fea3c996e08a71891c0090cbea2e96c..9c16ece4106f956af5cb3a30cb4fc667065abab8
> 100644
> --- a/lily/line-interface.cc
> +++ b/lily/line-interface.cc
> @@ -123,8 +123,8 @@ Line_interface::make_dashed_line (Real thick,
> Offset from, Offset to,
>Real dash_period, Real dash_fraction)
>  {
>dash_fraction = min (max (dash_fraction, 0.0), 1.0);
> -  Real on = dash_fraction * dash_period;
> -  Real off = max (0.0, dash_period - on - thick);
> +  Real on = dash_fraction * dash_period;
> +  Real off = max (0.0, dash_period - on);
>
>SCM at = scm_list_n (ly_symbol2scm ("dashed-line"),
> scm_from_double (thick),
> @@ -226,16 +226,21 @@ Line_interface::line (Grob *me, Offset from,
> Offset to)
>  return Stencil ();
>
>Real len = (to - from).length ();
> -
> -  int n = (int) rint ((len - period * fraction) / period);
> -  n = max (0, n);
> -  if (n > 0)
> +  /*
> +Dashed lines should begin and end with a dash.  Therefore,
> +there will be one more dash than complete dash + whitespace
> +units (full periods).
> +  */
> +  int full_period_count =
> +(int) rint ((len - period * fraction) / period);
> +  full_period_count = max (0, full_period_count);
> +  if (full_period_count > 0)
>  {
>/*
>  TODO: figure out something intelligent for really short
>  sections.
> -   */
> -  period = ((to - from).length () - period * fraction) / n;
> +  */
> +  period = len / (fraction + full_period_count);
>  }
>stencil = make_dashed_line (thick, from, to, period, fraction);
>  }
>
>
>
> ___
> lilypond-devel mailing list
> lilypond-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-devel

-- 
u...@openlilylib.org
https://openlilylib.org
http://lilypondblog.org


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel