Re: another 'wrong type argument' error

[Jonas Hahnfeld via LilyPond user discussion]

On Mon, 2022-10-17 at 20:11 +0100, Alex Harker wrote:
> Thanks for clarifying what would be helpful. I’m currently trying to
> get lilypond building locally with these scripts, although I’ve not
> managed to fully complete that process yet.
> 
> The dependencies were pretty much fine, but I had a 404 with zlib
> whilst downloading the source and had to move to the next version to
> get rid of that.

Sigh, the old zlib-1.2.12.tar.xz got moved away due to the fixed CVE. I
guess we'll need to update to 1.2.12 before the weekend then...

> I also managed to build the dependencies with a lower Mac OS
> requirement than the machine I was building on with very little in
> the way of added python code.

As I said, I still don't think this is the right way to go. The minimum
version is chosen for an objective reason (everything older is EOL by
Apple).

> When building lilypond I hit an issue with some old/partial version
> of harfbuzz in usr/local/ which I removed.
> Then I hit an error compiling the lexer, which as of yet I’ve not
> been able to trace.
> 
> I realise that the first priority is probably testing, but I’d like
> to be able to build as I feel I might be able to be more useful in
> that case. I also understand the fear about things breaking out of
> the blue, but for MacOS dev my experience is that if support for old
> Ones became an issue that’s more likely to be a compile-time, rather
> than a runtime issue.
> 
> In terms of testing - are there tests that would be good to run, or
> is the required testing more general (e.g. - it runs on an arbitrary
> lilypond score file).
> 
> In terms of Lilypond.app - I suspect this would be useful to maintain
> - it’s how I was using it until my latest system (at which point I
> moved to Frescobaldi to have a GUI - that’s a much nicer
> environment). I think the majority of Mac users wouldn’t be
> comfortable with a command-line interface, or having to deal with a
> separate GUI/environment to be installed onto. Thus, from my view
> this is about new adopters - getting people to try Lilypond in the
> first place.
> 
> I saw a branch that looked like it might be the old Mac app - I’d be
> happy to take a look once I can get lilypond building. Can someone
> confirm where this is? I presume the first goal would simply be to
> resurrect it as is? The packaging part is trivial - it’s the app
> itself will require more of look, but there are also tighter
> requirements in terms of code signing etc. these days in terms of
> getting around Apple’s gatekeeper and that would be something to
> think about later down the line, but only once the app was back up an
> running locally.

This was discussed before, and we *wanted* to get rid of LilyPad.
Please see Jean's answer for more details.

> Let me know also if I should continue any more technical questions
> here, or on another list.

Yes, let's stop hijacking this thread, the discussed topic has nothing
to do anymore with the original subject. Discussions like this should
happen in separate threads on lilypond-devel, not the -user list.

Jonas



signature.asc
Description: This is a digitally signed message part

Re: another 'wrong type argument' error

[Jean Abou Samra]

Hi,

I'm not a specialist of these topics, just replying to one
specific point…


Le 17/10/2022 à 21:11, Alex Harker a écrit :
*In terms of Lilypond.app* - I suspect this would be useful to 
maintain - it’s how I was using it until my latest system (at which 
point I moved to Frescobaldi to have a GUI - that’s a much nicer 
environment). I think the majority of Mac users wouldn’t be 
comfortable with a command-line interface, or having to deal with a 
separate GUI/environment to be installed onto. Thus, from my view this 
is about new adopters - getting people to try Lilypond in the first place.


I saw a branch that looked like it might be the old Mac app - I’d be 
happy to take a look once I can get lilypond building. Can someone 
confirm where this is?




https://github.com/gperciva/lilypad


I presume the first goal would simply be to resurrect it as is? The 
packaging part is trivial - it’s the app itself will require more of 
look, but there are also tighter requirements in terms of code signing 
etc. these days in terms of getting around Apple’s gatekeeper and that 
would be something to think about later down the line, but only once 
the app was back up an running locally.



I was actually *glad* to see the LilyPad app disappearing. Here
is my personal experience from initially trying LilyPond -- I
was on macOS at the time: I downloaded LilyPond.app as recommended
on the website, I saw there were GUI recommendations on the website
as well but didn't pay much attention, I used LilyPond in LilyPad
for two years or so, before I had the relief to discover Frescobaldi,
which is a *lot* more usable, and blamed myself for not trying
it earlier.

By default, people will choose whatever has been installed on their
computer, whatever you recommend them. By not providing a GUI, we
force people to install a decent editor, which is a bit more work
to install, but we also make their initial user experience a lot
more friendly. (And there is a gentle installation tutorial,
https://lilypond.org/doc/v2.23/Documentation/learning/graphical-setup-under-macos
on which I spent quite a lot of time ...)

In contrast, I think it would be great to have a way of installing
LilyPond that will look more familiar to macOS users (and thus
reassuring; in my experience people can be very afraid that software
they install might do something bad to their computer). But
*without* a GUI. Or perhaps just something that opens a window
saying that LilyPond has been installed successfully and pointing
to https://lilypond.org/easier-editing.html

Better yet: a .dmg package installing both Frescobaldi and LilyPond
together. The latest release of Frescobaldi is actually missing a
.dmg package, which is something you might want to help with ...
(CCing Davide about this.)

Best,
Jean

Re: another 'wrong type argument' error

[Karlin High]

On 10/13/2022 11:30 PM, Werner LEMBERG wrote:

actual Mac hardware


I have a 2012 MacBook Air, Intel Core i5, 4 GB RAM, macOS Catalina 
10.15.7, for an Apple-specific use case. I expect it will soon be left 
behind by the Apple upgrades train and need replaced for my purposes.


I could donate this to any developer wanting to take on responsibility 
for macOS releases. Or I could play a janitor role with it, such as 
having it sit here waiting for a GitLab Runner or equivalent.



--
Karlin High
Missouri, USA

Re: another 'wrong type argument' error

[Alex Harker]

Thanks for clarifying what would be helpful. I’m currently trying to get 
lilypond building locally with these scripts, although I’ve not managed to 
fully complete that process yet.

The dependencies were pretty much fine, but I had a 404 with zlib whilst 
downloading the source and had to move to the next version to get rid of that.
I also managed to build the dependencies with a lower Mac OS requirement than 
the machine I was building on with very little in the way of added python code.

When building lilypond I hit an issue with some old/partial version of harfbuzz 
in usr/local/ which I removed.
Then I hit an error compiling the lexer, which as of yet I’ve not been able to 
trace.

I realise that the first priority is probably testing, but I’d like to be able 
to build as I feel I might be able to be more useful in that case. I also 
understand the fear about things breaking out of the blue, but for MacOS dev my 
experience is that if support for old Ones became an issue that’s more likely 
to be a compile-time, rather than a runtime issue.

In terms of testing - are there tests that would be good to run, or is the 
required testing more general (e.g. - it runs on an arbitrary lilypond score 
file).

In terms of Lilypond.app - I suspect this would be useful to maintain - it’s 
how I was using it until my latest system (at which point I moved to 
Frescobaldi to have a GUI - that’s a much nicer environment). I think the 
majority of Mac users wouldn’t be comfortable with a command-line interface, or 
having to deal with a separate GUI/environment to be installed onto. Thus, from 
my view this is about new adopters - getting people to try Lilypond in the 
first place.

I saw a branch that looked like it might be the old Mac app - I’d be happy to 
take a look once I can get lilypond building. Can someone confirm where this 
is? I presume the first goal would simply be to resurrect it as is? The 
packaging part is trivial - it’s the app itself will require more of look, but 
there are also tighter requirements in terms of code signing etc. these days in 
terms of getting around Apple’s gatekeeper and that would be something to think 
about later down the line, but only once the app was back up an running locally.

Let me know also if I should continue any more technical questions here, or on 
another list.

Alex



> On 14 Oct 2022, at 19:02, Jonas Hahnfeld  wrote:
> 
> On Fri, 2022-10-14 at 04:30 +, Werner LEMBERG wrote:
>>> 
>>> In the spirit of my first comments in this email I’ll directly ask
>>> if the project needs help testing or working on the Mac build
>>> system at all?
>> 
>> Yes, we need help – namely for taking *permanent* care of the MacOS
>> releases in
>> 
>>   https://gitlab.com/lilypond/lilypond/-/releases
>> 
>> that have been built with the scripts in
>> 
>>   https://gitlab.com/lilypond/lilypond/-/tree/master/release
>> 
>> With 'permanent' I mean that the automatically created and released
>> binaries should be regularly tested on actual Mac hardware to check
>> whether they work as expected.  Jonas's fear is too real that some
>> day deployment support for older OS versions will break out of the
>> blue, unfortunately.
> 
> Slight clarification: the binaries are not created "automatically" by
> some CI pipeline or the like, but by executing the scripts linked above
> on a macOS node provided by MacStadium. But yes, testing them on a
> regular basis and in a wider set of configurations would be great.
> 
>> As Jonas writes: He isn't a MacOS users, and none of us main
>> developers is either.  It was a heroic effort of him to set up the
>> scripts, but details like handling deployment targets to make this
>> work on older MacOS versions needs a dedicated specialist.
> 
> The other point that was raised in the past was packaging as a
> LilyPond.app and a .dmg that users are more familiar with. In the end,
> it's "just" a special directory with some metadata files, but it needs
> somebody with the appropriate knowledge and hardware to figure out what
> needs to be done (if the idea is useful).
> 
> Jonas

Re: Building Mac OS LilyPond versions automatically (Was : another 'wrong type argument' error )

[Jonas Hahnfeld via LilyPond user discussion]

On Sun, 2022-10-16 at 11:20 +0200, Jacques Menu wrote:
> 
> 
> > Le 15 oct. 2022 à 21:16, Jonas Hahnfeld  a écrit
> > :
> > 
> > On Sat, 2022-10-15 at 21:09 +0200, Jacques Menu wrote:
> > > Hello Jonas,
> > > In my first attempt, I installed software on my machine with
> > > Homebrew and MacPorts, and you told me that was not the way to
> > > go.
> > > 
> > > I have the hardware and interest, but I’d need directives about
> > > how to proceed till I get a first version built the way needed to
> > > integrate that in the LilyPond production workflow.
> > > 
> > > Can someone provide that?
> > 
> > If you remember, we had a bit of discussion off list in September.
> > Basically, you need to run the scripts in the release/binaries/
> > directory. I just re-checked the log files you sent me back then,
> > and it appears that Ghostscript didn't compile. That's what you
> > need to solve as a first step, maybe looking at patches in MacPorts
> > or Homebrew…
> 
> OK.
> 
> And one I get this done, how do I integrate the result in the Lily
> build chain?

By making changes to said scripts and then submitting the patches.

Jonas


signature.asc
Description: This is a digitally signed message part

Re: Building Mac OS LilyPond versions automatically (Was : another 'wrong type argument' error )

[Jacques Menu]

> Le 15 oct. 2022 à 21:16, Jonas Hahnfeld  a écrit :
> 
> On Sat, 2022-10-15 at 21:09 +0200, Jacques Menu wrote:
>> Hello Jonas,
>> 
>>> Le 14 oct. 2022 à 20:05, Jonas Hahnfeld  a écrit :
>>> 
>>> (regarding "automatically" in the title, please see my other reply)
>>> 
>>> To be clear, I my self am not working on this due to lack of hardware.
>>> If somebody wants to give it a try, that would again be great. I can of
>>> course try to assist, but remote debugging only gets us that far…
>> 
>> 
>> In my first attempt, I installed software on my machine with Homebrew and
>> MacPorts, and you told me that was not the way to go.
>> 
>> I have the hardware and interest, but I’d need directives about how to
>> proceed till I get a first version built the way needed to integrate that
>> in the LilyPond production workflow.
>> 
>> Can someone provide that?
> 
> If you remember, we had a bit of discussion off list in September.
> Basically, you need to run the scripts in the release/binaries/
> directory. I just re-checked the log files you sent me back then, and
> it appears that Ghostscript didn't compile. That's what you need to
> solve as a first step, maybe looking at patches in MacPorts or
> Homebrew…


OK.

And one I get this done, how do I integrate the result in the Lily build chain?

JM

Re: Building Mac OS LilyPond versions automatically (Was : another 'wrong type argument' error )

[Jonas Hahnfeld via LilyPond user discussion]

On Sat, 2022-10-15 at 21:09 +0200, Jacques Menu wrote:
> Hello Jonas,
> 
> > Le 14 oct. 2022 à 20:05, Jonas Hahnfeld  a écrit :
> > 
> > (regarding "automatically" in the title, please see my other reply)
> > 
> > To be clear, I my self am not working on this due to lack of hardware.
> > If somebody wants to give it a try, that would again be great. I can of
> > course try to assist, but remote debugging only gets us that far…
> 
> 
> In my first attempt, I installed software on my machine with Homebrew and
> MacPorts, and you told me that was not the way to go.
> 
> I have the hardware and interest, but I’d need directives about how to
> proceed till I get a first version built the way needed to integrate that
> in the LilyPond production workflow.
> 
> Can someone provide that?

If you remember, we had a bit of discussion off list in September.
Basically, you need to run the scripts in the release/binaries/
directory. I just re-checked the log files you sent me back then, and
it appears that Ghostscript didn't compile. That's what you need to
solve as a first step, maybe looking at patches in MacPorts or
Homebrew...

Jonas


signature.asc
Description: This is a digitally signed message part

Re: Building Mac OS LilyPond versions automatically (Was : another 'wrong type argument' error )

[Jacques Menu]

Hello Jonas,

> Le 14 oct. 2022 à 20:05, Jonas Hahnfeld  a écrit :
> 
> (regarding "automatically" in the title, please see my other reply)
> 
> To be clear, I my self am not working on this due to lack of hardware.
> If somebody wants to give it a try, that would again be great. I can of
> course try to assist, but remote debugging only gets us that far…


In my first attempt, I installed software on my machine with Homebrew and 
MacPorts, and you told me that was not the way to go.

I have the hardware and interest, but I’d need directives about how to proceed 
till I get a first version built the way needed to integrate that in the 
LilyPond production workflow.

Can someone provide that?

JM

Re: Building Mac OS LilyPond versions automatically (Was : another 'wrong type argument' error )

[Jonas Hahnfeld via LilyPond user discussion]

(regarding "automatically" in the title, please see my other reply)

On Fri, 2022-10-14 at 08:29 +0200, Jacques Menu wrote:
> Hello folks,
> 
> I’m a regular user of Mac OS, which I use for development, and
> will help with the creation of LilyPond versions with pleasure.
> 
> My last try at building LilyPond from the source code on my Mac
> Mini M1 failed due to a library not being ported yet to this
> architecture, but Jonas told me that this should come with the
> current efforts by the developers team.

To be clear, I my self am not working on this due to lack of hardware.
If somebody wants to give it a try, that would again be great. I can of
course try to assist, but remote debugging only gets us that far...

Jonas
> 


signature.asc
Description: This is a digitally signed message part

Re: another 'wrong type argument' error

[Jonas Hahnfeld via LilyPond user discussion]

On Fri, 2022-10-14 at 04:30 +, Werner LEMBERG wrote:
> > 
> > In the spirit of my first comments in this email I’ll directly ask
> > if the project needs help testing or working on the Mac build
> > system at all?
> 
> Yes, we need help – namely for taking *permanent* care of the MacOS
> releases in
> 
>   https://gitlab.com/lilypond/lilypond/-/releases
> 
> that have been built with the scripts in
> 
>   https://gitlab.com/lilypond/lilypond/-/tree/master/release
> 
> With 'permanent' I mean that the automatically created and released
> binaries should be regularly tested on actual Mac hardware to check
> whether they work as expected.  Jonas's fear is too real that some
> day deployment support for older OS versions will break out of the
> blue, unfortunately.

Slight clarification: the binaries are not created "automatically" by
some CI pipeline or the like, but by executing the scripts linked above
on a macOS node provided by MacStadium. But yes, testing them on a
regular basis and in a wider set of configurations would be great.

> As Jonas writes: He isn't a MacOS users, and none of us main
> developers is either.  It was a heroic effort of him to set up the
> scripts, but details like handling deployment targets to make this
> work on older MacOS versions needs a dedicated specialist.

The other point that was raised in the past was packaging as a
LilyPond.app and a .dmg that users are more familiar with. In the end,
it's "just" a special directory with some metadata files, but it needs
somebody with the appropriate knowledge and hardware to figure out what
needs to be done (if the idea is useful).

Jonas


signature.asc
Description: This is a digitally signed message part

Building Mac OS LilyPond versions automatically (Was : another 'wrong type argument' error )

[Jacques Menu]

Hello folks,

I’m a regular user of Mac OS, which I use for development, and will help with 
the creation of LilyPond versions with pleasure.

My last try at building LilyPond from the source code on my Mac Mini M1 failed 
due to a library not being ported yet to this architecture, but Jonas told me 
that this should come with the current efforts by the developers team.

Hope that helps!

JM

> Le 14 oct. 2022 à 06:30, Werner LEMBERG  a écrit :
> 
> 
>>> So you checked all of LilyPond's dependencies and can guarantee
>>> that it will stay like this forever?
>> 
>> I am on Big Sur (11.6) and I can still choose 10.9 as a deployment
>> target.  [...]
> 
>>> I'm not going to work on anything. I have been alone trying to get
>>> a build for macOS even though I don't even use Apple hardware and
>>> other core developers do. It will take somebody willing to work on
>>> this effort *and commit to maintaining it* because I don't think
>>> it's a good idea to release something half-working.
>> 
>> In the spirit of my first comments in this email I’ll directly ask
>> if the project needs help testing or working on the Mac build system
>> at all?
> 
> Yes, we need help – namely for taking *permanent* care of the MacOS
> releases in
> 
>  https://gitlab.com/lilypond/lilypond/-/releases
> 
> that have been built with the scripts in
> 
>  https://gitlab.com/lilypond/lilypond/-/tree/master/release
> 
> With 'permanent' I mean that the automatically created and released
> binaries should be regularly tested on actual Mac hardware to check
> whether they work as expected.  Jonas's fear is too real that some day
> deployment support for older OS versions will break out of the blue,
> unfortunately.
> 
> As Jonas writes: He isn't a MacOS users, and none of us main
> developers is either.  It was a heroic effort of him to set up the
> scripts, but details like handling deployment targets to make this
> work on older MacOS versions needs a dedicated specialist.
> 
> 
>Werner

Re: another 'wrong type argument' error

[Werner LEMBERG]

>> So you checked all of LilyPond's dependencies and can guarantee
>> that it will stay like this forever?
> 
> I am on Big Sur (11.6) and I can still choose 10.9 as a deployment
> target.  [...]

>> I'm not going to work on anything. I have been alone trying to get
>> a build for macOS even though I don't even use Apple hardware and
>> other core developers do. It will take somebody willing to work on
>> this effort *and commit to maintaining it* because I don't think
>> it's a good idea to release something half-working.
> 
> In the spirit of my first comments in this email I’ll directly ask
> if the project needs help testing or working on the Mac build system
> at all?

Yes, we need help – namely for taking *permanent* care of the MacOS
releases in

  https://gitlab.com/lilypond/lilypond/-/releases

that have been built with the scripts in

  https://gitlab.com/lilypond/lilypond/-/tree/master/release

With 'permanent' I mean that the automatically created and released
binaries should be regularly tested on actual Mac hardware to check
whether they work as expected.  Jonas's fear is too real that some day
deployment support for older OS versions will break out of the blue,
unfortunately.

As Jonas writes: He isn't a MacOS users, and none of us main
developers is either.  It was a heroic effort of him to set up the
scripts, but details like handling deployment targets to make this
work on older MacOS versions needs a dedicated specialist.


Werner

Re: another 'wrong type argument' error

[David Kastrup]

David Wright  writes:

> No problem for a 1.5GHz 32-bit processor with 512MB memory.
> BTW the term "plain x86" is almost meaningless. For a start,
> are you talking about the processor, or the architecture?
> Debian's "amd64" architecture is still an x86, just 64-bit.

Well, for one thing one should not rely on a mathematical coprocessor.
It was optional (and not exactly cheap) with the 80386.  And yes, I did
run Linux (and previously UNIX) on an 80SX386, the 8-bit bus version of
the 80386 processor, though mainly as a thin client to a full-fledged
80486 server with a whopping 16MB of RAM and a SCSI hard disk with over
100MB of capacity.

I think we used Interactive UNIX and Coherent UNIX before converging on
Linux when it became useable (which was a surprisingly short time after
it became available first, something like 1 or 2 years).

-- 
David Kastrup

Re: another 'wrong type argument' error

[David Wright]

On Mon 10 Oct 2022 at 12:06:11 (+0100), Wols Lists wrote:
> On 10/10/2022 06:43, Jean Abou Samra wrote:
> > The problem isn’t LilyPond’s or its dependencies’ support for older macOS, 
> > which is better than even the system support. The real problem is Apple 
> > preventing you from upgrading your computer past a certain macOS version.
> 
> Which is probably down to newer versions of MacOS taking advantage of
> new chip features.
> 
> Linux drops support for older chips over time - it's almost impossible
> to get a distro that supports plain x86 any more ...

Hmm. My 2004 Acer Travelmate is currently running Debian/stable with
Linux acer 5.10.0-18-686 #1 SMP Debian 5.10.140-1 (2022-09-02) i686 GNU/Linux
and it can run FireFox, but slowly. Linux 5.10 is a longterm release;
kernel.org currently shows support until December 2026. The Debian/testing
installation manual still shows i386 support for their ~2023 release.

With the Travelmate, I just ran the source for K310 supplied in
https://lists.gnu.org/archive/html/lilypond-user/2020-10/msg00344.html
on Debian/stable's 2.22 i386 version, and the PDF output is visually
indistinguishable from that produced by 2.23.10 on current hardware.
Here's the log:

09:47:37 /tmp$ lily -d K-310 # -d selects the Debian-installed version of LP
/usr/bin/lilypond -dno-point-and-click K-310.ly
GNU LilyPond 2.22.0
Processing `K-310.ly'
Parsing...
Interpreting 
music...[8][16][24][32][40][48][56][64][72][80][88][96][104][112][120][128]
Preprocessing graphical objects...
Interpreting music...[8][16][24][32][40][48][56][64][72][80][88]
Preprocessing graphical objects...
Interpreting music...
warning: type check for `beatStructure' failed; value `1' must be of type `list'
[8][16][24][32][40][48][56][64][72][80][88][96][104][112][120][128][136][144][152][160][168][176][184][192][200][208][216][224][232][240][248]
Preprocessing graphical objects...
Finding the ideal number of pages...
Fitting music on 19 or 20 pages...
Drawing systems...
Converting to `K-310.pdf'...
Success: compilation successfully completed
09:48:31 /tmp$ 

No problem for a 1.5GHz 32-bit processor with 512MB memory.
BTW the term "plain x86" is almost meaningless. For a start,
are you talking about the processor, or the architecture?
Debian's "amd64" architecture is still an x86, just 64-bit.

> Because Apple has
> far tighter integration between computer and OS, they can more easily
> upgrade in lock-step.

Cheers,
David.

Re: another 'wrong type argument' error

[Alex Harker]

On 10 Oct 2022, at 20:29, Jonas Hahnfeld  wrote:

> Yes, I build on macOS 10.15 and it will work on versions newer than
> that, as also announced with the first release of this infrastructure:
> https://lists.gnu.org/archive/html/lilypond-user/2022-02/msg00155.html

I wanted to say that I didn’t mean to cause any friction in raising this issue 
about min deployment targets. I did my first serious project in lilypond in 
2021 and was super impressed with what I was able to achieve in terms of custom 
notation / layout etc. It’s an excellent project, and when recently moving to a 
newer MacOS the lack of as easy a route to running it was a little frustrating 
- I’m just interested in it being as available as possible to different people. 
I’m personally very grateful to anyone working on it for maintaining something 
so valuable.

>> I read that SDK 10.14.1 supports 10.9 as the oldest version 
> 
> So you checked all of LilyPond's dependencies and can guarantee that it
> will stay like this forever?

I am on Big Sur (11.6) and I can still choose 10.9 as a deployment target. FWIW 
I consider that to be a little beyond what I’d normally support (10.11 is about 
my cutoff), but it is still possible. In terms of the dependencies, that was 
the thing that I hadn’t considered detail  and it really depends how the build 
system works how much hassle it would be - if this can be set in one place then 
it would be straightforward to try, if it’s a matter of the individual 
dependencies approach to building then it’s totally different. As far as I can 
reason any incompatibility should break at compile time, however, rather than 
runtime, as this is about hooks in OS routines, and not any of the other code. 
It looks (from above) like a MacPorts build for 10.13 does currently work.

> For the record, the easier variant of this setting is the environment
> variable MACOSX_DEPLOYMENT_TARGET.

That makes sense - that’s what you’d set in Xcode - I just went directly for 
the clang/llvm docs and I wasn’t sure if it was an alias, but an environment 
variable would be easiest.

>> Whatever Jonas is able to manage with his build setup,
> 
> I'm not going to work on anything. I have been alone trying to get a
> build for macOS even though I don't even use Apple hardware and other
> core developers do. It will take somebody willing to work on this
> effort *and commit to maintaining it* because I don't think it's a good
> idea to release something half-working.

In the spirit of my first comments in this email I’ll directly ask if the 
project needs help testing or working on the Mac build system at all? I would 
be interested in helping out if it is needed, and I maintain and work on some 
other open source projects (https://github.com/AlexHarker 
 / https://github.com/iPlug2/iPlug2 
), with Mac as my main platform for 
development.

Jonas - thanks for your work on the Mac builds. It is appreciated here and I’m 
sure by lots of other people.

Alex

Re: another 'wrong type argument' error

[Thomas Morley]

Am Mi., 12. Okt. 2022 um 11:37 Uhr schrieb Thomas Morley
:
>
> Am Mo., 10. Okt. 2022 um 21:04 Uhr schrieb Kieren MacMillan
> :
> >
> > Hi Jean,
> >
> > > This looks like you have done something like
> > > { c'\custdyn "p" }
> > > instead of
> > > { c'\custdyn "{p}" }
> >
> > Hmmm… the only three calls I have look like the second (correct) version, 
> > not the first. But switching those three custom dynamics to simple/native 
> > dynamics eliminates the error, so it's definitely something in that code 
> > that's breaking.
> >
> > Because I need to keep ploughing forward on this score, I'm going to bail 
> > here and just leave them as simple dynamics… When I can take a breath (next 
> > week?), I'll return and see if I/we can figure out the real root of the 
> > problem.
> >
> > Thank you so much for all your help!
> > Kieren.
>
> Hi Kieren,
>
> sorry for the delay...
> I wrote the original code for 2.19.65 and overlooked the bug you
> encountered - it happens if the string-argument is plain text, i.e. no
> dynamics are present, _and_ no spaces occur like "laut", "sehr laut"
> would have worked.
> Furhermore there were a guile1/guile2 problem: `split-at' behaves
> differently now.
> The definition for `note-column::main-extent' is now superflous, can
> be retrieved by calling NoteColumn.main-extent.
>
> Attached you'll find the newest code.
>

Aargh, still an oversight...
New file attached.

>
> You need to rename the function `dynamicH' to `custdyn'
>
> Though, there's currently a patch waiting for 2.25. deleting the
> \simple-markup-command.
> https://gitlab.com/lilypond/lilypond/-/merge_requests/1650
> If merged it will break the coding again.
> While it is possible to work around I'll object to this change.
>
> Cheers,
>   Harm
\version "2.23.13"


 DynamicText, created on the fly

 Reads
  DynamicText.details.separator-pair
  DynamicText.details.dyn-rest-font-sizes
  DynamicText.details.markup-commands
  DynamicText.details.inner-x-space
  DynamicText.details.outer-x-space

#(use-modules (ice-9 regex))
  
#(define remove-empty
  ;; Remove empty strings and empty lists from the given list 'lst'
  (lambda (lst)
(remove 
  (lambda (e) 
(or
  (and (string? e) (string-null? e))
  (and (list? e) (null? e
  lst)))

#(define char-set:dynamics
  (char-set #\f #\m #\p #\r #\s #\z)) 
  
#(define (make-reg-exp separator-pair)
  (format #f "\\~a[^~a~a]*\\~a"
(car separator-pair)
(car separator-pair)
(cdr separator-pair)
(cdr separator-pair)))

#(define (dynamics-list separator-pair strg)
  (let ((reg-exp (make-reg-exp separator-pair))
(separators (char-set (car separator-pair) (cdr separator-pair
(map
  (lambda (s)
(let* ((match (string-match reg-exp s)))
   (if match 
   (let* ((poss-dyn (match:substring match))
  (cand (string-trim-both poss-dyn separators)))
 (if (string-every char-set:dynamics cand)
   (list
 (match:prefix match)
 cand
 (match:suffix match))
 s))  
   s)))
  (string-split strg #\space
  
#(define (dynamic-text::format-text 
   fontsizes inner-kern outer-kern text-markup-command lst)
  (let* ((mrkp-cmnd
   (lambda (arg) (make-normal-text-markup (text-markup-command arg
 (txt-font-size (if (pair? fontsizes) (cdr fontsizes) #f))
 (txt-mrkp-cmnd
   (lambda (txt)
 (if (number? txt-font-size)
 (make-fontsize-markup txt-font-size (mrkp-cmnd txt))
 (mrkp-cmnd txt
 (left-out (if (pair? outer-kern) (car outer-kern) #f))
 (left-inner (if (pair? inner-kern) (car inner-kern) #f))
 (right-inner (if (pair? inner-kern) (cdr inner-kern) #f))
 (right-out (if (pair? outer-kern) (cdr outer-kern) #f))
 (space-mrkp-cmd
   (lambda (space)
 (if (number? space)
 (txt-mrkp-cmnd (make-hspace-markup space))
 ""
(map
  (lambda (e)
(if (list? e)
(remove-empty
  (list
(cond ((and (string-null? (car e)) (equal? e (car lst))) '())
  ((string-null? (car e))
(space-mrkp-cmd left-out))
  ((and (not (string-null? (car e))) (equal? e (car lst)))
(make-concat-markup
(remove-empty
  (list
(txt-mrkp-cmnd (car e))
(space-mrkp-cmd left-inner)
  (else
(make-concat-markup
(remove-empty
  (list
(space-mrkp-cmd 

Re: another 'wrong type argument' error

[Thomas Morley]

Am Mo., 10. Okt. 2022 um 21:04 Uhr schrieb Kieren MacMillan
:
>
> Hi Jean,
>
> > This looks like you have done something like
> > { c'\custdyn "p" }
> > instead of
> > { c'\custdyn "{p}" }
>
> Hmmm… the only three calls I have look like the second (correct) version, not 
> the first. But switching those three custom dynamics to simple/native 
> dynamics eliminates the error, so it's definitely something in that code 
> that's breaking.
>
> Because I need to keep ploughing forward on this score, I'm going to bail 
> here and just leave them as simple dynamics… When I can take a breath (next 
> week?), I'll return and see if I/we can figure out the real root of the 
> problem.
>
> Thank you so much for all your help!
> Kieren.

Hi Kieren,

sorry for the delay...
I wrote the original code for 2.19.65 and overlooked the bug you
encountered - it happens if the string-argument is plain text, i.e. no
dynamics are present, _and_ no spaces occur like "laut", "sehr laut"
would have worked.
Furhermore there were a guile1/guile2 problem: `split-at' behaves
differently now.
The definition for `note-column::main-extent' is now superflous, can
be retrieved by calling NoteColumn.main-extent.

Attached you'll find the newest code.
You need to rename the function `dynamicH' to `custdyn'

Though, there's currently a patch waiting for 2.25. deleting the
\simple-markup-command.
https://gitlab.com/lilypond/lilypond/-/merge_requests/1650
If merged it will break the coding again.
While it is possible to work around I'll object to this change.

Cheers,
  Harm
\version "2.23.13"


 DynamicText, created on the fly

 Reads
  DynamicText.details.separator-pair
  DynamicText.details.dyn-rest-font-sizes
  DynamicText.details.markup-commands
  DynamicText.details.inner-x-space
  DynamicText.details.outer-x-space

#(use-modules (ice-9 regex))
  
#(define remove-empty
  ;; Remove empty strings and empty lists from the given list 'lst'
  (lambda (lst)
(remove 
  (lambda (e) 
(or
  (and (string? e) (string-null? e))
  (and (list? e) (null? e
  lst)))

#(define char-set:dynamics
  (char-set #\f #\m #\p #\r #\s #\z)) 
  
#(define (make-reg-exp separator-pair)
  (format #f "\\~a[^~a~a]*\\~a"
(car separator-pair)
(car separator-pair)
(cdr separator-pair)
(cdr separator-pair)))

#(define (dynamics-list separator-pair strg)
  (let ((reg-exp (make-reg-exp separator-pair))
(separators (char-set (car separator-pair) (cdr separator-pair
(map
  (lambda (s)
(let* ((match (string-match reg-exp s)))
   (if match 
   (let* ((poss-dyn (match:substring match))
  (cand (string-trim-both poss-dyn separators)))
 (if (string-every char-set:dynamics cand)
   (list
 (match:prefix match)
 cand
 (match:suffix match))
 s))  
   s)))
  (string-split strg #\space
  
#(define (dynamic-text::format-text 
   fontsizes inner-kern outer-kern text-markup-command lst)
  (let* ((mrkp-cmnd
   (lambda (arg) (make-normal-text-markup (text-markup-command arg
 (txt-font-size (if (pair? fontsizes) (cdr fontsizes) #f))
 (txt-mrkp-cmnd
   (lambda (txt)
 (if (number? txt-font-size)
 (make-fontsize-markup txt-font-size (mrkp-cmnd txt))
 (mrkp-cmnd txt
 (left-out (if (pair? outer-kern) (car outer-kern) #f))
 (left-inner (if (pair? inner-kern) (car inner-kern) #f))
 (right-inner (if (pair? inner-kern) (cdr inner-kern) #f))
 (right-out (if (pair? outer-kern) (cdr outer-kern) #f))
 (space-mrkp-cmd
   (lambda (space)
 (if (number? space)
 (txt-mrkp-cmnd (make-hspace-markup space))
 ""
(map
  (lambda (e)
(if (list? e)
(remove-empty
  (list
(cond ((and (string-null? (car e)) (equal? e (car lst))) '())
  ((string-null? (car e))
(space-mrkp-cmd left-out))
  ((and (not (string-null? (car e))) (equal? e (car lst)))
(make-concat-markup
(remove-empty
  (list
(txt-mrkp-cmnd (car e))
(space-mrkp-cmd left-inner)
  (else
(make-concat-markup
(remove-empty
  (list
(space-mrkp-cmd left-out)
(txt-mrkp-cmnd (car e))
(space-mrkp-cmd left-inner))
(second e)
(cond ((and (string-null? (last e)) 

Re: another 'wrong type argument' error

[Werner LEMBERG]

>> I read that SDK 10.14.1 supports 10.9 as the oldest version (I
>> couldn't quickly find the lowest value for SDK 10.15).  AFAIK, we
>> don't use any functionality that is available on newer macOS
>> versions only, so this route seems safe.
> 
> So you checked all of LilyPond's dependencies and can guarantee that
> it will stay like this forever?

I didn't, and of course I can't give any guaranties.

> For the record, the easier variant of this setting is the
> environment variable MACOSX_DEPLOYMENT_TARGET.

OK.

>> Whatever Jonas is able to manage with his build setup,
> 
> I'm not going to work on anything.  [...]

OK.  I agree that without a MacOS developer who has active interest in
maintaining support for older versions we cannot follow this path.


Werner

Re: another 'wrong type argument' error

[Jonas Hahnfeld via LilyPond user discussion]

On Mon, 2022-10-10 at 05:10 +, Werner LEMBERG wrote:
> > Confirmed using otool that the minimum OS for the linked build is
> > 10.15:
> > 
> > Load command 10
> >    cmd LC_BUILD_VERSION
> >    cmdsize 32
> >    platform 1
> >    minos 10.15
> >    sdk 10.15.6
> 
> Thanks.

Yes, I build on macOS 10.15 and it will work on versions newer than
that, as also announced with the first release of this infrastructure:
https://lists.gnu.org/archive/html/lilypond-user/2022-02/msg00155.html

> > That is certain to be the reason why it doesn’t run, but I suspect
> > a local build might run fine. I’d suggest setting this lower for
> > binary releases if there’s no pressing reason to require 10.15 on
> > Mac.
> 
> Sounds sensible.  Jonas?

I don't agree; I chose macOS 10.15 as a target because it was, until
recently, the oldest supported version. If we try to lower this
requirement I have no idea what will be work, and even worse I don't
have the possibility to test it. FWIW Homebrew also only actively
supports macOS 10.15, everything below that is provided on a best-
effort basis (and may be broken to a certain degree).

> On page
>  
> https://smallhacks.wordpress.com/2018/11/11/how-to-support-old-osx-version-with-a-recent-xcode/
> 
> I read that SDK 10.14.1 supports 10.9 as the oldest version (I
> couldn't quickly find the lowest value for SDK 10.15).  AFAIK, we
> don't use any functionality that is available on newer macOS versions
> only, so this route seems safe.

So you checked all of LilyPond's dependencies and can guarantee that it
will stay like this forever?

> > For reference when using clang/llvm the relevant compiler flag to
> > set the deployment target is:
> > 
> > -mmacos-version-min=
> 
> BTW, this flag is necessary for both compiling and linking.

For the record, the easier variant of this setting is the environment
variable MACOSX_DEPLOYMENT_TARGET.

> Whatever Jonas is able to manage with his build setup,

I'm not going to work on anything. I have been alone trying to get a
build for macOS even though I don't even use Apple hardware and other
core developers do. It will take somebody willing to work on this
effort *and commit to maintaining it* because I don't think it's a good
idea to release something half-working.

> I suggest to add a note to the download section(s) like the
> following:
> 
>   The macOS x86_64 binary works with macOS X.Y and higher.  For older
>   macOS versions please use MacPorts.

Yes, we can do that once we have the stable release and the binaries
are available from the Downloads page, it's generally not written on
the Development page.

Jonas


signature.asc
Description: This is a digitally signed message part

Re: another 'wrong type argument' error

[Jonas Hahnfeld via LilyPond user discussion]

On Mon, 2022-10-10 at 08:08 +0200, Jean Abou Samra wrote:
> 
> > Le 9 oct. 2022 à 22:45, Kieren MacMillan  a 
> > écrit :
> > 
> > dyld: Symbol not found: _iconv
> >  Referenced from: /usr/lib/libcups.2.dylib
> >  Expected in: /opt/local/lib/libiconv.2.dylib
> > in /usr/lib/libcups.2.dylib
> > Abort trap: 6
> 
> What surprises me in this error message is that mentions a dynamic library
> in /opt/local/lib, which I read is for MacPorts, but I thought we were
> linking with dependencies like libiconv statically. Where am I going wrong
> in my thinking?

We are only building libiconv for Windows; on the other platforms
(Linux, macOS, and also FreeBSD) it's provided by the system. On Linux
it's included in glibc and on macOS (at least on version 10.15) there
is /usr/lib/libiconv.2.dylib which apparently MacPorts replaces with
their own version. I'm not sure though at what point libcups.2.dylib
come in...

Jonas


signature.asc
Description: This is a digitally signed message part

Re: another 'wrong type argument' error

[Kieren MacMillan]

Hi Jean,

> This looks like you have done something like
> { c'\custdyn "p" }
> instead of
> { c'\custdyn "{p}" }

Hmmm… the only three calls I have look like the second (correct) version, not 
the first. But switching those three custom dynamics to simple/native dynamics 
eliminates the error, so it's definitely something in that code that's breaking.

Because I need to keep ploughing forward on this score, I'm going to bail here 
and just leave them as simple dynamics… When I can take a breath (next week?), 
I'll return and see if I/we can figure out the real root of the problem.

Thank you so much for all your help!
Kieren.

Re: another 'wrong type argument' error

[Jean Abou Samra]

Le 10/10/2022 à 19:07, Kieren MacMillan a écrit :

Hi Jean,


Can you send the complete code? It seems to be missing
the function dynamic-text::structered-list.

I've attached the include file I use.

Thanks!
Kieren.




This looks like you have done something like

{ c'\custdyn "p" }

instead of

{ c'\custdyn "{p}" }

The code tries to center the first (by default) dynamic
(i.e., "{...}") part encountered in the custom dynamic
text under the note. If there is no dynamic part, this
doesn't work.

Cheers,
Jean

Re: another 'wrong type argument' error

[Kieren MacMillan]

Hi Jean,

> Can you send the complete code? It seems to be missing
> the function dynamic-text::structered-list.

I've attached the include file I use.

Thanks!
Kieren.



dynamics_on-the-fly.ly
Description: Binary data

Re: another 'wrong type argument' error

[Kieren MacMillan]

Hi Jean,

> Re screenshot: what editor are you using?
> 
> In Frescobaldi, it seems that there is a glitch that prevents from
> pasting from the log output if you have selected something at the same
> time in the LilyPond code view, because that takes priority apparently,
> but in my experience, if you stop selecting something in the code,
> copy-pasting from the log works just fine.

FYI: That worked. Thanks!
Kieren.

Re: another 'wrong type argument' error

[Kieren MacMillan]

p.s. 

> Looking at dynamics_on-the-fly.ly, line 294+ is
> 
>   (if (pair? prev-self-alignment-X-tweaks)
>   '()
>   (ly:grob-set-property! grob 'X-offset
> (let* ((x-exts
>  (map
>(lambda (stil) (ly:stencil-extent stil X))
>(take all-stils 2)))
>(x-par (ly:grob-parent grob X))
>(parent-x-ext-center
>  (interval-center
>(if (ly:grob-property grob
>  'X-align-on-main-noteheads)
>(note-column::main-extent x-par)
>(ly:grob-extent x-par x-par X
> 
> with line 300 being
> 
>(take all-stils 2)))
> 
> What's the patch?

Looks like the definition [earlier in the code] is

(all-stils
  (map
(lambda (mrkp)
  (if (null? mrkp)
  empty-stencil
  (grob-interpret-markup grob
(if (markup-list? mrkp)
(make-concat-markup mrkp)
mrkp
  stil-candidates))

In case that helps…?

Thanks,
Kieren.

Re: another 'wrong type argument' error

[Jean Abou Samra]

Le 10/10/2022 à 18:56, Kieren MacMillan a écrit :

Hi Jean (et al.),


Heh, 2.23.14 _just_ came out.

MacPorts got updated.
I upgraded.



Good news! The maintainer is pretty reactive.




try using that and putting #(ly:set-option 'compile-scheme-code) at the top of 
your file (before any includes).
Also add #(debug-enable 'backtrace) for best results.

Done. Result:
[...]



Can you send the complete code? It seems to be missing
the function dynamic-text::structered-list.

Re: another 'wrong type argument' error

[Kieren MacMillan]

Hi Jean (et al.),

> Heh, 2.23.14 _just_ came out.

MacPorts got updated.
I upgraded.

> try using that and putting #(ly:set-option 'compile-scheme-code) at the top 
> of your file (before any includes).
> Also add #(debug-enable 'backtrace) for best results.

Done. Result:

 Preprocessing graphical objects...Backtrace:
   9 (apply-smob/1 #)
In 
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_textproc_lilypond/lilypond-devel/work/lilypond-2.23.14/out/share/lilypond/current/scm/lily/lily.scm:
   876:16  8 (lilypond-main _)
905:4  7 (lilypond-all _)
In srfi/srfi-1.scm:
640:9  6 (for-each # ?)
In 
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_textproc_lilypond/lilypond-devel/work/lilypond-2.23.14/out/share/lilypond/current/scm/lily/lily.scm:
915:9  5 (_ _)
In ice-9/boot-9.scm:
829:9  4 (catch _ _ # ?)
In unknown file:
   3 (ly:parse-file "/Users/kmac/Documents/01_music/scores/3?")
   2 (ly:book-process # #< Output_def> #< Output_def> #)
In 
/Users/kmac/Documents/01_music/scores/_include/init/Workarounds/dynamics_on-the-fly.ly:
   300:32  1 (tweak-proc #)
In unknown file:
   0 (list-head () 2)

Looking at dynamics_on-the-fly.ly, line 294+ is

   (if (pair? prev-self-alignment-X-tweaks)
   '()
   (ly:grob-set-property! grob 'X-offset
 (let* ((x-exts
  (map
(lambda (stil) (ly:stencil-extent stil X))
(take all-stils 2)))
(x-par (ly:grob-parent grob X))
(parent-x-ext-center
  (interval-center
(if (ly:grob-property grob
  'X-align-on-main-noteheads)
(note-column::main-extent x-par)
(ly:grob-extent x-par x-par X

with line 300 being

(take all-stils 2)))

What's the patch?

Thanks!
Kieren.

Re: another 'wrong type argument' error

[Kieren MacMillan]

Hi all,

> one cannot expect bleeding-edge software to run on unsupported OSes

For sure… I guess I just never thought of Lilypond as "bleeding-edge" before!  
:)

> My point was to
> temper the movement to investigate technical details of supporting
> old macOS and remind that it is already painful enough for us to
> support current OSes and architectures.

I don't want any real development bandwidth spent on this issue: If it's a 
matter of just setting a 'minos' parameter and everything works perfectly, then 
great — if it's more than that, or if lowering the minos breaks something else, 
then the dev-pool shouldn't pursue it further.

> PS: my offer to look at the file if provided with it still stands.

I appreciate the offer, and will try to send you something the moment I have 
the chance. (Right now, I'm scrambling to get other scores composed, arranged, 
input, and compiled — rehearsals start on Wednesday!)

Thanks (all!) for your help.
Kieren.

Re: another 'wrong type argument' error

[Jean Abou Samra]

Le 10/10/2022 à 13:06, Wols Lists a écrit :

On 10/10/2022 06:43, Jean Abou Samra wrote:
The problem isn’t LilyPond’s or its dependencies’ support for older 
macOS, which is better than even the system support. The real problem 
is Apple preventing you from upgrading your computer past a certain 
macOS version.


Which is probably down to newer versions of MacOS taking advantage of 
new chip features.


Linux drops support for older chips over time - it's almost impossible 
to get a distro that supports plain x86 any more ... Because Apple has 
far tighter integration between computer and OS, they can more easily 
upgrade in lock-step.





Well, it is also a part of their business model. At any rate,
I don't necessarily want to judge the merits of an OS/company,
but to explain that one cannot expect bleeding-edge software to
run on unsupported OSes. When you buy Apple hardware, you know
upfront what to expect with respect to upgrades. My point was to
temper the movement to investigate technical details of supporting
old macOS and remind that it is already painful enough for us to
support current OSes and architectures.

It is a perfectly reasonable solution to hope some people with
actual hardware running old macOS versions and with expertise in
macOS to produce adequate binaries, like MacPorts should be doing
shortly. So is running a system that is supported, and there are
many GNU/Linux distros out there that can be installed on such
hardware at no cost.

Best,
Jean

PS: my offer to look at the file if provided with it still stands.

Re: another 'wrong type argument' error

[David Kastrup]

Wols Lists  writes:

> On 10/10/2022 06:43, Jean Abou Samra wrote:
>> The problem isn’t LilyPond’s or its dependencies’ support for older
>> macOS, which is better than even the system support. The real
>> problem is Apple preventing you from upgrading your computer past a
>> certain macOS version.
>
> Which is probably down to newer versions of MacOS taking advantage of
> new chip features.
>
> Linux drops support for older chips over time - it's almost impossible
> to get a distro that supports plain x86 any more

Which would be what?  30 years?

My current computer is about 10 years, the backup computer about 15
years old.  Both are running current GNU/Linux systems.

I think it was about 5 years ago that EISA bus support was removed.

> ... Because Apple has far tighter integration between computer and OS,
> they can more easily upgrade in lock-step.

Removing old hardware support is not mandatory.

Admittedly that does not really hold when migrating to a completely
different CPU architecture, and Apple affords that move roughly every
one or two decades (Motorola 68K to PowerPC to x86 to M1 if I remember
correctly with regard to macOS),

-- 
David Kastrup

Re: another 'wrong type argument' error

[Wols Lists]

On 10/10/2022 06:43, Jean Abou Samra wrote:

The problem isn’t LilyPond’s or its dependencies’ support for older macOS, 
which is better than even the system support. The real problem is Apple 
preventing you from upgrading your computer past a certain macOS version.


Which is probably down to newer versions of MacOS taking advantage of 
new chip features.


Linux drops support for older chips over time - it's almost impossible 
to get a distro that supports plain x86 any more ... Because Apple has 
far tighter integration between computer and OS, they can more easily 
upgrade in lock-step.


Cheers,
Wol

Re: another 'wrong type argument' error

[Werner LEMBERG]

>> That is certain to be the reason why it doesn’t run, but I suspect
>> a local build might run fine. I’d suggest setting this lower for
>> binary releases if there’s no pressing reason to require 10.15 on
>> Mac.
> 
> Sounds sensible.  Jonas?

And thanks for having done the release, Jonas!


Werner

Re: another 'wrong type argument' error

[Jean Abou Samra]

> Le 9 oct. 2022 à 22:45, Kieren MacMillan  a 
> écrit :
> 
> dyld: Symbol not found: _iconv
>  Referenced from: /usr/lib/libcups.2.dylib
>  Expected in: /opt/local/lib/libiconv.2.dylib
> in /usr/lib/libcups.2.dylib
> Abort trap: 6



What surprises me in this error message is that mentions a dynamic library in 
/opt/local/lib, which I read is for MacPorts, but I thought we were linking 
with dependencies like libiconv statically. Where am I going wrong in my 
thinking?

Re: another 'wrong type argument' error

[Jean Abou Samra]

> Le 10 oct. 2022 à 07:10, Werner LEMBERG  a écrit :
> 
>> That is certain to be the reason why it doesn’t run, but I suspect a
>> local build might run fine. I’d suggest setting this lower for
>> binary releases if there’s no pressing reason to require 10.15 on
>> Mac.
> 
> Sounds sensible.  Jonas?
> 
> On page
> 
>  
> https://smallhacks.wordpress.com/2018/11/11/how-to-support-old-osx-version-with-a-recent-xcode/
> 
> I read that SDK 10.14.1 supports 10.9 as the oldest version (I
> couldn't quickly find the lowest value for SDK 10.15).  AFAIK, we
> don't use any functionality that is available on newer macOS versions
> only, so this route seems safe.



Given the number of dependencies LilyPond has, including dependencies that 
interact with low-level aspects of the system like Guile and Fontconfig, I 
strongly doubt this will be easy. MacOS 10.9 has been unsupported for six years 
already.

The problem isn’t LilyPond’s or its dependencies’ support for older macOS, 
which is better than even the system support. The real problem is Apple 
preventing you from upgrading your computer past a certain macOS version.

Jean

Re: another 'wrong type argument' error

[Werner LEMBERG]

> Confirmed using otool that the minimum OS for the linked build is
> 10.15:
> 
> Load command 10
>   cmd LC_BUILD_VERSION
>   cmdsize 32
>   platform 1
>   minos 10.15
>   sdk 10.15.6

Thanks.

> That is certain to be the reason why it doesn’t run, but I suspect a
> local build might run fine. I’d suggest setting this lower for
> binary releases if there’s no pressing reason to require 10.15 on
> Mac.

Sounds sensible.  Jonas?

On page

  
https://smallhacks.wordpress.com/2018/11/11/how-to-support-old-osx-version-with-a-recent-xcode/

I read that SDK 10.14.1 supports 10.9 as the oldest version (I
couldn't quickly find the lowest value for SDK 10.15).  AFAIK, we
don't use any functionality that is available on newer macOS versions
only, so this route seems safe.

> For reference when using clang/llvm the relevant compiler flag to
> set the deployment target is:
> 
> -mmacos-version-min=

BTW, this flag is necessary for both compiling and linking.

Whatever Jonas is able to manage with his build setup, I suggest to
add a note to the download section(s) like the following:

  The macOS x86_64 binary works with macOS X.Y and higher.  For older
  macOS versions please use MacPorts.


 Werner

Re: another 'wrong type argument' error

[Kieren MacMillan]

Hi Alex,

> Confirmed using otool that the minimum OS for the linked build is 10.15:
> 
> Load command 10
>   cmd LC_BUILD_VERSION
>   cmdsize 32
>   platform 1
>   minos 10.15
>   sdk 10.15.6

Oh! Fascinating. Thanks for digging that up.
Kieren.

Re: another 'wrong type argument' error

[Alex Harker]

Confirmed using otool that the minimum OS for the linked build is 10.15:

Load command 10
  cmd LC_BUILD_VERSION
  cmdsize 32
  platform 1
  minos 10.15
  sdk 10.15.6

That is certain to be the reason why it doesn’t run, but I suspect a local 
build might run fine. I’d suggest setting this lower for binary releases if 
there’s no pressing reason to require 10.15 on Mac.

 For reference when using clang/llvm the relevant compiler flag to set the 
deployment target is:

-mmacos-version-min=

Happy to help further if I can, but I’m fairly inexperienced with complex make 
systems (mostly having tended to use IDEs to build my projects) - I’ve done a 
little bit though recently one project that deploys to pure data, however.

Alex


> On 10 Oct 2022, at 00:31, Alex Harker  wrote:
> 
> The computer under discussion (2011 Intel Core i7 iMac) has a 64 bit 
> architecture and Mac OS 10.13 is 64 bit (Mac OS has had a 64 bit option since 
> 10.6 and 10.8 removed the 32 bit kernel).
> 
> This definitely isn’t likely to be a 64/32bit issue - I think that’s some 
> kind of confusion. 
> 
> However, is it possible that the build process for the newest lilypond 
> release discussed sets a minimum Mac OS of higher than 10.13? Mac OS settings 
> for this compiler variable are hard limits, even if the code could 
> compile/run on a lower OS. Something about 10.13 would seem a little 
> conservative for an open-source project of this nature.
> 
> I had a super-quick skim of the source, and beyond seeing that it looks like 
> a GNU make build system, I could only see that it was likely too complex for 
> me to be able to easily figure out what would be happening here quickly. If 
> nothing is being set for a minimum OS then it will (I believe) default to the 
> OS it is being compiled on - that might be the source of the issue.
> 
> Alex
> 
> 
>> On 9 Oct 2022, at 23:16, David Kastrup  wrote:
>> 
>> Jean Abou Samra  writes:
>> 
 Le 9 oct. 2022 à 22:52, Kieren MacMillan
  a écrit :
 
 The moment I can afford a new computer for my studio, I'll upgrade!
>>> 
>>> 
>>> Apart from buying new hardware, you could also run the Linux binaries
>>> in a Linux VM.
>> 
>> I would be surprised if a 64bit Linux would be supported by a VM on a
>> 32bit OS.
>> 
>> -- 
>> David Kastrup
>> 
> 

Re: another 'wrong type argument' error

[Alex Harker]

The computer under discussion (2011 Intel Core i7 iMac) has a 64 bit 
architecture and Mac OS 10.13 is 64 bit (Mac OS has had a 64 bit option since 
10.6 and 10.8 removed the 32 bit kernel).

This definitely isn’t likely to be a 64/32bit issue - I think that’s some kind 
of confusion. 

However, is it possible that the build process for the newest lilypond release 
discussed sets a minimum Mac OS of higher than 10.13? Mac OS settings for this 
compiler variable are hard limits, even if the code could compile/run on a 
lower OS. Something about 10.13 would seem a little conservative for an 
open-source project of this nature.

I had a super-quick skim of the source, and beyond seeing that it looks like a 
GNU make build system, I could only see that it was likely too complex for me 
to be able to easily figure out what would be happening here quickly. If 
nothing is being set for a minimum OS then it will (I believe) default to the 
OS it is being compiled on - that might be the source of the issue.

Alex


> On 9 Oct 2022, at 23:16, David Kastrup  wrote:
> 
> Jean Abou Samra  writes:
> 
>>> Le 9 oct. 2022 à 22:52, Kieren MacMillan
>>>  a écrit :
>>> 
>>> The moment I can afford a new computer for my studio, I'll upgrade!
>> 
>> 
>> Apart from buying new hardware, you could also run the Linux binaries
>> in a Linux VM.
> 
> I would be surprised if a 64bit Linux would be supported by a VM on a
> 32bit OS.
> 
> -- 
> David Kastrup
> 

Re: another 'wrong type argument' error

[David Kastrup]

Jean Abou Samra  writes:

>> Le 9 oct. 2022 à 22:52, Kieren MacMillan
>>  a écrit :
>> 
>> The moment I can afford a new computer for my studio, I'll upgrade!
>
>
> Apart from buying new hardware, you could also run the Linux binaries
> in a Linux VM.

I would be surprised if a 64bit Linux would be supported by a VM on a
32bit OS.

-- 
David Kastrup

Re: another 'wrong type argument' error

[Jean Abou Samra]

> Le 9 oct. 2022 à 22:52, Kieren MacMillan  a 
> écrit :
> 
> The moment I can afford a new computer for my studio, I'll upgrade!


Apart from buying new hardware, you could also run the Linux binaries in a 
Linux VM.

Jean

Re: another 'wrong type argument' error

[Kieren MacMillan]

Hi Jonas,

> Probably not since all Intel Core processors should be 64-bit. It's
> more likely that you are also running an ancient version of macOS.

Oh, for sure: macOS 10.13.6 (the maximum this old iMac will run).

> running an outdated and insecure operating system is bad by itself...

The moment I can afford a new computer for my studio, I'll upgrade! They just 
made Macs *so* well in the [second] Steve Jobs era, that I'm still running 
machines from 2011, 2008, 2006, and even 2002 (though to be fair, I only use 
that for iTunes and for the rare time I have to send a fax).

Thanks,
Kieren.

Re: another 'wrong type argument' error

[Jonas Hahnfeld via LilyPond user discussion]

On Sun, 2022-10-09 at 16:24 -0400, Kieren MacMillan wrote:
> Hi all,
> 
> > Heh, 2.23.14 _just_ came out.
> > https://gitlab.com/lilypond/lilypond/-/releases
> > Kieren, try using that
> 
> 
> When I download and unzip it, Frescobaldi doesn't like it:
> 
> 
> I'm assuming it’s a 64-versus-32-bit issue? (I'm working on a 2011
> Intel Core i7 iMac).

Probably not since all Intel Core processors should be 64-bit. It's
more likely that you are also running an ancient version of macOS. The
binaries are built in macOS 10.15, and even that version is EOL since
July this year.

> MacPorts (where I have 2.23.13 running fine) seems to not have
> 2.23.14 ready yet.
> 
> Other than moving to my laptop (64-bit capable) — which I can/will do
> if necessary — what are my options?

Compiling yourself. But more seriously, running an outdated and
insecure operating system is bad by itself...

Jonas


signature.asc
Description: This is a digitally signed message part

Re: another 'wrong type argument' error

[Kieren MacMillan]

Hi Jean,

> If you type "~/Downloads/lilypond-2.23.14/bin/lilypond" in a terminal,
> what does it give?

dyld: Symbol not found: _iconv
  Referenced from: /usr/lib/libcups.2.dylib
  Expected in: /opt/local/lib/libiconv.2.dylib
 in /usr/lib/libcups.2.dylib
Abort trap: 6

> Also, how did you install Frescobaldi? Is it the latest version?

It's 3.1.3, which I think is the latest version that has a macOS binary.
I'm going to install 3.2 using MacPorts and see what happens.

More soon (and thanks!),
Kieren.

Re: another 'wrong type argument' error

[Jean Abou Samra]

Le 09/10/2022 à 22:24, Kieren MacMillan a écrit :

Hi all,


Heh, 2.23.14 _just_ came out.
https://gitlab.com/lilypond/lilypond/-/releases
Kieren, try using that


When I download and unzip it, Frescobaldi doesn't like it:
[image]

I'm assuming it’s a 64-versus-32-bit issue? (I'm working on a 2011 
Intel Core i7 iMac).
MacPorts (where I have 2.23.13 running fine) seems to not have 2.23.14 
ready yet.


Other than moving to my laptop (64-bit capable) — which I can/will do 
if necessary — what are my options?





No, this is not a 32/64-bit issue, since the official binaries of recent
versions are all 64-bit, including on macOS.

If you type "~/Downloads/lilypond-2.23.14/bin/lilypond" in a terminal,
what does it give?

Also, how did you install Frescobaldi? Is it the latest version?

Re: another 'wrong type argument' error

[Kieren MacMillan]

Hi Harm,

> What happens if you follow the comments below? Cheers, Harm
> 
>>   ;; Next line should be used for 2.19.65 and above
>>   ;(ly:grob-set-property! grob 'stencil
>>   ;  (stack-stencils X RIGHT 0 all-stils))
>>   ;; This line is for 2.18.2, though sometimes the offset in 
>> x-axis
>>   ;; is a little off
>>   (ly:grob-set-property! grob 'text
>> (make-stencil-markup (stack-stencils X RIGHT 0 all-stils)))

Oh! Well, it doesn't stop the error from happening… but it's probably good to 
make this change anyway, since I'll be using >2.19.65 for all future scores.

Thanks,
Kieren.

Re: another 'wrong type argument' error

[Kieren MacMillan]

Hi all,

> Heh, 2.23.14 _just_ came out.
> https://gitlab.com/lilypond/lilypond/-/releases 
> 
> Kieren, try using that

When I download and unzip it, Frescobaldi doesn't like it:



I'm assuming it’s a 64-versus-32-bit issue? (I'm working on a 2011 Intel Core 
i7 iMac).
MacPorts (where I have 2.23.13 running fine) seems to not have 2.23.14 ready 
yet.

Other than moving to my laptop (64-bit capable) — which I can/will do if 
necessary — what are my options?

Thanks,
Kieren.

Re: another 'wrong type argument' error

[Jean Abou Samra]

> Le 9 oct. 2022 à 21:19, David Kastrup  a écrit :
> 
> Let's hope that better error
> pinpointing starts working soonish.



Heh, 2.23.14 _just_ came out.

https://gitlab.com/lilypond/lilypond/-/releases

Kieren, try using that and putting #(ly:set-option 'compile-scheme-code) at the 
top of your file (before any includes).

Also add #(debug-enable 'backtrace) for best results.

Re: another 'wrong type argument' error

[Jean Abou Samra]

> Le 9 oct. 2022 à 21:19, David Kastrup  a écrit :
> 
> No idea.  Most can be ruled out, and for the other two one would have to
> look at more context.
> 
> It's really a clumsy way to debug.



Not the least because the use of list-head could also be somewhere in Guile 
itself.

For example, if you want to debug this way, you also have to grep for 'take', 
which is aliased to list-head.

Re: another 'wrong type argument' error

[David Kastrup]

Kieren MacMillan  writes:

> Hi again,
>
> D'oh… The better implication for me to have gotten from your helpful
> email would have been to search for "list-head" in all the files in my
> path/folder…
>
> Here's the output of that effort:
>
> [from OLL]
> edition-engraver/engine.scm:623: ) (wildcard2regex (list-tail
> (list-head mod-cl (1- (length mod-cl))) 1) ))
> oll-core/internal/os-path.scm:174: (list-head path-list (- (length
> path-list) 1
> oll-core/internal/os-path.scm:208:  (list-head file (- (length file) 1
> oll-core/internal/os-path.scm:213:  (list-head file (- (length file) 2
> oll-core/internal/properties.scm:424: ((propset-path (list-head
> configuration-path (- (length configuration-path) 1)))
> oll-core/package.ily:59:(oll-root (list-head path (- (length path) 
> 2)))
> oll-misc/custom-elements/compound-slurs/module.ily:261: (list-head
> (list-tail cps 1) (- (length cps) 2))
> snippets/ly/_internal/options.ily:66: (parent (list-head opt-path (-
> (length opt-path) 1)))
> snippets/notation-snippets/compound-slurs/module.ily:261: (list-head
> (list-tail cps 1) (- (length cps) 2))

Those all look like they could not produce (list-head '() 2).

These two can theoretically trigger:

> snippets/templates/adjustable-centered-stanzas/module.ily:45: (helper
> (cons (list-head remain next-sublist-size) accum)

> [from personal/non-OLL files]
> text-spanner-inner-texts.ly:160: (cons (list-head text-list (car
> line-count-list)) result)

And the rest should not be able to produce that call either.

> text-spanner-inner-texts.ly:198: (tslc (append (list-head tslc (1-
> (length tslc)))
> text-spanner-inner-texts.ly:463: (inner-texts (cdr (list-head texts
> (1- (length texts))
>
> Anything there helpful for the purposes of diagnosis?

No idea.  Most can be ruled out, and for the other two one would have to
look at more context.

It's really a clumsy way to debug.  Let's hope that better error
pinpointing starts working soonish.

-- 
David Kastrup

Re: another 'wrong type argument' error

[Thomas Morley]

Am So., 9. Okt. 2022 um 20:51 Uhr schrieb Kieren MacMillan
:
>
> Hi David,
>
> > git grep list-head
> >
> > suggests woodwind diagrams, predefined fretboards, the function
> > offset-fret, the \parallelMusic construct as possible callers.
> >
> > Anything in that list?
>
> I doubt it…
>
> > If not, my guess would be some edition-engraver
> > code when taking into account your usual toolbox.
>
> I knew it couldn't be that, because I tried "shutting off" the EE in that 
> score, and it still failed.
>
> But your suggestion helped me find one thing that may well be the issue: this 
> score uses a "dynamics on the fly" function, and the ones that are working 
> don't. Here's the function:
>
> custdyn =
> #(define-event-function (parser location idx strg)
>   ((index? 1) string?)
>   "Returns customized DynamicText derived from @var{strg}.
> Parts which should be rendered with as dynamics should be entered by
> surrounding them with the elements of @code{details.separator-pair}, default 
> is
> @code{(cons #\\{ #\\})}.
> The output is done by using the procedures from 
> @code{details.markup-commands},
> defaulting to @code{(cons make-dynamic-markup make-italic-markup)}.
> Further customizing is possible by using
> @code{details.dyn-rest-font-sizes}, needs a pair, default is unset
> @code{details.inner-x-space}, needs a pair, default is unset
> @code{details.outer-x-space}, needs a pair, default is is unset
> The optional @var{idx} determines which dynamic part is centered under the
> NoteColumn (in case @var{strg} contains multiple dynamics).
> "
>   (let* ((dynamic (make-music 'AbsoluteDynamicEvent))
>  (tweak-proc
>(lambda (grob)
>  (let* (
> (separator-pair
>   (assoc-get
> 'separator-pair
> (ly:grob-property grob 'details)
> (cons #\{ #\})))
> ;; get the fontsizes to use from the relevant
> ;; details-sub-property, i.e. 'dyn-rest-font-sizes
> (dyn-rest-font-sizes
>   (assoc-get
> 'dyn-rest-font-sizes
> (ly:grob-property grob 'details)))
> ;; get the markup-commands to use from the relevant
> ;; details-sub-property, i.e. 'markup-commands, a pair
> ;; car for dynamic, cdr for the rest
> (markup-commands
>   (assoc-get
> 'markup-commands
> (ly:grob-property grob 'details)
> (cons make-dynamic-markup make-italic-markup)))
> ;; get the pair-value to use for inserting some space to 
> the
> ;; left and/or right of the dynamic, usefull for bracketed
> ;; dynamics or dynamics with punctuations
> (inner-kern
>   (assoc-get
> 'inner-x-space
> (ly:grob-property grob 'details)))
> ;; get the pair-value to use for inserting some space
> ;; between the dynamic expression and other text.
> (outer-kern
>   (assoc-get
> 'outer-x-space
> (ly:grob-property grob 'details)))
> (stil-candidates
>   (dynamic-text::structered-list
> separator-pair
> dyn-rest-font-sizes
> inner-kern
> outer-kern
> markup-commands
> (1- idx)
> strg))
> (all-stils
>   (map
> (lambda (mrkp)
>   (if (null? mrkp)
>   empty-stencil
>   (grob-interpret-markup grob
> (if (markup-list? mrkp)
> (make-concat-markup mrkp)
> mrkp
>   stil-candidates))
> (prev-self-alignment-X-tweaks
>   (filter
> (lambda (tw)
>   (eq? (car tw) 'self-alignment-X))
> (ly:prob-property
>   (ly:grob-property grob 'cause)
>   'tweaks
>
>  (begin

What happens if you follow the comments below? Cheers, Harm

>;; Next line should be used for 2.19.65 and above
>;(ly:grob-set-property! grob 'stencil
>;  (stack-stencils X RIGHT 0 all-stils))
>;; This line is for 2.18.2, though sometimes the offset in 
> x-axis
>;; is a little off
>

Re: another 'wrong type argument' error

[Kieren MacMillan]

Hi again,

D'oh… The better implication for me to have gotten from your helpful email 
would have been to search for "list-head" in all the files in my path/folder…

Here's the output of that effort:

[from OLL]
edition-engraver/engine.scm:623:) (wildcard2regex (list-tail 
(list-head mod-cl (1- (length mod-cl))) 1) ))
oll-core/internal/os-path.scm:174:  (list-head path-list (- (length 
path-list) 1
oll-core/internal/os-path.scm:208:  (list-head file (- (length file) 1
oll-core/internal/os-path.scm:213:  (list-head file (- (length file) 2
oll-core/internal/properties.scm:424:  ((propset-path (list-head 
configuration-path (- (length configuration-path) 1)))
oll-core/package.ily:59:(oll-root (list-head path (- (length path) 2)))
oll-misc/custom-elements/compound-slurs/module.ily:261:   
(list-head (list-tail cps 1) (- (length cps) 2))
snippets/ly/_internal/options.ily:66:  (parent (list-head opt-path (- 
(length opt-path) 1)))
snippets/notation-snippets/compound-slurs/module.ily:261:   
(list-head (list-tail cps 1) (- (length cps) 2))
snippets/templates/adjustable-centered-stanzas/module.ily:45:
(helper (cons (list-head remain next-sublist-size) accum)

[from personal/non-OLL files]
text-spanner-inner-texts.ly:160:   (cons (list-head text-list (car 
line-count-list)) result)
text-spanner-inner-texts.ly:198:   (tslc (append (list-head tslc (1- 
(length tslc)))
text-spanner-inner-texts.ly:463:(inner-texts (cdr 
(list-head texts (1- (length texts))

Anything there helpful for the purposes of diagnosis?

Thanks,
Kieren.

Re: another 'wrong type argument' error

[Kieren MacMillan]

Hi David,

> git grep list-head
> 
> suggests woodwind diagrams, predefined fretboards, the function
> offset-fret, the \parallelMusic construct as possible callers.
> 
> Anything in that list?

I doubt it…

> If not, my guess would be some edition-engraver
> code when taking into account your usual toolbox.

I knew it couldn't be that, because I tried "shutting off" the EE in that 
score, and it still failed.

But your suggestion helped me find one thing that may well be the issue: this 
score uses a "dynamics on the fly" function, and the ones that are working 
don't. Here's the function:

custdyn =
#(define-event-function (parser location idx strg)
  ((index? 1) string?)
  "Returns customized DynamicText derived from @var{strg}.
Parts which should be rendered with as dynamics should be entered by
surrounding them with the elements of @code{details.separator-pair}, default is
@code{(cons #\\{ #\\})}.
The output is done by using the procedures from @code{details.markup-commands},
defaulting to @code{(cons make-dynamic-markup make-italic-markup)}.
Further customizing is possible by using
@code{details.dyn-rest-font-sizes}, needs a pair, default is unset
@code{details.inner-x-space}, needs a pair, default is unset
@code{details.outer-x-space}, needs a pair, default is is unset
The optional @var{idx} determines which dynamic part is centered under the
NoteColumn (in case @var{strg} contains multiple dynamics).
"
  (let* ((dynamic (make-music 'AbsoluteDynamicEvent))
 (tweak-proc
   (lambda (grob)
 (let* (
(separator-pair
  (assoc-get
'separator-pair
(ly:grob-property grob 'details)
(cons #\{ #\})))
;; get the fontsizes to use from the relevant
;; details-sub-property, i.e. 'dyn-rest-font-sizes
(dyn-rest-font-sizes
  (assoc-get
'dyn-rest-font-sizes
(ly:grob-property grob 'details)))
;; get the markup-commands to use from the relevant
;; details-sub-property, i.e. 'markup-commands, a pair
;; car for dynamic, cdr for the rest
(markup-commands
  (assoc-get
'markup-commands
(ly:grob-property grob 'details)
(cons make-dynamic-markup make-italic-markup)))
;; get the pair-value to use for inserting some space to the
;; left and/or right of the dynamic, usefull for bracketed
;; dynamics or dynamics with punctuations
(inner-kern
  (assoc-get
'inner-x-space
(ly:grob-property grob 'details)))
;; get the pair-value to use for inserting some space
;; between the dynamic expression and other text.
(outer-kern
  (assoc-get
'outer-x-space
(ly:grob-property grob 'details)))
(stil-candidates
  (dynamic-text::structered-list
separator-pair
dyn-rest-font-sizes
inner-kern
outer-kern
markup-commands
(1- idx)
strg))
(all-stils
  (map
(lambda (mrkp)
  (if (null? mrkp)
  empty-stencil
  (grob-interpret-markup grob
(if (markup-list? mrkp)
(make-concat-markup mrkp)
mrkp
  stil-candidates))
(prev-self-alignment-X-tweaks
  (filter
(lambda (tw)
  (eq? (car tw) 'self-alignment-X))
(ly:prob-property
  (ly:grob-property grob 'cause)
  'tweaks

 (begin
   ;; Next line should be used for 2.19.65 and above
   ;(ly:grob-set-property! grob 'stencil
   ;  (stack-stencils X RIGHT 0 all-stils))
   ;; This line is for 2.18.2, though sometimes the offset in x-axis
   ;; is a little off
   (ly:grob-set-property! grob 'text
 (make-stencil-markup (stack-stencils X RIGHT 0 all-stils)))
   ;; if previous tweak for self-alignment-X is present return '()
   (if (pair? prev-self-alignment-X-tweaks)
   '()
   (ly:grob-set-property! grob 'X-offset
 

Re: another 'wrong type argument' error

[David Kastrup]

Kieren MacMillan  writes:

> Anyone know where I should be looking to find the culprit?

git grep list-head

suggests woodwind diagrams, predefined fretboards, the function
offset-fret, the \parallelMusic construct as possible callers.

Anything in that list?  If not, my guess would be some edition-engraver
code when taking into account your usual toolbox.

-- 
David Kastrup

Re: another 'wrong type argument' error

[Jean Abou Samra]

Hi Kieren,


Le 09/10/2022 à 19:38, Kieren MacMillan a écrit :

Hi again,

Something still isn't working with a few of my scores, and I'm hoping 
someone can once again point me in the right direction for a quick 
fix… (No, a MWE isn't a real option.)


— I'm running Lilypond 2.23.13 (installed via MacPorts) on macOS 
10.13.6 (High Sierra)

— I believe used convert-ly on every file that's in the include chain
— I've applied the \newSpacingSection fix that Jean gave last time

Unfortunately, I still sometimes (but not on all files!) get a compile 
error — here's the verbose output (sorry it's a screenshot: not quite 
sure how to get the same log output as text):




Re screenshot: what editor are you using?

In Frescobaldi, it seems that there is a glitch that prevents from
pasting from the log output if you have selected something at the same
time in the LilyPond code view, because that takes priority apparently,
but in my experience, if you stop selecting something in the code,
copy-pasting from the log works just fine.




[image]

Anyone know where I should be looking to find the culprit?



Unfortunately, this is one of those errors that are very hard
to understand because of the poor error messages and backtraces
that Guile 2 yields for interpreted code.

In the upcoming release 2.23.14, which might actually happen
this evening but could be later this week, there will be a
-dcompile-scheme-code option for using the other option Guile 2
has to run code, the compiler, which gives far more informative
error messages, so I suggest to either wait for 2.23.14, or if
you can't wait, send a full, possibly large example to the list
(or to me in private if necessary) so that we can try it out
in 2.23.14 with -dcompile-scheme-code.

Best,
Jean

another 'wrong type argument' error

[Kieren MacMillan]

Hi again,

Something still isn't working with a few of my scores, and I'm hoping someone 
can once again point me in the right direction for a quick fix… (No, a MWE 
isn't a real option.)

— I'm running Lilypond 2.23.13 (installed via MacPorts) on macOS 10.13.6 (High 
Sierra)
— I believe used convert-ly on every file that's in the include chain
— I've applied the \newSpacingSection fix that Jean gave last time

Unfortunately, I still sometimes (but not on all files!) get a compile error — 
here's the verbose output (sorry it's a screenshot: not quite sure how to get 
the same log output as text):



Anyone know where I should be looking to find the culprit?

Thanks,
Kieren.