GOP meta: pause in new proposals

2011-09-24 Thread Graham Percival
Hi all,

We've been passing proposals faster than we can implement them.
That's particularly a shame because there's a *huge* amount of
friction and unpleasantness that can be avoided by spending a few
hours on implementing a number of those proposals.

We will continue with the existing proposals, but I won't
introduce any new ones for the next 2 weeks, possibly longer.
I want to make a serious dent in the pain of our development
process.


Given the current amount of interest in pain removal work, I'm
forecasting that GOP will continue until April 2012 or so, and
thus GLISS won't begin until Summer 2012.

Cheers,
- Graham

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


GOP-PROP 13: patch management tools (probable withdraw)

2011-09-24 Thread Graham Percival
I don't see this proposal (really more of a set of musings)
going anywhere.  There's been a bunch of ideas:
  - tool X, tool Y
  - make better use of our current tools
  - do a survey of what other projects do
but nothing has made a significant amount of people go yeah, that
the right direction to move in!.

We're not getting closer to any kind of decision, and what's
worse, we're not even getting closer to figuring out how we would
make any kind of decision.


So I propose that we shelve this discussion.  If somebody feels
motivated and makes a detailed report about the benefits and
disadvantages of up various other tools, great; if somebody feels
motivated and makes a serious investigation of our *current* tools
(what capabilities are we missing, makes feature requests or bug
reports to the google overlords, etc), great!

If somebody is feeling optimistic about the discussion and thinks
I'm totally off-base on this, we can talk about that... but I'm
thinking that it needs some serious thought and energy, and at the
moment I think I should be putting my energy towards removing pain
points in our development for which we've already agreed on what
to do.

Cheers,
- Graham

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


Fix 1477: Add (ly:expect-warning msg args) to suppress expected warnings (issue 5037046)

2011-09-24 Thread pkx166h

Passes make and reg tests look ok but I guess someone who really knows
should check

See:

http://lilypond-stuff.1065243.n5.nabble.com/http-code-google-com-p-lilypond-issues-detail-id-1477-td4835846.html

This has a zipped dir of the make check results.

http://codereview.appspot.com/5037046/

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


Re: GOP-PROP 13: patch management tools (probable withdraw)

2011-09-24 Thread Peekay Ex
Hello,

On Sat, Sep 24, 2011 at 8:01 AM, Graham Percival
gra...@percival-music.ca wrote:
 I don't see this proposal (really more of a set of musings)
 going anywhere.  There's been a bunch of ideas:
  - tool X, tool Y
  - make better use of our current tools
  - do a survey of what other projects do
 but nothing has made a significant amount of people go yeah, that
 the right direction to move in!.

 We're not getting closer to any kind of decision, and what's
 worse, we're not even getting closer to figuring out how we would
 make any kind of decision.


 So I propose that we shelve this discussion.  If somebody feels
 motivated and makes a detailed report about the benefits and
 disadvantages of up various other tools, great; if somebody feels
 motivated and makes a serious investigation of our *current* tools
 (what capabilities are we missing, makes feature requests or bug
 reports to the google overlords, etc), great!

 If somebody is feeling optimistic about the discussion and thinks
 I'm totally off-base on this, we can talk about that... but I'm
 thinking that it needs some serious thought and energy, and at the
 moment I think I should be putting my energy towards removing pain
 points in our development for which we've already agreed on what
 to do.

Speaking for myself and (I think) people like Colin, Phil and Dymtryo
the biggest headache for bug-squadders and patch-testers is simply the
easy correlation between Rietveld and Google code. I know we've
already stated that. If this discussion has only done one thing it has
highlighted the extra work that this takes and the potential for
existing patches to wait and wait.

There seems to be four basic cases of how 'stuff' gets created in this regard.

1. Email from person (I'd like LP to do this, or LP breaks when you do X)
2. Rietveld issue with no tracker
3. Tracker issue with no Rietveld (usually RFEs or Devs/experienced
users who spot a bug)
4. Rietveld and Tracker are created at the same time

Could I therefore suggest two things?

1 Devs who put up a Rietveld put up a tracker too and use the *exact*
same title (even if it is very cryptic) the description can be simply
the link to the Rietveld URL.

if you can also cut;/paste the Rietveld comment into the tracker great
but it is not essential. Then leave all the other stuff (labels,
owners, tags etc) to the bug squadders or people like myself as I
think that might be what is putting people off using the tracker (what
label should it be? am I going to cause a lot of huffing and puffing I
use Type-Ugly when it is Type-Script and is it Patch-New or
Patch-review? and so on.

or

2. Devs who put up Rietvelds just add something in the comment like
'this needs a tracker item', or 'no tracker item for this yet' as I
realise that getting code up for initial review is more important than
the 'admin/paperwork' in many respects, but at least that line gives
us a chance, then when we see this we can add the tracker.

is that acceptable or am I flogging the proverbial dead horse :)


-- 
--
James

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


Re: PATCH: Countdown to 20110925

2011-09-24 Thread m...@apollinemike.com

On Sep 24, 2011, at 4:27 AM, Graham Percival wrote:

 On Fri, Sep 23, 2011 at 09:43:01PM -0400, Colin Campbell wrote:
 Instead, we present a special, one time only,  batch as
 requested by Mike Solomon. 
 
 Am I correct that these have not been checked by James?  I don't
 think we should call this a countdown.  By all means suggest
 that people review patches, but if they patch hasn't reached
 patch-review under the normal procedures, I don't think it should
 be called a countdown.
 

Then they should not be put on a countdown - I'm not sure which patches of mine 
will be review-ready by the time Colin sends out his weekly e-mail.  I ask him 
to please put all of these on the countdown, and it is up to him which ones to 
put on the countdown or not.  I am not sure what the normal procedures are, but 
I'm positive he is, and he makes the decision accordingly (see below).

 oh, and Mike: please stop asking for special favors for your
 patches.

I'm not sure what you mean.  I have sent Colin 7 e-mails regarding my patches.  
Here is the breakdown for every one of them:

7/21: E-mail with 5 patches. Next countdown: 1 patch.
7/25: E-mail with 3 patches. Next countdown: 3 patches.
8/5: E-mail with 5 patches: Next countdown: 0 patches.
8/9: E-mail with 4 patches.  Next countdown: 3 patches.
8/14: E-mail with 8 patches.  Next countdown: 2 patches put.
8/25: E-mail with 7 patches.  Next countdown: 2 patches put.
9/22: E-mail with 5 patches.  Next countdown: 5 patches put.

As you can see from the tallies above, whenever Colin does not want to put one 
of my patches on a countdown for whatever reason (too many other patches, not 
patch-review at the time he makes his batch, whatever) he doesn't.

The only response I've ever gotten back from him on this subject is:

-snip-
This is very helpful, Mike.  Do these patches have tracker issues or are they 
just on Rietveld?  ALso, do you use more than one ID on Rietveld?  I had a look 
last night, searching under mts...@gmail.com and saw only closed issues, but 
maybe I set the parameters wrongly? At any rate, I'll blend these into the next 
couple of patch batches.  You've certainly had a productive Summer, Mike!

Cheers,
Colin
-snip-

I would like to continue doing this, as it helps make sure that none of my 
patches fall through the cracks, it allows me to tell Colin which patches are 
the most important and which ones can wait, and I get the sense that it is 
helpful for Colin.  However, I also get the sense that from your comment above 
that you do not feel it is appropriate.  Could you elaborate further on what 
would be a better way to go about this?

 Everybody (other than me) works hard on their stuff.
 When you've made a new version of a patch, change the
 code.google.com issue to Patch-new, and then the updated patch
 will go through the system again.
 

I only do this when there are substantive changes (and when I remember to do it 
- I forget sometimes, as you point out below).  For example, if during a 
countdown someone recommends changing a regtest and I throw a patch up with the 
new regtest so that I can download the unified diff to apply to master, I don't 
check off patch new.

Anytime that I feel a change is big enough to merit going through the system 
again, I let Colin know (as you saw from this week's countdown for both the 
SpanBar and the TupletBracket patch).

 Making git-cl do this automatically will take about 30 minutes of
 python hacking.  Unfortunately, I only have 60 minutes left for
 this week, and I should reserve those for emails and fixing the
 darwin-ppc release problem that only I or Jan can fix.
 
 
   http://codereview.appspot.com/5050046/ (no issue #)
 
 http://code.google.com/p/lilypond/issues/detail?id=1921
 
   http://codereview.appspot.com/5067041/ (no issue #)
 
 http://code.google.com/p/lilypond/issues/detail?id=1922
 
   http://codereview.appspot.com/4961041/ (i imagine that it'll be pulled off
   by someone, but at least it'll get people looking at it!
 
 http://code.google.com/p/lilypond/issues/detail?id=1923
 
 
   http://codereview.appspot.com/4917046/ (i decided not to push this one
   because joe had some reservations - i think i've addressed them, but i'd
   like it to go through another countdown)
 
 Thanks for this.  The appropriate action is to change it to
 patch-new, and if James thinks it looks good, it will become
 patch-review.
 http://code.google.com/p/lilypond/issues/detail?id=1846
 
   http://codereview.appspot.com/4808082/ (it'll be this patch's 6th
   go-around! i want to throw it back up because i haven't heard any
   responses either way about the newest batch of changes)
 
 ditto.
 
 - Graham
 
 ___
 lilypond-devel mailing list
 lilypond-devel@gnu.org
 https://lists.gnu.org/mailman/listinfo/lilypond-devel

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

Re: PATCH: Countdown to 20110925

2011-09-24 Thread Graham Percival
On Sat, Sep 24, 2011 at 11:16:35AM +0200, m...@apollinemike.com wrote:
Then they should not be put on a countdown - I'm not sure which patches of
mine will be review-ready by the time Colin sends out his weekly e-mail.

It's three times a week.  There should be no rush to get stuff
added.  Just make patches, mark them patch-new, and the process
will handle them.
If the patch is good, it's pushed within 72 hours (unless there's
unusual load).  If it's not good, you'll get comments within 72
hours.

 However, I also get the sense that from your
comment above that you do not feel it is appropriate.  Could you elaborate
further on what would be a better way to go about this?

Add every patch to code.google.com with a Patch-new issue (or
adding Patch-new to an existing issue, if it's a bugfix).  Every
update to every patch should change that issue to Patch-new.

Result: no missed patches.  Every patch gets a regtest check
before it's reviewed, and every patch gets onto a countdown.

I don't like asking developers to do this manually -- hence my
fussing around with modifying git-cl to do this automatically.
But if you're concerned about patches going missing, then go
through these manual steps for a week or two until the new git-cl
has been tested some more.

Cheers,
- Graham

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


Re: PATCH: Countdown to 20110925

2011-09-24 Thread m...@apollinemike.com
On Sep 24, 2011, at 11:39 AM, Graham Percival wrote:

 On Sat, Sep 24, 2011 at 11:16:35AM +0200, m...@apollinemike.com wrote:
   Then they should not be put on a countdown - I'm not sure which patches of
   mine will be review-ready by the time Colin sends out his weekly e-mail.
 
 It's three times a week.  There should be no rush to get stuff
 added.  Just make patches, mark them patch-new, and the process
 will handle them.

Sorry - I don't know why I said weekly!

 If the patch is good, it's pushed within 72 hours (unless there's
 unusual load).  If it's not good, you'll get comments within 72
 hours.
 
 However, I also get the sense that from your
   comment above that you do not feel it is appropriate.  Could you elaborate
   further on what would be a better way to go about this?
 
 Add every patch to code.google.com with a Patch-new issue (or
 adding Patch-new to an existing issue, if it's a bugfix).  Every
 update to every patch should change that issue to Patch-new.
 
 Result: no missed patches.  Every patch gets a regtest check
 before it's reviewed, and every patch gets onto a countdown.
 
 I don't like asking developers to do this manually -- hence my
 fussing around with modifying git-cl to do this automatically.
 But if you're concerned about patches going missing, then go
 through these manual steps for a week or two until the new git-cl
 has been tested some more.
 

That's great!  I didn't follow that you were doing that (I don't read all the 
stuff on devel), but that will help a lot.

What would be useful in git-cl is a way to signal to the PatchMeister the 
developer's perceived importance of a patch.  If I have 8 patches waiting to 
get pushed, I generally have a sense of which ones I'd like to get into a 
countdown sooner rather than later.  Sometimes, this is obvious (i.e. if it 
fixes a Critical Issue).  But sometimes this is less obvious (i.e. it is needed 
so that I can work on something else), in which case it'd be great if I could 
communicate this through git-cl.  That way, if Colin is deciding between a 
batch of patches and there's a coin-flip between two patches from one 
developer, he'll have the developer's notes at his disposal to make the 
decision.

Cheers,
MS


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


Re: FiguredBass: Rewrite of the engraver to fix vertical position (issue 224052)

2011-09-24 Thread percival . music . ca

any chance of rebasing this patch?

http://codereview.appspot.com/224052/

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


Re: PATCH: Countdown to 20110925

2011-09-24 Thread Graham Percival
On Sat, Sep 24, 2011 at 11:49:44AM +0200, m...@apollinemike.com wrote:
 What would be useful in git-cl is a way to signal to the
 PatchMeister the developer's perceived importance of a patch.

Current thinking is to automatically randomly pick 10 patch-review
for the countdown, with priority for Critical.  I think we're
looking at an average of about 10 patches per week so far in Sep,
so that gives us a 200% overhead for sudden surges.

That said, I've just discovered a ton of old updated patches that
got lost, so it'll take a week or two to clear out that backlog.

Cheers,
- Graham

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


archeological patch digging

2011-09-24 Thread Graham Percival
I've just discovered about 10 patches that had new versions, but
hadn't been updated with Patch-new, so James wasn't checking them,
so they weren't getting to Patch-review, so they were never
getting onto a countdown.

I got bored before I finished going throught the entire list, and
I didn't look at any of the patch-abandoned stuff.  Does anybody
feel like doing this?

For each patch,
- if there's a newer version since the last set of complaints,
  make it patch-new
- if there's existing complaints and it's been over a month since
  any action, send PRIVATE email to the owner asking if it's
  abandoned.  I say private because public emails are often
  ignored.
  If you hear back from the owner that they've definitely given
  up, make it patch-abandoned.  If they say they're still working
  on it, just make a little comment to that effect so we know
  what's up.

Cheers,
- Graham

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


Re: Glyphs for Kievan Notation (issue 4951062)

2011-09-24 Thread Phil Holmes
- Original Message - 
From: aleksandr.andr...@gmail.com
To: percival.music...@gmail.com; janek.lilyp...@gmail.com; 
pkx1...@gmail.com; carl.d.soren...@gmail.com; lemzw...@googlemail.com; 
reinhold.kainho...@gmail.com; w...@gnu.org; n.putt...@gmail.com; 
gra...@percival-music.ca; m...@apollinemike.com

Cc: re...@codereview.appspotmail.com; lilypond-devel@gnu.org
Sent: Friday, September 23, 2011 9:00 PM
Subject: Re: Glyphs for Kievan Notation (issue 4951062)



make doc problem solved on my system. I can confirm that make and make
doc run successfully with this patch.



What did you do to get make doc going?

--
Phil Holmes



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


Re: musicxml2ly: title and subtitle (issue 1913), miscellaneous (issue 5096050)

2011-09-24 Thread ptrcklschmdt

On 2011/09/23 15:36:15, p-l-s wrote:

Hi Reinhold and Janek,



I hope I got it right this time. I didn't include the bit about

miscellaneous.

This will be part of a seperate patch.



BTW: I noticed that the midi-block is not always inserted in every .ly

file

(this is not related to my patch). I will do some testing...



Thanks for your help!
patrick


I just discovered that I forgot to add the changes related to
conversion-info and \center-column. Do I have to make a completely new
patch containing all 3 files (musicxml2ly.py, musicxml.py and
musicexp.py) or is it ok to upload only the files with these changes
(i.e. musicexp.py and musicxml2ly.py)?

http://codereview.appspot.com/5096050/

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


Re: Text hyphenation

2011-09-24 Thread Bertrand Bordage
2011/9/23 Janek Warchoł janek.lilyp...@gmail.com

 Hi Bertrand,

 2011/9/23 Bertrand Bordage bordage.bertr...@gmail.com:
  * making a system that allows to specify where a word is breakable (like
 \-
  in LaTeX);

 I vote for this because it seems most multi-language friendly.  I.e.,
 implementing hyphenation rules for all major languages (i'm interested
 at least in english, polish and latin) seems a big pain (or are free
 libraries about it avaiable?).


Thanks, Janek!

I worked on this yesterday. I chose '--' instead of '\-'. The result is
great (see attached).
I need to solve a few bugs before putting the patch on codereview.

Bertrand


hyphenation.pdf
Description: Adobe PDF document
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel


Re: New alist to replace special characters. (issue 4553056)

2011-09-24 Thread bordage . bertrand

Pushed as 688f5f1711d8ca07338385a2ae0191b1a8aae315.

http://codereview.appspot.com/4553056/

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


Re: Text hyphenation

2011-09-24 Thread Peekay Ex
Hello,

2011/9/24 Bertrand Bordage bordage.bertr...@gmail.com:
 2011/9/23 Janek Warchoł janek.lilyp...@gmail.com

 Hi Bertrand,

 2011/9/23 Bertrand Bordage bordage.bertr...@gmail.com:
  * making a system that allows to specify where a word is breakable (like
  \-
  in LaTeX);

 I vote for this because it seems most multi-language friendly.  I.e.,
 implementing hyphenation rules for all major languages (i'm interested
 at least in english, polish and latin) seems a big pain (or are free
 libraries about it avaiable?).

 Thanks, Janek!
 I worked on this yesterday. I chose '--' instead of '\-'. The result is
 great (see attached).

Hmm... breaking a 4 letter word into two over two lines?

:)

