GRCon 2022 - Washington DC - Sept. 26 - 30

[Josh Morman]

Greetings GNU Radio Community!

We are excited to announce that we are planning for GRCon 2022 to be run as
an in-person event September 26-30 at the Capital Hilton
 in Washington DC.  If you know you
will be planning to come, you are encouraged to go ahead and book your room
here:

https://book.passkey.com/go/GNU2022

Reservation line: (800) 405-0064

Group Code: GNU

GRCon 2022 will celebrate and showcase the substantial and remarkable
progress of GNU Radio and its usage in a diverse field of applications and
industries.  It is a week-long conference that includes high-quality
technical content and valuable networking opportunities. GRCon is a venue
that highlights design, implementation, and theory that has been
practically applied in a useful way. GRCon attendees come from a large
variety of backgrounds, including industry, academia, government, and
hobbyists.

More details about the event for participants and attendees will be updated
on the event website here: https://events.gnuradio.org/e/grcon22, but
please go ahead and start thinking about what great work you would like to
present at this year’s conference - the Call for Participation will be
announced soon.

If you have questions or would like to find out more about becoming one of
our valued sponsors please contact us at gr...@gnuradio.org.  Note that
this event can only be successful because of our sponsors - please see the
sponsors  that made
GRCon21 possible.

Since GRCon is run by a group of volunteers, we are also looking for people
to help with both the planning of and assisting during the event.  If you
are interested in volunteering in any capacity, please reach out to us
gr...@gnuradio.org

Sincerely,

The GRCon22 Organizers

Re: [VOLK] Release 2.5.1

[Marcus Müller]

Cursory glance at `git diff v2.5.0..v2.51 **/**.h` tells me you didn't change anything 
ABI-wise.


Cheers,
Marcus

On 14.02.22 13:38, Johannes Demel wrote:

Hi all,

while I did not run the ABI compliance checker to compare 2.5.0 vs 2.5.1 specifically, it 
is simple and can be done with this tool:

https://lvc.github.io/abi-compliance-checker/#ABI_Dumper
So far, we were able to keep the ABI compatible across VOLK 2.x.
Also, we didn't change any function signatures of existing functions.

It might be a worthwhile undertaking to add an ABI compliance checker to our CI.

The VOLK library is written in C. Here, we rely on C11. Also, we require cpu_features 
because detecting such features across systems and architectures is terribly difficult.


Then, the questions are: Why Boost, why C++17 at all?
We use tools around our library. The volk_profile utility and our tests are written in 
C++. Here, we need to write the profile results to a file. In the past, we used 
`boost::filesystem` to achieve this. `boost::filesystem` basically became part of C++17 
with `std::filesystem`. Thus, we use `std::filesystem` now.


Cheers
Johannes

On 13.02.22 12:08, Jeff Long wrote:

Fons - filesystem is used for the volk_profile utility.

Chris - do not assume ABI compatibility. A number of small things have changed in ".h" 
files.


On Sat, Feb 12, 2022 at 6:19 PM Chris Vine > wrote:


    On Sat, 12 Feb 2022 11:40:26 +0100
    Johannes Demel mailto:de...@ant.uni-bremen.de>> wrote:
 > Hi everyone!
 >
 > You can find the news at
    https://www.libvolk.org/release-v251.html
     as well.
 >
 > We have a new VOLK release! We are happy to announce VOLK v2.5.1! We
 > want to thank all contributors. This release wouldn't have been
    possible
 > without them.

    Hi,

    Is this ABI compatible with volk-2.5.0 (or put another way, if I
    upgrade from volk-2.5.0 will I need to recompile gnuradio)?

    Chris

Re: Are there firls and kaiser filter methods for C++ OOT?

[George Edwards]

Thank you very much Marcin!
George

On Sun, Feb 13, 2022, 11:05 PM Marcin Puchlik 
wrote:

> Hello George,
> Yes, there is. Check this out:
> https://www.gnuradio.org/doc/doxygen/firdes_8h_source.html
> https://www.gnuradio.org/doc/doxygen/pm__remez_8h.html
> BR,
> Marcin
>
> pon., 14 lut 2022 o 00:07 George Edwards 
> napisał(a):
>
>> Hello GNURadio Community,
>>
>> I am designing a Gnuradio OOT block in C++. Are there firls and kaiser
>> filter methods (analogous to the scipy package methods that one would use
>> in Python OOT) that I can call to generate coefficients.
>>
>> Thank you!
>>
>> Regards,
>> George
>>
>

Re: segfault in 3.10.1.1

[Steven Barbo]

Hi Franco.
Thank you so much for the trace information.
Very helpful and, i'm having fun poking around under the hood.

233   execve("/usr/bin/gnuradio-companion", ["gnuradio-companion",
"/UNUSED/testing123.grc"], 0x7fffb6e6d940 /* 8 vars */) = 0
247   execve("/usr/bin/dbus-launch", ["dbus-launch", "--autolaunch",
"95afc6e6d7a14382a620df11724dd0ec", "--binary-syntax", "--close-stderr"],
0x719900 /* 8 vars */) = 0
249   execve("/usr/bin/dbus-daemon", ["/usr/bin/dbus-daemon",
"--syslog-only", "--fork", "--print-pid", "5", "--print-address", "7",
"--session"], 0x7fff2a2c23e8 /* 8 vars */) = 0
253   execve("/usr/libexec/at-spi-bus-launcher",
["/usr/libexec/at-spi-bus-launcher"], 0xe44c00 /* 11 vars */) = 0
257   execve("/usr/bin/dbus-daemon", ["/usr/bin/dbus-daemon",
"--config-file=/usr/share/default"..., "--nofork", "--print-address", "3"],
0x7ffdaf0ca728 /* 11 vars */) = 0
258   execve("/usr/bin/gsettings", ["gsettings", "get",
"org.gnome.desktop.interface", "gtk-theme"], 0x719900 /* 8 vars */) = 0
275   execve("/usr/bin/dbus-launch", ["dbus-launch",
"--autolaunch=95afc6e6d7a14382a62"..., "--binary-syntax",
"--close-stderr"], 0x719900 /* 8 vars */) = 0
310   execve("/usr/libexec/at-spi2-registryd",
["/usr/libexec/at-spi2-registryd", "--use-gnome-session"], 0x9f7d30 /* 11
vars */) = 0
314   execve("/usr/bin/python3", ["/usr/bin/python3", "-u",
"/UNUSED/testing123.py"], 0x719900 /* 8 vars */) = 0


On Sun, Feb 13, 2022 at 11:04 AM Franco VENTURI 
wrote:

> Steve,
> I am glad to hear that you are now able to run GNU Radio Companion there.
> I am not familiar with the internals of GTK and GObjects and I can't
> really help you there.
>
> However this morning I ran GRC on a simple FM receiver example I have, and
> I used strace to track the calls to 'execve':
>
> strace -f -e execve -o /tmp/grc.trc gnuradio-companion
> FM-Receiver-RSPdx.grc
>
> The output from 'strace' here shows only these processes being launched
> directly by GRC:
>
> 6439 execve("/usr/local/bin/gnuradio-companion", ["gnuradio-companion",
> "FM-Receiver-RSPdx.grc"], 0x7ffc04bea340 /* 75 vars */) = 0
> 6450 execve("/bin/gsettings", ["gsettings", "get",
> "org.gnome.desktop.interface", "gtk-theme"], 0x55652906a3d0 /* 75 vars */)
> = 0
> 6456 execve("/usr/bin/python3", ["/usr/bin/python3", "-uc", "import runpy;
> runpy.run_path('/u"...], 0x55652906a3d0 /* 75 vars */) = 0
> 6529 execve("/usr/bin/python3", ["/usr/bin/python3", "-u",
> "/home/franco/SDR/gr-sdrplay3/exa"...], 0x55652906a3d0 /* 75 vars */) = 0
>
> I don't see GRC launching other additional processes directly; in my case
> some of processes you show in your message are part of the OS common
> services (for instance here I see a service called 'dbus-broker').
>
> Franco
>
>
> On 02/12/2022 10:25 PM Steven Barbo  wrote:
>
>
> Hello patient and helpful folks, hope this day finds you well.
> Have had some "success", gui runs appears work fine, not calling the
> offending functions  g_free and ffi_closure_free in
> gobject-introspection-1.70.0/girepository/girffi.c
>
> guessing these are the parameter linkages and walking trail for
> circuit path for each block etc.?
> no idea where this is even called from, wow there is a lot going on...
>
> **
>  * g_callable_info_free_closure:
>  * @callable_info: a callable info from a typelib
>  * @closure: ffi closure
>  *
>  * Frees a ffi_closure returned from g_callable_info_prepare_closure()
>  */
> void
> g_callable_info_free_closure (GICallableInfo *callable_info,
>   ffi_closure*closure)
> {
>   GIClosureWrapper *wrapper = (GIClosureWrapper *)closure;
>
>   //g_free (wrapper->ffi_closure.cif->arg_types);
>   //ffi_closure_free (wrapper->writable_self);
>
>   printf("%s ( [callable_info-> dummy1=%d, dummy2=%d, dummy3=%x,
> dummy4=%x, dummy5=%x, dummy6=%d, dummy7=%d,
> padding[0]=%x,padding[1]=%x,padding[2]=%x,padding[3]=%x], [closure-> ... ]
> )\n",__func__,callable_info->dummy1,callable_info->dummy2,callable_info->dummy3,callable_info->dummy4,callable_info->dummy3,callable_info->dummy6,callable_info->dummy7,callable_info->padding[0],callable_info->padding[1],callable_info->padding[2],callable_info->padding[3]);
>
> }
>
>
> typedef struct _GIBaseInfoStub {
>   /*  */
>   gint32 dummy1;
>   gint32 dummy2;
>   gpointer dummy3;
>   gpointer dummy4;
>   gpointer dummy5;
>   guint32  dummy6;
>   guint32  dummy7;
>   gpointer padding[4];
> } GIBaseInfo;
>
> /**
>  * GICallableInfo:
>  *
>  * Represents a callable, either #GIFunctionInfo, #GICallbackInfo or
>  * #GIVFuncInfo.
>  */
>
> 5.1# gnuradio-companion --log debug
>
> [DEBUG] Starting GNU Radio Companion (3.10.2) (main.py:70)
> [DEBUG] Loading platform (main.py:76)
> [DEBUG] Loading application (main.py:86)
> [DEBUG] Running (main.py:88)
> <<< Welcome to GNU Radio Companion 3.10.1.1 >>>
>
> Block paths:
> /usr/share/gnuradio/grc/blocks
>
> Loading: "/UNUSED/testing123.grc"
> >>> Done
> g_callable_info_free_closure ( [callable_info-> dummy1=2, dummy2=6,

Re: [VOLK] Release 2.5.1

[Johannes Demel]

Hi all,

while I did not run the ABI compliance checker to compare 2.5.0 vs 2.5.1 
specifically, it is simple and can be done with this tool:

https://lvc.github.io/abi-compliance-checker/#ABI_Dumper
So far, we were able to keep the ABI compatible across VOLK 2.x.
Also, we didn't change any function signatures of existing functions.

It might be a worthwhile undertaking to add an ABI compliance checker to 
our CI.


The VOLK library is written in C. Here, we rely on C11. Also, we require 
cpu_features because detecting such features across systems and 
architectures is terribly difficult.


Then, the questions are: Why Boost, why C++17 at all?
We use tools around our library. The volk_profile utility and our tests 
are written in C++. Here, we need to write the profile results to a 
file. In the past, we used `boost::filesystem` to achieve this. 
`boost::filesystem` basically became part of C++17 with 
`std::filesystem`. Thus, we use `std::filesystem` now.


Cheers
Johannes

On 13.02.22 12:08, Jeff Long wrote:

Fons - filesystem is used for the volk_profile utility.

Chris - do not assume ABI compatibility. A number of small things have 
changed in ".h" files.


On Sat, Feb 12, 2022 at 6:19 PM Chris Vine > wrote:


On Sat, 12 Feb 2022 11:40:26 +0100
Johannes Demel mailto:de...@ant.uni-bremen.de>> wrote:
 > Hi everyone!
 >
 > You can find the news at
https://www.libvolk.org/release-v251.html
 as well.
 >
 > We have a new VOLK release! We are happy to announce VOLK v2.5.1! We
 > want to thank all contributors. This release wouldn't have been
possible
 > without them.

Hi,

Is this ABI compatible with volk-2.5.0 (or put another way, if I
upgrade from volk-2.5.0 will I need to recompile gnuradio)?

Chris