lilypond-auto
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Lilypond-auto] [LilyIssues-auto] [testlilyissues:issues] #4975 [Windows


From: Auto mailings of changes to Lily Issues
Subject: [Lilypond-auto] [LilyIssues-auto] [testlilyissues:issues] #4975 [Windows] Grace notes cause staff to protrude into the margin
Date: Wed, 28 Sep 2016 11:49:16 +0000

Please really check that reverting only the change in lily/simple-spacer.cc is sufficient for removing the problem. Because if it is, we have a far larger problem either involving a fundamental Guile bug or a GCC compiler bug: the change in simple-spacer.cc is just

diff --git a/lily/simple-spacer.cc b/lily/simple-spacer.cc
index d17fa1e..ada1659 100644
--- a/lily/simple-spacer.cc
+++ b/lily/simple-spacer.cc
@@ -528,7 +528,7 @@ get_line_configuration (vector<Grob *> const &columns,
   for (vsize i = 1; i + 1 < ret.cols_.size (); i++)
     {
         SCM p = ret.cols_[i]->get_property ("line-break-permission");
-      if (p == ly_symbol2scm ("force"))
+      if (scm_is_eq (p, ly_symbol2scm ("force")))
         ret.satisfies_constraints_ = false;
     }

And the respective definitions in Guile 1.8 are:
#elif (SCM_DEBUG_TYPING_STRICTNESS == 1)
/ This is the default, which provides an intermediate level of compile time
* type checking while still resulting in very efficient code.

/
typedef struct scm_unused_struct * SCM;

/*
  The 0?: constructions makes sure that the code is never executed,
  and that there is no performance hit.  However, the alternative is
  compiled, and does generate a warning when used with the wrong
  pointer type.

  The Tru64 and ia64-hp-hpux11.23 compilers fail on `case (0?0=0:x)`
  statements, so for them type-checking is disabled.
*/
#if defined __DECC || defined __HP_cc
#   define SCM_UNPACK(x) ((scm_t_bits) (x))
#else
#   define SCM_UNPACK(x) ((scm_t_bits) (0? (*(SCM*)0=(x)): x))
#endif

followed by

#define scm_is_eq(x, y) (SCM_UNPACK (x) == SCM_UNPACK (y))

and also

/* For dealing with the bit level representation of scheme objects we define
 * scm_t_bits:
 */
/* On Solaris 7 and 8, /usr/include/sys/int_limits.h defines
   INTPTR_MAX and UINTPTR_MAX to empty, INTPTR_MIN is not defined.
   To avoid uintptr_t and intptr_t in this case we require
   UINTPTR_MAX-0 != 0 etc.  */
#if SCM_SIZEOF_INTPTR_T != 0 && defined(INTPTR_MAX) && defined(INTPTR_MIN) \
  && INTPTR_MAX-0 != 0 && INTPTR_MIN-0 != 0 \
  && SCM_SIZEOF_UINTPTR_T != 0 && defined(UINTPTR_MAX) && UINTPTR_MAX-0 != 0

typedef intptr_t scm_t_signed_bits;
#define SCM_T_SIGNED_BITS_MAX INTPTR_MAX
#define SCM_T_SIGNED_BITS_MIN INTPTR_MIN
typedef uintptr_t scm_t_bits;
#define SIZEOF_SCM_T_BITS SCM_SIZEOF_UINTPTR_T
#define SCM_T_BITS_MAX UINTPTR_MAX

#else

typedef signed long scm_t_signed_bits;
#define SCM_T_SIGNED_BITS_MAX LONG_MAX
#define SCM_T_SIGNED_BITS_MIN LONG_MIN
typedef unsigned long scm_t_bits;
#define SIZEOF_SCM_T_BITS SCM_SIZEOF_UNSIGNED_LONG
#define SCM_T_BITS_MAX ULONG_MAX

#endif

Either scm_t_bits is defined as an unsigned long (of length 32 bit) unable to actually hold a pointer value, in which case Guile will be broken. Or we have a compiler error during code generation. Either will affect a lot more code than just this.

So we better make quite sure that this change is responsible. And if it is, I'll need to look at the output of autoconf on the cross compilation of Guile, and then I'll likely need to check the generated assembly code.


[issues:#4975] [Windows] Grace notes cause staff to protrude into the margin

Status: Started
Created: Sun Sep 18, 2016 11:07 PM UTC by Simon Albrecht
Last Updated: Wed Sep 28, 2016 09:07 AM UTC
Owner: Phil Holmes

http://lilypond.1069038.n5.nabble.com/Grace-notes-and-staff-miss-alignment-tp181529p188186.html
As reported by Karol and confirmed by Pierre, this code

\version "2.19.48"

\transpose c c' {
  \repeat unfold 16 { e'8 a }
  R1*8
}

\transpose c c' {
  \repeat unfold 16 { \grace dis'8 e' \grace gis8 a }
  R1*8
} 

under Windows (at least 7 and 8) causes lots of programming error: mis-predicted force and has the last staff flow into the margin.
Output at http://lilypond.1069038.n5.nabble.com/file/n188186/ttttttt.pdf

The first bad version is 2.19.19.


Sent from sourceforge.net because address@hidden is subscribed to https://sourceforge.net/p/testlilyissues/issues/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/testlilyissues/admin/issues/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.

------------------------------------------------------------------------------
_______________________________________________
Testlilyissues-auto mailing list
address@hidden
https://lists.sourceforge.net/lists/listinfo/testlilyissues-auto

reply via email to

[Prev in Thread] Current Thread [Next in Thread]