Re: Run regression tests for lilypond-book (issue 2223). (issue 5569045)

[julien . rioux]

https://codereview.appspot.com/5569045/diff/3001/input/regression/lilypond-book/GNUmakefile
File input/regression/lilypond-book/GNUmakefile (right):

https://codereview.appspot.com/5569045/diff/3001/input/regression/lilypond-book/GNUmakefile#newcode36
input/regression/lilypond-book/GNUmakefile:36: # Prevent parallel
lilypond-book instances for this subdir
On 2020/02/22 22:54:40, hanwenn wrote:
> I know this is a long time ago, but can you remember why this was
added?

As far as I can remember, lilypond-book was not free of concurrency
issues with its use of a cache for snippets. Therefore the simplest to
avoid any issue with make -j was to disable concurrent calls to
lilypond-book.

https://codereview.appspot.com/5569045/

Re: CG: Update of Patchy instructions (issue 112280043 by pkx1...@gmail.com)

[julien . rioux]

Don't think it needs another countdown cycle, so the changes below could
be made before pushing.
Cheers,
Julien


https://codereview.appspot.com/112280043/diff/40001/Documentation/contributor/administration.itexi
File Documentation/contributor/administration.itexi (right):

https://codereview.appspot.com/112280043/diff/40001/Documentation/contributor/administration.itexi#newcode591
Documentation/contributor/administration.itexi:591: The tracker issue's
lable is then changed automatically to
label

https://codereview.appspot.com/112280043/diff/40001/Documentation/contributor/administration.itexi#newcode606
Documentation/contributor/administration.itexi:606: lable is changed
automatically to @qq{Patch-Needs_work}.
label

https://codereview.appspot.com/112280043/diff/40001/Documentation/contributor/administration.itexi#newcode627
Documentation/contributor/administration.itexi:627: 02 0-23/2 * * *
/home/joe/lilypond-extra/patches/lilypond-patchy-staging.py
joe -> patchy

https://codereview.appspot.com/112280043/diff/40001/Documentation/contributor/administration.itexi#newcode694
Documentation/contributor/administration.itexi:694: This occurs when
Patchy detects that the commit ID is has not changed
"is has" -> "has"

https://codereview.appspot.com/112280043/

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

Re: CG: Update of Patchy instructions (issue 112280043 by pkx1...@gmail.com)

[julien . rioux]

Thanks for this! Some comments.
Cheers,
Julien


https://codereview.appspot.com/112280043/diff/20001/Documentation/contributor/administration.itexi
File Documentation/contributor/administration.itexi (right):

https://codereview.appspot.com/112280043/diff/20001/Documentation/contributor/administration.itexi#newcode161
Documentation/contributor/administration.itexi:161: knowledge of of
compiling LilyPond and its documentation along with
"of of"

https://codereview.appspot.com/112280043/diff/20001/Documentation/contributor/administration.itexi#newcode172
Documentation/contributor/administration.itexi:172: requires some human
intervention in order to to visually check for any
"to to"

https://codereview.appspot.com/112280043/diff/20001/Documentation/contributor/administration.itexi#newcode178
Documentation/contributor/administration.itexi:178: compile, including
building all the LilyPond documentation, finally
The script makes sure that the new HEAD compiles, it does not attempt to
compile every individual commit.

https://codereview.appspot.com/112280043/diff/20001/Documentation/contributor/administration.itexi#newcode238
Documentation/contributor/administration.itexi:238: Commit access
@emph{is} required to test patches, but a valid login
"to test patches" -> "to test and push new commits"

https://codereview.appspot.com/112280043/diff/20001/Documentation/contributor/administration.itexi#newcode256
Documentation/contributor/administration.itexi:256: of the
@file{patches/} directory to your @var{PATH}.
Would be useful to give the exact command line to clone the repo.

https://codereview.appspot.com/112280043/diff/20001/Documentation/contributor/administration.itexi#newcode430
Documentation/contributor/administration.itexi:430: The script can also
be run using a @emph{single} tracker issue number as
You can have multiple arguments, each an issue number.

https://codereview.appspot.com/112280043/diff/20001/Documentation/contributor/administration.itexi#newcode525
Documentation/contributor/administration.itexi:525: @unnumberedsubsubsec
Checking the regression test results
OK, I made it this far.

https://codereview.appspot.com/112280043/

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

Re: Leave extension in .dep under mf/ , as we have multiple rules generating .dep files. (issue 99300043)

[julien . rioux]

On 2014/05/18 12:12:27, hanwenn wrote:

according to git it was Julien.


lgtm

https://codereview.appspot.com/99300043/

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

Re: Python 3 support

[Julien Rioux]

On Tue, Mar 18, 2014 at 4:43 PM, Jeremiah Benham  wrote:

> I have forked gub and have been working on it for a while now.
>
> https://github.com/jjbenham/gub
>
> It is very different now from https://github.com/gperciva/gub and the
> main master. I don't know how to contribute changes unless via per file
> basis. Then each patch would need to be tested. I have added support for
> gtk3 on mingw, darwin-x86 and linux-x86. I also upgraded many things like
> tar (this adds .xz support). This was all to support the denemo project. It
> would be nice to work with others on it.
>
> Jeremiah
>

Hi Jeremiah,

Thanks for reaching out. A while ago I noticed your fork and though that at
some point it would be good to investigate what should be contributed back.
Unfortunately it takes a lot of time to test changes in GUB, and I was
already puzzled enough by the various different branches between Jan's and
Graham's repos. I'm glad to hear that you would like to contribute your
changes back, that will be a welcome collaboration.

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

Re: Python 3 support

[Julien Rioux]

On Tue, Mar 18, 2014 at 12:44 PM, David Kastrup  wrote:

>
> That's not quite the same as "we already have hosting, a platform for
> contribution and review comments".  Everything beyond the content in
> private repositories is gone if a project is removed.  And "we have" is
> a bit of a euphemism for proprietary software run on a proprietary
> service with a proprietary data store for everything but the central
> repository itself.  It's more like "we are permitted to use".
>
> Of course, with Savannah we have the same situation regarding the "we
> are permitted to use" angle, but the motivations for the permission are
> different.  That makes me feel more at home.
>
>
Again, if you're keen on providing hosting elsewhere, why not go for it. My
point of view says it is not worth it, yours differ. I'll be glad if we get
back on thread.

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

Re: Python 3 support

[Julien Rioux]

On Tue, Mar 18, 2014 at 10:39 AM, David Kastrup  wrote:

> Julien Rioux  writes:
>
> > The current hosting situation isn't bad that we need to take such
> > important actions with savannah. With github, we already have hosting,
> > a platform for contribution and review comments, and relatively strong
> > visibility, at no effort from us.
>
> Who is "we"?  I for one am not going to agree to GitHub's quite invasive
> usage conditions for their "free" offerings which include killing a
> project for any reason they want to at any point of time, explicitly
> citing bandwidth usage as one such reason.
>
>
You're right, for contributing a patch and/or commenting through github,
it's "we" as in "those that are bold enough to sign up on github". "We"
also happily send patches or comments on the mailing list as usual; "we" as
in "those that are bold enough to post on public mailing lists". It's still
an added value that a non-empty set of people are happy with.


> Now the situation is in theory not all that different with Savannah.
> Except that Savannah does not serve stockholders but its users and Free
> Software.  When they find that there is a technical problem in
> connection with serving a project, "pull the plug" will be way lower in
> the list of remedies than with GitHub.
>
>
Fortunately with git repos even if the hosting goes, the project's source
code is still in hand,

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

Re: Python 3 support

[Julien Rioux]

On Mon, Mar 17, 2014 at 9:38 PM, Graham Percival
wrote:

> On Sun, Mar 16, 2014 at 04:41:46PM -0400, Julien Rioux wrote:
> > I think the following would be a good 1-2 punch approach for the
> > current development cycle: First, upgrade python in GUB and make
> > sure we can build current dev and stable branches of lilypond from
> > it. Then bump the python requirement in the dev branch and start
> > migrating to a codebase that supports python 2.6+ and python 3+
>
> Sounds great!  Thanks for working on this.
>
>
When would be a good timing to do the switch in GUB? Probably don't want to
mess with releases from the current stable (2.18.x) branch at this point,
so maybe wait until after the last 2.18.x is released, whenever that might
be?

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

Re: Python 3 support

[Julien Rioux]

On Tue, Mar 18, 2014 at 6:24 AM, David Kastrup  wrote:

> Julien Rioux  writes:
>
> > (BTW moving GUB to a user-agnostic home such as
> > https://github.com/lilypond
>
> > would make sense to avoid such confusion.  After Jan went mostly
> > inactive, Graham took over as the "official" home, but he is now
> > himself going into inactivity)
>
> Should we try asking Savannah, either non-GNU or GNU?  How much work
> would it be to meet Savannah's licensing/guideline restrictions
> regarding binary blobs and stuff?  How many of those are
> LilyPond-specific?
>
> If there are technically unavoidable obstacles, the special strategical
> significance of GUB might still make it possible to negotiate about the
> hosting with Richard Stallman, currently the ultimate decision maker.
>
> I think that cross-platform support is currently troublesome for enough
> projects that the "compile under GNU/Linux, provide everywhere" approach
> of GUB would mean a significant concentration of efforts for other GNU
> projects as well.
>
>
If you are keen on it, why not? Not sure if it's worth the trouble, though:
Maybe more visibility would bring GUB more workers, and in that vein
endorsement by a big player would be a boost. Unfortunately, I'm not sure
GUB has a strong significance anymore. With no maintainer, no support team,
virtually no devs, it's not attractive for new projects, which then opt for
other cross-build solutions instead.

The current hosting situation isn't bad that we need to take such important
actions with savannah. With github, we already have hosting, a platform for
contribution and review comments, and relatively strong visibility, at no
effort from us. It seems there is confusion about who owns the "official"
repo, which is easily solved if we move the repo from an individual to an
organization. And since it's literally a click or two to do that, I though
I would suggest it in passing. Anyway, we're sidestepping.

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

Re: Python 3 support

[Julien Rioux]

On Tue, Mar 18, 2014 at 3:33 AM, David Kastrup  wrote:

> I was of the opinion that GUB already uses Python 2.6?
>
>
GUB master at https://github.com/gperciva/gub (the current "official" home)
definitely does not use python 2.6. It ships python 2.4.5

If you are using GUB master at https://github.com/janneke/gub then it does
use python 2.6, but it lacks the fix for python's hashlib module, which
then fails to import at run time. I added that fix and a couple others in
the previously mentioned pull request.

(BTW moving GUB to a user-agnostic home such as
https://github.com/lilypondwould make sense to avoid such confusion.
After Jan went mostly inactive,
Graham took over as the "official" home, but he is now himself going into
inactivity)

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

Python 3 support

[Julien Rioux]

Hi,

Our python scripts currently require a python2 interpreter with version 
at least 2.4, but by bumping the requirement to 2.6 we could start 
introducing

from __future__ import print_function
which will be one of the major step towards supporting both python2 and 
python3 interpreters with a single codebase.


One of the big hurdle to bumping the python version requirement is our 
own cross-platform build system GUB which provides 2.4, but last summer 
I was able to build lilypond with an updated GUB, based on some 
experimental branch by Jan where I added a few commits. You can find the 
patchset here: https://github.com/gperciva/gub/pull/6


I think the following would be a good 1-2 punch approach for the current 
development cycle: First, upgrade python in GUB and make sure we can 
build current dev and stable branches of lilypond from it. Then bump the 
python requirement in the dev branch and start migrating to a codebase 
that supports python 2.6+ and python 3+


Thoughts? Objections?

Regards,
Julien


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

Re: [translations] Re: 2.18 release plans (again).

[Julien Rioux]

On 29/10/2013 4:43 AM, David Kastrup wrote:

Julien Rioux  writes:


On 27/10/2013 2:09 PM, Janek Warchoł wrote:

That's good, but the most irritating thing about this patch is not
that i have to solve merge conflicts.  I'm mainly irritated because a
piece of solid code (maybe it's not as solid as i think, but to know
that i need _reviews_) is laying dormant for *half a year*, which
prohibits me from working on some other stuff.  I would really like to
get some of my GSoC work finished and merged into master, and this
patch is a first step for that.



I'm curious, why is this issue set to Patch-waiting?


I had to go answer my own question: The patch contains code changes 
without the necessary doc changes, so it is not suitable for 
Patch-review state, but Janek would appreciate reviewer comments so that 
the code can reach a final form before doing the doc changes.



I think generally
people hardly ever have enough time to look at Patch-countdown issues,
so a Patch-waiting issue would definitely not get much attention.


Well, that's what Janek complained about.  It's more or less a
consequence of our grading system: "Patch-review" means "slated to move
to countdown" and "Patch-Countdown" means "slated to move to
Patch-push".


Patch-waiting seems like the correct qualifier. How about advertising 
those Patch-waiting issues as part of the Countdown email that is sent 
regularly? We currently have 7 of those, and could probably pretty 
quickly identify which one are truly waiting and which one are now 
abandoned.


Cheers,
Julien


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

Re: [translations] Re: 2.18 release plans (again).

[Julien Rioux]

On 27/10/2013 2:09 PM, Janek Warchoł wrote:

That's good, but the most irritating thing about this patch is not
that i have to solve merge conflicts.  I'm mainly irritated because a
piece of solid code (maybe it's not as solid as i think, but to know
that i need _reviews_) is laying dormant for *half a year*, which
prohibits me from working on some other stuff.  I would really like to
get some of my GSoC work finished and merged into master, and this
patch is a first step for that.



I'm curious, why is this issue set to Patch-waiting? I think generally 
people hardly ever have enough time to look at Patch-countdown issues, 
so a Patch-waiting issue would definitely not get much attention.


Cheers,
Julien


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

Build: Fix compilation with GNU make 4.0 (issue 18700043)

[julien . rioux]

Reviewers: John Mandereau,

Message:
Thanks to Thomas Klausner. This seems like the correct fix.

Cheers,
Julien

Description:
Build: Fix compilation with GNU make 4.0

Fix "recipes commence before first target" error.

Patch from Thomas Klausner.

Please review this at https://codereview.appspot.com/18700043/

Affected files (+1, -1 lines):
  M stepmake/stepmake/po-targets.make


Index: stepmake/stepmake/po-targets.make
diff --git a/stepmake/stepmake/po-targets.make  
b/stepmake/stepmake/po-targets.make
index  
8919dab8239e69f0378a0d6071fc1d249f8bbff0..8a0dd76053f51e8a7ef98f4e9b289a7e24c45218  
100644

--- a/stepmake/stepmake/po-targets.make
+++ b/stepmake/stepmake/po-targets.make
@@ -37,10 +37,10 @@ ifneq ($(strip $(ALL_PO_SOURCES)),)
 --keyword=_ --keyword=_f --keyword=_i \
 $(XGETTEXT_FLAGS) $(ALL_PO_SOURCES)
 endif
-endif
sed -i '1,2d' $(po-outdir)/$(package).po
 	sed -i -e 's/^\# This file is distributed.*/$(sed-header)/'  
$(po-outdir)/$(package).po
 	sed -i -e 's/^\"Content-Type: text\/plain.*/$(sed-content)/'  
$(po-outdir)/$(package).po

+endif


 po-update: po



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

Re: Build: Fix out-of-tree build from tarball. (issue 13854043)

[julien . rioux]

https://codereview.appspot.com/13854043/diff/16001/Documentation/GNUmakefile
File Documentation/GNUmakefile (right):

https://codereview.appspot.com/13854043/diff/16001/Documentation/GNUmakefile#newcode283
Documentation/GNUmakefile:283: $(outdir)/contributor.texi:
$(outdir)/ly-grammar.txt
On 2013/10/02 09:34:19, dak wrote:

The problem why this is creepier than the original rule is that

notation.texi is

a generated file (from notation.tely) while contributor.texi is an

original file

in our repository.



$(outdir)/contributor.texi is a generated file (from contributor.texi;
the rule is a simple copy).

https://codereview.appspot.com/13854043/

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

Re: Build: Fix out-of-tree build from tarball. (issue 13854043)

[julien . rioux]

https://codereview.appspot.com/13854043/diff/7001/Documentation/GNUmakefile
File Documentation/GNUmakefile (right):

https://codereview.appspot.com/13854043/diff/7001/Documentation/GNUmakefile#newcode283
Documentation/GNUmakefile:283: $(outdir)/contributor.texi:
$(outdir)/ly-grammar.txt
On 2013/10/01 10:27:08, dak wrote:

As mentioned in the comments: I don't think that contributor.texi

depends on

ly-grammar.txt: it just has a @verbatiminclude of it inside.  So it

should be

that whatever depends on contributor.texi would also depend on

ly-grammar.txt.


Concretely: contributor.texi does not need to get rebuilt when

touching

ly-grammar.txt.  I don't see a worse problem, though.


While that's technically true, my feeling is to go with the minimal
change to get the least surprises. Since this used to refer to
notation.texi, I simply changed it to notation.texi; this is easier to
do than typing multiple dependency rules for each output format, and
avoids the risk of missing one.

https://codereview.appspot.com/13854043/diff/7001/Documentation/de/GNUmakefile
File Documentation/de/GNUmakefile (right):

https://codereview.appspot.com/13854043/diff/7001/Documentation/de/GNUmakefile#newcode11
Documentation/de/GNUmakefile:11: $(outdir)/notation.texi:
$(outdir)/ly-grammar.txt
On 2013/10/01 10:27:08, dak wrote:

That gives us our own copy of ly-grammar.txt in the German

documentation, right?

right.

https://codereview.appspot.com/13854043/

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

Re: Add backup option to convert-ly (Issue 3572) (issue 14040043)

[julien . rioux]

Again, can we add a check if there is already a numbered backup around?

Make numbered backups for files that have numbered backups already.
 Otherwise, make single backups.  This is the default.

That would mean:



https://codereview.appspot.com/14040043/diff/6001/scripts/convert-ly.py
File scripts/convert-ly.py (right):

https://codereview.appspot.com/14040043/diff/6001/scripts/convert-ly.py#newcode239
scripts/convert-ly.py:239: if numbered:
if numbered or (os.path.exists(file + '.~1~') and os.path.isfile(file +
'.~1~')):

https://codereview.appspot.com/14040043/

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

Let convert-ly -d reflect last effective rather than last applied rule (issue 14077043)

[julien . rioux]

lgtm
Cheers,
Julien

https://codereview.appspot.com/14077043/

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

Re: Add backup option to convert-ly (Issue 3572) (issue 14040043)

[julien . rioux]

This suggestion from David sounded like a good default:
 Make numbered backups for files that have numbered backups already.


https://codereview.appspot.com/14040043/diff/1/scripts/convert-ly.py
File scripts/convert-ly.py (right):

https://codereview.appspot.com/14040043/diff/1/scripts/convert-ly.py#newcode243
scripts/convert-ly.py:243: back_up = file + '.' + str(n) + '~'
Should we go with what David suggested: file.ly.~1~ etc.

https://codereview.appspot.com/14040043/

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

scripts: improve strip-whitespace.py (issue 13720049)

[julien . rioux]

LGTM. You might want to add to your comment at the top: "Also convert
the file to Unix line endings."

https://codereview.appspot.com/13720049/

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

Re: ERROR: Please install required programs: International New Century Schoolbook fonts

[Julien Rioux]

On 12/09/2013 6:09 PM, Federico Bruni wrote:

2013/8/3 Federico Bruni mailto:fedel...@gmail.com>>

I'm getting this error if I run ./autogen.sh in git master:

ERROR: Please install required programs:  International New Century
Schoolbook fonts International New Century Schoolbook fonts

I can't find the missing package,  I have all the ones listes in the CG.
What I'm missing?


In the same directory, now it works if I checkout master branch and I
still get this error if I checkout translation branch.
Probably issue 3526 fixed by Julien?



Yes. Given multiple sets of installed Century fonts, ./configure now 
tries to find one that does have the Cyrillic characters. Previously, it 
would just take the first font location it could find, check that it had 
Cyrillic characters, and bomb out when it didn't, without checking the 
alternative locations for the font. I presume this fix hasn't made it 
into the translation branch yet.


Cheers,
Julien


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

Build dependencies for metafont files (issue 779). (issue 13681043)

[julien . rioux]

Reviewers: John Mandereau,

Message:
Please review.

Description:
Build dependencies for metafont files (issue 779).

