SWIG lua does not support overloaded methods

[karlnapf]

That is, when there are two c++ methods with the same name, lua modular interface only contains one of them.

[karlnapf]

Once resolved, lua can be re-added to meta-examples and cookbook. See https://github.com/shogun-toolbox/shogun/commit/bba5b32cc5e2acc05eede83e29b89d62690cba16

[besser82]

It's not our code… It's a simple limitation of LUA itself… See: http://www.swig.org/Doc3.0/Lua.html#Lua_nn17

So foo(int a) always gets shadowed by foo(int64t)…

[karlnapf]

This kills lua as an interface as most things cannot be used :( We can make it usable via renaming automatically, but it also is a mess to test this automatically with the meta examples. I still tend to do automatic renaming because it is better than removing the interface

[lisitsyn]

Future get/set stuff would be totally broken. My take on that is dropping Lua interface is a sane choice. It was a bit more relevant as there was Torch but there is PyTorch now.

[besser82]

@lisitsyn Will it be? I mean, Any my_data = get(char *); or set(char*, const any&) would still be no problem…

Print functions might be tricky, but for those we would just need to have mappings for the widest available type of any atomic type…

[lisitsyn]

Yeah you're right may be we can overcome it with something. But again not sure if it is worth.

[besser82]

Well, there is no real problem with Lua; the only thing is: Using the Lua-Interface will be slower then others, just because Lua-typemapping will always use the widest type of the underlying atomic type, e.g bool or int will be int64_t, float will use double.

Implementation-wise there is no real problem with Lua… It's just the fact, that Lua doesn't have a distiction between the width of the data-type used.

[besser82]

Anyways… If we really go down the road to a more modular approach, SWIG-interfaces need to be re-written from scratch - No way around it…

[karlnapf]

I suggest to disable and then work around at some point (i.e. to drop it :D)