Re: [Discuss-gnuradio] [RFC] PMT succession: experts' opinions on serialization libs

Hi, > I'm very certain that flatbuffers does handle this correctly, yes. > Haven't tried it, though. But "serialization library that doesn't deal > with cross-platform" sounds bad, doesn't it? You would think so yes, but it's not like it's un-heard of, especially if the primary goal was performan

Re: [Discuss-gnuradio] [RFC] PMT succession: experts' opinions on serialization libs

Hi Sylvain, I'm very certain that flatbuffers does handle this correctly, yes. Haven't tried it, though. But "serialization library that doesn't deal with cross-platform" sounds bad, doesn't it? Best regards, Marcus On Mon, 2019-09-30 at 08:37 +0200, Sylvain Munaut wrote: > Hi, > > > > Tbh, I'd

Re: [Discuss-gnuradio] [RFC] PMT succession: experts' opinions on serialization libs

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

Re: [Discuss-gnuradio] [RFC] PMT succession: experts' opinions on serialization libs

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

Re: [Discuss-gnuradio] [RFC] PMT succession: experts' opinions on serialization libs

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

Re: [Discuss-gnuradio] [RFC] PMT succession: experts' opinions on serialization libs

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)

Re: [Discuss-gnuradio] [RFC] PMT succession: experts' opinions on serialization libs

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

Re: [Discuss-gnuradio] [RFC] PMT succession: experts' opinions on serialization libs

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

Re: [Discuss-gnuradio] [RFC] PMT succession: experts' opinions on serialization libs

Just thinking outside the box here, but what about JSON? It is well defined, self documenting, easy to exchange between platforms and OS's, and supported natively by Python. Yes, it requires parsing, but I don't think that is a major drawback. Also it would not require any documentation to defi

Re: [Discuss-gnuradio] [RFC] PMT succession: experts' opinions on serialization libs

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. With that (somewhat) in mind, what about Flatbuffers as an alternative

[Discuss-gnuradio] [RFC] PMT succession: experts' opinions on serialization libs

To avoid the setting in of post-Conference downs: Dearest SDR Community with the Highest count of "Awesome" in the Universe, discussions at GRCon have made it abundantly clear that PMT needs to be replaced¹. Main issues with PMT are: * broken type system, * low suitability as tool for internal p