GSoC 2021
One thing we all need to be aware of is that GSoC has reduced the coding period by half for 2021. Projects are now about 175 hours instead of about 350 hours. As we think about projects, we need to be thinking about the reduced scope. Thanks, Carl
Re: Summer of Code inquiry
Hi Kyle, This is a totally selfish request… but I’d love it if you considered picking up the lyrics work where Janek left off. Taking that project to the goal line (bar line?) would not only solve a huge number of really thorny and time-consuming issues for anyone (like me) who writes music with lyrics, but it would almost certainly require the development of some really useful [spacing] routines and logic that could help with other issues and requests. I would be more than happy to be the “Community Mentor” for that project, though we’d have to find an actual Code Mentor willing to come on board. Cheers, Kieren. Kieren MacMillan, composer (he/him/his) ‣ website: www.kierenmacmillan.info ‣ email: kie...@kierenmacmillan.info
Re: Summer of Code inquiry
Re contemporary notation, I disagree with this. I work professionally on New Complexity School scores, and every composer has their own notation and preferences and idiosyncrasies. Other contemporary schools all have their own individual styles. We are nowhere near standardisation of the sort that applies to Common Era music. I have a Scheme library of code for my engraving that took fours years to develop in conjunction with my composer colleague. It's completely meaningless for anybody else. I don't know of many composers settling on Lachenmann notation, and indeed, many composers refuse to settle on a standard as part of their entire aesthetic. I think this is why the contemporary notation project has stalled - there is no and will not be any uniformity to make it worthwhile. I'd suggest you look at other aspects of LilyPond to work on, sincerely. Maybe something really practically useful like MusicXML work. I thought MAX is not open source, but a quite expensive commercial program from Cycling74? https://cycling74.com/shop Does not really fit the open source world of LilyPond, even though one library project may be open source. Or you could fix Issue 34! Andrew On 21/11/2020 5:00 am, 98123981293 1293812397123 wrote: Ok; the project concerning contemporary notation looks interesting and like it may leverage my background; per that problem description, re: specific composers: Helmut Lachenmann's notation is becoming widespread, so perhaps it would be worthwhile to engrave an entire score by this composer and develop custom Scheme extensions for doing so. Also, thank you for the Gitlab link and tip on "Frog" problems; I'll get set up there and start watching for things I can help on.
Re: [RFC] Automatic 'make check' in CI
On Nov 20, 2020, at 12:22, Jonas Hahnfeld wrote: > >>> Despite these shortcomings, I think it would make sense to enable >>> this first implementation in lilypond/lilypond. What do you think? >>> >> >> yes, +1 . I am especially happy that this will likely have no extra >> overhead. > > No extra overhead per pipeline in MRs, but you get an extra pipeline > for every merge to master. We'll see if this poses a serious problem… Given the positive feedback this change has already received, can we accelerate its progress? I'm eager to have it in place because I've got a branch with new some regression tests ready. — Dan
Re: Summer of Code inquiry
>The remaining ideas are still worth to consider, however, the mentioned mentors might not be available anymore. If you have further ideas please tell us. Ok; the project concerning contemporary notation looks interesting and like it may leverage my background; per that problem description, re: specific composers: Helmut Lachenmann's notation is becoming widespread, so perhaps it would be worthwhile to engrave an entire score by this composer and develop custom Scheme extensions for doing so. Also, thank you for the Gitlab link and tip on "Frog" problems; I'll get set up there and start watching for things I can help on. Further ideas: speaking of recursive acronyms, the bACH (Automated Composer Helper) library for Max/MSP went open source this year; they include a basic Lilypond export function, but it's quite buggy and not up to date. I did fork it to play around with it, but progress is slow going since I don't know C/C++ yet (bACH is mostly written in these two languages). The two developers are both very busy, and not frequent Lilypond users, so I thought it might be nice to have the bACH package and Lilypond learn to talk to each other in a deeper way given that both communities are now open source (well sort of, you still need Max to run bACH...but I wonder if in the future they intend to release it as an independent program; it's now a decade old). Including a basic 'export to bach' command in Lilypond might be easy enough. I don't know if any of this is a priority for Lilypond itself, but just thought I'd mention it since you asked if I had ideas. -Kyle
Re: [RFC] Automatic 'make check' in CI
Am Freitag, den 20.11.2020, 10:11 +0100 schrieb Han-Wen Nienhuys: > > There are a few known issues that I'm aware of: > > - I needed to delete input/regression/option-help.ly because it > > logs the options currently in use by lilypond, including the job- > > count which varies when using our own runners with more than one > > core. > > > > we could overwrite the job-count option in the option help, as it is > irrelevant by the time you get to the file processing. While this might work for job-count (I'd still consider it a hack), there is at least also log-file which depends on the current process. The right solution would be to show the original default value in the help output, but the test prints exactly what you enter into scm/lily.scm so I don't really see its benefit at this point.. > > > - Sometimes the test-results contain spurious diffs, for example > > here: > > https://hahnjo.gitlab.io/-/lilypond/- > > /jobs/858441670/artifacts/test-results/index.html > > I can reproduce this locally with --enable-checking, but haven't > > investigated further yet (there were a couple of other problems > > that I needed to solve in order to get things working...). If > > somebody has an idea for a fix, that would be great but I think > > these can be safely ignored for now. > > > > This could happen because of false-positives in the conservative > garbage collection. It's not super-likely, but at the same time, it > can't be ruled out. Does it always happen with the same files? I > have never seen this, and the files are not doing anything out of the > ordinary. It doesn't happen every time and AFAICT it might hit many different files, but I see it pretty consistently when building with --enable- checking. > IIRC, the dead-object detection can't be made to work anyway with > GUILE 2.x, so this might be a good moment to scrap it. As I said, I didn't investigate yet. But an explicit warning that consistently triggers on different systems at least makes me wonder if there's something going on. > > Despite these shortcomings, I think it would make sense to enable > > this first implementation in lilypond/lilypond. What do you think? > > > > yes, +1 . I am especially happy that this will likely have no extra > overhead. No extra overhead per pipeline in MRs, but you get an extra pipeline for every merge to master. We'll see if this poses a serious problem... Jonas signature.asc Description: This is a digitally signed message part
PATCHES - Countdown for November 20th
Hello,
Here is the current patch countdown list. The next countdown will be on
November 22nd.
A list of all merge requests can be found here:
https://gitlab.com/lilypond/lilypond/-/merge_requests?sort=label_priority
Push:
!514 main.cc: Show '-d=no-foo' in help screen (#2814) - Werner Lemberg
https://gitlab.com/lilypond/lilypond/-/merge_requests/514
!512 Doc: Small adjustments for NR 4.1.6 - Michael Käppler
https://gitlab.com/lilypond/lilypond/-/merge_requests/512
!506 NR: Revise fonts section - Werner Lemberg
https://gitlab.com/lilypond/lilypond/-/merge_requests/506
Countdown:
!516 Doc: Document debug-{slur,beam,tie}-scoring - Michael Käppler
https://gitlab.com/lilypond/lilypond/-/merge_requests/516
Review:
!518 Fix inclusion problems - Jonas Hahnfeld
https://gitlab.com/lilypond/lilypond/-/merge_requests/518
!510 Various font setup improvements - Werner Lemberg
https://gitlab.com/lilypond/lilypond/-/merge_requests/510
New:
!517 Run test-baseline on default branch - Jonas Hahnfeld
https://gitlab.com/lilypond/lilypond/-/merge_requests/517
Waiting:
!511 compile.itexi: Update requirements - Werner Lemberg
https://gitlab.com/lilypond/lilypond/-/merge_requests/511
***
Regards,
James
Re: [RFC] Automatic 'make check' in CI
On Wed, Nov 18, 2020 at 9:25 PM Jonas Hahnfeld wrote: > Hi all, > > I'd like to present a first workable version of 'make check' for use in > our CI pipelines. I've pushed the necessary commits to my personal fork > and created two merge requests to demonstrate the results: > > 1. Run 'make check' for merge requests (no difference) > URL: https://gitlab.com/hahnjo/lilypond/-/merge_requests/5 > Job: https://gitlab.com/hahnjo/lilypond/-/jobs/858498690 > test-results: > > https://hahnjo.gitlab.io/-/lilypond/-/jobs/858498690/artifacts/test-results/index.html > > 2. Introduce difference in bar-lines.ly > URL: https://gitlab.com/hahnjo/lilypond/-/merge_requests/6 > Job: https://gitlab.com/hahnjo/lilypond/-/jobs/852618720 > test-results: > > https://hahnjo.gitlab.io/-/lilypond/-/jobs/852618720/artifacts/test-results/index.html > > This first workable implementation contains the minimum functionality: > It runs 'make test-baseline' for every push to the master branch and > replaces 'make test' in the pipelines for MRs with 'make check'. The > test-results are uploaded as artifacts and can be either downloaded as > zip archive or viewed directly (see above). > > There are a few known issues that I'm aware of: > - I needed to delete input/regression/option-help.ly because it logs > the options currently in use by lilypond, including the job-count which > varies when using our own runners with more than one core. > we could overwrite the job-count option in the option help, as it is irrelevant by the time you get to the file processing. > - Sometimes the test-results contain spurious diffs, for example here: > > https://hahnjo.gitlab.io/-/lilypond/-/jobs/858441670/artifacts/test-results/index.html > I can reproduce this locally with --enable-checking, but haven't > investigated further yet (there were a couple of other problems that I > needed to solve in order to get things working...). If somebody has an > idea for a fix, that would be great but I think these can be safely > ignored for now. > This could happen because of false-positives in the conservative garbage collection. It's not super-likely, but at the same time, it can't be ruled out. Does it always happen with the same files? I have never seen this, and the files are not doing anything out of the ordinary. IIRC, the dead-object detection can't be made to work anyway with GUILE 2.x, so this might be a good moment to scrap it. > There are a few more elaborate things that I'd like to work on in the > future. For example, GitLab can show a list of 'failing' tests which > can tell us at first glance if we need to look into the test-results. > I've prototyped this integration in the second MR, but it's very > misleading because the file extensions are missing and GitLab prints "0 > failed out of null" when there are no tests. The obvious solution is to > mark all existing tests as success, but this requires a bit more > thought to integrate into output-distance.py (or somewhere else). > I was going to suggest to use junit XML files, but it looks you already found this. Fantastic! > Despite these shortcomings, I think it would make sense to enable this > first implementation in lilypond/lilypond. What do you think? > yes, +1 . I am especially happy that this will likely have no extra overhead. -- Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
