Re: GSoC'21 - View Only Mode
Hi Oscar, Congratulations on being accepted for GSoC 2021! I was a summer of code student (SOCIS, not GSoC) a few years ago, and I certainly don't regret it. I'm looking forward to reading your updates throughout the summer! Best regards, Håkon Vågsether man. 24. mai 2021, 12:40 skrev Marcus Müller : > Hey Oscar, > > it's great to have you around! > GRC is really at the heart of GNU Radio's user experience. We've been > hoping very much > someone would take on this project: Being able to safely share flow graphs > would open the > door to much greater community cooperation. > > While GSoC pays you to do your work (some of us here actually have been in > that situation > - it's great!), don't assume you have to do it alone. Certainly, your > mentor (and backup > mentors) will be there for any questions you have, but if there's anything > you feel like > is a great question to ask the community, please don't hesitate: you being > in this special > position doesn't mean you'd be getting the same support from the community > than everyone > else does. Please never hesitate to drop an email to > discuss-gnuradio@gnu.org, or to ask > and discuss on our Matrix server; especially #grc-dev:gnuradio.org [1] > will probably be a > great place to hang out. > > Thanks for being a part of all this, > have a lot of fun, i.e. > happy hacking! > --Marcus > > [1] reachable through > https://chat.gnuradio.org/#/room/#grc-dev:gnuradio.org , or any > other Matrix client > > On 24.05.21 11:19, Oscar Ekholm wrote: > > Hello, > > > > I've been accepted to work with GnuRadio for this year's Google Summer > of Code. I will be > > working on implementing a GRC View-Only Mode, which is a security > feature disabling > > execution of block parameters in untrusted flowgraphs. > > > > I will be posting weekly progress updates on my blog: > > https://oscekh.github.io/ <https://oscekh.github.io/> > > > > If you are interested in reading more about the View-Only mode it is > described further in > > my project proposal: > > > https://docs.google.com/document/d/1dL6PziJSopcY3O7gJ6CXiedTSdbhrHVFhR-UJRTmsng/edit?usp=sharing > > < > https://docs.google.com/document/d/1dL6PziJSopcY3O7gJ6CXiedTSdbhrHVFhR-UJRTmsng/edit?usp=sharing > > > > > > Please reach out if you have any questions, advice or thoughts you want > to share. > > > > Best regards, > > Oscar Ekholm > >
GSoC 2021 - Call for Ideas
Hello GNU Radio Community, The organization application for this year's installment of Google Summer of Code is quickly approaching (this Friday, February 19), and we are a little short on project ideas. This year's GSoC will feature 175 hour projects (down from 350), so the project scope is significantly smaller than previous years. Please keep this in mind when suggesting new projects. If you have an idea, or would like to be a mentor, please let me know, either via mail or Matrix (my handle is haakov), and write a short summary of your idea on our GSoC Ideas page: https://wiki.gnuradio.org/index.php/GSoCIdeas If you are unfamiliar with GSoC, you can read about it here: https://summerofcode.withgoogle.com/ Thank you! Best regards, Håkon Vågsether GSoC 2021 Organization Administrator
Re: [Discuss-gnuradio] gnuradio-companion-3.8.0 fails to run
This error message also occurs in one of the GRC tests:
https://github.com/gnuradio/gnuradio/issues/2678
Best regards
Håkon Vågsether
tor. 24. okt. 2019, 12:41 skrev Müller, Marcus (CEL) :
> Hi Barry,
>
> neat, haven't seen that one before, specifically :)
> But I've seen a test fail:
> https://github.com/gnuradio/gnuradio/issues/2678
>
> Mageia is RPM-based, right? Never used it before, but could you point
> me to the .SPEC file you're using to build that package?
>
> Hunch: replace
>
>
> utils.hide_bokeh_gui_options_if_not_installed(self.blocks['options'])
> with
>
> try:
>
> utils.hide_bokeh_gui_options_if_not_installed(self.blocks['options'])
> except KeyError: #this happens if there's no 'options' block
> pass
>
> and things should work.
> I honestly think we could improve the
> hide_bokeh_gui_options_if_not_installed to handle None arguments and
> use .get('options') instead of ['options']. Willing to pick up on that?
>
> Best regards,
> Marcus
>
> On Thu, 2019-10-24 at 19:03 +0100, Barry Jackson wrote:
> > [baz@jackodesktop ~]$ gnuradio-companion
> > Traceback (most recent call last):
> >File "/usr/bin/gnuradio-companion", line 102, in
> > run_main()
> >File "/usr/bin/gnuradio-companion", line 95, in run_main
> > exit(main())
> >File "/usr/lib/python3.8/site-packages/gnuradio/grc/main.py", line
> > 83, in main
> > platform.build_library()
> >File
> > "/usr/lib/python3.8/site-packages/gnuradio/grc/core/platform.py", line
> > 197, in build_library
> >
> utils.hide_bokeh_gui_options_if_not_installed(self.blocks['options'])
> >File "/usr/lib64/python3.8/collections/__init__.py", line 891, in
> > __getitem__
> > return self.__missing__(key)# support subclasses that
> > define __missing__
> >File "/usr/lib64/python3.8/collections/__init__.py", line 883, in
> > __missing__
> > raise KeyError(key)
> > KeyError: 'options'
> > [baz@jackodesktop ~]$
> >
> > I found this
> > https://www.mail-archive.com/discuss-gnuradio@gnu.org/msg69270.html
> > ...which looked promising, but deleting .~.gnuradio changes nothing here.
> >
> > I have just updated our (Mageia8) package tp py3/qt5 build and hit this
> > in testing prior to pushing to our dev branch repo.
> >
> > Any ideas welcome :)
> >
> > ___
> > 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] gr-ettus and GNU radio v3.8
Hello Erik, I haven't really looked at gr-ettus for the master branch yet, but have you tried replacing 'out' with 0 on line 125 in rfnoc_test1.py? It would also be helpful if you supplied a git branch or something to look at, I might give it a try myself. Best regards, Håkon Vågsether On Wed, Jul 3, 2019 at 12:22 PM Erik Heinz wrote: > I got a step further. The rfnoc domain for grc can be defined by a file > rfnoc.domain.yml. > > Now I can connect the module and generate a Python file from the flowgraph. > > > The connections still do not work at run time, though , see below. > > I have defined 'connect:' and 'cpp_connect:' in rfnoc.domain.yml, but this > definitions have no effect since this file is not read at run time and not > included in > > rfnoc_test1.py either. > > > Any suggestions? > > > Thanks and best regards, > > Erik > > > > Traceback (most recent call last): > File "./rfnoc_test1.py", line 180, in > main() > File "./rfnoc_test1.py", line 158, in main > tb = top_block_cls() > File "./rfnoc_test1.py", line 125, in __init__ > self.connect((self.uhd_rfnoc_streamer_dma_fifo_0, 'out'), > (self.qtgui_sink_x_0, 0)) > File "/usr/lib/python3.6/site-packages/gnuradio/gr/hier_block2.py", line > 48, in wrapped > func(self, src, src_port, dst, dst_port) > File "/usr/lib/python3.6/site-packages/gnuradio/gr/hier_block2.py", line > 111, in connect > self.primitive_connect(*args) > File "/usr/lib/python3.6/site-packages/gnuradio/gr/runtime_swig.py", > line 3606, in primitive_connect > return _runtime_swig.top_block_sptr_primitive_connect(self, *args) > TypeError: Wrong number or type of arguments for overloaded function > 'top_block_sptr_primitive_connect'. > Possible C/C++ prototypes are: > gr::hier_block2::connect(gr::basic_block_sptr) > > gr::hier_block2::connect(gr::basic_block_sptr,int,gr::basic_block_sptr,int) > > > > -- > *Von:* USRP-users im Auftrag von > Erik Heinz via USRP-users > *Gesendet:* Freitag, 28. Juni 2019 18:12 > *An:* discuss-gnuradio@gnu.org; usrp-us...@lists.ettus.com > *Betreff:* [USRP-users] gr-ettus and GNU radio v3.8 > > > Have there been any efforts yet to port gr-ettus to the gnuradio master > branch? > > I made some trials today with gr-ettus under gnuradio-master and at least > was able to compile and install it (except for fosphor which seems to need > Qt4). > Automatic conversion of the grc xml files to the yml format was not > possible, so I converted one by hand (uhd_rfnoc_dma_fifo). > > I got so far that the block shows up in grc and most error messages went > away. > There are still errors, however, about 'Domain key "rfnoc" is not > registered' for the input and output ports. This is probably the reason as > well why I cannot connect anything to this block (red arrows). > > Any ideas? How do I register the rfnoc domain? Are there any serious > reasons preventing the rfnoc blocks from working under v3.8? > > Best regards, > Erik > > ___ > 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] How to compile the example alone？
Hello ruiy! The display_qt example is compiled when you compile GNU Radio with gr-qtgui. So the executable should have the following path: gnuradio/build/gr-qtgui/examples/c++/display_qt If you want to rewrite CMakeLists.txt to compile it alone, I believe I can help with that. :) I'm not an expert in CMake, but I can point you to a CMakeLists.txt that I've used for the same purpose. I have uploaded it at: https://gist.github.com/haakov/7561494f3eaf77d4259d5abea33c0c4e Hope this helps! Best regards Håkon Vågsether Den lør. 3. mar. 2018, 11.34 skrev ruiy <2997215...@qq.com>: > I discover a example about how to compile the qtgui in c++. The example's > path is "gnuradio <https://github.com/gnuradio/gnuradio>/gr-qtgui > <https://github.com/gnuradio/gnuradio/tree/master/gr-qtgui>/examples > <https://github.com/gnuradio/gnuradio/tree/master/gr-qtgui/examples>/c++/ > display_qt.cc > <https://github.com/gnuradio/gnuradio/blob/master/gr-qtgui/examples/c%2B%2B/display_qt.cc>"(The > website is https://github.com/gnuradio/gnuradio/tree/master/gr-qtgui/ > examples/c%2B%2B). But I don't know how to compile it singlely. I try to > rewrite the CMakeLists.txt. However, I fail... > So if anyone know how to compile the display_qt.cc or how to rewrite the > CMakeLists.txt, please teach me. Thanks very much! > ___ > 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 10
Hi all, I have updated my blog with my tenth and final weekly blog post. You can read more at http://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] [SOCIS '17] GRC C++ Output: Week 9
Hi all, I have updated my blog for my next to last week, providing a demonstration of my recent additions. The most important changes are the build options, my yaml_blocks_python branch and last but not least, the ability to generate QT flowgraphs in C++ with GRC! :) 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
Re: [Discuss-gnuradio] [SOCIS '17] GRC C++ Output: Week 8
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 <per...@o2.pl> 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
[Discuss-gnuradio] [SOCIS '17] GRC C++ Output: Week 8
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] [SOCIS '17] GRC C++ Output: Week 7
Hi all, I was on holiday the previous week, but I have created a poster which I have included in my latest blog post. 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
Re: [Discuss-gnuradio] Problem with tutorial 3 GNU radio in Python
Hey Shane, You can fix this by moving line 129-131: *self.blocks_throttle_0 = blocks.throttle(gr.sizeof_float*1, samp_rate,True)self.analog_sig_source_x_1 = analog.sig_source_f(samp_rate, analog.GR_SIN_WAVE, freq, ampl, 0)self.analog_sig_source_x_0 = analog.sig_source_f(samp_rate, analog.GR_SQR_WAVE, 0.1, 1, 0)* to line 55. In other words, put them right after: *self.ampl = ampl = 1* You actually only need to move the line with *analog_sig_source_x_1*, but it might be nice to have them all in one place. Best regards, Håkon Vågsether On Wed, Sep 13, 2017 at 10:37 AM, Jacqueline.Walker <jacqueline.wal...@ul.ie > wrote: > Hi Shane, > > I believe this might be the solution. According to James Shimer on this > thread, it's a race condition in the python code - read on down the thread. > Anyway, the solution works, I tried it. > > regards > Jacqueline > > From: Discuss-gnuradio [discuss-gnuradio-bounces+jacqueline.walker= > ul...@gnu.org] on behalf of Shane Petcavich [spetcav...@hme.com] > Sent: 12 September 2017 23:19:44 > To: discuss-gnuradio@gnu.org > Subject: [Discuss-gnuradio] Problem with tutorial 3 GNU radio in Python > > Hello, > > I'm having an issue with tutorial3 in https://github.com/gnuradio/ > gr-tutorial, which I have cloned and put into a directory called > solutions. I have tried this on xubuntu, 3 different installations of > ubuntu 14.04 [virtual machines], and using the GNURadio Live USB. I have > tried installing GNURadio from the binary, installing from source, and > installing with pybombs. Currently using GNURadio 3.7.12. > > When trying to run the solution if_else_mod.py in: > > examples/tutorial3/python/ > > I get the error ' top_block_sptr' object has no attribute > 'analog_sig_source_x_1' > > This was previously discussed without much solution here: > https://lists.gnu.org/archive/html/discuss-gnuradio/2013-11/msg00243.html > > Any help would be appreciated. > > Thanks, > srp > > > > ___ > 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] [SOCIS '17] GRC C++ Output: Week 6
Hi all, The first milestone has been reached! You can read more and see a demonstration of the project's current state 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] [SOCIS '17] GRC C++ Output: Week 5
Hi all, The focus for this week has been the handling of parameters and variables. 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] [SOCIS '17] GRC C++ Output: Week 4
Hi all, The focus for this week has been the CppTopBlockGenerator class. You can read more at my blog: http://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
Re: [Discuss-gnuradio] [SOCIS '17] GRC C++ Output: Week 3
Hi Martin, Yes, I will allow QT-GUI-based applications! My 7th week is dedicated to that :) Best regards, Håkon Vågsether 18. aug. 2017 16.28 skrev "Martin Braun" <martin.br...@ettus.com>: On 08/13/2017 05:01 PM, Håkon Vågsether wrote: > Hi all, > > The focus for this week has been the CMakeLists.txt template. I have > written a small demonstration of my project in its current state. You > can read more at: > > http://grccpp.wordpress.com Looking at the pictures made me wonder if you're planning to allow QT-GUI-based applications? I realize it's still way off, but I was wondering if you had already given it some thought. Cheers, Martin ___ 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 3
Hi all, The focus for this week has been the CMakeLists.txt template. I have written a small demonstration of my project in its current state. You can read more at: http://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] [SOCIS '17] GRC C++ Output: Week 2
Hi all, The focus for this week has been the source file template. I've just updated my blog with more details, you can check it out at: http://grccpp.wordpress.com If you have questions or suggestions, please don't hesitate to ask! :) Best regards, Håkon Vågsether ___ 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 1
Hi Kartik,
Thanks for asking!
What I've envisioned is that the user chooses whether he/she wants GRC to
generate C++ or Python code. Currently the blocks' YAML files only contain
data and snippets that work in Python, ("from x import y" doesn't work in
C++, of course :)) so I'll have to add the corresponding C++ data to the
blocks.
This way, GRC will know whether to use the Python or C++ "parts" of the
block when generating. Hope this cleared things up! :)
Best regards,
Håkon Vågsether
31. jul. 2017 1.47 p.m. skrev "Kartik Patel" <kartikpatel1...@gmail.com>:
Hello Håkon,
Your project is pretty interesting. Finally, we are trying to give a
platform to "C++ only" programmers, too. :P
I have one query. Are you going to connect the Python blocks in the
generated C++ script? I am not sure if it is even possible, but may be SWIG
can help. If not, then will you be looking for some parameters in the
blocks XML whether the block is Python? In other words, how are you going
to detect if it's Python block?
Thanks!
Regards,
Kartik Patel
On Mon, Jul 31, 2017 at 2:27 PM, Håkon Vågsether <hauk...@gmail.com> wrote:
> Not yet, I'll do it today :)
>
> Best regards,
> Håkon Vågsether
>
> On Mon, Jul 31, 2017 at 9:32 AM, Marcus Müller <marcus.muel...@ettus.com>
> wrote:
>
>> Hi Håkon,
>>
>> thanks for the update :) And of course, thank for the python3 bugfix! Did
>> you do a pull-request against the "mainline" gnuradio/python3 branch yet?
>>
>> Very much looking forward to the moment where we can get the first
>> compiling C++ flow graph out of GRC :)
>>
>> Best regards,
>>
>> Marcus
>>
>> On 07/31/2017 12:19 AM, Håkon Vågsether wrote:
>>
>> Hi all,
>>
>> The focus for this week has been the header file template. I've just
>> updated my blog with some more details, you can check it out at:
>>
>> http://grccpp.wordpress.com
>>
>> If you have any questions or suggestions, please don't hesitate to ask :)
>>
>> Best regards,
>> Håkon Vågsether
>>
>>
>> ___
>> 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
>
>
___
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 1
Not yet, I'll do it today :) Best regards, Håkon Vågsether On Mon, Jul 31, 2017 at 9:32 AM, Marcus Müller <marcus.muel...@ettus.com> wrote: > Hi Håkon, > > thanks for the update :) And of course, thank for the python3 bugfix! Did > you do a pull-request against the "mainline" gnuradio/python3 branch yet? > > Very much looking forward to the moment where we can get the first > compiling C++ flow graph out of GRC :) > > Best regards, > > Marcus > > On 07/31/2017 12:19 AM, Håkon Vågsether wrote: > > Hi all, > > The focus for this week has been the header file template. I've just > updated my blog with some more details, you can check it out at: > > http://grccpp.wordpress.com > > If you have any questions or suggestions, please don't hesitate to ask :) > > Best regards, > Håkon Vågsether > > > ___ > 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
[Discuss-gnuradio] [SOCIS '17] GRC C++ Output: Week 1
Hi all, The focus for this week has been the header file template. I've just updated my blog with some more details, you can check it out at: http://grccpp.wordpress.com If you have any questions or suggestions, please don't hesitate to ask :) Best regards, Håkon Vågsether ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] [SOCIS '17] GRC C++ Output - Week 0: Introduction
Hello all, I am this year's SOCIS student, and I will be working on enabling GRC to output C++ code for the next 10 weeks. I am very excited to get started with the coding, and I'd like to thank the GNU Radio community (and in particular my mentors Sebastian Koslowski and Derek Kozel) for this opportunity to get involved in the project. My blog is now live at https://grccpp.wordpress.com/, and I have forked the main gnuradio repository at https://github.com/hauk142/gnuradio/tree/python3 . PS: Luca and Kartik, I have allowed myself to take great inspiration from you both with regard to blog design. Hope you don't mind :) Great work so far and good luck with the rest of your GSoC projects! Best regards, Håkon Vågsether ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Noobie Advice -- Installing Icons, Mime Type, and Menu Items
Hi Jerry, that's great! I'm glad you figured it out. You're absolutely right, things like this can indeed drive a person crazy. It's certainly driven me crazy a couple of times. I've edited the wiki, it should be fixed now :) Best regards, Håkon Vågsether 17. jul. 2017 4.44 p.m. skrev "Jerry" <jster...@att.net>: Hi Håkon Big thank you !! I understand that many times “instructions” are not precisely correct and may be missing pieces of code punctuations, grammar, etc. However, as an entry level person to Linux – when reading a wiki page or readme file…it is exactly these subtle missing pieces that can drive a person crazy. With your help it installed quickly. Best Jerry NY2KW *From:* Håkon Vågsether [mailto:hauk...@gmail.com] *Sent:* Monday, July 17, 2017 9:59 AM *To:* Jerry <jster...@att.net> *Cc:* discuss-gnuradio@gnu.org *Subject:* Re: [Discuss-gnuradio] Noobie Advice -- Installing Icons, Mime Type, and Menu Items Hi Jerry, if I understand you correctly, you are trying to run the executable "grc_setup_freedesktop" from within its directory. This will require you to prefix the executable with "./". "." means your current directory, but perhaps you already knew that. :) So, instead of: $ sudo grc_setup_freedesktop install you'll have to do: $ sudo. /grc_setup_freedesktop install If you want more info on this, this link might be helpful: http://www.linfo.org/path_env_var.html Hope I could be of any help. Best regards, Håkon Vågsether 17. jul. 2017 3.39 p.m. skrev "Jerry" <jster...@att.net>: I am just starting on in both Linux and gnuradio so steep learning curve so far. I successfully built installed the latest gnuradio into my Ubuntu 16.04 LTS using PyBOMBS. All works fine from the command line. I would like the convenience of a GRC desktop icon and I read on the wiki.gnuradio.org page to run the following: $ cd /libexec/gnuradio/ $ sudo grc_setup_freedesktop install I allowed PyBOMBS to install gnuradio into /prefix/default. I found /prefix/default/libexec/gnuradio which contains a green file ‘grc_setup_freedesktop’ but when I run the commands $ cd /prefix/default/libexec/gnuradio/ $ sudo grc_setup_freedesktop install I get an error: sudo: grc_setup_freedesktop : command not found…but grc_setup_freedesktop is in the /libexec/ folder Any advice appreciated. Jerry ___ 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] Noobie Advice -- Installing Icons, Mime Type, and Menu Items
Hi Jerry, if I understand you correctly, you are trying to run the executable "grc_setup_freedesktop" from within its directory. This will require you to prefix the executable with "./". "." means your current directory, but perhaps you already knew that. :) So, instead of: $ sudo grc_setup_freedesktop install you'll have to do: $ sudo. /grc_setup_freedesktop install If you want more info on this, this link might be helpful: http://www.linfo.org/path_env_var.html Hope I could be of any help. Best regards, Håkon Vågsether 17. jul. 2017 3.39 p.m. skrev "Jerry" <jster...@att.net>: I am just starting on in both Linux and gnuradio so steep learning curve so far. I successfully built installed the latest gnuradio into my Ubuntu 16.04 LTS using PyBOMBS. All works fine from the command line. I would like the convenience of a GRC desktop icon and I read on the wiki.gnuradio.org page to run the following: $ cd /libexec/gnuradio/ $ sudo grc_setup_freedesktop install I allowed PyBOMBS to install gnuradio into /prefix/default. I found /prefix/default/libexec/gnuradio which contains a green file ‘grc_setup_freedesktop’ but when I run the commands $ cd /prefix/default/libexec/gnuradio/ $ sudo grc_setup_freedesktop install I get an error: sudo: grc_setup_freedesktop : command not found…but grc_setup_freedesktop is in the /libexec/ folder Any advice appreciated. Jerry ___ 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] [GSoC] GNU Radio Companion Extensions: Output C++ Code
Hi Sebastian,
awesome! :) I've had a look at your code, it looks like a sensible way to
start tackling this feature.
About the parameter values, thanks for bringing that up! It sure does
complicate things, but from what I can see your suggestion sounds like a
good plan.
Best regards,
Håkon Vågsether
31. mar. 2017 4.32 p.m. skrev "Koslowski, Sebastian (CEL)" <
sebastian.koslow...@kit.edu>:
Dear Håkon,
I am very excited to see interest in this topic! A few additional comments:
- Any new templating should be done using Mako. The new YAML format Martin
mentioned roughly looks like this:
"""
id: blocks_add_const_vxx
label: Add Const
parameters:
- id: type
label: IO Type
dtype: enum
options: [complex, float, int, short]
option_attributes:
const_type: [complex_vector, real_vector, int_vector, int_vector]
fcn: [cc, ff, ii, ss]
hide: part
- id: const
label: Constant
dtype: ${ type.const_type }
default: '0'
- id: vlen
label: Vec Length
dtype: int
default: '1'
hide: ${ 'part' if vlen == 1 else 'none' }
inputs:
- dtype: ${ type }
vlen: ${ vlen }
outputs:
- dtype: ${ type }
vlen: ${ vlen }
templates:
imports: from gnuradio import blocks
make: blocks.add_const_v${type.fcn}(${const})
callbacks:
- set_k(${const})
"""
C++ specific templates could be added under "cpp_templates" or sth.
The main part of your work would be to implement a Generator subclass. You
maybe want to checkout my latest dev version to use as a starting point [0]
Another issue is how to deal with parameter values:
Say, I have a variable with "np.pi" as value. Or specify some filter coeffs
using a list [1, 1, 1, 1,...]. Or so some calculation "2 ** 4 + 1".
Those usually end up in the generated code somewhere. For C++ that would
fail...
I suggest, that at least some simple expressions should be transpiled for
the C++ code generation.
The alternative, writing all parameter values in C++ code, would require a
separate eval, validation, - basically a C++ version of GRC.
I'd rather do everything in Python and get the C++ output as a bonus on
top. This means that all blocks must still be available in Python - even if
they are just in output C++. This way we can load and instantiate things
like filter and constellation objects during design time (before you hit
generate) and do validation with those.
Sebastian
[0] https://github.com/skoslowski/gnuradio/blob/df1e94831c05e3b8
a25e5490f50ebf9e98795182/grc/core/generator/top_block.py
On 03/31/2017 02:07 PM, Håkon Vågsether wrote:
Hi Marcus,
thank you for your feedback.
> Also, would kind of had preferred to read "I've not used GNU Radio much
> before, but I've played around with the LiveDVD (or whatever you'd have
> done)" instead of reading "I've not used GNU Radio before(at all)" and
> seeing you use pretty dated screenshots from Josh's website instead of
> familiarizing yourself quickly, so that you could leave us with the
> certainty that hey, we don't have to teach you how to even start GRC ...
> not that I really think this will be any trouble for you, but the ease of
> getting started with GNU Radio, considering ready-made packages and the
> bootable liveDVD and the guided tutorials make me wonder much more why you
> didn't demonstrate you've played with GNU Radio before.
>
Haha, I understand what you mean, and you're right! I naturally wouldn't
post my proposal draft for this project without knowing how to even start
GRC :) I have spent the last few weeks tinkering and trying to gain some
familiarity with GRC and its source. I could (and should) have just taken a
screenshot myself! I will include this in my next draft.
> Big Plus is of course that you mention Cheetah, which proves you've
> actually looked at the source code, I guess! This is probably not going to
> hurt at this stage, but as Ben said, we're currently replacing that with
> Mako (Cheetah is kinda Python2 only, and we're making things work with Py3).
>
> So, I hope this is not asking too much from your time right now (you might
> be busy with exams for all I know about studying), but I'd recommend you
> checkout the "next" branch of the gnuradio repository, and try to build it
> with GRC enabled, and maybe add some "change to
> include " to your timeline after getting a rough idea of how
> code gen works there.
>
Right! I had already built it from source, but I was on the master branch.
I've built the next branch now, and I've noticed the addition of the GRCC
compiler.py in the grc/ directory. I suppose the GSoC project might as well
include adding the build options as command line arguments to this while
I'm at it.
> I like your block diagram, it clarifies a few things, and generally, I
> prefer reading a concise chart instead
Re: [Discuss-gnuradio] [GSoC] GNU Radio Companion Extensions: Output C++ Code
Hi Martin, okay, I see. This is useful information, thanks a lot! Best regards, Håkon Vågsether There's another thing: On 3.8, we'll be going to a different model of > writing GRC bindings (YAML-based). It's difficult to summarize the > changes, but basically, don't assume that we'll be using XML files forever. > > -- M > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] [GSoC] GNU Radio Companion Extensions: Output C++ Code
Hi Marcus, thank you for your feedback. > Also, would kind of had preferred to read "I've not used GNU Radio much > before, but I've played around with the LiveDVD (or whatever you'd have > done)" instead of reading "I've not used GNU Radio before(at all)" and > seeing you use pretty dated screenshots from Josh's website instead of > familiarizing yourself quickly, so that you could leave us with the > certainty that hey, we don't have to teach you how to even start GRC ... > not that I really think this will be any trouble for you, but the ease of > getting started with GNU Radio, considering ready-made packages and the > bootable liveDVD and the guided tutorials make me wonder much more why you > didn't demonstrate you've played with GNU Radio before. > Haha, I understand what you mean, and you're right! I naturally wouldn't post my proposal draft for this project without knowing how to even start GRC :) I have spent the last few weeks tinkering and trying to gain some familiarity with GRC and its source. I could (and should) have just taken a screenshot myself! I will include this in my next draft. > Big Plus is of course that you mention Cheetah, which proves you've > actually looked at the source code, I guess! This is probably not going to > hurt at this stage, but as Ben said, we're currently replacing that with > Mako (Cheetah is kinda Python2 only, and we're making things work with Py3). > > So, I hope this is not asking too much from your time right now (you might > be busy with exams for all I know about studying), but I'd recommend you > checkout the "next" branch of the gnuradio repository, and try to build it > with GRC enabled, and maybe add some "change to > include " to your timeline after getting a rough idea of how > code gen works there. > Right! I had already built it from source, but I was on the master branch. I've built the next branch now, and I've noticed the addition of the GRCC compiler.py in the grc/ directory. I suppose the GSoC project might as well include adding the build options as command line arguments to this while I'm at it. > I like your block diagram, it clarifies a few things, and generally, I > prefer reading a concise chart instead of a wall of text, and I think that > "writing down" the current code generation process in terms of > who-calls-what in Python in that shape would be awesome, because that would > allow you to make a second, modified chart that shows what you'd like to > add/change to that, and would also be a great starting point for the > (relatively compact) documentation we'd like you to deliver in the end. > I've made another diagram to visualise this, the dotted lined objects are objects that I'm planning to implement. I've tried to leave out the non-essential details to reduce complexity. As Ben pointed out (if I understood him correctly), it might not be worthwhile to create Makefiles directly from the templates, rather just leave it all to CMake. This does make sense and will save me some work. call_diag.png <https://drive.google.com/file/d/0B1ylsmzHTJ7Ab3p6YmN6TWxfTWs/view?usp=drive_web> Best regards, Håkon Vågsether ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] [GSoC] GNU Radio Companion Extensions: Output C++ Code
Hi Ben, thank you for your comments. On Wed, Mar 29, 2017 at 6:33 PM, Ben Hilburn <bhilb...@gnuradio.org> wrote: > Hi Håkon - > > Hah, indeed, your update and my e-mail flew past each other. I just took a > read over your update, and have some further comments: > >- I see you added some design details about Cheetah. So, actually, we >are in the process of migrating to Mako. You probably didn't see this >because the work is taking place in the 3.8.x development, and is not >reflected in the current 3.7.x branches. > > Right! Thanks for pointing that out, I've been using the master branch until you made me aware of this. I noticed the code generation part is still in Cheetah, I suppose I can help out with porting to Mako? > >- I think details of how you will integrate the need to compile C++ >flowgraphs into the GRC UX will be important to call out in the proposal. > > I've attempted to create a mock-up of how I think it could look: dropdown.png <https://drive.google.com/file/d/0B1ylsmzHTJ7AcHd2UVBqUndSaEE/view?usp=drive_web> Here "Compile" has been greyed out because Python is selected. "Options" brings up a new dialog window with more build options. This is not a very drastic change from the current state of the program, and I doubt it will confuse people who aren't used to the new options. Might want to change "Run" to "Build" and "Language" to "Output" or something like that, but this might not be as important at this stage. >- One of the major complexities, here, is that there are a lot of >blocks that are Python-only. How will you deal with blocks that don't have >C++ implementations? > > Yes I see. I imagine for the time being the UI will have to give an error and refuse to switch to C++ output if there are Python-only blocks present in the flowgraph. For example, gui/NotebookPage.py could have a check_cpp_compatible() method that is called from gui/ActionHandler.py when the user tries to switch to C++ output. I suppose this method would then have to check if there are any of the blocks in the flowgraph that aren't in a list of successfully ported blocks. There's probably a more elegant way to do this, just a suggestion :) Best regards, Håkon Vågsether ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] [GSoC] GNU Radio Companion Extensions: Output C++ Code
Woops, forgot to actually add the link. gsoc.pdf <https://drive.google.com/file/d/0B1ylsmzHTJ7AQ01lNDYzMHZweVk/view?usp=drivesdk> Sorry! :) Best regards, Håkon Vågsether 29. mar. 2017 5.53 p.m. skrev "Håkon Vågsether" <hauk...@gmail.com>: Hi Marcus, thank you for your feedback! You've made some very sound points. I agree with your comments on the order of events, it makes a lot of sense and sounds like a more sensible approach to this project. I also understand that you'd like me to emphasize more on my plan, and I have tried to do so in a new version of my proposal below. You're more than welcome to have another look at it, and please don't hesitate to notify me if I should correct or add something. I believe I've addressed all of your concerns :) Best regards, Håkon Vågsether On Sun, Mar 26, 2017 at 4:48 PM, Marcus Müller <marcus.muel...@ettus.com> wrote: > Dear Håkon, > > cool! The C++ output option for GRC has been on many wishlists for a long > long time. > > I do like the brevity of your proposal, however I miss a bit of you > describing *how* exactly you want to do things, and what to focus on in > which order. We're well aware of this specific idea being displayed very > generally in the ideas list; that has the purpose of letting you pick and > discuss your focus very freely. If I understand your timeline properly, > your order of things is > >1. Add GUI elements to GRC to make it to connect functionality later >2. C++ code generator >3. Build system infrastructure > > Having the UI interface as first item seems like a positive approach to > get to know the Python code of GRC a little better. I do think it kind of > could wait until you'd actually be able to generate C++ code – that'd give > you the chance to get a lot of feedback early and change directions of how > you do things; GRC in it's current situation is relatively well split > between the GUI and the (Python) code generation. > > I assume you've had a rough look at how Python generation in GRC works > right now (block_name.xml files describe the GRC blocks, including the code > that has to be called to instantiate an instance of the GNU Radio block > class, and how these blocks are set up and connected is described in > flow_graph.grc files; the actual python code is a template filled with the > info from these). > > Now, in a first approach, this would "only" (as if) be a matter of adding > new templates for the generated code, and new tags to the .xml files that > describe which C++ code to call – but it would still be great to see you > reflect a bit on whether you deem the same (Python-generation) templating > infrastructure suitable for this use case (really, doesn't have to be > in-depth – this is just a proposal) or whether you'd think there's things > to change. > > Same goes for the "Makefile" generation. We really won't nail you down on > what you propose now, but you giving a vision (maybe in a quick block > diagram) of how the Makefile (or build system, in general – we use CMake in > GNU Radio, and if you'd have another idea how to generate an executable > from the C++ you generate, don't be shy, we can and will gently criticize > if we found that necessary ;) ) will come together, and give maybe a list > of infos on what info comes from where and ends up in the C++ header and > the main source file and the Makefile, it'd give me a fuzzy warm feeling > about you having a plan how to approach things. > > So: I like your project proposal, but I like it so much that I'd want to > see more of a proposed idea here. I think both Felix and Sebastian don't > want to mentor you as a "code monkey" – the whole project would very much > value you as active critic and architect of "how things are done" in GRC > and GNU Radio in general, so it's kind of important to us that you > emphasize how your plan is more than what the Idea from the GSoC Ideas List > already defines. > > Best regards, > > Marcus > On 03/26/2017 02:20 PM, Håkon Vågsether wrote: > > Hello! > > My name is Håkon Vågsether, and I am a first year MSc student in > Cybernetics and Robotics at NTNU's (Norwegian University of Science and > Technology, Trondheim). I am very interested in participating in GSoC 2017 > for GNU Radio and I have added a link below to my proposal draft for the > GRC C++ output idea for this year's GSoC. I believe I have added everything > that was required, but I suppose I will have to be more specific with the > deliverables and milestones in the final proposal. I would love some > feedback, and if I have misinterpreted or neglected something, please tell > me so I can fix it for the final proposal! :) I am really excited to get in > t
[Discuss-gnuradio] [GSoC] GNU Radio Companion Extensions: Output C++ Code
Hello! My name is Håkon Vågsether, and I am a first year MSc student in Cybernetics and Robotics at NTNU's (Norwegian University of Science and Technology, Trondheim). I am very interested in participating in GSoC 2017 for GNU Radio and I have added a link below to my proposal draft for the GRC C++ output idea for this year's GSoC. I believe I have added everything that was required, but I suppose I will have to be more specific with the deliverables and milestones in the final proposal. I would love some feedback, and if I have misinterpreted or neglected something, please tell me so I can fix it for the final proposal! :) I am really excited to get in touch with you all and (hopefully) get started with this project. Thanks a lot! Best regards, Håkon Vågsether https://drive.google.com/file/d/0B1ylsmzHTJ7AQ01lNDYzMHZweVk/ view?usp=drivesdk ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
