Re: [Discuss-gnuradio] Python Unit Tests Running Twice
Kevin, Your comments got me thinking about my destructors. After poking around a bit I realized that one of the constructors (the actual radio interface) was never firing. Turns out that I was not calling delete() on the pointer to the radio manager instance. Once I fixed that everything just works. Still runs twice which is just odd to me, but it does work as expected! Thank you for guiding me in the right direction :D -Dave On Thu, Jun 16, 2016 at 11:51 PM, Kevin Reid wrote: > On Thu, Jun 16, 2016 at 8:48 PM, Dave NotTelling > wrote: > >> The radio is released properly when the destructor is called, but >> it's not getting called for some reason. I have several C++ tests that >> work like a champ, but the Python test doesn't actually release the >> resources that were allocated. I even tried assigning my block that talks >> to the radio to a variable in self (self.radio) and then setting it to None >> in the tearDown method. The resources still are not released. If I stop a >> GNU Radio flow graph that uses my block then everything is released just >> fine. Even when the Python test finishes (after the second run) the >> resources are released. It's just that the resources are not released >> between the back to back runs of the same test. >> > > Well, if your test involves a flow graph then make sure you're (stopping > and) discarding any references to the flow graph as well, since that will > hold onto the block. > > Can you share your Python code? > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Python Unit Tests Running Twice
On Thu, Jun 16, 2016 at 8:48 PM, Dave NotTelling wrote: > The radio is released properly when the destructor is called, but > it's not getting called for some reason. I have several C++ tests that > work like a champ, but the Python test doesn't actually release the > resources that were allocated. I even tried assigning my block that talks > to the radio to a variable in self (self.radio) and then setting it to None > in the tearDown method. The resources still are not released. If I stop a > GNU Radio flow graph that uses my block then everything is released just > fine. Even when the Python test finishes (after the second run) the > resources are released. It's just that the resources are not released > between the back to back runs of the same test. > Well, if your test involves a flow graph then make sure you're (stopping and) discarding any references to the flow graph as well, since that will hold onto the block. Can you share your Python code? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Python Unit Tests Running Twice
Kevin, The radio is released properly when the destructor is called, but it's not getting called for some reason. I have several C++ tests that work like a champ, but the Python test doesn't actually release the resources that were allocated. I even tried assigning my block that talks to the radio to a variable in self (self.radio) and then setting it to None in the tearDown method. The resources still are not released. If I stop a GNU Radio flow graph that uses my block then everything is released just fine. Even when the Python test finishes (after the second run) the resources are released. It's just that the resources are not released between the back to back runs of the same test. I completely agree that releasing the resources should be tested as well. This just seems like an odd bug to me. My Python isn't all that great so it's completely possible that I'm not doing something right =\ -Dave On Thu, Jun 16, 2016 at 11:24 PM, Kevin Reid wrote: > On Thu, Jun 16, 2016 at 5:21 PM, Dave NotTelling > wrote: > >> I have a solution in place right now that works around the second >> test, but it's nasty. Global variables and whatnot. >> > > You wrote originally that the reason the tests can't be run twice is “the > radio hardware is never released.” This sounds like a problem that can be > solved by making sure your test (by way of the code it tests, presumably) > releases the hardware properly. Then your tests are also testing > "releasing"! > > I recommend this course of action because I have had trouble resulting > from other people's drivers failing to close/release/reset the hardware > properly, or to be unable to be opened twice. > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Python Unit Tests Running Twice
On Thu, Jun 16, 2016 at 5:21 PM, Dave NotTelling wrote: > I have a solution in place right now that works around the second > test, but it's nasty. Global variables and whatnot. > You wrote originally that the reason the tests can't be run twice is “the radio hardware is never released.” This sounds like a problem that can be solved by making sure your test (by way of the code it tests, presumably) releases the hardware properly. Then your tests are also testing "releasing"! I recommend this course of action because I have had trouble resulting from other people's drivers failing to close/release/reset the hardware properly, or to be unable to be opened twice. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Python Unit Tests Running Twice
Martin, You're absolutely right about having hardware involved in the unit tests. They are strictly for my internal testing. Testing the code live in GNU Radio is turning out to be a serious headache =\ I have a solution in place right now that works around the second test, but it's nasty. Global variables and whatnot. I didn't think about the fact that some people need the XML output. Thank you for the explanation! -Dave On Thu, Jun 16, 2016 at 7:38 PM, Martin Braun wrote: > I don't think this is an accident; when we run the tests on our CIs, we > want both the regular output and the XML output. You're right that this > behaviour can be annoying, however, I found if this is giving me > trouble, it's usually because my test is stateful. Maybe you can come up > with a way to actually run this test twice in a row. > > Having unit tests that require hardware is unusual, in any case. Now of > course you can write whatever tests you like, but this kind of unit test > will make it difficult for others to replicate (and to integrate into a > CI system, which I find a useful benchmark for the utility of unit tests). > > That said, we should probably come up with a way to disable the > xmlrunner (maybe make it a pref), since most people won't care about it. > > M > > On 06/15/2016 03:44 PM, Dave NotTelling wrote: > > I noticed that my Python unit tests were running twice. Using PyCharm's > > debugger I was able to figure out that the culprit is the following > > snippet from gr_unittest.py: > > > > # use the xmlrunner if we can write the the directory > > if(xmlrunner is not None): > > xmlrunner.run(suite) > > > > main() > > > > > > xmlrunner.run(suite) runs my tests, when that finishes (failure or not) > > main() gets called which runs the tests again. This plays hell with my > > tests that talk to radio hardware as the radio hardware is never > > released. Should there be an 'else' clause that calls main()? > > > > Thanks! > > > > -Dave > > > > > > ___ > > Discuss-gnuradio mailing list > > Discuss-gnuradio@gnu.org > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Python Unit Tests Running Twice
I don't think this is an accident; when we run the tests on our CIs, we want both the regular output and the XML output. You're right that this behaviour can be annoying, however, I found if this is giving me trouble, it's usually because my test is stateful. Maybe you can come up with a way to actually run this test twice in a row. Having unit tests that require hardware is unusual, in any case. Now of course you can write whatever tests you like, but this kind of unit test will make it difficult for others to replicate (and to integrate into a CI system, which I find a useful benchmark for the utility of unit tests). That said, we should probably come up with a way to disable the xmlrunner (maybe make it a pref), since most people won't care about it. M On 06/15/2016 03:44 PM, Dave NotTelling wrote: > I noticed that my Python unit tests were running twice. Using PyCharm's > debugger I was able to figure out that the culprit is the following > snippet from gr_unittest.py: > > # use the xmlrunner if we can write the the directory > if(xmlrunner is not None): > xmlrunner.run(suite) > > main() > > > xmlrunner.run(suite) runs my tests, when that finishes (failure or not) > main() gets called which runs the tests again. This plays hell with my > tests that talk to radio hardware as the radio hardware is never > released. Should there be an 'else' clause that calls main()? > > Thanks! > > -Dave > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
