Forum: GNU Radio Why SWIG has been selected as C++ wrapper for Python for GNURadio ?

737f1fa97662647e91d932cb54548949?d=identicon&s=25 Joe D (Guest)
on 2014-06-20 10:35
(Received via mailing list)
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
B4ffbc711addde4c649b1ed526df6157?d=identicon&s=25 Martin Braun (Guest)
on 2014-06-20 11:23
(Received via mailing list)
On 06/20/2014 10:34 AM, Joe D wrote:
> 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 ?

First, you need to realize that the decision to use SWIG was made a long
way back, when there were less alternatives. At the time, one important
argument was that Python wasn't the only scripting language that was to
be supported.
At this point, we know a lot of SWIG's quirks, and there is little
reason to change. It does all we need (although it could do somethings a
bit faster, the build times are still annoying), and it integrates well
with our code structure.
To be honest: Few of us are 100% happy with SWIG, but it's the devil we
know :)

However, while there are alternatives to SWIG worth considering, Cython
is not suitable for what we need. I haven't looked into Boost.Python
closely, though.

M
D17685d174fee4ca258c75cce7bc2202?d=identicon&s=25 Marcus Müller (Guest)
on 2014-06-20 11:44
(Received via mailing list)
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?qu...
[2]
http://lists.gnu.org/archive/html/discuss-gnuradio...
[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
C539637020fd56193dd6daec746c4a84?d=identicon&s=25 Tom Rondeau (Guest)
on 2014-06-20 16:25
(Received via mailing list)
On Fri, Jun 20, 2014 at 5:42 AM, Marcus Müller
<marcus.mueller@ettus.com>
wrote:

> decided that they had to conceptually rework something, the second year it
> competitor Boost.Python, you had to define wrapper classes, and references
>
> choice for performance-critical blocks, anyway, as long as your Fortran and
> 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
D3e3c5e41e9aed486856802be823e181?d=identicon&s=25 Johnathan Corgan (Guest)
on 2014-06-20 19:24
(Received via mailing list)
Attachment: johnathan.vcf (335 Bytes)
Attachment: signature.asc (230 Bytes)
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
558c40b97bd1af8d912424757714bda9?d=identicon&s=25 Marcus Leech (Guest)
on 2014-06-21 09:50
(Received via mailing list)
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Please log in before posting. Registration is free and takes only a minute.
Existing account

NEW: Do you have a Google/GoogleMail, Yahoo or Facebook account? No registration required!
Log in with Google account | Log in with Yahoo account | Log in with Facebook account
No account? Register here.