Re: PROPOSAL: revise GLib message system

[Tim Janik <timj gtk org>]

On 10 Aug 1998, Owen Taylor wrote:

> 
> Tim Janik <timj@gtk.org> writes:
> 
> > On 7 Aug 1998, Owen Taylor wrote:
> > 

> > you could just use multiple calls for such cases, e.g.
> > typedef enum
> > {
> >   G_SEVERITY_FATAL,
> >   G_SEVERITY_WARNING,
> >   G_SEVERITY_INFO,
> >   G_SEVERITY_DEBUG
> > } GSeverityType;
> > 
> > g_info_set_handler (gtk_quark, G_SEVERITY_FATAL, gtk_info_handler_abort);
> > g_info_set_handler (gtk_quark, G_SEVERITY_CRITICAL, gtk_info_handler_continue);
> > g_info_set_handler (gtk_quark, G_SEVERITY_WARNING, gtk_info_handler_continue);
> > g_info_set_handler (gtk_quark, G_SEVERITY_INFO, gtk_info_handler_continue);
> > g_info_set_handler (gtk_quark, G_SEVERITY_DEBUG, gtk_info_handler_continue);
> 
> That's what I was trying to avoid. Especially, if there is a chance
> we might add new severity levels. I suppose we could define a special
> G_SEVERITY_ALL that would, when passed to g_log_set_handler, cause
> it to call itself for all severity levels.

so, i guess

typedef enum
{
  G_SEVERITY_FATAL    = 1 << 0,
  G_SEVERITY_WARNING  = 1 << 1,
  G_SEVERITY_INFO     = 1 << 2,
  G_SEVERITY_DEBUG    = 1 << 3,
  G_SEVERITY_MASK     = 0x0f
} GSeverityFlags;

would be what you thought of.
the one thing i don't like about this, is that it's likely to give the
impression that messages can be logged at different levels simoultanously,
which is totaly unreasonably actually...
that's why i'd rather not have the levels specified as flags, at the cost
of multiple function calls to g_log_set_handler().

> > but i'd prefer to use g_logger instead of g_info. g_info could be needed
> > as a fucntion name later on, and g_logger does express the purpose better.
> > it wouldn't for instance be unreasonable if we later feature a comandline
> > option, that's going to let the default message handlers log into a
> > file or somesuch.
> 
> g_logger can't be a function name (or macro name) because it isn't
> a verb. g_log() would be OK.

i actually grabbed the idea from logger(1).

> > with the sole purpose of increased readability.
> > on non-gcc systems, G_WARNING, G_ERROR and G_MESSAGE are even going
> > to be *real* functions (inlined), so we could just give them lower
> > case names in the first place...
> 
> I don't think this is going to work. Remember, we need to pass
> an extra argument in and for a varargs function, I think the
> only way we can do this on non-GCC systems is:
> 
>   g_warning (("%s failed", str));
> 
> which presumably fails the huge-commits test. This seems to imply that
> everything does need to define it's own warning error and message
> functions :-(

i'm certainly aware of the gcc-ism of varargs macros. since i wouldn't
want to make a g_warning (("%s failed", str)); commit, and consider
it unaccaptable to force every glib programmer on this world into the
same hassle, i'am trying to find a way around taht.

possibilities are:

- provide g_warning and friends as inline functions that use <stdarg.h>.
- resolve the log level stuff as a "g_warning" macro, thus using a 
  macro definition without arguments.
  this can be done by either
    #define g_warning	g_log_domain = G_LOG_DOMAIN; g_log_warning
  or through preprocessor magic that mangles the actuall function
  name, but this requires each library to provide their own
  implementation.

all of the above are a little ugly in some kinda way, but then,
that's the actuall reason the gcc guys invented (...) macros.

> But they still should be based on some sort of internal g_log()
> thing so everybody doesn't need to define their own handlers
> as well.

that's why i tend to go for the <stdarg.h> and inline variant for
non-gcc systems. the only drawbacks with this approach is that
we need to include <stdarg.h> for glib.h by default, and some
code bloat for those systems, where as the other solutions either
have the problem of requiering extra global variables (g_log_domain
and g_log_severity) or function implementations on the client side.
 
> > extern GQuark gtk_quark; would need to be initialized at the beginning of
> > gtk_init(), but do we really want quarks in this place? we can just as well
> > export const gchar *gtk_logger_domain = "Gtk", and use
> > -DG_LOGGER_DOMAIN=gtk_logger_domain. (this comes pretty close to the usual
> > -DPRG_NAME= or -DLIBRARY_NAME= that is used in many projects).
> 
> The reason I thought GQuark was to reduce the number of places
> that constant strings would appear in each file. I suppose any
> decent compiler combines constant strings, so it is only one
> extra (short) string for file. That is certainly simpler, and, 
> simpler definitely better here. (I'm am still uncertain that
> this all is worth the complexity to begin with...)

that's the reason why i proposed to use a global const string variable,
this way the string constant is not duplicated in every *.lo file of
e.g. gtk.


> > basically, g_warning and friends stay the same for the application programmer,
> > but for libraries like gtk or gdk, their specific behaviour can be tweaked
> > through a -DG_LOGGER_QUARK=something switch, i don't consider that inherently
> > evil...
> 
> Hmmm, I suppose we could say that it is sort of a function call, that
> just happens to provide some more functionality if you defined the
> G_LOG_DOMAIN...
>  
> Regards,
>                                         Owen
> 
> 

---
ciaoTJ