Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Hadrien Mary
    @hadim
    @ctrueden I agree Scijava native libs should be minimized but some special cases are definitively worth it. For example, @bnorthan wrapper around YacuDecu looks very promising. It's close to achieve real-time deconvolution.
    Brian Northan
    @bnorthan
    @hadim the reason ops-experiments has so many dependencies, is because I want to be able to benchmark various libraries against each other, so that you can test if a native library has a clear benefit, before going to the trouble of integrating it with something else.
    In the near future I want to benchmark the pure Cuda version of RL-deconvolution, against an MKL-version, against your hybrid DL2 version, and against a version using JTransforms.
    It's pretty obvious, for smaller datasets the CUDA version is way faster. However RL-deconvolution needs 4 or 5 copies of the image buffer, so you can't run the entire image on a GPU for volumes much larger than 2 gigs.
    Hadrien Mary
    @hadim
    I see.
    Brian Northan
    @bnorthan
    So I want to know, if your better off using MKL, a hybrid Cuda/java version, JTransforms or using a subvoluming scheme.
    Anyway, thanks to your contributions the last couple of days, we've pretty much got the native part integrated into the build.
    Brian Northan
    @bnorthan
    @hadim after more testing I ran into some runtime link errors. Right now the only way I can get the YacuDecu wrapper to run in Linux is using a Makefile instead of CMake
    Have you confirmed that your build setup, using CMake works at runtime?? Either way I'm still pretty happy with where we are. Thanks again for setting up the cppbuild stuff. That was really helpful. Even though I couldn't get CMake to work, I can just call make from cppbuild.sh and that works fine,
    Hadrien Mary
    @hadim
    @bnorthan: I just retested the .so lib generate by CMake and it does not work... I guess I've mixed libs during my earlier tests. As long as it works with the Makefile, I guess it's fine. I think the most important is the cppbuild.sh system that make the entire build flexible and easily adaptable to work on various machines + various CI.
    Jan Eglinger
    @imagejan
    @ctrueden is there a specific reason you updated some projects to pom-scijava 19.1.1 and not to latest 19.2.0 right away?
    Curtis Rueden
    @ctrueden
    Because I forgot 19.2.0 existed.
    The updates were in response to melting-pot errors I found testing locally.
    Jan Eglinger
    @imagejan
    :) ok, great, I thought I had missed something
    Curtis Rueden
    @ctrueden
    @imagejan and anyone else interested: do you have a few minutes to read some ramblings here about my imminent work on scijava-common?
    Curtis Rueden
    @ctrueden
    I started modularizing scijava-common into many smaller component artifacts this past December, and I need to continue that work, but I have been nervous about completely breaking the ecosystem in the process. I have a rough plan on how to proceed, but it would be nice to validate externally that I am not insane.
    Stefan Helfrich
    @stelfrich
    (That’s a continuation of your post on the forum?)
    Jan Eglinger
    @imagejan
    I'll jump on the train in a few minutes, but will likely have time to read during travel.
    Curtis Rueden
    @ctrueden
    (It's a community! Lots of rubber ducks! :-) )
    @stelfrich Not precisely a continuation, although some of that post may be relevant here.
    That post was about classloader shenanigans, to account for breaking changes. This rambling is about those actual breaking changes and how to develop them.
    Stefan Helfrich
    @stelfrich
    Alright! I have about 30mins and am a bit slow today.. so I hope you don’t expect an immediate response
    Curtis Rueden
    @ctrueden
    I considered whether to start a new repository, or keep working in scijava-common, and I tentatively think:
    • I need to keep working in scijava-common
    • On a branch for the shortest possible amount of time, which merges to master ASAP
    • Which updates the version to 3.0.0-alpha-1-SNAPSHOT
    • Which divides all the code into submodules, initially one huge unsorted module and then as I tease things out, into more modules, until unsorted is empty
    This preserves the git history, and lets git log --follow work on individual files.
    • Add a common submodule that aggregates scijava-common from all the component JARs so that we still have a single JAR file during the transition
    • The individual new modules are all versioned at 0.1.0-SNAPSHOT
    • Once all new modules have stabilized, they can be split out into their own Git repositories, each with its own copy of the Git history of scijava-common.
    This has the advantages of preserving the entire git history of all code in all cases. But the disadvantage of creating a lot of copies of things.
    I am wondering whether you guys think this is a stupid plan, or an OK plan.
    I hate having a temporary multi-module Maven project, but it is so convenient while massaging the module structure.
    Oh, I forgot to mention: also a deprecated submodule with all the deprecated classes that get renamed/moved, so that old stuff still compiles. But I fear this may ultimately be futile.
    I do not yet know whether it will be feasible to keep existing SciJava 2 commands working. I fear it may be difficult.
    Stefan Helfrich
    @stelfrich
    OK, wow. Got to think about that
    Curtis Rueden
    @ctrueden
    I have a lot of reservations about this plan:
    1. There may be >30 scijava core modules—that's 30 new Git repositories when the restructuring is complete.
    2. The backwards compatibility issues.
    3. The git history bloat.
    4. Inability to release new versions of scijava-common v2.x once the initial switchover to 3.0.0-alpha happens.
    Stefan Helfrich
    @stelfrich
    Could you give me an example or two of the new modules?
    collection context core indexer ops param plugin struct swing-widget util version widget
    Names all tentative of course. I don't really like swing-widget but it's a placeholder.
    Basically, every org.scijava.foo package will now be scijava-foo artifact.
    Stefan Helfrich
    @stelfrich
    It’s enough to get an idea!
    Curtis Rueden
    @ctrueden
    The multi-project configuration makes it really easy to verify that you aren't violating encapsulation or cross-polluting imports.
    ImageJ2 was originally much more modular—nearly this modular—but people were overwhelmed by the number of modules.
    But now people tell me SciJava Common is "bloated" so... screw 'em. Modules.
    The "sensible" thing to do, I suppose, is to develop this temporary multi-module monster on a separate integration branch, and keep it synchronized with master via rebases etc.
    But I just... just... HATE that! I am only one person, and keeping track of it is too much.
    There already is an sjc3 branch with changes intended for SJC3, and guess what? It is years out of date.
    Stefan Helfrich
    @stelfrich
    I know..