Robotics Service Bus: Issueshttps://code.cor-lab.de/https://code.cor-lab.de/favicon.ico?14019720732016-06-12T13:36:55ZOpen Source Collaboration Platform
Redmine Enhancement #2563 (New): Flush indices based on combined memory consumption of all indiceshttps://code.cor-lab.de/issues/25632016-06-12T13:36:55ZJ. Moringenjmoringe@cor-lab.uni-bielefeld.de
<p>The current approach of independent flush strategies for all indices is unsuitable for controlling the maximum memory used by indices.</p> Tasks #2559 (New): Scope renaminghttps://code.cor-lab.de/issues/25592016-06-08T12:17:41ZJ. Moringenjmoringe@cor-lab.uni-bielefeld.deTasks #2479 (New): Bag as bus server crashes in case client is closedhttps://code.cor-lab.de/issues/24792015-12-11T12:37:58ZJ. Wienkejwienke@techfak.uni-bielefeld.de
<p>I have seen this several times in case I terminate a bus client:<br /><pre>
jwienke@cinnabar ~ [1]> /media/local_data/jwienke/sensor-fusion/bin/rsbag play --loop=t /vol/toolkit/tutorial-sensor-fusion-with-rsb/data/tutorial_datafusion.tide socket:
2015-12-09T18:02:17.672763+01:00 40.42 % 326 [ 0, 808]
Error processing entry #<EVENT /kinect2/ #(10 6 10 2 8 ...) (850) E3E058D2> from
#<REPLAY-BAG-CONNECTION (2) {1015A7E2F3}> during replay according to strategy #<RECORDED-TIMING [0, *[ {1015A74F03}>.
Caused by:
> Couldn't write to #<SB-SYS:FD-STREAM for "socket 127.0.0.1:55555, peer: 127.0.0.1:53256" {100CB814F3}>: Broken pipe
<WARN> [13:36:24] [Worker for #<BUS-CONNECTION open #(127 0 0 1):53256>] rsb.transport.socket bus-connection.lisp (%make-error-policy bus-connection-error-policy) -
When #<BUS-CONNECTION closing: :RECEIVE ADDRESS?:PORT?> executed error
policy, error closing connection:
Couldn't write to #<SB-SYS:FD-STREAM
for "socket 127.0.0.1:55555, peer: 127.0.0.1:53256"
{100CB814F3}>:
Broken pipe
jwienke@cinnabar ~ [1]> /media/local_data/jwienke/sensor-fusion/bin/rsbag play --version
/media/local_data/jwienke/sensor-fusion/bin/rsbag play version 0.13.42-g6f687b5
SBCL version 1.2.15
RSB version 0.13.89-gac01044
RSBAG version 0.13.41-gda486e6
RSBAG-TIDELOG version 0.13.41-gda486e6
</pre></p> Enhancement #2376 (New): Allow to deduplicate participants in introspection exporthttps://code.cor-lab.de/issues/23762015-08-31T11:34:37ZJ. Wienkejwienke@techfak.uni-bielefeld.de
<p>When using <code>bag introspect</code> it would be nice if one could specify something like primary keys for the different elements in the introspection tree so that e.g. participants of the same type and scope, but different IDs could be deduplicated.</p> Tasks #2216 (New): Consider using git subtrees instead of submoduleshttps://code.cor-lab.de/issues/22162015-04-02T12:51:44ZJ. Moringenjmoringe@cor-lab.uni-bielefeld.de
<p>We can all agree, that our submodule setup sucks.</p>
<p>We discussed and rejected gitslave: <a class="external" href="https://projects.cor-lab.org/projects/corcse/wiki/GitSlave">https://projects.cor-lab.org/projects/corcse/wiki/GitSlave</a></p>
<p>Nicolas Hafner suggests git subtrees, which I (jmoringe) did not know about. We should probably look into that possibility.<br /><a class="external" href="http://blogs.atlassian.com/2013/05/alternatives-to-git-submodule-git-subtree/">http://blogs.atlassian.com/2013/05/alternatives-to-git-submodule-git-subtree/</a></p> Bug #2150 (New): Specification of preferred converters should be reconsideredhttps://code.cor-lab.de/issues/21502015-01-04T08:53:22ZR. Haschkerhaschke@techfak.uni-bielefeld.de
<p>From my point of view, the specification of preferred converters may be conceptually at the wrong level (currently at the level of transports).</p>
<p>Considering Listeners, they should receive the same data type, irrespective of the used transport. If there are several converters for a specific wire-schema, a preference needs to be given at the level of the Participant.<br />Considering Informers, there might be different wire-schemas to be used for different connectors. Hence, here the configuration at the transport level is sensible.</p>
<p>Hence, there is a need to handle in and out connectors differently!</p>
<p>Also, there should be an application-wide (default) converter preference, which should be used as args to rsb::converter::Repository::getConvertersForDeserialization and getConvertersForSerialization instead of the undecided default. The mentioned methods are used all over the framework and will fail if ambiguous converters are registered.</p>
<p>This application-wide default should be initialized from the rsc config system before the plugin system can register converters. This will allow meta converters (that use other converters to extract stuff, e.g. EventsByScopeMapConverter) to be correctly registered when ambiguous converters already exist. Otherwise success depends on load order!</p> Feature #2138 (New): Allow constructing scopes from a list of component strings (potentially sing...https://code.cor-lab.de/issues/21382014-12-17T13:13:52ZJ. Moringenjmoringe@cor-lab.uni-bielefeld.de
<ul>
<li>Java</li>
<li>C++</li>
<li>Python</li>
</ul> Tasks #2111 (New): Document converter disambiguation (programmatic and via config file) https://code.cor-lab.de/issues/21112014-11-27T12:30:35ZS. Wredeswrede@cor-lab.uni-bielefeld.de
<p>Cf. <code>rsbvideoreceiver</code> refactoring branch for an example on how to do this. Location to be decided, maybe troubleshooting.</p> Feature #1870 (New): Allow (optional) parallel method callshttps://code.cor-lab.de/issues/18702014-05-08T12:36:06ZJ. Moringenjmoringe@cor-lab.uni-bielefeld.de
<ul>
<li>Johannes will commit patches containing a short-term workaround for C++ and Java</li>
</ul> Feature #1769 (New): Store start and end timestamp of recordinghttps://code.cor-lab.de/issues/17692014-02-14T11:41:13ZJ. Moringenjmoringe@cor-lab.uni-bielefeld.de
<p>As opposed to timestamps of first/last recorded events.</p> Bug #1665 (New): Support common installations (to simlify cross compiliation)https://code.cor-lab.de/issues/16652013-12-03T10:46:15ZS. Herbrechtsmeiersherbrec@cit-ec.uni-bielefeld.de
<p>The current rsb projects contains many functions which are only needed for the local deployment. As most of this functions are not optional they don't allow a common installation and make the installation unusable in cross compiler environments. The main reason is that cmake and pkg-config files are not relocatable because they contain full paths from the installation or build time.</p>
<p>In common installation the following should not be needed: <br />- Add the release version to project and library names (example: rsb0.9 in rst-converters0.9.pc)<br />- Decode the so version in pkg-config files (example: librsb.so.0.9 in rsb.pc)<br />- Use so files instead of <del>l{libname} in pkg-config files (example: ${libdir}/librsb.so.0.9 in rsb.pc)<br /></del> Set full paths in cmake files (example: RSC_DIR in RSBConfig.cmake)</p>
<p>Additionally cmake files should save the dependency projects and use FIND_PACKAGE to detect the paths.</p> Feature #1102 (In Progress): Use data type definitions stored in log fileshttps://code.cor-lab.de/issues/11022012-07-27T08:53:25ZJ. Moringenjmoringe@cor-lab.uni-bielefeld.de
<p><code>bat-{cat,play,merge}</code> should use the data type definitions stored in log files when possible. This avoids loading IDL files all the time.</p> Enhancement #551 (Feedback): Language-specific configurationhttps://code.cor-lab.de/issues/5512011-09-07T08:09:08ZJ. Moringenjmoringe@cor-lab.uni-bielefeld.de
<p>We already have things like<br /><pre>
[transport.spread.converter.cpp]
bool = bool
image = IplImage
</pre><br />in the current configuration scheme.</p>
<p>With the introduction of more technical tunable parameters (e.g. <a href="https://code.cor-lab.de/issues/548" class="issue tracker-5 status-3 priority-4 priority-default closed parent" title="Threadless RSB (Resolved)">#548</a>, <a href="https://code.cor-lab.de/issues/550" class="issue tracker-2 status-3 priority-4 priority-default closed child" title="Selection of Receiving Strategy (Resolved)">#550</a>, <a href="https://code.cor-lab.de/issues/551" class="issue tracker-5 status-4 priority-5 priority-high3" title="Language-specific configuration (Feedback)">#551</a>), it seems unlikely that a single configuration file can be used to configure all language implementation simultaneously.</p>
Two solutions come to mind:
<ul>
<li>In addition to <code>rsb.conf</code>, have language-specific configuration file like <code>rsb-cpp.conf</code> that take precedence over the generic one</li>
<li>Extend the approach mentioned above and introduce language-specific options like <code>eventprocessing.receivingstrategy.cpp</code></li>
</ul> Enhancement #351 (New): Revise Converter Selection Mechanismhttps://code.cor-lab.de/issues/3512011-06-09T10:33:38ZJ. Moringenjmoringe@cor-lab.uni-bielefeld.de
<p>The converter selection mechanism has partially been extended to support more powerful selection strategies (see <a href="https://code.cor-lab.de/issues/304" class="issue tracker-4 status-3 priority-4 priority-default closed" title="Wildcard Mechnism for Converter Selection (Resolved)">#304</a>).</p>
However, the following aspects have not been adopted to this extension, yet:
<ul>
<li>The Java implementation does not have an implementation of any converter selection mechanism</li>
<li>Configuration
<ul>
<li><code>ParticipantConfig.Transport</code> is not suitable for extended selection strategies</li>
<li>Syntax and semantics for configuring new converter selection strategies has not yet been specified</li>
<li>Obviously, this specification has not yet been implemented</li>
</ul></li>
</ul> Bug #344 (New): C++ Spread: Transport-level errors are not handled properlyhttps://code.cor-lab.de/issues/3442011-06-05T15:37:24ZJ. Moringenjmoringe@cor-lab.uni-bielefeld.de
The ReceiverTask class has (at least) two potential causes of errors
<ul>
<li>Spread errors (currently ignored)</li>
<li>Converter errors (currently not handled, ignored at call site)</li>
</ul>