Hi John, A bit more information on my testing without luasocket.
I removed all the existing DLLs and deployed your lua.exe, wx.lua and wxlua_lua_shared-wx28mswu-2.8.12.dll. When I start my app, it crashes immediately (without any error message) with this report: Problem Event Name: APPCRASH Application Name: lua.exe Application Version: 0.0.0.0 Application Timestamp: 4fed3948 Fault Module Name: wxlua_lua_shared-wx28mswu-2.8.12.dll Fault Module Version: 0.0.0.0 Fault Module Timestamp: 4fed3947 Exception Code: c0000005 Exception Offset: 0000d8b2 OS Version: 6.0.6002.2.2.0.256.6 Locale ID: 1033 Additional Information 1: fd00 Additional Information 2: ea6f5fe8924aaa756324d57f87834160 Additional Information 3: fd00 Additional Information 4: ea6f5fe8924aaa756324d57f87834160 If I start a bit simpler version, it does show the editor window, but when I close the app (without doing anything else), it crashes with another crash report: Problem Event Name: APPCRASH Application Name: lua.exe Application Version: 0.0.0.0 Application Timestamp: 4fed3948 Fault Module Name: lua.exe Fault Module Version: 0.0.0.0 Fault Module Timestamp: 4fed3948 Exception Code: c0000005 Exception Offset: 00007c52 OS Version: 6.0.6002.2.2.0.256.6 Locale ID: 1033 Additional Information 1: fd00 Additional Information 2: ea6f5fe8924aaa756324d57f87834160 Additional Information 3: fd00 Additional Information 4: ea6f5fe8924aaa756324d57f87834160 Both seem to trigger the same error, just at different addresses. I don't have any additional information unfortunately, but please let me know if there is something I can try to assist in troubleshooting. Paul. On Sat, Jun 30, 2012 at 10:34 AM, Paul K <paulclin...@yahoo.com> wrote: > Hi John, > > (combining responses from three different messages) > > It all makes sense; I agree on UTF8. > >> You can't always expect that a lib compiled with one version of code >> to work with another. Ideally you would build wxLua and the socket lib >> together to ensure they both are using the same Lua library. In this >> case they are trying to use different lua51.dlls which is a real >> problem, they have to both use the same one. > > I understand. Any chance you can compile luasocket and luasec or at > least provide details on your build environment, so that I can match > it with my own compatible versions for those modules. I bet it's going > to be a problem for many people using new binaries (as binaries for > both of those modules will end up incompatible and many people will be > confused and disappointed). > >> Someday it may be possible to relax the conditions, but only for >> certain hand-picked functions. However, the reality is that I don't >> have the time to write docs for each exception so it's best to stick >> to the wxWidgets documentation since it's free and it's right. > > That's okay, I'll add an explicit conversion. I just wasn't sure what > has changed and if this should be addressed in my code. > >> People complained about the error box. I plan to replace it with a >> text console (like wxLua -c) so that when running error message will >> stream to it. This will be something that in Lua you can enable or >> disable it, e.g. wxlua.ShowConsoleOnPrint(true/false) or something. > > I think this would be an inferior solution comparing with the error > box. For me as a developer, it's critical to know when something is > not working. Right now, if I made a mistake, I get a detailed error > messages in my face. With a text console, I'll need to keep it on and > monitor all the time. > > It's even worse for my users. If one of my bugs slips through and > something is not working (let's say I made a mistake in EVT_CLOSE > event handler), the window will fail to close without any visible > indication as to what's wrong (and also possibly leaving the app in > some inconsistent state without any indication either). And there is > nothing to report back to me. I can't ask my users to turn the console > on if something looks strange in their application. > >> I don't understand this. The logic to trigger this error is very >> simple, when wxLua starts it saves a pointer to the lua_State* in the >> Lua registry. When an event callback is created the given lua_State* >> is compared with the original lua_State* in the registry and if they >> don't match you must be in a coroutine which means that Lua will give >> you an error about running code in a "suspended or dead coroutine" so >> instead of that rather cryptic message given later I error out >> earlier. > > It's possible that it's from using two dlls, but I'll need to re-test this. > > Essentially, even with the current binaries I should be able to remove > socket calls and add explicit type conversion and use it without any > issues. What I'm concerned about it the crash I was getting: > >>> If I comment luasocket out, the app crashed somewhere in >>> wxlua_lua_shared-wx28mswu-2.8.12.dll: >> >> No message? > > Right, no message, just a windows crash report. I'll re-test shortly > as I now understand better what the different DLLS are for, but I > don't expect this to change. > >> I am working on using a proxydll along the lines of this : >> http://lua-users.org/wiki/LuaProxyDllFour > > What do we gain by using LuaProxyDll? I thought I could do "require > 'wx'" from a statically linked LuaFreeze even today? > > Paul. > > On Sat, Jun 30, 2012 at 9:32 AM, John Labenski <jlaben...@gmail.com> wrote: >> On Fri, Jun 29, 2012 at 2:34 AM, Paul K <paulclin...@yahoo.com> wrote: >>> Hi John, >>> >>> Thank you for making the binaries available! I gave the Unicode >>> binaries a try, but the results are a mixed bag. I can barely get them >>> running for my application, which allows me to confirm that UTF-8 >>> encoding is now working, but other encodings stopped working. For >>> example, if I set font encoding to wx.wxFONTENCODING_CP1251, I see no >>> difference (it looks like it's always "fixed" to utf-8). This may be a >>> feature though. If this is going to be the way it is, I'm fine with >>> it. >> >> I have never needed to change the wxFONTENCODING so I don't think it >> is necessary. I bet you were trying to change it to map upper ASCII >> chars appropriately to a font, a poor mans Unicode that probably works >> well for Latin languages with tildes and such, but that's about it. >> When you use Unicode you don't need to mess with all that since UTF8, >> for example, can describe any character. >> >> Note the comment about "Please note that we will only discuss 8-bit >> fonts here and not Unicode (see Unicode Support in wxWidgets)." >> http://docs.wxwidgets.org/trunk/overview_fontencoding.html >> >> Unfortunately you either work in Unicode or ANSI and hope that the >> upper ASCII chars map to the letters you need. I don't think you can >> ever have it both ways as the upper ASCII chars are not >> compatible/equivalent to Unicode chars in any format. >> >>> Also, I can't get the binaries to work correctly with my application. >>> The first issue is that the existing lua socket binaries fail to load: >>> >>> ...\bin\lua.EXE: error loading module 'socket.core' from file >>> 'bin/clibs/socket\core.dll': >>> The specified module could not be found. >>> >>> even though the module *is* there and loads fine using the old >>> binaries. This may be related to the fact that socket\core.dll seems >>> to be compiled against lua5.1.dll, which you didn't include in the >>> package (and my existing one didn't work as it's not for 5.1.5). >> >> You can't always expect that a lib compiled with one version of code >> to work with another. Ideally you would build wxLua and the socket lib >> together to ensure they both are using the same Lua library. In this >> case they are trying to use different lua51.dlls which is a real >> problem, they have to both use the same one. >> >> I am working on using a proxydll along the lines of this : >> http://lua-users.org/wiki/LuaProxyDllFour >> >> It works... but I get missing comctrl32.dll dialogs every once in a >> while which makes it very hard to debug what is happening. >> >> wxlua_lua_shared-wx28mswu-2.8.12.dll is lua51.dll, but named so that >> there can't be any confusion about what it is or what it belongs to. >> In Linux all the wxLua libs are named this way so they won't conflict >> with any system libs, you can use symbolic links to "rename" them to >> whatever you need them to be called. In Windows, people play fast and >> loose with versioning and naming and you get problems like you're >> having. For any sort of known stability all libs *must* be compiled >> and linked to the same versions of the other libs. Do you know how the >> socket binaries were compiled, what flags (/MT vs /MD), what Lua >> version, etc? If they match to how wxLua is compiled *and* the Lua >> they used is binary compatible, 5.1.4 should be with 5.1.5 it may >> work... >> >>> If I comment luasocket out, the app crashed somewhere in >>> wxlua_lua_shared-wx28mswu-2.8.12.dll: >> >> No message? >> >>> This is running on Windows Vista (32bit). I only deployed wx.dll and >>> wxlua_lua_shared-wx28mswu-2.8.12.dll (not sure what >>> wxlua_lua_shared-wx28mswu-2.9.4.dll was for as wx.dll didn't want to >>> work without 2.8.12.dll). I thought I could pick what version of >>> wxwidgets I want to use (2.8.12 vs. 2.9.4), but it didn't work that >>> way. >> >> wxlua_lua_shared-wx28mswu-2.9.4.dll was an oversight, it is exactly >> the same as wxlua_lua_shared-wx28mswu-2.8.12.dll. >> >>> I don't quite understand the difference between lua.exe and >>> lua_shared.exe. It seems like lua.exe doesn't need lua51.dll, but >>> lua_shared.exe runs without that dll also, as you don't seem to >>> include the dll. >> >> lua_shared.exe and wx.dll are linked to wxlua_lua_shared-wx28mswu-2.8.12.dll. >> >> lua.exe is a standalone executable. >> >>> Also, wxLua* binaries (Freeze, Edit, etc.) seem to be statically >>> compiled and the previous version had them dynamically compiled (which >>> would be my preference, although other people may prefer it >>> differently). >> >> I think static is the way to go and using the proxydll above should >> solve the lua51.dll problem (at least name problem) for people trying >> to use random precompiled libs with require(). >> >> -------------------- >> >> The bottom line is that the next release will be quite different, much >> simpler for deployment, and far more compatible when using other libs. >> >> Regards, >> John >> >> ------------------------------------------------------------------------------ >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and >> threat landscape has changed and how IT managers can respond. Discussions >> will include endpoint security, mobile security and the latest in malware >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> _______________________________________________ >> wxlua-users mailing list >> wxlua-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/wxlua-users ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ wxlua-users mailing list wxlua-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxlua-users
