Le mardi 30 mai 2023 à 22:40 +0200, Jean Abou Samra a écrit :
> Le dimanche 28 mai 2023 à 14:37 +0200, Jean Abou Samra a écrit :
> >
> > One thing I will try when I can is building in a Kubuntu VM. So far, I used
> > a VM with the default Ubuntu variant, with GNOME. That would normally not
> > m
Le dimanche 28 mai 2023 à 14:37 +0200, Jean Abou Samra a écrit :
>
> One thing I will try when I can is building in a Kubuntu VM. So far, I used a
> VM with the default Ubuntu variant, with GNOME. That would normally not
> matter, but since the desktop environments are
> different, maybe Kubuntu
> Le 28 mai 2023 à 05:29, Colin Campbell a écrit :
>
> Just in case it might help, I uninstalled the font, and reran the test file,
> successfully. Logs attached to compare against failed run.
These logs sound like I was wrong to blame Pango. Apparently, the introduction
of emoji configur
On 2023-05-27 20:36, Colin Campbell wrote:
Well, colour me embarrassed! First, I had applied your patches using
git cola, and received a confirmation screen saying the patches were
applied. Being suspicious, I had a look at the actual files with Kate,
and found no patches had actually been
On 2023-05-27 16:45, Jean Abou Samra wrote:
Le dimanche 28 mai 2023 à 00:38 +0200, Jean Abou Samra a écrit :
Le samedi 27 mai 2023 à 16:31 -0600, Colin Campbell a écrit :
I generally keep my system current, and libpango is at 1.0-0 already.
The "1.0" version number denotes an ABI compatibil
Le dimanche 28 mai 2023 à 00:38 +0200, Jean Abou Samra a écrit :
> Le samedi 27 mai 2023 à 16:31 -0600, Colin Campbell a écrit :
> > I generally keep my system current, and libpango is at 1.0-0 already.
> The "1.0" version number denotes an ABI compatibility promise as far as I
> understand; curre
Le samedi 27 mai 2023 à 16:31 -0600, Colin Campbell a écrit :
> I generally keep my system current, and libpango is at 1.0-0 already.
The "1.0" version number denotes an ABI compatibility promise as far as I
understand; current versions of Pango are actually around 1.50. (1.0.0 is from
around
On 2023-05-27 16:10, Jean Abou Samra wrote:
Le dimanche 28 mai 2023 à 00:05 +0200, Jean Abou Samra a écrit :
If Pango fails to correctly substitute values in the FcConfig, it
could potentially mean that it's passed with some fields
uninitialized to Fontconfig. That could explain why the err
Le dimanche 28 mai 2023 à 00:05 +0200, Jean Abou Samra a écrit :
> If Pango fails to correctly substitute values in the FcConfig, it could
> potentially mean that it's passed with some fields uninitialized to
> Fontconfig. That could explain why the error is not
> reproducible; the value of "colo
Le samedi 27 mai 2023 à 07:50 +0200, Jean Abou Samra a écrit :
> > With lilypond 2.25.6 and your second patch applied, here are 2 .PDFs:
> > first is without the offending font installed, the second is the temporary
> > file produced when the font is present.
>
>
> Thanks, but I am more inte
>
> With lilypond 2.25.6 and your second patch applied, here are 2 .PDFs: first
> is without the offending font installed, the second is the temporary file
> produced when the font is present.
>
Thanks, but I am more interested in the log than the PDF for this one.
On 2023-05-26 02:24, Jean Abou Samra wrote:
Good that you can reproduce again. Now, can you try the patch with
FcPatternPrint and send the log? (No need for FC_DEBUG or --verbose or
--ps this time.)
With lilypond 2.25.6 and your second patch applied, here are 2 .PDFs:
first is without t
Le jeudi 25 mai 2023 à 19:06 -0600, Colin Campbell a écrit :
> I believe we now have a Bingo!
>
> I d/l and built lilypond 2.25.5 from the website, and ran it against the
> test file; it ran successfully.
>
> I re-installed the fonts-noto-color-emoji package, and ran lilypond
> 2.25.5 again, wh
Le mercredi 24 mai 2023 à 20:31 -0600, Colin Campbell a écrit :
> Applied this on top of your previous patch; let me know if you want it
> done differently.
>
> Again, no problems applying, compiling lilypond, nor compiling the test
> file.
>
> Resulting .PDF attached
Sorry for not being clea
On 2023-05-23 14:38, Jean Abou Samra wrote:
Le mardi 23 mai 2023 à 22:08 +0200, Jean Abou Samra a écrit :
So Pango is apparently requesting a font with colored glyphs from Fontconfig...
Speaking of which, I would also be interested in the output with
```
diff --git a/lily/all-font-metrics.
On 2023-05-23 13:28, Jean Abou Samra wrote:
Colin: it's really hard to debug this remotely (we might have to resort to VNC
or such, I'm afraid...) but there is one simple thing I would be interested in:
if you apply this patch, recompile LilyPond and redo the test, what happens?
```
diff -
Le mercredi 24 mai 2023 à 09:08 +, Werner LEMBERG a écrit :
> > So Pango is apparently requesting a font with colored glyphs from
> > Fontconfig...
>
> A bug?
Probably.
So far, I've been unable to understand where this happens; "git grep FC_COLOR"
yields no results in the Pango source code
> So Pango is apparently requesting a font with colored glyphs from
> Fontconfig...
A bug?
Werner
Le mardi 23 mai 2023 à 22:08 +0200, Jean Abou Samra a écrit :
> So Pango is apparently requesting a font with colored glyphs from
> Fontconfig...
Speaking of which, I would also be interested in the output with
```
diff --git a/lily/all-font-metrics.cc b/lily/all-font-metrics.cc
index dd8cfaa
Le mardi 23 mai 2023 à 21:15 +0200, Jean Abou Samra a écrit :
> Le lundi 22 mai 2023 à 08:07 +, Werner LEMBERG a écrit :
>
> > Regarding (2) I'm not sure where exactly the problem lies (i.e., whether it
> > is a LilyPond or a Pango issue).
>
> I'm rather sure it's a Pango or Fontconfig issu
Le mardi 23 mai 2023 à 21:15 +0200, Jean Abou Samra a écrit :
> Le lundi 22 mai 2023 à 08:07 +, Werner LEMBERG a écrit :
>
> > Regarding (2) I'm not sure where exactly the problem lies (i.e., whether it
> > is a LilyPond or a Pango issue).
>
> I'm rather sure it's a Pango or Fontconfig issu
Le lundi 22 mai 2023 à 08:07 +, Werner LEMBERG a écrit :
> Regarding (2) I'm not sure where exactly the problem lies (i.e., whether it
> is a LilyPond or a Pango issue).
I'm rather sure it's a Pango or Fontconfig issue.
Based on the fact that we use Pango's FreeType backend, which is not th
> Following your suggestion, Werner, I tried the test file with the
> cairo back end, and it worked as expected.
Great, please send me the created PDF for further analysis – just to
be sure :-)
> I then deleted the Noto Color Emoji font (synaptic also deleted
> texlive fonts extra links), and re
On 2023-05-22 02:07, Werner LEMBERG wrote:
(1) You have the font 'Noto Color Emoji' installed on your system (the
new one, with scalable glyphs using the 'COLR' v1 format). Say
`fc-list | less` to find out where it is located. This font
format is not supported by GhostScript –
Colin,
>> All this comes about as I'm thinking of getting back to
>> some documentation work, and wanted to compile docs locally. I'll
>> still keep that goal in mind.
>>
>> If you can still reproduce the problem after this cleaning, could
>> you run
>>
>> ```
>> FC_DEBUG=2025 build/out/bin/lily
(Adding back the bug list)
Le samedi 20 mai 2023 à 17:51 -0600, Colin Campbell a écrit :
>
> I redid git bisect today, doing everything on the command line (I used
> Frescobaldi last night). Each time, I ran "
>
> ```
> colin@Calvin:/Work/lilypond/lilypond$ cd build
> colin@Calvin:/Work/
Le vendredi 19 mai 2023 à 23:00 -0600, Colin Campbell a écrit :
> The result of git bisect:
>
> 1db87a2537d6d5ef6631cfbda63954c0a6ee095 is the first bad commit
> commit d1db87a2537d6d5ef6631cfbda63954c0a6ee095
> Author: Jonas Hahnfeld
> Date: Mon Apr 3 22:57:26 2023 +0200
>
> Doc: Avoid fu
The result of git bisect:
1db87a2537d6d5ef6631cfbda63954c0a6ee095 is the first bad commit
commit d1db87a2537d6d5ef6631cfbda63954c0a6ee095
Author: Jonas Hahnfeld
Date: Mon Apr 3 22:57:26 2023 +0200
Doc: Avoid full stop in node names
This propagates the changes from commit c245707e4f to
On 2023-05-19 15:43, Jean Abou Samra wrote:
Le vendredi 19 mai 2023 à 21:00 +0200, Jean Abou Samra a écrit :
Can you try to find which commit introduced the problem for you, using 'git
bisect'?
Alternatively: what's your Ubuntu version? I just installed a fresh Ubuntu
23.04 VM and compiled
Le vendredi 19 mai 2023 à 21:00 +0200, Jean Abou Samra a écrit :
> Can you try to find which commit introduced the problem for you, using 'git
> bisect'?
Alternatively: what's your Ubuntu version? I just installed a fresh Ubuntu
23.04 VM and compiled LilyPond in it but I cannot reproduce the pro
Le vendredi 19 mai 2023 à 12:26 -0600, Colin Campbell a écrit :
>
> On 2023-05-19 11:03, Jean Abou Samra wrote:
> > \version "2.25.5"
> >
> > #(define-markup-command (db layout props arg) (markup?)
> > (let ((stil (interpret-markup layout props arg)))
> > (pretty-print (ly:stencil-expr
On 2023-05-19 11:03, Jean Abou Samra wrote:
\version "2.25.5"
#(define-markup-command (db layout props arg) (markup?)
(let ((stil (interpret-markup layout props arg)))
(pretty-print (ly:stencil-expr stil))
stil))
\markup \db abc
Terminal output:
###
colin@Calvin:/W
Le vendredi 19 mai 2023 à 09:43 -0600, Colin Campbell a écrit :
> > Of all the errors you posted, which one is it now?
> ```
> colin@Calvin:/Work$ lilypond Non-Musical.ly
> GNU LilyPond 2.25.5 (running Guile 2.2)
> Processing `Non-Musical.ly'
> Parsing...
> Interpreting music...
On 2023-05-18 23:30, Jean Abou Samra wrote
Thanks, Werner, for the suggestion. I just tried it, and lilypond still errors
as before.
Of all the errors you posted, which one is it now?
colin@Calvin:/Work$ lilypond Non-Musical.ly
GNU LilyPond 2.25.5 (running Guile 2.2)
Processing `Non-Musical
> Thanks, Werner, for the suggestion. I just tried it, and lilypond still
> errors as before.
Of all the errors you posted, which one is it now?
On 2023-05-18 22:09, Werner LEMBERG wrote:
ran make successfully, got carried away and may have shot myself in
the foot by running sudo make install.
You should actually do
```
make bytecode
sudo make install-bytecode
```
Without installing the Guile bytecode, LilyPond is slooow.
Thanks,
> ran make successfully, got carried away and may have shot myself in
> the foot by running sudo make install.
You should actually do
```
make bytecode
sudo make install-bytecode
```
Without installing the Guile bytecode, LilyPond is slooow.
Werner
On 2023-05-18 21:07, Colin Campbell wrote:
On 2023-05-18 01:55, Jean Abou Samra wrote:
I'm going nuclear tomorrow: delete my clone, and start over.
No need to be *that* nuclear, you can just remove the build directory
and start a fresh build.
Deleted /build,
mkdir build,
cd build
On 2023-05-18 01:55, Jean Abou Samra wrote:
I'm going nuclear tomorrow: delete my clone, and start over.
No need to be *that* nuclear, you can just remove the build directory and start
a fresh build.
Deleted /build,
mkdir build,
cd build
ran make successfully, got carried away and may
Wonderful, thank you!
\--
Gwyn Ciesla
she/her/hers
\
in your fear, seek only peace
in your fear, seek only love
\-d. bowie
Sent from Proton Mail mobile
\ Original Message
On May 18, 2023, 12:53 PM, Jean Abou
Le jeudi 18 mai 2023 à 11:27 +0200, Jean Abou Samra a écrit :
> Gwyn, is it convenient for you to test patches? I think I see what this is
> caused by, but I cannot reproduce the bug in a local build (knowing what
> exact compiler flags are used in Fedora's builds
> might help).
> I'd like to kno
Gwyn, is it convenient for you to test patches? I think I see what this is
caused by, but I cannot reproduce the bug in a local build (knowing what exact
compiler flags are used in Fedora's builds might help).
I'd like to know if this fixes it:
```
diff --git a/lily/all-font-metrics-scheme.cc b
> I'm going nuclear tomorrow: delete my clone, and start over.
No need to be *that* nuclear, you can just remove the build directory and start
a fresh build.
> Le 18 mai 2023 à 05:49, Colin Campbell a écrit :
>
> Attached console output. I'll do a git pull and recompile a bit later, and
> report what happens. Note that the same test file when compiled using
> Frescobaldi as a front end, produces the following output:
>
>
> Starting lilypond 2.
On 2023-05-17 18:25, Jean Abou Samra wrote:
Could you please run with `lilypond --verbose` and send the output?
Thanks,
Jean
Now lilypond blows up in make:
colin@Calvin:/Work/lilypond/lilypond/build$ make -j3 SILENT=1
PythonUI_Init()
PythonUI_Init()
PythonUI_Init()
co
Attached console output. I'll do a git pull and recompile a bit later,
and report what happens. Note that the same test file when compiled
using Frescobaldi as a front end, produces the following output:
Starting lilypond 2.25.5 [Non-Musical.ly]...
programming error: unknown context mod tag
Le mercredi 17 mai 2023 à 17:48 -0600, Colin Campbell a écrit :
> Happens to me on Ubuntu as well:
I don't think that's the same bug. Regarding this:
> Fontconfig error: No writable cache directories
This error popped up at some point during the current cycle before being fixed
shortly therea
Happens to me on Ubuntu as well:
&&
colin@Calvin:/Work$ lilypond Non-Musical.ly
GNU LilyPond 2.25.5 (running Guile 2.2)
Fontconfig error: No writable cache directories
Processing `Non-Musical.ly'
Parsing...
Interpreting music...
Preprocessing graphical objects...
Find
Le mercredi 17 mai 2023 à 20:02 +, Gwyn Ciesla via bug-lilypond a écrit :
> Attaching reproducer.
>
> From Fedora bug:
>
> When I attempt to build a score using a PianoStaff or GrandStaff (which
> contains more than one sub-staff), lilypond crashes.
>
> Reproducible: Always
>
> Steps to Re
Attaching reproducer.
>From Fedora bug:
When I attempt to build a score using a PianoStaff or GrandStaff (which
contains more than one sub-staff), lilypond crashes.
Reproducible: Always
Steps to Reproduce:
1. Attempt to build a minimal reproducer (which I will attach) with
lilypond-2.25.4
Act
On 17/03/2023 16:26, David Kastrup wrote:
That is not a minimal example. Try
\new Staff \with { \consists "Custos_engraver" } { 1 }
Of course, I should have thought of that.
Best, Simon
Hi Jean,
On 17/03/2023 16:38, Jean Abou Samra wrote:
Thanks, but you already reported that bug about a year ago.
Thanks for digging that up/remembering. I did search the issue database
for ‘custos crash’ (or ‘crash custos’ maybe), but despite the label
“Crash” issue 6327 didn’t show up
th {
> \consists Custos_engraver
> } { 1 \break r1 1 }
>
>
> Not sure it’s ever going to trigger in real-life situations, but it’s a
> crash without error handling. “Output code 11.”
Thanks, but you already reported that bug about a year ago. See
[https://l
reak r1 1 }
>
>
> Not sure it’s ever going to trigger in real-life situations, but it’s
> a crash without error handling. “Output code 11.”
That is not a minimal example. Try
\new Staff \with { \consists "Custos_engraver" } { 1 }
--
David Kastrup
real-life situations, but it’s a
crash without error handling. “Output code 11.”
Best, Simon
Thanks, Jean!
On Fri, Jan 13, 2023 at 5:38 PM Jean Abou Samra wrote:
> Le 13/01/2023 à 23:36, Trevor Bača a écrit :
> > Hi,
> >
> > Skip-filled tuplets halt execution in 2.25.0.
> >
> > %%% BEGIN %%%
> >
> > \version "2.25.0"
> >
> > \new Staff { \times 2/3 { s2 s2 s2 } }
> >
> > %%% END %%%
> >
Le 13/01/2023 à 23:36, Trevor Bača a écrit :
Hi,
Skip-filled tuplets halt execution in 2.25.0.
%%% BEGIN %%%
\version "2.25.0"
\new Staff { \times 2/3 { s2 s2 s2 } }
%%% END %%%
GNU LilyPond 2.25.0 (running Guile 2.2)
Processing `test.ly'
Parsing...
Interpreting music...
warning: omitting t
Hi,
Skip-filled tuplets halt execution in 2.25.0.
%%% BEGIN %%%
\version "2.25.0"
\new Staff { \times 2/3 { s2 s2 s2 } }
%%% END %%%
GNU LilyPond 2.25.0 (running Guile 2.2)
Processing `test.ly'
Parsing...
Interpreting music...
warning: omitting tuplet bracket with neither left nor right bound
lt of said snippet in the Snippets-manual. No
clue how we avoid the crash, alas the image is wrong.
Compare https://lsr.di.unimi.it/LSR/Item?id=602 (running 2.22.2) with
http://lilypond.org/doc/v2.24/Documentation/snippets/paper-and-layout#paper-and-layout-clip-systems
Cheers,
Harm
%% DO NOT ED
Le 14/04/2022 à 09:38, Simon Albrecht a écrit :
Hello list,
this causes a crash while Interpreting music (Exiting with return code
11.):
% also happens with 2.20.0
\version "2.23.6"
%%{
% also happens with VaticanaVoice,MedicaeaVoice,Petrucci
Hello list,
this causes a crash while Interpreting music (Exiting with return code 11.):
% also happens with 2.20.0
\version "2.23.6"
%%{
% also happens with VaticanaVoice,MedicaeaVoice,PetrucciVoice
\new MensuralVoice {
% this prevents the crash
Il giorno gio, nov 19 2020 at 16:58:31 -0500, Trevor Bača
ha scritto:
(minimum-distance . 12) % errant comment causes crash
You should use `;` to add a comment in a Scheme block, so it doesn't
look like a bug to me.
v2.20 did not produce an error, but the documentation al
Hi,
This causes Lily to crash:
### BEGIN ###
\version "2.21.80"
\new Score
<<
\new GlobalContext { s1 }
\new Staff { c'1 }
>>
\layout {
\context {
\name GlobalContext
\type Engraver_group
\consists Axis_group
Well, it just so happened that the first file I tried on Arch makes
lilypond dump core, sheer bad luck. As per the suggestion here (which
I didn't even think of, too busy rushing into worrying about this) my
other files compile fine. So in fact there is no real issue. I'll
binary chop the file to s
Jonas' idea is good. If you (can) share your score with Jonas, don't
hesitate to share with me, and I'd be happy to try and compile it and tell
you if I run in the same problem. With three distros instead of one, we
might be able to narrow down a little the source of the issue.
Claire
On Wed, Jun
Am Mittwoch, den 24.06.2020, 19:17 +1000 schrieb Andrew Bernard:
> Just getting back into lilypond but nowadays on Arch Linux. Sorry to
> say both recent versions dump core:
> ...
> elapsed time: 0.61 seconds
> Element count 12833 (spanners 1146)
> Preprocessing graphical objects...
> Grob count 19
I'm on Manjaro KDE 5.4.44-1, whis is Arch-based. I use lilypond 2.20.0-3
(build date 2020/03/16, packager Antonio Rojas : aro...@archlinux.org) and
it works fine for me. If I'm not mistaken, Manjaro uses Arch repositories,
with some additional code review before incorporating the last changes, so
t
Just getting back into lilypond but nowadays on Arch Linux. Sorry to
say both recent versions dump core:
...
elapsed time: 0.61 seconds
Element count 12833 (spanners 1146)
Preprocessing graphical objects...
Grob count 19105Segmentation fault (core dumped)
Version from Arch AUR repository and Arch
to go through it, let alone set it all up for compiling.
I am unable to extract an MWE from the score that proves it. However,
being
clued in to a possible issue around tuplets, I found the issue by trial
and
error rather than gdb. Here it is: calling tupletFullLengthNote = ##t
causes the crash. Th
Here it is:
Using tupletFullLengthToNote = ##t crashes it.
\version "2.19.82"
\paper { indent = 0 ragged-right = ##t }
\layout {
\set tupletFullLength = ##t
\set tupletFullLengthNote = ##t
}
{ \tuplet 1/1 { b'1 } \break 4 }
That qualifies as a bug worth registering, does it not?
Andrew
_
iling.
I am unable to extract an MWE from the score that proves it. However, being
clued in to a possible issue around tuplets, I found the issue by trial and
error rather than gdb. Here it is: calling tupletFullLengthNote = ##t
causes the crash. This is definite. But it only occurs in my reasonably
On 2019-03-23 3:39 pm, Thomas Morley wrote:
Am Sa., 23. März 2019 um 21:41 Uhr schrieb Aaron Hill
:
\override TupletBracket.X-positions = #(lambda (grob)
(let ((xpos (ly:tuplet-bracket::calc-x-positions grob)))
(if (> (car xpos) (cdr xpos))
(format #t "\nwarning: Inv
Am Sa., 23. März 2019 um 21:41 Uhr schrieb Aaron Hill
:
>
> On 2019-03-23 6:46 am, Andrew Bernard wrote:
> > What calls calc_x_offset for Tuplet Number?
>
> This likely may be coming from Scheme. If you look at the Internals
> reference, you will see that the X-offset property for TupletNumber is
On 2019-03-23 6:46 am, Andrew Bernard wrote:
What calls calc_x_offset for Tuplet Number?
This likely may be coming from Scheme. If you look at the Internals
reference, you will see that the X-offset property for TupletNumber is
by default set to ly:tuplet-number::calc-x-offset.
That means
I'm not sure if this is the right list to discuss this on. Recently in my
200 page string quartet the tuplet brackets, which always used to be fine,
have started becomg too short, randomly, with no apparent obvious pattern,
and only a little bit, but enough to make the score very unprofessional
loo
I'm not sure if this is the right list to discuss this on. Recently in my
200 page string quartet the tuplet brackets, which always used to be fine,
have started becoming too short, randomly, with no apparent obvious
pattern, and only a little bit, but enough to make the score very
unprofessional l
Simon Albrecht writes:
> On 18.07.2018 10:59, David Kastrup wrote:
>> basically one of the calls to \offset gets junked because of LilyPond
>> not being able to disentangle them (one could extend the code to handle
>> this case but it would still balk at more complex combinations).
>
> Great! Thi
On 18.07.2018 10:59, David Kastrup wrote:
basically one of the calls to \offset gets junked because of LilyPond
not being able to disentangle them (one could extend the code to handle
this case but it would still balk at more complex combinations).
Great! This is exactly what would be needed in
Simon Albrecht writes:
> Hello everybody,
>
> this combination of a custom music function that combines the music
> simultaneously with itself and a \once\offset command causes LilyPond
> to crash (exit with return code 11):
>
>
> \version "2.19.
; is a bit of an exaggeration but at least it doesn't crash
anymore. It just drops transforms (and warns about that) until the
rest can be handled safely. Also contains commit: Add ly:grob-
warning function
for this one.
Thanks for working on
red by the notes so that the two \offsets stack
>>> their effects. But then that doesn't explain why the same behavior
>>> isn't seen when omitting \once in the first example.
>>
>> Try with \temporary (though avoiding the crash with the same kind of
>> manual
make sense providing simultaneous music results
in a single stem shared by the notes so that the two \offsets stack
their effects. But then that doesn't explain why the same behavior
isn't seen when omitting \once in the first example.
Try with \temporary (though avoiding the crash wit
Aaron Hill writes:
> On 2018-07-15 20:09, Aaron Hill wrote:
>> Seems the custom music function is not needed to reproduce a crash.
>>
>>
>> \version "2.19.82"
>> music = { \once \offset length 5 Stem 4 4 }
>> << \music \music >
t;> persists), then you can at least get it to compile.
>
> That's plausible: \once incurs action both at the current timestep and
> in preparation for the next timestep. If the context is in bad shape
> for the latter (and the context is not slated for continuation here),
> t
Aaron Hill writes:
> On 2018-07-15 20:09, Aaron Hill wrote:
>> Seems the custom music function is not needed to reproduce a crash.
>>
>>
>> \version "2.19.82"
>> music = { \once \offset length 5 Stem 4 4 }
>> << \music \music >
On 2018-07-15 20:09, Aaron Hill wrote:
Seems the custom music function is not needed to reproduce a crash.
\version "2.19.82"
music = { \once \offset length 5 Stem 4 4 }
<< \music \music >>
This also results in:
GNU LilyPond 2.19.82
Process
Hello,
On Sun, 15 Jul 2018 20:09:52 -0700, Aaron Hill wrote:
> On 2018-07-15 18:21, Simon Albrecht wrote:
> > Hello everybody,
> >
> > this combination of a custom music function that combines the music
> > simultaneously with itself and a \once\offset command c
On 2018-07-15 18:21, Simon Albrecht wrote:
Hello everybody,
this combination of a custom music function that combines the music
simultaneously with itself and a \once\offset command causes LilyPond
to crash (exit with return code 11):
\version "2.19.82"
test =
#(de
Hello everybody,
this combination of a custom music function that combines the music
simultaneously with itself and a \once\offset command causes LilyPond to
crash (exit with return code 11):
\version "2.19.82"
test =
#(define-music-function (parser location mus)
On 04/19/2018 09:10 AM, James Lowe wrote:
> Hello Gwyn,
>
> On Thu, 19 Apr 2018 08:51:41 -0500, Gwyn Ciesla wrote:
>
>> Hi! Gwyn Ciesla, Fedora lilypond maintainer.
>>
>> First, we have a crash I'm having trouble debugging:
>> https://bugzilla.redhat
Hello Gwyn,
On Thu, 19 Apr 2018 08:51:41 -0500, Gwyn Ciesla wrote:
> Hi! Gwyn Ciesla, Fedora lilypond maintainer.
>
> First, we have a crash I'm having trouble debugging:
> https://bugzilla.redhat.com/show_bug.cgi?id=1568274
I am not a developer so can only add that compiling
Hi! Gwyn Ciesla, Fedora lilypond maintainer.
First, we have a crash I'm having trouble debugging:
https://bugzilla.redhat.com/show_bug.cgi?id=1568274
Second, I can't build lilypond on Fedora 28 or newer. It fails with a
Python warning:
ERROR: Please install required programs: Python
Hello Frederic,
On Sat, 14 Apr 2018 09:42:20 +, Frédéric Gohier
wrote:
> hello,
>
> I face a crash when run the command line :
> /usr/local/bin/musicxml2ly --nd --nrp --npl --no-beaming -m
> MusicXMLV2_from_sibelius7.xml
>
> the traceback is :
> Tracebac
Please see http://lilypond.org/doc/v2.19/Documentation/contributor/patches
--
Phil Holmes
"Frédéric Gohier" wrote in message
news:he1pr1001mb140284687c61080bd2d06ee9ba...@he1pr1001mb1402.eurprd10.prod.outlook.com...
hello,
I face a crash when run the command line :
/usr
hello,
I face a crash when run the command line :
/usr/local/bin/musicxml2ly --nd --nrp --npl --no-beaming -m
MusicXMLV2_from_sibelius7.xml
the traceback is :
Traceback (most recent call last):
File "/usr/local/bin/musicxml2ly", line 3277, in
main()
File "/usr/local/
Please always reply to all:
2017-05-11 13:17 GMT+02:00 Silvio Ardito :
> Installed Python 2.7.13 all OK.
>
> 2017-05-11 0:43 GMT+02:00 Thomas Morley :
>
>>
>> 2017-05-10 9:36 GMT+02:00 Silvio Ardito :
>>
>>> The Lilypond version 2.14.-1 goes to the
2017-05-10 9:36 GMT+02:00 Silvio Ardito :
> The Lilypond version 2.14.-1 goes to the end.
> All subsequent versions crash.
>
> amelia
>
> On my machine (Ubuntu 16.04 64-bit) they all work, p.e. with 2.18.2:
$ musicxml2ly xml.xml musicxml2ly: Reading MusicXML from xml.x
The Lilypond version 2.14.-1 goes to the end.
All subsequent versions crash.
amelia
H:\LilyPondOLD\usr\bin>rem cd LilyPond\usr\bin
H:\LilyPondOLD\usr\bin>musicxml2ly.py -v Q:\MUSICA\SPARTITI\SCANNER\xml.xml -o
Q:\MUSICA\SPARTITI\SCANNER\xml.ly
Reading MusicXML from Q:\MUSICA\SPARTITI\S
Thanks for catching the issues with my example. I've tried to strip it down
even farther to the absolute simplest example that causes this crash. Try
this:
\version "2.19.49"
<<
% To get an interesting alternative bug, comment out the next line. Lilypond
finishes, but on
let 8/5{b8} \tuplet 12/7{c4} \tuplet 23/19{r8} \tuplet 47/37{e8}
\tuplet 43/29{f4}
\tuplet 27/23 {e2} \tuplet 15/11{r4.}
\tuplet 29/17{d8[ e g]} \tuplet 53/47{c,4.}
\tuplet 61/37{r4} \tuplet 17/14 {e8} \tuplet 23/18{f8} \tuplet 17/19{d8}
\tuplet 11/13{r8} \tuplet 3/5{f8}
}
}
--
View this
1 - 100 of 541 matches
Mail list logo
