| Commit message (Collapse) | Author | Files | Lines |
|
This is following the advice provided in https://matija.suklje.name/how-and-why-to-properly-write-copyright-statements-in-your-code
|
|
|
|
|
|
This field is deprecated together with the `test` command.
Instead, rely on the `dev` extra — which is what Travis CI is already using
to install the right set of dependencies.
|
|
As per https://github.com/pypa/setuptools/issues/1684, the test command in
setuptools is deprecated, so let's not go out of our way to have it work
correctly.
Travis is not depending on this feature at all.
|
|
This removes a number of fixed strings from the Python side of the setup,
and prefers referencing the `README.md` file by name.
|
|
This makes it easier in the integration to install all the needed dependencies.
|
|
The python-scsi module is not installable via pip, so there's no point in listing it as a dependency right now. It's probably better to replace this with a new extension altogether.
|
|
This simplifies compatibility with usbmon-tools for the reversing tools, and will allow converting all the type annotations inline, which is less intrusive.
|
|
|
|
|
|
|
|
|
|
Implemented based on the protocol documentation provide by Ascensia, with
portions from glucodump by @sm6xmm (relicensed by the author under MIT
license.)
Squashed from pull request #62.
Signed-off-by: Anders Hammarquist <iko@iko.pp.se>
Signed-off-by: Diego Elio Pettenò <flameeyes@flameeyes.com>
|
|
Python 3.4 lacks the `typing` module, which requires try/catch when
importing, making type annotations more verbose than needed.
At the time of writing, Debian oldstable has Python 3.5 available, so it
sounds like a good default.
|
|
Also sort the list so that's easier to know where to add it.
|
|
|
|
Most of the epydoc metadata (author, copyright, email) is duplicate in
the package's setup.py or README. These copies are more likely to get out
of date, and increase the amount of work to keep them in line.
The license information should rather be provided with an SPDX identifier,
which is more similar to what the Linux kernel and other projects, such as
pyserial, do.
|
|
Due to EURid threatening to suspend my domain, make sure that the
references are updated to point at the right stable domain.
This includes changes to the files as well as a mailmap to update the
author references in the log.
|
|
This avoids having the separate _MeterInfoBase class, and reads much nicer.
|
|
|
|
This still is required to fix Issue #38, but luckily it's just a test
failure for now.
|
|
The API changed in slightly incompatible ways so I'll have some work to
make sure this works on both versions (and that there is some test around
it, possibly).
|
|
As noted in Issue #30, this is currently untested, but I'm confident it
won't take much to get it to working state.
|
|
This simplifies the code a bit here and there, making sure that the
structures are all define at the top of the file. It also align the
structure of the driver a bit more with otultraeasy, making it easier to
spot the similitudes.
|
|
This removes the wholly complicated _Packet() object and replace it with
more readable construct.
Unfortunately this appears to reduce performance because of the serial
stream buffering, needed to calculate the checksum. It's unfortunate, but
it at least avoids a significant amount of custom code.
|
|
This replaces the use of manual structures with well-defined construct
entries; it also give consistency to packet vs message.
Log input and output messages, to be clearer.
|
|
Closes https://github.com/Flameeyes/glucometerutils/issues/34
|
|
|
|
This simplifies the code and enforces the validation within the format
documentation too.
construct can handle the full package verification, including dealing with
padding.
|
|
|
|
This should address Issue 5 (theoretically some of the dependencies are
OS-specific but that's a longer problem).
Also partially addresses Issue 9 because now we have an easy to understand
"install and try out" option.
|
|
This should make it easier to add dependencies and so on.
|
|
|
|
Supporting older Python is becoming harder, and modern Python is more
readable, particularly as it allows for less brittle code.
|
|
|
|
|
|
|