RE: Working on issue 665, how to proceed?

[lilypond]

> -----Oorspronkelijk bericht-----
> Van: Thomas Morley <address@hidden>
> Verzonden: Sunday, November 17, 2019 7:38 PM
> Aan: address@hidden
> CC: David Kastrup <address@hidden>; Urs Liska <address@hidden>;
> lilypond-devel <address@hidden>
> Onderwerp: Re: Working on issue 665, how to proceed?
> 
> Am So., 17. Nov. 2019 um 18:13 Uhr schrieb <address@hidden>:
> >
> > > -----Oorspronkelijk bericht-----
> > > Van: David Kastrup <address@hidden>
> > > > 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