Skip to main content
L
LoweMo_photo
Participating Frequently
December 3, 2016
Question

Getting yield errors when attempting require of debugscript

  • December 3, 2016
  • 2 replies
  • 3415 views

I've been using johnrellis​'s excellent Debugging Toolkit (debugscript) to help improve my Lightroom plugin development flow. It's been useful in a couple of plugins I've worked on, but in one particular project I've been collaborating on, if even all I do is include the "require lines", the plugin fails to operate properly and I find the following in the Plugin Manager error log:

**** Error 1
An error occurred while attempting to run one of the plug-in’s scripts.
attempt to yield across metamethod/C-call boundary
**** Error 2
Could not load the post-processing filter from this plug-in.
attempt to yield across metamethod/C-call boundary

I initially had tried wrapping all the (documentation-hinted) functions in the Debug.showErrors() calls and thought I must have made a mistake somewhere when I found the plugin wasn't working. So I reverted my changes and found things working again; at least things which I wanted to debug were working in their buggy state. (Now I think it's getting near perfection.) It wasn't till later that I found that trying to include the debugscript, even for simple things like a call to Debug.lognpp(), would fail (even before making any calls to its functionality.

I wonder if anyone else has seen this error. To replicate it, simply check out the project and uncomment the require lines (currently only in a couple of the files (e.g. in DialogTagging.lua😞

local Require = require 'Require'.path ("../debugscript.lrdevplugin")
local Debug = require 'Debug'.init ()
require 'strict'

And, well, you would also need to create a free developer account on Clarifai.com and follow the installation/config to be able to attempt to run the script, but I promise that it will be worth the effort if you want a really cool keywording tool, integrated into Lightroom. I'd just love to be able to use the Debugging Toolkit with it and have no idea what would cause this kind of error. I searched and there are not any explicit calls to yield, so it must be some Lightroom quirk, but there is likely a workaround for our use (I hope)...

Happy to hear any kind of response.

This topic has been closed for replies.

2 replies

D
DFBurns
Inspiring
December 9, 2016

For what it's worth, I came here to post the same question and found yours. I'm having the same issue. I decided to ditch my homegrown logging and move wholesale to John's debugging library. Now, my export plugin's dialog works fine but I get an error from Lightroom that "Could not load the post-processing filter from this plugin. Attempt to yield across ... blah blah."

(One odd thing is that Lightroom proceeds with some built-in process because it goes ahead and exports a JPEG of the selected image.)

Any strategies for figuring this out? This used to work fine before changing over to John's library so I thought I had all the tasks and contexts worked out but maybe I was lucky all along?

db

johnrellis
johnrellis
Legend
December 11, 2016

I've personally never used the Debugging Toolkit with a full-blown export plugin.  (Some of my plugins do exports internally, though.)  But I've used the toolkit extensively with all sorts of async tasks and SDK API calls that require such tasks.

One easy thing to try: Try renaming the plugin folder from myplugin.lrdevplugin to myplugin.lrplugin.  That will automatically disable Debug without needing to edit the code.  Do you still get the "attempt to yield across metamethod/C-call boundary"

I'm wondering if the problem has something to do with Debug.showErrors ().  When Debug is disabled, showErrors(func) uses LR's recommended method for ensuring errors are displayed:

    return function (...)
        return LrFunctionContext.callWithContext("wrapped", 
            function (context)
                LrDialogs.attachErrorDialogToFunctionContext (context)
                return func (unpack (arg))
                end)

But when debugging is enabled, showErrors (func) uses pcall () or LrTasks.pcall (), depending on whether the code is running on a task created by LrTasks.startAsyncTask() or is on the main task.  If you try to call an API function that yields internally within pcall (), you'll get the "attempt to yield across metamethod/C-call boundary" error. 

I don't have any hypothesis yet why showErrors() might be causing problems. 

D
DFBurns
Inspiring
December 12, 2016

Also, it's unfortunate that the LR SDK doesn't allow us to trap errors before it unwinds the stack, so you can see the stack as it exists when the error occurs, rather than after it is unwound to LR's error handler or Debug's error handler, which are usually near the bottom of the stack.

Lua provides xpcall() for such trapping, but it isn't available via the SDK; I've hacked LR to allow Debug to access xpcall(), but it doesn't work with LR's tasks.   LR appears to have something internally called coxpcall(), but I haven't figured out how to use it with plugins.  I don't think the ZeroBrane LR debugger has solved the problem either, but I might be wrong.


Amen to that. I've been writing software for 30 years and Lightroom is one of the least developer-friendly environments I've ever worked in.

johnrellis
johnrellis
Legend
December 3, 2016
attempt to yield across metamethod/C-call boundary

That error occurs when you call an API call that needs to be executed in a task started by LrTasks, e.g. photo:getDevelopSettings().

L
LoweMo_photoAuthor
Participating Frequently
December 3, 2016

Thank you, johnrellis. I'm sure there must be something like that. Strange that the error only occurs if the debugscript is included, though... but I'll do further investigation to see if there might be such a task that I've missed.

I don't think anything like that is in the parts I've contributed, since I've paid careful attention to that, but I did find something along those lines (a call to LrHttp.post() that needed to be within an LrFunctionContext.postAsyncTaskWithContext function block). So far, no changes I've tried have resolved this issue, though.

Terms & ConditionsAccessibility statement
Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices