inexlib_py is the collection of exlib examples related to Python put in a standalone package.

The 1.1.x contains examples coworking with Spark. It can be built with Python3. The 1.2.x contains examples that have a "client" mode so that they can send scene graphs to the inexlib_serv application.


There are C++ little applications that activate Python through it's library and a set of .py scripts that demonstrate how to activate inlib/exlib from a Python prompt by using the SWIG modules:            # pure inlib.     # on screen inlib/exlib graphics and plotting.  # offscreen inlib/exlib graphics and plotting.

These modules has been done by using the SWIG wrapping of some (but not all) classes of inlib and exlib.

C++ apps (source code in inexlib_py/inexlib/exlib/examples/cpp):

    hello_py.cpp            # to check Python activation from C++.
    h1d_spy.cpp             # inlib histogram wrapped with swig.
    plotter_spy_screen.cpp  # exlib plotting wrapped with swig.
    mandel_py.cpp           # check calling a C++ function from Python.

C++ inlib "client" apps (source code in inexlib_py/inexlib/inlib/examples/cpp):

    cube_to_sg_serv.cpp     # send a cube to inexlib_serv.
    lego_to_sg_serv.cpp     # send a lego plot to inexlib_serv.

Python .py scripts:                 # inlib histo.               # read an histo in a root file.               # write histos at the AIDA XML file format.                # project a ntuple found in the pawdemo.root file
                           # and plot the histo.      # visualise a solid/shape boolean operation.      # plot an histo by using softinex graphics and plotting.
                           # A simple viewer is used.         # same as upper but by using a more advanced "gui viewer".     # visualise an image in a fits file.           # random clouds of points in a plot.
    two_cubes_vis.pye      # show the "blender effect" on a coarse grained rearranged
                           # random points.             # create, fill and plot a 3D cloud of 3D random points.         # read points from cosmo_dc2_rdz_cut.csv, fill and plot a 3D cloud.         # read points from cosmo_dc2_rdz_cut.csv, fill and plot histos.    # read points from cosmo_dc2_rdz_cut.csv, and visualize them
                           # with a simple viewer (without a plot). # same as upper, but by using a more advanced viewer.

Spark examples:   # inlib histo.            # open spark_test_data.fits and a simple collect. # read a TBL in a fits file, do "ntuple projections" with Spark,
                             # and plot with the inexlib/plotter.        # open spark_test_data.fits, do a simple collect, fill and
                             # plot an histo.

 The scripts:                  
 uses parquet files not in the distribution.

See the README file on github for instructions on how to build, install and run.

What is wrapped ?

What is available of inlib/exlib from Python can be seen in the ".i" files given to SWIG. These are available on github at :


In particular the file nodes.i shows the inlib::sg::nodes declared to SWIG along their "fields" ("sf" for a simple field or "mf" for a multiple field). For example for inlib::sg::cube, what is declared to SWIG is :

    class cube : public node {
      virtual node* copy() const;
      virtual ~cube();
      cube(const cube&);
      cube& operator=(const cube&);
      sf<float> width;    //simple field for the width of the cube.
      sf<float> height;
      sf<float> depth;

The upper permits, from Python, to do something as :

    import inlib
    cube = inlib.sg_cube()

Note that we do not wrap all the C++ code with SWIG. In general in a C++ class, there are private and protected materials that are for developers and do not need to be seen from Python. The remaining public material can be split in "public/developer" and "public/user". "public/developer" material is for the developer to help classes working together. And the remaining "public/user" fields and methods are the "true" materials that a user want to see; it is the "spirit" for what the class and package had been created. In inexlib_py, we declare to SWIG only the C++ which is "public/user". For the moment, we do not have a nice web reference manual "a la doxygen" for the ".i", then the best is to jump directly in the .i files to have informations. What is here is in general self explanatory and should be already helpfull.