date:20111029

On Sat, Oct 29, 2011 at 08:43:20AM +0200, David Kastrup wrote:
> 
> After having my local staging up-to-date,
> I just pushed staging~1 to origin/dev/staging.

thanks, checked and pushed to master.

since the whole point of dev/staging is that it gets automatically
checked and pushed, there's no way (and no desire to implement)
select dev/staging~1 on my end.

- Graham

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

Re: dev/staging fail: illegal entry in bfrange

Graham Percival  writes:

> On Sat, Oct 29, 2011 at 08:43:20AM +0200, David Kastrup wrote:
>> 
>> After having my local staging up-to-date,
>> I just pushed staging~1 to origin/dev/staging.
>
> thanks, checked and pushed to master.

Sigh.  Again it has not been fast-forwarded, but the history has been
straightened out, dissolving my merge commit.

So much for keeping bijection intact.  We need to figure out what
happens here: I should have thought that the history was perfectly
fast-forwardable.

-- 
David Kastrup

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

Re: dev/staging fail: illegal entry in bfrange

David Kastrup  writes:

> Graham Percival  writes:
>
>> On Sat, Oct 29, 2011 at 08:43:20AM +0200, David Kastrup wrote:
>>> 
>>> After having my local staging up-to-date,
>>> I just pushed staging~1 to origin/dev/staging.
>>
>> thanks, checked and pushed to master.
>
> Sigh.  Again it has not been fast-forwarded, but the history has been
> straightened out, dissolving my merge commit.
>
> So much for keeping bijection intact.  We need to figure out what
> happens here: I should have thought that the history was perfectly
> fast-forwardable.

Maybe somebody with shell server access (is there anybody?  or a tool?)
can run git reflog on the server so that one can take a look at the
first page or so?

-- 
David Kastrup


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

Re: dev/staging fail: illegal entry in bfrange

David Kastrup  writes:

> David Kastrup  writes:
>
>> Graham Percival  writes:
>>
>>> On Sat, Oct 29, 2011 at 08:43:20AM +0200, David Kastrup wrote:
 
 After having my local staging up-to-date,
 I just pushed staging~1 to origin/dev/staging.
>>>
>>> thanks, checked and pushed to master.
>>
>> Sigh.  Again it has not been fast-forwarded, but the history has been
>> straightened out, dissolving my merge commit.
>>
>> So much for keeping bijection intact.  We need to figure out what
>> happens here: I should have thought that the history was perfectly
>> fast-forwardable.
>
> Maybe somebody with shell server access (is there anybody?  or a tool?)
> can run git reflog on the server so that one can take a look at the
> first page or so?

Anyway, for now I propose that Patchy _only_ tries straight pushes of
dev/staging to master.  No rebase of any kind.  If staging is not a
proper descendant of master, this can always be fixed manually.

Perhaps let Patchy send a mail to the list when master or staging
changed since the last attempt, and the push still fails.

-- 
David Kastrup


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

Re: dev/staging fail: illegal entry in bfrange

On Sat, Oct 29, 2011 at 09:31:16AM +0200, David Kastrup wrote:
> Sigh.  Again it has not been fast-forwarded, but the history has been
> straightened out, dissolving my merge commit.

oops, I think this is my fault.  I haven't read your last 20 or so
emails about git; I was too fixated on working out the logging
bugs in Patchy.

The merge was done with this function:
https://github.com/gperciva/lilypond-extra/blob/master/patches/compile_lilypond_test.py#L176

while the push is ideally done with this function
https://github.com/gperciva/lilypond-extra/blob/master/patches/compile_lilypond_test.py#L202
but instead I followed (the same) instructions here:
https://github.com/gperciva/lilypond-extra/blob/master/patches/compile_lilypond_test.py#L225

I'll spend 30 minutes tomorrow morning working on the git stuff,
unless somebody sends me a diff (an "unofficial diff" of just
writing "line 228 should be xyz" is also fine) and tells me that I
don't need to read that stuff as long as I copy&paste correctly.

sorry about losing track of this.

- Graham

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

Re: dev/staging fail: illegal entry in bfrange

Graham Percival  writes:

> sorry about losing track of this.

No need to apologize: _my_ computer is far too slow to be useful for
bisection, anyway.  It looks like we will have a bit of bijection
flakiness for a while until we get the staging business sorted out.

-- 
David Kastrup


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

Re: Parser error with self-defined predicate symbol-or-markup? in markup function

Reinhold Kainhofer  writes:

> Am Mittwoch, 26. Januar 2011, um 20:00:31 schrieb David Kastrup:
>> Reinhold Kainhofer  writes:
>> > I'm defining my own predicate symbol-or-markup? for the argument of a
>> > markup function.
> [...]
>> > but, as soon as I try to pass a markup, the parser complains that it
>> > expects an SCM_IDENTIFIER or SCM_TOKEN:
>> > \markup \mytest "test" \bold "f"
>> > 
>> > markup-or-symbol.ly:15:21: Fehler: syntax error, unexpected STRING,
>> > expecting SCM_IDENTIFIER or SCM_TOKEN
>> > \markup \mytest "test
>> >  " \bold "f"
>> 
>> markup? is specially detected and implemented in the parser.  It is
>> never actually called but rather used as a switch.
>> 
>> markup-or-symbol? isn't.  All predicates not recognized as markup? or
>> markup-list? expect a Scheme expression that will then be checked for
>> validity using the respective predicate.
>
> Okay, so it is currently not possible to write a markup function that takes a 
> markup or symbol (or any other scheme expression) as its argument?

Your original code should work without modification now.

-- 
David Kastrup


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

Re: Music function extension...

David Kastrup  writes:

> Valentin Villenave  writes:
>
>> On Sun, Oct 31, 2010 at 5:29 PM, David Kastrup  wrote:
>>> Perhaps I have not put myself forward reasonably clearly: the idea was
>>> not just to use a predicate in the function signature, but to let that
>>> predicate be special-cased in the parser.  The function expands to a
>>> number of tokens representing the signature constituents (that is
>>> already being done, we just need another token type), and then those
>>> signature tokens are used for interpreting the actually upcoming tokens.
>>
>> Then we'd end up breaking all backwards compatibility with the old
>>
>> \relative { c' d e }
>>
>> syntax, wouldn't we? (Since \relative would expect a pitch, not a
>> music expression.)
>
> Huh?  Why would \relative be affected?
>
>> Besides, apart from \relative and \transpose, how many actual commands
>> would require a pitch argument?
>
> I really don't understand what you are talking about.
>
> I was talking about the ability to _define_ music functions taking a
> pitch argument.  Not about changing existing commands.

So I replaced \relative and \transpose with music functions by now.  Sue
me.

-- 
David Kastrup


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

Re: lybook-db etc etc.

Han-Wen Nienhuys  writes:

> On Wed, Oct 26, 2011 at 1:13 PM, David Kastrup  wrote:
>> Well, I am currently in the process of running make info (similar to
>> make doc), and this is totally silly.
>>
>> In my opinion, the whole lybook-db stuff needs to go.  Instead, Lilypond
>> is run _once_ for all snippets of a lybook source, generating _one_
>> PostScript file.  Then GhostScript is run _once_ to generate a bunch of
>> eps files, or a multi-page PDF file with all graphics in them which get
>> referenced as needed.
>>
>> Bleedover of variables/fonts/whatever is not all that crucial since we
>> are talking about a single document source rather than an immaculate
>> database.
>
> on the contrary: the regtest is a tely document, so bleed will cause
> spurious diffs in the regtest, at least in the pixel comparison.

Bleed would be a bug in the snippets.  Global settings would likely need
to be forked out into an initialization file for the whole document.

Anyway, I am more concerned about "make doc" rather than "make test".

To put a perspective to it, I'd figure I could justify working on this
if we managed a pledge of €500 for every factor of 2 I can shave off
"make doc" (starting after "make all" from a fresh checkout), getting
free hand for the interaction between lilypond-book, Lilypond, and
Ghostscript _using_ GNU/Linux (I don't have the means to port, say,
socket communication to Windows, though at first I would stick with
batch processing that should "just work"TM).  That would be for a
uniprocessing setup.  A separate agreement may be possible for
multiprocessing, but then the results would not be deterministic for
bleedover problems since the set of snippets processed by a single
Lilypond/Ghostscript pipeline would vary from run to run.

-- 
David Kastrup

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

Re: scheme-tutorial.itely: avoid unnecessary copying (issue 5314065)

2011-10-29 Thread Ian Hulin

Hi David,
I don't want to get into a flame war here, as I think you're trying to
amend a section of manual here that needs a re-think/re-write.

I came to this conclusion when I noticed one place where it looked
like you were thinking in German, and made a common mistake in the
English version through tiredness/whatever ("wenn translated as
"when", rather than "if").

I then looked at the rest of the paragraph you'd written and it was
really good info you'd gathered from working in music-functions.scm
and the parser, but was quite different to understand for someone who
hadn't done the work you had.
Then I looked at the rest of the section, and saw that the text
surrounding the bits you changed suffered from a similar problem.
There were some bits of English-as-a-second-language crustiness in
style, and it attempted to develop the eventual resulting music
function definition bit-by-bit in Scheme.  There was also phrasing
which wasn't clear unless you'd already done a trawl through the Hello
Scheme! bit of the Guile manual.

