Re: Python 3
Hello,
On 21/09/2019 17:57, Werner LEMBERG wrote:
[...] I've split the third patch ("Fix musicxml2ly with Python 3")
into four smaller logical groups. I don't really mind which version
is applied, the outcome is the same.
LGTM, thanks.
Werner
___
Sorry for jumping in here.
I assume the testing of this is going to be done 'without' me?
Or do I need to help here (in whatever way I can) with regard to testing
Python3 patches?
I'm not set up to use GUB or anything specific with my own make env.
Let me know what, if anything, I can do to help.
James
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: updated Stockhausen example
>>I have a hard time imagining a performer bringing this to life in a >>manner justifying the complexity written into the score. > > Why? > > It seems you haven"t heard enough of today"s highly qualified and > dedicated performers ... It's not about performing this notation. I'm sure this could be *much* simpler notated, and nobody listening to it would hear a difference. At least for ensemble music this makes a huge difference IMHO – the simpler the score, the less rehearsal time you need, and the better the performance is. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: updated Stockhausen example
>> Here's an updated version of the Stockhausen example, with a lot of >> added comments to the source code. > > Looking at the image, this appears more to the credit of LilyPond > than Stockhausen. I have a hard time imagining a performer bringing > this to life in a manner justifying the complexity written into the > score. I fully agree. However, this is serial music, and later works are explicitly written for (programmable) synthesizers, which Stockhausen saw as the natural extension of a piano. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: updated Stockhausen example
Am 21. September 2019 19:09:55 MESZ schrieb David Kastrup : >Werner LEMBERG writes: > >> Here's an updated version of the Stockhausen example, with a lot of >> added comments to the source code. >> >> I've also attached an image of rendering the old code (as present in >> the git) with a lilypond binary from current git. > >[...] > >Looking at the image, this appears more to the credit of LilyPond than >Stockhausen. I have a hard time imagining a performer bringing this to >life in a manner justifying the complexity written into the score. Why? It seems you haven"t heard enough of today"s highly qualified and dedicated performers ... Urs > >-- >David Kastrup > >___ >lilypond-devel mailing list >lilypond-devel@gnu.org >https://lists.gnu.org/mailman/listinfo/lilypond-devel -- Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: updated Stockhausen example
Werner LEMBERG writes: > Here's an updated version of the Stockhausen example, with a lot of > added comments to the source code. > > I've also attached an image of rendering the old code (as present in > the git) with a lilypond binary from current git. [...] Looking at the image, this appears more to the credit of LilyPond than Stockhausen. I have a hard time imagining a performer bringing this to life in a manner justifying the complexity written into the score. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: updated Stockhausen example
> I've also attached an image of rendering the old code (as present in > the git) with a lilypond binary from current git. For reference, here's an image of the original score. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Python 3
> [...] I've split the third patch ("Fix musicxml2ly with Python 3")
> into four smaller logical groups. I don't really mind which version
> is applied, the outcome is the same.
LGTM, thanks.
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Python 3
Am Samstag, den 21.09.2019, 13:43 +0200 schrieb Werner LEMBERG:
> >> Well, I prefer a series of patches instead of a single patch.
>
> >
>
> > Ok, I'll split the third one. My concern was that a single part of
>
> > the series won't bring any benefit on its own. So for example only
>
> > changing the division operator will not make musicxml2ly work with
>
> > Python 3.
>
>
> In case there are patches within a series of patches that don't
> compile, please say that in the commit message for the benefit of `git
> bisect'. I think it is better to have smaller, easily comprehensible
> but probably uncompilable changes than a single, working chunk that is
> hard to read.
All patches in the progress of porting to Python 3 won't fully work
until all remaining issues are fixed.
That said, I've split the third patch ("Fix musicxml2ly with Python 3")
into four smaller logical groups. I don't really mind which version is
applied, the outcome is the same.
Regards,
Jonas
From d14e98aacdac0a600108fce9bb1fd278ac9cd3df Mon Sep 17 00:00:00 2001
From: Jonas Hahnfeld
Date: Sat, 21 Sep 2019 13:47:08 +0200
Subject: [PATCH 1/4] musicxml: Replace new.classobj() by type() for Python 3
---
python/musicxml.py | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/python/musicxml.py b/python/musicxml.py
index e1ddeb20e4..ecb0d0581f 100644
--- a/python/musicxml.py
+++ b/python/musicxml.py
@@ -1,5 +1,4 @@
# -*- coding: utf-8 -*-
-#import new
import string
from rational import *
import re
@@ -1794,7 +1793,7 @@ def get_class(name):
return classname
else:
class_name = name2class_name(name)
-klass = new.classobj(class_name,(Music_xml_node,) , {})
+klass = type(class_name,(Music_xml_node,) , {})
class_dict[name] = klass
return klass
--
2.23.0
From 269eec622002f379b18e04eeba59aa430631cb0c Mon Sep 17 00:00:00 2001
From: Jonas Hahnfeld
Date: Sat, 21 Sep 2019 13:37:33 +0200
Subject: [PATCH 2/4] musicxml2ly: Fix calls to functions from string
---
python/musicexp.py | 21 ++---
python/musicxml.py | 9 -
python/utilities.py| 2 +-
scripts/musicxml2ly.py | 25 -
4 files changed, 27 insertions(+), 30 deletions(-)
diff --git a/python/musicexp.py b/python/musicexp.py
index 29161432f1..d1eb05 100644
--- a/python/musicexp.py
+++ b/python/musicexp.py
@@ -1,7 +1,6 @@
# -*- coding: utf-8 -*-
import inspect
import sys
-import string
import re
import math
import lilylib as ly
@@ -19,7 +18,7 @@ whatOrnament = ""
ly_dur = None # stores lilypond durations
def escape_instrument_string (input_string):
-retstring = string.replace (input_string, "\"", "\\\"")
+retstring = input_string.replace("\"", "\\\"")
if re.match ('.*[\r\n]+.*', retstring):
rx = re.compile (r'[\n\r]+')
strings = rx.split (retstring)
@@ -529,7 +528,7 @@ class Music:
printer.newline ()
return
-lines = string.split (text, '\n')
+lines = text.split('\n')
for l in lines:
if l:
printer.unformatted_output ('% ' + l)
@@ -692,11 +691,11 @@ class NestedMusic(Music):
def get_properties (self):
return ("'elements (list %s)"
-% string.join ([x.lisp_expression() for x in self.elements]))
+% ' '.join ([x.lisp_expression() for x in self.elements]))
def get_subset_properties (self, predicate):
return ("'elements (list %s)"
-% string.join ([x.lisp_expression() for x in list(filter (predicate, self.elements))]))
+% ' '.join ([x.lisp_expression() for x in list(filter (predicate, self.elements))]))
def get_neighbor (self, music, dir):
assert music.parent == self
idx = self.elements.index (music)
@@ -1036,7 +1035,7 @@ class ChordEvent (NestedMusic):
basepitch = previous_pitch
if stem:
printer (stem.ly_expression ())
-printer ('<%s>' % string.join (pitches))
+printer ('<%s>' % ' '.join (pitches))
previous_pitch = basepitch
duration = self.get_duration ()
if duration:
@@ -1475,7 +1474,7 @@ class FretBoardEvent (NestedMusic):
notes = []
for n in fretboard_notes:
notes.append (n.ly_expression ())
- contents = string.join (notes)
+ contents = ' '.join (notes)
printer ('<%s>%s' % (contents,self.duration))
class FunctionWrapperEvent (Event):
@@ -1665,7 +1664,7 @@ class RhythmicEvent(Event):
return [ev.pre_note_ly (is_chord_element) for ev in self.associated_events]
def ly_expression_pre_note (self, is_chord_element):
-res = string.join (self.pre_note_ly (is_chord_element), ' ')
+res = ' '.join (self.pre_note_ly (is_chord_element))
if res != '':
res = res + ' '
return res
@@ -1813,7 +1812,7 @@
Re: Python 3
>> Well, I prefer a series of patches instead of a single patch. > > Ok, I'll split the third one. My concern was that a single part of > the series won't bring any benefit on its own. So for example only > changing the division operator will not make musicxml2ly work with > Python 3. In case there are patches within a series of patches that don't compile, please say that in the commit message for the benefit of `git bisect'. I think it is better to have smaller, easily comprehensible but probably uncompilable changes than a single, working chunk that is hard to read. But maybe others on the list think differently... Indeed, it would be a good idea IMHO to mention the preferred way in the contributor guide. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Python 3
Jonas Hahnfeld via lilypond-devel writes: > Am Samstag, den 21.09.2019, 13:09 +0200 schrieb Werner LEMBERG: >> >> `git add -p' is your friend to do that conveniently. >> >> > >> >> > Sure, that is the usual suggestion. But I'm not sure if that is >> >> > really helpful here because none of these changes will do anything >> >> > on its own. >> >> >> What do you mean with `none will do anything on its own'? >> >> > So my question is whether the patch is too large to go as one "fix >> >> > that script for Python 3"? >> >> >> Well, I prefer a series of patches instead of a single patch. > > Ok, I'll split the third one. My concern was that a single part of the > series won't bring any benefit on its own. So for example only > changing the division operator will not make musicxml2ly work with > Python 3. Personally I am here more with you than with Werner here: as long as all changes are of a similar character not achieving an identifiable goal of their own (or being the result of running some script that may warrant rerunning because of required fixes or because of getting applied to a different branch with different code in it), I don't see the point into splitting them into separate commits. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Python 3
Am Samstag, den 21.09.2019, 13:09 +0200 schrieb Werner LEMBERG: > >> `git add -p' is your friend to do that conveniently. > > > > > > Sure, that is the usual suggestion. But I'm not sure if that is > > > really helpful here because none of these changes will do anything > > > on its own. > > > What do you mean with `none will do anything on its own'? > > > So my question is whether the patch is too large to go as one "fix > > > that script for Python 3"? > > > Well, I prefer a series of patches instead of a single patch. Ok, I'll split the third one. My concern was that a single part of the series won't bring any benefit on its own. So for example only changing the division operator will not make musicxml2ly work with Python 3. Jonas signature.asc Description: This is a digitally signed message part ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Python 3
>> `git add -p' is your friend to do that conveniently. > > Sure, that is the usual suggestion. But I'm not sure if that is > really helpful here because none of these changes will do anything > on its own. What do you mean with `none will do anything on its own'? > So my question is whether the patch is too large to go as one "fix > that script for Python 3"? Well, I prefer a series of patches instead of a single patch. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Python 3
> If I remember correctly, this will be the time that we definitely > have to retire the PowerPC MacOSX version (it's not clear anybody is > actually using it, though). Hmm. Looking into MacPorts, I don't see any restriction for using python 3.7 on PowerPC. It seems that OS X 10.4 and 10.5 are still supported, which is good. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Python 3
Jonas Hahnfeld writes: > Am Samstag, den 21.09.2019, 11:25 +0200 schrieb David Kastrup: > >> I haven't checked yet, but at the current point of time, the best >> patches will be those running under both Python 2 and Python 3 without >> having to special-case code. Those can be applied to master and thus >> minimize the actual amount of code switching we ultimately need to do. > > I agree that this would be ideal, but pretty hard: Already the result > of running 2to3 can't be executed under Python 2 in some cases or may > start to give different results. Examples include > * "isinstance(s, unicode)" -> "isinstance(s, str)", which is something > different in Python 2, and > * "import StringIO" -> "import io", which didn't have all functions in > Python 2. > > If that is the way required to get Lilypond ported to Python 3, I can > try to work into that direction. But finally, I guess there will need > to be a hard switch to Python 3... I think the principal problem is that I don't see us providing a GUB installer with both Python2 and Python3 in it. So code that does not run in both will need to get switched over at the time we switch GUB from Python2 to Python3. If I remember correctly, this will be the time that we definitely have to retire the PowerPC MacOSX version (it's not clear anybody is actually using it, though). -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Python 3
Am Samstag, den 21.09.2019, 11:25 +0200 schrieb David Kastrup: > Jonas Hahnfeld via lilypond-devel < > lilypond-devel@gnu.org > > writes: > > > Am Samstag, den 21.09.2019, 12:09 +1000 schrieb Andrew Bernard: > > > So let me get this straight. > > > > > > It's not the case that GUB is completely broken. We can still build > > > releases. > > > > > > DK is working steadily to cherry pick items for 2.20. > > > > > > Python 2 to Python 3 is a major issue. > > > > > > So, I offered to do the 2->3 port a long time ago but circumstances > > > prevented me from doing so. Would it be constructive if I launched into > > > that aspect? I cant understand the lilypond internals code but I have > > > extensive Python experience. > > > > > > Would this be helpful to moving forward? > > > > > > But have people already started on this, I thought? > > > > I've also started looking into this and used the branch > > dev/knupero/lilypy3devel as a starting point (see also > > https://lists.gnu.org/archive/html/bug-lilypond/2019-08/msg00014.html > > ). > > > > On top of that I've worked on the attached patches which brings the > > make targets check / test and doc back to life with Python 3.7.4. Maybe > > they can be added to the branch mentioned above to serve as a single > > source of truth? I know the third patch is pretty large, let me know if > > I should try to split it up... > > > > As I'm pretty new to the development of Lilypond, I'm not really sure > > if there's something else to do in the source code repository itself? > > I'm pretty sure I didn't get to run through all error branches in all > > scripts, but the targets mentioned in the documentation work for me > > right now. If not, sounds like working on GUB would be next? > > I haven't checked yet, but at the current point of time, the best > patches will be those running under both Python 2 and Python 3 without > having to special-case code. Those can be applied to master and thus > minimize the actual amount of code switching we ultimately need to do. I agree that this would be ideal, but pretty hard: Already the result of running 2to3 can't be executed under Python 2 in some cases or may start to give different results. Examples include * "isinstance(s, unicode)" -> "isinstance(s, str)", which is something different in Python 2, and * "import StringIO" -> "import io", which didn't have all functions in Python 2. If that is the way required to get Lilypond ported to Python 3, I can try to work into that direction. But finally, I guess there will need to be a hard switch to Python 3... My 2 cents, Jonas signature.asc Description: This is a digitally signed message part ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Python 3
Am Samstag, den 21.09.2019, 11:20 +0200 schrieb Werner LEMBERG:
> >> So, I offered to do the 2->3 port a long time ago but circumstances
>
> >> prevented me from doing so. Would it be constructive if I launched
>
> >> into that aspect?
>
>
> Yes, definitely.
>
> > I've also started looking into this and used the branch
>
> > dev/knupero/lilypy3devel as a starting point (see also
>
> >
> https://lists.gnu.org/archive/html/bug-lilypond/2019-08/msg00014.html
> ).
>
>
> Yep.
>
> > On top of that I've worked on the attached patches which brings the
>
> > make targets check / test and doc back to life with Python 3.7.4.
>
> > Maybe they can be added to the branch mentioned above to serve as a
>
> > single source of truth? I know the third patch is pretty large, let
>
> > me know if I should try to split it up...
>
>
> I hope Knut will do that soon.
>
> Regarding patch size: I suggest that you group mechanical changes into
> separate patches, for example all changes related to
>
> / → //
>
> and
>
> decode('utf-8')
>
> could be two patches.
>
> `git add -p' is your friend to do that conveniently.
Sure, that is the usual suggestion. But I'm not sure if that is really
helpful here because none of these changes will do anything on its own.
So my question is whether the patch is too large to go as one "fix that
script for Python 3"?
> > As I'm pretty new to the development of Lilypond, I'm not really
>
> > sure if there's something else to do in the source code repository
>
> > itself? I'm pretty sure I didn't get to run through all error
>
> > branches in all scripts, but the targets mentioned in the
>
> > documentation work for me right now. If not, sounds like working on
>
> > GUB would be next?
>
>
> Getting acquainted with GUB is certainly very helpful. You might also
> look up the various issues in the bug tracker; maybe you find
> something that interests you.
I was more referring to tasks related to Python 3...
Thanks,
Jonas
signature.asc
Description: This is a digitally signed message part
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Python 3
Jonas Hahnfeld via lilypond-devel writes: > Am Samstag, den 21.09.2019, 12:09 +1000 schrieb Andrew Bernard: >> So let me get this straight. >> >> It's not the case that GUB is completely broken. We can still build >> releases. >> >> DK is working steadily to cherry pick items for 2.20. >> >> Python 2 to Python 3 is a major issue. >> >> So, I offered to do the 2->3 port a long time ago but circumstances >> prevented me from doing so. Would it be constructive if I launched into >> that aspect? I cant understand the lilypond internals code but I have >> extensive Python experience. >> >> Would this be helpful to moving forward? >> >> But have people already started on this, I thought? > > I've also started looking into this and used the branch > dev/knupero/lilypy3devel as a starting point (see also > https://lists.gnu.org/archive/html/bug-lilypond/2019-08/msg00014.html). > > On top of that I've worked on the attached patches which brings the > make targets check / test and doc back to life with Python 3.7.4. Maybe > they can be added to the branch mentioned above to serve as a single > source of truth? I know the third patch is pretty large, let me know if > I should try to split it up... > > As I'm pretty new to the development of Lilypond, I'm not really sure > if there's something else to do in the source code repository itself? > I'm pretty sure I didn't get to run through all error branches in all > scripts, but the targets mentioned in the documentation work for me > right now. If not, sounds like working on GUB would be next? I haven't checked yet, but at the current point of time, the best patches will be those running under both Python 2 and Python 3 without having to special-case code. Those can be applied to master and thus minimize the actual amount of code switching we ultimately need to do. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.20 where are we?
Andrew Bernard writes: > So let me get this straight. > > It's not the case that GUB is completely broken. We can still build > releases. It's not broken _yet_ because Python 2 is still more or less available and of course we can keep using it (ignoring security issues) as long as we want. This will hit the native builds first. There have been some hits concerning Ghostscript that are currently in check but may come back. Also some other issues. > DK is working steadily to cherry pick items for 2.20. I'd not use the label "steadily" here. > Python 2 to Python 3 is a major issue. > > So, I offered to do the 2->3 port a long time ago but circumstances > prevented me from doing so. Would it be constructive if I launched > into that aspect? I cant understand the lilypond internals code but I > have extensive Python experience. > > Would this be helpful to moving forward? > > But have people already started on this, I thought? Kurt had started on it but asked for help getting more done. I don't know to what degrees others have actually stepped in also, but it's not like one could not share work by arranging who ports what. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Python 3
>> So, I offered to do the 2->3 port a long time ago but circumstances
>> prevented me from doing so. Would it be constructive if I launched
>> into that aspect?
Yes, definitely.
> I've also started looking into this and used the branch
> dev/knupero/lilypy3devel as a starting point (see also
> https://lists.gnu.org/archive/html/bug-lilypond/2019-08/msg00014.html).
Yep.
> On top of that I've worked on the attached patches which brings the
> make targets check / test and doc back to life with Python 3.7.4.
> Maybe they can be added to the branch mentioned above to serve as a
> single source of truth? I know the third patch is pretty large, let
> me know if I should try to split it up...
I hope Knut will do that soon.
Regarding patch size: I suggest that you group mechanical changes into
separate patches, for example all changes related to
/ → //
and
decode('utf-8')
could be two patches.
`git add -p' is your friend to do that conveniently.
> As I'm pretty new to the development of Lilypond, I'm not really
> sure if there's something else to do in the source code repository
> itself? I'm pretty sure I didn't get to run through all error
> branches in all scripts, but the targets mentioned in the
> documentation work for me right now. If not, sounds like working on
> GUB would be next?
Getting acquainted with GUB is certainly very helpful. You might also
look up the various issues in the bug tracker; maybe you find
something that interests you.
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Python 3 (was: 2.20 where are we?)
Am Samstag, den 21.09.2019, 12:09 +1000 schrieb Andrew Bernard:
> So let me get this straight.
>
> It's not the case that GUB is completely broken. We can still build
> releases.
>
> DK is working steadily to cherry pick items for 2.20.
>
> Python 2 to Python 3 is a major issue.
>
> So, I offered to do the 2->3 port a long time ago but circumstances
> prevented me from doing so. Would it be constructive if I launched into
> that aspect? I cant understand the lilypond internals code but I have
> extensive Python experience.
>
> Would this be helpful to moving forward?
>
> But have people already started on this, I thought?
I've also started looking into this and used the branch
dev/knupero/lilypy3devel as a starting point (see also
https://lists.gnu.org/archive/html/bug-lilypond/2019-08/msg00014.html).
On top of that I've worked on the attached patches which brings the
make targets check / test and doc back to life with Python 3.7.4. Maybe
they can be added to the branch mentioned above to serve as a single
source of truth? I know the third patch is pretty large, let me know if
I should try to split it up...
As I'm pretty new to the development of Lilypond, I'm not really sure
if there's something else to do in the source code repository itself?
I'm pretty sure I didn't get to run through all error branches in all
scripts, but the targets mentioned in the documentation work for me
right now. If not, sounds like working on GUB would be next?
Regards,
Jonas
From f6595ce68dc47e4e60f94dd8b80dbd5573e4c360 Mon Sep 17 00:00:00 2001
From: Jonas Hahnfeld
Date: Thu, 19 Sep 2019 20:26:25 +0200
Subject: [PATCH 1/5] lilylib: sys.stderr.write expects strings
... not encoded bytes. This fixes the first error when running the
check / test target.
---
python/lilylib.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/python/lilylib.py b/python/lilylib.py
index 3850f4e2a3..ef156115a5 100644
--- a/python/lilylib.py
+++ b/python/lilylib.py
@@ -127,7 +127,7 @@ def is_verbose ():
return is_loglevel ("DEBUG")
def stderr_write (s):
-encoded_write (sys.stderr, s)
+sys.stderr.write (s)
def print_logmessage (level, s, fullmessage = True, newline = True):
if (is_loglevel (level)):
--
2.23.0
From 5630b85ec8d9a7344009a221916ba87904287848 Mon Sep 17 00:00:00 2001
From: Jonas Hahnfeld
Date: Thu, 19 Sep 2019 19:56:24 +0200
Subject: [PATCH 2/5] Read linking files in binary mode
This fixes the check / test target up to musicxml.
---
python/book_snippets.py | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/python/book_snippets.py b/python/book_snippets.py
index b84c269e6a..0a2f3fbb31 100644
--- a/python/book_snippets.py
+++ b/python/book_snippets.py
@@ -645,12 +645,11 @@ printing diff against existing file." % filename)
try:
if (self.global_options.use_source_file_names
and isinstance (self, LilypondFileSnippet)):
-fout = open (dst, 'w')
-fin = open (src, 'r')
-for line in fin.readlines ():
-fout.write (line.replace (self.basename (), self.final_basename ()))
-fout.close ()
-fin.close ()
+content = open (src, 'rb').read ()
+basename = self.basename ().encode ('utf-8')
+final_basename = self.final_basename ().encode ('utf-8')
+content = content.replace (basename, final_basename)
+open (dst, 'wb').write (content)
else:
try:
os.link (src, dst)
--
2.23.0
From 99a7c48d8c331f5a0a61884905c140ec654b3b8f Mon Sep 17 00:00:00 2001
From: Jonas Hahnfeld
Date: Wed, 18 Sep 2019 21:56:02 +0200
Subject: [PATCH 3/5] Fix musicxml2ly with Python 3
This passes the targets doc and check / test.
---
python/book_snippets.py | 24 +
python/musicexp.py | 29 ++--
python/musicxml.py | 20 +++---
python/rational.py | 13 ++---
python/utilities.py | 2 +-
scripts/musicxml2ly.py | 60 -
6 files changed, 76 insertions(+), 72 deletions(-)
diff --git a/python/book_snippets.py b/python/book_snippets.py
index 0a2f3fbb31..0f7888bcb9 100644
--- a/python/book_snippets.py
+++ b/python/book_snippets.py
@@ -605,7 +605,8 @@ class LilypondSnippet (Snippet):
if self.relevant_contents (existing) != self.relevant_contents (self.full_ly ()):
warning ("%s: duplicate filename but different contents of original file,\n\
printing diff against existing file." % filename)
-ly.stderr_write (self.filter_pipe (self.full_ly (), 'diff -u %s -' % filename))
+diff_against_existing = self.filter_pipe (self.full_ly ().encode ('utf-8'), 'diff -u %s -' % filename)
+ly.stderr_write
Re: 2.20 where are we?
Am 21. September 2019 04:09:36 MESZ schrieb Andrew Bernard : >So let me get this straight. > >It's not the case that GUB is completely broken. We can still build >releases. > >DK is working steadily to cherry pick items for 2.20. > >Python 2 to Python 3 is a major issue. > >So, I offered to do the 2->3 port a long time ago but circumstances >prevented me from doing so. Would it be constructive if I launched into > >that aspect? I cant understand the lilypond internals code but I have >extensive Python experience. > >Would this be helpful to moving forward? > This may be an even more important way to help than with the teo Frescobaldi topics I suggested to you. >But have people already started on this, I thought? > IIRC there were some things done or st least planned but surely nothing that should prevent you from joining ... Best Urs > >Andrew > > > >___ >lilypond-devel mailing list >lilypond-devel@gnu.org >https://lists.gnu.org/mailman/listinfo/lilypond-devel -- Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
