zerocm / zcm Goto Github PK

Great for debugging. Obviously, making this able to be turned on/off via a config would be required

actually was causing the full system to crash when the limit was hit

[22/51] Processing jar_create: build/zcm/java/classes/zcm/zcm/MessageAggregator$Message.class build/zcm/java/classes/zcm/zcm/MessageAggregator.class build/zcm/java/classes/zcm/zcm/Provider.class build/zcm/java/classes/zcm/zcm/URLParser.class build/zcm/java/classes/zcm/zcm/ZCM$SimpleSubscriber.class build/zcm/java/classes/zcm/zcm/ZCM$SubscriptionRecord.class build/zcm/java/classes/zcm/zcm/ZCM.class build/zcm/java/classes/zcm/zcm/ZCMDataInputStream.class build/zcm/java/classes/zcm/zcm/ZCMDataOutputStream.class build/zcm/java/classes/zcm/zcm/ZCMEncodable.class build/zcm/java/classes/zcm/zcm/ZCMJNI.class build/zcm/java/classes/zcm/zcm/ZCMSubscriber.class -> build/zcm/java/zcm.jar
../zcm/java/jni/zcm_zcm_ZCMJNI.c: In function ‘getNativePtr’:
../zcm/java/jni/zcm_zcm_ZCMJNI.c:25:12: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]
return (Internal*) nativePtr;
^
../zcm/java/jni/zcm_zcm_ZCMJNI.c: In function ‘setNativePtr’:
../zcm/java/jni/zcm_zcm_ZCMJNI.c:31:42: error: cast from pointer to integer of different size -Werror=pointer-to-int-cast->SetLongField(env, self, fld, (jlong)zcm);
^
cc1: all warnings being treated as errors

Allow the user to handle the incoming message data in a separate thread via a deep copy of the message. Would throw out any messages that arrived while the user was blocking

again, on/off configurable, but this would be nice to have for cross compiling for embedded systems

Nodejs errors on page reload frequently Assertion failed: pfd.revents & POLLIN (signaler.cpp:193) Aborted (core dumped) this may be a problem with a zmq socket getting handled by multiple threads

We currently have support in zcm-gen, but no binding of the actual zcm core library.

Should definitely include a mention in the tutorial of needing to set JAVA_HOME correctly. Probably just include these lines somewhere in a file that can just be sourced:
if [ -z ${JAVA_HOME+x} ]; then
export JAVA_HOME=$(readlink -f /usr/bin/javac | sed "s:/bin/javac::")
fi

Currently, the NodeJS implementation will only work on x86-64 machines. Extend to support more targets.

ZCM will not build under Python 2.4. In the python package Collections, defaultdict was not added until Python 2.5, as a result the application will not build.

1. check if there are changes from newer releases of LCM (including the 1.3 that just landed) that we want to pull into ZCM

2. check out this LCM pullreq to see if we want it: lcm-proj/lcm#39

If this should be deprecated because of the existence of the cpp zcm-spy-lite, we should just delete it, otherwise, we should rename it as something like: zcm-spy-clite so the tab completion on the command line is more consistent. (ie zcm-l"tab" should always go to logging related tools and zcm-s"tab" should always go to spy related tools)

From Isaac:

All urls should have clearly documented options as well as default arguments for all options. Ideally, the help-text that they register with the transport registrar would provide all of this information for the user at runtime. Example of this would be the udpm url defaulting to ttl=0 (instead of forcing the user to type ?ttl=0

Include directions on how to compile a .so and give that so to zcm-spy-lite

This appears to be an issue in LCM as well

Parsing user input in csvreader & csvwriter, for example, is quite verbose. Would be nice to abstract some of that away.

From Isaac:

How do we want to add embedded transports to the repo (it'd be nice for people to push back even chip specific transports, just need to think about how to organize / QA them)

at very least, it tries to load all of the log file into ram (which quickly breaks with large logfiles on constrained systems).

Currently, it appears that you can only query the MTU of the transport itself. This should be available for both blocking and nonblocking api.

Should consider how to allow the user to ask for an extrapolated message if bracketted messages arent available

ZeroMQ has an unfortunate subtlety where upon opening a socket, the first message or two are not successfully received. This is known behavior in ZMQ. ZCM inherits this behavior for the IPC transport as a result.

TODO: work around this issue or replace the IPC implementation entirely.

From Isaac:

Making the core implementation of zcm C++ (e.g. blocking.cpp) means we can't link a C program to a static library version of zcm. This came up as I was trying to build some tests for the zcm core. Basically, I was trying either to link to the zcm shared object without installing it (very hard without messing with LD_LIBRARY_PATH) and decided it would be better just to use a static version of the zcm library for local tests. However, if you try to make a C test program and link to the static libraries you get a whole bunch of errors. This is easily fixed by changing to only C++ local tests, but we should be aware of it.

ie the version without the gui

We should add a comment to the emitted zcmtypes that indicate that they intentionally have no copy constructor explicitly defined; they use the implicit copy constructor. This works because there is no dynamic memory in zcmtypes. Any dynamic fields are represented as vectors which have copy constructors defined in stdlib.

Break-case: running zcm-spy while broadcasting laser messages. Trying to use april.zcm.LaserPlugin to view the Laser point cloud and received a segfault from libzcm.so in the UDP code.

Do we already have this through Java?

Currently the NodeJS zcm-gen implementation doesn't work correctly for all zcmtypes. In particular, the type hashes for nested types are incorrect.