So when you wanted to add your extra it of information starting
"Note that this code works @emph{destructively} ..."
you faced an almost impossible job to phrase it clearly, be precise,
translate it from thinking in German, *and* fit it into the flow of
the existing text.

I can have a look at this section and think about a redraft. Carl, do
you have enough time to review a draft for Scheme-fu if I write the
first draft in OpenOffice Write?

David, can you send me something stating the point you wanted to make
about the stuff about writing Scheme within music function definition?
I'll incorporate it into the first draft.  Don't worry about how it
will fit into info.  Wenn es leichter ist, um klippenklar zu sein, daß
Sie es auf deutsch schreiben, machen Sie es so, und ich werde es
übersetzen. (If it's easier to be crystal-clear writing it in German,
do it that way and I'll translate).

Then I'll then get a version together in info and put it through review.

See below for some specific responses.

Cheers

Ian

On 29/10/11 00:49, d...@gnu.org wrote:
> Reviewers: carl.d.sorensen_gmail.com, Ian Hulin (gmail),
> 
> Message: On 2011/10/28 23:04:31, Ian Hulin (gmail) wrote:
>> David, I think you've updated an example in two places, and added
>> material
> which needs
>> to reference the second example after the first one.
> 
> I disagree.  I see only one example here.
Nevertheless, there were two @example blocks you had changed and your
comments referencing define-music-function issues were apparently
referencing the first example block which didn't yet include the
define-music-function statement. This, combined with your desire to be
technically precise about the music function issues, made
comprehension of your text very challenging.
The intermediate definition
> of a Scheme function is just a temporary simplification: the
> function is never used or demonstrated.
So why do you apparently reference it in your new text?  The
assumption, especially when reading a piece of prose like this
section, is that you when you write "this", you mean to reference
something above in the text, rather than below.  In this case, your
new text is ambiguous about which @example you mean.
There is also no information how one
> would actually get the information for passing into the Scheme 
> function at the Scheme level.
> 
> Since no attempt to do a complete example in Scheme is made, it
> would be nonsensical to add complications only required for a full
> Scheme version, only to drop them again later before even using
> them.
> 
> Since I don't have the time and energy to do this in the desired
> way (I was just trying to correct an example in discord with
> reality, making people think that about half of
> music-function-init.ly is defective), I am marking this as
> Patch_abandoned and Frog, and maybe somebody else can be interested
> in working on it until it meets the required standards.
> 
> 
> Description: scheme-tutorial.itely: avoid unnecessary copying
> 
> Please review this at http://codereview.appspot.com/5314065/
> 
> Affected files: M Documentation/extending/scheme-tutorial.itely
> 
> 
> Index: Documentation/extending/scheme-tutorial.itely diff --git
> a/Documentation/extending/scheme-tutorial.itely 
> b/Documentation/extending/scheme-tutorial.itely index 
> 4c180538f5e9ed8246bfbb821063fdb0341f825d..2177856324208ab1283a3c3db9240a9c6cc1f623
>
> 
100644
> --- a/Documentation/extending/scheme-tutorial.itely +++
> b/Documentation/extending/scheme-tutorial.itely @@ -256,7 +256,7 @@
> Abelson, see @subheading Lists
> 
> A very common Scheme data structure is the @emph{list}.  Formally,
> a -list is defined as either the empty list (represented as
> @code{'()}, +list is defined as either the empty list (represented
> as @code{'()}), or a pair whose @code{cdr} is a list.
> 
> There are many ways of creating lists.  Perhaps the most common is 
> @@ -1004,7 +1004,7 @@ and its inner expressions are stored a

Re: scheme-tutorial.itely: avoid unnecessary copying (issue 5314065)

On Sat, Oct 29, 2011 at 12:09:03PM +0100, Ian Hulin wrote:
> I can have a look at this section and think about a redraft. Carl, do
> you have enough time to review a draft for Scheme-fu if I write the
> first draft in OpenOffice Write?

A rewrite sounds good, but I heavily discourage openoffice.  Just
write a text file:

Blah blah blah

\relative c' {
  c4 d e f
}

blah blah blah lah balah

#(special-thingie)
\relative c' {
  d4 d3\special {mao} h7
}


then send it to James Lowe.  He will deal with texinfo for you.

- Graham

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

Re: scheme-tutorial.itely: avoid unnecessary copying (issue 5314065)

Ian Hulin  writes:

> Hi David,
> I don't want to get into a flame war here, as I think you're trying to
> amend a section of manual here that needs a re-think/re-write.

No flame war intended.  As I said: I can't expend the effort to do this
well.  I got annoyed by wrong information and corrected it.

The point was that it is nonsensical to copy material with an arcane
function ly:music-deep-copy when you already got a copy handed by
Lilypond, which happens every time information passes through a
MUSIC_IDENTIFIER token (also the case for $music constructs in #{
... #}).  When you refer to a variable via \music in Lilypond, you
already get a copy.  When you refer to a variable via #music in Scheme,
you get the original.  Lilypond's own music functions have no qualms
working destructively.  There is no point in the user trying to be
different, in particular since there is a dearth of convenience
functions for that purpose.

> I can have a look at this section and think about a redraft. Carl, do
> you have enough time to review a draft for Scheme-fu if I write the
> first draft in OpenOffice Write?

I am willing to answer questions and look at drafts (though not in
Oowrite).

But I don't have the resources to do this better myself.

-- 
David Kastrup

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

Re: dev/staging fail: illegal entry in bfrange

2011-10-29 Thread mike

On Oct 29, 2011, at 9:51 AM, David Kastrup wrote:

> Graham Percival  writes:
> 
>> sorry about losing track of this.
> 
> No need to apologize: _my_ computer is far too slow to be useful for
> bisection, anyway.  It looks like we will have a bit of bijection
> flakiness for a while until we get the staging business sorted out.
> 
> -- 
> David Kastrup
> 
> 

Hey all,

I'm on holiday this weekend - sorry for missing this series of e-mails & sorry 
for the missing @code.
I'll be able to get on this in a bit.

Cheers,
MS

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

Re: Sketch for in-notes. (issue 5293053)

2011-10-29 Thread m...@apollinemike.com

On Oct 29, 2011, at 9:00 AM, d...@gnu.org wrote:

>> 
> 
> Patch has been backed out.  It broke the documentation build this
> morning.  And it broke the documentation build with a line that Neil has
> already pointed out yesterday at noon.  It is not that this particular
> mistake was unheard of.
> 
> Since this kept the second in unfriendliness from accepting a patch
> series from the most unfriendly developer, consider the remarks to be
> expected as having been made.
> 
> I have not checked in this particular instance, but in my experience
> "make doc-clean info" detects most documentation building failures while
> appearing somewhat faster than a web build.
> 
> http://codereview.appspot.com/5293053/

New patch set uploaded.

Cheers,
MS

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

Re: source for Patchy the autobot

2011-10-29 Thread m...@apollinemike.com

On Oct 27, 2011, at 11:55 AM, Graham Percival wrote:

> Again, it would be great if somebody with more patience and/or
> pride in their work could take over Patchy.  As an incentive, you
> don't need to deal with our review process.  I'll hand git push
> ability for that repo out to anybody; just hack away and push
> without any concerns for code style or readability or reviews or
> whatever.
> 
> - Graham
> 

Hey Graham,

I'll have time in early 2012 to work on Patchy in more detail, but there is one 
contribution that I can make right away.  I thought that patchy did a full doc 
build (BUILD_ALL_DOCS = True), but the most recent problem with my in-notes 
patch leads me to believe that she doesn't.  Do you have any intuition as to 
how Patchy may be fine tuned to catch problems in the reg-tests/docs?  I'd 
gladly spend the hour necessary to write that Python code!

Cheers,
MS

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

Re: scheme-tutorial.itely: avoid unnecessary copying (issue 5314065)

2011-10-29 Thread Ian Hulin

Hi David,
On 29/10/11 13:22, David Kastrup wrote:
> Ian Hulin  writes:
> 
>> Hi David, I don't want to get into a flame war here, as I think
>> you're trying to amend a section of manual here that needs a
>> re-think/re-write.
> 
> No flame war intended.  As I said: I can't expend the effort to do
> this well.  I got annoyed by wrong information and corrected it.
> 
> The point was that it is nonsensical to copy material with an
> arcane function ly:music-deep-copy when you already got a copy
> handed by Lilypond, which happens every time information passes
> through a MUSIC_IDENTIFIER token (also the case for $music
> constructs in #{ ... #}).  When you refer to a variable via \music
> in Lilypond, you already get a copy.  When you refer to a variable
> via #music in Scheme, you get the original.  Lilypond's own music
> functions have no qualms working destructively.  There is no point
> in the user trying to be different, in particular since there is a
> dearth of convenience functions for that purpose.
> 
>> !!Ping!!<<  @image{Picture-of-lightbulb-lighting-up}
Got it.
>> I can have a look at this section and think about a redraft.
>> Carl, do you have enough time to review a draft for Scheme-fu if
>> I write the first draft in OpenOffice Write?
> 
> I am willing to answer questions and look at drafts (though not in 
> Oowrite).
> 
OK, I'll hack together a text file.  Do you want to do this via e-mail
or Rietveld?
> But I don't have the resources to do this better myself.
> 
OK.  It's on my to-do list.  I'll take a break from the Guile V2
Migration cave. . .
Cheers,
Ian


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

Re: source for Patchy the autobot

"m...@apollinemike.com"  writes:

> On Oct 27, 2011, at 11:55 AM, Graham Percival wrote:
>
>> Again, it would be great if somebody with more patience and/or
>> pride in their work could take over Patchy.  As an incentive, you
>> don't need to deal with our review process.  I'll hand git push
>> ability for that repo out to anybody; just hack away and push
>> without any concerns for code style or readability or reviews or
>> whatever.
>> 
>> - Graham
>> 
>
> Hey Graham,
>
> I'll have time in early 2012 to work on Patchy in more detail, but
> there is one contribution that I can make right away.  I thought that
> patchy did a full doc build (BUILD_ALL_DOCS = True), but the most
> recent problem with my in-notes patch leads me to believe that she
> doesn't.

Why?  She never admitted that patch into master.

-- 
David Kastrup


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

Re: source for Patchy the autobot

On Sat, Oct 29, 2011 at 03:38:27PM +0200, m...@apollinemike.com wrote:
> I'll have time in early 2012 to work on Patchy in more detail,
> but there is one contribution that I can make right away.  I
> thought that patchy did a full doc build (BUILD_ALL_DOCS =
> True), but the most recent problem with my in-notes patch leads
> me to believe that she doesn't.

I've decided to use the male pronoun for Patchy, since Vivi is a
girl and I don't want people to think I have a fixation on virtual
little girls.  (as an anime and vocaloid geek, of couse I actually
_do_, but I try not to make it terribly obvious)

Anyway, Patchy doesn't do a doc build for patches because of a
combation of
1) patch handling is not in a cronjob yet (he needs more testing)
2) I don't have a fast enough computer to want to sit through a
doc rebuild for every patch

As a result, right now Patchy only does a full doc build for the
dev/staging merge.

> Do you have any intuition as to
> how Patchy may be fine tuned to catch problems in the
> reg-tests/docs?  I'd gladly spend the hour necessary to write
> that Python code!

Best thing right now is testing + error-proofing Patchy.  Code
review would help; it's the best single method of catching bugs:
http://kev.inburke.com/kevin/the-best-ways-to-find-bugs-in-your-code/
look at Patchy source, assume that everything I wrote is flawed,
and send patches (or just push fixes) for those flaws.

once Patchy is tested a bit more, I'll put him in a cronjob (so my
computer can be busy with that when I'm not there), and once he's
tested even more, I'll offload him to James.

- Graham

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

changing-defaults.itely: correct misstatement about variables for context mods (issue 5306076)

2011-10-29 Thread pkx166h


Some Doc policy nit-picks


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

http://codereview.appspot.com/5306076/diff/1/Documentation/notation/changing-defaults.itely#newcode727
Documentation/notation/changing-defaults.itely:727: You may collect
context changes in a variable and apply them to a
Context changes in a variable can be a collected and applied to a ...

[don't refer to the reader (i.e. third person)]

http://codereview.appspot.com/5306076/diff/1/Documentation/notation/changing-defaults.itely#newcode742
Documentation/notation/changing-defaults.itely:742: melody = \relative
c'' { a4 a a a  a a a a }
bar checks please.

Also it might look more consistent  as

melody = \relative c'' {
  a4 a a a |
  a4 a a a |
}

http://codereview.appspot.com/5306076/diff/1/Documentation/notation/changing-defaults.itely#newcode753
Documentation/notation/changing-defaults.itely:753: >>
Indent incorrect for '>>'

http://codereview.appspot.com/5306076/

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

Re: Doc: NR Added new node for Custom Footnotes (issue 5315053)

2011-10-29 Thread pkx166h

Third Draft. Thanks so far. James

http://codereview.appspot.com/5315053/diff/5001/Documentation/notation/input.itely
File Documentation/notation/input.itely (right):

http://codereview.appspot.com/5315053/diff/5001/Documentation/notation/input.itely#newcode1020
Documentation/notation/input.itely:1020: There are two types of
footnotes that can be used; automatic footnotes
On 2011/10/27 01:56:26, Graham Percival wrote:

people don't read stuff in @subsection in html. Move this into

@unnumbered

Footnote overview

Done. I hope this was what you meant.

http://codereview.appspot.com/5315053/diff/5001/Documentation/notation/input.itely#newcode1064
Documentation/notation/input.itely:1064: \autoFootnoteGrob #'@var{Layout
Object} #'@var{(x . y)}
On 2011/10/27 01:56:26, Graham Percival wrote:

what is this @example doing here? don't the @lilypond[]s show how to

use it?

Yes they do. Although personally I don't think unless I pepper the
@lilypond examples with '\markup' as well which might make them look
messy/complicated, that it is that clear.

If you take the @lilypond above you can see I have avoided the \markup
function as it is implied (?) by the \autoFootnote however I *could*
have one if I wanted (as shown by using the \bold markup which requires
\markup to be explicitly stated.

So that was why I put the whole command syntax in. So what do you think?

http://codereview.appspot.com/5315053/diff/5001/Documentation/notation/input.itely#newcode1097
Documentation/notation/input.itely:1097: case use the manual
@code{\footnote} command below.
NB: Still waiting on mike to show me an example that I use in the
\footnote command below that I can use for top-level markup with
\autoFootnote. As I cannot seem to be able to reconstruct the example I
use with manual footnotes for automatic footnotes.

http://codereview.appspot.com/5315053/diff/5001/Documentation/notation/input.itely#newcode1107
Documentation/notation/input.itely:1107: for top-level @code{\markup} &
chorded notes, and @code{\footnoteGrob}
On 2011/10/27 01:56:26, Graham Percival wrote:

avoid & since non-english speakers might think it's input syntax.

Write out

"and" in full.

Done. Left the comma in after the 'list' so that the other 'and' doesn't
look to cumbersome to non-non English speakers. :)

http://codereview.appspot.com/5315053/

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

Re: source for Patchy the autobot

2011-10-29 Thread m...@apollinemike.com

On Oct 29, 2011, at 6:01 PM, Graham Percival wrote:

> 
> 2) I don't have a fast enough computer to want to sit through a
> doc rebuild for every patch
> 

I may be able to get a dedicated server for Patchy in the next year or so - 
I'll keep you posted.

Cheers,
MS

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

Error in git-cl

I've moved to the new git-cl as requested.  I tried to upload a fix for
Issue 11 for review (yes, I think I finally have the beamlet problem
fixed).

But when I tried to upload it, I had an error with git-cl:

sorensen2:lilypond Carl$ git-cl upload master
Traceback (most recent call last):
  File "/opt/local/bin/git-cl", line 16, in 
import projecthosting_upload
  File "/Users/Carl/git-cl/projecthosting_upload.py", line 94
except gdata.client.RequestError as err:
 ^
SyntaxError: invalid syntax
sorensen2:lilypond Carl$ which python
/opt/local/bin/python
sorensen2:lilypond Carl$ python --version
Python 2.6.6

Any thoughts on how I make this work?


Thanks,

Carl


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

make broken on OSX 10.5.8

Having some time to do some work on LilyPond, I grabbed a fresh master.

It no longer builds on OSX.

The compile fails in lily/staff-symbol.cc, with the following:

staff-symbol.cc: In static member function 'static std::vector > Staff_symbol::line_positions(Grob*)':
staff-symbol.cc:107: error: no matching function for call to
'std::vector >::vector(int&)'
../flower/include/std-vector.hh:96: note: candidates are: std::vector::vector(typename std::__flower_vector
>::const_iterator, typename std::__flower_vector
>>::const_iterator) [with T = Real, A = std::allocator]
../flower/include/std-vector.hh:92: note: std::vector::vector(const std::vector&) [with T = Real, A =
std::allocator]
../flower/include/std-vector.hh:88: note: std::vector::vector() [with T = Real, A = std::allocator]
staff-symbol.cc:120: error: no matching function for call to
'std::vector >::vector(int&)'
../flower/include/std-vector.hh:96: note: candidates are: std::vector::vector(typename std::__flower_vector
>::const_iterator, typename std::__flower_vector
>>::const_iterator) [with T = Real, A = std::allocator]
../flower/include/std-vector.hh:92: note: std::vector::vector(const std::vector&) [with T = Real, A =
std::allocator]
../flower/include/std-vector.hh:88: note: std::vector::vector() [with T = Real, A = std::allocator]
make[1]: *** [out/staff-symbol.o] Error 1
make: *** [all] Error 2


The code at hand is the following:

107   vector values (line_count);

120   vector values (line_count);




The code was introduced in d10ec4f5a95d5b205da1bd73102697f8cc03b5b6

Can anybody give me suggestions as to how to fix this?

Thanks,

Carl






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

Re: Horizontal spacing change between 2.15.9 and 2.15.10 (regression?)

2011-10-29 Thread Xavier Scheuer

On 24 October 2011 22:13, m...@apollinemike.com  wrote:
>
> Hey Xavier,
>
> If you use git bisect, you can track it down to an individual commit.
> This'll help us figure out how to fix the problem.

Hey,

Sorry for late follow-up.

I used git bisect between 2.15.9 and 2.15.10 (following instructions in
the CG).  It gave me  f7278543a3ca65ee239696c21b4a8d0155bb79db
Merge remote branch 'origin' into release/unstable
as the first bad commit.
But I must mention that in the lasts steps I got no bar lines any more,
so I considered them as good because I had 2 measures per line, but
maybe if the bar lines were present I would have had only 1 measure per
line and would have considered it as bad!

I also get, with the last one when I compiled the file, this error:
programming error: Improbable offset for stencil: inf staff space
Setting to zero.
continuing, cross fingers
programming error: Improbable offset for stencil: inf staff space
Setting to zero.
continuing, cross fingers

On 25 October 2011 02:00, Keith OHara  wrote:
>
> Xavier,
> Possibly I did this.  Sometime in 2007, the space after a key-signature
> or time-signature or clef became very compressible, because some spacing
> parameters were no longer respected (issue 1785).  I restored the
> enforcement of this space for version 2.15.9 with Janek's help to
> adjust parameters so that scores looked nice.
>
> A side effect of that fix was issue 1856: the space after time signatures
> could now stretch, which made some highly-stretched regression tests
> look different.  The fix to issue 1856 made the space at the beginning of
> each line perfectly rigid, and appeared in 2.15.10.
>
> Does the override below restore your scores?
>
> \override Score.KeySignature #'space-alist #'first-note
>  = #'(semi-fixed-space . 2.5)
> \override Score.Clef #'space-alist #'first-note
>  = #'(semi-fixed-space . 2.5)
> \override Score.TimeSignature #'space-alist #'first-note
>  = #'(semi-fixed-space . 2.0)

Hi Kieren,

I think you find the good spot.
It did restore my scores.  Actually  KeySignature #'space-alist
#'first-note = #'(semi-fixed-space . 2.5)  is sufficient (the other
ones do not show such a significant change).

