Re: Typos in English manual

 On 31/07/10 22:50, Michael S. Morales wrote:
> On 7/31/2010 10:31 AM, Neil Puttock wrote:
>>
>> I had a vague recollection that this was part of the doc policy, and
>> it's certainly listed here:
>>
>> http://lists.gnu.org/archive/html/lilypond-user/2007-09/msg00486.html
>>
>> * Do not use abbreviations (don't, won't, etc.).  If you do, use a
>>    comma after it:
>>
>>      blabla blabla, i.e., blabla blabla
>>
>> I don't know why it's not in CG though.
>>
>> Cheers,
>> Neil
>>    
>
> From what I've learned about using "i.e.," you can use it like:
>
> "He can read very well, i.e. [...]"
>
> So, the comma goes before the i.e., but not after because "est" (is)
> acts as a verb and it's not necessary. However, "i.e." sometimes also
> translates as "in other words," so a comma would be necessary there
> because it's a prepositional phrase.
>
You've just articulated what I was thinking, but a comma imho isn't
necessary after the prepositional. To provide a horribly stilted example

Re: T1055: Avoid using deprecated %module-public-interface in guile initialisation. (issue1160044)

Hi Patrick, Neil and all,

On 29/07/10 20:24, n.puttock <at> gmail.com wrote:
> On 2010/07/29 00:55:35, Patrick McCarty wrote:
>
>> With your patchset, I am getting a compile failure with the regression
> test
>> `profile-property-access.ly':
>
> Same here.

How did you guys track it down to this module?  I only get from the
regression test is this message (this is the tail of the log file).
<snip>

Processing 59/lily-af159abe
Processing 4f/lily-cdefb8cf
Processing 52/lily-23a75a14
command failed: /home/ian/lilypond/out/bin/lilypond -I ./ -I ./out-test
-I ../../input -I /home/ian/lilypond/Documentation -I
/home/ian/lilypond/Documentation/snippets -I ../../input/regression/ -I
/home/ian/lilypond/Documentation/included/ -I /home/ian/lilypond/mf/out/
-I /home/ian/lilypond/mf/out/ -I
/home/ian/lilypond/Documentation/pictures -I
/home/ian/lilypond/Documentation/pictures/./out-test -dbackend=eps
--formats=ps  -dseparate-log-files -dinclude-eps-fonts
-dgs-load-lily-fonts --header=texidoc -I
/home/ian/lilypond/Documentation/included/ -ddump-profile
-dcheck-internal-types -ddump-signatures -danti-alias-factor=1 -I
"/home/ian/lilypond/out/lybook-testdb"  -I

Re: Typos in English manual

On 7/31/10 5:51 PM, "Wols Lists" <antlists <at> youngman.org.uk> wrote:

>  On 31/07/10 22:50, Michael S. Morales wrote:
>> On 7/31/2010 10:31 AM, Neil Puttock wrote:
>>> 
>>> I had a vague recollection that this was part of the doc policy, and
>>> it's certainly listed here:
>>> 
>>> http://lists.gnu.org/archive/html/lilypond-user/2007-09/msg00486.html
>>> 
>>> * Do not use abbreviations (don't, won't, etc.).  If you do, use a
>>>    comma after it:
>>> 
>>>      blabla blabla, i.e., blabla blabla
>>> 
>>> I don't know why it's not in CG though.
>>> 
>>> Cheers,
>>> Neil
>>>   
>> 
>> From what I've learned about using "i.e.," you can use it like:
>> 
>> "He can read very well, i.e. [...]"
>> 
>> So, the comma goes before the i.e., but not after because "est" (is)
>> acts as a verb and it's not necessary. However, "i.e." sometimes also
>> translates as "in other words," so a comma would be necessary there
>> because it's a prepositional phrase.

Re: [PATCH] fix to issue 1173

On 7/30/10 10:06 PM, "Neil Puttock" <n.puttock <at> gmail.com> wrote:

> On 30 July 2010 14:19, Mike Solomon <mikesol <at> ufl.edu> wrote:
>> This raises an error message if showLastLength is not used to show full
>> measures.
> 
> Ouch. :)
> 
> We should always try to continue compilation (leaving aside syntax
> errors, of course) so I think it would be better to `round' the value
> if necessary to ensure it doesn't break full bars.
> 
> From the user's point of view, it's unlikely to matter if
> showLastLength doesn't result in exactly the specified number of bars.
> 
> BTW, you'd also need to fix showFirstLength.
> 
> Cheers,
> Neil
> 

