Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jan 28 2019 15:58
    bnorthan commented #557
  • Jan 25 2019 16:27
    gselzer commented #557
  • Jan 25 2019 08:37
    imagejan commented #592
  • Jan 25 2019 03:11
    HorizonP edited #592
  • Jan 25 2019 03:10
    HorizonP opened #592
  • Jan 22 2019 17:30
    ctrueden commented #591
  • Jan 22 2019 17:26
    haesleinhuepf edited #591
  • Jan 22 2019 17:19
    haesleinhuepf opened #591
  • Jan 21 2019 20:21
    dariomel edited #590
  • Jan 21 2019 20:20
    dariomel opened #590
  • Jan 21 2019 12:56
    bnorthan commented #557
  • Jan 21 2019 09:33
  • Jan 20 2019 14:05
    bnorthan commented #557
  • Jan 18 2019 22:53
    gselzer commented #557
  • Jan 18 2019 22:53
    gselzer commented #557
  • Jan 18 2019 20:12
    bnorthan commented #557
  • Jan 18 2019 19:50
    gselzer synchronize #557
  • Jan 18 2019 19:50

    gselzer on sharpen-smooth

    Add DefaultSmooth and DefaultSh… Preserve differentiation in sum… Rely on helper Ops to decrease … and 1 more (compare)

  • Jan 18 2019 19:14
    gselzer commented #557
  • Jan 18 2019 18:54
    gselzer synchronize #557
Gabriel Selzer
@gselzer
Because at the end of the day, we want this method to return a List<Discovery<AnnotatedElement>>, and how we define that Discovery depends on how we define the tags, I think
For example, the Discovery has to have a name, and that's tough to determine without a strict tag definition (but it's also a problem with taking a String... tags vs. a String tag. I'm tempted to refactor the method to only take a single tag
And I'd like to define a tag as a (tagType, name, body) pair that can be formulated in any way.

I'm temped to refactor the method to only take a single tag

Fwiw if a user wanted to check for multiple tags, they can just take the intersection of multiple lists...

Curtis Rueden
@ctrueden
I'm fine with only one tag requested per method call.
I don't understand the (tagType, name, body) idea, though. Could you elaborate on that?
Gabriel Selzer
@gselzer

I don't understand the (tagType, name, body) idea, though. Could you elaborate on that?

I refined this idea over Friday

The idea is that tags should be formatted @implNote <tagType> <options>
For example, you might see @implNote op names=foo.bar,foo.baz
Curtis Rueden
@ctrueden
Cool. Please use Parsington for the options syntax. See #@ parameter syntax for inspiration and code.
org.scijava.script.process.ParameterScriptProcessor
Which leans on the org.scijava.parse.DefaultParseService.
You can lift the org.scijava.parse package wholesale from SJC2 and put it in the incubator if you like, making any needed changes. The parsington dependency is isolated there.
Gabriel Selzer
@gselzer
Sure, would you like a module scijava-parse?
Curtis Rueden
@ctrueden
Yeah, that would make sense.
Gabriel Selzer
@gselzer
:+1:
Curtis Rueden
@ctrueden
I don't love the package prefixes org.scijava.parsington versus org.scijava.parse—if you have a better suggestion I'm interested, but if not then those names are serviceable enough.
There is still a question whether we are going to inject the incarnation of everything prior to releasing anything. E.g. org.scijava.v3.parse instead of org.scijava.parse. I think we will want to do it, even though it's ugly, because it will give us a lot more power later to redo APIs as needed without breaking everything.
Gabriel Selzer
@gselzer

There is still a question whether we are going to inject the incarnation of everything prior to releasing anything. E.g. org.scijava.v3.parse instead of org.scijava.parse. I think we will want to do it, even though it's ugly, because it will give us a lot more power later to redo APIs as needed without breaking everything.

Oops, I forgot to respond to this

@ctrueden I am in agreement that the vX incarnation is probably the right decision
But it might seem strange if org.scijava.v3.parse is part of the same "generation" as org.scijava.ops.engine, org.scijava.discovery, etc.
Is there a convention for v3 coming between the group and artifact names? Because org.scijava.parse.v3 might look better
Gabriel Selzer
@gselzer
Or, since the idea is that these modules combine to form SciJava V3, maybe every SciJava module should be org.scijava.v3.____ (e.g. org.scijava.v3.ops.engine)
I think it just comes down to whether the version emphasis should be on SciJava, or on each component (i.e. Parse)
Curtis Rueden
@ctrueden
I think all the scijava core stuff will share the same v number.
So we won't have org.scijava.ops at all... only org.scijava.v3.ops. We could start at v1 though if you prefer. I don't feel strongly.
Otherwise, as soon as we want to iterate on the core scijava platform again (ha ha, hopefully never, but you know... might need to break some API later)... we go from org.scijava.ops :arrow_right: org.scijava.ops.v2, which is weird... I'd rather go from v1 to v2, or even v3 to v4.
And obnoxiously, the artifactIds also need to incorporate that... so e.g. scijava-v3-ops, scijava-v3-parse, and so on.
We could even name the repo scijava/scijava-v3 instead of scijava/scijava, although I favor the latter at the moment.
Gabriel Selzer
@gselzer

Otherwise, as soon as we want to iterate on the core scijava platform again (ha ha, hopefully never, but you know... might need to break some API later)... we go from org.scijava.ops :arrow_right: org.scijava.ops.v2, which is weird... I'd rather go from v1 to v2, or even v3 to v4.

Does this scheme allow us to iterate on a particular component? Do you see us ever wanting to?

Curtis Rueden
@ctrueden
No, not if we are monoversioning scijava core. If we want to break out only a single component, it would move to its own repository like e.g. parsington.
Gabriel Selzer
@gselzer
Hmm, alright
Curtis Rueden
@ctrueden
Oh...
I just checked the doc where this is written up, and the thinking had evolved past what I'm saying above.
org.scijava.ops2 :arrow_right: org.scijava.ops3.
I forgot about that, sorry...
This is the equivalent of org.scijava.v2.ops :arrow_right: org.scijava.v3.ops
And then the artifacts are named scijava-ops2 and scijava-ops3 respectively.
I think we decided to do it this way because it still addresses the same issue (class name clashes across major versions), but is more in line with how popular OSS projects like Apache Commons do things.
But we do still need to decide how to name the packages being pulled out of SJC2, then.
E.g. since org.scijava.parse is taken, we have to call it org.scijava.parse2, with artifactId scijava-parse2.
And since we want to do monoversioning of core scijava components now... are we going to allow heterogeneous generation numbers?
The monoversioning doc is here but it's pretty barebones right now.
Gabriel Selzer
@gselzer
@ctrueden any naming preferences for our Explicitly-defined Op Environment?
I suppose the central idea is that this OpEnvironment will do no discovery...
BasicOpEnvironment?
Gabriel Selzer
@gselzer
LimitedOpEnvironment?
Curtis Rueden
@ctrueden
Sorry, I don't have a strong enough idea for how this op environment differs from a vanilla one.
If anything, I'd say the basic one should be DefaultOpEnvironment or BaseOpEnvironment, and then the fancy one should extend it? But it depends what functionality each one brings to the table.