On Sep 30, 2019, at 19:46, Matthew Peveler wrote:
>
> I've been maintaining my work in
> https://github.com/MasterOdin/lilypond/tree/py3_future2
> . . .
> … but I do not know one would approach making it work on both Python 2 and
> Python3.7 (and potentially other Python3 targets) and that I t
On Mon, Sep 30, 2019 at 7:08 PM Dan Eble wrote:
> The thought that gave rise to my question was that I would be more
> comfortable collaborating if these changes were in git rather than a dozen
> patches in multiple messages in the mailing list archive. (I don’t intend
> that to sound mean.)
>
On Sep 30, 2019, at 17:05, Matthew Peveler wrote:
>
> Please see attached for [ten] patches, which given the work done prior by
> Jonas, allows for running the various make targets under both python2&3
> (assuming application of my other two patches for py3)
The thought that gave rise to my qu
> This does assume however that GUB is updated to at least target at
> least Python 2.6 (for __future__.print_function).
GUB already contains python 2.6 support. However, lilypond isn't set
up to use it. This should be rather simple to do, I think. However,
I haven't gub used since months and
On Mon, Sep 30, 2019 at 5:46 PM Joram wrote:
> Am 27.09.19 um 22:34 schrieb Matthew Peveler:
> > long vs int, unicode vs str, StringIO vs io, iter.next vs
> > iter.__next__, reload, xrange vs range.
>
> It is very well feasible to support both version. I hope by shims you
> mean something like¹
>
On Sep 30, 2019, at 14:22, David Kastrup wrote:
>
> But I don't see
> that a clean cut from Python2 to Python3 in a single step is easily
> feasible and testable for all targets at once including all GUB targets.
Yeah, I did this for my own edification, and with the thought that it might
make it
Hi list,
when uploading a first patch set, git-cl asks for a sourceforge issue
number. If a new issue is created, everything is fine but when you
choose an existing issue, there is some 404 error and the Rietveld link
is not added to the sf issue—resulting in a missing Rietveld link on
www.ph
Am 27.09.19 um 22:34 schrieb Matthew Peveler:
> long vs int, unicode vs str, StringIO vs io, iter.next vs
> iter.__next__, reload, xrange vs range.
It is very well feasible to support both version. I hope by shims you
mean something like¹
from __future__ import division, print_function
fr
Hi all,
> https://codereview.appspot.com/568970043/diff/55143/ly/engraver-init.ly#newcode107
> ly/engraver-init.ly:107: ottavationMarkups =
> Should we change the defaults to something more beautiful? I’d vote for
> sub/superscript va/vb or numbers only.
+1
I’m happy to submit a [regular mar
https://codereview.appspot.com/568970043/diff/55143/ly/engraver-init.ly
File ly/engraver-init.ly (right):
https://codereview.appspot.com/568970043/diff/55143/ly/engraver-init.ly#newcode107
ly/engraver-init.ly:107: ottavationMarkups =
Should we change the defaults to something more beauti
On Sep 30, 2019, at 14:22, David Kastrup wrote:
>
> But I don't see
> that a clean cut from Python2 to Python3 in a single step is easily
> feasible and testable for all targets at once including all GUB targets.
OK.
On Sep 27, 2019, at 16:34, Matthew Peveler wrote:
> The primary thing missing
Dan Eble writes:
> On Sep 27, 2019, at 16:34, Matthew Peveler wrote:
>>
>> I'll have another email later on with patches for having this branch run
>> under both python2.7 & 3 as the necessary backport efforts were not really
>> all that extravagant with just a handful of shims around the chang
On Sep 27, 2019, at 16:34, Matthew Peveler wrote:
>
> I'll have another email later on with patches for having this branch run
> under both python2.7 & 3 as the necessary backport efforts were not really
> all that extravagant with just a handful of shims around the changes you
> noted in long vs
13 matches
Mail list logo
