lua-icxx-users — Any question related to using Luaxx in your code

Re: [Lua-icxx-users] lua_icxx + swig

[Domenico M. <dm...@gm...>]

After looking carefully at the source code, I found that you make use
of pushValToStack.


This can be used for a custom stack allocation to handle the swig call.

Here is what I've done :

I restored the original lua_icxx source code and added to LuaObjRef.h  the
following code


struct LUA_ICXX_CPP_API
UserStackAllocation
{
     virtual void pushToStack(lua_State* L) const = 0;
};

void pushValToStack(lua_State* L, const UserStackAllocation& objRef)
{
    objRef.pushToStack(L);
}




In my code I derive from UserStackAllocation to handle the swig calls

class Swig : public UserStackAllocation
{
     Swig(Foo* f);

     void pushToStack(lua_State* L) const {
                    SWIG_Lua_NewPointerObj( L, .... );
          }
}



Now I can simply use the standard way of calling a function


    void execCallback()
     {
       cb( Swig( new Foo ) );
     }


This solution is cleaner
Let me know if you are interested in adding it to the project

Thanks

Dom

On Sun, Feb 5, 2012 at 7:12 PM, Domenico Mangieri <dm...@gm...> wrote:

> I doesn't work as it is so I modified slightly lua_icxx code to
> accommodate this requirement.
>
> This is just a quick solution..
>
> with the changed code I can do this
>
>
>     void execCallback()
>      {
>        LuaFuncCallParams call= cb.prepCall()   // this is now public
>
>        SWIG_Lua_NewPointerObj( L, new Foo() .... )  // push wrapped object
> on the stack
>
>        call.doCall(1);   // doCall gets extra number of params pushed on
> the stack
>      }
>
>
>         This works.
>
>         Maybe it can be implemented differently but I'm sure this could be
> a popular feature for lua_icxx as I think the combo swig + lua_icxx is a
> winner!
>
>
>    Dom
>
>
>
> On Sun, Feb 5, 2012 at 5:26 PM, Domenico Mangieri <dm...@gm...>wrote:
>
>> Hi ..  more on this..
>>
>> I found that I can use  SWIG_Lua_NewPointerObj  provided by swig
>> generate file  to create the wrapping object
>>
>>
>>     void execCallback()
>>      {
>>        SWIG_Lua_NewPointerObj( L, new Foo() .... )
>>
>>        cb();
>>      }
>>
>> SWIG_Lua_NewPointerObj pushes the object into lua stack.
>>
>> Now the question is, can I call cb with no args given the pointer is
>> already in the stack  ?
>>
>> I'll give it a try..
>>
>> Dom
>>
>>
>>
>>
>> On Sun, Feb 5, 2012 at 3:34 PM, Domenico Mangieri <dm...@gm...>wrote:
>>
>>> Hi,
>>>
>>> I'm playing around with lua_icxx. I find it very useful with its unique
>>> approach to lua calls within c++.
>>>
>>> I'm currently using swig to wrap a large library and I'm using lua_icxx
>>> to provide callback supports from within c++ into lua.
>>>
>>> Here is an example
>>>
>>> *c++ *
>>>
>>> // Note : Foo is wrapped by swig
>>>
>>> class Foo
>>> {
>>>   public:
>>>
>>>     LuaFuncRef cb;
>>>
>>>     void registerCallback(const char* cb)
>>>     {
>>>         cb = _lua.eval(cb);
>>>     }
>>>     .....
>>>
>>>     void execCallback()
>>>     {
>>>        cb();
>>>     }
>>> };
>>>
>>>
>>>
>>>
>>>
>>> *lua :*
>>>
>>>
>>> function test()
>>>     print("cool")
>>> end
>>>
>>> f = Foo()
>>> f:registerCallback("test");
>>>
>>>
>>>
>>>
>>> That's all good.
>>>
>>> My problem now is to make use of swig wrap to pass c++ objects to lua
>>> callback;
>>>
>>> Something like this
>>>
>>>     void execCallback()
>>>     {
>>>        cb( new Foo );
>>>     }
>>>
>>> The callback works fine with basic types but not for UDT.
>>>
>>> Any idead how that could be solved ?
>>>
>>>
>>> Thank you for sharing this lib.
>>>
>>> Dom
>>>
>>>
>>
>

Re: [Lua-icxx-users] lua_icxx + swig

[Domenico M. <dm...@gm...>]

I doesn't work as it is so I modified slightly lua_icxx code to accommodate
this requirement.

This is just a quick solution..

with the changed code I can do this


    void execCallback()
     {
       LuaFuncCallParams call= cb.prepCall()   // this is now public

       SWIG_Lua_NewPointerObj( L, new Foo() .... )  // push wrapped object
on the stack

       call.doCall(1);   // doCall gets extra number of params pushed on
the stack
     }


        This works.

        Maybe it can be implemented differently but I'm sure this could be
a popular feature for lua_icxx as I think the combo swig + lua_icxx is a
winner!


   Dom


On Sun, Feb 5, 2012 at 5:26 PM, Domenico Mangieri <dm...@gm...> wrote:

> Hi ..  more on this..
>
> I found that I can use  SWIG_Lua_NewPointerObj  provided by swig generate
> file  to create the wrapping object
>
>
>     void execCallback()
>      {
>        SWIG_Lua_NewPointerObj( L, new Foo() .... )
>
>        cb();
>      }
>
> SWIG_Lua_NewPointerObj pushes the object into lua stack.
>
> Now the question is, can I call cb with no args given the pointer is
> already in the stack  ?
>
> I'll give it a try..
>
> Dom
>
>
>
>
> On Sun, Feb 5, 2012 at 3:34 PM, Domenico Mangieri <dm...@gm...>wrote:
>
>> Hi,
>>
>> I'm playing around with lua_icxx. I find it very useful with its unique
>> approach to lua calls within c++.
>>
>> I'm currently using swig to wrap a large library and I'm using lua_icxx
>> to provide callback supports from within c++ into lua.
>>
>> Here is an example
>>
>> *c++ *
>>
>> // Note : Foo is wrapped by swig
>>
>> class Foo
>> {
>>   public:
>>
>>     LuaFuncRef cb;
>>
>>     void registerCallback(const char* cb)
>>     {
>>         cb = _lua.eval(cb);
>>     }
>>     .....
>>
>>     void execCallback()
>>     {
>>        cb();
>>     }
>> };
>>
>>
>>
>>
>>
>> *lua :*
>>
>>
>> function test()
>>     print("cool")
>> end
>>
>> f = Foo()
>> f:registerCallback("test");
>>
>>
>>
>>
>> That's all good.
>>
>> My problem now is to make use of swig wrap to pass c++ objects to lua
>> callback;
>>
>> Something like this
>>
>>     void execCallback()
>>     {
>>        cb( new Foo );
>>     }
>>
>> The callback works fine with basic types but not for UDT.
>>
>> Any idead how that could be solved ?
>>
>>
>> Thank you for sharing this lib.
>>
>> Dom
>>
>>
>

Re: [Lua-icxx-users] lua_icxx + swig

[Domenico M. <dm...@gm...>]

Hi ..  more on this..

I found that I can use  SWIG_Lua_NewPointerObj  provided by swig generate
file  to create the wrapping object


    void execCallback()
    {
       SWIG_Lua_NewPointerObj( L, new Foo() .... )

       cb();
    }

SWIG_Lua_NewPointerObj pushes the object into lua stack.

Now the question is, can I call cb with no args given the pointer is
already in the stack  ?

I'll give it a try..

Dom



On Sun, Feb 5, 2012 at 3:34 PM, Domenico Mangieri <dm...@gm...> wrote:

> Hi,
>
> I'm playing around with lua_icxx. I find it very useful with its unique
> approach to lua calls within c++.
>
> I'm currently using swig to wrap a large library and I'm using lua_icxx to
> provide callback supports from within c++ into lua.
>
> Here is an example
>
> *c++ *
>
> // Note : Foo is wrapped by swig
>
> class Foo
> {
>   public:
>
>     LuaFuncRef cb;
>
>     void registerCallback(const char* cb)
>     {
>         cb = _lua.eval(cb);
>     }
>     .....
>
>     void execCallback()
>     {
>        cb();
>     }
> };
>
>
>
>
>
> *lua :*
>
>
> function test()
>     print("cool")
> end
>
> f = Foo()
> f:registerCallback("test");
>
>
>
>
> That's all good.
>
> My problem now is to make use of swig wrap to pass c++ objects to lua
> callback;
>
> Something like this
>
>     void execCallback()
>     {
>        cb( new Foo );
>     }
>
> The callback works fine with basic types but not for UDT.
>
> Any idead how that could be solved ?
>
>
> Thank you for sharing this lib.
>
> Dom
>
>

[Lua-icxx-users] lua_icxx + swig

[Domenico M. <dm...@gm...>]

Hi,

I'm playing around with lua_icxx. I find it very useful with its unique
approach to lua calls within c++.

I'm currently using swig to wrap a large library and I'm using lua_icxx to
provide callback supports from within c++ into lua.

Here is an example

*c++ *

// Note : Foo is wrapped by swig

class Foo
{
  public:

    LuaFuncRef cb;

    void registerCallback(const char* cb)
    {
        cb = _lua.eval(cb);
    }
    .....

    void execCallback()
    {
       cb();
    }
};





*lua :*


function test()
    print("cool")
end

f = Foo()
f:registerCallback("test");




That's all good.

My problem now is to make use of swig wrap to pass c++ objects to lua
callback;

Something like this

    void execCallback()
    {
       cb( new Foo );
    }

The callback works fine with basic types but not for UDT.

Any idead how that could be solved ?


Thank you for sharing this lib.

Dom

[Lua-icxx-users] Difficulty reading a std::string from a LuaTempResult

[Jon <pen...@gm...>]

Hello.

I'm experimenting with lua_icxx to see how helpful it might be. I'm having
trouble with this code:

LuaTempResult ltr = _interpreter_ptr->eval( "return 'test'" );
std::string ret = ltr[ 1 ];

Based on the examples provided it seems it should work. However, I get the
compiler error:

>c:\users\jon\documents\visual studio
2010\projects\dron\dron\script\script.cpp(29): error C2440: 'initializing'
: cannot convert from 'LuaTempResult::Item' to
'std::basic_string<_Elem,_Traits,_Ax>'
1>          with
1>          [
1>              _Elem=char,
1>              _Traits=std::char_traits<char>,
1>              _Ax=std::allocator<char>
1>          ]
1>          No constructor could take the source type, or constructor
overload resolution was ambiguous

When I change the code somewhat, I get an error better describing the
ambiguity:

1>c:\users\jon\documents\visual studio
2010\projects\dron\dron\script\script.cpp(27): error C2593: 'operator =' is
ambiguous
1>          c:\program files (x86)\microsoft visual studio
10.0\vc\include\xstring(772): could be
'std::basic_string<_Elem,_Traits,_Ax>
&std::basic_string<_Elem,_Traits,_Ax>::operator =(_Elem)'
1>          with
1>          [
1>              _Elem=char,
1>              _Traits=std::char_traits<char>,
1>              _Ax=std::allocator<char>
1>          ]
1>          c:\program files (x86)\microsoft visual studio
10.0\vc\include\xstring(767): or
'std::basic_string<_Elem,_Traits,_Ax>
&std::basic_string<_Elem,_Traits,_Ax>::operator =(const _Elem *)'
1>          with
1>          [
1>              _Elem=char,
1>              _Traits=std::char_traits<char>,
1>              _Ax=std::allocator<char>
1>          ]
1>          c:\program files (x86)\microsoft visual studio
10.0\vc\include\xstring(762): or
'std::basic_string<_Elem,_Traits,_Ax>
&std::basic_string<_Elem,_Traits,_Ax>::operator =(const
std::basic_string<_Elem,_Traits,_Ax> &)'
1>          with
1>          [
1>              _Elem=char,
1>              _Traits=std::char_traits<char>,
1>              _Ax=std::allocator<char>
1>          ]
1>          c:\program files (x86)\microsoft visual studio
10.0\vc\include\xstring(707): or
'std::basic_string<_Elem,_Traits,_Ax>
&std::basic_string<_Elem,_Traits,_Ax>::operator
=(std::basic_string<_Elem,_Traits,_Ax> &&)'
1>          with
1>          [
1>              _Elem=char,
1>              _Traits=std::char_traits<char>,
1>              _Ax=std::allocator<char>
1>          ]
1>          while trying to match the argument list '(std::string,
LuaTempResult::Item)'

