-
Notifications
You must be signed in to change notification settings - Fork 0
Draft: setup prototype service structure and implement working thread-… #2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Just a quick comment since it looks like a lot of work went into the logger. I apologize since we are clearly missing some communication here. The logger has been discussed at the developer meeting, but not really documented in a way that could be easily followed outside of that. We have started moving toward spdlog in EICrecon. There is some documentation on its implementation as a service https://github.com/eic/EICrecon#logging . This actually came up at the key4hep meeting this week where they said they were needing to implement a standard logger and asked what we were doing at EIC. I told them we were looking at spdlog and a few people piped up and said this was not the first time it was suggested. They seemed fairly positive at looking at it as a solution. |
I think The purpose of this functionality is a bit different, as I did write a minimal logger (just This is the signature of the log action: using LogAction = std::function<void(LogLevel, std::string_view, std::string_view)>; and here is how to register a different log action (should be done at the framework boundary): algorithms::LogSvc::instance().action(YourLogFunctionHere); I tried to keep this extremely simple. Do you think there is more info needed to link this to the logger service in JANA2? |
+ clang-format + added properties to the LogSvc
…thers, more like a base
This sounds reasonable. I was just concerned about duplication of effort and it sounds like there is none. Thanks for the detailed explanation. |
…c small debug fixes
So I was looking at this and ran into an issue. The spdlog package removed support for stream loggers years ago and put forth some pretty reasonable arguments for doing so. People asked about wrapping spdlog to add back in stream support and the response was (parphrased) "you can, but it is probably not a good idea for the same reasons it was removed". Thus, to support spdlog logging, you need printf-style calls that consist of a format string and a variable number of additional arguments. There seems to be only two ways to handle variable arguments: variadic templates and the old C-style va_list. The latter is probably a non-starter. So to support this type of logger we would need the interface class to have methods using variadic templates. The methods can't be virtual since you can't have a virtual templated method (at least in C++17 AFIK). This kind of blocks you from using a standard inheritance model of implementing an interface class. The only other option is to use a templated interface model where the template parameter implements the underlying logger system. The problem here is that the only way to include a template parameter in the logger class that a user can determine is to also make the algorithm class a template. Below is an example where I define a simple interface class and then both a templated and non-templated version of the algorithm class.
Option 2 could work, but it forces making all algorithms templated simply for the sake of the logger. Somehow that bothers me. Maybe there is something I'm missing. At the Developer's meeting today we discussed this and concluded there was no obviously good solution. So, we will move forward for now by having the generic algorithms hold a shared pointer to the spdlog logger that they should use . This can be set by the algorithm caller. If you (or anyone) can come up with a clever solution for abstracting out a printf style logger, then we can retrofit at that point. |
For future reference, David and I had a meeting to chat about the path forward. After the meeting we don't see any showstoppers. The plan is to:
|
Superseded by #3 |
Briefly, what does this PR introduce?
Introduce a mechanism for minimal services for the stand-alone algorithms, with hooks to be configured by a calling framework
What kind of change does this PR introduce?
Please check if this PR fulfills the following: