Re: [RFC] Transition to Guile 3.0
Am 08.04.2024 um 23:40 schrieb Jonas Hahnfeld: Thanks for testing! I assume this is also enabling Guile optimizations during LilyPond runtime? It would be interesting to see if there's a gain from just compiling the bytecode with optimizations. That would be a one-time cost that may be worth paying, especially if we had proper standalone bytecode compilation that parallelizes... Btw, I get a mass of warning messages during bytecode compilation about possibly unbound variables. IIUC, the reason is that we do not import our "own" modules (the ones in (lily)) from the files that need them, rather relying on loading all modules during startup one after another. Is this correct? That would explain that Guile fails to sort out the dependencies between the modules. Michael
Re: [RFC] Transition to Guile 3.0
Am 08.04.2024 um 23:40 schrieb Jonas Hahnfeld: [snip] Thanks for testing! I assume this is also enabling Guile optimizations during LilyPond runtime? It would be interesting to see if there's a gain from just compiling the bytecode with optimizations. That would be a one-time cost that may be worth paying, especially if we had proper standalone bytecode compilation that parallelizes... IIUC, this will only enable Guile optimizations during runtime when calling LilyPond with -dcompile-scheme-code=#t. My measurements were done without this option, so this is already the case you mentioned. Out of curiosity, I tested setting the optimization level to the maximum value (9). Bytecode compilation speed is exactly the same as with the default (2), runtime speed is not better than with level 2, however. Btw, I'm curious if -dcompile-scheme-code will work on Windows with your recent fixes for Guile on mingw64. Currently, it even segfaults for me. Michael
Re: [RFC] Transition to Guile 3.0
On Tue, 2024-04-02 at 16:40 +0200, Michael Käppler wrote: > Am 01.04.2024 um 22:03 schrieb Jonas Hahnfeld via Discussions on LilyPond > development: > > As pointed out by Han-Wen in November, this is actually fairly little > > code that gets dropped; we need to keep some related to optimizations > > for compatibility with 3.0.0 up to 3.0.2; see also below. > > Just to share some numbers: It is still the case with current Guile master, > that bytecode compilation is nearly 10x slower with the default optimization > level than > with optimizations switched off. > > make bytecode with default optimization level: > real 2m0,875s > user 1m59,989s > sys 0m0,796s > > make bytecode without optimizations: > real 0m16,535s > user 0m14,209s > sys 0m0,810s > > What concerns LilyPond processing speed, I did a comparison with the > medium-sized score > I also used for the JIT vs. non-JIT timings on Windows and got for 10 > subsequent runs: > > Without optimizations: > real 9m1,511s > user 8m52,375s > sys 0m11,423s > > With default optimization level: > real 8m34,762s > user 8m23,027s > sys 0m14,562s > > That would be -5% in compilation time. Does not pay off, I think. Thanks for testing! I assume this is also enabling Guile optimizations during LilyPond runtime? It would be interesting to see if there's a gain from just compiling the bytecode with optimizations. That would be a one-time cost that may be worth paying, especially if we had proper standalone bytecode compilation that parallelizes... Jonas signature.asc Description: This is a digitally signed message part
Re: [RFC] Transition to Guile 3.0
Am 01.04.2024 um 22:03 schrieb Jonas Hahnfeld via Discussions on LilyPond development: This is now up for review in the following merge request: https://gitlab.com/lilypond/lilypond/-/merge_requests/2293 As pointed out by Han-Wen in November, this is actually fairly little code that gets dropped; we need to keep some related to optimizations for compatibility with 3.0.0 up to 3.0.2; see also below. Just to share some numbers: It is still the case with current Guile master, that bytecode compilation is nearly 10x slower with the default optimization level than with optimizations switched off. make bytecode with default optimization level: real 2m0,875s user 1m59,989s sys 0m0,796s make bytecode without optimizations: real 0m16,535s user 0m14,209s sys 0m0,810s What concerns LilyPond processing speed, I did a comparison with the medium-sized score I also used for the JIT vs. non-JIT timings on Windows and got for 10 subsequent runs: Without optimizations: real 9m1,511s user 8m52,375s sys 0m11,423s With default optimization level: real 8m34,762s user 8m23,027s sys 0m14,562s That would be -5% in compilation time. Does not pay off, I think. Michael
Re: [RFC] Transition to Guile 3.0
On Sun, 2023-11-05 at 22:36 +0100, Jonas Hahnfeld wrote: > Step 4: Remove compatibility code for Guile 2.2 > This can happen after we made one or two releases with only Guile 3.0. This is now up for review in the following merge request: https://gitlab.com/lilypond/lilypond/-/merge_requests/2293 As pointed out by Han-Wen in November, this is actually fairly little code that gets dropped; we need to keep some related to optimizations for compatibility with 3.0.0 up to 3.0.2; see also below. > Step 5? Move to Ubuntu 22.04 for testing and bump requirement to Guile > 3.0.7? Then we could remove some more compatibility code, but let's > discuss this at some later point. I still want to go there, pending concrete assessment and implementation. Cheers Jonas signature.asc Description: This is a digitally signed message part
Re: [RFC] Transition to Guile 3.0
On Mon, 2023-12-04 at 21:55 +0100, Jonas Hahnfeld wrote: > On Sun, 2023-11-05 at 22:36 +0100, Jonas Hahnfeld wrote: > > > then remove automatic detection of Guile 2.2 from configure. > > I did not yet upload a merge request to make Guile 3.0 the default for > all builds: After more thought, I believe it's better to do this > together with the removal of automatic configure support for Guile 2.2, > to avoid the situation where we assume that Guile 3.0 is the default, > but building from source will gracefully configure with Guile 2.2, for > example because the system is missing the development package for Guile > 3.0... This next step (requiring Guile 3.0 and removing automatic detection of Guile 2.2 from configure) is now available as https://gitlab.com/lilypond/lilypond/-/merge_requests/2228 Jonas signature.asc Description: This is a digitally signed message part
Re: [RFC] Transition to Guile 3.0
>> then remove automatic detection of Guile 2.2 from configure. > > I did not yet upload a merge request to make Guile 3.0 the default > for all builds: After more thought, I believe it's better to do this > together with the removal of automatic configure support for Guile > 2.2, to avoid the situation where we assume that Guile 3.0 is the > default, but building from source will gracefully configure with > Guile 2.2, for example because the system is missing the development > package for Guile 3.0... +1 Werner
Re: [RFC] Transition to Guile 3.0
On Sun, 2023-11-05 at 22:36 +0100, Jonas Hahnfeld wrote: > Step 3: Switch to Guile 3.0 > Afterwards, we can merge > https://gitlab.com/lilypond/lilypond/-/merge_requests/2163 I put the merge request back on Patch::review, along with https://gitlab.com/lilypond/lilypond/-/merge_requests/2170 for the documentation build. Then we could have a release next weekend or the one after. If next weekend, the first release in January might be a bit bigger, we'll have to see... > then remove automatic detection of Guile 2.2 from configure. I did not yet upload a merge request to make Guile 3.0 the default for all builds: After more thought, I believe it's better to do this together with the removal of automatic configure support for Guile 2.2, to avoid the situation where we assume that Guile 3.0 is the default, but building from source will gracefully configure with Guile 2.2, for example because the system is missing the development package for Guile 3.0... Jonas signature.asc Description: This is a digitally signed message part
Re: LilyPond 2.25.10 with Guile 3.0
On Thu, 2023-11-16 at 11:11 -0600, Karlin High wrote: > On Sun, Nov 12, 2023 at 6:26 AM Jonas Hahnfeld via LilyPond user > discussion wrote: > > If you have some time, please test them in your setups and report back in > > case of problems! > > Seems OK so far. Windows 11 21H2, Intel Core i5-1135G7. > > " > > lilypond.exe scheme-sandbox > GNU LilyPond 2.25.10 (running Guile 3.0) > Processing > `C:/Users/owner/AppData/Local/frescobaldi/frescobaldi/lilypond-binaries/lilypond-2.25.10/share/lilypond/2.25.10/ly/scheme-sandbox.ly' > Parsing... > GNU Guile 3.0.9 > " Great, thanks for testing! > When I run convert-ly, it makes version statements "2.25.9". I can't > remember if that is expected or not for the 2.25.10 binaries. No > warnings of outdated versions are given when compiling the results. Yes, that's expected because there were no conversion rules for 2.25.10 and convert-ly doesn't force-update the version number (unless -- current-version is passed). Jonas signature.asc Description: This is a digitally signed message part
Re: LilyPond 2.25.10 with Guile 3.0
On Sun, Nov 12, 2023 at 6:26 AM Jonas Hahnfeld via LilyPond user discussion wrote: > If you have some time, please test them in your setups and report back in > case of problems! Seems OK so far. Windows 11 21H2, Intel Core i5-1135G7. " >lilypond.exe scheme-sandbox GNU LilyPond 2.25.10 (running Guile 3.0) Processing `C:/Users/owner/AppData/Local/frescobaldi/frescobaldi/lilypond-binaries/lilypond-2.25.10/share/lilypond/2.25.10/ly/scheme-sandbox.ly' Parsing... GNU Guile 3.0.9 " When I run convert-ly, it makes version statements "2.25.9". I can't remember if that is expected or not for the 2.25.10 binaries. No warnings of outdated versions are given when compiling the results. -- Karlin High Missouri, USA
Re: LilyPond 2.25.10 with Guile 3.0
> “_” needs to be replaced with “G_”. Already in Guile 2, but Guile 3 checks for > it more eagerly. Fixed in LSR. signature.asc Description: This is a digitally signed message part
Re: LilyPond 2.25.10 with Guile 3.0
> Le 12 nov. 2023 à 19:14, Robin Bannister a écrit : > > If I take the code of LSR1098 [1] , without the demo part, > Guile3 errors the input-warning call: > > GNU LilyPond 2.25.10 (running Guile 3.0) > Processing `1.ly' > Parsing... > 1.ly:38:2: error: Guile signaled an error for the expression beginning here > # > (define-music-function (name-tweaks left-indent right-indent) > > Syntax error: > 1.ly:40:64: _: bad use of '_' syntactic keyword in subform (_ " pseudoIndents > ~s ~s is stretching staff; expect distorted layout") of (_ " pseudoIndents ~s > ~s is stretching staff; expect distorted layout") “_” needs to be replaced with “G_”. Already in Guile 2, but Guile 3 checks for it more eagerly.
Re: LilyPond 2.25.10 with Guile 3.0
Jonas Hahnfeld wrote: On Sat, 2023-11-11 at 19:37 +0100, Jonas Hahnfeld wrote: We are happy to announce the release of LilyPond 2.25.10. And here are the binaries with Guile 3.0, built using https://gitlab.com/lilypond/lilypond/-/merge_requests/2163 and https://gitlab.com/lilypond/lilypond/-/merge_requests/2170 : https://gitlab.com/lilypond/lilypond/-/packages/20197593 If you have some time, please test them in your setups and report back in case of problems! If I take the code of LSR1098 [1] , without the demo part, Guile3 errors the input-warning call: GNU LilyPond 2.25.10 (running Guile 3.0) Processing `1.ly' Parsing... 1.ly:38:2: error: Guile signaled an error for the expression beginning here # (define-music-function (name-tweaks left-indent right-indent) Syntax error: 1.ly:40:64: _: bad use of '_' syntactic keyword in subform (_ " pseudoIndents ~s ~s is stretching staff; expect distorted layout") of (_ " pseudoIndents ~s ~s is stretching staff; expect distorted layout") 1.ly:1: warning: no \version statement found, please add \version "2.25.10" for future compatibility fatal error: failed files: "1.ly" If I include the rest of the file, I get a lot more errors. [1] https://lsr.di.unimi.it/LSR/Item?id=1098 Cheers, Robin
LilyPond 2.25.10 with Guile 3.0
On Sat, 2023-11-11 at 19:37 +0100, Jonas Hahnfeld wrote: > We are happy to announce the release of LilyPond 2.25.10. And here are the binaries with Guile 3.0, built using https://gitlab.com/lilypond/lilypond/-/merge_requests/2163 and https://gitlab.com/lilypond/lilypond/-/merge_requests/2170 : https://gitlab.com/lilypond/lilypond/-/packages/20197593 If you have some time, please test them in your setups and report back in case of problems! Jonas signature.asc Description: This is a digitally signed message part
Re: [RFC] Transition to Guile 3.0
On Sat, 2023-11-11 at 18:37 +0100, Han-Wen Nienhuys wrote: > On Sun, Nov 5, 2023 at 10:36 PM Jonas Hahnfeld wrote: > > Hi all, > > > > I hear LilyPond hasn't changed its Guile version since some time (more > > than 18 months). So before we get too comfortable with the current > > situation, let me propose to move to Guile 3.0. Below is a plan for > > that switch, with a transition period to test the official binaries. > > Last time, when going from Guile 1.8 to version 2.2, the switch had to > > coincide with moving away from GUB. Between Guile 2.2 and 3.0, we could > > in principle support both versions for a longer period. However, I > > personally think that a full transition and dropping support for Guile > > 2.2 is the more reasonable approach: It will reduce testing > > configurations (both for development and user reports) and hopefully > > enable some future cleanups in the code. > > Could you say a bit more about the benefits/disadvantages for the user? > I had the impression that Guile 3 had different (worse?) performance > characteristics relative to 2.2, but it's been a while. As far as I can tell from my limited tests so far, LilyPond built against Guile 2.2 or 3.0 has similar speeds. At least if you have compiled bytecode (that generates faster with Guile 3.0, but that's not really an advantage for users). The build with Guile 3.0 seems to have a slightly lower startup time, which is good for small scores, but we will be able to test in full tomorrow when I build the other binaries. > IIRC, one of the arguments to drop 1.8 is that Guile pre-2.x did not > support installing multiple versions alongside each other, which forced > distributions to choose whether to ship LilyPond or a recent version of > Guile. With 2.2 and later, that dilemma disappeared. Not quite: While it's true that Guile 1.8 was not prepared to be co- installed with later versions, it worked in practice because Guile 2.0 had the necessary modifications. What happened instead is that Linux distributions wanted to get rid of Guile 1.8, and some did before LilyPond was able to fully work with Guile 2.2. The same is currently happening again, for example we had to do quite some convincing to keep Guile 2.2 in Debian 12 Bookworm released this summer. So IMHO we really want to support Guile 3.0; Jean already did the hard work here last year, up to the point that some already build LilyPond 2.24.x with Guile 3.0 right now. > I quickly grepped over the source (grepping for SCM_MAJOR_VERSION), > but the bifurcations look very modest. In principle yes, we could continue to support Guile 2.2 and it wouldn't cause too many issues at first. However, we know from experience that supporting two versions of Guile has a certain cost, and I think we are better off just supporting Guile 3.0 going forward. Jonas signature.asc Description: This is a digitally signed message part
Re: [RFC] Transition to Guile 3.0
On Sun, Nov 5, 2023 at 10:36 PM Jonas Hahnfeld via Discussions on LilyPond development wrote: > Hi all, > > I hear LilyPond hasn't changed its Guile version since some time (more > than 18 months). So before we get too comfortable with the current > situation, let me propose to move to Guile 3.0. Below is a plan for > that switch, with a transition period to test the official binaries. > Last time, when going from Guile 1.8 to version 2.2, the switch had to > coincide with moving away from GUB. Between Guile 2.2 and 3.0, we could > in principle support both versions for a longer period. However, I > personally think that a full transition and dropping support for Guile > 2.2 is the more reasonable approach: It will reduce testing > configurations (both for development and user reports) and hopefully > enable some future cleanups in the code. > Could you say a bit more about the benefits/disadvantages for the user? I had the impression that Guile 3 had different (worse?) performance characteristics relative to 2.2, but it's been a while. IIRC, one of the arguments to drop 1.8 is that Guile pre-2.x did not support installing multiple versions alongside each other, which forced distributions to choose whether to ship LilyPond or a recent version of Guile. With 2.2 and later, that dilemma disappeared. I quickly grepped over the source (grepping for SCM_MAJOR_VERSION), but the bifurcations look very modest. -- Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
Re: Plan for LilyPond 2.24.3 and Transition to Guile 3.0
>> Step 1: Officially support Guile 3.0 and add optional CI testing I >> opened https://gitlab.com/lilypond/lilypond/-/merge_requests/2162 >> to add some compatibility with earlier versions of Guile 3.0 and >> then implement detection support in configure. It also creates >> Docker images and adds optional CI testing, as we had it for the >> transition to Guile 2.2. > > The MR is nominally on countdown right now, do we have a consensus > on this? +1 from me. > Please ping me on other fixes that you think should be part of 2.24.3, Perhaps !2093, !2105, !2137 (if of relevance), and !2152. Werner
Plan for LilyPond 2.24.3 and Transition to Guile 3.0
On Sun, 2023-11-05 at 22:36 +0100, Jonas Hahnfeld wrote: > Step 1: Officially support Guile 3.0 and add optional CI testing > I opened https://gitlab.com/lilypond/lilypond/-/merge_requests/2162 to > add some compatibility with earlier versions of Guile 3.0 and then > implement detection support in configure. It also creates Docker images > and adds optional CI testing, as we had it for the transition to Guile > 2.2. The MR is nominally on countdown right now, do we have a consensus on this? I'm fully ok with delaying this, but then it will miss the next unstable release that I would like to do this weekend, and the backport to the stable version tentatively planned for the next weekend (see below). > Step 2a: Assuming this testing goes fine, I would like to backport the > changes from the first step to stable/2.24 and release a new stable > version. The idea is that distributions wanting to drop their package > for Guile 2.2 can switch LilyPond 2.24 to Guile 3.0. Note that the > official binaries will stay Guile 2.2 for future bug fix releases, it's > only about officially supporting the later version. However, we also > have to see how the situation develops with Ghostscript 10.02.1, so > let's postpone discussion on this topic for now... So https://gitlab.com/lilypond/lilypond/-/merge_requests/2160 seems to work now, and I think we should get this out in an unstable release (next weekend) and then a bug fix release the weekend after. For other bug fixes, I marked a number of merge requests with the Backport label: https://gitlab.com/lilypond/lilypond/-/merge_requests?scope=all=merged_name[]=Backport Please ping me on other fixes that you think should be part of 2.24.3, or any of the above that should not be backported. For the support of Guile 3.0, it depends on whether we merge it for 2.25.10 and if people think it should be backported. Cheers, Jonas signature.asc Description: This is a digitally signed message part
Re: [RFC] Transition to Guile 3.0
>> Please let me know of your comments! > > I'm very happy that you got Guile 3.0 working on Windows. Kudos for > that (and I guess we need to send big thanks to Mike Gran too). +1 > What I don't really understand is why you want to add compatibility > with Guile 3.0.x for small x. [...] I think what Jonas does is the right way – support for Guile 3 in general to accommodate with as many distributions as possible. Werner
Re: [RFC] Transition to Guile 3.0
Le lundi 06 novembre 2023 à 01:11 +0100, David Kastrup a écrit : > I have not checked recently, but last time I looked, Guile's versioning > system more or less worked so that the development branch (and the > corresponding versions) was Andy Wingo's playground. It was not > concerned with APIs in any manner. Any API development and > corresponding changes consequently had to be done in the stable branch > and eventually forwardported into the development branch. Currently, as far as I am aware, there is not even a development branch separate from the stable branch. The branch "main" receives all development and 3.0.x releases are simply cut from it. That's even worse for stability than the setup you describe. signature.asc Description: This is a digitally signed message part
Re: [RFC] Transition to Guile 3.0
Jean Abou Samra writes: > What I don't really understand is why you want to add compatibility > with Guile 3.0.x for small x. Upstream completely breaks the normal > expectation from what you would find in a point release, by putting > features and even severely backwards incompatible changes (like > cross-module inlining in 3.0.8 *cough*), so I think this is definitely > going to be more work to keep supporting (in particular: testing) than > with dependencies that don't have this peculiarity. I'd rather define > a minimum version in the 3.0.x series that we want to support. I have not checked recently, but last time I looked, Guile's versioning system more or less worked so that the development branch (and the corresponding versions) was Andy Wingo's playground. It was not concerned with APIs in any manner. Any API development and corresponding changes consequently had to be done in the stable branch and eventually forwardported into the development branch. If that is still how things are done, the kind of feature/API stability we can depend on from distributions based on how much they can depend on being able to rely on version numbers for stability choices is limited. We use Guile as infrastructure, not as a Scheme hacking playground. But while Guile is historically sold as infrastructure, its community setup does not accommodate it. And for resolving that mess, we as the likely most competent party with an interest in that mess will be tasked with the consequences, for better or worse. -- David Kastrup
Re: [RFC] Transition to Guile 3.0
On Sun, 2023-11-05 at 22:48 +0100, Jean Abou Samra wrote: > What I don't really understand is why you want to add compatibility > with Guile 3.0.x for small x. Upstream completely breaks the normal > expectation from what you would find in a point release, by putting > features and even severely backwards incompatible changes (like > cross-module inlining in 3.0.8 *cough*), so I think this is definitely > going to be more work to keep supporting (in particular: testing) than > with dependencies that don't have this peculiarity. I'd rather define > a minimum version in the 3.0.x series that we want to support. Sure, but that is currently defined by Ubuntu 20.04 having Guile 3.0.1. We could of course move "Step 5" earlier in the process, but then I argue we still need to pay attention to what versions of Guile are in the wild, the next one probably being Guile 3.0.5 in Debian Bullseye... signature.asc Description: This is a digitally signed message part
Re: [RFC] Transition to Guile 3.0
Le dimanche 05 novembre 2023 à 22:36 +0100, Jonas Hahnfeld via Discussions on LilyPond development a écrit : > Please let me know of your comments! I'm very happy that you got Guile 3.0 working on Windows. Kudos for that (and I guess we need to send big thanks to Mike Gran too). What I don't really understand is why you want to add compatibility with Guile 3.0.x for small x. Upstream completely breaks the normal expectation from what you would find in a point release, by putting features and even severely backwards incompatible changes (like cross-module inlining in 3.0.8 *cough*), so I think this is definitely going to be more work to keep supporting (in particular: testing) than with dependencies that don't have this peculiarity. I'd rather define a minimum version in the 3.0.x series that we want to support. Jean signature.asc Description: This is a digitally signed message part
[RFC] Transition to Guile 3.0
Hi all, I hear LilyPond hasn't changed its Guile version since some time (more than 18 months). So before we get too comfortable with the current situation, let me propose to move to Guile 3.0. Below is a plan for that switch, with a transition period to test the official binaries. Last time, when going from Guile 1.8 to version 2.2, the switch had to coincide with moving away from GUB. Between Guile 2.2 and 3.0, we could in principle support both versions for a longer period. However, I personally think that a full transition and dropping support for Guile 2.2 is the more reasonable approach: It will reduce testing configurations (both for development and user reports) and hopefully enable some future cleanups in the code. Step 1: Officially support Guile 3.0 and add optional CI testing I opened https://gitlab.com/lilypond/lilypond/-/merge_requests/2162 to add some compatibility with earlier versions of Guile 3.0 and then implement detection support in configure. It also creates Docker images and adds optional CI testing, as we had it for the transition to Guile 2.2. Step 2: Release unstable version and test new binaries https://gitlab.com/lilypond/lilypond/-/merge_requests/2163 has the changes to produce official binaries with Guile 3.0(.9). For Windows, it currently relies on a number of patches that I also sent upstream. In some sense, the situation is not worse than Guile 2.2 where we also had patches. Or arguably it is better because there is the possibility that the changes will be merged upstream... I propose to not merge the changes for our binaries immediately, but instead produce an additional set of binaries with the next unstable release. That way, users can test on all platforms and make sure the setup works. Again, this is similar to what we had in LilyPond 2.23.6 when switching to Guile 2.2. Step 2a: Assuming this testing goes fine, I would like to backport the changes from the first step to stable/2.24 and release a new stable version. The idea is that distributions wanting to drop their package for Guile 2.2 can switch LilyPond 2.24 to Guile 3.0. Note that the official binaries will stay Guile 2.2 for future bug fix releases, it's only about officially supporting the later version. However, we also have to see how the situation develops with Ghostscript 10.02.1, so let's postpone discussion on this topic for now... Step 3: Switch to Guile 3.0 Afterwards, we can merge https://gitlab.com/lilypond/lilypond/-/merge_requests/2163 and then remove automatic detection of Guile 2.2 from configure. It would still be possible to build LilyPond with GUILE_FLAVOR=guile-2.2 for some limited time, until ... Step 4: Remove compatibility code for Guile 2.2 This can happen after we made one or two releases with only Guile 3.0. Step 5? Move to Ubuntu 22.04 for testing and bump requirement to Guile 3.0.7? Then we could remove some more compatibility code, but let's discuss this at some later point. Please let me know of your comments! Jonas signature.asc Description: This is a digitally signed message part
Re: Guile 3.0
Le 23/05/2022 à 23:00, Wol a écrit : On 23/05/2022 20:19, Han-Wen Nienhuys wrote: Vendoring Guile seems totally impractical. The Guile compilation does some sort of bootstrapping, which makes building it from scratch glacially slow (like: O(1 hour)), so it would be impossible for day to day development work. Just an idea, if "current" Guile has issues - could you just vendor Guile in the stable release? As said above, current Guile has issues, but not issues that are very pressing for us. That way at least you're not committed to supporting old Guiles indefinitely, but you can create a temporary fork to get a working release out the door ... The binary creation system actually builds dependencies in an isolated environment and supports applying patches to them. Jean
Re: Guile 3.0
Wol writes: > On 23/05/2022 20:19, Han-Wen Nienhuys wrote: >> Vendoring Guile seems totally impractical. The Guile compilation does >> some sort of bootstrapping, which makes building it from scratch >> glacially slow (like: O(1 hour)), so it would be impossible for day to >> day development work. > > Just an idea, if "current" Guile has issues - could you just vendor > Guile in the stable release? Well, Guile upstream has a strange notion of what "stable release" is supposed to mean, so in effect one would have to create one's own "stable release" and cherry-pick actual fixes instead of the entirety of what is stable more in the Augeas sense. -- David Kastrup
Re: Guile 3.0
On 23/05/2022 20:19, Han-Wen Nienhuys wrote: Vendoring Guile seems totally impractical. The Guile compilation does some sort of bootstrapping, which makes building it from scratch glacially slow (like: O(1 hour)), so it would be impossible for day to day development work. Just an idea, if "current" Guile has issues - could you just vendor Guile in the stable release? That way at least you're not committed to supporting old Guiles indefinitely, but you can create a temporary fork to get a working release out the door ... (And I run gentoo, so if Guile takes an hour to build - well so be it. Whenever Rust, Firefo or Thunderbird update I'm looking at all day for an update to complete :-) Cheers, Wol
Re: Guile 3.0
On Mon, May 23, 2022 at 9:19 PM Han-Wen Nienhuys wrote:
> I'm missing the context for this proposal.
>
Something in the original thread from Jonas made me think some distros were
wrangling keeping up distributing
guile only for lilypond's benefit. It's possible I misunderstood and he
actually meant that just regarding v 1.8, and that 2.2.x would be available
even without lilypond. But the question remains for a time when they'd like
to not ship 2.2.x and we're not ready to move to 3.x.y.
I do realize neither is very likely and I know Jean showed we work just
fine with 3.0.8, actually there are certain advantages there,
if you squint at it just the right way.
That led me to think that if guile is such a rare dependency, we wouldn't
want lilypond to be held ransom, you see.
The other half of the thought was a response to Jean's frustration of
feeling unable to land a simple bugfix into the guile project:
I'm sensitive to that, it's a kind of behaviour that gives me a hard time
too.
> Shipping dependencies ("vendoring") can be very useful, because it
> reduces the combinatorial space of version combinations that you have
> to support. Ghostscript does this with a lot of its dependencies (for
> example, libpng, IIRC)
>
Yes, I thought to us there would be the added advantage of being able to
apply a small set of fixes,
while we wait for mainline to mop them up. If that while is a time period
measured in lustra, I thought this could help us stay fresh
Jean expressed the hope to instead find a way to help the guile project
kick back into some kind of gear,
which if achievable I would agree would be a substantially better outcome
> Vendoring Guile seems totally impractical. The Guile compilation does
> some sort of bootstrapping, which makes building it from scratch
> glacially slow (like: O(1 hour)), so it would be impossible for day to
> day development work.
>
Yes, somebody else was saying the same, maybe Jean?
I wasn't aware of that, I had just casually browse the repo, where the C
part doesn't look big,
and assumed it was just about standing that up.
It occurs to me recompiling guile without a change in guile itself wouldn't
happen very often,
it'd still be set up as an external library as seen by the lilypond repo's
pov, so maybe
this is not the first concern for developers, but it'd certainly be
annoying for maintainers
and CI, both of which I completely agree would be undesirable burdens.
Cheers,
L
--
Luca Fascione
Re: Guile 3.0
On Sun, May 22, 2022 at 7:48 PM Luca Fascione wrote:
> I would like to bring up an option that I'd expect fair few of you will
> _really_ not like.
> I'm doing this not because I necessarily believe it to be a
> particularly good way forward,
> rather because I feel it is sometimes useful to articulate in words why an
> "obviously awful idea" is, in fact, awful. Or maybe it isn't
I'm missing the context for this proposal. However, here is my $0.02:
Shipping dependencies ("vendoring") can be very useful, because it
reduces the combinatorial space of version combinations that you have
to support. Ghostscript does this with a lot of its dependencies (for
example, libpng, IIRC)
Vendoring Guile seems totally impractical. The Guile compilation does
some sort of bootstrapping, which makes building it from scratch
glacially slow (like: O(1 hour)), so it would be impossible for day to
day development work.
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
Re: Guile 3.0
This also makes a lot of sense to me, yes. L On Mon, 23 May 2022, 13:12 Jean Abou Samra, wrote: > > > Le 22/05/2022 à 21:52, Luca Fascione a écrit : > > > > On Sun, May 22, 2022 at 9:05 PM Jonas Hahnfeld wrote: > > > > On Sun, 2022-05-22 at 20:14 +0200, Luca Fascione wrote: > > > So at the cost of rocking the cage a bit hard, I came asking the > > > uncomfortable question: > > > what would happen if (for this unique circumstance) we'd do what > one > > > would normally consider poor practice? > > > > Let's call your proposal by its true, scary name: we would > essentially > > *fork* Guile and, in the longer term, make it fit exactly what we > need > > for LilyPond. > > > > > > Well, I was not thinking the delta between "true" Guile and "ours" > > would ever get big. > > If it did, that is what I'd call a fork. And no, I'm _not_ advocating > > that. > > > > I'm more thinking something along the lines of make 3.81, actually: > > largely "mainline", > > plus a few small patches to adjust little details. (*) > > > > It's clear that a real fork is not useful here, I agree with you > > completely > > (*) 3.81 is famously incompatible with 3.82, and many large make > > systems are stuck in .81 land. > > So it's common for folks in that condition to build their own make > > applying a few (3? maybe 4) small > > patches to fix a few problems with the program instead. Effectively > > they run some kind of 3.81+ > > > > The second implication is that we get technologically stuck. > > > > > > Well, the idea is that much like now you'd state a dependency against > > Guile 2.2.x, > > you would then just ship the version you want. I don't see much of a > > difference there. > > (Again, the key in mind is that the changes from us are a _small_ set, > > so the fact that > > we would on occasion change the base checkout and reapply the diffs > > should be a > > small overhead. If you compound this with changed built to maximize > > the chances of > > eventual adoption, you'd risk eventually getting into a place where > > these changes are zero) > > > > With all that said, I think there are good reasons why things are > > considered bad practice. > > > > > > There were what felt like good reasons at the time when the practices > > were established, yes. > > > > However, as the hypotheses mutate, it can come a point where the > > conclusions don't follow any longer. > > > > For example: > > one doesn't want to fork because > > - it duplicates code and it's difficult to keep up the two diverged > > branches > > -> with RCS _definitely_, with git I'm not so sure. Space cost of > > duplication these days is zero. Time taken compiling one more repo, > > also zero. > > -> this means that now this part of the reason is reduced to > > understanding whether the divergence is large or small > > > > I've seen things that were bad practice when I was a student become > > acceptable or recommended now. > > I've come to see that "old wisdom" is sometimes not that wise after > > all (premature optimization for example, > > although in that case that's more an issue of misunderstanding of the > > original meaning, than actual change). > > > > Similar discussions have already taken place > > before, and I'm not sure if we're adding value by repeating them. > > Maybe > > we can come back to the original topic of this thread? > > > > > > Forgive me for making poor use of your and the others' time. > > I thought this might turn out to be pertinent if it opened up new ways > > of thinking about this choice. > > > > I might have introduced confusion with the mention of the bug > with source locations. In the specific case of LilyPond, this > bug is not very important. Almost all the warnings Guile gives > are pure noise in our case anyway (I haven't taken the time to > prepare an MR for silencing them yet). It was to illustrate the > fact that there can be serious bugs in Guile, and one could > well affect us. > > Apart from that, including the Guile sources in our tree and > building with them is something I would only do in a desperate > situation, e.g. Guile introducing changes that are fundamentally > incompatible with LilyPond's use case. It will be a nuisance > not to be able to use a Guile from the system since Guile these > days is quite slow to build. (The C code compiles fast, > but there is a whole bootstrap sequence to generate Scheme > compilers from Scheme code, which takes a lot of time.) > It will require synchronization with upstream if that is > desired. Also, while upstream isn't really active, they > do keep it at least building which is already something. > Rather, if it becomes clear that Guile is stuck, it would be > more reasonable to create a fork of Guile separate from LilyPond, > put it in a repository somewhere, invite the folks from guile-devel > who'd appreciate commit access on Guile but don't have it to > hack on it, advertise it for distros,
Re: Guile 3.0
Le 22/05/2022 à 21:52, Luca Fascione a écrit : On Sun, May 22, 2022 at 9:05 PM Jonas Hahnfeld wrote: On Sun, 2022-05-22 at 20:14 +0200, Luca Fascione wrote: > So at the cost of rocking the cage a bit hard, I came asking the > uncomfortable question: > what would happen if (for this unique circumstance) we'd do what one > would normally consider poor practice? Let's call your proposal by its true, scary name: we would essentially *fork* Guile and, in the longer term, make it fit exactly what we need for LilyPond. Well, I was not thinking the delta between "true" Guile and "ours" would ever get big. If it did, that is what I'd call a fork. And no, I'm _not_ advocating that. I'm more thinking something along the lines of make 3.81, actually: largely "mainline", plus a few small patches to adjust little details. (*) It's clear that a real fork is not useful here, I agree with you completely (*) 3.81 is famously incompatible with 3.82, and many large make systems are stuck in .81 land. So it's common for folks in that condition to build their own make applying a few (3? maybe 4) small patches to fix a few problems with the program instead. Effectively they run some kind of 3.81+ The second implication is that we get technologically stuck. Well, the idea is that much like now you'd state a dependency against Guile 2.2.x, you would then just ship the version you want. I don't see much of a difference there. (Again, the key in mind is that the changes from us are a _small_ set, so the fact that we would on occasion change the base checkout and reapply the diffs should be a small overhead. If you compound this with changed built to maximize the chances of eventual adoption, you'd risk eventually getting into a place where these changes are zero) With all that said, I think there are good reasons why things are considered bad practice. There were what felt like good reasons at the time when the practices were established, yes. However, as the hypotheses mutate, it can come a point where the conclusions don't follow any longer. For example: one doesn't want to fork because - it duplicates code and it's difficult to keep up the two diverged branches -> with RCS _definitely_, with git I'm not so sure. Space cost of duplication these days is zero. Time taken compiling one more repo, also zero. -> this means that now this part of the reason is reduced to understanding whether the divergence is large or small I've seen things that were bad practice when I was a student become acceptable or recommended now. I've come to see that "old wisdom" is sometimes not that wise after all (premature optimization for example, although in that case that's more an issue of misunderstanding of the original meaning, than actual change). Similar discussions have already taken place before, and I'm not sure if we're adding value by repeating them. Maybe we can come back to the original topic of this thread? Forgive me for making poor use of your and the others' time. I thought this might turn out to be pertinent if it opened up new ways of thinking about this choice. I might have introduced confusion with the mention of the bug with source locations. In the specific case of LilyPond, this bug is not very important. Almost all the warnings Guile gives are pure noise in our case anyway (I haven't taken the time to prepare an MR for silencing them yet). It was to illustrate the fact that there can be serious bugs in Guile, and one could well affect us. Apart from that, including the Guile sources in our tree and building with them is something I would only do in a desperate situation, e.g. Guile introducing changes that are fundamentally incompatible with LilyPond's use case. It will be a nuisance not to be able to use a Guile from the system since Guile these days is quite slow to build. (The C code compiles fast, but there is a whole bootstrap sequence to generate Scheme compilers from Scheme code, which takes a lot of time.) It will require synchronization with upstream if that is desired. Also, while upstream isn't really active, they do keep it at least building which is already something. Rather, if it becomes clear that Guile is stuck, it would be more reasonable to create a fork of Guile separate from LilyPond, put it in a repository somewhere, invite the folks from guile-devel who'd appreciate commit access on Guile but don't have it to hack on it, advertise it for distros, apply patches from the tracker, and try to either get upstream to realize its model is not working and change it, or to make that a new Guile with a community around it that can survive for the decades to come. If we get a need to fork Guile (I don't see a pressing need at the moment now that we are on Guile 2/3), let's not do it in isolation. Jean
Re: Guile 3.0
On Sun, May 22, 2022 at 9:05 PM Jonas Hahnfeld wrote: > On Sun, 2022-05-22 at 20:14 +0200, Luca Fascione wrote: > > So at the cost of rocking the cage a bit hard, I came asking the > > uncomfortable question: > > what would happen if (for this unique circumstance) we'd do what one > > would normally consider poor practice? > > Let's call your proposal by its true, scary name: we would essentially > *fork* Guile and, in the longer term, make it fit exactly what we need > for LilyPond. Well, I was not thinking the delta between "true" Guile and "ours" would ever get big. If it did, that is what I'd call a fork. And no, I'm _not_ advocating that. I'm more thinking something along the lines of make 3.81, actually: largely "mainline", plus a few small patches to adjust little details. (*) It's clear that a real fork is not useful here, I agree with you completely (*) 3.81 is famously incompatible with 3.82, and many large make systems are stuck in .81 land. So it's common for folks in that condition to build their own make applying a few (3? maybe 4) small patches to fix a few problems with the program instead. Effectively they run some kind of 3.81+ The second implication is that we get technologically stuck. Well, the idea is that much like now you'd state a dependency against Guile 2.2.x, you would then just ship the version you want. I don't see much of a difference there. (Again, the key in mind is that the changes from us are a _small_ set, so the fact that we would on occasion change the base checkout and reapply the diffs should be a small overhead. If you compound this with changed built to maximize the chances of eventual adoption, you'd risk eventually getting into a place where these changes are zero) > With all that said, I think there are good reasons why things are > considered bad practice. There were what felt like good reasons at the time when the practices were established, yes. However, as the hypotheses mutate, it can come a point where the conclusions don't follow any longer. For example: one doesn't want to fork because - it duplicates code and it's difficult to keep up the two diverged branches -> with RCS _definitely_, with git I'm not so sure. Space cost of duplication these days is zero. Time taken compiling one more repo, also zero. -> this means that now this part of the reason is reduced to understanding whether the divergence is large or small I've seen things that were bad practice when I was a student become acceptable or recommended now. I've come to see that "old wisdom" is sometimes not that wise after all (premature optimization for example, although in that case that's more an issue of misunderstanding of the original meaning, than actual change). > Similar discussions have already taken place > before, and I'm not sure if we're adding value by repeating them. Maybe > we can come back to the original topic of this thread? > Forgive me for making poor use of your and the others' time. I thought this might turn out to be pertinent if it opened up new ways of thinking about this choice. L -- Luca Fascione
Re: Guile 3.0
On Sun, 2022-05-22 at 20:14 +0200, Luca Fascione wrote: > So at the cost of rocking the cage a bit hard, I came asking the > uncomfortable question: > what would happen if (for this unique circumstance) we'd do what one > would normally consider poor practice? Let's call your proposal by its true, scary name: we would essentially *fork* Guile and, in the longer term, make it fit exactly what we need for LilyPond. This has a bunch of implications, one of which is that we take on the burden of maintaining that forked version. If you don't believe that will cause problems, I would just like to remind you that Guile 1.8 was fundamentally incompatible with 64-bit Windows. Nobody can foresee what will be the next problem; maybe there are none but I would doubt it; but any time spent on the maintenance of a fork is already too much in my eyes for a community that is comparably small. The second implication is that we get technologically stuck. As bad as the current situation is, it has given incentive to move on. For example, I'm thinking of Han-Wen's work on the structure of output backends that was originally meant to reduce the penalty with Guile 2.2 but in the end resulted in a net improvement overall. And after dropping support Guile 1.8 (and lots of related code!), Jean is already making good use of some of the new constructs. There are probably other parts that work around deficiencies in Guile 1.8 which could be cleaned up now (just search for "crazy bug" in scm/output-lib.scm). With all that said, I think there are good reasons why things are considered bad practice. Similar discussions have already taken place before, and I'm not sure if we're adding value by repeating them. Maybe we can come back to the original topic of this thread? Jonas signature.asc Description: This is a digitally signed message part
Re: Guile 3.0
On Sun, May 22, 2022 at 8:02 PM David Kastrup wrote: > What do you mean with "shipped"? I mean that when you clone the lilypond repo you'd find one more directory, say guile-2.2.7+/ or guile-3.0.8+/ or something like that. In fact we'd likely end up compiling a slightly different version thereof, as I was saying, because we'd apply a patch or two before building > I don't > think it makes sense with stuff that is supposed to be up to date with > current versions. > I would normally definitely agree with you if these two conditions were met: - the project was evolving at a non-geologic speed - there was evidence that if we encountered a problem, they would assist us I mean: the guile subsystem is the heart of lilypond, being held ransom (or rather, completely ignored) by a group of people that seems to show no interest in our issues is not what I'd considered a strategy of growth and fruitful collaboration. Besides: you say "current" version, but we're in this thread exactly because we can't, in fact, use the current version. (By a mile, I think the only one that works well is 2.2.7, right?) This hodgerypockery would at least give us true current, but we'd have to patch it, then again we'd be in a position where we _can_ patch it. So at the cost of rocking the cage a bit hard, I came asking the uncomfortable question: what would happen if (for this unique circumstance) we'd do what one would normally consider poor practice? L -- Luca Fascione
Re: Guile 3.0
Luca Fascione writes: > I would like to bring up an option that I'd expect fair few of you will > _really_ not like. > I'm doing this not because I necessarily believe it to be a > particularly good way forward, > rather because I feel it is sometimes useful to articulate in words why an > "obviously awful idea" is, in fact, awful. Or maybe it isn't > > So here it goes: what if we shipped the guile source? (I mean, in a > subdirectory of lilypond's source) What do you mean with "shipped"? In the repository (which is not what we ship)? That would have made some sense with Guile 1.8. I don't think it makes sense with stuff that is supposed to be up to date with current versions. -- David Kastrup
Re: Guile 3.0
I would like to bring up an option that I'd expect fair few of you will _really_ not like. I'm doing this not because I necessarily believe it to be a particularly good way forward, rather because I feel it is sometimes useful to articulate in words why an "obviously awful idea" is, in fact, awful. Or maybe it isn't So here it goes: what if we shipped the guile source? (I mean, in a subdirectory of lilypond's source) At a quick look, it doesn't seem to be particularly hard to build (comparatively speaking), and its dependencies are mostly fairly benign stuff that appear to be runtime dependencies anyways (like libgc and such, point being, you need to install all that when you install guile anyways; if I read it right only 'gnu-sed' is a compile-only dependency). One benefit I see is that we could ship it as vX.Y.X + a single patch, so that it fundamentally documents what we've done to it (albeit git history could also serve this purpose). As an example, it seems to me that for 3.0.8 we'd want Jean's patch about the line number reporting in errors, and I recall a discussion about storing precompiled scripts that at that point we might consider fixing in the guile source ourselves. I am confused in this second whether this compiled scripts issue is problematic in 2.2.x also or not. I'm saying this because it seems to me that, different from python, there's no real collaboration/interaction between the guile installed on one's system and the interpreter inside lilypond, and this would completely decouple us from the rest of the distribution's concerns about which version of guile to ship (and seen some distro use lilypond as an element of deciding the version it's possible they wouldn't ship it at all if it wasn't for lilypond?) Of course I'm seeing this as a possibly viable "lesser evil" kinda approach only because the evidence we have is that the project activity is minimal and their interest in addressing our needs (as exemplified by the post Jean's shared) is also near-zero. Which implies: we unblock ourselves without taking on this huge burden of staying caught-up with the upstream (and as an added "bonus" we also can decide to apply someone else's patches should they fix a problem we have) L On Sun, May 22, 2022 at 5:42 PM David Kastrup wrote: > Jean Abou Samra writes: > > > Le 22/05/2022 à 17:04, David Kastrup a écrit : > >> [...] > >>> Also see > >>> > >>> guile$ git shortlog -ns --since="2 months ago" > >>> 2 Timothy Sample > >>> 1 Ludovic Courtès > >>> 1 Mikael Djurfeldt > >> Well, it's the stable release branch. > > > > > > What would be the development branch? > > > > $ git branch --show-current > > main > > $ git shortlog -ns v3.0.8..HEAD > > 6 Ludovic Courtès > > 2 Timothy Sample > > 1 Andy Wingo > > 1 Mikael Djurfeldt > > 1 Rob Browning > > 1 Sergei Trofimovich > > 1 Vijay Marupudi > > I am not in control of Guile's development models or lack thereof. I > simply reported the information on their website that distributors would > go by. > > >> [...] > >> No, Guile is in trouble then. I mean, it is in trouble now. But if > >> distributors can easily do version-hopping on their own initiative and > >> end up with one version of Guile they are going to ship for their whole > >> distro, it would be good if that does not end up in making LilyPond > >> disappear. That's all. > >> > >> What we _recommend_ and use ourselves is an entirely different matter. > > > > > > OK, but in that case, what is your request concretely? > > Current LilyPond master works with Guile 3.0. > > That's essentially all. I wasn't sure of that from the discussion and > from what I remembered from previous exchanges. > > > Do you want to add it to the CI? > > I am afraid that I am not tracking the development of Guile and the CI > resources of LilyPond well enough to venture any opinion that would be > more qualified than that of the current developers. > > -- > David Kastrup > > -- Luca Fascione
Re: Guile 3.0
Jean Abou Samra writes: > Le 22/05/2022 à 17:04, David Kastrup a écrit : >> [...] >>> Also see >>> >>> guile$ git shortlog -ns --since="2 months ago" >>> 2 Timothy Sample >>> 1 Ludovic Courtès >>> 1 Mikael Djurfeldt >> Well, it's the stable release branch. > > > What would be the development branch? > > $ git branch --show-current > main > $ git shortlog -ns v3.0.8..HEAD > 6 Ludovic Courtès > 2 Timothy Sample > 1 Andy Wingo > 1 Mikael Djurfeldt > 1 Rob Browning > 1 Sergei Trofimovich > 1 Vijay Marupudi I am not in control of Guile's development models or lack thereof. I simply reported the information on their website that distributors would go by. >> [...] >> No, Guile is in trouble then. I mean, it is in trouble now. But if >> distributors can easily do version-hopping on their own initiative and >> end up with one version of Guile they are going to ship for their whole >> distro, it would be good if that does not end up in making LilyPond >> disappear. That's all. >> >> What we _recommend_ and use ourselves is an entirely different matter. > > > OK, but in that case, what is your request concretely? > Current LilyPond master works with Guile 3.0. That's essentially all. I wasn't sure of that from the discussion and from what I remembered from previous exchanges. > Do you want to add it to the CI? I am afraid that I am not tracking the development of Guile and the CI resources of LilyPond well enough to venture any opinion that would be more qualified than that of the current developers. -- David Kastrup
Guile 3.0 (was: Thinking about the next stable release)
Le 22/05/2022 à 17:04, David Kastrup a écrit : [...] Also see guile$ git shortlog -ns --since="2 months ago" 2 Timothy Sample 1 Ludovic Courtès 1 Mikael Djurfeldt Well, it's the stable release branch. What would be the development branch? $ git branch --show-current main $ git shortlog -ns v3.0.8..HEAD 6 Ludovic Courtès 2 Timothy Sample 1 Andy Wingo 1 Mikael Djurfeldt 1 Rob Browning 1 Sergei Trofimovich 1 Vijay Marupudi [...] No, Guile is in trouble then. I mean, it is in trouble now. But if distributors can easily do version-hopping on their own initiative and end up with one version of Guile they are going to ship for their whole distro, it would be good if that does not end up in making LilyPond disappear. That's all. What we _recommend_ and use ourselves is an entirely different matter. OK, but in that case, what is your request concretely? Current LilyPond master works with Guile 3.0. Do you want to add it to the CI? Jean
Re: guile-3.0 and LilyPond - here: /input/regression/context-defaultchild-cycle.ly fails
Thomas Morley writes:
> Am Mi., 22. Jan. 2020 um 00:59 Uhr schrieb David Kastrup :
>>
>>
>> #(ly:set-option 'warning-as-error #t)
>> %% not sure why these warnings appear twice [dfe]
>> -#(ly:expect-warning (_ "default child context begins a cycle: `~a'") 'Score)
>> -#(ly:expect-warning (_ "cannot find or create new `~a'") 'Bottom)
>> -#(ly:expect-warning (_ "default child context begins a cycle: `~a'") 'Score)
>> -#(ly:expect-warning (_ "cannot find or create new `~a'") 'Bottom)
>> +#(ly:expect-warning (_ "default child context begins a cycle: ~a") 'Score)
>> +#(ly:expect-warning (_ "cannot find or create context: ~a") 'Bottom)
>> +#(ly:expect-warning (_ "default child context begins a cycle: ~a") 'Score)
>> +#(ly:expect-warning (_ "cannot find or create context: ~a") 'Bottom)
>>
>> \header {
>>texidoc = "A @code{\\defaultchild} cycle does not induce an endless loop.
>
> Got it, many thanks
>
>>
>> So why is that patch not in your
>> input/regression/context-defaultchild-cycle ?
>
> Obviously I patched this regtest (to reflect new guile-3 shortcut of
> gettext), _before_ Dan corrected it.
> And prefered my patch during solving the merge-conflict, without
> noticing the correction.
Ah right, that gettext thing. Forgot about that.
--
David Kastrup
Re: guile-3.0 and LilyPond - here: /input/regression/context-defaultchild-cycle.ly fails
Am Mi., 22. Jan. 2020 um 00:59 Uhr schrieb David Kastrup :
>
> Thomas Morley writes:
>
> > Hi,
> >
> > some remarks:
> >
> > Guile-3.0
> > First I compiled successfully guile-master from their repo, giving GNU
> > Guile 3.0.0.6-f3298
> > Trying to compile LilyPond with that guile (ofcourse adding a bunch of
> > patches) I had some problems pointing configure to the correct guile
> > and guile-config to the correct places. This was due to my setup with
> > too many guile-versions around. So I did some clean up.
> >
> > LilyPond
> > Afterwards I've got a successful ´make´ with current LilyPond-master.
> > ´make LANGS='' doc´ failed, though.
> >
> > The problem is /input/regression/context-defaultchild-cycle.ly
> > I do not understand how this regtest survives any compilation.
> > It contains
> > #(ly:set-option 'warning-as-error #t)
> > and some
> > #(ly:expect-warning ...)
> > If I compile it, separetly I always get warnings (after disabling
> > 'warning-as-error )
> > warning: default child context begins a cycle: Score
> > warning: cannot find or create context: Bottom
> > warning: default child context begins a cycle: Score
> > warning: cannot find or create context: Bottom
> > warning: 4 expected warning(s) not encountered:
> > default child context begins a cycle: `Score'
> > cannot find or create new `Bottom'
> > default child context begins a cycle: `Score'
> > cannot find or create new `Bottom'
> >
> > As far as I understand it errors always.
>
> commit 51b6513eeeaea69293bd4f554f8021529ae85a49
> Author: Dan Eble
> Date: Mon Jul 2 13:36:48 2018 -0400
>
> Issue 5366: Move warnings out of find/create context functions
>
> The motivation for this is that Context::find_create_context () and
> find_context_near () should probably be merged for maintainability,
> but one of the differences between them that must be dealt with is
> that find_create_context () logs when it fails and find_context_near
> () does not. Adding warnings to find_context_near () risks being too
> noisy, leaving the option taken here.
>
> The new method Context::diagnostic_id (name, id) returns a formatted
> string (e.g. "Voice" or "Voice = mel") for use in a log message. It
> is used for the warnings that are being moved as well as a few other
> existing warnings to increase consistency.
>
> diff --git a/input/regression/context-defaultchild-cycle.ly
> b/input/regression/context-defaultchild-cycle.ly
> index f62532f8bb..46de604dfd 100644
> --- a/input/regression/context-defaultchild-cycle.ly
> +++ b/input/regression/context-defaultchild-cycle.ly
> @@ -2,10 +2,10 @@
>
> #(ly:set-option 'warning-as-error #t)
> %% not sure why these warnings appear twice [dfe]
> -#(ly:expect-warning (_ "default child context begins a cycle: `~a'") 'Score)
> -#(ly:expect-warning (_ "cannot find or create new `~a'") 'Bottom)
> -#(ly:expect-warning (_ "default child context begins a cycle: `~a'") 'Score)
> -#(ly:expect-warning (_ "cannot find or create new `~a'") 'Bottom)
> +#(ly:expect-warning (_ "default child context begins a cycle: ~a") 'Score)
> +#(ly:expect-warning (_ "cannot find or create context: ~a") 'Bottom)
> +#(ly:expect-warning (_ "default child context begins a cycle: ~a") 'Score)
> +#(ly:expect-warning (_ "cannot find or create context: ~a") 'Bottom)
>
> \header {
>texidoc = "A @code{\\defaultchild} cycle does not induce an endless loop.
Got it, many thanks
>
> So why is that patch not in your
> input/regression/context-defaultchild-cycle ?
Obviously I patched this regtest (to reflect new guile-3 shortcut of
gettext), _before_ Dan corrected it.
And prefered my patch during solving the merge-conflict, without
noticing the correction.
Thanks,
Harm
Re: guile-3.0 and LilyPond - here: /input/regression/context-defaultchild-cycle.ly fails
Thomas Morley writes:
> Hi,
>
> some remarks:
>
> Guile-3.0
> First I compiled successfully guile-master from their repo, giving GNU
> Guile 3.0.0.6-f3298
> Trying to compile LilyPond with that guile (ofcourse adding a bunch of
> patches) I had some problems pointing configure to the correct guile
> and guile-config to the correct places. This was due to my setup with
> too many guile-versions around. So I did some clean up.
>
> LilyPond
> Afterwards I've got a successful ´make´ with current LilyPond-master.
> ´make LANGS='' doc´ failed, though.
>
> The problem is /input/regression/context-defaultchild-cycle.ly
> I do not understand how this regtest survives any compilation.
> It contains
> #(ly:set-option 'warning-as-error #t)
> and some
> #(ly:expect-warning ...)
> If I compile it, separetly I always get warnings (after disabling
> 'warning-as-error )
> warning: default child context begins a cycle: Score
> warning: cannot find or create context: Bottom
> warning: default child context begins a cycle: Score
> warning: cannot find or create context: Bottom
> warning: 4 expected warning(s) not encountered:
> default child context begins a cycle: `Score'
> cannot find or create new `Bottom'
> default child context begins a cycle: `Score'
> cannot find or create new `Bottom'
>
> As far as I understand it errors always.
commit 51b6513eeeaea69293bd4f554f8021529ae85a49
Author: Dan Eble
Date: Mon Jul 2 13:36:48 2018 -0400
Issue 5366: Move warnings out of find/create context functions
The motivation for this is that Context::find_create_context () and
find_context_near () should probably be merged for maintainability,
but one of the differences between them that must be dealt with is
that find_create_context () logs when it fails and find_context_near
() does not. Adding warnings to find_context_near () risks being too
noisy, leaving the option taken here.
The new method Context::diagnostic_id (name, id) returns a formatted
string (e.g. "Voice" or "Voice = mel") for use in a log message. It
is used for the warnings that are being moved as well as a few other
existing warnings to increase consistency.
diff --git a/input/regression/context-defaultchild-cycle.ly
b/input/regression/context-defaultchild-cycle.ly
index f62532f8bb..46de604dfd 100644
--- a/input/regression/context-defaultchild-cycle.ly
+++ b/input/regression/context-defaultchild-cycle.ly
@@ -2,10 +2,10 @@
#(ly:set-option 'warning-as-error #t)
%% not sure why these warnings appear twice [dfe]
-#(ly:expect-warning (_ "default child context begins a cycle: `~a'") 'Score)
-#(ly:expect-warning (_ "cannot find or create new `~a'") 'Bottom)
-#(ly:expect-warning (_ "default child context begins a cycle: `~a'") 'Score)
-#(ly:expect-warning (_ "cannot find or create new `~a'") 'Bottom)
+#(ly:expect-warning (_ "default child context begins a cycle: ~a") 'Score)
+#(ly:expect-warning (_ "cannot find or create context: ~a") 'Bottom)
+#(ly:expect-warning (_ "default child context begins a cycle: ~a") 'Score)
+#(ly:expect-warning (_ "cannot find or create context: ~a") 'Bottom)
\header {
texidoc = "A @code{\\defaultchild} cycle does not induce an endless loop.
So why is that patch not in your
input/regression/context-defaultchild-cycle ?
--
David Kastrup
Re: guile-3.0 and LilyPond - here: /input/regression/context-defaultchild-cycle.ly fails
Am Mi., 22. Jan. 2020 um 00:41 Uhr schrieb Karlin High : > > On 1/21/2020 5:10 PM, Thomas Morley wrote: > > Afterwards I've got a successful ´make´ with current LilyPond-master. > > So it's a functional LilyPond with guile-3.0? How does it perform if fed > something big? I'm thinking of the thread on benchmarking that used > Vaughan McAlley's MDSM.ly, the Robert Carver "Missa Dum sacrum mysterium." > > <https://lists.gnu.org/archive/html/lilypond-user/2016-11/msg00700.html> > -- > Karlin High > Missouri, USA Hi Karlin, no idea. I'll first try to get a succesfull ´make doc´ and then try to get ´make test-baseline´ work, which failed for other recent guile-versions. Currently I commented the problematic code in the mentioned regtest, continuing with ´make doc´. Testing how far I'll get. Cheers, Harm
Re: guile-3.0 and LilyPond - here: /input/regression/context-defaultchild-cycle.ly fails
On 1/21/2020 5:10 PM, Thomas Morley wrote: Afterwards I've got a successful ´make´ with current LilyPond-master. So it's a functional LilyPond with guile-3.0? How does it perform if fed something big? I'm thinking of the thread on benchmarking that used Vaughan McAlley's MDSM.ly, the Robert Carver "Missa Dum sacrum mysterium." <https://lists.gnu.org/archive/html/lilypond-user/2016-11/msg00700.html> -- Karlin High Missouri, USA
guile-3.0 and LilyPond - here: /input/regression/context-defaultchild-cycle.ly fails
Hi, some remarks: Guile-3.0 First I compiled successfully guile-master from their repo, giving GNU Guile 3.0.0.6-f3298 Trying to compile LilyPond with that guile (ofcourse adding a bunch of patches) I had some problems pointing configure to the correct guile and guile-config to the correct places. This was due to my setup with too many guile-versions around. So I did some clean up. LilyPond Afterwards I've got a successful ´make´ with current LilyPond-master. ´make LANGS='' doc´ failed, though. The problem is /input/regression/context-defaultchild-cycle.ly I do not understand how this regtest survives any compilation. It contains #(ly:set-option 'warning-as-error #t) and some #(ly:expect-warning ...) If I compile it, separetly I always get warnings (after disabling 'warning-as-error ) warning: default child context begins a cycle: Score warning: cannot find or create context: Bottom warning: default child context begins a cycle: Score warning: cannot find or create context: Bottom warning: 4 expected warning(s) not encountered: default child context begins a cycle: `Score' cannot find or create new `Bottom' default child context begins a cycle: `Score' cannot find or create new `Bottom' As far as I understand it errors always. Currently I can't test with a guile-1-build of recent master (my mentioned cleanup was a little to thorough it seems) Hints? Cheers, Harm
lilydev-3.0.iso -- not mounting on mac osx
Hi all, On mac osx 10.10.2 I get the following when trying to install LilyDev 3: ___ Warning The following disk images couldn’t be opened Image lilydev-3.0.iso Reason no mountable file systems ___ …after downloading from here: http://www.et.byu.edu/~sorensen/lilydev-3.0.iso http://www.et.byu.edu/~sorensen/lilydev-3.0.iso ...as linked from here: http://lilypond.org/doc/v2.19/Documentation/contributor/lilydev http://lilypond.org/doc/v2.19/Documentation/contributor/lilydev Has anyone else had this problem? Thanks, -Paul ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilydev-3.0.iso -- not mounting on mac osx
Paul Morris wrote Hi all, On mac osx 10.10.2 I get the following when trying to install LilyDev 3: Nevermind... I was doing it wrong. Seems to be working fine now. -Paul -- View this message in context: http://lilypond.1069038.n5.nabble.com/lilydev-3-0-iso-not-mounting-on-mac-osx-tp172556p172561.html Sent from the Dev mailing list archive at Nabble.com. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 3.0?
2014/1/12 Carl Peterson carlopeter...@gmail.com: What I would *ultimately* like is the ability for someone to visually write each part on separate staves (or using two staves with two voices each), then those parts are translated into the template without any direct code manipulation. The visual interface would be like the single-line view in Finale (where it's not trying to deal with line lengths/spacing, etc.). This is basically what I do in MuseScore or Finale Notepad from the compositional side, but I'm trying to find the most efficient workflow to go from that to my template. I don't know if it's practical, possible, or what. I don't know whether this would be a Frescobaldi thing or a Denemo thing. I think this is exactly a Denemo thing. best, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 3.0?
Janek Warchoł janek.lilyp...@gmail.com writes: 2014/1/12 Carl Peterson carlopeter...@gmail.com: What I would *ultimately* like is the ability for someone to visually write each part on separate staves (or using two staves with two voices each), then those parts are translated into the template without any direct code manipulation. The visual interface would be like the single-line view in Finale (where it's not trying to deal with line lengths/spacing, etc.). This is basically what I do in MuseScore or Finale Notepad from the compositional side, but I'm trying to find the most efficient workflow to go from that to my template. I don't know if it's practical, possible, or what. I don't know whether this would be a Frescobaldi thing or a Denemo thing. I think this is exactly a Denemo thing. Well, the question is how much one could pluginize Denemo. Like, marking a passage in Emacs which then turns into a small Denemo display window (the keyboard commands would still travel via Emacs) and back again... This could be interesting technology... -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 3.0?
Janek Warchoł janek.lilyp...@gmail.com schrieb: 2014/1/12 Carl Peterson carlopeter...@gmail.com: What I would *ultimately* like is the ability for someone to visually write each part on separate staves (or using two staves with two voices each), then those parts are translated into the template without any direct code manipulation. The visual interface would be like the single-line view in Finale (where it's not trying to deal with line lengths/spacing, etc.). This is basically what I do in MuseScore or Finale Notepad from the compositional side, but I'm trying to find the most efficient workflow to go from that to my template. I don't know if it's practical, possible, or what. I don't know whether this would be a Frescobaldi thing or a Denemo thing. I think this is exactly a Denemo thing. Please add your doubts to the Frescobaldi issue. Urs best, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel -- Urs Liska openlilylib.org ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 3.0?
2014/1/10 Urs Liska u...@openlilylib.org: Well, compiling a few measures of a single staff feels nearly instantaneous, and when you're editing an orchestral score this makes a huge difference. Generally I'd think it would be a good idea to have such an interface in Frescobaldi. I know that this is not exactly what we're talking about, but i believe that things like this (previewing music, partially compiled scores, instant feedback sacrificing some quality) are exactly what Denemo is for. I honestly believe that Denemo would be invaluable to LilyPond if only it could open all Lily files, not just those created by itself. (and if the UIUX kinks would be ironed out). best, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 3.0?
Janek Warchoł janek.lilyp...@gmail.com writes:
2014/1/10 Urs Liska u...@openlilylib.org:
Well,
compiling a few measures of a single staff feels nearly instantaneous, and
when you're editing an orchestral score this makes a huge difference.
Generally I'd think it would be a good idea to have such an interface in
Frescobaldi.
I know that this is not exactly what we're talking about, but i
believe that things like this (previewing music, partially compiled
scores, instant feedback sacrificing some quality) are exactly what
Denemo is for. I honestly believe that Denemo would be invaluable to
LilyPond if only it could open all Lily files, not just those created
by itself. (and if the UIUX kinks would be ironed out).
One very nice integrated experience is offered by preview-latex
URL:http://www.gnu.org/software/auctex/preview-latex. preview-latex
has no clue about the documents itself and does not actually import
them. It does not parse them and does not touch the input or create a
representation of it. There are several things it does for fast update
of single items (the first run is per-document, though):
a) it dumps a preloaded format including all document classes and
document styles, namely everything before \begin{document}. This
operation is optional.
b) When rerunning material in a single item, it cuts it out, precedes it
with what it considers the document preamble, follows it by what it
considers the document ending, and runs that through. That means,
obviously, that any macros you refer to have to be defined in the
document preamble or stuff won't work. It's quite uncommon to arrange
a LaTeX source using actual macros, so that usually works pretty well.
When wanting to do that approach using LilyPond, the preloaded format
thing can be accommodated quite better than with TeX (which is taken
as-is as a binary): we can just have a LilyPond process waiting for
action, and use the session mechanism for providing a reasonably
prepared situation without needing a new process each time.
The problem is that LilyPond sources more often than not _are_ arranged
with macro definitions, so we need to get those dependencies right.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 3.0?
On Jan 10, 2014, at 11:41 PM, Paul Morris p...@paulwmorris.com wrote: Seems like getting just the notes (not layout) out of an imported musicXML file should be an easy and straightforward thing, but I guess not? I can't speak for Carl P's work. For me, effective LP input files require structure (variables, contexts) that MusicXML knows nothing of. And it's generally easier to create them than to fix them on import. Carl S. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 3.0?
2014/1/11 David Kastrup d...@gnu.org: One very nice integrated experience is offered by preview-latex URL:http://www.gnu.org/software/auctex/preview-latex. Indeed, this is very nice. Although i haven't used it, i know i would enjoy it :) j ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 3.0?
Janek Warchoł janek.lilyp...@gmail.com writes: 2014/1/11 David Kastrup d...@gnu.org: One very nice integrated experience is offered by preview-latex URL:http://www.gnu.org/software/auctex/preview-latex. Indeed, this is very nice. Although i haven't used it, i know i would enjoy it :) Well, actually it's a lot better than you'd guess from the screenshots: the proof-of-concept took about two weeks, and the screen shots would not have been much different then (apart from the descenders being wrong). There's been years of development going into it afterwards. It's technology that does not get in the way, is fast and reliable, and integrates with personal workflows seamlessly. I wish we'd have something like that for the LilyPond manuals. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 3.0?
Am Donnerstag, den 09.01.2014, 10:13 -0500 schrieb Carl Peterson: On Thu, Jan 9, 2014 at 6:20 AM, David Kastrup d...@gnu.org wrote: Another problem is that LilyPond has a usage philosophy and workflow that strongly penalizes manual tweaks. Graphically/manually oriented workflows detract from the importance of getting good default typesetting. I don't know that I agree with this, entirely. I use MuseScore, Scorio, and Finale Notepad (depending on where I am and how I feel) for compositional work because they provide ease of note entry in the composing process and the ability to have instant aural feedback on what I've written (particularly if I'm not at my keyboard to play what I've written). Once I have the draft of the music written, I will manually retype the music into my LilyPond template because of the good default typesetting it provides. Now, consider an IDE/GUI setup (perhaps an extension of Frescobaldi) that would allow me to define a variable for a voice, then pop up a musical staff to enter and play back the notes for that variable without dealing with the whole compilation process. No manual tweaking of notes, just the entry of the entry and playback of the notes, and I don't have to insert the notes into the music itself yet or deal with whatever may or may not be wrong with the rest of my file. I realize that this would not necessarily work for all use cases, but I think for a large number of them, this could be beneficial. It would reduce a number of my transcription errors without me having to compile, scan for errors, potentially figure out where the errors are (depending on workflow), correct, recompile, etc. Carl https://github.com/wbsoft/frescobaldi/issues/345 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 3.0?
Carl Sorensen-3 wrote I can't speak for Carl P's work. For me, effective LP input files require structure (variables, contexts) that MusicXML knows nothing of. And it's generally easier to create them than to fix them on import. I see what you mean. Unfortunately it makes it harder to use other tools that are optimized for composing with LilyPond... Seems like capturing just the musical content from a MusicXML file and then pasting it into a LP template or file that has the LP structure should be easier than re-typing it. But I defer to those with more experience in this area, as I've only done musicXML import a few times. David Kastrup wrote One very nice integrated experience is offered by preview-latex lt;URL:http://www.gnu.org/software/auctex/preview-latexgt;. snip I wish we'd have something like that for the LilyPond manuals. This does look good. It would be really nice to have something like this for the manuals. Urs Liska wrote https://github.com/wbsoft/frescobaldi/issues/345 I'm not sure about this. Seems like you could get basically the same workflow by using a second file as a sketchpad without having to introduce a new UI component. See my comment at the link above for more of my thoughts on this. -Paul -- View this message in context: http://lilypond.1069038.n5.nabble.com/3-0-tp157489p157682.html Sent from the Dev mailing list archive at Nabble.com. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 3.0?
On Sat, Jan 11, 2014 at 11:50 PM, Paul Morris p...@paulwmorris.com wrote: Carl Sorensen-3 wrote I can't speak for Carl P's work. For me, effective LP input files require structure (variables, contexts) that MusicXML knows nothing of. And it's generally easier to create them than to fix them on import. I see what you mean. Unfortunately it makes it harder to use other tools that are optimized for composing with LilyPond... Seems like capturing just the musical content from a MusicXML file and then pasting it into a LP template or file that has the LP structure should be easier than re-typing it. But I defer to those with more experience in this area, as I've only done musicXML import a few times. Urs Liska wrote https://github.com/wbsoft/frescobaldi/issues/345 I'm not sure about this. Seems like you could get basically the same workflow by using a second file as a sketchpad without having to introduce a new UI component. See my comment at the link above for more of my thoughts on this. -Paul Allow me to extend my use case a bit further. My own work is similar to what I understand of Carl S's work. I have a file where I define each of my SATB parts, each lyrical verse, and calls a template file that takes the parts and creates the two staves for the music, with both a part-combined voice for display purposes and separated voices for MIDI and lyric purposes (the separated notes are hidden and non-colliding, etc., in the layout). I have a second file where I include this master file and create either the paper hymnal layout or slides for projection (depending upon which layout template I call). I've done the two file workflow before, typically when I've created the four parts using a basic SATB template, then copied and pasted into the variables of my own template. That said, I am also trying to think about features which would make this more productive for someone who *isn't* inclined to work multiple files, variables, etc. What I would *ultimately* like is the ability for someone to visually write each part on separate staves (or using two staves with two voices each), then those parts are translated into the template without any direct code manipulation. The visual interface would be like the single-line view in Finale (where it's not trying to deal with line lengths/spacing, etc.). This is basically what I do in MuseScore or Finale Notepad from the compositional side, but I'm trying to find the most efficient workflow to go from that to my template. I don't know if it's practical, possible, or what. I don't know whether this would be a Frescobaldi thing or a Denemo thing. Since Denemo is already a GUI experience, it may be the better place to try to get this kind of functionality. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 3.0?
On Fri, Jan 10, 2014 at 12:46 AM, Paul Morris p...@paulwmorris.com wrote: Carl Peterson wrote I use MuseScore, Scorio, and Finale Notepad (depending on where I am and how I feel) for compositional work because they provide ease of note entry in the composing process and the ability to have instant aural feedback on what I've written (particularly if I'm not at my keyboard to play what I've written). Once I have the draft of the music written, I will manually retype the music into my LilyPond template because of the good default typesetting it provides. Hi Carl, Do you find that manually retyping is easier or better than export - musicXML - import? Curious to hear your thoughts as I would assume that import/export would be the ideal way to use a workflow like this. Retyping by far. I pretty much write exclusively a cappella SATB, and I have developed a very specific template/workflow for the part combining and layout. I've tried a few different ways of getting the music from these formats into LP, and in each case, I found myself spending longer in cleaning up the resulting LilyPond code than if I had just transcribed it manually from the other program. That is why I suggested an IDE feature that would allow for creating a variable, and then providing a basic visual note-entry tool that can handle single or chorded notes (whether it allows polyphonic music may be a more challenging question), then return minimal code (just the notes). I know someone suggested just turning off the PDF conversion to speed things up, but it's not just a matter of instantaneous aural feedback. There's a visual component and a matter of input error reduction, because I have been known to enter incorrect octaves or durations and not realize it until I've finished typing and have compiled the entire score. Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 3.0?
Carl Peterson: ... I know someone suggested just turning off the PDF conversion to speed things up, but it's not just a matter of instantaneous aural feedback. Ok. There's a visual component and a matter of input error reduction, because I have been known to enter incorrect octaves or durations and not realize it until I've finished typing and have compiled the entire score. A quick-n-dirty test mode would probably solve your need, just to check for typing errors and such (as you write above). What should such a mode need/disregard, what speedups are possible for such a test mode ? Regards, /Karl Hammar --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 3.0?
Am 10.01.2014 22:23, schrieb k...@aspodata.se: Carl Peterson: ... I know someone suggested just turning off the PDF conversion to speed things up, but it's not just a matter of instantaneous aural feedback. Ok. There's a visual component and a matter of input error reduction, because I have been known to enter incorrect octaves or durations and not realize it until I've finished typing and have compiled the entire score. A quick-n-dirty test mode would probably solve your need, just to check for typing errors and such (as you write above). What should such a mode need/disregard, what speedups are possible for such a test mode ? Well, compiling a few measures of a single staff feels nearly instantaneous, and when you're editing an orchestral score this makes a huge difference. Generally I'd think it would be a good idea to have such an interface in Frescobaldi. UI-wise it wouldn't be too hard to add that. However, there is one thing I've thought about several times and that doesn't make the issue so easy: If you have a short segment of a score, say in a variable, how can you guarantee that LilyPond has the right context for that (I'm not talking of \context, but of things like key, time signature, transposition etc.)? Urs Regards, /Karl Hammar --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel -- Urs Liska www.openlilylib.org ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 3.0?
Carl Peterson: ... Retyping by far. I pretty much write exclusively a cappella SATB, and I have developed a very specific template/workflow for the part combining and layout. I've tried a few different ways of getting the music from these formats into LP, and in each case, I found myself spending longer in cleaning up the resulting LilyPond code than if I had just transcribed it manually from the other program. ... What if the midi-lilypond conversion could be made better? I'm currently looking into that. Regards, /Karl Hammar --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 3.0?
Urs Liska: Am 10.01.2014 22:23, schrieb k...@aspodata.se: Carl Peterson: ... There's a visual component and a matter of input error reduction, because I have been known to enter incorrect octaves or durations and not realize it until I've finished typing and have compiled the entire score. A quick-n-dirty test mode would probably solve your need, just to check for typing errors and such (as you write above). What should such a mode need/disregard, what speedups are possible for such a test mode ? Well, compiling a few measures of a single staff feels nearly instantaneous, and when you're editing an orchestral score this makes a huge difference. Denpends on the computer you are using, http://turkos.aspodata.se/git/musik/ALotti/missa_a3_la_minore/04_agnus.ly is 17bars, 3voices with lyrics, and it still takes 5s on my box, Generally I'd think it would be a good idea to have such an interface in Frescobaldi. UI-wise it wouldn't be too hard to add that. However, there is one thing I've thought about several times and that doesn't make the issue so easy: If you have a short segment of a score, say in a variable, how can you guarantee that LilyPond has the right context for that (I'm not talking of \context, but of things like key, time signature, transposition etc.)? If you are only interested in checking octaves and durations, the context doesn't matter too much. Regards, /Karl Hammar --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 3.0?
On 1/9/14 9:43 PM, SoundsFromSound soundsfromso...@gmail.com wrote: dak wrote Joseph Rushton Wakeling lt;That must be the reason why the typical Word document features the consistent use of document styles for arriving at typographically superior results. -- David Kastrup ___ I honestly have never seen ONE Word document make use of styles. I'm not kidding. In all the docs I've come across in all areas, people never use them. Seriously! :) I use styles anytime I have to make a serious Word document (i.e. when I can't use LaTeX). Of course, that's probably part of the reason that I like LilyPondŠ. Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 3.0?
On Fri, Jan 10, 2014 at 4:25 PM, Urs Liska u...@openlilylib.org wrote: Well, compiling a few measures of a single staff feels nearly instantaneous, and when you're editing an orchestral score this makes a huge difference. Generally I'd think it would be a good idea to have such an interface in Frescobaldi. UI-wise it wouldn't be too hard to add that. However, there is one thing I've thought about several times and that doesn't make the issue so easy: If you have a short segment of a score, say in a variable, how can you guarantee that LilyPond has the right context for that (I'm not talking of \context, but of things like key, time signature, transposition etc.)? Couple of possibilities. Just thinking about Frescobaldi, since it seems to do a pretty good job of tracing things through the document(s), would it be possible to look for the reference to that variable and try to determine the context? Another option is that this is not a compilation feature (i.e., Fresco is not passing the variable to LP to compile), but rather it would allow a dialog box/popup and there would be the option to change certain things like time signature, transposition, etc. I actually think it should be some kind of bare-bones parser apart from LP proper (a bypass) that doesn't factor in articulations, manual tweaks, etc., but only considers absolutely essential components (notes, slurs, ties, chords, etc.). Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 3.0?
Am 10.01.2014 23:37, schrieb Carl Peterson: On Fri, Jan 10, 2014 at 4:25 PM, Urs Liska u...@openlilylib.org wrote: Well, compiling a few measures of a single staff feels nearly instantaneous, and when you're editing an orchestral score this makes a huge difference. Generally I'd think it would be a good idea to have such an interface in Frescobaldi. UI-wise it wouldn't be too hard to add that. However, there is one thing I've thought about several times and that doesn't make the issue so easy: If you have a short segment of a score, say in a variable, how can you guarantee that LilyPond has the right context for that (I'm not talking of \context, but of things like key, time signature, transposition etc.)? Couple of possibilities. Just thinking about Frescobaldi, since it seems to do a pretty good job of tracing things through the document(s), would it be possible to look for the reference to that variable and try to determine the context? I think that wouldn't be reliable because there are so many possibilities one couldn't really preview. Another option is that this is not a compilation feature (i.e., Fresco is not passing the variable to LP to compile), but rather it would allow a dialog box/popup and there would be the option to change certain things like time signature, transposition, etc. I actually think it should be some kind of bare-bones parser apart from LP proper (a bypass) that doesn't factor in articulations, manual tweaks, etc., but only considers absolutely essential components (notes, slurs, ties, chords, etc.). Carl Actually I think you're considering something like Denemo does: create a mock-up editor with output that will later be replaced by LilyPond's output. But now I see how it could be done. What you want is a tool that creates LilyPond input for you, isn't it? Like the keyboard is a tool, midi input is one and xml import is one. So you don't actually need the segment to be taken from the real file or even be related to it. What Frescobaldi can do is take some input code, put it in a scratch area and let LilyPond compile that as a temporary file. That's what it does when you compile a file that doesn't have a name yet. Or when you're in the New Score Wizard and click Preview. So what one could implement is a tool that provides some, but not too much space to edit text, a small preview pane and a set of UI elements for setting the musical context. From there it can wrap the source in a score template, respecting the settings of time, key etc. and compile this (maybe continuously). Then there are two buttons to copy/cut the source to the clipboard or to insert it at the current cursor position. Actually there already is a similar tool: Edit in place. When you right click on an item in the Music View and select Edit in Place it fires a small editor window where you can edit the current line in the source file. -- Urs Liska www.openlilylib.org ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 3.0?
Carl Peterson wrote Retyping by far. I pretty much write exclusively a cappella SATB, and I have developed a very specific template/workflow for the part combining and layout. I've tried a few different ways of getting the music from these formats into LP, and in each case, I found myself spending longer in cleaning up the resulting LilyPond code than if I had just transcribed it manually from the other program. Hmmm, I'm curious what kind of cleanup is needed? Is it the part combining of SATB that's the problem, with the musicXML having the music represented as harmonies / chords, and needing to isolate the different parts? ...or something else? Seems like getting just the notes (not layout) out of an imported musicXML file should be an easy and straightforward thing, but I guess not? That is why I suggested an IDE feature that would allow for creating a variable, and then providing a basic visual note-entry tool that can handle single or chorded notes (whether it allows polyphonic music may be a more challenging question), then return minimal code (just the notes). This makes me wonder if Schikker's List could work for this, either as a separate tool or possibly integrated into Frescobaldi? (It's written in Scheme whereas Frescobaldi is in Python, so that may be an obstacle?) It seems that if, as Urs is suggesting here, Frescobaldi moves towards more graphical features then we're headed for some duplication of effort between it and Schikker's List. Just this week I came across LilyComp (http://lilycomp.sourceforge.net/) which I haven't tried, and is probably too simple to be much help. But if it or something like it was integrated into Frescobaldi with the new auto-compile feature, perhaps just rendering a limited number of notes at a time in a separate window, that might start to be interesting. (It's written in python and is licensed under the GPL.) -Paul -- View this message in context: http://lilypond.1069038.n5.nabble.com/3-0-tp157489p157612.html Sent from the Dev mailing list archive at Nabble.com. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
3.0?
Please don't beat me up, but that's something I wondered about for quite some time: Is there _any_ notion what a LilyPond 3.0 may be? I mean 2.0 followed on 1.8, and now we're already towards .20 Is there any general idea about what would make the next major program version? Urs -- Urs Liska www.openlilylib.org ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 3.0?
Urs Liska writes: Is there _any_ notion what a LilyPond 3.0 may be? I could imagine that if LilyPond were made into an engraving library, and/or heavy rewiring to make it deeply integrated with a gui, or accept another native input language like the lilypond-driven fixed fresh release of MusicXML 4.0; something like that would warrant 3.0. I mean 2.0 followed on 1.8, and now we're already towards .20 We had major language changes and a deep incorporation of Guile, those made good excuses to move away from the 1.0 series. Jan -- Jan Nieuwenhuizen jann...@gnu.org | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.nl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 3.0?
- Original Message - From: Urs Liska u...@openlilylib.org To: LilyPond Development Team lilypond-devel@gnu.org Sent: Thursday, January 09, 2014 10:53 AM Subject: 3.0? Please don't beat me up, but that's something I wondered about for quite some time: Is there _any_ notion what a LilyPond 3.0 may be? I mean 2.0 followed on 1.8, and now we're already towards .20 Is there any general idea about what would make the next major program version? Urs Fundamental changes to the approach taken? -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 3.0?
Am 09.01.2014 12:03, schrieb Jan Nieuwenhuizen: Urs Liska writes: Is there _any_ notion what a LilyPond 3.0 may be? I could imagine that if LilyPond were made into an engraving library, and/or heavy rewiring to make it deeply integrated with a gui, Hm, this is something I was also thinking about: Of course LilyPond itself will never get graphical editing but remains a dedicated engraving tool. But it would probably make it more attractive for the consumer market if it had a nice default GUI. I personally would be pleased to see Frescobaldi become such a default GUI (of course not cutting out other options). Particularly given the prospect of Frescobaldi providing graphical editing capabilities soon (and provided we'll get the Mac OSX installation sorted out). Would such a step be _conceptually_ acceptable or should LilyPond remain GUI-agnostic? or accept another native input language like the lilypond-driven fixed fresh release of MusicXML 4.0; something like that would warrant 3.0. In that context: Does anybody have experience/knowledge/contact with MEI (www.music-encoding.org)? I mean 2.0 followed on 1.8, and now we're already towards .20 We had major language changes and a deep incorporation of Guile, those made good excuses to move away from the 1.0 series. Ah, OK: Urs Jan -- Urs Liska www.openlilylib.org ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 3.0?
On Jan 9, 2014, at 1:07 PM, Urs Liska u...@openlilylib.org wrote: Am 09.01.2014 12:03, schrieb Jan Nieuwenhuizen: Urs Liska writes: Is there _any_ notion what a LilyPond 3.0 may be? I could imagine that if LilyPond were made into an engraving library, and/or heavy rewiring to make it deeply integrated with a gui, Hm, this is something I was also thinking about: Of course LilyPond itself will never get graphical editing but remains a dedicated engraving tool. But it would probably make it more attractive for the consumer market if it had a nice default GUI. I personally would be pleased to see Frescobaldi become such a default GUI (of course not cutting out other options). Particularly given the prospect of Frescobaldi providing graphical editing capabilities soon (and provided we'll get the Mac OSX installation sorted out). Would such a step be _conceptually_ acceptable or should LilyPond remain GUI-agnostic”? GUI agnostic - there should be a clear separation between front end and backend. LilyPond is technically already GUI agnostic, as joe and vim (my two favorite GUIs) both act commendably as front ends to my LilyPond code. The best thing, by far, would to make LilyPond a modular engraving library with public APIs for each module. This way, building a GUI just means mapping visual symbols to API calls and displaying the result. GUIDO (for which I’m a developer) already works like this and has been embedded in several commercial and open-source apps. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 3.0?
On Thu, Jan 09, 2014 at 12:07:07PM +0100, Urs Liska wrote: But it would probably make it more attractive for the consumer market if it had a nice default GUI. I personally would be pleased to see Frescobaldi become such a default GUI (of course not cutting out other options). Particularly given the prospect of Frescobaldi providing graphical editing capabilities soon (and provided we'll get the Mac OSX installation sorted out). Would such a step be _conceptually_ acceptable or should LilyPond remain GUI-agnostic? I don't think that such a step would be conceptually acceptable (we could always provide a stripped down binary package without the editor). However, cross-compiling and distributing Frescobaldi would be a huge undertaking. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 3.0?
Urs Liska u...@openlilylib.org writes: Am 09.01.2014 12:03, schrieb Jan Nieuwenhuizen: Urs Liska writes: Is there _any_ notion what a LilyPond 3.0 may be? I could imagine that if LilyPond were made into an engraving library, and/or heavy rewiring to make it deeply integrated with a gui, Hm, this is something I was also thinking about: Of course LilyPond itself will never get graphical editing but remains a dedicated engraving tool. But it would probably make it more attractive for the consumer market if it had a nice default GUI. It's not for the consumer market anyway. Too much thinking. I personally would be pleased to see Frescobaldi become such a default GUI (of course not cutting out other options). Frescobaldi is not a GUI but an IDE. It runs on fewer platforms than LilyPond. Particularly given the prospect of Frescobaldi providing graphical editing capabilities soon (and provided we'll get the Mac OSX installation sorted out). Would such a step be _conceptually_ acceptable or should LilyPond remain GUI-agnostic? That question does not make sense. You don't describe such a step, I don't see what concepts are involved here, and there is no point in not adding support code for particular applications. One problem with GUI proponents is that they more often than not are of the opinion it should work good on Windows, let the rest be d***ed, and it is the position of the GNU project _not_ to introduce material that promotes the use of proprietary platforms over free ones. Another problem is that LilyPond has a usage philosophy and workflow that strongly penalizes manual tweaks. Graphically/manually oriented workflows detract from the importance of getting good default typesetting. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 3.0?
Urs Liska u...@openlilylib.org writes: Please don't beat me up, but that's something I wondered about for quite some time: Is there _any_ notion what a LilyPond 3.0 may be? I mean 2.0 followed on 1.8, and now we're already towards .20 Is there any general idea about what would make the next major program version? Not without GUILEv2 and likely some other architectural overhaul. The early 2.0 phase mostly got rid of TeX. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 3.0?
Carl Peterson:
...
Now, consider an IDE/GUI setup
(perhaps an extension of Frescobaldi) that would allow me to define a
variable for a voice, then pop up a musical staff to enter and play
back the notes for that variable without dealing with the whole
compilation process. No manual tweaking of notes, just the entry of
the entry and playback of the notes, and I don't have to insert the
notes into the music itself yet or deal with whatever may or may not
be wrong with the rest of my file. I realize that this would not
necessarily work for all use cases, but I think for a large number of
them, this could be beneficial. It would reduce a number of my
transcription errors without me having to compile, scan for errors,
potentially figure out where the errors are (depending on workflow),
correct, recompile, etc.
Sounds like a performance problem, you want to hear (quickly) how the
things you entered sounds. That can be done with lilypond as is, just
skip the ps/pdf generation, us a test file like:
ma = { your_music }
targetpitch = c
midi_tempo = { \tempo 2 = 100 }
\score {
\unfoldRepeats \transpose c \targetpitch
\new Staff \ma
\midi {
\midi_tempo
}
}
///
As an example take:
http://turkos.aspodata.se/git/musik/ALotti/missa_a3_la_minore/
Compiling it takes 15s on my box.
$ time lilypond 01_kyrie.ly
GNU LilyPond 2.19.0
Processing `01_kyrie.ly'
real0m14.844s
user0m10.914s
sys 0m0.291s
Skipping the to-pdf conversion saves me 2s
$ time lilypond --ps 01_kyrie.ly
...
real0m12.674s
user0m9.368s
sys 0m0.220s
And doing only midi is fast, 2.5s:
$ time lilypond 01_kyrie.ly
GNU LilyPond 2.19.0
Processing `01_kyrie.ly'
Parsing...
Interpreting music...
MIDI output to `01_kyrie.midi'...
Success: compilation successfully completed
real0m2.437s
user0m1.652s
sys 0m0.140s
So running
$ lilypond file.ly timidity file.midi
would probably solve your stated need.
Regards,
/Karl Hammar
---
Aspö Data
Lilla Aspö 148
S-742 94 Östhammar
Sweden
+46 173 140 57
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 3.0?
On 09/01/14 12:20, David Kastrup wrote: Another problem is that LilyPond has a usage philosophy and workflow that strongly penalizes manual tweaks. Graphically/manually oriented workflows detract from the importance of getting good default typesetting. I'm not sure that's necessarily the case. Making it easy to experiment with manual tweaks could be a very good way of working out how things need to be engraved, and thus provide guidance for better automated typesetting. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 3.0?
Joseph Rushton Wakeling joseph.wakel...@webdrake.net writes: On 09/01/14 12:20, David Kastrup wrote: Another problem is that LilyPond has a usage philosophy and workflow that strongly penalizes manual tweaks. Graphically/manually oriented workflows detract from the importance of getting good default typesetting. I'm not sure that's necessarily the case. Making it easy to experiment with manual tweaks could be a very good way of working out how things need to be engraved, and thus provide guidance for better automated typesetting. That must be the reason why the typical Word document features the consistent use of document styles for arriving at typographically superior results. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 3.0?
David Kastrup d...@gnu.org schrieb: Joseph Rushton Wakeling joseph.wakel...@webdrake.net writes: On 09/01/14 12:20, David Kastrup wrote: Another problem is that LilyPond has a usage philosophy and workflow that strongly penalizes manual tweaks. Graphically/manually oriented workflows detract from the importance of getting good default typesetting. I'm not sure that's necessarily the case. Making it easy to experiment with manual tweaks could be a very good way of working out how things need to be engraved, and thus provide guidance for better automated typesetting. That must be the reason why the typical Word document features the consistent use of document styles for arriving at typographically superior results. LOL! -- Urs Liska openlilylib.org ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 3.0?
On 09/01/14 21:05, David Kastrup wrote: That must be the reason why the typical Word document features the consistent use of document styles for arriving at typographically superior results. I'm not sure that I feel happy about your benchmark for comparison. I think Lilypond's user base is a bit smarter than that ... ;-) ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 3.0?
dak wrote Joseph Rushton Wakeling lt; joseph.wakeling@ gt; writes: On 09/01/14 12:20, David Kastrup wrote: Another problem is that LilyPond has a usage philosophy and workflow that strongly penalizes manual tweaks. Graphically/manually oriented workflows detract from the importance of getting good default typesetting. I'm not sure that's necessarily the case. Making it easy to experiment with manual tweaks could be a very good way of working out how things need to be engraved, and thus provide guidance for better automated typesetting. That must be the reason why the typical Word document features the consistent use of document styles for arriving at typographically superior results. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@ https://lists.gnu.org/mailman/listinfo/lilypond-devel I honestly have never seen ONE Word document make use of styles. I'm not kidding. In all the docs I've come across in all areas, people never use them. Seriously! :) Now, LibreOffice Writer on the other hand... - composer | sound designer LilyPond Tutorials (for beginners) -- http://bit.ly/bcl-lilypond -- View this message in context: http://lilypond.1069038.n5.nabble.com/3-0-tp157489p157553.html Sent from the Dev mailing list archive at Nabble.com. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 3.0?
Carl Peterson wrote I use MuseScore, Scorio, and Finale Notepad (depending on where I am and how I feel) for compositional work because they provide ease of note entry in the composing process and the ability to have instant aural feedback on what I've written (particularly if I'm not at my keyboard to play what I've written). Once I have the draft of the music written, I will manually retype the music into my LilyPond template because of the good default typesetting it provides. Hi Carl, Do you find that manually retyping is easier or better than export - musicXML - import? Curious to hear your thoughts as I would assume that import/export would be the ideal way to use a workflow like this. Thanks, -Paul -- View this message in context: http://lilypond.1069038.n5.nabble.com/3-0-tp157489p157554.html Sent from the Dev mailing list archive at Nabble.com. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lilypond Syntax Development and 3.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Samstag, 1. August 2009 09:52:59 schrieb Trevor Daniels: CRESCENDO Reinhold and Frederick: as you may have guessed, I'm proposing that your patch waits until 3.0. Anything requiring such manual tweaks will make some people very unhappy, such as mutopia. This also serves as test of developers: we've avoided getting pinned down with the input syntax because that would limit development. How do you two feel about your hard work on the \cr stuff being delayed by up to a year? I don't like asking this, but I think there are solid reasons for it. This would be a pity. I've now forgotten the details of the cr changes, but cannot a way be found to introduce the new versions now while retaining the deprecated versions until 3.0? Even a partial introduction now would help users. New patch, just for the backend: http://codereview.appspot.com/109072 The definition of \cresc etc. is still unchanged, but one can now define one's own command instead (or overwrite the definition of \cresc). Cheers, Reinhold - -- - -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQFKjy5STqjEwhXvPN0RAuctAJ4sCgw2JuB1jDcFMkWXLQC2WbzMoACfbTb9 YllPxoJxkaelcczQPDeLiek= =646x -END PGP SIGNATURE- ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lilypond Syntax Development and 3.0
On Sun, Aug 02, 2009 at 08:48:01PM +0200, John Mandereau wrote: Le lundi 27 juillet 2009 à 03:22 -0700, Graham Percival a écrit : One of the biggest complaints people have with lilypond -- other than that silly there's no gui -- is the changing syntax. Now, IMHO this project should be an opportunity to promote Erik Sandberg's music streams as a more stable music data representation before making syntax changes that can't be handled by regular expressions and that break a lot of source files. I think that's beyond us. Unless Erik or Han-Wen decide to implement it, I'm almost certain that this work will go nowhere. And since it's been 3 years since the thesis was finished, I think that if they wanted to do it, they'd have finished it. Understanding somebody else's half-finished work can be harder than doing it from scratch, after all! Basically, I don't see an overabundance of programmers with deep knowledge of lilypond internals (which is what the music streams would require). I *do* see an overabundance of intelligent people who see the value of creating general principals and rules. I'm certain that we can simplify+standarize the lilypond input notation, and I'm certain that I can organize such an effort. I'm not *at all* certain[1] that I could organize an attempt to implement the music streams. Umm, I don't mean overabundance as in there's too any of them. I'm using some other meaning of overabundance here. :) [1] or rather: I'm certain that if I cared deeply about this, I could do it. I simply don't care deeply about it -- I mean, I wouldn't sacrifice any academic matters in favor of working on music streams, whereas I _would_ sacrifice some academic matters in favor of GLISS or the normal lilypond maintenance. I n any case, I don't anticipate that GLISS would create many non-convert-ly changes. The main manual change would be the prefix - postfix change (\cr, \[, maybe one or two others). In theory, those could be automated, but since we probably won't have anybody who feels like writing python rules for that, we could just change \cr to \PREcr. That would identify the places were \PREcr needs to be moved and changed to \cr. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lilypond Syntax Development and 3.0
Le lundi 27 juillet 2009 à 03:22 -0700, Graham Percival a écrit : One of the biggest complaints people have with lilypond -- other than that silly there's no gui -- is the changing syntax. Now, inventing a language or standards is difficult. If you set it in stone too soon, you risk being stuck with decisions which may limit matters. If you keep on updating the syntax, interaction with older data (and other programs!) becomes complex. IMHO this project should be an opportunity to promote Erik Sandberg's music streams as a more stable music data representation before making syntax changes that can't be handled by regular expressions and that break a lot of source files. Best, John signature.asc Description: Ceci est une partie de message numériquement signée ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lilypond Syntax Development and 3.0
Graham Percival wrote Monday, July 27, 2009 11:22 AM Lilypond Syntax Development (tentative name) However, I think we now have a critical mass of interested users, experience with the syntax, and developers. I therefore propose to have a Grand Project devoted to stabilizing the lilypond input format. The time is right for this. I'd like to help. - We're going to have lots and lots of emails flying around. They don't really fit into either -devel or -user, so we'll use a mailist on lilynet.net. Maybe the already-created proposals mailist, maybe a syn...@lilynet.net mailist. - I could be convinced to use the lilynet wiki for this project, although we'd need account-locked pages, and it would increase my workload. No, stick to a simple maillist. CRESCENDO Reinhold and Frederick: as you may have guessed, I'm proposing that your patch waits until 3.0. Anything requiring such manual tweaks will make some people very unhappy, such as mutopia. This also serves as test of developers: we've avoided getting pinned down with the input syntax because that would limit development. How do you two feel about your hard work on the \cr stuff being delayed by up to a year? I don't like asking this, but I think there are solid reasons for it. This would be a pity. I've now forgotten the details of the cr changes, but cannot a way be found to introduce the new versions now while retaining the deprecated versions until 3.0? Even a partial introduction now would help users. - Graham Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lilypond Syntax Development and 3.0
Reinhold and Frederick: as you may have guessed, I'm proposing that your patch waits until 3.0. Anything requiring such manual tweaks will make some people very unhappy, such as mutopia. I think we should make *all* manual changes at once, but reassure people that this will (probably) be the last time (for non-tweaked scores, at least). No issue for me. I can wait; I have now my own tricks... However, the quicker, the better... Great project that you propose to make syntax uniform. Frédéric ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Lilypond Syntax Development and 3.0
I was going to hold off introducing this until the 3-4 major development issues had been sorted out, but the third time I found myself writing yes, I have a plan for this, but I'm going to wait a bit before discussing it, I decided I was behaving like a smarmy teenager. There's nothing time-critical in this thread, so if you're currently working on anything important, skip this email and come back to it later. We won't make any real decisions for a week or so. Lilypond Syntax Development (tentative name) One of the biggest complaints people have with lilypond -- other than that silly there's no gui -- is the changing syntax. Now, inventing a language or standards is difficult. If you set it in stone too soon, you risk being stuck with decisions which may limit matters. If you keep on updating the syntax, interaction with older data (and other programs!) becomes complex. However, I think we now have a critical mass of interested users, experience with the syntax, and developers. I therefore propose to have a Grand Project devoted to stabilizing the lilypond input format. SUMMARY Start: Sep 2009. Length: 6-9 months. We're not going to rush this. Goal: define an input format which we commit to being machine-updateable for the forseeable future. Any future patches which change the syntax in a non-convert-ly-able format will be rejected. (subject to the limitations, below) Once this is finished, we will release lilypond 3.0. LIMITATIONS and SCOPE - tweaks will not be included. Anything with \override, \set, \overrideProperty, \tweak, \revert, \unset, #(blah blah) ... including even those names themselves... is still fair game for NOT_SMART convert-ly updates. - other than that, everything is on the table. Is it a problem to have the tagline inside \header? What should the default behavior of \include be? When we abolish \times, do we move to \tuplet 3:2 or \tuplet 2/3 or what (for typical triplets in 4/4 time)? - we need to get standards for commands. This will help users remember them, and reduce the options for future names (and potential renamings later on). \commandOn and \commandOff seem to work well (should we *always* have an Off command?), but what about the command part? Should it be \nounVerbOn, or \verbNounOn ? Or \verbNotesWithExtraInformationOn ? - we need standards for the location of commands. Ligature brackets, I'm looking at you. (non-postfix notation must die!) - this Grand Project doesn't change whether we have a 2.16 or not. The main problem will be deciding what to do (with a bit of messiness anticipated for \tuplet); we could definitely release a 2.16 before merging _any_ of these changes. - we obviously can't /guarantee/ that we'll /never/ make any non-convert-ly changes in the basic format. But we *can* guarantee that such changes would force lilypond 4.0, and that we would only do so for overwhelmingly good reasons. WORKFLOW - We're going to have lots and lots of emails flying around. They don't really fit into either -devel or -user, so we'll use a mailist on lilynet.net. Maybe the already-created proposals mailist, maybe a syn...@lilynet.net mailist. - I could be convinced to use the lilynet wiki for this project, although we'd need account-locked pages, and it would increase my workload. - after the initial discussion of proposals has died down, I'll bring it to -devel. We're not going to make any (significant) changes without discussing it on -devel, but we're going to have huge threads about English grammar and silly ideas, and I don't want to clutter up -devel. Once whatever chaotic silliness on the syntax list is settled down, I'll bring the ideas to -devel. - as with GDP, I'll moderate the discussion. Not as with mailist moderation, but rather by introducing issues at specific times. We don't want a free-for-all discussion of all parts of the syntax at once; nothing will get resolved. DISCUSSION Don't respond to any of the specifics yet. Yes, we all have our pet irritations (like what the mao is up with \paper and \layout?!). There will be plenty of time to discuss them. At the moment, I'm looking for comments about the mandate -- what's the scope, how much interest is there, and does anybody object to such work? CRESCENDO Reinhold and Frederick: as you may have guessed, I'm proposing that your patch waits until 3.0. Anything requiring such manual tweaks will make some people very unhappy, such as mutopia. I think we should make *all* manual changes at once, but reassure people that this will (probably) be the last time (for non-tweaked scores, at least). This also serves as test of developers: we've avoided getting pinned down with the input syntax because that would limit development. How do you two feel about your hard work on the \cr stuff being delayed by up to a year? I don't like asking this, but I think there are solid reasons
Re: Lilypond Syntax Development and 3.0
A few comments from a consumer... Graham Percival gra...@percival-music.ca writes: SUMMARY Start: Sep 2009. Length: 6-9 months. We're not going to rush this. Goal: define an input format which we commit to being machine-updateable for the forseeable future. Any future patches which change the syntax in a non-convert-ly-able format will be rejected. (subject to the limitations, below) LIMITATIONS and SCOPE - We're going to have lots and lots of emails flying around. They don't really fit into either -devel or -user, so we'll use a mailist on lilynet.net. Maybe the already-created proposals mailist, maybe a syn...@lilynet.net mailist. Huh? Why would a discussion about syntax not fit into -devel? Anyway, here is my thought: we want a reliably machine-readable and writable input. Everything that does not concern the art of typesetting should be accessable easily from a C parser library. Of course I have my own pet language for manipulating score material (Lua), but then many people do. If one has something like a flex/bison syntax and/or a parser library and/on definite rules for what can, can't be done, then one has a lot of flexibility. The level one would like is that reading lilyput input and writing a lilyput input file that does the same, just transposing a voice, should not take more than 10 lines of code/script. Also reading an input file and writing an equivalent input file (just not using \input anymore) should be easy to do. In a similar vein, score editors should be able to export and import Lilypond code with an expectation of not having information loss occur (short of whitespace/source formatting, and possibly that can be preserved using intelligent schemes as well that keep track of manual source line breaks, indentation and comments). -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lilypond Syntax Development and 3.0
On Mon, Jul 27, 2009 at 01:31:35PM +0200, David Kastrup wrote: Graham Percival gra...@percival-music.ca writes: - We're going to have lots and lots of emails flying around. They don't really fit into either -devel or -user, so we'll use a mailist on lilynet.net. Maybe the already-created proposals mailist, maybe a syn...@lilynet.net mailist. Huh? Why would a discussion about syntax not fit into -devel? Because many suggestions will be silly. Many suggestions will be obviously impractical to developers, but not users. Many threads will devolve into discussions about historical music pedagogical terms. In short, there will be a lot of non-focused chit-chat. In the context of brainstorming and trying to pin down the format, I welcome silly/impractical suggestions (as long as they pertain to the syntax element(s) in question). But in the context of people with limited time trying to get serious work done, easily 90% of the emails about syntax changes will be unwelcome. That's why I propose that the initial discussions take place on a separate list with a mixture of interested users and developers. Once that group has finished discussing a particular syntax change, I'll bring it to -devel. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lilypond Syntax Development and 3.0
On 7/27/09 4:22 AM, Graham Percival gra...@percival-music.ca wrote: I was going to hold off introducing this until the 3-4 major development issues had been sorted out, but the third time I found myself writing yes, I have a plan for this, but I'm going to wait a bit before discussing it, I decided I was behaving like a smarmy teenager. There's nothing time-critical in this thread, so if you're currently working on anything important, skip this email and come back to it later. We won't make any real decisions for a week or so. Lilypond Syntax Development (tentative name) Are you on mind-altering drugs? ;) One of the biggest complaints people have with lilypond -- other than that silly there's no gui -- is the changing syntax. Now, inventing a language or standards is difficult. If you set it in stone too soon, you risk being stuck with decisions which may limit matters. If you keep on updating the syntax, interaction with older data (and other programs!) becomes complex. However, I think we now have a critical mass of interested users, experience with the syntax, and developers. I therefore propose to have a Grand Project devoted to stabilizing the lilypond input format. There's probably another reason why it makes sense to do this at this time: the syntax has largely settled down. SUMMARY Start: Sep 2009. Length: 6-9 months. We're not going to rush this. Goal: define an input format which we commit to being machine-updateable for the forseeable future. Any future patches which change the syntax in a non-convert-ly-able format will be rejected. (subject to the limitations, below) Once this is finished, we will release lilypond 3.0. LIMITATIONS and SCOPE - tweaks will not be included. Anything with \override, \set, \overrideProperty, \tweak, \revert, \unset, #(blah blah) ... including even those names themselves... is still fair game for NOT_SMART convert-ly updates. One nice thing about this limitation is that it allows ongoing syntax development outside of the base syntax. That is, if somebody wants to develop a new feature that is incompatible with the existing base syntax, they can do so in the form of a tweak (in the general sense, not the \tweak sense). They can work out the bugs, get the functionality going, and have usable output, even if it can't be added to the base syntax yet. So this preserves flexibility for development, while stabilizing syntax for standard usage. DISCUSSION Don't respond to any of the specifics yet. Yes, we all have our pet irritations (like what the mao is up with \paper and \layout?!). There will be plenty of time to discuss them. At the moment, I'm looking for comments about the mandate -- what's the scope, how much interest is there, and does anybody object to such work? I'm a bit skeptical that we will be able to really do this job right; and doing it wrong is worse (IMO) than not doing it at all. But I think that it's worth trying (maybe on a separate development branch) so that we can evaluate it before we commit to it. CRESCENDO Reinhold and Frederick: as you may have guessed, I'm proposing that your patch waits until 3.0. Anything requiring such manual tweaks will make some people very unhappy, such as mutopia. What if we added the new crescendo syntax as new syntax (e.g. with something like \newcresc), and kept the old syntax as well (so as not to break existing scores)? This would allow the use of the new syntax in current scores, and get the work going right now. By using different names, we could easily do the convert-ly when it came time to upgrade scores. The new syntax would be converted to version 3.0 syntax automatically, and the old syntax would get a NOT_SMART. We wouldn't need to wait for a year to get it going in this scenario. We'd simply have to live with less-than-optimal-syntax that would be automatically fixable when the new version comes out. This idea is similar to developing a new_foo_engraver, which is eventually phased converted to foo_engraver when the old foo_engraver is removed. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lilypond Syntax Development and 3.0
2009/7/27 Graham Percival gra...@percival-music.ca: Lilypond Syntax Development (tentative name) How about Grand Syntax Project, for Graham-ish consistency's sake? :-) However, I think we now have a critical mass of interested users, experience with the syntax, and developers. I therefore propose to have a Grand Project devoted to stabilizing the lilypond input format. I second this. Goal: define an input format which we commit to being machine-updateable for the forseeable future. Any future patches which change the syntax in a non-convert-ly-able format will be rejected. (subject to the limitations, below) Once this is finished, we will release lilypond 3.0. LIMITATIONS and SCOPE - we need standards for the location of commands. Ligature brackets, I'm looking at you. (non-postfix notation must die!) Yes it must. - we obviously can't /guarantee/ that we'll /never/ make any non-convert-ly changes in the basic format. But we *can* guarantee that such changes would force lilypond 4.0, and that we would only do so for overwhelmingly good reasons. For the past couple of years, the LilyPond language has become increasingly consistent, as exotic command names tend to be replaced: #(set-octavation 1) - \ottava #1 \fatText - \textLengthOn/Off \sustainDown/Up - \sustainOn/Off - We're going to have lots and lots of emails flying around. They don't really fit into either -devel or -user, so we'll use a mailist on lilynet.net. Maybe the already-created proposals mailist, maybe a syn...@lilynet.net mailist. Anyone interested in this may already have a look at lists.lilynet.net/proposals (though it is not meant to be an official mailing list, it might be a good start). - I could be convinced to use the lilynet wiki for this project, although we'd need account-locked pages, and it would increase my workload. Some of us can take care of the wiki part. - after the initial discussion of proposals has died down, I'll bring it to -devel. We're not going to make any (significant) changes without discussing it on -devel, but we're going to have huge threads about English grammar and silly ideas, and I don't want to clutter up -devel. Once whatever chaotic silliness on the syntax list is settled down, I'll bring the ideas to -devel. Absolutely. The more we keep -devel clean, the less we risk losing track of patches and important discussions. Reinhold and Frederick: as you may have guessed, I'm proposing that your patch waits until 3.0. Anything requiring such manual tweaks will make some people very unhappy, such as mutopia. Another possibility would be to have a 3.0 release meister, who could start maintaining a separate alpha branch for major syntax-breaking changes only, while non-syntax work goes on on 2.16. While maintaining LilyPond 2.x remains the absolute priority, this would allow us to take our time with the other branch. Every now and then, we could even publish 3.0 pre-beta GUB builds, on a lilynet-hosted ftp, as an unofficial semi-public testing period (of course, bug reports wouldn't belong on the official tracker, but we could have a special wiki category or something). Of course, this may require more resources than we have. Regards, Valentin ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lilypond Syntax Development and 3.0
Am Montag, 27. Juli 2009 12:22:33 schrieb Graham Percival: CRESCENDO Reinhold and Frederick: as you may have guessed, I'm proposing that your patch waits until 3.0. How about splitting up the patch into backend (i.e. supporting the spanner- type and -text property of the crescendo event in the engraver) and frontend (the new definition of the \cresc command). I'd really like to get the functionality into lilypond (i.e. the backend), since I'm currently preparing Urtext editions with lots of cresc. (http://www.eybler-edition.org/). That way, one can always define one's own \mycresc function that creates a crescendo event with the corresponding properties set, while the \cresc command still shows the old inconsistent behavior. Anything requiring such manual tweaks will make some people very unhappy, such as mutopia. Yes, anything that requires manual changes (or even automated changes) is a real PITA if you are seriously working on larger music editions. This also serves as test of developers: we've avoided getting pinned down with the input syntax because that would limit development. How do you two feel about your hard work on the \cr stuff being delayed by up to a year? I don't mind that much, it just that I rely on properly working text crescendo syntax locally, so I would probably not do much lilypond development if I needed to keep the patch locally... I would be exclusively running my own branch, so any patch to master would require quite a lot of work. Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lilypond Syntax Development and 3.0
In message 87tz0y5pm0@lola.goethe.zz, David Kastrup d...@gnu.org writes If one has something like a flex/bison syntax and/or a parser library and/on definite rules for what can, can't be done, then one has a lot of flexibility. I think we already have an Antlr syntax, don't we? Although iirc it's not actually used in lily itself, but it would be good to take that as a start. Cheers, Wol -- Anthony W. Youngman - anth...@thewolery.demon.co.uk ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lilypond Syntax Development and 3.0
On Mon, Jul 27, 2009 at 07:25:21AM -0600, Carl Sorensen wrote: On 7/27/09 4:22 AM, Graham Percival gra...@percival-music.ca wrote: Lilypond Syntax Development (tentative name) Are you on mind-altering drugs? ;) All the time, baby... sugar, caffene... I suppose even water qualifies. I mean, if I didn't drink water, my mind would certainly be altered! However, I think we now have a critical mass of interested users, experience with the syntax, and developers. I therefore propose to have a Grand Project devoted to stabilizing the lilypond input format. There's probably another reason why it makes sense to do this at this time: the syntax has largely settled down. Yes. There's still a few inconsistencies such as \hideNotes, but a determined push can clear up all those issues. - tweaks will not be included. Anything with \override, \set, \overrideProperty, \tweak, \revert, \unset, #(blah blah) ... including even those names themselves... is still fair game for NOT_SMART convert-ly updates. One nice thing about this limitation is that it allows ongoing syntax development outside of the base syntax. That is, if somebody wants to develop a new feature that is incompatible with the existing base syntax, they can do so in the form of a tweak (in the general sense, not the \tweak sense). They can work out the bugs, get the functionality going, and have usable output, even if it can't be added to the base syntax yet. So this preserves flexibility for development, while stabilizing syntax for standard usage. Yes. Also, the internal definition of \voiceOne or \pointAndClickOn can still be altered at a whim, as long as we update ly/property-init.ly. Reinhold and Frederick: as you may have guessed, I'm proposing that your patch waits until 3.0. Anything requiring such manual tweaks will make some people very unhappy, such as mutopia. What if we added the new crescendo syntax as new syntax (e.g. with something like \newcresc), and kept the old syntax as well (so as not to break existing scores)? Good idea. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lilypond Syntax Development and 3.0
On Mon, Jul 27, 2009 at 03:31:45PM +0200, Valentin Villenave wrote: 2009/7/27 Graham Percival gra...@percival-music.ca: Lilypond Syntax Development (tentative name) How about Grand Syntax Project, for Graham-ish consistency's sake? :-) LSD is much nicer than GSP, though. Reinhold and Frederick: as you may have guessed, I'm proposing that your patch waits until 3.0. Anything requiring such manual tweaks will make some people very unhappy, such as mutopia. Another possibility would be to have a 3.0 release meister, who could start maintaining a separate alpha branch for major syntax-breaking changes only, while non-syntax work goes on on 2.16. While maintaining LilyPond 2.x remains the absolute priority, this would allow us to take our time with the other branch. Not necessary. Most of the work (time-wise) will be discussing potential changes. Once we've decided what changes to make, it shouldn't take more than 2-3 months to get them done. That's eminently within the devel time between stable releases -- I mean, it's even within the aggressive schedule I proposed last Jan. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond tetex-3.0 tested
Sorry to bring up this old issue again, but I think we tried to solve a
non-issue or possibly solve some problem the wrong way.
It should never be necessary to run updmap for the ec-fonts since
the map file is specified explicitly in the call of dvips inside
lilypond and the documentation describes the corresponding flag
for lilypond-book again.
Also, if the ec-fonts installation is done in a way that works
for teTeX-3, then it should also work with teTeX-2, at least if
the files are installed somewhere below /usr/share/texmf/ and
not in any of the /share/texmf-*/ directories that were introduced
in teTeX-3.
/Mats
Mats Bengtsson wrote:
Jan Nieuwenhuizen wrote:
Bertalan Fodor writes:
I made the tests:
1. purge c:\cygwin
2. install old lilypond-2.4.2-1 with default settings - OK (this is
the test that that makes many user problem inexplicable)
:-)
3. install lilypond-2.4.3-1 (built against tetex-2.0) - OK
4. install tetex-3.0.0-1
FAIL1
Solution:
purge texmf/web2c/*.{base,fmt,emft} during tetex-2.0 uninstall
Although that would be the right solution, I'll purge them at the
start of the tetex-3.0 script. I'd rather not build and distribute
another tetex-2.0 version.
FAIL2
ec-fonts are not found
Solution:
updmap --enable
Map=/usr/share/texmf/dvips/ec-fonts-mftraced/ec-mftrace.map
I'm not sure how to overcome this in the packages
How about adding this to lilypond?
No, that's something for the installation script of ec-fonts-mftraced,
but as Bertalan pointed out, if might fail if someone updates from
tetex-2 to tetex-3.
/Mats
--
=
Mats Bengtsson
Signal Processing
Signals, Sensors and Systems
Royal Institute of Technology
SE-100 44 STOCKHOLM
Sweden
Phone: (+46) 8 790 8463
Fax: (+46) 8 790 7260
Email: [EMAIL PROTECTED]
WWW: http://www.s3.kth.se/~mabe
=
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond tetex-3.0 tested
Jan Nieuwenhuizen writes: - release lilypond packaged for tetex-2.0 - release tetex-3 - release ec-fonts for tetex-3, with dependency on tetex - release lilypond packaged for tetex-3.0 Yes, this is cleaner than the lilypond updmap hack. So are we good to go now? Jan. -- Jan Nieuwenhuizen [EMAIL PROTECTED] | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond tetex-3.0 tested
Bertalan Fodor writes: So, the new lilypond must contain the updmap also for ec-fonts-mftraced. This is a must, since ec-fonts doesn't rely on tetex, so tetex-3 may be installed before ec-fonts. Hmm, ok. Because tetex-3.0 will break existing lilypond, we must release tetex-3.0 for cygwin at the same time with lilypond-2.4.3 and ec-fonts-mftraced. Yes. I've added removal of /var/lib/texmf to the post-texmf.sh script, so I can send an update notice right after you lilypond with tetex-3.0 fixes is installed in Cywgin. Jan. -- Jan Nieuwenhuizen [EMAIL PROTECTED] | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond tetex-3.0 tested
Yes. I've added removal of /var/lib/texmf to the post-texmf.sh script, so I can send an update notice right after you lilypond with tetex-3.0 fixes is installed in Cywgin. You must also remove the tetex-2.0 generated files from /usr/share/web2c mf.base, *.fmt, *.emft Bert ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond tetex-3.0 tested
Bertalan Fodor writes: Yes. I've added removal of /var/lib/texmf to the post-texmf.sh script, so I can send an update notice right after you lilypond with tetex-3.0 fixes is installed in Cywgin. You must also remove the tetex-2.0 generated files from /usr/share/web2c ^texmf/ mf.base, *.fmt, *.emft .efmt Ok, added. Jan. -- Jan Nieuwenhuizen [EMAIL PROTECTED] | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
