Skip to content

Release 3.2.0 #580

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 80 commits into from
May 16, 2019
Merged

Release 3.2.0 #580

merged 80 commits into from
May 16, 2019

Conversation

hardbyte
Copy link
Owner

Promotes the beta release to final and merges into master.

Try the beta with:

pip install python-can==3.2.0b0

Changelog notes are on the beta release page - https://github.com/hardbyte/python-can/releases/tag/3.2.0-beta.0

All the issues and PRs for this release are closed in the milestone.

hardbyte and others added 30 commits February 24, 2019 21:30
* apply fixes from https://gist.github.com/acolomb/945cc5e5b29ced411f1df5b5f9c4a4d0
* simplify find_serial_devices()
* fix sphinx warning about indentation
* remove support for Python 3.4 
* update testing dependencies
* update README.rst
The internal reference for an opened interface via the CANAL API is
returned as an integer from the CanalOpen() DLL call in
Usb2CanAbstractionLayer.open().  It is supposed to be returned from
the abstraction layer and stored in the Usb2canBus.handle member for
later reference by all other API calls.

Add the missing return statement and adjust the docstring
accordingly.  Only valid handles (greater than 0) will be returned,
otherwise an exception is thrown already.
Before, the config value was not being actually sent to the PEAK hardware
due to the setter not being invoked. Instead, the private _state variable
was being written to directly.

Now, the setter is being invoked and the state is being properly sent
to the PEAK hardware.
Originally, the testcase would fail because timestamps would not match.
This was due to a Can.Message being initialized had a timestamp
value of 0, while a recv'd message had a virtual timestamp. When compared
they never matched.

Modified testcase now allows for some variation (0.016 s) in the timestamp
for a 0.01 s periodic message and compares the last message with the next
last message.
Tiny change.
* better developer docs
* Add section "About the IO module"
* add note about newly added section
* Update doc/internal-api.rst
…se class from execution and uses a simple del statement instead
felixdivo and others added 18 commits May 7, 2019 16:41
* This fixes the non-standard usage of __test__=False to exclude the base class from execution and uses a simple del statement instead

* refactor & comment player

* refactor message equality helper

* add temporary GC disabeling to test_cycle_time()

* add test for MessageSync

* exclude AppVeyor from MessageSync tests

* make tests/timings easier for CI tests

* make tests better suited for CI tests (by excluding them on some platforms)
Various trivial spelling changes throughout the generated docs:

    * 'farly' -> 'fairly'
    * 'throughly' -> 'thoroughly'
    * 'actally' -> 'actually'
    * 'tunred' -> 'turned'
    * 'seperator' -> 'separator'
    * 'busses' -> 'buses'
This would fail in version 4.0 of this library and already prints a warning.
Various spelling corrections in the generated docs
…ly-faster

Make coverage collection slightly faster
* Fix stuct packing in build_bcm_header on 32-bit

Previously build_bcm_header relied upon adding a "0q" at the end of the
struct format string in order to force a 8-byte wide alignment on the
struct, in order to interop with the structure defined in the Linux
headers:

    struct bcm_msg_head {
      __u32 opcode;
      __u32 flags;
      __u32 count;
      struct bcm_timeval ival1, ival2;
      canid_t can_id;
      __u32 nframes;
      struct can_frame frames[0];
    };

The Python code assumed that alignof(long long) == 8 bytes in order to
accomplish this. However, on certain 32-bit platforms, this assumption
is not true, and alignof(long long) == 4.

As the struct module does not provide logic to derive alignments of its
types, this changes the packing logic to use ctypes. This exposes the
alignment of the struct members, allowing us to determine whether padding
bytes are necessary.

Fixes #470

* Call BCM factory upon module initialization

In order to prevent the BCM factory method from being called each time a
BCM header struct is created, we create the class when the module gets
created.

* Add SocketCAN interface tests for BCM factory

Add a SocketCAN interface test file with tests for validating the
BcmMsgHead class created by bcm_header_factory on various platforms.

* Clean up comments referencing packing via struct

Clean up the old comment in build_bcm_header referencing the old packing
code that called into Python's struct library. This now uses ctypes, so
and the class is created via the bcm_header_factory factory function, so
we move the comment there instead.
These constants are no longer used in the code and can be cleaned up

Fixes #574
@codecov
Copy link

codecov bot commented May 13, 2019

Codecov Report

Merging #580 into master will decrease coverage by 0.62%.
The diff coverage is 41.56%.

@@            Coverage Diff             @@
##           master     #580      +/-   ##
==========================================
- Coverage   64.58%   63.96%   -0.63%     
==========================================
  Files          63       63              
  Lines        5647     5708      +61     
==========================================
+ Hits         3647     3651       +4     
- Misses       2000     2057      +57

@hardbyte hardbyte requested review from felixdivo and christiansandberg and removed request for felixdivo May 13, 2019 04:41
@felixdivo felixdivo added this to the 3.2 Release milestone May 13, 2019
Copy link
Collaborator

@felixdivo felixdivo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for collecting the changelog!

@hardbyte
Copy link
Owner Author

I've opened issues #584 #585 #586 to address the fact the diff isn't tested to the level we've been aiming for.

@hardbyte hardbyte merged commit d5dd7fe into master May 16, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants