[OMPI devel] [PATCH v3 2/2] Trying to get the C/R code to compile again. (send_*_nb)

From: Adrian Reber <adrian.re...@hs-esslingen.de> This patch changes all send/send_buffer occurrences in the C/R code to send_nb/send_buffer_nb. The new code compiles but does not work. Changes from V1: * #ifdef out the code (so it is preserved for later re-design) * marked the broken C/

Re: [OMPI devel] [PATCH v2 2/2] Trying to get the C/R code to compile again. (send_*_nb)

e isn't > the number of bytes sent any more - it is just ORTE_SUCCESS or else an error > code, so you should be testing for ORTE_SUCCESS == > > > > > On Dec 18, 2013, at 6:42 AM, Adrian Reber <adr...@lisas.de> wrote: > > > From: Adrian Reber <adrian

[OMPI devel] [PATCH v2 0/2] Trying to get the C/R code to compile again

From: Adrian Reber <adrian.re...@hs-esslingen.de> This is the second try to replace the usage of blocking send and recv in the C/R code with the non-blocking versions. The new code compiles (in contrast to the old code) but does not work yet. This is the first step to get the C/R code w

[OMPI devel] [PATCH v2 2/2] Trying to get the C/R code to compile again. (send_*_nb)

From: Adrian Reber <adrian.re...@hs-esslingen.de> This patch changes all send/send_buffer occurrences in the C/R code to send_nb/send_buffer_nb. The old code is still there but disabled using ifdefs (ENABLE_FT_FIXED). The new code compiles but does not work. Changes from V1: * #ifd

[OMPI devel] [PATCH v2 1/2] Trying to get the C/R code to compile again. (recv_*_nb)

From: Adrian Reber <adrian.re...@hs-esslingen.de> This patch changes all recv/recv_buffer occurrences in the C/R code to recv_nb/recv_buffer_nb. The old code is still there but disabled using ifdefs (ENABLE_FT_FIXED). The new code compiles but does not work. Changes from V1: * #ifd

Re: [OMPI devel] [PATCH v2] Trying to get the C/R code to compile again. (last)

the OOB, then we need to > > go directly to it. I'll have to check/correct the code, but the RML > > shouldn't even be storing a pointer to the OOB in it as there no longer is > > a direct linkage. > > > > > > > > > On Dec 9, 2013, at 5:38 AM, Adrian Reber <adr...@lisas.

Re: [OMPI devel] OMPI developer's meeting today

Is there a phone number I can use to join the meeting via phone from Germany? Adrian On Thu, Dec 12, 2013 at 02:43:38PM -0600, Ralph Castain wrote: > Sorry for delay - we just realized we hadn't addressed this yet. > > Plan is to still start at 9am as planned. Hope that is okay.

Re: [OMPI devel] [PATCH v2] Trying to get the C/R code to compile again. (last)

; > > > > > > > > > This doesn't seem right - if we are referencing the OOB, then we need to > > > go directly to it. I'll have to check/correct the code, but the RML > > > shouldn't even be storing a pointer to the OOB in it as there no longer > > > is a

Re: [OMPI devel] [PATCH v2] Trying to get the C/R code to compile again. (last)

Dec 9, 2013, at 5:38 AM, Adrian Reber <adr...@lisas.de> wrote: > > > diff --git a/orte/mca/rml/oob/rml_oob_component.c > > b/orte/mca/rml/oob/rml_oob_component.c > > index dd539cd..b91f4a3 100644 > > --- a/orte/mca/rml/oob/rml_oob_component.c > > +++ b/orte/

[OMPI devel] [PATCH v2] Trying to get the C/R code to compile again. (last)

From: Adrian Reber <adrian.re...@hs-esslingen.de> This are the remaining changes to get C/R to compile again. This patch includes various fixes all over the C/R code and are hard to group like the previous patches. Changes from V1: * explain why mca_base_component_distill_checkpoint

Re: [OMPI devel] [PATCH 4/4] Trying to get the C/R code to compile again. (last)

On Fri, Dec 06, 2013 at 08:43:39AM -0600, Josh Hursey wrote: > Did the mca_base_component_distill_checkpoint_ready paramter go away? Its > intention was to allow a user to have a build with C/R compiled in and then > choose at runtime if they want to restrict their component section to just > C/R

Re: [OMPI devel] [PATCH 2/4] Trying to get the C/R code to compile again. (send_*_nb)

se, then there's architectural issues with converting from > > blocking to nonblocking on both the sending and the receiving sides that > > might be a bit thorny to sort out. > > > > > > > > On Dec 4, 2013, at 10:54

Re: [OMPI devel] [PATCH 1/4] Trying to get the C/R code to compile again. (void value not ignored)

9 AM, Adrian Reber <adr...@lisas.de> wrote: > > > From: Adrian Reber <adrian.re...@hs-esslingen.de> > > > > This patch fixes > > > > error: void value not ignored as it ought to be > > > > in the C/R code by ignoring the return value of func

Re: [OMPI devel] [PATCH 4/4] Trying to get the C/R code to compile again. (last)

On Wed, Dec 04, 2013 at 08:07:39PM +, Jeff Squyres (jsquyres) wrote: > 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

[OMPI devel] [PATCH 0/4] Trying to get the C/R code to compile again

using "--with-ft=cr". This patchset only fixes existing compilation problems; the code is not yet expected to work. I used "make check" to verify that it does not break existing code. Adrian Reber (4): Trying to get the C/R code to compile again. (void value not ignored) T

[OMPI devel] [PATCH 3/4] Trying to get the C/R code to compile again. (recv_*_nb)

From: Adrian Reber <adrian.re...@hs-esslingen.de> This patch changes all recv/recv_buffer occurrences in the C/R code to recv_nb/recv_buffer_nb. Signed-off-by: Adrian Reber <adrian.re...@hs-esslingen.de> --- ompi/mca/crcp/bkmrk/crcp_bkmrk_pml.c| 49 +++- ort

[OMPI devel] [PATCH 4/4] Trying to get the C/R code to compile again. (last)

From: Adrian Reber <adrian.re...@hs-esslingen.de> This are the remaining changes to get C/R to compile again. This patch includes various fixes all over the C/R code and are hard to group like the previous patches. Signed-off-by: Adrian Reber <adrian.re...@hs-esslingen.de> --- omp

[OMPI devel] [PATCH 1/4] Trying to get the C/R code to compile again. (void value not ignored)

From: Adrian Reber <adrian.re...@hs-esslingen.de> 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: Adrian Reber <adrian.re...@hs-esslingen.de> -

[OMPI devel] [PATCH 2/4] Trying to get the C/R code to compile again. (send_*_nb)

From: Adrian Reber <adrian.re...@hs-esslingen.de> This patch changes all send/send_buffer occurrences in the C/R code to send_nb/send_buffer_nb. Signed-off-by: Adrian Reber <adrian.re...@hs-esslingen.de> --- ompi/mca/crcp/bkmrk/crcp_bkmrk_pml.c| 12 ++--- orte/mca

[OMPI devel] [PATCH] Trying to get the C/R code to compile again

). This first patch fixes wrong include directives when compiling with OPAL_SETUP_FT_OPTIONS. Adrian >From c417f21e5a720f8bfe9ee222948ae8c59d4a485b Mon Sep 17 00:00:00 2001 From: Adrian Reber <adrian.re...@hs-esslingen.de> List-Post: devel@lists.open-mpi.org Date: Wed, 20 Nov 2

Re: [OMPI devel] openmpi with FT enabled

ies at this > time. We're looking to restore that support next year as part of the 1.9 > release series. > > > On Oct 28, 2013, at 8:47 AM, Adrian Reber <adr...@lisas.de> wrote: > > > I am trying to compile openmpi (Revision: 29539) from svn > > with '--with-ft=cr'. I ge

[OMPI devel] openmpi with FT enabled

I am trying to compile openmpi (Revision: 29539) from svn with '--with-ft=cr'. I get a compilation error and I am lost how to solve it: ../../../../opal/mca/base/mca_base_components_open.c: In function 'open_components': ../../../../opal/mca/base/mca_base_components_open.c:144:9: error:

<    1   2