Closed sdalgard closed 9 years ago
Strange... I am pretty sure I got it to work... but remember I had that issue... I will look into it in more details.
Well, I generated the Kevoree wrapper for the ping pong example (Exercise 2 in tutorial 1) and it works. I just removed the connector from the ThingML configuration so that I expose the ports to Kevoree. The results is exactly the same. Maybe you can send me:
But I agree the checks on port name, etc might be redundant, as I already suspected (see that comment in the generator)
I can remove that test (or comment it in the generated code)
The check on port name is not a question of redundancy. As long as the generated ThingML code not know what it will be connected to (through kevoree), the code generator cannot do any assumption about it.
I tried to replace an internal ThingML connection
connector starter.from_ender => ender.to_starter
connector ender.from_starter => starter.to_ender
With a kevoree connection
bind node0.JavaPIF.JavaPIF_starter_from_enderPort chan1
bind node0.JavaPIF.JavaPIF_ender_to_starterPort_out chan1
bind node0.JavaPIF.JavaPIF_starter_to_enderPort_out chan2
bind node0.JavaPIF.JavaPIF_ender_from_starterPort chan2
My current code is checked in at https://github.com/sdalgard/training I can guide you through it if you want :-)
I see start node0 is still commented in your kevscript. Did you try to uncomment it? We comment by default since the generated script is imcomplete (missing channels)
I have not tried, I shall keep it in mind
Dont see that it does make any difference for this issue.
Note that I removed the test on port name (it should have fixed the issue?). If you want to test, I guess it should make a difference if the node is started or not.
I have now tested the new generator and it works :+1: It works without start node0...
The serialization (JSON) generated by ThingML includes name of the sender port. final String msg = "{\"message\":\"pif_token\",\"port\":\"to_ender_c\", \"token\":" + PrintIncForwardMsgs_pif_token_token__var + "}";
The receiving port will parse/deserialize the message and compare it with the name of the receiving port. if (json.get("port").asString().equals("from_starter_c")) { if (json.get("message").asString().equals("pif_token")) {
The name of the sender port and the receiver port will "in real life" not be the same. The result is that the received message is rejected.
Suggested fix: Skip test of port name at receiving side. Or also skip port name in the serialization. This should be ok as long as the cannels are point-to-point it should this should be safe.