But I do not understand why semi-fixed-space restores my scores,
because these scores look good with 2.14.2 (which has fixed-space,
isn't it?)!!  Maybe it is the conjunction of different changes in the
horizontal spacing that lead to a bigger change in my particular
scores, what do you think?

Thank you for your interest.  Please let me know if I can do something
about this.

Cheers,
Xavier

-- 
Xavier Scheuer 

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

Re: make broken on OSX 10.5.8

On 10/29/11 4:27 PM, "Carl Sorensen"  wrote:

>Having some time to do some work on LilyPond, I grabbed a fresh master.
>
>It no longer builds on OSX.
>
>The compile fails in lily/staff-symbol.cc, with the following:
>
>
>
>The code was introduced in d10ec4f5a95d5b205da1bd73102697f8cc03b5b6
>
>Can anybody give me suggestions as to how to fix this?

I think I figured it out.  The OSX compiler doesn't have a built in
std::vector namespace, so we use the vector class in flower/.  And the
functions in flower didn't include one with a single size argument.

Compiling now -- and I'll probably push it as soon as I complete the
compile.

Thanks,

Carl

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

Re: source for Patchy the autobot

On Sat, Oct 29, 2011 at 08:30:07PM +0200, m...@apollinemike.com wrote:
> On Oct 29, 2011, at 6:01 PM, Graham Percival wrote:
> 
> > 2) I don't have a fast enough computer to want to sit through a
> > doc rebuild for every patch
> 
> I may be able to get a dedicated server for Patchy in the next year or so - 
> I'll keep you posted.

