Difference between revisions of "Documentation/Nightly/Developers/FAQ/General"

From Slicer Wiki
Jump to: navigation, search
(Prepend documentation/versioncheck template. See http://na-mic.org/Mantis/view.php?id=2887)
Line 23: Line 23:
 
== How to schedule a Developer Hangout ? ==
 
== How to schedule a Developer Hangout ? ==
 
See instruction [[Developer_Meetings/OrganizerInstruction|here]]
 
See instruction [[Developer_Meetings/OrganizerInstruction|here]]
 +
 +
 +
== Should core feature be implemented in C++ or Python ? ==
 +
 +
Original comment from Andras Lasso copied from [https://github.com/Slicer/Slicer/pull/373#issuecomment-146894971 PR#373] discussion.
 +
 +
 +
There are many reasons for implementing Slicer core in C++, we just list here few reasons:
 +
 +
* C++ rigor and extensive compile-time checks increases the chance of catching errors earlier. C++ enforces many things that in Python are managed by good programming practices (that are not enforced and in general not followed by Slicer developers).
 +
 +
* C++ memory management is much more explicit, which is more difficult to learn than Python, but allows much better efficiency (you can prevent memory fragmentation, optimize memory reallocations, etc), which is useful for code that may run hundreds of times per second (this code does).
 +
 +
* There are lots of good examples of solid, fast C++ displayable managers. Python displayable managers are more at the experimental level.
 +
 +
* Accessibility of Python classes from C++ modules is cumbersome. Accessibility of C++ classes is very convenient from both Python and C++ modules.
 +
 +
* Some projects don't use Python and don't want to use it (Python brings in huge amount of additional code, which is a problem if you want to minimize the amount of code that goes through regulatory approval)
 +
 +
* Profiling and optimization of mixed C++/Python code is very difficult (both C++ and Python profilers treat the "other side" as black hole). Since all the rest of the Slicer core is implemented in C++ (with a few small exceptions), it is much easier to implement this in C++, too.
 +
 +
 +
That said, we love Python programming, do it extensively, but implementing Slicer core features in Python has just too many disadvantages.

Revision as of 16:08, 9 October 2015

Home < Documentation < Nightly < Developers < FAQ < General


For the latest Slicer documentation, visit the read-the-docs.


General

What is Slicer ?

3D Slicer is a free open source extensible software application for medical image computing and visualization. Mainly written in C++ and based on the NA-MIC kit, 3D Slicer relies on a variety of libraries: VTK, ITK, CTK, CMake, Qt and Python.

To ensure the stability of the application, relying on a robust software process, the source code is compiled and tested on a daily basis on a variety of platform configurations. The testing results are summarized and reported using a web-based centralized CDash dashboard. Developers of 3D Slicer can also report issues on the Slicer Discourse Forum or using the issues tracker.

3D Slicer consists of both a lean application core and modules offering specific functionality. The core implements the user interface, provides support for data input/output (IO) and visualization and also exposes developer interfaces that support extension of the application with new modules.

Multiple types of modules are supported: CLI, Loadable module, Scripted module and Editor effect. While the developer has to choose between one of these types to implement its module, the end user won't notice the difference as they all share the same look & feel. The choice for a given type of module is usually based on the type of inputs/parameters for a given module.

These modules can be either built-in or installed on demand via the extensions manager.

How to setup for Git development ?

See Slicer Setup

How to contribute a patch ?

The following instructions describes the recommended workflow to contribute patch to Slicer code base.

It is assumed that you followed the New community member checklist, have a clone of https://github.com/Slicer/Slicer/ and have setup the development environment as described here.

  1. Create an issue in the tracker setting severity to feature. For example, see issue #1906

    1. For simple changes (e.g typo, ...), this step is optional.
  2. Make sure your clone has a git remote. After forking Slicer repository, replace jcfr with your git login.

    git remote add jcfr git@github.com:jcfr/Slicer.git
    
  3. Create a topic named <issuer_number>-a-descriptive-topic-name. For example:

    git checkout -b 1906-uninstall-extensions-on-restart
    
  4. Fix the code or implement your feature, then commit your change(s)

    1. Make sure to read the Slicer Coding and Commit Style Guide
  5. Publish the topic on your fork

    git push jcfr 1906-uninstall-extensions-on-restart
    
  6. Create a Pull Request and add a note to the issue with a link pointing to your topic. For example, see note 1906#c4578



What is our bug / feature request workflow ?

The following diagram illustrates Slicer issue workflow:

Mantis-workflow.png

Source: Adapted from http://www.warelab.org/blog/?p=24


How to schedule a Developer Hangout ?

See instruction here


Should core feature be implemented in C++ or Python ?

Original comment from Andras Lasso copied from PR#373 discussion.


There are many reasons for implementing Slicer core in C++, we just list here few reasons:

  • C++ rigor and extensive compile-time checks increases the chance of catching errors earlier. C++ enforces many things that in Python are managed by good programming practices (that are not enforced and in general not followed by Slicer developers).
  • C++ memory management is much more explicit, which is more difficult to learn than Python, but allows much better efficiency (you can prevent memory fragmentation, optimize memory reallocations, etc), which is useful for code that may run hundreds of times per second (this code does).
  • There are lots of good examples of solid, fast C++ displayable managers. Python displayable managers are more at the experimental level.
  • Accessibility of Python classes from C++ modules is cumbersome. Accessibility of C++ classes is very convenient from both Python and C++ modules.
  • Some projects don't use Python and don't want to use it (Python brings in huge amount of additional code, which is a problem if you want to minimize the amount of code that goes through regulatory approval)
  • Profiling and optimization of mixed C++/Python code is very difficult (both C++ and Python profilers treat the "other side" as black hole). Since all the rest of the Slicer core is implemented in C++ (with a few small exceptions), it is much easier to implement this in C++, too.


That said, we love Python programming, do it extensively, but implementing Slicer core features in Python has just too many disadvantages.