ctrueden
commented
5 years ago This is a problem with method dispatch from scripting. When you call ops.image().equation(...), the script language looks at the method arguments of the ImageNamespace#equation methods, and tries to do a best match based on what was actually passed.
In the case of Groovy, the expression {x,y -> x+y} is an instance of a dynamically generated class like Script16$_run_closure1, which is then (amazingly!) correctly coerced into a java.util.function.BinaryDoubleOperator. But when you use ops.run(...), Groovy has no way to know that the closure object should be coerced to anything else—it simply gets added as an element of the Object[] passed to run. And then there is no SciJava converter that knows anything about Groovy closures. But there is a SciJava converter that converts the closure to a String—and since there is an equation op that accepts String, that one gets matched by the op matcher! 😆 Hence the bizarre error: Nashorn is trying to parse the stringified Groovy closure (Script78$_run_closure1@500de58;;). I find this so entertaining it warrants a second emoji: 😂
A fix is to instead write:
ops.run("image.equation", ops.run("create.img", [200, 100]), {x,y -> x+y} as java.util.function.DoubleBinaryOperator)The problem in Python is very likely the same issue.
The
image.equationops throw exceptions when trying to use them from scripting via theops.run("image.equation", ...)signature, whereas calling them viaops.image().equation(...)works just fine.In Groovy:
Exception
```text [WARNING] null javax.script.ScriptException:In Python:
Exception
```text [WARNING] null javax.script.ScriptException: