• Global community
    • Language:
      • Deutsch
      • English
      • Español
      • Français
      • Português
  • 日本語コミュニティ
    Dedicated community for Japanese speakers
  • 한국 커뮤니티
    Dedicated community for Korean speakers
Exit
0

Anyone using ZeroBrane for debugging plugins in recent LrC versions?

Participant ,
Apr 15, 2021 Apr 15, 2021

Copy link to clipboard

Copied

I am unable to get the ZeroBrane lua source code debugger up and running. It gives me the same "Could not find namespace: LrMobdebug" message, which many other people reportedly have run into trying to use this tool.

 

I'm aware that VERSION information in Modules\mobdebug.lrmodule\Info.lua is crucial. For the latest LrC version, I'm using the following version numbers, as per Jeffrey Friedl's sysinfo:

local info = {
  AgToolkitIdentifier = "com.zerobrane.lrmobdebug",
  AgExports = { LrMobdebug = "LrMobdebug.lua", },
  VERSION = { major=10, minor=2, revision=0, build=202103041821}
}
return info

 

All posts related to ZeroBrane in this forum are either old <=2018, or related to older LR versions (eg 6). Maybe it doesn't work anymore with recent versions of LrC.

 

Does anybody still use this, with recent LrC versions?

TOPICS
SDK

Views

244

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
LEGEND ,
Apr 15, 2021 Apr 15, 2021

Copy link to clipboard

Copied

I haven't tried ZeroBrane in years, but here's the equivalent Info.lua for my debugging toolkit:

return {
    AgToolkitIdentifier = "com.johnrellis.lrhiddenlua",
    AgExports = {LrHiddenLua = "LrHiddenLua.lua"},
    VERSION = {major = 10, minor = 2}}

 

You might try omitting "revision" and "build".

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
LEGEND ,
Apr 15, 2021 Apr 15, 2021

Copy link to clipboard

Copied

Also, try installing the Debugging Toolkit, which uses the same mechanism for controlling LR. That process may give clues as to what's going wrong with Zerobrane.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Participant ,
Apr 16, 2021 Apr 16, 2021

Copy link to clipboard

Copied

This is too embarrassing... the reason why I got all these "Could not find namespace: LrMobdebug" messages was simply that I missed to restart LrC after installing mobdebug.lrmodule, or at least after modifying its Info.lua file. 

VERSION = { major=10, minor=2 }

is perfectly fine, no need to specify revisions or build numbers.

 

I noticed my error only after installation of your Debugging Toolkit which required me to restart LrC. So in this regard, indeed it helped me to find the root cause why ZeroBrane was not working 🙂

 

Actually, I started debugging using your toolkit. I was feeling a bit uncomfortable to add all the necessary wrappers because I was modifying an existing plugin developed by other people on Github. Plus, I had a problem that after the first breakpoint execution wouldn't stop at further ones. Which is very likely due to insufficient or improper  code instrumentation by me. Finally, it complained about global variables being set, but not initialized before. I didn't know how to handle this. That was the point where I stopped.

 

In this case, ZeroBrane was the better choice for me it was easier to use for me and because the plugin code was already mature (apart from one small portion I had added). If I should ever consider writing something from scratch I will definitely consider your Debugging Toolkit with all its checks. As a person who learned programming in Pascal, Modula-2 and CHILL, these languages which just ignore typos are a real nightmare.

 

Thank you for always being available and supporting, John. Very much appreciate!

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
LEGEND ,
Apr 16, 2021 Apr 16, 2021

Copy link to clipboard

Copied

LATEST

Glad you got it resolved. As you discovered, the debugging toolkit automatically installs the debugging support required for the current version of LR and tells you to restart.   That's not so easy for Zerobrane to accomplish, given the way you attach it to LR.

 

Both Zerobrane and the debugging toolkit require wrappers/enablers in the same number of spots to fully enable breakpoints, single-stepping, stack tracing, and error trapping.  LR's task architecture (built upon the core Lua coroutines) requires that debugging hooks be enabled in each task you want to debug -- thus the wrappers.  The task architecture uses hidden tasks in suprising places, e.g. LrTasks.pcall() (which you should use in preference to the built-in pcall()), LrFunctionContext.callWithContext(), and callbacks from LrView controls. 

 

If you don't insert a wrapper/enabler at a particular spot with either debugger, you won't be able to break, single-step, or get a full stack trace in that task.  In older versions, Lua errors also wouldn't get trapped and displayed, though in the last year or two, Adobe finally enabled error trapping/display for all (or almost all) tasks.  A common confusion in these earlier LR versions was having a Lua error raised in a callback from an LrView control, and the error would be silently ignored and not displayed. 

 

Thus, the debugging toolkit has a blanket instruction to insert wrappers everywhere (you never know where the next bug will strike!).  But you can incrementally insert the wrappers in the sections of code where you likely need them, just as with Zerobrane.

 

"it complained about global variables"

 

That's from the standard Lua tool:

require "strict"

which I'm surprised that the existing code you're working on doesn't use. In my first day or two of plugin development, I didn't know about "strict" and I wasted a huge amount of time on typos.  You can omit "strict" without affecting the rest of the debugging toolkit.

  

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines