Top-level non-exported Rule not activating

[Jason Veldicott]

Hi,

I have encountered a simple situation in Dragonfly for which I've resorted to a bit of a hack to deal with, and mention here in case of interest to others, and also if there's a better way to do it.

I have a single top-level Rule, which refers to a repetition (which refers eventually to mapping and compound rules).  Not handling voice commands that the user speaks directly, "exported" is set to False.  In fact, it only works with DNS when set this way (for some good reason presumably).

A problem arises when entering context, in that because the rule is not exported, it is by default not activated.  This excludes the rule from decoding (in GrammarWrapper.results_callback()) and thus recognition.

It would not seem there is anything wrong with the rule setup as described, a top-level rule that is not exported, yet the activation mechanism seems not to support it. 

Regards

Jason

[Charlie Tango]

Hello Jason,

I'm trying to understand what you wrote, but I'm not sure I get your point.

You mentioned exported rules, active rules, top-level rules, and the
results_callback() method of the GrammarWrapper class. You discuss
different combinations of these, for example a non-exported rule that
you would like to be active.

Isn't it the case that those concepts are all actually the same, or
very closely related? Something like this:

"Exported rule" and "top-level rule" are identical. (At least for DNS;
WSR does make a distinction, as other grammars can refer to exported
rules, something which is not possible for DNS)

A rule's "active" state is only relevant for top-level rules.
Dragonfly's processing of an "internal" rule that is recognized as
part of a different top-level rule doesn't take the "internal" rule's
activity into account: it can always be processed.

The results_callback() method is only called once for the top-level
rule that is recognized. E.g. it is only called for exported rules
that are active. A non-exported rule can never be recognized (in DNS),
and inactive rules cannot be recognized at the moment.

How does the above relate to your message?

Best regards,
Charlie

[Jason Veldicott]

Hi Charlie,

There is an exported attribute in the Rule class that can be applied to any rule, wherever it appears in a grammar, including those at the top level.  (I guess if necessarily applied to only top level rules, the attribute could be applied automatically in the code.)

When this exported attribute is False, and if the rule is at the top level, the grammar doesn't work, because the rule is not activated.  DNS works with the rule properly (which seems contrary to what you mentioned), but within Dragonfly, the logic does not provide activation, as this is only applied to exported rules.

A simple code modification enabled activation of the rule.

This may be relevant to Dragonfly illuminati in terms of whether or not it is a reasonable scenario that it may not be desirable to export a top level rule.  

 

Regards

Jason

PS.. incidentally, seeing as "exported" can be applied to any rule, the definition of an exported rule as provided by code comments may be the most appropriate, aside from whatever meaning it has in DNS, with the key words it seems being "which can be spoken by the user":

- *exported* (boolean, default: *False*) --

           if true, this rule is a complete top-level rule which can be

           spoken by the user.  This should be *True* for voice-commands

           that the user can speak.

[Jason Veldicott]

Correction: 

This may be relevant to Dragonfly illuminati in terms of whether or not it is a reasonable scenario that it may not be desirable to export a top level rule yet still want it to be active for the sake of exported sub-rules.  

[Charlie Tango]

You lost me there, Jason.

> When this exported attribute is False, and if the rule is at the top
> level, the grammar doesn't work, because the rule is not activated.

By "the grammar doesn't work" do you mean that the rule is never
recognized, or that some error is given when loading the grammar?

> DNS works with the rule properly (which seems contrary to what you
> mentioned), but within Dragonfly, the logic does not provide
> activation, as this is only applied to exported rules.

What do you mean by "DNS works with the rule properly"?

You say activation is only applied to exported rules (aka top-level
rules, those that match a complete utterance). Isn't that obvious, as
a recognition could never consist of an active top-level rule
referring to an inactive sub-rule; that just doesn't make sense...

> A simple code modification enabled activation of the rule.

Could you perhaps share the code modification you mention that enables
activation of the rule?

Best regards,
Charlie

[Jason Veldicott]

I simply have a top level rule that isn't exported.  

The rule compiles to DNS ok. DNS doesn't choke on it during recognition.

During recognition however, Dragonfly wont engage the rule - because it will only activate rules that have "exported" set to True. 

This would appear to be a shortcoming in Dragonfly (not activating top level rules that are not exported), as, after modifying the code to allow its activation (with exported still False), the rule works as desired.  I could set "exported" to True, however, since the rule is merely a holder of sub-rules, and does not itself match spoken words, setting exported to True seems to 'break' the rule in DNS (chokes during recognition).

This is the hack applied to get the rule, named "main", to activate, in engine_natlink.GrammarWrapper, clearly not a general solution to the problem :

def results_callback(self, words, results):

        ...

        s = state_.State(words_rules, self.grammar._rule_names, self.engine)

        for r in self.grammar._rules:

            if not r.active and (not r.name == "main")  : continue 

                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^    

Jason