Explicitly setting the directory at the beginning of the start-mycroft.sh
and stop-mycroft.sh scripts. The behaves better if invoked from a
different directory.
Several minor and simple CLI fixes:
* The CLI was locking up with at Lock() deadlock when rebuilding the
filtered log.
* The simple_cli() wasn't registering handle_speak() on the websocket,
even though the handler was setup for it. The utterances are already
clear from the Input: line or from the logs being printed, so no need
to have a handle_utterance() registered in the simple_cli() case.
* Help wasn't refreshing the screen, so was invisible.
* An error could be thrown if Ctrl+Z was hit to suspend the 'fg' to
return to foreground before any key was pressed.
Numbers are now normalized to the text equivalent. This is to solve problems where mimic2 returns a speed up text generation when saying number values.
Allow a Padatious intent to override Adapt when it is VERY
certain that the utterance is directed at it. (95% confidence
or greater.) Right now that only occurs if the intent match
for the given phrase is perfect.
This solves this kind of issue:
* Adapt: Matching on "Set" and "Alarm"
* Padatious: Handling "is an alarm set"
* Fix logic error for when no Padatious intent
Previously, the location of the log files changed depending
on whether you were running on a Mark1/Picroft or under a
"Github" install. Now they are always under the same directory
at /var/log/mycroft-*.log
This also updates the CLI to pull from that location always.
Additionally:
* Removed the nonfunctional 'wifi' option from start-mycroft.sh
* Made the validation for dev_setup.sh exit instead of just show
a warning message in start-mycroft.sh
* Added code to allow dev_setup.sh to be run from different
directories successfully
Using a virtual environment is not necessary under Docker, which is a controlled
environment on its own. This uses the semi-standard existence check for ```.dockerenv```
as a way to detect when running in a Docker context.
The CLI would often have temporary screen corruption. This reworks
several things to correct that issue, although it looks like the
ultimate cause was drawing to the screen while in the middle of
waiting on a VT100 ESC keycode sequence.
* Rearchitected all screen drawing to run in a single thread. Now
call set_screen_dirty() instead of draw_screen()
* Added a lock on accessing the various Log buffers, preventing
changes to the buffer in the middle of a redraw
* Modified key reading logic when ESC character is received. Now
uses a 1 second timeout if no subsequent keycodes are sent
* Catch several special exceptions. Curses throws exceptions in some cases during get_wch(), such as
when you Ctrl+Z suspend the CLI the resume the process. Also moved Ctrl+C processing into this exception handler.
While working on the Alarm skill I discovered several issues with the
event scheduler. This PR cleans up those findings and resolves several
other potential issues:
1) To avoid thread synchronization issues, the EventScheduler had several
queues which independently held objects to be added/deleted/updated. However, the order of the events was undefined and got mixed since they were all batched together. So, for instance, if skill code performed:
self.add_event("foo", self.handle_foo)
if SomeReason:
self.cancel_event("foo")
The actual order of queue handling would perform Remove first, then Add which resulted in "foo" not being found for delete, but then added and left as an active event.
Now the EventScheduler protects the list using a Lock and the queues have been removed. Modifications to the list happen immediately after obtaining the lock and are not batched up.
2) One-time events were triggered while the event was still in the EventScheduler list. Now the entry is removed before invoking the handler.
3) Within the MycroftSkill.add_event(name, handler) is a local 'wrapper' method that actually makes the callback. The MycroftSkill.remove_event(name) method attempted to find entries in the events list and the associated handler entries in the self.emitter to remove. However, the emitter actually held the wrapper(handler), not the handler itself. So the emitter handlers were left behind.
This was a quiet bug until the next time you scheduled an event of the same name. When that second event finally triggered, it would fire off both the new and the old handler -- which snowballed in the 'skill-alarm:Beep' case, doubling and redoubling with every beep.
Now this cancels all the emitter listeners by name. There is a very slim chance that someone has registered a listener with the same name, but since it is namespaced to "skill-name:Event" I think this is pretty safe.
Not technically related, but a failure that has been lurking for
some time and is a French unit test that doesn't work depending
on the time of day when the test is run.
The start-mycroft.sh and stop-mycroft.sh scripts now automatically
run the enclosure client if the platform is defined as
"mycroft_mark_1".
Also corrected a copy/pasted comment and added a clarifying message during the stop when killing a process.
Add stop support for recent 'python3' change
Necessary after #1703
The -r option eliminates the quotes on output
Clean up the usage of jq, -r removes the quotes on output. Also eliminated the python2 support in the regex ```[p]ython[2|3]``` and dropped the unnecessary ```[p]```.
Verify platform file existence before read
It might not exist on a desktop install.
Verify platform file existence before read
This is reimplementation of #1649 which became divergent.
## Description
Adds a Ogg123Service and a play_ogg exactly like Mpg123Service and play_mp3
## How to test
I have a skill for a podcast which does not have an mp3 feed:
https://github.com/joshuacox/skill-GNUworldOrder
## Contributor license agreement signed?
signed by @joshuacox
At startup, Padatious was blocking in the fallback while the
training occurred. As a result, any attempts to use Mycroft
during that period would queue up rather than giving the
user feedback. Now it immediately returns False, allowing
user notification to occur elsewhere.