PATCHES - Countdown to April 4

[Colin Campbell]

Here is the current countdown list.

The next countdown will be on April 4th.

A list of all merge requests can be found here:
https://gitlab.com/lilypond/lilypond/-/merge_requests?sort=label_priority


 Push:

!1275 output-distance: parallelize GS processing - Han-Wen Nienhuys
https://gitlab.com/lilypond/lilypond/-/merge_requests/1275

!1264 SignumRepetitionis: ancient repeat sign - Dan Eble
https://gitlab.com/lilypond/lilypond/-/merge_requests/1264

!1254 Emmentaler: Remove unused glyphs - Owen Lamb
https://gitlab.com/lilypond/lilypond/-/merge_requests/1254

!1231 Separate help for internal vs external -d options. - Han-Wen Nienhuys
https://gitlab.com/lilypond/lilypond/-/merge_requests/1231


 Countdown:

!1280 cairo; set bounding box explicitly for EPS output - Han-Wen Nienhuys
https://gitlab.com/lilypond/lilypond/-/merge_requests/1280

!1279 Remove useless #:as-string in \with-dimensions and \with-dimension 
- Jean Abou Samra

https://gitlab.com/lilypond/lilypond/-/merge_requests/1279

!1278 Also use define-public for curried definitions - Jean Abou Samra
https://gitlab.com/lilypond/lilypond/-/merge_requests/1278

!1274 Remove support for dumping grob signatures - Han-Wen Nienhuys
https://gitlab.com/lilypond/lilypond/-/merge_requests/1274


 Review:

!1282 Improve display of LilyPond regression tests - Werner Lemberg
https://gitlab.com/lilypond/lilypond/-/merge_requests/1282

!1281 Doc-CG: use git switch & restore - Jean Abou Samra
https://gitlab.com/lilypond/lilypond/-/merge_requests/1281


 New:

No patches in New at this time.


 Waiting:

!1273 Rewrite some macros with the syntax-case system - Jean Abou Samra
https://gitlab.com/lilypond/lilypond/-/merge_requests/1273

!1210 DRAFT: doc: Support pygment syntax highlighting in PDF output - 
Werner Lemberg

https://gitlab.com/lilypond/lilypond/-/merge_requests/1210

!1136 \break implies \bar "" when needed - Dan Eble
https://gitlab.com/lilypond/lilypond/-/merge_requests/1136

!913 release: binaries with cairo - Han-Wen Nienhuys
https://gitlab.com/lilypond/lilypond/-/merge_requests/913

Cheers,

Colin

Re: Translation

[Dan Eble]

On Apr 2, 2022, at 10:10, Robert Ernest  wrote:
> 
> how can I help with translation, seeing as the webpage is mistranslated?
> 

Welcome, Robert.

See the Contributor's Guide, which is available in HTML or PDF at 
https://lilypond.org/development.html.

Regards,
— 
Dan

Translation

[Robert Ernest]

Hello,
how can I help with translation, seeing as the webpage is mistranslated?

Best Regards,
Robert Ernest

Re: Scheme pattern for retrieving data in objects

[Luca Fascione]

I can see this happening, I thought a bit about it and it seems to me there
are several factors that are potentially at play here:

 - one is how much alignment there is between the API presented to (or
rather, *perceived* by) the user vs their mental model of what is going on
in the program: the more distant these two are, the harder a time the user
will have, and whatever can be made to reduce this gap will feel good to
them. Besides, I'd imagine for most people the library shipped with
lilypond is at least one step removed from their problem space and
vocabulary, and the intervening adaptation layer is likely to feel like a
burden to people. I guess I'm saying that it seems to me lilypond is a bit
like plain TeX and there are many folks that find a layer like LaTeX is
better aligned with their mental models and how they prefer to reason about
their content

 - I'm unclear how technical or interested in coding the lilypond userbase
is: it seems to me that all folks that come to lilypond because the sheets
look great are not necessarily inclined to learn how to program to achieve
their goals, they're after the goal, and the software engineering aspects
of this provide no joy to them. Again, you see something similar in
TeX/LaTeX users as well

 - I myself still find scheme weird: this seems to be largely because it's
