>> there is no key signature at this point, right?
>
> This is my interpretation: the key signature is removed by
> break-visibility, but the X alignment of a mark is computed before
> that happens.
Thanks. If your interpretation is correct I consider it as
problematic, since it is not possible
> there is no key signature at this point, right?
This is my interpretation: the key signature is removed by break-visibility,
but the X alignment of a mark is computed before that happens.
signature.asc
Description: This is a digitally signed message part
In December I asked the question below on the 'lilypond-user' list
(https://lists.gnu.org/archive/html/lilypond-user/2023-12/msg00014.html),
alas, without an answer – I try again, this time on 'lilypond-devel'.
I'm also attaching the image for completeness.
Please help.
Werner
===
On May 18, 2023, at 00:29, Werner LEMBERG wrote:
>
>
>>> The snippet 'Adding volta brackets to additional staves'
>>>
>>> https://lsr.di.unimi.it/LSR/Item?id=427
>>>
>>> doesn't seem to do what the description says. Honestly, I have no
>>> idea what this snippet actually wants to demonstrate
>> The snippet 'Adding volta brackets to additional staves'
>>
>> https://lsr.di.unimi.it/LSR/Item?id=427
>>
>> doesn't seem to do what the description says. Honestly, I have no
>> idea what this snippet actually wants to demonstrate at all...
>
> https://gitlab.com/lilypond/lilypond/-/issues/6
On May 17, 2023, at 14:04, Werner LEMBERG wrote:
>
> The snippet 'Adding volta brackets to additional staves'
>
> https://lsr.di.unimi.it/LSR/Item?id=427
>
> doesn't seem to do what the description says. Honestly, I have no
> idea what this snippet actually wants to demonstrate at all...
htt
The snippet 'Adding volta brackets to additional staves'
https://lsr.di.unimi.it/LSR/Item?id=427
doesn't seem to do what the description says. Honestly, I have no
idea what this snippet actually wants to demonstrate at all...
Werner
>> > This code has obviously worked some time before, but it no longer
>> > doesn't. Is this a problem with the code or a bug?
>>
>> Fixed inside LSR by replacing
>> \once\omit Staff.BarLine
>> by
>> \once\hide Staff.BarLine
Thanks!
> I think it may be a bug. Consider:
>
> {
> \textLengthOn
Le dimanche 23 avril 2023 à 08:56 -0400, Dan Eble a écrit :
> I don't see a multi-measure rest.
D'oh! Somehow I couldn't see the actual code anymore once I was triggered by
that bug... Sorry.
(The output with \hide looks a lot like an MM rest.)
signature.asc
Description: This is a digitally
On Apr 23, 2023, at 05:22, Jean Abou Samra wrote:
>
>> {
>> \textLengthOn
>> s1-"loong"
>> \once \omit Staff.BarLine
>> \clef F
>> r1
>> }
>> with a starting spacer _and_ an omitted BarLine _and_ a clef change.
>>
>> 2.22. is ok, but output of 2.24. is bad.
>
>
> The MM r
gt; \clef F
> r1
> }
> with a starting spacer _and_ an omitted BarLine _and_ a clef change.
>
> 2.22. is ok, but output of 2.24. is bad.
The MM rest placement sounds like
https://gitlab.com/lilypond/lilypond/-/issues/6550
The horizontal placement of the clef looks strange but I haven't investigated
further.
signature.asc
Description: This is a digitally signed message part
Am So., 23. Apr. 2023 um 09:33 Uhr schrieb Thomas Morley
:
>
> Am So., 23. Apr. 2023 um 07:45 Uhr schrieb Werner LEMBERG :
> >
> >
> > Please have a look at
> >
> > https://lsr.di.unimi.it/LSR/Item?id=983
> >
> > This code has obviously worked some time before, but it no longer
> > doesn't. Is t
Am So., 23. Apr. 2023 um 07:45 Uhr schrieb Werner LEMBERG :
>
>
> Please have a look at
>
> https://lsr.di.unimi.it/LSR/Item?id=983
>
> This code has obviously worked some time before, but it no longer
> doesn't. Is this a problem with the code or a bug?
>
>
> Werner
>
Fixed inside LSR by r
Please have a look at
https://lsr.di.unimi.it/LSR/Item?id=983
This code has obviously worked some time before, but it no longer
doesn't. Is this a problem with the code or a bug?
Werner
Le lundi 27 mars 2023 à 12:17 +, Werner LEMBERG a écrit :
> For glyph 'two', the postprocessing effects are very subtle; FontForge
> adds points at all extrema and reduces the number of points to get
> smaller fonts (ensuring that the outline changes are less than a
> certain threshold). I sus
> This is the output of
> \markup \number 2
> using the official 2.25.2 Linux binaries on the one hand, and a
> self-compiled build made on the v2.25.2 tag from a clean directory
> on the other hand (PS backend in both cases).
My self-compiled LilyPond produces the 'other' glyph version (i.e.,
no
Folks,
This is the output of
\markup \number 2
using the official 2.25.2 Linux binaries on the one hand, and a self-
compiled build made on the v2.25.2 tag from a clean directory on the
other hand (PS backend in both cases).
If you look carefully at the tails on the right, you can see that they
Meanwhile I created https://gitlab.com/lilypond/lilypond/-/issues/6507
Am Sa., 31. Dez. 2022 um 19:01 Uhr schrieb Dan Eble :
>
> On Dec 30, 2022, at 12:10, Thomas Morley wrote:
> >
> > Hi all,
> >
> > please have a look at:
> >
> > \version "2.25.0"
> >
> > {
> > \override Score.BarNumber.break-
On Dec 30, 2022, at 12:10, Thomas Morley wrote:
>
> Hi all,
>
> please have a look at:
>
> \version "2.25.0"
>
> {
> \override Score.BarNumber.break-visibility = ##(#f #t #t)
> % \set Score.alternativeNumberingStyle = #'whatever
> b1
> \repeat volta 2 { c' c' }
> \alternative { d' e' }
>
Hi all,
please have a look at:
\version "2.25.0"
{
\override Score.BarNumber.break-visibility = ##(#f #t #t)
% \set Score.alternativeNumberingStyle = #'whatever
b1
\repeat volta 2 { c' c' }
\alternative { d' e' }
f'
}
As soon as the style-setting is uncommented it behaves like
\set
> Well, somehow I failed to make the obvious test: this also triggers
> the issue:
>
> \version "2.25.0"
>
> \markup \override #'(font-name . "Noto Sans Bold") "ABC"
>
>
>
> Does that reproduce it for you (after installing the Noto fonts if
> not already installed)?
>
`lilypond -dshow-avail
Le 12/12/2022 à 11:25, Werner LEMBERG a écrit :
Hmm. Using FreeType 2.12.1 (self-compiled) and FontConfig 2.13.1 (as
provided by my openSUSE box), running `lilypond --verbose` (from
current git) on the above input gives
```
...
[nonexistent_bold_3.8662109375]
Finding the ideal number of pages...
> \markup \override #'(font-name . "Nonexistent Bold") "ABC"
>
> With 2.22, this compiles without warning, and the resulting PDF
> contains the font "DejaVuSans-Bold" (according to pdffonts).
>
> With 2.23.82, it gives me
>
> GNU LilyPond 2.23.82 (running Guile 2.2)
> Processing `unfound-font.
Folks,
Coincidentally, at the same time as Lukas, I found another
font-related glitch, although I don't think it's the same:
\markup \override #'(font-name . "Nonexistent Bold") "ABC"
With 2.22, this compiles without warning, and the resulting PDF
contains the font "DejaVuSans-Bold" (accordin
>> OK, thanks. I wonder how the heuristics could be improved. Given
>> that a lyric hyphen must be preceded by whitespace, while normally
>> `--` as an articulation is following a non-whitespace character,
>> maybe a look-behind assertion for the latter would help? Something
>> similar could b
Le 02/11/2022 à 16:19, Werner LEMBERG a écrit :
OK, thanks. I wonder how the heuristics could be improved. Given
that a lyric hyphen must be preceded by whitespace, while normally
`--` as an articulation is following a non-whitespace character, maybe
a look-behind assertion for the latter would
>> ```
>> c''4-3 e-5 b-2 a-1
>> ```
>>
>> which Pygments translates to
>>
>> ```
>> @t{c''} @t{4} @t{-3} @t{e} @t{-5} @t{b} @t{-2} @t{a} @t{-1}
>> ```
>>
>> that is, the `-` is not typeset in bold.
>
> Because "-3" could just as well be a number rather than a fingering,
> and it's hard to guess.
>
Le 02/11/2022 à 14:53, Werner LEMBERG a écrit :
The above example was the wrong one, sorry. What I actually wanted to
show are inconsistencies. In the same section you can find
```
c''4-3 e-5 b-2 a-1
```
which Pygments translates to
```
@t{c''} @t{4} @t{-3} @t{e} @t{-5} @t{b} @t{-2} @t{a} @t
>> Please have a look at the attached image; it's taken from the LM,
>> chapter 3.1.4. As can be seen, `_` and `-` are bold, and `^`
>> isn't. Is it possible to make `_` and `-` bold only if used as
>> articulation (i.e., *after* `[_^-]`)?
>
> The relevant part of the output generated by lilypon
Le 29/10/2022 à 10:25, Werner LEMBERG a écrit :
Please have a look at the attached image; it's taken from the LM,
chapter 3.1.4. As can be seen, `_` and `-` are bold, and `^` isn't.
Is it possible to make `_` and `-` bold only if used as articulation
(i.e., *after* `[_^-]`)?
The relevant pat
Please have a look at the attached image; it's taken from the LM,
chapter 3.1.4. As can be seen, `_` and `-` are bold, and `^` isn't.
Is it possible to make `_` and `-` bold only if used as articulation
(i.e., *after* `[_^-]`)?
Werner
>> With current git (commit 44f1033467a6, using Guile 2.2.7), the
>> formatting of optional Scheme function arguments in the IR looks
>> strange. [...]
>
> I'll fix that later. An issue seems like the way to go for now.
Done.
https://gitlab.com/lilypond/lilypond/-/issues/6330
Werner
Le 18/04/2022 à 11:33, Werner LEMBERG a écrit :
With current git (commit 44f1033467a6, using Guile 2.2.7), the
formatting of optional Scheme function arguments in the IR looks
strange. For example, the signature
```
(define*-public (markup->string m #:key (layout #f) (props '()))
```
With current git (commit 44f1033467a6, using Guile 2.2.7), the
formatting of optional Scheme function arguments in the IR looks
strange. For example, the signature
```
(define*-public (markup->string m #:key (layout #f) (props '()))
```
appears as
```
Function: markup->string m
Le 01/03/2022 à 19:33, Werner LEMBERG a écrit :
Aren't ledger lines printed as a singular stencil for the entire
line? If so, it would make sense that the origin of the stencil
aligns with the staff symbol. It would also mean there is only one
grob to attach a balloon to.
Aah, ok. I didn't kn
Am Dienstag, dem 01.03.2022 um 14:41 + schrieb Werner LEMBERG:
> [git commit 3cdce08c24d3cef7f242214f2b48763242a2ead6]
>
> Please have a look at the output of
>
> ```
> \new Score \with {
> \consists "Balloon_engraver"
> } \new Staff {
> \balloonGrobText LedgerLineSpanner #'(1 . 1) "ledge
> Aren't ledger lines printed as a singular stencil for the entire
> line? If so, it would make sense that the origin of the stencil
> aligns with the staff symbol. It would also mean there is only one
> grob to attach a balloon to.
Aah, ok. I didn't know that (or skipped or forgot a correspo
On 2022-03-01 6:41 am, Werner LEMBERG wrote:
[git commit 3cdce08c24d3cef7f242214f2b48763242a2ead6]
Please have a look at the output of
```
\new Score \with {
\consists "Balloon_engraver"
} \new Staff {
\balloonGrobText LedgerLineSpanner #'(1 . 1) "ledger line"
c'''1
\balloonGrobText Le
[git commit 3cdce08c24d3cef7f242214f2b48763242a2ead6]
Please have a look at the output of
```
\new Score \with {
\consists "Balloon_engraver"
} \new Staff {
\balloonGrobText LedgerLineSpanner #'(1 . 1) "ledger line"
c'''1
\balloonGrobText LedgerLineSpanner #'(1 . -1) "ledger line"
c''
Le 09/11/2021 à 10:18, Han-Wen Nienhuys a écrit :
my worry would be alignment of accidental clusters. If you tweak
vertical sizes, can you still have accidentals at an octave distance
without colliding?
The accidental placement algorithm is based on
the glyphs' horizontal skylines, not their si
On Mon, Nov 8, 2021 at 7:30 PM Werner LEMBERG wrote:
> >> Does anybody know why the top and the bottom of the bounding box of
> >> the 'Flat' glyph, contrary to 'Sharp' and 'Natural', don't coincide
> >> (more or less) with the extrema of the glyph's outline? A small
> >
> > I can't remember any
On 08.11.2021 18:30, Werner LEMBERG wrote:
Does anybody know why the top and the bottom of the bounding box of
the 'Flat' glyph, contrary to 'Sharp' and 'Natural', don't coincide
(more or less) with the extrema of the glyph's outline? A small
I can't remember any reason.
The question is whe
>> Does anybody know why the top and the bottom of the bounding box of
>> the 'Flat' glyph, contrary to 'Sharp' and 'Natural', don't coincide
>> (more or less) with the extrema of the glyph's outline? A small
>
> I can't remember any reason.
:-)
The question is whether we should fix this.
Gi
On Sun, Nov 7, 2021 at 10:20 AM Werner LEMBERG wrote:
>
>
> Does anybody know why the top and the bottom of the bounding box of
> the 'Flat' glyph, contrary to 'Sharp' and 'Natural', don't coincide
> (more or less) with the extrema of the glyph's outline? A small
I can't remember any reason.
--
Does anybody know why the top and the bottom of the bounding box of
the 'Flat' glyph, contrary to 'Sharp' and 'Natural', don't coincide
(more or less) with the extrema of the glyph's outline? A small
overshoot outside of the box make sense (although Feta doesn't handle
this consistently), but the
Am Mo., 24. Mai 2021 um 12:17 Uhr schrieb David Kastrup :
>
> Thomas Morley writes:
>
> > Hi,
> >
> > while experimenting with test codes for issue
> > https://gitlab.com/lilypond/lilypond/-/issues/5977 I stumbled across:
> >
> > \score {
> > { \tempo 8 = 88 c'8^"toplevel Score" }
> > \layout
Thomas Morley writes:
> Hi,
>
> while experimenting with test codes for issue
> https://gitlab.com/lilypond/lilypond/-/issues/5977 I stumbled across:
>
> \score {
> { \tempo 8 = 88 c'8^"toplevel Score" }
> \layout { #(layout-set-staff-size 40) }
> }
>
> \book {
> \paper { #(layout-set-staff
Hi,
while experimenting with test codes for issue
https://gitlab.com/lilypond/lilypond/-/issues/5977 I stumbled across:
\score {
{ \tempo 8 = 88 c'8^"toplevel Score" }
\layout { #(layout-set-staff-size 40) }
}
\book {
\paper { #(layout-set-staff-size 40) }
{ \tempo 8 = 88 c'8^"explicit b
> Added to the tracker as
> https://gitlab.com/lilypond/lilypond/-/issues/6057.
Thanks.
> For the future, maybe this kind of quirks can be reported there
> directly (which would save them from the risk of getting lost under
> the volume of email).
Well, in most cases it's just my own clumsines
Le 16/10/2020 à 16:34, Jean Abou Samra a écrit :
Folks,
can someone please explain to me why the following code
{
\compressEmptyMeasures
c'4 4 4 4 | 4 4 4 4 | 4 4 4 4 | 4 4 4 4 | \break
R4*120 | \break
c'4 4 4 4 | 4 4 4 4 | 4 4 4 4 | 4 4 4 4 |
c'4 4 4 4 | 4 4 4 4
Folks,
can someone please explain to me why the following code
{
\compressEmptyMeasures
c'4 4 4 4 | 4 4 4 4 | 4 4 4 4 | 4 4 4 4 | \break
R4*120 | \break
c'4 4 4 4 | 4 4 4 4 | 4 4 4 4 | 4 4 4 4 |
c'4 4 4 4 | 4 4 4 4 | 4 4 4 4 | 4 4 4 4 |
c'4 4 4 4 | 4 4 4 4 | 4 4
[lilypond git 647e127c07a794d087c5e39bf23c0d4a7d66a957 from Oct. 6th]
Folks,
can someone please explain to me why the following code
{
\compressEmptyMeasures
c'4 4 4 4 | 4 4 4 4 | 4 4 4 4 | 4 4 4 4 | \break
R4*120 | \break
c'4 4 4 4 | 4 4 4 4 | 4 4 4 4 | 4 4 4 4 |
c'4 4
Am Donnerstag, den 01.10.2020, 16:03 +0200 schrieb Michael Käppler:
> Am 01.10.2020 um 12:24 schrieb Jonas Hahnfeld via Discussions on
> LilyPond development:
> > So I think it's more likely that the issue got exposed by
> > commit 5a957021a3 which runs lilypond once per document passed to
> > lily
Am 01.10.2020 um 12:24 schrieb Jonas Hahnfeld via Discussions on
LilyPond development:
So I think it's more likely that the issue got exposed by
commit 5a957021a3 which runs lilypond once per document passed to
lilypond-book instead of per included file. This increases the chance
of being unlucky
Jonas Hahnfeld writes:
> Am Donnerstag, den 01.10.2020, 14:07 +0200 schrieb David Kastrup:
>> Jonas Hahnfeld writes:
>>
>> > Am Donnerstag, den 01.10.2020, 05:07 +0200 schrieb Werner LEMBERG:
>> > > > > what was the last version in which this was seen working as
>> > > > > expected?
>> > >
>>
Am Donnerstag, den 01.10.2020, 14:07 +0200 schrieb David Kastrup:
> Jonas Hahnfeld writes:
>
> > Am Donnerstag, den 01.10.2020, 05:07 +0200 schrieb Werner LEMBERG:
> > > > > what was the last version in which this was seen working as
> > > > > expected?
> > >
> > > For me, three weeks ago.
> > >
Jonas Hahnfeld writes:
> Am Donnerstag, den 01.10.2020, 05:07 +0200 schrieb Werner LEMBERG:
>> >> what was the last version in which this was seen working as
>> >> expected?
>>
>> For me, three weeks ago.
>>
>> > Probably never did but people got lucky.
>>
>> Yes, it looks like that.
>
> So I
Am Donnerstag, den 01.10.2020, 05:07 +0200 schrieb Werner LEMBERG:
> >> what was the last version in which this was seen working as
> >> expected?
>
> For me, three weeks ago.
>
> > Probably never did but people got lucky.
>
> Yes, it looks like that.
So I think it's more likely that the issue
>> what was the last version in which this was seen working as
>> expected?
For me, three weeks ago.
> Probably never did but people got lucky.
Yes, it looks like that.
Werner
Han-Wen Nienhuys writes:
> On Wed, Sep 30, 2020 at 10:11 PM Han-Wen Nienhuys wrote:
>
>>
>>
>> On Wed, Sep 30, 2020 at 8:05 PM Werner LEMBERG wrote:
>>
>>>
>>> [git 9c3803fba4960b4afa63baeb50201a0cfa48f8f1]
>>>
>>> I
On Wed, Sep 30, 2020 at 10:11 PM Han-Wen Nienhuys wrote:
>
>
> On Wed, Sep 30, 2020 at 8:05 PM Werner LEMBERG wrote:
>
>>
>> [git 9c3803fba4960b4afa63baeb50201a0cfa48f8f1]
>>
>> I've just built the whole documentation, and I get a strange string
>>
On Wed, Sep 30, 2020 at 8:05 PM Werner LEMBERG wrote:
>
> [git 9c3803fba4960b4afa63baeb50201a0cfa48f8f1]
>
> I've just built the whole documentation, and I get a strange string
> replacement in Appendix A of the NR (from file
> `markup-list-commands.texi`), see attach
[git 9c3803fba4960b4afa63baeb50201a0cfa48f8f1]
I've just built the whole documentation, and I get a strange string
replacement in Appendix A of the NR (from file
`markup-list-commands.texi`), see attached image.
As far as I remember, this didn't happen previously. Is it possible
that
Hi David,
> @gcc experts (hence posting to devel also): Unfortunately, I cannot
> > build 2.19.15 on my machine because of errors of the type:
> >
> > /home/lukas/git/lilypond/lily/include/smobs.tcc:98:25: error: invalid
> > conversion from 'int' to 'scm_unused_struct* (*)(SCM, SCM) {aka
> > scm_u
Lukas-Fabian Moser writes:
> Hi Andrew,
>
> Am 25.06.19 um 10:56 schrieb Andrew Bernard:
>> What is it about 19? Is it some magic borderline number in some unit
>> system in lilypond? Do we know?
>
> I'd rather suspect there's some kind of "anthropic principle" at work
> here: The bugs (at least
Hi Andrew,
Am 25.06.19 um 10:56 schrieb Andrew Bernard:
What is it about 19? Is it some magic borderline number in some unit
system in lilypond? Do we know?
I'd rather suspect there's some kind of "anthropic principle" at work
here: The bugs (at least the one I reported) should probably occur
dy have an
idea what precisely is causing the problem?
Hmm, this works for me on 2.19.82 running on OSX under Frescobaldi. No extra
space.
What is your system configuration?
Now that's strange. The error can be reproduced on LilyBin, so it's not
my system (or an installation prob
Hello,
On 22/06/2019 22:48, Lukas-Fabian Moser wrote:
Folks,
while engraving a Bach chorale, I stumbled over an overlarge space
between a slur and a beam. After a happy hour of trying to boil the
problem down to a minimal example, I arrived at:
\version "2.19.39"
\new Staff
<<
{
R1
On 6/22/19, 3:48 PM, "Lukas-Fabian Moser" wrote:
That's about as much as I can contribute, I guess. Does anybody have an
idea what precisely is causing the problem?
Hmm, this works for me on 2.19.82 running on OSX under Frescobaldi. No extra
space.
What is your system conf
Folks,
while engraving a Bach chorale, I stumbled over an overlarge space
between a slur and a beam. After a happy hour of trying to boil the
problem down to a minimal example, I arrived at:
\version "2.19.39"
\new Staff
<<
{
R1
a''8( b'' b'' a'')
} \\ {
r4
}
>>
This leads
On 02/10/17 16:51, Francisco Vila wrote:
> I can not reproduce it just now. I uninstalled the precompiled version,
> did make install from git a couple of times, uninstalled it again,
> installed the procompiled version again, repeated everything a couple
> of times, and it seems to work now. The e
On 01/10/17 19:09, Federico Bruni wrote:
> If a program behaving like another program is not the strangest thing
> you have seen, well, for me it is.
> Both musicxml2ly and lilypond-book are in fact the same program, a
> python wrapper, which looks at `basename $0' to decide who is himself. I
> sti
Il giorno dom 1 ott 2017 alle 17:27, Francisco Vila
ha scritto:
On 29/09/17 09:47, Francisco Vila wrote:
Hello,
In 2.19.80 (git translation branch) it happens that lilypond-book
thinks
it is musicxml2ly and behaves as such. When I install our
pre-compiled
version 2.19.65 from the web,
On 29/09/17 09:47, Francisco Vila wrote:
> Hello,
> In 2.19.80 (git translation branch) it happens that lilypond-book thinks
> it is musicxml2ly and behaves as such. When I install our pre-compiled
> version 2.19.65 from the web, everything looks right.
>
> I lack the knowledge to debug this, but I
Hello,
In 2.19.80 (git translation branch) it happens that lilypond-book thinks
it is musicxml2ly and behaves as such. When I install our pre-compiled
version 2.19.65 from the web, everything looks right.
I lack the knowledge to debug this, but I'd thank any clue to begin
with. Thank you!
--
Fran
2015-08-29 17:42 GMT+02:00 David Kastrup :
> Thomas Morley writes:
>
>> 2015-08-29 5:30 GMT+02:00 David Kastrup :
>>> Thomas Morley writes:
>>>
Being on LilyDev3 ("Debian GNU/Linux 7 (wheezy)")
I nuked my build, and started from scratch and I knew texgyre was
_not_ installed.
Thomas Morley writes:
> 2015-08-29 5:30 GMT+02:00 David Kastrup :
>> Thomas Morley writes:
>>
>>> Being on LilyDev3 ("Debian GNU/Linux 7 (wheezy)")
>>>
>>> I nuked my build, and started from scratch and I knew texgyre was
>>> _not_ installed.
>>>
>>> Trying Dan's advice to get texgyre
>>> http:/
2015-08-29 5:30 GMT+02:00 David Kastrup :
> Thomas Morley writes:
>
>> Being on LilyDev3 ("Debian GNU/Linux 7 (wheezy)")
>>
>> I nuked my build, and started from scratch and I knew texgyre was
>> _not_ installed.
>>
>> Trying Dan's advice to get texgyre
>> http://lists.gnu.org/archive/html/lilypon
Thomas Morley writes:
> Being on LilyDev3 ("Debian GNU/Linux 7 (wheezy)")
>
> I nuked my build, and started from scratch and I knew texgyre was
> _not_ installed.
>
> Trying Dan's advice to get texgyre
> http://lists.gnu.org/archive/html/lilypond-devel/2015-08/msg00132.html
> didn't succeed.
>
>
On 29-08-2015 01:12, Thomas Morley wrote:
.
.
I had a similiar problem:
Being on LilyDev3 ("Debian GNU/Linux 7 (wheezy)")
I nuked my build, and started from scratch and I knew texgyre was
_not_ installed.
Trying Dan's advice to get texgyre
http://lists.gnu.org/archive/html/lilypond-
2015-08-28 10:13 GMT+02:00 Villum Sejersen :
> For around a week I have encountered a strange error message when installing
> lilypond master from git sources. I have no local branches.
>
> address@hidden:/usr/local/src/lilypond/build# lilypond -v
> GNU LilyPond 2.19.26
>
&g
Villum Sejersen writes:
> Hello
>
> On 28-08-2015 13:11, James wrote:
>
>> Hello,
>>
>>
>> On 28/08/15 09:13, Villum Sejersen wrote:
>>> For around a week I have encountered a strange error message when
>>> installing lilypond master from
> Hello
>
> On 28-08-2015 13:11, James wrote:
>
>> Hello,
>>
>>
>> On 28/08/15 09:13, Villum Sejersen wrote:
>>> For around a week I have encountered a strange error message when
>>> installing lilypond master from git sources. I have no
Hello
On 28-08-2015 13:11, James wrote:
Hello,
On 28/08/15 09:13, Villum Sejersen wrote:
For around a week I have encountered a strange error message when
installing lilypond master from git sources. I have no local branches.
address@hidden:/usr/local/src/lilypond/build# lilypond -v
GNU
Hello,
On 28/08/15 09:13, Villum Sejersen wrote:
> For around a week I have encountered a strange error message when
> installing lilypond master from git sources. I have no local branches.
>
> address@hidden:/usr/local/src/lilypond/build# lilypond -v
> GNU LilyPond 2.19.26
&
For around a week I have encountered a strange error message when
installing lilypond master from git sources. I have no local branches.
address@hidden:/usr/local/src/lilypond/build# lilypond -v
GNU LilyPond 2.19.26
Until at the point shown below, no errors or warnings occurred.
=
git
David Kastrup writes:
> David Kastrup writes:
>
>> Cleaned everything out. Baseline got rebuilt, same error. Checking
>> different patch (4360 instead of 4357), same error.
>>
>> I'll eventually do the "reboot computer" dance but I suspect that we got
>> ourselves a problem with Ubuntu 15.04.
> I suspect that we got ourselves a problem with Ubuntu 15.04.
I got the same assertion, on Lubuntu 15.04.
p
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
On 01/05/15 11:36, David Kastrup wrote:
James writes:
On 01/05/15 10:28, David Kastrup wrote:
David Kastrup writes:
"Phil Holmes" writes:
- Original Message -
From: "David Kastrup"
To:
Sent: Friday, May 01, 2015 9:47 AM
Subject: Strange "make c
On 01/05/15 11:40, David Kastrup wrote:
David Kastrup writes:
Cleaned everything out. Baseline got rebuilt, same error. Checking
different patch (4360 instead of 4357), same error.
I'll eventually do the "reboot computer" dance but I suspect that we got
ourselves a problem with Ubuntu 15.
David Kastrup writes:
> Cleaned everything out. Baseline got rebuilt, same error. Checking
> different patch (4360 instead of 4357), same error.
>
> I'll eventually do the "reboot computer" dance but I suspect that we got
> ourselves a problem with Ubuntu 15.04.
Well, either that, or with the
James writes:
> On 01/05/15 10:28, David Kastrup wrote:
>> David Kastrup writes:
>>
>>> "Phil Holmes" writes:
>>>
>>>> - Original Message -
>>>> From: "David Kastrup"
>>>> To:
>>>> S
On 01/05/15 10:28, David Kastrup wrote:
David Kastrup writes:
"Phil Holmes" writes:
- Original Message -
From: "David Kastrup"
To:
Sent: Friday, May 01, 2015 9:47 AM
Subject: Strange "make check" error
Never seen anything like that. I
David Kastrup writes:
> "Phil Holmes" writes:
>
>> - Original Message -
>> From: "David Kastrup"
>> To:
>> Sent: Friday, May 01, 2015 9:47 AM
>> Subject: Strange "make check" error
>>
>>
>>>
>
"Phil Holmes" writes:
> - Original Message -
> From: "David Kastrup"
> To:
> Sent: Friday, May 01, 2015 9:47 AM
> Subject: Strange "make check" error
>
>
>>
>> Never seen anything like that. I suppose it will be a
- Original Message -
From: "David Kastrup"
To:
Sent: Friday, May 01, 2015 9:47 AM
Subject: Strange "make check" error
Never seen anything like that. I suppose it will be a fluke and
rerunning the test will "fix" it, but has anybody encountered anyth
p/lilypond-autobuild/GNUmakefile.in:325: recipe for target 'local-check'
failed
make: *** [local-check] Error 1
Never seen anything like that. I suppose it will be a fluke and
rerunning the test will "fix" it, but has anybody encoun
James,
you are right, I just wanted to answer fast between 2 appointments.
Here it is
Franck
2015-01-27 17:07 GMT-05:00, James Lowe :
> On 27/01/15 18:25, Ali Cuota wrote:
>> Here it is.
>
> Hardly a 'tiny' example
>
> http://lilypond.org/tiny-examples.html
>
> Can you at least get rid of the cruf
2015-01-27 23:07 GMT+01:00 James Lowe :
> On 27/01/15 18:25, Ali Cuota wrote:
>> Here it is.
>
> Hardly a 'tiny' example
>
> http://lilypond.org/tiny-examples.html
>
> Can you at least get rid of the cruft that isn't anything to do with the
> problem? I.e. a single file would help to determine if t
On 27/01/15 18:25, Ali Cuota wrote:
> Here it is.
Hardly a 'tiny' example
http://lilypond.org/tiny-examples.html
Can you at least get rid of the cruft that isn't anything to do with the
problem? I.e. a single file would help to determine if the problem is to
do with the 'include' function or not
1 - 100 of 259 matches
Mail list logo
