Re: [Discuss-gnuradio] [SOCIS '17] GRC C++ Output: Week 8

[Piotr Krysik]

Hi Håkon,

Thanks for the info. I will try your code under that distro.

Regarding what I've shown - I compiled everything according to your
description and gnuradio-companion failed on my machine (Ubuntu 16.04)
to load because it couldn't import gr from gnuradio. This is why I've
shown what happens when trying to load that module.

Best Regards,
Piotr Krysik

W dniu 25.09.2017 o 02:39, Håkon Vågsether pisze:
> Hello Piotr,
>
> hmm, that certainly doesn't look like code I have touched, and I can't
> say I have seen that error before either. I'm running Arch Linux
> (Python 3.6.2), hope that helps! :)
>
> Python 3.5.2 (default, Aug 18 2017, 17:48:00)
> [GCC 5.4.0 20160609] on linux
> Type "help", "copyright", "credits" or "license" for more information.
> >>> from gnuradio import gr
> Traceback (most recent call last):
>   File
> "/usr/local/lib/python3.5/dist-packages/gnuradio/gr/__init__.py",
> line 39, in 
>     from .runtime_swig import *
>   File
> "/usr/local/lib/python3.5/dist-packages/gnuradio/gr/runtime_swig.py",
> line 28, in 
>     _runtime_swig = swig_import_helper()
>   File
>
...

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

Re: [Discuss-gnuradio] [SOCIS '17] GRC C++ Output: Week 8

[Håkon Vågsether]

Hello Piotr,

hmm, that certainly doesn't look like code I have touched, and I can't say
I have seen that error before either. I'm running Arch Linux (Python
3.6.2), hope that helps! :)

Best regards,
Håkon Vågsether

On Sun, Sep 24, 2017 at 4:27 PM, Piotr Krysik  wrote:

