RE: lua_ref problem

[Chris Chapman <Chris.chapman@...>]

Thanks everyone for their help in tracking this one down. Sorry for the
delayed response, but I've been ill and unwilling to face a computer screen
to track down the problem. It was as RLake pointed out to me, a problem with
the table size functions, related to my dropping the precision to 32 bit
floats. The compiler had for some reason generated double precision
instructions for the luaL_setn operation so that the size of the table was
not being set correctly.

Don't ask me how I fixed it, after tracking all references and being unable
to find why lua_Number was considered a double instead of float, one of the
Rebuild Alls resulted in the compiler generating single precision
instructions instead. Problem solved, although since the code-base is
unchanged, I'm loath to count it as properly gone away.

-----Original Message-----
From: Taj Khattra [mailto:taj.khattra@pobox.com]
Sent: 09 November 2003 19:16
To: Lua list
Subject: Re: lua_ref problem


On Fri, Nov 07, 2003 at 09:34:18AM -0600, Virgil Smith wrote:
> >Is this the result that everyone else gets?
> Not at all.  I just coded a quick test and my output is...
> 
> GetRef(FuncOne) = 3
> GetRef(FuncOne) = 4
> GetRef(FuncOne) = 5
> GetRef(FuncTwo) = 6
> GetRef(FuncOne) = 7
> GetRef(FuncOne) = 8
> 

me too

int getref(lua_State *L) { lua_pushnumber(L, lua_ref(L, 1)); return 1; }
int unref(lua_State *L) { lua_unref(L, lua_tonumber(L, -1)); return 0; }

---------------------------
bin> ./luaxxx -e"_PROMPT=''" -i <<EOF
> function foo() end
> function bar() end
> =getref(foo)
> =getref(foo)
> =getref(bar)
> =getref(foo)
> unref(3)
> =getref(foo)
> unref(5)
> =getref(bar)
> =getref(foo)
> EOF
3
4
5
6
3
5
7

bin>
---------------------------

-taj