Re: How to report `FontForge` problems while creating LilyPond fonts

[Torsten Hämmerle]

Sorry, my "turn" was a goof:  The loop in the outline produced a tiny
fissure…

Now I've put a bit more effort in it, combining two subpaths at their
intersection so that metapost's output will be a plain and simple outline,
/exactly/ matching the original turn outline, but without any loops or
overlaps:

 

Cheers,
Torsten

example-turn-v2.png
  



--
Sent from: http://lilypond.1069038.n5.nabble.com/Dev-f88644.html

Our language downloads are chaotic.

[David Kastrup]

For example, try downloading any French documentation from
 if
your browser locale is not French.  Possibly even if it is.

I am currently setting up the size listings to correspond with the
actual files linked there, but the actual files apparently are incorrect
all too often.

I've not yet discovered a coherent strategy in the various translations
how they attempt to, by and large, get a hold of downloads in their own
language.

The download details pages are where the sizes are currently given (the
others are without size currently as far as I can tell: it should not be
too much work to reorganise size indications once I am finished, to get
more of them).

-- 
David Kastrup

Re: How to report `FontForge` problems while creating LilyPond fonts

[Torsten Hämmerle]

Werner LEMBERG wrote
> The output produced by the `mf2pt1` script to convert METAFONT input files
> to Type1 PostScript fonts often contains overlapping glyphs.  This should
> be
> avoided in general.[1]  For this reason, `mf2pt1` by default calls
> `FontForge` in batch mode to remove overlaps.

Hello Werner,

Unfortunately, mf overlaps can hardly be avoided in many cases, because lots
of glyphs are being composed out of several overlapping predefined
components.
clefs.GG, for instance, consists of two overlapping clefs.G.
So I'm afraid we cannot save FontForge from dealing with overlaps in
general.

But, being harried by all the error messages currently produced (and
intrigued by your report), I've had a look at the specific errors and found
a way to solve all the issues without actually changing the final result
(well, except for an unnoticeable change to the TAB clef invisible to the
human eye).

I agree that FontForge should be able to cope with theses cases, but, as it
doesn't seem to be easy to solve, It'd probably be a good idea to change our
mf files in such a way that they can be processed without lamenting even
using the current FontForge release.

Just to start off with the "turn" example in *feta-scripts.mf*:
The turn glyphs consist of a rather fancy implementation of the S-shape with
and overlay of "ploop" at both ends.  The meet in mf control point 4l with
an "infinitesimal" deviation of slope.
I could circumvent this by junking the "ploop", just inserting two points
(5l and 6l) into the S-shape path.
Now we have replaced the overlapping objects by a self-intersecting path,
but FontForge does not complain anymore, but yielding the exact same result.

Picking up a pencircle and switching mf from "fill" to "draw" for seeing
what mf actually does, we get:

 

I absolutely dislike corners without a clearly defined intersection point,
but that's the way the glyph has been designed and changing this may
slightly change the resulting outline.

That's just one of many similar cases.

*feta-arrowheads.mf*
The arrowhead glyph can be cured by making one single path out of the two
superimposed components.

*feta-clefs.mf*
The G clef and all its derivatives can be immunized by inserting one
auxiliary point within the intersection area.
The (handwriting) TAB clef has a problem joining the two curvy strokes in
the B and just changing the starting angle of one of the parts by, say, 1
degree, will help. Unnoticeable change (and, after all, it's a "handwritten"
B).


*feta-timesignatures.mf*,
lastly, the common time glyph C can be processed flawlessly when shifting
the direction instruction in z2r from one side to the other. This is only
possible when replacing a straight connection by a rounded one within the
overlapping area.

All in all *minimal changes* that *do not affect the resulting mf outline*
at all but help FontForge to better handle the font conversion without any
complaints..

What do you think? Should I prepare a patch?

Regards,
Torsten

example-turn.png
  



--
Sent from: http://lilypond.1069038.n5.nabble.com/Dev-f88644.html

Re: Issue 5788: New French Beamimg Approach (issue 557500043 by torsten.haemme...@web.de)

[thomasmorley65]

On 2020/02/26 21:56:46, dak wrote:
> On 2020/02/26 21:50:05, lemzwerg wrote:
> > > How about
> > > * beamed-stem-french-adjustment
> > > * french-beaming-stem-adjustment
> > > …? 
> > 
> > I like the second one.
> 
> I'd be fine with it.

+1

https://codereview.appspot.com/557500043/

Re: Forge Software Evaluation by FSF

[David Kastrup]

Han-Wen Nienhuys  writes:

> On Wed, Feb 26, 2020 at 11:06 PM David Kastrup  wrote:
>
>> > There is also a bunch of verbiage about how tracking tags are evil.
>> > (lilypond.org has been running Google Analytics for 15 years or so).
>>
>> Because?
>
> We used it to improve our site layout and understand how people
> discovered LilyPond, so we could improve our marketing.

Some examples?  The problem is that by now tracking everybody has become
a pervasive and lucrative business that, due to data mining, makes it
almost impossible not to be permanently identified with a profile.  That
is a great help for repressive governments among other things.

> It's also useful for tracking downloads.

But for that it is not necessary to know the IP addresses.  And we
likely don't.  But employing Google's services here means that they do.
And Google did retire its "Do no evil" motto a few years ago without
much of a fanfare.

Now in connection with us still using Rietveld and having used Google
Code, this looks like at best a minor problem.  On the other hand, they
tend to work a whole lot less for profiling a wide range of people than
our main website would.

If we contribute to tracking down and jailing Chinese users who looked
at LilyPond for creating protest songs, that would be nothing to be
particularly proud of.

> We recently discussed the PDF manual, and if it makes sense to add the
> download size. If we'd annotate the link, we could easily see how
> often people download the manual, and whether it's worth time
> tinkering with it.

We don't offer downloads just for the PDF notation manual.  And we don't
see how an advertised download size influences download decisions.  If
we want to maximise downloads, we should probably remove all size
indications and have users hit their limits.  I think of the objective
more to provide a courtesy rather than maximize web traffic.

>> > I suggest to focus on the needs of our project, rather than the
>> > edicts of RMS.
>>
>> The FSF is not the "edicts of RMS" and it wasn't reduced to that
>> while he was president, either.  They are to a good degree in the
>> business of caring about details that are easily lost in complacency.
>> There is a value in that.  After all, our whole planet is slated for
>> extinction through complacency by now.
>>
>> So I see no point in not trying to evaluate the feedback they bother
>> to provide.  Whether we are realistically in a position to make our
>> project adopt it is a different question, but I see no point in
>> ignoring it.
>
> I am worried that having too many criteria will get us stuck in
> analysis-paralysis, which would leave in the state where we are
> currently, because we can't make up our minds.

We are currently in my book focusing on getting the current releases
out.  There is no point in switching while this is not finished since we
want to be able to deal with the release fallout without adding more
workload for the constant volunteers keeping our things running.  I am
grateful for a few people preevaluating our options: that gives us more
of a plan of what to try out in more seriousness once the time for doing
that is right.  There is still a large amount of catchup going on with
the translations group, with Italian and Spanish translations rushing to
the finishing line where they can be called complete.  And moving to
translating unstable will also be a large piece of work.  I don't want
to switch tools from underneath the translators while they are doing
incredibly heavy lifting.

But there is nothing wrong with developers starting to look at options
and see what a more serious evaluation would entail.  That's preparation
for making up our minds.  There will come a time when we want to get
down to a final list of options, and if it is more than one, seriously
evaluate them (including a non-trivial number of people doing business
there and getting a hang of it) and then pick one for longer.

-- 
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: axis-group-interface: avoid some cast warnings (issue 583510045 by hanw...@gmail.com)

[hanwenn]

commit de02798e05dcfb08858f9041bdf2a8297a27f9be
Author: Han-Wen Nienhuys 
Date:   Thu Feb 13 14:44:01 2020 +0100

axis-group-interface: avoid some cast warnings

https://sourceforge.net/p/testlilyissues/issues/5769
http://codereview.appspot.com/583510045



https://codereview.appspot.com/583510045/

Re: Parse inline scheme using per-expression port (issue 557330043 by hanw...@gmail.com)

[hanwenn]

commit 483292eb80da0869d22cd773eb480c662a499e89
Author: Han-Wen Nienhuys 
Date:   Tue Feb 18 09:40:00 2020 +0100

Parse inline scheme using per-expression port



https://codereview.appspot.com/557330043/

Re: Use HTTPS for all search boxes (issue 563570043 by hanw...@gmail.com)

[hanwenn]

commit 99a9a5b304b72910c31593f3b434b4b47874ebbf
Author: Han-Wen Nienhuys 
Date:   Fri Feb 21 16:20:52 2020 +0100

Use HTTPS for all search boxes

https://codereview.appspot.com/563570043/



https://codereview.appspot.com/563570043/

Re: Forge Software Evaluation by FSF

[Han-Wen Nienhuys]

On Wed, Feb 26, 2020 at 11:06 PM David Kastrup  wrote:

> > There is also a bunch of verbiage about how tracking tags are evil.
> > (lilypond.org has been running Google Analytics for 15 years or so).
>
> Because?

We used it to improve our site layout and understand how people
discovered LilyPond, so we could improve our marketing.

It's also useful for tracking downloads. We recently discussed the PDF
manual, and if it makes sense to add the download size. If we'd
annotate the link, we could easily see how often people download the
manual, and whether it's worth time tinkering with it.

> > I suggest to focus on the needs of our project, rather than the edicts
> > of RMS.
>
> The FSF is not the "edicts of RMS" and it wasn't reduced to that while
> he was president, either.  They are to a good degree in the business of
> caring about details that are easily lost in complacency.  There is a
> value in that.  After all, our whole planet is slated for extinction
> through complacency by now.
>
> So I see no point in not trying to evaluate the feedback they bother to
> provide.  Whether we are realistically in a position to make our project
> adopt it is a different question, but I see no point in ignoring it.

I am worried that having too many criteria will get us stuck in
analysis-paralysis, which would leave in the state where we are
currently, because we can't make up our minds.

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

Re: Forge Software Evaluation by FSF

[David Kastrup]

Han-Wen Nienhuys  writes:

> On Tue, Feb 25, 2020 at 11:23 PM Jonas Hahnfeld  wrote:
>>
>> Hi all,
>>
>> I was meaning to write on the next steps of switching to new tooling
>> when I came across this:
>> https://lwn.net/Articles/813254/rss
>> https://www.fsf.org/blogs/sysadmin/coming-soon-a-new-site-for-fully-free-collaboration
>> https://libreplanet.org/wiki/Fsf_2019_forge_evaluation
>>
>> In particular the last page claims with respect to GitLab:
>> "GNU ethical repo criteria: gitlab.com listed as C, but has been
>> operating at an F and will be reclassified soon because it sometimes
>> requires users to run nonfree Google ReCAPTCHA code they have been very
>> slowly working on moving away from for almost 2 years now [...]"
>>
>> What do people think about this? Is that serious enough to stop
>> considering GitLab?
>>
>> Note that Gerrit is not on the list (probably because it's not a
>> complete forge software, ie no issues?), so I can't comment on how it
>> compares with respect to freedom.
>
> Gerrit is open source under the Apache 2 license.  However, this is
> comparing apples and pears. Because gitlab.com is a service provider,
> that runs Gitlab for you.
>
> If we want someone to host our forge (eg. gitlab.com) for free or a
> small fee, that will have to be an entity that needs to scale its user
> support model (or it wouldn't be gratis). This typically means it
> needs something like reCaptcha to heed off spam/abuse, and Tor access
> is probably problematic for the same reason.
>
> This is also why I have a hard time taking the FSF's stance here
> seriously.  Their conditions make it almost impossible to use a
> commercial provider. For example C2 "Does not discriminate against
> classes of users, or against any country" is impossible to satisfy for
> any US company due to export restrictions for countries like North
> Korea and Iran.
>
> There is also a bunch of verbiage about how tracking tags are evil.
> (lilypond.org has been running Google Analytics for 15 years or so).

Because?

> I suggest to focus on the needs of our project, rather than the edicts
> of RMS.

The FSF is not the "edicts of RMS" and it wasn't reduced to that while
he was president, either.  They are to a good degree in the business of
caring about details that are easily lost in complacency.  There is a
value in that.  After all, our whole planet is slated for extinction
through complacency by now.

So I see no point in not trying to evaluate the feedback they bother to
provide.  Whether we are realistically in a position to make our project
adopt it is a different question, but I see no point in ignoring it.

>> Let me see if I can get more information on when they plan to bring
>> the hosting platform online.

It may well be that the recent upheavals have moved that somewhat to the
backburner.  Still good to check, though.

-- 
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: Issue 5788: New French Beamimg Approach (issue 557500043 by torsten.haemme...@web.de)

[dak]

On 2020/02/26 21:50:05, lemzwerg wrote:
> > How about
> > * beamed-stem-french-adjustment
> > * french-beaming-stem-adjustment
> > …? 
> 
> I like the second one.

I'd be fine with it.

https://codereview.appspot.com/557500043/

Re: [GSOC 2020] Discussing GNU Lilypond project ideas?

[Urs Liska]

Am Mittwoch, den 26.02.2020, 15:46 -0600 schrieb Karlin High:
> On 2/26/2020 3:28 PM, Leandro Doctors wrote:
> > Could you please point me in the right direction?
> 
> Thanks for your interest! In the past, Urs Liska has been leading
> GSOC 
> efforts. He's indicated that this list is his preferred way to begin 
> GSOC discussions, so I think you're at the right place.

That's correct, although I'd claim that this is a "natural" solution
and not my preference ;-)

But more importantly I'd like to stress that the GSoC page lists
project *ideas*, and if you're specifically interested in Scheme stuff
you may as well suggest other topics than listed there.

Urs

Re: Forge Software Evaluation by FSF

[Han-Wen Nienhuys]

On Tue, Feb 25, 2020 at 11:23 PM Jonas Hahnfeld  wrote:
>
> Hi all,
>
> I was meaning to write on the next steps of switching to new tooling
> when I came across this:
> https://lwn.net/Articles/813254/rss
> https://www.fsf.org/blogs/sysadmin/coming-soon-a-new-site-for-fully-free-collaboration
> https://libreplanet.org/wiki/Fsf_2019_forge_evaluation
>
> In particular the last page claims with respect to GitLab:
> "GNU ethical repo criteria: gitlab.com listed as C, but has been
> operating at an F and will be reclassified soon because it sometimes
> requires users to run nonfree Google ReCAPTCHA code they have been very
> slowly working on moving away from for almost 2 years now [...]"
>
> What do people think about this? Is that serious enough to stop
> considering GitLab?
>
> Note that Gerrit is not on the list (probably because it's not a
> complete forge software, ie no issues?), so I can't comment on how it
> compares with respect to freedom.

Gerrit is open source under the Apache 2 license.  However, this is
comparing apples and pears. Because gitlab.com is a service provider,
that runs Gitlab for you.

