Hello Guest it is December 11, 2019, 12:23:39 PM

Author Topic: Debugging Lua code...  (Read 1271 times)

0 Members and 1 Guest are viewing this topic.

Debugging Lua code...
« on: March 12, 2018, 02:53:43 PM »
The Mach4 alpha came out I seem to remember a debugger that allowed you to set break points in code and then while Mach4 was running normally, you could examine the state of your code at the break point.

Is that still available with build 3713 (the latest Dev build) with the new ZeroBrane support?

Are there any best practices for debugging modules while Mach4 is running?


-Freeman
I'm not a complete idiot...
    there are some parts missing.

Online smurph

*
  • *
  •  1,155 1,155
  • "That there... that's an RV."
    • View Profile
Re: Debugging Lua code...
« Reply #1 on: March 12, 2018, 05:15:27 PM »
ZeroBrane is in the latest builds.  The ScreenEditor document (in the Docs folder) has a section on how to debug the screen scripts. 

Steve
Re: Debugging Lua code...
« Reply #2 on: March 12, 2018, 05:35:01 PM »
Thanks Steve,

I am also writing modules that are outside of my screen set for a different approach to probing/offsets using a master tool or touch plate. I also need to implement tool measurement with a laser. Is it safe to assume that I can set break points within these modules and debug them the same way as described in the document?

I noticed that when I run ZeroBrane from within the screen editor, that I have to close and restart it each time I edit a UI event script. This can be a bit annoying if you are in the middle of a piece of code and you need to touch event handlers. Is it possible to keep the ZeroBrane running and have tabs added and removed as needed? Having ZeroBrane open shouldn't keep you from interacting with the screen editor. At the moment it does. I realize this would require some form of IPC between Mach4GUI and ZeroBrane. ZeroBrane may not even support it.


-Freeman
I'm not a complete idiot...
    there are some parts missing.

Online smurph

*
  • *
  •  1,155 1,155
  • "That there... that's an RV."
    • View Profile
Re: Debugging Lua code...
« Reply #3 on: March 12, 2018, 06:09:16 PM »
You can remote debug any script you want with ZeroBrane.  The script just has to have access to the mobdebug module and the lua sockets module.  The screen scripts have the package.path and package.cpath already setup for this.  Just do Operator->View Screen Script and look at the top of that code.  Cut and paste as needed. 

With ZeroBrane, you can now debug the screen scripts.  However, they are running in the screen (not the editor).  So to edit the code, one must exit out of the LUA editor and go back into the screen editor.  That is just the way it is.  Mainly because the scripts are compiled into one larger script.  But also because they are compiled and there is no way that the LUA editor is going to be able to compile the changes and insert them into the running screen.  It is why the ScreenScript.lua file is read only. 

Also, when editing a screen script from the properties of the object, a LUA editor is launched to edit it.  The script resides in the screen as a string.  So the screen writes that script out to a temporary file (so that the editor can open it).  The key thing here is that the screen launches the editor with a temporary file.  How do we know when you are done editing that temporary file?  Well...  because you closed the editor.  We can't tell that the editor closed the file, but we can tell if you closed the editor (because the Mach GUI opened it).  Currently, there is no way in the ZeroBrane editor to tell the Mach GUI if the temporary file is close and furthermore, there is nothing inside the Mach GUI to listen if there was.  Once the editor is closed, the screen compares the script in the temporary file to the string in the properties.  If they are different, then screen replaces the string with what was in the temporary file.  So leaving the editor open is not really an option.

Also note that if you try and open the screen LUA editor more than once, you will not succeed.  It will raise the existing instance of the LUA editor.  This is the default behavior of ZeroBrane Studio.  However, that can be changed in the user configuration.  Have a look at the ZeroBrane documentation on how to do this.  But also note that there can only be one LUA editor with a debug server running.  It uses TCP/IP ports in the background.  But a solution to the problem may be evident here.  Open the ZeroBrane editor from the GUI menu (this one will be the debug server).  Then edit the screen.  Each time you edit a script from an object property, a new editor will open.  So that you can edit it (and more importantly, close the editor to pick up the changes).  You'll just have to try it out.  Keep in mind that editing the any of the screen property scripts will cause the screen to regenerate the ScreenScript.lua file.  It only does this AFTER you exit the screen editor.  So if the ScreenScript.lua file is open in the first ZeroBrane editor will be stale.  The fix for that is to just close the ScreenScript.lua file before you exit the screen.  But your breakpoints may be lost or moved. 

All of this is why I outlined the way to debug the scripts in the manual like I did.  It is a solid and fool proof method for getting the job done.  It may have a lot of steps, but it has the desired results.  At least you guys now have the capability of using a debugger in the screen scripts where as before it was a lot more cumbersome with message boxes and SetLastError (called printf debugging in the programming world).

But the easiest thing to do to make debugging easier is "don't mess up" in the first place, right?  LOL

Steve

Re: Debugging Lua code...
« Reply #4 on: March 12, 2018, 06:36:27 PM »
Thanks Steve;

Excellent coverage on the issues. I'll have to read the document and reread what you posted bring it together in the way I'm doing work.

The last part about the ScreenScript.lua may explain why the exception messages in the log output are sometimes way off from the line numbers I'm expecting in the file as I edit it. I wonder if Lua has the ability to do something like C/C++ with #line preprocessor command. It would be nice to have accurate line numbers in the exception messages. Then again, I could just go look at the line in the ScreenScript.lua and match it up with the code I'm editing.

I'm not a complete idiot...
    there are some parts missing.
Re: Debugging Lua code...
« Reply #5 on: March 12, 2018, 07:11:36 PM »
Hi smurph,
a superb explanation...again. Maybe you should consider a career in software when you grow up...LOL

Craig
My wife left with my best friend...
     and I miss him!

Online smurph

*
  • *
  •  1,155 1,155
  • "That there... that's an RV."
    • View Profile
Re: Debugging Lua code...
« Reply #6 on: March 12, 2018, 07:37:54 PM »
LOL!!!  You think?  I dunno...  It hurts my brain sometimes.  LOL

Paul Kulchenko (the author of ZeroBrane Studio) did a really nice job and he has been a pleasure to work with.  The version that comes with Mach is a special version that he did up for us since the original mcLuaEditor.exe that we did had some special things inside it.  So he duplicated all of that and made it a really nice integration.  I was at the point where I really needed to spend some time making mcLuaEditor better (add remote debugging capability, etc...) but why re-invent the wheel?  Oh, BTW, that whole ZeroBrane Studio editor is done in LUA.  That shows you the power of the wxWidgets/LUA combination.  

Steve
Re: Debugging Lua code...
« Reply #7 on: March 13, 2018, 11:58:52 AM »
Integration ZeroBrain is great job!
But now I have some trouble with debugging. I start "Edit/Debug script" from menu and open M6.mcs from demo profile. But when I try to debug script, or just run it, this part of code return strange result

        local inst = mc.mcGetInstance()
   print(inst)
   local selectedtool, rc = mc.mcToolGetSelected(inst)
   print(rc)
   local currenttool, rc = mc.mcToolGetCurrent(inst)
   print(rc)

print

0
-17
-17

Whats mean of -17 result code, and what I do wrong?
Re: Debugging Lua code...
« Reply #8 on: March 13, 2018, 12:34:39 PM »
from modules directory mcErrorCheck.lua

[-17] = 'MERROR_API_INIT',

I have no idea what that means or how to fix it.
Re: Debugging Lua code...
« Reply #9 on: March 13, 2018, 12:36:58 PM »
If I'm reading this correctly, error -17 is assigned to mc.MERROR_API_INIT. This would suggest something was done out of order and the API hasn't been initialized yet. The first print statement shows that 'inst' is set to '0'. I have never seen an instance value of zero. Zero or negative numbers usually suggests a problem.

-Captain Obvious
I'm not a complete idiot...
    there are some parts missing.