> -----Oorspronkelijk bericht-----
> Van: Thomas Morley <thomasmorle...@gmail.com>
> Verzonden: Sunday, November 17, 2019 7:38 PM
> Aan: lilyp...@de-wolff.org
> CC: David Kastrup <d...@gnu.org>; Urs Liska <lilyli...@googlemail.com>;
> lilypond-devel <lilypond-devel@gnu.org>
> Onderwerp: Re: Working on issue 665, how to proceed?
>
> Am So., 17. Nov. 2019 um 18:13 Uhr schrieb <lilyp...@de-wolff.org>:
> >
> > > -----Oorspronkelijk bericht-----
> > > Van: David Kastrup <d...@gnu.org>
> > > > I did use a lot of define-method, as it is easy this way to be
> > > > type save.
> > >
> > > I don't think the cost justifies the effort here. Scheme is not
> > > intended as a "type safe" language.
>
> What disturbs me are things like:
>
> (define-method (->number (value <boolean>))
> (cond (value 1 (else 0)))
> )
>
> (define-method (->number (value <number>))
> value
> )
>
> (define-method (->number (value <string>))
> (string->number value)
> )
>
Actually I started without this kind of functions, but the lack of
understanding the structure of lilypond made me do it. Let me explain that:
Sometimes I have to make a calculation in code. For that calculation I need a
number. By analyzing the (display $music) I see I can use a music property as
one of the parameters of this calculation However I have no idea if this
parameter is a string or a number. Or worse, I assign the content of a music
property to an attribute of an xml-element, and then when this contents is
moved around I reuse it in a calculation. After I got a few exceptions on this
kind of calculation, I decided to make this kind of methods, for temporary use,
until a function is stable enough then I can remove this work around. But this
is to be used as a temporary solution, and I will mark these methods as: must
be removed before release.
There are more methods that are created as temporary solution.
I will remove all dependencies on those methods, and I will create functions to
be able to catch the callers, but will keep those functions for usage during
development.
> What misses is something like a test-suite.
> Once the code is mature enough to be implemented into core-lilypond, we
> would need to have some sort of regression-tests.
> Currently I've no clue how we could do so, though,
>
I have a kind of test suite: some lilypond files, that I process, and then open
in musescore. 😉
However, using normal tools it is also good possible to automate testing it.
After you have run lilypond on a file, you can run several tests on that file
to check.
For xml files there are a lot of possibilities: I should prefer to use an XPath
expression tester.
It works like this: Say you want to test whether a staccato is placed on the 'C
in measure 2.
Then using XPath expressions you can find an element 'C' in measure 2, which
also has a staccato entry.
This is the XPath expression to find it:
/score-partwise/part/measure[@number='2']/note/pitch/step[text()='C']/../../notations/articulations/staccato
In the same way you can check almost everything with an xpath evaluator. And I
am sure there is one in python.
I will be glad to assist in that process also.
> > And until that I will continue to ask the community for feedback.
> >
> > At the same time I encourage you to use what I have written so far,
> > and appreciate your feedback
>
> You're welcome ;)
>
>
> Cheers,
> Harm