If we want someone to host our forge (eg. gitlab.com) for free or a
small fee, that will have to be an entity that needs to scale its user
support model (or it wouldn't be gratis). This typically means it
needs something like reCaptcha to heed off spam/abuse, and Tor access
is probably problematic for the same reason.

This is also why I have a hard time taking the FSF's stance here
seriously.  Their conditions make it almost impossible to use a
commercial provider. For example C2 "Does not discriminate against
classes of users, or against any country" is impossible to satisfy for
any US company due to export restrictions for countries like North
Korea and Iran.

There is also a bunch of verbiage about how tracking tags are evil.
(lilypond.org has been running Google Analytics for 15 years or so).

I suggest to focus on the needs of our project, rather than the edicts of RMS.

> Let me see if I can get more information on when they plan to bring the
> hosting platform online.

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

Re: Issue 5788: New French Beamimg Approach (issue 557500043 by torsten.haemme...@web.de)

[lemzwerg--- via Discussions on LilyPond development]

> How about
> * beamed-stem-french-adjustment
> * french-beaming-stem-adjustment
> …? 

I like the second one.


https://codereview.appspot.com/557500043/

Re: [GSOC 2020] Discussing GNU Lilypond project ideas?

[Karlin High]

On 2/26/2020 3:28 PM, Leandro Doctors wrote:

Could you please point me in the right direction?


Thanks for your interest! In the past, Urs Liska has been leading GSOC 
efforts. He's indicated that this list is his preferred way to begin 
GSOC discussions, so I think you're at the right place.

--
Karlin High
Missouri, USA

Re: Issue 5788: New French Beamimg Approach (issue 557500043 by torsten.haemme...@web.de)

[torsten . haemmerle]

> I'll really make myself unpopular here, […]

No, that's what discussions are for.
I probably shouldn't have uploaded a second patch set before the
property
name had finally been decided upon, but I was kind of urged by the
countdown
starting and didn't have the time for working on it earlier.

The property is a positive value that will be subtracted from the stem's
length.

How about
* beamed-stem-french-adjustment
* french-beaming-stem-adjustment
…? 

> But the main thing is that I'd like its name to contain
"french-beaming" because
> it is not intended to be used for anything else and not guaranteed to
work for
> anything else.

I know it's only internal, but a meaningful and unambiguous property
name would be 
desirable nevertheless.

https://codereview.appspot.com/557500043/

[GSOC 2020] Discussing GNU Lilypond project ideas?

[Leandro Doctors]

Dear all,

My name is Leandro Doctors. I am seriously considering applying to
GSoC 2020 with GNU Lilypond.

I am interested in the Scheme-based ideas. (I have recently
rediscovered LISP, and I am a Clojure fan.) However, I haven't found
any indication on how to proceed the discussion in the Ideas page [1]. Should I
subscribe to 'lilydond-devel' [2]? Or should I do something else?

Could you please point me in the right direction?

Thank you in advance for your reply,
Leandro

[1] http://lilypond.org/google-summer-of-code.html
[2] http://lists.gnu.org/mailman/listinfo/lilypond-devel

PS: HTTPS is *not* used unless specified in the browser. There is no
redirection by default.

Re: Issue 5788: New French Beamimg Approach (issue 557500043 by torsten.haemme...@web.de)

[dak]

https://codereview.appspot.com/557500043/diff/563610046/scm/define-grob-properties.scm
File scm/define-grob-properties.scm (right):

https://codereview.appspot.com/557500043/diff/563610046/scm/define-grob-properties.scm#newcode1374
scm/define-grob-properties.scm:1374: amount of space in case of French
beaming style.")
I'll really make myself unpopular here, so the ones with the original
suggestion implemented here should likely give feedback before anything
is changed again, but:

Now that this is sorted among the _internal_ grob properties for
LilyPond's private use, it seems more appropriate to name it according
to its specific purpose.  My own choice would be
french-beaming-adjustment (if its normal sign is negative which I don't
know) or french-beaming-shortening (if its normal sign is positive). 
I'd have "beaming" in the name because otherwise it could be anything. 
As an internal property, its name does not need to be extra-easy to
type.

Why adjustment instead correction?  Because the default value is not a
badly placed French beaming stem in need of correction.

But the main thing is that I'd like its name to contain "french-beaming"
because it is not intended to be used for anything else and not
guaranteed to work for anything else.

So please: the people arguing for the original name change: just chime
in with "agree", "can find myself able to agree", or "don't agree".

Thanks!

https://codereview.appspot.com/557500043/

Re: Issue 5788: New French Beamimg Approach (issue 557500043 by torsten.haemme...@web.de)

[hanwenn]

On 2020/02/26 21:14:54, Be-3 wrote:
> On 2020/02/26 21:04:59, Be-3 wrote:
> > Changes applied following the reviewers' comments
> 
> All of the recommendations applied:
> 
> Rename stru Beam_stem_length ->  Beam_stem_end (Han-Wen)
> Rename property french-correction -> stem-end-shorten (Han-Wen)
> 
> Make property stem-end-shorten (was: french-correction) internal
(DAK)
> 
> Corrections to doc text (Werner)
> 
> New regression file added directly comparing french beaming to
standard
> beaming (Werner)
> 
> On my behalf:
> Modified changes.tely LilyPond example to show more variations in
less
> space so that it will not stick out into the margin in PDF
version.
> 
> Removed an unneccessary if, just multiplying by int 0 in this
case.
> 
> Full test successfully performed.
> 
> 
> @DAK: Sorry, the french-correction property (now: stem-end-shorten)
was supposed
> to be internal (as you guessed correctly in the end).  But I had
initially put

french-shorten sounds good to me, but you can paint the bike shed in
your favorite color if it is an internal property.



https://codereview.appspot.com/557500043/

Re: Issue 5788: New French Beamimg Approach (issue 557500043 by torsten.haemme...@web.de)

[torsten . haemmerle]

On 2020/02/26 21:04:59, Be-3 wrote:
> Changes applied following the reviewers' comments

All of the recommendations applied:

Rename stru Beam_stem_length ->  Beam_stem_end (Han-Wen)
Rename property french-correction -> stem-end-shorten (Han-Wen)

Make property stem-end-shorten (was: french-correction) internal
(DAK)

Corrections to doc text (Werner)

New regression file added directly comparing french beaming to
standard
beaming (Werner)

On my behalf:
Modified changes.tely LilyPond example to show more variations in
less
space so that it will not stick out into the margin in PDF version.

Removed an unneccessary if, just multiplying by int 0 in this case.

Full test successfully performed.


@DAK: Sorry, the french-correction property (now: stem-end-shorten) was
supposed
to be internal (as you guessed correctly in the end).  But I had
initially put it
in the all-user-grob-properties list in an early testing stage and plain
and
simply forgot to move it over to all-internal-grob-properties in time.

Cheers and thanks for reviewing,
Torsten




https://codereview.appspot.com/557500043/

Re: Remove OMF support (issue 545630044 by hanw...@gmail.com)

[hanwenn]

https://codereview.appspot.com/545630044/diff/579320044/make/ly-rules.make
File make/ly-rules.make (right):

https://codereview.appspot.com/545630044/diff/579320044/make/ly-rules.make#newcode64
make/ly-rules.make:64: $(call ly_progress,Making,$@,< texi)
On 2020/02/25 09:05:17, hahnjo wrote:
> You should delete these lines completely.

Done.

https://codereview.appspot.com/545630044/diff/579320044/stepmake/stepmake/texinfo-rules.make
File stepmake/stepmake/texinfo-rules.make (right):

https://codereview.appspot.com/545630044/diff/579320044/stepmake/stepmake/texinfo-rules.make#newcode124
stepmake/stepmake/texinfo-rules.make:124: $(call ly_progress,Making,$@,<
texi)
On 2020/02/25 09:05:17, hahnjo wrote:
> Remove completely

Done.

https://codereview.appspot.com/545630044/

PATCHES - Countdown for February 26th

[pkx166h]

Hello,

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

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

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

***


 Push:

5782 dump lilypond-book log files in $(outdir) - Han-Wen Nienhuys
https://sourceforge.net/p/testlilyissues/issues/5782
http://codereview.appspot.com/555330043

5779 SVG: Permit 'e' to appear in SVG font glyph paths - Jonas Hahnfeld
https://sourceforge.net/p/testlilyissues/issues/5779
http://codereview.appspot.com/561460044

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


 Countdown:

5792 .dir-locals.el: spell out nil settings - David Kastrup
https://sourceforge.net/p/testlilyissues/issues/5792
http://codereview.appspot.com/545640044

5790 Rational conversion clean-up - Dan Eble
https://sourceforge.net/p/testlilyissues/issues/5790
http://codereview.appspot.com/573570043

5789 Cleanup lilypond-book source - Han-Wen Nienhuys
https://sourceforge.net/p/testlilyissues/issues/5789
http://codereview.appspot.com/583570043

5788 New French Beamimg Approach - Torsten Hammerle
https://sourceforge.net/p/testlilyissues/issues/5788
http://codereview.appspot.com/557500043

5784 Avoid interaction in tex invocations - Han-Wen Nienhuys
https://sourceforge.net/p/testlilyissues/issues/5784
http://codereview.appspot.com/545620043


 Review:

5797 Do not run GC after processing every file. - Han-Wen Nienhuys
https://sourceforge.net/p/testlilyissues/issues/5797
http://codereview.appspot.com/579330043

5795 NR: Improve color table layout. - Werner LEMBERG
https://sourceforge.net/p/testlilyissues/issues/5795
http://codereview.appspot.com/557520043

5794 Remove outdated compiler checks in configure - Jonas Hahnfeld
https://sourceforge.net/p/testlilyissues/issues/5794
http://codereview.appspot.com/551510043

5793 Replace file-cookie and memory-stream - Jonas Hahnfeld
https://sourceforge.net/p/testlilyissues/issues/5793
http://codereview.appspot.com/581700043

5787 Add a cooperative FS lock to lilypond-book. - Han-Wen Nienhuys
https://sourceforge.net/p/testlilyissues/issues/5787
http://codereview.appspot.com/555360043

5777 Let flex handle the input stack - Jonas Hahnfeld
https://sourceforge.net/p/testlilyissues/issues/5777
http://codereview.appspot.com/563560043


 New:

No new patches at this time.


 Waiting:

5771 remove unnecessary (descend-to-context ... 'Score) - Dan Eble
https://sourceforge.net/p/testlilyissues/issues/5771
http://codereview.appspot.com/557440043

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


***



Regards,

James

Re: converting tabs to spaces in .mf files

[Werner LEMBERG]

>> What do you think about converting all tabs in the .mf files to
>> spaces?
> 
> I consider this a good idea.  [...]

OK, so I will do this within the next couple of days.


Werner

Re: run-and-check: close stdin (issue 545620043 by hanw...@gmail.com)

[zhtw1234]

On 2020/02/23 19:05:02, hanwenn wrote:
> 在2020/02/23
06：28：27，lemzwerg寫道：
> >>這裡正確的解決方法當然不是關閉stdin
> >>而是使用以下命令運行pdflatex
> >>
> >-交互批處理模式
> >>
> >>（在運行期間，它不會在輸出中顯示任何內容，
> >>因此，如果出現以下情況，您需要查閱日誌文件
> >>問題）或
> >>
> >-互動不間斷模式
> >>
> >>從不停止輸入。
> > 
> >聽起來很明智。韓文你可以試試嗎
> 
> Done
去死

https://codereview.appspot.com/545620043/

Re: run-and-check: close stdin (issue 545620043 by hanw...@gmail.com)

[zhtw1234]

On 2020/02/22 23:22:43, dak wrote:
> 在2020/02/22
22:08:33上，hanwenn寫道：
> >在2020/02/22 22:01:10，lemzwerg寫道：
> >>以前從未見過這樣的代碼，但是如果它解決了問題... :-)
> > 
> >這是互聯網上的剪切和粘貼，
> >
https://blog.apokalyptik.com/2007/10/24/bash-tip-closing-file-descriptors/
> > 
> >我很驚訝在控制台stdin上將make傳遞給子進程，但是它
> >確實發生了。
> 
>
最肯定的是標准文件描述符，適用於子級。正確的解決方法https://codereview.appspot.com/545620043/

Re: run-and-check: close stdin (issue 545620043 by hanw...@gmail.com)

[zhtw1234]

妓女

https://codereview.appspot.com/545620043/

Re: run-and-check: close stdin (issue 545620043 by hanw...@gmail.com)

[zhtw1234]

On 2020/02/22 23:22:43, dak wrote:
> 在2020/02/22
22:08:33上，hanwenn寫道：
> >在2020/02/22 22:01:10，lemzwerg寫道：
> >>以前從未見過這樣的代碼，但是如果它解決了問題... :-)
> > 
> >這是互聯網上的剪切和粘貼，
> >
https://blog.apokalyptik.com/2007/10/24/bash-tip-closing-file-descriptors/
> > 
> >我很驚訝在控制台stdin上將make傳遞給子進程，但是它
> >確實發生了。https://codereview.appspot.com/545620043/

