[synth]

@paulclinger Yeah I realized that later that and removed the require mobdebug line from code. I was able to start debugging at any time and saw the code break in Zerobrane. I wasnt able to detach the debugger though. I think I tried require(‘mobdebug’).done() but it was crashing Ctrlr. I ll try it out once more and let you know. 🙂

Thanks for looking at this.

Atom,
Which library do you currently use for the debugger ?

[synth]

Hmm that wasnt a good idea. Doesnt work in panel edit mode :

void CtrlrSlider::sliderValueChanged (Slider* sliderThatWasMoved)
{
    if (sliderThatWasMoved == &ctrlrSlider)
    {
		if ((bool)owner.getOwner().getEditor()->getProperty(Ids::uiPanelEditMode) == true)
			return;

		setComponentValue (ctrlrSlider.getValue(), true);
    }
}

I ll probably need to go in and record at each sliderChanged listener function I guess.

[synth]

I am looking at CtrlrModulatorProcessor::setValueFromGUI() now

It seems to get called for every user GUI interaction. Seems like an ideal place to record a lua string for the property change.

[synth]

On thinking more about this before I try this out, there is no need for a separate thread at all to update the Method Editor. The lua code can simply call back to C++ and there we can update the Method Editor and only show an UI to resume execution in a separate thread. Then we go into a modal loop in the main thread to block it.

When the user clicks resume, this separate thread terminates and unblocks the main thread to resume.

[synth]

That sounds good for now 🙂

What would be really awesome to try, and is also a lot more complex, is to update the Method Editor window itself with an arrow pointing out the current line of execution. And have buttons there to control resuming, stopping, setting breakpoints etc. Currently we cannot do that because the lua code executes in the main thread and updates the lua state there. So if I write an infinite loop in a Lua method, the only way to stop it would be to shut down Ctrlr 😛

So we need to move the panel execution to its own thread. So a panel can be debugged. And a misbehaving panel cannot crash the editor itself. Just like browsers do with various tabs.

But I think we can have only one other thread and only one panel executing at any time to prevent 2 threads calling into C++ code via the lua bindings and causing race conditions and other threading conditions.

So the run_code method() always executes in a separate asynchronous task and the main thread simply disables the panel UI and the method editor UI and also the console :P. This way we prevent the lua state from being accessed from 2 threads and being corrupted.

When run_code() finishes in the async task we get a callback. If run_code() causes the debug function to be called, this function needs to communicate

the current line of execution
the current stack and
the values of watched variables

to the main thread.

• This reply was modified 9 years, 6 months ago by synth.
• This reply was modified 9 years, 6 months ago by synth.
• This reply was modified 9 years, 6 months ago by synth.

[synth]

Ah cool 🙂 I ll try it.

Thanks that worked !

• This reply was modified 9 years, 6 months ago by synth.

[synth]

I see you got started with an initial debugging facility in debugger.lua

I havent checked the implementation yet, but do you essentially put a debug hook that gets called before a line is executed by the Lua interpretor ?

I was wondering how a watch window and a stack trace window can be implemented. While the debugger is halted inside the debug hook, the main thread is blocked there ? Since this is the JUCE message thread, so that too is blocked ? So would it be possible to update a UI element in the Lua Method Editor with the values of watch variables and stack traces and see them appear ?

[synth]

Looking at this more closely, it seems that what mobdebug does in Lua we can directly do in C++ through the Lua C API : http://www.lua.org/manual/5.1/index.html#index

MobDebug registers a debug_hook() in Lua and we can register a C function through : http://www.lua.org/manual/5.1/manual.html#lua_Hook

That would allow us to have a debugger integrated into Ctrlr itself rather then rely on an external debugger server.

We can also examine variable values and put them in a watch window and show the current stack : http://www.lua.org/manual/5.1/manual.html#lua_Debug

• This reply was modified 9 years, 6 months ago by synth.

[synth]

So it seems that the lua callbacks for various events in a panel, they seem to be placed in the panel file itself. That makes them impossible to debug thorough an external debugger.

Maybe while creating a new method for one of the panel callbacks, there can be an option to add it to a .lua file. If the file does not exist its created. The method code is always compiled from this file and the file can be given to an external debugger while debugging.

By the way the socket library needs to be exposed by a call to CtrlrLuaSocket::wrapForLua(L) in CtrlrLuaManager::wrapCtrlrClasses(lua_State* L)

• This reply was modified 9 years, 6 months ago by synth.

[synth]

I was able to load the OS module here on Ctrlr/Linux but this might behave differently on different OSes, hence the name.

Cool 🙂

• This reply was modified 9 years, 6 months ago by synth.

[synth]

