From f01e087e27cdb4c9bc46c8cc1b63883cf1214d80 Mon Sep 17 00:00:00 2001 From: Curle Date: Tue, 15 Oct 2019 20:18:12 +0100 Subject: [PATCH] Add the main file, with the majority of the documentation. --- main.cpp | 108 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 108 insertions(+) create mode 100644 main.cpp diff --git a/main.cpp b/main.cpp new file mode 100644 index 0000000..2511b4a --- /dev/null +++ b/main.cpp @@ -0,0 +1,108 @@ +#include +#include +using namespace std; + +/* Team Kitty, 2019 */ +/* Guinevere One */ + +/* This package is the parsing system (NLP) for the Guinevere system. + This package is split up into 5 different parts, each controlled by + modules. This is the file that controls all of the other modules, + making sure that the system reacts the way it was configured. + + It should be mentioned here, before we start, that this system does + not use advanced Machine Learning systems, or anything automagical. + It runs entirely on predetermined algorithms, which are fully + designed manually, so the system is not infallible. + + The system can be configured to run in 3 different ways; + - As a console application, where it uses stdio to communicate with + the user, parsing internally. This is ideal for command-line usage, + and was designed purely for testing the system. This is not the + intended usage. + - As a web server. In this configuration, it starts a web server on a + configurable port and listens for incoming connections. This is the + intended usage of the Guinevere parsing system, as it can then send + out commands to other devices. + - As a web client. In this configuration it listens for input over + stdin and sends it out to the listen server. This makes developing + the main clients considerably faster. + Maybe implement this into the Guinevere main clients eventually? + + Currently, the program has 5 sections, as mentioned above: + - Input; this is where the 3 modes mentioned above are implemented + - Parsing; this is only done if the console app configuration is + chosen above. Otherwise, it skips this module. + - Evaluation; this is only done in debug mode, in console app + configuration. It tries to prepare an output that tells the user how + likely it was to pick each module for the given input. + - Knowledge; if the output was strange, and if "Define" was the most + likely module in Evaluation, it can save time by enabling the + Knowledge system to attempt to get a definition of the "Define" + keyword from Wolfram|Alpha. Since this cuts down the rate of network + access by half, it might improve data usage. + - Output; finally, once all of the sections have yielded, it tries + to output the requested data in a decent format. If the system is + running as a console app, it outputs to STDOUT. If the system is + running as a web server, it sends a nicely formatted JSON + encoded package to the connected client, or displays said package if + running as the client. + + The Parsing and Knowledge systems connect to various Modules: + - Identify: Triggered by "What is", "Who is" and "How do I" questions. + It tries to pull a short definition from WikiTL;DR, or redirects to + the most appropriate Wiki page if that fails. If the user complains, + saying "That wasn't useful", or "Try again", it tries to reach out + to Plowie or W|A to get an answer there. If Identify doesn't work, + it falls through to the next appropriate module. + This is the module expected to be used the most, so it will have + the most time put into it. + - Control: Triggered by "Set", "Play" or other commands that are + deemed to be likely to control or change the state of something. + The Guinevere system was originally designed to be used with + custom Smart Home electronics and systems, so this will probably + be the second most developed system. It will have subsystems for + changing the color and intensity of smart lighting, as well as + systems for controlling custom Smart Locks eventually. + This will not be forseeable for quite a while, though. + - System Control: A subsystem of Control, but important enough to + require an explanation nonetheless. If Guinevere is eventually + integrated within Sync, this module will allow voice control of many + internal components of the system. With a builtin passcode, it can + also be used to control kernel level things, like multitasking + methods and paging control systems. In user-land, it can also be + used for dictation input (if you trust my algorithms enough) + or for changing user settings, such as keyboard layout, hotkey + behaviour, or window manager/compositor settings. + Perhaps this interface could eventually be used as an + optional replacement for configuration files? + - Define: The fallthrough. If the user says a random word, which is + not identified as a custom keyword, then the system will ping W|A to + get a nicely formatted definition of that word. +*/ + +// First is the definition of the common types: +/* There are three main classes used in the processing of requests: + - First, there is the input. The input is returned by the input + detection system, and is used in Processing for determining the + Intent. + - Second, there is the Intent itself. The Intent is a construction + of how likely the input command is to belong to a module. Since + the Intent algorithm is an algorithm and not a Machine Learning/ + Neural Network thing, it can be easily changed and tweaked to match + the correct criteria. Out of the Processing system, the intent is + used to trigger the correct module and the Intent is then discarded. + - The output is a structure which is given from Processing to Output, + and is used to generate a nicely formatted output. The output itself + is sent around inside the program as a JSON/XML string. I have yet + to decide. +*/ + + +int main() { + + + return 0; +} + +