comp.lang.ada
 help / color / mirror / Atom feed
From: "Marc A. Criley" <marc@mckae.com>
Subject: Re: ANNOUNCE: DTraq First Public Release
Date: Wed, 03 Sep 2003 00:50:52 GMT
Date: 2003-09-03T00:50:52+00:00	[thread overview]
Message-ID: <MVa5b.17003$EW1.16716@newsread1.news.atl.earthlink.net> (raw)
In-Reply-To: <ubru3cfxa.fsf@wanadoo.fr>

Pascal Obry wrote:
> 
> I've never used nor seen such a tool. Can you provides more information
> about what it can be used for ? How can it helps debugging ?

Many projects of any significant size have some sort of "logger", a
package or class or file of logging functions.  As the program runs,
information that the developer has decided would be useful to record
for subsequent analysis or monitoring is logged.  (Actually, specific
logging requirements may also be placed on an application by its
customer, especially for military systems.)

So such loggers basically record to one or more log files the
information that is submitted to the logging service while the app
runs, along with a timestamp and perhaps other useful information.

There are two general approaches regarding the form of the logged
data: One is that the application preconverts the data to text and
then logs that text, so the application has the responsibility of
properly interpreting and formatting the data that is then logged.

The second approach is to more-or-less provide an address and a number
of bytes to the logger, and the logger then writes those raw bytes to
the log file.  This address/size combination can sometimes be dressed
up as somehow simply specifying the object to log, or utilizing a
suitably instantiated generic (which is what DTraq does).

The problem with the first approach is that text representations
usually take up more bytes than the raw data, which means added I/O or
network traffic, plus the text conversion impacts application
performance.

The problem with the second approach is that the raw bytes still have
to be converted to text at some point.  So there are a couple typical
ways of doing that: defining layout templates that are overlayed on
the data to break them up and that describe how to interpret each
piece--scalar, record component, array element, string, integer,
float, character, etc.  Another is to create a "data dumper" that
programmatically converts a data stream into text, which is then
invoked by the logging system's "viewer".  And of course whenever a
data item's format changes, the corresponding template or dumper needs
to be updated, and when there's a need to log a new type of data, a
new template/dumper has to be created.

For the basic logging part, DTraq is like most other loggers--you
identify the data item you want to log, instantiate a generic
procedure with the type of that data item, and then add invocations of
that instantiation wherever you want to "tap" the value of that item.

Something like:

    type Color_Type is (Red, Green, Blue);

    Current_Color : Color_Type := Red;

    procedure Tap_Color is new DTraq.Tap
            (Color_Type, 121, "Color_Type");
    -- Tap's parameters are the type to tap, a numeric ID you pick
    -- to associate with it, and an optional string that will be
    -- later conveyed to the viewer.

Then wherever you want to record the current value insert:

    Tap_Color(Current_Color);

At this point the current value of Current_Color goes out to the log
file.

Now what you can do with DTraq is monitor your taps live while the
program is running, and verify that they're taking on the values you
expected as the program is put through its paces.

After you've done your run, you can then reload a log file into DTraq
and have it play it back for you, single or multiple step through the
logged data, forward or backward, reviewing how the key values changed
as the program executed.  And of course you can print out all or
portions of the logged data.


The key area where DTraq differs from other loggers is in the
conversion from raw bytes to text.  DTraq scans your Ada source code,
and with the aid of the Ada Semantic Information Specification (ASIS)
automatically locates the "Tap" invocations, identifies each type being
tapped, and analyzes it (including any components it may have) to
understand how to convert instances of the data type into
corresponding text, whether that item is a number, a character,
string, enumeration, record, or array.

This is all automatically done by running the "mkdtq" component of
DTraq over your code base--you NEVER have to manually convert, or
describe how to convert, raw data to text.  When a data item changes
or a new one is added, another invocation of mkdtq automatically picks
up the changes.

Makes things _much_ less tedious :-)

Hope this helps, there's detailed info in the DTraq user manual, and a
fully working example accompanies the distribution and is gone over
step by step in the manual.

Marc
marc 'at' mckae.com




  parent reply	other threads:[~2003-09-03  0:50 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-09-01 21:57 ANNOUNCE: DTraq First Public Release Marc A. Criley
2003-09-02 16:29 ` Pascal Obry
2003-09-02 17:23   ` Florian Weimer
2003-09-02 17:44     ` Pascal Obry
2003-09-02 18:12       ` Florian Weimer
2003-09-02 20:54   ` Guillaume Foliard
2003-09-03  0:00   ` Jeffrey Creem
2003-09-03  0:55     ` Marc A. Criley
2003-09-03  1:04       ` Jeffrey Creem
2003-09-03  0:50   ` Marc A. Criley [this message]
2003-09-05 16:43     ` Pascal Obry
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox