Wolf logging macro

Notice: This PR is only about simple wolf logging macro as described below and do not implement any data logging as this topic as to be discussed. A data logging draft class is implemented on branch wolf_data_logging.

Enable logging macro using third-party spdlog (MIT license) :

• WOLF_INFO
• WOLF_WARN
• WOLF_ERROR
• WOLF_DEBUG (enabled only if compiled in debug)
• WOLF_TRACE (which is the same as WOLF_DEBUG_HERE but enabled/disabled at compile time)

Trace logging is enabled/disabled from the src/CMakeLists.txt option

option(_WOLF_TRACE "Enable wolf tracing macro" OFF)

test_wolf_logging.cpp shows the following:

  WOLF_INFO("test info ", 5, " ", 0.123);
  WOLF_WARN("test warn ", 5, " ", 0.123);
  WOLF_ERROR("test error ", 5, " ", 0.123);
  WOLF_TRACE("test trace ", 5, " ", 0.123);
  WOLF_DEBUG("test debug ", 5, " ", 0.123);

Which, full feature enabled, produces :

The log pattern is :
[thread id][hour:min:sec.nanosec][log type] log-content

The TRACE log pattern is :
[thread id][hour:min:sec.nanosec][log type][$file l#$line : $function] log-content

Marked this merge request as a Work In Progress

Set this PR to WIP.
The question is, do we actually want to be able to enable/disable WOLF_DEBUG manually (at run-time) knowing that currently, if debug is disabled, it has an overhead cost of calling a function and testing a boolean ?? A zero cost might be preferable with the counter-part of not being able to manually enable/disable the debug macro. @jsola What do you think ?

Added 1 commit:

• fffcaf17 - add proper trace & set trace color green+bold

Compare with previous version

I think it should be at compile time

Ok make sense. I update this right away.

Added 1 commit:

• b26a4888 - debug macro compile time only

Compare with previous version

Unmarked this merge request as a Work In Progress

PR and description updated

Status changed to merged

Mentioned in commit d4222064

Is your issue similar to this? In problem.cpp:

ProblemPtr Problem::create(FrameStructure _frame_structure)
{
    ProblemPtr p(new Problem(_frame_structure)); // We use `new` and not `make_shared` since the Problem constructor is private and cannot be passes to `make_shared`.
    p->setup();
    return p->shared_from_this();
}

Explanation:

• Problem (in short, P) has three shared_ptr to H, T and M, and each of these has a weak_ptr to P.
• For the sake of a good user API, I want all these pointers to be valid just after creating P.
• At construction time, shared_from_this() does not work
  • Therefore, I cannot link H, T, M to P when I am constructing P:
    • H::problem_ptr = shared_from_this(); does not work!
• Solution: make constructor P() private, and write a factory method P::create() as in the code above
  • New Issue: To construct a ProblemPtr (aka shared_ptr<P>), I cannot use make_shared<P>, because it needs to call P() , and it is private:
    • ProblemPtr p = make_shared<P>(_frame_structure) does not work!
    • Solution: I call the shared_ptr constructor with the new syntax and not the make_shared:
      • ProblemPtr p(new Problem(_frame_structure)); works!

Indeed, only useful for the examples.

If we make other kind of tests, it will also be useful. Usually, we use it for specifying absolute path names to configuration files, most commonly YAML files.

Done option(_WOLF_TRACE "Enable wolf tracing macro" ON) in CMakeLists, and put debug options in 'debug' mode. But no debug info after issuing WOLF_DEBUG(...). What am I doing wrong? I even added option(_WOLF_DEBUG "Enable wolf debugging macro" ON), but no luck either.

You need to compile in debug to have the debug macro enabled. If you did then maybe cmake is referring to a cmake cache file rather than the actual cmakelists. You can delete the build directory and build from scratch to make sure. If after all that there is still nothing then we will check tomorrow.

OK. Now it does this. This is the end of a main() in a test:

    [...]

    problem->print();

    WOLF_DEBUG("hola ", 1, " nanu " , 2)

    return 0;
}

and this is the outcome of the DEBUG macro, surrounded by previous and posterior couts:

  F7
    Estim, ts=4,	 x = ( -1.7e-17 0        6.3     )
    C13 -> S1
Map
-----------------------------------------

[36m[4260977924346863084][23:54:57.933986000][debug] hola 1 nanu 2
[00mdestructed -P
destructed -M
destructed -T
destructed   -F7

It seems that

• some weird initial character is bing printed
• there is some weird info being printed
• a final endl is missing.

FYI: I am on my Mac. Should try on Ubuntu and see if these oddities are consistent there.

No hurry for this though.