Done :)
Please let me know what you think.
~Mike

_______________________________________________

Re: feta-accordion.mf, convertrules.py, musicxml2ly.py: sanitize accordion symbol names (issue1908041)

http://codereview.appspot.com/1908041/diff/10002/18002
File python/convertrules.py (right):

http://codereview.appspot.com/1908041/diff/10002/18002#newcode3014
python/convertrules.py:3014: 'accDot': 'dot',
indent

http://codereview.appspot.com/1908041/diff/10002/18002#newcode3018
python/convertrules.py:3018: 'accOldEE': 'oldEE'}
missing 'accDiscant'

http://codereview.appspot.com/1908041/diff/10002/18002#newcode3019
python/convertrules.py:3019: return '"\1%s"' %  d[m.group (2)]
This doesn't work for the `accordion.' part: it returns the matched
object rather than the string.

It seems you need to expand the backreference and add an extra
backslash:

return m.expand ('"\\1%s"' %  d[m.group (2)])

http://codereview.appspot.com/1908041/show

Re: feta-accordion.mf, convertrules.py, musicxml2ly.py: sanitize accordion symbol names (issue1908041)

On 2010/08/01 12:41:41, dak wrote:

> I changed the source according to the suggestions, but it does not
appear like
> the snippets or the docs are converted automatically.

> I have no idea how this is supposed to work, but if people say this is
correct,
> I'll commit it in this form.

The snippets will only pick up the changes via a full LSR update (i.e.,
running makelsr.py with the docs tarball from the LSR website), but it's
safe to run convert-ly directly (looks like the only snippet which needs
emending is accordion-discant-symbols.ly.)

You can edit the docs manually or run convert-ly; it's up to you.

Cheers,
Neil

You can edit them manually or run convert-ly on each file.

http://codereview.appspot.com/1908041/show

Re: [PATCH] fix to issue 1173

On 1 August 2010 08:18, Mike Solomon <mikesol <at> ufl.edu> wrote:

> Done :)
> Please let me know what you think.

Great!  I'll put it up on Rietveld and take a closer look later.

Thanks,
Neil

Re: [PATCH] fix to issue 1173

On 1 August 2010 13:25, Neil Puttock <n.puttock <at> gmail.com> wrote:

> Great!  I'll put it up on Rietveld and take a closer look later.

http://codereview.appspot.com/1741060/show

Re: feta-accordion.mf, convertrules.py, musicxml2ly.py: sanitize accordion symbol names (issue1908041)

On 2010/07/29 17:43:37, Graham Percival wrote:
> On 2010/07/29 13:01:47, c_sorensen_byu.edu wrote:
> > Right now you have put these conversions into a separate rule.  Add
them to
> > the 2.13.29 rule.  Then I think you have to do make to get the rules
into
> > convert-ly, but I'm not sure on that.

> You might need to do something like
>    make -C scripts
> but personally I'd just do a make clean and then make.

> Also, I wouldn't change the VERSION at all.

> It would definitely be nice if somebody looked into this and added
instructions
> to the CG, though.

> Cheers,
> - Graham

I changed the source according to the suggestions, but it does not
appear like the snippets or the docs are converted automatically.

I have no idea how this is supposed to work, but if people say this is
correct, I'll commit it in this form.

http://codereview.appspot.com/1908041/show

Re: T1055: Avoid using deprecated %module-public-interface in guile initialisation. (issue1160044)

On 2010/08/01 00:11:44, Ian Hulin wrote:

> How did you guys track it down to this module?

Since Patrick had already reported the failure, I cheated by applying
the patch and compiling profile-property-access.ly. :)

> I only get from the
> regression test is this message (this is the tail of the log file).
> <snip>

You should find the failed file further up the log.  Here's what I get:

Processing ./snippet-map--4234561403288800728
Failed files: (a1/lily-624a475e.ly)
logfile lilypond-multi-run-0.log (exit 1):
3/lily-9bd4398b
Processing da/lily-cddc2009
Processing 7b/lily-66b6addb
Processing f2/lily-115c7a97
Processing 1f/lily-aee531b8
Processing af/lily-14cabdbc
Processing 69/lily-663ee4f1
Processing 3c/lily-cf6046fa
Processing a3/lily-71898ac9
Processing 2d/lily-ca1387bf
Processing 26/lily-79010cda
Processing 76/lily-3893c7bc
Processing 09/lily-799c5df9
Processing 3f/lily-d9e46c0b