Robotics Systems Commons: Issueshttps://code.cor-lab.de/https://code.cor-lab.de/favicon.ico?14019720732016-05-26T11:50:33ZOpen Source Collaboration Platform
Redmine Feature #2550 (New): synchronized priority_queuehttps://code.cor-lab.de/issues/25502016-05-26T11:50:33ZM. Goerlichmgoerlic@techfak.uni-bielefeld.de
<p>It would be cool to have a priority_queue variant of the SynchronizedQueue<M>.</p>
<p>I didn't think this through but maybe the queue could be an argument on the constructor of the existing SynchronizedQueue<M>, defaulting to the std::queue.</p> Enhancement #2538 (New): Include SIGHUP in signal handling codehttps://code.cor-lab.de/issues/25382016-04-27T10:10:44ZJ. Wienkejwienke@techfak.uni-bielefeld.de
<p>In case a terminal is closed, running processes receive SIGHUP. Therefore we should also handle this signal type.</p> Bug #2472 (In Progress): Under windows rsc::misc timestamps are in milliseconds.https://code.cor-lab.de/issues/24722015-12-10T14:32:41ZM. Goerlichmgoerlic@techfak.uni-bielefeld.de
<p>under windows the send timestamp of the spread transport seems to be in milliseconds.</p>
<p>As Jan already found out the problem resides in the rsc::misc function for gathering the current timestamp (sorry, forgot the name...).</p>
<p>Here is a printout of a rsb-loggercpp that shows the data received from the windows host on a linux machine. Note the send timestamp.</p>
<pre>
-------------------------------------------------------------------------------
Event
Scope /kinect2_old/persontracking/state/5/
Id EventId[participantId = UUID[2c098dad-ab20-4e39-8c70-39330fb7a5c4], sequenceNumber = 2]
Type bytearray
Origin 2c098dad-ab20-4e39-8c70-39330fb7a5c4
Timestamps
Create 2015-Dec-10 15:16:13.341861+??:??
Send 2015-Dec-10 15:16:13.341000+??:??
Receive 2015-Dec-10 15:16:13.342695+??:??
Deliver 2015-Dec-10 15:16:13.342696+??:??
Payload (bytearray, length 4)
0x0000 0a 02 08 05
-------------------------------------------------------------------------------
</pre> Enhancement #2184 (Feedback): improve logging system to nicely play with log4cxxhttps://code.cor-lab.de/issues/21842015-02-23T02:44:20ZR. Haschkerhaschke@techfak.uni-bielefeld.de
<p>Current implementation of logging doesn't play nice with log4cxx, <br />i.e. a LoggingSystem that already provides hierarchical loggers.<br />In this case explicitly setting the log levels down the hierarchy,<br />overrules any settings made in log4cxx's own config files.</p>
Hence, I modified the code along the following guide lines:
<ul>
<li>loggers are created lazily on demand<br /> The <code>LoggerTreeNode</code> maintains the hierarchy (and explicitly set log levels).<br /> However, Loggers themselves will be only created by <code>LoggerFactor::getLogger()</code>.</li>
<li><code>LoggingSystem::createLogger</code> expects second argument now with desired log level.<br /> LoggingSystems like log4cxx want to ignore this argument, but rely on their hierarchy.</li>
<li>bool <code>LoggingSystem::needsRecursiveLevelSetting()</code> is used to choose
<ul>
<li>recursive TreeLevelUpdater for non-hierarchic LoggingSystems</li>
<li>SimpleLevelUpdater for hierarchic systems</li>
</ul>
</li>
<li>Do not use shared_ptrs for <code>LoggerTreeNode::assignedLevel</code>.<br /> This was only used to know whether a level was explicitly set. Use a bool instead.</li>
<li>Simplified <code>LoggerTreeNode::Visitor</code>
<ul>
<li><code>parentLevel</code> argument was never used --> removed, can be retrieved by <code>node->getLevel()</code></li>
<li>visiting includes called node -> reduces code duplication</li>
</ul></li>
</ul>
<p>Consequences:<br />As long as no log levels are set explicitly by rsc means, the<br />LoggingSystem can continue to use its own configuration mechanism.<br />Calling <code>setLevel()</code> overwrites these settings, but only for the current node.</p> Enhancement #2063 (In Progress): simplify clumsy usage of DebugToolshttps://code.cor-lab.de/issues/20632014-10-18T08:49:18ZR. Haschkerhaschke@techfak.uni-bielefeld.de
<p>Using backtrace functions requires a DebugTools object. Why did you choose for this rather clumsy design?</p>
<p>Instead of:</p>
<pre><code>rsc::debug::DebugToolsPtr dbg = rsc::debug::DebugTools::newInstance();<br />cout << dbg->formatBacktrace(dbg->createBacktrace());</code></pre>
<p>I suggest the following function-based usage:</p>
<pre><code>cout << rsc::debug::formatBacktrace(rsc::debug::createBacktrace());</code></pre>
<p>Having an overloaded convenience function, this can further simplify to:</p>
<pre><code>cout << rsc::debug::formatBacktrace();</code></pre>
<p>As there are no data elements, there is no need for an DebugTools object, isn't it?</p> Enhancement #1836 (New): Move printing of property values into separate functionhttps://code.cor-lab.de/issues/18362014-04-10T16:13:03ZJ. Moringenjmoringe@cor-lab.uni-bielefeld.de
<p>Could be used e.g. here:<br /><a href="/projects/cca/repository/entry/trunk/cca/src/cca/component/Info.cpp#L205" class="source">cca:source:trunk/cca/src/cca/component/Info.cpp#L205</a></p> Tasks #1646 (New): Document logging system configurationhttps://code.cor-lab.de/issues/16462013-10-16T13:32:51ZJ. Moringenjmoringe@cor-lab.uni-bielefeld.de
<p>I am aware that there is no RSC manual so far, but I would like to record the following in case such a manual is written at some point</p>
<blockquote><blockquote>
<p>when I use e.g. classes provided from included libraries, that use the<br />rsc logging functionality, is it possible to set a different log level<br />for these than for the "main" programm? Or maybe even per instance of<br />a class?</p>
</blockquote>
<p>For RSC-based logging, log-levels of individual loggers can be<br />configured based on logger names. Most libraries use fully qualified<br />class names as logger names (e.g. rsb.transport.spread.outconnector),<br />thus referring to individual instances is usually not possible. These<br />names can be referred to in e.g. rsb.conf:</p>
<p>[rsc.logging]<br />rsb.transport.spread.outconnector.LEVEL= ALL | TRACE | DEBUG | ...</p>
<p>or environment variables:</p>
<p>$ export RSC_LOGGING_RSB_TRANSPORT_SPREAD_OUTCONNECTOR_LEVEL=DEBUG ...</p>
</blockquote> Tasks #1451 (Feedback): Clarify configuration, when different rsx version installedhttps://code.cor-lab.de/issues/14512013-03-14T13:23:32ZAnonymous
<p>Clarify how to use find_package to pinn version of rsx dependencies.</p> Bug #1430 (New): Fix debian packaging to conform more strongly to debian policyhttps://code.cor-lab.de/issues/14302013-02-20T07:37:10ZA. Tuleualexandre.tuleu@epfl.ch
<p>I know this is an hassle, but it gives me lot of maintainance nightmare at higher levels because the debian policy is not strongly followed in the debian packaging of librsc.</p>
<p>Please fix the following issues :</p>
<ul>
<li>have a runtime and a dev package.</li>
<li>Make sure runtime package have the same full name than the library (with SONAME). Currently it should be librsc0.9</li>
<li>No header in the runtime package, but in the dev package</li>
<li>No librsc.so in the runtime, but in the dev package a symlink to librsc.so</li>
<li>fixed pkg-config file for this setup (no runtime path, and point simply to -lrsc)</li>
<li>provide a shlibs file for better debian integration. (see section 8.6). Basically it will be used by dpkg to maintain its database of symbols / shared lib dependency</li>
</ul>
<p>This come from the debian manual policy, and could causes problem, especially when using pkg-config to symlink with rsc (which is the case for liboncilla compilation from webots).</p>
<p>Please refer to <a class="external" href="http://www.debian.org/doc/debian-policy/ch-sharedlibs.html">http://www.debian.org/doc/debian-policy/ch-sharedlibs.html</a></p> Bug #1292 (Feedback): Do not set EXTERNAL_INCLUDE_COMMANDS in rsc/rst.pc.in by defaulthttps://code.cor-lab.de/issues/12922012-12-11T10:40:46ZS. Herbrechtsmeiersherbrec@cit-ec.uni-bielefeld.de
<p>The external include commands are not needed by default and are workarounds for external problems. Additionally it doesn't work with the PKG_CONFIG_SYSROOT_DIR option of pkg-config which is useful when cross compiling packages.</p> Bug #746 (New): Logger-Tree in LoggerFactory is not cleaned from abandoned loggers (pruning?)https://code.cor-lab.de/issues/7462011-12-05T18:14:45ZJ. Wienkejwienke@techfak.uni-bielefeld.de
<p>This map is filled up all the time but abandoned loggers are not removed.</p>
<p>A nice solution with the new LoggerProxy would be to invoke a callback of LoggerFactory in the destructor of the proxy.</p> Tasks #655 (New): Add a TaskExecutor implementation for many delayed taskshttps://code.cor-lab.de/issues/6552011-10-19T16:53:27ZJ. Wienkejwienke@techfak.uni-bielefeld.de
<p>The current ThreadedTaskExecutor immediately starts a thread for each task. This naive approach may exceed the thread limit very fast, especially if the majority of tasks is scheduled for future execution using the new method introduced with <a href="https://code.cor-lab.de/issues/652" class="issue tracker-4 status-3 priority-4 priority-default closed" title="Improve task model to allow delays for starting tasks (Resolved)">#652</a>. Hence, we need a special task executor which is better suited for this kind of scheduling.</p> Enhancement #654 (New): Improve cancellation of Tasks in the delay timehttps://code.cor-lab.de/issues/6542011-10-19T16:32:22ZJ. Wienkejwienke@techfak.uni-bielefeld.de
<p>With the current cancellation system of tasks, waiting threads in waitDone can only be reliably notified about the cancellation when the run method is executed by the threaded executor. This costs time and also prevents further optimizations by the executor. Improve this so that:</p>
<ul>
<li>a cancel request before run is called immediately notifies waiting threads and prevents the task from running</li>
</ul> Tasks #166 (New): Make windows subprocess test meaningfulhttps://code.cor-lab.de/issues/1662011-01-04T00:07:47ZJ. Wienkejwienke@techfak.uni-bielefeld.de
<p>Remove the current stub</p>