Re: [OMPI devel] RFC: Move of ompi_bitmap_t

Thanks - very helpful. Rich On 1/30/09 4:59 PM, "Ralph Castain" wrote: > The history is simple. Originally, there was one bitmap_t in orte that > was also used in ompi. Then the folks working on Fortran found that > they had to put a limit in the bitmap code to avoid getting

Re: [OMPI devel] RFC: Move of ompi_bitmap_t

The history is simple. Originally, there was one bitmap_t in orte that was also used in ompi. Then the folks working on Fortran found that they had to put a limit in the bitmap code to avoid getting values outside of Fortran's range. However, this introduced a problem - if we had the limit

Re: [OMPI devel] RFC: Move of ompi_bitmap_t

This should really be viewed as a code maintenance RFC. The reason this came up in the first place is because we are investigating the btl move, but these are really two very distinct issues. There are two bits of code that have virtually the same functionality - they do have the same interface

Re: [OMPI devel] Change of API in mpool

I think this fits into the same category of objections as to the other RFC - it should be done in the tmp branch and held there until the entire concept is validated. In this case, my concern would focus solely on the question of conversion time. Somewhere up the chain, somebody is passing

Re: [OMPI devel] RFC: Move of ompi_bitmap_t

I second Brian's concern. So unless this is just an announcement that this is being done on a tmp branch only until everything is in order I think we need further discussions. --td Brian Barrett wrote: So once again, I bring up my objection of this entire line of moving until such time as

Re: [OMPI devel] RFC: Move of ompi_bitmap_t

So once again, I bring up my objection of this entire line of moving until such time as the entire process is properly mapped out. I believe it's premature to being moving around code in preparation for a move that hasn't been proven viable yet. Until there is concrete evidence that such

[OMPI devel] RFC: Move of ompi_bitmap_t

On behalf of Laurent Broto RFC: Move of ompi_bitmap_t WHAT: Move ompi_bitmap_t into opal or onet-layer WHY: Remove dependency on ompi-layer. WHERE: ompi/class WHEN: Open MPI-1.4 TIMEOUT: February 3, 2009. - Details: WHY: The ompi_bitmap_t is being used

[OMPI devel] Change of API in mpool

Send yet again... RFC: Change of API in mpool WHAT: Remove dependency on ompi_info_t in mca_mpool_base_alloc WHY: To be able to move mpool out of the ompi-layer. WHERE: Changes just in the mpool and in ompi/mpi/c/alloc_mem.c WHEN: Open MPI-1.4 TIMEOUT: February 3, 2009.

Re: [OMPI devel] RFC: make predefined handles extern to pointers

After some more experiments I found my issue below wasn't due to the definitions but due to how I was compiling my sources. So it turns out that I get the same results from dbx when accessing an MPI_Comm type whether using the original trunk source or using the struct padding. Which makes

Re: [OMPI devel] [OMPI svn-private] svn:open-mpi r20380

Tim Mattox, Thanks for your very good suggestion; I will make sure that the author of that script incorporates it. It is possible he may not have a history of using Subversion and may not have understood the significance. Since ORNL now has four people working on the BTL move project (cf.,