On Oct 19, 2011, at 6:41 PM, George Bosilca wrote:
> A careful reading of the committed patch, would have pointed out that none of
> the concerns raised so far were true, the "old-way" behavior of the OMPI code
> was preserved.
Then perhaps you could have added some comments to explain the not-
There are several OPAL level error codes not used in the current code.
OPAL_ERR_TOPO_SLOT_LIST_NOT_SUPPORTED
OPAL_ERR_TOPO_SOCKET_NOT_SUPPORTED
OPAL_ERR_TOPO_CORE_NOT_SUPPORTED
OPAL_ERR_NOT_ENOUGH_SOCKETS
OPAL_ERR_NOT_ENOUGH_CORES
OPAL_ERR_INVALID_PHYS_CPU
OPAL_ERR_MULTIPLE_AFFINITIES
If somebody
A careful reading of the committed patch, would have pointed out that none of
the concerns raised so far were true, the "old-way" behavior of the OMPI code
was preserved. Moreover, every single of the error codes removed were not used
in ages.
What Brian pointed out as evil, evil being a subjec
George -
I wrote the error code gorp; I'm pretty sure I know exactly how it was
supposed to work.
There are 58 codes unused between OPAL_NETWORK_NOT_PARSEABLE and
OPAL_ERR_MAX. I now see what you did with ERR_REQUEST, and it's evil.
THat's not the intent of the error code logic at all. If you w
On Oct 19, 2011, at 2:50 PM, George Bosilca wrote:
> I don't know how you think that the error codes work in Open MPI, so I'll
> take the liberty to depict it here so we all agree we're talking about the
> same thing.
>
> The opal_strerror is a nice feature, it allow to register a range of err
Can I have an example on how the current trunk is broken due to this change?
Thanks,
george.
On Oct 19, 2011, at 16:32 , Ralph Castain wrote:
> I propose that we retain the rest of the changeset, but revert the OMPI
> constants to bring back their ORTE equivalents. We clearly should scrub tho
I don't know how you think that the error codes work in Open MPI, so I'll take
the liberty to depict it here so we all agree we're talking about the same
thing.
The opal_strerror is a nice feature, it allow to register a range of error
codes with a particular error converter. Every time you loo
I propose that we retain the rest of the changeset, but revert the OMPI
constants to bring back their ORTE equivalents. We clearly should scrub those
and update them to ensure they are both used and current, but it seems to me we
lose more than we gain by removing them.
On Oct 19, 2011, at 12:
Oy, yes, that is bad -- we cannot have overlapping ORTE and OMPI error codes.
That seems like a very bad idea (in addition to the mixing of + and -).
For one thing, that breaks opal_strerror(). That, in itself, seems like a
dealbreaker.
On Oct 19, 2011, at 1:51 PM, Barrett, Brian W wrote:
>
I actually think it's worse than that. An ORTE error code can now have
the same error code as an OMPI error. OMPI_ERR_REQUEST and
ORTE_ERR_RECV_LESS_THANK_POSTED now share the same integer return code.
Or, they should, if George hadn't made a mistake (see below). The sharing
of return codes seem
I've been wrestling with something from this commit, and I'm unsure of the
right answer. So please consider this a general design question for the
community.
This commit removes all the OMPI <-> ORTE equivalent constants - i.e., we used
to declare OMPI-prefixed equivalents to every ORTE-prefixe
It's not just my components, George - there are people with branches out there
that have OMPI components and changes in them. If you are going to gripe when
others make changes without warning, then you should abide by your own rules.
:-)
On Oct 19, 2011, at 8:16 AM, George Bosilca wrote:
> O
OK, just saw your commit. It make sense, an OMPI component should return OMPI
error codes. Thanks for the fix.
george.
On Oct 19, 2011, at 10:12 , George Bosilca wrote:
> I run an entire battery of tests on these without any issues. Moreover it is
> an OMPI related thing, and these error mes
I run an entire battery of tests on these without any issues. Moreover it is an
OMPI related thing, and these error messages were never used. Anyway, please
let me know what exactly failed, I'll fix it asap.
Thanks,
george.
On Oct 19, 2011, at 10:06 , Ralph Castain wrote:
> If you are go
If you are going to make such sweeping changes, could you please provide a
little warning as per our usual methods? This broke several things which can be
repaired, but would have been nice to know that we were going to make such a
change.
Thx
On Oct 18, 2011, at 9:51 PM, bosi...@osl.iu.edu w
15 matches
Mail list logo
