wxlua-users Mailing List for wxLua

Hi John,
> To be sure, for debugging you create a coroutine then run the whole
> app in that coroutine state using debug hooks and yields to pause it?
This is exactly correct. Debug hook is registered to that coroutine,
but the debugger itself runs in yet another coroutine.
> What happens when a wxLua app is paused at a breakpoint and an event
> handler is called? Don't you get an error saying something about
> resuming a suspended coroutine or is the coroutine not yielded to
> pause the execution?
No; never got this message. The application itself is suspended, so it
can't really receive any messages. In fact, I actually *do* set event
handlers from the debug coroutine while it's suspended to minimize
"busyness" of the application (it's around lines 540-550 in
mobdebug.lua), but I have never seen any crashes related to that.
> I would also like to understand what the advantages of the coroutine
> method of debugging are over the wxLua blocking socket method?
I don't use wxlua sockets because the debugger uses exactly the same
mechanism running wxlua or any other lua application.
> In any case, normally anyone who tries to connect an event handler in
> a coroutine will crash their program in a very hard to debug way,
> especially if the coroutine they installed the callback in gets
> garbage collected.
It seems like this has been working fine for me for as long as the
code that handles the callback is in the same coroutine as the code
that sets it (which is my case).
What I also do to support live coding is to call "error" from the
debug hook in the main coroutine, which allows me to reload the code
while the application is running. This is when it crashes with the
current wxlua code and doesn't crash with the patch. It seems like the
line I commented out in the patch does something to the Lua state that
causes the crash.
> I would like to find a way to have it work for your case, but also not
> frustrate new wxLua users who might imagine that they can somehow
> create a "threaded" GUI app using coroutines, not understanding that
> events are already sent asynchronously as has happened in the past.
>
> Maybe it is enough to simply have a strongly worded comment in the
> documentation, but please explain a little about your debugging
> methods.
"A strongly worded comment" would definitely make sense. Please let me
know if you'd need any additional details or a small example that
demonstrates the issue.
Paul.
On Wed, Feb 27, 2013 at 9:39 PM, John Labenski <jla...@gm...> wrote:
> On Wed, Feb 27, 2013 at 6:26 PM, Paul K <pau...@ya...> wrote:
>> Hi John,
>>
>> I'd like to resurrect this discussion as the issue hasn't been fully
>> put to bed and as I'm preparing for 2.9 wxwidgets upgrade I'd like to
>> figure out whether I still need to patch wxlua to support my use case.
>
>> I ended up patching wxlua and removing that one line that was added in
>> the revision 104 (line 103 in this diff:
>> http://wxlua.svn.sourceforge.net/viewvc/wxlua/trunk/wxLua/modules/wxlua/src/wxlcallb.cpp?r1=100&r2=104&pathrev=104).
>
> To be sure, for debugging you create a coroutine then run the whole
> app in that coroutine state using debug hooks and yields to pause it?
> What happens when a wxLua app is paused at a breakpoint and an event
> handler is called? Don't you get an error saying something about
> resuming a suspended coroutine or is the coroutine not yielded to
> pause the execution?
>
> I would also like to understand what the advantages of the coroutine
> method of debugging are over the wxLua blocking socket method?
>
> In any case, normally anyone who tries to connect an event handler in
> a coroutine will crash their program in a very hard to debug way,
> especially if the coroutine they installed the callback in gets
> garbage collected.
>
> I would like to find a way to have it work for your case, but also not
> frustrate new wxLua users who might imagine that they can somehow
> create a "threaded" GUI app using coroutines, not understanding that
> events are already sent asynchronously as has happened in the past.
>
> Maybe it is enough to simply have a strongly worded comment in the
> documentation, but please explain a little about your debugging
> methods.
>
> Regards,
> John
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_feb
> _______________________________________________
> wxlua-users mailing list
> wxl...@li...
> https://lists.sourceforge.net/lists/listinfo/wxlua-users

On Wed, Feb 27, 2013 at 6:26 PM, Paul K <pau...@ya...> wrote:
> Hi John,
>
> I'd like to resurrect this discussion as the issue hasn't been fully
> put to bed and as I'm preparing for 2.9 wxwidgets upgrade I'd like to
> figure out whether I still need to patch wxlua to support my use case.
> I ended up patching wxlua and removing that one line that was added in
> the revision 104 (line 103 in this diff:
> http://wxlua.svn.sourceforge.net/viewvc/wxlua/trunk/wxLua/modules/wxlua/src/wxlcallb.cpp?r1=100&r2=104&pathrev=104).
To be sure, for debugging you create a coroutine then run the whole
app in that coroutine state using debug hooks and yields to pause it?
What happens when a wxLua app is paused at a breakpoint and an event
handler is called? Don't you get an error saying something about
resuming a suspended coroutine or is the coroutine not yielded to
pause the execution?
I would also like to understand what the advantages of the coroutine
method of debugging are over the wxLua blocking socket method?
In any case, normally anyone who tries to connect an event handler in
a coroutine will crash their program in a very hard to debug way,
especially if the coroutine they installed the callback in gets
garbage collected.
I would like to find a way to have it work for your case, but also not
frustrate new wxLua users who might imagine that they can somehow
create a "threaded" GUI app using coroutines, not understanding that
events are already sent asynchronously as has happened in the past.
Maybe it is enough to simply have a strongly worded comment in the
documentation, but please explain a little about your debugging
methods.
Regards,
 John

On Wed, Feb 27, 2013 at 7:29 PM, Mitchell Monahan
<soc...@gm...> wrote:
> Hello, when I use the code that is on http://wxlua.sourceforge.com (here is
> the code in case you forgot:)
>
> frame = wx.wxFrame(wx.NULL, wx.wxID_ANY, "wxLua Minimal Demo",
> wx.wxDefaultPosition, wx.wxSize(450, 450),
> wx.wxDEFAULT_FRAME_STYLE)
...
> --------------------------------------
> I get an error when I go to help --> about(in it's own window):
> Lua: Error while running chunk
> E:\lua\wxLua\init.lua:38: wxLua: expected a 'wxWindow'
> for parameter 4, but got a 'nil'.
> Function called: 'wxMessageBox(string,string,number,nil)'
> 01. wxMessageBox([string,string,number,wxWindow,number,number])
> stack traceback:
> [C]: in function 'wxMessageBox'
> E:\lua\wxLua\init.lua:38: in function
> <E:\lua\wxLua\init.lua:37>
> [C]: in function 'MainLoop'
> C:\Program Files (x86)\Lua5円.1\lExecuter.wlua:799: in
> function '__main'
> C:\Program Files (x86)\Lua5円.1\lExecuter.wlua:802: in main
> chunk
> [C]: ?
I don't understand how/why the frame variable is nil in the callback?
> Yes, I did start this in the lexecutor that was included with Lua for
> Windows, and I am also using the wxLua that was included with Lua for
> Windows.
I don't know about lexecutor or much about Lua for Windows.
The code runs fine using the official wxLua binaries here:
http://sourceforge.net/projects/wxlua/files/wxlua/
Regards,
 John

Hello, when I use the code that is on http://wxlua.sourceforge.com (here is
the code in case you forgot:)
frame = wx.wxFrame(wx.NULL, wx.wxID_ANY, "wxLua Minimal Demo",
 wx.wxDefaultPosition, wx.wxSize(450, 450),
 wx.wxDEFAULT_FRAME_STYLE)
-- create a simple file menu
local fileMenu = wx.wxMenu()
fileMenu:Append(wx.wxID_EXIT, "E&xit", "Quit the program")
-- create a simple help menu
local helpMenu = wx.wxMenu()
helpMenu:Append(wx.wxID_ABOUT, "&About",
 "About the wxLua Minimal Application")
-- create a menu bar and append the file and help menus
local menuBar = wx.wxMenuBar()
menuBar:Append(fileMenu, "&File")
menuBar:Append(helpMenu, "&Help")
-- attach the menu bar into the frame
frame:SetMenuBar(menuBar)
-- create a simple status bar
frame:CreateStatusBar(1)
frame:SetStatusText("Welcome to wxLua.")
-- connect the selection event of the exit menu item to an
-- event handler that closes the window
frame:Connect(wx.wxID_EXIT, wx.wxEVT_COMMAND_MENU_SELECTED,
 function (event) frame:Close(true) end )
-- connect the selection event of the about menu item
frame:Connect(wx.wxID_ABOUT, wx.wxEVT_COMMAND_MENU_SELECTED,
 function (event)
 wx.wxMessageBox('This is the "About" dialog of the Minimal
wxLua sample.',
 "About wxLua",
 wx.wxOK + wx.wxICON_INFORMATION,
 frame)
 end )
-- finally, show the frame window
frame:Show(true)
--------------------------------------
I get an error when I go to help --> about(in it's own window):
Lua: Error while running chunk
E:\lua\wxLua\init.lua:38: wxLua: expected a 'wxWindow'
for parameter 4, but got a 'nil'.
Function called: 'wxMessageBox(string,string,number,nil)'
01. wxMessageBox([string,string,number,wxWindow,number,number])
stack traceback:
 [C]: in function 'wxMessageBox'
 E:\lua\wxLua\init.lua:38: in function
<E:\lua\wxLua\init.lua:37>
 [C]: in function 'MainLoop'
 C:\Program Files (x86)\Lua5円.1\lExecuter.wlua:799: in
function '__main'
 C:\Program Files (x86)\Lua5円.1\lExecuter.wlua:802: in main
chunk
 [C]: ?
Yes, I did start this in the lexecutor that was included with Lua for
Windows, and I am also using the wxLua that was included with Lua for
Windows.

Hi John,
I'd like to resurrect this discussion as the issue hasn't been fully
put to bed and as I'm preparing for 2.9 wxwidgets upgrade I'd like to
figure out whether I still need to patch wxlua to support my use case.
It all started here:
http://www.mail-archive.com/wxl...@li.../msg03002.html.
Basically, you made a change long time ago (I think when the code was
still in CVS) to avoid setting event handlers from coroutines, which
broke some code that was working before (at least for me). We
discussed this and you made a slight change
(http://wxlua.svn.sourceforge.net/viewvc/wxlua?view=revision&revision=104),
which made things better, but it didn't fully address the issue and
some of the code I need still doesn't run.
I ended up patching wxlua and removing that one line that was added in
the revision 104 (line 103 in this diff:
http://wxlua.svn.sourceforge.net/viewvc/wxlua/trunk/wxLua/modules/wxlua/src/wxlcallb.cpp?r1=100&r2=104&pathrev=104).
I can assure you that I've been running ZeroBrane Studio on Windows,
OSX, and Linux for 6+ months with that fix and have not seen or
received any problem related to that change. The problem *with* the
current code is easy to reproduce: take wx.dll compiled with the
current (not patched) version of wxlua and put it in bin/ folder of
ZBS. Try to run any of the turtle drawing examples that come with ZBS
using live coding (Project | Run as Scratchpad) and the Lua process
will crash. Comment out that line and it be executed correctly.
I'm fine with continuing applying this patch and using my own version,
but since there are people that build wxlua from the source (mostly on
Linux), it would be best to come to some agreement on this change. My
preference would be to remove it (note that reverting r104 is not
enough as it re-introduces a different issue). If you continue to
disagree, that's fine, but I'll then document the patch and update my
build scripts to apply it automatically. Thank you.
Paul.

Hi John,
> This is how I do it in stedit.cpp in the modules/wxstedit/src dir.
Should have checked there; I came up with very similar code, but also
included DocLineFromVisible:
function isLineVisible(line)
 local firstline = editor:DocLineFromVisible(editor:GetFirstVisibleLine())
 local lastline = math.min(editor:GetLineCount(),
 editor:DocLineFromVisible(editor:GetFirstVisibleLine() +
editor:LinesOnScreen()))
 return line >= firstline and line <= lastline
end
This is needed because lines can be wrapped (as they are in my case),
but LinesOnScreen counts those as well (so the number on the screen
will be larger than the number in the document).
Paul.
On Mon, Feb 25, 2013 at 9:28 PM, John Labenski <jla...@gm...> wrote:
> On Mon, Feb 25, 2013 at 1:30 PM, Paul K <pau...@ya...> wrote:
>> In the best tradition of self-answering, it turned out that
>> GetLineVisible doesn't do what I need: it only checks against whether
>> the line is hidden because of folding (not if it's outside of the
>> visible area, which is what I'm looking for). I don't see any other
>> API method that does this, so I calculate it myself using
>> GetFirstVisibleLine, LinesOnScreen, and DocLineFromVisible.
>
> Yes. It doesn't have the clearest name. I think you know this, but the
> wxStyledTextCtrl function names map pretty closely to Scintilla's
> message names.
>
> http://www.scintilla.org/ScintillaDoc.html#SCI_GETLINEVISIBLE
>
>
> This is how I do it in stedit.cpp in the modules/wxstedit/src dir.
>
> int first_line = top_line < 0 ? GetFirstVisibleLine() : top_line;
> int line_count = GetLineCount();
> int lines_visible = LinesOnScreen();
> int last_line = bottom_line < 0 ? wxMin(line_count, first_line
> + lines_visible) : bottom_line;
>
>
> Regards,
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_feb
> _______________________________________________
> wxlua-users mailing list
> wxl...@li...
> https://lists.sourceforge.net/lists/listinfo/wxlua-users

On Mon, Feb 25, 2013 at 1:30 PM, Paul K <pau...@ya...> wrote:
> In the best tradition of self-answering, it turned out that
> GetLineVisible doesn't do what I need: it only checks against whether
> the line is hidden because of folding (not if it's outside of the
> visible area, which is what I'm looking for). I don't see any other
> API method that does this, so I calculate it myself using
> GetFirstVisibleLine, LinesOnScreen, and DocLineFromVisible.
Yes. It doesn't have the clearest name. I think you know this, but the
wxStyledTextCtrl function names map pretty closely to Scintilla's
message names.
http://www.scintilla.org/ScintillaDoc.html#SCI_GETLINEVISIBLE
This is how I do it in stedit.cpp in the modules/wxstedit/src dir.
 int first_line = top_line < 0 ? GetFirstVisibleLine() : top_line;
 int line_count = GetLineCount();
 int lines_visible = LinesOnScreen();
 int last_line = bottom_line < 0 ? wxMin(line_count, first_line
+ lines_visible) : bottom_line;
Regards,

In the best tradition of self-answering, it turned out that
GetLineVisible doesn't do what I need: it only checks against whether
the line is hidden because of folding (not if it's outside of the
visible area, which is what I'm looking for). I don't see any other
API method that does this, so I calculate it myself using
GetFirstVisibleLine, LinesOnScreen, and DocLineFromVisible.
Paul.
On Sun, Feb 24, 2013 at 10:10 PM, Paul K <pau...@ya...> wrote:
> Hi John,
>
> Thank you for adding wxAuiToolBar to wxlua. One short question on
> GetLineVisible. According to the documentation it should return "1 if
> the passed in line is visible or 0 if it is not". For some reason, no
> matter what I pass, I always get back "true". Is it possible that
> there is some bug in the conversion of numbers wxlua gets from
> wxwidgets/Scintilla? Thank you.
>
> Paul.

Hi John,
Thank you for adding wxAuiToolBar to wxlua. One short question on
GetLineVisible. According to the documentation it should return "1 if
the passed in line is visible or 0 if it is not". For some reason, no
matter what I pass, I always get back "true". Is it possible that
there is some bug in the conversion of numbers wxlua gets from
wxwidgets/Scintilla? Thank you.
Paul.

Hi John,
> I will fix this tomorrow, but note that if you don't intend to call
> that particular function you can just rem out the failing part in the
> C++ binding code and put in whatever minimal stub is needed to get it
> to compile.
I tried to compile 2.9.5 using the latest code from SVN (including
your last fix), but it still fails with a similar issue:
[ 47%] Building CXX object
modules/wxbind/CMakeFiles/wxLuaBindLib.dir/src/wxadv_bind.cpp.obj
D:\Lua\build\wxlua\modules\wxbind\src\wxadv_bind.cpp: In function 'int
wxLua_wxGridCellEditor_PaintBackground1(lua_State*)':
D:\Lua\build\wxlua\modules\wxbind\src\wxadv_bind.cpp:8204:43: error:
no matching function for call to
'wxGridCellEditor::PaintBackground(const wxRect&, const
wxGridCellAttr&)'
D:\Lua\build\wxlua\modules\wxbind\src\wxadv_bind.cpp:8204:43: note:
candidate is:
D:/Lua/build/wxWidgets-2.9.5/include/wx/generic/grid.h:216:18: note:
virtual void wxGridCellEditor::PaintBackground(wxDC&, const wxRect&,
const wxGridCellAttr&)
D:/Lua/build/wxWidgets-2.9.5/include/wx/generic/grid.h:216:18: note:
candidate expects 3 arguments, 2 provided
This includes your fix in rev #158. I'd prefer not to stub and, but
rather compile out of the box. Also, it seems like the fix is likely
to break in the next update of wxwidgets:
!%wxchkver_2_9_5 virtual void PaintBackground(const wxRect& rectCell,
wxGridCellAttr *attr );
%wxchkver_2_9_5 virtual void PaintBackground(const wxRect& rectCell,
const wxGridCellAttr &attr );
Is it possible to do "<" and ">=" instead of "!" and (implied) "=="? Thank you.
Paul
On Wed, Jan 16, 2013 at 10:03 PM, John Labenski <jla...@gm...> wrote:
> On Thu, Dec 20, 2012 at 6:05 PM, AZ <red...@gm...> wrote:
>> I tried to build wxlua against 2.9.5 SVN trunk but it failed: is it 2.9
>> support a work in progress?
>
> No... not so much a work in progress as continual work of mapping the
> functions. Since wxLua wraps so much of wxWidgets any change in their
> API anywhere causes breakage.
>
> I will fix this tomorrow, but note that if you don't intend to call
> that particular function you can just rem out the failing part in the
> C++ binding code and put in whatever minimal stub is needed to get it
> to compile.
>
> Regards,
> John
>
> ------------------------------------------------------------------------------
> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
> MVPs and experts. ON SALE this month only -- learn more at:
> http://p.sf.net/sfu/learnmore_122712
> _______________________________________________
> wxlua-users mailing list
> wxl...@li...
> https://lists.sourceforge.net/lists/listinfo/wxlua-users