Re: Doc: Added documentation for fill-line line-width (issue 583340043 by davidgrant...@gmail.com)
On 2020/01/12 23:27:15, thomasmorley651 wrote: The patch itself LGTM Though sometimes I muse about whether we need NR 1.8.2 Formatting text in it's current state at all. Why do we explain some markup-commands explicitely and others not? They are all listed with examples in NR A.11 Text markup commands! An alternative would be to improve examples in the markup-commands where needed (as this patch does for fill-line) and, after explaining what markup is and how to use it, simply point to NR A.11. We already do similiar for markup-list-commands. https://sourceforge.net/p/testlilyissues/issues/5664/ https://codereview.appspot.com/583340043/
Re: Salzburg conference attendance?
Han-Wen Nienhuys writes: > Hey folks, > > I'll be at the Salzburg music engraving event. I was wondering if > there is anything regarding LilyPond that you want my input on. If so, > I can prepare something. I am a bit late to the game, but it's likely more of a longterm concern where it's a good idea to have something eventually for the CG: the LilyPond backend, basically line/page-breaking and positioning, is basically undocumented. Removing "simple closures" and replacing them with "unpure/pure containers" has reduced the number of unknowns, but for the general design there is little knowledge and little experience. That puts a high hurdle to a) adding new elements to LilyPond's typesetting b) improve typesetting results without unforeseen consequences c) make it possible to create custom layouts and page designs, like TeX permits by having the "output routine" that assembles material collected for filling a page something that the user can write by himself and then "shipout" rather than having everything hardwired in C++. This is definitely something that will end up a maintenance bottleneck for whatever developers and applications LilyPond is going to see in future. -- David Kastrup
Re: Cleanup initialization of configure process (issue 549350043 by jonas.hahnf...@gmail.com)
On Jan 15, 2020, at 09:00, jonas.hahnf...@gmail.com wrote: > What's causing problems is that the configure (and only that) > usually lives in the source directory. In fact, I think you can make the > source directory read-only right after running autoconf, everything else > should only touch the build directory. Well, plan to commit the ugly little hack; however, I will experiment with this if I have time. — Dan
Re: Cleanup initialization of configure process (issue 549350043 by jonas.hahnf...@gmail.com)
On 2020/01/15 13:50:29, dan_faithful.be wrote: On Jan 15, 2020, at 03:08, mailto:jonas.hahnf...@gmail.com wrote: > > Maybe I misunderstood your process; aren't you firing up a fresh > container for every build? No, I leave the container running, open an interactive shell into it, and use it for a relatively long time. It is quite like how a VM would be used, but the container holds just the tools required for building, testing, and debugging. Tasks like source control and editing occur on the host. > Just as a thought, then you > could run autogen.sh once on the host in the beginning (or have a second > container that is allowed to write, but only runs autoconf). I couldn't run autoconf on the host, because autoconf is not installed on the host. I could define a second service with write access for running autoconf. But is the root of this problem write permission, or separate source and build directories? Allowing writing to my source tree is something I am willing to consider. Storing 4GB of build output in my source tree is something I have good reasons (mentioned earlier) to resist. The first: I also have separate a build directory (even multiple for the same source directory if needed). You can just execute configure from a different directory, I also do this for most other software that I'm building. What's causing problems is that the configure (and only that) usually lives in the source directory. In fact, I think you can make the source directory read-only right after running autoconf, everything else should only touch the build directory. https://codereview.appspot.com/549350043/
Re: Cleanup initialization of configure process (issue 549350043 by jonas.hahnf...@gmail.com)
On Jan 15, 2020, at 03:08, jonas.hahnf...@gmail.com wrote: > > Maybe I misunderstood your process; aren't you firing up a fresh > container for every build? No, I leave the container running, open an interactive shell into it, and use it for a relatively long time. It is quite like how a VM would be used, but the container holds just the tools required for building, testing, and debugging. Tasks like source control and editing occur on the host. > Just as a thought, then you > could run autogen.sh once on the host in the beginning (or have a second > container that is allowed to write, but only runs autoconf). I couldn't run autoconf on the host, because autoconf is not installed on the host. I could define a second service with write access for running autoconf. But is the root of this problem write permission, or separate source and build directories? Allowing writing to my source tree is something I am willing to consider. Storing 4GB of build output in my source tree is something I have good reasons (mentioned earlier) to resist. > I can > probably live with the found solution for now, let's see how often it > causes headaches in the future. It doesn't seem like the kind of problem that would tend to multiply. > As my comment already hints to, I'm all in favor to drop (at the least > the current version number from) VERSION. I have a patch or two that get > rid of some scripts that rely on VERSION and instead use files generated > by configure. However I don't understand what "make website" does and > how it is used in production right now, so the file is not going away in > the next days. But that's not really the topic of this patch. I agree that it's wise to avoid disturbing `make website` for now. My point is that, if revising `make website` might eliminate the need for the kludge, then it is premature to require me to change my build environment. I'm not asking you to understand it all now, but to understand it before asking me to cope with it. I'm glad to hear that you are willing to live with the kluge for now. — Dan
Re: [Notensatz im 21. Jahrhundert] Lily+Scheme bootcamp?
On Tue, Jan 14, 2020 at 10:38 PM Kieren MacMillan wrote: > > Hi Harm, > > > my talk would be probably of some interest for you. > > It absolutely is. =) > > > Alas, it will be in german, so I can't imagine how helpful it would be for > > you. > > Ja, es ist so lange her, dass ich Deutsch gesprochen habe, dass ich fast > alles vergessen habe!! Doch ich werde da sein. Ich auch, but oh, I wish I could be there! Good luck to you and all! Best, David
Re: Is the CG out of date?
Dear Federico, Thanks. The GitHub file has the changed file name (which I'd worked out), but links to the CG documentation which says to install it as Fedora rather than Debian. I'm a Linux newbie, and don't know if it will make any difference. Any hints are welcome. Best regards, Peter mailto:lilyp...@ptoye.com www.ptoye.com - Tuesday, January 14, 2020, 10:31:49 PM, you wrote: > Il giorno mar 14 gen 2020 alle 18:21, Peter > Toye > ha scritto: >> I'm trying to work out how to run LilyDev in VirtualBox on a Windows >> system., but the information in section 2.1 of the CG seems to be >> inaccurate, and I suspect it's a bit out of date. >> >> Under "Installing LilyDev in VirtualBox" the filename is given as >> lilydev-vm-fedora-VERSION.raw but the downloaded version form the >> website was LilyDev-1-debian-vm.zip >> >> I assume that this is correct, but in that case should I install it >> as Debian rather than Fedora? >> > Yes, the CG is not up-to-date. > Please follow the README files in Github.
Re: Cleanup initialization of configure process (issue 549350043 by jonas.hahnf...@gmail.com)
On 2020/01/14 21:56:24, Dan Eble wrote: On 2020/01/14 18:21:32, hahnjo wrote: > Dan, if you don't want to run autogen.sh with a writable ~/lilypond-src, maybe > you can instead copy all files from that directory to a fresh one in the > container? If this expands to "rsync the latest changes to the build directory before you build; and if you forget, it builds anyway but your changes are disregarded," it's unappealing. Maybe I misunderstood your process; aren't you firing up a fresh container for every build? If you're still doing incremental builds, then this suggestion doesn't work obviously. Just as a thought, then you could run autogen.sh once on the host in the beginning (or have a second container that is allowed to write, but only runs autoconf). But anyway, I'm not going to continue reasoning about an environment that is so distrustful to any script that could do bad things. I can probably live with the found solution for now, let's see how often it causes headaches in the future. If the current little hack threatened to grow into something awful, an important question to ask would be, "What's the problem with having to configure before building the website?" I'm referring to this comment from early on: > Ideally, I'd like to get rid of the VERSION completely, but apparently you can > build the website without configure'ing the project. I wasn't sure if that is > still used, so I went for this solution. As my comment already hints to, I'm all in favor to drop (at the least the current version number from) VERSION. I have a patch or two that get rid of some scripts that rely on VERSION and instead use files generated by configure. However I don't understand what "make website" does and how it is used in production right now, so the file is not going away in the next days. But that's not really the topic of this patch. https://codereview.appspot.com/549350043/
