The payloads-unpacker is a module which decodes JAVA-payloads to C++ payloads. It is a completely new project doing native-unpack without any JAVA to C++ interface like JNI. The most significant difference from triggerUtil-C++ is a recursive structure imitated from JAVA-payloads. The payload-unpacker can reconstruct any complicated nesting-payload without special code. This feature makes much easier to follow up the update of JAVA-payloads.
The payload-unpacker is an IceTray-compliance project so that must compile
with IceTray. However, in order to check a reliability the unpacker itself
and to provide monitoring tools to offline-users, it also equips a test environment
based on ROOT. Unfortunately, these environments conflict sometimes. Therefore,
payload-unpacker equips the wrapper classes to switch these environments: when
you compile it as an IceTray module then it will be ROOT-free module.
See samples of wrapper class.
Basically, it follows normal IceTray module structure. The "stand-alone" directory is added to do ROOT compile and analysis, which doesn't affect IceTray compile. The core of unpacker consist of three sub-modules: base, unpacker, payloads, which used by both IceTray module and ROOT module. Any class placed in these directory must inherits PXXObject base class. As an IceTray project, it works as an independ library though it uses shared pointers and logging system.
The stand-alone directory has place folder of compiled-binary, root scripts, and additional analysis codes under the src directory. "make install" command will work below the src directory, even though some sub directory doesn't have source code.
The automatic test code, should be implemented all IceTray project, is placed
directly under the private directory.
Currently an unpack test code is placed inside the directly though it fails
at debug output (Unpack itself looks working well, but now we cannot checking
it).
There is a problem at compile when a class has a base class several times
in its inheritance tree. The original design of triggerUtil in JAVA implements
an interface several times, so I tried to copy the structure using multiple-inheritance
but couldn't compile.
Therefore, temporary I gave up to make the inheritance tree inside interfaces
(PXXIPayload, PXXITriggerPayload, etc), then you have to do dynamic_pointer_cast
when you want to use PXXIPayload::GetPayloadLength() from an PXXITriggerPayload
object, for example.
The virtual inheritance would be one solution, however, it makes the inheritance
tree extremely complicated and difficult to distinguish which (overridden)
function will be called.
I will try to improve the temporary structure using virtual inheritance as
less as påossible (It wouldn't change interface functions itself).
This is a structure of PXXEventPayload. The difference between v1 and v2 is only inside the PXXEventPayloadRecord and it is invisible from users.
The latest version of payloads-unpacker is available from sandbox area.
Use svn to get them with following command:
$ svn co http://code.icecube.wisc.edu/svn/sandbox/payloads-unpacker payloads-unpacker
To compile with IceTray, just follow same procedures as normal projects at $I3_WORK
$ source env.sh (or env.csh)
$
make -C payloads-unpacker all-tests
To compile with root, you have to make sure whether following environments are defined correctly:
export ROOTSYS=$HOME/work/root/pro (or your root dir)
export LD_LIBRARY_PATY=$LD_LIBRARY_PATH:$ROOTSYS/lib
export DYLD_LIBRARY_PATY=$DYLD_LIBRARY_PATH:$ROOTSYS/lib
export PATH=$PATH:$ROOTSYS/bin
Then, type
$ cd payloads-unpacker/stand_alone/src
$ make install
However, sometimes it doesn't work because of wrong include path.
This makefile uses a script placed in
payloads-unpacker/stand_alone/bin/cxxdepends
to generate include path flag.
The script is using a function
gcc -print-search-dirs
to get informations for include path, however, sometimes the output format would differ from my environments then the script doesn't work correctly.
If you saw the problem, please try
$ sh payloads-unpacker/stand_alone/bin/cxxdepends
then modify the script until you can get correct include path.
For example, my output would be as following.
-I/usr/include/ -I/usr/include/gcc/darwin/3.3/c++ -I/usr/include/gcc/darwin/3.3/c++/ppc-darwin -I/usr/include/gcc/darwin/3.3/c++/backward -I/usr/local/include -I/usr/include/gcc/darwin/3.3/c++/.. -I/usr/lib/gcc-lib/ppc-darwin/3.3/../../../../ppc-darwin/include
Currently it has only short test program. Try
$ cd $I3_WORK
$ Linux-i386(or your system)/bin/payloads-unpacker-test -s all
Now, the test succeeds to unpack EventPayload (v1 and v2) though it fails at dump output.
Try
$ cd payloads-unpacker/stand_alone/analysis
$ root -b EventPayloadTest.C
then you will get Dump outputs.
payloads-unpacker have a function to dump out which format is almost same
as that of JAVA triggerUtil.
See following samples.
Last updated 12/9/2005
Contact : Kotoyo Hoshina @ UW Madison