Trevor Daniels wrote Wednesday, January 13, 2010 11:18 AM
John Mandereau wrote Wednesday, January 13, 2010 9:44 AM
Le mercredi 13 janvier 2010 =C3=A0 09:27 +, Trevor Daniels a
=C3=A9crit=
In gitk (in either Unix or Windows) you can only
copy/paste within the fields that you can
Unfortunately, there's a hierarchy problem with the
@subsubheading Technical details
thing that had previously escaped my notice. I'm finding
this really confusing so I'll try to be clear. And I could
be wrong on some detail... Any instance of
@unnumberedsubsubsec foo
that comes
Trevor Daniels wrote:
Thanks Joe
Mark is currently redrafting this section of the CG and it seems
he has picked up and applied your changes in his latest patch.
That's great. Glad it was useful. :-)
Sometime soon I must get back onto the Contemporary Music docs. I'm
sorry for the absence
Joseph Wakeling wrote Thursday, January 14, 2010 12:11 PM
Sometime soon I must get back onto the Contemporary Music docs.
That would be good! Happy to help when you're ready.
Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
Suggestions:
1) stop sticking everything in the same thread; it makes it very hard
to keep track of what's happening.
2) I can't reproduce with some tests on programming-work.itexi based
on your description, so further debugging would be tricky for me.
3) this is a presentation issue, not a
On Wed, Jan 13, 2010 at 9:36 PM, Boris Shingarov b...@shingarov.com wrote:
Oh, and make sure you're using the latest GUB; IIRC there are 2 or
3 different git repositories floating around. You want the one at
github.
git://github.com/janneke/gub.git -- this one, right?
Yes.
I believe
On Wed, Jan 13, 2010 at 03:15:06PM +0100, John Mandereau wrote:
Another thing that we could do instead of creating another list is
writing down as a specification (even written quite informally) the
important changes already started i.e. the i18n of Texinfo, stuff
specific to building the
On Wed, Jan 13, 2010 at 03:27:59PM +0100, John Mandereau wrote:
I second this suggestion, except for the exclamation mark; I'd like
something more explicit, like [BUILD] or [DOCS BUILD] or whatever
depending on the area of the proposal. I suggest also to send such
emails by always starting a
Quoting Graham Percival gra...@percival-music.ca:
Didn't you read the part where I said you had to read the source, and
that there was probably something wrong in the above line?
Line 17 of lilypond.make is:
LILYPOND_REPO_URL=git://git.sv.gnu.org/lilypond.git
That's not hard to find, and I
On Thu, Jan 14, 2010 at 2:49 PM, Boris Shingarov b...@shingarov.com wrote:
That's the very first thing I found, but that's NOT what you were talking
about in the first e-mail. It is LILYPOND_REPO, which is a separate
variable.
And I said I was guessing.
You see, I read both the head revision
By the way, do you have a good reason to build using GUB anyway? If you
just want to build and install LilyPond on your own machine, it's by far
much easier to just build LilyPond directly.
I did actually manage to use GUB some year ago, when I wanted to try
some patches on the Windows
Mark Polesky wrote:
Yep. Thanks Joe!
Brilliant. There's probably plenty more that can be added -- see all
the info on the Wine wiki linked to -- but this seems to be the really
_essential_ stuff. Maybe also a link to where to get dos2unix ... ?
By the way, do you have a good reason to build using GUB anyway?
Because I read on the maillist that it was not possible to do a native
build of lilypond for win32.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
On Thu, Jan 14, 2010 at 3:56 PM, Boris Shingarov b...@shingarov.com wrote:
By the way, do you have a good reason to build using GUB anyway?
Because I read on the maillist that it was not possible to do a native build
of lilypond for win32.
Umm. It would be *way*, ***way*** easier to download
Umm. It would be *way*, ***way*** easier to download lilybuntu and do
a normal compile in there
Then I probably had misunderstood the purpose of Lilybuntu -- I thought
this was for people who did not have a real linux setup for doing
lilypond development -- like, having all the prerequisites
On Thu, Jan 14, 2010 at 4:17 PM, Boris Shingarov b...@shingarov.com wrote:
Umm. It would be *way*, ***way*** easier to download lilybuntu and do
a normal compile in there
Then I probably had misunderstood the purpose of Lilybuntu -- I thought this
was for people who did not have a real linux
Le jeudi 14 janvier 2010 à 08:36 +, Trevor Daniels a écrit :
Unlike copying from the SHA1 ID and Find fields, cntl-c
cannot be used to copy to the clipboard from this pane.
In Windows you have to press enter.
In gitk running under ubuntu even this does not work. The field
to be
A few more thoughts:
- you can build just the mingw installer by doing
bin/gub mingw::lilypond-installer
- you can also give it a different git repo, and presumably a file
location(?), on the command-line, but I can't remember the
syntax.
- the release work chapter of the CG in git
Hi again,
The attached file contains two almost identical scores (just the lenght of
them varies) without any special settings. However, the vertical layout of
both scores with identical settings is radically different:
-) The first, 6-measure score is placed on 6 (!!!) pages, with one measure
LGTM, pushed to master.
Cheers,
Neil
http://codereview.appspot.com/183159
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
I pushed the main draft of my changes to the CG Git chapter.
I mentioned a confusing TOC-pane behavior in an earlier
email:
http://lists.gnu.org/archive/html/lilypond-devel/2010-01/msg00363.html
Once the changes are up, you can witness this in the
split-HTML CG by using the TOC pane to navigate
In the pdf output of my CG patch, I noticed that the hyphens
in @code{--rebase} got separated from the word rebase:
...add the -r option (short for --
rebase) to keep commits on your...
The hyphens can even be separated from each other:
...(see git stash) and do git reset -
-hard
22 matches
Mail list logo
