From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,e074d1bef61cfe40 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-09-02 17:50:53 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!peernews-us.colt.net!newsfeed.news2me.com!elnk-nf2-pas!newsfeed.earthlink.net!stamper.news.pas.earthlink.net!stamper.news.atl.earthlink.net!newsread1.news.atl.earthlink.net.POSTED!not-for-mail From: "Marc A. Criley" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: ANNOUNCE: DTraq First Public Release References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: Date: Wed, 03 Sep 2003 00:50:52 GMT NNTP-Posting-Host: 63.189.241.112 X-Complaints-To: abuse@earthlink.net X-Trace: newsread1.news.atl.earthlink.net 1062550252 63.189.241.112 (Tue, 02 Sep 2003 17:50:52 PDT) NNTP-Posting-Date: Tue, 02 Sep 2003 17:50:52 PDT Organization: EarthLink Inc. -- http://www.EarthLink.net Xref: archiver1.google.com comp.lang.ada:42083 Date: 2003-09-03T00:50:52+00:00 List-Id: 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