Re: Error with make doc
[Carl sent me the file listing off-list, thanks! I will analyze it in due course.] > [...] and make test with a single job (to avoid race conditions that > have given me trouble in the past): Interesting. When is the 'past'? This shouldn't happen today, and it would be great if you could try a `-jXX' make option in the future so that we can see if you really get a failure. > now on to your requested steps: Ah, my steps were not intended to be used additionally but instead :-) > Everything completed without error. This is good. Regarding the `cp -l` issue: Irrespective of the faulty implementation on macOS it turns out that option `-l` isn't portable at all, as I was told by the autoconf people. I'm going to replace it with something else that also works across file system boundaries (which even a working `cp -l` does not). Werner
PATCHES - Countdown to February 5
Here is the current countdown report. The next countdown will begin on 2024-02-05 A list of all merge requests can be found here: https://gitlab.com/lilypond/lilypond/-/merge_requests?sort=label_priority Push: !2250 Fix compilation warnings. - Werner Lemberg https://gitlab.com/lilypond/lilypond/-/merge_requests/2250 !2246 binaries: Update dependencies - Jonas Hahnfeld https://gitlab.com/lilypond/lilypond/-/merge_requests/2246 Countdown: No patches in Countdown at this time. Review: !2251 Referencing individual LSR snippets - Werner Lemberg https://gitlab.com/lilypond/lilypond/-/merge_requests/2251 New: No patches in New at this time. Waiting: No patches in Waiting at this time. Cheers, Colin
Re: Chord grids enhancement
Le vendredi 02 février 2024 à 20:29 +0100, Éric Würbel a écrit : > Hi fellow listers > > (from a long time user and enthusiast of lilypond from the very first > released version), > > The recent introduction of so called "chord grids" is a long awaited > feature for me, amateur musician mainly involved in music requiring > improvisation. > > In particular, the ChordGrid context allows customization of the > rendering of grid cells, and proposes a \medianChordGridStyle which > adhere to a de facto standard of harmonic grids rendering. > > But this style is limited. By default, for 4/4 time signature, it only > proposes a median cut of a cell when there is one chord per quarter note > (1/4 1/4 1/4 1/4 pattern). In cases like 1 chord for two beats and the > two next chords for one beat each (1/2 1/4 1/4), it rolls back to the > "diagonal" notation (and I agree with Philippe Baudoin, this notation is > a real mess). > > I quickly hacked a modification (at scm level) to handle properly the > following patterns : > - 1/2 1/4 1/4 > - 1/4 1/4 1/2 > - 3/4 1/4 > - 1/4 3/4 > > Which are, in the context of 4/4 jazz, the most commonly encountered. > > I am currently working on Balkan music patterns with asymetric time > signatures, like 11/8, 7/8, etc, but I wait before proposing something, > because I suspect that the general problem has something in common with > the beaming grouping problem, so I want to be able to propose something > consistent with the automatic beam grouping approach. > > How can submit a patch ? forking the master branch and submitting a pull > request ? > > Thank you. > > Regards. > > Éric Adding Vincent in CC. I don't know much about jazz, I basically implemented this notation from his instructions. signature.asc Description: This is a digitally signed message part
Re: Chord grids enhancement
Ok, sorry, I should have read the document mentionned in the link. Le ven. 02 févr. 2024 à 16:54, Dan Eble a écrit : > On 2024-02-02 14:29, Éric Würbel wrote: > >> How can submit a patch ? forking the master branch and submitting a pull >> request ? > > Yes. > > https://lilypond.org/doc/v2.25/Documentation/contributor/summary-for-experienced-developers -- http://www.vents-sauvages.fr/ gemini://retry-abort.org/ Gemini ? https://gemini.circumlunar.space/
Re: Chord grids enhancement
On 2024-02-02 14:29, Éric Würbel wrote: How can submit a patch ? forking the master branch and submitting a pull request ? Yes. https://lilypond.org/doc/v2.25/Documentation/contributor/summary-for-experienced-developers -- Dan
Chord grids enhancement
Hi fellow listers (from a long time user and enthusiast of lilypond from the very first released version), The recent introduction of so called "chord grids" is a long awaited feature for me, amateur musician mainly involved in music requiring improvisation. In particular, the ChordGrid context allows customization of the rendering of grid cells, and proposes a \medianChordGridStyle which adhere to a de facto standard of harmonic grids rendering. But this style is limited. By default, for 4/4 time signature, it only proposes a median cut of a cell when there is one chord per quarter note (1/4 1/4 1/4 1/4 pattern). In cases like 1 chord for two beats and the two next chords for one beat each (1/2 1/4 1/4), it rolls back to the "diagonal" notation (and I agree with Philippe Baudoin, this notation is a real mess). I quickly hacked a modification (at scm level) to handle properly the following patterns : - 1/2 1/4 1/4 - 1/4 1/4 1/2 - 3/4 1/4 - 1/4 3/4 Which are, in the context of 4/4 jazz, the most commonly encountered. I am currently working on Balkan music patterns with asymetric time signatures, like 11/8, 7/8, etc, but I wait before proposing something, because I suspect that the general problem has something in common with the beaming grouping problem, so I want to be able to propose something consistent with the automatic beam grouping approach. How can submit a patch ? forking the master branch and submitting a pull request ? Thank you. Regards. Éric -- http://www.vents-sauvages.fr/ gemini://retry-abort.org/ Gemini ? https://gemini.circumlunar.space/
Re: Error with make doc
On Fri, Feb 2, 2024 at 4:34 AM Werner LEMBERG wrote: > >> Please read this and check whether you are affected by this > >> problem. In case you can confirm the issue please try whether it > >> works if you omit the `-l` option in all `cp` calls in my patch. > > > > I checked -- the results of the problem were different for me than > > for the bug report. I got the error message, but the hard link was > > never copied (there were not two files with the same inode -- only > > the original file. > > OK, so there is indeed a problem with `cp -l` on your macOS. It's > still hard to believe. > Yes, and apparently it's a new bug (older versions of the OS didn't have it, IIUC). > > BTW, which macOS version are you using? > Sonoma 14.2.1 (23C71) > > > I omitted the '-l' option in the cp calls in the patch. > > > > 'make doc' succeeded without any errors, so I thought I had success. But > > it turns out that > > > > a) I appear not to have the .css files copied (at least the output > >showed no css -- just basic white screen), and > > b) I appear not to have the image files copied (there are no images > >that show up in any of the pages accessible from > >www-out/offline-root). > > It seems that my patch doesn't work as expected, or that I have missed > something. As usual, please start from scratch and run the standard > incantation (or your adapted variation of it) > > > ``` > ./configure > make bytecode -j12 > make doc -j12 CPU_COUNT=12 LANGS="en" > ``` > > (please tell me what git commit you are using so that I can try > exactly the same setup). After finishing, please call > > ``` > find . | gzip > find.log.gz > ``` > > in your build directory and send me the file *privately* for further > inspection (it's about 750kByte compressed – listing approx. 16 > files) and of no real interest to other readers of this list). > > I will do this today. > > Does it make sense to try again with the xargs part of the patch, > > but using the GNU cp and find? > > For you personally, it certainly makes sense so that you get a > successful build. For the LilyPond project, however, I think it's > best to use native OS tools so that the number of additional > requisites stays as small as possible. > I tried with the xargs part of the patch, with the GNU cp and find. It executed sucessfully (no errors). But it also had no css on the resulting index.html. I viewed the source of index.html. It referenced the css from css/lilypond-website.css, but there was no 'css' directory in build/out-www/offline-root/. I tried copying the css directory from lilypond/Documentation to build/out-www/offline-root, but still didn't get a properly styled webpage. Thanks, Carl
Re: Error with make doc
>> Please read this and check whether you are affected by this >> problem. In case you can confirm the issue please try whether it >> works if you omit the `-l` option in all `cp` calls in my patch. > > I checked -- the results of the problem were different for me than > for the bug report. I got the error message, but the hard link was > never copied (there were not two files with the same inode -- only > the original file. OK, so there is indeed a problem with `cp -l` on your macOS. It's still hard to believe. BTW, which macOS version are you using? > I omitted the '-l' option in the cp calls in the patch. > > 'make doc' succeeded without any errors, so I thought I had success. But > it turns out that > > a) I appear not to have the .css files copied (at least the output >showed no css -- just basic white screen), and > b) I appear not to have the image files copied (there are no images >that show up in any of the pages accessible from >www-out/offline-root). It seems that my patch doesn't work as expected, or that I have missed something. As usual, please start from scratch and run the standard incantation (or your adapted variation of it) ``` ./configure make bytecode -j12 make doc -j12 CPU_COUNT=12 LANGS="en" ``` (please tell me what git commit you are using so that I can try exactly the same setup). After finishing, please call ``` find . | gzip > find.log.gz ``` in your build directory and send me the file *privately* for further inspection (it's about 750kByte compressed – listing approx. 16 files) and of no real interest to other readers of this list). > Does it make sense to try again with the xargs part of the patch, > but using the GNU cp and find? For you personally, it certainly makes sense so that you get a successful build. For the LilyPond project, however, I think it's best to use native OS tools so that the number of additional requisites stays as small as possible. Werner