The typesetter in me cringes slightly.

-- 
--
James

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


Re: Text hyphenation

2011-09-24 Thread Trevor Daniels


Peekay wrote Saturday, September 24, 2011 12:22 PM


2011/9/24 Bertrand Bordage bordage.bertr...@gmail.com:

I worked on this yesterday. I chose '--' instead of '\-'. The 
result is

great (see attached).


Hmm... breaking a 4 letter word into two over two lines?


Splitting père is even worse - that's not even two syllables,
so it really destroys readability.  Splits should only be placed
between syllables, but maybe this was just a demonstration.

Trevor



-
No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1410 / Virus Database: 1520/3915 - Release Date: 09/23/11


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


Re: Text hyphenation

2011-09-24 Thread Bertrand Bordage
2011/9/24 Peekay Ex pkx1...@gmail.com

 Hmm... breaking a 4 letter word into two over two lines?
 The typesetter in me cringes slightly.


Indeed, global rules would be great for absent-minded people like me...

@Trevor : Yes, this was only a manual demonstration.

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


Re: Glyphs for Kievan Notation (issue 4951062)

2011-09-24 Thread Aleksandr Andreev
 What did you do to get make doc going?

I nuked my entire lilypond-git directory, reinstalled the source and
ran make and make doc.

Then, I ran the Kievan patch and recompiled.

A

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


Re: Glyphs for Kievan Notation (issue 4951062)

2011-09-24 Thread Aleksandr Andreev
 This is a great work, but it doesn't fit correctly into LilyPond:

OK, I will merge with Parmesan and work on the Scheme stuff.

 I also agree with Werner, there's also a lot of cleanup to do inside
 your MetaFont stuff.

I'm  new to MetaFont, so right now I'm using it like a GUI-less
outline font editor. I know that's probably the wrong approach.

A

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


Does lilypond 2.15.x support guile 2.0 yet?

2011-09-24 Thread Dave Plater
If all else fails maybe I can use the release candidate of lilypond for openSUSE 12.1 and update to 2.16.0 before release. If it supports 
guile 2.0 then I'm wasting precious time on 2.14.2.
They wanted to drop lilypond as 2.12.3 has failed for 123 days in factory due to guile 2.0 and my absence for one and a half months due to 
unfortunate circumstances.


Thanks
Dave Plater

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


What is -dold-relative and why do we need it?

2011-09-24 Thread David Kastrup

In program-option-scheme.cc we have

  else if (var == ly_symbol2scm (old-relative))
{
  lily_1_8_relative = to_boolean (val);
  /* Needs to be reset for each file that uses this option. */
  lily_1_8_compatibility_used = to_boolean (val);
  val = scm_from_bool (to_boolean (val));
}

and it is queried in quite a few places.  Lilypond 1.8 seems like a
rather old version to support.

Do we really need to have this around?  Anybody even knows what it does?

-- 
David Kastrup


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


Re: Moving away from make

2011-09-24 Thread olafBuddenhagen
Hi,

On Fri, Aug 12, 2011 at 02:53:56PM +0100, Phil Holmes wrote:

 I understand it's been discussed before, but I am wondering whether
 it's worth thinking the unthinkable and considering moving away from
 make.  I know it's been used in loads of projects and is much loved,
 but actually, from a design perspective, it's appalling.

I don't understand why so many people think it is... The Make language
as it stands does have some quirks, but I like the fundamental concept.

But of course that's mostly irrelevant anyways when using a Makefile
generator such as Autotools...

 If I was writing a make system from scratch, I would describe
 dependencies in data structures that are viewable and editable, and
 have a separate program that uses those structures to determine which
 files need making.

I'm not sure why you need extra structures for that? For C/C++, gcc can
figure out the dependencies as a side effect of compiling the normal
source code; and this can be done for most other languages as well. Very
few non-trivial programs actually maintain their dependencies by hand
nowadays...

 I've done 5 minutes research and have found SCons.  I've not gone into
 any more depth with that yet.  Does it seem worth looking into this,
 or something else, in more detail?

I don't know about SCons, but at least the often-proposed Cmake is *not*
a Make replacement. It's a Makefile generator, just like Autotools.

Also please consider that the build system is not used only by
developers, but also by distribution packagers, and anyone else building
the software. Projects using Autotools are still by far the most
convenient; anything else means extra effort.

-antrik-

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


Re: Need help with openSUSE:Factory build failure in lilypond

2011-09-24 Thread Dave Plater

On 09/24/2011 12:37 AM, Reinhold Kainhofer wrote:

The problem with guile 2.0 is that it includes many major changes (compiled
code, new macro handling, new garbage collection, completely new
string/unicode handling, etc.), which also require major code changes and
restructuring. Lilypond, however, has not been tested AT ALL with the new
version yet. Currently, Ian is trying to make lilypond compile and make the
basics work with guile 2.0.

Guile is not just some additional extension package that lilypond uses, where
an update should be mostly painless. Lilyond uses Guile at its very core, and
large parts of lilypond are implemented in guile, so an update to guile 2.0
means replacing the very core of lilypond.

I don't think you want to play the guinea pig for such a guile 2.0 switch.

That's like switching to a completely untested, unstable kernel version
shortly before a distribution release.

Cheers,
Reinhold
My problem is that at the moment I'm one man alone trying to find a solution to this problem and still keep up with maintaining multimedia 
libs and apps along with a few others as an unpaid openSUSE community member.
I've started on a guile 1.88 package called guile1 but although --program-suffix=1 appends a one to the executables and I can just rename 
the pkg-config file, delete guile-config, rename the info pages and install the libs in $libdir/name there appears to be a lot more to do 
to produce a parallel installable guile1 package. Lilypond will also have to be patched to use it. I could use a bit of help, I'm not as 
familiar with autoconf and friends as I am with cmake and scons, I have difficulty with large packages such as lilypond and guile, I've 
only worked with simple library packages. It seems, from googling guile, the rpm based distributions are behind with their guile updates 
and the patches applied to the handful of openSUSE packages are very simple, gnucash for instance only seems to have a couple of lines in 
it's patch. The thing that surprises me the most is that guile 2 isn't backward compatible with guile 1, at least python 3 suffixes 
everything with a 3 and they have tools and information for porting from 2 to 3 guile doesn't seem to have any info about porting, not even 
in the list messages.


Thanks
Dave

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


Re: Big web page

2011-09-24 Thread Phil Holmes
- Original Message - 
From: Graham Percival gra...@percival-music.ca

To: Phil Holmes em...@philholmes.net
Cc: Devel lilypond-devel@gnu.org
Sent: Friday, September 23, 2011 7:54 PM
Subject: Re: Big web page



On Fri, Sep 23, 2011 at 05:03:21PM +0100, Phil Holmes wrote:

You know, I'm wondering if this serves any purpose.  It's a
humungous thing that takes an age to load and display, and for a
long time has had a load of missing images, bad links, etc.  No-one
complained much and no-one really seemed to notice.  Yet we lose the
images on web-examples and get a user report same day.

Given the shenanigans needed to create it, might it make sense to retire 
it?


When the new website was first being built, there was a huge
outcry when I suggested not bothering with it.

