Normalizing error checking about k2 HOT 11 CLOSED

error.h contains only one function CheckCudaError, I created it when @songmeixu did't committ PR about debug.h, now the whole file can be deleted (I'll do this now).

RE glog, I'm OK with removing glog, but for now, we have no CHECK marocs with printing out messages, e.g. k2_CHECK_EQ() << "message", and Log level mechanism, such as LOG(FATAL)<<, maybe @songmeixu would like to add those code?

from k2.

IE, the debug.h is expected to be used for cuda codes. Where the print msg would be silenced finally for release. Thus it's not for logging, but for debugging (in both DEBUG/NDEBUG mode, as K2_PARANOID_ASSERT takes effect in both).

As to non-cuda codes, I think msg is needed for logging and debugging/error-handling, thus glog/loguru is sth that valued. Consider the pytorch/tf is the first target for K2 to work with. They both utilized glog, I would vote glog +1. The problem to dev with glog in a library (K2 would be at 1st stage?) is, without a config which must be the final main() job, there should be a local one with the same macro-name. This is a convention to use with glog at least for a library. During called through main(), the preset define-check macro(#ifndef glog..) is used to choose from the real glog or the mimic one. In this way, the glog can be able to different mother-ships.

from k2.

A library should not expect a macro "the-predefined-glog-indicator-in-glog-header". If glog is not presented, the loguru should be ready, that means be inited in a default way in its part of the glog-or-loguru header. I made it init as so. Would check it to make sure it works (write tests).

from k2.

Another way is forget glog, define our one. But the default msg distributions (stdout/stderr) may make the upper-framework unhappy. That's a reason why glog is used widely.

from k2.

Meixu, I found your comment ". The problem to dev with glog in a library (K2 would be at 1st stage?) is, without a config which must be the final main() job, there should be a local one with the same macro-name. This is a convention to use with glog at least for a library." confusing. Can you please clarify with example code?

from k2.

Sorry about it and sure. I think the right way is to introduce loguru. And would write tests to show.

from k2.

If we have to use third-party log libraries, I would like to use glog instead of loguru. As you said before, a lot of projects use glog (e.g. PyTorch, TensorFlow). Or we write our own log system as we only need a few features (e.g. CHECK with printing error message, LOG(FATAL))

Sorry about it and sure. I think the right way is to introduce loguru. And would write tests to show.

from k2.

How do I feel like no one knows what I'm saying 🐶🐶🐶 I can't express myself well in Eng. If there is glog, there must be another logger that mimics it.

from k2.

OK, sorry, you mean there must be some init function to call InitGoogleGlog? or can you explain the requirements/limitation you declared with some sample code?

from k2.

sure, as dan has asked about.

from k2.

from k2.