2.20 where are we?

classic Classic list List threaded Threaded
31 messages Options
12
Reply | Threaded
Open this post in threaded view
|

2.20 where are we?

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?


Andrew



_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: 2.20 where are we?

Urs Liska-3


Am 21. September 2019 04:09:36 MESZ schrieb Andrew Bernard <[hidden email]>:

>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
>[hidden email]
>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
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Python 3 (was: 2.20 where are we?)

Dev mailing list
In reply to this post by Andrew Bernard
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

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel

0001-lilylib-sys.stderr.write-expects-strings.patch (1K) Download Attachment
0002-Read-linking-files-in-binary-mode.patch (1K) Download Attachment
0003-Fix-musicxml2ly-with-Python-3.patch (33K) Download Attachment
0004-abc2ly-Fix-division-for-Python-3.patch (1K) Download Attachment
0005-Fix-the-last-issues-with-lilypond-book-and-Python-3.patch (2K) Download Attachment
signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Python 3

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.

> 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
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
dak
Reply | Threaded
Open this post in threaded view
|

Re: 2.20 where are we?

dak
In reply to this post by Andrew Bernard
Andrew Bernard <[hidden email]> 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
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
dak
Reply | Threaded
Open this post in threaded view
|

Re: Python 3

dak
In reply to this post by Dev mailing list
Jonas Hahnfeld via lilypond-devel <[hidden email]> 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
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Python 3

Dev mailing list
In reply to this post by Werner LEMBERG
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

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Python 3

Dev mailing list
In reply to this post by dak
Am Samstag, den 21.09.2019, 11:25 +0200 schrieb David Kastrup:

> Jonas Hahnfeld via lilypond-devel <
> [hidden email]
> > 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

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel

signature.asc (499 bytes) Download Attachment
dak
Reply | Threaded
Open this post in threaded view
|

Re: Python 3

dak
Jonas Hahnfeld <[hidden email]> 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
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Python 3

Werner LEMBERG

> 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
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Python 3

Werner LEMBERG
In reply to this post by Dev mailing list

>> `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
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Python 3

Dev mailing list
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

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel

signature.asc (499 bytes) Download Attachment
dak
Reply | Threaded
Open this post in threaded view
|

Re: Python 3

dak
Jonas Hahnfeld via lilypond-devel <[hidden email]> 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
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Python 3

Werner LEMBERG
In reply to this post by Dev mailing list

>> 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
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Python 3

Dev mailing list
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

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel

0001-musicxml-Replace-new.classobj-by-type-for-Python-3.patch (1K) Download Attachment
0002-musicxml2ly-Fix-calls-to-functions-from-string.patch (15K) Download Attachment
0003-musicxml2ly-Fix-handling-of-encoded-data.patch (11K) Download Attachment
0004-musicxml2ly-Fix-integer-calculations-for-Python-3.patch (9K) Download Attachment
signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Python 3

Werner LEMBERG

> [...] 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
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Python 3

James Lowe-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
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Python 3 (was: 2.20 where are we?)

Matthew Peveler
In reply to this post by Dev mailing list
On Sat, Sep 21, 2019 at 5:52 AM Jonas Hahnfeld via lilypond-devel <
[hidden email]> wrote:
> 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.

In applying your patches and running "make check", I encountered a couple
of errors in scripts/build/output-distance.py, which would be summed up as:
1. Python 2 old style classes had a default __cmp__ which would compare the
id() of the classes, and used implicitly for sort. Python 3 removed this,
but need to define a __lt__ method for sort compat.
2. attempting to open midi files as str files, though they are filled with
binary data (and python/midi.py seems to expect binary in interacting with
the contents).

Please see the attached for small patches for these two things, and got
"make check" to run for me using Python 3.7.4 as well.

Regards,
Matt

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel

0001-add-__lt__-method-for-py2-old-style-class-sort-compa.patch (1K) Download Attachment
0002-read-midi-files-as-binary.patch (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Python 3 (was: 2.20 where are we?)

Matthew Peveler
On Mon, Sep 23, 2019 at 12:26 PM Matthew Peveler <[hidden email]>
wrote:
> Please see the attached for small patches for these two things, and got
"make check" to run for me using Python 3.7.4 as well.
Hm, not sure why the patch files got converted to binary when sending,
though I've also made them available at
https://gist.github.com/MasterOdin/8141656b872682a3a540f7af4a1c0d9f for
good measure.

Matt

>

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel

0001-add-__lt__-method-for-py2-old-style-class-sort-compa.patch (1K) Download Attachment
0002-read-midi-files-as-binary.patch (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Python 3 (was: 2.20 where are we?)

Dev mailing list
In reply to this post by Matthew Peveler
Am Montag, den 23.09.2019, 12:26 -0300 schrieb Matthew Peveler:

> On Sat, Sep 21, 2019 at 5:52 AM Jonas Hahnfeld via lilypond-devel <[hidden email]> wrote:
> > 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.
>
> In applying your patches and running "make check", I encountered a couple of errors in scripts/build/output-distance.py, which would be summed up as:
>
> 1. Python 2 old style classes had a default __cmp__ which would compare the id() of the classes, and used implicitly for sort. Python 3 removed this, but need to define a __lt__ method for sort compat.
> 2. attempting to open midi files as str files, though they are filled with binary data (and python/midi.py seems to expect binary in interacting with the contents).
>
> Please see the attached for small patches for these two things, and got "make check" to run for me using Python 3.7.4 as well.
>
> Regards,
> Matt
Ha, I already wondered why there are two targets check and test that
both ran into the same issues (when I started). Turns out, the target
"check" runs "test" but not the other way around, and I only verified
that "test" works in the end...

The patches make sense to me and also work on my system. You should
probably remove the print() statement in the second patch, though.

Thanks,
Jonas

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel

signature.asc (499 bytes) Download Attachment
12