Re: Further work on reducing make doc output - GOP 9
- Original Message - From: "Graham Percival" To: "Phil Holmes" Cc: "Devel" Sent: Monday, January 16, 2012 3:17 PM Subject: Re: Further work on reducing make doc output - GOP 9 On Sun, Jan 15, 2012 at 02:47:23PM -, Phil Holmes wrote: OK - so I don't think anyone has looked at this. Quick check: - what does 6>&1 do? is that a named pipe? - in general all the symbols looks a bit iffy... if we hadn't just had a huge issue with python subprocess on windows, I'd suggest writing a python script to do this -- it might be 20 lines instead of 13, but IMO "stderr" is more understandable than "1>&6". However, I think we've exhausted our love of python, so go ahead. oh -- maybe some comments? IIRC # is a comment in shell script. other than that, looks good. - Graham Updated version. This one actually redirects the stderr, which the previous one didn't... -- Phil Holmes CheckAndRun.sh Description: Binary data ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Further work on reducing make doc output - GOP 9
Graham Percival writes: > On Sun, Jan 15, 2012 at 02:47:23PM -, Phil Holmes wrote: >> OK - so I don't think anyone has looked at this. > > Quick check: > - what does 6>&1 do? is that a named pipe? Nope, it redirects the output on file descriptor 6 to file descriptor 1, the standard output. Somewhere else, something obviously gets redirected _to_ file descriptor 6. > - in general all the symbols looks a bit iffy... if we hadn't just > had a huge issue with python subprocess on windows, I'd suggest > writing a python script to do this -- it might be 20 lines > instead of 13, but IMO "stderr" is more understandable than > "1>&6". That redirects stdout _to_ file descriptor 6, and would likely be the source of the stuff that gets back via the other redirection. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Further work on reducing make doc output - GOP 9
On Sun, Jan 15, 2012 at 02:47:23PM -, Phil Holmes wrote: > OK - so I don't think anyone has looked at this. Quick check: - what does 6>&1 do? is that a named pipe? - in general all the symbols looks a bit iffy... if we hadn't just had a huge issue with python subprocess on windows, I'd suggest writing a python script to do this -- it might be 20 lines instead of 13, but IMO "stderr" is more understandable than "1>&6". However, I think we've exhausted our love of python, so go ahead. oh -- maybe some comments? IIRC # is a comment in shell script. other than that, looks good. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Further work on reducing make doc output - GOP 9
- Original Message - From: "Colin Campbell" I would imagine you can change/drop the @afourpaper line, although these are only ever intended as a proof of concept, so it's barely worth bothering. Regarding your scripts: can they be modified to accept a variable paper size, for those of us outside the A4 realm? Cheers, Colin -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Further work on reducing make doc output - GOP 9
On 12-01-15 07:47 AM, Phil Holmes wrote: OK - so I don't think anyone has looked at this. I think I've got 3 options: ask again here; make a patch from the test files I created, make a new directory in my lilypond-git directory and put them up, standalone, as a patch on Rietveld for review; or implement this system on the make doc build system and put the patch for review. I'm pretty much against the last one, owing to the chances of wasted time. Could anyone advise on the first 2 options? -- Phil Holmes It would seem reasonable to develop the test against your local doc build, then put up a patch on Rietveld for review, and possibly a Tracker item, as I can't quickly find an open one which would cover this. I suggest that because patches in the formal process seem to have a better chance of review, although not a guarantee. Regarding your scripts: can they be modified to accept a variable paper size, for those of us outside the A4 realm? Cheers, Colin -- I've learned that you shouldn't go through life with a catcher's mitt on both hands. You need to be able to throw something back. -Maya Angelou, poet (1928- ) ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Further work on reducing make doc output - GOP 9
- Original Message - From: "Phil Holmes" To: "Devel" Sent: Tuesday, December 27, 2011 11:34 AM Subject: Further work on reducing make doc output - GOP 9 I've written a shell script that has as its arguments a command line and a logfile. It runs the command, sending the output from that command to the logfile. It then returns the error status from the command line. If an error occurs, it displays a message indicating the name of the logfile. We should be able to use this to reduce the output of make doc considerably, while at the same time retaining the output in logfiles and pointing where to look in the event of a failure. I attach a set of files that can be used to show this in action. Note that one of the .texi files includes a file with errors, and, FWIW, texi2html continues happily, whereas texi2pdf stops on the error. This is also true even with error-limit =0 - texi2html seems to view errored input as simply something worth warning about. Also note the --clean option for texi2pdf - this reduces the cruft in the output directory a lot, and since we now have a separate logfile, I don't know of a reason to keep it. Please let me know if anyone knows different. I will convert this to a patch for proper review, but wanted those who understand Unix scripts to pass their eyes over a simple version first. TIA. OK - so I don't think anyone has looked at this. I think I've got 3 options: ask again here; make a patch from the test files I created, make a new directory in my lilypond-git directory and put them up, standalone, as a patch on Rietveld for review; or implement this system on the make doc build system and put the patch for review. I'm pretty much against the last one, owing to the chances of wasted time. Could anyone advise on the first 2 options? -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Further work on reducing make doc output - GOP 9
I've written a shell script that has as its arguments a command line and a logfile. It runs the command, sending the output from that command to the logfile. It then returns the error status from the command line. If an error occurs, it displays a message indicating the name of the logfile. We should be able to use this to reduce the output of make doc considerably, while at the same time retaining the output in logfiles and pointing where to look in the event of a failure. I attach a set of files that can be used to show this in action. Note that one of the .texi files includes a file with errors, and, FWIW, texi2html continues happily, whereas texi2pdf stops on the error. This is also true even with error-limit =0 - texi2html seems to view errored input as simply something worth warning about. Also note the --clean option for texi2pdf - this reduces the cruft in the output directory a lot, and since we now have a separate logfile, I don't know of a reason to keep it. Please let me know if anyone knows different. I will convert this to a patch for proper review, but wanted those who understand Unix scripts to pass their eyes over a simple version first. TIA. -- Phil Holmes CheckAndRun.sh Description: Binary data GNUmakefile Description: Binary data test.sh Description: Binary data TexiError.texi Description: Binary data ErrorInclude.itexi Description: Binary data TexiTest.texi Description: Binary data ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
