Re: 2.17.1 regtests
Phil Holmes philholmes.net> writes:
> Anyway, I found a number that concern me. See them at
> http://www.philholmes.net/lilypond/regtestresults/2.17.1/.
I think all the concerns are covered by your tracker items, or otherwise
covered, or not concerns.
completion-heads-polyphony-2.png -- Mike's skylines made a minor change
to issue 1537
repeat-sign-global-size-10.png -- as the author intended
stencil-color-rotation.png -- In the past, rotation worked after LilyPond
had placed everything, so users had to do our own collision avoidance.
We could tweak the hand-tuned rotation-point the test to accommodate
Mikes tighter spacing, if the collision is distracting.
mensural-ligatures.png -- Mike's skylines patch changed spacing with
textLengthOn, but maybe for the better in most cases. The overrides in
this test complicate the situation. The change is that, in
\relative f { \textLengthOn \repeat unfold 4 {f'-"MEM" f-"EME" }}
the words used to be in one line with the letters run up tight;
now they stagger.
markup-note-dot.png -- same as above, with markup instead of just text
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: bar-line interface part 2/2 (issue 6498052)
Great work so far.
Some minor suggestions:
http://codereview.appspot.com/6498052/diff/5001/scm/bar-line.scm
File scm/bar-line.scm (right):
http://codereview.appspot.com/6498052/diff/5001/scm/bar-line.scm#newcode203
scm/bar-line.scm:203:
If a user defines some curious bar-lines like:
#(define-bar-line "|SS...SS|" "|SS.." "..SS|" "|==...==|")
LilyPond will create some weird output without any hint whats wrong, I'd
suggest adding a warning like:
(map (lambda (x) (if (not (assoc-get x bar-glyph-alist))
(ly:warning (_ "bar-glyph ~a has to be defined before, in
separate
definition") x)))
(list eol-glyph bol-glyph))
and to change the order of the predefined bar-lines at the bottom of the
file.
http://codereview.appspot.com/6498052/diff/5001/scm/bar-line.scm#newcode212
scm/bar-line.scm:212:
If a user defines his own bar-line and chooses a glyph with
string-length greater than 1, compiling will fail without a useful
log-message.
I'd suggest:
(define-public (add-bar-glyph-print-procedure glyph proc)
"Specify the single glyph @var{glyph} that calls print procedure
@var{proc}.
The procedure @var{proc} has to be defined in the form
@code{(make-...-bar-line grob extent)} even if the @var{extent}
is not used within the routine."
(if (or (not (string? glyph))
(> (string-length glyph) 1))
(ly:warning (_ "glyph ~a is not of string-length 1") glyph)
(set! bar-glyph-print-procedures
(acons glyph proc bar-glyph-print-procedures
or sth like this
http://codereview.appspot.com/6498052/diff/5001/scm/bar-line.scm#newcode878
scm/bar-line.scm:878: (define-bar-line ":.|.:" ":|." ".|:" " .|.")
The following to lines should be moved to the position directly after
;;repeats
(see my comment above)
http://codereview.appspot.com/6498052/diff/5001/scm/bar-line.scm#newcode882
scm/bar-line.scm:882: (define-bar-line ":|]" "|" ":|]" " |")
I think it should be:
(define-bar-line ":|]" ":|]" "" " |")
http://codereview.appspot.com/6498052/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.17.1 regtests
mike mikesolomon.org mikesolomon.org> writes: > On 30 août 2012, at 00:44, David Kastrup gnu.org> wrote: > > > Much more worrying > > in my opinion is that the staffs in the first third of the page are > > crammed into each other so tightly that it becomes quite hard to guess > > which of the interleaved material belongs to top and which to bottom > > system. We addressed this in issue 1290, but it has come un-fixed. http://code.google.com/p/lilypond/issues/detail?id=1290 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB patch
Hi David,
Il giorno mer, 29/08/2012 alle 16.37 +0200, David Kastrup ha scritto:
> Hi, I just looked at the repository, and picked out the patch that was
> required for bypassing the bashism. However, I don't think that the
> "touch all manual pages" thing actually belongs in there and should
> likely get removed before committing this.
>
> John, is this correct?
If you don't include the "touch all manual pages" in your commit, GUB
build of tools::texinfo shall fail for every system, whether help2man is
available system-wide or not, as in this case Texinfo build does not
look for binaries in /usr/bin, at least not help2man.
If you find touching files like in this patch too ugly, a proper
solution is to add a GUB spec file for help2man (with a dependency on
Perl IIRC, which IIRC is already built in tools GUB target) and add its
dependency in Texinfo spec file.
Best,
John
>From faa7fadcdea789287e4a8e7ef0b7eccfbf29a790 Mon Sep 17 00:00:00 2001
From: administrator
Date: Tue, 28 Aug 2012 18:18:30 +0200
Subject: [PATCH] Work around a bashism/optimism breaking dash in texi2dvi
shellscript
---
gub/specs/texinfo.py | 10 ++
patches/texinfo-texi2dvi-4.13a.patch | 20
2 files changed, 30 insertions(+)
create mode 100644 patches/texinfo-texi2dvi-4.13a.patch
diff --git a/gub/specs/texinfo.py b/gub/specs/texinfo.py
index 746d8a3..e8e33f0 100644
--- a/gub/specs/texinfo.py
+++ b/gub/specs/texinfo.py
@@ -2,7 +2,17 @@ from gub import tools
class Texinfo__tools (tools.AutoBuild):
source = 'http://ftp.gnu.org/pub/gnu/texinfo/texinfo-4.13a.tar.gz'
+patches = [
+'texinfo-texi2dvi-4.13a.patch',
+]
def patch (self):
tools.AutoBuild.patch (self)
# Drop ncurses dependency
self.file_sub ([(' info ',' ')], '%(srcdir)s/Makefile.in')
+def autoupdate (self):
+# We don't want to rebuild Texinfo man pages
+#
+tools.AutoBuild.autoupdate (self)
+self.system ('''
+cd %(srcdir)s && touch doc/*.1
+''')
diff --git a/patches/texinfo-texi2dvi-4.13a.patch b/patches/texinfo-texi2dvi-4.13a.patch
new file mode 100644
index 000..37cff3e
--- /dev/null
+++ b/patches/texinfo-texi2dvi-4.13a.patch
@@ -0,0 +1,20 @@
+diff --git a/util/texi2dvi b/util/texi2dvi
+index 18b2214..7e5855a 100644
+--- a/util/texi2dvi
b/util/texi2dvi
+@@ -129,12 +129,13 @@
+ }
+ test_local
+ test $foo = bar
+-) || local () {
++) || eval '
++local () {
+ case $1 in
+ *=*) eval "$1";;
+ esac
+ }
+-
++'
+
+ # cd_orig
+ # ---
--
1.7.9.5
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.17.1 regtests
On 30 août 2012, at 00:44, David Kastrup wrote: > "m...@mikesolomon.org" writes: > >> The regtest that worries me most is les-nereides.ly. >> >> There is a comment starting on line 827 of axis-group-engraver.cc from >> Joe (vintage 2008) that describes this scenario. It's just that excess >> spacing has always hid it. It is now the time to tackle it head on, >> as w/ the new skyline patch this type of scenario will come up more >> often. > > You appear worried about the slur through the fingerings. Yes, that is > an ugly collision. But it is "merely" a collision. Much more worrying > in my opinion is that the staffs in the first third of the page are > crammed into each other so tightly that it becomes quite hard to guess > which of the interleaved material belongs to top and which to bottom > system. This generally looks like a non-existent staff-staff-spacing > only kept apart by collision avoidance. > system-system-spacing still works. I think it's fine to increase the minimum distance of system-system-padding (I'll let someone else make the call of how much) now that stuff is snugger. But the cross-staff problems matter a great deal. If you take out the slurs, the spacing problem is less of an eyesore (although still eyesoric). Cheers, MS > We _really_ need a smart padding strategy reducing this effect which is > _far_ too pronounced to produce readable scores. And perhaps > double-check that staff-staff-spacing is actually doing its part in > keeping the skylines at a distance. I somewhat doubt it. > > -- > David Kastrup > > > ___ > 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: 2.17.1 regtests
"m...@mikesolomon.org" writes: > The regtest that worries me most is les-nereides.ly. > > There is a comment starting on line 827 of axis-group-engraver.cc from > Joe (vintage 2008) that describes this scenario. It's just that excess > spacing has always hid it. It is now the time to tackle it head on, > as w/ the new skyline patch this type of scenario will come up more > often. You appear worried about the slur through the fingerings. Yes, that is an ugly collision. But it is "merely" a collision. Much more worrying in my opinion is that the staffs in the first third of the page are crammed into each other so tightly that it becomes quite hard to guess which of the interleaved material belongs to top and which to bottom system. This generally looks like a non-existent staff-staff-spacing only kept apart by collision avoidance. We _really_ need a smart padding strategy reducing this effect which is _far_ too pronounced to produce readable scores. And perhaps double-check that staff-staff-spacing is actually doing its part in keeping the skylines at a distance. I somewhat doubt it. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Lilypond-auto] Issue 2790 in lilypond: Patch: bar-line interface part 2/2
Am 30.08.2012 00:07, schrieb David Kastrup: Marc Hohl writes: Am 29.08.2012 21:43, schrieb lilyp...@googlecode.com: Updates: Labels: -Patch-new Patch-needs_work Comment #3 on issue 2790 by pkx1...@gmail.com: Patch: bar-line interface part 2/2 http://code.google.com/p/lilypond/issues/detail?id=2790#c3 Patchy the autobot says: lots of: +programming error: Parsed object should be dead: # I don't understand this error messages, and I didn't see any of them during the make test-baseline ... make test-redo cycle; even make doc succeds. Any hints where these errors come from? You need to configure with --disable-optimising (which does not make a whole lot of sense) and run with -ddebug-gc. This explains why I didn't see them. I spotted two differences in the regtests: bar-lines.ly shows a difference in the placement of the dashed bar-line, which is on purpose, and bar-line-segno.ly showed a missing bar line definition, which I will correct soonish. Thanks, Marc ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Font license. Was: Waltrop meeting outline
2012/8/28 Mats Bengtsson : > Han-Wen Nienhuys wrote: >>> >>> Change font license from GPL to dual licensed OFL / GPL (see >>> http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&id=OFL_web) >> >> We have agreement of this from the people who were here: >> >> Author: Janek Warchol >> Author: Jan Nieuwenhuizen >> Author: Marc Hohl (*) >> >> - Graham >> > I noticed my name was on the list of font contributors. I don't have any > problem with whatever licensing form you choose. Same here. I'm happy to go along with whatever you decide. As an aside, I'd like to take this opportunity to say thanks for all the amazing work you guys do for Lilypond (and especially for getting 2.16 released)! I must admit that the last time I actively used it was probably a few years ago, but just seeing all the improvements and the constant flow of things going on is mindblowing. Kudos to all involved! Best wishes, Max ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Lilypond-auto] Issue 2790 in lilypond: Patch: bar-line interface part 2/2
Marc Hohl writes:
> Am 29.08.2012 21:43, schrieb lilyp...@googlecode.com:
>> Updates:
>> Labels: -Patch-new Patch-needs_work
>>
>> Comment #3 on issue 2790 by pkx1...@gmail.com: Patch: bar-line
>> interface part 2/2
>> http://code.google.com/p/lilypond/issues/detail?id=2790#c3
>>
>> Patchy the autobot says: lots of: +programming error: Parsed object
>> should be dead: #> Hara_kiri_engraver) (consists Hara_kiri_engraver) (push
>> VerticalAxisGroup #t remove-empty) (description Remove staves which
>> are considered to be empty according to the list of interfaces set
>> by @code{keepAliveInterfaces}.))
>>
>>
>>
> I don't understand this error messages, and I didn't see any of them
> during the
>
> make test-baseline ... make test-redo
>
> cycle; even
>
> make doc
>
> succeds. Any hints where these errors come from?
You need to configure with --disable-optimising (which does not make a
whole lot of sense) and run with -ddebug-gc.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.17.1
eluze writes: > Phil Holmes wrote >> >> Can I just say that this is the first release I've build and uploaded? >> Fingers crossed. >> >> > congrats! > > however issue 2764 claims to solve the fingering problems of chords > containing a second - I can not confirm this (picture attached)! > > http://lilypond.1069038.n5.nabble.com/file/n131656/2764.png > > and also issue 2284 seems to produce the old output > > what's going on? Time lag. git log -10 --all --graph --decorate gives: * commit ecf25f33aa4c02efda0694280e956c147f5006ae (origin/staging) | Author: Phil Holmes | Date: Wed Aug 29 16:01:20 2012 +0100 | | Release: bump version. | * commit e98a84d3adfccbce3792b1176c937cc23589e669 |\ Merge: 58a49e2 bfc7fda | | Author: Phil Holmes | | Date: Wed Aug 29 15:59:49 2012 +0100 | | | | Merge remote branch 'origin/release/unstable' into HEAD | | | * commit bfc7fdae57842d561568d1516337ce60e9aa8be0 (tag: release/2.17.1-1, origin/release/unstable) | | Author: Graham Percival | | Date: Tue Aug 28 08:29:54 2012 +0100 | | | | Release: update news. | | * | commit 58a49e2c9dd187063f479389376705391d817ad3 | | Author: Marc Hohl | | Date: Sun Aug 26 11:04:54 2012 +0200 | | | | Issue 1236: CG+scripts should use $LILYPOND_GIT | | * | commit 66a7c3e925cbc1a34eaad04f80d4bc42ad9834ac (origin/master, origin/HEAD) | | Author: Mike Solomon | | Date: Wed Aug 29 10:22:31 2012 +0200 | | | | Uses FingeringColumn to avoid collisions of overlapping Fingerings. | | * | commit 2a6d112286bfaabe36ef54fc655821cd87a91f4b | | Author: Mike Solomon | | Date: Wed Aug 29 10:14:16 2012 +0200 | | | | Adds OctavateEight to the avoidance grobs of the Beam_collision_engraver | | * | commit b0f94fb2156046b5fc721f271d55e2feb788167d | | Author: Mike Solomon | | Date: Wed Aug 29 10:06:36 2012 +0200 | | | | Extracts Accidentals for AccidentalPlacements in the side-position-interface. | | | | Because AccidentalPlacements have no height, this makes sure that all | | accidentals are accounted for in case an engraver missed them. | | * | commit 1cdcb2f73f35834fef5cbbc2a6647a11ae468f85 | | Author: Marc Hohl | | Date: Tue Aug 28 22:52:24 2012 +0200 | | | | apply scripts/auxiliar/update-with-convert-ly.sh | | * | commit e6073c719af153e80ba9f31ed96040a3782a180a (HEAD, master) |/ Author: Mike Solomon | Date: Tue Aug 28 09:45:58 2012 +0200 | | Get rid of unused Skyline and Skyline_pair functions | * commit 1218da693e22c42b9f78074ad4d8f4a9151855c4 | Author: Keith OHara | Date: Wed Aug 15 23:01:36 2012 -0700 | | Properties to control placement of accidentals in KeySignatures | So since Phil took a bit of time after forking the unstable release branch to finish making the release, there are about 9 commits marked "Fixed_2_17_1" which have to be changed to "Fixed_2_17_2" since they missed the proper time to actually make it into 2.17.1. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: automated computing tasks for lilypond
Hello, On 29 August 2012 13:26, Graham Percival wrote: > > Yes. If you're ok with this, let's continue using your computer > as this. Could you re-enable the cronjob to run staging-merge > every 6 hours? OK I have set up all the push access and done a test and it seems to work, I cannot yet get it to send the email.. hmm.. probably some silly typo somewhere. But I haven't time to figure that out now, I'm starting to flag, and making more mistakes on the command line than I ought. I'll run patchy manually when I get up in the morning (about 7 hours from now-ish) and then will run it manually when I get back from work tomorrow evening and hopefully have more time to work out the kinks with this email business. James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Lilypond-auto] Issue 2790 in lilypond: Patch: bar-line interface part 2/2
Hello,
On 29 August 2012 22:44, Marc Hohl wrote:
> Am 29.08.2012 21:43, schrieb lilyp...@googlecode.com:
>>
>> Updates:
>> Labels: -Patch-new Patch-needs_work
>>
>> Comment #3 on issue 2790 by pkx1...@gmail.com: Patch: bar-line interface
>> part 2/2
>> http://code.google.com/p/lilypond/issues/detail?id=2790#c3
>>
>> Patchy the autobot says: lots of: +programming error: Parsed object should
>> be dead: #> Hara_kiri_engraver) (consists Hara_kiri_engraver) (push VerticalAxisGroup #t
>> remove-empty) (description Remove staves which are considered to be empty
>> according to the list of interfaces set by @code{keepAliveInterfaces}.))
>>
>>
>>
> I don't understand this error messages, and I didn't see any of them
> during the
>
> make test-baseline ... make test-redo
>
> cycle; even
>
> make doc
>
> succeds. Any hints where these errors come from?
Sorry for not making myself more clear, these are shown in the actual
reg tests themselves.
James
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Lilypond-auto] Issue 2790 in lilypond: Patch: bar-line interface part 2/2
Am 29.08.2012 21:43, schrieb lilyp...@googlecode.com:
Updates:
Labels: -Patch-new Patch-needs_work
Comment #3 on issue 2790 by pkx1...@gmail.com: Patch: bar-line
interface part 2/2
http://code.google.com/p/lilypond/issues/detail?id=2790#c3
Patchy the autobot says: lots of: +programming error: Parsed object
should be dead: #Hara_kiri_engraver) (consists Hara_kiri_engraver) (push
VerticalAxisGroup #t remove-empty) (description Remove staves which
are considered to be empty according to the list of interfaces set by
@code{keepAliveInterfaces}.))
I don't understand this error messages, and I didn't see any of them
during the
make test-baseline ... make test-redo
cycle; even
make doc
succeds. Any hints where these errors come from?
Marc
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Cache all pure minimum translations (issue 6498053)
I tried in on a score where should have its largest effect, a 41-page score with 15 staves per system, and saw 8%. user 2m26.191s -> 2m14.115s sys0m1.097s-> 0m1.049s http://codereview.appspot.com/6498053/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Ledger-line-spanner: symmetric extents; issue 2493 (issue 6490043)
On Wed, 29 Aug 2012 11:23:42 -0700, wrote:
http://codereview.appspot.com/6490043/diff/7001/lily/ledger-line-spanner.cc#newcode50
lily/ledger-line-spanner.cc:50: < Paper_column::get_rank
(previous_column)))
It seems that previous_column should have a rank falling before current column,
not after.
This is a helper function for the loop down on line 100, which runs backwards.
There is already a comment just below "we go from right to left."
The loop can now run forwards; maybe I should un-reverse it.
Also, it seems like if the variables are called this, then the order
should be correct when they are passed into the function (meaning the
one supposed to come before the other comes before the other).
Otherwise a programming error should be raised. What would be the case
where the ranks of the columns would be reversed and what would justify
that happening?
Master does raise a programming for ambitus note heads
\new Staff \with { \consists "Ambitus_engraver" } { c''' d'' e' f }
The ambitus engraver creates the heads when it first starts, and adds them
using add_grob(), but somehow that puts them between the c''' and d'' in the
array.
The array contains every note-head in the Staff (that is, thousands) so I would
rather not take the time to sort it. Creating an add_front() through all the
layers of classes, for use in ambitus_engraver.cc, did not seem wise.
Given at least one known exception to ordering, I added a test for ordering.
Now I think it better to test for the known exception: skip over any
ambitus-note-heads. Or, we could continue to issue a programming-error for
this case.
http://codereview.appspot.com/6490043/
My motivation is to replace the non-looping loop
Direction d=DOWN; do {...} while (flip (&d) != DOWN);
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.17.1
Phil Holmes wrote > > Can I just say that this is the first release I've build and uploaded? > Fingers crossed. > > congrats! however issue 2764 claims to solve the fingering problems of chords containing a second - I can not confirm this (picture attached)! http://lilypond.1069038.n5.nabble.com/file/n131656/2764.png and also issue 2284 seems to produce the old output what's going on? Eluze -- View this message in context: http://lilypond.1069038.n5.nabble.com/2-17-1-tp131654p131656.html Sent from the Dev mailing list archive at Nabble.com. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
2.17.1
Can I just say that this is the first release I've build and uploaded? Fingers crossed. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.17.1 regtests
- Original Message - From: To: "Phil Holmes" Cc: "Devel" Sent: Wednesday, August 29, 2012 7:34 PM Subject: Re: 2.17.1 regtests Thanks Phil! The regtest that worries me most is les-nereides.ly. There is a comment starting on line 827 of axis-group-engraver.cc from Joe (vintage 2008) that describes this scenario. It's just that excess spacing has always hid it. It is now the time to tackle it head > on, as w/ the new skyline patch this type of scenario will come up more often. You might want to look at http://code.google.com/p/lilypond/issues/detail?id=1450 which described the same problem. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.17.1 regtests
On 29 août 2012, at 18:58, Phil Holmes wrote: > I've just spent a happy few moments looking at around 900 regtest differences > - most of the ones between 2.17.0 and 17.1. It's not a big deal except for > my sanity - we did know there would be a lot. I've not checked them all, > because my PC gets rather hot while running the tests and it went sproing > towards the end, which sounded important so I aborted the tests at > tablature*.ly. In practice, I think the PC is OK... > > Anyway, I found a number that concern me. See them at > http://www.philholmes.net/lilypond/regtestresults/2.17.1/. Mike - some of > these will be halpful for your skylines work, so do please look at them. > There are others worth checking by those who value avoiding collisions. > Please do take a look. > > There are also logfile diffs that may be worth considering. Since Mike's > work allows systems to pack closer together, some of the checks on overflow > have changed, and it may be worth checking if the regtest is still doing its > job. Logfile diffs are below. > > HTH. > > === > > Differences in > D:\Music\LilyPondDev\RegressionTests\2.17.0\regression\Output\Logfiles\page-breaking-end-of-score.log > - warning: cannot fit music on page: overflow is 2.768012 > + warning: cannot fit music on page: overflow is 2.71 > > Differences in > D:\Music\LilyPondDev\RegressionTests\2.17.0\regression\Output\Logfiles\page-breaking-min-systems-per-page2.log > - warning: cannot fit music on page: overflow is 95.412213 > + warning: cannot fit music on page: overflow is 85.639124 > > Differences in > D:\Music\LilyPondDev\RegressionTests\2.17.0\regression\Output\Logfiles\page-breaking-page-count3.log > - warning: cannot fit music on page: overflow is 6.881579 > + warning: cannot fit music on page: overflow is 2.479124 > > Differences in > D:\Music\LilyPondDev\RegressionTests\2.17.0\regression\Output\Logfiles\page-overflow-compression.log > - warning: cannot fit music on page: overflow is 1.217463 > + Layout output to `page-overflow-compression.ps'... > - warning: compressing music to fit > + Converting to PNG... > - Layout output to `page-overflow-compression.ps'... > + Success: compilation successfully completed > - Converting to PNG... > + > - Success: compilation successfully completed > - > > Filename > D:\Music\LilyPondDev\RegressionTests\2.17.0\regression\Output\safe.png does > not exist > Filename > D:\Music\LilyPondDev\RegressionTests\2.17.0for2.17.1\regression\Output\safe.png > does not exist > Differences in > D:\Music\LilyPondDev\RegressionTests\2.17.0\regression\Output\Logfiles\scheme-engraver.log > - ) (length . #))((class rest-event rhythmic-event music-event > StreamEvent) (length . #) (duration . #) (origin . > # + ) (length . #))((class rest-event rhythmic-event music-event > StreamEvent) (length . #) (duration . #) (origin . > # - Converting to PNG...>)) > > + Converting to PNG...e-engraver.ly:55:6>)) > > > Differences in > D:\Music\LilyPondDev\RegressionTests\2.17.0\regression\Output\Logfiles\skiptypesetting-all-true.log > - Success: compilation successfully completed > + warning: 6 expected warning(s) not encountered: > - > + didn't find a vertical alignment in this system > > Differences in > D:\Music\LilyPondDev\RegressionTests\2.17.0\regression\Output\Logfiles\stem-length-estimation.log > - Layout output to `stem-length-estimation.ps'... > + warning: cannot fit music on page: overflow is 8.901118 > - Converting to PNG... > + warning: compressing music to fit > - Success: compilation successfully completed > + Layout output to `stem-length-estimation.ps'... > - > + Converting to PNG... > > > -- > Phil Holmes > > > > ___ > lilypond-devel mailing list > lilypond-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/lilypond-devel Thanks Phil! The regtest that worries me most is les-nereides.ly. There is a comment starting on line 827 of axis-group-engraver.cc from Joe (vintage 2008) that describes this scenario. It's just that excess spacing has always hid it. It is now the time to tackle it head on, as w/ the new skyline patch this type of scenario will come up more often. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Creates FingeringColumn to prevent vertical fingering intersections. (issue 6472056)
http://codereview.appspot.com/6472056/diff/1/lily/fingering-column.cc File lily/fingering-column.cc (right): http://codereview.appspot.com/6472056/diff/1/lily/fingering-column.cc#newcode38 lily/fingering-column.cc:38: map shifted; It seems quite pointless to use a map here instead of a bool array, since after sorting, grob positions are not changed and you can just index a bool array using shifted[x] rather than shifted[fingerings[x]] employing a map. I think we can assume that we don't have duplicate grobs in here. http://codereview.appspot.com/6472056/diff/1/lily/fingering-column.cc#newcode65 lily/fingering-column.cc:65: for (vsize i = min (fingerings.size () - 1, fingerings.size () / 2 + 1); i >= 1; i--) The commit message talks about "fanning out" from the middle of the column, but there is no comment whatsoever in here, and it is totally unclear what this is supposed to do. Add a few comments here, and preferably some ASCII art in comments illustrating problem and solution. http://codereview.appspot.com/6472056/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Ledger-line-spanner: symmetric extents; issue 2493 (issue 6490043)
http://codereview.appspot.com/6490043/diff/7001/lily/ledger-line-spanner.cc File lily/ledger-line-spanner.cc (right): http://codereview.appspot.com/6490043/diff/7001/lily/ledger-line-spanner.cc#newcode50 lily/ledger-line-spanner.cc:50: < Paper_column::get_rank (previous_column))) I'm having trouble following this naming convention. It seems that previous_column should have a rank falling before current column, not after. Also, it seems like if the variables are called this, then the order should be correct when they are passed into the function (meaning the one supposed to come before the other comes before the other). Otherwise a programming error should be raised. What would be the case where the ranks of the columns would be reversed and what would justify that happening? http://codereview.appspot.com/6490043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
bar-line interface part 2/2 (issue 6498052)
LGTM http://codereview.appspot.com/6498052/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
2.17.1 regtests
I've just spent a happy few moments looking at around 900 regtest differences - most of the ones between 2.17.0 and 17.1. It's not a big deal except for my sanity - we did know there would be a lot. I've not checked them all, because my PC gets rather hot while running the tests and it went sproing towards the end, which sounded important so I aborted the tests at tablature*.ly. In practice, I think the PC is OK... Anyway, I found a number that concern me. See them at http://www.philholmes.net/lilypond/regtestresults/2.17.1/. Mike - some of these will be halpful for your skylines work, so do please look at them. There are others worth checking by those who value avoiding collisions. Please do take a look. There are also logfile diffs that may be worth considering. Since Mike's work allows systems to pack closer together, some of the checks on overflow have changed, and it may be worth checking if the regtest is still doing its job. Logfile diffs are below. HTH. === Differences in D:\Music\LilyPondDev\RegressionTests\2.17.0\regression\Output\Logfiles\page-breaking-end-of-score.log - warning: cannot fit music on page: overflow is 2.768012 + warning: cannot fit music on page: overflow is 2.71 Differences in D:\Music\LilyPondDev\RegressionTests\2.17.0\regression\Output\Logfiles\page-breaking-min-systems-per-page2.log - warning: cannot fit music on page: overflow is 95.412213 + warning: cannot fit music on page: overflow is 85.639124 Differences in D:\Music\LilyPondDev\RegressionTests\2.17.0\regression\Output\Logfiles\page-breaking-page-count3.log - warning: cannot fit music on page: overflow is 6.881579 + warning: cannot fit music on page: overflow is 2.479124 Differences in D:\Music\LilyPondDev\RegressionTests\2.17.0\regression\Output\Logfiles\page-overflow-compression.log - warning: cannot fit music on page: overflow is 1.217463 + Layout output to `page-overflow-compression.ps'... - warning: compressing music to fit + Converting to PNG... - Layout output to `page-overflow-compression.ps'... + Success: compilation successfully completed - Converting to PNG... + - Success: compilation successfully completed - Filename D:\Music\LilyPondDev\RegressionTests\2.17.0\regression\Output\safe.png does not exist Filename D:\Music\LilyPondDev\RegressionTests\2.17.0for2.17.1\regression\Output\safe.png does not exist Differences in D:\Music\LilyPondDev\RegressionTests\2.17.0\regression\Output\Logfiles\scheme-engraver.log - ) (length . #))((class rest-event rhythmic-event music-event StreamEvent) (length . #) (duration . #) (origin . #+ ) (length . #))((class rest-event rhythmic-event music-event StreamEvent) (length . #) (duration . #) (origin . # - Converting to PNG...>)) > + Converting to PNG...e-engraver.ly:55:6>)) > Differences in D:\Music\LilyPondDev\RegressionTests\2.17.0\regression\Output\Logfiles\skiptypesetting-all-true.log - Success: compilation successfully completed + warning: 6 expected warning(s) not encountered: - + didn't find a vertical alignment in this system Differences in D:\Music\LilyPondDev\RegressionTests\2.17.0\regression\Output\Logfiles\stem-length-estimation.log - Layout output to `stem-length-estimation.ps'... + warning: cannot fit music on page: overflow is 8.901118 - Converting to PNG... + warning: compressing music to fit - Success: compilation successfully completed + Layout output to `stem-length-estimation.ps'... - + Converting to PNG... -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds octavation-eight-interface to the Beam_collision_engraver (issue 6475065)
On 2012/08/29 15:48:36, mike7 wrote: On 29 août 2012, at 16:13, mailto:d...@gnu.org wrote: > http://codereview.appspot.com/6475065/diff/1/scm/define-grob-interfaces.scm#newcode223 > scm/define-grob-interfaces.scm:223: annotation." > What about \clef "bass_8" or \clef "treble_15" ? Should be fine...it's the same grob (OctavateEight). Well, whether or not interface and grob name are a bit too narrow in their name choice due to limited space: most certainly the documentation string is far too specific, making it appear unlikely that it can be used for anything but \clef "xxx^8". And the choice of wording, apart from misspelling "frequency", is not really typical for LilyPond either. http://codereview.appspot.com/6475065/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds octavation-eight-interface to the Beam_collision_engraver (issue 6475065)
On 29 août 2012, at 16:13, d...@gnu.org wrote: > > http://codereview.appspot.com/6475065/diff/1/scm/define-grob-interfaces.scm > File scm/define-grob-interfaces.scm (right): > > http://codereview.appspot.com/6475065/diff/1/scm/define-grob-interfaces.scm#newcode223 > scm/define-grob-interfaces.scm:223: annotation." > What about \clef "bass_8" or \clef "treble_15" ? > > http://codereview.appspot.com/6475065/ > > ___ > lilypond-devel mailing list > lilypond-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/lilypond-devel Should be fine...it's the same grob (OctavateEight). ~Mike ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Regtests
On Wed, Aug 29, 2012 at 03:52:08PM +0200, Janek Warchoł wrote: > i know that i'm late - forgot about it, sorry :( - but nevertheless it > may still be possible: > what about having a separate release containing only Mike's patch? I think that's too much hassle right now with GUB changing so much and Phil taking over. However, there's absolutely nothing stopping you from generating two sets of regtest comparisons: 1) 2.17.0 to 6f4893fa86378aa4a637eedbde5efc4680efa5bf 2) 6f4893fa86378aa4a637eedbde5efc4680efa5bf to 28f3294954eff1f263d3b2e3de1c520f4d2fbdfc As an added bonus, you don't even need to use GUB for this! :) At least, I think you don't. But even if you do, you don't need to do a full GUB build for it. If you look at the file extra.txt in your GUB directory (not committed to git), you'll see some hints about how to build a specific branch of lilypond git. I think the second line from the bottom has what you want, after you change the platform to linux-x86 and the repo to lilypond-test.git. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Gub upload failure
On Wed, Aug 29, 2012 at 03:17:40PM +0100, Phil Holmes wrote: > git --git-dir downloads/lilypond/git push > ssh+git://gperci...@git.sv.gnu.org/srv/git/lilypond.git/ > refs/tags/release/2.17.1-1:refs/tags/release/2.17.1-1 > Permission denied (publickey). > > I'm assuming that this is because GUB is trying to log in as you to > the git repo and failing, because it has my key? a) is that right? > b) should I find the gpercival@git bit and change this to my git > username and c) what does this command do? a) yes b) very top of test-lily/upload.py. "maintainer" refers to the interaction with lilypond git repo. It would be nice if this was configurable somewhere other than editing the source code (i.e. local.make, an environmental variable, whatever). c) in lilypond git, type "git tag". Those show the exact commit hashes of every release we have; this makes it easier to do things like a git bisect of all changes between 2.15.36 and 2.15.37 to find out when a particular bug was introduced. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Gub upload failure
- Original Message - From: "David Kastrup" To: "Phil Holmes" Cc: Sent: Wednesday, August 29, 2012 3:39 PM Subject: Re: Gub upload failure "Phil Holmes" writes: - Original Message - From: "David Kastrup" To: Sent: Wednesday, August 29, 2012 3:21 PM Subject: Re: Gub upload failure "Phil Holmes" writes: OK - so it looks like I've now rsynched a few 100 MB of updates. I get this failure: git --git-dir downloads/lilypond/git push ssh+git://gperci...@git.sv.gnu.org/srv/git/lilypond.git/ refs/tags/release/2.17.1-1:refs/tags/release/2.17.1-1 Permission denied (publickey). I'm assuming that this is because GUB is trying to log in as you to the git repo and failing, because it has my key? a) is that right? Likely. b) should I find the gpercival@git bit and change this to my git username and c) what does this command do? Push the tag from downloads/lilypond/git to the main repository. I actually went ahead and found the line in the script, changed it and it then continued OK. However, it looks like the tag might already have been created locally. Sure, or it would not be possible to push it. git --git-dir downloads/lilypond/git tag -m "" -a release/2.17.1-1 git.sv.gnu.org/lilypond.git/release/unstable fatal: tag 'release/2.17.1-1' already exists I've never used tags and so need to do some research, but if you could tell me how to list and possibly delete tags in the local version of the repo, that would be helpful. git tag -d release/2.17.1-1 should suffice Yep. Thanks. It seemed to complete OK with that. Now to complete the post-release checklist and watch the website for the change to 2.17.1. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Gub upload failure
"Phil Holmes" writes: > - Original Message - > From: "David Kastrup" > To: > Sent: Wednesday, August 29, 2012 3:21 PM > Subject: Re: Gub upload failure > > >> "Phil Holmes" writes: >> >>> OK - so it looks like I've now rsynched a few 100 MB of updates. I >>> get this failure: >>> >>> git --git-dir downloads/lilypond/git push >>> ssh+git://gperci...@git.sv.gnu.org/srv/git/lilypond.git/ >>> refs/tags/release/2.17.1-1:refs/tags/release/2.17.1-1 >>> Permission denied (publickey). >>> >>> I'm assuming that this is because GUB is trying to log in as you to >>> the git repo and failing, because it has my key? a) is that right? >> >> Likely. >> >>> b) should I find the gpercival@git bit and change this to my git >>> username and c) what does this command do? >> >> Push the tag from downloads/lilypond/git to the main repository. > > I actually went ahead and found the line in the script, changed it and > it then continued OK. However, it looks like the tag might already > have been created locally. Sure, or it would not be possible to push it. > > git --git-dir downloads/lilypond/git tag -m "" -a release/2.17.1-1 > git.sv.gnu.org/lilypond.git/release/unstable > fatal: tag 'release/2.17.1-1' already exists > > I've never used tags and so need to do some research, but if you could > tell me how to list and possibly delete tags in the local version of > the repo, that would be helpful. git tag -d release/2.17.1-1 should suffice -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Gub upload failure
- Original Message - From: "David Kastrup" To: Sent: Wednesday, August 29, 2012 3:21 PM Subject: Re: Gub upload failure "Phil Holmes" writes: OK - so it looks like I've now rsynched a few 100 MB of updates. I get this failure: git --git-dir downloads/lilypond/git push ssh+git://gperci...@git.sv.gnu.org/srv/git/lilypond.git/ refs/tags/release/2.17.1-1:refs/tags/release/2.17.1-1 Permission denied (publickey). I'm assuming that this is because GUB is trying to log in as you to the git repo and failing, because it has my key? a) is that right? Likely. b) should I find the gpercival@git bit and change this to my git username and c) what does this command do? Push the tag from downloads/lilypond/git to the main repository. -- David Kastrup I actually went ahead and found the line in the script, changed it and it then continued OK. However, it looks like the tag might already have been created locally. My new error is: git --git-dir downloads/lilypond/git tag -m "" -a release/2.17.1-1 git.sv.gnu.org/lilypond.git/release/unstable fatal: tag 'release/2.17.1-1' already exists I've never used tags and so need to do some research, but if you could tell me how to list and possibly delete tags in the local version of the repo, that would be helpful. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Gub upload failure
"Phil Holmes" writes: > OK - so it looks like I've now rsynched a few 100 MB of updates. I > get this failure: > > git --git-dir downloads/lilypond/git push > ssh+git://gperci...@git.sv.gnu.org/srv/git/lilypond.git/ > refs/tags/release/2.17.1-1:refs/tags/release/2.17.1-1 > Permission denied (publickey). > > I'm assuming that this is because GUB is trying to log in as you to > the git repo and failing, because it has my key? a) is that right? Likely. > b) should I find the gpercival@git bit and change this to my git > username and c) what does this command do? Push the tag from downloads/lilypond/git to the main repository. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Gub upload failure
OK - so it looks like I've now rsynched a few 100 MB of updates. I get this failure: git --git-dir downloads/lilypond/git push ssh+git://gperci...@git.sv.gnu.org/srv/git/lilypond.git/ refs/tags/release/2.17.1-1:refs/tags/release/2.17.1-1 Permission denied (publickey). I'm assuming that this is because GUB is trying to log in as you to the git repo and failing, because it has my key? a) is that right? b) should I find the gpercival@git bit and change this to my git username and c) what does this command do? -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds octavation-eight-interface to the Beam_collision_engraver (issue 6475065)
http://codereview.appspot.com/6475065/diff/1/scm/define-grob-interfaces.scm File scm/define-grob-interfaces.scm (right): http://codereview.appspot.com/6475065/diff/1/scm/define-grob-interfaces.scm#newcode223 scm/define-grob-interfaces.scm:223: annotation." What about \clef "bass_8" or \clef "treble_15" ? http://codereview.appspot.com/6475065/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Regtests
- Original Message - From: "Janek Warchoł" To: "Graham Percival" Cc: "Phil Holmes" ; "Devel" Sent: Wednesday, August 29, 2012 2:52 PM Subject: Re: Regtests On Wed, Aug 29, 2012 at 2:15 PM, Graham Percival wrote: On Wed, Aug 29, 2012 at 01:09:20PM +0100, Phil Holmes wrote: 2.17.1. The official regtest comparison is against 2.15.38, because of the vagaries of my initial GUB build. ouch, but not critical in this case. Mike's monster patch changes pretty much everything, so a regtest comparison isn't useful. I mean, it's big enough that it would be more effective to reset the web regtest checker and recruit a new wave of users to evaluate them. [...] Given Mike's monster, I doubt that the pixel comparator will be useful for 2.17.1. i know that i'm late - forgot about it, sorry :( - but nevertheless it may still be possible: what about having a separate release containing only Mike's patch? Since 2.17.1 isn't released yet (at least officially), maybe we could do sth like this: - branch 6f4893fa86378aa4a637eedbde5efc4680efa5bf (last commit before skylines) as release/2.17.1, release it - then release 28f3294954eff1f263d3b2e3de1c520f4d2fbdfc (skylines) as 2.17.2 - continue as usual ? It would be handy for regtest comparisons and other things like that. Janek 2.17.1 is 90-odd % released - if my DSL uplink was faster it would be visible on the server now. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Regtests
On Wed, Aug 29, 2012 at 2:15 PM, Graham Percival wrote: > On Wed, Aug 29, 2012 at 01:09:20PM +0100, Phil Holmes wrote: >> 2.17.1. The official regtest comparison is against 2.15.38, because >> of the vagaries of my initial GUB build. > > ouch, but not critical in this case. Mike's monster patch changes > pretty much everything, so a regtest comparison isn't useful. > I mean, it's big enough that it would be more effective to reset > the web regtest checker and recruit a new wave of users to > evaluate them. > [...] > Given Mike's monster, I doubt that the pixel comparator will be > useful for 2.17.1. i know that i'm late - forgot about it, sorry :( - but nevertheless it may still be possible: what about having a separate release containing only Mike's patch? Since 2.17.1 isn't released yet (at least officially), maybe we could do sth like this: - branch 6f4893fa86378aa4a637eedbde5efc4680efa5bf (last commit before skylines) as release/2.17.1, release it - then release 28f3294954eff1f263d3b2e3de1c520f4d2fbdfc (skylines) as 2.17.2 - continue as usual ? It would be handy for regtest comparisons and other things like that. Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Right way of specifying engraver name?
2012/8/29 Francisco Vila : > 2012/8/29 Phil Holmes : >>> We say just "using the Span_stem_engraver" but the user can be >>> confused when adding/removing other engravers because it is sometimes >>> #Name_engraver and sometimes "Name_engraver". >> I don't believe that would be the right place to change anything. Everything >> stated there is correct. > > That's true, but I got confused. This would have avoided it. code.google.com/p/lilypond/issues/detail?id=2789 -- Francisco Vila. Badajoz (Spain) www.paconet.org , www.csmbadajoz.com ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: preliminary GLISS discussions
Janek Warchoł writes: > On Wed, Aug 29, 2012 at 3:15 PM, David Kastrup wrote: >> Graham Percival writes: >> >>> At the Waltrop meeting, Janek proposed a number of interesting but >>> potentially disruptive changes to the lilypond syntax. On a >>> personal note, I really like most of them, but it will take a good >>> chunk of work before they're ready to discuss on the main >>> development list. >>> >>> Further complicating issues is that it quickly became apparent >>> that I am not personally qualified to judge if a proposal is ready >>> for main discussion. >> >> Wouldn't the purpose of a discussion be to present and discuss >> advantages and drawbacks? The question of _discussing_ a change is in >> my opinion quite different from _implementing_ a change. > > I suppose Graham meant that proposals presented for main discussion > should be well-shaped and free of big and/or obvious problems. If there are big and/or obvious problems, the discussion would be short anyway. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: applying scheme indentation
On Wed, Aug 29, 2012 at 2:29 PM, David Kastrup wrote: > Maybe Ian could push his current branch to some dev/* branch so that one > can make a rough estimate what the costs of various ways of integration > would turn out to be? fixscm.sh is basically an esthetic fix. We > should do it when we are reasonably sure of no major resulting hassles. +1 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: automated computing tasks for lilypond
Il giorno mer, 29/08/2012 alle 14.28 +0100, James ha scritto: > They did reduce significantly since Phil and I were able to run tests > quickly. I often would run tests myself after the normal patchy tests > simply because I knew a change was significant (like Mike's skyline > for instance or Phils reduces black bars and even David's lexer/parser > change and I did capture a couple of 'passes tests but fails make doc' > problems. So by the time they get in to staging the creases were > ironed out. I fully agree that running the doc build has been worthwhile for some patches, and will likely continue to be so. > also does a normal 'make' always capture fat-finger texinfo typos? It > catches all mine, but I cannot be sure it would in every case. Indeed, no; some errors in Texinfo input are ignored or handled gracefully by makeinfo/texi2html (in particular they ignore any TeX code), whereas TeX may barf on them. Best J ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: preliminary GLISS discussions
On Wed, Aug 29, 2012 at 3:15 PM, David Kastrup wrote:
> Graham Percival writes:
>
>> At the Waltrop meeting, Janek proposed a number of interesting but
>> potentially disruptive changes to the lilypond syntax. On a
>> personal note, I really like most of them, but it will take a good
>> chunk of work before they're ready to discuss on the main
>> development list.
>>
>> Further complicating issues is that it quickly became apparent
>> that I am not personally qualified to judge if a proposal is ready
>> for main discussion.
>
> Wouldn't the purpose of a discussion be to present and discuss
> advantages and drawbacks? The question of _discussing_ a change is in
> my opinion quite different from _implementing_ a change.
I suppose Graham meant that proposals presented for main discussion
should be well-shaped and free of big and/or obvious problems. I
think his point is that the purpose of main discussion is to take a
well-shaped proposal, consider its advantages and drawbacks and make a
decision.
> With regard to providing a simpler interface to humans and computers,
> the proposals were somewhat conflicting in their direction, so it would
> make sense to discuss them separately where this happens to be the case.
I agree, they should be discussed somewhat separately ("somewhat"
meaning that we keep in mind that some potentially useful proposals
depend on other proposals).
cheers,
Janek
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: preliminary GLISS discussions
On Wed, Aug 29, 2012 at 03:15:08PM +0200, David Kastrup wrote: > Graham Percival writes: > > > Thoughts? opinions? alternatives that I haven't considered? > > These discussions are going to produce a *lot* of emails. > > And if they come to conclusions, they are going to produce effects on > everybody. Including people using "LilyPond as a service". Sorry, I think I was unclear. If we have a separate email list for preliminary syntax discussions, then I imagine that something like the "everything is postfix" idea would go like this: - initial email to syntax list - 10 emails about why it might be useful - 30 emails about music functions, including explaining what they are, what's the difference between music functions and parser objects and maybe a re-discussion of \displaymusic and lilypond scheme-sandbox.ly - 20 emails about what it would break in existing scores, how it might be possible (or not) to write a convert-ly rule, etc - 20 emails pinning down an formal proposal, summarizing previous emails about the advantages and disadvantages known so far. ... the above takes 2-4 weeks... - formal proposal to -devel list - 10 emails questioning the summarizes, pointing out advantages or disadvantages not previously discussed - 20 emails about specific difficulties in implementing the proposal - 20 emails discussing the trade-offs and whether it's actually worth adopting the proposal ... the above takes 1-3 weeks... - actual implementation, pushing to staging - 1 or 2 stable releases, and/or 6 or 12 months of usage "in the wild" - final adoption as a stable syntax Every proposal must still come to -devel, and there will be absolutely no disadvantage to somebody who ignores the "preparation" emails and only comments on the formal proposal. It's just the initial 100 emails that I'm suggesting that could take place on a separate list. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: automated computing tasks for lilypond
Hello On 29 August 2012 14:19, Graham Percival wrote: > On Wed, Aug 29, 2012 at 02:09:43PM +0100, James wrote: >> Just an off-the-cuff suggestion. If we had a 'patch-new-doc' and a >> 'patch-new' label would that be useful and tell patchy if it sees the >> former to build doc as well? > > I suppose so, although people uploading with git-cl would need to > specify that it was a doc patch... or perhaps git-cl could > recognize if Documentation/ or ly/ or scm/ were modified. > > However, I think this is a solution looking for a problem. How > often does a patch fail on staging-merge due to doc issues? They did reduce significantly since Phil and I were able to run tests quickly. I often would run tests myself after the normal patchy tests simply because I knew a change was significant (like Mike's skyline for instance or Phils reduces black bars and even David's lexer/parser change and I did capture a couple of 'passes tests but fails make doc' problems. So by the time they get in to staging the creases were ironed out. also does a normal 'make' always capture fat-finger texinfo typos? It catches all mine, but I cannot be sure it would in every case. I don't think you can completely reduce the need for some human interaction and you may be right about a 'solution looking for a problem', it just depends on how irritating/difficult it is to manage staging that breaks on a merge because of doc stuff. This usually requires a few back and forth of emails and manual intervention, James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: automated computing tasks for lilypond
Il giorno mer, 29/08/2012 alle 14.09 +0100, James ha scritto: > Just an off-the-cuff suggestion. If we had a 'patch-new-doc' and a > 'patch-new' label would that be useful and tell patchy if it sees the > former to build doc as well? This is a possible option. Another that I prefer is letting Patchy select the targets to build according to which files the patch touches (the documentation would need to be built quite often then, as for example every change in a .scm or .cc file would trigger a recompilation of the docs, OTOH "make test" would not run for changes in documentation-only files, IIRC like the ones in Documentation/). Ideally changes in makefiles would even trigger a test of other targets (dist, install install-doc, ...). John ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: automated computing tasks for lilypond
On Wed, Aug 29, 2012 at 02:09:43PM +0100, James wrote: > Just an off-the-cuff suggestion. If we had a 'patch-new-doc' and a > 'patch-new' label would that be useful and tell patchy if it sees the > former to build doc as well? I suppose so, although people uploading with git-cl would need to specify that it was a doc patch... or perhaps git-cl could recognize if Documentation/ or ly/ or scm/ were modified. However, I think this is a solution looking for a problem. How often does a patch fail on staging-merge due to doc issues? If we have a lot of those, then it may be worth fiddling with test-patches. But I can't think of many such breakages in the past six months. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: preliminary GLISS discussions
Graham Percival writes: > At the Waltrop meeting, Janek proposed a number of interesting but > potentially disruptive changes to the lilypond syntax. On a > personal note, I really like most of them, but it will take a good > chunk of work before they're ready to discuss on the main > development list. > > Further complicating issues is that it quickly became apparent > that I am not personally qualified to judge if a proposal is ready > for main discussion. Wouldn't the purpose of a discussion be to present and discuss advantages and drawbacks? The question of _discussing_ a change is in my opinion quite different from _implementing_ a change. > For example, one idea was to use postfix notation for (almost) > everything. David pointed out that this would wreck havok on music > functions, and I had to admit that I have no clue what a music > function is. I mean, I know that there's \commands, but I have no > clue what the difference is between \p, \relative, \staccato; other > than their effect on the graphical+midi output. Well, this was actually more or less divided into several separate changes. One part was to _enforce_ having to write a directional modifier for postevents, meaning that whenever _ or ^ are allowed, you need to write at least -, like c4-(-[-\p-~ . This would admittedly simplify the parser (and other programs trying to parse LilyPond input), particularly when music functions like \tweak and \displayMusic and event functions like \bendAfter and \rightHandFinger get involved. Another part was to keep the undirectional syntax alive but assign different meaning to it on an as-case basis. With regard to providing a simpler interface to humans and computers, the proposals were somewhat conflicting in their direction, so it would make sense to discuss them separately where this happens to be the case. > I'm not enthusiastic about cluttering -devel with preliminary > discussions like teaching me about music functions vs. whatever the > other thing are. I am not enthusiastic about cluttering -devel with non-preliminary discussions where everybody is assumed to have mastered the topics right from the start. There are reasons and implications for some of the design decisions, and part of the aims of such a discussion is leaving the participants with a better understanding about what is involved than the manual might provide. Frankly, the parser is a mess. Removing some convenience, like what I characterize as part one of his proposal, will provide at least some relief, at the cost of making previous syntax invalid and causing a less natural look of the music expressions. It is already possible to use this part of the syntax proposal as a _convention_. LilyPond just does not enforce it. > At one point there was a mailing list on lilynet for syntax > discussions, but I'm not certain if that's active. I could also make > a new gnu.org mailing list... but either of those options would > require anybody interested in that discussion to sign up for a new > mailing list. > > Thoughts? opinions? alternatives that I haven't considered? > These discussions are going to produce a *lot* of emails. And if they come to conclusions, they are going to produce effects on everybody. Including people using "LilyPond as a service". -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: preliminary GLISS discussions
On Wed, Aug 29, 2012 at 2:10 PM, Graham Percival wrote: > At the Waltrop meeting, Janek proposed a number of interesting but > potentially disruptive changes to the lilypond syntax. On a > personal note, I really like most of them, [...] I'm very happy to hear this :) > I'm not enthusiastic about cluttering -devel with preliminary > discussions like teaching me about music functions vs. whatever > the other thing are. At one point there was a mailing list on > lilynet for syntax discussions, but I'm not certain if that's > active. I could also make a new gnu.org mailing list... but > either of those options would require anybody interested in that > discussion to sign up for a new mailing list. I'm in. :) > Thoughts? opinions? alternatives that I haven't considered? > These discussions are going to produce a *lot* of emails. A chat might be more efficient for explaining things to other people, but it isn't archived and if it was, its difficult to search, i think. A separate mailing list seems to be a good fit. cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: automated computing tasks for lilypond
Hello, On 29 August 2012 14:03, John Mandereau wrote: > Hi Graham , James and LilyPond folks, > Il giorno mer, 29/08/2012 alle 13.26 +0100, Graham Percival ha scritto: >> John, could you disable staging-merge on Grenouille? that should >> free up some computing resources for the other tasks. > > Done, I also just reenabled patches tests, which given the new system to > track which patches have been tested locally is going to test a lot of > issues, it announced that it is going to test 21 issues (!). I should > find a way to allow human intervention during a test session to remove > some patches from the queue, enable the docs build for others, etc... Just an off-the-cuff suggestion. If we had a 'patch-new-doc' and a 'patch-new' label would that be useful and tell patchy if it sees the former to build doc as well? James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: automated computing tasks for lilypond
Hi Graham , James and LilyPond folks, Il giorno mer, 29/08/2012 alle 13.26 +0100, Graham Percival ha scritto: > John, could you disable staging-merge on Grenouille? that should > free up some computing resources for the other tasks. Done, I also just reenabled patches tests, which given the new system to track which patches have been tested locally is going to test a lot of issues, it announced that it is going to test 21 issues (!). I should find a way to allow human intervention during a test session to remove some patches from the queue, enable the docs build for others, etc... Best, John ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: automated computing tasks for lilypond
Hello, On 29 August 2012 13:26, Graham Percival wrote: > On Tue, Aug 28, 2012 at 10:44:17AM +0100, James wrote: >> On 28 August 2012 08:17, Graham Percival wrote: >> > - Patchy staging-merge: powerful computer, no fixed internet >> > connection. Every 6 hours? >> >> As you know you have mine that already does test-patchy (manually) and >> has done 'staging-merge' but it has no real bandwidth to offer >> 'hosting' or 'remote access' to other users - it sits at home behind a >> bog-standard DSL router. So it's essentially a 'push-only' server so >> to speak - hence the reason it was ok for Patchy merge. > > Yes. If you're ok with this, let's continue using your computer > as this. Could you re-enable the cronjob to run staging-merge > every 6 hours? Not a problem, I'll need some time tonight to re-look at setting up patchy-merge - (re)setting up push ability and all the smtp stuff, I reinstalled a new LilyDev the day before so need to do all that admin (mainly remind myself too). It's not a big deal but it'll take me an hour or so to get it all straight again, so don't turn off the other patchy merge just yet until I give the go ahead. > > John, could you disable staging-merge on Grenouille? that should > free up some computing resources for the other tasks. James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: applying scheme indentation
Graham Percival writes: > As per GOP 2-4 - C++ and scheme indentation, we now have a > fixscm.sh in the source tree. Running this was postponed pending > Mike's monster skyline patch and possibly some sort of guile 2.0 > thing. > > What's the status of the guile 2.0 patch? In particular, is it > safe to run fixscm.sh now, or should that wait until ... ? > > I've uploaded the results of fixscm.sh: > http://codereview.appspot.com/6499050 > (I didn't add a code.google.com issue tracker for this) > > > My preference is to push this now, and let Ian (or whoever) run > fixscm.sh on their own scheme work. That does not help with rebasing, only with merging, and it is unlikely that merging Ian's work without rebasing is a good idea, as it likely has a longer history. > But I'll defer to any scheme experts if they want to delay fixscm.sh > by a week or two. Maybe Ian could push his current branch to some dev/* branch so that one can make a rough estimate what the costs of various ways of integration would turn out to be? fixscm.sh is basically an esthetic fix. We should do it when we are reasonably sure of no major resulting hassles. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: automated computing tasks for lilypond
On Tue, Aug 28, 2012 at 10:44:17AM +0100, James wrote: > On 28 August 2012 08:17, Graham Percival wrote: > > - Patchy staging-merge: powerful computer, no fixed internet > > connection. Every 6 hours? > > As you know you have mine that already does test-patchy (manually) and > has done 'staging-merge' but it has no real bandwidth to offer > 'hosting' or 'remote access' to other users - it sits at home behind a > bog-standard DSL router. So it's essentially a 'push-only' server so > to speak - hence the reason it was ok for Patchy merge. Yes. If you're ok with this, let's continue using your computer as this. Could you re-enable the cronjob to run staging-merge every 6 hours? John, could you disable staging-merge on Grenouille? that should free up some computing resources for the other tasks. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: make website and environments variables [WAS: Web glitch]
Il 29/08/2012 14:21, Graham Percival ha scritto: On Tue, Aug 28, 2012 at 07:11:10PM +0200, Federico Bruni wrote: I can launch 'make website' now, but the css stylesheet is not loaded. Because there's no css/ directory in out-website/ Yes, because out-website/index.html is not the real website. Intead, look at out-website/website/index.html ok, I missed that thanks ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: make website and environments variables [WAS: Web glitch]
On Tue, Aug 28, 2012 at 07:11:10PM +0200, Federico Bruni wrote: > I can launch 'make website' now, but the css stylesheet is not loaded. > Because there's no css/ directory in out-website/ Yes, because out-website/index.html is not the real website. Intead, look at out-website/website/index.html - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Regtests
On Wed, Aug 29, 2012 at 01:09:20PM +0100, Phil Holmes wrote: > 2.17.1. The official regtest comparison is against 2.15.38, because > of the vagaries of my initial GUB build. ouch, but not critical in this case. Mike's monster patch changes pretty much everything, so a regtest comparison isn't useful. I mean, it's big enough that it would be more effective to reset the web regtest checker and recruit a new wave of users to evaluate them. In the future, please make sure that the regtests/ directory contains the regtest tarball of the previous version. Just download one from http://lilypond.org/download/binaries/test-output/ > This is spectacularly useless I'll look at the regtests > with my pixel comparator as soon as the upload of 2.17.1 has > completed (so far, 4 hours and counting...) Given Mike's monster, I doubt that the pixel comparator will be useful for 2.17.1. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
preliminary GLISS discussions
At the Waltrop meeting, Janek proposed a number of interesting but potentially disruptive changes to the lilypond syntax. On a personal note, I really like most of them, but it will take a good chunk of work before they're ready to discuss on the main development list. Further complicating issues is that it quickly became apparent that I am not personally qualified to judge if a proposal is ready for main discussion. For example, one idea was to use postfix notation for (almost) everything. David pointed out that this would wreck havok on music functions, and I had to admit that I have no clue what a music function is. I mean, I know that there's \commands, but I have no clue what the difference is between \p, \relative, \staccato; other than their effect on the graphical+midi output. I'm not enthusiastic about cluttering -devel with preliminary discussions like teaching me about music functions vs. whatever the other thing are. At one point there was a mailing list on lilynet for syntax discussions, but I'm not certain if that's active. I could also make a new gnu.org mailing list... but either of those options would require anybody interested in that discussion to sign up for a new mailing list. Thoughts? opinions? alternatives that I haven't considered? These discussions are going to produce a *lot* of emails. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Regtests
2.16.0 versus 2.15.95. Tiny differences in the dots on volta repeat numbers. Nothing else. If anyone wants to see examples, please let me know. 2.17.0 versus 2.16.0. Two major differences which aren't picked up by the general regtest checker. 1) Fret diagrams - the line showing top of the fret bar has changed in landscape mode. 2) Bookparts have lost their page numbers. Unless anyone can convince me that these are deliberate, I'll raise 2 critical regressions for them. See them at http://www.philholmes.net/lilypond/regtestresults/2.17.0/ 2.17.1. The official regtest comparison is against 2.15.38, because of the vagaries of my initial GUB build. This is spectacularly useless I'll look at the regtests with my pixel comparator as soon as the upload of 2.17.1 has completed (so far, 4 hours and counting...) -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: state of GUB and passing Release Meister to Phil
On Tue, Aug 28, 2012 at 11:18 PM, Graham Percival wrote: > (don't see this as me withdrawing from the project; I am now > going to seriously whip the CG into shape and mentor new > contributors. I'll talk more about that in a separate email) Cool! That definitely sounds like +1 for Graham! And +1 for Phil, of course! :) Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
minor GOP2-4 C++ indentation change
After further investiation of astyle at the Waltrop meeting, I've tweaked GOP2-4 - C++ and scheme indentation. Instead of using astyle 2.02 strictly, we will also allow astyle 2.02.1. The later version changes: * bar; into *bar; which matches the way that we format pointers which do not have a . You can see the results in c2489f8f9f47b1740b361366c0b317a799c3a090 - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
applying scheme indentation
As per GOP 2-4 - C++ and scheme indentation, we now have a fixscm.sh in the source tree. Running this was postponed pending Mike's monster skyline patch and possibly some sort of guile 2.0 thing. What's the status of the guile 2.0 patch? In particular, is it safe to run fixscm.sh now, or should that wait until ... ? I've uploaded the results of fixscm.sh: http://codereview.appspot.com/6499050 (I didn't add a code.google.com issue tracker for this) My preference is to push this now, and let Ian (or whoever) run fixscm.sh on their own scheme work. But I'll defer to any scheme experts if they want to delay fixscm.sh by a week or two. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: NR 3.2.1: clarify titles and \header blocks (2652) (issue 6474066)
http://codereview.appspot.com/6474066/diff/5001/Documentation/notation/input.itely
File Documentation/notation/input.itely (right):
http://codereview.appspot.com/6474066/diff/5001/Documentation/notation/input.itely#newcode368
Documentation/notation/input.itely:368: A @code{\header} block. This
sets the global, (i.e. the top of
On 2012/08/29 09:55:04, Graham Percival wrote:
Could I convince you to remove the commas?
Easily! I've removed them already. I'll not bother
posting another patch-set though.
Trevor
http://codereview.appspot.com/6474066/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB upload error
On Wed, Aug 29, 2012 at 11:58:12AM +0200, David Kastrup wrote: > "Phil Holmes" writes: > > Well, actually, I omitted that part of the instruction, since I could > > see my user in group lilypond... > > Your running processes don't change membership. Use > id > to see what the actual memberships are at the moment. Actually, groups gives you a cleaner display of your actual memberships. > What you can see in your system settings is just the starting membership > for new sessions/logins. Yes. Not an important point, though, since the upload is now happening. :) - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB upload error
Graham Percival writes: > On Wed, Aug 29, 2012 at 10:16:18AM +0100, Phil Holmes wrote: >> For reference, I added the new group and added my gub user to that >> group, and the script still barfed. It can't change the properties >> of the files unless it has the permissions to do that, which it >> doesn't. > > Hmm, are you sure you rebooted? Logging in again should be sufficient. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB upload error
"Phil Holmes" writes: > - Original Message - > From: "Graham Percival" > To: "Phil Holmes" > Cc: "Devel" > Sent: Wednesday, August 29, 2012 10:25 AM > Subject: Re: GUB upload error > > >> On Wed, Aug 29, 2012 at 10:16:18AM +0100, Phil Holmes wrote: >>> For reference, I added the new group and added my gub user to that >>> group, and the script still barfed. It can't change the properties >>> of the files unless it has the permissions to do that, which it >>> doesn't. >> >> Hmm, are you sure you rebooted? if your user is in group foo and >> bar, you should be able to change any file that you own to group >> foo or bar with no problems. > > Well, actually, I omitted that part of the instruction, since I could > see my user in group lilypond... Your running processes don't change membership. Use id to see what the actual memberships are at the moment. What you can see in your system settings is just the starting membership for new sessions/logins. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: NR 3.2.1: clarify titles and \header blocks (2652) (issue 6474066)
http://codereview.appspot.com/6474066/diff/5001/Documentation/notation/input.itely
File Documentation/notation/input.itely (right):
http://codereview.appspot.com/6474066/diff/5001/Documentation/notation/input.itely#newcode368
Documentation/notation/input.itely:368: A @code{\header} block. This
sets the global, (i.e. the top of
The combination of a parenthetical comment and a commatical comment
seems quite comedic. Could I convince you to remove the commas?
http://codereview.appspot.com/6474066/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Bump Fontforge version requirement (issue 1637) (issue 6479058)
LGTM, can be pushed directly to staging. http://codereview.appspot.com/6479058/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add support for Cyrillic in Texinfo/TeX (issue 6492045)
LGTM http://codereview.appspot.com/6492045/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Web: add W3C properties of border-*-radius after vendor ones (issue 2784) (issue 6489047)
LGTM, can be pushed directly to staging. http://codereview.appspot.com/6489047/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Bar line interface
Hello list, I just uploaded part 2/2 of the "Great Bar Line Interface Project", see http://codereview.appspot.com/6498052 I hope that it is understandable what I have done, but since the description of the patch is rather short, I'll give an overview: * the input string of a bar line called by \bar "" resembles 1:1 the output, so ":|" would be a repeat colon folllowed by a thin line, nothing else. So a proper repeat sign looks like ":|." from now on. * by (define-bar-line ...) or \defineBarLine one can easily define more bar line styles. these functions have four arguments, namely the bar line itself, the bar line used at the end of line, the bar line used at the begin of a new line and the span bar line. \barLine bar-glyph end-of-line begin-of-line span-bar For example, the repeat sign is defined by (define-bar-line ".|:" "|" ".|:" ".|") * There is the possibity to use annotations for barlines to distinguish between two identical barlines with different break apperance or span bar lines. (define-bar-line "|" "|" "" "|") (define-bar-line "|-withDashedSpanBar" "|" "" "!") The annotation sign is the "-". * To align span bars properly, the space character " " has a special meaning. When it occurs, the width of the resembling glyph in the bar line definition is used. (define-bar-line ":|." ":|." "" " |.") Notice the space in the span bar definition; it inserts an invisible spacer which is as wide as the ":" stencil to make the span bar align properly. * The computation of the bar line anchor has greatly improved (in my opinion). Whereas the former routine used hardcoded string comparison for taking repeat dots into account, the calculation is automated and water-proof (I think). * New glyphs could easily be added, as the regtest shows. The stencil function must have the form (make-...-bar-line grob extent), even if the extent is not used in the drawing process. Most probably this should be documented somewhere, but I didn't want to put this in the patch, because 1) I was too lazy finding the proper place for this 2) I think the patch is big enough without it Regards, Marc ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB upload error
- Original Message - From: "Graham Percival" To: "Phil Holmes" Cc: "Devel" Sent: Wednesday, August 29, 2012 10:25 AM Subject: Re: GUB upload error On Wed, Aug 29, 2012 at 10:16:18AM +0100, Phil Holmes wrote: For reference, I added the new group and added my gub user to that group, and the script still barfed. It can't change the properties of the files unless it has the permissions to do that, which it doesn't. Hmm, are you sure you rebooted? if your user is in group foo and bar, you should be able to change any file that you own to group foo or bar with no problems. Well, actually, I omitted that part of the instruction, since I could see my user in group lilypond... I had to run: sudo chown gub:lilypond -R * to get it going. Whatever works. :) I think that's the unofficial motto of GUB. - Graham -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB upload error
On Wed, Aug 29, 2012 at 10:16:18AM +0100, Phil Holmes wrote: > For reference, I added the new group and added my gub user to that > group, and the script still barfed. It can't change the properties > of the files unless it has the permissions to do that, which it > doesn't. Hmm, are you sure you rebooted? if your user is in group foo and bar, you should be able to change any file that you own to group foo or bar with no problems. > I had to run: > > sudo chown gub:lilypond -R * > > to get it going. Whatever works. :) I think that's the unofficial motto of GUB. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: convert-ly problem
Am 29.08.2012 00:14, schrieb Trevor Daniels: Marc Hohl wrote Tuesday, August 28, 2012 9:56 PM Am 28.08.2012 22:52, schrieb Graham Percival: On Tue, Aug 28, 2012 at 10:45:00PM +0200, Marc Hohl wrote: Am 28.08.2012 20:52, schrieb David Kastrup: Marc Hohl writes: After searching a bit more, git grep blank-page-force shows several hits, but in 2.17.x, this should read blank-page-penalty, so I assume when master gets updated, then the convert rules should be applied, or am I totally on the wrong track? apparently somebody wrote the rule but did not bother to run update-with-convert-ly and committing the result before making a release. So can/shall I do something to correct this? I think this should be fixed quite soon, otherwise 'make doc' will fail for every language other than english, IIUC. If there's syntax that hasn't been updated with update-with-convert-ly, then it should definitely be updated. However, apparently it didn't cause "make doc" to fail, since 2.17.0 and 2.17.1 have been built. (?) Regardless of that, please run update-with-convert-ly. Assuming the diff looks reasonable, please push directly to staging. But do manually check the diff (with gitk or any other git tool). Oh, this went parallel to me generating a rietveld patch. Can you have a quick glance at it? Afterwards, I'll push to staging. Marc, I've just logged on and seen this thread. The fault is mine. I wrote the convert-ly rule, but omitted to follow it up with update-with-convert-ly. I'm sorry about that. It was my first convert-ly rule and foolishly I didn't check the CG to see what should be done. Many thanks for fixing it for me. No problem, really. Glad that I could help so easily. And in the forthcoming patch for bar lines, I also wrote a convert-ly rule for the first time. I hope that all will be fine ;-) Regards, Marc Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB upload error
- Original Message - From: "Graham Percival" To: "Phil Holmes" Cc: "Devel" Sent: Tuesday, August 28, 2012 7:15 PM Subject: Re: GUB upload error On Tue, Aug 28, 2012 at 03:43:40PM +0100, Phil Holmes wrote: gub@gub-virtualbox:~/gub$ make lilypond-upload LILYPOND_BRANCH=release/unstable LILYPOND_REPO_URL=git://git.sv.gnu.org/lilypond.git chgrp -R lilypond uploads/lilypond* chgrp: invalid group: `lilypond' right, oops. You need to make a lilypond group on your computer, and almost certainly add your user to it. I think the commands are: addgroup lilypond gub (to add the user "gub" to the "lilypond" group, and I think it automatically makes a new group) Then reboot to make sure the change takes effect. - Graham OK - looks like we're now uploading. It'll take a while over DSL. I may need to move house to get to a fibre-equipped property For reference, I added the new group and added my gub user to that group, and the script still barfed. It can't change the properties of the files unless it has the permissions to do that, which it doesn't. I had to run: sudo chown gub:lilypond -R * to get it going. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Bug in guile?
David Kastrup writes: > "m...@mikesolomon.org" writes: > >> Hey all, >> >> Could someone well-versed in guile try running primitive-load-path on >> the attached file with and without the last line commented. Without >> the last line commented, on my machine, I get: >> >> guile> (primitive-load-path "/home/mikesol/pleasework.lyaux") >> >> Backtrace: >> In standard input: >>1: 0* [primitive-load-path "/home/mikesol/pleasework.lyaux"] >> >> standard input:1:1: In procedure string->number in expression >> (primitive-load-path "/home/mikesol/pleasework.lyaux"): >> standard input:1:1: Value out of range: 461 >> >> However, with the last line commented, everything works ok. This >> seems like a bug in Guile, but I wanna make sure that my input doesn't >> seem off before I report it to the list. >> >> Cheers, >> MS >> >> >> (define my-hash (make-hash-table 100)) >> (hashq-set! my-hash >> ae7d8fe61e91281e447a9e8c354114387284e14a0b4f3af8f392e1c9a943bd837ffb863f0602af >> 7.45493) > > Uh, you are aware _how_ one writes hexadecimal constants in Scheme? > They start with #x. I am surprised you should get an error only on the > last line. > > The lack of an error might be worth investigating _if_ it is > reproducible. And by the way: don't use hashq-set! on numbers: the result is undefined. You need to use hashv-set! to have equal values reliably map to the same hash bucket. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Bug in guile?
"m...@mikesolomon.org" writes: > Hey all, > > Could someone well-versed in guile try running primitive-load-path on > the attached file with and without the last line commented. Without > the last line commented, on my machine, I get: > > guile> (primitive-load-path "/home/mikesol/pleasework.lyaux") > > Backtrace: > In standard input: >1: 0* [primitive-load-path "/home/mikesol/pleasework.lyaux"] > > standard input:1:1: In procedure string->number in expression > (primitive-load-path "/home/mikesol/pleasework.lyaux"): > standard input:1:1: Value out of range: 461 > > However, with the last line commented, everything works ok. This > seems like a bug in Guile, but I wanna make sure that my input doesn't > seem off before I report it to the list. > > Cheers, > MS > > > (define my-hash (make-hash-table 100)) > (hashq-set! my-hash > ae7d8fe61e91281e447a9e8c354114387284e14a0b4f3af8f392e1c9a943bd837ffb863f0602af > 7.45493) Uh, you are aware _how_ one writes hexadecimal constants in Scheme? They start with #x. I am surprised you should get an error only on the last line. The lack of an error might be worth investigating _if_ it is reproducible. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: The currently still assembled part of the team in Waltrop
"Trevor Daniels" writes: >> Note the project lead being on the high horse after having wrapped up >> the 2.17.0 release for good. > > Thanks for the photo. Not as good as being there, but really nice to see. > > I know Graham and I think I can recognise you, David, but it would > be good to be able to put names to the other faces. I see Jan has > left already, or is he behind the camera? He left on the previous day, in weather conditions not favoring outdoor photographs. From left to right, this is Fridolin and David, Julien and Patrick from the Philomelos project, Rodolfo, Mike, John, Janek, Graham on top of Winni, and Conny, the principal, teacher, horse trainer and farm hand of the riding school. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Bug in guile?
Hey all, Could someone well-versed in guile try running primitive-load-path on the attached file with and without the last line commented. Without the last line commented, on my machine, I get: guile> (primitive-load-path "/home/mikesol/pleasework.lyaux") Backtrace: In standard input: 1: 0* [primitive-load-path "/home/mikesol/pleasework.lyaux"] standard input:1:1: In procedure string->number in expression (primitive-load-path "/home/mikesol/pleasework.lyaux"): standard input:1:1: Value out of range: 461 However, with the last line commented, everything works ok. This seems like a bug in Guile, but I wanna make sure that my input doesn't seem off before I report it to the list. Cheers, MS pleasework.lyaux Description: Binary data ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
