headers
Steve Dekorte | 19 Sep 1999 21:59
Gravatar

Re: evolutionary programming & Lua

Luiz Henrique de Figueiredo <lhf <at> tecgraf.puc-rio.br> wrote:
> Here is a simple implementation of arithmetic expressions in Lua that should
> be adequate for evolutionary programming.
>..
> E{add,1,{mul,2,3}}

I like this example, but isn't this going to be alot slower than doing it
as Dolfi suggested in Scheme? I suppose that you could also write something
to turn these structures into a string and call dostring() but then you've
got the whole code structure -> text -> compiled code that scheme avoids.

Steve
Permalink | Reply | 1 comment |
headers
Steve Dekorte | 20 Sep 1999 00:49
Gravatar

Re: evolutionary programming & Lua

Luiz Henrique de Figueiredo <lhf <at> tecgraf.puc-rio.br> wrote:
> >I suppose that you could also write something
> >to turn these structures into a string and call dostring() but then you've
> >got the whole code structure -> text -> compiled code that scheme avoids.
> 
> I don't get it. Why convert the tables into strings??

I meant convert them to their code equivalent and compile it so it will
execute faster. For example:

  7 + ( 4 * 3 )

executes faster than:

  E{add,7,{mul,4,3}}

right?

So make a function that turns:

 {add,7,{mul,4,3}}

into:

 myFunc = dostring("return function () return args.1 + ( args.2 * args.3 )")

and precompile it. Then execute it with the current args:

 result = myFunc({7,4,3})
(Continue reading)

Permalink | Reply | 3 comments |
headers
domain | 1 Sep 1999 05:31

Problem with Lua in c++ and stl

Hello,

I am using LUA in my game...One of my classes registers one of its
methods, Add(), with LUA, so that it can be called by LUA. I have
reduced my Add() method to simply doing a myvector.push_back(5),
myvector is a private variable in my class, vector<int> myvector. Am I
supposed to be using LUA differently with c++?

BTW, I think LUA is great, I just wish I can get this to work. Thanks.

My app dumps core somewhere within the stl code. Here is the backtrace:
#0  GameMap::AddTileBitmap (this=0x0, image=0x805f608)
    at /usr/local/include/g++/stl_vector.h:145
145         if (finish != end_of_storage) {
(gdb) bt
#0  GameMap::AddTileBitmap (this=0x0, image=0x805f608)
    at /usr/local/include/g++/stl_vector.h:145
#1  0x8049b83 in GameMap::AddTile (this=0x0) at game_map.cpp:56
#2  0x804b42c in callC () at game_map.cpp:64
#3  0x804b594 in luaD_calln () at game_map.cpp:64
#4  0x80507df in luaV_execute () at game_map.cpp:64
#5  0x804b5b6 in luaD_calln () at game_map.cpp:64
#6  0x80507df in luaV_execute () at game_map.cpp:64
#7  0x804b5b6 in luaD_calln () at game_map.cpp:64
#8  0x804b879 in luaD_protectedrun () at game_map.cpp:64
#9  0x804ba96 in do_main () at game_map.cpp:64
#10 0x804bbc8 in lua_dofile () at game_map.cpp:64
#11 0x804999c in GameMap::Load (this=0x805bdd8, 
    script_file=0x8054e22 "script/tileset_regular.lua") at
game_map.cpp:38
(Continue reading)

Permalink | Reply | 1 comment |
headers
David Jeske | 1 Sep 1999 06:57

Re: Problem with Lua in c++ and stl

On Wed, Sep 01, 1999 at 01:19:32AM -0300, Mike Cuddy wrote:
> // it's a pity that cfunction's in lua don't get to carry userdat, then we
> // could pass the object "implicitly" to the C -> C++ binding function.
> // instead of digging it out of a table.

Unfortunatly, it's not as simple as having a cfunction carry a
userdata. There is no portable way to build an argument list to pass
to a function call in C. On some platforms arguments are all passed on
the stack, on other platforms some arguments are passed in registers.

However, lua could provide simple "one argument" and "zero argument"
functions. The one argument case would handle C++ methods pretty
well. I'll have to see how much cleaner this would make my C++<->Lua
code.

--

-- 
David Jeske (N9LCA) + http://www.chat.net/~jeske/ + jeske <at> chat.net
Permalink | Reply | 0 comments |
headers
Luiz Henrique de Figueiredo | 1 Sep 1999 13:28
Picon

Re: Problem with Lua in c++ and stl

On Wed, Sep 01, 1999 at 01:19:32AM -0300, Mike Cuddy wrote:
> // it's a pity that cfunction's in lua don't get to carry userdat, then we
> // could pass the object "implicitly" to the C -> C++ binding function.
> // instead of digging it out of a table.

