On Dec 4, 2013 12:07 PM, "Jeff Squyres (jsquyres)"
wrote:
[...]
> But in some ways, having uncompilable code is a *good* thing, because it
tells you exactly where you need to work on the architecture. Just
updating it to *compile* removes that safeguard -- will you
remember/re-find all those plac
All he is doing is pushing intermediate steps upstream to maintain contact and
gain familiarity. No harm done as the code isn't built by default.
Broader design discussion can take place as we understand the problems
Sent from my iPhone
> On Dec 4, 2013, at 12:07 PM, "Jeff Squyres (jsquyres)"
On Dec 4, 2013, at 11:29 AM, Ralph Castain wrote:
> Jeff - you are jumping way ahead. I already said this needs further work to
> resolve blocking. These patches (per Adrian's email) just makes things compile
Fair enough.
But in some ways, having uncompilable code is a *good* thing, because it
On Dec 4, 2013, at 1:55 PM, Orion Poplawski wrote:
> Ah, great. Apologies for not checking in svn..
No worries; bug reports from downstream packagers are always appreciated!
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_busine
On 12/04/2013 11:53 AM, Jeff Squyres (jsquyres) wrote:
Thanks Orion!
FWIW, we've already fixed this post-1.7.3; it'll be in the 1.7.4 release.
The code location for this opal_output() also moved; it's now in
btl_usnic_stats.c, if you care.
Ah, great. Apologies for not checking in svn..
-
Thanks Orion!
FWIW, we've already fixed this post-1.7.3; it'll be in the 1.7.4 release.
The code location for this opal_output() also moved; it's now in
btl_usnic_stats.c, if you care.
On Dec 4, 2013, at 12:32 PM, Orion Poplawski wrote:
> The attached patch fixes this issue.
>
>
>
The attached patch fixes this issue.
Original Message
Subject: [Bug 1037231] New: openmpi FTBFS if "-Werror=format-security" flag is
used
List-Post: devel@lists.open-mpi.org
Date: Tue, 03 Dec 2013 03:26:30 +
From: bugzi...@redhat.com
To: or...@cora.nwra.com
https://bugzi
Jeff - you are jumping way ahead. I already said this needs further work to
resolve blocking. These patches (per Adrian's email) just makes things compile
Lower your bar, dude :-)
Sent from my iPhone
> On Dec 4, 2013, at 8:07 AM, "Jeff Squyres (jsquyres)"
> wrote:
>
>> On Nov 25, 2013, at 9:
On Nov 25, 2013, at 9:59 AM, Adrian Reber wrote:
> diff --git a/ompi/mca/bml/r2/bml_r2_ft.c b/ompi/mca/bml/r2/bml_r2_ft.c
> index 1448c04..fc16452 100644
> --- a/ompi/mca/bml/r2/bml_r2_ft.c
> +++ b/ompi/mca/bml/r2/bml_r2_ft.c
> @@ -191,7 +191,7 @@ int mca_bml_r2_ft_event(int state)
>
>
+1 on this patch.
On Nov 25, 2013, at 9:59 AM, Adrian Reber wrote:
> From: Adrian Reber
>
> This patch fixes
>
> error: void value not ignored as it ought to be
>
> in the C/R code by ignoring the return value of functions which
> no longer return a value (only void).
>
> Signed-off-by: A
On 12/04/13 14:53, Jeff Squyres (jsquyres) wrote:
On Dec 4, 2013, at 4:31 AM, Paul Kapinos wrote:
Argh - what a shame not to see "btl:usnic" :-|
What a shame you don't have Cisco hardware to use the usnic BTL! :-p
Well, this is far above my decision level :o)
Look for the openib message
Err... upon further thought, I might be totally wrong about emulating blocking.
There might be (probably are?) rules/assumptions in the ORTE layer (of which I
am *not* an expert) that disallow you from [emulating] blocking.
If that's the case, then there's architectural issues with converting f
On Nov 25, 2013, at 9:59 AM, Adrian Reber wrote:
> * Send Non-blocking
> */
> int orte_rml_ftrm_send_nb(orte_process_name_t* peer,
> struct iovec* msg,
> int count,
> orte_rml_tag_t tag,
> - i
On Nov 25, 2013, at 9:59 AM, Adrian Reber wrote:
> @@ -5616,16 +5597,8 @@ static int
> do_send_msg_detail(ompi_crcp_bkmrk_pml_peer_ref_t *peer_ref,
> /*
> * Recv the ACK msg
> */
> -if ( 0 > (ret = ompi_rte_recv_buffer(&peer_ref->proc_name, buffer,
> -
Don't encourage our users to write new fortran code ;)
-Nathan Hjelm
HPC-5, LANL
On Wed, Dec 04, 2013 at 02:28:44PM +, Jeff Squyres (jsquyres) wrote:
> FWIW, 1.7 also has the new MPI-3 "use mpi_f08" Fortran bindings, which are
> MUCH better than the old mpif.h and "use mpi" bindings.
>
> If
Ralph -- let's chat about this in Chicago next Friday. I'll add it to the
agenda on the wiki. I assume this would not be difficult stuff; we don't
really need to do anything fancy at all. I think we just want to sketch out
what exactly we want to do, and it could probably be done in a day or
On 04.12.2013 17:56, Jeff Squyres (jsquyres) wrote:
On Dec 4, 2013, at 2:52 AM, Igor Ivanov wrote:
It is the first mca variable with type as string from btl/openib as
'device_param_files'. Actually you can disable it and get failure on the second.
Description of case we see:
1. openib mca va
FWIW, 1.7 also has the new MPI-3 "use mpi_f08" Fortran bindings, which are MUCH
better than the old mpif.h and "use mpi" bindings.
If they care, you should strongly encourage users to "use mpi_f08" in new
Fortran subroutines. Forward and backwards compatibility was a major design
point for the
Thanks for the feedback and info. I think we can install 1.7x for those users
who don't want to deal with the warnings.
-david
--
David Gunter
HPC-3 PTools Team
On Dec 3, 2013, at 3:38 PM, Jeff Squyres (jsquyres)
mailto:jsquy...@cisco.com>> wrote:
You might want to double check that it does
We had committers at HLRS, but they are not as active any more (some people
left, funding priorities changed, etc.), and the VampirTrace folks are in
the general area. We could point you to them if that would be of help.
We also have a couple of folks in Spain who wrote the Java bindings, a few
fo
On Dec 4, 2013, at 2:52 AM, Igor Ivanov wrote:
> It is the first mca variable with type as string from btl/openib as
> 'device_param_files'. Actually you can disable it and get failure on the
> second.
>
> Description of case we see:
> 1. openib mca variables are registered during startup as s
On Dec 4, 2013, at 4:31 AM, Paul Kapinos wrote:
> Argh - what a shame not to see "btl:usnic" :-|
What a shame you don't have Cisco hardware to use the usnic BTL! :-p
>> Look for the openib messages, not the usnic messages.
>
> Well, as said there were *no messages* form the patch you provide
Dear Ralph,
do you know if Open MPI already have commiters in Munich? Any contact in
the Technical University of Munich or the LRZ compute center could be
easily reachable by us.
In any case, I will need to get familiar with the internals of the
library first. I am happy to say that the com
I'm not sure how many apps would benefit, but we are always interested in
taking back patches that extend the ability for researchers to explore new
capabilities provided they don't impact performance (or can be configured
out if they do) and are self-maintained (i.e., either the researcher agrees
FWIW: ORTE already has a sensor framework in it that reads some of these
things, so adding the coretemp etc is pretty trivial. These readings can be
taken in the ORTE event thread on daemons, but we could allow procs to do
so as well (if the app requests it), or can make it driven via the MPI_T
fun
On Wed, 4 Dec 2013 11:39:29 AM Jeff Squyres wrote:
> On Dec 3, 2013, at 7:54 PM,
> Christopher Samuel wrote:
>
> > Would it make any sense to expose system/environmental/thermal
> > information to the application via MPI_T ?
>
> Hmm. Interesting idea.
Phew. :-)
> Is the best way to grab such
On Dec 3, 2013, at 7:54 PM, Christopher Samuel wrote:
>> 2. The MPI_T performance variables are new. There's only a few
>> created right now (e.g., in the Cisco usnic BTL). But the field
>> is pretty wide open here -- the infrastructure is there, but we're
>> really not exposing much informat
Dear Jeff Squyres,
On 12/03/2013 11:27 PM, Jeff Squyres (jsquyres) wrote:
I'm sorry; I really wasn't paying attention to my email the week of SC, and
then I was on vacation for the Thanksgiving holiday. :-\
More below.
On Nov 20, 2013, at 4:13 PM, Compres wrote:
I was at the birds of a fe
On 12/03/13 23:27, Jeff Squyres (jsquyres) wrote:
On Nov 22, 2013, at 1:19 PM, Paul Kapinos wrote:
Well, I've tried this path on actual 1.7.3 (where the code is moved some 12
lines - beginning with 2700).
!! - no output "skipping device"! Also when starting main processes and
-bind-to-socket
It is the first mca variable with type as string from btl/openib as
'device_param_files'. Actually you can disable it and get failure on the
second.
Description of case we see:
1. openib mca variables are registered during startup as stage at select
component phase;
2. but a winner is cm compo
30 matches
Mail list logo
