AI Zone Admin Forum Add your forum
Share variable bug
 
 

I have two bots, bot1 and bot2
in a .top file a have the following rules:

u: (share input) share input
  $share_name = ^“Dies ist ein Teststring”
  $share_name
u: (share output) share_output
  $share_name

If I execute

share input

with bot1, than change the bot with

:bot bot2

and then try

share output

the variable is empty.

Did I get something wrong?
Or is this a bug?

 

 
  [ # 1 ]

Any feedback? At least anyone who can confirm this problem?

 

 
  [ # 2 ]

It works if you have at least one topic declared share. Do you?

 

 
  [ # 3 ]
Bruce Wilcox - Jun 12, 2016:

It works if you have at least one topic declared share. Do you?

Hey Bruce, now the sharing functionality is top priority in my project again.
I tested again with the newest version, still no luck.

Here is excactly what I am testing this time:

topic: ~test []
u
: (share1$share_test testSUCCESS
            executed
u
: (share2)
            
test $share_test 

I execute share1 with my first bot and get

executed

I execute share2 with my second bot and get only

test

.

If I set one topic share (or this topic) it starts getting strange.
I execute share1 with my first bot and get

executed

I execute share2 with my second bot and get nothing back (execution is probably aborted).

From there on Chatscript is in a state where it has plenty of bugs. It aborts statement during my normal execution that worked before. From what I see without a deeper analysis is that my variables get deleted randomly. Could be a memory corruption or something like that.

The only way to get Chatscript to a working state again is to delete the file with the test topic. restart the chatscript binary and build again, followed by a :reset.
If I skip any of these steps chatscript stays buggy.

 

 

 

 
  [ # 4 ]
Bruce Wilcox - Jun 12, 2016:

It works if you have at least one topic declared share. Do you?


Hey Bruce, I am here with a quick update.

I tried to further inspect the weird behavior. I tried to make a small example which reproduces the issue, but I wasn’t able to.
So I can only reproduce the issue with my rather complex code base.

All I have to do to produce the issue is add a topic, no matter if used or executed, with the shared flag.
Without any other changes or specific commands the behavior gets triggered.
I inspected the behavior a little further:
I added a log of a json object as last command and first command of a chatscript call. The problem is that the json object is cleared (means its suddenly an empty json object {}) from one chatscript call to the other although being marked permanent.

The other part of the issue, that $share_ variables don't work is however easy to reproduce without my codebase just extending harry.
Even without a second bot this doesn't work for me:

topic: ~test share ()
    
u: (create
        
$share_test 
        created

    u
: (print) 
        
printing$share_test 

tobi: > create
HARRY:  Created
tobi: > print
HARRY:  Printing:
tobi: >

I would expect HARRY to respond with

Printing: 1

instead


Thanks in advance,
Tobi

 

 
  [ # 5 ]

So I tried this after creating michael as a clone of harry in the same script.
:
topic: ~INTRODUCTIONS keep repeat (~emogoodbye ~emohello ~emohowzit name here )
t: Which countries have you visited?

topic: ~test share keep repeat[ alien retrieve]
t: gambit 1 $_tmp = ^createfact( youtt love everything)
t: gambit 2 $_tmp = ^createfact( youtt hate you)
t: gambit 3 $_tmp = ^createfact( youtt hate me)
t: gambit 4 $_tmp = ^createfact( youtt hate yourself)
u: (retrieve) @0 = ^query(direct_s youtt ? ?)
loop()
{
_0 = ^first(@0all)
_0 _1 _2 \n
}

Initially starting out in Harry, I type alien and got gambit 1. I typed retrieve and it showed 1 fact (which was stored in the share topic file. I did :bot michael and it switched bots. I typed retrieve and it showed the fact. I typed junk and then fool, which did gambit 2 and 3. Retrieve showed 3 facts. I did :bot harry. and then i did retrieve, he showed the same 3 facts.
Try that experiment first.

 

 
  [ # 6 ]

On the other hand, there is a bug in sharing variables, so they did not work (per your example) and I have fixed that for next release.

 

 
  [ # 7 ]
Bruce Wilcox - Aug 21, 2017:

So I tried this after creating michael as a clone of harry in the same script.
:
topic: ~INTRODUCTIONS keep repeat (~emogoodbye ~emohello ~emohowzit name here )
t: Which countries have you visited?

topic: ~test share keep repeat[ alien retrieve]
t: gambit 1 $_tmp = ^createfact( youtt love everything)
t: gambit 2 $_tmp = ^createfact( youtt hate you)
t: gambit 3 $_tmp = ^createfact( youtt hate me)
t: gambit 4 $_tmp = ^createfact( youtt hate yourself)
u: (retrieve) @0 = ^query(direct_s youtt ? ?)
loop()
{
_0 = ^first(@0all)
_0 _1 _2 \n
}

Initially starting out in Harry, I type alien and got gambit 1. I typed retrieve and it showed 1 fact (which was stored in the share topic file. I did :bot michael and it switched bots. I typed retrieve and it showed the fact. I typed junk and then fool, which did gambit 2 and 3. Retrieve showed 3 facts. I did :bot harry. and then i did retrieve, he showed the same 3 facts.
Try that experiment first.

Your example worked for me.
I guess I need to somehow make a minimalistic example to reprocuce the other problem I have with my codebase when declaring a topic share, right? Or do you have any idea what my problem could be?

 

 

 
  [ # 8 ]
Bruce Wilcox - Aug 21, 2017:

On the other hand, there is a bug in sharing variables, so they did not work (per your example) and I have fixed that for next release.

I noticed I have a weird bug entry every volley:

Finished 1: heapusedOnEntry: 15207028 heapUsedNow: 15228408 buffers:1 stackused: 84771656 stackusedNow:0 ~controltestn -
BUG in topic_tobi_share.txt
at 0:  unable to read user logfile USERS/topic_tobi_share.txt
: Invalid argument (22)
MinReleaseStackGap 83MB MinHeapAvailable 84MB
MaxBuffers used 32 of 80

I tried to debug and it seems to me that chatscript is trying to open the share.txt file with

fopen(path, (char*)"rb"); 

which fails. Maybe because the text file isn’t in binary format?

 

 
  [ # 9 ]

The bug message was caused by “\n\r” at the end of the path string.
Removing it before doing the fopen helped me get rid of the message, but I still have the problem that some json objects are deleted from the user file.

 

 
  [ # 10 ]

It may be that your total fact count exceeds the allowed per user (default 100, settable) so it only keeps n most recent facts

 

 
  [ # 11 ]

I increased the fact count. The problem only occurs if I set one topic shared.
So all my code without share is working correctly, I never get this error.
I add an empty topic with the shared attribute and the problem occurs.
If I remove the shared attribute and rebuild everything + restart chatscript, everything is working again.
It has something to do with the shared attribute.

May it be that the fact count doesn’t apply to shared facts? And that maybe all of my json facts get shared?

 

 
  [ # 12 ]

I verified that by increasing the default fact limit in the USERFACTS define.
Thank you so much, this was the hint I needed smile

So two more questions:

1. Why are all my json facts automatically shared if I add a shared topic which isn’t even used? Can I determine which json should be shared and which not?

2. Can I increase the fact limit for the shared facts from chatscript code? $cs_userfactlimit doesn’t seem to have an effect for them.

Thank you so much!

 

 
  [ # 13 ]

“The bug message was caused by “\n\r” at the end of the path string.”—are you saying the engine has a code bug—where?
1. SHARING means you need multiple bots to coordinate. No topic can manage sharing of facts, a topic knows nothing about facts. Ergo ALL facts must be shared.
2. $cs_userfactlimit is retrieved and applied every time when saving user data. HOWEVER, if you have defined an initial value in your bot definition, then although you change the value in script, it will change it back at end of volley. Do you have some knowledge in code that it should suddenly be higher for a period?

 

 

 
  [ # 14 ]
Bruce Wilcox - Aug 22, 2017:

“The bug message was caused by “\n\r” at the end of the path string.”—are you saying the engine has a code bug—where?

I saw it while debugging, that the name parameter of FILE* FopenReadWritten(const char* name) in os.cpp is sometimes “USERS/topic_user_share.txt” and sometimes “USERS/topic_user_share.txt\r\n”. I havent investigated this any further, since I don’t know the chatscript code very well yet and it didn’t solve my problem.

Bruce Wilcox - Aug 22, 2017:

1. SHARING means you need multiple bots to coordinate. No topic can manage sharing of facts, a topic knows nothing about facts. Ergo ALL facts must be shared.

The topic shouldn’t decide, I agree. Maybe it would be helpful if there would be an optional argument in ^createfeact or so to say if it should be saved in the bot userfile or in the shared userfile. At least it would be helpful for me :D

Bruce Wilcox - Aug 22, 2017:

2. $cs_userfactlimit is retrieved and applied every time when saving user data. HOWEVER, if you have defined an initial value in your bot definition, then although you change the value in script, it will change it back at end of volley. Do you have some knowledge in code that it should suddenly be higher for a period?

I think there is a misunderstanding here. I didn’t want to change the $cs_userfactlimit during a volley or so, I am just looking for a possibilty to set the number of facts saved in the topic_user_shared.txt, because the variable isn’t applied there. It only sets the number of facts saved in topic_user_bot.txt

 

 
  [ # 15 ]

Bruce, what do you think about the idea of an optional parameter for ^createfact and ^jsoncreate etc. that determines in which user topic file the fact(s) should be saved?

 

 
  login or register to react