Re: What is holding up 2.20 release?
Answering to myself:
Am Dienstag, den 17.12.2019, 19:58 +0100 schrieb Jonas Hahnfeld:
> Am Samstag, den 16.11.2019, 21:52 +0100 schrieb David Kastrup:
> > a77f387207 Fix musicxml2ly.py / Python 2.4.5 incompatibility
>
> I think it would be good to take this, but it requires
> 78225bc1b3 Chord names clean-up; no more Banter, exceptionsPartial or
> \powerChords.
> because the \powerChords chordkind has a format in the middle (see
> changes in ChordNameEvent).
There's actually an equivalent fix for ChordNameEvent by using the
modulo operator. With the two patches attached, stable/2.20 is passing
a full check with Python 2.4.6 on my system (the first one is actually
the original commit a77f387207 without the changes for ChordNameEvent).
Hope this helps,
Jonas
From 7b7ce029c6aef9aa2665be862605afc0d72f40f0 Mon Sep 17 00:00:00 2001
From: Knut Petersen
Date: Fri, 19 Jul 2019 00:05:00 +0200
Subject: [PATCH 1/2] Fix musicxml2ly.py / Python 2.4.5 incompatibility
In LilyPond 2.19.44 code was introduced that
improved musicxml2ly. Unfortunately, the new
code introduced a dependency on Python 2.7+,
although our installers only provide the
ancient Python 2.4.5.
If our Python 2.4.5 was used to interpret
musicxml2ly, some parts of the generated
lilypond source file were ok, in other parts
every character was paired with an additional
NUL byte. This commit fixes that problem
by adding '.encode('utf-8')' at some places.
A 2nd problem was that str.format() was
used. Unfortunately, str.format() is only
available in python 2.6+. The patch replaces
affected code with syntax compatible to our
Python 2.4.5.
This patch triggered the bug fixed in commit
39c9d91c46 "Fix relocate-preamble.py bug".
Do not cherry-pick without 39c9d91c46!
(cherry picked from commit a77f3872078ca38ca7c269a9195bb579737d0698,
without the changes to chordkind_dict because not all values start
with the format string unless we pick commit 78225bc1b3)
Conflicts:
python/musicexp.py
scripts/musicxml2ly.py
---
python/musicexp.py | 6 ++
python/musicxml.py | 2 +-
scripts/musicxml2ly.py | 5 ++---
3 files changed, 5 insertions(+), 8 deletions(-)
diff --git a/python/musicexp.py b/python/musicexp.py
index 6de0b71b1e..edb753d712 100644
--- a/python/musicexp.py
+++ b/python/musicexp.py
@@ -817,7 +817,7 @@ class Lyrics:
for l in self.lyrics_syllables:
lstr += l
#lstr += "\n}"
-return lstr
+return lstr.encode('utf-8')
class Header:
@@ -2230,9 +2230,7 @@ class StaffGroup:
escape_instrument_string (self.short_instrument_name)))
printer.newline ()
if self.sound:
-printer.dump(
-r'\set {stafftype}.midiInstrument = #"{sound}"'.format(
-stafftype=self.stafftype, sound=self.sound))
+printer.dump (r'\set %s.midiInstrument = #"%s"' % (self.stafftype, self.sound))
printer.newline ()
self.print_ly_contents (printer)
printer.newline ()
diff --git a/python/musicxml.py b/python/musicxml.py
index ae5ca80a59..6b70e02cc5 100644
--- a/python/musicxml.py
+++ b/python/musicxml.py
@@ -43,7 +43,7 @@ class Xml_node:
if not self._children:
return ''
-return ''.join([c.get_text() for c in self._children])
+return ''.join([c.get_text() for c in self._children]).encode('utf-8')
def message(self, msg):
ly.warning(msg)
diff --git a/scripts/musicxml2ly.py b/scripts/musicxml2ly.py
index e89c61ba14..d09973afdc 100755
--- a/scripts/musicxml2ly.py
+++ b/scripts/musicxml2ly.py
@@ -97,8 +97,7 @@ def extract_paper_information(score_partwise):
if 1 < staff_size < 100:
paper.global_staff_size = staff_size
else:
-msg = "paper.global_staff_size {} is too large, using defaults=20".format(
-staff_size)
+msg = "paper.global_staff_size %s is too large, using defaults=20" % staff_size
warnings.warn(msg)
paper.global_staff_size = 20
@@ -1248,7 +1247,7 @@ def musicxml_dynamics_to_lily_event(dynentry):
" = #(make-dynamic-script \"" + dynamicstext + "\")"
needed_additional_definitions.append(dynamicsname)
event = musicexp.DynamicsEvent()
-event.type = dynamicsname
+event.type = dynamicsname.encode('utf-8')
return event
# Convert single-color two-byte strings to numbers 0.0 - 1.0
--
2.24.0
From dc814c70a75dc3f25e3b09e6601c52467ea09451 Mon Sep 17 00:00:00 2001
From: Jonas Hahnfeld
Date: Tue, 17 Dec 2019 21:55:50 +0100
Subject: [PATCH 2/2] Second fix for musicxml2ly with Python 2.4.5
Alternative approach to commit a77f387207 which uses the modulo
operator available in Python 2.4 instead of just concatenating
value and self.kind which doesn't work for 'power'.
---
python/musicexp.py | 2 +-
scripts/musicxml2ly.py | 54 +-
2 files changed, 28 insertions(+), 28
Re: Issue 5621: Improve rehearsal mark position at beginning of staff (issue 547340043 by nine.fierce.ball...@gmail.com)
This patch passes make, make check and a full make doc. diffs as follows Dan's suggested Patch - https://codereview.appspot.com/547340043 Dan's Patch #1: https://cloud-u8zj2dc4b.yourownnet.eu/s/JxCkPH4NKsGDkbg Dan's Patch #3: https://cloud-u8zj2dc4b.yourownnet.eu/s/QXJB753MRD8xNnk Dan's Patch #4: https://cloud-u8zj2dc4b.yourownnet.eu/s/2P7QxpeWRiJdzmM Werner's Original Patch - applies to attached png files at start of ticket. https://codereview.appspot.com/553290043 Werner's original patch Set: https://cloud-u8zj2dc4b.yourownnet.eu/s/x82NgEnwzKKJykj https://codereview.appspot.com/547340043/
Re: What is holding up 2.20 release?
On Dec 17, 2019, at 13:58, Jonas Hahnfeld wrote: > I would also propose to pick the following, more recent commits: > […] > 86de0f8f38 Use a stable sort when ordering MIDI items > 152a281031 Issue 5217: Fix sorting order without outside-staff-priority Pretty please, pick these. I support not picking improvements to the development workflow. A person maintaining 2.20 will need to avoid referring to the 2.21 Contributor's Guide, but hopefully that's understandable. — Dan
Re: What is holding up 2.20 release?
Am 17.12.19 um 19:58 schrieb Jonas Hahnfeld:
3300acdd8d Issue 5532/1: \ottava doesn’t confuse ambitus
04a0052411 Issue 5532/2: add regtest
I think this is a fix for
a1bde20430 Issue 2575/1: Ambitus respects staffLineLayoutFunction
not yet in stable/2.20?
Not really. It fixes a bug I spotted when working on issue 2575 and
which is independent from 2575:
\version "2.19.83"
\new Staff \with {
\consists Ambitus_engraver
}
\relative {
\ottava 1
g'' f e d
\ottava 0
c b a g
}
3300acdd (issue 5532) does a check with scm_is_string which was changed
to Text_interface::is_markup in f1649830 to prevent a regression (issue
5559). This change doesn’t have to be picked because 5559 won’t be picked.
09bc2e2ed7 Issue 5560: remove script-chart.ly
should not be picked because it builds upon previous commits (for
example \henzeshortfermata)
I didn’t think of that when recommending to pick it, yes … And it’s not
really a problem to have script-chart.ly in 2.20 because any new scripts
added in 2.21.xx won’t be added to 2.20 branch, will they?
I just realized how many new features are in master that will be in a
stable release in 2.22.0 for the first time. I’m looking forward to 2.20
and 2.21 release because IIUC that means that release-blocking problems
will be solved and 2.22 can follow soon :) Sadly, I have not found the
time to learn enough about our build system to contribute (if there is
still something left that blocks releases).
Re: What is holding up 2.20 release?
Am Samstag, den 16.11.2019, 21:52 +0100 schrieb David Kastrup: > Carl Sorensen < > c_soren...@byu.edu > > writes: > > > Dear Team, > > > > It seems to me like we are pretty much in shape such that we should > > release 2.20. I'd be fine if we called 2.19.83-1 the 2.20 release, > > even if there are some critical regressions. 2.19.83 is SO much > > better than 2.18.2. > > > > IIUC, the only thing 2.20 is waiting on is for David K. to cherry-pick > > some patches. Is that correct? > > And putting out a new prerelease to be sure that those are ok, and > waiting for the translators to catch up with cherry-picked patches > containing stuff to be translated. > > But the current roadblock is David K. cherry-picking some patches. Here > is a remaining list (not completely up to date with current master, > though not missing much) to check for possible inclusion (assuming I > have not overlooked something important pickable in the sequence > before). If you see something important here (or something not in > current master), put in a word for it. And here's the second half and my thoughts about the commits: > 0e1eeb7838 aclocal.m4: Whitespace and formatting. "No functional change.", not needed to avoid conflicts with the rest of the commits listed below > bc4f5fdc29 Add glib-2.0 and gobject-2.0 library dependency already in stable/2.20, 24e873dcec > 4cc884ee09 ly: turkish-makam.ly - minor edit to sultaniyegah not relevant unless we pick db818c1220, see first half. > 189cfb95ea Doc: NR 2.9 Ancient Notation - add verbatim to @lilypond example > for custodes > 00b4c4c757 Doc: NR - expressive.itely - accidentals for naturals using > pitched trills would pick both > 03f4723afc Issue 5520/1: Improvements to \ambitusAfter > 2b52bc2bf1 Issue 5520/2: add \ambitusAfter to Changes not advisable to pick (as Malte noted, this is a new feature not present in stable/2.20) > 17d3d3a151 Issue 4362/1: head completion uses dotted breves > 49f41bf1c6 Issue 4362/2: add regtest I'm also for picking both (as proposed by Malte), but need to adapt the version statement in the test. > 47f74e11cf Doc: Use new syntax throughout all doc and examples would pick > 1d4717d0db NR: 2.10 Arabic Music - inlcude references to hel-arabic.ly "hel-arabic.ly" doesn't exist in stable/2.20 > 7ecc24c5e8 Issue #5524 New function css-color (accompanying x11-color) pretty large, would not pick > 53739c0ae6 Issue 5303 - Misplaced Notehead would pick, but need to adapt the version statement in the test > 3300acdd8d Issue 5532/1: \ottava doesn’t confuse ambitus > 04a0052411 Issue 5532/2: add regtest I think this is a fix for a1bde20430 Issue 2575/1: Ambitus respects staffLineLayoutFunction not yet in stable/2.20? > c5f63d33bf Add tex/txi-pt.tex would pick > 77b816a48f Issue 5535: Build logging: Improve METAFONT tracing not sure if we want this, it's about logging during the build process > 7583351fbf Optimize tree.gittxt messages reverted below > ebc35cb7b6 web:development: Make Release Numbers more current would pick > 34a114b835 Revert "Optimize tree.gittxt messages" revert of above commit > b62d62e402 Optimize tree.gittxt messages (v 2) I think this is still incorrect (also in master) because the remote might not be called origin. > 39c9d91c46 Fix relocate-preamble.py bug would pick > a77f387207 Fix musicxml2ly.py / Python 2.4.5 incompatibility I think it would be good to take this, but it requires 78225bc1b3 Chord names clean-up; no more Banter, exceptionsPartial or \powerChords. because the \powerChords chordkind has a format in the middle (see changes in ChordNameEvent). > 3f0b5c61a7 Issue 5541: treat CENTER in Side_position_interface::aligned_side would pick > 42c45c5dfc Web: update old links to Ben Lemon tutorials would pick and drop the conflict in Documentation/ja/web/manuals.itexi > cf600cc6f8 mf/README: Describe creation of Emmentaler fonts. would pick > 6b789abd46 ly: hel-arabic - comment out Sahnaz entry "hel-arabic.ly" doesn't exist in stable/2.20 > 2165edafc5 Issue 5551/1: better indexing support > 1eed54e8ff Issue 5551/2: improve generated documentation > 714792a1eb Issue 5552/1: HOWTO.index: new guide for creating index entries > b2799c1823 Issue 5552/2: NR: complete revision of all index entries would like to pick all, but the last one has many conflicts (10+ files) > 227fac3a04 We now need texinfo 6.1 or newer. not sure if that is true without the commits above > e926c294e3 Issue 5553: fix handling of @lilypond[verbatim] > 89036755a7 Replace code.google.com by SourceForge would pick both > 805e6ef94c bach-schenker.ly: Completely revised. > be39d353b7 Rename `Stockhausen_Klavierstueck2' to > `stockhausen-klavierstueckII'. > a6f8381ea4 stockhausen-klavierstueckII: Completely rewritten. would pick these commits > 1d3105fce4 run-and-check: Show output directory in case of error. would pick > 0457814df4 string-tunings-init: Fix typo in Banjo tuning. would pick > 4402d6c545
Re: Issue 5621: Improve rehearsal mark position at beginning of staff (issue 547340043 by nine.fierce.ball...@gmail.com)
On 2019/12/17 17:57:52, Dan Eble wrote: This is ready for a full review now. I don't think any new test cases are required. I haven't looked very deeply into the potential use of an unpure-pure container. It looks like unpure-pure containers are used for vertical placement, They are for things that are dependent on line-breaking. I should have thought this might apply here. and this is horizontal. If that answer is not satisfactory, let me know and I'll spend more time learning about it, but I'd rather work on other things. https://codereview.appspot.com/547340043/
Re: Issue 5621: Improve rehearsal mark position at beginning of staff (issue 547340043 by nine.fierce.ball...@gmail.com)
This is ready for a full review now. I don't think any new test cases are required. I haven't looked very deeply into the potential use of an unpure-pure container. It looks like unpure-pure containers are used for vertical placement, and this is horizontal. If that answer is not satisfactory, let me know and I'll spend more time learning about it, but I'd rather work on other things. https://codereview.appspot.com/547340043/
Re: Issue 5621: Improve rehearsal mark position at beginning of staff (issue 547340043 by nine.fierce.ball...@gmail.com)
let MAKE_SCHEME_CALLBACK... handle overloading This change lets me use both of these functions in Break_alignable_interface: SCM find_parent (SCM); Grob* find_parent (Grob*); An alternative is to mangle one of the names manually, e.g. internal_find_parent. clean up names, division between Scheme/C++ Thanks for the feedback on naming. Are the new callback names better? https://codereview.appspot.com/547340043/
Re: Problems building current stable/2.20 - new python.h requirements (?)
Am Dienstag, den 17.12.2019, 14:06 +0100 schrieb Jonas Hahnfeld:
> Am Dienstag, den 17.12.2019, 12:29 + schrieb
> pkx1...@posteo.net
> :
> > Hello,
> >
> > If I checkout current stable/2.20 and then try to build LilyPond I fail
> > during the 'configure' check with this
> >
> > --snip--
> >
> > ...
> >
> > config.status: creating config.make
> > config.status: creating config.hh
> >
> > ERROR: Please install required programs: Python.h (python-devel,
> > python-dev or libpython-dev package)
> > --snip--
> >
> > Yet if I checkout current master, staging etc. I don't get this.
> >
> > Is this expected - i.e. I know 'stable/2.20' is probably a bit of a
> > misnomer, but I was surprised to find something that was required over
> > and above what current master needed. Or is this something related to
> > all the GUB stuff that has been going on and this will need to be
> > 'ported' into 2.21 (master)?
>
> No, this is commit 2d45d5247e ("Drop requirement for python-devel") in
> master, but not yet in stable/2.20. This is actually on the list of
> commits I'd propose to backport that I sent yesterday...
Nope, sorry for the confusion: [...] that I *wanted* to send yesterday. After
picking some commits, it's actually failing "make check", so I wanted to look
into what's wrong before sending the list.
Jonas
signature.asc
Description: This is a digitally signed message part
Re: Problems building current stable/2.20 - new python.h requirements (?)
Am Dienstag, den 17.12.2019, 12:29 + schrieb pkx1...@posteo.net:
> Hello,
>
> If I checkout current stable/2.20 and then try to build LilyPond I fail
> during the 'configure' check with this
>
> --snip--
>
> ...
>
> config.status: creating config.make
> config.status: creating config.hh
>
> ERROR: Please install required programs: Python.h (python-devel,
> python-dev or libpython-dev package)
> --snip--
>
> Yet if I checkout current master, staging etc. I don't get this.
>
> Is this expected - i.e. I know 'stable/2.20' is probably a bit of a
> misnomer, but I was surprised to find something that was required over
> and above what current master needed. Or is this something related to
> all the GUB stuff that has been going on and this will need to be
> 'ported' into 2.21 (master)?
No, this is commit 2d45d5247e ("Drop requirement for python-devel") in
master, but not yet in stable/2.20. This is actually on the list of
commits I'd propose to backport that I sent yesterday...
Jonas
signature.asc
Description: This is a digitally signed message part
Problems building current stable/2.20 - new python.h requirements (?)
Hello, If I checkout current stable/2.20 and then try to build LilyPond I fail during the 'configure' check with this --snip-- ... config.status: creating config.make config.status: creating config.hh ERROR: Please install required programs: Python.h (python-devel, python-dev or libpython-dev package) --snip-- Yet if I checkout current master, staging etc. I don't get this. Is this expected - i.e. I know 'stable/2.20' is probably a bit of a misnomer, but I was surprised to find something that was required over and above what current master needed. Or is this something related to all the GUB stuff that has been going on and this will need to be 'ported' into 2.21 (master)? I only mention this after trying to test a patch for changes.tely for 2.20's eventual release (https://sourceforge.net/p/testlilyissues/issues/5601/ ) and failing with this requirement. Obviously I can install this stuff but wanted to check on this (for me anyway) unexpected configure error. Thanks. James
Re: Perception of LilyPond development status
Jacques Menu writes: > Hello David, > > Maybe this is totally stupid, but would it be meaningful to pick a > Guile 2 version, fix the issues in string > implementation and design, and freeze that fixed version for Lily’s > own use, without depending on Andy Wingo’s work for some time? By the way, we need to find a solution handling the byte-compiled files of Guile2. I think that's part of our current slowdown but I may be wrong. -- David Kastrup
Re: Perception of LilyPond development status
Jacques Menu writes: > Hello David, > > Maybe this is totally stupid, but would it be meaningful to pick a > Guile 2 version, fix the issues in string > implementation and design, and freeze that fixed version for Lily’s > own use, without depending on Andy Wingo’s work for some time? That "fix" would consist in making Guile strings UTF-8 only. Throw out everything else. Problem is that Scheme has in-place string manipulations that don't work with variable-size characters. It may be that recent Scheme standards have tried to become more UTF-8 friendly, no idea. A beyond-LilyPond fix would turn the internal string coding into some extension of UTF-8 like Emacs does. That is actually also a prerequisite of making something like Guilemacs ever take off. Getting Emacs' string implementation to its current quality took decades. A few seminal points: Code points for large characters are supported (at one point 32-bit characters, but it may be reduced to the theoretic maximum with 4-byte characters these days). Out-of-sequence bytes from 128–255 are represented with 2-byte sequences (overlong representations of 0–127 not valid as UTF-8), valid UTF-8 is represented as itself. That makes any binary data representable with a blow-up factor of at most 2. With Emacs, the details are in the various encoding itty-bitties: the internal processing is comparatively straightforward. Buffers are addressed by character positions, not bytes. The itty-bitty details mostly concern conversion into/out of the internal UTF-8 though and don't have much of an impact on the normal processing. -- David Kastrup
Re: Perception of LilyPond development status
Hello David, Maybe this is totally stupid, but would it be meaningful to pick a Guile 2 version, fix the issues in string implementation and design, and freeze that fixed version for Lily’s own use, without depending on Andy Wingo’s work for some time? JM > Le 14 déc. 2019 à 22:58, David Kastrup a écrit : > > Urs Liska writes: > >> Any LilyPond dev who does have a Facebook account might have a look at >> this interesting, although somewhat sad, discussion. I think it gives >> a clear picture of how our current state of development is perceived >> by users: >> >> https://www.facebook.com/groups/gnulilypond/permalink/10157762793383529/ > > The problem with the "obsolete version of Guile" is that Guile > development is falling apart. The only person actually working on the > development version of Guile is Andy Wingo. He does not participate on > the Guile developer list, he does not bother with bug reports, he does > not take input and does whatever he currently is interested in without > communicating it, and frequently breaking master. What he is interested > in is basically compiler/optimization development. He is not interested > in fixing the performance and design problems with Guile 2+'s string > implementation and design. There are about a dozen developers (probably > less by now) cleaning up on the stable branch, but they cannot do > significant independent development since they cannot coordinate with > the development version. > > This has been the case for 2.2, and it's more so for 2.3. I don't see > that there is a viable way for LilyPond to move forward to "current" > versions of Guile which have become completely unpredictable as a target > as well as as a platform. I think there will not be much of a way > around forking 1.8 and making that work for us as long as no > well-performing string-interface is available that would efficiently > facilitate the C/Scheme string passing density of LilyPond. > > Maybe we can coordinate something with Thien-Thi Nguyen who has been > keeping the Guile-1.8 branch tip in the official Guile repository from > bitrot due to Texinfo and language changes. > > -- > David Kastrup >
Re: Issue 5621: Improve rehearsal mark position at beginning of staff (issue 547340043 by nine.fierce.ball...@gmail.com)
This patch passes make, make check and a full make doc. Dan's 17th Dec (2nd) patch's reg test diffs are here: https://cloud-u8zj2dc4b.yourownnet.eu/s/QXJB753MRD8xNnk older: Dan's 15th Dec (1st) patch's reg test diffs are here: https://cloud-u8zj2dc4b.yourownnet.eu/s/JxCkPH4NKsGDkbg Werner's patch's reg test diffs are here: https://cloud-u8zj2dc4b.yourownnet.eu/s/x82NgEnwzKKJykj https://codereview.appspot.com/547340043/
Re: Introduce breakingRehearsalMarks for line-breaking RehearsalMarks (issue 577180043 by thomasmorle...@gmail.com)
Dan, I've set it to needs_work for now. https://codereview.appspot.com/577180043/
PATCHES - Countdown for December 17th
Hello, Here is the current patch countdown list. The next countdown will be on December 19th. A quick synopsis of all patches currently in the review process can be found here: http://philholmes.net/lilypond/allura/ Push: 5637 Port lilysong to subprocess module - Jonas Hahnfeld https://sourceforge.net/p/testlilyissues/issues/5637 http://codereview.appspot.com/561240043 5636 fix various warnings - Dan Eble https://sourceforge.net/p/testlilyissues/issues/5636 http://codereview.appspot.com/583200043 5635 show new regression-test cases - Dan Eble https://sourceforge.net/p/testlilyissues/issues/5635 http://codereview.appspot.com/577190043 5310 find_top_context () instead of get_global_context () - Dan Eble https://sourceforge.net/p/testlilyissues/issues/5310 http://codereview.appspot.com/565320043 Countdown: 5643 Only sort distances in output-distance.py - Jonas Hahnfeld https://sourceforge.net/p/testlilyissues/issues/5643 http://codereview.appspot.com/571260043 5642 rational.py: Switch to Rich Comparisons - Jonas Hahnfeld https://sourceforge.net/p/testlilyissues/issues/5642 http://codereview.appspot.com/561250043 5640 Fix regtests about Footnote - Thomas Morley https://sourceforge.net/p/testlilyissues/issues/5640 http://codereview.appspot.com/549320043 5639 compile with -std=c++11 - Dan Eble https://sourceforge.net/p/testlilyissues/issues/5639 http://codereview.appspot.com/553310045 Review: 5631 Introduce breakingRehearsalMarks for line-breaking RehearsalMarks - Thomas Morley https://sourceforge.net/p/testlilyissues/issues/5631 http://codereview.appspot.com/577180043 New: 5621 Improve positioning of rehearsal marks at the beginning of staff - Werner LEMBERG https://sourceforge.net/p/testlilyissues/issues/5621 http://codereview.appspot.com/553290043 *** Regards, James
