New Features as of version 1.2.1 

  April 5th, 2011

  Highlights:  
     * PicklingTools C++ M2k serialization supports big endian:
       this allows a particular Java client to work
       (email me if you want this client!)
     * Added workaround for Intel 10.0.12 compiler

  When the code for M2k serialization was ported from M2k to 
  PicklingTools, it missed the endianness code.  The Java client
  for talking to M2k uses big-endian, so M2k serialization needs
  to support big-endian.  To support this, we have to modify a number
  of files:
     chooseser.h:  Added a new argument (defaults to MachineRep_EEEI,
                   little-endian, which is most Linux intel boxes)
                   which allows M2k serialization to specify.  This
                   simply gets passed through to the new M2k routines.
     m2ser.h,.cc:  Added new MachineRep_e argument to a bunch of 
                   the serializations to allow the M2k serialization
                   to use Big (IEEE) or Little (EEEI) endian.
     midassocket.h,cc:  Added endian code.
  In the future, other protocols need to respect this, but right
  now, only the M2k serialization "respects" the endianness (the
  Pickling Protocol 2 is always little-endian, so that shouldn't 
  be an issue for that).

  Intel 10.0.12 C++ compiler seems to be too "agressive" at instantiating
  templates: some templates shouldn't be instantatied.  This caused problem 
  with the compare operations (operator<, >, etc) for complex_8, complex_16
  operations.   By default, complex compares shouldn't be supported 
  (Do you compare my magnitude? point-wise?  Python throws an exception:
  It seems the "right choice" that a C++ should simply not allow the
  instantiation; however, in the Intel 10.0.12 compiler, this philosophy 
  makes it so NOTHING can build, so for that compiler we have instantiate 
  some extra templates to get everything to build).  Some major customers 
  work with Intel 10.0.12 and we need to make them happy, so we have added 
  some truly heinous #ifdefs to deal with that compiler problem:
     We changed ocproxy.h, occomplex.h and ocarray.h: if you see
     __ICC==1010 && __INTEL_COMPILER_BUILD==20080112 in those files,
    it's solely to deal with Intel compiler 10.0.12.

  In the M2k area, the components don't build out of the box
  in release 1.2.0:  that should be fixed now.

  Testing: 
        RH6 32-bit wth GCC
        Fedora Core 14 64-bit with GCC 4.5.1
        RedHat 5.3 32-bit with Intel

  Updated Docs (for new release)
  Updated version numbers