> W dniu 18.09.2017 o 11:10, Håkon Vågsether pisze:
> > Hi all,
> >
> > The focus for this week has been the QT blocks. You can read more at:
> >
> > https://grccpp.wordpress.com
> >
> > Best regards,
> > Håkon Vågsether
> Hi Håkon,
>
> I'm trying to compile and run according to the description but I got an
> error when trying to do "from gnuradio import gr". Gnuradio-companion
> also doesn't run because of this.
> Below is the full error message. My OS is Ubuntu 16.04. I don't want you
> to loose focus to debug this particular problem, but can you tell me
> what is your setup (mainly distro), where your version of GRC works fine?
>
>
> Python 3.5.2 (default, Aug 18 2017, 17:48:00)
> [GCC 5.4.0 20160609] on linux
> Type "help", "copyright", "credits" or "license" for more information.
> >>> from gnuradio import gr
> Traceback (most recent call last):
>   File "/usr/local/lib/python3.5/dist-packages/gnuradio/gr/__init__.py",
> line 39, in 
> from .runtime_swig import *
>   File
> "/usr/local/lib/python3.5/dist-packages/gnuradio/gr/runtime_swig.py",
> line 28, in 
> _runtime_swig = swig_import_helper()
>   File
> "/usr/local/lib/python3.5/dist-packages/gnuradio/gr/runtime_swig.py",
> line 24, in swig_import_helper
> _mod = imp.load_module('_runtime_swig', fp, pathname, description)
>   File "/usr/lib/python3.5/imp.py", line 242, in load_module
> return load_dynamic(name, filename, file)
>   File "/usr/lib/python3.5/imp.py", line 342, in load_dynamic
> return _load(spec)
> ImportError: dynamic module does not define module export function
> (PyInit__runtime_swig)
>
> During handling of the above exception, another exception occurred:
>
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "/usr/local/lib/python3.5/dist-packages/gnuradio/gr/__init__.py",
> line 43, in 
> from .runtime_swig import *
>   File
> "/usr/local/lib/python3.5/dist-packages/gnuradio/gr/runtime_swig.py",
> line 28, in 
> _runtime_swig = swig_import_helper()
>   File
> "/usr/local/lib/python3.5/dist-packages/gnuradio/gr/runtime_swig.py",
> line 24, in swig_import_helper
> _mod = imp.load_module('_runtime_swig', fp, pathname, description)
>   File "/usr/lib/python3.5/imp.py", line 242, in load_module
> return load_dynamic(name, filename, file)
>   File "/usr/lib/python3.5/imp.py", line 342, in load_dynamic
> return _load(spec)
> ImportError: dynamic module does not define module export function
> (PyInit__runtime_swig)
>
> Best Regards,
> Piotr Krysik
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] [SOCIS '17] GRC C++ Output: Week 8

[Piotr Krysik]

W dniu 18.09.2017 o 11:10, Håkon Vågsether pisze:
> Hi all,
>
> The focus for this week has been the QT blocks. You can read more at:
>
> https://grccpp.wordpress.com
>
> Best regards,
> Håkon Vågsether
Hi Håkon,

I'm trying to compile and run according to the description but I got an
error when trying to do "from gnuradio import gr". Gnuradio-companion
also doesn't run because of this.
Below is the full error message. My OS is Ubuntu 16.04. I don't want you
to loose focus to debug this particular problem, but can you tell me
what is your setup (mainly distro), where your version of GRC works fine?


Python 3.5.2 (default, Aug 18 2017, 17:48:00)
[GCC 5.4.0 20160609] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from gnuradio import gr
Traceback (most recent call last):
  File "/usr/local/lib/python3.5/dist-packages/gnuradio/gr/__init__.py",
line 39, in 
    from .runtime_swig import *
  File
"/usr/local/lib/python3.5/dist-packages/gnuradio/gr/runtime_swig.py",
line 28, in 
    _runtime_swig = swig_import_helper()
  File
"/usr/local/lib/python3.5/dist-packages/gnuradio/gr/runtime_swig.py",
line 24, in swig_import_helper
    _mod = imp.load_module('_runtime_swig', fp, pathname, description)
  File "/usr/lib/python3.5/imp.py", line 242, in load_module
    return load_dynamic(name, filename, file)
  File "/usr/lib/python3.5/imp.py", line 342, in load_dynamic
    return _load(spec)
ImportError: dynamic module does not define module export function
(PyInit__runtime_swig)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/local/lib/python3.5/dist-packages/gnuradio/gr/__init__.py",
line 43, in 
    from .runtime_swig import *
  File
"/usr/local/lib/python3.5/dist-packages/gnuradio/gr/runtime_swig.py",
line 28, in 
    _runtime_swig = swig_import_helper()
  File
"/usr/local/lib/python3.5/dist-packages/gnuradio/gr/runtime_swig.py",
line 24, in swig_import_helper
    _mod = imp.load_module('_runtime_swig', fp, pathname, description)
  File "/usr/lib/python3.5/imp.py", line 242, in load_module
    return load_dynamic(name, filename, file)
  File "/usr/lib/python3.5/imp.py", line 342, in load_dynamic
    return _load(spec)
ImportError: dynamic module does not define module export function
(PyInit__runtime_swig)

Best Regards,
Piotr Krysik

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

Re: [Discuss-gnuradio] [SOCIS '17] GRC C++ Output: Week 8

[Marcus Müller]

Hey,

thanks for the extensive answer! So, yeah, I think finding a way to come
up with a graphical way to program C++ is a bigger problem than fixing
the GNU Radio scheduler :) you're certainly invited to help on enabling
loopbacks; there's no "real" reason it's forbidden by the scheduler.
Essentially, the fact that the scheduler won't allow you to do it is for
causality reasons:
At the point where the feedback merges into the "forward" stream, if you
for example have an "Add" block, then that block can't do anything until
there's input items on both inputs. But there can't be any input from
the feedback stream if there's no output of the "Add" block. You can
work around that, logically, by having a block in the feedback chain
that produces a few samples without input, or make an "Add" equivalent
that doesn't need input on both input streams to start, but it's not a
general guarantee these flow graphs can run.
Historically, it really could not work (as far as I remember the
previous single-threaded scheduler), but the hard "impossible" should
have changed to a "possible with some complications and a lot of ugly
corner cases".

Best regards,
Marcus

On 09/19/2017 02:53 PM, Federico 'Larroca' La Rocca wrote:
> Hi,
>
> so your idea is to use GNU Radio Companion to design blocks that
> internally has a loopback?
>
> Actually, my idea was to use the companion to design blocks in c++.
> They may have loops or not.
>
> That would kind of break the semantics of GRC being a tool for
> designing GNU Raio flow graphs
>
> You are very right on this "confusion" issue, of which I haven't thought.
>
> , but I'd still be open to that idea, if you could explain in
> which way that would differ from it simply being a unified
> "control loop" block that only is parameterizable (in which case
> you wouldn't benefit from the graphical representation of it being
> multiple blocks with feedback, because it's not what's happening,
> more confusing than clarifying).
>
> So, I don't really think that we can find a sufficiently general
> approach here that would justify letting users do something that
> GNU Radio itself can't. I'd much rather fix the scheduler than
> spend time on emulating a fix by having restricted feedback
> ability that only allows a very limited set of blocks to work in
> the feedback branch.
>
> What do you think?
>
>
> I'm not sure what you mean by "unified control loop", but after some
> thought I agree with your last comment.
> So, let me know how we can contribute to making loops possible in the
> scheduler. Not sure how much manpower we may get though, specially in
> the middle of the semester, but we'll do our best.
> Best
> Federico
>  
>
> Best regards,
>
> Marcus
>
>
>

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

Re: [Discuss-gnuradio] [SOCIS '17] GRC C++ Output: Week 8

[Federico 'Larroca' La Rocca]

Hi,

so your idea is to use GNU Radio Companion to design blocks that internally
> has a loopback?
>
Actually, my idea was to use the companion to design blocks in c++. They
may have loops or not.

> That would kind of break the semantics of GRC being a tool for designing
> GNU Raio flow graphs
>
You are very right on this "confusion" issue, of which I haven't thought.

> , but I'd still be open to that idea, if you could explain in which way
> that would differ from it simply being a unified "control loop" block that
> only is parameterizable (in which case you wouldn't benefit from the
> graphical representation of it being multiple blocks with feedback, because
> it's not what's happening, more confusing than clarifying).
>
So, I don't really think that we can find a sufficiently general approach
> here that would justify letting users do something that GNU Radio itself
> can't. I'd much rather fix the scheduler than spend time on emulating a fix
> by having restricted feedback ability that only allows a very limited set
> of blocks to work in the feedback branch.
>
> What do you think?
>

I'm not sure what you mean by "unified control loop", but after some
thought I agree with your last comment.
So, let me know how we can contribute to making loops possible in the
scheduler. Not sure how much manpower we may get though, specially in the
middle of the semester, but we'll do our best.
Best
Federico


> Best regards,
>
> Marcus
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] [SOCIS '17] GRC C++ Output: Week 8

[Marcus Müller]

Hi Federico,

so your idea is to use GNU Radio Companion to design blocks that
internally has a loopback?

That would kind of break the semantics of GRC being a tool for designing
GNU Raio flow graphs, but I'd still be open to that idea, if you could
explain in which way that would differ from it simply being a unified
"control loop" block that only is parameterizable (in which case you
wouldn't benefit from the graphical representation of it being multiple
blocks with feedback, because it's not what's happening, more confusing
than clarifying).

So, I don't really think that we can find a sufficiently general
approach here that would justify letting users do something that GNU
Radio itself can't. I'd much rather fix the scheduler than spend time on
emulating a fix by having restricted feedback ability that only allows a
very limited set of blocks to work in the feedback branch.

What do you think?

Best regards,

Marcus

On 09/19/2017 08:29 AM, Federico 'Larroca' La Rocca wrote:
> Hi Marcus, 
> Me and my team would be glad to help. I am aware that block
> interconnection depends on the scheduler, which forbids loops.
> However, my idea was not as ambitious as modifying the whole
> scheduler, but customizing the companion to generate the c++ code of a
> block, and thus my question (a sort of hier block, in terms of the
> companion, but written directly on c++, without interconnecting
> blocks, i.e. it would automatically generate the work() function, etc.). 
> This would of course be much less powerful than allowing loops on a
> flowgraph, and only certain operations would be allowed (those for
> which a c++ function exists). But it would allow to program relatively
> simple but useful blocks, including loops, with all the simplicity of
> the companion. 
> What do you think? 
> best
> Federico
>
>
> 2017-09-18 19:52 GMT-03:00 Marcus Müller  >:
>
> Hi Federico,
>
> Loops in the Flowgraph are currently forbidden by GNU Radio
> itself, not by the GRC designer.
>
> So, no, this is not scope of Hakon's project. If you want to
> contribute to having that feature in a generally useful manner, we
> can certainly chat about how you can improve the scheduler to make
> that possible.
>
> Best regards,
>
> Marcus
>
>
> On 09/18/2017 03:44 PM, Federico 'Larroca' La Rocca wrote:
>> Hi,
>> Outputting c++ from the companion would be a great addition to
>> GNU Radio. A small question: the possibility of having loops on
>> the flowgraph is contemplated on this project? We've been using
>> GNU Radio for teaching for some years now (highschool,
>> undergraduate and graduate students), and such feature would be
>> very useful and illustrative. For instance, when using a PLL, we
>> have to resort to feedforward schemes or using the blocks already
>> part of GNU Radio, but as a black box of sorts. Coding in c++
>> would be asking too much from students in a course where the
>> focus is on communications, whereas the companion is simply
>> perfect in terms of intuitiveness and ease of use.
>> best
>> Federico
>>
>> 2017-09-18 6:10 GMT-03:00 Håkon Vågsether > >:
>>
>> Hi all,
>>
>> The focus for this week has been the QT blocks. You can read
>> more at:
>>
>> https://grccpp.wordpress.com
>>
>> Best regards,
>> Håkon Vågsether
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org 
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> 
>>
>>
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org 
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> 
> ___ Discuss-gnuradio
> mailing list Discuss-gnuradio@gnu.org
> 
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>  
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] [SOCIS '17] GRC C++ Output: Week 8

[Federico 'Larroca' La Rocca]

Hi Marcus,
Me and my team would be glad to help. I am aware that block interconnection
depends on the scheduler, which forbids loops. However, my idea was not as
ambitious as modifying the whole scheduler, but customizing the companion
to generate the c++ code of a block, and thus my question (a sort of hier
block, in terms of the companion, but written directly on c++, without
interconnecting blocks, i.e. it would automatically generate the work()
function, etc.).
This would of course be much less powerful than allowing loops on a
flowgraph, and only certain operations would be allowed (those for which a
c++ function exists). But it would allow to program relatively simple but
useful blocks, including loops, with all the simplicity of the companion.
What do you think?
best
Federico


2017-09-18 19:52 GMT-03:00 Marcus Müller :

> Hi Federico,
>
> Loops in the Flowgraph are currently forbidden by GNU Radio itself, not by
> the GRC designer.
>
> So, no, this is not scope of Hakon's project. If you want to contribute to
> having that feature in a generally useful manner, we can certainly chat
> about how you can improve the scheduler to make that possible.
>
> Best regards,
>
> Marcus
>
> On 09/18/2017 03:44 PM, Federico 'Larroca' La Rocca wrote:
>
> Hi,
> Outputting c++ from the companion would be a great addition to GNU Radio.
> A small question: the possibility of having loops on the flowgraph is
> contemplated on this project? We've been using GNU Radio for teaching for
> some years now (highschool, undergraduate and graduate students), and such
> feature would be very useful and illustrative. For instance, when using a
> PLL, we have to resort to feedforward schemes or using the blocks already
> part of GNU Radio, but as a black box of sorts. Coding in c++ would be
> asking too much from students in a course where the focus is on
> communications, whereas the companion is simply perfect in terms of
> intuitiveness and ease of use.
> best
> Federico
>
> 2017-09-18 6:10 GMT-03:00 Håkon Vågsether :
>
>> Hi all,
>>
>> The focus for this week has been the QT blocks. You can read more at:
>>
>> https://grccpp.wordpress.com
>>
>> Best regards,
>> Håkon Vågsether
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>
>
> ___
> Discuss-gnuradio mailing 
> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] [SOCIS '17] GRC C++ Output: Week 8

[Marcus Müller]

Hi Federico,

Loops in the Flowgraph are currently forbidden by GNU Radio itself, not
by the GRC designer.

So, no, this is not scope of Hakon's project. If you want to contribute
to having that feature in a generally useful manner, we can certainly
chat about how you can improve the scheduler to make that possible.

Best regards,

Marcus


On 09/18/2017 03:44 PM, Federico 'Larroca' La Rocca wrote:
> Hi,
> Outputting c++ from the companion would be a great addition to GNU
> Radio. A small question: the possibility of having loops on the
> flowgraph is contemplated on this project? We've been using GNU Radio
> for teaching for some years now (highschool, undergraduate and
> graduate students), and such feature would be very useful and
> illustrative. For instance, when using a PLL, we have to resort to
> feedforward schemes or using the blocks already part of GNU Radio, but
> as a black box of sorts. Coding in c++ would be asking too much from
> students in a course where the focus is on communications, whereas the
> companion is simply perfect in terms of intuitiveness and ease of use.
> best
> Federico
>
> 2017-09-18 6:10 GMT-03:00 Håkon Vågsether  >:
>
> Hi all,
>
> The focus for this week has been the QT blocks. You can read more at:
>
> https://grccpp.wordpress.com
>
> Best regards,
> Håkon Vågsether
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org 
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
>
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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

Re: [Discuss-gnuradio] [SOCIS '17] GRC C++ Output: Week 8

[Federico 'Larroca' La Rocca]

Hi,
Outputting c++ from the companion would be a great addition to GNU Radio. A
small question: the possibility of having loops on the flowgraph is
contemplated on this project? We've been using GNU Radio for teaching for
some years now (highschool, undergraduate and graduate students), and such
feature would be very useful and illustrative. For instance, when using a
PLL, we have to resort to feedforward schemes or using the blocks already
part of GNU Radio, but as a black box of sorts. Coding in c++ would be
asking too much from students in a course where the focus is on
communications, whereas the companion is simply perfect in terms of
intuitiveness and ease of use.
best
Federico

2017-09-18 6:10 GMT-03:00 Håkon Vågsether :

> Hi all,
>
> The focus for this week has been the QT blocks. You can read more at:
>
> https://grccpp.wordpress.com
>
> Best regards,
> Håkon Vågsether
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] [SOCIS '17] GRC C++ Output: Week 8

[Håkon Vågsether]

Hi all,

The focus for this week has been the QT blocks. You can read more at:

https://grccpp.wordpress.com

Best regards,
Håkon Vågsether
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio