Re: Accessing Grob properties

[Paul Morris]

> Am 22.01.2016 um 21:54 schrieb David Kastrup:
>>> However, from there I don't get any further, and it seems I totally
 don't understand how the Scheme types are matched in C++.
 Any attempt to compare the content of beam_count_prop with a set of
 predefined values seems to fail, and even
 
if (scm_equal_p (ly_symbol2scm ("one"), ly_symbol2scm ("two")))
 
 returns true (using scm_equal_p equally as for the eq and eqv
 versions.
>> It does not return true but SCM_BOOL_F.  Which you then convert to a
>> true C++ boolean since it is non-zero.
>> 
>> You want   if (scm_is_eq (... ))
>> instead: predicates with name xxx_is_yyy return a C (or C++) boolean.
>> Predicates with name xxx_p return an SCM boolean which you need to
>> convert to a C++ boolean using, for example, scm_is_true.
>> 
>> ...
>> 
>> SCM_BOOL_F as a C condition is _true_ rather than false. 
> 
> Thank you for this clear and general explanation that will serve me much
> further than simply solving the problem at hand. Of course this totally
> makes sense - and works perfectly.

This is indeed helpful info.  I checked the CG to see if it covers this kind of 
thing, and it looks like it does, although I didn’t check closely enough to see 
if it covers this exact example.  

http://lilypond.org/doc/v2.19/Documentation/contributor/comparison

-Paul
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Accessing Grob properties

[David Kastrup]

Urs Liska  writes:

> It seems I'm now at a similar point in C++ Guile (scm_whatsoever) as I
> was with Guile Scheme at an earlier stage :-(
>
>   SCM subdivide_details =
> scm_assq_ref (beam_settings_, ly_symbol2scm ("subdivide-details"));
>
> seems to fetch the right thing, namely something like
> '((beam-count . metric))
>
> But then I start to get lost.
> I would expect
>
>   SCM beam_count_prop =
> scm_assq_ref (subdivide_details, ly_symbol2scm ("beam-count"));
>
> to assign beam_count_prop a symbol "metric" - as I get when I do the
> same thing in Scheme.

It does.

> However, from there I don't get any further, and it seems I totally
> don't understand how the Scheme types are matched in C++.
> Any attempt to compare the content of beam_count_prop with a set of
> predefined values seems to fail, and even
>
> if (scm_equal_p (ly_symbol2scm ("one"), ly_symbol2scm ("two")))
>
> returns true (using scm_equal_p equally as for the eq and eqv
> versions.

It does not return true but SCM_BOOL_F.  Which you then convert to a
true C++ boolean since it is non-zero.

You want   if (scm_is_eq (... ))
instead: predicates with name xxx_is_yyy return a C (or C++) boolean.
Predicates with name xxx_p return an SCM boolean which you need to
convert to a C++ boolean using, for example, scm_is_true.

> I would have expected that
>
>   beaming_options_.subdivided_beam_count_ =
> (scm_eqv_p (ly_symbol2scm("one"), ly_symbol2scm("one")))
> ? ONE
> : (scm_eqv_p (subdiv_beam_count_prop,
> ly_symbol2scm("base-moment")))
> ? BASE_MOMENT
> : METRIC;
>
> would assing the (new) member subdivided_beam_count one out of the three
> constants, depending on the value of the property:

This isn't Emacs Lisp (which has a clever definition of nil, which in
Lisp serves both the functions of #f and '()).  SCM_BOOL_F as a C
condition is _true_ rather than false.

-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Accessing Grob properties

[Urs Liska]

Am 22.01.2016 um 18:49 schrieb David Kastrup:
> Urs Liska  writes:
>
>> ...
>> I am now trying to implement configuration through
>>
>> \override Beam.subdivide-details.beam-count = #'metric
>> \override Beam.subdivide-details.ignore-shortening = ##f
>> etc.
>>
>> but I don't see the proper way of doing so (in C++).
>>
>> I am able to retrieve the property value somewhere in the Beam class
>> (beam.cc), but I don't seem to manage to get that information into
>> Beaming_options or Beaming_pattern.
>> Is it possible that the Beam object is only created when the
>> Beaming_pattern has already been completed?
> Maybe, but the beaming options are fetched at start time via
>
> lily/auto-beam-engraver.cc:244:  beam_settings_ = Grob_property_info (context 
> (), ly_symbol2scm ("Beam")).updated ();

Thank you. From here I could inject a new field in Beaming_options and
make Beaming_pattern::beamify use it.
This was the hook I was looking for.

But ...

>
>> Apart from that question I'd ask more generally:
>> How could I manage to get hold of the values in a Beam.subdivide-details
>> alist from within Beaming_pattern::beamify?
> Using calls of scm_assq_ref or so?

It seems I'm now at a similar point in C++ Guile (scm_whatsoever) as I
was with Guile Scheme at an earlier stage :-(

  SCM subdivide_details =
scm_assq_ref (beam_settings_, ly_symbol2scm ("subdivide-details"));

seems to fetch the right thing, namely something like
'((beam-count . metric))

But then I start to get lost.
I would expect

  SCM beam_count_prop =
scm_assq_ref (subdivide_details, ly_symbol2scm ("beam-count"));

to assign beam_count_prop a symbol "metric" - as I get when I do the
same thing in Scheme.

However, from there I don't get any further, and it seems I totally
don't understand how the Scheme types are matched in C++.
Any attempt to compare the content of beam_count_prop with a set of
predefined values seems to fail, and even

if (scm_equal_p (ly_symbol2scm ("one"), ly_symbol2scm ("two")))

returns true (using scm_equal_p equally as for the eq and eqv versions.

I would have expected that

  beaming_options_.subdivided_beam_count_ =
(scm_eqv_p (ly_symbol2scm("one"), ly_symbol2scm("one")))
? ONE
: (scm_eqv_p (subdiv_beam_count_prop,
ly_symbol2scm("base-moment")))
? BASE_MOMENT
: METRIC;

would assing the (new) member subdivided_beam_count one out of the three
constants, depending on the value of the property:

\override Beam.subdivide-details.beam-count = #'base-moment
=> BASE_MOMENT
etc.

But it always uses ONE
(which is consistent with the above observation).

In short:
What I want to achieve is
- read the property subdivide-details.beam-count from the available
beam_settings_
- assign the appropriate value from an enum (ONE/BASE_MOMENT/METRIC) to
the beaming_options field.

Any further assistance possible?

Thanks
Urs


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Accessing Grob properties

[Urs Liska]

Am 22.01.2016 um 20:29 schrieb Urs Liska:
>   beaming_options_.subdivided_beam_count_ =
> (scm_eqv_p (ly_symbol2scm("one"), ly_symbol2scm("one")))
> ? ONE
> : (scm_eqv_p (subdiv_beam_count_prop,
> ly_symbol2scm("base-moment")))
> ? BASE_MOMENT
> : METRIC;

Oops, that was the wrong test version, originally it was

  beaming_options_.subdivided_beam_count_ =
(scm_eqv_p (beam_count_prop, ly_symbol2scm("one")))
? ONE
: (scm_eqv_p (subdiv_beam_count_prop,
ly_symbol2scm("base-moment")))
? BASE_MOMENT
: METRIC;

but the result is the same: no matter what beam_count_prop seems to
hold, the result is always ONE.

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Accessing Grob properties

[Urs Liska]

Am 22.01.2016 um 21:54 schrieb David Kastrup:
>> However, from there I don't get any further, and it seems I totally
>> > don't understand how the Scheme types are matched in C++.
>> > Any attempt to compare the content of beam_count_prop with a set of
>> > predefined values seems to fail, and even
>> >
>> > if (scm_equal_p (ly_symbol2scm ("one"), ly_symbol2scm ("two")))
>> >
>> > returns true (using scm_equal_p equally as for the eq and eqv
>> > versions.
> It does not return true but SCM_BOOL_F.  Which you then convert to a
> true C++ boolean since it is non-zero.
>
> You want   if (scm_is_eq (... ))
> instead: predicates with name xxx_is_yyy return a C (or C++) boolean.
> Predicates with name xxx_p return an SCM boolean which you need to
> convert to a C++ boolean using, for example, scm_is_true.
>
> ...
>
> SCM_BOOL_F as a C condition is _true_ rather than false. 

Thank you for this clear and general explanation that will serve me much
further than simply solving the problem at hand. Of course this totally
makes sense - and works perfectly.

Best
Urs



___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Accessing Grob properties

[David Kastrup]

Urs Liska  writes:

> Am 18.01.2016 um 20:20 schrieb Urs Liska:
>> Am 18.01.2016 um 18:37 schrieb Simon Albrecht:
>>> On 18.01.2016 18:27, Urs Liska wrote:
 Am 18.01.2016 um 18:24 schrieb Kieren MacMillan:
> Hi Urs,
>
>> c)
>> Take a) as the default and provide a context property
> This.
>
> Thanks,
> Kieren.
>
 Any suggestions for a better name than

  \set subdividedBeamCountAddForShortenedBeam = ##t
>>> It would almost call for
>>> \override Beam.subdivide-details.ignore-shortening = ##f
>>> (this would be the default). Still a bit clumsy, and I don’t want to
>>> upturn your plans. But the options seem to be complex enough to be
>>> better stored in an alist.
>> I find this a very good idea. I don't feel very good with inventing
>> arbitrary independent context properties. Having a single object and
>> consistent interface would make it much more consistent to add more
>> configuration options to the beaming.
>>
>> That wouldn't bother my "plans" at all, it's just that I don't know out
>> of my hat where to define (and initialize) such an alist and how to
>> access its value from within the C++ beaming code. So any hints welcome ...
>>
>> Best
>> Urs
>
> I am now trying to implement configuration through
>
> \override Beam.subdivide-details.beam-count = #'metric
> \override Beam.subdivide-details.ignore-shortening = ##f
> etc.
>
> but I don't see the proper way of doing so (in C++).
>
> I am able to retrieve the property value somewhere in the Beam class
> (beam.cc), but I don't seem to manage to get that information into
> Beaming_options or Beaming_pattern.
> Is it possible that the Beam object is only created when the
> Beaming_pattern has already been completed?

Maybe, but the beaming options are fetched at start time via

lily/auto-beam-engraver.cc:244:  beam_settings_ = Grob_property_info (context 
(), ly_symbol2scm ("Beam")).updated ();

> Apart from that question I'd ask more generally:
> How could I manage to get hold of the values in a Beam.subdivide-details
> alist from within Beaming_pattern::beamify?

Using calls of scm_assq_ref or so?

-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user