Re: Add Code of Conduct

[James Lowe]

On 07/02/2020 09:50, Han-Wen Nienhuys wrote:

Thanks for your careful observations.

First, the CoC was actually coined by Mike, and I saw it as a proposal to
bring LilyPond into the next decade.


What is that even supposed to mean? Again empty, ]words that sound 
'nice' but mean nothing.



A CoC is a pretty normal concept these
days.


Here we go ... ".. everyone else does it... so we should .. " still with 
no point to any of it that I can see.



If having a CoC is required to be taken seriously by developers at
large, we should consider it.
And for those of us who don't take them seriously and see them as an 
attempt at behavioral control by certain people for certain people.

I concede that CoCs haven't yet reached this
level of ubiquity, though.

Probably for good reason.

For full disclosure, David has ticked me off in the past, and reacquainting
myself with the community means that I have to reacquaint myself with
David's way of communicating.


Can we just stop bashing David?


One of the recent emails (about the
development process), contained a passage that felt like a blow in my
stomach and upset me to the point of considering to leave again. (When I
say this, I am not asking for adulation). If that happens to me, imagine
what happens when a new contributor is on the receiving end of that. So I
am happy to see that David is trying new ways to address this problem.


All without having at CoC.



I have no personal stake in being a CoC committee member, and was actually
volunteered into it by Janek. I am happy to not be part of such a committee
(Elaine, would you be interested?), because my time is limited, and is
probably best spent in mentoring coders and explaining the code base. For
the record, I think Werner is an excellent candidate.



If we're doing a 'for the record', then just let me state here if/when 
we have a CoC, I will be leaving the LP project , so I guess you better 
start getting all your automation ducks in a row for patch testing and 
shepherding etc, or someone else will need to step in do what I 
currently do.


What a shame.

James

PATCHES - Countdown for February 8th

[pkx166h]

Hello,

Here is the current patch countdown list. The next countdown will be on
February 10th.

A quick synopsis of all patches currently in the review process can be
found here:

http://philholmes.net/lilypond/allura/


***


 Push:

5733 Fix various type-conversion warnings - Dan Eble
https://sourceforge.net/p/testlilyissues/issues/5733
http://codereview.appspot.com/559450053

5706 Doc: Correct and extend infos about LilyDev setup - xmichael-k
https://sourceforge.net/p/testlilyissues/issues/5706
http://codereview.appspot.com/561360043

5705 Silence warning in Stem::get_beaming () - Dan Eble
https://sourceforge.net/p/testlilyissues/issues/5705
http://codereview.appspot.com/565610043

5703 Run scripts/auxiliar/fixcc.py - David Kastrup
https://sourceforge.net/p/testlilyissues/issues/5703
http://codereview.appspot.com/549480043

5670 lily: fix some type conversion warnings - Han-Wen Nienhuys
https://sourceforge.net/p/testlilyissues/issues/5670
http://codereview.appspot.com/557190043


 Countdown:

No patches on countdown at this time.


 Review:

5738 Doc: Some miscellaneous suggestions from Peter Toye - xmichael-k
https://sourceforge.net/p/testlilyissues/issues/5738
http://codereview.appspot.com/579280043

5737 Clean up embedded scheme parsing/evaluation. - Han-Wen Nienhuys
https://sourceforge.net/p/testlilyissues/issues/5737
http://codereview.appspot.com/577410045

5718 Grow heap aggressively during music interpretation - Han-Wen Nienhuys
https://sourceforge.net/p/testlilyissues/issues/5718
http://codereview.appspot.com/561390043

5709 Use a pointer for the output parameter of Lily_lexer::scan_word - 
Han-Wen Nienhuys

https://sourceforge.net/p/testlilyissues/issues/5709
http://codereview.appspot.com/577440044


 New:

5679 In verbose mode, dump time spent on parsing lily.scm and friends. - 
Han-Wen Nienhuys

https://sourceforge.net/p/testlilyissues/issues/5679
http://codereview.appspot.com/573420043


 Waiting:

5740 Add \post to defer context actions to end of time step - Dan Eble
https://sourceforge.net/p/testlilyissues/issues/5740
http://codereview.appspot.com/581600043

5688 Announce end of multi-measure-rest - Han-Wen Nienhuys
https://sourceforge.net/p/testlilyissues/issues/5688
http://codereview.appspot.com/561310045

4943 Manual page breaking causing assertion failure - Thomas Morley
https://sourceforge.net/p/testlilyissues/issues/4943
http://codereview.appspot.com/575600043


***



Regards,

James

Re: Integration of Guilev2 branches into master

[David Kastrup]

David Kastrup  writes:

> David Kastrup  writes:
>> Han-Wen Nienhuys  writes:
>>
>>> On Fri, Feb 7, 2020 at 6:54 PM David Kastrup  wrote:
>>>
 I propose that I am going to pick up the pieces of
 not-actually-formally-reviewed patches making up the bulk of them and
 put them, Guilev2-guarded (so that they don't affect Guilev1
 compilations) into staging->master without going through the formal
 processes.

 The reason to do that is that the current state already likely wasted
 considerable time of Han-Wen by finding solutions for problems that were
 already previously turned into non-showstoppers although not necessarily
 in the cleanest manner.  But it would seem that even if part of them is
 likely to eventually be superseded, giving Han-Wen a better starting
 place would make him work and plan more effectively.

>>>
>>> Thanks, David!
>>>
>>> Can you mark the commits with some prefix ("GUILE2: blah") so they stand
>>> out?
>>
>> Oh good grief, I remember now.  The commit I sent in the review of yours
>> already had stopped working with some Guile version, and the recommended
>> fix by Guile developers was in a different commit.  Cough cough.
>>
>> Most of the off-branch Guilev2 work was done by Antonio Ospite but
>> without Guilev2 guards and collected by Harm who is not a C++ programmer
>> and thus was not in a position to place guards.  Some of that work is,
>> well, not meant for eternity.
>>
>> Nevertheless, with guards in it, it may still provide a reasonable bit
>> of headstart.

Ok, there are still 3 unmerged patches marked XXX in the (now rebased)
branch dev/guile-v2-work .  They are unmerged because they are marked
XXX .  Here is the list:

commit ad1ff054835fa7940307d9c5bbb7e1b55ee7ebbe (HEAD -> guile-v2-work, 
origin/dev/guile-v2-work)
Author: Antonio Ospite 
Date:   Tue Nov 22 16:25:01 2016 +0100

XXX reset the locale when building index.html

It looks like resetting the locale is still needed to produce index.html

TO be hones, I am NOT sure if this is needed, it is possible than I had
a dirty build when I come up with this workaround for a build failure.

commit f3c8caf0cc3576b333d57bde02d939898ba77a02
Author: Antonio Ospite 
Date:   Tue Nov 22 16:25:01 2016 +0100

XXX don't override LANG globally in the build process

For now lilypond depends on a UTF-8 locale to produce correct results
when using guile-2.0, so don't override LANG globally to give lilypond
a chance to use the UTF-8 locale from the environment when building the
documentation.

commit cc2c1084f24017f1bb6194d46be44099bd19fc7f
Author: Antonio Ospite 
Date:   Tue Nov 22 12:59:14 2016 +0100

XXX add support for itexi files to the vim config

commit 6970872939f4bb716151645b92762ae4cf9d030d
Author: Antonio Ospite 
Date:   Thu Nov 10 11:17:18 2016 +0100

XXX Avoid the lockup in ly_scm_write_string

Sometimes when calling ly_scm_write_string (in particular from
print_scm_val, called by type_check_assignment) the scm_call_2 function
never returns.

Add a dirty hack to avoid the lockup.


The vim config file actually has nothing to do with Guilev2 as far as I
can see: we should likely make this a regular issue and pass it in that
way.

"Avoid the lockup" is not even a "hack": it just stomps dead some
message call that for unfathomable reasons locks up.  I'd say we stay
away from that until the problem is triggered, then try finding a real
solution.

The build process changes look like a can of worms: if we could make
LilyPond switch itself into an UTF-8 environment reliably without
looking at the actual environment, that would likely be preferable.
Though I am not too sure about it.

When in doubt, cherry-pick one from those (though I'll probably back out
the vim thing soonish from the branch and give it its own issue).

-- 
David Kastrup
My replies have a tendency to cause friction.  To help mitigating
damage, feel free to forward problematic posts to me adding a subject
like "timeout 1d" (for a suggested timeout of 1 day) or "offensive".

Re: RFC: docker for CI

[Jonas Hahnfeld via Discussions on LilyPond development]

Am Freitag, den 07.02.2020, 13:21 +0100 schrieb Han-Wen Nienhuys:
> Proposal: rather than using the patchy scripts for validating
> LilyPond, we use docker images.
> 
> General idea
> 
> 
> There is a script ("driver") that drives docker running on a dedicated
> build machine ("host").
> 
> There are several images:
> 
> * The base dev image.
> 
> The base image is based on some stripped Linux distribution, with all
> the devtools necessary for compiling LilyPond. In addition, it
> contains a copy of ccache, and a git clone of the LilyPond sourcecode
> 
> * The base release image for a specific git commit.
> 
> The procedure to build it is as follows:
> 
>   * take the base dev image
>   * fetch the git commit
>   * runs (make ; make test-baseline)
>   * runs (make dist-clean)
> 
> This saves the result as a docker image. The Docker image now contains
> a clean lilypond tree, the C++ compilation results (in ccache), and a
> test baseline.
> 
> The base release image is made at official LilyPond releases, or at
> any release that has a new graphical regtest result
> 
> 
> CI: build binary
> 
> 
> Given a proposed change (as git commit):
> 
>  * take base release image
>  * run (make; make doc) >& log-file
> 
> On success, the driver saves the result as a docker image, tagged with the
> commit sha1.
> 
> On failure, the driver uploads the last bit of the log-file to our code
> review system.
> 
> 
> CI: regtest
> ===
> 
> Given a proposed change (as git commit)
> 
>   * take CI build image
>   * run (make check >& log-file)
>   * use a headless browser to take a image snapshot of the top of regtest
> result page.
> 
> 
> On success, the driver uploads the image snapshot to code review.
> 
> On failure, the driver uploads the last bit of the log-file to code review.
> 
> 
> Considerations
> ==
> 
> * Because the build happens inside a container, we can test multiple
>   builds. We could build against guile 1.8 and 2.2 at the same time,
>   for example

I don't agree that we need containers for this, you can easily set
environment variables to make configure pick up the version you want to
use.

> * Because the "build binary" step reuses CCache results, it can
>   complete quickly.

Maybe I don't fully understand the proposal, but:
 * if we only build the release image for every "official" tag, it will
not provide quicker builds - especially towards the end of a cycle when
many changes have accumulated.
 * if instead we build images for every commit, then incremental
building of a provided patch will be fast(er) (_if_ it doesn't touch
any header file). But what's then the point of using ccache, we can
just trigger a full build?

Jonas


signature.asc
Description: This is a digitally signed message part

Re: Doc: Some miscellaneous suggestions from Peter Toye (issue 579280043 by michael.kaepp...@googlemail.com)

[lilypond]

-
Saturday, February 8, 2020, 5:03:15 AM, you wrote:


>> Теноры

>> Very odd - I've just installed a CMU font and it's got all the
>> Russian alphabet.

> What exactly do you mean with 'installing'?  I'm talking about the
> creation of PDF files using xelatex, using only standardized fonts
> (this is, avoiding fonts that are accidentally present on your
> system).

I thought that "install a font" meant "install a font". I'm on Windows, so it 
may have other meanings on other OSs. 

>> See the line above which is in CMU Concrete!

> ???  I use Emacs to read my e-mail, and emacs
> is configured to use the
> font 'DejaVu Sans Mono' on my GNU/Linux box.  This font contains
> Cyrillic glyphs...

I composed that line in the email using CMU Concrete. Presumably your email 
client changes that.

>> Are you sure that you've got all of the font installed?

> It seems there is a fundamental
> misunderstanding.  We want to
> *restrict* the fonts used for creating the
> documentation to an exactly
> defined set so that you get identical PDFs regardless on which
> platform they are built.  By default, texinfo uses the 'Computer
> Modern' (CM) family; for some additional glyphs the 'EC' and 'feym*'
> font families get used.  None of those fonts
> contain Cyrillic glyphs.

OK, that's fine by me. I was confused as earlier emails referred to the font 
family, not the version of the font that are used in the documentation project, 
which you tell me is a subset.

> Note that music snippets in the PDF are handled differently.


> Werner

Mac 64-bit builds: Guile segfault?

[Marnen Laibow-Koser]

Folks—

>From the feedback I’ve been getting, it looks like my 64-bit Mac builds are
working well for most people.  However, one user—one only one of two Macs
he has access to—is consistently getting a segfault with these builds right
around the time that it loads Guile and/or lily.scm (he says the 32-bit
builds work).  There are detailed logs and troubleshooting info at
https://gitlab.com/marnen/lilypond-mac-builder/issues/16 , but I’ve run out
of ideas to try.  Can someone help?  Thanks so much!

Best,
-- 
Marnen Laibow-Koser mar...@marnen.org http://www.marnen.org Sent from Gmail
Mobile

Re: RFC: docker for CI

[David Kastrup]

Jonas Hahnfeld via Discussions on LilyPond development
 writes:

> Am Freitag, den 07.02.2020, 13:21 +0100 schrieb Han-Wen Nienhuys:
>> 
>> Considerations
>> ==
>> 
>> * Because the build happens inside a container, we can test multiple
>>   builds. We could build against guile 1.8 and 2.2 at the same time,
>>   for example
>
> I don't agree that we need containers for this, you can easily set
> environment variables to make configure pick up the version you want to
> use.

I use stuff like

./configure GUILE_CONFIG=/usr/local/tmp/guile-1.8/bin/guile-config 
GUILE=/usr/bin/guile

all the time.

>> * Because the "build binary" step reuses CCache results, it can
>>   complete quickly.
>
> Maybe I don't fully understand the proposal, but:
>  * if we only build the release image for every "official" tag, it will
> not provide quicker builds - especially towards the end of a cycle when
> many changes have accumulated.
>  * if instead we build images for every commit, then incremental
> building of a provided patch will be fast(er) (_if_ it doesn't touch
> any header file). But what's then the point of using ccache, we can
> just trigger a full build?

Full builds are slower.  But I really don't trust our dependencies all
too much, and for example Clang builds don't get a working set of
dependencies anyway (which is sort of curious since it is the modular
Clang that should be able to parse for them easily).

-- 
David Kastrup

Re: RFC: docker for CI

[Jonas Hahnfeld via Discussions on LilyPond development]

Am Samstag, den 08.02.2020, 13:51 +0100 schrieb David Kastrup:
> Jonas Hahnfeld via Discussions on LilyPond development
> <
> lilypond-devel@gnu.org
> > writes:
> 
> > Am Freitag, den 07.02.2020, 13:21 +0100 schrieb Han-Wen Nienhuys:
> > > Considerations
> > > ==
> > > 
> > > * Because the build happens inside a container, we can test multiple
> > >   builds. We could build against guile 1.8 and 2.2 at the same time,
> > >   for example
> > 
> > I don't agree that we need containers for this, you can easily set
> > environment variables to make configure pick up the version you want to
> > use.
> 
> I use stuff like
> 
> ./configure GUILE_CONFIG=/usr/local/tmp/guile-1.8/bin/guile-config 
> GUILE=/usr/bin/guile
> 
> all the time.

Exactly.

> > > * Because the "build binary" step reuses CCache results, it can
> > >   complete quickly.
> > 
> > Maybe I don't fully understand the proposal, but:
> >  * if we only build the release image for every "official" tag, it will
> > not provide quicker builds - especially towards the end of a cycle when
> > many changes have accumulated.
> >  * if instead we build images for every commit, then incremental
> > building of a provided patch will be fast(er) (_if_ it doesn't touch
> > any header file). But what's then the point of using ccache, we can
> > just trigger a full build?
> 
> Full builds are slower.

True, but my point is that it doesn't matter: You have to do a full
build to populate ccache; or you just build with the changes already
applied, what's the difference?

Jonas

> But I really don't trust our dependencies all
> too much, and for example Clang builds don't get a working set of
> dependencies anyway (which is sort of curious since it is the modular
> Clang that should be able to parse for them easily).


signature.asc
Description: This is a digitally signed message part

Re: Mac 64-bit builds: Guile segfault?

[Hans Åberg]

> On 8 Feb 2020, at 13:51, Marnen Laibow-Koser  wrote:
> 
> From the feedback I’ve been getting, it looks like my 64-bit Mac builds are
> working well for most people.  However, one user—one only one of two Macs
> he has access to—is consistently getting a segfault with these builds right
> around the time that it loads Guile and/or lily.scm (he says the 32-bit
> builds work).  There are detailed logs and troubleshooting info at
> https://gitlab.com/marnen/lilypond-mac-builder/issues/16 , but I’ve run out
> of ideas to try.  Can someone help?  Thanks so much!

Not knowing if it is related, but on MacOS, the Boehm GC must be initialized 
before the first allocation, and the latter may in C++ happen before ‘main' is 
called.

Re: Mac 64-bit builds: Guile segfault?

[Thomas Morley]

Am Sa., 8. Feb. 2020 um 13:51 Uhr schrieb Marnen Laibow-Koser
:
>
> Folks—
>
> From the feedback I’ve been getting, it looks like my 64-bit Mac builds are
> working well for most people.  However, one user—one only one of two Macs
> he has access to—is consistently getting a segfault with these builds right
> around the time that it loads Guile and/or lily.scm (he says the 32-bit
> builds work).  There are detailed logs and troubleshooting info at
> https://gitlab.com/marnen/lilypond-mac-builder/issues/16 , but I’ve run out
> of ideas to try.  Can someone help?  Thanks so much!
>
> Best,
> --
> Marnen Laibow-Koser mar...@marnen.org http://www.marnen.org Sent from Gmail
> Mobile

There are some reports of segfaulting builds of guile "Segfault while
building on 64-bit Cygwin"
https://lists.gnu.org/archive/html/guile-devel/2020-01/msg00112.html

I doubt it's relevant, though. Those reports are for guile-2.9.7 and newer...

Cheers,
  Harm

Re: Mac 64-bit builds: Guile segfault?

[Marnen Laibow-Koser]

On Sat, Feb 8, 2020 at 8:39 AM Thomas Morley 
wrote:
[...]

>
> There are some reports of segfaulting builds of guile "Segfault while
> building on 64-bit Cygwin"
> https://lists.gnu.org/archive/html/guile-devel/2020-01/msg00112.html
>
> I doubt it's relevant, though. Those reports are for guile-2.9.7 and
> newer...


Plus these segfaults happen during execution, not compilation.


>
> Cheers,
>   Harm
>
-- 
Marnen Laibow-Koser mar...@marnen.org http://www.marnen.org Sent from Gmail
Mobile

Re: Add Code of Conduct (issue 575620043 by janek.lilyp...@gmail.com)

[Kieren MacMillan]

Hi Wol,

> The worry is that said developer may decide his talents
> are better spent elsewhere, and he'll quit ...

We need to weigh that concert against the documented reality that multiple 
other developers have already done so, and the worry that more might follow (or 
never join in the first place).

> a quick skim of the emails says to me this is rapidly turning into a toxic 
> tragedy of the commons.

100% agreed.

> The REAL tragedy is OUTSIDERS coming in, thinking things
> are being mis-managed, and imposing their own rules.

What about insiders like me — here in the Pond for 17 years — who agree that 
things are being mismanaged?

> [gentoo] lost an awful lot of developers a while back because a couple of
> developers turned toxic and, in *private* conversations, drove a lot
> people on the edge away. They finally got thrown out, but it took the
> project a LONG time to recover.

I would suggest that "developers turn[ing] toxic" was the problem, not the 
private or public nature of the conversation(s).

> another woman in the same venue who just accepted that it was a male 
> environment
> with no malicious intent but that she just couldn't take it when the 
> testosterone got out of hand.
> It IS a hard nut to crack.

Actually, that nut is pretty easy to crack, I believe: don’t allow testosterone 
to get out of hand. #problemsolved

Cheers,
Kieren.


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

Re: Add Code of Conduct

[Kieren MacMillan]

Hi James,

> What a shame.

To me, the greatest shame is that all the positive energy and momentum coming 
out of the Salzburg conference is, it seems, in real danger of being shut down 
by toxic energy of the same kind that has led to the community attrition over 
the last 5-7 years.

Just an observation from someone who’s been here since 2003, and watched this 
movie before.

Regards,
Kieren.


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

Re: Splitting Staves

[Kieren MacMillan]

Hi Dan (et al.),

> On Feb 6, 2020, at 09:32, Kieren MacMillan  
> wrote:
>> So what I want to work on is some sort of ”Splittable Staff“.

Just to be clear, Valentin wrote that, not me.  =)

> This terminology looks at the use case from a point of view that might not be 
> very consistent with LilyPond.  Let's think carefully about what we want to 
> call this, because names have a way of coloring the problem-solving process.

Agreed.

> We should entertain "moving voices" as an alternative idea to "splitting 
> staves" so that we are more likely to find the best solution.

Definitely. In the best case scenario, I’ve always dreamed that we could move 
items not just to adjacent staves (as would be true in a standard divisi 
situation), but also to adjacent non-staves [!] and non-adjacent contexts of 
all types (staves and non-staves). I look forward to discussing the 
possibilities.

> +1, however something less than "fully and correctly" might work for a good 
> number of people and be implemented sooner.

Oh, I’m definitely of the "progress not perfection" mindset… but I also believe 
(and think you agree) that we should try to get the best possible 
fundamentals/plan in place, so that we (a) have a good foundation to build on 
and add to in the future, and (b) don’t have to reinvent the wheel "the next 
time".

Best,
Kieren.


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

Re: Add Code of Conduct [Another RFC or not now?]

[Karlin High]

I think the Code of Conduct discussion is reaching (or has reached) the 
point of exhaustion and is unlikely to be productive if continued 
further in current directions. It seems there is pretty strong 
opposition to adopting the Contributor Covenant Code of Conduct as 
originally proposed.


I'm thankful for the occasion to self-reflect on Lilypond's discussion 
environment. I've been thinking about this a lot. A point was made 
earlier that the expectation of having Codes of Conduct in open-source 
communities is not going to go away. In that case, I think it would be 
best to "fill the vacuum" and adopt something everyone finds acceptable. 
That, as opposed to having a sufficiently-influential outside party 
demand adoption of a Code the community doesn't want, as happened to the 
SQLite project.


In the spirit of the recent "RFC" posts that explore different future 
directions, I think I could soon propose something for a Code of 
Conduct. (It draws on some centuries-old traditions of community 
conflict resolution.)


However, I'd like to hear from David Kastrup and James Lowe first. To 
me, their opposition registered as the strongest.


Question: Would this opposition apply to all Codes of Conduct as a 
matter of principle? Or just to the particular one that was proposed, 
and you'd consider supporting a more-acceptable alternative?


And, would you like to see an alternative proposal...

* Soon
* Later
* Please never

I'm not going to propose anything now if it's felt the entire issue 
needs a rest for the moment.


--
Karlin High
Missouri, USA

Re: event queue with thread for c++

[Jonas Hahnfeld via Discussions on LilyPond development]

Am Freitag, den 07.02.2020, 19:26 +0100 schrieb Han-Wen Nienhuys:
> Hey Dan,
> 
> I thought you might know this.
> 
> To do 
> https://codereview.appspot.com/561390043/
>  properly, I have to expand
> the heap when GC notifies us that a collection took place. Unfortunately,
> libgc notifications are done with the garbage collector lock held. So I'll
> need schedule a call to GC_expand_heap on a different thread.
> 
> Would you know what is the best way to do this in C++ nowadays?

If I understand the information correctly, it would be enough to pass
data from the callback to e.g. the main thread, right?

When a single boolean is sufficient (ie call that function now), I'd
start with std::atomic_flag which is guaranteed to be lock-free. Upon
reading the documentation, the semantics are a bit weird (ie
test_and_set sets the flag to true). So you'd need flag.clear() in the
callback and if (!flag.test_and_set()) GC_expand_heap(...) in the main
code. A thin layer around it may improve readability, ie doing the
inverted logic in a struct / class. Alternatively you can use
std::atomic which is probably lock-free on all architectures we
care about.

If you need to transport more than that (ie an integer), the more
generic std::atomic might be a choice. For your concrete case,
declare the following:
static std::atomic_size_t expand_heap = ATOMIC_VAR_INIT(0);
then in the callback:
expand_heap = <<>>;
and in the main thread:
// Benign race condition: Check that there is something to do to avoid
// writes if the variable is already 0. The value is then retrieved
// via exchange() below which is atomic.
if (expand_heap != 0) {
  size_t arg = expand_heap.exchange(0);
  if (arg != 0) {
GC_expand_hp(arg);
  }
}

Does this already solve your needs?
Jonas


signature.asc
Description: This is a digitally signed message part

Re: Splitting Staves

[David Kastrup]

Kieren MacMillan  writes:

> Hi Dan (et al.),
>
>> On Feb 6, 2020, at 09:32, Kieren MacMillan  
>> wrote:
>>> So what I want to work on is some sort of ”Splittable Staff“.
>
> Just to be clear, Valentin wrote that, not me.  =)
>
>> This terminology looks at the use case from a point of view that
>> might not be very consistent with LilyPond.  Let's think carefully
>> about what we want to call this, because names have a way of
>> coloring the problem-solving process.
>
> Agreed.

Without having even looked at the problem, let me add that the
programming/Scheme layer of LilyPond often allows to _map_ a problem
description in composer terms to an approach in LilyPond terms.  So
sometimes finding a consistent way of describing and structuring a
problem may garner the necessary help from the list that then provides a
solution that talks to the user in composer terms, and to the program in
LilyPond terms.

End of pontification.  Just something that tends to lurk in the back of
my mind and sometimes might give a different outlook on a problem.

-- 
David Kastrup
My replies have a tendency to cause friction.  To help mitigating
damage, feel free to forward problematic posts to me adding a subject
like "timeout 1d" (for a suggested timeout of 1 day) or "offensive".

Re: Splitting Staves

[Kieren MacMillan]

Hi David,

> the programming/Scheme layer of LilyPond often allows to _map_
> a problem description in composer terms to an approach in LilyPond terms.
> So sometimes finding a consistent way of describing and structuring a
> problem may garner the necessary help from the list that then provides a
> solution that talks to the user in composer terms, and to the program in
> LilyPond terms.

An excellent point. I’ll think about the problem from a composer’s and 
engraver’s standpoint (where I spend most of my working hours) as well as from 
a programmer’s standpoint (where I only spend a minority of my working hours) 
and see what similarities and differences emerge; hopefully that reflection 
will help when it comes time to discuss possible maps.

Thanks,
Kieren.


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

Re: Add Code of Conduct [Another RFC or not now?]

[David Kastrup]

Karlin High  writes:

> I think the Code of Conduct discussion is reaching (or has reached)
> the point of exhaustion and is unlikely to be productive if continued 
> further in current directions. It seems there is pretty strong
> opposition to adopting the Contributor Covenant Code of Conduct as 
> originally proposed.
>
> I'm thankful for the occasion to self-reflect on Lilypond's discussion
> environment. I've been thinking about this a lot. A point was made 
> earlier that the expectation of having Codes of Conduct in open-source
> communities is not going to go away. In that case, I think it would be 
> best to "fill the vacuum" and adopt something everyone finds
> acceptable. That, as opposed to having a sufficiently-influential
> outside party demand adoption of a Code the community doesn't want, as
> happened to the SQLite project.
>
> In the spirit of the recent "RFC" posts that explore different future
> directions, I think I could soon propose something for a Code of 
> Conduct. (It draws on some centuries-old traditions of community
> conflict resolution.)
>
> However, I'd like to hear from David Kastrup and James Lowe first. To
> me, their opposition registered as the strongest.
>
> Question: Would this opposition apply to all Codes of Conduct as a
> matter of principle? Or just to the particular one that was proposed, 
> and you'd consider supporting a more-acceptable alternative?
>
> And, would you like to see an alternative proposal...

I've proposed looking at the GNU Kind Communication Guidelines as
something that one can point to and aim to heed.
.  It has
certainly worthwhile advice.  I don't see that an approach focused on
providing a promise of punishment and removal will really work for the
predominant problem we are actually dealing with.  I don't think it
makes sense to promise something that one does not aim to keep, or that
one knows by experience that one will not be able to keep in spite of
trying.  A blind person cannot sensibly promise they'll stop overturning
chairs.

I have no problem with getting told "this is not ok".  By anyone.  And
the less delay there is, the sooner I can try getting the overturned
chairs up again.  Routing things through a committee is not making this
easier.  Having a code that allows people to deduce that it is my
behavior that is out of line and tell me so, pointing out just where
that is the case, might help.  But the promise of penalties is something
that will achieve nothing but frustrating both the offended parties as
well as myself until either leaves.

-- 
David Kastrup
My replies have a tendency to cause friction.  To help mitigating
damage, feel free to forward problematic posts to me adding a subject
like "timeout 1d" (for a suggested timeout of 1 day) or "offensive".

Re: event queue with thread for c++

[David Kastrup]

Jonas Hahnfeld via Discussions on LilyPond development
 writes:

> Am Freitag, den 07.02.2020, 19:26 +0100 schrieb Han-Wen Nienhuys:
>> Hey Dan,
>> 
>> I thought you might know this.
>> 
>> To do 
>> https://codereview.appspot.com/561390043/
>>  properly, I have to expand
>> the heap when GC notifies us that a collection took place. Unfortunately,
>> libgc notifications are done with the garbage collector lock held. So I'll
>> need schedule a call to GC_expand_heap on a different thread.
>> 
>> Would you know what is the best way to do this in C++ nowadays?
>
> If I understand the information correctly, it would be enough to pass
> data from the callback to e.g. the main thread, right?
>
> When a single boolean is sufficient (ie call that function now), I'd
> start with std::atomic_flag which is guaranteed to be lock-free. Upon
> reading the documentation, the semantics are a bit weird (ie
> test_and_set sets the flag to true). So you'd need flag.clear() in the
> callback and if (!flag.test_and_set()) GC_expand_heap(...) in the main
> code. A thin layer around it may improve readability, ie doing the
> inverted logic in a struct / class. Alternatively you can use
> std::atomic which is probably lock-free on all architectures we
> care about.
>
> If you need to transport more than that (ie an integer), the more
> generic std::atomic might be a choice. For your concrete case,
> declare the following:
> static std::atomic_size_t expand_heap = ATOMIC_VAR_INIT(0);
> then in the callback:
> expand_heap = <<>>;
> and in the main thread:
> // Benign race condition: Check that there is something to do to avoid
> // writes if the variable is already 0. The value is then retrieved
> // via exchange() below which is atomic.
> if (expand_heap != 0) {
>   size_t arg = expand_heap.exchange(0);
>   if (arg != 0) {
> GC_expand_hp(arg);
>   }
> }
>
> Does this already solve your needs?
> Jonas

It's worth pointing out that almost _all_ of our Scheme-level
allocations are routed through the Smob_core class, so doing the heap
extension _there_ when one passes there next should be workable.  While
the code certainly does allocate non-Smob SCM objects a lot as well (by
calling things like scm_cons), the smobbed ones should be worked often
enough that extending the heap then should not cause too much churn.

-- 
David Kastrup

Re: Add Code of Conduct

[Thomas Morley]

Am Sa., 8. Feb. 2020 um 14:59 Uhr schrieb Kieren MacMillan
:

> To me, the greatest shame is that all the positive energy and momentum coming 
> out of the Salzburg conference is, it seems, in real danger of being shut 
> down by toxic energy of the same kind that has led to the community attrition 
> over the last 5-7 years.
>
> Just an observation from someone who’s been here since 2003, and watched this 
> movie before.

Hi Kieren,

