interface logging API with poco logger

[guruofquality]

From @guruofquality on May 12, 2016 4:19

From @guruofquality on September 7, 2014 20:1

• this will enable all of the toolkits log reporting to work together nicely
• proper log reporting when blocks are instantiated on remote hosts

Copied from original issue: pothosware/gnuradio#1

Copied from original issue: pothosware/gr-runtime#5

[ncorgan]

WIP here: https://github.com/pothosware/gr-pothos/tree/logging

[ncorgan]

I'm working on rebasing this back off the gr3.8 branch onto master, but an issue occurred to me that I haven't quite figured out a solution to yet.

See this example output:

std::shared_ptr<Pothos::Block> factory__udp_sink(const Pothos::DType &itemsize, const std::string & host, int port, int payload_size, bool eof) 
{
    auto __orig_block = udp_sink::make(itemsize.size(), host, port, payload_size, eof);
    auto __pothos_block = makeGrPothosBlock(__orig_block);
    auto __orig_block_ref = std::ref(*static_cast<gr::blocks::udp_sink *>(__orig_block.get()));
    __pothos_block->registerCallable("payload_size", Pothos::Callable(&gr::blocks::udp_sink::payload_size).bind(__orig_block_ref, 0)); 
    __pothos_block->registerCallable("connect", Pothos::Callable(&gr::blocks::udp_sink::connect).bind(__orig_block_ref, 0)); 
    __pothos_block->registerCallable("disconnect", Pothos::Callable(&gr::blocks::udp_sink::disconnect).bind(__orig_block_ref, 0)); 
    return __pothos_block;
}

The code to overwrite a GNU Radio block's logger with our Poco logger is done inside makeGrPothosBlock, at which point the GNU Radio block has already been constructed. Any logging that's done in construction won't be logged in the block's new Poco logger. Perhaps there's something global we could do, but I'm not sure.

[guruofquality]

Its kind of like that for just about any library with its logging buried in the libs. In the case of SoapySDR, we just register a custom log handler. So what if instead of redirecting the blocks logger, just the destination logger in gr-runtime was redirected into poco. I dont know enough about the gr-logging, but presumably you can snag the output so you can handle it in a gui or send it to file? That way we would catch any and all library prints from gnuradio libs.

[ncorgan]

Getting at the global logging infrastructure may be feasible. We can't directly access the internals because the only block hackery we can do is adding our "friend class" declarations, but it can be overridden with a config file. Perhaps at init time, we have a one-time operation to write a temporary file, override the logging style with our own, and it'll all just work from there. I'm not sure if we can use that to point it to the new Poco logging class though.

I'll give that a try sometime this week and let you know how it works out. If that ends up working, I'll update this pull request with that solution.

[guruofquality]

I guess gnuradio didnt make an API to have a function called by the logger. I think that would be great for guis like GRC or GQRX so they could tie in somehow. Its not a big deal. I wouldnt try to hack it, even if we could. I guess those library logs are just lost. But have fun if you want to try. I suppose this issue can be closed reguardless.