Closed guruofquality closed 7 years ago
@guruofquality that's part of the updates from @SDRplay -- I'm not sure of the exact reason other than they're working with the master branch -- I've been working off master here and didn't catch that either -- please feel free to update it to something more compatible with the active release if you've got a quick fix.
We're just working with master branch for everything - isn't everyone?
Ah, I should have looked closer at the commiter. @SDRplay I personally build from the release branches of projects that have them. And FWIW somewhere in the slew of github issues that showup in my inbox, I did see someone else run into this.
But I bring this up because the use of KwargsToString didn't really seem to make sense anyway. It seems the goal is to parse fields from the value of "label" in the argument mapping. So I don't think the whole argument map needs to be formatted into a single string for this to work anyway.
So that was my take on it, unless I misunderstood. If that's correct, I can make the change myself, its minor, but I don't have anyway to test it. Volunteers, if I push a branch?
@guruofquality please do I'll check it out here and see how it goes with the RSP1
@guruofquality working fine here; label appears to be showing the same as before
Just a note that its the label thats parsed and encoded with a device id number, which it looks like it's necessary to discern when multiple sdr plays are present. Since its not bombing out with SoapySDR_logf(SOAPY_SDR_WARNING, "Can't find Dev string in args");
I think we are in good shape for the code to have extracted the number and done the right thing, I put the commit on master now.
@cjcliffe I was wondering the reasoning behind the label parsing stuff that uses kwargs to string:
It looks as if the code just wants to parse the label string for device version markup. Would it have made more sense to use
std::string strargs; if(args.count("label")!=0)strargs = args.at("label");
to parse just the label string? I ask because KwargsToString API isnt yet in a release, and a lot of builds work off of releases of SoapySDR, including myself. Otherwise we should at least bump thefind_package(SoapySDR ...
requirement if needed or find some workaround.