recepie for ctbgui

WIP
2025-06-13 05:17:13 +02:00 · 2022-05-02 12:03:59 +02:00 · 2022-04-29 15:59:26 +02:00
605 changed files with 17103 additions and 86561 deletions
--- a/.gitmodules
+++ b/.gitmodules
@ -0,0 +1,3 @@
+[submodule "python/pybind11"]
+	path = libs/pybind11
+	url = https://github.com/pybind/pybind11.git
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@ -2,7 +2,7 @@
 # Copyright (C) 2021 Contributors to the SLS Detector Package
 cmake_minimum_required(VERSION 3.12)
 project(slsDetectorPackage)
-set(PROJECT_VERSION 7.0.2)
+set(PROJECT_VERSION 6.1.1)

 set(CMAKE_CXX_FLAGS_RELEASE "-O3 -DNDEBUG")

@ -48,7 +48,6 @@ option(SLS_USE_TESTS "TESTS" OFF)
 option(SLS_USE_INTEGRATION_TESTS "Integration Tests" OFF)
 option(SLS_USE_SANITIZER "Sanitizers for debugging" OFF)
 option(SLS_USE_PYTHON "Python bindings" OFF)
-option(SLS_INSTALL_PYTHONEXT "Install the python extension in the install tree under CMAKE_INSTALL_PREFIX/python/" OFF)
 option(SLS_USE_CTBGUI "ctb GUI" OFF)
 option(SLS_BUILD_DOCS "docs" OFF)
 option(SLS_BUILD_EXAMPLES "examples" OFF)
@ -83,8 +82,6 @@ endif()
 #Maybe have an option guarding this?
 set(SLS_INTERNAL_RAPIDJSON_DIR ${CMAKE_CURRENT_SOURCE_DIR}/libs/rapidjson)

-set(SLS_INTERNAL_QWT_DIR ${CMAKE_CURRENT_SOURCE_DIR}/libs/qwt-6.1.5)
-
 set(ClangFormat_EXCLUDE_PATTERNS    "build/" 
                                    "libs/" 
                                    "slsDetectorCalibration/" 
@ -225,7 +222,6 @@ if (SLS_USE_RECEIVER)
 endif (SLS_USE_RECEIVER)

 if (SLS_USE_GUI)   
-    add_subdirectory(libs/qwt)  
    add_subdirectory(slsDetectorGui)
 endif (SLS_USE_GUI)

@ -239,7 +235,7 @@ endif (SLS_USE_INTEGRATION_TESTS)

 if (SLS_USE_PYTHON)
    find_package (Python 3.6 COMPONENTS Interpreter Development)
-    add_subdirectory(libs/pybind  ${CMAKE_BINARY_DIR}/bin/)
+    add_subdirectory(libs/pybind11  ${CMAKE_BINARY_DIR}/bin/)
    add_subdirectory(python)
 endif(SLS_USE_PYTHON)

--- a/README.md
+++ b/README.md
@ -1,233 +1,102 @@
-## Dependencies
-Before building from source make sure that you have the [software wiki](https://slsdetectorgroup.github.io/devdoc/dependencies.html) installed. If installing using conda, conda will manage the dependencies. Avoid also installing packages with pip. 
+### Note

-## Documentaion
-Detailed documentation can be found in the [software wiki](https://slsdetectorgroup.github.io/devdoc/index.html) and on the [official site](https://www.psi.ch/en/detectors/software).
+Please do not update to any xxxx.xx.xx.dev0 tags. They are not releases, but tags for internal usage.
+Use only releases with tags such as x.x.x or x.x.x-rcx.

-## Installation
+### Documentation
+##### 5.0.0 - Latest Release
+Detailed documentation on the latest release can be found in the [software wiki](https://slsdetectorgroup.github.io/devdoc/index.html) and on the [official site](https://www.psi.ch/en/detectors/software).

-### 1. Install binaries using conda
-Conda is not only useful to manage python environments but can also
-be used as a user space package manager. Dates in the tag (for eg. 2020.07.23.dev0) 
-are from the developer branch. Please use released tags for stability.
-
-We have three different packages available:
-* **slsdetlib** shared libraries and command line utilities 
-* **slsdetgui** GUI
-* **slsdet** Python bindings
+##### Older Releases
+Documentation is found in the package.

+### Binaries
+Binaries for the slsDetectorPackage are available through conda. 
 ```
-#Add channels for dependencies and our library
+#Add conda channels
 conda config --add channels conda-forge
 conda config --add channels slsdetectorgroup
 conda config --set channel_priority strict

-#create and activate an environment with our library
-#replace 6.1.1 with the required tag
-conda create -n myenv slsdetlib=6.1.1
-conda activate myenv
+conda install slsdetlib   #only shared lib and command line
+conda install slsdet      #python bindings (includes slsdetlib)
+conda install slsdetgui   #gui (includes qt4)

-#ready to use
-sls_detector_get exptime
-etc ...
-```
+#Install specific version
+conda install slsdet=2020.03.02.dev0 #developer version from 3 March 2020

-```
-# List available versions
-# lib and binaries
-conda search slsdetlib
-# python
-conda search slsdet
-# gui
-conda search slsdetgui
 ```

-### 2. Build from source
-
-##### 2.1 Download Source Code from github
+### Source code
+One can also obtain the source code from this repository and compile.
 ```
-git clone https://github.com/slsdetectorgroup/slsDetectorPackage.git --branch 7.0.0
-```
-
-**Pybind for Python**<br>
-* **v7.0.0+**:
-pybind11 packaged into 'libs/pybind'. No longer a submodule. No need for "recursive" or "submodule update".
- 
-* **Older versions**:
-   pybind11 is a submodule. Must be cloned using "recursive" and updated when switching between versions using the following commands.
+git clone https://github.com/slsdetectorgroup/slsDetectorPackage.git

 ```
-# clone using recursive to get pybind11 submodule
-git clone --recursive https://github.com/slsdetectorgroup/slsDetectorPackage.git
+#### Dependencies 

-# update submodule when switching between releases
-cd slsDetectorPackage
-git submodule update --init
+Refer [this page](https://slsdetectorgroup.github.io/devdoc/dependencies.html)  for dependencies.
+
+
+#### Compilation 
+
+Compiling can be done in two ways. Either with the convenience script
+cmk.sh or directly with cmake for more control.
+
+**1. Compile using script cmk.sh**<br>
+
+These are mainly aimed at those not familiar with using ccmake and cmake. 
 ```
+    The binaries are generated in slsDetectorPackage/build/bin directory.

-##### 2.2 Build from source
-
-
-###### Build using CMake
-
-```
-# outside slsDetecorPackage folder
-mkdir build && cd build
-
-# configure & generate Makefiles using cmake
-# by listing all your options (alternately use ccmake described below)
-# cmake3 for some systems
-cmake ../slsDetectorPackage -DCMAKE_INSTALL_PREFIX=/your/install/path
-
-# compiled to the build/bin directory
-make -j12 #or whatever number of cores you are using to build
-
-# install headers and libs in /your/install/path directory
-make install
-```
-
-Instead of the cmake command, one can use ccmake to get a list of options to configure and generate Makefiles at ease.
-
-
-```
-# ccmake3 for some systems
-ccmake ..
- 
-# choose the options
-# first press [c] - configure
-# then press [g] - generate
-```
-
-|Example cmake options|Comment|
-|---|---|
-| -DSLS_USE_PYTHON=ON            | Python                                 |   
-| -DPython_FIND_VIRTUALENV=ONLY  | Python from only the conda environment |
-| -DZeroMQ_HINT=/usr/lib64       | Use system zmq instead                 |    
-| -DSLS_USE_GUI=ON               | GUI                                    |
-
-
-###### Build using in-built cmk.sh script
-
-```
-The binaries are generated in slsDetectorPackage/build/bin directory.
-
-Usage: ./cmk.sh [-b] [-c] [-d <HDF5 directory>] [e] [g] [-h] [i] [-j <Number of threads>] 
-[-k <CMake command>] [-l <Install directory>] [m] [n] [-p] [-q <Zmq hint directory>] 
-[r] [s] [t] [u] [z]  
-[no option]: only make
-b: Builds/Rebuilds CMake files normal mode
-c: Clean
-d: HDF5 Custom Directory
-e: Debug mode
-g: Build/Rebuilds gui
-h: Builds/Rebuilds Cmake files with HDF5 package
-i: Builds tests
-j: Number of threads to compile through
-k: CMake command
-l: Install directory
-m: Manuals
-n: Manuals without compiling doxygen (only rst)
-p: Builds/Rebuilds Python API
-q: Zmq hint directory
-r: Build/Rebuilds only receiver
-s: Simulator
-t: Build/Rebuilds only text client
-u: Chip Test Gui
-z: Moench zmq processor
+    Usage: ./cmk.sh [-c] [-b] [-p] [e] [t] [r] [g] [s] [u] [i] [m] [n] [-h] [z] [-d <HDF5 directory>] [-l Install directory] [-k <CMake command>] [-j <Number of threads>]
+    -[no option]: only make
+    -c: Clean
+    -b: Builds/Rebuilds CMake files normal mode
+    -p: Builds/Rebuilds Python API
+    -h: Builds/Rebuilds Cmake files with HDF5 package
+    -d: HDF5 Custom Directory
+    -k: CMake command
+    -l: Install directory
+    -t: Build/Rebuilds only text client
+    -r: Build/Rebuilds only receiver
+    -g: Build/Rebuilds only gui
+    -s: Simulator
+    -u: Chip Test Gui
+    -j: Number of threads to compile through
+    -e: Debug mode
+    -i: Builds tests
+    -m: Manuals
+    -n: Manuals without compiling doxygen (only rst)
+    -z: Moench zmq processor

    
-# display all options
-./cmk.sh -?
+    # get all options
+    ./cmk.sh -?

-# new build and compile in parallel (recommended basic option):
-./cmk.sh -cbj5
-
-# new build, python and compile in parallel:
-./cmk.sh -cbpj5
-
-#To use the system zmq (/usr/lib64) instead
-./cmk.sh -cbj5 -q /usr/lib64
+    # new build  and compile in parallel:
+    ./cmk.sh -bj5
+```
+ 
+**2. Compile without script**<br>
+Use cmake to create out-of-source builds, by creating a build folder parallel to source directory. This would create a debug build with address sanitizers.
+```
+    $ mkdir build
+    $ cd build
+    $ cmake ../slsDetectorPackage  -DCMAKE_BUILD_TYPE=Debug -DSLS_USE_SANITIZER=ON
+    $ make -j12 #or whatever number of threads wanted
 ```

-###### Build on old distributions
-
-If your linux distribution doesn't come with a C++11 compiler (gcc>4.8) then 
-it's possible to install a newer gcc using conda and build the slsDetectorPackage
-using this compiler
-
+To install binaries using CMake
 ```
-#Create an environment with the dependencies
-conda create -n myenv gxx_linux-64 cmake zmq
-conda activate myenv
-
-# outside slsDetecorPackage folder
-mkdir build && cd build
-cmake ../slsDetectorPackage -DCMAKE_PREFIX_PATH=$CONDA_PREFIX
-make -j12
-```
-
-###### Build slsDetectorGui (Qt5)
-
-1. Using pre-built binary on conda
-```
-conda create -n myenv slsdetgui=7.0.0
-conda activate myenv
-```
-
-2. Using system installation on RHEL7
-```
-yum install qt5-qtbase-devel.x86_64
-yum install qt5-qtsvg-devel.x86_64 
-```
-
-3. Using conda
-```
-#Add channels for dependencies and our library
-conda config --add channels conda-forge
-conda config --add channels slsdetectorgroup
-conda config --set channel_priority strict
-
-# create environment to compile
-# on rhel7
-conda create -n slsgui zeromq gxx_linux-64 gxx_linux-64 mesa-libgl-devel-cos6-x86_64 qt
-# on fedora or newer systems
-conda create -n slsgui zeromq qt
-
-# when using conda compilers, would also need libgl, but no need for it on fedora unless maybe using it with ROOT
-
-# activate environment
-conda activate slsgui
-
-# compile with cmake outside slsDetecorPackage folder
-mkdir build && cd build
-cmake ../slsDetectorPackage -DSLS_USE_GUI=ON
-make -j12
-
-# or compile with cmk.sh
-cd slsDetectorPackage
-./cmk.sh -cbgj9
-```
-
-###### Build documentation from package
-The documentation for the slsDetectorPackage is build using a combination 
-of Doxygen, Sphinx and Breathe. The easiest way to install the dependencies
-is to use conda 
-
-```
-conda create -n myenv python sphinx_rtd_theme breathe
-```
-
-```
-# using cmake or ccmake to enable DSLS_BUILD_DOCS
-# outside slsDetecorPackage folder
-mkdir build && cd build
-cmake ../slsDetectorPackage -DSLS_BUILD_DOCS=ON
-
-make docs # generate API docs and build Sphinx RST
-make rst # rst only, saves time in case the API did not change
+    git clone --recursive https://github.com/slsdetectorgroup/slsDetectorPackage.git
+    mkdir build && cd build
+    cmake ../slsDetectorPackage -DCMAKE_INSTALL_PREFIX=/your/install/path
+    make -j12 #or whatever number of cores you are using to build
+    make install
 ```


-## Support
+### Support
    dhanya.thattil@psi.ch
-    erik.frojdh@psi.ch
+    erik.frojdh@psi.ch
--- a/RELEASE.txt
+++ b/RELEASE.txt
@ -1,174 +1,148 @@
-SLS Detector Package Major Release 7.0.2 released on 12.07.2023
+SLS Detector Package Minor Release 7.0.0 released on 25.11.2021
 ===============================================================

-This document describes the differences between v7.0.2 and v7.0.1   
+This document describes the differences between v7.0.0 and v6.x.x   



    CONTENTS
    --------
-    1   Resolved Issues
-    2   On-board Detector Server Compatibility
-    3   Firmware Requirements
-    4   Kernel Requirements
-    5   Download, Documentation & Support
+    1.  New or Changed Features
+    2.  Resolved Issues
+    3.  Firmware Requirements
+    4.  Kernel Requirements
+    5.  Download, Documentation & Support



-1 Resolved Issues
-=================
+
+1. New or Changed Features
+==========================
+
+- Fixed minor warnings (will fix commandline print of excess packets for missing packets)
+- ctb slow adcs and any other adcs (other than temp) goes to the control Server
+- number of udp interfaces is 2 for Eiger (CHANGE IN API??)
+- added module id for virtual servers into the udp header
+- refactoring (rxr)
+- fixed patsetbit and patsetmask for moench
+- changed default vref of adc9257 to 2V for moench (from 1.33V)
+- moench and ctb - can set the starting frame number of next acquisition
+- mythen server kernel check incompatible (cet timezone)
+- rx_arping
+- rx_threadsids max is now 9 (breaking api)
+- fixed datastream disabling for eiger. Its only available in 10g mode.
+- m3 server crash (vthrehsold dac names were not provided)
+- allow vtrim to be interpolated for Eiger settings
+- m3 setThresholdEnergy and setAllThresholdEnergy was overwriting gaincaps with settings enum
+- can set localhost with virtual server with minimum configuration: (hostname localhost, rx_hostname localhost, udp_dstip auto)
+- increases the progress according to listened index. (not processed index)
+- current frame index points to listened frame index (not processed index)
+- when in discard partial frames or empty mode, the frame number doesnt increase by 1, it increases to that number (so its faster)
+- file write disabled by default
+- eiger 12 bit mode
+- start non blocking acquisition at modular level
+- connect master commands to api (allow set master for eiger)
+--ignore-config command line
+- command line argument 'master' mainly for virtual servers (also master/top for real eiger), only one virtual server for eiger, use command lines for master/top
+- stop servers also check for errors at startup( in case it was running with an older version)
+- hostname cmd failed when connecting to servers in update mode (ctb, moench, jungfrau, eiger)
+- missingpackets signed (negative => extra packets)
+- framescaught and frameindex now returns a vector for each port
+- progress looks at activated or enabled ports, so progress does not stagnate
+- (eiger) disable datastreaming also for virtual servers only for 10g
+- missing packets also takes care of disabled ports
+- added geometry to metadata
+- 10g eiger nextframenumber get fixed.
+- stop, able to set nextframenumber to a consistent (max + 1) for all modules if different (eiger/ctb/jungfrau/moench)
+- ctb: can set names for all the dacs
+- fpga/kernel programming, checks if drive is a special file and not a normal file
+- gotthard 25 um image reconstructed in gui and virtual hdf5 (firmware updated for slave to reverse channels)
+- master binary file in json format now
+- fixed bug introduced in 6.0.0: hdf5 files created 1 file per frame after the initial file which had maxframesperfile
+- m3 polarity, interpolation (enables all counters when enabled), pump probe, analog pulsing, digital pulsing
+- updatedetectorserver - removes old server current binary pointing to for blackfin
+- removing copydetectorserver using tftp 
+>>>>>>> developer
+- registerCallBackRawDataReady and registerCallBackRawDataModifyReady now gives a sls_receiver_header* instead of a char*, and uint32_t to size_t
+- registerCallBackStartAcquisition gave incorrect imagesize (+120 bytes). corrected.
+- registerCallBackStartAcquisition parameter is a const string reference
+- m3 (runnig config second time with tengiga 0, dr !=32, counters !=0x7) calculated incorrect image size expected
+- fixed row column indexing (mainly for multi module Jungfrau 2 interfaces )
+- eiger gui row indices not flipped anymore (fix in config)
+
+2. Resolved Issues
+==================


-    Firmware
-    --------
-
-    *   [Jungfrau] Stopping acquisition in sync mode
-        Previously, stopping acquisition in sync mode would result in the slave
-        status remaining in Running status for next acquisition and framesl (frames
-        left) would be stuck from the previous acquisition. This is fixed in firmware.
-  
-
-
-    Detector Server
-    ---------------
-
-    *   [Jungfrau] Changing master to slave in sync mode
-        When in sync mode, changing from master to slave would change the status
-        to Running in firmware. A workaround in the detector server fixes this.
-
-    *   [Jungfrau] Row and column for multi module Jungfrau 
-        This mainly affected only the GUI, unless one was using the row and column
-        sent out by the detector. Row and column values were mixed up, but fixed now.
-
-    *   [Jungfrau] Timing in sync mode
-        When sync is enabled, setting or getting timing would give an error. This 
-        is fixed now.
-
-
-    Client
-    ------
-
-    *   [Jungfrau] Multi module sync mode
-        For start, stop and trigger acquisition, the procedure to start the slaves
-        (or the master for stop acquisition) first had to be obeyed. This is fixed
-        now.
+3. Firmware Requirements
+========================
+        
+    Eiger
+    =====  
+    Compatible version : 08.10.2021 (v29)
    
+    Jungfrau
+    ========       
+    Compatible version : 31.08.2021 (v1.2, PCB v1.0) 
+                       : 08.10.2021 (v2.2, PCB v2.0)

-    ZMQ
-    ---
+    Gotthard
+    ========   
+    Compatible version : 08.02.2018 (50um and 25um Master)
+                       : 09.02.2018 (25 um Slave) 

-    *   [Jungfrau][Gotthard2] Client ZMQ port when using 2 interfaces
-        When switching between 1 and 2 interfaces, the client or gui zmq port
-        was not set properly and resulted in dummy streaming forever. This is
-        fixed now.
+    Mythen3
+    =======
+    Compatible version : 10.09.2021 (v1.1)

-    *   Rx_roi
-        This parameter is now also streamed in the zmq header to be able to use in 
-        external GUIs.
+    Gotthard2
+    =========
+    Compatible version : 27.05.2021 (v0.1)

+    Moench
+    ======
+    Compatible version : 05.10.2020 (v1.0)

-    GUI
-    ---
+    Ctb
+    ===
+    Compatible version : 05.10.2020 (v1.0)

-    *   [Jungfrau] Show Fix_G0 in expert mode
-        Fix_G0 was only shown when expert mode was enabled from Settings Tab. Now, 
-        fixed to show when expert mode enabled from any tab.
+    Detector Upgrade
+    ================
+    The following can be upgraded remotely:
+    Eiger      via bit files
+    Jungfrau   via command <.pof>
+    Mythen3    via command <.rbf>
+    Gotthard2  via command <.rbf> 
+    Moench     via command <.pof>
+    Ctb        via command <.pof>

-    
-
-
-2  On-board Detector Server Compatibility
-==========================================
-
-
-    Eiger       7.0.0
-    Jungfrau    7.0.2
-    Mythen3     7.0.0
-    Gotthard2   7.0.0
-    Gotthard    7.0.0
-    Moench      7.0.0
-    Ctb         7.0.0
-    
-
-    On-board Detector Server Upgrade
-    --------------------------------
-
-    From v6.1.0 (without tftp):
-        Using command 'updatedetectorserver'
-    From 5.0.0 (with tftp):
-        Using command 'copydetectorserver'
+    The following cannot be upgraded remotely:
+    Gotthard   

    Instructions available at
+        https://slsdetectorgroup.github.io/devdoc/firmware.html
+    and
        https://slsdetectorgroup.github.io/devdoc/serverupgrade.html



-
-3 Firmware Requirements
-========================
-
-
-    Eiger       20.02.2023 (v31)
-    
-    Jungfrau    16.05.2023 (v1.4.1, HW v1.0) 
-                15.05.2023 (v2.4.1, HW v2.0)
-
-    Mythen3     24.01.2023 (v1.4)
-
-    Gotthard2   23.11.2022 (v0.3)
-
-    Gotthard    08.02.2018 (50um and 25um Master)
-                09.02.2018 (25 um Slave) 
-
-    Moench      05.12.2022 (v0.3)
-
-    Ctb         05.12.2022 (v1.1)
-
-
-    Detector Upgrade
-    ----------------
-
-    The following can be upgraded remotely:
-
-    Eiger      via bit files
-    Jungfrau   via command <.pof>
-    Mythen3    via command <.rbf>
-    Gotthard2  via command <.rbf>
-    Moench     via command <.pof>
-    Ctb        via command <.pof>
-
-    Gotthard cannot be upgraded remotely  
-
-    Except Eiger, 
-        upgrade 
-            Using command 'programfpga' or
-
-        udpate both server and firmware simultaneously
-            Using command 'update'
-
-
-    Instructions available at
-        https://slsdetectorgroup.github.io/devdoc/firmware.html
-
-
-
-
-4 Kernel Requirements
+4. Kernel Requirements
 ======================

    Blackfin 
-    --------
+    ========
    Latest version: Fri Oct 29 00:00:00 2021
    
    Older ones will work, but might have issues with programming firmware via
    the package.

    Nios
-    -----
+    ====
    Compatible version: Mon May 10 18:00:21 CEST 2021

    Kernel Upgrade
-    ---------------
+    ==============
    Eiger   via bit files
    Others  via command

@ -180,8 +154,7 @@ This document describes the differences between v7.0.2 and v7.0.1



-
-5 Download, Documentation & Support
+5. Download, Documentation & Support
 ====================================

    Download
@ -194,10 +167,7 @@ This document describes the differences between v7.0.2 and v7.0.1
    -------------
    
    Installation:
-        https://slsdetectorgroup.github.io/devdoc/installation.html
-
-    Quick Start Guide:
-        https://slsdetectorgroup.github.io/devdoc/quick_start_guide.html
+        https://slsdetectorgroup.github.io/devdoc/installation.html#
        
    Firmware Upgrade:
        https://slsdetectorgroup.github.io/devdoc/firmware.html
@ -217,6 +187,9 @@ This document describes the differences between v7.0.2 and v7.0.1
    Command Line Documentation:
        https://slsdetectorgroup.github.io/devdoc/commandline.html

+    Quick Start Guide:
+        https://slsdetectorgroup.github.io/devdoc/quick_start_guide.html
+        
    C++ API Documentation:
        https://slsdetectorgroup.github.io/devdoc/detector.html
       
@ -233,16 +206,8 @@ This document describes the differences between v7.0.2 and v7.0.1
        https://slsdetectorgroup.github.io/devdoc/receivers.html
        https://slsdetectorgroup.github.io/devdoc/slsreceiver.html

-    Detector UDP Header:
-        https://slsdetectorgroup.github.io/devdoc/udpheader.html
-        https://slsdetectorgroup.github.io/devdoc/udpdetspec.html
-
-    slsReceiver Zmq Format:
-        https://slsdetectorgroup.github.io/devdoc/slsreceiver.html#zmq-json-header-format
-
    TroubleShooting:
        https://slsdetectorgroup.github.io/devdoc/troubleshooting.html
-        https://slsdetectorgroup.github.io/devdoc/troubleshooting.html#receiver-pc-tuning-options
        
    Further Documentation:
        https://www.psi.ch/en/detectors/documentation
--- a/cmake/FindQwt.cmake
+++ b/cmake/FindQwt.cmake
@ -0,0 +1,118 @@
+# Qt Widgets for Technical Applications
+# available at http://www.http://qwt.sourceforge.net/
+#
+# The module defines the following variables:
+#  QWT_FOUND - the system has Qwt
+#  QWT_INCLUDE_DIR - where to find qwt_plot.h
+#  QWT_INCLUDE_DIRS - qwt includes
+#  QWT_LIBRARY - where to find the Qwt library
+#  QWT_LIBRARIES - aditional libraries
+#  QWT_MAJOR_VERSION - major version
+#  QWT_MINOR_VERSION - minor version
+#  QWT_PATCH_VERSION - patch version
+#  QWT_VERSION_STRING - version (ex. 5.2.1)
+#  QWT_ROOT_DIR - root dir (ex. /usr/local)
+
+#=============================================================================
+# Copyright 2010-2013, Julien Schueller
+# All rights reserved.
+# 
+# Redistribution and use in source and binary forms, with or without
+# modification, are permitted provided that the following conditions are met: 
+# 
+# 1. Redistributions of source code must retain the above copyright notice, this
+#    list of conditions and the following disclaimer. 
+# 2. Redistributions in binary form must reproduce the above copyright notice,
+#    this list of conditions and the following disclaimer in the documentation
+#    and/or other materials provided with the distribution. 
+#
+# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND
+# ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+# WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+# DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR
+# ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+# (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+# LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+# ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+# SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+# The views and conclusions contained in the software and documentation are those
+# of the authors and should not be interpreted as representing official policies, 
+# either expressed or implied, of the FreeBSD Project.
+#=============================================================================
+
+
+find_path ( QWT_INCLUDE_DIR
+  NAMES qwt_plot.h
+  HINTS $ENV{QWTDIR} $ENV{QWTDIR}/src ${QT_INCLUDE_DIR}
+  PATH_SUFFIXES qwt qwt-qt3 qwt-qt4 qwt-qt5
+)
+
+set ( QWT_INCLUDE_DIRS ${QWT_INCLUDE_DIR} )
+
+# version
+set ( _VERSION_FILE ${QWT_INCLUDE_DIR}/qwt_global.h )
+if ( EXISTS ${_VERSION_FILE} )
+  file ( STRINGS ${_VERSION_FILE} _VERSION_LINE REGEX "define[ ]+QWT_VERSION_STR" )
+  if ( _VERSION_LINE )
+    string ( REGEX REPLACE ".*define[ ]+QWT_VERSION_STR[ ]+\"(.*)\".*" "\\1" QWT_VERSION_STRING "${_VERSION_LINE}" )
+    string ( REGEX REPLACE "([0-9]+)\\.([0-9]+)\\.([0-9]+)" "\\1" QWT_MAJOR_VERSION "${QWT_VERSION_STRING}" )
+    string ( REGEX REPLACE "([0-9]+)\\.([0-9]+)\\.([0-9]+)" "\\2" QWT_MINOR_VERSION "${QWT_VERSION_STRING}" )
+    string ( REGEX REPLACE "([0-9]+)\\.([0-9]+)\\.([0-9]+)" "\\3" QWT_PATCH_VERSION "${QWT_VERSION_STRING}" )
+  endif ()
+endif ()
+
+
+# check version
+set ( _QWT_VERSION_MATCH TRUE )
+if ( Qwt_FIND_VERSION AND QWT_VERSION_STRING )
+  if ( Qwt_FIND_VERSION_EXACT )
+    if ( NOT Qwt_FIND_VERSION VERSION_EQUAL QWT_VERSION_STRING )
+      set ( _QWT_VERSION_MATCH FALSE )
+    endif ()
+  else ()
+    if ( QWT_VERSION_STRING VERSION_LESS Qwt_FIND_VERSION )
+      set ( _QWT_VERSION_MATCH FALSE )
+    endif ()
+  endif ()
+endif ()
+
+
+find_library ( QWT_LIBRARY
+  NAMES qwt qwt-qt3 qwt-qt4 qwt-qt5
+  HINTS $ENV{QWTDIR}/lib ${QT_LIBRARY_DIR}
+)
+
+set ( QWT_LIBRARIES ${QWT_LIBRARY} )
+
+
+# try to guess root dir from include dir
+if ( QWT_INCLUDE_DIR )
+  string ( REGEX REPLACE "(.*)/include.*" "\\1" QWT_ROOT_DIR ${QWT_INCLUDE_DIR} )
+# try to guess root dir from library dir
+elseif ( QWT_LIBRARY )
+  string ( REGEX REPLACE "(.*)/lib[/|32|64].*" "\\1" QWT_ROOT_DIR ${QWT_LIBRARY} )
+endif ()
+
+
+# handle the QUIETLY and REQUIRED arguments
+include ( FindPackageHandleStandardArgs )
+if ( CMAKE_VERSION LESS 2.8.3 )
+  find_package_handle_standard_args( Qwt DEFAULT_MSG QWT_LIBRARY QWT_INCLUDE_DIR _QWT_VERSION_MATCH )
+else ()
+  find_package_handle_standard_args( Qwt REQUIRED_VARS QWT_LIBRARY QWT_INCLUDE_DIR _QWT_VERSION_MATCH VERSION_VAR QWT_VERSION_STRING )
+endif ()
+
+
+mark_as_advanced (
+  QWT_LIBRARY 
+  QWT_LIBRARIES
+  QWT_INCLUDE_DIR
+  QWT_INCLUDE_DIRS
+  QWT_MAJOR_VERSION
+  QWT_MINOR_VERSION
+  QWT_PATCH_VERSION
+  QWT_VERSION_STRING
+  QWT_ROOT_DIR
+)
--- a/cmk.sh
+++ b/cmk.sh
@ -18,7 +18,6 @@ CTBGUI=0
 MANUALS=0
 MANUALS_ONLY_RST=0
 MOENCHZMQ=0
-ZMQ_HINT_DIR=""


 CLEAN=0
@ -27,26 +26,25 @@ CMAKE_PRE=""
 CMAKE_POST=""

 usage() { echo -e "
-Usage: $0 [-b] [-c] [-d <HDF5 directory>] [e] [g] [-h] [i] [-j <Number of threads>] [-k <CMake command>] [-l <Install directory>] [m] [n] [-p] [-q <Zmq hint directory>] [r] [s] [t] [u] [z]  
+Usage: $0 [-c] [-b] [-p] [e] [t] [r] [g] [s] [u] [i] [m] [n] [-h] [z] [-d <HDF5 directory>] [-l Install directory] [-k <CMake command>] [-j <Number of threads>]
 -[no option]: only make
- -b: Builds/Rebuilds CMake files normal mode
 -c: Clean
- -d: HDF5 Custom Directory
- -e: Debug mode
- -g: Build/Rebuilds gui
+ -b: Builds/Rebuilds CMake files normal mode
+ -p: Builds/Rebuilds Python API
 -h: Builds/Rebuilds Cmake files with HDF5 package
- -i: Builds tests
- -j: Number of threads to compile through
+ -d: HDF5 Custom Directory
 -k: CMake command
 -l: Install directory
+ -t: Build/Rebuilds only text client
+ -r: Build/Rebuilds only receiver
+ -g: Build/Rebuilds only gui
+ -s: Simulator
+ -u: Chip Test Gui
+ -j: Number of threads to compile through
+ -e: Debug mode
+ -i: Builds tests
 -m: Manuals
 -n: Manuals without compiling doxygen (only rst)
- -p: Builds/Rebuilds Python API
- -q: Zmq hint directory
- -r: Build/Rebuilds only receiver
- -s: Simulator
- -t: Build/Rebuilds only text client
- -u: Chip Test Gui
 -z: Moench zmq processor

 Rebuild when you switch to a new build and compile in parallel:
@ -83,50 +81,69 @@ For rebuilding only certain sections
 
 " ; exit 1; }

-while getopts ":bcd:eghij:k:l:mnpq:rstuz" opt ; do
+while getopts ":bpchd:k:l:j:trgeisumnz" opt ; do
 	case $opt in
 	b) 
 		echo "Building of CMake files Required"
 		REBUILD=1
 		;;
+	p)
+    	echo "Compiling Options: Python" 
+		PYTHON=1
+		REBUILD=1
+		;;   
 	c) 
 		echo "Clean Required"
 		CLEAN=1
 		;;
-	d) 
-		echo "New HDF5 directory: $OPTARG" 
-		HDF5DIR=$OPTARG
-		;;
-	e)
-		echo "Compiling Options: Debug" 
-		DEBUG=1
-		;;  
-	g) 
-		echo "Compiling Options: GUI" 
-		GUI=1
-		REBUILD=1
-		;; 
 	h) 
 		echo "Building of CMake files with HDF5 option Required"
 		HDF5=1
 		REBUILD=1
 		;;
-	i)
-		echo "Compiling Options: Tests" 
-		TESTS=1
-		;;   
-	j) 
-		echo "Number of compiler threads: $OPTARG" 
-		COMPILERTHREADS=$OPTARG
-		;;
-	k)
-		echo "CMake command: $OPTARG"
-		CMAKE="$OPTARG"
+	d) 
+		echo "New HDF5 directory: $OPTARG" 
+		HDF5DIR=$OPTARG
 		;;
 	l)
 		echo "CMake install directory: $OPTARG"
 		INSTALLDIR="$OPTARG"
 		;;
+	k)
+		echo "CMake command: $OPTARG"
+		CMAKE="$OPTARG"
+		;;
+	j) 
+		echo "Number of compiler threads: $OPTARG" 
+		COMPILERTHREADS=$OPTARG
+		;;
+	t) 
+    	echo "Compiling Options: Text Client" 
+		TEXTCLIENT=1
+		REBUILD=1
+		;;      
+	r) 
+		echo "Compiling Options: Receiver" 
+		RECEIVER=1
+		REBUILD=1
+		;;      
+	g) 
+		echo "Compiling Options: GUI" 
+		GUI=1
+		REBUILD=1
+		;;  
+	e)
+		echo "Compiling Options: Debug" 
+		DEBUG=1
+		;;   
+	i)
+		echo "Compiling Options: Tests" 
+		TESTS=1
+		;;   
+	s)
+		echo "Compiling Options: Simulator" 
+		SIMULATOR=1
+		;; 
 	m)	
 		echo "Compiling Manuals"
 		MANUALS=1
@ -135,37 +152,14 @@ while getopts ":bcd:eghij:k:l:mnpq:rstuz" opt ; do
 		echo "Compiling Manuals (Only RST)"
 		MANUALS_ONLY_RST=1
 		;;
-	p)
-    	echo "Compiling Options: Python" 
-		PYTHON=1
-		REBUILD=1
-		;;   
-	q) 
-		echo "Zmq hint directory: $OPTARG" 
-		ZMQ_HINT_DIR=$OPTARG
-		;;
-	r) 
-		echo "Compiling Options: Receiver" 
-		RECEIVER=1
-		REBUILD=1
-		;;      
-	s)
-		echo "Compiling Options: Simulator" 
-		SIMULATOR=1
-		;; 
-	t) 
-    	echo "Compiling Options: Text Client" 
-		TEXTCLIENT=1
-		REBUILD=1
+	z)	
+		echo "Compiling Moench Zmq Processor"
+		MOENCHZMQ=1
 		;;
 	u)
 		echo "Compiling Options: Chip Test Gui"
 		CTBGUI=1
 		;;
-	z)	
-		echo "Compiling Moench Zmq Processor"
-		MOENCHZMQ=1
-		;;
  \?)
    echo "Invalid option: -$OPTARG" 
 		usage
@ -260,12 +254,6 @@ if [ $TESTS -eq 1 ]; then
 	echo "Tests Option enabled"
 fi 

-#zmq hint dir
-if [ -n "$ZMQ_HINT_DIR" ]; then
-	CMAKE_POST+=" -DZeroMQ_HINT="$ZMQ_HINT_DIR
-	CMAKE_POST+=" -DZeroMQ_DIR="
-#	echo "Enabling Zmq Hint Directory: $ZMQ_HINT_DIR"
-fi 

 #hdf5 rebuild
 if [ $HDF5 -eq 1 ]; then
--- a/conda-recepie/conda_build_config.yaml
+++ b/conda-recepie/conda_build_config.yaml
@ -1,8 +0,0 @@
-python:
-    - 3.8
-    - 3.9
-    - 3.10
-    - 3.11
-    
-numpy: 
-    - 1.17
--- a/conda-recepie/copy_ctbgui.sh
+++ b/conda-recepie/copy_ctbgui.sh
@ -1,11 +0,0 @@
-# SPDX-License-Identifier: LGPL-3.0-or-other
-# Copyright (C) 2021 Contributors to the SLS Detector Package
-mkdir $PREFIX/lib
-mkdir $PREFIX/bin
-mkdir $PREFIX/include
-
-
-
-cp build/bin/ctbGui $PREFIX/bin/.
-cp build/bin/libctbRootLib.so $PREFIX/lib/.
-
--- a/conda-recepie/copy_gui.sh
+++ b/conda-recepie/copy_gui.sh
@ -1,5 +0,0 @@
-# SPDX-License-Identifier: LGPL-3.0-or-other
-# Copyright (C) 2021 Contributors to the SLS Detector Package
-#Copy the GUI 
-mkdir -p $PREFIX/bin
-cp build/install/bin/slsDetectorGui $PREFIX/bin/.
--- a/conda-recepie/copy_lib.sh
+++ b/conda-recepie/copy_lib.sh
@ -1,22 +0,0 @@
-# SPDX-License-Identifier: LGPL-3.0-or-other
-# Copyright (C) 2021 Contributors to the SLS Detector Package
-
-mkdir -p $PREFIX/lib
-mkdir -p $PREFIX/bin
-mkdir -p $PREFIX/include/sls
-# mkdir $PREFIX/include/slsDetectorPackage
-
-#Shared and static libraries
-cp build/install/lib/* $PREFIX/lib/
-
-#Binaries
-cp build/install/bin/sls_detector_acquire $PREFIX/bin/.
-cp build/install/bin/sls_detector_get $PREFIX/bin/.
-cp build/install/bin/sls_detector_put $PREFIX/bin/.
-cp build/install/bin/sls_detector_help $PREFIX/bin/.
-cp build/install/bin/slsReceiver $PREFIX/bin/.
-cp build/install/bin/slsMultiReceiver $PREFIX/bin/.
-
-
-cp build/install/include/sls/* $PREFIX/include/sls
-cp -rv build/install/share $PREFIX
--- a/conda-recepie/copy_moench.sh
+++ b/conda-recepie/copy_moench.sh
@ -1,6 +0,0 @@
-# SPDX-License-Identifier: LGPL-3.0-or-other
-# Copyright (C) 2021 Contributors to the SLS Detector Package
-
-#Copy the Moench executables 
-mkdir -p $PREFIX/bin
-cp build/install/bin/moench* $PREFIX/bin/.
--- a/conda-recepie/meta.yaml
+++ b/conda-recepie/meta.yaml
@ -1,131 +0,0 @@
-
-package:
-  name: sls_detector_software
-  version: {{ environ.get('GIT_DESCRIBE_TAG', '') }}
-
-source:
-  - path: ..
-
-build:
-  number: 0
-  binary_relocation: True
-  rpaths:
-    - lib/
-
-requirements:
-  build:
-    - {{ compiler('c') }}
-    - {{compiler('cxx')}}
-    - cmake
-    - qt 5.*
-    - zeromq
-    - xorg-libx11
-    - xorg-libice
-    - xorg-libxext
-    - xorg-libsm
-    - xorg-libxau
-    - xorg-libxrender
-    - xorg-libxfixes
-    - {{ cdt('mesa-libgl-devel') }}      # [linux]
-    - {{ cdt('mesa-libegl-devel') }}     # [linux]
-    - {{ cdt('mesa-dri-drivers') }}      # [linux]
-    - {{ cdt('libselinux') }}            # [linux]
-    - {{ cdt('libxdamage') }}            # [linux]
-    - {{ cdt('libxxf86vm') }}            # [linux]
-    - expat
-
-  host:
-    - libstdcxx-ng
-    - libgcc-ng
-    - zeromq
-    - xorg-libx11
-    - xorg-libice
-    - xorg-libxext
-    - xorg-libsm
-    - xorg-libxau
-    - xorg-libxrender
-    - xorg-libxfixes
-    - expat
-
-  run:
-    - zeromq
-    - libstdcxx-ng
-    - libgcc-ng 
-
-
-outputs:
-  - name: slsdetlib
-    script: copy_lib.sh
-
-    requirements:
-      build:
-        - {{ compiler('c') }}
-        - {{compiler('cxx')}}
-        - libstdcxx-ng
-        - libgcc-ng
-        - zeromq
-
-      host:
-        - zeromq
-
-      run: 
-        - libstdcxx-ng
-        - libgcc-ng
-        - zeromq
-
-  - name: slsdet
-
-    script: build_pylib.sh
-
-    requirements:
-      build:
-        - python
-        - {{ compiler('c') }}
-        - {{compiler('cxx')}}
-        - {{ pin_subpackage('slsdetlib', exact=True) }}
-        - setuptools
-
-      host:
-        - python
-        - {{ pin_subpackage('slsdetlib', exact=True) }}
-
-
-      run:
-        - libstdcxx-ng
-        - libgcc-ng
-        - python
-        - numpy
-        - {{ pin_subpackage('slsdetlib', exact=True) }}
-
-
-    test:
-      imports:
-        - slsdet
-
-  - name: slsdetgui
-    script: copy_gui.sh
-    requirements:
-
-      build:
-        - {{ compiler('c') }}
-        - {{compiler('cxx')}}
-        - {{ pin_subpackage('slsdetlib', exact=True) }}
-
-      run:
-        - {{ pin_subpackage('slsdetlib', exact=True) }}
-        - qt 5.*
-        - expat
-
-  - name: moenchzmq
-    script: copy_moench.sh
-    requirements:
-
-      build:
-        - {{ compiler('c') }}
-        - {{compiler('cxx')}}
-        - {{ pin_subpackage('slsdetlib', exact=True) }}
-
-
-      run:
-        - {{ pin_subpackage('slsdetlib', exact=True) }}
-        - expat
--- a/conda-recepie/run_test.sh
+++ b/conda-recepie/run_test.sh
@ -1,3 +0,0 @@
-# SPDX-License-Identifier: LGPL-3.0-or-other
-# Copyright (C) 2021 Contributors to the SLS Detector Package
-ctest -j2
--- a/conda-recipes/ctbgui/build.sh
+++ b/conda-recipes/ctbgui/build.sh
@ -0,0 +1,24 @@
+# SPDX-License-Identifier: LGPL-3.0-or-other
+# Copyright (C) 2021 Contributors to the SLS Detector Package
+
+mkdir build
+
+cd build
+cmake .. \
+      -DCMAKE_PREFIX_PATH=$CONDA_PREFIX \
+      -DCMAKE_INSTALL_PREFIX=$PREFIX \
+      -DSLS_USE_CTBGUI=ON \
+      -DSLS_EXT_BUILD=ON\
+      -DCMAKE_BUILD_TYPE=Release \
+      -DSLS_USE_HDF5=OFF\
+     
+NCORES=$(getconf _NPROCESSORS_ONLN)
+echo "Building using: ${NCORES} cores"
+cmake --build . -- -j${NCORES}
+cmake --build . --target install
+
+CTEST_OUTPUT_ON_FAILURE=1 ctest -j 2
+
+#Clean up for the next build
+# cd ..
+# rm -rf build
--- a/conda-recipes/ctbgui/meta.yaml
+++ b/conda-recipes/ctbgui/meta.yaml
@ -0,0 +1,94 @@
+package:
+  name: ctbgui
+  version: {{ environ.get('GIT_DESCRIBE_TAG', '') }}
+
+source:
+  - path: ../..
+
+build:
+  number: 0
+  binary_relocation: True
+  rpaths:
+    - lib/
+
+requirements:
+  build:
+    - {{ compiler('c') }}
+    - {{compiler('cxx')}}
+    - slsdetlib {{ environ.get('GIT_DESCRIBE_TAG', '') }}
+    - cmake
+    - root
+    # - qwt 6.*
+    # - qt 4.8.*
+    # - zeromq
+    # - xorg-libx11
+    # - xorg-libice
+    # - xorg-libxext
+    # - xorg-libsm
+    # - xorg-libxau
+    # - xorg-libxrender
+    # - xorg-libxfixes
+    # - {{ cdt('mesa-libgl-devel') }}      # [linux]
+    # - {{ cdt('mesa-libegl-devel') }}     # [linux]
+    # - {{ cdt('mesa-dri-drivers') }}      # [linux]
+    # - {{ cdt('libselinux') }}            # [linux]
+    # - {{ cdt('libxdamage') }}            # [linux]
+    # - {{ cdt('libxxf86vm') }}            # [linux]
+    # - expat
+
+  host:
+    - libstdcxx-ng
+    - libgcc-ng
+    - root
+    - slsdetlib {{ environ.get('GIT_DESCRIBE_TAG', '') }}
+    # - zeromq
+    # - xorg-libx11
+    # - xorg-libice
+    # - xorg-libxext
+    # - xorg-libsm
+    # - xorg-libxau
+    # - xorg-libxrender
+    # - xorg-libxfixes
+    # - expat
+
+  run:
+    # - zeromq
+    - libstdcxx-ng
+    - libgcc-ng 
+    - root
+    # - slsdetlib {{ environ.get('GIT_DESCRIBE_TAG', '') }}
+    # - qwt 6.*
+    # - qt 4.8.*
+    # - expat
+
+
+
+  # - name: slsdetgui
+  #   script: copy_gui.sh
+  #   requirements:
+
+  #     build:
+  #       - {{ compiler('c') }}
+  #       - {{compiler('cxx')}}
+  #       - {{ pin_subpackage('slsdetlib', exact=True) }}
+  #       - qwt 6.*
+
+  #     run:
+  #       - {{ pin_subpackage('slsdetlib', exact=True) }}
+  #       - qwt 6.*
+  #       - qt 4.8.*
+  #       - expat
+
+  # - name: moenchzmq
+  #   script: copy_moench.sh
+  #   requirements:
+
+  #     build:
+  #       - {{ compiler('c') }}
+  #       - {{compiler('cxx')}}
+  #       - {{ pin_subpackage('slsdetlib', exact=True) }}
+
+
+  #     run:
+  #       - {{ pin_subpackage('slsdetlib', exact=True) }}
+  #       - expat
--- a/conda-recipes/moenchzmq/build.sh
+++ b/conda-recipes/moenchzmq/build.sh
@ -0,0 +1,25 @@
+# SPDX-License-Identifier: LGPL-3.0-or-other
+# Copyright (C) 2021 Contributors to the SLS Detector Package
+
+mkdir build
+
+cd build
+cmake .. \
+      -DCMAKE_PREFIX_PATH=$CONDA_PREFIX \
+      -DCMAKE_INSTALL_PREFIX=$PREFIX \
+      -DSLS_USE_MOENCH=ON\
+      -DSLS_USE_TESTS=ON \
+      -DSLS_EXT_BUILD=ON \
+      -DCMAKE_BUILD_TYPE=Release \
+      -DSLS_USE_HDF5=OFF\
+     
+NCORES=$(getconf _NPROCESSORS_ONLN)
+echo "Building using: ${NCORES} cores"
+cmake --build . -- -j${NCORES}
+cmake --build . --target install
+
+CTEST_OUTPUT_ON_FAILURE=1 ctest -j 2
+
+#Clean up for the next build
+# cd ..
+# rm -rf build
--- a/conda-recipes/moenchzmq/meta.yaml
+++ b/conda-recipes/moenchzmq/meta.yaml
@ -0,0 +1,36 @@
+
+package:
+  name: moenchzmq
+  version: {{ environ.get('GIT_DESCRIBE_TAG', '') }}
+
+source:
+  - path: ../..
+
+build:
+  number: 0
+  binary_relocation: True
+  rpaths:
+    - lib/
+
+requirements:
+  build:
+    - {{ compiler('c') }}
+    - {{compiler('cxx')}}
+    - cmake
+    - libstdcxx-ng
+    - libgcc-ng
+    - zeromq
+    - libtiff
+    - slsdetlib {{ environ.get('GIT_DESCRIBE_TAG', '') }}
+
+  host:
+    - zeromq
+    - libtiff
+    - slsdetlib {{ environ.get('GIT_DESCRIBE_TAG', '') }}
+
+  run: 
+    - libstdcxx-ng
+    - libgcc-ng
+    - zeromq
+    - libtiff
+    - slsdetlib {{ environ.get('GIT_DESCRIBE_TAG', '') }}
--- a/conda-recipes/slsdet/build.sh
+++ b/conda-recipes/slsdet/build.sh
@ -2,5 +2,7 @@
 # Copyright (C) 2021 Contributors to the SLS Detector Package

 echo "|<-------- starting python build"
+echo $PWD
 cd python
-${PYTHON} setup.py install
+echo "folder: $PWD"
+${PYTHON} setup.py install
--- a/conda-recipes/slsdet/conda_build_config.yaml
+++ b/conda-recipes/slsdet/conda_build_config.yaml
@ -0,0 +1,2 @@
+python: 
+   - 3.9
--- a/conda-recipes/slsdet/meta.yaml
+++ b/conda-recipes/slsdet/meta.yaml
@ -0,0 +1,34 @@
+
+package:
+  name: slsdet
+  version: {{ environ.get('GIT_DESCRIBE_TAG', '') }}
+
+source:
+  - path: ../..
+
+build:
+  number: 0
+  binary_relocation: True
+  rpaths:
+    - lib/
+
+requirements:
+  build:
+    - python
+    - {{ compiler('c') }}
+    - {{compiler('cxx')}}
+    - cmake
+    - slsdetlib {{ environ.get('GIT_DESCRIBE_TAG', '') }}
+    - setuptools
+
+  host:
+    - python
+    - slsdetlib {{ environ.get('GIT_DESCRIBE_TAG', '') }}
+
+
+  run:
+    - libstdcxx-ng
+    - libgcc-ng
+    - python
+    - numpy
+    - slsdetlib {{ environ.get('GIT_DESCRIBE_TAG', '') }}
--- a/conda-recipes/slsdetgui/build.sh
+++ b/conda-recipes/slsdetgui/build.sh
@ -0,0 +1,24 @@
+# SPDX-License-Identifier: LGPL-3.0-or-other
+# Copyright (C) 2021 Contributors to the SLS Detector Package
+
+mkdir build
+
+cd build
+cmake .. \
+      -DCMAKE_PREFIX_PATH=$CONDA_PREFIX \
+      -DCMAKE_INSTALL_PREFIX=$PREFIX \
+      -DSLS_USE_GUI=ON \
+      -DSLS_EXT_BUILD=ON\
+      -DCMAKE_BUILD_TYPE=Release \
+      -DSLS_USE_HDF5=OFF\
+     
+NCORES=$(getconf _NPROCESSORS_ONLN)
+echo "Building using: ${NCORES} cores"
+cmake --build . -- -j${NCORES}
+cmake --build . --target install
+
+CTEST_OUTPUT_ON_FAILURE=1 ctest -j 2
+
+#Clean up for the next build
+# cd ..
+# rm -rf build
--- a/conda-recipes/slsdetgui/meta.yaml
+++ b/conda-recipes/slsdetgui/meta.yaml
@ -0,0 +1,91 @@
+package:
+  name: slsdetgui
+  version: {{ environ.get('GIT_DESCRIBE_TAG', '') }}
+
+source:
+  - path: ../..
+
+build:
+  number: 0
+  binary_relocation: True
+  rpaths:
+    - lib/
+
+requirements:
+  build:
+    - {{ compiler('c') }}
+    - {{compiler('cxx')}}
+    - slsdetlib {{ environ.get('GIT_DESCRIBE_TAG', '') }}
+    - cmake
+    - qwt 6.*
+    - qt 4.8.*
+    - zeromq
+    - xorg-libx11
+    - xorg-libice
+    - xorg-libxext
+    - xorg-libsm
+    - xorg-libxau
+    - xorg-libxrender
+    - xorg-libxfixes
+    - {{ cdt('mesa-libgl-devel') }}      # [linux]
+    - {{ cdt('mesa-libegl-devel') }}     # [linux]
+    - {{ cdt('mesa-dri-drivers') }}      # [linux]
+    - {{ cdt('libselinux') }}            # [linux]
+    - {{ cdt('libxdamage') }}            # [linux]
+    - {{ cdt('libxxf86vm') }}            # [linux]
+    - expat
+
+  host:
+    - libstdcxx-ng
+    - libgcc-ng
+    - slsdetlib {{ environ.get('GIT_DESCRIBE_TAG', '') }}
+    - zeromq
+    - xorg-libx11
+    - xorg-libice
+    - xorg-libxext
+    - xorg-libsm
+    - xorg-libxau
+    - xorg-libxrender
+    - xorg-libxfixes
+    - expat
+
+  run:
+    - zeromq
+    - libstdcxx-ng
+    - libgcc-ng 
+    - slsdetlib {{ environ.get('GIT_DESCRIBE_TAG', '') }}
+    - qwt 6.*
+    - qt 4.8.*
+    - expat
+
+
+
+  # - name: slsdetgui
+  #   script: copy_gui.sh
+  #   requirements:
+
+  #     build:
+  #       - {{ compiler('c') }}
+  #       - {{compiler('cxx')}}
+  #       - {{ pin_subpackage('slsdetlib', exact=True) }}
+  #       - qwt 6.*
+
+  #     run:
+  #       - {{ pin_subpackage('slsdetlib', exact=True) }}
+  #       - qwt 6.*
+  #       - qt 4.8.*
+  #       - expat
+
+  # - name: moenchzmq
+  #   script: copy_moench.sh
+  #   requirements:
+
+  #     build:
+  #       - {{ compiler('c') }}
+  #       - {{compiler('cxx')}}
+  #       - {{ pin_subpackage('slsdetlib', exact=True) }}
+
+
+  #     run:
+  #       - {{ pin_subpackage('slsdetlib', exact=True) }}
+  #       - expat
--- a/conda-recipes/slsdetlib/build.sh
+++ b/conda-recipes/slsdetlib/build.sh
@ -2,17 +2,18 @@
 # Copyright (C) 2021 Contributors to the SLS Detector Package

 mkdir build
-mkdir install
+
 cd build
 cmake .. \
      -DCMAKE_PREFIX_PATH=$CONDA_PREFIX \
-      -DCMAKE_INSTALL_PREFIX=install \
+      -DCMAKE_INSTALL_PREFIX=$PREFIX \
      -DSLS_USE_TEXTCLIENT=ON \
      -DSLS_USE_RECEIVER=ON \
-      -DSLS_USE_GUI=ON \
-      -DSLS_USE_MOENCH=ON\
+      -DSLS_USE_GUI=OFF \
+      -DSLS_USE_MOENCH=OFF\
      -DSLS_USE_TESTS=ON \
      -DSLS_USE_PYTHON=OFF \
+      -DSLS_DEVEL_HEADERS=ON \
      -DCMAKE_BUILD_TYPE=Release \
      -DSLS_USE_HDF5=OFF\
     
@ -21,4 +22,8 @@ echo "Building using: ${NCORES} cores"
 cmake --build . -- -j${NCORES}
 cmake --build . --target install

-CTEST_OUTPUT_ON_FAILURE=1 ctest -j 1
+CTEST_OUTPUT_ON_FAILURE=1 ctest -j 2
+
+#Clean up for the next build
+# cd ..
+# rm -rf build
--- a/conda-recipes/slsdetlib/meta.yaml
+++ b/conda-recipes/slsdetlib/meta.yaml
@ -0,0 +1,90 @@
+
+package:
+  name: slsdetlib
+  version: {{ environ.get('GIT_DESCRIBE_TAG', '') }}
+
+source:
+  - path: ../..
+
+build:
+  number: 0
+  binary_relocation: True
+  rpaths:
+    - lib/
+
+requirements:
+      build:
+        - {{ compiler('c') }}
+        - {{compiler('cxx')}}
+        - cmake
+        - libstdcxx-ng
+        - libgcc-ng
+        - zeromq
+
+      host:
+        - zeromq
+
+      run: 
+        - libstdcxx-ng
+        - libgcc-ng
+        - zeromq
+
+
+# outputs:
+#   - name: slsdetlib
+#     script: build_lib.sh
+
+#     requirements:
+#       build:
+#         - {{ compiler('c') }}
+#         - {{compiler('cxx')}}
+#         - libstdcxx-ng
+#         - libgcc-ng
+#         - zeromq
+
+#       host:
+#         - zeromq
+
+#       run: 
+#         - libstdcxx-ng
+#         - libgcc-ng
+#         - zeromq
+
+  # - name: slsdet
+  #   script: build_py.sh
+
+    # requirements:
+    #   build:
+    #     - python
+    #     - {{ compiler('c') }}
+    #     - {{compiler('cxx')}}
+    #     - {{ pin_subpackage('slsdetlib', exact=True) }}
+    #     - setuptools
+
+    #   host:
+    #     - python
+    #     - {{ pin_subpackage('slsdetlib', exact=True) }}
+
+
+    #   run:
+    #     - libstdcxx-ng
+    #     - libgcc-ng
+    #     - python
+    #     - numpy
+    #     - {{ pin_subpackage('slsdetlib', exact=True) }}
+
+  # - name: slsdetgui
+  #   script: build_gui.sh
+  #   requirements:
+
+  #     build:
+  #       - {{ compiler('c') }}
+  #       - {{compiler('cxx')}}
+  #       - {{ pin_subpackage('slsdetlib', exact=True) }}
+  #       - qwt 6.*
+
+  #     run:
+  #       - {{ pin_subpackage('slsdetlib', exact=True) }}
+  #       - qwt 6.*
+  #       - qt 4.8.*
+  #       - expat
--- a/ctbGui/CMakeLists.txt
+++ b/ctbGui/CMakeLists.txt
@ -83,8 +83,12 @@ target_link_libraries(ctbGui PUBLIC
    ${TIFF_LIBRARIES}
 )

-set_target_properties(ctbGui PROPERTIES
-    RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin
-
-)
+#set_target_properties(ctbGui PROPERTIES
+#    RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin
+#
+#)

+install(TARGETS ctbGui ctbRootLib
+    RUNTIME DESTINATION ${CMAKE_INSTALL_BINDIR}
+    LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR}
+)
--- a/ctbGui/ctbAcquisition.cpp
+++ b/ctbGui/ctbAcquisition.cpp
@ -828,14 +828,14 @@ void ctbAcquisition::setCanvas(TCanvas* c) {
  myCanvas->AddExec("dynamic",Form("((ctbAcquisition*)%p)->canvasClicked()",this));
  // myCanvas->AddExec("ex","canvasClicked()");
 }
-void ctbAcquisition::dataCallback(sls::detectorData *data, long unsigned int index, unsigned int dum, void* pArgs) {
+void ctbAcquisition::dataCallback(detectorData *data, long unsigned int index, unsigned int dum, void* pArgs) {

  // return 
  ((ctbAcquisition*)pArgs)->plotData(data,index);
 }


-int ctbAcquisition::plotData(sls::detectorData *data, int index) {
+int ctbAcquisition::plotData(detectorData *data, int index) {

  /*
 ******************************************************************
@ -988,7 +988,7 @@ sample1 (dbit0 + dbit1 +...)if (cmd == "rx_dbitlist") {
 	ped=0;
 	aval=dataStructure->getValue(data->data,x,y);
 	//aval=dataStructure->getChannel(data->data,x,y);
-	// cout << x << " " <<y << " "<< aval << endl;
+	cout << x << " " <<y << " "<< aval << endl;
 	if (cbGetPedestal->IsOn()) {
 	  if (photonFinder) {
 	    photonFinder->addToPedestal(aval,x,y);
--- a/ctbGui/ctbAcquisition.h
+++ b/ctbGui/ctbAcquisition.h
@ -28,8 +28,8 @@ class TGTextButton;
 namespace sls
 {
   class Detector;
-   class detectorData;
 };
+class detectorData;

 template <class dataType> class slsDetectorData;

@ -201,10 +201,10 @@ class ctbAcquisition : public TGGroupFrame {
   void setBitGraph (int i ,int en, Pixel_t col);
   void startAcquisition();
   static   void progressCallback(double,void*);
-   static void dataCallback(sls::detectorData*, long unsigned int, unsigned int,  void*);
+   static void dataCallback(detectorData*, long unsigned int, unsigned int,  void*);
   int StopFlag;
   
-   int plotData(sls::detectorData*, int);
+   int plotData(detectorData*, int);

   void setPatternFile(const char* t);

--- a/ctbGui/patternGenerator/deserializer.cpp
+++ b/ctbGui/patternGenerator/deserializer.cpp
@ -0,0 +1,112 @@
+// SPDX-License-Identifier: LGPL-3.0-or-other
+// Copyright (C) 2021 Contributors to the SLS Detector Package
+
+#include <stdlib.h>  
+#include <stdint.h>  
+#include <string.h>  
+#include <sys/utsname.h>   
+#include <sys/types.h>
+#include <unistd.h>  
+#include <sys/types.h>
+#include <sys/stat.h>
+#include <errno.h>
+#include <math.h>
+#include <fcntl.h>
+#include <stdarg.h>
+#include <stdio.h>
+#include <string.h>
+#include <unistd.h>
+
+int main(int argc, char *argv[]) {
+
+  int iarg;
+  char fname[10000];
+  uint64_t word;
+  int val[64];
+  int bit[64];
+  FILE *fdin;
+  
+  int nb=2;
+  int off=0;
+  int ioff=0;
+  int dr=24;
+  int idr=0;
+  int ib=0;
+  int iw=0;
+  bit[0]=19;
+  bit[1]=8;
+  //  for (iarg=0; iarg<argc; iarg++) printf("%d %s\n",iarg, argv[iarg]);
+  
+  if (argc<2) printf("Error: usage is %s fname [dr off  b0 b1 bn]\n");
+  
+  if (argc>2) dr=atoi(argv[2]);
+  if (argc>3) off=atoi(argv[3]);
+  if (argc>4) {
+  for (ib=0; ib<64; ib++) {
+    if (argc>4+ib) {
+      bit[ib]=atoi(argv[4+ib]);
+      nb++;
+    }
+  }
+  
+  }
+  
+  idr=0;
+  for (ib=0; ib<nb; ib++) {
+    val[ib]=0;
+  }
+  
+  
+  fdin=fopen(argv[1],"rb");
+  if (fdin==NULL) {
+    printf("Cannot open input file %s for reading\n",argv[1]);
+    return 200;
+  } 
+  
+  while (fread((void*)&word, 8, 1, fdin)) {
+    //   printf("%llx\n",word);
+    if (ioff<off) ioff++;
+    else {
+      
+      for (ib=0; ib<nb; ib++) {
+	if (word&(1<<bit[ib])) 	  val[ib]|=(1<<idr);
+      }
+      idr++;
+      if (idr==dr) {
+	idr=0;
+	fprintf(stdout,"%d\t",iw++);
+	for (ib=0; ib<nb; ib++) {
+#ifdef HEX
+	  fprintf(stdout,"%08llx\t",val[ib]);
+#else
+	  fprintf(stdout,"%lld\t",val[ib]);
+	  
+#endif
+	  
+	  val[ib]=0;
+	}
+	fprintf(stdout,"\n");
+      }
+      
+    }
+
+  }
+  if (idr!=0) {
+    fprintf(stdout,"%d\t",iw++);
+    for (ib=0; ib<nb; ib++) {
+#ifdef HEX
+	  fprintf(stdout,"%08llx\t",val[ib]);
+#else
+	  fprintf(stdout,"%lld\t",val[ib]);
+	  
+#endif
+	  
+	  val[ib]=0;
+    }
+    fprintf(stdout,"\n");
+  }
+
+  fclose(fdin);
+
+  return 0;
+}
--- a/ctbGui/patternGenerator/generate.sh
+++ b/ctbGui/patternGenerator/generate.sh
--- a/ctbGui/patternGenerator/generator.c
+++ b/ctbGui/patternGenerator/generator.c
@ -0,0 +1,179 @@
+// SPDX-License-Identifier: LGPL-3.0-or-other
+// Copyright (C) 2021 Contributors to the SLS Detector Package
+/****************************************************************************
+usage to generate a patter test.pat from test.p
+
+gcc -DINFILE="\"test.p\"" -DOUTFILE="\"test.pat\"" -o test.exe generator.c ; ./test.exe ; rm test.exe
+
+
+*************************************************************************/
+
+#include <stdlib.h>  
+#include <stdint.h>  
+#include <string.h>  
+#include <sys/utsname.h>   
+#include <sys/types.h>
+#include <unistd.h>  
+#include <sys/types.h>
+#include <sys/stat.h>
+#include <errno.h>
+#include <math.h>
+#include <fcntl.h>
+#include <stdarg.h>
+#include <stdio.h>
+#include <string.h>
+#include <unistd.h>
+
+#define MAXLOOPS 3
+#define MAXTIMERS 3
+#define MAXWORDS 1024
+
+
+
+uint64_t pat=0;
+uint64_t iopat=0;
+uint64_t clkpat=0;
+
+int iaddr=0;
+int waitaddr[3]={MAXWORDS,MAXWORDS,MAXWORDS};
+int startloopaddr[3]={MAXWORDS,MAXWORDS,MAXWORDS}; 
+int stoploopaddr[3]={MAXWORDS,MAXWORDS,MAXWORDS}; 
+int start=0, stop=0;
+uint64_t waittime[3]={0,0,0};
+int nloop[3]={0,0,0};
+
+char infile[10000], outfile[10000];
+
+FILE *fd, *fd1;
+uint64_t PAT[MAXWORDS];
+
+
+int i,ii,iii,j,jj,jjj,pixx,pixy,memx,memy,muxout,memclk,colclk,rowclk,muxclk,memcol,memrow,loopcounter;
+
+void setstart() {
+  start=iaddr;
+}
+
+void setstop() {
+  stop=iaddr;
+}
+
+void setinput(int bit) {
+  uint64_t mask=1;
+  mask=mask<<bit;
+  iopat &= ~mask;
+}
+
+void setoutput(int bit) {
+  uint64_t mask=1;
+  mask=mask<<bit;
+  iopat |= mask;
+}
+/*
+void setclk(int bit) {
+  uint64_t mask=1;
+  mask=mask<<bit;
+  iopat |= mask;
+  clkpat |= mask;
+}
+*/
+void clearbit(int bit){
+  uint64_t mask=1;
+  mask=mask<<bit;
+  pat &= ~mask;
+}
+void setbit(int bit){
+  uint64_t mask=1;
+  mask=mask<<bit;
+  pat |= mask;
+}
+
+int checkbit(int bit) {
+  uint64_t mask=1;
+  mask=mask<<bit;
+  return (pat & mask ) >>bit;
+}
+
+void setstartloop(int iloop) {
+  if (iloop>=0 && iloop<MAXLOOPS)
+    startloopaddr[iloop]=iaddr;
+}
+
+
+void setstoploop(int iloop) {
+  if (iloop>=0 && iloop<MAXLOOPS)
+    stoploopaddr[iloop]=iaddr;
+}
+
+
+void setnloop(int iloop, int n) {
+  if (iloop>=0 && iloop<MAXLOOPS)
+    nloop[iloop]=n;
+}
+
+void setwaitpoint(int iloop) {
+  if (iloop>=0 && iloop<MAXTIMERS)
+    waitaddr[iloop]=iaddr;
+}
+
+
+void setwaittime(int iloop, uint64_t t) {
+  if (iloop>=0 && iloop<MAXTIMERS)
+    waittime[iloop]=t;
+}
+
+
+
+
+void pw(){
+  if (iaddr<MAXWORDS)
+    PAT[iaddr]= pat;
+  fprintf(fd,"patword 0x%04x 0x%016llx\n",iaddr, pat);
+  iaddr++;
+  if (iaddr>=MAXWORDS) printf("ERROR: too many word in the pattern (%d instead of %d)!",iaddr, MAXWORDS);
+}
+
+int parseCommand(int clk, int cmdbit, int cmd, int length) {
+  int ibit;
+  clearbit(clk);
+  for (ibit=0; ibit<length; ibit++) {
+    if (cmd&(1>>ibit))
+      setbit(cmdbit);
+    else
+      clearbit(cmdbit);
+    pw();
+    /******/
+    setbit(clk);
+    pw();
+    /******/
+  }
+};
+
+
+
+main(void) {
+  int iloop=0;
+  fd=fopen(OUTFILE,"w");
+#include INFILE
+
+  fprintf(fd,"patioctrl 0x%016llx\n",iopat);
+  //fprintf(fd,"patclkctrl 0x%016llx\n",clkpat);
+  fprintf(fd,"patlimits 0x%04x 0x%04x\n",start, stop);
+
+  for (iloop=0; iloop<MAXLOOPS; iloop++) {
+    fprintf(fd,"patloop%d 0x%04x 0x%04x\n",iloop, startloopaddr[iloop], stoploopaddr[iloop]);
+    if ( startloopaddr[iloop]<0 || stoploopaddr[iloop]<= startloopaddr[iloop]) nloop[iloop]=0;
+    fprintf(fd,"patnloop%d %d\n",iloop, nloop[iloop]);
+  }
+
+  for (iloop=0; iloop<MAXTIMERS; iloop++) {
+    fprintf(fd,"patwait%d 0x%04x\n",iloop, waitaddr[iloop]);
+    if (waitaddr[iloop]<0) waittime[iloop]=0;
+    fprintf(fd,"patwaittime%d %lld\n",iloop, waittime[iloop]);
+  }
+  
+  close((int)fd);
+  fd1=fopen(OUTFILEBIN,"w");
+  fwrite(PAT,sizeof(uint64_t),iaddr, fd1);
+  close((int)fd1);
+}
--- a/ctbGui/patternGenerator/test.p
+++ b/ctbGui/patternGenerator/test.p
@ -0,0 +1,201 @@
+//define signals and directions (Input, outputs, clocks)
+
+
+#define compTestIN 1
+setoutput(compTestIN);
+
+#define curON 32
+setoutput(curON);
+
+#define side_clk 2
+setclk(side_clk);
+
+#define side_din 3
+setoutput(side_din);
+
+#define clear_shr 4
+setoutput(clear_shr);
+
+#define bottom_din 5
+setoutput(bottom_din);
+
+#define bottom_clk 6
+setclk(bottom_clk);
+
+#define gHG 7
+setoutput(gHG);
+
+#define bypassCDS 31
+setoutput(bypassCDS);
+
+
+#define ENprechPRE 8
+setoutput(ENprechPRE);
+
+
+#define res 9
+setoutput(res);
+
+#define pulseOFF 30
+setoutput(pulseOFF);
+
+#define connCDS 27
+setoutput(connCDS);
+
+#define Dsg_1 24
+setoutput(Dsg_1);
+
+
+#define Dsg_2 25
+setoutput(Dsg_2);
+
+
+#define Dsg_3 23
+setoutput(Dsg_3);
+
+#define sto0 10
+setoutput(sto0);
+
+#define sto1 11
+setoutput(sto1);
+
+#define sto2 12
+setoutput(sto2);
+
+#define resCDS 13
+setoutput(resCDS);
+
+#define prechargeConnect 14
+setoutput(prechargeConnect);
+
+#define pulse 15
+setoutput(pulse);
+
+#define PCT_mode 21
+setoutput(PCT_mode);
+
+#define res_DGS 16
+setoutput(res_DGS);
+
+#define adc_ena 17
+setoutput(adc_ena);
+
+
+#define CLKBIT 18
+setclk(CLKBIT);
+
+
+#define adc_sync 63
+setoutput(adc_sync);
+
+
+
+
+
+	  
+#define PW pw()
+#define SB(x) setbit(x) 
+#define CB(x) clearbit(x)
+#define CLOCK  clearbit(CLKBIT); pw();setbit(CLKBIT);pw()
+#define LCLOCK  clearbit(CLKBIT); pw();setbit(CLKBIT);pw();clearbit(CLKBIT); pw()
+#define CLOCKS(x) for (i=0;i<x;i++) {clearbit(CLKBIT);pw(); setbit(CLKBIT); pw();}
+#define STOP setstop();
+#define START setstart();
+#define REPEAT(x) for (i=0;i<(x);i++) {pw();}
+#define DOFOR(x) for (j=0;j<(x);j++) {
+// }				     
+#define STARTUP1 CB(compTestIN);SB(clear_shr);CB(side_clk);CB(side_din);CB(bottom_din);CB(bottom_clk);
+#define STARTUP2 CB(pulse);SB(PCT_mode);SB(pulseOFF);CB(curON);
+#define STARTUP3 SB(res);SB(gHG);SB(ENprechPRE);
+#define STARTUP4 SB(bypassCDS); CB(connCDS);CB(sto0);SB(sto1);SB(sto2);
+#define STARTUP5 SB(resCDS);CB(Dsg_1);CB(Dsg_2);SB(Dsg_3);CB(prechargeConnect);SB(res_DGS);
+#define STARTUP STARTUP1 STARTUP2 STARTUP3 STARTUP4 STARTUP5 PW;
+
+
+
+
+
+//****NOTES****//
+//FUNCTIONS
+//Declare functions at the beginning 
+void load_pix(int nx, int ny)
+{//SELECT PIXEL 1,1 for readout
+SB(clear_shr);PW;PW;
+CB(clear_shr);PW;PW;PW;PW;
+
+SB(side_din);PW;
+SB(side_clk);PW;
+CB(side_din);
+setstartloop(0); //loop on the rows
+SB(side_clk);PW;
+setstoploop(0);  //finish loop on the rows
+setnloop(0,ny); //set number row selected -can be changed dynamically
+CB(side_clk);PW;
+SB(bottom_din);PW;
+SB(bottom_clk);PW;
+CB(bottom_din);
+setstartloop(1); //loop on the columns
+SB(bottom_clk);PW;
+setstoploop(1); //loop on the columns
+setnloop(1,ny); //set number columns selected -can be changed dynamically
+}
+   
+void load_col(void)
+{//SELECT COLUMN 1 for readout
+SB(clear_shr);PW;PW;
+CB(clear_shr);PW;PW;PW;PW;
+SB(bottom_din);PW;
+SB(bottom_clk);PW;
+CB(bottom_clk);PW;
+CB(bottom_din);PW;
+}
+//END of FUNCTIONS
+////////////////////////////////////////////////////////
+//LET BYPASS PREAMP AND CDS and write on preamp out.//
+//THIS ALLOWS CHECKING SOURCE FOLLOWERS               //
+////////////////////////////////////////////////////////
+
+   
+PW;
+   
+SB(5); PW;
+
+CB(5); PW;
+
+START; //pattern starts from here
+STARTUP;
+setwaitpoint(0); //set wait points
+PW;
+setwaittime(0,20); //wait time - can be changed dynamically
+SB(adc_ena);PW;
+   printf("ADC sync %x %d %llx\n",iaddr,adc_sync, pat);
+SB(adc_sync);PW;
+   printf("ADC sync %x %d  %llx\n",iaddr, adc_sync, pat);
+CB(gHG);
+setwaitpoint(1); //set wait points
+setwaittime(1,16); //wait time - can be changed dynamically
+CB(adc_sync);PW;
+load_pix(10, 20);
+
+CB(res);
+//CB(Dsg_3);PW;
+CB(res_DGS);
+setwaitpoint(2); //set wait points
+setwaittime(2,1000); //wait time - can be changed dynamically
+
+//SB(res_DGS);
+//PW;
+//SB(Dsg_3);
+//
+//CB(connCDS);
+//TEST SIGNALS END
+//
+REPEAT(20)
+
+//****************//
+//*FINAL COMMANDS*//
+//****************//
+CB(adc_ena);PW;
+//STARTUP;
+STOP; PW; //stops here
+//REPEAT(4);
--- a/docs/CMakeLists.txt
+++ b/docs/CMakeLists.txt
@ -55,9 +55,6 @@ set(SPHINX_SOURCE_FILES
  src/troubleshooting.rst
  src/receivers.rst
  src/slsreceiver.rst
-  src/udpheader.rst
-  src/udpconfig.rst
-  src/udpdetspec.rst
 )

 foreach(filename ${SPHINX_SOURCE_FILES})
--- a/docs/src/dependencies.rst
+++ b/docs/src/dependencies.rst
@ -21,8 +21,10 @@ the shared libraries these are needed:
 GUI
 -----------------------

- * Qt 5.9
- * Qwt 6.1.5 (packaged in libs/)
+The GUI is currently using Qt4 but watch out for an upgrade to 5. 
+
+ * Qt 4.8
+ * Qwt 6.1

 -----------------------
 Python bindings
--- a/docs/src/firmware.rst
+++ b/docs/src/firmware.rst
@ -92,40 +92,25 @@ Download
 Upgrade
 ^^^^^^^^

-.. warning ::
-
-    In case you have had issues in the past with programming via software:
-
-    * 6.1.2 server has a fix for seamless fpga programming
-
-    * We recommend first updating the on-board detector server to 6.1.2 (with client 6.1.x) using command 'updatedetectorserver' or 'copydetectorserver'.
-
-    * Then use command 'programfpga' to only update firmware or use command 'update' to update firmware and server to the latest release.
+.. note :: 

+    These instructions are for upgrades from v5.0.0. For earlier versions, contact us.


 Check :ref:`firmware troubleshooting <blackfin firmware troubleshooting>` if you run into issues while programming firmware.

-
+Always ensure that the client and server software are of the same release.


 Program from console
    .. code-block:: bash

-        # These instructions are for upgrades from v5.0.0. For earlier versions, please contact us.
-
-        # Always ensure that the client and server software are of the same release.
-
-        # copies server, links new server to jungfrauDetectorServer, 
+        # copies server from tftp folder of pc, links new server to jungfrauDetectorServer, 
        # removes old server from respawn, sets up new lnked server to respawn
-        # programs fpga, reboots
-
-        # v5.0.0 - 6.0.0 (copies server from tftp folder of the pc)
+        # programs fpga,
+        # reboots
        sls_detector_put update jungfrauDetectorServervxxx pcxxx xx.pof

-        # v6.1.1 - present (copies server from the full path provided)
-        sls_detector_put update jungfrauDetectorServervxxx xx.pof
-
        # Or only program firmware
        sls_detector_put programfpga xxx.pof

@ -170,6 +155,10 @@ Upgrade
 Mythen III
 -----------

+.. note :: 
+
+  As it is still in development, the rbf files must be picked up from us.
+
 Download 
 ^^^^^^^^^^^^^

@ -181,21 +170,16 @@ Download
 Upgrade
 ^^^^^^^^

+Always ensure that the client and server software are of the same release.
+
 Program from console
    .. code-block:: bash

-        # Always ensure that the client and server software are of the same release.
-
-        # copies server, links new server to mythen3DetectorServer, 
-        # removes old server from respawn, sets up new lnked server to respawn
-        # programs fpga, reboots
-
-        # v5.0.0 - 6.0.0 (copies server from tftp folder of the pc)
+        # copies server from tftp folder of pc, links new server to mythen3DetectorServer, 
+        # programs fpga,
+        # reboots
        sls_detector_put update mythen3DetectorServervxxx pcxxx xxx.rbf

-        # v6.1.1 - present (copies server from the full path provided)
-        sls_detector_put update mythen3DetectorServervxxx xxx.rbf
-
        # Or only program firmware
        sls_detector_put programfpga xxx.rbf

@ -215,21 +199,16 @@ Download
 Upgrade
 ^^^^^^^^

+Always ensure that the client and server software are of the same release.
+
 Program from console
    .. code-block:: bash

-        # Always ensure that the client and server software are of the same release.
-        
-        # copies server, links new server to gotthard2DetectorServer, 
-        # removes old server from respawn, sets up new lnked server to respawn
-        # programs fpga, reboots
-
-        # v5.0.0 - 6.0.0 (copies server from tftp folder of the pc)
+        # copies server from tftp folder of pc, links new server to gotthard2DetectorServer, 
+        # programs fpga,
+        # reboots
        sls_detector_put update gotthard2DetectorServervxxx pcxxx xxx.rbf

-        # v6.1.1 - present (copies server from the full path provided)
-        sls_detector_put update gotthard2DetectorServervxxx xxx.rbf
-
        # Or only program firmware
        sls_detector_put programfpga xxx.rbf

@ -251,36 +230,19 @@ Download
 Upgrade
 ^^^^^^^^

-.. warning ::
-
-    In case you have had issues in the past with programming via software:
-
-    * 6.1.2 server has a fix for seamless fpga programming
-
-    * We recommend first updating the on-board detector server to 6.1.2 (with client 6.1.x) using command 'updatedetectorserver' or 'copydetectorserver'.
-
-    * Then use command 'programfpga' to only update firmware or use command 'update' to update firmware and server to the latest release.
-
-
-
 Check :ref:`firmware troubleshooting <blackfin firmware troubleshooting>` if you run into issues while programming firmware.

+Always ensure that the client and server software are of the same release.

 Program from console
    .. code-block:: bash

-        # Always ensure that the client and server software are of the same release.
-
-        # copies server, links new server to moenchDetectorServer, 
+        # copies server from tftp folder of pc, links new server to moenchDetectorServer, 
        # removes old server from respawn, sets up new lnked server to respawn
-        # programs fpga, reboots
-
-        # v5.0.0 - 6.0.0 (copies server from tftp folder of the pc)
+        # programs fpga,
+        # reboots
        sls_detector_put update moenchDetectorServervxxx pcxxx xx.pof

-        # v6.1.1 - present (copies server from the full path provided)
-        sls_detector_put update moenchDetectorServervxxx xx.pof
-
        # Or only program firmware
        sls_detector_put programfpga xxx.pof

@ -300,22 +262,17 @@ Upgrade

 Check :ref:`firmware troubleshooting <blackfin firmware troubleshooting>` if you run into issues while programming firmware.

+Always ensure that the client and server software are of the same release.

 Program from console
    .. code-block:: bash

-        # Always ensure that the client and server software are of the same release.
-        
-        # copies server, links new server to ctbDetectorServer, 
+        # copies server from tftp folder of pc, links new server to ctbDetectorServer, 
        # removes old server from respawn, sets up new lnked server to respawn
-        # programs fpga, reboots
-
-        # v5.0.0 - 6.0.0 (copies server from tftp folder of the pc)
+        # programs fpga,
+        # reboots
        sls_detector_put update ctbDetectorServervxxx pcxxx xx.pof

-        # v6.1.1 - present (copies server from the full path provided)
-        sls_detector_put update ctbDetectorServervxxx xx.pof
-
        # Or only program firmware
        sls_detector_put programfpga xxx.pof

--- a/docs/src/index.rst
+++ b/docs/src/index.rst
@ -66,15 +66,6 @@ Welcome to slsDetectorPackage's documentation!
    virtualserver
    serverdefaults

-
-.. toctree::
-    :caption: Detector UDP Header
-    :maxdepth: 2
-
-    udpheader
-    udpconfig
-    udpdetspec
-
 .. toctree::
    :caption: Receiver
    :maxdepth: 2
--- a/docs/src/installation.rst
+++ b/docs/src/installation.rst
@ -1,28 +1,100 @@
+
+
+
+.. note :: 
+
+    The default branch of our git repository is developer. It contains the 
+    latest development version. It is expected to compile and work but 
+    features might be added or tweaked. In some cases the API might also change
+    without being communicated. If absolute stability of the API is needed please
+    use one of the release versions. 
+
 .. warning ::
    
    Before building from source make sure that you have the 
    :doc:`dependencies <../dependencies>` installed. If installing using conda, conda will 
-    manage the dependencies. Avoid also installing packages with pip. 
-   
+    manage the dependencies.
+    

 .. _Installation:

-
 Installation
-===============
+==============================================
+
+.. _build from source using cmake:
+
+Build from source using CMake
+---------------------------------
+
+Note that on some systems, for example RH7,  cmake v3+ is available under the cmake3 alias.
+It is also required to clone with the option --recursive to get the git submodules used
+in the package. 
+
+
+.. code-block:: bash
+
+    git clone --recursive https://github.com/slsdetectorgroup/slsDetectorPackage.git
+    mkdir build && cd build
+    cmake ../slsDetectorPackage -DCMAKE_INSTALL_PREFIX=/your/install/path
+    make -j12 #or whatever number of cores you are using to build
+    make install
+
+The easiest way to configure options is to use the ccmake utility. 
+
+.. code-block:: bash
+
+    #from the build directory
+    ccmake .
+
+
+Build using cmk.sh script
+-------------------------
+These are mainly aimed at those not familiar with using ccmake and cmake.
+
+.. code-block:: bash
+
+    The binaries are generated in slsDetectorPackage/build/bin directory.
+
+    Usage: $0 [-c] [-b] [-p] [e] [t] [r] [g] [s] [u] [i] [m] [n] [-h] [z] [-d <HDF5 directory>] [-l Install directory] [-k <CMake command>] [-j <Number of threads>]
+    -[no option]: only make
+    -c: Clean
+    -b: Builds/Rebuilds CMake files normal mode
+    -p: Builds/Rebuilds Python API
+    -h: Builds/Rebuilds Cmake files with HDF5 package
+    -d: HDF5 Custom Directory
+    -k: CMake command
+    -l: Install directory
+    -t: Build/Rebuilds only text client
+    -r: Build/Rebuilds only receiver
+    -g: Build/Rebuilds only gui
+    -s: Simulator
+    -u: Chip Test Gui
+    -j: Number of threads to compile through
+    -e: Debug mode
+    -i: Builds tests
+    -m: Manuals
+    -n: Manuals without compiling doxygen (only rst)
+    -z: Moench zmq processor
+    
+    # get all options
+    ./cmk.sh -?
+
+    # new build  and compile in parallel:
+    ./cmk.sh -bj5
+

 Install binaries using conda
-------------------------------
+--------------------------------

 Conda is not only useful to manage python environments but can also
-be used as a user space package manager. Dates in the tag (for eg. 2020.07.23.dev0) 
-are from the developer branch. Please use released tags for stability.
+be used as a user space package manager. 

 We have three different packages available:

-    * **slsdetlib** shared libraries and command line utilities 
-    * **slsdetgui** GUI
-    * **slsdet** Python bindings
+ * **slsdetlib**, shared libraries and command line utilities 
+ * **slsdetgui**, GUI
+ * **slsdet**, Python bindings
+

 .. code-block:: bash

@ -31,9 +103,9 @@ We have three different packages available:
    conda config --add channels slsdetectorgroup
    conda config --set channel_priority strict

-    #create and activate an environment with our library
-    #replace 6.1.1 with the required tag
-    conda create -n myenv slsdetlib=6.1.1
+    #cerate an environment with our library, then activate
+    #replace 2020.07.20.dev0 with the required tag
+    conda create -n myenv slsdetlib=2020.07.23.dev0
    conda activate myenv

    #ready to use
@ -44,145 +116,11 @@ We have three different packages available:
 .. code-block:: bash

    #List available versions
-    # lib and binaries
-    conda search slsdetlib
-    # python
    conda search slsdet
-    # gui
-    conda search slsdetgui


-
-
-Build from source
-------------------
-
-
-1. Download Source Code from github
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-.. code-block:: bash
-
-    git clone https://github.com/slsdetectorgroup/slsDetectorPackage.git --branch 6.1.1
-
-
-| **Pybind for Python**
-| v7.0.0+:
-|   pybind11 packaged into 'libs/pybind'. No longer a submodule. No need for "recursive" or "submodule update".
-| 
-| Older versions:
-|   pybind11 is a submodule. Must be cloned using "recursive" and updated when switching between versions using the following commands.
-
-.. code-block:: bash
-    
-    # clone using recursive to get pybind11 submodule
-    git clone --recursive https://github.com/slsdetectorgroup/slsDetectorPackage.git
-
-    # update submodule when switching between releases
-    cd slsDetectorPackage
-    git submodule update --init
-   
-
-.. _build from source using cmake:
-
-
-
-2. Build from Source
-^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-Build using CMake
-^^^^^^^^^^^^^^^^^^^^^^
-
-.. code-block:: bash
-
-    # outside slsDetecorPackage folder
-    mkdir build && cd build
-
-    # configure & generate Makefiles using cmake
-    # by listing all your options (alternately use ccmake described below)
-    # cmake3 for some systems
-    cmake ../slsDetectorPackage -DCMAKE_INSTALL_PREFIX=/your/install/path
-
-    # compiled to the build/bin directory
-    make -j12 #or whatever number of cores you are using to build
-
-    # install headers and libs in /your/install/path directory
-    make install
-
-
-Instead of the cmake command, one can use ccmake to get a list of options to configure and generate Makefiles at ease.
-
-.. code-block:: bash
-
-    # ccmake3 for some systems
-    ccmake ..
- 
-    # choose the options
-    # first press [c] - configure
-    # then press [g] - generate
-
-
-
-===============================     ===========================================
-Example cmake options               Comment
-===============================     ===========================================
-DSLS_USE_PYTHON=ON                 Python
-DPython_FIND_VIRTUALENV=ONLY       Python from only the conda environment 
-DZeroMQ_HINT=/usr/lib64            Use system zmq instead
-DSLS_USE_GUI=ON                    GUI
-===============================     ===========================================
-
-
-
-Build using in-built cmk.sh script
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-
-.. code-block:: bash
-
-    The binaries are generated in slsDetectorPackage/build/bin directory.
-
-    Usage: ./cmk.sh [-b] [-c] [-d <HDF5 directory>] [e] [g] [-h] [i] [-j <Number of threads>] 
-    [-k <CMake command>] [-l <Install directory>] [m] [n] [-p] [-q <Zmq hint directory>] 
-    [r] [s] [t] [u] [z]  
-    -[no option]: only make
-    -b: Builds/Rebuilds CMake files normal mode
-    -c: Clean
-    -d: HDF5 Custom Directory
-    -e: Debug mode
-    -g: Build/Rebuilds gui
-    -h: Builds/Rebuilds Cmake files with HDF5 package
-    -i: Builds tests
-    -j: Number of threads to compile through
-    -k: CMake command
-    -l: Install directory
-    -m: Manuals
-    -n: Manuals without compiling doxygen (only rst)
-    -p: Builds/Rebuilds Python API
-    -q: Zmq hint directory
-    -r: Build/Rebuilds only receiver
-    -s: Simulator
-    -t: Build/Rebuilds only text client
-    -u: Chip Test Gui
-    -z: Moench zmq processor
-
-    
-    # display all options
-    ./cmk.sh -?
-
-    # new build and compile in parallel (recommended basic option):
-    ./cmk.sh -cbj5
-
-    # new build, python and compile in parallel:
-    ./cmk.sh -cbpj5
-
-    #To use the system zmq (/usr/lib64) instead
-    ./cmk.sh -cbj5 -q /usr/lib64
-
-
-
-Build on old distributions
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Build from source on old distributions
+-----------------------------------------

 If your linux distribution doesn't come with a C++11 compiler (gcc>4.8) then 
 it's possible to install a newer gcc using conda and build the slsDetectorPackage
@ -193,64 +131,12 @@ using this compiler
    #Create an environment with the dependencies
    conda create -n myenv gxx_linux-64 cmake zmq
    conda activate myenv
-
-    # outside slsDetecorPackage folder
-    mkdir build && cd build
    cmake ../slsDetectorPackage -DCMAKE_PREFIX_PATH=$CONDA_PREFIX
    make -j12


-
-Build slsDetectorGui (Qt5)
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-1. Using pre-built binary on conda
-    .. code-block:: bash
-
-        conda create -n myenv slsdetgui=7.0.0
-        conda activate myenv
-
-
-2. Using system installation on RHEL7
-    .. code-block:: bash
-
-        yum install qt5-qtbase-devel.x86_64
-        yum install qt5-qtsvg-devel.x86_64 
-
-
-3. Using conda
-    .. code-block:: bash
-
-        #Add channels for dependencies and our library
-        conda config --add channels conda-forge
-        conda config --add channels slsdetectorgroup
-        conda config --set channel_priority strict
-
-        # create environment to compile
-        # on rhel7
-        conda create -n slsgui zeromq gxx_linux-64 gxx_linux-64 mesa-libgl-devel-cos6-x86_64 qt
-        # on fedora or newer systems
-        conda create -n slsgui zeromq qt
-
-        # when using conda compilers, would also need libgl, but no need for it on fedora unless maybe using it with ROOT
-
-        # activate environment
-        conda activate slsgui
-
-        # compile with cmake outside slsDetecorPackage folder
-        mkdir build && cd build
-        cmake ../slsDetectorPackage -DSLS_USE_GUI=ON
-        make -j12
-
-        # or compile with cmk.sh
-        cd slsDetectorPackage
-        ./cmk.sh -cbgj9
-
-
-
-
 Build this documentation
-^^^^^^^^^^^^^^^^^^^^^^^^
+-------------------------------

 The documentation for the slsDetectorPackage is build using a combination 
 of Doxygen, Sphinx and Breathe. The easiest way to install the dependencies
@ -258,15 +144,11 @@ is to use conda

 .. code-block:: bash

-    conda create -n myenv python sphinx_rtd_theme breathe
+    conda create -n myenv python sphinx sphinx_rtd_theme

+Then enable the option SLS_BUILD_DOCS to create the targets

 .. code-block:: bash

-    # using cmake or ccmake to enable DSLS_BUILD_DOCS
-    # outside slsDetecorPackage folder
-    mkdir build && cd build
-    cmake ../slsDetectorPackage -DSLS_BUILD_DOCS=ON
-
    make docs # generate API docs and build Sphinx RST
-    make rst # rst only, saves time in case the API did not change
+    make rst # rst only, saves time in case the API did not change
--- a/docs/src/pyexamples.rst
+++ b/docs/src/pyexamples.rst
@ -10,46 +10,27 @@ open an issue in our our  `github repo
 Setting exposure time 
 ------------------------------------

-Setting and reading back exposure time can be done either using a Python 
-datetime.timedelta, DurationWrapper or by setting the time in seconds. 
+Setting and reading back exposure time can be done either using a Python datetime.timedelta
+or by setting the time in seconds. 

 ::

    # Set exposure time to 1.2 seconds
    >>> d.exptime = 1.2
-    >>> d.exptime = 5e-07

-    # Setting exposure time using timedelta (upto microseconds precision)
+    # Setting exposure time using timedelta
    import datetime as dt
    >>> d.exptime = dt.timedelta(seconds = 1.2)
-    >>> d.exptime = dt.timedelta(seconds = 1, microseconds = 3)

    # With timedelta any arbitrary combination of units can be used
    >>> t = dt.timedelta(microseconds = 100, seconds = 5.3, minutes = .3)

-    # using DurationWrapper to set in seconds
-    >>> from slsdet import DurationWrapper
-    >>> d.exptime = DurationWrapper(1.2)
-    
-    # using DurationWrapper to set in ns
-    >>> t = DurationWrapper()
-    >>> t.set_count(500)
-    >>> d.exptime = t
-
    # To set exposure time for individual detector one have to resort
    # to the C++ style API.
    # Sets exposure time to 1.2 seconds for module 0, 6 and 12
    >>> d.setExptime(1.2, [0, 6, 12]) 
    >>> d.setExptime(dt.timedelta(seconds = 1.2), [0, 6, 12]) 

-    # to get in seconds
-    >>> d.period
-    181.23
-
-    # to get in DurationWrapper
-    >>> d.getExptime()
-    [sls::DurationWrapper(total_seconds: 181.23 count: 181230000000)]
-


 ------------------------------------
@ -239,7 +220,8 @@ Setting and getting times
    # This sets the exposure time for all modules
    d.exptime = 0.5

-    # exptime also accepts a python datetime.timedelta (upto microseconds resolution)
+    # exptime also accepts a python datetime.timedelta
+    # which can be used to set the time in almost any unit
    t = dt.timedelta(milliseconds = 2.3)
    d.exptime = t

@ -247,25 +229,16 @@ Setting and getting times
    t = dt.timedelta(minutes = 3, seconds = 1.23)
    d.exptime = t

-    # using DurationWrapper to set in seconds
-    >>> from slsdet import DurationWrapper
-    >>> d.exptime = DurationWrapper(1.2)
-    
-    # using DurationWrapper to set in ns
-    >>> t = DurationWrapper()
-    >>> t.set_count(500)
-    >>> d.exptime = t
-
    # exptime however always returns the time in seconds
    >>> d.exptime
    181.23 

    # To get back the exposure time for each module 
    # it's possible to use getExptime, this also returns
-    # the values as  DurationWrapper
+    # the values as datetime.timedelta

    >>> d.getExptime()
-    [sls::DurationWrapper(total_seconds: 181.23 count: 181230000000)]
+    [datetime.timedelta(seconds=181, microseconds=230000), datetime.timedelta(seconds=181, microseconds=230000)]

    # In case the values are the same it's possible to use the
    # element_if_equal function to reduce the values to a single 
@ -273,8 +246,7 @@ Setting and getting times

    >>> t = d.getExptime()
    >>> element_if_equal(t)
-    sls::DurationWrapper(total_seconds: 1.2 count: 1200000000)
-
+    datetime.timedelta(seconds=1)

 --------------
 Reading dacs
--- a/docs/src/pygettingstarted.rst
+++ b/docs/src/pygettingstarted.rst
@ -6,7 +6,7 @@ Getting Started
 Which Python?  
 --------------------

-We require at least Python 3.6 and strongly recommended that you don't use the system
+We require at lest Python 3.6 and strongly recommended that you don't use the system
 Python installation. The examples in this documentation uses `conda
 <https://docs.conda.io/en/latest/miniconda.html>`_ since it provides good support
 also for non Python packages but there are also other alternatives like, pyenv. 
@ -14,35 +14,28 @@ also for non Python packages but there are also other alternatives like, pyenv.
 Using something like conda also allows you to quickly switch beteen different Python 
 environments. 

---------------------
-Building from Source 
---------------------
-
-If you are not installing slsdet binaries from conda, but instead building from 
-source, please refer to  :ref:`the installation section<Installation>` for details.
-
-Don't forget to compile with the option SLS_USE_PYTHON=ON to enable the Python 
-bindings or if you use the cmk.sh script -p.
-
-.. note ::
-
-    Ensure that the sls det python lib compiled is for the expected python version.
-    For example, build/bin/_slsdet.cpython-39-x86_64-linux-gnu.so for Python v3.9.x
+.. warning ::

+    If you use conda avoid also installing packages with pip. 

 ---------------------
 PYTHONPATH 
 ---------------------

-If you install slsdet binaries using conda everything is set up and you can
+If you install slsdet using conda everything is set up and you can
 directly start using the Python bindings. However, if you build 
-from source you need to tell Python where to find slsdet to use it. This
-can be done by adding your build/bin directory to PYTHONPATH. 
+from source you need to tell Python where to find slsdet. This
+is be done by adding your build/bin directory to PYTHONPATH. 

 .. code-block:: bash

    export PYTHONPATH = /path/to/your/build/bin:$PYTHONPATH

+.. note ::
+
+    Don't forget to compile with the option SLS_USE_PYTHON=ON to enable
+    the Python bindings or if you use the cmk.sh script -p.
+
 --------------------------------------
 Which detector class should I use? 
 --------------------------------------
@ -153,11 +146,9 @@ their name.
 :: 

    >>> [item for item in dir(d) if 'time' in item]
-    ['compdisabletime', 'exptime', 'exptimel', 'frametime', 'getExptime', 
-    'getExptimeForAllGates', 'getExptimeLeft', 'getSubExptime', 'patwaittime', 
-    'patwaittime0', 'patwaittime1', 'patwaittime2', 'runtime', 'setExptime', 
-    'setSubExptime', 'subdeadtime', 'subexptime']
-
+    ['exptime', 'getExptime', 'getExptimeForAllGates', 'getExptimeLeft', 
+    'getSubExptime', 'patwaittime0', 'patwaittime1', 'patwaittime2', 
+    'setExptime', 'setSubExptime', 'subdeadtime', 'subexptime']

 The above method works on any Python object but for convenience we also 
 included two functions to find names. View prints the names one per line
@ -169,7 +160,6 @@ while find returns a list of names.

    >>> view('exptime')
    exptime
-    exptimel
    getExptime
    getExptimeForAllGates
    getExptimeLeft
@ -178,7 +168,6 @@ while find returns a list of names.
    setSubExptime
    subexptime

-
    >>> find('exptime')
    ['exptime', 'getExptime', 'getExptimeForAllGates', 'getExptimeLeft', 
    'getSubExptime', 'setExptime', 'setSubExptime', 'subexptime']
@ -196,39 +185,19 @@ To access the documentation of a function directly from the Python prompt use he
    Help on property:

        Period between frames, accepts either a value in seconds or datetime.timedelta
-        
+
        Note
        -----
-        :getter: always returns in seconds. To get in DurationWrapper, use getPeriod
-        
-        Example
+        :getter: always returns in seconds. To get in datetime.delta, use getPeriod
+
+        Examples
        -----------
-        >>> # setting directly in seconds
        >>> d.period = 1.05
-        >>>
-        >>> # setting directly in seconds
-        >>> d.period = 5e-07
-        >>> 
-        >>> # using timedelta (up to microseconds precision)
-        >>> from datatime import timedelta
-        >>> d.period = timedelta(seconds = 1, microseconds = 3)
-        >>> 
-        >>> # using DurationWrapper to set in seconds
-        >>> from slsdet import DurationWrapper
-        >>> d.period = DurationWrapper(1.2)
-        >>> 
-        >>> # using DurationWrapper to set in ns
-        >>> t = DurationWrapper()
-        >>> t.set_count(500)
-        >>> d.period = t
-        >>>
-        >>> # to get in seconds
+        >>> d.period = datetime.timedelta(minutes = 3, seconds = 1.23)
        >>> d.period
        181.23
-        >>> 
-        >>> d.getExptime()
-        [sls::DurationWrapper(total_seconds: 181.23 count: 181230000000)]
-
+        >>> d.getPeriod()
+        [datetime.timedelta(seconds=181, microseconds=230000)]


 ----------------------
@ -248,12 +217,11 @@ The enums can be found in slsdet.enums

    import slsdet
    >>> [e for e in dir(slsdet.enums) if not e.startswith('_')]
-    ['M3_GainCaps', 'burstMode', 'clockIndex', 'cls', 'dacIndex', 'detectorSettings', 
-    'detectorType', 'dimension', 'externalSignalFlag', 'fileFormat', 
-    'frameDiscardPolicy', 'gainMode', 'name', 'polarity', 'portPosition', 
-    'readoutMode', 'runStatus', 'speedLevel', 'streamingInterface', 'timingMode', 
-    'timingSourceType', 'vetoAlgorithm']
-
+    ['burstMode', 'clockIndex', 'dacIndex', 
+    'detectorSettings', 'detectorType', 'dimension', 'externalSignalFlag', 
+    'fileFormat', 'frameDiscardPolicy', 
+    'readoutMode', 'runStatus', 'speedLevel', 'timingMode', 
+    'timingSourceType']

    # Even though importing using * is not recommended one could
    # get all the enums like this: 
--- a/docs/src/quick_start_guide.rst
+++ b/docs/src/quick_start_guide.rst
@ -66,15 +66,11 @@ For a Single Module
        # sets destination udp ports (not needed, default is 50001)
        udp_dstport 50012

-        # 1g data out
        # source udp ips must be same subnet at destintaion udp ips
-        # udp_srcip 192.168.1.112
-        # destination udp ip picked up from rx_hostname (if auto)
-        # udp_dstip auto
+        udp_srcip 192.168.1.112

-        # 10g data out
-        udp_srcip 10.30.20.200
-        udp_dstip 10.30.20.6
+        # destination udp ip picked up from rx_hostname (if auto)
+        udp_dstip auto

        # set file path
        fpath /tmp
--- a/docs/src/receivers.rst
+++ b/docs/src/receivers.rst
@ -4,8 +4,41 @@ Receivers
 Receiver processes can be run on same or different machines as the client, receives the data from the detector (via UDP packets).
 When using the slsReceiver/ slsMultiReceiver, they can be further configured by the client control software (via TCP/IP) to set file name, file path, progress of acquisition etc.

+Detector UDP Header
+---------------------

-To know more about detector receiver configuration, please check out :ref:`detector udp header and udp commands in the config file <detector udp header>`
+| The UDP data format for the packets consist of a common header for all detectors, followed by the data for that one packet.
+
+**The SLS Detector Header**
+
+.. table:: <-------------------------------- 8 bytes -------------------------------->
+    :align: center
+    :widths: 30,30,30,30
+
+    +--------------------------------------------------------------------+
+    |frameNumber                                                         |
+    +---------------------------------+----------------------------------+
+    |expLength                        |packetNumber                      |
+    +---------------------------------+----------------------------------+
+    |bunchId                                                             |
+    +--------------------------------------------------------------------+
+    |timestamp                                                           |
+    +----------------+----------------+----------------+-----------------+
+    |modId           |row             |column          |reserved         |
+    +----------------+----------------+----------------+--------+--------+
+    |debug                            |roundRNumber    |detType |version |
+    +---------------------------------+----------------+--------+--------+
+
+UDP configuration in Config file
+----------------------------------
+
+#. UDP source port is hardcoded in detector server, starting at 32410.
+#. **udp_dstport** : UDP destination port number. Port in receiver pc to listen to packets from the detector.
+#. **udp_dstip** : IP address of UDP destination interface. IP address of interface in receiver pc to listen to packets from detector. If **auto** is used (only when using slsReceiver/ slsMultiReceiver), the IP of **rx_hostname** is picked up.
+#. **udp_dstmac** : Mac address of UDP destination interface. MAC address of interface in receiver pc to list to packets from detector. Only required when using custom receiver, else slsReceiver/slsMultiReceiver picks it up from **udp_dstip**.
+#. **udp_srcip** : IP address of UDP source interface. IP address of detector UDP interface to send packets from. Do not use for Eiger 1Gb interface (uses its hardware IP). For others, must be in the same subnet as **udp_dstip**.
+#. **udp_srcmac** : MAC address of UDP source interface. MAC address of detector UDP interface to send packets from. Do not use for Eiger (uses hardware mac). For others, it is not necessary, but can help for switch and debugging to put unique values for each module.
+ 

 Custom Receiver
 ----------------
--- a/docs/src/servers.rst
+++ b/docs/src/servers.rst
@ -1,14 +1,5 @@
-Getting Started
-===============
-
-Detector Servers include:
-   * Control server [default port: 1952]
-      * Almost all client communication.
-   * Stop server [default port: 1953]
-      *  Client requests for detector status, stop acquisition, temperature, advanced read/write registers.
-
-When using a blocking acquire command (sls_detector_acquire or Detector::acquire), the control server is blocked until end of acquisition. However, stop server commands could be used in parallel.
-
+Detector Servers
+=================

 Location
 ---------
@ -23,19 +14,26 @@ Arguments
   .. code-block:: bash  

      Possible arguments are:
-         -v, --version            : Software version
-         -p, --port <port>        : TCP communication port with client. 
-         -g, --nomodule           : [Mythen3][Gotthard2] 
-                                    Generic or No Module mode. Skips detector type checks. 
-         -f, --phaseshift <value> : [Gotthard] only. Sets phase shift. 
-         -d, --devel              : Developer mode. Skips firmware checks. 
-         -u, --update             : Update mode. Skips firmware checks and initial detector setup. 
-         -i, --ignore-config      : [Eiger][Jungfrau][Gotthard][Gotthard2][Moench] 
-                                    Ignore config file. 
-         -m, --master <master>    : [Eiger][Mythen3][Gotthard][Gotthard2] 
-                                    Set Master to 0 or 1. Precedence over config file. Only for virtual servers except Eiger. 
-         -t, --top <top>          : [Eiger] Set Top to 0 or 1. Precedence over config file. 
-         -s, --stopserver         : Stop server. Do not use as it is created by control server 
+      -v, --version            : Software version
+      -p, --port <port>        : TCP communication port with client. 
+      -g, --nomodule           : [Mythen3][Gotthard2] Generic or No Module mode. 
+                                 Skips detector type checks.
+      -f, --phaseshift <value> : [Gotthard] only. Sets phase shift. 
+      -d, --devel              : Developer mode. Skips firmware checks. 
+      -u, --update             : Update mode. Skips firmware checks and initial detector setup. 
+      -s, --stopserver         : Stop server. Do not use as it is created by control server 
+
+
+Basics
+------------
+
+Detector Servers include:
+   * Control server [default port: 1952]
+      * Almost all client communication.
+   * Stop server [default port: 1953]
+      *  Client requests for detector status, stop acquisition, temperature, advanced read/write registers.
+
+When using a blocking acquire command (sls_detector_acquire or Detector::acquire), the control server is blocked until end of acquisition. However, stop server commands could be used in parallel.


 .. _Automatic start servers:
@ -92,8 +90,6 @@ One can start the on-board detector server automatically upon powering on the bo
      .. code-block:: bash
      
         sync
-
-         # physically reboot for Gotthard II or Mythen III
         reboot

         # verify
--- a/docs/src/serverupgrade.rst
+++ b/docs/src/serverupgrade.rst
@ -1,6 +1,6 @@
 .. _Detector Server Upgrade:
-Upgrade
-========
+Detector Server Upgrade
+=======================


 **Location:** slsDetectorPackage/serverBin/ folder for every release.
@ -14,7 +14,7 @@ Upgrade
    Eiger requires a manual reboot. Or killall the servers and restart the new linked one. If you are in the process of updating firmware, then don't reboot yet.


-6.1.1+ (no tftp required)
+From 6.1.1 and above (no tftp required)
 ---------------------------------------

 #. Program from console
@ -60,7 +60,7 @@ Troubleshooting with tftp
 #. text file busy: You are trying to copy the same server.


-< 5.0.0
--------
+Older than 5.0.0
+-----------------

 Please contact us.
--- a/docs/src/slsreceiver.rst
+++ b/docs/src/slsreceiver.rst
@ -86,209 +86,16 @@ Client Commands
        sls_detector_get -h rx_framescaught


-ZMQ: Json Header Format
------------------------
-
-
-**Change in field names from slsDetectorPackage v6.x.x to v7.0.0**
-
-* detSpec1 <- bunchId
-* detSpec2 <- reserved
-* detSpec3 <- debug
-* detSpec4 <- roundRNumber
-
-
-**Format**
-
-    .. code-block:: bash 
-
-        {
-            "jsonversion": unsigned int,
-            "bitmode": unsigned int,
-            "fileIndex": unsigned long int,
-            "detshape": [
-                unsigned int,
-                unsigned int
-            ],
-            "shape": [
-                unsigned int,
-                unsigned int
-            ],
-            "size": unsigned int,
-            "acqIndex": unsigned long int,
-            "frameIndex": unsigned long int,
-            "progress": double,
-            "fname": string,
-            "data": unsigned int,
-            "completeImage": unsigned int,
-
-            "frameNumber": unsigned long long int,
-            "expLength": unsigned int,
-            "packetNumber": unsigned int,
-            "detSpec1": unsigned long int,
-            "timestamp": unsigned long int,
-            "modId": unsigned int,
-            "row": unsigned int,
-            "column": unsigned int,
-            "detSpec2": unsigned int,
-            "detSpec3": unsigned int,
-            "detSpec4": unsigned int,
-            "detType": unsigned int,
-            "version": unsigned int,
-            
-            "flipRows": unsigned int,
-            "quad": unsigned int,
-            "addJsonHeader": {
-                string : string
-            },
-            "rx_roi": [
-                unsigned int,
-                unsigned int,
-                unsigned int,
-                unsigned int
-            ]
-        }
-
-   +--------------+----------------------------------------------+
-   |   Field      |       Description                            |
-   +--------------+----------------------------------------------+
-   | jsonversion  | Version of the json header.                  |
-   |              | Value at 4 for v6.x.x - v7.0.1               | 
-   |              | Value at 5 for v7.0.2                        |
-   +--------------+----------------------------------------------+
-   | bitmode      | Bits per pixel [4|8|16|32]                   |
-   +--------------+----------------------------------------------+
-   | fileIndex    | Current file acquisition index               |
-   +--------------+----------------------------------------------+
-   | detshape     | Geometry of the entire detector              |
-   +--------------+----------------------------------------------+
-   | shape        | Geometry of the current port streamed out    |
-   +--------------+----------------------------------------------+
-   | size         | Size of image of current port in bytesout    |
-   +--------------+----------------------------------------------+
-   | acqIndex     | Frame number from the detector (redundant)   |
-   +--------------+----------------------------------------------+
-   | frameIndex   | Frame number of current acquisition          |
-   |              | (Starting at 0)                              |
-   +--------------+----------------------------------------------+
-   | progress     | Progress of current acquisition in %         |
-   +--------------+----------------------------------------------+
-   | fname        | Current file name                            |
-   +--------------+----------------------------------------------+
-   | data         | 1 if there is data following                 |
-   |              | 0 if dummy header                            |
-   +--------------+----------------------------------------------+
-   | completeImage| 1 if no missing packets for this frame       |
-   |              | in this port, else 0                         |
-   +--------------+----------------------------------------------+
-   | frameNumber  | Frame number                                 |
-   |              | [From detector udp header]                   |
-   +--------------+----------------------------------------------+
-   | expLength    | subframe number (32 bit eiger)               |
-   |              | or real time exposure time in 100ns (others) |
-   |              | [From detector udp header]                   |
-   +--------------+----------------------------------------------+
-   | packetNumber | Number of packets caught for that frame      |
-   +--------------+----------------------------------------------+
-   | detSpec1     | See :ref:`here<Detector Specific Fields>`    |
-   |              | [From detector udp header]                   |
-   +--------------+----------------------------------------------+
-   | timestamp    | Timestamp with 10 MHz clock                  |
-   |              | [From detector udp header]                   |
-   +--------------+----------------------------------------------+
-   | modId        | Module Id                                    |
-   |              | [From detector udp header]                   |
-   +--------------+----------------------------------------------+
-   | row          | Row number in detector                       |
-   |              | [From detector udp header]                   |
-   +--------------+----------------------------------------------+
-   | column       | Column number in detector                    |
-   |              | [From detector udp header]                   |
-   +--------------+----------------------------------------------+
-   | detSpec2     | See :ref:`here<Detector Specific Fields>`    |
-   |              | [From detector udp header]                   |
-   +--------------+----------------------------------------------+
-   | detSpec3     | See :ref:`here<Detector Specific Fields>`    |
-   |              | [From detector udp header]                   |
-   +--------------+----------------------------------------------+
-   | detSpec4     | See :ref:`here<Detector Specific Fields>`    |
-   |              | [From detector udp header]                   |
-   +--------------+----------------------------------------------+
-   | detType      | Detector type enum                           |
-   | detSpec3     | See :ref:`Detector enum<Detector Enum>`      |
-   |              | [From detector udp header]                   |
-   +--------------+----------------------------------------------+
-   | version      | Detector header version. At 2                |
-   |              | [From detector udp header]                   |
-   +--------------+----------------------------------------------+
-   | flipRows     | 1 if rows should be flipped.                 |
-   |              | Usually for Eiger bottom.                    |
-   +--------------+----------------------------------------------+
-   | quad         | 1 if its an Eiger quad.                      |
-   +--------------+----------------------------------------------+
-   | addJsonHeader| Optional custom parameters that is required  |
-   |              | for processing code.                         |
-   +--------------+----------------------------------------------+
-   | rx_roi       | ROI in the receiver per port (xmin, xmax,    |
-   |              | ymin, ymax). For external guis to know       |
-   |              | what is saved                                |
-   +--------------+----------------------------------------------+
-
-SLS Receiver Header Format
--------------------------
-
-It is 112 bytes and consists of:
-    * 48 bytes of the SLS Detector Header (described in :ref:`the current detector header <detector udp header>`)
-    * 64 bytes of packet mask
-
-.. code-block:: cpp 
-    
-    typedef struct {
-        uint64_t frameNumber;
-        uint32_t expLength;
-        uint32_t packetNumber;
-        uint64_t detSpec1;
-        uint64_t timestamp;
-        uint16_t modId;
-        uint16_t row;
-        uint16_t column;
-        uint16_t detSpec2;
-        uint32_t detSpec3;
-        uint16_t detSpec4;
-        uint8_t detType;
-        uint8_t version;
-    } sls_detector_header;
-
-    struct sls_receiver_header {
-        sls_detector_header detHeader; /**< is the detector header */
-        sls_bitset packetsMask;        /**< is the packets caught bit mask */
-    };
-
-
-.. note :: 
-
-    | The packetNumber in the SLS Receiver Header will be modified to number of packets caught by receiver for that frame. For eg. Jungfrau will have 128 packets per frame. If it is less, then this is a partial frame due to missing packets.
-    
-    | Furthermore, the bit mask will specify which packets have been received.
-
-
-
-
 File format
 --------------

-Master file is in json format.
+* The file name format is [fpath]/[fname]_dx_fy_[findex].raw, where x is module index and y is file index. **fname** is file name prefix and by default "run". **fpath** is '/' by default.

-The file name format is [fpath]/[fname]_dx_fy_[findex].raw, where x is module index and y is file index. **fname** is file name prefix and by default "run". **fpath** is '/' by default.
+* Each acquisition will have an increasing acquisition index or findex (if file write enabled). This can be retrieved by using **findex** command. 

+* Each acquisition can have multiple files (the file index number **y**), with **rx_framesperfile** being the maximum number of frames per file. The default varies for each detector type.

-Each acquisition will have an increasing acquisition index or findex (if file write enabled). This can be retrieved by using **findex** command. 
-
-
-Each acquisition can have multiple files (the file index number **y**), with **rx_framesperfile** being the maximum number of frames per file. The default varies for each detector type.
-
-
-Some file name examples:
+* Some file name examples:

    .. code-block:: bash

@ -301,19 +108,17 @@ Some file name examples:
        # second acquisition, first file
        path-to-file/run_d0_f0_1.raw

+* Each acquisition will create a master file that can be enabled/disabled using **fmaster**. This should have parameters relevant to the acquisition.

-Each acquisition will create a master file that can be enabled/disabled using **fmaster**. This should have parameters relevant to the acquisition.
-
+* SLS Receiver Header consist of SLS Detector Header + 64 bytes of bitmask, altogether 112 bytes. The packetNumber in the sls detector header part, will be updated to number of packets caught by receiver for that frame. Furthermore, the bit mask will specify which packets have been received.

 **Binary file format**

-This is the default file format. 
+* This is the default file format. 

+* Each data file will consist of frames, each consisting of slsReceiver Header followed by data for 1 frame.

-Each data file will consist of frames, each consisting of slsReceiver Header followed by data for 1 frame.
-
-
-Master file is of ASCII format and will also include the format of the slsReceiver Header.
+* Master file is of ASCII format and will also include the format of the slsReceiver Header.


 **HDF5 file formats**
@ -355,7 +160,7 @@ When handling callbacks, the control should be returned as soon as possible, to
 **Example**
    * `main cpp file <https://github.com/slsdetectorgroup/api-examples/blob/master/e4-receiver_callbacks.cpp>`_ 
    * `cmake file <https://github.com/slsdetectorgroup/api-examples/blob/master/CMakeLists.txt>`_. 
-    * how to install the slsDetectorPackage with cmake is provided :ref:`here <build from source using cmake>`.
+    * how to install the slsDetectorPackage is provided :ref:`here <build from source using cmake>`.
    * compile the example **e4-rxr** by:

        .. code-block:: bash
--- a/docs/src/troubleshooting.rst
+++ b/docs/src/troubleshooting.rst
@ -8,24 +8,21 @@ open an issue at our  `github repo issues
 Common
 ------

+Missing Packets
+^^^^^^^^^^^^^^^
+Possible causes could be the following:

-1. Total Failure of Packet Delivery
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+#. Receiver PC is not tuned for socket buffer size and input packet queue.
+    * Refer to :ref:`Increase rmem_default, rmem_max and max_backlog<Receiver PC Tuning>`

-#. Data cable plugged into the wrong interface on board (Jungfrau)
-    * Please ensure that the data cable is plugged into the rightmost interface (default for single interface). The inner one is disabled for PCB v1.0 and must be selected via command for PCB v2.0.
+#. Wiring
+    * Faulty wiring or connecting cable to incorrect interface.

 #. Link up and speed
-    * Check ethtool and find if Link Deteced:Yes and Speed is acceptable (>10k).
-    * Check to see if the 10G link is up (blue or red LED on board, close to SFP+). If not:
-
-       * Check transeiver and fibers are compatible (all MMF 850nm or all SMF 1030nm)
-       * Check fiber
-       * Check fiber polarity (if short range, unplug the link anywhere, and look at the light/dark pattern: dark has to mate with light)
+    * Check to see if there is a blue LED on board to signal that the link is up. Check ethtool and find if Link Deteced:Yes and Speed is acceptable (>10k).

 #. Detector is not acquiring (Not Eiger)
    * Take an acquisition with many images and using the following steps instead of acquire:
-
        .. code-block:: bash

            sls_detector_put status start
@ -33,63 +30,37 @@ Common
            # which means the detector is acquiring.
            sls_detector_get framesl 

-            # If you are using multiple modules, the previous command can return -1 because each module will return different values. Then, check for a single module instead: sls_detector_get 0:framesl
+    .. note ::
+    
+        If you are using multiple modules, the previous command can return -1 because each module will return different values. Then, check for a single module instead: sls_detector_get 0:framesl

+#. Data cable plugged into the wrong interface on board (Jungfrau)
+    * Please ensure that the data cable is plugged into the rightmost interface. The middle one is disabled for PCB v1.0 and must be selected via command for PCB v2.0.

-#. Detector is not sending data (Except Eiger)
-    * Check the board to see if the green LED close to SFP is blinking (detector is sending data). If not, detector is not operated properly (period too short/long, no trigger in trigger mode) or misconfigured and needs reboot.
+#. Detector is not sending data
+    * Check the board to see if the green LED is blinking next to the data cable, which means that the detector is sending data.

-#. Power supply
-    * Check if power supply has enough current. 
-    * For Jungfrau, refer to :ref:`Jungfrau Power Supply Troubleshooting<Jungfrau Troubleshooting Power Supply>`.
+#. Firewall or security feature
+    * A firewall or some security feature could be blocking the reception of data.
+
+#. Ethernet interface not configured properly
+    * Ensure that the interfaces used are configured properly with the right mask and ip. Eg. use ifconfig and route commands to verify.

 #. Ethernet interface not configured for Jumbo frames (10Gb)
-    * Ensure that the interfaces (on NIC and the switch) used in receiver pc have MTU 9000 (jumbo frames) enabled.
+    * Ensure that the interfaces used in receiver pc have MTU 9000 (jumbo frames) enabled.

+#. Detector IP (Not Eiger)
+    * Ensure it is valid and does not end if 0 or 255. Also ensure that the detector ip is in the same subnet as rx_udpip and the masking in the interface configuration ensures this rule.

-#. Check if 'rx_frames' counter in 'ifconfig' do not increment for interface.
-    * If no, check switch configuration if present. Port counters of switch can also help to identify problem.
-    * If yes, but receiver software does not see it:
-
-        * Check no firewall (eg. firewalld) is present or add rules
-        * Check that selinux is disabled ( or add rules)
-        
-#. Source UDP IP in config file (Not Eiger)
-    * Ensure it is valid and does not end if 0 or 255. Also ensure that the source ip 'udp_srcip' is in the same subnet as destination ip 'udp_dstip' and the masking in the interface configuration ensures this rule.
-    * Eg. If interface IP is 102.10.10.110 and mask is 255.255.255.0, udp_srcip has to be 102.10.10.xxx (same subnet)
-    * Use ifconfig and route commands to verify etheret interface configuration
-
-
-#. Netstat and netcat
-    * Try with netstat to see if its really listening to the right interface. Or netcat to see if you get packets.
-
-#. Wireshark or Tcpdump
+#. Tcpdump or wireshark
    * Use one of these to confirm that you receive packets (with the right filtering ie. source and destination ports, ip).

-
-
-2. Partial or Random Packet Loss (Performance)
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-.. note ::
-    
-    The following suggestions are for convenience. Please do not follow blindly, research each parameter and adapt it to your system.
-
-#. Receiver PC is not tuned for socket buffer size and input packet queue or other parameters.
-    * Refer to :ref:`Receiver PC Tuning<Receiver PC Tuning>`
-
-#. Wiring
-    * Faulty wiring or connecting cable to incorrect interface.
-
+#. Check SFP modules
+    * Check if the SFP modules on both sides of the fiber are of same type.

 #. Pinging the subnet (receiving only a few number of packets each time)
    * If a switch is used between a receiver pc and detector instead of plugging the cables directly, one might have to ping any ip in the subnet of the Ethernet interface constantly so that it does not forget the ip during operation.
    * Eg. if rx_udpip is 10.2.3.100, then ping constantly 10.2.3.xxx, where xxx is any ip other than 100.
-    * Using slsReceiver, you can use a command that does this for you:
-        .. code-block:: bash
-        
-            # arping the interface in a separate thread every minute
-            sls_detector_put rx_arping 1



@ -97,12 +68,6 @@ Common

 Receiver PC Tuning Options
 ^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-.. note ::
-
-    | xth1 is example interface name in the following examples. 
-    | These settings are lost at pc reboot.
-
 #. Increase maximum receive socket buffer size and socket input packet queue. 
    * Temporarily (until shut down)
        .. code-block:: bash
@ -146,7 +111,6 @@ Receiver PC Tuning Options
        # check how many GB memory you can allocate, to avoid swapping otherwise    


-
 #. Modify ethtool settings. 
    * rx ring parameters
        .. code-block:: bash
@ -163,9 +127,6 @@ Receiver PC Tuning Options
            # check 
            ethtool -c xth1

-            # enable adaptive xoalescence parameters
-            ethtool -C xth1 adaptive-rx on
-
            # set to max value in your pc settings
            ethtool -C xth1 rx-usecs 100 

@ -177,43 +138,11 @@ Receiver PC Tuning Options

            # set to max value in your pc settings
            ethtool -A xth1 rx on
-    
-    * generic receiver offload (might not always work)
-        .. code-block:: bash
+ 
+    .. note ::

-            # check
-            ethtool -k xth1
-
-            # enable generic receiver offload
-            ethtool -K xth1 gro
-        
-
-#. Disable power saving in CPU frequency scaling and set system to performance 
-    * Check current policy (default might be powersave or schedutil)
-        .. code-block:: bash
-            
-            # check current active governor and range of cpu freq policy
-            cpupower frequency-info --policy
-            # list all available governors for this kernel
-            cpupower frequency-info --governors  
-
-    * Temporarily (until shut down)
-        .. code-block:: bash
-            
-            # set to performance
-            sudo cpupower frequency-set -g performance
-
-            # or
-            cpufreq-info
-            for i in ‘seq 0 7‘; do cpufreq-set -c $i -g performance; done
-            
-    * Permanently
-        .. code-block:: bash
-            
-            # edit /etc/sysconfig/cpupower to preference
-
-            # enable or disable permanently
-            sudo systemctl enable cpupower
+        | xth1 is example interface name. 
+        | These settings are lost at pc reboot.

 #. Give user speicific user scheduling privileges.
    .. code-block:: bash
@ -226,29 +155,18 @@ Receiver PC Tuning Options

        This is also set if slsReceiver is run as root user.
        
-#. Some more advanced options: 
-    .. warning ::
        
-        Please do not try if you do not understand
+#. Disable power saving in CPU frequency 
+    .. code-block:: bash

-    #. reduce the number of queue per NIC to the number of expected streams: ethtool -L xth0 combined 2 
-    #. assign each queue to its stream:  ethtool -U xth0 flow-type tcp4 dst-port 50004 action 1
-    #. assign to each queue (IRQ) one CPU on the right socket:  echo "3"> /proc/irq/47/smp_affinity_list    #change the numbers looking at /proc/interrupts
-    #. disable irqbalance service 
-    #. Be sure that the switch knows the receiver mac address. Most switches reset the mac lists every few minutes, and since the receiver only receives, there is not a periodic refresh of the mac list. In this case, one can set a fixed mac list in the switch, or setup some kind of script arping or pinging out from that interface (will be available in 7.0.0). 
-    #. assign the receiver numa node (also with -m) to the socket where the NIC is attached. To know it, cat /sys/class/net/ethxxx/device/numa_node
-    #. ensure file system performance can handle sustained high data rate:
-        
-        * One can use dd: 
+        # or similar command depending on your distribution
+        cpupower frequency-info
+        cpupower frequency-set -g performance

-            .. code-block:: bash
-	            
-                dd if=/dev/zero of=/testpath/testfile bs=1M count=100000
-        * Or better fio (which needs to be installed) 
+        # or
+        cpufreq-info
+        for i in ‘seq 0 7‘; do cpufreq-set -c $i -g performance; done

-            .. code-block:: bash
-	        
-                fio --name=global –directory=/testpath/ --rw=write --ioengine=libaio --direct=0 --size=200G -- 	numjobs=2 --iodepth=1 --bs=1M –name=job

 slsReceiver Tuning
 ^^^^^^^^^^^^^^^^^^
@ -256,25 +174,18 @@ slsReceiver Tuning
 #. Starting receiver as root to have scheduling privileges.

 #. For 10g, enable flow control
-
    .. code-block:: bash

        sls_detector_put flowcontrol10g 1

-#. Increase slsReceiver ring buffer depth 
-    This can be tuned depending on the number of receivers (modules) and memory available.
-
+#. Increase slsReceiver fifo depth between listening and processing threads.
    .. code-block:: bash

-        # sugggested not to use more than half memory of CPU socket in case of NUMA systems) for this
-
        sls_detector_get rx_fifodepth
-        # sets number of frames in fifo to 1024 ~1GB per receiver. Default is 2500
-        sls_detector_put rx_fifodepth 1024
-
-#. Increase number of frames per file 
-    This can reduce time taken to open and close files.
+        # sets number of frames in fifo to 5000
+        sls_detector_put rx_fifodepth 5000

+#. Increase number of frames per file to reduce time taken to open and close files.
    .. code-block:: bash

        sls_detector_get rx_framesperfile
@ -282,31 +193,10 @@ slsReceiver Tuning
        # writes all frames into a single file
        sls_detector_put rx_framesperfile 0

-#. Disable file write
-    This can ensure it is not the file system performance hampering high date rate.
-
-    .. code-block:: bash
-
-        sls_detector_put fwrite 0
-

 Shared memory error
 ^^^^^^^^^^^^^^^^^^^
-For errors due to access or size, use any of the following suggestions.
-    #. Delete shared memory files and try again
-    #. Use environment variable to use a different shared memory ending in jfxx
-        
-        .. code-block:: bash
-
-            # shared memory ending in jfxx
-            export SLSDETNAME=jfxx
-
-    #. USe a different multi shared memory ID
-        .. code-block:: bash
-    
-            sls_detector_put 2-config xxxx.config
-            # or
-            sls_detector_put 2-hostname bchipxxx
+| For errors due to access or size, delete shared memory files nd try again.

 To list all shared memory files of sls detector package.
    .. code-block:: bash
@ -417,7 +307,6 @@ Cannot get multi module data

 #. Check :ref:`Common Multi Module Troubleshooting<common troubleshooting multi module data>`
 #. Power Supply
-    * Jungfrau needs a ~4A per module for a short time at startup. If not, it reboots misconfigured.
    * Comment out this line in the config file: powerchip 1
    * Powering on the chip increases the power consumption by a considerable amount. If commenting out this line aids in getting data (strange data due to powered off chip), then it could be the power supply current limit. Fix it (possibly to 8A current limit) and uncomment the powerchip line back in config file.

--- a/docs/src/udpconfig.rst
+++ b/docs/src/udpconfig.rst
@ -1,37 +0,0 @@
-.. _detector udp header:
-
-
-Config file
-============
-
-Commands to configure the UDP in the config file:
-
-.. note :: 
-
-    These command are recommended to be placed before "rx_hostname" if it is used.
-
-Source Port
-----------
-    Hardcoded in detector server, starting at 32410.
-
-udp_srcip - Source IP
---------------------
-    IP address of detector UDP interface to send packets from. Do not use for Eiger 1Gb interface (uses its hardware IP). For others, must be in the same subnet as **udp_dstip**.
-
-udp_srcmac - Source MAC
-----------------------
-    MAC address of detector UDP interface to send packets from. Do not use for Eiger (uses hardware mac). For others, it is not necessary, but can help for switch and debugging to put unique values for each module.
- 
-
-udp_dstport - Desintation Port
-------------------------------
-    Port in receiver pc to listen to packets from the detector.
-
-udp_dstip - Destination IP
--------------------------
-    IP address of interface in receiver pc to listen to packets from detector. If **auto** is used (only when using slsReceiver/ slsMultiReceiver), the IP of **rx_hostname** is picked up.
-
-udp_dstmac - Destination MAC
----------------------------
-    MAC address of interface in receiver pc to list to packets from detector. Only required when using custom receiver, else slsReceiver/slsMultiReceiver picks it up from **udp_dstip**.
-
--- a/docs/src/udpdetspec.rst
+++ b/docs/src/udpdetspec.rst
@ -1,152 +0,0 @@
-.. _detector specific fields:
-
-Detector Specific Fields
-========================
-
-Please check out :ref:`the current detector header <detector udp header>` to see 
-where the detector specific fields are placed.
-
-
-
-Eiger
------
-
-.. table:: Detector Specific Field
-   
-   +----------+------------------------------+
-   | expLength| Sub Frame Number             |
-   +----------+------------------------------+
-   | detSpec1 | 0x0                          |
-   +----------+------------------------------+
-   | detSpec2 | 0x0                          |
-   +----------+------------------------------+
-   | detSpec3 | e14a                         |
-   +----------+------------------------------+
-   | detSpec4 | Round Robin Interface Number |
-   +----------+------------------------------+
-
-
-Jungfrau
---------
-
-.. table:: Detector Specific Field
-
-   +----------+------------------------------+
-   | detSpec1 | Bunch Id [#]_                |
-   +----------+------------------------------+
-   | detSpec2 | 0                            |
-   +----------+------------------------------+
-   | detSpec3 | DAQ info                     |
-   +----------+------------------------------+
-   | detSpec4 | 0                            |
-   +----------+------------------------------+
-
-
-.. table:: DAQ Info Field
-
-   +----------+--------------------+----------------------------------------------+
-   |   Bits   |       Name         |   Description                                |
-   +----------+--------------------+-----+----------------------------------------+
-   | 0        | High gain          |  1  | High Gain enabled                      |
-   |          |                    +-----+----------------------------------------+
-   |          |                    |  0  | High Gain disabled                     |
-   +----------+--------------------+-----+----------------------------------------+
-   | 1        | Fix gain stage 1   |  1  | Gain stage 1 fixed. The switch that    |
-   |          |                    |     | selects the gains stage 1 is active all|
-   |          |                    |     | the time.                              |
-   |          |                    +-----+----------------------------------------+
-   |          |                    |  0  | Gain stage 1 unset. The switch that    |
-   |          |                    |     | selects the gains stage 1 is inactive  |
-   |          |                    |     | all the time.                          |
-   +----------+--------------------+-----+----------------------------------------+
-   | 2        | Fix gain stage 2   |  1  | Gain stage 2 fixed. The switch that    |
-   |          |                    |     | selects the gains stage 2 is active all|
-   |          |                    |     | the time.                              |
-   |          |                    +-----+----------------------------------------+
-   |          |                    |  0  | Gain stage 2 unset. The switch that    |
-   |          |                    |     | selects the gains stage 2 is inactive  |
-   |          |                    |     | all the time.                          |
-   +----------+--------------------+-----+----------------------------------------+
-   | 4        | Comparator reset   |  1  | On-chip comparator in reset state.     | 
-   |          |                    |     | Dynamic-gain switching is therefore    |
-   |          |                    |     | disabled.                              |
-   |          |                    +-----+----------------------------------------+
-   |          |                    |  0  | On-chip comparator active.             |
-   +----------+--------------------+-----+-----+-----+----------------------------+
-   | 7-5      | Jungfrau chip      |Bit 7|Bit 6|Bit 5| Description                |
-   |          | version            +-----+-----+-----+----------------------------+
-   |          |                    | 0   |   0 |  0  | v1.0                       |
-   |          |                    +-----+-----+-----+----------------------------+
-   |          |                    | 0   |   0 |  1  | v1.1                       |
-   |          |                    +-----+-----+-----+----------------------------+
-   |          |                    | 0   |   1 |  X  | Reserved                   |
-   |          |                    +-----+-----+-----+----------------------------+
-   |          |                    | 1   |   X |  X  | Reserved                   |
-   +----------+--------------------+-----+-----+-----+----------------------------+
-   | 11-8     | Storage cell select|Storage cell used for this exposure. This     |
-   |          |                    |field defines the storage cell that was used  |
-   |          |                    |to acquire the data of this frame             |
-   +----------+--------------------+-----+----------------------------------------+
-   | 12       | Force switching    |  1  | Forced switching to gain stage 1 at the|
-   |          | to gain stage 1    |     | start of the exposure period.          |
-   |          |                    +-----+----------------------------------------+
-   |          |                    |  0  | Disabled forced gain switching to gain |
-   |          |                    |     | stage 1. Dynamic gain switching        |
-   |          |                    |     | conditions apply.                      |
-   +----------+--------------------+-----+----------------------------------------+
-   | 13       | Force switching    |  1  | Forced switching to gain stage 2 at the|
-   |          | to gain stage 2    |     | start of the exposure period.          |
-   |          |                    +-----+----------------------------------------+
-   |          |                    | 0   | Disabled forced gain switching to gain |
-   |          |                    |     | stage 2. Dynamic gain switching        |
-   |          |                    |     | conditions apply.                      |
-   +----------+--------------------+-----+-----+-----+----------------------------+
-   | 23-16    |  10-Gigabit event  |The 8-bit event code contains value of the    |
-   |          |  code              |event received over the 10 GbE interface by   |
-   |          |                    |JUNGFRAU detector at the moment of the frame  |
-   |          |                    |acquisition.                                  |
-   +----------+--------------------+-----+----------------------------------------+
-   | 31       | External input flag|  1  | External input flag detected in the    |
-   |          |                    |     | last exposure.                         |
-   |          |                    +-----+----------------------------------------+
-   |          |                    |  0  | External input flag not detected in the|
-   |          |                    |     | last exposure.                         |
-   +----------+--------------------+-----+----------------------------------------+
-
-
-
-Gotthard2
----------
-
-.. table:: Detector Specific Field
-
-   +----------+------------------------------+
-   | detSpec1 | Train Id [#]_                |
-   +----------+------------------------------+
-   | detSpec2 | Bunch Id [#]_                |
-   +----------+------------------------------+
-   | detSpec3 | 0                            |
-   +----------+------------------------------+
-   | detSpec4 | 0                            |
-   +----------+------------------------------+
-
-
-Mythen3
----------
-
-.. table:: Detector Specific Field
-
-   +----------+------------------------------+
-   | detSpec1 | 0                            |
-   +----------+------------------------------+
-   | detSpec2 | 0                            |
-   +----------+------------------------------+
-   | detSpec3 | 0                            |
-   +----------+------------------------------+
-   | detSpec4 | 0                            |
-   +----------+------------------------------+
-
-
-.. [#] **Bunch Id**: bunch identification number received by the detector at the moment of frame acquisition.
-.. [#] **Train Id**: train identification number received by the detector at the moment of frame acquisition.
-.. [#] **Bunch Id**: bunch identification number to identify every single exposure during a burst acquisition.
--- a/docs/src/udpheader.rst
+++ b/docs/src/udpheader.rst
@ -1,125 +0,0 @@
-.. _detector udp header:
-
-Format
-=======
-
-The UDP data format for the packets consist of a common header for all detectors, followed by the data for that one packet.
-
-
-Current Version
---------------------------
-
-**v2.0 (slsDetectorPackage v7.0.0+)**
-
-.. table:: <---------------------------------------------------- 8 bytes per row --------------------------------------------->
-    :align: center
-    :widths: 30,30,30,15,15
-
-    +---------------------------------------------------------------+
-    |                          frameNumber                          |
-    +-------------------------------+-------------------------------+
-    |            expLength          |         packetNumber          |
-    +-------------------------------+-------------------------------+
-    |                         **detSpec1**                          |
-    +---------------------------------------------------------------+
-    |                           timestamp                           |
-    +---------------+---------------+---------------+---------------+
-    |     modId     |      row      |     column    |  **detSpec2** |
-    +---------------+---------------+---------------+-------+-------+
-    |          **detSpec3**         |  **detSpec4** |detType|version|
-    +-------------------------------+---------------+-------+-------+
-
-
-.. note :: 
-
-    Since there is no difference in the format of the UDP header from the detector
-    from the previous version (v2.0), the version number stays the same.
-    
-    Only the struture member names have changed in sls_detector_defs.h
-
-
-
-Description
------------
-
-* **Detector specific field** descriptions are found :ref:`here<detector specific fields>`.
-
-* **frameNumber**: framenumber to which the current packet belongs to.
-
-* **expLength**: measured exposure time of the frame in tenths of microsecond. It is instead the sub frame number for Eiger.
-
-* **packetNumber**: packet number of the frame to which the current data belongs to.
-
-* **timestamp**: time measured at the start of frame exposure since the start of the current measurement. It is expressed in tenths of microsecond.
-
-* **modId**: module ID picked up from det_id_[detector type].txt on the detector cpu.
-
-* **row**: row position of the module in the detector system. It is calculated by the order of the module in hostname command, as well as the detsize command.
-
-* **column**: column position of the module in the detector system.  It is calculated by the order of the module in hostname command, as well as the detsize command.
-
-* **detType**: detector type from enum of detectorType in the package.
-
-* **version**: current version of the detector header (0x2).
-
-
-Detector Enum
--------------
-
-    ================    ========
-    Detector Type        Value
-    ================    ========
-    GENERIC             0
-    EIGER               1
-    GOTTHARD            2    
-    JUNGFRAU            3    
-    CHIPTESTBOARD       4        
-    MOENCH              5
-    MYTHEN3             6
-    GOTTHARD2           7    
-    ================    ========
-
-
-
-Previous Versions
-----------------
-**v2.0 (Package v4.0.0 -  6.x.x)**
-
-.. table:: <---------------------------------------------------- 8 bytes ---------------------------------------------------->
-    :align: center
-    :widths: 30,30,30,15,15
-
-    +---------------------------------------------------------------+
-    |                          frameNumber                          |
-    +-------------------------------+-------------------------------+
-    |            expLength          |         packetNumber          |
-    +-------------------------------+-------------------------------+
-    |                            bunchid                            |
-    +---------------------------------------------------------------+
-    |                           timestamp                           |
-    +---------------+---------------+---------------+---------------+
-    |     modId     |    **row**    |   **column**  |  **reserved** |
-    +---------------+---------------+---------------+-------+-------+
-    |             debug             |  roundRNumber |detType|version|
-    +-------------------------------+---------------+-------+-------+
-
-**v1.0 (Package v3.0.0 -  3.1.5)**
-
-.. table:: <---------------------------------------------------- 8 bytes ---------------------------------------------------->
-    :align: center
-    :widths: 30,30,30,15,15
-
-    +---------------------------------------------------------------+
-    |                          frameNumber                          |
-    +-------------------------------+-------------------------------+
-    |            expLength          |         packetNumber          |
-    +-------------------------------+-------------------------------+
-    |                            bunchid                            |
-    +---------------------------------------------------------------+
-    |                           timestamp                           |
-    +---------------+---------------+---------------+---------------+
-    |     modId     |    xCoord     |     yCoord    |    zCoord     |
-    +---------------+---------------+---------------+-------+-------+
-    |             debug             |  roundRNumber |detType|version|
-    +-------------------------------+---------------+-------+-------+
-
--- a/docs/src/virtualserver.rst
+++ b/docs/src/virtualserver.rst
@ -1,6 +1,6 @@
 .. _Virtual Detector Servers:
-Simulators
-===========
+Detector Simulators
+===================

 Compilation
 -----------
@ -13,14 +13,16 @@ Compilation
 * Using cmk.sh script,
     .. code-block:: bash  
        
-        ./cmk.sh -bsj9 # option -s is for simulator
+        ./cmk.sh -bsj9 #option s is for simulator


 Binaries
 ^^^^^^^^
    .. code-block:: bash  

-        eigerDetectorServer_virtual
+        eigerDetectorServerMaster_virtual
+        eigerDetectorServerSlaveTop_virtual
+        eigerDetectorServerSlaveBottom_virtual
        jungfrauDetectorServer_virtual
        gotthardDetectorServer_virtual
        gotthard2DetectorServer_virtual
@ -65,15 +67,7 @@ Sample Config file
 ^^^^^^^^^^^^^^^^^^
 There are sample config files for each detector in slsDetectorPackage/examples folder.

-For a Single Module (Basic)
-    .. code-block:: bash  
-
-        hostname localhost
-        rx_hostname localhost
-        udp_dstip auto
-
-
-For a Single Module (With Options)
+For a Single Module
    .. code-block:: bash  

        # connects to control port 1912
@ -146,7 +140,7 @@ Gui
 Limitations
 -----------

-#. Data coming out of virtual server is fake. 
+#. Data coming out of virtual server is fake. Value at each pixel/ channel is incremented by 1.

 #. A stop will stop the virtual acquisition only at the start of every new frame.

--- a/docs/static/extra.css
+++ b/docs/static/extra.css
@ -1,4 +1,4 @@
 /* override table no-wrap */
 .wy-table-responsive table td, .wy-table-responsive table th {
    white-space: normal;
-}
+}
--- a/evalVersionVariables.sh
+++ b/evalVersionVariables.sh
@ -0,0 +1,24 @@
+# SPDX-License-Identifier: LGPL-3.0-or-other
+# Copyright (C) 2021 Contributors to the SLS Detector Package
+GITREPO1='git remote -v'
+GITREPO2=" | grep \"fetch\" | cut -d' ' -f1"
+BRANCH1='git branch -v'
+BRANCH2=" | grep '*' | cut -d' ' -f2"
+REPUID1='git log --pretty=format:"%H" -1'
+AUTH1_1='git log --pretty=format:"%cn" -1'
+AUTH1_2=" | cut -d' ' -f1"
+AUTH2_1='git log --pretty=format:"%cn" -1'
+AUTH2_2=" | cut -d' ' -f2"
+FOLDERREV1='git log --oneline . '   #used for all the individual server folders
+FOLDERREV2=" | wc -l"  #used for all the individual server folders
+REV1='git log --oneline  '
+REV2=" | wc -l"
+
+GITREPO=`eval $GITREPO1  $GITREPO2`
+BRANCH=`eval $BRANCH1  $BRANCH2`
+REPUID=`eval $REPUID1`
+AUTH1=`eval $AUTH1_1  $AUTH1_2`
+AUTH2=`eval $AUTH2_1  $AUTH2_2`
+REV=`eval $REV1  $REV2`
+FOLDERREV=`eval $FOLDERREV1  $FOLDERREV2`
+
--- a/examples/badchannel.txt
+++ b/examples/badchannel.txt
@ -1,6 +0,0 @@
-0
-10, 30
-40:45 50:52
-1279
-# all bad channels are applied for all counters in deector
-
--- a/examples/jctb_moench03_T1.config
+++ b/examples/jctb_moench03_T1.config
@ -409,18 +409,18 @@ patword 018d 0008599f0008503a
 patioctrl 8f0effff6dbffdbf
 patclkctrl 0000000000000000
 patlimits 0000 018c
-patloop 0 013a 016b
-patnloop 0 199
-patloop 1 0400 0400
-patnloop 1 0
-patloop 2 0400 0400
-patnloop 2 0
-patwait 0 00aa
-patwaittime 0 10000
-patwait 1 0400
-patwaittime 1 0
-patwait 2 0400
-patwaittime 2 0
+patloop0 013a 016b
+patnloop0 199
+patloop1 0400 0400
+patnloop1 0
+patloop2 0400 0400
+patnloop2 0
+patwait0 00aa
+patwaittime0 10000
+patwait1 0400
+patwaittime1 0
+patwait2 0400
+patwaittime2 0

 #############################################
 ### edit with hostname or 1Gbs IP address of your server
--- a/examples/jungfrau_two.config
+++ b/examples/jungfrau_two.config
@ -5,7 +5,7 @@ detsize 1024 1024
 hostname bchip048+bchip052+

 # 1Gb receiver pc hostname  (default tcpport: 1954)
-rx_hostname pcmoench01:1954+pcmoench01:1955+
+rx_hostname pcmoench01+pcmoench01:1955



--- a/examples/moench03_T1.config
+++ b/examples/moench03_T1.config
@ -3,33 +3,33 @@
 ### edit with hostname or IP address of your detector 
 ############################################
 #hostname bchip181+
-hostname bchip135 
+hostname bchip119.psi.ch

 #############################################
 ### edit with hostname or 1Gbs IP address of your server
 ############################################
-rx_hostname mpc2011
+rx_hostname mpc2011:1777

 #############################################
 ### edit with 10 Gbs IP of your server
 ############################################
-udp_dstip 10.1.1.102
+udp_dstip 10.1.2.102
 #############################################
 ### edit with any number in the subnet of your server (first 3 numbers as above)
 ############################################
-udp_srcip 10.1.1.19
-udp_dstport 32411
+udp_srcip 10.1.2.19
+udp_dstport 32000

 #############################################
 ### edit with 10 Gbs IP of your server
 ############################################
-rx_zmqip 10.1.1.102
-rx_zmqport 50003
+rx_zmqip 10.1.2.102
+rx_zmqport 77000
 #############################################
 ### edit with 1 Gbs IP of PC where you will run the GUI
 ############################################
-zmqip 129.129.202.57
-zmqport 50001
+zmqip  129.129.202.132
+zmqport 77001



@ -38,7 +38,7 @@ rx_zmqstream 1



-frames 100000
+frames 1000
 period 0.0006
 exptime 0.00035

@ -62,3 +62,9 @@ highvoltage 90
 #adcreg 0x14 0x40


+
+frames 10
+period 0.1
+rx_jsonpara subframes 1
+rx_jsonpara frameMode raw
+rx_jsonpara detectorMode analog
--- a/examples/virtual_ctb_moench.config
+++ b/examples/virtual_ctb_moench.config
@ -1,18 +1,18 @@
 # detector hostname
 hostname localhost:1910

-# udp destination ports
-udp_dstport 50010
-
-# udp source ip (same subnet as udp_dstip)
-udp_srcip 192.168.1.100
-
 # receiver hostname
 rx_hostname mpc1922:2010

+# udp destination ports
+udp_dstport 50010
+
 # udp destination ip from rx_hostname
 udp_dstip auto

+# udp source ip (same subnet as udp_dstip)
+udp_srcip 192.168.1.100
+
 # output file directory
 fpath /tmp

@ -27,7 +27,418 @@ dbitclk 40


 # patterns
-pattern /tmp/pattern.pat
+patword 0x0000 0x0000000000000000
+patword 0x0001 0x0000000000000000
+patword 0x0002 0x0008000900080000
+patword 0x0003 0x0008000900080000
+patword 0x0004 0x0008000900080000
+patword 0x0005 0x0008000900080000
+patword 0x0006 0x0008000900080000
+patword 0x0007 0x0008000900080000
+patword 0x0008 0x0008000900080000
+patword 0x0009 0x0008000900080000
+patword 0x000a 0x0008000900080000
+patword 0x000b 0x0008000900080000
+patword 0x000c 0x0008000900080000
+patword 0x000d 0x0008000900080000
+patword 0x000e 0x0008000900080000
+patword 0x000f 0x0008000900080000
+patword 0x0010 0x0008000900080000
+patword 0x0011 0x0008000900080000
+patword 0x0012 0x0008000900080000
+patword 0x0013 0x0008000900080000
+patword 0x0014 0x0008000900080000
+patword 0x0015 0x0008000900080000
+patword 0x0016 0x0008400900080020
+patword 0x0017 0x0008400900080020
+patword 0x0018 0x0008599f0418503a
+patword 0x0019 0x0008599f0418503a
+patword 0x001a 0x0108599f0418503a
+patword 0x001b 0x0108599f0418503a
+patword 0x001c 0x0108599f0418503a
+patword 0x001d 0x0108599f0418503a
+patword 0x001e 0x0108599f0418503a
+patword 0x001f 0x0108599f0418503a
+patword 0x0020 0x0108599f0418503a
+patword 0x0021 0x0108599f0418503a
+patword 0x0022 0x0108599f0418503a
+patword 0x0023 0x0108599f0418503a
+patword 0x0024 0x0108599f0418503a
+patword 0x0025 0x0108599f0418503a
+patword 0x0026 0x0108599f0418503a
+patword 0x0027 0x0108599f0418503a
+patword 0x0028 0x0108599f0418503a
+patword 0x0029 0x0108599f0418503a
+patword 0x002a 0x0108599f0418503a
+patword 0x002b 0x0108599f0418503a
+patword 0x002c 0x0108599f0418503a
+patword 0x002d 0x0108599f0418503a
+patword 0x002e 0x0108599f0418503a
+patword 0x002f 0x0108599f0418503a
+patword 0x0030 0x0108599f0418503a
+patword 0x0031 0x0108599f0418503a
+patword 0x0032 0x0108599f0418503a
+patword 0x0033 0x0108599f0418503a
+patword 0x0034 0x0108599f0418503a
+patword 0x0035 0x0108599f0418503a
+patword 0x0036 0x0108599f0418503a
+patword 0x0037 0x0108599f0418503a
+patword 0x0038 0x0108599f0418503a
+patword 0x0039 0x0108599f0418503a
+patword 0x003a 0x0108599f0418503a
+patword 0x003b 0x0108599f0418503a
+patword 0x003c 0x0108599f0418503a
+patword 0x003d 0x0108599f0418503a
+patword 0x003e 0x0108599f0418503a
+patword 0x003f 0x0108599f0418503a
+patword 0x0040 0x0108599f0418503a
+patword 0x0041 0x0108599f0418503a
+patword 0x0042 0x0108599f0418503a
+patword 0x0043 0x0108599f0418503a
+patword 0x0044 0x0108599f0418503a
+patword 0x0045 0x0108599f0418503a
+patword 0x0046 0x0108599f0418503a
+patword 0x0047 0x0108599f0418503a
+patword 0x0048 0x0108599f0418503a
+patword 0x0049 0x0108599f0418503a
+patword 0x004a 0x0108599f0418503a
+patword 0x004b 0x0108599f0418503a
+patword 0x004c 0x0108599f0418503a
+patword 0x004d 0x0108599f0418503a
+patword 0x004e 0x0108599f0418503a
+patword 0x004f 0x0108599f0418503a
+patword 0x0050 0x0108599f0418503a
+patword 0x0051 0x0108599f0418503a
+patword 0x0052 0x0108599f0418503a
+patword 0x0053 0x0108599f0418503a
+patword 0x0054 0x0108599f0418503a
+patword 0x0055 0x0108599f0418503a
+patword 0x0056 0x0108599f0418503a
+patword 0x0057 0x0108599f0418503a
+patword 0x0058 0x0108599f0418503a
+patword 0x0059 0x0108599f0418503a
+patword 0x005a 0x0108599f0418503a
+patword 0x005b 0x0108599f0418503a
+patword 0x005c 0x0108599f0418503a
+patword 0x005d 0x0108599f0418503a
+patword 0x005e 0x0108599f0418503a
+patword 0x005f 0x0108599f0418503a
+patword 0x0060 0x0108599f0418503a
+patword 0x0061 0x0108599f0418503a
+patword 0x0062 0x0108599f0418503a
+patword 0x0063 0x0108599f0418503a
+patword 0x0064 0x0108599f0418503a
+patword 0x0065 0x0108599f0418503a
+patword 0x0066 0x0108599f0418503a
+patword 0x0067 0x0108599f0418503a
+patword 0x0068 0x0108599f0418503a
+patword 0x0069 0x0108599f0418503a
+patword 0x006a 0x0108599f0418503a
+patword 0x006b 0x0108599f0418503a
+patword 0x006c 0x0108599f0418503a
+patword 0x006d 0x0108599f0418503a
+patword 0x006e 0x0108599f0418503a
+patword 0x006f 0x0108599f0418503a
+patword 0x0070 0x0108599f0418503a
+patword 0x0071 0x0108599f0418503a
+patword 0x0072 0x0108599f0418503a
+patword 0x0073 0x0108599f0418503a
+patword 0x0074 0x0108599f0418503a
+patword 0x0075 0x0108599f0418503a
+patword 0x0076 0x0108599f0418503a
+patword 0x0077 0x0108599f0418503a
+patword 0x0078 0x0108599f0418503a
+patword 0x0079 0x0108599f0418503a
+patword 0x007a 0x0108599f0418503a
+patword 0x007b 0x0108599f0418503a
+patword 0x007c 0x0108599f0418503a
+patword 0x007d 0x0108599f0418503a
+patword 0x007e 0x010859960418503a
+patword 0x007f 0x010859960418503a
+patword 0x0080 0x010859960418503a
+patword 0x0081 0x010859960418503a
+patword 0x0082 0x010859960418503a
+patword 0x0083 0x010859960418503a
+patword 0x0084 0x010859960418503a
+patword 0x0085 0x010859960418503a
+patword 0x0086 0x010859960418503a
+patword 0x0087 0x010859960418503a
+patword 0x0088 0x010859960418503a
+patword 0x0089 0x010859960418503a
+patword 0x008a 0x010859960418503a
+patword 0x008b 0x010859960418503a
+patword 0x008c 0x010859960418503a
+patword 0x008d 0x010859960418503a
+patword 0x008e 0x010859960418503a
+patword 0x008f 0x010859960418503a
+patword 0x0090 0x010859960418503a
+patword 0x0091 0x010859960418503a
+patword 0x0092 0x010819960418501a
+patword 0x0093 0x010819960418501a
+patword 0x0094 0x010819960418501a
+patword 0x0095 0x010819960418501a
+patword 0x0096 0x030819960418501a
+patword 0x0097 0x030819960418501a
+patword 0x0098 0x030819960418501a
+patword 0x0099 0x030819960418501a
+patword 0x009a 0x030819960418501a
+patword 0x009b 0x030819960418501a
+patword 0x009c 0x030819960418501a
+patword 0x009d 0x030819960418501a
+patword 0x009e 0x030819960418501a
+patword 0x009f 0x030819960418501a
+patword 0x00a0 0x030819960418501a
+patword 0x00a1 0x030819960418501a
+patword 0x00a2 0x030819960418501a
+patword 0x00a3 0x030819960418501a
+patword 0x00a4 0x030819960418501a
+patword 0x00a5 0x030819960418501a
+patword 0x00a6 0x030819960418501a
+patword 0x00a7 0x030819960418501a
+patword 0x00a8 0x030819960418501a
+patword 0x00a9 0x030819960418501a
+patword 0x00aa 0x030819960418501a
+patword 0x00ab 0x030819960418501a
+patword 0x00ac 0x030819960008501a
+patword 0x00ad 0x030819960008501a
+patword 0x00ae 0x030819960008501a
+patword 0x00af 0x030819960008501a
+patword 0x00b0 0x030819960008501a
+patword 0x00b1 0x030819960008501a
+patword 0x00b2 0x030819960008501a
+patword 0x00b3 0x030819960008501a
+patword 0x00b4 0x030819960008501a
+patword 0x00b5 0x030819960008501a
+patword 0x00b6 0x030819960008501a
+patword 0x00b7 0x030819960008501a
+patword 0x00b8 0x030819960008501a
+patword 0x00b9 0x030819960008501a
+patword 0x00ba 0x030819960008501a
+patword 0x00bb 0x030819960008501a
+patword 0x00bc 0x030819960008501a
+patword 0x00bd 0x030819960008501a
+patword 0x00be 0x030819960008501a
+patword 0x00bf 0x030819960008501a
+patword 0x00c0 0x0308199f0008501a
+patword 0x00c1 0x0308199f0008501a
+patword 0x00c2 0x0308199f0008501a
+patword 0x00c3 0x0308199f0008501a
+patword 0x00c4 0x0308199f0008501a
+patword 0x00c5 0x0308199f0008501a
+patword 0x00c6 0x0308199f0008501a
+patword 0x00c7 0x0308199f0008501a
+patword 0x00c8 0x0308199f0008501a
+patword 0x00c9 0x0308199f0008501a
+patword 0x00ca 0x0308199f0008501a
+patword 0x00cb 0x0308199f0008501a
+patword 0x00cc 0x0308199f0008501a
+patword 0x00cd 0x0308199f0008501a
+patword 0x00ce 0x0308199f0008501a
+patword 0x00cf 0x0308199f0008501a
+patword 0x00d0 0x0308199f0008501a
+patword 0x00d1 0x0308199f0008501a
+patword 0x00d2 0x0308199f0008501a
+patword 0x00d3 0x0308199f0008501a
+patword 0x00d4 0x0308599f0008503a
+patword 0x00d5 0x0308599f0008503a
+patword 0x00d6 0x030c599f000850ba
+patword 0x00d7 0x030c599f000850ba
+patword 0x00d8 0x030c599f000850ba
+patword 0x00d9 0x030c599f000850ba
+patword 0x00da 0x030c599f000850ba
+patword 0x00db 0x030c599f000850ba
+patword 0x00dc 0x030c599f000850ba
+patword 0x00dd 0x030c599f000850ba
+patword 0x00de 0x030c599f000850ba
+patword 0x00df 0x030c599f000850ba
+patword 0x00e0 0x030c599f000850ba
+patword 0x00e1 0x030c599f000850ba
+patword 0x00e2 0x030c599f000850ba
+patword 0x00e3 0x030c599f000850ba
+patword 0x00e4 0x030c599f000850ba
+patword 0x00e5 0x030c599f000850ba
+patword 0x00e6 0x030c599f000850ba
+patword 0x00e7 0x030c599f000850ba
+patword 0x00e8 0x030c599f000850ba
+patword 0x00e9 0x030c599f000850ba
+patword 0x00ea 0x030c799f010858ba
+patword 0x00eb 0x030c799f010858ba
+patword 0x00ec 0x030c599f000850ba
+patword 0x00ed 0x030c599f000850ba
+patword 0x00ee 0x030c599f000850ba
+patword 0x00ef 0x030c599f000850ba
+patword 0x00f0 0x030c599f000850ba
+patword 0x00f1 0x030c599f000850ba
+patword 0x00f2 0x030c599f000850ba
+patword 0x00f3 0x030c599f000850ba
+patword 0x00f4 0x030c599f000850ba
+patword 0x00f5 0x030c599f000850ba
+patword 0x00f6 0x030c599f000850ba
+patword 0x00f7 0x030c599f000850ba
+patword 0x00f8 0x030c599f000850ba
+patword 0x00f9 0x030c599f000850ba
+patword 0x00fa 0x030c599f000850ba
+patword 0x00fb 0x030c599f000850ba
+patword 0x00fc 0x030c599f000850ba
+patword 0x00fd 0x030c599f000850ba
+patword 0x00fe 0x030c599f000850ba
+patword 0x00ff 0x030c599f000850ba
+patword 0x0100 0x030c599f000850ba
+patword 0x0101 0x030c599f000850ba
+patword 0x0102 0x030c599f400850ba
+patword 0x0103 0x030c599f400850ba
+patword 0x0104 0x030c599f600850ba
+patword 0x0105 0x030c599f400850ba
+patword 0x0106 0x030c599f400850ba
+patword 0x0107 0x030c599f400850ba
+patword 0x0108 0x870c599f682e50ba
+patword 0x0109 0x870c599f482850ba
+patword 0x010a 0x870c599f000e50ba
+patword 0x010b 0x870c599f000850ba
+patword 0x010c 0x870c599f000e50ba
+patword 0x010d 0x870c599f000850ba
+patword 0x010e 0x870c599f000e50ba
+patword 0x010f 0x870c599f000850ba
+patword 0x0110 0x870c599f000e50ba
+patword 0x0111 0x870c599f000850ba
+patword 0x0112 0x870c599f000e50ba
+patword 0x0113 0x870c599f000850ba
+patword 0x0114 0x870c599f000e50ba
+patword 0x0115 0x870c599f000850ba
+patword 0x0116 0x870c599f000e50ba
+patword 0x0117 0x870c599f000850ba
+patword 0x0118 0x870c599f000e50ba
+patword 0x0119 0x870c599f000850ba
+patword 0x011a 0x870c599f000e50ba
+patword 0x011b 0x870c599f000850ba
+patword 0x011c 0x870c599f000e50ba
+patword 0x011d 0x870c599f000850ba
+patword 0x011e 0x870c599f000e50ba
+patword 0x011f 0x870c599f000850ba
+patword 0x0120 0x870c599f000e50ba
+patword 0x0121 0x870c599f000850ba
+patword 0x0122 0x870c599f200e50ba
+patword 0x0123 0x870c599f000850ba
+patword 0x0124 0x870c599f000e50ba
+patword 0x0125 0x870c599f000850ba
+patword 0x0126 0x870c599f000e50ba
+patword 0x0127 0x870c599f000850ba
+patword 0x0128 0x870c599f000e50ba
+patword 0x0129 0x870c599f000850ba
+patword 0x012a 0x870c599f000e50ba
+patword 0x012b 0x870c599f000850ba
+patword 0x012c 0x870c599f000e50ba
+patword 0x012d 0x870c599f000850ba
+patword 0x012e 0x870c599f000e50ba
+patword 0x012f 0x870c599f000850ba
+patword 0x0130 0x870c599f000e50ba
+patword 0x0131 0x870c599f000850ba
+patword 0x0132 0x870c599f000e50ba
+patword 0x0133 0x870c599f000850ba
+patword 0x0134 0x870c599f000e50ba
+patword 0x0135 0x870c599f000850ba
+patword 0x0136 0x870c599f000e50ba
+patword 0x0137 0x870c599f000850ba
+patword 0x0138 0x870c599f000e50ba
+patword 0x0139 0x870c599f000850ba
+patword 0x013a 0x870c599f282e50ba
+patword 0x013b 0x870c599f082850ba
+patword 0x013c 0x870c599f000e50ba
+patword 0x013d 0x870c599f000850ba
+patword 0x013e 0x870c599f000e50ba
+patword 0x013f 0x870c599f000850ba
+patword 0x0140 0x870c599f000e50ba
+patword 0x0141 0x870c599f000850ba
+patword 0x0142 0x870c599f000e50ba
+patword 0x0143 0x870c599f000850ba
+patword 0x0144 0x870c599f000e50ba
+patword 0x0145 0x870c599f000850ba
+patword 0x0146 0x870c599f000e50ba
+patword 0x0147 0x870c599f000850ba
+patword 0x0148 0x870c599f000e50ba
+patword 0x0149 0x870c599f000850ba
+patword 0x014a 0x870c599f000e50ba
+patword 0x014b 0x870c599f000850ba
+patword 0x014c 0x870c599f000e50ba
+patword 0x014d 0x870c599f000850ba
+patword 0x014e 0x870c599f000e50ba
+patword 0x014f 0x870c599f000850ba
+patword 0x0150 0x870c599f000e50ba
+patword 0x0151 0x870c599f000850ba
+patword 0x0152 0x870c599f000e50ba
+patword 0x0153 0x870c599f000850ba
+patword 0x0154 0x870c599f200e50ba
+patword 0x0155 0x870c599f000850ba
+patword 0x0156 0x870c599f000e50ba
+patword 0x0157 0x870c599f000850ba
+patword 0x0158 0x870c599f000e50ba
+patword 0x0159 0x870c599f000850ba
+patword 0x015a 0x870c599f000e50ba
+patword 0x015b 0x870c599f000850ba
+patword 0x015c 0x870c599f000e50ba
+patword 0x015d 0x870c599f000850ba
+patword 0x015e 0x870c599f000e50ba
+patword 0x015f 0x870c599f000850ba
+patword 0x0160 0x870c599f000e50ba
+patword 0x0161 0x870c599f000850ba
+patword 0x0162 0x870c599f000e50ba
+patword 0x0163 0x870c599f000850ba
+patword 0x0164 0x870c599f000e50ba
+patword 0x0165 0x870c599f000850ba
+patword 0x0166 0x870c599f000e50ba
+patword 0x0167 0x870c599f000850ba
+patword 0x0168 0x870c599f000e50ba
+patword 0x0169 0x870c599f000850ba
+patword 0x016a 0x870c599f000e50ba
+patword 0x016b 0x870c599f000850ba
+patword 0x016c 0x070c599f000850ba
+patword 0x016d 0x070c599f000850ba
+patword 0x016e 0x000c599f000850ba
+patword 0x016f 0x000c599f000850ba
+patword 0x0170 0x0008599f200e503a
+patword 0x0171 0x0008599f0008503a
+patword 0x0172 0x0008599f200e503a
+patword 0x0173 0x0008599f0008503a
+patword 0x0174 0x0008599f0008503a
+patword 0x0175 0x0008599f0008503a
+patword 0x0176 0x0008599f0008503a
+patword 0x0177 0x0008599f0008503a
+patword 0x0178 0x0008599f0008503a
+patword 0x0179 0x0008599f0008503a
+patword 0x017a 0x0008599f0008503a
+patword 0x017b 0x0008599f0008503a
+patword 0x017c 0x0008599f0008503a
+patword 0x017d 0x0008599f0008503a
+patword 0x017e 0x0008599f0008503a
+patword 0x017f 0x0008599f0008503a
+patword 0x0180 0x0008599f0008503a
+patword 0x0181 0x0008599f0008503a
+patword 0x0182 0x0008599f0008503a
+patword 0x0183 0x0008599f0008503a
+patword 0x0184 0x0008599f0008503a
+patword 0x0185 0x0008599f0008503a
+patword 0x0186 0x0008599f0008503a
+patword 0x0187 0x0008599f0008503a
+patword 0x0188 0x0008599f0008503a
+patword 0x0189 0x0008599f0008503a
+patword 0x018a 0x0008599f0008503a
+patword 0x018b 0x0008599f0008503a
+patword 0x018c 0x0008599f0008503a
+patword 0x018d 0x0008599f0008503a
+patioctrl 0x8f0effff6dbffdbf
+patlimits 0x0000 0x018c
+patloop0 0x013a 0x016b
+patnloop0 0x199
+patloop1 0x0400 0x0400
+patnloop1 0
+patloop2 0x0400 0x0400
+patnloop2 0
+patwait0 0x00aa
+patwaittime0 10000
+patwait1 0x0400
+patwaittime1 0
+patwait2 0x0400
+patwaittime2 0

 # dacs
 dac 6 800
--- a/examples/virtual_eiger_1_half_module.config
+++ b/examples/virtual_eiger_1_half_module.config
@ -1,13 +1,13 @@
 # detector hostname
 hostname localhost:1900

+# receiver hostname
+rx_hostname mpc1922:2000
+
 # udp destination ports
 udp_dstport 50000
 udp_dstport2 50001

-# receiver hostname
-rx_hostname mpc1922:2000
-
 # udp destination ip from rx_hostname
 udp_dstip auto

--- a/examples/virtual_eiger_2_half_modules.config
+++ b/examples/virtual_eiger_2_half_modules.config
@ -1,15 +1,15 @@
 # detector hostname
 hostname localhost:1900+localhost:1902+

+# receiver hostname
+rx_hostname mpc1922:2000+mpc1922:2001+
+
 # udp destination ports
 0:udp_dstport 50000
 0:udp_dstport2 50001
 1:udp_dstport 50002
 1:udp_dstport2 50003

-# receiver hostname
-rx_hostname mpc1922:2000+mpc1922:2001+
-
 # udp destination ip from rx_hostname
 udp_dstip auto

--- a/examples/virtual_gotthard.config
+++ b/examples/virtual_gotthard.config
@ -1,18 +1,18 @@
 # detector hostname
 hostname localhost:1904

-# udp destination ports
-udp_dstport 50004
-
-# udp source ip (same subnet as udp_dstip)
-udp_srcip 192.168.1.100
-
 # receiver hostname
 rx_hostname mpc1922:2004

+# udp destination ports
+udp_dstport 50004
+
 # udp destination ip from rx_hostname
 udp_dstip auto

+# udp source ip (same subnet as udp_dstip)
+udp_srcip 192.168.1.100
+
 # output file directory
 fpath /tmp

--- a/examples/virtual_gotthard2.config
+++ b/examples/virtual_gotthard2.config
@ -1,12 +1,24 @@
 # detector hostname
 hostname localhost:1914

+# receiver hostname
+rx_hostname mpc1922:2014
+
 # udp destination ports
 udp_dstport 50014

+# udp destination ip from rx_hostname
+udp_dstip auto
+
 # udp source ip (same subnet as udp_dstip)
 udp_srcip 192.168.1.100

+# output file directory
+fpath /tmp
+
+# disable file writing
+fwrite 0
+
 # enable 2nd interface for veto debugging
 # udp destination port for veto
 udp_dstport2 50015
@ -15,18 +27,6 @@ udp_dstip2 auto
 # udp source ip (same subnet as udp_dstip)
 udp_srcip2 192.168.1.100

-# receiver hostname
-rx_hostname mpc1922:2014
-
-# udp destination ip from rx_hostname
-udp_dstip auto
-
-# output file directory
-fpath /tmp
-
-# disable file writing
-fwrite 0
-
 # to enable 2nd interface for veto debugging
 numinterfaces 2

--- a/examples/virtual_jungfrau.config
+++ b/examples/virtual_jungfrau.config
@ -1,21 +1,21 @@
 # detector hostname
 hostname localhost:1906

+# receiver hostname
+rx_hostname mpc1922:2006
+
 # udp destination ports
 udp_dstport 50006
 udp_dstport2 50007

-# udp source ip (same subnet as udp_dstip)
-udp_srcip 192.168.1.100
-udp_srcip2 192.168.1.100
-
-# receiver hostname
-rx_hostname mpc1922:2006
-
 # udp destination ip from rx_hostname
 udp_dstip auto
 udp_dstip2 auto

+# udp source ip (same subnet as udp_dstip)
+udp_srcip 192.168.1.100
+udp_srcip2 192.168.1.100
+
 # output file directory
 fpath /tmp

--- a/examples/virtual_jungfrau_4.config
+++ b/examples/virtual_jungfrau_4.config
@ -4,6 +4,13 @@ detsize 2048 1024
 # detector hostname
 virtual 4 1952

+# receiver hostname and tcpports
+0:rx_tcpport 1970
+1:rx_tcpport 1971
+2:rx_tcpport 1972
+3:rx_tcpport 1973
+rx_hostname mpc1922
+
 # udp destination ports
 0:udp_dstport2 50001
 0:udp_dstport2 50002
@ -14,21 +21,14 @@ virtual 4 1952
 3:udp_dstport 50007
 3:udp_dstport2 50008

-# udp source ip (same subnet as udp_dstip)
-udp_srcip 192.168.1.100
-udp_srcip2 192.168.1.100
-
-# receiver hostname and tcpports
-0:rx_tcpport 1970
-1:rx_tcpport 1971
-2:rx_tcpport 1972
-3:rx_tcpport 1973
-rx_hostname mpc1922
-
 # udp destination ip from rx_hostname
 udp_dstip auto
 udp_dstip2 auto

+# udp source ip (same subnet as udp_dstip)
+udp_srcip 192.168.1.100
+udp_srcip2 192.168.1.100
+
 # transmission delay frame
 0:txndelay_frame 0
 1:txndelay_frame 1
--- a/examples/virtual_moench.config
+++ b/examples/virtual_moench.config
@ -1,18 +1,18 @@
 # detector hostname
 hostname localhost:1908

-# udp destination ports
-udp_dstport 50008
-
-# udp source ip (same subnet as udp_dstip)
-udp_srcip 192.168.1.100
-
 # receiver hostname
 rx_hostname mpc1922:2008

+# udp destination ports
+udp_dstport 50008
+
 # udp destination ip from rx_hostname
 udp_dstip auto

+# udp source ip (same subnet as udp_dstip)
+udp_srcip 192.168.1.100
+
 # output file directory
 fpath /tmp

--- a/examples/virtual_mythen3.config
+++ b/examples/virtual_mythen3.config
@ -1,18 +1,18 @@
 # detector hostname
 hostname localhost:1912

-# udp destination ports
-udp_dstport 50012
-
-# udp source ip (same subnet as udp_dstip)
-udp_srcip 192.168.1.100
-
 # receiver hostname
 rx_hostname mpc1922:2012

+# udp destination ports
+udp_dstport 50012
+
 # udp destination ip from rx_hostname
 udp_dstip auto

+# udp source ip (same subnet as udp_dstip)
+udp_srcip 192.168.1.100
+
 # output file directory
 fpath /tmp

--- a/genVersionHeader.sh
+++ b/genVersionHeader.sh
@ -0,0 +1,27 @@
+# SPDX-License-Identifier: LGPL-3.0-or-other
+# Copyright (C) 2021 Contributors to the SLS Detector Package
+#####! /bin/awk -f
+
+
+if [ $# -lt 3 ] 
+then
+    echo "wrong usage"
+    exit -1
+fi
+
+
+fin=$1
+ftmp=$2
+fout=$3
+
+
+#dat=echo "date '+%Y%m%d'"
+
+echo "Updating $fout"
+#echo "in: $fin tmp: $ftmp out: $fout"
+
+#awk 'NR==FNR {if ($3=="Date:") {l[FNR]=$4; gsub("-","",l[FNR]);} else { if (match($0,"Rev")) {l[FNR]=$(NF);} else {l[FNR]="\""$(NF)"\"";};};next} {$0=$1" "$2" "l[FNR]}1' $fin $ftmp > $fout
+
+awk 'BEGIN {l[0]=0; "date +%Y%m%d" | getline l[1]; l[2]="\"/\""; l[3]="\"nobody\""; l[3]="\"nobody\""; l[4]="\"0000-0000-0000\"";} \
+NR==FNR {if (match($0,"Rev")) {l[0]="0x"$(NF);} else if (match($0,"Date")) {l[1]="0x"$4; gsub("-","",l[1]);} else if (match($0,"URL")) {l[2]="\""$(NF)"\"";} else if (match($0,"Author")) {l[3]="\""$(NF)"\"";} else if (match($0,"UUID")) {l[4]="\""$(NF)"\"";} else if (match($0,"Branch")) {l[5]="\""$(NF)"\"";};next;} 
+{if (match($2,"REV")) {$0=$1" "$2" "l[0];} else if (match($2,"DATE")) {$0=$1" "$2" "l[1];} else if (match($2,"URL")) {$0=$1" "$2" "l[2];} else if (match($2,"AUTH")) {$0=$1" "$2" "l[3];} else if (match($2,"UUID")) {$0=$1" "$2" "l[4];} else if (match($2,"BRANCH")) {$0=$1" "$2" "l[5];}}1' $fin $ftmp > $fout
--- a/integrationTests/test-eigerIntegration.cpp
+++ b/integrationTests/test-eigerIntegration.cpp
@ -6,8 +6,6 @@
 #include "tests/globals.h"
 #include <iostream>

-namespace sls {
-
 class MultiDetectorFixture {
  protected:
    DetectorImpl d;
@ -138,7 +136,7 @@ TEST_CASE_METHOD(MultiDetectorFixture, "Get ID", "[.eigerintegration][cli]") {
    std::string hn = test::hostname;
    hn.erase(std::remove(begin(hn), end(hn), 'b'), end(hn));
    hn.erase(std::remove(begin(hn), end(hn), 'e'), end(hn));
-    auto hostnames = split(hn, '+');
+    auto hostnames = sls::split(hn, '+');
    CHECK(hostnames.size() == d.getNumberOfDetectors());
    for (int i = 0; i != d.getNumberOfDetectors(); ++i) {
        CHECK(d.getId(defs::DETECTOR_SERIAL_NUMBER, 0) ==
@ -200,5 +198,3 @@ TEST_CASE_METHOD(MultiDetectorFixture, "rate correction",
    d.setRateCorrection(200);
    CHECK(d.getRateCorrection() == 200);
 }
-
-} // namespace sls
--- a/integrationTests/test-integrationDectector.cpp
+++ b/integrationTests/test-integrationDectector.cpp
@ -24,8 +24,6 @@
 // extern std::string detector_type;
 // extern dt type;

-namespace sls {
-
 TEST_CASE("Single detector no receiver", "[.integration][.single]") {
    auto t = Module::getTypeFromDetector(test::hostname);
    CHECK(t == test::type);
@ -50,8 +48,8 @@ TEST_CASE("Set control port then create a new object with this control port",
    Is this the best way to initialize the detectors
    Using braces to make the object go out of scope
    */
-    int old_cport = DEFAULT_TCP_CNTRL_PORTNO;
-    int old_sport = DEFAULT_TCP_STOP_PORTNO;
+    int old_cport = DEFAULT_PORTNO;
+    int old_sport = DEFAULT_PORTNO + 1;
    int new_cport = 1993;
    int new_sport = 2000;
    {
@ -79,7 +77,7 @@ TEST_CASE("Set control port then create a new object with this control port",

    Module d(test::type);
    d.setHostname(test::hostname);
-    CHECK(d.getStopPort() == DEFAULT_TCP_STOP_PORTNO);
+    CHECK(d.getStopPort() == DEFAULT_PORTNO + 1);
    d.freeSharedMemory();
 }

@ -285,14 +283,14 @@ TEST_CASE(
    CHECK(m.getRateCorrection() == ratecorr);

    // ratecorr fail with dr 4 or 8
-    CHECK_THROWS_AS(m.setDynamicRange(8), RuntimeError);
+    CHECK_THROWS_AS(m.setDynamicRange(8), sls::RuntimeError);
    CHECK(m.getRateCorrection() == 0);
    m.setDynamicRange(16);
    m.setDynamicRange(16);
    m.setRateCorrection(ratecorr);
    m.setDynamicRange(16);
    m.setRateCorrection(ratecorr);
-    CHECK_THROWS_AS(m.setDynamicRange(4), RuntimeError);
+    CHECK_THROWS_AS(m.setDynamicRange(4), sls::RuntimeError);
    CHECK(m.getRateCorrection() == 0);
 }

@ -331,11 +329,11 @@ TEST_CASE("Chiptestboard Loading Patterns", "[.ctbintegration]") {
    m.setPatternWord(addr, word);
    CHECK(m.setPatternWord(addr, -1) == word);
    addr = MAX_ADDR;
-    CHECK_THROWS_AS(m.setPatternWord(addr, word), RuntimeError);
+    CHECK_THROWS_AS(m.setPatternWord(addr, word), sls::RuntimeError);
    CHECK_THROWS_WITH(m.setPatternWord(addr, word),
                      Catch::Matchers::Contains("be between 0 and"));
    addr = -1;
-    CHECK_THROWS_AS(m.setPatternWord(addr, word), RuntimeError);
+    CHECK_THROWS_AS(m.setPatternWord(addr, word), sls::RuntimeError);
    CHECK_THROWS_WITH(m.setPatternWord(addr, word),
                      Catch::Matchers::Contains("be between 0 and"));

@ -410,7 +408,7 @@ TEST_CASE("Chiptestboard Dbit offset, list, sampling, advinvert",
    CHECK(m.getReceiverDbitList().size() == 10);

    list.push_back(64);
-    CHECK_THROWS_AS(m.setReceiverDbitList(list), RuntimeError);
+    CHECK_THROWS_AS(m.setReceiverDbitList(list), sls::RuntimeError);
    CHECK_THROWS_WITH(m.setReceiverDbitList(list),
                      Catch::Matchers::Contains("be between 0 and 63"));

@ -478,7 +476,7 @@ TEST_CASE("Eiger or Jungfrau nextframenumber",
    CHECK(m.acquire() == slsDetectorDefs::OK);
    CHECK(m.getReceiverCurrentFrameIndex() == val);

-    CHECK_THROWS_AS(m.setNextFrameNumber(0), RuntimeError);
+    CHECK_THROWS_AS(m.setNextFrameNumber(0), sls::RuntimeError);

    if (m.getDetectorTypeAsString() == "Eiger") {
        val = 281474976710655;
@ -513,10 +511,8 @@ TEST_CASE("Eiger partialread", "[.eigerintegration][partialread]") {
    m.setDynamicRange(8);
    m.setPartialReadout(256);
    CHECK(m.getPartialReadout() == 256);
-    CHECK_THROWS_AS(m.setPartialReadout(1), RuntimeError);
+    CHECK_THROWS_AS(m.setPartialReadout(1), sls::RuntimeError);
    CHECK(m.getPartialReadout() == 256);
-    CHECK_THROWS_AS(m.setPartialReadout(0), RuntimeError);
+    CHECK_THROWS_AS(m.setPartialReadout(0), sls::RuntimeError);
    m.setPartialReadout(256);
-}
-
-} // namespace sls
+}
--- a/integrationTests/test-integrationMulti.cpp
+++ b/integrationTests/test-integrationMulti.cpp
@ -6,12 +6,10 @@
 #include "tests/globals.h"
 #include <iostream>

-namespace sls {
-
 using namespace Catch::literals;

 TEST_CASE("Initialize a multi detector", "[.integration][.multi]") {
-    auto hostnames = split(test::hostname, '+');
+    auto hostnames = sls::split(test::hostname, '+');

    DetectorImpl d(0, true, true);
    d.setHostname(test::hostname.c_str());
@ -104,5 +102,3 @@ TEST_CASE("Set and read timers", "[.integration][.multi]") {

    d.freeSharedMemory();
 }
-
-} // namespace sls
--- a/libs/pybind/CMakeLists.txt
+++ b/libs/pybind/CMakeLists.txt
@ -1,299 +0,0 @@
-# CMakeLists.txt -- Build system for the pybind11 modules
-#
-# Copyright (c) 2015 Wenzel Jakob <wenzel@inf.ethz.ch>
-#
-# All rights reserved. Use of this source code is governed by a
-# BSD-style license that can be found in the LICENSE file.
-
-cmake_minimum_required(VERSION 3.4)
-
-# The `cmake_minimum_required(VERSION 3.4...3.22)` syntax does not work with
-# some versions of VS that have a patched CMake 3.11. This forces us to emulate
-# the behavior using the following workaround:
-if(${CMAKE_VERSION} VERSION_LESS 3.22)
-  cmake_policy(VERSION ${CMAKE_MAJOR_VERSION}.${CMAKE_MINOR_VERSION})
-else()
-  cmake_policy(VERSION 3.22)
-endif()
-
-# Avoid infinite recursion if tests include this as a subdirectory
-if(DEFINED PYBIND11_MASTER_PROJECT)
-  return()
-endif()
-
-# Extract project version from source
-file(STRINGS "${CMAKE_CURRENT_SOURCE_DIR}/include/pybind11/detail/common.h"
-     pybind11_version_defines REGEX "#define PYBIND11_VERSION_(MAJOR|MINOR|PATCH) ")
-
-foreach(ver ${pybind11_version_defines})
-  if(ver MATCHES [[#define PYBIND11_VERSION_(MAJOR|MINOR|PATCH) +([^ ]+)$]])
-    set(PYBIND11_VERSION_${CMAKE_MATCH_1} "${CMAKE_MATCH_2}")
-  endif()
-endforeach()
-
-if(PYBIND11_VERSION_PATCH MATCHES [[\.([a-zA-Z0-9]+)$]])
-  set(pybind11_VERSION_TYPE "${CMAKE_MATCH_1}")
-endif()
-string(REGEX MATCH "^[0-9]+" PYBIND11_VERSION_PATCH "${PYBIND11_VERSION_PATCH}")
-
-project(
-  pybind11
-  LANGUAGES CXX
-  VERSION "${PYBIND11_VERSION_MAJOR}.${PYBIND11_VERSION_MINOR}.${PYBIND11_VERSION_PATCH}")
-
-# Standard includes
-include(GNUInstallDirs)
-include(CMakePackageConfigHelpers)
-include(CMakeDependentOption)
-
-if(NOT pybind11_FIND_QUIETLY)
-  message(STATUS "pybind11 v${pybind11_VERSION} ${pybind11_VERSION_TYPE}")
-endif()
-
-# Check if pybind11 is being used directly or via add_subdirectory
-if(CMAKE_SOURCE_DIR STREQUAL PROJECT_SOURCE_DIR)
-  ### Warn if not an out-of-source builds
-  if(CMAKE_CURRENT_SOURCE_DIR STREQUAL CMAKE_CURRENT_BINARY_DIR)
-    set(lines
-        "You are building in-place. If that is not what you intended to "
-        "do, you can clean the source directory with:\n"
-        "rm -r CMakeCache.txt CMakeFiles/ cmake_uninstall.cmake pybind11Config.cmake "
-        "pybind11ConfigVersion.cmake tests/CMakeFiles/\n")
-    message(AUTHOR_WARNING ${lines})
-  endif()
-
-  set(PYBIND11_MASTER_PROJECT ON)
-
-  if(OSX AND CMAKE_VERSION VERSION_LESS 3.7)
-    # Bug in macOS CMake < 3.7 is unable to download catch
-    message(WARNING "CMAKE 3.7+ needed on macOS to download catch, and newer HIGHLY recommended")
-  elseif(WINDOWS AND CMAKE_VERSION VERSION_LESS 3.8)
-    # Only tested with 3.8+ in CI.
-    message(WARNING "CMAKE 3.8+ tested on Windows, previous versions untested")
-  endif()
-
-  message(STATUS "CMake ${CMAKE_VERSION}")
-
-  if(CMAKE_CXX_STANDARD)
-    set(CMAKE_CXX_EXTENSIONS OFF)
-    set(CMAKE_CXX_STANDARD_REQUIRED ON)
-  endif()
-
-  set(pybind11_system "")
-
-  set_property(GLOBAL PROPERTY USE_FOLDERS ON)
-else()
-  set(PYBIND11_MASTER_PROJECT OFF)
-  set(pybind11_system SYSTEM)
-endif()
-
-# Options
-option(PYBIND11_INSTALL "Install pybind11 header files?" ${PYBIND11_MASTER_PROJECT})
-option(PYBIND11_TEST "Build pybind11 test suite?" ${PYBIND11_MASTER_PROJECT})
-option(PYBIND11_NOPYTHON "Disable search for Python" OFF)
-set(PYBIND11_INTERNALS_VERSION
-    ""
-    CACHE STRING "Override the ABI version, may be used to enable the unstable ABI.")
-
-cmake_dependent_option(
-  USE_PYTHON_INCLUDE_DIR
-  "Install pybind11 headers in Python include directory instead of default installation prefix"
-  OFF "PYBIND11_INSTALL" OFF)
-
-cmake_dependent_option(PYBIND11_FINDPYTHON "Force new FindPython" OFF
-                       "NOT CMAKE_VERSION VERSION_LESS 3.12" OFF)
-
-# NB: when adding a header don't forget to also add it to setup.py
-set(PYBIND11_HEADERS
-    include/pybind11/detail/class.h
-    include/pybind11/detail/common.h
-    include/pybind11/detail/descr.h
-    include/pybind11/detail/init.h
-    include/pybind11/detail/internals.h
-    include/pybind11/detail/type_caster_base.h
-    include/pybind11/detail/typeid.h
-    include/pybind11/attr.h
-    include/pybind11/buffer_info.h
-    include/pybind11/cast.h
-    include/pybind11/chrono.h
-    include/pybind11/common.h
-    include/pybind11/complex.h
-    include/pybind11/options.h
-    include/pybind11/eigen.h
-    include/pybind11/embed.h
-    include/pybind11/eval.h
-    include/pybind11/gil.h
-    include/pybind11/iostream.h
-    include/pybind11/functional.h
-    include/pybind11/numpy.h
-    include/pybind11/operators.h
-    include/pybind11/pybind11.h
-    include/pybind11/pytypes.h
-    include/pybind11/stl.h
-    include/pybind11/stl_bind.h
-    include/pybind11/stl/filesystem.h)
-
-# Compare with grep and warn if mismatched
-if(PYBIND11_MASTER_PROJECT AND NOT CMAKE_VERSION VERSION_LESS 3.12)
-  file(
-    GLOB_RECURSE _pybind11_header_check
-    LIST_DIRECTORIES false
-    RELATIVE "${CMAKE_CURRENT_SOURCE_DIR}"
-    CONFIGURE_DEPENDS "include/pybind11/*.h")
-  set(_pybind11_here_only ${PYBIND11_HEADERS})
-  set(_pybind11_disk_only ${_pybind11_header_check})
-  list(REMOVE_ITEM _pybind11_here_only ${_pybind11_header_check})
-  list(REMOVE_ITEM _pybind11_disk_only ${PYBIND11_HEADERS})
-  if(_pybind11_here_only)
-    message(AUTHOR_WARNING "PYBIND11_HEADERS has extra files:" ${_pybind11_here_only})
-  endif()
-  if(_pybind11_disk_only)
-    message(AUTHOR_WARNING "PYBIND11_HEADERS is missing files:" ${_pybind11_disk_only})
-  endif()
-endif()
-
-# CMake 3.12 added list(TRANSFORM <list> PREPEND
-# But we can't use it yet
-string(REPLACE "include/" "${CMAKE_CURRENT_SOURCE_DIR}/include/" PYBIND11_HEADERS
-               "${PYBIND11_HEADERS}")
-
-# Cache variable so this can be used in parent projects
-set(pybind11_INCLUDE_DIR
-    "${CMAKE_CURRENT_LIST_DIR}/include"
-    CACHE INTERNAL "Directory where pybind11 headers are located")
-
-# Backward compatible variable for add_subdirectory mode
-if(NOT PYBIND11_MASTER_PROJECT)
-  set(PYBIND11_INCLUDE_DIR
-      "${pybind11_INCLUDE_DIR}"
-      CACHE INTERNAL "")
-endif()
-
-# Note: when creating targets, you cannot use if statements at configure time -
-# you need generator expressions, because those will be placed in the target file.
-# You can also place ifs *in* the Config.in, but not here.
-
-# This section builds targets, but does *not* touch Python
-# Non-IMPORT targets cannot be defined twice
-if(NOT TARGET pybind11_headers)
-  # Build the headers-only target (no Python included):
-  # (long name used here to keep this from clashing in subdirectory mode)
-  add_library(pybind11_headers INTERFACE)
-  add_library(pybind11::pybind11_headers ALIAS pybind11_headers) # to match exported target
-  add_library(pybind11::headers ALIAS pybind11_headers) # easier to use/remember
-
-  target_include_directories(
-    pybind11_headers ${pybind11_system} INTERFACE $<BUILD_INTERFACE:${pybind11_INCLUDE_DIR}>
-                                                  $<INSTALL_INTERFACE:${CMAKE_INSTALL_INCLUDEDIR}>)
-
-  target_compile_features(pybind11_headers INTERFACE cxx_inheriting_constructors cxx_user_literals
-                                                     cxx_right_angle_brackets)
-  if(NOT "${PYBIND11_INTERNALS_VERSION}" STREQUAL "")
-    target_compile_definitions(
-      pybind11_headers INTERFACE "PYBIND11_INTERNALS_VERSION=${PYBIND11_INTERNALS_VERSION}")
-  endif()
-else()
-  # It is invalid to install a target twice, too.
-  set(PYBIND11_INSTALL OFF)
-endif()
-
-include("${CMAKE_CURRENT_SOURCE_DIR}/tools/pybind11Common.cmake")
-
-# Relative directory setting
-if(USE_PYTHON_INCLUDE_DIR AND DEFINED Python_INCLUDE_DIRS)
-  file(RELATIVE_PATH CMAKE_INSTALL_INCLUDEDIR ${CMAKE_INSTALL_PREFIX} ${Python_INCLUDE_DIRS})
-elseif(USE_PYTHON_INCLUDE_DIR AND DEFINED PYTHON_INCLUDE_DIR)
-  file(RELATIVE_PATH CMAKE_INSTALL_INCLUDEDIR ${CMAKE_INSTALL_PREFIX} ${PYTHON_INCLUDE_DIRS})
-endif()
-
-if(PYBIND11_INSTALL)
-  install(DIRECTORY ${pybind11_INCLUDE_DIR}/pybind11 DESTINATION ${CMAKE_INSTALL_INCLUDEDIR})
-  set(PYBIND11_CMAKECONFIG_INSTALL_DIR
-      "${CMAKE_INSTALL_DATAROOTDIR}/cmake/${PROJECT_NAME}"
-      CACHE STRING "install path for pybind11Config.cmake")
-
-  if(IS_ABSOLUTE "${CMAKE_INSTALL_INCLUDEDIR}")
-    set(pybind11_INCLUDEDIR "${CMAKE_INSTALL_FULL_INCLUDEDIR}")
-  else()
-    set(pybind11_INCLUDEDIR "\$\{PACKAGE_PREFIX_DIR\}/${CMAKE_INSTALL_INCLUDEDIR}")
-  endif()
-
-  configure_package_config_file(
-    tools/${PROJECT_NAME}Config.cmake.in "${CMAKE_CURRENT_BINARY_DIR}/${PROJECT_NAME}Config.cmake"
-    INSTALL_DESTINATION ${PYBIND11_CMAKECONFIG_INSTALL_DIR})
-
-  if(CMAKE_VERSION VERSION_LESS 3.14)
-    # Remove CMAKE_SIZEOF_VOID_P from ConfigVersion.cmake since the library does
-    # not depend on architecture specific settings or libraries.
-    set(_PYBIND11_CMAKE_SIZEOF_VOID_P ${CMAKE_SIZEOF_VOID_P})
-    unset(CMAKE_SIZEOF_VOID_P)
-
-    write_basic_package_version_file(
-      ${CMAKE_CURRENT_BINARY_DIR}/${PROJECT_NAME}ConfigVersion.cmake
-      VERSION ${PROJECT_VERSION}
-      COMPATIBILITY AnyNewerVersion)
-
-    set(CMAKE_SIZEOF_VOID_P ${_PYBIND11_CMAKE_SIZEOF_VOID_P})
-  else()
-    # CMake 3.14+ natively supports header-only libraries
-    write_basic_package_version_file(
-      ${CMAKE_CURRENT_BINARY_DIR}/${PROJECT_NAME}ConfigVersion.cmake
-      VERSION ${PROJECT_VERSION}
-      COMPATIBILITY AnyNewerVersion ARCH_INDEPENDENT)
-  endif()
-
-  install(
-    FILES ${CMAKE_CURRENT_BINARY_DIR}/${PROJECT_NAME}Config.cmake
-          ${CMAKE_CURRENT_BINARY_DIR}/${PROJECT_NAME}ConfigVersion.cmake
-          tools/FindPythonLibsNew.cmake
-          tools/pybind11Common.cmake
-          tools/pybind11Tools.cmake
-          tools/pybind11NewTools.cmake
-    DESTINATION ${PYBIND11_CMAKECONFIG_INSTALL_DIR})
-
-  if(NOT PYBIND11_EXPORT_NAME)
-    set(PYBIND11_EXPORT_NAME "${PROJECT_NAME}Targets")
-  endif()
-
-  install(TARGETS pybind11_headers EXPORT "${PYBIND11_EXPORT_NAME}")
-
-  install(
-    EXPORT "${PYBIND11_EXPORT_NAME}"
-    NAMESPACE "pybind11::"
-    DESTINATION ${PYBIND11_CMAKECONFIG_INSTALL_DIR})
-
-  # Uninstall target
-  if(PYBIND11_MASTER_PROJECT)
-    configure_file("${CMAKE_CURRENT_SOURCE_DIR}/tools/cmake_uninstall.cmake.in"
-                   "${CMAKE_CURRENT_BINARY_DIR}/cmake_uninstall.cmake" IMMEDIATE @ONLY)
-
-    add_custom_target(uninstall COMMAND ${CMAKE_COMMAND} -P
-                                        ${CMAKE_CURRENT_BINARY_DIR}/cmake_uninstall.cmake)
-  endif()
-endif()
-
-# BUILD_TESTING takes priority, but only if this is the master project
-if(PYBIND11_MASTER_PROJECT AND DEFINED BUILD_TESTING)
-  if(BUILD_TESTING)
-    if(_pybind11_nopython)
-      message(FATAL_ERROR "Cannot activate tests in NOPYTHON mode")
-    else()
-      add_subdirectory(tests)
-    endif()
-  endif()
-else()
-  if(PYBIND11_TEST)
-    if(_pybind11_nopython)
-      message(FATAL_ERROR "Cannot activate tests in NOPYTHON mode")
-    else()
-      add_subdirectory(tests)
-    endif()
-  endif()
-endif()
-
-# Better symmetry with find_package(pybind11 CONFIG) mode.
-if(NOT PYBIND11_MASTER_PROJECT)
-  set(pybind11_FOUND
-      TRUE
-      CACHE INTERNAL "True if pybind11 and all required components found on the system")
-endif()
--- a/libs/pybind/LICENSE
+++ b/libs/pybind/LICENSE
@ -1,29 +0,0 @@
-Copyright (c) 2016 Wenzel Jakob <wenzel.jakob@epfl.ch>, All rights reserved.
-
-Redistribution and use in source and binary forms, with or without
-modification, are permitted provided that the following conditions are met:
-
-1. Redistributions of source code must retain the above copyright notice, this
-   list of conditions and the following disclaimer.
-
-2. Redistributions in binary form must reproduce the above copyright notice,
-   this list of conditions and the following disclaimer in the documentation
-   and/or other materials provided with the distribution.
-
-3. Neither the name of the copyright holder nor the names of its contributors
-   may be used to endorse or promote products derived from this software
-   without specific prior written permission.
-
-THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND
-ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
-WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
-DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE
-FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
-DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
-SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
-CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
-OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
-OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
-
-Please also refer to the file .github/CONTRIBUTING.md, which clarifies licensing of
-external contributions to this project including patches, pull requests, etc.
--- a/libs/pybind/MANIFEST.in
+++ b/libs/pybind/MANIFEST.in
@ -1,5 +0,0 @@
-recursive-include pybind11/include/pybind11 *.h
-recursive-include pybind11 *.py
-recursive-include pybind11 py.typed
-include pybind11/share/cmake/pybind11/*.cmake
-include LICENSE README.rst pyproject.toml setup.py setup.cfg
--- a/libs/pybind/README.rst
+++ b/libs/pybind/README.rst
@ -1,180 +0,0 @@
-.. figure:: https://github.com/pybind/pybind11/raw/master/docs/pybind11-logo.png
-   :alt: pybind11 logo
-
-**pybind11 — Seamless operability between C++11 and Python**
-
-|Latest Documentation Status| |Stable Documentation Status| |Gitter chat| |GitHub Discussions| |CI| |Build status|
-
-|Repology| |PyPI package| |Conda-forge| |Python Versions|
-
-`Setuptools example <https://github.com/pybind/python_example>`_
-• `Scikit-build example <https://github.com/pybind/scikit_build_example>`_
-• `CMake example <https://github.com/pybind/cmake_example>`_
-
-.. start
-
-
-**pybind11** is a lightweight header-only library that exposes C++ types
-in Python and vice versa, mainly to create Python bindings of existing
-C++ code. Its goals and syntax are similar to the excellent
-`Boost.Python <http://www.boost.org/doc/libs/1_58_0/libs/python/doc/>`_
-library by David Abrahams: to minimize boilerplate code in traditional
-extension modules by inferring type information using compile-time
-introspection.
-
-The main issue with Boost.Python—and the reason for creating such a
-similar project—is Boost. Boost is an enormously large and complex suite
-of utility libraries that works with almost every C++ compiler in
-existence. This compatibility has its cost: arcane template tricks and
-workarounds are necessary to support the oldest and buggiest of compiler
-specimens. Now that C++11-compatible compilers are widely available,
-this heavy machinery has become an excessively large and unnecessary
-dependency.
-
-Think of this library as a tiny self-contained version of Boost.Python
-with everything stripped away that isn't relevant for binding
-generation. Without comments, the core header files only require ~4K
-lines of code and depend on Python (3.6+, or PyPy) and the C++
-standard library. This compact implementation was possible thanks to
-some of the new C++11 language features (specifically: tuples, lambda
-functions and variadic templates). Since its creation, this library has
-grown beyond Boost.Python in many ways, leading to dramatically simpler
-binding code in many common situations.
-
-Tutorial and reference documentation is provided at
-`pybind11.readthedocs.io <https://pybind11.readthedocs.io/en/latest>`_.
-A PDF version of the manual is available
-`here <https://pybind11.readthedocs.io/_/downloads/en/latest/pdf/>`_.
-And the source code is always available at
-`github.com/pybind/pybind11 <https://github.com/pybind/pybind11>`_.
-
-
-Core features
-------------
-
-
-pybind11 can map the following core C++ features to Python:
-
- Functions accepting and returning custom data structures per value,
-  reference, or pointer
- Instance methods and static methods
- Overloaded functions
- Instance attributes and static attributes
- Arbitrary exception types
- Enumerations
- Callbacks
- Iterators and ranges
- Custom operators
- Single and multiple inheritance
- STL data structures
- Smart pointers with reference counting like ``std::shared_ptr``
- Internal references with correct reference counting
- C++ classes with virtual (and pure virtual) methods can be extended
-  in Python
-
-Goodies
-------
-
-In addition to the core functionality, pybind11 provides some extra
-goodies:
-
- Python 3.6+, and PyPy3 7.3 are supported with an implementation-agnostic
-  interface (pybind11 2.9 was the last version to support Python 2 and 3.5).
-
- It is possible to bind C++11 lambda functions with captured
-  variables. The lambda capture data is stored inside the resulting
-  Python function object.
-
- pybind11 uses C++11 move constructors and move assignment operators
-  whenever possible to efficiently transfer custom data types.
-
- It's easy to expose the internal storage of custom data types through
-  Pythons' buffer protocols. This is handy e.g. for fast conversion
-  between C++ matrix classes like Eigen and NumPy without expensive
-  copy operations.
-
- pybind11 can automatically vectorize functions so that they are
-  transparently applied to all entries of one or more NumPy array
-  arguments.
-
- Python's slice-based access and assignment operations can be
-  supported with just a few lines of code.
-
- Everything is contained in just a few header files; there is no need
-  to link against any additional libraries.
-
- Binaries are generally smaller by a factor of at least 2 compared to
-  equivalent bindings generated by Boost.Python. A recent pybind11
-  conversion of PyRosetta, an enormous Boost.Python binding project,
-  `reported <https://graylab.jhu.edu/Sergey/2016.RosettaCon/PyRosetta-4.pdf>`_
-  a binary size reduction of **5.4x** and compile time reduction by
-  **5.8x**.
-
- Function signatures are precomputed at compile time (using
-  ``constexpr``), leading to smaller binaries.
-
- With little extra effort, C++ types can be pickled and unpickled
-  similar to regular Python objects.
-
-Supported compilers
-------------------
-
-1. Clang/LLVM 3.3 or newer (for Apple Xcode's clang, this is 5.0.0 or
-   newer)
-2. GCC 4.8 or newer
-3. Microsoft Visual Studio 2017 or newer
-4. Intel classic C++ compiler 18 or newer (ICC 20.2 tested in CI)
-5. Cygwin/GCC (previously tested on 2.5.1)
-6. NVCC (CUDA 11.0 tested in CI)
-7. NVIDIA PGI (20.9 tested in CI)
-
-About
-----
-
-This project was created by `Wenzel
-Jakob <http://rgl.epfl.ch/people/wjakob>`_. Significant features and/or
-improvements to the code were contributed by Jonas Adler, Lori A. Burns,
-Sylvain Corlay, Eric Cousineau, Aaron Gokaslan, Ralf Grosse-Kunstleve, Trent Houliston, Axel
-Huebl, @hulucc, Yannick Jadoul, Sergey Lyskov Johan Mabille, Tomasz Miąsko,
-Dean Moldovan, Ben Pritchard, Jason Rhinelander, Boris Schäling, Pim
-Schellart, Henry Schreiner, Ivan Smirnov, Boris Staletic, and Patrick Stewart.
-
-We thank Google for a generous financial contribution to the continuous
-integration infrastructure used by this project.
-
-
-Contributing
-~~~~~~~~~~~~
-
-See the `contributing
-guide <https://github.com/pybind/pybind11/blob/master/.github/CONTRIBUTING.md>`_
-for information on building and contributing to pybind11.
-
-License
-~~~~~~~
-
-pybind11 is provided under a BSD-style license that can be found in the
-`LICENSE <https://github.com/pybind/pybind11/blob/master/LICENSE>`_
-file. By using, distributing, or contributing to this project, you agree
-to the terms and conditions of this license.
-
-.. |Latest Documentation Status| image:: https://readthedocs.org/projects/pybind11/badge?version=latest
-   :target: http://pybind11.readthedocs.org/en/latest
-.. |Stable Documentation Status| image:: https://img.shields.io/badge/docs-stable-blue.svg
-   :target: http://pybind11.readthedocs.org/en/stable
-.. |Gitter chat| image:: https://img.shields.io/gitter/room/gitterHQ/gitter.svg
-   :target: https://gitter.im/pybind/Lobby
-.. |CI| image:: https://github.com/pybind/pybind11/workflows/CI/badge.svg
-   :target: https://github.com/pybind/pybind11/actions
-.. |Build status| image:: https://ci.appveyor.com/api/projects/status/riaj54pn4h08xy40?svg=true
-   :target: https://ci.appveyor.com/project/wjakob/pybind11
-.. |PyPI package| image:: https://img.shields.io/pypi/v/pybind11.svg
-   :target: https://pypi.org/project/pybind11/
-.. |Conda-forge| image:: https://img.shields.io/conda/vn/conda-forge/pybind11.svg
-   :target: https://github.com/conda-forge/pybind11-feedstock
-.. |Repology| image:: https://repology.org/badge/latest-versions/python:pybind11.svg
-   :target: https://repology.org/project/python:pybind11/versions
-.. |Python Versions| image:: https://img.shields.io/pypi/pyversions/pybind11.svg
-   :target: https://pypi.org/project/pybind11/
-.. |GitHub Discussions| image:: https://img.shields.io/static/v1?label=Discussions&message=Ask&color=blue&logo=github
-   :target: https://github.com/pybind/pybind11/discussions
--- a/libs/pybind/docs/Doxyfile
+++ b/libs/pybind/docs/Doxyfile
@ -1,21 +0,0 @@
-PROJECT_NAME           = pybind11
-INPUT                  = ../include/pybind11/
-RECURSIVE              = YES
-
-GENERATE_HTML          = NO
-GENERATE_LATEX         = NO
-GENERATE_XML           = YES
-XML_OUTPUT             = .build/doxygenxml
-XML_PROGRAMLISTING     = YES
-
-MACRO_EXPANSION        = YES
-EXPAND_ONLY_PREDEF     = YES
-EXPAND_AS_DEFINED      = PYBIND11_RUNTIME_EXCEPTION
-
-ALIASES                = "rst=\verbatim embed:rst"
-ALIASES               += "endrst=\endverbatim"
-
-QUIET                  = YES
-WARNINGS               = YES
-WARN_IF_UNDOCUMENTED   = NO
-PREDEFINED             = PYBIND11_NOINLINE
--- a/libs/pybind/docs/Makefile
+++ b/libs/pybind/docs/Makefile
@ -1,192 +0,0 @@
-# Makefile for Sphinx documentation
-#
-
-# You can set these variables from the command line.
-SPHINXOPTS    =
-SPHINXBUILD   = sphinx-build
-PAPER         =
-BUILDDIR      = .build
-
-# User-friendly check for sphinx-build
-ifeq ($(shell which $(SPHINXBUILD) >/dev/null 2>&1; echo $$?), 1)
-$(error The '$(SPHINXBUILD)' command was not found. Make sure you have Sphinx installed, then set the SPHINXBUILD environment variable to point to the full path of the '$(SPHINXBUILD)' executable. Alternatively you can add the directory with the executable to your PATH. If you don't have Sphinx installed, grab it from http://sphinx-doc.org/)
-endif
-
-# Internal variables.
-PAPEROPT_a4     = -D latex_paper_size=a4
-PAPEROPT_letter = -D latex_paper_size=letter
-ALLSPHINXOPTS   = -d $(BUILDDIR)/doctrees $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) .
-# the i18n builder cannot share the environment and doctrees with the others
-I18NSPHINXOPTS  = $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) .
-
-.PHONY: help clean html dirhtml singlehtml pickle json htmlhelp qthelp devhelp epub latex latexpdf text man changes linkcheck doctest coverage gettext
-
-help:
-	@echo "Please use \`make <target>' where <target> is one of"
-	@echo "  html       to make standalone HTML files"
-	@echo "  dirhtml    to make HTML files named index.html in directories"
-	@echo "  singlehtml to make a single large HTML file"
-	@echo "  pickle     to make pickle files"
-	@echo "  json       to make JSON files"
-	@echo "  htmlhelp   to make HTML files and a HTML help project"
-	@echo "  qthelp     to make HTML files and a qthelp project"
-	@echo "  applehelp  to make an Apple Help Book"
-	@echo "  devhelp    to make HTML files and a Devhelp project"
-	@echo "  epub       to make an epub"
-	@echo "  latex      to make LaTeX files, you can set PAPER=a4 or PAPER=letter"
-	@echo "  latexpdf   to make LaTeX files and run them through pdflatex"
-	@echo "  latexpdfja to make LaTeX files and run them through platex/dvipdfmx"
-	@echo "  text       to make text files"
-	@echo "  man        to make manual pages"
-	@echo "  texinfo    to make Texinfo files"
-	@echo "  info       to make Texinfo files and run them through makeinfo"
-	@echo "  gettext    to make PO message catalogs"
-	@echo "  changes    to make an overview of all changed/added/deprecated items"
-	@echo "  xml        to make Docutils-native XML files"
-	@echo "  pseudoxml  to make pseudoxml-XML files for display purposes"
-	@echo "  linkcheck  to check all external links for integrity"
-	@echo "  doctest    to run all doctests embedded in the documentation (if enabled)"
-	@echo "  coverage   to run coverage check of the documentation (if enabled)"
-
-clean:
-	rm -rf $(BUILDDIR)/*
-
-html:
-	$(SPHINXBUILD) -b html $(ALLSPHINXOPTS) $(BUILDDIR)/html
-	@echo
-	@echo "Build finished. The HTML pages are in $(BUILDDIR)/html."
-
-dirhtml:
-	$(SPHINXBUILD) -b dirhtml $(ALLSPHINXOPTS) $(BUILDDIR)/dirhtml
-	@echo
-	@echo "Build finished. The HTML pages are in $(BUILDDIR)/dirhtml."
-
-singlehtml:
-	$(SPHINXBUILD) -b singlehtml $(ALLSPHINXOPTS) $(BUILDDIR)/singlehtml
-	@echo
-	@echo "Build finished. The HTML page is in $(BUILDDIR)/singlehtml."
-
-pickle:
-	$(SPHINXBUILD) -b pickle $(ALLSPHINXOPTS) $(BUILDDIR)/pickle
-	@echo
-	@echo "Build finished; now you can process the pickle files."
-
-json:
-	$(SPHINXBUILD) -b json $(ALLSPHINXOPTS) $(BUILDDIR)/json
-	@echo
-	@echo "Build finished; now you can process the JSON files."
-
-htmlhelp:
-	$(SPHINXBUILD) -b htmlhelp $(ALLSPHINXOPTS) $(BUILDDIR)/htmlhelp
-	@echo
-	@echo "Build finished; now you can run HTML Help Workshop with the" \
-	      ".hhp project file in $(BUILDDIR)/htmlhelp."
-
-qthelp:
-	$(SPHINXBUILD) -b qthelp $(ALLSPHINXOPTS) $(BUILDDIR)/qthelp
-	@echo
-	@echo "Build finished; now you can run "qcollectiongenerator" with the" \
-	      ".qhcp project file in $(BUILDDIR)/qthelp, like this:"
-	@echo "# qcollectiongenerator $(BUILDDIR)/qthelp/pybind11.qhcp"
-	@echo "To view the help file:"
-	@echo "# assistant -collectionFile $(BUILDDIR)/qthelp/pybind11.qhc"
-
-applehelp:
-	$(SPHINXBUILD) -b applehelp $(ALLSPHINXOPTS) $(BUILDDIR)/applehelp
-	@echo
-	@echo "Build finished. The help book is in $(BUILDDIR)/applehelp."
-	@echo "N.B. You won't be able to view it unless you put it in" \
-	      "~/Library/Documentation/Help or install it in your application" \
-	      "bundle."
-
-devhelp:
-	$(SPHINXBUILD) -b devhelp $(ALLSPHINXOPTS) $(BUILDDIR)/devhelp
-	@echo
-	@echo "Build finished."
-	@echo "To view the help file:"
-	@echo "# mkdir -p $$HOME/.local/share/devhelp/pybind11"
-	@echo "# ln -s $(BUILDDIR)/devhelp $$HOME/.local/share/devhelp/pybind11"
-	@echo "# devhelp"
-
-epub:
-	$(SPHINXBUILD) -b epub $(ALLSPHINXOPTS) $(BUILDDIR)/epub
-	@echo
-	@echo "Build finished. The epub file is in $(BUILDDIR)/epub."
-
-latex:
-	$(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex
-	@echo
-	@echo "Build finished; the LaTeX files are in $(BUILDDIR)/latex."
-	@echo "Run \`make' in that directory to run these through (pdf)latex" \
-	      "(use \`make latexpdf' here to do that automatically)."
-
-latexpdf:
-	$(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex
-	@echo "Running LaTeX files through pdflatex..."
-	$(MAKE) -C $(BUILDDIR)/latex all-pdf
-	@echo "pdflatex finished; the PDF files are in $(BUILDDIR)/latex."
-
-latexpdfja:
-	$(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex
-	@echo "Running LaTeX files through platex and dvipdfmx..."
-	$(MAKE) -C $(BUILDDIR)/latex all-pdf-ja
-	@echo "pdflatex finished; the PDF files are in $(BUILDDIR)/latex."
-
-text:
-	$(SPHINXBUILD) -b text $(ALLSPHINXOPTS) $(BUILDDIR)/text
-	@echo
-	@echo "Build finished. The text files are in $(BUILDDIR)/text."
-
-man:
-	$(SPHINXBUILD) -b man $(ALLSPHINXOPTS) $(BUILDDIR)/man
-	@echo
-	@echo "Build finished. The manual pages are in $(BUILDDIR)/man."
-
-texinfo:
-	$(SPHINXBUILD) -b texinfo $(ALLSPHINXOPTS) $(BUILDDIR)/texinfo
-	@echo
-	@echo "Build finished. The Texinfo files are in $(BUILDDIR)/texinfo."
-	@echo "Run \`make' in that directory to run these through makeinfo" \
-	      "(use \`make info' here to do that automatically)."
-
-info:
-	$(SPHINXBUILD) -b texinfo $(ALLSPHINXOPTS) $(BUILDDIR)/texinfo
-	@echo "Running Texinfo files through makeinfo..."
-	make -C $(BUILDDIR)/texinfo info
-	@echo "makeinfo finished; the Info files are in $(BUILDDIR)/texinfo."
-
-gettext:
-	$(SPHINXBUILD) -b gettext $(I18NSPHINXOPTS) $(BUILDDIR)/locale
-	@echo
-	@echo "Build finished. The message catalogs are in $(BUILDDIR)/locale."
-
-changes:
-	$(SPHINXBUILD) -b changes $(ALLSPHINXOPTS) $(BUILDDIR)/changes
-	@echo
-	@echo "The overview file is in $(BUILDDIR)/changes."
-
-linkcheck:
-	$(SPHINXBUILD) -b linkcheck $(ALLSPHINXOPTS) $(BUILDDIR)/linkcheck
-	@echo
-	@echo "Link check complete; look for any errors in the above output " \
-	      "or in $(BUILDDIR)/linkcheck/output.txt."
-
-doctest:
-	$(SPHINXBUILD) -b doctest $(ALLSPHINXOPTS) $(BUILDDIR)/doctest
-	@echo "Testing of doctests in the sources finished, look at the " \
-	      "results in $(BUILDDIR)/doctest/output.txt."
-
-coverage:
-	$(SPHINXBUILD) -b coverage $(ALLSPHINXOPTS) $(BUILDDIR)/coverage
-	@echo "Testing of coverage in the sources finished, look at the " \
-	      "results in $(BUILDDIR)/coverage/python.txt."
-
-xml:
-	$(SPHINXBUILD) -b xml $(ALLSPHINXOPTS) $(BUILDDIR)/xml
-	@echo
-	@echo "Build finished. The XML files are in $(BUILDDIR)/xml."
-
-pseudoxml:
-	$(SPHINXBUILD) -b pseudoxml $(ALLSPHINXOPTS) $(BUILDDIR)/pseudoxml
-	@echo
-	@echo "Build finished. The pseudo-XML files are in $(BUILDDIR)/pseudoxml."
--- a/libs/pybind/docs/_static/css/custom.css
+++ b/libs/pybind/docs/_static/css/custom.css
@ -1,3 +0,0 @@
-.highlight .go {
-  color: #707070;
-}
--- a/libs/pybind/docs/advanced/cast/chrono.rst
+++ b/libs/pybind/docs/advanced/cast/chrono.rst
@ -1,81 +0,0 @@
-Chrono
-======
-
-When including the additional header file :file:`pybind11/chrono.h` conversions
-from C++11 chrono datatypes to python datetime objects are automatically enabled.
-This header also enables conversions of python floats (often from sources such
-as ``time.monotonic()``, ``time.perf_counter()`` and ``time.process_time()``)
-into durations.
-
-An overview of clocks in C++11
------------------------------
-
-A point of confusion when using these conversions is the differences between
-clocks provided in C++11. There are three clock types defined by the C++11
-standard and users can define their own if needed. Each of these clocks have
-different properties and when converting to and from python will give different
-results.
-
-The first clock defined by the standard is ``std::chrono::system_clock``. This
-clock measures the current date and time. However, this clock changes with to
-updates to the operating system time. For example, if your time is synchronised
-with a time server this clock will change. This makes this clock a poor choice
-for timing purposes but good for measuring the wall time.
-
-The second clock defined in the standard is ``std::chrono::steady_clock``.
-This clock ticks at a steady rate and is never adjusted. This makes it excellent
-for timing purposes, however the value in this clock does not correspond to the
-current date and time. Often this clock will be the amount of time your system
-has been on, although it does not have to be. This clock will never be the same
-clock as the system clock as the system clock can change but steady clocks
-cannot.
-
-The third clock defined in the standard is ``std::chrono::high_resolution_clock``.
-This clock is the clock that has the highest resolution out of the clocks in the
-system. It is normally a typedef to either the system clock or the steady clock
-but can be its own independent clock. This is important as when using these
-conversions as the types you get in python for this clock might be different
-depending on the system.
-If it is a typedef of the system clock, python will get datetime objects, but if
-it is a different clock they will be timedelta objects.
-
-Provided conversions
--------------------
-
-.. rubric:: C++ to Python
-
- ``std::chrono::system_clock::time_point`` → ``datetime.datetime``
-    System clock times are converted to python datetime instances. They are
-    in the local timezone, but do not have any timezone information attached
-    to them (they are naive datetime objects).
-
- ``std::chrono::duration`` → ``datetime.timedelta``
-    Durations are converted to timedeltas, any precision in the duration
-    greater than microseconds is lost by rounding towards zero.
-
- ``std::chrono::[other_clocks]::time_point`` → ``datetime.timedelta``
-    Any clock time that is not the system clock is converted to a time delta.
-    This timedelta measures the time from the clocks epoch to now.
-
-.. rubric:: Python to C++
-
- ``datetime.datetime`` or ``datetime.date`` or ``datetime.time`` → ``std::chrono::system_clock::time_point``
-    Date/time objects are converted into system clock timepoints. Any
-    timezone information is ignored and the type is treated as a naive
-    object.
-
- ``datetime.timedelta`` → ``std::chrono::duration``
-    Time delta are converted into durations with microsecond precision.
-
- ``datetime.timedelta`` → ``std::chrono::[other_clocks]::time_point``
-    Time deltas that are converted into clock timepoints are treated as
-    the amount of time from the start of the clocks epoch.
-
- ``float`` → ``std::chrono::duration``
-    Floats that are passed to C++ as durations be interpreted as a number of
-    seconds. These will be converted to the duration using ``duration_cast``
-    from the float.
-
- ``float`` → ``std::chrono::[other_clocks]::time_point``
-    Floats that are passed to C++ as time points will be interpreted as the
-    number of seconds from the start of the clocks epoch.
--- a/libs/pybind/docs/advanced/cast/custom.rst
+++ b/libs/pybind/docs/advanced/cast/custom.rst
@ -1,93 +0,0 @@
-Custom type casters
-===================
-
-In very rare cases, applications may require custom type casters that cannot be
-expressed using the abstractions provided by pybind11, thus requiring raw
-Python C API calls. This is fairly advanced usage and should only be pursued by
-experts who are familiar with the intricacies of Python reference counting.
-
-The following snippets demonstrate how this works for a very simple ``inty``
-type that that should be convertible from Python types that provide a
-``__int__(self)`` method.
-
-.. code-block:: cpp
-
-    struct inty { long long_value; };
-
-    void print(inty s) {
-        std::cout << s.long_value << std::endl;
-    }
-
-The following Python snippet demonstrates the intended usage from the Python side:
-
-.. code-block:: python
-
-    class A:
-        def __int__(self):
-            return 123
-
-
-    from example import print
-
-    print(A())
-
-To register the necessary conversion routines, it is necessary to add an
-instantiation of the ``pybind11::detail::type_caster<T>`` template.
-Although this is an implementation detail, adding an instantiation of this
-type is explicitly allowed.
-
-.. code-block:: cpp
-
-    namespace pybind11 { namespace detail {
-        template <> struct type_caster<inty> {
-        public:
-            /**
-             * This macro establishes the name 'inty' in
-             * function signatures and declares a local variable
-             * 'value' of type inty
-             */
-            PYBIND11_TYPE_CASTER(inty, const_name("inty"));
-
-            /**
-             * Conversion part 1 (Python->C++): convert a PyObject into a inty
-             * instance or return false upon failure. The second argument
-             * indicates whether implicit conversions should be applied.
-             */
-            bool load(handle src, bool) {
-                /* Extract PyObject from handle */
-                PyObject *source = src.ptr();
-                /* Try converting into a Python integer value */
-                PyObject *tmp = PyNumber_Long(source);
-                if (!tmp)
-                    return false;
-                /* Now try to convert into a C++ int */
-                value.long_value = PyLong_AsLong(tmp);
-                Py_DECREF(tmp);
-                /* Ensure return code was OK (to avoid out-of-range errors etc) */
-                return !(value.long_value == -1 && !PyErr_Occurred());
-            }
-
-            /**
-             * Conversion part 2 (C++ -> Python): convert an inty instance into
-             * a Python object. The second and third arguments are used to
-             * indicate the return value policy and parent object (for
-             * ``return_value_policy::reference_internal``) and are generally
-             * ignored by implicit casters.
-             */
-            static handle cast(inty src, return_value_policy /* policy */, handle /* parent */) {
-                return PyLong_FromLong(src.long_value);
-            }
-        };
-    }} // namespace pybind11::detail
-
-.. note::
-
-    A ``type_caster<T>`` defined with ``PYBIND11_TYPE_CASTER(T, ...)`` requires
-    that ``T`` is default-constructible (``value`` is first default constructed
-    and then ``load()`` assigns to it).
-
-.. warning::
-
-    When using custom type casters, it's important to declare them consistently
-    in every compilation unit of the Python extension module. Otherwise,
-    undefined behavior can ensue.
--- a/libs/pybind/docs/advanced/cast/eigen.rst
+++ b/libs/pybind/docs/advanced/cast/eigen.rst
@ -1,310 +0,0 @@
-Eigen
-#####
-
-`Eigen <http://eigen.tuxfamily.org>`_ is C++ header-based library for dense and
-sparse linear algebra. Due to its popularity and widespread adoption, pybind11
-provides transparent conversion and limited mapping support between Eigen and
-Scientific Python linear algebra data types.
-
-To enable the built-in Eigen support you must include the optional header file
-:file:`pybind11/eigen.h`.
-
-Pass-by-value
-=============
-
-When binding a function with ordinary Eigen dense object arguments (for
-example, ``Eigen::MatrixXd``), pybind11 will accept any input value that is
-already (or convertible to) a ``numpy.ndarray`` with dimensions compatible with
-the Eigen type, copy its values into a temporary Eigen variable of the
-appropriate type, then call the function with this temporary variable.
-
-Sparse matrices are similarly copied to or from
-``scipy.sparse.csr_matrix``/``scipy.sparse.csc_matrix`` objects.
-
-Pass-by-reference
-=================
-
-One major limitation of the above is that every data conversion implicitly
-involves a copy, which can be both expensive (for large matrices) and disallows
-binding functions that change their (Matrix) arguments.  Pybind11 allows you to
-work around this by using Eigen's ``Eigen::Ref<MatrixType>`` class much as you
-would when writing a function taking a generic type in Eigen itself (subject to
-some limitations discussed below).
-
-When calling a bound function accepting a ``Eigen::Ref<const MatrixType>``
-type, pybind11 will attempt to avoid copying by using an ``Eigen::Map`` object
-that maps into the source ``numpy.ndarray`` data: this requires both that the
-data types are the same (e.g. ``dtype='float64'`` and ``MatrixType::Scalar`` is
-``double``); and that the storage is layout compatible.  The latter limitation
-is discussed in detail in the section below, and requires careful
-consideration: by default, numpy matrices and Eigen matrices are *not* storage
-compatible.
-
-If the numpy matrix cannot be used as is (either because its types differ, e.g.
-passing an array of integers to an Eigen parameter requiring doubles, or
-because the storage is incompatible), pybind11 makes a temporary copy and
-passes the copy instead.
-
-When a bound function parameter is instead ``Eigen::Ref<MatrixType>`` (note the
-lack of ``const``), pybind11 will only allow the function to be called if it
-can be mapped *and* if the numpy array is writeable (that is
-``a.flags.writeable`` is true).  Any access (including modification) made to
-the passed variable will be transparently carried out directly on the
-``numpy.ndarray``.
-
-This means you can write code such as the following and have it work as
-expected:
-
-.. code-block:: cpp
-
-    void scale_by_2(Eigen::Ref<Eigen::VectorXd> v) {
-        v *= 2;
-    }
-
-Note, however, that you will likely run into limitations due to numpy and
-Eigen's difference default storage order for data; see the below section on
-:ref:`storage_orders` for details on how to bind code that won't run into such
-limitations.
-
-.. note::
-
-    Passing by reference is not supported for sparse types.
-
-Returning values to Python
-==========================
-
-When returning an ordinary dense Eigen matrix type to numpy (e.g.
-``Eigen::MatrixXd`` or ``Eigen::RowVectorXf``) pybind11 keeps the matrix and
-returns a numpy array that directly references the Eigen matrix: no copy of the
-data is performed.  The numpy array will have ``array.flags.owndata`` set to
-``False`` to indicate that it does not own the data, and the lifetime of the
-stored Eigen matrix will be tied to the returned ``array``.
-
-If you bind a function with a non-reference, ``const`` return type (e.g.
-``const Eigen::MatrixXd``), the same thing happens except that pybind11 also
-sets the numpy array's ``writeable`` flag to false.
-
-If you return an lvalue reference or pointer, the usual pybind11 rules apply,
-as dictated by the binding function's return value policy (see the
-documentation on :ref:`return_value_policies` for full details).  That means,
-without an explicit return value policy, lvalue references will be copied and
-pointers will be managed by pybind11.  In order to avoid copying, you should
-explicitly specify an appropriate return value policy, as in the following
-example:
-
-.. code-block:: cpp
-
-    class MyClass {
-        Eigen::MatrixXd big_mat = Eigen::MatrixXd::Zero(10000, 10000);
-    public:
-        Eigen::MatrixXd &getMatrix() { return big_mat; }
-        const Eigen::MatrixXd &viewMatrix() { return big_mat; }
-    };
-
-    // Later, in binding code:
-    py::class_<MyClass>(m, "MyClass")
-        .def(py::init<>())
-        .def("copy_matrix", &MyClass::getMatrix) // Makes a copy!
-        .def("get_matrix", &MyClass::getMatrix, py::return_value_policy::reference_internal)
-        .def("view_matrix", &MyClass::viewMatrix, py::return_value_policy::reference_internal)
-        ;
-
-.. code-block:: python
-
-    a = MyClass()
-    m = a.get_matrix()  # flags.writeable = True,  flags.owndata = False
-    v = a.view_matrix()  # flags.writeable = False, flags.owndata = False
-    c = a.copy_matrix()  # flags.writeable = True,  flags.owndata = True
-    # m[5,6] and v[5,6] refer to the same element, c[5,6] does not.
-
-Note in this example that ``py::return_value_policy::reference_internal`` is
-used to tie the life of the MyClass object to the life of the returned arrays.
-
-You may also return an ``Eigen::Ref``, ``Eigen::Map`` or other map-like Eigen
-object (for example, the return value of ``matrix.block()`` and related
-methods) that map into a dense Eigen type.  When doing so, the default
-behaviour of pybind11 is to simply reference the returned data: you must take
-care to ensure that this data remains valid!  You may ask pybind11 to
-explicitly *copy* such a return value by using the
-``py::return_value_policy::copy`` policy when binding the function.  You may
-also use ``py::return_value_policy::reference_internal`` or a
-``py::keep_alive`` to ensure the data stays valid as long as the returned numpy
-array does.
-
-When returning such a reference of map, pybind11 additionally respects the
-readonly-status of the returned value, marking the numpy array as non-writeable
-if the reference or map was itself read-only.
-
-.. note::
-
-    Sparse types are always copied when returned.
-
-.. _storage_orders:
-
-Storage orders
-==============
-
-Passing arguments via ``Eigen::Ref`` has some limitations that you must be
-aware of in order to effectively pass matrices by reference.  First and
-foremost is that the default ``Eigen::Ref<MatrixType>`` class requires
-contiguous storage along columns (for column-major types, the default in Eigen)
-or rows if ``MatrixType`` is specifically an ``Eigen::RowMajor`` storage type.
-The former, Eigen's default, is incompatible with ``numpy``'s default row-major
-storage, and so you will not be able to pass numpy arrays to Eigen by reference
-without making one of two changes.
-
-(Note that this does not apply to vectors (or column or row matrices): for such
-types the "row-major" and "column-major" distinction is meaningless).
-
-The first approach is to change the use of ``Eigen::Ref<MatrixType>`` to the
-more general ``Eigen::Ref<MatrixType, 0, Eigen::Stride<Eigen::Dynamic,
-Eigen::Dynamic>>`` (or similar type with a fully dynamic stride type in the
-third template argument).  Since this is a rather cumbersome type, pybind11
-provides a ``py::EigenDRef<MatrixType>`` type alias for your convenience (along
-with EigenDMap for the equivalent Map, and EigenDStride for just the stride
-type).
-
-This type allows Eigen to map into any arbitrary storage order.  This is not
-the default in Eigen for performance reasons: contiguous storage allows
-vectorization that cannot be done when storage is not known to be contiguous at
-compile time.  The default ``Eigen::Ref`` stride type allows non-contiguous
-storage along the outer dimension (that is, the rows of a column-major matrix
-or columns of a row-major matrix), but not along the inner dimension.
-
-This type, however, has the added benefit of also being able to map numpy array
-slices.  For example, the following (contrived) example uses Eigen with a numpy
-slice to multiply by 2 all coefficients that are both on even rows (0, 2, 4,
-...) and in columns 2, 5, or 8:
-
-.. code-block:: cpp
-
-    m.def("scale", [](py::EigenDRef<Eigen::MatrixXd> m, double c) { m *= c; });
-
-.. code-block:: python
-
-    # a = np.array(...)
-    scale_by_2(myarray[0::2, 2:9:3])
-
-The second approach to avoid copying is more intrusive: rearranging the
-underlying data types to not run into the non-contiguous storage problem in the
-first place.  In particular, that means using matrices with ``Eigen::RowMajor``
-storage, where appropriate, such as:
-
-.. code-block:: cpp
-
-    using RowMatrixXd = Eigen::Matrix<double, Eigen::Dynamic, Eigen::Dynamic, Eigen::RowMajor>;
-    // Use RowMatrixXd instead of MatrixXd
-
-Now bound functions accepting ``Eigen::Ref<RowMatrixXd>`` arguments will be
-callable with numpy's (default) arrays without involving a copying.
-
-You can, alternatively, change the storage order that numpy arrays use by
-adding the ``order='F'`` option when creating an array:
-
-.. code-block:: python
-
-    myarray = np.array(source, order="F")
-
-Such an object will be passable to a bound function accepting an
-``Eigen::Ref<MatrixXd>`` (or similar column-major Eigen type).
-
-One major caveat with this approach, however, is that it is not entirely as
-easy as simply flipping all Eigen or numpy usage from one to the other: some
-operations may alter the storage order of a numpy array.  For example, ``a2 =
-array.transpose()`` results in ``a2`` being a view of ``array`` that references
-the same data, but in the opposite storage order!
-
-While this approach allows fully optimized vectorized calculations in Eigen, it
-cannot be used with array slices, unlike the first approach.
-
-When *returning* a matrix to Python (either a regular matrix, a reference via
-``Eigen::Ref<>``, or a map/block into a matrix), no special storage
-consideration is required: the created numpy array will have the required
-stride that allows numpy to properly interpret the array, whatever its storage
-order.
-
-Failing rather than copying
-===========================
-
-The default behaviour when binding ``Eigen::Ref<const MatrixType>`` Eigen
-references is to copy matrix values when passed a numpy array that does not
-conform to the element type of ``MatrixType`` or does not have a compatible
-stride layout.  If you want to explicitly avoid copying in such a case, you
-should bind arguments using the ``py::arg().noconvert()`` annotation (as
-described in the :ref:`nonconverting_arguments` documentation).
-
-The following example shows an example of arguments that don't allow data
-copying to take place:
-
-.. code-block:: cpp
-
-    // The method and function to be bound:
-    class MyClass {
-        // ...
-        double some_method(const Eigen::Ref<const MatrixXd> &matrix) { /* ... */ }
-    };
-    float some_function(const Eigen::Ref<const MatrixXf> &big,
-                        const Eigen::Ref<const MatrixXf> &small) {
-        // ...
-    }
-
-    // The associated binding code:
-    using namespace pybind11::literals; // for "arg"_a
-    py::class_<MyClass>(m, "MyClass")
-        // ... other class definitions
-        .def("some_method", &MyClass::some_method, py::arg().noconvert());
-
-    m.def("some_function", &some_function,
-        "big"_a.noconvert(), // <- Don't allow copying for this arg
-        "small"_a            // <- This one can be copied if needed
-    );
-
-With the above binding code, attempting to call the the ``some_method(m)``
-method on a ``MyClass`` object, or attempting to call ``some_function(m, m2)``
-will raise a ``RuntimeError`` rather than making a temporary copy of the array.
-It will, however, allow the ``m2`` argument to be copied into a temporary if
-necessary.
-
-Note that explicitly specifying ``.noconvert()`` is not required for *mutable*
-Eigen references (e.g. ``Eigen::Ref<MatrixXd>`` without ``const`` on the
-``MatrixXd``): mutable references will never be called with a temporary copy.
-
-Vectors versus column/row matrices
-==================================
-
-Eigen and numpy have fundamentally different notions of a vector.  In Eigen, a
-vector is simply a matrix with the number of columns or rows set to 1 at
-compile time (for a column vector or row vector, respectively).  NumPy, in
-contrast, has comparable 2-dimensional 1xN and Nx1 arrays, but *also* has
-1-dimensional arrays of size N.
-
-When passing a 2-dimensional 1xN or Nx1 array to Eigen, the Eigen type must
-have matching dimensions: That is, you cannot pass a 2-dimensional Nx1 numpy
-array to an Eigen value expecting a row vector, or a 1xN numpy array as a
-column vector argument.
-
-On the other hand, pybind11 allows you to pass 1-dimensional arrays of length N
-as Eigen parameters.  If the Eigen type can hold a column vector of length N it
-will be passed as such a column vector.  If not, but the Eigen type constraints
-will accept a row vector, it will be passed as a row vector.  (The column
-vector takes precedence when both are supported, for example, when passing a
-1D numpy array to a MatrixXd argument).  Note that the type need not be
-explicitly a vector: it is permitted to pass a 1D numpy array of size 5 to an
-Eigen ``Matrix<double, Dynamic, 5>``: you would end up with a 1x5 Eigen matrix.
-Passing the same to an ``Eigen::MatrixXd`` would result in a 5x1 Eigen matrix.
-
-When returning an Eigen vector to numpy, the conversion is ambiguous: a row
-vector of length 4 could be returned as either a 1D array of length 4, or as a
-2D array of size 1x4.  When encountering such a situation, pybind11 compromises
-by considering the returned Eigen type: if it is a compile-time vector--that
-is, the type has either the number of rows or columns set to 1 at compile
-time--pybind11 converts to a 1D numpy array when returning the value.  For
-instances that are a vector only at run-time (e.g. ``MatrixXd``,
-``Matrix<float, Dynamic, 4>``), pybind11 returns the vector as a 2D array to
-numpy.  If this isn't want you want, you can use ``array.reshape(...)`` to get
-a view of the same data in the desired dimensions.
-
-.. seealso::
-
-    The file :file:`tests/test_eigen.cpp` contains a complete example that
-    shows how to pass Eigen sparse and dense data types in more detail.
--- a/libs/pybind/docs/advanced/cast/functional.rst
+++ b/libs/pybind/docs/advanced/cast/functional.rst
@ -1,109 +0,0 @@
-Functional
-##########
-
-The following features must be enabled by including :file:`pybind11/functional.h`.
-
-
-Callbacks and passing anonymous functions
-=========================================
-
-The C++11 standard brought lambda functions and the generic polymorphic
-function wrapper ``std::function<>`` to the C++ programming language, which
-enable powerful new ways of working with functions. Lambda functions come in
-two flavors: stateless lambda function resemble classic function pointers that
-link to an anonymous piece of code, while stateful lambda functions
-additionally depend on captured variables that are stored in an anonymous
-*lambda closure object*.
-
-Here is a simple example of a C++ function that takes an arbitrary function
-(stateful or stateless) with signature ``int -> int`` as an argument and runs
-it with the value 10.
-
-.. code-block:: cpp
-
-    int func_arg(const std::function<int(int)> &f) {
-        return f(10);
-    }
-
-The example below is more involved: it takes a function of signature ``int -> int``
-and returns another function of the same kind. The return value is a stateful
-lambda function, which stores the value ``f`` in the capture object and adds 1 to
-its return value upon execution.
-
-.. code-block:: cpp
-
-    std::function<int(int)> func_ret(const std::function<int(int)> &f) {
-        return [f](int i) {
-            return f(i) + 1;
-        };
-    }
-
-This example demonstrates using python named parameters in C++ callbacks which
-requires using ``py::cpp_function`` as a wrapper. Usage is similar to defining
-methods of classes:
-
-.. code-block:: cpp
-
-    py::cpp_function func_cpp() {
-        return py::cpp_function([](int i) { return i+1; },
-           py::arg("number"));
-    }
-
-After including the extra header file :file:`pybind11/functional.h`, it is almost
-trivial to generate binding code for all of these functions.
-
-.. code-block:: cpp
-
-    #include <pybind11/functional.h>
-
-    PYBIND11_MODULE(example, m) {
-        m.def("func_arg", &func_arg);
-        m.def("func_ret", &func_ret);
-        m.def("func_cpp", &func_cpp);
-    }
-
-The following interactive session shows how to call them from Python.
-
-.. code-block:: pycon
-
-    $ python
-    >>> import example
-    >>> def square(i):
-    ...     return i * i
-    ...
-    >>> example.func_arg(square)
-    100L
-    >>> square_plus_1 = example.func_ret(square)
-    >>> square_plus_1(4)
-    17L
-    >>> plus_1 = func_cpp()
-    >>> plus_1(number=43)
-    44L
-
-.. warning::
-
-    Keep in mind that passing a function from C++ to Python (or vice versa)
-    will instantiate a piece of wrapper code that translates function
-    invocations between the two languages. Naturally, this translation
-    increases the computational cost of each function call somewhat. A
-    problematic situation can arise when a function is copied back and forth
-    between Python and C++ many times in a row, in which case the underlying
-    wrappers will accumulate correspondingly. The resulting long sequence of
-    C++ -> Python -> C++ -> ... roundtrips can significantly decrease
-    performance.
-
-    There is one exception: pybind11 detects case where a stateless function
-    (i.e. a function pointer or a lambda function without captured variables)
-    is passed as an argument to another C++ function exposed in Python. In this
-    case, there is no overhead. Pybind11 will extract the underlying C++
-    function pointer from the wrapped function to sidestep a potential C++ ->
-    Python -> C++ roundtrip. This is demonstrated in :file:`tests/test_callbacks.cpp`.
-
-.. note::
-
-    This functionality is very useful when generating bindings for callbacks in
-    C++ libraries (e.g. GUI libraries, asynchronous networking libraries, etc.).
-
-    The file :file:`tests/test_callbacks.cpp` contains a complete example
-    that demonstrates how to work with callbacks and anonymous functions in
-    more detail.
--- a/libs/pybind/docs/advanced/cast/index.rst
+++ b/libs/pybind/docs/advanced/cast/index.rst
@ -1,43 +0,0 @@
-.. _type-conversions:
-
-Type conversions
-################
-
-Apart from enabling cross-language function calls, a fundamental problem
-that a binding tool like pybind11 must address is to provide access to
-native Python types in C++ and vice versa. There are three fundamentally
-different ways to do this—which approach is preferable for a particular type
-depends on the situation at hand.
-
-1. Use a native C++ type everywhere. In this case, the type must be wrapped
-   using pybind11-generated bindings so that Python can interact with it.
-
-2. Use a native Python type everywhere. It will need to be wrapped so that
-   C++ functions can interact with it.
-
-3. Use a native C++ type on the C++ side and a native Python type on the
-   Python side. pybind11 refers to this as a *type conversion*.
-
-   Type conversions are the most "natural" option in the sense that native
-   (non-wrapped) types are used everywhere. The main downside is that a copy
-   of the data must be made on every Python ↔ C++ transition: this is
-   needed since the C++ and Python versions of the same type generally won't
-   have the same memory layout.
-
-   pybind11 can perform many kinds of conversions automatically. An overview
-   is provided in the table ":ref:`conversion_table`".
-
-The following subsections discuss the differences between these options in more
-detail. The main focus in this section is on type conversions, which represent
-the last case of the above list.
-
-.. toctree::
-   :maxdepth: 1
-
-   overview
-   strings
-   stl
-   functional
-   chrono
-   eigen
-   custom
--- a/libs/pybind/docs/advanced/cast/overview.rst
+++ b/libs/pybind/docs/advanced/cast/overview.rst
@ -1,170 +0,0 @@
-Overview
-########
-
-.. rubric:: 1. Native type in C++, wrapper in Python
-
-Exposing a custom C++ type using :class:`py::class_` was covered in detail
-in the :doc:`/classes` section. There, the underlying data structure is
-always the original C++ class while the :class:`py::class_` wrapper provides
-a Python interface. Internally, when an object like this is sent from C++ to
-Python, pybind11 will just add the outer wrapper layer over the native C++
-object. Getting it back from Python is just a matter of peeling off the
-wrapper.
-
-.. rubric:: 2. Wrapper in C++, native type in Python
-
-This is the exact opposite situation. Now, we have a type which is native to
-Python, like a ``tuple`` or a ``list``. One way to get this data into C++ is
-with the :class:`py::object` family of wrappers. These are explained in more
-detail in the :doc:`/advanced/pycpp/object` section. We'll just give a quick
-example here:
-
-.. code-block:: cpp
-
-    void print_list(py::list my_list) {
-        for (auto item : my_list)
-            std::cout << item << " ";
-    }
-
-.. code-block:: pycon
-
-    >>> print_list([1, 2, 3])
-    1 2 3
-
-The Python ``list`` is not converted in any way -- it's just wrapped in a C++
-:class:`py::list` class. At its core it's still a Python object. Copying a
-:class:`py::list` will do the usual reference-counting like in Python.
-Returning the object to Python will just remove the thin wrapper.
-
-.. rubric:: 3. Converting between native C++ and Python types
-
-In the previous two cases we had a native type in one language and a wrapper in
-the other. Now, we have native types on both sides and we convert between them.
-
-.. code-block:: cpp
-
-    void print_vector(const std::vector<int> &v) {
-        for (auto item : v)
-            std::cout << item << "\n";
-    }
-
-.. code-block:: pycon
-
-    >>> print_vector([1, 2, 3])
-    1 2 3
-
-In this case, pybind11 will construct a new ``std::vector<int>`` and copy each
-element from the Python ``list``. The newly constructed object will be passed
-to ``print_vector``. The same thing happens in the other direction: a new
-``list`` is made to match the value returned from C++.
-
-Lots of these conversions are supported out of the box, as shown in the table
-below. They are very convenient, but keep in mind that these conversions are
-fundamentally based on copying data. This is perfectly fine for small immutable
-types but it may become quite expensive for large data structures. This can be
-avoided by overriding the automatic conversion with a custom wrapper (i.e. the
-above-mentioned approach 1). This requires some manual effort and more details
-are available in the :ref:`opaque` section.
-
-.. _conversion_table:
-
-List of all builtin conversions
-------------------------------
-
-The following basic data types are supported out of the box (some may require
-an additional extension header to be included). To pass other data structures
-as arguments and return values, refer to the section on binding :ref:`classes`.
-
-+------------------------------------+---------------------------+-----------------------------------+
-|  Data type                         |  Description              | Header file                       |
-+====================================+===========================+===================================+
-| ``int8_t``, ``uint8_t``            | 8-bit integers            | :file:`pybind11/pybind11.h`       |
-+------------------------------------+---------------------------+-----------------------------------+
-| ``int16_t``, ``uint16_t``          | 16-bit integers           | :file:`pybind11/pybind11.h`       |
-+------------------------------------+---------------------------+-----------------------------------+
-| ``int32_t``, ``uint32_t``          | 32-bit integers           | :file:`pybind11/pybind11.h`       |
-+------------------------------------+---------------------------+-----------------------------------+
-| ``int64_t``, ``uint64_t``          | 64-bit integers           | :file:`pybind11/pybind11.h`       |
-+------------------------------------+---------------------------+-----------------------------------+
-| ``ssize_t``, ``size_t``            | Platform-dependent size   | :file:`pybind11/pybind11.h`       |
-+------------------------------------+---------------------------+-----------------------------------+
-| ``float``, ``double``              | Floating point types      | :file:`pybind11/pybind11.h`       |
-+------------------------------------+---------------------------+-----------------------------------+
-| ``bool``                           | Two-state Boolean type    | :file:`pybind11/pybind11.h`       |
-+------------------------------------+---------------------------+-----------------------------------+
-| ``char``                           | Character literal         | :file:`pybind11/pybind11.h`       |
-+------------------------------------+---------------------------+-----------------------------------+
-| ``char16_t``                       | UTF-16 character literal  | :file:`pybind11/pybind11.h`       |
-+------------------------------------+---------------------------+-----------------------------------+
-| ``char32_t``                       | UTF-32 character literal  | :file:`pybind11/pybind11.h`       |
-+------------------------------------+---------------------------+-----------------------------------+
-| ``wchar_t``                        | Wide character literal    | :file:`pybind11/pybind11.h`       |
-+------------------------------------+---------------------------+-----------------------------------+
-| ``const char *``                   | UTF-8 string literal      | :file:`pybind11/pybind11.h`       |
-+------------------------------------+---------------------------+-----------------------------------+
-| ``const char16_t *``               | UTF-16 string literal     | :file:`pybind11/pybind11.h`       |
-+------------------------------------+---------------------------+-----------------------------------+
-| ``const char32_t *``               | UTF-32 string literal     | :file:`pybind11/pybind11.h`       |
-+------------------------------------+---------------------------+-----------------------------------+
-| ``const wchar_t *``                | Wide string literal       | :file:`pybind11/pybind11.h`       |
-+------------------------------------+---------------------------+-----------------------------------+
-| ``std::string``                    | STL dynamic UTF-8 string  | :file:`pybind11/pybind11.h`       |
-+------------------------------------+---------------------------+-----------------------------------+
-| ``std::u16string``                 | STL dynamic UTF-16 string | :file:`pybind11/pybind11.h`       |
-+------------------------------------+---------------------------+-----------------------------------+
-| ``std::u32string``                 | STL dynamic UTF-32 string | :file:`pybind11/pybind11.h`       |
-+------------------------------------+---------------------------+-----------------------------------+
-| ``std::wstring``                   | STL dynamic wide string   | :file:`pybind11/pybind11.h`       |
-+------------------------------------+---------------------------+-----------------------------------+
-| ``std::string_view``,              | STL C++17 string views    | :file:`pybind11/pybind11.h`       |
-| ``std::u16string_view``, etc.      |                           |                                   |
-+------------------------------------+---------------------------+-----------------------------------+
-| ``std::pair<T1, T2>``              | Pair of two custom types  | :file:`pybind11/pybind11.h`       |
-+------------------------------------+---------------------------+-----------------------------------+
-| ``std::tuple<...>``                | Arbitrary tuple of types  | :file:`pybind11/pybind11.h`       |
-+------------------------------------+---------------------------+-----------------------------------+
-| ``std::reference_wrapper<...>``    | Reference type wrapper    | :file:`pybind11/pybind11.h`       |
-+------------------------------------+---------------------------+-----------------------------------+
-| ``std::complex<T>``                | Complex numbers           | :file:`pybind11/complex.h`        |
-+------------------------------------+---------------------------+-----------------------------------+
-| ``std::array<T, Size>``            | STL static array          | :file:`pybind11/stl.h`            |
-+------------------------------------+---------------------------+-----------------------------------+
-| ``std::vector<T>``                 | STL dynamic array         | :file:`pybind11/stl.h`            |
-+------------------------------------+---------------------------+-----------------------------------+
-| ``std::deque<T>``                  | STL double-ended queue    | :file:`pybind11/stl.h`            |
-+------------------------------------+---------------------------+-----------------------------------+
-| ``std::valarray<T>``               | STL value array           | :file:`pybind11/stl.h`            |
-+------------------------------------+---------------------------+-----------------------------------+
-| ``std::list<T>``                   | STL linked list           | :file:`pybind11/stl.h`            |
-+------------------------------------+---------------------------+-----------------------------------+
-| ``std::map<T1, T2>``               | STL ordered map           | :file:`pybind11/stl.h`            |
-+------------------------------------+---------------------------+-----------------------------------+
-| ``std::unordered_map<T1, T2>``     | STL unordered map         | :file:`pybind11/stl.h`            |
-+------------------------------------+---------------------------+-----------------------------------+
-| ``std::set<T>``                    | STL ordered set           | :file:`pybind11/stl.h`            |
-+------------------------------------+---------------------------+-----------------------------------+
-| ``std::unordered_set<T>``          | STL unordered set         | :file:`pybind11/stl.h`            |
-+------------------------------------+---------------------------+-----------------------------------+
-| ``std::optional<T>``               | STL optional type (C++17) | :file:`pybind11/stl.h`            |
-+------------------------------------+---------------------------+-----------------------------------+
-| ``std::experimental::optional<T>`` | STL optional type (exp.)  | :file:`pybind11/stl.h`            |
-+------------------------------------+---------------------------+-----------------------------------+
-| ``std::variant<...>``              | Type-safe union (C++17)   | :file:`pybind11/stl.h`            |
-+------------------------------------+---------------------------+-----------------------------------+
-| ``std::filesystem::path<T>``       | STL path (C++17) [#]_     | :file:`pybind11/stl/filesystem.h` |
-+------------------------------------+---------------------------+-----------------------------------+
-| ``std::function<...>``             | STL polymorphic function  | :file:`pybind11/functional.h`     |
-+------------------------------------+---------------------------+-----------------------------------+
-| ``std::chrono::duration<...>``     | STL time duration         | :file:`pybind11/chrono.h`         |
-+------------------------------------+---------------------------+-----------------------------------+
-| ``std::chrono::time_point<...>``   | STL date/time             | :file:`pybind11/chrono.h`         |
-+------------------------------------+---------------------------+-----------------------------------+
-| ``Eigen::Matrix<...>``             | Eigen: dense matrix       | :file:`pybind11/eigen.h`          |
-+------------------------------------+---------------------------+-----------------------------------+
-| ``Eigen::Map<...>``                | Eigen: mapped memory      | :file:`pybind11/eigen.h`          |
-+------------------------------------+---------------------------+-----------------------------------+
-| ``Eigen::SparseMatrix<...>``       | Eigen: sparse matrix      | :file:`pybind11/eigen.h`          |
-+------------------------------------+---------------------------+-----------------------------------+
-
-.. [#] ``std::filesystem::path`` is converted to ``pathlib.Path`` and
-   ``os.PathLike`` is converted to ``std::filesystem::path``.
--- a/libs/pybind/docs/advanced/cast/stl.rst
+++ b/libs/pybind/docs/advanced/cast/stl.rst
@ -1,249 +0,0 @@
-STL containers
-##############
-
-Automatic conversion
-====================
-
-When including the additional header file :file:`pybind11/stl.h`, conversions
-between ``std::vector<>``/``std::deque<>``/``std::list<>``/``std::array<>``/``std::valarray<>``,
-``std::set<>``/``std::unordered_set<>``, and
-``std::map<>``/``std::unordered_map<>`` and the Python ``list``, ``set`` and
-``dict`` data structures are automatically enabled. The types ``std::pair<>``
-and ``std::tuple<>`` are already supported out of the box with just the core
-:file:`pybind11/pybind11.h` header.
-
-The major downside of these implicit conversions is that containers must be
-converted (i.e. copied) on every Python->C++ and C++->Python transition, which
-can have implications on the program semantics and performance. Please read the
-next sections for more details and alternative approaches that avoid this.
-
-.. note::
-
-    Arbitrary nesting of any of these types is possible.
-
-.. seealso::
-
-    The file :file:`tests/test_stl.cpp` contains a complete
-    example that demonstrates how to pass STL data types in more detail.
-
-.. _cpp17_container_casters:
-
-C++17 library containers
-========================
-
-The :file:`pybind11/stl.h` header also includes support for ``std::optional<>``
-and ``std::variant<>``. These require a C++17 compiler and standard library.
-In C++14 mode, ``std::experimental::optional<>`` is supported if available.
-
-Various versions of these containers also exist for C++11 (e.g. in Boost).
-pybind11 provides an easy way to specialize the ``type_caster`` for such
-types:
-
-.. code-block:: cpp
-
-    // `boost::optional` as an example -- can be any `std::optional`-like container
-    namespace pybind11 { namespace detail {
-        template <typename T>
-        struct type_caster<boost::optional<T>> : optional_caster<boost::optional<T>> {};
-    }}
-
-The above should be placed in a header file and included in all translation units
-where automatic conversion is needed. Similarly, a specialization can be provided
-for custom variant types:
-
-.. code-block:: cpp
-
-    // `boost::variant` as an example -- can be any `std::variant`-like container
-    namespace pybind11 { namespace detail {
-        template <typename... Ts>
-        struct type_caster<boost::variant<Ts...>> : variant_caster<boost::variant<Ts...>> {};
-
-        // Specifies the function used to visit the variant -- `apply_visitor` instead of `visit`
-        template <>
-        struct visit_helper<boost::variant> {
-            template <typename... Args>
-            static auto call(Args &&...args) -> decltype(boost::apply_visitor(args...)) {
-                return boost::apply_visitor(args...);
-            }
-        };
-    }} // namespace pybind11::detail
-
-The ``visit_helper`` specialization is not required if your ``name::variant`` provides
-a ``name::visit()`` function. For any other function name, the specialization must be
-included to tell pybind11 how to visit the variant.
-
-.. warning::
-
-    When converting a ``variant`` type, pybind11 follows the same rules as when
-    determining which function overload to call (:ref:`overload_resolution`), and
-    so the same caveats hold. In particular, the order in which the ``variant``'s
-    alternatives are listed is important, since pybind11 will try conversions in
-    this order. This means that, for example, when converting ``variant<int, bool>``,
-    the ``bool`` variant will never be selected, as any Python ``bool`` is already
-    an ``int`` and is convertible to a C++ ``int``. Changing the order of alternatives
-    (and using ``variant<bool, int>``, in this example) provides a solution.
-
-.. note::
-
-    pybind11 only supports the modern implementation of ``boost::variant``
-    which makes use of variadic templates. This requires Boost 1.56 or newer.
-
-.. _opaque:
-
-Making opaque types
-===================
-
-pybind11 heavily relies on a template matching mechanism to convert parameters
-and return values that are constructed from STL data types such as vectors,
-linked lists, hash tables, etc. This even works in a recursive manner, for
-instance to deal with lists of hash maps of pairs of elementary and custom
-types, etc.
-
-However, a fundamental limitation of this approach is that internal conversions
-between Python and C++ types involve a copy operation that prevents
-pass-by-reference semantics. What does this mean?
-
-Suppose we bind the following function
-
-.. code-block:: cpp
-
-    void append_1(std::vector<int> &v) {
-       v.push_back(1);
-    }
-
-and call it from Python, the following happens:
-
-.. code-block:: pycon
-
-   >>> v = [5, 6]
-   >>> append_1(v)
-   >>> print(v)
-   [5, 6]
-
-As you can see, when passing STL data structures by reference, modifications
-are not propagated back the Python side. A similar situation arises when
-exposing STL data structures using the ``def_readwrite`` or ``def_readonly``
-functions:
-
-.. code-block:: cpp
-
-    /* ... definition ... */
-
-    class MyClass {
-        std::vector<int> contents;
-    };
-
-    /* ... binding code ... */
-
-    py::class_<MyClass>(m, "MyClass")
-        .def(py::init<>())
-        .def_readwrite("contents", &MyClass::contents);
-
-In this case, properties can be read and written in their entirety. However, an
-``append`` operation involving such a list type has no effect:
-
-.. code-block:: pycon
-
-   >>> m = MyClass()
-   >>> m.contents = [5, 6]
-   >>> print(m.contents)
-   [5, 6]
-   >>> m.contents.append(7)
-   >>> print(m.contents)
-   [5, 6]
-
-Finally, the involved copy operations can be costly when dealing with very
-large lists. To deal with all of the above situations, pybind11 provides a
-macro named ``PYBIND11_MAKE_OPAQUE(T)`` that disables the template-based
-conversion machinery of types, thus rendering them *opaque*. The contents of
-opaque objects are never inspected or extracted, hence they *can* be passed by
-reference. For instance, to turn ``std::vector<int>`` into an opaque type, add
-the declaration
-
-.. code-block:: cpp
-
-    PYBIND11_MAKE_OPAQUE(std::vector<int>);
-
-before any binding code (e.g. invocations to ``class_::def()``, etc.). This
-macro must be specified at the top level (and outside of any namespaces), since
-it adds a template instantiation of ``type_caster``. If your binding code consists of
-multiple compilation units, it must be present in every file (typically via a
-common header) preceding any usage of ``std::vector<int>``. Opaque types must
-also have a corresponding ``class_`` declaration to associate them with a name
-in Python, and to define a set of available operations, e.g.:
-
-.. code-block:: cpp
-
-    py::class_<std::vector<int>>(m, "IntVector")
-        .def(py::init<>())
-        .def("clear", &std::vector<int>::clear)
-        .def("pop_back", &std::vector<int>::pop_back)
-        .def("__len__", [](const std::vector<int> &v) { return v.size(); })
-        .def("__iter__", [](std::vector<int> &v) {
-           return py::make_iterator(v.begin(), v.end());
-        }, py::keep_alive<0, 1>()) /* Keep vector alive while iterator is used */
-        // ....
-
-.. seealso::
-
-    The file :file:`tests/test_opaque_types.cpp` contains a complete
-    example that demonstrates how to create and expose opaque types using
-    pybind11 in more detail.
-
-.. _stl_bind:
-
-Binding STL containers
-======================
-
-The ability to expose STL containers as native Python objects is a fairly
-common request, hence pybind11 also provides an optional header file named
-:file:`pybind11/stl_bind.h` that does exactly this. The mapped containers try
-to match the behavior of their native Python counterparts as much as possible.
-
-The following example showcases usage of :file:`pybind11/stl_bind.h`:
-
-.. code-block:: cpp
-
-    // Don't forget this
-    #include <pybind11/stl_bind.h>
-
-    PYBIND11_MAKE_OPAQUE(std::vector<int>);
-    PYBIND11_MAKE_OPAQUE(std::map<std::string, double>);
-
-    // ...
-
-    // later in binding code:
-    py::bind_vector<std::vector<int>>(m, "VectorInt");
-    py::bind_map<std::map<std::string, double>>(m, "MapStringDouble");
-
-When binding STL containers pybind11 considers the types of the container's
-elements to decide whether the container should be confined to the local module
-(via the :ref:`module_local` feature).  If the container element types are
-anything other than already-bound custom types bound without
-``py::module_local()`` the container binding will have ``py::module_local()``
-applied.  This includes converting types such as numeric types, strings, Eigen
-types; and types that have not yet been bound at the time of the stl container
-binding.  This module-local binding is designed to avoid potential conflicts
-between module bindings (for example, from two separate modules each attempting
-to bind ``std::vector<int>`` as a python type).
-
-It is possible to override this behavior to force a definition to be either
-module-local or global.  To do so, you can pass the attributes
-``py::module_local()`` (to make the binding module-local) or
-``py::module_local(false)`` (to make the binding global) into the
-``py::bind_vector`` or ``py::bind_map`` arguments:
-
-.. code-block:: cpp
-
-    py::bind_vector<std::vector<int>>(m, "VectorInt", py::module_local(false));
-
-Note, however, that such a global binding would make it impossible to load this
-module at the same time as any other pybind module that also attempts to bind
-the same container type (``std::vector<int>`` in the above example).
-
-See :ref:`module_local` for more details on module-local bindings.
-
-.. seealso::
-
-    The file :file:`tests/test_stl_binders.cpp` shows how to use the
-    convenience STL container wrappers.
--- a/libs/pybind/docs/advanced/cast/strings.rst
+++ b/libs/pybind/docs/advanced/cast/strings.rst
@ -1,292 +0,0 @@
-Strings, bytes and Unicode conversions
-######################################
-
-Passing Python strings to C++
-=============================
-
-When a Python ``str`` is passed from Python to a C++ function that accepts
-``std::string`` or ``char *`` as arguments, pybind11 will encode the Python
-string to UTF-8. All Python ``str`` can be encoded in UTF-8, so this operation
-does not fail.
-
-The C++ language is encoding agnostic. It is the responsibility of the
-programmer to track encodings. It's often easiest to simply `use UTF-8
-everywhere <http://utf8everywhere.org/>`_.
-
-.. code-block:: c++
-
-    m.def("utf8_test",
-        [](const std::string &s) {
-            cout << "utf-8 is icing on the cake.\n";
-            cout << s;
-        }
-    );
-    m.def("utf8_charptr",
-        [](const char *s) {
-            cout << "My favorite food is\n";
-            cout << s;
-        }
-    );
-
-.. code-block:: pycon
-
-    >>> utf8_test("🎂")
-    utf-8 is icing on the cake.
-    🎂
-
-    >>> utf8_charptr("🍕")
-    My favorite food is
-    🍕
-
-.. note::
-
-    Some terminal emulators do not support UTF-8 or emoji fonts and may not
-    display the example above correctly.
-
-The results are the same whether the C++ function accepts arguments by value or
-reference, and whether or not ``const`` is used.
-
-Passing bytes to C++
--------------------
-
-A Python ``bytes`` object will be passed to C++ functions that accept
-``std::string`` or ``char*`` *without* conversion.  In order to make a function
-*only* accept ``bytes`` (and not ``str``), declare it as taking a ``py::bytes``
-argument.
-
-
-Returning C++ strings to Python
-===============================
-
-When a C++ function returns a ``std::string`` or ``char*`` to a Python caller,
-**pybind11 will assume that the string is valid UTF-8** and will decode it to a
-native Python ``str``, using the same API as Python uses to perform
-``bytes.decode('utf-8')``. If this implicit conversion fails, pybind11 will
-raise a ``UnicodeDecodeError``.
-
-.. code-block:: c++
-
-    m.def("std_string_return",
-        []() {
-            return std::string("This string needs to be UTF-8 encoded");
-        }
-    );
-
-.. code-block:: pycon
-
-    >>> isinstance(example.std_string_return(), str)
-    True
-
-
-Because UTF-8 is inclusive of pure ASCII, there is never any issue with
-returning a pure ASCII string to Python. If there is any possibility that the
-string is not pure ASCII, it is necessary to ensure the encoding is valid
-UTF-8.
-
-.. warning::
-
-    Implicit conversion assumes that a returned ``char *`` is null-terminated.
-    If there is no null terminator a buffer overrun will occur.
-
-Explicit conversions
--------------------
-
-If some C++ code constructs a ``std::string`` that is not a UTF-8 string, one
-can perform a explicit conversion and return a ``py::str`` object. Explicit
-conversion has the same overhead as implicit conversion.
-
-.. code-block:: c++
-
-    // This uses the Python C API to convert Latin-1 to Unicode
-    m.def("str_output",
-        []() {
-            std::string s = "Send your r\xe9sum\xe9 to Alice in HR"; // Latin-1
-            py::str py_s = PyUnicode_DecodeLatin1(s.data(), s.length());
-            return py_s;
-        }
-    );
-
-.. code-block:: pycon
-
-    >>> str_output()
-    'Send your résumé to Alice in HR'
-
-The `Python C API
-<https://docs.python.org/3/c-api/unicode.html#built-in-codecs>`_ provides
-several built-in codecs.
-
-
-One could also use a third party encoding library such as libiconv to transcode
-to UTF-8.
-
-Return C++ strings without conversion
-------------------------------------
-
-If the data in a C++ ``std::string`` does not represent text and should be
-returned to Python as ``bytes``, then one can return the data as a
-``py::bytes`` object.
-
-.. code-block:: c++
-
-    m.def("return_bytes",
-        []() {
-            std::string s("\xba\xd0\xba\xd0");  // Not valid UTF-8
-            return py::bytes(s);  // Return the data without transcoding
-        }
-    );
-
-.. code-block:: pycon
-
-    >>> example.return_bytes()
-    b'\xba\xd0\xba\xd0'
-
-
-Note the asymmetry: pybind11 will convert ``bytes`` to ``std::string`` without
-encoding, but cannot convert ``std::string`` back to ``bytes`` implicitly.
-
-.. code-block:: c++
-
-    m.def("asymmetry",
-        [](std::string s) {  // Accepts str or bytes from Python
-            return s;  // Looks harmless, but implicitly converts to str
-        }
-    );
-
-.. code-block:: pycon
-
-    >>> isinstance(example.asymmetry(b"have some bytes"), str)
-    True
-
-    >>> example.asymmetry(b"\xba\xd0\xba\xd0")  # invalid utf-8 as bytes
-    UnicodeDecodeError: 'utf-8' codec can't decode byte 0xba in position 0: invalid start byte
-
-
-Wide character strings
-======================
-
-When a Python ``str`` is passed to a C++ function expecting ``std::wstring``,
-``wchar_t*``, ``std::u16string`` or ``std::u32string``, the ``str`` will be
-encoded to UTF-16 or UTF-32 depending on how the C++ compiler implements each
-type, in the platform's native endianness. When strings of these types are
-returned, they are assumed to contain valid UTF-16 or UTF-32, and will be
-decoded to Python ``str``.
-
-.. code-block:: c++
-
-    #define UNICODE
-    #include <windows.h>
-
-    m.def("set_window_text",
-        [](HWND hwnd, std::wstring s) {
-            // Call SetWindowText with null-terminated UTF-16 string
-            ::SetWindowText(hwnd, s.c_str());
-        }
-    );
-    m.def("get_window_text",
-        [](HWND hwnd) {
-            const int buffer_size = ::GetWindowTextLength(hwnd) + 1;
-            auto buffer = std::make_unique< wchar_t[] >(buffer_size);
-
-            ::GetWindowText(hwnd, buffer.data(), buffer_size);
-
-            std::wstring text(buffer.get());
-
-            // wstring will be converted to Python str
-            return text;
-        }
-    );
-
-Strings in multibyte encodings such as Shift-JIS must transcoded to a
-UTF-8/16/32 before being returned to Python.
-
-
-Character literals
-==================
-
-C++ functions that accept character literals as input will receive the first
-character of a Python ``str`` as their input. If the string is longer than one
-Unicode character, trailing characters will be ignored.
-
-When a character literal is returned from C++ (such as a ``char`` or a
-``wchar_t``), it will be converted to a ``str`` that represents the single
-character.
-
-.. code-block:: c++
-
-    m.def("pass_char", [](char c) { return c; });
-    m.def("pass_wchar", [](wchar_t w) { return w; });
-
-.. code-block:: pycon
-
-    >>> example.pass_char("A")
-    'A'
-
-While C++ will cast integers to character types (``char c = 0x65;``), pybind11
-does not convert Python integers to characters implicitly. The Python function
-``chr()`` can be used to convert integers to characters.
-
-.. code-block:: pycon
-
-    >>> example.pass_char(0x65)
-    TypeError
-
-    >>> example.pass_char(chr(0x65))
-    'A'
-
-If the desire is to work with an 8-bit integer, use ``int8_t`` or ``uint8_t``
-as the argument type.
-
-Grapheme clusters
-----------------
-
-A single grapheme may be represented by two or more Unicode characters. For
-example 'é' is usually represented as U+00E9 but can also be expressed as the
-combining character sequence U+0065 U+0301 (that is, the letter 'e' followed by
-a combining acute accent). The combining character will be lost if the
-two-character sequence is passed as an argument, even though it renders as a
-single grapheme.
-
-.. code-block:: pycon
-
-    >>> example.pass_wchar("é")
-    'é'
-
-    >>> combining_e_acute = "e" + "\u0301"
-
-    >>> combining_e_acute
-    'é'
-
-    >>> combining_e_acute == "é"
-    False
-
-    >>> example.pass_wchar(combining_e_acute)
-    'e'
-
-Normalizing combining characters before passing the character literal to C++
-may resolve *some* of these issues:
-
-.. code-block:: pycon
-
-    >>> example.pass_wchar(unicodedata.normalize("NFC", combining_e_acute))
-    'é'
-
-In some languages (Thai for example), there are `graphemes that cannot be
-expressed as a single Unicode code point
-<http://unicode.org/reports/tr29/#Grapheme_Cluster_Boundaries>`_, so there is
-no way to capture them in a C++ character type.
-
-
-C++17 string views
-==================
-
-C++17 string views are automatically supported when compiling in C++17 mode.
-They follow the same rules for encoding and decoding as the corresponding STL
-string type (for example, a ``std::u16string_view`` argument will be passed
-UTF-16-encoded data, and a returned ``std::string_view`` will be decoded as
-UTF-8).
-
-References
-==========
-
-* `The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!) <https://www.joelonsoftware.com/2003/10/08/the-absolute-minimum-every-software-developer-absolutely-positively-must-know-about-unicode-and-character-sets-no-excuses/>`_
-* `C++ - Using STL Strings at Win32 API Boundaries <https://msdn.microsoft.com/en-ca/magazine/mt238407.aspx>`_
--- a/libs/pybind/docs/advanced/classes.rst
+++ b/libs/pybind/docs/advanced/classes.rst
--- a/libs/pybind/docs/advanced/embedding.rst
+++ b/libs/pybind/docs/advanced/embedding.rst
@ -1,262 +0,0 @@
-.. _embedding:
-
-Embedding the interpreter
-#########################
-
-While pybind11 is mainly focused on extending Python using C++, it's also
-possible to do the reverse: embed the Python interpreter into a C++ program.
-All of the other documentation pages still apply here, so refer to them for
-general pybind11 usage. This section will cover a few extra things required
-for embedding.
-
-Getting started
-===============
-
-A basic executable with an embedded interpreter can be created with just a few
-lines of CMake and the ``pybind11::embed`` target, as shown below. For more
-information, see :doc:`/compiling`.
-
-.. code-block:: cmake
-
-    cmake_minimum_required(VERSION 3.4)
-    project(example)
-
-    find_package(pybind11 REQUIRED)  # or `add_subdirectory(pybind11)`
-
-    add_executable(example main.cpp)
-    target_link_libraries(example PRIVATE pybind11::embed)
-
-The essential structure of the ``main.cpp`` file looks like this:
-
-.. code-block:: cpp
-
-    #include <pybind11/embed.h> // everything needed for embedding
-    namespace py = pybind11;
-
-    int main() {
-        py::scoped_interpreter guard{}; // start the interpreter and keep it alive
-
-        py::print("Hello, World!"); // use the Python API
-    }
-
-The interpreter must be initialized before using any Python API, which includes
-all the functions and classes in pybind11. The RAII guard class ``scoped_interpreter``
-takes care of the interpreter lifetime. After the guard is destroyed, the interpreter
-shuts down and clears its memory. No Python functions can be called after this.
-
-Executing Python code
-=====================
-
-There are a few different ways to run Python code. One option is to use ``eval``,
-``exec`` or ``eval_file``, as explained in :ref:`eval`. Here is a quick example in
-the context of an executable with an embedded interpreter:
-
-.. code-block:: cpp
-
-    #include <pybind11/embed.h>
-    namespace py = pybind11;
-
-    int main() {
-        py::scoped_interpreter guard{};
-
-        py::exec(R"(
-            kwargs = dict(name="World", number=42)
-            message = "Hello, {name}! The answer is {number}".format(**kwargs)
-            print(message)
-        )");
-    }
-
-Alternatively, similar results can be achieved using pybind11's API (see
-:doc:`/advanced/pycpp/index` for more details).
-
-.. code-block:: cpp
-
-    #include <pybind11/embed.h>
-    namespace py = pybind11;
-    using namespace py::literals;
-
-    int main() {
-        py::scoped_interpreter guard{};
-
-        auto kwargs = py::dict("name"_a="World", "number"_a=42);
-        auto message = "Hello, {name}! The answer is {number}"_s.format(**kwargs);
-        py::print(message);
-    }
-
-The two approaches can also be combined:
-
-.. code-block:: cpp
-
-    #include <pybind11/embed.h>
-    #include <iostream>
-
-    namespace py = pybind11;
-    using namespace py::literals;
-
-    int main() {
-        py::scoped_interpreter guard{};
-
-        auto locals = py::dict("name"_a="World", "number"_a=42);
-        py::exec(R"(
-            message = "Hello, {name}! The answer is {number}".format(**locals())
-        )", py::globals(), locals);
-
-        auto message = locals["message"].cast<std::string>();
-        std::cout << message;
-    }
-
-Importing modules
-=================
-
-Python modules can be imported using ``module_::import()``:
-
-.. code-block:: cpp
-
-    py::module_ sys = py::module_::import("sys");
-    py::print(sys.attr("path"));
-
-For convenience, the current working directory is included in ``sys.path`` when
-embedding the interpreter. This makes it easy to import local Python files:
-
-.. code-block:: python
-
-    """calc.py located in the working directory"""
-
-
-    def add(i, j):
-        return i + j
-
-
-.. code-block:: cpp
-
-    py::module_ calc = py::module_::import("calc");
-    py::object result = calc.attr("add")(1, 2);
-    int n = result.cast<int>();
-    assert(n == 3);
-
-Modules can be reloaded using ``module_::reload()`` if the source is modified e.g.
-by an external process. This can be useful in scenarios where the application
-imports a user defined data processing script which needs to be updated after
-changes by the user. Note that this function does not reload modules recursively.
-
-.. _embedding_modules:
-
-Adding embedded modules
-=======================
-
-Embedded binary modules can be added using the ``PYBIND11_EMBEDDED_MODULE`` macro.
-Note that the definition must be placed at global scope. They can be imported
-like any other module.
-
-.. code-block:: cpp
-
-    #include <pybind11/embed.h>
-    namespace py = pybind11;
-
-    PYBIND11_EMBEDDED_MODULE(fast_calc, m) {
-        // `m` is a `py::module_` which is used to bind functions and classes
-        m.def("add", [](int i, int j) {
-            return i + j;
-        });
-    }
-
-    int main() {
-        py::scoped_interpreter guard{};
-
-        auto fast_calc = py::module_::import("fast_calc");
-        auto result = fast_calc.attr("add")(1, 2).cast<int>();
-        assert(result == 3);
-    }
-
-Unlike extension modules where only a single binary module can be created, on
-the embedded side an unlimited number of modules can be added using multiple
-``PYBIND11_EMBEDDED_MODULE`` definitions (as long as they have unique names).
-
-These modules are added to Python's list of builtins, so they can also be
-imported in pure Python files loaded by the interpreter. Everything interacts
-naturally:
-
-.. code-block:: python
-
-    """py_module.py located in the working directory"""
-    import cpp_module
-
-    a = cpp_module.a
-    b = a + 1
-
-
-.. code-block:: cpp
-
-    #include <pybind11/embed.h>
-    namespace py = pybind11;
-
-    PYBIND11_EMBEDDED_MODULE(cpp_module, m) {
-        m.attr("a") = 1;
-    }
-
-    int main() {
-        py::scoped_interpreter guard{};
-
-        auto py_module = py::module_::import("py_module");
-
-        auto locals = py::dict("fmt"_a="{} + {} = {}", **py_module.attr("__dict__"));
-        assert(locals["a"].cast<int>() == 1);
-        assert(locals["b"].cast<int>() == 2);
-
-        py::exec(R"(
-            c = a + b
-            message = fmt.format(a, b, c)
-        )", py::globals(), locals);
-
-        assert(locals["c"].cast<int>() == 3);
-        assert(locals["message"].cast<std::string>() == "1 + 2 = 3");
-    }
-
-
-Interpreter lifetime
-====================
-
-The Python interpreter shuts down when ``scoped_interpreter`` is destroyed. After
-this, creating a new instance will restart the interpreter. Alternatively, the
-``initialize_interpreter`` / ``finalize_interpreter`` pair of functions can be used
-to directly set the state at any time.
-
-Modules created with pybind11 can be safely re-initialized after the interpreter
-has been restarted. However, this may not apply to third-party extension modules.
-The issue is that Python itself cannot completely unload extension modules and
-there are several caveats with regard to interpreter restarting. In short, not
-all memory may be freed, either due to Python reference cycles or user-created
-global data. All the details can be found in the CPython documentation.
-
-.. warning::
-
-    Creating two concurrent ``scoped_interpreter`` guards is a fatal error. So is
-    calling ``initialize_interpreter`` for a second time after the interpreter
-    has already been initialized.
-
-    Do not use the raw CPython API functions ``Py_Initialize`` and
-    ``Py_Finalize`` as these do not properly handle the lifetime of
-    pybind11's internal data.
-
-
-Sub-interpreter support
-=======================
-
-Creating multiple copies of ``scoped_interpreter`` is not possible because it
-represents the main Python interpreter. Sub-interpreters are something different
-and they do permit the existence of multiple interpreters. This is an advanced
-feature of the CPython API and should be handled with care. pybind11 does not
-currently offer a C++ interface for sub-interpreters, so refer to the CPython
-documentation for all the details regarding this feature.
-
-We'll just mention a couple of caveats the sub-interpreters support in pybind11:
-
- 1. Sub-interpreters will not receive independent copies of embedded modules.
-    Instead, these are shared and modifications in one interpreter may be
-    reflected in another.
-
- 2. Managing multiple threads, multiple interpreters and the GIL can be
-    challenging and there are several caveats here, even within the pure
-    CPython API (please refer to the Python docs for details). As for
-    pybind11, keep in mind that ``gil_scoped_release`` and ``gil_scoped_acquire``
-    do not take sub-interpreters into account.
--- a/libs/pybind/docs/advanced/exceptions.rst
+++ b/libs/pybind/docs/advanced/exceptions.rst
@ -1,398 +0,0 @@
-Exceptions
-##########
-
-Built-in C++ to Python exception translation
-============================================
-
-When Python calls C++ code through pybind11, pybind11 provides a C++ exception handler
-that will trap C++ exceptions, translate them to the corresponding Python exception,
-and raise them so that Python code can handle them.
-
-pybind11 defines translations for ``std::exception`` and its standard
-subclasses, and several special exception classes that translate to specific
-Python exceptions. Note that these are not actually Python exceptions, so they
-cannot be examined using the Python C API. Instead, they are pure C++ objects
-that pybind11 will translate the corresponding Python exception when they arrive
-at its exception handler.
-
-.. tabularcolumns:: |p{0.5\textwidth}|p{0.45\textwidth}|
-
-+--------------------------------------+--------------------------------------+
-|  Exception thrown by C++             |  Translated to Python exception type |
-+======================================+======================================+
-| :class:`std::exception`              | ``RuntimeError``                     |
-+--------------------------------------+--------------------------------------+
-| :class:`std::bad_alloc`              | ``MemoryError``                      |
-+--------------------------------------+--------------------------------------+
-| :class:`std::domain_error`           | ``ValueError``                       |
-+--------------------------------------+--------------------------------------+
-| :class:`std::invalid_argument`       | ``ValueError``                       |
-+--------------------------------------+--------------------------------------+
-| :class:`std::length_error`           | ``ValueError``                       |
-+--------------------------------------+--------------------------------------+
-| :class:`std::out_of_range`           | ``IndexError``                       |
-+--------------------------------------+--------------------------------------+
-| :class:`std::range_error`            | ``ValueError``                       |
-+--------------------------------------+--------------------------------------+
-| :class:`std::overflow_error`         | ``OverflowError``                    |
-+--------------------------------------+--------------------------------------+
-| :class:`pybind11::stop_iteration`    | ``StopIteration`` (used to implement |
-|                                      | custom iterators)                    |
-+--------------------------------------+--------------------------------------+
-| :class:`pybind11::index_error`       | ``IndexError`` (used to indicate out |
-|                                      | of bounds access in ``__getitem__``, |
-|                                      | ``__setitem__``, etc.)               |
-+--------------------------------------+--------------------------------------+
-| :class:`pybind11::key_error`         | ``KeyError`` (used to indicate out   |
-|                                      | of bounds access in ``__getitem__``, |
-|                                      | ``__setitem__`` in dict-like         |
-|                                      | objects, etc.)                       |
-+--------------------------------------+--------------------------------------+
-| :class:`pybind11::value_error`       | ``ValueError`` (used to indicate     |
-|                                      | wrong value passed in                |
-|                                      | ``container.remove(...)``)           |
-+--------------------------------------+--------------------------------------+
-| :class:`pybind11::type_error`        | ``TypeError``                        |
-+--------------------------------------+--------------------------------------+
-| :class:`pybind11::buffer_error`      | ``BufferError``                      |
-+--------------------------------------+--------------------------------------+
-| :class:`pybind11::import_error`      | ``ImportError``                      |
-+--------------------------------------+--------------------------------------+
-| :class:`pybind11::attribute_error`   | ``AttributeError``                   |
-+--------------------------------------+--------------------------------------+
-| Any other exception                  | ``RuntimeError``                     |
-+--------------------------------------+--------------------------------------+
-
-Exception translation is not bidirectional. That is, *catching* the C++
-exceptions defined above will not trap exceptions that originate from
-Python. For that, catch :class:`pybind11::error_already_set`. See :ref:`below
-<handling_python_exceptions_cpp>` for further details.
-
-There is also a special exception :class:`cast_error` that is thrown by
-:func:`handle::call` when the input arguments cannot be converted to Python
-objects.
-
-Registering custom translators
-==============================
-
-If the default exception conversion policy described above is insufficient,
-pybind11 also provides support for registering custom exception translators.
-Similar to pybind11 classes, exception translators can be local to the module
-they are defined in or global to the entire python session.  To register a simple
-exception conversion that translates a C++ exception into a new Python exception
-using the C++ exception's ``what()`` method, a helper function is available:
-
-.. code-block:: cpp
-
-    py::register_exception<CppExp>(module, "PyExp");
-
-This call creates a Python exception class with the name ``PyExp`` in the given
-module and automatically converts any encountered exceptions of type ``CppExp``
-into Python exceptions of type ``PyExp``.
-
-A matching function is available for registering a local exception translator:
-
-.. code-block:: cpp
-
-    py::register_local_exception<CppExp>(module, "PyExp");
-
-
-It is possible to specify base class for the exception using the third
-parameter, a ``handle``:
-
-.. code-block:: cpp
-
-    py::register_exception<CppExp>(module, "PyExp", PyExc_RuntimeError);
-    py::register_local_exception<CppExp>(module, "PyExp", PyExc_RuntimeError);
-
-Then ``PyExp`` can be caught both as ``PyExp`` and ``RuntimeError``.
-
-The class objects of the built-in Python exceptions are listed in the Python
-documentation on `Standard Exceptions <https://docs.python.org/3/c-api/exceptions.html#standard-exceptions>`_.
-The default base class is ``PyExc_Exception``.
-
-When more advanced exception translation is needed, the functions
-``py::register_exception_translator(translator)`` and
-``py::register_local_exception_translator(translator)`` can be used to register
-functions that can translate arbitrary exception types (and which may include
-additional logic to do so).  The functions takes a stateless callable (e.g. a
-function pointer or a lambda function without captured variables) with the call
-signature ``void(std::exception_ptr)``.
-
-When a C++ exception is thrown, the registered exception translators are tried
-in reverse order of registration (i.e. the last registered translator gets the
-first shot at handling the exception). All local translators will be tried
-before a global translator is tried.
-
-Inside the translator, ``std::rethrow_exception`` should be used within
-a try block to re-throw the exception.  One or more catch clauses to catch
-the appropriate exceptions should then be used with each clause using
-``PyErr_SetString`` to set a Python exception or ``ex(string)`` to set
-the python exception to a custom exception type (see below).
-
-To declare a custom Python exception type, declare a ``py::exception`` variable
-and use this in the associated exception translator (note: it is often useful
-to make this a static declaration when using it inside a lambda expression
-without requiring capturing).
-
-The following example demonstrates this for a hypothetical exception classes
-``MyCustomException`` and ``OtherException``: the first is translated to a
-custom python exception ``MyCustomError``, while the second is translated to a
-standard python RuntimeError:
-
-.. code-block:: cpp
-
-    static py::exception<MyCustomException> exc(m, "MyCustomError");
-    py::register_exception_translator([](std::exception_ptr p) {
-        try {
-            if (p) std::rethrow_exception(p);
-        } catch (const MyCustomException &e) {
-            exc(e.what());
-        } catch (const OtherException &e) {
-            PyErr_SetString(PyExc_RuntimeError, e.what());
-        }
-    });
-
-Multiple exceptions can be handled by a single translator, as shown in the
-example above. If the exception is not caught by the current translator, the
-previously registered one gets a chance.
-
-If none of the registered exception translators is able to handle the
-exception, it is handled by the default converter as described in the previous
-section.
-
-.. seealso::
-
-    The file :file:`tests/test_exceptions.cpp` contains examples
-    of various custom exception translators and custom exception types.
-
-.. note::
-
-    Call either ``PyErr_SetString`` or a custom exception's call
-    operator (``exc(string)``) for every exception caught in a custom exception
-    translator.  Failure to do so will cause Python to crash with ``SystemError:
-    error return without exception set``.
-
-    Exceptions that you do not plan to handle should simply not be caught, or
-    may be explicitly (re-)thrown to delegate it to the other,
-    previously-declared existing exception translators.
-
-    Note that ``libc++`` and ``libstdc++`` `behave differently <https://stackoverflow.com/questions/19496643/using-clang-fvisibility-hidden-and-typeinfo-and-type-erasure/28827430>`_
-    with ``-fvisibility=hidden``. Therefore exceptions that are used across ABI boundaries need to be explicitly exported, as exercised in ``tests/test_exceptions.h``.
-    See also: "Problems with C++ exceptions" under `GCC Wiki <https://gcc.gnu.org/wiki/Visibility>`_.
-
-
-Local vs Global Exception Translators
-=====================================
-
-When a global exception translator is registered, it will be applied across all
-modules in the reverse order of registration. This can create behavior where the
-order of module import influences how exceptions are translated.
-
-If module1 has the following translator:
-
-.. code-block:: cpp
-
-      py::register_exception_translator([](std::exception_ptr p) {
-        try {
-            if (p) std::rethrow_exception(p);
-        } catch (const std::invalid_argument &e) {
-            PyErr_SetString("module1 handled this")
-        }
-      }
-
-and module2 has the following similar translator:
-
-.. code-block:: cpp
-
-      py::register_exception_translator([](std::exception_ptr p) {
-        try {
-            if (p) std::rethrow_exception(p);
-        } catch (const std::invalid_argument &e) {
-            PyErr_SetString("module2 handled this")
-        }
-      }
-
-then which translator handles the invalid_argument will be determined by the
-order that module1 and module2 are imported. Since exception translators are
-applied in the reverse order of registration, which ever module was imported
-last will "win" and that translator will be applied.
-
-If there are multiple pybind11 modules that share exception types (either
-standard built-in or custom) loaded into a single python instance and
-consistent error handling behavior is needed, then local translators should be
-used.
-
-Changing the previous example to use ``register_local_exception_translator``
-would mean that when invalid_argument is thrown in the module2 code, the
-module2 translator will always handle it, while in module1, the module1
-translator will do the same.
-
-.. _handling_python_exceptions_cpp:
-
-Handling exceptions from Python in C++
-======================================
-
-When C++ calls Python functions, such as in a callback function or when
-manipulating Python objects, and Python raises an ``Exception``, pybind11
-converts the Python exception into a C++ exception of type
-:class:`pybind11::error_already_set` whose payload contains a C++ string textual
-summary and the actual Python exception. ``error_already_set`` is used to
-propagate Python exception back to Python (or possibly, handle them in C++).
-
-.. tabularcolumns:: |p{0.5\textwidth}|p{0.45\textwidth}|
-
-+--------------------------------------+--------------------------------------+
-|  Exception raised in Python          |  Thrown as C++ exception type        |
-+======================================+======================================+
-| Any Python ``Exception``             | :class:`pybind11::error_already_set` |
-+--------------------------------------+--------------------------------------+
-
-For example:
-
-.. code-block:: cpp
-
-    try {
-        // open("missing.txt", "r")
-        auto file = py::module_::import("io").attr("open")("missing.txt", "r");
-        auto text = file.attr("read")();
-        file.attr("close")();
-    } catch (py::error_already_set &e) {
-        if (e.matches(PyExc_FileNotFoundError)) {
-            py::print("missing.txt not found");
-        } else if (e.matches(PyExc_PermissionError)) {
-            py::print("missing.txt found but not accessible");
-        } else {
-            throw;
-        }
-    }
-
-Note that C++ to Python exception translation does not apply here, since that is
-a method for translating C++ exceptions to Python, not vice versa. The error raised
-from Python is always ``error_already_set``.
-
-This example illustrates this behavior:
-
-.. code-block:: cpp
-
-    try {
-        py::eval("raise ValueError('The Ring')");
-    } catch (py::value_error &boromir) {
-        // Boromir never gets the ring
-        assert(false);
-    } catch (py::error_already_set &frodo) {
-        // Frodo gets the ring
-        py::print("I will take the ring");
-    }
-
-    try {
-        // py::value_error is a request for pybind11 to raise a Python exception
-        throw py::value_error("The ball");
-    } catch (py::error_already_set &cat) {
-        // cat won't catch the ball since
-        // py::value_error is not a Python exception
-        assert(false);
-    } catch (py::value_error &dog) {
-        // dog will catch the ball
-        py::print("Run Spot run");
-        throw;  // Throw it again (pybind11 will raise ValueError)
-    }
-
-Handling errors from the Python C API
-=====================================
-
-Where possible, use :ref:`pybind11 wrappers <wrappers>` instead of calling
-the Python C API directly. When calling the Python C API directly, in
-addition to manually managing reference counts, one must follow the pybind11
-error protocol, which is outlined here.
-
-After calling the Python C API, if Python returns an error,
-``throw py::error_already_set();``, which allows pybind11 to deal with the
-exception and pass it back to the Python interpreter. This includes calls to
-the error setting functions such as ``PyErr_SetString``.
-
-.. code-block:: cpp
-
-    PyErr_SetString(PyExc_TypeError, "C API type error demo");
-    throw py::error_already_set();
-
-    // But it would be easier to simply...
-    throw py::type_error("pybind11 wrapper type error");
-
-Alternately, to ignore the error, call `PyErr_Clear
-<https://docs.python.org/3/c-api/exceptions.html#c.PyErr_Clear>`_.
-
-Any Python error must be thrown or cleared, or Python/pybind11 will be left in
-an invalid state.
-
-Chaining exceptions ('raise from')
-==================================
-
-Python has a mechanism for indicating that exceptions were caused by other
-exceptions:
-
-.. code-block:: py
-
-    try:
-        print(1 / 0)
-    except Exception as exc:
-        raise RuntimeError("could not divide by zero") from exc
-
-To do a similar thing in pybind11, you can use the ``py::raise_from`` function. It
-sets the current python error indicator, so to continue propagating the exception
-you should ``throw py::error_already_set()``.
-
-.. code-block:: cpp
-
-    try {
-        py::eval("print(1 / 0"));
-    } catch (py::error_already_set &e) {
-        py::raise_from(e, PyExc_RuntimeError, "could not divide by zero");
-        throw py::error_already_set();
-    }
-
-.. versionadded:: 2.8
-
-.. _unraisable_exceptions:
-
-Handling unraisable exceptions
-==============================
-
-If a Python function invoked from a C++ destructor or any function marked
-``noexcept(true)`` (collectively, "noexcept functions") throws an exception, there
-is no way to propagate the exception, as such functions may not throw.
-Should they throw or fail to catch any exceptions in their call graph,
-the C++ runtime calls ``std::terminate()`` to abort immediately.
-
-Similarly, Python exceptions raised in a class's ``__del__`` method do not
-propagate, but are logged by Python as an unraisable error. In Python 3.8+, a
-`system hook is triggered
-<https://docs.python.org/3/library/sys.html#sys.unraisablehook>`_
-and an auditing event is logged.
-
-Any noexcept function should have a try-catch block that traps
-class:`error_already_set` (or any other exception that can occur). Note that
-pybind11 wrappers around Python exceptions such as
-:class:`pybind11::value_error` are *not* Python exceptions; they are C++
-exceptions that pybind11 catches and converts to Python exceptions. Noexcept
-functions cannot propagate these exceptions either. A useful approach is to
-convert them to Python exceptions and then ``discard_as_unraisable`` as shown
-below.
-
-.. code-block:: cpp
-
-    void nonthrowing_func() noexcept(true) {
-        try {
-            // ...
-        } catch (py::error_already_set &eas) {
-            // Discard the Python error using Python APIs, using the C++ magic
-            // variable __func__. Python already knows the type and value and of the
-            // exception object.
-            eas.discard_as_unraisable(__func__);
-        } catch (const std::exception &e) {
-            // Log and discard C++ exceptions.
-            third_party::log(e);
-        }
-    }
-
-.. versionadded:: 2.6
--- a/libs/pybind/docs/advanced/functions.rst
+++ b/libs/pybind/docs/advanced/functions.rst
@ -1,614 +0,0 @@
-Functions
-#########
-
-Before proceeding with this section, make sure that you are already familiar
-with the basics of binding functions and classes, as explained in :doc:`/basics`
-and :doc:`/classes`. The following guide is applicable to both free and member
-functions, i.e. *methods* in Python.
-
-.. _return_value_policies:
-
-Return value policies
-=====================
-
-Python and C++ use fundamentally different ways of managing the memory and
-lifetime of objects managed by them. This can lead to issues when creating
-bindings for functions that return a non-trivial type. Just by looking at the
-type information, it is not clear whether Python should take charge of the
-returned value and eventually free its resources, or if this is handled on the
-C++ side. For this reason, pybind11 provides a several *return value policy*
-annotations that can be passed to the :func:`module_::def` and
-:func:`class_::def` functions. The default policy is
-:enum:`return_value_policy::automatic`.
-
-Return value policies are tricky, and it's very important to get them right.
-Just to illustrate what can go wrong, consider the following simple example:
-
-.. code-block:: cpp
-
-    /* Function declaration */
-    Data *get_data() { return _data; /* (pointer to a static data structure) */ }
-    ...
-
-    /* Binding code */
-    m.def("get_data", &get_data); // <-- KABOOM, will cause crash when called from Python
-
-What's going on here? When ``get_data()`` is called from Python, the return
-value (a native C++ type) must be wrapped to turn it into a usable Python type.
-In this case, the default return value policy (:enum:`return_value_policy::automatic`)
-causes pybind11 to assume ownership of the static ``_data`` instance.
-
-When Python's garbage collector eventually deletes the Python
-wrapper, pybind11 will also attempt to delete the C++ instance (via ``operator
-delete()``) due to the implied ownership. At this point, the entire application
-will come crashing down, though errors could also be more subtle and involve
-silent data corruption.
-
-In the above example, the policy :enum:`return_value_policy::reference` should have
-been specified so that the global data instance is only *referenced* without any
-implied transfer of ownership, i.e.:
-
-.. code-block:: cpp
-
-    m.def("get_data", &get_data, py::return_value_policy::reference);
-
-On the other hand, this is not the right policy for many other situations,
-where ignoring ownership could lead to resource leaks.
-As a developer using pybind11, it's important to be familiar with the different
-return value policies, including which situation calls for which one of them.
-The following table provides an overview of available policies:
-
-.. tabularcolumns:: |p{0.5\textwidth}|p{0.45\textwidth}|
-
-+--------------------------------------------------+----------------------------------------------------------------------------+
-| Return value policy                              | Description                                                                |
-+==================================================+============================================================================+
-| :enum:`return_value_policy::take_ownership`      | Reference an existing object (i.e. do not create a new copy) and take      |
-|                                                  | ownership. Python will call the destructor and delete operator when the    |
-|                                                  | object's reference count reaches zero. Undefined behavior ensues when the  |
-|                                                  | C++ side does the same, or when the data was not dynamically allocated.    |
-+--------------------------------------------------+----------------------------------------------------------------------------+
-| :enum:`return_value_policy::copy`                | Create a new copy of the returned object, which will be owned by Python.   |
-|                                                  | This policy is comparably safe because the lifetimes of the two instances  |
-|                                                  | are decoupled.                                                             |
-+--------------------------------------------------+----------------------------------------------------------------------------+
-| :enum:`return_value_policy::move`                | Use ``std::move`` to move the return value contents into a new instance    |
-|                                                  | that will be owned by Python. This policy is comparably safe because the   |
-|                                                  | lifetimes of the two instances (move source and destination) are decoupled.|
-+--------------------------------------------------+----------------------------------------------------------------------------+
-| :enum:`return_value_policy::reference`           | Reference an existing object, but do not take ownership. The C++ side is   |
-|                                                  | responsible for managing the object's lifetime and deallocating it when    |
-|                                                  | it is no longer used. Warning: undefined behavior will ensue when the C++  |
-|                                                  | side deletes an object that is still referenced and used by Python.        |
-+--------------------------------------------------+----------------------------------------------------------------------------+
-| :enum:`return_value_policy::reference_internal`  | Indicates that the lifetime of the return value is tied to the lifetime    |
-|                                                  | of a parent object, namely the implicit ``this``, or ``self`` argument of  |
-|                                                  | the called method or property. Internally, this policy works just like     |
-|                                                  | :enum:`return_value_policy::reference` but additionally applies a          |
-|                                                  | ``keep_alive<0, 1>`` *call policy* (described in the next section) that    |
-|                                                  | prevents the parent object from being garbage collected as long as the     |
-|                                                  | return value is referenced by Python. This is the default policy for       |
-|                                                  | property getters created via ``def_property``, ``def_readwrite``, etc.     |
-+--------------------------------------------------+----------------------------------------------------------------------------+
-| :enum:`return_value_policy::automatic`           | This policy falls back to the policy                                       |
-|                                                  | :enum:`return_value_policy::take_ownership` when the return value is a     |
-|                                                  | pointer. Otherwise, it uses :enum:`return_value_policy::move` or           |
-|                                                  | :enum:`return_value_policy::copy` for rvalue and lvalue references,        |
-|                                                  | respectively. See above for a description of what all of these different   |
-|                                                  | policies do. This is the default policy for ``py::class_``-wrapped types.  |
-+--------------------------------------------------+----------------------------------------------------------------------------+
-| :enum:`return_value_policy::automatic_reference` | As above, but use policy :enum:`return_value_policy::reference` when the   |
-|                                                  | return value is a pointer. This is the default conversion policy for       |
-|                                                  | function arguments when calling Python functions manually from C++ code    |
-|                                                  | (i.e. via ``handle::operator()``) and the casters in ``pybind11/stl.h``.   |
-|                                                  | You probably won't need to use this explicitly.                            |
-+--------------------------------------------------+----------------------------------------------------------------------------+
-
-Return value policies can also be applied to properties:
-
-.. code-block:: cpp
-
-    class_<MyClass>(m, "MyClass")
-        .def_property("data", &MyClass::getData, &MyClass::setData,
-                      py::return_value_policy::copy);
-
-Technically, the code above applies the policy to both the getter and the
-setter function, however, the setter doesn't really care about *return*
-value policies which makes this a convenient terse syntax. Alternatively,
-targeted arguments can be passed through the :class:`cpp_function` constructor:
-
-.. code-block:: cpp
-
-    class_<MyClass>(m, "MyClass")
-        .def_property("data",
-            py::cpp_function(&MyClass::getData, py::return_value_policy::copy),
-            py::cpp_function(&MyClass::setData)
-        );
-
-.. warning::
-
-    Code with invalid return value policies might access uninitialized memory or
-    free data structures multiple times, which can lead to hard-to-debug
-    non-determinism and segmentation faults, hence it is worth spending the
-    time to understand all the different options in the table above.
-
-.. note::
-
-    One important aspect of the above policies is that they only apply to
-    instances which pybind11 has *not* seen before, in which case the policy
-    clarifies essential questions about the return value's lifetime and
-    ownership.  When pybind11 knows the instance already (as identified by its
-    type and address in memory), it will return the existing Python object
-    wrapper rather than creating a new copy.
-
-.. note::
-
-    The next section on :ref:`call_policies` discusses *call policies* that can be
-    specified *in addition* to a return value policy from the list above. Call
-    policies indicate reference relationships that can involve both return values
-    and parameters of functions.
-
-.. note::
-
-   As an alternative to elaborate call policies and lifetime management logic,
-   consider using smart pointers (see the section on :ref:`smart_pointers` for
-   details). Smart pointers can tell whether an object is still referenced from
-   C++ or Python, which generally eliminates the kinds of inconsistencies that
-   can lead to crashes or undefined behavior. For functions returning smart
-   pointers, it is not necessary to specify a return value policy.
-
-.. _call_policies:
-
-Additional call policies
-========================
-
-In addition to the above return value policies, further *call policies* can be
-specified to indicate dependencies between parameters or ensure a certain state
-for the function call.
-
-Keep alive
----------
-
-In general, this policy is required when the C++ object is any kind of container
-and another object is being added to the container. ``keep_alive<Nurse, Patient>``
-indicates that the argument with index ``Patient`` should be kept alive at least
-until the argument with index ``Nurse`` is freed by the garbage collector. Argument
-indices start at one, while zero refers to the return value. For methods, index
-``1`` refers to the implicit ``this`` pointer, while regular arguments begin at
-index ``2``. Arbitrarily many call policies can be specified. When a ``Nurse``
-with value ``None`` is detected at runtime, the call policy does nothing.
-
-When the nurse is not a pybind11-registered type, the implementation internally
-relies on the ability to create a *weak reference* to the nurse object. When
-the nurse object is not a pybind11-registered type and does not support weak
-references, an exception will be thrown.
-
-If you use an incorrect argument index, you will get a ``RuntimeError`` saying
-``Could not activate keep_alive!``. You should review the indices you're using.
-
-Consider the following example: here, the binding code for a list append
-operation ties the lifetime of the newly added element to the underlying
-container:
-
-.. code-block:: cpp
-
-    py::class_<List>(m, "List")
-        .def("append", &List::append, py::keep_alive<1, 2>());
-
-For consistency, the argument indexing is identical for constructors. Index
-``1`` still refers to the implicit ``this`` pointer, i.e. the object which is
-being constructed. Index ``0`` refers to the return type which is presumed to
-be ``void`` when a constructor is viewed like a function. The following example
-ties the lifetime of the constructor element to the constructed object:
-
-.. code-block:: cpp
-
-    py::class_<Nurse>(m, "Nurse")
-        .def(py::init<Patient &>(), py::keep_alive<1, 2>());
-
-.. note::
-
-    ``keep_alive`` is analogous to the ``with_custodian_and_ward`` (if Nurse,
-    Patient != 0) and ``with_custodian_and_ward_postcall`` (if Nurse/Patient ==
-    0) policies from Boost.Python.
-
-Call guard
----------
-
-The ``call_guard<T>`` policy allows any scope guard type ``T`` to be placed
-around the function call. For example, this definition:
-
-.. code-block:: cpp
-
-    m.def("foo", foo, py::call_guard<T>());
-
-is equivalent to the following pseudocode:
-
-.. code-block:: cpp
-
-    m.def("foo", [](args...) {
-        T scope_guard;
-        return foo(args...); // forwarded arguments
-    });
-
-The only requirement is that ``T`` is default-constructible, but otherwise any
-scope guard will work. This is very useful in combination with ``gil_scoped_release``.
-See :ref:`gil`.
-
-Multiple guards can also be specified as ``py::call_guard<T1, T2, T3...>``. The
-constructor order is left to right and destruction happens in reverse.
-
-.. seealso::
-
-    The file :file:`tests/test_call_policies.cpp` contains a complete example
-    that demonstrates using `keep_alive` and `call_guard` in more detail.
-
-.. _python_objects_as_args:
-
-Python objects as arguments
-===========================
-
-pybind11 exposes all major Python types using thin C++ wrapper classes. These
-wrapper classes can also be used as parameters of functions in bindings, which
-makes it possible to directly work with native Python types on the C++ side.
-For instance, the following statement iterates over a Python ``dict``:
-
-.. code-block:: cpp
-
-    void print_dict(const py::dict& dict) {
-        /* Easily interact with Python types */
-        for (auto item : dict)
-            std::cout << "key=" << std::string(py::str(item.first)) << ", "
-                      << "value=" << std::string(py::str(item.second)) << std::endl;
-    }
-
-It can be exported:
-
-.. code-block:: cpp
-
-    m.def("print_dict", &print_dict);
-
-And used in Python as usual:
-
-.. code-block:: pycon
-
-    >>> print_dict({"foo": 123, "bar": "hello"})
-    key=foo, value=123
-    key=bar, value=hello
-
-For more information on using Python objects in C++, see :doc:`/advanced/pycpp/index`.
-
-Accepting \*args and \*\*kwargs
-===============================
-
-Python provides a useful mechanism to define functions that accept arbitrary
-numbers of arguments and keyword arguments:
-
-.. code-block:: python
-
-   def generic(*args, **kwargs):
-       ...  # do something with args and kwargs
-
-Such functions can also be created using pybind11:
-
-.. code-block:: cpp
-
-   void generic(py::args args, const py::kwargs& kwargs) {
-       /// .. do something with args
-       if (kwargs)
-           /// .. do something with kwargs
-   }
-
-   /// Binding code
-   m.def("generic", &generic);
-
-The class ``py::args`` derives from ``py::tuple`` and ``py::kwargs`` derives
-from ``py::dict``.
-
-You may also use just one or the other, and may combine these with other
-arguments.  Note, however, that ``py::kwargs`` must always be the last argument
-of the function, and ``py::args`` implies that any further arguments are
-keyword-only (see :ref:`keyword_only_arguments`).
-
-Please refer to the other examples for details on how to iterate over these,
-and on how to cast their entries into C++ objects. A demonstration is also
-available in ``tests/test_kwargs_and_defaults.cpp``.
-
-.. note::
-
-    When combining \*args or \*\*kwargs with :ref:`keyword_args` you should
-    *not* include ``py::arg`` tags for the ``py::args`` and ``py::kwargs``
-    arguments.
-
-Default arguments revisited
-===========================
-
-The section on :ref:`default_args` previously discussed basic usage of default
-arguments using pybind11. One noteworthy aspect of their implementation is that
-default arguments are converted to Python objects right at declaration time.
-Consider the following example:
-
-.. code-block:: cpp
-
-    py::class_<MyClass>("MyClass")
-        .def("myFunction", py::arg("arg") = SomeType(123));
-
-In this case, pybind11 must already be set up to deal with values of the type
-``SomeType`` (via a prior instantiation of ``py::class_<SomeType>``), or an
-exception will be thrown.
-
-Another aspect worth highlighting is that the "preview" of the default argument
-in the function signature is generated using the object's ``__repr__`` method.
-If not available, the signature may not be very helpful, e.g.:
-
-.. code-block:: pycon
-
-    FUNCTIONS
-    ...
-    |  myFunction(...)
-    |      Signature : (MyClass, arg : SomeType = <SomeType object at 0x101b7b080>) -> NoneType
-    ...
-
-The first way of addressing this is by defining ``SomeType.__repr__``.
-Alternatively, it is possible to specify the human-readable preview of the
-default argument manually using the ``arg_v`` notation:
-
-.. code-block:: cpp
-
-    py::class_<MyClass>("MyClass")
-        .def("myFunction", py::arg_v("arg", SomeType(123), "SomeType(123)"));
-
-Sometimes it may be necessary to pass a null pointer value as a default
-argument. In this case, remember to cast it to the underlying type in question,
-like so:
-
-.. code-block:: cpp
-
-    py::class_<MyClass>("MyClass")
-        .def("myFunction", py::arg("arg") = static_cast<SomeType *>(nullptr));
-
-.. _keyword_only_arguments:
-
-Keyword-only arguments
-======================
-
-Python implements keyword-only arguments by specifying an unnamed ``*``
-argument in a function definition:
-
-.. code-block:: python
-
-    def f(a, *, b):  # a can be positional or via keyword; b must be via keyword
-        pass
-
-
-    f(a=1, b=2)  # good
-    f(b=2, a=1)  # good
-    f(1, b=2)  # good
-    f(1, 2)  # TypeError: f() takes 1 positional argument but 2 were given
-
-Pybind11 provides a ``py::kw_only`` object that allows you to implement
-the same behaviour by specifying the object between positional and keyword-only
-argument annotations when registering the function:
-
-.. code-block:: cpp
-
-    m.def("f", [](int a, int b) { /* ... */ },
-          py::arg("a"), py::kw_only(), py::arg("b"));
-
-.. versionadded:: 2.6
-
-A ``py::args`` argument implies that any following arguments are keyword-only,
-as if ``py::kw_only()`` had been specified in the same relative location of the
-argument list as the ``py::args`` argument.  The ``py::kw_only()`` may be
-included to be explicit about this, but is not required.
-
-.. versionchanged:: 2.9
-   This can now be combined with ``py::args``. Before, ``py::args`` could only
-   occur at the end of the argument list, or immediately before a ``py::kwargs``
-   argument at the end.
-
-
-Positional-only arguments
-=========================
-
-Python 3.8 introduced a new positional-only argument syntax, using ``/`` in the
-function definition (note that this has been a convention for CPython
-positional arguments, such as in ``pow()``, since Python 2). You can
-do the same thing in any version of Python using ``py::pos_only()``:
-
-.. code-block:: cpp
-
-   m.def("f", [](int a, int b) { /* ... */ },
-          py::arg("a"), py::pos_only(), py::arg("b"));
-
-You now cannot give argument ``a`` by keyword. This can be combined with
-keyword-only arguments, as well.
-
-.. versionadded:: 2.6
-
-.. _nonconverting_arguments:
-
-Non-converting arguments
-========================
-
-Certain argument types may support conversion from one type to another.  Some
-examples of conversions are:
-
-* :ref:`implicit_conversions` declared using ``py::implicitly_convertible<A,B>()``
-* Calling a method accepting a double with an integer argument
-* Calling a ``std::complex<float>`` argument with a non-complex python type
-  (for example, with a float).  (Requires the optional ``pybind11/complex.h``
-  header).
-* Calling a function taking an Eigen matrix reference with a numpy array of the
-  wrong type or of an incompatible data layout.  (Requires the optional
-  ``pybind11/eigen.h`` header).
-
-This behaviour is sometimes undesirable: the binding code may prefer to raise
-an error rather than convert the argument.  This behaviour can be obtained
-through ``py::arg`` by calling the ``.noconvert()`` method of the ``py::arg``
-object, such as:
-
-.. code-block:: cpp
-
-    m.def("floats_only", [](double f) { return 0.5 * f; }, py::arg("f").noconvert());
-    m.def("floats_preferred", [](double f) { return 0.5 * f; }, py::arg("f"));
-
-Attempting the call the second function (the one without ``.noconvert()``) with
-an integer will succeed, but attempting to call the ``.noconvert()`` version
-will fail with a ``TypeError``:
-
-.. code-block:: pycon
-
-    >>> floats_preferred(4)
-    2.0
-    >>> floats_only(4)
-    Traceback (most recent call last):
-      File "<stdin>", line 1, in <module>
-    TypeError: floats_only(): incompatible function arguments. The following argument types are supported:
-        1. (f: float) -> float
-
-    Invoked with: 4
-
-You may, of course, combine this with the :var:`_a` shorthand notation (see
-:ref:`keyword_args`) and/or :ref:`default_args`.  It is also permitted to omit
-the argument name by using the ``py::arg()`` constructor without an argument
-name, i.e. by specifying ``py::arg().noconvert()``.
-
-.. note::
-
-    When specifying ``py::arg`` options it is necessary to provide the same
-    number of options as the bound function has arguments.  Thus if you want to
-    enable no-convert behaviour for just one of several arguments, you will
-    need to specify a ``py::arg()`` annotation for each argument with the
-    no-convert argument modified to ``py::arg().noconvert()``.
-
-.. _none_arguments:
-
-Allow/Prohibiting None arguments
-================================
-
-When a C++ type registered with :class:`py::class_` is passed as an argument to
-a function taking the instance as pointer or shared holder (e.g. ``shared_ptr``
-or a custom, copyable holder as described in :ref:`smart_pointers`), pybind
-allows ``None`` to be passed from Python which results in calling the C++
-function with ``nullptr`` (or an empty holder) for the argument.
-
-To explicitly enable or disable this behaviour, using the
-``.none`` method of the :class:`py::arg` object:
-
-.. code-block:: cpp
-
-    py::class_<Dog>(m, "Dog").def(py::init<>());
-    py::class_<Cat>(m, "Cat").def(py::init<>());
-    m.def("bark", [](Dog *dog) -> std::string {
-        if (dog) return "woof!"; /* Called with a Dog instance */
-        else return "(no dog)"; /* Called with None, dog == nullptr */
-    }, py::arg("dog").none(true));
-    m.def("meow", [](Cat *cat) -> std::string {
-        // Can't be called with None argument
-        return "meow";
-    }, py::arg("cat").none(false));
-
-With the above, the Python call ``bark(None)`` will return the string ``"(no
-dog)"``, while attempting to call ``meow(None)`` will raise a ``TypeError``:
-
-.. code-block:: pycon
-
-    >>> from animals import Dog, Cat, bark, meow
-    >>> bark(Dog())
-    'woof!'
-    >>> meow(Cat())
-    'meow'
-    >>> bark(None)
-    '(no dog)'
-    >>> meow(None)
-    Traceback (most recent call last):
-      File "<stdin>", line 1, in <module>
-    TypeError: meow(): incompatible function arguments. The following argument types are supported:
-        1. (cat: animals.Cat) -> str
-
-    Invoked with: None
-
-The default behaviour when the tag is unspecified is to allow ``None``.
-
-.. note::
-
-    Even when ``.none(true)`` is specified for an argument, ``None`` will be converted to a
-    ``nullptr`` *only* for custom and :ref:`opaque <opaque>` types. Pointers to built-in types
-    (``double *``, ``int *``, ...) and STL types (``std::vector<T> *``, ...; if ``pybind11/stl.h``
-    is included) are copied when converted to C++ (see :doc:`/advanced/cast/overview`) and will
-    not allow ``None`` as argument.  To pass optional argument of these copied types consider
-    using ``std::optional<T>``
-
-.. _overload_resolution:
-
-Overload resolution order
-=========================
-
-When a function or method with multiple overloads is called from Python,
-pybind11 determines which overload to call in two passes.  The first pass
-attempts to call each overload without allowing argument conversion (as if
-every argument had been specified as ``py::arg().noconvert()`` as described
-above).
-
-If no overload succeeds in the no-conversion first pass, a second pass is
-attempted in which argument conversion is allowed (except where prohibited via
-an explicit ``py::arg().noconvert()`` attribute in the function definition).
-
-If the second pass also fails a ``TypeError`` is raised.
-
-Within each pass, overloads are tried in the order they were registered with
-pybind11. If the ``py::prepend()`` tag is added to the definition, a function
-can be placed at the beginning of the overload sequence instead, allowing user
-overloads to proceed built in functions.
-
-What this means in practice is that pybind11 will prefer any overload that does
-not require conversion of arguments to an overload that does, but otherwise
-prefers earlier-defined overloads to later-defined ones.
-
-.. note::
-
-    pybind11 does *not* further prioritize based on the number/pattern of
-    overloaded arguments.  That is, pybind11 does not prioritize a function
-    requiring one conversion over one requiring three, but only prioritizes
-    overloads requiring no conversion at all to overloads that require
-    conversion of at least one argument.
-
-.. versionadded:: 2.6
-
-    The ``py::prepend()`` tag.
-
-Binding functions with template parameters
-==========================================
-
-You can bind functions that have template parameters. Here's a function:
-
-.. code-block:: cpp
-
-    template <typename T>
-    void set(T t);
-
-C++ templates cannot be instantiated at runtime, so you cannot bind the
-non-instantiated function:
-
-.. code-block:: cpp
-
-    // BROKEN (this will not compile)
-    m.def("set", &set);
-
-You must bind each instantiated function template separately. You may bind
-each instantiation with the same name, which will be treated the same as
-an overloaded function:
-
-.. code-block:: cpp
-
-    m.def("set", &set<int>);
-    m.def("set", &set<std::string>);
-
-Sometimes it's more clear to bind them with separate names, which is also
-an option:
-
-.. code-block:: cpp
-
-    m.def("setInt", &set<int>);
-    m.def("setString", &set<std::string>);
--- a/libs/pybind/docs/advanced/misc.rst
+++ b/libs/pybind/docs/advanced/misc.rst
@ -1,337 +0,0 @@
-Miscellaneous
-#############
-
-.. _macro_notes:
-
-General notes regarding convenience macros
-==========================================
-
-pybind11 provides a few convenience macros such as
-:func:`PYBIND11_DECLARE_HOLDER_TYPE` and ``PYBIND11_OVERRIDE_*``. Since these
-are "just" macros that are evaluated in the preprocessor (which has no concept
-of types), they *will* get confused by commas in a template argument; for
-example, consider:
-
-.. code-block:: cpp
-
-    PYBIND11_OVERRIDE(MyReturnType<T1, T2>, Class<T3, T4>, func)
-
-The limitation of the C preprocessor interprets this as five arguments (with new
-arguments beginning after each comma) rather than three.  To get around this,
-there are two alternatives: you can use a type alias, or you can wrap the type
-using the ``PYBIND11_TYPE`` macro:
-
-.. code-block:: cpp
-
-    // Version 1: using a type alias
-    using ReturnType = MyReturnType<T1, T2>;
-    using ClassType = Class<T3, T4>;
-    PYBIND11_OVERRIDE(ReturnType, ClassType, func);
-
-    // Version 2: using the PYBIND11_TYPE macro:
-    PYBIND11_OVERRIDE(PYBIND11_TYPE(MyReturnType<T1, T2>),
-                      PYBIND11_TYPE(Class<T3, T4>), func)
-
-The ``PYBIND11_MAKE_OPAQUE`` macro does *not* require the above workarounds.
-
-.. _gil:
-
-Global Interpreter Lock (GIL)
-=============================
-
-When calling a C++ function from Python, the GIL is always held.
-The classes :class:`gil_scoped_release` and :class:`gil_scoped_acquire` can be
-used to acquire and release the global interpreter lock in the body of a C++
-function call. In this way, long-running C++ code can be parallelized using
-multiple Python threads. Taking :ref:`overriding_virtuals` as an example, this
-could be realized as follows (important changes highlighted):
-
-.. code-block:: cpp
-    :emphasize-lines: 8,9,31,32
-
-    class PyAnimal : public Animal {
-    public:
-        /* Inherit the constructors */
-        using Animal::Animal;
-
-        /* Trampoline (need one for each virtual function) */
-        std::string go(int n_times) {
-            /* Acquire GIL before calling Python code */
-            py::gil_scoped_acquire acquire;
-
-            PYBIND11_OVERRIDE_PURE(
-                std::string, /* Return type */
-                Animal,      /* Parent class */
-                go,          /* Name of function */
-                n_times      /* Argument(s) */
-            );
-        }
-    };
-
-    PYBIND11_MODULE(example, m) {
-        py::class_<Animal, PyAnimal> animal(m, "Animal");
-        animal
-            .def(py::init<>())
-            .def("go", &Animal::go);
-
-        py::class_<Dog>(m, "Dog", animal)
-            .def(py::init<>());
-
-        m.def("call_go", [](Animal *animal) -> std::string {
-            /* Release GIL before calling into (potentially long-running) C++ code */
-            py::gil_scoped_release release;
-            return call_go(animal);
-        });
-    }
-
-The ``call_go`` wrapper can also be simplified using the ``call_guard`` policy
-(see :ref:`call_policies`) which yields the same result:
-
-.. code-block:: cpp
-
-    m.def("call_go", &call_go, py::call_guard<py::gil_scoped_release>());
-
-
-Binding sequence data types, iterators, the slicing protocol, etc.
-==================================================================
-
-Please refer to the supplemental example for details.
-
-.. seealso::
-
-    The file :file:`tests/test_sequences_and_iterators.cpp` contains a
-    complete example that shows how to bind a sequence data type, including
-    length queries (``__len__``), iterators (``__iter__``), the slicing
-    protocol and other kinds of useful operations.
-
-
-Partitioning code over multiple extension modules
-=================================================
-
-It's straightforward to split binding code over multiple extension modules,
-while referencing types that are declared elsewhere. Everything "just" works
-without any special precautions. One exception to this rule occurs when
-extending a type declared in another extension module. Recall the basic example
-from Section :ref:`inheritance`.
-
-.. code-block:: cpp
-
-    py::class_<Pet> pet(m, "Pet");
-    pet.def(py::init<const std::string &>())
-       .def_readwrite("name", &Pet::name);
-
-    py::class_<Dog>(m, "Dog", pet /* <- specify parent */)
-        .def(py::init<const std::string &>())
-        .def("bark", &Dog::bark);
-
-Suppose now that ``Pet`` bindings are defined in a module named ``basic``,
-whereas the ``Dog`` bindings are defined somewhere else. The challenge is of
-course that the variable ``pet`` is not available anymore though it is needed
-to indicate the inheritance relationship to the constructor of ``class_<Dog>``.
-However, it can be acquired as follows:
-
-.. code-block:: cpp
-
-    py::object pet = (py::object) py::module_::import("basic").attr("Pet");
-
-    py::class_<Dog>(m, "Dog", pet)
-        .def(py::init<const std::string &>())
-        .def("bark", &Dog::bark);
-
-Alternatively, you can specify the base class as a template parameter option to
-``class_``, which performs an automated lookup of the corresponding Python
-type. Like the above code, however, this also requires invoking the ``import``
-function once to ensure that the pybind11 binding code of the module ``basic``
-has been executed:
-
-.. code-block:: cpp
-
-    py::module_::import("basic");
-
-    py::class_<Dog, Pet>(m, "Dog")
-        .def(py::init<const std::string &>())
-        .def("bark", &Dog::bark);
-
-Naturally, both methods will fail when there are cyclic dependencies.
-
-Note that pybind11 code compiled with hidden-by-default symbol visibility (e.g.
-via the command line flag ``-fvisibility=hidden`` on GCC/Clang), which is
-required for proper pybind11 functionality, can interfere with the ability to
-access types defined in another extension module.  Working around this requires
-manually exporting types that are accessed by multiple extension modules;
-pybind11 provides a macro to do just this:
-
-.. code-block:: cpp
-
-    class PYBIND11_EXPORT Dog : public Animal {
-        ...
-    };
-
-Note also that it is possible (although would rarely be required) to share arbitrary
-C++ objects between extension modules at runtime. Internal library data is shared
-between modules using capsule machinery [#f6]_ which can be also utilized for
-storing, modifying and accessing user-defined data. Note that an extension module
-will "see" other extensions' data if and only if they were built with the same
-pybind11 version. Consider the following example:
-
-.. code-block:: cpp
-
-    auto data = reinterpret_cast<MyData *>(py::get_shared_data("mydata"));
-    if (!data)
-        data = static_cast<MyData *>(py::set_shared_data("mydata", new MyData(42)));
-
-If the above snippet was used in several separately compiled extension modules,
-the first one to be imported would create a ``MyData`` instance and associate
-a ``"mydata"`` key with a pointer to it. Extensions that are imported later
-would be then able to access the data behind the same pointer.
-
-.. [#f6] https://docs.python.org/3/extending/extending.html#using-capsules
-
-Module Destructors
-==================
-
-pybind11 does not provide an explicit mechanism to invoke cleanup code at
-module destruction time. In rare cases where such functionality is required, it
-is possible to emulate it using Python capsules or weak references with a
-destruction callback.
-
-.. code-block:: cpp
-
-    auto cleanup_callback = []() {
-        // perform cleanup here -- this function is called with the GIL held
-    };
-
-    m.add_object("_cleanup", py::capsule(cleanup_callback));
-
-This approach has the potential downside that instances of classes exposed
-within the module may still be alive when the cleanup callback is invoked
-(whether this is acceptable will generally depend on the application).
-
-Alternatively, the capsule may also be stashed within a type object, which
-ensures that it not called before all instances of that type have been
-collected:
-
-.. code-block:: cpp
-
-    auto cleanup_callback = []() { /* ... */ };
-    m.attr("BaseClass").attr("_cleanup") = py::capsule(cleanup_callback);
-
-Both approaches also expose a potentially dangerous ``_cleanup`` attribute in
-Python, which may be undesirable from an API standpoint (a premature explicit
-call from Python might lead to undefined behavior). Yet another approach that
-avoids this issue involves weak reference with a cleanup callback:
-
-.. code-block:: cpp
-
-    // Register a callback function that is invoked when the BaseClass object is collected
-    py::cpp_function cleanup_callback(
-        [](py::handle weakref) {
-            // perform cleanup here -- this function is called with the GIL held
-
-            weakref.dec_ref(); // release weak reference
-        }
-    );
-
-    // Create a weak reference with a cleanup callback and initially leak it
-    (void) py::weakref(m.attr("BaseClass"), cleanup_callback).release();
-
-.. note::
-
-    PyPy does not garbage collect objects when the interpreter exits. An alternative
-    approach (which also works on CPython) is to use the :py:mod:`atexit` module [#f7]_,
-    for example:
-
-    .. code-block:: cpp
-
-        auto atexit = py::module_::import("atexit");
-        atexit.attr("register")(py::cpp_function([]() {
-            // perform cleanup here -- this function is called with the GIL held
-        }));
-
-    .. [#f7] https://docs.python.org/3/library/atexit.html
-
-
-Generating documentation using Sphinx
-=====================================
-
-Sphinx [#f4]_ has the ability to inspect the signatures and documentation
-strings in pybind11-based extension modules to automatically generate beautiful
-documentation in a variety formats. The python_example repository [#f5]_ contains a
-simple example repository which uses this approach.
-
-There are two potential gotchas when using this approach: first, make sure that
-the resulting strings do not contain any :kbd:`TAB` characters, which break the
-docstring parsing routines. You may want to use C++11 raw string literals,
-which are convenient for multi-line comments. Conveniently, any excess
-indentation will be automatically be removed by Sphinx. However, for this to
-work, it is important that all lines are indented consistently, i.e.:
-
-.. code-block:: cpp
-
-    // ok
-    m.def("foo", &foo, R"mydelimiter(
-        The foo function
-
-        Parameters
-        ----------
-    )mydelimiter");
-
-    // *not ok*
-    m.def("foo", &foo, R"mydelimiter(The foo function
-
-        Parameters
-        ----------
-    )mydelimiter");
-
-By default, pybind11 automatically generates and prepends a signature to the docstring of a function
-registered with ``module_::def()`` and ``class_::def()``. Sometimes this
-behavior is not desirable, because you want to provide your own signature or remove
-the docstring completely to exclude the function from the Sphinx documentation.
-The class ``options`` allows you to selectively suppress auto-generated signatures:
-
-.. code-block:: cpp
-
-    PYBIND11_MODULE(example, m) {
-        py::options options;
-        options.disable_function_signatures();
-
-        m.def("add", [](int a, int b) { return a + b; }, "A function which adds two numbers");
-    }
-
-Note that changes to the settings affect only function bindings created during the
-lifetime of the ``options`` instance. When it goes out of scope at the end of the module's init function,
-the default settings are restored to prevent unwanted side effects.
-
-.. [#f4] http://www.sphinx-doc.org
-.. [#f5] http://github.com/pybind/python_example
-
-.. _avoiding-cpp-types-in-docstrings:
-
-Avoiding C++ types in docstrings
-================================
-
-Docstrings are generated at the time of the declaration, e.g. when ``.def(...)`` is called.
-At this point parameter and return types should be known to pybind11.
-If a custom type is not exposed yet through a ``py::class_`` constructor or a custom type caster,
-its C++ type name will be used instead to generate the signature in the docstring:
-
-.. code-block:: text
-
-     |  __init__(...)
-     |      __init__(self: example.Foo, arg0: ns::Bar) -> None
-                                              ^^^^^^^
-
-
-This limitation can be circumvented by ensuring that C++ classes are registered with pybind11
-before they are used as a parameter or return type of a function:
-
-.. code-block:: cpp
-
-    PYBIND11_MODULE(example, m) {
-
-        auto pyFoo = py::class_<ns::Foo>(m, "Foo");
-        auto pyBar = py::class_<ns::Bar>(m, "Bar");
-
-        pyFoo.def(py::init<const ns::Bar&>());
-        pyBar.def(py::init<const ns::Foo&>());
-    }
--- a/libs/pybind/docs/advanced/pycpp/index.rst
+++ b/libs/pybind/docs/advanced/pycpp/index.rst
@ -1,13 +0,0 @@
-Python C++ interface
-####################
-
-pybind11 exposes Python types and functions using thin C++ wrappers, which
-makes it possible to conveniently call Python code from C++ without resorting
-to Python's C API.
-
-.. toctree::
-   :maxdepth: 2
-
-   object
-   numpy
-   utilities
--- a/libs/pybind/docs/advanced/pycpp/numpy.rst
+++ b/libs/pybind/docs/advanced/pycpp/numpy.rst
@ -1,455 +0,0 @@
-.. _numpy:
-
-NumPy
-#####
-
-Buffer protocol
-===============
-
-Python supports an extremely general and convenient approach for exchanging
-data between plugin libraries. Types can expose a buffer view [#f2]_, which
-provides fast direct access to the raw internal data representation. Suppose we
-want to bind the following simplistic Matrix class:
-
-.. code-block:: cpp
-
-    class Matrix {
-    public:
-        Matrix(size_t rows, size_t cols) : m_rows(rows), m_cols(cols) {
-            m_data = new float[rows*cols];
-        }
-        float *data() { return m_data; }
-        size_t rows() const { return m_rows; }
-        size_t cols() const { return m_cols; }
-    private:
-        size_t m_rows, m_cols;
-        float *m_data;
-    };
-
-The following binding code exposes the ``Matrix`` contents as a buffer object,
-making it possible to cast Matrices into NumPy arrays. It is even possible to
-completely avoid copy operations with Python expressions like
-``np.array(matrix_instance, copy = False)``.
-
-.. code-block:: cpp
-
-    py::class_<Matrix>(m, "Matrix", py::buffer_protocol())
-       .def_buffer([](Matrix &m) -> py::buffer_info {
-            return py::buffer_info(
-                m.data(),                               /* Pointer to buffer */
-                sizeof(float),                          /* Size of one scalar */
-                py::format_descriptor<float>::format(), /* Python struct-style format descriptor */
-                2,                                      /* Number of dimensions */
-                { m.rows(), m.cols() },                 /* Buffer dimensions */
-                { sizeof(float) * m.cols(),             /* Strides (in bytes) for each index */
-                  sizeof(float) }
-            );
-        });
-
-Supporting the buffer protocol in a new type involves specifying the special
-``py::buffer_protocol()`` tag in the ``py::class_`` constructor and calling the
-``def_buffer()`` method with a lambda function that creates a
-``py::buffer_info`` description record on demand describing a given matrix
-instance. The contents of ``py::buffer_info`` mirror the Python buffer protocol
-specification.
-
-.. code-block:: cpp
-
-    struct buffer_info {
-        void *ptr;
-        py::ssize_t itemsize;
-        std::string format;
-        py::ssize_t ndim;
-        std::vector<py::ssize_t> shape;
-        std::vector<py::ssize_t> strides;
-    };
-
-To create a C++ function that can take a Python buffer object as an argument,
-simply use the type ``py::buffer`` as one of its arguments. Buffers can exist
-in a great variety of configurations, hence some safety checks are usually
-necessary in the function body. Below, you can see a basic example on how to
-define a custom constructor for the Eigen double precision matrix
-(``Eigen::MatrixXd``) type, which supports initialization from compatible
-buffer objects (e.g. a NumPy matrix).
-
-.. code-block:: cpp
-
-    /* Bind MatrixXd (or some other Eigen type) to Python */
-    typedef Eigen::MatrixXd Matrix;
-
-    typedef Matrix::Scalar Scalar;
-    constexpr bool rowMajor = Matrix::Flags & Eigen::RowMajorBit;
-
-    py::class_<Matrix>(m, "Matrix", py::buffer_protocol())
-        .def(py::init([](py::buffer b) {
-            typedef Eigen::Stride<Eigen::Dynamic, Eigen::Dynamic> Strides;
-
-            /* Request a buffer descriptor from Python */
-            py::buffer_info info = b.request();
-
-            /* Some basic validation checks ... */
-            if (info.format != py::format_descriptor<Scalar>::format())
-                throw std::runtime_error("Incompatible format: expected a double array!");
-
-            if (info.ndim != 2)
-                throw std::runtime_error("Incompatible buffer dimension!");
-
-            auto strides = Strides(
-                info.strides[rowMajor ? 0 : 1] / (py::ssize_t)sizeof(Scalar),
-                info.strides[rowMajor ? 1 : 0] / (py::ssize_t)sizeof(Scalar));
-
-            auto map = Eigen::Map<Matrix, 0, Strides>(
-                static_cast<Scalar *>(info.ptr), info.shape[0], info.shape[1], strides);
-
-            return Matrix(map);
-        }));
-
-For reference, the ``def_buffer()`` call for this Eigen data type should look
-as follows:
-
-.. code-block:: cpp
-
-    .def_buffer([](Matrix &m) -> py::buffer_info {
-        return py::buffer_info(
-            m.data(),                                /* Pointer to buffer */
-            sizeof(Scalar),                          /* Size of one scalar */
-            py::format_descriptor<Scalar>::format(), /* Python struct-style format descriptor */
-            2,                                       /* Number of dimensions */
-            { m.rows(), m.cols() },                  /* Buffer dimensions */
-            { sizeof(Scalar) * (rowMajor ? m.cols() : 1),
-              sizeof(Scalar) * (rowMajor ? 1 : m.rows()) }
-                                                     /* Strides (in bytes) for each index */
-        );
-     })
-
-For a much easier approach of binding Eigen types (although with some
-limitations), refer to the section on :doc:`/advanced/cast/eigen`.
-
-.. seealso::
-
-    The file :file:`tests/test_buffers.cpp` contains a complete example
-    that demonstrates using the buffer protocol with pybind11 in more detail.
-
-.. [#f2] http://docs.python.org/3/c-api/buffer.html
-
-Arrays
-======
-
-By exchanging ``py::buffer`` with ``py::array`` in the above snippet, we can
-restrict the function so that it only accepts NumPy arrays (rather than any
-type of Python object satisfying the buffer protocol).
-
-In many situations, we want to define a function which only accepts a NumPy
-array of a certain data type. This is possible via the ``py::array_t<T>``
-template. For instance, the following function requires the argument to be a
-NumPy array containing double precision values.
-
-.. code-block:: cpp
-
-    void f(py::array_t<double> array);
-
-When it is invoked with a different type (e.g. an integer or a list of
-integers), the binding code will attempt to cast the input into a NumPy array
-of the requested type. This feature requires the :file:`pybind11/numpy.h`
-header to be included. Note that :file:`pybind11/numpy.h` does not depend on
-the NumPy headers, and thus can be used without declaring a build-time
-dependency on NumPy; NumPy>=1.7.0 is a runtime dependency.
-
-Data in NumPy arrays is not guaranteed to packed in a dense manner;
-furthermore, entries can be separated by arbitrary column and row strides.
-Sometimes, it can be useful to require a function to only accept dense arrays
-using either the C (row-major) or Fortran (column-major) ordering. This can be
-accomplished via a second template argument with values ``py::array::c_style``
-or ``py::array::f_style``.
-
-.. code-block:: cpp
-
-    void f(py::array_t<double, py::array::c_style | py::array::forcecast> array);
-
-The ``py::array::forcecast`` argument is the default value of the second
-template parameter, and it ensures that non-conforming arguments are converted
-into an array satisfying the specified requirements instead of trying the next
-function overload.
-
-There are several methods on arrays; the methods listed below under references
-work, as well as the following functions based on the NumPy API:
-
- ``.dtype()`` returns the type of the contained values.
-
- ``.strides()`` returns a pointer to the strides of the array (optionally pass
-  an integer axis to get a number).
-
- ``.flags()`` returns the flag settings. ``.writable()`` and ``.owndata()``
-  are directly available.
-
- ``.offset_at()`` returns the offset (optionally pass indices).
-
- ``.squeeze()`` returns a view with length-1 axes removed.
-
- ``.view(dtype)`` returns a view of the array with a different dtype.
-
- ``.reshape({i, j, ...})`` returns a view of the array with a different shape.
-  ``.resize({...})`` is also available.
-
- ``.index_at(i, j, ...)`` gets the count from the beginning to a given index.
-
-
-There are also several methods for getting references (described below).
-
-Structured types
-================
-
-In order for ``py::array_t`` to work with structured (record) types, we first
-need to register the memory layout of the type. This can be done via
-``PYBIND11_NUMPY_DTYPE`` macro, called in the plugin definition code, which
-expects the type followed by field names:
-
-.. code-block:: cpp
-
-    struct A {
-        int x;
-        double y;
-    };
-
-    struct B {
-        int z;
-        A a;
-    };
-
-    // ...
-    PYBIND11_MODULE(test, m) {
-        // ...
-
-        PYBIND11_NUMPY_DTYPE(A, x, y);
-        PYBIND11_NUMPY_DTYPE(B, z, a);
-        /* now both A and B can be used as template arguments to py::array_t */
-    }
-
-The structure should consist of fundamental arithmetic types, ``std::complex``,
-previously registered substructures, and arrays of any of the above. Both C++
-arrays and ``std::array`` are supported. While there is a static assertion to
-prevent many types of unsupported structures, it is still the user's
-responsibility to use only "plain" structures that can be safely manipulated as
-raw memory without violating invariants.
-
-Vectorizing functions
-=====================
-
-Suppose we want to bind a function with the following signature to Python so
-that it can process arbitrary NumPy array arguments (vectors, matrices, general
-N-D arrays) in addition to its normal arguments:
-
-.. code-block:: cpp
-
-    double my_func(int x, float y, double z);
-
-After including the ``pybind11/numpy.h`` header, this is extremely simple:
-
-.. code-block:: cpp
-
-    m.def("vectorized_func", py::vectorize(my_func));
-
-Invoking the function like below causes 4 calls to be made to ``my_func`` with
-each of the array elements. The significant advantage of this compared to
-solutions like ``numpy.vectorize()`` is that the loop over the elements runs
-entirely on the C++ side and can be crunched down into a tight, optimized loop
-by the compiler. The result is returned as a NumPy array of type
-``numpy.dtype.float64``.
-
-.. code-block:: pycon
-
-    >>> x = np.array([[1, 3], [5, 7]])
-    >>> y = np.array([[2, 4], [6, 8]])
-    >>> z = 3
-    >>> result = vectorized_func(x, y, z)
-
-The scalar argument ``z`` is transparently replicated 4 times.  The input
-arrays ``x`` and ``y`` are automatically converted into the right types (they
-are of type  ``numpy.dtype.int64`` but need to be ``numpy.dtype.int32`` and
-``numpy.dtype.float32``, respectively).
-
-.. note::
-
-    Only arithmetic, complex, and POD types passed by value or by ``const &``
-    reference are vectorized; all other arguments are passed through as-is.
-    Functions taking rvalue reference arguments cannot be vectorized.
-
-In cases where the computation is too complicated to be reduced to
-``vectorize``, it will be necessary to create and access the buffer contents
-manually. The following snippet contains a complete example that shows how this
-works (the code is somewhat contrived, since it could have been done more
-simply using ``vectorize``).
-
-.. code-block:: cpp
-
-    #include <pybind11/pybind11.h>
-    #include <pybind11/numpy.h>
-
-    namespace py = pybind11;
-
-    py::array_t<double> add_arrays(py::array_t<double> input1, py::array_t<double> input2) {
-        py::buffer_info buf1 = input1.request(), buf2 = input2.request();
-
-        if (buf1.ndim != 1 || buf2.ndim != 1)
-            throw std::runtime_error("Number of dimensions must be one");
-
-        if (buf1.size != buf2.size)
-            throw std::runtime_error("Input shapes must match");
-
-        /* No pointer is passed, so NumPy will allocate the buffer */
-        auto result = py::array_t<double>(buf1.size);
-
-        py::buffer_info buf3 = result.request();
-
-        double *ptr1 = static_cast<double *>(buf1.ptr);
-        double *ptr2 = static_cast<double *>(buf2.ptr);
-        double *ptr3 = static_cast<double *>(buf3.ptr);
-
-        for (size_t idx = 0; idx < buf1.shape[0]; idx++)
-            ptr3[idx] = ptr1[idx] + ptr2[idx];
-
-        return result;
-    }
-
-    PYBIND11_MODULE(test, m) {
-        m.def("add_arrays", &add_arrays, "Add two NumPy arrays");
-    }
-
-.. seealso::
-
-    The file :file:`tests/test_numpy_vectorize.cpp` contains a complete
-    example that demonstrates using :func:`vectorize` in more detail.
-
-Direct access
-=============
-
-For performance reasons, particularly when dealing with very large arrays, it
-is often desirable to directly access array elements without internal checking
-of dimensions and bounds on every access when indices are known to be already
-valid.  To avoid such checks, the ``array`` class and ``array_t<T>`` template
-class offer an unchecked proxy object that can be used for this unchecked
-access through the ``unchecked<N>`` and ``mutable_unchecked<N>`` methods,
-where ``N`` gives the required dimensionality of the array:
-
-.. code-block:: cpp
-
-    m.def("sum_3d", [](py::array_t<double> x) {
-        auto r = x.unchecked<3>(); // x must have ndim = 3; can be non-writeable
-        double sum = 0;
-        for (py::ssize_t i = 0; i < r.shape(0); i++)
-            for (py::ssize_t j = 0; j < r.shape(1); j++)
-                for (py::ssize_t k = 0; k < r.shape(2); k++)
-                    sum += r(i, j, k);
-        return sum;
-    });
-    m.def("increment_3d", [](py::array_t<double> x) {
-        auto r = x.mutable_unchecked<3>(); // Will throw if ndim != 3 or flags.writeable is false
-        for (py::ssize_t i = 0; i < r.shape(0); i++)
-            for (py::ssize_t j = 0; j < r.shape(1); j++)
-                for (py::ssize_t k = 0; k < r.shape(2); k++)
-                    r(i, j, k) += 1.0;
-    }, py::arg().noconvert());
-
-To obtain the proxy from an ``array`` object, you must specify both the data
-type and number of dimensions as template arguments, such as ``auto r =
-myarray.mutable_unchecked<float, 2>()``.
-
-If the number of dimensions is not known at compile time, you can omit the
-dimensions template parameter (i.e. calling ``arr_t.unchecked()`` or
-``arr.unchecked<T>()``.  This will give you a proxy object that works in the
-same way, but results in less optimizable code and thus a small efficiency
-loss in tight loops.
-
-Note that the returned proxy object directly references the array's data, and
-only reads its shape, strides, and writeable flag when constructed.  You must
-take care to ensure that the referenced array is not destroyed or reshaped for
-the duration of the returned object, typically by limiting the scope of the
-returned instance.
-
-The returned proxy object supports some of the same methods as ``py::array`` so
-that it can be used as a drop-in replacement for some existing, index-checked
-uses of ``py::array``:
-
- ``.ndim()`` returns the number of dimensions
-
- ``.data(1, 2, ...)`` and ``r.mutable_data(1, 2, ...)``` returns a pointer to
-  the ``const T`` or ``T`` data, respectively, at the given indices.  The
-  latter is only available to proxies obtained via ``a.mutable_unchecked()``.
-
- ``.itemsize()`` returns the size of an item in bytes, i.e. ``sizeof(T)``.
-
- ``.ndim()`` returns the number of dimensions.
-
- ``.shape(n)`` returns the size of dimension ``n``
-
- ``.size()`` returns the total number of elements (i.e. the product of the shapes).
-
- ``.nbytes()`` returns the number of bytes used by the referenced elements
-  (i.e. ``itemsize()`` times ``size()``).
-
-.. seealso::
-
-    The file :file:`tests/test_numpy_array.cpp` contains additional examples
-    demonstrating the use of this feature.
-
-Ellipsis
-========
-
-Python provides a convenient ``...`` ellipsis notation that is often used to
-slice multidimensional arrays. For instance, the following snippet extracts the
-middle dimensions of a tensor with the first and last index set to zero.
-
-.. code-block:: python
-
-   a = ...  # a NumPy array
-   b = a[0, ..., 0]
-
-The function ``py::ellipsis()`` function can be used to perform the same
-operation on the C++ side:
-
-.. code-block:: cpp
-
-   py::array a = /* A NumPy array */;
-   py::array b = a[py::make_tuple(0, py::ellipsis(), 0)];
-
-
-Memory view
-===========
-
-For a case when we simply want to provide a direct accessor to C/C++ buffer
-without a concrete class object, we can return a ``memoryview`` object. Suppose
-we wish to expose a ``memoryview`` for 2x4 uint8_t array, we can do the
-following:
-
-.. code-block:: cpp
-
-    const uint8_t buffer[] = {
-        0, 1, 2, 3,
-        4, 5, 6, 7
-    };
-    m.def("get_memoryview2d", []() {
-        return py::memoryview::from_buffer(
-            buffer,                                    // buffer pointer
-            { 2, 4 },                                  // shape (rows, cols)
-            { sizeof(uint8_t) * 4, sizeof(uint8_t) }   // strides in bytes
-        );
-    })
-
-This approach is meant for providing a ``memoryview`` for a C/C++ buffer not
-managed by Python. The user is responsible for managing the lifetime of the
-buffer. Using a ``memoryview`` created in this way after deleting the buffer in
-C++ side results in undefined behavior.
-
-We can also use ``memoryview::from_memory`` for a simple 1D contiguous buffer:
-
-.. code-block:: cpp
-
-    m.def("get_memoryview1d", []() {
-        return py::memoryview::from_memory(
-            buffer,               // buffer pointer
-            sizeof(uint8_t) * 8   // buffer size
-        );
-    })
-
-.. versionchanged:: 2.6
-    ``memoryview::from_memory`` added.
--- a/libs/pybind/docs/advanced/pycpp/object.rst
+++ b/libs/pybind/docs/advanced/pycpp/object.rst
@ -1,286 +0,0 @@
-Python types
-############
-
-.. _wrappers:
-
-Available wrappers
-==================
-
-All major Python types are available as thin C++ wrapper classes. These
-can also be used as function parameters -- see :ref:`python_objects_as_args`.
-
-Available types include :class:`handle`, :class:`object`, :class:`bool_`,
-:class:`int_`, :class:`float_`, :class:`str`, :class:`bytes`, :class:`tuple`,
-:class:`list`, :class:`dict`, :class:`slice`, :class:`none`, :class:`capsule`,
-:class:`iterable`, :class:`iterator`, :class:`function`, :class:`buffer`,
-:class:`array`, and :class:`array_t`.
-
-.. warning::
-
-    Be sure to review the :ref:`pytypes_gotchas` before using this heavily in
-    your C++ API.
-
-.. _instantiating_compound_types:
-
-Instantiating compound Python types from C++
-============================================
-
-Dictionaries can be initialized in the :class:`dict` constructor:
-
-.. code-block:: cpp
-
-    using namespace pybind11::literals; // to bring in the `_a` literal
-    py::dict d("spam"_a=py::none(), "eggs"_a=42);
-
-A tuple of python objects can be instantiated using :func:`py::make_tuple`:
-
-.. code-block:: cpp
-
-    py::tuple tup = py::make_tuple(42, py::none(), "spam");
-
-Each element is converted to a supported Python type.
-
-A `simple namespace`_ can be instantiated using
-
-.. code-block:: cpp
-
-    using namespace pybind11::literals;  // to bring in the `_a` literal
-    py::object SimpleNamespace = py::module_::import("types").attr("SimpleNamespace");
-    py::object ns = SimpleNamespace("spam"_a=py::none(), "eggs"_a=42);
-
-Attributes on a namespace can be modified with the :func:`py::delattr`,
-:func:`py::getattr`, and :func:`py::setattr` functions. Simple namespaces can
-be useful as lightweight stand-ins for class instances.
-
-.. _simple namespace: https://docs.python.org/3/library/types.html#types.SimpleNamespace
-
-.. _casting_back_and_forth:
-
-Casting back and forth
-======================
-
-In this kind of mixed code, it is often necessary to convert arbitrary C++
-types to Python, which can be done using :func:`py::cast`:
-
-.. code-block:: cpp
-
-    MyClass *cls = ...;
-    py::object obj = py::cast(cls);
-
-The reverse direction uses the following syntax:
-
-.. code-block:: cpp
-
-    py::object obj = ...;
-    MyClass *cls = obj.cast<MyClass *>();
-
-When conversion fails, both directions throw the exception :class:`cast_error`.
-
-.. _python_libs:
-
-Accessing Python libraries from C++
-===================================
-
-It is also possible to import objects defined in the Python standard
-library or available in the current Python environment (``sys.path``) and work
-with these in C++.
-
-This example obtains a reference to the Python ``Decimal`` class.
-
-.. code-block:: cpp
-
-    // Equivalent to "from decimal import Decimal"
-    py::object Decimal = py::module_::import("decimal").attr("Decimal");
-
-.. code-block:: cpp
-
-    // Try to import scipy
-    py::object scipy = py::module_::import("scipy");
-    return scipy.attr("__version__");
-
-
-.. _calling_python_functions:
-
-Calling Python functions
-========================
-
-It is also possible to call Python classes, functions and methods
-via ``operator()``.
-
-.. code-block:: cpp
-
-    // Construct a Python object of class Decimal
-    py::object pi = Decimal("3.14159");
-
-.. code-block:: cpp
-
-    // Use Python to make our directories
-    py::object os = py::module_::import("os");
-    py::object makedirs = os.attr("makedirs");
-    makedirs("/tmp/path/to/somewhere");
-
-One can convert the result obtained from Python to a pure C++ version
-if a ``py::class_`` or type conversion is defined.
-
-.. code-block:: cpp
-
-    py::function f = <...>;
-    py::object result_py = f(1234, "hello", some_instance);
-    MyClass &result = result_py.cast<MyClass>();
-
-.. _calling_python_methods:
-
-Calling Python methods
-========================
-
-To call an object's method, one can again use ``.attr`` to obtain access to the
-Python method.
-
-.. code-block:: cpp
-
-    // Calculate e^π in decimal
-    py::object exp_pi = pi.attr("exp")();
-    py::print(py::str(exp_pi));
-
-In the example above ``pi.attr("exp")`` is a *bound method*: it will always call
-the method for that same instance of the class. Alternately one can create an
-*unbound method* via the Python class (instead of instance) and pass the ``self``
-object explicitly, followed by other arguments.
-
-.. code-block:: cpp
-
-    py::object decimal_exp = Decimal.attr("exp");
-
-    // Compute the e^n for n=0..4
-    for (int n = 0; n < 5; n++) {
-        py::print(decimal_exp(Decimal(n));
-    }
-
-Keyword arguments
-=================
-
-Keyword arguments are also supported. In Python, there is the usual call syntax:
-
-.. code-block:: python
-
-    def f(number, say, to):
-        ...  # function code
-
-
-    f(1234, say="hello", to=some_instance)  # keyword call in Python
-
-In C++, the same call can be made using:
-
-.. code-block:: cpp
-
-    using namespace pybind11::literals; // to bring in the `_a` literal
-    f(1234, "say"_a="hello", "to"_a=some_instance); // keyword call in C++
-
-Unpacking arguments
-===================
-
-Unpacking of ``*args`` and ``**kwargs`` is also possible and can be mixed with
-other arguments:
-
-.. code-block:: cpp
-
-    // * unpacking
-    py::tuple args = py::make_tuple(1234, "hello", some_instance);
-    f(*args);
-
-    // ** unpacking
-    py::dict kwargs = py::dict("number"_a=1234, "say"_a="hello", "to"_a=some_instance);
-    f(**kwargs);
-
-    // mixed keywords, * and ** unpacking
-    py::tuple args = py::make_tuple(1234);
-    py::dict kwargs = py::dict("to"_a=some_instance);
-    f(*args, "say"_a="hello", **kwargs);
-
-Generalized unpacking according to PEP448_ is also supported:
-
-.. code-block:: cpp
-
-    py::dict kwargs1 = py::dict("number"_a=1234);
-    py::dict kwargs2 = py::dict("to"_a=some_instance);
-    f(**kwargs1, "say"_a="hello", **kwargs2);
-
-.. seealso::
-
-    The file :file:`tests/test_pytypes.cpp` contains a complete
-    example that demonstrates passing native Python types in more detail. The
-    file :file:`tests/test_callbacks.cpp` presents a few examples of calling
-    Python functions from C++, including keywords arguments and unpacking.
-
-.. _PEP448: https://www.python.org/dev/peps/pep-0448/
-
-.. _implicit_casting:
-
-Implicit casting
-================
-
-When using the C++ interface for Python types, or calling Python functions,
-objects of type :class:`object` are returned. It is possible to invoke implicit
-conversions to subclasses like :class:`dict`. The same holds for the proxy objects
-returned by ``operator[]`` or ``obj.attr()``.
-Casting to subtypes improves code readability and allows values to be passed to
-C++ functions that require a specific subtype rather than a generic :class:`object`.
-
-.. code-block:: cpp
-
-    #include <pybind11/numpy.h>
-    using namespace pybind11::literals;
-
-    py::module_ os = py::module_::import("os");
-    py::module_ path = py::module_::import("os.path");  // like 'import os.path as path'
-    py::module_ np = py::module_::import("numpy");  // like 'import numpy as np'
-
-    py::str curdir_abs = path.attr("abspath")(path.attr("curdir"));
-    py::print(py::str("Current directory: ") + curdir_abs);
-    py::dict environ = os.attr("environ");
-    py::print(environ["HOME"]);
-    py::array_t<float> arr = np.attr("ones")(3, "dtype"_a="float32");
-    py::print(py::repr(arr + py::int_(1)));
-
-These implicit conversions are available for subclasses of :class:`object`; there
-is no need to call ``obj.cast()`` explicitly as for custom classes, see
-:ref:`casting_back_and_forth`.
-
-.. note::
-    If a trivial conversion via move constructor is not possible, both implicit and
-    explicit casting (calling ``obj.cast()``) will attempt a "rich" conversion.
-    For instance, ``py::list env = os.attr("environ");`` will succeed and is
-    equivalent to the Python code ``env = list(os.environ)`` that produces a
-    list of the dict keys.
-
-..  TODO: Adapt text once PR #2349 has landed
-
-Handling exceptions
-===================
-
-Python exceptions from wrapper classes will be thrown as a ``py::error_already_set``.
-See :ref:`Handling exceptions from Python in C++
-<handling_python_exceptions_cpp>` for more information on handling exceptions
-raised when calling C++ wrapper classes.
-
-.. _pytypes_gotchas:
-
-Gotchas
-=======
-
-Default-Constructed Wrappers
----------------------------
-
-When a wrapper type is default-constructed, it is **not** a valid Python object (i.e. it is not ``py::none()``). It is simply the same as
-``PyObject*`` null pointer. To check for this, use
-``static_cast<bool>(my_wrapper)``.
-
-Assigning py::none() to wrappers
--------------------------------
-
-You may be tempted to use types like ``py::str`` and ``py::dict`` in C++
-signatures (either pure C++, or in bound signatures), and assign them default
-values of ``py::none()``. However, in a best case scenario, it will fail fast
-because ``None`` is not convertible to that type (e.g. ``py::dict``), or in a
-worse case scenario, it will silently work but corrupt the types you want to
-work with (e.g. ``py::str(py::none())`` will yield ``"None"`` in Python).
--- a/libs/pybind/docs/advanced/pycpp/utilities.rst
+++ b/libs/pybind/docs/advanced/pycpp/utilities.rst
@ -1,155 +0,0 @@
-Utilities
-#########
-
-Using Python's print function in C++
-====================================
-
-The usual way to write output in C++ is using ``std::cout`` while in Python one
-would use ``print``. Since these methods use different buffers, mixing them can
-lead to output order issues. To resolve this, pybind11 modules can use the
-:func:`py::print` function which writes to Python's ``sys.stdout`` for consistency.
-
-Python's ``print`` function is replicated in the C++ API including optional
-keyword arguments ``sep``, ``end``, ``file``, ``flush``. Everything works as
-expected in Python:
-
-.. code-block:: cpp
-
-    py::print(1, 2.0, "three"); // 1 2.0 three
-    py::print(1, 2.0, "three", "sep"_a="-"); // 1-2.0-three
-
-    auto args = py::make_tuple("unpacked", true);
-    py::print("->", *args, "end"_a="<-"); // -> unpacked True <-
-
-.. _ostream_redirect:
-
-Capturing standard output from ostream
-======================================
-
-Often, a library will use the streams ``std::cout`` and ``std::cerr`` to print,
-but this does not play well with Python's standard ``sys.stdout`` and ``sys.stderr``
-redirection. Replacing a library's printing with ``py::print <print>`` may not
-be feasible. This can be fixed using a guard around the library function that
-redirects output to the corresponding Python streams:
-
-.. code-block:: cpp
-
-    #include <pybind11/iostream.h>
-
-    ...
-
-    // Add a scoped redirect for your noisy code
-    m.def("noisy_func", []() {
-        py::scoped_ostream_redirect stream(
-            std::cout,                               // std::ostream&
-            py::module_::import("sys").attr("stdout") // Python output
-        );
-        call_noisy_func();
-    });
-
-.. warning::
-
-    The implementation in ``pybind11/iostream.h`` is NOT thread safe. Multiple
-    threads writing to a redirected ostream concurrently cause data races
-    and potentially buffer overflows. Therefore it is currently a requirement
-    that all (possibly) concurrent redirected ostream writes are protected by
-    a mutex. #HelpAppreciated: Work on iostream.h thread safety. For more
-    background see the discussions under
-    `PR #2982 <https://github.com/pybind/pybind11/pull/2982>`_ and
-    `PR #2995 <https://github.com/pybind/pybind11/pull/2995>`_.
-
-This method respects flushes on the output streams and will flush if needed
-when the scoped guard is destroyed. This allows the output to be redirected in
-real time, such as to a Jupyter notebook. The two arguments, the C++ stream and
-the Python output, are optional, and default to standard output if not given. An
-extra type, ``py::scoped_estream_redirect <scoped_estream_redirect>``, is identical
-except for defaulting to ``std::cerr`` and ``sys.stderr``; this can be useful with
-``py::call_guard``, which allows multiple items, but uses the default constructor:
-
-.. code-block:: cpp
-
-    // Alternative: Call single function using call guard
-    m.def("noisy_func", &call_noisy_function,
-          py::call_guard<py::scoped_ostream_redirect,
-                         py::scoped_estream_redirect>());
-
-The redirection can also be done in Python with the addition of a context
-manager, using the ``py::add_ostream_redirect() <add_ostream_redirect>`` function:
-
-.. code-block:: cpp
-
-    py::add_ostream_redirect(m, "ostream_redirect");
-
-The name in Python defaults to ``ostream_redirect`` if no name is passed.  This
-creates the following context manager in Python:
-
-.. code-block:: python
-
-    with ostream_redirect(stdout=True, stderr=True):
-        noisy_function()
-
-It defaults to redirecting both streams, though you can use the keyword
-arguments to disable one of the streams if needed.
-
-.. note::
-
-    The above methods will not redirect C-level output to file descriptors, such
-    as ``fprintf``. For those cases, you'll need to redirect the file
-    descriptors either directly in C or with Python's ``os.dup2`` function
-    in an operating-system dependent way.
-
-.. _eval:
-
-Evaluating Python expressions from strings and files
-====================================================
-
-pybind11 provides the ``eval``, ``exec`` and ``eval_file`` functions to evaluate
-Python expressions and statements. The following example illustrates how they
-can be used.
-
-.. code-block:: cpp
-
-    // At beginning of file
-    #include <pybind11/eval.h>
-
-    ...
-
-    // Evaluate in scope of main module
-    py::object scope = py::module_::import("__main__").attr("__dict__");
-
-    // Evaluate an isolated expression
-    int result = py::eval("my_variable + 10", scope).cast<int>();
-
-    // Evaluate a sequence of statements
-    py::exec(
-        "print('Hello')\n"
-        "print('world!');",
-        scope);
-
-    // Evaluate the statements in an separate Python file on disk
-    py::eval_file("script.py", scope);
-
-C++11 raw string literals are also supported and quite handy for this purpose.
-The only requirement is that the first statement must be on a new line following
-the raw string delimiter ``R"(``, ensuring all lines have common leading indent:
-
-.. code-block:: cpp
-
-    py::exec(R"(
-        x = get_answer()
-        if x == 42:
-            print('Hello World!')
-        else:
-            print('Bye!')
-        )", scope
-    );
-
-.. note::
-
-    `eval` and `eval_file` accept a template parameter that describes how the
-    string/file should be interpreted. Possible choices include ``eval_expr``
-    (isolated expression), ``eval_single_statement`` (a single statement, return
-    value is always ``none``), and ``eval_statements`` (sequence of statements,
-    return value is always ``none``). `eval` defaults to  ``eval_expr``,
-    `eval_file` defaults to ``eval_statements`` and `exec` is just a shortcut
-    for ``eval<eval_statements>``.
--- a/libs/pybind/docs/advanced/smart_ptrs.rst
+++ b/libs/pybind/docs/advanced/smart_ptrs.rst
@ -1,174 +0,0 @@
-Smart pointers
-##############
-
-std::unique_ptr
-===============
-
-Given a class ``Example`` with Python bindings, it's possible to return
-instances wrapped in C++11 unique pointers, like so
-
-.. code-block:: cpp
-
-    std::unique_ptr<Example> create_example() { return std::unique_ptr<Example>(new Example()); }
-
-.. code-block:: cpp
-
-    m.def("create_example", &create_example);
-
-In other words, there is nothing special that needs to be done. While returning
-unique pointers in this way is allowed, it is *illegal* to use them as function
-arguments. For instance, the following function signature cannot be processed
-by pybind11.
-
-.. code-block:: cpp
-
-    void do_something_with_example(std::unique_ptr<Example> ex) { ... }
-
-The above signature would imply that Python needs to give up ownership of an
-object that is passed to this function, which is generally not possible (for
-instance, the object might be referenced elsewhere).
-
-std::shared_ptr
-===============
-
-The binding generator for classes, :class:`class_`, can be passed a template
-type that denotes a special *holder* type that is used to manage references to
-the object.  If no such holder type template argument is given, the default for
-a type named ``Type`` is ``std::unique_ptr<Type>``, which means that the object
-is deallocated when Python's reference count goes to zero.
-
-It is possible to switch to other types of reference counting wrappers or smart
-pointers, which is useful in codebases that rely on them. For instance, the
-following snippet causes ``std::shared_ptr`` to be used instead.
-
-.. code-block:: cpp
-
-    py::class_<Example, std::shared_ptr<Example> /* <- holder type */> obj(m, "Example");
-
-Note that any particular class can only be associated with a single holder type.
-
-One potential stumbling block when using holder types is that they need to be
-applied consistently. Can you guess what's broken about the following binding
-code?
-
-.. code-block:: cpp
-
-    class Child { };
-
-    class Parent {
-    public:
-       Parent() : child(std::make_shared<Child>()) { }
-       Child *get_child() { return child.get(); }  /* Hint: ** DON'T DO THIS ** */
-    private:
-        std::shared_ptr<Child> child;
-    };
-
-    PYBIND11_MODULE(example, m) {
-        py::class_<Child, std::shared_ptr<Child>>(m, "Child");
-
-        py::class_<Parent, std::shared_ptr<Parent>>(m, "Parent")
-           .def(py::init<>())
-           .def("get_child", &Parent::get_child);
-    }
-
-The following Python code will cause undefined behavior (and likely a
-segmentation fault).
-
-.. code-block:: python
-
-   from example import Parent
-
-   print(Parent().get_child())
-
-The problem is that ``Parent::get_child()`` returns a pointer to an instance of
-``Child``, but the fact that this instance is already managed by
-``std::shared_ptr<...>`` is lost when passing raw pointers. In this case,
-pybind11 will create a second independent ``std::shared_ptr<...>`` that also
-claims ownership of the pointer. In the end, the object will be freed **twice**
-since these shared pointers have no way of knowing about each other.
-
-There are two ways to resolve this issue:
-
-1. For types that are managed by a smart pointer class, never use raw pointers
-   in function arguments or return values. In other words: always consistently
-   wrap pointers into their designated holder types (such as
-   ``std::shared_ptr<...>``). In this case, the signature of ``get_child()``
-   should be modified as follows:
-
-.. code-block:: cpp
-
-    std::shared_ptr<Child> get_child() { return child; }
-
-2. Adjust the definition of ``Child`` by specifying
-   ``std::enable_shared_from_this<T>`` (see cppreference_ for details) as a
-   base class. This adds a small bit of information to ``Child`` that allows
-   pybind11 to realize that there is already an existing
-   ``std::shared_ptr<...>`` and communicate with it. In this case, the
-   declaration of ``Child`` should look as follows:
-
-.. _cppreference: http://en.cppreference.com/w/cpp/memory/enable_shared_from_this
-
-.. code-block:: cpp
-
-    class Child : public std::enable_shared_from_this<Child> { };
-
-.. _smart_pointers:
-
-Custom smart pointers
-=====================
-
-pybind11 supports ``std::unique_ptr`` and ``std::shared_ptr`` right out of the
-box. For any other custom smart pointer, transparent conversions can be enabled
-using a macro invocation similar to the following. It must be declared at the
-top namespace level before any binding code:
-
-.. code-block:: cpp
-
-    PYBIND11_DECLARE_HOLDER_TYPE(T, SmartPtr<T>);
-
-The first argument of :func:`PYBIND11_DECLARE_HOLDER_TYPE` should be a
-placeholder name that is used as a template parameter of the second argument.
-Thus, feel free to use any identifier, but use it consistently on both sides;
-also, don't use the name of a type that already exists in your codebase.
-
-The macro also accepts a third optional boolean parameter that is set to false
-by default. Specify
-
-.. code-block:: cpp
-
-    PYBIND11_DECLARE_HOLDER_TYPE(T, SmartPtr<T>, true);
-
-if ``SmartPtr<T>`` can always be initialized from a ``T*`` pointer without the
-risk of inconsistencies (such as multiple independent ``SmartPtr`` instances
-believing that they are the sole owner of the ``T*`` pointer). A common
-situation where ``true`` should be passed is when the ``T`` instances use
-*intrusive* reference counting.
-
-Please take a look at the :ref:`macro_notes` before using this feature.
-
-By default, pybind11 assumes that your custom smart pointer has a standard
-interface, i.e. provides a ``.get()`` member function to access the underlying
-raw pointer. If this is not the case, pybind11's ``holder_helper`` must be
-specialized:
-
-.. code-block:: cpp
-
-    // Always needed for custom holder types
-    PYBIND11_DECLARE_HOLDER_TYPE(T, SmartPtr<T>);
-
-    // Only needed if the type's `.get()` goes by another name
-    namespace pybind11 { namespace detail {
-        template <typename T>
-        struct holder_helper<SmartPtr<T>> { // <-- specialization
-            static const T *get(const SmartPtr<T> &p) { return p.getPointer(); }
-        };
-    }}
-
-The above specialization informs pybind11 that the custom ``SmartPtr`` class
-provides ``.get()`` functionality via ``.getPointer()``.
-
-.. seealso::
-
-    The file :file:`tests/test_smart_ptr.cpp` contains a complete example
-    that demonstrates how to work with custom reference-counting holder types
-    in more detail.
--- a/libs/pybind/docs/basics.rst
+++ b/libs/pybind/docs/basics.rst
@ -1,307 +0,0 @@
-.. _basics:
-
-First steps
-###########
-
-This sections demonstrates the basic features of pybind11. Before getting
-started, make sure that development environment is set up to compile the
-included set of test cases.
-
-
-Compiling the test cases
-========================
-
-Linux/macOS
-----------
-
-On Linux  you'll need to install the **python-dev** or **python3-dev** packages as
-well as **cmake**. On macOS, the included python version works out of the box,
-but **cmake** must still be installed.
-
-After installing the prerequisites, run
-
-.. code-block:: bash
-
-   mkdir build
-   cd build
-   cmake ..
-   make check -j 4
-
-The last line will both compile and run the tests.
-
-Windows
-------
-
-On Windows, only **Visual Studio 2017** and newer are supported.
-
-.. Note::
-
-    To use the C++17 in Visual Studio 2017 (MSVC 14.1), pybind11 requires the flag
-    ``/permissive-`` to be passed to the compiler `to enforce standard conformance`_. When
-    building with Visual Studio 2019, this is not strictly necessary, but still advised.
-
-..  _`to enforce standard conformance`: https://docs.microsoft.com/en-us/cpp/build/reference/permissive-standards-conformance?view=vs-2017
-
-To compile and run the tests:
-
-.. code-block:: batch
-
-   mkdir build
-   cd build
-   cmake ..
-   cmake --build . --config Release --target check
-
-This will create a Visual Studio project, compile and run the target, all from the
-command line.
-
-.. Note::
-
-    If all tests fail, make sure that the Python binary and the testcases are compiled
-    for the same processor type and bitness (i.e. either **i386** or **x86_64**). You
-    can specify **x86_64** as the target architecture for the generated Visual Studio
-    project using ``cmake -A x64 ..``.
-
-.. seealso::
-
-    Advanced users who are already familiar with Boost.Python may want to skip
-    the tutorial and look at the test cases in the :file:`tests` directory,
-    which exercise all features of pybind11.
-
-Header and namespace conventions
-================================
-
-For brevity, all code examples assume that the following two lines are present:
-
-.. code-block:: cpp
-
-    #include <pybind11/pybind11.h>
-
-    namespace py = pybind11;
-
-Some features may require additional headers, but those will be specified as needed.
-
-.. _simple_example:
-
-Creating bindings for a simple function
-=======================================
-
-Let's start by creating Python bindings for an extremely simple function, which
-adds two numbers and returns their result:
-
-.. code-block:: cpp
-
-    int add(int i, int j) {
-        return i + j;
-    }
-
-For simplicity [#f1]_, we'll put both this function and the binding code into
-a file named :file:`example.cpp` with the following contents:
-
-.. code-block:: cpp
-
-    #include <pybind11/pybind11.h>
-
-    int add(int i, int j) {
-        return i + j;
-    }
-
-    PYBIND11_MODULE(example, m) {
-        m.doc() = "pybind11 example plugin"; // optional module docstring
-
-        m.def("add", &add, "A function that adds two numbers");
-    }
-
-.. [#f1] In practice, implementation and binding code will generally be located
-         in separate files.
-
-The :func:`PYBIND11_MODULE` macro creates a function that will be called when an
-``import`` statement is issued from within Python. The module name (``example``)
-is given as the first macro argument (it should not be in quotes). The second
-argument (``m``) defines a variable of type :class:`py::module_ <module>` which
-is the main interface for creating bindings. The method :func:`module_::def`
-generates binding code that exposes the ``add()`` function to Python.
-
-.. note::
-
-    Notice how little code was needed to expose our function to Python: all
-    details regarding the function's parameters and return value were
-    automatically inferred using template metaprogramming. This overall
-    approach and the used syntax are borrowed from Boost.Python, though the
-    underlying implementation is very different.
-
-pybind11 is a header-only library, hence it is not necessary to link against
-any special libraries and there are no intermediate (magic) translation steps.
-On Linux, the above example can be compiled using the following command:
-
-.. code-block:: bash
-
-    $ c++ -O3 -Wall -shared -std=c++11 -fPIC $(python3 -m pybind11 --includes) example.cpp -o example$(python3-config --extension-suffix)
-
-.. note::
-
-    If you used :ref:`include_as_a_submodule` to get the pybind11 source, then
-    use ``$(python3-config --includes) -Iextern/pybind11/include`` instead of
-    ``$(python3 -m pybind11 --includes)`` in the above compilation, as
-    explained in :ref:`building_manually`.
-
-For more details on the required compiler flags on Linux and macOS, see
-:ref:`building_manually`. For complete cross-platform compilation instructions,
-refer to the :ref:`compiling` page.
-
-The `python_example`_ and `cmake_example`_ repositories are also a good place
-to start. They are both complete project examples with cross-platform build
-systems. The only difference between the two is that `python_example`_ uses
-Python's ``setuptools`` to build the module, while `cmake_example`_ uses CMake
-(which may be preferable for existing C++ projects).
-
-.. _python_example: https://github.com/pybind/python_example
-.. _cmake_example: https://github.com/pybind/cmake_example
-
-Building the above C++ code will produce a binary module file that can be
-imported to Python. Assuming that the compiled module is located in the
-current directory, the following interactive Python session shows how to
-load and execute the example:
-
-.. code-block:: pycon
-
-    $ python
-    Python 3.9.10 (main, Jan 15 2022, 11:48:04)
-    [Clang 13.0.0 (clang-1300.0.29.3)] on darwin
-    Type "help", "copyright", "credits" or "license" for more information.
-    >>> import example
-    >>> example.add(1, 2)
-    3
-    >>>
-
-.. _keyword_args:
-
-Keyword arguments
-=================
-
-With a simple code modification, it is possible to inform Python about the
-names of the arguments ("i" and "j" in this case).
-
-.. code-block:: cpp
-
-    m.def("add", &add, "A function which adds two numbers",
-          py::arg("i"), py::arg("j"));
-
-:class:`arg` is one of several special tag classes which can be used to pass
-metadata into :func:`module_::def`. With this modified binding code, we can now
-call the function using keyword arguments, which is a more readable alternative
-particularly for functions taking many parameters:
-
-.. code-block:: pycon
-
-    >>> import example
-    >>> example.add(i=1, j=2)
-    3L
-
-The keyword names also appear in the function signatures within the documentation.
-
-.. code-block:: pycon
-
-    >>> help(example)
-
-    ....
-
-    FUNCTIONS
-        add(...)
-            Signature : (i: int, j: int) -> int
-
-            A function which adds two numbers
-
-A shorter notation for named arguments is also available:
-
-.. code-block:: cpp
-
-    // regular notation
-    m.def("add1", &add, py::arg("i"), py::arg("j"));
-    // shorthand
-    using namespace pybind11::literals;
-    m.def("add2", &add, "i"_a, "j"_a);
-
-The :var:`_a` suffix forms a C++11 literal which is equivalent to :class:`arg`.
-Note that the literal operator must first be made visible with the directive
-``using namespace pybind11::literals``. This does not bring in anything else
-from the ``pybind11`` namespace except for literals.
-
-.. _default_args:
-
-Default arguments
-=================
-
-Suppose now that the function to be bound has default arguments, e.g.:
-
-.. code-block:: cpp
-
-    int add(int i = 1, int j = 2) {
-        return i + j;
-    }
-
-Unfortunately, pybind11 cannot automatically extract these parameters, since they
-are not part of the function's type information. However, they are simple to specify
-using an extension of :class:`arg`:
-
-.. code-block:: cpp
-
-    m.def("add", &add, "A function which adds two numbers",
-          py::arg("i") = 1, py::arg("j") = 2);
-
-The default values also appear within the documentation.
-
-.. code-block:: pycon
-
-    >>> help(example)
-
-    ....
-
-    FUNCTIONS
-        add(...)
-            Signature : (i: int = 1, j: int = 2) -> int
-
-            A function which adds two numbers
-
-The shorthand notation is also available for default arguments:
-
-.. code-block:: cpp
-
-    // regular notation
-    m.def("add1", &add, py::arg("i") = 1, py::arg("j") = 2);
-    // shorthand
-    m.def("add2", &add, "i"_a=1, "j"_a=2);
-
-Exporting variables
-===================
-
-To expose a value from C++, use the ``attr`` function to register it in a
-module as shown below. Built-in types and general objects (more on that later)
-are automatically converted when assigned as attributes, and can be explicitly
-converted using the function ``py::cast``.
-
-.. code-block:: cpp
-
-    PYBIND11_MODULE(example, m) {
-        m.attr("the_answer") = 42;
-        py::object world = py::cast("World");
-        m.attr("what") = world;
-    }
-
-These are then accessible from Python:
-
-.. code-block:: pycon
-
-    >>> import example
-    >>> example.the_answer
-    42
-    >>> example.what
-    'World'
-
-.. _supported_types:
-
-Supported data types
-====================
-
-A large number of data types are supported out of the box and can be used
-seamlessly as functions arguments, return values or with ``py::cast`` in general.
-For a full overview, see the :doc:`advanced/cast/index` section.
--- a/libs/pybind/docs/benchmark.py
+++ b/libs/pybind/docs/benchmark.py
@ -1,87 +0,0 @@
-import datetime as dt
-import os
-import random
-
-nfns = 4  # Functions per class
-nargs = 4  # Arguments per function
-
-
-def generate_dummy_code_pybind11(nclasses=10):
-    decl = ""
-    bindings = ""
-
-    for cl in range(nclasses):
-        decl += f"class cl{cl:03};\n"
-    decl += "\n"
-
-    for cl in range(nclasses):
-        decl += f"class {cl:03} {{\n"
-        decl += "public:\n"
-        bindings += f'    py::class_<cl{cl:03}>(m, "cl{cl:03}")\n'
-        for fn in range(nfns):
-            ret = random.randint(0, nclasses - 1)
-            params = [random.randint(0, nclasses - 1) for i in range(nargs)]
-            decl += f"    cl{ret:03} *fn_{fn:03}("
-            decl += ", ".join(f"cl{p:03} *" for p in params)
-            decl += ");\n"
-            bindings += f'        .def("fn_{fn:03}", &cl{cl:03}::fn_{fn:03})\n'
-        decl += "};\n\n"
-        bindings += "        ;\n"
-
-    result = "#include <pybind11/pybind11.h>\n\n"
-    result += "namespace py = pybind11;\n\n"
-    result += decl + "\n"
-    result += "PYBIND11_MODULE(example, m) {\n"
-    result += bindings
-    result += "}"
-    return result
-
-
-def generate_dummy_code_boost(nclasses=10):
-    decl = ""
-    bindings = ""
-
-    for cl in range(nclasses):
-        decl += f"class cl{cl:03};\n"
-    decl += "\n"
-
-    for cl in range(nclasses):
-        decl += "class cl%03i {\n" % cl
-        decl += "public:\n"
-        bindings += f'    py::class_<cl{cl:03}>("cl{cl:03}")\n'
-        for fn in range(nfns):
-            ret = random.randint(0, nclasses - 1)
-            params = [random.randint(0, nclasses - 1) for i in range(nargs)]
-            decl += f"    cl{ret:03} *fn_{fn:03}("
-            decl += ", ".join(f"cl{p:03} *" for p in params)
-            decl += ");\n"
-            bindings += f'        .def("fn_{fn:03}", &cl{cl:03}::fn_{fn:03}, py::return_value_policy<py::manage_new_object>())\n'
-        decl += "};\n\n"
-        bindings += "        ;\n"
-
-    result = "#include <boost/python.hpp>\n\n"
-    result += "namespace py = boost::python;\n\n"
-    result += decl + "\n"
-    result += "BOOST_PYTHON_MODULE(example) {\n"
-    result += bindings
-    result += "}"
-    return result
-
-
-for codegen in [generate_dummy_code_pybind11, generate_dummy_code_boost]:
-    print("{")
-    for i in range(0, 10):
-        nclasses = 2**i
-        with open("test.cpp", "w") as f:
-            f.write(codegen(nclasses))
-        n1 = dt.datetime.now()
-        os.system(
-            "g++ -Os -shared -rdynamic -undefined dynamic_lookup "
-            "-fvisibility=hidden -std=c++14 test.cpp -I include "
-            "-I /System/Library/Frameworks/Python.framework/Headers -o test.so"
-        )
-        n2 = dt.datetime.now()
-        elapsed = (n2 - n1).total_seconds()
-        size = os.stat("test.so").st_size
-        print("   {%i, %f, %i}," % (nclasses * nfns, elapsed, size))
-    print("}")
--- a/libs/pybind/docs/benchmark.rst
+++ b/libs/pybind/docs/benchmark.rst
@ -1,95 +0,0 @@
-Benchmark
-=========
-
-The following is the result of a synthetic benchmark comparing both compilation
-time and module size of pybind11 against Boost.Python. A detailed report about a
-Boost.Python to pybind11 conversion of a real project is available here: [#f1]_.
-
-.. [#f1] http://graylab.jhu.edu/RosettaCon2016/PyRosetta-4.pdf
-
-Setup
-----
-
-A python script (see the ``docs/benchmark.py`` file) was used to generate a set
-of files with dummy classes whose count increases for each successive benchmark
-(between 1 and 2048 classes in powers of two). Each class has four methods with
-a randomly generated signature with a return value and four arguments. (There
-was no particular reason for this setup other than the desire to generate many
-unique function signatures whose count could be controlled in a simple way.)
-
-Here is an example of the binding code for one class:
-
-.. code-block:: cpp
-
-    ...
-    class cl034 {
-    public:
-        cl279 *fn_000(cl084 *, cl057 *, cl065 *, cl042 *);
-        cl025 *fn_001(cl098 *, cl262 *, cl414 *, cl121 *);
-        cl085 *fn_002(cl445 *, cl297 *, cl145 *, cl421 *);
-        cl470 *fn_003(cl200 *, cl323 *, cl332 *, cl492 *);
-    };
-    ...
-
-    PYBIND11_MODULE(example, m) {
-        ...
-        py::class_<cl034>(m, "cl034")
-            .def("fn_000", &cl034::fn_000)
-            .def("fn_001", &cl034::fn_001)
-            .def("fn_002", &cl034::fn_002)
-            .def("fn_003", &cl034::fn_003)
-        ...
-    }
-
-The Boost.Python version looks almost identical except that a return value
-policy had to be specified as an argument to ``def()``. For both libraries,
-compilation was done with
-
-.. code-block:: bash
-
-    Apple LLVM version 7.0.2 (clang-700.1.81)
-
-and the following compilation flags
-
-.. code-block:: bash
-
-    g++ -Os -shared -rdynamic -undefined dynamic_lookup -fvisibility=hidden -std=c++14
-
-Compilation time
----------------
-
-The following log-log plot shows how the compilation time grows for an
-increasing number of class and function declarations. pybind11 includes many
-fewer headers, which initially leads to shorter compilation times, but the
-performance is ultimately fairly similar (pybind11 is 19.8 seconds faster for
-the largest largest file with 2048 classes and a total of 8192 methods -- a
-modest **1.2x** speedup relative to Boost.Python, which required 116.35
-seconds).
-
-.. only:: not latex
-
-    .. image:: pybind11_vs_boost_python1.svg
-
-.. only:: latex
-
-    .. image:: pybind11_vs_boost_python1.png
-
-Module size
-----------
-
-Differences between the two libraries become much more pronounced when
-considering the file size of the generated Python plugin: for the largest file,
-the binary generated by Boost.Python required 16.8 MiB, which was **2.17
-times** / **9.1 megabytes** larger than the output generated by pybind11. For
-very small inputs, Boost.Python has an edge in the plot below -- however, note
-that it stores many definitions in an external library, whose size was not
-included here, hence the comparison is slightly shifted in Boost.Python's
-favor.
-
-.. only:: not latex
-
-    .. image:: pybind11_vs_boost_python2.svg
-
-.. only:: latex
-
-    .. image:: pybind11_vs_boost_python2.png
--- a/libs/pybind/docs/changelog.rst
+++ b/libs/pybind/docs/changelog.rst
--- a/libs/pybind/docs/classes.rst
+++ b/libs/pybind/docs/classes.rst
@ -1,541 +0,0 @@
-.. _classes:
-
-Object-oriented code
-####################
-
-Creating bindings for a custom type
-===================================
-
-Let's now look at a more complex example where we'll create bindings for a
-custom C++ data structure named ``Pet``. Its definition is given below:
-
-.. code-block:: cpp
-
-    struct Pet {
-        Pet(const std::string &name) : name(name) { }
-        void setName(const std::string &name_) { name = name_; }
-        const std::string &getName() const { return name; }
-
-        std::string name;
-    };
-
-The binding code for ``Pet`` looks as follows:
-
-.. code-block:: cpp
-
-    #include <pybind11/pybind11.h>
-
-    namespace py = pybind11;
-
-    PYBIND11_MODULE(example, m) {
-        py::class_<Pet>(m, "Pet")
-            .def(py::init<const std::string &>())
-            .def("setName", &Pet::setName)
-            .def("getName", &Pet::getName);
-    }
-
-:class:`class_` creates bindings for a C++ *class* or *struct*-style data
-structure. :func:`init` is a convenience function that takes the types of a
-constructor's parameters as template arguments and wraps the corresponding
-constructor (see the :ref:`custom_constructors` section for details). An
-interactive Python session demonstrating this example is shown below:
-
-.. code-block:: pycon
-
-    % python
-    >>> import example
-    >>> p = example.Pet("Molly")
-    >>> print(p)
-    <example.Pet object at 0x10cd98060>
-    >>> p.getName()
-    'Molly'
-    >>> p.setName("Charly")
-    >>> p.getName()
-    'Charly'
-
-.. seealso::
-
-    Static member functions can be bound in the same way using
-    :func:`class_::def_static`.
-
-Keyword and default arguments
-=============================
-It is possible to specify keyword and default arguments using the syntax
-discussed in the previous chapter. Refer to the sections :ref:`keyword_args`
-and :ref:`default_args` for details.
-
-Binding lambda functions
-========================
-
-Note how ``print(p)`` produced a rather useless summary of our data structure in the example above:
-
-.. code-block:: pycon
-
-    >>> print(p)
-    <example.Pet object at 0x10cd98060>
-
-To address this, we could bind a utility function that returns a human-readable
-summary to the special method slot named ``__repr__``. Unfortunately, there is no
-suitable functionality in the ``Pet`` data structure, and it would be nice if
-we did not have to change it. This can easily be accomplished by binding a
-Lambda function instead:
-
-.. code-block:: cpp
-
-        py::class_<Pet>(m, "Pet")
-            .def(py::init<const std::string &>())
-            .def("setName", &Pet::setName)
-            .def("getName", &Pet::getName)
-            .def("__repr__",
-                [](const Pet &a) {
-                    return "<example.Pet named '" + a.name + "'>";
-                }
-            );
-
-Both stateless [#f1]_ and stateful lambda closures are supported by pybind11.
-With the above change, the same Python code now produces the following output:
-
-.. code-block:: pycon
-
-    >>> print(p)
-    <example.Pet named 'Molly'>
-
-.. [#f1] Stateless closures are those with an empty pair of brackets ``[]`` as the capture object.
-
-.. _properties:
-
-Instance and static fields
-==========================
-
-We can also directly expose the ``name`` field using the
-:func:`class_::def_readwrite` method. A similar :func:`class_::def_readonly`
-method also exists for ``const`` fields.
-
-.. code-block:: cpp
-
-        py::class_<Pet>(m, "Pet")
-            .def(py::init<const std::string &>())
-            .def_readwrite("name", &Pet::name)
-            // ... remainder ...
-
-This makes it possible to write
-
-.. code-block:: pycon
-
-    >>> p = example.Pet("Molly")
-    >>> p.name
-    'Molly'
-    >>> p.name = "Charly"
-    >>> p.name
-    'Charly'
-
-Now suppose that ``Pet::name`` was a private internal variable
-that can only be accessed via setters and getters.
-
-.. code-block:: cpp
-
-    class Pet {
-    public:
-        Pet(const std::string &name) : name(name) { }
-        void setName(const std::string &name_) { name = name_; }
-        const std::string &getName() const { return name; }
-    private:
-        std::string name;
-    };
-
-In this case, the method :func:`class_::def_property`
-(:func:`class_::def_property_readonly` for read-only data) can be used to
-provide a field-like interface within Python that will transparently call
-the setter and getter functions:
-
-.. code-block:: cpp
-
-        py::class_<Pet>(m, "Pet")
-            .def(py::init<const std::string &>())
-            .def_property("name", &Pet::getName, &Pet::setName)
-            // ... remainder ...
-
-Write only properties can be defined by passing ``nullptr`` as the
-input for the read function.
-
-.. seealso::
-
-    Similar functions :func:`class_::def_readwrite_static`,
-    :func:`class_::def_readonly_static` :func:`class_::def_property_static`,
-    and :func:`class_::def_property_readonly_static` are provided for binding
-    static variables and properties. Please also see the section on
-    :ref:`static_properties` in the advanced part of the documentation.
-
-Dynamic attributes
-==================
-
-Native Python classes can pick up new attributes dynamically:
-
-.. code-block:: pycon
-
-    >>> class Pet:
-    ...     name = "Molly"
-    ...
-    >>> p = Pet()
-    >>> p.name = "Charly"  # overwrite existing
-    >>> p.age = 2  # dynamically add a new attribute
-
-By default, classes exported from C++ do not support this and the only writable
-attributes are the ones explicitly defined using :func:`class_::def_readwrite`
-or :func:`class_::def_property`.
-
-.. code-block:: cpp
-
-    py::class_<Pet>(m, "Pet")
-        .def(py::init<>())
-        .def_readwrite("name", &Pet::name);
-
-Trying to set any other attribute results in an error:
-
-.. code-block:: pycon
-
-    >>> p = example.Pet()
-    >>> p.name = "Charly"  # OK, attribute defined in C++
-    >>> p.age = 2  # fail
-    AttributeError: 'Pet' object has no attribute 'age'
-
-To enable dynamic attributes for C++ classes, the :class:`py::dynamic_attr` tag
-must be added to the :class:`py::class_` constructor:
-
-.. code-block:: cpp
-
-    py::class_<Pet>(m, "Pet", py::dynamic_attr())
-        .def(py::init<>())
-        .def_readwrite("name", &Pet::name);
-
-Now everything works as expected:
-
-.. code-block:: pycon
-
-    >>> p = example.Pet()
-    >>> p.name = "Charly"  # OK, overwrite value in C++
-    >>> p.age = 2  # OK, dynamically add a new attribute
-    >>> p.__dict__  # just like a native Python class
-    {'age': 2}
-
-Note that there is a small runtime cost for a class with dynamic attributes.
-Not only because of the addition of a ``__dict__``, but also because of more
-expensive garbage collection tracking which must be activated to resolve
-possible circular references. Native Python classes incur this same cost by
-default, so this is not anything to worry about. By default, pybind11 classes
-are more efficient than native Python classes. Enabling dynamic attributes
-just brings them on par.
-
-.. _inheritance:
-
-Inheritance and automatic downcasting
-=====================================
-
-Suppose now that the example consists of two data structures with an
-inheritance relationship:
-
-.. code-block:: cpp
-
-    struct Pet {
-        Pet(const std::string &name) : name(name) { }
-        std::string name;
-    };
-
-    struct Dog : Pet {
-        Dog(const std::string &name) : Pet(name) { }
-        std::string bark() const { return "woof!"; }
-    };
-
-There are two different ways of indicating a hierarchical relationship to
-pybind11: the first specifies the C++ base class as an extra template
-parameter of the :class:`class_`:
-
-.. code-block:: cpp
-
-    py::class_<Pet>(m, "Pet")
-       .def(py::init<const std::string &>())
-       .def_readwrite("name", &Pet::name);
-
-    // Method 1: template parameter:
-    py::class_<Dog, Pet /* <- specify C++ parent type */>(m, "Dog")
-        .def(py::init<const std::string &>())
-        .def("bark", &Dog::bark);
-
-Alternatively, we can also assign a name to the previously bound ``Pet``
-:class:`class_` object and reference it when binding the ``Dog`` class:
-
-.. code-block:: cpp
-
-    py::class_<Pet> pet(m, "Pet");
-    pet.def(py::init<const std::string &>())
-       .def_readwrite("name", &Pet::name);
-
-    // Method 2: pass parent class_ object:
-    py::class_<Dog>(m, "Dog", pet /* <- specify Python parent type */)
-        .def(py::init<const std::string &>())
-        .def("bark", &Dog::bark);
-
-Functionality-wise, both approaches are equivalent. Afterwards, instances will
-expose fields and methods of both types:
-
-.. code-block:: pycon
-
-    >>> p = example.Dog("Molly")
-    >>> p.name
-    'Molly'
-    >>> p.bark()
-    'woof!'
-
-The C++ classes defined above are regular non-polymorphic types with an
-inheritance relationship. This is reflected in Python:
-
-.. code-block:: cpp
-
-    // Return a base pointer to a derived instance
-    m.def("pet_store", []() { return std::unique_ptr<Pet>(new Dog("Molly")); });
-
-.. code-block:: pycon
-
-    >>> p = example.pet_store()
-    >>> type(p)  # `Dog` instance behind `Pet` pointer
-    Pet          # no pointer downcasting for regular non-polymorphic types
-    >>> p.bark()
-    AttributeError: 'Pet' object has no attribute 'bark'
-
-The function returned a ``Dog`` instance, but because it's a non-polymorphic
-type behind a base pointer, Python only sees a ``Pet``. In C++, a type is only
-considered polymorphic if it has at least one virtual function and pybind11
-will automatically recognize this:
-
-.. code-block:: cpp
-
-    struct PolymorphicPet {
-        virtual ~PolymorphicPet() = default;
-    };
-
-    struct PolymorphicDog : PolymorphicPet {
-        std::string bark() const { return "woof!"; }
-    };
-
-    // Same binding code
-    py::class_<PolymorphicPet>(m, "PolymorphicPet");
-    py::class_<PolymorphicDog, PolymorphicPet>(m, "PolymorphicDog")
-        .def(py::init<>())
-        .def("bark", &PolymorphicDog::bark);
-
-    // Again, return a base pointer to a derived instance
-    m.def("pet_store2", []() { return std::unique_ptr<PolymorphicPet>(new PolymorphicDog); });
-
-.. code-block:: pycon
-
-    >>> p = example.pet_store2()
-    >>> type(p)
-    PolymorphicDog  # automatically downcast
-    >>> p.bark()
-    'woof!'
-
-Given a pointer to a polymorphic base, pybind11 performs automatic downcasting
-to the actual derived type. Note that this goes beyond the usual situation in
-C++: we don't just get access to the virtual functions of the base, we get the
-concrete derived type including functions and attributes that the base type may
-not even be aware of.
-
-.. seealso::
-
-    For more information about polymorphic behavior see :ref:`overriding_virtuals`.
-
-
-Overloaded methods
-==================
-
-Sometimes there are several overloaded C++ methods with the same name taking
-different kinds of input arguments:
-
-.. code-block:: cpp
-
-    struct Pet {
-        Pet(const std::string &name, int age) : name(name), age(age) { }
-
-        void set(int age_) { age = age_; }
-        void set(const std::string &name_) { name = name_; }
-
-        std::string name;
-        int age;
-    };
-
-Attempting to bind ``Pet::set`` will cause an error since the compiler does not
-know which method the user intended to select. We can disambiguate by casting
-them to function pointers. Binding multiple functions to the same Python name
-automatically creates a chain of function overloads that will be tried in
-sequence.
-
-.. code-block:: cpp
-
-    py::class_<Pet>(m, "Pet")
-       .def(py::init<const std::string &, int>())
-       .def("set", static_cast<void (Pet::*)(int)>(&Pet::set), "Set the pet's age")
-       .def("set", static_cast<void (Pet::*)(const std::string &)>(&Pet::set), "Set the pet's name");
-
-The overload signatures are also visible in the method's docstring:
-
-.. code-block:: pycon
-
-    >>> help(example.Pet)
-
-    class Pet(__builtin__.object)
-     |  Methods defined here:
-     |
-     |  __init__(...)
-     |      Signature : (Pet, str, int) -> NoneType
-     |
-     |  set(...)
-     |      1. Signature : (Pet, int) -> NoneType
-     |
-     |      Set the pet's age
-     |
-     |      2. Signature : (Pet, str) -> NoneType
-     |
-     |      Set the pet's name
-
-If you have a C++14 compatible compiler [#cpp14]_, you can use an alternative
-syntax to cast the overloaded function:
-
-.. code-block:: cpp
-
-    py::class_<Pet>(m, "Pet")
-        .def("set", py::overload_cast<int>(&Pet::set), "Set the pet's age")
-        .def("set", py::overload_cast<const std::string &>(&Pet::set), "Set the pet's name");
-
-Here, ``py::overload_cast`` only requires the parameter types to be specified.
-The return type and class are deduced. This avoids the additional noise of
-``void (Pet::*)()`` as seen in the raw cast. If a function is overloaded based
-on constness, the ``py::const_`` tag should be used:
-
-.. code-block:: cpp
-
-    struct Widget {
-        int foo(int x, float y);
-        int foo(int x, float y) const;
-    };
-
-    py::class_<Widget>(m, "Widget")
-       .def("foo_mutable", py::overload_cast<int, float>(&Widget::foo))
-       .def("foo_const",   py::overload_cast<int, float>(&Widget::foo, py::const_));
-
-If you prefer the ``py::overload_cast`` syntax but have a C++11 compatible compiler only,
-you can use ``py::detail::overload_cast_impl`` with an additional set of parentheses:
-
-.. code-block:: cpp
-
-    template <typename... Args>
-    using overload_cast_ = pybind11::detail::overload_cast_impl<Args...>;
-
-    py::class_<Pet>(m, "Pet")
-        .def("set", overload_cast_<int>()(&Pet::set), "Set the pet's age")
-        .def("set", overload_cast_<const std::string &>()(&Pet::set), "Set the pet's name");
-
-.. [#cpp14] A compiler which supports the ``-std=c++14`` flag.
-
-.. note::
-
-    To define multiple overloaded constructors, simply declare one after the
-    other using the ``.def(py::init<...>())`` syntax. The existing machinery
-    for specifying keyword and default arguments also works.
-
-Enumerations and internal types
-===============================
-
-Let's now suppose that the example class contains internal types like enumerations, e.g.:
-
-.. code-block:: cpp
-
-    struct Pet {
-        enum Kind {
-            Dog = 0,
-            Cat
-        };
-
-        struct Attributes {
-            float age = 0;
-        };
-
-        Pet(const std::string &name, Kind type) : name(name), type(type) { }
-
-        std::string name;
-        Kind type;
-        Attributes attr;
-    };
-
-The binding code for this example looks as follows:
-
-.. code-block:: cpp
-
-    py::class_<Pet> pet(m, "Pet");
-
-    pet.def(py::init<const std::string &, Pet::Kind>())
-        .def_readwrite("name", &Pet::name)
-        .def_readwrite("type", &Pet::type)
-        .def_readwrite("attr", &Pet::attr);
-
-    py::enum_<Pet::Kind>(pet, "Kind")
-        .value("Dog", Pet::Kind::Dog)
-        .value("Cat", Pet::Kind::Cat)
-        .export_values();
-
-    py::class_<Pet::Attributes>(pet, "Attributes")
-        .def(py::init<>())
-        .def_readwrite("age", &Pet::Attributes::age);
-
-
-To ensure that the nested types ``Kind`` and ``Attributes`` are created within the scope of ``Pet``, the
-``pet`` :class:`class_` instance must be supplied to the :class:`enum_` and :class:`class_`
-constructor. The :func:`enum_::export_values` function exports the enum entries
-into the parent scope, which should be skipped for newer C++11-style strongly
-typed enums.
-
-.. code-block:: pycon
-
-    >>> p = Pet("Lucy", Pet.Cat)
-    >>> p.type
-    Kind.Cat
-    >>> int(p.type)
-    1L
-
-The entries defined by the enumeration type are exposed in the ``__members__`` property:
-
-.. code-block:: pycon
-
-    >>> Pet.Kind.__members__
-    {'Dog': Kind.Dog, 'Cat': Kind.Cat}
-
-The ``name`` property returns the name of the enum value as a unicode string.
-
-.. note::
-
-    It is also possible to use ``str(enum)``, however these accomplish different
-    goals. The following shows how these two approaches differ.
-
-    .. code-block:: pycon
-
-        >>> p = Pet("Lucy", Pet.Cat)
-        >>> pet_type = p.type
-        >>> pet_type
-        Pet.Cat
-        >>> str(pet_type)
-        'Pet.Cat'
-        >>> pet_type.name
-        'Cat'
-
-.. note::
-
-    When the special tag ``py::arithmetic()`` is specified to the ``enum_``
-    constructor, pybind11 creates an enumeration that also supports rudimentary
-    arithmetic and bit-level operations like comparisons, and, or, xor, negation,
-    etc.
-
-    .. code-block:: cpp
-
-        py::enum_<Pet::Kind>(pet, "Kind", py::arithmetic())
-           ...
-
-    By default, these are omitted to conserve space.
--- a/libs/pybind/docs/cmake/index.rst
+++ b/libs/pybind/docs/cmake/index.rst
@ -1,8 +0,0 @@
-CMake helpers
-------------
-
-Pybind11 can be used with ``add_subdirectory(extern/pybind11)``, or from an
-install with ``find_package(pybind11 CONFIG)``. The interface provided in
-either case is functionally identical.
-
-.. cmake-module:: ../../tools/pybind11Config.cmake.in
--- a/libs/pybind/docs/compiling.rst
+++ b/libs/pybind/docs/compiling.rst
@ -1,638 +0,0 @@
-.. _compiling:
-
-Build systems
-#############
-
-.. _build-setuptools:
-
-Building with setuptools
-========================
-
-For projects on PyPI, building with setuptools is the way to go. Sylvain Corlay
-has kindly provided an example project which shows how to set up everything,
-including automatic generation of documentation using Sphinx. Please refer to
-the [python_example]_ repository.
-
-.. [python_example] https://github.com/pybind/python_example
-
-A helper file is provided with pybind11 that can simplify usage with setuptools.
-
-To use pybind11 inside your ``setup.py``, you have to have some system to
-ensure that ``pybind11`` is installed when you build your package. There are
-four possible ways to do this, and pybind11 supports all four: You can ask all
-users to install pybind11 beforehand (bad), you can use
-:ref:`setup_helpers-pep518` (good, but very new and requires Pip 10),
-:ref:`setup_helpers-setup_requires` (discouraged by Python packagers now that
-PEP 518 is available, but it still works everywhere), or you can
-:ref:`setup_helpers-copy-manually` (always works but you have to manually sync
-your copy to get updates).
-
-An example of a ``setup.py`` using pybind11's helpers:
-
-.. code-block:: python
-
-    from glob import glob
-    from setuptools import setup
-    from pybind11.setup_helpers import Pybind11Extension
-
-    ext_modules = [
-        Pybind11Extension(
-            "python_example",
-            sorted(glob("src/*.cpp")),  # Sort source files for reproducibility
-        ),
-    ]
-
-    setup(..., ext_modules=ext_modules)
-
-If you want to do an automatic search for the highest supported C++ standard,
-that is supported via a ``build_ext`` command override; it will only affect
-``Pybind11Extensions``:
-
-.. code-block:: python
-
-    from glob import glob
-    from setuptools import setup
-    from pybind11.setup_helpers import Pybind11Extension, build_ext
-
-    ext_modules = [
-        Pybind11Extension(
-            "python_example",
-            sorted(glob("src/*.cpp")),
-        ),
-    ]
-
-    setup(..., cmdclass={"build_ext": build_ext}, ext_modules=ext_modules)
-
-If you have single-file extension modules that are directly stored in the
-Python source tree (``foo.cpp`` in the same directory as where a ``foo.py``
-would be located), you can also generate ``Pybind11Extensions`` using
-``setup_helpers.intree_extensions``: ``intree_extensions(["path/to/foo.cpp",
-...])`` returns a list of ``Pybind11Extensions`` which can be passed to
-``ext_modules``, possibly after further customizing their attributes
-(``libraries``, ``include_dirs``, etc.).  By doing so, a ``foo.*.so`` extension
-module will be generated and made available upon installation.
-
-``intree_extension`` will automatically detect if you are using a ``src``-style
-layout (as long as no namespace packages are involved), but you can also
-explicitly pass ``package_dir`` to it (as in ``setuptools.setup``).
-
-Since pybind11 does not require NumPy when building, a light-weight replacement
-for NumPy's parallel compilation distutils tool is included. Use it like this:
-
-.. code-block:: python
-
-    from pybind11.setup_helpers import ParallelCompile
-
-    # Optional multithreaded build
-    ParallelCompile("NPY_NUM_BUILD_JOBS").install()
-
-    setup(...)
-
-The argument is the name of an environment variable to control the number of
-threads, such as ``NPY_NUM_BUILD_JOBS`` (as used by NumPy), though you can set
-something different if you want; ``CMAKE_BUILD_PARALLEL_LEVEL`` is another choice
-a user might expect. You can also pass ``default=N`` to set the default number
-of threads (0 will take the number of threads available) and ``max=N``, the
-maximum number of threads; if you have a large extension you may want set this
-to a memory dependent number.
-
-If you are developing rapidly and have a lot of C++ files, you may want to
-avoid rebuilding files that have not changed. For simple cases were you are
-using ``pip install -e .`` and do not have local headers, you can skip the
-rebuild if an object file is newer than its source (headers are not checked!)
-with the following:
-
-.. code-block:: python
-
-    from pybind11.setup_helpers import ParallelCompile, naive_recompile
-
-    ParallelCompile("NPY_NUM_BUILD_JOBS", needs_recompile=naive_recompile).install()
-
-
-If you have a more complex build, you can implement a smarter function and pass
-it to ``needs_recompile``, or you can use [Ccache]_ instead. ``CXX="cache g++"
-pip install -e .`` would be the way to use it with GCC, for example. Unlike the
-simple solution, this even works even when not compiling in editable mode, but
-it does require Ccache to be installed.
-
-Keep in mind that Pip will not even attempt to rebuild if it thinks it has
-already built a copy of your code, which it deduces from the version number.
-One way to avoid this is to use [setuptools_scm]_, which will generate a
-version number that includes the number of commits since your last tag and a
-hash for a dirty directory. Another way to force a rebuild is purge your cache
-or use Pip's ``--no-cache-dir`` option.
-
-.. [Ccache] https://ccache.dev
-
-.. [setuptools_scm] https://github.com/pypa/setuptools_scm
-
-.. _setup_helpers-pep518:
-
-PEP 518 requirements (Pip 10+ required)
---------------------------------------
-
-If you use `PEP 518's <https://www.python.org/dev/peps/pep-0518/>`_
-``pyproject.toml`` file, you can ensure that ``pybind11`` is available during
-the compilation of your project.  When this file exists, Pip will make a new
-virtual environment, download just the packages listed here in ``requires=``,
-and build a wheel (binary Python package). It will then throw away the
-environment, and install your wheel.
-
-Your ``pyproject.toml`` file will likely look something like this:
-
-.. code-block:: toml
-
-    [build-system]
-    requires = ["setuptools>=42", "wheel", "pybind11~=2.6.1"]
-    build-backend = "setuptools.build_meta"
-
-.. note::
-
-    The main drawback to this method is that a `PEP 517`_ compliant build tool,
-    such as Pip 10+, is required for this approach to work; older versions of
-    Pip completely ignore this file. If you distribute binaries (called wheels
-    in Python) using something like `cibuildwheel`_, remember that ``setup.py``
-    and ``pyproject.toml`` are not even contained in the wheel, so this high
-    Pip requirement is only for source builds, and will not affect users of
-    your binary wheels. If you are building SDists and wheels, then
-    `pypa-build`_ is the recommended official tool.
-
-.. _PEP 517: https://www.python.org/dev/peps/pep-0517/
-.. _cibuildwheel: https://cibuildwheel.readthedocs.io
-.. _pypa-build: https://pypa-build.readthedocs.io/en/latest/
-
-.. _setup_helpers-setup_requires:
-
-Classic ``setup_requires``
--------------------------
-
-If you want to support old versions of Pip with the classic
-``setup_requires=["pybind11"]`` keyword argument to setup, which triggers a
-two-phase ``setup.py`` run, then you will need to use something like this to
-ensure the first pass works (which has not yet installed the ``setup_requires``
-packages, since it can't install something it does not know about):
-
-.. code-block:: python
-
-    try:
-        from pybind11.setup_helpers import Pybind11Extension
-    except ImportError:
-        from setuptools import Extension as Pybind11Extension
-
-
-It doesn't matter that the Extension class is not the enhanced subclass for the
-first pass run; and the second pass will have the ``setup_requires``
-requirements.
-
-This is obviously more of a hack than the PEP 518 method, but it supports
-ancient versions of Pip.
-
-.. _setup_helpers-copy-manually:
-
-Copy manually
-------------
-
-You can also copy ``setup_helpers.py`` directly to your project; it was
-designed to be usable standalone, like the old example ``setup.py``. You can
-set ``include_pybind11=False`` to skip including the pybind11 package headers,
-so you can use it with git submodules and a specific git version. If you use
-this, you will need to import from a local file in ``setup.py`` and ensure the
-helper file is part of your MANIFEST.
-
-
-Closely related, if you include pybind11 as a subproject, you can run the
-``setup_helpers.py`` inplace. If loaded correctly, this should even pick up
-the correct include for pybind11, though you can turn it off as shown above if
-you want to input it manually.
-
-Suggested usage if you have pybind11 as a submodule in ``extern/pybind11``:
-
-.. code-block:: python
-
-    DIR = os.path.abspath(os.path.dirname(__file__))
-
-    sys.path.append(os.path.join(DIR, "extern", "pybind11"))
-    from pybind11.setup_helpers import Pybind11Extension  # noqa: E402
-
-    del sys.path[-1]
-
-
-.. versionchanged:: 2.6
-
-    Added ``setup_helpers`` file.
-
-Building with cppimport
-========================
-
-[cppimport]_ is a small Python import hook that determines whether there is a C++
-source file whose name matches the requested module. If there is, the file is
-compiled as a Python extension using pybind11 and placed in the same folder as
-the C++ source file. Python is then able to find the module and load it.
-
-.. [cppimport] https://github.com/tbenthompson/cppimport
-
-.. _cmake:
-
-Building with CMake
-===================
-
-For C++ codebases that have an existing CMake-based build system, a Python
-extension module can be created with just a few lines of code:
-
-.. code-block:: cmake
-
-    cmake_minimum_required(VERSION 3.4...3.18)
-    project(example LANGUAGES CXX)
-
-    add_subdirectory(pybind11)
-    pybind11_add_module(example example.cpp)
-
-This assumes that the pybind11 repository is located in a subdirectory named
-:file:`pybind11` and that the code is located in a file named :file:`example.cpp`.
-The CMake command ``add_subdirectory`` will import the pybind11 project which
-provides the ``pybind11_add_module`` function. It will take care of all the
-details needed to build a Python extension module on any platform.
-
-A working sample project, including a way to invoke CMake from :file:`setup.py` for
-PyPI integration, can be found in the [cmake_example]_  repository.
-
-.. [cmake_example] https://github.com/pybind/cmake_example
-
-.. versionchanged:: 2.6
-   CMake 3.4+ is required.
-
-Further information can be found at :doc:`cmake/index`.
-
-pybind11_add_module
-------------------
-
-To ease the creation of Python extension modules, pybind11 provides a CMake
-function with the following signature:
-
-.. code-block:: cmake
-
-    pybind11_add_module(<name> [MODULE | SHARED] [EXCLUDE_FROM_ALL]
-                        [NO_EXTRAS] [THIN_LTO] [OPT_SIZE] source1 [source2 ...])
-
-This function behaves very much like CMake's builtin ``add_library`` (in fact,
-it's a wrapper function around that command). It will add a library target
-called ``<name>`` to be built from the listed source files. In addition, it
-will take care of all the Python-specific compiler and linker flags as well
-as the OS- and Python-version-specific file extension. The produced target
-``<name>`` can be further manipulated with regular CMake commands.
-
-``MODULE`` or ``SHARED`` may be given to specify the type of library. If no
-type is given, ``MODULE`` is used by default which ensures the creation of a
-Python-exclusive module. Specifying ``SHARED`` will create a more traditional
-dynamic library which can also be linked from elsewhere. ``EXCLUDE_FROM_ALL``
-removes this target from the default build (see CMake docs for details).
-
-Since pybind11 is a template library, ``pybind11_add_module`` adds compiler
-flags to ensure high quality code generation without bloat arising from long
-symbol names and duplication of code in different translation units. It
-sets default visibility to *hidden*, which is required for some pybind11
-features and functionality when attempting to load multiple pybind11 modules
-compiled under different pybind11 versions.  It also adds additional flags
-enabling LTO (Link Time Optimization) and strip unneeded symbols. See the
-:ref:`FAQ entry <faq:symhidden>` for a more detailed explanation. These
-latter optimizations are never applied in ``Debug`` mode.  If ``NO_EXTRAS`` is
-given, they will always be disabled, even in ``Release`` mode. However, this
-will result in code bloat and is generally not recommended.
-
-As stated above, LTO is enabled by default. Some newer compilers also support
-different flavors of LTO such as `ThinLTO`_. Setting ``THIN_LTO`` will cause
-the function to prefer this flavor if available. The function falls back to
-regular LTO if ``-flto=thin`` is not available. If
-``CMAKE_INTERPROCEDURAL_OPTIMIZATION`` is set (either ``ON`` or ``OFF``), then
-that will be respected instead of the built-in flag search.
-
-.. note::
-
-   If you want to set the property form on targets or the
-   ``CMAKE_INTERPROCEDURAL_OPTIMIZATION_<CONFIG>`` versions of this, you should
-   still use ``set(CMAKE_INTERPROCEDURAL_OPTIMIZATION OFF)`` (otherwise a
-   no-op) to disable pybind11's ipo flags.
-
-The ``OPT_SIZE`` flag enables size-based optimization equivalent to the
-standard ``/Os`` or ``-Os`` compiler flags and the ``MinSizeRel`` build type,
-which avoid optimizations that that can substantially increase the size of the
-resulting binary. This flag is particularly useful in projects that are split
-into performance-critical parts and associated bindings. In this case, we can
-compile the project in release mode (and hence, optimize performance globally),
-and specify ``OPT_SIZE`` for the binding target, where size might be the main
-concern as performance is often less critical here. A ~25% size reduction has
-been observed in practice. This flag only changes the optimization behavior at
-a per-target level and takes precedence over the global CMake build type
-(``Release``, ``RelWithDebInfo``) except for ``Debug`` builds, where
-optimizations remain disabled.
-
-.. _ThinLTO: http://clang.llvm.org/docs/ThinLTO.html
-
-Configuration variables
-----------------------
-
-By default, pybind11 will compile modules with the compiler default or the
-minimum standard required by pybind11, whichever is higher.  You can set the
-standard explicitly with
-`CMAKE_CXX_STANDARD <https://cmake.org/cmake/help/latest/variable/CMAKE_CXX_STANDARD.html>`_:
-
-.. code-block:: cmake
-
-    set(CMAKE_CXX_STANDARD 14 CACHE STRING "C++ version selection")  # or 11, 14, 17, 20
-    set(CMAKE_CXX_STANDARD_REQUIRED ON)  # optional, ensure standard is supported
-    set(CMAKE_CXX_EXTENSIONS OFF)  # optional, keep compiler extensions off
-
-The variables can also be set when calling CMake from the command line using
-the ``-D<variable>=<value>`` flag. You can also manually set ``CXX_STANDARD``
-on a target or use ``target_compile_features`` on your targets - anything that
-CMake supports.
-
-Classic Python support: The target Python version can be selected by setting
-``PYBIND11_PYTHON_VERSION`` or an exact Python installation can be specified
-with ``PYTHON_EXECUTABLE``.  For example:
-
-.. code-block:: bash
-
-    cmake -DPYBIND11_PYTHON_VERSION=3.6 ..
-
-    # Another method:
-    cmake -DPYTHON_EXECUTABLE=/path/to/python ..
-
-    # This often is a good way to get the current Python, works in environments:
-    cmake -DPYTHON_EXECUTABLE=$(python3 -c "import sys; print(sys.executable)") ..
-
-
-find_package vs. add_subdirectory
---------------------------------
-
-For CMake-based projects that don't include the pybind11 repository internally,
-an external installation can be detected through ``find_package(pybind11)``.
-See the `Config file`_ docstring for details of relevant CMake variables.
-
-.. code-block:: cmake
-
-    cmake_minimum_required(VERSION 3.4...3.18)
-    project(example LANGUAGES CXX)
-
-    find_package(pybind11 REQUIRED)
-    pybind11_add_module(example example.cpp)
-
-Note that ``find_package(pybind11)`` will only work correctly if pybind11
-has been correctly installed on the system, e. g. after downloading or cloning
-the pybind11 repository  :
-
-.. code-block:: bash
-
-    # Classic CMake
-    cd pybind11
-    mkdir build
-    cd build
-    cmake ..
-    make install
-
-    # CMake 3.15+
-    cd pybind11
-    cmake -S . -B build
-    cmake --build build -j 2  # Build on 2 cores
-    cmake --install build
-
-Once detected, the aforementioned ``pybind11_add_module`` can be employed as
-before. The function usage and configuration variables are identical no matter
-if pybind11 is added as a subdirectory or found as an installed package. You
-can refer to the same [cmake_example]_ repository for a full sample project
-- just swap out ``add_subdirectory`` for ``find_package``.
-
-.. _Config file: https://github.com/pybind/pybind11/blob/master/tools/pybind11Config.cmake.in
-
-
-.. _find-python-mode:
-
-FindPython mode
---------------
-
-CMake 3.12+ (3.15+ recommended, 3.18.2+ ideal) added a new module called
-FindPython that had a highly improved search algorithm and modern targets
-and tools. If you use FindPython, pybind11 will detect this and use the
-existing targets instead:
-
-.. code-block:: cmake
-
-    cmake_minimum_required(VERSION 3.15...3.22)
-    project(example LANGUAGES CXX)
-
-    find_package(Python 3.6 COMPONENTS Interpreter Development REQUIRED)
-    find_package(pybind11 CONFIG REQUIRED)
-    # or add_subdirectory(pybind11)
-
-    pybind11_add_module(example example.cpp)
-
-You can also use the targets (as listed below) with FindPython. If you define
-``PYBIND11_FINDPYTHON``, pybind11 will perform the FindPython step for you
-(mostly useful when building pybind11's own tests, or as a way to change search
-algorithms from the CMake invocation, with ``-DPYBIND11_FINDPYTHON=ON``.
-
-.. warning::
-
-    If you use FindPython to multi-target Python versions, use the individual
-    targets listed below, and avoid targets that directly include Python parts.
-
-There are `many ways to hint or force a discovery of a specific Python
-installation <https://cmake.org/cmake/help/latest/module/FindPython.html>`_),
-setting ``Python_ROOT_DIR`` may be the most common one (though with
-virtualenv/venv support, and Conda support, this tends to find the correct
-Python version more often than the old system did).
-
-.. warning::
-
-    When the Python libraries (i.e. ``libpythonXX.a`` and ``libpythonXX.so``
-    on Unix) are not available, as is the case on a manylinux image, the
-    ``Development`` component will not be resolved by ``FindPython``. When not
-    using the embedding functionality, CMake 3.18+ allows you to specify
-    ``Development.Module`` instead of ``Development`` to resolve this issue.
-
-.. versionadded:: 2.6
-
-Advanced: interface library targets
-----------------------------------
-
-Pybind11 supports modern CMake usage patterns with a set of interface targets,
-available in all modes. The targets provided are:
-
-   ``pybind11::headers``
-     Just the pybind11 headers and minimum compile requirements
-
-   ``pybind11::pybind11``
-     Python headers + ``pybind11::headers``
-
-   ``pybind11::python_link_helper``
-     Just the "linking" part of pybind11:module
-
-   ``pybind11::module``
-     Everything for extension modules - ``pybind11::pybind11`` + ``Python::Module`` (FindPython CMake 3.15+) or ``pybind11::python_link_helper``
-
-   ``pybind11::embed``
-     Everything for embedding the Python interpreter - ``pybind11::pybind11`` + ``Python::Python`` (FindPython) or Python libs
-
-   ``pybind11::lto`` / ``pybind11::thin_lto``
-     An alternative to `INTERPROCEDURAL_OPTIMIZATION` for adding link-time optimization.
-
-   ``pybind11::windows_extras``
-     ``/bigobj`` and ``/mp`` for MSVC.
-
-   ``pybind11::opt_size``
-     ``/Os`` for MSVC, ``-Os`` for other compilers. Does nothing for debug builds.
-
-Two helper functions are also provided:
-
-    ``pybind11_strip(target)``
-      Strips a target (uses ``CMAKE_STRIP`` after the target is built)
-
-    ``pybind11_extension(target)``
-      Sets the correct extension (with SOABI) for a target.
-
-You can use these targets to build complex applications. For example, the
-``add_python_module`` function is identical to:
-
-.. code-block:: cmake
-
-    cmake_minimum_required(VERSION 3.4)
-    project(example LANGUAGES CXX)
-
-    find_package(pybind11 REQUIRED)  # or add_subdirectory(pybind11)
-
-    add_library(example MODULE main.cpp)
-
-    target_link_libraries(example PRIVATE pybind11::module pybind11::lto pybind11::windows_extras)
-
-    pybind11_extension(example)
-    if(NOT MSVC AND NOT ${CMAKE_BUILD_TYPE} MATCHES Debug|RelWithDebInfo)
-        # Strip unnecessary sections of the binary on Linux/macOS
-        pybind11_strip(example)
-    endif()
-
-    set_target_properties(example PROPERTIES CXX_VISIBILITY_PRESET "hidden"
-                                             CUDA_VISIBILITY_PRESET "hidden")
-
-Instead of setting properties, you can set ``CMAKE_*`` variables to initialize these correctly.
-
-.. warning::
-
-    Since pybind11 is a metatemplate library, it is crucial that certain
-    compiler flags are provided to ensure high quality code generation. In
-    contrast to the ``pybind11_add_module()`` command, the CMake interface
-    provides a *composable* set of targets to ensure that you retain flexibility.
-    It can be especially important to provide or set these properties; the
-    :ref:`FAQ <faq:symhidden>` contains an explanation on why these are needed.
-
-.. versionadded:: 2.6
-
-.. _nopython-mode:
-
-Advanced: NOPYTHON mode
-----------------------
-
-If you want complete control, you can set ``PYBIND11_NOPYTHON`` to completely
-disable Python integration (this also happens if you run ``FindPython2`` and
-``FindPython3`` without running ``FindPython``). This gives you complete
-freedom to integrate into an existing system (like `Scikit-Build's
-<https://scikit-build.readthedocs.io>`_ ``PythonExtensions``).
-``pybind11_add_module`` and ``pybind11_extension`` will be unavailable, and the
-targets will be missing any Python specific behavior.
-
-.. versionadded:: 2.6
-
-Embedding the Python interpreter
--------------------------------
-
-In addition to extension modules, pybind11 also supports embedding Python into
-a C++ executable or library. In CMake, simply link with the ``pybind11::embed``
-target. It provides everything needed to get the interpreter running. The Python
-headers and libraries are attached to the target. Unlike ``pybind11::module``,
-there is no need to manually set any additional properties here. For more
-information about usage in C++, see :doc:`/advanced/embedding`.
-
-.. code-block:: cmake
-
-    cmake_minimum_required(VERSION 3.4...3.18)
-    project(example LANGUAGES CXX)
-
-    find_package(pybind11 REQUIRED)  # or add_subdirectory(pybind11)
-
-    add_executable(example main.cpp)
-    target_link_libraries(example PRIVATE pybind11::embed)
-
-.. _building_manually:
-
-Building manually
-=================
-
-pybind11 is a header-only library, hence it is not necessary to link against
-any special libraries and there are no intermediate (magic) translation steps.
-
-On Linux, you can compile an example such as the one given in
-:ref:`simple_example` using the following command:
-
-.. code-block:: bash
-
-    $ c++ -O3 -Wall -shared -std=c++11 -fPIC $(python3 -m pybind11 --includes) example.cpp -o example$(python3-config --extension-suffix)
-
-The ``python3 -m pybind11 --includes`` command fetches the include paths for
-both pybind11 and Python headers. This assumes that pybind11 has been installed
-using ``pip`` or ``conda``. If it hasn't, you can also manually specify
-``-I <path-to-pybind11>/include`` together with the Python includes path
-``python3-config --includes``.
-
-On macOS: the build command is almost the same but it also requires passing
-the ``-undefined dynamic_lookup`` flag so as to ignore missing symbols when
-building the module:
-
-.. code-block:: bash
-
-    $ c++ -O3 -Wall -shared -std=c++11 -undefined dynamic_lookup $(python3 -m pybind11 --includes) example.cpp -o example$(python3-config --extension-suffix)
-
-In general, it is advisable to include several additional build parameters
-that can considerably reduce the size of the created binary. Refer to section
-:ref:`cmake` for a detailed example of a suitable cross-platform CMake-based
-build system that works on all platforms including Windows.
-
-.. note::
-
-    On Linux and macOS, it's better to (intentionally) not link against
-    ``libpython``. The symbols will be resolved when the extension library
-    is loaded into a Python binary. This is preferable because you might
-    have several different installations of a given Python version (e.g. the
-    system-provided Python, and one that ships with a piece of commercial
-    software). In this way, the plugin will work with both versions, instead
-    of possibly importing a second Python library into a process that already
-    contains one (which will lead to a segfault).
-
-
-Building with Bazel
-===================
-
-You can build with the Bazel build system using the `pybind11_bazel
-<https://github.com/pybind/pybind11_bazel>`_ repository.
-
-Generating binding code automatically
-=====================================
-
-The ``Binder`` project is a tool for automatic generation of pybind11 binding
-code by introspecting existing C++ codebases using LLVM/Clang. See the
-[binder]_ documentation for details.
-
-.. [binder] http://cppbinder.readthedocs.io/en/latest/about.html
-
-[AutoWIG]_ is a Python library that wraps automatically compiled libraries into
-high-level languages. It parses C++ code using LLVM/Clang technologies and
-generates the wrappers using the Mako templating engine. The approach is automatic,
-extensible, and applies to very complex C++ libraries, composed of thousands of
-classes or incorporating modern meta-programming constructs.
-
-.. [AutoWIG] https://github.com/StatisKit/AutoWIG
-
-[robotpy-build]_ is a is a pure python, cross platform build tool that aims to
-simplify creation of python wheels for pybind11 projects, and provide
-cross-project dependency management. Additionally, it is able to autogenerate
-customizable pybind11-based wrappers by parsing C++ header files.
-
-.. [robotpy-build] https://robotpy-build.readthedocs.io
--- a/libs/pybind/docs/conf.py
+++ b/libs/pybind/docs/conf.py
@ -1,369 +0,0 @@
-#!/usr/bin/env python3
-#
-# pybind11 documentation build configuration file, created by
-# sphinx-quickstart on Sun Oct 11 19:23:48 2015.
-#
-# This file is execfile()d with the current directory set to its
-# containing dir.
-#
-# Note that not all possible configuration values are present in this
-# autogenerated file.
-#
-# All configuration values have a default; values that are commented out
-# serve to show the default.
-
-import os
-import re
-import subprocess
-import sys
-from pathlib import Path
-
-DIR = Path(__file__).parent.resolve()
-
-# If extensions (or modules to document with autodoc) are in another directory,
-# add these directories to sys.path here. If the directory is relative to the
-# documentation root, use os.path.abspath to make it absolute, like shown here.
-# sys.path.insert(0, os.path.abspath('.'))
-
-# -- General configuration ------------------------------------------------
-
-# If your documentation needs a minimal Sphinx version, state it here.
-# needs_sphinx = '1.0'
-
-# Add any Sphinx extension module names here, as strings. They can be
-# extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
-# ones.
-extensions = [
-    "breathe",
-    "sphinx_copybutton",
-    "sphinxcontrib.rsvgconverter",
-    "sphinxcontrib.moderncmakedomain",
-]
-
-breathe_projects = {"pybind11": ".build/doxygenxml/"}
-breathe_default_project = "pybind11"
-breathe_domain_by_extension = {"h": "cpp"}
-
-# Add any paths that contain templates here, relative to this directory.
-templates_path = [".templates"]
-
-# The suffix(es) of source filenames.
-# You can specify multiple suffix as a list of string:
-# source_suffix = ['.rst', '.md']
-source_suffix = ".rst"
-
-# The encoding of source files.
-# source_encoding = 'utf-8-sig'
-
-# The master toctree document.
-master_doc = "index"
-
-# General information about the project.
-project = "pybind11"
-copyright = "2017, Wenzel Jakob"
-author = "Wenzel Jakob"
-
-# The version info for the project you're documenting, acts as replacement for
-# |version| and |release|, also used in various other places throughout the
-# built documents.
-
-# Read the listed version
-with open("../pybind11/_version.py") as f:
-    code = compile(f.read(), "../pybind11/_version.py", "exec")
-loc = {}
-exec(code, loc)
-
-# The full version, including alpha/beta/rc tags.
-version = loc["__version__"]
-
-# The language for content autogenerated by Sphinx. Refer to documentation
-# for a list of supported languages.
-#
-# This is also used if you do content translation via gettext catalogs.
-# Usually you set "language" from the command line for these cases.
-language = None
-
-# There are two options for replacing |today|: either, you set today to some
-# non-false value, then it is used:
-# today = ''
-# Else, today_fmt is used as the format for a strftime call.
-# today_fmt = '%B %d, %Y'
-
-# List of patterns, relative to source directory, that match files and
-# directories to ignore when looking for source files.
-exclude_patterns = [".build", "release.rst"]
-
-# The reST default role (used for this markup: `text`) to use for all
-# documents.
-default_role = "any"
-
-# If true, '()' will be appended to :func: etc. cross-reference text.
-# add_function_parentheses = True
-
-# If true, the current module name will be prepended to all description
-# unit titles (such as .. function::).
-# add_module_names = True
-
-# If true, sectionauthor and moduleauthor directives will be shown in the
-# output. They are ignored by default.
-# show_authors = False
-
-# The name of the Pygments (syntax highlighting) style to use.
-# pygments_style = 'monokai'
-
-# A list of ignored prefixes for module index sorting.
-# modindex_common_prefix = []
-
-# If true, keep warnings as "system message" paragraphs in the built documents.
-# keep_warnings = False
-
-# If true, `todo` and `todoList` produce output, else they produce nothing.
-todo_include_todos = False
-
-
-# -- Options for HTML output ----------------------------------------------
-
-# The theme to use for HTML and HTML Help pages.  See the documentation for
-# a list of builtin themes.
-
-html_theme = "furo"
-
-# Theme options are theme-specific and customize the look and feel of a theme
-# further.  For a list of options available for each theme, see the
-# documentation.
-# html_theme_options = {}
-
-# Add any paths that contain custom themes here, relative to this directory.
-# html_theme_path = []
-
-# The name for this set of Sphinx documents.  If None, it defaults to
-# "<project> v<version> documentation".
-# html_title = None
-
-# A shorter title for the navigation bar.  Default is the same as html_title.
-# html_short_title = None
-
-# The name of an image file (relative to this directory) to place at the top
-# of the sidebar.
-# html_logo = None
-
-# The name of an image file (within the static path) to use as favicon of the
-# docs.  This file should be a Windows icon file (.ico) being 16x16 or 32x32
-# pixels large.
-# html_favicon = None
-
-# Add any paths that contain custom static files (such as style sheets) here,
-# relative to this directory. They are copied after the builtin static files,
-# so a file named "default.css" will overwrite the builtin "default.css".
-html_static_path = ["_static"]
-
-html_css_files = [
-    "css/custom.css",
-]
-
-# Add any extra paths that contain custom files (such as robots.txt or
-# .htaccess) here, relative to this directory. These files are copied
-# directly to the root of the documentation.
-# html_extra_path = []
-
-# If not '', a 'Last updated on:' timestamp is inserted at every page bottom,
-# using the given strftime format.
-# html_last_updated_fmt = '%b %d, %Y'
-
-# If true, SmartyPants will be used to convert quotes and dashes to
-# typographically correct entities.
-# html_use_smartypants = True
-
-# Custom sidebar templates, maps document names to template names.
-# html_sidebars = {}
-
-# Additional templates that should be rendered to pages, maps page names to
-# template names.
-# html_additional_pages = {}
-
-# If false, no module index is generated.
-# html_domain_indices = True
-
-# If false, no index is generated.
-# html_use_index = True
-
-# If true, the index is split into individual pages for each letter.
-# html_split_index = False
-
-# If true, links to the reST sources are added to the pages.
-# html_show_sourcelink = True
-
-# If true, "Created using Sphinx" is shown in the HTML footer. Default is True.
-# html_show_sphinx = True
-
-# If true, "(C) Copyright ..." is shown in the HTML footer. Default is True.
-# html_show_copyright = True
-
-# If true, an OpenSearch description file will be output, and all pages will
-# contain a <link> tag referring to it.  The value of this option must be the
-# base URL from which the finished HTML is served.
-# html_use_opensearch = ''
-
-# This is the file name suffix for HTML files (e.g. ".xhtml").
-# html_file_suffix = None
-
-# Language to be used for generating the HTML full-text search index.
-# Sphinx supports the following languages:
-#   'da', 'de', 'en', 'es', 'fi', 'fr', 'h', 'it', 'ja'
-#   'nl', 'no', 'pt', 'ro', 'r', 'sv', 'tr'
-# html_search_language = 'en'
-
-# A dictionary with options for the search language support, empty by default.
-# Now only 'ja' uses this config value
-# html_search_options = {'type': 'default'}
-
-# The name of a javascript file (relative to the configuration directory) that
-# implements a search results scorer. If empty, the default will be used.
-# html_search_scorer = 'scorer.js'
-
-# Output file base name for HTML help builder.
-htmlhelp_basename = "pybind11doc"
-
-# -- Options for LaTeX output ---------------------------------------------
-
-latex_engine = "pdflatex"
-
-latex_elements = {
-    # The paper size ('letterpaper' or 'a4paper').
-    # 'papersize': 'letterpaper',
-    #
-    # The font size ('10pt', '11pt' or '12pt').
-    # 'pointsize': '10pt',
-    #
-    # Additional stuff for the LaTeX preamble.
-    # remove blank pages (between the title page and the TOC, etc.)
-    "classoptions": ",openany,oneside",
-    "preamble": r"""
-\usepackage{fontawesome}
-\usepackage{textgreek}
-\DeclareUnicodeCharacter{00A0}{}
-\DeclareUnicodeCharacter{2194}{\faArrowsH}
-\DeclareUnicodeCharacter{1F382}{\faBirthdayCake}
-\DeclareUnicodeCharacter{1F355}{\faAdjust}
-\DeclareUnicodeCharacter{0301}{'}
-\DeclareUnicodeCharacter{03C0}{\textpi}
-
-""",
-    # Latex figure (float) alignment
-    # 'figure_align': 'htbp',
-}
-
-# Grouping the document tree into LaTeX files. List of tuples
-# (source start file, target name, title,
-#  author, documentclass [howto, manual, or own class]).
-latex_documents = [
-    (master_doc, "pybind11.tex", "pybind11 Documentation", "Wenzel Jakob", "manual"),
-]
-
-# The name of an image file (relative to this directory) to place at the top of
-# the title page.
-# latex_logo = 'pybind11-logo.png'
-
-# For "manual" documents, if this is true, then toplevel headings are parts,
-# not chapters.
-# latex_use_parts = False
-
-# If true, show page references after internal links.
-# latex_show_pagerefs = False
-
-# If true, show URL addresses after external links.
-# latex_show_urls = False
-
-# Documents to append as an appendix to all manuals.
-# latex_appendices = []
-
-# If false, no module index is generated.
-# latex_domain_indices = True
-
-
-# -- Options for manual page output ---------------------------------------
-
-# One entry per manual page. List of tuples
-# (source start file, name, description, authors, manual section).
-man_pages = [(master_doc, "pybind11", "pybind11 Documentation", [author], 1)]
-
-# If true, show URL addresses after external links.
-# man_show_urls = False
-
-
-# -- Options for Texinfo output -------------------------------------------
-
-# Grouping the document tree into Texinfo files. List of tuples
-# (source start file, target name, title, author,
-#  dir menu entry, description, category)
-texinfo_documents = [
-    (
-        master_doc,
-        "pybind11",
-        "pybind11 Documentation",
-        author,
-        "pybind11",
-        "One line description of project.",
-        "Miscellaneous",
-    ),
-]
-
-# Documents to append as an appendix to all manuals.
-# texinfo_appendices = []
-
-# If false, no module index is generated.
-# texinfo_domain_indices = True
-
-# How to display URL addresses: 'footnote', 'no', or 'inline'.
-# texinfo_show_urls = 'footnote'
-
-# If true, do not generate a @detailmenu in the "Top" node's menu.
-# texinfo_no_detailmenu = False
-
-primary_domain = "cpp"
-highlight_language = "cpp"
-
-
-def generate_doxygen_xml(app):
-    build_dir = os.path.join(app.confdir, ".build")
-    if not os.path.exists(build_dir):
-        os.mkdir(build_dir)
-
-    try:
-        subprocess.call(["doxygen", "--version"])
-        retcode = subprocess.call(["doxygen"], cwd=app.confdir)
-        if retcode < 0:
-            sys.stderr.write(f"doxygen error code: {-retcode}\n")
-    except OSError as e:
-        sys.stderr.write(f"doxygen execution failed: {e}\n")
-
-
-def prepare(app):
-    with open(DIR.parent / "README.rst") as f:
-        contents = f.read()
-
-    if app.builder.name == "latex":
-        # Remove badges and stuff from start
-        contents = contents[contents.find(r".. start") :]
-
-        # Filter out section titles for index.rst for LaTeX
-        contents = re.sub(r"^(.*)\n[-~]{3,}$", r"**\1**", contents, flags=re.MULTILINE)
-
-    with open(DIR / "readme.rst", "w") as f:
-        f.write(contents)
-
-
-def clean_up(app, exception):
-    (DIR / "readme.rst").unlink()
-
-
-def setup(app):
-
-    # Add hook for building doxygen xml when needed
-    app.connect("builder-inited", generate_doxygen_xml)
-
-    # Copy the readme in
-    app.connect("builder-inited", prepare)
-
-    # Clean up the generated readme
-    app.connect("build-finished", clean_up)
--- a/Show More
+++ b/Show More
Author	SHA1	Message	Date
Erik Frojdh	4a6693de3f	recepie for ctbgui	2022-05-02 12:03:59 +02:00
Erik Frojdh	a891db8d06	WIP	2022-04-29 15:59:26 +02:00