Developer Meetings/20130212

To discuss

• ITKv4 enabled by default / SimpleITK updated to v0.6.1. See r21688
  • Review list of existing issue (mantis tag: ITKv4)
• Approach to display log on windows: http://slicer-devel.65872.n3.nabble.com/Windows-command-line-tp4027441p4027524.html
  • Log to file ?
  • Provide an other (application + Launcher) which would be console aware ?
• Demo AutoRun for CLI modules (Julien, #2940)
• Continuous integration
  • Test takes way too long - What about creating a ctest LABEL named "fast" or one named "slow". It would then be easy to run integration tests: ctest -L fast or ctest -LE slow
  • Python self test are very long. Does it make sens to run them continously. What about one time a week ? During the weekend ?
• Refactor of Python self test
  • Duplicated code :( ... => maintenance hell. See third point reported here.
• Re-enable setup windows 32-bit nightly
• CMake'ification / OpenSSL integration: No progress due to integration of ITKv4.
• Extensions
  • Considering disabling extension ukftractography. See https://github.com/pnlbwh/ukftractography/issues/3
    • Adding extension named "Boost" would probably help: https://github.com/pnlbwh/ukftractography/issues/2
  • Will very probably add an extension named "JsonCpp". See JsonCpp.s4ext

Conclusion

• Reviewed ITKv4 issue in Mantis
  • Issue #2289 - CreateADICOMSeries using ITKv4 does not properly write out Z-spacing
    • => Jim Miller is working on the issue
    • => A regression test should be added to illustrate the problem.

• Console output on windows
  • To provide feedback for windows user, possible non-exclusive approaches could be to
    • => have a popup windows when command like: --help are executed.
    • => log output to a file
  • Finally, improving the launcher so that it detects crash and propose an email template with meaningful information would be nice.

• Agreed that having a mechanism to run only "fast" test or exclude "slow" test would help both "Continuous integration" process and would allow developer to run test locally without having to wait 30mins.

• Discussed issue #2915
  • Having some VTK helper class to "safely" communicate events from thread to main loop would help.

• Agreed than re-factoring the python self-test infrastructure to minimize code duplication makes sens.

• Presented the concept of "Developer / build-time" extension. Such extension allows to have extension depending on project without having to implement a Superbuild system in the extension itself.
  • This make sens in the context of project/library required at testing time only or if the project generate static library or is headerless.
  • This could also motivate a feature allowing to pass CMake option that would be listed in a extension description file.

• Julien presented his work regarding the CLI AutoRun feature. See http://www.na-mic.org/Bug/view.php?id=2940
  • The will be integrated soon into Slicer. In the mean time, you can check it out here
  • If enabled, it will basically allow any given CLI to run if:
    • => Inputs are modified
    • => Parameters are changed
  • This will be a great addition, it will enable to create pipeline of CLIs very easily.
  • Will also be available from python.

• Presented to Jim the work (prototype) did at Kitware regarding remote execution of modules:

In a nutshell, the idea is to have a public facing API allowing to execute CLIs. By having the concept of instance_id it is possible to keep the execution of given set of CLIs on the same instance to avoid costly data transfer and leverage the fact data are already in memory.

A midas server would expose an API like:

slicer.reserve(timeout = -1)           # reserve a slicer instance for execution. Release the instance after <timeout>
slicer.cli.list(instance_id)           # list all cli modules associated with a given instance.
slicer.cli.describe(instance_id, name) # describe the cli available on a given instance
slicer.cli.run(instance_id, name, parameters) # run cli
slicer.release(instance_id)            # release a given instance

By using a midas server, data could then be easily transfer in and out from a common data storage.

Each Slicer instance would also run its own web server exposing also a simple API to "talk" with either a midas instance or any other client being on the same network. It could for example be an other Slicer instance.

The API associated with the Slicer server would be:

slicer.cli.list()
slicer.cli.describe(name)
slicer.cli.run(name, parameters)

The "server" running in Slicer would be Twisted, the event-driven networking engine written in Python and licensed under the open source MIT license.

The prototype code of the corresponding midas module is currently available here.

On midas side, work is required to implement the "slicer.reserve / release()" method. Currently, as a first implementation it could return the "id" of a Slicer instance running along side the midas server. Moving forward, the idea would be to be able to either have existing Slicer instance registered as available or spawning virtual machine on the amazon cloud ...

On Slicer side, the integration of Twisted need to be reviewed.

All of that said, if you believe this could benefit your projects. Make sure to drop a line to Jim (millerjvge.com) and myself (jchris.fillionrkitware.com).

• JsonCpp Extension has been merged and is all green :-): http://slicer.cdash.org/index.php?project=Slicer4&filtercount=1&showfilters=1&field1=buildname/string&compare1=63&value1=Json