Hello everyone,
Here’s a general call for help on the GNU Radio project if you are so
inclined. If you’ve wanted to contribute back to the code, but weren’t
sure
how to make a difference, there are lots of little things to look at.
We’ve
set up a Jenkins continuous integration server that keeps track of the
code
issues, including enumerating all “TODO” and “FIXME” comments through
the
source code. It also tests and graphs the test code we’ve put in there.
You
can see these results here:
http://www.gnuradio.org/jenkins/job/GNURadio-master/
What we want to see is the red and yellow graph lines going down and the
blue lines going up. The blue graph is the number of QA tests run. Any
more
QA tests for a) blocks that do not currently have any QA code or b) more
corner cases for blocks already being tested would be most welcome.
The red and yellow lines mostly represent compiler warnings and
TODO/FIXMEs.
Many of these might be very quickly resolvable with a few lines changed.
Some of them are probably more complex to know what the right answer is,
so
if you have some ideas, start a thread on the mailing list to discuss
what
the right fix might be.
Keep in mind on the warnings that libusrp and libusrp2 seem to be the
cause
of most of them. I wouldn’t worry about fixing these because those have
been
deprecated and will be removed from the code when we release the next
version.
So while many of these bugs/issues/warnings/todo’s have been around for
a
while and haven’t seemed to hurt anything, any time we remove one of
these,
we’ve made the code better, more robust and reliable, and less likely to
cause headaches in the future. Every little bit helps.
Thanks!
Tom
On 10/03/2011 11:32 AM, Tom R. wrote:
What we want to see is the red and yellow graph lines going down and the
blue lines going up. The blue graph is the number of QA tests run. Any more
QA tests for a) blocks that do not currently have any QA code or b) more
corner cases for blocks already being tested would be most welcome.
The red and yellow lines mostly represent compiler warnings and TODO/FIXMEs.
Many of these might be very quickly resolvable with a few lines changed.
Some of them are probably more complex to know what the right answer is, so
if you have some ideas, start a thread on the mailing list to discuss what
the right fix might be.
I am looking at the warnings in audio_alsa_sink.cc, but I do not see
them output on the console when I do compiles. Any ideas? I believe I
see why they occur and how to fix them, just trying to make sure the
warnings are really there. Is libtool screwing us over?
Philip
On Mon, Oct 3, 2011 at 1:27 PM, Philip B. [email protected]
wrote:
issues, including enumerating all “TODO” and “FIXME” comments through the
corner cases for blocks already being tested would be most welcome.
I am looking at the warnings in audio_alsa_sink.cc, but I do not see them
output on the console when I do compiles. Any ideas? I believe I see why
they occur and how to fix them, just trying to make sure the warnings are
really there. Is libtool screwing us over?
Philip
I’m only seeing a FIXME as a way of avoiding the generation of
a compiler warning. So I don’t think you would see this when compiling.
It
looks like the question is what’s the right way to set these and use
them?
It comes from this:
snd_pcm_access_mask_t *access_mask;
snd_pcm_access_mask_t **access_mask_ptr = &access_mask; // FIXME:
workaround for compiler warning
I think the question is, is this level of indirection the right thing to
do?
Let me know if you were talking about something else that I’ve missed.
Tom
On Mon, Oct 3, 2011 at 2:17 PM, Philip B. [email protected]
wrote:
sure
http://www.gnuradio.org/****jenkins/job/GNURadio-master/http://www.gnuradio.org/**jenkins/job/GNURadio-master/
The red and yellow lines mostly represent compiler warnings and
output on the console when I do compiles. Any ideas? I believe I see why
Tom
Arg, I get it. The warning only occurs on 32 bit machines since
sizeof(long) = sizeof(int)
Philip
Ah, I see. Yes, the machine that’s running Jenkins is 32-bit. This
should be
fixed in any case.
Tom
On 10/03/2011 02:00 PM, Tom R. wrote:
set up a Jenkins continuous integration server that keeps track of the
more
a compiler warning. So I don’t think you would see this when compiling. It
Tom
Arg, I get it. The warning only occurs on 32 bit machines since
sizeof(long) = sizeof(int)
Philip
On 10/03/2011 11:32 AM, Tom R. wrote:
Hello everyone,
Here’s a general call for help on the GNU Radio project if you are so
inclined. If you’ve wanted to contribute back to the code, but weren’t sure
how to make a difference, there are lots of little things to look at. We’ve
set up a Jenkins continuous integration server that keeps track of the code
issues, including enumerating all “TODO” and “FIXME” comments through the
source code. It also tests and graphs the test code we’ve put in there. You
can see these results here:
http://www.gnuradio.org/jenkins/job/GNURadio-master/
How often does this update?
Philip
On Fri, Oct 7, 2011 at 7:40 AM, Philip B. [email protected]
wrote:
issues, including enumerating all “TODO” and “FIXME” comments through the
Right now, it’s once a week. Early Monday morning for the master branch
and
early Tuesday morning for the next branch.
If this becomes a really useful tool that people are using constantly, I
could be easily persuaded to go to nightly builds. At that point,
though,
we’ll want to launch a new machine to handle the compilations and not
over-burden our web server.
Tom