Somehow the code in COPASI.R that is generated by SWIG does not work very well with enumerations.
The enumerations as in CModel::TimeUnit are converted to string in R. So if one calls CModel_getTimeUnitEnum(model) where model is an external pointer to a CModel instance, you get a string that describes the time unit, e.g. "s".

According to the rather short SWIG documentation on R and enumerations, this should also work the other way round, so calling CModel_setTimeUnit(model,"s") should set the time unit for the model to seconds. The code that SWIG generated is supposed to convert the string to the corresponding enum.

Although this translation code is there, is contains a bug (at least in SWIG 2.0.4 and 1.3.40) because it calls the enumToInteger function with "_p_CModel__TimeUnit" as the argument instead of "_CModel__TimeUnit". Since SWIG defines the enums in .__E___CModel__TimeUnit and not ".__E___p_CModel__TimeUnit", this leads to an error during execution.

This problem can be fixed if one fixes all the methods in COPASI.R that set an enum, which is rather cumbersome.

Modifying COPASI.R with
:%s/enumToInteger\(.*\)"_p/enumToInteger\1"/
in vim should fix all occurences of this problem.

The way enums are translated in the R language bindings could also lead to problems if enum names are not unique throughout all classes. Currently I am not aware of any enums that are duplicated in different classes and that have different integer representations.

-> This has actually been fixed with a new typemap in R.i, so search and replace in COPASI.R is no longer necessary.

The way enums are translated in the R language bindings could also lead to problems if enum names are not unique throughout all classes. Currently I am not aware of any enums that are duplicated in different classes and that have different integer representations.

-> No it doesn't because it is handled in a class specific manner.

----------------------------------------------------------------------

SWIG 1.3.40 also seems to have problems with the creation of R string from std::string.
It uses a call to allocVector(CHARSXP ...) which doesn't seem to work anymore starting with R version 2.8.

-> This seems to be fixed in SWIG 2.0.4.

-----------------------------------------------------------------------

Building R bindings under linux (Ubuntu 11.04) also leads to the problem that the development packages for lapack get installed which conflict with the CLAPACK I am normally using to compile COPASI.
This is actually a problem of our build system (or more specifically a limit of gcc and other compilers that you can't really fix the search order of header file directories).
There are several ways to fix this. The cleanest would be to check the include paths that were specified and to put the one that points to something general like /usr/include, /opt/include or /usr/local/include at the end. This way more specific paths would be searched first.

Another way of fixing this is to not use any libraries that come packaged with the system, but to compile all dependencies yourself. This way /usr/include will hopefully not appear in the include path. Also using a version of R that was compiled from the sources and is installed in a more specific location could help.

-> I changed the build system a bit and compiling with the system lapack works quite well if C_INT in copasi.h is adjusted to be the same type as integer from f2c.h
-> Additionally g2c has to be replaced by f2c in common.pri and I actually had to replace f2c by -Wl,-Bstatic -lf2c -Wl,-Bdynamic to make sure f2c was linked statically because the dynamic version was complaining a bout missing reference to __MAIN. There are other ways to solve this, but this seemed easiest

---------------------------------------------------------------------
Since R compiles the sources itself, it determines the compiler flags, which at least in the case of Ubuntu 11.04 uses -O3 to compile the sources.
Using optimizations greater than O1 have lead to problems with the resulting binaries for SWIG generated code before, so this also might be a problem that needs to be fixed.

-> to use a different set of compiler options, one can create a directory called .R in the home directory and create a file called Makevars in that directory. In set file CFLAGS, CXXFLAGS etc can be set. There are probably other solutions as well which work better with qmake, but for now this is all I need for debugging.
-----------------------------------------------------------------------

At least the 64bit bindings for R seem to have problems with methods that take size_t as the index.
The wrapped functions expect an object that is derived from size_t and the program will stop if it just finds a numerical value.

-> this is again a problem with passing references to function. Adding a typemap to R.i that tells SWIG to treat size_t as "numeric" just like the other integer references solves this (see rtype.swg in the SWIG distribution). 

------------------------------------------------------------------------

Somehow calling setFunction on a CReaction instance with an object that is a wrapped 
CEvaluationTree pointer as e.g. returned by CFunctionDB_findFunction does not work because
the code that SWIG generates can not determine that the underlying C++ object is actually a
CFunction pointer.

Normally the code generated by SWIG for R language bindings seems to be able
to handle the upcasting to the most specific type quite well without any
additional typemaps. At least in one small example that I wrote to debug this
problem, it worked.
I suspect that the multiple inheritance that we use in COPASI throws SWIG off.

