Hi John, > Interesting, but that means that they're emulating the removed functions and > I wonder what their setfenv() does.
Right; the code for setfenv is here: https://github.com/corsix/twoface/blob/master/twoface.c#L492-L532 > In 5.2 setfenv() function was removed and the environment for a function is > set by the _ENV table which should be the first upvalue for the function. I > believe that this is automatic so the 5.2 behavior should be more expected, > but I haven't rigorously tested what happens with callbacks in modules or > even if you swap out the _ENV before setting the callback. > http://stackoverflow.com/questions/14290527/recreating-setfenv-in-lua-5-2 yes, I'm familiar with this logic (in fact, one of the answers is mine), but only on the Lua side. I'm not sure how it maps to C calls. > Is there any way to detect when the twoface DLL is being used so that the > code can take the 5.2 path? Possibly, but I can't answer that question. > Or maybe compile wxLua for 5.2 and use woface to treat 5.1 as 5.2 instead of > the other way around. No, this won't work as Twoface only works one way (mapping 5.1 calls to 5.2 engine). For now I patched my build process to remove those fragments and so far have been running with twoface and Lua 5.2 without issues. I'm still not sure what that fragment I removed does as my event callbacks use various upvalues and seem to work correctly without that setfenv check (and they were throwing the error before I removed the checks), which makes me think that the check is not really needed. I'll leave the decision up to you and let you know if I run into any issues, but so far I only have two patches that make my wxlua libraries deviate from yours: this change (not deployed yet) and the live coding fix I applied (http://comments.gmane.org/gmane.comp.lib.wxwidgets.wxlua.user/3273). Actually, there is one more interesting issue, related to the live coding fix. I'll describe it briefly here, maybe you can add some details to it. The classes you create in wxlua conveniently allow additional properties to be assigned to them. For example, I can do "local editor = wxstc.wxStyledTextCtrl(...)" and then "editor.foo = 'bar'" and it all works. However, if I then try to access editor.foo from *another* coroutine, it doesn't "see" that property and I get "wxLua: Unable to call an unknown method ..." error, even though the property is there. I haven't been able to figure out where exactly it fails and for now I just worked around these cases, but it would be great if this could be fixed (if there is a fix for that). Ideally, editor.foo should return nil and editor.foo() should return an error, but the comment you have in the code seems to point out that it may not be possible to distinguish between these two cases. I think it's because in editor.foo(), it gets the value of editor.foo first and then calls it as a function. I'll be fine if it returns `nil` and then fails on the function call. Paul. On Sat, Jul 20, 2013 at 11:26 AM, John Labenski <jlaben...@gmail.com> wrote: > > On Fri, Jul 19, 2013 at 7:54 PM, Paul K <paulclin...@yahoo.com> wrote: >> >> Hi John, >> >> I've been looking into using twoface ABI mapper >> (http://corsix.github.io/twoface/) to run ZeroBrane Studio on top of >> Lua 5.2 without recompiling wxlua and luasocket (both are compiled for >> Lua 5.1). For those not familiar with it, it allows to run Lua 5.2 >> engine with modules compiled for Lua 5.1 without any changes to those >> modules. In my case, I use it with ZBS that is compiled for Lua 5.1 >> and can make it run with Lua 5.2 by replacing lua51.dll with a >> different one (and adding lua52.dll). >> > > Interesting, but that means that they're emulating the removed functions and > I wonder what their setfenv() does. > > >> >> I have been able to run it with wxlua, but I ended up patching wxlua >> in one place. For some reason when I ran it originally, I was getting >> "wxLua: wxEvtHandler::Connect() in wxLuaEventCallback::OnEvent(), >> callback function is not a Lua function." messages in more or less >> random places. This error comes from an event handler check in >> wxlcallb.cpp and it appears to be only active for Lua 5.1: >> >> #if LUA_VERSION_NUM < 502 >> // lua_setfenv() is not in Lua 5.2 nor can you set an env for >> a function anymore >> wxlState.GetGlobals(); >> if (wxlState.lua_SetFenv(-2) != 0) >> #endif // LUA_VERSION_NUM < 502 >> { >> // Don't track the wxEvent since we don't own it and tracking >> it >> // causes clashes in the object registry table since many can >> be >> // created and deleted and the mem address is resused by C++. >> wxlState.wxluaT_PushUserDataType(event, event_wxl_type, >> false); >> wxlState.LuaPCall(1, 0); // one input no returns >> } >> #if LUA_VERSION_NUM < 502 >> else >> wxlState.wxlua_Error("wxLua: wxEvtHandler::Connect() in >> wxLuaEventCallback::OnEvent(), callback function is not a Lua >> function."); >> #endif // LUA_VERSION_NUM < 502 >> >> I have never seen this error with 5.1 and am not sure what the purpose >> of it is. Given that it doesn't even run for Lua 5.2, I completely >> disabled this check and everything appears to be working as expected. >> > > It's there for backwards compatibility so that programs run as expected in > 5.1, but in 5.2 things are a little different. See below. > > >> >> Is there any reason for this check (especially given that it behaves >> differently for lua 5.1 and 5.2) and is it possible to remove/disable >> it? >> > > In < 5.2 wxLua used the globals as the environment for the callback function > to give a uniform state. This was how it was before I took over wxLua and > though it wasn't strictly necessary I didn't see any reason to change it. > > In 5.2 setfenv() function was removed and the environment for a function is > set by the _ENV table which should be the first upvalue for the function. I > believe that this is automatic so the 5.2 behavior should be more expected, > but I haven't rigorously tested what happens with callbacks in modules or > even if you swap out the _ENV before setting the callback. > > http://stackoverflow.com/questions/14290527/recreating-setfenv-in-lua-5-2 > > -------------------------------- > > Is there any way to detect when the twoface DLL is being used so that the > code can take the 5.2 path? Or maybe compile wxLua for 5.2 and use woface to > treat 5.1 as 5.2 instead of the other way around. > > > Regards, > John > > > > ------------------------------------------------------------------------------ > See everything from the browser to the database with AppDynamics > Get end-to-end visibility with application monitoring from AppDynamics > Isolate bottlenecks and diagnose root cause in seconds. > Start your free trial of AppDynamics Pro today! > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk > _______________________________________________ > wxlua-users mailing list > wxlua-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wxlua-users > ------------------------------------------------------------------------------ See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk _______________________________________________ wxlua-users mailing list wxlua-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxlua-users
