Printing from c++ code

GNU Radio
1

I am unable to print from C++ code in gnuradio. I have tried various
combinations of included libraries and different types of print
statements
in my C++ code. However, nothing that I have tried yet (see some
attempts
below) has let me see any output from the command terminal (where my
printed
python output appears). I found an old response from Eric B. for a
similar
problem, but the offered solution did not work for me either.

// #include // DAK
#include
// #include <stdio.h> // DAK
// #include // DAK
#include
…
fprintf(stdout, “\nTEST”);
fprintf(stderr, “\nTEST”);
printf (“\nThis is a test”);
fprintf(stderr, “Samples Processed: %d\n”, d_processed),
fflush(stderr);

During the make/make install process (executed from the /src and
/src/lib
directories after my experimental changes; not sure where I’m supposed
to do
this). I see errors if my C++ syntax is not correct, so presumably my
changes are actually being compiled and I also see the corresponding
object
file times changing appropriately. There could well be a problem with
the
importing of modules in python or C++ and/or my directory structure or
paths… sort of why I need the print statements to work in the first
place.

I don’t claim to understand the hierarchy of python/swig/c++ calls or
the
autotools processes yet. My basic task is to figure out the execution
progress and sequencing of some routines written by others (which are a
bit
more complicated than the one in D. Shen’s tutorial). I want to
understand
the control flow for some ucla 802.15.4 extension code to gnuradio,
specifically in the receive direction.

In general, how should/could standard I/O work out of a C++ program
through
SWIG into python? Could someone tell me what is supposed to work
(i.e.
maybe the pertinent #include and (f)printf statements. Alternatively,
maybe
someone could give alternatives to my primitive approach for
understanding
python/C++ program control flow and calling structure? I have tried
using
the python interpreter and manually listing modules and module paths
after
each encountered import statement; pretty tedious.

Presumably, there could be issues if C++ print statements get executed
at
the same rate as RF data is processed… but right now being swamped by
print statement output from the signal processing code would be a
welcome
problem!

Thanks, David

–
View this message in context:
http://www.nabble.com/Printing-from-c%2B%2B-code-tp25891709p25891709.html
Sent from the GnuRadio mailing list archive at Nabble.com.

2

My first guess is that you have gnuradio modules installed on more than
one place in your system; older modules compiled without the printfs are
being used, and the newer ones have second priority in the search path.
Try a sudo make uninstall, and run your program, you should get errors.

My second guess would be that your work function is not getting called,
or there is some conditional logic before the printfs. Try putting some
printfs in the constructor of the block, just to prove to yourself that
it prints on instantiation.

-Josh

3

My first guess is that you have gnuradio modules installed on more than
one place in your system; older modules compiled without the printfs are
being used, and the newer ones have second priority in the search path.
Try a sudo make uninstall, and run your program, you should get errors.

That was indeed the case. I guess, during my various botched attempts
at
gnuradio installation, I had created multiple directories of gnuradio
modules and then lost track of which one was actually ‘working’. Changes
to
the C code, followed by a ‘sudo make install’ in the same directory, now
have the desired effect, so thanks very much.

Actually, sudo make uninstall didn’t quite do it for me. I had to
remove a
fair number of gnuradio-related modules by hand… I found that Synaptic
uninstallation, then installation (followed by ‘re-installation’ of
certain
modules) worked quite well as a process.

For the record, I tripped over the following minor issues during my
re-installation of gnuradio and the UCLA code:
. there seem to be some dependencies between gnuradio-omnithread and
gnuradio-utils (re-installing gnuradio-omnithread in Synaptic removed
the
offending gnuradio-utils incompatibilty by removing gnuradio-utils).
. the UCLA installation procedure defaults to a ‘/usr/local’ root
directory, which doesn’t fit with gnuradio. I changed the UCLA
configure
file setting of ac_default_prefix to equal ‘/usr’. After re-running the
new
configure file, this worked for me. Note that bootstrap clobbers the
configure file (and any changes that you’ve made to it ;-/) so you don’t
need/want to re-run this.

View this message in context:
http://www.nabble.com/Printing-from-c%2B%2B-code-tp25891709p25951913.html
Sent from the GnuRadio mailing list archive at Nabble.com.