Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Issue 3304 #2

Closed
wants to merge 4 commits into from
Closed

Issue 3304 #2

wants to merge 4 commits into from

Conversation

Keith-OHara
Copy link
Contributor

No description provided.

@Keith-OHara
spacing-options: clarify documentation
6877267
@Keith-OHara
springs: comment and typo
83269b6
@Keith-OHara
note-spacing: stretch somewhat uniformly
a389298 
Start with a basic spring based on the note duration, and apply optical
corrections to that.  This results in more consistent springs thus more
uniform stretching in polyphonic situations.
@Keith-OHara
note-spacing: let compressibility be uniform; issue 3304
2a38177 
Comments implied that half the width of accidentals, etc., was added
to the ideal spacing between notes, but in fact only compressibility
was affected.  The non-uniform compressibility caused note-spacing
to become non-uniform when the lines were compressed.  For example
A sequence {\stemUp a a d a] would have the head of the D tuck under
the preceding A.

This commit keeps spacing uniform on compressed lines until objects
come within padding of each other.
@uliska
Copy link
Contributor

uliska commented Dec 20, 2013

Hi Keith,

I'm not sure how to proceed here.
Actually I don't know where additions to this fork will end up, and I can't judge your additions.
And I don't know if Janek is available to do anything currently (or even gets notified about this pull request).

@jan-warchol
Copy link
Member

Oh my, i see i didn't reply to this pull request... Sorry again :(
Thanks for trying to push forward using GitHub for LilyPond development, Keith! Unfortunately i'm afraid that without broader support from other devs using GitHub won't be accepted anyway :(

I'm closing the pull request since the patches was merged in an "ordinary" manner already.

uliska pushed a commit that referenced this pull request Apr 16, 2016
@dakhubgit
Issue 4687/1: Let \etc in partial markup commands stand for any argum…
70eaa17 
…ents

Previously, \etc could only stand for a final markup argument.  Now an
arbitrary kind and number of arguments from the last markup command in
a markup command chain may be omitted.

Example:

quarter-markup = \markup \note-by-number #2 \etc

\markup { 3/8: \quarter #1 #UP }
hahnjo added a commit that referenced this pull request Dec 28, 2020
@hahnjo
Protect against GC when constructing a System
aacb2da 
With Guile 2.2, it's possible to observe crashes like
    #0  std::vector<Grob*, std::allocator<Grob*> >::size() const (this=0x0)
    #1  System::derived_mark() const (this=0x556efd94f460) at [...]/lily/system.cc:113
    #2  0x0000556ef6b08f25 in Grob::mark_smob() const (this=0x556efd94f460)
    #3 to #10 in libguile-2.2.so.1 and libgc.so.1
    #11 0x00007f0e322bc875 in scm_i_new_smob ()
    #12 0x0000556ef6b0100b in scm_new_smob (data=93935189161312, tc=13943)
    #13 Smob_base<Grob_array>::register_ptr(Grob_array*) (p=0x556efd94f560)
    #14 Simple_smob<Grob_array>::smobbed_copy() const (this=<synthetic pointer>)
    #15 Grob_array::make_array()
    #16 0x0000556ef6c72bdf in System::init_elements() (this=0x556efd94f460)
    #17 0x0000556ef6bfb3f9 in Score_engraver::initialize() (this=0x556efc946cd0)

In this case, System::init_elements() calls Grob_array::make_array()
to later initialize all_elements_, which is consequently 0 until then.
hahnjo added a commit that referenced this pull request Dec 28, 2020
@hahnjo
System: Initialize all member variables
5fc9757 
With Guile 2.2, it's possible to observe crashes like
    #0  System::derived_mark() const (this=0x55bd0b6a3730)
        at [...]/lily/include/smobs.hh:321
    #1  0x000055bd05f62f25 in Grob::mark_smob() const (this=0x55bd0b6a3730)
    #2  to #9 in libguile-2.2.so.1 and libgc.so.1
    #10 0x00007f5ed5bfe875 in scm_i_new_smob ()
    #11 0x000055bd05f5b00b in scm_new_smob (data=94270412975808, tc=13943)
    #12 Smob_base<Grob_array>::register_ptr(Grob_array*) (p=0x55bd0a7a6ec0)
    #13 Simple_smob<Grob_array>::smobbed_copy() const (this=<synthetic pointer>)
    #14 Grob_array::make_array()
    #15 0x000055bd060ccbdf in System::init_elements() (this=0x55bd0b6a3730)
    #16 0x000055bd060553f9 in Score_engraver::initialize() (this=0x55bd08b51ed0)

The reason is that System::System (SCM) did not initialize the pscore_
field and relied on Paper_score::typeset () to fill in the data. When
a GC happens between the two steps, System::derived_mark () calls
self_scm () (at lily/include/smobs.hh:321) on an uninitialized pointer.
hahnjo added a commit that referenced this pull request Jan 18, 2021
@hahnjo
Protect against GC when constructing a System
b18c0c8 
With Guile 2.2, it's possible to observe crashes like
    #0  std::vector<Grob*, std::allocator<Grob*> >::size() const (this=0x0)
    #1  System::derived_mark() const (this=0x556efd94f460) at [...]/lily/system.cc:113
    #2  0x0000556ef6b08f25 in Grob::mark_smob() const (this=0x556efd94f460)
    #3 to #10 in libguile-2.2.so.1 and libgc.so.1
    #11 0x00007f0e322bc875 in scm_i_new_smob ()
    #12 0x0000556ef6b0100b in scm_new_smob (data=93935189161312, tc=13943)
    #13 Smob_base<Grob_array>::register_ptr(Grob_array*) (p=0x556efd94f560)
    #14 Simple_smob<Grob_array>::smobbed_copy() const (this=<synthetic pointer>)
    #15 Grob_array::make_array()
    #16 0x0000556ef6c72bdf in System::init_elements() (this=0x556efd94f460)
    #17 0x0000556ef6bfb3f9 in Score_engraver::initialize() (this=0x556efc946cd0)

In this case, System::init_elements() calls Grob_array::make_array()
to later initialize all_elements_, which is consequently 0 until then.

(cherry picked from commit aacb2da)
hahnjo added a commit that referenced this pull request Jan 18, 2021
@hahnjo
System: Initialize all member variables
8183e7f 
With Guile 2.2, it's possible to observe crashes like
    #0  System::derived_mark() const (this=0x55bd0b6a3730)
        at [...]/lily/include/smobs.hh:321
    #1  0x000055bd05f62f25 in Grob::mark_smob() const (this=0x55bd0b6a3730)
    #2  to #9 in libguile-2.2.so.1 and libgc.so.1
    #10 0x00007f5ed5bfe875 in scm_i_new_smob ()
    #11 0x000055bd05f5b00b in scm_new_smob (data=94270412975808, tc=13943)
    #12 Smob_base<Grob_array>::register_ptr(Grob_array*) (p=0x55bd0a7a6ec0)
    #13 Simple_smob<Grob_array>::smobbed_copy() const (this=<synthetic pointer>)
    #14 Grob_array::make_array()
    #15 0x000055bd060ccbdf in System::init_elements() (this=0x55bd0b6a3730)
    #16 0x000055bd060553f9 in Score_engraver::initialize() (this=0x55bd08b51ed0)

The reason is that System::System (SCM) did not initialize the pscore_
field and relied on Paper_score::typeset () to fill in the data. When
a GC happens between the two steps, System::derived_mark () calls
self_scm () (at lily/include/smobs.hh:321) on an uninitialized pointer.

(cherry picked from commit 5fc9757)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
3 participants
@Keith-OHara @uliska @jan-warchol