You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This PR adds in the autogenerated tests made for ImageJ Ops by @awalter17, massaged to work on ImageJ Ops2. This PR also massages/eliminates some create Ops to this end, to try and coalesce all Ops under the singular create namespace.
Points of discussion for the reviewers:
These tests call the Ops as functions, but the Ops are written as Computer.Arity1s (this is slick for whole-image conversion). Unfortunately, for single-type conversion, though, this is tricky to match - you can't write ops.unary("convert.float64").input(myByte).apply(), because adaptation will fail*. As a result I've added .outType calls, however I think it looks unnecessarily clunky. The only other alternative I could think of, though, would be to have both a Computer and a Function implementation for all convert Ops, which defeats the purpose of adaptation ☹️
Note that the first commit will fail the build because I did not solve the matching problems in the test until the second commit - we should squash the two commits before merging.
* fails because the standard Function --> Computers.Arity1 adaptors look for either a Function<ByteType, Object> or a Producer<Object>, which in the former case fails because a matched dependency makes the adaptation fail, and in the latter fails because there are multiple matches.
The only other alternative I could think of, though, would be to have both a Computer and a Function implementation for all convert Ops, which defeats the purpose of adaptation
The only other alternative I could think of, though, would be to have both a Computer and a Function implementation for all convert Ops, which defeats the purpose of adaptation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR adds in the autogenerated tests made for ImageJ Ops by @awalter17, massaged to work on ImageJ Ops2. This PR also massages/eliminates some
createOps to this end, to try and coalesce all Ops under the singularcreatenamespace.Points of discussion for the reviewers:
Computer.Arity1s (this is slick for whole-image conversion). Unfortunately, for single-type conversion, though, this is tricky to match - you can't writeops.unary("convert.float64").input(myByte).apply(), because adaptation will fail*. As a result I've added.outTypecalls, however I think it looks unnecessarily clunky. The only other alternative I could think of, though, would be to have both aComputerand aFunctionimplementation for allconvertOps, which defeats the purpose of adaptation* fails because the standard
Function-->Computers.Arity1adaptors look for either aFunction<ByteType, Object>or aProducer<Object>, which in the former case fails because a matched dependency makes the adaptation fail, and in the latter fails because there are multiple matches.Closes scijava/scijava#112