Keep parsed document in memory (was: LilyPond as a service)

2016-02-22 Thread Urs Liska
Hi David, thank you for your explanation, which is the base for a (presumably more complicated) follow-up question. Am 17.02.2016 um 23:31 schrieb David Kastrup: > Urs Liska writes: > >> I know this has been discussed in various flavors over the years, but I >> need to raise the issue once more.

Re: Keep parsed document in memory

2016-02-22 Thread David Kastrup
Urs Liska writes: > So, let's assume we already had implemented a server daemon mode for > LilyPond. > Would it be possible to make that daemon keep a representation of the > *parsed* document in memory? > > OK, looking at it from traditional use-cases this might seem > nonsensical. Why would you

Re: Keep parsed document in memory

2016-02-22 Thread Urs Liska
Am 22.02.2016 um 12:27 schrieb David Kastrup: > Urs Liska writes: > >> So, let's assume we already had implemented a server daemon mode for >> LilyPond. >> Would it be possible to make that daemon keep a representation of the >> *parsed* document in memory? >> >> OK, looking at it from tradition

Re: Doc: NR: 3.x Clarification for \keepWithTag and fix Typo in example (issue 279140043 by pkx1...@gmail.com)

2016-02-22 Thread Federico Bruni
Il giorno dom 21 feb 2016 alle 11:44, pkx1...@gmail.com ha scritto: Thanks Federico - see inline for my replies. https://codereview.appspot.com/279140043/diff/40001/Documentation/notation/input.itely File Documentation/notation/input.itely (right): https://codereview.appspot.com/279140043/diff

Re: Doc: NR: 3.x Clarification for \keepWithTag and fix Typo in example (issue 279140043 by pkx1...@gmail.com)

2016-02-22 Thread dak
https://codereview.appspot.com/279140043/diff/60001/Documentation/notation/input.itely File Documentation/notation/input.itely (right): https://codereview.appspot.com/279140043/diff/60001/Documentation/notation/input.itely#newcode2323 Documentation/notation/input.itely:2323: \keepWithTag #'(A B)

Re: Allura account

2016-02-22 Thread Valentin Villenave
On Tue, Feb 16, 2016 at 2:42 PM, Trevor Daniels wrote: > I see you're already registered as a Developer on Allura. Maybe Phil just > beat me to it. Greetings Trevor, could you add me as well? (On the off chance I’m able to contribute a bit more to LilyPond in weeks to come...) My SF usename is

Re: Keep parsed document in memory

2016-02-22 Thread Sharon Rosner
> I worked on a large score with about 100 A3 pages with 13 point staff > size (~ 50 minutes of huge orchestra). > > Compiling the full score using manual breaks took around 7 minutes, with > the console output seemingly indicating the switch from parsing to > engraving after around 1'30. > Then I

Re: Keep parsed document in memory

2016-02-22 Thread Urs Liska
Hi Sharon, Am 22.02.2016 um 20:22 schrieb Sharon Rosner: >> I worked on a large score with about 100 A3 pages with 13 point staff >> size (~ 50 minutes of huge orchestra). >> >> Compiling the full score using manual breaks took around 7 minutes, with >> the console output seemingly indicating the

Re: Keep parsed document in memory

2016-02-22 Thread Simon Albrecht
On 22.02.2016 20:22, Sharon Rosner wrote: Having worked on numerous big scores I've found that if you separate the instrumental parts into separate files you can work quite efficiently on fixes, tweaks and annotations. That’s true for proofreading, but it’s not true for beautification, and mak

Re: Keep parsed document in memory

2016-02-22 Thread Sharon Rosner
> That’s true for proofreading, but it’s not true for beautification, and > making the full score publication-ready. Horizontal and vertical spacing > will be completely different if only individual parts are compiled, or > if sections of the full score are compiled without having a notion of >

Re: Allura account

2016-02-22 Thread Trevor Daniels
Hi Valentin Nice to have you back! I've added your username as a Developer, so you should now be able to Read, Create and Update Issues. Trevor - Original Message From: "Valentin Villenave" To: "Trevor Daniels" Cc: "Carl Sorensen" ; "Phil Holmes" ; "Carl Sorensen" ; "Lily-Deve

Re: Define French as a separate input language (issue 288290043 by v.villen...@gmail.com)

2016-02-22 Thread v . villenave
Reviewers: simon.albrecht, Message: On 2016/02/22 20:46:57, simon.albrecht wrote: https://codereview.appspot.com/288290043/diff/1/Documentation/notation/pitches.itely File Documentation/notation/pitches.itely (right): https://codereview.appspot.com/288290043/diff/1/Documentation/notation/pit

Re: Define French as a separate input language (issue 288290043 by v.villen...@gmail.com)

2016-02-22 Thread Noeck
Hi, if you allow non-ascii letters in the note names (namely é in ré), why not go all the way and call the language "français" instead of "francais" (or at least in addition)? Cheers, Joram ___ lilypond-devel mailing list lilypond-devel@gnu.org https:/

Re: Define French as a separate input language (issue 288290043 by v.villen...@gmail.com)

2016-02-22 Thread Valentin Villenave
On Mon, Feb 22, 2016 at 11:53 PM, Noeck wrote: > if you allow non-ascii letters in the note names (namely é in ré), why > not go all the way and call the language "français" instead of > "francais" (or at least in addition)? Greetings Joram, that’s exactly what this patch does :-) The reason for