Thanks for the heads up. Fixed -- sorry about that.
> On Jul 4, 2015, at 12:11 PM, George Bosilca wrote:
>
> On OS X the generating the MPI library fails with the following error message:
>
> duplicate symbol _ompi_buffer_detach_f08 in:
> .libs/buffer_detach_f.o
> profile/.libs/libmpi
Thankfully, I didn't understand it. :-)
> On Feb 20, 2015, at 2:49 PM, Paul Hargrove wrote:
>
>
>INTEGER JEFF(3)
>DATA JEFF/4HMR. ,4HFORT,3HRAN/
>
> If you can understand that, you should probably pretend you can't :-)
>
> -Paul [who has actually used Computed GO TO and Arith
Good grins. Thanks Paul.
Larry Baker
US Geological Survey
650-329-5608
ba...@usgs.gov
On 20 Feb 2015, at 11:49 AM, Paul Hargrove wrote:
>
>INTEGER JEFF(3)
>DATA JEFF/4HMR. ,4HFORT,3HRAN/
>
> If you can understand that, you should probably pretend you can't :-)
>
> -Paul [wh
INTEGER JEFF(3)
DATA JEFF/4HMR. ,4HFORT,3HRAN/
If you can understand that, you should probably pretend you can't :-)
-Paul [who has actually used Computed GO TO and Arithmetic IF]
On Fri, Feb 20, 2015 at 11:28 AM, Larry Baker wrote:
> Excellent, Mr. Fortran. Thank you.
>
> By th
Excellent, Mr. Fortran. Thank you.
By the way, I meant to write Branch ON Low Bit Set/Clear.
Larry Baker
US Geological Survey
650-329-5608
ba...@usgs.gov
On 20 Feb 2015, at 11:22 AM, Jeff Squyres (jsquyres) wrote:
> On Feb 20, 2015, at 2:12 PM, Larry Baker wrote:
>>
>> Beware, this has/may
On Feb 20, 2015, at 2:12 PM, Larry Baker wrote:
>
> Beware, this has/may not always be the case. This is due to C's historical
> confusion/misuse of integers as boolean data types. On VAX hardware, the low
> bit was the only significant part of a Fortran LOGICAL data type, owing to
> the arc
On 20 Feb 2015, at 3:09 AM, Gilles Gouaillardet wrote:
> George,
>
> this is correctly handled in ompi_testany_f :
>
> /* Increment index by one for fortran conventions. Note that
>all Fortran compilers have FALSE==0; we just need to check
>for any nonzero value
On Feb 20, 2015, at 10:01 AM, George Bosilca wrote:
>
> Great. Using grep I couldn't find how this is handled anywhere in the source
> directory. But it seems to me that the Fortran layer is now way more
> complicated than I initially thought.
Fortran is your friend.
(repeat until you believe
Great. Using grep I couldn't find how this is handled anywhere in the
source directory. But it seems to me that the Fortran layer is now way more
complicated than I initially thought.
George.
On Fri, Feb 20, 2015 at 8:27 AM, Jeff Squyres (jsquyres) wrote:
> Gilles is correct. The same kind
Gilles is correct. The same kind of increment happens in all the test/wait
Fortran code that returns indexes.
"Mr. Fortran"? Ouch. :-)
> On Feb 20, 2015, at 6:09 AM, Gilles Gouaillardet
> wrote:
>
> George,
>
> this is correctly handled in ompi_testany_f :
>
> /* Increment index
George,
this is correctly handled in ompi_testany_f :
/* Increment index by one for fortran conventions. Note that
all Fortran compilers have FALSE==0; we just need to check
for any nonzero value (because TRUE is not always 1) */
Cheers,
Gilles
On 2015/02/20 1:15
Sorry but I miss the connection between this test and the issue of TestAny
in Fortran?
On Thu, Feb 19, 2015 at 2:00 PM, Dave Goodell (dgoodell) wrote:
> On Feb 19, 2015, at 10:15 AM, George Bosilca wrote:
>
> > While looking the MPI_Testany issue, I came across a very unsettling
> sentence in
On Feb 19, 2015, at 10:15 AM, George Bosilca wrote:
> While looking the MPI_Testany issue, I came across a very unsettling sentence
> in the MPI standard (3.0 page 58 line 36).
>
> > The array is indexed from zero in C, and from one in Fortran.
>
> This sentence seems to indicate that the inde
13 matches
Mail list logo
