Hi Fernando, I think Heiko's point was regarding the global Shogun object you mentioned > in the first e-mail.
Any logging function in SGIO will be thread safe and non-blocking. Changing the way message is printed and any other options won't be (it can be easily fixed, but I don't think this is needed). I think source location is actually quite important for logging. There > should be some alternative keeping it, while allowing us to get rid of > macro's if that's worth. > I agree. There is "std::expermintal::source_location" but that's not implemented yet. And there are GCC's extension methods that can do the same, but that's compiler dependent. If source location is needed, then it's best to keep the macros. About using fmtlib for "python-like syntax instead of or in addition to > printf's", what do you think? I like fmtlib, and it's going to be part of C++20, so I don't see why not :"D. On Tue, Jul 23, 2019 at 2:59 PM Fernando J. Iglesias García < fernando.iglesi...@gmail.com> wrote: > Hey Ahmed, > > On Mon, 22 Jul 2019 at 23:33, Ahmed Essam <theartful...@gmail.com> wrote: > >> Thanks for the feedback! >> >> spdlog is friendly with multi threaded code. In fact, I currently use in >> the PR (as viktor suggested) an async logger, which does the logging in a >> different thread altogether. >> > > I think Heiko's point was regarding the global Shogun object you mentioned > in the first e-mail. > > >> Regarding the exposure of spdlog, I can add the functionality for >> directing streams to files, and we might discuss what other functionality >> is expected. However, exposing spdlog would give a huge amount of >> flexibility, as you can easily do whatever you want, thanks to their >> amazing interface and built-in sinks. >> >> Note that getting rid of macros means getting rid of source location >> (line, function, and file name). >> > > I think source location is actually quite important for logging. There > should be some alternative keeping it, while allowing us to get rid of > macro's if that's worth. > > About using fmtlib for "python-like syntax instead of or in addition to > printf's", what do you think? > > >> >> >> On Mon, Jul 22, 2019 at 11:24 PM Heiko Strathmann < >> heiko.strathm...@gmail.com> wrote: >> >>> Hi! >>> >>> Great initiative! See below >>> >>> Am Mo., 22. Juli 2019 um 19:49 Uhr schrieb Ahmed Essam < >>> theartful...@gmail.com>: >>> >>>> Regarding using spdlog, here are the assumptions: >>>> 1. There will be only one global SGIO object for logging. >>>> >>> Similar problems as for random: This means that multithreaded code will >>> also use this for logging, and we will need some sort of critical around >>> the log output. I wonder how that would affect performance. Also I wonder >>> how other (multithreaded) libs do this? Some minimal research might be good >>> here. >>> >>> >>>> 2. Two streams are used: stdout (for all log levels except for >>>> MSG_ERROR) and stderr, and the user can direct any of them. >>>> >>> That sounds very reasonable >>> >>> 3. spdlog will be exposed. That is the user will use spdlog sinks to >>>> redirect streams. I don't see a reason to wrap around them or add options >>>> to manipulate them further. Exposing spdlog is more flexible. So we can use >>>> "dist_sink" for example to redirect to multiple sinks. >>>> >>> I am not too sure about this. Backend libraries tend to change over the >>> years and explicitly adding those into the codebase usually causes >>> headaches later on. So I'd actually prefer some plugin like thing, but I >>> can probably be convinced ;) >>> >>> >>>> >>>> Some questions: >>>> 1. Are these assumptions reasonable? >>>> 2. Should we use fmtlib? I currently format using sprintf, but fmtlib >>>> is supposedly similar in runtime speed, and adds a little overhead in >>>> compile time (header library with compile time format checking!). The >>>> downside (for us) is that it uses python-like formatting. >>>> >>> Seems fine to me >>> >>> >>>> 3. Should we get rid of macros? >>>> >>> I think that would be nice. I guess they were used to switch off things >>> at compile time. We don't really do that anymore. >>> >>> >>
