Where communities thrive

Join over 1.5M+ people
Join over 100K+ communities
Free without limits
Create your own community

Explore more communities

imagej/imagej-ops

ImageJ Ops: "Write once, run anywhere" image processing

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

juglab forked
juglab/imagej-ops
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

Curtis Rueden

@ctrueden

Are you OK with that for now? If you need PRs to be reviewed and merged this week, I will find a way to make that happen. It will radically alter my focus for the week, but I can do it if you need it. Otherwise, we can block a future week for me to dive into the incubator with you. I don't see a way around doing things that way—it's complex enough that I'll want to make it my primary focus for at least a full week, to be of maximal help.

Gabriel Selzer

@gselzer

Later is fine

The best I can do is to make as many of them sequential as possible

That way we can work through the chain with minimal rebasing

Curtis Rueden

@ctrueden

OK. Would it help to decide on a big "PR merging week" now? Or do you want to wait till you make more progress first? Either way is fine.

Gabriel Selzer

@gselzer

I think there's enough PR stuff there where we can decide on a week now

https://github.com/scijava/incubator/pulls

Curtis Rueden

@ctrueden

I blocked off Tuesday, August 10 - Friday, August 13 in my calendar. I will try to fully focus on the incubator during that time.

Gabriel Selzer

@gselzer

Sounds great!

Curtis Rueden

@ctrueden

Looking forward to it. :smile:

Gabriel Selzer

@gselzer

@ctrueden do you have time to take a look at scijava/incubator@fb4e52d ? For some reason, ProvenanceTest.testAdaptationRecoveryFromString only seems to pass when I run in debug in Eclipse, and not on the CLI/on Eclipse when I run it

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:

Binary progress reporting (i.e. incomplete/complete), for Ops that are unable/unwilling to report progress
Single-pass progress reporting (i.e. you specify nelements in your input, and check them off one by one)
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

Looks like it was added in May 2020: https://github.com/apache/maven-surefire/commit/ed70a5683398f5de55b958e5c8579db89dc7f594#diff-5b8bf215cf3cae58f2561c00010bb9435baed626d8b5dc48067ff441c397d910

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

Chat via Matrix