abumq / easyloggingpp Goto Github PK

Feature does "pretty much" like:

explicit Configurations(const std::string& configurationFile_, const Configurations& base_) {
    std::for_each(base_.list().begin(), base_.list().end(), set);
    parseFromFile(configurationFile_);
}

For this we need to add overloaded set that takes internal::Configuration*

Currently all logs are written in one file. Add support for logs to be written in different files, e.g, my_app_errors.log my_app_info.log. THIS SHOULD BE AN EXTRA FEATURE AND SHOULD NOT AFFECT DEVELOPERS WHO PREFER ALL LOGS IN SINGLE FILE.

INFO(..), DEBUG(..) etc, are too generalized and sometimes cause issue for example in xcode DEBUG macro is defined when debugging causing warnings to turn up

Rename log names with preceeding L (for log), new levels will be called

LINFO, LDEBUG ... etc

For users using newer version of easylogging++ and want to use older way of log names, they may define _SUPPORT_LEGACY_LOG_NAMES to use them

Currently logs are formatted like following
[TYPE] [DATE/TIME] [FUNCTION] [LOCATION] MESSAGE

Provide ability as constant called LOG_FORMAT that is used to format log

• %t : TYPE
• %d : DATE/TIME
• %f : FUNCTION
• %l : LOCATION / FILE, LINE
• %m : LOG MESSAGE

As an example currently logs are displayed as:
const std::string LOG_FORMAT = "[%t] [%d] [%f] [%l] %m";
but this needs to be implemented

Introduce new log level called QA that is only logged when _QUALITY_ASSURANCE is defined. This has format, _ENABLE_QA_LOGS but not _DISABLE_QA_LOGS

Test everything for _WIN32 and _WIN64 in windows machine including:

