.. we can register routines when embedding via the
R_getEmbeddingDLLInfo()
.. so we just register our functions directly now
in RTool rather than needing a dynamic library.
.. its cleaner and there are no nasty casts and build
settings required
.. reimplemented with native R API
.. switched to .Call in R function since .C means all functions
return void and must return by a pass by reference parameter.
.. its not needed as the workaround of using an extern "C" function
to perform the function pointer cast conforms to standard.
.. this just simplifies src.pro that was getting heavy
.. fixup R SHLIB build and integration to work on OSX
**** WARNING ****
If you build for OSX with GC_WANT_R You will need to
manually copy RGoldenCheetah.so into the app bundle.
$ cp RGoldenCheetah.so ./GoldenCheetah.app/Contents/MacOS
*****************
.. phew. that was hard.
.. To register routines with R you need to place them in a shared
library.
.. The routines we want to register are part of the GC codebase so
cannot be linked into that shared library (it would be the whole
of GC).
.. So; we have a shared library (RGoldenCheetah.cpp) which has stubs
for all the registered functions and an array of pointers to the
actual functions.
.. We load the library (once R is embedded it is loaded in main.cpp)
.. After the library is loaded we then call one of its public
functions (GCInitialiseFunctions) to tell it where all the GC
functions are (we only have GCdisplay at present for this proof
of the concept).
.. Along the way we need to deref/cast DL_FUNC in RTool.cpp which
is not permitted in ISO C, so we also update qmake to add a
special rule to compile `dodgy' sources with -fpermissive. And
the only dodgy source is RTool.cpp.
.. This commmit will break GC_WANT_R builds on OSX, and will be
fixed up shortly.
.. The motivation behind this is to avoid RInside/Rcpp for Windows
builds -- enabling R support (which is not currently possible).
.. to use the R C API for to avoid use of Rcpp and RInside
.. the shlib doesn't do anything and isn't loaded in RTool
at this point. Need to get this working cross-platform
and iron out the build time nits.
.. so don't even try to build and warn via qmake
.. RInside/Rcpp do not suport MSVC
.. Microsoft Open R may help, but doesn't at this point
.. we can revisit at a later date.
.. not complete, but we now have a canvas (QGraphicsView)
to plot the R output without needing to use x11() or
quartz(), window() etc.
.. the primitives do not honour the graphic engine context so
all lines etc are white on black.
.. will fix and improve in followup commits, need to test
with QT4.8 and cross-platform.
.. since the R runtime is shared by charts we offer the ability
to prefix variables with $$ to ensure they don't conflict
across multiple RCharts.
.. $$d <- GC.activity() would actually be parsed within R as
gc0d <- GC.activity(). The next chart would get gc1 and so
on.
.. it is optional, so charts could share data structures (but
wonder why you might do that)
.. we still need to encapsulate the code to plot within a
script to ensure it is refreshed when the chart is selected
or underlying data changes.
.. believe it or not the R base code for plot (plot.c)
skipped plotting circles if they were white on white.
.. took me 4 hours to fix this by setting startcol and
startfill in DevDesc for the device.
.. But at least the R driver now works properly -- we can
now integrate with a qt widget.
.. the R graphics device now gets called for hist() so we can
work on the interaction with a QT widget now.
.. still have other problems to deal with (!)
.. GoldenCheetahGD is instantiated
.. GC.display() to create new GD
GC.activate() to activate the GD
NOTE: a fair amount of qDebug() in at present as
the graphics functions are being created.
