doc: clean up syntax highlighting 69/5069/3
authorMatthias Diener <mdiener@illinois.edu>
Tue, 9 Apr 2019 21:36:25 +0000 (16:36 -0500)
committerMatthias Diener <mdiener@illinois.edu>
Tue, 9 Apr 2019 21:39:51 +0000 (15:39 -0600)
- always put language explicitly, not via '::'
- fix a few misidentified code block languages
- use 'c++' language instead of 'cpp', 'c', 'C'

Change-Id: Ie40bc67ed1385aef3b59f7c1ac6c38e16f108758

22 files changed:
doc/README.rst
doc/ampi/manual.rst
doc/armci/manual.rst
doc/bignetsim/manual.rst
doc/bigsim/manual.rst
doc/charisma/manual.rst
doc/charj/manual.rst
doc/charm++/manual.rst
doc/converse/manual.rst
doc/convext/manual.rst
doc/debugger/manual.rst
doc/f90charm/manual.rst
doc/faq/manual.rst
doc/fem/manual.rst
doc/ifem/manual.rst
doc/jade/manual.rst
doc/libraries/manual.rst
doc/mblock/manual.rst
doc/netfem/manual.rst
doc/pose/manual.rst
doc/projections/manual.rst
doc/tcharm/manual.rst

index e4f51104aedb1ef547ab1003f948b4ca379ac6c2..bc9ea2754a83cb504b5912c3c83fdba56a253c7e 100644 (file)
@@ -51,7 +51,7 @@ Lists
 
 - Itemized:
 
-  ::
+  .. code-block:: none
 
     - Item 1
     - Item 2
@@ -59,7 +59,7 @@ Lists
 
 - Enumerated:
 
-  ::
+  .. code-block:: none
 
     #. Item 1
     #. Item 2
@@ -70,7 +70,7 @@ Sections
 
 Sections get defined by underlining their title:
 
-::
+.. code-block:: none
 
   Section name
   ============
@@ -93,34 +93,26 @@ Code
 
 - Code blocks (similar to ``\begin{alltt} .. \end{alltt}``):
 