• Computer name
• Username
• Date/Time
• Make directory
• Log with colouring [shouldn't be coloured]

g++ supports func but preferably we will use PRETTY_FUNCTION to make it easier b/w overloaded functions
apparently VC++ supports FUNCTION but we need to confirm this
investigate the other compilers and use that.

Additionally,
if we use #ifndef __func__ this always compiles that shouldn't be the case in g++ !

Issue has been reported for configuration file. User get Bad file []

Current work around is to use Configurations class in main class and set all the loggers conf to whats needed

   easyloggingpp::Configurations logConf;   // Load default conf
   //easyloggingpp::Configurations logConf("/data/internal_apps/ops_toolkit/src/configs/log.conf"); // Does not work!
   logConf.set(easyloggingpp::Level::ELPP_DEBUG, easyloggingpp::ConfigurationType::ELPP_ToStandardOutput, "false");         // Do not output debug logs, just save them to file!
   logConf.setAll(easyloggingpp::ConfigurationType::ELPP_Filename, "/data/internal_apps/ops_toolkit/build/logs/ops_toolkit.log");  // Save all logs to same file
   easyloggingpp::Loggers::resetAllLoggersConfigurations(logConf);    // Reset all loggers to same configuration
   // We need different logging conditions for trivial logger - condition different from other logger is format for each level does not have "logger ID" in it
   logConf.parseFromText(easyloggingpp::internal::registeredLoggers->constants()->DEFAULT_LOGGER_CONFIGURATION);  // Get log from default configurations (as specified in easylogging++.h)
   logConf.setAll(easyloggingpp::ConfigurationType::ELPP_Filename, "/data/internal_apps/ops_toolkit/build/logs/ops_toolkit.log");  // Set logger conf
   easyloggingpp::Loggers::reConfigureLogger(easyloggingpp::Loggers::trivialLogger(), logConf);  // Reconfigure logger

Easylogging++ needs to have an a dedicated log monitor dedicated to read easylogging++ logs.

Down the track we can integrate newly written parser for logs (a seperate library that needs to be written for parsing) to write plugins for IDE's such as VS and eclipse.

Following need to be considered to understand format; conf, global conf, headers and any inline declarations

This will be in repo/tools/el-monitor

We need to test easylogging++ (and fix any issues that comes on the way) to test in following platforms / compilers:

• Visual C++ 9.0 (2008)
• Visual C++ 10.0 (2010)
• Visual C++ 11.0 (2012)
• GNU C++ Compiler
• Windows 7 (64-bit)
• Windows 8 (64-bit)
• Ubuntu (32-bit and 64-bit) (g++ 4.7)
• Linux Mint (64-bit) (g++ 4.7)
• Scientific Linux 6.2 (g++ 4.4.6)

Ditch either linked or full version away, its causing unnecessary redundancy

Currently all the loggings are using normal 1-level or conditional logs,

write enhancements to support verbose level loggings.

We can do this by having a macro check to start logging, macro called:
_SUPPORT_EASYLOGGINGPP_
and that SHOULD be defined in main(..) function in C++ application in order to support verbose (and other parameter specific if applicable in future) type logging for current application.

Verbose logging macros should be:
VLOG(level, logMessage)
VLOG_IF(level, logMessage)
and parameters should be:
--v=1 etc,

Log types already injected will be

• TrivialLogger
• BusinessLogger
• SecurityLogger

format specifier is %type

This is injectable by #29

STATUS and HINT levels are useless, ditch them away

Issue has been reported by Les who uses Windows and is having his log file not rolling out after reaching the size.

I have changed this feature to beta mode until every test is completed

Default log file should either wait for configurations to be setup or create it on first logging. even if user has his own configurations, default log file would be created anyway (even though its empty).

Also we should change default log file to /tmp/logs/myeasylog.log

Currently we write log message inside parenthesis, we need to change this behaviour by using something from INFO(... << ...) to INFO << .. << ..

add support for

• std::deque
• __gnu_cxx::slist GNUC
• std::set
• std::multiset
• std::multimap
• __gnu_cxx::hash_map GNUC
• __gnu_cxx::hash_multimap GNUC

Log format is customizable but date formats are static. It would be great to have a custom date format;

Original request from Marco:

it would be nice to be allowed to specify the date format, maybe with the same format recognized by strftime.

I found an issue in when executing on windows (Windows Server 2008 R2, to be exact). In this function:

Line 226, in the function:

static inline std::string getDateTime(void)

The time_t currTime is never initialized, resulting in null being returned for localtime(), and then an assertion in strftime() since the timeInfo will be null.

To fix, the variable currTime must be initialized, as illustrated below. Note the call to time() in the line after the declaration of currTime:

static inline std::string getDateTime(void) {
  if (!(::easyloggingpp::showDateTime || ::easyloggingpp::showDate || ::easyloggingpp::showTime)) return "";
#if _WINDOWS
    time_t currTime;
    time(&currTime);   // *** Added by codyzu ***
#elif _LINUX || _MAC
    timeval currTime;
    gettimeofday(&currTime, NULL);
    int milliSeconds = 0;
    if ((::easyloggingpp::showDateTime) || (::easyloggingpp::showTime)) {
      milliSeconds = currTime.tv_usec / 1000;
    }
#endif //_WINDOWS
    struct tm * timeInfo;
#if _WINDOWS
    timeInfo = localtime(&currTime);
#elif _LINUX || _MAC
    timeInfo = localtime(&currTime.tv_sec);
#endif //_WINDOWS
    strftime(::easyloggingpp::dateBuffer, ::easyloggingpp::kDateBufferSize, ::easyloggingpp::dateFormat, timeInfo);
#if _LINUX || _MAC
    if ((::easyloggingpp::showDateTime) || (::easyloggingpp::showTime)) {
      sprintf(::easyloggingpp::dateBuffer, "%s.%d", ::easyloggingpp::dateBuffer, milliSeconds);
    }
#endif //_LINUX || _MAC
  return std::string(::easyloggingpp::dateBuffer);
}

I found the solution in the example code on MSDN for localtime().

• Review whole code, re-write from scratch to improve performance
• Provide more features
• Support legacy names

if you have _END_EASYLOGGINGPP in the middle of application and have _ALWAYS_CLEAN_LOGS defined, it cleans out all the logs every time we re-log something after _END_EASYLOGGINGPP

For example:

 int sum(int a, int b) {
   INFO("Adding " << a << " and " << b);
   _END_EASYLOGGINGPP
   return a+b;
 }
 int main() {
   sum(1,2);
   INFO("..."); // this will clean the logs (if compiled using `-D _ALWAYS_CLEAN_LOGS`) since we have `END_EASYLOGGINGPP` in sum(..)
   _END_EASYLOGGINGPP
 }

FUNC(int, main, (int argc, char** argv))

   _END_EASYLOGGING
END_FUNC(0)

because END_FUNC macro logs performance of function so the logs are cleaned out (because of preceeding _END_EASYLOGGINGPP)

Currently build fails in Qt5 because of some API changes mentioned in QtDoc.

• QBool not available anymore - have check for Qt5 and remove it during pre-processing
• QChar does not have toAscii() anymore - use toLatin1()

Currently, debugging is set by developer (using _ENABLE_DEBUG_LOGS) and doesn't identify if really 'Debugging' using gdb or IDEs.

Make this real. Use _ENABLE_DEBUG_LOGS value something like (in line 175 [https://github.com/mkhan3189/EasyLoggingPP/blob/master/easylogging%2B%2B.h#L175 ]):

#define _DEBUG_LOG   (defined(_DEBUG) /* VS */  || defined(/* gdb debug macro */)) &&   (defined(_ENABLE_DEBUG_LOGS) && !defined(_DISABLE_DEBUG_LOGS)) /* for enable */

Currently ROLL OUT feature works like all or none, we need to change that behaviour.

This will also help Les to help improve

it works ONLY with default configuration.
if you point to the config file or you do any manipulation around ELPP_RollOutSize something like (and id doesn't matter what value you use)
    easyloggingpp::Configurations defaultConf;
    defaultConf.setToDefault();
    defaultConf.set(easyloggingpp::Level::ELPP_ALL, easyloggingpp::ConfigurationType::ELPP_ToStandardOutput, "false");
    defaultConf.set(easyloggingpp::Level::ELPP_ALL, easyloggingpp::ConfigurationType::ELPP_RollOutSize, "0");
    easyloggingpp::Loggers::reconfigureAllLoggers(defaultConf);

is GPF in 
void parse(const Configurations& configurations_)
       case ConfigurationType::ELPP_RollOutSize:
(...)
             } while (i <= it->first); 

Add support for logging conditionally as well as interval by using something like:

LINFO_IF_EVERY_N(condition_, interval_) << " log message";

Every time changes to EasyLogging++ are made, update.sh becomes unstable, this is because of finding / grepping commands used within update.sh script. We need to make it more stable so that this doesn't affect upcoming versions

For any application, the very first log does not get written to file.

All subsequent logs do get written. First log do get displayed to standard output though

Disabling loggings shouldnt affect code using SUB and FUNC macro

Original request from Marco:

I think that by ELPP_MillisecondsLength you actually mean ELPP_MillisecondsWidth... right? If so, probably better to change the name :-)

I agree with Marco and will be changing this in future release

Check for path and log file existence once. If it doesn't exist, create! This should be done on initialization

Do not iterator through all the elements of containers while logging them,

limit it by defining constant in Logger class

static const unsigned int kContainerMaxLog = 100;

Currently easylogging++ looks for library and uses custom mutex class, need to throw this overheaded process.
This sometimes result in failure (if libs are not available)

Embeed a custom class

There is a bug in logging raw array i.e, logger doesnt go through all the elements

There are too many inlined functions that shouldnt be. E.g, init func has now gotten bigger and shouldnt be as of 2.82
Following changes need to be applied:
Init -> non inline
createLogPath -> non inline
read log -> inline
Add elseif`s instead of if..if..if in WRITE_LOG macro

Username and host should be initialized as char pointer variables

Samples have become quite a big mess, we can clean a lot of them by merging, removing and setting

For example, valgrind_happy.cpp is a removal candidate etc

Once issue #29 is completed, throw PERFORMANCE away as severity level and inject it as log type.

Use PDEBUG for performance tracking

Check to see if compiler is c++0x at minimum and lock shared memory still support c++98 (if threading not avail). Do not use conditions for boost thread.

An append variable for a log would be nice. I don't always want to append to a log file, especially if I'm testing and a bug occurs. I don't really want to see old logs from previous runs.

There is a memory leak when tracking performance, this comes from END_FUNC that re-initialte all the streams to write function performance summary to logs.

Proof

sh build_all.sh && valgrind ./bin/time_tracker.cpp.bin
==19585== Memcheck, a memory error detector
==19585== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==19585== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==19585== Command: ./bin/time_tracker.cpp.bin
==19585== 
[INFO] [26/01/2013 11:38:10.975] Result is 3
==19585== 
==19585== HEAP SUMMARY:
==19585==     in use at exit: 1,417 bytes in 3 blocks
==19585==   total heap usage: 131 allocs, 128 frees, 55,029 bytes allocated
==19585== 
==19585== LEAK SUMMARY:
==19585==    definitely lost: 0 bytes in 0 blocks
==19585==    indirectly lost: 0 bytes in 0 blocks
==19585==      possibly lost: 537 bytes in 1 blocks
==19585==    still reachable: 880 bytes in 2 blocks
==19585==         suppressed: 0 bytes in 0 blocks
==19585== Rerun with --leak-check=full to see details of leaked memory
==19585== 
==19585== For counts of detected and suppressed errors, rerun with: -v
==19585== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2)

Currently logs date/time don't have milliseconds. Include that for logs to be even more useful

To fix this replace _ENABLE_FATAL_LOGS with _FATAL_LOG in line 509 of easylogging++.h

FAQ 2 in FAQs shows an issue that needs design improvement so that when any number of libraries use _INITIALIZE_EASYLOGGINGPP they are not thrown with syntax error or run-time error (seg fault)

Currently Logger class is defined as extern to manage memory properly. We need to come up with a solution so that this behaviour / design does not affect anyone.

Current workaround is that no library should use _INITIALIZE_EASYLOGGINGPP at release mode. Basic idea is to have this used ONCE AND ONLY ONCE per application. Here by application, I mean application that will be used by end user.

Split functions into following namespaces:
::easyloggingpp::internal
Contain functions that are used internally by EasyLogging++
::easyloggingpp::helper
Contain functions that user may used, e.g, readLog()

When program looks like:

int main(int argc, const char** argv) {
  _START_EASYLOGGINGPP(argc, argv)
 ...
}

Compiler has error that says invalid conversion from const char** to char**

Works for:

int main(int argc, char** argv) {
  _START_EASYLOGGINGPP(argc, argv)
 ...
}

Continuation of issue reported by Marco;

Also, again with the same compiler, I get some warnings about uninitialised variables as below:

$ make easylogging-bug
In file included from easylogging-bug.cpp:2:
EasyLoggingPP/easylogging++.h:1249:21: warning: variable
      'currConfig' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized]
                if (isConfig(line)) {
                    ^~~~~~~~~~~~~~
EasyLoggingPP/easylogging++.h:1273:40: note: uninitialized use
      occurs here
                __EASYLOGGINGPP_ASSERT(currConfig != 1010, "Unrecognized configuration [" << currConfigStr...
                                       ^~~~~~~~~~
EasyLoggingPP/easylogging++.h:115:55: note: expanded from macro
      '__EASYLOGGINGPP_ASSERT'
#      define __EASYLOGGINGPP_ASSERT(expr, msg) if (!(expr)) { std::cerr << "EASYLOGGING++ ASSERTION...
                                                      ^
EasyLoggingPP/easylogging++.h:1249:17: note: remove the 'if' if
      its condition is always true
                if (isConfig(line)) {
                ^~~~~~~~~~~~~~~~~~~~
EasyLoggingPP/easylogging++.h:1233:40: note: initialize the
      variable 'currConfig' to silence this warning
                unsigned int currConfig;
                                       ^
                                        = 0

Either Register template must unregister all the registered Class* before assigning list_ to other.list_ or use move semantics but be careful since we need support for C++98 too