Try using LrTasks.pcall() instead of the standard Lua pcall().
afraid not. Same thing exactly. It's beginning to look like a bug, I think.
I assume, running into a syntax error stops execution of the script. So the line with assert will not be reached.
No. The line "local f = assert( loadstring( code ) )" runs and I get a log from the first Debug.logn line. It's the second Debug.logn that it never gets to.It's dying somewhere in f().
Changing it to assert( f() ) doesn't work. Neither does add pcall().
It's dying somewhere in f().
Oh, I misunderstood that. So the compilation of the string by loadstring() is succeeding, it's the execution of the resulting function that's failing. To avoid further ambiguity, when you invoke f() with exactly the following lines:
local success, result = LrTasks.pcall (f)
Debug.logn ("pcall", success)
What happens? Note that a common mistake, which I've made a number of times, is to use pcall like this: LrTasks.pcall (f()). That will have no effect.
That did it. Yes, I was using pcall( f() ). Which in hindsight was pretty dumb.
Now I'm getting some error messages back and I can actually debug my code
Thanks for your help, John. Appreciated.
One other thing occurred to me: When an error occurs in many of the callback functions a plugin passes to the SDK API, the error is by default silently ignored. I can never remember for which callbacks this happens, so I make it a habit to wrap all callbacks with Debug.showErrors. E.g.
onMessage = Debug.showErrors (function (socket, message
I think it's a pretty good bet that it you do this, then you won't need the pcall(). I didn't notice this originally, because I wasn't very familiar with LrSocket.