discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: gr 3.9 OOT execution error: unknown base type gr::block


From: Tom McDermott
Subject: Re: gr 3.9 OOT execution error: unknown base type gr::block
Date: Wed, 5 May 2021 11:09:41 -0700

HI Josh - here is the entire file ./python/bindings/python_bindings.cc:

/*
 * Copyright 2020 Free Software Foundation, Inc.
 *
 * This file is part of GNU Radio
 *
 * SPDX-License-Identifier: GPL-3.0-or-later
 *
 */

#include <pybind11/pybind11.h>

#define NPY_NO_DEPRECATED_API NPY_1_7_API_VERSION
#include <numpy/arrayobject.h>

namespace py = pybind11;

// Headers for binding functions
/**************************************/
/* The following comment block is used for
/* gr_modtool to insert function prototypes
/* Please do not delete
/**************************************/
// BINDING_FUNCTION_PROTOTYPES(
    void bind_hermesNB(py::module& m);
    void bind_hermesWB(py::module& m);
// ) END BINDING_FUNCTION_PROTOTYPES


// We need this hack because import_array() returns NULL
// for newer Python versions.
// This function is also necessary because it ensures access to the C API
// and removes a warning.
void* init_numpy()
{
    import_array();
    return NULL;
}

PYBIND11_MODULE(hpsdr_python, m)
{
    // Initialize the numpy C API
    // (otherwise we will see segmentation faults)
    init_numpy();

    // Allow access to base block methods
    py::module::import("gnuradio.gr");

    /**************************************/
    /* The following comment block is used for
    /* gr_modtool to insert binding function calls
    /* Please do not delete
    /**************************************/
    // BINDING_FUNCTION_CALLS(
    bind_hermesNB(m);
    bind_hermesWB(m);
    // ) END BINDING_FUNCTION_CALLS
}

-- Tom, N5EG




On Wed, May 5, 2021 at 9:41 AM Josh Morman <mormjb@gmail.com> wrote:
That looks right.  And in python_bindings.cc, do you see the import of base block methods like:

PYBIND11_MODULE(blocks_python, m)
{
    // Initialize the numpy C API
    // (otherwise we will see segmentation faults)
    init_numpy();

    // Allow access to base block methods
    py::module::import("gnuradio.gr");

On Wed, May 5, 2021 at 11:21 AM Tom McDermott <tom.n5eg@gmail.com> wrote:
Hi Josh - thanks for your help.

from ./python/bindings/hermesNB_python.cc:

void bind_hermesNB(py::module& m)
{

    using hermesNB    = ::gr::hpsdr::hermesNB;


    py::class_<hermesNB, gr::block, gr::basic_block,
        std::shared_ptr<hermesNB>>(m, "hermesNB", D(hermesNB))

        .def(py::init(&hermesNB::make),
           py::arg("RxFreq0"),
... long list of arguments...
          D(hermesNB,make)
        )

-- Tom, N5EG


On Wed, May 5, 2021 at 7:26 AM Josh Morman <mormjb@gmail.com> wrote:
Tom,

What does your hermesNB_python.cc look like?

There should be a declaration for the binding in there that looks like:
    py::class_<block_name,
               gr::sync_block,
               gr::block,
               gr::basic_block,

or something to that effect.  It could be that modtool didn't add the parent classes so that the inherited methods show up in the bindings.  If so, that is a bug.  I'm just thinking that what you are seeing would be the case if gr:;block wasn't a part of the declaration of the binding (which should happen automatically)

I don't think it is related to the capitalization of the category name - in the code, the module is all lowercase.

Josh

On Wed, May 5, 2021 at 10:20 AM Tom McDermott <tom.n5eg@gmail.com> wrote:
I'm working on porting my OOT to gr 3.9  The 3.7 and 3.8 versions work fine.
The ported code is compiled and make installed.  My OOT is visible in GRC, and
I've added to a new flowgraph.

My OOT is in category HPSDR  and the module is hermesNB (of several).

When I try to execute a simple flowgraph in GRC with this OOT I get the following error:

Traceback (most recent call last):
  File "/home/tom/Desktop/Test_AM.py", line 38, in <module>
    import hpsdr
  File "/usr/lib/python3/dist-packages/hpsdr/__init__.py", line 18, in <module>
    from .hpsdr_python import *
ImportError: generic_type: type "hermesNB" referenced unknown base type "gr::block"

Do I need to add code somewhere to import gr::block   ??

Is there an issue with capitalization of  hpsdr  vs. category name of HPSDR  ??

-- Tom, N5EG





reply via email to

[Prev in Thread] Current Thread [Next in Thread]