just different from everything else I'm familiar with both from a "look"
perspective, but much more importantly from a semantics perspective. I am
aware that as a descendent of Lisp it predates a lot of the common
languages of today, and in a number of ways it's rather more elegant and
better conceived as a language, I am just stating that it's *different*. I
happen to be a very driven person, so I'll muscle through that to get to
the sheets and sheet-making process I want, but I don't know how many other
people have a taste for this or find it enjoyable, I'd imagine most folks
just find it annoying instead. And especially for folks that do this
outside of their work time, being impeded in one's goals for reasons that
bring along an advantage that one may not find material, is unlikely to
feel like a good state of things. Point being: scheme is very different,
and occasionally very subtly so, from languages like python, ruby,
javascript and all the everyday, garden variety stuff folks are likely to
see at work, I don't know how many people will find this as positive trait,
vs how many would find it an undesirable state of things

I totally see wha Han-Wen is saying and I agree that a lateral-shift kinda
thing is not going to be that useful in the long term. However I wrote this
to express why I don't think all these changes necessarily belong in that
category, I see clear cases where plenty of value is provided to users
instead.

Luca


On Sat, Apr 2, 2022 at 2:50 PM Werner LEMBERG  wrote:

>
> >> Over the years, I've become extremely wary of syntactic sugar: it
> >> adds an extra barrier to usage/development because everyone not
> >> only has to learn Scheme, they also have to learn the (lilypond
> >> specific) idioms involved.
> >
> > I'm curious you say that, since my experience is precisely the
> > opposite: I've had far better results "selling" Lilypond to people
> > using syntactic sugar than basically anything else I can
> > identify. The people I’ve "converted" all want to be able to type
> > things like
> >
> >\reverseMusic \foo
> >
> > rather than learning how to write the equivalent function in
> > Scheme. In other words, syntactic sugar keeps them from learning
> > Scheme as opposed to having to learn it.
> >
> > Am I missing something? Is my experience unique?
>
> No, your experience is not unique.  I think that developers and normal
> users (but probably not Scheme wizards) have rather diametral views on
> this topic.
>
>
> Werner
>


-- 
Luca Fascione
Distinguished Engineer - Ray Tracing - NVIDIA

Re: Scheme pattern for retrieving data in objects

[David Kastrup]

Kieren MacMillan  writes:

> Hi Han-Wen,
>
>> Over the years, I've become extremely wary of syntactic sugar: it adds
>> an extra barrier to usage/development because everyone not only has to
>> learn Scheme, they also have to learn the (lilypond specific) idioms
>> involved.
>
> I'm curious you say that, since my experience is precisely the
> opposite: I've had far better results "selling" Lilypond to people
> using syntactic sugar than basically anything else I can identify. The
> people I’ve "converted" all want to be able to type things like
>
>\reverseMusic \foo
>
> rather than learning how to write the equivalent function in
> Scheme. In other words, syntactic sugar keeps them from learning
> Scheme as opposed to having to learn it.
>
> Am I missing something? Is my experience unique?

You are talking about different things.  Syntactic sugar says the same
thing but in a more cohesive manner.  That is not the same as assembling
dedicated functionality from suitable components.

Syntactic sugar saves clutter which is not the same as hiding internals.

-- 
David Kastrup

Re: Scheme pattern for retrieving data in objects

[Kieren MacMillan]

Hi Werner,

> your experience is not unique.  I think that developers and normal users
> (but probably not Scheme wizards) have rather diametral views on this topic.

Excellent point.
— Kieren

Re: Scheme pattern for retrieving data in objects

[Dan Eble]

