Skip to content
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

Make use of time source type for throttling logs #183

Merged
merged 6 commits into from
Oct 21, 2019

Conversation

BMarchi
Copy link
Contributor

@BMarchi BMarchi commented Oct 1, 2019

Part of 797. Gives meaning to the time_source_type argument to throttle macros.

  • Linux Build Status
  • Arch Build Status
  • Windows Build Status
  • OSX Build Status

Signed-off-by: Brian Ezequiel Marchi <brian.marchi65@gmail.com>
@@ -154,7 +154,7 @@ TEST_F(TestLoggingMacros, test_logging_throttle) {
auto is_before_throttle_end =
((std::chrono::system_clock::now() - start) < throttle_time);
RCUTILS_LOG_ERROR_THROTTLE(
RCUTILS_STEADY_TIME, throttle_time.count(), first ? "first" : "other");
rcutils_steady_time_now, throttle_time.count(), first ? "first" : "other");
Copy link
Contributor

@hidmic hidmic Oct 1, 2019

Choose a reason for hiding this comment

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

@BMarchi nit: why not keeping the function behind the macro? RCUTILS_STEADY_TIME reads better.

@@ -54,7 +54,8 @@
skipfirst_doc_lines = [
'The first log call is being ignored but all subsequent calls are being processed.']
throttle_params = OrderedDict((
('time_source_type', 'The time source type of the time to be used'),
('time_source_type', 'Function that returns rcutils_ret_t and expects a '
'rcutils_time_point_value_t pointer.'),
Copy link
Contributor

Choose a reason for hiding this comment

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

@BMarchi nit: I wonder if time_source makes more sense than time_source_type. @dirk-thomas thoughts?

Copy link
Member

Choose a reason for hiding this comment

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

Well, "time source" has a very specific meaning in rclcpp and since this is not the same I would avoid using the same term for it. See my other comment for a suggestion.

Copy link
Contributor Author

@BMarchi BMarchi Oct 3, 2019

Choose a reason for hiding this comment

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

So should I call it then get_time_point_value?

@@ -54,7 +54,8 @@
skipfirst_doc_lines = [
'The first log call is being ignored but all subsequent calls are being processed.']
throttle_params = OrderedDict((
('time_source_type', 'The time source type of the time to be used'),
('time_source_type', 'Function that returns rcutils_ret_t and expects a '
Copy link
Member

Choose a reason for hiding this comment

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

How about renaming this parameter to match the new semantic, e.g. get_time_point_value?

Copy link
Contributor

Choose a reason for hiding this comment

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

That goes against #183 (comment). Do we want to be explicit about the parameter being a function or do we want to hide it for the sake of API ergonomics? I'm slightly inclined towards the latter but it's not a strong stand.

Copy link
Member

Choose a reason for hiding this comment

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

The function parameter is being used as a function:

if (time_source_type(&__rcutils_logging_now) != RCUTILS_RET_OK) {

There is no way you can just pass RCUTILS_STEADY_TIME (assuming it isn't a macro defining a function).

Copy link
Contributor

Choose a reason for hiding this comment

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

That's precisely what I'm proposing, an alias for that function so that it reads better. But it's a detail and orthogonal to the actual macro parameter name.

Copy link
Contributor

Choose a reason for hiding this comment

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

And that's what @BMarchi implemented in e1b4344. WDYT @dirk-thomas ?

Copy link
Member

Choose a reason for hiding this comment

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

My previous comment still applies: it is not a time source so it should not be named time_source imo.

Signed-off-by: Brian Ezequiel Marchi <brian.marchi65@gmail.com>
…mbinations

Signed-off-by: Brian Ezequiel Marchi <brian.marchi65@gmail.com>
Signed-off-by: Brian Ezequiel Marchi <brian.marchi65@gmail.com>
@@ -168,7 +169,7 @@ def __init__(self, *, params=None, args=None, doc_lines=None):
}, **name_args
},
doc_lines=skipfirst_doc_lines + throttle_doc_lines + name_doc_lines)),
))
))
Copy link
Member

Choose a reason for hiding this comment

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

This looks like an unrelated and unnecessary change?

Signed-off-by: Brian Ezequiel Marchi <brian.marchi65@gmail.com>
Copy link
Contributor

@hidmic hidmic left a comment

Choose a reason for hiding this comment

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

LGTM pending green CI

@@ -39,6 +39,8 @@ extern "C"
#define RCUTILS_NS_TO_MS(nanoseconds) (nanoseconds / (1000LL * 1000LL))
/// Convenience macro to convert nanoseconds to microseconds.
#define RCUTILS_NS_TO_US(nanoseconds) (nanoseconds / 1000LL)
/// Convenience macro to reference the function for system time.
Copy link
Contributor

Choose a reason for hiding this comment

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

@BMarchi nit: ref that function

Signed-off-by: Brian Ezequiel Marchi <brian.marchi65@gmail.com>
@mabelzhang mabelzhang added the enhancement New feature or request label Oct 17, 2019
@BMarchi BMarchi merged commit e7eb74c into master Oct 21, 2019
@delete-merged-branch delete-merged-branch bot deleted the BMarchi/enable_throttling_logs branch October 21, 2019 21:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants