That's actually an extensively great idea (though I admit it hadn't crossed my mind so far)!
So, for this to make it upstream, first of all, it'd need an OK from Tim, as that probably kinda reassigns copyright to the FSF (Ben would be my go-to authority on that). Then, I'd obviously have to play "grumpy mean old maintainer" a bit: I know there's qa_es.py, but I think it's been written before we fixed shutdown bugs, so, probably, there's a bit good functionality that's not covered by tests. Seeing how much "fun" we've had after extending runtime infrastructure (and that's what I'd consider eventstream), to avoid regressions in the future, I'd have to insist on a few additional tests. Don't know how they'd look like, which might be an indication I'd need to invite Tim for a beer and talk about what should be tested. Code coverage metrics alone do not make for good testing. And: As cool as eventstream is, and as much as I like Tim's blog, we'd obviously need formal documentation; right now, I can't find a docs/ folder in my gr-eventstream build directory, so at least the building of API docs needs to be fixed. And: if we do gr-eventstream, we'd do it properly, which means that someone needs to sit down and write a guide that integrates with the tutorials. I'm afraid a simple copypasta from Tim's block wouldn't do, but would need to be broken down for beginners to understand the problem at hand first (which requires some GNU Radio operational theory). So, as I can't do that today, and probably not in the first two weeks of April, either, I'd propose we make a GREP out of that. Want to champion that? That way, we'd document a desire to improve GNU Radio at its core, and give us a target. Cheers, Marcus On Thu, 2018-03-29 at 00:44 +0000, Dan CaJacob wrote: > Speaking of gr-eventstream, Marcus: is there any intent to pull that or > something like it into core in this new Gnuradio world? > > On Wed, Mar 28, 2018 at 3:22 PM Müller, Marcus (CEL) <[email protected]> wrote: > > Hi Samuel, > > On Wed, 2018-03-28 at 14:54 +0200, samuel verdon wrote: > > > I forgot to say that my graph is connected to hardware (bladerf or > > > limesdr) via osmocom block. This one give me the error that there is not > > > enough data. > > > > Jeff's mail recommending gr-eventstream was on-spot. > > > > Best regards, > > Marcus_______________________________________________ > > Discuss-gnuradio mailing list > > [email protected] > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > -- > Very Respectfully, > > Dan CaJacob
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
