On Thu, 4 Dec 2008, Maxime Debon wrote:
> By now, the objective is to call this or another library from R front end.
>
> I truely think it's possible to make a link between these tools but there is
> a constraint with libmesh::init(argc, argv). This last function is now
> deprecated but the initialisation problem remains the same.
>
> R extension with C or C++ code could be declared this way :
> ___________________________________________
>
> double foo(double A, double B) { return A+B; };
>
> extern "C" {
> void foo_R(double* output, double* A, double* B){
> *output = foo(*A,*B);
> };
> }
> ___________________________________________
>
> With non libmesh code, this is fine
>
> The question is :
>
> How and where should libmesh::init(argc, argv) be called if foo depends on
> libMesh ?
I've never used R, but this bit of the manual seems to apply:
"Various R functions in a package can be used to initialize and clean
up. For packages without a name space, these are .First.lib and
.Last.lib. (See Load hooks, for packages with a name space.) It is
conventional to define these functions in a file called zzz.R"
Allocate a singleton LibMeshInit object in the initialization function
and destroy it in the clean up function.
> May be argc and argv could be fakes.
They can be fakes as far as we're concerned; just make argc=0 and
GetPot will be happy with even a NULL argv. Your MPI implementation
and PETSc might be stricter.
---
Roy
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Libmesh-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libmesh-users
