Re: ANN: Pygments support for LilyPond
Le 27/11/2021 à 17:36, Jean Abou Samra a écrit : I tried this solution, and I am experiencing a few problems. For one thing, Firefox doesn't render the bold typewriter fonts as bold (this is not happening in your pygments.pdf, but, for reasons I don't understand, it happens with the doc build). Also, when extractpdfmark is used and the TeX engine is XeTeX, GhostScript gives errors: Making Documentation/out-www/en/changes.pdf < texi Error: File did not complete the page properly and may be damaged. Output may be incorrect. Error: File did not complete the page properly and may be damaged. Output may be incorrect. Error: File did not complete the page properly and may be damaged. Output may be incorrect. Error: File did not complete the page properly and may be damaged. Output may be incorrect. In this case, even Evince doesn't render the bold. See the attached PDFs, without-extractpdfmark.pdf and after-extractpdfmark-and-gs.pdf. (You'll find the extractpdfmark and gs invocations in Documentation/GNUmakefile.) The only difference is in the invocation, either 'make -C Documentation out=www out-www/en/changes.pdf' or 'make -C Documentation out=www USE_EXTRACTPDFMARK=no out-www/en/changes.pdf'. (In my environment, XeTeX is being used by default.) Also, the bold text looks a bit 'hirsute' when zomming out in Evince. I guess that's the hinting issue you mentioned. I tried to reduce the boldness by changing the value 0.2 in common-macros.itexi but it didn't have an effect -- I wonder what's going on. Any ideas? You can reproduce all this by checking out my branch (if you visit the merge request, GitLab gives you command-line instructions in 'Check out branch'). I am not sure how I wrote this. For the most part, it is plain wrong. I must have messed up in my tests. So, the real story is that a specific combination triggers the problem: XeTeX and extractpdfmark. Here is a standalone reproducer: take your file pygments.texinfo, and run PDFTEX=xetex texi2pdf -o pygments-initial.pdf pygments.texinfo && extractpdfmark -o pygments.pdfmark pygments-initial.pdf && gs -dBATCH -dNOSAFER -dNOPAUSE -sDEVICE=pdfwrite -dAutoRotatePages=/None -dPrinted=false -sOutputFile=pygments-after-gs.pdf -c "3000 setvmthreshold" -I out-fonts/ -I out-fonts/Font pygments.pdfmark pygments-initial.pdf (I am not sure why having built LilyPond and passing "-I out-fonts -I out-fonts/Font" to gs is necessary.) Without PDFTEX=xetex, all is fine. With it, you should get GPL Ghostscript 9.54.0 (2021-03-30) Copyright (C) 2021 Artifex Software, Inc. All rights reserved. This software is supplied under the GNU AGPLv3 and comes with NO WARRANTY: see the file COPYING for details. Processing pages 1 through 1. Page 1 Error: File did not complete the page properly and may be damaged. Output may be incorrect. and the file pygments-after-gs.pdf, created from pygments-initial.pdf through gs, will not display bold. Also, forget about Firefox not displaying the bold glyphs. It actually does, but much more lightly, which is why I didn't notice it. Best, Jean
Re: ANN: Pygments support for LilyPond
Le 27/11/2021 à 23:02, Jean Abou Samra a écrit : [Sorry for Werner who will receive this email twice, I initially sent it from an address that is not subscribed to the list.] Le 27/11/2021 à 17:36, Jean Abou Samra a écrit : Excerpt from an email that became private more or less by accident (I've asked Werner): Anyway, as far as I know the package cfr-lm does provide LatinModern monowidth typewriter italic, bold and bold italic. https://ctan.org/pkg/cfr-lm Yes, it does. However, there is no need to look at this package; the fonts in question are from the 'lm' family, and there is no additional value in 'cfr-lm' for the task at hand. It is non-trivial to set 'lm' up for texinfo. Main reason is that there is no 'OT1' font encoding (and its siblings for 'OT1TT' and 'OT1OT' for typewriter and italic, respectively) available – texinfo is*not* suited to 'T1' encoding in general. It would thus be necessary to set up virtual fonts (`.vf`) together with its metrics files (`.tfm`), and those files had to be distributed with LilyPond. Using CTAN's `fontinst` package it is not very complicated to create such VFs, but we would also need to add proper CMap support to make copy-and-paste work in PDFs. As you can see, there is*a lot* of things to do. Of course, you could argue that we only need to have fonts for the `@example` environment. However, due to page breaking (which adds page headers and footers and takes care of footnotes), I'm not sure whether we could completely replace the fonts without interfering with texinfo's output routines, which switches fonts forth and back. Life would be much easier if we would drop pdfTeX support, using XeTeX or luatex only. We could then directly use the OpenType font version of 'lm', for example. However, I favor generic solutions for all three TeX engines. --- I tried this solution, and I am experiencing a few problems. For one thing, Firefox doesn't render the bold typewriter fonts as bold (this is not happening in your pygments.pdf, but, for reasons I don't understand, it happens with the doc build). Also, when extractpdfmark is used and the TeX engine is XeTeX, GhostScript gives errors: Making Documentation/out-www/en/changes.pdf < texi Error: File did not complete the page properly and may be damaged. Output may be incorrect. Error: File did not complete the page properly and may be damaged. Output may be incorrect. Error: File did not complete the page properly and may be damaged. Output may be incorrect. Error: File did not complete the page properly and may be damaged. Output may be incorrect. In this case, even Evince doesn't render the bold. See the attached PDFs, without-extractpdfmark.pdf and after-extractpdfmark-and-gs.pdf. (You'll find the extractpdfmark and gs invocations in Documentation/GNUmakefile.) The only difference is in the invocation, either 'make -C Documentation out=www out-www/en/changes.pdf' or 'make -C Documentation out=www USE_EXTRACTPDFMARK=no out-www/en/changes.pdf'. (In my environment, XeTeX is being used by default.) Also, the bold text looks a bit 'hirsute' when zomming out in Evince. I guess that's the hinting issue you mentioned. I tried to reduce the boldness by changing the value 0.2 in common-macros.itexi but it didn't have an effect -- I wonder what's going on. Any ideas? You can reproduce all this by checking out my branch (if you visit the merge request, GitLab gives you command-line instructions in 'Check out branch'). Thanks, Jean I am not sure how I wrote this. For the most part, it is plain wrong. I must have messed up in my tests. So, the real story is that a specific combination triggers the problem: XeTeX and extractpdfmark. Here is a standalone reproducer: take your file pygments.texinfo, and run PDFTEX=xetex texi2pdf -o pygments-initial.pdf pygments.texinfo && extractpdfmark -o pygments.pdfmark pygments-initial.pdf && gs -dBATCH -dNOSAFER -dNOPAUSE -sDEVICE=pdfwrite -dAutoRotatePages=/None -dPrinted=false -sOutputFile=pygments-after-gs.pdf -c "3000 setvmthreshold" -I out-fonts/ -I out-fonts/Font pygments.pdfmark pygments-initial.pdf (I am not sure why having built LilyPond and passing "-I out-fonts -I out-fonts/Font" to gs is necessary.) Without PDFTEX=xetex, all is fine. With it, you should get GPL Ghostscript 9.54.0 (2021-03-30) Copyright (C) 2021 Artifex Software, Inc. All rights reserved. This software is supplied under the GNU AGPLv3 and comes with NO WARRANTY: see the file COPYING for details. Processing pages 1 through 1. Page 1 Error: File did not complete the page properly and may be damaged. Output may be incorrect. and the file pygments-after-gs.pdf, created from pygments-initial.pdf through gs, will not display bold. Also, forget about Firefox not displaying the bold glyphs. It actually does, but much more
Re: [RFC] Moving to Guile 2.2 and away from GUB
On Fri, Nov 26, 2021 at 12:54 PM Jonas Hahnfeld wrote: > A build without optimizations crashed more or less immediately upon > compiling the regression tests. That said, I'm not really interested in > debugging advice - if you have ideas, please reproduce the problem on > your end (shouldn't be too hard) and try them. I tried both ideas, and it doesn't help. -- Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
Re: ANN: Pygments support for LilyPond
[Sorry for Werner who will receive this email twice, I initially sent it from an address that is not subscribed to the list.] Le 27/11/2021 à 17:36, Jean Abou Samra a écrit : Excerpt from an email that became private more or less by accident (I've asked Werner): Anyway, as far as I know the package cfr-lm does provide LatinModern monowidth typewriter italic, bold and bold italic. https://ctan.org/pkg/cfr-lm Yes, it does. However, there is no need to look at this package; the fonts in question are from the 'lm' family, and there is no additional value in 'cfr-lm' for the task at hand. It is non-trivial to set 'lm' up for texinfo. Main reason is that there is no 'OT1' font encoding (and its siblings for 'OT1TT' and 'OT1OT' for typewriter and italic, respectively) available – texinfo is*not* suited to 'T1' encoding in general. It would thus be necessary to set up virtual fonts (`.vf`) together with its metrics files (`.tfm`), and those files had to be distributed with LilyPond. Using CTAN's `fontinst` package it is not very complicated to create such VFs, but we would also need to add proper CMap support to make copy-and-paste work in PDFs. As you can see, there is*a lot* of things to do. Of course, you could argue that we only need to have fonts for the `@example` environment. However, due to page breaking (which adds page headers and footers and takes care of footnotes), I'm not sure whether we could completely replace the fonts without interfering with texinfo's output routines, which switches fonts forth and back. Life would be much easier if we would drop pdfTeX support, using XeTeX or luatex only. We could then directly use the OpenType font version of 'lm', for example. However, I favor generic solutions for all three TeX engines. --- I tried this solution, and I am experiencing a few problems. For one thing, Firefox doesn't render the bold typewriter fonts as bold (this is not happening in your pygments.pdf, but, for reasons I don't understand, it happens with the doc build). Also, when extractpdfmark is used and the TeX engine is XeTeX, GhostScript gives errors: Making Documentation/out-www/en/changes.pdf < texi Error: File did not complete the page properly and may be damaged. Output may be incorrect. Error: File did not complete the page properly and may be damaged. Output may be incorrect. Error: File did not complete the page properly and may be damaged. Output may be incorrect. Error: File did not complete the page properly and may be damaged. Output may be incorrect. In this case, even Evince doesn't render the bold. See the attached PDFs, without-extractpdfmark.pdf and after-extractpdfmark-and-gs.pdf. (You'll find the extractpdfmark and gs invocations in Documentation/GNUmakefile.) The only difference is in the invocation, either 'make -C Documentation out=www out-www/en/changes.pdf' or 'make -C Documentation out=www USE_EXTRACTPDFMARK=no out-www/en/changes.pdf'. (In my environment, XeTeX is being used by default.) Also, the bold text looks a bit 'hirsute' when zomming out in Evince. I guess that's the hinting issue you mentioned. I tried to reduce the boldness by changing the value 0.2 in common-macros.itexi but it didn't have an effect -- I wonder what's going on. Any ideas? You can reproduce all this by checking out my branch (if you visit the merge request, GitLab gives you command-line instructions in 'Check out branch'). Thanks, Jean I am not sure how I wrote this. For the most part, it is plain wrong. I must have messed up in my tests. So, the real story is that a specific combination triggers the problem: XeTeX and extractpdfmark. Here is a standalone reproducer: take your file pygments.texinfo, and run PDFTEX=xetex texi2pdf -o pygments-initial.pdf pygments.texinfo && extractpdfmark -o pygments.pdfmark pygments-initial.pdf && gs -dBATCH -dNOSAFER -dNOPAUSE -sDEVICE=pdfwrite -dAutoRotatePages=/None -dPrinted=false -sOutputFile=pygments-after-gs.pdf -c "3000 setvmthreshold" -I out-fonts/ -I out-fonts/Font pygments.pdfmark pygments-initial.pdf (I am not sure why having built LilyPond and passing "-I out-fonts -I out-fonts/Font" to gs is necessary.) Without PDFTEX=xetex, all is fine. With it, you should get GPL Ghostscript 9.54.0 (2021-03-30) Copyright (C) 2021 Artifex Software, Inc. All rights reserved. This software is supplied under the GNU AGPLv3 and comes with NO WARRANTY: see the file COPYING for details. Processing pages 1 through 1. Page 1 Error: File did not complete the page properly and may be damaged. Output may be incorrect. and the file pygments-after-gs.pdf, created from pygments-initial.pdf through gs, will not display bold. Also, forget about Firefox not displaying the bold glyphs. It actually does, but much more lightly, which is why I didn't notice it. Best, Jean
Re: [RFC] Moving to Guile 2.2 and away from GUB
On 27/11/2021 17:30, Jonas Hahnfeld wrote: Am Samstag, dem 27.11.2021 um 11:13 +0100 schrieb Jonas Hahnfeld via Discussions on LilyPond development: Am Mittwoch, dem 24.11.2021 um 20:13 +0100 schrieb Jonas Hahnfeld via Discussions on LilyPond development: I'd like to propose that we release 2.23.5 relatively soon (as Phil has time) using GUB [...] Okay, scratch that: GUB is currently broken building for mingw, who would have guessed... Oh how I hate it! https://gitlab.com/lilypond/lilypond/-/merge_requests/1032 for mingw, and https://github.com/gperciva/gub/pull/88 for fixing GUB because we now have too many .ly files... Phil, if you want to do a release already tomorrow, we can probably merge the fixes early unless there are some immediate concerns. Jonas Can do a release tomorrow. I can pull the GUB fix before I do it if you want to push the Gitlab merge request. Phil
Re: [RFC] Moving to Guile 2.2 and away from GUB
Am Samstag, dem 27.11.2021 um 11:13 +0100 schrieb Jonas Hahnfeld via Discussions on LilyPond development: > Am Mittwoch, dem 24.11.2021 um 20:13 +0100 schrieb Jonas Hahnfeld via > Discussions on LilyPond development: > > I'd like to propose that we release 2.23.5 relatively soon (as Phil has > > time) using GUB [...] > > Okay, scratch that: GUB is currently broken building for mingw, who > would have guessed... Oh how I hate it! https://gitlab.com/lilypond/lilypond/-/merge_requests/1032 for mingw, and https://github.com/gperciva/gub/pull/88 for fixing GUB because we now have too many .ly files... Phil, if you want to do a release already tomorrow, we can probably merge the fixes early unless there are some immediate concerns. Jonas signature.asc Description: This is a digitally signed message part
Re: [RFC] Moving to Guile 2.2 and away from GUB
Am Samstag, dem 27.11.2021 um 14:31 +0100 schrieb Jan Nieuwenhuizen: > Jonas Hahnfeld writes: > > > Am Samstag, dem 27.11.2021 um 12:43 +0100 schrieb Jan Nieuwenhuizen: > > > I already proposed using GNU Guix, making use of its excellent cross > > > build system and creation of universal binaries. > > > > The problem is there is no such thing as cross-compilation for recent > > macOS > > Yeah, the Darwin cross build would have to be ported to Guix; There is nothing to port; I claim it's not feasible technically + legally at the same time. > that would be quite some work, but then it could benefit many. So, how many open source projects would benefit from such work? I know that we are the only ones using GUB, is that now different with Guix? Because doing the work in a general fashion for nobody to use it, is a waste IMHO. > > I have never deeply looked into GNU Guix, but from my understanding > > it's a general solution that will probably involve dynamic libraries, > > again getting us into all sorts of trouble > > Yes, Guix uses dynamic libraries, and so do its universal binaries. I'm > not aware of any sort trouble with that. > > FWIW, Jean pointed out that my remark came too late, and inappropriately > so. Sorry about that. I'm not sure I agree on "too late", but certainly "late". As such, it would at least be fair to consider my arguments for why I don't consider proposals brought forward repeatedly without proofs as alternatives. I did think quite a bit about different ways, and I certainly didn't like writing yet another build solution... Jonas signature.asc Description: This is a digitally signed message part
Re: [RFC] Moving to Guile 2.2 and away from GUB
Am Samstag, dem 27.11.2021 um 14:15 +0100 schrieb Jan Nieuwenhuizen: > Jean Abou Samra writes: > > > Le 27/11/2021 à 12:43, Jan Nieuwenhuizen a écrit : > > > But yeah, some 5 years ago > > > > > > I already proposed using GNU Guix, making use of its excellent cross > > > build system and creation of universal binaries. > > > > At this point, it's a bit too late to discuss other solutions > > in my opinion. Jonas obviously invested a ton of work in > > this > > Ah, my bad. Then that's great or too bad, depending on your viewpoint. > After GUB (already when working on GUB, ftm) my hope was to avoid > duplicating efforts of maintaining cross build systems. I wholeheartedly agree, which is why we're not maintaining the cross build tool installation ourselves but just install the packages from Ubuntu. Because the advantage of only cross-compiling for mingw is that it's very common, with available support in quite some distributions. signature.asc Description: This is a digitally signed message part
Re: [RFC] Moving to Guile 2.2 and away from GUB
Am Samstag, dem 27.11.2021 um 13:54 +0100 schrieb David Kastrup: > Jonas Hahnfeld via Discussions on LilyPond development > writes: > > > Am Samstag, dem 27.11.2021 um 12:43 +0100 schrieb Jan Nieuwenhuizen: > > > I already proposed using GNU Guix, making use of its excellent cross > > > build system and creation of universal binaries. > > > > The problem is there is no such thing as cross-compilation for recent > > macOS, it's simply not allowed by Apple. > > There could be for Darwin and it's conceivable that a command line > application like LilyPond could be delivered in that manner without > involving Apple's proprietary build environments. Likely without > offering platform-specific font integration. Maybe for the most basic applications without dependencies because even linking with libc will be tricky. For LilyPond, we're talking quite a number of dependencies where some (for example glib2) link against macOS frameworks. How would that ever work? Feel free to prove me wrong, but that requires some code demonstration - repeatedly making the same claim whenever the discussion comes up doesn't bring us forward. signature.asc Description: This is a digitally signed message part
Re: [RFC] Moving to Guile 2.2 and away from GUB
Jonas Hahnfeld writes: > Am Samstag, dem 27.11.2021 um 12:43 +0100 schrieb Jan Nieuwenhuizen: >> Carl Sorensen writes: >> >> > I think GUB was a great idea, but it has proven difficult to maintain. >> > And the creator of GUB (Jan), has indicated that he thinks it is not >> > worth continuing to work on. So GUB has been a dead man walking for >> > some time. >> >> FWIW, Han-Wen is the initial author of GUB >> >> >> https://gitlab.com/janneke/gub/-/commit/34095019c86ced7dc3be79e306b7a7b45e3ab909 >> >> in an effort to combine the Darwin and MinGW cross build >> scripts/makefiles. >> >> But yeah, some 5 years ago >> >> https://lists.gnu.org/archive/html/lilypond-devel/2016-03/msg00204.html >> >> I already proposed using GNU Guix, making use of its excellent cross >> build system and creation of universal binaries. > > The problem is there is no such thing as cross-compilation for recent > macOS Yeah, the Darwin cross build would have to be ported to Guix; that would be quite some work, but then it could benefit many. > I have never deeply looked into GNU Guix, but from my understanding > it's a general solution that will probably involve dynamic libraries, > again getting us into all sorts of trouble Yes, Guix uses dynamic libraries, and so do its universal binaries. I'm not aware of any sort trouble with that. FWIW, Jean pointed out that my remark came too late, and inappropriately so. Sorry about that. Greetings, Janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: [RFC] Moving to Guile 2.2 and away from GUB
Jean Abou Samra writes: > Le 27/11/2021 à 12:43, Jan Nieuwenhuizen a écrit : >> But yeah, some 5 years ago >> >> I already proposed using GNU Guix, making use of its excellent cross >> build system and creation of universal binaries. > > At this point, it's a bit too late to discuss other solutions > in my opinion. Jonas obviously invested a ton of work in > this Ah, my bad. Then that's great or too bad, depending on your viewpoint. After GUB (already when working on GUB, ftm) my hope was to avoid duplicating efforts of maintaining cross build systems. Greetings, Janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: [RFC] Moving to Guile 2.2 and away from GUB
Le 27/11/2021 à 12:43, Jan Nieuwenhuizen a écrit : But yeah, some 5 years ago https://lists.gnu.org/archive/html/lilypond-devel/2016-03/msg00204.html I already proposed using GNU Guix, making use of its excellent cross build system and creation of universal binaries. Greetings, Janneke At this point, it's a bit too late to discuss other solutions in my opinion. Jonas obviously invested a ton of work in this, on the premise (at least when submitting the first RFC merge request adding the set of scripts to our source) that it would eventually become what we officially use. Now I think the question is when this becomes the standard, not if. Thanks, Jean
Re: [RFC] Moving to Guile 2.2 and away from GUB
Jonas Hahnfeld via Discussions on LilyPond development writes: > Am Samstag, dem 27.11.2021 um 12:43 +0100 schrieb Jan Nieuwenhuizen: >> Carl Sorensen writes: >> >> Hi, >> >> > I think GUB was a great idea, but it has proven difficult to maintain. >> > And the creator of GUB (Jan), has indicated that he thinks it is not >> > worth continuing to work on. So GUB has been a dead man walking for >> > some time. >> >> FWIW, Han-Wen is the initial author of GUB >> >> >> https://gitlab.com/janneke/gub/-/commit/34095019c86ced7dc3be79e306b7a7b45e3ab909 >> >> in an effort to combine the Darwin and MinGW cross build >> scripts/makefiles. >> >> But yeah, some 5 years ago >> >> https://lists.gnu.org/archive/html/lilypond-devel/2016-03/msg00204.html >> >> I already proposed using GNU Guix, making use of its excellent cross >> build system and creation of universal binaries. > > The problem is there is no such thing as cross-compilation for recent > macOS, it's simply not allowed by Apple. There could be for Darwin and it's conceivable that a command line application like LilyPond could be delivered in that manner without involving Apple's proprietary build environments. Likely without offering platform-specific font integration. -- David Kastrup
PATCHES - Countdown for November 27th
Hello, Here is the current patch countdown list. The next countdown will be on November 29th. A list of all merge requests can be found here: https://gitlab.com/lilypond/lilypond/-/merge_requests?sort=label_priority Push: !1020 mf: Avoid FontForge overlap removal bug - Werner Lemberg https://gitlab.com/lilypond/lilypond/-/merge_requests/1020 !1016 Store NoteColumn main extent in a property - Jean Abou Samra https://gitlab.com/lilypond/lilypond/-/merge_requests/1016 Countdown: !1025 GC fixes for System and Spanner - David Kastrup https://gitlab.com/lilypond/lilypond/-/merge_requests/1025 !1024 Fix regtest nondeterminism in Guile 2 - Jean Abou Samra https://gitlab.com/lilypond/lilypond/-/merge_requests/1024 !1023 Docfix: Learning Manual, sec 4.2.1, correct number of contexts - John Wheeler https://gitlab.com/lilypond/lilypond/-/merge_requests/1023 !1022 \segnoMark command - Dan Eble https://gitlab.com/lilypond/lilypond/-/merge_requests/1022 !1021 Repeat_styler: issue AlternativeEvents - Dan Eble https://gitlab.com/lilypond/lilypond/-/merge_requests/1021 !1019 Draft: RFC: Add syntax highlighting to documentation - Jean Abou Samra https://gitlab.com/lilypond/lilypond/-/merge_requests/1019 !1017 lilypond-book: Fix include handling by `kpsewhich` - Michael Käppler https://gitlab.com/lilypond/lilypond/-/merge_requests/1017 !1012 Take slur skylines from stencil - Jean Abou Samra https://gitlab.com/lilypond/lilypond/-/merge_requests/1012 Review: !1031 NR: minor documentation improvements - Werner Lemberg https://gitlab.com/lilypond/lilypond/-/merge_requests/1031 !1030 Make user tweaks to line spanner Y positions relative to relevant group - Jean Abou Samra https://gitlab.com/lilypond/lilypond/-/merge_requests/1030 !1028 output-distance cleanups - Han-Wen Nienhuys https://gitlab.com/lilypond/lilypond/-/merge_requests/1028 !1027 Doc-zh: Update web/community - Guyutongxue https://gitlab.com/lilypond/lilypond/-/merge_requests/1027 !1026 Allow byte-compilation of song-util.scm - Jean Abou Samra https://gitlab.com/lilypond/lilypond/-/merge_requests/1026 New: No patches in New at this time. Waiting: !913 release: binaries with cairo - Han-Wen Nienhuys https://gitlab.com/lilypond/lilypond/-/merge_requests/913 *** -- Regards James OpenPGP_0xAAC8D177A7F5A364.asc Description: OpenPGP public key
Re: [RFC] Moving to Guile 2.2 and away from GUB
Am Samstag, dem 27.11.2021 um 12:43 +0100 schrieb Jan Nieuwenhuizen: > Carl Sorensen writes: > > Hi, > > > I think GUB was a great idea, but it has proven difficult to maintain. > > And the creator of GUB (Jan), has indicated that he thinks it is not > > worth continuing to work on. So GUB has been a dead man walking for > > some time. > > FWIW, Han-Wen is the initial author of GUB > > > https://gitlab.com/janneke/gub/-/commit/34095019c86ced7dc3be79e306b7a7b45e3ab909 > > in an effort to combine the Darwin and MinGW cross build > scripts/makefiles. > > But yeah, some 5 years ago > > https://lists.gnu.org/archive/html/lilypond-devel/2016-03/msg00204.html > > I already proposed using GNU Guix, making use of its excellent cross > build system and creation of universal binaries. The problem is there is no such thing as cross-compilation for recent macOS, it's simply not allowed by Apple. I have never deeply looked into GNU Guix, but from my understanding it's a general solution that will probably involve dynamic libraries, again getting us into all sorts of trouble that I've demonstrated can be avoided. Regards, Jonas signature.asc Description: This is a digitally signed message part
Re: [RFC] Moving to Guile 2.2 and away from GUB
Carl Sorensen writes: Hi, > I think GUB was a great idea, but it has proven difficult to maintain. > And the creator of GUB (Jan), has indicated that he thinks it is not > worth continuing to work on. So GUB has been a dead man walking for > some time. FWIW, Han-Wen is the initial author of GUB https://gitlab.com/janneke/gub/-/commit/34095019c86ced7dc3be79e306b7a7b45e3ab909 in an effort to combine the Darwin and MinGW cross build scripts/makefiles. But yeah, some 5 years ago https://lists.gnu.org/archive/html/lilypond-devel/2016-03/msg00204.html I already proposed using GNU Guix, making use of its excellent cross build system and creation of universal binaries. Greetings, Janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: TimeSignature with note in denominator
Flaming Hakama by Elaine writes: > On Mon, Nov 15, 2021 at 11:11 AM David Kastrup wrote: >> >> Where "convert this into a reasonable time signature" would imply the >> ability to convert this into the two separate components, a functional >> and a visual one. At the current point of time, something like >> 2/4. (for what is commonly referred to as 6/8 in standard notation) has >> no natural conversion to the functional components >> numerator/denominator. One could do this "more naturally" by allowing >> the "denominator" to be a rational number instead of just an integer. > > In particular, it is not clear what you mean about 6/8 being a case where > it is not clear how to interpret it. I am not interested in this "discussion" where my words are constantly being used as the inspiration for coming up with strawmen that have nothing to do with what I am saying. If people cannot be bothered to actually read what I write there is no point in my participation. -- David Kastrup
Re: [RFC] Moving to Guile 2.2 and away from GUB
Am Mittwoch, dem 24.11.2021 um 20:13 +0100 schrieb Jonas Hahnfeld via Discussions on LilyPond development: > I'd like to propose that we release 2.23.5 relatively soon (as Phil has time) > using GUB [...] Okay, scratch that: GUB is currently broken building for mingw, who would have guessed... Oh how I hate it! Jonas signature.asc Description: This is a digitally signed message part