Write .dep files containing make dependency rules for .mf files,
allowing to simply type `make' to process the fonts after changing
an input'ed file and have the fonts updated with the minimum amount
of processing.

These .dep files are generated by recursively scanning for lines
of the form "input X;" in the .mf files, and looking up these
input'ed files within the mf source directory. The .dep files are
included into the build by stepmake/generic-targets.make.

http://code.google.com/p/lilypond/issues/detail?id=779

Please review this at https://codereview.appspot.com/13681043/

Affected files (+24, -3 lines):
  M stepmake/stepmake/metafont-rules.make
  M stepmake/stepmake/metafont-vars.make


Index: stepmake/stepmake/metafont-rules.make
diff --git a/stepmake/stepmake/metafont-rules.make  
b/stepmake/stepmake/metafont-rules.make
index  
5b6ad17d91a0a204a1470509e61ea3cdac5e19e7..5be005a1985dc7e998a0d85df79b40c48f4784fe  
100644

--- a/stepmake/stepmake/metafont-rules.make
+++ b/stepmake/stepmake/metafont-rules.make
@@ -2,13 +2,13 @@

 # we want to see botched results as well.
 $(outdir)/%.dvi: %.mf
-   -MFINPUTS=$(src-dir) $(METAFONT) "\scrollmode; input $<;"
+   -$(DO_MF_DEP) MFINPUTS=$(src-dir) $(METAFONT) "\scrollmode; input $<;"
gftodvi $(basename $<)
mv $(basename $<).dvi $(outdir)
rm $(basename $<).*gf

 $(outdir)/%.tfm $(outdir)/%.log: %.mf
-	MFINPUTS=$(src-dir) $(METAFONT) "\mode:=$(MFMODE); nonstopmode; input  
$<;" $(METAFONT_QUIET)
+	$(DO_MF_DEP) MFINPUTS=$(src-dir) $(METAFONT) "\mode:=$(MFMODE);  
nonstopmode; input $<;" $(METAFONT_QUIET)

 # Let's keep this log output, it saves another mf run.
mv $(basename $(@F)).log $(basename $(@F)).tfm $(outdir)
rm -f $(basename $(@F)).*gf  $(basename $(@F)).*pk
@@ -19,7 +19,7 @@ $(outdir)/%.tfm $(outdir)/%.log: %.mf
 # the soft link for mf2pt1.mp is for recent mpost versions
 # which no longer dump a .mem file
 $(outdir)/%.pfb: %.mf $(outdir)/mf2pt1.mem $(outdir)/%.log
-   TMP=`mktemp -d $(outdir)/pfbtemp.$*.X` \
+   $(DO_MF_DEP) TMP=`mktemp -d $(outdir)/pfbtemp.$*.X` \
&& ( cd $$TMP \
&& ln -s ../mf2pt1.mem . \
&& ln -s ../../mf2pt1.mp . \
Index: stepmake/stepmake/metafont-vars.make
diff --git a/stepmake/stepmake/metafont-vars.make  
b/stepmake/stepmake/metafont-vars.make
index  
aeb75c5f004cf1ab1da0e78b985dfdd93dab11be..73f35a53ed68cd0490ccaa367b5f58fe83739492  
100644

--- a/stepmake/stepmake/metafont-vars.make
+++ b/stepmake/stepmake/metafont-vars.make
@@ -15,3 +15,24 @@ METAFONT_QUIET = >/dev/null
 else
 METAFONT_QUIET =
 endif
+
+# Find the metafont file $(1) within the source dirs and return its path.
+# If not found, return $(outdir)/$(1) assuming that it is a generated file.
+find-mf = \
+$(firstword \
+   $(wildcard $(src-dir)/$(1)) \
+   $(wildcard $(top-src-dir)/mf/$(1)) \
+   $(outdir)/$(1) \
+)
+
+# Recursively scan the metafont .mf file $(1) for "input X;"
+# and return all dependencies.
+scan-mf = \
+$(foreach f, $(shell test -f $(1) && sed  
-ne "/^[[:space:]]*input[[:space:]]/s/^[[:space:]]*input\([^.;]*\)\(.mf;\|;\)/\1.mf/p"  
$(1)), \

+   $(call find-mf,$(f)) \
+   $(call scan-mf,$(call find-mf,$(f))) \
+)
+
+# Find dependencies for the target $@, based on the metafont source file  
$<,

+# and write the dependencies to a .dep file.
+DO_MF_DEP = ( echo ./$@: $(call scan-mf,$<) > $(basename $@).dep ) &&



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

Re: Build everything on the first pass of make. (issue 13333048)

[Julien Rioux]

On Thu, Sep 12, 2013 at 5:47 AM, Phil Holmes  wrote:

> I don't understand what you're fixing here, Julien.  On my machine,
> deleting the build directory completely, then recreating it and running
> make (-j9 of course) completely rebuilds the binaries in a single pass.
>  Further immediate calls to make do nothing.
>
>
Good to know, but here it doesn't work out quite like this. For me the
emmentaler font files are being rebuilt on the second call to make. Somehow
it thinks that the fontforge script files are newer than the font files, so
it rebuilds the font files. I'll attach the log below. The patch fixes this.

For make doc, a bunch of stuff is rebuilt on second pass, but fixing all
this is hard to track.


> The only significant bug in this area that I'm aware of is that modifying
> metafont files does not cause the font files to be rebuilt - we have to do
> some deleting in build/mf/out to force a rebuild.
>

Yep, that's bug 779: http://code.google.com/p/lilypond/issues/detail?id=779
John was working on it, it seems, but probably got sidetracked.

Cheers,
Julien
jrioux@camel ~/git/lilypond (master)$ git checkout master
Already on 'master'
jrioux@camel ~/git/lilypond (master)$ git pull
Already up-to-date.
jrioux@camel ~/git/lilypond (master)$ rm -rf build
jrioux@camel ~/git/lilypond (master)$ mkdir build
jrioux@camel ~/git/lilypond (master)$ ./autogen.sh --noconf &> /dev/null
jrioux@camel ~/git/lilypond (master)$ cd build
jrioux@camel ~/git/lilypond/build (master)$ ../configure --disable-optimising 
&> /dev/null
jrioux@camel ~/git/lilypond/build (master)$ make &> /dev/null
jrioux@camel ~/git/lilypond/build (master)$ make -n
make --no-builtin-rules -C scripts/build
make[1]: Entering directory `/home/jrioux/git/lilypond/build/scripts/build'
true
make[1]: Leaving directory `/home/jrioux/git/lilypond/build/scripts/build'
make --no-builtin-rules PACKAGE=LILYPOND package=lilypond -C python all &&  
make --no-builtin-rules PACKAGE=LILYPOND package=lilypond -C scripts all &&  
make --no-builtin-rules PACKAGE=LILYPOND package=lilypond -C flower all &&  
make --no-builtin-rules PACKAGE=LILYPOND package=lilypond -C lily all &&  make 
--no-builtin-rules PACKAGE=LILYPOND package=lilypond -C mf all &&  make 
--no-builtin-rules PACKAGE=LILYPOND package=lilypond -C ly all &&  make 
--no-builtin-rules PACKAGE=LILYPOND package=lilypond -C tex all &&  make 
--no-builtin-rules PACKAGE=LILYPOND package=lilypond -C ps all &&  make 
--no-builtin-rules PACKAGE=LILYPOND package=lilypond -C scm all &&  make 
--no-builtin-rules PACKAGE=LILYPOND package=lilypond -C po all &&  make 
--no-builtin-rules PACKAGE=LILYPOND package=lilypond -C elisp all &&  make 
--no-builtin-rules PACKAGE=LILYPOND package=lilypond -C vim all &&  make 
--no-builtin-rules PACKAGE=LILYPOND package=lilypond -C input all &&  make 
--no-builtin-rules PACKAGE=LILYPOND package=lilypond -C Documentation all && 
true
make[1]: Entering directory `/home/jrioux/git/lilypond/build/python'
make PACKAGE=LILYPOND package=lilypond -C auxiliar all && true
make[2]: Entering directory `/home/jrioux/git/lilypond/build/python/auxiliar'
true
make[2]: Leaving directory `/home/jrioux/git/lilypond/build/python/auxiliar'
make[1]: Leaving directory `/home/jrioux/git/lilypond/build/python'
make[1]: Entering directory `/home/jrioux/git/lilypond/build/scripts'
make PACKAGE=LILYPOND package=lilypond -C build man && true
make[2]: Entering directory `/home/jrioux/git/lilypond/build/scripts/build'
true
make[2]: Leaving directory `/home/jrioux/git/lilypond/build/scripts/build'
make PACKAGE=LILYPOND package=lilypond -C build all && true
make[2]: Entering directory `/home/jrioux/git/lilypond/build/scripts/build'
true
make[2]: Leaving directory `/home/jrioux/git/lilypond/build/scripts/build'
make[1]: Leaving directory `/home/jrioux/git/lilypond/build/scripts'
make[1]: Entering directory `/home/jrioux/git/lilypond/build/flower'
true
make[1]: Leaving directory `/home/jrioux/git/lilypond/build/flower'
make[1]: Entering directory `/home/jrioux/git/lilypond/build/lily'
true
true
make[1]: Leaving directory `/home/jrioux/git/lilypond/build/lily'
make[1]: Entering directory `/home/jrioux/git/lilypond/build/mf'
cd ./out && /usr/local/bin/fontforge -script emmentaler-11.pe
cd ./out && /usr/local/bin/fontforge -script emmentaler-13.pe
cd ./out && /usr/local/bin/fontforge -script emmentaler-14.pe
cd ./out && /usr/local/bin/fontforge -script emmentaler-16.pe
cd ./out && /usr/local/bin/fontforge -script emmentaler-18.pe
cd ./out && /usr/local/bin/fontforge -script emmentaler-20.pe
cd ./out && /usr/local/bin/fontforge -script emmentaler-23.pe
make -C /home/jrioux/git/lilypond/build link-mf-tree
make[2]: Entering directory `/home/jrioux/git/lilypond/build'
make[2]: Nothing to be done for `link-mf-tree'.
make[2]: Leaving directory `/home/jrioux/git/lilypond/build'
true
make[1]: Leaving directory `/home/jrioux/git/lilypond/build/mf'
make[1]: Entering directory `/home/jrioux/git/lilypond/build/ly'
true
make[

Re: ./test-patchy on steroids

[Julien Rioux]

On Wed, Sep 11, 2013 at 6:19 PM, James  wrote:

> Julien,
>
> I just had a bit of a shock when I ran the test-patchy script - then
> realized that I had inadvertently added an extra character before running
> the script
>
> --snip--
> jlowe@jlowe26vm ~/lilypond-extra/patches (master)$ ./test-patches.py ]
> issues [3539, 3521, 3473, 3256, 3194, 3192, 3166, 3086, 3056, 3047, 3031,
> 3026, 3003, 2998, 2968, 2893, 2830, 2801, 2736, 2683, 2681, 2658, 2647,
> 2646, 2594, 2586, 2535, 2474, 2473, 2411, 2368, 2236, 2230, 2207, 2141,
> 2091, 2082, 2066, 2026, 2009, 1908, 1434, 1380, 1370, 1351, 1333, 1278,
> 1269, 1228, 1107, 1093, 1030, 1005, 990, 971, 822, 694, 657, 601, 539, 355,
> 318, 34]
>
>
The interface to test-patches.py allow you to specify a series of issue
numbers on the command line. The command-line parameters are passed to a
search query on the issue page. The list you are getting is definitely
weird, but it matches what the issue page returns for a "id:]" query:
http://code.google.com/p/lilypond/issues/list?q=id%3A]
I have no idea how that makes senses.


> --snip--
>
> ;)
>
> Thought maybe David had gone on some bug-fix rampage!
>
> James
>

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

Re: getting fc-list to see gsfonts

[Julien Rioux]

On 11/09/2013 2:38 PM, Mark Polesky wrote:

Julien Rioux wrote:

But now I'm curious, how do I get fc-list to "see" the
fonts in the gsfonts directory?


Looks like you have to run fc-cache to update the
database. Something like: sudo fc-cache -fsv


Julien and David,

I'll start by reiterating that my build now works fine, as
long as I do:

   ../configure --with-ncsb-dir=/usr/share/fonts/type1/gsfonts/

So, I have a successful workaround.  And yes David, I
manually applied Julien's patch before he pushed it.  Now
I'm simply curious to see how I can get fc-list to see the
fonts.  Julien, I tried both of these:

   sudo fc-cache -fsv
   sudo fc-cache -fsv /usr/share/fonts/type1/gsfonts/

With both commands, I get output that contains this:

   /usr/share/fonts/type1/gsfonts: caching, new cache
   contents: 35 fonts, 0 dirs
   /var/cache/fontconfig: cleaning cache directory
   fc-cache: succeeded

And yet

   fc-list | grep entury

returns nothing, even after rebooting.


I have the same problem (fc database not updating). I'm not sure how to 
update this fc-list stuff, but it seemed to me that fc-cache is the 
command we want to use for it, though, it doesn't seem to work here either.



Julien, I'd like to make a suggestion.  In the error
message, I think it would be far more helpful if instead of
this

   or use --with-ncsb-dir

it said something like this

   or use `configure --with-ncsb-dir=PATH_TO_GSFONTS_DIR'

The point is that it is not at all intuitive to know that
gsfonts is the source of the New Century Schoolbook files.



Well, it's not clear that gsfonts is the correct directory for everyone.

Cheers,
Julien


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

Re: Restore the default `make' target. (issue 13290047)

[julien . rioux]

On 2013/09/11 18:54:01, Mark Polesky wrote:

personally, I would find this wording more intuitive:



   same as `make all', but restricted to the current directory



Sounds good.


Although... I guess `make local-all' and `make default' do the same

thing?

Maybe you could just say



   same as `make local-all'



There isn't a local-all target (although `make help' hints that there
should be). hmm, should probably corrcet this as well.

Cheers,
Julien

https://codereview.appspot.com/13290047/

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

Build everything on the first pass of make. (issue 13333048)

[julien . rioux]

Reviewers: John Mandereau, lemzwerg,

Message:
Please review.

Description:
Build everything on the first pass of make.

Everything should be built and up-to-date after a one-shot `make' call.
Currently, this is not the case: fonts are being rebuilt on the secnod
pass. This required a dependency fix for emmentaler fonts. The
dependencies are ordered so that fonts aren't rebuilt on a subsequent
call to make.

For one-shot `make doc', we also have issues, and things are a bit more
difficult to track down. Dependencies for web.texi in translated
languages are fixed.

Please review this at https://codereview.appspot.com/1048/

Affected files (+5, -4 lines):
  M make/doc-i18n-root-rules.make
  M mf/GNUmakefile


Index: make/doc-i18n-root-rules.make
diff --git a/make/doc-i18n-root-rules.make b/make/doc-i18n-root-rules.make
index  
d374e5ca7339d97b03dace3d413b210eb5ee2174..a8e7ab5edef58af094481bc22cf685056b893d43  
100644

--- a/make/doc-i18n-root-rules.make
+++ b/make/doc-i18n-root-rules.make
@@ -2,7 +2,7 @@
 .SUFFIXES: .html .info .texi .texinfo

 # Explicitly list the dependencies on generated content
-$(outdir)/web.texi: $(outdir)/weblinks.itexi
+$(outdir)/web.texi: $(outdir)/we-wrote.itexi $(outdir)/others-did.itexi  
$(outdir)/weblinks.itexi


 $(top-build-dir)/Documentation/$(outdir)/%/index.$(ISOLANG).html:  
$(outdir)/%/index.html $(TRANSLATION_LILY_IMAGES)

mkdir -p $(dir $@)
Index: mf/GNUmakefile
diff --git a/mf/GNUmakefile b/mf/GNUmakefile
index  
f81b56dabef7f8de1bd4cd73b9bec5c7670b21bd..325bf8f9c97a464105822c873f14cddbfc7fd76f  
100644

--- a/mf/GNUmakefile
+++ b/mf/GNUmakefile
@@ -99,9 +99,10 @@ $(PE_SCRIPTS): $(buildscript-dir)/gen-emmentaler-scripts
$< --dir=$(outdir)


-# Make tfm files first, log files last,
-# so that normally log files aren't made twice
-ALL_GEN_FILES = $(LOG_FILES) \
+# Generate emmentaler-*.pe scripts first, and *.otf, *.svg, *.woff files  
last,
+# so that normally these files aren't regenerated on a subsequent call to  
make.

+ALL_GEN_FILES = $(PE_SCRIPTS) \
+   $(LOG_FILES) \
$(ENC_FILES) \
$(LISP_FILES) \
$(OTF_TABLES) \



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

Disallow metapost versions 1.504 < x < 1.803. (issue 13413046)

[julien . rioux]

Reviewers: dak, lemzwerg,

Message:
Please review.

Description:
Disallow metapost versions 1.504 < x < 1.803.

Add a check in ./configure to avoid these buggy
versions of metapost:

1.504 < mpost --version < 1.803

Fixes issue 3539:
Configure should forbid mpost 1.802 from TexLive 2013
http://code.google.com/p/lilypond/issues/detail?id=3539

Please review this at https://codereview.appspot.com/13413046/

Affected files (+8, -0 lines):
  M aclocal.m4


Index: aclocal.m4
diff --git a/aclocal.m4 b/aclocal.m4
index  
87d8474316adf7dced50154d180d117ff572ac0a..8c03fcc196e45944256ec47ecbe7cf0900d8b0df  
100644

