For a project, I am working with libfreenect2 and because I am reading some commands from console I want to hide the messages* that libfreenect2 outputs when the kinect is acquiring data. How could I do that?
*I mean all the messages about skipping data and so on
Google is your friend: https://openkinect.github.io/libfreenect2/group__logging.html
void libfreenect2::setGlobalLogger ( Logger * logger )
Set the logger for all log output in this library.
Parameters
logger Pointer to your logger, or NULL to disable logging. The memory will be freed automatically. You should not free the pointer.
So just use libfreenect2::setGlobalLogger(NULL);
Another way, that also works if you don't have direct access to the API (e.g. when using the OpenNI2 driver), is to set the LIBFREENECT2_LOGGER_LEVEL environment variable.
Possible values are:
None
Error
Warning
Info
Debug
Related
I'm using XML to configure log4cxx. The appender is a RollingFileAppender that outputs to a folder like yyyy/MM/dd/HHmm, and I need to know what that folder is at the end of the program.
I can't get the current yyyy/MM/dd/HHmm at runtime because that value will likely be different than it was when the log directory was created. After scanning log4cxx's documentation, I found only one function that was relevant:
log4cxx::FileAppender::getFile()
which returns the file that an appender is logging to.
The problem with that is that calls to log4cxx::Logger::getAppender() yield only AppenderPtrs- I could dynamic_cast this into a FileAppender if I know that's the ultimate type, but this introduces uncertainty into the program. Is there really no way to get the current log directory from log4cxx?
Thanks!
There is currently no(easy) way to get the name of the file that the RollingFileAppender is using.
Using Logger::getAppender() is the best way to get the correct appender that you are looking for. Since the appenders should all have unique names, there shouldn't be any issue with casting to the correct type. If you want to be safe about casting, use log4cxx::cast<FileAppender>( AppenderPtr ) which will return an invalid pointer if the object is unable to be casted to the correct type.
I need to turn off the spdlog level before some code then return it to the previous value after.
How do I get the current level before turning it off?
To get current level of logger use logger::level().
To set new level use logger::set_level().
Scenario 1: User-constructed logger
If you have a spdlog::logger object you're using (say, my_logger), then:
You can obtain the level with: my_logger.level().
If you just want to know whether a certain-level message would be logged, then use my_logger.should_log(some_level) where some_level could be, for example spdlog::level::debug.
Scenario 2: The global logger
Now suppose you're using the global logger (e.g. you emit log messages using spdlog::info(), spdlog::error() and such).
spdlog version 1.8.0 and later
You can obtain the global log level with a call to spdlog::get_level() (which is a freestanding function, not a method).
spdlog versions before 1.8.0
You need to get your hand on the implicit logger object - by callingspdlog::default_logger_raw() (it gets you a pointer.) Now just proceed as in Scenario 1 above.
There seems now to be a function to get the global logging level:
spdlog::get_level();
I have the following statements:
static Logging::Logger* common_logger = new Logging::Logger(Logging::Logger::LEVEL);
In the Logger.h i have
class Logger {
public:
enum LEVEL {
Debug,
Warning,
Notification,
Error
};
}
I have included the file Logger.h inside my another class as :
Logging::log(CustomDialog::logger, Logging::Entry, CustomDialog::CLASSNAME, "CustomDialog");
I need to know if this is the right way to do the reason why i am doing this is to get logs based upon the level.
Regards,
Take a look at Log4cxx - it's easy to use and contains just about every feature you might want in a logging framework for C++. It's extensible, it can be configured through configuration files, and it even supports remote logging out of the box.
You can use ACE_DEBUG, it seems old-school (ala printf) but thread-safe, reliable and fully configurable (use logfiles, stdout etc..) You'll have to link against libACE(Adaptive Communication Framework) of course, but it's development packages are easily available in many linux distros per default nowadays. I've been looking over the list from that C++ logging libraries post, mentioned by Als, but it seems most people are running into mem leaks with many of the frameworks and boost::Log is not out yet.
Another point is that most logging libraries using streams, for example like this:
// from thread 1
mlog(mlog::DEBUG) << "Debug message goes here" << mlog::endl;
// from thread 2
mlog(mlog::INFO) << "Info message goes here" << mlog::endl;
will not work as expected in a multithreaded environment, while ACE will perform correctly there.
The output of the above will look something like this:
[thread1 | 12:04.23] Debug me[thread2 | 12:04.24] Info message goesssage goes herehere
At my server, we receive Self Described Messages (as defined here... which btw wasn't all that easy as there aren't any 'good' examples of this in c++).
At this point I am having no issue creating messages from these self-described ones. I can take the FileDescriptorSet, go through each FileDescriptorProto, adding each to a DescriptorPool (using BuildFile, which also gives me every defined FileDescriptor).
From here I can create any of the messages which were defined in the FileDescriptorSet with a DynamicMessageFactory instanced with the DP and calling GetPrototype (which is very easy to do as our SelfDescribedMessage required the messages full_name() and thus we can call the FindMessageTypeByName method of the DP, giving us the properly encoded Message Prototype).
The question is how can I take each already defined Descriptor or message and dynamically BUILD a 'master' message that contains all of the defined messages as nested messages. This would primarily be used for saving the current state of the messages. Currently we're handling this by just instancing a type of each message in the server(to keep a central state across different programs). But when we want to 'save off' the current state, we're forced to stream them to disk as defined here. They're streamed one message at a time (with a size prefix). We'd like to have ONE message (one to rule them all) instead of the steady stream of separate messages. This can be used for other things once it is worked out (network based shared state with optimized and easy serialization)
Since we already have the cross-linked and defined Descriptors, one would think there would be an easy way to build 'new' messages from those already defined ones. So far the solution has alluded us. We've tried creating our own DescriptorProto and adding new fields of the type from our already defined Descriptors but got lost (haven't deep dived into this one yet). We've also looked at possibly adding them as extensions (unknown at this time how to do so). Do we need to create our own DescriptorDatabase (also unknown at this time how to do so)?
Any insights?
Linked example source on BitBucket.
Hopefully this explanation will help.
I am attempting to dynamically build a Message from a set of already defined Messages. The set of already defined messages are created by using the "self-described" method explained(briefly) in the official c++ protobuf tutorial (i.e. these messages not available in compiled form). This newly defined message will need to be created at runtime.
Have tried using the straight Descriptors for each message and attempted to build a FileDescriptorProto. Have tried looking at the DatabaseDescriptor methods. Both with no luck. Currently attempting to add these defined messages as an extension to another message (even tho at compile time those defined messages, and their 'descriptor-set' were not classified as extending anything) which is where the example code starts.
you need a protobuf::DynamicMessageFactory:
{
using namespace google;
protobuf::DynamicMessageFactory dmf;
protobuf::Message* actual_msg = dmf.GetPrototype(some_desc)->New();
const protobuf::Reflection* refl = actual_msg->GetReflection();
const protobuf::FieldDescriptor* fd = trip_desc->FindFieldByName("someField");
refl->SetString(actual_msg, fd, "whee");
...
cout << actual_msg->DebugString() << endl;
}
I was able to solve this problem by dynamically creating a .proto file and loading it with an Importer.
The only requirement is for each client to either send across its proto file (only needed at init... not during full execution). The server then saves each proto file to a temp directory. An alternative if possible is to just point the server to a central location that holds all of the needed proto files.
This was done by first using a DiskSourceTree to map actual path locations to in program virtual ones. Then building the .proto file to import every proto file that was sent across AND define an optional field in a 'master message'.
After the master.proto has been saved to disk, i Import it with the Importer. Now using the Importers DescriptorPool and a DynamicMessageFactory, I'm able to reliably generate the whole message under one message. I will be putting an example of what I am describing up later on tonight or tomorrow.
If anyone has any suggestions on how to make this process better or how to do it different, please say so.
I will be leaving this question unanswered up until the bounty is about to expire just in case someone else has a better solution.
What about serializing all the messages into strings, and making the master message a sequence of (byte) strings, a la
message MessageSet
{
required FileDescriptorSet proto_files = 1;
repeated bytes serialized_sub_message = 2;
}
I'm new to MFC, once I create my first app, in myApp::InitInstance() . I have
SetRegistryKey(_T("Local AppWizard-Generated Applications"));
Can I delete this and save settings to my own ini construct ?
Edit: After further testing, the solution below does not work if your app class is derived from CWinAppEx ! It does work if your app is directly derived from CWinApp.
To store values in an .ini file instead of the registry:
Omit the call to SetRegistryKey.
In your app class, set m_pszProfileName to the full path of your .ini file. The filename string must be allocated using malloc, because the framework will call free on it when your app shuts down. First free the existing value, then assign your new string:
free((void*)m_pszProfileName);
m_pszProfileName = ::_tcsdup(_T("C:\\somedir\\myini.ini"));
Call CWinApp::GetProfileInt, CWinApp::WriteProfileInt and similar functions as usual.
I strongly recommend using a path under APPDATA for storing your .ini file.
Yes you can. CWinApp::SetProfileXXX() does this for you, actually - but I wouldn't use these methods anymore in 2010, they were OK when ppl moved from .ini to the registry.
I am not sure if this is possible as a .ini file has only strings for your program. You can create an operating system script (.bat for windows, .sh for unix etc) and call it using system() call.
Use win32 APIs WriteProfileString (write to INI file) and GetProfileString (read from INI file)
For more help
ms-help://MS.MSDNQTR.v90.en/sysinfo/base/writeprofilestring.htm