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: Fri, 14 May 2010 17:53:52 +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 :content-transfer-encoding; bh=zWcuEG4+1/g15ftVmsQ3TL38fbu3Qk6kvQQSO7w+22k=; b=Zm7spkOjncv+W8A9W9gvp+2t33Ov4t7opV4noIMOxOeEdOVKQ+yqXzKpSb/Cqzoi/T WTg2RT19AtqTlj+auOZv7eMAGrwZYaB/NrZD3N2YB3HYvlNVWHAIF2CRHz4MCskoHu2O NNT/EFBKZXaQ4Xx+cUnxiNTzfRq85c+yySfqk=
- 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:content-transfer-encoding; b=K1mOEcvEqaMcphaJwh2TBO3mAf8Oh1J1fvppkgjqMxUXuoveq/GO6Ys982/RkIe8m3 AsXzK6V6RV/OiB40OqQvp1RKuk15O5iwRkrYMxhGQRlZ5gfaShtMoPCzNXHYCRT+F/Pd +rYuZkeXVQcgCxfc1NN73uvrW15uupw1wXQxM=
>
> Does your algorithm still work if you do something like:
>
> \override MyGrob #'(bound-details left Y) = #10
> \override MyGrob #'(bound-details right X) = #20
> \revert MyGrob #'(bound-details left Y)
yes!
> And will it work with
>
> \override MyGrob #'(bound-details left Y) = #10
> \override MyGrob #'(bound-details right X) = #20
> \revert MyGrob #'bound-details
no! argh! but this seems broken even without my mod :)
This is the problem as I see it:
When you first override bound-details, you get a copy of bound-details
with two "left" inside: the first has two "Y" properties and the
second is identical to the pre-override one. This bound-details list
is prepended to the current alist. So now you have two bound-details:
this and the original.
The second override works the same way: it makes a copy of the fist
bound-details it encounters (our new one), and prepends it to the
alist, modifying the "right" list in it as above. Now we have *three*
bound-details in the alist.
Then the revert arrives. It drops the first bound-details it
encounters, so now there are two: the one created with the first
override and the original one.
The one used subsequently is the first one in the list, the one with
two "left" sublists.
Please note that with the current version you will end up with two
"left" sublists and an empty "right" sublist since it will trigger the
nested property bug too.
This snippet shows it all:
\relative c' {
c1\startTrillSpan
c1\stopTrillSpan
\override TrillSpanner #'(bound-details left Y) = #90
\override TrillSpanner #'(bound-details right Y) = #90
\revert TrillSpanner #'(bound-details)
c1\startTrillSpan
c1\stopTrillSpan
}
But this issue for the moment leaves me unprepared :)
Right now I think maybe the easiest solution is, in
execute_override_property(), to check if a copy of the nested list you
are modifying exists, and modify this one instead of making a whole
new copy.
>
> I think that a patch, including a test file (that can be added to our
> regression tests) would be a great idea!
Patch on it's way! please give me a couple days since I should be
working on my thesis right now :)
Ciao,
Rodolfo
---
----
Join the Frogs!