lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


Yeah, you are right. I should push only  an address of OpenCV object
pointer, whole structure is not necessary.

Thanks for criticism, I'll rewrite it as soon as I can and put on
sourceforge svn.

I think that it will be something like that:

template<typename cvtype>
void luacv_pushObject(lua_State *L,cvtype *data,const char
*type_name,bool copy=false)
{
 if (!data) lua_pushnil(L);
 else
{
  cvtype **object=(cvtype**)lua_newuserdata(L,sizeof(cvtype*));
  if (copy)
  {
    cvtype*c=(cvtype*)luacv_alloc(sizeof(cvtype));
    *c=*data;
    object=&c;
  }
  else
    object=&data;

    luaL_getmetatable(L,type_name);
    lua_setmetatable(L,-2);
}
}


regards,
Jiří Prymus

2011/3/9 Gaspard Bucher <gaspard@teti.ch>:
> Reference counting in OpenCV is for Matrix.
> If you push a userdata on the stack, only the pointer is allocated by Lua
> anyway...
> This is what I use to push new objects:
> /** Push a custom type on the stack.
>  * Since the value is passed as a pointer, we assume it has been created
>  * using 'new' and Lua can safely call delete when it needs to garbage-
>  * -collect it.
>  */
> template<class T>
> void lua_pushclass(lua_State *L, T *ptr, const char *type_name) {
>   T **userdata = (T**)lua_newuserdata(L, sizeof(T*));
>   *userdata = ptr;
>   // the userdata is now on top of the stack
>   // set metatable (contains methods)
>   luaL_getmetatable(L, type_name);
>   lua_setmetatable(L, -2);
> }
> Usage:
>     Mat * retval__ = new Mat();
>     lua_pushclass<Mat>(L, retval__, "cv.Mat");
> Destructor:
> /** __gc */
> static int Mat_destructor(lua_State *L) {
>   Mat **userdata = (Mat**)luaL_checkudata(L, 1, "cv.Mat");
>   if (*userdata) delete *userdata;
>   *userdata = NULL;
>   return 0;
> }
>
> On Wed, Mar 9, 2011 at 6:10 PM, Jiří Prymus <jiri.prymus@gmail.com> wrote:
>>
>> Hi Gaspard,
>>
>> I'm using this structure as a wrapper for pointer that I pushing onto
>> the lua stack, so Lua allocate only sizeof this structure.
>>
>> template <typename cvtype>
>> struct luacv_obj
>> {
>>  cvtype *data;
>>  bool dealloc_data;
>>  int ref;
>> };
>>
>> cvtype* data - is a pointer to OpenCV object
>>
>> bool dealloc_data  - check if garbage collector callback  __gc can
>> dealloc data or they are shared by another object (to avoid segfault).
>>
>> int ref - reference on LUA_REGISTRY stack position, I'm using this in
>> cvRelease* functions when I want to break references(luaL_unref()) to
>> this object and kill it, thus call __gc method.
>>
>> As far as I know the reference counting in OpenCV is only for
>> matrices, or  isn't?
>>
>> regards,
>> Jiří Prymus
>>
>>
>> 2011/3/9 Gaspard Bucher <gaspard@teti.ch>:
>> > Hi Jiří,
>> > I have scrolled through the code and I do not understand the need for
>> > your
>> > boxed object model (struct luacv_obj). OpenCV has reference counting for
>> > the
>> > data already. Why do you need this extra layer ?
>> > Gaspard
>> >
>> > On Wed, Mar 9, 2011 at 10:28 AM, Jiří Prymus <jiri.prymus@gmail.com>
>> > wrote:
>> >>
>> >> Thanks Gaspard,
>> >>
>> >> your feedback gave me a lot of new powers:). I'm glad  that you are
>> >> planning use LuaCV in your Lubyk project, but please consider that
>> >> LuaCV is in early alpha stage. It has functionality, but it  wasn't
>> >> tested as far as I want. It has up to 16000 lines of code so be sure
>> >> I've made some mistakes.
>> >>
>> >> And about integrating LuaCV to OpenCV source package. It would be
>> >> awesome, but even if I had a chance I don't do that until I'll be sure
>> >> that LuaCV is relatively bug free.
>> >>
>> >> Btw: I'll take a look on your Lubyk project, it looks promising.
>> >>
>> >> regards,
>> >> Jiří Prymus
>> >>
>> >> 2011/3/8 Gaspard Bucher <gaspard@teti.ch>:
>> >> > Jiří, I love you !
>> >> > I created a first OpenCV binding against a previous version but could
>> >> > not
>> >> > find the time to rework the bindings for 2.2.
>> >> > Your bindings look very good (much better then mine) and much more
>> >> > complete.
>> >> > I will therefore use your work in Lubyk. I'll keep you posted on the
>> >> > integration of OpenCV there: it might be an interesting environment
>> >> > for
>> >> > your
>> >> > projects too (easy access to GUI, live coding, live video, etc).
>> >> > If possible, please consider pushing your bindings to the OpenCV
>> >> > sources
>> >> > (I
>> >> > was given commit access just for this but never considered my work
>> >> > good
>> >> > enough for the move)...
>> >> > Your the man !
>> >> > Gaspard
>> >
>> >
>
>