For some of our single-parameter constructors, we _want_ to have implicit
conversions, because that makes the code more readable. Mark these up for
cpplint to ignore.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Within some of the internal headers, we do not have a complete declaration of
some namespaces, and that's ok. Most of these cases are within macros anyway.
Since there's no sane way to make cpplint happy otherwise, lets ignore these
warnings instead.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
In both cases, the warning is about a function argument that we do not use.
There's no benefit of doing a c++-style cast there, especially since they're
function arguments. In fact, doing anything else would just make the code less
readable. As such, we opt to ignore these warnings instead.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Since there's only two places where we use the `kaleidoscope::ranges` namespace,
and it's easy to use `ranges::` there, instead of the bare enum, lets do that,
and make cpplint happier.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
All of these places use a template argument (usually indirectly) for array
sizes, so they are _not_ variable sized. It just so happens that cpplint is
unable to figure that out on its own. For this reason, mark them explicitly, and
let cpplint ignore these false positives.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
While `using namespace` certainly has its downsides, in these cases, the scope
is local to a single file, and makes the code _much_ more readable, offsetting
any downsides the directive otherwise has. As such, lets tell cpplint to ignore
these.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
To silence a warning, explicitly ignore the return value of `RUN_ALL_TESTS`: we
exit on failure anyway, the return value isn't useful for us in any way.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Instead of running the tests right after compiling them, compile them all first,
then run them one after another. This way the test output is kept much closer
together, which is easier to glance over.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
The workaround was put in place as an attempt to get virtual builds going on
macOS, natively. It wasn't enough, and it doesn't work, so lets drop it.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
We do a number of things here:
- Bump the distro version from Trusty to Bionic, because we need newer tools.
- Install cmake.
- Unset CC, because it interferes with our virtual builds.
- Run the googletest-based suite before building the examples
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
This adds a googletest-based test harness (with googletest pulled into
`testing/googletest`, so we have a fixed state of it), and a few test
cases that demonstrate its use.
Original work by Eric Paniagua in #898, with minor cleanups by Gergely
Nagy.
Signed-off-by: Eric Paniagua <epaniagua@google.com>
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
We do not need `getShortName()` anymore: setting the shortname is now done via
device properties instead. Doing it with `getShortName` only results in
duplicated symbols.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
We can pass arguments to the entrypoint from the `docker run` commandline, so we
do not need to do that via an environment variable. This way, we're an
environment variable and an `eval` shorter.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
To make it easier to reproduce things, and to help build in a clean environment,
this adds a thin Dockerfile that has Arduino and arduino-cli pre-installed, and
- along with the `bin/run-docker` script - is set up so that one can easily run
arbitrary commands in the context of the current bundle and Kaleidoscope.
The first run will take a while, because docker will build the image. Subsequent
runs will use the cache.
To use: `bin/run-docker make`, for example. Any argument passed to the
`bin/run-docker` will be eval-ed within the container, and will run there.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Previously, rolling over from one System Control key to another would
cause the second one to be released as soon as the first one was
released, because the empty release report would be sent
unconditionally on release of any System Control key.
This change stores the value of the last System Control key
pressed. When a System Control key is released, it first checks to see
that the released key's keycode matches the last one pressed before
sending the empty report.
Signed-off-by: Michael Richters <gedankenexperimenter@gmail.com>
Gergely Nagy
Jesse Vincent
Eric Paniagua
Michael Richters