Re: trouble uploading a patch

[Werner LEMBERG]

>> Maybe the solution to the problem is to scrap Win10 altogether.
>> The insidious updates seem to have messed up my permissions, so I
>> can't update VirtualBox -- even running the installer as an
>> administrator.  (Was hoping that a newer version would correct the
>> problem I'm having.)
> 
> Sorry to hear that.  Some time ago I used a dual boot setup. After
> all I hear from Win 10 updates, I'm very happy I dropped windows
> entirely.

Maybe doing the opposite is a possible solution, i.e., running Win 10
within VirtualBox.


Werner

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: trouble uploading a patch

[Thomas Morley]

Hi David,

2017-02-15 0:25 GMT+01:00 David Nalesnik :
> Hi Harm,
>
> On Thu, Feb 9, 2017 at 8:10 AM, David Nalesnik  
> wrote:
>> On Wed, Feb 8, 2017 at 3:46 PM, Thomas Morley  
>> wrote:
>>> 2017-02-08 14:37 GMT+01:00 David Nalesnik :
>>>
 I notice that the patch has gotten swept up into the review process.
 If you like, I will tell James to remove it, or maybe put it into
 waiting so I can figure out how to fix my machine?  (It's already
 gotten a review!) I don't want to put you or anybody to extra trouble.
>>>
>>
>> Hi Harm,
>>
>>>
>>> Hi David,
>>>
>>> I'd happily shepherd this issue.
>>> It would be a pitty to waste the already started review.
>>>
>>> I doubt I can help figuring out whats wrong with your VB, though, if
>>> you think I can check/test anything from my end, please shout.
>>>
>>
>> Thanks--I appreciate this!  I'll wait to collect a good number of
>> review comments before submitting any updates.
>>
>
> OK--I've made a patch update based on the review comments so far.
> (See attachment.)

I'll upload it asap, which will likely be tomorrow evening.

> Maybe the solution to the problem is to scrap Win10 altogether.  The
> insidious updates seem to have messed up my permissions, so I can't
> update VirtualBox -- even running the installer as an administrator.
> (Was hoping that a newer version would correct the problem I'm
> having.)

Sorry to hear that.
Some time ago I used a dual boot setup. After all I hear from Win 10
updates, I'm very happy I dropped windows entirely.

Cheers,
  Harm

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: trouble uploading a patch

[David Nalesnik]

Hi Harm,

On Thu, Feb 9, 2017 at 8:10 AM, David Nalesnik  wrote:
> On Wed, Feb 8, 2017 at 3:46 PM, Thomas Morley  
> wrote:
>> 2017-02-08 14:37 GMT+01:00 David Nalesnik :
>>
>>> I notice that the patch has gotten swept up into the review process.
>>> If you like, I will tell James to remove it, or maybe put it into
>>> waiting so I can figure out how to fix my machine?  (It's already
>>> gotten a review!) I don't want to put you or anybody to extra trouble.
>>
>
> Hi Harm,
>
>>
>> Hi David,
>>
>> I'd happily shepherd this issue.
>> It would be a pitty to waste the already started review.
>>
>> I doubt I can help figuring out whats wrong with your VB, though, if
>> you think I can check/test anything from my end, please shout.
>>
>
> Thanks--I appreciate this!  I'll wait to collect a good number of
> review comments before submitting any updates.
>

OK--I've made a patch update based on the review comments so far.
(See attachment.)

Maybe the solution to the problem is to scrap Win10 altogether.  The
insidious updates seem to have messed up my permissions, so I can't
update VirtualBox -- even running the installer as an administrator.
(Was hoping that a newer version would correct the problem I'm
having.)

Anyway, thanks!

David
From 0fd5890a32e9cb298853b6b8187a51d6ef7bfbc4 Mon Sep 17 00:00:00 2001
From: David Nalesnik 
Date: Sat, 4 Feb 2017 19:13:31 -0600
Subject: [PATCH] Let analysis brackets support text

Ability to add labels to brackets is essential for musical analysis.

This patch introduces a new grob, "HorizontalBracketText," a spanner
created along with "HorizontalBracket" by Horizontal_bracket_engraver.

Repeated text of broken brackets is parenthesized.
---
 Documentation/changes.tely | 18 ++
 Documentation/notation/editorial.itely | 13 ++--
 .../snippets/new/analysis-brackets-with-labels.ly  | 38 ++
 .../regression/horizontal-bracket-broken-texted.ly | 25 ++
 input/regression/horizontal-bracket-texted.ly  | 36 
 lily/horizontal-bracket-engraver.cc| 31 +++---
 lily/horizontal-bracket.cc |  6 +---
 scm/define-grob-interfaces.scm |  5 +++
 scm/define-grob-properties.scm |  1 +
 scm/define-grobs.scm   | 18 ++
 scm/output-lib.scm | 27 +++
 11 files changed, 206 insertions(+), 12 deletions(-)
 create mode 100644 Documentation/snippets/new/analysis-brackets-with-labels.ly
 create mode 100644 input/regression/horizontal-bracket-broken-texted.ly
 create mode 100644 input/regression/horizontal-bracket-texted.ly

diff --git a/Documentation/changes.tely b/Documentation/changes.tely
index 2a64778..f205d00 100644
--- a/Documentation/changes.tely
+++ b/Documentation/changes.tely
@@ -62,6 +62,24 @@ which scares away people.
 @end ignore
 
 @item
+It is now possible to add text to analysis brackets through the
+@code{HorizontalBracketText} object.
+@lilypond[quote,verbatim]
+\layout {
+  \context {
+\Voice
+\consists "Horizontal_bracket_engraver"
+  }
+}
+
+{
+  \once \override HorizontalBracketText.text = "a"
+  c''\startGroup d''\stopGroup
+  e''-\tweak text "a'" \startGroup d''\stopGroup
+}
+@end lilypond
+
+@item
 The ends of hairpins may now be fine-tuned using the @code{shorten-pair}
 grob property, which previously only affected text-spanners like
 @code{TupletBracket} and @code{OttavaBracket}.  Positive values offset
diff --git a/Documentation/notation/editorial.itely b/Documentation/notation/editorial.itely
index 458fce1..8dc3ac9 100644
--- a/Documentation/notation/editorial.itely
+++ b/Documentation/notation/editorial.itely
@@ -879,12 +879,19 @@ Analysis brackets may be nested.
 }
 @end lilypond
 
-@seealso
-Snippets:
-@rlsr{Editorial annotations}.
+@snippets
 
+@lilypondfile[verbatim,quote,ragged-right,texidoc,doctitle]
+{analysis-brackets-above-the-staff.ly}
+
+@lilypondfile[verbatim,quote,ragged-right,texidoc,doctitle]
+{analysis-brackets-with-labels.ly}
+
+@seealso
 Internals Reference:
 @rinternals{Horizontal_bracket_engraver},
 @rinternals{HorizontalBracket},
 @rinternals{horizontal-bracket-interface},
+@rinternals{HorizontalBracketText},
+@rinternals{horizontal-bracket-text-interface},
 @rinternals{Staff}.
diff --git a/Documentation/snippets/new/analysis-brackets-with-labels.ly b/Documentation/snippets/new/analysis-brackets-with-labels.ly
new file mode 100644
index 000..30ae349
--- /dev/null
+++ b/Documentation/snippets/new/analysis-brackets-with-labels.ly
@@ -0,0 +1,38 @@
+\version "2.19.55"
+
+\header {
+  lsrtags = "editorial-annotations, tweaks-and-overrides"
+
+  texidoc = "
+Text may be added to analysis brackets through the @code{text} property
+of the @code{HorizontalBracketText} grob.  Adding 

Re: Add lilypond version predicates/operators (issue 317270043 by g...@ursliska.de)

[David Kastrup]

thomasmorle...@gmail.com writes:

> To throw in my own 2cts.
>
> Why not compare strings, looks more straight forward to me.
>
> (define (calculate-version-harm ref-version)
>   (cond ((string? ref-version) ref-version)
> ((number-list? ref-version)
>  (string-concatenate (list-join (map number->string ref-version)
> ".")))
> (else (ly:error "whatever-massage"
>
> (define (version-compare? op v1 v2)
> "Compare two versions @var{v1} and @var{v2} with the operator @var{op}.
>   The operator would typically be
>   string=?, string? , string>=? , etc."
>  (op (calculate-version-harm v1) (calculate-version-harm v2)))
>
> The issue I can imagine: probably more expensive, especially with
> guilev2

Because (string #t

> https://codereview.appspot.com/317270043/


-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Add lilypond version predicates/operators (issue 317270043 by g...@ursliska.de)

[Urs Liska]

Hi Harm,


Am 14.02.2017 um 22:03 schrieb thomasmorle...@gmail.com:
> To throw in my own 2cts.
>
> Why not compare strings, looks more straight forward to me.
>
>

Indeed your code looks simpler, and your measurement indicates that the
computational cost is very similar.
However, David's last comment(s) made me think that this can be quite
useful beyond mere LilyPond version comparison, namely a generic
list-compare? or so. Although our handling of missing trailing elements
is pretty specific to *version* comparison.


I think I'll stick to the recursive list comparison and make it more
generic using David's suggestion.

Urs

>
>
> Cheers,
>   Harm
>
> https://codereview.appspot.com/317270043/
>
> ___
> lilypond-devel mailing list
> lilypond-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-devel

-- 
u...@openlilylib.org
https://openlilylib.org
http://lilypondblog.org


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Add lilypond version predicates/operators (issue 317270043 by g...@ursliska.de)

[thomasmorley65]

On 2017/02/14 21:08:48, thomasmorley651 wrote:


> The issue I can imagine: probably more expensive, especially with

guilev2

Please disregard the time values from my previous posts, they are
adulterated by the problems of _LilyPond_ with guile2

Doing all in pure guile-2.1.6 gives:

string-comparison:
$ time guile --no-auto-compile guile-test.scm
#t#t#f

real0m0.038s
user0m0.028s
sys 0m0.008s

list-comparison:
$ time guile --no-auto-compile guile-test.scm
#t#f#f

real0m0.037s
user0m0.024s
sys 0m0.016s





https://codereview.appspot.com/317270043/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Add lilypond version predicates/operators (issue 317270043 by g...@ursliska.de)

[thomasmorley65]

On 2017/02/14 21:03:19, thomasmorley651 wrote:

To throw in my own 2cts.



Why not compare strings, looks more straight forward to me.



(define (calculate-version-harm ref-version)
   (cond ((string? ref-version) ref-version)
 ((number-list? ref-version)
  (string-concatenate (list-join (map number->string

ref-version) ".")))

 (else (ly:error "whatever-massage"



(define (version-compare? op v1 v2)
"Compare two versions @var{v1} and @var{v2} with the operator

@var{op}.

   The operator would typically be
   string=?, string? , string>=? , etc."
  (op (calculate-version-harm v1) (calculate-version-harm v2)))



;; Examples
(write (version-compare? string=? (lilypond-version) (ly:version)))
(write (version-compare? string>? "2.19.57" (ly:version)))
(write (version-compare? string<=? "2.19.57" (lilypond-version)))



The issue I can imagine: probably more expensive, especially with

guilev2


In a ly-file:



$ time lilydevel atest-48.ly
GNU LilyPond 2.19.52
Processing `atest-48.ly'
Parsing...#t#t#f
Success: compilation successfully completed



real0m1.279s
user0m1.148s
sys 0m0.128s



Using a build from (not so) recent master, with guile-2.1.6:



$ time lilypond-git atest-48.ly
GNU LilyPond 2.19.55
Import (ice-9 threads) to have access to `call-with-new-thread'.
Import (ice-9 threads) to have access to `current-thread'.
Processing `atest-48.ly'
Parsing...#t#t#f
Success: compilation successfully completed



real0m5.145s
user0m5.620s
sys 0m0.120s




Cheers,
   Harm


Here the values for Urs' proposal

$ time lilydevel atest-48.ly
GNU LilyPond 2.19.52
Processing `atest-48.ly'
Parsing...#t#f#f
Success: compilation successfully completed

real0m1.307s
user0m1.204s
sys 0m0.100s


$ time lilypond-git atest-48.ly
GNU LilyPond 2.19.55
Import (ice-9 threads) to have access to `call-with-new-thread'.
Import (ice-9 threads) to have access to `current-thread'.
Processing `atest-48.ly'
Parsing...#f#f#f
Success: compilation successfully completed

real0m5.239s
user0m5.756s
sys 0m0.084s


https://codereview.appspot.com/317270043/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Add lilypond version predicates/operators (issue 317270043 by g...@ursliska.de)

[thomasmorley65]

To throw in my own 2cts.

Why not compare strings, looks more straight forward to me.

(define (calculate-version-harm ref-version)
  (cond ((string? ref-version) ref-version)
((number-list? ref-version)
 (string-concatenate (list-join (map number->string ref-version)
".")))
(else (ly:error "whatever-massage"

(define (version-compare? op v1 v2)
"Compare two versions @var{v1} and @var{v2} with the operator @var{op}.
  The operator would typically be
  string=?, string? , string>=? , etc."
 (op (calculate-version-harm v1) (calculate-version-harm v2)))

;; Examples
(write (version-compare? string=? (lilypond-version) (ly:version)))
(write (version-compare? string>? "2.19.57" (ly:version)))
(write (version-compare? string<=? "2.19.57" (lilypond-version)))

The issue I can imagine: probably more expensive, especially with
guilev2

In a ly-file:

$ time lilydevel atest-48.ly
GNU LilyPond 2.19.52
Processing `atest-48.ly'
Parsing...#t#t#f
Success: compilation successfully completed

real0m1.279s
user0m1.148s
sys 0m0.128s

Using a build from (not so) recent master, with guile-2.1.6:

$ time lilypond-git atest-48.ly
GNU LilyPond 2.19.55
Import (ice-9 threads) to have access to `call-with-new-thread'.
Import (ice-9 threads) to have access to `current-thread'.
Processing `atest-48.ly'
Parsing...#t#t#f
Success: compilation successfully completed

real0m5.145s
user0m5.620s
sys 0m0.120s


Cheers,
  Harm

https://codereview.appspot.com/317270043/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Add lilypond version predicates/operators (issue 317270043 by g...@ursliska.de)

[dak]

On 2017/02/14 18:20:56, git wrote:


Ah yes. I had removed the
   (and (eq? op =)
part, which I shouldn't have done


Well, that works only for a very particular equivalence.  How about
something like

#(define (lexicographically op a b)
   (let* ((ca (car a))
  (iseql (op ca ca)))
 (let loop ((ca ca) (cb (car b)) (a (cdr a)) (b (cdr b)))
   (let ((axb (op ca cb)))
 (if (and (pair? a) (pair? b)
  (eq? axb iseql (op cb ca)))
 (loop (car a) (car b) (cdr a) (cdr b))
 axb)

#(define (ly:version? op . rest)
  (lexicographically op (ly:version) rest))

#(format #t "> 2.19 : ~S, >= 2.19 : ~S\n= 2.16 : ~S, = 2.19 : ~S\n"
 (ly:version? > 2 19)
 (ly:version? >= 2 19)
 (ly:version? = 2 16)
 (ly:version? = 2 19))


https://codereview.appspot.com/317270043/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Add lilypond version predicates/operators (issue 317270043 by g...@ursliska.de)

[git]

https://codereview.appspot.com/317270043/diff/20001/scm/lily-library.scm
File scm/lily-library.scm (right):

https://codereview.appspot.com/317270043/diff/20001/scm/lily-library.scm#newcode899
scm/lily-library.scm:899: (let* ((a (car v1)) (b (car v2))
On 2017/02/14 17:29:33, dak wrote:

Requires v1/v2 to have at least one element.  Admittedly quite a

reasonable

precondition.



OIf we have that, we don't need (op 0 0) but can use (op a a) instead.

 The

advantage is that we are no longer bound to _numeric_ comparisons

then.  This

lexicographic compare will then also work with string= and similar.


Acknowledged.

https://codereview.appspot.com/317270043/diff/20001/scm/lily-library.scm#newcode903
scm/lily-library.scm:903: ((not axb) #f)
On 2017/02/14 17:29:33, dak wrote:

This will let (version-compare? '(2 18) < '(2 19)) deliver #f after

comparing

only 2 with 2, right?


Ah yes. I had removed the
  (and (eq? op =)
part, which I shouldn't have done

https://codereview.appspot.com/317270043/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Add lilypond version predicates/operators (issue 317270043 by g...@ursliska.de)

[dak]

https://codereview.appspot.com/317270043/diff/20001/scm/lily-library.scm
File scm/lily-library.scm (right):

https://codereview.appspot.com/317270043/diff/20001/scm/lily-library.scm#newcode899
scm/lily-library.scm:899: (let* ((a (car v1)) (b (car v2))
Requires v1/v2 to have at least one element.  Admittedly quite a
reasonable precondition.

OIf we have that, we don't need (op 0 0) but can use (op a a) instead.
The advantage is that we are no longer bound to _numeric_ comparisons
then.  This lexicographic compare will then also work with string= and
similar.

https://codereview.appspot.com/317270043/diff/20001/scm/lily-library.scm#newcode903
scm/lily-library.scm:903: ((not axb) #f)
This will let (version-compare? '(2 18) < '(2 19)) deliver #f after
comparing only 2 with 2, right?

https://codereview.appspot.com/317270043/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Lily version operators documentation

[Trevor Daniels]

Urs Liska wrote Tuesday, February 14, 2017 9:23 AM

> my patch https://sourceforge.net/p/testlilyissues/issues/5067/
> http://codereview.appspot.com/317270043 is currently on countdown. It
> introduces the procedures
> 
> - lilypond>?
> - lilypond>=?
> - lilypond - lilypond<=?
> - lilypond=?
> 
> comparing a given version to the one currently compiling the document.
> This makes it possible to write library code supporting multiple
> LilyPond versions across syntax changes.
> 
> My question is: Where can I add documentation for this? Browsing through
> Extending and IR doesn't seem to indicate a suitable place. It *might*
> be fitting somewhere in the "General input and output" of the NR, but
> I'm way from being sure about that either.

As these functions are not intended for the usual LilyPond user I
don't think the NR is suitable, other than to have them listed in A22.
Similarly, they will also be listed in the IR under Scheme functions.

Perhaps the best place to add a description is in Section 2 of the
Usage Manual where convert-ly is discussed?  A new subsection 
2.2 Testing the version (displacing the existing sections down 1)
could be added.  But I concede mixing with convert-ly is hardly ideal.

Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Add lilypond version predicates/operators (issue 317270043 by g...@ursliska.de)

[dak]

On 2017/02/14 15:51:13, dak wrote:

On 2017/02/14 15:49:26, dak wrote:
> On 2017/02/14 15:46:20, git wrote:
> > On 2017/02/14 15:37:35, pwm wrote:
> > > On 2017/02/14 15:15:07, git wrote:
> > > > I like this more because it's more of a typical procedure

invocation.

> > > > I think I'll create a new patch with this and a simplified
> calculate-version
> > > > (that doesn't accept string lists)
> > >
> > > Well, having the procedure as the first argument might be more

scheme-ish?

> > >
> > > Maybe best would be to have a "version-compare" function that

compares two

> > > version lists using a procedure.  Then define "ly:version?" so

it calls

> > > "version-compare" with the current LilyPond version (to handle

the primary

> use
> > > case).  The "version-compare" function could be David's looping

function,

> but
> > > modified so that it took two version lists and a procedure as

arguments.

> >
> > This is what I'm currently working on.
> > However, I found an issue in David's suggestion, namely the
> > (op 0 0) ;; return #t iff op includes equality
> > line.
> > This makes the function return #t when comparing with = and one

list

shortened
> > Try e.g. (ly:version? = 2 16)
> > This returns #t because in the third iteration when the reference

version

has
> > run out of elements it compares 0 to 0.
>
> Have you actually tried it?  If your major version is not actually

2.16, you

> will not even _get_ into a third iteration.



Ok, I take that back.  I admit that the tie-breaker does not work with

strict

equality.  I'll have to think about it.


How about:

#(define (ly:version? op . rest)
   (define eqlop (op 0 0))
   (let loop ((ver (ly:version)) (rest rest))
 (if (or (null? ver) (null? rest))
 eqlop
 (let* ((a (car ver)) (b (car rest))
(axb (op a b)) (bxa (op b a)))
   (if (eq? axb bxa eqlop)
   (loop (cdr ver) (cdr rest))
   axb)


#(format #t "> 2.19 : ~S, >= 2.19 : ~S\n= 2.16 : ~S, = 2.19 : ~S\n"
 (ly:version? > 2 19)
 (ly:version? >= 2 19)
 (ly:version? = 2 16)
 (ly:version? = 2 19))


https://codereview.appspot.com/317270043/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Add lilypond version predicates/operators (issue 317270043 by g...@ursliska.de)

[git]

> > However, I found an issue in David's suggestion, namely the
> > (op 0 0) ;; return #t iff op includes equality
> > line.
> > This makes the function return #t when comparing with = and one

list

shortened
> > Try e.g. (ly:version? = 2 16)
> > This returns #t because in the third iteration when the reference

version

has
> > run out of elements it compares 0 to 0.
>
> Have you actually tried it?  If your major version is not actually

2.16, you

> will not even _get_ into a third iteration.



Ok, I take that back.  I admit that the tie-breaker does not work with

strict

equality.  I'll have to think about it.


Yes, my interpretation was wrong (as it's not related to the list
length).

But I've found the solution (I hope)
I need a three-way switch when jumping in the loop:
- Both lists have no further elements: Return current result
- One list has no further elements: Return (op 0 0)
- Both lists have further elements: go into the recursion.

I'll upload a new patch, combining this with Paul's interface suggestion

https://codereview.appspot.com/317270043/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Add lilypond version predicates/operators (issue 317270043 by g...@ursliska.de)

[dak]

On 2017/02/14 15:46:20, git wrote:

On 2017/02/14 15:37:35, pwm wrote:
> On 2017/02/14 15:15:07, git wrote:
> > I like this more because it's more of a typical procedure

invocation.

> > I think I'll create a new patch with this and a simplified

calculate-version

> > (that doesn't accept string lists)
>
> Well, having the procedure as the first argument might be more

scheme-ish?

>
> Maybe best would be to have a "version-compare" function that

compares two

> version lists using a procedure.  Then define "ly:version?" so it

calls

> "version-compare" with the current LilyPond version (to handle the

primary use

> case).  The "version-compare" function could be David's looping

function, but

> modified so that it took two version lists and a procedure as

arguments.


This is what I'm currently working on.
However, I found an issue in David's suggestion, namely the
(op 0 0) ;; return #t iff op includes equality
line.
This makes the function return #t when comparing with = and one list

shortened

Try e.g. (ly:version? = 2 16)
This returns #t because in the third iteration when the reference

version has

run out of elements it compares 0 to 0.


Have you actually tried it?  If your major version is not actually 2.16,
you will not even _get_ into a third iteration.

https://codereview.appspot.com/317270043/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Add lilypond version predicates/operators (issue 317270043 by g...@ursliska.de)

[dak]

On 2017/02/14 15:49:26, dak wrote:

On 2017/02/14 15:46:20, git wrote:
> On 2017/02/14 15:37:35, pwm wrote:
> > On 2017/02/14 15:15:07, git wrote:
> > > I like this more because it's more of a typical procedure

invocation.

> > > I think I'll create a new patch with this and a simplified
calculate-version
> > > (that doesn't accept string lists)
> >
> > Well, having the procedure as the first argument might be more

scheme-ish?

> >
> > Maybe best would be to have a "version-compare" function that

compares two

> > version lists using a procedure.  Then define "ly:version?" so it

calls

> > "version-compare" with the current LilyPond version (to handle the

primary

use
> > case).  The "version-compare" function could be David's looping

function,

but
> > modified so that it took two version lists and a procedure as

arguments.

>
> This is what I'm currently working on.
> However, I found an issue in David's suggestion, namely the
> (op 0 0) ;; return #t iff op includes equality
> line.
> This makes the function return #t when comparing with = and one list

shortened

> Try e.g. (ly:version? = 2 16)
> This returns #t because in the third iteration when the reference

version has

> run out of elements it compares 0 to 0.



Have you actually tried it?  If your major version is not actually

2.16, you

will not even _get_ into a third iteration.


Ok, I take that back.  I admit that the tie-breaker does not work with
strict equality.  I'll have to think about it.

https://codereview.appspot.com/317270043/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Add lilypond version predicates/operators (issue 317270043 by g...@ursliska.de)

[dak]

On 2017/02/14 15:37:35, pwm wrote:

On 2017/02/14 15:15:07, git wrote:
> I like this more because it's more of a typical procedure

invocation.

> I think I'll create a new patch with this and a simplified

calculate-version

> (that doesn't accept string lists)



Well, having the procedure as the first argument might be more

scheme-ish?


Maybe best would be to have a "version-compare" function that compares

two

version lists using a procedure.  Then define "ly:version?" so it

calls

"version-compare" with the current LilyPond version (to handle the

primary use

case).  The "version-compare" function could be David's looping

function, but

modified so that it took two version lists and a procedure as

arguments.

It's not a "version-compare" as much as a "lexicographic-compare".

https://codereview.appspot.com/317270043/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Add lilypond version predicates/operators (issue 317270043 by g...@ursliska.de)

[git]

On 2017/02/14 15:37:35, pwm wrote:

On 2017/02/14 15:15:07, git wrote:
> I like this more because it's more of a typical procedure

invocation.

> I think I'll create a new patch with this and a simplified

calculate-version

> (that doesn't accept string lists)



Well, having the procedure as the first argument might be more

scheme-ish?


Maybe best would be to have a "version-compare" function that compares

two

version lists using a procedure.  Then define "ly:version?" so it

calls

"version-compare" with the current LilyPond version (to handle the

primary use

case).  The "version-compare" function could be David's looping

function, but

modified so that it took two version lists and a procedure as

arguments.

This is what I'm currently working on.
However, I found an issue in David's suggestion, namely the
(op 0 0) ;; return #t iff op includes equality
line.
This makes the function return #t when comparing with = and one list
shortened
Try e.g. (ly:version? = 2 16)
This returns #t because in the third iteration when the reference
version has
run out of elements it compares 0 to 0.

https://codereview.appspot.com/317270043/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Add lilypond version predicates/operators (issue 317270043 by g...@ursliska.de)

[paulwmorris]

On 2017/02/14 15:15:07, git wrote:

I like this more because it's more of a typical procedure invocation.
I think I'll create a new patch with this and a simplified

calculate-version

(that doesn't accept string lists)


Well, having the procedure as the first argument might be more
scheme-ish?

Maybe best would be to have a "version-compare" function that compares
two version lists using a procedure.  Then define "ly:version?" so it
calls "version-compare" with the current LilyPond version (to handle the
primary use case).  The "version-compare" function could be David's
looping function, but modified so that it took two version lists and a
procedure as arguments.

https://codereview.appspot.com/317270043/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Add lilypond version predicates/operators (issue 317270043 by g...@ursliska.de)

[git]

On 2017/02/14 15:00:10, pwm wrote:

https://codereview.appspot.com/317270043/diff/1/scm/lily-library.scm
File scm/lily-library.scm (right):



https://codereview.appspot.com/317270043/diff/1/scm/lily-library.scm#newcode909

scm/lily-library.scm:909: (define-public (lilypond>? ref-version)
Instead of a separate procedure for each comparison, what about making

it

generic:



(define-public (version-compare v1 proc v2)
   "Compare two versions @var{v1} and @var{v2} with the
procedure @var{proc}.  The versions are lists of
three numbers like @code{'(2 18 0)}.  The procedure
would typically be <, >, <=, >=, =, etc."
   (proc (calculate-version v1) (calculate-version v2)))



Usage looks like:



(version-compare (ly:version) >= '(2 18 0))



Then it can be used to compare any two versions, not necessarily

LilyPond (might

also be useful for packages some day?) and the user learns ly:version.




(Having done this, I see David's suggestion... haven't looked at it

closely

yet.)


I like this more because it's more of a typical procedure invocation.
I think I'll create a new patch with this and a simplified
calculate-version
(that doesn't accept string lists)

https://codereview.appspot.com/317270043/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Add lilypond version predicates/operators (issue 317270043 by g...@ursliska.de)

[git]

Reviewers: dak, pwm,

Message:
I'm choking a little bit with having the operator as the first argument
instead of
actually being the first element. But apart from that this solution
works very well.
And as this is not intended to be end-user facing code it's of course OK
to have
just one single possible input format (number list and no version
string).

Description:
Add lilypond version predicates/operators

This set of predicates/operators compares a given reference version
to the LilyPond version that is currently being executed.
This makes it possible to implement "version switches" to write
(library) code that is compatible over syntax changes.

NOTE: I'm not sure where (and if) this should be documented.
Please make suggestions

Please review this at https://codereview.appspot.com/317270043/

Affected files (+48, -0 lines):
  M scm/lily-library.scm


Index: scm/lily-library.scm
diff --git a/scm/lily-library.scm b/scm/lily-library.scm
index  
214c095cf2c720c0429cb8dfc6b753acc1304b77..ab6d5655321d2a20feef569c74fb799101a0710b  
100644

--- a/scm/lily-library.scm
+++ b/scm/lily-library.scm
@@ -888,6 +888,54 @@ and will be applied to NUM."
 (fancy-format #f (car custom-format) num))
(else (fancy-format #f "~(~@r~)" num

+;;
+;; lilypond version
+
+(define (calculate-version ref-version)
+  "Return an integer representation of the LilyPond version,
+   can be compared with the operators."
+  (let*
+   ((v-list
+ (if (number-list? ref-version)
+ (map truncate ref-version)
+ (map string->number (string-split ref-version #\.
+(use-list
+ (list-head
+  (append v-list (make-list (max 0 (- 3 (length v-list))) 0)) 3)))
+   (+ (* 100 (first use-list))
+ (* 1000 (second use-list))
+ (third use-list
+
+(define-public (lilypond>? ref-version)
+  "Return #t if the executed LilyPond version
+   is greater than the given @var{ref-version}"
+  (> (calculate-version (ly:version))
+ (calculate-version ref-version)))
+
+(define-public (lilypond>=? ref-version)
+  "Return #t if the executed LilyPond version
+   is greater than or equal to the given @var{ref-version}"
+  (>= (calculate-version (ly:version))
+  (calculate-version ref-version)))
+
+(define-public (lilypondhttps://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Add lilypond version predicates/operators (issue 317270043 by g...@ursliska.de)

[paulwmorris]

https://codereview.appspot.com/317270043/diff/1/scm/lily-library.scm
File scm/lily-library.scm (right):

https://codereview.appspot.com/317270043/diff/1/scm/lily-library.scm#newcode909
scm/lily-library.scm:909: (define-public (lilypond>? ref-version)
Instead of a separate procedure for each comparison, what about making
it generic:

(define-public (version-compare v1 proc v2)
  "Compare two versions @var{v1} and @var{v2} with the
   procedure @var{proc}.  The versions are lists of
   three numbers like @code{'(2 18 0)}.  The procedure
   would typically be <, >, <=, >=, =, etc."
  (proc (calculate-version v1) (calculate-version v2)))

Usage looks like:

(version-compare (ly:version) >= '(2 18 0))

Then it can be used to compare any two versions, not necessarily
LilyPond (might also be useful for packages some day?) and the user
learns ly:version.

(Having done this, I see David's suggestion... haven't looked at it
closely yet.)

https://codereview.appspot.com/317270043/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Add lilypond version predicates/operators (issue 317270043 by g...@ursliska.de)

[dak]

https://codereview.appspot.com/317270043/diff/1/scm/lily-library.scm
File scm/lily-library.scm (right):

https://codereview.appspot.com/317270043/diff/1/scm/lily-library.scm#newcode894
scm/lily-library.scm:894: (define (calculate-version ref-version)
This seems overly complicated.  Why not just stick with a number list?
Something like
#(define (ly:version? op . rest)
   (let loop ((ver (ly:version)) (rest rest))
 (if (or (null? ver) (null? rest))
 (op 0 0) ;; return #t iff op includes equality
 (let* ((a (car ver)) (b (car rest))
(axb (op a b)) (bxa (op b a)))
   (if (eq? axb bxa)
   (loop (cdr ver) (cdr rest))
   axb)

#(format #t ">2.19 : ~S, >= 2.19 : ~S\n"
 (ly:version? > 2 19)
 (ly:version? >= 2 19))

https://codereview.appspot.com/317270043/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Avoid using void * as SCM (issue 314500043 by d...@gnu.org)

[lemzwerg]

LGTM

https://codereview.appspot.com/314500043/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Use explicit typecasts for Scm_variable->SCM (issue 316300043 by d...@gnu.org)

[lemzwerg]

LGTM

https://codereview.appspot.com/316300043/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Lily version operators documentation

[Dan Eble]

On Feb 14, 2017, at 04:23 , Urs Liska  wrote:
> introduces the procedures
> 
> - lilypond>?
[etc.]
> comparing a given version to the one currently compiling the document.


Adding “version” to the name would be clearer.
— 
Dan


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Lily version operators documentation

[Urs Liska]

Hi,

my patch https://sourceforge.net/p/testlilyissues/issues/5067/
http://codereview.appspot.com/317270043 is currently on countdown. It
introduces the procedures

- lilypond>?
- lilypond>=?
- lilypondhttps://openlilylib.org
http://lilypondblog.org


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel