Re: Adds Scheme function for spring constructor. (issue 5306050)
Reviewers: Bertrand Bordage, Neil Puttock, dak,
Message:
Hey all,
I've made all of the requested changes save Spring::equal_p, as I can't
see a clear consensus about what changes need to be made here. As this
problem is outside the purview of this patch, it may be worth it to
propose another patch that treats this issue (and others like it in
other smobs if such issues exist) separately.
Cheers,
MS
Description:
Adds Scheme function for spring constructor.
Please review this at http://codereview.appspot.com/5306050/
Affected files:
M lily/spring-smob.cc
M scm/lily.scm
Index: lily/spring-smob.cc
diff --git a/lily/spring-smob.cc b/lily/spring-smob.cc
index
8e263d06944bd406b3bbff5a7a12165ce3f7a917..0f22f06778b199664ceaf81cca6e1a07403b4383
100644
--- a/lily/spring-smob.cc
+++ b/lily/spring-smob.cc
@@ -42,3 +42,41 @@ Spring::equal_p (SCM a, SCM b)
return a == b ? SCM_BOOL_T : SCM_BOOL_F;
}
+LY_DEFINE (ly_make_spring, ly:make-spring,
+ 2, 0, 0, (SCM ideal, SCM min_dist),
+ Make a spring. @var{ideal} is the ideal distance of the
+spring, and @var{min-dist} is the minimum distance.)
+{
+ LY_ASSERT_TYPE (scm_is_number, ideal, 1);
+ LY_ASSERT_TYPE (scm_is_number, min_dist, 2);
+
+ Spring s (scm_to_double (ideal), scm_to_double (min_dist));
+
+ return s.smobbed_copy ();
+}
+
+LY_DEFINE
(ly_spring_set_inverse_compress_strength_x, ly:spring-set-inverse-compress-strength!,
+ 2, 0, 0, (SCM spring, SCM strength),
+ Set the inverse compress @var{strength} of @var{spring}.)
+{
+ LY_ASSERT_SMOB (Spring, spring, 1);
+ LY_ASSERT_TYPE (scm_is_number, strength, 2);
+
+ Spring *s = unsmob_spring (spring);
+ s-set_inverse_compress_strength (scm_to_double (strength));
+ return s-smobbed_copy ();
+}
+
+LY_DEFINE
(ly_spring_set_inverse_stretch_strength_x, ly:spring-set-inverse-stretch-strength!,
+ 2, 0, 0, (SCM spring, SCM strength),
+ Set the inverse stretch @var{strength} of @var{spring}.)
+{
+ LY_ASSERT_SMOB (Spring, spring, 1);
+ LY_ASSERT_TYPE (scm_is_number, strength, 2);
+
+ Spring *s = unsmob_spring (spring);
+ s-set_inverse_stretch_strength (scm_to_double (strength));
+ return s-smobbed_copy ();
+}
+
+IMPLEMENT_TYPE_P (Spring, ly:spring?);
\ No newline at end of file
Index: scm/lily.scm
diff --git a/scm/lily.scm b/scm/lily.scm
index
88f1183b926dcf19e4cabcc9cc4f373a335a1e67..1e68b78a15e28b44fec1274a6580877a042d0763
100644
--- a/scm/lily.scm
+++ b/scm/lily.scm
@@ -575,6 +575,7 @@ LilyPond safe mode. The syntax is the same as
`define*-public'.
(,ly:skyline-pair? . pair of skylines)
(,ly:source-file? . source file)
(,ly:spanner? . spanner)
+(,ly:spring? . spring)
(,ly:stencil? . stencil)
(,ly:stream-event? . stream event)
(,ly:translator? . translator)
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
musicexp.py: Fix for issue 1985 (issue 5303063)
Reviewers: Reinhold,
Message:
I uploaded a patch for Issue 1985: musicxml2ly: group-symbol none leads
to bus error.
Description:
musicexp.py: Fix for issue 1985
The musicxml value 'none' of the group-symbol element is now converted
to 'SystemStartBar' instead of 'f', the compilation of which lead to a
bus error/seg fault.
Please review this at http://codereview.appspot.com/5303063/
Affected files:
M python/musicexp.py
Index: python/musicexp.py
diff --git a/python/musicexp.py b/python/musicexp.py
index
d105ef333d2bfb8f50f2dba428b4fbb00caf29e0..8610f8aa44f138886c5a1bed5cb4963a3f43a34f
100644
--- a/python/musicexp.py
+++ b/python/musicexp.py
@@ -1793,7 +1793,7 @@ class StaffGroup:
if self.spanbar == no:
printer.dump (\\override SpanBar #'transparent = ##t)
brack = {brace: SystemStartBrace,
- none: f,
+ none: SystemStartBar,
line: SystemStartSquare}.get (self.symbol, None)
if brack:
printer.dump (systemStartDelimiter = #'%s % brack)
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: nobody cares about LSR, part 2 (was: wrong alignment...)
- Original Message - From: Graham Percival gra...@percival-music.ca To: -Eluze elu...@gmail.com; lilypond-devel@gnu.org Cc: bug-lilyp...@gnu.org Sent: Sunday, October 23, 2011 4:00 AM Subject: nobody cares about LSR, part 2 (was: wrong alignment...) On Sat, Oct 22, 2011 at 12:22:54PM -0700, -Eluze wrote: 1) add a snippet to LSR showing this method. Make sure that the snippet is tagged with docs. 2) wait until it's automatically part of the docs. although the snippet i added a few days ago is not approved yet i can see it when browsing the snippets. Yes. Either be patient, or wait for somebody to care about LSR. I normally do this on my Bug squad day - Sunday. Last week I did quite a bit of squadding and forgot about the beloved LSR. All is now up to date. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [translations] Re: CG 5.8.3: updating committish of lsr snippets
I've almost gave up here. I don't have skills nor time to spend on this issue, sorry. The attached patch fixes the bad object error. I have no idea if it's correct and how the updating of .texidoc files works. make check-translation still looks weird to me, but I won't care for now What I've done = Which is the committish that I should have used in my .texidoc files when I committed them? The answer should be: the commit id (my commit) of the makelsr that processed them. Right? So, I checked the log of each file in Documentation/snippets. I noticed that most of them had this committish (c3b51...), so I substitued the bad object: sed -i 's/514674cb00c18629242dfcde0c1a4976758adc56/c3b519f0dd5ff0f8ccfc9a39ed1fe8df8b43741c/g' *.texidoc Then I fixed the few files that are related to a different committish. This is the final committish situation in Documentation/it/texidocs: $ cat * | grep committish %% Translation of GIT committish: c3b519f0dd5ff0f8ccfc9a39ed1fe8df8b43741c %% Translation of GIT committish: c3b519f0dd5ff0f8ccfc9a39ed1fe8df8b43741c %% Translation of GIT committish: c3b519f0dd5ff0f8ccfc9a39ed1fe8df8b43741c %% Translation of GIT committish: c3b519f0dd5ff0f8ccfc9a39ed1fe8df8b43741c %% Translation of GIT committish: c3b519f0dd5ff0f8ccfc9a39ed1fe8df8b43741c %% Translation of GIT committish: 34607d3e36a93030690ccd780a7ffce621ca1e0f %% Translation of GIT committish: c3b519f0dd5ff0f8ccfc9a39ed1fe8df8b43741c %% Translation of GIT committish: c3b519f0dd5ff0f8ccfc9a39ed1fe8df8b43741c %% Translation of GIT committish: c3b519f0dd5ff0f8ccfc9a39ed1fe8df8b43741c %% Translation of GIT committish: c3b519f0dd5ff0f8ccfc9a39ed1fe8df8b43741c %% Translation of GIT committish: 34607d3e36a93030690ccd780a7ffce621ca1e0f %% Translation of GIT committish: c3b519f0dd5ff0f8ccfc9a39ed1fe8df8b43741c %% Translation of GIT committish: c3b519f0dd5ff0f8ccfc9a39ed1fe8df8b43741c %% Translation of GIT committish: c3b519f0dd5ff0f8ccfc9a39ed1fe8df8b43741c %% Translation of GIT committish: c3b519f0dd5ff0f8ccfc9a39ed1fe8df8b43741c %% Translation of GIT committish: c3b519f0dd5ff0f8ccfc9a39ed1fe8df8b43741c %% Translation of GIT committish: c3b519f0dd5ff0f8ccfc9a39ed1fe8df8b43741c %% Translation of GIT committish: c3b519f0dd5ff0f8ccfc9a39ed1fe8df8b43741c %% Translation of GIT committish: c3b519f0dd5ff0f8ccfc9a39ed1fe8df8b43741c %% Translation of GIT committish: c3b519f0dd5ff0f8ccfc9a39ed1fe8df8b43741c %% Translation of GIT committish: 34607d3e36a93030690ccd780a7ffce621ca1e0f From c7b2f1e51dd570b6c3376c25f1970338cf483987 Mon Sep 17 00:00:00 2001 From: Federico Bruni fedel...@gmail.com Date: Sun, 23 Oct 2011 20:44:34 +0200 Subject: [PATCH] Doc-it: fix the wrong committishes (bad object) in .texidoc files --- ...modern-transcription-of-gregorian-music.texidoc |2 +- ...-modern-transcription-of-mensural-music.texidoc |2 +- .../it/texidocs/anglican-psalm-template.texidoc|2 +- Documentation/it/texidocs/hymn-template.texidoc|2 +- .../it/texidocs/jazz-combo-template.texidoc|2 +- .../orchestra,-choir-and-piano-template.texidoc|2 +- .../it/texidocs/piano-template-simple.texidoc |2 +- .../piano-template-with-centered-dynamics.texidoc |2 +- .../piano-template-with-centered-lyrics.texidoc|2 +- .../piano-template-with-melody-and-lyrics.texidoc |2 +- .../satb-choir-template---four-staves.texidoc |2 +- ...template-with-notes,-lyrics,-and-chords.texidoc |2 +- ...le-staff-template-with-notes-and-chords.texidoc |2 +- ...le-staff-template-with-notes-and-lyrics.texidoc |2 +- .../single-staff-template-with-only-notes.texidoc |2 +- .../string-quartet-template-simple.texidoc |2 +- ...ng-quartet-template-with-separate-parts.texidoc |2 +- ...template-with-automatic-piano-reduction.texidoc |2 +- ...rics-aligned-below-and-above-the-staves.texidoc |2 +- ...nsemble-template-with-verse-and-refrain.texidoc |2 +- .../it/texidocs/vocal-ensemble-template.texidoc|2 +- 21 files changed, 21 insertions(+), 21 deletions(-) diff --git a/Documentation/it/texidocs/ancient-notation-templatemodern-transcription-of-gregorian-music.texidoc b/Documentation/it/texidocs/ancient-notation-templatemodern-transcription-of-gregorian-music.texidoc index 56e558f..6a89812 100644 --- a/Documentation/it/texidocs/ancient-notation-templatemodern-transcription-of-gregorian-music.texidoc +++ b/Documentation/it/texidocs/ancient-notation-templatemodern-transcription-of-gregorian-music.texidoc @@ -1,4 +1,4 @@ -%% Translation of GIT committish: 514674cb00c18629242dfcde0c1a4976758adc56 +%% Translation of GIT committish: c3b519f0dd5ff0f8ccfc9a39ed1fe8df8b43741c texidocit = Questo esempio mostra come realizzare una trascrizione moderna di musica gregoriana. La musica gregoriana non presenta suddivisione in misure né gambi; diff --git
Re: lily-guile updates and CG: Scheme-C interface section. (issue 4917044)
lily-guile updates pushed as 6ee8c04678442855cb794d4598c056c15c42673b. http://codereview.appspot.com/4917044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Rename \markuplines to \markuplist (before running convert-ly) (issue 5312050)
LGTM. You'll be happy to know that Mike and I are currently trying to get rid of \markuplines, so that there will only be a \markup command. http://codereview.appspot.com/5312050/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lily-guile updates and CG: Scheme-C interface section. (issue 4917044)
As usual, too late in the game. Better late than never.
http://codereview.appspot.com/4917044/diff/16006/Documentation/contributor/programming-work.itexi
File Documentation/contributor/programming-work.itexi (right):
http://codereview.appspot.com/4917044/diff/16006/Documentation/contributor/programming-work.itexi#newcode1871
Documentation/contributor/programming-work.itexi:1871: (scm_list_p
(scm_value) scm_value != SCM_EOL)
scm_list_p is _always_ true according to C since it is either SCM_BOOL_T
or SCM_BOOL_F, both of which are non-zero.
http://codereview.appspot.com/4917044/diff/16006/Documentation/contributor/programming-work.itexi#newcode1880
Documentation/contributor/programming-work.itexi:1880: since a list of
at least one member is considered as a pair.
But not every pair is a proper list. scm_list_[ returns #t only for
proper lists, not circular lists and not dotted lists.
Still, this check is usually what one wants since it is cheap (list?
goes through the whole list with a hare/tortoise algorithm). It just
won't catch the degenerate cases.
http://codereview.appspot.com/4917044/diff/16006/Documentation/contributor/programming-work.itexi#newcode1884
Documentation/contributor/programming-work.itexi:1884: interface.
As a rule of thumb, you get an scm_is_[something] for cheap predicates,
those that are likely to be inlined. So you have scm_is_pair, but not
scm_is_list, and scm_is_eq but not scm_is_eqv or scm_is_equal.
http://codereview.appspot.com/4917044/diff/16006/Documentation/contributor/programming-work.itexi#newcode1892
Documentation/contributor/programming-work.itexi:1892: This should be
used instead of @code{scm_is_true} and @code{scm_is_false}
Both scm_is_true and scm_is_false compare only for equality with #f,
like if does.
http://codereview.appspot.com/4917044/diff/16006/Documentation/contributor/programming-work.itexi#newcode1893
Documentation/contributor/programming-work.itexi:1893: for properties
since empty lists are sometimes used to unset them.
since reading any unset property returns an empty list, and Lilypond has
the convention to interpret unset boolean properties as false.
http://codereview.appspot.com/4917044/diff/16006/Documentation/contributor/programming-work.itexi#newcode1904
Documentation/contributor/programming-work.itexi:1904: @node Conversion
The whole node is duplication.
http://codereview.appspot.com/4917044/diff/16006/lily/lily-guile.cc
File lily/lily-guile.cc (left):
http://codereview.appspot.com/4917044/diff/16006/lily/lily-guile.cc#oldcode339
lily/lily-guile.cc:339: return true;
This returns true if every pair in list a is also in list b. But list b
can contain more key-value pairs than a. Since an alist can contain
duplicate entries (the former shadowing the latter), counting members is
not sufficient to deduce equivalence.
Also if a contains shadowed (different) entries, the test will never
turn out #t. For example, this returns false when comparing '((#t . #t)
(#t . #f)) with itself.
If this function is indeed not used, delete this totally broken thing
that can't be easily fixed.
http://codereview.appspot.com/4917044/diff/16006/lily/lily-guile.cc
File lily/lily-guile.cc (right):
http://codereview.appspot.com/4917044/diff/16006/lily/lily-guile.cc#newcode325
lily/lily-guile.cc:325: // This one is used nowhere.
If it is used nowhere, it should be removed. It is catastrophically
wrong.
http://codereview.appspot.com/4917044/diff/16006/lily/lily-guile.cc#newcode329
lily/lily-guile.cc:329: if (!scm_is_pair (a) || !scm_is_pair (b))
This returns false even if both alists are empty.
http://codereview.appspot.com/4917044/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: nobody cares about LSR, part 2 (was: wrong alignment...)
On Sun, Oct 23, 2011 at 01:34:53PM +0100, Phil Holmes wrote: - Original Message - From: Graham Percival gra...@percival-music.ca Yes. Either be patient, or wait for somebody to care about LSR. I normally do this on my Bug squad day - Sunday. Last week I did quite a bit of squadding and forgot about the beloved LSR. All is now up to date. I don't see any commits in git, so no, all is not up to date. In particular, Eluze is not going to see the snippet in the official docs until somebody does more work. Run makelsr locally. Then read CG 7.4 and do that. Ask Valentin or Neil for help, or put up with me. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
PATCH: Countdown to 20111025
For 20:00 MDT Tuesday October 25, 2011 Issue 1984 http://code.google.com/p/lilypond/issues/detail?id=1984: Patch: parser.yy: make Scheme and music expressions equivalent as function arguments. - R -5295054 http://codereview.appspot.com/5295054/ (pushed to dev/staging as cda3f6014feee11572a41e5d7ebf2151787d6d77) Issue 1972 http://code.google.com/p/lilypond/issues/detail?id=1972: Seg fault and 100% CPU when using \override Staff.StaffSymbol #'ledger-positions - R4974075 http://codereview.appspot.com/4974075/ (The Rietveld issue is marked closed, but I don't believe it has been pushed) Cheers, Colin -- I've learned that you shouldn't go through life with a catcher's mitt on both hands. You need to be able to throw something back. -Maya Angelou, poet (1928- ) ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Make doc broken - 1d9a73b13ee576d28c0f41f5b243f2ebb1ff9fcf
On Sat, Oct 22, 2011 at 10:55:52AM +0200, m...@apollinemike.com wrote: On Oct 22, 2011, at 6:10 AM, Graham Percival wrote: dev/staging will be merged with master at least once every 24 hours[1] as long as it compiles. Could you point me to the place in the CG with instructions about how to push to dev/staging and/or give me instructions for how to do that via email? The way that I'd try to do it is this: git checkout dev/staging git cherry-pick abcd1234 git push origin dev/staging but I'm not certain if that's the best way to do it. David has concerns about merge vs. fast-forward, but I'm not familiar enough with git to know the difference. (I have a few emails on the subject saved in my urgent email mailbox, but then again I have 134 other emails in there, which makes the whole thing a bit of a mockery) Hopefully somebody can correct or fill in the missing details. I'll add it to the CG once that's done. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
