make doc, problem with bibtex
'make doc' is returning the error below, can you help me? make[2]: Entering directory '/home/fede/lilypond-git/Documentation' BSTINPUTS=./essay /home/fede/lilypond-git/scripts/build/out/bib2texi \ -s /home/fede/lilypond-git/Documentation/lily-bib \ -o ./out-www/colorado.itexi \ -q \ ./essay/colorado.bib bibtex: Not writing to /home/fede/.cache/tmpzYBXQHbib2texi.blg (openout_any = p). I couldn't open file name `/home/fede/.cache/tmpzYBXQHbib2texi.blg' Bibtex exited with nonzero exit status!GNUmakefile:118: recipe for target 'out-www/colorado.itexi' failed make[2]: *** [out-www/colorado.itexi] Error 1 make[2]: Leaving directory '/home/fede/lilypond-git/Documentation' /home/fede/lilypond-git/stepmake/stepmake/generic-targets.make:166: recipe for target 'WWW-1' failed make[1]: *** [WWW-1] Error 2 make[1]: Leaving directory '/home/fede/lilypond-git' /home/fede/lilypond-git/stepmake/stepmake/generic-targets.make:182: recipe for target 'doc-stage-1' failed make: *** [doc-stage-1] Error 2 fede@laptop:~/lilypond-git$ ls ../.cache/tmpzYBXQHbib2texi tmpzYBXQHbib2texi tmpzYBXQHbib2texi.aux .blg file is not there. $ apt-cache policy texlive-bibtex-extra | grep Installed Installed: 2014.20141024-1 Probably not related, but some days ago I changed default TMPDIR (/tmp) to save some space on / partition: $ echo $TMPDIR /home/fede/.cache ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: make doc, problem with bibtex
Federico Bruni fedel...@gmail.com writes: 'make doc' is returning the error below, can you help me? make[2]: Entering directory '/home/fede/lilypond-git/Documentation' BSTINPUTS=./essay /home/fede/lilypond-git/scripts/build/out/bib2texi \ -s /home/fede/lilypond-git/Documentation/lily-bib \ -o ./out-www/colorado.itexi \ -q \ ./essay/colorado.bib bibtex: Not writing to /home/fede/.cache/tmpzYBXQHbib2texi.blg (openout_any = p). 9. TeX can write output files, via the '\openout' primitive; this opens a security hole vulnerable to Trojan horse attack: an unwitting user could run a TeX program that overwrites, say, '~/.rhosts'. Analogous security holes exist for many other programs. To alleviate this, there is a configuration variable 'openout_any', which selects one of three levels of security. When it is set to 'a' (for any), no restrictions are imposed. When it is set to 'r' (for restricted), filenames beginning with '.' are disallowed (except '.tex' because LaTeX needs it). When it is set to 'p' (for paranoid) additional restrictions are imposed: an absolute filename must refer to a file in (a subdirectory) of 'TEXMFOUTPUT', and any attempt to go up a directory level is forbidden (that is, paths may not contain a '..' component). The paranoid setting is the default. (For backwards compatibility, 'y' and '1' are synonyms of 'a', while 'n' and '0' are synonyms for 'r'.) The function 'kpathsea_out_name_ok', with a filename as second argument, returns 'true' if that filename is acceptable to be opend for output or 'false' otherwise. Probably not related, but some days ago I changed default TMPDIR (/tmp) to save some space on / partition: $ echo $TMPDIR /home/fede/.cache It looks to me like .cache starts with a dot... -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: make doc, problem with bibtex
Il giorno sab 1 nov 2014 alle 12:18, David Kastrup d...@gnu.org ha scritto: Probably not related, but some days ago I changed default TMPDIR (/tmp) to save some space on / partition: $ echo $TMPDIR /home/fede/.cache It looks to me like .cache starts with a dot... Ok, the easiest fix was changing TMPDIR to ~/tmp Thanks ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: make doc problem
Reinhold Kainhofer reinh...@kainhofer.com writes: On 2012-01-27 00:00, Julien Rioux wrote: On 26/01/2012 11:13 AM, Reinhold Kainhofer wrote: On 22/01/2012 20:58, Julien Rioux wrote: Thanks, you're quite right CPU is not the limiting factor for the build. Disk access and usage of swap when compiling input/regression/collated-files slows down the build to a crawl for me. The problem here is that lilypond builds up memory from 400MB to ~1GB without releasing... Most of these allocations don't seem to be memory leaks, but rather due to guile. Cheers, Reinhold Is it a bug? We're talking about lilypond running with the -dread-input-files flag here. Once a snippet has been processed and lilypond moves on to the next one, there is no reason to hold onto the memory used by the previous snippet, right? Please check the -devel mailing list (e.g. thread Memleaks or not last August/September), where I already observed this. I fully agree that after one file is processed, lilypond should reset to its initial state and not need more memory than before. I have no idea why the memory is going up like it does. To me it doesn't look like a classical memleak, but rather somthing with the Guile garbage collection... As far as I can see, every music event tends to contain an origin of type Input, and every Input keeps a SourceFile alive, and every SourceFile keeps a string port to the whole file. Any object that does not make it into garbage collection will keep the whole pipe busy. But let's assume this gets collected nicely. In that case, we have the problem that the source files are allocated as _one_ chunk each. If the memory allocator does not have a contiguous piece of memory of that size available, it will have to allocate a new one. And _if_ the memory allocator has a contiguous piece of memory of that size available and somebody asks for small pieces of memory, then it has no business _not_ allocating from the large piece of memory. And the next time a large piece of memory is asked for, there is none available. It might be worth checking whether everything is working as well as one could hope, but there is a non-zero danger that any fixes with good results are to a good degree depending on the operating system as well. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: make doc problem
- Original Message - From: Julien Rioux jri...@physics.utoronto.ca To: lilypond-devel@gnu.org Cc: bug-lilyp...@gnu.org Sent: Thursday, January 26, 2012 11:00 PM Subject: Re: make doc problem On 26/01/2012 11:13 AM, Reinhold Kainhofer wrote: On 22/01/2012 20:58, Julien Rioux wrote: Thanks, you're quite right CPU is not the limiting factor for the build. Disk access and usage of swap when compiling input/regression/collated-files slows down the build to a crawl for me. The problem here is that lilypond builds up memory from 400MB to ~1GB without releasing... Most of these allocations don't seem to be memory leaks, but rather due to guile. Cheers, Reinhold Is it a bug? We're talking about lilypond running with the -dread-input-files flag here. Once a snippet has been processed and lilypond moves on to the next one, there is no reason to hold onto the memory used by the previous snippet, right? -- Julien I'm trying to look at memory usage on my Ubuntu box. If I watch the build using System Monitor, I rarely see more than a gig used. However, using free even my dormant machine is now showing 3 Gigs used. Is this because I have around 2 Gigs marked as cache? Is the actual in-use memory used-cache? -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: make doc problem
- Original Message - From: Phil Holmes m...@philholmes.net To: lilypond-devel@gnu.org; Julien Rioux jri...@physics.utoronto.ca Cc: bug-lilyp...@gnu.org Sent: Friday, January 27, 2012 1:38 PM Subject: Re: make doc problem - Original Message - From: Julien Rioux jri...@physics.utoronto.ca To: lilypond-devel@gnu.org Cc: bug-lilyp...@gnu.org Sent: Thursday, January 26, 2012 11:00 PM Subject: Re: make doc problem On 26/01/2012 11:13 AM, Reinhold Kainhofer wrote: On 22/01/2012 20:58, Julien Rioux wrote: Thanks, you're quite right CPU is not the limiting factor for the build. Disk access and usage of swap when compiling input/regression/collated-files slows down the build to a crawl for me. The problem here is that lilypond builds up memory from 400MB to ~1GB without releasing... Most of these allocations don't seem to be memory leaks, but rather due to guile. Cheers, Reinhold Is it a bug? We're talking about lilypond running with the -dread-input-files flag here. Once a snippet has been processed and lilypond moves on to the next one, there is no reason to hold onto the memory used by the previous snippet, right? -- Julien I'm trying to look at memory usage on my Ubuntu box. If I watch the build using System Monitor, I rarely see more than a gig used. However, using free even my dormant machine is now showing 3 Gigs used. Is this because I have around 2 Gigs marked as cache? Is the actual in-use memory used-cache? Here's a graph of used-cache, which fits well with my observations of system monitor. My machine when lying dormant having finished make/make doc uses 970 MiB memory. The peak I saw during make doc was 2.4 Gig. So make doc takes around 1.4 Gigs when doing its greatest processing with 8 parallel processors. Is this too much for your machine, Julien? If it's a desktop, 4 Gigs of memory is about £30 now, which might be a simpler solution than messing with how make doc runs. -- Phil Holmes attachment: MemUsed.png___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: make doc problem
On 22/01/2012 20:58, Julien Rioux wrote: Thanks, you're quite right CPU is not the limiting factor for the build. Disk access and usage of swap when compiling input/regression/collated-files slows down the build to a crawl for me. The problem here is that lilypond builds up memory from 400MB to ~1GB without releasing... Most of these allocations don't seem to be memory leaks, but rather due to guile. 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 https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: make doc problem
- Original Message - From: Reinhold Kainhofer reinh...@kainhofer.com To: Julien Rioux jri...@physics.utoronto.ca Cc: lilypond-devel@gnu.org; bug-lilyp...@gnu.org Sent: Thursday, January 26, 2012 4:13 PM Subject: Re: make doc problem On 22/01/2012 20:58, Julien Rioux wrote: Thanks, you're quite right CPU is not the limiting factor for the build. Disk access and usage of swap when compiling input/regression/collated-files slows down the build to a crawl for me. The problem here is that lilypond builds up memory from 400MB to ~1GB without releasing... Most of these allocations don't seem to be memory leaks, but rather due to guile. Cheers, Reinhold It only takes that amount of memory for big builds. I've never seen much over 1 Gig total memory during a make with 8 CPUs all running lilypond. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: make doc problem
On 22/01/2012 2:58 PM, Julien Rioux wrote: Thanks, you're quite right CPU is not the limiting factor for the build. Disk access and usage of swap when compiling input/regression/collated-files slows down the build to a crawl for me. Could we redistribute the regression test input files into subfolders of say ~50 files each, possibly sorting them into categories if it makes sense? -- Julien ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: make doc problem
On 26/01/2012 11:13 AM, Reinhold Kainhofer wrote: On 22/01/2012 20:58, Julien Rioux wrote: Thanks, you're quite right CPU is not the limiting factor for the build. Disk access and usage of swap when compiling input/regression/collated-files slows down the build to a crawl for me. The problem here is that lilypond builds up memory from 400MB to ~1GB without releasing... Most of these allocations don't seem to be memory leaks, but rather due to guile. Cheers, Reinhold Is it a bug? We're talking about lilypond running with the -dread-input-files flag here. Once a snippet has been processed and lilypond moves on to the next one, there is no reason to hold onto the memory used by the previous snippet, right? -- Julien ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: make doc problem
On Thu, Jan 26, 2012 at 05:57:43PM -0500, Julien Rioux wrote: On 22/01/2012 2:58 PM, Julien Rioux wrote: Thanks, you're quite right CPU is not the limiting factor for the build. Disk access and usage of swap when compiling input/regression/collated-files slows down the build to a crawl for me. Could we redistribute the regression test input files into subfolders of say ~50 files each, possibly sorting them into categories if it makes sense? Wanted to do that for ages, but that's not something to get into now. But this shouldn't be an issue -- don't we split it into lists of IIRC 300 files? We had some kind of emergency bugfix like that. ... yeah, see make/lysdoc-rules.make You may want to look into that; perhaps changing the division from 300 to 50 would speed up the build? - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: make doc problem
On 26/01/2012 6:14 PM, Graham Percival wrote: On Thu, Jan 26, 2012 at 05:57:43PM -0500, Julien Rioux wrote: On 22/01/2012 2:58 PM, Julien Rioux wrote: Thanks, you're quite right CPU is not the limiting factor for the build. Disk access and usage of swap when compiling input/regression/collated-files slows down the build to a crawl for me. Could we redistribute the regression test input files into subfolders of say ~50 files each, possibly sorting them into categories if it makes sense? Wanted to do that for ages, but that's not something to get into now. But this shouldn't be an issue -- don't we split it into lists of IIRC 300 files? We had some kind of emergency bugfix like that. ... yeah, see make/lysdoc-rules.make You may want to look into that; perhaps changing the division from 300 to 50 would speed up the build? - Graham The `echo' command-line is broken down into 300-file chunks. They all still end up into one collated-files.tely Anyway, it kind of sounds like a workaround or an emergency action as you say. Were the memory released at each snippet then it shouldn't be an issue. Cheers, Julien ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: make doc problem
On 2012-01-27 00:00, Julien Rioux wrote: On 26/01/2012 11:13 AM, Reinhold Kainhofer wrote: On 22/01/2012 20:58, Julien Rioux wrote: Thanks, you're quite right CPU is not the limiting factor for the build. Disk access and usage of swap when compiling input/regression/collated-files slows down the build to a crawl for me. The problem here is that lilypond builds up memory from 400MB to ~1GB without releasing... Most of these allocations don't seem to be memory leaks, but rather due to guile. Cheers, Reinhold Is it a bug? We're talking about lilypond running with the -dread-input-files flag here. Once a snippet has been processed and lilypond moves on to the next one, there is no reason to hold onto the memory used by the previous snippet, right? Please check the -devel mailing list (e.g. thread Memleaks or not last August/September), where I already observed this. I fully agree that after one file is processed, lilypond should reset to its initial state and not need more memory than before. I have no idea why the memory is going up like it does. To me it doesn't look like a classical memleak, but rather somthing with the Guile garbage collection... 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 https://lists.gnu.org/mailman/listinfo/lilypond-devel
make doc problem
Hi all! Not only that I can no longer use -j on a first build (it is OK on the next builds), which means 40' for a make doc LANGS='fr' and about 2 hours for all languages, I now have to make doc-clean in order to view a corrected typo. I've tried a touch masterfile.tely before make doc but it doesn't change anything. Does anybody else experiment this as well? Cheers, Jean-Charles ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: make doc problem
- Original Message - From: Jean-Charles Malahieude lily...@orange.fr To: Lily Bugs bug-lilyp...@gnu.org; lilypond-devel lilypond-devel@gnu.org; Julien Rioux jri...@physics.utoronto.ca Sent: Sunday, January 22, 2012 6:19 PM Subject: make doc problem Hi all! Not only that I can no longer use -j on a first build (it is OK on the next builds), which means 40' for a make doc LANGS='fr' and about 2 hours for all languages, I now have to make doc-clean in order to view a corrected typo. I've tried a touch masterfile.tely before make doc but it doesn't change anything. Does anybody else experiment this as well? Cheers, Jean-Charles I've run a few with -j9 CPU_COUNT=9 this afternoon with no problems. The only oddity I've noticed is that make doc make doc now seems to rebuild a lot of files the second run. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: make doc problem
On 22/01/2012 1:19 PM, Jean-Charles Malahieude wrote: Hi all! Not only that I can no longer use -j on a first build (it is OK on the next builds), which means 40' for a make doc LANGS='fr' and about 2 hours for all languages, I now have to make doc-clean in order to view a corrected typo. I've tried a touch masterfile.tely before make doc but it doesn't change anything. Does anybody else experiment this as well? Cheers, Jean-Charles Hi Jean-Charles, I can't run -j, I have a single core. Can you please report more precisely why you can no longer use it? The second issue I have not seen. If I correct a typo in a file in Documentation then make doc will rebuild it. OK I should check Documentation/fr right now... Regards, Julien ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: make doc problem
On 22/01/2012 1:30 PM, Phil Holmes wrote: I've run a few with -j9 CPU_COUNT=9 this afternoon with no problems. The only oddity I've noticed is that make doc make doc now seems to rebuild a lot of files the second run. -- Phil Holmes I've hit a roadblock with issue 2125 which attempted to fix that make doc; make doc problem. With that patch, on my machine the second make doc reports `nothing to be done'. So it works on my machine but not yours and I haven't quite figured it out yet. Regards, Julien ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: make doc problem
- Original Message - From: Julien Rioux jri...@physics.utoronto.ca To: Phil Holmes m...@philholmes.net Cc: Jean-Charles Malahieude lily...@orange.fr; LilyPond Bugs bug-lilyp...@gnu.org; LilyPond Devel lilypond-devel@gnu.org Sent: Sunday, January 22, 2012 6:35 PM Subject: Re: make doc problem On 22/01/2012 1:30 PM, Phil Holmes wrote: I've run a few with -j9 CPU_COUNT=9 this afternoon with no problems. The only oddity I've noticed is that make doc make doc now seems to rebuild a lot of files the second run. -- Phil Holmes I've hit a roadblock with issue 2125 which attempted to fix that make doc; make doc problem. With that patch, on my machine the second make doc reports `nothing to be done'. So it works on my machine but not yours and I haven't quite figured it out yet. Regards, Julien Please shout if you want logfiles or testing. I can run tests fairly quickly if I've got my lily machine up and running. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: make doc problem
On 22/01/2012 1:32 PM, Julien Rioux wrote: The second issue I have not seen. If I correct a typo in a file in Documentation then make doc will rebuild it. OK I should check Documentation/fr right now... When I edit Documentation/fr/essay/literature.itely and issue a make doc from within build/Documentation/fr then Documentation/fr/essay.tely is recompiled. I can see the result in Documentation/fr/out-www/essay/* and in Documentation/out-www/essay.fr.* [1] Please report in more details the problems that you encounter, e.g. which file are you modifying and how are you calling make. Thanks, Regards, Julien [1] Big side note: It doesn't work flawlessly: notation.tely and a bunch of other manuals are also recompiled when they shouldn't, since I didn't touch any of their source files. This problem I trace back to the CHAIN_RULE in make/ly-rules.make, which I didn't dare touch up to now. This rule states that web depends on usage depends on notation depends on... etc. so that only one instance of lilypond-book is running at once on any given manual. As a side-effect it means that manuals depend on each other when that isn't in fact the case. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: make doc problem
On 22/01/2012 2:11 PM, Jean-Charles Malahieude wrote: What I've done to check is: open Documentation/fr/usage/running.itely add the five X at the beginning of the first text line XCe chapitre passe en revue ce qui se passe lorsque vous lancez LilyPond. save it and make -j3 doc LANGS='fr' File out-www/offline-root/Documentation/usage/running-lilypond.fr.html still shows Ce chapitre passe en revue ce qui se passe lorsque vous lancez LilyPond. -- Jean-Charles You're right, I forgot that I caused that. Give me a moment I will push the fix to staging... Regards, Julien ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: make doc problem
On 22/01/2012 2:15 PM, Julien Rioux wrote: On 22/01/2012 2:11 PM, Jean-Charles Malahieude wrote: What I've done to check is: open Documentation/fr/usage/running.itely add the five X at the beginning of the first text line XCe chapitre passe en revue ce qui se passe lorsque vous lancez LilyPond. save it and make -j3 doc LANGS='fr' File out-www/offline-root/Documentation/usage/running-lilypond.fr.html still shows Ce chapitre passe en revue ce qui se passe lorsque vous lancez LilyPond. -- Jean-Charles You're right, I forgot that I caused that. Give me a moment I will push the fix to staging... Regards, Julien Done: 930dbeff8f5d31faa9654365c8ed84a30e489e83 Hope this fixes it for you as well. Thanks, Julien ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: make doc problem
Le 22/01/2012 20:22, Julien Rioux disait : On 22/01/2012 2:15 PM, Julien Rioux wrote: On 22/01/2012 2:11 PM, Jean-Charles Malahieude wrote: What I've done to check is: open Documentation/fr/usage/running.itely add the five X at the beginning of the first text line XCe chapitre passe en revue ce qui se passe lorsque vous lancez LilyPond. save it and make -j3 doc LANGS='fr' File out-www/offline-root/Documentation/usage/running-lilypond.fr.html still shows Ce chapitre passe en revue ce qui se passe lorsque vous lancez LilyPond. -- Jean-Charles You're right, I forgot that I caused that. Give me a moment I will push the fix to staging... Regards, Julien Done: 930dbeff8f5d31faa9654365c8ed84a30e489e83 Hope this fixes it for you as well. Yes, many thanks! -- Jean-Charles ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: make doc problem
On 22/01/2012 2:38 PM, David Kastrup wrote: Julien Riouxjri...@physics.utoronto.ca writes: I can't run -j, I have a single core. This is factually incorrect. You can run -j just fine, but you can't expect much of a speedup. On a single-core machine, make -j 2 typically gives you a speedup of maybe 15% (given sufficient memory) since the CPU can keep busy on processing a second job when the other job is waiting for the disk to provide new input. More importantly, you'll get to see the same kind of problems that the true multi-core people experience when using -j. So very much recommended for testing. Thanks, you're quite right CPU is not the limiting factor for the build. Disk access and usage of swap when compiling input/regression/collated-files slows down the build to a crawl for me. -- Julien ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: make doc problem
Hello, On 22 January 2012 20:05, David Kastrup d...@gnu.org wrote: Julien Rioux jri...@physics.utoronto.ca writes: Thanks, you're quite right CPU is not the limiting factor for the build. Disk access and usage of swap when compiling input/regression/collated-files slows down the build to a crawl for me. If it is really usage of swap: getting more memory will be by far the cheapest method of speeding up your computer much more than buying a faster CPU ever could. getting an SSD will also help if you have run out of memory slots to fill. -- -- James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
