ZeroBrane Studio for Vera v0.90 is out -- Lua IDE for debugging on Vera devices

Developer's Corner General Dev Discussions
1

Hi All,

I’m pleased to announce the release of the new version of ZeroBrane Studio for Vera (0.90). The new version includes Vera integration as well as the IDE functionality changes. If you want to skip the details, install the new version, copy any settings you have in “Edit | Preferences | Settings: System” (if you installed into a different folder than your current version), and select “Unregister Devices” from the popup menu in the editor (to update the debugger on the device to get access to some new functionality).

Anyone who bought ZBS4V is eligible for the free upgrade and can access the new version by using the URL from the confirmation email. If you don’t have the URL, let me know via email and I’ll help you with that.

In terms of Vera integration, the new package provides better error handling and allows to remove files on the device from the IDE (use “Remove Remote File” from the context (right click) menu in the editor). The documentation has also been updated; I suggest checking the getting started page (Getting Started - ZeroBrane Studio for Vera/MCV devices - Lua IDE/editor/debugger for Windows, Mac OSX, and Linux) for the overview on what debugging features are supported.

The first thing you will likely notice is simplified user interface and updated application icons. The IDE is now using lighter colors and better fonts by default and has better icons in the toolbar. Captions have been removed from the panels; you can double click on tab background before dragging panels. The project dropdown was removed; there is now Project tab that has the same content. To switch between projects you can use (1) “File | Recent Projects”, (2) right click in the project/file tree and select “Project Directory”, or (3) use “Choose a project directory” dropdown on the toolbar. The function dropdown (previously on the toolbar) was replaced with the new Outline tab next to Project tab. The functionality of the outline has been improved as you can use it for navigation and it’s updated in real-time as your source code changes.

Some other IDE changes:

  • Added scope-aware auto-complete for local/global variables.
  • Added support for editing and expanding table elements in Watch window.
  • Added highlighting all instances of selected text.
  • Added replacing all selected instances using a dialog.
  • Added search in Console and Output windows.
  • Added re-indentation of selected fragment or entire file.
  • Added support for switching breakpoints at run-time.
  • Added bookmark handling.
  • Added Detach process command to stop debugging and continue process.

Overall, these changes should provide even more pleasing experience with the IDE.

You can still run the old and the new version side by side and they will even share the same config. If you do this, you may notice small UI glitches when you switch between versions (this is because the layout is slightly different); you can fix those by going to “View | Defaut Layout”.

The IDE also provides new debugging functionality (for example, setting/removing breakpoints at run-time), which require a new debugger deployed to the device. For that to happen you need to select “Unregister Devices” from the context (right click) menu in the editor. You only need to do this once after the upgrade. The new version of the debugger is 0.611, which you can confirm by running “require(‘mobdebug’)._VERSION” in the Remote Console when the debugging is on.

Thanks to the beta-testers of the current version and to all the users who provided their feedback and suggestions on how to improve the product!

Please let me know if you run into any issues with the new version as I only have one device and have not been able to test it on various firmware versions. The auto-detection mechanism used in UI5 has changed in UI6 and UI7, so if the address of your device is not auto-detected, you may need to specify it manually as described in this FAQ answer (Frequently Asked Questions - ZeroBrane Studio for Vera/MCV devices - Lua IDE/editor/debugger for Windows, Mac OSX, and Linux).

Paul.

2

I am happy to report that installing the new version was totally painless. For interest, I installed it in a different folder to the previous version and copied my system settings over. Both versions work perfectly.

I like the changes to the UI and the additional features. Good work, Paul.

3

It’s been a month+ for me getting my feet wet with plugins, lua and the “standard” development environment for Vera (modify code in a stand alone text editor, add log entries, upload , wait, refresh, wait, run, view log…rinse repeat…) So now I’m comfortable enough with the whole process to know what a pain in the ass it generally is.

I just paid for installed this and configured for my UI7 unit and going through a couple of the tutorials.

This is brilliant. :slight_smile: Well worth the investment.

Now if you could do the same thing for UI JSON editing…you know…a GUI for placing controls and modifying their properties for both UI5 and UI7…I’d pay double the price of admission for that!

4

I do have a question about uploading / downloading files from the /etc/cmh-ludl/

Is there a reason why you must have an active debugging session to take advantage of this? Even though I can’t make real use of the IDE for .xml and .json files, it would be an added convenience to be able to quickly edit and the upload these files from within ZeroBrane.

5

@RexBeckett, @JoeyD, thank you for the feedback! Glad it’s working well for you.

I do have a question about uploading / downloading files from the /etc/cmh-ludl/
Is there a reason why you must have an active debugging session to take advantage of this? Even though I can’t make real use of the IDE for .xml and .json files, it would be an added convenience to be able to quickly edit and the upload these files from within ZeroBrane.

I agree. The main reason forusing debugging is that there is no easy way to get results back from luup calls that execute Lua code, so ZBS is using the debugging session as a transport to send the files to the device. I’ve tried sending files as part of the RunLua action, but it’s been problematic in my tests with some large files.

You can have one debugging session to send any files to the device. I do realize that it can be done more seamlessly and continue to explore options to remove that dependency on debugging… Paul.

6

+1 on removing the debug session requirement for uploading files.

7

Paul,
FYI, most of my coding experience up to now has been with Visual Basic for Applications, so that is my frame of reference.

I don’t quite understand how the breakpoint in ZeroBane is implemented. I expect to be able to start a debugging session, and then press F5 again (continue) and then the code would execute non-stop until either an error is encountered or the break point is reached. (The code execution only pauses at the breakpoint ).

I’m not seeing this behavior in ZeroBane. Once a debug session starts, pressing F5 again (continue) stops at other places in the code (seemingly random to me) before getting to the breakpoint, where it will also stop.

Finally, It would be helpful for all “print” output to go to the output console when the code is executed. From what I can tell,print output is only sent while actively debugging and stepping through code. At the very least, once you start a debugging session, I feel that all print output should be sent. (In other words, if I press F5 twice…once to start and a second time to continue all print output should go to the output console).

Thoughts?

Edit…well I did add the <debugger.redirect = ‘c’> setting, and restarted the IDE a couple times…and the print behavior seems to be what I expect. However, the set-point behavior is still as above (not what I would expect.)

8

ok; I’ll experiment a bit more to see if I can come up with a way to do this.

9

I don’t quite understand how the breakpoint in ZeroBane is implemented. I expect to be able to start a debugging session, and then press F5 again (continue) and then the code would execute non-stop until either an error is encountered or the break point is reached. (The code execution only pauses at the breakpoint ).

@JoeyD, that’s exactly how it should behave, so your expectation is correct.

I’m not seeing this behavior in ZeroBane. Once a debug session starts, pressing F5 again (continue) stops at other places in the code (seemingly random to me) before getting to the breakpoint, where it will also stop.

I’ll need more information or some code on which to reproduce this (if this is reproducible). There used to be a bug when breakpoints would not reset between sessions (as the remote application doesn’t exit when the debugging is done, there may be breakpoints set in the debugger from previous sessions), but it’s been long fixed.

Do you debug code from the IDE or do you start debugging remotely (for example, to debug scene or plugin code)? You can enable verbose debugging (by setting “debugger.verbose=true” in the config file) and I’d like to see this output when you run into this issue next time (you can email it to support@zerobrane.com).

Finally, It would be helpful for all “print” output to go to the output console when the code is executed. From what I can tell,print output is only sent while actively debugging and stepping through code. At the very least, once you start a debugging session, I feel that all print output should be sent. (In other words, if I press F5 twice…once to start and a second time to continue all print output should go to the output console).

Correct; during debugging all “print” output should go to the console, but not during normal “running” as at that time there is no channel to deliver “print” results back to the IDE.

Do you have an example of this not happening? Is there some specific code I can try this on? Paul.

10

I think I can reproduce a case that is still affected by this bug. I can reproduce it by putting this code (for example) in a new document:

local a=1 local b=2 local c=3 local d=4 local e=5 local f=6 local g=7 local h=8

Set a breakbpoint on line 5, start the debugger (forces save of new doc). Then exit the IDE before continuing or completing the debugging session. reload the IDE. There are no breakpoint indicators. However, if you start debugging again on this doc, it will break on line 5.

So it may be a broad case where if you exit the IDE while a debugging session is still active that the breakpoints are not being reset properly.

Thanks for the great product and support!

11

[quote=“JoeyD, post:10, topic:185329”]So it may be a broad case where if you exit the IDE while a debugging session is still active that the breakpoints are not being reset properly.

Thanks for the great product and support![/quote]

JoeyD, thank you for the example; there is indeed an issue as the breakpoints are reset when the debugging starts (after the restart), but at point the information about breakpoints that were set in the last session is not available. The current workaround is to remove breakpoints first before exiting, or click on that line to set/reset the breakpoint, or to reload the luup engine, which will reset the breakpoints. I expect this to be fixed in the next release. Paul.

12

Just wanted to say that remote debugging is a god-send. :slight_smile:

Being able to step through the code as it was running on Vera allowed me to track down an issue in minutes…and I can’t imagine how long it would have taken otherwise!

13

Any tips on setting up Remote Debugging? My ZBS menus for upload and download to/from Vera are greyed out as well. I added a path.vera in the user.lua and tried it in the system.lua to no avail.

It registered my device the first time I hit debug but stopped responding to breakpoints after a while. When I set a breakpoint then press F5 it blows off the breakpoint and places a Program completed in xx.xx seconds in the output. I have never been able to set a breakpoint then hit it remotely. I’m not a novice at using a debugger, I’ve used Soft-ice, Borland, Visual Studio, and a whole host of other debuggers. I’m sure there is something simple that I am missing but I am not sure what it could be. For now, I am relegated to writing messages to the log.

14

Maybe this will help…it’s interesting that you mentioned a couple things related to similar comments I made earlier…that should give ZBS an indication where some improvement in usability may be in order. :slight_smile:

  1. In order for “uploading / downloading” to be active, you must be in an active debugging session. In other words, you must have pressed “play” and the debugging session must not complete.

  2. Breakpoints are still a little flakey (see previous posts). At least if you exit ZBS while a session is active, and then go back in. Hopefully that will be addressed soon.

  3. I believe (assume?) your PC must be on the same local network as your vera.

  4. In my system settings, (Edit…Preferences…settings: user)_ I have:

path.vera = '192.168.1.25'

(That’s my local IP address for my vera).

  1. For remote debugging, I use Method 1 as described here.

You need to insert the IP address of the PC you are using to debug in your require(‘mobdebug’).start(‘device-IP-address’) statement. You can easily get this by starting a debugging session (on any file) and you’ll see in the output window: “Using ‘xxx.xxx.x.xx’ as the debugger server address.”

You must NOT have an active debugging session when you start running remote code, but you must have the debugging server running.

I did find that sometimes the first time it does not open up a new IDE tab, and you must try a second time.

15

I went through Method 1 over and over again and never got it to work originally. With your clues I figured out why.

I run a couple of different vpn clients on my PC and noticed that it was picking up the last client IP assigned to my Cisco client as the IP address for the debugger server. Note this is not the active IP for the PC when the connection is not active but the Cisco client is pretty invasive. Shutting all of the VPN services down and running ipconfig /renew made the actual IP of my PC get used for the debugger server. Which is on the same subnet as my Vera and the breakpoint got hit. I suppose I should have been paying more attention to the output pane.

Thanks for that.

Yeah, I figured out the upload/download thing pretty early on and decided not to use it anymore because of the debugging session requirement. I keep scp open and drag my files in that way.

16

@JoeyD, thank you for the feedback and the detailed suggestions!

  1. In order for “uploading / downloading” to be active, you must be in an active debugging session. In other words, you must have pressed “play” and the debugging session must not complete.

I’m looking into relaxing this requirement to make upload working outside of the debugging session.

  1. Breakpoints are still a little flakey (see previous posts). At least if you exit ZBS while a session is active, and then go back in. Hopefully that will be addressed soon.

This issue has been fixed; I just need to complete testing the debugger with the old versions of ZBS4V that users may still be using. I’ll deploy the updated debugger and will post instructions on how to upgrade in few days.

@rstrouse,

Any tips on setting up Remote Debugging? My ZBS menus for upload and download to/from Vera are greyed out as well. I added a path.vera in the user.lua and tried it in the system.lua to no avail.

The instructions that JoeyD posted should help, but if you still have issues, please let us know and we will try to help. My suggestion is to start with the simplest script (like those that are included with ZBS4V) and try to get the debugging working. If it still doesn’t work even for the simple script, it would be useful to see the content of the Output window (ideally with “debugger.verbose=true”; you can email it to support@zerobrane.com). Thank you. Paul.

17

Thank you for the update; glad you got it working!

18

I wouldn’t worry too much about it since just about everything has an issue with the Cisco VPN client. Just if you see it again tell the person to kill the startup services and run an ipconfig /renew this drops all the Cisco hooks. For some reason it sometimes can hang on to the reassigned IP for the tunnel. Windows network services do not seem to be affected but apps sometimes get the wrong IP.

19

[quote=“JoeyD, post:10, topic:185329”]Set a breakbpoint on line 5, start the debugger (forces save of new doc). Then exit the IDE before continuing or completing the debugging session. reload the IDE. There are no breakpoint indicators. However, if you start debugging again on this doc, it will break on line 5.

So it may be a broad case where if you exit the IDE while a debugging session is still active that the breakpoints are not being reset properly.

Thanks for the great product and support![/quote]

@JoeyD, and others who noticed the same problem. This issue has been fixed and the fix will be included in the next version. If you want to use the update now, you’ll need to the following:

  1. Download the updated version of mobdebug.lua to replace /lualibs/mobdebug/mobdebug.lua file from https://raw.githubusercontent.com/pkulchenko/ZeroBraneStudio/master/lualibs/mobdebug/mobdebug.lua
  2. Start ZBS and start Luup/Vera debugging
  3. Right click in the editor with your script and select “Unregister Devices”
  4. Right click in the editor and select “Restart Luup Engine”

After this the breakpoints should be removed between sessions as expected. Please let me know if you run into any other issues. Paul.

20

Thanks, Paul!
I’ll try it out and let you know if I still see any issues.