Re: guilev2-work [was: LilyPond boolean syntax? \true and \false]
2016-01-16 21:40 GMT+01:00 David Kastrup : > Thomas Morley writes: > >> 2016-01-12 0:22 GMT+01:00 David Kastrup : >>> Thomas Morley writes: >>> 2016-01-11 23:14 GMT+01:00 David Kastrup : >> Btw, it wasn't entirely clear to me that guilev2.x changes essential >> stuff that often. >> Exactly which guile-version are we aiming for? > > The non-existing 2.0.12. Currently, the stable-2.0 branch. The main > challenge currently seems to be compiling LilyPond with a Guile version > that is not installed on your system. To be sure, the exercise is: (1) checkout the marked branch ~/guile (master)$ git branch -a * master >>> [...] remotes/origin/stable-2.0 ^^ >>> [...] >>> (2) Compile it (3) Build LilyPond with this guile somehow Correct? >>> >>> It's the basis for making more tangible progress. [...] >> >> I've now checked out branch origin/stable-2.0, derived a local branch >> and compiled it. >> >> ~/guile/meta (my-stable-2.0)$ ./guile >> GNU Guile 2.0.11.170-4d08e >> [...] >> >> Should be the version we aim at. >> >> Though, how to compile LilyPond with this guile-version? >> Which commands do you actually use for it? > > That question is easy to answer: I never built with anything but the > Ubuntu Guile versions. So this would appear to be of the "look at what > options "./configure --help" offers for this" kind. And if it's silent > about that, see what kind of environment variables might be interpreted. > > I mean, Gub has to do the same here: build its own library version and > use/link it. So there must be a way. > > -- > David Kastrup "./configure --help" offers some options, eg. --with-python-include=DIR --with-python-lib=NAME but nothing directly for guile. There are several environment variables like CFLAGS but I don't know how to use them or the syntax they expect. Full output of "./configure --help" attached. I really hope someone can demonstrate how to point configure to a self-compiled guile. Cheers, Harm `configure' configures this package to adapt to many kinds of systems. Usage: ../configure [OPTION]... [VAR=VALUE]... To assign environment variables (e.g., CC, CFLAGS...), specify them as VAR=VALUE. See below for descriptions of some of the useful variables. Defaults for the options are specified in brackets. Configuration: -h, --help display this help and exit --help=shortdisplay options specific to this package --help=recursivedisplay the short help of all the included packages -V, --version display version information and exit -q, --quiet, --silent do not print `checking ...' messages --cache-file=FILE cache test results in FILE [disabled] -C, --config-cache alias for `--cache-file=config.cache' -n, --no-create do not create output files --srcdir=DIRfind the sources in DIR [configure dir or `..'] Installation directories: --prefix=PREFIX install architecture-independent files in PREFIX [/usr/local] --exec-prefix=EPREFIX install architecture-dependent files in EPREFIX [PREFIX] By default, `make install' will install all the files in `/usr/local/bin', `/usr/local/lib' etc. You can specify an installation prefix other than `/usr/local' using `--prefix', for instance `--prefix=$HOME'. For better control, use the options below. Fine tuning of the installation directories: --bindir=DIRuser executables [EPREFIX/bin] --sbindir=DIR system admin executables [EPREFIX/sbin] --libexecdir=DIRprogram executables [EPREFIX/libexec] --sysconfdir=DIRread-only single-machine data [PREFIX/etc] --sharedstatedir=DIRmodifiable architecture-independent data [PREFIX/com] --localstatedir=DIR modifiable single-machine data [PREFIX/var] --libdir=DIRobject code libraries [EPREFIX/lib] --includedir=DIRC header files [PREFIX/include] --oldincludedir=DIR C header files for non-gcc [/usr/include] --datarootdir=DIR read-only arch.-independent data root [PREFIX/share] --datadir=DIR read-only architecture-independent data [DATAROOTDIR] --infodir=DIR info documentation [DATAROOTDIR/info] --localedir=DIR locale-dependent data [DATAROOTDIR/locale] --mandir=DIRman documentation [DATAROOTDIR/man] --docdir=DIRdocumentation root [DATAROOTDIR/doc/PACKAGE] --htmldir=DIR html documentation [DOCDIR] --dvidir=DIRdvi documentation [DOCDIR] --pdfdir=DIRpdf documentation [DOCDIR] --psdir=DIR ps documentation [DOCDIR] System types: --build=BUILD configure for building on BUILD [guessed] --host=HOST cross-compile to build programs to run on HOST [BUILD] Optional Features: --disable-option-checking ignore unrecogniz
git-cl documentation and issue #4666
Hi James, I thought your CG edits in issue 4666 were a really helpful improvement: https://sourceforge.net/p/testlilyissues/issues/4666/ Did you intend to keep this git-cl info (install and configuration) in the 3.3.4 Commits and Patches section, so that it is repeated in both places? Seems like 3.3.4 should now just link to 2.3 git-cl for install, update, and configuration instructions. (Currently one has to scroll past the install and configure section each time one consults the docs about how to create or upload a patch for review.) -Paul ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: ly:one-page-breaking (was: ly:one-line-breaking)
> On Jan 19, 2016, at 4:02 AM, Richard Shann wrote: > > That's great news! For the application to Denemo taglines and footnotes > are not wanted anyway as it is for creating a score to play from > on-screen. > I guess it will be some time before this code gets into a release? It depends on whether or not this is acceptable with the current known issues. (Some other pressing demands mean that I need to take a break from LilyPond work for some months, so I won’t have time to further improve upon this any time soon.) In its current state it would already work for many of the more obvious use cases – like Denemo’s on-screen score or producing image files destined for other documents. Should I put this up for code review or should we discuss this on the dev list? …or in an issue tracker? >> The approach is to temporarily set the page-height to the largest size >> possible, > > What is the largest size possible? I tried playing around with some > sizes, and some didn't work … I tried setting it to positive infinity, but that gave a programming error when there was a tagline. I traced the error to Stencil::translate, which throws the error for any value greater than 1e6. So I used 1e6 as the temporary page-height and everything is working fine. >> do the line breaking and page layout for that page height, then get the >> vertical position on the page and the height of the lowest system (or top >> level markup), and use that to calculate and then set the final page height >> so that it fits the content of the page. > > A crude version of this is what will be in the impending Denemo release > - Denemo creates the SVG output and counts the pages and then re-runs > LilyPond at a larger page size. I think that should work pretty well for your use case. I considered a similar approach before I worked out the current one. -Paul ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Result of (ly:get-option 'point-and-click)
Urs Liska writes: > Hi devs, > > please consider > > #(if (ly:get-option 'point-and-click) > (let ((point-and-click (ly:get-option 'point-and-click))) >(display point-and-click))) > > Can this ever print anything else than #t ? Yes. > As far as I can see > (ly:get-option 'point-and-click) > > can return either #t or #f, is that right? No. > And if that's right what is the code in output-ps.scm for: > > (if (ly:get-option 'point-and-click) > (let* ((cause (ly:grob-property grob 'cause)) > (music-origin (if (ly:stream-event? cause) >(ly:event-property cause 'origin))) > (point-and-click (ly:get-option 'point-and-click))) > (if (and > (ly:input-location? music-origin) > (cond ((boolean? point-and-click) point-and-click) >((symbol? point-and-click) > (ly:in-event-class? cause point-and-click)) >(else (any (lambda (t) > (ly:in-event-class? cause t)) > point-and-click > > It looks that all this code is only executed when point-and-click is > set, so I don't see why all this code has to be executed. When all else fails, try reading the documentation. http://lilypond.org/doc/v2.18/Documentation/usage/configuring-the-system-for-point-and-click#selective-point_002dand_002dclick> > As a test I replaced the conditional by a simple > (if (ly:input-location? music-origin) > and a few test scores compiled with proper point-and-click in the output > file. > > So: Is there a reason for this code or can I remove it? There is a reason, it is extensively documented, and you could have used "git blame -w" on the lines in question to lead that reason back to commit 4e021773761fbb873602891f788b408c5c085953 Author: David Kastrup Date: Tue Nov 1 20:55:04 2011 +0100 Issue 1954: Implement event type filtering for pointAndClick events. I mean, code cleanup is all well and nice, but we are talking about a well-traceable feature with full user-level documentation, user-level commands to control it, and regtest and everything here. What does it take to save a feature from "cleanup"? -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Result of (ly:get-option 'point-and-click)
Hi devs, please consider #(if (ly:get-option 'point-and-click) (let ((point-and-click (ly:get-option 'point-and-click))) (display point-and-click))) Can this ever print anything else than #t ? As far as I can see (ly:get-option 'point-and-click) can return either #t or #f, is that right? And if that's right what is the code in output-ps.scm for: (if (ly:get-option 'point-and-click) (let* ((cause (ly:grob-property grob 'cause)) (music-origin (if (ly:stream-event? cause) (ly:event-property cause 'origin))) (point-and-click (ly:get-option 'point-and-click))) (if (and (ly:input-location? music-origin) (cond ((boolean? point-and-click) point-and-click) ((symbol? point-and-click) (ly:in-event-class? cause point-and-click)) (else (any (lambda (t) (ly:in-event-class? cause t)) point-and-click It looks that all this code is only executed when point-and-click is set, so I don't see why all this code has to be executed. As a test I replaced the conditional by a simple (if (ly:input-location? music-origin) and a few test scores compiled with proper point-and-click in the output file. So: Is there a reason for this code or can I remove it? Urs ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: ly:one-page-breaking (was: ly:one-line-breaking)
On Mon, 2016-01-18 at 22:51 -0500, Paul Morris wrote: > > On Jan 9, 2016, at 1:30 PM, Richard Shann wrote: > > > > I was wondering if it would be possible to develop a variant of "all on > > one line", namely "all on one page", where the page height would be > > automatically adjusted to fit the music, leaving the width as set. > > I’m glad to report that I’ve made some real progress. > The code in the attached patch delivers the basic functionality, with a few > "known issues". > Namely the tagline and any footnotes are not included, > and bookparts trigger default page breaking for some reason. > I haven’t tested it extensively but titles (etc.), top level markups, > multiple scores, > all seem to work just fine. That's great news! For the application to Denemo taglines and footnotes are not wanted anyway as it is for creating a score to play from on-screen. I guess it will be some time before this code gets into a release? > The approach is to temporarily set the page-height to the largest size > possible, What is the largest size possible? I tried playing around with some sizes, and some didn't work ... > do the line breaking and page layout for that page height, then get the > vertical position on the page and the height of the lowest system (or top > level markup), and use that to calculate and then set the final page height > so that it fits the content of the page. A crude version of this is what will be in the impending Denemo release - Denemo creates the SVG output and counts the pages and then re-runs LilyPond at a larger page size. Richard ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel