On 24/08/13 00:24, Philip Ashmore wrote: > On 23/08/13 12:59, Blasche Alexander wrote: >> Hi Robin, >> >> I am not sure whether you are aware of >> http://qt.gitorious.org/qtplayground/qlogger >> >> It is pretty much what you describe. It was even close to a merge into >> qtcore already (only rejected due to feature freeze). It gives you a >> complete API including ways to integrate with qDebug/qWarning, runtime >> activation, little to no overhead when deactivated and there was reasonably >> broad agreement already. Also see: >> >> http://lists.qt-project.org/pipermail/development/2012-December/008886.html >> >> If you have spare cycles to actually make this happen I would propose you >> start with a 95% done system rather than new. >> >> -- >> Alex > For a tracing system to be useful and stand a chance of being adopted by > the libraries used by Qt as well as Qt itself, it shouldn't be part of Qt. > > My humble attempt is available as part of v3c: > > http://sourceforge.net/projects/v3c/ > > It has commits going back to 2011 but I deleted the earlier ones so it's > even older. > > You can control tracing at compile time, link time and runtime. > You can cache trace output and only dump it if it's noteworthy, e.g. if > something went wrong or a corner case is hit. > > This uses a stringstream to cache the trace output. > > This will be available in the next version - the one I'm using with my > projects now (the version in SourceForge has the TraceCache macro but I > never got around to using/testing it until recently). > > Some examples: > void fn(int a, int x) > { > TraceWrap(__PRETTY_FUNCTION__ << " a: " << a); > trace << "the value of x is " << x << '.' << endl; > } > > It has a pluggable architecture, but the main application decides if > trace output goes to cout, cerr or a file or nowhere. > > It doesn't have module-level trace control but that could be added. > I forgot to mention I've also got v3c-qt: http://sourceforge.net/projects/v3c-qt/ There's an "examples" tar-ball there that shows how to integrate tracing into some demo Qt Applications.
My projects use the automake "make && make check && make distcheck && make install" commands, as well as "make debian/ make ubuntu". For iterative development I really like "make -j9". Oh and you can configure build targets, the defaults are "debug" and "release". The point of proposing a tracing system/library that's not part of Qt is that it can be adopted by non-Qt libraries which Qt might eventually use. > Regards, > Philip Ashmore >> >> ________________________________________ >> From: [email protected] >> [[email protected]] on behalf >> of Robin Burchell [[email protected]] >> Sent: Friday, August 23, 2013 13:20 >> To: [email protected] >> Cc: Poenitz Andre >> Subject: [Development] Tracing Qt >> >> Hi, >> >> (apologies in advance for the wall of text) >> >> It's inevitable when working with Qt that sooner or later, you >> probably have a desire to work on tracing Qt - or at least part of it. >> Qt Creator's QML profiler is one such very prominent example of an >> area where this may be useful, but there are many others: usually >> sprinkled around Qt hidden behind various defines, environment >> variables, and other hard-to-find places. This makes digging into a >> problem somewhat hard, unless you are (or can be handheld by) a Qt >> expert when you start digging. >> >> It's also a bit of a problem in that each of these methods uses >> different ways to communicate information, meaning it is difficult to >> write tooling to inspect this data and visualise it. We also miss out >> on tracing in a number of areas that *could* potentially be valuable, >> such as touch event processing, the event loop, the sky's the limit. >> >> Thanks to Carsten and Andre for their input in hashing the details of >> this proposal out. >> >> Proposal >> ======== >> >> Let's look at unifying tracing inside Qt. Let's add code to Qt itself >> to enable easy introspection of what exactly is going on. >> >> When looking at tracing, it can be boiled down into two levels - an >> area (which may be a feature being inspected, or a subsystem - for >> instance, QML performance, vsync timestamps, ...) containing events, >> so from this, we can gather that we need a way to categorise logging >> by area, and the capability to switch logging on by area. >> >> An area should be associated with a simple numeric identifier to avoid >> expensive code when manipulating events, but there will be some form >> of name => id mapping (for the environment variable below, for >> instance). >> >> Suggested area-based API: >> enum TraceArea { >> TraceAreaDrawing (drawing event, frame event) >> ... other areas as required >> TraceAreaUser = 1000 // held for possible future expansion into >> allowing dynamic area registration >> } >> >> QT_ENABLE_TRACE=inputevents,frameevents,magicalmonkeyevents >> rationale: providing system-wide defaults enables tracing of >> system-wide behaviour is very useful. Being able to inspect exactly >> what an entire set of Qt-based applications are doing while a user is >> interacting with it would be a useful thing. >> >> enable_trace(TraceArea area) >> disable_trace(TraceArea area) >> rationale: a developer may want to turn tracing of an individual area >> on/off at runtime, as they start something they are particularly >> interested in tracing. This has some inspiration in >> CALLGRIND_START_INSTRUMENTATION/CALLGRIND_STOP_INSTRUMENTATION also. >> >> Along with this user-facing API, we also need some mechanism to enable >> different applications of the tracing data (for instance, the QML >> profiler from Creator, Android's systrace >> https://developer.android.com/tools/help/systrace.html, plain console >> logging, etc). Multiple tracers should be able to handle a single >> area. Tracers would live in seperate plugins. >> >> Example tracer API: >> class QTracer { virtual void logStart() = 0; virtual void logEnd() = 0; } >> >> QTracer subclasses would register their interest in a particular event >> type on construction: >> >> struct MyCoolConsoleTracer : public QTracer { >> MyCoolConsoleTracer() : QTracer() { >> q_register_tracer_for_area(this, TraceAreaDrawing); // we are >> interested in this particular event type >> } >> >> virtual void logStart() { >> qDebug() << "Trace event for drawing, start: " << >> QDateTime::currentMSecsSinceEpoch() >> } >> virtual void logEnd() { >> qDebug() << "Trace event for drawing, end: " << >> QDateTime::currentMSecsSinceEpoch() >> } >> }; >> >> The invocation of tracer subclasses is controlled by a simple RAII class: >> >> struct QTraceEvent { >> QTraceEvent(TraceArea area); // invokes logStart on all interested >> tracers >> ~QTraceEvent(); // invokes logEnd on all interested tracers >> } >> >> Example use being something like: >> >> void draw() { >> QTraceEvent e(TraceAreaDrawing); >> // do painting >> paintOnScreen(); >> } >> >> Thoughts, flames, cookies? >> >> BR, >> Robin >> (with jolla hat on) >> _______________________________________________ >> Development mailing list >> [email protected] >> http://lists.qt-project.org/mailman/listinfo/development >> _______________________________________________ >> Development mailing list >> [email protected] >> http://lists.qt-project.org/mailman/listinfo/development >> > _______________________________________________ > Development mailing list > [email protected] > http://lists.qt-project.org/mailman/listinfo/development > _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
