Swig Instant Notes

Miscellaneous Notes

• Need Swig version > 1.3.29 otherwise will get compilation errors of: error: invalid conversion from ‘const char*’ to ‘char*’

• Investigate bug, that after not being able to import a material model, we seem to be unable to compile that material model, but are able to when restarting Continuity without trying to import that material model

Making manual changes to the generated C/C++ files

• If you want to make any local edits to an auto-generated C/C++ file, like adding debug prints, you will need to edit the *.i file created by Swig.

• By default, that file will be in .continuity/dynamicBinaries/<modelType>/<TheModelYouHaveAleadyCompiled>, and will be named something like: contmodel_55332f6a8b5631ee0fc3f33a3516206f.i.

• The *.i file will contain the full raw source listing as generated by Continuity in addition to other things required by Swig.
• After making the necessary edits to the *.i file, you will need to recompile the file to generate the new binary to be able to have your changes take effect when you run Continuity.
• You first need to make sure that the version of Python you are using is the same as for Continuity, so for Linux/Mac you need to do ‘source mglinit’. For Windows you need to make sure the proper Python is defined in your Path variable.
• After ensuring you are running the proper version of Python run:

   python setup.py build
  

   

• This will compile the new binary file and put it into the .continuity/dynamicBinaries/<modelType>/<TheModelYouHaveAleadyCompiled>/build/lib* directory.

• You then need to copy that new binary file to overwrite the existing binary in .continuity/dynamicBinaries/<modelType>/<TheModelYouHaveAleadyCompiled>

Upgrading Instant

• Instant is currently being including the mgltools zip file, and therefore, all of the individual files are not under any source control. This makes it a bit cumbersome to keep track of local edits, and hence we need to be careful when upgrading.
• There are currently 3 files that are edited: build.py, codegeneration.py and output.py
• build.py (recompile method) — We need to have Windows use the mingw32 compiler

    if 'win32' in sys.platform:
        cmd = "python %s build_ext -c mingw32 install --install-platlib=." % setup_name
    else:
        cmd = "python %s build_ext install --install-platlib=." % setup_name

• codegeneration.py (write_setup method) — We need to account for spaces in paths when looking for Swig

    import sys
    if 'win32' in sys.platform:
        import win32api
        swig_include_dirs.append(os.path.join(win32api.GetShortPathName(os.path.dirname(__file__)), 'swig'))
    else:
        swig_include_dirs.append(os.path.join(os.path.dirname(__file__), 'swig'))

• output.py (instant_error method) — Seems to be a bug when displaying the error

     if len(message) > 1:
         text = message[0] % message[1:]
     else:
         text = message[0]

Adding New C Functions

• If the need arises to add a new Python call to a C function the following will outline the process.
• Firstly, put the source code in the Continuity tree where you want it, preferably somewhere under src/csrc. It is recommended that your C function be of type void, and simply pass in the variable(s) that will be assigned the result.
• Get Swig and Instant to compile that code.
• You will need to write the instructions for Swig and Instant on how you need your C function to be compiled, which includes any additional libraries/includes required.

• The easiest way to do this is by looking at an existing example, so please see pcty/cont_classes/BuildSuperluInterface.py (which exists as of svn version 7608). This file compiles the code in /src/csrc/superlu_dgssv_mod.c.

• Most of the things should be self explanatory in the file, and it likely will not need significant modification. The main area to examine is where it defines the additional_declarations variable, as that is defining the types of C variables your function is expecting.

• As seen in the BuildSuperluInterface.py file, all the variable types are defined in cont_classes/InstantHelper, so should there not be a variable type needed, one needs to be added to that file in the same manner as the others.

• It should be made clear that the way we are passing the variables is simply by using pointers and we are not doing any boundary checking on them, so it is up to the C code to not access any memory beyond what each variable has allocated.

• Currently the way we are building any Swig/Instant binaries is by including the call into the <CONT_ROOT>/dynamicMake.py file. This file gets called at the end of compiling all of Continuity, so you can ensure that your C code will be compiled when needed when compiling Continuity. However, you can also just run python dynamicMake.py from CONT_ROOT and compile your code separately from the rest of Continuity.

• If you search dynamicMake for BuildSuperluInterface, you will see there are only 4 lines added to that file.

• When calling your C function from Python, nothing special needs to be done other than importing the binary and making sure the variables that you are passing to the C code are of the proper type, generally all numpy variables/arrays of either int or double type.
• You will also need to update pcty/form/updateServerBinaries.py to have your binary copied into the proper location under pcty, probably pcty/server. Search updateServerBinaries for superluBinaries to see how it was handled for that binary.
• Lastly, when everything works as expected check in all your code, including the binaries where then get built (e.g., winlib), not from where they get copied to (e.g., pcty/server)