Re: Please test gub
On 2/6/19, 3:42 PM, "lilypond-devel on behalf of Knut Petersen" wrote: >> - the need to make sure that `python` calls a python2 interpreter. > No idea how this could be solved elegantly. I guess it can't, so we > have again something to document... > Use /usr/bin/env python2? Does every python 2.x installation really contain a python2 executable? OSX 10.12 Sierra has python 2.7 but does not have a python2 executable. Only python. At least this is the case on my machine. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: New feature: automatically invert chords or drop/rise chord notes (issue 365840043 by v.villen...@gmail.com)
On Feb 7, 2019, at 14:49, v.villen...@gmail.com wrote: > > That being said, no problem for adding index entries no matter what we > end up choosing. Would anyone else have thoughts on the subject of > \invertChords vs \rotateChords? So that it’s clear: I have no firm objection to \invertChords. I just wanted to make sure that the names were well explored. Regards, — Dan ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Please test gub
Hi Knut, hi folks, On Mon 2019-01-28 13:53 +0100, Knut Petersen wrote: > Please report success / fails with os / version / cpu info. With this setup: - PRs 53-60 (including update to PR 59 on January 27) applied to GUB, - Ubuntu 14.05 LTS amd64, ran in a chroot from Fedora 29, - an Intel Core 2 Duo E8500 at 3.16GHz I had a build of LilyPond binaries, tests and docs without error in about 8 hours, with master branch; I got also the same with stable/2.20 branch plus a couple of additional commits: - addition of texinfo/txi-pt.tex from Texinfo sources, as Portuguese translation has been added and I don't have Texinfo installed in GUB host system; - update of texinfo.tex (not necessary, but I did it together with txi- pt.tex addition) - application of Masamichi Hosoda patch for issue 5463; - backport from master of "Add `TEX` environemnt variable for texi2pdf". I pushed the resulting branch to dev/jm-stable-2.20 so you may review this. I succesfully tested Linux-64 bit binary built from LilyPond master branch on my Fedora 29 system, on a medium-sized sample. As for documentation, the text in UTF-8 sample in Snippets is well rendered in LilyPond output, but non-Latin1 text is not rendered in ly code quotation in PDF format (this text is also screwed in last 2.19 release, whereas in 2.18 last release only Latin-1 and Cyrillic text is rendered in ly source). I've had some trouble doing non clean GUB builds, namely a Python KeyError with "odcctools-doc". I'll do other builds from scratch, testing newer pull requests on top of #53-60, and will also make an attempt on Fedora 29 plus local install of GCC 7 (with GCC 8 shipped with this distro, tools:guile GUB build fails, and it seems hard to fix). Best -- John Mandereau ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: New feature: automatically invert chords or drop/rise chord notes (issue 365840043 by v.villen...@gmail.com)
On 2019/02/03 14:59:03, dan_faithful.be wrote: While it is true that this algorithm yields chords that people call inversions, it does not yield every chord that might be so called. Huh. Not having learned music theory in an English-speaking environment, I must say I’m at a bit of a loss when I see these referred to as "inversions" anyway (which they’re really not). However, it’s my understanding that this is their sort-of-official name; whereas "chord rotations", whilst making sense in a way, doesn’t seem to register as usual musical lingo (a cursory DuckDuckGo search mainly returns engineering and seismology results). Also, please note that the command we’re discussing here isn’t \inversion (that’s an already-existing, and aptly-named, LilyPond command), but \invertChords. And somehow, \rotateChords would sound a bit like a misnomer to me (I’d expect it to change the order of the intervals *inside* the chord, whilst preserving the same lowest and highest note -- perhaps it’s because I’m used to literally "rotating" chords in a 2D-plane when representing pitches in a Tonnetz). That being said, no problem for adding index entries no matter what we end up choosing. Would anyone else have thoughts on the subject of \invertChords vs \rotateChords? Thanks! V. https://codereview.appspot.com/365840043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Please test gub
Hi, On 06.02.19 23:31, Knut Petersen wrote: On 06.02.19 15:09, Werner LEMBERG wrote: That leaves the two problems of - LLVMgold.so in /usr/lib/bfd-plugins shadowing liblto_plugin.so (I rm'ed LLVMgold.so there for the purpose of the above gub run.) This is definitely *not* a gub issue. It's strange that only the compilation of guile is affected by the problem, but I consider this a pure coincidence. IOW, this should be added to the gub documentation, as a special preparation step for some LLVM/binutils combinations. I agree. I have no idea regarding that issue and trust your assessment. - the need to make sure that `python` calls a python2 interpreter. No idea how this could be solved elegantly. I guess it can't, so we have again something to document... Use /usr/bin/env python2? Does every python 2.x installation really contain a python2 executable? Not sure, but according to PEP 394, they "should". The PEP dates back to 2011, so I'd assume that all systems have a corresponding alias by now, and only the default `python` is different. (IIUC, Gentoo follows Arch's example, see the bottom of https://wiki.gentoo.org/wiki/Python; do we have any Gentoo users here?) Of course, Arch obviously disregards the PEP's first recommendation (python should point to python2), so it's perfectly fair to consider this entirely Arch's / Gentoo's fault. However, one of the good reasons Archers state to follow the explicit python2 / python3 spelling (and having python3 as default) is that python2 will see it's end of maintenance at the end of this year, and they plan to stop distributing python2 as a first-class citizen in the core repositories more or less immediately (it will still be easily available via community repos though). So following all of the PEP, you'd end up with a system that has python3, but neither python nor python2. Perhaps that's harsh, but it's a reasonable decision given that official support ends. In the rationale, the PEP says "As some of the former distributions did not provide a python2 command by default, there was previously no way for Python 2 code (or any code that invokes the Python 2 interpreter directly rather than via sys.executable) to reliably run on all Unix-like systems without modification, as the python command would invoke the wrong interpreter version on some systems, and the python2 command would fail completely on others." so this might not be *entirely* smooth. https://mail.python.org/pipermail/python-dev/2011-March/108491.html mentions Debian, Slack and BSDs; but AFAIK, all of those follow the PEP these days. I think we also would need to change some lilypond files ... FWIW, this is what is done in the Arch packaging process: for file in $(find . -name '*.py' -print); do sed -i 's_^#!.*/usr/bin/python_#!/usr/bin/python2_' $file sed -i 's_^#!.*/usr/bin/env.*python_#!/usr/bin/env python2_' $file done sed -i 's|GUILE_CFLAGS=.*|GUILE_CFLAGS="`pkg-config --cflags guile-1.8`"|' configure sed -i 's|GUILE_LDFLAGS=.*|GUILE_LDFLAGS="`pkg-config --libs guile-1.8`"|' configure plus a patch regarding fontsizes; not sure what this is about: https://git.archlinux.org/svntogit/community.git/tree/trunk/lilyfontsize.patch?h=packages/lilypond It might be worth testing whether applying this patch upstream breaks anything for someone else; but of course, that's from an Arch user's perspective... Cheers, Alex smime.p7s Description: S/MIME Cryptographic Signature ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
debugging problem
Folks, while trying to find out why https://sourceforge.net/p/testlilyissues/issues/5472/ doesn't work as expected, I stumbled across a problem that I'm not able to locate since hours. Consider this call (with the patch from issue #5472 applied), where lilypond gets configured and compiled in a separate directory `lilypond.compiled': cd /home/wl \ && mkdir out-test \ && /home/wl/git/lilypond.compiled/out/bin/lilypond -V \ -H texidoc \ -H options \ -o ./out-test \ /home/wl/git/lilypond/input/regression/midi/crescendo-gap-compatible-target.ly Where is the output name constructed for the MIDI file? To be more precise, where is the string /home/wl/git/lilypond/input/regression/midi/crescendo-gap-compatible-target.ly converted to the basename of the MIDI file? Right now, in function `write-performance-midis' (file `midi.scm'), `basename' is already /crescendo-gap-compatible-target.ly (note the incorrect leading slash)... Any help is highly appreciated. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCHES - Countdown for Feb 7th
> New: No new patches at this time. Please put https://sourceforge.net/p/testlilyissues/issues/5468/ into the loop – it contains a new, improved patch, and it seems that I've reset the tags to wrong values so that it slipped your attention. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
PATCHES - Countdown for Feb 7th
Hello, Here is the current patch countdown list. The next countdown will be on February 10th A quick synopsis of all patches currently in the review process can be found here: http://philholmes.net/lilypond/allura/ Push: 5471 Improve relocation debug messages. - Werner LEMBERG https://sourceforge.net/p/testlilyissues/issues/5471 http://codereview.appspot.com/347070043 Countdown: 5464 New feature: automatically invert chords or drop/rise chord notes - Valentin Villenave https://sourceforge.net/p/testlilyissues/issues/5464 http://codereview.appspot.com/365840043 1367 Enhancement: NoteNames context should handle any note names language - Valentin Villenave https://sourceforge.net/p/testlilyissues/issues/1367 http://codereview.appspot.com/8593046] Review: No patches on review at this time. New: No new patches at this time. *** Regards James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
