I'm encountering the same problem on maint. And I did remember to rebuild.
I removed the build directory, recreated it, and started over with cmake
just to be sure. It's the same stack trace.
On Fri, Feb 21, 2014 at 7:54 PM, West, Nathan
wrote:
> If you just want to get back to a system that p
If you just want to get back to a system that passes QA you should
just be able to build off of maint.
On Fri, Feb 21, 2014 at 6:05 PM, Kelly Boswell wrote:
> I removed the implementation of volk_malloc that uses posix_menacing by
> commenting everything from the #if to #else and the final #endif
I removed the implementation of volk_malloc that uses posix_menacing by
commenting everything from the #if to #else and the final #endif but the
segmentation fault remains. I noticed it's being called in a few other
files as well. Do I need to remove those, too? Thanks in advance.
On Feb 21, 2014 1
Hi Guys,
Ok, I have found out how to make it work reliably. You must register a
listener with set_msg_handler, and then you will get the missing
messages there.
In light of this, I do not see how pdu_to_tagged_stream could work
reliably. It does not register a listener (but it does not block
eith
Just came across a typo in gr_fmdet_cf.cc (compare to previous version to
see the correct code). Line 87 currently reads:
Sdot = d_scl * (-S0+d_8*S1-d_8*S1+S4);
Note that the middle two terms are identical and therefore don't do
anything. The correct code should read:
Sdot = d_scl * (-S0+d_8
Hi Guys,
I am using the messaging support of basic_block registering the
message queue with message_port_register_in and removed the obtained
messages with delete_head_blocking. This block is producing streams
and everything seems to work fine as long as I consume the messages
fast enough. However
Do you think that if I go back and try to install GR 3.7.0 instead, it may
work ?
--
View this message in context:
http://gnuradio.4.n7.nabble.com/Issue-while-installing-GR-3-7-tp46435p46466.html
Sent from the GnuRadio mailing list archive at Nabble.com.
___
I just pushed the latest WIP for fixing gr-audio on OSX; I hope some
adventurous OSX users can test this branch out & provide feedback! If you want
to help, but don't know how, ask me and I'll provide instructions. - MLD
< https://github.com/michaelld/gnuradio/tree/fix_gr_audio_osx >
Fixes tha
Thank you.
I have another question.
I have a strange situation where I have two sub-flowgraphs. The two
sub-flowgraphs are connected by a message queue. The 1st Sink can talk to the
2nd Source through this queue.
TOP BLOCK{
1st subgraph [1st Source]——[…]——[1st Sink]
2nd subgraph [2
Hi Ruecan,
this just the question if we should move away from
#ifndef INCLUDED_FILENAME_OF_HEADER_H
#define INCLUDED_FILENAME_OF_HEADER_H
#endif
to the more sanity-ensuring
#pragma once
preprocessor directive.
Sadly, this was not related to your problem...
Still have no idea what's causing
Well don't worry, it wasn't actually causing problems ;)
After fixing, I got out my zsh-foo and tried
echo $(( $(git ls-files |grep .h$|xargs git grep --heading "#ifndef INCLUDED"|wc -l) -
$(git ls-files |grep .h$|xargs git grep --heading "#ifndef INCLUDED"| uniq | wc -l) ))
luckily, there are n
Guys,
I re make from clean but still got the same error.
PS: after pulling the bugfix, do I need to execute any other command, other
than
*git pull https://github.com/marcusmueller/gnuradio.git
master_fix_message_strobe_random_ifndef *
Tim, I did not get what you mean by
Tim O'Shea wrote
> chan
good find, this was probably my fault - sorry
We should consider changing headers to use "#pragma once" which is
simpler and less error prone
do people still use gcc older than 3.4 ? I think this is pretty widely
supported now
not sure if that would cause swig issues as well -
-Tim
On 02/21/2
Thank you, Tom. I'll try that after I'm off of work tonight. And thank you
for the great ideas, Nathan.
On Fri, Feb 21, 2014 at 2:39 AM, West, Nathan
wrote:
> On Thu, Feb 20, 2014 at 11:25 PM, Kelly Boswell
wrote:
>> After the make test failed for this module, I decided to poke around to
see
>> i
Yeah, start completely clean.
Very Respectfully,
Dan CaJacob
On Fri, Feb 21, 2014 at 11:17 AM, Ruecan wrote:
> I just pulled the changes then did make but get the same error.
>
> I am not so familiar with git. After pulling your bugfix, do I need to make
> clean, remove the CMakeCache then do
I just pulled the changes then did make but get the same error.
I am not so familiar with git. After pulling your bugfix, do I need to make
clean, remove the CMakeCache then do cmake again then make or am I missing
some part of the process.
--
View this message in context:
http://gnuradio.4.n
On 02/20/2014 11:32 AM, Syed Aqeel Raza wrote:
> Kindly assist me and point out the mistake I've made, waiting for
> earliest reply. Thanks.
Syed,
this not a reasonable thing to ask for here. You have built an entire
transceiver chain, and all you tell is that "it's not working".
Unless someone
Ruecan:
I got carried away. This is indeed a bugfix for the header file not being
processed in some cases, but since the error appeared although actually
processing the fixed header file, I've run out of ideas, still.
On 02/21/2014 04:37 PM, Marcus Müller wrote:
Should be :)
Just as side info:
On 02/21/2014 04:37 AM, Ed Criscuolo wrote:
> I checked the code, and indeed, there is no method by any name
> for setting the loop_bandwidth attribute.
Ed,
thanks -- could you please go the extra mile and post an issue on the
tracker?
M
___
Discuss-g
Should be :)
Just as side info:
http://www.boost.org/doc/libs/1_54_0/doc/html/boost/random/mt19937.html
Sorry, totally running low on clues here...
This is twice as strange since boost::random is missing mt19937; if it was
std:: I'd guess on a non-C++11 standard library, but like it is...
If cle
On 02/21/2014 12:38 AM, Activecat wrote:
> Problem:
> Says, the instantaneous interpolation_factor is 3.
> As inherited from gr::block, the scheduler may call the general_work()
> with noutput_items=2 (any number is possible).
> When this happen, there is nothing to be done except to consume_each(0
Thanks Marcus,
Actually the boost version I have is 1.54.0.
Is this ok ?
--
View this message in context:
http://gnuradio.4.n7.nabble.com/Issue-while-installing-GR-3-7-tp46435p46451.html
Sent from the GnuRadio mailing list archive at Nabble.com.
__
Hi Alexander,
interesting approach!
Just a few quick questions to understand better:
> Now with hardware:
> VLC - Named Pipe 1 - File Source GRC - OFDM MOD - USRP Sink- USRP -Source -
OFDM DEMOD - File Sink GRC - Named Pipe 2 - Mplayer
> (FAILS!!). Reports: Segfault (core dumped). GRC file is
Hello all
Sorry if this is a duplicate, haven't found a thread with me specific
config (no UDP).
System:
ubuntu 12.10
N2100
SBX
GNU Radio 3.7.2.1
UHD 003.006.002-1
I have been trying to set up a video link (loop back cable) using named
pipes but am stuck with a crash.
It works until I introduce
On Fri, Feb 21, 2014 at 2:39 AM, West, Nathan
wrote:
> On Thu, Feb 20, 2014 at 11:25 PM, Kelly Boswell wrote:
>> After the make test failed for this module, I decided to poke around to see
>> if there is an easy fix. I made a script that simply executes the test over
>> and over until it seg faul
Hi Ed - Thanks for the kind words! All of the warnings you show are normal for
OSX 10.8 or 10.9 and GNU Radio release in MacPorts. If you move to
gnuradio-devel, you'll be able to get rid of the "failed to XInitThreads()"
warning; if you move to 10.9, you'll get even more warnings if/when you
On Feb 20, 2014, at 10:58 PM, Bruce wrote:
> Where did you find that particular install?
Hi Bruce - Ed is talking about using MacPorts to install GNU Radio; see also
the various wiki pages related to these topics:
< http://gnuradio.org/redmine/projects/gnuradio/wiki/InstallingGR >
< https://tr
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Syed,
test 2 should be completely transparent and thus you shouldn't lose
quality. The input bitrate of the video is below 1Mb/s, so for a pure
loopback test I can't imagine this going wrong. Are you sure that the
sending VLC does *not* decode the
28 matches
Mail list logo
