PDA

View Full Version : JSON lua module



mhund
August 3rd, 2016, 10:29 AM
Hi Ron,

just using this JSON lua module which is integrated in G6 and 'm experiencing some issues with the decode function, if the json keys are stringed numbers.

The following lua code

aaa = json.decode('{"1": {"a": "a","b": "b","c": "c"}, "2": {"a": "a", "b": "b","c": "c"}, "3": {"a": "a", "b": "b", "c": "c"}}')

is decoded in to faulty table aaa like ...

aaa = {{},{},{}} with endless depth

can you reproduce this and maybe fix it? I tried to reverse engineer the json.lua but didn't understand the method used to decode.

Thanks in advance,

Martin

mhund
August 3rd, 2016, 10:47 AM
If i take the json like

{"A": {"a": "a","b": "b","c": "c"}, "B": {"a": "a", "b": "b","c": "c"}, "C": {"a": "a", "b": "b", "c": "c"}}

it works fine. It seems to me that the decode function has a problem with number keys as strings.

mhund
August 3rd, 2016, 11:16 AM
Third comment: Just saw at https://github.com/craigmj/json4lua/releases that the developer has published a 1.0 but this it still suffering from the same problem. It does not like number keys as string. If I skip the "" it works too.

{1: {"a": "a","b": "b","c": "c"}, 2: {"a": "a", "b": "b","c": "c"}, 3: {"a": "a", "b": "b", "c": "c"}}

But I cannot do that in my case because the json is produced by a philips hue bridge :-(

mhund
August 3rd, 2016, 04:37 PM
Hi,

update from my side:

The author of the json lua lib has provided a newer version (which is much more lean and efficient) but still provides this bug concerning the number keys.

@Ron: I would urgently recommend to switch to the newer version 1.0.0 from 2015 anyway.

https://github.com/craigmj/json4lua/releases

you can simply take the file json.lua, rename it to init.lua, copy it to the lua/json directory in girder. The only change needed is to switch the json table from local to global in line 39.

to cope with the number key bug, I wrote a simple wrapper function which changes the "1" keys to a real number keys without "". It works with the 1.0.0 from 2015. But it does not work with the 0.9.50 which is currently included in girder6.

I contacted the author from the lib concerning the bug and will let you know if he responds.

Ron
August 8th, 2016, 01:39 PM
Thanks for the work you did here. I will switch to the newer version. Let me know what he says about the number bug.

mhund
August 10th, 2016, 03:37 AM
Hi Ron,

update: Together with the developer of the json4lua module, I found out a real weird thing: The issue seems not to be with the json implementation, but with the lua5.1 implementation used in girder. I reduced it to the core. You can type the following lines in the lua console of girder:

s={["1"]="a"} works well (key is a number as string, value is a string)

s={["1"]={"a"}} works not at all (key is number as string, value is a table containing what ever)

Can you confirm this?

Thanks for your support and regards,

Martin

Ron
August 10th, 2016, 02:02 PM
Strange both work for me:


table.print({["1"]={"a"}})



Wed Aug 10 11:01:00 2016 { -- #0
Wed Aug 10 11:01:00 2016 ["1"] = { -- #1
Wed Aug 10 11:01:00 2016 [1] = "a",
Wed Aug 10 11:01:00 2016 } -- #1,
Wed Aug 10 11:01:00 2016 } -- #0


table.print({["1"]="a"})



Wed Aug 10 11:01:19 2016 { -- #0
Wed Aug 10 11:01:19 2016 ["1"] = "a",
Wed Aug 10 11:01:19 2016 } -- #0

mhund
August 10th, 2016, 08:46 PM
strange - what I did:

1. write s={["1"]={"a"}} to the lua console
2. check variable inspector for s

and you should see the behaviour.

Ron
August 10th, 2016, 10:15 PM
The variable inspector goes into an infinite loop, that's odd. But I believe that bug is limited to the inspector. If you do

table.print(s)

you get the expected result:



Wed Aug 10 19:14:14 2016 { -- #0
Wed Aug 10 19:14:14 2016 ["1"] = { -- #1
Wed Aug 10 19:14:14 2016 [1] = "a",
Wed Aug 10 19:14:14 2016 } -- #1,
Wed Aug 10 19:14:14 2016 } -- #0

mhund
August 11th, 2016, 04:13 AM
Maybe. This would mean that also my json based scripts never had issues but only my debugging by inspector lead me into a wrong direction :-)
Sorry for the confusion. At least you have a reason to keep an eye on the inspector ;-)