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 <pau...@ya...> 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 <jla...@gm...> wrote: >> On Fri, Jun 29, 2012 at 2:34 AM, Paul K <pau...@ya...> 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 >> wxl...@li... >> https://lists.sourceforge.net/lists/listinfo/wxlua-users