Adapted bundled grammar for Caster v1.0.0

[LexiconCode]

Adapted bundled grammar for Caster v1.0.0

Caster v1.0.0 is close to release. A few things to note.

• User grammars can now be added to C:\Users\%USERNAME%\.caster\rules and loaded from rather than the internal apps directory. Simply copy the file to the directory and follow the next sub bullet point.
  • After restarting Caster Say enable python voice coding plugin for the grammar to load. (Only needs to be done once, Caster remembers between reboots/starts.)
• Switched from MergeRule to MappingRule. The rule should not be CCR (MergeRule) unless explicitly designed. Let me know if you intend for it to be a CCR grammar.
• You can edit grammars and reload live without rebooting the engine. Currently Caster does reload grammars but not modules so be aware.

[mpourmpoulis]

Thank you very much for your time Once again!
I assume that regarding the rules folder the same applies for the other bundles as well ? I will fix the documentation and make a few Small changes myself. I think it is best the Commands are not chained At least for the time being!

[LexiconCode]

I assume that regarding the rules folder the same applies for the other bundles as well
You're welcome and I hope to continue to find ways to contribute.

1.0.0 has unified the loading mechanism across all of Caster and is significantly easier to use. With those enhancements the user directory can load any type of caster supported grammar. In previous versions you could easily create a global ccr grammar but not app grammar without a jumping through significant hoops.

Therefore I would leave your previous recommendation for the last two versions in place and utilize rules folder for Caster 1.0.0. Once Caster 1.0.0 has been released for a while you could begin to phase out the older versions to simplify documentation and code.

[mpourmpoulis]

Thanks for the clarification!

[mpourmpoulis]

firstly many many thanks for all your help! I know these are very busy period for you and my apologies for bothering you but it seems there is a small issue :)

today I tested the 1.0.0 bundlesand they worked flawlessly on Windows. Because with release 0.0.4 support was added
in the 0.5 and 0.6 bundles for Aenea , I tried with a 1.x as wellbenchmarking against the latest version of Caster 1.1.3.

Unfortunately, it did not work, as it seems that then mapping rulemaker imports AppContext directly from dragonfly
and as a result the application context from aenea never comes into play.
to give you an idea, as I am working with the Windows host and Linux guest , commands are only executed on the guest machine when my window sublime is in the foreground.

For my personal use case there are easy workarounds but but this prevents me from supporting fully aenea,as for people with a Linux host that is a big problem I guess.

would you happen to have any ideas to work around this issue?

Furthermore , unless I have misclassified the cause of the issue, other grammars might be affected as well!

[mpourmpoulis]

I quickly tested the default sublime rule as well, same issue appears!

[LexiconCode]

Thanks for the in-depth testing! I will be looking at this over the next few days and see what I can do.

[mpourmpoulis]

Thanks a lot for the quick response and Otherwise good job with the new release:)

[LexiconCode]

Looks like in a few days became a few minutes ago (:

Needs to be tested yet but you made it easy pointing out rulemaker. Thanks again.

I don't have Aenea set up on my end so if you could test the above pull request that would be great!

[mpourmpoulis]

'okay I tested it and is working :)
however this exception keeps printing on the NatLink window

Traceback (most recent call last):
File "C:\Python27\lib\site-packages\dragonfly\engines\backend_natlink\engine.py", line 285, in begin_callback
self.grammar.process_begin(executable, title, handle)
File "C:\Python27\lib\site-packages\dragonfly\grammar\grammar_base.py", line 444, in process_begin
or self._context.matches(executable, title, handle):
File "C:\NatLink\NatLink\MacroSystem\aenea\proxy_contexts.py", line 146, in matches
return self._reduce_matches(self._check_properties())
File "C:\NatLink\NatLink\MacroSystem\aenea\proxy_contexts.py", line 119, in _check_properties
self.arguments[key])
File "C:\NatLink\NatLink\MacroSystem\aenea\proxy_contexts.py", line 127, in _property_match
desired = desired.lower()
AttributeError: 'NoneType' object has no attribute 'lower'

as a second note, though aenea is generally kinda laggy in my set up, I get the feeling it is a bit more, might have to do with these exceptions

[LexiconCode]

Interesting I would comment out the import one file at a time and see if anything is being triggered from Caster.

[mpourmpoulis]

But do not want to bother you with a performance issue might be my mistake, I have not used aenea in a while. In general I use it Mostly to check that the bBundles are working as native Caster actions Can be used with the VM:)

[mpourmpoulis]

Unfortunately the only way to prevent these exceptions seems to be to commend out from the mapping rule maker :( I even tried disabling both the sublime and the Plugging rulesBut to no avail.
I took a look at the code of aenea And it seems that the line of code that is Dragon the exception has changed. Perhaps Has something do with that? Not sure, I try looking into it tomorrow.
I think it is best if other people take a look at it as well.Might be that my setup is to blame, I don't know

[LexiconCode]

All right this should be solved within using the latest master branch in the respective projects involved. Aenea Now checks for None variables in AppContext and Caster includes Aenea AppContext override in Mapping Rule Maker.