Re: [Discuss-gnuradio] Python Unit Test with message ports - "Could not find port"

[Steven Knudsen]

Hey, thank you, too, for the help.

Kind of solved my problem, but not happy about it...

I thought this is all just python-related since it was python stuff that generated the error. The C++ code in the old and new versions is identical since when I created stuff from scratch, I just copied and pasted most of the old C++ source into the new files. However, I did write the python unit test guts from scratch to fill out the gr_modtool-generated qa_xxx.py file. I did an experiment where I swapped out the new files for the original, problematical files. It was not until I got to the qa_xxx.py that things stopped working. 

Looked at the python in the “bad” qa_xxx.py file and noticed that, from earlier dev tests, I had left in “from foo import periodic_msg_source” and a few other non-necessary imports (non-necessary once things worked right and I was done experimenting). Commented out the foo import and things worked! Hmmmm. So, went to my new qa_xxx.y and added the “from foo import periodic_msg_source” statement and… it continued to work!?! What the heck??? Iterated a couple more times with the bad qa_xxx.py file and it’s repeatable; the from foo statement causes the “Could not port” error. Comment it out, the error goes away…

Finally, I have to conclude it’s an import order problem. I’m not much of a Python expert, but it seems wrong to me that order (in this case) matters. I’ve attached the file that “breaks”, but the problem is seen in the imports;

This order results in the “Could not find port" 

import pmt

from foo import periodic_msg_source

import time

from gnuradio import gr, gr_unittest

from gnuradio import blocks

import jitc_swig as jitc

#from foo import periodic_msg_source

This order works

import pmt

#from foo import periodic_msg_source

import time

from gnuradio import gr, gr_unittest

from gnuradio import blocks

import jitc_swig as jitc

from foo import periodic_msg_source

I suspect that foo has some kind of dependency, but I can’t take the time now to go look as I am behind in writing unit tests for my customer. I don’t want to impugn the author of gr-foo in all this, of course, but note the source is getting old now...

Very, very weird, and totally reproducible.

qa_random_sequenced_pdu.py
Description: Text Data

Steven Knudsen, Ph.D., P.Eng.

www. techconficio.ca

www.linkedin.com/in/knudstevenknudsen

Der entscheidende Augenblick der menschlichen Entwicklung ist immerwährend. Darum sind die revolutionären geistigen Bewegungen, welche alles Frühere für nichtig erklären, im Recht, denn es ist noch nichts geschehen. - Franz Kafka

On Jan 13, 2017, at 06:58, Marcus Müller <address@hidden> wrote:

Hi Steven,

thanks for the compliments, and yeah, I can fully understand it's somewhat frustrating to not find the root cause of something, and I surely would have enjoyed to reproduce the issue, but if you need to move on, I can completely comprehend.

Thanks, and keep up the good work,

Marcus

On 01/13/2017 01:53 AM, Steven Knudsen wrote:

Hi all,

Getting stuck means you have to try something else…

Marcus and i thought it can’t hurt to try and create from scratch a new message-only block and test it. 

Long story short (and good news), that worked just fine. I even changed the new OOT message block to have ports with the same names as the offending block below — worked in GRC and in a unit test.

The next obvious thing was to recreate my desired message-only block, tossing the old one into the bit bucket. Everything just worked.

So, what could have been the problem? Not sure, especially since the original block worked flawlessly in GRC and never worked in the python unit test. 

I hate “solutions” like this, but I suppose that if anyone ever sees something like this again, we can hope they see these posts and cut straight to making a clean block using gr_modtool.

Time to move on!

Thanks for your help, Marcus.

steven

On Jan 12, 2017, at 09:11, Steven Knudsen <address@hidden> wrote:

Thanks very much, Marcus, for the help.

As requested, I used

        self.tb.msg_connect((self.blocks_message_strobe_0, pmt.string_to_symbol('strobe')), (self.jitc_random_sequenced_pdu_0, pmt.string_to_symbol('generate')))

Sadly, no change in that the “Could not find port” problem persists.

To be sure, I also applied your suggestion with the gr-blocks random_pdu block in the same source (much as I did below) and used

        self.tb.msg_connect((self.blocks_message_strobe_0, pmt.string_to_symbol('strobe')), (self.jitc_random_pdu_0, pmt.string_to_symbol('generate')))

which worked just fine.

I’ll continue to compare the gr-blocks implementation with my OOT module. I would still like to think there is a difference somewhere in the source or a script or something, but I can’t see how that would explain why my OOT works fine in GRC.

Last, I did try to follow the logic/code that tracks the registered ports starting with gnuradio-runtime/lib/flowgraph.cc, but I became a bit lost as things moved through swig…

BTW, my GR version is 3.7.10.1

Again, thanks for your help!

steven

On Jan 12, 2017, at 03:39, Marcus Müller <address@hidden> wrote:

Hi Steven,

On 12.01.2017 02:21, Steven Knudsen wrote:

You worry me with your “various ways” comment :-/

That's what I do: I comment and worry people. And I just finished my comment.
No, really, I was just surprised that a) it doesn't work and b) it claims "a is not in set {a,b}". That feels ever so slightly wrong.

All I have done is extended the random_pdu from gr-blocks by including a sequence number in the PDU. So, the constructor is where the message ports are registered and is identical to the random_pdu constructor. I’ve attached a snippet (rsp_constructor.snippet) that contains my exact code.

Thanks, OK the most relevant line here is

      message_port_register_in(pmt::mp("generate"));

which looks right; I really sense shenanigans here. So, to narrow this down:

Can you do a

        self.tb.msg_connect((self.blocks_message_strobe_0, pmt.string_to_symbol('strobe')), (self.jitc_random_sequenced_pdu_0, pmt.string_to_symbol('generate')))

to rule out any strangenesses that the whole behind-the-scenery PMT conversion does?

Best regards,
Marcus

My version works the same as the original when run from GRC. I’ve attached a screencap of the simple flowgraph used to verify this. I’ve also attached the generated python. 

I took the main code from that generated python and added to my unit test and modified only by changing ‘self’ to self.tb’. When I run that code, I get the could not find port error. 

If I modify that code to connect only the output of the Message Strobe to the print port of the Message Debug, it works.

That is, this does not work,

        self.tb.msg_connect((self.blocks_message_strobe_0, 'strobe'), (self.jitc_random_sequenced_pdu_0, 'generate'))

#        self.tb.msg_connect((self.blocks_message_strobe_0, 'strobe'), (self.blocks_message_debug_0, 'print'))

        self.tb.msg_connect((self.jitc_random_sequenced_pdu_0, 'pdus'), (self.blocks_message_debug_0, 'print'))

But this does work

#        self.tb.msg_connect((self.blocks_message_strobe_0, 'strobe'), (self.jitc_random_sequenced_pdu_0, 'generate'))

        self.tb.msg_connect((self.blocks_message_strobe_0, 'strobe'), (self.blocks_message_debug_0, 'print'))

#        self.tb.msg_connect((self.jitc_random_sequenced_pdu_0, 'pdus'), (self.blocks_message_debug_0, 'print'))

Last observation is that if I replace my random_sequenced_pdu with block’s random_pdu,it all works. So, it’s definitely something with my module. Is something not generated via/by swig maybe? I tried digging into gr-blocks to look for differences, but so far none that I can see.

Sorry this is kind of long, but it’s a weird problem, weird because my stuff works fine in GRC!?!

regards, and thanks,

steven

---

From:	Marcus Müller
Subject:	Re: [Discuss-gnuradio] Python Unit Test with message ports - "Could not find port"
Date:	Wed, 11 Jan 2017 14:49:40 +0100
User-agent:	Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0

---

Hi Steven, 

that's strange indeed. In various ways. 

Could you tell us:

1. where do you register the message port? Could you copy&paste that exact line?
2. could you copy&paste both message_connect lines from the GRC-generated and your unit test python?

Thanks,

Marcus

On 01/11/2017 01:35 AM, Steven Knudsen wrote:

Hi all,

I am trying to write a unit test for a message-only block, let’s call it “foo”, that has an input message port “generate". When I use the block in GRC, everything is fine. I can connect its message ports to standard GNU Radio message blocks, like message_strobe and message_debug with no problems.

However, when I try and do the same in a Python unit test, I get the message

Could not find port: generate in:

generate

system

If, for example, in the same unit test I connect the message_strobe with message_debug, all is well.

If I then connect message_strobe to foo, I get the error above.

I double checked that the message port declarations are the same as you find in a block like message_strobe. 

I double checked the syntax of msg_connect, making sure it looks exactly the same as it does in the GRC generated Python file.

Anyone seen this recently? I have found some references by searching online, but nothing that has helped.

Thanks very much!

steven