Proposal for 2.8: Glog
- From: Maciej Katafiasz <ml mathrick org>
- To: GTK+ Devel List <gtk-devel-list gnome org>
- Subject: Proposal for 2.8: Glog
- Date: Tue, 03 May 2005 21:03:05 +0200
here's a proposal for addition to Glib 2.8, named Glog.
Bunch of details:
What is it?
Glog is debugging and logging library. It provides simple, but flexible
logging facilities, with support for multiple logging levels, and allows
to precisely specify the output to be shown. Its output can be coloured,
and logging messages can be sorted by different categories for use by
separate pieces of code.
Glog depends only on Glib, and has no other dependencies (besides usual
GNU toolchain). Optionally it can make use of glibc's printf()
How mature is it?
Very. The library itself is 2 months old, but the entirety of code was
taken from GStreamer, where it has been used *extensively* for years. It
is the very basic tool used by gstreamer team for debugging purposes,
and works great in this role.
It is very small and self-contained, has very little impact on existing
code (none in fact, if you don't use it explicitly), adds only minimal
API and integrates with Glib out of the box. Glog compiles everywhere
where GStreamer does, which is (AFAIK) everywhere where Glib compiles,
including win32, osx, and weirdarse unices you'd rather forget about. It
also builds natively under MSVC on win32.
We feel that logging support provided by Glog is mature and of immense
usefulness for much broader class of applications than just GStreamer,
hence this proposal.
Whole libification was done by Benjamin Otte of GStreamer fame, to whom
the credit goes.
Who would want to use it?
Anyone who is interestend in precise tracking and logging of code
execution. Glog doesn't directly replace Glib's debugging facilities,
which are mostly intended for detecting programming errors, but rather
complements it by providing extensive tools for observing runtime
behaviour, especially when time domain is of importance, as is the case
for media processing.
In short, if you'd use Log4j, you'd also use Glog.
How performant is it?
Enough. Our experience shows that impact is barely noticable, and
doesn't exceed 5% when logging is turned off. All GStreamer builds sport
logging support by default, and we're media framework using Glog all
over the place, so you can get the idea :). When not used the runtime
penalty is exactly 0% (you need to opt in to use Glog).
If maximum performance is of concern, Glog can be compiled out with a
single line, reducing all calls to NOPs.
Where can I get it?
cvs -d:pserver:anoncvs pdx freedesktop org:/cvs/gstreamer co
To see it in action, just run (provided you have GStreamer installed)
$ gst-inspect-0.8 --gst-debug=*:5
and watch in awe. To get feel of category support, try
$ gst-launch-0.8 --gst-debug=GST_STATES:3,GST_PLUGIN_LOADING:5 fakesrc !
That's about it. GStreamer team will still be maintaining Glog once it's
incorporated in Glib proper. Total amount of time estimated necessary
for integration: 2 hours (if it goes bad, all it really takes is copying
the source and slightly adjusting autofoo).
Maciej Katafiasz <ml mathrick org>
] [Thread Prev