I'd like to fully agree to your statement about the positive energy,
etc out of the Salzburg conference.
It was a great event and great to meet so many people and great to
(I'll stop continuing the list ...).
Again a big, big THANK YOU to Werner and all who made it possible!!

We discussed many plans, among them (without claim of completeness)
- developer-tools (move to GitHub or similar)
- implement stuff from openlilylib
- CoC
- finally migrate to guile-2
- ...

Though, those were plans, sometimes more declarations of intents.
Ofcourse there was not the time to discuss the details.
Home again, and making those plans public, not only more people got
involved (with probably different opinions), but one had a better
opportunity to think over the details.
Thus I think it's natural, thoughts will diverge even more than
already noticed in Salzburg.

Let me pick a not so heated discussed point: developer-tools and share
my own thoughts:
While I still object going for GitHub, I changed my mind wrt to other tools.
I reflected some of my reservations, coming from simply lazyness: I
had to do hard work to get to grips with the current reviewing-setup.
Thus I feared the need to do it again. Nowadays I think, it may be
better to move away from Rietveld/sourceforge.

On other plans even more objections may happen, see James' thoughts
about the CoC.

Again, I think it's natural to observe a broader, more diverging
amount of opinions.

We need to deal with this, without starting a flame-war, going toxic
or whatever, but in a civil way.

Not going into details of the CoC-discussion, why not handle it as what it is:
It's a patch. Review showed there are too many objections. Thus it
should be set to 'needs work' or 'waiting'.
Otoh, there are suggestions to replace this proposal. Why not focus on
those proposals?



For me it's more a shame we are distracted by such discussions from
doing our work.
Although my time is very limited during the usual workingweek, I'd
love to do more on the guile-v2-thingy or at least doing tests for the
already done work, etc. Instead I write this mail (okay, a 'make
test-baseline' runs in the background) or read through very long
threads

Cheers,
  Harm

P.S. that 'make test-baseline' failed, I'll need to investigate after
sending this.

Re: Add Code of Conduct [Another RFC or not now?]

[Karlin High]

On 2/8/2020 9:17 AM, David Kastrup wrote:

I've proposed looking at the GNU Kind Communication Guidelines as
something that one can point to and aim to heed.
.  It has
certainly worthwhile advice.


Thanks for the link. I saw it earlier, wanted to read it later, and 
finally have. I agree with you that it's good advice.



I don't see that an approach focused on
providing a promise of punishment and removal will really work for the
predominant problem we are actually dealing with.


I agree, and think my intended proposal does not focus on providing 
punishment and removal.



I don't think it
makes sense to promise something that one does not aim to keep, or that
one knows by experience that one will not be able to keep in spite of
trying.  A blind person cannot sensibly promise they'll stop overturning
chairs.

I have no problem with getting told "this is not ok".  By anyone.  And
the less delay there is, the sooner I can try getting the overturned
chairs up again.  Routing things through a committee is not making this
easier.  Having a code that allows people to deduce that it is my
behavior that is out of line and tell me so, pointing out just where
that is the case, might help.  But the promise of penalties is something
that will achieve nothing but frustrating both the offended parties as
well as myself until either leaves.


Thanks for sharing. None of that seems like a basic conflict with the 
ideas I have.


In light of the 2 questions earlier, I'm registering this as responses of:

* Not opposed to all Codes of Conduct as a matter of principle, but 
deeply concerned about provisions for their enforcement.


* No proposal now, give the issue a rest

Corrections are desired if I am wrong in that.
--
Karlin High
Missouri, USA

Re: Add Code of Conduct

[David Kastrup]

Thomas Morley  writes:

> Although my time is very limited during the usual workingweek, I'd
> love to do more on the guile-v2-thingy or at least doing tests for the
> already done work, etc. Instead I write this mail (okay, a 'make
> test-baseline' runs in the background) or read through very long
> threads
>
> Cheers,
>   Harm
>
> P.S. that 'make test-baseline' failed, I'll need to investigate after
> sending this.

Now that most of the original guile-v2-work branch is in, I should
likely give this another try and also see which of the remaining three
XXX patches is required and why.  And possibly what else.

I think having a state where it works out of the box without byte
compilation would be a less distracting starting point for searching a
solution for the compilation problem.  It would be disruptive if we had
to abandon the markup macro.  Not that I am the least bit fond of it,
but it's almost omnipresent.

-- 
David Kastrup
My replies have a tendency to cause friction.  To help mitigating
damage, feel free to forward problematic posts to me adding a subject
like "timeout 1d" (for a suggested timeout of 1 day) or "offensive".

Re: Add Code of Conduct

[Kieren MacMillan]

Hi Harm,

Fair points, all.

> Again a big, big THANK YOU to Werner and all who made it possible!!

+1!

> Not going into details of the CoC-discussion, why not handle it as what it is:
> It's a patch. Review showed there are too many objections. Thus it
> should be set to 'needs work' or 'waiting'.
> Otoh, there are suggestions to replace this proposal. Why not focus on
> those proposals?

Excellent suggestion.

Thanks,
Kieren.


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

Re: Add Code of Conduct

[David Kastrup]

Kieren MacMillan  writes:

> Hi Harm,
>
> Fair points, all.
>
>> Again a big, big THANK YOU to Werner and all who made it possible!!
>
> +1!

Major seconded.

>> Not going into details of the CoC-discussion, why not handle it as what it 
>> is:
>> It's a patch. Review showed there are too many objections. Thus it
>> should be set to 'needs work' or 'waiting'.
>> Otoh, there are suggestions to replace this proposal. Why not focus on
>> those proposals?
>
> Excellent suggestion.

Unsurprisingly I am partial to that suggestion.

-- 
David Kastrup
My replies have a tendency to cause friction.  To help mitigating
damage, feel free to forward problematic posts to me adding a subject
like "timeout 1d" (for a suggested timeout of 1 day) or "offensive".

Re: Add Code of Conduct

[David Kastrup]

Thomas Morley  writes:

> P.S. that 'make test-baseline' failed, I'll need to investigate after
> sending this.
>
>

input/regression/display-lily-tests.ly:230:1: fatal error: Test unequal: BUG.
in  = \applyOutput Foo #(lambda (arg) (list))
out = \applyOutput Foo ##f


\test ##[ \applyOutput Foo #(lambda (arg) (list)) #]


Not much of a surprise here: Guile-2 does not keep the source of
functions around in general.  And Urs turned warnings in that file into
errors so that they would not get overlooked.  Which certainly is
sensible, but it means we need to think about what to do here.

-- 
David Kastrup
My replies have a tendency to cause friction.  To help mitigating
damage, feel free to forward problematic posts to me adding a subject
like "timeout 1d" (for a suggested timeout of 1 day) or "offensive".

Re: Add Code of Conduct

[Urs Liska]

Am Samstag, den 08.02.2020, 17:31 +0100 schrieb David Kastrup:
> Thomas Morley  writes:
> 
> > P.S. that 'make test-baseline' failed, I'll need to investigate
> > after
> > sending this.
> > 
> > 
> 
> input/regression/display-lily-tests.ly:230:1: fatal error: Test
> unequal: BUG.
> in  = \applyOutput Foo #(lambda (arg) (list))
> out = \applyOutput Foo ##f
> 
> 
> \test ##[ \applyOutput Foo #(lambda (arg) (list)) #]
> 
> 
> Not much of a surprise here: Guile-2 does not keep the source of
> functions around in general.  And Urs 

? (is there another one around here?)

> turned warnings in that file into
> errors so that they would not get overlooked.  Which certainly is
> sensible, but it means we need to think about what to do here.
> 

Re: Add Code of Conduct

[Urs Liska]

Am Samstag, den 08.02.2020, 17:52 +0100 schrieb David Kastrup:
> Urs Liska  writes:
> 
> > Am Samstag, den 08.02.2020, 17:31 +0100 schrieb David Kastrup:
> > > Thomas Morley  writes:
> > > 
> > > > P.S. that 'make test-baseline' failed, I'll need to investigate
> > > > after
> > > > sending this.
> > > > 
> > > > 
> > > 
> > > input/regression/display-lily-tests.ly:230:1: fatal error: Test
> > > unequal: BUG.
> > > in  = \applyOutput Foo #(lambda (arg) (list))
> > > out = \applyOutput Foo ##f
> > > 
> > > 
> > > \test ##[ \applyOutput Foo #(lambda (arg) (list)) #]
> > > 
> > > 
> > > Not much of a surprise here: Guile-2 does not keep the source of
> > > functions around in general.  And Urs 
> > 
> > ? (is there another one around here?)
> 
> Dan.  Knowing my luck, now both will be offended.  Sorry.

No, I'm not offended ;-)

Urs
> 
> > > turned warnings in that file into
> > > errors so that they would not get overlooked.  Which certainly is
> > > sensible, but it means we need to think about what to do here.

Re: Add Code of Conduct

[David Kastrup]

Urs Liska  writes:

> Am Samstag, den 08.02.2020, 17:31 +0100 schrieb David Kastrup:
>> Thomas Morley  writes:
>> 
>> > P.S. that 'make test-baseline' failed, I'll need to investigate
>> > after
>> > sending this.
>> > 
>> > 
>> 
>> input/regression/display-lily-tests.ly:230:1: fatal error: Test
>> unequal: BUG.
>> in  = \applyOutput Foo #(lambda (arg) (list))
>> out = \applyOutput Foo ##f
>> 
>> 
>> \test ##[ \applyOutput Foo #(lambda (arg) (list)) #]
>> 
>> 
>> Not much of a surprise here: Guile-2 does not keep the source of
>> functions around in general.  And Urs 
>
> ? (is there another one around here?)

Dan.  Knowing my luck, now both will be offended.  Sorry.

>> turned warnings in that file into
>> errors so that they would not get overlooked.  Which certainly is
>> sensible, but it means we need to think about what to do here.

-- 
David Kastrup
My replies have a tendency to cause friction.  To help mitigating
damage, feel free to forward problematic posts to me adding a subject
like "timeout 1d" (for a suggested timeout of 1 day) or "offensive".

Re: Add Code of Conduct [Another RFC or not now?]

[Phil Holmes]

- Original Message - 
From: "Karlin High" 


However, I'd like to hear from David Kastrup and James Lowe first. To 
me, their opposition registered as the strongest.



I remain strongly opposed to a CoC.

--
Phil Holmes

Re: event queue with thread for c++

[Han-Wen Nienhuys]

On Sat, Feb 8, 2020 at 4:23 PM David Kastrup  wrote:

>
> > Does this already solve your needs?
>

I found a way, using pthread_create.  Unfortunately, it's doesn't really
work, because there is no way to discover the size of the live set.



> > Jonas
>
> It's worth pointing out that almost _all_ of our Scheme-level
> allocations are routed through the Smob_core class, so doing the heap
> extension _there_ when one passes there next should be workable.


I'd rather not, that path is somewhat hot. But you do give me an idea now:
I could use the smob count as a proxy for the size of the heap, which is
what I wanted all along.


> While
> the code certainly does allocate non-Smob SCM objects a lot as well (by
> calling things like scm_cons), the smobbed ones should be worked often
> enough that extending the heap then should not cause too much churn.
>
> --
> David Kastrup
>


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

Re: event queue with thread for c++

[David Kastrup]

Han-Wen Nienhuys  writes:

> On Sat, Feb 8, 2020 at 4:23 PM David Kastrup  wrote:
>
>>
>> > Does this already solve your needs?
>>
>
> I found a way, using pthread_create.  Unfortunately, it's doesn't really
> work, because there is no way to discover the size of the live set.

Frankly, if a sophisticated garbage collector is not capable of working
reasonably without extensive help when running for an application that
has no really extraordinary behavior, there is something wrong.  I think
we even do call gc manually between files, when utilisation is expected
to be low.  Given that the GC is somewhat reputed, I doubt that these
online-tuning tricks will give a major boost in performance.  I think
the best we can hope for is getting a reasonably fitting set of initial
parameters.  At least that should save us from runaway conditions.  Or
if not, we have someone we can blame for it.

-- 
David Kastrup
My replies have a tendency to cause friction.  To help mitigating
damage, feel free to forward problematic posts to me adding a subject
like "timeout 1d" (for a suggested timeout of 1 day) or "offensive".

Re: event queue with thread for c++

[Jonas Hahnfeld via Discussions on LilyPond development]

Am Samstag, den 08.02.2020, 18:36 +0100 schrieb Han-Wen Nienhuys:
> 
> 
> On Sat, Feb 8, 2020 at 4:23 PM David Kastrup  wrote:
> > > Does this already solve your needs?
> > 
> 
> I found a way, using pthread_create.  Unfortunately, it's doesn't really 
> work, because there is no way to discover the size of the live set.

Hm, spawning a new thread for every heap resizing doesn't sound like a
good idea. But I'll wait for you to post the patch and then take a
look.

Jonas


signature.asc
Description: This is a digitally signed message part

Re: Add Code of Conduct [Another RFC or not now?]

[Werner LEMBERG]

>> However, I'd like to hear from David Kastrup and James Lowe
>> first. To me, their opposition registered as the strongest.
> 
> I remain strongly opposed to a CoC.

Hmm.  What about simply using the GNU Kind Communication Guidelines,
maybe adding 'LilyPond' at some strategic places?


Werner

Re: Add Code of Conduct [Another RFC or not now?]

[David Kastrup]

Werner LEMBERG  writes:

>>> However, I'd like to hear from David Kastrup and James Lowe
>>> first. To me, their opposition registered as the strongest.
>> 
>> I remain strongly opposed to a CoC.
>
> Hmm.  What about simply using the GNU Kind Communication Guidelines,
> maybe adding 'LilyPond' at some strategic places?

"This page is licensed under a Creative Commons
Attribution-NoDerivatives 4.0 International License."

Which is sort-of stupid given the character of a loose accumulation of
advice, but one could still put something around them stating how we
desire them to be applied to LilyPond's various media.

-- 
David Kastrup
My replies have a tendency to cause friction.  To help mitigating
damage, feel free to forward problematic posts to me adding a subject
like "timeout 1d" (for a suggested timeout of 1 day) or "offensive".

Re: Add Code of Conduct [Another RFC or not now?]

[Carl Sorensen]

On 2/8/20, 10:55 AM, "lilypond-devel on behalf of David Kastrup" 
 
wrote:

Werner LEMBERG  writes:

>>> However, I'd like to hear from David Kastrup and James Lowe
>>> first. To me, their opposition registered as the strongest.
>> 
>> I remain strongly opposed to a CoC.
>
> Hmm.  What about simply using the GNU Kind Communication Guidelines,
> maybe adding 'LilyPond' at some strategic places?

"This page is licensed under a Creative Commons
Attribution-NoDerivatives 4.0 International License."

Which is sort-of stupid given the character of a loose accumulation of
advice, but one could still put something around them stating how we
desire them to be applied to LilyPond's various media.

I think the Werner was asking a question of Phil, namely, would he be opposed 
to using the GNU Kind Communication Guidelines.

Thanks,

Carl
 

Re: Doc: Some miscellaneous suggestions from Peter Toye (issue 579280043 by michael.kaepp...@googlemail.com)

[Werner LEMBERG]

>>> See the line above which is in CMU Concrete!
> 
>> ???  I use Emacs to read my e-mail, and emacs is configured to use
>> the font 'DejaVu Sans Mono' on my GNU/Linux box.  This font
>> contains Cyrillic glyphs...
> 
> I composed that line in the email using CMU Concrete.  Presumably
> your email client changes that.

You have (correctly) sent a plain text e-mail, which doesn't preserve
any font information...

>> None of those fonts contain Cyrillic glyphs.
> 
> OK, that's fine by me. I was confused as earlier emails referred to
> the font family,

Just for clarification.  A font family 'Foo' traditionally consists of
'Foo Regular', 'Foo Bold', 'Foo Italic', and 'Foo Bold Italic'.  Some
font families contain *much* more series – Computer Modern (CM) is
such an example[1] – others contain only a single one.  The PDFs as
produced by texinfo use CM (plus some other, additional fonts, as
mentioned in a previous e-mail).

Note that 'CMU Concrete' is a completely different thing; while based
on CM, it is not part of it.  With 'part of it' I mean that
historically it wasn't part of the fonts that TeX has started many
years ago.

> not the version of the font that are used in the documentation
> project, which you tell me is a subset.

What I'm talking about has nothing to do with font versions.


Werner


[1] To be more precise, CM is a collection of various font families.

Re: Add Code of Conduct [Another RFC or not now?]

[Phil Holmes]

- Original Message - 
From: "Werner LEMBERG" 

To: 
Cc: ; ; ; 
; 

Sent: Saturday, February 08, 2020 5:50 PM
Subject: Re: Add Code of Conduct [Another RFC or not now?]





However, I'd like to hear from David Kastrup and James Lowe
first. To me, their opposition registered as the strongest.


I remain strongly opposed to a CoC.


Hmm.  What about simply using the GNU Kind Communication Guidelines,
maybe adding 'LilyPond' at some strategic places?


   Werner



I've not read them, so can't immediately comment.

FWIW I had substantial experience of managing commercial developments (1,500 
developers, over $200M annual budget).


Every now and then HR would tell us we needed things like this, and force us 
all onto training courses.  It just wasted time.  The best solution is 
always understanding and taking things easy.


--
Phil Holmes 

Re: event queue with thread for c++

[Han-Wen Nienhuys]

On Sat, Feb 8, 2020 at 6:46 PM Jonas Hahnfeld  wrote:

> > > > Does this already solve your needs?
> > I found a way, using pthread_create.  Unfortunately, it's doesn't really
> work, because there is no way to discover the size of the live set.
>
> Hm, spawning a new thread for every heap resizing doesn't sound like a
> good idea. But I'll wait for you to post the patch and then take a
> look.
>

it's already there. You can take a look.

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

Re: RFC: docker for CI

[Han-Wen Nienhuys]

On Sat, Feb 8, 2020 at 2:05 PM Jonas Hahnfeld  wrote:

>
> > >  * if instead we build images for every commit, then incremental
> > > building of a provided patch will be fast(er) (_if_ it doesn't touch
> > > any header file). But what's then the point of using ccache, we can
> > > just trigger a full build?
> >
> > Full builds are slower.
>
> True, but my point is that it doesn't matter: You have to do a full
> build to populate ccache; or you just build with the changes already
> applied, what's the difference?
>
>
the point is that you can take a snapshot of the full build at a point in
time.  As long as the C++ code doesn't change dramatically between that
point and the commit to be tested, you'd get cache hits on a "clean" build
at a new commit, making the whole thing faster.

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

Re: RFC: docker for CI

[Han-Wen Nienhuys]

On Fri, Feb 7, 2020 at 9:48 PM Dan Eble  wrote:

> On Feb 7, 2020, at 15:21, Han-Wen Nienhuys  wrote:
> >>>   * use a headless browser to take a image snapshot of the top of
> regtest
> >>>  result page.
> >>>
> >> Sounds convoluted.  Why not attach the difference images directly?
> >
> > Those are potentially 1372 images to attach if you made a change with
> global impact.
>
> Why not attach the N images with the greatest differences directly?
>
> More generally, I'd want a digest of the results (not all of which are
> visual) that is as useful as possible for the size we are willing to post
> to the review.  We control output-distance.py, so we could generate
> something new that fits this case.
>
>
come to think of it, most of the automated infrastructure (eg. travis,
Google cloud build etc.) operates in terms of builds in containers, and
when something happens, you get the final log file as diagnostic output.
The process in the container doesn't have access to a credential, so it
cannot post anything to Github/gerrit/gitlab/etc.

So it's best if we can make the whole process give diagnostics as ASCII
build logs.

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

Re: Add Code of Conduct [Another RFC or not now?]

[Karlin High]

On 2/8/2020 11:24 AM, Phil Holmes wrote:

I remain strongly opposed to a CoC.


Clearly noted; thanks for responding. I have nothing further to say on 
this topic just now; it's pretty much all been covered in prior messages.


I'm sorry if I got your name wrong. I know "Phil Holmes" and "James 
Lowe" are names associated with great service to the project in managing 
patches and builds, but I have trouble remembering who's who for them.

--
Karlin High
Missouri, USA

Re: RFC: docker for CI

[Jonas Hahnfeld via Discussions on LilyPond development]

Am Samstag, den 08.02.2020, 19:18 +0100 schrieb Han-Wen Nienhuys:
> 
> 
> On Sat, Feb 8, 2020 at 2:05 PM Jonas Hahnfeld  wrote:
> > > >  * if instead we build images for every commit, then incremental
> > > > building of a provided patch will be fast(er) (_if_ it doesn't touch
> > > > any header file). But what's then the point of using ccache, we can
> > > > just trigger a full build?
> > > 
> > > Full builds are slower.
> > 
> > True, but my point is that it doesn't matter: You have to do a full
> > build to populate ccache; or you just build with the changes already
> > applied, what's the difference?
> > 
> 
> the point is that you can take a snapshot of the full build at a point in 
> time.  As long as the C++ code doesn't change dramatically between that point 
> and the commit to be tested, you'd get cache hits on a "clean" build at a new 
> commit, making the whole thing faster.

So you do intend to create a new "base release image" for every commit?
The initial proposal had
> The base release image is made at official LilyPond releases, or at
> any release that has a new graphical regtest result
which means we will have "dramatic" changes of the C++ code later in
the cycle.

Jonas


signature.asc
Description: This is a digitally signed message part

Re: RFC: docker for CI

[Han-Wen Nienhuys]

On Sat, Feb 8, 2020 at 7:24 PM Jonas Hahnfeld  wrote:

> > the point is that you can take a snapshot of the full build at a point
> in time.  As long as the C++ code doesn't change dramatically between that
> point and the commit to be tested, you'd get cache hits on a "clean" build
> at a new commit, making the whole thing faster.
>
> So you do intend to create a new "base release image" for every commit?
> The initial proposal had
> > The base release image is made at official LilyPond releases, or at
> > any release that has a new graphical regtest result
> which means we will have "dramatic" changes of the C++ code later in
> the cycle.
>

We'd make them as often as necessary. My thinking is that we don't have to
do this on every commit.



> Jonas
>


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

Re: Add Code of Conduct [Another RFC or not now?]

[Urs Liska]

Am 8. Februar 2020 19:23:34 MEZ schrieb Karlin High :
>On 2/8/2020 11:24 AM, Phil Holmes wrote:
>> I remain strongly opposed to a CoC.
>
>Clearly noted; thanks for responding. I have nothing further to say on 
>this topic just now; it's pretty much all been covered in prior
>messages.
>
>I'm sorry if I got your name wrong. I know "Phil Holmes" and "James 
>Lowe" are names associated with great service to the project in
>managing 
>patches and builds, but I have trouble remembering who's who for them.

No, you remembered right, James voiced his opposition in even stronger, 
borderline inappropriate ä, words.

Urs

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Re: Add Code of Conduct [Another RFC or not now?]

[pkx166h]

On 08/02/2020 17:50, Werner LEMBERG wrote:

GNU Kind Communication Guidelines


To-may-to, To-mah-to Werner.

Anyway to answer Karlin's request, I am probably the last person in the 
'dev' team to worry about. Yes I seem to do a lot of 'work' but it *is* 
just 'janitorial' duties (which is a rather good way to explain it) and, 
assuming we do manage to get the automation suggestions in place then 
there will be no need of what I do, which will be much better for the 
project (I hope).


Note however that there has never been anything stopping anyone else 
from fully testing patches (I occasionally offer this up when a dev 
complains that things are too slow for them in terms of patch review, or 
if they have a patch sat in the new queue waiting on 'someone' to test). 
Because of lost patches we had a second person (similar to me, a non-dev 
I think, called Colin) that kept track of these (again with useful 
helper scripts from Mark Hohl?).


(If I am mis-remembering names here I apologize)

Colin decided he could no longer commit to his 'LP duties anymore' and 
no one offered to step in, so I did - otherwise nothing would have got 
done it seemed and those existing devs at that time may have become more 
demoralised. So now here we are with me doing both roles and doing them 
manually (more or less) because we ran out of people to step in to do 
these things and the helper scripts stopped working when we moved from 
Google Code.


Anyway, the point is that nothing I do here is as very significant 
compared to those developers that actually write 'code' (I am not 
looking for sympathy here, I am merely stating what I believe), so my 
opinions about a CoC are, in the grand scheme of things, not going to 
affect the code base of LP (i.e. you won't be losing a useful developer 
so to speak), but I was more and more objecting to the seemingly 
selected deafness/blind-eye turning of some of the people commenting on 
this CoC thread as if it was all 'sweetness and light'. So without any 
real skin to loose in this game I spoke up.


If we end up waiting for the automation stuff to be working and THEN 
implement the CoC (or this GNU Happy Place Pamhplet) then it won't 
affect the project at all as my current duties will be voided (and 
again, that is fine). But if this CoC was, as it was seeming as of 
yesterday, a foregone conclusion (unlike the Automation) then I thought 
I better warn the dev team so they could at least plan for my absence.


Maybe this will help focus minds on the automation?

If so, then something positive would have come out of this CoC thread 
after all.


regards

James

Re: Add Code of Conduct [Another RFC or not now?]

[Karlin High]

On 2/8/2020 12:46 PM, pkx1...@posteo.net wrote:

then something positive would have come out of this CoC thread after all.


Thanks for your response; clearly noted.

Phil Holmes makes builds.

James Lowe manages issue and patch reviews.

Hopefully I can remember this.

In my opinion, positive things have indeed come out of these threads. 
They may not be what any one person had in mind, but that's to be 
expected whenever a community discusses something.

--
Karlin High
Missouri, USA

Re: Add Code of Conduct [Another RFC or not now?]

[Kieren MacMillan]

Hi Karlin,

> In my opinion, positive things have indeed come out of these threads. They 
> may not be what any one person had in mind, but that's to be expected 
> whenever a community discusses something.

That’s exactly what I was going to say.  =)

Best,
Kieren.


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

Re[2]: Add Code of Conduct [Another RFC or not now?]

[Trevor]

Phil Holmes wrote 08/02/2020 17:24:56
Subject: Re: Add Code of Conduct [Another RFC or not now?]


- Original Message - From: "Karlin High" 
However, I'd like to hear from David Kastrup and James Lowe first. To me, their 
opposition registered as the strongest.

I remain strongly opposed to a CoC.

As do I. I'm quite sure we on this list are all perfectly capable of 
civil and caring behaviour without having it spelled out in nanny-ish 
terms.


Trevor

Re: Grow heap aggressively during music interpretation (issue 561390043 by hanw...@gmail.com)

[hanwenn]

On 2020/02/08 20:05:53, hanwenn wrote:
> Use smob count as memory proxy

This looks good to me now; softcoding the 2000 is left as an exercise to
the reader in another commit

https://codereview.appspot.com/561390043/

Re: Add Code of Conduct [Another RFC or not now?]

[David Kastrup]

pkx1...@posteo.net writes:

> Anyway to answer Karlin's request, I am probably the last person in
> the 'dev' team to worry about. Yes I seem to do a lot of 'work' but it
> *is* just 'janitorial' duties (which is a rather good way to explain
> it) and, assuming we do manage to get the automation suggestions in
> place then there will be no need of what I do, which will be much
> better for the project (I hope).

The manual comparison of visuals is still not going to do itself.  But
yes, it would be better if the procedures took care of more stuff that
computers can do similarly well to people, given the kind of exact
instructions computers need.

> Anyway, the point is that nothing I do here is as very significant
> compared to those developers that actually write 'code' (I am not
> looking for sympathy here, I am merely stating what I believe),

I hope you will not mind if I believe otherwise.  The whole "janitorial"
procedures have been designed to put grease to the wheels that, in the
form of developers responsible for the "actual" progress, can lean quite
to the squeeky side.  I perfectly well remember the tensions that arose
when we were working with a single master and all developers ground to a
halt for days on end because somebody committed something that had some
trivial oversight somewhere.  Or because weeks later someone complained
that his use case looked much worse than before.

Now it's easy to say "that's work that anyone can do" (though not
entirely correct, particularly given the rather inconspicuous manner in
which you substitute scripts that are falling apart with manual labour,
something one all too easily forgets), doing so reliably for years and
years on end makes it a fixture of stability.  That the sometimes heated
developer discussions are an antithesis of.

Or, more poetically, your work turns a scrapyard of tools into a home
one returns to.

> so my opinions about a CoC are, in the grand scheme of things, not
> going to affect the code base of LP (i.e. you won't be losing a useful
> developer so to speak), but I was more and more objecting to the
> seemingly selected deafness/blind-eye turning of some of the people
> commenting on this CoC thread as if it was all 'sweetness and
> light'. So without any real skin to loose in this game I spoke up.
>
> If we end up waiting for the automation stuff to be working and THEN
> implement the CoC (or this GNU Happy Place Pamhplet)

It's not really a set of rules, just a bunch of advice that has some
chance of working.  Basically it was Stallman's way of saying "we don't
need a Code of Conduct with its enforcement mechanisms if people try
giving others the benefit of doubt some more and take some care to avoid
escalation, and here are a few tips for that".  They won't help against
willful and/or unabating provocations: where they turn disruptive, one
will still have to think about what to do then.  It has happened, but we
got through.

> then it won't affect the project at all as my current duties will be
> voided (and again, that is fine). But if this CoC was, as it was
> seeming as of yesterday, a foregone conclusion (unlike the Automation)
> then I thought I better warn the dev team so they could at least plan
> for my absence.
>
> Maybe this will help focus minds on the automation?
>
> If so, then something positive would have come out of this CoC thread
> after all.

Frankly, the state of the automatation is pitiful, but we were also
partly laboring from a dearth of API documentation IIRC as well as a
lack of people versed in the respective programming
languages/systems/frameworks.

Lame excuses, I know.  At any rate, things on my plate tend to make me
panic, and you give more a steady vibe of clearing plates rather than
stacking things up.  Which may not necessarily always act to your
advantage, but quite to that of the project.

-- 
David Kastrup
My replies have a tendency to cause friction.  To help mitigating
damage, feel free to forward problematic posts to me adding a subject
like "timeout 1d" (for a suggested timeout of 1 day) or "offensive".

Re: Add Code of Conduct [Another RFC or not now?]

[David Kastrup]

Karlin High  writes:

> On 2/8/2020 11:24 AM, Phil Holmes wrote:
>> I remain strongly opposed to a CoC.
>
> Clearly noted; thanks for responding. I have nothing further to say on
> this topic just now; it's pretty much all been covered in prior
> messages.
>
> I'm sorry if I got your name wrong. I know "Phil Holmes" and "James
> Lowe" are names associated with great service to the project in
> managing patches and builds, but I have trouble remembering who's who
> for them.

The mnemonic I go by is that the mail address pkx starts with p which
means that it is James.  Seriously: I suspect that as silly as it
sounds, that may be one of the larger hurdles for developing two
different mental images for people one only identifies by their names
and Email addresses.

-- 
David Kastrup
My replies have a tendency to cause friction.  To help mitigating
damage, feel free to forward problematic posts to me adding a subject
like "timeout 1d" (for a suggested timeout of 1 day) or "offensive".

Re: Add Code of Conduct [Another RFC or not now?]

[David Kastrup]

Trevor  writes:

> Phil Holmes wrote 08/02/2020 17:24:56
> Subject: Re: Add Code of Conduct [Another RFC or not now?]
>
>>- Original Message - From: "Karlin High" >>However, I'd like to hear from David Kastrup and James Lowe
>> first. To me, their opposition registered as the strongest.
>>I remain strongly opposed to a CoC.
>>
> As do I. I'm quite sure we on this list are all perfectly capable of
> civil and caring behaviour without having it spelled out in nanny-ish
> terms.

In my case it is more that spelling it out in nanny-ish and other terms
has been attempted plenty.  At some point of time one has to forego the
wishful thinking and move to mitigation strategies.

-- 
David Kastrup
My replies have a tendency to cause friction.  To help mitigating
damage, feel free to forward problematic posts to me adding a subject
like "timeout 1d" (for a suggested timeout of 1 day) or "offensive".

Re: Add Code of Conduct [Another RFC or not now?]

[Graham Percival]

