[Insight-developers] Enhanced logging mechanism

[Hans Johnson]

Bill,

FIRST:  The only part that I can see is still failing is the new test 
module that I designed to stress the outter limits of what the new 
mechanism should be able to do.  I have removed this test since ITK does 
not yet need this functionality, and some of the legacy compilers can't 
handle it.  If this final attempt does not work, I will roll back all 
changes after 9:00pm tonight.

SECOND: The "tricky" solution given in the previous message about using 
the  loki hacks was not going to work (upon further review, it was just 
a complete re-write of the code).

THIRD:  Here is the situation and problem that I was trying to solve:

1) The Logger mechanism in itk had all the "message handling" features 
that I needed
2) The Logger mechanism had the "message format" hard coded to force a 
50 character preamble prior to delivering the message (I could not live 
with that part)
3) I wanted to maintain complete compatibility with the existing API 
including the LoggerManager which is also hardwired to the Logger and 
the ThreadLogger(the ThreadLogger derives from Logger).

I identified that the core logging functionality can be divided as follows:

1) A base class called Logger that defined the interface that defines:
            a) The different acceptable logging levels
            b) The basic member functions that all loggers must also contain
            c)  Messaging format was hard coded.
2) A ThreadLogger class that was hard coded as subclass of Logger that 
defines:
            a) Thread safe queuing mechanism to wrap around the base 
class by overloading each of the basic member functions

My solution was to push the Logger class up to an abstract base class 
(i.e. LoggerBase) with a default implementation exactly like the old 
code.  I then templated the ThreadLogger as a wrapper around any class 
that meets the LoggerBase specifications (LoggerThreadWrapper).  
Finally, I created typedef's to generate specializations of this 
generalized framework to meet the old API.

I sent the code to the list for review, and discussed the changes with 
several people on the weekly telecom call.  I wrote a test suite for the 
enhanced capabilities, and tested the classes on gcc 3.2, 3.4, 4.0, 
linux, mac, and SGI MipsPro before committing it.

FINALLY:  We are setting up a set of windows machines and are attempting 
to purchase MSVS 6, borland, and MSVS 7.  So that we may attempt to 
avoid these problems in the future.



Hans





Lorensen, William E (Research) wrote:

>Hans,
>There are still several issues with the logger changes. Not just windows. The gcc2.95 compiler is also having trouble.
>
>I'm not sure whay so many changes were required to meet your needs. I haven't looked at the logger mechanism in detail. Could there have been a less "tricky" way to get what you wanted?
>
>If you can't come up with a portable solution in the next couple of days, I think you should back out all of your changes until after the release. I'm afraind that this much disruption so close to the release is not good.
>
>Bill
>
>-----Original Message-----
>From: Hans Johnson [mailto:hans-johnson at uiowa.edu]
>Sent: Sunday, November 06, 2005 10:02 AM
>To: Lorensen, William E (Research)
>Cc: ITK
>Subject: Re: [Insight-developers] Enhanced logging mechanism
>
>
>Bill,
>
>I was just looking at this.  I surely thought this was a correct syntax.
>
>Well.... It appears that VS6sp5 does not support this strucuture, VS7 is
>supposed to support it.  Since I don't have either VS6 or VS7, I'll need to
>use the dashboard to test the changes.  I've got a quickfix that I will be
>submitting shortly.
>
>There is a more complete work around descrirbed the loki toolkit,
>loki/MSVC/1200/MSVC6Helpers.h:
>
>============================================================================
>////////////////////////////////////////////////////////////////////////////
>////
>// class template ApplyImpl1
>// Invocation: ApplyImpl1<T>::template Result<T1>
>// T must be a nontemplate type with a nested class template named In.
>// The class template is a helper for the Apply1-Template
>////////////////////////////////////////////////////////////////////////////
>////
>    template <class TypeWithNestedTemplate>
>    struct ApplyImpl1
>    {
>      template<bool flag>
>      struct VC_WORKAROUND : public TypeWithNestedTemplate {};
>
>      struct VC_WORKAROUND<true>
>      { template<class> struct In; };
>
>      template< typename T1 > struct Result : public
>      VC_WORKAROUND<
>::Loki::Private::AlwaysFalse<TypeWithNestedTemplate>::value >::template
>In<T1>
>      {
>        typedef VC_WORKAROUND<
>::Loki::Private::AlwaysFalse<TypeWithNestedTemplate>::value >::template
>In<T1> Base;
>
>      };
>    };
>============================================================================
>
>The loki/MSVC/1300/ version of the code does not seem to require these work
>arounds.   
>
>Hans
>
>PS:  Could we please make a retirement plan for all compilers?
>gcc4 to be retired between 2008 and 2016
>gcc3 to be retired between 2007 and 2013
>VS7  to be retired between 2007 and 2010
>VS6  to be retired between 2005 and 2006
>
>On 11/6/05 7:31 AM, "Lorensen, William E (Research)" <lorensen at crd.ge.com>
>wrote:
>
>  
>
>>Hans,
>>
>>Looks like the microsoft compilers don't like your code. I see that
>>LoggerThreadWrapper is a subclass of its template parameter. Is this OK?
>>
>>Bill
>>
>>    
>>
>
>
>  
>