Re: [Discuss-gnuradio] Why SWIG has been selected as C++ wrapper for Python for GNURadio ?

[Marcus Leech]

I find that it's relatively-common for people to criticize existing codebases because they don't use library <foo>, or aren't written in <vogue-language-of-the-week>, or don't use <exciting-new-framework-of-the-year>.  The nice thing about computer-sciencey things is that there's *always* a multitude of pathways to achieve any given goal.  The fact that some group of people would

choose a pathway different than the pathway *you* would choose doesn't make those choices *wrong*, just *different*.

 

That's not to say that certain pathways aren't *inherently* wrong.  For example, if Gnu Radio had chosen to code the signal-processing blocks in Python, rather than just the "control plane"

  layer, it would have caused most people, I think, to question the sanity of such a choice.

 

Just my two cents from 35 years in this racket....

 

 

on Jun 20, 2014, Tom Rondeau <address@hidden> wrote:

On Fri, Jun 20, 2014 at 5:42 AM, Marcus Müller <address@hidden> wrote:

Hi Joe,

Disclaimer: I haven't been around when SWIG was introduced into GNU Radio. These are somewhat educated guesses, but since I've had *some* fun with SWIG, I wondered myself and this is what I rationalized.

- SWIG was around at the time GNU Radio was rewritten, which must have been around 2004. I think the choice to use SWIG was made before that [1]. SWIG has been around since '96, so I guess it was expected to be somewhat stable/reliable. Boost.Python was started in '03, and if the guys behind it decided that they had to conceptually rework something, the second year it exists sounds like a dangerous time to use it. ctypes is (I think) python-2.5esque, so this couldn't have been around back in the day, and only does basic C wrapping.
- It does what GNU Radio needed: Generate python wrapper classes without the developers needing to actually write code; defining the interface was enough for a "normal" block to be SWIG'ed, and specialized wrapper classes only had to be written for some of the core things so that things like connect()ing blocks would work. It is arguable if writing and maintaining the SWIG .i files (especially since we're talking about the autohell era) was worth the trouble of avoiding that, but for the only comparable competitor Boost.Python, you had to define wrapper classes, and references to the classes wrapped and their members. Pyrex/Cython now is a complete different language and would have made GNU Radio something much more multi-paradigmatic, whilst adding even more to the "active" codebase that had to be maintained by hand.
- It was expected that if SWIG wasdone right, GNU Radio could end up with multiple scripting language interfaces [2]. Nowadays, people are content to use python, especially since we now (feels like yesterday) have support to write gr::block classes in python, which of course needed a lot of gateway work, so (to my knowledge) there haven't been efforts to make use of more than the C++ and Python SWIG capabilities[3].

Greetings,
Marcus

[1] http://lists.gnu.org/archive/cgi-bin/namazu.cgi?query=SWIG&submit=Search!&idxname=discuss-gnuradio&max=20&result=normal&sort=date%3Aearly
[2] http://lists.gnu.org/archive/html/discuss-gnuradio/2003-03/msg00135.html
[3] After all, for scripting python works really nice and is easy to learn. If you wanted to use a fast Matrix operation in Fortran, there is no stopping you from doing that from C++, which is the programming language of choice for performance-critical blocks, anyway, as long as your Fortran and C++ compilers are ABI-compliant. If you wanted

On 20.06.2014 10:34, Joe D wrote:

Hi All

This is a question intended  for the Software designers and maintainers of
the GNURadio

Is there a specific reason / advantage of using SWIG as a C++ wrapper over
using other avaialble  wrappers  for C++ as Boost.Python , Cython etc ....
in the context of GNURadio ?

Thanks!
Joe

 

Martin and Marcus nicely answered the question for you.

 

Just wanted to say that while we're not entirely impressed with some features of SWIG, the fact that it's working well for us and the disruption we would cause switching it out is not worth it. We'd have to make sure that the changes would result in a perfect 1-to-1 match with what we're exporting using swig.

 

Tom

 

---

_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio