On Tue, 4 Nov 2014 09:12:51 +0100
Øyvind Evju <[email protected]> wrote:
> Thanks, Johan, but the error still persist. And thank for the neat
> trick, Jan, but that also doesn't solve this specific issue.
Don't know if it helps here but you may need to use the pattern like
// typemaps
#ifdef SWIG
%include "petsc4py/petsc4py.i"
#endif
// includes
#include ...
namespace dolfin {
// your code
}
otherwise compile_extension_module wraps whole code to namespace
dolfin {} block thus moving #included code to dolfin namespace which
was not expected.
Jan
>
>
> -Øyvind
>
>
> 2014-11-03 17:11 GMT+01:00 Jan Blechta <[email protected]>:
>
> > BTW, you can add any typemap missed by DOLFIN by adding something
> > like
> >
> > #ifdef SWIG
> > %include "petsc4py/petsc4py.i"
> > #endif
> >
> > or in this case
> >
> > #ifdef SWIG
> > %include "dolfin/swig/common/pre.i"
> > #endif
> >
> > to your extension code.
> >
> > Jan
> >
> >
> > On Mon, 3 Nov 2014 16:40:16 +0100
> > Johan Hake <[email protected]> wrote:
> >
> > > Could you check if it is fixed with this branch?
> > >
> > > johanhake/fix-swig-common-include
> > >
> > > You probably need to remove all compiled extension modules from
> > > the cache.
> > >
> > > rm -rf ~/.instant/cache/dolfin_*
> > >
> > > Johan
> > >
> > > On Mon, Nov 3, 2014 at 4:28 PM, Øyvind Evju <[email protected]>
> > > wrote:
> > >
> > > > Great :)
> > > >
> > > >
> > > > -Øyvind
> > > >
> > > > 2014-11-03 16:26 GMT+01:00 Johan Hake <[email protected]>:
> > > >
> > > >> No it is not :)
> > > >>
> > > >> It is included using #include but not %include.
> > > >>
> > > >> I can push a fix for this.
> > > >>
> > > >> Johan
> > > >>
> > > >> On Mon, Nov 3, 2014 at 4:22 PM, Øyvind Evju <[email protected]>
> > > >> wrote:
> > > >>
> > > >>> Yes, it is.
> > > >>>
> > > >>>
> > > >>> -Øyvind
> > > >>>
> > > >>> 2014-11-03 16:09 GMT+01:00 Johan Hake <[email protected]>:
> > > >>>
> > > >>>> Can you check
> > > >>>>
> > > >>>> if dolfin/swig/common/pre.i
> > > >>>>
> > > >>>> is included in the generated
> > > >>>>
> > > >>>> .instant/cache/dolfin_compile_code_XXX/dolfin_compile_code_XXX.i
> > > >>>>
> > > >>>> file? In that file we include tghe petsc4py.i with all the
> > > >>>> relevant typesmaps. So if we do not include that file we
> > > >>>> probably should :)
> > > >>>>
> > > >>>> Johan
> > > >>>>
> > > >>>> On Mon, Nov 3, 2014 at 3:52 PM, Øyvind Evju
> > > >>>> <[email protected]> wrote:
> > > >>>>
> > > >>>>> When petsc4py is installed, the mpi_comm_world-function
> > > >>>>> returns a petsc4py.PETSc.Comm-object. I guess this is true
> > > >>>>> for all MPI communicators. When writing an extension module
> > > >>>>> using a MPI_Comm as argument, this fails.
> > > >>>>>
> > > >>>>> MWE:
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>> *from dolfin import *cpp_module="""void foo(MPI_Comm comm)
> > > >>>>> {}"""compiled_module =
> > > >>>>>
> > compile_extension_module(cpp_module)compiled_module.foo(mpi_comm_world())*
> > > >>>>>
> > > >>>>> I guess this is related to this:
> > > >>>>>
> > https://bitbucket.org/fenics-project/dolfin/issue/195/petsc4py-applies-own-typemap-for-mpi_comm
> > > >>>>>
> > > >>>>> Any way to work with this?
> > > >>>>>
> > > >>>>>
> > > >>>>> -Øyvind
> > > >>>>>
> > > >>>>>
> > > >>>>> _______________________________________________
> > > >>>>> fenics mailing list
> > > >>>>> [email protected]
> > > >>>>> http://fenicsproject.org/mailman/listinfo/fenics
> > > >>>>>
> > > >>>>>
> > > >>>>
> > > >>>
> > > >>
> > > >
> >
> >
_______________________________________________
fenics mailing list
[email protected]
http://fenicsproject.org/mailman/listinfo/fenics
