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_BASE_VERBOSE_WARN = 10,
MCA_BASE_VERBOSE_INFO = 20,
MCA_BASE_VERBOSE_DEBUG = 40,
MCA_BASE_VERBOSE_TRACE = 60,
MCA_BASE_VERBOSE_MAX = 100,
};
static mca_base_var_enum_value_t verbose_values[] = {
{"none", MCA_BASE_VERBOSE_NONE},
{"error", MCA_BASE_VERBOSE_ERROR},
{"warn", MCA_BASE_VERBOSE_WARN},
{"info", MCA_BASE_VERBOSE_INFO},
{"debug", MCA_BASE_VERBOSE_DEBUG},
{"trace", MCA_BASE_VERBOSE_TRACE},
{NULL, -1}
};
-Nathan
On Tue, Jun 09, 2015 at 12:42:05AM +0900, KAWASHIMA Takahiro wrote:
> > 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:
> This does not indicate an error. But users/developers should
> be aware on debugging/tuning. For example, network-level
> timeout, hardware queue full, buggy code.
> Often used with OMPI_ERR_TEMP_OUT_OF_RESOURCE.
>
> INFO:
> Information that may be useful for users and developers.
> Not so verbose. Output only on initialization or
> object creation etc.
>
> DEBUG:
> Information that is useful only for developers.
> Not so verbose. Output once per MPI routine call.
>
> TRACE:
> Information that is useful only for developers.
> Verbose. Output more than once per MPI routine call.
>
> Regards,
> KAWASHIMA Takahiro
>
> > 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 <r...@open-mpi.org> wrote:
> >
> > > 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 apply the same logic to the MCA param system.
> > > Let’s just define ~4 named levels and get rid of the fine grained
> > > numbering.
> > >
> > >
> > > On Jun 8, 2015, at 2:04 AM, Gilles Gouaillardet <gil...@rist.or.jp
> > > <javascript:_e(%7B%7D,'cvml','gil...@rist.or.jp');>> wrote:
> > >
> > > 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",
> > > "DEBUG",
> > > "TRACE",
> > > "NOTSET",
> > > "UNKNOWN"
> > > };
> > >
> > > Cheers,
> > >
> > > Gilles
> > >
> > > On 5/30/2015 1:32 AM, Nathan Hjelm wrote:
> > >
> > > At the moment we have a loosely enforced standard for verbosity
> > > values. In general frameworks accept anything in the range 0 - 100 with
> > > few exceptions. I am thinking about adding an enumerator for verbosities
> > > that will accept values in this range and certain named constants which
> > > will match with specific verbosity levels. One possible set: none - 0,
> > > low - 25, med - 50, high - 75, max - 100. I am open to any set of named
> > > verbosities.
> > >
> > > Thoughts?
> _______________________________________________
> devel mailing list
> de...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post:
> http://www.open-mpi.org/community/lists/devel/2015/06/17475.php
pgpVFYxsar0oC.pgp
Description: PGP signature
