Debugging tips for Lightroom plugins

  • 1
  • Question
  • Updated 6 years ago
I'm developing a plugin and am having trouble using the photo:getdevelopsettings function.
Calling the function is resulting in a popup box showing up with the error message 'Assertion Failed!'
I'm not getting any errors to any logs that are more descriptive (one to the console that says, "Oops! An untagged string (assertion failed!) got thrown far enough that we display it to the user. This shouldn't happen.")

I'm on a mac running LR version 4.0.
I would love to know of somewhere with tips on debugging these kind of plugin errors and errors in general.

Any help is greatly appreciated.

Thanks!
Sean
Photo of Sean Gubelman

Sean Gubelman

  • 5 Posts
  • 0 Reply Likes
  • anxious

Posted 6 years ago

  • 1
Photo of John R. Ellis

John R. Ellis, Champion

  • 3893 Posts
  • 1034 Reply Likes
Unfortunately, Adobe disabled most of the Lua debugging hooks, so debugging is painful. However, if you haven't already, you might look at the LR Debugging Toolkit

http://www.johnrellis.com/lightroom/d...

It makes it much easier to set "breakpoints" and examine arbitrary data structures interactively.

Re the assertion failed, that sounds like a bug in LR that might be triggered by invalid arguments and/or not calling photo:getDevelopSettings() from a task started by LrTask. In general, the SDK is reasonably consistent about generating more informative error messages. Insert a "breakpoint" right before:

Debug.pause (photo, ...any other values you'd like to examine...)
Photo of jdv

jdv, Champion

  • 728 Posts
  • 56 Reply Likes
If you want more descriptive logging at critical parts, you are going to have to do it yourself via LrLogger.

As for debugging frameworks, some folks have released tools that can help you with Lr development. See here for some references to them: http://www.assembla.com/spaces/lrdevp...
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 385 Reply Likes
Note: Lr namespace functions are case sensitive.

Also, calling using a colon vs. dot is a common oops.

And, if you do LrDialogs.message( tostring( photo ) ) it should indicate if you're working with a proper LrPhoto.

Post exact code and we may be able to spot the immediate problem straight away.

-R
Photo of Sean Gubelman

Sean Gubelman

  • 5 Posts
  • 0 Reply Likes
Thanks for the tips, guys!

Here's the code

------------
local LrApplication = import 'LrApplication'
local settingsKeys = require('DevelopSettingKeys')

local currCatalog = LrApplication.activeCatalog()

local currPhoto = currCatalog:getTargetPhoto()

local LrTasks = import 'LrTasks'

function doStuff ()

currCatalog:withWriteAccessDo( "stuff", function ()

logging:log("getting settings")

local developSettings = currPhoto.getDevelopSettings()

logging:log("printing settings")

logging:log(tostring(developSettings[settingsKeys.Exposure]))

logging:log("printing settings complete")

end, {timeout = 5, callback = function()
logging:log("done")
end } )

end

LrTasks.startAsyncTask(doStuff, "stuff")
--------------

last log that is printed out is "getting settings". The whole thing is run as a menu item.
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 385 Reply Likes
You need to call currPhoto:getDevelopSettings() with a colon, not a dot.

PS - When I get "assertion failed" when calling an Lr function, 9 times out of 10 that's the reason ;-} (9 of the other 10% is other forms of bad parameter(s)).

(colon means: pass object to left of colon as first parameter to function call at right of colon - accessible in function as "self")

R
Photo of Sean Gubelman

Sean Gubelman

  • 5 Posts
  • 0 Reply Likes
Is this specified in the documentation? Where do I find out which functions require it and not? Is it guess and check? :P
Photo of Sean Gubelman

Sean Gubelman

  • 5 Posts
  • 0 Reply Likes
Never mind it's in the documentation in the declaration of the functions. Just didn't notice it before -- Just assumed that the dot vs. colon was a instance vs. static method thing.
Photo of Sean Gubelman

Sean Gubelman

  • 5 Posts
  • 0 Reply Likes
Looked a bit closer at the : operator in lua, and it all makes sense now. :)