Hi Josh,
thanks for the info. Was about to look at this mail...
Have just asked Jeff to plz readd ,-)
Is Oracle / Sun not part of OMPI anymore?
CU,
Rainer
On 15.07.2013, at 21:24, Jeff Squyres (jsquyres) wrote:
> You've been re-added.
>
> Thanks!
>
>
> On Jul 15, 2013, at 3:23 PM, Steve
Terry is dropping his account due to change in "day job"
responsibilities. I'm retaining mine. Oracle status is changing from
member to contributor.
On 7/16/2013 12:16 AM, Rainer Keller wrote:
Hi Josh,
thanks for the info. Was about to look at this mail...
Is Oracle / Sun not part of OMPI a
What: Add support for the MPI-3 MPI_Count datatype and functions:
MPI_Get_elements_x, MPI_Status_set_elements_x, MPI_Type_get_extent_x,
MPI_Type_get_true_extent_x, and MPI_Type_size_x. This will be CMR'd to 1.7.3 if
there are no objections.
Why: MPI_Count is required by the MPI 3.0 standard. Th
Nathan,
I read your code and it's definitively looking good. I have however few minor
issues with your patch.
1. MPI_Aint is unsigned as it must represent the difference between two memory
arbitrary locations. In your MPI_Type_get_[true_]extent_x you go through size_t
possibly reducing it's ex
On Jul 16, 2013, at 4:22 PM, George Bosilca wrote:
> Btw, I have a question to you fellow MPI Forum attendees. I just can't
> remember why the MPI forum felt there was a need for the
> MPI_Type_get[_true]_extent_x? MPI_Count can't be bigger than MPI_Aint,
Yes, it can -- it has to be the larges
On Jul 16, 2013, at 3:22 PM, George Bosilca wrote:
> I read your code and it's definitively looking good. I have however few minor
> issues with your patch.
>
> 1. MPI_Aint is unsigned as it must represent the difference between two
> memory arbitrary locations. In your MPI_Type_get_[true_]ext
It's a typo, MPI_Aint is of course unsigned.
George.
On Jul 16, 2013, at 22:37 , David Goodell (dgoodell) wrote:
> On Jul 16, 2013, at 3:22 PM, George Bosilca wrote:
>
>> I read your code and it's definitively looking good. I have however few
>> minor issues with your patch.
>>
>> 1. MPI_
On Tue, Jul 16, 2013 at 10:22:33PM +0200, George Bosilca wrote:
> Nathan,
>
> I read your code and it's definitively looking good. I have however few minor
> issues with your patch.
>
> 1. MPI_Aint is unsigned as it must represent the difference between two
> memory arbitrary locations. In your
I think you meant signed. It is signed in both configure.ac and
ompi_datatype_module.c.
-Nathan
On Tue, Jul 16, 2013 at 10:48:12PM +0200, George Bosilca wrote:
> It's a typo, MPI_Aint is of course unsigned.
>
> George.
>
> On Jul 16, 2013, at 22:37 , David Goodell (dgoodell)
> wrote:
>
>
On Jul 16, 2013, at 4:54 PM, Nathan Hjelm wrote:
>> 3. We had a policy that we only export one single MPI level function per
>> file in the mpi directory. You changed this as some of the files exports now
>> two function (the original function together with the _x version).
>
> I was trying to
On Jul 16, 2013, at 22:29 , Jeff Squyres (jsquyres) wrote:
> On Jul 16, 2013, at 4:22 PM, George Bosilca wrote:
>
>> Btw, I have a question to you fellow MPI Forum attendees. I just can't
>> remember why the MPI forum felt there was a need for the
>> MPI_Type_get[_true]_extent_x? MPI_Count c
On Tue, Jul 16, 2013 at 10:22:33PM +0200, George Bosilca wrote:
> Nathan,
>
> I read your code and it's definitively looking good. I have however few minor
> issues with your patch.
>
> 1. MPI_Aint is unsigned as it must represent the difference between two
> memory arbitrary locations. In your
Apparently I just can't type that freaking word. Thanks Nathan for pointing out
the truth ;)
George.
On Jul 16, 2013, at 22:56 , Nathan Hjelm wrote:
> I think you meant signed. It is signed in both configure.ac and
> ompi_datatype_module.c.
>
> -Nathan
>
> On Tue, Jul 16, 2013 at 10:48:12
On Jul 16, 2013, at 5:03 PM, George Bosilca wrote:
>> Yes, it can -- it has to be the largest integer type (i.e., it even has to
>> be able to handle an MPI_Offset).
>
> Technicalities! In the entire standard MPI_Offset is only used to access
> files, not to build datatypes. As such there is n
On Jul 16, 2013, at 23:03 , Nathan Hjelm wrote:
> On Tue, Jul 16, 2013 at 10:22:33PM +0200, George Bosilca wrote:
>> Nathan,
>>
>> I read your code and it's definitively looking good. I have however few
>> minor issues with your patch.
>>
>> 1. MPI_Aint is unsigned as it must represent the di
On Tue, Jul 16, 2013 at 11:03:27PM +0200, George Bosilca wrote:
>
> On Jul 16, 2013, at 22:29 , Jeff Squyres (jsquyres)
> wrote:
>
> > On Jul 16, 2013, at 4:22 PM, George Bosilca wrote:
> >
> >> Btw, I have a question to you fellow MPI Forum attendees. I just can't
> >> remember why the MPI
On Jul 16, 2013, at 4:03 PM, George Bosilca
wrote:
> On Jul 16, 2013, at 22:29 , Jeff Squyres (jsquyres)
> wrote:
>
>> On Jul 16, 2013, at 4:22 PM, George Bosilca wrote:
>>
>>> Btw, I have a question to you fellow MPI Forum attendees. I just can't
>>> remember why the MPI forum felt there
On Jul 16, 2013, at 23:07 , "Jeff Squyres (jsquyres)"
wrote:
> On Jul 16, 2013, at 5:03 PM, George Bosilca wrote:
>
>>> Yes, it can -- it has to be the largest integer type (i.e., it even has to
>>> be able to handle an MPI_Offset).
>>
>> Technicalities! In the entire standard MPI_Offset is
On Tue, Jul 16, 2013 at 11:08:32PM +0200, George Bosilca wrote:
>
> On Jul 16, 2013, at 23:03 , Nathan Hjelm wrote:
>
> > On Tue, Jul 16, 2013 at 10:22:33PM +0200, George Bosilca wrote:
> >> Nathan,
> >>
> >> I read your code and it's definitively looking good. I have however few
> >> minor is
Er... changing that value will have ABI implications... :-(
On Jul 16, 2013, at 5:12 PM, Nathan Hjelm wrote:
> Ugh, that isn't what I wanted to hear. MPI_Count can have the value of
> MPI_UNDEFINED which we define as -32766. Do we have to redefine this value to
> ensure there are no problems?
On Jul 16, 2013, at 23:11 , "David Goodell (dgoodell)"
wrote:
> On Jul 16, 2013, at 4:03 PM, George Bosilca
> wrote:
>
>> On Jul 16, 2013, at 22:29 , Jeff Squyres (jsquyres)
>> wrote:
>>
>>> On Jul 16, 2013, at 4:22 PM, George Bosilca wrote:
>>>
Btw, I have a question to you fellow
I would like to question the choice for the new … spartan ompi_info output? I
would not mind restoring the default behavior, aka. have a verbose "--all",
instead of some [random] MCA params.
Btw, something is wrong i the following output. I have an "btl = sm,self" in my
.openmpi/mca-params.conf
On Jul 16, 2013, at 6:04 PM, George Bosilca wrote:
> I would like to question the choice for the new … spartan ompi_info output?
I won't debate the logic - I'll leave that to Jeff and Nathan
> I would not mind restoring the default behavior, aka. have a verbose "--all",
> instead of some [ran
On the trunk:
pml_ob1_component.c: In function 'mca_pml_ob1_component_register':
pml_ob1_component.c:207: warning: passing argument 12 of
'mca_base_pvar_register' from incompatible pointer type
pml_ob1_component.c:213: warning: passing argument 12 of
'mca_base_pvar_register' from incompatible po
24 matches
Mail list logo
