wxlua-users — wxLua list for users and developers

Re: [wxlua-users] Preliminary wxLua Binaries for 2.8.12 for MSW

[Блажнов В. <vbl...@ya...>]

Sorry, it's my problem: I used wxLua.exe from obsolete version. Sample works well running with Unicode interpreter 2.8.12.

04.07.2012, 07:30, "John Labenski" <jla...@gm...>:
> On Tue, Jul 3, 2012 at 4:34 AM, Блажнов Валерий <vbl...@ya...> wrote:
>
>>  tree.wx.lua sample works with errors with 2.8.12 MSW Unicode build:
>>  C:\Program Files\Lua\5.1\lua.exe: ...s\wxLua\wxLua-2.8.12-MSW-Unicode\samples\tree.wx.lua:154: wxLua: Expect
>>  ed a 'number' for parameter 1, but got a 'string'.
>>  Function called: 'wxLuaTreeItemData(string)'
>>  01. wxLuaTreeItemData::wxLuaTreeItemData(number])
>>  stack traceback:
>>          [C]: in function 'wxLuaTreeItemData'
>>          ...s\wxLua\wxLua-2.8.12-MSW-Unicode\samples\tree.wx.lua:154: in function 'main'
>>          ...s\wxLua\wxLua-2.8.12-MSW-Unicode\samples\tree.wx.lua:193: in main chunk
>>          [C]: ?
>
> I don't get this error using the same binaries and neither should you.
> The wxLuaTreeItemData actually takes any type of data as an input
> parameter.
>
> I opened a DOS prompt, went to the wxLua/bin dir and ran
>
>>  lua.exe ..\samples\tree.wx.lua
>
> Can you explain a little how you are running this?
>
> 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

Re: [wxlua-users] Compilation error with the latest svn code (rev.102)

[John L. <jla...@gm...>]

On Wed, Jul 4, 2012 at 7:47 PM, Paul K <pau...@ya...> wrote:
> Hi John,
>
> I'm getting a compilation error on the latest wxlua revision (102) from svn:
>
> It can't find definitions for wxPopupWindow and
> wxPopupTransientWindow; commenting out defines in
> wxLua/modules/wxbind/setup/wxluasetup.h (wxPopupWindow and
> wxPopupTransientWindow) allows the compilation to complete without
> problems.
>
> This is on MacOS.

Thanks for reporting, what you did is fine if you don't use or need
the two controls. I'll commit a fix next week.

Regards,
    John

Re: [wxlua-users] Can't compiling monolithic lib on MacOS

[John L. <jla...@gm...>]

On Wed, Jul 4, 2012 at 7:44 PM, Paul K <pau...@ya...> wrote:
> Hi John,
>
> I'm having troubles compiling monolithic dylib on MacOS. I've read the

Try using cmake, I have not been able to test in OSX for some time and
won't be able to until next week. Hopefully there wasn't too much
breakage when I adjusted the MSW build.

http://wxlua.sourceforge.net/docs/install.html#C4.3

Regards,
     John

[wxlua-users] Compilation error with the latest svn code (rev.102)

[Paul K <pau...@ya...>]

Hi John,

I'm getting a compilation error on the latest wxlua revision (102) from svn:

/Users/paul/svn/wxlua/trunk/wxLua/bk-deps g++ -c -o
wxbindcore_dll_wxcore_bind.o -I./.pch/wxprec_wxbindcore_dll
-I../modules/wxbind/setup -I../modules -I./.. -I/usr/include/lua5.1
-DWXMAKINGDLL_WXBINDCORE -dynamic -fPIC -DPIC
-I/Users/paul/Downloads/wxMac-2.8.12/lib/wx/include/mac-unicode-release-2.8
-I/Users/paul/Downloads/wxMac-2.8.12/include
-I/Users/paul/Downloads/wxMac-2.8.12/contrib/include
-D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXMAC__  -arch i386
-DwxLUA_USEBINDING_WXGL=0 -DwxLUA_USEBINDING_WXMEDIA=0
-DwxLUA_USEBINDING_WXSTC=0 -O2 -fno-common
./wxbind/src/wxcore_bind.cpp
./wxbind/src/wxcore_bind.cpp: In function ‘int
wxLua_function_wxGetAccelFromString(lua_State*)’:
./wxbind/src/wxcore_bind.cpp:3456: warning: ‘wxGetAccelFromString’ is
deprecated (declared at
/Users/paul/Downloads/wxMac-2.8.12/include/wx/utils.h:577)
./wxbind/src/wxcore_bind.cpp:3456: warning: ‘wxGetAccelFromString’ is
deprecated (declared at
/Users/paul/Downloads/wxMac-2.8.12/include/wx/utils.h:577)
./wxbind/src/wxcore_bind.cpp: In function ‘wxLuaBindClass*
wxLuaGetClassList_wxcore(size_t&)’:
./wxbind/src/wxcore_bind.cpp:7130: error: ‘wxPopupTransientWindow’ has
not been declared
./wxbind/src/wxcore_bind.cpp:7134: error: ‘wxPopupWindow’ has not been declared
make[1]: *** [wxbindcore_dll_wxcore_bind.o] Error 1
make: *** [modules] Error 2

It can't find definitions for wxPopupWindow and
wxPopupTransientWindow; commenting out defines in
wxLua/modules/wxbind/setup/wxluasetup.h (wxPopupWindow and
wxPopupTransientWindow) allows the compilation to complete without
problems.

This is on MacOS.

Paul.

[wxlua-users] Can't compiling monolithic lib on MacOS

[Paul K <pau...@ya...>]

Hi John,