Re: run-and-check: close stdin (issue 545620043 by hanw...@gmail.com)

[zhtw1234]

On 哭爸

https://codereview.appspot.com/545620043/

Re: run-and-check: close stdin (issue 545620043 by hanw...@gmail.com)

[zhtw1234]

臭雞歪

https://codereview.appspot.com/545620043/

Re: run-and-check: close stdin (issue 545620043 by hanw...@gmail.com)

[zhtw1234]

幹你娘，全家死光

https://codereview.appspot.com/545620043/

Re: Forge Software Evaluation by FSF

[Jonas Hahnfeld]

Am Dienstag, den 25.02.2020, 23:38 +0100 schrieb David Kastrup:
> Jonas Hahnfeld <
> hah...@hahnjo.de
> > writes:
> 
> > Hi all,
> > 
> > I was meaning to write on the next steps of switching to new tooling
> > when I came across this:
> > https://lwn.net/Articles/813254/rss
> > 
> > https://www.fsf.org/blogs/sysadmin/coming-soon-a-new-site-for-fully-free-collaboration
> > 
> > https://libreplanet.org/wiki/Fsf_2019_forge_evaluation
> > 
> > 
> > In particular the last page claims with respect to GitLab:
> > "GNU ethical repo criteria: gitlab.com listed as C, but has been
> > operating at an F and will be reclassified soon because it sometimes
> > requires users to run nonfree Google ReCAPTCHA code they have been very
> > slowly working on moving away from for almost 2 years now [...]"
> > 
> > What do people think about this? Is that serious enough to stop
> > considering GitLab?
> > 
> > Note that Gerrit is not on the list (probably because it's not a
> > complete forge software, ie no issues?), so I can't comment on how it
> > compares with respect to freedom.
> > 
> > Let me see if I can get more information on when they plan to bring the
> > hosting platform online.
> 
> We don't have a whole lot of viable alternatives at the moment.  And we
> have the problem that LilyPond is pretty large (even discounting the CI
> thing) for being a well-beloved free-tier customer.
> 
> Being supported by the FSF certainly would solve some worries (not
> likely CI) but they are not exactly bristling in manpower either.
> 
> So it would be interesting in several respects what the FSF is planning
> to do and support, and how viable for a big project what they are
> thinking about could be.
> 
> The FSF has in recent months been hit heavily by Richard Stallman
> stepping back as president of the FSF and the FSF having to more
> formally redefine their manner of providing support for the GNU project.
> That may have affected the speed with which they are progressing with
> that project.
> 
> At any rate, there is nothing wrong with trying to get more information
> for arriving at a decision, so it would be great for you to figure out
> what the current plans regarding project hosting are.