James already has an exteremely computer.  That's not an issue.
The only problem is testing and reliability.

- Graham

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

Re: Horizontal spacing change between 2.15.9 and 2.15.10 (regression?)

2011-10-29 Thread Keith OHara

On 25 October 2011 02:00, Keith OHara  wrote:
> Possibly I did this.  Sometime in 2007, the space after a key-signature
> or time-signature or clef became very compressible, because some spacing
> parameters were no longer respected (issue 1785).  

Xavier a écrit
> I think you find the good spot.
> It did restore my scores.  

> But I do not understand why semi-fixed-space restores my scores,
> because these scores look good with 2.14.2 (which has fixed-space,
> isn't it?)!!  

fixed-space was there in 2.14.2, but it did not function since 2007.

Did your score have the notes very close to the key signature, as in 

?

Sometimes it becomes hard to read if the notes compress against the clefs
and key signatures, but other times we would like to use every bit of space:

In specific cases, of course, you can put a \noBreak to force more measures
on one line.

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

Re: make broken on OSX 10.5.8

On Sat, Oct 29, 2011 at 11:34:35PM +, Carl Sorensen wrote:
> I think I figured it out.  The OSX compiler doesn't have a built in
> std::vector namespace, so we use the vector class in flower/.

That sounds weird.  Are you on lion, and does that default to llvm
instead of gcc ?  If so, you might need to explicitly add -lstdc++
to the linker stage.  (I discovered that in artifastring; no idea
if that applies to lilypond as well but I wouldn't be surprised)
If you're still on gcc, then what version of gcc doesn't supply
std::vector ?

I really think this can be fixed by explicitly including a header
and/or linking to a library.

- Graham

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

Re: Error in git-cl

On Sat, Oct 29, 2011 at 09:03:28PM +, Carl Sorensen wrote:
>   File "/Users/Carl/git-cl/projecthosting_upload.py", line 94
> except gdata.client.RequestError as err:
>  ^
> SyntaxError: invalid syntax

huh, that's supposed to be valid.  I'm on python 2.6.5, and I
think it works here, although I can't remember deliberately trying
to force that exception to test it.  I'll do that in a few hours.

> Any thoughts on how I make this work?

cheap and dirty: remove the except, remove the try, and let python
print the exception as normal?

alternately, switch back to the old git-cl (you can just checkout
an earlier revision in the same git tree) to get your patch
uploaded, and come back to git-cl later.

- Graham

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

Re: make broken on OSX 10.5.8



On 10/29/11 9:23 PM, "Graham Percival"  wrote:

>On Sat, Oct 29, 2011 at 11:34:35PM +, Carl Sorensen wrote:
>> I think I figured it out.  The OSX compiler doesn't have a built in
>> std::vector namespace, so we use the vector class in flower/.
>
>That sounds weird.  Are you on lion, and does that default to llvm
>instead of gcc ?  If so, you might need to explicitly add -lstdc++
>to the linker stage.  (I discovered that in artifastring; no idea
>if that applies to lilypond as well but I wouldn't be surprised)
>If you're still on gcc, then what version of gcc doesn't supply
>std::vector ?
>
>I really think this can be fixed by explicitly including a header
>and/or linking to a library.

No, I'm on Leopard.

In flower/include/std-vector.hh we see:

70 #if HAVE_STL_DATA_METHOD
 71 #include 
 72 #else /* !HAVE_STL_DATA_METHOD */
 73 #define vector __flower_vector
 74 #include 
 75 #undef vector
 7



In my config.log, I see the following:

347 configure:5124: checking for stl.data () method
 348 configure:5145: g++ -c -I/opt/local/include  -O2 -finline-functions
-g -pipe   conftest.cpp >&5
 349 conftest.cpp:9:1: warning: "PACKAGE_NAME" redefined
 350 conftest.cpp:2:1: warning: this is the location of the previous
definition
 351 conftest.cpp:23: error: 'class std::vector
>' has no  member named 'data'
 352 configure:5145: $? = 1
 353 configure: failed program was:
 354 | /* confdefs.h */
 355 | #define PACKAGE_NAME ""
 356 | #define PACKAGE_TARNAME ""
 357 | #define PACKAGE_VERSION ""
 358 | #define PACKAGE_STRING ""
 359 | #define PACKAGE_BUGREPORT ""
 360 | #define PACKAGE_URL ""
 361 | #define PACKAGE "lilypond"
 362 | #define PACKAGE_NAME "LilyPond"
 363 | #define TOPLEVEL_VERSION "2.15.17"
 364 | #define DIRSEP '/'
 365 | #define PATHSEP ':'
 366 | #define DATADIR "/Users/Carl/lilypond/share"
 367 | #define BUILD_PACKAGE_DATADIR
"/Users/Carl/lilypond/out/share/lilypond"
 368 | #define LIBDIR "NONE/lib"
 369 | #define BUILD_PACKAGE_LIBDIR "/Users/Carl/lilypond/out/lib/lilypond"
 370 | #define NDEBUG 1
 371 | /* end confdefs.h.  */
 372 |
 373 | #include 
 374 | using namespace std;
 375 | vector  v;
 376 | void *p = v.data ();
 377 |
 378 | int
 379 | main ()
 380 | {
 381 |
 382 |   ;
 383 |   return 0;
 384 | }
 385 configure:5152: result: no

And HAVE_STL_DATA_METHOD is not defined in config.status



So I think my fix is actually correct, although there may be a way to get
my system to have the data method.

Thanks,

Carl



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

Re: make broken on OSX 10.5.8