Re: Please test gub
>> ??? What exactly needs Portuguese? Lilypond doesn't, AFAICS. > > In stable/2.20 here's a translation of the website in this language, > and a PDF of the website is built and even shipped in the > documentation tarball and the website, e.g. look at the end of the > file list on http://lilypond.org/doc/v2.19/Documentation/ Thanks, but uh, oh – how come that this is not in the `master' branch? David K.? > Is there some practical usage of web*.pdf documents, or shall we > prevent their building? Yes, I think we should prevent that, if possible – they are indeed of no practical use. > BTW it was me the guy who proposed to work on this, and I've > completed nearly 3/4 of the migration of a big patch for > cross-building Python 2.7; lots of tests of Python scripts in > binaries may be necessary when this is ready to be built. Excellent news! Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 64-bit version of Lilypond?
>> I don't have access to a mac, I don't think that I know anybody who >> uses one within a 20 miles radius, and my knowledge of MacOS is >> almost limited to the single information that it does exist. >> Therefore I definitely will not work on 64-bit mac support in gub. I just want to remark that building lilypond on recent MacOS versions work just fine (see, for example, the `lilypond-devel' package for MacPorts). > Could anyone describe the process GUB uses to produce the current > macOS installer? Maybe at least a starting point for research on > 64-bit macOS builds could be determined. Or at a "guided tour" of > GUB sources in this area, to help newcomers to the code understand > what they'll be looking at. We don't have that yet, sorry. The process of providing 64bit support would start with defining `darwin-64' as an allowed platform to build on and to build for, then looking for a suitable Apple SDK for compilation and installation.[*] All follow-up problems probably have to be solved case by case. Werner [*] It should be the one with the lowest version possible so that older 64bit MacOS versions are not excluded. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: MacOS 64-bit build
> On 13 Feb 2019, at 20:16, Daniel Johnson wrote:
>
> I am using guile 1.8.8, gcc 7.4.0, and flex 2.6.4. Here's my configure line:
>
> On build, I get a long string of errors originating in out/lexer.cc:
>
> out/lexer.cc:6272:46: error: cannot convert 'std::istream {aka
> std::basic_istream}' to 'std::istream* {aka std::basic_istream*}'
> in assignment
> YY_CURRENT_BUFFER_LVALUE->yy_input_file = yyin;
Use flex 2.5.37, as the flex 2.6.* C++ lexer is broken (discussed on the Bison
lists): a stream pointer has been changed in the declaration to a reference
without doing it in the code. Reported some years ago on the flex list.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
MacOS 64-bit build
Hi all,
Apologies if this is off-topic or excessively noobish.
As an educational process, I've been working on a script to get Lilypond
2.19.82 to build on MacOS Mojave with dependencies mostly handled by
Homebrew. I had to build extractpdfmark by hand, but the rest of the
dependency tree is Homebrew. I am using guile 1.8.8, gcc 7.4.0, and flex
2.6.4. Here's my configure line:
PATH="/usr/local/opt/texinfo/bin:/usr/local/opt/flex/bin:/usr/local/opt/bison/bin:$PATH"
\
CC=/usr/local/bin/gcc-7 CXX=/usr/local/bin/gcc-7
CPP=/usr/local/bin/cpp-7 \
CPPFLAGS="-I/usr/local/include -I/usr/local/opt/flex/include" \
LDFLAGS="-L/usr/local/lib -L/usr/local/opt/flex/lib
-L/usr/local/opt/bison/lib" \
./configure --with-texgyre-dir=/Library/Fonts --disable-documentation
--disable-optimising \
--disable-pipe --disable-debugging --disable-guile2 --disable-profiling
On build, I get a long string of errors originating in out/lexer.cc:
out/lexer.cc:6272:46: error: cannot convert 'std::istream {aka
std::basic_istream}' to 'std::istream* {aka
std::basic_istream*}' in assignment
YY_CURRENT_BUFFER_LVALUE->yy_input_file = yyin;
^~~~
out/lexer.cc: In constructor 'yyFlexLexer::yyFlexLexer(std::istream*,
std::ostream*)':
out/lexer.cc:6387:75: error: 'std::basic_istream<_CharT,
_Traits>::basic_istream() [with _CharT = char; _Traits =
std::char_traits]' is protected within this context
yyFlexLexer::yyFlexLexer( std::istream* arg_yyin, std::ostream*
arg_yyout )
^
In file included from
/usr/local/Cellar/gcc@7/7.4.0/include/c++/7.4.0/iostream:40:0,
from out/lexer.cc:120:
/usr/local/Cellar/gcc@7/7.4.0/include/c++/7.4.0/istream:606:7: note:
declared protected here
basic_istream()
^
out/lexer.cc:6387:75: error: 'std::basic_ostream<_CharT,
_Traits>::basic_ostream() [with _CharT = char; _Traits =
std::char_traits]' is protected within this context
yyFlexLexer::yyFlexLexer( std::istream* arg_yyin, std::ostream*
arg_yyout )
^
In file included from
/usr/local/Cellar/gcc@7/7.4.0/include/c++/7.4.0/iostream:39:0,
from out/lexer.cc:120:
/usr/local/Cellar/gcc@7/7.4.0/include/c++/7.4.0/ostream:384:7: note:
declared protected here
basic_ostream()
^
out/lexer.cc:6389:9: error: no match for 'operator=' (operand types are
'std::istream {aka std::basic_istream}' and 'std::istream* {aka
std::basic_istream*}')
yyin = arg_yyin;
^~~~
In file included from
/usr/local/Cellar/gcc@7/7.4.0/include/c++/7.4.0/iostream:40:0,
from out/lexer.cc:120:
/usr/local/Cellar/gcc@7/7.4.0/include/c++/7.4.0/istream:625:7: note:
candidate: std::basic_istream<_CharT, _Traits>&
std::basic_istream<_CharT,
_Traits>::operator=(std::basic_istream<_CharT, _Traits>&&) [with _CharT
= char; _Traits = std::char_traits]
operator=(basic_istream&& __rhs)
^~~~
/usr/local/Cellar/gcc@7/7.4.0/include/c++/7.4.0/istream:625:7: note:
no known conversion for argument 1 from 'std::istream* {aka
std::basic_istream*}' to 'std::basic_isttream&&'
out/lexer.cc:6390:10: error: no match for 'operator=' (operand types are
'std::ostream {aka std::basic_ostream}' and 'std::ostream* {aka
std::basic_ostream*}')
yyout = arg_yyout;
^
In file included from
/usr/local/Cellar/gcc@7/7.4.0/include/c++/7.4.0/iostream:39:0,
from out/lexer.cc:120:
/usr/local/Cellar/gcc@7/7.4.0/include/c++/7.4.0/ostream:402:7: note:
candidate: std::basic_ostream<_CharT, _Traits>&
std::basic_ostream<_CharT,
_Traits>::operator=(std::basic_ostream<_CharT, _Traits>&&) [with _CharT
= char; _Traits = std::char_traits]
operator=(basic_ostream&& __rhs)
^~~~
/usr/local/Cellar/gcc@7/7.4.0/include/c++/7.4.0/ostream:402:7: note:
no known conversion for argument 1 from 'std::ostream* {aka
std::basic_ostream*}' to 'std::basic_ostream&&'
out/lexer.cc: In member function 'virtual void
yyFlexLexer::switch_streams(std::istream*, std::ostream*)':
out/lexer.cc:6436:11: error: no match for 'operator=' (operand types are
'std::ostream {aka std::basic_ostream}' and 'std::ostream* {aka
std::basic_ostream*}')
yyout = new_out;
^~~
In file included from
/usr/local/Cellar/gcc@7/7.4.0/include/c++/7.4.0/iostream:39:0,
from out/lexer.cc:120:
/usr/local/Cellar/gcc@7/7.4.0/include/c++/7.4.0/ostream:402:7: note:
candidate: std::basic_ostream<_CharT, _Traits>&
std::basic_ostream<_CharT,
_Traits>::operator=(std::basic_ostream<_CharT, _Traits>&&) [with _CharT
= char; _Traits = std::char_traits]
operator=(basic_ostream&& __rhs)
^~~~
/usr/local/Cellar/gcc@7/7.4.0/include/c++/7.4.0/ostream:402:7: note:
no known conversion for argument 1 from 'std::ostream* {aka
std::basic_ostream*}' to 'std::basic_ostream&&'
out/lexer.cc: At global scope:
out/lexer.cc:32:25: error: prototype for 'size_t
Re: 64-bit version of Lilypond?
On 2/13/2019 6:17 AM, Knut Petersen wrote: I don't have access to a mac, I don't think that I know anybody who uses one within a 20 miles radius, and my knowledge of MacOS is almost limited to the single information that it does exist. Therefore I definitely will not work on 64-bit mac support in gub. Could anyone describe the process GUB uses to produce the current macOS installer? Maybe at least a starting point for research on 64-bit macOS builds could be determined. Or at a "guided tour" of GUB sources in this area, to help newcomers to the code understand what they'll be looking at. -- Karlin High Missouri, USA ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 64-bit version of Lilypond?
On 2/13/2019 6:16 AM, Knut Petersen wrote: "LilyPond's GUB build system is currently being repaired" is misleading: Gub from grahams repository + pull request or e.g the gub at https://github.com/knupero/gub.git (grahams gub + pull requests 53-60) has been tested by a lot of people, I don't see a reason not to use it. Thank you for the clarification. At this point, what is needed to continue building further releases of LilyPond? -- Karlin High Missouri, USA ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Can alternateTextSpannerEngraver now completely replace Text_spanner_engraver in a public release?
David Nalesnik writes: > David, > > On Wed, Feb 13, 2019 at 8:35 AM David Kastrup wrote: >> >> David Nalesnik writes: >> >> > On Wed, Feb 13, 2019 at 7:49 AM Trevor Bača wrote: >> >> >> >> Could somebody else possibly provide James a patch of David N.'s >> >> alternateTextSpannerEngraver? >> >> >> >> Trevor. >> > >> > The issue which would come up is that it is written in Scheme, rather >> > than C++. This has implications for documentation. >> >> It does? What kind of documentation cannot be achieved in Scheme that >> would be possible in C++? >> > Ah, OK, thanks for the update. I must be thinking of a past state of affairs. commit df854ae456ad2e57139ddcb345760b4c321e1cbb Author: David Kastrup Date: Sat Jan 28 01:16:54 2017 +0100 Issue 1375/3: Register scheme engravers This registers Measure_counter_engraver and Span_stem_engraver to make them documented and callable like C++ engravers. commit 6887546c5caf87cdc94252c020f39b43a57bf057 Author: David Kastrup Date: Tue Jun 16 14:14:27 2015 +0200 Issue 1375/2: Create Translator_creator class Previously, translators were created by copying from a context-less instantiation of the translator containing its documentation. This had several unpleasant consequences, the most problematic likely being the inability to register Scheme engravers because their documentation would be identical to all other Scheme engravers. A new Translator_creator class takes over the task of creating Translator instances when called with a context argument. As a result of joining the mechanisms for Scheme engravers and C++ engravers, ly:translator-name and ly:translator-description are reimplemented in a manner resembling object properties. commit 6d1c5d25389afa6dbbfb4722df3732e764cbbf2e Author: David Kastrup Date: Fri Jan 27 13:27:03 2017 +0100 Issue 1375/1: Let Translator constructor take a Context argument This is the first step towards constructing rather than cloning translators when creating contexts. On its own, it does not make sense, but the change is large and mostly mechanical, so keeping it separate from the actually difficult parts makes sense. This is not even yesteryear's news but yonderyesteryear's news. Not that 2 years are a lot of time at the current development speed. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Can alternateTextSpannerEngraver now completely replace Text_spanner_engraver in a public release?
David, On Wed, Feb 13, 2019 at 8:35 AM David Kastrup wrote: > > David Nalesnik writes: > > > On Wed, Feb 13, 2019 at 7:49 AM Trevor Bača wrote: > >> > >> Could somebody else possibly provide James a patch of David N.'s > >> alternateTextSpannerEngraver? > >> > >> Trevor. > > > > The issue which would come up is that it is written in Scheme, rather > > than C++. This has implications for documentation. > > It does? What kind of documentation cannot be achieved in Scheme that > would be possible in C++? > > Here is some page from the Internals reference: > > File: lilypond-internals.info, Node: Merge_rests_engraver, Next: > Metronome_mark_engraver, Prev: Mensural_ligature_engraver, Up: Engravers > and Performers > > 2.2.71 Merge_rests_engraver > --- > > Engraver to merge rests in multiple voices on the same staff. This > works by gathering all rests at a time step. If they are all of the > same length and there are at least two they are moved to the correct > location as if there were one voice. > >Properties (read) > > ‘suspendRestMerging’ (boolean) > When using the Merge_rest_engraver do not merge rests when > this is set to true. > >‘Merge_rests_engraver’ is not part of any context. > > > This is an engraver written in Scheme. Ah, OK, thanks for the update. I must be thinking of a past state of affairs. David N ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Can alternateTextSpannerEngraver now completely replace Text_spanner_engraver in a public release?
On Wed, Feb 13, 2019 at 8:35 AM David Kastrup wrote: > David Nalesnik writes: > > > On Wed, Feb 13, 2019 at 7:49 AM Trevor Bača > wrote: > >> > >> Could somebody else possibly provide James a patch of David N.'s > >> alternateTextSpannerEngraver? > >> > >> Trevor. > > > > The issue which would come up is that it is written in Scheme, rather > > than C++. This has implications for documentation. > > It does? What kind of documentation cannot be achieved in Scheme that > would be possible in C++? > > Here is some page from the Internals reference: > > File: lilypond-internals.info, Node: Merge_rests_engraver, Next: > Metronome_mark_engraver, Prev: Mensural_ligature_engraver, Up: Engravers > and Performers > > 2.2.71 Merge_rests_engraver > --- > > Engraver to merge rests in multiple voices on the same staff. This > works by gathering all rests at a time step. If they are all of the > same length and there are at least two they are moved to the correct > location as if there were one voice. > >Properties (read) > > ‘suspendRestMerging’ (boolean) > When using the Merge_rest_engraver do not merge rests when > this is set to true. > >‘Merge_rests_engraver’ is not part of any context. > > > This is an engraver written in Scheme. > > -- > David Kastrup > Thank you both (David and David) so much for engaging on this last step! Truly wonderful; and if I can just chime in one last time while you are thinking through the problem: I *think* (not 100% certain, but close to it) that the ideal final implementation path would be not just to add alternateTextSpannerEngraver as, say, Alternate_text_spanner_engraver, but rather to *replace* the existing Text_spanner_engraver with (the implementation of) alternateTextSpannerEngraver. I think this was clear in my previous mail, but I just wanted to insert one last time here as the question of Scheme-vs-C++ final resting spot gets considered. Trevor. -- Trevor Bača www.trevorbaca.com soundcloud.com/trevorbaca ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Can alternateTextSpannerEngraver now completely replace Text_spanner_engraver in a public release?
David Nalesnik writes: > On Wed, Feb 13, 2019 at 7:49 AM Trevor Bača wrote: >> >> Could somebody else possibly provide James a patch of David N.'s >> alternateTextSpannerEngraver? >> >> Trevor. > > The issue which would come up is that it is written in Scheme, rather > than C++. This has implications for documentation. It does? What kind of documentation cannot be achieved in Scheme that would be possible in C++? Here is some page from the Internals reference: File: lilypond-internals.info, Node: Merge_rests_engraver, Next: Metronome_mark_engraver, Prev: Mensural_ligature_engraver, Up: Engravers and Performers 2.2.71 Merge_rests_engraver --- Engraver to merge rests in multiple voices on the same staff. This works by gathering all rests at a time step. If they are all of the same length and there are at least two they are moved to the correct location as if there were one voice. Properties (read) ‘suspendRestMerging’ (boolean) When using the Merge_rest_engraver do not merge rests when this is set to true. ‘Merge_rests_engraver’ is not part of any context. This is an engraver written in Scheme. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Can alternateTextSpannerEngraver now completely replace Text_spanner_engraver in a public release?
On Wed, Feb 13, 2019 at 7:49 AM Trevor Bača wrote: > > On Wed, Feb 13, 2019 at 4:58 AM James Lowe wrote: > > > Hello Trevor, > > > > On Tue, 12 Feb 2019 16:45:35 -0600, Trevor Bača > > wrote: > > > > > > > > > > Question: is it now possible to replace Text_spanner_engraver with David > > > N.'s extended implementation, in a coming public release of LilyPond? > > > > > > > > > Trevor. > > > > > > > > > If you have a patch based on current master I can at least test that for > > you.] > > > > James > > > > Hi James, > > I have no patch. > > Could somebody else possibly provide James a patch of David N.'s > alternateTextSpannerEngraver? > > Trevor. The issue which would come up is that it is written in Scheme, rather than C++. This has implications for documentation. I could work this into the existing C++ code and present a patch, if that's best. DN ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
PATCHES - Countdown for Feb 13th
Hello, Here is the current patch countdown list. The next countdown will be on February 16th A quick synopsis of all patches currently in the review process can be found here: http://philholmes.net/lilypond/allura/ Push: 5474 Segfault when attempting to create an undefined grob. - Valentin Villenave https://sourceforge.net/p/testlilyissues/issues/5474 http://codereview.appspot.com/349840043 5472 flower/file-name.cc: Fix canonical file name representation. - Werner LEMBERG https://sourceforge.net/p/testlilyissues/issues/5472 http://codereview.appspot.com/355920043 5468 yyout2grammar.py: Various fixes. - Werner LEMBERG https://sourceforge.net/p/testlilyissues/issues/5468 http://codereview.appspot.com/363900043 5464 New feature: automatically invert chords or drop/rise chord notes - Valentin Villenave https://sourceforge.net/p/testlilyissues/issues/5464 http://codereview.appspot.com/365840043 Countdown: No patches on countdown at this time. Review: 5473 Use "simple strings" rather than #"hash-prefixed Scheme strings" - Valentin Villenave https://sourceforge.net/p/testlilyissues/issues/5473 http://codereview.appspot.com/363910043 1367 Enhancement: NoteNames context should handle any note names language - Valentin Villenave https://sourceforge.net/p/testlilyissues/issues/1367 http://codereview.appspot.com/221710044 New: No new patches at this time. *** Regards James - End Forwarded Message - ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Can alternateTextSpannerEngraver now completely replace Text_spanner_engraver in a public release?
On Wed, Feb 13, 2019 at 4:58 AM James Lowe wrote: > Hello Trevor, > > On Tue, 12 Feb 2019 16:45:35 -0600, Trevor Bača > wrote: > > > > > > Question: is it now possible to replace Text_spanner_engraver with David > > N.'s extended implementation, in a coming public release of LilyPond? > > > > > > Trevor. > > > > > If you have a patch based on current master I can at least test that for > you.] > > James > Hi James, I have no patch. Could somebody else possibly provide James a patch of David N.'s alternateTextSpannerEngraver? Trevor. -- Trevor Bača www.trevorbaca.com soundcloud.com/trevorbaca ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 64-bit version of Lilypond?
Hi Sven! It does work (with complaints) on 10.13 as well as 10.14. But Apple will stop supporting 32-bit applications in 10.15 which will be released sometime in September, so we need a 64-bit build before then. I was not aware of the fact that MacOS support will be broken in a few months, and I don't think that anybody currently works on that problem. I don't have access to a mac, I don't think that I know anybody who uses one within a 20 miles radius, and my knowledge of MacOS is almost limited to the single information that it does exist. Therefore I definitely will not work on 64-bit mac support in gub. If nobody volunteers to implement a 64-bit mac target in gub, lilypond on the mac might soon be history. Knut ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 64-bit version of Lilypond?
On 12.02.19 20:46, Karlin High wrote: On 2/12/2019 1:12 PM, Joseph Austin wrote: I just installed version 2.19.82-1 on my Mac OSX 10.13.4, and Mac complains that it's 32 bit software. Is there or will there be a 64-bit version of Lilypond that runs on Mac? LilyPond's GUB build system is currently being repaired. Once it returns to production, it needs more work on teaching it to build a 64-bit Mac version of LilyPond. The next version of macOS is planned to only use 64-bit software. "LilyPond's GUB build system is currently being repaired" means: * Some undocumented limitations were removed from gub and lilypond. To give an example: gub only was able to succeed if it was executed as user gub and if it was installed in the directory /home/gub/gub/NewGub. Both limitations were removed. * Gub was only able to succeed on some very old linux distributions, e.g. ubuntu 14 and 16. Today it's possible to use gub on at least ubuntu 14, 16 and 18, opensuse tumbleweed, opensuse leaf, debian 9.7, mint and archlinux. It is not necessary to boot one of the tested distributions, you might chroot to some minimal disk image or use e.g. VirtualBox on a Windows system. I don't know of anybody who tried that, but I don't see a reason why building lilypond installers using VirtualBox on a MacOS host should fail. "LilyPond's GUB build system is currently being repaired" is misleading: Gub from grahams repository + pull request or e.g the gub at https://github.com/knupero/gub.git (grahams gub + pull requests 53-60) has been tested by a lot of people, I don't see a reason not to use it. Some work has to be done: A lot of ancient software is built and used, the result is distributed. Ancient means e.g. that and even older version of guile is used. Ancient means that gub still use gcc 4. Ancient means that gub uses a maintenance release of glibc 2.3 published in 2007, glibc 2.3 dates back to the year 2002. Ancient means that gub builds, uses and distributes python 2.4.5 although at least lilypond's script musicxml2ly requires at least python version 2.7, a version released in the year 2010. Current gub only succeeds to test lilypond and to build the lilypond documentation because a bug in gub (introduced more than a decade ago) has the result that the system's python and not the python compiled by gub is used during some parts of the build process. Currently a few people work on gub, but I tend to believe that none of the lilypond developers test if a patch is compatible to gub before they propose it. After a lilypond patch is proposed, James does test it. But even James does not use gub for testing. Gub does allow to build branches of lilypond it fetches from a local git-daemon, it is also possible to instruct gub to directly use a local lilypond git directory. But these features are hidden, undocumented, and therefore probably unused. We should update some of the ancient software gub uses. I think some people work on that. We should update our documentation. Will be done later, most of the relevant information has been posted to lilypond-devel. Knut ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Can alternateTextSpannerEngraver now completely replace Text_spanner_engraver in a public release?
Hello Trevor, On Tue, 12 Feb 2019 16:45:35 -0600, Trevor Bača wrote: > > Question: is it now possible to replace Text_spanner_engraver with David > N.'s extended implementation, in a coming public release of LilyPond? > > > Trevor. > If you have a patch based on current master I can at least test that for you.] James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 64-bit version of Lilypond?
On Wed, 13 Feb 2019 at 08:06, Jacques Menu wrote: > Hello Joseph, > > Does it only complain, and work anyway, on 10.13.4? It’s OK here on > 10.13.6. > It does work (with complaints) on 10.13 as well as 10.14. But Apple will stop supporting 32-bit applications in 10.15 which will be released sometime in September, so we need a 64-bit build before then. -- Sven Axelsson ++[>++>+++>++>++ ><-]>.+..>+.>+.<<-.>>+.>.<<. +++.>-.<<++.>>.<++.>>>++..>>.<. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
