Re: [OMPI devel] MPI_Win_get_group

On 8/1/07, Jeff Squyres wrote: > BTW, I totally forgot to mention a notable C++ MPI bindings project > that is the next-generation/successor to OMPI: the Boost C++ MPI > bindings (boost.mpi). > > http://www.generic-programming.org/~dgregor/boost.mpi/doc/ > > I believe there's also python bind

Re: [OMPI devel] MPI_Win_get_group

On 8/6/07, Jeff Squyres wrote: > On Aug 6, 2007, at 2:42 PM, Lisandro Dalcin wrote: > > Because many predefined, intrinsic objects cannot (or should not be > > able to) be freed, acording to the standard. > > I understand that. :-) But why would you call XXX.Free() on an > intrinsic object? If

Re: [OMPI devel] MPI_Win_get_group

On Aug 6, 2007, at 2:42 PM, Lisandro Dalcin wrote: having to call XXX.Free() for every object i get from a call like XXX.Get_something() is really an unnecesary pain. Gotcha. But I don't see why this means that you need to know if an MPI handle points to an intrinsic object or not...? Beca

Re: [OMPI devel] MPI_Win_get_group

On 8/1/07, Jeff Squyres wrote: > On Jul 31, 2007, at 6:43 PM, Lisandro Dalcin wrote: >> having to call XXX.Free() for every > > object i get from a call like XXX.Get_something() is really an > > unnecesary pain. > > Gotcha. > > But I don't see why this means that you need to know if an MPI handle

Re: [OMPI devel] MPI_Win_get_group

BTW, I totally forgot to mention a notable C++ MPI bindings project that is the next-generation/successor to OMPI: the Boost C++ MPI bindings (boost.mpi). http://www.generic-programming.org/~dgregor/boost.mpi/doc/ I believe there's also python bindings included...? On Aug 1, 2007, at

Re: [OMPI devel] MPI_Win_get_group

On Jul 31, 2007, at 6:43 PM, Lisandro Dalcin wrote: I am working in the development of MPI for Python, a port of MPI to Python, a high level language with automatic memory management. Said that, in such an environment, having to call XXX.Free() for every object i get from a call like XXX.Get_so

Re: [OMPI devel] MPI_Win_get_group

On 7/31/07, Jeff Squyres wrote: > Just curious -- why do you need to know if a handle refers to a > predefined object? If I understand correctly, new handles shoud be freed in order to do not leak things, to follow good programming practices, and being completelly sure a valgrind run do not repor

Re: [OMPI devel] MPI_Win_get_group

On Jul 31, 2007, at 4:52 PM, Lisandro Dalcin wrote: In general, I think MPI standard should be fixed/clarified in many places regarding to handling of returned references. Testing for predefined Comm a Group handling is rather easy, but for Datatypes is really cumbersome. Perhaps a MPI_Type_is_n

Re: [OMPI devel] MPI_Win_get_group

On 7/31/07, Dries Kimpe wrote: > The MPI_File_get_view description in the standard has some issues related > to copies and named datatypes: > > see > http://www-unix.mcs.anl.gov/~gropp/projects/parallel/MPI/mpi-errata/discuss/fileview/fileview-1-clean.txt Indeed, your comment was exactly the sour

Re: [OMPI devel] MPI_Win_get_group

* Lisandro Dalcin [2007-07-30 18:19:21]: > On 7/30/07, George Bosilca wrote: > > In the data-type section there is an advice to implementors that > > state that a copy can simply increase the reference count if > > applicable. So, we might want to apply the same logic here ... > BTW, you just

Re: [OMPI devel] MPI_Win_get_group

On 7/30/07, George Bosilca wrote: > In the data-type section there is an advice to implementors that > state that a copy can simply increase the reference count if > applicable. So, we might want to apply the same logic here ... BTW, you just mentioned other obscure case. Do this apply to NAMED d

Re: [OMPI devel] MPI_Win_get_group

In the data-type section there is an advice to implementors that state that a copy can simply increase the reference count if applicable. So, we might want to apply the same logic here ... george. On Jul 30, 2007, at 4:16 PM, Jeff Squyres wrote: On Jul 30, 2007, at 9:58 AM, Lisandro Dalc

Re: [OMPI devel] MPI_Win_get_group

On Jul 30, 2007, at 9:58 AM, Lisandro Dalcin wrote: In the mean time, I would prefer to follow the standard as close as possible. If not, some external, stupid test suite (like the one I have for mip4py) would report that OMPI is wrong about this point. What exactly are you testing for? Equal

Re: [OMPI devel] MPI_Win_get_group

On 7/29/07, Jeff Squyres wrote: > On Jul 28, 2007, at 4:41 PM, Lisandro Dalcin wrote: > > > In the mean time, I would prefer to follow the standard as close as > > possible. If not, some external, stupid test suite (like the one I > > have for mip4py) would report that OMPI is wrong about this poi

Re: [OMPI devel] MPI_Win_get_group

On Jul 28, 2007, at 4:41 PM, Lisandro Dalcin wrote: In the mean time, I would prefer to follow the standard as close as possible. If not, some external, stupid test suite (like the one I have for mip4py) would report that OMPI is wrong about this point. What exactly are you testing for? BTW,

Re: [OMPI devel] MPI_Win_get_group

On 7/28/07, Brian Barrett wrote: > In my opinion, we conform to the standard. We reference count the > group, it's incremented on call to MPI_WIN_GROUP, and you can safely > call MPI_GROUP_FREE on the group returned from MPI_WIN_GROUP. Groups > are essentially immutable, so there's no way I can

Re: [OMPI devel] MPI_Win_get_group

On Jul 28, 2007, at 6:27 AM, Jeff Squyres wrote: On Jul 27, 2007, at 8:27 PM, Lisandro Dalcin wrote: MPI_WIN_GET_GROUP returns a duplicate of the group of the communicator used to create the window. associated with win. The group is returned in group. Well, it seems OMPI (v1.2 svn) is not r

Re: [OMPI devel] MPI_Win_get_group

On Jul 27, 2007, at 8:27 PM, Lisandro Dalcin wrote: MPI_WIN_GET_GROUP returns a duplicate of the group of the communicator used to create the window. associated with win. The group is returned in group. Well, it seems OMPI (v1.2 svn) is not returning a duplicate, comparing the handles with == C

[OMPI devel] MPI_Win_get_group

The MPI-2 standard says (see bottom of ) MPI_WIN_GET_GROUP returns a duplicate of the group of the communicator used to create the window. associated with win. The group is returned in group. Pease, note the 'duplicate' ... Well, it