Re: [wxlua-users] Using wxlua with Lua 5.1 and Twoface ABI mapper
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=48808831iu=/4140/ostg.clktrk___
wxlua-users mailing list
wxlua-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxlua-users
Re: [wxlua-users] wxlua trunk build fails on Windows using Mingw
On Fri, Jul 19, 2013 at 3:34 PM, Paul K paulclin...@yahoo.com wrote: Hi John, I tried to compile the current trunk on Windows using mingw and ran into a compilation error: ...wxLua/modules/wxbind/src/wxcore_bind.cpp: In member function 'virtual bool wxLuaBinding_wxcore::RegisterBinding(const wxLuaState)': ...wxlua/wxLua/modules/wxbind/src/wxcore_bind.cpp:7495:46: error: 'wxEVT_COMMAND_DIRPICKER_CHANGED' was not declared in this scope ...wxLua/modules/wxbind/src/wxcore_bind.cpp:7496:46: error: 'wxEVT_COMMAND_FILEPICKER_CHANGED' was not declared in this scope This follows a warning about re-definition: ...wxLua/modules/wxbind/src/wxcore_bind.cpp:73:0: warning: wxEVT_COMMAND_DIRPICKER_CHANGED redefined [enabled by default] ...include/wx-2.9/wx/filepicker.h:418:0: note: this is the location of the previous definition ...wxLua/modules/wxbind/src/wxcore_bind.cpp:74:0: warning: wxEVT_COMMAND_FILEPICKER_CHANGED redefined [enabled by default] ...include/wx-2.9/wx/filepicker.h:417:0: note: this is the location of the previous definition The issue seems to be caused by this #if in modules/wxbind/src/wxcore_bind.cpp: #if defined(__MINGW32__) || defined(__GNUWIN32__) // FIX: internal compiler error: output_operand: invalid expression as operand I'm not sure if the comment still applies, but I removed this #if (and another one around line 7488 in the same file) and compiled without any errors/issues. When you say remove the #if you mean just the #if statement or all of the code in the #if statement. As you can tell that is a strange hack for that compiler and I wish I documented the version. Can you please take a look at this and check if this #if is still needed? It's seems like you can safely remove it. Thank you. I'm using the latest wxwidgets (2.9.5 release candidate) and gcc 4.6.2. What gcc are you using? MingW as per these directions or something else and from where and why? http://wxlua.sourceforge.net/docs/install.html#C2.4 http://sourceforge.net/projects/mingw/files/Installer/mingw-get-inst/ The mingw-get-inst-20120426http://sourceforge.net/projects/mingw/files/Installer/mingw-get-inst/mingw-get-inst-20120426/is gcc 4.7.0 and I do believe that that #if is needed for that compiler. 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=48808831iu=/4140/ostg.clktrk___ wxlua-users mailing list wxlua-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxlua-users
Re: [wxlua-users] Using wxlua with Lua 5.1 and Twoface ABI mapper
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
