Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Gabriel Selzer
    @gselzer
    I'm just going to leave it the way it is
    Curtis Rueden
    @ctrueden
    Sounds good.
    Giuseppe Barbieri
    @elect86
    today I saw this and immediately though at when you, Curtis, told me that the community is kind of hating Java. If you got something light to do, you can hear it in background
    Gabriel Selzer
    @gselzer
    @ctrueden so I think that I am nearly to a state that builds in the discoverer refactoring
    The remaining question is how we should give Ops/OpCollections to the StaticDiscoverer in tests
    We currently give them classes, but the Discoverers are supposed to give a list of instances
    Gabriel Selzer
    @gselzer
    @ctrueden my goal today is to try and purge SciJava Common, finally
    Starting with SciJava Types, we have this NilConverter
    I think we either:
    1. Delete the NilConverter
    2. Introduce SciJava Converter2 to the incubator
    Any opinions?
    (Additionally, Types depends on org.scijava.util.MiscUtils.compare, but I'm just going to figure out how to get the same functionality without that dependency)
    Curtis Rueden
    @ctrueden
    Get rid of the nil converter, I think. Ops doesn't need it, right?
    Gabriel Selzer
    @gselzer
    No
    Curtis Rueden
    @ctrueden
    We can put that converter in a different module downstream, if/when the need arises.
    Gabriel Selzer
    @gselzer
    :+1:
    Gabriel Selzer
    @gselzer
    Hmm, there's also a bunch of uses of FileUtils in TypesTest.
    Gabriel Selzer
    @gselzer
    @ctrueden created SciJava Common3
    Currently it only has Validated, ValidityProblem, and ValidityException in the org.scijava.common3.validity package
    Debating adding Priority to that as well
    Any opinions on Priority?
    5 replies
    Curtis Rueden
    @ctrueden
    @gselzer I'm curious if you ever read the dev.java/learn tutorials, e.g. decoupling modules with services. I'm going to check them out this week.
    5 replies
    Gabriel Selzer
    @gselzer
    @ctrueden any opinions on where VersionUtils lives in Scijava 3? For now I'm going to put it in SJC3
    Although it uses POM and Manifest (and by extension Versioned), which live in the package org.scijava.util...
    5 replies
    Gabriel Selzer
    @gselzer
    Also, for now I am going to make a scijava-priority module. I don't think it needs to be scijava-priority2, because there is no org.scijava.priority package. Happy to discuss this choice if you want
    1 reply
    Gabriel Selzer
    @gselzer

    @ctrueden my goal today is to try and purge SciJava Common, finally

    To this end, I am also going to delete PluginBasedClassOpInfoGenerator :wave:

    1 reply
    I cannot decide where it should live, personally. We can always recover it if we decide that we need it at a later date
    Gabriel Selzer
    @gselzer

    Although it uses POM and Manifest (and by extension Versioned), which live in the package org.scijava.util...

    I'm going to start moving this stuff into SJC3 so that I can make progress on Ops, but I want to have a discussion about everything I move into there

    Gabriel Selzer
    @gselzer
    In case anyone else finds this interesting, IntelliJ was giving me warnings for many of my StringBuilder.append() calls that included some String variable. What might be better known is that String concatenation with variables uses new StringBuilder().append(s1)...append(sN).toString()uner the hood. What I learned was that chaining calls are heavily optimized over sequential calls.
    It's cool that IntelliJ will notify you of that.
    Gabriel Selzer
    @gselzer
    @ctrueden any opinions on where MersenneTwisterFast lives in SciJava 3?
    ImageJ Ops2 wants to use it
    We could either put it in SJC3, or we could make a SciJava Random module
    Gabriel Selzer
    @gselzer
    I'm also migrating over ThreadService as a new interface ThreadManager. Disposable is also going to come over, so I can clean up ThreadManager.
    Curtis Rueden
    @ctrueden
    For ImageJ Ops2, did you test with java.util.Random instead of MersenneTwisterFast? Is Random still a lot slower?
    I only want to migrate the Mersenne twister if the performance gain is still big.
    And if we do migrate it, I think scijava-common should be an OK place, sure.
    Gabriel Selzer
    @gselzer

    For ImageJ Ops2, did you test with java.util.Random instead of MersenneTwisterFast? Is Random still a lot slower?

    Not yet. I am trying to clean up the compile errors

    Gabriel Selzer
    @gselzer
    @ctrueden I'm looking around for a new incubator issue to work on
    What do you think about scijava/scijava#55
    Curtis Rueden
    @ctrueden
    Do we need an application container right now?
    I don't think we're ready to start mass porting SJC2 services over. scijava/scijava#55 would start us down that road, but I don't think we need it for publication. Is that issue currently on the project board? We might be able to kick it.
    Gabriel Selzer
    @gselzer
    It's on the project board, with a 1.0.0 target
    Curtis Rueden
    @ctrueden
    Are you OK with kicking it to unscheduled? Or do you think we need to address it now?
    Gabriel Selzer
    @gselzer
    I think the Discovery abstraction will allow us to address it later
    As far as Ops goes
    Curtis Rueden
    @ctrueden
    OK, I kicked it to unscheduled.
    Gabriel Selzer
    @gselzer
    :+1:
    Curtis Rueden
    @ctrueden
    I think the most urgent issue is scijava/scijava#56
    Did you ever complete a working prototype of an imglib2-algorithm fork declaring ops using the javadoc annotation mechanism?
    If not, now is the time.