Some love for ZeroBrane Studio

I’d like to say that having a fast Lua debugger and IDE (specifically ZeroBrane Studio, ZBS from now on) - has been a benefit for LuaZ80.

Up till now, I’ve used the command line and a tiny Z80 single step debugger I wrote. However, having a Lua debugger has allowed me to debug stuff that I didn’t even realise was broken - or would have taken longer to figure out in other ways. Whereas I always use a debugger in C++ and C, generally I use a lot of print statements in dynamic programming languages like Python and Lua. But I’ve realised how much help a good debugger is for Lua.

Over the weekend I came across the ZBS remote console (and I had read about it as a feature http://studio.zerobrane.com/features.html … but never used it). So, whilst you are debugging, the local console (which can be used to test bits of Lua or poke ZBS itself) becomes a remote console that’s an interactive session with your Lua program you are debugging - so you can check variables (which you can view with the watch or stack view as well), run functions in your program, define new stuff, or whatever you want.

I also want to play with the Live Coding feature http://notebook.kulchenko.com/zerobrane/live-coding-in-lua-bret-victor-style

For LuaZ80, the Lua code that implements the actual Z80 microprocessor instructions is created piecemeal a line or two at a time and assembled into a table then converted (joined together) into a string with table.concat. All of the fragments are in the same file (lua_z80.lua) based on the operation of original Z80 instructions. The string we then 'compile’/‘process’ with load() to make a function to call that we can call when we reach that Z80 address to run a few Z80 instructions.

Obviously it’s a bit of a problem debugging the code fragments that implement the Z80 because they don’t live in a fixed file. Previously I was using my Z80 single step debugger to view the affects, view the Lua code and guess why the fragment was broken. However with ZBS, using editor.autoactivate = true in my preference file allows me to single step debug this code in a ‘magically created’ file in ZBS.

ZBS is written in Lua (wxLua, wxWidgets, Lua and LuaJIT libraries excluded) which seems a bonus if YOU are coding in Lua - either all Lua or as a small part of your main program (e.g. data load format or script extension language). Did I mention it integrates and debugs external projects very well?

Paul, the author, is also extremely responsive to feedback, and as an open source project it’s great!

As a side note, I’m a bit of fan of Eclipse (several other Java-based IDEs are available) and use PyDev extension for Python work, and CDT for some C++ work. And I’ve also used LDT, which is nice as well. My main problem with LDT is debugging is, for some reason, incredibly slow: running in the debugger takes forever - over five minutes to run (in the debugger) a piece of unit test code on one project that takes a fraction of a second in ZBS - both on Mac OS X and on Win7. (I could complain about the stability of Eclipse with extensions but hey, it’s free and very powerful, so I really have no right to complain). As an active user of Eclipse, Visual Studio and Xcode, ZBS is an amazing piece of work that compares very favourably with the big players.

So, yay for ZeroBrane Studio!