Re: LilyPond 2.25.14

[Karlin High]

On 3/23/2024 2:00 PM, Jonas Hahnfeld wrote:

Would be interesting to see how this compares to the "vanilla" package


I tried it, 3 runs. First one maybe unfair because font cache 
initialization or something.


real0m48.643s
user0m0.000s
sys 0m0.031s

real0m31.457s
user0m0.015s
sys 0m0.000s

real0m31.591s
user0m0.000s
sys 0m0.031s

The another with the JIT version:

real0m32.319s
user0m0.000s
sys 0m0.030s

But I expect I should get the computer otherwise idle as far as possible 
for this. I had other software running, but nothing with heavy loads.

--
Karlin High
Missouri, USA

Re: LilyPond 2.25.14

[Karlin High]

On 3/23/2024 10:02 AM, Jonas Hahnfeld via LilyPond user discussion wrote:
Windows build with Guile JIT: https://cloud.hahnjo.de/s/Ek5x9rybpiPNtoj 
This turns on just-in-time compilation that was added in Guile 3.0, but 
we had to keep disabled on Windows until now. Please test, especially on 
larger scores where this should provide a performance advantage.


Carver MSDM.ly, subject of many past performance-test posts.

Inte Core i5-3450
24 GB RAM
Windows 10 22H2

real 0m32.109s
user 0m0.000s
sys 0m0.015s

--
Karlin High
Missouri, USA

Re: LilyPond 2.25.10 with Guile 3.0

[Karlin High]

On Sun, Nov 12, 2023 at 6:26 AM Jonas Hahnfeld via LilyPond user
discussion  wrote:
> If you have some time, please test them in your setups and report back in 
> case of problems!

Seems OK so far. Windows 11 21H2, Intel Core i5-1135G7.

