On 26/09/13 15:04, David Kastrup wrote:
How many substantial patches would you expect yourself to be
contributing in the wake of such a move per month to LilyPond?
Don't know. Most of my potential contributions to Lilypond are likely to be
documentation -- among other things I'd like to revis
On 26/09/13 15:23, David Kastrup wrote:
Well, you think that it's better to demoralize existing developers
rather than hypothetical would-be contributors nobody knows.
This is going to be a toxic direction of discussion if we pursue it, so I won't
respond, except to say that it is not my inten
On 26/09/13 16:37, Trevor Daniels wrote:
Almost exactly what I was about to reply, but Phil beat me to it! In fact I
think I remember helping you add the Contemporary music headings some
time ago, or was it someone else?
The section originates with me but I got diverted into trying to create a
On 26/09/13 17:16, Phil Holmes wrote:
I think it's waiting for someone to propose how it could be represented in
LilyPond. If _someone_ were to do that, it might progress - it was only a few
months ago it was last looked at.
Unfortunately, it was someone putting forward a workaround which I'd
On 26/09/13 17:35, Joseph Rushton Wakeling wrote:
Unfortunately, it was someone putting forward a workaround which I'd already
proposed and found lacking, as it doesn't play nice with transposition :-(
There was actually a patch submitted which tweaked the internal pitch
repr
On 26/09/13 18:38, David Kastrup wrote:
You commented on the issue where this patch originated as late as July:
http://code.google.com/p/lilypond/issues/detail?id=1278#c7>. So
it's hard to argue that it was not discoverable to you.
This July I got an email update from the issue, and responded.
On 27/09/13 03:44, Graham Percival wrote:
On Thu, Sep 26, 2013 at 03:12:27PM +0200, Joseph Rushton Wakeling wrote:
This risks becoming another corrosive discussion,
Then WTF are you starting it?
Because I had hoped that what I said was sufficiently qualified not to create
bad feeling
Hello all,
I'm trying to build Lilypond from git-HEAD source for the first time in a while
and running into some curiosities from the ./configure script. This is on
Ubuntu 13.10.
First of all: ./configure requests a number of build dependencies that are not
listed on the pages here:
http:/
On 05/10/13 17:24, David Kastrup wrote:
That's not a "workaround" since your fonts would all be broken. Maybe
install TeXlive2013 to a local tree and update to the newest version
using tlmgr?
Currently trying to get it to set up a local texmf tree -- running any tlmgr
command, e.g. tlmgr init
On 05/10/13 19:39, David Kastrup wrote:
Joseph Rushton Wakeling writes:
Unfortunately, nobody seems to be interested in
https://bugs.launchpad.net/ubuntu/+source/texlive-bin/+bug/1220653>
Thanks ever so much for looking into the problem in this depth.
In my experience it can help if m
On 05/10/13 20:08, Joseph Rushton Wakeling wrote:
In my experience it can help if more than one person reports the bug as
affecting them (I've just done so). So, fingers crossed. By the look of it
though, they just copy over from Debian rather than having any dedicated TeXlive
mainta
On 05/10/13 19:01, David Kastrup wrote:
Maybe you can use tlmgr for updating your Metapost.
Well, you saw the error I encountered when trying to use tlmgr to do that.
(Maybe I'm just misunderstanding how it works, I've never used it before.)
No idea. Or complain to Ubuntu that they still h
On 16/10/13 00:11, Janek Warchoł wrote:
I need at least 2 people who'd like to experiment with me - doing this
alone doesn't make sense. Colin, Joe - are you still interested?
Anyone else?
Yup, still in. :-)
___
lilypond-devel mailing list
lilypond
On 19/10/13 10:16, James wrote:
The point is that when I am managing 15 patch reviews I don't (won't) read the
email thread [1] I look at tracker, see what has been said, I click on Rietveld
see what has been said; it's all there in front of me, no extra windows to click
or open, one single appli
On 20/10/13 11:15, James wrote:
Yes, although I don't want to be considered arrogant that it should only be
'acceptable to me'; but when the last Patch-nanny decided he was going 'spend
more time with his family' (so to speak speaking) and wanted to pass on the role
to someone else, the silence f
On 21/10/13 04:00, Carl Sorensen wrote:
I have to say that I much prefer the Lilypond method for handling tasks
and reviews to the Gitlab method.
Can you describe in more detail what it is that you like about how Lilypond does
things, and how that is missing (or inferior) in GitLab?
However
On 21/10/13 06:13, Carl Sorensen wrote:
Even though it can be a pain to rebase commits, when it's done on the
current Lilypond process I feel like the commit messages are much better
than the ones that show up by default on Gitlab (merging branch xyz).
I'll test this out on GitLab just to see w
On 21/10/13 07:41, Werner LEMBERG wrote:
This latter thing bothered me too initially (with GitHub) as I was
used to just pulling from the main repo to my local machine and
submitting patches via email; but I quickly realized that it was
actually sensible, and that those user repos are just plac
On 21/10/13 07:58, Werner LEMBERG wrote:
I don't see a major simplification for the maintainer. The most
important action IMHO for contributing a patch is to rebase, ensuring
that the patch compiles with master. As far as I can see, github's
ticketing system doesn't allow to simply update the p
On 21/10/13 09:09, Werner LEMBERG wrote:
Good to know, thanks. [I assume that `overwrite' still somehow
retains the previously version for reference, right?]
In the short term I think so (you'll see stuff in the comment history like
"so-and-so commented on an outdated diff"). In the long run
A couple of messages accidentally went off-list, forwarding them back here with
Werner's agreement :-)
On 21/10/13 08:02, Werner LEMBERG wrote:
The other advantage is that the merge commit is "authored" by the
person with master commit access who approves the merge request.
So, you have in hi
On 21/10/13 10:01, Trevor Daniels wrote:
The vast majority of my contributions are single-commit, and I
suspect most other contributions are the same. They are easy
to manage and generate a clean history with merge commits
appearing only when they are appropriate. Our git repository was
not alw
On 21/10/13 11:11, David Kastrup wrote:
Now it's rather hard to do a proper balance of the merits: basically we
are not aiming for a "I could discipline myself into using xxx" verdict
but rather for "this will definitely make things quite easier for me in
the long run" for a majority of existing
On 21/10/13 14:25, Carl Sorensen wrote:
And based on Joseph's comments, it appears that I may be misusing GitLab a
little bit -- we've not been using good descriptions of the merge requests
(in fact, we may have not been using *any* descriptions of the merge
requests) so the merge commits only ha
On 21/10/13 14:30, Carl Sorensen wrote:
In our current workflow, once I submit a patch, it's a fixed submission.
I have to resubmit a different patch in order to change it.
In the gitlab workflow, when I submit a merge request, it's a dynamic
thing. Any time I push my merge-request branch to or
On 23/10/13 18:22, David Kastrup wrote:
Of course, this was sort of predictable. Would we have been in time if
we had immediately created a backport of the configure patch and named
the result 2.16.3?
I think it would depend on when you got it out by. As far as I can tell Ubuntu
just imports
On 24/10/13 17:24, David Kastrup wrote:
But they take the source package and compile themselves.
I think it likely that's an automated process.
Debian has already taken a fixed Metapost long ago, but Ubuntu has not
updated the TeXlive binaries in spite of me reporting the problem.
When did
On 23/10/13 18:22, David Kastrup wrote:
This can seriously affect LilyPond's reputation. Anybody putting
together a comparison of various typesetting programs under GNU/Linux
will more likely be using this version than any other.
I don't know about other glyphs, but for what it's worth, the tr
On 25/10/13 11:36, David Kastrup wrote:
More like out-of-stylized. At any rate, incomplete flags actually
impede the readability more than once per line.
Again, if it makes any difference -- remember that this is a release with only
6-month max lifecycle, and that non-LTS (long-term-support)
On 25/10/13 12:09, David Kastrup wrote:
Who knows? If they go with "TeXlive2013" as released for lack of a
compelling reason...
This is the version they have in the current development repositories:
https://launchpad.net/ubuntu/+source/texlive-bin/2013.20130729.30972-2
That's the fixed versio
On 23/10/13 18:22, David Kastrup wrote:
Ubuntu 13.10 is delivered with LilyPond 2.16.2 built using a Metapost
version of 1.802. Consequently, all the included fonts look like crap.
Just FYI -- I've had a response from someone at Canonical who has asked me to
check a couple of things for them.
On 25/10/13 19:31, Colin Campbell wrote:
FWIW, after installing Ubuntu 13.10 and seeing my ../configure choke on the
mpost version, I followede Werner Lemberg's suggestion from here:
http://article.gmane.org/gmane.comp.gnu.lilypond.devel/55828/match=mpost+broken
and all seems to be well. At least
Hello all,
The building of the various manuals takes quite a long time, but the build
process itself is silent so it's not easy to tell if they're actually
progressing or have somehow hung.
e.g. currently I'm just seeing:
LILYPOND_VERSION=2.17.29 /usr/bin/python -tt ../scripts/lilypond-book.
On 25/10/13 13:45, Joseph Rushton Wakeling wrote:
Just FYI -- I've had a response from someone at Canonical who has asked me to
check a couple of things for them. Will update as/when I have more info.
There's now an updated texlive-binaries package in the saucy-proposed
repository,
Hi all,
I'm just checking the updated Lilypond packages in Ubuntu saucy-proposed (the
ones that have the fix for the mpost bug) and I'm finding something odd: I
installed the PDF docs to check the fonts, but I can't find the actual PDF files
anywhere in /usr/share/doc.
Where are they typical
On 02/11/13 11:13, Joseph Rushton Wakeling wrote:
I'm just checking the updated Lilypond packages in Ubuntu saucy-proposed (the
ones that have the fix for the mpost bug) and I'm finding something odd: I
installed the PDF docs to check the fonts, but I can't find the actual PDF fi
On 01/11/13 16:29, Joseph Rushton Wakeling wrote:
There's now an updated texlive-binaries package in the saucy-proposed
repository, which can be used to test Lilypond builds:
https://bugs.launchpad.net/ubuntu/+source/lilypond/+bug/1243777/comments/11
The saucy-proposed repository now als
On 02/11/13 15:12, Mike Solomon wrote:
Not sure what a git formatted patch is…I can, however, download the Rietveld
patch and send it to you if you want.
Git can extract text patch files from your version history, which can then be
sent by email. It's a simpler way of getting patches to/from
On 03/11/13 10:09, Mike Solomon wrote:
Looks like some files in flower don't play nice with the most recent version of
the standard library bundled with Xcode…
Any ideas for how to proceed?
If I understand right (I'm not a Mac user), latest Xcode has clang as default
compiler, and symlinks t
On 03/11/13 10:37, David Kastrup wrote:
We committed a few Clang-related fixes in the past, I think mostly due
to Graham's insistence/testing, but I think at some point of time the
"compile with Clang" ambition just faded.
I just tried a clang-based build on my Ubuntu 13.10 system, just to see
On 03/11/13 11:00, Mike Solomon wrote:
That’s fine, I’ll download gcc.
From what I understand from friends who've experienced the same, you'll have to
manually remove/rewrite some of the symlinks.
Just to check -- before you rework everything -- did you manually re-run the
configure script
On 03/11/13 11:20, Hans Aberg wrote:
FYI, some "Extended Helmholtz-Ellis JI” accidentals [1-2], in fact designed
quite recently, but a nice input. There is also a Unicode font at [3]. Notation also
mentioned at [4].
The arrow accidentals that LilyPond has, are used for syntonic comma 81/81
al
On 03/11/13 11:18, Mike Solomon wrote:
Yeah, the output is fine (clean bill of health, all systems go). I had to
specifically set CPPFLAGS to deal w/ some homebrew issues, but otherwise
nothing out of the ordinary.
Ahh, OK. That's odd; OK, I accept that the clang you have has been a little
On 03/11/13 11:42, Joseph Rushton Wakeling wrote:
For Lilypond in particular, the problem of supporting microtonal notation is
less about symbols per se and more about the underlying representation of pitch,
and how that relates both to accidentals and transposition.
Specifically in relation
On 03/11/13 12:33, Mike Solomon wrote:
[ ... snip ... ]
…these fonts are always a pain, but I usually figure out some way to cheat and
get them in there. But that shouldn’t have anything to do with the compiler.
Well, what's odd is that your ./configure script says that it finds gcc:
chec
On 03/11/13 12:34, Hans Aberg wrote:
I know how to do it from the theoretical point of view, but somebody who knows
the internals of LilyPond must do it.
Of course. I'm just raising it as pertinent to the discussion. :-)
___
lilypond-devel mailing
On 03/11/13 13:36, Mike Solomon wrote:
Doesn’t work, but all the files in flower compile fine with gcc, so I’m a happy
camper.
Apple’s home cooked clang is not free software, so there’s no reason to expect
free software to compile with it. I don’t mind giving up on it.
It's difficult to see
On 03/11/13 17:55, Hans Aberg wrote:
As a preparation, LilyPond might get intervals: it is going to be too
complicated to write out names for all pitch combinations.
A pitch is defined by a written pitch plus a sequence of intervals added to it.
Accidentals are a special case: intervals not ch
On 03/11/13 13:53, David Kastrup wrote:
We've been fingerpointing back and forth for years over this. Without
an actual user/musician like Hans at least teaming up with a programmer,
nothing will happen.
It's not meant to be fingerpointing -- I'm not blaming anyone for development
not moving
On 07/11/13 07:26, Keith OHara wrote:
The arrow notation also gives two options for the half-flat: natural-down-
arrow and flat-up-arrow. If someone uses both options for the half-flat in
the same piece, LilyPond can keep track of the choice by using a tuning
system that has them at slightly dif
Hello all,
It looks like there's a blocking factor in releasing the fixed Lilypond 2.16.2
on Ubuntu 13.10: the PowerPC build of the updated package is failing.
Here's the build log:
https://launchpadlibrarian.net/155579346/buildlog_ubuntu-saucy-powerpc.lilypond_2.16.2-2build0.1_FAILEDTOBUILD.t
On 07/11/13 22:21, Keith OHara wrote:
The use of two alterations, natural-up and sharp-down, for the same pitch
where the note-head is on the same staff-position is problematic to read.
I would hope that composers choose one glyph and use it consistently
within a piece.
Your notational preferen
On 09/11/13 11:10, Janek Warchoł wrote:
Hmm. Good question. Maybe it could be attached to NoteHeads, not NoteColumns?
(As i understand it, the problem with attachments results from the
fact that slurs are attached to notecolumns (the bound of the slur
spanner is the NoteColumn), and at staff-le
On 23/10/13 18:22, David Kastrup wrote:
Ubuntu 13.10 is delivered with LilyPond 2.16.2 built using a Metapost
version of 1.802. Consequently, all the included fonts look like crap.
The fix for this should now be released:
https://bugs.launchpad.net/ubuntu/+source/lilypond/+bug/1243777/comments
On 03/12/13 13:16, David Kastrup wrote:
LilyPond's rendition of the slurs is actually reasonable readable.
However, the measures take probably 40% more width.
That's not necessarily a bad thing. My impression is that older scores are
often more horizontally (and vertically) compact in order t
On 03/12/13 14:25, David Nalesnik wrote:
The problem is that the position of the tuplet number is tied to the placement
of the tuplet bracket, whether it is drawn or not.
I would argue that probably here the _real_ problem is that the tuplet bracket
is designed to always place itself "outside"
On 09/01/14 12:20, David Kastrup wrote:
Another problem is that LilyPond has a usage philosophy and workflow
that strongly penalizes manual tweaks. Graphically/manually oriented
workflows detract from the importance of getting good default
typesetting.
I'm not sure that's necessarily the case.
On 09/01/14 21:05, David Kastrup wrote:
That must be the reason why the typical Word document features the
consistent use of document styles for arriving at typographically
superior results.
I'm not sure that I feel happy about your benchmark for comparison. I think
Lilypond's user base is a
On 13/03/15 12:51, David Kastrup wrote:
GitLab (like GitHub) does not run on free software. They have some
"community" version of their software freely available at least.
Gitorious was "eating its own dog food" with regard to running on their
free software version, but they have just been acqui
On 10/04/15 09:34, Werner LEMBERG wrote:
While I don't like bzr, the launchpad interface for reporting bugs and
the like looks OK to me. So yes, this is a possible solution.
I think this has already been mentioned but just to chip in that it
isn't just about reviewing patches, patches have to
On 10/04/15 09:34, Werner LEMBERG wrote:
So the question is whether Launchpad has a usable API, right? Joseph,
do you know more?c
Just to follow up on this, I exchanged a few messages on Reddit with Colin
Watson (who's leading the git-support effort) following this announcement:
http://blog.
On 03/05/15 16:53, Phil Holmes wrote:
I'd be willing to start a draft "requirements for issue handling" document
tomorrow, if no-one else is desperate.
That'd be great, though it'd be even better if there could be clear requirements
beyond merely those of issue handling -- code hosting, code r
101 - 162 of 162 matches
Mail list logo
