Re: Patchy email
On 30.07.19 01:39, David Kastrup wrote: No, that make test needs a fix. make test is supposed to test the version in the work directory, not some weird amalgamate between system installed version and work directory version. Any idea what would be required here? Yes. https://codereview.appspot.com/560840043/ https://sourceforge.net/p/testlilyissues/issues/5544/ Knut ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Fix relocate-preamble.py bug (issue 560840043 by knup...@gmail.com)
Reviewers: , Message: Please review. See 'Re: Patchy email' thread in lilypond-devel. Knut Description: Fix relocate-preamble.py bug In relocate-preamble.py the search path for python modules is changed. If a python script / module used in our regression tests is changed, the results of "make test-baseline", "make test" and patchy are random without this patch: Fresh scripts could load modules installed by an older version of lilypond. Please review this at https://codereview.appspot.com/560840043/ Affected files (+7, -0 lines): M python/relocate-preamble.py.in Index: python/relocate-preamble.py.in diff --git a/python/relocate-preamble.py.in b/python/relocate-preamble.py.in index 13bae3983145b7184ce83859f2faebd608a8da19..8896e8ca0f1187a7f67893862888c334daaa91a5 100644 --- a/python/relocate-preamble.py.in +++ b/python/relocate-preamble.py.in @@ -16,4 +16,11 @@ bindir = os.path.abspath (os.path.dirname (sys.argv[0])) for p in ['share', 'lib']: datadir = os.path.abspath (bindir + '/../%s/lilypond/current/python/' % p) sys.path.insert (0, datadir) + +# Python scripts executed during 'make test' and 'make test-baseline' +# must use their own versions of the scripts and the files loaded by +# those scripts. Assume to be in such a situation if the path to the +# script ends with 'scripts/out'. +if bindir.endswith (r'/scripts/out'): +sys.path.insert (0, bindir + r'/../../python/out') """ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond-book-preamble and cropping
"Urs Liska" writes: > 30. Juli 2019 11:16, "David Kastrup" schrieb: > >> "Urs Liska" writes: >> >>> I'm not sure if this is actually a *development* request or if it >>> could also be solved at the "user" level. >>> >>> As Werner showed in https://github.com/jperon/lyluatex/issues/268 >>> (https://github.com/jperon/lyluatex/issues/268) there is an issue with >>> the output of scores compiled with `lilypond-book-preamble.ly`. AFAICT >>> this is something inherent in the lilypond-book handling which should >>> also be visible in any lilypond-book scores. >>> >>> When compiling with lilypond-book-preamble the score gets sliced in >>> systems, and each system is *additionally cropped*. I have never >>> understood the commands in that file so I don't know in what order >>> these things happen, I don't even know if that lack of the concept of >>> a "page" (we only have a sequence of systems now) affects the actual >>> layout process. >>> >>> Of course you will often want to have the cropped systems, essentially >>> when including single systems in a text document, or at the top or the >>> bottom of pages. However, when stacking the resulting systems this >>> means that the space between systems is inconsistent and generally too >>> narrow. This can sometimes be alleviated by adding space between the >>> systems, but sometimes this doesn't help. As Werner's example images >>> in the issue report linked above show: when a system has much >>> additional stuff above or below (e.g. marks, text or just legder >>> lines) this significantly disturbes the vertical spacing. >>> >>> What I would need to achieve - either by providing some modification >>> of lilypond-book-preamble or as a feature request to be added to >>> LilyPond - is a compilation mode that behaves like >>> lilypond-book-preamble *without the vertical cropping* (but with >>> horizontal cropping). Alternatively (maybe even better) would be >>> writing an additional aux file stating the amount of space cropped, at >>> least at the top and bottom but maybe for all four sides. Or the >>> original image size before cropping. Anything that can be used to >>> infer the space one should add before and after the system to rebuild >>> LilyPond's original page layout. >>> >>> Any ideas? >> >> For employing something like TeX, one needs to know the baseline, the >> top extent, the bottom extent, and the skyline spacing to be used >> between one system and the next. Then one can pad as necessary when >> systems are separated by pagebreaks or other material and use the >> skyline spacing then they aren't. Yes, glue like that can be >> constructed in TeX while still leaving the page break decisions to TeX. >> >> The main problem we are having with cropping is the implementation of >> cross staff material which does not count towards skylines and extents. >> Instead it would need to count towards the upper skyline and extent in >> its top staff, and towards the bottom skyline and extent in its bottom >> staff. That way it would not push apart the systems it crosses while >> still making an impact letting it survive in the bounding boxes. > > I see that an issue is that *of course* a PDF including one system > *has* to cause a problem when two adjacent systems > overlap. https://github.com/jperon/lyluatex/issues/268#issuecomment-516358134 > and > https://github.com/jperon/lyluatex/issues/268#issuecomment-516360973 > show contrived examples compiled with and without > lilypond-book-preamble to demonstrate the problem. > > Would there be any way to get LilyPond to produce a number from which > one can infer the extent by which two adjacent systems should overlap > or have been drawn apart through the page layout? Uh, no? We'd be using them in \score-lines or lilypond-book if they were available, wouldn't we? Flexible spacing and skyline-based spacing only exists internally of LilyPond's page breaker/builder. Cracking this open would certainly increase LilyPond's flexibility a lot and would give the design of custom page layouts a lot more substance. But this is quite a closed box as of now. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond-book-preamble and cropping
30. Juli 2019 11:16, "David Kastrup" schrieb: > "Urs Liska" writes: > >> I'm not sure if this is actually a *development* request or if it >> could also be solved at the "user" level. >> >> As Werner showed in https://github.com/jperon/lyluatex/issues/268 >> (https://github.com/jperon/lyluatex/issues/268) there is an issue with >> the output of scores compiled with `lilypond-book-preamble.ly`. AFAICT >> this is something inherent in the lilypond-book handling which should >> also be visible in any lilypond-book scores. >> >> When compiling with lilypond-book-preamble the score gets sliced in >> systems, and each system is *additionally cropped*. I have never >> understood the commands in that file so I don't know in what order >> these things happen, I don't even know if that lack of the concept of >> a "page" (we only have a sequence of systems now) affects the actual >> layout process. >> >> Of course you will often want to have the cropped systems, essentially >> when including single systems in a text document, or at the top or the >> bottom of pages. However, when stacking the resulting systems this >> means that the space between systems is inconsistent and generally too >> narrow. This can sometimes be alleviated by adding space between the >> systems, but sometimes this doesn't help. As Werner's example images >> in the issue report linked above show: when a system has much >> additional stuff above or below (e.g. marks, text or just legder >> lines) this significantly disturbes the vertical spacing. >> >> What I would need to achieve - either by providing some modification >> of lilypond-book-preamble or as a feature request to be added to >> LilyPond - is a compilation mode that behaves like >> lilypond-book-preamble *without the vertical cropping* (but with >> horizontal cropping). Alternatively (maybe even better) would be >> writing an additional aux file stating the amount of space cropped, at >> least at the top and bottom but maybe for all four sides. Or the >> original image size before cropping. Anything that can be used to >> infer the space one should add before and after the system to rebuild >> LilyPond's original page layout. >> >> Any ideas? > > For employing something like TeX, one needs to know the baseline, the > top extent, the bottom extent, and the skyline spacing to be used > between one system and the next. Then one can pad as necessary when > systems are separated by pagebreaks or other material and use the > skyline spacing then they aren't. Yes, glue like that can be > constructed in TeX while still leaving the page break decisions to TeX. > > The main problem we are having with cropping is the implementation of > cross staff material which does not count towards skylines and extents. > Instead it would need to count towards the upper skyline and extent in > its top staff, and towards the bottom skyline and extent in its bottom > staff. That way it would not push apart the systems it crosses while > still making an impact letting it survive in the bounding boxes. I see that an issue is that *of course* a PDF including one system *has* to cause a problem when two adjacent systems overlap. https://github.com/jperon/lyluatex/issues/268#issuecomment-516358134 and https://github.com/jperon/lyluatex/issues/268#issuecomment-516360973 show contrived examples compiled with and without lilypond-book-preamble to demonstrate the problem. Would there be any way to get LilyPond to produce a number from which one can infer the extent by which two adjacent systems should overlap or have been drawn apart through the page layout? Urs > > -- > David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond-book-preamble and cropping
"Urs Liska" writes: > I'm not sure if this is actually a *development* request or if it > could also be solved at the "user" level. > > As Werner showed in https://github.com/jperon/lyluatex/issues/268 > (https://github.com/jperon/lyluatex/issues/268) there is an issue with > the output of scores compiled with `lilypond-book-preamble.ly`. AFAICT > this is something inherent in the lilypond-book handling which should > also be visible in any lilypond-book scores. > > When compiling with lilypond-book-preamble the score gets sliced in > systems, and each system is *additionally cropped*. I have never > understood the commands in that file so I don't know in what order > these things happen, I don't even know if that lack of the concept of > a "page" (we only have a sequence of systems now) affects the actual > layout process. > > Of course you will often want to have the cropped systems, essentially > when including single systems in a text document, or at the top or the > bottom of pages. However, when stacking the resulting systems this > means that the space between systems is inconsistent and generally too > narrow. This can sometimes be alleviated by adding space between the > systems, but sometimes this doesn't help. As Werner's example images > in the issue report linked above show: when a system has much > additional stuff above or below (e.g. marks, text or just legder > lines) this significantly disturbes the vertical spacing. > > What I would need to achieve - either by providing some modification > of lilypond-book-preamble or as a feature request to be added to > LilyPond - is a compilation mode that behaves like > lilypond-book-preamble *without the vertical cropping* (but with > horizontal cropping). Alternatively (maybe even better) would be > writing an additional aux file stating the amount of space cropped, at > least at the top and bottom but maybe for all four sides. Or the > original image size before cropping. Anything that can be used to > infer the space one should add before and after the system to rebuild > LilyPond's original page layout. > > Any ideas? For employing something like TeX, one needs to know the baseline, the top extent, the bottom extent, and the skyline spacing to be used between one system and the next. Then one can pad as necessary when systems are separated by pagebreaks or other material and use the skyline spacing then they aren't. Yes, glue like that can be constructed in TeX while still leaving the page break decisions to TeX. The main problem we are having with cropping is the implementation of cross staff material which does not count towards skylines and extents. Instead it would need to count towards the upper skyline and extent in its top staff, and towards the bottom skyline and extent in its bottom staff. That way it would not push apart the systems it crosses while still making an impact letting it survive in the bounding boxes. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
lilypond-book-preamble and cropping
I'm not sure if this is actually a *development* request or if it could also be solved at the "user" level. As Werner showed in https://github.com/jperon/lyluatex/issues/268 (https://github.com/jperon/lyluatex/issues/268) there is an issue with the output of scores compiled with `lilypond-book-preamble.ly`. AFAICT this is something inherent in the lilypond-book handling which should also be visible in any lilypond-book scores. When compiling with lilypond-book-preamble the score gets sliced in systems, and each system is *additionally cropped*. I have never understood the commands in that file so I don't know in what order these things happen, I don't even know if that lack of the concept of a "page" (we only have a sequence of systems now) affects the actual layout process. Of course you will often want to have the cropped systems, essentially when including single systems in a text document, or at the top or the bottom of pages. However, when stacking the resulting systems this means that the space between systems is inconsistent and generally too narrow. This can sometimes be alleviated by adding space between the systems, but sometimes this doesn't help. As Werner's example images in the issue report linked above show: when a system has much additional stuff above or below (e.g. marks, text or just legder lines) this significantly disturbes the vertical spacing. What I would need to achieve - either by providing some modification of lilypond-book-preamble or as a feature request to be added to LilyPond - is a compilation mode that behaves like lilypond-book-preamble *without the vertical cropping* (but with horizontal cropping). Alternatively (maybe even better) would be writing an additional aux file stating the amount of space cropped, at least at the top and bottom but maybe for all four sides. Or the original image size before cropping. Anything that can be used to infer the space one should add before and after the system to rebuild LilyPond's original page layout. Any ideas? Thanks Urs ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Patchy email
On 30.07.19 01:39, David Kastrup wrote: Stracing shows that after 'make all' it is also necessary to execute 'make install' prior to 'make test-baseline' or 'make test-clean'. That's insane. Having to install LilyPond before being able to test it makes no sense. During regression testing we use "musicxml2ly --out=- -". A strace log of such a run is in TC.18804. grep ^openat TC.18804 | grep -v ENOENT | grep /home/knut/sources | \ sort | sed -e 's|[^"]*\"/home/knut/sources/lilybuilt|$PREFIX|' \ -e 's|[^"]*\"/home/knut/sources/lily/build|$BUILDDIR|' -e 's|\"[^"]*||' | uniq results in $BUILDDIR/scripts/out/musicxml2ly $PREFIX/share/lilypond/2.21.0/python/lilylib.pyc $PREFIX/share/lilypond/2.21.0/python/lilylib.py $PREFIX/share/lilypond/2.21.0/python/musicexp.pyc $PREFIX/share/lilypond/2.21.0/python/musicexp.py $PREFIX/share/lilypond/2.21.0/python/musicxml2ly_conversion.pyc $PREFIX/share/lilypond/2.21.0/python/musicxml2ly_conversion.py $PREFIX/share/lilypond/2.21.0/python/musicxml.pyc $PREFIX/share/lilypond/2.21.0/python/musicxml.py $PREFIX/share/lilypond/2.21.0/python/rational.pyc $PREFIX/share/lilypond/2.21.0/python/rational.py $PREFIX/share/lilypond/2.21.0/python/utilities.pyc $PREFIX/share/lilypond/2.21.0/python/utilities.py So only the musicxml2ly file is from the version to test, all the other python files are old. If 'make install' is omitted, the result depends both on files from the baseline version and on files that belong to the version of lilypond that was last installed with the same prefix. Then we need to fix that. Yes. If the process also succeeds on your system we would know that patchy needs a fix. No, that make test needs a fix. make test is supposed to test the version in the work directory, not some weird amalgamate between system installed version and work directory version. Any idea what would be required here? The fastest 'fix' would be to compile with a prefix pointing into a subdirectory of the build directory and installing into that prior to 'make test-baseline'. But that is an ugly workaround. I'll have a look at the makefiles this night. Knut ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel