analog of tk 'send' command.

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

analog of tk 'send' command.

Max Ischenko

Hi all.

I encounter the following problem.
I developing two programs, both of them use Lua as their scripting language.
And i need a way to talk between this two programs.
There are many IPC in UNIX; signals, pipes, sockets, ...
but I would like to use something like this:
lua_send(123, 'session.itm.value = 2134');


Did anyone do something similar?
I think to implement it via UDP packet --> dostring().
Will this work and not too slow?


-- 
HTTP; (Ach 'tE 'tE 'pE) adj, n: 1. Handy Tool (for) Touring Pornos 2. Happy
Techies Tour for Pornos 3. who cares, as long as it ends with Pornos.

Reply | Threaded
Open this post in threaded view
|

tolua, c++, garbagecollection and memory management

Dirk Ringe
Hi,

the tolua docs are somewhat cryptic about this, so I just ask the list. We
are currently doing a game with lua as script engine for animation
definitions, user interface and other stuff. We use tolua for binding our
game objects to lua. Now there are some questions about how tolua uses
memory management and works together with the garbage collector. Since we
currently use tolua 3.2, but probably switch to tolua 4.0 when it is ready,
it would be nice if the questions are answered for both versions!

1. I create a c++ object from within lua, with something like

	button = CMnuButton:new()

  Will the appropriate destructor be called when button leaves the scope
(ie. the GC gets it)?

  Ex:

  function Dialog()
    local b1
    local b2

    b1 = CMnuButton:new()
    b2 = CMnuButton:new()
  end

2. Now I register the object within my framework. From now on my framework
should be responsible for this object, and the GC should NOT delete the
userdata associated with button, when button is collected. Is there any
chance to do something like this?

Ex:

  function Dialog()
    local b1
    local b2

    b1 = CMnuButton:new()
    b2 = CMnuButton:new()
    Screen:RegisterButton(b1)
    Screen:RegisterButton(b2)
  end

3. I have methods that return pointer to an object. Will this object stay
untouched when the var where it is referenced by leaves the scope?

Ex:

  function Dialog()
    local b1
    b1 = Screen:GetActiveButton()
  end

4. I see from the code, that tolua makes copies of userdata objects returns
by reference or value. Are these objects correctly collected when they leave
scope?





Thx,

  Dirk


Reply | Threaded
Open this post in threaded view
|

Re: tolua, c++, garbagecollection and memory management

Waldemar Celes-3
>
>
> the tolua docs are somewhat cryptic about this, so I just ask the list. We
> are currently doing a game with lua as script engine for animation
> definitions, user interface and other stuff. We use tolua for binding our
> game objects to lua. Now there are some questions about how tolua uses
> memory management and works together with the garbage collector. Since we
> currently use tolua 3.2, but probably switch to tolua 4.0 when it is ready,
> it would be nice if the questions are answered for both versions!
>
> 1. I create a c++ object from within lua, with something like
>
>         button = CMnuButton:new()
>
>   Will the appropriate destructor be called when button leaves the scope
> (ie. the GC gets it)?
>

no, it won't be collected. objects created with "new" should be explicitly
deleted with "delete".
or you may call the function "takeownership" to tell tolua to collect it when it
leaves the scope.

>
>
> 2. Now I register the object within my framework. From now on my framework
> should be responsible for this object, and the GC should NOT delete the
> userdata associated with button, when button is collected. Is there any
> chance to do something like this?
>
> Ex:
>
>   function Dialog()
>     local b1
>     local b2
>
>     b1 = CMnuButton:new()
>     b2 = CMnuButton:new()
>     Screen:RegisterButton(b1)
>     Screen:RegisterButton(b2)
>   end

again, it will not be garbage collected.

>
> 3. I have methods that return pointer to an object. Will this object stay
> untouched when the var where it is referenced by leaves the scope?
>

sure.

> 4. I see from the code, that tolua makes copies of userdata objects returns
> by reference or value. Are these objects correctly collected when they leave
> scope?

in that case, it will be collected. the behavior here is the same as when you
call "takeownership".

-- waldemar


Reply | Threaded
Open this post in threaded view
|

Re: analog of tk 'send' command.

Roberto Ierusalimschy
In reply to this post by Max Ischenko
> but I would like to use something like this:
> lua_send(123, 'session.itm.value = 2134');

Check ALua: http://www.tecgraf.puc-rio.br/~ururahy/alua/

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: tolua, c++, garbagecollection and memory management

Christian Vogler-2
In reply to this post by Waldemar Celes-3
On Thu, Jan 11, 2001 at 02:50:14PM -0200, Waldemar Celes wrote:
> no, it won't be collected. objects created with "new" should be
> explicitly deleted with "delete".  or you may call the function
> "takeownership" to tell tolua to collect it when it leaves the
> scope.

I wrote some meta-code that makes this somewhat easier. Basically, if
you define a class A, it lets you do the following:

uncollected_instance = A:new(blah ...)
collected_instance = A(blah ...)

The first syntax does not take ownership, while the second one
does. Siome and I find this pretty convenient in our project. If
anyone is interested, e-mail me, and I will make it available.

I also have a whole bunch of tips and tricks for generating good C++
bindings with tolua. Trouble is only, they all pertain to tolua 3.2,
and I'm not sure how many of them are still valid for tolua 4.0. But
again, if anyone is interested, I will be happy to share them.

- Christian

Reply | Threaded
Open this post in threaded view
|

Re: tolua, c++, garbagecollection and memory management

James Hearn
Christian Vogler wrote:
> 
> On Thu, Jan 11, 2001 at 02:50:14PM -0200, Waldemar Celes wrote:
> > no, it won't be collected. objects created with "new" should be
> > explicitly deleted with "delete".  or you may call the function
> > "takeownership" to tell tolua to collect it when it leaves the
> > scope.
> 
> I wrote some meta-code that makes this somewhat easier. Basically, if
> you define a class A, it lets you do the following:
> 
> uncollected_instance = A:new(blah ...)
> collected_instance = A(blah ...)
> 
> The first syntax does not take ownership, while the second one
> does. Siome and I find this pretty convenient in our project. If
> anyone is interested, e-mail me, and I will make it available.
> 
> I also have a whole bunch of tips and tricks for generating good C++
> bindings with tolua. Trouble is only, they all pertain to tolua 3.2,
> and I'm not sure how many of them are still valid for tolua 4.0. But
> again, if anyone is interested, I will be happy to share them.
> 
> - Christian

I would be very interested in hearing your tips. I'm about to bind a c++
game-windowing toolkit to lua, and any info would be helpful.

--James Hearn

Reply | Threaded
Open this post in threaded view
|

Re: analog of tk 'send' command.

Steve Dekorte-4
In reply to this post by Max Ischenko
Roberto Ierusalimschy wrote:
> Check ALua: http://www.tecgraf.puc-rio.br/~ururahy/alua/ 

This is an neat project. 
Is there much overhead associated with communicating with agents on
the same machine? I'm wondering if an actor-based language could be 
implemented with this.

Steve

Reply | Threaded
Open this post in threaded view
|

Re: tolua, c++, garbagecollection and memory management

Sebby
In reply to this post by James Hearn
This could easily be done with a C++ functor template to define the 
stub functions. Here is a link to an example of functors

http://www.bestweb.net/~rhickey/

Sebastien St-Laurent
[hidden email]

--- In [hidden email], James Hearn <james.hearn@b...> wrote:
> Christian Vogler wrote:
> > 
> > On Thu, Jan 11, 2001 at 02:50:14PM -0200, Waldemar Celes wrote:
> > > no, it won't be collected. objects created with "new" should be
> > > explicitly deleted with "delete".  or you may call the function
> > > "takeownership" to tell tolua to collect it when it leaves the
> > > scope.
> > 
> > I wrote some meta-code that makes this somewhat easier. 
Basically, if
> > you define a class A, it lets you do the following:
> > 
> > uncollected_instance = A:new(blah ...)
> > collected_instance = A(blah ...)
> > 
> > The first syntax does not take ownership, while the second one
> > does. Siome and I find this pretty convenient in our project. If
> > anyone is interested, e-mail me, and I will make it available.
> > 
> > I also have a whole bunch of tips and tricks for generating good 
C++
> > bindings with tolua. Trouble is only, they all pertain to tolua 
3.2,
> > and I'm not sure how many of them are still valid for tolua 4.0. 
But
> > again, if anyone is interested, I will be happy to share them.
> > 
> > - Christian
> 
> I would be very interested in hearing your tips. I'm about to bind 
a c++
> game-windowing toolkit to lua, and any info would be helpful.
> 
> --James Hearn


Reply | Threaded
Open this post in threaded view
|

Re: tolua, c++, garbagecollection and memory management

Christian Vogler-2
On Fri, Jan 12, 2001 at 03:27:56AM -0000, Sebby  wrote:
> This could easily be done with a C++ functor template to define the 
> stub functions. Here is a link to an example of functors
>
> http://www.bestweb.net/~rhickey/

Yor ideas remind me a lot of the Qt library's signal/slot
mechanism. Have you taken a look at it? Your approach, however, has
the advantage that it does not rely on any kind of extensions to the
C++ language, whereas with Qt you need a special preprocessor (moc).

- Christian

Reply | Threaded
Open this post in threaded view
|

AW: tolua, c++, garbagecollection and memory management

Dirk Ringe
QT signal/slot system does not only need a preprocessor, but also uses
string message parsing, with causes a lot of overhead. Any decent template
based C++ callback system should be able to outperform the signal/slot
system and also provide more type safety (which is essentially for free on a
template system).

For infos about C++ callbacks look at the following site:

http://sunsite.dk/lgdc/articles.php3?mode=body&articleid=5


I did extend the system so that I am able to bind a Lua function to a
callback, so that when the C++ object calls the callback it can jump
seamless into Lua (without even knowing about Lua in the system).  Very nice
feature, when you don't know beforehand, what parts of your code will be
written in Lua and what in C++ (sometimes we got to switch from Lua to C++
for performance reasons, etc.)


Dirk

-----Ursprungliche Nachricht-----
Von: [hidden email]
[[hidden email] Auftrag von Christian Vogler
Gesendet: Freitag, 12. Januar 2001 10:25
An: Multiple recipients of list
Betreff: Re: tolua, c++, garbagecollection and memory management


On Fri, Jan 12, 2001 at 03:27:56AM -0000, Sebby  wrote:
> This could easily be done with a C++ functor template to define the
> stub functions. Here is a link to an example of functors
>
> http://www.bestweb.net/~rhickey/

Yor ideas remind me a lot of the Qt library's signal/slot
mechanism. Have you taken a look at it? Your approach, however, has
the advantage that it does not rely on any kind of extensions to the
C++ language, whereas with Qt you need a special preprocessor (moc).

- Christian


Reply | Threaded
Open this post in threaded view
|

Re: AW: tolua, c++, garbagecollection and memory management

James Hearn
Dirk Ringe wrote:
> 
> QT signal/slot system does not only need a preprocessor, but also uses
> string message parsing, with causes a lot of overhead. Any decent template
> based C++ callback system should be able to outperform the signal/slot
> system and also provide more type safety (which is essentially for free on a
> template system).
> 
> For infos about C++ callbacks look at the following site:
> 
> http://sunsite.dk/lgdc/articles.php3?mode=body&articleid=5
> 
> I did extend the system so that I am able to bind a Lua function to a
> callback, so that when the C++ object calls the callback it can jump
> seamless into Lua (without even knowing about Lua in the system).  Very nice
> feature, when you don't know beforehand, what parts of your code will be
> written in Lua and what in C++ (sometimes we got to switch from Lua to C++
> for performance reasons, etc.)
> 
> Dirk

May I ask how you were able to bind lua to these callbacks? The game
windowing system I am modifying is a mini-Qt-alike system for the
Allegro game library. (No language extensions or string parsing, but it
does require gui objects to inherit from a base gui object class in
order to gain access to the signal and slot controlling methods.) My
goal is to be able to dynamically create/modify/save guis from a lua
console within a program. A big part of this would be using lua
functions transparently as signals/slots.


Many thanks,

James Hearn

Reply | Threaded
Open this post in threaded view
|

AW: AW: tolua, c++, garbagecollection and memory management

Dirk Ringe
Thats exact the concept we have for our gui system. Our GUI consists of C++
classes for all the base gui stuff like windows and buttons and edits
fields. The components use a callback system like described in the article
below, the usage of these is a bit like delphi.

Now all these objects are available to the Lua state via toLua. Lua code is
able to receive such signals via these callbacks but are not able to send
signals (which when I think about it should also be perfectly possible *g*).

So how to persuade the C++ callback system to call Lua functions
transparently? A Lua call requires a state and the function name (and also
the parameters, but this will be taken care for later). These parameters are
not part of the callback storage, so I have to provide a proxy class for
this binding. Like this one:

template <class arg1>
class CScrCallbackProxy1 : public CScrCallbackProxyBase
{
public:

    void Execute (arg1 _a1)
    {
        pScript->PushObject (_a1);
        pScript->CallFunction (sFunction);
    };


    CScrEnvironment *pScript;
    CUtlString sFunction;
};


Now when we bind the Lua function we create an instance of the proxy class,
store the state pointer (encapsuled in CScrEnvironment) and the function
name in this object, store the instance pointer in a global list for memory
management and create a C++ callback calling Execute with this special
instance object. Like this:

template <class arg1>
CUtlCallback1 <CScrCallbackProxy1 <arg1>, arg1> ScrMakeFunctor1
(CScrEnvironment *_pScript, const CUtlString &_sFunction)
{
    CScrCallbackProxy1 <arg1> *pProxy;

    pProxy = new CScrCallbackProxy1 <arg1> ();
    pProxy->pScript = _pScript;
    pProxy->sFunction = _sFunction;
    _pScript->RegisterProxy (pProxy);

    return UtlMakeFunctor1 (pProxy, CScrCallbackProxy1<arg1>::Execute);
};



All this template stuff is based on the base C++ callback paper, so don't be
worried, it is expained somewhere, but not here *g* But feel free to ask
offline for this, if you want further infos. I like this template magic and
callback stuff....


And for the params life is really easy. You've probably seen the PushObject
function pushing data on the Lua stack without caring for the type? Just a
few more template lines. This one will select based on the type a mapper
class and calls push on that:

template <class T> void PushObject (T What) { CScrTypeMapper<T>::Push
(What); }



And this are the mapper class definitions:


template <class T>
class CScrTypeMapper
{
    public:

        static void Push (T What) { lua_pushuserdata (What); };
};

template <>
class CScrTypeMapper <int>
{
    public:

        static void Push (int What) { lua_pushnumber (What); };
};

template <>
class CScrTypeMapper <double>
{
    public:

        static void Push (double What) { lua_pushnumber (What); };
};

template <>
class CScrTypeMapper <CUtlString>
{
    public:

        static void Push (CUtlString What) { lua_pushstring (const_cast
<char *> (What.CMbStr ())); };
};




Is rather long the explanation, but I hope you can understand this...


Dirk



-----Ursprungliche Nachricht-----
Von: [hidden email]
[[hidden email] Auftrag von James Hearn
Gesendet: Freitag, 12. Januar 2001 14:41
An: Multiple recipients of list
Betreff: Re: AW: tolua, c++, garbagecollection and memory management


Dirk Ringe wrote:
>
> QT signal/slot system does not only need a preprocessor, but also uses
> string message parsing, with causes a lot of overhead. Any decent template
> based C++ callback system should be able to outperform the signal/slot
> system and also provide more type safety (which is essentially for free on
a
> template system).
>
> For infos about C++ callbacks look at the following site:
>
> http://sunsite.dk/lgdc/articles.php3?mode=body&articleid=5
>
> I did extend the system so that I am able to bind a Lua function to a
> callback, so that when the C++ object calls the callback it can jump
> seamless into Lua (without even knowing about Lua in the system).  Very
nice
> feature, when you don't know beforehand, what parts of your code will be
> written in Lua and what in C++ (sometimes we got to switch from Lua to C++
> for performance reasons, etc.)
>
> Dirk

May I ask how you were able to bind lua to these callbacks? The game
windowing system I am modifying is a mini-Qt-alike system for the
Allegro game library. (No language extensions or string parsing, but it
does require gui objects to inherit from a base gui object class in
order to gain access to the signal and slot controlling methods.) My
goal is to be able to dynamically create/modify/save guis from a lua
console within a program. A big part of this would be using lua
functions transparently as signals/slots.


Many thanks,

James Hearn