Hi,
>> Tbh, I'd just assume that in all these formats, being tight-packing by
>> default, std::complex can just be represented by the equivalent
>> of struct {float re; float im;} complex;.
I haven't delved into the code, but do you know if it handles properly
architecture differences between sen
Hi all,
Ettus points at this mailing list as the official forum for raising UHD
related questions.
This mail is sent to seek input on a recent regression we are seeing when
the official Debian UHD package removed "-lboost_system" from uhd.pc 'Libs'
in the following patch:
https://sources.debian.o
If you decide to go that route I'm happy to discuss possible re-use of
libsigmf and/or lessons learned from the trenches offline (I happen to be
using it a *lot*). It's not *really* specific to SigMF. It's really just
about getting c++ struct types easily converted to/from python. External
dependen
Wow, thanks. Yeah, that clearly reinforces flatbuffers as tool of
choice.
Tbh, I'd just assume that in all these formats, being tight-packing by
default, std::complex can just be represented by the equivalent
of struct {float re; float im;} complex;.
On Sun, 2019-09-29 at 09:32 -0500, West, Nat
While developing libsigmf (https://github.com/deepsig/libsigmf) I went
through a similar experience. The objective was to have painless json
file/string <-> real c++ type (this means the serialization thing had to
generate a slimmed down type that is effectively a struct of vector, int,
float, etc)
Hi Barry,
thanks for bringing this up! JSON was one of the considered, but
scrapped ideas; I'll explain why:
On Sat, 2019-09-28 at 20:13 -0400, Barry Duggan wrote:
> Just thinking outside the box here, but what about JSON? It is well
> defined,
JSON is not really overly well-defined when it co
Hi Nick,
On Sat, 2019-09-28 at 15:54 -0700, Nick Foster wrote:
> I think it's wise to avoid hitching our metaphorical horse to any
> software project we can't absolutely depend on; questionable
> dependency choices have bit us, as you mention, many times.
Sad but true.
> With that (somewhat) in
