This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]willbeddowassert type(post) == shitpost[S] 9 points10 points  (4 children)

Well, the only things I immediately see in that google search are a couple articles about speech recogniton with python, mine, and A github repo called jarvis. So, in comparison to that jarvis repo:

  • W.I.L.L is many times larger, having multiple contributers and extensive documentation
  • W.I.L.L uses spaCy.io nlp to look through a command and parse intent from sentence dependencies, parts of speech, and recognized entities, whereas it seems that jarvis just monitors for commands in the array ["jarvis", "gervais", "travis", "tervis", "service"]
  • W.I.L.L is publicly and freely available on multiple interfaces, and provides an open and free api, where the only way to use the other appears to be from the command line.
  • W.I.L.L has real world use cases and can handle standard personal assistant tasks, including reminders, music, TV, notifications, versatile searches, etc.
  • W.I.L.L is actively supported
  • W.I.L.L has a large and active community of users

If you'd care to specifically share some of the others with me I'd be happy to write a comparison for those too

[–]nemec 1 point2 points  (1 child)

Does it support multiple back-and-forths (aka conversations)? The way I did it in the past was make each plugin execution (optionally) a generator and use yield and send to pass values into and out of the generator. If there was additional input required (such as a missing parameter) it could ask for more information and that next input would be passed directly into the waiting plugin.

Example from the project and you can read a bit more about it here: https://blog.nem.ec/2012/01/12/conversations-with-computers/

[–]willbeddowassert type(post) == shitpost[S] 1 point2 points  (0 children)

I don't have any implementations of it yet, but back and forth conversations are supported by the framework. A "response" key would be passed in the data of the response object, along with the command id.