Re: What's the deal with info documentation images?
On Sat, Aug 29, 2009 at 07:21:33AM +0200, David Kastrup wrote: > Graham Percival writes: > > > ... and by some odd coincidence, we haven't made a stable release > > with it in such a state. Imagine that! > > Does that mean that one is not supposed to report problems until a > stable release has been made? The documentation, particularly the build process, is in heavy flux at the moment. > It would make much more sense to land the user in either the command > line reference (with top-level links to the notation reference) or vice > versa. > > > (or rather, if I was *forced* to pick one, I'd go with the AU, > > since that at least has the command-line arguments) > > It hasn't. Let's walk through this, comments in <<<>>>. The AU -- Application Usage -- lilypond-application -- most definitely *does* contain the command-line arguments. > Notation > > > This book explains all the LilyPond commands which produce notation. > > Note: The Notation assumes that the reader knows basic > material covered in the Learning and is familiar with the > English musical terms presented in the Musical Glossary. > > > And that's it. The links don't lead to the notation manual, but merely > to a short blurb that tells you what the notation manual would be if you > actually managed to find it. I mean, wow. Talk about wow. And I told you that it was added to git already: http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commit;h=e71d9dda07d43f16c4de5d8aca710b819de95a86 I mean, wow. Talk about wow. ... or maybe you didn't notice the VERY NEXT piece of text? Read it now --- * *note Notation: (lilypond-notation)Top.: read this manual in the same format as this one. > > I'd accept a patch that produces an info version of just the > > "Manuals" page. Or made it so that "info lilypond" started at the > > Manuals page. > > So that I can see what the manuals would mean, were I able to figure out > where to find them? The links are there. > Please try getting at any detailed information yourself with the > existing documentation tree before making fun of me. > > I may be stupid, but at one point of time you have to cater even for > stupid people. Let me be clear. - are the info docs not finished? yes. - are the pdf, html, etc. not finished? yes. - did I completely underestimate the pain in doing ANYTHING with the lilypond build process? yes. - would I have completely changed almost everybody about the past summer if I had realized how much trouble it was to change the build system? sweet mao yes. That said, the info docs are a fairly minor concern at the moment, given the mess that the rest of the system is. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: What's the deal with info documentation images?
Graham Percival writes: > On Fri, Aug 28, 2009 at 08:36:33AM +0200, David Kastrup wrote: >> Graham Percival writes: >> >> > Well, yes. FIXMEs generally aren't impressive. The FIXMEs will >> > definitely be dealt with. The images might be dealt with, if >> > somebody deals with them. >> >> But previously (info "(lilypond)") lead to useful top-level information. >> Currently it leads to a chaotic ensemble of FIXMEs, side remarks only >> relevant for web pages, > > ... and by some odd coincidence, we haven't made a stable release > with it in such a state. Imagine that! Does that mean that one is not supposed to report problems until a stable release has been made? > The previous arrangement dumped you into the NR, which is not > suitable for beginners. The current arrangement is suitable for beginners? I again state that the _project_ webpage is not a suitable starting point for the user-level documentation of a _single_ version of Lilypond. Not in info, not in HTML. > Unlike most projects, lilypond has extensive documentation. In order > to let people navigate through and find the part(s) they want to read, > we have it split between multiple manuals. I can't identify any one > manual (other than the current "general" one) that would make sense > for a "info lilypond". It is not a general manual, it is the project home page. The aims of a manual are so much different from that of a project home page that folding the two does not make sense. For the web page, it makes sense to have links leading to "Documentation", even of several versions. For the documentation, it does not make sense. It is supposed to _be_ the documentation, not lead there. It would make much more sense to land the user in either the command line reference (with top-level links to the notation reference) or vice versa. > (or rather, if I was *forced* to pick one, I'd go with the AU, > since that at least has the command-line arguments) It hasn't. Let's walk through this, comments in <<<>>>. File: lilypond.info, Node: Top, Next: Introduction, Up: (dir) (lilypond)Top LilyPond... music notation for everyone *** LilyPond ... music notation for everyone FIXME: images broken in info What is LilyPond? - LilyPond is an open-source music engraving program, devoted to producing the highest-quality sheet music possible. This free software brings the aesthetics of traditionally engraved music to computer printouts. Read more in our *note Introduction::! <<>> FIXME: process news items like the old web site: select first 4 items to insert here, and generate RSS. (*note Old news::) <<>> Quick links --- Stable .. *note Download 2.12.3: Download. *note Manuals 2.12.3: Manuals. <<>> Unstable *note Download 2.13.2: Development. *note Manuals 2.13.2: Development. <<>> * Menu: * Introduction:: Start here to creating sheet music. * Download:: Get LilyPond. * Manuals:: Read The Fine Manuals (RTFM). * Community::Contact other users. << I'd accept a patch that produces an info version of just the > "Manuals" page. Or made it so that "info lilypond" started at the > Manuals page. So that I can see what the manuals would mean, were I able to figure out where to find them? Please try getting at any detailed information yourself with the existing documentation tree before making fun of me. I may be stupid, but at one point of time you have to cater even for stupid people. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Move ambitus print callback to scheme
Carl Sorensen writes: > On Aug 28, 2009, at 1:16 PM, "Nicolas Sceaux" > wrote: > >> >> According to R5RS, it is an error to modify a literal list. >> If a function returns '(), the caller won't be allowed to >> apply a modifying function on the result (eg. append!) >> > > IIUC, '() is not a literal list, but a constant that represents the > empty list. It is a literal list in my opinion, but one that happens to have no unique and/or modifiable conses. Append will work just fine on it. >> However, guile does not report modifying a literal list as an error, >> and actually modifies it, so this is somewhat rhetorical. It is not rhetorical since a modified literal list will actually stay modified when you call the function the next time. Can't happen with '() though. guile> (define (weird) (append! '(4) '(5))) guile> (weird) (4 5) guile> (weird) (4 5 . #1#) guile> (weird) Backtrace: In standard input: 7: 0* [weird] 4: 1 [append! (4 5 . #1#) (5 . #0#)] standard input:4:17: In procedure last-pair in expression (append! (quote #) (quote #)): standard input:4:17: Circular structure in position 1: (4 5 . #1#) ABORT: (misc-error) guile> -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] option to prevent EPS backend from creating .tex/.texi/.count files
> Here is a patch that introduces a command line option aux-files, > which can be used (-daux-files=#f, -dno-aux-files or #(ly:set-option > 'no-aux-files)) to prevent lilypond's eps backend from creating > .tex(i) and .count files: > > http://codereview.appspot.com/110107 > > Okay to apply? Nice idea. While you are at it, please investigate why there are still clipping problems during the EPS->PNG conversion. For an example, look at the snappizzicato example image in the notation reference. My guess is that the `bbox' and similar backends of ghostscript don't expand fonts but simply use the metrics of the fonts referenced in an EPS for the calculation of the bounding box; this gives bad results with lilypond fonts. As a possible solution, I can imagine that we add an intermediate step to convert the fonts in an EPS file into PS paths, for example, by using the `epswrite' device (as demonstrated in the `eps2eps' script which comes with ghostscript). This should assure that the bboxes are exact. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
[PATCH] option to prevent EPS backend from creating .tex/.texi/.count files
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
since I'm currently using lilypond to create lots of small example files for a
larger thesis (written in Word), I'm using the eps backend to create nicely
clipped images. However, instead of one file per example, the eps backend
creates a .tex, a .texi, a .count and several *-1.{pdf,png,eps} files.
Here is a patch that introduces a command line option aux-files, which can be
used (-daux-files=#f, -dno-aux-files or #(ly:set-option 'no-aux-files)) to
prevent lilypond's eps backend from creating .tex(i) and .count files:
http://codereview.appspot.com/110107
Okay to apply?
I'm still looking into not creating -1.eps files for examples with only one
system (in that case, the .eps and the -1.eps files will be identical,
anyway!).
Cheers,
Reinhold
- --
- --
Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/
* Financial & Actuarial Math., Vienna Univ. of Technology, Austria
* http://www.fam.tuwien.ac.at/, DVR: 0005886
* LilyPond, Music typesetting, http://www.lilypond.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
iD8DBQFKmIflTqjEwhXvPN0RAp/BAJ4h0buiQG1UgPIacdC6RabDKAyUWACgqxwG
T0LC2IiNRVMghMDHQ8SSVCw=
=v9cH
-END PGP SIGNATURE-
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: What's the deal with info documentation images?
On Fri, Aug 28, 2009 at 08:36:33AM +0200, David Kastrup wrote: > Graham Percival writes: > > > Well, yes. FIXMEs generally aren't impressive. The FIXMEs will > > definitely be dealt with. The images might be dealt with, if > > somebody deals with them. > > But previously (info "(lilypond)") lead to useful top-level information. > Currently it leads to a chaotic ensemble of FIXMEs, side remarks only > relevant for web pages, Update: aha, now I see what you were talking about... I'd forgotten all the direntry stuff for the docs. I just happened to come across it by accident while I was re-working the main page of NR. Yes, this will be fixed before 2.13.5. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: funky build errors
On Fri, Aug 28, 2009 at 08:55:41AM +0200, Werner LEMBERG wrote: > > Executable based on sources from 00:29 GMT 29-Apr-2008. > > Library based on sources from 20:49 GMT 30-Apr-2008. > > This is ooold. I've compiled the current CVS of FontForge by myself, > and I don't see this (and I haven't seen such errors since almost a > year). George has fixed a bunch of such problems later in 2008, IIRC. > PS: Perhaps we should enforce a newer FontForge version in the > configure script. If there's bugs that affect us that are fixed by later versions, then I guess we should do this. I'll a bit sad to have lilypond no longer compile on debian/stable[1], but I must admit that this is a weird state of affairs. :) [1] I guess that texi2html already spoils this, although that's only in the docs and not the main program. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: What's the deal with info documentation images?
On Fri, Aug 28, 2009 at 08:36:33AM +0200, David Kastrup wrote: > Graham Percival writes: > > > Well, yes. FIXMEs generally aren't impressive. The FIXMEs will > > definitely be dealt with. The images might be dealt with, if > > somebody deals with them. > > But previously (info "(lilypond)") lead to useful top-level information. > Currently it leads to a chaotic ensemble of FIXMEs, side remarks only > relevant for web pages, ... and by some odd coincidence, we haven't made a stable release with it in such a state. Imagine that! > It is quite difficult to actually find a working link to _any_ useful > documentation since half of the links don't work and the other half has > non-obvious names and a structure that has nothing to do with info. If you're tracking git, you would have noticed that I added such links before you sent this message. > I don't see _any_ advantage for the resulting info documentation at > all. With regard to info, the previous arrangement was better in all > respects I can imagine. The previous arrangement dumped you into the NR, which is not suitable for beginners. It also *completely* missed the important info in Usage / AU, namely the command-line arguments. With the new system, users are directed to the appropriate manuals. Unlike most projects, lilypond has extensive documentation. In order to let people navigate through and find the part(s) they want to read, we have it split between multiple manuals. I can't identify any one manual (other than the current "general" one) that would make sense for a "info lilypond". (or rather, if I was *forced* to pick one, I'd go with the AU, since that at least has the command-line arguments) I'd accept a patch that produces an info version of just the "Manuals" page. Or made it so that "info lilypond" started at the Manuals page. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Move ambitus print callback to scheme
On Aug 28, 2009, at 1:16 PM, "Nicolas Sceaux" wrote: > > According to R5RS, it is an error to modify a literal list. > If a function returns '(), the caller won't be allowed to > apply a modifying function on the result (eg. append!) > IIUC, '() is not a literal list, but a constant that represents the empty list. > However, guile does not report modifying a literal list as an error, > and actually modifies it, so this is somewhat rhetorical. Carl > ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Move ambitus print callback to scheme
Le 27 août 09 à 22:38, Neil Puttock a écrit : 2009/8/26 Carl Sorensen : The patch looks good to me. Cheers. You code the empty list as (list). I typically code the empty list as '(). It there a preference? I suspect that we ought to be consistent, although it's not highly important. It could be part of the code janitor work, though. It's just something I noticed in a few places internally (these all seem to be changes made by Nicolas) and thought it was clearer, though admittedly I haven't been particularly consistent when deciding between the two forms. :) According to R5RS, it is an error to modify a literal list. If a function returns '(), the caller won't be allowed to apply a modifying function on the result (eg. append!) However, guile does not report modifying a literal list as an error, and actually modifies it, so this is somewhat rhetorical. nicolas ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LilyPond talks earlier this year at IRCAM and Musikhochschule Stuttgart
Hi Trevor, I wanted to take a minute to provide feedback on two LilyPond-oriented presentations I was able to make earlier this year. Congratulations, and "thanks" from the community! Off-line, I'd be very interested in seeing a (tran)script of your presentation(s): I'm scheduled to give some lectures about Lilypond this year at various universities and colleges in North America. Thanks, Kieren. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Implement framework for post-fix text (de)cresc spanners
On Fri, Aug 28, 2009 at 7:29 AM, Reinhold Kainhofer wrote: >> - get_property_setting() should take SCMs rather than const char* , so >> you save runtime lookups. > > I don't exactly understand what you mean by this... The two parameters of > get_property_setting are passed on the get_property, which call > internal_get_property (symbol2scm (...)) on them. Of course, I could do the > symbol2scm before calling get_property_setting and then call > internal_get_property there, but I don't see how this will save anything (in > particular, since the context property names will be dynamically built from > the start_type: (start_type + "Text").c_str () > > The only thing that might be optimized is the fixed-name event properties. But > that saves one symbol2scm call for hairpins and two for text crescendi. Is > this really worth the trouble of handling the two property names differently > to > save on symbol2scm call? Sorry - I only took a brief look. It might not be worth the trouble in this case, but in general it is better for the C++ part to work with SCMs, so the symbol lookups can be memoized in the caller. -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Implement framework for post-fix text (de)cresc spanners
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Samstag, 22. August 2009 19:19:18 schrieb Han-Wen Nienhuys: > brief comments: > > - get_property_setting() should take SCMs rather than const char* , so > you save runtime lookups. I don't exactly understand what you mean by this... The two parameters of get_property_setting are passed on the get_property, which call internal_get_property (symbol2scm (...)) on them. Of course, I could do the symbol2scm before calling get_property_setting and then call internal_get_property there, but I don't see how this will save anything (in particular, since the context property names will be dynamically built from the start_type: (start_type + "Text").c_str () The only thing that might be optimized is the fixed-name event properties. But that saves one symbol2scm call for hairpins and two for text crescendi. Is this really worth the trouble of handling the two property names differently to save on symbol2scm call? Cheers, Reinhold - -- - -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial & Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQFKl7GQTqjEwhXvPN0RAgPxAJ4iduCC6mqqxSjSF/91Kt+vLulF/QCgkVVD I+LvGekkcHIGVtfCatzNcl4= =pG2z -END PGP SIGNATURE- ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: funky build errors
> I assume that "needed" and "unneeded" aren't actually > contradictions... or maybe they are, and that's why the internal > error is printed. They are contradictions, thus the internal error. It's a rounding issue in FontForge. > Executable based on sources from 00:29 GMT 29-Apr-2008. > Library based on sources from 20:49 GMT 30-Apr-2008. This is ooold. I've compiled the current CVS of FontForge by myself, and I don't see this (and I haven't seen such errors since almost a year). George has fixed a bunch of such problems later in 2008, IIRC. Please update FontForge. Werner PS: Perhaps we should enforce a newer FontForge version in the configure script. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: horizontal offset bug of skip markups
Werner LEMBERG wrote Thursday, August 27, 2009 3:11 PM
After all, it is very easy to place the markup where you want it
by
simply using two spacer notes:
foo = {
s1
\time 7/8 s8^"foobar" s8*6
\time 10/8
}
OK, I haven't thought of that solution, thanks. This should
perhaps
be added to the documentation.
There is a serious drawback of the above solution: If
`skipbars=##t',
you must write e.g. `s1*3' to get a three-bar multi-measure rest
in
constructions like `<< { ... } {... } >>'. Replacing it with `s4
s2. s1*2' gives a different result...
Going back to the original problem, the
only way I can see of positioning markup
reliably to the left of a measure containing
full-measure rests it to use a rehearsal
mark with \mark, adjusting the font as required,
and repositioning the text from that known
position if necessary.
As the suggested solution in the NR no longer
works I'll change it to this, unless a better
solution is forthcoming from someone else.
A possible solution (and maybe even a good one regardless of the
specific problem) is to make `skipbars' ignore the structure of
skip
rests, always accumulating them to the maximum value.
That sounds reasonable, but is not a solution
that is immediately available.
Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