So it seems that I need to open the mobdebug.lua file in Ctrlr as well as my Test.lua file. Then I need to switch my project directory in Zerobrane to the one which has Test.lua

Then I need to choose save and compile all in Ctrlr which seems to notify Zerobrane. At least I can see that the code breaks there during compilation at :

require('mobdebug').start()

function testme()                    <----------------------- right here
    console("testme() called")
    console("Step 1")
    console("Step 2") 
end

Then I press F10 multiple times to complete the compilation. After that if I call testme() from the console, the code breaks at “console(“testme() called”)”

[synth]

I have modified mobdebug to remove 1 line which refers to the ‘os’ library. Now it compiled and I can see the code stopped at the breakpoint in Zerobrane. I ll test it out and post the changes.

——————

I copied mobdebug from ZeroBraneStudioEduPack-0.80-win32\lualibs\mobdebug\ into Source\Lua\mobdebug in Ctrlr and suddenly it seems to compile fine. I was getting an error in line 643 in mobdebug.lua earlier but that seems to be gone now.

console() output seems to be sent to Ctrlr only after the debugging session completes. Probably print() may work better. I have yet to check if the watch window works in Zerobrane to observe locals

• This reply was modified 9 years, 6 months ago by synth.

[synth]

It worked.

[synth]

ok, that helped.

It seems the ‘os’ library is required now as mobdebug uses it :

--
-- MobDebug 0.60
-- Copyright 2011-14 Paul Kulchenko
-- Based on RemDebug 1.0 Copyright Kepler Project 2005
--

-- use loaded modules or load explicitly on those systems that require that
local require = require
local io = io or require "io"
local table = table or require "table"
local string = string or require "string"
local coroutine = coroutine or require "coroutine"
-- protect require "os" as it may fail on embedded systems without os module
local os = os or (function(module)
  local ok, res = pcall(require, module)
  return ok and res or nil
end)("os")

local mobdebug = {....

I tried :

lua_pushcfunction(luaState, luaopen_os);
lua_pushliteral(luaState, "os");
lua_call(luaState, 1, 0);

That compiles but it crashes with memory leaks in Juce.

[synth]

Trying with :

	lua_pushcfunction(luaState, luaopen_io);
	lua_pushliteral(luaState, "io");
	lua_call(luaState, 1, 0);

in CtrlrLuaManager::CtrlrLuaManager(CtrlrPanel &_owner)

—————-

ok that did work and “local io = io or require “io” works now

• This reply was modified 9 years, 6 months ago by synth.

[synth]

Yes I guess I can currently use “require” with the following patterns for the path to load packages distributed as .lua files, like mobdebug :

http://www.lua.org/pil/8.1.html

For C-packages there is http://www.lua.org/pil/8.2.html

Still not sure where the io.lua file actually is though in Ctrlr. Or maybe its a C-package.

————-

I found a C file in the current lua source code for lua-5.2.3 in liolib.c. I ll try getting the one for lua-5.1 and compiling it with Ctrlr.

• This reply was modified 9 years, 6 months ago by synth.
• This reply was modified 9 years, 6 months ago by synth.

[synth]

I wonder if there is some central place where I can get these standard libs for Lua.

What is the Lua version being used by Ctrlr ?

[synth]

ok I added mobdebug from ZeroBrane to Ctrlr at Source\Lua\mobdebug

I see that mobdebug requires some extra modules :

--
-- MobDebug 0.60
-- Copyright 2011-14 Paul Kulchenko
-- Based on RemDebug 1.0 Copyright Kepler Project 2005
--

-- use loaded modules or load explicitly on those systems that require that
local require = require
local io = io or require "io"
local table = table or require "table"
local string = string or require "string"
local coroutine = coroutine or require "coroutine"
-- protect require "os" as it may fail on embedded systems without os module
local os = os or (function(module)
  local ok, res = pcall(require, module)
  return ok and res or nil
end)("os")
..
...

I will try to find the io library and the others and compile it in with Ctrlr. I wonder if there is some central place where I can get these standard libs for Lua.

What is the Lua version being used by Ctrlr ?

• This reply was modified 9 years, 6 months ago by synth.
• This reply was modified 9 years, 6 months ago by synth.

[synth]

So I added a .lua file to one of my panels today with the following contents :

--
--
--
require('mobdebug').start()

function testme()
    console("Test me called")
end

This is as given in http://studio.zerobrane.com/doc-remote-debugging.html

It seems mobdebug is needed. I am not sure though if only the luasocket and mobdebug from Zerobrane works, or the luasocket library thats already there in Ctrlr (along with mobdebug also added to Ctrlr) will work.

[synth]

Ah ok thanks.

[Author]

Posts