lua-users home
lua-l archive

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

2012/4/23 Luiz Henrique de Figueiredo <>:
> Nice to see lmapm attract some interest.
>> this is a new implement of Luiz's lmapm module:
>> - renamed some functions:
> If you change the API, then it's not a reimplementation of lmapm:
> it's a new binding to MAPM, which is fine.
>> - use static work temporary variables to store intermediate result.
> This is a laudable goal, but the way you have implemented it, with
> static C variables, your library only works for a single Lua state or
> thread. In general, Lua libraries should not have static C data that
> depends on the Lua state.
> In your case, you could allocate temporary variables in the registry,
> but I'm not sure it's worth the trouble.
> For a C library whose objects have to be created by the library it's
> hard to avoid creating garbage. Some C libraries allow the user to init
> objects using local variables and this makes it easier to avoid *some*
> of the garbage when evaluating complex expressions. For instance, my
> bindings to qd and interval support this.
> However, the main source of garbage is intermediate results and this
> cannot be controlled automatically unless you do something like
>        begin_evaluate()
>                a=<complicated expression>
>        end_evaluate()
> and allow the binding to keep a stack of objects that is reused at
> the end; only the last object is keep.
> I think we have discussed this scheme in the past here (or was it in IRC?).
> Anyway, in a garbage collected language like Lua, you should not be (too)
> concerned about garbage, unless you create lots of it. Moreover, the
> generational mode in Lua 5.2 can probably mitigate this problem.

I have pushed a new version of lmapm on, if you compile it with:


then you will get per lua_State lm_State. that is stored on the
upvalue of every functions in module, every static variables except LL
are stored in that state.

Xavier Wang.