Use of boost::format() in GR 3.10

[gvanem]

I've checked out the gnuradio-3.10 branch of this project like this:

git clone https://github.com/fventuri/gr-sdrplay3.git --single-branch --branch gnuradio-3.10 <MY_GR_ROOT>\gr-sdrplay3 

Correct?

But I've big troubles compiling it due to the use of boost::format() etc. From a clang-cl compile:

rsp_impl.cc(47,39): error: no member named 'format' in namespace 'boost'
        GR_LOG_ERROR(d_logger, boost::format("sdrplay_api_LockDeviceApi() Error: %s") % sdrplay_api_GetErrorString(err));
                               ~~~~~~~^
F:/gv/dx-radio/gnuradio/gv-build/include\gnuradio/logger.h(251,30): note: expanded from macro 'GR_LOG_ERROR'
        log->d_logger->error(msg); \
                             ^~~

etc. etc.

Shouldn't this really be:

--- a/rsp_impl.cc 2022-03-23 10:04:01
+++ b/rsp_impl.cc                                  2022-03-23 10:32:05
@@ -44,7 +44,7 @@
     sdrplay_api_ErrT err;
     err = sdrplay_api_LockDeviceApi();
     if (err != sdrplay_api_Success) {
-        GR_LOG_ERROR(d_logger, boost::format("sdrplay_api_LockDeviceApi() Error: %s") % sdrplay_api_GetErrorString(err));
+        d_logger->error("sdrplay_api_LockDeviceApi() Error: {:s}", sdrplay_api_GetErrorString(err));
     }

These errors happened recently. So perhaps there's was another breaking commit in GR-master repo that caused this?

[fventuri]

Good catch Gisle.

I just tried to rebuild the 'gnuradio-3.10' branch here this morning against the 'main' branch of GNU Radio, and it failed with the same errors you saw (which will need exactly the fix you suggested).
My previous successful build was on 3/16, i.e. about a week ago, so, as you correctly noticed, the change happened in the main branch in the last week.
Since the main branch is actually what will become GNU Radio 3.11, it is probably best if I made your proposed change to a new branch, not gnuradio-3.10.
I have been thinking in the last few days of renaming/realigning the branches in this gr-sdrplay3 OOT module to match the names of the branches in GNU Radio, so that there will be a maint-3.9, a maint-3.10, and finally a main (which will be 3.11), so at this point I think it is best if I were to make these branch changes first, and then apply your suggested code change to the new main branch.

Tonight after work I'll start working on these changes (I want to merge the allow_arbitrary_sample_rate_and_bandwidth branch first), and I'll send you an update on my progress.

Franco

[gvanem]

Besides, are we required to use those butt-ugly {:s} formats now?
So what is the replacement for e.g. %lg?

A big step backwards with these SPDlog formats IMHO. Why not both?

But testing GR 3.11 with a top_block.py generated from FM-Receiver-SDRplay.grc works fine with my RSP1a.
But some formats are still wrong:
[*** LOG ERROR #0001 ***] [2022-03-23 13:03:48] [rsp1a] {invalid type specifier}

Not specifying where that is!

[fventuri]

Yup - I am planning to switch to use 'fmt' and 'spdlog', like they do in 3.11, in the new 'main' branch after I'm done moving those branches around.

[gvanem]

I figured out those SPDlog format. Not so hard. Except to replace a %.2lf, I used {2:.2f}.
Here are my diffs with some fixes for clang-cl.

[fventuri]

Thanks for all your help, Gisle.
I switched to 'spdlog' and '{fmt}' (no more boost::format) like you did in the diffs in the new main branch, and I was able to build the OOT module, and to run a GNU Radio Companion flowgraph without errors.

Please give it a try when you have some time and let me know what you think,
Franco

[gvanem]

Please give it a try when you have some time and let me know what you think,

Works fine! But kinda confusing that this commit is in master. No maint-3.11 when there is a maint-3.10 ..

[fventuri]

Gisle,
first of all thanks for trying it out and I am really glad it is working well there too.

The names of the branches in gr-sdrplay3 now match exactly the names of the branches in GNU Radio; they have a branch for version 3.9 (which is in maintenance mode) called maint-3.9, another branch for 3.10 (in maintenance mode too) called maint-3.10, and finally a branch for the ongoing development (which will eventually become the official 3.11, but is still subject to breaking changes, like we saw with the spdlog thing) called main.

I thought it would be easier and more clear to keep the branch names the same in this OOT module.

Franco