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
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.
Gabriel Selzer
@gselzer
Makes sense
karlduderstadt
@karlduderstadt

Bit of a random question. Hope it doesn't distract from the converstaion. But I was wondering is it possible to force imagej-ops to run single threaded?

For example, when running an op using opService.run can I prevent multithreading?

31 replies
karlduderstadt
@karlduderstadt
Screenshot 2021-11-04 at 12.46.10.png
Curtis Rueden
@ctrueden
@gselzer Could you please do a pass over the Road to SciJava Ops project board? I see issues in "To do" that I believe you have now tackled or have WIPs tackling. And there are issues in "In Progress" that are not currently assigned to you or anyone. All issues in "In Progress" should have at least one assignee. You can also drag-and-drop cards in order of priority, so that things at the top get looked at first, and things you feel should be saved till later (December) go more toward the bottom.
2 replies
Gabriel Selzer
@gselzer
@ctrueden I've been thinking, I'm not quite sure that OpEnvironmentFactory implementations, discoverable using ServiceLoader, are the way to go.
Because at the end of the day, you are going to want to choose which of those OpEnvironmentFactory objects you want to use, and that is pretty hard to do if you are getting them through ServiceLoader
5 replies
Curtis Rueden
@ctrueden
Here are slides from a hopefully-not-too-technical overview talk I gave today about SciJava Ops / ImageJ Ops 2.
Jean-Yves Tinevez
@tinevez
:plus1: Excellent!
John Bogovic
@bogovicj
nice!
Curtis Rueden
@ctrueden
Hey @gselzer! Remember how you said ops weren't being properly initialized in napari-imagej, even though they implement Initializable? I think the reason is that there are two Initializable interfaces: one in scijava-common and one in imagej-ops. See imagej/imagej-ops#455
7 replies
Gabriel Selzer
@gselzer
@ctrueden at this point the incubator is nearly free from SJC. Unfortunately, DefaultEquation still depends on ScriptService...we might have to migrate that next week
11 replies
Gabriel Selzer
@gselzer
@hinerm @ctrueden I'm starting to prototype a fix to #643. Any opinions?
4 replies