Re: Variations on the theme "The remote end hung up unexpectedly"
On Dec 27, 2011, at 11:44 PM, David Kastrup wrote: > "m...@apollinemike.com" writes: > >> Hey all, >> >> I've been getting the following message for current master for a day-ish now: >> >> ssh: Could not resolve hostname git.sv.gnu.org: Name or service not known >> fatal: The remote end hung up unexpectedly >> >> I'm downloading staging just fine, however. >> >> I'm not using the newest LilyDev and I'm not exactly how to check the >> keyring. Any help would be appreciated! >> >> Here's my .git/config file: >> >> [core] >> repositoryformatversion = 0 >> filemode = true >> bare = false >> logallrefupdates = true >> [remote "origin"] >> fetch = +refs/heads/*:refs/remotes/origin/* >> url = ssh://git.sv.gnu.org/srv/git/lilypond.git >> fetch = +refs/heads/staging:refs/remotes/origin/staging > > Maybe move the url line above the first fetch line? > Resolved after a power cycle. I had shut my vBox down before, but apparently it needed a second shutting down. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Sooo sorry!
Folks, I'm very sorry to just have pushed a Makefile fix directly to `master' instead of `staging'. My fingers were faster than my brain. Am I right if I suppose that it's best to just wait for your cursing and doing nothing else otherwise? Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Sooo sorry!
Werner LEMBERG writes: > Folks, > > > I'm very sorry to just have pushed a Makefile fix directly to `master' > instead of `staging'. My fingers were faster than my brain. > > Am I right if I suppose that it's best to just wait for your cursing > and doing nothing else otherwise? Well, since master was luckily strictly ahead of staging, I bounced staging to be in synch. The problem we are having now is just that your fix has not seen Patchy. I have taken a look, and it looks unlikely to have unexpected side effects. So there will likely be no problem. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Sooo sorry!
>> Am I right if I suppose that it's best to just wait for your >> cursing and doing nothing else otherwise? > > Well, since master was luckily strictly ahead of staging, I bounced > staging to be in synch. Thanks! > The problem we are having now is just that your fix has not seen > Patchy. I have taken a look, and it looks unlikely to have > unexpected side effects. So there will likely be no problem. Actually, I wasn't able to compile master without that patch: `make all' aborted with In file included from parse-scm.cc:26:0: ./include/lily-lexer.hh:28:21: fatal error: parser.hh: No such file or directory Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Sooo sorry!
Werner LEMBERG writes: >>> Am I right if I suppose that it's best to just wait for your >>> cursing and doing nothing else otherwise? >> >> Well, since master was luckily strictly ahead of staging, I bounced >> staging to be in synch. > > Thanks! > >> The problem we are having now is just that your fix has not seen >> Patchy. I have taken a look, and it looks unlikely to have >> unexpected side effects. So there will likely be no problem. > > Actually, I wasn't able to compile master without that patch: `make > all' aborted with > > In file included from parse-scm.cc:26:0: > ./include/lily-lexer.hh:28:21: fatal error: parser.hh: No such file or > directory More likely `make -j3 all'... I suspected as much seeing your patch. parser.hh and parser.cc are generated independently since ae9b8d637bae923bf8069f5e0f9bdb327bb98559, and it would appear that I have overlooked dependencies arising from f7437fd4f26ab6ca5b2814f08938d66c80544ed2. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Avoids TupletBracket-Fingering and TupletBracket-StringNumber collisions. (issue 5505079)
Reviewers: ,
Message:
Note that this applies only to staging until the next fast-forward of
master.
Cheers,
MS
Description:
Avoids TupletBracket-Fingering and TupletBracket-StringNumber
collisions.
Please review this at http://codereview.appspot.com/5505079/
Affected files:
A input/regression/tuplet-bracket-avoid-fingering.ly
A input/regression/tuplet-bracket-avoid-string-number.ly
M lily/tuplet-engraver.cc
Index: input/regression/tuplet-bracket-avoid-fingering.ly
diff --git a/input/regression/tuplet-bracket-avoid-fingering.ly
b/input/regression/tuplet-bracket-avoid-fingering.ly
new file mode 100644
index
..570d9d783d0ed83b91303f1e26dace45f3be0874
--- /dev/null
+++ b/input/regression/tuplet-bracket-avoid-fingering.ly
@@ -0,0 +1,12 @@
+\version "2.15.24"
+
+\header {
+ texidoc = "@code{TupletBracket} grobs avoid @code{Fingering} grobs.
+"
+}
+
+\relative d'' {
+ \override TupletBracket #'direction = #UP
+ \times 2/3 { d4 a8-4 }
+}
+
Index: input/regression/tuplet-bracket-avoid-string-number.ly
diff --git a/input/regression/tuplet-bracket-avoid-string-number.ly
b/input/regression/tuplet-bracket-avoid-string-number.ly
new file mode 100644
index
..4a1b797b9fe1506b6940d03f896d970cb470101d
--- /dev/null
+++ b/input/regression/tuplet-bracket-avoid-string-number.ly
@@ -0,0 +1,12 @@
+\version "2.15.24"
+
+\header {
+ texidoc = "@code{TupletBracket} grobs avoid @code{StringNumber} grobs.
+"
+}
+
+\relative d'' {
+ \override TupletBracket #'direction = #UP
+ \times 2/3 { d4 8 }
+}
+
Index: lily/tuplet-engraver.cc
diff --git a/lily/tuplet-engraver.cc b/lily/tuplet-engraver.cc
index
9ff42cad61ffad3731474952fa7cf3b8a9cf4352..a99369ccd78c4a883b42d51a57080cb1182a0c89
100644
--- a/lily/tuplet-engraver.cc
+++ b/lily/tuplet-engraver.cc
@@ -65,6 +65,8 @@ protected:
DECLARE_ACKNOWLEDGER (note_column);
DECLARE_ACKNOWLEDGER (script);
+ DECLARE_ACKNOWLEDGER (finger);
+ DECLARE_ACKNOWLEDGER (string_number);
DECLARE_TRANSLATOR_LISTENER (tuplet_span);
virtual void finalize ();
void start_translation_timestep ();
@@ -220,6 +222,28 @@ Tuplet_engraver::acknowledge_script (Grob_info inf)
}
void
+Tuplet_engraver::acknowledge_finger (Grob_info inf)
+{
+ for (vsize j = 0; j < tuplets_.size (); j++)
+if (tuplets_[j].bracket_)
+ {
+Item *i = dynamic_cast (inf.grob ());
+Tuplet_bracket::add_script (tuplets_[j].bracket_, i);
+ }
+}
+
+void
+Tuplet_engraver::acknowledge_string_number (Grob_info inf)
+{
+ for (vsize j = 0; j < tuplets_.size (); j++)
+if (tuplets_[j].bracket_)
+ {
+Item *i = dynamic_cast (inf.grob ());
+Tuplet_bracket::add_script (tuplets_[j].bracket_, i);
+ }
+}
+
+void
Tuplet_engraver::start_translation_timestep ()
{
last_tuplets_.clear ();
@@ -246,6 +270,8 @@ Tuplet_engraver::Tuplet_engraver ()
ADD_ACKNOWLEDGER (Tuplet_engraver, note_column);
ADD_ACKNOWLEDGER (Tuplet_engraver, script);
+ADD_ACKNOWLEDGER (Tuplet_engraver, finger);
+ADD_ACKNOWLEDGER (Tuplet_engraver, string_number);
ADD_TRANSLATOR (Tuplet_engraver,
/* doc */
"Catch tuplet events and generate appropriate bracket.",
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Sooo sorry!
>> In file included from parse-scm.cc:26:0: >> ./include/lily-lexer.hh:28:21: fatal error: parser.hh: No such file or >> directory > > More likely `make -j3 all'... No, it was a single threaded make call -- I always divert both stdin and stdout of `make all' to a file, and with -j3 this output would be much harder to read. BTW, in older GNU make versions, files were processed alphabetically, but this is no longer the case. It seems that my GNU make 3.82 accidentally selected a processing order which triggered the problem. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Sooo sorry!
Werner LEMBERG writes:
>>> In file included from parse-scm.cc:26:0:
>>> ./include/lily-lexer.hh:28:21: fatal error: parser.hh: No such
>>> file or directory
>>
>> More likely `make -j3 all'...
>
> No, it was a single threaded make call -- I always divert both stdin
> and stdout of `make all' to a file, and with -j3 this output would be
> much harder to read.
>
> BTW, in older GNU make versions, files were processed alphabetically,
> but this is no longer the case. It seems that my GNU make 3.82
> accidentally selected a processing order which triggered the problem.
Or mine one which didn't. I _did_ use make -j3 for the tests before
committing the fix just to make somewhat sure that a multijob make would
not accidentally suffer, and it might just be that this left the
single-job variant untested.
Ugh. Perhaps I should just cater for the single-job variants and let
others sort out the rest. Though -j3 actually does seem to help a bit
here ("plenty" of memory, laptop disk).
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Give slurs skylines in outside-staff-priority calculations. (issue 5504055)
On Dec 25, 2011, at 10:50 PM, Janek Warchoł wrote: > Hi Mike, > > (i've come back finally) When i was thinking about LilyPond lately, i > decided that changing character outlines from boxes to something more > precise was perhaps the most important thing we should improve now - > and i see that you are working on this! Great! > My (quick) question is: would be easy to apply your solution to other > objects? I know that lyrics and dynamics really need improvement in > this area too - see this example: http://www.sendspace.com/file/dm4ua2 > (source is attached to pdf). > > Many thanks! > Janek Hey Janek, Welcome back! Vertical skylines are useful for any object whose height changes appreciably over its horizontal span. Slurs (sometimes) fall into this category. Accidentals fall into this category as well and have been dealt with similarly (I don't know who wrote the code, but there is code in accidental.cc to get a boxed approximation of an accidental's form). I am not sure that dynamics and lyrics have subtleties in their shape that could be better approximated by the use of boxes (perhaps dynamics more than lyrics as they are slanted, but I'm dubious of this). To fix the problem, it'll be necessary to cook up a few minimal examples showing each problem (ideally with lines that can be commented out to trigger the problem). Once you have this, we'll be able to find the cause rather quickly. I suspect that the issue arises from too-generous pure height approximations and/or oddities in inter-staff vertical spacing, so boxes are likely not the solution. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Give slurs skylines in outside-staff-priority calculations. (issue 5504055)
> I am not sure that dynamics and lyrics have subtleties in their shape that could be better approximated by the use of boxes (perhaps dynamics more than lyrics as they are slanted, but I'm dubious of this). You might also have a look at issue #1097. Should be almost trivial for you :-) Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Give slurs skylines in outside-staff-priority calculations. (issue 5504055)
On Dec 28, 2011, at 11:49 AM, Werner LEMBERG wrote: > >> I am not sure that dynamics and lyrics have subtleties in their > shape that could be better approximated by the use of boxes (perhaps > dynamics more than lyrics as they are slanted, but I'm dubious of > this). > > You might also have a look at issue #1097. Should be almost trivial > for you :-) > More "almost" than "trivial" :-) What makes it complicated is that the tuplet-bracket stencil function is embedded in all sorts of print functions that make harvesting its data a bit tricky. I'll chip away at it over the next few days when I have time & throw something up on Reitveld. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Give slurs skylines in outside-staff-priority calculations. (issue 5504055)
On Dec 28, 2011, at 3:41 AM, "m...@apollinemike.com" wrote: > > On Dec 25, 2011, at 10:50 PM, Janek Warchoł wrote: > >> Hi Mike, >> >> (i've come back finally) When i was thinking about LilyPond lately, i >> decided that changing character outlines from boxes to something more >> precise was perhaps the most important thing we should improve now - >> and i see that you are working on this! Great! >> My (quick) question is: would be easy to apply your solution to other >> objects? I know that lyrics and dynamics really need improvement in >> this area too - see this example: http://www.sendspace.com/file/dm4ua2 >> (source is attached to pdf). >> >> Many thanks! >> Janek > > Hey Janek, > > Welcome back! > > Vertical skylines are useful for any object whose height changes appreciably > over its horizontal span. Slurs (sometimes) fall into this category. > Accidentals fall into this category as well and have been dealt with > similarly (I don't know who wrote the code, but there is code in > accidental.cc to get a boxed approximation of an accidental's form). > > I am not sure that dynamics and lyrics have subtleties in their shape that > could be better approximated by the use of boxes (perhaps dynamics more than > lyrics as they are slanted, but I'm dubious of this). > > To fix the problem, it'll be necessary to cook up a few minimal examples > showing each problem (ideally with lines that can be commented out to trigger > the problem). Once you have this, we'll be able to find the cause rather > quickly. I suspect that the issue arises from too-generous pure height > approximations and/or oddities in inter-staff vertical spacing, so boxes are > likely not the solution. > Looking at Janek's examples, there are places where a hairpin could go closer to the notes if it didn't have a rectangular skyline the size of the large end. There are also places that the lyrics could go closer if the extended used a skyline that had its tiny height instead of the character box height. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Variations on the theme "The remote end hung up unexpectedly"
- Original Message - From: To: "lilypond-devel Development" Sent: Tuesday, December 27, 2011 10:25 PM Subject: Variations on the theme "The remote end hung up unexpectedly" Hey all, I've been getting the following message for current master for a day-ish now: ssh: Could not resolve hostname git.sv.gnu.org: Name or service not known fatal: The remote end hung up unexpectedly For reference, the clue to this one is in the first line: "Could not resolve hostname git.sv.gnu.org". ssh is trying to resolve the git.sv.gnu.org hostname into an IP address and failing. It means there's something fundamentally wrong with the network on your computer - either DNS is screwed or you've no external network access. I'd expect browsing and email to fail, too. I know it's now fixed, but if you do see the "Could not resolve" message, suspect your network, not git. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Error: Illegal entry in bfrange block in ToUnicode CMap
- Original Message -
From: "Jean-Charles Malahieude"
To: "Phil Holmes"
Cc: "Devel"
Sent: Tuesday, December 27, 2011 7:29 PM
Subject: Re: Error: Illegal entry in bfrange block in ToUnicode CMap
Le 27/12/2011 18:14, Phil Holmes disait :
More looking at make doc output. This set of error messages ("Error:
Illegal entry in bfrange block in ToUnicode CMap") has been discussed
before, and it's not a Lilypond issue, it's to do with texi2pdf on
Ubuntu. Nevertheless, it does litter the output of make doc with
hundreds of error lines, which isn't good. A prime culprit is
notation, and the errors come from 2 parts of the documentation:
3.3.3, where we're supposed to be showing Cyrillic, and the list of
special characters in Appendix A11.
If you check a PDF for 3.3.3 you'll see that the Cyrillic isn't even
there, and ditto the special characters: № is missing (twice)
as well as &ng; and &NG;. It looks like they not only cause an error,
they don't get generated at all, which makes the PDF docs look odd.
I cannot help, but just to inform that I encounter the same behavior on
my Fedora 15 box with a fresh build. I don't get the error message, but
Cyrillic characters are absent of the pdf -- by the way, the right most
column doesn't appear in the appendix.
Cheers,
Jean-Charles
Thanks. I'm looking at a fix to get the columns to fit the page.
--
Phil Holmes
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Give slurs skylines in outside-staff-priority calculations. (issue 5504055)
On 28/12/2011 11:40, m...@apollinemike.com wrote:
> On Dec 25, 2011, at 10:50 PM, Janek Warchoł wrote:
> Vertical skylines are useful for any object whose height changes appreciably
> over its horizontal span. Slurs (sometimes) fall into this category.
> Accidentals fall into this category as well and have been dealt with
> similarly (I don't know who wrote the code, but there is code in
> accidental.cc to get a boxed approximation of an accidental's form).
>
> I am not sure that dynamics and lyrics have subtleties in their shape that
> could be better approximated by the use of boxes (perhaps dynamics more than
> lyrics as they are slanted, but I'm dubious of this).
>
> To fix the problem, it'll be necessary to cook up a few minimal examples
> showing each problem (ideally with lines that can be commented out to trigger
> the problem). Once you have this, we'll be able to find the cause rather
> quickly. I suspect that the issue arises from too-generous pure height
> approximations and/or oddities in inter-staff vertical spacing, so boxes are
> likely not the solution.
Another situation is that center-aligned barnumbers (right-aligned
barnumers simply look ugly for >100 bars) are shifted upwards by the
rectangular box of the treble clef, even though no collision would occur
at all. Simple example is attached.
Cheers,
Reinhold
--
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/
* Financial & Actuarial Math., Vienna Univ. of Technology, Austria
* http://www.fam.tuwien.ac.at/, DVR: 0005886
* LilyPond, Music typesetting, http://www.lilypond.org
\version "2.15.24"
\relative c'' {
\override Score.BarNumber #'self-alignment-X = #CENTER
\repeat unfold 5 { c1 c1 c1 | \break }
}
treble_clef_barnumber.pdf
Description: Adobe PDF document
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Fixes width of NR A.11 - List of special character (issue 5504091)
Reviewers: Bertrand Bordage, J_lowe, percivall,
Message:
Please review
Description:
At present, the NR section A.11 has a table which flows off the side of
the PDF page. This patch fixes that, with the table reduced to 4
columns rather than 5.
Please review this at http://codereview.appspot.com/5504091/
Affected files:
M Documentation/included/special-characters.ly
Index: Documentation/included/special-characters.ly
diff --git a/Documentation/included/special-characters.ly
b/Documentation/included/special-characters.ly
index
447e2c8a4f33686a8faff586e32042070956dc79..1576a83dbfc09d192ce7c51a8d1e431cc52bbde4
100644
--- a/Documentation/included/special-characters.ly
+++ b/Documentation/included/special-characters.ly
@@ -1,6 +1,5 @@
\version "2.15.17"
-#(set-default-paper-size "a4")
\paper {
#(include-special-characters)
}
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixes width of NR A.11 - List of special character (issue 5504091)
LGTM. http://codereview.appspot.com/5504091/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Give slurs skylines in outside-staff-priority calculations. (issue 5504055)
2011/12/28 m...@apollinemike.com : > > On Dec 25, 2011, at 10:50 PM, Janek Warchoł wrote: >> My (quick) question is: would be easy to apply your solution to other >> objects? I know that lyrics and dynamics really need improvement in >> this area too - see this example: http://www.sendspace.com/file/dm4ua2 >> (source is attached to pdf). > > Vertical skylines are useful for any object whose height changes > appreciably over its horizontal span. Slurs (sometimes) fall into this > category. > Accidentals fall into this category as well and have been dealt with similarly > (I don't know who wrote the code, but there is code in accidental.cc > to get a boxed approximation of an accidental's form). Indeed; i've seen that code. However, it could use some improvement, as can be seen in http://code.google.com/p/lilypond/issues/detail?id=2141 . > I am not sure that dynamics and lyrics have subtleties in their shape > that could be better approximated by the use of boxes (perhaps dynamics > more than lyrics as they are slanted, but I'm dubious of this). There might be a better solution, but they could be done better even with subdivided boxes, as can be seen by examining the example i linked to. > To fix the problem, it'll be necessary to cook up a few minimal examples > showing each problem (ideally with lines that can be commented out to trigger > the problem). Done! Examples are attached to issue 2148 http://code.google.com/p/lilypond/issues/detail?id=2148 By the way, i'm attaching examples in pdf format rather than png, because this gives me unlimited resolution (and i can attach Lily source code inside pdf). Do you like it or are pngs better? > Once you have this, we'll be able to find the cause rather quickly. > I suspect that the issue arises from too-generous pure height approximations > and/or oddities in inter-staff vertical spacing, so boxes are likely not the > solution. Um, i think the cause is simpler than that :) 2011/12/28 Werner LEMBERG : > >> I am not sure that dynamics and lyrics have subtleties in their >> shape that could be better approximated by the use of boxes (perhaps >> dynamics more than lyrics as they are slanted, but I'm dubious of >> this). > > You might also have a look at issue #1097. Should be almost trivial > for you :-) It would be great to fix this too! You know, one thing comes to my mind: should we really use boxes for all sorts of collision calculations? I think it would give much better results it we calculated real distance between objects (i.e. between black areas). We know the outlines of font glyphs, the real shape of slur... Could we implement a global "metric" for measuring distances between objects? My friend Łukasz (Luke) thinks this should be the way to go. W dniu 28 grudnia 2011 13:01 użytkownik Carl Sorensen napisał: > Looking at Janek's examples, there are places where a hairpin could go closer > to the notes > if it didn't have a rectangular skyline the size of the large end. There are > also places > that the lyrics could go closer if the extended used a skyline that had its > tiny height > instead of the character box height. Exactly. 2011/12/28 Reinhold Kainhofer : > Another situation is that center-aligned barnumbers (right-aligned > barnumers simply look ugly for >100 bars) are shifted upwards by the > rectangular box of the treble clef, even though no collision would occur > at all. Thank you for a nice example, i've used it in issue 2148. cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Glyphs for Kievan Notation (issue 4951062)
2011/12/27 Aleksandr Andreev : > Hi Janek, > > Good to hear that you are back. > > The issues that Bertrand and others were raising have all been addressed. > > In addition, I've been able to implement a few other features > (Parentheses to offset optional melisma, different shapes for the half > notes, and the final barlien). Great! Congratulations :) > Right now, I am trying to work on the following features: getting the > final note to be flush and getting the phrases to be separated by > space. > > However, I've been unable to figure out how to control the amount of > spacing between notes, and so this is what I need help with. Nobody > seems to know! Unfortunately, i don't know this too :( > If you think we should go ahead and push what is ready, I'm all for that. Definately! Please prepare a working (i.e. it cannot break compilation) patch containing finished features. cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Give slurs skylines in outside-staff-priority calculations. (issue 5504055)
On Dec 28, 2011, at 4:46 PM, Janek Warchoł wrote: > It would be great to fix this too! > You know, one thing comes to my mind: should we really use boxes for > all sorts of collision calculations? I think it would give much > better results it we calculated real distance between objects (i.e. > between black areas). We know the outlines of font glyphs, the real > shape of slur... Could we implement a global "metric" for measuring > distances between objects? My friend Łukasz (Luke) thinks this should > be the way to go. This is possible. To do this in LilyPond, you'd have to: -) Have skylines admit only lines and curves. Have all boxes decomposed into lines. -) Create a Line object like the Bezier object and subclass it from a class shape with all of the virtual methods you'd want to use. -) Figure out a way to read font data into Lines and Curves that can then get fed to skylines. -) Write Bezier & Line intersection algorithms (easy) and keep meticulous track of exactly how thick these curves are (harder). I don't have time to do this now, but it is certainly not impossible. The first step would be the porting of font data over to Bezier and Line objects in LilyPond. If you're looking for a welcome back project in the domain of collision avoidance, this'd certainly be it! Note, however, that the gain in precision you'd get from this type of calculation may lead to long calculation times (LilyPond spends a lot of time already in skylines) so while it's a worthwhile experiment, it may lead to deceiving results on the time front. That said, it is always possible to switch on and off more costly calculation methods (for example, Scripts use skyline calculations with the side-position-interface, whereas other grobs just use intervals). Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Regression tests don't run
Here's the contents of the relevant log file: GNU LilyPond 2.15.24 Killed ing ./snippet-map--1615808177 Processing 94/lily-32d78681 Processing 8d/lily-d2e2b327 Processing 29/lily-e0ac5d9b Processing 89/lily-1efebec4 Processing 56/lily-44b4b5eb Processing de/lily-7583ff9a Processing a1/lily-2532f52b Processing e9/lily-cc1cc235 Processing eb/lily-b9b3e4da Processing c4/lily-5ec3314c Processing b6/lily-ed22f196 Processing 15/lily-7dccbf09 Processing 14/lily-f30583e8 Processing fb/lily-225d5a65 Processing d5/lily-430551bd Processing 8f/lily-6ab7ba14 Processing 2b/lily-67a53cb6 Processing b9/lily-87587e29 Processing 14/lily-ec228008 Processing 53/lily-986709b2 Processing b7/lily-139426fd Processing 86/lily-19d35db6 Processing 82/lily-c4fec699 Processing ad/lily-e2043b05 Processing d2/lily-235b4f54 Processing 77/lily-8d63c64e Processing a3/lily-35b258bb Processing 0b/lily-4a373899 Processing 21/lily-61a92dad Processing b3/lily-aa32cc8b Processing a7/lily-49addee4 Processing ce/lily-e862b98f Processing ac/lily-607721f0 Processing c6/lily-f054e88e Processing 79/lily-720c9c29 Processing 2b/lily-9d8ed098 Processing 22/lily-1718ce3f Processing fa/lily-c94b8509 Processing 32/lily-223f4956 Processing 5f/lily-5b10c699 Processing 4e/lily-5a511e5e Processing cc/lily-95d0d592 Processing 9f/lily-4aff3b6d Processing ab/lily-eb1df898 Processing 83/lily-4b937056 Processing ce/lily-dbdc055c Processing 28/lily-5dd413f5 Processing 23/lily-1ef97ebb Processing e8/lily-537bc5aa Processing 65/lily-75309660 Processing e2/lily-62607bbd Processing f5/lily-d942e982 Processing aa/lily-4099c8bb Processing a6/lily-496abe90 Processing 06/lily-82d85ecc Processing ba/lily-b01b78ac Processing 4f/lily-55bea4f5 Processing 5a/lily-6a849106 Processing ed/lily-6e585fc8 Processing 58/lily-266fe9bc Processing 67/lily-133725e9 Processing 10/lily-bd86e368 Processing 91/lily-8e889cab Processing ad/lily-0851732d Processing e7/lily-3f441e4e Processing 91/lily-6383f8ee Processing 55/lily-8d0f229b Processing 05/lily-ea938668 Processing 2d/lily-3cf5aeba Processing 5f/lily-6a87f0ee Processing 66/lily-f56ccaae Processing ab/lily-4214384a Processing c8/lily-def31f4b Processing 1a/lily-b90d23c4 Processing fe/lily-16d8c40d Processing 5f/lily-824fd7df Processing ee/lily-82ee4955 Processing bf/lily-87f1c433 Processing e9/lily-697dfab3 Processing 60/lily-6c5ab550 Processing fd/lily-2f531b63 Processing b5/lily-a1e251f8 Processing 5e/lily-538dfa61 Processing 29/lily-905dff02 Processing 08/lily-163a34d7 Processing 10/lily-eeb266cd Processing 15/lily-f6bf1744 Processing 52/lily-f1c532f3 Processing e8/lily-39b668da Processing b3/lily-96491fef Processing 65/lily-12d11fe6 Processing ad/lily-4a65a9a9 Processing a6/lily-d85b2254 Processing 6a/lily-67029b14 Processing 3f/lily-dc74be5e Processing cc/lily-c86299ef Processing fd/lily-5c314c83 Processing 80/lily-1efcebab Processing 5c/lily-33bf9ef2 Processing 08/lily-1e228cd2 Processing d0/lily-74b8777a Processing 54/lily-bd72b7b6 Processing 7c/lily-8723b55c Processing dd/lily-9f75a27c Processing 91/lily-af7c96bf Processing 4c/lily-cc405751 Processing e4/lily-d9de67dd Processing e5/lily-33240bbc Processing 0b/lily-b64e2787 Processing 0a/lily-3c39c489 Processing c7/lily-4bc72a99 Processing dd/lily-acce9bcc Processing e3/lily-cf149140 Processing 94/lily-0def3433 Processing 90/lily-1098a953 Processing 0a/lily-3c5e91eb Processing 1b/lily-aeadd10a Processing e7/lily-17aec669 Processing 9b/lily-cc62da83 Processing f7/lily-ea9b5f76 Processing dd/lily-4497eb29 Processing f8/lily-62272f3c Processing b1/lily-e3db0b2b Processing 09/lily-ada16d72 Processing ac/lily-129a96e6 Processing f1/lily-c4f730c3 Processing a0/lily-52083928 Processing 37/lily-3e40c16c Processing a4/lily-b59df3db Processing 09/lily-1f5cc835 Processing 4e/lily-13e26396 Processing 22/lily-b5e766bb Processing 7e/lily-a887c164 Processing a4/lily-94320b95 Processing ba/lily-de8a468a Processing 56/lily-68611a0f Processing 29/lily-a9ff2d11 Processing 78/lily-fa60fe17 Processing dd/lily-9325fcdd Processing 8d/lily-b308bddb Processing 1e/lily-e83a90bd Processing 1a/lily-6f475f86 Processing 03/lily-68481a2f Processing 94/lily-c6d701c7 Processing 4f/lily-bb045b97 Processing c4/lily-a38f1a04 Processing e0/lily-386d9cdf Processing 19/lily-ece14a02 Processing a8/lily-1c89eb9d Processing cf/lily-c27adf63 Processing ff/lily-42692278 Processing 72/lily-bfd4d468 Processing f8/lily-854040e0 Processing 53/lily-0b6cd35e Processing 0a/lily-e018ab08 Processing 7a/lily-00408d77 Processing 53/lily-f91afdf8 Processing e2/lily-7f07ecf0 Processing 3b/lily-8f72236e Processing 38/lily-4ca5881d Processing 26/lily-b10705d7 Processing 50/lily-0bc3e5ca Processing de/lily-40a05bca Processing c6/lily-73a13001 Processing 38/lily-8bf11382 Processing 42/lily-551e1b0f Processing db/lily-3d77e7c4 Processing 37/lily-661f1a21 Processing 4b/lily-7352cabe Processing f5/lily-bb35059a Processing 0d/lily-349857a3 Processing 2d/lily-29933104 Processing 42/lily-9fcb7364 Processing c9/lily-f35bd5a4 Processing c4/lily-9c1
Re: Give slurs skylines in outside-staff-priority calculations. (issue 5504055)
http://codereview.appspot.com/5504055/diff/3002/scm/define-grob-properties.scm File scm/define-grob-properties.scm (right): http://codereview.appspot.com/5504055/diff/3002/scm/define-grob-properties.scm#newcode1101 scm/define-grob-properties.scm:1101: (skyline-quantizing ,ly:vsize? "The number of boxes to break a Mike, why have you added this predicate? It has no analogue in Scheme. I think integer? would be fine for this. You can silently prevent negative numbers. http://codereview.appspot.com/5504055/diff/3002/scm/define-grob-properties.scm#newcode1102 scm/define-grob-properties.scm:1102: slur into when calculating its skyline.") I think this should be more generic. There are other objects which would benefit from this such as hairpins and text spanners. http://codereview.appspot.com/5504055/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Give slurs skylines in outside-staff-priority calculations. (issue 5504055)
On Dec 28, 2011, at 6:30 PM, n.putt...@gmail.com wrote: > > http://codereview.appspot.com/5504055/diff/3002/scm/define-grob-properties.scm > File scm/define-grob-properties.scm (right): > > http://codereview.appspot.com/5504055/diff/3002/scm/define-grob-properties.scm#newcode1101 > scm/define-grob-properties.scm:1101: (skyline-quantizing ,ly:vsize? "The > number of boxes to break a > Mike, why have you added this predicate? It has no analogue in Scheme. > I think integer? would be fine for this. You can silently prevent > negative numbers. > I added it precisely to un-silently prevent negative numbers. It's true that it has no analogue in Scheme, but I didn't think this was a prerequisite for adding a predicate. In lily.scm, there are several predicates that don't have Scheme analogues (cheap-list, I believe, has no Scheme counterpart). > http://codereview.appspot.com/5504055/diff/3002/scm/define-grob-properties.scm#newcode1102 > scm/define-grob-properties.scm:1102: slur into when calculating its > skyline.") > I think this should be more generic. There are other objects which > would benefit from this such as hairpins and text spanners. Will do. If anyone feels like taking this on, please do - I have a few hard deadlines coming up and my lily development will be minimal for the next month-ish. Writing vertical-skyline approximations is not that bad - just use the slur model as a template and move code around to avoid duplication (for example, in the tuplet case, you'd want to change Tuplet_bracket::make_bracket to spit out a list of stencils and then harvest the boxes from the bounding boxes of the stencils in this list - then, move whatever logic is needed before calling Tuplet_bracket::make_bracket to a different callback that can be used by both the print callback and the vertical skylines callback). Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Give slurs skylines in outside-staff-priority calculations. (issue 5504055)
On 2011/12/28 17:41:03, mike_apollinemike.com wrote: I added it precisely to un-silently prevent negative numbers. It's true that it has no analogue in Scheme, but I didn't think this was a prerequisite for adding a predicate. In lily.scm, there are several predicates that don't have Scheme analogues (cheap-list, I believe, has no Scheme counterpart). I don't think that's a fair comparison. cheap-list is recognizably a predicate for lists. Anybody who wants to check for a positive integer isn't going to use ly:vsize? unless they're familiar with C++. Cheers, Neil http://codereview.appspot.com/5504055/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixes width of NR A.11 - List of special character (issue 5504091)
LGTM, please push to staging directly http://codereview.appspot.com/5504091/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Give slurs skylines in outside-staff-priority calculations. (issue 5504055)
On Dec 28, 2011, at 6:47 PM, n.putt...@gmail.com wrote: > On 2011/12/28 17:41:03, mike_apollinemike.com wrote: > >> I added it precisely to un-silently prevent negative numbers. >> It's true that it has no analogue in Scheme, but I didn't think this > was a >> prerequisite for adding a predicate. In lily.scm, there are several > predicates >> that don't have Scheme analogues (cheap-list, I believe, has no Scheme >> counterpart). > > I don't think that's a fair comparison. cheap-list is recognizably a > predicate for lists. Anybody who wants to check for a positive integer > isn't going to use ly:vsize? unless they're familiar with C++. > > Cheers, > Neil Ah, I see what you mean. Yes, you're right, it's a better idea to create a positive-integer? predicate. Patch forthcoming. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Give slurs skylines in outside-staff-priority calculations. (issue 5504055)
On Dec 28, 2011, at 8:02 PM, m...@apollinemike.com wrote: > On Dec 28, 2011, at 6:47 PM, n.putt...@gmail.com wrote: > >> On 2011/12/28 17:41:03, mike_apollinemike.com wrote: >> >>> I added it precisely to un-silently prevent negative numbers. >>> It's true that it has no analogue in Scheme, but I didn't think this >> was a >>> prerequisite for adding a predicate. In lily.scm, there are several >> predicates >>> that don't have Scheme analogues (cheap-list, I believe, has no Scheme >>> counterpart). >> >> I don't think that's a fair comparison. cheap-list is recognizably a >> predicate for lists. Anybody who wants to check for a positive integer >> isn't going to use ly:vsize? unless they're familiar with C++. >> >> Cheers, >> Neil > > Ah, I see what you mean. > Yes, you're right, it's a better idea to create a positive-integer? > predicate. Patch forthcoming. This wound up being a non-negative-integer predicate, as 0 is a valid vsize. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.15.23 regtests
Graham Percival percival-music.ca> writes: > On Mon, Dec 26, 2011 at 12:32:51PM -, Phil Holmes wrote: > > > > -warning: cannot fit music on page: ragged-spacing was requested, > > but page was compressed > > > > which ostensibly seems good, since we've lost a warning. > > One of the spacing patches changed that; The last-page spacing patch for issue 1377 makes the default setting ragged-last-bottom=##t tolerate stretching and compression. You still get the warning in cases where you could want it: if you set ragged-bottom=##t and any page, including the last, needs to be squeezed to fit. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Update lilygit.tcl (Issue 2092) (issue 5504092)
Reviewers: ,
Message:
Here's a stab at revising lily-git.tcl to facilitate patch pushing by
git novices.
Please review.
Thanks,
Carl
Description:
Update lilygit.tcl (Issue 2092)
Makes lilygit.tcl respect the environment variable $LILYPOND_GIT.
If $LILYPOND_GIT is unset, default of $HOME/lilypond-git will be used.
Also does all working on dev/local_working branch, instead of master
Adds a Push Patch button to push patch to staging.
Please review this at http://codereview.appspot.com/5504092/
Affected files:
M scripts/auxiliar/lily-git.tcl
Index: scripts/auxiliar/lily-git.tcl
diff --git a/scripts/auxiliar/lily-git.tcl b/scripts/auxiliar/lily-git.tcl
index
6f16791313d94a5aa83bfe7742406c16fff93e37..46740b35cbee4a56768baa33d5162dde48bd6a2e
100755
--- a/scripts/auxiliar/lily-git.tcl
+++ b/scripts/auxiliar/lily-git.tcl
@@ -4,13 +4,15 @@
# Copyright 2009--2011 by Johannes Schindelin and Carl Sorensen
#
-set version 0.64
+set version 0.65
# set to 1 to set up for translation, to 0 for other
set translator 0
# location of lilypond git
-set lily_dir $env(HOME)/lilypond-git
+if [catch {set lily_dir $env(LILYPOND_GIT)}] {
+ set lily_dir $env(HOME)/lilypond-git
+}
if {$translator == 1} {
set windowTitle \
@@ -24,7 +26,8 @@ if {$translator == 1} {
"LilyPond Contributor's Git Interface version $version"
set updateButtonText "1. Update source"
set initializeButtonText "1. Get source"
-set originHead "master"
+set originHead "staging"
+set workingBranch "dev/local_working"
set rebase 1
}
package require Tk
@@ -215,6 +218,7 @@ proc update_lilypond {rebase} {
global lily_dir
global originHead
global translator
+global workingBranch
. config -cursor watch
if {![file exists $lily_dir]} {
write_to_output "Cloning LilyPond (this can take some time) ...\n"
@@ -228,16 +232,22 @@ proc update_lilypond {rebase} {
git reset --hard origin/$originHead
git config branch.$originHead.remote origin
git config branch.$originHead.merge refs/heads/$originHead
+if {$workingBranch != ""} {
+ git branch -f $workingBranch
+ git checkout $workingBranch
+}
.buttons.commitFrame.commit configure -state normal
.buttons.commitFrame.amend configure -state normal
.buttons.update configure -text buttonUpdateText
.buttons.patch configure -state normal
+.buttons.push configure -state normal
.buttons.panic configure -state normal
toggle_rebase
} else {
write_to_output "Updating LilyPond...\n"
git fetch origin
if {$rebase} {
+git checkout $workingBranch
git rebase origin/$originHead
} else {
git merge origin/$originHead
@@ -267,6 +277,16 @@ proc make_patch_from_origin {rebase} {
. config -cursor ""
}
+
+proc push_patch_to_staging {} {
+global workingBranch
+global originHead
+
+git checkout $workingBranch
+git rebase $originHead
+git push origin HEAD:$workingBranch
+}
+
proc abort_changes {} {
global abort_dir
global originHead
@@ -396,6 +416,8 @@ button .buttons.update -text $updateButtonText \
-command update_lilypond_with_rebase
button .buttons.patch -text "3. Make patch set" \
-command patch_from_origin
+button .buttons.push -text "4. Push patch to staging" \
+-command push_to_staging
toggle_rebase
button .buttons.panic -text "Abort changes -- Reset to origin" \
-command abort_changes -fg Blue -bg Red
@@ -406,6 +428,7 @@ if {![file exists $lily_dir]} {
.buttons.commitFrame.commit configure -state disabled
.buttons.commitFrame.amend configure -state disabled
.buttons.patch configure -state disabled
+.buttons.push configure -state disabled
.buttons.panic configure -state disabled
}
@@ -414,6 +437,7 @@ if {![file exists $lily_dir]} {
pack .buttons.update -side left
pack .buttons.commitFrame -side left
pack .buttons.patch -side left
+pack .buttons.push -side left
pack .buttons.spacer -side left
pack .buttons.panic -side right
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Update lilygit.tcl (Issue 2092) (issue 5504092)
Thanks for working on this! Unfortunately I'm between cities at the moment; I'll try to comment more tomorrow evening. First thought: I'm a bit leery of adding a "push to staging", since: 1. that clutters up the interface. Sure, it's just one more button, but OTOH that's 25% more buttons. :) 2. it might confuse new contributors, who aren't allowed to push to staging. 3. anybody who's stayed around long enough to get git push ability shouldn't need it. (particularly once I get around to working on my cg patch again) http://codereview.appspot.com/5504092/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
