lua-users home
lua-l archive

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


>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

For reference info my script was....
---
function FuncOne(a)
	return a*2
end

function FuncTwo(a,b)
	return FuncOne(a+b)
end

print("GetRef(FuncOne) = ", GetRef(FuncOne), "\n")
print("GetRef(FuncOne) = ", GetRef(FuncOne), "\n")
print("GetRef(FuncOne) = ", GetRef(FuncOne), "\n")
print("GetRef(FuncTwo) = ", GetRef(FuncTwo), "\n")
print("GetRef(FuncOne) = ", GetRef(FuncOne), "\n")
print("GetRef(FuncOne) = ", GetRef(FuncOne), "\n")

---
and the registered function "GetRef" is...

int GetRef(lua_State *L)
{
	lua_pushnumber(L, (double)lua_ref(L, 1));
	return 1;
}

---
My Lua sources were base Lua5.0 (release) source compiled into a Windows DLL
with purely the addition of a MSVC .def file, a .cpp file containing an
empty "DLLMain", and a resource file with version info (gotta give credit
for a great tool to where it belongs :)

----
And before anyone criticizes the lack of error checking etc.  This was all
thrown together just to make this reply.

----
SO.

>I see the malloc/realloc hooks I wrote, and the
>search and replace changing all occurrences of
>double->float and long->int (required to make
>Lua 32-bit under Playstation2).

Thus the bug in Lua most likely lies these mods.
I recommend building a simple test program with the sources directly
compiled in (starting with unmodified raw "official" form).  If that doesn't
work, um, er, write back to everyone.  If that does work, then introduce
your mods one major change at a time until it breaks, then back up a step
and introduce that major step in pieces (if you can).


Well that's my $0.02.





-----Original Message-----
From: lua-bounces@bazar2.conectiva.com.br
[mailto:lua-bounces@bazar2.conectiva.com.br]On Behalf Of Chris Chapman
Sent: Friday, November 07, 2003 4:35 AM
To: 'Lua list'
Subject: RE: lua_ref problem


I'm not looking for reference counting or garbage collection behaviour. I am
looking for a way to store a reference to a Lua function so that it can be
called from the C code at a later date, without having to store a string
representing the function name.

I guess what I'm asking is for the original Lua 4.0 behaviour - that lua_ref
would return a unique reference ID for each value passed to it, even if the
lua value is the same.

E.g.
lua_ref(foo) == 3
lua_ref(foo) == 4
lua_ref(foo) == 5
lua_unref(3)
lua_ref(foo) == 3
lua_ref(foo) == 6

>From Roberto's reply to my original post (Lua on the Playstation2), I
inferred that this was the intended behaviour even in Lua 5.0. Hence I
brought it up with the list as a possible issue.

This behaviour occurs immediately after startup, so a lua_open, then a
lua_baselibopen, the lua_register for GetFunctionReference then the call to
this script. The code I posted is exactly the code used to invoke the
problem. Having diffed my source tree and the original lua distribution, I
see the malloc/realloc hooks I wrote, and the search and replace changing
all occurrences of double->float and long->int (required to make Lua 32-bit
under Playstation2).

Tracing through the luaL_ref call, I get the following behaviour - every
single time the function is called

lua_isnil(L, -1) always returns false, because the value being referenced is
not nil
lua_rawgeti(L, t, FREELIST_REF) pushes 0 onto the stack, so the function
goes into the /*no free elements*/ case
luaL_getn(L, t) always returns 0, which is less than RESERVED_REFS, so ref
ends up being 3
The value 3 is used for the rest of the function and eventually returned.

Is this the result that everyone else gets?