| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Signed-off-by: Josh Morman <jmorman@gnuradio.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
| |
...so they play nice with epy modules generated from other fg in the same dir
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| | |
|
| |
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
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.
|
|
|
Includes basic converter from XML/Cheetah to YAML/Mako based block format.
|
