Some background PNGs are 0-length
> The following PNG files (only) {snip} are empty (i.e., their length is 0
bytes):
> lily-home-32x32.png
> nav1-active.png
> nav1-bg.png
> nav1-hover.png
> nav2-active.png
> nav2-bg.png
> nav2-hover.png
> All are in Documentation/pictures/.
Another set of these picture files, including their actual picture data,
resides in the 'extra administrative stuff' Git repository (lilypond-extra).
IMO the actual content of these files should live in the $LILYPOND_GIT
repository, not in the lilypond-extra ($LILYPOND_WEB_MEDIA_GIT) repository.
Presumably, the reason for the existence of this 'extra administrative
stuff' Git repository is to keep separate (and perhaps more secure) some
various files which exist solely for purposes orthogonal to LilyPond: i.e.,
to meet the needs of (or to correct problems caused by) some particular (and
not general) website hosting software, or for other security purposes.
If, in our 'extra administrative stuff' Git repository, we maintain
pictures, as well as (perhaps) files which exist for reasons other than the
above ones, then IMO we're asking for trouble at some future time, and
needlessly complicating our build process.
The following demonstrates that the 'extra administrative stuff' repository
holds the actual contents of these files:
$ cd ~/lilypond-extra
$ find * -name 'lily-home-32x32.png'
pictures/lily-home-32x32.png
$ git log --full-history pictures/lily-home-32x32.png
commit 67fcbd8bf06e5bc4a404a2df8ac5d1181b3819bc
Merge: 2191d54 a79eaf9
Author: PhilHolmes
Date: Fri Jan 23 15:58:13 2015 +
Merge pull request #17 from PaulMorris/webnav-images
Web: images for navbar revision
commit a79eaf9f548389fd6e3f3cf700e8108e2df11882
Author: Paul Morris
Date: Wed Jan 14 22:08:35 2015 -0500
Web: images for navbar revision
See issue 4258
https://code.google.com/p/lilypond/issues/detail?id=4258
$ ls -Gdg `git diff --name-only 67fcbd8..a79eaf9^`
-rw-r--r-- 1 3058 Aug 6 12:29 pictures/lily-home-32x32.png
-rw-r--r-- 1 147 Aug 6 12:29 pictures/nav1-active.png
-rw-r--r-- 1 160 Aug 6 12:29 pictures/nav1-bg.png
-rw-r--r-- 1 160 Aug 6 12:29 pictures/nav1-hover.png
-rw-r--r-- 1 140 Aug 6 12:29 pictures/nav2-active.png
-rw-r--r-- 1 140 Aug 6 12:29 pictures/nav2-bg.png
-rw-r--r-- 1 140 Aug 6 12:29 pictures/nav2-hover.png
--
View this message in context:
http://lilypond.1069038.n5.nabble.com/Some-background-PNGs-are-0-length-tp180917p181312.html
Sent from the Bugs mailing list archive at Nabble.com.
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Some background PNGs are 0-length
RELEVANT COMMIT The latest commit relevant to the below problem seems to be "Web: Revise navigation bars with CSS gradients": http://git.savannah.gnu.org/cgit/lilypond.git/diff/?id=0a89d9ec5ab4b03a6396c0970aa0a227f8950c31 which regards issue "#4258 Patch: Web: revise navigation bars with CSS gradients": http://sourceforge.net/p/testlilyissues/issues/4258/ https://code.google.com/p/lilypond/issues/detail?id=4258 with code review "Issue 193140043: Web: revise navigation bars with CSS gradients (Closed)": https://codereview.appspot.com/193140043/ MINOR PROBLEM The following PNG files (only), added by the above commit, are empty (i.e., their length is 0 bytes): lily-home-32x32.png nav1-active.png nav1-bg.png nav1-hover.png nav2-active.png nav2-bg.png nav2-hover.png as revealed by: $ ls -Sdlr `find . -type f` | head All are in Documentation/pictures/. Here's the (only) file which references the first PNG: Documentation/css/lilypond-website.css All web browsers seem to use this single PNG, not just IE (Microsoft's Internet Explorer). Only one file references the later PNGs (after the first PNG): Documentation/css/lilypond-website-ie-fixes.css Its comments say: /* IE9 and IE8 lack support for CSS gradients so this file */ /* supplies background images for them instead. */ Seemingly (therefore), any effect of the emptiness of these later PNGs would become noticeable only with IE 9 or below. Perhaps someone intended to replace all these empty PNGs with actual, functional PNGs at some future time. However, as yet, no one has done so. Web developers' usual practice, as I understand it, is to provide actual, image-containing PNGs as a fallback to various CSS syntax which fails in certain web browsers. BTW, here's the (only) file which references these CSS files: Documentation/lilypond-texi2html.init A comment there explains the use of these fixes for IE: # Add a conditionally included CSS file for IE, for either the docs or the website There, the fixes are applied to IE versions less than or equal to 9 for the web manual, but less than or equal to 7 for all other usages. BTW, I wonder why we have this version difference between usages? This post in 2010 reported statistics on IE visits to lilypond.org: http://lilypond.1069038.n5.nabble.com/Issue-1182-in-lilypond-Website-rendering-problem-with-navigation-bar-in-IE-6-tp85968p85974.html Windows XP is limited to IE 8. -- View this message in context: http://lilypond.1069038.n5.nabble.com/Some-background-PNGs-are-0-length-tp180917.html Sent from the Bugs mailing list archive at Nabble.com. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: *.eps and *.svg .gitignore patterns match files in repo
Here's how to generate the complete list of files in the working tree (and thus, files in the current repository branch) which match patterns anywhere in Git's multiple gitignore sources: $ cd $LILYPOND_GIT $ find . -path ./.git -prune -o -print | git check-ignore --stdin --no-index --verbose The command identifies the particular gitignore source lines, as well. At present, in a freshly checked-out repository (without doing any build steps), the output still is relatively voluminous. After we have adjusted .gitignore appropriately, then in order to catch such files in the future, this check would seem desirable as part of the regular release process. For details (of course), see: $ man find $ man git-check-ignore -- View this message in context: http://lilypond.1069038.n5.nabble.com/eps-and-svg-gitignore-patterns-match-files-in-repo-tp179828p180314.html Sent from the Bugs mailing list archive at Nabble.com. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
*.eps and *.svg .gitignore patterns match files in repo
On Aug 25, 2015; 5:05pm James Lowe wrote: On 25/08/15 18:48, markdblackwell wrote: Per https://www.kernel.org/pub/software/scm/git/docs/gitignore.html A gitignore file specifies intentionally untracked files that Git should ignore. Files already tracked by Git are not affected Aug 23, 2015; 6:21am, James Lowe wrote: I had similar problems when trying to add snippets in the doc for midi, i.e. any snippet ending in -midi.ly Mark D. Blackwell wrote: Because of these patterns in the .gitignore's, Git will ignore changes to those files. I misspoke. More accurately: If a file is *already* in the repository, then its name matching a .gitignore pattern won't cause Git to ignore changes to it; Git still will commit its changes easily. Only *new* files which match a .gitignore pattern will be ignored, silently. If these particular new files have names (or extensions, or path fragments, depending on the particular .gitignore pattern) similar to files present in the repository, then this is confusing. Aug 23, 2015; 6:35am David Kastrup wrote: Basically, having files both in the repository and in .gitignore is a recipe for trouble. The patterns should likely be made more discriminatory. In order to make the relevant patterns more accurately discriminatory, we might identify the programs (that we use) which generate noise files (i.e., files we want to exclude from the repository) of these kinds, and in which directories. Does anybody know? Otherwise, we should try removing these particular .gitignore patterns, and see whether our procedures still generate any of these unwanted files—and in which directories. Then (obviously) we can reinstate the patterns, and make them more discriminatory. Here's what Git blame says is the latest commit which changed the relevant lines in /.gitignore: $ git blame .gitignore 915e0d52 (Jan Nieuwenhuizen 2006-12-05 14:54:32 +0100 2) *-midi.ly 915e0d52 (Jan Nieuwenhuizen 2006-12-05 14:54:32 +0100 9) *.eps 915e0d52 (Jan Nieuwenhuizen 2006-12-05 14:54:32 +0100 26) *.svg Well I am not sure exactly what we're looking for but when I removed these entries in my .gitignore and then ran both an out of and in tree make doc, make test-baseline and a make check, I didn't get any files showing up when I then did a 'git status'. Is that good enough? Now, I'm unsure exactly what you mean. Just to clear up one possibility first, I suppose you might be asking whether this is a good enough test to establish that these current lines in .gitignore are no problem. With that I would disagree, for the reason David Kastrup stated. Let me admit that I'm not expert on (all) the various tools used by (all the) people who now, or in future, might work on LilyPond, and who might submit patches for Rietveld review, or who might commit changes to the master branch of LilyPond's repository on Savannah. Therefore, regarding the question whether yours is a good enough *test* of the safety of removing those two lines (*.eps and *.svg), I don't know. Why are those lines in there? Usually people add patterns to .gitignore to cover problematic files which arise in practice. Perhaps indeed those patterns should be removed now, as you did in your test. This would simplify .gitignore. A more conservative approach would be to change them so that they ignore files of those extensions, but only in the top-level directory. That might cover such noise files as actually do arise naturally (maybe; I don't know). So, the lines would be: /*.eps /*.svg Have you seen this similar thread?: http://lilypond.1069038.n5.nabble.com/build-gitignore-pattern-matches-files-in-repo-tt179867.html Based on it, the pattern build/ in .gitignore should be changed perhaps to: /build/ These three (3) changes to lines in .gitignore, if committed to the LilyPond master branch on Savannah, would cover absolutely all the files of the current repository (as of August 21, 2015, anyway), so that no file matches a pattern in .gitignore. I believe this is what David Kastrup desires (see above). -- View this message in context: http://lilypond.1069038.n5.nabble.com/eps-and-svg-gitignore-patterns-match-files-in-repo-tp179828p180196.html Sent from the Bugs mailing list archive at Nabble.com. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
*.eps and *.svg .gitignore patterns match files in repo
Per https://www.kernel.org/pub/software/scm/git/docs/gitignore.html A gitignore file specifies intentionally untracked files that Git should ignore. Files already tracked by Git are not affected Aug 23, 2015; 6:21am, James Lowe wrote: I had similar problems when trying to add snippets in the doc for midi, i.e. any snippet ending in -midi.ly Mark D. Blackwell wrote: Because of these patterns in the .gitignore's, Git will ignore changes to those files. I misspoke. More accurately: If a file is *already* in the repository, then its name matching a .gitignore pattern won't cause Git to ignore changes to it; Git still will commit its changes easily. Only *new* files which match a .gitignore pattern will be ignored, silently. If these particular new files have names (or extensions, or path fragments, depending on the particular .gitignore pattern) similar to files present in the repository, then this is confusing. Aug 23, 2015; 6:35am David Kastrup wrote: Basically, having files both in the repository and in .gitignore is a recipe for trouble. The patterns should likely be made more discriminatory. In order to make the relevant patterns more accurately discriminatory, we might identify the programs (that we use) which generate noise files (i.e., files we want to exclude from the repository) of these kinds, and in which directories. Does anybody know? Otherwise, we should try removing these particular .gitignore patterns, and see whether our procedures still generate any of these unwanted files—and in which directories. Then (obviously) we can reinstate the patterns, and make them more discriminatory. Here's what Git blame says is the latest commit which changed the relevant lines in /.gitignore: $ git blame .gitignore 915e0d52 (Jan Nieuwenhuizen 2006-12-05 14:54:32 +0100 2) *-midi.ly 915e0d52 (Jan Nieuwenhuizen 2006-12-05 14:54:32 +0100 9) *.eps 915e0d52 (Jan Nieuwenhuizen 2006-12-05 14:54:32 +0100 26) *.svg -- View this message in context: http://lilypond.1069038.n5.nabble.com/eps-and-svg-gitignore-patterns-match-files-in-repo-tp179828p180152.html Sent from the Bugs mailing list archive at Nabble.com. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
build/ .gitignore pattern matches files in repo
Currently, the top level .gitignore (of LilyPond's repository) contains this pattern: I found no pattern negating this, in any .gitignore file (at any directory level). Currently, the repository on the server contains files (see below) which match this pattern. Because of this, Git will ignore changes to those files. Therefore: * Should the pattern be changed to /build/ , so it doesn't match the files? * Should the matching files be removed? * Should the .gitignore pattern be deleted? * (If the present, peculiar situation is exactly what is desired, then) should the top level .gitignore include some comment explaining it? The following files match the pattern in the top-level .gitignore: -- View this message in context: http://lilypond.1069038.n5.nabble.com/build-gitignore-pattern-matches-files-in-repo-tp179867.html Sent from the Bugs mailing list archive at Nabble.com. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
*.eps and *.svg .gitignore patterns match files in repo
Any chance to see an uncensored version of this on the
actual mailing list? Not everybody uses Nabble, and you
can see what got actually sent out on the list by looking at
http://lists.gnu.org/archive/html/bug-lilypond/2015-08/msg00065.html
--David Kastrup
Thanks for that. :) Now, I've added the archive to my toolbar for future
checking.
The full text follows (without HTML tags; I had used {raw}).
Currently, the top level .gitignore (of LilyPond's repository) contains
these patterns:
*.eps
*.svg
I found no pattern negating them, in any .gitignore file (at any directory
level).
If any files match patterns in the .gitignore's, then:
* Should those .gitignore patterns be deleted?
* Should those matching files be removed?
* Should the top-level .gitignore include a negating pattern, to cause Git
to version-control the files? Such as (in the present case):
!/Documentation/pictures/**/*.eps
!/Documentation/pictures/**/*.svg
* (If the present, peculiar situation is exactly what is desired then)
should the top level .gitignore include some comment explaining it?
Because of these patterns in the .gitignore's, Git will ignore changes to
those files.
Actually, the following files (in the repository on the server) match these
patterns in the .gitignore's:
$ find * -name '*.eps'
Documentation/pictures/context-example.eps
$ find * -name '*.svg' | sort
Documentation/pictures/bwv861mm33-34-annotate.svg
Documentation/pictures/nestedboxes.svg
Documentation/pictures/page-layout-comparison.svg
Documentation/pictures/text-input-1-annotate-de.svg
Documentation/pictures/text-input-1-annotate-es.svg
Documentation/pictures/text-input-1-annotate-fr.svg
Documentation/pictures/text-input-1-annotate-hu.svg
Documentation/pictures/text-input-1-annotate-it.svg
Documentation/pictures/text-input-1-annotate.svg
Documentation/pictures/text-input-2-annotate-de.svg
Documentation/pictures/text-input-2-annotate-es.svg
Documentation/pictures/text-input-2-annotate-fr.svg
Documentation/pictures/text-input-2-annotate-hu.svg
Documentation/pictures/text-input-2-annotate-it.svg
Documentation/pictures/text-input-2-annotate.svg
Documentation/pictures/text-input-parts-both-annotate-de.svg
Documentation/pictures/text-input-parts-both-annotate-es.svg
Documentation/pictures/text-input-parts-both-annotate-fr.svg
Documentation/pictures/text-input-parts-both-annotate-hu.svg
Documentation/pictures/text-input-parts-both-annotate-it.svg
Documentation/pictures/text-input-parts-both-annotate.svg
Documentation/pictures/text-input-parts-single-annotate-de.svg
Documentation/pictures/text-input-parts-single-annotate-es.svg
Documentation/pictures/text-input-parts-single-annotate-fr.svg
Documentation/pictures/text-input-parts-single-annotate-hu.svg
Documentation/pictures/text-input-parts-single-annotate-it.svg
Documentation/pictures/text-input-parts-single-annotate.svg
Documentation/pictures/text-input-pop-annotate-de.svg
Documentation/pictures/text-input-pop-annotate-es.svg
Documentation/pictures/text-input-pop-annotate-fr.svg
Documentation/pictures/text-input-pop-annotate-hu.svg
Documentation/pictures/text-input-pop-annotate-it.svg
Documentation/pictures/text-input-pop-annotate.svg
Documentation/pictures/text-input-score-annotate-de.svg
Documentation/pictures/text-input-score-annotate-es.svg
Documentation/pictures/text-input-score-annotate-fr.svg
Documentation/pictures/text-input-score-annotate-hu.svg
Documentation/pictures/text-input-score-annotate-it.svg
Documentation/pictures/text-input-score-annotate.svg
$ du -ch `find * -name '*.eps'`
124Ktotal
$ du -ch `find * -name '*.svg'`
412Ktotal
--
View this message in context:
http://lilypond.1069038.n5.nabble.com/eps-and-svg-gitignore-patterns-match-files-in-repo-tp179828p179870.html
Sent from the Bugs mailing list archive at Nabble.com.
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
build/ .gitignore pattern matches files in repo
Any chance to see an uncensored version of this on the actual mailing list?
--David Kastrup
Thanks for that. :) Now, I've added the archive to my toolbar for future
checking.
The full text follows (without HTML tags; I had used {raw}).
Currently, the top level .gitignore (of LilyPond's repository) contains this
pattern:
build/
I found no pattern negating this, in any .gitignore file (at any directory
level).
Currently, the repository on the server contains files (see below) which
match this pattern. Because of this, Git will ignore changes to those files.
Therefore:
* Should the pattern be changed to /build/ , so it doesn't match the files?
* Should the matching files be removed?
* Should the .gitignore pattern be deleted?
* (If the present, peculiar situation is exactly what is desired, then)
should the top level .gitignore include some comment explaining it?
The following files match the pattern in the top-level .gitignore:
$ find scripts/build | sort
scripts/build
scripts/build/GNUmakefile
scripts/build/pl
scripts/build/pl/help2man.pl
scripts/build/pl/mf2pt1.pl
scripts/build/py
scripts/build/py/bib2texi.py
scripts/build/py/catmidi.py
scripts/build/py/create-version-itexi.py
scripts/build/py/create-weblinks-itexi.py
scripts/build/py/extract_texi_filenames.py
scripts/build/py/gen-emmentaler-scripts.py
scripts/build/py/genicon.py
scripts/build/py/grand-replace.py
scripts/build/py/html-to-texi.py
scripts/build/py/install.py
scripts/build/py/lilypond-words.py
scripts/build/py/lys-to-tely.py
scripts/build/py/makesnippets.py
scripts/build/py/make-version.py
scripts/build/py/mass-link.py
scripts/build/py/mf-to-table.py
scripts/build/py/output-distance.py
scripts/build/py/pytt.py
scripts/build/py/relative.py
scripts/build/py/texi2omf.py
scripts/build/py/text2html.py
scripts/build/py/website_post.py
scripts/build/py/www_post.py
scripts/build/py/yyout2grammar.py
scripts/build/sh
scripts/build/sh/install-info-html.sh
scripts/build/sh/run-and-check.sh
scripts/build/txt
scripts/build/txt/website-known-missing-files.txt
$ du -ch `find scripts/build`
284Ktotal
--
View this message in context:
http://lilypond.1069038.n5.nabble.com/build-gitignore-pattern-matches-files-in-repo-tp179867p179871.html
Sent from the Bugs mailing list archive at Nabble.com.
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: *.eps and *.svg .gitignore patterns match files in repo
Actually, the following files match patterns in the .gitignore's Currently, the repository on the server contains those *.eps and *.svg files. (I neglected to state this, clearly.) Because of patterns in the .gitignore's, Git will ignore changes to those files. -- View this message in context: http://lilypond.1069038.n5.nabble.com/eps-and-svg-gitignore-patterns-match-files-in-repo-tp179828p179834.html Sent from the Bugs mailing list archive at Nabble.com. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
*.eps and *.svg .gitignore patterns match files in repo
Currently, the top level .gitignore (of LilyPond's repository) contains these patterns: I found no pattern negating them, in any .gitignore file (at any directory level). If any files match patterns in the .gitignore's, then: * Should those .gitignore patterns be deleted? * Should those matching files be removed? * Should the top-level .gitignore include a negating pattern, to cause Git to version-control the files? Such as (in the present case): * (If the present, peculiar situation is exactly what is desired then) should the top level .gitignore include some comment explaining it? Actually, the following files match patterns in the .gitignore's: -- View this message in context: http://lilypond.1069038.n5.nabble.com/eps-and-svg-gitignore-patterns-match-files-in-repo-tp179828.html Sent from the Bugs mailing list archive at Nabble.com. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
`Help Us' section duplicated
Interesting. With me, it does: The link in leads me to Not for you? You are right; that link does—for me, too! However, I neglected to be specific enough in my very short summary: The *first (front matter) page* of the Contributor's Guide manual (version 2.19.23, in the second paragraph) refers people to a very important section, 'Help Us' located in another manual: the Web/General Information manual. Here's the front matter text I'm talking about: This manual documents contributing to LilyPond version 2.19.23. It discusses technical issues and policies that contributors should follow. This manual is not intended to be read sequentially; new contributors should only read the sections which are relevant to them. For more information about different jobs, see _*Help us*_. The link in the last two words, above—`*Help us*'—goes to: -- View this message in context: http://lilypond.1069038.n5.nabble.com/Help-Us-section-duplicated-tp178962p178998.html Sent from the Bugs mailing list archive at Nabble.com. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: `Help Us' section duplicated
the Contributor's Guide includes a link to `Help us'. Should that link go to section `Help us' of: 1. The Contributor's Guide manual?; or of 2. The Web/General Information manual? Of course, this only links the subsection within the CG, as with all other links of the kind. Actually, it doesn't. Should it? -- View this message in context: http://lilypond.1069038.n5.nabble.com/Help-Us-section-duplicated-tp178962p178995.html Sent from the Bugs mailing list archive at Nabble.com. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
`Help Us' section
The first (front matter) page of the Contributor's Guide manual (version 2.19.23, in the second paragraph) refers people to a very important section, 'Help Us' located in another manual: the Web/General Information manual. In the PDF version: `For more information about different jobs, see Section “Help us” in General Information.' In the HTML version: `For more information about different jobs, see _Help us_.' Its underlying HTML (reformatted for clarity) is: However, currently the Contributor's Guide also incorporates a duplicate copy of this 'Help us' subsection, plainly visible near the top of the index. Its text exactly matches that in the Web/General Information manual, and includes the same, detailed discussions of `Simple tasks' and `Advanced tasks'. The duplication extends all the way from: Help us/We need you! down through: Bugfixes or new features: read Section “Programming work” in Contributor’s Guide. This, combined with referring the reader (as it turns out) to the same content, yet in another manual, might somewhat confuse readers as to why. (It did so, for me.) Also, some readers might be motivated to check whether or not the content indeed is exactly duplicated (since we don't say so). They might possibly consider that it could have fallen obsolete in one or another of the copies (in the usual way). Question: The first page of the Contributor's Guide, for people who are considering helping LilyPond, includes a link to `Help us'. Should that link go to section `Help us' of: 1. The Contributor's Guide manual?; or of 2. The Web/General Information manual? IMO, best is that: 1. The link should continue to target that same section of the Web/General Information manual; and 2. The duplicate text in the Contributor's Guide manual should be replaced by something like: Please see Section “Help us” in General Information. including a link to it (of course). Alternatively, if actually and currently the repeated text is maintained in only one place in the source code, perhaps this particular duplication of text in the manuals can't cause problems. However, in that case, exactly at that point in the Contributor's Guide, IMO we briefly should state something like: This information is an exact, automatic copy of section `Help us' from the Web/General Information manual. None of the other manuals duplicates the `Help us` section text, BTW. -- View this message in context: http://lilypond.1069038.n5.nabble.com/Help-Us-section-tp178960.html Sent from the Bugs mailing list archive at Nabble.com. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
`Help Us' section duplicated
The first (front matter) page of the Contributor's Guide manual (version 2.19.23, in the second paragraph) refers people to a very important section, 'Help Us' located in another manual: the Web/General Information manual. In the PDF version: `For more information about different jobs, see Section “Help us” in General Information.' In the HTML version: `For more information about different jobs, see _Help us_.' Its underlying HTML (reformatted for clarity) is: However, currently the Contributor's Guide also incorporates a duplicate copy of this 'Help us' subsection, plainly visible near the top of the index. Its text exactly matches that in the Web/General Information manual, and includes the same, detailed discussions of `Simple tasks' and `Advanced tasks'. The duplication extends all the way from: Help us/We need you! down through: Bugfixes or new features: read Section “Programming work” in Contributor’s Guide. This, combined with referring the reader (as it turns out) to the same content, yet in another manual, might somewhat confuse readers as to why. (It did so, for me.) Also, some readers might be motivated to check whether or not the content indeed is exactly duplicated (since we don't say so). They might possibly consider that it could have fallen obsolete in one or another of the copies (in the usual way). Question: The first page of the Contributor's Guide, for people who are considering helping LilyPond, includes a link to `Help us'. Should that link go to section `Help us' of: 1. The Contributor's Guide manual?; or of 2. The Web/General Information manual? IMO, best is that: 1. The link should continue to target that same section of the Web/General Information manual; and 2. The duplicate text in the Contributor's Guide manual should be replaced by something like: Please see Section “Help us” in General Information. including a link to it (of course). Alternatively, if actually and currently the repeated text is maintained in only one place in the source code, perhaps this particular duplication of text in the manuals can't cause problems. However, in that case, exactly at that point in the Contributor's Guide, IMO we briefly should state something like: This information is an exact, automatic copy of section `Help us' from the Web/General Information manual. None of the other manuals duplicates the `Help us` section text, BTW. -- View this message in context: http://lilypond.1069038.n5.nabble.com/Help-Us-section-duplicated-tp178962.html Sent from the Bugs mailing list archive at Nabble.com. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
barNumberCheck broken in LilyPond 2.19.22
If a user passes a wrong bar number to \barNumberCheck, LilyPond 2.19.22
produces a Scheme error:
lilypond tiny-example.ly
GNU LilyPond 2.19.22
Processing `tiny-example.ly'
Parsing...
Interpreting
music...C:/progra/lilypond/current/usr/share/lilypond/current/ly/music-functions-init.ly:220:24:
In procedure ly:input-warning in expression (ly:input-warning (*location*)
Barcheck failed got ~a expect ~a ...):
C:/progra/lilypond/current/usr/share/lilypond/current/ly/music-functions-init.ly:220:24:
Wrong type argument in position 1 (expecting Input): #f
Tiny-example.ly contains the following code:
\version 2.19.18 % Please ignore this version number!
notes = {
c'2 d'
\barNumberCheck #3
}
\book {
\bookOutputName barNumberCheck-tiny-example-test
\score {
\notes
\layout { }
}
}
I'm using Windows XP.
--
View this message in context:
http://lilypond.1069038.n5.nabble.com/barNumberCheck-broken-in-LilyPond-2-19-22-tp178423.html
Sent from the Bugs mailing list archive at Nabble.com.
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
