| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Signed-off-by: Josh Morman <jmorman@gnuradio.org>
|
| |
|
|
| |
Signed-off-by: Håkon Vågsether <hauk142@gmail.com>
|
| |
|
|
|
|
|
|
|
| |
Flowgraphs may use oot modules. When generating cpp code an oot module
may require a package that is not provided by gnuradio.
So I propose to add an additional entry parameters in the cpp template
to provide a list of package names.
Signed-off-by: Volker Schroer <3470424+dl1ksv@users.noreply.github.com>
|
| |
|
|
| |
Signed-off-by: Marcus Müller <mmueller@gnuradio.org>
|
| |
|
|
|
|
|
| |
Make all ports follow the `vlen` of their master port the same way it is
for `dtype`. Fixes #4634.
Signed-off-by: Solomon Tan <solomonbstoner@yahoo.com.au>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I refer to the mailing list thread on May 8 2021 regarding "Embedded
Python Block Tutorial Param ID Error".
The bug is caused by #4522 as names of embedded python blocks
such as `epy_block_0` are blacklisted because of "blocks" in the
argument `black_listed_ids`. It affects both embedded python blocks and
modules. This commit fixes the bug by granting exemption for these two
types of blocks from id validation.
This commit makes the regex more strictly follow the naming convention
of epy blocks and modules so that only these will be fast-tracked
through the id validation. The naming convention appears to be a "epy"
prefix, followed by "block" or "module", and a number suffix.
This regex also takes into account the user copying-and-pasting the epy
blocks resulting in id names like `epy_block_0_0` and `epy_block_0_0_0`.
Instead of checking for epy blocks or modules using the naming
convention in the id like commit ac383d1 does, this commit checks by
looking at the block's key. All epy blocks and modules are identified
with the key `epy_block` and `epy_module` respectively.
This commit fixes the bug by changing the import name such that it does
not coincide with the generated id for epy blocks and modules. This
means that there no longer needs to be an exception case in the
validation id function for epy blocks and modules.
This commit fixes the bug by giving epy blocks and modules a new
attribute that grants them exemption from blacklist id validation.
Unlike v1, v2 and v3, this does not depend on the naming convention of
the block ids or block keys, which could change in the future, making
the code less of a hassle to maintain.
Improved on v5 (commit b85da80) with the following changes.
1. Changed `exempt_from_id_validation` from an instance variable to a
class variable since all instances of epy blocks and modules are
affected by the bug mentioned in v5.
2. Changed `hasattr` to `getattr` to prevent the bug where a block is
exempted from id validation when `exempt_from_id_validation=False`.
Improved from v6 (commit e66ed85). This grants the exemption to
blocks/modules only after they are marked for blacklist. This change
makes sure that the id exemption is used only to prevent the
blacklisting bug. The blocks/modules will still go through other forms
of id validation such as the naming convention check.
Signed-off-by: Solomon Tan <solomonbstoner@yahoo.com.au>
|
| |
|
|
|
|
|
|
|
|
| |
Run the option_attributes validation routine on the extended dictionary,
i.e., after inheriting the properties from the base_key parameter. By
doing so, if the dtype property is inherited, the
_validate_option_attributes still sees it and does not throw a key
error.
Signed-off-by: Igor Freire <igor@blockstream.com>
|
| |
|
|
| |
...so they play nice with epy modules generated from other fg in the same dir
|
| | |
|
| |
|
|
|
|
|
|
| |
update_bus_logic() is called when disabling a bus, it doesn't check if
it's been previously enabled. This causes it to restore port.hidden with
a None which ultimately is converted to False. So it never hides the
message ports.
Also, filter message ports from buses.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
All of the removed `from __future__ import` were needed in older
versions of Python (mostly 2.5.x and below) but later became mandatory
in most versions of Python 3 hence are not necessary anymore.
More specifically, according to __future__.py[1]:
- unicode_literals is part of Python since versions 2.6.0 and 3.0.0;
- print_function is part of Python since versions 2.6.0 and 3.0.0;
- absolute_import is part of Python since versions 2.5.0 and 3.0.0;
- division is part of Python since versions 2.2.0 and 3.0.0;
Get rid of those unnecessary imports to slightly clean up the codebase.
[1] https://github.com/python/cpython/blob/master/Lib/__future__.py
|
| | |
|
| |
|
|
| |
amongst other things, allows assert statements to use items within namespaces the blocks import
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
The underlying issue is that the built in blocks all end up getting the
'cpp' flag, which is not valid for the embedded python blocks
To fix this some work needs to be done in the "Flags" class, as all the
flags added to classes that get accumulated in the build_ins list get
added to all the classes
See register_build_in
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Added support for C++ std::map<> from python dict
- Fixed default initialization of parameters in main()
- Added missing include for realtime scheduling
- Added default CMake option for std=c++11 as this is required for
gnuradio >= 3.8
- Fixed mako template to add initialization to parameter declarations in
main()
- Fixed C++ constructor initialization list generation
- Fixed parameter type determination when an lvalue is used in an rvalue
expression
- Improved determining type of C++ variables
- Added C++ support for gr_complex parameters
- Fixed C++ generation of nested container types
- Added C++ support for virtual source/sink
- Moved cmake CMAKE_CXX_STANDARD 11 option from options.yml to
CMakeLists.txt.mako
- Fixed qtqui_sink to allow multiple instances
- Revised virtual connection processing in cpp_top_block.py
Reviewed-By: Håkon Vagsether <hauk142@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
| |
This feature adds the ability to insert arbitrary code into the python
flowgraph. It gives a little more low-level flexibility for quickly
modifying flowgraphs and adding custom bits of code rather than having
to go and edit the generated py file
One example is synchronizing multiple USRP objects - sometimes you want
different sync than what is offered in the multi-usrp object, so you can
put a bit of code in the snippet block to do the custom synchronization
|
| | |
|
| |
|
|
|
|
| |
It is necessary to have access to the show_id flag for a python module
in grc to be able to access it elsewhere. This adds the flag when the
module object is created in the block library.
|
| | |
|
| | |
|
| |
|
|
| |
Couple of leftover todos from the copy of busports code from 3.7
|
| |
|
|
|
|
|
|
| |
Bus ports had not been added back in since the refactor of grc
Hopefully this fully enables busports though there are still some
issues with the gr-fec flowgraphs
Fixes #2277
|
| |
|
|
| |
useful for variable and parameter blocks, but maybe others too
|
| |
|
|
|
| |
An older version of PR 2278 was accidently merged by me.
This fixup brings in the correct changes to dummy.py
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Before this fix, it was not possible to add a 'Python Module' to a GRC
flow graph, it would just throw exceptions when you tried.
|
| |
|
|
|
| |
Avoid erroring out for block that don't have C++ constructors (e.g.
virtual sinks).
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Enabling the option_attributes to be accessed by the rest of the
block's parameters by using a new string subtype. Also adding
validation.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
4340e4fe836d525ce30cd0a884400b77222a1848)
|
| | |
|
|
|
Includes basic converter from XML/Cheetah to YAML/Mako based block format.
|
