On Fri, 2025-08-29 at 06:45 +, Werner LEMBERG wrote:
> > The score below has the Bar_number_engraver moved to Staff level:
>
> > depending on the details of the music this causes an error:
>
> >
>
> > programming error: cyclic dependency:
>
> >
[moving to bug-lilyp...@gnu.org]
On 2025-08-28 10:52, Richard Shann wrote:
The score below has the Bar_number_engraver moved to Staff level:
depending on the details of the music this causes an error:
programming error: cyclic dependency: calculation-in-progress encountered for
cal layout).
>> Of course, the error message is cryptic, and my interpretation
>> might just be an educated guess – but I believe that a error
>> message is OK for this situation.
>
> I'm hoping so, but although there is an ly:expect-warning there
> doesn't
> The score below has the Bar_number_engraver moved to Staff level:
> depending on the details of the music this causes an error:
>
> programming error: cyclic dependency:
> calculation-in-progress encountered for
> VerticalAxisGroup.adjacent-pure-heights
> continuing,
The score below has the Bar_number_engraver moved to Staff level:
depending on the details of the music this causes an error:
programming error: cyclic dependency: calculation-in-progress encountered for
VerticalAxisGroup.adjacent-pure-heights
continuing, cross fingers
In the real-life example
On 2013/03/24 16:39:03, Trevor Daniels wrote:
> Please choose between patchsets 4 and 5.
I prefer 5. The warning does no harm if it is
never triggered, but is there in case some future
change elsewhere assumes a non-empty stencil will
be aligned even if its extent is empty. It is
relevant t
Patchset 5 warns the user when the extent is empty and stencil isn't.
However, i'm not sure if we should warn about such situations at all;
i haven't found any similar warnings in the codebase. Also, detecting
non-empty stencils with empty extents is quite unrelated to alignment
code.
Please
On 2013/03/24 12:45:38, dak wrote:
On 2013/03/24 12:37:14, Trevor Daniels wrote:
> I was a little concerned that problems might
> result when a non-empty stencil was given an
> empty extent, but as this passes all tests it
> looks like this fear was unfounded.
I don't think your fear is unfoun
On 2013/03/24 12:45:38, dak wrote:
On 2013/03/24 12:37:14, Trevor Daniels wrote:
> I was a little concerned that problems might
> result when a non-empty stencil was given an
> empty extent, but as this passes all tests it
> looks like this fear was unfounded.
I don't think your fear is unfoun
On 2013/03/24 12:37:14, Trevor Daniels wrote:
I was a little concerned that problems might
result when a non-empty stencil was given an
empty extent, but as this passes all tests it
looks like this fear was unfounded.
I don't think your fear is unfounded: there just does not seem to be any
sens
I was a little concerned that problems might
result when a non-empty stencil was given an
empty extent, but as this passes all tests it
looks like this fear was unfounded.
So LGTM apart from a nitpick.
Trevor
https://codereview.appspot.com/7533046/diff/15001/lily/self-alignment-interface.cc
F
On 2013/03/23 16:38:21, t.daniels_treda.co.uk wrote:
A 'programming error' should be issued only when an internal
inconsistency
in LilyPond's code or data structures is detected. Any such message
should
always result in a bug being reported and tracked. If the problem is
so i'll move on", or shout "hey,
> there are empty grobs flying around! Do something about it!".
>
> Example: if we override grob's stencil to #f, the extent will be #f as
> well:
>
> \version "2.17.12"
> { c' e' f' d' }
&
ng with it, so i'll move on", or shout "hey,
there are empty grobs flying around! Do something about it!".
Example: if we override grob's stencil to #f, the extent will be #f as
well:
\version "2.17.12"
{ c' e' f' d' }
\addlyrics { la le \over
t;
> It is telling that (presumably after looking at the code at least
> once) you don't know what the logic of the code is.
No, in this case I actually did not bother to even look. I looked at
the function name and the programming error message, and that was more
or less it. For b
On Thu, Mar 21, 2013 at 9:14 AM, wrote:
> On 2013/03/21 08:04:42, janek wrote:
>
>> So, you think that we shouldn't report any programming error in these
>> alignment funcitons since an empty extent doesn't prevent us from
>> doing our job i.e. aligning)?
>
On 2013/03/21 08:04:42, janek wrote:
So, you think that we shouldn't report any programming error in these
alignment
funcitons since an empty extent doesn't prevent us from doing our job
(i.e.
aligning)?
Well, with an empty extent it would appear our job of aligning _self_ is
al
ment shouldn't have
empty extent"?
If you want to
flag problems, it might make more sense to address them in those
callers that
depend on non-emptiness than here.
So, you think that we shouldn't report any programming error in these
alignment funcitons since an empty extent do
https://codereview.appspot.com/7533046/diff/3001/lily/self-alignment-interface.cc
File lily/self-alignment-interface.cc (right):
https://codereview.appspot.com/7533046/diff/3001/lily/self-alignment-interface.cc#newcode63
lily/self-alignment-interface.cc:63: programming_error ("cannot align on
se
LGTM
https://codereview.appspot.com/7533046/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
that an empty
extent is equivalent to (0 . 0)?
In other words, maybe this fragment of code should never report any
programming errors?
Description:
report a programming error when trying to align on empty parent
To align grobs, we look at their extents (which are basically
grob dimensions in respe
> Can you file a full bugreport?
Done, issue #716.
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
On Sun, Dec 28, 2008 at 3:37 PM, Han-Wen Nienhuys wrote:
>>> Can you file a full bugreport?
>>
>> Before I do this: How can I provide more useful debugging information?
>
> The sequence of commands to reproduce. If this started recently, when
> this problem was introduced.
I see this too, but i
On Sun, Dec 28, 2008 at 3:21 PM, Werner LEMBERG wrote:
>> > programming error: Parsed object should be dead:
>> >static scm_unused_struct* Prob::mark_smob(scm_unused_struct*)
>> > continuing, cross fingers
>> > programming error: Parsed o
> > If compiled with --disable-optimisation, calling lilypond always emits
> >
> > programming error: Parsed object should be dead:
> >static scm_unused_struct* Prob::mark_smob(scm_unused_struct*)
> > continuing, cross fingers
> > programming
On Fri, Dec 26, 2008 at 7:22 AM, Werner LEMBERG wrote:
>
> If compiled with --disable-optimisation, calling lilypond always emits
>
> programming error: Parsed object should be dead:
>static scm_unused_struct* Prob::mark_smob(scm_unused_struct*)
> continuing, cross fing
If compiled with --disable-optimisation, calling lilypond always emits
programming error: Parsed object should be dead:
static scm_unused_struct* Prob::mark_smob(scm_unused_struct*)
continuing, cross fingers
programming error: Parsed object should be dead:
static scm_unused_struct
Hi Reinhold,
There's a problem using tempoHideNote if there's no markup text, since
it returns SCM_BOOL_F to the engraver, resulting in a programming
error:
\set Score.tempoHideNote = ##t
\tempo 4 = 60
returns `Object is not a markup.'
I've attached a patch which gets rid
During a `make all', I see this in the log file (prettified):
Processing `/home/wl/git/lilypond.compiled/ly/generate-documentation.ly'
Parsing...<2kB of output omitted>
Writing "lilypond-internals.texi"...]]
programming error: Parsed object should be dead:
Graham Percival wrote:
What should I call bugs which display a "programming error", but which
appear to produce perfect graphical output? Type-defect, Priority-low?
Yes, sounds good.
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
LilyPond Software Desig
What should I call bugs which display a "programming error", but which
appear to produce perfect graphical output? Type-defect, Priority-low?
- Graham
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailma
> > Parsing...
> > Interpreting music... [3]
> > Preprocessing graphical objects...
> > Calculating line breaks...
> > programming error: Stem has no extent in Slur_score_state
> > continuing, cross fingers
> > programming error: Stem has no extent in Slur_scor
On Wednesday 27 April 2005 15:53, David Bobroff wrote:
> In recent CVS I'm getting this:
>
> GNU LilyPond 2.5.21
> Processing `/home/david/dean/ode/test.ly'
> Parsing...
> Interpreting music... [3]
> Preprocessing graphical objects...
> Calculating line breaks..
In recent CVS I'm getting this:
GNU LilyPond 2.5.21
Processing `/home/david/dean/ode/test.ly'
Parsing...
Interpreting music... [3]
Preprocessing graphical objects...
Calculating line breaks...
programming error: Stem has no extent in Slur_score_state
continuing, cross fingers
program
On Mar 16, 2005, at 4:42 PM, David Bobroff wrote:
Calculating page breaks...programming error: Stencil::moved_to_edge:
adding empty stencil.
Continuing; crossing fingers
I reported this on March 8 while using v 2.5.13 but there was no
response. I continue to see the error reported but the output
s...programming error: Stencil::moved_to_edge:
adding empty stencil.
Continuing; crossing fingers
Layout output to `test.ps'...
I have been getting this same 'programming error' for some days now
(across several CVS update versions). I was concerned until I saw that
I seemed to be
Juergen Reuter <[EMAIL PROTECTED]> wrote:
>
>
> On Mon, 8 Nov 2004, Karl Hammar wrote:
>
> > ...
> >
> > I have found a way to get rid of the errors.
> >
> > Previous run, lots of errors from make web:
> >
> > $ grep -i error log | wc -l
> > 1359
> > $
> >
> > New idea:
> >
> > $
On Mon, 8 Nov 2004, Karl Hammar wrote:
> ...
>
> I have found a way to get rid of the errors.
>
> Previous run, lots of errors from make web:
>
> $ grep -i error log | wc -l
> 1359
> $
>
> New idea:
>
> $ (./autogen.sh --prefix=$HOME; make clean; make all install; .
> buildscript
//
> > $ cat run
> > (./autogen.sh --prefix=$HOME; make clean; make "$@") > log 2>&1
> > $ ./run all install web
> > $ grep 'programming error: Grob `NoteHead'\'' has no interface for
> > property' log | wc
> >
:
>
> $ grep ChangeLog CVS/Entries
> /ChangeLog/1.2805/Fri Nov 5 17:00:22 2004//
> $ cat run
> (./autogen.sh --prefix=$HOME; make clean; make "$@") > log 2>&1
> $ ./run all install web
> $ grep 'programming error: Grob `NoteHead'\'
$ grep ChangeLog CVS/Entries
/ChangeLog/1.2805/Fri Nov 5 17:00:22 2004//
$ cat run
(./autogen.sh --prefix=$HOME; make clean; make "$@") > log 2>&1
$ ./run all install web
$ grep 'programming error: Grob `NoteHead'\'' has no interface for prop
ical objects...
> Calculating line breaks... [2]
> programming error: Grob `Glissando' has no interface for property
> `style'
> Continuing; crossing fingers
> programming error: Grob `Glissando' has no interface for property
> `style'
> Continuing; cro
On 10-Oct-04, at 3:05 AM, Han-Wen Nienhuys wrote:
Try executing with
-e "(ly:set-option 'internal-type-checking #t)"
Ok. These files seem to produce correct output, but they give a
"programming error" when building them. They only print the error when
using that opti
Now processing `lily-1822262335.ly'
Parsing...
Interpreting music... [3]
Preprocessing graphical objects...
Calculating line breaks...
programming error: Grob `DynamicTextSpanner' has no interface for property
`bound-padding'
Continuing; crossing fingers
Paper
Now processing `lily-1943255492.ly'
Parsing...
Interpreting music... programming error: Grob `LigatureBracket' has no interface for
property `ligature-primitive-callback'
Continuing; crossing fingers
warning: Programming error: Ligature_engraver::stop_translation_times
Now processing `lily-807907910.ly'
Parsing...
Interpreting music... programming error: Grob `NoteHead' has no interface for
property `delta-pitch'
Continuing; crossing fingers
programming error: Grob `NoteHead' has no interface for property `delta-pitch'
Con
Now processing `lily-1835636204.ly'
Parsing...
Interpreting music... [1]
Preprocessing graphical objects...
Calculating line breaks... [2]
programming error: Grob `Glissando' has no interface for property `style'
Continuing; crossing fingers
programming error: Grob `Glissando&#x
47 matches
Mail list logo
