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) <address@hidden> 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
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
--
Very Respectfully,
Dan CaJacob
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio