Difference between revisions of "Developer Meetings/20130212"
m |
(convert email tags to template) Tag: 2017 source edit |
||
(16 intermediate revisions by 4 users not shown) | |||
Line 1: | Line 1: | ||
+ | __TOC__ | ||
+ | |||
== To discuss == | == To discuss == | ||
* ITKv4 enabled by default / SimpleITK updated to v0.6.1. See [http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=21688 r21688] | * ITKv4 enabled by default / SimpleITK updated to v0.6.1. See [http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=21688 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 | * Approach to display log on windows: http://slicer-devel.65872.n3.nabble.com/Windows-command-line-tp4027441p4027524.html | ||
** Log to file ? | ** Log to file ? | ||
** Provide an other (application + Launcher) which would be console aware ? | ** Provide an other (application + Launcher) which would be console aware ? | ||
+ | * Demo AutoRun for CLI modules (Julien, [http://www.na-mic.org/Bug/view.php?id=2940 #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: <code>ctest -L fast</code> or <code>ctest -LE slow</code> | ||
+ | ** 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 [http://www.na-mic.org/Wiki/index.php/2013_Project_Week:SelfTests 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 [https://github.com/chrismullins/ExtensionsIndex/commit/987fa3008e2b7f7f5ff49f80a4e6c736d66499f9 JsonCpp.s4ext] | ||
== 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. | ||
+ | |||
+ | * 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 [http://public.kitware.com/gitweb?p=Bender/Slicer.git;a=commit;h=503190a99c085bdeefc295d685921c754f3106a2 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 [http://twistedmatrix.com/trac/ 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 [https://github.com/midasplatform/pyslicer/tree/slicerweb 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 (millerjv{{@}}ge.com) and myself (jchris.fillionr{{@}}kitware.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 |
Latest revision as of 05:02, 27 November 2019
Home < Developer Meetings < 20130212Contents
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
orctest -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 ?
- 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:
- 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
- Considering disabling extension ukftractography. See https://github.com/pnlbwh/ukftractography/issues/3
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.
- Issue #2289 - CreateADICOMSeries using ITKv4 does not properly write out Z-spacing
- 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.
- To provide feedback for windows user, possible non-exclusive approaches could be to
- 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.fillionr
kitware.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