Re: anyone notice speed of 2.17.95 on Windows ?
On Mon, 25 Nov 2013 00:10:08 -0800, David Kastrup d...@gnu.org wrote: Keith OHara k-ohara5...@oco.net writes: I timed one big score, Movement 1 of http://www.mutopiaproject.org/cgibin/piece-info.cgi?id=1793 2.16.2 2.17.95 WinXP 2m 30s 5m 10s Fedora 1m 50s 1m 50s Have you used the GUB-compiled binary package, or Fedora's built-in or a self-compiled package? I think that you probably can only make platform-specific comparisons if you use GUB for all. GUB-compiled packages in all cases give the same results as above. Most of the increase in time to set this score happened between 2.17.0 and .1 2.16.2 2m 30s 2.17.0 2m 28s 2.17.1 4m 06s so it is probably the issue 2148 patch, use of outlines instead of boxes for layout. I did speed-test that patch, but under Linux. Maybe the system calls to the font server, to get outlines for the glyphs, take longer under Windows. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: anyone notice speed of 2.17.95 on Windows ?
On Dec 10, 2013, at 10:36 AM, Keith OHara k-ohara5...@oco.net wrote: On Mon, 25 Nov 2013 00:10:08 -0800, David Kastrup d...@gnu.org wrote: Keith OHara k-ohara5...@oco.net writes: I timed one big score, Movement 1 of http://www.mutopiaproject.org/cgibin/piece-info.cgi?id=1793 2.16.2 2.17.95 WinXP 2m 30s 5m 10s Fedora 1m 50s 1m 50s Have you used the GUB-compiled binary package, or Fedora's built-in or a self-compiled package? I think that you probably can only make platform-specific comparisons if you use GUB for all. GUB-compiled packages in all cases give the same results as above. Most of the increase in time to set this score happened between 2.17.0 and .1 2.16.2 2m 30s 2.17.0 2m 28s 2.17.1 4m 06s so it is probably the issue 2148 patch, use of outlines instead of boxes for layout. I did speed-test that patch, but under Linux. Maybe the system calls to the font server, to get outlines for the glyphs, take longer under Windows. One easy way to avoid this is to turn off this feature with vertical-skylines = ##f for lots of grobs - I do this often for big scores when I want to compile them fast, but I reactivate the more accurate vertical skylines for the final version. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: anyone notice speed of 2.17.95 on Windows ?
Keith OHara wrote Tuesday, December 10, 2013 8:36 AM Most of the increase in time to set this score happened between 2.17.0 and .1 2.16.2 2m 30s 2.17.0 2m 28s 2.17.1 4m 06s so it is probably the issue 2148 patch, use of outlines instead of boxes for layout. I did speed-test that patch, but under Linux. Maybe the system calls to the font server, to get outlines for the glyphs, take longer under Windows. Could be. I've noticed that changing fonts under pure Windows programs like Excel takes a surprisingly long time. That's under Vista Home Premium. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: anyone notice speed of 2.17.95 on Windows ?
Mike Solomon m...@mikesolomon.org writes: On Dec 10, 2013, at 10:36 AM, Keith OHara k-ohara5...@oco.net wrote: On Mon, 25 Nov 2013 00:10:08 -0800, David Kastrup d...@gnu.org wrote: Keith OHara k-ohara5...@oco.net writes: I timed one big score, Movement 1 of http://www.mutopiaproject.org/cgibin/piece-info.cgi?id=1793 2.16.2 2.17.95 WinXP 2m 30s 5m 10s Fedora 1m 50s 1m 50s Have you used the GUB-compiled binary package, or Fedora's built-in or a self-compiled package? I think that you probably can only make platform-specific comparisons if you use GUB for all. GUB-compiled packages in all cases give the same results as above. Most of the increase in time to set this score happened between 2.17.0 and .1 2.16.2 2m 30s 2.17.0 2m 28s 2.17.1 4m 06s so it is probably the issue 2148 patch, use of outlines instead of boxes for layout. I did speed-test that patch, but under Linux. Maybe the system calls to the font server, to get outlines for the glyphs, take longer under Windows. One easy way to avoid this is to turn off this feature with vertical-skylines = ##f for lots of grobs - I do this often for big scores when I want to compile them fast, but I reactivate the more accurate vertical skylines for the final version. Sigh. It's stuff like that which really makes me pessimistic about the prospects of LilyPond as serious software. If its developers consider it unusable for serious work out of the box without making use of their personal, secret bag of tricks, how are we supposed to tell people with a straight face that this software is useful other than as either a toy or a tinker box? -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: anyone notice speed of 2.17.95 on Windows ?
On Dec 10, 2013, at 11:27 AM, David Kastrup d...@gnu.org wrote: Mike Solomon m...@mikesolomon.org writes: On Dec 10, 2013, at 10:36 AM, Keith OHara k-ohara5...@oco.net wrote: On Mon, 25 Nov 2013 00:10:08 -0800, David Kastrup d...@gnu.org wrote: Keith OHara k-ohara5...@oco.net writes: I timed one big score, Movement 1 of http://www.mutopiaproject.org/cgibin/piece-info.cgi?id=1793 2.16.2 2.17.95 WinXP 2m 30s 5m 10s Fedora 1m 50s 1m 50s Have you used the GUB-compiled binary package, or Fedora's built-in or a self-compiled package? I think that you probably can only make platform-specific comparisons if you use GUB for all. GUB-compiled packages in all cases give the same results as above. Most of the increase in time to set this score happened between 2.17.0 and .1 2.16.2 2m 30s 2.17.0 2m 28s 2.17.1 4m 06s so it is probably the issue 2148 patch, use of outlines instead of boxes for layout. I did speed-test that patch, but under Linux. Maybe the system calls to the font server, to get outlines for the glyphs, take longer under Windows. One easy way to avoid this is to turn off this feature with vertical-skylines = ##f for lots of grobs - I do this often for big scores when I want to compile them fast, but I reactivate the more accurate vertical skylines for the final version. Sigh. It's stuff like that which really makes me pessimistic about the prospects of LilyPond as serious software. If its developers consider it unusable for serious work out of the box It’s the opposite - I use the out of the box settings for serious work - it’s the unserious playing around that I try to speed up. I’ve said on several occasions that I’m indifferent deactivating some or all of vertical skylines as a default. Several people are against this deactivation (notable Janek). I’d be interested in gradations of UI options called perhaps: \faster-but-uglier \a-lot-faster-but-a-lot-uglier \ridiculously-fast-and-heinously-ugly that people can invoke at the top level to speed things up but get uglier results. This is trivial to implement, but I’d be interested to hear what UI-savvy people think. Cheers, MS___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: anyone notice speed of 2.17.95 on Windows ?
\faster-but-uglier \a-lot-faster-but-a-lot-uglier \ridiculously-fast-and-heinously-ugly :-) With some serious names, this could be quite useful. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: anyone notice speed of 2.17.95 on Windows ?
Mike Solomon m...@mikesolomon.org writes: On Dec 10, 2013, at 11:27 AM, David Kastrup d...@gnu.org wrote: Mike Solomon m...@mikesolomon.org writes: On Dec 10, 2013, at 10:36 AM, Keith OHara k-ohara5...@oco.net wrote: I did speed-test that patch, but under Linux. Maybe the system calls to the font server, to get outlines for the glyphs, take longer under Windows. One easy way to avoid this is to turn off this feature with vertical-skylines = ##f for lots of grobs - I do this often for big scores when I want to compile them fast, but I reactivate the more accurate vertical skylines for the final version. Sigh. It's stuff like that which really makes me pessimistic about the prospects of LilyPond as serious software. If its developers consider it unusable for serious work out of the box It’s the opposite - I use the out of the box settings for serious work - it’s the unserious playing around that I try to speed up. How is unserious playing around not part of a serious creative work flow? I’ve said on several occasions that I’m indifferent deactivating some or all of vertical skylines as a default. Several people are against this deactivation (notable Janek). If we have more than a factor of 2 in timing involved between Linux and Windows, then we do too much repeated processing in the font server. I’d be interested in gradations of UI options called perhaps: \faster-but-uglier \a-lot-faster-but-a-lot-uglier \ridiculously-fast-and-heinously-ugly Nope. In this case, the answer is to cache frequently accessed information instead of requesting it again and again. We don't want to give people a choice between different ways in which LilyPond will be bad. We just don't want LilyPond to be bad. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: anyone notice speed of 2.17.95 on Windows ?
- Original Message - From: Werner LEMBERG w...@gnu.org To: m...@mikesolomon.org Cc: k-ohara5...@oco.net; d...@gnu.org; lilypond-devel@gnu.org Sent: Tuesday, December 10, 2013 9:43 AM Subject: Re: anyone notice speed of 2.17.95 on Windows ? \faster-but-uglier \a-lot-faster-but-a-lot-uglier \ridiculously-fast-and-heinously-ugly :-) With some serious names, this could be quite useful. TBH I potentially wouldn't use them. When I benchmarked with and without skylines, I found there was only a noticeable difference with a lot of markup or similar: normal music had almost no effect. As a result, I concluded with skylining was the correct default. However, an option similar to \pointAndClickOff would be simple and could be handy: it could include a number of sensible attempted speed ups. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: anyone notice speed of 2.17.95 on Windows ?
On Dec 10, 2013, at 11:47 AM, David Kastrup d...@gnu.org wrote: Mike Solomon m...@mikesolomon.org writes: On Dec 10, 2013, at 11:27 AM, David Kastrup d...@gnu.org wrote: Mike Solomon m...@mikesolomon.org writes: On Dec 10, 2013, at 10:36 AM, Keith OHara k-ohara5...@oco.net wrote: I did speed-test that patch, but under Linux. Maybe the system calls to the font server, to get outlines for the glyphs, take longer under Windows. One easy way to avoid this is to turn off this feature with vertical-skylines = ##f for lots of grobs - I do this often for big scores when I want to compile them fast, but I reactivate the more accurate vertical skylines for the final version. Sigh. It's stuff like that which really makes me pessimistic about the prospects of LilyPond as serious software. If its developers consider it unusable for serious work out of the box It’s the opposite - I use the out of the box settings for serious work - it’s the unserious playing around that I try to speed up. How is unserious playing around not part of a serious creative work flow? It is - I misunderstood what you said. For years, starting with Graham Percival, we’ve been kicking the around the idea of invoking LilyPond at various speed/beauty tradeoffs. I am for this, but to date there have been no propositions that gel with the entire community. I have suggested turning off all my sideline work as a default, but people feel this would not be the best option, so for now, we have it all, which is also not the best option. I stand by Graham’s idea. I’ve said on several occasions that I’m indifferent deactivating some or all of vertical skylines as a default. Several people are against this deactivation (notable Janek). If we have more than a factor of 2 in timing involved between Linux and Windows, then we do too much repeated processing in the font server. I’d be interested in gradations of UI options called perhaps: \faster-but-uglier \a-lot-faster-but-a-lot-uglier \ridiculously-fast-and-heinously-ugly Nope. In this case, the answer is to cache frequently accessed information instead of requesting it again and again. We don't want to give people a choice between different ways in which LilyPond will be bad. We just don't want LilyPond to be bad. In my initial patches, which involved caching everything, there was no appreciable speed-up on Mac and Linux. I did not test it on Windows, but I don’t remember Windows users (Janek) reporting back problems). I would be interested to do rigorous testing on Windows. It is not hard to do - it requires creating a Scheme hash linking glyph names to skylines. I still advocate allowing users to specify a speed/beauty tradeoff, which can be done in concert with optimization to LilyPond’s core. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: anyone notice speed of 2.17.95 on Windows ?
Mike Solomon m...@mikesolomon.org writes: On Dec 10, 2013, at 11:47 AM, David Kastrup d...@gnu.org wrote: Nope. In this case, the answer is to cache frequently accessed information instead of requesting it again and again. We don't want to give people a choice between different ways in which LilyPond will be bad. We just don't want LilyPond to be bad. In my initial patches, which involved caching everything, there was no appreciable speed-up on Mac and Linux. Maybe caching in unsuitable form? Cached data should be in a form directly usable for processing (with some possible tradeoffs between memory impact and unpacking speed), not in the form that function/library/system calls will return it. I did not test it on Windows, but I don’t remember Windows users (Janek) reporting back problems). Well, sounds like hen-and-egg here: we need more serious users to give more definite feedback, so that we can make LilyPond more suitable for more serious users. I would be interested to do rigorous testing on Windows. It is not hard to do - it requires creating a Scheme hash linking glyph names to skylines. I still advocate allowing users to specify a speed/beauty tradeoff, which can be done in concert with optimization to LilyPond’s core. That makes only sense where there is an incurable reason for a large tradeoff. in concert with optimization to LilyPond's core is, in my experience, a buzzphrase. In particular the word optimization tends to be construed as somewhat tune an unsuitable algorithm, making it inscrutable in the process. I know that this use of optimization is widespread, but I have a thorough dislike for it. Almost any task can be algorithmically cast into the n lg (n) category which, with modern processors, is usually doable without having to think about tradeoffs. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: anyone notice speed of 2.17.95 on Windows ?
On Dec 10, 2013, at 12:18 PM, David Kastrup d...@gnu.org wrote: Mike Solomon m...@mikesolomon.org writes: On Dec 10, 2013, at 11:47 AM, David Kastrup d...@gnu.org wrote: Nope. In this case, the answer is to cache frequently accessed information instead of requesting it again and again. We don't want to give people a choice between different ways in which LilyPond will be bad. We just don't want LilyPond to be bad. In my initial patches, which involved caching everything, there was no appreciable speed-up on Mac and Linux. Maybe caching in unsuitable form? Cached data should be in a form directly usable for processing (with some possible tradeoffs between memory impact and unpacking speed), not in the form that function/library/system calls will return it. I had cached skylines, although it’s true that it is possible to cache results to function calls (i.e. calls to Skyline::distance for the exact same two skylines). Or there may be a better way to cache the skylines. But LilyPond takes a looot of time in Skyline distance calculations. I did not test it on Windows, but I don’t remember Windows users (Janek) reporting back problems). Well, sounds like hen-and-egg here: we need more serious users to give more definite feedback, so that we can make LilyPond more suitable for more serious users. I would be interested to do rigorous testing on Windows. It is not hard to do - it requires creating a Scheme hash linking glyph names to skylines. I still advocate allowing users to specify a speed/beauty tradeoff, which can be done in concert with optimization to LilyPond’s core. That makes only sense where there is an incurable reason for a large tradeoff. in concert with optimization to LilyPond's core is, in my experience, a buzzphrase. In particular the word optimization tends to be construed as somewhat tune an unsuitable algorithm, making it inscrutable in the process. I know that this use of optimization is widespread, but I have a thorough dislike for it. Almost any task can be algorithmically cast into the n lg (n) category which, with modern processors, is usually doable without having to think about tradeoffs. I agree that the main goal should be speeding up the algorithm while maintaining, if not augmenting, its understandability. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
PATCHES: Countdown – December 13th – 06:00 GMT
hello *Countdown – December 13th – 06:00 GMT* * * * * * * * * * * 3679 http://code.google.com/p/lilypond/issues/detail?id=3679q=label%3APatch-countdown%20OR%20label%3APatch-waiting%20OR%20label%3APatch-review%20OR%20label%3APatch-new%20OR%20label%3APatch-pushsort=patchcolspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary%20Modified Enhancement David Kastrup push Patch: Rewrite the autobeam logic to use GUILE fractions rather than moments 3712 http://code.google.com/p/lilypond/issues/detail?id=3712q=label%3APatch-countdown%20OR%20label%3APatch-waiting%20OR%20label%3APatch-review%20OR%20label%3APatch-new%20OR%20label%3APatch-pushsort=patchcolspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary%20Modified Enhancement David Kastrup countdown Patch: Ponding about Turkish Ebook by Server Acim 3710 http://code.google.com/p/lilypond/issues/detail?id=3710q=label%3APatch-countdown%20OR%20label%3APatch-waiting%20OR%20label%3APatch-review%20OR%20label%3APatch-new%20OR%20label%3APatch-pushsort=patchcolspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary%20Modified Documentation Keith Ohara countdown NR 4.4.1 collisions 3708 http://code.google.com/p/lilypond/issues/detail?id=3708q=label%3APatch-countdown%20OR%20label%3APatch-waiting%20OR%20label%3APatch-review%20OR%20label%3APatch-new%20OR%20label%3APatch-pushsort=patchcolspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary%20Modified Enhancement David Kastrup countdown Patch: Change the default ANTI_ALIAS_FACTOR for documentation builds to 1 3707 http://code.google.com/p/lilypond/issues/detail?id=3707q=label%3APatch-countdown%20OR%20label%3APatch-waiting%20OR%20label%3APatch-review%20OR%20label%3APatch-new%20OR%20label%3APatch-pushsort=patchcolspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary%20Modified Enhancement Janek Warchol countdown Patch: font: rewrite accidental code (sharp and natural) 3697 http://code.google.com/p/lilypond/issues/detail?id=3697q=label%3APatch-countdown%20OR%20label%3APatch-waiting%20OR%20label%3APatch-review%20OR%20label%3APatch-new%20OR%20label%3APatch-pushsort=patchcolspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary%20Modified Ugly Keith Ohara countdown markup \super and \sub do not use the local fontsize 3674 http://code.google.com/p/lilypond/issues/detail?id=3674q=label%3APatch-countdown%20OR%20label%3APatch-waiting%20OR%20label%3APatch-review%20OR%20label%3APatch-new%20OR%20label%3APatch-pushsort=patchcolspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary%20Modified Build David Kastrup countdown Multiprocessor builds fail on some platforms 3664 http://code.google.com/p/lilypond/issues/detail?id=3664q=label%3APatch-countdown%20OR%20label%3APatch-waiting%20OR%20label%3APatch-review%20OR%20label%3APatch-new%20OR%20label%3APatch-pushsort=patchcolspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary%20Modified Enhancement Devon Schudy countdown Patch: Support articulations, slurs and breaths in MIDI. Fixed_2_19_0 3628 http://code.google.com/p/lilypond/issues/detail?id=3628q=label%3APatch-countdown%20OR%20label%3APatch-waiting%20OR%20label%3APatch-review%20OR%20label%3APatch-new%20OR%20label%3APatch-pushsort=patchcolspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary%20Modified Ugly Keith Ohara countdown Patch: Make sure slurs actually avoid stafflines. 3713 http://code.google.com/p/lilypond/issues/detail?id=3713q=label%3APatch-countdown%20OR%20label%3APatch-waiting%20OR%20label%3APatch-review%20OR%20label%3APatch-new%20OR%20label%3APatch-pushsort=patchcolspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary%20Modified Defect David Kastrup review default for baseline-skip not available while calling column-markup-command in the lists for repeatCommands 3705 http://code.google.com/p/lilypond/issues/detail?id=3705q=label%3APatch-countdown%20OR%20label%3APatch-waiting%20OR%20label%3APatch-review%20OR%20label%3APatch-new%20OR%20label%3APatch-pushsort=patchcolspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary%20Modified Enhancement Janek Warchol review Patch: Metafont code cleanup 3239 http://code.google.com/p/lilypond/issues/detail?id=3239q=label%3APatch-countdown%20OR%20label%3APatch-waiting%20OR%20label%3APatch-review%20OR%20label%3APatch-new%20OR%20label%3APatch-pushsort=patchcolspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary%20Modified Enhancement Janek Warchol waiting Patch: rewrite Self_alignment_interface May 2013 3186
Use standard inclusion scheme for FreeType headers. (issue 35580043)
https://codereview.appspot.com/35580043/diff/1/lily/open-type-font.cc File lily/open-type-font.cc (right): https://codereview.appspot.com/35580043/diff/1/lily/open-type-font.cc#newcode26 lily/open-type-font.cc:26: #include FT_TRUETYPE_TABLES_H This is inscrutable programming. It relies on open-type-font.hh including font-metric.hh which in turn includes freetype.hh which happens to include the library header ft2build.h defining macros like FT_TRUETYPE_TABLES_H. Please, if you use identifiers defined in a particular header file, include that particular header file instead of assuming that if it magically seems to be defined for some reason, everything will turn out fine. The compile time difference is minuscule if a header file turns out to get included more than once. https://codereview.appspot.com/35580043/diff/1/lily/pango-font.cc File lily/pango-font.cc (right): https://codereview.appspot.com/35580043/diff/1/lily/pango-font.cc#newcode25 lily/pango-font.cc:25: #include FT_XFREE86_H This is even more reckless programming. It relies on pango/pangoft2.h including the particular header file from freetype that defines FT_XFREE86_H. This issue is called Use standard inclusion scheme for FreeType headers, and the standard inclusion scheme will most definitely not state that Freetype headers will be incidentally defined by loading some pango library. That's not just inscrutable, it is completely out of our control. https://codereview.appspot.com/35580043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
branching
Hey all, As 2.18 draws near, I’d like to work with everyone to establish a system of branching for LilyPond development. After several rounds of discussing things with David K, this emerged as the best way to avoid arguments about integrating work into the development branch that have led several contributors, including myself, to significantly reduce time on the project. [1] I feel that this reduction in commit diversity is the biggest obstacle to LilyPond’s future evolution, which is why I’m calling on everyone to make a concerted effort to think this through. There seem to me to be two main issues to sort out in doing this: ** how to get developers into the habit of working on separate git branches ** how to get users using these branches I have opinions about both, which I will state below. After some go around, I’d like to see something written up as a community-endorsed proposal that would then be implemented by myself and whoever else wants to help me out. ** how to get developers into the habit of creating separate git branches Several developers would create development branches, i.e. devel-dk, etc.. These branches have no theme other than their being the principal sandbox of a particular developer or group of developers. There would also be a devel-jd for John Doe, meaning anyone who does not have their own branch. All of these branches would track staging. We would limit the number of these branches to around 5. Work on staging would then consist _only_ in merging these branches (or cherry picking commits from them) to staging. These merges would be regular, part of the countdown cycle and discussable. Patch review would exist just as now, except that “push” means that things get pushed to one of these branches instead of to staging. Developers who don’t know how to use git’s branch features would be given help by those who know how. ** how to get users using these branches On the website, we would offer _all_ of these development branches, including the one built off of staging, as GUB builds. We would also contain a tracker showing number of downloads and encouraging users to download the branches that have been downloaded the _least_. This would allow us to ensure that all branches are being tried out. On the website, developers could also request that certain users use certain branches. For example, if I were doing a lot of lyric work, I would ask on the website for people frequently using lyrics to use my branch. I’m looking forward to hearing everyone’s ideas on this. Cheers, MS [1] Development branches should not be construed as a substitute for collegial communication in our community, irrespective of the degree of difference between any of its members. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: branching
On Tue, Dec 10, 2013 at 02:42:45PM +0200, Mike Solomon wrote: On the website, we would offer _all_ of these development branches, including the one built off of staging, as GUB builds. A few years ago, we were asked to cut our downloads down to 5 GB. I deleted a bunch of devel stuff and got it down to 7 or 8, but we're probably back to 15 GB now. I don't think we should fill up the server with that many builds, nor do I think we should ask James to do all that building. We would also contain a tracker showing number of downloads and encouraging users to download the branches that have been downloaded the _least_. I don't like the idea of treating users as guinea pigs. If somebody wants to test out devel stuff, it's not unreasonable for them to compile it themselves (inside lilydev if necessary). - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: branching
On Dec 10, 2013, at 2:58 PM, Graham Percival gra...@percival-music.ca wrote: On Tue, Dec 10, 2013 at 02:42:45PM +0200, Mike Solomon wrote: On the website, we would offer _all_ of these development branches, including the one built off of staging, as GUB builds. A few years ago, we were asked to cut our downloads down to 5 GB. I deleted a bunch of devel stuff and got it down to 7 or 8, but we're probably back to 15 GB now. I don't think we should fill up the server with that many builds, nor do I think we should ask James to do all that building. I agree about the not asking James part - this should be split up (different gubs making different builds). As for the filling the server part, this seems like something that can be solved with alternate hosting sites for the download links. We would also contain a tracker showing number of downloads and encouraging users to download the branches that have been downloaded the _least_. I don't like the idea of treating users as guinea pigs. If somebody wants to test out devel stuff, it's not unreasonable for them to compile it themselves (inside lilydev if necessary). I don’t either, but I do like the idea of asking them to be guinea pigs. To this end, I’ll send an e-mai to the users list about this. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Metafont code cleanup (issue 38530043)
However, if you don't mind, i'd prefer to leave it as is - i have _already_ spent about 4 hours cleaning up and rebasing commits to make them somewhat ordered for review, and i'm quite tired. I do mind. this is not the sort of thing that can be done in a follow up patch. If you don't want to do that, I can do the only-move-files-in-the-first-commit part, but I can't promise I'll finish before the weekend. p https://codereview.appspot.com/38530043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: branching
Mike Solomon m...@mikesolomon.org writes: Hey all, As 2.18 draws near, I’d like to work with everyone to establish a system of branching for LilyPond development. After several rounds of discussing things with David K, this emerged as the best way to avoid arguments about integrating work into the development branch that have led several contributors, including myself, to significantly reduce time on the project. [1] It will take me considerable time to address this more thoroughly, but in the mean time I want to have on record that what Mike writes here under this emerged as the best way _not_ in _any_ way summarizing our discussion. Instead it is his _personal_ idea how to address topics we covered. Writing something like this emerged as the best way when we did not even talk about it wrongly insinuates that it presents a common understanding of how to address problems covered in the discussion. Feel free to quote passages or complete mails from me in the course of that discussion: there is nothing in there that I would not have equally said in public. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: branching
On Dec 10, 2013, at 4:23 PM, David Kastrup d...@gnu.org wrote: Mike Solomon m...@mikesolomon.org writes: Hey all, As 2.18 draws near, I’d like to work with everyone to establish a system of branching for LilyPond development. After several rounds of discussing things with David K, this emerged as the best way to avoid arguments about integrating work into the development branch that have led several contributors, including myself, to significantly reduce time on the project. [1] It will take me considerable time to address this more thoroughly, but in the mean time I want to have on record that what Mike writes here under this emerged as the best way _not_ in _any_ way summarizing our discussion. Instead it is his _personal_ idea how to address topics we covered. Writing something like this emerged as the best way when we did not even talk about it wrongly insinuates that it presents a common understanding of how to address problems covered in the discussion. Sorry, I in no way mean to apply that this is a proposition on David’s behalf. This is a proposition from me that it is a response to our discussion, not a summary of it. Feel free to quote passages or complete mails from me in the course of that discussion: there is nothing in there that I would not have equally said in public. (quotes from David) The basic idea behind that is not to make confrontations nicer but reduce the necessity for them by establishing playing fields with different authorities. So that people can get work done without endangering the release, and I can get releases done without pissing people off as a prerequisite. We won't be able to completely separate the two, but both our current code base and our current development model are quite bad for getting this under control. … As I said: there are certainly decisions where a vote does make sense: mostly when there is a choice between alternatives. For go ahead or not kind of decisions, the answer should likely be go ahead in a sandbox, and with enough exposure of the sandbox to testers and end users, we'll be better equipped to make an informed decision. That's how it tends to work with the Linux kernel, but both our code base as well as our infrastructure is not really diverse enough to make this easy. It _would_ be easier in a Scheme universe, or with loadable C++ modules. But either case requires that enough of the internals are implemented through exchangeable interfaces that swapping out key parts for user-written code can be done without disrupting too many unrelated parts in the process. … My proposal is a first-pass at starting a dialogue about this that people can respond to - I expect some or all of it to be rejected, but the important thing is to start talking about it now. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: branching
On Tue, Dec 10, 2013 at 04:30:32PM +0200, Mike Solomon wrote: (quotes from David) The basic idea behind that is not to make confrontations nicer but reduce the necessity for them by establishing playing fields with different authorities. So that people can get work done without endangering the release, and I can get releases done without pissing people off as a prerequisite. I agree with this idea, but I feel like I'm missing something. How would regular git branches be insufficient for this? Is it simply the lack of GUB for branches? I mean, is the problem a technical or social one? My gut feeling is that this is a social issue, so any technical wish-lists are a red herring. That said, I admit that I haven't even skimmed the patch countdowns in the past few months, let alone read any arguments on -devel. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: branching
Graham Percival gra...@percival-music.ca writes: On Tue, Dec 10, 2013 at 04:30:32PM +0200, Mike Solomon wrote: (quotes from David) The basic idea behind that is not to make confrontations nicer but reduce the necessity for them by establishing playing fields with different authorities. So that people can get work done without endangering the release, and I can get releases done without pissing people off as a prerequisite. I agree with this idea, but I feel like I'm missing something. How would regular git branches be insufficient for this? Is it simply the lack of GUB for branches? I mean, is the problem a technical or social one? My gut feeling is that this is a social issue, so any technical wish-lists are a red herring. We won't make social issues go away by creating policies. Basically we have limited possibilities to change how amicably people react when they are stepping on each others' toes. Creating more room is a technical measure. It will not change the kind of social interaction we perceive as problematic, but it will still serve to reduce the opportunities for it to occur and cause problems. That said, I admit that I haven't even skimmed the patch countdowns in the past few months, let alone read any arguments on -devel. Mike frequently referenced a Rietveld review as an example in his last mails to the list. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: slurs avoid stafflines: move far enough; issue 3628 (issue 35310043)
https://codereview.appspot.com/35310043/diff/80001/lily/slur-configuration.cc File lily/slur-configuration.cc (right): https://codereview.appspot.com/35310043/diff/80001/lily/slur-configuration.cc#newcode66 lily/slur-configuration.cc:66: + state.line_thickness_ On 2013/12/08 10:10:11, janek wrote: The comment says half of the staffline but here it's not halved - is this ok? It says half for the staff line, half for the slur outline each of those halves being half a line-thickness. Two halves add to one, so there is a full thine-thickness added in the code. https://codereview.appspot.com/35310043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: anyone notice speed of 2.17.95 on Windows ?
On Tue, 10 Dec 2013 01:59:09 -0800, Phil Holmes m...@philholmes.net wrote: When I benchmarked with and without skylines, I found there was only a noticeable difference with a lot of markup or similar: normal music had almost no effect. As a result, I concluded with skylining was the correct default. I agreed about the default being good, but normal music was 30% slower http://lists.gnu.org/archive/html/lilypond-devel/2013-09/msg00234.html (We see there the effect of Mike's commit that cached the (millions) of page-fillings from Joe's line-breaking scheme; that caching made 2.14 3x faster than 2.12.) I had seen the same, moderate, effect on Linux, but the same music suffers more with skylines on my WinXP system. I'll try your Mikado on my WinXP system, to narrow down the key components that show the 2x slowdown. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: branching
On 12/10/13 5:42 AM, Mike Solomon m...@mikesolomon.org wrote: Hey all, As 2.18 draws near, I¹d like to work with everyone to establish a system of branching for LilyPond development. After several rounds of discussing things with David K, this emerged as the best way to avoid arguments about integrating work into the development branch that have led several contributors, including myself, to significantly reduce time on the project. I can see how the proposed mechanism avoids arguments about work that is going into individual developers branches, but I don't see how this avoids arguments about what goes into the development branch. As far as I can see, this proposal supports the creation of multiple forks of the lilypond development branch, one for each of the privileged developers, plus one for the accepted features. And then lilypond.org should support all of those forks. This seems like a nightmare to me. It is good for somebody who wants to get their features out the the user base. But this just makes the decisions about what to include in the development branch more emotionally charged. I'll present a hypothetical exchange between two caricatures: the creative developer who is only concerned about adding a really neat feature, and doesn't care how it affects the code base; and the consistent developer who is only concerned about the consistency of the code base, and would rather have no new features added than have a new feature added that requires contortions in the syntax, the parser/lexer, or the code base. Note that both of these are caricatures, drawn for the purpose of highlighting the conflict, not for the purpose of illustrating the behavior of any real developer. Creative developer: See how many people like this feature? It's so positive that we absolutely have to include it. Consistent developer: See how badly this would destroy the current code base? It's just an ugly hack. If we accept features like this, our code base will soon consist of nothing but ugly hacks. I don't care how many people like the feature; it's disastrous as currently implemented, so I won't accept it. And now, in addition to the different points of view of these developers, we have the added pressure of users clamoring for a feature. Personally, I want *both* the creative developer and the consistent developer to be satisfied. I want ugly hacks in the codebase to be decreasing, not increasing. I want new features that make the engraving better. If we can't implement new features without ugly hacks, I don't think they should be added to the codebase. But I don't want stasis in the codebase to prevent the addition of new features. Developers already have branches on the main repository. So this proposal is not really to add branches. The real issue in the proposal is about how to get users using these branches. I have a very hard time thinking that it's in the best interest of lilypond as a project to have multiple official development branches. Instead, I think that developers who create a branch that provides some new functionality should invite users to test the branch (which probably means that the developer needs to get GUB running on his or her branch and then make the binaries available). [1] I feel that this reduction in commit diversity is the biggest obstacle to LilyPond¹s future evolution, which is why I¹m calling on everyone to make a concerted effort to think this through. I have made a concerted effort to think this through. I believe that a reduction in commit diversity is a serious problem. I think the community was greatly weakened when Mike felt that it was no longer worth putting up with the hassles to make his contributions. However, I think that a fractured development branch (up to 6 different branches) would be an even bigger obstacle to future evolution. I think it would lead to a balkanization of LilyPond. Of course, given my participation in development over the last couple of years, my input may not be worth much. Thanks, Carl S. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: branching
On Dec 10, 2013, at 9:32 PM, Carl Sorensen c_soren...@byu.edu wrote: On 12/10/13 5:42 AM, Mike Solomon m...@mikesolomon.org wrote: Hey all, As 2.18 draws near, I¹d like to work with everyone to establish a system of branching for LilyPond development. After several rounds of discussing things with David K, this emerged as the best way to avoid arguments about integrating work into the development branch that have led several contributors, including myself, to significantly reduce time on the project. This seems like a nightmare to me. It is good for somebody who wants to get their features out the the user base. But this just makes the decisions about what to include in the development branch more emotionally charged. It seems like everyone agrees, so this is definitely not the way to go. I'll present a hypothetical exchange between two caricatures: the creative developer who is only concerned about adding a really neat feature, and doesn't care how it affects the code base; and the consistent developer who is only concerned about the consistency of the code base, and would rather have no new features added than have a new feature added that requires contortions in the syntax, the parser/lexer, or the code base. This is a fantastic hypothetical exchange. [1] I feel that this reduction in commit diversity is the biggest obstacle to LilyPond¹s future evolution, which is why I¹m calling on everyone to make a concerted effort to think this through. I have made a concerted effort to think this through. I believe that a reduction in commit diversity is a serious problem. I think the community was greatly weakened when Mike felt that it was no longer worth putting up with the hassles to make his contributions. However, I think that a fractured development branch (up to 6 different branches) would be an even bigger obstacle to future evolution. I think it would lead to a balkanization of LilyPond. Of course, given my participation in development over the last couple of years, my input may not be worth much. After seeing people’s responses, I agree. It is obvious from everyone’s reflections (especially yours, which is very thorough) that if branches become an institutionalized feature of development, they will hurt LilyPond. I rescind my idea. The only hassle for me, which I did not run up against when I started with the project, is David’s way of communicating. I’m not claiming this is all on him, but I’m also pretty sure that I’m not the only one who has peaced out because of this. I am looking for ways for this to no longer be an issue. I was hoping that branches would go a way towards making this happen for myself and hopefully other developers, but it’s clear that this is not a good idea. In my two day jobs, director of the ensemble 101 and developer for the Guido project, I work with two (very different) teams of people on projects that require creativity, consistency, and tons of communication. Neither of them has any of this friction resulting from communication issues, both of them enjoy a diversity in major contributions, and both are evolving rapidly and stably in several interesting ways at the same time. I truly hope that LilyPond can be like that. Thank you for taking the time to think this over and for your response. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: branching
On Tue, Dec 10, 2013 at 3:21 PM, Mike Solomon m...@mikesolomon.org wrote: The only hassle for me, which I did not run up against when I started with the project, is David’s way of communicating. I’m not claiming this is all on him, but I’m also pretty sure that I’m not the only one who has peaced out because of this. I am looking for ways for this to no longer be an issue. I was hoping that branches would go a way towards making this happen for myself and hopefully other developers, but it’s clear that this is not a good idea. In my two day jobs, director of the ensemble 101 and developer for the Guido project, I work with two (very different) teams of people on projects that require creativity, consistency, and tons of communication. Neither of them has any of this friction resulting from communication issues, both of them enjoy a diversity in major contributions, and both are evolving rapidly and stably in several interesting ways at the same time. I truly hope that LilyPond can be like that. I don't know how you communicate with your other two teams, but the simple fact is that email is a terrible method of communication, when it comes to the things that you appear to be seeking. An amused or straightforward comment can across as harsh or sarcastic when visual and aural cues are absent (citing the studies that show that 90% of communication is nonverbal, i.e., not connected to the actual words). Some people's manners of speech translate into text-only communication better than others', and some don't translate at all. I had a boss a couple of years back who could be very friendly and personable face-to-face, but unless she was obvious happy about something, always came across as stern and upset with the way things were done. It happens. But you may already be well aware of all this. It is regrettable that you would let such things interfere with your contributions to LilyPond. Ultimately, it is about the project, not the people. Perhaps counter-intuitively, the answer to the problem you perceive is not to reduce participation, but to increase participation. In my own case, my interactions with David had the effect of getting me more involved in the behind the scenes workings of the code. Why? So that eventually, David won't be able to criticize me for not being willing to get my hands dirty. I haven't made a commit yet, but that's probably a matter of weeks or days (whenever I get git-cl set up on my dev machine). In the meantime, instead of complaining about this feature or that feature, or going Oh, poor, pitiful me, someone give me a code snippet to do x, I've tried to dig into things to make them work. Now the thing I'm trying to figure out is how to make what I'm doing usable for others who do the same things so that LilyPond is an easier environment to use. Will I ever get to where I'm wrangling the underlying C++ code? Probably not. But I'm working on what I can. Cheers, Carl P. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Use standard inclusion scheme for FreeType headers. (issue 35580043)
Reviewers: dak, Message: My patch is very simple, as you can see, just replacing the hardcoded header paths with macros (this is what I refer as `standard inclusion scheme') to make it compile. The `reckless' programming was there before me, so to say, and I admit that I haven't tried in any way to make it more elegant. I fully agree that it makes sense to add #include freetype.hh or #include ft2build.h where FreeType header macro names are used. Description: Use standard inclusion scheme for FreeType headers. The most recent FreeType release (2.5.1) has changed locations for header files. Using the standard way, this is not visible to applications. Please review this at https://codereview.appspot.com/35580043/ Affected files (+6, -6 lines): M lily/freetype-error.cc M lily/freetype.cc M lily/open-type-font.cc M lily/pango-font.cc M lily/ttf.cc Index: lily/freetype-error.cc diff --git a/lily/freetype-error.cc b/lily/freetype-error.cc index 00e5cae3519b28cc8f1314334e25cd3ec3884115..88af76c1ae84ad97b870e016a0c8e1ac432ed90f 100644 --- a/lily/freetype-error.cc +++ b/lily/freetype-error.cc @@ -31,7 +31,7 @@ const struct Freetype_error_message const char *err_msg; } ft_errors[] = -#include freetype/fterrors.h +#include FT_ERRORS_H ; Index: lily/freetype.cc diff --git a/lily/freetype.cc b/lily/freetype.cc index d7d4843ce8be17504b0e132b1fbfde45d71b04d1..55a3fb378095af6a0f7f35f7f3e89d55ad6a550a 100644 --- a/lily/freetype.cc +++ b/lily/freetype.cc @@ -20,8 +20,8 @@ #include freetype.hh #include warn.hh -#include freetype/ftoutln.h -#include freetype/ftbbox.h +#include FT_OUTLINE_H +#include FT_BBOX_H FT_Library freetype2_library; Index: lily/open-type-font.cc diff --git a/lily/open-type-font.cc b/lily/open-type-font.cc index df6a744d0e42165e6d31837d1b474c16b78c8fc9..837a1f23001772aebe5bec7271c2084b80e82ca4 100644 --- a/lily/open-type-font.cc +++ b/lily/open-type-font.cc @@ -23,7 +23,7 @@ using namespace std; -#include freetype/tttables.h +#include FT_TRUETYPE_TABLES_H #include dimensions.hh #include freetype.hh Index: lily/pango-font.cc diff --git a/lily/pango-font.cc b/lily/pango-font.cc index ee986fc94d76a653256212c0a7e9ab7d80517bbc..b148a5bc08cf52b98849d2c71663859a254813cc 100644 --- a/lily/pango-font.cc +++ b/lily/pango-font.cc @@ -22,7 +22,7 @@ #define PANGO_ENABLE_BACKEND #include pango/pangoft2.h -#include freetype/ftxf86.h +#include FT_XFREE86_H #include map #include cstdio Index: lily/ttf.cc diff --git a/lily/ttf.cc b/lily/ttf.cc index eaeb67adfb25a46b9dfbd16858a4abd0d1e755b4..6d7f97bf37c4703df35cda3a58673059e34d1159 100644 --- a/lily/ttf.cc +++ b/lily/ttf.cc @@ -20,7 +20,7 @@ #include cstdio #include freetype.hh -#include freetype/tttables.h +#include FT_TRUETYPE_TABLES_H #include international.hh #include memory-stream.hh ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: anyone notice speed of 2.17.95 on Windows ?
On Tue, 10 Dec 2013 09:57:20 -0800, Keith OHara k-ohara5...@oco.net wrote: On Tue, 10 Dec 2013 01:59:09 -0800, Phil Holmes m...@philholmes.net wrote: When I benchmarked with and without skylines, I found there was only a noticeable difference with a lot of markup or similar: normal music had almost no effect. As a result, I concluded with skylining was the correct default. I'll try your Mikado on my WinXP system, Chorus Number 5 takes 17.2s with 2.16.2, and takes 31.1s with 2.17.95 This ratio of times is worse than Phil saw when he timed the full Act1 using Win64Vista. So maybe the larger slowdown is localized to WinXP. Disabling all the vertical-skylines-from-stencil-integral settings brings the time down to 16.2s with version 2.17.95. The last time we had a doubling of time required on Windows relative to Linux, issue 1926, it was repeated calls to find_by_name() that go through Pango to the font server. Here the outlines seem to be properly cached; it looks like each text glyph is looked up just one extra time. The call the to FreeType glyph-outline code might cause the extra time, or maybe Guile is less efficient on WinXP, as every nook and cranny in every letter is represented in the skylines objects in Scheme. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: branching
Hi, On Tue, Dec 10, 2013 at 2:46 PM, Carl Peterson carlopeter...@gmail.comwrote: On Tue, Dec 10, 2013 at 3:21 PM, Mike Solomon m...@mikesolomon.orgwrote: The only hassle for me, which I did not run up against when I started with the project, is David’s way of communicating. I’m not claiming this is all on him, but I’m also pretty sure that I’m not the only one who has peaced out because of this. I am looking for ways for this to no longer be an issue. I was hoping that branches would go a way towards making this happen for myself and hopefully other developers, but it’s clear that this is not a good idea. In my two day jobs, director of the ensemble 101 and developer for the Guido project, I work with two (very different) teams of people on projects that require creativity, consistency, and tons of communication. Neither of them has any of this friction resulting from communication issues, both of them enjoy a diversity in major contributions, and both are evolving rapidly and stably in several interesting ways at the same time. I truly hope that LilyPond can be like that. I don't know how you communicate with your other two teams, but the simple fact is that email is a terrible method of communication, when it comes to the things that you appear to be seeking. An amused or straightforward comment can across as harsh or sarcastic when visual and aural cues are absent (citing the studies that show that 90% of communication is nonverbal, i.e., not connected to the actual words). Some people's manners of speech translate into text-only communication better than others', and some don't translate at all. I had a boss a couple of years back who could be very friendly and personable face-to-face, but unless she was obvious happy about something, always came across as stern and upset with the way things were done. It happens. But you may already be well aware of all this. I always feel a bit silly writing emoticons and exclamation points, but they are nice to see(!) It is regrettable that you would let such things interfere with your contributions to LilyPond. Exactly. Both you and David are invaluable to this project. I watched the paralysis set in, the deadlock, and wondered a bit about the future of the project. I think there has to be some compromise in this Apollonian/Dionysian test of wills (to throw in a little pretentiousness). Ultimately, it is about the project, not the people. Perhaps counter-intuitively, the answer to the problem you perceive is not to reduce participation, but to increase participation. In my own case, my interactions with David had the effect of getting me more involved in the behind the scenes workings of the code. Why? So that eventually, David won't be able to criticize me for not being willing to get my hands dirty. Well, I ordinarily have a bit of a thin skin, and I remember reading somewhere on the lists that you have to have some nerve to contribute. My personal response to the possibility of brutally honest criticism--which is a necessary thing if this project isn't going to go to hell--is to make sure I've got everything as polished as I can make it before I make it public. And accepting that I've got a lot to learn, (This is about me, and is in no way directed at you, Mike.) However, when the standstill happens, something has to be done. I'm sorry that I don't have any solution to offer, other than to try to work together for the sake of LilyPond, (Emoticons! Kidding.) --David ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Use standard inclusion scheme for FreeType headers. (issue 35580043)
On 2013/12/10 21:20:54, lemzwerg wrote: My patch is very simple, as you can see, just replacing the hardcoded header paths with macros (this is what I refer as `standard inclusion scheme') to make it compile. The `reckless' programming was there before me, so to say, and I admit that I haven't tried in any way to make it more elegant. No, it wasn't. Before your change, header _names_ were used for inclusion. Those do not require to be defined before use. After your change, header _macros_ were used for inclusion. Those require to be defined before use. The problem of using macros without reliably ensuring their definition before use was introduced by this patch. I fully agree that it makes sense to add #include freetype.hh or #include ft2build.h where FreeType header macro names are used. What does Freetype state about where its header macro names are defined? It is obvious that ft2build.h will cause their definition (or this would not have compiled) but it's not clear that this definition is not also incidental rather than well-defined. https://codereview.appspot.com/35580043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: anyone notice speed of 2.17.95 on Windows ?
Keith OHara k-ohara5...@oco.net writes: On Tue, 10 Dec 2013 09:57:20 -0800, Keith OHara k-ohara5...@oco.net wrote: On Tue, 10 Dec 2013 01:59:09 -0800, Phil Holmes m...@philholmes.net wrote: When I benchmarked with and without skylines, I found there was only a noticeable difference with a lot of markup or similar: normal music had almost no effect. As a result, I concluded with skylining was the correct default. I'll try your Mikado on my WinXP system, Chorus Number 5 takes 17.2s with 2.16.2, and takes 31.1s with 2.17.95 This ratio of times is worse than Phil saw when he timed the full Act1 using Win64Vista. So maybe the larger slowdown is localized to WinXP. Disabling all the vertical-skylines-from-stencil-integral settings brings the time down to 16.2s with version 2.17.95. The last time we had a doubling of time required on Windows relative to Linux, issue 1926, it was repeated calls to find_by_name() that go through Pango to the font server. Here the outlines seem to be properly cached; it looks like each text glyph is looked up just one extra time. Once every time it is written, or once per document? And what does just one extra time mean? One extra per which occasion? The call the to FreeType glyph-outline code might cause the extra time, or maybe Guile is less efficient on WinXP, as every nook and cranny in every letter is represented in the skylines objects in Scheme. If there are differences in speed, I can't imagine them to be in anything but possibly garbage collection/allocation, and it seems unlikely that they would not then have been apparent with other uses. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: branching
On Dec 11, 2013, at 12:03 AM, David Nalesnik david.nales...@gmail.com wrote: Hi, On Tue, Dec 10, 2013 at 2:46 PM, Carl Peterson carlopeter...@gmail.com wrote: On Tue, Dec 10, 2013 at 3:21 PM, Mike Solomon m...@mikesolomon.org wrote: The only hassle for me, which I did not run up against when I started with the project, is David’s way of communicating. I’m not claiming this is all on him, but I’m also pretty sure that I’m not the only one who has peaced out because of this. I am looking for ways for this to no longer be an issue. I was hoping that branches would go a way towards making this happen for myself and hopefully other developers, but it’s clear that this is not a good idea. In my two day jobs, director of the ensemble 101 and developer for the Guido project, I work with two (very different) teams of people on projects that require creativity, consistency, and tons of communication. Neither of them has any of this friction resulting from communication issues, both of them enjoy a diversity in major contributions, and both are evolving rapidly and stably in several interesting ways at the same time. I truly hope that LilyPond can be like that. I don't know how you communicate with your other two teams, Face-to-face communication for one, e-mail for another. I always feel a bit silly writing emoticons and exclamation points, but they are nice to see(!) It is regrettable that you would let such things interfere with your contributions to LilyPond. Exactly. Both you and David are invaluable to this project. I watched the paralysis set in, the deadlock, and wondered a bit about the future of the project. I think there has to be some compromise in this Apollonian/Dionysian test of wills (to throw in a little pretentiousness). See: http://lilypond.1069038.n5.nabble.com/Allows-minimum-length-to-work-for-end-of-line-spanners-issue-7453046-td141952.html#a142870 as one of several examples. There is truth in anything David says, meaning that I (like him (and most of us on this list)) have caused bugs that I did not find or fix before someone else. How, does this warrant this communication style? This chain of e-mails was the single determinant that ruled LilyPond out of a government funded, multi-national European typesetting project I’m organizing in which the team will need to extend aspects of the software. I imagined the score of man hours that goes into all the projects I do and how important team morale is over the long term. I don’t want anyone on my team to lose time feeling bad from e-mail confrontations - it’s not worth it for many reasons. Ultimately, it is about the project, not the people. Perhaps counter-intuitively, the answer to the problem you perceive is not to reduce participation, but to increase participation. In my own case, my interactions with David had the effect of getting me more involved in the behind the scenes workings of the code. Why? So that eventually, David won't be able to criticize me for not being willing to get my hands dirty. Well, I ordinarily have a bit of a thin skin, and I remember reading somewhere on the lists that you have to have some nerve to contribute. My personal response to the possibility of brutally honest criticism--which is a necessary thing if this project isn't going to go to hell--is to make sure I've got everything as polished as I can make it before I make it public. And accepting that I've got a lot to learn, (This is about me, and is in no way directed at you, Mike.) Of course I have a lot to learn, too. I release things in various states of polished-ness to the list, often because its their unpolished-ness that I need comments or opinions on. This in and of itself is valuable information. Imagining a hypothetical scenario where I sent a patch that someone wants to see restructured into several commits before they can review it. One developer responds: It’s difficult for me to understand what you’re doing - please split it up. and another responds: Please act like a member of the community, start taking other people into consideration and split up your patches. The information is the same, but (A) makes me want to stay in the project a lot more than (B). A lot of (B) causes me to lose interest. How does one proceed? Should one gloss over the way (B) is written and get (A) out of it? Should one respond to (B) on its own terms? How does one let these things not interfere with one’s contributions? I currently have a boss who is an industry-expert in typesetting that decided not to get involved with LilyPond development 3 or 4 years ago because of feuds he saw on the devel list. This is not good. By old developers not contributing as much and new ones not wanting to join, our community has dwindled down to one where 40% of commits are made by one person, and this is including documentation, meaning that
Re: anyone notice speed of 2.17.95 on Windows ?
On Tue, 10 Dec 2013 17:22:19 -0800, David Kastrup d...@gnu.org wrote: Keith OHara k-ohara5...@oco.net writes: The last time we had a doubling of time required on Windows relative to Linux, issue 1926, it was repeated calls to find_by_name() that go through Pango to the font server. Here the outlines seem to be properly cached; it looks like each text glyph is looked up just one extra time. Once every time it is written, or once per document? And what does just one extra time mean? One extra per which occasion? After a brief look at the code, it looked like for each glyph being laid out there is one extra call of Open_type_font:: or Pango_font::name_to_index(), which is the function called by find_by_name() that caused the extra time with issue 1926. That is, for every 'mf' in the piece, we look up two glyphs by name 'm' and 'f' from the font to get a skyline for the 'mf', each skyline is built just once. The look-ups are extra over those used to implement the stencil. One extra lookup per glyph might be enough to explain the difference. We need to look up the glyph to get a skyline, but maybe could cache its index into the font in the stencil. What did you mean to suggest here? : In this case, the answer is to cache frequently accessed information instead of requesting it again and again. The call the to FreeType glyph-outline code might cause the extra time, or maybe Guile is less efficient on WinXP, as every nook and cranny in every letter is represented in the skylines objects in Scheme. If there are differences in speed, I can't imagine them to be in anything but possibly garbage collection/allocation, and it seems unlikely that they would not then have been apparent with other uses. Probably true. I mentioned these possibilities after noticing that there are quite a few boxes required to represent the outline of each letter.. What did you mean to suggest here? : Maybe caching in unsuitable form? Cached data should be in a form directly usable for processing (with some possible tradeoffs between memory impact and unpacking speed), not in the form that function/library/system calls will return it. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Use standard inclusion scheme for FreeType headers. (issue 35580043)
The problem of using macros without reliably ensuring their definition before use was introduced by this patch. Right you are, I haven't thought of this. Will post a follow-up patch to Rietveld soon. What does Freetype state about where its header macro names are defined? It is obvious that ft2build.h will cause their definition (or this would not have compiled) but it's not clear that this definition is not also incidental rather than well-defined. Actually, it stated nothing! I've just added a section to the FreeType API documentation which describes that properly. Thanks for the bug report, so to say :-) https://codereview.appspot.com/35580043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
centralization of lilypond development and forking (was: branching)
On Wed, Dec 11, 2013 at 08:39:58AM +0200, Mike Solomon wrote: See: http://lilypond.1069038.n5.nabble.com/Allows-minimum-length-to-work-for-end-of-line-spanners-issue-7453046-td141952.html#a142870 as one of several examples. There is truth in anything David says, meaning that I (like him (and most of us on this list)) have caused bugs that I did not find or fix before someone else. How, does this warrant this communication style? Interesting. I totally agree that lilypond has a problem (see below), but in that email chain I find myself nodding along with David. I mean, he makes empirical claims (such as documentation about partial elliptic stencils) that I assume are accurate (since I doubt he would make empirical claims without checking that they are true). However, I am not blind to the end result of the communications. I mean, at the beginning of September 2012 (after the meeting at the ranch) I was more enthusiastic about LilyPond than I had been for the previous 5 years, but one month later I decided to pretty much quit the project. I know I have the (well-deserved) reputation of being extremely conservative, but that's in part because I don't want to abuse any donations or make any demands on existing/previous volunteers. The idea of providing multiple binaries is one such example (donated web serving and bandwidth), and the general notion of lilypond should not break stuff that previously deliberately worked is another. But that's not to say that those constraints are unbreakable. The usual approach in the open-source community to a situation where a significant number of people want to have a radical break with previous traditions is to fork the project. As a thought experiment, let's suppose that a new project forks from 2.18.0, called OakMountain instead of LilyPond. At a bare minimum, OakMountain would need: - a git repository. (trivially easy these days) - does it want to provide binaries? Using GUB would bring in a huge amount of technical constraints, along with a certain amount of bandwidth required. But maybe OakMountain wouldn't care about that; it could target linux only, and provide an Ubuntu disk image for any users on windows or OSX who want to do engraving. (admittedly, the Ubuntu image would also require a fair chunk of bandwidth... but maybe OakMountain would target the default Ubuntu 12.04 live disk image) - does it want to provide any defence against regressions? Maybe not. Maybe OakMountain would guarantee that monophonic music with no lyrics will still work, but anything else could change and break. This is not a rhetorical question. I'm still quite interested in having a music engraving system that's suitable for a final version of my string music scores (particularly in conjuction with Vivi, physical modelling performances of those works). As we saw in Sep 2012, LilyPond does not qualify, but if this was a goal of OakMountain then I'd be interested in joining. (that said, I'm contractually forbidden from contributing code to open-source projects until June 2014, although emails and organization are fine) Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: branching
One thing that is important to restate is that I realize that, unlike my bad-but-getting-better commenting style, _all_ of this is out of David’s control in that it stems from a medical issue. Which means that the communication problems won’t go away - they’re going to be a fixture of LilyPond development so long as he’s involved. As a group of humans, it is _everyone’s_ responsibility to find creative ways to get past handicaps because _no one_ wants to have them. What I’d like to see is a situation where David can blow off steam however he needs to, he doesn’t feel like people are ignoring him, and LilyPond can be a dynamic, multiplayer environment without people getting offended and leaving the project. I fully agree. I got into the habit of contacting apparently offended people off-list to explain the very reasons why communication on this list can be tedious sometimes. And please remember the most important thing: There is *never* an intention, as far as I can see, to offend people. The more factual the discussion, the better it works. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Use standard inclusion scheme for FreeType headers. (issue 35580043)
Will post a follow-up patch to Rietveld soon. http://code.google.com/p/lilypond/issues/detail?id=3717 https://codereview.appspot.com/35580043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: centralization of lilypond development and forking (was: branching)
On Dec 11, 2013, at 9:18 AM, Graham Percival gra...@percival-music.ca wrote: On Wed, Dec 11, 2013 at 08:39:58AM +0200, Mike Solomon wrote: See: http://lilypond.1069038.n5.nabble.com/Allows-minimum-length-to-work-for-end-of-line-spanners-issue-7453046-td141952.html#a142870 as one of several examples. There is truth in anything David says, meaning that I (like him (and most of us on this list)) have caused bugs that I did not find or fix before someone else. How, does this warrant this communication style? Interesting. I totally agree that lilypond has a problem (see below), but in that email chain I find myself nodding along with David. I mean, he makes empirical claims (such as documentation about partial elliptic stencils) that I assume are accurate (since I doubt he would make empirical claims without checking that they are true). Anything empirical in there is accurate. However, I am not blind to the end result of the communications. I mean, at the beginning of September 2012 (after the meeting at the ranch) I was more enthusiastic about LilyPond than I had been for the previous 5 years, but one month later I decided to pretty much quit the project. This is bad. If this were some ultimate, fatalistic consequence of participation in any open-source project, I’d shrug and move onto the next, but it is precisely because in every other project I participate in this _doesn’t_ exist that I’m going through pains to try to solve this here. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