-  - Code blocks have syntax highlighting for C++ by default, via the pygments
+  - Code blocks have syntax highlighting via the pygments
     (http://pygments.org) library.
 
-  - Automatic syntax highlighting (default language: C++): ``::``
+  - Do not use the default ``::`` highlighting mode, but specify the
+    language explicitly: ``.. code-block:: fortran`` (or ``c++``, ``none``, ...)
 
-    ::
-
-      ::
-
-        int foo();
-        int bar();
-
-  - Specify language: ``.. code-block:: fortran`` instead of ``::``
-
-    ::
+    .. code-block:: none
 
       .. code-block:: fortran
 
         call foo()
         call bar()
 
-  Versions of pygments newer than 2.3.1 allow specifying ``charmci`` as the
-  language for ci-files (instead of the default C++).
+  Versions of pygments newer than 2.3.1 will allow specifying ``charmci`` as the
+  language for ci-files (instead of using C++).
 
 Figures
 -------
 
-::
+.. code-block:: none
 
   .. figure:: figures/detailedsim_newer.png
     :name: BigNetSim1
@@ -134,7 +126,7 @@ Tables
 
 Code:
 
-::
+.. code-block:: none
 
   .. table:: Table caption goes here.
     :name: tableref
@@ -169,7 +161,7 @@ Adding reference labels
 Labels to refer to tables and figures are created by the ``:name:`` property above.
 Create labels for sections like this:
 
-::
+.. code-block:: none
 
   .. _my-label:
   Section ABCD
@@ -194,7 +186,7 @@ URLs get parsed and displayed as links automatically. For example: https://charm
 Citations
 ---------
 
-::
+.. code-block:: none
 
   This is a reference [Ref]_ .
 
@@ -203,7 +195,7 @@ Citations
 Footnotes
 ---------
 
-::
+.. code-block:: none
 
   This text has a footnote [1]_
 
index 172aea928dbd2b94ae198fc358e5c06c325682de..64774c91d1c32411181db205695755e463041b9f 100644 (file)
@@ -223,7 +223,7 @@ extensions are available in C, C++, and Fortran, with the exception of
 ``AMPI_Command_argument_count`` and ``AMPI_Get_command_argument`` which
 are only available in Fortran.
 
-::
+.. code-block:: none
 
    AMPI_Migrate          AMPI_Register_pup            AMPI_Get_pup_data
    AMPI_Migrate_to_pe    AMPI_Set_migratable          AMPI_Evacuate
@@ -253,7 +253,7 @@ These attributes are accessible from any rank by calling
    call MPI_Comm_get_attr(MPI_COMM_WORLD, AMPI_MY_WTH, my_wth, flag, ierr)
 
 
-::
+.. code-block:: c++
 
    // C/C++:
    int my_wth, flag;
@@ -382,7 +382,7 @@ is that of changing a single pointer per user-level thread context
 switch. Currently, Charm++ supports it for x86/x86_64 platforms when
 using GNU compilers.
 
-::
+.. code-block:: c++
 
    // C/C++ example:
    int myrank;
@@ -397,7 +397,7 @@ using GNU compilers.
 For the example above, the following changes to the code handle the
 global variables:
 
-::
+.. code-block:: c++
 
    // C++ example:
    thread_local int myrank;
@@ -492,7 +492,7 @@ was renamed to ``END SUBROUTINE``.
      END DO
    END SUBROUTINE
 
-::
+.. code-block:: c++
 
    //C Example
    #include <mpi.h>
@@ -533,7 +533,7 @@ first group the shared data into a user-defined type.
      END TYPE ! modified
    END MODULE
 
-::
+.. code-block:: c++
 
    //C Example
    struct shareddata{
@@ -572,7 +572,7 @@ take this data as argument.
      END DO
    END SUBROUTINE
 
-::
+.. code-block:: c++
 
    //C Example
    void MPI_Main{
@@ -732,7 +732,7 @@ Calling ``AMPI_Migrate`` on a rank with pending send requests (i.e. from
 MPI_Isend) is currently not supported, therefore users should always
 wait on any outstanding send requests before calling ``AMPI_Migrate``.
 
-::
+.. code-block:: c++
 
    // Main time-stepping loop
    for (int iter=0; iter < max_iters; iter++) {
@@ -809,7 +809,7 @@ Suppose the user data, chunk, is defined as a derived type in Fortran90:
      END TYPE chunk
    END MODULE
 
-::
+.. code-block:: c++
 
    //C Example
    struct chunk{
@@ -840,7 +840,7 @@ written as:
      call pup(p, c%byp)
    end subroutine
 
-::
+.. code-block:: c++
 
    //C Example
    void chunkpup(pup_er p, struct chunk c){
@@ -889,7 +889,7 @@ Suppose the type ``dchunk`` is declared as:
      END TYPE dchunk
    END MODULE
 
-::
+.. code-block:: c++
 
    //C Example
    struct dchunk{
@@ -927,7 +927,7 @@ Then the pack-unpack subroutine is written as:
 
    END SUBROUTINE
 
-::
+.. code-block:: c++
 
    //C Example
    void dchunkpup(pup_er p, struct dchunk c){
@@ -1033,7 +1033,7 @@ does not revoke its allocation). Any load imbalance resulting from the
 restart can then be managed by the runtime system. Use of this scheme is
 illustrated in the code snippet below.
 
-::
+.. code-block:: c++
 
    // Main time-stepping loop
    for (int iter=0; iter < max_iters; iter++) {
@@ -1070,7 +1070,7 @@ do appropriate unpacking based on data type, and return.
 for this get request including the data buffer. Finally,
 ``AMPI_Iget_data`` is the routine used to access the data.
 
-::
+.. code-block:: c++
 
 
    int AMPI_Iget(MPI_Aint orgdisp, int orgcnt, MPI_Datatype orgtype, int rank,
@@ -1112,7 +1112,7 @@ and ``Solids_Main``\  [5]_ writing a subroutine called ``MPI_Setup``.
      CALL AMPI_Register_main(Fluids_Main)
    END SUBROUTINE
 
-::
+.. code-block:: c++
 
    //C Example
    void MPI_Setup(){
@@ -1171,7 +1171,7 @@ to send data to rank number 47 within the Fluids module, it calls:
    CALL MPI_Send(InitialTime, 1, MPI_Double_Precision, tag,
                  47, MPI_Comm_Universe(Fluids_Comm), ierr)
 
-::
+.. code-block:: c++
 
    //C Example
    int Fluids_Comm = 2;
@@ -1188,7 +1188,7 @@ this data:
    CALL MPI_Recv(InitialTime, 1, MPI_Double_Precision, tag,
                  36, MPI_Comm_Universe(Solids_Comm), stat, ierr)
 
-::
+.. code-block:: c++
 
    //C Example
    int Solids_Comm = 1;
@@ -1306,7 +1306,7 @@ Projections, link with ``ampicc -tracemode projections``.
 
 AMPI defines the following extensions for tracing support:
 
-::
+.. code-block:: none
 
    AMPI_Trace_begin                      AMPI_Trace_end
 
index 67206412d44003ebb840830350b93679e219406a..5ce18bc89b20d6afd96ab8834a84f36c043497a8 100644 (file)
@@ -70,7 +70,7 @@ other’s global address space in order to print “hello world”.
 
 The main function has to be compliant to ANSI C:
 
-::
+.. code-block:: c++
 
    #include <stdio.h>
    #include <stdlib.h>
@@ -153,7 +153,7 @@ arbitrary local and remote memory locations. It uses two arrays of
 pointers: one for source and one for destination addresses. The length
 of each array is equal to the number of segments.
 
-::
+.. code-block:: c++
 
    typedef struct {
      void *src_ptr_ar;
@@ -184,14 +184,14 @@ failure (See Section :numref:`sec::error codes` for details).
 Startup, Cleanup and Status Functions
 -------------------------------------
 
-::
+.. code-block:: c++
 
    int ARMCI_Init(void);
 
 Initializes the ARMCI library. This function must be called before any
 ARMCI functions may be used.
 
-::
+.. code-block:: c++
 
    int ARMCI_Finalize(void);
 
@@ -199,27 +199,27 @@ Shuts down the ARMCI library. No ARMCI functions may be called after
 this call is made. It must be used before terminating the program
 normally.
 
-::
+.. code-block:: c++
 
    void ARMCI_Cleanup(void);
 
 Releases system resources that the ARMCI library might be holding. This
 is intended to be used before terminating the program in case of error.
 
-::
+.. code-block:: c++
 
    void ARMCI_Error(char *msg, int code);
 
 Combines the functionality of ARMCI_Cleanup and Charm++’s CkAbort call.
 Prints to *stdout* and *stderr* ``msg`` followed by an integer ``code``.
 
-::
+.. code-block:: c++
 
    int ARMCI_Procs(int *procs);
 
 The number of processes is stored in the address ``procs``.
 
-::
+.. code-block:: c++
 
    int ARMCI_Myid(int *myid);
 
@@ -229,7 +229,7 @@ The id of the process making this call is stored in the address
 ARMCI Memory Allocation
 -----------------------
 
-::
+.. code-block:: c++
 
    int ARMCI_Malloc(void* ptr_arr[], int bytes);
 
@@ -239,21 +239,21 @@ process. The pointer address of each process’ allocated memory is stored
 at ``ptr_arr[]`` indexed by the process’ id (see ``ARMCI_Myid``). Each
 process gets a copy of ``ptr_arr``.
 
-::
+.. code-block:: c++
 
    int ARMCI_Free(void *ptr);
 
 Collective operation to free memory which was allocated by
 ``ARMCI_Malloc``.
 
-::
+.. code-block:: c++
 
    void *ARMCI_Malloc_local(int bytes);
 
 Local memory of size ``bytes`` allocated. Essentially a wrapper for
 ``malloc``.
 
-::
+.. code-block:: c++
 
    int ARMCI_Free_local(void *ptr);
 
@@ -263,7 +263,7 @@ wrapper for ``free``.
 Put and Get Communication
 -------------------------
 
-::
+.. code-block:: c++
 
    int ARMCI_Put(void *src, void *dst, int bytes, int proc);
 
@@ -271,7 +271,7 @@ Transfer contiguous data of size ``bytes`` from the local process memory
 (source) pointed to by ``src`` into the remote memory of process id
 ``proc`` pointed to by ``dst`` (remote memory pointer at destination).
 
-::
+.. code-block:: c++
 
    int ARMCI_NbPut(void *src, void* dst, int bytes, int proc,
                    armci_hdl_t *handle);
@@ -280,7 +280,7 @@ The non-blocking version of ``ARMCI_Put``. Passing a ``NULL`` value to
 ``handle`` makes this function perform an implicit handle non-blocking
 transfer.
 
-::
+.. code-block:: c++
 
    int ARMCI_PutS(void *src_ptr, int src_stride_ar[],
                   void *dst_ptr, int dst_stride_ar[],
@@ -301,7 +301,7 @@ process ``proc``\ ’s memory layout. ``count`` is an array of size
 As an example, assume two 2-dimensional C arrays residing on different
 processes.
 
-::
+.. code-block:: c++
 
              double A[10][20]; /* local process */
              double B[20][30]; /* remote process */
@@ -310,7 +310,7 @@ To put a block of data of 3x6 doubles starting at location (1,2) in
 ``A`` into location (3,4) in ``B``, the arguments to ``ARMCI_PutS`` will
 be as follows (assuming C/C++ memory layout):
 
-::
+.. code-block:: c++
 
              src_ptr = &A[0][0] + (1 * 20 + 2); /* location (1,2) */
              src_stride_ar[0] = 20 * sizeof(double);
@@ -321,7 +321,7 @@ be as follows (assuming C/C++ memory layout):
              stride_levels = 1;
              proc = /*<B's id> */;
 
-::
+.. code-block:: c++
 
    int ARMCI_NbPutS(void *src_ptr, int src_stride_ar[],
                     void *dst_ptr, int dst_stride_ar[],
@@ -332,7 +332,7 @@ The non-blocking version of ``ARMCI_PutS``. Passing a ``NULL`` value to
 ``handle`` makes this function perform an implicit handle non-blocking
 transfer.
 
-::
+.. code-block:: c++
 
    int ARMCI_Get(void *src, void *dst, int bytes, int proc);
 
@@ -340,7 +340,7 @@ Transfer contiguous data of size ``bytes`` from the remote process
 memory at process ``proc`` (source) pointed to by ``src`` into the local
 memory of the calling process pointed to by ``dst``.
 
-::
+.. code-block:: c++
 
    int ARMCI_NbGet(void *src, void *dst, int bytes, int proc,
                    armci_hdl_t *handle);
@@ -349,7 +349,7 @@ The non-blocking version of ``ARMCI_Get``. Passing a ``NULL`` value to
 ``handle`` makes this function perform an implicit handle non-blocking
 transfer.
 
-::
+.. code-block:: c++
 
    int ARMCI_GetS(void *src_ptr, int src_stride_ar[],
                   void* dst_ptr, int dst_stride_ar[],
@@ -359,7 +359,7 @@ Transfer strided data segments from remote process memory on process
 ``proc`` to the local memory of the calling process. The semantics of
 the parameters to this function are the same as that for ``ARMCI_PutS``.
 
-::
+.. code-block:: c++
 
    int ARMCI_NbGetS(void *src_ptr, int src_stride_ar[],
                     void* dst_ptr, int dst_stride_ar[],
@@ -373,7 +373,7 @@ transfer.
 Explicit Synchronization
 ------------------------
 
-::
+.. code-block:: c++
 
    int ARMCI_Wait(armci_hdl_t *handle);
    int ARMCI_WaitProc(int proc);
@@ -381,7 +381,7 @@ Explicit Synchronization
    int ARMCI_Test(armci_hdl_t *handle);
    int ARMCI_Barrier();
 
-::
+.. code-block:: c++
 
    int ARMCI_Fence(int proc);
 
@@ -389,7 +389,7 @@ Blocks the calling process until all *put* or *accumulate* operations
 the process issued to the remote process ``proc`` are completed at the
 destination.
 
-::
+.. code-block:: c++
 
    int ARMCI_AllFence(void);
 
@@ -401,7 +401,7 @@ operations it issued are completed on all remote destinations.
 Extensions to the Standard API
 ------------------------------
 
-::
+.. code-block:: c++
 
    void ARMCI_Migrate(void);
    void ARMCI_Async_Migrate(void);
@@ -417,7 +417,7 @@ List of Unimplemented Functions
 The following functions are supported on the standard ARMCI
 implementation but not yet supported in the Charm++ port.
 
-::
+.. code-block:: c++
 
    int ARMCI_GetV(...);
    int ARMCI_NbGetV(...);
index c48e935c83f6de9ceff1902cfd8e900055a5c545..577bd903822c38b9b4af0642da3d179b3284e6ce 100644 (file)
@@ -50,10 +50,10 @@ needs to be complemented with a few more libraries from BigSim and with
 the Pose discrete-event simulator. These pieces can be built,
 respectively, with:
 
-::
+.. code-block:: bash
 
-   ./build bgampi netlrts-linux-x86_64 -O2
-   ./build pose netlrts-linux-x86_64 -O2
+   ./build bgampi netlrts-linux-x86_64 -O2
+   ./build pose netlrts-linux-x86_64 -O2
 
 Access to the discrete-event simulation is realized via a Charm++
 package originally named BigNetSim (now called BigSimulator). Assuming
@@ -62,7 +62,7 @@ obtained from the Web with a subversion checkout such as:
 
 .. code-block:: bash
 
-      svn co https://charm.cs.uiuc.edu/svn/repos/BigNetSim/
+   $ svn co https://charm.cs.uiuc.edu/svn/repos/BigNetSim/
 
 In the subdir ’trunk/’ created by the checkout, the file Makefile.common
 must be edited so that ’CHARMBASE’ points to the regular Charm++
index beb7c4523c141ade568dfe35f4fc0e8f2b920e3e..a17024540316b8c7771451def6fc570057ba3cdb 100644 (file)
@@ -489,7 +489,7 @@ Writing a BigSim Application
 Application Skeleton
 ~~~~~~~~~~~~~~~~~~~~
 
-::
+.. code-block:: c++
 
    Handler function prototypes;
    Node specific data type declarations;
@@ -511,7 +511,7 @@ Application Skeleton
 Sample Application 1
 ~~~~~~~~~~~~~~~~~~~~
 
-::
+.. code-block:: c++
 
    /* Application:
     *   Each node starting at [0,0,0] sends a packet to next node in
@@ -588,7 +588,7 @@ Sample Application 1
 Sample Application 2
 ~~~~~~~~~~~~~~~~~~~~
 
-.. code-block:: C
+.. code-block:: c++
 
 
    /* Application:
index 692826a6770a91672cc966c63cadca61983ff0fb..53bb4d3a20cd96b76f69c94635c65bcde0a4e5f7 100644 (file)
@@ -81,7 +81,7 @@ A Charisma program or module has one "MainChare" class, and it does not
 require explicit instantiation since it is a singleton. The statement to
 declare MainChare looks like this:
 
-.. code-block:: cpp
+.. code-block:: c++
 
        class JacobiMain : MainChare;
 
@@ -91,7 +91,7 @@ the class types. The dimensionality information of the object array is
 given in a pair of brackets with each dimension size separated by a
 comma.
 
-.. code-block:: cpp
+.. code-block:: c++
 
        class JacobiWorker : ChareArray1D;
        obj workers : JacobiWorker[N];
@@ -345,7 +345,7 @@ code, and incorporate the sequential portion in the final header file.
 For example, if a molecular dynamics simulation has the following
 classes (as declared in the orchestration code):
 
-.. code-block:: cpp
+.. code-block:: c++
 
        class MDMain : MainChare;
        class Cell : ChareArray3D;
@@ -374,7 +374,7 @@ Second, in the body of the function, the keyword ``produce`` is used to
 connect the orchestration parameter and the local variables whose value
 will be sent out, in a format of a function call, as follows.
 
-.. code-block:: cpp
+.. code-block:: c++
 
        produce(produced_parameter, local_variable[, size_of_array]);
 
@@ -394,7 +394,7 @@ Since ``lb`` and ``rb`` are declared to have the local type and dimension of
 ``double [512]``, the producing statement should connect it with a local
 variable of ``double [512]``.
 
-.. code-block:: cpp
+.. code-block:: c++
 
        void JacobiWorker::produceBorders(outport lb, outport rb) {
          ...
@@ -416,7 +416,7 @@ specify the reduction operation. Built-in reduction operations are ``+``
 basic data types. For instance the following statements takes the sum of
 all local value of ``result`` and for output in ``sum``.
 
-.. code-block:: cpp
+.. code-block:: c++
 
        reduce(sum, result, "+");
 
@@ -425,13 +425,13 @@ function or operator defined to do the reduction. For example, assume we
 have a class called ``Force``, and we have an ``add`` function (or a ``+``
 operator) defined.
 
-.. code-block:: cpp
+.. code-block:: c++
 
        Force& Force::add(const Force& f);
 
 In the reduction to sum all the local forces, we can use
 
-.. code-block:: cpp
+.. code-block:: c++
 
        reduce(sumForces, localForce, "add");
 
@@ -509,7 +509,7 @@ for such info as problem size.
 Following the first line, the library's input and output parameters are
 posted with keywords ``inparam`` and ``outparam``.
 
-.. code-block:: cpp
+.. code-block:: c++
 
      module FFT3D(CHUNK, M, N);
      inparam indata;
@@ -526,7 +526,7 @@ To use a Charisma module library, the programmer first needs to create
 an instance of the library. There are two steps: including the module
 and creating an instance.
 
-.. code-block:: cpp
+.. code-block:: c++
 
      use FFT3D;
      library f1 : FFT3D(CHUNK=10, M=10, N=100);
@@ -544,7 +544,7 @@ output parameters are the same, and the object name and function name
 are replaced with the library instance name and the keyword ``call``
 connected with a colon.
 
-.. code-block:: cpp
+.. code-block:: c++
 
      (f1_outdata[*]) <- f1:call(f1_indata[*]);
 
@@ -576,7 +576,7 @@ Charm++ program. Please refer to the load balancing section in Charm++
 manual for more information on ``PUP`` functions. A typical example
 would look like this in user's sequential ``.C`` file:
 
-.. code-block:: cpp
+.. code-block:: c++
 
      void JacobiWorker::sequentialPup(PUP::er& p){
        p|myLeft; p|myRight; p|myUpper; p|myLower;
@@ -631,7 +631,7 @@ is created with all the elements populated. For instance, when we have
 the following declaration in the orchestration code, an array of NxNxN
 is created.
 
-.. code-block:: cpp
+.. code-block:: c#
 
        class Cell : ChareArray3D;
        obj cells : Cell[N,N,N];
@@ -648,7 +648,7 @@ this case, Charisma provides flexibility of declaring a sparse object
 array, with a ``sparse`` keyword following the object array declaration,
 as follows.
 
-.. code-block:: cpp
+.. code-block:: c#
 
        class CellPair : ChareArray6D;
        obj cellpairs : CellPair[N,N,N,N,N,N],sparse;
@@ -659,7 +659,7 @@ the elements to create. As an example, the following function
 essentially tells the system to generate all the NxNxNxNxNxN elements
 for the 6D array.
 
-.. code-block:: cpp
+.. code-block:: c++
 
      void getIndex_cellpairs(CkVec<CkArrayIndex6D>& vec) {
        int i,j,k,l,m,n;
@@ -702,7 +702,7 @@ sequential code are in ``JacobiWorker.h`` and ``JacobiWorker.C``. Note that
 ``JacobiWorker.h`` contains only the sequential portion of JacobiWorker's
 declaration.
 
-.. code-block:: cpp
+.. code-block:: c++
 
    #define N 512
    #define M 16
@@ -724,7 +724,7 @@ to show how consumed parameters (``rghost`` and ``lghost`` in
 ``JacobiWorker::compute``) and produced parameters (``lb`` and ``rb`` in
 ``JacobiWorker::produceBorders``) are handled.
 
-.. code-block:: cpp
+.. code-block:: c++
 
    void JacobiWorker::compute(double rghost[], double lghost[]) {
        /* local computation for updating elements*/
index 417c8071d975a0f63c3760617b6e95c1605f1539..81a8aae9502f4e6d083077a2569cd416ed128e15 100644 (file)
@@ -123,7 +123,7 @@ SDAG statements:
 
 These statements can be used inside of any entry method.
 
-::
+.. code-block:: c++
 
        when receiveMsg(SampleObject obj) {...}
 
@@ -138,7 +138,7 @@ Extern statements:
 If you want to use any other C++ function/feature, you have to define it
 as *extern*.
 
-::
+.. code-block:: c++
 
        extern atoi;            //define in the beginning of the file
        int x = atoi(y);        //use anywhere
@@ -148,14 +148,14 @@ Reduction statements:
 
 Currently only plain reductions are supported.
 
-::
+.. code-block:: c++
 
        contribute(CkCallback(CkReductionTarget(Main, done), mainProxy));
 
 Some Charm++ statements that can be used in a Charj program:
 ------------------------------------------------------------
 
-::
+.. code-block:: c++
 
        CkExit();
        CkPrintf();
index 5785a6b3a37f3033dce43173675d4c434eed1223..8b2ac5d0d56dc98106f2e1517d612275b8a42c6c 100644 (file)
@@ -356,7 +356,7 @@ cannot be nested, but each *ci* file can have several modules. Modules
 are specified using the keyword *module*. A module name must be a valid
 C++ identifier.
 
-::
+.. code-block:: c++
 
    module myFirstModule {
        // Parallel interface declarations go here
@@ -396,7 +396,7 @@ A module may depend on the parallel entities declared in another module.
 It can express this dependency using the *extern* keyword. *extern* ed
 modules do not have to be present in the same *ci* file.
 
-::
+.. code-block:: c++
 
    module mySecondModule {
 
@@ -431,7 +431,7 @@ modules. The decl.h and def.h files may be generated for other modules,
 but the runtime system is not aware of entities declared in such
 unreachable modules.
 
-::
+.. code-block:: c++
 
    module A {
        ...
@@ -475,7 +475,7 @@ become laborious if the decl.h file has to included in several places.
 Charm++ supports the keyword *include* in *ci* files to permit the
 inclusion of any header directly into the generated decl.h files.
 
-::
+.. code-block:: c++
 
    module A {
        include "myUtilityClass.h"; //< Note the semicolon
@@ -650,7 +650,7 @@ entry method and is used to create or spawn chare objects during
 execution. Class member functions are annotated as entry methods by
 declaring them in the interface file as:
 
-::
+.. code-block:: c++
 
    entry void Entry1(parameters);
 
@@ -666,7 +666,7 @@ parameter marshalling.
 For example, a chare could have this entry method declaration in the
 interface (``.ci``) file:
 
-::
+.. code-block:: c++
 
      entry void foo(int i,int k);
 
@@ -677,7 +677,7 @@ Since Charm++ runs on distributed memory machines, we cannot pass an
 array via a pointer in the usual C++ way. Instead, we must specify the
 length of the array in the interface file, as:
 
-::
+.. code-block:: c++
 
      entry void bar(int n,double arr[n]);
 
@@ -699,7 +699,7 @@ section.
 Array parameters and other parameters can be combined in arbitrary ways,
 as:
 
-::
+.. code-block:: c++
 
      entry void doLine(float data[n],int n);
      entry void doPlane(float data[n*n],int n);
@@ -734,7 +734,7 @@ large structure by reference than by value.
 As an example, refer to the following code from
 ``examples/charm++/PUP/HeapPUP``:
 
-::
+.. code-block:: c++
 
    // In HeapObject.h:
 
@@ -811,7 +811,7 @@ constructor that is an entry method, and may have any number of other
 entry methods. All chare classes and their entry methods are declared in
 the interface (``.ci``) file:
 
-::
+.. code-block:: c++
 
        chare ChareType
        {
@@ -830,7 +830,7 @@ constructs can be used in the interface file, as demonstrated in
 To be concrete, the C++ definition of the chare above might have the
 following definition in a ``.h`` file:
 
-::
+.. code-block:: c++
 
       class ChareType : public CBase_ChareType {
           // Data and member functions as in C++
@@ -876,7 +876,7 @@ Once you have declared and defined a chare class, you will want to
 create some chare objects to use. Chares are created by the ``ckNew``
 method, which is a static method of the chare’s proxy class:
 
-::
+.. code-block:: c++
 
       CProxy_chareType::ckNew(parameters, int destPE);
 
@@ -900,14 +900,14 @@ takes two arguments, an ``int`` and a ``double``.
 #. This will create a new chare of type C on any processor and return a
    proxy to that chare:
 
-   ::
+   .. code-block:: c++
 
          CProxy_C chareProxy = CProxy_C::ckNew(1, 10.0);
 
 #. This will create a new chare of type C on processor destPE and return
    a proxy to that chare:
 
-   ::
+   .. code-block:: c++
 
          CProxy_C chareProxy = CProxy_C::ckNew(1, 10.0, destPE);
 
@@ -921,7 +921,7 @@ Method Invocation on Chares
 A message may be sent to a chare through a proxy object using the
 notation:
 
-::
+.. code-block:: c++
 
        chareProxy.EntryMethod(parameters)
 
@@ -936,7 +936,7 @@ You can get direct access to a local chare using the proxy’s ckLocal
 method, which returns an ordinary C++ pointer to the chare if it exists on
 the local processor, and NULL otherwise.
 
-::
+.. code-block:: c++
 
        C *c=chareProxy.ckLocal();
        if (c==NULL) {
@@ -969,14 +969,14 @@ Read-only variables are declared by using the type modifier readonly,
 which is similar to const in C++. Read-only data is specified in the
 ``.ci`` file (the interface file) as:
 
-::
+.. code-block:: c++
 
     readonly Type ReadonlyVarName;
 
 The variable ReadonlyVarName is declared to be a read-only variable of
 type Type. Type must be a single token and not a type expression.
 
-::
+.. code-block:: c++
 
     readonly message MessageType *ReadonlyMsgName;
 
@@ -985,7 +985,7 @@ type MessageType. Pointers are not allowed to be readonly variables
 unless they are pointers to message types. In this case, the message
 will be initialized on every PE.
 
-::
+.. code-block:: c++
 
     readonly Type ReadonlyArrayName [arraysize];
 
@@ -997,7 +997,7 @@ Read-only variables must be declared either as global or as public class
 static data in the C/C++ implementation files, and these declarations have
 the usual form:
 
-::
+.. code-block:: c++
 
     Type ReadonlyVarName;
     MessageType *ReadonlyMsgName;
@@ -1044,7 +1044,7 @@ Declaring a One-dimensional Array
 
 You can declare a one-dimensional (1D) chare array as:
 
-::
+.. code-block:: c++
 
    //In the .ci file:
    array [1D] A {
@@ -1064,7 +1064,7 @@ several fields:
 -  thisIndex: the element’s array index (an array element can obtain a
    proxy to itself like this thisProxy[thisIndex])
 
-::
+.. code-block:: c++
 
    class A : public CBase_A {
      public:
@@ -1076,7 +1076,7 @@ several fields:
 Note that A must have a *migration constructor*, which is typically
 empty:
 
-::
+.. code-block:: c++
 
    //In the .C file:
    A::A(void)
@@ -1099,7 +1099,7 @@ Declaring Multi-dimensional Arrays
 Charm++ supports multi-dimensional or user-defined indices. These array
 types can be declared as:
 
-::
+.. code-block:: c++
 
    //In the .ci file:
    array [1D]  ArrayA { entry ArrayA(); entry void e(parameters);}
@@ -1116,7 +1116,7 @@ CkArrayIndexFoo, which must be defined before including the ``.decl.h``
 file (see section :numref:`user-defined array index type` on
 user-defined array indices for more information).
 
-::
+.. code-block:: c++
 
    //In the .h file:
    class ArrayA : public CBase_ArrayA { public: ArrayA(){} ...};
@@ -1166,14 +1166,14 @@ array creation. CProxy_Array::ckNew returns a proxy object, which can be
 kept, copied, or sent in messages. The following creates a 1D array
 containing elements indexed (0, 1, …, dimX-1):
 
-::
+.. code-block:: c++
 
    CProxy_ArrayA a1 = CProxy_ArrayA::ckNew(params, dimX);
 
 Likewise, a dense multidimensional array can be created by passing the
 extents at creation time to ckNew.
 
-::
+.. code-block:: c++
 
    CProxy_ArrayB a2 = CProxy_ArrayB::ckNew(params, dimX, dimY);
    CProxy_ArrayC a3 = CProxy_ArrayC::ckNew(params, dimX, dimY, dimZ);
@@ -1220,7 +1220,7 @@ depending on the dimensionality of the array:
 To send a message to an array element, index the proxy and call the
 method name:
 
-::
+.. code-block:: c++
 
    a1[i].doSomething(parameters);
    a3(x,y,z).doAnother(parameters);
@@ -1234,7 +1234,7 @@ Messages are not guaranteed to be delivered in order. For instance, if a
 method is invoked on method A and then method B; it is possible that B
 is executed before A.
 
-::
+.. code-block:: c++
 
    a1[i].A();
    a1[i].B();
@@ -1249,7 +1249,7 @@ Broadcasts on Chare Arrays
 To broadcast a message to all the current elements of an array, simply
 omit the index (invoke an entry method on the chare array proxy):
 
-::
+.. code-block:: c++
 
    a1.doIt(parameters); //<- invokes doIt on each array element
 
@@ -1270,7 +1270,7 @@ group.
 The data to be reduced comes from a call to the member contribute
 method:
 
-::
+.. code-block:: c++
 
    void contribute(int nBytes, const void *data, CkReduction::reducerType type);
 
@@ -1283,7 +1283,7 @@ the same reduction type.
 For example, if we want to sum each array/group member’s single integer
 myInt, we would use:
 
-::
+.. code-block:: c++
 
        // Inside any member method
        int myInt=get_myInt();
@@ -1294,7 +1294,7 @@ numbers. For example, if each element of a chare array has a pair of
 doubles forces[2], the corresponding elements of which are to be added
 across all elements, from each element call:
 
-::
+.. code-block:: c++
 
        double forces[2]=get_my_forces();
        contribute(2*sizeof(double),forces,CkReduction::sum_double);
@@ -1305,7 +1305,7 @@ don’t use &forces.
 A slightly simpler interface is available for ``std::vector<T>``, since
 the class determines the size and count of the underlying type:
 
-::
+.. code-block:: c++
 
        CkCallback cb(...);
        vector<double> forces(2);
@@ -1327,7 +1327,7 @@ callback to the reduction target, the entry method index is generated by
 ``CkIndex_ChareClass::method_name(...)``. For example, the code for a
 typed reduction that yields an ``int``, would look like this:
 
-::
+.. code-block:: c++
 
      // In the .ci file...
      entry [reductiontarget] void done(int result);
@@ -1361,7 +1361,7 @@ data; they can also be used to signal the fact that all array/group
 members have reached a certain synchronization point. In this case, a
 simpler version of contribute may be used:
 
-::
+.. code-block:: c++
 
        contribute();
 
@@ -1455,7 +1455,7 @@ arrays- just pass the correct number of bytes to contribute.
 CkReduction::set returns a collection of CkReduction::setElement
 objects, one per contribution. This class has the definition:
 
-::
+.. code-block:: c++
 
    class CkReduction::setElement
    {
@@ -1468,7 +1468,7 @@ objects, one per contribution. This class has the definition:
 Example: Suppose you would like to contribute 3 integers from each array
 element. In the reduction method you would do the following:
 
-::
+.. code-block:: c++
 
    void ArrayClass::methodName (CkCallback &cb)
    {
@@ -1483,7 +1483,7 @@ element. In the reduction method you would do the following:
 Inside the reduction’s target method, the contributions can be accessed
 by using the ``CkReduction::setElement->next()`` iterator.
 
-::
+.. code-block:: c++
 
    void SomeClass::reductionTargetMethod (CkReductionMsg *msg)
    {
@@ -1520,7 +1520,7 @@ reduced in the same order as each other. As an example, a chare array
 element can contribute to a gatherv-like operation using a tuple
 reduction that consists of two set reductions.
 
-::
+.. code-block:: c++
 
    int tupleSize = 2;
    CkReduction::tupleElement tupleRedn[] = {
@@ -1539,7 +1539,7 @@ remain in scope until ``CkReductionMsg::buildFromTuple`` completes.
 The result of this reduction is a single CkReductionMsg that can be
 processed as multiple reductions:
 
-::
+.. code-block:: c++
 
    void Foo::allgathervResult (CkReductionMsg* msg)
    {
@@ -1564,7 +1564,7 @@ Destroying Array Elements
 To destroy an array element - detach it from the array, call its
 destructor, and release its memory-invoke its Array destroy method, as:
 
-::
+.. code-block:: c++
 
    a1[i].ckDestroy();
 
@@ -1591,7 +1591,7 @@ one another, related to data and synchronization dependencies.
 Consider one way of expressing these constraints using flags, buffers,
 and counters, as in the following example:
 
-::
+.. code-block:: c++
 
    // in .ci file
    chare ComputeObject {
@@ -1661,7 +1661,7 @@ messages in a ``when`` statement, or to do local operations before a
 message is sent or after it’s received. The earlier example can be
 adapted to use serial blocks as follows:
 
-::
+.. code-block:: c++
 
    // in .ci file
    chare ComputeObject {
@@ -1715,7 +1715,7 @@ generated-code macro in the class.
 Serial blocks can also specify a textual ‘label’ that will appear in
 traces, as follows:
 
-::
+.. code-block:: c++
 
      entry void firstInput(Input i) {
        serial "process first" {
@@ -1741,7 +1741,7 @@ processed; otherwise, control is returned to the Charm++ scheduler.
 
 The use of ``when`` substantially simplifies the example from above:
 
-::
+.. code-block:: c++
 
    // in .ci file
    chare ComputeObject {
@@ -1791,7 +1791,7 @@ For simplicity, ``when`` constructs can also specify multiple expected
 entry methods that all feed into a single body, by separating their
 prototypes with commas:
 
-::
+.. code-block:: c++
 
    entry void startStep() {
      when firstInput(Input first),
@@ -1836,7 +1836,7 @@ they appeared in plain C or C++ code. In the running example,
 start the next step. Instead of this arrangement, the loop structure can
 be made explicit:
 
-::
+.. code-block:: c++
 
    // in .ci file
    chare ComputeObject {
@@ -1873,7 +1873,7 @@ be made explicit:
 If this code should instead run for a fixed number of iterations, we can
 instead use a for loop:
 
-::
+.. code-block:: c++
 
    // in .ci file
    chare ComputeObject {
@@ -1936,7 +1936,7 @@ independently before the call to ``computeInteractions``. Since we don’t
 care which order they get processed in, and want it to happen as soon as
 possible, we can apply ``overlap``:
 
-::
+.. code-block:: c++
 
    // in .ci file
    chare ComputeObject {
@@ -1989,7 +1989,7 @@ the body.
 
 The syntax of ``forall`` is
 
-::
+.. code-block:: c++
 
    forall [IDENT] (MIN:MAX,STRIDE) BODY
 
@@ -2017,7 +2017,7 @@ the runtime will not “commit” to this branch until the second arrives.
 If another dependency fully matches, the partial match will be ignored
 and can be used to trigger another ``when`` later in the execution.
 
-::
+.. code-block:: c++
 
    case {
      when a() { }
@@ -2043,7 +2043,7 @@ file).
 
 For example, an array named “Foo” that uses sdag code might contain:
 
-::
+.. code-block:: c++
 
    class Foo : public CBase_Foo {
    public:
@@ -2092,7 +2092,7 @@ includes support special for STL containers to ease development in C++.
 
 Like many C++ concepts, the PUP framework is easier to use than describe:
 
-::
+.. code-block:: c++
 
    class foo : public mySuperclass {
     private:
@@ -2175,7 +2175,7 @@ For arrays, you can use the utility method PUParray, which takes the
 PUP::er, the array base pointer, and the array length. This utility
 method is defined for user-defined types T as:
 
-::
+.. code-block:: c++
 
        template<class T>
        inline void PUParray(PUP::er &p,T *array,int length) {
@@ -2207,7 +2207,7 @@ PUPbytes, you can define an operator\ ``|`` to pup the object. For
 example, if myClass contains two fields a and b, the operator\ ``|``
 might look like:
 
-::
+.. code-block:: c++
 
      inline void operator|(PUP::er &p,myClass &c) {
        p|c.a;
@@ -2361,7 +2361,7 @@ generated superclasses.
 
 A simple example for an array follows:
 
-::
+.. code-block:: c++
 
    //In the .h file:
    class A2 : public CBase_A2 {
@@ -2414,7 +2414,7 @@ parameters must abide by the standard PUP contract (see section
 A simple example of using PUP to marshall user defined data types
 follows:
 
-::
+.. code-block:: c++
 
    class Buffer {
    public:
@@ -2872,7 +2872,7 @@ to configure the load balancer, etc. These functions are:
    load balancing from occurring too often in *automatic without sync
    mode*. Here is how to use it:
 
-   ::
+   .. code-block:: c++
 
       // if used in an array element
       LBDatabase *lbdb = getLBDB();
@@ -2956,10 +2956,10 @@ Below are the descriptions about the compiler and runtime options:
    working directory to the *tmp* subdirectory of your build and making
    them by name.
 
-   ::
+   .. code-block:: bash
 
-       cd netlrts-linux-x86_64/tmp
-       make PhasebyArrayLB
+      $ cd netlrts-linux-x86_64/tmp
+      $ make PhasebyArrayLB
 
 #. **Write and use your own load balancer**
 
@@ -3137,7 +3137,7 @@ Simple Load Balancer Usage Example - Automatic with Sync LB
 A simple example of how to use a load balancer in sync mode in one’s
 application is presented below.
 
-::
+.. code-block:: c++
 
    /*** lbexample.ci ***/
    mainmodule lbexample {
@@ -3157,7 +3157,7 @@ application is presented below.
 
 ——————————————————————————-
 
-::
+.. code-block:: c++
 
    /*** lbexample.C ***/
    #include <stdio.h>
@@ -3262,7 +3262,7 @@ Group Definition
 
 In the interface (``.ci``) file, we declare
 
-::
+.. code-block:: c++
 
    group Foo {
      // Interface specifications as for normal chares
@@ -3277,7 +3277,7 @@ In the interface (``.ci``) file, we declare
 The definition of the ``Foo`` class is given in the ``.h`` file, as
 follows:
 
-::
+.. code-block:: c++
 
    class Foo : public CBase_Foo {
      // Data and member functions as in C++
@@ -3297,13 +3297,13 @@ Groups are created using ckNew like chares and chare arrays. Given the
 declarations and definitions of group ``Foo`` from above, we can create
 a group in the following manner:
 
-::
+.. code-block:: c++
 
    CProxy_Foo fooProxy = CProxy_Foo::ckNew(parameters1);
 
 One can also use ckNew to get a CkGroupID as shown below:
 
-::
+.. code-block:: c++
 
    CkGroupID fooGroupID = CProxy_Foo::ckNew(parameters1);
 
@@ -3312,7 +3312,7 @@ CkEntryOptions. For example, in the following code, the creation of
 group ``GroupB`` on each PE depends on the creation of ``GroupA`` on
 that PE.
 
-::
+.. code-block:: c++
 
    // Create GroupA
    CkGroupID groupAID = CProxy_GroupA::ckNew(parameters1);
@@ -3340,7 +3340,7 @@ group through a proxy of that group. If we have a group with a proxy
 that branch of the group which resides on PE ``somePE``, we would
 accomplish this with the following syntax:
 
-::
+.. code-block:: c++
 
    fooProxy[somePE].someEntryMethod(parameters);
 
@@ -3348,7 +3348,7 @@ This call is asynchronous and non-blocking; it returns immediately after
 sending the message. A message may be broadcast to all branches of a
 group (i.e., to all PEs) using the notation :
 
-::
+.. code-block:: c++
 
    fooProxy.anotherEntryMethod(parameters);
 
@@ -3361,7 +3361,7 @@ Recall that each PE hosts a branch of every instantiated group.
 Sequential objects, chares and other groups can gain access to this
 *PE-local* branch using ckLocalBranch():
 
-::
+.. code-block:: c++
 
    GroupType *g=groupProxy.ckLocalBranch();
 
@@ -3410,7 +3410,7 @@ NodeGroup Declaration
 Node groups are defined in a similar way to groups.  [10]_ For example,
 in the interface file, we declare:
 
-::
+.. code-block:: c++
 
     nodegroup NodeGroupType {
      // Interface specifications as for normal chares
@@ -3418,7 +3418,7 @@ in the interface file, we declare:
 
 In the ``.h`` file, we define NodeGroupType as follows:
 
-::
+.. code-block:: c++
 
     class NodeGroupType : public CBase_NodeGroupType {
      // Data and member functions as in C++
@@ -3442,7 +3442,7 @@ number* argument to the square bracket operator of the proxy object. A
 broadcast is expressed by omitting the square bracket notation. For
 completeness, example syntax for these two cases is shown below:
 
-::
+.. code-block:: c++
 
     // Invoke `someEntryMethod' on the i-th logical node of
     // a NodeGroup whose proxy is `myNodeGroupProxy':
@@ -3508,7 +3508,7 @@ the routine exactly once on *every logical node* before the computation
 begins, or to declare a regular C++ subroutine initproc to be executed
 exactly once on *every PE*.
 
-::
+.. code-block:: c++
 
    module foo {
        initnode void fooNodeInit(void);
@@ -3675,7 +3675,7 @@ code for messages. Message declaration is straightforward for fixed-size
 messages. Given a message of type ``MyFixedSizeMsg``, simply include the
 following in the .ci file:
 
-::
+.. code-block:: c++
 
     message MyFixedSizeMsg;
 
@@ -3685,7 +3685,7 @@ encapsulate. The following example illustrates this requirement. In it,
 a message of type ``MyVarsizeMsg``, which encapsulates three
 variable-length arrays of different types, is declared:
 
-::
+.. code-block:: c++
 
     message MyVarsizeMsg {
       int arr1[];
@@ -3701,7 +3701,7 @@ type of your message is ``T``, then ``class T`` must inherit from
 example, for our fixed size message type ``MyFixedSizeMsg`` above, we
 might write the following in the .h file:
 
-::
+.. code-block:: c++
 
    class MyFixedSizeMsg : public CMessage_MyFixedSizeMsg {
      int var1;
@@ -3716,7 +3716,7 @@ In particular, note the inclusion of the static array of ``double``\ s,
 ``double``\ s. Similarly, for our example varsize message of type
 ``MyVarsizeMsg``, we would write something like:
 
-::
+.. code-block:: c++
 
    class MyVarsizeMsg : public CMessage_MyVarsizeMsg {
      // variable-length arrays
@@ -3744,7 +3744,7 @@ Thus the mtype class declaration should be similar to:
 place, messages can be allocated and used in the program. Messages are
 allocated using the C++ new operator:
 
-::
+.. code-block:: c++
 
     MessageType *msgptr =
      new [(int sz1, int sz2, ... , int priobits=0)] MessageType[(constructor arguments)];
@@ -3755,7 +3755,7 @@ prioritized messages. These arguments are not specified for fixed size
 messages. For instance, to allocate a message of our example message
 ``MyFixedSizeMsg``, we write:
 
-::
+.. code-block:: c++
 
    MyFixedSizeMsg *msg = new MyFixedSizeMsg(<constructor args>);
 
@@ -3769,14 +3769,14 @@ used to store the message priority. So, if we wanted to create
 ``MyVarsizeMsg`` whose ``arr1``, ``arr2`` and ``arr3`` arrays contain
 10, 20 and 7 elements of their respective types, we would write:
 
-::
+.. code-block:: c++
 
    MyVarsizeMsg *msg = new (10, 20, 7) MyVarsizeMsg(<constructor args>);
 
 Further, to add a 32-bit priority bitvector to this message, we would
 write:
 
-::
+.. code-block:: c++
 
    MyVarsizeMsg *msg = new (10, 20, 7, sizeof(uint32_t)*8) VarsizeMessage;
 
@@ -3790,7 +3790,7 @@ array containing the size of each variable-length array, rather than
 specifying individual sizes as separate arguments. For example, we could
 create a message of type ``MyVarsizeMsg`` in the following manner:
 
-::
+.. code-block:: c++
 
    int sizes[3];
    sizes[0] = 10;               // arr1 will have 10 elements
@@ -3803,7 +3803,7 @@ create a message of type ``MyVarsizeMsg`` in the following manner:
 set the various elements of the encapsulated arrays in the following
 manner:
 
-::
+.. code-block:: c++
 
      msg->arr1[13] = 1;
      msg->arr2[5] = 32.82;
@@ -3813,7 +3813,7 @@ manner:
 And pass it to an asynchronous entry method invocation, thereby sending
 it to the corresponding chare:
 
-::
+.. code-block:: c++
 
    myChareArray[someIndex].foo(msg);
 
@@ -3834,7 +3834,7 @@ The Charm++ interface translator generates implementation for three
 static methods for the message class CMessage_mtype. These methods have
 the prototypes:
 
-::
+.. code-block:: c++
 
        static void* alloc(int msgnum, size_t size, int* array, int priobits);
        static void* pack(mtype*);
@@ -3851,7 +3851,7 @@ packed message where each field requires individual allocation. The
 alloc method should actually allocate the message using CkAllocMsg,
 whose signature is given below:
 
-::
+.. code-block:: c++
 
    void *CkAllocMsg(int msgnum, int size, int priobits);
 
@@ -3859,7 +3859,7 @@ For varsize messages, these static methods ``alloc``, ``pack``, and
 ``unpack`` are generated by the interface translator. For example, these
 methods for the VarsizeMessage class above would be similar to:
 
-::
+.. code-block:: c++
 
    // allocate memory for varmessage so charm can keep track of memory
    static void* alloc(int msgnum, size_t size, int* array, int priobits)
@@ -3932,7 +3932,7 @@ with parameter marshalling or the PUP framework described later.
 Packed messages are declared in the ``.ci`` file the same way as
 ordinary messages:
 
-::
+.. code-block:: c++
 
    message PMessage;
 
@@ -3942,7 +3942,7 @@ unpack. These methods are called by the Charm++ runtime system, when the
 message is determined to be crossing address-space boundary. The
 prototypes for these methods are as follows:
 
-::
+.. code-block:: c++
 
    static void *PMessage::pack(PMessage *in);
    static PMessage *PMessage::unpack(void *in);
@@ -3974,7 +3974,7 @@ following tasks are done in the unpack method:
 
 Here is an example of a packed-message implementation:
 
-::
+.. code-block:: c++
 
    // File: pgm.ci
    mainmodule PackExample {
@@ -4054,7 +4054,7 @@ specify the keyword for the desired attribute in the attribute list of
 that entry method’s ``.ci`` file declaration. The syntax for this is as
 follows:
 
-::
+.. code-block:: c++
 
    entry [attribute1, ..., attributeN] void EntryMethod(parameters);
 
@@ -4077,7 +4077,7 @@ sync
    scheduler, e.g. a threaded entry methods. Calls expecting a return
    value will receive it as the return from the proxy invocation:
 
-   ::
+   .. code-block:: c++
 
        ReturnMsg* m;
        m = A[i].foo(a, b, c);
@@ -4263,7 +4263,7 @@ For parameter marshaling, the queueingtype can be set for
 CkEntryOptions, which is passed to an entry method invocation as the
 optional last parameter.
 
-::
+.. code-block:: c++
 
      CkEntryOptions opts1, opts2;
      opts1.setQueueing(CK_QUEUEING_FIFO);
@@ -4290,7 +4290,7 @@ Messages
 The first two options, CK_QUEUEING_FIFO and CK_QUEUEING_LIFO, are used
 as follows:
 
-::
+.. code-block:: c++
 
      MsgType *msg1 = new MsgType ;
      CkSetQueueing(msg1, CK_QUEUEING_FIFO);
@@ -4337,7 +4337,7 @@ to hold the priority. One then stores the priority in the message.
 Finally, one informs the system that the message contains an integer
 priority using CkSetQueueing:
 
-::
+.. code-block:: c++
 
      MsgType *msg = new (8*sizeof(int)) MsgType;
      *(int*)CkPriorityPtr(msg) = prio;
@@ -4479,7 +4479,7 @@ To send an array using the zero copy Direct API, define a CkNcpyBuffer
 object on the sender chare specifying the pointer, size, a CkCallback
 object and an optional mode parameter.
 
-::
+.. code-block:: c++
 
    CkCallback srcCb(CkIndex_Ping1::sourceDone, thisProxy[thisIndex]);
    // CkNcpyBuffer object representing the source buffer
@@ -4509,7 +4509,7 @@ synchronization mechanisms, the callback is not entirely useful and in
 such cases, ``CkCallback::ignore`` can be passed as the callback
 parameter.
 
-::
+.. code-block:: c++
 
    CkCallback destCb(CkIndex_Ping1::destinationDone, thisProxy[thisIndex]);
    // CkNcpyBuffer object representing the destination buffer
@@ -4522,7 +4522,7 @@ This can be done using a regular entry method invocation as shown in the
 following code snippet, where the sender, arrProxy[0] sends its source
 object to the receiver chare, arrProxy[1].
 
-::
+.. code-block:: c++
 
    // On Index 0 of arrProxy chare array
    arrProxy[1].recvNcpySrcObj(source);
@@ -4532,7 +4532,7 @@ can perform a get operation on its destination CkNcpyBuffer object by
 passing the source object as an argument to the runtime defined get
 method as shown in the following code snippet.
 
-::
+.. code-block:: c++
 
    // On Index 1 of arrProxy chare array
    // Call get on the local destination object passing the source object
@@ -4546,12 +4546,12 @@ the sender for the sender to perform a put on its source object by
 passing the source CkNcpyBuffer object as an argument to the runtime
 defined put method as shown in in the code snippet.
 
-::
+.. code-block:: c++
 
    // On Index 1 of arrProxy chare array
    arrProxy[0].recvNcpyDestObj(dest);
 
-::
+.. code-block:: c++
 
    // On Index 0 of arrProxy chare array
    // Call put on the local source object passing the destination object
@@ -4562,7 +4562,7 @@ in both the objects are invoked. Within the CkNcpyBuffer source
 callback, ``sourceDone()``, the buffer can be safely modified or freed
 as shown in the following code snippet.
 
-::
+.. code-block:: c++
 
    // Invoked by the runtime on source (Index 0)
    void sourceDone() {
@@ -4575,7 +4575,7 @@ Similarly, inside the CkNcpyBuffer destination callback,
 complete into the destination buffer and the user can begin operating on
 the newly available data as shown in the following code snippet.
 
-::
+.. code-block:: c++
 
    // Invoked by the runtime on destination (Index 1)
    void destinationDone() {
@@ -4597,7 +4597,7 @@ illustrates the accessing of the original buffer pointer in the callback
 method by casting the ``data`` field of the ``CkDataMsg`` object into a
 ``CkNcpyBuffer`` object.
 
-::
+.. code-block:: c++
 
    // Invoked by the runtime on source (Index 0)
    void sourceDone(CkDataMsg *msg) {
@@ -4611,7 +4611,7 @@ method by casting the ``data`` field of the ``CkDataMsg`` object into a
 The following code snippet illustrates the usage of the ``setRef``
 method.
 
-::
+.. code-block:: c++
 
    const void *refPtr = &index;
    CkNcpyBuffer source(arr1, arr1Size * sizeof(int), srcCb, CK_BUFFER_REG);
@@ -4621,7 +4621,7 @@ Similar to the buffer pointer, the user set arbitrary reference pointer
 can be also accessed in the callback method. This is shown in the next
 code snippet.
 
-::
+.. code-block:: c++
 
    // Invoked by the runtime on source (Index 0)
    void sourceDone(CkDataMsg *msg) {
@@ -4780,7 +4780,7 @@ example, after using a CkNcpyBuffer object called ``srcInfo``, the user
 can re-initialize the same object with other values. This is shown in
 the following code snippet.
 
-::
+.. code-block:: c++
 
    // initialize src with new values
    src.init(ptr, 200, newCb, CK_BUFFER_REG);
@@ -4796,7 +4796,7 @@ de-registration, if intended to register again, it is required to call
 allocated from a preregistered mempool. This is required to set the
 registration memory handles and will not incur any registration costs.
 
-::
+.. code-block:: c++
 
    // register previously de-registered buffer
    src.registerMem();
@@ -4814,14 +4814,14 @@ without a copy.
 To send an array using the zero copy message send API, specify the array
 parameter in the .ci file with the nocopy specifier.
 
-::
+.. code-block:: c++
 
    entry void foo (int size, nocopy int arr[size]);
 
 While calling the entry method from the .C file, wrap the array i.e the
 pointer in a CkSendBuffer wrapper.
 
-::
+.. code-block:: c++
 
    arrayProxy[0].foo(500000, CkSendBuffer(arrPtr));
 
@@ -4830,7 +4830,7 @@ buffer. To be notified on completion of the RDMA operation, pass an
 optional callback object in the CkSendBuffer wrapper associated with the
 specific nocopy array.
 
-::
+.. code-block:: c++
 
    CkCallback cb(CkIndex_Foo::zerocopySent(NULL), thisProxy[thisIndex]);
    arrayProxy[0].foo(500000, CkSendBuffer(arrPtr, cb));
@@ -4841,7 +4841,7 @@ to overwrite the buffer sent via the zero copy entry method send API and
 this buffer can be accessed by dereferencing the CkDataMsg received in
 the callback.
 
-::
+.. code-block:: c++
 
    //called when RDMA operation is completed
    void zerocopySent(CkDataMsg *m)
@@ -4866,14 +4866,14 @@ on completing the transfer of each of the two nocopy parameters.
 For multiple arrays to be sent via RDMA, declare the entry method in the
 .ci file as:
 
-::
+.. code-block:: c++
 
    entry void foo (int size1, nocopy int arr1[size1], int size2, nocopy double arr2[size2]);
 
 In the .C file, it is also possible to have different callbacks
 associated with each nocopy array.
 
-::
+.. code-block:: c++
 
    CkCallback cb1(CkIndex_Foo::zerocopySent1(NULL), thisProxy[thisIndex]);
    CkCallback cb2(CkIndex_Foo::zerocopySent2(NULL), thisProxy[thisIndex]);
@@ -4955,7 +4955,7 @@ that identifies which entry method will be called. An entry method index
 is the Charm++ version of a function pointer. The entry method index can
 be obtained using the syntax:
 
-::
+.. code-block:: c++
 
    int myIdx = CkIndex_ChareName::EntryMethod(parameters);
 
@@ -4983,7 +4983,7 @@ Possible constructors are:
    entry point index - ep) of the given Chare (specified by the chare
    id). Note that a chare proxy will also work in place of a chare id:
 
-   ::
+   .. code-block:: c++
 
       CkCallback(CkIndex_Foo::bar(NULL), thisProxy[thisIndex])
 
@@ -4991,7 +4991,7 @@ Possible constructors are:
    invoked, the callback will pass param and the result message to the
    given C function, which should have a prototype like:
 
-   ::
+   .. code-block:: c++
 
       void myCallbackFn(void *param, void *message)
 
@@ -5042,7 +5042,7 @@ send on the callback with the result message as an argument. As an
 example, a library which accepts a CkCallback object from the user and
 then invokes it to return a result may have the following interface:
 
-::
+.. code-block:: c++
 
    //Main library entry point, called by asynchronous users:
    void myLibrary(...library parameters...,const CkCallback &cb)
@@ -5085,7 +5085,7 @@ is invoked on the associated callback. It can be used in situations when
 the return value is not needed, and only the synchronization is
 important. For example:
 
-::
+.. code-block:: c++
 
    // Call the "doWork" method and wait until it has completed
    void mainControlFlow() {
@@ -5104,7 +5104,7 @@ retrieved by passing a pointer to *CkCallbackResumeThread*. This pointer
 will be modified by *CkCallbackResumeThread* to point to the incoming
 message. Notice that the input pointer has to be cast to *(void*&)*:
 
-::
+.. code-block:: c++
 
    // Call the "doWork" method and wait until it has completed
    void mainControlFlow() {
@@ -5130,7 +5130,7 @@ CkCallbackResumeThread callbacks below.
 For heap allocation, the user must explicitly “delete” the callback in
 order to suspend the thread.
 
-::
+.. code-block:: c++
 
    // Call the "doWork" method and wait until it has completed
    void mainControlFlow() {
@@ -5150,7 +5150,7 @@ situation, the function “thread_delay” can be invoked on the callback to
 force the thread to suspend. This also works for heap allocated
 callbacks.
 
-::
+.. code-block:: c++
 
    // Call the "doWork" method and wait until it has completed
    void mainControlFlow() {
@@ -5164,24 +5164,24 @@ callbacks.
      ...some more work after the thread is resumed...
    }
 
-In all cases a *CkCallbackResumeThread* can be used to suspend a
-  thread only once.
-(See Main.cpp of `Barnes-Hut
-  MiniApp <http://charmplusplus.org/miniApps/#barnes>`__ for a complete
-  example).
-*Deprecated usage*: in the past, “thread_delay” was used to retrieve
-  the incoming message from the callback. While that is still allowed
-  for backward compatibility, its usage is deprecated. The old usage is
-  subject to memory leaks and dangling pointers.
-
-Callbacks can also be tagged with reference numbers which can be
-  matched inside SDAG code. When the callback is created, the creator
-  can set the refnum and the runtime system will ensure that the message
-  invoked on the callback’s destination will have that refnum. This
-  allows the receiver of the final callback to match the messages based
-  on the refnum value. (See
-  ``examples/charm++/examples/charm++/ckcallback`` for a complete
-  example).
+In all cases a *CkCallbackResumeThread* can be used to suspend a
+thread only once.
+(See Main.cpp of `Barnes-Hut
+MiniApp <http://charmplusplus.org/miniApps/#barnes>`__ for a complete
+example).
+*Deprecated usage*: in the past, “thread_delay” was used to retrieve
+the incoming message from the callback. While that is still allowed
+for backward compatibility, its usage is deprecated. The old usage is
+subject to memory leaks and dangling pointers.
+
+Callbacks can also be tagged with reference numbers which can be
+matched inside SDAG code. When the callback is created, the creator
+can set the refnum and the runtime system will ensure that the message
+invoked on the callback’s destination will have that refnum. This
+allows the receiver of the final callback to match the messages based
+on the refnum value. (See
+``examples/charm++/examples/charm++/ckcallback`` for a complete
+example).
 
 Waiting for Completion
 ----------------------
@@ -5228,7 +5228,7 @@ scheduler; that is, it must be a threaded entry method (*cf.*
 it is provided as the return value from the invocation on the proxy
 object:
 
-::
+.. code-block:: c++
 
     ReturnMsg* m;
     m = A[i].foo(a, b, c);
@@ -5256,7 +5256,7 @@ until the value is available.
 Charm++ provides all the necessary infrastructure to use futures by
 means of the following functions:
 
-::
+.. code-block:: c++
 
     CkFuture CkCreateFuture(void)
     void CkReleaseFuture(CkFuture fut)
@@ -5267,14 +5267,14 @@ means of the following functions:
 To illustrate the use of all these functions, a Fibonacci example in
 Charm++ using futures in presented below:
 
-::
+.. code-block:: c++
 
    chare fib {
      entry fib(bool amIroot, int n, CkFuture f);
      entry [threaded] void run(bool amIroot, int n, CkFuture f);
    };
 
-::
+.. code-block:: c++
 
    void  fib::run(bool amIRoot, int n, CkFuture f) {
       if (n < THRESHOLD)
@@ -5342,7 +5342,7 @@ First, the detector should be constructed. This call would typically
 belong in application startup code (it initializes the group that keeps
 track of completion):
 
-::
+.. code-block:: c++
 
    CProxy_CompletionDetector detector = CProxy_CompletionDetector::ckNew();
 
@@ -5350,7 +5350,7 @@ When it is time to start completion detection, invoke the following
 method of the library on *all* branches of the completion detection
 group:
 
-::
+.. code-block:: c++
 
    void start_detection(int num_producers,
                         CkCallback start,
@@ -5379,7 +5379,7 @@ should be set below the application’s priority if possible.
 
 For example, the call
 
-::
+.. code-block:: c++
 
    detector.start_detection(10,
                             CkCallback(CkIndex_chare1::start_test(), thisProxy),
@@ -5398,7 +5398,7 @@ completion detection library is set to 0 in this case.
 Once initialization is complete (the “start” callback is triggered),
 make the following call to the library:
 
-::
+.. code-block:: c++
 
    void CompletionDetector::produce(int events_produced)
    void CompletionDetector::produce() // 1 by default
@@ -5406,31 +5406,31 @@ make the following call to the library:
 For example, within the code for a chare array object, you might make
 the following call:
 
-::
+.. code-block:: c++
 
    detector.ckLocalBranch()->produce(4);
 
 Once all the “events” that this chare is going to produce have been sent
 out, make the following call:
 
-::
+.. code-block:: c++
 
    void CompletionDetector::done(int producers_done)
    void CompletionDetector::done() // 1 by default
 
-::
+.. code-block:: c++
 
    detector.ckLocalBranch()->done();
 
 At the same time, objects can also consume produced elements, using the
 following calls:
 
-::
+.. code-block:: c++
 
    void CompletionDetector::consume(int events_consumed)
    void CompletionDetector::consume() // 1 by default
 
-::
+.. code-block:: c++
 
    detector.ckLocalBranch()->consume();
 
@@ -5460,7 +5460,7 @@ has two variants which expect the following arguments:
 
 #. A CkCallback object. The syntax of this call looks like:
 
-   ::
+   .. code-block:: c++
 
         CkStartQD(const CkCallback& cb);
 
@@ -5473,7 +5473,7 @@ has two variants which expect the following arguments:
    and a handle to the chare on which that entry function should be
    called. The syntax of this call looks like this:
 
-   ::
+   .. code-block:: c++
 
        CkStartQD(int Index,const CkChareID* chareID);
 
@@ -5482,7 +5482,7 @@ has two variants which expect the following arguments:
    CkIndex object corresponding to the chare containing that entry
    method. The syntax of this call is as follows:
 
-   ::
+   .. code-block:: c++
 
       myIdx=CkIndex_ChareClass::entryMethod(parameters);
 
@@ -5497,7 +5497,7 @@ CkWaitQD, by contrast, does not register a callback. Rather, CkWaitQD
 parameters and returns no value. A call to CkWaitQD simply looks like
 this:
 
-::
+.. code-block:: c++
 
      CkWaitQD();
 
@@ -5525,7 +5525,7 @@ proxy’s ckLocal method, which returns an ordinary C++ pointer to the
 element if it exists on the local processor, and NULL if the element
 does not exist or is on another processor.
 
-::
+.. code-block:: c++
 
    A1 *a=a1[i].ckLocal();
    if (a==NULL) // ...is remote -- send message
@@ -5567,7 +5567,7 @@ array elements. A CkArrayOptions object will be constructed
 automatically in this special common case. Thus the following code
 segments all do exactly the same thing:
 
-::
+.. code-block:: c++
 
    // Implicit CkArrayOptions
    a1=CProxy_A1::ckNew(parameters,nElements);
@@ -5599,7 +5599,7 @@ passed into the CkArrayOptions constructor, or set one at a time. The
 following shows two different ways to create CkArrayOptions for a 2D
 array with only the odd indices from (1,1) to (10,10) being populated:
 
-::
+.. code-block:: c++
 
    // Set at construction
    CkArrayOptions options(CkArrayIndex2D(1,1),
@@ -5616,7 +5616,7 @@ The default for start is :math:`0^d` and the default for step is
 :math:`1^d` (where :math:`d` is the dimension of the array), so the
 following are equivalent:
 
-::
+.. code-block:: c++
 
    // Specify just the number of elements
    CkArrayOptions options(nElements);
@@ -5659,7 +5659,7 @@ which can be used similar to custom ones described below.
 A custom map object is implemented as a group which inherits from
 CkArrayMap and defines these virtual methods:
 
-::
+.. code-block:: c++
 
    class CkArrayMap : public Group
    {
@@ -5675,7 +5675,7 @@ CkArrayMap and defines these virtual methods:
 For example, a simple 1D blockmapping scheme. Actual mapping is handled
 in the procNum function.
 
-::
+.. code-block:: c++
 
    class BlockMap : public CkArrayMap
    {
@@ -5701,7 +5701,7 @@ the location of a new array’s elements using the setMap method of the
 CkArrayOptions object described above. For example, if you’ve declared a
 map object named “BlockMap”:
 
-::
+.. code-block:: c++
 
    // Create the map group
    CProxy_BlockMap myMap=CProxy_BlockMap::ckNew();
@@ -5730,7 +5730,7 @@ populateInitial on each processor.
 You can create your own set of elements by creating your own map object
 and overriding this virtual function of CkArrayMap:
 
-::
+.. code-block:: c++
 
    virtual void populateInitial(int arrayHdl,int numInitial,
            void *msg,CkArray *mgr)
@@ -5743,7 +5743,7 @@ populateInitial creates new array elements using the method ``void
 CkArray::insertInitial(CkArrayIndex idx,void \*ctorMsg)``. For example, to
 create one row of 2D array elements on each processor, you would write:
 
-::
+.. code-block:: c++
 
    void xyElementMap::populateInitial(int arrayHdl,int numInitial,
        void *msg,CkArray *mgr)
@@ -5772,7 +5772,7 @@ migrate together. For example, this code creates two arrays A and B
 which are bound together- A[i] and B[i] will always be on the same
 processor.
 
-::
+.. code-block:: c++
 
    // Create the first array normally
    aProxy=CProxy_A::ckNew(parameters,nElements);
@@ -5813,7 +5813,7 @@ element migrated, the *data* pointer in *UserArray* is re-allocated in
 *pup()*, thus *UserArray* is responsible to refresh the pointer *dest*
 stored in *Alibrary*.
 
-::
+.. code-block:: c++
 
    class Alibrary: public CProxy_Alibrary {
    public:
@@ -5868,7 +5868,7 @@ at any time. Array elements need not be contiguous.
 If using insert to create all the elements of the array, you must call
 CProxy_Array::doneInserting before using the array.
 
-::
+.. code-block:: c++
 
    // In the .C file:
    int x,y,z;
@@ -5944,7 +5944,7 @@ restriction and let the array creation be made from any PE. To do this,
 CkCallback must be given as an argument for ckNew to provide the created
 chare array’s CkArrayID to the callback function.
 
-::
+.. code-block:: c++
 
    CProxy_SomeProxy::ckNew(parameters, nElements, CkCallback(CkIndex_MyClass::someFunction(NULL), thisProxy));
 
@@ -5961,7 +5961,7 @@ default constructor is expected to be used.
 Alternatively, CkArrayOptions can be used in place of nElements to
 further configure array characteristics.
 
-::
+.. code-block:: c++
 
    // Creating a 3-dimensional chare array with 2 parameters
    CkArrayOptions options(dimX, dimY, dimZ);
@@ -5984,7 +5984,7 @@ index data.
 For example, if you have a structure or class named “Foo”, you can use a
 Foo object as an array index by defining the class:
 
-::
+.. code-block:: c++
 
     // Include to inherit from CkArrayIndex
     #include <charm++.h>
@@ -6011,7 +6011,7 @@ user code. Larger values will increase the size of each message.
 
 You can then declare an array indexed by Foo objects with
 
-::
+.. code-block:: c++
 
     // in the .ci file:
     array [Foo] AF { entry AF(); ... }
@@ -6029,14 +6029,14 @@ You can then declare an array indexed by Foo objects with
 Note that since our CkArrayIndexFoo constructor is not declared with the
 explicit keyword, we can equivalently write the last line as:
 
-::
+.. code-block:: c++
 
     a[f].insert();
 
 The array index (an object of type Foo) is then accessible as “thisIndex”. For
 example:
 
-::
+.. code-block:: c++
 
     // in the .C file:
     AF::AF() {
@@ -6087,7 +6087,7 @@ ckNew() function of the CProxySection. The user will need to provide
 array indexes of all the array section members through either explicit
 enumeration, or an index range expression. For example, for a 3D array:
 
-::
+.. code-block:: c++
 
      std::vector<CkArrayIndex3D> elems;  // add array indices
      for (int i=0; i<10; i++)
@@ -6099,7 +6099,7 @@ enumeration, or an index range expression. For example, for a 3D array:
 Alternatively, one can do the same thing by providing the index range
 [lbound:ubound:stride] for each dimension:
 
-::
+.. code-block:: c++
 
      CProxySection_Hello proxy = CProxySection_Hello::ckNew(helloArrayID, 0, 9, 1, 0, 19, 2, 0, 29, 2);
 
@@ -6110,7 +6110,7 @@ For user-defined array index other than CkArrayIndex1D to
 CkArrayIndex6D, one needs to use the generic array index type:
 CkArrayIndex.
 
-::
+.. code-block:: c++
 
      std::vector<CkArrayIndex> elems;  // add array indices
      CProxySection_Hello proxy = CProxySection_Hello::ckNew(helloArrayID, elems);
@@ -6160,7 +6160,7 @@ Section Multicasts
 Once the proxy is obtained at section creation time, the user can
 broadcast to all the section members, like this:
 
-::
+.. code-block:: c++
 
      CProxySection_Hello proxy;
      proxy.someEntry(...); // section broadcast
@@ -6183,7 +6183,7 @@ By default, CkMulticast builds a spanning tree for multicast/reduction
 with a factor of 2 (binary tree). One can specify a different branching
 factor when creating the section.
 
-::
+.. code-block:: c++
 
      CProxySection_Hello sectProxy = CProxySection_Hello::ckNew(..., 3); // factor is 3
 
@@ -6192,7 +6192,7 @@ from CkMcastBaseMsg, as the following example shows. Note that
 CkMcastBaseMsg must come first, this is IMPORTANT for CkMulticast
 library to retrieve section information out of the message.
 
-::
+.. code-block:: c++
 
    class HiMsg : public CkMcastBaseMsg, public CMessage_HiMsg
    {
@@ -6222,7 +6222,7 @@ parameter in the contribute(). The CkSectionInfo for a section can be
 retrieved from a message in a multicast entry point using function call
 CkGetSectionInfo:
 
-::
+.. code-block:: c++
 
      CkSectionInfo cookie;
 
@@ -6249,7 +6249,7 @@ use.
 
 See the following example:
 
-::
+.. code-block:: c++
 
        CkCallback cb(CkIndex_myArrayType::myReductionEntry(NULL),thisProxy);
        CProxySection_Hello::contribute(sizeof(int), &data, CkReduction::sum_int, cookie, cb);
@@ -6278,7 +6278,7 @@ not optimized after multicast root migrated.” In the current
 implementation, the user needs to initiate the rebuilding process using
 resetSection.
 
-::
+.. code-block:: c++
 
    void Foo::pup(PUP::er & p) {
        // if I am multicast root and it is unpacking
@@ -6311,7 +6311,7 @@ characteristics.
 
 Given three arrays declared thusly:
 
-::
+.. code-block:: c++
 
   std::vector<CkArrayID> aidArr(3);
   for (int i=0; i<3; i++) {
@@ -6322,7 +6322,7 @@ Given three arrays declared thusly:
 One can make a section including the lower half elements of all three
 arrays as follows:
 
-::
+.. code-block:: c++
 
   int aboundary = ArraySize/2;
   int afloor = aboundary;
@@ -6371,7 +6371,7 @@ in an application. In the following we show a manual delegation example
 using CkMulticast (the same can be applied to custom delegation
 managers):
 
-::
+.. code-block:: c++
 
      CkArrayOptions opts(...);
      opts.setSectionAutoDelegate(false); // manual delegation
@@ -6388,13 +6388,13 @@ One can also set the default branching factor when creating a
 CkMulticastMgr group. Sections created via this manager will use the
 specified branching factor for their multicast tree. For example,
 
-::
+.. code-block:: c++
 
      CkGroupID mCastGrpId = CProxy_CkMulticastMgr::ckNew(3); // factor is 3
 
 Contributing using a custom CkMulticastMgr group:
 
-::
+.. code-block:: c++
 
      CkSectionInfo cookie;
 
@@ -6409,7 +6409,7 @@ Contributing using a custom CkMulticastMgr group:
 Setting default reduction client for a section when using manual
 delegation:
 
-::
+.. code-block:: c++
 
      CProxySection_Hello sectProxy;
      CkMulticastMgr *mcastGrp = CProxy_CkMulticastMgr(mCastGrpId).ckLocalBranch();
@@ -6417,7 +6417,7 @@ delegation:
 
 Writing the pup method:
 
-::
+.. code-block:: c++
 
     void Foo::pup(PUP::er & p) {
       // if I am multicast root and it is unpacking
@@ -6450,7 +6450,7 @@ BaseChare, then the derived chare of type DerivedChare needs to be
 declared in the Charm++ interface file to be explicitly derived from
 BaseChare. Thus, the constructs in the ``.ci`` file should look like:
 
-::
+.. code-block:: c++
 
      chare BaseChare {
        entry BaseChare(someMessage *);
@@ -6472,7 +6472,7 @@ to remotely invoke only public methods.
 
 The class definitions of these chares should look like:
 
-::
+.. code-block:: c++
 
      class BaseChare : public CBase_BaseChare {
        // private or protected data
@@ -6491,7 +6491,7 @@ It is possible to create a derived chare, and invoke methods of base
 chare from it, or to assign a derived chare proxy to a base chare proxy
 as shown below:
 
-::
+.. code-block:: c++
 
      ...
      otherMessage *msg = new otherMessage();
@@ -6508,7 +6508,7 @@ DerivedChare::DerivedChare(someMessage*) to
 BaseChare::BaseChare(someMessage*), they can be forwarded through the
 CBase type constructor as follows:
 
-::
+.. code-block:: c++
 
    DerivedChare::DerivedChare(someMessage *msg)
    : CBase_DerivedChare(msg) // Will forward all arguments to BaseChare::BaseChare
@@ -6530,7 +6530,7 @@ Inheritance for Messages
 Messages cannot inherit from other messages. A message can, however,
 inherit from a regular C++ class. For example:
 
-::
+.. code-block:: c++
 
     // In the .ci file:
     message BaseMessage1;
@@ -6579,7 +6579,7 @@ described below.
 
 A message template might be declared as follows:
 
-::
+.. code-block:: c++
 
    module A {
      template <class DType, int N=3>
@@ -6591,7 +6591,7 @@ Note that default template parameters are supported.
 If one wished to include variable-length arrays in a message template,
 those can be accomodated as well:
 
-::
+.. code-block:: c++
 
    module B {
      template <class DType>
@@ -6603,7 +6603,7 @@ those can be accomodated as well:
 Similarly, chare class templates (for various kinds of chares) would be
 written:
 
-::
+.. code-block:: c++
 
    module C {
      template <typename T>
@@ -6632,7 +6632,7 @@ written:
 
 Entry method templates are declared like so:
 
-::
+.. code-block:: c++
 
    module D {
        array [1D] libArray {
@@ -6646,7 +6646,7 @@ The definition of templated Charm++ entities works almost identically to
 the definition of non-template entities, with the addition of the
 expected template signature:
 
-::
+.. code-block:: c++
 
    // A.h
    #include "A.decl.h"
@@ -6680,7 +6680,7 @@ instantiation is desired.
 For the message and chare templates described above, a few
 instantiations might look like
 
-::
+.. code-block:: c++
 
    module D {
      extern module A;
@@ -6698,7 +6698,7 @@ because they must specify the chare class containing them. The template
 arguments are also specified directly in the method’s parameters, rather
 than as distinct template arguments.
 
-::
+.. code-block:: c++
 
    module E {
      extern module D;
@@ -6711,7 +6711,7 @@ To enable generic programming using Charm++ entities, we define a number
 of type trait utilities. These can be used to determine at compile-time
 if a type is a certain kind of Charm++ type:
 
-::
+.. code-block:: c++
 
    #include "charm++_type_traits.h"
 
@@ -6755,7 +6755,7 @@ as an additional parameter to contribute. It is an error for chare array
 elements to specify different callbacks to the same reduction
 contribution.
 
-::
+.. code-block:: c++
 
        double forces[2]=get_my_forces();
        // When done, broadcast the CkReductionMsg to "myReductionEntry"
@@ -6765,14 +6765,14 @@ contribution.
 In the case of the reduced version used for synchronization purposes,
 the callback parameter will be the only input parameter:
 
-::
+.. code-block:: c++
 
        CkCallback cb(CkIndex_myArrayType::myReductionEntry(NULL), thisProxy);
        contribute(cb);
 
 and the corresponding callback function:
 
-::
+.. code-block:: c++
 
    void myReductionEntry(CkReductionMsg *msg)
    {
@@ -6816,14 +6816,14 @@ CkReductionMsg::buildNew(int nBytes,const void \*data) method.
 
 Thus every reduction function has the prototype:
 
-::
+.. code-block:: c++
 
    CkReductionMsg *reductionFn(int nMsg,CkReductionMsg **msgs);
 
 For example, a reduction function to add up contributions consisting of
 two machine ``short int``\ s would be:
 
-::
+.. code-block:: c++
 
    CkReductionMsg *sumTwoShorts(int nMsg,CkReductionMsg **msgs)
    {
@@ -6854,7 +6854,7 @@ every node, you can safely store the CkReduction::reducerType in a
 global or class-static variable. For the example above, the reduction
 function is registered and used in the following manner:
 
-::
+.. code-block:: c++
 
    // In the .ci file:
    initnode void registerSumTwoShorts(void);
@@ -6896,7 +6896,7 @@ own custom streamable reducers by reusing the message memory of the
 zeroth message in their reducer function by passing it as the last
 argument to CkReduction::buildNew:
 
-::
+.. code-block:: c++
 
    CkReductionMsg *sumTwoShorts(int nMsg,CkReductionMsg **msgs)
    {
@@ -6921,7 +6921,7 @@ when calling CkReduction::addReducer by specifying an optional boolean
 parameter (default is false). They can also provide a name string for
 their reducer to aid in debugging (default is NULL).
 
-::
+.. code-block:: c++
 
    static void initNodeFn(void) {
        sumTwoShorts = CkReduction::addReducer(sumTwoShorts, /* streamable = */ true, /* name = */ "sumTwoShorts");
@@ -6952,7 +6952,7 @@ No allocation
 
 The simplest case is when there is no dynamic allocation. Example:
 
-.. code-block:: cpp
+.. code-block:: c++
 
    class keepsFoo : public mySuperclass {
    private:
@@ -6973,7 +6973,7 @@ The next simplest case is when we contain a class that is always
 allocated during our constructor, and deallocated during our destructor.
 Then no allocation is needed within the pup routine.
 
-.. code-block:: cpp
+.. code-block:: c++
 
    class keepsHeapFoo : public mySuperclass {
    private:
@@ -6996,7 +6996,7 @@ If we need values obtained during the pup routine before we can allocate
 the class, we must allocate the class inside the pup routine. Be sure to
 protect the allocation with ``if (p.isUnpacking())``.
 
-.. code-block:: cpp
+.. code-block:: c++
 
    class keepsOneFoo : public mySuperclass {
    private:
@@ -7023,7 +7023,7 @@ pup the array length, do our allocation, and then pup the array data. We
 could allocate memory using malloc/free or other allocators in exactly
 the same way.
 
-.. code-block:: cpp
+.. code-block:: c++
 
    class keepsDoubles : public mySuperclass {
    private:
@@ -7053,7 +7053,7 @@ If our allocated object may be ``NULL``, our allocation becomes much more
 complicated. We must first check and pup a flag to indicate whether the
 object exists, then depending on the flag, pup the object.
 
-.. code-block:: cpp
+.. code-block:: c++
 
    class keepsNullFoo : public mySuperclass {
    private:
@@ -7085,7 +7085,7 @@ An array of actual classes can be treated exactly the same way as an
 array of basic types. ``PUParray`` will pup each element of the array
 properly, calling the appropriate ``operator|``.
 
-.. code-block:: cpp
+.. code-block:: c++
 
    class keepsFoos : public mySuperclass {
    private:
@@ -7116,7 +7116,7 @@ since the PUParray routine does not work with pointers. An "allocate"
 routine to set up the array could simplify this code. More ambitious is
 to construct a "smart pointer" class that includes a pup routine.
 
-.. code-block:: cpp
+.. code-block:: c++
 
    class keepsFooPtrs : public mySuperclass {
    private:
@@ -7200,7 +7200,7 @@ needed.
 For example, if *parent* is a concrete superclass, and *child* and *tchild* are
 its subclasses:
 
-.. code-block:: cpp
+.. code-block:: c++
 
    // --------- In the .ci file ---------
    PUPable parent;
@@ -7267,7 +7267,7 @@ pointer to a parent or child using the vertical bar ``PUP::er`` syntax,
 which on the receive side will create a new object of the appropriate
 type:
 
-.. code-block:: cpp
+.. code-block:: c++
 
    class keepsParent {
        parent *obj; // May actually point to a child class (or be NULL)
@@ -7290,7 +7290,7 @@ If ``obj`` is ``NULL`` when packed, it will be restored to ``NULL`` when unpacke
 For example, if the nodes of a binary tree are PUP::able, one may write
 a recursive pup routine for the tree quite easily:
 
-.. code-block:: cpp
+.. code-block:: c++
 
    // --------- In the .ci file ---------
    PUPable treeNode;
@@ -7340,7 +7340,7 @@ can be kept and the object used indefinitely.
 For example, if the entry method bar needs a ``PUP::able`` parent object for
 in-call processing, you would use a ``CkReference`` like this:
 
-.. code-block:: cpp
+.. code-block:: c++
 
    // --------- In the .ci file ---------
    entry void barRef(int x, CkReference<parent> p);
@@ -7353,7 +7353,7 @@ in-call processing, you would use a ``CkReference`` like this:
 If the entry method needs to keep its parameter, use a ``CkPointer`` like
 this:
 
-.. code-block:: cpp
+.. code-block:: c++
 
    // --------- In the .ci file ---------
    entry void barPtr(int x, CkPointer<parent> p);
@@ -7368,7 +7368,7 @@ messages, which are consumed when sent, the same object can be passed to
 several parameter marshalled entry methods. In the example above, we
 could do:
 
-.. code-block:: cpp
+.. code-block:: c++
 
       parent *p = new child;
       someProxy.barRef(x, *p);
@@ -7382,7 +7382,7 @@ C and Fortran programmers can use a limited subset of the ``PUP::er``
 capability. The routines all take a handle named ``pup_er``. The routines
 have the prototype:
 
-.. code-block:: c
+.. code-block:: c++
 
    void pup_type(pup_er p, type *val);
    void pup_types(pup_er p, type *vals, int nVals);
@@ -7394,7 +7394,7 @@ C meanings.
 
 A byte-packing routine
 
-.. code-block:: c
+.. code-block:: c++
 
    void pup_bytes(pup_er p, void *data, int nBytes);
 
@@ -7445,7 +7445,7 @@ section number with the ``seek`` method, and end the seeking with the
 ``endBlock`` method. For example, if we have two objects A and B, where A's
 pup depends on and affects some object B, we can pup the two with:
 
-.. code-block:: cpp
+.. code-block:: c++
 
    void pupAB(PUP::er &p)
    {
@@ -7481,7 +7481,7 @@ System-level programmers may occasionally find it useful to define their
 own ``PUP::er`` objects. The system ``PUP::er`` class is an abstract base class
 that funnels all incoming pup requests to a single subroutine:
 
-.. code-block:: cpp
+.. code-block:: c++
 
        virtual void bytes(void *p, int n, size_t itemSize, dataType t);
 
@@ -7543,7 +7543,7 @@ printAllocation(FILE \*fp):
 For example, one can obtain the rank of a processor, whose coordinates are
 known, on Cray XE6 using the following code:
 
-.. code-block:: cpp
+.. code-block:: c++
 
    TopoManager *tmgr = TopoManager::getTopoManager();
    int rank, x, y, z, t;
@@ -7679,7 +7679,7 @@ Checkpointing
 
 The API to checkpoint the application is:
 
-.. code-block:: cpp
+.. code-block:: c++
 
      void CkStartCheckpoint(char* dirname, const CkCallback& cb);
 
@@ -7688,7 +7688,7 @@ files will be stored, and ``cb`` is the callback function which will be
 invoked after the checkpoint is done, as well as when the restart is
 complete. Here is an example of a typical use:
 
-.. code-block:: cpp
+.. code-block:: c++
 
      /* ... */ CkCallback cb(CkIndex_Hello::SayHi(), helloProxy);
      CkStartCheckpoint("log", cb);
@@ -7816,7 +7816,7 @@ Checkpointing
 The function that application developers can call to record a checkpoint
 in a chare-array-based application is:
 
-.. code-block:: cpp
+.. code-block:: c++
 
          void CkStartMemCheckpoint(CkCallback &cb)
 
@@ -7833,7 +7833,7 @@ double in-memory checkpoint) or ``"to_file=file_name"`` (to checkpoint to
 disk), and pass that object to the function ``AMPI_Migrate()`` as in the
 following:
 
-.. code-block:: cpp
+.. code-block:: c++
 
    // Setup
    MPI_Info in_memory, to_file;
@@ -7884,7 +7884,7 @@ it stores them in the local disk. The checkpoint files are named
 Users can pass the runtime option ``+ftc_disk`` to activate this mode. For
 example:
 
-::
+.. code-block:: c++
 
       ./charmrun hello +p8 +ftc_disk
 
@@ -7895,7 +7895,7 @@ In order to have the double local-storage checkpoint/restart
 functionality available, the parameter ``syncft`` must be provided at
 build time:
 
-::
+.. code-block:: c++
 
       ./build charm++ netlrts-linux-x86_64 syncft
 
@@ -7920,9 +7920,9 @@ failures occur after the first checkpoint. The runtime parameter
 ``kill_file`` has to be added to the command line along with the file
 name:
 
-::
+.. code-block:: bash
 
-      ./charmrun hello +p8 +kill_file <file>
+   $ ./charmrun hello +p8 +kill_file <file>
 
 An example of this usage can be found in the ``syncfttest`` targets in
 ``tests/charm++/jacobi3d``.
@@ -8043,7 +8043,7 @@ source code. The interface functions of this library are as follows:
 Lambda syntax for *CkLoop* is also supported. The interface for using
 lambda syntax is as follows:
 
-.. code-block:: cpp
+.. code-block:: c++
 
       void CkLoop_Parallelize(
       int numChunks, int lowerRange, int upperRange,
@@ -8095,7 +8095,7 @@ The changes to the CkLoop API call are the following:
    additional variable that provides the fraction of iterations that are
    statically scheduled:
 
-   .. code-block:: cpp
+   .. code-block:: c++
 
       void CkLoop_ParallelizeHybrid(
       float staticFraction,
@@ -8253,7 +8253,7 @@ chare is running. The following is an example to describe how you can
 use shared data structures for OpenMP regions on the integrated OpenMP
 with Charm++:
 
-.. code-block:: cpp
+.. code-block:: c++
 
    /* Maximum possible number of OpenMP threads in the upcoming OpenMP region.
       Users can restrict this number with 'omp_set_num_threads()' for each chare
@@ -8288,7 +8288,7 @@ OpenMP library and ported to Charm++ program running multiple OpenMP
 instances on chares. The test suite can be found in
 ``tests/converse/openmp_test``.
 
-.. code-block:: cpp
+.. code-block:: c++
 
    /* omp_<directive>_<clauses> */
    omp_atomic
@@ -8368,7 +8368,7 @@ PE again by calling this API with value 1 after they disable it during
 certain procedure so that the PE can help others after that. The
 following example shows how this API can be used.
 
-.. code-block:: cpp
+.. code-block:: c++
 
    CkSetPeHelpsOtherThreads(0);
 
@@ -8467,7 +8467,7 @@ with a pure MPI program:
    functions whose task is to start work for the Charm++ libraries. Here
    is an example interface function for the *hello* library.
 
-   .. code-block:: cpp
+   .. code-block:: c++
 
       void HelloStart(int elems)
       {
@@ -8830,7 +8830,7 @@ user can provide a specific class which inherits from
 ``LBPredictorFunction`` and implement the appropriate functions. Here is
 the abstract class:
 
-::
+.. code-block:: c++
 
    class LBPredictorFunction {
    public:
@@ -8851,7 +8851,7 @@ the abstract class:
    the function parameters. An example for the *predict* function is
    given below.
 
-   ::
+   .. code-block:: c++
 
       double predict(double x, double *param) {return (param[0]*x + param[1]);}
 
@@ -8864,7 +8864,7 @@ the abstract class:
    parameters, respectively). For the function in the example should
    look like:
 
-   ::
+   .. code-block:: c++
 
       void function(double x, double *param, double &y, double *dyda) {
         y = predict(x, param);
@@ -8927,7 +8927,7 @@ strategies).
 In an array element, the following function can be invoked to overwrite
 the CPU load that is measured by the load balancing framework.
 
-::
+.. code-block:: c++
 
       double newTiming;
       setObjTime(newTiming);
@@ -8938,7 +8938,7 @@ the superclass of all array elements.
 The users can also retrieve the current timing that the load balancing
 runtime has measured for the current array element using *getObjTime()*.
 
-::
+.. code-block:: c++
 
       double measuredTiming;
       measuredTiming = getObjTime();
@@ -8955,14 +8955,14 @@ each Chare based on certain computational model of the applications.
 To do so, in the array element’s constructor, the user first needs to
 turn off automatic CPU load measurement completely by setting
 
-::
+.. code-block:: c++
 
       usesAutoMeasure = false;
 
 The user must also implement the following function to the chare array
 classes:
 
-::
+.. code-block:: c++
 
       virtual void CkMigratable::UserSetLBLoad();      // defined in base class
 
@@ -8988,7 +8988,7 @@ their strategy for load balancing based on the instrumented ProcArray
 and ObjGraph provided by the load balancing framework. This strategy is
 implemented within this function:
 
-::
+.. code-block:: c++
 
    void FooLB::work(LDStats *stats) {
      /** ========================== INITIALIZATION ============================= */
@@ -9067,7 +9067,7 @@ information .
 
 The database data structure named LDStats is defined in *CentralLB.h*:
 
-::
+.. code-block:: c++
 
 
      struct ProcStats {  // per processor
@@ -9200,7 +9200,7 @@ char \*pack();
 A typical invocation to send a request from the client to the server has
 the following format:
 
-::
+.. code-block:: c++
 
    CcsSendRequest (&server, "pyCode", 0, request.size(), request.pack());
 
@@ -9213,7 +9213,7 @@ To execute a Python script on a running server, the client has to create
 an instance of ``PythonExecute``, the two constructors have the
 following signature (java has a corresponding functionality):
 
-::
+.. code-block:: c++
 
    PythonExecute(char *code, bool persistent=false, bool highlevel=false, CmiUInt4 interpreter=0);
    PythonExecute(char *code, char *method, PythonIterator *info, bool persistent=false,
@@ -9267,7 +9267,7 @@ busy waiting
 These flags can be set and checked with the following routines (CmiUInt4
 represent a 4 byte unsigned integer):
 
-::
+.. code-block:: c++
 
    void setCode(char *set);
    void setPersistent(bool set);
@@ -9394,7 +9394,7 @@ invoked. These values can be specified either while constructing the
 PythonExecute variable (see the second constructor in
 section :numref:`pythonExecute`), or with the following methods:
 
-::
+.. code-block:: c++
 
    void setMethodName(char *name);
    void setIterator(PythonIterator *iter);
@@ -9410,7 +9410,7 @@ because it is trivial to serialize such objects.
 If instead pointers or dynamic memory allocation are used, the following
 methods have to be reimplemented to support correct serialization:
 
-::
+.. code-block:: c++
 
    int size();
    char * pack();
@@ -9461,7 +9461,7 @@ safe to call ``CcsNoResponse(server)``.
 
 The two options can also be dynamically set with the following methods:
 
-::
+.. code-block:: c++
 
    void setWait(bool set);
    bool isWait();
@@ -9487,7 +9487,7 @@ immediate return (false).
 
 The wait option can be dynamically modified with the two methods:
 
-::
+.. code-block:: c++
 
    void setWait(bool set);
    bool isWait();
@@ -9507,7 +9507,7 @@ python-compliant. This is done through the keyword python placed in
 square brackets before the object name in the .ci file. Some examples
 follow:
 
-::
+.. code-block:: c++
 
    mainchare [python] main {...}
    array [1D] [python] myArray {...}
@@ -9520,7 +9520,7 @@ registers it to receive scripts directed to “pycode”. The argument of
 ``registerPython`` is the string that CCS will use to address the Python
 scripting capability of the object.
 
-::
+.. code-block:: c++
 
    Cproxy_myArray localVar = CProxy_myArray::ckNew(10);
    localVar.registerPython("pycode");
@@ -9536,7 +9536,7 @@ the *ck* module. Two of these, **read** and **write** are only available
 if redefined by the object. The signatures of the two methods to
 redefine are:
 
-::
+.. code-block:: c++
 
    PyObject* read(PyObject* where);
    void write(PyObject* where, PyObject* what);
@@ -9560,7 +9560,7 @@ subsection :numref:`pythonIterator`, it is necessary to implement two
 functions which will be called by the system. These two functions have
 the following signatures:
 
-::
+.. code-block:: c++
 
    int buildIterator(PyObject*, void*);
    int nextIteratorUpdate(PyObject*, PyObject*, void*);
@@ -9616,7 +9616,7 @@ The name of the function identifies the type of Python object stored
 inside the PyObject container (i.e String, Int, Long, Float, Complex),
 while the parameter of the functions identifies the C++ object type.
 
-::
+.. code-block:: c++
 
    void pythonSetString(PyObject*, char*, char*);
    void pythonSetString(PyObject*, char*, char*, int);
@@ -9653,7 +9653,7 @@ can return an object as complex as needed.
 
 The method must have the following signature:
 
-::
+.. code-block:: c++
 
    entry [python] void highMethod(int handle);
 
@@ -9736,7 +9736,7 @@ proxy. This restores the proxy to normal operation.
 
 One use of these routines might be:
 
-::
+.. code-block:: c++
 
      CkGroupID mgr=somebodyElsesCommLib(...);
      CProxy_foo p=...;
@@ -9751,7 +9751,7 @@ The client interface is very simple; but it is often not called by users
 directly. Often the delegate manager library needs some other
 initialization, so a more typical use would be:
 
-::
+.. code-block:: c++
 
      CProxy_foo p=...;
      p.someEntry1(...); //Sent to foo normally
@@ -9780,7 +9780,7 @@ delegated to it is used. Since any kind of proxy can be delegated, there
 are separate virtual methods for delegated Chares, Groups, NodeGroups,
 and Arrays.
 
-::
+.. code-block:: c++
 
    class CkDelegateMgr : public Group {
    public:
@@ -9827,7 +9827,7 @@ parameters passed in have the following descriptions.
 #. **idx** The destination array index. This may be looked up using the
    lastKnown method of the array manager, e.g., using:
 
-   ::
+   .. code-block:: c++
 
      int lastPE=CProxy_CkArray(a).ckLocalBranch()->lastKnown(idx);
 
@@ -9863,7 +9863,7 @@ Exposing Control Points in a Charm++ Program
 The program should include a header file before any of its ``*.decl.h``
 files:
 
-::
+.. code-block:: c++
 
        #include <controlPoints.h>
 
@@ -9873,7 +9873,7 @@ made at startup in the program.
 The program will request the values for each control point on PE 0.
 Control point values are non-negative integers:
 
-::
+.. code-block:: c++
 
        my_var = controlPoint("any_name", 5, 10);
        my_var2 = controlPoint("another_name", 100,101);
@@ -9882,7 +9882,7 @@ To specify information about the effects of each control point, make
 calls such as these once on PE 0 before accessing any control point
 values:
 
-::
+.. code-block:: c++
 
        ControlPoint::EffectDecrease::Granularity("num_chare_rows");
        ControlPoint::EffectDecrease::Granularity("num_chare_cols");
@@ -9916,7 +9916,7 @@ Control Point Framework Advances Phases
 The program provides a callback to the control point framework in a
 manner such as this:
 
-::
+.. code-block:: c++
 
        // Once early on in program, create a callback, and register it
        CkCallback cb(CkIndex_Main::granularityChange(NULL),thisProxy);
@@ -9931,7 +9931,7 @@ Alternatively, the program can specify that it wants to call
 to delay its adaptation for a while. To do this, it specifies ``false``
 as the final parameter to ``registerCPChangeCallback`` as follows:
 
-::
+.. code-block:: c++
 
       registerCPChangeCallback(cb, false);
 
@@ -9940,7 +9940,7 @@ as the final parameter to ``registerCPChangeCallback`` as follows:
 Program Advances Phases
 ^^^^^^^^^^^^^^^^^^^^^^^
 
-::
+.. code-block:: c++
 
         registerControlPointTiming(duration); // called after each program iteration on PE 0
         gotoNextPhase(); // called after some number of iterations on PE 0
@@ -9967,7 +9967,7 @@ experimental framework, these are subject to change.
 The scheme used for tuning can be selected at runtime by the use of one
 of the following options:
 
-::
+.. code-block:: none
 
         +CPSchemeRandom            Randomly Select Control Point Values
     +CPExhaustiveSearch            Exhaustive Search of Control Point Values
@@ -9985,14 +9985,14 @@ so is not enabled by default. To use any type of measurement based
 steering scheme, it is necessary to add a runtime command line argument
 to the user program to enable the tracing module:
 
-::
+.. code-block:: none
 
        +CPEnableMeasurements
 
 The following flags enable the gathering of the different types of
 available measurements.
 
-::
+.. code-block:: none
 
            +CPGatherAll            Gather all types of measurements for each phase
    +CPGatherMemoryUsage            Gather memory usage after each phase
@@ -10002,7 +10002,7 @@ The control point framework will periodically adapt the control point
 values. The following command line flag determines the frequency at
 which the control point framework will attempt to adjust things.
 
-::
+.. code-block:: none
 
         +CPSamplePeriod     number The time between Control Point Framework samples (in seconds)
 
@@ -10012,7 +10012,7 @@ runs. The following command line arguments specify that a file named
 measurements for each phase as well as the control point values used in
 each phase.
 
-::
+.. code-block:: none
 
             +CPSaveData            Save Control Point timings & configurations at completion
             +CPLoadData            Load Control Point timings & configurations at startup
@@ -10079,7 +10079,7 @@ To make a Charm++ application malleable, first, pup routines for all of
 the constructs in the application need to be written. This includes
 writing a pup routine for the ``mainchare`` and marking it migratable:
 
-::
+.. code-block:: c++
 
        mainchare [migratable]  Main { ... }
 
@@ -10097,14 +10097,14 @@ four cores from each node, whereas what you likely want is to use eight
 cores on only one of the physical nodes after shrinking. For example,
 instead of having a nodelist like this:
 
-::
+.. code-block:: none
 
        host a
        host b
 
 the nodelist should be like this:
 
-::
+.. code-block:: none
 
        host a
        host a
@@ -10346,7 +10346,7 @@ of these modes is shown. Caution: in reality, one almost always has to
 add some command-line options in addition to the simplified syntax shown
 below. The options are described next.
 
-::
+.. code-block:: none
 
     * Compile C                            charmc -o pgm.o pgm.c
     * Compile C++                          charmc -o pgm.o pgm.C
@@ -10535,9 +10535,9 @@ load the executable onto the parallel machine.
 
 To run a Charm++ program named “pgm” on four processors, type:
 
-::
+.. code-block:: bash
 
-   charmrun pgm +p4
+   charmrun pgm +p4
 
 Execution on platforms which use platform specific launchers, (i.e.,
 **aprun**, **ibrun**), can proceed without charmrun, or charmrun can be
@@ -10550,9 +10550,9 @@ local machine, but it is convenient and often useful for debugging. For
 example, a Charm++ program can be run on one processor in the debugger
 using:
 
-::
+.. code-block:: bash
 
-   gdb pgm
+   gdb pgm
 
 If the program needs some environment variables to be set for its
 execution on compute nodes (such as library paths), they can be set in
@@ -10690,9 +10690,9 @@ The remaining options cover details of process launch and connectivity:
    ``++remote-shell`` and list them as part of the value after the
    executable name as follows:
 
-   ::
+   .. code-block:: bash
 
-      ./charmrun ++mpiexec ++remote-shell "mpiexec --YourArgumentsHere" ./pgm
+      ./charmrun ++mpiexec ++remote-shell "mpiexec --YourArgumentsHere" ./pgm
 
    Use of this option can potentially provide a few benefits:
 
@@ -10765,9 +10765,9 @@ The remaining options cover details of process launch and connectivity:
    Script to run node-program with. The specified run script is invoked
    with the node program and parameter. For example:
 
-   ::
+   .. code-block:: bash
 
-      ./charmrun +p4 ./pgm 100 2 3 ++runscript ./set_env_script
+      ./charmrun +p4 ./pgm 100 2 3 ++runscript ./set_env_script
 
    In this case, the ``set_env_script`` is invoked on each node before
    launching ``pgm``.
@@ -10840,9 +10840,9 @@ process there are two types of threads:
   schedules them on worker threads.
 | To use SMP mode in Charm++, build charm with the ``smp`` option, e.g.:
 
-::
+.. code-block:: bash
 
-   ./build charm++ netlrts-linux-x86_64 smp
+   ./build charm++ netlrts-linux-x86_64 smp
 
 There are various trade-offs associated with SMP mode. For instance,
 when using SMP mode there is no waiting to receive messages due to long
@@ -10923,9 +10923,9 @@ necessary to spawn one thread less than the number of cores in order to
 leave one free for the OS to run on. An example run command might look
 like:
 
-::
+.. code-block:: bash
 
-   ./charmrun ++ppn 3 +p6 +pemap 1-3,5-7 +commap 0,4 ./app <args>
+   ./charmrun ++ppn 3 +p6 +pemap 1-3,5-7 +commap 0,4 ./app <args>
 
 This will create two logical nodes/OS processes (2 = 6 PEs/3 PEs per
 node), each with three worker threads/PEs (``++ppn 3``). The worker
@@ -10996,7 +10996,7 @@ The format of this file allows you to define groups of machines, giving
 each group a name. Each line of the nodes file is a command. The most
 important command is:
 
-::
+.. code-block:: none
 
    host <hostname> <qualifiers>
 
@@ -11024,7 +11024,7 @@ All qualifiers accept “\*” as an argument, this resets the modifier to
 its default value. Note that currently, the passwd, cpus, and speed
 factors are ignored. Inline qualifiers are also allowed:
 
-::
+.. code-block:: none
 
    host beauty ++cpus 2 ++shell ssh
 
@@ -11034,7 +11034,7 @@ last qualifier on the “host” or “group” statement line.
 
 Here is a simple nodes file:
 
-::
+.. code-block:: none
 
            group kale-sun ++cpus 1
              host charm.cs.illinois.edu ++shell ssh
@@ -11051,9 +11051,9 @@ and group main. The ++nodegroup option is used to specify which group of
 machines to use. Note that there is wraparound: if you specify more
 nodes than there are hosts in the group, it will reuse hosts. Thus,
 
-::
+.. code-block:: bash
 
-           charmrun pgm ++nodegroup kale-sun +p6
+   $ charmrun pgm ++nodegroup kale-sun +p6
 
 uses hosts (charm, dp, grace, dagger, charm, dp) respectively as nodes
 (0, 1, 2, 3, 4, 5).
@@ -11061,9 +11061,9 @@ uses hosts (charm, dp, grace, dagger, charm, dp) respectively as nodes
 If you don’t specify a ++nodegroup, the default is ++nodegroup main.
 Thus, if one specifies
 
-::
+.. code-block:: bash
 
-           charmrun pgm +p4
+   $ charmrun pgm +p4
 
 it will use “localhost” four times. “localhost” is a Unix trick; it
 always find a name for whatever machine you’re on.
@@ -11588,7 +11588,7 @@ The calls for recording user events are the following:
 
    Eg.
 
-   ::
+   .. code-block:: c++
 
          traceRegisterUserEvent("Critical Code", 20); // on PE 0
          double critStart = CmiWallTimer();;  // start time
index 81c460cfb76b3d48e5bd6d30034b5578bcd1abd2..19a0d68b772e5cf399929c76e230a0204211f59e 100644 (file)
@@ -19,7 +19,7 @@ don’t execute ``main`` are asleep when the program begins. The function
 ``ConverseInit`` is used to start the Converse system, and to wake up the
 sleeping processors.
 
-::
+.. code-block:: c++
 
    typedef void (*CmiStartFn)(int argc, char **argv);
    void ConverseInit(int argc, char *argv[], CmiStartFn fn, int usched, int
@@ -73,21 +73,21 @@ returned. In this mode, all polling for messages must be done manually
 (probably using CsdScheduler explicitly). This option is not supported
 by the sim version.
 
-::
+.. code-block:: c++
 
   void ConverseExit(int exitcode /*optional*/)
 
 This function is only used in ConverseInit-returns mode, described
 above.
 
-::
+.. code-block:: c++
 
   void CmiAbort(char *msg)
 
 This function can be used portably to abnormally terminate a Converse
 program. Before termination, it prints a message supplied as ``msg``.
 
-::
+.. code-block:: c++
 
   void CmiAssert(int expr)
 
@@ -140,13 +140,13 @@ nonetheless, and the user must be aware that this is (usually) required.
 
 The following functions are provided to define the handler numbers:
 
-::
+.. code-block:: c++
 
   typedef void (*CmiHandler)(void *)
 
 Functions that handle Converse messages must be of this type.
 
-::
+.. code-block:: c++
 
   int CmiRegisterHandler(CmiHandler h)
 
@@ -159,7 +159,7 @@ the same numbers on all processors. This insures global consistency.
 CmiRegisterHandler returns the number which was chosen for the function
 being registered.
 
-::
+.. code-block:: c++
 
   int CmiRegisterHandlerGlobal(CmiHandler h)
 
@@ -170,7 +170,7 @@ broadcasting those handler numbers to other processors, and installing
 them using CmiNumberHandler below. The user should take care not to
 invoke those handlers until they are fully installed.
 
-::
+.. code-block:: c++
 
   int CmiRegisterHandlerLocal(CmiHandler h)
 
@@ -179,7 +179,7 @@ that is not consistent across processors. This function chooses a
 locally-meaningful number for the function, and records it locally. No
 attempt is made to ensure consistency across processors.
 
-::
+.. code-block:: c++
 
   void CmiNumberHandler(int n, CmiHandler h)
 
@@ -225,7 +225,7 @@ message.
 
 The following functions are provided to help build message buffers:
 
-::
+.. code-block:: c++
 
   void *CmiAlloc(int size)
 
@@ -236,14 +236,14 @@ way to allocate message buffers. The returned pointer point to the
 message header, the user data will follow it. See CmiMsgHeaderSizeBytes
 for this.
 
-::
+.. code-block:: c++
 
   void CmiFree(void *ptr)
 
 This function frees the memory pointed to by ptr. ptr should be a
 pointer that was previously returned by CmiAlloc.
 
-::
+.. code-block:: c++
 
   #define CmiMsgHeaderSizeBytes
 
@@ -253,20 +253,20 @@ header and the data. This macro helps you to do so. For example, if one
 want to allocate an array of 100 int, he should call the function this
 way:
 
-::
+.. code-block:: c++
 
   void CmiSetHandler(int *MessageBuffer, int HandlerId)
 
 This macro sets the handler number of a message to HandlerId.
 
-::
+.. code-block:: c++
 
   int CmiGetHandler(int *MessageBuffer)
 
 This call returns the handler of a message in the form of a handler
 number.
 
-::
+.. code-block:: c++
 
   CmiHandler CmiGetHandlerFunction(int *MessageBuffer)
 
@@ -310,35 +310,35 @@ we provide several variations on each send function:
    processor. This means that when the message is received, any “free”
    processor within than node can handle it.
 
-::
+.. code-block:: c++
 
   void CmiSyncSend(unsigned int destPE, unsigned int size, void *msg)
 
 Sends msg of size size bytes to processor destPE. When it returns, you
 may reuse the message buffer.
 
-::
+.. code-block:: c++
 
   void CmiSyncNodeSend(unsigned int destNode, unsigned int size, void *msg)
 
 Sends msg of size size bytes to node destNode. When it returns, you may
 reuse the message buffer.
 
-::
+.. code-block:: c++
 
   void CmiSyncSendAndFree(unsigned int destPE, unsigned int size, void *msg)
 
 Sends msg of size size bytes to processor destPE. When it returns, the
 message buffer has been freed using CmiFree.
 
-::
+.. code-block:: c++
 
   void CmiSyncNodeSendAndFree(unsigned int destNode, unsigned int size, void *msg)
 
 Sends msg of size size bytes to node destNode. When it returns, the
 message buffer has been freed using CmiFree.
 
-::
+.. code-block:: c++
 
   CmiCommHandle CmiAsyncSend(unsigned int destPE, unsigned int size, void *msg)
 
@@ -348,7 +348,7 @@ this returns true, you may reuse the message buffer. If the returned
 communication handle is 0, message buffer can be reused immediately,
 thus saving a call to CmiAsyncMsgSent.
 
-::
+.. code-block:: c++
 
   CmiCommHandle CmiAsyncNodeSend(unsigned int destNode, unsigned int size, void *msg)
 
@@ -358,7 +358,7 @@ this returns true, you may reuse the message buffer. If the returned
 communication handle is 0, message buffer can be reused immediately,
 thus saving a call to CmiAsyncMsgSent.
 
-::
+.. code-block:: c++
 
   void CmiSyncVectorSend(int destPE, int len, int sizes[], char *msgComps[])
 
@@ -369,7 +369,7 @@ contains pointers to the pieces; the size of msgComps[i] is taken from
 sizes[i]. When it returns, sizes, msgComps and the message components
 specified in msgComps can be immediately reused.
 
-::
+.. code-block:: c++
 
   void CmiSyncVectorSendAndFree(int destPE, int len, int sizes[], char *msgComps[])
 
@@ -382,7 +382,7 @@ this function therefore, they should be dynamically allocated using
 CmiAlloc. However, the sizes and msgComps array themselves are not
 freed.
 
-::
+.. code-block:: c++
 
   CmiCommHandle CmiAsyncVectorSend(int destPE, int len, int sizes[], char *msgComps[])
 
@@ -398,21 +398,21 @@ parameters can be reused. If the returned communication handle is 0,
 message buffer can be reused immediately, thus saving a call to
 CmiAsyncMsgSent.
 
-::
+.. code-block:: c++
 
   int CmiAsyncMsgSent(CmiCommHandle handle)
 
 Returns true if the communication specified by the given CmiCommHandle
 has proceeded to the point where the message buffer can be reused.
 
-::
+.. code-block:: c++
 
   void CmiReleaseCommHandle(CmiCommHandle handle)
 
 Releases the communication handle handle and associated resources. It
 does not free the message buffer.
 
-::
+.. code-block:: c++
 
   void CmiMultipleSend(unsigned int destPE, int len, int sizes[], char *msgComps[])
 
@@ -434,21 +434,21 @@ will not be able to provide the service to the user.)
 
 Broadcasting Messages
 ---------------------
-::
+.. code-block:: c++
 
   void CmiSyncBroadcast(unsigned int size, void *msg)
 
 Sends msg of length size bytes to all processors excluding the processor
 on which the caller resides.
 
-::
+.. code-block:: c++
 
   void CmiSyncNodeBroadcast(unsigned int size, void *msg)
 
 Sends msg of length size bytes to all nodes excluding the node on which
 the caller resides.
 
-::
+.. code-block:: c++
 
   void CmiSyncBroadcastAndFree(unsigned int size, void *msg)
 
@@ -457,7 +457,7 @@ on which the caller resides. Uses CmiFree to deallocate the message
 buffer for msg when the broadcast completes. Therefore msg must point to
 a buffer allocated with CmiAlloc.
 
-::
+.. code-block:: c++
 
   void CmiSyncNodeBroadcastAndFree(unsigned int size, void *msg)
 
@@ -466,7 +466,7 @@ the caller resides. Uses CmiFree to deallocate the message buffer for
 msg when the broadcast completes. Therefore msg must point to a buffer
 allocated with CmiAlloc.
 
-::
+.. code-block:: c++
 
   void CmiSyncBroadcastAll(unsigned int size, void *msg)
 
@@ -474,7 +474,7 @@ Sends msg of length size bytes to all processors including the processor
 on which the caller resides. This function does not free the message
 buffer for msg.
 
-::
+.. code-block:: c++
 
   void CmiSyncNodeBroadcastAll(unsigned int size, void *msg)
 
@@ -482,7 +482,7 @@ Sends msg of length size bytes to all nodes including the node on which
 the caller resides. This function does not free the message buffer for
 msg.
 
-::
+.. code-block:: c++
 
   void CmiSyncBroadcastAllAndFree(unsigned int size, void *msg)
 
@@ -491,7 +491,7 @@ on which the caller resides. This function frees the message buffer for
 msg before returning, so msg must point to a dynamically allocated
 buffer.
 
-::
+.. code-block:: c++
 
   void CmiSyncNodeBroadcastAllAndFree(unsigned int size, void *msg)
 
@@ -499,7 +499,7 @@ Sends msg of length size bytes to all nodes including the node on which
 the caller resides. This function frees the message buffer for msg
 before returning, so msg must point to a dynamically allocated buffer.
 
-::
+.. code-block:: c++
 
   CmiCommHandle CmiAsyncBroadcast(unsigned int size, void *msg)
 
@@ -511,7 +511,7 @@ is 0, message buffer can be reused immediately, thus saving a call to
 CmiAsyncMsgSent. msg should not be overwritten or freed before the
 communication is complete.
 
-::
+.. code-block:: c++
 
   CmiCommHandle CmiAsyncNodeBroadcast(unsigned int size, void *msg)
 
@@ -523,7 +523,7 @@ message buffer can be reused immediately, thus saving a call to
 CmiAsyncMsgSent. msg should not be overwritten or freed before the
 communication is complete.
 
-::
+.. code-block:: c++
 
   CmiCommHandle CmiAsyncBroadcastAll(unsigned int size, void *msg)
 
@@ -535,7 +535,7 @@ is 0, message buffer can be reused immediately, thus saving a call to
 CmiAsyncMsgSent. msg should not be overwritten or freed before the
 communication is complete.
 
-::
+.. code-block:: c++
 
   CmiCommHandle CmiAsyncNodeBroadcastAll(unsigned int size, void *msg)
 
@@ -552,14 +552,14 @@ communication is complete.
 Multicasting Messages
 ---------------------
 
-::
+.. code-block:: c++
 
   typedef ... CmiGroup;
 
 A CmiGroup represents a set of processors. It is an opaque type. Group
 IDs are useful for the multicast functions below.
 
-::
+.. code-block:: c++
 
   CmiGroup CmiEstablishGroup(int npes, int *pes);
 
@@ -569,14 +569,14 @@ some resources. In particular, establishing a group uses some network
 bandwidth (one broadcast’s worth) and a small amount of memory on all
 processors.
 
-::
+.. code-block:: c++
 
   void CmiSyncMulticast(CmiGroup grp, unsigned int size, void *msg)
 
 Sends msg of length size bytes to all members of the specified group.
 Group IDs are created using CmiEstablishGroup.
 
-::
+.. code-block:: c++
 
   void CmiSyncMulticastAndFree(CmiGroup grp, unsigned int size, void *msg)
 
@@ -585,7 +585,7 @@ Uses CmiFree to deallocate the message buffer for msg when the broadcast
 completes. Therefore msg must point to a buffer allocated with CmiAlloc.
 Group IDs are created using CmiEstablishGroup.
 
-::
+.. code-block:: c++
 
   CmiCommHandle CmiAsyncMulticast(CmiGroup grp, unsigned int size, void *msg)
 
@@ -598,13 +598,13 @@ CmiAsyncMsgSent. msg should not be overwritten or freed before the
 communication is complete. Group IDs are created using
 CmiEstablishGroup.
 
-::
+.. code-block:: c++
 
   void CmiSyncListSend(int npes, int *pes, unsigned int size, void *msg)
 
 Sends msg of length size bytes to npes processors in the array pes.
 
-::
+.. code-block:: c++
 
   void CmiSyncListSendAndFree(int npes, int *pes, unsigned int size, void *msg)
 
@@ -613,7 +613,7 @@ CmiFree to deallocate the message buffer for msg when the multicast
 completes. Therefore, msg must point to a buffer allocated with
 CmiAlloc.
 
-::
+.. code-block:: c++
 
   CmiCommHandle CmiAsyncListSend(int npes, int *pes, unsigned int size, void *msg)
 
@@ -661,7 +661,7 @@ expanded by adding more nodes.
 The signatures for the functions in
 Table :numref:`table:reductions` are:
 
-::
+.. code-block:: c++
 
   void CmiReduce(void *msg, int size, CmiReduceMergeFn mergeFn);
 
@@ -696,7 +696,7 @@ explicitly passed in “Struct” functions only, since for the message
 versions it is taken from the header of msg. Moreover there are several
 other function pointers passed in by the user:
 
-::
+.. code-block:: c++
 
   void * (*mergeFn)(int *size, void *local, void **remote, int count)
 
@@ -722,7 +722,7 @@ allocated. Each element in remote is the complete incoming message
 it has been packed by the pup function (without any additional header)
 for struct reductions.
 
-::
+.. code-block:: c++
 
   void (*pupFn)(pup_er p, void *data)
 
@@ -734,7 +734,7 @@ The data can be either the same data passed in as first parameter of any
 called for sizing and packing. (Note: It will not be called for
 unpacking.)
 
-::
+.. code-block:: c++
 
   void (*deleteFn)(void *ptr)
 
@@ -766,7 +766,7 @@ CmiReductionID. It is up to the user to guarantee this.)
 A CmiReductionID can be obtained by the user in three ways, using one of
 the following functions:
 
-::
+.. code-block:: c++
 
   CmiReductionID CmiGetGlobalReduction()
 
@@ -775,7 +775,7 @@ every processor, and in the same order if called multiple times. This
 would generally be inside initialization code, that can set aside some
 CmiReductionIDs for later use.
 
-::
+.. code-block:: c++
 
   CmiReductionID CmiGetDynamicReduction()
 
@@ -783,7 +783,7 @@ This function may be called only
 on processor zero. It returns a unique ID, and it is up to the user to
 distribute this ID to any processor that needs it.
 
-::
+.. code-block:: c++
 
   void CmiGetDynamicReductionRemote(int handlerIdx, int pe, int dataSize, void *data)
 
@@ -869,7 +869,7 @@ views scheduler’s queue as a single prioritized queue that includes
 messages directed at that processor and messages from the node-level
 queue sorted according to priorities.
 
-::
+.. code-block:: c++
 
   void CsdEnqueueGeneral(void *Message, int strategy, int priobits, int *prioptr)
 
@@ -878,7 +878,7 @@ sorted according to its priority and the queueing ``strategy``. The
 meaning of the priobits and prioptr fields depend on the value of
 strategy, which are explained below.
 
-::
+.. code-block:: c++
 
   void CsdNodeEnqueueGeneral(void *Message, int strategy, int priobits, int *prioptr)
 
@@ -926,86 +926,86 @@ emerged from the scheduler’s queue. It is normal to actually store the
 priority *in the message itself*, though it is up to the user to
 actually arrange storage for the priority.
 
-::
+.. code-block:: c++
 
   void CsdEnqueue(void *Message)
 
 This macro is a shorthand for
 
-::
+.. code-block:: c++
 
    CsdEnqueueGeneral(Message, CQS_QUEUEING_FIFO,0, NULL)
 
 provided here for backward compatibility.
 
-::
+.. code-block:: c++
 
   void CsdNodeEnqueue(void *Message)
 
 This macro is a shorthand for
 
-::
+.. code-block:: c++
 
    CsdNodeEnqueueGeneral(Message, CQS_QUEUEING_FIFO,0, NULL)
 
 provided here for backward compatibility.
 
-::
+.. code-block:: c++
 
   void CsdEnqueueFifo(void *Message)
 
 This macro is a shorthand for
 
-::
+.. code-block:: c++
 
    CsdEnqueueGeneral(Message, CQS_QUEUEING_FIFO,0, NULL)
 
 provided here for backward compatibility.
 
-::
+.. code-block:: c++
 
   void CsdNodeEnqueueFifo(void *Message)
 
 This macro is a shorthand for
 
-::
+.. code-block:: c++
 
    CsdNodeEnqueueGeneral(Message, CQS_QUEUEING_FIFO,0, NULL)
 
 provided here for backward compatibility.
 
-::
+.. code-block:: c++
 
   void CsdEnqueueLifo(void *Message)
 
 This macro is a shorthand for
 
-::
+.. code-block:: c++
 
    CsdEnqueueGeneral(Message, CQS_QUEUEING_LIFO,0, NULL)
 
 provided here for backward compatibility.
 
-::
+.. code-block:: c++
 
   void CsdNodeEnqueueLifo(void *Message)
 
 This macro is a shorthand for
 
-::
+.. code-block:: c++
 
    CsdNodeEnqueueGeneral(Message, CQS_QUEUEING_LIFO,0, NULL)
 
 provided here for backward compatibility.
 
-::
+.. code-block:: c++
 
   int CsdEmpty()
 
 This function returns non-zero integer when the scheduler’s
 processor-level queue is empty, zero otherwise.
 
-::
+.. code-block:: c++
 
   int CsdNodeEmpty()
 
@@ -1038,7 +1038,7 @@ In each iteration, a scheduler first looks for any message that has
 arrived from another processor, and delivers it. If there isn’t any, it
 selects a message from the locally enqueued messages, and delivers it.
 
-::
+.. code-block:: c++
 
   void CsdScheduleForever(void)
 
@@ -1046,7 +1046,7 @@ Extract and deliver messages until the
 scheduler is stopped. Raises the idle handling converse signals. This is
 the scheduler to use in most Converse programs.
 
-::
+.. code-block:: c++
 
   int CsdScheduleCount(int n)
 
@@ -1055,7 +1055,7 @@ messages have been delivered, then return 0. If the scheduler is stopped
 early, return :math:`n` minus the number of messages delivered so far.
 Raises the idle handling converse signals.
 
-::
+.. code-block:: c++
 
   void CsdSchedulePoll(void)
 
@@ -1063,7 +1063,7 @@ Extract and deliver messages until no more
 messages are available, then return. This is useful for running
 non-networking code when the networking code has nothing to do.
 
-::
+.. code-block:: c++
 
   void CsdScheduler(int n)
 
@@ -1071,7 +1071,7 @@ If :math:`n` is zero, call CsdSchedulePoll. If :math:`n` is negative,
 call CsdScheduleForever. If :math:`n` is positive, call
 CsdScheduleCount(\ :math:`n`).
 
-::
+.. code-block:: c++
 
   int CmiDeliverMsgs(int MaxMsgs)
 
@@ -1082,7 +1082,7 @@ MaxMsgs messages have been retrieved and their handlers called. It
 returns the difference between total messages delivered and MaxMsgs. The
 handler is given a pointer to the message as its parameter.
 
-::
+.. code-block:: c++
 
   void CmiDeliverSpecificMsg(int HandlerId)
 
@@ -1091,7 +1091,7 @@ with its handler field equal to HandlerId. This functions leaves alone
 all other messages. It returns after the invoked handler function
 returns.
 
-::
+.. code-block:: c++
 
   void CsdExitScheduler(void)
 
@@ -1102,7 +1102,7 @@ routine.
 The Timer
 ---------
 
-::
+.. code-block:: c++
 
   double CmiTimer(void)
 
@@ -1114,14 +1114,14 @@ microsecond accuracy.
 Processor Ids
 -------------
 
-::
+.. code-block:: c++
 
   int CmiNumPe(void)
 
 Returns the total number of processors on which the parallel program is
 being run.
 
-::
+.. code-block:: c++
 
   int CmiMyPe(void)
 
@@ -1186,7 +1186,7 @@ of portability.
 
 Macros for node-shared variables:
 
-::
+.. code-block:: c++
 
   CsvDeclare(type,variable)
 
@@ -1200,7 +1200,7 @@ Macros for node-shared variables:
 
 Macros for PE-private variables:
 
-::
+.. code-block:: c++
 
   CpvDeclare(type,variable)
 
@@ -1214,7 +1214,7 @@ Macros for PE-private variables:
 
 Macros for thread-private variables:
 
-::
+.. code-block:: c++
 
   CtvDeclare(type,variable)
 
@@ -1242,7 +1242,7 @@ provide a module-init function for each file (in the sample code -
 called at the beginning of execution to complete the installations of
 all global variables.
 
-::
+.. code-block:: c++
 
    File: Module1.c
 
@@ -1280,39 +1280,39 @@ machines, Converse provides the following functions and/or macros.
 shared-memory machines also, and have the effect of only one processor
 per node and only one thread per processor.)
 
-::
+.. code-block:: c++
 
   int CmiMyNode()
 
 Returns the node number to which the calling processor belongs.
 
-::
+.. code-block:: c++
 
   int CmiNumNodes()
 
 Returns number of nodes in the system. Note that this is not the same as
 ``CmiNumPes()``.
 
-::
+.. code-block:: c++
 
   int CmiMyRank()
 
 Returns the rank of the calling processor within a shared memory node.
 
-::
+.. code-block:: c++
 
   int CmiNodeFirst(int node)
 
 Returns the processor number of the lowest ranked processor on node
 ``node``
 
-::
+.. code-block:: c++
 
   int CmiNodeSize(int node)
 
 Returns the number of processors that belong to the node ``node``.
 
-::
+.. code-block:: c++
 
   int CmiNodeOf(int pe)
 
@@ -1320,7 +1320,7 @@ Returns the node number to which processor ``pe`` belongs. Indeed,
 ``CmiMyNode()`` is a utility macro that is aliased to
 ``CmiNodeOf(CmiMyPe())``.
 
-::
+.. code-block:: c++
 
   int CmiRankOf(int pe)
 
@@ -1331,48 +1331,48 @@ Returns the rank of processor ``pe`` in the node to which it belongs.
 Node-level Locks and other Synchronization Mechanisms
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-::
+.. code-block:: c++
 
   void CmiNodeBarrier()
 
 Provide barrier synchronization at the node level, i.e. all the
 processors belonging to the node participate in this barrier.
 
-::
+.. code-block:: c++
 
   typedef McDependentType CmiNodeLock
 
 This is the type for all the node-level locks in Converse.
 
-::
+.. code-block:: c++
 
   CmiNodeLock CmiCreateLock(void)
 
 Creates, initializes and returns a new lock. Initially the lock is
 unlocked.
 
-::
+.. code-block:: c++
 
   void CmiLock(CmiNodeLock lock)
 
 Locks ``lock``. If the ``lock`` has been locked by other processor,
 waits for ``lock`` to be unlocked.
 
-::
+.. code-block:: c++
 
   void CmiUnlock(CmiNodeLock lock)
 
 Unlocks ``lock``. Processors waiting for the ``lock`` can then compete
 for acquiring ``lock``.
 
-::
+.. code-block:: c++
 
   int CmiTryLock(CmiNodeLock lock)
 
 Tries to lock ``lock``. If it succeeds in locking, it returns 0. If any
 other processor has already acquired the lock, it returns 1.
 
-::
+.. code-block:: c++
 
   voi CmiDestroyLock(CmiNodeLock lock)
 
@@ -1382,7 +1382,7 @@ operations with ``lock`` after a call to this function.
 Input/Output
 ------------
 
-::
+.. code-block:: c++
 
   void CmiPrintf(char *format, arg1, arg2, ...)
 
@@ -1390,7 +1390,7 @@ This function does an atomic ``printf()`` on ``stdout``. On machine with
 host, this is implemented on top of the messaging layer using
 asynchronous sends.
 
-::
+.. code-block:: c++
 
   int CmiScanf(char *format, void *arg1, void *arg2, ...)
 
@@ -1399,7 +1399,7 @@ processor, on which the caller resides, blocks for input. On machines
 with host, this is implemented on top of the messaging layer using
 asynchronous send and blocking receive.
 
-::
+.. code-block:: c++
 
   void CmiError(char *format, arg1, arg2, ...)
 
@@ -1419,40 +1419,40 @@ performance. The root of the spanning tree (processor based or
 node-based) is always 0, thus the CmiSpanTreeRoot call has been
 eliminated.
 
-::
+.. code-block:: c++
 
   int CmiSpanTreeParent(int procNum)
 
 This function returns the processor number of the parent of procNum in
 the spanning tree.
 
-::
+.. code-block:: c++
 
   int CmiNumSpanTreeChildren(int procNum)
 
 Returns the number of children of procNum in the spanning tree.
 
-::
+.. code-block:: c++
 
   void CmiSpanTreeChildren(int procNum, int *children)
 
 This function fills the array children with processor numbers of
 children of procNum in the spanning tree.
 
-::
+.. code-block:: c++
 
   int CmiNodeSpanTreeParent(int nodeNum)
 
 This function returns the node number of the parent of nodeNum in the
 spanning tree.
 
-::
+.. code-block:: c++
 
   int CmiNumNodeSpanTreeChildren(int nodeNum)
 
 Returns the number of children of nodeNum in the spanning tree.
 
-::
+.. code-block:: c++
 
   void CmiNodeSpanTreeChildren(int nodeNum, int *children)
 
@@ -1479,7 +1479,7 @@ the correct locations, even on a new processor. This is especially
 useful when the format of the data structure is complex or unknown, as
 with thread stacks.
 
-::
+.. code-block:: c++
 
   void *CmiIsomalloc(int size)
 
@@ -1489,7 +1489,7 @@ the allocated region.
 CmiIsomalloc makes allocations with page granularity (typically several
 kilobytes); so it is not recommended for small allocations.
 
-::
+.. code-block:: c++
 
   void CmiIsomallocFree(void *doomedBlock)
 
@@ -1501,7 +1501,7 @@ After a CmiIsomallocFree, references to that block will likely result in
 a segmentation violation. It is illegal to call CmiIsomallocFree more
 than once on the same block.
 
-::
+.. code-block:: c++
 
   void CmiIsomallocPup(pup_er p,void **block)
 
@@ -1515,13 +1515,13 @@ Note- Use of this function to pup individual blocks is not supported any
 longer. All the blocks allocated via CmiIsomalloc are pupped by the RTS
 as one single unit.
 
-::
+.. code-block:: c++
 
   int CmiIsomallocLength(void *block);
 
 Return the length, in bytes, of this isomalloc’d block.
 
-::
+.. code-block:: c++
 
   int CmiIsomallocInRange(void *address)
 
@@ -1543,7 +1543,7 @@ own thread schedulers.
 Basic Thread Calls
 ------------------
 
-::
+.. code-block:: c++
 
   typedef struct CthThreadStruct *CthThread;
 
@@ -1551,21 +1551,21 @@ This is an opaque type defined in ``converse.h``. It represents a
 first-class thread object. No information is publicized about the
 contents of a CthThreadStruct.
 
-::
+.. code-block:: c++
 
   typedef void (CthVoidFn)(void *);
 
 This is a type defined in ``converse.h``. It represents a function that
 returns nothing.
 
-::
+.. code-block:: c++
 
   typedef CthThread (CthThFn)(void);
 
 This is a type defined in ``converse.h``. It represents a function that
 returns a CthThread.
 
-::
+.. code-block:: c++
 
   CthThread CthSelf()
 
@@ -1574,7 +1574,7 @@ control that inherently existed when the program began executing
 ``main`` counts as a thread. You may retrieve that thread object using
 ``CthSelf`` and use it like any other.
 
-::
+.. code-block:: c++
 
   CthThread CthCreate(CthVoidFn fn, void *arg, int size)
 
@@ -1590,7 +1590,7 @@ thread of control that came into existence when your program was first
 (say, by calling ``CthSelf`` in ``main``), and it can be used like any
 other ``CthThread``.
 
-::
+.. code-block:: c++
 
   CthThread CthCreateMigratable(CthVoidFn fn, void *arg, int size)
 
@@ -1601,7 +1601,7 @@ This is only a hint to the runtime system; some threads implementations
 cannot migrate threads, others always create migratable threads. In
 these cases, CthCreateMigratable is equivalent to CthCreate.
 
-::
+.. code-block:: c++
 
   CthThread CthPup(pup_er p,CthThread t)
 
@@ -1611,7 +1611,7 @@ a thread between processors, or checkpoint the state of a thread.
 Only a suspended thread can be Pup’d. Only a thread created with
 CthCreateMigratable can be Pup’d.
 
-::
+.. code-block:: c++
 
   void CthFree(CthThread t)
 
@@ -1621,7 +1621,7 @@ actually be postponed until the thread suspends. To terminate itself, a
 thread calls ``CthFree(CthSelf())``, then gives up control to another
 thread.
 
-::
+.. code-block:: c++
 
   void CthSuspend()
 
@@ -1630,14 +1630,14 @@ not start executing again until somebody pushes it into the scheduler
 queue again, using CthAwaken below. Control transfers to the next task
 in the scheduler queue.
 
-::
+.. code-block:: c++
 
   void CthAwaken(CthThread t)
 
 Pushes a thread into the scheduler queue. Caution: a thread must only be
 in the queue once. Pushing it in twice is a crashable error.
 
-::
+.. code-block:: c++
 
   void CthAwakenPrio(CthThread t, int strategy, int priobits, int *prio)
 
@@ -1647,7 +1647,7 @@ thread must only be in the queue once. Pushing it in twice is a
 crashable error. ``prio`` is not copied internally, and is used when the
 scheduler dequeues the message, so it should not be reused until then.
 
-::
+.. code-block:: c++
 
   void CthYield()
 
@@ -1655,7 +1655,7 @@ This function is part of the scheduler-interface. It simply executes
 ``{ CthAwaken(CthSelf()); CthSuspend(); }``. This combination gives up
 control temporarily, but ensures that control will eventually return.
 
-::
+.. code-block:: c++
 
   void CthYieldPrio(int strategy, int priobits, int *prio)
 
@@ -1664,7 +1664,7 @@ This function is part of the scheduler-interface. It simply executes
 This combination gives up control temporarily, but ensures that control
 will eventually return.
 
-::
+.. code-block:: c++
 
   CthThread CthGetNext(CthThread t)
 
@@ -1675,7 +1675,7 @@ variables, and other synchronization abstractions to link threads
 together into queues. This function returns the contents of the next
 field.
 
-::
+.. code-block:: c++
 
   void CthSetNext(CthThread t, CthThread next)
 
@@ -1730,7 +1730,7 @@ To achieve this, you must first implement a new kind of ready-queue. You
 must implement a function that inserts threads into this queue. The
 function must have this prototype:
 
-::
+.. code-block:: c++
 
   void awakenfn(CthThread t, int strategy, int priobits, int *prio);
 
@@ -1739,7 +1739,7 @@ to. You must implement a function that makes the decision: which thread
 should the current thread transfer to. This function must have this
 prototype:
 
-::
+.. code-block:: c++
 
   CthThread choosefn();
 
@@ -1750,7 +1750,7 @@ scheduling thread.
 You then configure individual threads to actually use this new
 ready-queue. This is done using CthSetStrategy:
 
-::
+.. code-block:: c++
 
   void CthSetStrategy(CthThread t, CthAwkFn awakenfn, CthThFn choosefn)
 
@@ -1769,7 +1769,7 @@ will cause it to transfer control to a thread chosen by your
 You may reset a thread to its normal behavior using
 CthSetStrategyDefault:
 
-::
+.. code-block:: c++
 
   void CthSetStrategyDefault(CthThread t)
 
@@ -1784,7 +1784,7 @@ sure that control gets transferred to everywhere it needs to go.
 
 Scheduling threads may need to use this function as well:
 
-::
+.. code-block:: c++
 
   void CthResume(CthThread t)
 
@@ -1892,7 +1892,7 @@ CcdUSER
 CcdUSERMAX
    All conditions from CcdUSER to CcdUSERMAX (inclusive) are available.
 
-::
+.. code-block:: c++
 
    int CcdCallOnCondition(int condnum, CcdVoidFn fnp, void* arg)
 
@@ -1903,7 +1903,7 @@ functions may be registered for the same condition number.
 ``CcdVoidFn`` is a function pointer with the signature ``void fnp(void
 *userParam, double curWallTime)``
 
-::
+.. code-block:: c++
 
   int CcdCallOnConditionKeep(int condnum, CcdVoidFn fnp, void* arg)
 
@@ -1911,7 +1911,7 @@ As above, but the association is permanent- the given function will
 be called again whenever this condition is raised.
 Returns an index that may be used to cancel the association later.
 
-::
+.. code-block:: c++
 
   void CcdCancelCallOnCondition(int condnum, int idx)
 
@@ -1922,7 +1922,7 @@ corresponding function will no longer be called when the condition is
 raised. Note that it is illegal to call these two functions to cancel
 callbacks from within ccd callbacks.
 
-::
+.. code-block:: c++
 
   void CcdRaiseCondition(int condNum)
 
@@ -1931,7 +1931,7 @@ When this function is called, it invokes all the functions whose
 pointers were registered for the ``condNum`` via a *prior* call to
 ``CcdCallOnCondition`` or ``CcdCallOnConditionKeep``.
 
-::
+.. code-block:: c++
 
   void CcdCallFnAfter(CcdVoidFn fnp, void* arg, double msLater)
 
@@ -1941,7 +1941,7 @@ function ``fnp`` is actually called the first time the scheduler gets
 control after ``deltaT`` milliseconds have elapsed. The default
 polling resolution for timed callbacks is 5 ms.
 
-::
+.. code-block:: c++
 
   double CcdSetResolution(double newResolution)
 
@@ -1956,7 +1956,7 @@ critical path of an application. This function also returns the old
 resolution in seconds in case it needs to be reset to a non-default
 value.
 
-::
+.. code-block:: c++
 
   double CcdResetResolution()
 
@@ -1964,7 +1964,7 @@ This call returns the time based callback polling resolution to its
 default, 5 milliseconds. It returns the previously set resolution in
 seconds.
 
-::
+.. code-block:: c++
 
   double CcdIncreaseResolution(double newResolution)
 
@@ -1998,9 +1998,9 @@ CCS: Starting a Server
 
 A Converse program is started using
 
-::
+.. code-block:: bash
 
-   charmrun pgmname +pN charmrun-opts pgm-opts
+   charmrun pgmname +pN charmrun-opts pgm-opts
 
 charmrun also accepts the CCS options:
 
@@ -2029,19 +2029,19 @@ C interface (files “ccs-client.c” and “ccs-client.h”) and Java interface
 The C routines use the skt_abort error-reporting strategy; see
 “sockRoutines.h” for details. The C client API is:
 
-::
+.. code-block:: c++
 
   void CcsConnect(CcsServer *svr, char *host, int port); Connect to the
 
 given CCS server. svr points to a pre-allocated CcsServer structure.
 
-::
+.. code-block:: c++
 
   void CcsConnectIp(CcsServer *svr, int ip, int port);
 
 As above, but a numeric IP is specified.
 
-::
+.. code-block:: c++
 
   int CcsNumNodes(CcsServer *svr);
 
@@ -2055,7 +2055,7 @@ These functions return information about the parallel
 machine; they are equivalent to the Converse calls CmiNumNodes,
 CmiNumPes, CmiNodeFirst, and CmiNodeSize.
 
-::
+.. code-block:: c++
 
   void CcsSendRequest(CcsServer *svr, char *hdlrID, int pe, unsigned int
   size, const char *msg);
@@ -2064,7 +2064,7 @@ Ask the server to execute the handler hdlrID on
 the given processor. The handler is passed the given data as a message.
 The data may be in any desired format (including binary).
 
-::
+.. code-block:: c++
 
   int CcsSendBroadcastRequest(CcsServer *svr, const char *hdlrID, int
   size, const void *msg);
@@ -2072,7 +2072,7 @@ The data may be in any desired format (including binary).
 As CcsSendRequest, only that the handler hdlrID
 is invoked on all processors.
 
-::
+.. code-block:: c++
 
   int CcsSendMulticastRequest(CcsServer *svr, const char *hdlrID,
   int  npes, int *pes, int size, const void *msg);
@@ -2080,7 +2080,7 @@ is invoked on all processors.
 As CcsSendRequest, only that the handler hdlrID is invoked on the processors
 specified in the array pes (of size npes).
 
-::
+.. code-block:: c++
 
   int CcsRecvResponse(CcsServer *svr, unsigned int maxsize,
   char *recvBuffer, int timeout);
@@ -2089,7 +2089,7 @@ Receive a response to the previous request
 in-place. Timeout gives the number of seconds to wait before returning
 0; otherwise the number of bytes received is returned.
 
-::
+.. code-block:: c++
 
   int CcsRecvResponseMsg(CcsServer *svr, unsigned int *retSize,
   char **newBuf, int timeout);
@@ -2097,13 +2097,13 @@ in-place. Timeout gives the number of seconds to wait before returning
 As above, but receive a variable-length
 response. The returned buffer must be free()’d after use.
 
-::
+.. code-block:: c++
 
   int CcsProbe(CcsServer *svr);
 
 Return 1 if a response is available; otherwise 0.
 
-::
+.. code-block:: c++
 
   void CcsFinalize(CcsServer *svr);
 
@@ -2130,7 +2130,7 @@ returning 0.
 
 The handler registration interface is:
 
-::
+.. code-block:: c++
 
   void CcsUseHandler(char *id, int hdlr);
 
@@ -2145,7 +2145,7 @@ After a handler has been registered to CCS, the user can also setup a
 merging function. This function will be passed in to CmiReduce to
 combine replies to multicast and broadcast requests.
 
-::
+.. code-block:: c++
 
   void CcsSetMergeFn(const char *name, CmiReduceMergeFn newMerge);
 
@@ -2154,7 +2154,7 @@ will be used for CCS request received as broadcast or multicast.
 
 These calls can be used from within a CCS handler:
 
-::
+.. code-block:: c++
 
   int CcsEnabled(void);
 
@@ -2162,21 +2162,21 @@ Return 1 if CCS routines are available (from
 conv-mach.h). This routine does not determine if a CCS server port is
 actually open.
 
-::
+.. code-block:: c++
 
   int CcsIsRemoteRequest(void);
 
 Return 1 if this handler was called via
 CCS; 0 if it was called as the result of a normal Converse message.
 
-::
+.. code-block:: c++
 
   void CcsCallerId(skt_ip_t *pip, unsigned int *pport);
 
 Return the IP address and TCP port number of the CCS client that invoked this method.
 Can only be called from a CCS handler invoked remotely.
 
-::
+.. code-block:: c++
 
   void CcsSendReply(int size, const void *reply);
 
@@ -2184,14 +2184,14 @@ Send the given data back to the client as a reply. Can only be called from a CCS
 invoked remotely. In case of broadcast or multicast CCS requests, the
 handlers in all processors involved must call this function.
 
-::
+.. code-block:: c++
 
   CcsDelayedReply CcsDelayReply(void);
 
 Allows a CCS reply to be delayed until after the handler has completed.
 Returns a token used below.
 
-::
+.. code-block:: c++
 
   void CcsSendDelayedReply(CcsDelayedReply d,int size, const void *reply);
 
@@ -2299,7 +2299,7 @@ The interface provides functions to register(pin) and unregister(unpin)
 memory on the NIC hardware. The emulated version of these operations do
 not do anything.
 
-::
+.. code-block:: c++
 
   int CmiRegisterMemory(void *addr, unsigned int size);
 
@@ -2310,7 +2310,7 @@ making remote DMA operations on this memory possible. This directly
 calls the hardware driver function for registering the memory region and
 is usually an expensive operation, so should be used sparingly.
 
-::
+.. code-block:: c++
 
   int CmiUnRegisterMemory(void *addr, unsigned int size);
 
@@ -2364,7 +2364,7 @@ There are two different sets of RDMA operations
 to create a suitable data structure for this purpose. This is the reason
 this has been kept opaque from the programmer.
 
-::
+.. code-block:: c++
 
   void *CmiPut(unsigned int sourceId, unsigned int targetId, void
   *Saddr, void *Taadr, unsigned int size);
@@ -2374,7 +2374,7 @@ Saddr on the machine specified by sourceId to Taddr on the machine
 specified by targetId. The memory region being RDMA’ed is of length size
 bytes.
 
-::
+.. code-block:: c++
 
   void *CmiGet(unsigned int sourceId, unsigned int targetId, void
   *Saddr, void *Taadr, unsigned int size);
@@ -2382,7 +2382,7 @@ bytes.
 Similar to CmiPut except the direction of the data transfer is opposite;
 from target to source.
 
-::
+.. code-block:: c++
 
   void CmiPutCb(unsigned int sourceId, unsigned int targetId, void
   *Saddr, void *Taddr, unsigned int size, CmiRdmaCallbackFn fn, void
@@ -2391,7 +2391,7 @@ from target to source.
 Similar to CmiPut except a callback is called when the operation
 completes.
 
-::
+.. code-block:: c++
 
   void CmiGetCb(unsigned int sourceId, unsigned int targetId, void
   *Saddr, void *Taddr, unsigned int size, CmiRdmaCallbackFn fn, void
@@ -2410,7 +2410,7 @@ completion. One mechanism is for the programmer to check for completion.
 The other mechanism is through callback functions registered during the
 RDMA operations.
 
-::
+.. code-block:: c++
 
   int CmiWaitTest(void *obj);
 
@@ -2430,7 +2430,7 @@ supplied default stream shared amongst all chares on the processor, or
 creating a private stream. Note that there is a limit on the number of
 private streams, which at the time of writing was 15,613.
 
-::
+.. code-block:: c++
 
   struct CrnStream;
 
@@ -2440,19 +2440,19 @@ user is responsible for allocating the memory for this structure.
 Default Stream Calls
 --------------------
 
-::
+.. code-block:: c++
 
   void CrnSrand(int seed);
 
 Seeds the default random number generator with ``seed``.
 
-::
+.. code-block:: c++
 
   int CrnRand(void);
 
 Returns the next random number in the default stream as an integer.
 
-::
+.. code-block:: c++
 
   int CrnDrand(void);
 
@@ -2461,7 +2461,7 @@ Returns the next random number in the default stream as a double.
 Private Stream Calls
 --------------------
 
-::
+.. code-block:: c++
 
   void CrnInitStream(CrnStream *dest, int seed, int type);
 
@@ -2469,21 +2469,21 @@ Initializes a new stream with its initial state stored in ``dest``. The
 user must supply a seed in ``seed``, as well as the ``type`` of the
 stream, where the ``type`` can be 0, 1, or 2.
 
-::
+.. code-block:: c++
 
   double CrnDouble(CrnStream *genptr);
 
 Returns the next random number in the stream whose state is given by
 ``genptr``; the number is returned as a double.
 
-::
+.. code-block:: c++
 
   double CrnInt(CrnStream *genptr);
 
 Returns the next random number in the stream whose state is given by
 ``genptr``; the number is returned as an integer.
 
-::
+.. code-block:: c++
 
   double CrnFloat(CrnStream *genptr);
 
@@ -2519,7 +2519,7 @@ Create / Destroy Persistent Handler
 The interface provides functions to crate and destroy handler on the
 processor for use of persistent communication.
 
-::
+.. code-block:: c++
 
   Persistenthandle CmiCreatePersistent(int destPE, int maxBytes);
 
@@ -2528,7 +2528,7 @@ and maximum bytes for this persistent communication. Machine layer will
 send message to destPE and setup a persistent communication. A buffer of
 size maxBytes is allocated in the destination PE.
 
-::
+.. code-block:: c++
 
   PersistentReq CmiCreateReceiverPersistent(int maxBytes);
   PersistentHandle CmiRegisterReceivePersistent(PersistentReq req);
@@ -2541,14 +2541,14 @@ should call CmiRegisterReceivePersistent() to setup the persistent
 communication. The function returns a PersistentHandle which can then be
 used for the persistent communication.
 
-::
+.. code-block:: c++
 
   void CmiDestroyPersistent(PersistentHandle h);
 
 This function destroys a persistent communication specified by
 PersistentHandle h.
 
-::
+.. code-block:: c++
 
   void CmiDestroyAllPersistent();
 
@@ -2561,7 +2561,7 @@ Persistent Operation
 This section presents functions that uses persistent handler for
 communications.
 
-::
+.. code-block:: c++
 
   void CmiUsePersistentHandle(PersistentHandle *p, int n)
 
index d304ce7d1d828ea7e9b46357d32c1ce7f2b51585..3779f415627317461e894f2f60ec0afd57db299b 100644 (file)
@@ -165,7 +165,7 @@ you may fire the next batch of tasks via CmsFireTask again.
 Example Program
 ---------------
 
-::
+.. code-block:: c++
 
    #include "cms.h"
 
@@ -319,7 +319,7 @@ Releases memory used by q.
 
 The following Templates are available for use in C++:
 
-::
+.. code-block:: c++
 
    template<class T>
    class CkQ {
@@ -426,20 +426,20 @@ arrives and is handled, the user’s function is called.
 
 For example, if the CPM scanner sees the following function declaration
 
-::
+.. code-block:: c++
 
        CpmInvokable myfunc(int x, int y) { ... }
 
 The scanner will generate a launcher named ``Cpm_myfunc``. The launcher
 has this prototype:
 
-::
+.. code-block:: c++
 
        void Cpm_myfunc(CpmDestination destination, int x, int y);
 
 If one were to call ``Cpm_myfunc`` as follows:
 
-::
+.. code-block:: c++
 
        Cpm_myfunc(CpmSend(3), 8, 9);
 
@@ -558,7 +558,7 @@ All the functions shown above accept processor numbers as arguments.
 Instead of supplying a processor number, one can also supply the special
 symbols CPM_ALL or CPM_OTHERS, causing a broadcast. For example,
 
-::
+.. code-block:: c++
 
    Cpm_print_integer(CpmMakeThread(CPM_ALL), 5);
 
@@ -574,7 +574,7 @@ argument lists. In particular, the argument list of a CpmInvokable
 function can only contain cpm-single-arguments and cpm-array-arguments,
 as defined by this grammar:
 
-::
+.. code-block:: c++
 
        cpm-single-argument :== typeword varname
        cpm-array-argument  :== typeword '*' varname
@@ -623,7 +623,7 @@ A second program, ``example2.c``, uses array arguments:
 The word ``CpmStr`` is a CPM built-in type, it represents a
 null-terminated string:
 
-::
+.. code-block:: c++
 
        typedef char *CpmStr;
 
@@ -647,7 +647,7 @@ types.
 
 CPM knows which type is which only through the following declarations:
 
-::
+.. code-block:: c++
 
        CpmDeclareSimple(typeword);
        CpmDeclarePointer(typeword);
@@ -800,7 +800,7 @@ We now show an example CPM command, and describe the steps that are
 taken when the command is executed. The command we will consider is this
 one:
 
-::
+.. code-block:: c++
 
    Cpm_print_integer(CpmEnqueueFIFO(3), 12);
 
@@ -810,7 +810,7 @@ Which sends a message to processor 3, ordering it to call
 The first step is taken by CpmEnqueueFIFO, which builds the
 CpmDestination. The following is the code for CpmEnqueueFIFO:
 
-::
+.. code-block:: c++
 
    typedef struct CpmDestinationSend_s
    {
@@ -855,7 +855,7 @@ normally taken by a launcher:
 
 The code for the send-function is here:
 
-::
+.. code-block:: c++
 
    void *CpmEnqueueFIFO1(CpmDestinationSend dest, int len, void *msg)
    {
@@ -882,7 +882,7 @@ handler will be called. The result will be that ``CpmEnqueueFIFO2`` will
 be called on the destination processor. Here is the code for
 ``CpmEnqueueFIFO2``:
 
-::
+.. code-block:: c++
 
    void CpmEnqueueFIFO2(void *msg)
    {
@@ -917,13 +917,13 @@ This pointer must be coerced to type CpmDestination.
 
 The send-function must have the following prototype:
 
-::
+.. code-block:: c++
 
        void sendfunction(CpmDestination dest, int msglen, void *msgptr)
 
 It can access the envelope of the message using CpmEnv:
 
-::
+.. code-block:: c++
 
        int *CpmEnv(void *msg);
 
@@ -1057,7 +1057,7 @@ use of the load balancers.
 
 ``hello.c:``
 
-::
+.. code-block:: c++
 
    #include <stdio.h>
    #include "converse.h"
@@ -1183,7 +1183,7 @@ Minimal Requirements
 The minimal requirements for a load balancer are illustrated by the
 following code.
 
-::
+.. code-block:: c++
 
    #include <stdio.h>
    #include "converse.h"
@@ -1278,7 +1278,7 @@ components of) the message ``msg``.
 Thus, an implementation of the **CldEnqueue** function might have the
 following structure:
 
-::
+.. code-block:: c++
 
    void CldEnqueue(int pe, void *msg, int infofn)
    {
@@ -1307,7 +1307,7 @@ Thus, to use the info function, we need to get the actual function via
 the handler index provided to **CldEnqueue**. Typically,
 **CldEnqueue** would contain the following declarations:
 
-::
+.. code-block:: c++
 
      int len, queueing, priobits;
      unsigned int *prioptr;
@@ -1316,7 +1316,7 @@ the handler index provided to **CldEnqueue**. Typically,
 
 Subsequently, a call to ``ifn`` would look like this:
 
-::
+.. code-block:: c++
 
      ifn(msg, &pfn, &len, &queueing, &priobits, &prioptr);
 
@@ -1325,7 +1325,7 @@ queuing strategy and priority, and also a pack function, which will be
 used when we need to send the message elsewhere. For now, consider the
 case where the message is to be locally enqueued:
 
-::
+.. code-block:: c++
 
      ...
      else if (pe == CmiMyPe())
@@ -1344,7 +1344,7 @@ that it has room for extra handler information and a reference to the
 info function. Therefore, before we handle the last three cases of
 **CldEnqueue**, we have a little extra work to do:
 
-::
+.. code-block:: c++
 
      ...
      else
@@ -1371,7 +1371,7 @@ values may have changed in the packing process.
 
 Finally, we handle our last few cases:
 
-::
+.. code-block:: c++
 
      ...
          if (pe==CLD_BROADCAST)
@@ -1385,7 +1385,7 @@ Finally, we handle our last few cases:
 The above example also provides **CldHandler** which is used to receive
 messages that **CldEnqueue** forwards to other processors.
 
-::
+.. code-block:: c++
 
    CpvDeclare(int, CldHandlerIndex);
 
@@ -1409,7 +1409,7 @@ this more below.
 Finally, Converse initialization functions call **CldModuleInit** to
 initialize the load balancer module.
 
-::
+.. code-block:: c++
 
    void CldModuleInit()
    {
@@ -1431,7 +1431,7 @@ tokens of messages in a processor’s scheduler in a way that they can be
 removed and relocated to a different processor at any time. The
 interface for this module is as follows:
 
-::
+.. code-block:: c++
 
    void CldSwitchHandler(char *cmsg, int handler)
    void CldRestoreHandler(char *cmsg)
@@ -1464,7 +1464,7 @@ module. It is typically called from the load balancer’s
 
 The helper module also provides the following functions:
 
-::
+.. code-block:: c++
 
    void CldMultipleSend(int pe, int numToSend)
    int CldRegisterInfoFn(CldInfoFn fn)
@@ -1483,7 +1483,7 @@ You may want to use the three status variables. These can be used to
 keep track of what your LB is doing (see usage in cldb.neighbor.c and
 itc++queens program).
 
-::
+.. code-block:: c++
 
    CpvDeclare(int, CldRelocatedMessages);
    CpvDeclare(int, CldLoadBalanceMessages);
@@ -1526,7 +1526,7 @@ This means that messages can later be removed for relocation.
 **CldPutToken** adds the message to the token queue on the local
 processor.
 
-::
+.. code-block:: c++
 
    #include <stdio.h>
    #include "converse.h"
@@ -1738,7 +1738,7 @@ interchangeable with their pthread equivalents. In addition, you may
 prevent Converse from defining the pthread names at all with the
 preprocessor symbol SUPPRESS_PTHREADS:
 
-::
+.. code-block:: c++
 
    #define SUPPRESS_PTHREADS
    #include <cpthreads.h>
@@ -1788,7 +1788,7 @@ procedure, create a POSIX thread to run ``mymain``. We provide a
 convenience function to do this, called Cpthreads_start_main. The
 startup code will be much like this:
 
-::
+.. code-block:: c++
 
    void mystartup(int argc, char **argv)
    {
@@ -1906,7 +1906,7 @@ by a context-free grammar:
 
 Where:
 
-::
+.. code-block:: none
 
        dest-clause :== CPATH_DEST ',' pathptr ',' index ',' index ',' ...
        tag-clause  :== CPATH_TAG ',' tag
@@ -1970,7 +1970,7 @@ dest-clause, end-clause)``
 
 Where:
 
-::
+.. code-block:: none
 
        over-clause :== CPATH_OVER ',' pathptr ',' index ',' index ',' ...
        dest-clause :== CPATH_DEST ',' pathptr ',' index ',' index ',' ...
index d8b6d652c3afec4e7eaaa5e488fa89b2d589e3c0..ea15c2f237f27ff692651edd92568296d009c42d 100644 (file)
@@ -474,7 +474,7 @@ debugging support in charm.
 The code below shows a simple class declaration that includes a ``pup``
 method.
 
-::
+.. code-block:: c++
 
      class foo {
       private:
index 67da9124147c2f104062fb9f8dcb7dbf41ef27da..9e7797603e7b45b7fd00b817de71e1533ce71c64 100644 (file)
@@ -35,22 +35,22 @@ example:
 
 .. code-block:: fortran
 
-         ! ## Just replace Hello throughout with your chare's name. ##
-         ! ## and add your chare's personal data below where indicated ##
-         ! ## Everything else remains the same ##
-         MODULE HelloMod
+   ! ## Just replace Hello throughout with your chare's name. ##
+   ! ## and add your chare's personal data below where indicated ##
+   ! ## Everything else remains the same ##
+   MODULE HelloMod
 
-         TYPE Hello
-         ! ## your chare's data goes here, the integer below is an example ##
-         integer data
-         END TYPE
+   TYPE Hello
+   ! ## your chare's data goes here, the integer below is an example ##
+   integer data
+   END TYPE
 
-         TYPE HelloPtr
-         TYPE (Hello), POINTER :: obj
-         integer*8 aid
-         END TYPE
+   TYPE HelloPtr
+   TYPE (Hello), POINTER :: obj
+   integer*8 aid
+   END TYPE
 
-         END MODULE
+   END MODULE
 
 You can think of this module as a Chare declaration. Type [Hello]
 defines arbitrary user program data and HelloPtr defines the Chare
@@ -129,7 +129,7 @@ task to write a short C++ file including these two headers files. You
 should also provide definitions for readonly variables in this C++ file.
 It can be as simple as this:
 
-::
+.. code-block:: c++
 
    #include "hello.decl.h"
    int chunkSize;  // define readonly variables here
@@ -145,7 +145,7 @@ functions that the translator generates:
 
 Take the readonly variable chunkSize as an example:
 
-::
+.. code-block:: c++
 
    Set_Chunksize(chunkSize);
    Get_Chunksize(chunkSize);
@@ -157,7 +157,7 @@ Third, for the user’s convenience, several Charm++ runtime library functions
 have their Fortran interface defined in the F90Charm library. These
 currently include:
 
-::
+.. code-block:: c++
 
    CkExit()
    CkMyPe(integer mype)
@@ -188,7 +188,7 @@ In this step, you need to write a Charm++ interface file (.ci).
 In the file you can declare parallel chare arrays and their
 entry methods. The syntax is the same as in Charm++.
 
-::
+.. code-block:: c++
 
          // ## Just replace Hello throughout with your chare's name. ##
          // ## and add your chare's entry points below where indicated ##
index 7d1f94e5bfe75bfea8d081695ac0037ecb78be0b..654a94a75dbef0f01dca02d3a390ca75737ee251 100644 (file)
@@ -313,7 +313,7 @@ thread blocking and unblocking and a return message are not needed.
 Another big advantage of asynchronous methods is that it’s easy to make
 things run in parallel. If I execute:
 
-::
+.. code-block:: c++
 
    a->foo();
    b->bar();
@@ -344,7 +344,7 @@ In order to make an entry method threaded, one should add the keyword
 *threaded* withing square brackets after the *entry* keyword in the
 interface file:
 
-::
+.. code-block:: c++
 
    module M {
      chare X {
@@ -358,7 +358,7 @@ If I don’t want to use threads, how can an asynchronous method return a value?
 The usual way to get data back to your caller is via another invocation
 in the opposite direction:
 
-::
+.. code-block:: c++
 
    void A::start(void) {
      b->giveMeSomeData();
@@ -383,7 +383,7 @@ called it, and what method to call a back on. For this kind of
 request/response code, you can abstract away the “where to return the
 data” with a *CkCallback* object:
 
-::
+.. code-block:: c++
 
    void A::start(void) {
      b->giveMeSomeData(CkCallback(CkIndex_A::hereIsTheData,thisProxy));
@@ -540,7 +540,7 @@ One can have class-static variables as read-onlies. Inside a chare,
 group or array declaration in the *.ci* file, one can have a readonly
 variable declaration. Thus:
 
-::
+.. code-block:: c++
 
    chare someChare {
      ...
@@ -730,7 +730,7 @@ After sizing and packing a migrating array element, the array manager
 in the non-leaf nodes of your inheritance hierarchy are *virtual
 destructors*, with declaration syntax:
 
-::
+.. code-block:: c++
 
    class foo : ... {
      ...
@@ -817,7 +817,7 @@ Migratable groups must declare a migration constructor (taking
 constructor *must* call the superclass migration constructor as in this
 example:
 
-::
+.. code-block:: c++
 
    class MyGroup : public CBase_MyGroup {
      ...
@@ -961,7 +961,7 @@ then pup all the elements.
 
 For example, if you have a 2D grid like this:
 
-::
+.. code-block:: c++
 
    class foo {
     private:
@@ -1186,7 +1186,7 @@ My debugging printouts seem to be out of order. How can I prevent this?
 Printouts from different processors do not normally stay ordered.
 Consider the code:
 
-::
+.. code-block:: c++
 
    ...somewhere... {
      CkPrintf("cause\n");
@@ -1462,7 +1462,7 @@ includes a macro “FLINKAGE” that makes the symbol linkable from fortran (in
 C++, this expands to extern “C”), so a complete Fortran subroutine looks
 like in C or C++:
 
-::
+.. code-block:: c++
 
    FLINKAGE void FTN_NAME(FOO,foo)(void);
 
@@ -1512,7 +1512,7 @@ C:
           x=i
       END SUBROUTINE
 
-::
+.. code-block:: c++
 
       /* C/C++ */
       FLINKAGE void FTN_NAME(BAR,bar)(int *i) {
@@ -1535,7 +1535,7 @@ C:
           x=arr(1)
       END SUBROUTINE
 
-::
+.. code-block:: c++
 
       /* C/C++ */
       FLINKAGE void FTN_NAME(BAR,bar)(int *arr) {
@@ -1574,7 +1574,7 @@ C:
           END DO
       END SUBROUTINE
 
-::
+.. code-block:: c++
 
       /* C/C++ */
       FLINKAGE void FTN_NAME(BAR2,bar2)(int *arr,int *len1p,int *len2p) {
@@ -1597,7 +1597,7 @@ C:
           CALL BARS('some string',arg);
       END SUBROUTINE
 
-::
+.. code-block:: c++
 
       /* C/C++ */
       FLINKAGE void FTN_NAME(BARS,bars)(char *str,int *arg,int strlen) {
index c0cbcc840dda048ccc1172313f62eba946b8ac94..90f62b44dd72cc616a85d4c9a375b9db928f72d2 100644 (file)
@@ -143,7 +143,7 @@ Figure :numref:`fig:forcedecomp` (b).
 
 Hence, each chunk’s time loop has the structure:
 
-::
+.. code-block:: none
 
         chunk time loop
              element loop-- Element deformation applies forces to
@@ -169,7 +169,7 @@ and does the main work of the program. In the language of the TCHARM
 manual, init() runs in the serial context, and driver() runs in the
 parallel context.
 
-::
+.. code-block:: none
 
         subroutine init
              read the serial mesh and configuration data
@@ -196,7 +196,7 @@ FEM framework program using the MPI style. This is a more general, more
 flexible method of running the program, but it is more complicated than
 the classic mode. All FEM framework calls are available in either mode.
 
-::
+.. code-block:: none
 
       main program
          MPI_Init
@@ -326,7 +326,7 @@ or from whatever TCHARM code executes before the FEM_Attach.
 Utility
 -------
 
-::
+.. code-block:: c++
 
   int FEM_Num_partitions();
 
@@ -337,7 +337,7 @@ Utility
 Return the number of mesh chunks in the current computation. Can only be
 called from the driver routine.
 
-::
+.. code-block:: c++
 
   int FEM_My_partition();
 
@@ -348,7 +348,7 @@ called from the driver routine.
 Return the number of the current chunk, from 0 to num_partitions-1. Can
 only be called from the driver routine.
 
-::
+.. code-block:: c++
 
   double FEM_Timer();
 
@@ -359,7 +359,7 @@ only be called from the driver routine.
 Return the current wall clock time, in seconds. Resolution is
 machine-dependent, but is at worst 10ms.
 
-::
+.. code-block:: c++
 
   void FEM_Print_partition();
 
@@ -371,7 +371,7 @@ Print a debugging representation of the current chunk’s mesh. Prints the
 entire connectivity array, and data associated with each local node and
 element.
 
-::
+.. code-block:: c++
 
   void FEM_Print(const char *str);
 
@@ -513,7 +513,7 @@ FEM_ELEM+\ :math:`elType` is partitioned.
 Mesh Entity Manipulation
 ------------------------
 
-::
+.. code-block:: c++
 
   int FEM_Mesh_default_read(void);
 
@@ -529,7 +529,7 @@ Return the default reading mesh. This routine is valid:
 
 -  Anytime after a call to FEM_Mesh_set_default_read.
 
-::
+.. code-block:: c++
 
   int FEM_Mesh_default_write(void);
 
@@ -547,7 +547,7 @@ Return the default writing mesh. This routine is valid:
 
 -  Anytime after a call to FEM_Mesh_set_default_write.
 
-::
+.. code-block:: c++
 
   int FEM_Mesh_get_length(int mesh,int entity);
 
@@ -560,24 +560,24 @@ Return the number of entitys that exist in this mesh.
 This call can be used with any entity. For example, to get the number of
 nodes,
 
-::
+.. code-block:: c++
 
          nNodes=FEM_Mesh_get_length(mesh,FEM_NODE)
 
 To get the number of ghost nodes,
 
-::
+.. code-block:: c++
 
          nGhostNodes=FEM_Mesh_get_length(mesh,FEM_GHOST+FEM_NODE)
 
 To get the number of real elements of type 2,
 
-::
+.. code-block:: c++
 
        nElem=FEM_Mesh_get_length(mesh,FEM_ELEM+2)
 
 
-::
+.. code-block:: c++
 
   void FEM_Mesh_data(int mesh,int entity,int attr, void *data, int
   first, int length, int datatype,int width);
@@ -605,7 +605,7 @@ the mesh.
    width values, and contains the data values of the attribute for the
    corresponding entity. This data must be formatted as one of:
 
-   ::
+   .. code-block:: fortran
 
             datatype :: data(width,length)
             datatype :: data(width*length)
@@ -630,7 +630,7 @@ the mesh.
 For example, to set the element connectivity, which is stored as 3
 integer node indices in nodes, you would:
 
-::
+.. code-block:: c++
 
   /* C version */
   int *nodes=new int[3*nElems];
@@ -650,7 +650,7 @@ To add a new node property with 2 double-precision numbers from an array
 mat (containing, for example, material properties), you would first pick
 an unused user data "tag", for example 13, and:
 
-::
+.. code-block:: c++
 
   /* C version */
   double *mat=new double[2*nNodes];
@@ -666,7 +666,7 @@ an unused user data "tag", for example 13, and:
 Entity Inquiry
 --------------
 
-::
+.. code-block:: c++
 
   int FEM_Mesh_get_width(int mesh,int entity,int attr);
 
@@ -678,7 +678,7 @@ Entity Inquiry
 Return the width of the attribute attr of entity of mesh. This is the
 value previously passed as “width” to FEM_Mesh_data.
 
-::
+.. code-block:: c++
 
   int FEM_Mesh_get_datatype(int mesh,int entity,int attr);
 
@@ -690,7 +690,7 @@ value previously passed as “width” to FEM_Mesh_data.
 Return the FEM data type of the attribute attr of entity of mesh. This
 is the value previously passed as “datatype” to FEM_Mesh_data.
 
-::
+.. code-block:: c++
 
   int FEM_Mesh_get_entities(int mesh,int *entities);
 
@@ -709,7 +709,7 @@ For example, a simple mesh might have two entity types: FEM_NODE and
 FEM_ELEM+1.
 
 
-::
+.. code-block:: c++
 
   int FEM_Mesh_get_attributes(int mesh,int entity,int *attributes);
 
@@ -727,7 +727,7 @@ For example, a simple element might have three attributes: FEM_CONN for
 node connectivity, FEM_GLOBALNO for global element numbers, and
 FEM_DATA+7 for a material type.
 
-::
+.. code-block:: c++
 
   const char *FEM_Get_entity_name(int entity,char *storage);
   const char *FEM_Get_attr_name(int attr,char *storage);
@@ -742,7 +742,7 @@ These routines are only available in C.
 
 Advanced Entity Manipulation
 ----------------------------
-::
+.. code-block:: c++
 
   void FEM_Mesh_data_offset(int mesh,int entity,int attr, void *data,
   int first, int length, int datatype,int width, int offsetBytes,int
@@ -762,7 +762,7 @@ See the documentation of IDXL_Layout_offset in
 Section :numref:`sec:IDXLLayoutoffset` for details on how to set
 offsetBytes, distanceBytes, and skewBytes.
 
-::
+.. code-block:: c++
 
   void FEM_Mesh_data_layout(int mesh,int entity,int attr, void *data,
   int firstItem, int length, IDXL_Layout_t layout);
@@ -797,7 +797,7 @@ describe local data and hence operate independently on each chunk.
 Mesh Routines
 -------------
 
-::
+.. code-block:: c++
 
   int FEM_Mesh_allocate(void);
 
@@ -808,7 +808,7 @@ Mesh Routines
 Create a new local mesh object. The mesh is initially empty, but it is a
 setting mesh, so call FEM_Mesh_data to fill the mesh with data.
 
-::
+.. code-block:: c++
 
   int FEM_Mesh_deallocate(int mesh);
 
@@ -819,7 +819,7 @@ setting mesh, so call FEM_Mesh_data to fill the mesh with data.
 
 Destroy this local mesh object, and its associated data.
 
-::
+.. code-block:: c++
 
   int FEM_Mesh_copy(int mesh);
 
@@ -831,7 +831,7 @@ Destroy this local mesh object, and its associated data.
 Create a new mesh object with a separate copy of the data stored in
 this old mesh object.
 
-::
+.. code-block:: c++
 
   void FEM_Mesh_write(int mesh,const char *prefix,int partNo,int
   nParts);
@@ -857,7 +857,7 @@ format is currently ASCII based, but it is subject to change. We
 strongly recommend using the FEM routines to read and write these files
 rather than trying to prepare or parse them yourself.
 
-::
+.. code-block:: c++
 
   int FEM_Mesh_read(const char *prefix,int partNo,int nParts);
 
@@ -871,7 +871,7 @@ Read a new mesh from the file “prefix_vppartNo_nParts.dat”. The new
 mesh begins in getting mode, so you can read the data out of the mesh
 using calls to FEM_Mesh_data.
 
-::
+.. code-block:: c++
 
   int FEM_Mesh_broadcast(int mesh,int fromRank,FEM_Comm_t comm_context);
 
@@ -890,7 +890,7 @@ processors.
 For example, if rank 0 has a mesh named “src”, we can partition src for
 all the processors by executing:
 
-::
+.. code-block:: c++
 
      m=FEM_Mesh_broadcast(src,0,MPI_COMM_WORLD);
 
@@ -898,7 +898,7 @@ The new, partitioned mesh is in getting mode, so you can read the
 partitioned data using calls to FEM_Mesh_data. This call does not affect
 mesh in any way.
 
-::
+.. code-block:: c++
 
   int FEM_Mesh_reduce(int mesh,int toRank,FEM_Comm_t comm_context);
 
@@ -919,7 +919,7 @@ mesh.
 Mesh Utility
 ------------
 
-::
+.. code-block:: c++
 
   int FEM_Mesh_is_get(int mesh)
 
@@ -931,7 +931,7 @@ Mesh Utility
 Return true if this mesh is in getting mode. A getting mesh returns
 values to FEM_Mesh_data.
 
-::
+.. code-block:: c++
 
   int FEM_Mesh_is_set(int mesh)
 
@@ -943,7 +943,7 @@ values to FEM_Mesh_data.
 Return true if this mesh is in setting mode. A setting mesh extracts
 values from FEM_Mesh_data.
 
-::
+.. code-block:: c++
 
   void FEM_Mesh_become_get(int mesh)
 
@@ -954,7 +954,7 @@ values from FEM_Mesh_data.
 
 Put this mesh in getting mode, so you can read back its values.
 
-::
+.. code-block:: c++
 
   void FEM_Mesh_become_set(int mesh)
 
@@ -965,7 +965,7 @@ Put this mesh in getting mode, so you can read back its values.
 
 Put this mesh in setting mode, so you can set its values.
 
-::
+.. code-block:: c++
 
   void FEM_Mesh_print(int mesh);
 
@@ -979,7 +979,7 @@ Print out a text description of the nodes and elements of this mesh.
 Advanced Mesh Manipulation
 --------------------------
 
-::
+.. code-block:: c++
 
   typedef void (*FEM_Userdata_fn)(pup_er p,void *data);
   void FEM_Mesh_pup(int mesh,int pupTag, FEM_Userdata_fn fn, void *data);
@@ -1010,7 +1010,7 @@ constants such as the timestep or material properties. data is made a
 part of the mesh, and it will be read and written, sent and received,
 partitioned and assembled with the mesh.
 
-::
+.. code-block:: c++
 
   void FEM_Mesh_send(int mesh,int toRank,int tag,FEM_Comm_t
   comm_context);
@@ -1026,7 +1026,7 @@ to mix direct MPI calls with your FEM calls.
 
 This call does not affect mesh.
 
-::
+.. code-block:: c++
 
   int FEM_Mesh_recv(int fromRank,int tag,FEM_Comm_t comm_context);
 
@@ -1042,7 +1042,7 @@ use MPI_ANY_TAG for tag to match any tag.
 
 The new mesh is returned in getting mode.
 
-::
+.. code-block:: c++
 
   void FEM_Mesh_partition(int mesh,int nParts,int *destMeshes);
 
@@ -1059,7 +1059,7 @@ The partitioned mesh is returned in getting mode. This is a local call;
 FEM_Mesh_broadcast is the collective version. This call does not affect
 the source mesh mesh.
 
-::
+.. code-block:: c++
 
   int FEM_Mesh_assemble(int nParts,const int *srcMeshes);
 
@@ -1080,7 +1080,7 @@ The assembled mesh is returned in getting mode. This is a local call;
 FEM_Mesh_reduce is the collective version. This call does not affect the
 source meshes.
 
-::
+.. code-block:: c++
 
   void FEM_Mesh_copy_globalno(int src_mesh,int dest_mesh);
 
@@ -1183,7 +1183,7 @@ all the ghost nodes after all the real nodes. The code to extract and
 renumber the connectivity of some 3-node triangles stored in FEM_ELEM+2
 would be:
 
-::
+.. code-block:: c++
 
    /* C version */
    int nReal=FEM_Mesh_get_length(mesh,FEM_ELEM+2);
@@ -1244,7 +1244,7 @@ The framework’s ghost handling is element-centric. You specify which
 kinds of elements should be ghosts and how they connect by listing their
 faces before partitioning.
 
-::
+.. code-block:: c++
 
   void FEM_Add_ghost_layer(int nodesPerFace,int doAddNodes);
 
@@ -1273,7 +1273,7 @@ node-adjacent ghosts, a face is a single node.
  Calling this routine several times creates several layers of ghost
  elements, and the different layers need not have the same parameters.
 
-::
+.. code-block:: c++
 
   void FEM_Add_ghost_elem(int elType,int facesPerElem,const int
      *elem2face);
@@ -1306,7 +1306,7 @@ The above two routines are always used together. For example, if your
 elements are 3-node triangles and you only require one shared node for
 inclusion in a single ghost layer, you would use:
 
-::
+.. code-block:: c++
 
   FEM_Add_ghost_layer(1,1); /* 1 node per face: node adjacency */
   const static int tri2node[]={0,1,2};
@@ -1315,7 +1315,7 @@ inclusion in a single ghost layer, you would use:
 If you require two shared nodes (a shared edge), the code will look
 like:
 
-::
+.. code-block:: c++
 
   FEM_Add_ghost_layer(2,1); /* 2 nodes per face: edge adjacency */
   const static int tri2edge[]={0,1,  1,2,  2,0};
@@ -1345,7 +1345,7 @@ right sides; ordinary cross-processor parallel ghosts lie along the top
 edge where this chunk joins up with the rest of the domain; and the
 external boundary along the bottom of the chunk has no ghosts.
 
-::
+.. code-block:: c++
 
   void FEM_Add_linear_periodicity( int nFaces,int nPer, const int
   *facesA,const int *facesB, int nNodes,const double *nodeLocs );
@@ -1366,7 +1366,7 @@ order is recovered by matching 3d locations in the nodeLocs array.
 This call can be repeated, for example if the domain is periodic along
 several directions. This call can only be issued from init().
 
-::
+.. code-block:: c++
 
   void FEM_Sym_coordinates(int elTypeOrMinusOne,double *locs);
 
@@ -1396,7 +1396,7 @@ Advanced Symmetries and Ghosts-Lower Layer
 The geometric symmetry layer in the preceding section is actually a thin
 wrapper around this lower, more difficult to use layer.
 
-::
+.. code-block:: c++
 
   void FEM_Set_sym_nodes(const int *canon,const int *sym);
 
@@ -1454,7 +1454,7 @@ Node canon sym
 12   4     12 (bottom+right)
 ==== ===== =================
 
-::
+.. code-block:: c++
 
   void FEM_Get_sym(int elTypeOrMinusOne,int *destSym);
 
@@ -1486,7 +1486,7 @@ remain part of the framework indefinitely. These routines always use the
 default mesh, as returned by FEM_Mesh_default_read and
 FEM_Mesh_default_write.
 
-::
+.. code-block:: c++
 
   void FEM_Set_elem(int elType,int nEl,int doublePerEl,int nodePerEl);
   void FEM_Get_elem(int elType,int *nEl,int *doublePerEl,int
@@ -1514,7 +1514,7 @@ no need to make them in linearly increasing order. However, for a given
 type of element FEM_Set_elem must be called before setting that
 element’s connectivity or data.
 
-::
+.. code-block:: c++
 
   void FEM_Set_elem_conn(int elType,const int *conn);
   void FEM_Get_elem_conn(int elType,int *conn);
@@ -1549,7 +1549,7 @@ stored contiguously).
 
 In this older interface, ghost nodes are indicated by invalid,
 
-::
+.. code-block:: c++
 
   void FEM_Set_node(int nNode,int doublePerNode);
   void FEM_Get_node(int
@@ -1572,7 +1572,7 @@ with each node.
 Old Mesh Data
 -------------
 
-::
+.. code-block:: c++
 
   void FEM_Set_node_data(const double *data);
   void FEM_Get_node_data(double *data);
@@ -1628,7 +1628,7 @@ Section :numref:`sec:ghostnum` is used in the new API.
    Old ghost element and node numbering. FEM_Get_ghost_returns
    :math:`g`, FEM_Get_returns :math:`n`.
 
-::
+.. code-block:: c++
 
   int FEM_Get_node_ghost(void);
   int FEM_Get_elem_ghost(int elemType);
@@ -1636,7 +1636,7 @@ Section :numref:`sec:ghostnum` is used in the new API.
 The examples below iterate over the real and ghost elements using the
 old numbering:
 
-::
+.. code-block:: c++
 
   // C version:
   int firstGhost,max;
@@ -1662,14 +1662,14 @@ old numbering:
 Old Backward Compatibility
 --------------------------
 
-::
+.. code-block:: c++
 
   void FEM_Set_mesh(int nElem, int nNodes, int nodePerEl,const int*
   conn);
 
 This is a convenience routine equivalent to:
 
-::
+.. code-block:: c++
 
   FEM_Set_node(nNodes,0);
   FEM_Set_elem(0,nElem,0,nodePerEl);
@@ -1696,7 +1696,7 @@ imposed force or position. The routines in this section are used to
 describe this kind of mesh-associated data—data that only applies to
 some “sparse” subset of the nodes or elements.
 
-::
+.. code-block:: c++
 
   void FEM_Set_sparse(int S_id,int nRec, const int *nodes,int
   nodesPerRec, const void *data,int dataPerRec,int dataType);
@@ -1732,7 +1732,7 @@ For example, if the first set of sparse data is 17 sparse data records,
 each containing 2 nodes stored in bNodes and 3 integers stored in bDesc,
 we would make the call:
 
-::
+.. code-block:: c++
 
   /*C version*/
   FEM_Set_sparse(0,17, bNodes,2, bDesc,3,FEM_INT);
@@ -1742,7 +1742,7 @@ we would make the call:
   ! Fortran version
   CALL FEM_Set_sparse(1,17, bNodes,2, bDesc,3,FEM_INT)
 
-::
+.. code-block:: c++
 
   void FEM_Set_sparse_elem(int S_id,const int *rec2elem);
 
@@ -1760,7 +1760,7 @@ within that type. For example, to attach the 3 sparse records at S_id
 to the elements numbered 10, 11, and 12 of the element type elType,
 use:
 
-::
+.. code-block:: c++
 
   /*C version*/
   int rec2elem[]={elType,10, elType,11, elType,12};
@@ -1774,7 +1774,7 @@ use:
   rec2elem(2,1)=10; rec2elem(2,2)=11; rec2elem(2,3)=12;
   CALL FEM_Set_sparse_elem(S_id,rec2elem)
 
-::
+.. code-block:: c++
 
   int FEM_Get_sparse_length(int S_id);
   void FEM_Get_sparse(int S_id,int *nodes,void *data);
@@ -1800,7 +1800,7 @@ In this old interface, there is no way to access sparse ghosts.
 Mesh Modification
 =================
 
-::
+.. code-block:: c++
 
   void FEM_Update_mesh(FEM_Update_mesh_fn routine, int
   callMeshUpdated,int doWhat);
@@ -1905,7 +1905,7 @@ Index List Calls
 You refer to an Index List via an opaque handle—in C, the integer
 typedef IDXL_t; in Fortran, a bare INTEGER.
 
-::
+.. code-block:: c++
 
   IDXL_t FEM_Comm_shared(int mesh,int entity);
 
@@ -1922,7 +1922,7 @@ the send/sum communication pattern.
 Must be called from driver. mesh must be a reading mesh. entity must be
 FEM_NODE. You may not call IDXL_Destroy on the returned list.
 
-::
+.. code-block:: c++
 
   IDXL_t FEM_Comm_ghost(int mesh,int entity);
 
@@ -1948,7 +1948,7 @@ This routine must be called from driver. mesh must be a reading mesh.
 entity must not include FEM_GHOST-ghosts are already included. You may
 not call IDXL_Destroy on the returned list.
 
-::
+.. code-block:: c++
 
   IDXL_t IDXL_Create(void);
 
@@ -1962,7 +1962,7 @@ IDXL_Copy or IDXL_Combine.
 Must be called from driver. You must eventually call IDXL_Destroy on the
 returned list.
 
-::
+.. code-block:: c++
 
   void IDXL_Combine(IDXL_t dest,IDXL_t src,int startSend,int startRecv);
 
@@ -1985,7 +1985,7 @@ twice.
 Advanced Index List Calls
 ~~~~~~~~~~~~~~~~~~~~~~~~~
 
-::
+.. code-block:: c++
 
   void IDXL_Destroy(IDXL_t l);
 
@@ -1998,7 +1998,7 @@ Destroy this Index List, and free the list storage allocated by the
 framework. Only call this routine with lists you created using
 IDXL_Create; not lists obtained directly from the FEM framework.
 
-::
+.. code-block:: c++
 
   void IDXL_Print(IDXL_t l);
 
@@ -2011,7 +2011,7 @@ Print out the contents of this Index List. This routine shows both the
 send and receive indices on the list, for each chunk we communicate
 with.
 
-::
+.. code-block:: c++
 
   void IDXL_Copy(IDXL_t dest,IDXL_t src);
 
@@ -2023,7 +2023,7 @@ with.
 Copy the contents of the source Index List into the destination Index
 List, which should be empty.
 
-::
+.. code-block:: c++
 
   void IDXL_Shift(IDXL_t l,int startSend,int startRecv);
 
@@ -2034,7 +2034,7 @@ List, which should be empty.
 
 Like IDXL_Combine, but only shifts the indices within a single list.
 
-::
+.. code-block:: c++
 
   void IDXL_Add_entity(int newIdx,int nBetween,int *between);
 
@@ -2093,7 +2093,7 @@ In most programs, the data to be communicated is a dense array of data
 of one type. In this case, there is only one layout routine you need to
 know:
 
-::
+.. code-block:: c++
 
   IDXL_Layout_t IDXL_Layout_create(int type,int width);
 
@@ -2125,7 +2125,7 @@ IDXL_DOUBLE   double        DOUBLE PRECISION
 For example, if you keep a dense array with 3 doubles of force per node,
 you’d call this routine as:
 
-::
+.. code-block:: c++
 
   // C++ version:
   double *force=new double[3*n];
@@ -2150,7 +2150,7 @@ These advanced routines are only needed if you want to exchange data
 stored in an array of user-defined types. Most programs only need
 IDXL_Layout_create.
 
-::
+.. code-block:: c++
 
   IDXL_Layout_t IDXL_Layout_offset(int type, int width, int offsetBytes,
   int distanceBytes,int skewBytes);
@@ -2192,7 +2192,7 @@ In C, the offsetof and sizeof keywords are useful for finding these
 values. In Fortran, we provide a special routine called foffsetof that
 returns the distance, in bytes, between its two arguments.
 
-::
+.. code-block:: c++
 
   // C++ version:
   typedef struct {
@@ -2217,7 +2217,7 @@ returns the distance, in bytes, between its two arguments.
   &          foffsetof(nodes(1),nodes(1)%force),
   &          foffsetof(nodes(1),nodes(2)),0)
 
-::
+.. code-block:: c++
 
   void IDXL_Layout_destroy(IDXL_Layout_t layout);
 
@@ -2229,7 +2229,7 @@ returns the distance, in bytes, between its two arguments.
 Destroy this Layout. You only need call this routine if you repeatedly
 create layouts.
 
-::
+.. code-block:: c++
 
   int IDXL_Get_layout_type(IDXL_Layout_t layout);
 
@@ -2239,7 +2239,7 @@ create layouts.
 
 Return the IDXL datatype for this layout.
 
-::
+.. code-block:: c++
 
   int IDXL_Get_layout_width(IDXL_Layout_t layout);
 
@@ -2250,7 +2250,7 @@ Return the IDXL datatype for this layout.
 Return the layout width—the number of data items that are communicated
 per entity.
 
-::
+.. code-block:: c++
 
   int IDXL_Get_layout_distance(IDXL_Layout_t layout);
 
@@ -2267,7 +2267,7 @@ Layout Compatibility Routines
 Before IDXL was made a separate library, FEM included these routines,
 which are still preserved for backward compatibility.
 
-::
+.. code-block:: c++
 
   IDXL_Layout_t FEM_Create_simple_field(int type,int width);
 
@@ -2278,7 +2278,7 @@ which are still preserved for backward compatibility.
 
 This routine is completely interchangeable to IDXL_Layout_create.
 
-::
+.. code-block:: c++
 
   int FEM_Create_field(int type,int width,int offset,int distance);
 
@@ -2302,7 +2302,7 @@ to determine where to get and put the communicated data.
 Communication Routines
 ~~~~~~~~~~~~~~~~~~~~~~
 
-::
+.. code-block:: c++
 
   void IDXL_Comm_sendsum(IDXL_Comm_t comm,IDXL_t indices,IDXL_Layout_t
   layout,void *data);
@@ -2327,7 +2327,7 @@ It is a more general version of the old FEM routine FEM_Update_field.
 For example, to sum up the shared-node values in a 3d force vector
 indexed by node, you would use:
 
-::
+.. code-block:: c++
 
   // C++ version:
   double *force=new double[3*nNodes];
@@ -2349,7 +2349,7 @@ indexed by node, you would use:
   !... in the time loop ...
       CALL IDXL_Comm_sendsum(0,shared_indices,force_layout,force)
 
-::
+.. code-block:: c++
 
   void IDXL_Comm_sendrecv(IDXL_Comm_t comm,IDXL_t indices,IDXL_Layout_t
   layout,void *data);
@@ -2375,7 +2375,7 @@ FEM_Update_ghost_field. For example, to obtain 7 solution values per
 ghost element, storing gElem ghosts in the array just after the nElem
 regular elements, we could:
 
-::
+.. code-block:: c++
 
   // C++ version:
   double *elem=new double[7*(nElem+gElem)];
@@ -2404,7 +2404,7 @@ regular elements, we could:
 Advanced Communication Routines
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-::
+.. code-block:: c++
 
   IDXL_Comm_t IDXL_Comm_begin(int tag,int context);
 
@@ -2420,7 +2420,7 @@ Every call to this routine must eventually be matched by a call to
 IDXL_Comm_wait. Warning: for now, tag and context are ignored, and there
 can be only one outstanding communication operation.
 
-::
+.. code-block:: c++
 
   void IDXL_Comm_send(IDXL_Comm_t comm,IDXL_t indices,IDXL_Layout_t
   layout,const void *data);
@@ -2437,7 +2437,7 @@ this data array.
 This routine is always non-blocking; as the data array passed in will
 not be copied out until the call to IDXL_Comm_flush.
 
-::
+.. code-block:: c++
 
   void IDXL_Comm_recv(IDXL_Comm_t comm,IDXL_t indices,IDXL_Layout_t
   layout,void *data);
@@ -2454,7 +2454,7 @@ layout, into this data array.
 This routine is always non-blocking; as the data array passed in will
 not be copied into until the call to IDXL_Comm_wait.
 
-::
+.. code-block:: c++
 
   void IDXL_Comm_sum(IDXL_Comm_t comm,IDXL_t indices,IDXL_Layout_t
   layout,void *data);
@@ -2471,7 +2471,7 @@ with this layout, into this data array.
 This routine is always non-blocking; as the data array passed in will
 not be added to until the call to IDXL_Comm_wait.
 
-::
+.. code-block:: c++
 
   void IDXL_Comm_flush(IDXL_Comm_t comm);
 
@@ -2487,7 +2487,7 @@ large message is more efficient than sending many small messages.
 This routine is typically non-blocking, and may only be issued at most
 once per IDXL_Comm_begin.
 
-::
+.. code-block:: c++
 
   void IDXL_Comm_wait(IDXL_Comm_t comm);
 
@@ -2524,7 +2524,7 @@ ID to FEM_Update_field (which does the shared node communication),
 FEM_Reduce_field (which applies a reduction over node values), or one of
 the other routines described below.
 
-::
+.. code-block:: c++
 
   void FEM_Update_field(int Fid,void *nodes);
 
@@ -2548,7 +2548,7 @@ the same across all processors that share the node.
 
 This routine is equivalent to an IDXL_Comm_Sendsum operation.
 
-::
+.. code-block:: c++
 
   void FEM_Read_field(int Fid,void *nodes,char *fName);
 
@@ -2581,7 +2581,7 @@ other chunks.
 
 This routine has no IDXL equivalent.
 
-::
+.. code-block:: c++
 
   void FEM_Reduce_field(int Fid,const void *nodes,void *out,int op);
 
@@ -2614,7 +2614,7 @@ op must be one of:
 
 This routine has no IDXL equivalent.
 
-::
+.. code-block:: c++
 
   void FEM_Reduce(int Fid,const void *inVal,void *outVal,int op);
 
@@ -2634,7 +2634,7 @@ FEM_Reduce_field.
 May only be called from driver, and to complete, must be called from
 every chunk’s driver routine.
 
-::
+.. code-block:: c++
 
   ! C example
   double inArr[3], outArr[3];
@@ -2657,7 +2657,7 @@ Ghost Communication
 It is possible to get values for a chunk’s ghost nodes and elements from
 the neighbors. To do this, use:
 
-::
+.. code-block:: c++
 
   void FEM_Update_ghost_field(int Fid, int elTypeOrMinusOne, void
   *data);
@@ -2679,7 +2679,7 @@ Ghost List Exchange
 It is possible to exchange sparse lists of ghost elements between FEM
 chunks.
 
-::
+.. code-block:: c++
 
   void FEM_Exchange_ghost_lists(int elemType,int nIdx,const int
   *localIdx);
@@ -2695,7 +2695,7 @@ neighboring chunks that connect to its ghost elements on the other
 side. That is, if the element localIdx[i] has a ghost on some chunk c,
 localIdx[i] will be sent to and show up in the ghost list of chunk c.
 
-::
+.. code-block:: c++
 
   int FEM_Get_ghost_list_length(void);
 
@@ -2703,7 +2703,7 @@ Returns the number of entries in my
 ghost list—the number of my ghosts that other chunks passed to their
 call to FEM_Exchange_ghost_lists.
 
-::
+.. code-block:: c++
 
   void FEM_Get_ghost_list(int *retLocalIdx);
 
@@ -2742,7 +2742,7 @@ This creates the node and element adjacency information that is
 essential for the adaptivity operations. It also initializes all the
 mesh adaptivity related internal objects in the framework.
 
-::
+.. code-block:: c++
 
   void FEM_ADAPT_Init(int meshID)
 
@@ -2764,14 +2764,14 @@ smallest altitude and this value during mesh adaptivity is not allowed
 to go beyond a certain limit. Because the larger this value after a
 certain limit, the worse the element quality.
 
-::
+.. code-block:: c++
 
   void FEM_ADAPT_SetElementSizeField(int meshID, int elem, double size);
 
 For the mesh specified by meshID, for the element elem, we set the
 desired size for each element to be size.
 
-::
+.. code-block:: c++
 
   void FEM_ADAPT_SetElementSizeField(int meshID, double *sizes);
 
@@ -2779,14 +2779,14 @@ For the mesh specified by meshID, for the element elem, we set the
 desired size for each element from the corresponding entry in the sizes
 array.
 
-::
+.. code-block:: c++
 
   void FEM_ADAPT_SetReferenceMesh(int meshID);
 
 For each element int this mesh defined by meshID set its size to the
 average edge length of the corresponding element.
 
-::
+.. code-block:: c++
 
   void FEM_ADAPT_GradateMesh(int meshID, double smoothness);
 
@@ -2808,7 +2808,7 @@ operations to generate a mesh with higher quality elements while
 achieving the desired size (which is usually average edge length per
 element), or it could even be the area of each element.
 
-::
+.. code-block:: c++
 
   void FEM_ADAPT_Refine(int meshID, int qm, int method, double
   factor,double *sizes);
@@ -2821,7 +2821,7 @@ specified in the sizes array. In this array each entry corresponds to
 the corresponding element. Negative entries in sizes array indicate no
 refinement.
 
-::
+.. code-block:: c++
 
   void FEM_ADAPT_Coarsen(int meshID, int qm, int method, double
   factor,double *sizes);
@@ -2834,7 +2834,7 @@ specified in the sizes array. In this array each entry corresponds to
 the corresponding element. Negative entries in sizes array indicate no
 coarsening.
 
-::
+.. code-block:: c++
 
   void FEM_ADAPT_AdaptMesh(int meshID, int qm, int method, double
   factor,double *sizes);
@@ -2847,7 +2847,7 @@ also performs a mesh repair operation where it gets rid of some bad
 quality elements by Delaunay flip or coarsening as the geometry in the
 area demands.
 
-::
+.. code-block:: c++
 
   int FEM_ADAPT_SimpleRefineMesh(int meshID, double targetA, double xmin,
   double ymin, double xmax, double ymax);
@@ -2858,7 +2858,7 @@ meshID is given by targetA. This function only performs a series of
 refinements on the elements in this region. If the area is larger, then
 no coarsening is done.
 
-::
+.. code-block:: c++
 
   int FEM_ADAPT_SimpleCoarsenMesh(int meshID, double targetA, double xmin,
   double ymin, double xmax, double ymax);
@@ -2879,7 +2879,7 @@ adaptivity algorithms are designed to work on. There is a function that
 can be used to test various properties of a mesh, like area, quality,
 geometric consistency, idxl list correctness, etc.
 
-::
+.. code-block:: c++
 
   void FEM_ADAPT_TestMesh(int meshID);
 
index 73a6f9c5706f6d53f45e36a584d932d15b5a8e5a..1a578737487e8a7f38e1f5110cd790d0392b1338 100644 (file)
@@ -115,11 +115,11 @@ for the :math:`b` vector.
 IFEM_Solve_shared
 -----------------
 
-::
+.. code-block:: c++
 
-  void IFEM_Solve_shared(ILSI_Solver s, ILSI_Param *p, int fem_mesh, int
-    fem_entity, int length, int width, IFEM_Matrix_product_c A, void *ptr,
-    const double *b, double *x);
+   void IFEM_Solve_shared(ILSI_Solver s, ILSI_Param *p, int fem_mesh, int
+     fem_entity, int length, int width, IFEM_Matrix_product_c A, void *ptr,
+     const double *b, double *x);
 
 .. code-block:: fortran
 
@@ -156,7 +156,7 @@ Fortran, these arrays should be allocated like x(width,length).
 When this routine returns, x is the final value for the unknown vector,
 and the output values of the solver parameters p will have been written.
 
-::
+.. code-block:: c++
 
    // C++ Example
    int mesh=FEM_Mesh_default_read();
@@ -210,7 +210,7 @@ IFEM requires you to write a matrix-vector product routine that will
 evaluate :math:`A x` for various vectors :math:`x`. You may use any
 subroutine name, but it must take these arguments:
 
-::
+.. code-block:: c++
 
   void IFEM_Matrix_product(void *ptr, int length, int width, const double
     *src, double *dest);
@@ -242,7 +242,7 @@ After calling this routine, the framework will handle combining the
 overlapping portions of these vectors across processors to arrive at a
 consistent global matrix-vector product.
 
-::
+.. code-block:: c++
 
    // C++ Example
    #include "ifemc.h"
@@ -300,7 +300,7 @@ consistent global matrix-vector product.
 IFEM_Solve_shared_bc
 --------------------
 
-::
+.. code-block:: c++
 
   void IFEM_Solve_shared_bc(ILSI_Solver s, ILSI_Param *p, int fem_mesh,
   int fem_entity, int length, int width, int bcCount, const int *bcDOF,
@@ -341,7 +341,7 @@ For example, if :math:`width` is 3 in a 3d problem, we would set node
 :math:`ny`\ ’s y coordinate to 4.6 and node :math:`nz`\ ’s z coordinate
 to 7.3 like this:
 
-::
+.. code-block:: c++
 
    // C++ Example
    int bcCount=2;
index 423674d77582a8dea4115d30d6e2a79da5ab4c15..a1ad68bb63816121fa82abd2a42336acc7b9663b 100644 (file)
@@ -95,7 +95,7 @@ Every mainchare’s main is executed at startup.
 threaded methods
 ----------------
 
-::
+.. code-block:: java
 
    class C {
        public threaded void start(CProxy_CacheGroup cg) { ... }
@@ -104,7 +104,7 @@ threaded methods
 readonly
 --------
 
-::
+.. code-block:: java
 
    class C {
        public static readonly CProxy_TheMain mainChare;
@@ -119,7 +119,7 @@ is propagated to all processors. Then execution begins.
 msa
 ---
 
-::
+.. code-block:: java
 
    arr1.enroll();
    int a = arr1[10]; // get
index 05caf2734a3b96f6b0a2683b5b0964582073c09c..5ec925052b0b72ccbaa162a793a61e5ebefb5701 100644 (file)
@@ -55,14 +55,14 @@ The liveViz routines are in the Charm++ header “liveViz.h”.
 A typical program provides a chare array with one entry method with the
 following prototype:
 
-::
+.. code-block:: c++
 
      entry void functionName(liveVizRequestMsg *m);
 
 This entry method is supposed to deposit its (array element’s) chunk of
 the image. This entry method has following structure:
 
-::
+.. code-block:: c++
 
      void myArray::functionName (liveVizRequestMsg *m)
      {
@@ -87,7 +87,7 @@ image will have the pixel with highest intensity or in other words
 largest value), you need to pass one more parameter (liveVizCombine_t)
 to the “liveVizDeposit” function:
 
-::
+.. code-block:: c++
 
     liveVizDeposit (m, startX, startY, width, height, imageBuff, this,
                     max_image_data);
@@ -114,7 +114,7 @@ routine below. This routine converts fully assembled ‘float’ pixels to
 RGB 3-byte pixels, and is called only on processor 0 after each client
 request.
 
-::
+.. code-block:: c++
 
   extern "C"
   void liveVizFloatToRGB(liveVizRequest &req,
@@ -132,7 +132,7 @@ main chare:
    method ’functionName’ (described above). You must create the chare
    array using a CkArrayOptions ’opts’ parameter. For instance,
 
-   ::
+   .. code-block:: c++
 
        CkArrayOptions opts(rows, cols);
        array = CProxy_Type::ckNew(opts);
@@ -170,7 +170,7 @@ The liveVizConfig parameters are:
 
 A typical 2D, RGB, non-push call to liveVizConfig looks like this:
 
-::
+.. code-block:: c++
 
       liveVizConfig cfg(true,false);
 
@@ -205,7 +205,7 @@ First we describe the use of Poll Mode, and then we will describe the
 differences. liveVizPoll must get control during the creation of your
 array, so you call liveVizPollInit with no parameters.
 
-::
+.. code-block:: c++
 
        liveVizPollInit();
        CkArrayOptions opts(nChares);
@@ -217,7 +217,7 @@ requests them. Each server generated image is buffered until the client
 can get the image. The buffered images will be stored in memory on
 processor 0.
 
-::
+.. code-block:: c++
 
      liveVizPollDeposit(this,
                         startX,startY,            // Location of local piece
@@ -233,7 +233,7 @@ sum_image_data and 3 bytes per pixel.
 
 A sample liveVizPoll server and client are available at:
 
-::
+.. code-block:: none
 
               .../charm/examples/charm++/lvServer
               .../ccs_tools/bin/lvClient
@@ -441,7 +441,7 @@ unique identifier for the newly created set of proxies.
 
 An example of Charm-FFT initialization using Charm_createFFT:
 
-::
+.. code-block:: c++
 
   // .ci
   extern module fft_charm;
@@ -477,7 +477,7 @@ when an FFT instance has been created.
 Using the newly received proxy, the user can identify whether a local PE
 has XPencils and/or ZPencils.
 
-::
+.. code-block:: c++
 
        void Driver::proxyCreated(idMsg *msg) {
          CProxy_fft2d fftProxy = msg->id;
@@ -493,7 +493,7 @@ has XPencils and/or ZPencils.
 Then, the grid’s dimensions on a PE can be acquired by using
 *Charm_getOutputExtents* and *Charm_getInputExtents*.
 
-::
+.. code-block:: c++
 
        if (hasX) {
          Charm_getOutputExtents(gridStart[MY_X], gridEnd[MY_X],
@@ -518,7 +518,7 @@ output buffers. In most cases, this is simply the product of the three
 dimensions, but for real-to-complex FFT calcaultion, FFTW-style storage
 for the input buffers is used (as shown below).
 
-::
+.. code-block:: c++
 
        dataSize = gridLength[MY_X] * gridLength[MY_Y] * gridLength[MY_Z];
 
@@ -545,7 +545,7 @@ FFT operation is complete.
 
 For forward FFT
 
-::
+.. code-block:: c++
 
        if (CkMyPe() == 0) {
            Charm_doForwardFFT(CkCallback(CkIndex_Driver::fftDone(), thisProxy), fftProxy);
@@ -553,7 +553,7 @@ For forward FFT
 
 For backward FFT
 
-::
+.. code-block:: c++
 
        if (CkMyPe() == 0) {
            Charm_doBackwardFFT(CkCallback(CkIndex_Driver::fftDone(), thisProxy), fftProxy);
@@ -729,7 +729,7 @@ To use TRAM for sending to a group, a GroupMeshStreamer group should be
 created. Either of the following two GroupMeshStreamer constructors can
 be used for that purpose:
 
-::
+.. code-block:: c++
 
    template<class dtype, class ClientType, class RouterType>
    GroupMeshStreamer<dtype, ClientType, RouterType>::
@@ -755,7 +755,7 @@ Sending to a Chare Array
 For sending to a chare array, an ArrayMeshStreamer group should be
 created, which has a similar constructor interface to GroupMeshStreamer:
 
-::
+.. code-block:: c++
 
    template <class dtype, class itype, class ClientType,
              class RouterType>
@@ -832,7 +832,7 @@ each of the three modes.
 When using completion detection, each local instance of TRAM must be
 initialized using the following variant of the overloaded init function:
 
-::
+.. code-block:: c++
 
    template <class dtype, class RouterType>
    void MeshStreamer<dtype, RouterType>::
@@ -868,7 +868,7 @@ termination. In this case, each local instance of TRAM must be
 initialized using a different interface for the overloaded init
 function:
 
-::
+.. code-block:: c++
 
    template <class dtype, class RouterType>
    void MeshStreamer<dtype, RouterType>::
@@ -888,7 +888,7 @@ CkArrayID object for the chare array that will perform the sends,
 precluding the need to manually determine the number of client chares
 per PE:
 
-::
+.. code-block:: c++
 
    template <class dtype, class RouterType>
    void MeshStreamer<dtype, RouterType>::
@@ -900,22 +900,22 @@ per PE:
 
 The init interface for using quiescence detection is:
 
-::
+.. code-block:: c++
 
    template <class dtype, class RouterType>
    void MeshStreamer<dtype, RouterType>::init(CkCallback startCb,
                                               int prio);
 
-After initialization is finished, the system invokes startCb,
-  signaling to the user that the library is ready to accept data items
-  for sending.
+After initialization is finished, the system invokes startCb,
+signaling to the user that the library is ready to accept data items
+for sending.
 
 Sending
 ~~~~~~~
 
 Sending with TRAM is done through calls to insertData and broadcast.
 
-::
+.. code-block:: c++
 
    template <class dtype, class RouterType>
    void MeshStreamer<dtype, RouterType>::
@@ -951,7 +951,7 @@ Receiving
 To receive data items sent using TRAM, the user must define the process
 function for each client group and array:
 
-::
+.. code-block:: c++
 
    void process(const dtype &ran);
 
@@ -979,7 +979,7 @@ of the primary mechanisms.
 Termination typically requires the user to issue a number of calls to
 the done function:
 
-::
+.. code-block:: c++
 
    template <class dtype, class RouterType>
    void MeshStreamer<dtype, RouterType>::
@@ -1082,19 +1082,19 @@ follows:
 
 -  Registration of the message type:
 
-   ::
+   .. code-block:: c++
 
       message MeshStreamerMessage<dtype>;
 
 -  Registration of the base aggregator class
 
-   ::
+   .. code-block:: c++
 
       group MeshStreamer<dtype, RouterType>;
 
 -  Registration of the derived aggregator class
 
-   ::
+   .. code-block:: c++
 
       group GroupMeshStreamer<dtype, ClientType, RouterType>;
 
@@ -1103,20 +1103,20 @@ follows:
 
 -  Registration of the message type:
 
-   ::
+   .. code-block:: c++
 
       message MeshStreamerMessage<ArrayDataItem<dtype, itype> >;
 
 -  Registration of the base aggregator class
 
-   ::
+   .. code-block:: c++
 
       group MeshStreamer<ArrayDataItem<dtype, itype>,
                          RouterType>;
 
 -  Registration of the derived aggregator class
 
-   ::
+   .. code-block:: c++
 
       group ArrayMeshStreamer<dtype, itype, ClientType,
                               RouterType>;
@@ -1188,9 +1188,9 @@ GPU Manager is not included by default when building Charm++. In order
 to use GPU Manager, the user must build Charm++ using the ``cuda``
 option, e.g.
 
-::
+.. code-block:: bash
 
-   ./build charm++ netlrts-linux-x86_64 cuda -j8
+   ./build charm++ netlrts-linux-x86_64 cuda -j8
 
 Building GPU Manager requires an installation of the CUDA toolkit on the
 system.
@@ -1220,13 +1220,13 @@ informs the runtime that a chare has offloaded work to the GPU, allowing
 the provided Charm++ callback to be invoked once it is complete. The
 non-blocking API has the following prototype:
 
-::
+.. code-block:: c++
 
      void hapiAddCallback(cudaStream_t stream, CkCallback* callback);
 
 Other HAPI calls:
 
-::
+.. code-block:: c++
 
      void hapiCreateStreams();
      cudaStream_t hapiGetStream();
index cb17d4501b3e2b40d67cf599fd9a7b488a9109ed..109abde3929cb99dcd8101ee16f4fa32572ddefd 100644 (file)
@@ -186,9 +186,9 @@ domain into the number of blocks you specify, then writes out .mblk and
 For example, to divide the single binary mesh “in1.msh” into 20 pieces
 “out00001.[mb]blk”..“out00020.[mb]blk”, you’d use
 
-::
+.. code-block:: bash
 
-       makemblock in1.msh 20 out
+   $ makemblock in1.msh 20 out
 
 You would then run this mesh using 20 virtual processors.
 
@@ -210,7 +210,7 @@ The values passed to these functions are typically read from a
 configuration file or computed from command-line parameters.
 
 
-::
+.. code-block:: c++
 
   int MBLK_Set_prefix(const char *prefix);
 
@@ -225,7 +225,7 @@ This function is called to set the block filename prefix. For example,
 if the input block files are named “gridX00001.mblk” and
 “gridX00002.mblk”, the prefix is the string “gridX”.
 
-::
+.. code-block:: c++
 
   int MBLK_Set_nblocks(const int n);
 
@@ -245,7 +245,7 @@ balancing and allow adaptive overlap of computation and communication.
 Be sure to set the number of blocks equal to the number of virtual
 processors (+vp command-line option).
 
-::
+.. code-block:: c++
 
   int MBLK_Set_dim(const int n);
 
@@ -261,7 +261,7 @@ dimensional computations are currently supported.
 Utility
 -------
 
-::
+.. code-block:: c++
 
   int MBLK_Get_nblocks(int* n);
 
@@ -274,7 +274,7 @@ Utility
 Get the total number of blocks in the current computation. Can only be
 called from the driver routine.
 
-::
+.. code-block:: c++
 
   int MBLK_Get_myblock(int* m);
 
@@ -287,7 +287,7 @@ called from the driver routine.
 Get the id of the current block, an integer from 0 to the number of
 blocks minus one. Can only be called from the driver routine.
 
-::
+.. code-block:: c++
 
   int MBLK_Get_blocksize(int* dims);
 
@@ -302,7 +302,7 @@ of the array dims should be 3, and will be filled with the :math:`i`,
 :math:`j`, and :math:`k` dimensions of the block. Can only be called
 from the driver routine.
 
-::
+.. code-block:: c++
 
   int MBLK_Get_nodelocs(const int* nodedim,double *nodelocs);
 
@@ -329,7 +329,7 @@ the locations of ghost nodes, create a node-centered field containing
 the node locations and do an update field. Can only be called from the
 driver routine.
 
-::
+.. code-block:: c++
 
   double MBLK_Timer(void);
 
@@ -340,7 +340,7 @@ driver routine.
 Return the current wall clock time, in seconds. Resolution is
 machine-dependent, but is at worst 10ms.
 
-::
+.. code-block:: c++
 
   void MBLK_Print_block(void);
 
@@ -351,7 +351,7 @@ machine-dependent, but is at worst 10ms.
 Print a debugging representation of the framework’s information about
 the current block.
 
-::
+.. code-block:: c++
 
   void MBLK_Print(const char *str);
 
@@ -378,7 +378,7 @@ field ID to MBLK_Update_Field (which does the overlapping block
 communication) and/or MBLK_Reduce_Field (which applies a reduction over
 block values).
 
-::
+.. code-block:: c++
 
   int MBLK_Create_Field(int *dimensions,int isVoxel,const int
   base_type,const int vec_len,const int offset,const int dist, int
@@ -458,7 +458,7 @@ returns the offset in bytes of memory between its two given variables. C
 users can use the built-in ``sizeof`` keyword or pointer arithmetic to
 achieve the same result.
 
-::
+.. code-block:: c++
 
   void MBLK_Update_field(const int fid,int ghostwidth, void *grid);
 
@@ -495,7 +495,7 @@ routine returns, the given field will updated. If the update was
 successful MBLK_SUCCESS is returned, otherwise MBLK_FAILURE is returned in case
 of error.
 
-::
+.. code-block:: c++
 
   void MBLK_Iupdate_field(const int fid,int ghostwidth, void *ingrid, void* outgrid);
 
@@ -521,7 +521,7 @@ the update must be checked using MBLK_Test_update or MBLK_Wait_update.
 
 There can be only one outstanding Iupdate call in progress at any time.
 
-::
+.. code-block:: c++
 
   int MBLK_Test_update(int *status);
 
@@ -537,7 +537,7 @@ MBLK_DONE if the update was completed or MBLK_NOTDONE if the update is
 still pending. Rather than looping if the update is still pending,
 call MBLK_Wait_update to relinquish the CPU.
 
-::
+.. code-block:: c++
 
   void MBLK_Wait_update(void);
 
@@ -548,7 +548,7 @@ call MBLK_Wait_update to relinquish the CPU.
 MBLK_Wait_update call is a blocking call and is used in association with
 MBLK_Iupdate_field call. It blocks until the update is completed.
 
-::
+.. code-block:: c++
 
   void MBLK_Reduce_field(int fid,void *grid, void *out,int op);
 
@@ -578,7 +578,7 @@ op must be one of:
 -  MBLK_MAX -- each element of ``outVal`` will be the largest value among the
    corresponding field of all blocks
 
-::
+.. code-block:: c++
 
   void MBLK_Reduce(int fid,void *inVal,void *outVal,int op);
 
@@ -608,7 +608,7 @@ The Multiblock framework keeps track of where boundary conditions are to
 be applied. You register a subroutine that the framework will call to
 apply each type of external boundary condition.
 
-::
+.. code-block:: c++
 
   int MBLK_Register_bc(const int bcnum, int ghostWidth, const MBLK_BcFn bcfn);
 
@@ -643,7 +643,7 @@ this routine. The routine should be declared like:
        integer :: start(3), end(3)
        end subroutine
 
-::
+.. code-block:: c++
 
        /* In C */
        void applyMyBC(void *param1,void *param2,int *start,int *end);
@@ -681,7 +681,7 @@ the boundary, with a 2-deep ghost region, would be:
 
        end subroutine
 
-::
+.. code-block:: c++
 
   int MBLK_Apply_bc(const int bcnum, void *param1,void *param2);
 
@@ -697,7 +697,7 @@ MBLK_Apply_bc call is made to apply all boundary condition functions
 of type ``bcnum`` to the block. ``param1`` and ``param2`` are passed unmodified to
 the boundary condition function.
 
-::
+.. code-block:: c++
 
   int MBLK_Apply_bc_all(void* param1, void* param2);
 
@@ -753,7 +753,7 @@ checkpointing your values).
 PUP functions are much easier to write than explain -- a simple C heap
 block and the corresponding PUP function is:
 
-::
+.. code-block:: c++
 
   typedef struct {
     int n1; /*Length of first array below*/
@@ -819,7 +819,7 @@ A Fortran ``TYPE`` block and corresponding PUP routine is as follows:
           END IF
         END SUBROUTINE
 
-::
+.. code-block:: c++
 
   int MBLK_Register(void *block, MBLK_PupFn pup_ud, int* rid)
 
@@ -836,7 +836,7 @@ from driver. It returns MBLK_SUCESS if the call was successful and
 MBLK_FAILURE in case of error. For the declarations above, you call
 MBLK_Register as:
 
-::
+.. code-block:: c++
 
              /*C/C++ driver() function*/
              int myId, err;
@@ -861,7 +861,7 @@ MBLK_Register as:
 Note that Fortran blocks must be allocated on the stack in driver, while
 C/C++ blocks may be allocated on the heap.
 
-::
+.. code-block:: c++
 
   void MBLK_Migrate()
 
@@ -878,7 +878,7 @@ your PUP function will be called with an unpacking pupper. MBLK_Migrate
 will then return, whereupon you should call MBLK_Get_registered to get
 your unpacked data block. Can only be called from the driver.
 
-::
+.. code-block:: c++
 
   int MBLK_Get_Userdata(int n, void** block)
 
index e6193bd88314e2362a1cbc2a445beb5257bcb0ad..c3f873cca264ebe1d9d34fbe7e2e0625d9985918 100644 (file)
@@ -139,7 +139,7 @@ Simple Interface
 
 The details of how to make each call are:
 
-::
+.. code-block:: c++
 
      NetFEM NetFEM_Begin(int source, int step, int dim, int flavor);
 
@@ -170,7 +170,7 @@ out of your arrays. Or it can take the value NetFEM_WRITE, which writes
 out the data to files named “NetFEM/step/source.dat” for offline
 visualization.
 
-::
+.. code-block:: c++
 
      void NetFEM_End(NetFEM n);
 
@@ -182,7 +182,7 @@ visualization.
 Finishes describing a single piece of a mesh, which then makes the
 mesh available for display.
 
-::
+.. code-block:: c++
 
      void NetFEM_Nodes(NetFEM n,int nNodes,const double *loc,const char *name);
 
@@ -210,7 +210,7 @@ client. We recommend also including the location units here, for example
 "Position (m)".
 
 
-::
+.. code-block:: c++
 
      void NetFEM_Elements(NetFEM n,int nElements,int nodePerEl,const int *conn,const char *name);
 
@@ -242,7 +242,7 @@ or conn((e-1)*nodePerEl+1).
 name is a human-readable name for the elements to display in the client.
 For example, this might be "Linear-Strain Triangles".
 
-::
+.. code-block:: c++
 
      void NetFEM_Vector(NetFEM n,const double *data,const char *name);
 
@@ -267,7 +267,7 @@ data[2*e]; in Fortran, element :math:`e`\ ’s vector is data(:,e).
 name is a human-readable name for this vector data. For example, this
 might be "Velocity (m/s)".
 
-::
+.. code-block:: c++
 
      void NetFEM_Scalar(NetFEM n,const double *data,int dataPer,const char *name);
 
@@ -313,7 +313,7 @@ In C, use the macro “NetFEM_Field(theStruct,theField)” to describe the
 FIELD. For example, to describe the field “loc” of your structure named
 “node_t”,
 
-::
+.. code-block:: c++
 
       node_t *myNodes=...;
       ..., NetFEM_Field(node_t,loc), ...
@@ -329,7 +329,7 @@ arguments, can be used for this. For example, to describe the field
       TYPE(NODE), ALLOCATABLE :: n(:)
       ..., foffsetof(n(1),n(1)%loc),foffsetof(n(1),n(2)), ...
 
-::
+.. code-block:: c++
 
       void NetFEM_Nodes_field(NetFEM n,int nNodes,FIELD,const void *loc,const char *name);
 
@@ -339,7 +339,7 @@ arguments, can be used for this. For example, to describe the field
 
 A FIELD version of NetFEM_Nodes.
 
-::
+.. code-block:: c++
 
       void NetFEM_Elements_field(NetFEM n,int nElements,int nodePerEl,FIELD,int idxBase,const int *conn,const char *name);
 
@@ -351,7 +351,7 @@ A FIELD version of NetFEM_Elements. This version also allows you to
 control the starting node index of the connectivity array—in C, this is
 normally 0; in Fortran, this is normally 1.
 
-::
+.. code-block:: c++
 
       void NetFEM_Vector_field(NetFEM n,const double *data,FIELD,const char *name);
 
@@ -361,7 +361,7 @@ normally 0; in Fortran, this is normally 1.
 
 A FIELD version of NetFEM_Vector.
 
-::
+.. code-block:: c++
 
       void NetFEM_Scalar_field(NetFEM n,const double *data,int dataPer,FIELD,const char *name);
 
index eb8c9bee7fa70ec1f68c0f5e127a54ab61961d92..b1678b8033398a2f968c0fb8aa4f092400168dbf 100644 (file)
@@ -249,7 +249,7 @@ Currently, event messages are declared with no reference to what they
 might inherit from (unlike in Charm++). The translator takes care of
 this. In addition, they must define ``operator=``.
 
-::
+.. code-block:: c++
 
   class myMessage {
     public:
@@ -268,7 +268,7 @@ as well. In addition, a ``pup`` and ``operator=`` must be provided.
 The ``pup`` method should call the ``pup`` method of the global state
 representation class being used.
 
-::
+.. code-block:: c++
 
   class mySim {
     int anInt; float aFloat; char aString[20];
@@ -298,7 +298,7 @@ fit. It could be given an empty body and should still work for POSE.
 Poser entry constructors (those described in the ``.ci`` file) should
 follow the template below:
 
-::
+.. code-block:: c++
 
   mySim::mySim(myMessage *m)
   {
@@ -316,7 +316,7 @@ those.
 
 An event method should have the following form:
 
-::
+.. code-block:: c++
 
   void mySim::myEventMethod(eventMsg *m) {
     // body of method
@@ -338,7 +338,7 @@ Creation of Poser Objects
 
 Posers are created within a module using the following syntax:
 
-::
+.. code-block:: c++
 
   int hdl = 13; // handle should be unique
   myMessage *m = new myMessage;
@@ -351,7 +351,7 @@ simulation time zero, and can be referred to by the handle 13.
 Creating a poser from outside the module (*i.e.* from ``main``) is
 somewhat more complex:
 
-::
+.. code-block:: c++
 
   int hdl = 13;
   myMessage *m = new myMessage;
@@ -375,7 +375,7 @@ There are three ways to send events within a POSE module. The first and
 most commonly used way involves specifying and offset in simulation time
 from the current time. The syntax follows:
 
-::
+.. code-block:: c++
 
   aMsg = new eventMsg;
   POSE_invoke(myEventMethod(aMsg), mySim, hdl, 0);
@@ -393,7 +393,7 @@ are not a part of the simulation, they do not have a current time, or
 OVT, by which to specify an offset. The syntax is nearly identical to
 that above, only the last parameter is an absolute time.
 
-::
+.. code-block:: c++
 
   aMsg = new eventMsg;
   POSE_invoke_at(myEventMethod(aMsg), mySim, hdl, 56);
@@ -409,7 +409,7 @@ outside any module, but this is not recommended.
 The third approach is useful when an object send events to itself. It is
 simply a slightly shorter syntax for the same thing as ``POSE_invoke``:
 
-::
+.. code-block:: c++
 
   aMsg = new eventMsg;
   POSE_local_invoke(myEventMethod(aMsg), offset);
@@ -426,7 +426,7 @@ OVT) to the timestamp of the event.
 It is also possible to elapse time on an object while the object is
 executing an event. This is accomplished thus:
 
-::
+.. code-block:: c++
 
  elapse(42);
 
@@ -444,7 +444,7 @@ To interface these with a main program module, say :math:`Pgm` in files
 ``pgm.ci``, ``pgm.h`` and ``pgm.C``, the ``pgm.ci`` file must declare
 the POSE module as extern in the ``mainmodule Pgm`` block. For example:
 
-::
+.. code-block:: c++
 
   mainmodule Pgm {
     extern module <modname>;
@@ -474,7 +474,7 @@ each with a unique handle. The programmer is responsible for choosing
 and keeping track of the handles created for posers. Once all posers are
 created, the simulation can be started:
 
-::
+.. code-block:: c++
 
   POSE_start();
 
@@ -660,7 +660,7 @@ Glossary of POSE-specific Terms
      on. For example, to register the function ``wrapUp`` in the main
      module as a callback:
 
-   ::
+   .. code-block:: c++
 
         CProxy_main M(mainhandle);
         POSE_registerCallBack(CkCallback(CkIndex_main::wrapUp(), M));
index cc372c0302fa63ac57d1d285a7d5613ca32c21f3..cf719a70825acd2b63b39bd38eed2a0d3ac5b7a6 100644 (file)
@@ -356,7 +356,7 @@ The calls for recording user events are the following:
 
    Eg.
 
-   ::
+   .. code-block:: c++
 
          traceRegisterUserEvent("Critical Code", 20); // on PE 0
          double critStart = CmiWallTimer();  // start time
index a6f312e0244cedc2e2f3275aa8e2aa8fec66e963..e73f3c55692ebbeb2f9ef58c28fa4bfed1ca4dbe 100644 (file)
@@ -232,7 +232,7 @@ merely sizing a buffer, or checkpointing your values).
 pup functions are much easier to write than explain- a simple C heap
 block and the corresponding pup function is:
 
-::
+.. code-block:: c++
 
         typedef struct {
           int n1;/*Length of first array below*/
@@ -294,7 +294,7 @@ You indicate to TCharm that you want a pup routine called using the
 routine below. An arbitrary number of blocks can be registered in this
 fashion.
 
-::
+.. code-block:: c++
 
   void TCHARM_Register(void *block, TCharmPupFn pup_fn)
 
@@ -308,7 +308,7 @@ Associate the given data block and pup function. Can only be called
 from the parallel context. For the declarations above, you call
 TCHARM_Register as:
 
-::
+.. code-block:: c++
 
              /*In C/C++ driver() function*/
              my_block m;
@@ -334,7 +334,7 @@ Fortran, the "TARGET" attribute must be used on the block (as above) or
 else the compiler may not update values during a migration, because it
 believes only it can access the block.
 
-::
+.. code-block:: c++
 
   void TCHARM_Migrate()
 
@@ -363,7 +363,7 @@ deleting pup handle, so you need not handle that case.
 
 A C example is:
 
-::
+.. code-block:: c++
 
         int g_arr[17];
         double g_f;
@@ -409,7 +409,7 @@ A Fortran example is:
 You register your global variable pup routine using the method below.
 Multiple pup routines can be registered the same way.
 
-::
+.. code-block:: c++
 
   void TCHARM_Readonly_globals(TCharmPupGlobalFn pup_fn)
 
@@ -441,7 +441,7 @@ frameworks cannot be attached more than once to single set of threads.
 That is, a single thread cannot have two attached AMPI frameworks, since
 the MPI_COMM_WORLD for such a thread would be indeterminate.
 
-::
+.. code-block:: c++
 
   void TCHARM_Create(int nThreads, TCharmThreadStartFn thread_fn)
 
@@ -463,7 +463,7 @@ to the current set of threads.
 
 To attach a chare array to the TCharm array, use:
 
-::
+.. code-block:: c++
 
   CkArrayOptions TCHARM_Attach_start(CkArrayID *retTCharmArray,int
   *retNumElts)
@@ -569,7 +569,7 @@ The overall scheme for writing a TCharm-based library "Foo" is:
    context because a TCharm::semaGet blocks if a local TCharm::semaGet
    hasn’t yet executed.
 
-   ::
+   .. code-block:: c++
 
       //This is either called by FooFallbackSetuo mentioned above, or by the user
       //directly from TCHARM_User_setup (for multi-module programs)
@@ -591,7 +591,7 @@ The overall scheme for writing a TCharm-based library "Foo" is:
    design is to avoid the Ctv, and instead hand the user an opaque
    handle that includes your array proxy.
 
-   ::
+   .. code-block:: c++
 
       //_fooptr is the Ctv that points to the current chunk FooChunk and is only valid in
       //routines called from fooDriver()
@@ -605,7 +605,7 @@ The overall scheme for writing a TCharm-based library "Foo" is:
 
 #. Define the array used by the library
 
-   ::
+   .. code-block:: c++
 
       class FooChunk: public TCharmClient1D {
          CProxy_FooChunk thisProxy;
@@ -638,7 +638,7 @@ The overall scheme for writing a TCharm-based library "Foo" is:
 #. Block a thread for communication using thread->suspend and
    thread->resume
 
-   ::
+   .. code-block:: c++
 
       int FooChunk::doCommunicate(...)
       {
@@ -678,7 +678,7 @@ The overall scheme for writing a TCharm-based library "Foo" is:
    the user passes you an index-the int index will need to be
    decremented before use, or incremented before a return.
 
-   ::
+   .. code-block:: c++
 
       CLINKAGE void FOO_Communicate(int x, double y, int * arr) {
          TCHARM_API_TRACE("FOO_Communicate", "foo"); //2nd parameter is the name of the library