Am I doing something wrong? How can I get this to work?

Thanks

Jon.

Re: [Lua-icxx-users] [ANN] lua-icxx v1.01

[oliver <oli...@gm...>]

Hi Patrick, I started working on this last fall (2010), and only recently
decided to publicize it. Thanks for pointing out your project, always good
to see alternative ways of doing things.

when you need to use Lua from C++ without exposing
> C function in Lua (one-way), it should be enough to be able to
> evaluate arbitrary Lua expressions, passing around arguments and
> return values.


For me the above wasn't enough. I needed ways to keep references to compiled
chunks of Lua code so that calling them often didn't require recompiling
strings of code over and over. Also needed to sandbox the scripting
environment, and easily load DLL's.  As explained in the docs for lua-icxx,
I could not find any other lib that did that.

I also really like how LuaTempResult gives access to any number of return
values on the stack, with automatic type inference (for basic types).
Potentially some conversion functions could also be defined for UDT, but
that's slipping into domain of supporting UDT natively in Lua-icxx, I rather
combine lua-icxx with SWIG (or other) for that (which is what I actually
do).

Here is how some of your example code from LuaClassBasedCall would look like
with Lua-icxx (have not had time to run this, so may need some tweaking):

LuaInterpreter L;
L.doString("print('Hello world')");

LuaTableRef myTable = L.eval("mytable={true, 0, 3.1416, 0, 'world'}; return
mytable");
// only dict support right now:
myTable[2] = 2; // replaces the first zero in mytable
myTable[4] = "Hello"; // no wide char support right now

LuaTempResult res = L.eval("for k,v in pairs(mytable) do print(k,v,type(v))
end");
if ( ! res.isOK() )
    cout << "Lua error : %s\n" << res.errMsg();

// get table items
bool   res1 = myTable[1];
double res2 = myTable[2];
float  res3 = myTable[3];
string res4 = myTable[4]; // no wchar support yet
string res5 = myTable[5];
printf("mytable = { %d, %g, %g, %S, %s }\n", res1, res2, res3, res4, res5);

LuaFuncRef sumFn = L.chunkFromString("local a,b,c=...; return a+b+c");
double sum = sumFn(2.3, 4, 3.1416);     // figures out all types
string pi  = sumFn("3.1", "4", "16");   // no recompilation
printf("The sum is %g\n", sum);

// Outputs example:
LuaTempResult vals = L.eval("s='P\\0Q\\0R'; u=io.stdin; return
s,u,{1,2,3}");
string aString   = vals[0];
LuaObjRef stdin  = vals[1]; // opaque pointers only; combine with SWIG for
more
LuaTableRef a123 = vals[2];

// Custom types: combine with SWIG or tolua++ or other
LuaTempResult modLoaded = L.openDynLib( "your_lib", "luaopen_your_lib" );
if ( ! modLoaded.ok() )
    throw runtime_error("FATAL error: could not load Lua extension
"your-lib"");
LuaClassObjRef yourObj = L.eval("yourObj"); // assume your_lib created a
global
yourObj.callMethod("sayHello", "world"); // from Lua:
yourObj:sayHello("world")

The above shows how different the two libraries are. And the above does not
show off several important capabilities of Lua-icxx like sandboxing. Sure,
Lua-icxx doesn't currently support wchar, or STL containers, but these just
haven't been requirements; if other users really like to use Lua-icxx and
there is strong demand for such things then there is no reason they couldn't
be added.

Oliver