Hi John,

> Please read this thread to understand a little more about why it was blocked.
> http://www.mail-archive.com/wxlua-users@lists.sourceforge.net/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 <jlaben...@gmail.com> wrote:
> On Sat, Jun 30, 2012 at 9:00 PM, Paul K <paulclin...@yahoo.com> 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/wxlua-users@lists.sourceforge.net/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
> 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

Reply via email to