Re: [frogs] Changing subproperties with grob-set-property (working on bug #40)

[ Thread Index | Date Index | More lilynet.net/frogs Archives ]


Neil Puttock schrieb:
2009/11/2 Marc Hohl <marc@xxxxxxxxxx>:

Ok, then:

LY_DEFINE (ly_grob_set_nested_property_x, "ly:grob-set-nested-property!",
   3, 0, 0, (SCM grob, SCM symlist, SCM val),
   "Set nested property @var{symlist} in grob @var{grob} to value
@var{val}.")
{
Grob *sc = unsmob_grob (grob);

LY_ASSERT_SMOB (Grob, grob, 1);
LY_ASSERT_TYPE (ly_cheap_is_list, symlist, 2);

Hmm, now I've had more time to think about this, I'm not sure this is
ideal, since there's no check that the elements of the list are
symbols.  It's probably safer to use SCM_ASSERT_TYPE to brew a custom
assertion for "list of symbols":

bool type_ok = ly_cheap_is_list (symlist);

  if (type_ok)
    for (SCM s = symlist; scm_is_pair (s); s = scm_cdr (s))
      type_ok &= ly_is_symbol (scm_car (s));

  SCM_ASSERT_TYPE (type_ok, symlist, SCM_ARG2, __FUNCTION__, "list of symbols");

Ok.
if (!ly_is_procedure (val)
   && !type_check_assignment (symlist, val, ly_symbol2scm
("backend-type?")))
 error ("typecheck failed");

I'm afraid you can't do this on a nested property, since
type_check_assignment () expects a symbol as the first arg.  Though
you could extract the main symbol (e.g., 'bound-details) using scm_car
(), the type check would still fail due to a mismatch between the
property type (list?) and the val (which would be a number in the case
of your snippet above).

I just copied this part from the definition of ly:grob-set-property!
and pasted it (as I never stop to mention: this is all very unfamiliar to me, so it just looked ok). Is there an alternative for this check, or should I simply
drop it completely?
set_nested_property (sc, scm_list_n (symlist, SCM_UNDEFINED), val);

Since symlist is already a SCM list, you don't need to use scm_list_n here:

set_nested_property (sc, symlist, val);

Ah, of course. I was so overwhelmed by the fact that I found out where scm_list_n is defined and what it does (in new-dynamic.engraver.cc is a call for scm_list_3, so grepping through the code showed that there exists an _n variant, and so on), that I simply overlooked this fact.

(Hm, it still feels like the time beginning with scheme where I stirred
in the fog and put several pieces together in the hope they will work
somehow...).

Don't worry, it'll soon make perfect sense, though if you're starting
to get cold feet, you could try implementing this in Scheme instead.

I am not sure whether this would be a better solution; I am learning
slowly, but I think that sooner or later I have to dive into the c++ code,
so if you don't loose your patience with me, I'll follow this task to whatever end (I should stop watching LOTR, it tends to bring too much pathos into my mails ;-)

Marc

---

----
Join the Frogs!


Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/