lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Issue 915 Multi-measure rests dependent on prefatory matter in other


From: Karl Hammar
Subject: Re: Issue 915 Multi-measure rests dependent on prefatory matter in other staves
Date: Sun, 16 May 2010 15:35:35 +0200 (CEST)

Neil Puttock:
> On 15 May 2010 14:37, Karl Hammar <address@hidden> wrote:
> > git-pull
> > wget http://codereview.appspot.com/download/issue931041_1.diff
> > patch -p1 < issue931041_1.diff --dry-run
> > patch -p1 < issue931041_1.diff
> > make > log 2>&1; make test-redo >> log 2>&1
> 
> I very rarely use `make test-redo'.

The difference between test-redo and check is small:

$ grep -A 6 ^test-redo: GNUmakefile 
test-redo:
        for a in `cat $(RESULT_DIR)/changed.txt` ; do \
                echo removing $$a* ; \
                rm -f $$a* ;\
        done
        $(MAKE) check

$ grep RESULT_DIR GNUmakefile | head -1
RESULT_DIR=$(top-build-dir)/out/test-results
$ cat out/test-results/changed.txt; echo # missing final newline
input/regression/out-test//test-output-distance
input/regression/out-test//rest-collision-beam-note
input/regression/out-test//tree
$

Does it matter, if not, why is in the contributor manual ?

> I basically do what Carl outlined in the other thread:
> 
> make test-baseline
> 
> git apply issue931041_1.diff
> 
> make check

The contributor manual says (3.6.3.1):

   * Initial test:

          make [-jX]
          make test-baseline
          make [-jX CPU_COUNT=X] check

   * Edit/compile/test cycle:

          _## edit source files, then..._

          make clean                    _## only if needed (see below)_
          make [-jX]                    _## only if needed (see below)_
          make test-redo                _## redo files differing from baseline_
          make [-jX CPU_COUNT=X] check  _## CPU_COUNT here?_

   * Reset:

          make test-clean

It has an "make check" after the test-baseline which you don't have, is 
it redundant?

git-apply and patch -p1 produces the same result, so that is not the 
cause of our different output:

$ cd ..
$ cp -a lilypond/ lilypond.b    
$ cd lilypond.b/
$ git-apply -v issue931041_1.diff 
Applied patch lily/bar-line.cc cleanly.
Applied patch lily/include/bar-line.hh cleanly.
Applied patch lily/include/note-spacing.hh cleanly.
Applied patch lily/include/paper-column.hh cleanly.
Applied patch lily/multi-measure-rest.cc cleanly.
Applied patch lily/note-spacing.cc cleanly.
Applied patch lily/paper-column.cc cleanly.
Applied patch scm/define-grob-properties.scm cleanly.
Applied patch scm/define-grobs.scm cleanly.
$ cd ../lilypond
$ patch -p1 < issue931041_1.diff 
patching file lily/bar-line.cc
patching file lily/include/bar-line.hh
patching file lily/include/note-spacing.hh
patching file lily/include/paper-column.hh
patching file lily/multi-measure-rest.cc
patching file lily/note-spacing.cc
patching file lily/paper-column.cc
patching file scm/define-grob-properties.scm
patching file scm/define-grobs.scm
$ cd ..
$ diff -Naur lilypond*       
$

> > Also, it would be much easier to look throuht the patch if it did not
> > contain so many whitespace changes. In the first 100lines, I see:
> 
> Why would you want to look at the bare diff?

Isn't the diff a complete statement of what you want to change?
Also you *did* cite the diff.

>  The whole point of
> uploading the patchset to Rietveld is to make it easier to see the
> changes in each file.

Well, it might help someone else, but not me -- I have mail and git.
Putting things on web sites and getting things from them makes it take
more time.

***

If I take it from the beginning:

$ git-log | head -1
commit 22d889f4d27469864c31db81445e9de49774ae23
$ git-status  
# On branch master
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#       issue1195044_1_2.diff
#       issue1195044_1_3.diff
#       issue931041_1.diff
#       log
nothing added to commit but untracked files present (use "git add" to track)
$ make clean > /dev/null 2>/dev/null
$ make > log 2>&1
$ make test-baseline > log1 2>&1
Processing ./snippet-map-1678077630
...
Processing 41/lily-67666737
Failed files: ()
$ make check > log2 2>&1
Processing ./snippet-map-1678077630
...
Processing 90/lily-015675ea
Failed files: ()
$ patch -p1 < issue931041_1.diff 
$ make > log3 2>&1
$ make test-redo > log4 2>&1
Processing ./snippet-map--1837524129
...
Failed files: ()
$ fgrep '<img src="input/regression/out-test/' out/test-results/index.html | 
grep -v test-output-distance.compare.jpeg
<img src="input/regression/out-test//rest-collision-beam-note.compare.jpeg" 
style="border-style: none; max-width: 500px;">
$ # above file attached
$ make check > log5 2>&1
Processing ./snippet-map-170730255
...
Failed files: ()
$  # the same output is produced
$ ls -1  input/regression/out-test/multi-measure-rest-multi-staff-center*
input/regression/out-test/multi-measure-rest-multi-staff-center-1.eps
input/regression/out-test/multi-measure-rest-multi-staff-center-1.signature
input/regression/out-test/multi-measure-rest-multi-staff-center-systems.count
input/regression/out-test/multi-measure-rest-multi-staff-center-systems.tex
input/regression/out-test/multi-measure-rest-multi-staff-center-systems.texi
input/regression/out-test/multi-measure-rest-multi-staff-center.eps
input/regression/out-test/multi-measure-rest-multi-staff-center.log
input/regression/out-test/multi-measure-rest-multi-staff-center.ly
input/regression/out-test/multi-measure-rest-multi-staff-center.profile
input/regression/out-test/multi-measure-rest-multi-staff-center.texidoc
input/regression/out-test/multi-measure-rest-multi-staff-center.txt
$ # no jpeg
$ cp input/regression/out-test/multi-measure-rest-multi-staff-center.eps .
$ epstopdf multi-measure-rest-multi-staff-center.eps # pdf attached

What can I say?

Regards,
/Karl Hammar

Attachment: rest-collision-beam-note.compare.jpeg
Description: rest-collision-beam-note.compare.jpeg

Attachment: multi-measure-rest-multi-staff-center.pdf
Description: multi-measure-rest-multi-staff-center.pdf


reply via email to

[Prev in Thread] Current Thread [Next in Thread]