8000 Handle error frame messages in CanutilsLogWriter and CanutilsLogReader. by hardbyte · Pull Request #255 · hardbyte/python-can · GitHub
[go: up one dir, main page]

Skip to content

Handle error frame messages in CanutilsLogWriter and CanutilsLogReader.#255

Merged
felixdivo merged 61 commits intodevelopfrom
fix-217
Apr 8, 2018
Merged

Handle error frame messages in CanutilsLogWriter and CanutilsLogReader.#255
felixdivo merged 61 commits intodevelopfrom
fix-217

Conversation

@hardbyte
Copy link
Owner

Closes #217 (cherry picked from commit 61f27e1)

Replaces #247

@hardbyte hardbyte mentioned this pull request Feb 17, 2018
@hardbyte hardbyte added this to the 2.2 Release milestone Feb 17, 2018
@felixdivo
Copy link
Collaborator

Oh no, this seems to be a problem with timestamps again ...
I will have a look at it as soon as I can, which might be a few days from now.

@felixdivo
Copy link
Collaborator

Oh wow, now the tests pass. ^^ I will still patch it to not occur again if there is still a problem ...

< 8000 input type="hidden" name="disable_live_updates" value="false" data-targets="batch-deferred-content.inputs" autocomplete="off" />
@felixdivo
Copy link
Collaborator

Okay, so as I understand it, the tests above fail (and should always fail) because of a legitimate reason. The problem resides in can.io.asc.py :: ASCWriter.log_event(...). Link. When a message with timestamp=None is fed to on_message_received (which calls log_event), the current time.time() is written to the file in the line above. All other reader / writer pairs would write zero in that case, which makes more sense for me. So in order to make it consistent with the others, I changed it to not "cleverly" take the current timestamp, but rather write a plain zero. It that okay?

Copy link
Collaborator
@christiansandberg christiansandberg left a comment

Choose a reason for hiding this comment

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

Sorry, there were too many unrelated changes so I only got half way through. Could you clean this up a little and focus on error frames?

@@ -1,9 +1,13 @@
#!/usr/bin/env python
# coding: utf-8
Copy link
Collaborator

Choose a reason for hiding this comment

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

The shebang is only useful if the file can be executed as a script. Most files here are modules so it doesn't add any value.

I don't think there are any non-ASCII characters in these files so the UTF-8 should not be needed either. Besides, UTF-8 is default in Python 3.

Copy link
Collaborator

Choose a reason for hiding this comment

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

These changes originate from a different PR that this one was rebased on, since it required changes that were made over there. That is also the reason for why there are so many file that were changed.

I think the shebang does add value as it make clear that it is compatible with Python 2 & 3 as well as being uniform. But I guess that's subjective. It doesn't do any harm however.

The coding line does add value as well, since it enforces the same behavior on Python 2 & 3. That is desirable since everything that makes these versions more alike in such manners is welcome for maintainability. It also makes it explicit.


def __init__(self, function, error_code, arguments):
super(IscanError, self).__init__()
#: Status code
Copy link
Collaborator

Choose a reason for hiding this comment

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

Why was this changed? See Sphinx documentation.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Sorry, I misunderstood that. I will revert that.

self.channel_info = channel

bitrate = kwargs.get('bitrate', 500000)
bitrate = kwargs.get('bitrate', can.rc.get('bitrate', 500000))
Copy link
Collaborator

Choose a reason for hiding this comment

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

This should be solved on a higher level instead so that it works for all interfaces.

Copy link
Collaborator

Choose a reason for hiding this comment

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

You are right. I removed it.

@felixdivo
Copy link
Collaborator

@christiansandberg Hey, I think there was a misunderstanding. I wanted to ask if you could comment on my design question above concerning the writers in the can.io.* module. But thank you very much for your review!

@christiansandberg
Copy link
Collaborator

If you could rebase on top of develop it would be easier to find the actual changes.

@felixdivo
Copy link
Collaborator
felixdivo commented Mar 15, 2018

Holy f*ck! That made it worse. I simply rebased on top of develop.

@felixdivo
Copy link
Collaborator

Oh, you can see the actual changes here! I hope that helps ...

can/io/asc.py Outdated
channel = msg.channel if isinstance(msg.channel, int) else self.channel
line = self.LOG_STRING.format(time=timestamp,

line = self.LOG_STRING.format(time=msg.timestamp,
Copy link
Collaborator

Choose a reason for hiding this comment

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

Here is an example of an ASC file. There is not much info on this format but my interpretation is that Begin Triggerblock Mon Mar 7 01:21:51 pm 2005 defines the start of measurement and the timestamps are relative to this time.

@christiansandberg
Copy link
Collaborator

I'm thinking it would be better to wait with writing the header until the first message is received and use that timestamp instead of the current time. This would make the result more reproducible and allow for converting formats in the future.

I still think a log_event call without a timestamp is better off with the last logged timestamp instead of 0 or time.time().

@felixdivo
Copy link
Collaborator
felixdivo commented Mar 17, 2018

I now changed CanutilsLogWriter and ASCWriter to behave more similar in 79d8d38 & d1a6b16. This is how they now behave:

ASCWriter
The measurement starts with the timestamp of the first registered message.
If a message has a timestamp smaller than the previous one (or 0 or None),
it gets assigned the timestamp that was written for the last message.
It the first message does not have a timestamp, it is set to zero.

CanutilsLogWriter
If a message has a timestamp smaller than the previous one (or 0 or None),
it gets assigned the timestamp that was written for the last message.
It the first message does not have a timestamp, it is set to zero.

Shall I merge it like that? The tests all run successfully and the changes can be viewed here.

can/io/asc.py Outdated
if not self.header_written:
self.last_timestamp = (timestamp or 0.0)
self.started = self.last_timestamp
self.log_file.write("Begin Triggerblock %s\n" % self.last_timestamp)
Copy link
Collaborator

Choose a reason for hiding this comment

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

Timestamp should be converted to the format "%a %b %m %I:%M:%S %p %Y".

@felixdivo
Copy link
Collaborator

I also added base hex timestamps absolute\n to the header of each ASC file, like over here.

@felixdivo felixdivo dismissed christiansandberg’s stale review April 2, 2018 10:35

won't change; was discussed in another PR

in the resulting file. The locations as selected randomly
but deterministically, which makes the test reproducible.
:param bool round_timestamps: if True, rounds timestamps using :meth:`~builtin.round`
before comparing the read messages/events
Copy link
Collaborator

Choose a reason for hiding this comment

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

Maybe it's better to specify number of decimal places to match against? ASC files only store 4 decimals currently.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Well, I think the problem comes from the timestamps being relative to the start of the measurement, but that start timestamp is being serialized without sub-second precision. One failing test case failed because of something like 1000000.197 != 1000000.2. So I guess rounding is more appropriate in the case of ASC files.

Copy link
Collaborator

Choose a reason for hiding this comment

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

@christiansandberg Do you agree with that? Shall we merge it?

Copy link
Collaborator

Choose a reason for hiding this comment

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

Right, didn’t think of that. Go ahead and merge.

@felixdivo felixdivo merged commit 73889eb into develop Apr 8, 2018
@felixdivo felixdivo deleted the fix-217 branch April 8, 2018 18:58
@felixdivo felixdivo mentioned this pull request Jul 28, 2018
@christiansandberg christiansandberg mentioned this pull request Sep 20, 2018
2 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants

0