I think a C closure might help here.
--lhf
Permalink | Reply | 0 comments |
headers
Waldemar Celes | 1 Sep 1999 17:02
Picon

Re: Problem with Lua in c++ and stl

> I am using LUA in my game...One of my classes registers one of its
> methods, Add(), with LUA, so that it can be called by LUA. I have
> reduced my Add() method to simply doing a myvector.push_back(5),
> myvector is a private variable in my class, vector<int> myvector. Am I
> supposed to be using LUA differently with c++?
>

you can try using "tolua" for binding your classes and methods to Lua.
http://www.tecgraf.puc-rio.br/~celes/tolua/tolua-v3.html

-- waldemar
Permalink | Reply | 0 comments |
headers
Supratik Champati | 1 Sep 1999 19:46

3.2 Bug

lua 3.2 bug on HPUX machines

The following piece of code in lparser.c needs to be replaced

static TaggedString *str_checkname (LexState *ls) {
  return tsvalue(&ls->fs->f->consts[checkname(ls)]);
}

-- modified code
static TaggedString *str_checkname (LexState *ls) {
  int sc = checkname(ls);
  return tsvalue(&ls->fs->f->consts[sc]);
}

This is causing a core dump on HPUX machines. The reason
is rather obvious.

I hope this change finds its way thru to the official release.

Thanks
--

-- 
Supratik
Permalink | Reply | 5 comments |
headers
Michael T. Richter | 1 Sep 1999 20:18

Re: 3.2 Bug

At 01:53 PM 9/1/99 , you wrote:
>static TaggedString *str_checkname (LexState *ls) {
>  return tsvalue(&ls->fs->f->consts[checkname(ls)]);
>}

>static TaggedString *str_checkname (LexState *ls) {
>  int sc = checkname(ls);
>  return tsvalue(&ls->fs->f->consts[sc]);
>}

>This is causing a core dump on HPUX machines. The reason
>is rather obvious.

It isn't obvious at all to me.  What's the problem?  Does HPUX's version of
C not allow return values of functions in array accessors?

--
Michael T. Richter    <mtr <at> ottawa.com>    http://www.igs.net/~mtr/
          PGP Key: http://www.igs.net/~mtr/pgp-key.html
PGP Fingerprint: 40D1 33E0 F70B 6BB5 8353 4669 B4CC DD09 04ED 4FE8
Permalink | Reply | 1 comment |
headers
Supratik Champati | 1 Sep 1999 20:53

Re: 3.2 Bug

oops! I wanted to say it isn't rather obvious.

The problem is ls->fs->f->consts is initially NULL.
the call to checkname(ls) allocates the array.
On HPUX it is trying to access the index of a NULL array
and hence dumping core.

Michael T. Richter wrote:
> 
> At 01:53 PM 9/1/99 , you wrote:
> >static TaggedString *str_checkname (LexState *ls) {
> >  return tsvalue(&ls->fs->f->consts[checkname(ls)]);
> >}
> 
> >static TaggedString *str_checkname (LexState *ls) {
> >  int sc = checkname(ls);
> >  return tsvalue(&ls->fs->f->consts[sc]);
> >}
> 
> >This is causing a core dump on HPUX machines. The reason
> >is rather obvious.
> 
> It isn't obvious at all to me.  What's the problem?  Does HPUX's version of
> C not allow return values of functions in array accessors?
> 
> --
> Michael T. Richter    <mtr <at> ottawa.com>    http://www.igs.net/~mtr/
>           PGP Key: http://www.igs.net/~mtr/pgp-key.html
> PGP Fingerprint: 40D1 33E0 F70B 6BB5 8353 4669 B4CC DD09 04ED 4FE8
(Continue reading)

Permalink | Reply | 0 comments |
headers
Luiz Henrique de Figueiredo | 1 Sep 1999 22:18
Picon

Re: 3.2 Bug

>From lua-l <at> tecgraf.puc-rio.br Wed Sep  1 14:54:07 1999
>From: Supratik Champati <champati <at> sofy.com>

>lua 3.2 bug on HPUX machines
>
>The following piece of code in lparser.c needs to be replaced
>
>static TaggedString *str_checkname (LexState *ls) {
>  return tsvalue(&ls->fs->f->consts[checkname(ls)]);
>}
>
>-- modified code
>static TaggedString *str_checkname (LexState *ls) {
>  int sc = checkname(ls);
>  return tsvalue(&ls->fs->f->consts[sc]);
>}
>
>This is causing a core dump on HPUX machines. The reason
>is rather obvious.

It's not at all obvious too me.
Unfortunately, we don't have access to HPUX machines.
Could you please send me details? What compiler? gcc?
Perhaps we could compare the assembly output for the two versions of
str_checkname.
--lhf
Permalink | Reply | 0 comments |

Gmane