--- a/aclocal.m4
+++ b/aclocal.m4
@@ -1167,6 +1167,14 @@ AC_DEFUN(STEPMAKE_TEXMF_DIRS, [
 AC_DEFUN(STEPMAKE_TEXMF, [
 STEPMAKE_PROGS(METAFONT, mf-nowin mf mfw mfont, $1)
 STEPMAKE_PROGS(METAPOST, mpost, $1)
+if test "$METAPOST" != ""; then
+   ver=`STEPMAKE_GET_VERSION($METAPOST)`
+   num=`STEPMAKE_NUMERIC_VERSION($ver)`
+   # Avoid buggy metapost versions: 1.504 < x < 1.803
+   if test "$num" -gt "1504000" -a "$num" -lt "1803000"; then
+STEPMAKE_ADD_ENTRY($1, ["mpost (due to a bug in metapost,  
versions 1.504 < x < 1.803 are not supported; installed: $ver)"])

+   fi
+fi

 AC_MSG_CHECKING(for working metafont mode)
 modelist='ljfour lj4 lj3 lj2 ljet laserjet'



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

Re: Restore the default `make' target. (issue 13290047)

[julien . rioux]

Updated to be purely documentational.

https://codereview.appspot.com/13290047/

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

Re: getting fc-list to see gsfonts

[Julien Rioux]

On 11/09/2013 3:28 AM, Mark Polesky wrote:

So, after Julien's patch

   https://codereview.appspot.com/13390043

I finally get a proper error at the configure stage:

   ERROR: Please install required programs:  International
   New Century Schoolbook fonts (make sure the fc-list
   utility can see them, or use --with-ncsb-dir)

   See INSTALL.txt for more information on how to build
   LilyPond



Great. This patch is going in so everyone will benefit.


After a lot of searching, I realized that all I needed was

   ../configure --with-ncsb-dir=/usr/share/fonts/type1/gsfonts/

and now my fonts work (finally!).

But now I'm curious, how do I get fc-list to "see" the fonts
in the gsfonts directory?



Looks like you have to run fc-cache to update the database. Something like:
sudo fc-cache -fsv

Cheers,
Julien


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

Re: Restore the default `make' target. (issue 13290047)

[julien . rioux]

Reviewers: dak,

Message:
On 2013/09/06 16:39:24, dak wrote:

https://codereview.appspot.com/13290047/diff/1/stepmake/stepmake/generic-targets.make

File stepmake/stepmake/generic-targets.make (right):



https://codereview.appspot.com/13290047/diff/1/stepmake/stepmake/generic-targets.make#newcode1

stepmake/stepmake/generic-targets.make:1: .PHONY : all clean bin-clean

default

dist exe help html lib man TAGS\
That change might be independently useful.



https://codereview.appspot.com/13290047/diff/1/stepmake/stepmake/generic-targets.make#newcode5

stepmake/stepmake/generic-targets.make:5: default: all
I have no idea what makes you think that default is not a defined

target for

most Makefiles.



git grep "^default:"



turns up a host of default targets.



Documentation/GNUmakefile:default: local-txt-doc
Documentation/css/GNUmakefile:default:
Documentation/logo/GNUmakefile:default: $(lilypond-icon) $(ly-icon)
Documentation/misc/GNUmakefile:default: local-txt-doc
Documentation/pictures/GNUmakefile:default:
GNUmakefile.in:default: $(config_h) build-dir-setup build-scripts
lily/GNUmakefile:default:
make/abc-targets.make:default:
make/doc-i18n-root-targets.make:default:
make/lilypond-book-targets.make:default:
make/midi-targets.make:default:
make/musicxml-targets.make:default:
mf/GNUmakefile:default: $(ALL_GEN_FILES) \
po/GNUmakefile:default: $(MO_FILES)
python/GNUmakefile:default: $(outdir)/relocate-preamble.py
python/auxiliar/GNUmakefile:default:
stepmake/stepmake/automatically-generated.sub.make:default:
stepmake/stepmake/documentation-targets.make:default:
stepmake/stepmake/executable-targets.make:default: $(EXECUTABLE)
stepmake/stepmake/help2man-targets.make:default: man
stepmake/stepmake/library-targets.make:default: $(LIBRARY)
stepmake/stepmake/python-module-targets.make:default:

$(OUT_PY_MODULES) $(OUT_PY

stepmake/stepmake/shared-library-targets.make:default:

$(SHARED_LIBRARY)

stepmake/stepmake/texinfo-targets.make:default: $(INFO_FILES)
stepmake/stepmake/topdocs-targets.make:default: local-txt-doc



So you should likely check which particular Makefile is missing a

default target

and double-check by trying "make default" since there are a lot of

opportunities

for having the default target defined in an include file.


I was confused. default exists, it's just not what I expected after
reading the description: the empty target is equivalent to `make all'
(which recurses through all subdirectories) and not `make default'
(which acts in the local directory only). I'll turn this issue into a
documentation one, changing what `make help' has to say about the
default target.

Cheers,
Julien

Description:
Restore the default `make' target.

`make help' mentions that `default' is the same as the
empty target, but it's not even a defined target. This
commit restores `default' as the default, empty target.

Please review this at https://codereview.appspot.com/13290047/

Affected files (+4, -2 lines):
  M stepmake/stepmake/generic-targets.make


Index: stepmake/stepmake/generic-targets.make
diff --git a/stepmake/stepmake/generic-targets.make  
b/stepmake/stepmake/generic-targets.make
index  
1b998b938dfc3eb6b2c0bbb13dc0aa1c06be10e3..6837bf5558a7411b5fd7dc187b0114bc813aa47f  
100644

--- a/stepmake/stepmake/generic-targets.make
+++ b/stepmake/stepmake/generic-targets.make
@@ -1,8 +1,10 @@
-.PHONY : all clean bin-clean default dist exe help html lib TAGS\
+.PHONY : all clean bin-clean default dist exe help html lib man TAGS\
 po doc doc-stage-1 WWW-1 WWW-2 WWW-post local-WWW-1 local-WWW-2\
 log-clean

-all:default
+default: all
+
+all:
$(LOOP)

 man:



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

Since Bison is optional, need to distribute Documentation/out/ly-grammar.txt (issue 13475043)

[julien . rioux]

LGTM

https://codereview.appspot.com/13475043/

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

Re: Keep bison-generated files in sync. (issue 13466043)

[julien . rioux]

See http://code.google.com/p/lilypond/issues/detail?id=3528


https://codereview.appspot.com/13466043/diff/2001/stepmake/stepmake/c++-rules.make
File stepmake/stepmake/c++-rules.make (right):

https://codereview.appspot.com/13466043/diff/2001/stepmake/stepmake/c++-rules.make#newcode16
stepmake/stepmake/c++-rules.make:16: $(BISON) -o $(subst .hh,.cc,$@) -d
$<
On 2013/09/02 17:46:15, dak wrote:

Han-Wen's version was slightly different:



$(BISON) -d -o $(subst .hh,.cc,$@)  $<



but I don't consider it graceful.  I'd try



$(BISON) -d -o $*.cc  $<



instead.  I _think_ this should take the right directory.


The ordering of -d and -o options doesn't matter, so it was exactly the
same. We can use $* if you prefer, but let's not forget the output dir,
so
$(BISON) -d -o $(outdir)/$*.cc $<
OK?

https://codereview.appspot.com/13466043/diff/2001/stepmake/stepmake/c-rules.make
File stepmake/stepmake/c-rules.make (right):

https://codereview.appspot.com/13466043/diff/2001/stepmake/stepmake/c-rules.make#newcode16
stepmake/stepmake/c-rules.make:16: $(BISON) -o $(subst .h,.c,$@) -d $<
On 2013/09/02 17:46:15, dak wrote:

Do we need this rule at all?  We don't have .y files in the tree and

the only

actual C file would appear to be python/midi.c anyway.


It is part of stepmake, and it is conceivable (although I wouldn't wish
it on anyone) that somebody has decided to use stepmake for their own
project. (lilypond doesn't use this rule)

https://codereview.appspot.com/13466043/

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

Re: patch to remove unused header tie-column-format.hh

[Julien Rioux]

On 21/08/2013 12:32 AM, Frédéric Bron wrote:

Please read
http://www.lilypond.org/doc/v2.17/Documentation/contributor-big-page.html#summary-for-experienced-developers
and start using git-cl. Plain patches posted to -devel tend to get forgotten
in mist of syntax changes and font standards debates.


I know but there is no issue in the tracker for this. Could you create one?

Frédéric



git-cl will create the issue for you when you upload your patch. If it 
doesn't, please report it as a bug.


Cheers,
Julien


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

Re: patch to remove unused header tie-column-format.hh

[Julien Rioux]

On 20/08/2013 3:00 PM, Frédéric Bron wrote:

Dear all,

The header tie-column-format.hh is unused. tie-column-format.cc was
removed in 2.10 and removing the header does not prevent lilypond to
build. Only 2 files were including it without actually using it.
Here is the proposed patch.

Frédéric





Please read 
http://www.lilypond.org/doc/v2.17/Documentation/contributor-big-page.html#summary-for-experienced-developers 
and start using git-cl. Plain patches posted to -devel tend to get 
forgotten in mist of syntax changes and font standards debates.


Cheers,
Julien


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

Re: colorful make output! yum!

[Julien Rioux]

On 20/08/2013 9:00 AM, Phil Holmes wrote:

However, I (and, from what I've seen, David K, and
almost certainly Graham and probably Julien) would strongly oppose adding
extra complexity to the already over-complex build system.


I actually don't mind this, provided I can turn it off. I think it's 
getting more bad reviews than it is deserved, and if it had been 
submitted has a patch in the standard way it probably would have gone 
under the radar.


Cheers,
Julien


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

Re: Windows tutorial updates (issue 12980044)

[julien . rioux]

On 2013/08/17 12:29:08, Julien Rioux wrote:

It looks like we can download individual patches for each file,
so maybe we can use this with Patchy somehow,


I've updated Patchy to handle the "too large to download" patchset. You
can review here: https://github.com/gperciva/lilypond-extra/pull/14 or
grab a full copy here:
https://github.com/jrioux/lilypond-extra/archive/rietveld.zip

I've updated git-cl again to also handle these "too large" patchsets
when doing "git cl patch 12980044". Review here:
https://github.com/gperciva/git-cl/pull/3 or grab a full copy here:
https://github.com/jrioux/git-cl/archive/rietveld.zip

I hope this will make reviewing Phil's work easier.

Cheers,
Julien

https://codereview.appspot.com/12980044/

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

Re: make website fails on platforms where python3 is the default. (issue 12769043)

[julien . rioux]

Reviewers: janek, Graham Percival,

Message:
On 2013/08/16 04:45:59, Graham Percival wrote:

When building with WEBSITE_ONLY_BUILD, $(PYTHON) will default to

python (as

defined at the top of the file).  We do that because we don't run

./configure on

the web server.



I _think_ this will be safe enough, but it might be nice to change the

upper

definition to $(PYTHON) = python2


I did not touch that part specifically because I do not want to break
anything with the current machine that runs this build. Is there a
python2 on the host machine where this command would normally be run?
AFAIK the python2 alias is only installed if python3 is also installed
on the system, which might or might not be the case.

Cheers,
Julien

Description:
make website fails on platforms where python3 is the default.







Use the python found by ./configure to build the website.

Please review this at https://codereview.appspot.com/12769043/

Affected files:
  M make/website.make


Index: make/website.make
diff --git a/make/website.make b/make/website.make
index  
bf3b2ad865d747ef26375efc3f96e272fa7499a3..3e8df628d564f956f0be839224a947ae082b1c54  
100644

--- a/make/website.make
+++ b/make/website.make
@@ -68,11 +68,11 @@ EXTRACT_TEXI_FILENAMES=$(PYTHON)  
$(script-dir)/extract_texi_filenames.py $(quiet

-I $(dir $<) \
-I $(OUT) \
-o $(OUT)
-CREATE_VERSION=python $(script-dir)/create-version-itexi.py
-CREATE_WEBLINKS=python $(script-dir)/create-weblinks-itexi.py
-MASS_LINK=python $(script-dir)/mass-link.py
-WEB_POST=python $(script-dir)/website_post.py
-WEB_BIBS=python $(script-dir)/bib2texi.py
+CREATE_VERSION=$(PYTHON) $(script-dir)/create-version-itexi.py
+CREATE_WEBLINKS=$(PYTHON) $(script-dir)/create-weblinks-itexi.py
+MASS_LINK=$(PYTHON) $(script-dir)/mass-link.py
+WEB_POST=$(PYTHON) $(script-dir)/website_post.py
+WEB_BIBS=$(PYTHON) $(script-dir)/bib2texi.py

 EXAMPLES=$(LILYPOND_WEB_MEDIA_GIT)/ly-examples
 PICTURES=$(LILYPOND_WEB_MEDIA_GIT)/pictures



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

Re: Windows tutorial updates (issue 12980044)

[julien . rioux]

On 2013/08/17 11:31:41, PhilEHolmes wrote:

The patch set on Rietveld now includes the new images (thanks,

Julien).

hmm, the images are there, we can see them in the side-by-side diffs...
but for the patch, Rietveld says "Patch set is too large to download".
Bummer. It looks like we can download individual patches for each file,
so maybe we can use this with Patchy somehow, but for now Patchy still
won't be able to test this.

Anyway, thanks for trying.

Cheers,
Julien

https://codereview.appspot.com/12980044/

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

Re: Support for testing min and max versions of Guile. (issue 11303044)

[Julien Rioux]

On Mon, Jul 22, 2013 at 1:18 PM, Graham Percival
wrote:

> On Mon, Jul 22, 2013 at 02:03:31PM +, d...@gnu.org wrote:
> > As far as I know, 1.9 is the development series culminating in the
> > stable 2.0, so while 1.9 is not all too likely to be installed on
> > current systems, allowing/preferring it over 1.8 is not going to be
> > helpful.  I think the cutoff point should be at 1.9.
>
> Good point.
>
>
I'll make sure to make the change before committing.


> > Do we have an override option for those people who actually want to
> > develop towards 2.0 or are they supposed to edit the autoconf files?
>
> Don't we have a separate branch for guile-2.0?  If not, we should,
> and that branch can change the numbers to "guile 2.0 or higher".
> (or 2.x if we rely on any more recent guile features or bugfixe)
>

One overrides these auto settings in the usual way, setting
GUILE=/path/to/guile etc on the command line. And as you have seen, once we
are ready for guile 2, it's a one-line change in configure.ac

>> Should we document this somewhere?

I think the commit message, pointing to the relevant tracker issue and code
review, should be sufficient.

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

Re: Fedora 19 comes with guile 2.0.9 - cannot use 2.17.22

[Julien Rioux]

On 20/07/2013 5:00 PM, Ian Hulin wrote:

On 13/07/13 20:51, Frédéric Bron wrote:

I don't think ./configure should do this automatically, but at
the very least, it should fail when it finds a guile version that
is incompatible with our source code. Can you please open an
issue for it\?


good point, I will do that. Frédéric


Hi Frédéric,

Could you make the Guile-1 compatibility a separate issue from 3382,
which is about tex-info versions?



These are different issues, I don't think there was ever any confusion 
about that. Frédéric sent a very clear message to lilypond-bugs about it.



Here's a suggestion: add an --enable-guile-1-compatibilty option
defaulting to #t until the Guile 2 conversion cut-over.

If set to true this sets up the variables you mentioned to be exported
in make.

Once the Guile-2 conversion is complete, we reverse the default for
--enable-guile-1-compatibilty to #f.

aclocal.m4 is the bit which does the configure option parsing,

We'd need new internal variable guile_1_compatibility_b which then
controls declaring

 if test "$guile_1_compatibility_b" = yes; then
AC_DEFINE(GUILE_1_COMPATIBILITY)
DEFINES="$DEFINES -DGUILE_1_COMPATIBILITY"
GUILE=" /usr/bin/guile1.8"
GUILE_CONFIG=" /usr/bin/guile1.8-config"
GUILE_TOOLS=" /usr/bin/guile1.8-tools"
 fi

This is untested but you get the idea.  Model the changes for
aclocal.m4 on the --enable-optimising/($)optimising_b sections.

I haven't looked at what would be needed in the makefiles but this
should give you or Julien a start.



I got started already, see 
http://code.google.com/p/lilypond/issues/detail?id=3461. I don't think 
that we need a guile-1 compatibility mode right now, since we don't even 
support guile-2 yet and dropping guile-1 seems pretty far on the horizon.


--
Julien


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

Re: Unable to run test patchy - URI changed for tracker?

[Julien Rioux]

On 18/07/2013 11:46 AM, James wrote:

On 18/07/13 16:08, Phil Holmes wrote:

- Original Message - From: "Julien Rioux" 
To: 
Sent: Thursday, July 18, 2013 4:04 PM
Subject: Re: Unable to run test patchy - URI changed for tracker?



On 18/07/2013 11:00 AM, Phil Holmes wrote:

- Original Message ----- From: "Julien Rioux" 
To: 
Sent: Thursday, July 18, 2013 3:50 PM
Subject: Re: Unable to run test patchy - URI changed for tracker?



On 18/07/2013 2:39 AM, Graham Percival wrote:

On Wed, Jul 17, 2013 at 03:48:52PM +0100, Phil Holmes wrote:

Three options I can think of.  1) use something other than Google.


[...]

3) "Screen scrape".


I'd be seriously concerned about breakage.  That said, it wouldn't
be too bad if we used a fixed format like

PATCHY: info to be parsed\n
\n

for all updates.

- Graham



I tried the scraping idea out, and it wasn't too bad to set up. Might
be good for a temporary fix at least. The result is at
https://github.com/gperciva/lilypond-extra/pull/12

--
Julien



LGTM as a way of getting a list of issues, but I'm still unsure how the
issue labels would be updated, since this requires a logged-in project
member.

--
Phil Holmes


The comment updates using accept-patch.py and reject-patch.py aren't
broken (yet), so let's hope it stays this way.

--
Julien



So - LGTM, although I've only briefly eyeballed it.  Can you push to
the main lilypond-extra repo so James can pull and test it on his
machine?

--
Phil Holmes

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


I can test this now if someone pushes it.

James


Done.

--
Julien


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

Re: Unable to run test patchy - URI changed for tracker?

[Julien Rioux]

On 18/07/2013 11:00 AM, Phil Holmes wrote:

- Original Message - From: "Julien Rioux" 
To: 
Sent: Thursday, July 18, 2013 3:50 PM
Subject: Re: Unable to run test patchy - URI changed for tracker?



On 18/07/2013 2:39 AM, Graham Percival wrote:

On Wed, Jul 17, 2013 at 03:48:52PM +0100, Phil Holmes wrote:

Three options I can think of.  1) use something other than Google.


[...]

3) "Screen scrape".


I'd be seriously concerned about breakage.  That said, it wouldn't
be too bad if we used a fixed format like

PATCHY: info to be parsed\n
\n

for all updates.

- Graham



I tried the scraping idea out, and it wasn't too bad to set up. Might
be good for a temporary fix at least. The result is at
https://github.com/gperciva/lilypond-extra/pull/12

--
Julien



LGTM as a way of getting a list of issues, but I'm still unsure how the
issue labels would be updated, since this requires a logged-in project
member.

--
Phil Holmes


The comment updates using accept-patch.py and reject-patch.py aren't 
broken (yet), so let's hope it stays this way.


--
Julien


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

Re: Unable to run test patchy - URI changed for tracker?

[Julien Rioux]

On 18/07/2013 2:39 AM, Graham Percival wrote:

On Wed, Jul 17, 2013 at 03:48:52PM +0100, Phil Holmes wrote:

Three options I can think of.  1) use something other than Google.


[...]

3) "Screen scrape".


I'd be seriously concerned about breakage.  That said, it wouldn't
be too bad if we used a fixed format like

PATCHY: info to be parsed\n
\n

for all updates.

- Graham



I tried the scraping idea out, and it wasn't too bad to set up. Might be 
good for a temporary fix at least. The result is at 
https://github.com/gperciva/lilypond-extra/pull/12


--
Julien


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

Re: Fedora 19 comes with guile 2.0.9 - cannot use 2.17.22

[Julien Rioux]

On 13/07/2013 6:52 AM, Frédéric Bron wrote:

I read also that:
"The packages will have to be patched to Require and BuildRequire the
compat-guile18(-devel) package. Furthermore, they will have to be
patched (if necessary) to use the renamed autotools macros. The
patches to spec files and autotools macros are easy to implement.
Packages that are already built will not have to be rebuilt (there are
no soname bumps in the compat package) and should function without any
problems. Only new releases will have to be patched."

This confirms that lilypond cannot be built without modification. I
just have to find these "easy to implement" patches... If someone has
ideas!


I found in the src rpm what to do:
export GUILE=/usr/bin/guile1.8
export GUILE_CONFIG=/usr/bin/guile1.8-config
export GUILE_TOOLS=/usr/bin/guile1.8-tools

that works now! Any possibility to do that automatically in configure?
Frédéric



I don't think ./configure should do this automatically, but at the very 
least, it should fail when it finds a guile version that is incompatible 
with our source code. Can you please open an issue for it\?


Cheers,
Julien


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

Re: Issues building documentation on Fedora 19

[Julien Rioux]

On 13/07/2013 3:19 PM, Frédéric Bron wrote:

I can now build lilypond and compile at least the simple score { c }

But when I do my build process:

export GUILE=/usr/bin/guile1.8
export GUILE_CONFIG=/usr/bin/guile1.8-config
export GUILE_TOOLS=/usr/bin/guile1.8-tools
sh autogen.sh --noconfigure
mkdir build
cd build
../configure
make -j8 CPU_COUNT=8

I get the following errors:

Please check the logfile usage.makeinfo.log for errors
Please check the logfile contributor.makeinfo.log for errors

The files are attached and if I remove the warnings, this is what remains:
./build-2013-07-11/Documentation/usage.makeinfo.log:
out/usage/lilypond-book.texi:1179: @itemx must follow @item
out/usage/lilypond-book.texi:1183: @itemx must follow @item
out/usage/lilypond-book.texi:1187: @itemx must follow @item
out/usage/lilypond-book.texi:1192: @itemx must follow @item
out/usage/lilypond-book.texi:1201: @itemx must follow @item
out/usage/lilypond-book.texi:1205: @itemx must follow @item
out/usage/lilypond-book.texi:1210: @itemx must follow @item
out/usage/lilypond-book.texi:1233: @itemx must follow @item

./build-2013-07-11/Documentation/contributor.makeinfo.log:
/home/fred/lilypond/Documentation/included/compile.itexi:925: raising
the section level of @unnumberedsubsubsec which is too low

I wonder if texi2html version in F19 is too new? I have version 1.82 installed.



Not texi2html, but recent texinfo causes problems. The patch is ready 
and I just need to push it. See 
http://code.google.com/p/lilypond/issues/detail?id=3382


Cheers,
Julien



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

Re: Images from Liedboek with attribution

[Julien Rioux]

On 12/06/2013 2:27 PM, James wrote:

Nice. But where are the images of the score?

  ;)



http://www.liedboek.nl/voorbeelden/proefbundel

It looks really nice :)

--
Julien

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

Re: make doc fails

[Julien Rioux]

On 16/03/2013 6:27 PM, David Nalesnik wrote:

/usr/bin/python -tt
/home/david/lilypond-git/scripts/build/create-weblinks-itexi.py >
out-www/weblinks.itexi
make[3]: *** No rule to make target
`/home/david/lilypond-git/Documentation/cs/web/news-front.itexi', needed by
`out-www/web.texi'.  Stop.


Try removing Documentation/cs/out-www/web.dep and running `make doc' 
again. If it succeeds but fails at the next language, repeat for each 
language. Alternatively, if all that fails, try `make doc-clean' and 
running `make doc' again.


Regards,
Julien

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

Re: build: missing explicit dependency?

[Julien Rioux]

On Thu, Mar 14, 2013 at 5:39 AM, Francisco Vila  wrote:
> 2013/3/12 Julien Rioux :
>> OK I see, so testing for the binaries is not enough. We`ll need to
>> find out what else is required and add a test for it. Does anybody
>> know? If you or anyone else do uninstall texlive-metapost and provide
>> a log from a failed make, I think that would be useful.
>
> I uninstalled texlive-metapost and removed the mf/out directory. Then
> issued ./autogen.sh and obtained the green light to run 'make'. It
> stopped with these last lines:
>
> Output written on parmesan-noteheads26.600gf (101 characters, 29364 bytes).
> Transcript written on parmesan-noteheads26.log.
> mv parmesan-noteheads26.log parmesan-noteheads26.tfm ./out
> rm -f parmesan-noteheads26.*gf  parmesan-noteheads26.*pk
> ~/source/lilypond/scripts/build/out/mf-to-table \
> --global-lisp=./out/feta11.otf-gtable \
> --lisp=./out/feta11.lisp \
> --outdir=./out \
> --enc ./out/feta11.enc \
> out/feta11.log
> cd ./out \
>&& touch mf2pt1.mem \
>&& mpost -progname=mpost -ini ~/source/lilypond/mf/mf2pt1.mp \\dump
> This is MetaPost, version 1.504 (kpathsea version 6.1.0)
> (~/source/lilypond/mf/mf2pt1.mp
> ! I can't open file `mfplain'.
> l.27 input mfplain
>   ;
> Please type another input file name:
>
>
> That's it. I searched for mfplain and found that texlive-metapost provides
>
>   /usr/share/texlive/texmf-dist/metapost/base/mfplain.mp
>
> and
>
>   /usr/share/texlive/texmf-dist/metapost/config/mfplain.ini
>
> So I installed the package and compiling could continue.
>
> Thanks
> --
> Francisco Vila. Badajoz (Spain)
> www.paconet.org , www.csmbadajoz.com

This commit: 
http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commit;h=8d2268dbc8bcd94e14105196a8f8ac0ed8fceb34

adds the file mp/mf2pt1.mp to our git repository. This file contains
"input mfplain" so it relies on mfplain.mp being available. We can
search for mfplain.mp during ./configure using kpsewhich, but I wonder
if we should instead just distribute this file in our git repository
along with mf2pt1.mp? c.c.ing Werner who added mf2pt1.mp initially.

--
Julien

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

Re: build: missing explicit dependency?

[Julien Rioux]

On Tue, Mar 12, 2013 at 2:05 PM, Francisco Vila  wrote:
> 2013/3/12 Julien Rioux :
>> On 02/03/2013 11:54 AM, Francisco Vila wrote:
>>>
>>> Hello. When trying to build lilypond, I had to install the
>>> texlive-metapost package which the autogen.sh did not ask for. Is this
>>> a flaw of the config process?
>>>
>>
>> Actually, ./configure is checking for both mf and mpost. Do you still have a
>> config.log around from the failing build by any chance?
>
> No. I have one that contains
>
> configure:7216: found /usr/bin/mpost
> configure:7227: result: mpost
> ...
> configure:7067: found /usr/bin/mf-nowin
> configure:7078: result: mf-nowin
>
> but mpost and mf-nowin are provided by the texlive-binaries package in
> my distro. I had to install texlive-metapost in addition. I could try
> uninstalling it and see if it fails.
>
> --
> Francisco Vila. Badajoz (Spain)
> www.paconet.org , www.csmbadajoz.com

OK I see, so testing for the binaries is not enough. We`ll need to
find out what else is required and add a test for it. Does anybody
know? If you or anyone else do uninstall texlive-metapost and provide
a log from a failed make, I think that would be useful.

Cheers,
Julien

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

Re: build: missing explicit dependency?

[Julien Rioux]

On 02/03/2013 11:54 AM, Francisco Vila wrote:

Hello. When trying to build lilypond, I had to install the
texlive-metapost package which the autogen.sh did not ask for. Is this
a flaw of the config process?



Actually, ./configure is checking for both mf and mpost. Do you still 
have a config.log around from the failing build by any chance?


--
Julien

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

Re: Alternative pixel-based regtest checker

[Julien Rioux]

On 01/03/2013 2:15 PM, Phil Holmes wrote:

4 files attached.  To try this out: create a new directory and place
NoTagline.ly in it.  Create a subdirectory called input and put some
regtest files in there.  Run MakeOldPix.sh.  Make a change to lilypond.
Run MakeNewPix.sh.  Run ComparePix.sh.  Om my tests there were some
false alarms, but it seems a fairly simple way to make an alternative
regtest checker.

There's lots of improvements that could be made: parallelism, using
something other than diff, but it basically works.

Thoughts?

--
Phil Holmes



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



I haven't tested your code, I am sure it is useful, I just have one 
thing to note: Are you aware of the --threshold command-line switch for 
script/build/output-distance.py? I wonder if setting it to a lower 
default value would not reveal the "missing" regtest changes that you 
are presumably looking for.


--
Julien

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

Re: build: missing explicit dependency?

[Julien Rioux]

On 05/03/2013 11:07 AM, Francisco Vila wrote:

2013/3/3 James :

On 2 March 2013 16:54, Francisco Vila  wrote:

Hello. When trying to build lilypond, I had to install the
texlive-metapost package which the autogen.sh did not ask for. Is this
a flaw of the config process?



Well when I follow the NR to install the software to compile LP the
builddep-lilypond seems to contain this


NR? you mean CG
http://lilypond.org/doc/v2.17/Documentation/contributor/requirements-for-compiling-lilypond
What is the builddep-lilypond and why do we link to ubuntu? Sorry, I
don't understand.



https://launchpad.net/ubuntu/precise/+source/lilypond

I am not sure what Linux Dist you are using but did you follow the NR or are
you getting the parts in a different way.


I tried not to install any package that weren't required and therefore
I installed only what config took as enough to start compiling. After
issuing 'make' it did fail for a missing package not listed explicitly
by autogen.sh

Yes, CG does lists metapost. But this peckage was not auto-installed
as a dependency from other previous packages.



I agree that this looks like something that the configure script should 
have caught. Thanks for reporting it, we should open an issue for it.


--
Julien

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

Re: DOC: Update CG 8.7 Patch Handling (issue 7101048)

[julien . rioux]

Reitveld -> Rietveld

https://codereview.appspot.com/7101048/

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

Re: CG: explicitly detail the correct values for git cl config (issue 7096052)

[julien . rioux]

At this point, the git-cl used by the project has been sufficiently
geared towards lilypond development that I somewhat doubt anybody is
using it for work outside of lilypond. It might not make sense at all
for "our" git-cl to keep asking these superfluous questions; should they
be remove entirely?

https://codereview.appspot.com/7096052/

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

Fix KeyError in website_post.py from Issue 847 (issue 7021043)

[julien . rioux]

LGTM

https://codereview.appspot.com/7021043/

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

Re: Update contributors. (issue 6689045)

[Julien Rioux]

On Fri, Oct 19, 2012 at 8:47 AM, Janek Warchoł  wrote:
> On Fri, Oct 19, 2012 at 10:36 AM,   wrote:
>> I missed that Bertrand Bordage, Joe Neeman, and Carl D. Sorensen are
>> listed both under "developers" and "contributors". According to the
>> policy they should be removed from "contributors". Also Colin Hall is
>> listed under "developers" so probably should not be added under
>> "contributors: bug squad" like I did.
>>
>> The list of main developers looks rather long. Are there any "current
>> developers" to move to "previous developers" (e.g. they haven't been
>> around for a while)?
>
> depends on what you mean.
> I don't remember any commits from Jonathan Kulp, Mark Polesky, Carl
> Sorensen and Neil Puttock in past couple of months, but all of them
> send an email or two from time to time.
> Janek

Seems fine then. I meant more like if there was inactivity for years.

Cheers,
Julien

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

Re: Update contributors. (issue 6689045)

[julien . rioux]

I missed that Bertrand Bordage, Joe Neeman, and Carl D. Sorensen are
listed both under "developers" and "contributors". According to the
policy they should be removed from "contributors". Also Colin Hall is
listed under "developers" so probably should not be added under
"contributors: bug squad" like I did.

The list of main developers looks rather long. Are there any "current
developers" to move to "previous developers" (e.g. they haven't been
around for a while)?

Cheers,
Julien

http://codereview.appspot.com/6689045/

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

Re: problem uploading a patch

[Julien Rioux]

On 10/17/2012 02:55 PM, David Nalesnik wrote:

Julien,

On Wed, Oct 17, 2012 at 1:33 AM, Julien Rioux
  wrote:

On 16/10/2012 4:36 PM, David Nalesnik wrote:


david@david-desktop ~/lilypond-git (dev/measure_counter)$ git cl issue
2445
Issue number: 2445 (http://codereview.appspot.com/2445)



This should be the issue number from the Rietveld page, not the one from
google code page.



OK, I see.  Thanks!

I figured that I'd need to create the Rietveld issue first, which I
attempted to do using the issue creation form.  Unfortunately, I can't
get past the requirement for a url or uploaded file.  What should I do
here?

-David


$ git cl issue 0

to reset (remove any association to a Rietveld issue)

$ git cl upload origin/master

to upload (given that the branch is no longer associated to a Rietveld 
issue, it will create a new Rietveld issue)


Cheers,
Julien

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

Re: problem uploading a patch

[Julien Rioux]

On 16/10/2012 4:36 PM, David Nalesnik wrote:

david@david-desktop ~/lilypond-git (dev/measure_counter)$ git cl issue 2445
Issue number: 2445 (http://codereview.appspot.com/2445)


This should be the issue number from the Rietveld page, not the one from 
google code page.


--
Julien

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

Re: Update contributors. (issue 6689045)

[Julien Rioux]

On Mon, Oct 15, 2012 at 5:18 PM,   wrote:
> Sorry, there's a bit of confusion here.  The past policy was:

Thanks, I've updated the file to clarify the policy and made sure that
I do not move contributors from past to current but simply add them to
current.

Cheers,
Julien

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

Re: Translations for create-weblinks-itexi.py (issue 6681045)

[Julien Rioux]

On Mon, Oct 15, 2012 at 7:40 AM,   wrote:
> this looks strange: when i go to side-by-side diffs, i don't see any
> changes, just "error: old chunk mismatch".

I don't know what caused that, but you can rely on the raw patch set.
Since this patch only adds lines and does not remove any lines, the
reviewing shouldn't suffer much from missing side-by-side view.

Cheers,
Julien

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

Re: convert-ly (issue 2670) (issue 6610058)

[Julien Rioux]

On Mon, Oct 8, 2012 at 4:08 PM,   wrote:
> The changelog says
>
> "Don't update \version when no rule is applied."
>
> That's what the existing -d --diff-version-update command does.  If this
> is intended to be the default behaviour now, then the command-line
> option should be removed.

No, -d does not become the default; the behavior of convert-ly is
unchanged when rules are being applied, and -d is still used in the
same way. The change concerns itself only with the case that no rule
applies, because the version of the file is already up-to-date. In
this case, it used to be that the version in the file would be set to
version of the last rule, which would sometimes mean that the version
of the file upon output is lower than the version at input. This is
what we avoid in this patch.

Please consult http://code.google.com/p/lilypond/issues/detail?id=2670
and references therein.

Cheers,
Julien

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

Re: [talk] why it'd be great to have web interface for submittingsimple doc patches

[Julien Rioux]

On 07/10/2012 5:33 AM, Phil Holmes wrote:

- Original Message - From: "Joseph Rushton Wakeling"

To: "Phil Holmes" 
Cc: "James" ; 
Sent: Saturday, October 06, 2012 5:26 PM
Subject: Re: [talk] why it'd be great to have web interface for
submittingsimple doc patches



On 10/06/2012 05:46 PM, Phil Holmes wrote:

As you say, compile-edit-compile cycles are shorter than the full
build, but can
occasionally not reveal errors, so for a proper test it's always
better to nuke
the build directory and rebuild from scratch.


Out of curiosity, what kind of errors?  I imagine stuff involving
cross-references, the index, etc.?



It's more that there are a variety of outputs generated from the doc
source - pdf, split html, large html, info, etc. - to be sure that the
source is OK you need to be certain all have been generated and
therefore checked, and the simplest way of ensuring that is from a clean
build.

--
Phil Holmes


It should be possible to avoid make clean. There will be a need for make 
doc-clean when moving or removing an included file. Other cases should 
be considered as bugs. If you witness that something doesn't get 
regenerated after you modified a file, please file it as a bug.


--
Julien


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

Re: convert-ly (issue 2670) (issue 6610058)

[Julien Rioux]

On Sat, Oct 6, 2012 at 1:06 AM,  wrote:

> Are you going to report the number of errors using the `errors'
> variable?  In case this is true, I would consider this a bad idea, since
> you abuse the functionality of the exit status.
>
> How large can `errors' become?  The value returned by `exit' must be in
> the range 0-255 (with 0 meaning `no error').
>
> http://codereview.appspot.com/**6610058/
>

I thought it would be interesting to track the number of errors, yes, but
you are absolutely right. I`ll change it to return 0 (success) or 1
(failure).

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

Re: lilypond-book: treat iffalse sections in latex as block comments (issue 6584073)

[julien . rioux]

Try to add a regression test example with a valid lilypond block
inbetween two multiline comments.


http://codereview.appspot.com/6584073/diff/1/python/book_latex.py
File python/book_latex.py (right):

http://codereview.appspot.com/6584073/diff/1/python/book_latex.py#newcode88
python/book_latex.py:88: \\iffalse.*\\fi))''',
.* should be replaced by the non-greedy .*?

http://codereview.appspot.com/6584073/

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

convert-ly (issue 2670) (issue 6610058)

[julien . rioux]

Reviewers: ,

Message:
For review:

Description:
convert-ly:

- Exit with error status when errors occur.

- Use unicode strings for file names printing.

- Don't update \version when no rule is applied.

This fixes issue 2670.

Please review this at http://codereview.appspot.com/6610058/

Affected files:
  M scripts/convert-ly.py


Index: scripts/convert-ly.py
diff --git a/scripts/convert-ly.py b/scripts/convert-ly.py
index  
2772acc7382c144590cb73ca2da6c3db58603059..c755eb71c3a10a2a4556c2dd16b433dc9f42a386  
100644

--- a/scripts/convert-ly.py
+++ b/scripts/convert-ly.py
@@ -185,10 +185,9 @@ string."""

 ly.progress (_ ("Applying conversion: "), newline = False)

-last_conversion = ()
+last_conversion = None
+errors = 0
 try:
-if not conv_list:
-last_conversion = to_version
 for x in conv_list:
 if x != conv_list[-1]:
 ly.progress (tup_to_str (x[0]), newline = False)
@@ -202,8 +201,9 @@ string."""
 ly.error (_ ("Error while converting")
   + '\n'
   + _ ("Stopping at last successful rule"))
+errors += 1

-return (last_conversion, str)
+return (last_conversion, str, errors)



@@ -228,7 +228,7 @@ class InvalidVersion (Exception):
   self.version = version

 def do_one_file (infile_name):
-ly.progress (_ ("Processing `%s\'... ") % infile_name, True)
+ly.progress (_ (u"Processing `%s\'... ") % infile_name, True)

 if infile_name:
 infile = open (infile_name, 'r')
@@ -256,12 +256,12 @@ def do_one_file (infile_name):
 raise InvalidVersion (".".join ([str(n) for n in from_version]))


-(last, result) = do_conversion (input, from_version, to_version)
+(last, result, errors) = do_conversion (input, from_version,  
to_version)


+if global_options.force_current_version and \
+(last is None or last == to_version):
+last = str_to_tuple (program_version)
 if last:
-if global_options.force_current_version and last == to_version:
-last = str_to_tuple (program_version)
-
 if global_options.diff_version_update:
 if result == input:
 # check the y in x.y.z  (minor version number)
@@ -281,23 +281,24 @@ def do_one_file (infile_name):
 elif not global_options.skip_version_add:
 result = newversion + '\n' + result

-ly.progress ('\n')
-
-if global_options.edit:
-try:
-os.remove(infile_name + '~')
-except:
-pass
-os.rename (infile_name, infile_name + '~')
-outfile = open (infile_name, 'w')
-else:
-outfile = sys.stdout
-
+ly.progress ('\n')

-outfile.write (result)
+if global_options.edit and result != input:
+try:
+os.remove(infile_name + '~')
+except:
+pass
+os.rename (infile_name, infile_name + '~')
+outfile = open (infile_name, 'w')
+else:
+outfile = sys.stdout

+outfile.write (result)
+
 sys.stderr.flush ()

+return errors
+
 def do_options ():
 opt_parser = get_option_parser()
 (options, args) = opt_parser.parse_args ()
@@ -331,25 +332,29 @@ def main ():

 identify ()

+errors = 0
 for f in files:
 if f == '-':
-f = ''
-elif not os.path.isfile (f):
-ly.error (_ ("%s: Unable to open file") % f)
-if len (files) == 1:
-sys.exit (1)
+continue
+f = f.decode(sys.stdin.encoding or "utf-8")
+if not os.path.isfile (f):
+ly.error (_ (u"%s: Unable to open file") % f)
+errors += 1
 continue
 try:
-do_one_file (f)
+errors += do_one_file (f)
 except UnknownVersion:
-ly.error (_ ("%s: Unable to determine version.  Skipping") % f)
+ly.error (_ (u"%s: Unable to determine version.  Skipping") %  
f)

+errors += 1
 except InvalidVersion:
 # Compat code for 2.x and 3.0 syntax ("except .. as v" doesn't
 # work in python 2.4!):
 t, v, b = sys.exc_info ()
-ly.error (_ ("%s: Invalid version string `%s' \n"
+ly.error (_ (u"%s: Invalid version string `%s' \n"
  "Valid version strings consist of three numbers, "
  "separated by dots, e.g. `2.8.12'") % (f,  
v.version) )

+errors += 1
+sys.exit(errors)


 main ()



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

Re: make test

[Julien Rioux]

On 08/08/2012 4:59 AM, Phil Holmes wrote:

I've been looking at how the regression test comparison works.  The
first thing I find is that we have 2 effectively duplicate, but
different, pages on running regtest comparisons:

http://lilypond.org/doc/v2.15/Documentation/contributor/verify-regression-tests

http://lilypond.org/doc/v2.15/Documentation/contributor/regtest-comparison

I think the latter is probably more accurate.  I think it would be best
to delete one and point to the other?

I've also been benchmarking.  For example, I know that make CPU_COUNT=9
test is _much_ faster than make test, but the make -j9 test isn't worth
doing - most of the time is spent building the single regtest document,
which lilypond parallelises much better than make.  I have had errors
using -jX so am slightly suspicious of that option.  I would like to add
the best way to parallelise the test process to the CG.



Currently the build system is set up so that all regtests in a given 
directory are processed by one instance of lilypond (called from 
lilypond-book). Since there is only one process, there really isn't 
anything that `make' could parallelize in this area. At the same time, 
there's nothing to fear in using -j9 to make test.



I've also been looking at how output-distance works.  Does anyone now
understand what this actually does?  From following the code, it looks
to me like it doesn't actually compare images - it compares the
.signature files, and if there's a difference over the threshold, it
creates an image of the original and changed file, and then makes a
"ghost" version of the change to overlay on the original.  Does this
seem correct.  Worth documenting?

--
Phil Holmes



--
Julien


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

Re: Patchy switches for forcing make doc don't seem to work

[Julien Rioux]

On 20/08/2012 8:53 AM, James wrote:

John,

On 20 August 2012 13:09, John Mandereau  wrote:

Hi James,
Il giorno lun, 20/08/2012 alle 10.40 +0100, James ha scritto:

I am not able to work out how to force patchy during a test-patches.py
to also make doc as well as the test and test-baseline.

I don't have access to my machine I run patchy on at the moment - it
is at home and I am at work - but there is an entry in one of the
'conf' files that allows me to set the option to make doc 'TRUE'.


Are you sure there is such an entry?  I have looked at the configuration
files
(patches/{lilypond-patchy-config-DEFAULT,compile_lilypond_test/pachy_config.py})
 git history, and I haven't found anything that kinda matched.


https://github.com/gperciva/lilypond-extra/blob/master/patches/compile_lilypond_test/__init__.py

Line #37



On line #431, change quick_make=True to quick_make=False and you will be 
doing a `make doc' (in addition to `make check' and everything).


A command-line switch would be much better, but for the time being this 
is something you could do.


Cheers,
Julien


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

Re: Fix for several musicxml2ly bugs. (issue 5697059)

[julien . rioux]

Hi Patrick,

A cleaned up version of this patch has been committed (and credited to
you), so you may close this Rietveld issue. You will see the fix in
version 2.15.41, the next development release.

Cheers,
Julien

http://codereview.appspot.com/5697059/

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

Re: LSR updates and translations

[Julien Rioux]

On 25/06/2012 1:53 PM, John Mandereau wrote:

Il giorno lun, 25/06/2012 alle 18.50 +0100, Phil Holmes ha scritto:

And John M could no doubt help. It's a question of how much time they have
to contribute.


If what we want to achieve is well enough specified, then I can offer to
go for it.

Cheers,
John



I would be happy to help, too, though time is sparse. What I miss here 
is a concrete example of what is needed, as I couldn't quite figure out 
the actual problem at hand.


Cheers,
Julien




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

Re: Add missing shebang line in MacOSX instructions. (issue 6300118)

[julien . rioux]

Reviewers: Graham Percival,

Message:
On 2012/06/22 08:19:29, Graham Percival wrote:

I thought that bash doesn't need the shebang in some cases?  at least,

I could

have sworn that I never added the shebang in this case?


As I understand it, problems ensue when you try to call that script from
python.

--
Julien

Description:
Add missing shebang line in MacOSX instructions.

Please review this at http://codereview.appspot.com/6300118/

Affected files:
  M Documentation/web/download.itexi


Index: Documentation/web/download.itexi
diff --git a/Documentation/web/download.itexi  
b/Documentation/web/download.itexi
index  
55306b48d89798718b81951c45706e9343885d25..365ecedaa3595aac6da3db6860c35f72d1653778  
100644

--- a/Documentation/web/download.itexi
+++ b/Documentation/web/download.itexi
@@ -358,6 +358,7 @@ Create a file called @command{lilypond} which contains

 @divClass{h-scroll-auto}
 @example
+#!/bin/bash
 exec @var{DIR}/LilyPond.app/Contents/Resources/bin/lilypond "$@@"
 @end example
 @divEnd



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

Re: Treat accidentals parentheses as cautionary (issue 6310065)

[julien . rioux]

Reviewers: MikeSol, Graham Percival,

Message:
On 2012/06/22 08:20:56, Graham Percival wrote:

LGTM, although I'd personally have prepended "musicxml2ly:" to the

beginning of

the patch subject line.  That makes it much more obvious when skimming

the git

history (or just available patches to review).


I just did a git am using his patch, but I'll amend the commit before
pushing. Do we need some license statement from Rodolfo?

--
Julien

Description:
Treat accidentals parentheses as cautionary

Patch from Rodolfo Zitellini

Please review this at http://codereview.appspot.com/6310065/

Affected files:
  M scripts/musicxml2ly.py


Index: scripts/musicxml2ly.py
diff --git a/scripts/musicxml2ly.py b/scripts/musicxml2ly.py
index  
69125dc9db6cdccbb52d47c19296c6191974fa4e..cd76ebeca3e14d073aa7c24d6c0098c040d9c1c9  
100644

--- a/scripts/musicxml2ly.py
+++ b/scripts/musicxml2ly.py
@@ -1784,8 +1784,12 @@ def musicxml_note_to_lily_main_event (n):

 acc = n.get_maybe_exist_named_child ('accidental')
 if acc:
-# let's not force accs everywhere.
-event.cautionary = acc.cautionary
+# AccidentalCautionary in lily has parentheses
+# so treat accidental explicitly in parentheses as cautionary
+if hasattr(acc, 'parentheses') and acc.parentheses == "yes":
+event.cautionary = True
+else:
+event.cautionary = acc.cautionary
 # TODO: Handle editorial accidentals
 # TODO: Handle the level-display setting for displaying  
brackets/parentheses





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

Re: Website build crashing

[Julien Rioux]

On 26/04/2012 5:53 AM, m...@mikesolomon.org wrote:

Hey all,

My website build crashes with:

mikesol@mikesol-laptop:~/lilypond-git$ sudo make 
LILYPOND_WEB_MEDIA_GIT=/home/mikesol/lilypond-extra website
make --no-builtin-rules config_make=./config.make \
top-src-dir=/home/mikesol/lilypond-git \
-f /home/mikesol/lilypond-git/make/website.make \
website
make[1]: Entering directory `/home/mikesol/lilypond-git'
cp /home/mikesol/lilypond-git/Documentation/misc/out 
out-website/website/misc/out
cp: omitting directory `/home/mikesol/lilypond-git/Documentation/misc/out'
make[1]: *** [out-website/website/misc/out] Error 1
make[1]: Leaving directory `/home/mikesol/lilypond-git'
make: *** [website] Error 2

It seems that the cp command is trying to copy the misc/out directory without 
adding the -r flag.  Can someone confirm this problem before I open a tracker 
issue?

Cheers,
MS



I confirm. Did you create an issue for it?

--
Julien


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

Re: Changes .tex files to get rid of warning (issue 5976055)

[Julien Rioux]

On Mon, Apr 2, 2012 at 11:11 AM, Phil Holmes  wrote:
> - Original Message - From: "Julien Rioux" 
> To: ; ;
> ; ; ;
> 
>
>> > A snippet with a deprecated option, triggering compatibility mode:
>> >
>> > -\lilypond[11pt,fragment]{c' e' g'}
>> > +\lilypond[staffsize=11,fragment]{c' e' g'}
>> >
>> > \end{document}
>>
>> This change to tex-compatibility-mode.tex makes no sense. The whole
>> point of this file is to test that deprecated options are still
>> supported.
>> --
>> Julien
>
>
> Excellent catch - thanks, Julien.  I was in auto-correct mode.  How do you
> suggest we correct this?  I doubt we want this warning displayed.
> run-and-check?
>
> --
> Phil Holmes
>
>

Yes I think run-and-check is fine for this.
--
Julien

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

Doc: CG Update compile.itexi for doc build (issue 5967060)

[julien . rioux]

LGTM

http://codereview.appspot.com/5967060/

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

Re: Changes .tex files to get rid of warning (issue 5976055)

[Julien Rioux]

On Sun, Apr 1, 2012 at 2:32 PM,   wrote:
> Reviewers: Julien Rioux, Graham Percival, dak,
>
> Message:
> Please review
>
> Description:
> These files used what appears to be a deprecated syntax to invoke
> lilypond-book, resulting in these warnings:
>
> lilypond-book.py: warning: deprecated ly-option used: 11pt=None
> lilypond-book.py: warning: compatibility mode translation: staffsize=11
>
> Applying these changes gets rid of those errors in make doc.
>
> Please review this at http://codereview.appspot.com/5976055/
>
> Affected files:
>  Documentation/usage/latex-lilypond-example.latex
>  M input/regression/lilypond-book/tex-comments.lytex
>  M input/regression/lilypond-book/tex-compatibility-mode.lytex
>  M input/regression/lilypond-book/tex-lilypond-inside-itemize.lytex
>  M input/regression/lilypond-book/tex-lilypond-inside-table.lytex
>
>
> Index: input/regression/lilypond-book/tex-compatibility-mode.lytex
> diff --git a/input/regression/lilypond-book/tex-compatibility-mode.lytex
> b/input/regression/lilypond-book/tex-compatibility-mode.lytex
> index
> aab288e7b3504e235b72706b45e27688cade59ca..933b7ec4fd7d82fbcffd231baf0ded51d8cc2c0e
> 100644
> --- a/input/regression/lilypond-book/tex-compatibility-mode.lytex
> +++ b/input/regression/lilypond-book/tex-compatibility-mode.lytex
> @@ -5,6 +5,6 @@
>
>  A snippet with a deprecated option, triggering compatibility mode:
>
> -\lilypond[11pt,fragment]{c' e' g'}
> +\lilypond[staffsize=11,fragment]{c' e' g'}
>
>  \end{document}

This change to tex-compatibility-mode.tex makes no sense. The whole
point of this file is to test that deprecated options are still
supported.
--
Julien

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

Re: volunteer for patchy new-patches

[Julien Rioux]

On 27/03/2012 3:20 PM, Marek Klein wrote:

2012/3/27 Julien Rioux


On 27/03/2012 2:58 PM, Marek Klein wrote:



However, I cannot find the log file :(

On a default configuration this logfile would be in

/tmp/lilypond-autobuild

Cheers,
Julien



Here it is:
http://gregoriana.sk/data/log-None-nice-make-test-baseline--j3-CPU_COUNT=3.txt

(The word "Chyba" means Error)

Marek




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


So it points to 
/tmp/lilypond-autobuild/build/out/lybook-testdb/snippet-names--7220266384705246370.log


Is that file still around?

--
Julien


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

Re: volunteer for patchy new-patches

[Julien Rioux]

On 27/03/2012 2:58 PM, Marek Klein wrote:

2012/3/27 James


I reset one of mine on the countdown

http://code.google.com/p/lilypond/issues/detail?id=2216

Try that.





This is the output:



Trying issue 2216
Found patch: (2216, '/home/marek/lilypond-patchy/issue5843060_6001.diff',
'AU: Document all options for lilypond -dhelp')
Problem compiling master. Patchy cannot reliably continue.
Traceback (most recent call last):
   File "test-patches.py", line 16, in
 main(issues_id)
   File "test-patches.py", line 12, in main
 patchy.do_check(issues)
   File "/home/marek/lilypond-patchy/projecthosting_patches.py", line 213,
in do_check
 compile_lilypond_test.main(patches)
   File "/home/marek/lilypond-patchy/compile_lilypond_test.py", line 289, in
main
 raise err
Exception: Failed runner: nice make test-baseline -j3 CPU_COUNT=3
See the log file log-None-nice-make-test-baseline--j3-CPU_COUNT=3.txt


However, I cannot find the log file :(

Marek




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


On a default configuration this logfile would be in /tmp/lilypond-autobuild

Cheers,
Julien


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

Re: dist-check failure

[Julien Rioux]

On 26/03/2012 8:42 PM, Graham Percival wrote:

ge.ja.html
file from VC not distributed:
lilypond-2.15.35/Documentation/misc/browser-language.nl.html
file from VC not distributed:
lilypond-2.15.35/input/regression/lilypond-book/include/example.ly
file from VC not distributed:
lilypond-2.15.35/input/regression/lilypond-book/include/myvar.ily
rm -rf /tmp/tmpGQR4Q7
Traceback (most recent call last):
   File "test-lily/dist-check.py", line 137, in
 main ()
   File "test-lily/dist-check.py", line 132, in main
 check_files (tarball, repo)
   File "test-lily/dist-check.py", line 117, in check_files
 raise Exception ('dist error found')
Exception: dist error found


- Graham


Is it fixed now with master?

--
Julien


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

Re: In-tree make check fails with lilypond-book include file regtest.

[Julien Rioux]

On 27/03/2012 9:37 AM, David Kastrup wrote:

David Kastrup  writes:


commit ee70161485a2d2f347db3e29724a943c741ef524
Author: Julien Rioux
Date:   Wed Mar 21 09:13:55 2012 -0400

 Regtests for lilypond-book include files located in subdir.


causes the regtests to fail.  Rerunning configure, make clean and make
test does not help.


Reverted for now.



I locally reverted your revert and could make, make test and make doc 
from scratch in the src dir after the fixes that I committed today. 
Unless there is any objections I will push the revert of the revert to 
staging.


--
Julien


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

Re: volunteer for patchy new-patches

[Julien Rioux]

On 27/03/2012 1:48 PM, Marek Klein wrote:

Hi,
2012/3/23 Graham Percival



Well, you need to figure out why
  git fetch
in your $LILYPOND_GIT repository fails.



git fetch works now...

I need som new patch for play with...

Marek




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


When there are no issues with a label of Patch=new, you can still test 
patches by specifying issue numbers on the command line like this:


python test-patches.py 2216

without having to reset the said issue.

--
Julien


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

Re: Don't reload initialization files when processing multiple files (issue 5874044)

[julien . rioux]

LGTM

http://codereview.appspot.com/5874044/

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

Re: Tracks old announcements, news and changelogs. (issue 5843069)

[Julien Rioux]

On Fri, Mar 23, 2012 at 5:12 AM,   wrote:
> Awesome work as always.  There's some unintended (and bad) changes to
> GNUmakefile.in.
>

That's a mistake when I uploaded (pointing to the wrong commit in
git-cl upload). Just trust me that I won't commit this, but I am not
uploading again in order to get the countdown over with.

> It's also missing the changelog and announcement for 2.14, but that can
> get added in a different patch.  The important thing is to get this
> infrastructure pushed.
>

hmmm, where are those? Not in the origin/archive/web branch.
--
Julien

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

Re: lilypond-book: Set include path for --output option (issue 2423). (issue 5846075)

[Julien Rioux]

On Fri, Mar 23, 2012 at 4:33 AM,   wrote:
> I'm seeing "old chunk mismatch" for this patch.  Could you try uploading
> it again to a new rietveld issue?
>
> http://codereview.appspot.com/5846075/

Fixed, it was a bad upload (no need for a new issue number).

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

Re: lilypond-book: Set include path for --output option (issue 2423). (issue 5846075)

[Julien Rioux]

On Wed, Mar 21, 2012 at 9:37 AM, Julien Rioux  wrote:
> On Wed, Mar 21, 2012 at 1:39 AM,   wrote:
>>
>> http://codereview.appspot.com/5846075/diff/1/scripts/lilypond-book.py
>> File scripts/lilypond-book.py (right):
>>
>> http://codereview.appspot.com/5846075/diff/1/scripts/lilypond-book.py#newcode639
>> scripts/lilypond-book.py:639: global_options.include_path.insert (0,
>> inverse_relpath (original_dir, global_options.output_dir))
>> Wouldn't it be easier if you just added the absolute path to
>> original_dir?
>>
>
> It would be easier, but I think the proposed patch is a better
> implementation. Using absolute paths makes the document less portable
> and prone to errors caused by any weird characters that a user might
> have in the names of parent directories. Absolute paths also didn't
> play well with lilypond on Windows (see
> http://code.google.com/p/lilypond/issues/detail?id=2209 ). While I
> didn't test the suggested patch on Windows yet, I will do so very
> soon.
>
> Regards,
> Julien
>
>> http://codereview.appspot.com/5846075/

So after some testing, this looks good with python on windows, too.

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

Re: Corrected style of comments (issue 5862052)

[julien . rioux]

Are the changes to .gitignore intentional?

http://codereview.appspot.com/5862052/

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

Re: A new home for browser-language (issue 2412). (issue 5870043)

[Julien Rioux]

On Wed, Mar 21, 2012 at 4:42 PM, Julien Rioux  wrote:
> On Wed, Mar 21, 2012 at 4:33 PM,   wrote:
>>
>> http://codereview.appspot.com/5870043/diff/1/python/auxiliar/postprocess_html.py
>> File python/auxiliar/postprocess_html.py (right):
>>
>> http://codereview.appspot.com/5870043/diff/1/python/auxiliar/postprocess_html.py#newcode71
>> python/auxiliar/postprocess_html.py:71: browser_language_url =
>> "/misc/browser-language"
>> please change to /website/misc/browser-language.  I'm not 100% certain
>> it's safe to have a /misc/ so let's avoid that potential problem for
>> now.
>>
>> http://codereview.appspot.com/5870043/
>
> Sure I'll change it. Does this also apply to the other patch on countdown i.e.
> http://codereview.appspot.com/5843069/diff/17/Documentation/common-macros.itexi

Done. I'm running patch-new patchy on this.
Julien

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

Re: Tracks old announcements, news and changelogs. (issue 5843069)

[Julien Rioux]

On Wed, Mar 21, 2012 at 5:16 PM,   wrote:
>
> http://codereview.appspot.com/5843069/diff/17/Documentation/common-macros.itexi
> File Documentation/common-macros.itexi (right):
>
> http://codereview.appspot.com/5843069/diff/17/Documentation/common-macros.itexi#newcode185
> Documentation/common-macros.itexi:185:
> @uref{http://www.lilypond.org/misc/\MISC-FILE\,\MISC-TEXT\}
> sorry, please change this to http://www.lilypond.org/website/misc/
>
> http://codereview.appspot.com/5843069/

Done. I'm running patch-new patchy on this.
Julien

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

Re: A new home for browser-language (issue 2412). (issue 5870043)

[Julien Rioux]

On Wed, Mar 21, 2012 at 4:33 PM,   wrote:
>
> http://codereview.appspot.com/5870043/diff/1/python/auxiliar/postprocess_html.py
> File python/auxiliar/postprocess_html.py (right):
>
> http://codereview.appspot.com/5870043/diff/1/python/auxiliar/postprocess_html.py#newcode71
> python/auxiliar/postprocess_html.py:71: browser_language_url =
> "/misc/browser-language"
> please change to /website/misc/browser-language.  I'm not 100% certain
> it's safe to have a /misc/ so let's avoid that potential problem for
> now.
>
> http://codereview.appspot.com/5870043/

Sure I'll change it. Does this also apply to the other patch on countdown i.e.
http://codereview.appspot.com/5843069/diff/17/Documentation/common-macros.itexi

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

Re: lilypond-book: Set include path for --output option (issue 2423). (issue 5846075)

[Julien Rioux]

On Wed, Mar 21, 2012 at 1:39 AM,   wrote:
>
> http://codereview.appspot.com/5846075/diff/1/scripts/lilypond-book.py
> File scripts/lilypond-book.py (right):
>
> http://codereview.appspot.com/5846075/diff/1/scripts/lilypond-book.py#newcode639
> scripts/lilypond-book.py:639: global_options.include_path.insert (0,
> inverse_relpath (original_dir, global_options.output_dir))
> Wouldn't it be easier if you just added the absolute path to
> original_dir?
>

It would be easier, but I think the proposed patch is a better
implementation. Using absolute paths makes the document less portable
and prone to errors caused by any weird characters that a user might
have in the names of parent directories. Absolute paths also didn't
play well with lilypond on Windows (see
http://code.google.com/p/lilypond/issues/detail?id=2209 ). While I
didn't test the suggested patch on Windows yet, I will do so very
soon.

Regards,
Julien

> http://codereview.appspot.com/5846075/

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

Re: volunteer for patchy new-patches

[Julien Rioux]

On 20/03/2012 4:26 PM, Marek Klein wrote:

Hi,

2012/3/16 Graham Percival


On Fri, Mar 16, 2012 at 09:52:52PM +0100, Marek Klein wrote:


I can do it, I think (almost every day).


Great!  Here's the link to get started:
http://lilypond.org/doc/v2.15/Documentation/contributor/patchy

... although apparently that doesn't include a link to the actual
code.  huh.
https://github.com/gperciva/lilypond-extra

- Graham



what are the next steps? Should I try to run python
lilypond-patchy-staging.py ?

Marek



python test-patches.py

--
Julien


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

Re: Tracks old announcements, news and changelogs. (issue 5843069)

[Julien Rioux]

On Tue, Mar 20, 2012 at 2:07 PM,   wrote:
> LGTM
>
> http://codereview.appspot.com/5843069/

Thanks for having a look. By the way, it looks like
http://lilypond.org/website just replicates http://lilypong.org at a
deeper level -- any reason why this is so? Is that from before the
switch to the new website?

Julien

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

Re: What's with the build directories?

[Julien Rioux]

Graham Percival  percival-music.ca> writes:
> On Mon, Mar 19, 2012 at 01:24:54PM +0100, David Kastrup wrote:
> > I find that in my patchy runs, I get directories
> > /tmp/lilypond-autobuild (my configured build directory)
> > and a hierarchy of "build" directories under it, possibly one per tested
> > patch (?).
> 
> nope, nothing to do with Patchy.
> 
> > ls /tmp/lilypond-autobuild/build/build/build/build/
> > GNUmakefile  local.make
> 
> That's normal.  People were asking why we have nested build dirs
> at least two years ago.  *shrug*  Patches appreciated?  I'm not
> eager to poke the build system with a sharp stick.

So I did a quick search but I'm probably not touching it either.

Lines 421, 422 of stepmake/aclocal.m4:
for mf in `cd $srcdir ; find . -maxdepth $d -mindepth $d -name GNUmakefile`; do
mkdir -p $(dirname $mf)

recursively search for files named GNUmakefile and create a corresponding
directory in the build dir. The build dir itself contains a GNUmakefile. This
happens at each configure run (which Patchy happens to do at every patch).

Regards,
Julien


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

Re: Sets lilypond-id message to type progress (issue 5848056)

[Julien Rioux]

On Sun, Mar 18, 2012 at 1:49 PM,   wrote:
>
> http://codereview.appspot.com/5848056/diff/1/scripts/lilypond-book.py
> File scripts/lilypond-book.py (right):
>
> http://codereview.appspot.com/5848056/diff/1/scripts/lilypond-book.py#newcode104
> scripts/lilypond-book.py:104: progress(_ ('%s (GNU LilyPond) %s' %
> (ly.program_name, ly.program_version)))

We don't need the _ (), we don't translate that string.
Julien

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

Re: Hiding old website /web/install page (issue 5500069)

[julien . rioux]

this rietveld issue can be closed.

http://codereview.appspot.com/5500069/

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

Re: Copy pdf docs to new website folder (issue 5507046)

[julien . rioux]

On 2012/01/03 20:36:48, Graham Percival wrote:

On Tue, Jan 03, 2012 at 06:31:54PM +, mailto:hashas...@gmail.com

wrote:

> Sorry, didn't understand what you mean by "add issue 2166 to track

this"


It's not relevant unless you're going to be making other patches.
If you are, read the "summary for experienced developers" again in
more detail.  The git-cl step wasn't done properly.



> Anything I can do to help this to get live?



Wait a day or two.  It's on the countdown right now.  See the
summary for experienced developers if you don't know what that
means.



Cheers,
- Graham


This rietveld issue can be closed.

http://codereview.appspot.com/5507046/

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

Re: FW: [LilyPond] Your organization application has been rejected.

[Julien Rioux]

On 16/03/2012 5:16 PM, Julien Rioux wrote:

There are a few organisations interesting for lilypond hackers:
inkscape (to learn about svg), closure (to learn a scheme-like
language), buildbot (could be helpful but we already have the gran
unified builder).



libreoffice (improve the lilypond plugin), wikimedia (lilypond plugin again)

--
Julien


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

Re: volunteer for patchy new-patches

[Julien Rioux]

On 16/03/2012 4:55 PM, Graham Percival wrote:

On Fri, Mar 16, 2012 at 09:52:52PM +0100, Marek Klein wrote:


I can do it, I think (almost every day).


Great!  Here's the link to get started:
http://lilypond.org/doc/v2.15/Documentation/contributor/patchy

... although apparently that doesn't include a link to the actual
code.  huh.
https://github.com/gperciva/lilypond-extra

- Graham


No?
http://lilypond.org/doc/v2.15/Documentation/contributor/patchy#Installing-patchy

--
Julien


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

Re: FW: [LilyPond] Your organization application has been rejected.

[Julien Rioux]

On 16/03/2012 4:45 PM, Janek Warchoł wrote:

On Fri, Mar 16, 2012 at 6:53 PM, Carl Sorensen  wrote:

On 3/16/12 11:44 AM, "no-re...@google-melange.appspotmail.com"
  wrote:


Thank you for submitting "LilyPond" organization application to Google
Summer of Code 2012.
Unfortunately, we were unable to accept your organization's application
at this time.
We received many more applications for the program than we are able to
accommodate,
and we would encourage you to reapply for future instances of the program.
Best regards,
  Google Open Source Programs


As you can see, we did not qualify for GSOC this year.


No!!
:( :( :(
That's all they wrote?  No feedback on our application anywhere?


There should be a possibility to email/chat with them about the 
application process and how they come to this decision. This would be 
the best indication for next year.


--
Julien


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