more code-cleanup patches
Are these two patches okay to apply?
I have a question about the second one.
Starting on line 845 in define-grob-properties.scm, there is a group
labeled "grobs & grob arrays", and of the 60 or so properties there, all
of them have type ly:grob or ly:grob-array, except the following nine.
Should these nine properties be moved to the section labeled "other"
starting on line 951?
;; grobs & grob arrays. (alphabetical)
(accidental-grobs ,list? "An alist with @code{(@var{notename} .
@var{groblist})} entries.")
(adjacent-pure-heights ,pair? "A pair of vectors. Used by a
@code{VerticalAxisGroup} to cache the @code{Y-extent}s of different column
ranges.")
(bar-extent ,number-pair? "The Y-extent of the actual bar line.
This may differ from @code{Y-extent} because it does not include the dots in
a repeat bar line.")
(cross-staff ,boolean? "For a beam or a stem, this is true if we
depend on inter-staff spacing.")
(forced ,boolean? "Manually forced accidental.")
(glyph-name ,string? "The glyph name within the font.")
(important-column-ranks ,vector? "A cache of columns that contain
@code{items-worth-living} data.")
(note-columns ,pair? "A list of @code{NoteColumn} grobs.")
(pure-Y-offset-in-progress ,boolean? "A debugging aid for catching
cyclic dependencies.")
Thanks.
- Mark
0001-define-context-properties.scm-Sort-translation-prope.patch
Description: Binary data
0002-define-grob-properties.scm-Sort-user-and-internal-gr.patch
Description: Binary data
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Size of test output binaries has doubled
On Sat, Jul 18, 2009 at 09:14:40PM -0600, Carl Sorensen wrote: > In preparing information on regression testing for the Contributors' Guide, > I happened to check the downloadable regression test results at > > http://lilypond.org/download/binaries/test-output/ > > I noticed that prior to 2.13.2 the test results were approximately 70-80 MB. > > For 2.13.2 and 2.13.3, the results are approximately 136 MB. > > Is this an intended (or understood) behavior, or is it a bug of some sort? Well, it happened when I started making releases. We /have/ been adding a lot of regtests recently, but I don't imagine that there were _that_ many between .1 and .2. My initial guesses: - GUB uses the system's convert (imagemagick) or pnmtopng or something like that, and kainhofer has a different version of those files than Han-Wen's system. (and the other version has poorer compresson) - 64-bit CPUs naturally produce larger png files. (hey, I didn't say these were all *good* guess. ;) - Seriously: GUB might be adding extra files to the tarball... maybe a "make clean" somewhere is failing, resulting in a bunch of intermediate files being included? I'd encourage any interested parties to compare the files in the .1 and later tarballs, and to compare the filesizes. Remote debugging from Vancouver to Germany is a pain, and in any case I'm at a music camp starting in 12 hours, so I won't be looking at this soon. (if it's still a problem in Sep, I should have a desktop computer available, so debugging GUB will be *much* easier) The steps I take are outlined at the end of Documentation/devel/release-notes.itexi, with the following additions: - checkout commit c1645812f5c2707640961085cdccc77d27dffccb (later versions seem to have some instability with git downloads) - apply the attached patch. Yes, it's a marvel of bad python, but I couldn't change m.group(2) or find out how to make a new "group" (or whatever variable type m is) within 10 minutes. (random python annoyance: when I do "print m", I want information about that variable. Don't tell me a memory address or something like that -- that's what perl would do!) better solution: revert change to output -HEAD instead of -1 (or whatever the build number is). Patches appreciated. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Size of test output binaries has doubled
On Sun, Jul 19, 2009 at 12:18:41PM +0200, John Mandereau wrote:
> Le dimanche 19 juillet 2009 à 02:07 -0700, Graham Percival a écrit :
> > - apply the attached patch.
>
> I (and probably other readers) miss the attachment.
Oops, sorry. I subconsciously tried to protect your eyes by not
attaching it. :)
The horror is attached now.
Cheers,
- Graham
diff --git a/test-lily/rsync-test.py b/test-lily/rsync-test.py
index c7ac423..fa855f0 100644
--- a/test-lily/rsync-test.py
+++ b/test-lily/rsync-test.py
@@ -149,12 +149,21 @@ def compare_test_info (options):
current_test_output = ''
for f in outputs:
m = re.search ('lilypond-([.0-9]+)-([0-9]+).test-output.tar.bz2', f)
+ishead = 0
+if not m:
+m = re.search ('lilypond-([.0-9]+)-(HEAD).test-output.tar.bz2', f)
+# ugly hack for "latest version"
+#m.group(2) = 999## doesn't work; can't modify a group
+ishead = 1
if not m:
printf (f)
assert 0
version = list (map (int, m.group (1).split ('.')))
-build = int (m.group (2))
+if ishead:
+build = 999
+else:
+build = int (m.group (2))
tup = (version, build)
if tup <= current_tuple:
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: accessing accidentals with \tweak
2009/7/18 Carl Sorensen : > Thanks for your creativity! Could said "creativity" give birth to a LSR snippet as well? :-) Regards, Valentin ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Fw: Understanding the processing model
(forwarded from -user) Martin Hosken wrote: > Is there any documentation that explains more of the internal workings > of lilypond. I'm looking for something that explains how music events > get to engravers and then what happens afterwards with the layout > events. 'When' are stencils executed? Is it possible to write an > engraver in scm? > > I am managing to get somewhere with writing scheme code to do what I > want, but the effects are usually more through luck than judgement: I > write something expecting something to happen and it doesn't so I have > to write it a different way. I think if I understood the overall > processing of events better from music events through to output events > and when things execute, I could do a whole lot better. +1 - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: more code-cleanup patches
2009/7/19 Mark Polesky :
> Are these two patches okay to apply?
LGTM.
> Starting on line 845 in define-grob-properties.scm, there is a group
> labeled "grobs & grob arrays", and of the 60 or so properties there, all
> of them have type ly:grob or ly:grob-array, except the following nine.
> Should these nine properties be moved to the section labeled "other"
> starting on line 951?
I would leave these two since they involve lists of grobs:
> (accidental-grobs ,list? "An alist with @code{(@var{notename} .
> @var{groblist})} entries.")
> (note-columns ,pair? "A list of @code{NoteColumn} grobs.")
You can move the following to user properties, since it is
user-serviceable (as shown by Marc's new tablature implementation):
> (glyph-name ,string? "The glyph name within the font.")
I'm fine with moving the rest.
Regards,
Neil
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: more code-cleanup patches
Okay, following the combined suggestions of Neil and Joe, I made these changes to the define-grob-properties patch: 1) keep in "grobs & grob arrays." section, unmodified: * (accidental-grobs ,list? ...) 2) keep in "grobs & grob arrays." section, but change type: * (note-columns ,ly:grob-array? ...) ;; type was pair? 3) move to "other" section: * (adjacent-pure-heights ,pair? ...) * (bar-extent ,number-pair? ...) * (cross-staff ,boolean? ...) * (forced ,boolean? ...) * (important-column-ranks ,vector? ...) * (pure-Y-offset-in-progress ,boolean? ...) 4) move from all-internal-grob-properties to all-user-grob-properties: * (glyph-name ,string? ...) I attached the updated patch. Okay to apply? - Mark 0002-define-grob-properties.scm-Sort-user-and-internal-pr.patch Description: Binary data ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: (c) does not equal "copyright"
On Sat, Jul 18, 2009, Hans Aberg said: > ask them to provide proof that you were the > clicker. can we afford to pay the legal fees associated with the asking of that question in court? Why waste time debateing? find a willing tadpole and turn them loose. -- Dana Emery ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fw: Understanding the processing model
On Sun, Jul 19, 2009 at 08:31:59AM -0700, Mark Polesky wrote: > > (forwarded from -user) > > Martin Hosken wrote: > > Is there any documentation that explains more of the internal workings > > of lilypond. I'm looking for something that explains how music events > > get to engravers and then what happens afterwards with the layout > > events. 'When' are stencils executed? Is it possible to write an > > engraver in scm? > > +1 Erik Sandberg's thesis. IIRC it's somewhere on one of the Publications pages. In the new website, it's in Community->Publications, and may well get linked to from the CG. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fw: Understanding the processing model
On Sun, Jul 19, 2009 at 11:58 AM, Graham Percival wrote: > On Sun, Jul 19, 2009 at 08:31:59AM -0700, Mark Polesky wrote: >> >> (forwarded from -user) >> >> Martin Hosken wrote: >> > Is there any documentation that explains more of the internal workings >> > of lilypond. I'm looking for something that explains how music events >> > get to engravers and then what happens afterwards with the layout >> > events. 'When' are stencils executed? Is it possible to write an >> > engraver in scm? >> >> +1 > > Erik Sandberg's thesis. IIRC it's somewhere on one of the > Publications pages. > > In the new website, it's in Community->Publications, and may well > get linked to from the CG. Yes, Erik's thesis is a great resource, but IIRC it only explains the first part of the process in detail, and only briefly mentions the role of the engravers. There is no mention of the order-of-operations within an engraver, the acknowledging process, the grob->stencil conversion, etc. (Yes, I plan on eventually documenting all of this in the CG once I figure it out.) -Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: (c) does not equal "copyright"
On 19 Jul 2009, at 19:52, > wrote: ask them to provide proof that you were the clicker. can we afford to pay the legal fees associated with the asking of that question in court? Only in fair justice systems... Why waste time debateing? find a willing tadpole and turn them loose. ...there are of course precedents. Hans ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Understanding the processing model
On 7/19/09 12:58 PM, "Graham Percival" wrote: > On Sun, Jul 19, 2009 at 08:31:59AM -0700, Mark Polesky wrote: >> >> (forwarded from -user) >> >> Martin Hosken wrote: >>> Is there any documentation that explains more of the internal workings >>> of lilypond. I'm looking for something that explains how music events >>> get to engravers and then what happens afterwards with the layout >>> events. 'When' are stencils executed? Is it possible to write an >>> engraver in scm? >> >> +1 > > Erik Sandberg's thesis. IIRC it's somewhere on one of the > Publications pages. > > In the new website, it's in Community->Publications, and may well > get linked to from the CG. CG 8.1, with link to Erik's thesis. The problem with this is that it only really describes the parsing and iterating stages; the translation step is just so much hand waving. It wasn't until last week that I demonstrated to myself how parsing and translating were separated. I was debugging time-signature setting and I demonstrated that all the music was parsed (by using display-music scheme printouts) before any of it was translated (by displaying values in code execution). I had heard about it before, but it made more sense after my debugging efforts. A well-written, simple introduction to the translation step accomplished by translators or engravers would be a major help to understanding how to modify LilyPond. Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
