Re: Use vectors rather than lists for skylines. (issue 583750043 by hanw...@gmail.com)
On 2020/04/22 07:43:17, hanwenn wrote: > Finally, to Dan's point: I haven't looked at heap profiling. ... > For now, I don't intend to try this out I was asking for David's benefit. Personally, this change doesn't concern me. In my professional work, we usually avoid lists for some of the reasons you mentioned. -- Dan https://codereview.appspot.com/583750043/
Re: Doc: Minor typo (missing dash) in MusicXML2ly usage (issue 551800043 by michael.kaepp...@googlemail.com)
On 2020/04/21 16:24:47, michael.kaeppler wrote: > Hope this is the right way to submit translation fixes. Any advice is > appreciated. I think goin' through Rietveld is overkill in this case. You'd better send a git formatted patch to lilypond-devel or translation mailing lists. Patch should be applied to the translation branch. Have you ever considered updating some manual? http://lilypond.org/doc/v2.21/Documentation/contributor/translating-the-documentation https://codereview.appspot.com/551800043/
Re: Make dblatex an optional dependency (issue 567480043 by jonas.hahnf...@gmail.com)
LGTM https://codereview.appspot.com/567480043/
Make dblatex an optional dependency (issue 567480043 by jonas.hahnf...@gmail.com)
Reviewers: , Message: For some context: I played with the Docker containers shared by Han-Wen. The one based on Ubuntu 16.04 (Xenial) is 974MB in size. Removing things like git, nano, gdb and additional fonts (when purely interested in automated building) gets me down to 809MB. Of the remaining, dblatex seems to be one of the larger dependencies because it pulls in much of TeXlive. After removing the image only weighs 667MB. Given that it is used only for compiling a single test produced by lilypond-book (nothing that ever shows up in the uploaded documentation), I would also be happy to drop the dependency entirely. The lost coverage amounts to not checking that the produced .xml file can be processed by dblatex... Description: Make dblatex an optional dependency Commit cfa910f1c1 in 2012 made it required unless disabling the doc build. This is an overapproximation since dblatex is only required for compiling the DocBook result of running lilypond-book on the file input/regression/lilypond-book/suffix-lyxml.lyxml. If unavailable the rules in make/lilypond-book-*.make have checks to only produce the intermediate .xml file, without running dblatex to produce a .pdf. Please review this at https://codereview.appspot.com/567480043/ Affected files (+1, -1 lines): M configure.ac Index: configure.ac diff --git a/configure.ac b/configure.ac index 05b868afe8fc1eef782b5a827df49965e6b81730..162d7e60904450d22c0ae1aa21fd88603a20a249 100644 --- a/configure.ac +++ b/configure.ac @@ -372,7 +372,7 @@ fi STEPMAKE_PROGS(MAKEINFO, makeinfo, REQUIRED, 6.1) STEPMAKE_PROGS(TEXI2HTML, texi2html, $DOCUMENTATION_REQUIRED, 1.82, 1.82) -STEPMAKE_PROGS(DBLATEX, dblatex, $DOCUMENTATION_REQUIRED, 0.1.4) +STEPMAKE_PROGS(DBLATEX, dblatex, OPTIONAL, 0.1.4) STEPMAKE_PROGS(BIBTEX, bibtex, $DOCUMENTATION_REQUIRED) STEPMAKE_PROGS(PDFLATEX, xelatex pdflatex, $DOCUMENTATION_REQUIRED) if test "$PDFLATEX" = "xelatex"; then
stepmake: Remove defunct test template (issue 565960043 by jonas.hahnf...@gmail.com)
LGTM https://codereview.appspot.com/565960043/
[trial] getting started
here we go: https://gitlab.com/lilypond-issues/lilypond-trial To reiterate: This is _NOT_ meant for "production" work, just for evaluation. If we decide to fully use GitLab, I'll do a fresh migration into the https://gitlab.com/lilypond group and archive the test repositories. So feel free to play with it! The migration has the current issues as of yesterday 20:43 CEST. As far as I can tell, links between the issues work and I manually corrected the handful with cyclic references. Please check if you find something that's still broken. To get started, either send me your username on gitlab.com (preferably in a private response to avoid spamming the list) or just click 'Request Access' in your browser. A few random notes: - Setting your 'Notification setting' to 'Watch' will get you 'notifications for any activity' - The drop-downs from SF are implemented in terms of scoped issues. That's actually a feature from Premium, but available for all public repositories on gitlab.com. For an example see my first dummy MR - setting a new label will automatically remove the old one as you would expect. That's all for now - let's have some fun! Jonas signature.asc Description: This is a digitally signed message part
Re: poll: switching our development platform
Am Mittwoch, den 22.04.2020, 10:31 +0100 schrieb James Lowe: > On 21/04/2020 18:54, Jonas Hahnfeld wrote: > > Am Mittwoch, den 15.04.2020, 21:15 +0200 schrieb Jonas Hahnfeld: > > > With 2.21.0 done, I'd like to restart discussion about switching our > > > development platform. To recall, we had proposals about using Gerrit > > > [1] (don't miss follow-ups in March [2]) and GitLab / gitlab.com [3]. > > > > > > [...] > > > > > > To conclude, I believe we should choose one of Gerrit and GitLab and > > > have a trial to see if the processes can be carried over. (If not, we > > > can still give the other platform a try.) > > > I'd propose we kind of vote, so please reply with your thoughts. > > > > Okay, so let me try to briefly summarize the expressed opinions on the > > list so far (correct me if I got something wrong or missed a point): > > Han-Wen is in favor of Gerrit; David leans towards GitLab; Federico and > > me are in favor of GitLab; Werner is fine with both solutions. > > David, Dan, and Federico comment that Gerrit would still leaves us with > > SF for hosting the issues; James says that image attachments (without > > sharing links) are a good thing to have - as far as I understand for > > both bug reports and reviews. > > > > Given that I would like to propose that we carry a trial of gitlab.com. > > I would have liked this to happen in the > > https://gitlab.com/lilypond > > > > group, but I haven't heard back from Janek on granting access. So I guess I > > will prune the previous test migration and dump the current set of issues > > to also make sure that we're satisfied with the migration script. I'll > > announce once ready and whoever wants to participate can send me the > > username on gitlab.com to add to the project. > > > > Jonas > > Let me know how this will affect my work with patch countdown and/or if > there is anything you'd like me to start doing / checking to help speed > this up. In my opinion we shouldn't use real patches in the trial (or if we do, also submit them "the old way"). Still it would be a great help if you participated in the trial to make sure the process carries over. I've run the migration script last night (~9h) and will now do some post-processing. I'll keep all of you posted once we can start. Jonas signature.asc Description: This is a digitally signed message part
Re: Frescobaldi distribution packages
Ubuntu 20.04 will come with LilyPond 2.20. Older releases are usually not updated after the release and will keep 2.18. Ubuntu 2.20 will probably be released tomorrow. https://packages.ubuntu.com/focal/lilypond Frescobaldi will be 3.0.0 and not the latest 3.1.2: https://packages.ubuntu.com/focal/frescobaldi Cheers, Joram
Re: poll: switching our development platform
On 21/04/2020 18:54, Jonas Hahnfeld wrote: Am Mittwoch, den 15.04.2020, 21:15 +0200 schrieb Jonas Hahnfeld: With 2.21.0 done, I'd like to restart discussion about switching our development platform. To recall, we had proposals about using Gerrit [1] (don't miss follow-ups in March [2]) and GitLab / gitlab.com [3]. [...] To conclude, I believe we should choose one of Gerrit and GitLab and have a trial to see if the processes can be carried over. (If not, we can still give the other platform a try.) I'd propose we kind of vote, so please reply with your thoughts. Okay, so let me try to briefly summarize the expressed opinions on the list so far (correct me if I got something wrong or missed a point): Han-Wen is in favor of Gerrit; David leans towards GitLab; Federico and me are in favor of GitLab; Werner is fine with both solutions. David, Dan, and Federico comment that Gerrit would still leaves us with SF for hosting the issues; James says that image attachments (without sharing links) are a good thing to have - as far as I understand for both bug reports and reviews. Given that I would like to propose that we carry a trial of gitlab.com. I would have liked this to happen in the https://gitlab.com/lilypond group, but I haven't heard back from Janek on granting access. So I guess I will prune the previous test migration and dump the current set of issues to also make sure that we're satisfied with the migration script. I'll announce once ready and whoever wants to participate can send me the username on gitlab.com to add to the project. Jonas Let me know how this will affect my work with patch countdown and/or if there is anything you'd like me to start doing / checking to help speed this up. Regards James
Re: Frescobaldi distribution packages
Hello On 22/04/2020 06:22, Andrew Bernard wrote: Am I right in supposing that 2.20.0 is the now stable version? I notice that, for example, installing Frescobaldi on OpenSuse Leap 15 installs 2.18.2 together with it. Should these system packages now use 2.20.0 instead? That would be a good way to get people off the old versions, for those newly setting up. How does lilypond get into distribution repositories anyway? Is there any thing I can do to help in this regard? It's not a big deal as it is trivial to install 2.20.0 and get Frescobaldi to use that. But it seems to more 2.18.2 is, in a way, deprecated, or at least not one's first choice now. While I cannot speak for Frescobaldi, a general problem of LilyPond has been that the Guile (version 1.8) that was required for 2.18 (and pretty much all of 2.19 if not still 2.20) was finally deprecated such that most distributions had to remove LP because of that - at least that was how I, as a non-developer, understood it. This meant that LP had to be removed or packaged with its own version of Guile which was a problem for maintainers generally. I am not sure what the current state of Guile packaging/support is with LP 2.20 and the various distributions and I am sure that others who know more can chime on or correct me if I was wrong. But I think that was the gist of it right? James
Re: Use binary search in Axis_group_interface::combine_pure_heights. (issue 573730043 by hanw...@gmail.com)
On 2020/04/21 09:15:28, hahnjo wrote: > LGTM otherwise > > https://codereview.appspot.com/573730043/diff/567470043/lily/axis-group-interface.cc > File lily/axis-group-interface.cc (right): > > https://codereview.appspot.com/573730043/diff/567470043/lily/axis-group-interface.cc#newcode206 > lily/axis-group-interface.cc:206: auto it = lower_bound (break_ranks.begin (), > break_ranks.end (), start); > Could you add a comment that break_ranks is sorted by construction in > Paper_score::find_break_indices() -- if that is true: I had a quick look at the > code and this seems the most likely explanation why a binary search is legit. > But please double check and let me know if that guess is correct. added a comment to paper-score.hh https://codereview.appspot.com/573730043/
Re: Use binary search in Axis_group_interface::combine_pure_heights. (issue 573730043 by hanw...@gmail.com)
https://codereview.appspot.com/573730043/
Re: Use binary search in Axis_group_interface::combine_pure_heights. (issue 573730043 by hanw...@gmail.com)
https://codereview.appspot.com/573730043/
Re: Use vectors rather than lists for skylines. (issue 583750043 by hanw...@gmail.com)
current master: 4f906b95aea99f2a47d5ba037f7421e5bb933c42 (origin/master) Issue 5908: get_path_list: use loop instead of tail recursion Command being timed: "out/bin/lilypond.4f906b95ae -I carver MSDM" User time (seconds): 34.30 Maximum resident set size (kbytes): 1139208 this patch: 889131d584f77f44acc8d801ce254d7d2ba85aa4 (HEAD, vector-skyline) Use vectors rather than lists for skylines. Command being timed: "out/bin/lilypond.889131d584 -I carver MSDM" User time (seconds): 31.66 Maximum resident set size (kbytes): 1054432 I disagree David's assessment on several theoretical grounds too: * "less maintainable manner with hand-written optimisations". I don't see these in this patch. This (together with the Tie_performer) is the only place in LilyPond that uses lists. We could get rid of std::list on maintenance grounds alone. * The linked list has an overhead of 2 pointers, on a 4x Real datastructure, ie. 50% overhead. The vector has (assuming a 2x growth strategy) 100% overhead. There is a little more overhead, but we could tune that by adjustin the vector growth strategy. With a linked list, there is no choice in space/time tradeoff. * The linked list approach is much worse for fragmentation. It has to allocate a ton on 48-byte objects, some of which have long lifetime. This will create a highly fragmented pool of 48-byte objects. We don't have use for so many of these objects elsewhere. By contrast, the vector approach will create a distribution of differently sized objects, which can be recycled into other vectors. * Linked lists provide O(1) random insertion, but this is exactly the algorithmic property we don't need at all in this problem. By contrast, the buildings are sorted, and if we store them in an array, we can use binary search for efficient searching. For example, we generate glyph outlines for each character in every text in the score. With binary search, we can quickly check if the bbox of the char is within the outline, and avoid doing the work to generate and merge the outline. This likely cuts the amount of merges by a factor 2: the bottom half of a text above the staff is obscured by the bottom of the staff, so it doesn't need to be processed at all. Finally, to Dan's point: I haven't looked at heap profiling. The google heap-profiler is available at https://gperftools.github.io/gperftools/heapprofile.html, and I would be happy to comment on heap profiles that anyone wishes to collect. My educated guess is that the skyline code, with or without this patch, will figure highly in the stats, simply because we compute skylines in so much detail. For now, I don't intend to try this out: the skylines are such an obvious time sink that that is the area to optimize. This is reinforced by my other patch for skylines (https://codereview.appspot.com/547980044/). On Wed, Apr 22, 2020 at 1:39 AM wrote: > > I am rather skeptical about the usefulness of such microoptimizations > without influence on algorithmic complexity. In return for better > memory locality you buy into quite larger memory fragmentation, and we > have scores of comparatively modest size already exhausting memory. All > that exhausted memory needs to get filled and processed, so it would > rather seem like the true savings are not to be found in doing the same > kind of work in a slightly faster but less maintainable manner with > hand-written optimisations, but rather in figuring out why too much work > is being done in the first place. > > The more one replaces standard tools and operations, the harder it > becomes to figure out what kind of stuff actually goes wrong and fix it, > or change the strategies and algorithms wholesale. > > https://codereview.appspot.com/583750043/ -- Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
Re: Frescobaldi distribution packages
Il giorno mer 22 apr 2020 alle 15:22, Andrew Bernard ha scritto: How does lilypond get into distribution repositories anyway? Is there any thing I can do to help in this regard? You may ask the distro maintainer to upgrade the package. In Fedora, lilypond 2.20 is currently available in rawhide (33), but I guess it will be available soon in 32 as soon as it passes from beta to stable. Same for Debian, I see 2.20 in testing: https://packages.debian.org/search?keywords=lilypond
