Hi Prasoon - Welcome to the world of GNU Radio! A few questions to help
clarify your query:
What OS are you using? Guessing Windows but just checking.
How did you install GR? and its dependencies? ... from source, from an
archive, something else?
Cheers! - MLD
On Fri, Dec 28, 2018, at 6:13 AM,
i corrected) , could see
> error:PyQt4,gnuradio modules not found.I installed
> PyQt4-4.11.4-gpl-Py2.7-Qt4.8.7-x64.exePyQt4 from riverbank ,but still the
> error shows up.Really appreciate help!
>
> Note:Both python2.7 and python3 installed in the machine.
>
> Thanks and regards
&g
Hi Albin - Thank you for all of your work here! I haven't tested it out, but
reading through it (and other PRs) you're really helping Volk along for NEON.
I'm not going to review this PR, just comment about PRs in general ... for now.
In general for GR / Volk PRs: Keep them targeted and simple;
Maybe some of you have noticed that I've been working on getting volk
1.4 and gnuradio 3.8 to compile and cross compile for ARM with clang
(specifically clang 7 but seems to work down to at least 3.8).
I'm happy to say that it's working pretty well now! Volk with neon
support works and most of
Here's a summary of of comments that have come up in chat:
- Andrej recommended using PyBind11, a close cousin to boost.python. it
comes recommended by Sebastian Koslowski also. It's only a few headers and
we could ship it as part of the source tree.
- The question arose if we even need the
7-Qt4.8.7-x64.exePyQt4 from riverbank ,but still the
error shows up.Really appreciate help!
Note:Both python2.7 and python3 installed in the machine.
Thanks and regards
Prasoon
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.gnu.org/archive/html/di
Hi All,
I'm new to GNU Radio.
1.I installed 3.7.13.4 version.
2.I tried running the generated python scripts from GNU Radio Companion as
shown in tutorial.
3.But along with some syntax errors(which i corrected) , could see
error:PyQt4,gnuradio modules not found.I installed
On Fri, Dec 28, 2018 at 2:43 PM Müller, Marcus (IEH)
wrote:
> For them, that's very important, as they use that to supply resilient
> infrastructure. I hope I'm representing the idea kinda correctly here:
> They might want to log system events ("SUPERVISOR: INFO system load
> surpassing 75%")
The second release candidate of UHD version 3.13.1.0 has been tagged and is
available for testing. It has been a little while, but we deliberately
slowed down to fix several issues in an attempt to make UHD more stable.
There have been 150 commits since the 3.13.0.2 release just 4 months ago
and
I think many users, myself included, use logs for debugging. I would
hesitate to have the log messages propagate through the very system that
you are trying to debug with said messages. I would rather the logs be
emitted from the system under test as simply and promptly as possible. I
think
I'll second what Jared wrote, and add the following: I'd like -any-
logging GR uses to provide protected printing, such that logged messages
do not interleave. [Obviously, unlogged messages might interleave /
intermix; all depends on the actual printing interface.] Trying to parse
such interleaved
Hi Martin, hi Community,
first of all: thanks for all the fish err GREPs! We need to kick off
this discussion.
So, this PR is very dear to my heart, because I consider log4cpp to be
an especially problematic dependency.
And I consider our logging to be subpar considering the size of the
code
12 matches
Mail list logo
