Re: contributing instructions are misleading!
Am 12.12.2013 05:26, schrieb Carl Peterson:
On Wed, Dec 11, 2013 at 10:35 PM, Graham Percival
gra...@percival-music.ca mailto:gra...@percival-music.ca wrote
Fixing this doesn't require a reorganization. It requires
deleting the two incorrect bits, dumping a @ref{Submitting a
patch} or whatever the @node is called. On a similar note,
there's at least 2 checklists before submitting a patch, at
least 1 of which has obsolete info.
It may not require a reorganization, but is there a clearer, more
concise way of presenting the information to where there is one
truth and we can say, if you want to contribute, go to this page for
the process? I think there needs to be a page that just outlines the
basic process and branches based on what people are doing/using.
For instance, trying to synthesize the information in broad strokes
(and I could be missing, misstating, or overgeneralizing something):
1) You need to be running Linux.
1.1: If you aren't using Linux, you can run Linux within your
current operating system with LilyDev by following these instructions
[link]
1.2: If you're already running Linux, great! Here's how to make
sure you have all the packages and tools needed to work on LilyPond [link]
2) You need to connect to the git repository and download the source
files. To understand what git is, go here [link].
2.1: If you are using the command line, go here [link]
2.2: If you are not comfortable using the command line, go here to
download lily-git.tcl [link]
3) Once you have downloaded the files, begin making your edits. Go
here to see some of our development policies and practices [link]
4) As you edit the code, you will need to make one or more local
commits to your code, to record your changes in a way that can be
eventually integrated into the official source.
4.1: If you are using the command line, go here [link]
4.2: If you are using lily-git.tcl, go here [link]
5) When you finish editing, you need to create patch files that
represent the changes you made
5.1: If you are using the command line, go here [link]
5.2: If you are using lily-git.tcl, go here [link]
6) With your patch files ready, go here for directions on how to
upload your changes for review and eventually submit them to the
source code [link]
In my searching, I didn't find a page that really did this. Section
1.2 of the current CG should theoretically do this (based on the
title), but it mostly just talks philosophically about git.
This is exactly the kind of information I'd need now too. (And being in
that situation I can't offer doing anything about it.)
One particular question I have could be answered in this thread.
If I'm not completely wrong the CG insists on installing and using
git-cl for uploading patches.
But if I'm not mistaken hardly anyone currently uses it.
So _if_ there is a way to upload a patch for review using normal command
line git, email and/or upload forms, I'd really prefer not to use
git-cl, which seems to be rather restrictive (by design).
But of course this should be documented (as 5.1 of Carl's list).
Urs
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: contributing instructions are misleading!
Am 12.12.2013 09:42, schrieb Urs Liska: One particular question I have could be answered in this thread. If I'm not completely wrong the CG insists on installing and using git-cl for uploading patches. But if I'm not mistaken hardly anyone currently uses it. So _if_ there is a way to upload a patch for review using normal command line git, email and/or upload forms, I'd really prefer not to use git-cl, which seems to be rather restrictive (by design). But of course this should be documented (as 5.1 of Carl's list). Sorry, I mixed up git-cl and lily-git, the latter being the one that I'd rather not start using. Urs ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: anyone notice speed of 2.17.95 on Windows ?
Werner LEMBERG w...@gnu.org writes: One extra lookup per glyph might be enough to explain the difference. We need to look up the glyph to get a skyline, but maybe could cache its index into the font in the stencil. That does not sound very useful since we still would do the lookup once per stencil rather than once per m and once per f. It _is_ annoying that this job is not done efficiently by the Freetype library. I don't follow. What exactly is annoying? Please explain. Caching of frequently accessed information if that information is expensive to access. Is it possible that the Freetype library on Windows imprudently accesses (and possibly creates on the fly) some Truetype versions or conversions of the fonts for getting the outlines? Nope. FreeType uses exactly the same code on both platforms, Unlikely as it is talking to different font servers and systems. and it never converts fonts on the fly. But its request to the respective font subsystem might still result in stuff getting resolved via the Truetype path. That might also explain URL:http://code.google.com/p/lilypond/issues/detail?id=2657, the still unresolved Issue 2657: font kerning on Windows is broken Certainly not. This is not a FreeType problem, since kerning and the like is handled one level above FreeType. Well, if Freetype talks to different levels above, it might have misunderstandings with the upper level on Windows. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: contributing instructions are misleading!
Urs Liska u...@openlilylib.org writes: Am 12.12.2013 05:26, schrieb Carl Peterson: 1) You need to be running Linux. 1.1: If you aren't using Linux, you can run Linux within your current operating system with LilyDev by following these instructions [link] 1.2: If you're already running Linux, great! Here's how to make sure you have all the packages and tools needed to work on LilyPond [link] It's more like: on a scale of 1 to 5 of being able to work on LilyPond without major hassles, you can use one of the following: current Ubuntu5 Virtual environment LilyDev on Windows, MacOSX, other 4 Most other GNU/Linux distributions4.5 FreeBSD 3.5 Native MacOSX 2 Native Windows0 This is exactly the kind of information I'd need now too. (And being in that situation I can't offer doing anything about it.) One particular question I have could be answered in this thread. If I'm not completely wrong the CG insists on installing and using git-cl for uploading patches. But if I'm not mistaken hardly anyone currently uses it. That's wrong. Every developer I know uses it. The hardly anyone applies to lily-git.tcl, quite a different beast. So _if_ there is a way to upload a patch for review using normal command line git, email and/or upload forms, I'd really prefer not to use git-cl, which seems to be rather restrictive (by design). No, it isn't. lily-git.tcl is. But lily-git.tcl does not do the issue management (at least not that I know of, never having used it), but rather organizes your git repo and caters for pushing eventually. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Enable manual-specific styling of documentation; issue 3714 (issue 36480048)
LGTM, although it is difficult to visualise the effect of the various colours without seeing them. https://codereview.appspot.com/36480048/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Not able to manually update any tracker issue
Can someone else verify for me please? http://code.google.com/p/lilypond/issues/detail?id=3714 Try to give this a patch-new label and see if you can update the ticket. Thanks James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Not able to manually update any tracker issue
James pkx1...@gmail.com writes: Can someone else verify for me please? http://code.google.com/p/lilypond/issues/detail?id=3714 Try to give this a patch-new label and see if you can update the ticket. Get an http error 500. Interesting, never seen that one before. A more common problem would be that you can update the issue itself, but the summary issue list will trail for hours. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: anyone notice speed of 2.17.95 on Windows ?
On Dec 12, 2013, at 10:43 AM, David Kastrup d...@gnu.org wrote: Werner LEMBERG w...@gnu.org writes: One extra lookup per glyph might be enough to explain the difference. We need to look up the glyph to get a skyline, but maybe could cache its index into the font in the stencil. That does not sound very useful since we still would do the lookup once per stencil rather than once per m and once per f. It _is_ annoying that this job is not done efficiently by the Freetype library. I don't follow. What exactly is annoying? Please explain. Caching of frequently accessed information if that information is expensive to access. Is it possible that the Freetype library on Windows imprudently accesses (and possibly creates on the fly) some Truetype versions or conversions of the fonts for getting the outlines? Nope. FreeType uses exactly the same code on both platforms, Unlikely as it is talking to different font servers and systems. and it never converts fonts on the fly. But its request to the respective font subsystem might still result in stuff getting resolved via the Truetype path. That might also explain URL:http://code.google.com/p/lilypond/issues/detail?id=2657, the still unresolved Issue 2657: font kerning on Windows is broken Certainly not. This is not a FreeType problem, since kerning and the like is handled one level above FreeType. Well, if Freetype talks to different levels above, it might have misunderstandings with the upper level on Windows. One possibility is to implement aux files for lilypond runs that do some form of caching. Reading the aux files and storing their data in caches may be less time consuming than the Freetype calls. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: contributing instructions are misleading!
Am 12.12.2013 10:02, schrieb David Kastrup: This is exactly the kind of information I'd need now too. (And being in that situation I can't offer doing anything about it.) One particular question I have could be answered in this thread. If I'm not completely wrong the CG insists on installing and using git-cl for uploading patches. But if I'm not mistaken hardly anyone currently uses it. That's wrong. Every developer I know uses it. The hardly anyone applies to lily-git.tcl, quite a different beast. So_if_ there is a way to upload a patch for review using normal command line git, email and/or upload forms, I'd really prefer not to use git-cl, which seems to be rather restrictive (by design). No, it isn't. lily-git.tcl is. But lily-git.tcl does not do the issue management (at least not that I know of, never having used it), but rather organizes your git repo and caters for pushing eventually. As written in my other reply I'd already noticed my mistake. Urs ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Website improvements, part 1
Am 12.12.2013 04:19, schrieb Graham Percival: On Wed, Dec 11, 2013 at 02:21:28PM +0100, Urs Liska wrote: - I changed Easier editing to Editing. ok. I also like the applicances tab, although I agree with you that the name might be ideal (but I also can't think of a better name right now). Just a bunch of ideas: We're talking about - Applications of LilyPond - Use of LilyPond in different contexts - Abusing LiylPond - integrating LilyPond in other tools - making LilyPond part of something else - using LilyPond as an engine for other tools Does this trigger any ideas for a menu/page title with anybody? - I organized the entry scenario (= introduction.html) according to three questions - Why should I consider LilyPond? IMO examples should remain part of that. Any more opinions on that? My reasoning was: - I think Features-Background-Freedom and then How LilyPond works is a good reading path - Examples is similar to a Screenshots menu item in many websites and can be somewhat taken out of that intitial reading path - I added the link to Examples to the Where now? box on Features. However, now I see that I would revert making Background link directly to the Essay manual because that would take the reader out of the reading path. (and my updated text on Background makes it easier to understand) - Does it really work/what's the real-world use? I'd be fine with calling that box LilyPond in the real world, although I'm not certain if the applicances should be in this category. I mean, some of them make sense (like wikipedia), but others seem like toy examples. That's probably right, but we should hope to get more entries to that page in the future. And even toy examples give an impression of the diversity of things you can do with LilyPond. We've already covered serious use in Productions. I have to say, the Appliances are more questionable after renaming the box as you suggest ;-) If anything, I think that the web frontends should get their own tab. You mean the box from Editing should be raised to its own page, next to Editing? This is reflected in the layout of the boxes on introduction.html while it's irrelevant in which direction the user proceeds from the Why box At the moment, the order seems to go top-left, bottom-left, top-right, bottom-right. It is, although it was on purpose that after the first box you can actually go right _or_ down. The general design of the website is to go top-left, top-right, bottom-left, bottom-right. I'm not certain this is an important distinction, but it's worth considering. OK, I considered it by clicking through the complete website (except the docs of course) and saw that there isn't any single comparable case. Usually when we have two boxes side by side they are followed by a column-center box, so the flow is clear. The only exception is on the Download subpages: - on the Mac and Windows pages we have two short boxes left and one long box right. But they're not clearly defining a reading path but rather an alternative - on the Unix page we also have two boxes left and one box right, but it's clear that it's going top-left, bottom-left, right. So what to do with it? Semantically it would be less ambiguous to use only one column for the Introduction page. But that wouldn't look nice because the items are so short. I could accept changing this order (i.e. exchange the boxes right-top and bottom-left), but I wouldn't consider it necessary - the ambiguity should be suitable for that page. Any more opinions? However, I still think that text input and editing should be the final part of the introduction. Please specify why you think so. The incentive for reviewing of the website structure was (on lilypond-user) that too many people don't realize the basics of the compiled approach when visiting the website. Which causes too many people to get stuck when they're not able to open LilyPond. My goal was to strenghten the conceptual side in the default reading path by leading to these core concepts earlier. As mentioned above I consider Examples, Productions and Appliances more like an optional path. - I think it would be good to add something about version control on the Text input page, but that's something I wouldn't want to do without prior discussion. I disagree. The purpose of text input is to make potential users realize that yes, we use text, but no, it's not too complicated. Version control is a complicated concept for non-programmers which would dilute the previous message. You already mentioned version control on the Features page, which should be sufficient. Accepted. This is why I asked first in that case ;-) - I think the @contactUsAbout macro should be reconsidered. I agree, you made good points here. Please note that *this* is the kind of change that can be done immediately, submitted for review, etc. It doesn't
Fwd: Re: Website improvements, part 1
Am 12.12.2013 11:00, schrieb Urs Liska: Then I should base a patch on current master, upload it and - assuming it will be accepted - mail the patch to someone (?) for pushing it? OK, I've now uploaded my first two patches (one about the content and one addressing in the CG a problem I encountered for the first). I'll see how this works out and decide how to proceed. Urs ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Not able to manually update any tracker issue
On 12/12/13 09:24, David Kastrup wrote: James pkx1...@gmail.com writes: Can someone else verify for me please? http://code.google.com/p/lilypond/issues/detail?id=3714 Try to give this a patch-new label and see if you can update the ticket. Get an http error 500. Interesting, never seen that one before. A more common problem would be that you can update the issue itself, but the summary issue list will trail for hours. Seems to be OK now. I know they had done some 'network maintenance' as the trackers were read-only for an hour or so, perhaps it was just an hangover from that - some routing update not propagated. C'est la Vie! James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Enable manual-specific styling of documentation; issue 3714 (issue 36480048)
On Thu, Dec 12, 2013 at 2:21 AM, lemzw...@googlemail.com wrote:
LGTM, with one small nit.
https://codereview.appspot.com/36480048/diff/1/Documentation/css/lilypond-
manuals.css
File Documentation/css/lilypond-manuals.css (right):
https://codereview.appspot.com/36480048/diff/1/Documentation/css/lilypond-
manuals.css#newcode456
Documentation/css/lilypond-manuals.css:456: body.learning{
background-color: #ccffcc; }
This and the next lines are a duplication from the top of the patch.
Why? Looks like a mistake...
https://codereview.appspot.com/36480048/
It could be. It may need to be deleted, or there may have been something
else I was intending to style. I'll take a look a bit later today.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Website questions: GSoC
The page GSoC 2012 is obviously outdated. What should be done with it? Immediate reaction: Put it on the attic. But: Would it be useful to write a summary of what of it actually happened? If yes: Is there something willing and able to do that? Urs ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Website questions: GSoC
On Dec 12, 2013, at 3:06 PM, Urs Liska u...@openlilylib.org wrote: The page GSoC 2012 is obviously outdated. What should be done with it? Immediate reaction: Put it on the attic. But: Would it be useful to write a summary of what of it actually happened? If yes: Is there something willing and able to do that? Urs Janek participated in that - I was his mentor. I’d recommend you ask him about that, perhaps in a personal mail, as he’s taken a leave of absence. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Enable manual-specific styling of documentation; issue 3714 (issue 36480048)
On Thu, Dec 12, 2013 at 7:49 AM, Carl Peterson carlopeter...@gmail.comwrote:
On Thu, Dec 12, 2013 at 2:21 AM, lemzw...@googlemail.com wrote:
LGTM, with one small nit.
https://codereview.appspot.com/36480048/diff/1/
Documentation/css/lilypond-manuals.css
File Documentation/css/lilypond-manuals.css (right):
https://codereview.appspot.com/36480048/diff/1/
Documentation/css/lilypond-manuals.css#newcode456
Documentation/css/lilypond-manuals.css:456: body.learning{
background-color: #ccffcc; }
This and the next lines are a duplication from the top of the patch.
Why? Looks like a mistake...
https://codereview.appspot.com/36480048/
It could be. It may need to be deleted, or there may have been something
else I was intending to style. I'll take a look a bit later today.
I just remembered. It does need to be deleted. I had pulled down the
earlier chunk of code to get the hex color values and forgot to take it
back out. I'll update the patch later, when I have access to my dev
machine. Thanks for catching.
Carl
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Enable manual-specific styling of documentation; issue 3714 (issue 36480048)
On Thu, Dec 12, 2013 at 4:10 AM, tdanielsmu...@googlemail.com wrote: LGTM, although it is difficult to visualise the effect of the various colours without seeing them. https://codereview.appspot.com/36480048/ I'll see what I can do about getting representative screenshots. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Website questions: GSoC
Am 12.12.2013 14:10, schrieb Mike Solomon: On Dec 12, 2013, at 3:06 PM, Urs Liska u...@openlilylib.org wrote: The page GSoC 2012 is obviously outdated. What should be done with it? Immediate reaction: Put it on the attic. But: Would it be useful to write a summary of what of it actually happened? If yes: Is there something willing and able to do that? Urs Janek participated in that - I was his mentor. I’d recommend you ask him about that, perhaps in a personal mail, as he’s taken a leave of absence. Cheers, MS I know that Janek participated - and couldn't finish his project. So this is all we have: One participant who failed? Then I suggest completely removing the page from the website. It's nothing to be embarrassed about, but also nothing to put on your website IMO. Question: Should the ideas on that page be preserved as ideas for future development? This could be on the tracker or on some other page. Urs ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
CG: Add comment about git-cl editor (issue 41310043)
Reviewers: ,
Message:
Describing the solution for my problem when using git-cl for the first
time
Description:
CG: Add comment about git-cl editor
git-cl fires either the editor specified by the EDITOR environment
variable or vi if EDITOR isn't defined.
Commit mentions this in the CG
Please review this at https://codereview.appspot.com/41310043/
Affected files (+5, -0 lines):
M Documentation/contributor/source-code.itexi
Index: Documentation/contributor/source-code.itexi
diff --git a/Documentation/contributor/source-code.itexi
b/Documentation/contributor/source-code.itexi
index
f44dd31b3fd2534a0fe591ab10014e9184e51e93..6af2b6fbfe897b466ada93ad0912c5b48d1118a9
100644
--- a/Documentation/contributor/source-code.itexi
+++ b/Documentation/contributor/source-code.itexi
@@ -1384,6 +1384,11 @@ can be used.
@end itemize
+First you will see a terminal editor where you can edit the
+message that will accompany your patch. @code{git-cl} will respect
+the @var{EDITOR} environment variable if defined, otherwise it
+will use @code{vi} as the default editor.
+
After prompting for your Google email address and password, the
patch set will be posted to Rietveld, and you will be given a URL
for your patch.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Web: Download: Add introductory text (issue 40510046)
Reviewers: ,
Description:
Web: Download: Add introductory text
This addresses the initial issue discussed on lilypond-user:
too many people don't understand what they download and get
stuck on not being able to open the LilyPond program.
Add a text that explains the compiled approach and makes clear
one should have LilyPond _and_ an editing environment.
The current warning (which apparently wasn't sufficient)
has been removed from this page but is kept on the subpages
in case someone reaches them by a direct link.
Please review this at https://codereview.appspot.com/40510046/
Affected files (+31, -2 lines):
M Documentation/web/download.itexi
Index: Documentation/web/download.itexi
diff --git a/Documentation/web/download.itexi
b/Documentation/web/download.itexi
index
91bd1a334ca98a8b106c7cffdbe0dbcd1d7c0d92..46eebd9f850867872f0e7ef06b3a21d68d3d5cd1
100644
--- a/Documentation/web/download.itexi
+++ b/Documentation/web/download.itexi
@@ -32,12 +32,41 @@ our @ref{Text input}.}
@heading Downloads for LilyPond @versionStable
@end ifset
-@warningTextBased
-
@divEnd
@divClass{link-headings}
+@divClass{column-center-top}
+@subheading Before you proceed ...
+
+... you should be aware of some facts and concepts.
+
+LilyPond is a @strong{command line application} translating files written
in
+LilyPond's music description language into graphical
+scores. It does @strong{not} constitute a working environment. What you
will be
+working with for entering your scores is either a @emph{text editor} of
your
+choice, or a dedicated editing tool for LilyPond files.
+
+If you want you can go to @ref{Text input} and learn more about LilyPond's
+input language concept.
+
+@subsubheading I'm new to LilyPond and don't have a dedicated editor yet
+
+If you don't already have an editing environment for LilyPond you should
+go to @ref{Editing} now. Apart from getting information on the editing
+concept you'll find a list of known editors. For beginners it is
+recommended to download and install either @strong{Frescobaldi} or
+@strong{Denemo}. Both can take care of installing LilyPond for you.
+
+@subsubheading I'm already a LilyPond user and just want a new version
+
+However, if you already have and editing environment and simply want
+to install a new LilyPond version you can proceed below.
+
+
+@divEnd
+
+
@divClass{column-left-top}
@subheading For users
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: CG: Add comment about git-cl editor (issue 41310043)
On 2013/12/12 11:11:45, uliska wrote: Describing the solution for my problem when using git-cl for the first time Actually I'm not sure if @var is the right one here? https://codereview.appspot.com/41310043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Web: Reword contactUsAbout macro (issue 40860046)
Reviewers: ,
Message:
As suggested here
http://lists.gnu.org/archive/html/lilypond-devel/2013-12/msg00183.html
a first small patch for the website
Description:
Web: Reword contactUsAbout macro
Providing information on new reviews/productions etc.
should be possible by simply writing an email to bug-lilypond.
Redirecting to the Bug Report guide is off-putting.
Please review this at https://codereview.appspot.com/40860046/
Affected files (+6, -2 lines):
M Documentation/web.texi
Index: Documentation/web.texi
diff --git a/Documentation/web.texi b/Documentation/web.texi
index
e6b077d328972fbea17a9ccbd033c75f5af90bdd..621488e92f53b98df0714c4fc46b49335a220d71
100644
--- a/Documentation/web.texi
+++ b/Documentation/web.texi
@@ -306,8 +306,12 @@ Distributions will want to install lilypond.info in
postinstall, doing:
@divClass{heading-center}
@divClass{contactBox}
If you are aware of any other \topic\ which could be listed here,
-please let us know by following the instructions on
-@ref{Bug reports}.
+please let us know by writing a message to the bug-lilypond
+mailing list. If you're not subscribed yet you can do so on the list's
+@uref{https://lists.gnu.org/mailman/listinfo/bug-lilypond,info page}
+or post directly through the
+@uref{http://post.gmane.org/post.php?group=gmane.comp.gnu.lilypond.bugs,
+gmane lilypond.bugs web interface}.
@divEnd
@divEnd
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Website improvements, part 1
Urs Liska wrote Am 12.12.2013 04:19, schrieb Graham Percival: On Wed, Dec 11, 2013 at 02:21:28PM +0100, Urs Liska wrote: - I changed Easier editing to Editing. ok. I also like the applicances tab, although I agree with you that the name might be ideal (but I also can't think of a better name right now). Just a bunch of ideas: We're talking about - Applications of LilyPond - Use of LilyPond in different contexts - Abusing LiylPond - integrating LilyPond in other tools - making LilyPond part of something else - using LilyPond as an engine for other tools Does this trigger any ideas for a menu/page title with anybody? What about just Other uses ? That's broad enough to cover anything that one might want to put there in the future. (It's the best thing I've been able to come up with.) -Paul -- View this message in context: http://lilypond.1069038.n5.nabble.com/Website-improvements-part-1-tp155589p155659.html Sent from the Dev mailing list archive at Nabble.com. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: anyone notice speed of 2.17.95 on Windows ?
Caching of frequently accessed information if that information is expensive to access. *That* I have understood :-) Please give more information, in particular, which calls appear to be expensive. Nope. FreeType uses exactly the same code on both platforms, Unlikely as it is talking to different font servers and systems. Being the maintainer of FreeType, I think I can answer this correctly, so please believe me. The only system-specific stuff is debugging code. Maybe you are mixing this up with fontconfig? and it never converts fonts on the fly. But its request to the respective font subsystem might still result in stuff getting resolved via the Truetype path. Well, this is beyond the control of FreeType. Even on Windows, lilypond talks with fontconfig, right? And as far as I know, fontconfig doesn't convert fonts – given that FreeType understands a lot of font formats, this would be really silly. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Website questions: GSoC
Urs Liska wrote Am 12.12.2013 14:10, schrieb Mike Solomon: On Dec 12, 2013, at 3:06 PM, Urs Liska lt; ul@ gt; wrote: The page GSoC 2012 is obviously outdated. What should be done with it? What about just changing it to GSoC (dropping the 2012) and make it a general GSoC page. Assuming we're still interested in attracting future GSoCoders, having this page shows our interest, our past participation, and some examples of what future projects might look like. Janek's GSoC work can legitimately be presented in a positive light: he learned a lot, the task turned out to be more involved than was first thought, but he is still working on finishing it and is still actively contributing to the project in other ways as well etc. -Paul -- View this message in context: http://lilypond.1069038.n5.nabble.com/Website-questions-GSoC-tp155646p155661.html Sent from the Dev mailing list archive at Nabble.com. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Website questions: GSoC
Am 12.12.2013 16:39, schrieb Paul Morris: Urs Liska wrote Am 12.12.2013 14:10, schrieb Mike Solomon: On Dec 12, 2013, at 3:06 PM, Urs Liska lt; ul@ gt; wrote: The page GSoC 2012 is obviously outdated. What should be done with it? What about just changing it to GSoC (dropping the 2012) and make it a general GSoC page. Assuming we're still interested in attracting future GSoCoders, having this page shows our interest, our past participation, and some examples of what future projects might look like. Sounds good. Could be made into sth like: These are some ideas. Maybe you're interested in such a project? What would be the basic requirement to apply for/participate in a future GSoC? Janek's GSoC work can legitimately be presented in a positive light: he learned a lot, the task turned out to be more involved than was first thought, but he is still working on finishing it and is still actively contributing to the project in other ways as well etc. If we turn it into a generic GSoC page that's certainly possible. Urs ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Website questions: GSoC
Urs Liska u...@openlilylib.org writes: Am 12.12.2013 16:39, schrieb Paul Morris: Urs Liska wrote Am 12.12.2013 14:10, schrieb Mike Solomon: On Dec 12, 2013, at 3:06 PM, Urs Liska lt; ul@ gt; wrote: The page GSoC 2012 is obviously outdated. What should be done with it? What about just changing it to GSoC (dropping the 2012) and make it a general GSoC page. Assuming we're still interested in attracting future GSoCoders, having this page shows our interest, our past participation, and some examples of what future projects might look like. Sounds good. Could be made into sth like: These are some ideas. Maybe you're interested in such a project? What would be the basic requirement to apply for/participate in a future GSoC? Janek's GSoC work can legitimately be presented in a positive light: he learned a lot, the task turned out to be more involved than was first thought, but he is still working on finishing it and is still actively contributing to the project in other ways as well etc. If we turn it into a generic GSoC page that's certainly possible. I'd let the topic of the last GSoC rest until there are more tangible followup results. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Website questions: GSoC
Am 12.12.2013 16:51, schrieb David Kastrup: Urs Liska u...@openlilylib.org writes: Am 12.12.2013 16:39, schrieb Paul Morris: Urs Liska wrote Am 12.12.2013 14:10, schrieb Mike Solomon: On Dec 12, 2013, at 3:06 PM, Urs Liska lt; ul@ gt; wrote: The page GSoC 2012 is obviously outdated. What should be done with it? What about just changing it to GSoC (dropping the 2012) and make it a general GSoC page. Assuming we're still interested in attracting future GSoCoders, having this page shows our interest, our past participation, and some examples of what future projects might look like. Sounds good. Could be made into sth like: These are some ideas. Maybe you're interested in such a project? What would be the basic requirement to apply for/participate in a future GSoC? Janek's GSoC work can legitimately be presented in a positive light: he learned a lot, the task turned out to be more involved than was first thought, but he is still working on finishing it and is still actively contributing to the project in other ways as well etc. If we turn it into a generic GSoC page that's certainly possible. I'd let the topic of the last GSoC rest until there are more tangible followup results. What do you exactly mean by that? Leaving the page as it is currently? Or removing the page completely? I can't tell what you suggest. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Website questions: GSoC
Urs Liska u...@openlilylib.org writes: Am 12.12.2013 16:51, schrieb David Kastrup: Urs Liska u...@openlilylib.org writes: Am 12.12.2013 16:39, schrieb Paul Morris: Urs Liska wrote Am 12.12.2013 14:10, schrieb Mike Solomon: On Dec 12, 2013, at 3:06 PM, Urs Liska lt; ul@ gt; wrote: The page GSoC 2012 is obviously outdated. What should be done with it? What about just changing it to GSoC (dropping the 2012) and make it a general GSoC page. Assuming we're still interested in attracting future GSoCoders, having this page shows our interest, our past participation, and some examples of what future projects might look like. Sounds good. Could be made into sth like: These are some ideas. Maybe you're interested in such a project? What would be the basic requirement to apply for/participate in a future GSoC? Janek's GSoC work can legitimately be presented in a positive light: he learned a lot, the task turned out to be more involved than was first thought, but he is still working on finishing it and is still actively contributing to the project in other ways as well etc. If we turn it into a generic GSoC page that's certainly possible. I'd let the topic of the last GSoC rest until there are more tangible followup results. What do you exactly mean by that? Leaving the page as it is currently? Or removing the page completely? I can't tell what you suggest. I suggest to let the topic of the _last_ GSoC rest until there are more tangible results. That concerns the Janek's GSoC work can legitimately be presented in a positive light angle. That does neither mean leaving the page as it is currently, nor removing it completely. It just means that we should not try selling something as a success until we have more to show for it. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Website questions: GSoC
Am 12.12.2013 17:09, schrieb David Kastrup: Urs Liska u...@openlilylib.org writes: Am 12.12.2013 16:51, schrieb David Kastrup: Urs Liska u...@openlilylib.org writes: Am 12.12.2013 16:39, schrieb Paul Morris: Urs Liska wrote Am 12.12.2013 14:10, schrieb Mike Solomon: On Dec 12, 2013, at 3:06 PM, Urs Liska lt; ul@ gt; wrote: The page GSoC 2012 is obviously outdated. What should be done with it? What about just changing it to GSoC (dropping the 2012) and make it a general GSoC page. Assuming we're still interested in attracting future GSoCoders, having this page shows our interest, our past participation, and some examples of what future projects might look like. Sounds good. Could be made into sth like: These are some ideas. Maybe you're interested in such a project? What would be the basic requirement to apply for/participate in a future GSoC? Janek's GSoC work can legitimately be presented in a positive light: he learned a lot, the task turned out to be more involved than was first thought, but he is still working on finishing it and is still actively contributing to the project in other ways as well etc. If we turn it into a generic GSoC page that's certainly possible. I'd let the topic of the last GSoC rest until there are more tangible followup results. What do you exactly mean by that? Leaving the page as it is currently? Or removing the page completely? I can't tell what you suggest. I suggest to let the topic of the _last_ GSoC rest until there are more tangible results. That concerns the Janek's GSoC work can legitimately be presented in a positive light angle. That does neither mean leaving the page as it is currently, nor removing it completely. It just means that we should not try selling something as a success until we have more to show for it. Thanks. That's clear now. So my suggestion is: - Rename GSoC 2012 to GSoC - Add a general introduction, saying sth like maybe we could participate again in the future - keep the topic suggestions (apart from Janek's topic) I think this could be left until someone feels the need to clarify/add/update anything. Urs ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Website questions: GSoC
David Kastrup wrote I suggest to let the topic of the _last_ GSoC rest until there are more tangible results. That concerns the Janek's GSoC work can legitimately be presented in a positive light angle. That does neither mean leaving the page as it is currently, nor removing it completely. It just means that we should not try selling something as a success until we have more to show for it. That makes sense to me. No need to either hide it as a failure or sell it as a success before the results are in. -Paul -- View this message in context: http://lilypond.1069038.n5.nabble.com/Website-questions-GSoC-tp155646p155668.html Sent from the Dev mailing list archive at Nabble.com. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Website questions: GSoC
Urs Liska wrote Thursday, December 12, 2013 1:27 PM Question: Should the ideas on that page be preserved as ideas for future development? This could be on the tracker or on some other page. Most if not all of Janek's work is preserved in the LilyPond git repository under various incomplete branches with 'Janek' in the name. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Web: Download: Add introductory text (issue 40510046)
A couple of nitpicks, otherwise LGTM. https://codereview.appspot.com/40510046/diff/1/Documentation/web/download.itexi File Documentation/web/download.itexi (right): https://codereview.appspot.com/40510046/diff/1/Documentation/web/download.itexi#newcode57 Documentation/web/download.itexi:57: concept you'll find a list of known editors. For beginners it is Beginners are recommended to ... https://codereview.appspot.com/40510046/diff/1/Documentation/web/download.itexi#newcode63 Documentation/web/download.itexi:63: However, if you already have and editing environment and simply want and - an https://codereview.appspot.com/40510046/diff/1/Documentation/web/download.itexi#newcode64 Documentation/web/download.itexi:64: to install a new LilyPond version you can proceed below. proceed as described below. https://codereview.appspot.com/40510046/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Website questions: GSoC
Am 12.12.2013 18:36, schrieb Trevor Daniels: Urs Liska wrote Thursday, December 12, 2013 1:27 PM Question: Should the ideas on that page be preserved as ideas for future development? This could be on the tracker or on some other page. Most if not all of Janek's work is preserved in the LilyPond git repository under various incomplete branches with 'Janek' in the name. Trevor Actually I was talking about the _other_ stuff, Our 2012 ideas list. Now I see that Janek's work isn't on that page at all. Urs ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Website questions: Manual-Web
I've raised this issue already, but I think it needs to be considered in its own thread: What to do with Manuals-Web? When I go there I can download the whole website as a PDF. OK, this makes sense. Getting it as one big HTML page also makes sense. [but where can I get it in info format?) But clicking on Web (split HTML) brings you to a copy of the whole website, just several directories below the original. This is irritating, to say the least. If this page is there for the first two items I mentioned the text in the left box should definitely be clarified. Currently this manual leads the reader to believe that he gets yet one more manual, with some general information. Are there more purposes to that page than providing the PDF and Big HTML versions of the website that I don't see? And there is one more thing I stumbled over (although I don't find an instance of it right now): There are links from within the real manuals that seem to link to the website but actually point to that web manual (i.e. pages below lilypond.org/doc/2.17/web). If there isn't a point I didn't see so far I tend to suggest: - Completely rewrite the Web box on Manuals-Web - Clarify the Read it box and remove the link to Web (split HTML) Does someone have any enlightenment available for me? Urs ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Enable manual-specific styling of documentation; issue 3714 (issue 36480048)
On Thu, Dec 12, 2013 at 1:06 AM, carlopeter...@gmail.com wrote: Message: Patch for initial solution to issue 3714, regarding color-coding of manuals. Please review this at https://codereview.appspot.com/36480048/ I have submitted follow-up patches to Rietveld to address comments regarding the duplicate CSS definitions. I also found where a change to simplify the manual-specific definition caused a problem with the default color choices (when a specific color set has not been defined), and have corrected this. For those who need a visual of these changes, I've uploaded screenshots to the Google Code issue. https://code.google.com/p/lilypond/issues/detail?id=3714. Regards, Carl P. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Enable manual-specific styling of documentation; issue 3714 (issue 36480048)
On 2013/12/12 22:50:05, Carl P. wrote: issue 3714, adjust sidebar colors for legibility and contrast I think that the index sidebar colors are too dark. They dominate the page, in my opinon. In the current design, the sidebar color and the highlight box fill color are the same. Why not keep it that way? Thanks, Carl S. https://codereview.appspot.com/36480048/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Enable manual-specific styling of documentation; issue 3714 (issue 36480048)
On Thu, Dec 12, 2013 at 05:58:33PM -0500, Carl Peterson wrote: For those who need a visual of these changes, I've uploaded screenshots to the Google Code issue. https://code.google.com/p/lilypond/issues/detail?id=3714. Woah, why are you changing the whole background? It looks a bit cartoony. I would suggest only changing the sidebar and possibly header, not anything in the main doc pages. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Web: Download: Add introductory text (issue 40510046)
Overall this is a bit too chatty for my liking. I have tried to give
some constructive suggestions but please make sure that you follow the
doc guidelines and use the appropriate Texinfo commands (as applicable).
It fails make at the moment (I will see why from my patchy and update
the Tracker accordingly)
https://codereview.appspot.com/40510046/diff/20001/Documentation/web/download.itexi
File Documentation/web/download.itexi (right):
https://codereview.appspot.com/40510046/diff/20001/Documentation/web/download.itexi#newcode38
Documentation/web/download.itexi:38:
Is this whole section conforming to the correct line length - 72 (or 66)
chars? At least here in Rietveld it looks sloppy with weird line breaks.
Maybe this is just the way it is displayed here but can we make sure
please.
https://codereview.appspot.com/40510046/diff/20001/Documentation/web/download.itexi#newcode40
Documentation/web/download.itexi:40: @subheading Before you proceed ...
I don't like those elipses and they aren't really needed (or being used
correctly, they are for missing words and anyway there is a texinfo
command for 'dots'.) can we just have 'Before you proceed' and be done?
https://codereview.appspot.com/40510046/diff/20001/Documentation/web/download.itexi#newcode42
Documentation/web/download.itexi:42: ... you should be aware of some
facts and concepts.
Remove this '... you should be aware of ...' line. Subheading is enough.
https://codereview.appspot.com/40510046/diff/20001/Documentation/web/download.itexi#newcode50
Documentation/web/download.itexi:50: If you want you can go to @ref{Text
input} and learn more about LilyPond's
What happens if they 'don't want?' Remove the 'If you want you can go
to'
Just keep it simple. I.e 'See @ref{Text input} to learn more.'
https://codereview.appspot.com/40510046/diff/20001/Documentation/web/download.itexi#newcode53
Documentation/web/download.itexi:53: @subsubheading I'm new to LilyPond
and don't have a dedicated editor yet
I personally don't like these 'first person' question-type headings, but
if we have to have them can we just remove the 'I'm new to LilyPond' and
get to the point.
Something like 'Which dedicated LilyPond Editor' or similar.
https://codereview.appspot.com/40510046/diff/20001/Documentation/web/download.itexi#newcode55
Documentation/web/download.itexi:55: If you don't already have an
editing environment for LilyPond you should
You had already subheaded this section as '[I] ... don't have a
dedicated editor...' so these first words are redundant. Just skip to
the point.
See @ref{Editing} to find a list of LilyPond editors. Frescobaldi or
Denemo are recommended for beginners.
https://codereview.appspot.com/40510046/diff/20001/Documentation/web/download.itexi#newcode57
Documentation/web/download.itexi:57: concept you'll find a list of known
editors. Beginners are
Two spaces after a full point.
https://codereview.appspot.com/40510046/diff/20001/Documentation/web/download.itexi#newcode59
Documentation/web/download.itexi:59: @strong{Denemo}. Both can take care
of installing LilyPond for you.
Two spaces after a full point
https://codereview.appspot.com/40510046/diff/20001/Documentation/web/download.itexi#newcode64
Documentation/web/download.itexi:64: to install a new LilyPond version
you can proceed as described below.
Is this section even needed?
https://codereview.appspot.com/40510046/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Parser: make optional arguments compatible with lookahead (issue 41720043)
As usual, thanks for working on such simplifications and clean-ups! Inspecting the code (without really understanding it), I haven't seen any gross irregularities, and this is probably the only thing I can check... https://codereview.appspot.com/41720043/diff/1/lily/parser.yy File lily/parser.yy (right): https://codereview.appspot.com/41720043/diff/1/lily/parser.yy#newcode1073 lily/parser.yy:1073: if (!unsmob_music ($$)) Looks like a slightly incorrect indentation... https://codereview.appspot.com/41720043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
PATCHES: Countdown – December 16th – 06:00 GMT
Hello, *Countdown – December 16th – 06:00 GMT* * * * * * * * * * * 3712 http://code.google.com/p/lilypond/issues/detail?id=3712q=label%3APatch-countdown%20OR%20label%3APatch-waiting%20OR%20label%3APatch-review%20OR%20label%3APatch-new%20OR%20label%3APatch-pushsort=patchcolspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary%20Modified Enhancement David Kastrup push Patch: Ponding about Turkish Ebook by Server Acim 3707 http://code.google.com/p/lilypond/issues/detail?id=3707q=label%3APatch-countdown%20OR%20label%3APatch-waiting%20OR%20label%3APatch-review%20OR%20label%3APatch-new%20OR%20label%3APatch-pushsort=patchcolspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary%20Modified Enhancement Janek Warchol push Patch: font: rewrite accidental code (sharp and natural) 3674 http://code.google.com/p/lilypond/issues/detail?id=3674q=label%3APatch-countdown%20OR%20label%3APatch-waiting%20OR%20label%3APatch-review%20OR%20label%3APatch-new%20OR%20label%3APatch-pushsort=patchcolspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary%20Modified Build David Kastrup push Multiprocessor builds fail on some platforms 3664 http://code.google.com/p/lilypond/issues/detail?id=3664q=label%3APatch-countdown%20OR%20label%3APatch-waiting%20OR%20label%3APatch-review%20OR%20label%3APatch-new%20OR%20label%3APatch-pushsort=patchcolspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary%20Modified Enhancement Devon Schudy push Patch: Support articulations, slurs and breaths in MIDI. Fixed_2_19_0 3717 http://code.google.com/p/lilypond/issues/detail?id=3717q=label%3APatch-countdown%20OR%20label%3APatch-waiting%20OR%20label%3APatch-review%20OR%20label%3APatch-new%20OR%20label%3APatch-pushsort=patchcolspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary%20Modified Enhancement Werner Lemberg countdown Patch: Include `freetype.hh' where appropriate. 3713 http://code.google.com/p/lilypond/issues/detail?id=3713q=label%3APatch-countdown%20OR%20label%3APatch-waiting%20OR%20label%3APatch-review%20OR%20label%3APatch-new%20OR%20label%3APatch-pushsort=patchcolspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary%20Modified Defect David Kastrup countdown default for baseline-skip not available while calling column-markup-command in the lists for repeatCommands 3686 http://code.google.com/p/lilypond/issues/detail?id=3686q=label%3APatch-countdown%20OR%20label%3APatch-waiting%20OR%20label%3APatch-review%20OR%20label%3APatch-new%20OR%20label%3APatch-pushsort=patchcolspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary%20Modified Documentation James Lowe countdown Add mention of LibreOffice in addition to OpenOffice.org in the Usage Manual 3540 http://code.google.com/p/lilypond/issues/detail?id=3540q=label%3APatch-countdown%20OR%20label%3APatch-waiting%20OR%20label%3APatch-review%20OR%20label%3APatch-new%20OR%20label%3APatch-pushsort=patchcolspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary%20Modified Documentation James Lowe countdown DOC: Add link to video tutorials 3719 http://code.google.com/p/lilypond/issues/detail?id=3719q=label%3APatch-countdown%20OR%20label%3APatch-waiting%20OR%20label%3APatch-review%20OR%20label%3APatch-new%20OR%20label%3APatch-pushsort=patchcolspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary%20Modified Enhancement Urs review Patch: CG: Add comment about git-cl editor 3718 http://code.google.com/p/lilypond/issues/detail?id=3718q=label%3APatch-countdown%20OR%20label%3APatch-waiting%20OR%20label%3APatch-review%20OR%20label%3APatch-new%20OR%20label%3APatch-pushsort=patchcolspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary%20Modified Enhancement Urs review Patch: Web: Reword contactUsAbout macro 3714 http://code.google.com/p/lilypond/issues/detail?id=3714q=label%3APatch-countdown%20OR%20label%3APatch-waiting%20OR%20label%3APatch-review%20OR%20label%3APatch-new%20OR%20label%3APatch-pushsort=patchcolspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary%20Modified Documentation review website: use colors to distinguish each manual and stable vs. development 3705 http://code.google.com/p/lilypond/issues/detail?id=3705q=label%3APatch-countdown%20OR%20label%3APatch-waiting%20OR%20label%3APatch-review%20OR%20label%3APatch-new%20OR%20label%3APatch-pushsort=patchcolspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary%20Modified Enhancement Janek Warchol review Patch: Metafont code cleanup 3723
Re: Parser: make optional arguments compatible with lookahead (issue 41720043)
Reviewers: lemzwerg,
https://codereview.appspot.com/41720043/diff/1/lily/parser.yy
File lily/parser.yy (right):
https://codereview.appspot.com/41720043/diff/1/lily/parser.yy#newcode1073
lily/parser.yy:1073: if (!unsmob_music ($$))
On 2013/12/13 06:13:32, lemzwerg wrote:
Looks like a slightly incorrect indentation...
How so? This file is (see first line) basically indented in the Linux
style. It's true that this tends to place the brace on the same line as
the if. If it is on a separate line, however, it is lined up with the
closing brace.
I certainly can put the brace in the same line, but that's not
correcting indentation, merely compressing the code a bit more.
What's more annoying is that the copypaste passages often use spaces
instead of tabs, while the global indentation style is supposed to use
tabs. This partly stems from a brief period where this file got edited
while project-wide directory file variables told Emacs not to use tabs.
The inconsistency is somewhat annoying, but in the interest of letting
git blame work, gratuitous changes while moving lines around are not
a good idea.
Description:
Parser: make optional arguments compatible with lookahead
Basically reimplementing the MYBACKUP and MYREPARSE macros based on an
experimentally verified understanding of the LALR(1) parser produced
by Bison, this makes it possible to greatly simplify the grammar while
making optional funciton arguments (and particularly the following
non-optional arguments even when optional arguments are being skipped)
behave much more predictable.
Further simplifications are feasible: this is a first pitch. Consists
of the following commits in reverse order:
Adapt documentation for optional arguments now that lookahead is
permissible
Parser: properly disambiguate pitches from music in function arguments
In many instances, function arguments were parsed greedily without
looking at the function argument predicates first. This did not allow
using subsequent function arguments of type pitch and duration since
they were combined into one music expression.
Parser: remove command_element and command_event synonyms of tempo_event
Parser: remove pitch_arg and PITCH_ARG
Parser: inline a few common expressions occuring only once now
Remove all closed music expressions
Permit event functions to use a non-closed argument list.
Add location data to extra_tokens_ stack in lexer.
Parser: let MYREPARSE and MYBACKUP back up even in presence of lookahead
This implies that the lookahead token must not yet have made an impact
on the state stack other than causing the reduction of the current
rule, or switching the lookahead token while Bison is mulling it over
will cause trouble.
Since an LALR(1) works on the top of the stack, this can usually be
guaranteed. The Too much lookahead message is not produced. If
these constructs are misused, the parser should typically complain
about the replacement token being unexpected.
The advantage is the ability to vastly simplify syntax rules that up
to now have to avoid lookahead tokens with a lot of drudgework.
Move the extra_token mechanism out of the lexer proper
Calling lex-pop_extra_token explicitly in the parser's yylex function
makes things considerably more robust. It also allows pushing and
popping the EOF condition, necessary for backing up right at the end
of a file, like with ##{ \relative { c d e f } #} where the music
expression is checked against being a pitch, and then is backed up.
Please review this at https://codereview.appspot.com/41720043/
Affected files (+258, -449 lines):
M Documentation/extending/programming-interface.itely
M lily/include/lily-lexer.hh
M lily/lexer.ll
M lily/lily-parser.cc
M lily/parser.yy
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Parser: make optional arguments compatible with lookahead (issue 41720043)
https://codereview.appspot.com/41720043/diff/1/lily/parser.yy File lily/parser.yy (right): https://codereview.appspot.com/41720043/diff/1/lily/parser.yy#newcode1073 lily/parser.yy:1073: if (!unsmob_music ($$)) What's more annoying is that the copypaste passages often use spaces instead of tabs, while the global indentation style is supposed to use tabs. This is what I'm referring to. I find such issues irritating, but maybe this is only me. The inconsistency is somewhat annoying, but in the interest of letting git blame work, gratuitous changes while moving lines around are not a good idea. Yep. There are more such issues in the file, BTW. I'm quite unhappy that we can't fix this easily without obfuscating results of `blame' command... https://codereview.appspot.com/41720043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Parser: make optional arguments compatible with lookahead (issue 41720043)
On 2013/12/13 06:47:29, lemzwerg wrote: https://codereview.appspot.com/41720043/diff/1/lily/parser.yy File lily/parser.yy (right): https://codereview.appspot.com/41720043/diff/1/lily/parser.yy#newcode1073 lily/parser.yy:1073: if (!unsmob_music ($$)) What's more annoying is that the copypaste passages often use spaces instead of tabs, while the global indentation style is supposed to use tabs. This is what I'm referring to. I find such issues irritating, but maybe this is only me. The inconsistency is somewhat annoying, but in the interest of letting git blame work, gratuitous changes while moving lines around are not a good idea. Yep. There are more such issues in the file, BTW. I'm quite unhappy that we can't fix this easily without obfuscating results of `blame' command... One can fix indentation in a separate commit not doing other things. In the particular case of lily/lexer.ll and lily/parser.yy however, there is no automatic indentation available. Indentation Linux with tabs merely means that you have to manually indent start and end of a syntax rule and most lines inside of a rule will match that. Since we have no automatic indentation engine that will work for those files, it seems pointless to do reorganizations manually that will not stay around. There is a comment at the start of those files essentially expressing this rationale. I have not actively invested thought in the tabs/spaces in this patch: the Emacs settings here imply that new code will get tab-spaced, so the space-spacing definitely stems from copypaste passages. Where they are really copypaste rather than cutpaste, git will likely not correlate them anyway, but given the overall state of the file, it seems silly to try making a large effort. https://codereview.appspot.com/41720043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: anyone notice speed of 2.17.95 on Windows ?
On Tue, 10 Dec 2013 22:44:18 -0800, Keith OHara k-ohara5...@oco.net wrote: After a brief look at the code, it looked like for each glyph being laid out there is one extra call of Open_type_font:: or Pango_font::name_to_index(), which is the function called by find_by_name() that caused the extra time with issue 1926. I am happy to say that I was wrong here. Open_type_font:: and Pango_font::name_to_index() each call FT_Get_Name_Index(). Inserting print statements to trace those calls I find that FT_Get_Name_Index is called: 7 times for each character in a Tempo 5 times for each character in a Text Script ... 1 time for each notehead 5 times for each rest If I use boxes instead of glyph outlines for vertical-skylines: 0 times for each character in a Tempo (probably just uses the Unicode index) 0 times for each character in a Text Script ( ) 1 time for each notehead 5 times for each rest So the outlines for each letter are re-built several times (through some path in the code that I have not yet found). Whether the expensive part is the FreeType function call, or joining about 60 boxes per character into the skyline for the word, there is a good chance that we can save both by building skylines once for each word. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
gdb and hanging lilypond
Hey all, On my GCC-built-but-running-on-OSX lilypond, LilyPond has started to hang at the “Finding the ideal number of pages” stage. I have compiled LilyPond with debugging and without optimization, but when I gdb it and kill the process, no meaningful stack trace is given: My wild guess is that there’s some mix and match problem between dynamically linked libraries that have been compiled with clang and the executable, which is compiled with gcc. In the meantime, I’m gonna try to get lilypond compiling with clang again. I may just give up and get another VBox if it is too much of a hassle. In the mean-meantime, I’ve put the cryptic gdb backtrace below. Does anyone know how to try to get it to be more informative? Cheers, MS MacBook-Pro-de-Mike:bidouillage mikesolomon$ sudo gdb lilypond GNU gdb (GDB) 7.6.1 Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as x86_64-apple-darwin13.0.0. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /Users/mikesolomon/devel/lilypond/build/lily/out/lilypond...done. (gdb) run foo.ly Starting program: /Users/mikesolomon/devel/lilypond/build/out/bin/lilypond foo.ly GNU LilyPond 2.19.0 Processing `foo.ly' Parsing... Interpreting music... Preprocessing graphical objects... Finding the ideal number of pages...[New Thread 0x1a0b of process 14992] Program received signal SIGTERM, Terminated. 0x7fff930a90de in ?? () (gdb) backtrace #0 0x7fff930a90de in ?? () #1 0x7fff5fbf98b0 in ?? () #2 0x000100dff36c in ?? () #3 0x00d444c0 in ?? () warning: (Internal error: pc 0x0 in read in psymtab, but not in symtab.) warning: (Internal error: pc 0x0 in read in psymtab, but not in symtab.) #4 0x in ?? () (gdb) ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: anyone notice speed of 2.17.95 on Windows ?
On Dec 13, 2013, at 9:07 AM, Keith OHara k-ohara5...@oco.net wrote: On Tue, 10 Dec 2013 22:44:18 -0800, Keith OHara k-ohara5...@oco.net wrote: After a brief look at the code, it looked like for each glyph being laid out there is one extra call of Open_type_font:: or Pango_font::name_to_index(), which is the function called by find_by_name() that caused the extra time with issue 1926. I am happy to say that I was wrong here. Open_type_font:: and Pango_font::name_to_index() each call FT_Get_Name_Index(). Inserting print statements to trace those calls I find that FT_Get_Name_Index is called: 7 times for each character in a Tempo My LilyPond is not working for some reason (see previous e-mail about debugging). Once I get it up and running, I’ll have a go at this. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
