Project

General

Profile

Feature #23217

make cout destination output fully customizable...

Added by Ron Rechenmacher about 2 months ago. Updated about 1 month ago.

Status:
Under Discussion
Priority:
Normal
Assignee:
-
Target version:
-
Start date:
09/03/2019
Due date:
% Done:

0%

Estimated time:
Duration:

Description

In artdaq_mfextensions, we have created a plugin which allows the user to define the format of the messages using a
simplified printf style format specification. The code allows, for example,
format_string:"%%MSG-%s N: %d %T %r %f:%u\n%m\n%MSG"
to cause messages to be printed out in the default (3-line) format.
It would be nice if this plugin could be incorporated into the base messagefacility as an alternate "cout" destination.
The plugin code can be viewed at:
https://cdcvs.fnal.gov/redmine/projects/mf-extensions/repository/git/revisions/develop/entry/mfextensions/Destinations/OTS_mfPlugin.cc
Note: this code works with message from all the Log* methods. As far as I can tell, the Log{Problem,Print,Verbatim,Trace,...} methods
work with the full filename such that we have added a feature where a configurable portion of the filename will be printed.

History

#1 Updated by Kyle Knoepfel about 2 months ago

  • Status changed from New to Feedback

In what way does the supported 'timestamp' pattern not meed your need? See 'art --print-description mfPlugin:cout' and look for the 'timestamp' parameter.

Also, messagefacility's plugin system is there specifically so users can implement their own destinations, as you have done. Is there a reason why OTS_mfPlugin should become part of the general distribution?

#2 Updated by Ron Rechenmacher about 2 months ago

timestamp formatting is not an issue.
The example OTS_mfPlugin allows complete control over both what_info is printed and what_order the info is printed in.
It allows for the standard 3 line formatting but does not (currently) support automatic line breaks in the message text.
When I configure the OTS_mfPlugin to produce the exact output that the built-in cout type produces, the messages seem to
take 15 to 20% longer. Although I don't have proof, I'm guessing this is b/c of plugin mechanism overhead.
So, IMHO, you should consider including it because of the complete (i.e. better) configuration ability (currently, partial output configurability is provided but it does not seem possible to opt out of printing filename:linenum) along with efficiency gains over the plugin.

#3 Updated by Kyle Knoepfel about 1 month ago

  • Status changed from Feedback to Under Discussion


Also available in: Atom PDF