main function has more than 200 local variables

[metacoma]

trafficstars

Hi, any help with this? Thanks ;-)

lua: /usr/local/share/lua/5.1/jsonschema/init.lua:188: [string "jsonschema:anonymous"]:3686: main function has more than 200 local variables
stack traceback:
        [C]: in function 'error'
        /usr/local/share/lua/5.1/jsonschema/init.lua:188: in function </usr/local/share/lua/5.1/jsonschema/init.lua:168>
        (tail call): ?
        .///compiled/abstract/minetest_mod/generator.lua:995: in main chunk
        [C]: in function 'require'
        ./check.lua:2: in main chunk
        [C]: ?

[membphis]

can you supply a mini case for this bug?

[metacoma]

can you supply a mini case for this bug?

Hello, thanks for reply ;-)

I have a complex system to generation lua objects based on reclass model for minetest game.

I defined several objects in yaml format, and then run reclass tool to compile them in one big "inventory".

In object definition, I added section "__schema" keyword to define how to validate parameters in lua object methods, like set/get

Then, I use jinja2 template to generate lua code.

And as .a result, I got file like this: https://github.com/metacoma/kapitan-abstract/blob/ljsonscheme-fail-max-200-values/compiled/abstract/minetest_mod/generator.lua (Yep, I know about JSON schem ref/id feature, but not using it)

Also, if you need to reproduce my error, you can easily do it with:

git clone http://github.com/metacoma/kapitan-abstract
cd kapitan-abstract
git checkout ljsonscheme-fail-max-200-values
lua ./check.lua 

Funny moment, before lua-jsonchema, I used lua-rapidjson library for validation and got segmentation fault in my case.

[metacoma]

by the way, construction with jsonschema ref/id works fine: https://github.com/metacoma/kapitan-abstract/blob/master/inventory/classes/type/network/hw/hp_procurve_2810.yml#L32

[Tieske]

fyi, here's how we solved the problem: https://github.com/Tieske/lua-resty-ljsonschema/pull/2

[metacoma]

fyi, here's how we solved the problem: Tieske#2

Thanks for the tip!

[jdesgats]

I suspected that issue could occur for very big schemas. @Tieske fix works, it not as efficient as local variables, but it probably don't have a significant overhead either, this needs measurements. I'll try to merge it asap.

[Jiajie-Ma-LF]

Hey @Tieske, if I still use the jsonSchema-4, whether I would face this error or not? Actually, I test the v4 of jsonSchema, it still has this issue, could you help to double-check does this problem is still alive in version 4, thanks very much.