On Sat, Feb 08, 2020 at 07:21:30PM +, Trevor wrote:
> Phil Holmes wrote 08/02/2020 17:24:56
> Subject: Re: Add Code of Conduct [Another RFC or not now?]
> 
> > - Original Message - From: "Karlin High"  > > However, I'd like to hear from David Kastrup and James Lowe first. To me, 
> > > their opposition registered as the strongest.
> > I remain strongly opposed to a CoC.
> > 
> As do I. I'm quite sure we on this list are all perfectly capable of civil
> and caring behaviour without having it spelled out in nanny-ish terms.

I've stayed silent since I'm not a contributor any more, but if
there's an "I'm sparticus" moment happening, then I will go on
record as saying that I think the proposed CoC is a mistake.

I don't have any reasons that haven't been mentioned already,
other than one meta-reason: proposals like this are very divisive.
Trying to have this discussion in the middle of a "final sprint
towards 2.20" was unfortunate.

I speak from experience on that last point: after the 2012
developer meeting at David's ranch (I think that was the year),
I was all fired up and started a round of divisive discussions
(I think it was the "grand lilypond input syntax standardization").
Within 2-3 weeks, I had squandered all of the good feelings and
energy sparked from that meeting.  I view that as my worst blunder
from all my years of involvement with LilyPond.

Cheers,
- Graham

parser-ly-from-scheme: Make #{ compilable (issue 581610043 by d...@gnu.org)

[thomasmorley65]

Afaict, LGTM

A remark:


https://codereview.appspot.com/581610043/diff/569310043/scm/parser-ly-from-scheme.scm
File scm/parser-ly-from-scheme.scm (right):

