On Apr 20, 2016, at 9:14 AM, Jeff Squyres (jsquyres) wrote:
>
> I was under the impression that this warning script only ran for developer
> builds. But it looks like it's unconditionally run at the end of "make
> install" (on master only -- so far).
>
> Should we make this only run for devel
[inline]
On Apr 7, 2016, at 12:53 PM, git...@crest.iu.edu wrote:
>
> This is an automated email from the git hooks/post-receive script. It was
> generated because a ref change was pushed to the repository containing
> the project "open-mpi/ompi".
>
> The branch, master has been updated
> v
On Feb 25, 2016, at 4:05 PM, Jeff Squyres (jsquyres) wrote:
>
> On Feb 25, 2016, at 2:59 PM, Paul Hargrove wrote:
>>
>> Not an error - a new API in C++11 to get number of dimensions in a
>> multi-dimensional array.
>> http://en.cppreference.com/w/cpp/types/rank
>
> So you can't have a local v
On Nov 11, 2015, at 10:09 AM, Ralph Castain wrote:
>
> FWIW: I don’t think that’s the issue here. I don’t see these warnings on my
> CentOS7 box, for example. I think this is driven by the fact that odin has
> some very old compilers and a very different environment, and so it has
> historical
Once you squash all these warnings, you could set up a little bit of Jenkins or
Travis CI logic to check for PRs that add new warnings and marks them
appropriately. Of course, with people making commits directly to master,
warnings introduced by those direct commits will be ascribed to those wh
On Sep 3, 2015, at 3:40 PM, Burette, Yohann wrote:
> I see what you are saying. Thank you for pointing it out.
>
> Would MTL_OFI_RETRY_UNTIL_DONE be better instead?
Yes, I think that would be an improvement.
Thanks,
-Dave
On Sep 3, 2015, at 1:03 PM, git...@crest.iu.edu wrote:
> diff --git a/ompi/mca/mtl/ofi/mtl_ofi.h b/ompi/mca/mtl/ofi/mtl_ofi.h
> index 3584d8a..a035b1c 100644
> --- a/ompi/mca/mtl/ofi/mtl_ofi.h
> +++ b/ompi/mca/mtl/ofi/mtl_ofi.h
> @@ -38,6 +38,14 @@
> #include "mtl_ofi_endpoint.h"
> #include "mtl_o
On Aug 20, 2015, at 3:03 PM, git...@crest.iu.edu wrote:
> This is an automated email from the git hooks/post-receive script. It was
> generated because a ref change was pushed to the repository containing
> the project "open-mpi/ompi".
>
> The branch, master has been updated
> via d5763a82
On May 19, 2015, at 1:22 PM, Ralph Castain wrote:
> No thx 😉
>
> I would rather not create code czars
Hence my "half version" alternative suggestion.
-Dave
On May 19, 2015, at 12:36 PM, Ralph Castain wrote:
> Our pr tests aren't good enough for what you propose
I made no claim about whether PRs even needed automated testing in order to
switch to this scheme. Right now I could push any old garbage I want into the
master directly without ever usin
On May 19, 2015, at 5:08 AM, Jeff Squyres (jsquyres) wrote:
> On May 18, 2015, at 5:03 PM, Mark Santcroos
> wrote:
>
>> What I didn't see in the doc, will you continue to work with two repo's or
>> will that change too?
>> (I found that confusing as a newcomer)
>
> Unfortunately, yes, we wil
On Apr 27, 2015, at 8:54 AM, Jeff Squyres (jsquyres) wrote:
> Neat trick about perl -pie; I wasn't aware of that.
Make sure to write it as "-pi -e" (as Paul had it) or "-p -i -e", or it
probably won't do what you expect.
>> On Apr 23, 2015, at 10:42 PM, Paul Hargrove wrote:
>>
>> Since perl
On Apr 14, 2015, at 11:02 PM, Gilles Gouaillardet wrote:
> Dave,
>
> my understanding is that the presence of common symbols should be treated as
> a warning
> (and hence make install should not fail)
>
> makes sense ?
It should be a warning... are you seeing otherwise in your builds? Here's
ons where the lock is implicit.
>
> George.
>
>
> On Wed, Mar 25, 2015 at 4:59 PM, Dave Goodell (dgoodell)
> wrote:
> On Mar 25, 2015, at 3:02 PM, git...@crest.iu.edu wrote:
>
> > +static inline int32_t opal_atomic_swap_32( volatile int32_t *addr,
> >
On Mar 25, 2015, at 3:02 PM, git...@crest.iu.edu wrote:
> +static inline int32_t opal_atomic_swap_32( volatile int32_t *addr,
> +int32_t newval)
> +{
> +int32_t oldval;
> +
> +__asm__ __volatile__("xchg %1, %0" :
This code *looks* buggy because it l
On Mar 4, 2015, at 3:25 PM, Paul Hargrove wrote:
> On Wed, Mar 4, 2015 at 1:04 PM, Dave Goodell (dgoodell)
> wrote:
> [...]
> > libibverbs: Warning: couldn't open config directory '/etc/libibverbs.d'.
> > libibverbs: Warning: no userspace device-speci
On Mar 4, 2015, at 11:56 AM, Paul Hargrove wrote:
> I have a system with InifniPath HCAs, where I've historically tested mtl:psm.
> For some reason, that appears to have ceased working some time in the past 4
> months.
> However, this report is about something else.
> I am using the current mast
On Feb 25, 2015, at 10:45 AM, Jeff Squyres (jsquyres)
wrote:
> On Feb 24, 2015, at 5:44 PM, Paul Hargrove wrote:
>>
>> FIRST:
>> I believe that *something* should have occurred when no dl component could
>> be built.
>> Either the build should have been aborted or it could/should have switche
On Feb 20, 2015, at 6:46 AM, git...@crest.iu.edu wrote:
> This is an automated email from the git hooks/post-receive script. It was
> generated because a ref change was pushed to the repository containing
> the project "open-mpi/ompi-tests".
>
> The branch, master has been updated
> via ff
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
My personal opinion on this is that adding a bot:rebase command is a bit silly.
IMO only the author of the PR should be allowed to issue this command, since
it modifies his/her fork repo, in which case why not just use the git command
line to do this? We shouldn't be implementing a full copy o
On Jan 5, 2015, at 8:40 PM, Gilles Gouaillardet
wrote:
> Dave,
>
> what if you do
>
> touch ompi/include/mpi.h.in && sleep 1 && touch
> config/opal_config_pthreads.m4 && ./autogen.pl && module unload
> cisco/autotools/ac269-am1133-lt242 && ./configure --prefix=$PWD/_prefix &&
> make
>
>
>
ected, so bottom line,
> only developers that update m4 files can be affected)
>
>
> Cheers,
>
> Gilles
>
> On Tue, Dec 23, 2014 at 2:26 AM, Dave Goodell (dgoodell)
> wrote:
> On Dec 22, 2014, at 2:42 AM, Gilles Gouaillardet
> wrote:
>
> > Jeff
On Dec 22, 2014, at 5:16 AM, Gilles Gouaillardet
wrote:
> Jeff,
>
> MTT reported some errors when building some test suites :
> http://mtt.open-mpi.org/index.php?do_redir=2219
>
> the root cause was some missing flags in the wrappers.
> i fixed that in 8976dcf6101412f6bd0080764d19a3e9d4edf570
On Dec 22, 2014, at 2:42 AM, Gilles Gouaillardet
wrote:
> Jeff and all,
>
> i just found "by accident" that make can require autotools.
>
> for example:
>
> from (generated) ompi/include/Makefile :
> $(srcdir)/mpi.h.in: $(am__configure_deps)
>($(am__cd) $(top_srcdir) && $(AUTOHEADER)
Quoting from
https://github.com/blog/1938-vulnerability-announced-update-your-git-clients
"""
A critical Git security vulnerability has been announced today, affecting all
versions of the official Git client and all related software that interacts
with Git repositories, including GitHub for Win
On Nov 6, 2014, at 12:44 AM, George Bosilca wrote:
> PS: Sorry Dave I also pushed a master branch merge ...
It's not the end of the world, just try to keep an eye on it and avoid doing it
in the future. If you need any help avoiding it, feel free to ping me or the
devel@ list in general.
-Da
On Nov 3, 2014, at 10:50 AM, Alexander Mikheev wrote:
> It is --amend of my previous commit. When I tried to push my amended commit,
> the merge was required.
Ah, I just spotted the minor difference between the two commits. The second
argument to setenv() was changed from integer zero to a
On Nov 3, 2014, at 10:41 AM, Jed Brown wrote:
> "Dave Goodell (dgoodell)" writes:
>> Most of the time a "pull" won't succeed if you have uncommitted
>> modifications your tree, so I'm not sure how pull/commit/push would
>> actually work
Hi Alex,
Why did you push this "OSHMEM: spml ikrit..." commit twice? I see it here
(together with an undesirable merge-of-master commit) and also as 065dc9b4.
-Dave
On Nov 3, 2014, at 2:03 AM, git...@crest.iu.edu wrote:
> This is an automated email from the git hooks/post-receive script. It w
On Nov 1, 2014, at 3:44 AM, Gilles Gouaillardet
wrote:
> Hi Dave,
>
> I am sorry about that, the doc is not to be blamed here.
> I usually do pull/commit/push in a row to avoid this kind of things but i
> screwed up this time ...
> I cannot remember if i did commit/pull/push or if i simply for
Hi Gilles,
Please try to avoid creating merge-of-master commits like 68bec0ae ("Merge
branch 'master' of..."), they just clutter the history. A rebase is almost
always more appropriate in this situation.
https://github.com/open-mpi/ompi/wiki/GitBestPractices
If you created that commit with "g
On Oct 17, 2014, at 9:51 AM, Jed Brown wrote:
> "Jeff Squyres (jsquyres)" writes:
>
>> Meaning: we deliberately chose not to change the development style of
>> the community to "develop on release branch" when we moved to git.
>
> Understood. It's your choice, but workflow is a big feature of
this because the projects I was working on had very
> little concurrent commits going in.
>
> thanks for pointing this out though,
>
> Howard
>
>
> 2014-10-08 7:29 GMT-06:00 Dave Goodell (dgoodell) :
> On Oct 3, 2014, at 5:10 PM, git...@crest.iu.edu wrote:
>
> > - L
On Oct 3, 2014, at 5:10 PM, git...@crest.iu.edu wrote:
> - Log -
> https://github.com/open-mpi/ompi/commit/93eba3ac70606db12465319804f2733f13bc9ca4
>
> commit 93eba3ac70606db12465319804f2733f13bc9ca4
> Merge: fd6a044 bd2974f
> Author
On Oct 2, 2014, at 11:47 AM, Ralph Castain wrote:
>
> On Oct 2, 2014, at 9:43 AM, Jeff Squyres (jsquyres)
> wrote:
>
>> On Oct 2, 2014, at 12:37 PM, Ralph Castain wrote:
>>
>>> Sonow that I've fought thru and created a pull request, I find that I
>>> cannot assign it to anyone for revi
On Oct 2, 2014, at 11:17 AM, Ralph Castain
wrote:
>
> On Oct 2, 2014, at 9:13 AM, Dave Goodell (dgoodell)
> wrote:
>
>> On Oct 2, 2014, at 10:38 AM, git...@crest.iu.edu wrote:
>>
>>> This is an automated email from the git hooks/post-receive script. I
On Oct 2, 2014, at 10:38 AM, git...@crest.iu.edu wrote:
> This is an automated email from the git hooks/post-receive script. It was
> generated because a ref change was pushed to the repository containing
> the project "open-mpi/ompi".
>
> The branch, master has been updated
> via 3263f721
I just accidentally killed four nodes worth of MTT tests in our Cisco lab
cluster, so some of our MTT results may look quite bad in the near future. The
affected nodes were mpi005..mpi008, in case it makes the results easier to
filter.
Apologies to anyone who was planning on using this particu
On Aug 20, 2014, at 11:55 AM, svn-commit-mai...@open-mpi.org wrote:
> Author: rhc (Ralph Castain)
> Date: 2014-08-20 12:55:36 EDT (Wed, 20 Aug 2014)
> New Revision: 32556
> URL: https://svn.open-mpi.org/trac/ompi/changeset/32556
>
> Log:
> Track down the last piece of the connection problem. It a
WHAT: Add a new "opal/threads/spinlock.h" header to OPAL that will typically
use the OS spinlock primitives if present.
WHY: opal_mutex_t is too slow for some use cases and opal_atomic_lock_t is
inefficiently implemented for most architectures
WHEN: timeout is after next week's engineering call
On Aug 11, 2014, at 11:54 AM, Paul Hargrove wrote:
> I am on the same page with George here - if it's on the list then support it
> until its been removed.
>
> I happen to have systems to test, I believe, every supported atomics
> implementation except for DEC Alpha, and so I did test them all
On Aug 7, 2014, at 11:37 PM, George Bosilca wrote:
> Paul's tests identified an small issue with the previous patch (a real
> corner-case for ARM v5). The patch below is fixing all known issues.
Wait, why do we care about ARMv5? It's certainly not a serious HPC platform,
nor is it even a rele
WHAT: Allow reservation of a symbol namespace that is independent of component
location.
WHY: All of the framework location/abstraction churn over the years has made it
challenging to maintain single source versions of MCA components (e.g., the
"usnic" BTL) that work with multiple versions of O
Jeff and I were talking about some namespacing issues that have come up in the
recent BTL move from OMPI to OPAL. AFAIK, the current system for namespacing
external symbols is to name them "mca_FRAMEWORK_COMPONENT_symbol" (e.g.,
"mca_btl_tcp_add_procs" in the tcp BTL). Similarly, the DSO for t
On Jul 24, 2014, at 2:00 PM, Mike Dubman wrote:
> OSHMEM memheap implementation relies on the "_end" symbol provided by linux
> linker. The _end symbol indicates the beginning of the program dynamic
> allocation area.
> This is needed to allow programmatic access to the process global/static
again.
-Dave
On Jul 22, 2014, at 12:20 PM, Ralph Castain wrote:
> You need to rm -rf ompi/contrib/vt and then svn up again - it's a stale .deps
> directory entry
>
> On Jul 22, 2014, at 10:15 AM, Dave Goodell (dgoodell)
> wrote:
>
>> FYI, this causes build
FYI, this causes build failures in OTF code in our Jenkins installation. It's
probably caused by this commit:
https://svn.open-mpi.org/trac/ompi/changeset/32265
I don't have time to track it down myself, unfortunately.
-Dave
Begin forwarded message:
> From:
> Subject: Build failed in Jenkin
On Jul 16, 2014, at 3:08 PM, Joshua Ladd wrote:
> Ralph warned me that no matter what decision we made, someone would probably
> violently object. So, with that in mind, let me put my diplomat hat on...
FWIW, I don't think my objections here have been "violent".
> Dave, I'm sorry you view this
On Jul 16, 2014, at 12:15 PM, Mike Dubman wrote:
> we have a strong use-case for list of env variables passed as mca params.(it
> was presented and discussed in the past).
I'm not disputing your use case for "mca_base_env_list". I'm only lamenting
the crapification of our mpirun user interfac
On Jul 16, 2014, at 12:27 PM, Joshua Ladd wrote:
> Dave,
>
> Your example will error out. If someone tries to set envars with both
> mechanism, the job fails. The decision to do so was also made at the Dev
> meeting and is so that we don't have to do this kind of checking.
Hmm, indeed it doe
On Jul 16, 2014, at 11:31 AM, Ralph Castain wrote:
> Nobody was "against" retaining it. The issue is that "-x" isn't an MCA
> parameter, nor does it get translated to one under the covers. So the problem
> was one of how to insert it into the typical MCA param precedence chain.
I understand th
On Jul 15, 2014, at 2:03 PM, Mike Dubman wrote:
> these are two separate issues:
>
> 1. -x var=val (or -mca opal_base_envlist var=val) will work in the same way
> opal_base_envlist does the same as "-x" and can be used in the very same
> fashion as -x
>
> 2. When list of vars is passed with he
This commit (and the subsequent amendments to the feature) doesn't appear to
support escaping the separator. A later commit allows you to change the
separator character, which helps, but AFAICS you still can't actually escape
the separator itself. That seems like a real deficiency to me...
Fu
On May 13, 2014, at 4:01 PM, Nathan Hjelm wrote:
> While tracking down memory leaks in components I ran into an interesting
> issue. osc/rdma uses an opal_free_list_t (not an ompi_free_list_t) for
> buffer fragments. The fragment class allocates a buffer as part in the
> constructor and frees the
I've filed a ticket for this so that we don't lose track of it:
https://svn.open-mpi.org/trac/ompi/ticket/4578
-Dave
On Apr 24, 2014, at 2:37 AM, Lisandro Dalcin wrote:
> Please review the attached patch,
>
> ==19533== Conditional jump or move depends on uninitialised value(s)
> ==19533==
Lisandro,
Thanks for the bug report. It seems that nobody has time to work on this at
the moment, so I've filed a ticket so that we don't lose track of it:
https://svn.open-mpi.org/trac/ompi/ticket/4577
-Dave
On Apr 21, 2014, at 9:55 AM, Lisandro Dalcin wrote:
> A very basic test for MPI_Co
On Apr 16, 2014, at 5:32 AM, Jeff Squyres (jsquyres) wrote:
> What source code repository technology(ies) do you use for Open MPI
> development? (indicate all that apply)
>
> - SVN
> - Mercurial
> - Git
Mostly Git (via the Github mirror and git-svn), and very rarely direct SVN.
Never Mercuri
ke an argument - it is shorthand for "npernode 1". You probably meant to
> use the "npernode" option, which would have worked.
>
>
> On Mar 31, 2014, at 9:57 AM, Dave Goodell (dgoodell)
> wrote:
>
>> Ralph,
>>
>> When I use the "--per
Ralph,
When I use the "--pernode" option (instead of "--map-by ppr:1:node") with
v1.8@r31295, I get this:
8<
$ mpiexec --pernode 2 -n 4 --host dg1,dg2 ./ring_c
--
The following command line options and corresponding
Ralph,
I'm seeing problems with MPIEXEC_TIMEOUT in v1.7 @ r31103 (fairly close to
HEAD):
8<
MPIEXEC_TIMEOUT=8 mpirun --mca btl usnic,sm,self -np 4 ./sleeper
--
The user-provided time limit for job execution has been
Might want to replace the bzero with memset while you're at it. I recall
hitting portability problems on weird systems and Linux systems where
features.h has been poked the wrong way with "_POSIX_SOURCE" and friends.
-Dave
On Mar 11, 2014, at 4:59 PM, svn-commit-mai...@open-mpi.org wrote:
> A
Nathan,
The onesided/test_acc2 test is failing in our Cisco MTT runs on the trunk and
v1.7.5 branches:
8<
test_acc2 == Mon Mar 10 15:31:47 2014
Time per int accumulate 0.769040 microsecs
P0, Test No. 0, PASSED: accumulate performance Mon Mar 10 15:31:47 2014
==
Begin forwarded message:
> From:
> Subject: [OMPI svn] svn:open-mpi r30894 - in branches/v1.7: . ompi
> ompi/attribute ompi/debuggers ompi/errhandler ompi/include ompi/mca/btl
> ompi/mca/btl/openib/connect ompi/mca/op ompi/mca/osc ompi/mca/osc/base
> ompi/mca/osc/portals4 ompi/mca/osc/rdma omp
On Feb 19, 2014, at 6:36 AM, George Bosilca wrote:
> There is one minor thing I would suggest to change. In your patch
> in_unexpected_list is defined as a bool, which translates to an int on most
> platforms.
This statement isn't true. sizeof(bool)==1 on my Mac and on our x86_64 Linux
clust
Should be fixed on trunk by r30674. It's been CMRed to v1.7.5 here:
https://svn.open-mpi.org/trac/ompi/ticket/4254
-Dave
On Feb 11, 2014, at 11:00 AM, Jeff Squyres (jsquyres)
wrote:
> Excellent; thanks Paul. We're having a look.
>
> On Feb 8, 2014, at 6:50 PM, Paul Hargrove wrote:
>
>> W
On Feb 10, 2014, at 6:14 PM, Jeff Squyres (jsquyres) wrote:
> As a side effect, this means that -- for 32 bit builds -- we will not support
> large filesystems well (e.g., filesystems with 64 bit offsets). BlueGene is
> an example of such a system (not that OMPI supports BlueGene, but...).
To
On Feb 4, 2014, at 1:44 PM, svn-commit-mai...@open-mpi.org wrote:
> Author: hjelmn (Nathan Hjelm)
> Date: 2014-02-04 14:44:08 EST (Tue, 04 Feb 2014)
> New Revision: 30555
> URL: https://svn.open-mpi.org/trac/ompi/changeset/30555
>
> Log:
> Fix wrapper ldflags.
>
> cmr=v1.7.4:reviewer=jsquyres
>
On Jan 28, 2014, at 2:18 PM, Orion Poplawski wrote:
> Why does mpio.h get installed? For the Fedora package I end up with:
>
> /usr/lib64/openmpi/include/mpio.h
>
> but it is listed here in openmpi-1.7.4rc2/ompi/mca/io/romio/romio/Makefile.am:
>
> # nodist_ b/c these are created by config.sta
On Dec 20, 2013, at 4:43 PM, Paul Hargrove wrote:
> The warning is correct that no such interface exists.
> However 127.0.0.1/24 DOES exist:
>
> $ ifconfig lo0 inet
> lo0: flags=8049 metric 0 mtu 16384
>options=63
>inet 127.0.0.1 netmask 0xff00
Minor quibble, Paul: that
Jeff Squyres is usually our Fortran expert for this sort of issue, but he's on
vacation until after the Thanksgiving holiday in the US. So please expect a
modest delay in (properly) responding to your question.
-Dave
On Nov 21, 2013, at 9:37 AM, "Gunter, David O" wrote:
> We have a user comp
Mike,
Why not put these packaging files in "/contrib/dist/..." in SVN and then
symlink them to "/debian" as a step in your build script? Top level names are
(somewhat) precious and should not be added casually.
-Dave
On Nov 6, 2013, at 4:50 AM, svn-commit-mai...@open-mpi.org wrote:
> Author:
Mike,
I've never personally used git2svn, but my understanding is that it would
require us to essentially "lock" the repository to all other commits while you
are using it, which isn't very friendly to the rest of the community. Also,
using git2svn probably wouldn't twiddle the SVN merge track
Based on discussion with Mellanox around the recent GitHub mirror updates, I've
added a .mailmap file in r29494. It helps address two goals:
1) To be able to fix misspelled names without rewinding the Git history.
2) To be able to add email addresses incrementally without rewinding Git
history
74 matches
Mail list logo
