LTR compatible wrappers with SWIG for eLua
Locked
|
Hello, I have introduced two new language modules in SWIG> elua and eluac. They can be used for automatic LTR compatible wrapper code generation for eLua which could be used for testing and prototyping of new eLua modules. For now, I have put the entire source tree on sourceforge. It's an unofficial SWIG-2.0.4 release with support for eLua. (http://sourceforge.net/projects/eluaswig/files/) Working with elua and eluac is the same as working with the SWIG Lua module. No additional information is required. I have written a small wiki post on how -elua is different from -eluac. (http://sourceforge.net/p/eluaswig/wiki/Home/). Please follow the instructions on the 'README' file to install eluaswig from source. My system configuration: Linux raman 2.6.39-ARCH #1 SMP PREEMPT GNU/Linux I use a Stellaris ARM Cortex-M3 luminary LM3S8962 as my standard board. All my wrapper code tests have worked fine. This version does not support compatibility with both optram = 0 and optram = 1 (It is not very hard to get this done though). If we don't use LTR, we can always use -lua with SWIG for eLua. Once you get eluaswig installed, invoke SWIG with -elua/c switch from your favourite terminal and supply the SWIG interface file (extension '.i'). The rotable we are interested in is 'swig_commands[]'. By default, -elua or -eluac will put all the macro symbolic named constants (Eg: #define PI 3.14) and enum values in a rotable called 'swig_constants[]' A sample wrapper file: const LUA_REG_TYPE swig_commands[] = { {LSTRKEY("new_int_array"), LFUNCVAL(_wrap_new_int_array)}, {LSTRKEY("delete_int_array"), LFUNCVAL(_wrap_delete_int_array)}, {LSTRKEY("int_array_getitem"), LFUNCVAL(_wrap_int_array_getitem)}, .... }; const LUA_REG_TYPE mt[] = { {LSTRKEY("__index"), LFUNCVAL(SWIG_Lua_module_get)}, {LSTRKEY("__newindex"), LFUNCVAL(SWIG_Lua_module_set)}, {LSTRKEY(".get"), LROVAL(dot_get)}, {LSTRKEY(".set"), LROVAL(dot_set)}, {LNILKEY, LNILVAL} }; const LUA_REG_TYPE swig_constants[] = { {LSTRKEY("PI"), LNUMVAL(3.14)}, {LSTRKEY("STRING"), LSTRVAL("Free as in freedom, GNU-GPL V3")}, {LSTRKEY("C"), LNUMVAL(C)}, {LSTRKEY("CPP"), LNUMVAL(CPP)}, ... }; Note that mt[] is only generated with the -elua switch. -eluac puts everything in one rotable, swig_commands. The wrapper introduces a new macro LSTRVAL, (just like LNUMVAL or LFUNCVAL) to handle macros like #define STR "Free as in freedom". To access such constants from eLua, we can write: print(mod.const.PI) -- Will print 3.14. ('mod' is the module name) Please read the eLua/c section in the TODO file in the source directory for known issues. I can write a detailed documentation for hacking around the language modules if people are interested. Please try to get the source installed and test it out. Please give me suggestions on how to take this forward. Awaiting your response, Raman |
|
|
Very neat. I haven't used SWIG a great deal, but have experimented
with it for providing wrappers/interfaces for C libraries in Python. Is your primary intent to make it easier to generate interfaces for arbitrary C libraries you might want to link in, or so that we could generate interfaces for existing code in a programmatic way instead of hand-creating the wrapper code, or something else? I haven't thought about using SWIG with embedded targets, but I can see the value in perhaps making it easier to create modules that work with Lua as well as eLua without maintaining as much preprocessor to switch between LTR and non-LTR implementations. I think I may give this a try for LuaRPC which exists both as a stand-alone module and as an eLua module and in order to support both I have to duplicate the binding code. Best. -jsnyder On Sat, Jul 30, 2011 at 9:28 AM, raman <[hidden email]> wrote: > > Hello, > > I have introduced two new language modules in SWIG> elua and eluac. They can > be used for automatic LTR compatible wrapper code generation for eLua which > could > be used for testing and prototyping of new eLua modules. For now, I have put > the > entire source tree on sourceforge. It's an unofficial SWIG-2.0.4 release > with support > for eLua. (http://sourceforge.net/projects/eluaswig/files/) > > Working with elua and eluac is the same as working with the SWIG Lua module. > No additional information is required. I have written a small wiki post on > how -elua > is different from -eluac. (http://sourceforge.net/p/eluaswig/wiki/Home/). > > Please follow the instructions on the 'README' file to install eluaswig from > source. > My system configuration: Linux raman 2.6.39-ARCH #1 SMP PREEMPT GNU/Linux > I use a Stellaris ARM Cortex-M3 luminary LM3S8962 as my standard board. All > my > wrapper code tests have worked fine. > > This version does not support compatibility with both optram = 0 and optram > = 1 > (It is not very hard to get this done though). If we don't use LTR, we can > always use > -lua with SWIG for eLua. > > Once you get eluaswig installed, invoke SWIG with -elua/c switch from your > favourite > terminal and supply the SWIG interface file (extension '.i'). > > The rotable we are interested in is 'swig_commands[]'. By default, -elua or > -eluac will > put all the macro symbolic named constants (Eg: #define PI 3.14) and enum > values > in a rotable called 'swig_constants[]' > > A sample wrapper file: > const LUA_REG_TYPE swig_commands[] = { > {LSTRKEY("new_int_array"), LFUNCVAL(_wrap_new_int_array)}, > {LSTRKEY("delete_int_array"), LFUNCVAL(_wrap_delete_int_array)}, > {LSTRKEY("int_array_getitem"), LFUNCVAL(_wrap_int_array_getitem)}, > .... > }; > > const LUA_REG_TYPE mt[] = { > {LSTRKEY("__index"), LFUNCVAL(SWIG_Lua_module_get)}, > {LSTRKEY("__newindex"), LFUNCVAL(SWIG_Lua_module_set)}, > {LSTRKEY(".get"), LROVAL(dot_get)}, > {LSTRKEY(".set"), LROVAL(dot_set)}, > {LNILKEY, LNILVAL} > }; > > const LUA_REG_TYPE swig_constants[] = { > {LSTRKEY("PI"), LNUMVAL(3.14)}, > {LSTRKEY("STRING"), LSTRVAL("Free as in freedom, GNU-GPL V3")}, > {LSTRKEY("C"), LNUMVAL(C)}, > {LSTRKEY("CPP"), LNUMVAL(CPP)}, > ... > }; > > Note that mt[] is only generated with the -elua switch. -eluac puts > everything > in one rotable, swig_commands. > > The wrapper introduces a new macro LSTRVAL, (just like LNUMVAL or LFUNCVAL) > to > handle macros like #define STR "Free as in freedom". To access such > constants from > eLua, we can write: print(mod.const.PI) -- Will print 3.14. ('mod' is the > module name) > > Please read the eLua/c section in the TODO file in the source directory for > known > issues. > > I can write a detailed documentation for hacking around the language modules > if > people are interested. > > Please try to get the source installed and test it out. Please give me > suggestions on > how to take this forward. > > Awaiting your response, > > Raman > > > -- > View this message in context: http://elua-development.2368040.n2.nabble.com/LTR-compatible-wrappers-with-SWIG-for-eLua-tp6636280p6636280.html > Sent from the eLua Development mailing list archive at Nabble.com. > _______________________________________________ > eLua-dev mailing list > [hidden email] > https://lists.berlios.de/mailman/listinfo/elua-dev > eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Is your primary intent to make it easier to generate interfaces for arbitrary C libraries you might want to link in, or so that we could generate interfaces for existing code in a programmatic way instead of hand-creating the wrapper code, or something else? The latter. It's easier for us to generate wrappers for existing code without having to know the details of the C-Lua API. I haven't thought about using SWIG with embedded targets, but I can see the value in perhaps making it easier to create modules that work with Lua as well as eLua without maintaining as much preprocessor to switch between LTR and non-LTR implementations. Certainly. I think I may give this a try for LuaRPC which exists both as a stand-alone module and as an eLua module and in order to support both I have to duplicate the binding code. Ok. Great. Please keep me posted. Raman Best. -jsnyder On Sat, Jul 30, 2011 at 9:28 AM, raman <[hidden email]> wrote: > > Hello, > > I have introduced two new language modules in SWIG> elua and eluac. They can > be used for automatic LTR compatible wrapper code generation for eLua which > could > be used for testing and prototyping of new eLua modules. For now, I have put > the > entire source tree on sourceforge. It's an unofficial SWIG-2.0.4 release > with support > for eLua. (http://sourceforge.net/projects/eluaswig/files/) > > Working with elua and eluac is the same as working with the SWIG Lua module. > No additional information is required. I have written a small wiki post on > how -elua > is different from -eluac. (http://sourceforge.net/p/eluaswig/wiki/Home/). > > Please follow the instructions on the 'README' file to install eluaswig from > source. > My system configuration: Linux raman 2.6.39-ARCH #1 SMP PREEMPT GNU/Linux > I use a Stellaris ARM Cortex-M3 luminary LM3S8962 as my standard board. All > my > wrapper code tests have worked fine. > > This version does not support compatibility with both optram = 0 and optram > = 1 > (It is not very hard to get this done though). If we don't use LTR, we can > always use > -lua with SWIG for eLua. > > Once you get eluaswig installed, invoke SWIG with -elua/c switch from your > favourite > terminal and supply the SWIG interface file (extension '.i'). > > The rotable we are interested in is 'swig_commands[]'. By default, -elua or > -eluac will > put all the macro symbolic named constants (Eg: #define PI 3.14) and enum > values > in a rotable called 'swig_constants[]' > > A sample wrapper file: > const LUA_REG_TYPE swig_commands[] = { > {LSTRKEY("new_int_array"), LFUNCVAL(_wrap_new_int_array)}, > {LSTRKEY("delete_int_array"), LFUNCVAL(_wrap_delete_int_array)}, > {LSTRKEY("int_array_getitem"), LFUNCVAL(_wrap_int_array_getitem)}, > .... > }; > > const LUA_REG_TYPE mt[] = { > {LSTRKEY("__index"), LFUNCVAL(SWIG_Lua_module_get)}, > {LSTRKEY("__newindex"), LFUNCVAL(SWIG_Lua_module_set)}, > {LSTRKEY(".get"), LROVAL(dot_get)}, > {LSTRKEY(".set"), LROVAL(dot_set)}, > {LNILKEY, LNILVAL} > }; > > const LUA_REG_TYPE swig_constants[] = { > {LSTRKEY("PI"), LNUMVAL(3.14)}, > {LSTRKEY("STRING"), LSTRVAL("Free as in freedom, GNU-GPL V3")}, > {LSTRKEY("C"), LNUMVAL(C)}, > {LSTRKEY("CPP"), LNUMVAL(CPP)}, > ... > }; > > Note that mt[] is only generated with the -elua switch. -eluac puts > everything > in one rotable, swig_commands. > > The wrapper introduces a new macro LSTRVAL, (just like LNUMVAL or LFUNCVAL) > to > handle macros like #define STR "Free as in freedom". To access such > constants from > eLua, we can write: print(mod.const.PI) -- Will print 3.14. ('mod' is the > module name) > > Please read the eLua/c section in the TODO file in the source directory for > known > issues. > > I can write a detailed documentation for hacking around the language modules > if > people are interested. > > Please try to get the source installed and test it out. Please give me > suggestions on > how to take this forward. > > Awaiting your response, > > Raman > > > -- > View this message in context: http://elua-development.2368040.n2.nabble.com/LTR-compatible-wrappers-with-SWIG-for-eLua-tp6636280p6636280.html > Sent from the eLua Development mailing list archive at Nabble.com. > _______________________________________________ > eLua-dev mailing list > [hidden email] > https://lists.berlios.de/mailman/listinfo/elua-dev > _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
In reply to this post by raman
Hi,
On Sat, Jul 30, 2011 at 5:28 PM, raman <[hidden email]> wrote:
Thank you very much for your effort, I can see this being a big help for a lot of people. There is an unfortunate catch though: the LTR semantics aren't guaranteed to remain the same. In fact, if you check out our "ltrwork" branch you'll see a quite different way of definining the LTR tables (and I'm guessing a bit harder to get into SWIG) which will probably make it to the master branch in the future. I'm hoping this won't make you change your mind about maintaining your new language modules, this is simply awesome :)
Best, Bogdan
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Thank you very much for your effort, I can see this being a big help for a lot of people. There is an unfortunate catch though: the LTR semantics aren't guaranteed to remain the same. In fact, if you check out our "ltrwork" branch you'll see a quite different way of definining the LTR tables (and I'm guessing a bit harder to get into SWIG) which will probably make it to the master branch in the future. I'm hoping this won't make you change your mind about maintaining your new language modules, this is simply awesome :) Best, Bogdan Hello, Thanks for the reply. No problem. eluaswig can certainly evolve as eLua evolves. Raman > > Raman > > > -- > View this message in context: > http://elua-development.2368040.n2.nabble.com/LTR-compatible-wrappers-with-SWIG-for-eLua-tp6636280p6636280.html > Sent from the eLua Development mailing list archive at Nabble.com. > _______________________________________________ > eLua-dev mailing list > [hidden email] > https://lists.berlios.de/mailman/listinfo/elua-dev > _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Hello, I heard from the SWIG community. They are slightly uncomfortable with the inclusion of support for eLua as a separate language module. They however don't mind the integration of the eLua language module with regular SWIG Lua. This is certainly possible but it would result in a highly monolithic code structure with conditional compilation and eLua specific macros in regular SWIG Lua. This might still work but the time delta between each SWIG release is not fixed. One solution could be to support eLua wrapper generation independent of SWIG by creating a separate tool with constant support and maintenance. What is preferred ? How can we proceed ? Awaiting your response. Raman |
|
|
On Thu, Aug 4, 2011 at 8:31 AM, raman <[hidden email]> wrote:
I guess one question is, how monolithic is SWIG and its language modules? I presume they don't just work like plugins and that with the current implementation you'd end up having to maintain a patch against SWIG unless it gets integrated?
Is there any way with SWIG to make some of the interface generation optional? I.e.: to kindof make the Lua support "flavors" of Lua? Or, does it pretty much have to generate code that would be compatible with both from a given interface file? If SWIG doesn't have this as a feature, I wonder whether this might be useful for them? We are getting into an age where languages have multiple implementations (Python, Ruby, Lua among others..), sometimes these implementations will have differing native C APIs I think as well?
I'm not sure how much of your work might translate to other tools since I've not implemented a language with SWIG before or delved into its inner workings. There are some other Lua binding generators out there, like tolua (http://www.tecgraf.puc-rio.br/~celes/tolua/) which appears to be written in C and have similar functionality to what SWIG does. There's also LuaNativeObjects (https://github.com/Neopallium/LuaNativeObjects) which is written in Lua.
On the one hand it might be nice to be able to use something like SWIG which is a mature, well maintained project, but on the other hand.. if we're adding dependencies to our build system, it's also nice if we can implement it in pure Lua so that we don't actually have to add an external dependency. We also _do_ have a newer build system that Bogdan has worked on implemented in Lua that potentially something like this could be integrated into, since part of what we'd like to do there is auto-generate the platform_conf.h and move some of what we have in C preprocessor into Lua.
(P.S.: Sometimes Dave Beazley comes to the Python user group meetings where I am so if you need me to bug him about anything in person... :-) )
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Hello,
Certainly. This is very much possible. We can support the eLua flavor on regular SWIG Lua. I have also implemented it. I have merged the language modules 'elua' and 'eluac' with SWIG Lua. This flavor of Lua can be accessed from command line with the switches '-lua -elua0.8' & '-lua -eluac0.8'. (Issue swig -lua -help). For now, SWIG will support elua0.8. Since the LTR semantics may change in the future, a provision for compatibility with previous versions of eLua is thought of and is possible.The existing version can be modified to support the newer versions of eLua in the future. Please find the source tree on sourceforge: http://sourceforge.net/projects/eluaswig/files/eluaswig1.0.tar.gz/download
Yes, I have worked with tolua but like you said SWIG is matured and a well maintained project. Based on working experience, I was able to conclude that SWIG does a far superior job than tolua, 5.1.4
Yes, when it comes to dependencies, it will take a hit. :(
Awaiting your response. Raman
|
«
Return to eLua Development
|
1 view|%1 views
| Free forum by Nabble | Edit this page |