I'd rather keep it around, at least for a bit longer, because it
serves as a canary.  Is the doc build system as generic as we
need?  no.  (note that there's a few pictures in other manuals;
it's not just web-big-html that needs them)   Is the doc build
system as well-organized as we need?  of course not.


I think we can do a huge amount of work just by cleaning up the
make website process.  Admittedly that doesn't include
web-big-html, but the increased understanding and simplifications
should have follow-on effects to make doc.

Cheers,
- Graham



I thought I'd start with a rather easier to follow description of how make 
website works.  It's attached as a text file with no formatting as yet, for 
quick thoughts.  If wanted I could put it on Rietveld as is, or if it's 
close enough to being useful, I could texify it first.


--
Phil Holmes


The Story of make website

The rule for make website is found in GNUmakefile.in:

website:
$(MAKE) config_make=$(config_make) \
top-src-dir=$(top-src-dir) \
-f $(top-src-dir)/make/website.make \
website

This translates as:

make --no-builtin-rules config_make=./config.make \
top-src-dir=/home/phil/lilypond-git \
-f /home/phil/lilypond-git/make/website.make \
website

which has the effect of setting the variables config_make and top-src-dir and 
then processing the file git/make/website.make with the target of website.

website.make starts with the following:

ifeq ($(WEBSITE_ONLY_BUILD),1)

which checks to see whether the variable WEBSITE_ONLY_BUILD was set to one on 
the command line.  This is only done for standalone website builds, not in the 
normal case.  The result of the test determines the value of some variables 
that are set.  A number of other variables are set, in order to establish 
locations of various files.  An example is:

CREATE_VERSION=python $(script-dir)/create-version-itexi.py

The rule for website is:

website: website-texinfo website-css website-pictures website-examples web-post
cp $(SERVER_FILES)/favicon.ico $(OUT)/website
cp $(SERVER_FILES)/robots.txt $(OUT)/website
cp $(top-htaccess) $(OUT)/.htaccess
cp $(dir-htaccess) $(OUT)/website/.htaccess

so we see that this starts by running the rules for 5 other targets, then 
finishes by copying some files.  We'll cover that later - first 
website-texinfo.  That rule is:

website-texinfo: website-version website-xrefs website-bibs
for l in '' $(WEB_LANGS); do \
if test -n $$l; then \
langopt=--lang=$$l; \
langsuf=.$$l; \
fi; \
$(TEXI2HTML) --prefix=index \
--split=section \
--I=$(top-src-dir)/Documentation/$$l \
--I=$(top-src-dir)/Documentation \
--I=$(OUT) \
$$langopt \
--init-file=$(texi2html-init-file) \
-D web_version \
--output=$(OUT)/$$l \
$(top-src-dir)/Documentation/$$l/web.texi ; \
ls $(OUT)/$$l/*.html | xargs grep -L 'UNTRANSLATED NODE: IGNORE ME' | sed 
's!$(OUT)/'$$l'/!!g' | xargs $(MASS_LINK) --prepend-suffix=$$langsuf hard 
$(OUT)/$$l/ $(OUT)/website/ ; \
done

which therefore depends on website-version, website-xrefs  website-bibs.

website-version:
mkdir -p $(OUT)
$(CREATE_VERSION) $(top-src-dir)  $(OUT)/version.itexi
$(CREATE_WEBLINKS) $(top-src-dir)  $(OUT)/weblinks.itexi

which translates as:

mkdir -p out-website
python /home/phil/lilypond-git/scripts/build/create-version-itexi.py 
/home/phil/lilypond-git  out-website/version.itexi
python /home/phil/lilypond-git/scripts/build/create-weblinks-itexi.py 
/home/phil/lilypond-git  out-website/weblinks.itexi

So, we make out-website then send the output of create-version-itexi.py to out-website/version.itexi and create-weblinks-itexi.py to out-website/weblinks.itexi.  


create-version-itexi.py parses the file VERSION in the top source dir.  It 
contains:


Re: Creates convert-ly rules for flag syntax changes (issue 5050046)

2011-09-24 Thread pkx166h

Passes make and reg tests

http://codereview.appspot.com/5050046/

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


Re: Adds StemTremolo to the note column's element list. (issue 5067041)

2011-09-24 Thread pkx166h

passes make, get some reg tests show up but nothing of note.

See attached on

http://code.google.com/p/lilypond/issues/detail?id=1922#c1

http://codereview.appspot.com/5067041/

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


Re: Prevents nested tuplets from colliding. (issue 4808082)

2011-09-24 Thread pkx166h

Passes make and reg tests show as before see:

http://code.google.com/p/lilypond/issues/detail?id=1855#c9

James

http://codereview.appspot.com/4808082/

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


Re: Improves horizontal spacing of axis groups that SpanBar grobs traverse. (issue 4917046)

2011-09-24 Thread pkx166h

Passes make, reg tests that get spewed out look identical, too many to
attach but they are zipped here

http://lilypond-stuff.1065243.n5.nabble.com/http-code-google-com-p-lilypond-issues-detail-id-1846-td4837220.html

http://codereview.appspot.com/4917046/

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


Re: musicxml2ly: title and subtitle (issue 1913), miscellaneous (issue 5096050)

2011-09-24 Thread pkx166h

passes make and reg tests

http://codereview.appspot.com/5096050/

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


Re: T1780 remove scheme format calls with no destination parameter - deprecated in Guile V2 (issue 4974078)

2011-09-24 Thread pkx166h

This patch no longer applies to current tree (as of 24th Sept)

http://codereview.appspot.com/4974078/

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


Re: lily/bezier.cc: Avoid a floating point compare (issue 5121042)

2011-09-24 Thread pkx166h

passes make and reg tests

http://codereview.appspot.com/5121042/

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


Re: Sketch for broken beams with consistent slopes (issue 4961041)

2011-09-24 Thread pkx166h

Passes make but there are a few reg tests that someone should look at

See

http://code.google.com/p/lilypond/issues/detail?id=1844#c5



http://codereview.appspot.com/4961041/

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


Re: Several fixes for annotate-spacing. (issue 4950071)

2011-09-24 Thread pkx166h

Passes make and reg tests

http://codereview.appspot.com/4950071/

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


Re: Sketch for fix of issue 307 (issue 4813048)

2011-09-24 Thread pkx166h

passes make and reg tests

http://codereview.appspot.com/4813048/

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


Re: New partcombineUp and partcombineDown functions (issue 4514042)

2011-09-24 Thread pkx166h

passes make and reg tests

http://codereview.appspot.com/4514042/

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


Re: Does lilypond 2.15.x support guile 2.0 yet?

2011-09-24 Thread Graham Percival
On Fri, Sep 23, 2011 at 03:53:56PM +0200, Dave Plater wrote:
 If all else fails maybe I can use the release candidate of lilypond
 for openSUSE 12.1 and update to 2.16.0 before release.

There is absolutely zero chance of lilypond 2.16 using guile 2.0.
There is maybe a 10% chance that any version of lilypond will
support guile 2.0 in 2011.  Total guesswork for future
predictions: 50% chance of supporting guile 2.0 before July 2012,
80% chance of support guile 2.0 before the end of 2012.

What that means for opensuse is up to you.  If you particularly
want guile 2.0, then by all means jump in; the more people working
on it, the higher the chances are that it'll get done sooner.  But
based on the amount of work that currently goes into guile 2.0,
those are my estimates.

Cheers,
- Graham

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


Re: NR Context Layout Order rewrite (5.1.7) - tracker 1812 (issue 4839061)

2011-09-24 Thread pkx166h

Reviewers: Trevor Daniels,

Message:
On 2011/08/10 22:32:13, Trevor Daniels wrote:

James
My suggestion was to remove the *material* in 5.1.7 and replace it

with material

from 5.4.3, removing 5.4.3 as a section.  The reference at the end of

the

material from 5.4.3 will need to be removed.  Also, following Neil's

reminder,

we need to expand the documentation of the use of \accepts in 5.1.7

too, using

his neat example.
Trevor


I've done an initial patch and know it still needs more work but I need
some guidance and suggestions as this is something I know little about
technically


Description:
Doc: NR remove 5.1.7

Tracker issue 1812

Removed 5.1.7 as it was felt that this was already explaind in 5.1.6
the use of \accepts and \denies is now only required when
creating new contexts.

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

Affected files:
  M Documentation/notation/changing-defaults.itely



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


Re: NR Context Layout Order rewrite (5.1.7) - tracker 1812 (issue 4839061)

2011-09-24 Thread tdanielsmusic

James
Looks pretty good.  I've made a couple of suggested additions.  Could
you please make a new patch with these changes in, and then I'll give it
a more careful check over.
Trevor


http://codereview.appspot.com/4839061/diff/3001/Documentation/notation/changing-defaults.itely
File Documentation/notation/changing-defaults.itely (right):

http://codereview.appspot.com/4839061/diff/3001/Documentation/notation/changing-defaults.itely#newcode935
Documentation/notation/changing-defaults.itely:935: @cindex contexts,
layout order
@funindex \accepts
@funindex \denies

http://codereview.appspot.com/4839061/diff/3001/Documentation/notation/changing-defaults.itely#newcode954
Documentation/notation/changing-defaults.itely:954: To places chord
names on a stave e.g.,
Replace the previous two paras with:

The @qq{accepts} list of a context can be changed with the
@code{\accepts} and @code{\denies} commands.  @code{\accepts} adds a
context to the @qq{accepts} list and @code{\denies} removes a context
from the list.  For example, it would not normally be desirable for
chord names to be nested within a @{Staff} context, so the
@code{ChordNames} context is not included by default in the @qq{accepts}
list of the @code{Staff} context, but if this were to be required it can
be done:

http://codereview.appspot.com/4839061/diff/3001/Documentation/notation/changing-defaults.itely#newcode964
Documentation/notation/changing-defaults.itely:964:
Add here:

@code{\denies} is mainly used when a new context is being based on
another, but the required nesting differs.  For example, the
@code{VaticanaStaff} context is based on the @code{Staff} context, but
with the @code{VaticanaVoice} context substituted for the @code{Voice}
context in the @qq{accepts} list.

http://codereview.appspot.com/4839061/diff/3001/Documentation/notation/changing-defaults.itely#newcode967
Documentation/notation/changing-defaults.itely:967: @rprogram{An extra
staff appears}.
Add:

Installed Files:
@file{ly/engraver-init.ly}.

http://codereview.appspot.com/4839061/

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


Re: Implement define-event-function (issue 5083045)

2011-09-24 Thread dak

Pushed as 5aac8e8d8e2b1fc490354cba2cdecd204e9d5006

http://codereview.appspot.com/5083045/

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


Re: parser.yy: allow composite_music to also consist of a MUSIC_IDENTIFIER. (issue 5090045)

2011-09-24 Thread dak

Pushed as 049021415e2af3a48b1ec6d724df3d2f1d9f7dd3

http://codereview.appspot.com/5090045/

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


parser.yy et al: Make \relative a music function. (issue 5123043)

2011-09-24 Thread dak

Reviewers: ,

Message:
This is a rather straightforward patch to take \relative out of the
grammar and let it be implemented as a music function.

I have copied some code from parser.yy straight to music-scheme.cc to
make ly:make-music-relative!.  This code keeps the original indentation
so that git blame -C will recognize its origin.  If desired, the
indentation can be fixed with a separate commit instead.

I have not touched the lily_1_8_relative wart when working on this.  So
there are a few likely changes offering themselves, but it seems to be
cleaner to me if they are in a separate commit.

One surprise was that I got 18 additional shift/reduce conflicts when
removing \relative that needed to get fixed by augmenting the operator
list.

This suggests that it might be possible to introduce some artificial
terminal symbols and corresponding rules (taking the old place of
RELATIVE and more in the grammar) not actually produced by the lexer to
cut down on the number of symbols needing operator priorities.

Interesting.

Regtests pass with good visuals on my system (I think), so I am pushing
this to dev/staging.  It seems like a reasonably solid change to me, and
in good shape.  Since there will be almost no documents not going
through the new code paths, it should move to master only after a full
check including DOC builds on clean systems.

Description:
parser.yy et al: Make \relative a music function.

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

Affected files:
  M lily/lily-lexer.cc
  M lily/music-scheme.cc
  M lily/parser.yy
  M ly/music-functions-init.ly


Index: lily/lily-lexer.cc
diff --git a/lily/lily-lexer.cc b/lily/lily-lexer.cc
index  
f80ea67703010594d088202f86e12702d27879c8..6c1336744b3286f6e2f0ca21d13ad8c5d4a508ca  
100644

--- a/lily/lily-lexer.cc
+++ b/lily/lily-lexer.cc
@@ -75,7 +75,6 @@ static Keyword_ent the_key_tab[]
   {once, ONCE},
   {override, OVERRIDE},
   {paper, PAPER},
-  {relative, RELATIVE},
   {remove, REMOVE},
   {repeat, REPEAT},
   {rest, REST},
Index: lily/music-scheme.cc
diff --git a/lily/music-scheme.cc b/lily/music-scheme.cc
index  
89c810a5679df344d5ab41ee8f4f70c2b9dbfd81..34545fa911d33da5293c4c656e2342da1d4ad329  
100644

--- a/lily/music-scheme.cc
+++ b/lily/music-scheme.cc
@@ -20,6 +20,7 @@
 #include music.hh

 #include duration.hh
+#include program-option.hh
 #include warn.hh

 LY_DEFINE (ly_music_length, ly:music-length,
@@ -158,6 +159,24 @@ LY_DEFINE (ly_music_compress, ly:music-compress,
   return sc-self_scm ();
 }

+LY_DEFINE (ly_make_music_relative_x, ly:make-music-relative!,
+  2, 0, 0, (SCM music, SCM pitch),
+  Make @var{music} relative to @var{pitch},
+   return final pitch.)
+{
+  LY_ASSERT_TYPE (unsmob_music, music, 1);
+  LY_ASSERT_TYPE (unsmob_pitch, pitch, 2);
+
+   Pitch start = *unsmob_pitch (pitch);
+   Music *m = unsmob_music (music);
+   Pitch last = m-to_relative_octave (start);
+   if (lily_1_8_relative)
+   m-set_property (last-pitch, last.smobbed_copy ());
+
+   return last.smobbed_copy ();
+}
+
+
 LY_DEFINE (ly_music_duration_length, ly:music-duration-length, 1, 0, 0,
(SCM mus),
Extract the duration field from @var{mus} and return the
Index: lily/parser.yy
diff --git a/lily/parser.yy b/lily/parser.yy
index  
4714f67326d9595728c8d7fe798483a2f297a19d..b0a584ff91e93fd71465659a7d181c7321093bce  
100644

--- a/lily/parser.yy
+++ b/lily/parser.yy
@@ -62,6 +62,8 @@ or
   PITCH_IDENTIFIER NOTENAME_PITCH TONICNAME_PITCH
   SCM_FUNCTION SCM_IDENTIFIER SCM_TOKEN
   UNSIGNED DURATION_IDENTIFIER
+  CHORDMODE CHORDS DRUMMODE DRUMS FIGUREMODE FIGURES LYRICMODE LYRICS
+  NOTEMODE

  /* The above are the symbols that can start function arguments */

@@ -107,10 +109,8 @@ using namespace std;
 #include main.hh
 #include misc.hh
 #include music.hh
-#include music.hh
 #include output-def.hh
 #include paper-book.hh
-#include program-option.hh
 #include scm-hash.hh
 #include score.hh
 #include text-interface.hh
@@ -156,7 +156,6 @@ SCM get_next_unique_lyrics_context_id ();


 static Music *make_music_with_input (SCM name, Input where);
-SCM make_music_relative (Pitch start, SCM music, Input loc);
 SCM run_music_function (Lily_parser *parser, Input loc, SCM func, SCM  
args);

 SCM check_scheme_arg (Lily_parser *parser, Input loc, SCM fallback,
  SCM arg, SCM args, SCM pred);
@@ -217,7 +216,6 @@ void set_music_properties (Music *p, SCM a);
 %token ONCE \\once
 %token OVERRIDE \\override
 %token PAPER \\paper
-%token RELATIVE \\relative
 %token REMOVE \\remove
 %token REPEAT \\repeat
 %token REST \\rest
@@ -370,7 +368,6 @@ If we give names, Bison complains.
 %type scm post_event
 %type scm post_event_nofinger
 %type scm re_rhythmed_music
-%type scm relative_music
 %type scm simple_element
 %type scm simple_music_property_def
 %type scm start_symbol
@@ -385,7 +382,6 @@ If we give names, Bison complains.

 %type scm 

Re: parser.yy et al: Make \relative a music function. (issue 5123043)

2011-09-24 Thread dak

Pushed as db3e78a1d3ac62dff61e80a3f0ccf60009f535ed to /dev/staging

http://codereview.appspot.com/5123043/

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


Re: Moving away from make

2011-09-24 Thread Graham Percival
On Fri, Sep 23, 2011 at 07:08:26PM +0200, olafbuddenha...@gmx.net wrote:
 Hi,
 
 On Fri, Aug 12, 2011 at 02:53:56PM +0100, Phil Holmes wrote:
 
  I understand it's been discussed before, but I am wondering whether
  it's worth thinking the unthinkable and considering moving away from
  make.  I know it's been used in loads of projects and is much loved,
  but actually, from a design perspective, it's appalling.
 
 I don't understand why so many people think it is... The Make language
 as it stands does have some quirks, but I like the fundamental concept.

That's like saying java has some quirks, but I like the
fundamental concept of architecture-independent interpreted code
and just-in-time compilers.  There's an order of magnitude
between ease of programming in python and java.

 But of course that's mostly irrelevant anyways when using a Makefile
 generator such as Autotools...

Phil was using the term make to refer to our stepmake system,
which is on top of autotools, which (of course) is on top of
actual make(1).  Yes, this is technically incorrect, but I think
that's a relatively small nit to pick.

  If I was writing a make system from scratch, I would describe
  dependencies in data structures that are viewable and editable, and
  have a separate program that uses those structures to determine which
  files need making.
 
 I'm not sure why you need extra structures for that? For C/C++, gcc can
 figure out the dependencies as a side effect of compiling the normal
 source code; and this can be done for most other languages as well. Very
 few non-trivial programs actually maintain their dependencies by hand
 nowadays...

That's a great comfort for our lilypond texinfo documentation,
which *does* require explicit dependencies.

As far as I know, every single build system has trivially easy
support for C/C++ compilation.  That's not an issue.  The issue is
building documentation, building swig python modules (for me
personally, not lilypond), generating translations, generating
test cases and automatically showing potential problems, etc.

According to
  find . -name *.make -or -name GNUmakefile* | xargs cat | wc -l
we have 5059 lines of build-system stuff.  Actually, that's not
counting python helper scripts:
  wc scripts/build/*.py -l
4113 total

So... 9171 lines of build-system junk.  I think this meme is
appropriate:
  It's over NINE THOUSAND!!!

This didn't happen for fun and giggles.  Over the years, we've
built up hack upon hack, and ended up with this unholy mess.  Is
that purely the fault of autotools?  No.  Could it be *worse* if
we used a different build system?  Sure.  But it could also be
*better* if we used a different build system.

  I've done 5 minutes research and have found SCons.  I've not gone into
  any more depth with that yet.  Does it seem worth looking into this,
  or something else, in more detail?
 
 I don't know about SCons, but at least the often-proposed Cmake is *not*
 a Make replacement. It's a Makefile generator, just like Autotools.

Yes, but it's still a different *build system*.  Our interaction
with the build system would take the form of CMakeLists.txt files.
Would that interaction result in a more maintainable system, i.e.
one which does not have a powerlevel of OVER 9000?  Probably yes.

What's uncertain is how much work would be involved in switching
to that (or any other) build system, vs. how much better that
would make matters,

Cheers,
- Graham

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


Re: Moving away from make

2011-09-24 Thread Han-Wen Nienhuys
On Sat, Sep 24, 2011 at 10:05 PM, Graham Percival
gra...@percival-music.ca wrote:
  If I was writing a make system from scratch, I would describe
  dependencies in data structures that are viewable and editable, and
  have a separate program that uses those structures to determine which
  files need making.

 I'm not sure why you need extra structures for that? For C/C++, gcc can
 figure out the dependencies as a side effect of compiling the normal
 source code; and this can be done for most other languages as well. Very
 few non-trivial programs actually maintain their dependencies by hand
 nowadays...

 That's a great comfort for our lilypond texinfo documentation,
 which *does* require explicit dependencies.

 As far as I know, every single build system has trivially easy
 support for C/C++ compilation.  That's not an issue.  The issue is
 building documentation, building swig python modules (for me
 personally, not lilypond), generating translations, generating
 test cases and automatically showing potential problems, etc.

 According to
  find . -name *.make -or -name GNUmakefile* | xargs cat | wc -l
 we have 5059 lines of build-system stuff.  Actually, that's not
 counting python helper scripts:
  wc scripts/build/*.py -l
 4113 total

 So... 9171 lines of build-system junk.  I think this meme is
 appropriate:
  It's over NINE THOUSAND!!!

 This didn't happen for fun and giggles.  Over the years, we've
 built up hack upon hack, and ended up with this unholy mess.  Is
 that purely the fault of autotools?  No.  Could it be *worse* if
 we used a different build system?  Sure.  But it could also be
 *better* if we used a different build system.

You sound spoiled.

* The build scripts are not really part of the complexity of the build
system.  They are normal programs, they are just not intended to be
run by end users.  I assume you are not considering a rewrite of
output-distance.py in CMake's scripting language.

* You make 5000 lines of makefile sound as if it is a lot.  I think
you should look at other packages' build systems more closely.

For example, coreutils, which is 70k lines of C, and a trivial
documtentation and test process has, count'dem: 2000 lines of
Makefile.am.

This is for just linking together a bunch of bog-standard C object
files, generating an info page, and running some shell scripts as
tests.

I think 5k lines is pretty impressive for a package as complex as
LilyPond, considering that it has a bizarre documentation process,
translated docs, python bindings, fonts that are run through metapost
and fontforge, a complex regression test, and needs weird acrobatics
to find its gazilion different init files.

-- 
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen

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


Re: Moving away from make

2011-09-24 Thread Graham Percival
On Sat, Sep 24, 2011 at 10:41:05PM -0300, Han-Wen Nienhuys wrote:
 On Sat, Sep 24, 2011 at 10:05 PM, Graham Percival
 gra...@percival-music.ca wrote:
  This didn't happen for fun and giggles.  Over the years, we've
  built up hack upon hack, and ended up with this unholy mess.
 
 You sound spoiled.

Why, because I think it's not perfect?  How many discussions, how
many developer-hours, have we spend talking about build problems
on this list?  How much frustration and wasted time/goodwill have
we spent on those problems?

Despite that, I'm not advocating a move away from make; it would
take us about 200 hours to reach merely the current level of build
system-ness.  There are far more important things to work on --
but I'm not going to pretend that the status quo is great, nor do
I think it's silly to ask about switching to a different system.


I will admit there is one aspect in which I *am* spoiled, though:
I am totally spoiled by python's readable code.  I am so
accustomed to writing stuff like
cmd = compiler + ' -o ' + exe_name + src_files
or
cmd = %(compiler)s -o %(exe_name)s %(src_files) % locals()
that I find stuff like
$(CC) -o $@ $
silly.  The readability for casual contributors -- which is what
most people looking at build system stuff are -- is ridiculously
better in python than anything else.

 * The build scripts are not really part of the complexity of the
 build system.  They are normal programs, they are just not
 intended to be run by end users.  I assume you are not
 considering a rewrite of output-distance.py in CMake's scripting
 language.

True.  OTOH, there is certainly complexity in there that we don't
need -- AFAIK we don't use bib2html.pl any more; we instead ose
bib2texi.py.  So we could remove the perl file from the
GNUmakefiles, and even remove the script entirely from our source
tree.

It's stuff like that which bugs me.  Some time down the road,
somebody will be trying to fix some bug in the bibliography, and
they'll spend hours looking at bib2html and the files it produces,
before finally discovering that it's not actually used.

 * You make 5000 lines of makefile sound as if it is a lot.  I think
 you should look at other packages' build systems more closely.
 
 For example, coreutils, which is 70k lines of C, and a trivial
 documtentation and test process has, count'dem: 2000 lines of
 Makefile.am.

 This is for just linking together a bunch of bog-standard C object
 files, generating an info page, and running some shell scripts as
 tests.

Wow.  That's insane.

 I think 5k lines is pretty impressive for a package as complex as
 LilyPond, considering that it has a bizarre documentation process,
 translated docs, python bindings, fonts that are run through metapost
 and fontforge, a complex regression test, and needs weird acrobatics
 to find its gazilion different init files.

It's certainly impressive, and it could definitely be worse.
But it's not easy to maintain.  At least, it's not easy to
maintain for casual developers like me.  I'd be overjoyed if
somebody non-spoiled and non-stupid (i.e. not me) offered to step
forward and fix the known problems with the build system.

Cheers,
- Graham

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


Re: Moving away from make

2011-09-24 Thread Graham Percival
On Sun, Sep 25, 2011 at 03:12:14AM +0100, Graham Percival wrote:
 On Sat, Sep 24, 2011 at 10:41:05PM -0300, Han-Wen Nienhuys wrote:
  You sound spoiled.

On second thought, I really *am* spoiled: I don't want to even
notice the build system.  I view it in the same way I view food:
a waste of time that's unfortunately necessary for survival.


I mean, food is a pain.  You need to leave the house/university to
buy it, you need to carry it home, you need to cook (or otherwise
prepare) it, then eat it, then wash the dishes, and occasionally
empty the garbage depending on what you were preparing.

Now, with frozen lazagna the cooking+washing isn't so bad (since
you can eat it out the dish; you only need to wash one fork).  But
if you eat nothing but microwaved food, you get sick.  Trust me,
I've tried.  Life would be so much easier if/when they have some
kind of grey mush that provides all nutrients you need!


That's what I want from a build system.  I want a grey mush that
just works.  No problems, no confusion, no work required to
maintain it.  I want to spend time improving documentation or
fixing bugs in graphical output or adding new features!
Unfortunately that's not possible, so I'm hoping for the next best
thing: to have a build system which requires the least amount of
work, while still providing the most robust environment with the
least amount of confusion for developers.

Now, I suppose that since I have such hostility for build systems,
I really shouldn't be involved in discussing them -- I should
leave it up to people who enjoy dealing with their crap.
Unfortunately, just like the kitchen garbage in my shared
apartment, if I don't clean up the garbage from time to time,
nobody else does.

Cheers,
- Graham

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


Re: Improves horizontal spacing of axis groups that SpanBar grobs traverse. (issue 4917046)

2011-09-24 Thread Mike Solomon
On Sep 24, 2011, at 9:31 PM, pkx1...@gmail.com wrote:

 Passes make, reg tests that get spewed out look identical, too many to
 attach but they are zipped here
 
 http://lilypond-stuff.1065243.n5.nabble.com/http-code-google-com-p-lilypond-issues-detail-id-1846-td4837220.html
 
 http://codereview.appspot.com/4917046/

Just so you all know, the changes show up because SpanBar no longer has a 
Y-extent in this patch.

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


Re: Sketch for broken beams with consistent slopes (issue 4961041)

2011-09-24 Thread Mike Solomon
On Sep 24, 2011, at 9:57 PM, pkx1...@gmail.com wrote:

 Passes make but there are a few reg tests that someone should look at
 
 See
 
 http://code.google.com/p/lilypond/issues/detail?id=1844#c5


The only thing that I'm not sure about is beam-slope-stemlet.ly.  What do 
people think of this compared to the old version?

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


Re: Adds StemTremolo to the note column's element list. (issue 5067041)

2011-09-24 Thread k-ohara5a5a

On 2011/09/19 18:48:17, mike_apollinemike.com wrote:


What I'd really like to know is why the spring ideal and minimum

distances are

different just by virtue of its belonging to the array, but I have a

feeling the

answer lies deep in the bowels of the horizontal spacing code and I

don't have

time to get to the bottom of that in the foreseeable future.


I doubt anyone can remember this faster than you can figure it out.

Note_spacing::get_spacing() uses the horizontal skylines of the
NoteColumns to set the spring lengths.

Spacing_interface::skylines() sets these skylines using the elements...
somehow.  Probably the elements' extents are the boxes over which the
skyline is draped (or rather, shrink-wrapped since it is the skyline for
horizontal spacing).

http://codereview.appspot.com/5067041/

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