I'm having troubles compiling monolithic dylib on MacOS. I've read the
description here (http://wxlua.sourceforge.net/docs/install.html#C4)
about SHARED and MONOLITHIC options, but can't find what corresponds
to them in the new make configuration. I've tried different
combinations, but can't get one dylib for wx lib that I need. This is
using the latest configuration from svn and wxwidgets 2.8.12.

This is what I'm using:

CFLAGS="-arch i386" LDFLAGS="-arch i386" CPPFLAGS="-arch i386"
CXXFLAGS="-arch i386" ./configure --disable-debug --enable-shared
--enable-unicode --enable-monolithic-luamodule
--with-wxdir=/Users/paul/Downloads/wxMac-2.8.12

The closest options I see are --enable-shared and
--enable-monolithis-luamodule, but it still generates a bunch of
dylibs with *bind* names:

./lib/liblua5.1.0.0.0.dylib
./lib/liblua5.1.0.dylib
./lib/liblua5.1.dylib
./lib/libwxlua_macu_wxbindadv-2.8.0.0.7.dylib
./lib/libwxlua_macu_wxbindadv-2.8.0.dylib
./lib/libwxlua_macu_wxbindadv-2.8.dylib
./lib/libwxlua_macu_wxbindaui-2.8.0.0.7.dylib
./lib/libwxlua_macu_wxbindaui-2.8.0.dylib
./lib/libwxlua_macu_wxbindaui-2.8.dylib
./lib/libwxlua_macu_wxbindbase-2.8.0.0.7.dylib
./lib/libwxlua_macu_wxbindbase-2.8.0.dylib
./lib/libwxlua_macu_wxbindbase-2.8.dylib
./lib/libwxlua_macu_wxbindcore-2.8.0.0.7.dylib
./lib/libwxlua_macu_wxbindcore-2.8.0.dylib
./lib/libwxlua_macu_wxbindcore-2.8.dylib
./lib/libwxlua_macu_wxbindhtml-2.8.0.0.7.dylib
./lib/libwxlua_macu_wxbindhtml-2.8.0.dylib
./lib/libwxlua_macu_wxbindhtml-2.8.dylib
./lib/libwxlua_macu_wxbindnet-2.8.0.0.7.dylib
./lib/libwxlua_macu_wxbindnet-2.8.0.dylib
./lib/libwxlua_macu_wxbindnet-2.8.dylib
./lib/libwxlua_macu_wxbindrichtext-2.8.0.0.7.dylib
./lib/libwxlua_macu_wxbindrichtext-2.8.0.dylib
./lib/libwxlua_macu_wxbindrichtext-2.8.dylib
./lib/libwxlua_macu_wxbindxml-2.8.0.0.7.dylib
./lib/libwxlua_macu_wxbindxml-2.8.0.dylib
./lib/libwxlua_macu_wxbindxml-2.8.dylib
./lib/libwxlua_macu_wxbindxrc-2.8.0.0.7.dylib
./lib/libwxlua_macu_wxbindxrc-2.8.0.dylib
./lib/libwxlua_macu_wxbindxrc-2.8.dylib
./lib/libwxlua_macu_wxlua-2.8.0.0.7.dylib
./lib/libwxlua_macu_wxlua-2.8.0.dylib
./lib/libwxlua_macu_wxlua-2.8.dylib
./lib/libwxlua_macu_wxluadebug-2.8.0.0.7.dylib
./lib/libwxlua_macu_wxluadebug-2.8.0.dylib
./lib/libwxlua_macu_wxluadebug-2.8.dylib
./lib/libwxlua_macu_wxluasocket-2.8.0.0.7.dylib
./lib/libwxlua_macu_wxluasocket-2.8.0.dylib
./lib/libwxlua_macu_wxluasocket-2.8.dylib

wxwidgets were compiled with this config:

CFLAGS="-arch i386" LDFLAGS="-arch i386" CPPFLAGS="-arch i386"
CXXFLAGS="-arch i386" ./configure --enable-monolithic --disable-debug
--enable-shared --enable-unicode
--with-macosx-sdk=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.6.sdk
--with-macosx-version-min=10.6 --without-lib tiff

What do I need to specify to get one libwx.dylib file or something like that?

Paul.

Re: [wxlua-users] Preliminary wxLua Binaries for 2.8.12 for MSW

[John L. <jla...@gm...>]

On Sun, Jul 1, 2012 at 11:50 PM, Paul K <pau...@ya...> wrote:
>
>> How exactly are you using the coroutines? You're creating one to run a
>> Lua script and somehow debug it. Can the wxFrame live for longer than
>> the life of coroutine?
>
> No, wxFrame can't live for longer than the life of coroutine. It is
> indeed for ZeroBraneStudio, but indirectly; the IDE itself doesn't
> depend on this, but the debugging component (provided by MobDebug:
> https://github.com/pkulchenko/MobDebug) does.
>
> The logic in question is part of the controller() function and is a
> completely generic code:
>
>       local coro_debugee = coroutine.create(debugee)
>       debug.sethook(coro_debugee, debug_hook, "lcr")
>       local status, err = coroutine.resume(coro_debugee)
>
> It creates a coroutine for debugee (which is a function created as a
> result of loadstring/loadfile, for example, debugee =
> loadfile('minimal.wx.lua')), sets a debug hook on it and resumes it.
> All wxlua logic is encapsulated there, but with this fix the execution
> fails.

I see, this is a rather unique use case. I cannot think of any other
way to use use an event callback in a coroutine that might work
besides running the whole program in it as you're doing. I'm still
suspicious since the coroutine will be suspended when event callbacks
are called.

Can you confirm if there aren't any problems if you debug a program in
wxLua 2.8.10 with an OnPaint event handler and a wxMenu callback,
debug past where the callbacks are connected and the event loop is
running. Then cover and uncover the frame to run the OnPaint handler
and open the menu item. Does it work as expected and can you debug
into the callback function? The minimal.wx.lua sample has both of
these and the wxLua.exe debugger works as expected. How does your use
of coroutines compare?

Regards,
    John

Re: [wxlua-users] wxThread Status

[John L. <jla...@gm...>]

On Mon, Jul 2, 2012 at 8:15 AM, Anders Andersson <all...@gm...> wrote:
> (I hope this is how you replay to a message, sorry haven't been using any
> mailing lists lately)

I prefer replying inline with the previous comment so it reads better.

>  Yes, I have looked into the bindings and it seems to be that some other wx
> classes are missing, such as wxVListBox, wxHtmlListBox, wxServer, wxClient,
> wxDataViewCtrl + helper classes etc. Which I use all of them in my C++ app.

wxVListBox and wxHtmlListBox are straightforward to wrap. wxServer,
wxClient, and wxDataViewCtrl take a little more work since we have to
derive from them to allow Lua implementations of the virtual
functions. There is no reason wxLua doesn't have any of these other
than the lack of time it takes to do it.

> I have basically a wxWidgets C++ application and would like to embed a
> script language to allow users to create GUI in some kind of sand-boxed
> environment. Some of the application needs to be converted to wxLua. And it
> is there where wxThreads, wxVListBox, wxDataViewCtrl etc, are used (no
> bindings for them yet). The pros for wxLua is that the user writing the
> script does not have to think about pointers, memory etc. So to allow the
> user to use C++ code is just the opposite of what I'm trying to do.

Asking scripting users to write wxThreads is a lot to ask of them, but
maybe not depending on the level of experience you expect these users
to have.

> What do you think, Is it better to use wxPython instead? Although its more
> feature complete but it uses more memory, slower, new language, and is more
> difficult to embed.

wxPython is certainly more complete and the python libraries you can
add to it are impressive. wxLua as you mention is fully embeddable and
you can run multiple wxLuaStates at once. It really depends on your
needs. The bindings for wxLua are stable and protect from pointer
problems, but no attempt has been made (nor will it probably ever be
made) to do additional value and range checking on all parameters to
wxWidgets functions, so you can still crash the program. wxWidgets 2.9
in release mode has the assert checks enabled so you do get some
protection with the wxCHECK_MSG dialogs. I do not know if wxPython
adds extra checks, but I don't think it does since that would take an
incredible amount of effort.

> And if I continue with wxLua do you think it will be a
> big task to try to create bindings for the rest of the wxWidgets library.

Not really, you can see the bindings in the bindings/wxwidgets
directory and basically they're stripped down headers. If no virtual
functions have to be overridden a class can be implemented in an hour.
The hardest part is making sure you really got it cross-platform and
working in 2.8 and 2.9.

http://wxlua.sourceforge.net/docs/binding.html

Regards,
    John

Re: [wxlua-users] Preliminary wxLua Binaries for 2.8.12 for MSW

[John L. <jla...@gm...>]

On Tue, Jul 3, 2012 at 4:34 AM, Блажнов Валерий <vbl...@ya...> wrote:
> tree.wx.lua sample works with errors with 2.8.12 MSW Unicode build:
> C:\Program Files\Lua\5.1\lua.exe: ...s\wxLua\wxLua-2.8.12-MSW-Unicode\samples\tree.wx.lua:154: wxLua: Expect
> ed a 'number' for parameter 1, but got a 'string'.
> Function called: 'wxLuaTreeItemData(string)'
> 01. wxLuaTreeItemData::wxLuaTreeItemData(number])
> stack traceback:
>         [C]: in function 'wxLuaTreeItemData'
>         ...s\wxLua\wxLua-2.8.12-MSW-Unicode\samples\tree.wx.lua:154: in function 'main'
>         ...s\wxLua\wxLua-2.8.12-MSW-Unicode\samples\tree.wx.lua:193: in main chunk
>         [C]: ?

I don't get this error using the same binaries and neither should you.
The wxLuaTreeItemData actually takes any type of data as an input
parameter.

I opened a DOS prompt, went to the wxLua/bin dir and ran
> lua.exe ..\samples\tree.wx.lua

Can you explain a little how you are running this?

Regards,
    John

Re: [wxlua-users] compiling in release mode

[John L. <jla...@gm...>]

On Tue, Jul 3, 2012 at 8:39 AM, Andre Arpin <ar...@ki...> wrote:
>
> macro: WX_SET_LIBRARIES

Please help me by briefly noting where things like this are so I don't
have to search for them.

FindwxWidgets.cmake is CMake's function to find wxWidgets and is very
strangely written. I made a copy of it to fix a small bug ot not being
able to select a unicode build after it had found an ANSI build, but
there may be more issues.

> test for debug file even if only release mode is being compiled

Please uncheck wxWidgets_USE_REL_AND_DBG in the CMake gui and try
again. I think that's the intention of that variable.

I would like to avoid having to completely rewrite that file, but we'll see...

Regards,
     John

[wxlua-users] compiling in release mode

[Andre A. <ar...@ki...>]

macro: WX_SET_LIBRARIES

test for debug file even if only release mode is being compiled

So you must compile the debug version even if you only want the release version.

This probably explain my problem.

Andre

Re: [wxlua-users] Preliminary wxLua Binaries for 2.8.12 for MSW

[Блажнов В. <vbl...@ya...>]

tree.wx.lua sample works with errors with 2.8.12 MSW Unicode build:
C:\Program Files\Lua\5.1\lua.exe: ...s\wxLua\wxLua-2.8.12-MSW-Unicode\samples\tree.wx.lua:154: wxLua: Expect
ed a 'number' for parameter 1, but got a 'string'.
Function called: 'wxLuaTreeItemData(string)'
01. wxLuaTreeItemData::wxLuaTreeItemData(number])
stack traceback:
        [C]: in function 'wxLuaTreeItemData'
        ...s\wxLua\wxLua-2.8.12-MSW-Unicode\samples\tree.wx.lua:154: in function 'main'
        ...s\wxLua\wxLua-2.8.12-MSW-Unicode\samples\tree.wx.lua:193: in main chunk
        [C]: ?


29.06.2012, 09:29, "John Labenski" <jla...@gm...>:
> These are not well tested and things are not as complete as I would
> like, but better sooner than never.
>
> https://sourceforge.net/projects/wxlua/files/wxlua/2.8.12.0/
>
> Enjoy!
>
> -John Labenski
>
> ------------------------------------------------------------------------------
> 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

Re: [wxlua-users] Current version does not work in release mode

[Andre A. <ar...@ki...>]

> Can you completely delete the old build dir and try again. The
> binaries on SourceForge were built using MSVC2008 and work fine. Do
> you have mismatched versions of wxWidgets headers and libs.

Try to anwer using Chrome does not seem to work.

Works fine now that I reset the world.

Thank you.

Andre

Re: [wxlua-users] Current version does not work in release mode

[Andre A. <ar...@ki...>]

> Can you completely delete the old build dir and try again. The
> binaries on SourceForge were built using MSVC2008 and work fine. Do
> you have mismatched versions of wxWidgets headers and libs.


Yes you are right.
I keep a separate clean area but it got corrupted.
Should have reset it first. Lazy I guess.

Many improvements in this version particularly wx.dll works.
Replace a number of exe by lua file this is great.

Thank for all the work and for your continue help.

Andre

Re: [wxlua-users] wxThread Status

[Anders A. <all...@gm...>]

(I hope this is how you replay to a message, sorry haven't been using any
mailing lists lately)

