Re: Making a list argument reliably optional

[David Kastrup]

Robin Bannister  writes:

>  David Kastrup wrote:
>
>> Could you please post an actual minimal example we
>> could talk about usefully?
>
> OK.  I'm moving, but unsure of the direction.
>
> notnumber.ly is a complete instance of trying to be more specific.
> It breaks at 2.19.39.

That would likely be issue 4798
 with one of the
following commits:

commit 34917fefd1167f963c44fbcf47ab7f4184fc4cdc
Author: David Kastrup 
Date:   Thu Mar 10 18:23:48 2016 +0100

Issue 4798/6: Admit lists starting with UNSIGNED as music function arguments

commit 0453c1df927617386bfd63f22965a72f43b192a8
Author: David Kastrup 
Date:   Sun Mar 13 20:49:49 2016 +0100

Issue 4798/5: Use key-list? for several music command predicates

This is sort of arbitrary currently but matches the kind of syntax
accepted by \override/\revert due to their definition in the parser.

commit 77cf1054ff5aeb20978a1586a44f5b95fb365585
Author: David Kastrup 
Date:   Wed Feb 3 19:38:29 2016 +0100

Issue 4798/4: Parser work for key lists including numbers

This admits key lists containing non-negative numbers into various
syntactic constructs previously using symbol lists.


A number list can be used after this as a function argument, like

\time 3,1 4/4

Or even

\time 4 4/4

A number list counts as not-number?.  So if you are out for a more
specific type of list before a number, you should check for that.  Yes,
this is a feature coming with drawbacks that may be surprising.
Optional argument processing that does not make use of \default relies
on predicates not being misinterpreted, and interpreting some input as a
list (symbol list or number list) is probably the most likely candidate
for unexpected matches.  Optional list arguments should be as specific
as possible for that reason, in a manner that input suitable for the
following non-optional argument cannot be misinterpreted as matching.

Sorry for that.  With great power comes great confusability.

-- 
David Kastrup

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

Re: Making a list argument reliably optional

[Robin Bannister]

 David Kastrup wrote:


Could you please post an actual minimal example we
could talk about usefully?


OK.  I'm moving, but unsure of the direction.

notnumber.ly is a complete instance of trying to be more specific.
It breaks at 2.19.39.


Cheers,
Robin
% versions 2.18.2 through 2.19.38 ok 
% versions from 2.19.39 onwards nok

#(define (notnumber? x)
  (not (number? x)))

listnumber = 
#(define-music-function (parser location listarg numberarg) 
  ((notnumber? '()) number?) 
  (let ((str (number->string numberarg)))
#{ 
  c''1-\markup $str
#}))

{
  s1_"using notnumber? as a most specific exclusion of numberarg's 333:"  
  \break
  s1_"\listnumber #'() 333" \listnumber #'() 333 s1 % baseline ok 
  \break 
  s1_"\listnumber 333"  \listnumber 333 s1 s1 % 2.19.38 ok  2.19.39 nok
}
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Making a list argument reliably optional

[David Kastrup]

Robin Bannister  writes:

> David Kastrup wrote:
>
>> So your examples are much too generic to give advice.  It's likely that
>> you can solve your problem by using a much more specific predicate than
>> list? unless the form of list that you want to admit really needs to
>> allow something like a single-element string list. 
>
> Well no, the \liststring calls were to make a vividly correct contrast!
> My case is like the \listnumber 333 call.
>
> I can't imagine how list? could accept the number 333,
> or why some putative automagic would want it to.
> And if I use a more specific predicate and it solves the 2.19.39
> problem, how can I know if it is going to stay solved?
>
>
> I tried the following (which is probably nonsense):
>
> 
>
> #(define (notnumber? x)
>   (not (number? x)))
>
> listnumber =
> #(define-music-function (parser location listarg numberarg)
>   ((notnumber? '()) number?)
>   (let ((str (number->string numberarg)))
> #{
>   c''1-\markup $str
> #}))
>
> 
>
> and it still says:   error: wrong type for argument 2.  Expecting number

It doesn't say anything like that since it doesn't even call
listnumber.  And your other example is a complex mixture of listnumber
and liststring.  Could you please post an actual minimal example we
could talk about usefully?

-- 
David Kastrup

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

Re: Making a list argument reliably optional

[Robin Bannister]

David Kastrup wrote:


So your examples are much too generic to give advice.  It's likely that
you can solve your problem by using a much more specific predicate than
list? unless the form of list that you want to admit really needs to
allow something like a single-element string list. 


Well no, the \liststring calls were to make a vividly correct contrast!
My case is like the \listnumber 333 call.

I can't imagine how list? could accept the number 333,
or why some putative automagic would want it to.
And if I use a more specific predicate and it solves the 2.19.39 
problem, how can I know if it is going to stay solved?



I tried the following (which is probably nonsense):



#(define (notnumber? x)
  (not (number? x)))

listnumber =
#(define-music-function (parser location listarg numberarg)
  ((notnumber? '()) number?)
  (let ((str (number->string numberarg)))
#{
  c''1-\markup $str
#}))



and it still says:   error: wrong type for argument 2.  Expecting number


Cheers,
Robin

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

Re: Making a list argument reliably optional

[David Kastrup]

Robin Bannister  writes:

> Hallo all
>
> I'm having unexpected problems with a music function.
> It takes several arguments, the first of which expects a list,
> and should be optional.
>
> Today it tripped up when run with a late 2.19 version and I narrowed
> this down to 2.19.39. It seemed to have trouble with the second
> parameter so I set up test cases where this varied, expecting a
> mixture of good and bad.  But instead I got a confusing mixture of bad
> and bad, including a 2.18.2 failure.  See listargtest.ly.
>
>
> The music function chordRepeats has a similar first argument for
> event-types but that hasn't helped me see what I am doing wrong.
> I suppose it's me or my computer that's wonky, so I would be glad of
> a fresh eye or a second opinion.

A list? predicate for an optional argument is very iffy since there is a
whole lot of input that can be made to match this predicate.

For example, "bla" is a string list with a single element if it cannot
be matched otherwise.

It works more or less when the next argument is music (though in
\lyricmode this is an entirely different can of worms).

So your examples are much too generic to give advice.  It's likely that
you can solve your problem by using a much more specific predicate than
list? unless the form of list that you want to admit really needs to
allowq something like a single-element string list.  Maybe you need to
rethink your interface then.

-- 
David Kastrup

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

Making a list argument reliably optional

[Robin Bannister]

Hallo all

I'm having unexpected problems with a music function.
It takes several arguments, the first of which expects a list,
and should be optional.

Today it tripped up when run with a late 2.19 version and I narrowed 
this down to 2.19.39. It seemed to have trouble with the second 
parameter so I set up test cases where this varied, expecting a mixture 
of good and bad.  But instead I got a confusing mixture of bad and bad, 
including a 2.18.2 failure.  See listargtest.ly.



The music function chordRepeats has a similar first argument for 
event-types but that hasn't helped me see what I am doing wrong.

I suppose it's me or my computer that's wonky, so I would be glad of
a fresh eye or a second opinion.


Cheers,
Robin

liststring = 
#(define-music-function (parser location listarg stringarg) 
((list? '()) string?) 
(let ((str stringarg))
#{ 
  c''1-\markup $str
#}))


listnumber = 
#(define-music-function (parser location listarg numberarg) 
((list? '()) number?) 
(let ((str (number->string numberarg)))
#{ 
  c''1-\markup $str
#}
))


{
  s1_"empty listarg supplied:"\break
  s1_"\liststring #'() \"aaa\"" \liststring #'() "aaa" s1 \break
  s1_"\listnumber #'() 111" \listnumber #'() 111 s1   \break
}
{
  s1_"listarg not supplied:"  \break
  s1_"\liststring \"bbb\""  \liststring "bbb" s1  \break % 2.16.2 ok   2.18.2 nok
  s1_"\liststring \"222\""  \liststring "222" s1  \break % 2.19.39 ok  2.19.80 nok
  s1_"\listnumber 333"  \listnumber 333 s1\break % 2.19.38 ok  2.19.39 nok
}
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

crossplatform Python script for point-and-click

[Federico Bruni]

Hi folks

I remember that some time ago a user in this list shared a Python 
script to get point-and-click working on Windows and probably other 
operating systems. I can't remember his name, as I think he writes very 
seldomly in this list. I've searched the archive but I cannot find it.


I found only a Python script shared by Mark Knoop, but that's for Linux 
only:

https://github.com/markk/textedit-ly

I'm asking because I've struggled a lot to make point-and-click work on 
Windows and Mac while writing a blog post for lilypondblog.org, but 
eventually gave up because the Scheme script works only with certain 
settings. I can't remember now, but I think system variables worked 
only if defined in the OS and not within the script, at least in 
Windows. Details don't matter here. In general I think that a Python 
script would probably work better crossplatform and that would be 
consistent with the rest of the lilypond utility scripts.


Thanks in advance
Federico




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