Re: odd configure error
Op donderdag 26-03-2009 om 21:06 uur [tijdzone +0800], schreef Graham Percival: > > GIT from git.sv.gnu.org > > git clone git://git.sv.gnu.org/lilypond.git > > This does not set up easy pulling or pushing in the future, and > generally assumes that people know how to use git > > To get the main source code and documentation, > > mkdir lilypond; cd lilypond > > git init-db > > git remote add -f -t master -m master origin > > git://git.sv.gnu.org/lilypond.git/ > > git checkout -b master origin/master > > After approximately four hours of discussion between git experts > and non-experts, we decided that this is the best sequence of > commands for most contributors. Well, this is utterly ridiculous IMNSHO. I would suggest to * fix the main lilypond repo so that git clone "just works", or * ask on g...@vger.kernel.org what else we're doing wrong, or * fix git so that git clone "just works" If all of these fail, and git clone is *supposed* to be utterly unusable, I suggest to look seriously into switching to bazaar or hg. Jan. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: odd configure error
On 3/27/09 7:24 AM, "Jan Nieuwenhuizen" wrote: > Op donderdag 26-03-2009 om 21:06 uur [tijdzone +0800], schreef Graham > Percival: > >>> GIT from git.sv.gnu.org >>> git clone git://git.sv.gnu.org/lilypond.git >> >> This does not set up easy pulling or pushing in the future, and >> generally assumes that people know how to use git > >>> To get the main source code and documentation, >>> mkdir lilypond; cd lilypond >>> git init-db >>> git remote add -f -t master -m master origin >>> git://git.sv.gnu.org/lilypond.git/ >>> git checkout -b master origin/master >> >> After approximately four hours of discussion between git experts >> and non-experts, we decided that this is the best sequence of >> commands for most contributors. > > Well, this is utterly ridiculous IMNSHO. I would suggest to > > * fix the main lilypond repo so that git clone "just works", or > * ask on g...@vger.kernel.org what else we're doing wrong, or > * fix git so that git clone "just works" > > If all of these fail, and git clone is *supposed* to be utterly > unusable, I suggest to look seriously into switching to bazaar or hg. Please, let's not change the version control system again. Git works well once you get on it. We're talking about a one-time difference of three commands vs. one command. If it "just worked", we'd have one command: git clone git://git.sv.gnu.org/lilypond.git If it doesn't, we have a *one-time* use of three commands: git init-db git remote add -f -t master -m master origin git://git.sv.gnu.org/lilypond.git/ (note -- the git remote command is word-wrapped onto two lines). git checkout -b master origin/master Once this is done, it's good to go. I'm not opposed to making it *just work*. I am opposed to switching from git just because of this minor inconvenience. Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: odd configure error
On Fri, Mar 27, 2009 at 07:56:53AM -0600, Carl D. Sorensen wrote: > > On 3/27/09 7:24 AM, "Jan Nieuwenhuizen" wrote: > > > Well, this is utterly ridiculous IMNSHO. I would suggest to > > > > * fix the main lilypond repo so that git clone "just works", or > > * ask on g...@vger.kernel.org what else we're doing wrong, or > > * fix git so that git clone "just works" > > > > If all of these fail, and git clone is *supposed* to be utterly > > unusable, I suggest to look seriously into switching to bazaar or hg. > > I'm not opposed to making it *just work*. I am opposed to switching from > git just because of this minor inconvenience. Agreed. Now, I'm totally in favor of people complaining to vger.kernel.org. But I think this has to be done by a knowledgeable git person... and even once we convince them that there *is* a problem, and it's *not* caused by our setup (assuming this is true), then it'll still take two years for the fixed version of git clone to be available in people's repositories. No, we do not want to ask contributors to download git from an unstable branch. That's far worse than a 5-line cut&paste job. Now, according to Patrick, "git clone" works for the main branch. Unfortunately I can't see myself testing this in the near future (my apartment has a pathetic internet connection, and the university doesn't allow git connections). However, we need brainless cut&paste instructions for the translations and web as well. Another question is whether it makes sense to keep web/ as a branch in the main lilypond git. I mean, if we're storing gub/ in a separate project, why not stick web/ there as well. ... this again would involve a fairly involved bit of organization that I am totally willing to do in June, but not before. I propose that we leave things as they are right now, unless somebody has the energy to take charge of this task. I estimate 10 hours if you know git, and 20 hours if you don't. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: odd configure error
On Thu, Mar 26, 2009 at 02:31:21PM -0700, Patrick McCarty wrote: > Let's say remote master has changed in the meantime, and you want to > create a new patch rebased on current master: > > cd lilypond > git checkout master > git pull > git checkout mybranch > git rebase master > git format-patch master Err... isn't that more complicated than cd lilypond git pull origin ... edit... git format-patch origin ? I'd take a complicated setup followed by one-line updates over a simple setup followed by three-line updates any day. I'm still amazed at git. Simple things should be simple. I can teach people how to use svn in 15 minutes. But to do the equivalent of "svn update, svn add, svn ci" in git takes... well, I don't know how long we've spent discussing it, but it's way more than 15 minutes! Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: odd configure error
Op vrijdag 27-03-2009 om 22:11 uur [tijdzone +0800], schreef Graham Percival: > Now, according to Patrick, "git clone" works for the main branch. That's my experience, at least with git 1.6. > Another question is whether it makes sense to keep web/ as a > branch in the main lilypond git. I mean, if we're storing gub/ in > a separate project, why not stick web/ there as well. I vote to move web to its own repository, ie, have one repository per code base/project. Jan. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Patches for the web site
Thanks, applied! Should be online in an hour or so. Cheers, - Graham On Thu, Mar 26, 2009 at 02:56:46PM -0700, Patrick McCarty wrote: > Hello, > > The first patch fixes a newly added link on the download page, and the > second adds LilyPond 2.13 to the list on the documentation page. > > > Thanks, > Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: odd configure error
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Freitag, 27. März 2009 schrieb Graham Percival: > On Thu, Mar 26, 2009 at 02:31:21PM -0700, Patrick McCarty wrote: > > Let's say remote master has changed in the meantime, and you want to > > create a new patch rebased on current master: > > > > cd lilypond > > git checkout master > > git pull > > git checkout mybranch > > git rebase master > > git format-patch master It's actually easier: cd lilypond git checkout mybranch (unless you are already there) git fetch git rebase origin/master git format-patch origin/master > I'm still amazed at git. Simple things should be simple. I can > teach people how to use svn in 15 minutes. But to do the > equivalent of "svn update, svn add, svn ci" in git takes... well, > I don't know how long we've spent discussing it, but it's way more > than 15 minutes! git pull git add ... git commit git push origin master So, one additional command, but you don't mess with the server in the first three, so there is an additional safety net. Cheers, Reinhold - -- - -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial & Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQFJzPHkTqjEwhXvPN0RAl6XAJ412rPnD0/3qYOUDu/2UXfcHaERVwCfS6R6 Z+tMHr9wf1+umpFpTt38nbE= =+tw9 -END PGP SIGNATURE- ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: odd configure error
Graham Percival wrote Friday, March 27, 2009 2:11 PM On Fri, Mar 27, 2009 at 07:56:53AM -0600, Carl D. Sorensen wrote: On 3/27/09 7:24 AM, "Jan Nieuwenhuizen" wrote: > Well, this is utterly ridiculous IMNSHO. I would suggest to > > * fix the main lilypond repo so that git clone "just works", > or > * ask on g...@vger.kernel.org what else we're doing wrong, or > * fix git so that git clone "just works" > > If all of these fail, and git clone is *supposed* to be utterly > unusable, I suggest to look seriously into switching to bazaar > or hg. I'm not opposed to making it *just work*. I am opposed to switching from git just because of this minor inconvenience. Agreed. +1 Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Tied accidentals in chords still taking up space
Joe Neeman wrote:
> On Thu, 2009-03-26 at 10:26 -0400, Chris Snyder wrote:
>> Joe Neeman wrote:
> It's not necessary to announce every grob (for example, of the three
> copies of every breakable grob, only the middle-of-line copy gets
> announced). The code for creating these non-announced grobs is in
> Item::copy_breakable_items. In particular, you need the
> get_root_system(original_grob)->typeset_grob(cloned_grob) line to give
> your clone a layout_.
That makes sense - when does this announce need to happen? Right now, I
have it checking accidentals during calculate_positioning_done to see if
they have layouts, and announcing them if not. Is this acceptable?
> This is a bit tricky. To do this properly, you might need to add a
> Note_head::get_accidental function that has the logic for finding the
> right accidental (you could create a new property,
> "break-reminder-accidental-grob", for the new copy). Then you'd need to
> change every place that does get_object("accidental-grob") to use the
> new function; there aren't very many such places. It should be safe to
> just pick one copy if you want to put this off until later.
How about making the accidental-grob property point to a callback? I'm
not sure if it's better or not, but I figured I'd consider the
possibilities.
I've gotten to the point where the spacing is being calculated
correctly. However, it's not printing the correct accidentals - after a
line break, there's a space where the accidentals should be, then
accidentals printed over the noteheads. I've confirmed that the
misplaced accidentals are the copies that aren't supposed to be printed,
and the correct accidentals are not being printed.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: odd configure error
On Fri, Mar 27, 2009 at 8:33 AM, Reinhold Kainhofer wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Am Freitag, 27. März 2009 schrieb Graham Percival: >> On Thu, Mar 26, 2009 at 02:31:21PM -0700, Patrick McCarty wrote: >> > Let's say remote master has changed in the meantime, and you want to >> > create a new patch rebased on current master: >> > >> > cd lilypond >> > git checkout master >> > git pull >> > git checkout mybranch >> > git rebase master >> > git format-patch master > > It's actually easier: > > cd lilypond > git checkout mybranch (unless you are already there) > git fetch > git rebase origin/master > git format-patch origin/master That's true. This method does simplify things. I sometimes forget that there are remote branches and that they can be used for various purposes. :-) -Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Tied accidentals in chords still taking up space
On Fri, 2009-03-27 at 15:04 -0400, Chris Snyder wrote:
> Joe Neeman wrote:
> > On Thu, 2009-03-26 at 10:26 -0400, Chris Snyder wrote:
> >> Joe Neeman wrote:
> > It's not necessary to announce every grob (for example, of the three
> > copies of every breakable grob, only the middle-of-line copy gets
> > announced). The code for creating these non-announced grobs is in
> > Item::copy_breakable_items. In particular, you need the
> > get_root_system(original_grob)->typeset_grob(cloned_grob) line to give
> > your clone a layout_.
>
> That makes sense - when does this announce need to happen? Right now, I
> have it checking accidentals during calculate_positioning_done to see if
> they have layouts, and announcing them if not. Is this acceptable?
I think you should do it as soon as you clone() the accidental (in
Accidental_placement::add_accidental perhaps?).
> > This is a bit tricky. To do this properly, you might need to add a
> > Note_head::get_accidental function that has the logic for finding the
> > right accidental (you could create a new property,
> > "break-reminder-accidental-grob", for the new copy). Then you'd need to
> > change every place that does get_object("accidental-grob") to use the
> > new function; there aren't very many such places. It should be safe to
> > just pick one copy if you want to put this off until later.
>
> How about making the accidental-grob property point to a callback? I'm
> not sure if it's better or not, but I figured I'd consider the
> possibilities.
That would be better, yes. You can determine which accidental is the
right one using the same logic as Accidental::print. Note that this
logic is only valid after the line-breaking has taken place, so you
should note that in the documentation in scm/define-grob-properties.scm.
> I've gotten to the point where the spacing is being calculated
> correctly. However, it's not printing the correct accidentals - after a
> line break, there's a space where the accidentals should be, then
> accidentals printed over the noteheads. I've confirmed that the
> misplaced accidentals are the copies that aren't supposed to be printed,
> and the correct accidentals are not being printed.
In Accidental::print, are the correct accidentals committing suicide?
You might need to change the logic there.
I can't think why the accidentals would be printed over the noteheads,
though. You might get a clue if you check the value of
ape->grobs_[j]->relative_coordinate(common[X_AXIS], X_AXIS) after
accidental-placement.cc:397.
Joe
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