"
>lilypond.exe scheme-sandbox
GNU LilyPond 2.25.10 (running Guile 3.0)
Processing 
`C:/Users/owner/AppData/Local/frescobaldi/frescobaldi/lilypond-binaries/lilypond-2.25.10/share/lilypond/2.25.10/ly/scheme-sandbox.ly'
Parsing...
GNU Guile 3.0.9
"

When I run convert-ly, it makes version statements "2.25.9". I can't
remember if that is expected or not for the 2.25.10 binaries. No
warnings of outdated versions are given when compiling the results.
-- 
Karlin High
Missouri, USA

Re: LilyPond 2.25.9

[Karlin High]

On 10/7/2023 10:41 AM, Jonas Hahnfeld via Discussions on LilyPond 
development wrote:
With this release, LilyPond's HTML documentation switches (back) to 
texi2any. While we tried to make sure that existing links will continue 
to work, please report back if that is not the case.


The initial appearance is good.

Jonas, you are somehow the go-to developer for major technical-debt 
upgrades like this. Whatever further adjustments texi2any ends up 
needing, just having this in place is an excellent accomplishment.

--
Karlin High
Missouri, USA

Automating LilyPond setup on Windows

[Karlin High]

LilyPond's current build system produces stand-alone, relocatable
Windows executables distributed in a zip folder.

Which I think approaches the ideal.

However, for the past 2 human generations or so, Windows users have
been taught they are unqualified to manage locations of software
executables. They are taught this is exclusively the installer's job,
like setup.exe or something.

There have now been several questions on the lilypond-user list with
some form of "I downloaded this zip folder, now what do I do with it?
How do I 'install' it?"

I expect such questions will continue until Windows users have an
automated way to get the executables in place.

Suggestions for improving the current-practice's documentation were made...

<https://lists.gnu.org/archive/html/lilypond-user/2023-03/msg00173.html>

...which led to a Merge Request, where I was encouraged to present an
idea separately from it.

<https://gitlab.com/lilypond/lilypond/-/merge_requests/1869#note_1314585504>

So here goes. The idea is this: Offer Windows users an optional
install script that downloads the zip folder and arranges its contents
as they would expect done by an installer.

This idea is completely separate from the build system. I am not
suggesting any changes for that.

Rather, I am looking at what the Micro text editor has. It also is a
stand-alone, relocatable executable needing no "installation" efforts.

The install script made for it is here:

<https://github.com/benweissmann/getmic.ro/blob/master/index.sh>

It is rather more elaborate than what I have in mind, but in practice
it can work like this:

$ curl https://getmic.ro | bash

For Windows, rather than such a one-liner, I am thinking more of an
"install.bat" file to download and execute. Completely optional. It
would:

* Download the LilyPond zip folder
* Extract it to a reasonable location
* Perhaps add the new LilyPond to Frescobaldi.

That could be done by using the freshly-extracted LilyPond's Python
executable to run the code Frescobaldi has for doing that.

<https://github.com/frescobaldi/frescobaldi/blob/92ad12137135b1693f6041567c81d2fa0f4ecf28/frescobaldi_app/lilypondinfo.py>

Or, maybe it would be better to have all this handled within
Frescobaldi instead?

Have Frescobaldi look up the latest version of LilyPond, and if it
doesn't exist on the user's computer, offer to download and install
it? It's been mentioned within that project:

<https://github.com/frescobaldi/frescobaldi/issues/1429>

<https://github.com/frescobaldi/frescobaldi/issues/313>

I don't plan to go further with this idea unless a good consensus
emerges for doing so.
--
Karlin High
Missouri, USA

Re: GSoC 2023

[Karlin High]

On 2/3/2023 1:17 AM, Werner LEMBERG wrote:

Who did the LilyPond's registration as an organization last time?


I remember Urs Liska being the main facilitator for Google Summer of 
Code work.


<https://lists.gnu.org/archive/html/lilypond-user/2020-02/msg00331.html>

<https://lists.gnu.org/archive/html/lilypond-devel/2020-03/msg00785.html>
--
Karlin High
Missouri, USA

Re: Ghostscript and new PDF interpreter

[Karlin High]

On 1/10/2023 4:46 AM, Werner LEMBERG wrote:

And no possibility of 'unifying' different fonts with the [new] pdfwrite
device.'


Ghostscript's Ken Sharp says:

"
The new PDF interpreter uses the object number, which is the unique 
identifier in PDF files, to key the fonts and as a result there is no 
longer any possibility of confusing two different fonts as being the same.

"
<https://bugs.ghostscript.com/show_bug.cgi?id=706316#c1>

And I start doing some "flies buzzing in a bottle" thinking since I 
don't know what an "object number" is or does.


Is there a way to influence what object numbers are assigned to fonts?
--
Karlin High
Missouri, USA

Re: Missing items to make Cairo ready

[Karlin High]

On 1/5/2023 4:30 PM, Jonas Hahnfeld wrote:

What I find worrying in this discussion is that proponents of having
Cairo sooner than later keep dismissing the size argument


Concern granted. I do appreciate optimal PDFs.

How much effort should be expended for what level of optimization, 
Cairo's costs in PDF optimization vs benefits in SVG output, I will not 
have the expertise to advance those discussions very much.


Thanks for the reminder to minimize dismissiveness.
--
Karlin High
Missouri, USA

Re: Missing items to make Cairo ready

[Karlin High]

On Thu, Jan 5, 2023, 6:07 AM Han-Wen Nienhuys  wrote:

> If we do custom post processing, we might as well postprocess the final
> PDF directly to make all snippets point to a single music font object?
>

I would like to hear more about what that could look like. There were
numerous mentions of Poppler; can it do things like that?

This got me thinking of the "Engrave (Publish)" command in Frescobaldi.
Optimize output instead of processing only after the source is final.
--
Karlin High
Missouri, USA

>

Re: Missing items to make Cairo ready

[Karlin High]

On 1/4/2023 3:22 PM, Werner LEMBERG wrote:

Honestly, a fourfold size increase is not something that I would call
'acceptable'.


Upstream might need some convincing.

Ghostscript's Ken Sharp in 2017:

"When we have customers wanting to send us 125GB files I have to say 
that a concern over file sizes in the few megabytes seems a bit picky."


<https://lists.gnu.org/archive/html/lilypond-devel/2017-09/msg00131.html>
--
Karlin High
Missouri, USA

Re: The hel-arabic.ly file story...

[Karlin High]

On 1/2/2023 10:25 AM, Amir Czwink wrote:

But I wonder, how the process will work then? Every one simply commits
what he thinks is best and we regularly overwrite each others
contributions?


LilyPond's process for contributions is documented here, in the 
Contributor's Guide:


<http://lilypond.org/doc/v2.25/Documentation/contributor/lifecycle-of-a-merge-request>

Especially section 3.3.3 Patch Countdown:

"
The Patch Meister reviews the tracker periodically, to list patches 
which have been on review for at least 24 hours. For each patch, the 
Handler reviews any discussion on the merge request, to determine 
whether the patch can go forward. If there is any indication that a 
developer thinks the patch is not ready, the Handler marks it 
Patch::needs_work and makes a comment regarding the reason, referring to 
the comment if needed.


Patches with explicit approval, or at least no negative comment, are 
updated to Patch::countdown. The countdown is a 48-hour waiting period 
in which any final reviews or complaints should be made.

"

I understand this process was set up to balance the interests of both 
code reviewers and contributors, in regard to how long it takes a 
contribution to become part of the code base.

--
Karlin High
Missouri, USA

Re: Missing items to make Cairo ready

[Karlin High]

On Fri, Dec 30, 2022 at 10:20 AM Lukas-Fabian Moser  wrote:
> That being said: My uneducated guess would be that with Cairo etc., it
> might be more natural/easy to import vector graphics in SVG format than
> in EPS?

And apparently tools such as Inkscape offer EPS to SVG conversion.

<https://inkscape.org/forums/questions/using-inkscape-to-convert-from-eps-to-svg-same-result-as-adobe-illustrator/>

Although that reference mentions disagreements among different tools
with color space matching and such.
-- 
Karlin High
Missouri, USA

Re: Missing items to make Cairo ready

[Karlin High]

On Fri, Dec 30, 2022 at 6:55 AM Jonas Hahnfeld via Discussions on
LilyPond development  wrote:
>
> On Fri, 2022-12-30 at 13:08 +0100, Jean Abou Samra wrote:
> > As I said, I don't see obvious use cases for \epsfile where you
> > really need vector graphics. LilyPond provides markup commands
> > for that.
>
> Ok, in that case we can properly deprecate this once we have an
> alternative (see above). I still think losing the ability to include
> (external) vector graphics is a loss, though.

What are the chances of having a conversion tool that produces
LilyPond markup commands for the vectors in formats such as EPS?

Perhaps as an eps2ly or something.
-- 
Karlin High
Missouri, USA

Re: Oriental microtonal music

[Karlin High]

On 12/29/2022 4:06 PM, David Kastrup wrote:

I doubt anybody has an idea what you want to to get done by whom for
what reason.


My email address was in the To: header.

In Cc: were the other people I had mentioned here:

<https://lists.gnu.org/archive/html/lilypond-devel/2022-12/msg00179.html>

Therefore, I understood that post as a response to my question about 
which available participants in the LilyPond community could advise on 
code reviews for Oriental microtonal music.


A threading disconnect at worst.
--
Karlin High
Missouri, USA

Re: The hel-arabic.ly file story...

[Karlin High]

On 12/28/2022 4:09 PM, Werner LEMBERG wrote:

asking you or others

Who else do we have?

Hans Åberg?

Adam Good?

Graham Breed?

I lose track of their alignments with Turkish vs Persian vs Arabic music.
--
Karlin High
Missouri, USA

Re: The hel-arabic.ly file story...

[Karlin High]

On 12/28/2022 10:17 AM, Amir Czwink wrote:

new contributions with (I'm sorry but thats the truth)
bad quality over proven ones, that have been existing since 2008 at
least, have been included into lilypond without questioning its
purpose


Producing sheet music for music traditions outside of LilyPond's focus 
is only possible thanks to the efforts of contributors from those 
traditions.


There are a certain number of active followers for LilyPond community 
discussion on its email lists, the code review process, and so on.


I am unclear on how many people with skill in Arabic music are in that 
number. I was not aware of your work, having only started following the 
email lists in 2016 or so.


I know nothing about Arabic music, other than it seems to have more 
notes per octave than what is used in music traditions descended from 
Western Europe.


The only comments I have are about how to keep the "proven" 
contributions prioritized over the "bad quality" ones.


Any time changes are proposed in a specialized area, it may be that the 
specialist proposing it does not have views representative of all other 
people in the specialty.


I think the LilyPond community then has 2 choices:

(1) Take the specialist's proposal at face value, beyond obvious and 
immediate problems


As you say, "one developer decided to contribute his ideas and nobody
questioned that in the code review." Perhaps because nobody else 
involved knew what questions to ask?


(2) Make the specialist's contribution wait for acceptance until another 
suitable and unrelated expert can be found to review it.


"Looks good, but this patch will have to wait until we find someone else 
to review it, who isn't your colleage, but is still well-versed in Tuvan 
Throat Singing from past centuries in Mongolia."


I remember seeing a similar thing in past discussion on note heads for 
shaped-note music traditions. A fine-details feature request was being 
asserted as highly important, while I'd somehow spent my entire life in 
said music tradition without even knowing the details in question 
existed, and was unable to find them when I started looking for them.


<https://lists.gnu.org/archive/html/lilypond-devel/2020-07/msg00229.html>

The fine details of mirrored-MI notes are possibly gone now.

Because, all the community had to go on was, "in the past, an expert 
said it needs to be that way."


There were apparently few lasting references given to establish that the 
claimed feature was representative of the entire music tradition in 
question. When future contributors get to looking, and can't 
substantiate the claim, it may well be disregarded if that expert is not 
around to defend it.


The better we can document the reasons behind a change in community 
discussions related to them, the better chances there are of future 
changes deferring to the past discussions.


I commend you for submitting a merge request to improve LilyPond's 
quality for Arabic music as you see it needs.

--
Karlin High
Missouri, USA

Re: Darwin 64 questions

[Karlin High]

On Wed, Dec 21, 2022, 3:29 PM Paolo Prete  wrote:

> 4) What about 64 bit binary builds for versions different than 1.19.83,
> 2.22.0 and 2.24.0? Are they available somewhere?
>

No. I understand none were produced, partly due to conflicts between the
prior build system and Apple's SDK licensing. There should be prior
discussion on this in the archives.
--
Karlin High
Missouri, USA

>

Re: New CI runner

[Karlin High]

On 12/12/2022 10:34 AM, Jean Abou Samra wrote:

What version of macOS does this MacBook Air have?


It is also in end-of-life, but is able to get to macOS Catalina 10.15.7

Details:

MacBook Air (11-inch, mid-2012)
Intel Core i5-3317U 1.7-2.6 GHz (2 cores, 4 threads)
4 GB RAM

I keep this thing around to run the Apple Configurator 2 software, 
related to iOS device management. Eventually I will have to upgrade, 
because the oldest software that works with the newest device will still 
be too-new for this machine. I am interested in knowing if an Intel or 
Apple Silicon CPU would be more useful to future lilypond-devel purposes.

--
Karlin High
Missouri, USA

Re: New CI runner

[Karlin High]

No, it is Linux. (Docker in Alpine in ProxMox.)

If a macOS machine is wanted, I have a MacBook Air which could help,
although its capacities are unremarkable.
--
Karlin High
Missouri, USA

Automated testing for users' LilyPond collections with new development versions

[Karlin High]

This message intrigued me:

<https://lists.gnu.org/archive/html/lilypond-devel/2022-11/msg00222.html>

In it, Eric Benson reported a setup that allows testing new versions of 
LilyPond on a sizable body of work in a somewhat automated fashion.


Now, could automation like that also make use of the infrastructure for 
LilyPond's regression tests?


<http://lilypond.org/doc/v2.23/Documentation/contributor/regtest-comparison>

What effort/value would there be in making an enhanced convert-ly tool 
that tests a new version of LilyPond on a user's entire collection of 
work, reporting differences between old and new versions in performance 
and output?


Enabling something like this:

* New release of LilyPond comes out. Please test.

* Advanced users with large collections of LilyPond files do the 
equivalent of "make test-baseline," but for their collection instead of 
LilyPond's regtests. Elapsed time is recorded, also CPU and RAM info as 
seems good.


* New LilyPond gets installed

* Upgrade script runs convert-ly on the collection, first offering 
backup via convert-ly options or tarball-style.


* Equivalent of "make check" runs

* A report generates, optionally as email to lilypond-devel, with 
summary of regression test differences and old-vs-new elapsed time.


Ideally, this could quickly produce lots of good testing info for 
development versions of LilyPond, in a way encouraging user participation.

--
Karlin High
Missouri, USA

Re: BDWGC fix in 2.24?

[Karlin High]

On 11/18/2022 4:06 AM, Jean Abou Samra wrote:

Do we keep the current workaround, which still
gives some crashes?


In that case, possibly releasing with a "known issue" note, and 
explaining how Windows users could use Windows Subsystem for Linux if 
they have very large scores approaching memory limits?


And, then maybe have 2.24.1 release after the BDWGC fix comes down.

It looks to me like the different choices will be a matter of figuring 
out which set of trade-offs will be best for the entire LilyPond 
community, within acceptable norms for a stable release.

--
Karlin High
Missouri, USA

Code Signing for LilyPond executables (WAS: LilyPond 2.23.81 on lilypond-user)

[Karlin High]

> Continuing a lilypond-user discussion on code signing for LilyPond 
executables, in hopes of pacifying security software.



On 16/11/2022 7:55 am, Karlin High wrote:
On 11/15/2022 2:30 PM, Jonas Hahnfeld via Discussions on LilyPond 
development wrote:

b) whether we would need to buy a certificate for that.


I think the answer is "yes, need to buy certificate."

And even that is no guarantee of executables not getting flagged after 
downloads, UNLESS there is a large and powerful outfit behind the 
signature that the security companies wish to avoid angering.


<http://blog.nirsoft.net/2009/05/17/antivirus-companies-cause-a-big-headache-to-small-developers/> 



If a certificate WAS pursed, with macOS having the greatest need I 
expect, it looks like it would need contact info and a mailing 
address. That is where I stopped research, having no idea what would 
be used there.


On 11/15/2022 5:40 PM, Andrew Bernard wrote:
I have never had a Windows app certified, but I don't think there is any 
cost associated with it, it's just a process at Microsoft. This sort of 
signing in not a TLS certificate possibly involving cost (though most 
people use Let's Encrypt now).


This is a page from Microsoft. I think it's outdated but the principles 
would remain roughly the same.


https://learn.microsoft.com/en-us/windows/win32/win_cert/windows-certification-portal 




If there is any interest I'd be happy to investigate this more 
seriously. perhaps this should be on the devel list?



Andrew 


A code signing certificate is not the same thing as a TLS certificate. 
Perhaps the difference would mostly be marketing and the nature of 
assurance assertions from the provider.


Step 3 at the windows-certification-portal link includes "Get a code 
signing certificate."


That leads to this page with 7 different options for certificate providers:

<https://learn.microsoft.com/en-us/windows-hardware/drivers/dashboard/code-signing-cert-manage>

I am seeing annual prices from 129 to over 500 USD. Depending on what 
options are included, such as Extended Validation certificates and 
Hardware Security Modules for protecting the signing.


I am dim on what Extended Validation all involves. But I have in mind it 
includes verifying that the entity buying the certificate has a 
legitimate existence. For LilyPond, that entity would be... the main 
developer listed in GNU projects? The Free Software Foundation? 
Something else?


Maybe skip Extended Validation then.

But then some providers list "Immediate reputation with Microsoft 
SmartScreen Filter" as a selling point for Extended Validation.


Which I guess would fall back to having new executables still getting 
flagged, and having someone immediately respond with a request to have 
the fresh EXE file marked as trusted. The times I've done this to aid 
small developers I trust who have just published new code, Microsoft 
goes through a routine of "Who are you, anyway? Are you the publisher?" 
I guess trying to make sure I am not a malware distributor trying to get 
their latest evil scheme pre-approved with security software somehow.


Those very cautious could just wait a week or two for all that to settle 
before downloading and running. Eventually security software catches on.


For Apple's macOS world, things are far different yet. Possible starting 
point:


<https://developer.apple.com/support/certificates/>
--
Karlin High
Missouri, USA

Re: LilyPond 2.23.81

[Karlin High]

On 11/15/2022 2:30 PM, Jonas Hahnfeld via Discussions on LilyPond 
development wrote:

b) whether we would need to buy a certificate for that.


I think the answer is "yes, need to buy certificate."

And even that is no guarantee of executables not getting flagged after 
downloads, UNLESS there is a large and powerful outfit behind the 
signature that the security companies wish to avoid angering.


<http://blog.nirsoft.net/2009/05/17/antivirus-companies-cause-a-big-headache-to-small-developers/>

If a certificate WAS pursed, with macOS having the greatest need I 
expect, it looks like it would need contact info and a mailing address. 
That is where I stopped research, having no idea what would be used there.

--
Karlin High
Missouri, USA

Re: Can Guile v3.0.8 be part of the LilyPond v2.24 release?

[Karlin High]

On Mon, Nov 14, 2022, 7:25 PM Volodymyr Prokopyuk <
volodymyrprokop...@gmail.com> wrote:

> Can the migration be part of the LilyPond v2.24 release?
>

Recent discussion has the 2.24 release planned for mid-December or so. I
expect migration to newer Guile versions, especially ones that have large
architectural changes, cannot be considered for 2.24 at this point.
--
Karlin High
Missouri, USA

>

Re: texi2any upgrade: Is there a regtest showing the results needed?

[Karlin High]

On 11/1/2022 4:44 PM, Jean Abou Samra wrote:
As Jonas said: you are welcome to work on this, but be prepared for a 
bumpy ride.


Provided the expectations stay low and long-term, I have a pretty deep 
patience for whatever community process is needed along the way.


Feedback like this regarding best approaches is appreciated. My coding 
background is Microsoft Office Visual Basic for Applications, which is 
not the best foundation for an effort like the texi2any upgrade.

--
Karlin High
Missouri, USA

texi2any upgrade: Is there a regtest showing the results needed?

[Karlin High]

On 10/25/2022 4:00 PM, Jonas Hahnfeld wrote:
> I think it may be better to rewrite the needed customizations more or
> less from scratch. From a few preliminary tests some time ago, many
> things will work very differently with texi2any; some customizations
> won't be necessary anymore (because there are options to get the same
> effect) and some new ones will be needed.
>
> From 
<https://lists.gnu.org/archive/html/lilypond-devel/2022-10/msg00194.html>


With the start-afresh approach for lilypond-texi2html.init, it seems to 
me the first thing that would be needed is a regtest or Minimal Working 
Example of sorts: A concise texinfo file calling for each feature or 
function needing equivalent replication in the upgrade.


Once the targeted version of texi2any is producing acceptable results 
from that file, then move on to testing on the full documentation.


I read the Contributors Guide, Chapter 9, Regression Tests, and did not 
see any references to something like this. Does anyone know if such a 
thing already exists?


If not, does it seem like anything worth pursuing?

Personally, I could see it aiding future upgrade efforts. And for my 
involvement in such efforts currently, I would almost need to do it 
regardless to fill in the gaps in my understanding of the codebase, 
Texinfo old and new, and what feature requests if any need sent upstream.

--
Karlin High
Missouri, USA

Re: LilyPond 2.23.80

[Karlin High]

On 10/22/2022 3:32 PM, Jonas Hahnfeld via LilyPond user discussion wrote:

test your scores with this version


All seems well after several hours of light use on Windows 10.
--
Karlin High
Missouri, USA

Is a texi2any upgrade still wanted, and what would it take? (WAS: Re: New Lilypond logo?)

[Karlin High]

On 10/24/2022 10:12 AM, Jean Abou Samra wrote:

If you want my subjective personal opinion: the current logo
and website are just fine.


I understand there is a technical-debt issue in this area, though. 
Related to an old version of Texinfo, and the older texi2html vs the 
newer texi2any. Which is to generate the website concurrently with the 
rest of the documentation.


Near as I can tell, this reference best captures the issue:

<https://gitlab.com/lilypond/lilypond/-/issues/1557>

I have had my eye on this area as a potential future personal project, a 
long-term seasons-of-code level effort.


However, my levels of Linux development know-how are quite varied. What 
foundational knowledge would be needed for that effort? Reading the 
texinfo 1.82 manual, as well as a newer version?

--
Karlin High
Missouri, USA

Re: LilyPond 2.23.14

[Karlin High]

On Sun, Oct 9, 2022 at 3:57 PM Jonas Hahnfeld via Discussions on
LilyPond development  wrote:
> please test with your use cases and notify us of any problems.

I spent a few hours yesterday with LilyPond 2.23.14 and Frescobaldi
3.2, on Windows 10 21H1.

While I am not the most demanding user -- mostly doing SATB/TTBB
shape-note hymns and light choral works -- all seems well for me with
this release. In spite of the major foundational upgrades completed
and underway such as Guile 2+ and Cairo, the software is still
LilyPond-as-expected and I would not be aware of the changes if I was
not following the mailing lists.

Kudos to all involved, especially Jonas Hahnfeld for managing the releases.
-- 
Karlin High
Missouri, USA

Re: RFC on MR 1368

[Karlin High]

On 5/25/2022 4:16 PM, David Kastrup wrote:

I cannot do much
more than express my gratitude that I see people willing to work on
addressing one another's concerns and wish them success doing it without
wasting unnecessary amounts of their energy.


Same here. The font-structure issues have multiple overlapping technical 
topics far beyond any capacities I have for engaging with them. All 
parties in the discussion have my respect for what they have contributed 
to LilyPond.


Disagreement is relationally expensive, and its costs must be managed. 
But sometimes working through it is necessary to reach better 
understandings of an issue.

--
Karlin High
Missouri, USA

Re: Blockers for Guile 2.2

[Karlin High]

On 2/22/2022 10:55 AM, Werner LEMBERG wrote:

In particular, we can't tell non-developers "Please use the
current development version, which works very reliably" and introduce
a severe slowness at the same time.


Perhaps that advice could be suspended for one series of development 
versions? Doing one last Guile 1.8 stable release before the Guile 2.2 
transition, then advising to stick with that if interim slowness in 
development versions is unacceptable.

--
Karlin High
Missouri, USA

Re: Clarifying Windows support

[Karlin High]

On Mon, Feb 14, 2022, 3:47 PM Jean Abou Samra  wrote:

>  currently says systems as old
> as Windows 2000 are supported, which is obviously not true. It looks
> like that page has not been updated for long. What should we replace
> this statement with?
>

How about not mentioning a specific version at all? Some form of "supported
on current versions of Windows, possibly functional on older ones."
--
Karlin High
Missouri, USA

>

Re: Fwd: Binaries of LilyPond 2.23.5 with Guile 2.2

[Karlin High]

On 12/7/2021 4:10 PM, Petr Pařízek wrote:
The build that you made on July 3rd, under the name 
"lilypond-mingw-x86_64-full", is running okay


Can you generate and post a hash of the lilypond.exe you have on your 
Win 7 64-bit machine? This would show if anything got bothered in 
download or decompression.


Windows software for generating hashes, if needed:

<https://www.nirsoft.net/utils/hashmyfiles-x64.zip>
--
Karlin High
Missouri, USA

Re: compiling MacOS application in LilyDev

[Karlin High]

On 11/8/2021 4:55 PM, Kieren MacMillan wrote:

I’m on 10.13.6 (High Sierra)


High Sierra can still run 32-bit, right? That could allow for using GUB 
on LilyDev to produce a standard macOS installer.

--
Karlin High
Missouri, USA

Re: compiling MacOS application in LilyDev

[Karlin High]

On Sun, Nov 7, 2021, 6:46 PM Kieren MacMillan 
wrote:

> is it possible for me to compile a version of Lilypond that will run
> natively on my Mac OS machine?
>

One starting point:



>

Re: AVG Antivirus stopped LilyPond PDF generation

[Karlin High]

On 9/20/2021 12:31 PM, Karlin High wrote:

The product was AVG Free 21.7.3196, definitions 21.7.3196.


Correction, definitions 210920-4.
--
Karlin High
Missouri, USA

AVG Antivirus stopped LilyPond PDF generation

[Karlin High]

I am unsure which mailing list is best suited for this report. A 
LilyPond user called for help with errors of the following form:


"
Converting to `test.pdf'...

warning: `(gs -q -dNODISPLAY -dNOSAFER -dNOPAUSE -dBATCH 
-dAutoRotatePages=/None -dPrinted=false ./tmp--tmp-4710074)' failed (1)


fatal error: failed files: "C:/Users/user/Desktop/My songs/test.ly"

Exited with return code 1.
"

This is coming from Windows 10 Pro 21H1, LilyPond 2.23.3, Frescobaldi 
3.1.3. It looked to me like GhostScript was unable to write the PDF, the 
sort of error that would happen if directory permissions or file locking 
was interfering somehow.


But it turned out to be AVG Antivirus causing the PDF generation 
failure. Disabling the antivirus fixed the problem, PDFs would then 
generate just fine. Re-enabling the antivirus also re-enabled the problem.


The product was AVG Free 21.7.3196, definitions 21.7.3196. It has now 
been replaced, all seems OK, reporting this for future reference.

--
Karlin High
Missouri, USA

Re: Hosting a FUDforum on lilypond.org

[Karlin High]

On 8/2/2021 7:25 AM, Jean Abou Samra wrote:

I started searching for alternatives, and didn't find many.
In fact exactly one, called FUDforum -- Fast Uncompromising
Discussions, and not Fear, Uncertainty and Doubt! Its main
page is itself a FUDforum, [11], and the documentation is
at [12].


I appreciate the research efforts. I glanced at the documentation, and 
found this page that explains "Mailing List Manager" features.


<http://cvs.prohost.org/index.php?title=Mailing_List_Manager>

"The Mailing List Manager admin control panel allows the administrator 
to define mailing list rules that allow FUDforum to archive messages 
from a mailing list as well as allow the forum's own messages to be sent 
to the mailing list."


That sounds pretty promising.
--
Karlin High
Missouri, USA

Re: SMuFL name mapping update, 9 July

[Karlin High]

On 7/9/2021 9:09 PM, Owen Lamb wrote:
I've dropped in the next few Emmentaler categories (Default Noteheads, 
Special Noteheads, and Shape-note Noteheads), so feel free to give it a 
look at https://wolfgangsta.github.io/emmentaler-bravura/. Please let me 
know what you think, especially regarding the red "contentious" cells!


I looked over the list, focusing on the shape notes. Nothing stood out 
to me as being wrong, although I have no skill for the font design 
concerns here.


It looks like the majority of the red=contentious cells for shape notes 
are in the Walker shapes. I am not aware there is a living music 
tradition or community still using these or the Funk ones, as there is 
for Aiken and Sacred Harp. The value of Walker and Funk shapes would 
mainly be for reproducing historical works.


Therefore, I would say feel free to do whatever makes sense and results 
in usable fonts. There is unlikely to be many "normal" users with 
highly-specific concerns for Walker shapes. And if someone is doing a 
labor-of-love scholarly historical reproduction of a Walker-heads work, 
it is doubtful this project can foresee what they would care about 
without having such an expert available at this point.


You are reaching a point where I am starting to go, "Eh, if Owen Lamb 
studied and designed something for LilyPond fonts, it's probably fine."

--
Karlin High
Missouri, USA

Re: Lilypond 64-bit binaries

[Karlin High]

On 4/22/2021 1:32 PM, Kieren MacMillan wrote:

I believe I have a client who might be willing to donate time on an 
internet-accessible Apple server.


I'm pretty sure the original discussion mentioned MacStadium, a macOS 
hosting service.


<https://www.macstadium.com/opensource>

"To support the FOSS community, MacStadium is offering FREE Mac mini 
hosting for developers working on open source projects."

--
Karlin High
Missouri, USA

Re: State of LilyPond with Guile 2.2

[Karlin High]

On 4/12/2021 7:06 AM, David Kastrup wrote:

Not being able to use 64-bit addressing on Windows with GUILE 1.8 is
an extremely serious problem.

I was of the opinion that we distributed a 64-bit version here?  Or did
I get that wrong?


Windows Subsystem for Linux continues to gain capability. It's allowing 
for Linux executables called from Windows and vice versa.


I understand the Windows-native LilyPond build consumes the most 
maintenance resources of all the builds.


Maybe eventually it's easier to have a PowerShell script or something 
that sets up everything LilyPond needs under the Windows Subsystem for 
Linux? Downside: needs a more-recent Windows 10 to do good with this.

--
Karlin High
Missouri, USA

Re: Test reader speed of Guile 3.0.6

[Karlin High]

On Fri, Mar 19, 2021, 7:09 PM Knut Petersen 
wrote:

> Now the second part of my tests. A score typical for my usage of
> lilypond.  96 bars, SATB divisi, 13 pages A4.
>

I wonder what the Carver MSDM score would look like. Searching the
archives, it's seemingly become an informal standard for large-project
stress tests.
--
Karlin High
Missouri, USA

>

Re: Test reader speed of Guile 3.0.6

[Karlin High]

On 3/19/2021 8:03 AM, Knut Petersen wrote:

Building lilypond 'master' with guile 'master' looks promising:


Indeed. I understand memory usage has been higher for LilyPond with 
post-1.8 guile versions. Was any of that notable in these tests?

--
Karlin High
Missouri, USA

Re: hello list!

[Karlin High]

On 1/19/2021 2:11 PM, Adam McCartney wrote:

I look forward to learning some new things on here and to help out where I can.


Welcome! The Contributor's Guide is a good starting point.

<http://lilypond.org/development.html>

--
Karlin High
Missouri, USA

Re: Stop issue verification?

[Karlin High]

On 10/26/2020 12:42 PM, Jean Abou Samra wrote:
the purpose is to cover also issues that are not actually bugs but were 
opened because of a mis-expectation of the program's behavior 
(currently, "Invalid").


"Not Applicable" or "N/A" or "Does Not Apply"?

"Not A Bug"?

Maybe too negative: "Ignored," "Disregarded,"
--
Karlin High
Missouri, USA

Re: Stop issue verification?

[Karlin High]

On 10/26/2020 12:16 PM, Jean Abou Samra wrote:

Something like "Void" or "Won't fix" would be a good option in my opinion.


Would "Inactive" be too negative or inaccurate?
--
Karlin High
Missouri, USA

Re: feasibilty question: simple GUI for web-based Lilypond instance

[Karlin High]

On Fri, Oct 23, 2020 at 3:36 PM Kieren MacMillan <
kieren_macmil...@sympatico.ca> wrote:

> The app/site *must* allow entry of notes using either a MIDI keyboard or a
> "Quick Entry" (mouse-click) type UI; drag-and-drop would obviously be a
> bonus, but is hardly necessary.
>


> in a “perfect” world, the students wouldn’t even see the .ly code.
>

I'm understanding this use case wants...

* No-code GUI music entry
* Runs in a web browser
* Allows collaborative editing

Many of the Git websites would have ways to collaboratively edit LilyPond
code, without needing to know very much about Git.

The Denemo project has lots of efforts for entering music without much
LilyPond coding.

LilyBin and Hacklily are the leaders for in-browser LilyPond work.

Combining all of this, though... I'm having trouble imagining what
"collaborative editing" would look like in a "No-code GUI." Something like
PDF commenting? Has anything like that ever been seen in the LilyPond
ecosystem? Paolo Prete's Spontini-Editor might be the closest thing I can
remember.
-- 
Karlin High
Missouri, USA

Re: on branching...

[Karlin High]

On 10/5/2020 7:33 AM, Michael Käppler wrote:

Sure, it may be that there are
still lots of problems there, waiting to be uncovered. But debating whether
we need more testing at first does not help, when we do not have
enough people to do it.


What would a reasonably-adequate testing effort look like? Maybe that 
could be crowd-sourced if step-by-step instructions are given.

--
Karlin High
Missouri, USA

Re: GSoC 2020: Shape-note notehead encoding

[Karlin High]

On Thu, Jul 23, 2020 at 9:00 PM Karlin High  wrote:
> The four-shape communities... I gather these folks would be more likely to 
> care

If anyone wants more input on these questions, maybe a post on
lilypond-user would be in order? There have been people from the
four-shapes scene active there in the past.

<https://lists.gnu.org/archive/html/lilypond-user/2018-05/msg00256.html>

--
Karlin High
Missouri, USA

Re: GSoC 2020: Shape-note notehead encoding

[Karlin High]

On Thu, Jul 23, 2020 at 6:29 PM Owen Lamb  wrote:
> Aha! Apparently all the old issue conversations have been migrated to
GitLab. The links and attachments work fine here:
https://gitlab.com/lilypond/lilypond/-/issues/1060

Brilliant! I had clean missed how that's worked out.

> This book being the only source cited for such differences, I don't think
there's any reason at the moment to propose the two variants be
distinguished within SMuFL itself. Bar objections, I'll go ahead and call
Emmentaler's mirrored versions stylistic alternates and leave it at that.
>
> I'm also going to hold off on asking for distinction between half and
whole noteheads, because, as far as I can tell, there isn't enough of one.
It appears that Walker always defaults to down-stem notes unless lack of
space necessitates up-stems, so that would explain why whole notes are only
found in their down-stem variants. There's no situation where using the
up-"stem" variant of a stemless note would free up space or avoid a
collision, so down-stem is simply used all the time!
>
> Of course, this raises the question of what to do with our current
whole-half distinction. I motion to scrap it, and have \walkerHeads and
\walkerHeadsMinor default to downwards stems and noteheads to achieve the
same effect. It'll be more accurate to Walker's originals, to boot. Any
objections here?

There are at least two shape-note communities. The four-shapes (Sacred
Harp, Fasola) <https://fasola.org/> and the seven-shapes (Aiken.) Here's my
perspective from the seven-shapes world, with no experience in the
four-shapes one.

I think the majority of seven-shapes people today are in church communities
descended from the singing school traditions of early America, especially
the south. <https://en.wikipedia.org/wiki/Singing_school> These include the
Mennonites (Joseph Funk's people) and the Church of Christ groups. I don't
know exactly what size this community is, but based on group populations,
I'm going to guess over a million people. Some of these have had people
singing from seven-shape hymnals every Sunday for the past century or more.
I think shape notes are important to these people, but not their defining
feature or their main reason to exist. For their music printing purposes,
unless someone's trying to reprint a landmark work, exact historic
authenticity is probably not a huge concern provided things are
recognizable. New songs and new books are continually being published in
this scene. Personally, LilyPond's Aiken Thins are the only shapes I need
for what I do. I've sung from seven-shapes books all my life, and it's
telling that only from the LilyPond community did I learn the distinctions
being discussed here.

The four-shape communities seem more defined by particular books (Sacred
Harp, etc) and conventions or singing events based on them. Their Wikipedia
article indicates that deviations from the historic tradition can be
divisive issues. <https://en.wikipedia.org/wiki/Sacred_Harp> I gather these
folks would be more likely to care which bars of a MI diamond note head are
darker than the others. They also have the advantage of organizational
structures to contact with questions on their musical matters, whereas for
seven-shapes I'd have no idea who's word would carry.
-- 
Karlin High
Missouri, USA

Re: GSoC 2020: Shape-note notehead encoding

[Karlin High]

On Wed, Jul 22, 2020 at 4:31 PM Owen Lamb  wrote:
> Firstly, none of the corpora (aha!) you provided or ones I found myself
> seemed to present both mirrored versions of mi in the same document, as
> Massive Lion claimed on the original Google Code archive should be the case
> depending on stem direction at least in Funk's system. I'd be hard pressed
> to make a case for our mirrored Aikin and up/down Funk variants if I can't
> show them in action.
>
> In addition, I could not find anywhere in the corpora an example of a whole
> notehead being distinct from its corresponding half notehead in any style.

So far I haven't been able to find mirrored notehead examples either.
Maybe the old shape-note tunebook scans I'm checking aren't from the
right editions for finding them.

And I've read over the archived Google Code discussion. That was
before my time in the LilyPond community, I have very little
experience prior to 2016 or so. If we could find the image attachments
from the original postings, those were claimed to have examples of
these mirrored noteheads. But none of the attachment links seem to
work, and archive.org doesn't have them either. Maybe the link format
changed at some point, and archive.org would have them if I only knew
how to ask?
-- 
Karlin High
Missouri, USA

Re: GSoC 2020: Shape-note notehead encoding

[Karlin High]

On 7/22/2020 12:09 PM, Carl Sorensen wrote:
We have it in our university library.  Would you like me to get it and 
make some page scans?


I expect there are editions of that one with both shaped and unshaped 
notes. If it's shaped notes, and it's not too much bother, and it's felt 
to be helpful for this development effort... then it might be 
interesting to see how that generation of hymnal has things.

--
Karlin High
Missouri, USA

Re: GSoC 2020: Shape-note notehead encoding

[Karlin High]

On 7/22/2020 11:15 AM, Carl Sorensen wrote:
But to my eye, the Mennonite Hymnal from 1969 has the best aesthetics of 
all the scans you shared.


Much of the shape-note tradition is aimed at amateurs. It's trying to 
get a strong community-wide music tradition from minimal educational 
resources. For that 1969 book, the level of music training behind it is 
probably higher than many of the others.


<https://emu.edu/faculty-staff/?show=nafzigkj>

There is also a successor, "Hymnal: A Worship Book" from 1992.
<https://www.amazon.com/dp/0836180011>

But I don't own one of those and can't find page scans anywhere.
--
Karlin High
Missouri, USA

Re: GSoC 2020: Shape-note notehead encoding

[Karlin High]

On Tue, Jul 21, 2020 at 7:40 PM Owen Lamb  wrote:
> Are there any corpuses (corpori?) of shape-note repertoire that I can 
> cite for my proposal (perhaps what was once used to determine our own 
> set)?


(Re-sending to list without 4 PDF attachments, ~2 MB. Instead, a Google 
Drive link is given below.)


I can't say I've completely understood the glyphs discussion here. And
Carl Sorensen's post linking to the design history of LilyPond shape
notes may be a more concise way to find what you want. But otherwise,
if you want cor... corpor... examples, here you go:

The shape-note tradition comes from Early American music. Some forms
of it are still in current use for new publications.

William Walker, source of the Walker notes
<https://hymnary.org/person/Walker_W>

The Southern Harmony, 1835 (4 shapes)
This is the book that brought us the hymn "Amazing Grace" in its
most-famous form.
<https://en.wikipedia.org/wiki/Southern_Harmony>
<https://archive.org/details/southernharmonymwalk/page/8/mode/1up>

The Christian Harmony, 1867 (7 shapes)
<https://archive.org/details/christianharmony00walk>

Joseph Funk, source of the Funk notes
<https://hymnary.org/person/Funk_J2>

Harmonia Sacra, 1860
<https://en.wikipedia.org/wiki/Harmonia_Sacra>
<https://archive.org/details/newharmoniasacra0funk> (1942 edition)

Jesse B. Aikin, source of the Aiken notes (as misspelled by the
Sibelius software)
<https://en.wikipedia.org/wiki/Jesse_B._Aikin>

The Christian Minstrel, 1853
<https://archive.org/details/christianminstre00aiki_0>

For new publishing, the Aikin shapes have pretty much won out - with
the possible exception of four-shape fa-so-la. I've read that Aikin
had patented his note shapes and threatened to sue the Funk-descended
Ruebush-Kiefer publishing company. As part of the settlement, further
publishing there was done with Aikin's shapes.

The rest of these references come from various periods and branches of
Christianity's Mennonite tradition, of which Funk was a part.

Church and Sunday School Hymnal, 1902
<https://hymnary.org/hymnal/CSSH1902>

Church Hymnal, 1954
<https://archive.org/details/selectionsfromch00scot>

Christian Hymnal, 1959
<https://archive.org/details/christianhymnalc00chur>

The rest are probably too new for archive.org and friends to have
picked up. PDF scans are on Google Drive:

<https://drive.google.com/drive/folders/1Ep-bDPkOK6bH1I8wsODqmrK2SjjLbdCF>

The PDFs were scanned by a phone camera, so the quality isn't the
greatest.

The Mennonite Hymnal, 1969
<https://www.amazon.com/dp/0836181514>

Heartland Hymns, 2005 (Yes, Fraktur in 2005. The
German-speaking Mennonite communities were in the USA since 1710 or so
and didn't get the memo that Antiqua has won. The remaining German
speakers are stuck HARD on Fraktur.)
<https://www.amazon.com/dp/1897080050>

Hymns of the Church, 2011
<https://www.amazon.com/dp/0615364748>

Mountain Laurel Echoes, 2012
<https://prairieviewpress.com/product/mountain-laurel-echoes/>
Prairie View Press is probably the current standard-bearer for this
branch of the shape-note hymnal tradition. I understand they're using
Finale with a custom font.
<https://prairieviewpress.com/typesetting-printing-services/>

If these examples are inadequate, there is lots more
material available.
--
Karlin High
Missouri, USA

Re: GSoC 2020 update, July 18

[Karlin High]

On Sat, Jul 18, 2020, 9:29 PM Owen Lamb  wrote:

> After that, I encoded those glyphs, filling out the rest of the Aikin
> shape-note glyphs while I was at it.
>

Thanks for that! I'm in a community that uses Aikin noteheads to the
exclusion of all else.
--
Karlin High
Missouri, USA

>

Re: NR pdf is larger with current git by 15%

[Karlin High]

On 7/11/2020 4:14 AM, Werner LEMBERG wrote:

OK.  What do you think about opening a ghostscript issue, asking the
developers for an explanation?  Maybe our new method can be slightly
adapted to avoid the size increase.


The question might have to be asked carefully. Ghostscript's Ken Sharp 
in 2017:


"When we have customers wanting to send us 125GB files I have to say 
that a concern over file sizes in the few megabytes seems a bit picky."


<https://lists.gnu.org/archive/html/lilypond-devel/2017-09/msg00131.html>
--
Karlin High
Missouri, USA

Re: Accidentals' font

[Karlin High]

On 7/4/2020 5:55 AM, Paolo Prete wrote:

Just leave Feta as a native font and insert a dummy
wrapper for Gonville in the ./configure. This does not require any
development, nor uniformity in the coding standard and can be easily added
to the source tree.


This discussion is reminding me of the Google Summer of Code project 
proposal, "Support for Style Sheets."


"
LilyPond’s engraving output can be tweaked to the least detail, and one 
important addition in recent years was the ability to use alternative 
notation fonts. It is possible to create reusable modules for “house 
styles”, but this project aims at bringing this to a new level by 
creating a convenient extension package with support for creating, 
applying, and sharing modular style sheets.

"
<http://lilypond.org/google-summer-of-code.html>

That looks to me like there IS community support for having ways to 
change the look-and-feel of LilyPond's output, depending how the 
development goals are defined and presented.

--
Karlin High
Missouri, USA

Re: GSoC 2020: make hangs when making fonts

[Karlin High]

On Mon, Jun 29, 2020, 4:40 PM Thomas Morley  wrote:
> Let me take the opportunity to thank you for your work.
> Although it's a topic where I can't help, I enjoy reading your posts.

Same here. This is exemplary for future GSoC participants.
--
Karlin High
Missouri, USA

Re: GSoC 2020 update, June 15

[Karlin High]

On 6/16/2020 10:26 PM, Owen Lamb wrote:

I wasn't sure what to say as to my "affiliation" with LilyPond and/or GSoC


I've also had that feeling when interacting with other entities on 
behalf of the LilyPond. This has happened maybe twice. In the past, I've 
said something like "I am a volunteer doing research and testing for the 
GNU LilyPond project (lilypond.org, sheet music engraving software) and 
I'm working on [insert topic here.]"

--
Karlin High
Missouri, USA

Re: Remove lily-git?

[Karlin High]

On 6/3/2020 3:14 PM, Jean Abou Samra wrote:

There is a discussion at https://gitlab.com/lilypond/lilypond/-/issues/1012
about the future of lily-git.Basically, I think that it no longer makes 
sense to keep it now that we switched to GitLab.


I remember seeing this thing bring in over 500MB of dependencies on a 
Debian Linux system. And I was thinking, "If that's the only piece of 
TCL in the whole LilyPond ecosystem, there has GOT to be a way to avoid 
having this."

--
Karlin High
Missouri, USA

Re: helping with testing resources

[Karlin High]

On 5/23/2020 1:00 PM, Jonas Hahnfeld wrote:

If you have spare hardware and / or want to help with CI testing


I've built LilyPond from source a number of times, but not to mastery of 
the process. And I have a computer shop and lots of hardware choices, 
and wonder what to set up for best service here. What is usually the 
resource constraint for building LilyPond - CPU, RAM, or disk I/O?

--
Karlin High
Missouri, USA

Re: [RFC] Enabling GitLab CI

[Karlin High]

On Sun, May 17, 2020, 3:11 PM Dan Eble  wrote:

> I might be willing to plug in a cheap, headless computer to crank through
> patches night and day, but probably not if it will upload GBs of results.
>

I can also offer this, from a computer shop with lots of spare hardware and
an unmetered 30 mbps up & down Internet connection. I've done various
distributed computing things like Folding@Home and Storj, and this doesn't
sound much harder.
--
Karlin High
Missouri, USA

>

Re: 2.21.0 Issues all verified!

[Karlin High]

On 5/16/2020 5:28 PM, David Kastrup wrote:

I prefer having an actual issue number for the details for anything of
non-trivial nature.


I don't know how related this is, but GitLab has "Description templates."

<https://docs.gitlab.com/ee/user/project/description_templates.html>

It looks like that could prefill descriptions for issues and merge 
requests with common questions, like does this need a regtest, does it 
need documentation, does it need a "Changes" entry, etc.

--
Karlin High
Missouri, USA

Re: 2.21.0 Issues all verified!

[Karlin High]

On 5/16/2020 5:05 PM, Valentin Villenave wrote:

Well, thanks to you!  And to everybody who gave a hand (Federico,
Karlin, and a few others?).


Thanks also, Carl! I verified exactly one issue, slowly and carefully 
just to learn the process. Last week didn't give me capacity to get much 
beyond that. I expect that an effort like this one is easier to 
crowd-source than things like the Python3 upgrade.


I'm increasingly convinced that group efforts are best raised by giving 
step-by-step instructions. As was seen here, or in Knut Petersen's 
"Please Test GUB" work.

--
Karlin High
Missouri, USA

Re: Verifying issues on Gitlab

[Karlin High]

On 5/11/2020 5:01 PM, Federico Bruni wrote:

If nobody else jumps in, I will probably give up soon.


If someone wants to help, are there step-by-step directions anywhere?
--
Karlin High
Missouri, USA

Re: Google Summer of Code project

[Karlin High]

On 3/13/2020 12:37 AM, Owen Lamb wrote:

I'm interested in applying for a GSoC project.



Any suggestions on where to start / who to talk to?


Thanks for your interest! Urs Liska leads most of the GSOC efforts. He 
follows this list, so you've already found the best place to begin.

--
Karlin High
Missouri, USA

Re: a new way to build LilyPond binary releases

[Karlin High]

On 3/12/2020 8:43 AM, Jonas Hahnfeld wrote:

The mingw executable now also
works under wine, but it'd be great if you could test the full version
(and possibly other large scores) on your system. The link is:
https://github.com/hahnjo/lilypond-binaries/releases/tag/2020-03-12


I'll give it a try, thanks. It may go a day or so until I have a response.
--
Karlin High
Missouri, USA

Re: [RFC] switch to Gerrit

[Karlin High]

On 3/11/2020 3:04 PM, David Kastrup wrote:

Rietveld takes OAuth if I understand correctly.  While I don't really
know whether that is "sufficiently neutral and uncontroversial", it is
something we have depended on for a long time.

So while it is always good to improve, it doesn't sound like it should
be a complete deal breaker.


Good point, don't criticize a proposal for something accepted in the 
status quo.


Although I think Rietveld only takes Google logins and not other OAuth 
options. I seem to remember a potential contributor or two not wanting 
Google accounts and declining to use Rietveld as a result.

--
Karlin High
Missouri, USA

Re: [RFC] switch to Gerrit

[Karlin High]

On Wed, Mar 11, 2020 at 1:19 PM Jonas Hahnfeld via Discussions on
LilyPond development  wrote:
>
> Am Mittwoch, den 11.03.2020, 18:55 +0100 schrieb Han-Wen Nienhuys:
> > Gerrit itself does not have an authentication service. See
> > https://gerrit-review.googlesource.com/Documentation/config-gerrit.html#auth
> >
> > ; I guess in our circumstances, we could do OAuth on top of Google,
> > Github or Facebook accounts.
> >
> > What do you mean with "own authentication service" ?
>
> I mean: Is there a hosted Gerrit that does not require a GitHub
> account? Ideally with the possibility to create an account just for
> that.

If a hosted Gerrit service could use ANY OAuth provider, surely
there's a sufficiently neutral and uncontroversial one somewhere that
works for LilyPond purposes? The big-name tech companies all tend to
have fair numbers of people avoiding them by principle. GNU Social (no
experience, little research) apparently has an Open ID service, which
is similar-but-different than OAuth?
-- 
Karlin High
Missouri, USA

Re: a new way to build LilyPond binary releases

[Karlin High]

On Wed, Mar 11, 2020 at 10:56 AM Jonas Hahnfeld  wrote:
> Please let me know if something doesn't work at all

That sounds like an interesting project. I tested the Windows version,
and it works. I got a PDF from compiling { c' } as a hello-world test.

Now, is this supposed to be a 64-bit application? I can easily get
confused about 64-bit MinGW vs 64-bit applications on it. LilyPond's
32-bit Windows version is susceptible to out-of-memory crashes.

<https://lists.gnu.org/archive/html/lilypond-user/2018-12/msg00408.html>

I tried the test in that thread, on both the official LilyPond 2.19.84
and the binary you shared. Both crash, but with slightly different
error messages:

Offical 2.19.84 says...
Preprocessing graphical objects...terminate called after throwing an
instance of 'std::bad_alloc'
  what():  std::bad_alloc

This binary from GitHub says...
Preprocessing graphical objects...Exception code=0xc005 flags=0x0
at 0x005056A5. Access violation - attempting to read data at
address 0x

The computer running those has Windows 10 Pro 64-bit 1909, Intel Core
i5-3450, 24GB RAM.

LilyPond's 32-bit macOS version was similarly affected, and the
apparent out-of-memory crash was resolved by recent efforts that build
64-bit macOS applications. If the GitHub binary isn't expected to be
64-bit, then this whole issue is probably a distraction at this time
and can be disregarded until attempting 64-bit Windows builds.
-- 
Karlin High
Missouri, USA

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: testing out Docker CI scripts?

[Karlin High]

On 2/22/2020 4:43 PM, David Kastrup wrote:

The download size for the notation manual comes out at 35MB which is
about double than what we had for 2.16.  I actually find that somewhat
irritating.  I'd have to check the old conversations about
extractpdfmark and see whether this is indeed where our change of text
fonts would have placed us even after the extractpdfmark work.  Though I
do seem to remember that the subsetting problem depended on the kind of
font used, and the newer fonts were in a different form.


That reminds me of this thread with lilypond-devel and gs-devel lists, 
and Ken Sharp from Artifex the GhostScript place.


<https://lists.gnu.org/archive/html/lilypond-devel/2017-09/msg00096.html>

Ken Sharp's position was, "Risking incorrect output for the minimal 
benefit of a slightly smaller file seems unwise to me."


Then a large technical discussion ensued about edge cases of PDF font 
embedding.

--
Karlin High
Missouri, USA

Re: What kind of forum are we lacking?

[Karlin High]

On 2/11/2020 10:03 AM, David Kastrup wrote:

There
is nothing wrong per se with the user list, but it's not indexed in a
manner where many of the high quality answers would be accumulated into
wisdom, and it is comparatively rare that something gets condensed into
the somewhat hard to find LSR, and then the educational aspect goes
somewhat missing.  This kind of stuff does not rise to the level where
making a package of the code makes a lot of sense either.

Just throwing this out in case somebody has an idea for such things.


How about if email list traffic was periodically summarized and posted 
to the "Scores of Beauty" blog <https://lilypondblog.org/> ?

--
Karlin High
Missouri, USA

Re: Integration of Guilev2 branches into master

[Karlin High]

On 2/10/2020 3:22 PM, Han-Wen Nienhuys wrote:

How are filenames encoded on Windows?


Not sure which Microsoft document is authoritative, but...

"
NTFS stores file names in Unicode. In contrast, the older FAT12, FAT16, 
and FAT32 file systems use the OEM character set.

"

<https://docs.microsoft.com/en-us/windows/win32/intl/character-sets-used-in-file-names>

--
Karlin High
Missouri, USA

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?]

[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: 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.
<https://www.gnu.org/philosophy/kind-communication.html>.  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 [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: [RFC] switch to GitLab / gitlab.com

[Karlin High]

On 2/7/2020 2:36 AM, Jonas Hahnfeld wrote:

You removed the important part with my answer:

Additionally I'm not (yet) proposing to use MRs to actually
merge the change, that still happens via staging -> master. I only
propose that we use the UI to review the patches, instead of Rietveld.


Apologies. I will be more careful with quote trimming.
--
Karlin High
Missouri, USA

Re: [RFC] switch to GitLab / gitlab.com

[Karlin High]

On 2/7/2020 1:59 AM, Jonas Hahnfeld wrote:

re "single-patch commits": Firstly we currently push multiple commits
from one review (at least Dan and I do), so I don't fully understand
the point.


I probably didn't relate the discussion properly. It had to do with 
commits vs branch merges. This post raises the question:


<https://lists.gnu.org/archive/html/lilypond-devel/2018-04/msg00023.html>

And these seemed like GitLab's answer to it:

<https://docs.gitlab.com/ee/user/project/merge_requests/squash_and_merge.html>

<https://docs.gitlab.com/ee/user/project/merge_requests/fast_forward_merge.html>


Do we need to import from Rietveld? The current issues have links to
the reviews, I think we should just get as much out of SF as possible
and keep the references to the external system.


I think you're right.


I first want to gather consensus that GitLab is really a platform that
(at least) a large part of the community could agree on, for the scoped
purpose of replacing the three tools we currently use.


Very good. Does anyone know of reasons why GitLab would NOT be a good 
fit for Lilypond? I won't know them due to lack of experience, and don't 
feel I have anything further to say here.

--
Karlin High
Missouri, USA

Re: [RFC] switch to GitLab / gitlab.com

[Karlin High]

On Wed, Feb 5, 2020 at 9:09 AM Jonas Hahnfeld  wrote:
> I propose
> to start using GitLab hosted on gitlab.com [4] for all of this:
> Repository, Issues, and Merge Requests (MR) for reviews.

A thread in 2018 explored GitLab's feasibility for LilyPond.

<https://lists.gnu.org/archive/html/lilypond-devel/2018-04/msg00014.html>

Some points made in that discussion was that SourceForge Allura's
issue status tracking features should be equaled or exceeded by any
new system, that single-patch commits are likely preferred to
branch-merge commits, and that ideally the comments for issue-based
discussion could be separated from code-review discussion.

Looking at GitLab's features, their "labels" for status tracking,
single-checkbox "squash merge" setting (can be set by patch submitter
or the person accepting it) and "resolvable discussions" would at
least have a chance of meeting those expectations.

> Using the managed installation on gitlab.com has the advantage that we
> don't need to maintain it. Also future contributors might already have
> an account and can start submitting MRs as they are used to. It should
> make bug reporting more straight-forward too, with the issues right
> next to the repository.

As I recall, hosted GitLab's top-end Gold service, $99 USD per user
per month, is the default for public repositories. At no charge;
they're catering to Open Source projects with that. If a repository is
set to Private, the GitLab price list enters the picture and advanced
features go away until they get some money. To me, that all seems
perfectly sensible. I'm not sure what benefits a self-hosted GitLab
would bring that justify the resources it would need.

> If deemed necessary, it should be possible to transfer existing issues
> from SourceForge via GitLab's API.

Importing as much SourceForge Allura and Rietveld content as possible
would aid future understanding of coding decisions.

It looks like there are Allura import methods available, even if by
way of SourceForge -> GitHub -> GitLab.

<https://github.com/cmungall/gosf2github>
<https://docs.gitlab.com/ee/administration/raketasks/github_import.html>

Rietveld export, I'm not sure about. The only thing I could see would
be scraping the site for Issues that have a CC of
lilypond-devel_gnu.org, unless there are export features I've missed.

> GitLab has a feature called 'Repository mirroring' [8], working in both
> directions. During the switching period, we could maintain Savannah as
> our main repository and let GitLab pull in changes from there. After a
> final cut, GitLab could instead be configured to push master and
> stable/* branches to Savannah.

This would effectively have GitLab be the "staging" branch, then. GNU
Savannah could still be "master."

One possible next step: import to GitLab a LilyPond Git repository,
some SourceForge, and some Rietveld content so people can try it out
and see if it's something acceptable and workable. Unfortunately, as a
tax preparer it's the wrong time of the year for me to help very much.

(CC to Kevin Barry, who mentioned GitLab experience in a separate
thread. My info here is more based on research than experience, so
please call out any misunderstandings I have.)
-- 
Karlin High
Missouri, USA

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

[Karlin High]

On 2/6/2020 2:45 PM, David Kastrup wrote:

I am working on an Email signature that might be helping to convey the
message.


Nice idea, but sometimes drawing attention to a problem only makes 
things worse. How about focusing on the success mode instead of the 
failure mode?


"
I aim to communicate with empathy. Have I failed? Reply "OUCH!"
"

I'm thinking along the lines of the "How's my driving? Call (phone)" 
stickers often seen on long-haul trucks in America.

--
Karlin High
Missouri, USA

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

[Karlin High]

ng.html> I'd like to see that changed so
that anyone with Git commit privileges and a flexible schedule
(allowing doing more Lilypond work if getting more Lilypond pay) could
get their name and brief bio on that page with a paypal.me link or
similar. Changes to the page would go through normal code review,
hardly any new processes would be needed.
-- 
Karlin High
Missouri, USA

Re: packaging lilypond as a docker container?

[Karlin High]

On 1/22/2020 7:23 AM, Jan Nieuwenhuizen wrote:

FWIW, four years ago I created a prototype

 https://lists.gnu.org/archive/html/lilypond-devel/2016-03/msg00204.html


Thanks a lot for the reference, copied to notes for responses to future 
mailing list GUB questions.


Am I understanding it correctly, that the Guix project in the linked 
message successfully used MinGW to make a "Hello, World" command line 
program for Windows?

--
Karlin High
Missouri, USA

Re: GUILE 2/3 and string encoding cost

[Karlin High]

On 1/22/2020 2:07 PM, Han-Wen Nienhuys wrote:

Do we have a standardized test file for benchmarking performance?


I can't speak to "standardized," but I do remember some threads that had 
benchmarking going on by various users, using large LilyPond projects.


The Robert Carver "Missa Dum Sacrum Mysterium" from Vaughan McAlley. 
(114 pages)


<https://lists.gnu.org/archive/html/lilypond-user/2016-11/msg00700.html>

And the Heinrich Schütz "Schwanengesang" Psalm 119 from Brent Annable. 
(194 pages)


<https://lists.gnu.org/archive/html/lilypond-user/2018-05/msg00211.html>
--
Karlin High
Missouri, USA

Re: packaging lilypond as a docker container?

[Karlin High]

On 1/22/2020 4:36 AM, David Kastrup wrote:

I have no experience with Docker and containers.


The one time I tried Docker on Windows, I was put off by the setup 
effort that seemed intended to initiate the user into an entire 
worldview and ecosystem. Docker seemingly didn't provide an easy way to 
download their software without creating an account at their place 
first. That's behavior I expect from Google, Apple, and Microsoft, not 
an open-source project. After some digging, I think there was a direct 
download link somewhere, given in a forum post. But then after the 
install, Docker seemed pretty non-functional until I logged into my 
local software with a Docker account.


Okay, okay... I sort-of get why they're doing this, I can deal with it.

BUT THEN the command-line window for the Docker container kept going 
non-responsive on me, needing a kill with Windows Task Manager. Research 
turned up the sorts of sprawling forum threads that I'm used to seeing 
for failed Windows updates. Lots of suggestions, most aren't helping, 
the problem seemed like an unsolved mystery. And the answer that seemed 
most promising would have been non-trivial to implement.


At that point, I retreated back to VirtualBox, Hyper-V, and Windows 
Subsystem for Linux. I was getting too far removed from LilyPond to not 
feel like I was pursuing a dead end.


IN DEFENSE OF DOCKER, all of that is from memory and I can't recover the 
exact details without research. I'm sure my experience is not 
representative and that Docker is actually great. No way could it have 
as large of a following as it does otherwise. I'm just unfortunate to 
have never seen Docker's best stuff or completely understand why I need 
it. Someday™ I plan to try again.


But the conclusion I came to is that setup effort for Docker on Windows 
is not much different than for VirtualBox. (Unless, of course, someone's 
going for the full VirtualBox experience with host-guest shared 
clipboard like in that other thread right now. I never got that working 
on LilyDev, either, making do with network file shares and such to move 
things to and from the VM.)


Docker on Windows is apparently changing a lot, too. Windows Subsystem 
for Linux is now going for a full Linux kernel, and allowing Linux file 
access and execution from the Windows environment containing it. Haven't 
checked for a while, not sure where Microsoft is at with that effort, 
but Docker seems to be building on it.


<https://docs.docker.com/docker-for-windows/wsl-tech-preview/>
--
Karlin High
Missouri, USA

Re: guile-3.0 and LilyPond - here: /input/regression/context-defaultchild-cycle.ly fails

[Karlin High]

On 1/21/2020 5:10 PM, Thomas Morley wrote:

Afterwards I've got a successful ´make´ with current LilyPond-master.


So it's a functional LilyPond with guile-3.0? How does it perform if fed 
something big? I'm thinking of the thread on benchmarking that used 
Vaughan McAlley's MDSM.ly, the Robert Carver "Missa Dum sacrum mysterium."


<https://lists.gnu.org/archive/html/lilypond-user/2016-11/msg00700.html>
--
Karlin High
Missouri, USA

Re: packaging lilypond as a docker container?

[Karlin High]

On 1/21/2020 1:49 AM, Han-Wen Nienhuys wrote:

if GUB is used, who is maintaining and/or working on it?


Almost exactly a year ago, there was a sizable "Please test gub" effort 
initiated by Knut Petersen.


<https://lists.gnu.org/archive/html/lilypond-devel/2019-01/msg00221.html>

Clear instructions were given for exactly how to test GUB, and just that 
thread seems to have involved about 16 people.


More recently, it looks like Jonas Hahnfeld's work with Python 3 
migration involved quite a number of changes to GUB.


From the notes I've kept, Jan Nieuwenhuizen proposed replacing GUB with 
something based on Guix.


<https://lists.gnu.org/archive/html/lilypond-user/2016-09/msg00690.html>

That idea was mentioned a few times since, but I can't recall if 
GUB-replacement discussions have moved beyond that or not.

--
Karlin High
Missouri, USA

Re: packaging lilypond as a docker container?

[Karlin High]

On 1/20/2020 4:05 PM, Carl Sorensen wrote:

If the process of making the Docker application would also allow a simple set 
up for a build environment in non-Linux machines, I think that would be a huge 
win.


There already is a LilyDev Docker image.

<https://github.com/fedelibre/LilyDev/tree/master/docker>

I tried it once, but was unable to get it working. It was my first and 
only experience with Docker, so that's probably my fault. I was also 
unmotivated to persevere due to having LilyDev environments running on 
various other VM things. (VirtualBox, Microsoft Hyper-V, Windows 
Subsystem for Linux, etc)

--
Karlin High
Missouri, USA

Re: github mirror of lilypond?

[Karlin High]

On 1/18/2020 4:59 AM, Jonas Hahnfeld via Discussions on LilyPond 
development wrote:

I strongly dislike Gerrit, it's really hard to learn and even after
some time I still can't figure out how to use it correctly.


This topic is outside my expertise. But I understood that Gerrit and 
Rietveld are both descendants of Google's proprietary internal-use 
Mondrian code review tool.


<https://www.gerritcodereview.com/about.html>

I see quite a few patches lately that show Jonas Hahnfeld as the author...

<https://codereview.appspot.com/user/hahnjo>
<https://git.savannah.gnu.org/cgit/lilypond.git/log/?qt=author=Jonas+Hahnfeld>

...so I'm wondering if Rietveld has you suffering in silence ;) or if 
the fork and rewrite mentioned on that Gerrit "about" page has greatly 
diverged the user experiences of these respective products?

--
Karlin High
Missouri, USA

Re: github mirror of lilypond?

[Karlin High]

There was a thread from April 2018 that explored GitLab's suitability
for LilyPond.

<https://lists.gnu.org/archive/html/lilypond-devel/2018-04/msg00014.html>

As I recall from that discussion, most of the first-to-mind concerns
about available features and workflows seemed like things GitLab could
handle.

And pace the FSF, GitLab now has License Compliance features of some sort.
<https://docs.gitlab.com/ee/user/application_security/license_compliance/>
-- 
Karlin High
Missouri, USA

Re: github mirror of lilypond?

[Karlin High]

On 1/18/2020 5:00 PM, David Kastrup wrote:

GitHub is putting our eggs in Microsoft's basket.  Not too enthused
about that idea.


Apparently GNU has some say as well in the matter of repo hosting choice.

<https://www.gnu.org/software/repo-criteria.html>

They also have a report card for various repo hosting services, but it's 
dated to 2016.


<https://www.gnu.org/software/repo-criteria-evaluation.html>
--
Karlin High
Missouri, USA

Re: macOS 64-bit

[Karlin High]

On Sat, Jan 11, 2020 at 1:32 PM Marnen Laibow-Koser 
wrote:

> New version is now available at
>
> https://bintray.com/marnen/lilypond-darwin-64/download_file?file_path=lilypond-2.19.83.build20200111.1-darwin-64.tar.gz
> <https://bintray.com/marnen/lilypond-darwin-64/download_file?file_path=lilypond-2.19.83.build20200111.1-darwin-64.tar.gz(sha-256>


I can report a success on a MacBook Air (mid 2012) running macOS Mojave
10.14.6. Way to go, Marnen!

I noticed the same "unable to revert mtime" message reported earlier, but
it seems that was only on first run.
-- 
Karlin High
Missouri, USA

Re: MacOS 64bit installer

[Karlin High]

On 10/31/2019 1:05 PM, Malte Meyn wrote:
I would need to know that people can actually use the program without 
emulators or other additional software on their own computers


Would any of the online options fit your use case?

<http://lilybin.com/>
<https://www.hacklily.org/>

--
Karlin High
Missouri, USA

Re: gub targets + binary packages

[Karlin High]

On 10/22/2019 1:53 PM, Jonas Hahnfeld wrote:

(Does GUB really produce a LilyPond.app?)


Yes, within a tar.bz2 archive.

Anyway, right now GUB is not using Python 3 for building LilyPond, so 
you need to manually copy the built Python 3.7.4 from GUB to your Mac.



Okay, thanks for the clarification. I'll look at that next.



./python --version

...and it said...

Python 2.6.6


So yeah, that's not correct. But until now GUB should have built Python 
2.4.5, so where is version 2.6.6 coming from?



Unless a long-time LilyPond developer can answer, we won't easily find out.

Now, my knowledge of LilyPond is pretty variable. Especially the inner 
workings of the macOS distribution. 

--
Karlin High
Missouri, USA

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

Re: gub targets + binary packages

[Karlin High]

On Mon, Oct 21, 2019 at 11:39 AM Jonas Hahnfeld  wrote:

> Just to double-check: You built on Linux, copied the binaries to macOS and
> were able to execute them? Because as far as I understand, releases are not
> built natively right now...
>
>
All correct. GUB on Ubuntu on VirtualBox on Windows 7.

if python -V doesn't crash and prints 3.7.4 I would be happy for now.
>

I haven't done much yet. I went to this file path...

/Applications/LilyPond.app/Contents/MacOS

...and then ran the command...

./python --version

...and it said...

Python 2.6.6

Now, my knowledge of LilyPond is pretty variable. Especially the inner
workings of the macOS distribution. Maybe I'm executing the wrong Python?
-- 
Karlin High
Missouri, USA
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: gub targets + binary packages

[Karlin High]

On 10/18/2019 4:00 AM, Jonas Hahnfeld via lilypond-devel wrote:

I managed to get Python 3.7.4 integrated into gub.



Would be great if somebody could check
that the binaries actually work on macOS 10.14.



I cloned <https://github.com/hahnjo/gub.git> and checked out the python3 
branch. GUB built the macOS binaries, and I can confirm that they work 
on macOS 10.14.6.


Now, what's a good test to confirm that it's got a good Python 3.7.4? 
Once I have that verified, I'll post the steps of what I did.

--
Karlin High
Missouri, USA

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

Re: lilypond does not work with Mac OS 10.15 (Catalina)

[Karlin High]

On 10/8/2019 2:57 AM, Maria-Angeles Casares-de-Cal via lilypond-devel wrote:

Will we have news soon of the new Lilypond (64 bits) to work in macOS 10.15?

We hope you can solve this issue. It is worth the work of updating Lilypond so 
that it can be used from now on the new Apple computers and the old ones that 
have been updated to the new operating system.


Unfortunately, there is currently no clear path to making a 64-bit macOS 
distribution of LilyPond. There is a conflict between Apple's Software 
License Agreement for their XCode developer tools and the GNU General 
Public License that LilyPond uses. This has been discussed at length 
elsewhere on LilyPond email lists, references can be given if they'd be 
helpful for you.

--
Karlin High
Missouri, USA

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

Re: LilyPond's gs console output on windows

[Karlin High]

On Thu, Aug 22, 2019 at 2:36 PM David Kastrup  wrote:
>
> Werner LEMBERG  writes:
>
> >> I know wonder whether this problem is
> >>
> >>   (1) limited to the gs program that comes with lilypond,
> >>   (2) related to the way gub is compiling gs,
> >>   (3) connected to changes in the Windows 10 console,
> >>   (4) or whether this a generic issue with gs itself, probably fixed
> >>   in newer gs versions.
> >>
> >> If we will have this behaviour with the next gub build also, I
> >> suggest that it gets documented.
>
> Didn't Windows require something like rungs or mgs or gswin32c or so?

I have LilyPond 2.19.83 on Windows 7 Pro 64-bit SP1 and Windows 10 Pro
64-bit version 1903.

Both of them behave the same way on Windows console: output a blank
line and exit.

Windows 10 does the same thing on PowerShell.

But, with Windows Subsystem for Linux, one can type "bash" in the
console and it switches to a bash environment. That seems to execute
things as expected. I haven't tried Git on Windows' bash shell.

Now, about GhostScript helper programs:

C:\Program Files (x86)\LilyPond\usr\bin>dir *gs* /B
gs-9.21.dll
gs-9.dll
gs.dll
gs.exe
gsettings.exe
gspawn-win32-helper-console.exe
gspawn-win32-helper.exe
gsx.exe

I also have PDF Creator (from pdfforge.org) which has its own GhostScript.

C:\Program Files\PDFCreator\Ghostscript\Bin>dir /B
gsdll32.dll
gsdll32.lib
gswin32c.exe

C:\Program Files\PDFCreator\Ghostscript\Bin> gswin32c.exe
GPL Ghostscript 9.25 (2018-09-13)
Copyright (C) 2018 Artifex Software, Inc.  All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
GS>

Hopefully that was helpful. I can do further testing if requested.
-- 
Karlin High
Missouri, USA

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

Re: development stalled

[Karlin High]

On 8/13/2019 4:42 PM, David Kastrup wrote:

"Frank Bryce"  writes:


Unfortunately Im not a programmer so I dont know how to
help.


I am not enthused about our current delays 


David K. or other contributors, what would you suggest is a good 
LilyPond development area for beginners to work on?


The documentation seems often suggested, but in my experience it mostly 
looks good already (the English version, anyway) and I still have the 
same question: what needs work?


The Contributor Guide suggests searching the issue tracker for issues 
labeled "frog," but the most recent one is from 2014. Would this still 
be a good approach?

--
Karlin High
Missouri, USA

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