Re: [Discuss-gnuradio] [GSOC 2018] Ideas please!

[Martin Braun]

Marcus,

these are great suggestions! As far as the packaging task goes, it's
important that we keep it within well defined *coding* tasks. For
example, GSoC clearly states that documentation changes are not for
GSoC. Scripting/maintenance falls into a grey zone, gr_modtool updates
are OK.

Cheers,
Martin

On 10/14/2017 03:21 AM, Marcus Müller wrote:
> Hi Felix!
> 
> 
> to get this started:
> 
> I've got some ideas that I'd be willing to mentor (not all of them at
> once, and for some I'd like to have a "peer" mentor, or at least input
> from someone who's done that kind of software engineering before). I
> don't think this list is even exhaustive, but these are the things that
> popped into my mind quickest, so I guess that speaks for them:
> 
>   * Radar implementations
>       o MIMO Radar: 1-by-2, 2-by-2 radar? Or a generalized approach? I'm
>         sure there's a wealth of existing implementations out there, but
>         we have no "well demonstratable, halfway clean" impl
>       o passive radar using e.g. DVB-T2 or -S2 as signal donor (we
>         happen to have demod/mod for that already, anything else would
>         fly, too)?
>         That with a distributed approach (i.e. two independent observers
>         extracting/regenerating the "clean" direct path from the RX,
>         then crosscorrelating the RX with that to get a PDP, then
>         combine the two PDPs to find objects on the ℝ²)
>   * Make Ctrlport good (again):
>       o We've all been having quite some trouble with the unstable mess
>         Thrift has turned out to be, and with ZeroMQ in-tree and
>         low-hanging fruit RPC alternatives (ZeroRPC, which is Msgpack
>         over ZMQ, for example), and the original idea that the RPC
>         transport beneath Ctrlport should be switchable, I'd like to see
>         someone actually implement an RPC transport mechanism that
>         allows us to get rid of the Thrift dependency
>         I'm also very open to having someone do e.g. a REST kind of RPC
>         API, but I do think we need a low-overhead RPC mechanism, so
>         this is kind of a thing I'd rather see "nearly comes for free
>         after ZeroRPC works" with a ZWS (ZMQ over websocket transport)
>         impl (we already have python-based XMLRPC, and it works for slow
>         things that are variables or function calls in the GRC-generated
>         Python file)
>   * Packaging: While that does sound like a core dev team/maintainer's
>     job, packaging is important, and there's a lot of interesting
>     footwork to be done that's less of a coordinating and more of a
>     read-the-docs/implementation thingie:
>       o Write scripts (CMake, bash, Python?) and add them to the
>         gr-modtool template that
>           + automatically generate a good-style Deb, RPM, Arch Pkg,
>             Whatever-the-brew-we-use on OS X, maybe even an MSI that
>             works with Geoff's Windows port/ /
>           + a minimal script/git branch you can merge/diff to add that
>             functionality to existing modules
>           + a script to upload the resulting package (source packages)
>             to the respective build services of major Distros (that
>             being COPR, Launchpad, build.opensuse.org…)
>           + maybe even: CGRAN gets an interface that checks whether a
>             OOT module has native packages, and on which platforms these
>             build correctly according to above build services
>       o Make GNU Radio main tree packaging good (again) for people who
>         aren't on debian(oids): adopt Maitland's great "gnuradio is a
>         package depending on libgnuradio-runtime, libgnuradio-fft,
>         libgnuradio-audio, libgnuradio-uhd…" for all distros
>           + Entails writing RPM specs, arch pkg, and
>             the-rest-of-what's-realistic-from-above
>           + benefit: People can install gnuradio-runtime, and exactly
>             these in-tree modules they need. No need to install UHD and
>             QT5 on a raspberry pi that doesn't have a USRP nor a screen
>           + From there on, kind of a maintainer's job to keep in touch
>             with the distro maintainers to push out the results, XOR
>           + keep things on our own repos (not that hard with above build
>             services) and have our own package trees that explicitly
>             conflict with stock distro packages (not good in the FOSS
>             community sense, but will work out for users if we also
>             build the application packages the distros package (mainly:
>             GQRX, I guess, maybe gr-airmodes))
>   * GUI Integration: Looks like we're sticking with Qt5 – so, let's have
>     an easy way to integrate into Qt5 GUI.
>       o Idea: Wrap the Qt GUI sinks to appear in QtCreator, including
>         the GUI aspects of their parameterization
>           + Export of GUI yields UIC (XML file describing the form)
>           + Load that UIC in the "Options" Block in GRC
>           + GRC shows dialog to map existing QT Sinks in Flow graph to
>             GUI elements from UIC
>               # Possibly even visually! You can load the UIC and
>                 preview, then hook up double click signal slots.
>           + Generates python that loads UIC, places the sink widgets
>             where they belong
> 
> Cheers,
> 
> Marcus
> 
> On 14.10.2017 10:42, Wunsch, Felix (CEL) wrote:
>>
>> Hi all,
>>
>>
>> even though GSoC 2017 has ended not too long ago, we already need to
>> start the preparations for next year!
>>
>>
>> After 5 years of being org admin, Martin has asked for somebody else
>> to take over that task and I'm happy to volunteer for this. Having
>> profited from the GSoC experience myself, this is a great way for me
>> to give back some of the support I received back then.
>>
>>
>> And at this point, we need your support! Do you have a project in mind
>> that could be realized by a student in about 3 months of coding and/or
>> want to mentor? Let's discuss your ideas here on the list and then add
>> them to the wiki so we have a nice range of fleshed-out projects when
>> the org application period starts on January 4. If you are interested
>> but need some inspiration, have a look at the current ideas list and
>> past GSoC projects!
>>
>>
>> Current list: https://wiki.gnuradio.org/index.php/GSoCIdeas
>>
>> Old projects: https://wiki.gnuradio.org/index.php/GSoCPastProjects​
>>
>>
>> Cheers,
>> Felix
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>