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

Am Donnerstag, den 06.02.2020, 21:34 -0600 schrieb Karlin High: > On Wed, Feb 5, 2020 at 9:09 AM Jonas Hahnfeld < > hah...@hahnjo.de > > wrote: > > I propose > > to start using GitLab hosted on gitlab.com [4] for all of this: > > Repository, Issues, and Merge

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

Am Freitag, den 07.02.2020, 02:30 -0600 schrieb 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

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

Am Freitag, den 07.02.2020, 10:36 +0100 schrieb Urs Liska: > I think this is an extremely good point. Being able to squash upon merge, > with or without merge commit, in combination with being able to automate that > as a staging branch with final test, seems a very good idea to me. Possibly in

Re: PATCHES - Countdown for February 4th

Am Freitag, den 07.02.2020, 14:47 +0100 schrieb Han-Wen Nienhuys: > > > On Wed, Feb 5, 2020 at 9:20 AM Han-Wen Nienhuys wrote: > > > > On Wed, Feb 5, 2020 at 9:14 AM Jonas Hahnfeld wrote: > > > Am Dienstag, den 04.02.2020, 23:14 +0100 schrieb Han-Wen Nienhuys:

GUILE2: softcode GC environment tuning (issue 563500045 by hanw...@gmail.com)

LGTM https://codereview.appspot.com/563500045/

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

The approach sounds good to me. I can confirm that this works on my system and the runtime is pretty good. Please readd the autoconf logic to detect bdw-gc. FWIW I tried to research on the internals of GC. I found the following statement that decides whether to collect or just expand the heap: htt

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

On 2020/02/09 09:36:40, hanwenn wrote: > On Sun, Feb 9, 2020 at 10:25 AM wrote: > > FWIW I tried to research on the internals of GC. I found the following > > statement that decides whether to collect or just expand the heap: > > https://github.com/ivmai/bdwgc/blob

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

LGTM, thanks for this clearly documented change! https://codereview.appspot.com/561390043/

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

Am Freitag, den 07.02.2020, 16:28 +0100 schrieb Federico Bruni: > Il giorno ven 7 feb 2020 alle 10:33, Federico Bruni > < > f...@inventati.org > > ha scritto: > > I guess that the quality of the issue migration might influence the > > decision. > > I forgot I already investigated the SF -> GitLa

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

Am Sonntag, den 09.02.2020, 22:50 +0100 schrieb Jonas Hahnfeld: > Am Freitag, den 07.02.2020, 16:28 +0100 schrieb Federico Bruni: > > Il giorno ven 7 feb 2020 alle 10:33, Federico Bruni > > < > > f...@inventati.org > > > > > ha scritto: > > > I gue

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

Am Sonntag, den 09.02.2020, 23:03 +0100 schrieb David Kastrup: > Jonas Hahnfeld < > hah...@hahnjo.de > > writes: > > > Am Freitag, den 07.02.2020, 16:28 +0100 schrieb Federico Bruni: > > > Il giorno ven 7 feb 2020 alle 10:33, Federico Bruni > > > &l

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

Am Sonntag, den 09.02.2020, 23:34 +0100 schrieb Federico Bruni: > Il giorno dom 9 feb 2020 alle 22:50, Jonas Hahnfeld < > hah...@hahnjo.de > > > ha scritto: > > Thanks for sharing! I put together a simplistic script to create a > > proof-of-concept: > >

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

Am Montag, den 10.02.2020, 07:58 +0100 schrieb Han-Wen Nienhuys: > Very nice. Why is the project/user called lilypond-issues? Because I don't want to to do this with my personal account. First I created a personal repo hahnjo/lilypond and granted lilypond-issues access to it. That doesn't work unf

input/regression/multi-measure-rest-reminder: a demo of user-defined grobs (issue 557380044 by hanw...@gmail.com)

Thanks for providing a test. Not able to run it right now, maybe tomorrow. https://codereview.appspot.com/557380044/diff/563510046/input/regression/multi-measure-rest-reminder.ly File input/regression/multi-measure-rest-reminder.ly (right): https://codereview.appspot.com/557380044/diff/563510046

Re: input/regression/multi-measure-rest-reminder: a demo of user-defined grobs (issue 557380044 by hanw...@gmail.com)

On 2020/02/10 21:28:53, hahnjo wrote: > Thanks for providing a test. Not able to run it right now, maybe tomorrow. Looks good to me (modulo the nits), see https://sourceforge.net/p/testlilyissues/issues/5747/ for how the output looks like. https://codereview.appspot.com/557380044/

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

Am Montag, den 10.02.2020, 09:20 +0100 schrieb Jonas Hahnfeld: > Am Sonntag, den 09.02.2020, 23:34 +0100 schrieb Federico Bruni: > > Il giorno dom 9 feb 2020 alle 22:50, Jonas Hahnfeld < > > hah...@hahnjo.de > > > > > > ha scritto: > > > Thanks for s

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

Am Dienstag, den 11.02.2020, 13:48 +0100 schrieb Federico Bruni: > Il giorno mar 11 feb 2020 alle 13:18, Jonas Hahnfeld < > hah...@hahnjo.de > > > ha scritto: > > > > Another shortcoming is that links to other issues are broken > > > > (transformed i

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

Am Dienstag, den 11.02.2020, 14:16 +0100 schrieb David Kastrup: > Jonas Hahnfeld < > hah...@hahnjo.de > > writes: > > > Am Montag, den 10.02.2020, 09:20 +0100 schrieb Jonas Hahnfeld: > > > Am Sonntag, den 09.02.2020, 23:34 +0100 schrieb Federico Bruni: > >

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

Am Dienstag, den 11.02.2020, 14:27 +0100 schrieb David Kastrup: > Jonas Hahnfeld < > hah...@hahnjo.de > > writes: > > > Am Dienstag, den 11.02.2020, 13:48 +0100 schrieb Federico Bruni: > > > Il giorno mar 11 feb 2020 alle 13:18, Jonas Hahnfeld < > >

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

Am Dienstag, den 11.02.2020, 14:37 +0100 schrieb Jonas Hahnfeld: > Am Dienstag, den 11.02.2020, 14:27 +0100 schrieb David Kastrup: > > Jonas Hahnfeld < > > hah...@hahnjo.de > > > > > writes: > > > Am Dienstag, den 11.02.2020, 13:48 +0100 schrieb Federic

Re: Drop support for multiple configurations (issue 581630043 by jonas.hahnf...@gmail.com)

Reviewers: lemzwerg, carl.d.sorensen_gmail.com, hanwenn, Message: On 2020/02/12 20:45:31, hanwenn wrote: > https://codereview.appspot.com/581630043/diff/563520043/Documentation/included/compile.itexi > File Documentation/included/compile.itexi (left): > > https://codereview.appspot.com/581630043/

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

https://codereview.appspot.com/557330043/diff/579310044/configure.ac File configure.ac (left): https://codereview.appspot.com/557330043/diff/579310044/configure.ac#oldcode42 configure.ac:42: GUILEv2=no Is this meant to be part of this patch? I'm all in for requiring / defaulting to Guile 2.2 onc

Add a RAII wrapper for extracting FT_Face from PangoFcFont (issue 549560043 by hanw...@gmail.com)

LGTM https://codereview.appspot.com/549560043/

Re: Make Pango >= 1.36 mandatory. (issue 565660044 by hanw...@gmail.com)

LGTM, thanks for getting rid of the old code! https://codereview.appspot.com/565660044/

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

On 2020/02/13 13:34:59, hanwenn wrote: > [...] > > https://codereview.appspot.com/557330043/diff/579310044/lily/include/overlay-string-port.hh > File lily/include/overlay-string-port.hh (right): > > https://codereview.appspot.com/557330043/diff/579310044/lily/include/overlay-string-port.hh#newcod

Re: Generate dependency files with Clang (issue 555300044 by jonas.hahnf...@gmail.com)

Reviewers: lemzwerg, hanwenn, Message: On 2020/02/16 21:24:59, dak wrote: > It's also the only thing that we needed a C compiler (rather than C++) for. > Well, at least regarding native compilation. GUB of course needs a C compiler > for bootstrapping the cross-building environment. But that do

Re: Generate dependency files with Clang (issue 555300044 by jonas.hahnf...@gmail.com)

On 2020/02/17 07:18:25, hahnjo wrote: > On 2020/02/16 21:25:42, hanwenn wrote: > > please, for the love of god, do not use automake. > > > > It is slow and arcane, and generally a complete PITA to work with. We created > > stepmake after fighting with automake for a while. > > Do you have concre

Re: 2.20 and 2.21 release plans

Am Montag, den 17.02.2020, 13:25 +0100 schrieb David Kastrup: > Ok, I think 2.20 is basically done and we should push it out by the end > of this week. This leaves a few days for the translation team to catch > up with the current state. Wohoo! > [...] > > What does this mean for 2.21.0? I thi

Re: 2.20 and 2.21 release plans

Am Montag, den 17.02.2020, 14:59 +0100 schrieb David Kastrup: > Jonas Hahnfeld < > hah...@hahnjo.de > > writes: > > > Am Montag, den 17.02.2020, 13:25 +0100 schrieb David Kastrup: > > > Ok, I think 2.20 is basically done and we should push it out by the end >

Re: Staging broken.

Am Dienstag, den 18.02.2020, 14:19 +0100 schrieb David Kastrup: > James < > pkx1...@posteo.net > > writes: > > Actually if you look on the tracker you'll see that I wrote > > > > 'Passes make, make test-baseline, and a full make doc.' > > > > This is probably my fault misunderstanding what can an

Re: Staging broken.

Am Mittwoch, den 19.02.2020, 09:34 +0100 schrieb David Kastrup: > Jonas Hahnfeld < > hah...@hahnjo.de > > writes: > > > Am Dienstag, den 18.02.2020, 14:19 +0100 schrieb David Kastrup: > > > The procedure for a patch would be > > > > > > git

Let flex handle the input stack (issue 563560043 by jonas.hahnf...@gmail.com)

Reviewers: , https://codereview.appspot.com/563560043/diff/567260043/aclocal.m4 File aclocal.m4 (right): https://codereview.appspot.com/563560043/diff/567260043/aclocal.m4#newcode556 aclocal.m4:556: # check for yyFlexLexer.yypop_buffer_state () since flex 2.5.29 Random thought: Do we want to che

Implement Grob::event_cause, Grob::ultimate_event_cause (issue 559500043 by d...@gnu.org)

LGTM, nice cleanup https://codereview.appspot.com/559500043/

Re: Staging broken.

Am Mittwoch, den 19.02.2020, 17:30 +0100 schrieb David Kastrup: > David Kastrup < > d...@gnu.org > > writes: > > > Han-Wen Nienhuys < > > hanw...@gmail.com > > > writes: > > > > > On Wed, Feb 19, 2020 at 9:19 AM Han-Wen Nienhuys < > > > hanw...@gmail.com > > > > wrote: > > > > > > > > +// Necess

Re: Staging broken.

Am Donnerstag, den 20.02.2020, 20:21 +0100 schrieb David Kastrup: > Jonas Hahnfeld < > hah...@hahnjo.de > > writes: > > > Am Mittwoch, den 19.02.2020, 17:30 +0100 schrieb David Kastrup: > > > David Kastrup < > > > d...@gnu.org > > > &

Re: Let flex handle the input stack (issue 563560043 by jonas.hahnf...@gmail.com)

https://codereview.appspot.com/563560043/diff/567260043/aclocal.m4 File aclocal.m4 (right): https://codereview.appspot.com/563560043/diff/567260043/aclocal.m4#newcode556 aclocal.m4:556: # check for yyFlexLexer.yypop_buffer_state () since flex 2.5.29 On 2020/02/20 23:05:46, hanwenn wrote: > On 20

Re: Let flex handle the input stack (issue 563560043 by jonas.hahnf...@gmail.com)

On 2020/02/21 08:21:07, lemzwerg wrote: > > > could we check the version number instead? > > > > No, the header doesn't have version information. > > So we need both a recent flex program and a recent flex header, right? For the > former a version test would be easy, see > > http://git.savannah

Re: Accept GUILE 2 without extra configure options (issue 569390043 by hanw...@gmail.com)

guile-config since 2.0 has the following comment: "This script has been deprecated. Just use pkg-config." Mabye it makes sense to completely turn to pkg-config? My system has $ ll /usr/lib/pkgconfig/guile-* -rw-r--r-- 1 root root 453 11. Jan 2019 /usr/lib/pkgconfig/guile-1.8.pc -rw-r--r-- 1 root

Re: Accept GUILE 2 without extra configure options (issue 569390043 by hanw...@gmail.com)

On 2020/02/21 16:22:52, lemzwerg wrote: > > Mabye it makes sense to completely turn to pkg-config? > > Sounds sensible. In particular, it eases cross-compilation. Reading my mind ;-) On 2020/02/21 16:25:02, dak wrote: > > So this would also work for Guile 1.8 (which should either be preferred a

Re: Accept GUILE 2 without extra configure options (issue 569390043 by hanw...@gmail.com)

On 2020/02/21 16:36:57, hanwenn wrote: > On 2020/02/21 16:02:14, hahnjo wrote: > > guile-config since 2.0 has the following comment: > > "This script has been deprecated. Just use pkg-config." > > > > Mabye it makes sense to completely turn to pkg-config? My system has $ ll > > /usr/lib/pkgconfig/

Re: Accept GUILE 2 without extra configure options (issue 569390043 by hanw...@gmail.com)

On 2020/02/21 17:08:34, hanwenn wrote: > On 2020/02/21 16:39:20, hahnjo wrote: > > $ pkg-config --cflags guile-1.8 > > -D_FORTIFY_SOURCE=2 -pthread > > Done. (It's ugly to put CFLAGS into the LIBS variable, but it works) Uh, we don't add CFLAGS when linking? That sounds ... dangerous. https://co

Re: Accept GUILE 2 without extra configure options (issue 569390043 by hanw...@gmail.com)

A few nits on m4 escapes, but otherwise LGTM - works very well on my system with three versions of Guile installed! https://codereview.appspot.com/569390043/diff/571710044/aclocal.m4 File aclocal.m4 (right): https://codereview.appspot.com/569390043/diff/571710044/aclocal.m4#newcode693 aclocal.m4

Re: Accept GUILE 2 without extra configure options (issue 569390043 by hanw...@gmail.com)

https://codereview.appspot.com/569390043/diff/571710044/aclocal.m4 File aclocal.m4 (right): https://codereview.appspot.com/569390043/diff/571710044/aclocal.m4#newcode697 aclocal.m4:697: if [[ -z "$GUILE_FLAVOR" ]] ; then You can actually make this a little nicer by putting the next check in the

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

The current change leaves a few questions unanswered: What should lilypond-book do if there happens to be an old .lock file around? Right now, it just sits there and does nothing which is not obvious to the user. Also, what's the benefit of doing this? Is it worth doing in terms of runtime? http

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

On 2020/02/23 15:54:54, hanwenn wrote: > I think this is worth it because it simplifies the build system, and puts the > locking in the place where we actually access the resource. Let me disagree: It complicates lilypond-book with something that no (external) user of the script cares about. So IM

Cleanup lilypond-book source (issue 583570043 by hanw...@gmail.com)

LGTM, thanks for the cleanup! In the future we might even consider putting all the book_*.py files into a directory / package. That should make it more natural to import them. https://codereview.appspot.com/583570043/diff/545630043/python/book_base_test.py File python/book_base_test.py (right):

Re: Cleanup lilypond-book source (issue 583570043 by hanw...@gmail.com)

LGTM https://codereview.appspot.com/583570043/

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

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) You should delete these lines completely.

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

On 2020/02/25 08:09:21, hanwenn wrote: > Jonas, did you want to have another look? Yes, hopefully later today, no guarantee though https://codereview.appspot.com/555360043/

Re: please avoid tabs

Am Dienstag, den 25.02.2020, 11:13 +0100 schrieb Werner LEMBERG: > Folks, > > > something that can be easily missed while doing reviews with Rietveld: > Since a long time we avoid tabs if possible. > > > Werner > > > PS: I've cleaned up `configure.ac` and `aclocal.m4` in the staging >

Re: Replace file-cookie and memory-stream (issue 581700043 by jonas.hahnf...@gmail.com)

https://codereview.appspot.com/581700043/diff/569410044/lily/ttf.cc File lily/ttf.cc (right): https://codereview.appspot.com/581700043/diff/569410044/lily/ttf.cc#newcode95 lily/ttf.cc:95: On 2020/02/25 17:53:20, lemzwerg wrote: > I think the second empty line can be removed. Done. https://cod

aclocal.m4 (STEPMAKE_GUILE_DEVEL): Fix logic and improve diagnostics. (issue 573570044 by lemzw...@googlemail.com)

https://codereview.appspot.com/573570044/diff/559570043/aclocal.m4 File aclocal.m4 (right): https://codereview.appspot.com/573570044/diff/559570043/aclocal.m4#newcode683 aclocal.m4:683: AC_MSG_RESULT([no]) Do we really want that many "no"s in the output https://codereview.appspot.com/573570044/

Re: aclocal.m4 (STEPMAKE_GUILE_DEVEL): Fix logic and improve diagnostics. (issue 573570044 by lemzw...@googlemail.com)

On 2020/02/25 19:50:34, lemzwerg wrote: > > Do we really want that many "no"s in the output > > Currently, you get this (in one long line): > > checking for guile-1.8 >= 1.8.2... checking for guile-2.2 >= 2.2.0... checking > for guile-2.0 >= 2.0.7... Package guile-2.0 was not found in the pkg-c

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

So I can see a consistent improvement by ~40s for 'make -j4 CPU_COUNT=4 test', going down from ~4m to 3m30s. The patch at https://codereview.appspot.com/547680043 explains that this is due to parallelism in input/regression/lilypond-book/. I see no influence on 'make -j4 CPU_COUNT=4 doc', staying f

Forge Software Evaluation by FSF

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

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

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.

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

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

Re: Forge Software Evaluation by FSF

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

Re: Forge Software Evaluation by FSF

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: > > ht

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

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

Re: Fixes for cross-compilation to x86_64-w64-mingw32 (issue 579340043 by jonas.hahnf...@gmail.com)

Reviewers: lemzwerg, benko.pal, Message: On 2020/02/28 09:23:44, benko.pal wrote: > it may not matter, but actually long is 32 bit, void * is 64 bit on current > native 64 bit platforms too, I believe. Only mingw, on Linux long is 64 bit AFAICT. See also https://stackoverflow.com/a/384672/1060694

Re: Fixes for cross-compilation to x86_64-w64-mingw32 (issue 579340043 by jonas.hahnf...@gmail.com)

https://codereview.appspot.com/579340043/diff/571760043/lily/accidental-engraver.cc File lily/accidental-engraver.cc (left): https://codereview.appspot.com/579340043/diff/571760043/lily/accidental-engraver.cc#oldcode338 lily/accidental-engraver.cc:338: (long) trans); On 2020/02/28 09:54:16, hanw

Re: Fixes for cross-compilation to x86_64-w64-mingw32 (issue 579340043 by jonas.hahnf...@gmail.com)

On 2020/02/28 10:02:46, hanwenn wrote: > https://codereview.appspot.com/579340043/diff/571760043/lily/accidental-engraver.cc > File lily/accidental-engraver.cc (left): > > https://codereview.appspot.com/579340043/diff/571760043/lily/accidental-engraver.cc#oldcode338 > lily/accidental-engraver.cc:3

output-distance: treat non-existent files as empty string (issue 583590043 by hanw...@gmail.com)

LGTM https://codereview.appspot.com/583590043/

Re: #5703 Run scripts/auxiliar/fixcc.py imminent

Am Samstag, den 29.02.2020, 02:36 +0100 schrieb David Kastrup: > Hi, I've run scripts/auciliar/fixcc.py on the stable branch now. So > that it is reasonably easy to cherry-pick new commits from master into > the stable branch, it would make sense doing that in staging/master as > well. This is a

Re: Fixes for cross-compilation to x86_64-w64-mingw32 (issue 579340043 by jonas.hahnf...@gmail.com)

On 2020/02/29 10:37:28, hahnjo wrote: > Rename DATADIR to CONFIG_DATADIR I need this additional fix to make it work with Guile 2.2 https://codereview.appspot.com/579340043/

Re: aclocal.m4: Remove STEPMAKE_LIBTOOL. (issue 571790044 by lemzw...@googlemail.com)

LGTM, thanks. May I ask to fast-track this cleanup? AFAICS this is the only reference to STEPMAKE_LIBTOOL and I have some further cleanups (IEEE-conformance compiler flags, STEPMAKE_DLOPEN, STEPMAKE_MAN, and --with-lang=LANG) that would conflict. I couldn't push this earlier because of conflicts w

Re: 2.21.0 release plans and considerations

Hi David, Am Sonntag, den 01.03.2020, 14:28 +0100 schrieb David Kastrup: > Recently I asked the list to consider not putting any changes in master > right now where we'd like to be able to figure out whether they are > "introduced after 2.21.0" or not. At least with regard to build system > chang

Re: 2.21.0 release plans and considerations

Am Sonntag, den 01.03.2020, 15:39 +0100 schrieb David Kastrup: > > But fortunately, we are now at the point where 2.20 _and_ 2.21 are going > to be a thing rather soon. Assuming that things like the Python3 > migration don't cause more of a standstill for 2.21.0 than we imagine, > but then one ca

Re: mf: use python scripting for generating Emmentaler fonts (issue 553580043 by hanw...@gmail.com)

On 2020/02/29 22:53:43, lemzwerg wrote: > > > Can we assume that FontForge's python support and is > > > always enabled? Shall we check this? > > > > the FF page doesn't say that python is optional. > > It's a build option in both the old (configure) and new (cmake) builds... GUB doesn't have i

Re: 2.21.0 release plans and considerations

Am Montag, den 02.03.2020, 10:48 +0100 schrieb Jonas Hahnfeld: > Am Sonntag, den 01.03.2020, 15:39 +0100 schrieb David Kastrup: > > > > But fortunately, we are now at the point where 2.20 _and_ 2.21 are going > > to be a thing rather soon. Assuming that things like the

Re: 2.21.0 release plans and considerations

Am Montag, den 02.03.2020, 19:38 +0100 schrieb David Kastrup: > Jonas Hahnfeld < > hah...@hahnjo.de > > writes: > > > Am Montag, den 02.03.2020, 10:48 +0100 schrieb Jonas Hahnfeld: > > > Am Sonntag, den 01.03.2020, 15:39 +0100 schrieb David Kastrup: > >

Re: Does the following Python error in the musicxml tests ring a bell?

Am Montag, den 02.03.2020, 19:53 +0100 schrieb David Kastrup: > I am currently trying to merge translations and master. make test gives > me > > [...] > Making input/regression/lilypond-book/out-test/html-musicxml-file.html < htmly > langdefs.py: warning: lilypond-doc gettext domain not found. >

Re: Does the following Python error in the musicxml tests ring a bell?

Am Montag, den 02.03.2020, 20:10 +0100 schrieb David Kastrup: > dev/translation-merge > > Fails at make test (at least on my system). Ah, the merge re-instantiated some code for Python 2. The following diff fixes 'make test' for me: diff --git a/python/musicxml.py b/python/musicxml.py index 06cf

Re: Does the following Python error in the musicxml tests ring a bell?

Am Montag, den 02.03.2020, 21:40 +0100 schrieb David Kastrup: > Jonas Hahnfeld < > hah...@hahnjo.de > > writes: > > > Am Montag, den 02.03.2020, 20:10 +0100 schrieb David Kastrup: > > > dev/translation-merge > > > > > > Fails at make test

Re: [David Kastrup] [translations] Branches rededicated!

Hi David, it looks like now both branches have master merged and are identical: $ git diff origin/dev/translation-merge origin/translation [empty] Is that intended? To me this sounds conceptually wrong, given that you want to use one of them (I didn't understand which one) for 2.20.1 - I don't t

Re: [David Kastrup] [translations] Branches rededicated!

Am Dienstag, den 03.03.2020, 11:01 +0100 schrieb David Kastrup: > Jonas Hahnfeld < > hah...@hahnjo.de > > writes: > > > Hi David, > > > > it looks like now both branches have master merged and are identical: > > $ git diff origin/dev/translation-merge

Re: Does the following Python error in the musicxml tests ring a bell?

Am Dienstag, den 03.03.2020, 11:05 +0100 schrieb David Kastrup: > Jonas Hahnfeld < > hah...@hahnjo.de > > writes: > > > Am Montag, den 02.03.2020, 21:40 +0100 schrieb David Kastrup: > > > Jonas Hahnfeld < > > > hah...@hahnjo.de > > > > >

Re: Does the following Python error in the musicxml tests ring a bell?

Am Dienstag, den 03.03.2020, 11:13 +0100 schrieb Jonas Hahnfeld: > Am Dienstag, den 03.03.2020, 11:05 +0100 schrieb David Kastrup: > > Jonas Hahnfeld < > > hah...@hahnjo.de > > > > > writes: > > > Am Montag, den 02.03.2020, 21:40 +0100 schrieb David Kas

Re: Does the following Python error in the musicxml tests ring a bell?

Am Dienstag, den 03.03.2020, 17:10 +0100 schrieb David Kastrup: > David Kastrup < > d...@gnu.org > > writes: > > > Jonas Hahnfeld < > > hah...@hahnjo.de > > > writes: > > > This gives me 6 rather small merge conflicts that I could easily > >

translation updates in master (was: Re: Does the following Python error in the musicxml tests ring a bell?)

Am Dienstag, den 03.03.2020, 17:50 +0100 schrieb David Kastrup: > Jonas Hahnfeld < > hah...@hahnjo.de > > writes: > > Perfect. I only restored the following files from the branch to keep > > the Portuguese translation: > > * Documentation/web/server/lil

Re: translation updates in master

Am Dienstag, den 03.03.2020, 20:32 +0100 schrieb David Kastrup: > Jonas Hahnfeld < > hah...@hahnjo.de > > writes: > > > Am Dienstag, den 03.03.2020, 17:50 +0100 schrieb David Kastrup: > > > Jonas Hahnfeld < > > > hah...@hahnjo.de > > >

Re: 2.21.0 release plans and considerations

Am Mittwoch, den 04.03.2020, 09:34 +0100 schrieb Han-Wen Nienhuys: > On Sun, Mar 1, 2020 at 3:12 PM Jonas Hahnfeld < > hah...@hahnjo.de > > wrote: > > For example, I'd very much like #5799 to be part of 2.21.0 to be able > > to cross-compile to x86_64-w64-mingw32

GUB for LilyPond 2.21

I think I just finished fighting GUB to produce working binaries for the next unstable LilyPond 2.21. Please review the PR and merge: https://github.com/gperciva/gub/pull/71 I propose to ditch FreeBSD because the binaries are not working anyway and darwin-ppc/linux-ppc which is 32 bit PPC and not r

Re: 2.21.0 release plans and considerations

Am Donnerstag, den 05.03.2020, 11:45 +0100 schrieb Han-Wen Nienhuys: > On Wed, Mar 4, 2020 at 9:46 AM Jonas Hahnfeld wrote: > > The basic idea is to produce native binaries with all dependencies > > compiled as static libraries, with dependencies only on the most basic > >

Re: 2.21.0 release plans and considerations

Am Donnerstag, den 05.03.2020, 19:50 +0100 schrieb Han-Wen Nienhuys: > > > On Thu, Mar 5, 2020 at 2:16 PM Jonas Hahnfeld wrote: > > > * I'd base it off Git commits rather than tarballs. The tarballs are > > > anachronistic, and with git commits, it will be eas

configure.ac: Restore check for 'libguile18.h'. (issue 557580043 by lemzw...@googlemail.com)

https://codereview.appspot.com/557580043/diff/551560043/configure.ac File configure.ac (right): https://codereview.appspot.com/557580043/diff/551560043/configure.ac#newcode198 configure.ac:198: # they rename 'libguile.h' to 'libguile18.h'. Can you be more precise as to what distributions? Guile

Re: 2.21.0 release plans and considerations

> make a build > > -- > Phil Holmes > > > - Original Message - > From: "Jonas Hahnfeld" < > hah...@hahnjo.de > > > To: "Han-Wen Nienhuys" < > hanw...@gmail.com > > > Cc: "David Kastrup" < > d...@gnu.org > &g

Re: aclocal.m4: Update PKG_* macros to pkg-config 0.29.2 (issue 551590044 by lemzw...@googlemail.com)

The update LGTM On 2020/03/07 09:32:47, hanwenn wrote: > https://codereview.appspot.com/551590044/diff/553640043/aclocal.m4 > File aclocal.m4 (right): > > https://codereview.appspot.com/551590044/diff/553640043/aclocal.m4#newcode1127 > aclocal.m4:1127: # pkg.m4 - Macros to locate and utilise pkg-

Re: config.status has been broken by issue 5780 "Accept GUILE 2 without extra configure options"

Am Samstag, den 07.03.2020, 08:54 +0100 schrieb David Kastrup: > David Kastrup < > d...@gnu.org > > writes: > > > If I previously did > > > > GUILE_CONFIG=/usr/local/tmp/guile-1.8/bin/guile-config ./configure > > ./config.status --recheck > > > > then the Guile configuration was reused. If I no

Re: config.status has been broken by issue 5780 "Accept GUILE 2 without extra configure options"

Am Samstag, den 07.03.2020, 10:37 +0100 schrieb Werner LEMBERG: > >>> Is there anybody who recently built with a non-system version of > > >>> Guile-1.8 intentionally? > > >> > > >> I do this all the time. > > > > > > So how did you do it last week? > > > I updated my build script, see belo

Re: modularize `aclocal.m4`?

Am Samstag, den 07.03.2020, 10:27 +0100 schrieb Werner LEMBERG: > In standard GNU projects, the `aclocal.m4` file gets auto-generated > with the `aclocal` script; the necessary M4 scripts are either taken > from the system or from a directory that gets specified with some > command line options to

Re: config.status has been broken by issue 5780 "Accept GUILE 2 without extra configure options"

Am Samstag, den 07.03.2020, 11:19 +0100 schrieb David Kastrup: > Jonas Hahnfeld < > hah...@hahnjo.de > > writes: > > > Am Samstag, den 07.03.2020, 10:37 +0100 schrieb Werner LEMBERG: > > > > > > Is there anybody who recently built with a non-system vers

Re: config.status has been broken by issue 5780 "Accept GUILE 2 without extra configure options"

Am Samstag, den 07.03.2020, 11:24 +0100 schrieb Werner LEMBERG: > >> I updated my build script, see below. > > > > > > How did you notice that you had to? > > > Since I don't have guile 2.x installed the problem was immediately > visible. > > >> Note that I install texi2html 1.82 and guile 1.

Re: config.status has been broken by issue 5780 "Accept GUILE 2 without extra configure options"

Am Samstag, den 07.03.2020, 11:34 +0100 schrieb David Kastrup: > Jonas Hahnfeld < > hah...@hahnjo.de > > writes: > > > Am Samstag, den 07.03.2020, 08:54 +0100 schrieb David Kastrup: > > > David Kastrup < > > > d...@gnu.org >

Re: config.status has been broken by issue 5780 "Accept GUILE 2 without extra configure options"

Am Samstag, den 07.03.2020, 13:53 +0100 schrieb David Kastrup: > Jonas Hahnfeld < > hah...@hahnjo.de > > writes: > > > Am Samstag, den 07.03.2020, 11:19 +0100 schrieb David Kastrup: > > > We are not talking about "keep everything compatible". We are tal

Re: config.status has been broken by issue 5780 "Accept GUILE 2 without extra configure options"

Am Samstag, den 07.03.2020, 16:24 +0100 schrieb David Kastrup: > Jonas Hahnfeld < > hah...@hahnjo.de > > writes: > > > Am Samstag, den 07.03.2020, 13:53 +0100 schrieb David Kastrup: > > > Jonas Hahnfeld < > > > hah...@hahnjo.de > > > >

Fix test target name in python/GNUmakefile (issue 575790044 by hanw...@gmail.com)

I think this is wrong. Instead 'make test' should recurse into the subdirectories. Likely we should also fix this for flower IIRC https://codereview.appspot.com/575790044/

Re: Fix test target name in python/GNUmakefile (issue 575790044 by hanw...@gmail.com)

On 2020/03/07 21:24:48, hanwenn wrote: > On 2020/03/07 19:23:13, Dan Eble wrote: > > On 2020/03/07 18:59:54, hahnjo wrote: > > > I think this is wrong. Instead 'make test' should recurse into the > > > subdirectories. > > > > Agreed. That would be here in the top-level GNUMakefile.in: > > > > te

Fix most encoding problems with Guile 2.x (issue 555420043 by jonas.hahnf...@gmail.com)

Reviewers: , Message: FYI: This makes a `check` with Guile 2.2 for `baseline` from Guile 1.8 almost clean. Left are: * output races, ie `input/regression/option-help.log`, `input/regression/woodwind-diagrams-key-lists.log`, `input/regression/safe.log` * rounding differences: `input/regression/mark

  1   2   3   4   5   6   7   8   9   10   >