Hi Tom, hi Michael,
jep, fixed that, and my pull request was recently merged (thanks,
jcorgan ;) ).
Sadly, the fix only applies to new modules, but the fix is basically the
same as commenting that line out.
Instead of commenting it out, you can be safe that your module will also
respect C++ blocks if you add some later, you can try-except-surround
that import statement like:
try:
from mavlink_swig import *
except ImportError as e:
pass
(compare [1])
Greetings,
Marcus
[1]
https://github.com/marcusmueller/gnuradio/commit/06023871a7966101a5e50d4d906628ecaecf94f0
On 20.05.2014 15:13, Tom Rondeau wrote:
> On Tue, May 20, 2014 at 8:26 AM, Michal Jakubiak <[email protected]> wrote:
>
>> Hi there,
>>
>> I'm writing an OOT module. For now, the only block I've made is written in
>> Python.
>> I follow the guide and everythins is ok until I run the top_block and get
>> this error:
>>
>> File "/usr/local/lib/python2.7/dist-packages/mavlink/__init__.py", line
>> 45, in <module>
>> from mavlink_swig import *
>>
>> FYI, "mavlink" is the name of my module.
>>
>> Now, if I comment that line out everything seems to work fine. Is this a
>> serious issue or can I just go on using it this way?
>>
> I believe this issue has been corrected in recent weeks (Marcus Mueller I
> think handled it for us). No, if you just have Python blocks, then you do
> not require the "from xxx_swig import *" line, so you should be fine. Just
> remember that you've done this if you ever add a C++ block to your project.
>
> Tom
>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> [email protected]
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
