themoos / core-moos Goto Github PK
View Code? Open in Web Editor NEWA very light weight, easy to use middleware. You will need core-moos above all other components
A very light weight, easy to use middleware. You will need core-moos above all other components
Since commit 1e61cbb in core-moos
, essential-moos
fails to build.
This is the commit in question:
------------------------------------------------------------
commit 1e61cbb23f45b2d3b93568243f0518a13e3b1e9e
Author: Paul Newman <[email protected]>
Date: Sat Jun 10 20:39:37 2017 +0100
putative efficiency in CMOOSCommPkt
5 files changed, 79 insertions(+), 102 deletions(-)
------------------------------------------------------------
and the error message in essential-moos
is this:
<redacted>/essential-moos/Essentials/pMOOSBridge/MOOSUDPLink.cpp:173:19: error: no member named 'Fill' in 'CMOOSCommPkt'
PktRx.Fill(pBuffer+q,nRqd);
~~~~~ ^
1 error generated.
Hi, I'm new to MOOS. I want to use time from external source (ROS). Is it enough to modify MOOSLocalTime(). Regards,
core-moos/Core/libMOOS/Utils/MOOSUtilityFunctions.cpp
Lines 232 to 308 in 2494242
There is a race condition between threads in the MOOSDB caused by getprotobyname and getprotobynumber in XPCGetProtocol.cpp. The result is that the tcp server in the MOOSCommServer can be set as UDP instead of TCP resulting in the listen call continuously throwing an 'operation not supported' exception and putting the MOOSDB into a busy loop.
The solution is to change the getprotobyname and getprotobynumber calls in XPCGetProtocol.cpp to the thread-safe reentrant versions, getprotobyname_r and get protobynumber_r. The Linux Man page for getprotobyname_r provides a good example of the changes necessary.
Is there a reason for multiple of these these lines to have const on them twice?
This has broken pymoos (https://github.com/davidhodo/pymoos) bindings and how boost-python detects the return values.
The user should have the option to compile libMOOS as a static archive (.a) or shared library (.so).
Currently, the CMakeLists.txt for libMOOS is hard-coded to build a static archive.
Hi,
This is a minor issue: MSVC complains about Stop() not returning a value:
bool Stop()
{
Thread_.Stop();
}
should be (I guess):
bool Stop()
{
return Thread_.Stop();
}
Best,
JL
Some modifications are needed to successfuly MOOS with AppCasting under Windows.
#ifdef _WIN32
#include <io.h>
#endif
~~if(!MOOSStrCmp(term_reporting, "true") && (isatty(1) == 0))~~
#ifdef _WIN32
if(!MOOSStrCmp(term_reporting, "true") && (_isatty(1) == 0))
#else
if(!MOOSStrCmp(term_reporting, "true") && (isatty(1) == 0))
#endif
When using timewarp, m_dfAppStartTime
shouldn't be multiplied by timewarp:
core-moos/Core/libMOOS/App/MOOSApp.cpp
Line 344 in 64c9750
The previous line should be :
m_dfAppStartTime = MOOSTime(false);
Hi there,
I'm trying to run moos inside a docker container derived from Ubuntu 18.04. I want to install only the bare minimum of apt packages to reduce the image size. I'm doing so by passing --no-install-recommends
to apt install which prevents installing recommended/suggested packages.
However, I found out that if I pass --no-install-recommends
to apt install, then MOOSDB and most other ivp binaries compile but don't run correctly and throw XPCException. This is being thrown somewhere in libMOOS/Comms.
Meanwhile, all is well if I don't pass --no-install-recommends
and install all recommended/suggested packages, but obviously this makes the image size pretty big.
This makes me think there's an implicit runtime dependency for XPC communication. I'm trying to figure out what exactly it is, and was wondering if you have a pointer.
For your reference, here's a list of apt packages. The exception happens in both runtime and compile time images.
Runtime image:
Compile time image:
The MOOSDB should reset the console color after the server audit lines. (line 110 of ServerAudit.cpp)
Iterate is delayed after receiving mail. Even indefinitely if mail is regular and faster than app_tick.
OnNewMail is always called as soon as mail arrives, even if max_app_tick should be limiting it.
Reproduction:
Test app
main --moos_app_tick=1 --moos_max_app_tick=1 --moos_iterate_mode=2
umm -p=TEST_VAR:10@2
#include <MOOS/libMOOS/App/MOOSApp.h>
#include <iostream>
#include <chrono>
using namespace std::chrono;
class TestApp : public CMOOSApp
{
bool OnConnectToServer() override;
bool OnNewMail(std::list<CMOOSMsg>& Main) override;
bool Iterate() override;
private:
steady_clock::time_point iter_time, mail_time;
int mail_count{0}, iter_count{0};
};
int main(int argc, char** argv){
TestApp App;
std::cerr << "Running...\n";
App.Run("TestApp", "mission.moos", argc, argv);
std::cerr << "Done\n";
}
bool TestApp::OnConnectToServer() {
std::cerr << "OnConnectToServer\n";
Register("TEST_VAR", 0);
return true;
}
bool TestApp::OnNewMail(std::list<CMOOSMsg>& mail) {
auto now = steady_clock::now();
double dt_s = duration_cast<duration<double>>(now - mail_time).count();
mail_time = now;
std::cerr << "\nOnNewMail " << mail_count++
<< " " << dt_s << ": " + std::to_string(mail.size()) + "\n";
for(CMOOSMsg& msg : mail){
msg.Trace();
}
return true;
}
bool TestApp::Iterate() {
auto now = steady_clock::now();
double dt_s = duration_cast<duration<double>>(now - iter_time).count();
iter_time = now;
std::cerr << "\nIterate " << iter_count++ << " " << dt_s << "\n";
return true;
}```
We’ve found a bug that’s can cause a segfault in MOOSDB, I've attached a patch for a fix as .txt files as that's what's supported for upload. There are possible performance implications with our patch, as we're now mutex locking ProcessClient which may have been concurrent before, and now is more sequential. This can only be avoided with C+17 shared_lock or some complicated back-port of that to C++11 ( our compiler standard).
The bug ultimately caused a segfault in MOOSDB at ThreadedCommServer.cpp#388:
bool ThreadedCommServer::ProcessClient(ClientThreadSharedData &SDFromClient,MOOS::ServerAudit & Auditor)
...
for(q=m_ClientThreads.begin();q!=m_ClientThreads.end();++q)
{
ClientThread* pClient = q->second;
if(m_pfnFetchAllMailCallBack!=NULL && pClient->IsAsynchronous())
because pClient is null/uninitialised. This is caused by a race condition with:
bool ThreadedCommServer::AddAndStartClientThread(XPCTcpSocket & NewClientSocket,const std::string & sName)
...
m_ClientThreads[sName] = pNewClientThread;
Adding to m_ClientThreads needs to be mutually exclusive with any other operation on the map and needs guarding with a mutex (only with the Add though, multiple Reads can happen at once).
Minor point but not sure whether the tone in this help is appropriate in https://github.com/themoos/core-moos/blob/24942423ce3f3ebdb3cee876edb71bdd04dc5555/Core/tools/ktm/ktm.cpp
void PrintHelpAndExit()
{
std::cerr<<"Kill The MOOS (ktm)\n";
std::cerr<<"--channel=<address> address to issue kill on \n";
std::cerr<<"--port=<int> port to issue kill on \n";
std::cerr<<"--phrase=<string> pass phrase which Suicide listeners are keyed to\n";
std::cerr<<"--all pass to network, it is a massacre\n";
std::cerr<<"--query find out who would jump\n";
std::cerr<<"--name=<string> only apply if matches pattern\n";
If:
Then:
I believe this is because ThreadedCommServer::ProcessClient() only iterates through asynchronous client threads when data is received, and MOOSDBVar changes do not trigger this processing. Thus, poking a variable with uMS or any client transmission will force processing.
the CMakeLists.txt was updated to reflect the version of 10.5, but an associated tag was not created for it. Could that be done?
CMOOSCommsClient::Notify("foo", 3) will not compile (at least on g++ 4.7.3-1ubuntu1) because the second parameter is an int, and there is no overload for int.
Notify called with an int used to implicitly cast to double in pre-10 versions of MOOS. This behavior should be restored.
I have discovered what I think is a race condition in the MOOSDB related to wildcard subscriptions. It only seems to happen when you have this situation:
App1 registers for message “foo_” from “_”
App2 registers for message “foo”
App3 sends message on “foo”
Note the two different ways to register for messages. Now only App2 will receive the message. If you change this pattern in almost any way, it works fine. For example if App2 registers before App1, or if App3 sends before App2 registers, or if App2 uses wildcard registration then both App1 and App2 will receive the message.
This issue is present in the trunk on Oct. 2 2013.
This is pretty easy to test with a few dead-simple apps. I launched them with pAntler and used a long MSBetweenLaunches to ensure things start in the order I want. Then put a delay in the publishing for enough time for everything to start.
This can also be tested with the umm utility:
Open 4 terminals
in one
./MOOSDB
in the second
./umm -w='foo_:_' --verbose
in the third
./umm -s=foo --verbose
in the forth
./umm -p=foo
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.