https://codereview.appspot.com/581610043/diff/569310043/scm/parser-ly-from-scheme.scm#newcode19
scm/parser-ly-from-scheme.scm:19: (define (read-lily-expression-internal
lily-string filename line closures)
I was going to write that we would need to care about displayLilyMusic
as well, though checking again I noticed:

\void \displayLilyMusic 
\new Voice { \applyContext #(lambda (ctx) (display ctx)) b4 }

with an older lily-build against guile-2.0.14 returns:

\new Voice { \applyContext ##f
 b4 }

A todays build with guile-2.2.6 returned:

\new Voice { \applyContext #(lambda (ctx) (display ctx))
 b4 }

Which is nice.

Not sure whether it's a lilypond or guile improvement.

https://codereview.appspot.com/581610043/

Re: can a Scheme engraver "solve" Issue #34 (grace note bug)? [cross-posted]

[Han-Wen Nienhuys]

On Fri, Feb 7, 2020 at 2:46 PM Kieren MacMillan <
kieren_macmil...@sympatico.ca> wrote:

> Hi all,
>
> Here’s the brainstorm I’ve currently got going:
>
> Issue #34, a.k.a. the grace note bug, is one of Lilypond’s
> longest-standing and most newbie-unfriendly issues. It doesn’t appear in
> single-staff scores, obviously — only in multi-staff scores where one staff
> has a grace note [in the note code] and one or more other staves don’t.
>
> So…
>
> Can Someone™ write a Scheme engraver that listens for grace events and
> automagically adds grace skips of equal duration at the same moment in all
> other staves of a given score? *Intuitively*, \consist-ing that engraver
> into a score sounds to me like the perfect (Band-Aid™?) solution, modulo
> what is apparently a very difficult and/or time-consuming recoding of some
> deep fundamentals in Lilypond’s timing codebase.
>
> Let me know if I’m just talking nonsense.
> If not, let me know how I can help make this "fix" a reality
>


Unfortunately, it's not obvious where to insert the skips. Consider this

staff1 : grace 16th,  whole note

staff2 :  X, whole note

now, if X is a \clef, you probably want to insert the skip after the X, but
if X is a \once \override for the NoteHead, adding a skip after X will make
it inoperable.

I fear this is essentially unsolvable in the current model.

I think the right solution would be to kill grace timing altogether, and
initiate some sort special "embedded" engraving pass that creates the Grace
grobs all at once.

That would have another downside: if we construct the grace note grobs in a
special pass, there is nothing to synchronize them across staves. You could
have two-handed piano music where the left and right hand do grace notes in
a synchronized way. I don't if that exists in practice, but it is one of
the reasons for the current approach.

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

Don't let display-lily-tests use anonymous functions (issue 545550044 by d...@gnu.org)

[thomasmorley65]

LGTM

https://codereview.appspot.com/545550044/

Re: can a Scheme engraver "solve" Issue #34 (grace note bug)? [cross-posted]

[Lukas-Fabian Moser]

Am 08.02.20 um 21:44 schrieb Han-Wen Nienhuys:

I think the right solution would be to kill grace timing altogether, and
initiate some sort special "embedded" engraving pass that creates the Grace
grobs all at once.

That would have another downside: if we construct the grace note grobs in a
special pass, there is nothing to synchronize them across staves. You could
have two-handed piano music where the left and right hand do grace notes in
a synchronized way. I don't if that exists in practice, but it is one of
the reasons for the current approach.


I would expect that synchronized grace notes do exist. But more often 
than not, at least one solitary grace note is meant to happen "some 
infinitesimal amount of time before the main note", without a need to 
keep track of (so-to-say) different lengths of infinitesimal moments 
across voices/staves.


Hence, in combination with accidentals, the current approach leads to 
ugly things like


\version "2.19.82"

<<
  \new Staff { \grace a'8 gis'2 }
  \new Staff { \grace dis'8 e'2 }
>>

(which I encountered quite a lot when engraving, for instance, examples 
from Mozart chamber music).


My standard workaround is to allow LilyPond to use two different points 
in grace time:


\version "2.19.82"

<<
  \new Staff { \grace a'8 gis'2 }
  \new Staff { \grace dis'8*1/2 e'2 }
>>

But that's also not ideal, firstly from a semantic point of view, 
secondly because the visual outcome depends on the chosen factor, while 
I basically want Lily to put the grace not "as close as 
possible/graphically sensible" to the main note.


Best
Lukas

Re: can a Scheme engraver "solve" Issue #34 (grace note bug)? [cross-posted]

[Benkő Pál]

Han-Wen Nienhuys  ezt írta (időpont: 2020. febr. 8., Szo
21:44):

>
>
> If we construct the grace note grobs in a
> special pass, there is nothing to synchronize them across staves. You could
> have two-handed piano music where the left and right hand do grace notes in
> a synchronized way. I don't if that exists in practice, but it is one of
> the reasons for the current approach.
>

IIRC the flower motif of the Turangalila symphony is notated just like
that.  It's a simple note-for-note example; I'll try to find more complex
examples.

p

>

Re: parser-ly-from-scheme: Make #{ compilable (issue 581610043 by d...@gnu.org)

[dak]

Reviewers: thomasmorley651,


https://codereview.appspot.com/581610043/diff/569310043/scm/parser-ly-from-scheme.scm
File scm/parser-ly-from-scheme.scm (right):

https://codereview.appspot.com/581610043/diff/569310043/scm/parser-ly-from-scheme.scm#newcode19
scm/parser-ly-from-scheme.scm:19: (define (read-lily-expression-internal
lily-string filename line closures)
On 2020/02/08 20:35:49, thomasmorley651 wrote:
> I was going to write that we would need to care about displayLilyMusic
as well,
> though checking again I noticed:
> 
> \void \displayLilyMusic 
> \new Voice { \applyContext #(lambda (ctx) (display ctx)) b4 }
> 
> with an older lily-build against guile-2.0.14 returns:
> 
> \new Voice { \applyContext ##f
>  b4 }
> 
> A todays build with guile-2.2.6 returned:
> 
> \new Voice { \applyContext #(lambda (ctx) (display ctx))
>  b4 }
> 
> Which is nice.
> 
> Not sure whether it's a lilypond or guile improvement.

Uh, is this the right issue to discuss this with?  Also
dak@lola:/usr/local/tmp/lilypond$ dpkg -l guile-2.2-dev
Desired=Unknown/Install/Remove/Purge/Hold
|
Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version  Architecture Description
+++-==---=
ii  guile-2.2-dev  2.2.6+1-1amd64Development files for Guile
2.2

Are you completely sure that you are using a version of LilyPond
compiled with Guile-2.2.6?  Because I did not do that fix in issue 5743
on a whim but because code very similar to the above bombed out in
display-lily-tests.ly.  Maybe the test code in there behaves differently
for some reason?

Description:
parser-ly-from-scheme: Make #{ compilable

For better or worse, Guile 2 has problems byte-compiling function
values.  Factor out the previous internal function
read-lily-expression-internal and refer to it by (module-relative)
name rather than value in Guile 2.

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

Affected files (+11, -11 lines):
  M scm/parser-ly-from-scheme.scm


Index: scm/parser-ly-from-scheme.scm
diff --git a/scm/parser-ly-from-scheme.scm b/scm/parser-ly-from-scheme.scm
index 
2c75010ab809df3e24b3736a6021dad8c6604e59..1bd8ac70da2a6cc2e38f0f513f9ff317af8bab47
 100644
--- a/scm/parser-ly-from-scheme.scm
+++ b/scm/parser-ly-from-scheme.scm
@@ -16,6 +16,13 @@
  You should have received a copy of the GNU General Public License
  along with LilyPond.  If not, see .
 
+(define (read-lily-expression-internal lily-string filename line closures)
+  (let* ((clone (ly:parser-clone closures (*location*)))
+ (result (ly:parse-string-expression clone lily-string filename line)))
+(if (ly:parser-has-error? clone)
+(ly:parser-error (_ "error in #{ ... #}") (*location*)))
+result))
+
 (define-public (read-lily-expression chr port)
   "Read a lilypond music expression enclosed within @code{#@{} and @code{#@}}
 from @var{port} and return the corresponding Scheme music expression.
@@ -97,16 +104,9 @@ from @var{port} and return the corresponding Scheme music 
expression.
   (else
(do ((c (copy-char) (copy-char)))
((char=? c #\nl)
-
-(define (embedded-lilypond lily-string filename line closures)
-  (let* ((clone (ly:parser-clone closures (*location*)))
- (result (ly:parse-string-expression clone lily-string
- filename line)))
-(if (ly:parser-has-error? clone)
-(ly:parser-error (_ "error in #{ ... #}") (*location*)))
-result))
-(list embedded-lilypond
-  lily-string filename line
-  (cons 'list (reverse! closures)
+(list (if (guile-v2)
+  '(@@ (lily) read-lily-expression-internal)
+  read-lily-expression-internal)
+  lily-string filename line (cons 'list (reverse! closures)
 
 (read-hash-extend #\{ read-lily-expression)

Re: ’Pond Jobs & Their Descriptions

[Janek Warchoł]

Hi Kieren,

czw., 6 lut 2020 o 00:55 Kieren MacMillan 
napisał(a):

> Hello all!
>
> I’m curious as to all the various jobs/tasks required to keep Lilypond
> development moving forward at the fastest possible pace and in the most
> efficient possible way. Is there a single list compiled anywhere, written
> with an eye to extreme granularity? (The closest I can find is <
> http://lilypond.org/doc/v2.19/Documentation/contributor/help-us>, and the
> 9 bullet points there are at least an order of magnitude fewer than the
> list I’m thinking of.) If not, I’ll start a list, brainstormed from my
> naïve perspective.
>

I appreciate the initiative, and I agree that we could use a clearer view
on the responsibilities and skills needed in the community. However, I am
pretty sure that creating a detailed list is not an effective way of
solving this problem. I'm pretty sure that we'd spend a *lot* of time on
discussion and even if we agree on the results, it'll be even more work to
implement the processes, and until it's ready there would be no tangible
benefits. My whole professional experience taught me that such
planning-heavy approaches are costly and often fail.

Do you know about agile methodologies? In short, they are about doing work
iteratively: instead of making a detailed plan and following it (usually
until you discover midway that, because of missing data, half of the plan
doesn't make sense), start with setting a small self-contained goal,
complete it (with only basic planning), and when you're done you take step
back to include what you've learned in the process. It usually yields much
better results. You may find this link helpful (but I suggest that you
don't go on reading everything on that site):
https://www.atlassian.com/agile/manifesto

Therefore I suggest to apply the Pareto principle (
https://en.wikipedia.org/wiki/Pareto_principle) and do something much more
lightweight. For example, I suggest to ask this question: what are the 3
areas where LP community is most "shortstaffed"? (e.g. do we need more
people to do patch review, testing automation, whatever?). Once we discover
that, I would go on asking "what's the one thing that would make it
easier/more attractive to contribute in that area". Boom, 2 weeks later we
actually have some specific improvements.


czw., 6 lut 2020 o 01:21 Graham Percival 
napisał(a):

> On Wed, Feb 05, 2020 at 06:55:38PM -0500, Kieren MacMillan wrote:
>
> (c) help new developers find the best way in to the 'Pond.
>
> I'm not up to date on current LilyPond,


Whoah, Graham! Nice to see you, man! Long time no see :-)


> but I suspect that the
> answer is "try to find developers willing to mentor".


I'm willing to mentor, as I've committed to improving LP contributor
experience (even though not much happened on that front from my side, as I
got sidetracked by huge CoC discussion).

BTW do you remember that about 8 years ago I promised you to mentor some
"Frogs" when my patch for shortened flags will be merged? It's still not
done, but whatever, I want to keep my promise ;-)

Best,
Janek

[RFC] weekly dev chats

[Janek Warchoł]

Hello,

I just got inspired by the Agile Manifesto Principles[1], specifically:
> The most efficient and effective method of
> conveying information to and within a development
> team is face-to-face conversation.

This reminded me how dynamic, positive and motivating were the LP talks in
Salzburg. To get more of such energy I suggest to have weekly dev
"meetings". Since not everyone would be able to participate (at least
regularly), no binding decisions should be made there, but I'm quite sure
it'll be helpful in getting better understanding and common perspective
across the community.

I'd be willing to organize and moderate the meetings (take care of
preparing the agenda and sharing the take-aways with the devel list). I
know that it'd be a challenge to find a time that will work for people from
different timezones, but I'll figure somethig out (have some ideas already).

Thumbs up or thumbs down?

Janek

[1] https://agilemanifesto.org/principles.html

Re: ’Pond Jobs & Their Descriptions

[Kieren MacMillan]

Hi Janek,

> I appreciate the initiative, and I agree that we could use a clearer view on 
> the responsibilities and skills needed in the community. However, I am pretty 
> sure that creating a detailed list is not an effective way of solving this 
> problem. I'm pretty sure that we'd spend a *lot* of time on discussion and 
> even if we agree on the results, it'll be even more work to implement the 
> processes

What processes? I never suggested any processes be developed or implemented.

> and until it's ready there would be no tangible benefits

I don’t see that as a necessary condition of what I’m suggesting.

> Do you know about agile methodologies?

Yes. And in fact I’m trying to use them.  :)

> start with setting a small self-contained goal, complete it (with only basic 
> planning), and when you're done you take step back to include what you've 
> learned in the process.

That’s exactly what I’m doing.

> I suggest to ask this question: what are the 3 areas where LP community is 
> most "shortstaffed"?

I’m curious how you’re going to answer that question without actually knowing 
what the areas of the LP community are.

> Once we discover that, I would go on asking "what's the one thing that would 
> make it easier/more attractive to contribute in that area". Boom, 2 weeks 
> later we actually have some specific improvements.

Well, nothing is stopping you from doing that in parallel to my [personal] 
effort.

> I'm willing to mentor, as I've committed to improving LP contributor 
> experience

Just an FYI: I’m not going to even bother trying to set up any repositories or 
LilyDev or anything development-related until the contributor experience and 
toolchain is settled on. So the sooner you get that done, the sooner you can 
mentor me in whatever the new processes and toolchains are.

Regards,
Kieren.


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

Re: RFC: docker for CI

[Janek Warchoł]

In principle, thumbs up. However, I think it's essential that we don't try
to do too much at once; I'd suggest to focus on one most important aspect
first. To do that, I'd like to ask a helper question: what are 2 most
important reasons for using Docker instead of Patchy? In other words, what
are 2 things that we want to be able to do which are impossible/difficult
with Patchy? (your proposal tells about the "what?" and the "how?", I'd
like to know the "why?")

cheers :-)
Janek



pt., 7 lut 2020 o 13:21 Han-Wen Nienhuys  napisał(a):

> Proposal: rather than using the patchy scripts for validating
> LilyPond, we use docker images.
>
> General idea
> 
>
> There is a script ("driver") that drives docker running on a dedicated
> build machine ("host").
>
> There are several images:
>
> * The base dev image.
>
> The base image is based on some stripped Linux distribution, with all
> the devtools necessary for compiling LilyPond. In addition, it
> contains a copy of ccache, and a git clone of the LilyPond sourcecode
>
> * The base release image for a specific git commit.
>
> The procedure to build it is as follows:
>
>   * take the base dev image
>   * fetch the git commit
>   * runs (make ; make test-baseline)
>   * runs (make dist-clean)
>
> This saves the result as a docker image. The Docker image now contains
> a clean lilypond tree, the C++ compilation results (in ccache), and a
> test baseline.
>
> The base release image is made at official LilyPond releases, or at
> any release that has a new graphical regtest result
>
>
> CI: build binary
> 
>
> Given a proposed change (as git commit):
>
>  * take base release image
>  * run (make; make doc) >& log-file
>
> On success, the driver saves the result as a docker image, tagged with the
> commit sha1.
>
> On failure, the driver uploads the last bit of the log-file to our code
> review system.
>
>
> CI: regtest
> ===
>
> Given a proposed change (as git commit)
>
>   * take CI build image
>   * run (make check >& log-file)
>   * use a headless browser to take a image snapshot of the top of regtest
> result page.
>
>
> On success, the driver uploads the image snapshot to code review.
>
> On failure, the driver uploads the last bit of the log-file to code review.
>
>
> Considerations
> ==
>
> * Because the build happens inside a container, we can test multiple
>   builds. We could build against guile 1.8 and 2.2 at the same time,
>   for example
>
> * Because the "build binary" step reuses CCache results, it can
>   complete quickly.
>
> * The regtest continues to be expensive to compute. In the future, I
>   hope it would not need a human to kick it off or post results back
>   into review, but likely, it should require a manual step in the
>   review process to kick off, eg. in Gerrit "Run-Regtest" +1 vote.
>
> * For security, the host should use https://github.com/google/gvisor
>   to avoid being hacked by malicious code in proposed changes.
>
> --
> Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
>

Re: [RFC] weekly dev chats

[Kieren MacMillan]

Hi Janek,

> I suggest to have weekly dev "meetings".

If they are at a time when I’m available, I’d be more than happy to be involved.

Regardless, it’s a great idea — in fact, I was in the middle of drafting an 
email to suggest it when your email came through.  =)

Cheers,
Kieren.


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

Re: RFC: docker for CI

[Janek Warchoł]

sob., 8 lut 2020 o 23:30 Janek Warchoł 
napisał(a):

> In principle, thumbs up. However, I think it's essential that we don't try
> to do too much at once; I'd suggest to focus on one most important aspect
> first. To do that, I'd like to ask a helper question: what are 2 most
> important reasons for using Docker instead of Patchy? In other words, what
> are 2 things that we want to be able to do which are impossible/difficult
> with Patchy?
>

In yet another words: please give me a "user story" so that I can visualize
the outcome :-)

Re: [RFC] Commit message format

[Janek Warchoł]

+1 to all parts of the proposal from me.

pt., 7 lut 2020 o 16:39 Han-Wen Nienhuys  napisał(a):

> Currently, on push most our commit messages look like:
>
> Issue XXX: Subject
>
> Body
> Body
>
>
> There are a couple of downsides to this format:
>
> * The number takes up space in the
>
> git log --format=short
>
>   output
>
> * The number is meaningless without the site that hosts the tracker
>
> Proposal
> ===
>
> I would like to propose a different format,
>
> Subject
>
> Body
> Body
>
> Link to code review
> Link to issue
>
> By embedding the links, we offer something clickable to whomever is
> browsing the commit message.
>
> Somewhat relatedly, I would like to propose to use SHA1s + subject
> lines to refer to previous changes, rather than issue numbers, eg.
>
>04a0dc ("Disable Python's hash randomization")
>
> this makes the reference impervious to problems with the issue tracker
> (network outage, renumbering due to server migrations, etc). Including
> the subject line makes it easier to intuitively understand what is going
> on.
>
> Finally, I want to encourage everyone to write Why something was
> changed rather What. One can deduce what changed by looking at the
> commit message.  It is much harder to fathom Why some change was
> necessary.
>
> --
> Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
>

displayLilyMusic and guilev2

[Thomas Morley]

Hi,

one problem with guilev2 are anonymous procedures. Like how to get
nice output for

\void
\displayLilyMusic \new Voice { \applyContext #(lambda (ctx) (display ctx)) b4 }

An older lily-build out of e57c27dc14 with the patches from
guilev2-work on top and guile-2.0.14 returned:
\new Voice { \applyContext ##f b4 }
Which is suboptimal.

A todays build out of c334743a6d and guile-2.2.6, selfcompiled out of
~/guile-2.2 (my-guile-2-2-6)$ git log --oneline
9a11be136 (HEAD -> my-guile-2-2-6, origin/stable-2.2)
00-repl-server.test: don't use fixed path for socket
5d2956497 Respect thread local fluid defaults
aa0bfa2f9 Fix peval bug that ignored excess args
fb7b873af web: Update comment regarding the 'tls-wrap' port wrapper.
edf5aea7a Fix non-deterministic crash in 'finalization_thread_proc'.
659526d33 ports: 'scm_port_poll' honors "w" flags.
a69b567d9 (guile-2.2.6) build: Do not record LDFLAGS in .pc file.
85de8637c (tag: v2.2.6) Bump version for Guile 2.2.6.
...

returns:
\new Voice { \applyContext #(lambda (ctx) (display ctx)) b4 }
which is nice again and the same as in 2.19.84 with guile-1.8

Does anybody knows whether it's a guile- or lily-improvement?


Cheers,
  Harm

Re: parser-ly-from-scheme: Make #{ compilable (issue 581610043 by d...@gnu.org)

[thomasmorley65]

On 2020/02/08 22:02:59, dak wrote:

> Uh, is this the right issue to discuss this with?  

Likely not, I opened a thread on -devel.


> Are you completely sure that you are using a version of LilyPond
compiled with
> Guile-2.2.6?  

At least 
$ lilypond-git scheme-sandbox

returns:

GNU LilyPond 2.21.0
Processing
`/home/hermann/lilypond-git/build/out/share/lilypond/current/ly/scheme-sandbox.ly'
Parsing...
GNU Guile 2.2.6.7-9a11b
[...]




https://codereview.appspot.com/581610043/

Re: Add Code of Conduct [Another RFC or not now?]

[David Kastrup]

Graham Percival  writes:

> On Sat, Feb 08, 2020 at 07:21:30PM +, Trevor wrote:
>> Phil Holmes wrote 08/02/2020 17:24:56
>> Subject: Re: Add Code of Conduct [Another RFC or not now?]
>> 
>> > - Original Message - From: "Karlin High" > > > However, I'd like to hear from David Kastrup and James Lowe
>> > first. To me, their opposition registered as the strongest.
>> > I remain strongly opposed to a CoC.
>> > 
>> As do I. I'm quite sure we on this list are all perfectly capable of civil
>> and caring behaviour without having it spelled out in nanny-ish terms.
>
> I've stayed silent since I'm not a contributor any more, but if
> there's an "I'm sparticus" moment happening, then I will go on
> record as saying that I think the proposed CoC is a mistake.
>
> I don't have any reasons that haven't been mentioned already,
> other than one meta-reason: proposals like this are very divisive.
> Trying to have this discussion in the middle of a "final sprint
> towards 2.20" was unfortunate.
>
> I speak from experience on that last point: after the 2012
> developer meeting at David's ranch (I think that was the year),
> I was all fired up and started a round of divisive discussions
> (I think it was the "grand lilypond input syntax standardization").

GLISS was not a new project: it had been ongoing from before my
involvement.  A bit of a problem was that it had been going on for a
while without sensible feedback from those who had a good grasp of the
existing parser/lexer implementation of the input language of LilyPond,
and that input language had a lot of ad-hoc elements.

> Within 2-3 weeks, I had squandered all of the good feelings and energy
> sparked from that meeting.  I view that as my worst blunder from all
> my years of involvement with LilyPond.

Hey, I had chalked this up to my slate.  In retrospect, I saw LilyPond
in need to grow roots and you saw it in need to grow wings.  And we were
both excited about its new momentum.  You saw new potential but I am a
lousy follower: I am unable to follow through with anything that I don't
see as the best course.  Heck, I am not even good at following through
with stuff I do see as the best course.

You've clearly been the much better organiser and motivator: the people
who still keep the "shop running" are doing so in processes originally
set up by you and given meaning by you.  And I am basically drawing
blanks when thinking about how to make people pick up the slack when
someone ultimately leaves.

I still think we should have been able to make this work better between
us but have no idea how.  And that's bad because LilyPond needs to
become better at making its community members count, and core
programmers can only do so much of the heavy lifting even when they are
all in agreement.

-- 
David Kastrup
My replies have a tendency to cause friction.  To help mitigating
damage, feel free to forward problematic posts to me adding a subject
like "timeout 1d" (for a suggested timeout of 1 day) or "offensive".

Re: can a Scheme engraver "solve" Issue #34 (grace note bug)? [cross-posted]

[David Kastrup]

Han-Wen Nienhuys  writes:

> Unfortunately, it's not obvious where to insert the skips. Consider this
>
> staff1 : grace 16th,  whole note
>
> staff2 :  X, whole note
>
> now, if X is a \clef, you probably want to insert the skip after the X, but
> if X is a \once \override for the NoteHead, adding a skip after X will make
> it inoperable.
>
> I fear this is essentially unsolvable in the current model.
>
> I think the right solution would be to kill grace timing altogether, and
> initiate some sort special "embedded" engraving pass that creates the Grace
> grobs all at once.
>
> That would have another downside: if we construct the grace note grobs in a
> special pass, there is nothing to synchronize them across staves. You could
> have two-handed piano music where the left and right hand do grace notes in
> a synchronized way. I don't if that exists in practice, but it is one of
> the reasons for the current approach.

I don't think grace notes are usually synchronized optically.  I may be wrong.

-- 
David Kastrup

Re: [RFC] weekly dev chats

[David Kastrup]

Janek Warchoł  writes:

> Hello,
>
> I just got inspired by the Agile Manifesto Principles[1], specifically:
>> The most efficient and effective method of
>> conveying information to and within a development
>> team is face-to-face conversation.
>
> This reminded me how dynamic, positive and motivating were the LP talks in
> Salzburg. To get more of such energy I suggest to have weekly dev
> "meetings". Since not everyone would be able to participate (at least
> regularly), no binding decisions should be made there, but I'm quite sure
> it'll be helpful in getting better understanding and common perspective
> across the community.
>
> I'd be willing to organize and moderate the meetings (take care of
> preparing the agenda and sharing the take-aways with the devel list). I
> know that it'd be a challenge to find a time that will work for people from
> different timezones, but I'll figure somethig out (have some ideas already).
>
> Thumbs up or thumbs down?

What kind of meeting were you thinking of?  IRC/Chat?  Voice?  And/or
video?

-- 
David Kastrup

Re: can a Scheme engraver "solve" Issue #34 (grace note bug)? [cross-posted]

[Kieren MacMillan]

Hi David (et al.),

> I don't think grace notes are usually synchronized optically.

According to our recent "live-from-London" keynote speaker…  ;)

… you are correct — in fact, in one example, she shows how grace groups [of 
different "sizes"] on two different staves can be compressed [to the right] to 
be closer to the principal note/beat, thus "ruining" any optical 
synchronization between the staves.

Cheers,
Kieren.


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

Re: displayLilyMusic and guilev2

[David Kastrup]

Thomas Morley  writes:

> Hi,
>
> one problem with guilev2 are anonymous procedures. Like how to get
> nice output for
>
> \void
> \displayLilyMusic \new Voice { \applyContext #(lambda (ctx) (display ctx)) b4 
> }
>
> An older lily-build out of e57c27dc14 with the patches from
> guilev2-work on top and guile-2.0.14 returned:
> \new Voice { \applyContext ##f b4 }
> Which is suboptimal.
>
> A todays build out of c334743a6d and guile-2.2.6, selfcompiled out of
> ~/guile-2.2 (my-guile-2-2-6)$ git log --oneline
> 9a11be136 (HEAD -> my-guile-2-2-6, origin/stable-2.2)
> 00-repl-server.test: don't use fixed path for socket
> 5d2956497 Respect thread local fluid defaults
> aa0bfa2f9 Fix peval bug that ignored excess args
> fb7b873af web: Update comment regarding the 'tls-wrap' port wrapper.
> edf5aea7a Fix non-deterministic crash in 'finalization_thread_proc'.
> 659526d33 ports: 'scm_port_poll' honors "w" flags.
> a69b567d9 (guile-2.2.6) build: Do not record LDFLAGS in .pc file.
> 85de8637c (tag: v2.2.6) Bump version for Guile 2.2.6.
> ...
>
> returns:
> \new Voice { \applyContext #(lambda (ctx) (display ctx)) b4 }
> which is nice again and the same as in 2.19.84 with guile-1.8
>
> Does anybody knows whether it's a guile- or lily-improvement?

No idea.  It might be a different compilation option or environment or
eval setting that is at work here because I have ostensibly also a 2.2.6
and your commits on top of the tag don't look like they could make a
difference.

-- 
David Kastrup
My replies have a tendency to cause friction.  To help mitigating
damage, feel free to forward problematic posts to me adding a subject
like "timeout 1d" (for a suggested timeout of 1 day) or "offensive".

Re: [RFC] weekly dev chats

[Janek Warchoł]

sob., 8 lut 2020 o 23:56 David Kastrup  napisał(a):

> Janek Warchoł  writes:
> > I'd be willing to organize and moderate the meetings (take care of
> > preparing the agenda and sharing the take-aways with the devel list). I
> > know that it'd be a challenge to find a time that will work for people
> from
> > different timezones, but I'll figure somethig out (have some ideas
> already).
> >
> > Thumbs up or thumbs down?
>
> What kind of meeting were you thinking of?  IRC/Chat?  Voice?  And/or
> video?
>

Right, I should have clarified that. I'm thinking about voice call. (Video
call would be great but I expect it may result in more problems than
benefits.)

Thanks for asking!
Janek

Re: displayLilyMusic and guilev2

[Thomas Morley]

Am Sa., 8. Feb. 2020 um 23:59 Uhr schrieb David Kastrup :
>
> Thomas Morley  writes:
>
> > Hi,
> >
> > one problem with guilev2 are anonymous procedures. Like how to get
> > nice output for
> >
> > \void
> > \displayLilyMusic \new Voice { \applyContext #(lambda (ctx) (display ctx)) 
> > b4 }
> >
> > An older lily-build out of e57c27dc14 with the patches from
> > guilev2-work on top and guile-2.0.14 returned:
> > \new Voice { \applyContext ##f b4 }
> > Which is suboptimal.
> >
> > A todays build out of c334743a6d and guile-2.2.6, selfcompiled out of
> > ~/guile-2.2 (my-guile-2-2-6)$ git log --oneline
> > 9a11be136 (HEAD -> my-guile-2-2-6, origin/stable-2.2)
> > 00-repl-server.test: don't use fixed path for socket
> > 5d2956497 Respect thread local fluid defaults
> > aa0bfa2f9 Fix peval bug that ignored excess args
> > fb7b873af web: Update comment regarding the 'tls-wrap' port wrapper.
> > edf5aea7a Fix non-deterministic crash in 'finalization_thread_proc'.
> > 659526d33 ports: 'scm_port_poll' honors "w" flags.
> > a69b567d9 (guile-2.2.6) build: Do not record LDFLAGS in .pc file.
> > 85de8637c (tag: v2.2.6) Bump version for Guile 2.2.6.
> > ...
> >
> > returns:
> > \new Voice { \applyContext #(lambda (ctx) (display ctx)) b4 }
> > which is nice again and the same as in 2.19.84 with guile-1.8
> >
> > Does anybody knows whether it's a guile- or lily-improvement?
>
> No idea.  It might be a different compilation option or environment or
> eval setting that is at work here because I have ostensibly also a 2.2.6
> and your commits on top of the tag don't look like they could make a
> difference.

To be sure, you still get:
\new Voice { \applyContext ##f b4 }
?

Cheers,
  Harm

Re: [RFC] weekly dev chats

[David Kastrup]

Janek Warchoł  writes:

> sob., 8 lut 2020 o 23:56 David Kastrup  napisał(a):
>
>> Janek Warchoł  writes:
>> > I'd be willing to organize and moderate the meetings (take care of
>> > preparing the agenda and sharing the take-aways with the devel list). I
>> > know that it'd be a challenge to find a time that will work for people
>> from
>> > different timezones, but I'll figure somethig out (have some ideas
>> already).
>> >
>> > Thumbs up or thumbs down?
>>
>> What kind of meeting were you thinking of?  IRC/Chat?  Voice?  And/or
>> video?
>>
>
> Right, I should have clarified that. I'm thinking about voice call. (Video
> call would be great but I expect it may result in more problems than
> benefits.)
>
> Thanks for asking!
> Janek

Found "Pidgin messenger" installed on my Ubuntu Studio.  It purports to
talk AIM, Bonjour, Gadu-Gadu, Google Talk, Groupwise, ICQ, IRC, Simple,
Sametime, XMPP and Zephyr.  No idea whether it does screencasts.

-- 
David Kastrup
My replies have a tendency to cause friction.  To help mitigating
damage, feel free to forward problematic posts to me adding a subject
like "timeout 1d" (for a suggested timeout of 1 day) or "offensive".

Re: displayLilyMusic and guilev2

[David Kastrup]

Thomas Morley  writes:

> Am Sa., 8. Feb. 2020 um 23:59 Uhr schrieb David Kastrup :
>>
>> Thomas Morley  writes:
>>
>> > Hi,
>> >
>> > one problem with guilev2 are anonymous procedures. Like how to get
>> > nice output for
>> >
>> > \void
>> > \displayLilyMusic \new Voice { \applyContext #(lambda (ctx) (display ctx)) 
>> > b4 }
>> >
>> > An older lily-build out of e57c27dc14 with the patches from
>> > guilev2-work on top and guile-2.0.14 returned:
>> > \new Voice { \applyContext ##f b4 }
>> > Which is suboptimal.
>> >
>> > A todays build out of c334743a6d and guile-2.2.6, selfcompiled out of
>> > ~/guile-2.2 (my-guile-2-2-6)$ git log --oneline
>> > 9a11be136 (HEAD -> my-guile-2-2-6, origin/stable-2.2)
>> > 00-repl-server.test: don't use fixed path for socket
>> > 5d2956497 Respect thread local fluid defaults
>> > aa0bfa2f9 Fix peval bug that ignored excess args
>> > fb7b873af web: Update comment regarding the 'tls-wrap' port wrapper.
>> > edf5aea7a Fix non-deterministic crash in 'finalization_thread_proc'.
>> > 659526d33 ports: 'scm_port_poll' honors "w" flags.
>> > a69b567d9 (guile-2.2.6) build: Do not record LDFLAGS in .pc file.
>> > 85de8637c (tag: v2.2.6) Bump version for Guile 2.2.6.
>> > ...
>> >
>> > returns:
>> > \new Voice { \applyContext #(lambda (ctx) (display ctx)) b4 }
>> > which is nice again and the same as in 2.19.84 with guile-1.8
>> >
>> > Does anybody knows whether it's a guile- or lily-improvement?
>>
>> No idea.  It might be a different compilation option or environment or
>> eval setting that is at work here because I have ostensibly also a 2.2.6
>> and your commits on top of the tag don't look like they could make a
>> difference.
>
> To be sure, you still get:
> \new Voice { \applyContext ##f b4 }
> ?

dak@lola:/usr/local/tmp/lilypond$ out/bin/lilypond scheme-sandbox
GNU LilyPond 2.21.0
Processing 
`/usr/local/tmp/lilypond/out/share/lilypond/current/ly/scheme-sandbox.ly'
Parsing...
GNU Guile 2.2.6
Copyright (C) 1995-2019 Free Software Foundation, Inc.

Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
This program is free software, and you are welcome to redistribute it
under certain conditions; type `,show c' for details.

Enter `,help' for help.
scheme@(#{ g161}#)> (void (displayLilyMusic #{ \new Voice { \applyContext 
#(lambda (ctx) (display ctx)) b4 } #}))

\new Voice { \applyContext ##f
 b4 }
scheme@(#{ g161}#)> 


Success: compilation successfully completed
dak@lola:/usr/local/tmp/lilypond$ 

\void
\displayLilyMusic \new Voice { \applyContext #(lambda (ctx) (display ctx)) b4 }


-*- mode: compilation; default-directory: "/tmp/" -*-
Compilation started at Sun Feb  9 00:21:33

/usr/local/tmp/lilypond/out/bin/lilypond hh.ly
GNU LilyPond 2.21.0
Processing `hh.ly'
Parsing...
\new Voice { \applyContext ##f
 b4 }

hh.ly:1: warning: no \version statement found, please add

\version "2.21.0"

for future compatibility
Success: compilation successfully completed

Compilation finished at Sun Feb  9 00:21:35



-- 
David Kastrup
My replies have a tendency to cause friction.  To help mitigating
damage, feel free to forward problematic posts to me adding a subject
like "timeout 1d" (for a suggested timeout of 1 day) or "offensive".

Re: Add Code of Conduct

[Janek Warchoł]

Elaine,

pt., 7 lut 2020 o 02:28 Flaming Hakama by Elaine 
napisał(a):

> 1) "Adopt this CoC or I will leave the community"  Such threats amount to a
> my-way-or-the-highway attitude, which is an attempt to enforce veto power
> in what is supposed to be a collaborative / concensus / democratic
> approach.  Also difficult to disentangle the degree to which this is
> intentionally or unintentionally an unprofessional attempt to elicit
> praise, with the expected reactions of "oh no, don't leave, you're too
> valuable".  To me, this is toxic behavior and I would welcome their
> self-removal from the community if this is their idea of how to conduct
> themselves in an exemplary manner.
>

Such behaviour is indeed bad, but did anyone actually post such an
ultimatum? Speaking about myself, I definitely don't consider adopting CoC
a condition for my return to the community. If that wasn't clear, I
apologize.


> 2) Being disingenuous regarding the point of the CoC.  While it may be a
> bit overboard for DK to assume that removing him is the sole point of the
> proposal, it is equally disingenuous for the proposers of the CoC to
> suggest that any such consequences would be unintended, since that is the
> *only* actionalble part of the proposal, and DK is the most obvious target
> for such concerns.  What has become clear to me is that there is a
> disharmony between the original BDFL and the incumbent BDFL.  This specific
> proposal for a CoC seems to me to be an attempt to provide the *appearance*
> of some kind of consensus-based or otherwise democratic process, in an
> effort to reinstate the original BDFL and dethrone the incumbent BDFL, when
> in fact there is nothing consensus-based or democratic about the proposal
> at all.  So, it has a taste of insencerity and disguised motives, which is
> exactly the opposite of what a CoC should be engendering.
>

Okay, I admit that I didn't think (or rather: think hard enough) about how
the proposal will be perceived by DK and the community. I apologize for
this lack of thoughtfulness. I can only say that my motivation was to help
the community grow, by addressing the issue that I found most troublesome
for me (tension and heated discussions between contributors), and I wanted
to just get it done. Bad approach.


pt., 7 lut 2020 o 06:03 Carl Sorensen  napisał(a):

> I trust each of the individuals who were proposed to be on the committee.


I am humbled to hear this from you, especially after this long discussion
and the enormous amount of protests and suspicion about my (our) motivation.


> The main issue I had (and continue to have) with the proposed CoC is the
> prospect of punitive-appearing enforcement actions taken after a private
> process with the complainant remaining anonymous.
>

Absolutely, and I assure that - if I were to be part of the committee - I
would never have done that. (I can see that it may not had been clear from
the proposed CoC.)

I would not be concerned about anonymous "I felt" statements were the job
> of the committee to provide support to the complainant, rather than to
> provide consequences to the putative offender.
>

You are right. In fact, I had considered providing support to the
complainant to be the basic job of the committee (not punishing anyone).
But I can see that it was not clear from the proposal.

I see Mike Solomon and Janek as the most open proponents of the CoC.
> Neither one appears to want power in the LilyPond organizational
> structure.  Both appear to want a more welcoming and less stressful
> community.  I think it's important to take their requests at face value,
> rather than assuming hidden agendas.
>

Thank you, Carl. Yes, this is (and was) exactly my motivation, and I'd be
grateful if the community took it as such (similarly how we try to take
David's email literally and not as sarcasm).

Janek

Re: Add Code of Conduct

[David Kastrup]

Janek Warchoł  writes:

> Elaine,
>
> pt., 7 lut 2020 o 02:28 Flaming Hakama by Elaine 
> napisał(a):
>
>> 1) "Adopt this CoC or I will leave the community"  Such threats amount to a
>> my-way-or-the-highway attitude, which is an attempt to enforce veto power
>> in what is supposed to be a collaborative / concensus / democratic
>> approach.  Also difficult to disentangle the degree to which this is
>> intentionally or unintentionally an unprofessional attempt to elicit
>> praise, with the expected reactions of "oh no, don't leave, you're too
>> valuable".  To me, this is toxic behavior and I would welcome their
>> self-removal from the community if this is their idea of how to conduct
>> themselves in an exemplary manner.
>>
>
> Such behaviour is indeed bad, but did anyone actually post such an
> ultimatum?

Almost half of of the proposal is concerned with that.

## Enforcement Guidelines

Community leaders will follow these Community Impact Guidelines in
determining the consequences for any action they deem in violation of this
Code of Conduct:

### 1. Correction

**Community Impact**: Use of inappropriate language or other behavior deemed
unprofessional or unwelcome in the community.

**Consequence**: A private, written warning from community leaders, providing
clarity around the nature of the violation and an explanation of why the
behavior was inappropriate. A public apology may be requested.

### 2. Warning

**Community Impact**: A violation through a single incident or series of
actions.

**Consequence**: A warning with consequences for continued behavior. No
interaction with the people involved, including unsolicited interaction with
those enforcing the Code of Conduct, for a specified period of time. This
includes avoiding interactions in community spaces as well as external
channels like social media. Violating these terms may lead to a temporary or
permanent ban.

### 3. Temporary Ban

**Community Impact**: A serious violation of community standards, including
sustained inappropriate behavior.

**Consequence**: A temporary ban from any sort of interaction or public
communication with the community for a specified period of time. No public
or private interaction with the people involved, including unsolicited
interaction with those enforcing the Code of Conduct, is allowed during this
period. Violating these terms may lead to a permanent ban.

### 4. Permanent Ban

**Community Impact**: Demonstrating a pattern of violation of community
standards, including sustained inappropriate behavior,  harassment of an
individual, or aggression toward or disparagement of classes of individuals.

**Consequence**: A permanent ban from any sort of public interaction within
the community.

-- 
David Kastrup
My replies have a tendency to cause friction.  To help mitigating
damage, feel free to forward problematic posts to me adding a subject
like "timeout 1d" (for a suggested timeout of 1 day) or "offensive".

Re: Add Code of Conduct

[David Kastrup]

David Kastrup  writes:

> Janek Warchoł  writes:
>
>> Elaine,
>>
>> pt., 7 lut 2020 o 02:28 Flaming Hakama by Elaine 
>> napisał(a):
>>
>>> 1) "Adopt this CoC or I will leave the community"  Such threats amount to a
>>> my-way-or-the-highway attitude, which is an attempt to enforce veto power
>>> in what is supposed to be a collaborative / concensus / democratic
>>> approach.  Also difficult to disentangle the degree to which this is
>>> intentionally or unintentionally an unprofessional attempt to elicit
>>> praise, with the expected reactions of "oh no, don't leave, you're too
>>> valuable".  To me, this is toxic behavior and I would welcome their
>>> self-removal from the community if this is their idea of how to conduct
>>> themselves in an exemplary manner.
>>>
>>
>> Such behaviour is indeed bad, but did anyone actually post such an
>> ultimatum?
>
> Almost half of of the proposal is concerned with that.

I should really read twice what I am replying to.  Sorry, my reply was
not matching the question.

-- 
David Kastrup
My replies have a tendency to cause friction.  To help mitigating
damage, feel free to forward problematic posts to me adding a subject
like "timeout 1d" (for a suggested timeout of 1 day) or "offensive".

Re: Add Code of Conduct

[Janek Warchoł]

+1 to everything Harm said, and big thanks to Werner! (and Urs, who
co-organized Salzburg event)

Janek

sob., 8 lut 2020 o 16:52 Thomas Morley 
napisał(a):

> Am Sa., 8. Feb. 2020 um 14:59 Uhr schrieb Kieren MacMillan
> :
>
> > To me, the greatest shame is that all the positive energy and momentum
> coming out of the Salzburg conference is, it seems, in real danger of being
> shut down by toxic energy of the same kind that has led to the community
> attrition over the last 5-7 years.
> >
> > Just an observation from someone who’s been here since 2003, and watched
> this movie before.
>
> Hi Kieren,
>
> I'd like to fully agree to your statement about the positive energy,
> etc out of the Salzburg conference.
> It was a great event and great to meet so many people and great to
> (I'll stop continuing the list ...).
> Again a big, big THANK YOU to Werner and all who made it possible!!
>
> We discussed many plans, among them (without claim of completeness)
> - developer-tools (move to GitHub or similar)
> - implement stuff from openlilylib
> - CoC
> - finally migrate to guile-2
> - ...
>
> Though, those were plans, sometimes more declarations of intents.
> Ofcourse there was not the time to discuss the details.
> Home again, and making those plans public, not only more people got
> involved (with probably different opinions), but one had a better
> opportunity to think over the details.
> Thus I think it's natural, thoughts will diverge even more than
> already noticed in Salzburg.
>
> Let me pick a not so heated discussed point: developer-tools and share
> my own thoughts:
> While I still object going for GitHub, I changed my mind wrt to other
> tools.
> I reflected some of my reservations, coming from simply lazyness: I
> had to do hard work to get to grips with the current reviewing-setup.
> Thus I feared the need to do it again. Nowadays I think, it may be
> better to move away from Rietveld/sourceforge.
>
> On other plans even more objections may happen, see James' thoughts
> about the CoC.
>
> Again, I think it's natural to observe a broader, more diverging
> amount of opinions.
>
> We need to deal with this, without starting a flame-war, going toxic
> or whatever, but in a civil way.
>
> Not going into details of the CoC-discussion, why not handle it as what it
> is:
> It's a patch. Review showed there are too many objections. Thus it
> should be set to 'needs work' or 'waiting'.
> Otoh, there are suggestions to replace this proposal. Why not focus on
> those proposals?
>
>
>
> For me it's more a shame we are distracted by such discussions from
> doing our work.
> Although my time is very limited during the usual workingweek, I'd
> love to do more on the guile-v2-thingy or at least doing tests for the
> already done work, etc. Instead I write this mail (okay, a 'make
> test-baseline' runs in the background) or read through very long
> threads
>
> Cheers,
>   Harm
>
> P.S. that 'make test-baseline' failed, I'll need to investigate after
> sending this.
>
>

Re: Add Code of Conduct

[Janek Warchoł]

niedz., 9 lut 2020 o 00:39 David Kastrup  napisał(a):

> David Kastrup  writes:
>
> > Janek Warchoł  writes:
> >
> >> Elaine,
> >>
> >> pt., 7 lut 2020 o 02:28 Flaming Hakama by Elaine <
> ela...@flaminghakama.com>
> >> napisał(a):
> >>
> >>> 1) "Adopt this CoC or I will leave the community"  Such threats amount
> to a
> >>> my-way-or-the-highway attitude, which is an attempt to enforce veto
> power
> >>> in what is supposed to be a collaborative / concensus / democratic
> >>> approach.  Also difficult to disentangle the degree to which this is
> >>> intentionally or unintentionally an unprofessional attempt to elicit
> >>> praise, with the expected reactions of "oh no, don't leave, you're too
> >>> valuable".  To me, this is toxic behavior and I would welcome their
> >>> self-removal from the community if this is their idea of how to conduct
> >>> themselves in an exemplary manner.
> >>>
> >>
> >> Such behaviour is indeed bad, but did anyone actually post such an
> >> ultimatum?
> >
> > Almost half of of the proposal is concerned with that.
>
> I should really read twice what I am replying to.  Sorry, my reply was
> not matching the question.
>

It's okay, I was going to ask for clarification :-)

Re: Add Code of Conduct

[David Kastrup]

Thomas Morley  writes:

> Am Sa., 8. Feb. 2020 um 14:59 Uhr schrieb Kieren MacMillan
> :
>
>> To me, the greatest shame is that all the positive energy and
>> momentum coming out of the Salzburg conference is, it seems, in real
>> danger of being shut down by toxic energy of the same kind that has
>> led to the community attrition over the last 5-7 years.
>>
>> Just an observation from someone who’s been here since 2003, and
>> watched this movie before.
>
> Hi Kieren,
>
> I'd like to fully agree to your statement about the positive energy,
> etc out of the Salzburg conference.
> It was a great event and great to meet so many people and great to
> (I'll stop continuing the list ...).
> Again a big, big THANK YOU to Werner and all who made it possible!!
>
> We discussed many plans, among them (without claim of completeness)
> - developer-tools (move to GitHub or similar)
> - implement stuff from openlilylib
> - CoC
> - finally migrate to guile-2
> - ...

Did we discuss a Code of Conduct?  I might have brought this upon myself
with my "clever" talk title about "Conduct of Code" as an antithesis to
a "Code of Conduct" focused approach of making people get along with
each other.  I actually just received a rejection of a "Conduct of Code"
talk at the Chemnitzer Linuxtage since the organisers thought that
projects "LaTeX", "Emacs" and "LilyPond" were not really suitable as
projects showcasing a "Code of Conduct".  Which was sort of the point.
Nobody reads abstracts anymore.

So maybe I'm responsible for bringing up the idea in the first place
because of being too confusing in my choice of title, and people just
thought "David sure forgets what he promised to be talking about".

-- 
David Kastrup
My replies have a tendency to cause friction.  To help mitigating
damage, feel free to forward problematic posts to me adding a subject
like "timeout 1d" (for a suggested timeout of 1 day) or "offensive".

Re: Add Code of Conduct

[Janek Warchoł]

James,

first, I am sorry that you are so disturbed. I realize that this is
partially my fault, so I apologize.

sob., 8 lut 2020 o 09:23 James Lowe  napisał(a):

> On 07/02/2020 09:50, Han-Wen Nienhuys wrote:
> > Thanks for your careful observations.
> >
> > First, the CoC was actually coined by Mike, and I saw it as a proposal to
> > bring LilyPond into the next decade.
>
> What is that even supposed to mean? Again empty, ]words that sound
> 'nice' but mean nothing.
>
> > A CoC is a pretty normal concept these
> > days.
>
> Here we go ... ".. everyone else does it... so we should .. " still with
> no point to any of it that I can see.
>
> > If having a CoC is required to be taken seriously by developers at
> > large, we should consider it.
>
> And for those of us who don't take them seriously and see them as an
> attempt at behavioral control by certain people for certain people.
>
> > I concede that CoCs haven't yet reached this
> > level of ubiquity, though.
>
> Probably for good reason.
>
> > For full disclosure, David has ticked me off in the past, and
> reacquainting
> > myself with the community means that I have to reacquaint myself with
> > David's way of communicating.
>
> Can we just stop bashing David?
>
> > One of the recent emails (about the
> > development process), contained a passage that felt like a blow in my
> > stomach and upset me to the point of considering to leave again. (When I
> > say this, I am not asking for adulation). If that happens to me, imagine
> > what happens when a new contributor is on the receiving end of that. So I
> > am happy to see that David is trying new ways to address this problem.
>
> All without having at CoC.
>
> > I have no personal stake in being a CoC committee member, and was
> actually
> > volunteered into it by Janek. I am happy to not be part of such a
> committee
> > (Elaine, would you be interested?), because my time is limited, and is
> > probably best spent in mentoring coders and explaining the code base. For
> > the record, I think Werner is an excellent candidate.
>
> If we're doing a 'for the record', then just let me state here if/when
> we have a CoC, I will be leaving the LP project , so I guess you better
> start getting all your automation ducks in a row for patch testing and
> shepherding etc, or someone else will need to step in do what I
> currently do.
>
> What a shame.
>

I initially wanted to write "If I were Han-Wen...", but then realized it's
a bad idea. I'll let Han-Wen speak for himself; however, please let me
express my emotions.

I am very saddened by this message. I see a member of the community whose
frustration didn't meet with understanding, but rather with something that
looks like mocking or sarcasm.

As I see it, Han-Wen expressed his emotions. He didn't do it in an
aggressive way; I wouldn't say that he bashed David, either. (David, please
correct me if you felt bashed by Han-Wen's message.) Han-Wen's point was to
empathize with new contributors, and he actually praised David for the
changes he's making.

Han-Wen, I am very sorry that what you wrote didn't meet with empathy or at
least understanding. I imagine you may be very frustrated.

Janek

Re: Add Code of Conduct [Another RFC or not now?]

[Janek Warchoł]

Graham,

sob., 8 lut 2020 o 21:23 Graham Percival 
napisał(a):

> I don't have any reasons that haven't been mentioned already,
> other than one meta-reason: proposals like this are very divisive.
> Trying to have this discussion in the middle of a "final sprint
> towards 2.20" was unfortunate.
>

True. A big mistake on my part.

David,

sob., 8 lut 2020 o 23:41 David Kastrup  napisał(a):

> Graham Percival  writes:
> > I speak from experience on that last point: after the 2012
> > developer meeting at David's ranch (I think that was the year),
> > I was all fired up and started a round of divisive discussions
> > (I think it was the "grand lilypond input syntax standardization").
>
> GLISS was not a new project: it had been ongoing from before my
> involvement.  A bit of a problem was that it had been going on for a
> while without sensible feedback from those who had a good grasp of the
> existing parser/lexer implementation of the input language of LilyPond,
> and that input language had a lot of ad-hoc elements.
>
> > Within 2-3 weeks, I had squandered all of the good feelings and energy
> > sparked from that meeting.  I view that as my worst blunder from all
> > my years of involvement with LilyPond.
>
> Hey, I had chalked this up to my slate.  In retrospect, I saw LilyPond
> in need to grow roots and you saw it in need to grow wings.  And we were
> both excited about its new momentum.  You saw new potential but I am a
> lousy follower: I am unable to follow through with anything that I don't
> see as the best course.  Heck, I am not even good at following through
> with stuff I do see as the best course.
>
> You've clearly been the much better organiser and motivator: the people
> who still keep the "shop running" are doing so in processes originally
> set up by you and given meaning by you.  And I am basically drawing
> blanks when thinking about how to make people pick up the slack when
> someone ultimately leaves.
>
> I still think we should have been able to make this work better between
> us but have no idea how.  And that's bad because LilyPond needs to
> become better at making its community members count, and core
> programmers can only do so much of the heavy lifting even when they are
> all in agreement.
>

Thank you for these words, I find them inspiring!

Janek

Re: ’Pond Jobs & Their Descriptions

[Janek Warchoł]

Kieren,

I see that I've misunderstood you - I apologize. My LP time today is over,
so I'll follow on this topic on the next occasion :)

sob., 8 lut 2020 o 23:31 Kieren MacMillan 
napisał(a):

> Hi Janek,
>
> > I appreciate the initiative, and I agree that we could use a clearer
> view on the responsibilities and skills needed in the community. However, I
> am pretty sure that creating a detailed list is not an effective way of
> solving this problem. I'm pretty sure that we'd spend a *lot* of time on
> discussion and even if we agree on the results, it'll be even more work to
> implement the processes
>
> What processes? I never suggested any processes be developed or
> implemented.
>
> > and until it's ready there would be no tangible benefits
>
> I don’t see that as a necessary condition of what I’m suggesting.
>
> > Do you know about agile methodologies?
>
> Yes. And in fact I’m trying to use them.  :)
>
> > start with setting a small self-contained goal, complete it (with only
> basic planning), and when you're done you take step back to include what
> you've learned in the process.
>
> That’s exactly what I’m doing.
>
> > I suggest to ask this question: what are the 3 areas where LP community
> is most "shortstaffed"?
>
> I’m curious how you’re going to answer that question without actually
> knowing what the areas of the LP community are.
>
> > Once we discover that, I would go on asking "what's the one thing that
> would make it easier/more attractive to contribute in that area". Boom, 2
> weeks later we actually have some specific improvements.
>
> Well, nothing is stopping you from doing that in parallel to my [personal]
> effort.
>
> > I'm willing to mentor, as I've committed to improving LP contributor
> experience
>
> Just an FYI: I’m not going to even bother trying to set up any
> repositories or LilyDev or anything development-related until the
> contributor experience and toolchain is settled on. So the sooner you get
> that done, the sooner you can mentor me in whatever the new processes and
> toolchains are.
>
> Regards,
> Kieren.
> 
>
> Kieren MacMillan, composer (he/him/his)
> ‣ website: www.kierenmacmillan.info
> ‣ email: i...@kierenmacmillan.info
>
>

Re: Add Code of Conduct (issue 575620043 by janek.lilyp...@gmail.com)

[Janek Warchoł]

niedz., 9 lut 2020 o 00:31  napisał(a):

> On 2020/02/08 22:57:13, janek wrote:
> > Because of significant disagreement, and to ensure that LilyPond
> contributors
> > don't feel pushed, I am hereby officially withdrawing this proposal. I
> apologize
> > for the disturbance caused by the way I have introduced this.
> >
> > Maybe I'll submit a revised proposal, but if I do, I'll definitely
> start with a
> > discussion on the mailing list first.
>
> I should apologize for my reaction here.  I need to learn to express "I
> don't see how I could do the part required by me to make this work" in a
> manner distinguishable from a preventive strike.  A skill that could
> have helped in a few situations.
>

Thank you, David, for this message. I appreciate it a lot!
"Apologize" is a magic word indeed; most of my irritation vanished after
reading your message and I feel we're part of the team again :-)

all the best,
Janek

Re: Add Code of Conduct (issue 575620043 by janek.lilyp...@gmail.com)

[dak]

On 2020/02/08 22:57:13, janek wrote:
> Because of significant disagreement, and to ensure that LilyPond
contributors
> don't feel pushed, I am hereby officially withdrawing this proposal. I
apologize
> for the disturbance caused by the way I have introduced this.
> 
> Maybe I'll submit a revised proposal, but if I do, I'll definitely
start with a
> discussion on the mailing list first.

I should apologize for my reaction here.  I need to learn to express "I
don't see how I could do the part required by me to make this work" in a
manner distinguishable from a preventive strike.  A skill that could
have helped in a few situations.

https://codereview.appspot.com/575620043/

Re: Add Code of Conduct (issue 575620043 by janek.lilyp...@gmail.com)

[janek . lilypond]

Because of significant disagreement, and to ensure that LilyPond
contributors don't feel pushed, I am hereby officially withdrawing this
proposal. I apologize for the disturbance caused by the way I have
introduced this.

Maybe I'll submit a revised proposal, but if I do, I'll definitely start
with a discussion on the mailing list first.

https://codereview.appspot.com/575620043/

Re: Grow heap aggressively during music interpretation (issue 561390043 by hanw...@gmail.com)

[nine . fierce . ballads]

https://codereview.appspot.com/561390043/diff/567180043/lily/include/smobs.hh
File lily/include/smobs.hh (right):

https://codereview.appspot.com/561390043/diff/567180043/lily/include/smobs.hh#newcode312
lily/include/smobs.hh:312: static size_t count;
It seems that this is initialized to zero because it is static, but if
it simply had an "= 0", I wouldn't have had to go refresh my memory with
a web search.

Is it correct that there are no static Smobs anywhere in the program? 
If there were, it would be responsible to spend some time checking
whether this could be affected by the "static initialization order
fiasco."  (Maybe you already have.)

https://codereview.appspot.com/561390043/

Re: Add Code of Conduct [Another RFC or not now?]

[Graham Percival]

On Sat, Feb 08, 2020 at 11:41:11PM +0100, David Kastrup wrote:
> Graham Percival  writes:
> > Within 2-3 weeks, I had squandered all of the good feelings and energy
> > sparked from that meeting.  I view that as my worst blunder from all
> > my years of involvement with LilyPond.
> 
> Hey, I had chalked this up to my slate.

Oh my goodness, I sincerely hope not!  I've always had very high
regard for your programming ability and diligence, and I can't
recall taking offense at any "harsh truths" that you threw my way.
(I was sometimes disappointed that they *were* true, but I never
blamed the messenger!)

No, there were a lot of other things happening in my life at the
end of 2012:

- I had finished writing my PhD dissertation, and I always viewed
  "completing a degree" as a chance to take stock of my life.
  I started the grand documentation project in 2007, 1 year before
  finishing my Masters', with the explicit goal of training my
  replacements so that I could quit in good conscience.  That new
  project was an attempt at another big project as I left lilypond
  again.

- I knew that my first postdoc job was at a university which had
  the "charming" idea of laying claim to all the intellectual
  property that I created, so I would be legally unable to
  contribute to lilypond.  (At least, not able to contribute code.
  Given that my main contribution at the time was emails and
  organization, I could have completed a bit, but it might have
  been awkward.)

- I knew that my publication record was not stellar, and no amount
  of time spent on lilypond would lead to a publication (of the
  type that mattered in my branch of academia, i.e. a "tier 1"
  IEEE or ACM journal).

- it had been almost ten years since I'd actually composed any
  music, so I was increasingly wondering why I was spending 10-15
  hours a week on LilyPond.

> In retrospect, I saw LilyPond in need to grow roots and you saw
> it in need to grow wings.

Yeah, that was another big mistake on my part.  In almost every
other instance of "hopeful wings" from 2009 to 2012, I'd argued in
favour of stability and keeping things moving (albeit slowly),
instead of taking risks.

> You've clearly been the much better organiser and motivator: the people
> who still keep the "shop running" are doing so in processes originally
> set up by you and given meaning by you.

Yes -- that's the "stability" part that I'm good at.

> And I am basically drawing blanks when thinking about how to
> make people pick up the slack when someone ultimately leaves.

My dream was always to have a "volunteer funnel".  For
non-programmers, find people willing to reliably do small tasks,
such as LSR, bug reports, translations, and documentation edits.
Then, after a few months of that, encourage them to move on to
more complicated tasks.

The tricky thing is:
- you need to expect at least 50% of people to flake out.  It's
  not because they're bad people, it's not because the lilypond
  community are bad people... that's just the nature of volunteer
  organizations.  I see it offline, too.  People understimate
  the difficulty of tasks, overestimate their time & energy, and
  underestimate the possibilty of other demands on their time
  (jobs, families, hobbies, etc).
- so the person organizing the volunteers (or ideally, the
  volunteers in a specific area such as bugs) needs to constantly
  be recruiting.  Well, not necessarily *constantly*, but if you
  ever think "ok, we've got all 7 days of bug reporters handled so
  I can relax", that's a danger sign.  If they're working well,
  then encourage 1 or 2 to move to a different task, and recruit
  new volunteers to fill the gaps.
- equally important, the "volunteer wrangler" needs to be
  emotionally prepared to see a lot of effort walk out the door
  when volunteers realize that they can't continue.

> I still think we should have been able to make this work better between
> us but have no idea how.

No, there was no fault on your side.  And to be fair to myself, it
wasn't really a "fault" on my side -- it was definitely time for
me to move on.  I should have handled it more gracefully (so yes,
I blame myself for that).  But there was nobody to blame for my
leaving the project; if anything, I should have left a year or two
earlier.  It was simply not a good fit with my life at the time.

Cheers,
- Graham