> On Apr 2, 2022, at 07:38, Han-Wen Nienhuys  wrote:
> 
> On Fri, Apr 1, 2022 at 6:43 PM Jean Abou Samra  > wrote:
...
>> (fetch left-bound-info assoc-ref (common-Y X padding attach-dir)

I'm not enthusiastic about multiple variable declarations in one line or 
variable declarations that don't even look like declarations.


> Over the years, I've become extremely wary of syntactic sugar: it adds
> an extra barrier to usage/development because everyone not only has to
> learn Scheme, they also have to learn the (lilypond specific) idioms
> involved.

+1.  I can imagine frustration after imitating some working code that calls 
`ly:grob-property` and being asked in review to use `fetch` instead because it 
is better.

If the basic syntax is too verbose, could it be revised rather than added to?

  (ly:get grob 'X-offset)
  (ly:get grob 'left-bound-info 'padding)
  (ly:get context 'alterationGlyphs 1/2)

— 
Dan

Re: Scheme pattern for retrieving data in objects

[Werner LEMBERG]

>> Over the years, I've become extremely wary of syntactic sugar: it
>> adds an extra barrier to usage/development because everyone not
>> only has to learn Scheme, they also have to learn the (lilypond
>> specific) idioms involved.
> 
> I'm curious you say that, since my experience is precisely the
> opposite: I've had far better results "selling" Lilypond to people
> using syntactic sugar than basically anything else I can
> identify. The people I’ve "converted" all want to be able to type
> things like
> 
>\reverseMusic \foo
> 
> rather than learning how to write the equivalent function in
> Scheme. In other words, syntactic sugar keeps them from learning
> Scheme as opposed to having to learn it.
> 
> Am I missing something? Is my experience unique?

No, your experience is not unique.  I think that developers and normal
users (but probably not Scheme wizards) have rather diametral views on
this topic.


Werner

Re: Scheme pattern for retrieving data in objects

[Kieren MacMillan]

Hi Han-Wen,

> Over the years, I've become extremely wary of syntactic sugar: it adds
> an extra barrier to usage/development because everyone not only has to
> learn Scheme, they also have to learn the (lilypond specific) idioms
> involved.

I'm curious you say that, since my experience is precisely the opposite: I've 
had far better results "selling" Lilypond to people using syntactic sugar than 
basically anything else I can identify. The people I’ve "converted" all want to 
be able to type things like

   \reverseMusic \foo

rather than learning how to write the equivalent function in Scheme. In other 
words, syntactic sugar keeps them from learning Scheme as opposed to having to 
learn it.

Am I missing something? Is my experience unique?
Kieren.


Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: kie...@kierenmacmillan.info

Re: Scheme pattern for retrieving data in objects

[Han-Wen Nienhuys]

On Fri, Apr 1, 2022 at 6:43 PM Jean Abou Samra  wrote:
>
> Folks,
>
> Just a random thought in passing: I just wrote something of this kind
> once again:
>
> (let ((elements (ly:music-property m 'elements))
>(element (ly:music-property m 'element))
>(articulations (ly:music-property m 'articulations)))
>...)
>
> (let ((padding (assoc-ref details 'padding))
>(common-Y (assoc-ref details 'common-Y)))
>...)
>
> (let ((padding (ly:grob-property grob 'padding)
>(shorten-pair (ly:grob-property grob 'shorten-pair))
>(normalized-endpoints (ly:grob-property grob 'normalized-endpoints)))
>...)
>
>
> Does anyone find a value in defining a macro for this?
>
>
> \version "2.23.8"
>
> #(define-syntax-rule (fetch obj getter (sym ...) body body* ...)
> (let ((evald-obj obj)
>   (evald-getter getter))
>   (let ((sym (getter obj 'sym))
> ...)
> body body* ...)))
> {
>c'1
>\tweak after-line-breaking
>  #(lambda (grob)
> (fetch grob ly:grob-property (left-bound-info)
>   (fetch left-bound-info assoc-ref (common-Y X padding attach-dir)
> (ly:message "common-Y=~a X=~a padding=~a attach-dir=~a"
> common-Y X padding attach-dir
>\startTextSpan
>c'1\stopTextSpan
> }

It's shorter, but is it easier to understand and discover? Is the
former code (which is somewhat verbose) a real barrier to getting
coding/typesetting done?

Over the years, I've become extremely wary of syntactic sugar: it adds
an extra barrier to usage/development because everyone not only has to
learn Scheme, they also have to learn the (lilypond specific) idioms
involved.

-- 
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen