Renaming endl to RESTendl and other loggers functions

[juanangp]

This PR try to address the misleading use of custom endl and renames the different custom logger functions:

• Renamed custom endl to RESTendl. Note that we have 2 different ´RESTendl´. endl_t RESTendl inside TRestMetadata and static RESTendl inside TRestStringOuput. However, the implementation has not been changed.
• Renamed other logger functions
  • info --> RESTInfo
  • debug --> RESTDebug
  • essential --> RESTEssential
  • warning --> RESTWarning
  • fout --> RESTcout
  • ferr --> RESTError
• Added REST_Verbose_Level enum inside TRestStringOuput class, now verbosity is written as TRestStringOutput::REST_Verbose_Level::REST_XXXX.
• Added REST_Display_Orientation enum inside TRestStringOuput.h
• Removal of extern functions from startup.cpp now the custom loggers are defined as static functions inside TRestStringOuput.h
• Removal of define COLOR_XXX inside TRestStringOuput.h, using constexpr const char* const COLOR_ instead.

Related PR:

• Renaming endl to RESTendl and other loggers functions detectorlib#49
• Renaming endl to RESTendl and other loggers functions geant4lib#49
• Renaming endl to RESTendl and other logger functions rawlib#63
• Renaming endl to RESTendl and other logger functions tracklib#17
• Renaming endl to RESTendl and other logger functions connectorslib#13
• Renaming endl to RESTendl and other logger functions axionlib#24
• Renaming endl to RESTendl and other logger functions restG4#47

[jgalan]

what it is doing fout?

Perhaps ferr could just be RESTError?

[juanangp]

what it is doing fout?

I think is standard output with silent verbosity.

Perhaps ferr could just be RESTError?

Yes, perhaps we should have a quorum about this? Currently we have:

• RESTFout verboseLevel >= silent --> RESTCout ?
• RESTFerr verboseLevel >= silent --> RESTError ?
• RESTWarning verboseLevel >= warning
• RESTEssential verboseLevel >= essential == warning --> RESTLog ?
• RESTInfo verboseLevel >= info
• RESTSuccess verboseLevel >= info
• RESTDebug verboseLevel >= debug
• RESTExtreme verboseLevel >= extreme

[jgalan]

Ok, I updated RESTFerr because it was kind of obvious when comparing with RESTWarning.

I agree with RESTCout but not sure about RESTLog because this is connected to a verboseLevel="essential" parameter and corresponding output level.

[juanangp]

Ok, I updated RESTFerr because it was kind of obvious when comparing with RESTWarning.

I agree with RESTCout but not sure about RESTLog because this is connected to a verboseLevel="essential" parameter and corresponding output level.

OK, I can change that btw, do you prefer RESTCout or RESTcout without capital letter.

[lobis]

I think maybe it would be better to use a namespace for the logger methods i.e. logger::info instead of RESTInfo. What do you think?

Also I think the logger needs a bit of a rework (on a future PR), some of the things I would modify:

Stop using cout like interface for logging messages, use something like https://github.com/fmtlib/fmt instead (probably its alerady packed into root?).

This would allows us, among many things, to define custom formatting for things such as TVector3 or even REST classes so that we can "just print them", reducing significantly the code.

Use https://github.com/gabime/spdlog as the logging library and build a logger on top of it, instead of implementing it from scratch, which has many nice features including https://github.com/gabime/spdlog#backtrace-support

[juanangp]

I think maybe it would be better to use a namespace for the logger methods i.e. logger::info instead of RESTInfo. What do you think?

I think we should use namespaces when the definition of some variables might be misleading, that's why I renamed info to RESTInfo , so now it is clear that this function belongs to REST. Perhaps we should implement a generic namespace REST, then would be trivial to do REST::info, or perhaps REST::logger::info. Since, we are not using many namespaces in the code I don't see the advantage. Also, we should avoid the use of using namespace xxx because it invalidates the first statement, but this is a different topic.

Also I think the logger needs a bit of a rework (on a future PR), some of the things I would modify:

The main issue is that we are using the same implementation for different features, we have the TRestStringOutput logic implemented in TRestMetadata with the verbosity of a particular metadata class using the input in the rml file. Moreover, some errors and warnings are logged inside the TRestMetadata and stored inside the root file. I think is difficult to keep this feature without changing the code design, but we can think of better way to perform the logging.