YetAnotherForum
Welcome Guest Search | Active Topics | Log In | Register

[sqrat] weird binding behavior after upgrading to 0.9.1
inq
#1 Posted : Thursday, September 3, 2015 3:50:34 PM(UTC)
Rank: Newbie

Groups: Registered
Joined: 7/15/2012(UTC)
Posts: 6

Thanks: 0 times
Was thanked: 0 time(s) in 0 post(s)
Hi,

in my project I need to work a lot with JSON data so I'm trying to convert this directly to Sqrat objects which I'm binding for use directly inside the scripts. For the JSON part, I'm using jsoncpp. To illustrate the concept, think: JSON string -> Json::Value object -> Sqrat object.

This used to work great in sqrat 0.8.2, but after the upgrade to 0.9.1 I get some very strange behavior on the scripting side, namely accessing any slot within such a 'converted' table throws "the index 'XXX' does not exist'. Iterating through the table (using 'foreach') shows all the key/value pairs are in place, but trying to access them through delegation fails.

Original JSON String:
Code:
{"i":0,"ch":100,"md":1}


Squirrel snippet:
Code:

local scdef = trcache.getSubTC(0); //trcache is the instance of a bound class; prototype for the bound method in C++ is: Sqrat::Table getSubTC(uint idsubtc)
foreach(skey, sval in scdef)
{
  ::print("=> >scdef("+scdef.len()+")> '"+skey+"' <- '"+sval+"'");
  ::print("=> >wtf("+skey+")>: "+scdef[skey]);
}
try
{
  ::print("=> i is: "+scdef.i); //throws the exception
}
catch(err)
{
  ::print(err);
}


This outputs (ignore the extra info in the formatting):
Quote:

03-09-2015 18:03:58 :25: scr: {0}: => >scdef(3)> 'i' <- '0'
03-09-2015 18:03:58 :25: scr: {0}: => >wtf(i)>: 0
03-09-2015 18:03:58 :25: scr: {0}: => >scdef(3)> 'ch' <- '100'
03-09-2015 18:03:58 :25: scr: {0}: => >wtf(ch)>: 100
03-09-2015 18:03:58 :25: scr: {0}: => >scdef(3)> 'md' <- '1'
03-09-2015 18:03:58 :25: scr: {0}: => >wtf(md)>: 1
03-09-2015 18:03:58 :25: scr: {0}: the index 'i' does not exist


Iterating through the slots seems to work but accessing the slot by name throws an exception? Is something different in binding in sqrat 0.9.1 as opposed to 0.8.2?

For reference, I'm also including the method use to convert between Json::Value and Sqrat::Table:

Code:
bool J2Sq::j2sqtable(Json::Value *root, Sqrat::Table sqt)
{
    for(Json::ValueIterator jit = root->begin(); jit != root->end(); jit++)
    {
        const SQChar *pn = _SC(jit.memberName());
        switch((*jit).type())
        {
        case Json::nullValue:
            sqt.SetValue(pn, NULL);
            break;
        case Json::intValue:
            sqt.SetValue(pn, jw->getint(&(*jit)));
            break;
        case Json::uintValue:
            sqt.SetValue(pn, jw->getuint(&(*jit)));
            break;
        case Json::realValue:
            sqt.SetValue(pn, jw->getdouble(&(*jit)));
            break;
        case Json::stringValue:
            sqt.SetValue(pn, jw->getcstring(&(*jit)));
            break;
        case Json::booleanValue:
            sqt.SetValue(pn, jw->getbool(&(*jit)));
            break;
        case Json::arrayValue:
            {Sqrat::Array tsqa(sqt.GetVM());
            j2sqarray(&(*jit), tsqa);
            sqt.SetValue(pn, tsqa);
            break;}
        case Json::objectValue:
            {Sqrat::Table tsqt(sqt.GetVM());
            j2sqtable(&(*jit), tsqt);
            sqt.SetValue(pn, tsqt);
            break;}
        default:
            break;
        }
    }
    return true;
}


It's possible that some weird bug exists in the conversion code and that this was only brought out by the upgrade, but in any case this has gotten me stumped..

Any help is kindly appreciated!
bluehazzard
#2 Posted : Monday, September 7, 2015 10:20:04 PM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 1/1/2013(UTC)
Posts: 58
Location: italy

Thanks: 14 times
Was thanked: 3 time(s) in 3 post(s)
i have not read your post, but i suggest to post it also on the sqrat page on sourceforge (issue tracker), so you will probably get quicker a answer...
greetings
inq
#3 Posted : Saturday, September 12, 2015 2:42:02 PM(UTC)
Rank: Newbie

Groups: Registered
Joined: 7/15/2012(UTC)
Posts: 6

Thanks: 0 times
Was thanked: 0 time(s) in 0 post(s)
We've finally managed to solve the problem.

To anyone reading this post, the issue was with neither Sqrat, nor Squirrel - it was however unexpected that the upgrade brought out a very strange bug that lay dormant in our code for many months.

We run squirrel in a multithreaded environment where each thread has its own VM. Json to Sqrat converted objects are being cached - they are 'read-only' objects and are freely accessible by any thread at any time. The problem lies in the VM that the Sqrat objects were first created on, which is the one belonging to a random thread. I guess you can see where this is going: accessing the object from a script running on any other VM than the one that created the cache produces the described problem.

In hindsight the mistake seems obvious, however running with Sqrat 0.8.2 never produced any errors - and I still don't understand why iteration works at all (nevermind delegation).
wizzard
#4 Posted : Sunday, September 13, 2015 5:29:59 AM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 5/19/2013(UTC)
Posts: 133

Thanks: 4 times
Was thanked: 21 time(s) in 20 post(s)
I'd imagine that the following commit caused your issue
http://sourceforge.net/p...3659053c852e15f8ebe055a/
inq
#5 Posted : Wednesday, September 16, 2015 11:35:18 AM(UTC)
Rank: Newbie

Groups: Registered
Joined: 7/15/2012(UTC)
Posts: 6

Thanks: 0 times
Was thanked: 0 time(s) in 0 post(s)
Yes, that seems exactly the case!
At least everything's working properly now, and by properly I mean the way it was always intended to.
Users browsing this topic
Guest (2)
Forum Jump  
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.

Clean Slate theme by Jaben Cargman (Tiny Gecko)
Powered by YAF 1.9.4 | YAF © 2003-2010, Yet Another Forum.NET
This page was generated in 0.193 seconds.