>
> I think it is unfair to put this burden on us developers
> for the 2.25.xx series.
Fair enough. I was mainly thinking it could be worthwhile for the
developers' sake to reduce the number of email threads from users taken by
surprise when their code stops working. A fair amount of time seems t
>> Do you think this isn't prominently enough? If so, how could this
>> be improved?
>
> I think that as with many warnings, the fact that it's always there
> leads to it fading into the background for many readers,
> particularly as they learn from experience that for *most* code,
> *most* of
>
> Isn't that the reason that the changes documentation is written in the
> first place...to warn users about upcoming changes? So an extra warning
> in the email would be redundant, and this warning would also fade into
> the background? (by the way, I don't think that comparatively a _lot_ of
>
Isn't that the reason that the changes documentation is written in the
first place...to warn users about upcoming changes? So an extra warning
in the email would be redundant, and this warning would also fade into
the background? (by the way, I don't think that comparatively a _lot_ of
users us
>
> Do you think this isn't prominently enough? If so, how could this be
> improved?
>
I think that as with many warnings, the fact that it's always there leads
to it fading into the background for many readers, particularly as they
learn from experience that for *most* code, *most* of the time,
>> if you have reasonable ideas how such API changes could be
>> communicated better I am sure people would love to hear them and if
>> feasible incorporate them.
>
> IMO one relatively simple change would be to add a note to the release
> announcement email mentioning that users should expect to
>
> if you have reasonable ideas how such API changes could be
> communicated better I am sure people would love to hear them and if
> feasible
> incorporate them.
IMO one relatively simple change would be to add a note to the release
announcement email mentioning that users should expect to need
On 2025-02-09 06:32, Valentin Petzel wrote:
the new property is there to allow for convert-ly to automatically make old
things work. I just do not fully understand why it is necessary and could not
simply be handled by adding a conversion function, e.g. turing something like
`...proportionalNota
On 2025-02-08 20:28, Valentin Petzel wrote:> I just don’t get how
adding a new property that is not supposed to be used is perferable to simply
add the conversion directly to the convert-ly rule.
It is difficult -- not simple -- to write perfect conversions. The
"AsMoment" properties allow a
On 2025-02-08 19:45, Paolo Prete wrote:
This is not the case. In fact, the raised warning says:
"warning: the property 'proportionalNotationDuration' must be of type
'non-negative exact rational or +inf.0', ignoring invalid value '#
proportionalNotationDuration is not deprecated. Its type has
AFAIK a normal user should see a warning for a deprecated property and an
error for an API break.
This is not the case: the user here sees a warning for an API break.
Fortunately, out of deliberate fussiness, I made sure that my test cases
already stop corresponding to warnings rather than just err
Hello Paolo,
> Given that, as Valentin noted, a new property has been introduced that
> allows code to be compiled with the old function, what is the point of
> exposing it to the user if it then corresponds to an API break?
> If it had been treated as a deprecated property I could have simply ign
>> proportionalNotationDuration is not deprecated. Its type has been
>> changed, therefore the warning about not accepting a moment is correct.
>
> that's what I was saying. Wouldn't it have been better to treat it
> as a deprecated property with an appropriate warning, rather than as
> an API b
that's what I was saying.
Wouldn't it have been better to treat it as a deprecated property with an
appropriate warning, rather than as an API break with a warning instead of
an error?
Given that, as Valentin noted, a new property has been introduced that
allows code to be compiled with the old fun
Hello Saul,
> The deprecated
> properties provide a way for convert-ly to modify code so it still compiles
> without requiring automatic conversions applied to potentially arbitrary
> Scheme code.
The deprecated syntax is in fact automatically converted. I just don’t get how
adding a new propert
On Sun, Feb 9, 2025 at 2:01 AM Saul Tobin wrote:
>>
>> Instead of the old interface use this deprecated new interface,
>> instead of just: Use the same interface, but you will need to add a type
>> conversion.
>
>
> The deprecated properties aren't intended for end users to write in their
> code.
>
> Instead of the old interface use this deprecated new interface,
> instead of just: Use the same interface, but you will need to add a type
> conversion.
The deprecated properties aren't intended for end users to write in their
code. New human written code should use the non-deprecated names a
On Sun, Feb 9, 2025 at 1:20 AM Valentin Petzel wrote:
>
> Hello Saul,
>
> > I don't want to speak for Dan, but I believe the objective is to get user
> > code moved over to actually using exact rationals rather than moments for
> > these properties, not just to allow the use of exact rationals in
Hello Saul,
> I don't want to speak for Dan, but I believe the objective is to get user
> code moved over to actually using exact rationals rather than moments for
> these properties, not just to allow the use of exact rationals in addition
> to moments.
This is not what I talked about. My point
I don't want to speak for Dan, but I believe the objective is to get user
code moved over to actually using exact rationals rather than moments for
these properties, not just to allow the use of exact rationals in addition
to moments.
It's worth pointing out that there were extended discussions on
Hello Paolo,
> Why has forward compatibility not been ensured for this function?
The relevant merge request is this one:
https://gitlab.com/lilypond/lilypond/-/merge_requests/2546
As you can see this one also introduces a compatibilty property
`proportionalNotationDurationAsMoment` and a conve
LilyPond has never guaranteed backward compatibility of its API between
versions, except for minor versions of the same stable release. It's
usually the case that between any given two versions only a small subset of
code requires changes, but you should always assume that when upgrading to
a new L
Thanks Valentin, I will definitely use it in my code.
But this API change leaves me a bit perplexed. It's the first one I've
encountered since LilyPond 2.19.84! For this reason I am crossposting
this message with the devel mailing list.
Why has forward compatibility not been ensured for this functi
Hello Paolo,
> Is there a way to make this snippet compatible with all LilyPond
> versions starting from 2.19.84?
You could do something like this
```
requireVersion =
#(define-scheme-function (version then else)
(string? scheme? scheme?)
(define (list< x y)
(if (null? x)
#f
Hello everyone,
I've noticed that starting from LilyPond version 2.25.23, this snippet
produces the following warning:
{
\set Score.proportionalNotationDuration = #(ly:make-moment 1 32)
c' c' c'
}
warning: the property 'proportionalNotationDuration' must be of type
'non-negative exact rational o
Michael Gerdau writes:
>> We are happy to announce the release of LilyPond 2.25.23. This is
>> termed a development release, but these are usually reliable for
>> testing new features and recent bug fixes. However, if you require
>> stability, we recommend using ver
We are happy to announce the release of LilyPond 2.25.23. This is
termed a development release, but these are usually reliable for
testing new features and recent bug fixes. However, if you require
stability, we recommend using version 2.24.4, the current stable
release.
Please refer to the
We are happy to announce the release of LilyPond 2.25.23. This is
termed a development release, but these are usually reliable for
testing new features and recent bug fixes. However, if you require
stability, we recommend using version 2.24.4, the current stable
release.
Please refer to the
28 matches
Mail list logo
