Phew! I'd no idea my questions would create nearly
that kind of level of response on the list. I should
post more often! :)
Anyways, here are a few suggestions that might - just
might - work around some of the problems that have
been mentioned:
1. Publish the stable header files early, or fragmen
Folks --
I don't have anything new to say to this specific post, but I did want
to say that today has been most excellent in terms of feedback for us.
I thank you all for your time in writing this all down and sending it
to us; every post is being read. It has certainly caused a lot of
disc
On Jun 15, 2005, at 2:32 PM, Benjamin Allan wrote:
Although we have not made a final decision yet, given that community
involvement is a *strong* goal of this project, we've actively
discussed several models of how to bring the community into Open MPI.
One possibility is to have a minimal regist
On Jun 15, 2005, at 7:02 PM, Ben Allan wrote:
The ompi_info command was directly derived from the LAM/MPI laminfo
command. However, I've never liked the fact that there's a "_" in the
name. Should it be renamed? Options I see are:
I, for obvious reasons (mainly to do with 'well, most projec
[an aside for the mailing list admin before the main message:
I want to subscribe a secondary address
and then check the box that
says nomail in the mailman membership list.
The secondary address can post mail but runs no
server to accept inbound mail, which tends to squish
the confirm portion of
On Jun 15, 2005, at 6:07 PM, Jeff Squyres wrote:
bin/ompi_info presents an opportunity to help all us shlubs that
have to do gnu build systems.
BTW, I forgot to mention -- try running "ompi_info -all" and/or
"ompi_info -all -parsable". It is explicitly aimed at those who need
to query the c
On Jun 15, 2005, at 3:51 PM, Benjamin Allan wrote:
bin/ompi_info presents an opportunity to help all us shlubs that
have to do gnu build systems.
Heh. So you got a bootleg Open MPI tarball after all! :-) (I'm
actually in the middle of replying to your other post -- sometimes it
takes me a
bin/ompi_info presents an opportunity to help all us shlubs that
have to do gnu build systems.
It appears it could be extended to include useful bits of info
that are normally classed as build magic.
e.g. gnome-config, xml2-config, etc, etc.
I see lam-config was debated at least briefly back in 2
Benjamin Allan writes:
I would like to emphasize Ben's point about integration.
I really could care less whether the implementation works right now
or not. However, I care very much how the build system functions,
since that it where the hard work of integration will be. You are
making m
On Jun 15, 2005, at 12:23 PM, Bogdan Costescu wrote:
On Tue, 14 Jun 2005, Brian Barrett wrote:
It would be nice if the c++ compiler wrapper were
installed under mpicxx, mpiCC, and mpic++ instead of
just the latter 2.
Yeah, we can do that, no problem.
Sorry for the silly question, but is th
Well said Jeff!
I look forward to seeing Open MPI's code when it's released.
Until then, I am happy to continue to use LAM/MPI for my clusters.
I wish you had called it OpenMPI though... better for googling ;-)
--
Tim Mattox - tmat...@gmail.com
http://homepage.mac.com/tmattox/
I'm a brigh
Just a brief response on two points (lest the 'insiders' think
there are no sympathetic outsiders...).
On Wed, Jun 15, 2005 at 01:09:27PM -0400, Jeff Squyres wrote:
>
> Although we have not made a final decision yet, given that community
> involvement is a *strong* goal of this project, we've ac
Ahh, the real reasons:
3. The HPC community is quite small, and the competition is quite
fierce...
Open Source tends to weed out the weaker competition (i.e. users decide
the winner). If you have the best solution, competition shouldn't be a
concern.
6. We're still working through the le
On Tue, 14 Jun 2005, Brian Barrett wrote:
It would be nice if the c++ compiler wrapper were
installed under mpicxx, mpiCC, and mpic++ instead of
just the latter 2.
Yeah, we can do that, no problem.
Sorry for the silly question, but is there any kind of document or
formal recommendation rega
Your points are certainly valid; thanks for the input.
I hope my post from a few minutes ago sheds like on our rationale and
our future directions.
One of the reasons that has been discussed among the Open MPI team for
not opening the tree to everyone is the fact that at least some of us
are
On Jun 14, 2005, at 9:54 PM, Scott Feldman wrote:
We're a quiet bunch. :-)
Which is a bad thing for Open Source development. It seems Open MPI is
closed-source development project with an open-source release model.
At this point in our development, I somewhat agree. But this will soon
ch
Scott Feldman wrote:
> Which is a bad thing for Open Source development. It seems Open MPI is
> closed-source development project with an open-source release model.
That has been my impression as well. The projects seems completely
disinterested in outside involvement, and fails in both the in
Yes, I agree.
At the very least, it sure would be nice to have a read-only source tree
available. It's understood that many things will be broken, but without
a visible source base that tracks active development, you're not getting
any of the benefits of an 'open' development model.
Personally,
On Tue, Jun 14, 2005 at 06:54:42PM -0700, Scott Feldman wrote:
>
> On Jun 14, 2005, at 5:45 PM, Jeff Squyres wrote:
>
> > We're a quiet bunch. :-)
>
> Which is a bad thing for Open Source development. It seems Open MPI is
> closed-source development project with an open-source release model.
19 matches
Mail list logo
