Re: centralization of lilypond development and forking (was: branching)

On Dec 11, 2013, at 9:18 AM, Graham Percival 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.

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-dev

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 L

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

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

Re: anyone notice speed of 2.17.95 on Windows ?

On Tue, 10 Dec 2013 17:22:19 -0800, David Kastrup wrote: "Keith OHara" 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 c

Re: branching

On Dec 11, 2013, at 12:03 AM, David Nalesnik wrote: > > Hi, > > On Tue, Dec 10, 2013 at 2:46 PM, Carl Peterson > wrote: > On Tue, Dec 10, 2013 at 3:21 PM, Mike Solomon wrote: > > The only hassle for me, which I did not run up against when I started with > the project, is David’s way of com

Re: anyone notice speed of 2.17.95 on Windows ?

"Keith OHara" writes: > On Tue, 10 Dec 2013 09:57:20 -0800, Keith OHara wrote: > >> On Tue, 10 Dec 2013 01:59:09 -0800, Phil Holmes 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

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 hav

Re: branching

Hi, On Tue, Dec 10, 2013 at 2:46 PM, Carl Peterson wrote: > On Tue, Dec 10, 2013 at 3:21 PM, Mike Solomon 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 als

Re: anyone notice speed of 2.17.95 on Windows ?

On Tue, 10 Dec 2013 09:57:20 -0800, Keith OHara wrote: On Tue, 10 Dec 2013 01:59:09 -0800, Phil Holmes 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 con

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

Re: branching

On Tue, Dec 10, 2013 at 3:21 PM, Mike Solomon 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 becau

Re: branching

On Dec 10, 2013, at 9:32 PM, Carl Sorensen wrote: > > > On 12/10/13 5:42 AM, "Mike Solomon" 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

Re: branching

On 12/10/13 5:42 AM, "Mike Solomon" 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 w

Re: anyone notice speed of 2.17.95 on Windows ?

On Tue, 10 Dec 2013 01:59:09 -0800, Phil Holmes 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

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 wrot

Re: branching

Graham Percival 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 peop

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 > end

Re: branching

On Dec 10, 2013, at 4:23 PM, David Kastrup wrote: > Mike Solomon 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

Re: branching

Mike Solomon 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 develo

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 d

Re: branching

On Dec 10, 2013, at 2:58 PM, Graham Percival 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 down

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

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 seve

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-

PATCHES: Countdown – December 13th – 06:00 GMT

hello *Countdown – December 13th – 06:00 GMT* * * * * * * * * * * 3679

Re: anyone notice speed of 2.17.95 on Windows ?

On Dec 10, 2013, at 12:18 PM, David Kastrup wrote: > Mike Solomon writes: > >> On Dec 10, 2013, at 11:47 AM, David Kastrup 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 pe

Re: anyone notice speed of 2.17.95 on Windows ?

Mike Solomon writes: > On Dec 10, 2013, at 11:47 AM, David Kastrup 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

Re: anyone notice speed of 2.17.95 on Windows ?

On Dec 10, 2013, at 11:47 AM, David Kastrup wrote: > Mike Solomon writes: > >> On Dec 10, 2013, at 11:27 AM, David Kastrup wrote: >> >>> Mike Solomon writes: >>> On Dec 10, 2013, at 10:36 AM, Keith OHara wrote: > > I did speed-test that patch, but under Linux. Maybe the sys

Re: anyone notice speed of 2.17.95 on Windows ?

- Original Message - From: "Werner LEMBERG" To: Cc: ; ; 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 cou

Re: anyone notice speed of 2.17.95 on Windows ?

Mike Solomon writes: > On Dec 10, 2013, at 11:27 AM, David Kastrup wrote: > >> Mike Solomon writes: >> >>> On Dec 10, 2013, at 10:36 AM, Keith OHara wrote: I did speed-test that patch, but under Linux. Maybe the system calls to the font server, to get outlines for the glyphs,

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/lis

Re: anyone notice speed of 2.17.95 on Windows ?

On Dec 10, 2013, at 11:27 AM, David Kastrup wrote: > Mike Solomon writes: > >> On Dec 10, 2013, at 10:36 AM, Keith OHara wrote: >> >>> On Mon, 25 Nov 2013 00:10:08 -0800, David Kastrup wrote: >>> "Keith OHara" writes: > I timed one big score, Movement 1 of >

Re: anyone notice speed of 2.17.95 on Windows ?

Mike Solomon writes: > On Dec 10, 2013, at 10:36 AM, Keith OHara wrote: > >> On Mon, 25 Nov 2013 00:10:08 -0800, David Kastrup wrote: >> >>> "Keith OHara" writes: >>> I timed one big score, Movement 1 of 2.1

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

Re: anyone notice speed of 2.17.95 on Windows ?

On Dec 10, 2013, at 10:36 AM, Keith OHara wrote: > On Mon, 25 Nov 2013 00:10:08 -0800, David Kastrup wrote: > >> "Keith OHara" writes: >> >>> I timed one big score, Movement 1 of >>> >>> 2.16.2 2.17.95 >>> WinXP 2m 30s

Re: anyone notice speed of 2.17.95 on Windows ?

On Mon, 25 Nov 2013 00:10:08 -0800, David Kastrup wrote: "Keith OHara" writes: I timed one big score, Movement 1 of 2.16.2 2.17.95 WinXP 2m 30s 5m 10s Fedora 1m 50s 1m 50s Have you used the GUB-compiled binary