[ImageJ-devel] 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 <ctrueden at wisc.edu> 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 <bnorthan at gmail.com> 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
>> ImageJ-devel at imagej.net
>> http://imagej.net/mailman/listinfo/imagej-devel
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://imagej.net/pipermail/imagej-devel/attachments/20150630/4ec9432e/attachment.html>