Comments (15)
Currently running YARP 3.4 on TEO (https://github.com/roboticslab-uc3m/teo-hardware-issues/issues/58) with the new logging system and fancy colors enabled (roboticslab-uc3m/teo-developer-manual@89c44dc).
Edit: rolled back to YARP 3.3 due to lack of Python 2 support.
from questions-and-answers.
from questions-and-answers.
As soon as YARP 3.5 is released, I'm going to gradually drop support for YARP 3.3 and require 3.4, introducing logging components in our repositories.
Done. Component names start with rl
and reflect the main class of the library (or the library name itself), device or program, e.g. rl.YarpCloudUtils
, rl.KdlSolver
, rl.DumpCanBus
. Components are declared and defined in their own .hpp/.cpp pair of files, then added to CMakeLists.txt (example). If only used in a single translation unit, they can be placed in an anonymous namespace and defined via YARP_LOG_COMPONENT
(example).
from questions-and-answers.
YARP's logging system is undergoing a major overhaul. New features include fine-grained component-based tagging, and a lot more information accompanying each log event. See robotology/yarp#2256 and linked dependent tickets. Also, robotology/yarp#2258 contains a nice screenshot of new yarplogger in action.
I'm a bit concerned about performance and the lack of Windows support (we can take advantage of previous experience on color-debug and submit a patch, though; see roboticslab-uc3m/color-debug#5), but this is really cool.
Implemented in YARP 3.3.x, see robotology/yarp#2076.
from questions-and-answers.
YARP's logging system is undergoing a major overhaul.
This is nicely documented in http://www.yarp.it/yarp_logging.html (source).
from questions-and-answers.
Color-debug is officially dead in most of roboticslab-uc3m (search) and in all asrob-uc3m repos (search). Leftovers:
- https://github.com/roboticslab-uc3m/WBPCwaiter (PhD thesis-related): demo-like repo
̶-̶ ̶h̶t̶t̶p̶s̶:̶/̶/̶g̶i̶t̶h̶u̶b̶.̶c̶o̶m̶/̶r̶o̶b̶o̶t̶i̶c̶s̶l̶a̶b̶-̶u̶c̶3̶m̶/̶t̶e̶o̶-̶b̶l̶e̶n̶d̶e̶r̶-̶m̶o̶d̶e̶l̶s̶:̶ ̶j̶u̶s̶t̶ ̶i̶n̶ ̶a̶ ̶s̶i̶n̶g̶l̶e̶ ̶C̶+̶+̶ ̶f̶i̶l̶e̶ - https://github.com/roboticslab-uc3m/bullet-yarp-plugins: abandoned?
- https://github.com/roboticslab-uc3m/xgnitive: abandoned?
- https://github.com/roboticslab-uc3m/footsteps: abandoned?
As soon as YARP 3.5 is released, I'm going to gradually drop support for YARP 3.3 and require 3.4, introducing logging components in our repositories. For now, the component-less scheme I followed mostly everywhere is:
yInfo() << "Bla bla bla" << value << "bla bla bla";
- A single sentence.
- Begins with uppercase letter.
- No ending period.
from questions-and-answers.
In view of the forthcoming replacement of color-debug with YARP logging goodies, I'm transferring this issue to a more horizontally focused location.
from questions-and-answers.
Further remarks (see #90 (comment)):
- Logging utilities support "components", i.e. additional tags that help identify the source of a log line. These are placed between the log level and the actual log message, e.g.
[INFO] |yarp.os.Port| Port /bla active...
- Trace lines are dismissed by the compiler unless the project is build in Debug configuration. Besides, they need to be explicitly enabled through an environment variable. In non-verbose mode, trace lines also include the calling method's signature.
- For yarplogger to work, applications must be launched either via
yarprun
(initialized with the--log
parameter) or command line plus an environment variable:- yarprun enables launching apps on remote machines, optionally piping the standard output to an xterm shell. If enabled, any kind of output is forwarded to the logger; this includes YARP logger utilities,
printf
,std::cout
... - For yarplogger to collect application output when launched via command line, the
YARP_FORWARD_LOG_ENABLE
variable needs to be set to1
. This comes at the cost of using another port/thread and so on, and only YARP logger utilities can be piped (no other output is allowed).
- yarprun enables launching apps on remote machines, optionally piping the standard output to an xterm shell. If enabled, any kind of output is forwarded to the logger; this includes YARP logger utilities,
- yarplogger has plenty of funcionalities, you can even unveil the full backtrace of each line if explicitly enabled, along with the absolute path of the source file, line number, calling method, etc.
- The CLI counterpart, yarplogger-console, is mostly an RPC interface for quickly inspecting available log streams and saving logs to file, which is of course also attainable via regular yarplogger.
- Stream macros are slightly less performant than the C-style ones, but also easier to use. For instance, there is an overload for printing a
std::vector
. - We can emulate the old
CD_XXX_NO_HEADER
behavior with stream macros:Although this is an artificial example as the following would also work:std::vector<int> my_vector { 1, 2, 3, 4, 5 }; { auto && _temp = yInfo(); temp << "let's unpack a random vector:"; for (int value : my_vector) _temp << value; _temp << "end"; } // logger prints this before leaving the previous code block: // let's unpack a random vector: 1 2 3 4 5 end
yInfo() << my_vector;
from questions-and-answers.
I have given this a try at roboticslab-uc3m/openrave-yarp-plugins@ea405eb and asrob-uc3m/yarp-devices@c7f717c. Some things to consider:
-
Component names should be expressive, but not too long. I have chosen the schema
namespace.main_class
, much like core YARP does. I refused to add an intermediate term for the repository name (in my initial thoughts, the schema wasgithub_org.github_repo.main_class
) since that would make much longer names. Also, I assume name clashes should not be a thing in our orgs and, if necessary, a device/library/application can either refine its component name a bit or use more than one component. -
Log contents should be inspected one by one to make sure their original intention is preserved. Now, color-debug provides the file name and line number along with the log level and the log message. This filename is not always unique, but we manage to sort things out. At most, and when not in verbose mode, YARP logging utilities can only provide the component name via stdout/stderr. It is therefore a good idea to enhance existing log messages (where deemed convenient) so that they reflect the method or process currently going on.
-
In the light of the thorough review I am anticipating in the previous point, it should be a good idea to check the logic of existing log levels (i.e. is this debug line really debug, or should I promote it to info level, and so on) and whether more log lines should be added. There is one particular case: we abuse
CD_DEBUG
for signalizing method entrance. It might be a good idea to switch toyTrace
here, unless we really need them in Release config. Alternatively, throttling macros could be an option. -
As an additional side quest, search for
std::cout
s andprintf
s that should be morphed into YARP logging macros. Also, make sure there are no newlines in the newly adapted YARP log lines, since those are automatically appended anyway.
from questions-and-answers.
Note the --verbose
option to yarpdev
and several other companion utilities has been superseded by logging components (robotology/yarp#2389 (comment)). This may partially affect the solutions adopted in #49. For instance, but not sure if a feature or a bug, now I can see all debug lines related to device configuration when issuing yarpdev --device EmulatedControlboard --name /fake
, no YARP_VERBOSE=1
environment variable nor --verbose
option involved (the former would additionally bloat the console with lots of comms-related notices). Besides, I need to look into lines such as this: rf.setVerbose(true)
.
from questions-and-answers.
I recall having come across some YARP utilities that understand and handle these logging streams, perhaps yarpdatadumper
or yarpdataplayer
. We can also mention the yarplogger
program, but its documentation is scarce.
A few cons against migrating to YARP's logger:
- No colors (obviously).
- I don't see any option for enabling or disabling specific logging macros (you can control this via CMake with color-debug).
- ...?
Edit: regarding integration within YARP utilities, see robotology/community#206.
from questions-and-answers.
Behold a screenshot of yarplogger
.
from questions-and-answers.
It reminds me of Android's Logcat, which is extremely useful for debugging on Android:
from questions-and-answers.
No colors (obviously).
False, just set the YARP_COLORED_OUTPUT
environment variable. See INFO and DEBUG logs below:
from questions-and-answers.
A few more words about YARP log streams:
- six levels: trace (if
YARP_TRACE_ENABLE=1
), yInfo, yWarning, yDebug (enabled by default, turn off withYARP_DEBUG_ENABLE=0
), yError, yFatal (callsstd::exit
) plus yAssert; see description at robotology/yarp#252 (comment) - supports colors (if
YARP_COLORED_OUTPUT=1
) - verbose output (if
YARP_VERBOSE_OUTPUT=1
) prints full paths and function signatures along with the line number - broadcasts logs via YARP port (if
YARP_FORWARD_LOG_ENABLE=1
oryarplogger
was started) - you can't disable specific log levels on the console
- nice
yarplogger
support, didn't tryyarplogger-console
yet - recommended way of using
yarplogger
is to run apps/devices in ayarprun
node (add--log
); thus, every single output is recorded, whereas theYARP_FORWARD_LOG_ENABLE=1
way is unable to record non-YARP-logger lines - supports two signatures per log level:
yDebug(...)
: much likeprintf(...)
, inserts a newline at the endyDebug() << "value:" << val;
: stream-like format, you can store this in a variable and append more stuff later within the same line of text (rememberCD_DEBUG_NO_HEADER
?)
- both signatures use C++ streams under the hood and call
std::endl
, which automatically flushes the output (we do this by hand in CD) yarplogger
allows you to access logs for specific ports, show them on GUI with timestamps and nice colors (you can disable unwanted log levels), save specific logs to file or the entire log session
I'm a bit concerned about performance and the lack of Windows support (we can take advantage of previous experience on color-debug and submit a patch, though; see roboticslab-uc3m/color-debug#5), but this is really cool. Shall we take this seriously and replace color-debug usage in our repos? Attaching screenshot for science, I made color-debug macros call YARP logger functions for this test:
Relevant sources:
- yarp/os/Log.h (include this if using
yDebug(...)
signature) - yarp/os/LogStream.h (include this if using
yDebug() << ...
signature) - Log.cpp
from questions-and-answers.
Related Issues (20)
- Make dox target via YCM goodies HOT 9
- Unit tests and unsatisfied dependencies lead to compilation failure HOT 1
- Embrace hooks HOT 3
- Bump required YCM version (v0.10+) HOT 4
- YARP 3.0 upgrade path HOT 5
- Update CMake/YCM export options HOT 10
- [GitHub] Git LFS disabled for roboticslab-uc3m HOT 2
- Centralize Travis scripts HOT 4
- Changes to git branch policy in YARP/YCM HOT 8
- Drop dual master-develop branching in favor of a single prod branch HOT 10
- Review installation-related snippets in Markdown docs HOT 1
- Migrate to GitHub Actions HOT 24
- Add C++ examples to main build HOT 7
- Update links to GitBook project instances on legacy servers HOT 3
- Portmonitors renamed at YARP >= 3.5 HOT 1
- Update links pointing at new subdomain HOT 4
- sp_ineachdb and also sp_msforeachDB return only 50 records instead of hundreds HOT 3
- Randomization problems with JsPsych HOT 1
- cards in Thingsboard professional version HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from questions-and-answers.