Difference between revisions of "Developer Meetings/20130212"

From Slicer Wiki
Jump to: navigation, search
m
Line 19: Line 19:
  
 
== Conclusion ==
 
== Conclusion ==
 +
 +
* Reviewed ITKv4 issue in Mantis
 +
** Issue [http://www.na-mic.org/Bug/view.php?id=2289 #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 [http://www.na-mic.org/Bug/view.php?id=2915 #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.
 +
 +
* 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.reserve(instance_id)            # release a given instance
 +
 +
Each Slicer instance would also run it's 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.list(name)
 +
slicer.cli.run(name)
 +
 +
The "server" running in Slicer would be [http://twistedmatrix.com/trac/ Twisted], the event-driven networking engine written in Python and licensed under the open source MIT license.
 +
 +
The prototype code is currently available here:

Revision as of 21:28, 18 February 2013

Home < 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

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.
  • 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.reserve(instance_id)            # release a given instance

Each Slicer instance would also run it's 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.list(name)
slicer.cli.run(name)

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 is currently available here:

Retrieved from "https://www.slicer.org/w/index.php?title=Developer_Meetings/20130212&oldid=30534"