> Here's the short answer:
Thanks a lot for the detailed explanation!
> chain_callback () returns SCM_UNDEFINED if the property data being
> chained isn't a procedure or closure. [...]
For me, this seems to be the right action.
> For TupletNumber, [...] since its positioning relies on the
> co
On 2 November 2010 07:41, Werner LEMBERG wrote:
> Have you meanwhile found some time to ponder? I'm quite curious...
Yes. :)
Here's the short answer:
chain_callback () returns SCM_UNDEFINED if the property data being
chained isn't a procedure or closure.
(grob-closure.cc)
78 else
79
>> OK. To debug this is beyond my capabilities, sorry. Hopefully, I
>> find time to dive into lilypond's Scheme details, but currently I
>> have no time to do that; right now I'm pretending to be Joe User.
>
> No problem. I've done a bit more investigating, and I think I know
> what's going on
>> Or is there a deeper problem?
>
> I think so. Perhaps there's a callback returning SCM_UNDEFINED by
> mistake or forgetting to change an undefined default to something
> sane.
OK. To debug this is beyond my capabilities, sorry. Hopefully, I
find time to dive into lilypond's Scheme details,
On 30 October 2010 15:48, Werner LEMBERG wrote:
> OK. To debug this is beyond my capabilities, sorry. Hopefully, I
> find time to dive into lilypond's Scheme details, but currently I have
> no time to do that; right now I'm pretending to be Joe User.
No problem. I've done a bit more investiag
On 30 October 2010 08:39, Werner LEMBERG wrote:
> Would it be sufficient to handle SCM_UNDEFINED in
> type_check_assignment?
I don't think so. Unlike SCM_EOL or SCM_BOOL_F it doesn't have an
analogue in Scheme code.
> Or is there a deeper problem?
I think so. Perhaps there's a callback retur
>> in file lily-guile.cc; for the above lilypond call it gets passed a
>> value of 0x204 for `val'.[1] This is obviously a special constant,
>> however, I haven't found out what guile symbol this corresponds to
>> due to the extremely cryptic definitions in libguile's `tags.h'
>> file.
>
> It's SC
On 29 October 2010 09:18, Werner LEMBERG wrote:
> in file lily-guile.cc; for the above lilypond call it gets passed a
> value of 0x204 for `val'.[1] This is obviously a special constant,
> however, I haven't found out what guile symbol this corresponds to due
> to the extremely cryptic definition
> lilypond -dcheck-internal-types input/regression/slur-tuplet.ly
>
> It appears that there is some internal error in LilyPond that is
> causing -dcheck-internal-types not to work properly.
Yep.
> I'm afraid this is over my head, although I'll look around a bit
> more at it.
I did a bit of deb
On 10/28/10 4:52 PM, "Carl Sorensen" wrote:
> On 10/28/10 4:44 PM, "Carl Sorensen" wrote:
>> On 10/28/10 4:39 PM, "Werner LEMBERG" wrote:
I don't think it's a Heisenburg. The make test fails for me, too.
>>>
>>> Me too... Very, very strange. Anybody out here who knows enough
>>> about t
On 10/28/10 4:44 PM, "Carl Sorensen" wrote:
>
>
>
>
> On 10/28/10 4:39 PM, "Werner LEMBERG" wrote:
>
>>
>>
>>> I don't think it's a Heisenburg. The make test fails for me, too.
>>
>> Me too... Very, very strange. Anybody out here who knows enough
>> about the Scheme internals to de
On 10/28/10 4:39 PM, "Werner LEMBERG" wrote:
>
>
>> I don't think it's a Heisenburg. The make test fails for me, too.
>
> Me too... Very, very strange. Anybody out here who knows enough
> about the Scheme internals to debug it?
I'm currently seeing if I can reproduce it by a single com
> I don't think it's a Heisenburg. The make test fails for me, too.
Me too... Very, very strange. Anybody out here who knows enough
about the Scheme internals to debug it?
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://li
>> \sourcefilename "slur-tuplet.ly"
>
> But when I manually compile this regtest, I get: [...]
>
> success: Compilation successfully completed
Honestly, I've suspected that. The question is whether Graham has
observed a Heisenbug, or whether the change really triggers the crash
in the build...
On 10/28/10 4:00 PM, "Werner LEMBERG" wrote:
>>> \sourcefilename "slur-tuplet.ly"
>>
>> But when I manually compile this regtest, I get: [...]
>>
>> success: Compilation successfully completed
>
> Honestly, I've suspected that. The question is whether Graham has
> observed a Heisenbug, or whe
Hello
On 28/10/2010 23:00, Werner LEMBERG wrote:
>>> \sourcefilename "slur-tuplet.ly"
>>
>> But when I manually compile this regtest, I get: [...]
>>
>> success: Compilation successfully completed
>
> Honestly, I've suspected that. The question is whether Graham has
> observed a Heisenbug, or whe
On 10/28/10 7:54 AM, "Carl Sorensen" wrote:
> On 10/27/10 11:32 PM, "Werner LEMBERG" wrote:
>>> However, I do have the original doc-build error, which would
>>> presumably be the same problem as the regtest failure: [...]
>>>
>>> c7/lily-4bb72c87.ly
>>
>> The compilation of this file fails?
On 10/27/10 11:32 PM, "Werner LEMBERG" wrote:
>> However, I do have the original doc-build error, which would
>> presumably be the same problem as the regtest failure: [...]
>>
>> c7/lily-4bb72c87.ly
>
> The compilation of this file fails? Which snippet is that?
By looking at out/lybook-db
> The recent "improve positioning of TupletNumber and Slur" patch
> breaks the doc and regtest compile. I don't understand to
> understand how or why, but it does, so I've reverted that commit.
Umpf. What a pity. If you are correct, my tiny, innocent change has
unveiled a more serious bug whic
19 matches
Mail list logo
