built ins

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

built ins

Brian Northan
Hi everyone

Just noticed that built-ins were added recently.

https://github.com/imagej/imagej-ops/pull/145

Is there documentation anywhere on how to update the built-ins after updating the signature of an op?? 

Mainly I'm wondering if there is any scripts or automated code generation steps to perform??

If it is just a matter of updating the signatures manually I can figure out how to do that.  Just want to make I don't miss an automated step I should be running.

Thanks

Brian

_______________________________________________
ImageJ-devel mailing list
[hidden email]
http://imagej.net/mailman/listinfo/imagej-devel
Reply | Threaded
Open this post in threaded view
|

Re: built ins

Curtis Rueden
Hi Brian,

> Is there documentation anywhere on how to update the built-ins after
> updating the signature of an op??  

Not yet. We can make a wiki page. The other thing missing is a top-level "built-ins completeness test" to make sure that all built-ins are actually present and being tested for. (Right now, each unit tests covers a specific op name, but there is no test that verifies all op names are being tested.)

Due to limitations in generic type matching (as described at https://github.com/imagej/imagej-ops/issues/19), we were not able to fully automate generation of the built-in methods. So unfortunately they must be added manually. But there is a significant unit testing infrastructure that tries hard to verify everything matches.

Here's a quick rundown:

1A) If you add a new concrete op implementation for an existing op name, then the existing built-in test method will pick it up.

1B) Or if the implementation corresponds to a new name foo, you can add the completeness test by adding a new testFoo() method to the appropriate namespace test class (e.g., MathNamespaceTest for math, LogicNamespaceTest for logic, or GlobalNamespaceTest for methods in the OpService itself).

2) The unit test will notice that your new op does not have corresponding built-in method signature(s), and spit out a detailed error message suggesting the method bodies to be added. The method bodies are pretty close to correct except for they are missing generic parameters. So you must tweak the argument types by hand to make the generics match the fields of the concrete op implementation.

3) Then just paste the method body into the appropriate namespace class (e.g., MathNamespace for math, LogicNamespace for logic, or OpService and DefaultOpService for global. Then the relevant completeness test should pass again.

4) If multiple ops have clashing signatures, you can make a single built-in method with an @OpMethod annotation the specifies multiple concrete op classes in its "ops" attribute. Method parameters and return type must then use the most common compatible superclass of all involved ops.

Let me know if any of that needs clarification; happy to elaborate further, and point out specific examples as needed.

Regards,
Curtis

On Mon, Jun 29, 2015 at 9:21 AM, Brian Northan <[hidden email]> wrote:
Hi everyone

Just noticed that built-ins were added recently.

https://github.com/imagej/imagej-ops/pull/145

Is there documentation anywhere on how to update the built-ins after updating the signature of an op?? 

Mainly I'm wondering if there is any scripts or automated code generation steps to perform??

If it is just a matter of updating the signatures manually I can figure out how to do that.  Just want to make I don't miss an automated step I should be running.

Thanks

Brian

_______________________________________________
ImageJ-devel mailing list
[hidden email]
http://imagej.net/mailman/listinfo/imagej-devel



_______________________________________________
ImageJ-devel mailing list
[hidden email]
http://imagej.net/mailman/listinfo/imagej-devel
Reply | Threaded
Open this post in threaded view
|

Re: built ins

Brian Northan
Thanks Curtis

I was able to get it working.  The error message from the unit test were very helpful.  I'll let you know if any issues come up. 

Brian

On Mon, Jun 29, 2015 at 2:49 PM, Curtis Rueden <[hidden email]> wrote:
Hi Brian,

> Is there documentation anywhere on how to update the built-ins after
> updating the signature of an op??  

Not yet. We can make a wiki page. The other thing missing is a top-level "built-ins completeness test" to make sure that all built-ins are actually present and being tested for. (Right now, each unit tests covers a specific op name, but there is no test that verifies all op names are being tested.)

Due to limitations in generic type matching (as described at https://github.com/imagej/imagej-ops/issues/19), we were not able to fully automate generation of the built-in methods. So unfortunately they must be added manually. But there is a significant unit testing infrastructure that tries hard to verify everything matches.

Here's a quick rundown:

1A) If you add a new concrete op implementation for an existing op name, then the existing built-in test method will pick it up.

1B) Or if the implementation corresponds to a new name foo, you can add the completeness test by adding a new testFoo() method to the appropriate namespace test class (e.g., MathNamespaceTest for math, LogicNamespaceTest for logic, or GlobalNamespaceTest for methods in the OpService itself).

2) The unit test will notice that your new op does not have corresponding built-in method signature(s), and spit out a detailed error message suggesting the method bodies to be added. The method bodies are pretty close to correct except for they are missing generic parameters. So you must tweak the argument types by hand to make the generics match the fields of the concrete op implementation.

3) Then just paste the method body into the appropriate namespace class (e.g., MathNamespace for math, LogicNamespace for logic, or OpService and DefaultOpService for global. Then the relevant completeness test should pass again.

4) If multiple ops have clashing signatures, you can make a single built-in method with an @OpMethod annotation the specifies multiple concrete op classes in its "ops" attribute. Method parameters and return type must then use the most common compatible superclass of all involved ops.

Let me know if any of that needs clarification; happy to elaborate further, and point out specific examples as needed.

Regards,
Curtis

On Mon, Jun 29, 2015 at 9:21 AM, Brian Northan <[hidden email]> wrote:
Hi everyone

Just noticed that built-ins were added recently.

https://github.com/imagej/imagej-ops/pull/145

Is there documentation anywhere on how to update the built-ins after updating the signature of an op?? 

Mainly I'm wondering if there is any scripts or automated code generation steps to perform??

If it is just a matter of updating the signatures manually I can figure out how to do that.  Just want to make I don't miss an automated step I should be running.

Thanks

Brian

_______________________________________________
ImageJ-devel mailing list
[hidden email]
http://imagej.net/mailman/listinfo/imagej-devel




_______________________________________________
ImageJ-devel mailing list
[hidden email]
http://imagej.net/mailman/listinfo/imagej-devel