Re: [frogs] Stepping into the code for nested properties |
[ Thread Index |
Date Index
| More lilynet.net/frogs Archives
]
- To: "frogs@xxxxxxxxxxx" <frogs@xxxxxxxxxxx>
- Subject: Re: [frogs] Stepping into the code for nested properties
- From: Rodolfo Zitellini <xhero.gm@xxxxxxxxx>
- Date: Wed, 12 May 2010 19:13:35 +0200
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=ityjXcuc6CKVuYSFAa1WxGyaLufCdA9RxaagWBkCyS4=; b=wvYqYSM4JkxkjYwKGgKHoBhho4j9/PikNCLs6TcSIY32Uz7k4bGkUaNBK1wESoOr6E 0QAeb7qjDbSKWLfSTTZHKaYb5cjobU3GFOk9kNvp1bAW26p64wSNXBmyZ1T6wtglV/gw mtKD6eTQ5OTwda3tHpXlePnc1p5XWaD+MjykI=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=mk60zmsqEebBpHmie7IxUKzlcCs2TBVfEcGfU0Bk9841LJZXaLz2QbpectO81mXkoG wmrY5XgZPfSuQ7PWuOKaRapfYOHkxKimTomPTGUKb6B1rDPzO6BD8igg8HvnHluVa4dt QbP0lbyjSGWRDVVgMmRHrbxwJDFliMuIIxCRg=
I did some digging with the debugger (and pretty-print :)
It seems that when overriding nested props are treated exactly like
non-nested ones, as Neil suggested. When you do an \override, in the
CAR of the current property list is placed a new list with the
elements of the same list:
(<many elements>) -> ((<many elements>) <many elements>)
The new value is then prepended, but the old one is maintained in the CAR:
((<the_element> <other elements>) <the_element> <other elements>) ->
(<the_element_new> <the_element> <other elements>) <the_element>
<other elements>)
So we end up with a "backup" copy of the list and the current list in
the CAR, with two copies of the modified prop: old and new values.
Nested properties are treated similary. If you do an override, say in
(bound-details left <an_item>) only the sublist of the nested prop is
duplicated and not the whole prop:
(bound-details (left <my_item> <other_items>)) ->
(bound-details
(left <my_item_new> <my_item> <other_items>)
(left <my_item> <other_items>))
I hope I got this correctly! :)
Now, what seems to trigger the problem is that in the debugger I see a
call to execute_revert_property() before every
execute_override_property(). So the code:
\override TrillSpanner #'(bound-details left Y) = #'99
seems to generate a revert on #'(bound-details left Y) before setting
the property.
If this is the first override in that context
execute_revert_property() just returns. BUT if an override was already
done the CAR of it's properties contains the current used properties.
nested_property_revert_alist() will then find the property you are
overriding and it pops it out of the list. After the override you end
up with something like this:
(bound-details
(left <my_item_new> <other_items>)
(left <my_item> <other_items>))
note that in the first instance of (left) the old value of <my_item>
is missing, since it was popped by the revert.
When you explicitally do a \reverts on this property,
nested_property_revert_alist() seems to care only of the first (left)
that it encounters, and pops (correctly) <my_item_new>, leaving the
nested property without a copy of <my_item>.
This extends easily to the \revert-one-some-prop breaking after an
\override-another: nested_property_revert_alist() always pops out the
list the \reverted item, even if it is the only copy present. It seems
then that other parts of the program just access the first instance of
the nested prop they encounter, thus not finding it's subproperty,
this even if subsequently in the list other copies of the nested
property (with all elements) are present.
Can't the default value just be copied from the "backup" part of the
context's property alist, which is always present?
Hope I was not too boring :)
cheers,
Rodolfo
---
----
Join the Frogs!