where to put useful lists in the docs?
Hi everyone,
I got stuck trying to determine which grobs get attached to
musical paper-columns, and which grobs get attached to non-musical
paper-columns, so I wrote these list-generating scheme procedures:
(define grobs-sorted-by-paper-column
(let loop ((remaining all-grob-descriptions)
(musical '())
(non-musical '()))
(cond ((null? remaining) (cons musical non-musical))
((ly:assoc-get 'non-musical (cdar remaining))
(loop (cdr remaining)
musical
(append non-musical `(,(caar remaining)
(else (loop (cdr remaining)
(append musical `(,(caar remaining)))
non-musical)
(define-public musical-column-grobs
(car grobs-sorted-by-paper-column))
(define-public non-musical-column-grobs
(cdr grobs-sorted-by-paper-column))
which can be displayed from a lilypond file like so (duh):
{
#(display musical-column-grobs)
#(display non-musical-column-grobs)
}
My question is this: Is there a place in the source code for
things like this? Certainly future developers could save time if
lists like these are easier to retrieve. Initially I had the crazy
idea of a) putting these procedures in define-grobs.scm and b)
mentioning in the paper-column-interface docstring how the lists
can be displayed --- which would've entailed putting scheme code
in a docstring:
" For lists of musical and non-musical objects"
" compile @code{#(display musical-column-grobs)} or"
" @code{#(display non-musical-column-grobs)}."
Is there a better way? I'm thinking of a recent patch which was
well-received IIRC:
http://lists.gnu.org/archive/html/lilypond-devel/2009-04/msg0.html
Any thoughts?
- Mark
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: git not fetching from origin...
On Sun, May 24, 2009 at 10:33:51PM -0600, Carl D. Sorensen wrote: > > On 5/24/09 8:40 PM, "Mark Polesky" wrote: > > > > > I think the instructions in the CG just aren't clear enough. Is > > anyone out there happily making git patches on Windows? Let me > > know! > > I believe that Patrick McCarty is happily making git patches on > Windows, and perhaps Andrew Hawryluk, as well. I don't want to give the impression that I'm making git patches on Windows, because I'm not. If I was, my explanations might be a little more informed, because there might be some peculiarities with using Git on Windows. I'm just hoping that the general Git commands work the same on Windows as they do on GNU/Linux. -Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: git not fetching from origin...
On Sun, May 24, 2009 at 11:07:06PM -0600, Carl D. Sorensen wrote: > > On 5/24/09 10:57 PM, "Patrick McCarty" wrote: > > > On Sun, May 24, 2009 at 07:40:08PM -0700, Mark Polesky wrote: > > > > The "already up to date" means that all of your remote tracking > > branches reflect the current state of the branches at git.sv.gnu.org, > > and that your local branch has been updated accordingly. > > Another way of saying this is that "There are no changes on the > remote repository that are not reflected in your local repository." > Note that it doesn't mean there aren't changes in your local > repository, as compared with the remote. True. I usually don't have to worry about this though, because I always do my work on a separate local branch in order to keep the master branch free of clutter. -Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: git not fetching from origin...
On 5/24/09 10:57 PM, "Patrick McCarty" wrote: > On Sun, May 24, 2009 at 07:40:08PM -0700, Mark Polesky wrote: > > The "already up to date" means that all of your remote tracking > branches reflect the current state of the branches at git.sv.gnu.org, > and that your local branch has been updated accordingly. Another way of saying this is that "There are no changes on the remote repository that are not reflected in your local repository." Note that it doesn't mean there aren't changes in your local repository, as compared with the remote. You can check for differences between your local repository and the remote repository with git diff origin/master which will compare the current branch with origin/master and show you the patch it would take to convert origin/master into your current branch. HTH, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: git not fetching from origin...
On Sun, May 24, 2009 at 07:40:08PM -0700, Mark Polesky wrote:
>
> I guess I'm confused about the difference between origin and
> master. And the difference between pulling and fetching (and
> cloning, though that's not mentioned in the CG).
"git clone" is a command that you use to *copy* the remote LilyPond
repository from git.sv.gnu.org to your computer. So, you only need to
do this one time. The "git remote" method described in the CG can be
useful, but if you are just working on the LilyPond source code, "git
clone" should work just fine.
"git fetch" updates your remote tracking branches to the latest state
of the repo at git.sv.gnu.org.
"git pull" does a "git fetch" first, and then merges the latest
changes from the remote repo with the commits (if any) you have made
on your local branch.
> If I accidentally make changes to master, and I try to pull from
> origin, it says it's already up to date. I assumed origin was
> supposed to be at git.sv.gnu.org, so does that mean I accidentally
> made my local master the origin? Is there even such a thing as a
> local master?
I *think* origin is the name of the top-level remote tracking branch.
So, every remote tracking branch will have a name beginning with
origin: origin/master, origin/web, origin/dev/kainhofer, etc.
The "already up to date" means that all of your remote tracking
branches reflect the current state of the branches at git.sv.gnu.org,
and that your local branch has been updated accordingly.
Depending on the way you set up your git repo ("git clone" versus "git
remote ..."), you may not have a local master branch. You can check
by running "git branch" and seeing if master is in the list.
This is what my output looks like:
$ git branch
master
* pmccarty
> And how do I exit the EDIT_COMMITMSG window? I've included an
> image showing the window. If I click on the X button, the whole
> git bash shell closes along with it. That can't be right. And when
> did my lily-local get ahead of origin/master by 47 commits?
You are inside of Vim. To exit Vim without saving changes, type
:q!
Sorry if you already knew this, but just overlooked the fact that you
were using Vim.
Looking at the "git commit" man page, I see that you can change the
editor by modifying the GIT_EDITOR environmental variable. You might
consider doing this if you don't want to use Vim.
HTH,
Patrick
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: git not fetching from origin...
On 5/24/09 10:46 PM, "Mark Polesky" wrote: > > >> And how do I exit the EDIT_COMMITMSG window? I've included an >> image showing the window. If I click on the X button, the whole >> git bash shell closes along with it. That can't be right. > > Okay, this one I figured out. It says here > http://www.kernel.org/pub/software/scm/git/docs/git-commit.html#_environment_a > nd_configuration_variables > > The editor used to edit the commit log message will be chosen from > the GIT_EDITOR environment variable, the core.editor configuration > variable, the VISUAL environment variable, or the EDITOR > environment variable (in that order). > > So I right-clicked on the Desktop "My Computer" icon --> > Properties --> Advanced --> Environment Variables --> User > variables --> New --> > > Variable Name: GIT_EDITOR > Variable Value: > > So now, > > $ git commit -a > > opens my preferred editor. > > One down. Maybe there's hope! Absolutely! You're on the downhill side now! This should be added to the CG. Who's got responsibility for the git part of the CG? Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: git not fetching from origin...
> And how do I exit the EDIT_COMMITMSG window? I've included an > image showing the window. If I click on the X button, the whole > git bash shell closes along with it. That can't be right. Okay, this one I figured out. It says here http://www.kernel.org/pub/software/scm/git/docs/git-commit.html#_environment_and_configuration_variables The editor used to edit the commit log message will be chosen from the GIT_EDITOR environment variable, the core.editor configuration variable, the VISUAL environment variable, or the EDITOR environment variable (in that order). So I right-clicked on the Desktop "My Computer" icon --> Properties --> Advanced --> Environment Variables --> User variables --> New --> Variable Name: GIT_EDITOR Variable Value: So now, $ git commit -a opens my preferred editor. One down. Maybe there's hope! - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: git not fetching from origin...
On 5/24/09 8:40 PM, "Mark Polesky" wrote: > > > Oh man, this is just way too frustrating. It's OK, you're close. > > Maybe it's a Windows thing, but nothing about git is clear to me > anymore. I feel like I'm trying to learn from three different > manuals, none of which quite work. Then I try out a couple of git > commands in the bash shell and next thing I know, everything's > corrupted... But if it is corrupted, it's really easy to get it back. I remember that it was hard getting up to speed, but now it seems OK, at least for my common tasks. > > I guess I'm confused about the difference between origin and > master. And the difference between pulling and fetching (and > cloning, though that's not mentioned in the CG). You've got it. Origin is git.sv.gnu.org. It is a git repository that has lots of branches, and tags, and versions. origin/master is the current HEAD, or most recent commit on origin. You can also have a master in your local repository. cloning sets up a local copy of the remote repository, which is traditionally called origin (you could call it something else if you wanted to, but by calling it origin, all the examples seem to work right). One confusing thing is that there is no firm name attached to git.sv.gnu.org. When you create a git repository, you also create a remote which is a local data entry that points to git.sv.gnu.org. So although you think of it as being on savannah, the pointer is actually on your machine. Fetch gets copies of the files from a remote (usually origin). Pull gets copies of the files from a remote and merges them with a local branch. Pull is the equivalent of fetch followed by merge. I never fetch, only pull. > > If I accidentally make changes to master, and I try to pull from > origin, it says it's already up to date. I assumed origin was > supposed to be at git.sv.gnu.org, so does that mean I accidentally > made my local master the origin? Is there even such a thing as a > local master? If you make changes to master, and don't commit them, then pull, it will be already up to date because the changes were never committed. The proper way to undo the changes that you've made but never committed, is to do git checkout master which gets clean copies of the files on the master branch from the repository and puts them in your working directory. Once you have changes to your files that you like, you do git commit -a which copies the changed files to the repository, along with a commit message. Now my terminology here may not be "git approved", but it's how I understand things. You can never make changes to origin/master, because you don't have push access. Even if you did have push access, you'd have to execute a git push command in order to make those changes. I promise you, you can't ruin origin, no matter what you do. Yes there is (or can be) a local master. If you run the gitk program, it will show you the local master. > > And how do I exit the EDIT_COMMITMSG window? I've included an > image showing the window. If I click on the X button, the whole > git bash shell closes along with it. That can't be right. And when > did my lily-local get ahead of origin/master by 47 commits? Most likely the EDIT_COMMITMSG window is a vi or vim equivalent editor. I'd suggest that you try the following. 1) move your cursor to a blank line (I generally do it at the top). 2) type i to enter input mode. 3) Type in a one-sentence commit message 4) Hit the escape key 5) Type :wq, which will write the changes and quit the editor. That will complete your commit. I have no idea how lily-local got ahead of origin master by 47 commits. If I were you, I'd save the files you've changed in some other directory, delete your local git repository, and start over. > > I think the instructions in the CG just aren't clear enough. Is > anyone out there happily making git patches on Windows? Let me > know! I believe that Patrick McCarty is happily making git patches on Windows, and perhaps Andrew Hawryluk, as well. I'm sorry about the difficulty of getting up to speed on this. It's one of those things that is really hard to get (I remember struggling with it), and then once it clicks in, you wonder why it was so hard. If the CG instructions don't work (and obviously they haven't for you), you'd be helping others if you could point out the problems you had in following the CG instructions show we can improve them. Thanks for being willing to take this on. I know it's frustrating. You want to do some real work, and instead of doing real work you're mucking around getting lost in some arcane program that doesn't seem to work right, and you can't even ask a question because you don't know what to ask. But once you get it figured out, it will be better, I promise. HTH, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [frogs] patch for issue 708
On Sun, May 24, 2009 at 7:14 AM, Carl D. Sorensen wrote: > > > > On 5/24/09 4:49 AM, "Neil Puttock" wrote: > >> 2009/5/24 Carl D. Sorensen : >>> Thanks, Applied. >> >> Unfortunately, there are two serious flaws here: >> >> - keySignature alists which aren't backquoted (e.g., the example in >> the bug tracker) will be ignored >> >> - entries of the form (notename . alteration) are mangled: >> >> \set Staff.keySignature = #'((0 . 2) (1 . 2) (4 . 2)) >> >> -> \set Staff.keySignature = #`(((0 . 2) . ,SEMI-SHARP) >> ((2 . 4) . ,SHARP)) >> >> Less seriously, the two conversion functions appear to be identical >> apart from the different dictionaries for alterations. Would it be >> possible to use a single `fixKS' function with the dictionaries passed >> as an argument to cut down on the duplication? > > > Thanks for catching this, Neil. > > Andrew, I've reverted the patch. Could you rewrite it to fix these issues? Yes, I'll take a look at it. Thanks, Neil for catching those! Won't be this week, but I'll keep you posted. Andrew ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: git not fetching from origin...
forgot the png... <>___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: git not fetching from origin...
Oh man, this is just way too frustrating. Maybe it's a Windows thing, but nothing about git is clear to me anymore. I feel like I'm trying to learn from three different manuals, none of which quite work. Then I try out a couple of git commands in the bash shell and next thing I know, everything's corrupted... I guess I'm confused about the difference between origin and master. And the difference between pulling and fetching (and cloning, though that's not mentioned in the CG). If I accidentally make changes to master, and I try to pull from origin, it says it's already up to date. I assumed origin was supposed to be at git.sv.gnu.org, so does that mean I accidentally made my local master the origin? Is there even such a thing as a local master? And how do I exit the EDIT_COMMITMSG window? I've included an image showing the window. If I click on the X button, the whole git bash shell closes along with it. That can't be right. And when did my lily-local get ahead of origin/master by 47 commits? I think the instructions in the CG just aren't clear enough. Is anyone out there happily making git patches on Windows? Let me know! Thanks, - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: DOCS: revising LM "Score and Parts"
>> I've made some progress. When I try to run "make score" on Windows >> XP, As it stands, the Makefile doesn't work with Windows. For documentation purposes I strongly suggest to cook up a special Windows Makefile with the same functionality. >>%.pdf %.midi: %.ly >> $(LILY_CMD) $<; \ >> if test -f "$*.pdf"; then \ >>mv "$*.pdf" PDF/; \ >> fi; \ >> if test -f "$*.midi"; then \ >>mv "$*.midi" MIDI/; \ >> fi >> >> Now, the full score compiles if I change the score target to this: >> >>score: >> $(LILY_CMD) Scores/$(piece).ly >> >> So it looks like the Windows environment doesn't know how to deal >> with the pattern rule defined at the top of the Makefile. If nothing compiles then the Makefile doesn't find the *.ly files in the `Score' subdirectory. This means that the VPATH settings don't work. Do you use the `CURDIR' variable in the VPATH path elements? BTW, you can see the exact make rules with make -r -R -p Makefile Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: DOCS: revising LM "Score and Parts"
>> I don't know what >> $(LILY_CMD) $<; \ >> means, This calls lilypond -- or rather the contents of the variable LILY_CMD -- with the prerequisite (the *.ly file) as the argument. >> but the two if statements seem to check if there are any pdf or >> midi files around and then move them to their directories. >> >> On Windows this can be achieved as follows: >> if exist *.pdf move "*.pdf" PDF/ >> if exist *.midi move "*.pdf" MIDI/ > > If it has to be on one line: > if exist *.pdf move "*.pdf" PDF/ & if exist *.midi move "*.pdf" MIDI/ It is not necessary to put everything on a single line, but if you do so you avoid (at least under GNU/Linux) additional calls to the command shell, making the execution faster. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: DOCS: revising LM "Score and Parts"
Am 25.05.2009, 00:21 Uhr, schrieb Henning Plumeyer : I don't know what $(LILY_CMD) $<; \ means, but the two if statements seem to check if there are any pdf or midi files around and then move them to their directories. On Windows this can be achieved as follows: if exist *.pdf move "*.pdf" PDF/ if exist *.midi move "*.pdf" MIDI/ If it has to be on one line: if exist *.pdf move "*.pdf" PDF/ & if exist *.midi move "*.pdf" MIDI/ Henning ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: DOCS: revising LM "Score and Parts"
Am 23.05.2009, 04:41 Uhr, schrieb Jonathan Kulp : I've made some progress. When I try to run "make score" on Windows XP, I get the following message: make: *** No rule to make target `stamitz.ly', needed by `stamitz.pdf'. Stop. I get no such message when I run it on Linux. Right now the target "score" is defined like this: # The dependencies of the full score. $(piece).pdf: $(piece).ly $(notes) .PHONY: score score: $(piece).pdf At the top of the makefile is the pattern rule: # The pattern rule to create PDF and MIDI files from a LY input file. # The .pdf output files are created in the `PDF' subdirectory, and the # .midi files are put into the `MIDI' subdirectory. %.pdf %.midi: %.ly $(LILY_CMD) $<; \ if test -f "$*.pdf"; then \ mv "$*.pdf" PDF/; \ fi; \ if test -f "$*.midi"; then \ mv "$*.midi" MIDI/; \ fi Now, the full score compiles if I change the score target to this: score: $(LILY_CMD) Scores/$(piece).ly So it looks like the Windows environment doesn't know how to deal with the pattern rule defined at the top of the Makefile. Maybe I can help a bit, allthough I don't know make, but I am familiar with windows and it's command line. I've just read a little bit of the helpfile of make. As far as I understand in the block below the line %.pdf %.midi: %.ly are commands to execute. So they have to be translated to the Windows batch language. I don't know what $(LILY_CMD) $<; \ means, but the two if statements seem to check if there are any pdf or midi files around and then move them to their directories. On Windows this can be achieved as follows: if exist *.pdf move "*.pdf" PDF/ if exist *.midi move "*.pdf" MIDI/ BTW, Windows can handle paths with / as well as with \. Henning ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: centering of instrument names
2009/5/24 Joe Neeman :
> On Sun, 2009-05-24 at 02:32 +, Kieren MacMillan wrote:
>> Hi Neil (et al),
>>
>> I'm definitely talkin' out the back of my head here, but... =\
>>
>> Can the instrument name blob take advantage of a "vertical skyline"
>> ("profile"?) the way the rest of the notation (notes, etc.) take advantage
>> of a "horizontal skyline"? That would certainly solve the problem precisely,
>> without having to manually adjust #'padding or whatever.
>
> We can (and do) use sideways pointing skylines (although they're called
> "horizontal skylines" in the source). I think the problem here is that
> the InstrumentNames currently are capable of positioning themselves (ie.
> they don't have to know about the other InstrumentNames), and it
> requires some structural changes in order to let them position
> themselves as a group, which I think would be necessary in order to get
> the result I've suggested.
>
Once properly centered, we could apply the negative padding workaround
in the meantime, in case of necessity.
Or, in a second pass, could each instrument name calculate by itself
the distance to the leftmost brace, then apply an offset to all being
the lowest distance found minus the padding, if greater than zero? In
our example, the "Timpani in D,A" would be the closest one, that it
still can be shrinked.
Feel free to say this is a stupidity.
--
Francisco Vila. Badajoz (Spain)
www.paconet.org
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: centering of instrument names
Hi Joe, We can (and do) use sideways pointing skylines (although they're called "horizontal skylines" in the source). I think the problem here is that the InstrumentNames currently are capable of positioning themselves (ie. they don't have to know about the other InstrumentNames), and it requires some structural changes in order to let them position themselves as a group, which I think would be necessary in order to get the result I've suggested. OK -- thanks for the clarification. Kieren. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: DOCS: revising LM "Score and Parts"
Valentin Villenave wrote: 2009/5/22 Jonathan Kulp : Initial efforts are fruitless. I installed GNUMake on the XP partition, but when I type the command "make" in the dos shell, it says there's no such program. I tried "Make" and "make.exe" as well with the same results. I have no idea what to try next because there's hardly anything about running it on Windows in the documentation. I'll check more on it later. I find it exhausting even to spend a few minutes using Windows... Have you installed Mingw/MSys? This is the preferred way to have not only make but all essential commands available; this way you can use proper bash instead of cmd. http://www.mingw.org/wiki/msys Regards, Valentin I haven't tried that. Maybe I'll try it tonight. Thanks for the recommendation. Jon -- Jonathan Kulp http://www.jonathankulp.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
RE: centering of instrument names
On Sun, 2009-05-24 at 02:32 +, Kieren MacMillan wrote:
> Hi Neil (et al),
>
> I'm definitely talkin' out the back of my head here, but... =\
>
> Can the instrument name blob take advantage of a "vertical skyline"
> ("profile"?) the way the rest of the notation (notes, etc.) take advantage of
> a "horizontal skyline"? That would certainly solve the problem precisely,
> without having to manually adjust #'padding or whatever.
We can (and do) use sideways pointing skylines (although they're called
"horizontal skylines" in the source). I think the problem here is that
the InstrumentNames currently are capable of positioning themselves (ie.
they don't have to know about the other InstrumentNames), and it
requires some structural changes in order to let them position
themselves as a group, which I think would be necessary in order to get
the result I've suggested.
Joe
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: page breaking changed in 2.13 ???
On Sun, 2009-05-24 at 11:53 -0700, ArnoWaschk wrote: > > > Werner LEMBERG wrote: > > > > > >> i am using a 2.13 lilypond compiled from today's git repo, and i am > >> observing - in comparison to a version from around 10th of April - > >> that the page breaking strategy seems to have changed significantly. > >> Which leads me in one case of a before 47page piano reduction score > >> (1 to 4 staves per page, staff lines number irregular) becoming a > >> 123page score only having one line per page, even if just being a > >> piano solo line... > > > > This looks like a bug. Can you reduce it so that Joe can check it? > > > > Thank you for your reply! > > No, i do not have a clue how to reduce a huge score, which seems to fail > > because of a certain hugeness... > > I only see that shorter scores get less extreme results... > > And anyway i am far too short of time for experiments. Which is why i am > > *most urgently* seeking for a way back! > > Going to 2.12 would be quite a step back in quality... I would suggest avoiding the current git code (and probably the current development branch altogether) if you really need things to work urgently. You can try git checkout b0ab8d44ad4c8232f672da9775bd8a564771e1c4 since this particular commit occurred before I started messing with page-breaking stuff. I would appreciate it, however, if you could produce a small example when you have time, as that would help me fix the bug. > > > >> P. S. I would also be grateful for instructions to roll back my > >> source tree to the April version, if that is the easiest... > > > > Just use `gitk' to select a certain revision (or tag) `foo'. Then > > say, on the command line, > > > > git checkout foo > > > > Yes, but how to translate 10th of April 2009 into foo? I cannot see a tag > > in that period...? If there is no tag, you can replace "foo" by the SHA1 ID of a commit. Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: DOCS: revising LM "Score and Parts"
2009/5/22 Jonathan Kulp : > Initial efforts are fruitless. I installed GNUMake on the XP partition, but > when I type the command "make" in the dos shell, it says there's no such > program. I tried "Make" and "make.exe" as well with the same results. I > have no idea what to try next because there's hardly anything about running > it on Windows in the documentation. I'll check more on it later. I find it > exhausting even to spend a few minutes using Windows... Have you installed Mingw/MSys? This is the preferred way to have not only make but all essential commands available; this way you can use proper bash instead of cmd. http://www.mingw.org/wiki/msys Regards, Valentin ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: page breaking changed in 2.13 ???
Arno Waschk wrote: > > > > Werner LEMBERG wrote: >> >> >>> i am using a 2.13 lilypond compiled from today's git repo, and i am >>> observing - in comparison to a version from around 10th of April - >>> that the page breaking strategy seems to have changed significantly. >>> Which leads me in one case of a before 47page piano reduction score >>> (1 to 4 staves per page, staff lines number irregular) becoming a >>> 123page score only having one line per page, even if just being a >>> piano solo line... >> This looks like a bug. Can you reduce it so that Joe can check it? >> >> Thank you for your reply! >> No, i do not have a clue how to reduce a huge score, which seems to fail >> because of a certain hugeness... >> I only see that shorter scores get less extreme results... >> And anyway i am far too short of time for experiments. Which is why i am >> *most urgently* seeking for a way back! >> Going to 2.12 would be quite a step back in quality... >> >>> P. S. I would also be grateful for instructions to roll back my >>> source tree to the April version, if that is the easiest... >> Just use `gitk' to select a certain revision (or tag) `foo'. Then say, on the command line, >> git checkout foo >> >> Yes, but how to translate 10th of April 2009 into foo? I cannot see a tag >> in that period...? >> >> and compile this. Later, you might revert to the top of git with >> git checkout master >> >> Werner >> >> thanks again, Arno >> >> >> ___ >> lilypond-devel mailing list >> lilypond-devel@gnu.org >> http://lists.gnu.org/mailman/listinfo/lilypond-devel >> >> > > -- View this message in context: http://www.nabble.com/page-breaking-changed-in-2.13-tp23696365p23696908.html Sent from the Gnu - Lilypond - Dev mailing list archive at Nabble.com. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: page breaking changed in 2.13 ???
Werner LEMBERG wrote: > > >> i am using a 2.13 lilypond compiled from today's git repo, and i am >> observing - in comparison to a version from around 10th of April - >> that the page breaking strategy seems to have changed significantly. >> Which leads me in one case of a before 47page piano reduction score >> (1 to 4 staves per page, staff lines number irregular) becoming a >> 123page score only having one line per page, even if just being a >> piano solo line... > > This looks like a bug. Can you reduce it so that Joe can check it? > > Thank you for your reply! > No, i do not have a clue how to reduce a huge score, which seems to fail > because of a certain hugeness... > I only see that shorter scores get less extreme results... > And anyway i am far too short of time for experiments. Which is why i am > *most urgently* seeking for a way back! > Going to 2.12 would be quite a step back in quality... > >> P. S. I would also be grateful for instructions to roll back my >> source tree to the April version, if that is the easiest... > > Just use `gitk' to select a certain revision (or tag) `foo'. Then > say, on the command line, > > git checkout foo > > Yes, but how to translate 10th of April 2009 into foo? I cannot see a tag > in that period...? > > > and compile this. Later, you might revert to the top of git with > > git checkout master > > > Werner > > thanks again, Arno > > > ___ > lilypond-devel mailing list > lilypond-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/lilypond-devel > > -- View this message in context: http://www.nabble.com/page-breaking-changed-in-2.13-tp23696365p23696831.html Sent from the Gnu - Lilypond - Dev mailing list archive at Nabble.com. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: page breaking changed in 2.13 ???
> i am using a 2.13 lilypond compiled from today's git repo, and i am > observing - in comparison to a version from around 10th of April - > that the page breaking strategy seems to have changed significantly. > Which leads me in one case of a before 47page piano reduction score > (1 to 4 staves per page, staff lines number irregular) becoming a > 123page score only having one line per page, even if just being a > piano solo line... This looks like a bug. Can you reduce it so that Joe can check it? > P. S. I would also be grateful for instructions to roll back my > source tree to the April version, if that is the easiest... Just use `gitk' to select a certain revision (or tag) `foo'. Then say, on the command line, git checkout foo and compile this. Later, you might revert to the top of git with git checkout master Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
page breaking changed in 2.13 ???
Dear list, i am using a 2.13 lilypond compiled from today's git repo, and i am observing - in comparison to a version from around 10th of April - that the page breaking strategy seems to have changed significantly. Which leads me in one case of a before 47page piano reduction score (1 to 4 staves per page, staff lines number irregular) becoming a 123page score only having one line per page, even if just being a piano solo line... How can i switch back to the old behaviour, or to a behaviour similar to the earlier one? Thank you very much for any help! Arno P. S. I would also be grateful for instructions to roll back my source tree to the April version, if that is the easiest... -- View this message in context: http://www.nabble.com/page-breaking-changed-in-2.13-tp23696365p23696365.html Sent from the Gnu - Lilypond - Dev mailing list archive at Nabble.com. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: centering of instrument names
2009/5/24 Kieren MacMillan :
> Can the instrument name blob take advantage of a "vertical skyline"
> ("profile"?) the way the rest of the notation (notes, etc.) take advantage of
> a "horizontal skyline"? That would certainly solve the problem precisely,
> without having to manually adjust #'padding or whatever.
Yes, I think that's how a professional engraver would do it.
--
Francisco Vila. Badajoz (Spain)
www.paconet.org
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [frogs] patch for issue 708
On Sun, May 24, 2009 at 07:14:28AM -0600, Carl D. Sorensen wrote: > > Graham, I added a comment to the bugtracker, and tried to change the status, > but I couldn't find a way to do it? Do I have access to change status? You have the same access as Valentin, and he can do this stuff. To change the status, you need "add a comment" (even if you don't want to leave a comment), then select the Status drop-down box. > On a more general note, do you have any suggestions for how to check > convert-ly rules? For code, we have regression tests. For convert-ly, as > far as I know, we have nothing. Should we be establishing convert-ly > regression tests? I hope think that we won't have so many convert-ly rules that this become necessary. Certainly at the moment I think it would take more work than it would be worth. If we ever get a dedicated convert-ly person (another unfilled job for years *sigh*), then this could be a good idea. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [frogs] patch for issue 708
On 5/24/09 4:49 AM, "Neil Puttock" wrote: > 2009/5/24 Carl D. Sorensen : >> Thanks, Applied. > > Unfortunately, there are two serious flaws here: > > - keySignature alists which aren't backquoted (e.g., the example in > the bug tracker) will be ignored > > - entries of the form (notename . alteration) are mangled: > > \set Staff.keySignature = #'((0 . 2) (1 . 2) (4 . 2)) > > -> \set Staff.keySignature = #`(((0 . 2) . ,SEMI-SHARP) > ((2 . 4) . ,SHARP)) > > Less seriously, the two conversion functions appear to be identical > apart from the different dictionaries for alterations. Would it be > possible to use a single `fixKS' function with the dictionaries passed > as an argument to cut down on the duplication? Thanks for catching this, Neil. Andrew, I've reverted the patch. Could you rewrite it to fix these issues? Graham, I added a comment to the bugtracker, and tried to change the status, but I couldn't find a way to do it? Do I have access to change status? Neil, On a more general note, do you have any suggestions for how to check convert-ly rules? For code, we have regression tests. For convert-ly, as far as I know, we have nothing. Should we be establishing convert-ly regression tests? Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [frogs] patch for issue 708
2009/5/24 Carl D. Sorensen : > Thanks, Applied. Unfortunately, there are two serious flaws here: - keySignature alists which aren't backquoted (e.g., the example in the bug tracker) will be ignored - entries of the form (notename . alteration) are mangled: \set Staff.keySignature = #'((0 . 2) (1 . 2) (4 . 2)) -> \set Staff.keySignature = #`(((0 . 2) . ,SEMI-SHARP) ((2 . 4) . ,SHARP)) Less seriously, the two conversion functions appear to be identical apart from the different dictionaries for alterations. Would it be possible to use a single `fixKS' function with the dictionaries passed as an argument to cut down on the duplication? Regards, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
