-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Grammar lists do not work correctly with Dragon 15 in some cases #82
Comments
This would add convenience for me, because it would allow me to have a dragonfly grammar that consistently capitalizes words. |
This issue with lists is unrelated to the problem we have been discussing
on the Caster Gitter channel.
I suspect that problem is a regression in Dragonfly that has, until now,
gone virtually unnoticed, since most users make use of grammar, rather than
grammar rule, contexts. Either that, or it is a quirk of DNS itself. I
see nothing unusual in the relevant parts of the Natlink source code.
|
DNS 13 is the expected outcome for in process?
Updated the imports from @Danesprite example. import natlink
from natlinkcore.natlinkutils import GrammarBase
# spec "this big red object is good"
class ThisGrammar(GrammarBase):
gramSpec = """
<start> exported = this <ruleOne> is {list};
<ruleOne> = big <ruleTwo> object;
<ruleTwo> = red | blue;
"""
def initialize(self):
self.load(self.gramSpec)
self.activateAll()
# Add a dynamic list containing the words "good" and "bad".
self.setList("list", ["good", "bad"])
def gotResults_start(self,words,fullResults):
natlink.playString('Heard macro "sample list"{enter}')
if __name__ == '__main__':
natlink.natConnect()
thisGrammar = ThisGrammar()
thisGrammar.initialize()
def unload():
global thisGrammar
if thisGrammar: thisGrammar.unload()
thisGrammar = None
if __name__ == '__main__':
try:
natlink.waitForSpeech()
finally:
natlink.natDisconnect() |
Out of process - Make sure DNS process is not running Kill dns process
When loading the script the following traceback occurs and DNS processes must be killed.
|
Sorry for the late reply, @LexiconCode. I'm not sure why it is printed out twice, but yes, that is a reasonable outcome for natspeak.exe. The other error you're seeing is likely unrelated. I do not see the point of using Natlink in this fashion. If the library is to be used "out of process," DNS should have started up properly and the Natlink messages window should be present. There should be no need to close DNS as long as each grammar is unloaded before the remote process -- python.exe -- disconnects. And that might be done automatically anyway, I don't recall. Incidentally, I have run Dragonfly's test suite "out of process" for years now without having to close/restart DNS. |
There are a number of Natlink quirks like this one that are likely unfixable. It might be better to simply list them all together in one place and reserve the GitHub issue tracker for things that can be fixed. What I have in mind is something like the sections sometimes found at the end of UNIX manual pages, e.g. csh(1), Bugs. Do you know if there is a sort of Natlink "bugs," "caveats," or "limitations" list somewhere already? |
Hi Dane, I had read this one before, but it was not in my attention. I will look at this soon (still on vacation for the coming week). Please mention other things as an issue too, More structure we can think about later, first see what we can tackle... |
Hi Quintijn,
No problem, this is not a pressing issue. Hope you enjoy your vacation.
I'll put a list of things together soon and open a new issue.
…On Sun, 11 Sep 2022 23:51:03 -0700 Quintijn Hoogenboom ***@***.***> wrote:
Hi Dane, I had read this one before, but it was not in my attention. I will look at this soon (still on vacation for the coming week).
Please mention other things as an issue too, More structure we can think about later, first see what we can tackle...
--
Reply to this email directly or view it on GitHub:
#82 (comment)
You are receiving this because you were mentioned.
Message ID: ***@***.***>
|
hi Dane, I added you as a potential assignee as well. If anyone wants to take a stab at this they would be welcome. |
I will take the first step on this! |
Thank you, Doug. I did investigate this, but got no further than tracing the code path of `GramObj.appendList()' to the COM methods in speech.h.
The odd thing is that no error is reported. That is, there is no indication from DNS that list operations fail. (A NatError would be raised in that case.) Since lists do work "in process," this makes me think it's an obscure bug on the DNS side.
Again, this issue is not pressing. I would be content to have it documented somewhere.
…On Thu, 15 Sep 2022 08:55:29 -0700 Doug Ransom ***@***.***> wrote:
hi Dane, I added you as a potential assignee as well. If anyone wants to take a stab at this they would be welcome.
--
Reply to this email directly or view it on GitHub:
#82 (comment)
You are receiving this because you were assigned.
Message ID: ***@***.***>
|
Dane, when trying your grammar, it just works. Recently there was a fix with recognitionMimic and lists. Could you please try again your example grammar, after installing the latest installer, that LexiconCode will release soon? |
All right. I think this issue can be closed then. |
This is still an issue with Dragon 15. It only occurs out of process. I'm reopening this issue because of #198. Strangely, I can add and speak list items if they're single characters — letters and numbers. It seems that any item longer than one character will append to a list successfully, but won't match via speech or mimic. |
Natlink's named/dynamic grammar list functionality does not work correctly with Dragon 15 if used in a stand-alone Python process. However, it works just fine in a command module loaded by natspeak.exe. The related methods are
GramObj.appendList()
andGramObj.emptyList()
.The problem can be replicated by running my sample_list.py Natlink command module. The module will load without issue, but Dragon will fail to match a spoken or mimicked command to the grammar. If one says, for example, "this big red object is good," Dragon will normally output the spoken words instead. It would seem that Dragon is either not receiving or not setting the list words and therefore cannot recognize the command. If the module is loaded into natlink normally via the user directory, it will work properly.
This behaviour occurs in the older Python 2.7 and the newer Python 3.8 versions of Natlink.
I note that this can only be related to the C++ code since Dragonfly, which uses the
GramObj
class directly, has the same problem.This issue, if it is indeed fixable and not another Dragon "quirk" we must simply endure, should be considered low priority since Natlink is not normally used in this fashion.
The text was updated successfully, but these errors were encountered: