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