Encounter mistakes when use table in communication
Opened this issue · 4 comments
When use functions
neighbors.broadcast("key", sendTable)
and neighbors.listen("key", function(vid, recvTable, rid) { })
to communicate, if sendTable and recvTable are defined as tables, and several recvTables are stored in another map, such as messageStorage, fail to fetch the right value of recvTable in messageStorage.
Sample source codes are provided in attached file, with testbzzDesired.bzz and testbzzDesired.argos showing the desired result, and testbzz.bzz and testbzz.argos showing the actual result.
bzzIssue.zip
Can you please be more specific? The code you sent me forces me to guess a little too much. What do you mean by:
fail to fetch the right value of recvTable in messageStorage
What do you expect to see, and what do you see instead?
In the code that you provide in testbuzz.bzz, the following lines overwrite the same message over and over:
neighbors.listen("message",
function(vid,value,rid){
#store the received message
m_messageRecv.ID=value.ID
#add the received message
m_messageStorage[m_messageCunt]=m_messageRecv
m_messageCunt=m_messageCunt+1
})
at the end, what you should see is that every element of m_messageStorage is the same.
Sorry for fail to describe the issue clearly.
I intend to save messages received from different neighbours as elements of m_messageStorage, so once the neighbors.listen() function is called, the received value should be saved as an element in m_messageStorage, which means the elements in m_messageStorage should be different. But it seems they are overwrite somewhere as you mentioned, and all the elements become the same.
When I exchange the m_messageRecv to value in the following line:
m_messageStorage[m_messageCunt]=m_messageRecv (1)
every thing works as I expected.
It seems that the problem is about the table m_messageRecv, which is used to save the received message for temporary and should be equal to value. So the outcome should be the same no matter I use m_messageRecv or value in (1). But the fact is when I use m_messageRecv, every element in m_messageStorage is overwritten, and I don't know why.
This is not a bug, it's just the way tables work in Buzz. Tables are
handled by reference, not by value. The behavior you see is correct.
If you want to deep copy a table, you have to do it like in the second code
example you show.
On Nov 22, 2016 02:08, "dbtx123" notifications@github.com wrote:
Sorry for fail to describe the issue clearly.
I intend to save messages received from different neighbours as elements
of m_messageStorage, so once the neighbors.listen() function is
called, the received value should be saved as an element in
m_messageStorage,which means the elements in m_messageStorage should
be different. But it seems they are overwrite somewhere as you mentioned,
and all the elements become the same.
When I exchange the m_messageRecv to value in the following line:
m_messageStorage[m_messageCunt]=m_messageRecv (1)
every thing works as I expected.
It seems that the problem is about the table m_messageRecv, which is
used to save the received message for temporary and should be equal to
value. So the outcome should be the same no matter I use m_messageRecv
or value in (1). But the fact is when I use m_messageRecv, every
element in m_messageStorage is overwritten, and I don't know why.—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#13 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/ACmZYzWsjFIFq0CePH0FDlTj6imz5FXhks5rApTegaJpZM4K44f9
.
I see. Thank you very much for answering my question!