New features as of version 1.11 -Added OC namespace for C++ (minor ripples throughout baseline, esp. Xm area) -Minor bug fix for Numeric array pickling, -Fixed some warnings and minor bugs exposed by g++ 4.4.x (on FC 12 and 13) -In Pickling Protocol 0, wasn't handling strings with embedded ctl-sequences -In Pickling Protocol 2, underestimated size of buffer to dump to, fixed M2k code and raw C++ code -Added some catches to server examples to show how to keep the server up if client disconnects May 18th, 2010 Code tested on RedHat 4.4, 5.3, Fedora Core 12, 13 and Tru64 OSF1. Namespace work in the C++ area: * Added the ABILITY to put all the OpenContainers code and PicklingTools code into a C++ namespace. The older versions of the OC library (and PTOOLS) were in the "global" space, not protected by a C++ namespace. We have added namespaces to OC as of version 1.6.7 (with PicklingTools 1.1.1), but in a backwards compatible way. Old code should be completely backwards compatible: it should still compile and and link and run the same. The namespaces have the extra benefit that all the link symbols are encapsulated in the the OC namespace so as not to conflict with similar symbols. The way this works: by default, namespaces are turned on in the new version, but with a default "using namespace oc;" here in ocport.h: Thus the names are all available at the global level as before, but link symbols are protected inside the OC namespace. If you wish to force the user to deal with the OC namespace (so the user has to do "using"s manually), you can: #define OC_FORCE_NAMESPACE // See below You can completely also turn off the namespace declarations to completely eliminate any namespace constructs (for severe backwards compatibility constraints) by asserting: #define OC_NAMESPACE_EXPERT__NO_NAMESPACES // shouldn't need to do this but you are very very unlikely to need to do that. The default (with the namespace constructs in-place and the "using namespace OC") should work with old code without any code changes (just a recompile/relink). This is a mechanism for when that doesn't work. **EXPERT USERS: By default, we insert a "using namespace OC" into a .h file (ocport.h), which is usually a no-no in C++ circles: we only do it to preserve backwards compatibility with previous versions of the library. We do, however, allow control over the 'using' via a special macro to turn "off" the using: #define OC_FORCE_NAMESPACE // force user to do 'using' himself Really, you should only use this if you are trying to combine this library with another library (MITE, Midas 2k) in the same .cc file, but you also may just want to force the user to use namespaces and have them deal with them appropriately. In a perfect world, all the PTOOLS code would have been namespaced already and this wouldn't be an issue: a good chunk of this code, however, migrated from ARM C++ code. You can, for example, turn off the 'using' on a file-by-file basis like: #include "mite.h" Has conflicting symbols, like HashTableT #define OC_FORCE_NAMESPACE #include "ocport.h" using OC::HashTableT; Forces user to manually use/qualify OC In general, the default should work fine: you probably only need this if (a) you want to force your user to deal with manual namespaces or (b) link OC with MITE or M2k in the same process/file * All the C++ code in this distribution are by default in the OC namespace, with a using opening it up for all users. All tests and examples in the baseline have an #ifdef that allows the user to compile in either mode. The default is namespacing turned off for backwards compatibility, otherwise it opens up all names in the namespace: #if defined(OC_FORCE_NAMESPACE) using namspace OC; // open up OC namespace #endif The purpose of this is two-fold: allow the PTOOLS option tree to link with the MITE option tree (they have a LOT of code in common) or to simply link PicklingTools code with any baseline with name conflicts (esp. M2k). * Fixed multiple minor warnings (discovered by g++ 4.4.3 and 4.4.4) when using char* when should be using const char *. * Added a comment in ocstring.h to show how to turn off the strict aliasing warning/detection for OCString (g++ 4.4.x seems to be extra zealous in finding these). Also added (in a comment) the option to the Makefile.Linux to show you might set the flags if this is a problem. * Found a bug in the p2common.h file (this affects all C++ versions): the dump4byteInteger and dump8ByteInteger were checking integers incorrectly and dumping incorrectly in one instance. It was a latent error spotted by the g++ 4.4.3: the "bug" was actually masked because the if test was malformed and caused it to do the right thing most of the time. * Moved OpenContainers 1.6.6. to OpenContainers 1.6.7 (namespace changes), updating version numbers. Changed the runall scripts to run all tests and examples with all three models: o default (namespace OC with 'using namespace OC;' in ocport.h), o strict via -DOC_FORCE_NAMESPACE (nameapace OC with no default using) o severe backwards compatible cia -DOC_EXPERT_NAMESPACE__NO_NAMESPACES (which completely turns off namespaces) Numeric array work in the C++ area: * When using Pickling Protocol 0 _or_ 2, if the array has no shape:: (Numeric.zeros((), typecode='i')) # no shape then Python pickles the Numeric array slightly differently than if the user specifies a shape:: (Numeric.zeros((2,2), typecode='i')) # 2x2 Numeric array of int It's rare that a user should do a no-shape array, but if the user wants to use an "empty Numeric array" with type as a placeholder, it should still be legal. This affects all the C++ code that deals with dumping and loading Numeric arrays (both protocol 0 and 2). This seems to happen in 2.4-2.6 for sure. This causes fixes to be needed in two places: how PicklingProtocol 0 loads and Protocol 2 loads (we don't need to fix dumps, be cause we can't produce shapeless arrays from C++ with Array<>). * Added some Numeric shapeless arrays to midastalker_ex2.py for some testing for Protocol 0 and 2, * Added test for shapeless arrays in p2_test.cc Pickling Protocol 0 work in the C++ area: * Discovered we weren't handling strings with binary data correctly: Python turns those escape sequences back into binary data. Fixed. Pickling Protocol 2 work in the C++ area: * When using an ArrayDisposition of Numeric or Array with Protocol 2, we underestimate the size of the buffer needed for a dump. Fixed. All server examples: Xm, Python and C++ * Added an exception catch block: All servers have an "active thread", so an exception can cause the server to come down. The sendBllocking will throw an exception if a client fails, so updated all examples to show how to handle this. In the M2k area: * same problem as the C++ area with Numeric arrays with no shape (see above). This causes fixes to be needed in two places: how PicklingProtocol 0 loads and Protocol 2 loads: very similar fixes as above (P0 reuses the code, so only added a functional TupleLength: P2 required a little code change). * same problem with Pickling Protocol 0: minor change to m2opalpython.h to handle fix to Pickling Protocol 0. * adjusted the m2protocol2.cc so as to have the buffer size adjustments (buffer was being underestimated) In the Xm area: * By default, the new PTOOLS option tree should work with old code (you will need to recompile and relink everything that uses the PTOOLS option tree, but no code changes). There are directions on how to deliver a version of the option tree with strict namespacing enforced, see the README in the Xm area. The default should fix any link problems PTOOLS had when linking with MITE/M2k. * Added the t4val, t4tab, pipetab as part of the conditional OC namespace * Fixed all host primitives to compile with/without namespaces, i.e.: #if defined(OC_FORCE_NAMESPACE) using namspace OC; // open up OC namespace #endif * Updated the libraries.cfg and primitives.cfg. * all fixes from C++ and opencontainers 1.6.7 area (see above) forwarded to Xm area