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
Hah, figured it out :grin:
Curtis Rueden
@ctrueden
Glad to hear! And sorry for not responding sooner.
Gabriel Selzer
@gselzer
Wrote 1e-10 when I meant to write -1e10 :wink:
Curtis Rueden
@ctrueden
:laughing:
Gabriel Selzer
@gselzer
Just a note, I'd like to devise a better plan for delgating between our extensibly-discovered InfoChainGenerators than a priority system...
Actually, it's doable if all OpInfos have some sort of tag that goes in the signature
My current strategy only adds tags for Adaptation, and (in the future) simplification
Gabriel Selzer
@gselzer
@ctrueden just an FYI, I seem to have tackled the beast that is Simplified Op generation from a signature...
:confetti_ball:
Curtis Rueden
@ctrueden
:musical_score: :dancers: :musical_note:
Gabriel Selzer
@gselzer
I want to do more testing (e.g. simplification of an adaptation is next), but looking promising
Gabriel Selzer
@gselzer
@ctrueden (or anyone else) do you have any intuition as to what types of progress reporting "schemes" might be useful to run in ops?
Currently I foresee a couple:
  1. Binary progress reporting (i.e. incomplete/complete), for Ops that are unable/unwilling to report progress
  2. Single-pass progress reporting (i.e. you specify nelements in your input, and check them off one by one)
  3. Multi-pass progress reporting (e.g. running through an image 3 times, performing essentially 2. three times)
Gabriel Selzer
@gselzer
@ctrueden this is new (at least new since the last time I delved into JUnit 5 with JPMS); I've never seen that double module-info.java structure before
Gabriel Selzer
@gselzer
I don't think this is something we'd want to phase into the SciJava ecosystem, right?
Curtis Rueden
@ctrueden
@gselzer Not sure what you mean by "phase into the SciJava ecosystem"... would changes be required to pom-scijava? It looks like your project's module descriptors cover it, no?
Gabriel Selzer
@gselzer
@ctrueden I just meant that it is something we could adopt as Java 11, JUnit 5, JPMS, etc. become involved in more and more SciJava projects

@gselzer Not sure what you mean by "phase into the SciJava ecosystem"... would changes be required to pom-scijava? It looks like your project's module descriptors cover it, no?

No changes would be required to pom-scijava, more talking about the single module-info vs. the double module-info

Curtis Rueden
@ctrueden
Oh, I'm 100% in favor of a double module-info if it's clean and functional, because test scope is a different thing than main scope.
Gabriel Selzer
@gselzer

Oh, I'm 100% in favor of a double module-info if it's clean and functional, because test scope is a different thing than main scope.

Sure, but it requires that there be two differently-named modules, and iirc this requires (it's good practice at least) different package names

Curtis Rueden
@ctrueden
So we move the unit tests to a separate .tests subpackage for each set of unit tests? We can do that I think, no?
It makes it slightly harder to test package-protected things...
Gabriel Selzer
@gselzer
So to test package foo.bar we'd need a package foo.bartest, or foo.bart

So we move the unit tests to a separate .tests subpackage for each set of unit tests? We can do that I think, no?

I could be wrong but I think this is not good enough. foo.bar.test might cause complications if it is not in module foo.bar

Curtis Rueden
@ctrueden
OK, feel free to dig further and make a decision what you think would be best, then. I vote for either: A) dual module-infos if there is a clean design; or B) separate test modules in a Maven multi-module build if not. Because I don't think it's OK to inflict any test-only deps (including junit) onto the main module downstream.
Gabriel Selzer
@gselzer

OK, feel free to dig further and make a decision what you think would be best, then. I vote for either: A) dual module-infos if there is a clean design; or B) separate test modules in a Maven multi-module build if not. Because I don't think it's OK to inflict any test-only deps (including junit) onto the main module downstream.

Well, we can get around test-only dependencies by ensuring they are on the classpath, not the modulepath

This is what we currently do for junit; for SciJava Ops Engine there are currently no test-only dependencies
I agree though, that (A) is the ideal solution
Gabriel Selzer
@gselzer
@ctrueden I cannot decide how strictly I'd like to define what a "tag" is in Discoverer.elementsTaggedWith(String... tags)
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.
Gabriel Selzer
@gselzer

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