> Can't reproduce this here on x86_64, Ubuntu 22.04.
> I did 100 subsequent runs without a single failure.
>
> Jean, which system are you on?
Fedora 40, x86_64.
> If you can reproduce this often enough, could you share a core dump?
Well, I've been testing it with the official released binaries
Can't reproduce this here on x86_64, Ubuntu 22.04.
I did 100 subsequent runs without a single failure.
Jean, which system are you on?
If you can reproduce this often enough, could you share a core dump?
Am 02.06.2024 um 14:41 schrieb Jean Abou Samra:
On my Linux machine with 2.25.16, that file
On Sun, Jun 2, 2024 at 9:09 AM Werner LEMBERG wrote:
>
> > On my Linux machine with 2.25.16, that file nondeterministically
> > compiles, segfaults, or triggers a floating point exception. No time
> > to investigate more, though.
>
> Trevor, please open an issue!
>
Done.
Opened as #6716.
Thank
> On my Linux machine with 2.25.16, that file nondeterministically
> compiles, segfaults, or triggers a floating point exception. No time
> to investigate more, though.
Trevor, please open an issue!
Werner
On my Linux machine with 2.25.16, that file nondeterministically compiles,
segfaults, or triggers a floating point exception. No time to investigate
more, though.
signature.asc
Description: This is a digitally signed message part
Aha, thanks for running under Windows.
Further testing shows it's a bug with only the ARM distributions of 2.25.15
and 2.25.16; running on a MacBook Air with an M2 (2022) chip under macOS
14.5 gives these results:
2.25.16 (ARM): infinite loop
2.25.15 (ARM): infinite loop
2.25.16 (x86): OK
2.25.1
If there's a connection to Guile, we know there are some differences in
the distributions by platform.
I would try on my Win10 system, but I managed to find myself in
hospital again. (Nothing to serious.)
On May 31, 2024 12:28 AM, Craig Fearing via bug-lilypond
wrote:
FWIW
FWIW I ran this 15 consecutive times on my Win 11, Ryzen 7 system. One
time it took 2 seconds to compile, the rest were all 1.9 seconds. No
errors any time.
On 2024-05-30 23:24, Trevor Bača wrote:
Hi,
I have what appears to be a very difficult bug.
[snip]
... I suspect it may take two or
two or three
successive attempts to interpret music.ly before triggering the loop on
some operating systems (or chip architectures), even though the loop
triggers consistently on my machine.
Note, too, that LilyPond sometimes (though not always) crashes out of the
infinite loop with ...
fatal error
I am getting a programming error with the following code:
%%%
\version "2.24.3" % 2.25.14 too
rightHand = \relative {
c''4( c c c | \break
g4 g \tuplet 3/2 4 { c,8) \change Staff = "lower" g[ g] } g4 |
}
\new PianoStaff <<
\new Staff = "upper&q
> Also, I'm pretty sure that the intent of FcChar8* in Fontconfig is
> to represent UTF-8 so this is probably worthy of a bug report to the
> Fontconfig people?
Indeed. To do so it would be helpful to check the output of `fc-list`
(ideally with proper patterns to make the result more similar to
> I can confirm that replacing
>
> scm_write_line (ly_string2scm (str), port);
>
> with
>
> scm_c_write (port, str.c_str (), str.length ());
>
> fixes the issue on my end. I’d be happy to make a merge request for
> this.
I've updated
https://gitlab.com/lilypond/lilypond/-/merge_requests/2231
the time to check this but is there not a way to simply write
>> bytes to (current-error-port) in Guile?
>
> Like scm_c_write <
> https://www.gnu.org/software/guile/manual/html_node/Using-Ports-from-C.html >
> ?
> I don't have the time to check this but is there not a way to simply write
> bytes to (current-error-port) in Guile?
Like scm_c_write
< https://www.gnu.org/software/guile/manual/html_node/Using-Ports-from-C.html >
?
signature.asc
Description: This is a digitally signed message part
Le vendredi 12 janvier 2024 à 06:08 +, Werner LEMBERG a écrit :
> How shall we proceed?
I don't have the time to check this but is there not a way to simply write bytes
to (current-error-port) in Guile? IIRC, all Guile ports can be used in both
binary and text ways.
Also, I'
Le mardi 09 janvier 2024 à 12:43 -0500, Nate Whetsell a écrit :
> I’m starting to think this may be a bug in Guile.
Well, Guile's encoding handling is quite bug-ridden.
signature.asc
Description: This is a digitally signed message part
works as expected (with a � where the encoding issue occurs). When
>> I use the default strategy ('error, presumably), LilyPond outputs:
>> [...]
>
> How shall we proceed?
>
>
>Werner
be a bug in Guile.
Can you make your example code generic and report it to the Guile
people?
> When I use a conversion strategy of 'substitute, the conversion
> works as expected (with a � where the encoding issue occurs). When
> I use the default strategy ('error, presumabl
Thanks for making the merge request. Unfortunately, it didn’t fix the issue,
although it really seems like it should have. I’m starting to think this may be
a bug in Guile.
With the patch applied, running `lilypond -dshow-available-fonts` outputs:
GNU LilyPond 2.25.12 (running Guile 3.0)
ERROR
> On macOS Ventura v13.6.3 (and almost certainly other versions), the
> string produced when using -dshow-available-fonts need not be
> encoded as UTF-8.
Thanks, should be fixed with this MR:
https://gitlab.com/lilypond/lilypond/-/merge_requests/2231
Out of interest: Which font shows this be
05fstringn>.
That function throws an error when conversion fails (that is, when the C
string passed to scm_from_utf8_stringn is not actually encoded as UTF-8).
On macOS Ventura v13.6.3 (and almost certainly other versions), the string
produced when using -dshow-available-fonts need not be e
Using the snippet below (based on the official webpage's one) causes an
extra full measure rest to be printed out of the staff, overlapping the
mark "D.S..." (see print screen below).
It happens every time one or more full measure rests are added at the
beginning of Coda when using the version 2.24
On 01/02/2023 11:12, Jean Abou Samra wrote:
> Saul,
>
>
>> Le 1 févr. 2023 à 04:16, Saul Tobin a écrit :
>>
>> The fourth example engraver here:
>> https://extending-lilypond.readthedocs.io/en/latest/extending/translation.html#fourth-engraver-example
>>
>> Running this code in 2.24 crashes on i
Am Mi., 1. Feb. 2023 um 04:16 Uhr schrieb Saul Tobin
:
>
> The fourth example engraver here:
> https://extending-lilypond.readthedocs.io/en/latest/extending/translation.html#fourth-engraver-example
>
> Running this code in 2.24 crashes on initializing the engraver with In
> procedure ly:spanner-set
> Le 1 févr. 2023 à 11:23, Thomas Morley a écrit :
>
> Am Mi., 1. Feb. 2023 um 04:16 Uhr schrieb Saul Tobin
> :
>>
>> The fourth example engraver here:
>> https://extending-lilypond.readthedocs.io/en/latest/extending/translation.html#fourth-engraver-example
>>
>> Running this code in 2.24 c
Saul,
> Le 1 févr. 2023 à 04:16, Saul Tobin a écrit :
>
> The fourth example engraver here:
> https://extending-lilypond.readthedocs.io/en/latest/extending/translation.html#fourth-engraver-example
>
> Running this code in 2.24 crashes on initializing the engraver with In
> procedure ly:spanne
The fourth example engraver here:
https://extending-lilypond.readthedocs.io/en/latest/extending/translation.html#fourth-engraver-example
Running this code in 2.24 crashes on initializing the engraver with In
procedure ly:spanner-set-bound!: Wrong type argument in position 3
(expecting Item): ().
Hi,
with 2.25.0
/Documentation/snippets/new/ancient-notation-templatemodern-transcription-of-gregorian-music.ly
emits:
programming error: no stem for note column
Cheers,
Harm
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https
Le 12/07/2022 à 19:26, Pascal LEGRIS via bug-lilypond a écrit :
% French é character for ré is not displayed in chord name and the following
warning is displayed:
% (process:55672): Pango-WARNING **: 18:36:49.582:
% Invalid UTF-8 string passed to pango_layout_set_text()
% Avertissement : aucun g
% French é character for ré is not displayed in chord name and the following
warning is displayed:
% (process:55672): Pango-WARNING **: 18:36:49.582:
% Invalid UTF-8 string passed to pango_layout_set_text()
% Avertissement : aucun glyphe ne correspond au caractère U+FFFD
% dans la fonte «
/opt/
Le 16/06/2022 à 01:41, Knute Snortum a écrit :
Using one-page-breaking and ragged-last-bottom together produces a
fatal error. I can see that these two properties don't make sense
together, but ragged-last-bottom should just be ignored or some
graceful warning issued.
\version &q
Using one-page-breaking and ragged-last-bottom together produces a
fatal error. I can see that these two properties don't make sense
together, but ragged-last-bottom should just be ignored or some
graceful warning issued.
\version "2.23.9"
\paper {
ragged-last-bottom = ##f
Le 08/06/2022 à 12:46, David Kastrup a écrit :
Knute Snortum writes:
The following snippet will cause an error in version 2.22.2:
%%%
\version "2.22.2"
\relative {
c''2. \grace { b16[ c] } \slashedGrace { d8 } c4\trill |
}
%%%
This error does not show up in 2.23.9
Knute Snortum writes:
> The following snippet will cause an error in version 2.22.2:
>
> %%%
> \version "2.22.2"
>
> \relative {
> c''2. \grace { b16[ c] } \slashedGrace { d8 } c4\trill |
> }
> %%%
>
> This error does not show up in 2.23.9,
The following snippet will cause an error in version 2.22.2:
%%%
\version "2.22.2"
\relative {
c''2. \grace { b16[ c] } \slashedGrace { d8 } c4\trill |
}
%%%
This error does not show up in 2.23.9, so I don't know if there's any
action to take, but I thought I
On May 27, 2022, at 10:28, Jean Abou Samra wrote:
>
> Le 27/05/2022 à 14:34, Dan Eble a écrit :
>> I would at least like to understand whether the error message is reasonable
>> first.
>
> Do you mean whether it is reasonable for \bar "" during a
> no
Le 27/05/2022 à 14:34, Dan Eble a écrit :
I would at least like to understand whether the error message is
reasonable first.
Do you mean whether it is reasonable for \bar "" during a
note to trigger a programming error, or whether it is
reasonable for MensuralStaff to have "&q
quot;")?
I think that measureBarType = #'() would be harmless in \incipit because there
is no need to allow break points, but with so much already in flux, I would
prefer not to throw in another hack. I would at least like to understand
whethe
indent = 5\cm
incipit-width = 3\cm
}
}
with recent versions it returns:
programming error: Loose column does not have right side to attach to.
First bad comit is:
commit 8ae26d8330c603d249fec5953a887de9fbcbe31c
Author: Dan Eble
Date: Thu Mar 10 20:08:31 2022 -0500
Refactor Ba
; >\layout {
> > indent = 5\cm
> > incipit-width = 3\cm
> >}
> > }
> >
> > with recent versions it returns:
> > programming error: Loose column does not have right side to attach to.
> >
> > First bad com
Le 26/05/2022 à 17:12, Thomas Morley a écrit :
Hi,
consider:
\score {
\new Staff \with { instrumentName = "" } { \incipit { c'1. } R1 }
\layout {
indent = 5\cm
incipit-width = 3\cm
}
}
with recent versions it returns:
programming error: Loose column does
Hi,
consider:
\score {
\new Staff \with { instrumentName = "" } { \incipit { c'1. } R1 }
\layout {
indent = 5\cm
incipit-width = 3\cm
}
}
with recent versions it returns:
programming error: Loose column does not have right side to attach to.
First bad c
Le 02/05/2022 à 08:50, Stéphane SOPPERA a écrit :
Hi,
This very basic program reproduce the issue:
#(error "test")
\relative {
c'1 |
}
With Lilypond 2.20, the compilation produces:
Processing `scheme_err.ly'
Parsing...
scheme_err.ly:1:2: error: GUILE signaled an erro
Hi,
This very basic program reproduce the issue:
#(error "test")
\relative {
c'1 |
}
With Lilypond 2.20, the compilation produces:
Processing `scheme_err.ly'
Parsing...
scheme_err.ly:1:2: error: GUILE signaled an error for the expression
beginning here
#
(error &qu
Le 22/03/2022 à 21:29, Knute Snortum a écrit :
If you use strict-note-spacing (or strict-grace-spacing) with grace
notes that contain a spacer, a programming error is encountered. Here
is a MWE:
%%%
\version "2.23.6"
\relative c'''' {
g4
\
If you use strict-note-spacing (or strict-grace-spacing) with grace
notes that contain a spacer, a programming error is encountered. Here
is a MWE:
%%%
\version "2.23.6"
\relative c'''' {
g4
\newSpacingSection
\override Score.SpacingSpanner.strict-note-spac
lilypond, I get the "Library not loaded" error:
>
> dyld: Library not loaded: @executable_path/../lib/libintl.8.dylib
>Referenced from: /Applications/LilyPond.app/Contents/Resources/bin/lilypond
>Reason: image not found
> Abort trap: 6
>
> There is a fix onlin
This is something that has been happening for the past eight months,
since at least version 2.21. I can download and install the latest
version for my operating system (10.12.6), but whenever I try to run
lilypond, I get the "Library not loaded" error:
dyld: Library not loaded: @execu
Per the original error message I posted, it was trying to use version 3.8 of
the Homebrew version. But I tried linking version 3.8, and then version 3.9,
and even 3.6, still got errors. But in each case, python on the system side had
no trouble importing encodings.
> On Oct 12, 2021, at 4
Am Dienstag, dem 12.10.2021 um 16:15 -0400 schrieb Jim Weisbin:
>
>
> > On Oct 12, 2021, at 4:13 PM, Jonas Hahnfeld
> > wrote:
> >
> > Am Dienstag, dem 12.10.2021 um 16:02 -0400 schrieb Jim Weisbin:
> > > I was under some pressure to get this working for a client, who
> > > was unfortunately on
> On Oct 12, 2021, at 4:13 PM, Jonas Hahnfeld wrote:
>
> Am Dienstag, dem 12.10.2021 um 16:02 -0400 schrieb Jim Weisbin:
>> I was under some pressure to get this working for a client, who was
>> unfortunately on Mac OS Catalina. I tried importing xml files with
>> many many different combinatio
Am Dienstag, dem 12.10.2021 um 16:02 -0400 schrieb Jim Weisbin:
> I was under some pressure to get this working for a client, who was
> unfortunately on Mac OS Catalina. I tried importing xml files with
> many many different combinations of Lilypond and Frescobaldi. The
> only combination I could g
I was under some pressure to get this working for a client, who was
unfortunately on Mac OS Catalina. I tried importing xml files with many many
different combinations of Lilypond and Frescobaldi. The only combination I
could get to work was with Frescobaldi 3.1.2 and an "unofficial" build of
L
Am Montag, dem 11.10.2021 um 23:49 +0200 schrieb Jean Abou Samra:
>
> Le 10/10/2021 à 10:15, James a écrit :
> > Hello Jim,
> >
> > I didn't see any replies to this but it seems to me that this might be
> > Frescobaldi specific. The Frescobaldi developer lurks on these lists
> > but it might be
Le 10/10/2021 à 10:15, James a écrit :
Hello Jim,
I didn't see any replies to this but it seems to me that this might be
Frescobaldi specific. The Frescobaldi developer lurks on these lists
but it might be worth pinging him directly.
There are a number of ways - https://frescobaldi.org/lin
James
Lilypond 2.22.1 installed via Macports, works. Frescobaldi v 3.1.3 installed
via the DMG works. But fails to import MusicXML files with this error:
Starting musicxml2ly...
Python path configuration:
PYTHONHOME = '/Applications/Fresc
Lilypond 2.22.1 installed via Macports, works. Frescobaldi v 3.1.3 installed
via the DMG works. But fails to import MusicXML files with this error:
Starting musicxml2ly...
Python path configuration:
PYTHONHOME = '/Applications/Frescobaldi.app/Contents/Resources'
PYTHONPATH =
ve { \global \grace s8 r4}
>> }
%%%
--
Knute Snortum
On Sun, Sep 19, 2021 at 6:38 AM Martin Steindl
wrote:
>
> Hello,
>
> I stumbled on a weird display error when using \acciaccatura (or any
> other grace note) on the beginning of a staff in a multi-staff environment.
>
Hello,
I stumbled on a weird display error when using \acciaccatura (or any
other grace note) on the beginning of a staff in a multi-staff environment.
Somehow, the time signature (and the key -- not shown in example) is
displayed before _and_ after the \acciaccatura.
Greetings
Martin
thanks
On 05/09/2021 18:16, Jean Abou Samra wrote:
Le 05/09/2021 à 10:45, Jean Abou Samra a écrit :
I'll probably propose a patch.
Here you go:
https://gitlab.com/lilypond/lilypond/-/merge_requests/909
Jean
--
Regards
James
___
bug-lilypond
Le 05/09/2021 à 10:45, Jean Abou Samra a écrit :
I'll probably propose a patch.
Here you go:
https://gitlab.com/lilypond/lilypond/-/merge_requests/909
Jean
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/
Hello anyone on the bug list, could someone just verify what was
reported by Paul (below) sounds correct and if this is a bug or just a
doc edit (or both).
Thanks,
James
Thanks for reminding.
Le 25/08/2021 à 15:36, Paul Hodges a écrit :
On the page:
http://lilypond.org/doc/v2.23/Docum
Hello anyone on the bug list, could someone just verify what was
reported by Paul (below) sounds correct and if this is a bug or just a
doc edit (or both).
Thanks,
James
On 25/08/2021 14:36, Paul Hodges wrote:
On the page:
http://lilypond.org/doc/v2.23/Documentation/notation/custom-titles-h
On the page:
http://lilypond.org/doc/v2.23/Documentation/notation/custom-titles-headers-and-footers
the syntax for using \on-the-fly is specified as:
variable = \markup {
…
\on-the-fly \procedure markup
…
}
and the following examples use the same. Note the use of \ to in
Am Samstag, dem 13.02.2021 um 14:58 + schrieb James:
> On Sat, 2021-02-13 at 13:29 +0100, Johannes Feulner wrote:
> > HI there,
> >
> > updating from LilyPond version 2.19.53 to 2.23.1 I found unexpected
> > non-fatal error messages in LilyPonds output whenever a
On Sat, 2021-02-13 at 13:29 +0100, Johannes Feulner wrote:
> HI there,
>
> updating from LilyPond version 2.19.53 to 2.23.1 I found unexpected
> non-fatal error messages in LilyPonds output whenever a music
> function
> is defined:
>
> Analysieren...
> Programmierf
Le 13/02/2021 à 13:29, Johannes Feulner a écrit :
HI there,
updating from LilyPond version 2.19.53 to 2.23.1 I found unexpected
non-fatal error messages in LilyPonds output whenever a music function
is defined:
Analysieren...
Programmierfehler: Parsed object should be dead #Music((void
Johannes Feulner writes:
> HI there,
>
> updating from LilyPond version 2.19.53 to 2.23.1 I found unexpected
> non-fatal error messages in LilyPonds output whenever a music function
> is defined:
>
> Analysieren...
> Programmierfehler: Parsed object should be dead #
HI there,
updating from LilyPond version 2.19.53 to 2.23.1 I found unexpected
non-fatal error messages in LilyPonds output whenever a music function
is defined:
Analysieren...
Programmierfehler: Parsed object should be dead #Music((void . #t))((name . Music) (types)) >
This happens even
>> `convert-ly` is a python script. For Windows, rename the file
>>
>> c:\Program Files (x86)\usr\bin\convert-ly
>>
>> to
>>
>> convert-ly.py
>>
>> Then Windows will know to run the python interpreter on this file.
>>
>> NOTE: This script works as is on Linux because the first line of the
>
> `convert-ly` is a python script. For Windows, rename the file
>
> c:\Program Files (x86)\usr\bin\convert-ly
>
> to
>
> convert-ly.py
>
> Then Windows will know to run the python interpreter on this file.
>
> NOTE: This script works as is on Linux because the first line of the
> script say
`bug.ly'
> Parsing...
> Interpreting music...
> Preprocessing graphical objects...
> Finding the ideal number of pages...
> Fitting music on 1 page...
> Drawing systems...
> programming error: no broken bound
> continuing, cross fingers
> programming error: no broken bo
Hi Carl,
Thanks for your thoughtful response, and apologies for my ignorance, I'm a
newbie and this is my first reported "bug". At the time, I was trying to
figure out a way to hide unnecessary printed chords for irregular or long
intervals. Since then, someone on the user list pointed out that t
On 2/29/20, 1:46 AM, "Ben Eichler" wrote:
HI there,
I read at "2.7.2 Displaying Chords" in the docs: "*Chord names can be
displayed only at the start of lines and when the chord changes.*"
This is a little bit misleading. By default, each chord in the content is
Hello Ben,
On 29/02/2020 08:46, Ben Eichler wrote:
HI there,
I read at "2.7.2 Displaying Chords" in the docs: "*Chord names can be
displayed only at the start of lines and when the chord changes.*"
This is a little bit misleading. By default, each chord in the content is
printed by Lilypond.
HI there,
I read at "2.7.2 Displaying Chords" in the docs: "*Chord names can be
displayed only at the start of lines and when the chord changes.*"
This is a little bit misleading. By default, each chord in the content is
printed by Lilypond. The documentation is trying to point out that this
beh
Hi,
When I compile this file, I get the following output:
GNU LilyPond 2.19.83
Processing `bug.ly'
Parsing...
Interpreting music...
Preprocessing graphical objects...
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing systems...
programming error: no broken bound
conti
Am 27.12.19 um 00:33 schrieb Thomas Morley:
Hi,
the following code returns
programming error: Loose column does not have right side to attach to.
for all versions from 2.14.2 up to 2.21.0
No error for 2.12.3
{
\set Score.defaultBarType = #""
r2
b1\glissando
c'
}
Hi,
the following code returns
programming error: Loose column does not have right side to attach to.
for all versions from 2.14.2 up to 2.21.0
No error for 2.12.3
{
\set Score.defaultBarType = #""
r2
b1\glissando
c'
}
Cheers,
Harm
This doesn’t crash in current master.
Am 19.10.19 um 21:11 schrieb Mats Bengtsson:
Sorry, here comes the buggy example:
\version "2.19.83"
\relative c'{
\time 2/4
% This first line gives the error:
d16 d64-. ( d-. d-. d-. ) e16 e16:64 fis16 fis16:64 g16 g16:64 |
% Explicitly
Sorry, here comes the buggy example:
\version "2.19.83"
\relative c'{
\time 2/4
% This first line gives the error:
d16 d64-. ( d-. d-. d-. ) e16 e16:64 fis16 fis16:64 g16 g16:64 |
% Explicitly shortening the beam helps:
d16 [ d64-. ( d-. d-. d-. )] e16 e16:64 fis16 fis16:64 g16
Hi,
The following example illustrates a bug in 2.19.83 that's a regression
against 2.18. Compiling with 2.19.83 gives
GNU LilyPond 2.19.83
Processing `bug.ly'
Parsing...
Interpreting music...
Preprocessing graphical objects...lilypond:
/home/gub/NewGub/gub/target/linux-64/src/lilypond-git.sv.
Am Fr., 20. Sept. 2019 um 02:19 Uhr schrieb Andrew Bernard
:
>
> Using 2.21 from git, the non-default tuplet example in the NR throws an
> error.
>
>
> \relative c'' {
>\once \override TupletNumber.text =
> #(tuplet-number::non-default-tuplet-denominator-
Using 2.21 from git, the non-default tuplet example in the NR throws an
error.
\relative c'' {
\once \override TupletNumber.text =
#(tuplet-number::non-default-tuplet-denominator-text 7)
\tuplet 3/2 { c4. c4. c4. c4. }
\once \override TupletNumber.text =
#(tuplet-n
I don't know if this has been reported, but I just updated pango on Arch, and
the version 1:1.44.5-1 is working fine now !
--
Sent from: http://lilypond.1069038.n5.nabble.com/Bugs-f58488.html
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://
> these "compressing over-full page" warnings may be caused
> by running a lilypond executable, which was compiled with
> the old pango library (1.43), with the new pango lib (1.44).
Good news: The newest Pango version (1.44.5) works again with
LilyPond; the problems have been fixed (on the Pango
), with the new pango lib (1.44).
>
> What is your pango version?
>
> Thomas
>
> On Wed, Aug 14, 2019 at 03:16:56PM +0200, Anzick wrote:
>
>> Hello, with even the most simple score I am getting this error:
>>
>>
>> warning: compressing over-full pag
with even the most simple score I am getting this error:
>
>
> warning: compressing over-full page by 77044.3 staff-spaces
>
>
> warning: page 1 has been compressed
>
>
> The same file apears to work fine on Mac, but not on Linux.
> \version "2.19.82"
>
On 2019-08-14 6:16 am, Anzick wrote:
Hello, with even the most simple score I am getting this error:
warning: compressing over-full page by 77044.3 staff-spaces
warning: page 1 has been compressed
The same file apears to work fine on Mac, but not on Linux.
Could you provide details of your
Am 14.08.19 um 15:16 schrieb Anzick:
Hello, with even the most simple score I am getting this error:
warning: compressing over-full page by 77044.3 staff-spaces
warning: page 1 has been compressed
The same file apears to work fine on Mac, but not on Linux.
Hi Anzick,
I cannot
Hello, with even the most simple score I am getting this error:
warning: compressing over-full page by 77044.3 staff-spaces
warning: page 1 has been compressed
The same file apears to work fine on Mac, but not on Linux.
\version "2.19.82"
\pointAndClickOff
\header {
tit
On Tue, Aug 06, 2019 at 12:11:44PM +0200, Knut Petersen wrote:
> On 04.08.19 13:39, Werner LEMBERG wrote:
> >>In my case, it's not really a compilation error but mostly strange
> >>behavior with texts and markups. Here is a very small example with
> >>a bug in
On 04.08.19 13:39, Werner LEMBERG wrote:
In my case, it's not really a compilation error but mostly strange
behavior with texts and markups. Here is a very small example with
a bug in the appearance of the TimeSignature.
<http://lilypond.1069038.n5.nabble.com/file/t5604/51.png>
> In my case, it's not really a compilation error but mostly strange
> behavior with texts and markups. Here is a very small example with
> a bug in the appearance of the TimeSignature.
>
> <http://lilypond.1069038.n5.nabble.com/file/t5604/51.png>
Hmm. The only thi
Werner LEMBERG wrote
> The question is now what exactly causes this:
>
> error: invalid conversion from 'gpointer' {aka 'void*'}
> to 'FT_Face' {aka 'FT_FaceRec_*'}
>
> during the lilypond compilation? Is this really caused by
> The question is now what exactly causes this:
>
> error: invalid conversion from 'gpointer' {aka 'void*'}
> to 'FT_Face' {aka 'FT_FaceRec_*'}
>
> during the lilypond compilation? Is this really caused by pango? Or
> is
s major version (i.e., the
first zero after `.so' in the library name). This means that by
default the dynamic linker uses the library file with the most recent
minor and patch version (4400.2).
The question is now what exactly causes this:
error: invalid conversion from 'gpointer&#
Hello,
also on Arch Linux.
1.44-1 lists
lrwxrwxrwx root/root 0 2019-07-27 22:40 usr/lib/libpango-1.0.so ->
libpango-1.0.so.0
lrwxrwxrwx root/root 0 2019-07-27 22:40 usr/lib/libpango-1.0.so.0 ->
libpango-1.0.so.0.4400.0
-rwxr-xr-x root/root313016 2019-07-27 22:40
usr/lib/libpa
Werner LEMBERG wrote
> Can you please tell me the librarie's .so numbers of 1.43.0 and 1.44.1
> (or 1.44.2)?
>
>
> Werner
Yes sure, but I don't know how to find that...
--
Sent from: http://lilypond.1069038.n5.nabble.com/Bugs-f58488.html
___
b
> For info, I'm using Archlinux and after making a maintenance update
> via pacman, I had a similar problem. LilyPond became almost
> unusable with pango 1.44.1-1 and I was forced to downgrade to
> 1.43.0.-2.
Can you please tell me the librarie's .so numbers of 1.43.0 and 1.44.1
(or 1.44.2)?
1 - 100 of 1540 matches
Mail list logo
