Re: tolua survey

["mnicolet" <mnicolet@...>]

----- Original Message -----
From: "Luiz Henrique de Figueiredo" <lhf@tecgraf.puc-rio.br>
To: "Multiple recipients of list" <lua-l@tecgraf.puc-rio.br>
Sent: Monday, November 25, 2002 2:19 PM
Subject: tolua survey


> We're trying to decide the future of tolua and we'd like to hear your
opinion.
> If you use tolua (or something else) to automatically bind C or C++ code
to Lua,
> please fill in the brief survey below and send it directly to us at
> lua@tecgraf.puc-rio.br .
>
> Thanks for your time.
> --lhf and celes
>
> * Do you use tolua? If not, do you use any other wrapper?
     No. I created my own wrapper ( luapi ). But it´s not a true wrapper,
it´s a stub
     library to provide for repetitive ´standard lua/C code´.

> * Do you use tolua for C or C++?
     Both.
> * What features do you miss in tolua?
     I decided not to try tolua because ´two file maintenance´, and lack of
actualization
     ( see ahead )
.    My application code is  frequently changed.  Also, at first sigth, it
seems generating lots of code. .
     Is this rigth ?
> * How could tolua be improved?
    Celes just said that some comments are recognized ( even if a pkg still
needed ... but nearly
    empty ). So, the ´two file´ question is half answered.
    The remaining is an application design issue: are we coding lua bindings
into every application
    module ? or are we confining the bindings to some ´special services´
ones  ?
    Because of some config language independence, I am using the second
model: as far as I
    can, the usage ( the service or functionality ) of the
configuration/extension language is
    as confined as possible, having standard C functions which
´transparently´ returns the
    ´service´ results  to the main environment. In other words, most
application modules are not
    so much concerned with what exactly is going behind scenes. Of course,
there is not a
    full functional independence: expected services are more or less coupled
to extension language
    features, but at least we can recognize some ´access points´.
    Partially, I prefer this model because some uncertainties: recently, I
posted some questions
    ( nobody answered ), by example, how to tigth control the gc. For a
´normal´ application,
    the gc performance degradation is not an issue, while the total memory
usage is.
    Despite all the previous junk, I just revisited tolua docs.
    Some ´extra conditional compiling´ would be neccesary, by example:
    tolua has the pretty ´@´  ´token´ ( I don´t know what it´s exactly in
semantic terms )
    to rename host objects. But currenttly, its use _requires_ a pkg hand
written, because there
    is no way to fake the C compiler. Also, I see that some C++ keywords
must not appear
    ( ´public´ ) etc.
    It seems to me that what is needed is a sort of specialist ´sed´, a tool
that reads a C/C++ header
    and interprets
    a) some #ifdef directives
    #ifdef  TOLUA_EXCLUSIVE_USE
    type cfunca( int, int, int a = 5 ) @ Coverloadedf
    type cfuncb( char * )    @  Coverloadedf
   #else
    type cfunca( int, int, int )
   etc
   #endif
    May be also required some extra trickery. Some preprocessors don´t
completely
    ignore the FALSE ifdef region. By example Watcom 10.6 generates an error
on this construct
    #ifdef TOLUA
    #define BADSTR "badstring              // note the absent closing quote
    #else
     ....
    #endif
    even if TOLUA is not defined, the pre parses the #define BADSTR line,
and claims that a
    \ continuation char is absent, and worse, it thinks that all remaining
text is part of the
    offending string, not seeing the endif  etc
    May be other preprocs do this way with other consttructs so may be (
compile time option ? )
    the ´toluased´ tool needs to recognize thigs like
    ///(tolua) type .... etc
    the ///(tolua) token would be neccesary to start a comment from the
preproc point of view, but
    to inform the ´ssed´ that this is not really a comment from the tolua
perspective
 b) some special block and line comments ( more than Celes reported )
     // _tolua_block_include
      ....
     // _tolua_block_end
    // _tolua_block_exclude
    ....
    // _tolua_block_end
    ....      // _tolua_line_include
    ...       // _tolua_line_exclude
Having this tool ( which also a makefile could invoke ) one could devise the
pkg to $#include
an automatically generated file ...
I think about a distinct tool because it seems more easy to textually
´parse´ a file ´sed style´
ignoring the saved lines semantics and sintax than to do all af them at once
( the line ´directives´
are  cumbersome ... )
Also, another good reason is customization: when compiling the tool, one
could define
not only the ´special comments´ but, more important, the special constructs
needed to
fake the preproc ( the ´///(tolua)´ example ) but allowing true comments
I don´t even tried tolua, because while using 3.2, I was excessively newbie;
when tried
4.0, tolua was not ported to that version; then I find more understandable
and usable
the userdata logic of 5.0a, and married with.




> (end of survey)