On 2 July 2012 05:35, John Labenski <jla...@gm...> wrote:

> On Fri, Jun 29, 2012 at 8:39 AM, Anders Andersson <all...@gm...>
> wrote:
>
> Currently the bindings are not written, see wxLua/bindings/wxwidgets
> for the others.
>
> I'm not sure offhand, writing the bindings is easy, but in this case a
> wxLuaThread class would have to be written to call your Lua function
> when Entry() is called, OnExit() called, and expose Exit().
>
> The question is whether Lua can run them, I don't think the Lua stack
> can do it out of the box and lua_lock() and lua_unlock() would have to
> be written.
>
> http://lua-users.org/wiki/ThreadsTutorial
>
> Perhaps coroutines would work for you, the only limitation on them
> with wxLua is that you cannot create an event callback in a coroutine,
> but neither can you in a wxThread so it shouldn't matter. The downside
> is that in a coroutine you have to manage timeslicing.
>
> It sounds you have a C++ app? If so, one possibility is to keep the
> threads in C++ and use wxLua for other parts using wxPostEvent for
> communication.
>
> Regards,
>      John
>


 Yes, I have looked into the bindings and it seems to be that some other wx
classes are missing, such as wxVListBox, wxHtmlListBox, wxServer, wxClient,
wxDataViewCtrl + helper classes etc. Which I use all of them in my C++ app.
that's sad I was hoping for a more feature complete wxlua. I would like to
help implement them but I'm not that comfortable with the lua embedding api
yet. To be totally honest I don't even know the Lua language fully yet.

I have basically a wxWidgets C++ application and would like to embed a
script language to allow users to create GUI in some kind of sand-boxed
environment. Some of the application needs to be converted to wxLua. And it
is there where wxThreads, wxVListBox, wxDataViewCtrl etc, are used (no
bindings for them yet). The pros for wxLua is that the user writing the
script does not have to think about pointers, memory etc. So to allow the
user to use C++ code is just the opposite of what I'm trying to do.

What do you think, Is it better to use wxPython instead? Although its more
feature complete but it uses more memory, slower, new language, and is more
difficult to embed. And if I continue with wxLua do you think it will be a
big task to try to create bindings for the rest of the wxWidgets library.

Thanks

Re: [wxlua-users] Preliminary wxLua Binaries for 2.8.12 for MSW

[Paul K <pau...@ya...>]

Hi John,

Just to elaborate a bit on use cases. I currently use it for
non-invasive debugging and have also been working on a profiler that
is using the same mechanism. In general, any application that needs to
set a debug hook without modifying the code of the script, will
trigger this check and run into the same problem.

Paul.

