Re: stable/2.20 might fail to build

2019-07-04 Thread Werner LEMBERG 
>> So the `stable' branch should add the file `txi-pt.tex' from
>> upstream, right?
> 
> Yes.  And we need to add the filename to the list of copied files in
> grand-replace.py.  See attached patch for stable/2.20.

LGTM, thanks!


Werner

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Build fix for stable 2.20 on openSuSE Tumbleweed

2019-07-04 Thread Knut Petersen 

Hi David!

Attached is bc4f5fdc299 of master ported to stable/2.20.
Cherry picking did not work as the aclocal.m4 files diverged to much.

Knut
>From db670c8174b3f00c0e9676683f3f1c74b787b5ee Mon Sep 17 00:00:00 2001
From: Knut Petersen 
Date: Thu, 4 Jul 2019 08:09:22 +0200
Subject: [PATCH 2/2] Add glib-2.0 and gobject-2.0 library dependency

For a long time we relied on pango/pangoft2
to pull in the glib and gobject libraries.
That worked as long as every distribution
used a pangoft2.pc file that included both
libs in the 'Required:' line.

According to the pkg-config documentation
that was definitely wrong, and the problem
was corrected on opensuse tumbleweed recently.

As a consequence, building lilypond failed
with a linker error as we use symbols from
both libs directly in our c++ source code.

Cherry-picking bc4f5fdc299 does not work, but
this patch is equivalent to bc4f5fdc299 in
lilypond master.
---
 aclocal.m4 | 39 ++-
 config.make.in | 12 +---
 configure.ac   |  2 ++
 3 files changed, 49 insertions(+), 4 deletions(-)

diff --git a/aclocal.m4 b/aclocal.m4
index 1228f6ca29..68ae1be130 100644
--- a/aclocal.m4
+++ b/aclocal.m4
@@ -1221,7 +1221,6 @@ AC_DEFUN(STEPMAKE_WARN, [
 warn_b=yes
 ])
 
-
 dnl PKG_CHECK_MODULES(GSTUFF, gtk+-2.0 >= 1.3 glib = 1.3.4, action-if, action-not)
 dnl defines GSTUFF_LIBS, GSTUFF_CFLAGS, see pkg-config man page
 dnl also defines GSTUFF_PKG_ERRORS on error
@@ -1274,6 +1273,44 @@ AC_DEFUN(PKG_CHECK_MODULES, [
   fi
 ])
 
+AC_DEFUN(STEPMAKE_GLIB, [
+PKG_CHECK_MODULES(GLIB, $1 >= $3, have_glib=yes, true)
+if test "$have_glib" = yes; then
+	AC_DEFINE(HAVE_GLIB)
+save_CPPFLAGS="$CPPFLAGS"
+save_LIBS="$LIBS"
+	CPPFLAGS="$GLIB_CFLAGS $CPPFLAGS"
+	LIBS="$GLIB_LIBS $LIBS"
+	AC_SUBST(GLIB_CFLAGS)
+	AC_SUBST(GLIB_LIBS)
+	CPPFLAGS="$save_CPPFLAGS"
+	LIBS="$save_LIBS"
+else
+  r="libglib-dev or glib?-devel"
+  ver="`pkg-config --modversion $1`"
+  STEPMAKE_ADD_ENTRY($2, ["$r >= $3 (installed: $ver)"])
+fi
+])
+
+AC_DEFUN(STEPMAKE_GOBJECT, [
+PKG_CHECK_MODULES(GOBJECT, $1 >= $3, have_gobject=yes, true)
+if test "$have_gobject" = yes; then
+	AC_DEFINE(HAVE_GOBJECT)
+save_CPPFLAGS="$CPPFLAGS"
+save_LIBS="$LIBS"
+	CPPFLAGS="$GOBJECT_CFLAGS $CPPFLAGS"
+	LIBS="$GOBJECT_LIBS $LIBS"
+	AC_SUBST(GOBJECT_CFLAGS)
+	AC_SUBST(GOBJECT_LIBS)
+	CPPFLAGS="$save_CPPFLAGS"
+	LIBS="$save_LIBS"
+else
+  r="libgobject-dev or gobject?-devel"
+  ver="`pkg-config --modversion $1`"
+  STEPMAKE_ADD_ENTRY($2, ["$r >= $3 (installed: $ver)"])
+fi
+])
+
 AC_DEFUN(STEPMAKE_FREETYPE2, [
 PKG_CHECK_MODULES(FREETYPE2, $1 >= $3, have_freetype2=yes, true)
 if test "$have_freetype2" = yes; then
diff --git a/config.make.in b/config.make.in
index 420600ae8e..e3d7cec0ef 100644
--- a/config.make.in
+++ b/config.make.in
@@ -15,12 +15,15 @@ FREETYPE2_CFLAGS = @FREETYPE2_CFLAGS@
 GUILE_CFLAGS = @GUILE_CFLAGS@
 PANGO_FT2_CFLAGS = @PANGO_FT2_CFLAGS@
 PYTHON_CFLAGS = @PYTHON_CFLAGS@
+GLIB_CLFAGS = @GLIB_CFLAGS@ @GOBJECT_CFLAGS@
 
 CONFIG_CPPFLAGS = @CPPFLAGS@
 CONFIG_DEFINES = @DEFINES@
 
-CONFIG_CFLAGS = @CFLAGS@ $(GUILE_CFLAGS) $(FREETYPE2_CFLAGS) $(PANGO_FT2_CFLAGS)
-CONFIG_CXXFLAGS = @CXXFLAGS@ $(GUILE_CFLAGS) $(FREETYPE2_CFLAGS) $(PANGO_FT2_CFLAGS)
+CONFIG_CFLAGS = @CFLAGS@ $(GLIB_CFLAGS) $(GUILE_CFLAGS) \
+ $(FREETYPE2_CFLAGS) $(PANGO_FT2_CFLAGS)
+CONFIG_CXXFLAGS = @CXXFLAGS@ $(GUILE_CFLAGS) $(FREETYPE2_CFLAGS) \
+ $(PANGO_FT2_CFLAGS)
 
 FONTCONFIG_LIBS = @FONTCONFIG_LIBS@
 GUILE_LIBS = @GUILE_LDFLAGS@
@@ -28,8 +31,11 @@ FREETYPE2_LIBS = @FREETYPE2_LIBS@
 PANGO_FT2_LIBS = @PANGO_FT2_LIBS@
 PYTHON_LIBS = @PYTHON_LDFLAGS@
 CXXABI_LIBS = @CXXABI_LIBS@
+GLIB_LIBS = @GLIB_LIBS@ @GOBJECT_LIBS@
 
-CONFIG_LIBS = @LIBS@ @EXTRA_LIBS@ $(GUILE_LIBS) $(PANGO_FT2_LIBS) $(FONTCONFIG_LIBS) $(FREETYPE2_LIBS)
+CONFIG_LIBS = @LIBS@ @EXTRA_LIBS@ $(GLIB_LIBS) $(GUILE_LIBS) \
+  $(PANGO_FT2_LIBS) $(FONTCONFIG_LIBS) \
+  $(FREETYPE2_LIBS)
 CONFIG_LDFLAGS = @LDFLAGS@
 
 PACKAGE = @PACKAGE@
diff --git a/configure.ac b/configure.ac
index 0bb574c44d..5ddefb73fa 100644
--- a/configure.ac
+++ b/configure.ac
@@ -295,6 +295,8 @@ if test "$have_pangoft2_with_otf_feature" != yes ; then
 fi
 STEPMAKE_FONTCONFIG(fontconfig, REQUIRED, 2.4.0)
 STEPMAKE_FREETYPE2(freetype2, REQUIRED, 2.1.10)
+STEPMAKE_GLIB(glib-2.0, REQUIRED, 2.38)
+STEPMAKE_GOBJECT(gobject-2.0, REQUIRED, 2.38)
 
 STEPMAKE_WINDOWS
 
-- 
2.22.0

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: stable/2.20 might fail to build

2019-07-04 Thread Knut Petersen 

Hi Werner!


So the `stable' branch should add the file `txi-pt.tex' from upstream,
right?



Yes. And we need to add the filename to the list of copied files in 
grand-replace.py. See attached patch for stable/2.20.

Knut

>From 36e4be23ca414ca9d315d89b94d5a3e4cbb20f4d Mon Sep 17 00:00:00 2001
From: Knut Petersen 
Date: Thu, 4 Jul 2019 11:03:34 +0200
Subject: [PATCH 1/2] Add tex/txi-pt.tex

We need txi-*.tex files for all the languages we
support. Without them, building of lilypond fails.

If you did not experience that problem, you were
lucky and texinfo is installed on your build system.
In that case the system's txi-pt.tex is used, see
Documentation/pt/web.texi2pdf.log.

txi-pt.tex is taken from texinfo 6.1 (we use that
version in gub).
---
 scripts/build/grand-replace.py |  1 +
 tex/txi-pt.tex | 72 ++
 2 files changed, 73 insertions(+)
 create mode 100644 tex/txi-pt.tex

diff --git a/scripts/build/grand-replace.py b/scripts/build/grand-replace.py
index bb038fbf1d..fa7ece14c5 100644
--- a/scripts/build/grand-replace.py
+++ b/scripts/build/grand-replace.py
@@ -50,6 +50,7 @@ copied_files = [
 'txi-hu.tex',
 'txi-it.tex',
 'txi-nl.tex',
+'txi-pt.tex',
 ]
 
 def main ():
diff --git a/tex/txi-pt.tex b/tex/txi-pt.tex
new file mode 100644
index 00..202bf10eaf
--- /dev/null
+++ b/tex/txi-pt.tex
@@ -0,0 +1,72 @@
+% $Id: txi-pt.tex 5191 2013-02-23 00:11:18Z karl $
+% txi-pt.tex -- Portuguese translations for texinfo.tex.
+%
+% Copyright 1999, 2007, 2008 Free Software Foundation, Inc.
+%
+% This program is free software; you can redistribute it and/or modify
+% it under the terms of the GNU General Public License as published by
+% the Free Software Foundation; either version 3 of the License, or (at
+% your option) any later version.
+%
+% This program is distributed in the hope that it will be useful,
+% but WITHOUT ANY WARRANTY; without even the implied warranty of
+% MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+% GNU General Public License for more details.
+%
+% You should have received a copy of the GNU General Public License
+% along with this program.  If not, see .
+%
+% Written by Lalo Martins  at 05 August 1999
+
+\txisetlanguage{portuguese}{2}{3}
+
+\plainnonfrenchspacing
+
+\gdef\putwordAppendix{Ap\^endice}
+\gdef\putwordChapter{Cap\'\ptexi tulo}
+\gdef\putwordfile{Data}
+\gdef\putwordin{em}
+\gdef\putwordInfo{Info}
+\gdef\putwordMethodon{M\'etodo de}
+\gdef\putwordon{em}
+\gdef\putwordof{de}
+\gdef\putwordpage{P\'agina}
+\gdef\putwordsection{se\,c\~ao}
+\gdef\putwordSection{Se\,c\~ao}
+\gdef\putwordsee{veja}
+\gdef\putwordSee{Veja}
+\gdef\putwordShortTOC{Breve Sum\'ario}
+\gdef\putwordTOC{Sum\'ario}
+%%
+\gdef\putwordNoTitle{Sem T\'\ptexi tulo}
+%%
+%% New defintion for the output of months.
+\gdef\putwordMJan{Janeiro}
+\gdef\putwordMFeb{Fevereiro}
+\gdef\putwordMMar{Mar\,co}
+\gdef\putwordMApr{Abril}
+\gdef\putwordMMai{Maio}
+\gdef\putwordMJun{Junho}
+\gdef\putwordMJul{Julho}
+\gdef\putwordMAug{Agosto}
+\gdef\putwordMSep{Setembro}
+\gdef\putwordMOct{Outubro}
+\gdef\putwordMNov{Novembro}
+\gdef\putwordMDec{Dezembro}
+%%
+%% Index handling should also work correct in german
+\gdef\putwordIndexNonexistent{(\'Indice inexistente)}
+\gdef\putwordIndexIsEmpty{(\'Indice vazio)}
+%%
+%% \defmac
+\gdef\putwordDefmac{Macro}
+%% \defspec
+\gdef\putwordDefspec{Forma Especial}
+%% \defivar
+\gdef\putwordDefivar{Vari\'avel de Inst\^ancia}
+%% \defvar
+\gdef\putwordDefvar{Vari\'avel}
+%% \defopt
+\gdef\putwordDefopt{Op\,c\~ao de Usu\'ario}
+%% \deffun
+\gdef\putwordDeffunc{Fun\,c\~ao}
-- 
2.22.0

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

stem.cc - issue 5303 - misplaced notehead (issue 570830043 by pkxgnugi...@runbox.com)

2019-07-04 Thread pkxgnugitcl 

Reviewers: ,

Message:
Passes make, make check and a full make doc.

Description:
stem.cc - issue 5303 - misplaced notehead

In loop calculating the attachments
of chord node heads to stem,
calculate last used position by
_rounding_ to int rather than by
truncating to int.

This fixes issue 5303 (misplaced note head bug).

Also add regression test.

Please review this at https://codereview.appspot.com/570830043/

Affected files (+15, -1 lines):
  A input/regression/misplaced-note-head-bug.ly
  M lily/stem.cc


Index: input/regression/misplaced-note-head-bug.ly
diff --git a/input/regression/misplaced-note-head-bug.ly  
b/input/regression/misplaced-note-head-bug.ly

new file mode 100644
index  
..1e5918631c27039e7f75dbf44c6f215363aaa970

--- /dev/null
+++ b/input/regression/misplaced-note-head-bug.ly
@@ -0,0 +1,14 @@
+\version "2.19.16"
+
+\header {
+
+  texidoc = "Misplaced note head bug (issue 5303) should be fixed."
+
+}
+
+\layout {
+  #(layout-set-staff-size 19)
+}
+
+
+{ 2 \clef bass  }
Index: lily/stem.cc
diff --git a/lily/stem.cc b/lily/stem.cc
index  
37aa40c250934eb08d1bc6f16bd7598671099193..34bf557fca9c538f22c5fe9c3ff85895ab0f2bca  
100644

--- a/lily/stem.cc
+++ b/lily/stem.cc
@@ -626,7 +626,7 @@ Stem::calc_positioning_done (SCM smob)
   else
 parity = true;

-  lastpos = int (p);
+  lastpos = int (round (p));
 }

   return SCM_BOOL_T;



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: misplaced-note-head bug (issue 5303)

2019-07-04 Thread David Kastrup 
Lukas-Fabian Moser  writes:

> To me, this would seem to suggest that the "less invasive" bugfix I
> proposed (by rounding) would in fact preserve the incompleteness in
> the move from int to float calculations that Han-Wen probably
> introduced by accident (unless (*) is motivated in a way I do not
> understand). This would seem to me to suggest that (*) should be
> replaced by a straight "lastpos = p;".

Agreed.

> It all comes down to the question I can't answer due to lack of
> knowledge about the internal workings: What's the rationale for the
> claim that dy can only be integer or .5?

I think short of rewriting everything to use integers again, removing
the int cast seems like the fix more in line with what the code is
currently written to do/be.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: misplaced-note-head bug (issue 5303)

2019-07-04 Thread Lukas-Fabian Moser 



I would think that rounding the int and keeping lastpos as an integer
would be less invasive and I would do that.

It would be less invasive, the question is what the right thing would
be.  Anybody have an idea whether non-integer positions can sensibly be
employed here for, say, chromatic notation systems having three
positions per staff-line?  Or is that all integer in that case?

There's this strange comment in lily/stem.cc:564 that kept worrying me, 
the basic logic being:


  bool parity = true;
  Real lastpos = Real (Staff_symbol_referencer::get_position (heads[0]));

  for (vsize i = 1; i < heads.size (); i++)
    {
  Real p = Staff_symbol_referencer::get_position (heads[i]);
  Real dy = fabs (lastpos - p);

  /*
    dy should always be 0.5, 0.0, 1.0, but provide safety margin
    for rounding errors.
  */
  if (dy < 0.1 + threshold)
    {
  if (parity)
    {

  [move note head to non-default side of stem]

    }
  parity = !parity;
    }
  else
    parity = true;

  lastpos = int (p);
    }

This was introduced by Han-Wen in 2004 (e7cb72c9fce) with the following 
patch:


   bool parity= true;
-  int lastpos = int (Staff_symbol_referencer::get_position (heads[0]));
+  Real lastpos = Real (Staff_symbol_referencer::get_position (heads[0]));
   for (int i=1; i < heads.size (); i ++)
 {
   Real p = Staff_symbol_referencer::get_position (heads[i]);
-  int dy =abs (lastpos- (int)p);
+  Real dy =fabs (lastpos- p);

-  if (dy <= 1)
+  /*
+   dy should always be 0.5, 0.0, 1.0, but provide safety margin
+   for rounding errors.
+  */
+  if (dy < 1.1)
 {
   if (parity)
     {

  [move note head to non-default side of stem]

     }
   parity = !parity;
 }
   else
 parity = true;

   lastpos = int (p); // (*)
 }

That is: Before, although note head positions were floats, they were 
immediately truncated to integers for any calculations. After, they were 
allowed to be floats, but


a) the explicit downcast to int was not removed at (*) (this is where 
the misplaced-note-head-bug arises)
b) a comment was added claiming that the floats should in fact be 
rationals with denominator 2.


To me, this would seem to suggest that the "less invasive" bugfix I 
proposed (by rounding) would in fact preserve the incompleteness in the 
move from int to float calculations that Han-Wen probably introduced by 
accident (unless (*) is motivated in a way I do not understand). This 
would seem to me to suggest that (*) should be replaced by a straight 
"lastpos = p;".


It all comes down to the question I can't answer due to lack of 
knowledge about the internal workings: What's the rationale for the 
claim that dy can only be integer or .5?


Lukas


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

PATCHES - Countdown for July 4th

2019-07-04 Thread James 

Hello,

Here is the current patch countdown list. The next countdown will be on 
July 7th


A quick synopsis of all patches currently in the review process can be 
found here:


http://philholmes.net/lilypond/allura/





Push:

5524 New function css-color (accompanying x11-color) - Urs Liska
https://sourceforge.net/p/testlilyissues/issues/5524
http://codereview.appspot.com/580780043

5512 Use new syntax consistently throughout docs and examples - Valentin 
Villenave

https://sourceforge.net/p/testlilyissues/issues/5512
http://codereview.appspot.com/572640043


Countdown:

5531 NR: 2.10 Arabic Music - include references to hel-arabic.ly - James 
Lowe

https://sourceforge.net/p/testlilyissues/issues/5531
http://codereview.appspot.com/560790043


Review:

No Patches in Review at this time.


New:

5303 layout-set-staff-space confuses chord note head placement in a 
certain situation - James Lowe

https://sourceforge.net/p/testlilyissues/issues/5303
http://codereview.appspot.com/570830043


***

Regards,


James
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: misplaced-note-head bug (issue 5303)

2019-07-04 Thread Benkő Pál 
David Kastrup  ezt írta (időpont: 2019. júl. 4., Cs, 18:16):
>
> "Phil Holmes"  writes:
>
> > - Original Message -
> > From: "Lukas-Fabian Moser" 
> >>
> >> Questions:
> >>
> >> a) How to decide which fix is "better"? (My guess that using floats
> >> might pose the danger of rounding errors adding up until something bad
> >> happens - probably only for huge chords comprising hundreds of notes,
> >> but I'd tend to favor the solution with rounding.)
> >
> >
> > I would think that rounding the int and keeping lastpos as an integer
> > would be less invasive and I would do that.
>
> It would be less invasive, the question is what the right thing would
> be.  Anybody have an idea whether non-integer positions can sensibly be
> employed here for, say, chromatic notation systems having three
> positions per staff-line?  Or is that all integer in that case?

I'd translate such notation to line-positions like '(-6 -3 0 3 6) and
keep integer positions for note heads; don't know whether there are
other systems out there.

p

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: misplaced-note-head bug (issue 5303)

2019-07-04 Thread David Kastrup 
"Phil Holmes"  writes:

> - Original Message - 
> From: "Lukas-Fabian Moser" 
>>
>> Questions:
>>
>> a) How to decide which fix is "better"? (My guess that using floats
>> might pose the danger of rounding errors adding up until something bad
>> happens - probably only for huge chords comprising hundreds of notes,
>> but I'd tend to favor the solution with rounding.)
>
>
> I would think that rounding the int and keeping lastpos as an integer
> would be less invasive and I would do that.

It would be less invasive, the question is what the right thing would
be.  Anybody have an idea whether non-integer positions can sensibly be
employed here for, say, chromatic notation systems having three
positions per staff-line?  Or is that all integer in that case?

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: misplaced-note-head bug (issue 5303)

2019-07-04 Thread Phil Holmes 


- Original Message - 
From: "Lukas-Fabian Moser" 


Questions:

a) How to decide which fix is "better"? (My guess that using floats
might pose the danger of rounding errors adding up until something bad
happens - probably only for huge chords comprising hundreds of notes,
but I'd tend to favor the solution with rounding.)



I would think that rounding the int and keeping lastpos as an integer would 
be less invasive and I would do that.


--
Phil Holmes 



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: misplaced-note-head bug (issue 5303)

2019-07-04 Thread Lukas-Fabian Moser 

Hi James,


a) How to decide which fix is "better"? (My guess that using floats
might pose the danger of rounding errors adding up until something bad
happens - probably only for huge chords comprising hundreds of notes,
but I'd tend to favor the solution with rounding.)

That question is above my pay-grade


I went with my "feeling" described earlier now, heartened by the 
regtests showing no problems that I could spot.



b) Would anybody be willing to shepherd a patch through the review process?

Sure I can do that for you. 'Git format-patch master' if you would be so kind? 
:)

Thanks much! See attached.

c) Does the situation warrant inclusion of a new regression test? (The
example in the bug report on
https://sourceforge.net/p/testlilyissues/issues/5303/ would be suitable
I think.)

Put one in - it's easier to ask for forgiveness than permission right?


I'm sorry - I didn't realize that this can be done by just adding a file 
to input/regression. Done now.


Lukas

>From 36f2d4e768c1a14c668ab5d132099969796cc5fb Mon Sep 17 00:00:00 2001
From: Lukas-Fabian Moser 
Date: Thu, 4 Jul 2019 16:18:50 +0200
Subject: [PATCH] In loop calculating the attachments of chord node heads to
 stem, calculate last used position by _rounding_ to int rather than by
 truncating to int. This fixes issue 5303 (misplaced note head bug).

Also add regression test.
---
 input/regression/misplaced-note-head-bug.ly | 15 +++
 lily/stem.cc|  2 +-
 2 files changed, 16 insertions(+), 1 deletion(-)
 create mode 100644 input/regression/misplaced-note-head-bug.ly

diff --git a/input/regression/misplaced-note-head-bug.ly b/input/regression/misplaced-note-head-bug.ly
new file mode 100644
index 00..2a645f2a57
--- /dev/null
+++ b/input/regression/misplaced-note-head-bug.ly
@@ -0,0 +1,15 @@
+\version "2.19.16"
+
+\header {
+
+  texidoc = "Misplaced note head bug (issue 5303) should be fixed."
+
+}
+
+\layout {
+  #(layout-set-staff-size 19)
+}
+
+
+{ 2 \clef bass  }
+
diff --git a/lily/stem.cc b/lily/stem.cc
index 37aa40c250..34bf557fca 100644
--- a/lily/stem.cc
+++ b/lily/stem.cc
@@ -626,7 +626,7 @@ Stem::calc_positioning_done (SCM smob)
   else
 parity = true;
 
-  lastpos = int (p);
+  lastpos = int (round (p));
 }
 
   return SCM_BOOL_T;
-- 
2.17.1

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: stable/2.20 might fail to build

2019-07-04 Thread Werner LEMBERG 

> During building stable/ 2.20 we have to build the Portuguese
> website. As we have no  txi-pt.tex in the tex/ directory that will
> fail if there is no installation of texinfo on the host system.

So the `stable' branch should add the file `txi-pt.tex' from upstream,
right?

> Before I write a patch: Could someone please explain to me why we
> use txi-*.tex files stored in /tex instead of the build system's
> files?

Normally, tex and texinfo are not distributed together – for example,
`TeXLive' doesn't contain texinfo.  I think the idea is thus to enable
a documentation build (using tex) without the need to use texinfo.


Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: stable/2.20 might fail to build

2019-07-04 Thread David Kastrup 
Knut Petersen  writes:

> Hi everybody!
>
> During building stable/ 2.20 we have to build the Portuguese
> website. As we have no  txi-pt.tex in the tex/ directory that will
> fail if there is no installation of texinfo on the host system.
>
> Before I write a patch: Could someone please explain to me why
> we use txi-*.tex files stored in /tex instead of the build system's
> files?

Frequent significant divergence from upstream Texinfo?  I think we had
several Texinfo language supports and features before Texinfo proper had
them.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

stable/2.20 might fail to build

2019-07-04 Thread Knut Petersen 

Hi everybody!

During building stable/ 2.20 we have to build the Portuguese
website. As we have no  txi-pt.tex in the tex/ directory that will
fail if there is no installation of texinfo on the host system.

Before I write a patch: Could someone please explain to me why
we use txi-*.tex files stored in /tex instead of the build system's
files?

Knut





___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: misplaced-note-head bug (issue 5303)

2019-07-04 Thread James Lowe 
Hello

On Thu, 4 Jul 2019 12:31:46 +0200, Lukas-Fabian Moser  wrote:

> Folks,
> 
> only now was I able to do regression tests regarding my proposed fix(es) 
> of the misplaced-note-head-bug (issue 5303):
> 
> The bug is caused by the integer-cast
> 
> lastpos = int (p);
> 
> in lily/stem.cc:629.
> 
> Replacing it by either
> i) lastpos = p; // use float value
> or
> ii) lastpos = int (round (p)) // correctly round to integer
> 
> resolves the bug. Neither variant introduces regressions (differences 
> only in in test-output-distance and rest-dot-position, the latter being, 
> I think, unrelated - the seemingly random position changes of dots to 
> multi-voice simultaneous rests).
> 
> Questions:
> 
> a) How to decide which fix is "better"? (My guess that using floats 
> might pose the danger of rounding errors adding up until something bad 
> happens - probably only for huge chords comprising hundreds of notes, 
> but I'd tend to favor the solution with rounding.)

That question is above my pay-grade

> 
> b) Would anybody be willing to shepherd a patch through the review process?

Sure I can do that for you. 'Git format-patch master' if you would be so kind? 
:)

> 
> c) Does the situation warrant inclusion of a new regression test? (The 
> example in the bug report on 
> https://sourceforge.net/p/testlilyissues/issues/5303/ would be suitable 
> I think.)
> 

Put one in - it's easier to ask for forgiveness than permission right?

James

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: misplaced-note-head bug (issue 5303)

2019-07-04 Thread Lukas-Fabian Moser 

Folks,

only now was I able to do regression tests regarding my proposed fix(es) 
of the misplaced-note-head-bug (issue 5303):


The bug is caused by the integer-cast

lastpos = int (p);

in lily/stem.cc:629.

Replacing it by either
i) lastpos = p; // use float value
or
ii) lastpos = int (round (p)) // correctly round to integer

resolves the bug. Neither variant introduces regressions (differences 
only in in test-output-distance and rest-dot-position, the latter being, 
I think, unrelated - the seemingly random position changes of dots to 
multi-voice simultaneous rests).


Questions:

a) How to decide which fix is "better"? (My guess that using floats 
might pose the danger of rounding errors adding up until something bad 
happens - probably only for huge chords comprising hundreds of notes, 
but I'd tend to favor the solution with rounding.)


b) Would anybody be willing to shepherd a patch through the review process?

c) Does the situation warrant inclusion of a new regression test? (The 
example in the bug report on 
https://sourceforge.net/p/testlilyissues/issues/5303/ would be suitable 
I think.)


Best
Lukas


diff --git a/lily/stem.cc b/lily/stem.cc
index 37aa40c250..2a0f6fef84 100644
--- a/lily/stem.cc
+++ b/lily/stem.cc
@@ -626,7 +626,7 @@ Stem::calc_positioning_done (SCM smob)
   else
 parity = true;
 
-  lastpos = int (p);
+  lastpos = p;
 }
 
   return SCM_BOOL_T;
diff --git a/lily/stem.cc b/lily/stem.cc
index 37aa40c250..34bf557fca 100644
--- a/lily/stem.cc
+++ b/lily/stem.cc
@@ -626,7 +626,7 @@ Stem::calc_positioning_done (SCM smob)
   else
 parity = true;
 
-  lastpos = int (p);
+  lastpos = int (round (p));
 }
 
   return SCM_BOOL_T;
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel