A documentation/tutorial/whatever problem

Check out and its (currently) two answers while the second one (which was posted first) has not been removed. This second answer has obviously been written by a capa

Re: A documentation/tutorial/whatever problem

. > What kind of project should we tackle in order to help people better use > what is there in a manner that is reasonably easy to use and understand? > I think this is a great question. I wish I had a great answer to this great question, but I don't think I do. I think it's

A documentation/tutorial/whatever problem

Check out and its (currently) two answers while the second one (which was posted first) has not been removed. This second answer has obviously been written by a capa

Re: A documentation/tutorial/whatever problem

r than the list of music functions) - should they > be in 5.1.3 Tweaking methods? The problem is that \propertyTweak is a programming tool, not a user tool. The user will be better off using \tweak/\override explicitly where it is appropriate: something like \lyrics { \tweak color #re

Re: A documentation/tutorial/whatever problem

At 12:29 on 06 Nov 2024, David Kastrup wrote: > Check out > > and its (currently) two answers while the second one > (which was posted first) has not been removed. > T

Re: A documentation/tutorial/whatever problem

ake. It is nice that `grob-transformer` renders the task comparatively straightforward and easy to do. The problem with considering it a trivial piece of convenience then is that you are less incline to actually use it. -- David Kastrup

Re: regtest threshold problem

On 2024-04-28 03:34, Werner LEMBERG wrote: > Independent of improving the metrics, maybe we could improve the review workflow by adding dynamic control to the diff web page to expand or collapse the entries based on a variable threshold. Yes, this would be a nice feature – please submit an issu

Re: regtest threshold problem

>> I'm working on a modification of `musicxml2ly` that will cause a >> change in the result as shown by the attached images. However, our >> regtest classifies this as 'below threshold' and doesn't display >> it. [...] > > Independent of improving the metrics, maybe we could improve the > review

Re: regtest threshold problem

On 2024-04-27 00:24, Werner LEMBERG wrote: I'm working on a modification of `musicxml2ly` that will cause a change in the result as shown by the attached images. However, our regtest classifies this as 'below threshold' and doesn't display it. Does anybody have an idea how to improve this? I'

regtest threshold problem

I'm working on a modification of `musicxml2ly` that will cause a change in the result as shown by the attached images. However, our regtest classifies this as 'below threshold' and doesn't display it. Does anybody have an idea how to improve this? I'm not an expert in image analysis, and a quic

Re: fundamental problem with `\autoBeamOff`

>> > Using \noBeam should let you terminate the beam early: [...] >> >> Very nice! Maybe we should add your fix to the git repository? >> > Seems to me like we need a documentation fix. Something like: > > A beam that is started by the autobeamer will end according to the > autobeaming rules

Re: fundamental problem with `\autoBeamOff`

On Mon, Mar 25, 2024 at 11:47 AM Werner LEMBERG wrote: > > >> Consider this small example. > >> ```tex > >> { > >> f'8 f' \autoBeamOff f' f' > >> f' f' f' f' > >> } > >> ``` > >> > >> For me it was surprising to see that `\autoBeamOff` doesn't act > >> immediately but rather two eighths later

Re: fundamental problem with `\autoBeamOff`

>> Consider this small example. >> ```tex >> { >> f'8 f' \autoBeamOff f' f' >> f' f' f' f' >> } >> ``` >> >> For me it was surprising to see that `\autoBeamOff` doesn't act >> immediately but rather two eighths later. The documentation >> doesn't mention this, AFAICS, and I consider this beha

Re: fundamental problem with `\autoBeamOff`

On 2024-03-25 9:34 am, Werner LEMBERG wrote: Consider this small example. ```tex { f'8 f' \autoBeamOff f' f' f' f' f' f' } ``` For me it was surprising to see that `\autoBeamOff` doesn't act immediately but rather two eighths later. The documentation doesn't mention this, AFAICS, and I con

fundamental problem with `\autoBeamOff`

Consider this small example. ```tex { f'8 f' \autoBeamOff f' f' f' f' f' f' } ``` For me it was surprising to see that `\autoBeamOff` doesn't act immediately but rather two eighths later. The documentation doesn't mention this, AFAICS, and I consider this behaviour rather counter-intuitive.

Re: Harp_pedal_engraver: an overengineered solution to a niche problem

On 2023-12-07 05:12, Saul Tobin wrote: I’d welcome feedback and I’d be happy to submit this as a pull request for either OLL or Lilypond itself if there is interest. They're "merge requests" on GitLab, but they smell as sweet.  You would likely get more engagement from busy developers if you

Harp_pedal_engraver: an overengineered solution to a niche problem

to this problem. The user only needs to enter pedal settings at the beginning of a passage, which looks like: <>\setHarpPedals { d c b e f g a } Harp_pedal_engraver then listens for notes and automatically prints pedal changes when new accidentals occur. Manually entered pedal changes (usi

Re: Doc-problem with new markup-command

Am Do., 23. Nov. 2023 um 11:53 Uhr schrieb Jean Abou Samra : > > > > Now m̀ake' fails. > > Offending line in the doc-string is > > The input-string @var{strg} may be composed by any string of \";|.:![]{}\". > > Obviously the braces, { and }, need to be escaped. > > How to? > > > Like this I think:

Re: Doc-problem with new markup-command

> Now m̀ake' fails. > Offending line in the doc-string is > The input-string @var{strg} may be composed by any string of \";|.:![]{}\". > Obviously the braces, { and }, need to be escaped. > How to? Like this I think: ... composed of the characters @samp{; | . : ! [ ] @{ @}}

Re: Doc-problem with new markup-command

Am Do., 23. Nov. 2023 um 10:49 Uhr schrieb Thomas Morley : > > Am Do., 23. Nov. 2023 um 10:40 Uhr schrieb Jean Abou Samra > : > > > > > Ok. > > > https://gitlab.com/lilypond/lilypond/-/merge_requests/2179 > > > > Oh, I see. You forgot to give it a #:category . > > Thanks for the hint. Would it mak

Re: Doc-problem with new markup-command

Am Do., 23. Nov. 2023 um 10:40 Uhr schrieb Jean Abou Samra : > > > Ok. > > https://gitlab.com/lilypond/lilypond/-/merge_requests/2179 > > Oh, I see. You forgot to give it a #:category . Thanks for the hint. Would it make sense to warn if #:category is omitted? Corrected patch is up. Thanks, Har

Re: Doc-problem with new markup-command

> Ok. > https://gitlab.com/lilypond/lilypond/-/merge_requests/2179 Oh, I see. You forgot to give it a #:category . signature.asc Description: This is a digitally signed message part

Re: Doc-problem with new markup-command

Am Do., 23. Nov. 2023 um 10:23 Uhr schrieb Jean Abou Samra : > > Is this a doc build from scratch or an incremental rebuild? >From scratch. > I'd suggest opening the MR anyway. Ok. https://gitlab.com/lilypond/lilypond/-/merge_requests/2179

Re: Doc-problem with new markup-command

Is this a doc build from scratch or an incremental rebuild? I'd suggest opening the MR anyway.

Doc-problem with new markup-command

Hi, I'm working on #3164 "add a `\bar-line` markup function" and thought the patch is ready to upload for review, i.e. the new bar-line-markup-command works as I think it should, `make check' (with a new regtest) returns as expected. `make doc' succeds without errors. Alas, the new markup-command

Re: lyric font change problem in ver 2.24.0

Thankyou Sir for solving this problem, it was indeed the corrupt font. I downloaded nudi font from the link given by you, and yes it worked fine.   Thanks once again Regards Raj From: Jean Abou Samra <j...@abou-samra.fr> Sent: Thu, 23 Feb 2023 20:12:53 To: rajwn <ra...@rediffmai

Re: lyric font change problem in ver 2.24.0

> > All the fonts I install goes to  > C:/Users/Raj/AppData/Local/Microsoft/Windows/Fonts > > I had no problem with version 2.22.0, it worked very well. > > I will attach you the text file > also the nudi font. Thanks for giving a reproductible examp

Re: lyric font change problem in ver 2.24.0

Le jeudi 23 février 2023 à 04:13 +, rajwn a écrit : > Regarding the problem mentioned above, I downloaded Lilypond version 2.24.1 > but problem still exists. > Sorry to trouble you. (Adding back the list) The first thing I would check is the output from ``` #(ly:font-c

Re: problem with LSR snippet #602

> On 23 Jan 2023, at 09:52, Jean Abou Samra wrote: > > > But LSR is not using -dbackend=eps anymore… Is GS really getting invoked? Current options, as suggested, are -jlsr,lsr,/mnt/lilyjail,/tmp -dbackend=eps --eps -dtall-page-formats=eps -dno-use-paper-size-for-page > In any case, this

Re: problem with LSR snippet #602

> On 23 Jan 2023, at 09:36, Werner LEMBERG wrote: > > > > Any idea what could be done? The manual compilation includes the EPS > snippet, LSR doesn't... (The different line lengths in the images > below are not relevant.) > > Well, with -dbackend=eps LSR expects that ghostscript won't b

Re: problem with LSR snippet #602

 > Le 23 janv. 2023 à 09:49, Sebastiano Vigna a > écrit : >  > >> On 23 Jan 2023, at 09:36, Werner LEMBERG wrote: >> >> >> >> Any idea what could be done? The manual compilation includes the EPS >> snippet, LSR doesn't... (The different line lengths in the images >> below are not relev

Fw: problem with LSR snippet #602

Any idea what could be done? The manual compilation includes the EPS snippet, LSR doesn't... (The different line lengths in the images below are not relevant.) Werner --- Begin Message --- > On 21 Jan 2023, at 19:36, Werner LEMBERG wrote: > > > Sebastiano, > > > please have a look

Re: lyric font change problem in ver 2.24.0

Le 25/12/2022 à 16:19, rajwn via Discussions on LilyPond development a écrit : I have problem regarding the Indian ascii fonts "nudi 01 e" in version 2.24.0,  It doesn't change. This problem did not exist in version 2.22.0 Pease help. \version "2.24.0" #(ly:font-confi

lyric font change problem in ver 2.24.0

I have problem regarding the Indian ascii fonts "nudi 01 e" in version 2.24.0,  It doesn't change. This problem did not exist in version 2.22.0 Pease help. \version "2.24.0" #(ly:font-config-add-directory "C:/Users/../../Windows/Fonts/") \relative

Re: strut problem

If you > use it, you need to have an understanding of how stencils work at > the low level. > > I don’t see what we would gain by changing those internals. No problem. I'm only thinking aloud :-) >> What I want is to have the `\strut` command work in general. If >>

Re: strut problem, Re: strut problem, Re: strut problem, Re: strut problem

 > Le 19 nov. 2022 à 08:04, Werner LEMBERG a écrit : >  >> A stencil has an X extent, a Y extent and a stencil expression >> (Scheme list). That's all. >> Think of it in another way. If LilyPond gave non-empty skylines to >> stencils with empty extents, a grob with its stencil set to >> #empty-s

Re: strut problem,Re: strut problem,Re: strut problem,Re: strut problem

> A stencil has an X extent, a Y extent and a stencil expression > (Scheme list). That's all. > > Think of it in another way. If LilyPond gave non-empty skylines to > stencils with empty extents, a grob with its stencil set to > #empty-stencil would stop taking no space. Instead, it would take >

Re: strut problem,Re: strut problem

Le 18/11/2022 à 23:16, Werner LEMBERG a écrit : Put yourself in the shoes of LilyPond trying to compute the skylines of this stencil: (ly:make-stencil "" empty-interval '(-0.3 . 0.7)) According to you, the skyline should be a zero-width spike. At which horizontal coordinate is this spike? Any

Re: strut problem,Re: strut problem

> Put yourself in the shoes of LilyPond trying to compute the skylines > of this stencil: > > (ly:make-stencil "" empty-interval '(-0.3 . 0.7)) > > According to you, the skyline should be a zero-width spike. At > which horizontal coordinate is this spike? Any value would be > legitimate. Well

Re: strut problem,Re: strut problem,Re: strut problem,Re: strut problem

> You did see the code I posted that would do what you asked for? Sorry, no, I missed it. Thanks! Werner

Re: strut problem,Re: strut problem,Re: strut problem,Re: strut problem

they can't be, since if you want \strut to factor into the >> skylines, its placement will be visible in the shape of the skylines >> (and consequently make a difference in the spacing). > > You are correct with your LaTeX observation. However, the longer I > think about

Re: strut problem

Le 18/11/2022 à 12:34, Werner LEMBERG a écrit : It is completely unclear to me how you would take non-printing stencils with empty extents into skylines. How should the resulting skylines look like? If the X extent is empty-interval, why should the vertical skyline take this stencil into accoun

Re: strut problem,Re: strut problem

>> What I suggest is that zero-width/zero-height objects >> *are* taken in account for computing the skylines. > > What makes your (redefined) \strut not taken into account [...] is > caused by the "" stencil expression, which LilyPond never gives > skylines to Ah, thanks. > It is completely u

Re: strut problem

Le 18/11/2022 à 12:05, Werner LEMBERG a écrit : The latter. What I suggest is that zero-width/zero-height objects *are* taken in account for computing the skylines. What makes your (redefined) \strut not taken into account into skylines is not just its empty X extent. You can see that it is

Re: strut problem

>> However, the longer I think about struts – even `\vspace` is >> nothing else than a vertical strut! – the more I believe that there >> is a conceptual problem in LilyPond: There is a 'typesetting mode' >> where vertical struts have an effect (like the

Re: strut problem

Le 18/11/2022 à 05:46, Werner LEMBERG a écrit : You are correct with your LaTeX observation. However, the longer I think about struts – even `\vspace` is nothing else than a vertical strut! – the more I believe that there is a conceptual problem in LilyPond: There is a 'typesetting mode&#

Re: strut problem,Re: strut problem,Re: strut problem,Re: strut problem

> skylines, its placement will be visible in the shape of the skylines > (and consequently make a difference in the spacing). You are correct with your LaTeX observation. However, the longer I think about struts – even `\vspace` is nothing else than a vertical strut! – the more I believe that ther

Re: strut problem,Re: strut problem

Le 17/11/2022 à 18:49, Werner LEMBERG a écrit : Why is the vertical extent of the strut ignored? Because side positioning is primarily based on (vertical) skylines, not extents. Thanks. What is the reasoning behind this? For me, this behaviour is unexpected. By the way, this is one reason

Re: strut problem,Re: strut problem

Le 17/11/2022 à 18:49, Werner LEMBERG a écrit : Why is the vertical extent of the strut ignored? Because side positioning is primarily based on (vertical) skylines, not extents. Thanks. What is the reasoning behind this? For me, this behaviour is unexpected. If side positioning were done w

Re: strut problem,Re: strut problem

>> Why is the vertical extent of the strut ignored? > > Because side positioning is primarily based on (vertical) skylines, > not extents. Thanks. What is the reasoning behind this? For me, this behaviour is unexpected. Werner

Re: strut problem

Werner LEMBERG writes: > Consider this input. > > ``` > \version "2.23.81" > > #(define-markup-command (strut layout props) >() >#:properties ((baseline-skip)) >(ly:make-stencil "" > empty-interval > (cons (* -0.3 baseline-skip) >

Re: strut problem

Le 17/11/2022 à 18:14, Werner LEMBERG a écrit : Consider this input. ``` \version "2.23.81" #(define-markup-command (strut layout props) () #:properties ((baseline-skip)) (ly:make-stencil "" empty-interval (cons (* -0.3 baseline-skip)

strut problem

Consider this input. ``` \version "2.23.81" #(define-markup-command (strut layout props) () #:properties ((baseline-skip)) (ly:make-stencil "" empty-interval (cons (* -0.3 baseline-skip) (* 0.7 baseline-skip { \ove

Re: problem with vertical spacing paper variables

> If you add back some margins, you will see that there is a bar > number on the left of the system, which is out of the page when > margins are removed, but nevertheless takes vertical space. Add > > \layout { >   \context { >     \Score >     \remove Bar_number_engraver >   } > } That's it, tha

Re: problem with vertical spacing paper variables

Le 03/09/2022 à 22:20, Werner LEMBERG a écrit : I'm working on integrating the visual grob index into the NR. To do that, I'm trying to get the largest possible `@image` without overfull warnings, then setting the margins to zero. This works just fine. However, when also setting the vertical s

Re: Problem

I haven't actually run into >> any problems with clashes, but I also haven't tried multiple lilypond >> binaries with different names on my system -- I've just used different app >> bundles. > > I would claim it's even less error-prone with the

Re: Problem

versions of all the necessary utilities, so I don't need to worry about > clashes with improper versions of utilities. I haven't actually run into any > problems with clashes, but I also haven't tried multiple lilypond binaries > with different names on my system -- I've just

Re: Problem

On 8/1/21, 10:21 AM, "lilypond-devel on behalf of Jonas Hahnfeld via Discussions on LilyPond development" wrote: > For me, personally, I'd prefer to see us follow up with either Marnen's or Jaques's work (they may actually be very similar -- I'm not sure) so we can get installable

Re: Problem

Am Sonntag, dem 01.08.2021 um 15:36 + schrieb Carl Sorensen: > Jonas Hahnfeld has been working on an experimental binary build that avoids > the complexities of GUB and avoids cross-compiling, that uses separate > packages for each system, thus enabling a user of MacOS to build their own >

Re: Problem

On 8/1/21, 8:42 AM, "lilypond-user on behalf of Craig Comstock" wrote: > Could I help/ volunteer somehow that this workaround gets integrated in the current download version, don't know if that error only happens with MacOS X.14.6 aka 'Mojave' though. FWIW I am using 20.0

Re: GUB mingw pixman 0.40 linking problem

Hi everybody, It's also a linker problem with mingw, but this problem proves to be hard for me. I solved the problem. Knut

GUB mingw pixman 0.40 linking problem

1.16.0, fails with the same problem, so there is no need to work on anything but the latest stable code. Pixman 0.40 initially failed for all platforms, but adding appropriate LDFLAGS helped for linux.* and darwin-x86. See pixman-new.py. It's also a linker problem with mingw, but this pr

Timing problem for parallel make info ?

Hi, regarding my previous complaint of Info no longer containing images: it actually happens that only _some_ images are missing (among them the very first in the notation manual which triggered my reaction) and replaced with [[image of music]]. In the info file, there really is [[image of music

Re: Problem with OTF support

> Silly me! FreeType already offers the necessary functionality (see > `ftcid.h`): > > FT_Get_CID_Is_Internally_CID_Keyed > FT_Get_CID_From_Glyph_Index > > I'll prepare a fix. Here it is: https://gitlab.com/lilypond/lilypond/-/merge_requests/474 Please test! Werner

Re: Problem with OTF support

> do you think this can be solved within LilyPond? Otherwise I could > add a service to FreeType so that function `cff_charset_cid_to_gindex` > (in FreeType's file `src/cff/cffload.c`) gets a public API...[*] Silly me! FreeType already offers the necessary functionality (see `ftcid.h`): FT_

Re: Problem with OTF support

onts, so CID==GID. I think these non-subset fonts would be fine. > > Maybe your analysis is correct. However, I've just tried > 'NotoSerifJP-Regular.otf' – it is this font that gets packaged by many > GNU/Linux distributions, and not its sibling > 'NotoSerifCJKjp-R

Re: Problem with OTF support

I think these non-subset fonts would be fine. Maybe your analysis is correct. However, I've just tried 'NotoSerifJP-Regular.otf' – it is this font that gets packaged by many GNU/Linux distributions, and not its sibling 'NotoSerifCJKjp-Regular.otf' –, and I get exactly the same

Re: Problem with OTF support

> If this is indeed a bug [...] It definitely is. > could you please open an issue at GitLab? Done: https://gitlab.com/lilypond/lilypond/-/issues/6058 Werner

Re: Problem with OTF support

Am Montag, den 19.10.2020, 19:44 +0200 schrieb Werner LEMBERG: > [lilypond dcd531b0f, gs 9.52] > > Processing the following sample code > >   \paper { >     #(define fonts >   (set-global-fonts >    #:roman "Source Han Serif TW" >    #:sans "sans-serif" >    #:typewriter "monospac

Re: Problem with OTF support

> [lilypond dcd531b0f, gs 9.52] > > Processing the following sample code > > \paper { > #(define fonts > (set-global-fonts >#:roman "Source Han Serif TW" >#:sans "sans-serif" >#:typewriter "monospace" > )) > } > > \markup { "ろ" } % This is character

Problem with OTF support

[lilypond dcd531b0f, gs 9.52] Processing the following sample code \paper { #(define fonts (set-global-fonts #:roman "Source Han Serif TW" #:sans "sans-serif" #:typewriter "monospace" )) } \markup { "ろ" } % This is character U+308D. causes the attach

Re: GUB - today's problem

Deleted target, but the build failed at the same spot with the same error. -- Phil Holmes - Original Message - From: "Jonas Hahnfeld" To: "Phil Holmes" ; "Devel" Sent: Sunday, July 26, 2020 12:18 PM Subject: Re: GUB - today's problem

Re: GUB - today's problem

- Original Message - > From: "Jonas Hahnfeld" < > hah...@hahnjo.de > > > To: "Phil Holmes" < > em...@philholmes.net > >; "Devel" < > lilypond-devel@gnu.org > > > Sent: Sunday, July 26, 2020 11:52 AM > Subject: Re: GUB - today's problem > > > signature.asc Description: This is a digitally signed message part

Re: GUB - today's problem

uot;Phil Holmes" ; "Devel" Sent: Sunday, July 26, 2020 11:52 AM Subject: Re: GUB - today's problem

Re: GUB - today's problem

Am Sonntag, den 26.07.2020, 11:34 +0100 schrieb Phil Holmes: > From lilypond-test.log: > > /home/gub/NewGub/gub/target/tools/root/usr/lib/libffi.so.6: undefined > reference to `__stack_chk_fail@GLIBC_2.4' > /home/gub/NewGub/gub/target/tools/root/usr/lib/libffi.so.6: undefined > reference to `mko

GUB - today's problem

From lilypond-test.log: /home/gub/NewGub/gub/target/tools/root/usr/lib/libffi.so.6: undefined reference to `__stack_chk_fail@GLIBC_2.4' /home/gub/NewGub/gub/target/tools/root/usr/lib/libffi.so.6: undefined reference to `mkostemp@GLIBC_2.7' collect2: error: ld returned 1 exit status make[1]: *

Re: Today's problem with GUB build

Am Mittwoch, den 15.07.2020, 17:31 +0100 schrieb Phil Holmes: > Here's the logfile and the ly file. > > Once we understand the issue, I'll wait until you say "go" for 21.4. Okay, we have the two doc fixes (mine for HTML and Masamichi's for PDF) and Han-Wen's renaming fix in master. This does not

Re: 2.21.3 build problem on Mac OS X Mojave

Thanks a lot Werner, works like a charm! JM > Le 19 juil. 2020 à 09:11, Werner LEMBERG a écrit : > > > >> In fact I did the ‘git clone’ afresh, moving aside previous >> attempts. Thus the contents of ‘build’ on both OSes is the result of >> the commands I showed, up to '../configure'. >> >>

Re: 2.21.3 build problem on Mac OS X Mojave

> In fact I did the ‘git clone’ afresh, moving aside previous > attempts. Thus the contents of ‘build’ on both OSes is the result of > the commands I showed, up to '../configure'. > > That’s why I don’t get what happens… For me, using an up-to-date MacPorts system, compilation of LilyPond from

Re: 2.21.3 build problem on Mac OS X Mojave

PS> My goal is to build Lily to do experiments on the Mac, which is much faster and confortable for me to work with, rather that on my Debian virtual machine. > Le 18 juil. 2020 à 17:23, Jacques Menu a écrit : > > Hello Jonas and Werner, > > In fact I did the ‘git clone’ afresh, moving aside p

Re: 2.21.3 build problem on Mac OS X Mojave

Hello Jonas and Werner, In fact I did the ‘git clone’ afresh, moving aside previous attempts. Thus the contents of ‘build’ on both OSes is the result of the commands I showed, up to '../configure'. That’s why I don’t get what happens… JM > Le 18 juil. 2020 à 16:46, Werner LEMBERG a écrit :

Re: 2.21.3 build problem on Mac OS X Mojave

> I’m trying to build LilyPond 2.21.3 locally, both on Debian 9 and > Mac OS X 10.14.6 (Mojave). On the latter, I installed Apple’s > XCode, the needed tools in /opt with MacPorts, and the needed fonts > in /opt/local/share/fonts/urw-core35-fonts. You might apply https://github.com/macports/m

Re: 2.21.3 build problem on Mac OS X Mojave

Hi, Am Samstag, den 18.07.2020, 15:14 +0200 schrieb Jacques Menu: > Hello folks, > > I’m trying to build LilyPond 2.21.3 locally, both on Debian 9 and Mac OS X > 10.14.6 (Mojave). > On the latter, I installed Apple’s XCode, the needed tools in /opt with > MacPorts, and the needed fonts in /opt

2.21.3 build problem on Mac OS X Mojave

Hello folks, I’m trying to build LilyPond 2.21.3 locally, both on Debian 9 and Mac OS X 10.14.6 (Mojave). On the latter, I installed Apple’s XCode, the needed tools in /opt with MacPorts, and the needed fonts in /opt/local/share/fonts/urw-core35-fonts. Performing the same ‘git clone’ and the

Re: Today's problem with GUB build

On Fri, Jul 17, 2020 at 5:05 PM Han-Wen Nienhuys wrote: > > On Fri, Jul 17, 2020 at 4:47 PM Han-Wen Nienhuys wrote: > > Maybe something is off with the init after fork, but GUILE's random > > initialization also doesn't look very reliable: > > > > https://git.savannah.nongnu.org/cgit/guile.git//t

Re: Today's problem with GUB build

On Fri, Jul 17, 2020 at 4:47 PM Han-Wen Nienhuys wrote: > Maybe something is off with the init after fork, but GUILE's random > initialization also doesn't look very reliable: > > https://git.savannah.nongnu.org/cgit/guile.git//tree/libguile/random.c/?id=5f22d1090bef72639f2744402c0466d8dbf8f8ac#n1

Re: Today's problem with GUB build

On Thu, Jul 16, 2020 at 10:58 AM David Kastrup wrote: > > Han-Wen Nienhuys writes: > > > On Wed, Jul 15, 2020 at 10:48 PM David Kastrup wrote: > > > >> Well ok. But only 100 random numbers are being used (there is > >> another call using 1000 instead, the choice appearing random). > >>

Re: Today's problem with GUB build

Han-Wen Nienhuys writes: > On Wed, Jul 15, 2020 at 10:48 PM David Kastrup wrote: > >> Well ok. But only 100 random numbers are being used (there is >> another call using 1000 instead, the choice appearing random). >> Let's assume we have 10 processes going through 138 files each. The >

Re: Today's problem with GUB build

On Wed, Jul 15, 2020 at 10:48 PM David Kastrup wrote: > Well ok. But only 100 random numbers are being used (there is > another call using 1000 instead, the choice appearing random). > Let's assume we have 10 processes going through 138 files each. The > processes are going to switch to

Re: Today's problem with GUB build

Le 15/07/2020 à 22:48, David Kastrup a écrit : Now if I remember correctly, there were some changes in how lilypond-book worked that typically resulted in double the number of processes getting spawned than asked for which would give us 19 instead of 9 possibilities for collision. That would ra

Re: Today's problem with GUB build

Hi David, Le 15/07/2020 à 23:01, David Kastrup a écrit : Not using random at all but using the pid, in contrast, should be collision-proof, assuming that we are not working on a shared file system accessed by multiple computers with separate process id pools. But then locking is likely to be non

Re: Today's problem with GUB build

David Kastrup writes: > Jonas Hahnfeld writes: > >> Am Mittwoch, den 15.07.2020, 21:35 +0200 schrieb David Kastrup: >>> Jonas Hahnfeld writes: >>> > Am Mittwoch, den 15.07.2020, 17:31 +0100 schrieb Phil Holmes: >>> > > Here's the logfile and the ly file. >>> > >>> > Could this be collisions of

Re: Today's problem with GUB build

Jonas Hahnfeld writes: > Am Mittwoch, den 15.07.2020, 21:35 +0200 schrieb David Kastrup: >> Jonas Hahnfeld writes: >> > Am Mittwoch, den 15.07.2020, 17:31 +0100 schrieb Phil Holmes: >> > > Here's the logfile and the ly file. >> > >> > Could this be collisions of the random file names generated

Re: Today's problem with GUB build

Am Mittwoch, den 15.07.2020, 21:35 +0200 schrieb David Kastrup: > Jonas Hahnfeld writes: > > Am Mittwoch, den 15.07.2020, 17:31 +0100 schrieb Phil Holmes: > > > Here's the logfile and the ly file. > > > > Could this be collisions of the random file names generated for > > temporary files? The arg

Re: Today's problem with GUB build

Jonas Hahnfeld writes: > Am Mittwoch, den 15.07.2020, 17:31 +0100 schrieb Phil Holmes: >> Here's the logfile and the ly file. > > Could this be collisions of the random file names generated for > temporary files? The argument to backend-library.scm:248 comes > from create-file-exclusive which ret

Re: Today's problem with GUB build

Le 15/07/2020 à 19:44, Jean Abou Samra a écrit : Hi, Le 15/07/2020 à 18:31, Phil Holmes a écrit : Here's the logfile and the ly file. /home/gub/NewGub/gub/target/linux-x86/root/usr/share/lilypond/current/scm/backend-library.scm:248:5: In procedure close-port in expression (close-port port):

Re: Today's problem with GUB build

Hi, Le 15/07/2020 à 18:31, Phil Holmes a écrit : Here's the logfile and the ly file. /home/gub/NewGub/gub/target/linux-x86/root/usr/share/lilypond/current/scm/backend-library.scm:248:5: In procedure close-port in expression (close-port port): /home/gub/NewGub/gub/target/linux-x86/root/usr/shar

Re: Today's problem with GUB build

Am Mittwoch, den 15.07.2020, 17:31 +0100 schrieb Phil Holmes: > Here's the logfile and the ly file. Could this be collisions of the random file names generated for temporary files? The argument to backend-library.scm:248 comes from create-file-exclusive which returns #f if the file already exists

Re: Today's problem with GUB build

Here's the logfile and the ly file. Once we understand the issue, I'll wait until you say "go" for 21.4. -- Phil Holmes - Original Message - From: "Jonas Hahnfeld" To: "Phil Holmes" ; "Devel" Sent: Wednesday, July 15, 2020 4

Re: Today's problem with GUB build

her, I plan to do a release every couple of > weeks anyway. > > -- > Phil Holmes > > > - Original Message - > From: "Jonas Hahnfeld" < > hah...@hahnjo.de > > > To: "Phil Holmes" < > em...@philholmes.net > >; "Devel"

  1   2   3   4   5   6   7   8   9   10   >