So I tried, but not very successfully: There have been some posts to
repo-criteria-discuss in January and last October, but not in between.
The mentioned list libreplanet-dev is empty, except for one reaction to
the blog post. Same holds for savannah-hackers-public. Unless I missed
a very obvious place, I'm not sure where the discussions are taking
place...

I also had a look at the evaluated software:
 * For Pagure, there exists an importer script from GitHub and the now
shut down fedorahosted.org. However I can't even get a small project of
mine migrated and there's close to no documentation on this interface.
Looking into the source code hasn't helped either.
 * Gitea also recently got a migration interface. Again only for
GitHub, and it didn't work either when I tried. To make things even
worse, the interface is internal only so you need to write the
migration logic in Go, wait for a release and deploy it to the server.
 * I found no migration of issues to SourceHut, it's probably too new.

All three of them also have APIs that allow to create issues / tickets
/ whatever they name it. However you can't supply the ids, they are
autogenerated.
Long story short: We would not be able to migrate our existing issues
from SF and retain their ids. I consider this a blocker, and I don't
have any hint to believe that this possibility will suddenly appear.

Jonas


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

Re: Forge Software Evaluation by FSF

[Jonas Hahnfeld]

Am Mittwoch, den 26.02.2020, 14:56 +0100 schrieb Werner LEMBERG:
> > I see they reviewed SourceHut, which seems to be actively trying to
> 
> > comply with FSF's repository expectations. I'd come across SourceHut
> 
> > earlier, and its minimalist design and a few other things reminded me
> 
> > a little of LilyPond's culture.
> 
> 
> SourceHut looks very nice!

from https://libreplanet.org/wiki/Fsf_2019_forge_evaluation:
"Upstream claims it is alpha software."

> 
> BTW, here's an FSF blog post from yesterday regarding a 'forge'.
> 
>   
> https://www.fsf.org/blogs/sysadmin/coming-soon-a-new-site-for-fully-free-collaboration

Well yes, that's the link I quoted in my initial message.

Jonas


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

Re: Forge Software Evaluation by FSF

[Werner LEMBERG]

> I see they reviewed SourceHut, which seems to be actively trying to
> comply with FSF's repository expectations. I'd come across SourceHut
> earlier, and its minimalist design and a few other things reminded me
> a little of LilyPond's culture.

SourceHut looks very nice!

BTW, here's an FSF blog post from yesterday regarding a 'forge'.

  
https://www.fsf.org/blogs/sysadmin/coming-soon-a-new-site-for-fully-free-collaboration


Werner

Re: Getting download sizes right: proof of concept

[David Kastrup]

Jean-Charles Malahieude  writes:

> Le 26/02/2020 à 02:18, David Kastrup a écrit :
>> 
>> Anybody want to see what it takes to get this across the finishing line?
>>
>
> Just a nitpick: the sizes are in Documentation/web/manuals.itexi.
> I'll have a look this afternoon.

Oh, I know.  The respective macros would no longer get any sizes as
arguments ultimately.  This is just a sketch for now.  Fixing the macros
and their invocations will be easy to do.  Also polishing the script.
The important thing is to get script called at a late point in building
the HTML where the files we want to have measured for size are all in
place.

-- 
David Kastrup

Re: Getting download sizes right: proof of concept

[David Kastrup]

Werner LEMBERG  writes:

>>> I'd need someone to take this sketch and integrate it into the
>>> build system (I just don't really understand the build system).
>> 
>> Do we really need this?
>
> Yes, I think this is *very* useful.  It's always nice to know big file
> sizes (i.e., files larger than, say, 1MByte) in advance.  Not everyone
> is using a fast (and cheap) internet connection.
>
>> We could just delete the download size from text and be correct in a
>> much simpler way.  For today's standards, the difference between 6M
>> and 35M isn't really all that relevant.
>
> I strongly disagree.  It's still a very large difference.

Note that there is the simpler solution of having a script run manually
after build, fixing up the sizes in the source which one can then
commit.

Advantage: a no-brainer to have this work for all outputs including PDF
and Texinfo.

Disadvantage: if the computer where the size recalculations have been
done and committed and the computer building the website have, say,
different fonts installed, the numbers can still be off.  Also if one
has some PDF tools in the build that the other hasn't.

I decided that accurate numbers were desirable enough to have them
recalculated every time.  Putting them into the source (like defining
them in some Makefile) would have required some tricky dependencies,
like not writing them in the large HTML file in order to be able to
first build the large HTML file, then calculate its size, and then have
the size available for building the split HTML file.

So this approach of fixing the files up after the fact.  Which again
changes their size minusculy but we use size here for estimating
download times, not for verifying the downloads as being untampered.  If
we put in md5sums (for example), this fixup would of course not work as
an approach and we could not allow for circular dependencies to be
broken by patchup.

-- 
David Kastrup

Re: Getting download sizes right: proof of concept

[Jean-Charles Malahieude]

Le 26/02/2020 à 02:18, David Kastrup a écrit :



Anybody want to see what it takes to get this across the finishing line?



Just a nitpick: the sizes are in Documentation/web/manuals.itexi.
I'll have a look this afternoon.

Cheers,
--
Jean-Charles

Re: Add a cooperative FS lock to lilypond-book. (issue 555360043 by hanw...@gmail.com)

[dak]

On 2020/02/26 08:28:33, hahnjo wrote:
> On 2020/02/26 08:19:39, hahnjo wrote:

> > > On a philosophical level, it is a lilypond-book implementation
detail
> > > that it can't deal with concurrent invocation, so the remediation
for
> > > this problem should be in lilypond-book too.
> > 
> > Let me disagree: It's an implementation detail of make that it runs
things in
> > parallel. IMHO a build system should ensure that the result of
running with
> > multiple jobs is the same as a sequential run.
> 
> That said: I'm also fine if some other developer accepts this patch.
See my
> timing data above to get to your own conclusion. After all, my opinion
is just
> one of a larger range.

My take on this is that this "implementation detail" of parallel
invocation resulting in awkward breakage is something that warrants
fixing irrespective of our build system.  All that the UG states here is

‘--lily-output-dir=DIR’
 Write lily-XXX files to directory DIR, link into ‘--output’
 directory.  Use this option to save building time for documents in
 different directories which share a lot of identical snippets.

It doesn't state at all what happens in cases of contentions.  Fixing
contentions with a lock is a brute-force solution just not allowing for
parallelism, but it is a solution to the contention problem.

It is not a solution to lilypond-book starting more jobs than Make knows
about.  Or to all but one lilypond-book invocation not doing any
progress and blocking Make which could instead start other actual
single-process tasks.  So I see this patch and its approach as an
improvement to lilypond-book.  I don't see that it solves the parallel
build carnage: it just scales down the impact from having to choose
between complete serialization and database failure.

https://codereview.appspot.com/555360043/

Re: Getting download sizes right: proof of concept

[Werner LEMBERG]

>> I'd need someone to take this sketch and integrate it into the
>> build system (I just don't really understand the build system).
> 
> Do we really need this?

Yes, I think this is *very* useful.  It's always nice to know big file
sizes (i.e., files larger than, say, 1MByte) in advance.  Not everyone
is using a fast (and cheap) internet connection.

> We could just delete the download size from text and be correct in a
> much simpler way.  For today's standards, the difference between 6M
> and 35M isn't really all that relevant.

I strongly disagree.  It's still a very large difference.


Werner

Re: Add a cooperative FS lock to lilypond-book. (issue 555360043 by hanw...@gmail.com)

[Han-Wen Nienhuys]

On Wed, Feb 26, 2020 at 9:59 AM Han-Wen Nienhuys  wrote:
> In this patch, we create a "xxx.lock" file, which is a little ugly.
> Let me see if we can lock the directory directly.

you can't (it has to be a file.)

see https://gavv.github.io/articles/file-locks/#common-features for
more background.

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

Re: ly:page-turn-breaking core dumps

[Han-Wen Nienhuys]

On Tue, Feb 25, 2020 at 11:56 PM Pierre-Luc Gauthier
 wrote:

> Well, my system is more than a file. Anywho, I will provide a working
> bug… it sadly wont be minimal though.

> > You can send it by private mail.
>
> I'll prepare and send asap.

I had a short look, but I'll need more time, which I have on Friday.

The problem happens on the first page of the bass part, where we have
to fit the titles with the music.

Maybe you can experiment with removing some titles?

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

Re: Add a cooperative FS lock to lilypond-book. (issue 555360043 by hanw...@gmail.com)

[Han-Wen Nienhuys]

On Wed, Feb 26, 2020 at 9:19 AM  wrote:
> > A lock (a file lock, in this case) is the standard solution for
> > serializing concurrent access to a shared resource (a standard
> > problem). What is your objection against using a standard solution?
>
> Yes, locks are a standard solution, but file locks are brittle. I've
> seen them fail far too often (ever had your apt-get / yum / pacman error
> out because there was a lock-file?) so I object to adding this

No, not of late.

it's useful to distinguish between "file locks" and "lock files".  The
latter are a form of the former, but they rely on the lock process to
remove lock files if the process aborts.

Git uses these files pervasively, the reason being that this is the
only way to make locking work on NFS. Maybe you've seen problems with
Git?

fcntl locks used here are managed by the kernel. If the process
holding the lock dies, the lock is freed. So there is no staleness
(but they don't work on NFS). I challenge you to come up with a
mechanism where one can observe brittle behavior.

In this patch, we create a "xxx.lock" file, which is a little ugly.
Let me see if we can lock the directory directly.

>
> > On a philosophical level, it is a lilypond-book implementation detail
> > that it can't deal with concurrent invocation, so the remediation for
> > this problem should be in lilypond-book too.
>
> Let me disagree: It's an implementation detail of make that it runs
> things in parallel. IMHO a build system should ensure that the result of
> running with multiple jobs is the same as a sequential run.
>
> https://codereview.appspot.com/555360043/



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

Re: Add a cooperative FS lock to lilypond-book. (issue 555360043 by hanw...@gmail.com)

[jonas . hahnfeld]

On 2020/02/26 08:19:39, hahnjo wrote:
> On 2020/02/26 07:59:36, hanwenn wrote:
> > On Tue, Feb 25, 2020 at 11:09 PM 
wrote:
> > > Another solution might be serialize only lilypond-book and let tex
et
> > > al. run concurrently. That should also be harmless, right?
> > 
> > But this is exactly what this patch does.
> 
> I meant "serialize only lilypond-book in the Makefile [...]", sorry
for not
> being specific. I agree that this patch attempts to go this way in
> lilypond-book, and that's what I object to, see below.
> 
> > I don't understand your objection. Serializing mechanism in the
> > makefile are obscure and hard to understand, because build systems
> > want to do as many things in parallel as possible.
> 
> ... so it's the build system's responsibility to get things right. In
our case
> this means: Do *not* call lilypond-book in parallel.
> 
> > A lock (a file lock, in this case) is the standard solution for
> > serializing concurrent access to a shared resource (a standard
> > problem). What is your objection against using a standard solution?
> 
> Yes, locks are a standard solution, but file locks are brittle. I've
seen them
> fail far too often (ever had your apt-get / yum / pacman error out
because there
> was a lock-file?) so I object to adding this complexity if it only
helps for a
> single case in our build (ie input/regression/lilypond-book/).
> 
> > On a philosophical level, it is a lilypond-book implementation
detail
> > that it can't deal with concurrent invocation, so the remediation
for
> > this problem should be in lilypond-book too.
> 
> Let me disagree: It's an implementation detail of make that it runs
things in
> parallel. IMHO a build system should ensure that the result of running
with
> multiple jobs is the same as a sequential run.

That said: I'm also fine if some other developer accepts this patch. See
my timing data above to get to your own conclusion. After all, my
opinion is just one of a larger range.

https://codereview.appspot.com/555360043/

Re: Add a cooperative FS lock to lilypond-book. (issue 555360043 by hanw...@gmail.com)

[jonas . hahnfeld]

On 2020/02/26 07:59:36, hanwenn wrote:
> On Tue, Feb 25, 2020 at 11:09 PM 
wrote:
> > Another solution might be serialize only lilypond-book and let tex
et
> > al. run concurrently. That should also be harmless, right?
> 
> But this is exactly what this patch does.

I meant "serialize only lilypond-book in the Makefile [...]", sorry for
not being specific. I agree that this patch attempts to go this way in
lilypond-book, and that's what I object to, see below.

> I don't understand your objection. Serializing mechanism in the
> makefile are obscure and hard to understand, because build systems
> want to do as many things in parallel as possible.

... so it's the build system's responsibility to get things right. In
our case this means: Do *not* call lilypond-book in parallel.

> A lock (a file lock, in this case) is the standard solution for
> serializing concurrent access to a shared resource (a standard
> problem). What is your objection against using a standard solution?

Yes, locks are a standard solution, but file locks are brittle. I've
seen them fail far too often (ever had your apt-get / yum / pacman error
out because there was a lock-file?) so I object to adding this
complexity if it only helps for a single case in our build (ie
input/regression/lilypond-book/).

> On a philosophical level, it is a lilypond-book implementation detail
> that it can't deal with concurrent invocation, so the remediation for
> this problem should be in lilypond-book too.

Let me disagree: It's an implementation detail of make that it runs
things in parallel. IMHO a build system should ensure that the result of
running with multiple jobs is the same as a sequential run.

https://codereview.appspot.com/555360043/

Re: Getting download sizes right: proof of concept

[Han-Wen Nienhuys]

On Wed, Feb 26, 2020 at 2:19 AM David Kastrup  wrote:
>
>
> I'd need someone to take this sketch and integrate it into the build
> system (I just don't really understand the build system).

Do we really need this? We could just delete the download size from
text and be correct in a much simpler way. For today's standards, the
difference between 6M and 35M isn't really all that relevant.


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

Re: Add a cooperative FS lock to lilypond-book. (issue 555360043 by hanw...@gmail.com)

[Han-Wen Nienhuys]

On Tue, Feb 25, 2020 at 11:09 PM  wrote:
> Another solution might be serialize only lilypond-book and let tex et
> al. run concurrently. That should also be harmless, right?

But this is exactly what this patch does.

I don't understand your objection. Serializing mechanism in the
makefile are obscure and hard to understand, because build systems
want to do as many things in parallel as possible.

A lock (a file lock, in this case) is the standard solution for
serializing concurrent access to a shared resource (a standard
problem). What is your objection against using a standard solution?

On a philosophical level, it is a lilypond-book implementation detail
that it can't deal with concurrent invocation, so the remediation for
this problem should be in lilypond-book too.

> In total I'm still not convinced by this complexity.
>
> https://codereview.appspot.com/555360043/



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