Re: Flex on macOS

illet 2023 à 22:29 +0200, Hans Åberg a écrit : >> >> >> Apple has patched their version of Flex so that the generated .cc file must >> be used with their header FlexLexer.h. > > I don't think this is the problem. Before I installed Flex from Homebrew, the > only Fl

Re: Flex on macOS

> On 31 Jul 2023, at 01:15, Jean Abou Samra wrote: > > I noticed that the macOS-provided flex version (on the MacStadium node > provided > by Marnen, which runs the unsupported macOS Catalina) was ~10 years old, so I > installed Flex from Homebrew (required setting CPPFLAGS + LDFLAGS + PATH

Re: MacPorts builds for 'Yosemite' and 'El Capitan' fail

> On 5 Feb 2023, at 13:54, Werner LEMBERG wrote: > > I see the following error: > > rational.cc:68:33: error: call to 'abs' is ambiguous > num_ = static_cast (::abs (n)); >^ > /usr/include/stdlib.h:129:6: note: candidate function > int abs(int)

Re: Turkish makam

> On 18 Jan 2023, at 05:07, Adam Good wrote: > > Let's take the makam Rast: > > g a bfc c d e fb > > the pitch g just happens to be the finalis...every song or instrumental > composition will have a melody that must end on that pitch. And the > accidentals say "b one koma flat" and "f four

Re: Turkish makam

> On 16 Jan 2023, at 10:30, Luca Fascione wrote: > >> On Sun, Jan 15, 2023 at 3:49 PM Hans Åberg wrote: >> As the full number of Turkish makam is very large, perhaps too many to have >> in this file, there might be a turkish-makam-extended for the less common

Re: Turkish makam

> On 16 Jan 2023, at 02:29, Adam Good wrote: > > On Sun, Jan 15, 2023 at 9:49 AM Hans Åberg wrote: > > As the full number of Turkish makam is very large, perhaps too many to have > in this file, there might be a turkish-makam-extended for the less common > ones. >

Re: Turkish makam

> On 15 Jan 2023, at 14:45, Adam Good wrote: > > Hans and Werner, > For a couple reasons, I deliberately used the name turkish-makam.ly to make > a distinction and clarity between the Arabic and Turkish varieties of > (respectively) maqam and makam theory and notation systems. Also I do have >

Re: Turkish makam

> On 14 Jan 2023, at 08:06, Werner LEMBERG wrote: > >>> Too bad that `makam.ly` is essentially undocumented... >> >> From what I can see, makam.ly is the original faulty file, only >> there for backwards compatibility, which might be removed if there >> is no need for that. > > We could make

Re: Turkish makam

> On 13 Jan 2023, at 19:03, Werner LEMBERG wrote: > >> [...] a possible future change could be, say, >> >> \include "arabic.ly" >> \language "arabic-hel" >> >> but I don't see much benefit for that. > > Hmm, probably it *is* the way to go – this is exactly what is done in > `makam.ly` and

Re: Oriental microtonal music

> On 29 Dec 2022, at 23:35, Karlin High wrote: > > My email address was in the To: header. > > In Cc: were the other people I had mentioned here: > > > > Therefore, I understood that post as a response to my question

Oriental microtonal music

Graham Breed wrote a file regular.ly that allows for retuning into any ET (around C4, not A4), but Adam Good is expert on Turkish music specifically. There are some issues with Turkish, Persian and Arabic music that must be dealt with when adapting for LilyPond: Notation

Re: Prefer luatex for documentation

> On 19 Nov 2022, at 11:19, Werner LEMBERG wrote: > > In https://gitlab.com/lilypond/lilypond/-/merge_requests/1714 I > suggest that we prefer luatex for building the documentation. What do > people think? The people that developed LuaTeX also developed ConTeXt, but the latter has now

Re: Mac Unofficial bundle

> On 12 Nov 2022, at 20:16, Jeremiah Benham wrote: > > Does anyone here know how the unofficial Mac bundle was created? I assume > it was not created using gub. Was it macports? Is there a script you guys > use to slurp up all the files into a bundle or how are you crating it? The current one

Re: 64-bit MacBook Air M2 problems

> On 15 Aug 2022, at 17:57, Jean Abou Samra wrote: > > Also, when you enter the apostrophe from the keyboard, is it really > a straight apostrophe -> ' <- or could it be that macOS does > you the “favor” to replace it with a curly apostrophe ->’ <- ? > LilyPond expects straight

MacPorts clang dependency

The MacPorts page below says that lilypond-devel (and also lilypond) depends on clang-13, however, clang-14 has now been released. Curiously, 'port info lilypond-devel' does not mention clang at all. Also, the dependency on Guile is listed as guile, which I figure will be Guile 3 when updated

Re: compiling MacOS application in LilyDev

> On 9 Nov 2021, at 19:06, Kieren MacMillan > wrote: > >> The intent is probably to create an app. > > Yes, for me to run (personally). > >> One can make installers with MacPorts, I posted some on the users list. > > I found that thread — helpful! > > I tried, and got: > > Error: Failed

Re: compiling MacOS application in LilyDev

> On 9 Nov 2021, at 19:06, Kieren MacMillan > wrote: > > Hi Hans, > >> The intent is probably to create an app. > > Yes, for me to run (personally). > >> One can make installers with MacPorts, I posted some on the users list. > > I found that thread — helpful! > > I tried, and got: > >

Re: compiling MacOS application in LilyDev

> On 9 Nov 2021, at 19:06, Kieren MacMillan > wrote: > > Hi Hans, > >> One can make installers with MacPorts, I posted some on the users list. > > I found that thread — helpful! > > I tried, and got: > > Error: … You tried what? Making your own installer from MacPorts? —The ones I do

Re: compiling MacOS application in LilyDev

> On 9 Nov 2021, at 00:50, Karlin High wrote: > > 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. The intent is probably to create an

Re: Shortcut for \repeat unfold

> On 26 Sep 2021, at 10:16, Jean Abou Samra wrote: > > Le 26/09/2021 à 09:57, Hans Åberg a écrit : >>> On 26 Sep 2021, at 06:49, Werner LEMBERG wrote: >>> >>> You might provide a MR, maybe it gets accepted. I still doubt that it >>> would b

Re: Shortcut for \repeat unfold

> On 26 Sep 2021, at 06:49, Werner LEMBERG wrote: > The idea here is different, it is for identifiers, and in the input syntax only, does not change the internal semantics at all. It is good not having to type backslash when a command is used. >>> >>> Really? I highly doubt

Re: Shortcut for \repeat unfold

> On 25 Sep 2021, at 19:25, Werner LEMBERG wrote: > Perhaps the LilyPond syntax might be tweaked so that identifiers starting with a UTF-8 multi-byte (high bit set) character do not need the backslash. Then simply ×2 would look good. >>> >>> This reminds me of TeX's 'active

Re: Shortcut for \repeat unfold

> On 25 Sep 2021, at 18:37, Werner LEMBERG wrote: > >>> And I think it would be nice to have an even more natural variant >>> for that; I think it's reasonable to provide & show/recommend >>> convenient solutions for standard tasks (rather than say "you can >>> define your own abbreviation

Re: Shortcut for \repeat unfold

> On 25 Sep 2021, at 17:47, Lukas-Fabian Moser wrote: > > And I think it would be nice to have an even more natural variant for that; I > think it's reasonable to provide & show/recommend convenient solutions for > standard tasks (rather than say "you can define your own abbreviation here if

Re: SMuFL name mapping update, 9 July

and at expanding Emmentaler in a couple areas. > > Owen > > On 7/10/2021 6:29 AM, Hans Åberg wrote: >>> On 10 Jul 2021, at 04:09, Owen Lamb wrote: >>> >>> A bit of news on the SMuFL front. I've dropped in the next few Emmentaler >>> categories (De

Re: SMuFL name mapping update, 9 July

> On 10 Jul 2021, at 04:09, Owen Lamb wrote: > > A bit of news on the SMuFL front. 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/.

Re: lilypond on Apple silicon

> On 16 Jan 2021, at 13:05, Werner LEMBERG wrote: > > According to > > https://ports.macports.org/port/lilypond/summary > > the problems with the dependencies have been fixed; this means that > lilypond should now install fine using MacPorts on Apple silicon. I tried building

Re: tie over clef change

> On 28 Sep 2020, at 00:26, Lukas-Fabian Moser wrote: > >>> However, this gets *never* notated as such. >>> >> I gave the example of augment sixth chords, that seem to never be notated as >> diminished sevenths. >> >> https://en.wikipedia.org/wiki/Augmented_sixth_chord > I assume you meant

Re: tie over clef change

> On 27 Sep 2020, at 22:17, Werner LEMBERG wrote: > >>> It is common, for example, for a composer to write D sharp for some >>> instruments and E flat for others. >> >> A composer should write so that it becomes easy for the musician to >> perform, otherwise they will have to edit the score,

Re: tie over clef change

> On 27 Sep 2020, at 22:01, David Kastrup wrote: > > Hans Åberg writes: > >>> On 27 Sep 2020, at 19:57, Lukas-Fabian Moser wrote: >>> >>>> I seem to remember that even in Bach's B minor mass (where E12 was not >>>> yet a thing) th

Re: tie over clef change

> On 27 Sep 2020, at 20:59, Kevin Barry wrote: > >> Both cases were discussed. For an orchestra they are not the same pitch, >> thus formally a slur. > > You cannot make this assumption. It is exceptional to distinguish D > sharp and E flat since most performed orchestral music is equally >

Re: tie over clef change

> On 27 Sep 2020, at 19:57, Lukas-Fabian Moser wrote: > >> I seem to remember that even in Bach's B minor mass (where E12 was not >> yet a thing) there is an enharmonic tie (or at least tonal repetition?) >> in the transition from "Confiteor" to "Et expecto". I mean, that >> transition is a

Re: tie over clef change

> On 27 Sep 2020, at 20:20, David Kastrup wrote: > > Hans Åberg writes: > >>> On 27 Sep 2020, at 19:31, David Kastrup wrote: >>> >>> Hans Åberg writes: >>> >>>>> On 26 Sep 2020, at 18:04, Dan Eble wrote: >>>>>

Re: tie over clef change

> On 27 Sep 2020, at 19:31, David Kastrup wrote: > > Hans Åberg writes: > >>> On 26 Sep 2020, at 18:04, Dan Eble wrote: >>> >>>> On Sep 26, 2020, at 09:41, Dan Eble wrote: >>>> >>>> On Sep 26, 2020, at 08:55, Werner LEMBE

Re: tie over clef change

> On 26 Sep 2020, at 20:58, Kevin Barry wrote: > > On Sat, 26 Sep 2020 at 19:30, Hans Åberg wrote: >>>>>> The notes d♯ to e♭ have different pitches in the staff notation >>>>>> system, which cannot express E12 enharmonic equivalents, so this >

Re: tie over clef change

> On 26 Sep 2020, at 19:36, Dan Eble wrote: > > On Sep 26, 2020, at 13:11, Hans Åberg wrote: >> >>> >>> On 26 Sep 2020, at 18:50, Dan Eble wrote: >>> >>> On Sep 26, 2020, at 12:34, Hans Åberg wrote: >>>> >>>>

Re: tie over clef change

> On 26 Sep 2020, at 19:56, Werner LEMBERG wrote: > The notes d♯ to e♭ have different pitches in the staff notation system, which cannot express E12 enharmonic equivalents, so this is slur. So it should be a slur that looks like slur. > > I disagree. For all practical purposes

Re: tie over clef change

Re: tie over clef change

> On 26 Sep 2020, at 18:04, Dan Eble wrote: > >> On Sep 26, 2020, at 09:41, Dan Eble wrote: >> >> On Sep 26, 2020, at 08:55, Werner LEMBERG wrote: >>> >>> >>> Despite Gould's “incorrect” verdict, here is an example from an old UE >>> edition of Liszt's “Liebestraum No. 1”, which

Re: tie over clef change

> On 26 Sep 2020, at 14:55, Werner LEMBERG wrote: > > Despite Gould's “incorrect” verdict, here is an example from an old UE > edition of Liszt's “Liebestraum No. 1”, which demonstrates that ties > over clef changes *do* happen and make sense sometimes... > > I still think that LilyPond

Re: Language selection

> On 20 Aug 2020, at 15:22, Phil Holmes wrote: > > If I go to http://lilypond.org/doc/v2.21/Documentation/notation/index.html > and click any of the links, I get a page in Spanish, which I'm not. > > Anyone know why? Probably because your parents weren't Spanish.

Re: collision \breathe with accidentals

> On 7 Aug 2020, at 08:17, Werner LEMBERG wrote: > > As the attached images show, the breathing sign *sometimes* collides > with accidentals. Looks like a bug. If you agree I'll add it to the > tracker. > > Any idea how to circumvent that? In addition to that, I place the breath mark above

Re: Almost, but not quite: C++ STL in LilyPond

> On 6 May 2020, at 08:21, Han-Wen Nienhuys wrote: > > Regarding GC, once we leave behind GUILE 1.x, we could adorn all SCM > containing structures with a operator new/operator delete, which calls > scm_gc_alloc()/scm_gc_free(). That would get rid of marking functions. > For vectors, we could

Re: Almost, but not quite: C++ STL in LilyPond

> On 5 May 2020, at 18:57, David Kastrup wrote: > > Hans Åberg writes: > >>> On 5 May 2020, at 17:09, David Kastrup wrote: >>> >>> One reason is that we want to get rid of finalisers particularly in >>> connection with the Boehm GC. Fin

Re: Almost, but not quite: C++ STL in LilyPond

> On 5 May 2020, at 17:09, David Kastrup wrote: > > One reason is that we want to get rid of finalisers particularly in > connection with the Boehm GC. Finalisers are called when garbage is > collected, the collection of garbage is typically indicative of the > expected lifetime of our

Re: Make operator= private in Scheme_hash_table (issue 557680043 by hanw...@gmail.com)

> On 13 Apr 2020, at 17:15, hanw...@gmail.com wrote: > > On 2020/04/13 14:55:12, hahnjo wrote: >> If the function is not meant to be implemented / used, it should be > explicitly >> deleted (C++11). > > Done. > > https://codereview.appspot.com/557680043/ One might prefer having a deleted

Re: How do I change LOCALEDIR?

> On 2 Mar 2020, at 01:46, Marnen Laibow-Koser wrote: > > On Sun, Mar 1, 2020 at 7:04 PM Hans Åberg wrote: > > > On 1 Mar 2020, at 23:45, Marnen Laibow-Koser wrote: > > > > One question as I continue to work on 64-bit Mac packaging: how do I set > &g

Re: How do I change LOCALEDIR?

> On 1 Mar 2020, at 23:45, Marnen Laibow-Koser wrote: > > One question as I continue to work on 64-bit Mac packaging: how do I set > LOCALEDIR (in this case, to match the packaged app bundle rather than the > build-time path)? Unlike everything else of this nature, neither the > .reloc files

Re: lilypond-darwin-64 app doesn't work on Mac OS Lion

> On 17 Feb 2020, at 17:04, Werner LEMBERG wrote: > > > For fun I tried to execute > > > https://bintray.com/marnen/lilypond-darwin-64/lilypond-2.19.83/2.19.83.build20200207173449 > > on my old MacOS Lion box, with the following error. > > Traceback (most recent call last): > … >

Re: Doc: Some miscellaneous suggestions from Peter Toye (issue 579280043 by michael.kaepp...@googlemail.com)

> On 9 Feb 2020, at 15:09, Graham King wrote: > > From a speed-reading of Gould, it appears that she uses the verb "alter" and > the adjective "altered", but _not_ the noun "alteration" in this context. > > It is worth noting that "alteration" has a very specific and well-established >

Re: Mac 64-bit builds: Guile segfault?

> On 8 Feb 2020, at 13:51, Marnen Laibow-Koser wrote: > > From the feedback I’ve been getting, it looks like my 64-bit Mac builds are > working well for most people. However, one user—one only one of two Macs > he has access to—is consistently getting a segfault with these builds right >

Re: Disable C++ exceptions (issue 571430048 by jonas.hahnf...@gmail.com)

> On 28 Jan 2020, at 23:28, hanw...@gmail.com wrote: > > I don't think there is any chance of ever using exceptions in LilyPond, > because we can't mix them with the GUILE call stack. One can combine C++ and Guile exceptions, by converting back and forth between them. Even though GCC admits

Re: GUILE 2/3 and string encoding cost

> On 24 Jan 2020, at 10:03, Han-Wen Nienhuys wrote: > > On Thu, Jan 23, 2020 at 10:39 PM David Kastrup wrote: > >> >>> on mozart-hrn-3, over 3 runs, we get >>> >>> 2.0.14 - avg 2.1s >>> 1.8.8 - avg 0.31s >>> >>> so the new GC is about 5-10x slower than the old one. With GUILE 1.8, >>>

Re: Issue 4550: Avoid "using namespace std; " in included files (Take 2) (issue 579240043 by nine.fierce.ball...@gmail.com)

> On 23 Jan 2020, at 13:43, lemzwerg--- via Discussions on LilyPond development > wrote: > >> Why is this ugly? std::string is really the name of the class. > > No question, but I would prefer > > struct xxx { >using std:string; > >string foo; >string bar; >string baz; >

Re: MacOS 64-bit build

> On 9 Jan 2020, at 18:00, Werner LEMBERG wrote: > >>> There is no guarantee that `FlexLexer.h` found during compilation >>> is the one that is used by a recent flex version. Unfortunately, >>> `FlexLexer.h` doesn't contain any version information, so it is >>> really impossible to protect

Re: MacOS 64-bit build

> On 9 Jan 2020, at 13:34, Werner LEMBERG wrote: > >> `configure` should warn or bail on incompatible flex versions. I >> suggest we add a version check in configure.ac to ensure that flex >> version is between 2.5.37 and 2.5.39 (given that 2.5.38 and 2.5.39 >> actually works). > > What you

Re: macOS 64-bit

> On 7 Jan 2020, at 23:21, Marnen Laibow-Koser wrote: > >>> Also, of course, the point is to do this in a way that doesn’t require >> the end users to have MacPorts. >> >> The Emacs.app seemed to be working when put in /Applications/ so it might >> be distributed independently. > > Right,

Re: macOS 64-bit

> On 7 Jan 2020, at 22:35, Jonas Hahnfeld via Discussions on LilyPond > development wrote: > > By far no Mac expert, but if dynamic libraries are problematic would it > help to have a static executable? I experimented with such a setup for > Linux, and I eventually got it to build. Not sure

Re: macOS 64-bit

> On 7 Jan 2020, at 22:20, Marnen Laibow-Koser wrote: > > On Tue, Jan 7, 2020 at 4:16 PM Hans Åberg wrote: > [...] > > FYI, it is possible to build apps using MacPorts, for example, there is > emacs-app that installs Emacs.app in /Applications/MacPorts/, and it seems

Re: macOS 64-bit

> On 7 Jan 2020, at 21:52, Marnen Laibow-Koser wrote: > > Some updates. For the time being, at least, I've changed approaches. > Since I couldn't understand much of GUB's OS detection logic, and no one > seemed able to help with that, I abandoned GUB entirely for my latest > attempt and used

Re: Issue 5639: compile with -std=c++11 (issue 553310045 by nine.fierce.ball...@gmail.com)

> On 14 Dec 2019, at 09:54, lemzwerg--- via Discussions on LilyPond development > wrote: > > LGTM, thanks! > > https://codereview.appspot.com/553310045/ > The C++11 range for statement is nice too, if the iterator self is not addressed. For example, in beam.cc: for (auto& s: stems) {

Re: Issue 5639: compile with -std=c++11 (issue 553310045 by nine.fierce.ball...@gmail.com)

> On 14 Dec 2019, at 13:07, d...@gnu.org wrote: > > I don't want to get your enthusiasm up prematurely, but I think that the > GUB GCC versions we need(?)/use for PowerPC might not be entirely great > with C++11 though they'll likely support it when given explicitly on the > command line. From

Helmholtz-Ellis accidentals

> On 21 Oct 2018, at 10:56, Torsten Hämmerle wrote: > > If I understand it correctly, the main reason for switching to Bravura are > missing Emmentaler accidental glyphs (obviously the multi-arrowed ones, if I > look at your definition files). > > Incidentally, I'm planning to fill in the

Re: Frescobaldi on MacOS 10.15 with MacPorts

> On 21 Oct 2019, at 01:24, Davide Liessi wrote: > > Il giorno sab 19 ott 2019 alle ore 20:31 Hans Åberg > ha scritto: >> Instead I experienced further corruption, and decided to reinstall the whole >> of MacPorts from scratch. I do not want to try it agai

Re: Frescobaldi on MacOS 10.15 with MacPorts

> On 19 Oct 2019, at 19:53, Davide Liessi wrote: > > Dear Hans, > > Il giorno sab 19 ott 2019 alle ore 19:01 Hans Åberg > ha scritto: >> For some reason, MacPorts ‘port install frescobaldi-devel’ failed on MacOS >> 10.15, and a ticket could not resolve it.

Frescobaldi on MacOS 10.15 with MacPorts

For some reason, MacPorts ‘port install frescobaldi-devel’ failed on MacOS 10.15, and a ticket could not resolve it. So perhaps somebody here might want giving it a try. ___ lilypond-devel mailing list lilypond-devel@gnu.org

Re: macOS 64-bit

> On 19 Oct 2019, at 17:30, Jahrme Risner wrote: > > On Thu, Oct 17, 2019 at 19:08, Marnen Laibow-Koser wrote: > >> Awesome, thanks; I’ll try it when I get a chance. I still want to get an >> .app bundle built, but it’s good to know that the mdmg approach actually >> works as advertised. :)

Re: macOS 64-bit

> On 18 Oct 2019, at 00:30, Marnen Laibow-Koser wrote: > > On Thu, Oct 17, 2019 at 6:24 PM Hans Åberg wrote: > >> I made an installer into /opt/lilypond/ on MacOS 10.15, which you might >> try out. > > > With port mdmg/mpkg, or some other way? Yes, see h

Re: macOS 64-bit

> On 17 Oct 2019, at 09:21, Werner LEMBERG wrote: > > I have a 64bit Mac OS 10.7.5 machine at home; I made an installer into /opt/lilypond/ on MacOS 10.15, which you might try out. > theoretically, this > should do the compilation job too, right? It takes a very long time to do it as one has

Re: 64 bit

[Moving to lilypond-devel] > On 16 Oct 2019, at 18:02, Werner LEMBERG wrote: > Maybe if a compiler is not listed as a dependency, it will just take what is currently installed. >>> >>> Yes. >> >> So perhaps it suffices to remove it from the lilypond-devel >> dependency list to get

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

> On 12 Oct 2019, at 07:21, Eric Benson wrote: > > gcc8 doesn’t build in MacPorts on Catalina, at least it didn’t build for me > on Thursday. There was a MacPorts release on Friday, but I haven’t tried it > yet. Maybe the problem has been fixed. I never got lilypond to build with > gcc8 because

Re: Compiling instructions for macOS 10.15 Catalina

> On 13 Oct 2019, at 06:02, tansongchen wrote: > > I tried to follow this, but I encountered another problem: dependency > "libgcc9" is not able to be built. Here is the log: main.log > Make ticket with the log attached at

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

> On 12 Oct 2019, at 14:28, Werner LEMBERG wrote: > >> But on the hand, I have never seen anything installing in /opt/ >> besides MacPorts on MacOS. And also packages are put in /usr/local/. > > Well, that homebrew occupies `/usr/local' is far from optimal. It decided to avoid it because of

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

> On 12 Oct 2019, at 13:43, Werner LEMBERG wrote: > > What about `/opt/lilypond’? The location /usr/local/ is for user installations on BSD systems, there is for example /usr/local/texlive, so it seems natural. >>> >>> Well, I don't care enough to argue :-) >> >> Why not?

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

> On 12 Oct 2019, at 12:09, Werner LEMBERG wrote: > > I think I put it into /usr/local/lilypond or /usr/local/lilypond-devel. Which location would you prefer? >>> >>> What about `/opt/lilypond’? >> >> The location /usr/local/ is for user installations on BSD systems, >> there is

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

> On 12 Oct 2019, at 10:55, Werner LEMBERG wrote: > >> I think I put it into /usr/local/lilypond or >> /usr/local/lilypond-devel. Which location would you prefer? > > What about `/opt/lilypond’? The location /usr/local/ is for user installations on BSD systems, there is for example

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

> On 12 Oct 2019, at 07:21, Eric Benson wrote: > > gcc8 doesn’t build in MacPorts on Catalina, at least it didn’t build for me > on Thursday. There was a MacPorts release on Friday, but I haven’t tried it > yet. Maybe the problem has been fixed. I never got lilypond to build with > gcc8

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

> On 12 Oct 2019, at 07:00, Werner LEMBERG wrote: > > >>> Well, right now you have to build MacPorts from source on MacOS >>> 10.15 – I guess this takes almost a day of compilation. (I don't >>> have such an OS, by the way). >> >> The link I gave has an installer for MacOS 10.15, and it

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

> On 11 Oct 2019, at 21:43, Werner LEMBERG wrote: > A problem with the [MacPorts] lilypond-devel package is that it listed all dependencies for the build as required for the installer, including GCC, making it very large, so it should be slimmed down. >>> >>> This is not

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

> On 11 Oct 2019, at 19:16, Eric Benson wrote: > > > I see that MacPorts now has been updated for MacOS 10.15. > > Hah! If only I had waited one more day! It was not a waste of time — I have also done such package chasing, but a package manager is of course more convenient. :-)

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

> On 11 Oct 2019, at 18:41, Werner LEMBERG wrote: > > >> A problem with the [MacPorts] lilypond-devel package is that it >> listed all dependencies for the build as required for the installer, >> including GCC, making it very large, so it should be slimmed down. > > This is not correct any

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

> On 11 Oct 2019, at 18:41, Werner LEMBERG wrote: > > See > > https://lists.gnu.org/archive/html/lilypond-devel/2019-10/msg00047.html The dependency has not yet been update to GCC 9, it seems: https://ports.macports.org/port/lilypond-devel/summary

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

> On 10 Oct 2019, at 17:41, Eric Benson wrote: > > I haven't tried to build the Mac OS application, Lilypond.app, because I > don't use it myself. I only use the command line lilypond. I believe it is deprecated, as there are better alternatives, Frescobaldi was one suggestion I think.

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

> On 10 Oct 2019, at 17:41, Eric Benson wrote: > > sudo port install lilypond-devel > > That should work, after which you will have /opt/local/bin/lilypond > installed. You have to make sure that /opt/local/bin is on your $PATH. MacPorts adds it to $PATH, though not correctly first: I have

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

> On 10 Oct 2019, at 18:45, Carl Sorensen wrote: > > I think that we are going to need to move to having somebody with a Mac build > and provide an OSX 64-bit build for lilypond, rather than using GUB for the > 64-bit build. MacPorts can create a standalone installer, one can choose

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

> On 10 Oct 2019, at 17:55, Eric Benson wrote: > > > This is good, but I think GCC 8 was kept deliberately as it was unclear if > > GCC 9 would work. > > gcc8 failed to build on MacPorts on Catalina on the latest Xcode. Rather than > try to understand why, I switched to gcc9 and it seems to

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

> On 10 Oct 2019, at 9:01:57 AM, Eric Benson wrote: > > I was able to build Lilypond on Catalina, using the newest Xcode. MacPorts > does not yet have a distribution for Catalina, so I built it from source as > well. It seems to work fine. I did have to make one change to the Portfile > for

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

> On 8 Oct 2019, at 09:57, Maria-Angeles Casares-de-Cal via lilypond-devel > wrote: > > For the attention of the Lilypond Developer Team: > > Lilypond is an remarkable app, but now Lilypond does not work with the new > Mac operating system (macOS 10.15 Catalina). > > Will we have news soon

Re: 64-bit version of Lilypond?

gt; Yes I read about the slow updating, but I guess that’s better than having > nothing. Is there a place that I could download that build? > >> On 1 Jul 2019, at 00:11, Hans Åberg wrote: >> >> >>> On 30 Jun 2019, at 22:49, Yentl Tijssens wrote: >>> >

Re: Executable options style question

> On 11 Jul 2019, at 09:32, Jacques Menu wrote: > > I’ve wondering about command line options with multiple values. > > Which one of the following in preferable in your opinion: > > DESSUS="Cor anglais" > xml2ly -msr-part-rename "P1 = ${DESSUS}" > > or: > > DESSUS="Cor anglais" > xml2ly

Re: 64-bit version of Lilypond?

> On 30 Jun 2019, at 22:49, Yentl Tijssens wrote: > > Hey, > > I’m a bit of a nooby tech enthusiast and upgraded to the Catalina Beta. Of > course Lilypond doesn’t work on that version because it is a 32-bit > application. > I saw your post and was wondering if you could provide me your way

Re: macOS 64-bit

> On 18 May 2019, at 02:58, Carl Sorensen wrote: > > I'm a Mac user and would love to get to 64 bit. It is already in MacPorts, both lilypond and lilypond-devel, and at least the latter seems to be working fine, though some systematic testing would be good.

Re: macOS 64-bit

> On 17 May 2019, at 21:37, Daniel Johnson wrote: > > I had to manually download, build and install the following: > - TeX Gyre font > - Flex 2.5.37 Later version of Flex have broken C++ generation. Akim Demaille found a way around this, maybe here:

Re: macOS 64-bit

> On 17 May 2019, at 21:48, Marnen Laibow-Koser wrote: > > On Fri, May 17, 2019 at 3:27 PM Hans Åberg wrote: > > > On 17 May 2019, at 21:14, Marnen Laibow-Koser wrote: > > > > On Fri, May 17, 2019 at 3:06 PM Hans Åberg wrote: > > > >

Re: macOS 64-bit

> On 17 May 2019, at 21:14, Marnen Laibow-Koser wrote: > > On Fri, May 17, 2019 at 3:06 PM Hans Åberg wrote: > >> LilyPond uses Guile 1.8, not the latest, and the lilypond in MacPorts uses >> gcc8, not the latest supported gcc9. >> > Will it build with GCC

Re: macOS 64-bit

> On 17 May 2019, at 16:10, Marnen Laibow-Koser wrote: > >> Given that MacPorts supports more packages than Homebrew this is a >> very bold statement. > > Homebrew supports enough packages, and it’s really easy to add new ones, so > that’s pretty much irrelevant. Somebody said it had problems

Re: macOS 64-bit

> On 17 May 2019, at 00:26, Marnen Laibow-Koser wrote: > > Perhaps I don’t understand. If GUB merely calls out to Xcode, how is this > a GPL3 issue? One needs to extract the SDK, and that has only been done for an old XCode version that is 32-bit, so it wouldn’t help anyway.

Re: macOS 64-bit

> On 17 May 2019, at 00:06, Jahrme Risner wrote: > > There is not, AFAIK, *any* elegant > solution to the usage of texlive on macOS. TeXLive is in MacPorts, and one can choose the components. Also, one can have different installers for the program and docs and merge the stuff.

Re: 64-bit version of Lilypond?

> On 15 Mar 2019, at 13:06, Karlin High wrote: > > On 3/15/2019 4:44 AM, Han-Wen Nienhuys wrote: >> I have been following this thread with half an eye. What is the > problem exactly? > Here's my understanding so far. > > * The next version of macOS will only run 64-bit software. (The current

Re: 64-bit version of Lilypond?

> On 15 Mar 2019, at 10:44, Han-Wen Nienhuys wrote: > > If Apple and their lawyers think it is fine to redistribute GPL > binaries made with XCode, then we should be fine too. The one you use now provides GCC4.2 I think it is, but later versions only provides Clang, not the real one but an

  1   2   3   >