Nathan,
i think it is a good idea to use names vs numeric values for verbosity.
what about using "a la" log4c verbosity names ?
http://sourceforge.net/projects/log4c/
static const char* const priorities[] = {
"FATAL",
"ALERT",
"CRIT",
"ERROR",
"WARN",
"NOTICE",
"INFO
Could we maybe narrow it down some? If we are going to do it, let’s not make
the mistake of the MCA param system and create so many levels. Nobody can
figure out the right gradation as it is just too fine grained.
I think Nathan’s proposal is the max that makes sense.
I’d also like to see us ap
so what about :
static const char* const priorities[] = {
"ERROR",
"WARN",
"INFO",
"DEBUG",
"TRACE"
};
and merge debug and trace if there should be only 4
Cheers,
Gilles
On Monday, June 8, 2015, Ralph Castain wrote:
> Could we maybe narrow it down some? If we are going t
> static const char* const priorities[] = {
> "ERROR",
> "WARN",
> "INFO",
> "DEBUG",
> "TRACE"
> };
+1
I usually use these levels.
Typical usage:
ERROR:
Print an error message on returning a value other than
OMPI_SUCCESS (and OMPI_ERR_TEMP_OUT_OF_RESOURCE etc.).
WARN:
That would work. The standard verbosity levels could be one of those
values but allow any number in the interval [0,100] or any of none,
error, warn, info, debug, and trace. The standard levels could be
defined as:
enum {
MCA_BASE_VERBOSE_NONE = 0,
MCA_BASE_VERBOSE_ERROR = 1,
MCA_BAS
So how is the user going to specify these? -mca oob_base_verbose debug?
> On Jun 8, 2015, at 9:11 AM, Nathan Hjelm wrote:
>
>
> That would work. The standard verbosity levels could be one of those
> values but allow any number in the interval [0,100] or any of none,
> error, warn, info, debug,
Yes.
-Nathan
On Mon, Jun 08, 2015 at 09:17:17AM -0700, Ralph Castain wrote:
> So how is the user going to specify these? -mca oob_base_verbose debug?
>
> > On Jun 8, 2015, at 9:11 AM, Nathan Hjelm wrote:
> >
> >
> > That would work. The standard verbosity levels could be one of those
> > val
Developers --
Per our new release scheme, it's (slightly past) time to branch for v2.0.0.
Howard and I would like to talk about branching tomorrow (9 June 2015) on the
weekly webex:
- what features are incomplete?
- what bug fixes are coming in immanently?
- what else is needed before v2.0.0?
-
Can we wait until the f2f meeting in 2 weeks ?
George.
On Mon, Jun 8, 2015 at 1:50 PM, Jeff Squyres (jsquyres)
wrote:
> Developers --
>
> Per our new release scheme, it's (slightly past) time to branch for v2.0.0.
>
> Howard and I would like to talk about branching tomorrow (9 June 2015) on
The goal is to branch annually on June 1. We're already past that -- we let it
slip because we were in Chicago last week at the MPI Forum. I.e., that seemed
like a good reason to let it slip.
Howard and I talked about this on the phone today (i.e., whether we should wait
until the f2f meeting
My only reason is that if we delay the branch for the face-to-face meeting,
so an extra delay of a mere one week, we could use the extra time to
finalize some of the pending updates (e.g. add_proc).
George.
On Mon, Jun 8, 2015 at 2:43 PM, Jeff Squyres (jsquyres)
wrote:
> The goal is to branch
I am halfway through the infrastructure changes required for the
non-blocking collective I/O operations. It will take me probably 2 more
days of coding to finish what I wanted to get done before the branch,
but unfortunately I can not guarantee that I will get to it this week.
Since it is very
In a perfect world, branching = feature complete. But I doubt that will be the
case here.
Let's talk about it on the call tomorrow and scope what 2.0 things are still
being worked on.
> On Jun 8, 2015, at 4:07 PM, George Bosilca wrote:
>
> My only reason is that if we delay the branch for t
Got it; thanks.
Sent from my phone. No type good.
> On Jun 8, 2015, at 4:14 PM, Edgar Gabriel wrote:
>
> I am halfway through the infrastructure changes required for the non-blocking
> collective I/O operations. It will take me probably 2 more days of coding to
> finish what I wanted to get
14 matches
Mail list logo
