Archive for the 'SmartInspect 2.0' Category

We are happy to announce that SmartInspect 2.0 has been released! The new version contains more than 100 new features and improvements (our What’s New page has all the details). Here is a quick list of the most important new features in this upgrade:

• Full Unicode support in all libraries and in the Console
• Backlog queue management for improved I/O performance
• Watches Graph to track variable values and resources
• New memory and text log protocols
• New modern look and productivity improvements
• Session tracking for easier integration into complex applications
• Support for hourly, daily, weekly and monthly log rotation
• Many view improvements and new filters
• New log entry types and log methods
• Custom protocols and protocol actions
• Support for Windows Vista, .NET 3.0 and Java 1.6
• And much more

And because a picture says more than a thousand words, the following screenshot shows the new SmartInspect Console with the updated look and feel and some of the new features like the Watches Graph on the right:

Customers who ordered SmartInspect on or after the 1^st October 2006 can download the new version from our My Gurock.com customer portal. If you purchased SmartInspect before that date, you can upgrade to the new version by ordering the SmartInspect 1.x upgrade in our shop (we also have an introductory price for the new version and for the upgrade until March 31^st).

We are currently working on getting the last bits of the new SmartInspect release finished (which should be available at the end of February) and I decided to introduce another new feature of SmartInspect 2.0: the memory protocol.

The memory protocol can be used for writing logging information to memory instead of writing it directly to file or sending it to the Console. When needed, it can save its queue of logging data to a user-supplied stream or file. The memory protocol has been designed to allow exception reporting mechanisms to include a log file when an error occurs.

When an end-user sends an exception report to the developer, it is now possible to use rich SmartInspect log files in addition to traditional call stack information to inspect an error. And because the memory protocol can be configured to use only a tiny bit of memory space, it is both very fast and consumes only few resources and can stay enabled at all times.

We designed this feature especially to integrate SmartInspect better with exception reporting products like EurekaLog, MadExcept and similar solutions.

We are happy to announce that the upcoming major version of SmartInspect will come with full Unicode support. The current version is limited to logging and displaying ANSI strings and we think that this just isn’t suitable for a modern Windows application anymore.

All components of SmartInspect (the log format, libraries, Console and Configuration Builder) have been updated to handle Unicode data. The log format, for instance, now uses UTF-8 encoded strings instead of plain old ANSI strings. We will update our log format and protocols documentation on our website accordingly when the new version is available.

For the Java and .NET libraries, the Unicode porting was naturally a no-brainer since strings on these platforms were already in Unicode form. The only required change was therefore the switch to the UTF-8 log format encoding. For the Delphi library, the Console and the Configuration Builder (which are all implemented in Delphi) on the other hand, this was a lot more work. The native ‘String’ type in Delphi is an 8-bit string which does not handle Unicode very well (actually it doesn’t handle Unicode at all except UTF-8 encoded strings). We were therefore forced to replace all occurrences of ‘String’ with ‘WideString’ (the Delphi equivalent of Windows’ 16-bit Unicode strings) and all string handling routines and classes with Unicode enabled alternatives. Additionally we needed to update most of the graphical controls in the Console and the Configuration Builder.

What sounds simple was actually a tremendous amount of work, but we are very confident that the work was worth it. We plan to publish the glory details of porting Delphi applications to Unicode in a future posting (maybe on CDN?); probably once SmartInspect 2.0 is released.

This posting is part of a series introducing new features of the upcoming SmartInspect 2.0 version. Subscribe to our blog to learn about other new features.

Several new features have been added to the views in the SmartInspect Console. First, the views now support inverse filtering. This means you can now specify if a certain result for a filter should be inverted. As an example, it is now possible to limit a view to log entries whose session differs from the “Main” session by specifying a simple session filter and checking its invert option.

Second, the view filters have been enhanced to support log entry title filtering and you can now limit views to log entries whose titles match a certain string. Title filters have a case sensitive option, support for regular expressions and you can optionally invert the filter result to exclude log entries. Both new types of filtering, the title and inverse filters, allow a lot of useful scenarios which weren’t possible with earlier SmartInspect versions.

Other new view features include the Clear View Rules functionality to clear view filters with a single click, the Clone View functionality to clone a view, the new Close Other Views option to remove multiple views at once and a lot more. AutoView rules have also been enhanced to support log entry types as well as the new title and inverse filtering.

This posting is part of a series introducing new features of the upcoming SmartInspect 2.0 version. Subscribe to our blog to learn about other new features.

This is the first posting of a series talking about upcoming features of SmartInspect 2.0. The first new feature that we want to introduce is the so called backlog functionality. The backlog feature of the SmartInspect libraries is a flexible packet queue that minimizes the I/O costs by saving log entries in memory until a log packet with a certain configurable log level is logged. We got the idea for this feature from one of our customers who implemented a similar functionality with the help of the library filter event.

If the backlog of a protocol is enabled, log packets are first written to a queue in memory rather than directly to the protocol specific destination (a log file or TCP/IP connection, for example). The queue can be configured to have a certain trigger log level and a maximum amount of memory that it consumes. If a log packet arrives with a log level equal to or greater than the specified trigger log level, the queue is flushed and all packets in the queue are written to the actual protocol destination. If the packet queue has been filled up with packets and a new packet is about to be stored, old entries are automatically discarded. The new backlog functionality can thus drastically reduce the I/O performance costs involved in logging.

We designed the backlog functionality especially for production usage. If you enable the backlog and configure it to save log packets to a log file in case of an error, you will be able to analyze all errors that occurred over the time and inspect them in their context. Unimportant log entries that were generated long before an error occurred are automatically discarded. This approach guarantees the best performance during regular production usage and enough information when an actual error occurs.

Depending on the used protocol and the complexity of the logging functions, the logging performance can be improved by a factor 10 and more. Since the logging performance plays a very important part on production systems, we are really happy to have this feature in SmartInspect.

We have been quietly working on SmartInspect 2.0 in the last months and are now ready to talk about all the great new features and changes of the upcoming version. To highlight the upcoming benefits and to give every major new feature its own space to be discussed, we are going to publish postings with detailed explanations of the all the new things here on this blog.

When will SmartInspect 2.0 be available for customers? We plan to release the new version in Q1 2007 and every customer who purchased SmartInspect on or after the 1st October will get a free upgrade. That’s right, if you order SmartInspect now or in the coming weeks, you will get SmartInspect 2.0 without paying for the upgrade. You will even save money, because we plan to increase the price of SmartInspect by 20% - 30%.

Existing customers who purchased SmartInspect before the 1st October can upgrade to SmartInspect 2.0 with a discount. We are also planning on establishing a maintenance and support contract as a yearly subscription that includes major upgrades as well as all the existing support options.

We came to the conclusion that a yearly support subscription is better for both our customers and for us. Customers have the assurance that they can always access the latest version without first paying for an upgrade and the yearly subscription price is easier to plan with. On the other hand, we will be able to release new features immediately without worrying about keeping new features for major releases.