On Sun, Jul 1, 2012 at 8:50 PM, Paul K <pau...@ya...> wrote:
> Hi John,
>
>> Please read this thread to understand a little more about why it was blocked.
>> http://www.mail-archive.com/wxl...@li.../msg02296.html
>
> I read the thread, but don't see anything that warranted that
> particular change. You provided workable solutions to the problem that
> the original poster had and in the end the problem was solved:
>
> "I've solved the problem by creating a small module that allows to
> execute, from a coroutine, a function in the main thread. It helps to
> keep the main thread code independant from the coroutine code. My
> application works fine now, thanks for the help."
>
>> How exactly are you using the coroutines? You're creating one to run a
>> Lua script and somehow debug it. Can the wxFrame live for longer than
>> the life of coroutine?
>>
>> This is for ZeroBraneStudio? How do I run it and where is the code?
>> There seems to be a lot of binary files there. Where is the code that
>> uses the coroutines?
>> https://github.com/pkulchenko/ZeroBraneStudio
>
> You don't need any of those binary files as long as you can run "lua
> src/main.lua zbstudio" command. in fact, just use your binaries with
> luasocket and you should be able to run it (just clear the bin/ folder
> and put your files and lua.exe there).
>
> No, wxFrame can't live for longer than the life of coroutine. It is
> indeed for ZeroBraneStudio, but indirectly; the IDE itself doesn't
> depend on this, but the debugging component (provided by MobDebug:
> https://github.com/pkulchenko/MobDebug) does.
>
> The logic in question is part of the controller() function and is a
> completely generic code:
>
>       local coro_debugee = coroutine.create(debugee)
>       debug.sethook(coro_debugee, debug_hook, "lcr")
>       local status, err = coroutine.resume(coro_debugee)
>
> It creates a coroutine for debugee (which is a function created as a
> result of loadstring/loadfile, for example, debugee =
> loadfile('minimal.wx.lua')), sets a debug hook on it and resumes it.
> All wxlua logic is encapsulated there, but with this fix the execution
> fails.
>
>> The issue is that doing this is dangerous and sometimes you have to
>> stop people from trying to shoot themselves in the foot.
>
> It may be a valid reason in some cases, but I think in this case it
> broke a completely legitimate use of this functionality. In fact, in
> the original case the user was getting a reasonably informative error.
>
>>> been working fine before in many different situations (I have never
>>> had a single problem with it) and this is a deal breaker for me. As
>>
>> Deal?
>
> In the sense that I'd like to upgrade to the new version, but with the
> debugger being a critical component and not working, I won't be able
> to.
>
> Paul.
>
> On Sun, Jul 1, 2012 at 7:52 PM, John Labenski <jla...@gm...> wrote:
>> On Sat, Jun 30, 2012 at 9:00 PM, Paul K <pau...@ya...> wrote:
>>>
>>> Couple of things that are not working. Shortcuts in the full screen
>>> mode I reported earlier are not working. Either something has changed
>>> or I did not test them correctly with the previous version.
>>
>> I would test the old version to see if the behavior has changed, in
>> any case it would be something that wxWidgets has changed. It may just
>> be that when the menu is removed the accelerators are removed too. You
>> can supplement or replace them using a wxAcceleratorTable.
>>
>>> The other thing that is not working is the debugging for wxwidgets
>>> apps I have, which triggers this "wxLua: Creating a callback function
>>> in a coroutine is not allowed since it will only be called when the
>>> thread is either suspended or dead." message. This seems to be caused
>>> by the fact that I have two main loop in the application. Your earlier
>>> explanation sheds some light on this:
>>
>> As explained in the code you've seen, there are many things wrong with
>> allowing it, the least of which is that you definitely cannot call
>> coroutine.resume() from the event handler in the coroutine.
>> Search for "cannot resume non-suspended coroutine" here:
>> http://wxlua.svn.sourceforge.net/viewvc/wxlua/trunk/wxLua/modules/lua/src/ldo.c?revision=100&view=markup
>>
>> The worst is that wxLua can't tell when a coroutine is collected so
>> wxLua will crash if an event handler is called into that coroutine.
>>
>> Please read this thread to understand a little more about why it was blocked.
>> http://www.mail-archive.com/wxl...@li.../msg02296.html
>>
>> The issue is that doing this is dangerous and sometimes you have to
>> stop people from trying to shoot themselves in the foot.
>>
>> How exactly are you using the coroutines? You're creating one to run a
>> Lua script and somehow debug it. Can the wxFrame live for longer than
>> the life of coroutine?
>>
>> This is for ZeroBraneStudio? How do I run it and where is the code?
>> There seems to be a lot of binary files there. Where is the code that
>> uses the coroutines?
>> https://github.com/pkulchenko/ZeroBraneStudio
>>
>>> It seems like the check is too aggressive, as this functionality has
>>> been working fine before in many different situations (I have never
>>> had a single problem with it) and this is a deal breaker for me. As
>>
>> Deal?
>>
>>>> ps. Note that I don't think you ever got error messages from wx.dll...
>>>> When lua.exe is run it does a pcall() on the input file and so it gets
>>>> the error messages, I don't believe it's even possible for wxLua to
>>>
>>> This part seems to be working as I expect it to work (or even better).
>>
>> Ahh... Ok, you get the error messages from the coroutine and not the
>> main lua_State, this is right.
>>
>> 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

Re: [wxlua-users] Preliminary wxLua Binaries for 2.8.12 for MSW

[Paul K <pau...@ya...>]

Hi John,

> Please read this thread to understand a little more about why it was blocked.
> http://www.mail-archive.com/wxl...@li.../msg02296.html

I read the thread, but don't see anything that warranted that
particular change. You provided workable solutions to the problem that
the original poster had and in the end the problem was solved:

"I've solved the problem by creating a small module that allows to
execute, from a coroutine, a function in the main thread. It helps to
keep the main thread code independant from the coroutine code. My
application works fine now, thanks for the help."

> How exactly are you using the coroutines? You're creating one to run a
> Lua script and somehow debug it. Can the wxFrame live for longer than
> the life of coroutine?
>
> This is for ZeroBraneStudio? How do I run it and where is the code?
> There seems to be a lot of binary files there. Where is the code that
> uses the coroutines?
> https://github.com/pkulchenko/ZeroBraneStudio

You don't need any of those binary files as long as you can run "lua
src/main.lua zbstudio" command. in fact, just use your binaries with
luasocket and you should be able to run it (just clear the bin/ folder
and put your files and lua.exe there).

No, wxFrame can't live for longer than the life of coroutine. It is
indeed for ZeroBraneStudio, but indirectly; the IDE itself doesn't
depend on this, but the debugging component (provided by MobDebug:
https://github.com/pkulchenko/MobDebug) does.

The logic in question is part of the controller() function and is a
completely generic code:

      local coro_debugee = coroutine.create(debugee)
      debug.sethook(coro_debugee, debug_hook, "lcr")
      local status, err = coroutine.resume(coro_debugee)

It creates a coroutine for debugee (which is a function created as a
result of loadstring/loadfile, for example, debugee =
loadfile('minimal.wx.lua')), sets a debug hook on it and resumes it.
All wxlua logic is encapsulated there, but with this fix the execution
fails.

> The issue is that doing this is dangerous and sometimes you have to
> stop people from trying to shoot themselves in the foot.

It may be a valid reason in some cases, but I think in this case it
broke a completely legitimate use of this functionality. In fact, in
the original case the user was getting a reasonably informative error.

>> been working fine before in many different situations (I have never
>> had a single problem with it) and this is a deal breaker for me. As
>
> Deal?

In the sense that I'd like to upgrade to the new version, but with the
debugger being a critical component and not working, I won't be able
to.

Paul.

On Sun, Jul 1, 2012 at 7:52 PM, John Labenski <jla...@gm...> wrote:
> On Sat, Jun 30, 2012 at 9:00 PM, Paul K <pau...@ya...> wrote:
>>
>> Couple of things that are not working. Shortcuts in the full screen
>> mode I reported earlier are not working. Either something has changed
>> or I did not test them correctly with the previous version.
>
> I would test the old version to see if the behavior has changed, in
> any case it would be something that wxWidgets has changed. It may just
> be that when the menu is removed the accelerators are removed too. You
> can supplement or replace them using a wxAcceleratorTable.
>
>> The other thing that is not working is the debugging for wxwidgets
>> apps I have, which triggers this "wxLua: Creating a callback function
>> in a coroutine is not allowed since it will only be called when the
>> thread is either suspended or dead." message. This seems to be caused
>> by the fact that I have two main loop in the application. Your earlier
>> explanation sheds some light on this:
>
> As explained in the code you've seen, there are many things wrong with
> allowing it, the least of which is that you definitely cannot call
> coroutine.resume() from the event handler in the coroutine.
> Search for "cannot resume non-suspended coroutine" here:
> http://wxlua.svn.sourceforge.net/viewvc/wxlua/trunk/wxLua/modules/lua/src/ldo.c?revision=100&view=markup
>
> The worst is that wxLua can't tell when a coroutine is collected so
> wxLua will crash if an event handler is called into that coroutine.
>
> Please read this thread to understand a little more about why it was blocked.
> http://www.mail-archive.com/wxl...@li.../msg02296.html
>
> The issue is that doing this is dangerous and sometimes you have to
> stop people from trying to shoot themselves in the foot.
>
> How exactly are you using the coroutines? You're creating one to run a
> Lua script and somehow debug it. Can the wxFrame live for longer than
> the life of coroutine?
>
> This is for ZeroBraneStudio? How do I run it and where is the code?
> There seems to be a lot of binary files there. Where is the code that
> uses the coroutines?
> https://github.com/pkulchenko/ZeroBraneStudio
>
>> It seems like the check is too aggressive, as this functionality has
>> been working fine before in many different situations (I have never
>> had a single problem with it) and this is a deal breaker for me. As
>
> Deal?
>
>>> ps. Note that I don't think you ever got error messages from wx.dll...
>>> When lua.exe is run it does a pcall() on the input file and so it gets
>>> the error messages, I don't believe it's even possible for wxLua to
>>
>> This part seems to be working as I expect it to work (or even better).
>
> Ahh... Ok, you get the error messages from the coroutine and not the
> main lua_State, this is right.
>
> 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

Re: [wxlua-users] wxThread Status

[John L. <jla...@gm...>]

On Fri, Jun 29, 2012 at 8:39 AM, Anders Andersson <all...@gm...> wrote:
>
> Since I use a lot of wxThreads in my application, I wonder what the status
> is of implementing wxThreads in wxLua? The last post I found about this was
> from 2010.

Currently the bindings are not written, see wxLua/bindings/wxwidgets
for the others.

> I know there is "coroutine" but again it's very slow and not like the real
> thing. I wonder what the problem is with implementing wxThreads? (im not
> familiar with wxLua code). I only use wxTHREAD_DETACHED, is it not just to
> write an interface for wxThread and let wxWidgets manage the rest?

I'm not sure offhand, writing the bindings is easy, but in this case a
wxLuaThread class would have to be written to call your Lua function
when Entry() is called, OnExit() called, and expose Exit().

The question is whether Lua can run them, I don't think the Lua stack
can do it out of the box and lua_lock() and lua_unlock() would have to
be written.

http://lua-users.org/wiki/ThreadsTutorial

Perhaps coroutines would work for you, the only limitation on them
with wxLua is that you cannot create an event callback in a coroutine,
but neither can you in a wxThread so it shouldn't matter. The downside
is that in a coroutine you have to manage timeslicing.

It sounds you have a C++ app? If so, one possibility is to keep the
threads in C++ and use wxLua for other parts using wxPostEvent for
communication.

Regards,
     John

Re: [wxlua-users] wxPopupWindow patch

[John L. <jla...@gm...>]

On Thu, Jun 28, 2012 at 9:38 AM, Qito Nomnom <qit...@gm...> wrote:
> Hi everybody.
>
> I found out that there is no bindings for wxPopupWindow and
> wxPopupTransientWindow classes. I am using popup windows in my project, so i
> wrote bindings, they are in attachment

Thank you very much, applied to SVN.

Regards,
    John

Re: [wxlua-users] Current version does not work in release mode

[John L. <jla...@gm...>]

On Sun, Jul 1, 2012 at 10:12 PM, Andre Arpin <ar...@ki...> wrote:
> window, using
>
> cmake  -G "Visual Studio 9 2008" -DwxWidgets_ROOT_DIR:STRING=E:/wxWidgets/ -
> DwxWidgets_LIB_DIR:STRING=E:/wxWidgets/lib/vc_lib  E:/wxWidgets/wxLua
>
> to generate the control files
>
> the programs crash right out of the top
> wxlua, wxStEdit
>
> debug is fine

Can you completely delete the old build dir and try again. The
binaries on SourceForge were built using MSVC2008 and work fine. Do
you have mismatched versions of wxWidgets headers and libs.

Regards,
    John

Re: [wxlua-users] Preliminary wxLua Binaries for 2.8.12 for MSW

[John L. <jla...@gm...>]

On Sat, Jun 30, 2012 at 9:00 PM, Paul K <pau...@ya...> wrote:
>
> Couple of things that are not working. Shortcuts in the full screen
> mode I reported earlier are not working. Either something has changed
> or I did not test them correctly with the previous version.

I would test the old version to see if the behavior has changed, in
any case it would be something that wxWidgets has changed. It may just
be that when the menu is removed the accelerators are removed too. You
can supplement or replace them using a wxAcceleratorTable.

> The other thing that is not working is the debugging for wxwidgets
> apps I have, which triggers this "wxLua: Creating a callback function
> in a coroutine is not allowed since it will only be called when the
> thread is either suspended or dead." message. This seems to be caused
> by the fact that I have two main loop in the application. Your earlier
> explanation sheds some light on this:

As explained in the code you've seen, there are many things wrong with
allowing it, the least of which is that you definitely cannot call
coroutine.resume() from the event handler in the coroutine.
Search for "cannot resume non-suspended coroutine" here:
http://wxlua.svn.sourceforge.net/viewvc/wxlua/trunk/wxLua/modules/lua/src/ldo.c?revision=100&view=markup

The worst is that wxLua can't tell when a coroutine is collected so
wxLua will crash if an event handler is called into that coroutine.

Please read this thread to understand a little more about why it was blocked.
http://www.mail-archive.com/wxl...@li.../msg02296.html

The issue is that doing this is dangerous and sometimes you have to
stop people from trying to shoot themselves in the foot.

How exactly are you using the coroutines? You're creating one to run a
Lua script and somehow debug it. Can the wxFrame live for longer than
the life of coroutine?

This is for ZeroBraneStudio? How do I run it and where is the code?
There seems to be a lot of binary files there. Where is the code that
uses the coroutines?
https://github.com/pkulchenko/ZeroBraneStudio

> It seems like the check is too aggressive, as this functionality has
> been working fine before in many different situations (I have never
> had a single problem with it) and this is a deal breaker for me. As

Deal?

>> ps. Note that I don't think you ever got error messages from wx.dll...
>> When lua.exe is run it does a pcall() on the input file and so it gets
>> the error messages, I don't believe it's even possible for wxLua to
>
> This part seems to be working as I expect it to work (or even better).

Ahh... Ok, you get the error messages from the coroutine and not the
main lua_State, this is right.

Regards,
    John

[wxlua-users] Current version does not work in release mode

[Andre A. <ar...@ki...>]

window, using 

cmake  -G "Visual Studio 9 2008" -DwxWidgets_ROOT_DIR:STRING=E:/wxWidgets/ -
DwxWidgets_LIB_DIR:STRING=E:/wxWidgets/lib/vc_lib  E:/wxWidgets/wxLua

to generate the control files

the programs crash right out of the top
wxlua, wxStEdit

debug is fine

Andre

PS: No modification in the programs

Re: [wxlua-users] Preliminary wxLua Binaries for 2.8.12 for MSW

[Paul K <pau...@ya...>]

Hi John,

On that coroutine check; it seems like it is the result of this
commit, which specifically added this functionality:
http://wxlua.cvs.sourceforge.net/viewvc/wxlua/wxLua/modules/wxlua/src/wxlcallb.cpp?r1=1.62&r2=1.63

I cannot speak to the reasoning behind this (I read the description,
but don't have the background), but I can say that I've extensively
used the previous version in various situations involving co-routines
(including connecting event handlers from coroutines, which is part of
my debugger logic) and have never had problems with the application
because of that.

My suggestion is to revert this change.

Paul.

On Sat, Jun 30, 2012 at 6:00 PM, Paul K <pau...@ya...> wrote:
> Hi John,
>
>> Download 2.8.12.1 and try it. I have tested with
>> luasocket-2.0.2-lua-5.1.2-Win32-vc8.zip downloaded from Lua binaries
>> and it works.
>
> This is huge progress; very close to where I'd like to be. I got the
> application working with these binaries (including luasocket) and
> almost all the functions I tested are working correctly. The UTF
> characters are also displayed and copied correctly.
>
> Couple of things that are not working. Shortcuts in the full screen
> mode I reported earlier are not working. Either something has changed
> or I did not test them correctly with the previous version.
>
> The other thing that is not working is the debugging for wxwidgets
> apps I have, which triggers this "wxLua: Creating a callback function
> in a coroutine is not allowed since it will only be called when the
> thread is either suspended or dead." message. This seems to be caused
> by the fact that I have two main loop in the application. Your earlier
> explanation sheds some light on 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 seems like the check is too aggressive, as this functionality has
> been working fine before in many different situations (I have never
> had a single problem with it) and this is a deal breaker for me. As
> far as I can tell, any debugger that executes the main script in a
> separate co-routine (as mine does) will get this error.
>
> You can check it with this simple script:
>
> local func,err = loadfile('minimal.wx.lua')
> if err then error(err) end
> local ok, err = coroutine.resume(coroutine.create(func))
> if err then error(err) end
>
> If you run this, you will get "minicoro.lua:4: minimal.wx.lua:49:
> wxLua: Creating a callback function in a coroutine is not allowed
> since it will only be called when the thread is either suspended or
> dead.", which should not really happen.
>
>> ps. Note that I don't think you ever got error messages from wx.dll...
>> When lua.exe is run it does a pcall() on the input file and so it gets
>> the error messages, I don't believe it's even possible for wxLua to
>> get them. I think what you got are print() statements? Though, it has
>> been a long time since 2.8.10 and I have not retested it. I have
>> reinstated the error handler, but it's never called, but it's there
>> and will pop up a dialog if it ever gets called. Run your program from
>> a DOS prompt and the print and error messages will be printed to the
>> console.
>
> This part seems to be working as I expect it to work (or even better).
> I do get a window with an error AND the same error reported to the
> console, which is good. I won't attach the screenshot, but you can see
> the same message I'm talking about if you take "minimal.wx.lua" sample
> and change wx.wxMessageBox to wx.wxMessageBox1 (anything that causes
> run-time error will do). I get a messageBox with "wxLua Runtime Error"
> title and this error message (also reported to stdout):
>
> wxLua Runtime Error:
> Lua: Error while running chunk
> minimal.wx.lua:79: attempt to call field 'wxMessageBox1' (a nil value)
> stack traceback:
>        minimal.wx.lua:79: in function <minimal.wx.lua:78>
>        [C]: in function 'MainLoop'
>        minimal.wx.lua:96: in main chunk
>        [C]: ?
>
> So, my main issue is that check for coroutine that breaks my debugging
> and some other functionality. Thank you!
>
> Paul.
>
> On Sat, Jun 30, 2012 at 1:48 PM, John Labenski <jla...@gm...> wrote:
>> Ok... lets start fresh and not try to debug the old stuff.
>>
>> Download 2.8.12.1 and try it. I have tested with
>> luasocket-2.0.2-lua-5.1.2-Win32-vc8.zip downloaded from Lua binaries
>> and it works.
>>
>> This is how I did it, put luasocket's bin/ mime/ socket/ dirs as
>> subdirs of the wxLua/bin dir (or anywhere, but then adjust
>> LUA_PATH...) then you can run :
>>
>> lua myapp.lua
>> wxLua myapp.lua
>> wxLuaFreeze myapp.lua
>> wxLuaEdit myapp.lua
>>
>> where myapp.lua has
>>
>> ------
>> require("socket")
>> print("Is socket here ? ", socket)
>>
>> require("wx")
>> print(print, print_lua)
>>
>> f = wx.wxFrame(wx.NULL, -1, "Hello")
>> f:Show()
>> wx.wxGetApp():MainLoop()
>> ------
>>
>> Success!
>>
>> Please read here to understand what lua51.dll and lua5.1.dll are all about:
>>
>> http://wxlua.svn.sourceforge.net/viewvc/wxlua/trunk/wxLua/modules/luaproxydll/proxydll.c?revision=100&view=markup
>>
>> DO NOT COPY someone else's lua51.dll into the wxLua bin dir, it will never work.
>>
>> ps. Note that I don't think you ever got error messages from wx.dll...
>> When lua.exe is run it does a pcall() on the input file and so it gets
>> the error messages, I don't believe it's even possible for wxLua to
>> get them. I think what you got are print() statements? Though, it has
>> been a long time since 2.8.10 and I have not retested it. I have
>> reinstated the error handler, but it's never called, but it's there
>> and will pop up a dialog if it ever gets called. Run your program from
>> a DOS prompt and the print and error messages will be printed to the
>> console.
>>
>> 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

Re: [wxlua-users] Preliminary wxLua Binaries for 2.8.12 for MSW

[Paul K <pau...@ya...>]

Hi John,

> Download 2.8.12.1 and try it. I have tested with
> luasocket-2.0.2-lua-5.1.2-Win32-vc8.zip downloaded from Lua binaries
> and it works.

This is huge progress; very close to where I'd like to be. I got the
application working with these binaries (including luasocket) and
almost all the functions I tested are working correctly. The UTF
characters are also displayed and copied correctly.

Couple of things that are not working. Shortcuts in the full screen
mode I reported earlier are not working. Either something has changed
or I did not test them correctly with the previous version.

The other thing that is not working is the debugging for wxwidgets
apps I have, which triggers this "wxLua: Creating a callback function
in a coroutine is not allowed since it will only be called when the
thread is either suspended or dead." message. This seems to be caused
by the fact that I have two main loop in the application. Your earlier
explanation sheds some light on 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 seems like the check is too aggressive, as this functionality has
been working fine before in many different situations (I have never
had a single problem with it) and this is a deal breaker for me. As
far as I can tell, any debugger that executes the main script in a
separate co-routine (as mine does) will get this error.

You can check it with this simple script:

local func,err = loadfile('minimal.wx.lua')
if err then error(err) end
local ok, err = coroutine.resume(coroutine.create(func))
if err then error(err) end

If you run this, you will get "minicoro.lua:4: minimal.wx.lua:49:
wxLua: Creating a callback function in a coroutine is not allowed
since it will only be called when the thread is either suspended or
dead.", which should not really happen.

> ps. Note that I don't think you ever got error messages from wx.dll...
> When lua.exe is run it does a pcall() on the input file and so it gets
> the error messages, I don't believe it's even possible for wxLua to
> get them. I think what you got are print() statements? Though, it has
> been a long time since 2.8.10 and I have not retested it. I have
> reinstated the error handler, but it's never called, but it's there
> and will pop up a dialog if it ever gets called. Run your program from
> a DOS prompt and the print and error messages will be printed to the
> console.

This part seems to be working as I expect it to work (or even better).
I do get a window with an error AND the same error reported to the
console, which is good. I won't attach the screenshot, but you can see
the same message I'm talking about if you take "minimal.wx.lua" sample
and change wx.wxMessageBox to wx.wxMessageBox1 (anything that causes
run-time error will do). I get a messageBox with "wxLua Runtime Error"
title and this error message (also reported to stdout):

wxLua Runtime Error:
Lua: Error while running chunk
minimal.wx.lua:79: attempt to call field 'wxMessageBox1' (a nil value)
stack traceback:
	minimal.wx.lua:79: in function <minimal.wx.lua:78>
	[C]: in function 'MainLoop'
	minimal.wx.lua:96: in main chunk
	[C]: ?

So, my main issue is that check for coroutine that breaks my debugging
and some other functionality. Thank you!

Paul.

On Sat, Jun 30, 2012 at 1:48 PM, John Labenski <jla...@gm...> wrote:
> Ok... lets start fresh and not try to debug the old stuff.
>
> Download 2.8.12.1 and try it. I have tested with
> luasocket-2.0.2-lua-5.1.2-Win32-vc8.zip downloaded from Lua binaries
> and it works.
>
> This is how I did it, put luasocket's bin/ mime/ socket/ dirs as
> subdirs of the wxLua/bin dir (or anywhere, but then adjust
> LUA_PATH...) then you can run :
>
> lua myapp.lua
> wxLua myapp.lua
> wxLuaFreeze myapp.lua
> wxLuaEdit myapp.lua
>
> where myapp.lua has
>
> ------
> require("socket")
> print("Is socket here ? ", socket)
>
> require("wx")
> print(print, print_lua)
>
> f = wx.wxFrame(wx.NULL, -1, "Hello")
> f:Show()
> wx.wxGetApp():MainLoop()
> ------
>
> Success!
>
> Please read here to understand what lua51.dll and lua5.1.dll are all about:
>
> http://wxlua.svn.sourceforge.net/viewvc/wxlua/trunk/wxLua/modules/luaproxydll/proxydll.c?revision=100&view=markup
>
> DO NOT COPY someone else's lua51.dll into the wxLua bin dir, it will never work.
>
> ps. Note that I don't think you ever got error messages from wx.dll...
> When lua.exe is run it does a pcall() on the input file and so it gets
> the error messages, I don't believe it's even possible for wxLua to
> get them. I think what you got are print() statements? Though, it has
> been a long time since 2.8.10 and I have not retested it. I have
> reinstated the error handler, but it's never called, but it's there
> and will pop up a dialog if it ever gets called. Run your program from
> a DOS prompt and the print and error messages will be printed to the
> console.
>
> 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

Re: [wxlua-users] Preliminary wxLua Binaries for 2.8.12 for MSW

[John L. <jla...@gm...>]

Ok... lets start fresh and not try to debug the old stuff.

Download 2.8.12.1 and try it. I have tested with
luasocket-2.0.2-lua-5.1.2-Win32-vc8.zip downloaded from Lua binaries
and it works.

This is how I did it, put luasocket's bin/ mime/ socket/ dirs as
subdirs of the wxLua/bin dir (or anywhere, but then adjust
LUA_PATH...) then you can run :

lua myapp.lua
wxLua myapp.lua
wxLuaFreeze myapp.lua
wxLuaEdit myapp.lua

where myapp.lua has

------
require("socket")
print("Is socket here ? ", socket)

require("wx")
print(print, print_lua)

f = wx.wxFrame(wx.NULL, -1, "Hello")
f:Show()
wx.wxGetApp():MainLoop()
------

Success!

Please read here to understand what lua51.dll and lua5.1.dll are all about:

http://wxlua.svn.sourceforge.net/viewvc/wxlua/trunk/wxLua/modules/luaproxydll/proxydll.c?revision=100&view=markup

DO NOT COPY someone else's lua51.dll into the wxLua bin dir, it will never work.

ps. Note that I don't think you ever got error messages from wx.dll...
When lua.exe is run it does a pcall() on the input file and so it gets
the error messages, I don't believe it's even possible for wxLua to
get them. I think what you got are print() statements? Though, it has
been a long time since 2.8.10 and I have not retested it. I have
reinstated the error handler, but it's never called, but it's there
and will pop up a dialog if it ever gets called. Run your program from
a DOS prompt and the print and error messages will be printed to the
console.

Regards,
    John

Re: [wxlua-users] change to lua module.cpp

[John L. <jla...@gm...>]

On Sun, Nov 21, 2010 at 8:06 AM, Andre Arpin <ar...@ki...> wrote:
> Hi
>
> After restarting the chnage does not work you have to do it explicitly which
> is a bind.
>
> This is ridiculous and probably a bug in system 7.
>
> // Override the base class virtual functions
> bool wxLuaModuleApp::OnInit()
> {
> #ifdef __WXMSW__
>     ::LoadLibrary(_T("comctl32.dll"));
> #endif
>     return true;
> }
>
> Andre

Thank you for this! I wish I hadn't missed it before, it would have
saved me quite a bit of time.

Thanks again,
    -John