leapmotion / autowiring Goto Github PK
View Code? Open in Web Editor NEWA C++ Inversion of Control Framework
Home Page: http://autowiring.io/
License: Apache License 2.0
A C++ Inversion of Control Framework
Home Page: http://autowiring.io/
License: Apache License 2.0
AutoInjectable
is deprecated and has weird behaviors. Remove it.
Pointing autowiring_DIR at the root dir (e.g. /path/to/autowiring-0.5.4) doesn't satisfy find_package. Pointing autowiring_DIR at the cmake subdir does work, but I wouldn't consider this to be "the autowiring dir", so it's somewhat misleading.
Recommend putting the relevant cmake files (autowiring-config.cmake and autowiring-configVersion.cmake) in the autowiring root dir.
DispatchQueue
is used for a number of concurrent consumer operations, and it has quite awful scalability. It was originally designed for the single-consumer use case, which means that this circumstance is not necessarily a design flaw, but it's about time that it be updated.
Switch to a lock-free data structure for introducing new entries into the queue (maybe a circular buffer?), and consider platform-specific optimizations to receive notifications of entries added to the queue. Also consider allowing DispatchQueue::WaitForEvent
to consume all events in the queue, and make better use of condition_variable::notify_one
in order to reduce the load on the scheduler.
When playing with DispatchQueueTest.Barrier
line 77, the unit test would fail with std::chrono::nanoseconds
was 1e4, but pass with 1e5
The Linux package contains Autowiring-1.0.3-Linux, not autowiring-1.0.3-Linux as expected.
Connected to leapmotion/PipelineAutomation#864
If you try and set a breakpoint in a function with a couple of autosignals on the callstack, it hangs visual studio. Admitedly, this is a problem with Visual Studio, but in practice it means that debugging code that uses autosignals on windows is extremely cumbersome.
We need a way to obtain the current packet from anywhere under an AutoFilter
. Create a new static method called AutoPacket::CurrentPacket
which will return the current packet when the AutoFilter
is being called, and will return nullptr
when an AutoFilter
is not on the call stack. Use dumb pointers for speed, here, not smart pointers.
This problem was first discovered 27 days ago in http://sf-github.leap.corp/leapmotion/platform/issues/2602
We have spent time debugging it and still don't understand the mechanism. Perhaps this is due to some interaction between auto_prev and auto_out accumulated arguments e.g. const FigureSubFrame* frames[].
We can verify that Figure3D::AutoFilter is called in normal operation, but then the entire AutoFilter function stops getting entered as soon as the 'p' key is pressed in Figure. This happens if and only if an AutoFilter using auto_prev is injected. For example, the problem can be reproduced via HandOpticalFlow :
LeapSvc.exe --run --tracking_version=v2_init
but when the AutoRequired() is removed, the pause/unpause problem goes away.
This applies to injecting HandOpticalFlow, HandOpticalFlowDebug, or HandDepthEstimate all of which use auto_prev. With V3 tracking, many of these classes have become necessary, making this issue more of a concern.
I get this error frequently, but the message is very unhelpful. Surely with RTTI we can at least print out a string representation of the offending type?
There appears to be a race condition in Autowiring where adding an AutoFilter
lambda to a packet while it is processing may result in it being called twice.
This problem happens in Platform (See PR #4044).
Comparisons against std::type_info
are causing substantial performance degradation, we need to address this by removing all uses of std::type_info
wherever it's necessary to perform runtime dynamic type handling. Afterwards, benchmark the speed of Autowired and AutoFilter to determine how much of a performance improvement we get.
My version of Clang crashes while compiling any Autowiring source file. This happens in the preprocessor step while trying to parse cpp11.h. The error message is:
0 clang 0x0000000100c57bb2 main + 12932498
Stack dump:
0. Program arguments: /usr/bin/clang -cc1 -triple x86_64-apple-macosx10.7.0 -emit-obj -disable-free -disable-llvm-verifier -main-file-name NewAutoFilter.cpp -pic-level 2 -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu core2 -target-linker-version 136 -coverage-file /Volumes/Disk Image/os-controls-build/contrib/autowiring/src/autowiring/CMakeFiles/Autowiring.dir/NewAutoFilter.cpp.o -resource-dir /usr/bin/../lib/clang/4.2 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk -D NDEBUG -I /Users/vdods/lm/os-controls/contrib/autowiring/. -I /Users/vdods/lm/os-controls/contrib/autowiring/contrib -I /Users/vdods/lm/os-controls/contrib/autowiring/contrib/websocketpp -I /Users/vdods/lm/os-controls/contrib/autowiring/contrib/gtest-1.7.0/fused-src -I /Users/vdods/lm/os-controls/contrib/autowiring/autowiring -I /opt/local/Libraries/boost_1_55_0-libc++/include -fmodule-cache-path /var/folders/d6/4b7tq65j6r9dcmpj7y2f0w980000gn/T/clang-module-cache -stdlib=libc++ -O3 -std=c++11 -fdeprecated-macro -fdebug-compilation-dir /Users/vdods/lm/os-controls-build/contrib/autowiring/src/autowiring -ferror-limit 19 -fmessage-length 148 -stack-protector 1 -mstackrealign -fblocks -fobjc-runtime=macosx-10.7.0 -fobjc-dispatch-method=mixed -fobjc-default-synthesize-properties -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o CMakeFiles/Autowiring.dir/NewAutoFilter.cpp.o -x c++ /Users/vdods/lm/os-controls/contrib/autowiring/src/autowiring/NewAutoFilter.cpp
I went in and hacked cpp11.h to see what was causing the crash and it was the use of __has_include at line 52. I tried replacing <initializer_list> with in that __has_include directive, and it still crashed. Taking the call to the __has_include directive fixed the crash, but obviously leaves a hole in the functionality. Thus a hack-workaround is to change the line
#define HAS_INITIALIZER_LIST __has_include(<initializer_list>) && __has_feature(cxx_generalized_initializers)
to
#define HAS_INITIALIZER_LIST __has_feature(cxx_generalized_initializers)
This includes
I get a number of build errors when compiling with without USE_LIBCXX (using libstdc++
). These include:
I think the nullptr
problem is the root cause.
All of our copyright headers are through 2014
This causes a crash when mask_shared is called when the type needs to be aligned in a specific way in memory.
All CPP and H files should have the Leap Motion copyright string at the top; adjust the linter so that it will validate this in addition to validating our tab/space stuff.
Related to #671, Cyclical dependencies are bad, but if all Autowired fields were automatically reset on context teardown, they would be much less of a problem.
Let the following code work:
for (int i : {0,4,2,5,1,3}) {
int sleepTime = dist(mt);
p += [i, sleepTime]() {};
}
std::vector<int> result;
for (auto it = p.begin<void(); it != p.end<void>(); ++it);
A specialization for parallel::begin<void>
is needed to get this code functional.
This one is a complex one. We need the ability to add information about the decorations that will be attached by a particular AutoFilter
at runtime, rather than relying exclusively on information gained from the signature of the AutoFilter
itself.
This will allow us to have an AutoFilter
that accepts an AutoPacket&
, but still have some information about what types of decorations that filter is responsible for attaching at runtime. Furthermore, we can tighten behavior down by requiring that filters which accept an AutoPacket&
as an input explicitly declare the decorations they intend to attach--or else they will not be permitted to attach any.
Suggested syntax:
void MyFilter::AutoInit(void) {
AutoRequired<AutoPacketFactory> factory;
factory->Augment<MyFilter, DecorationType0>();
}
This syntax relies on Autowiring's AutoInit
behavior, which is invoked on an object immediately after it is injected into a context and registered but before it is made a candidate for autowiring. This registration step can't be done from the constructor, because the filter won't been added to the AutoPacketFactory
until the object is completely constructed.
A service crash occurs after sleep/resume. This did not occur on Develop prior to autowiring update. Stack trace and branch commit hash attached below.
10/10
UPD-Autowiring branch: a0c90e87cc9e174272aa3f1150d90810f8c9e97a
Stack Trace:
msvcr120.dll!abort() Line 88 C
msvcr120.dll!_purecall() Line 59 C
LeapSvc.exe!autowiring::signal::operator()(enum VigilanceReason &&) C++
LeapSvc.exe!operator<<(class std::basic_ostream<char,struct std::char_traits > &,enum LEDMode) C++
LeapSvc.exe!DispatchQueue::DispatchAllEvents(void) C++
LeapSvc.exe!CoreJob::DispatchAllAndClearCurrent(void) C++
LeapSvc.exe!std::_Func_impl<struct std::_Callable_obj<class std::_Bind<0,void,class <lambda_21250f153e69945bed5dd5697e2e3945> >,0>,class std::allocator<class std::_Func_class >,void>::_Do_call(void) C++
LeapSvc.exe!std::_Packaged_state::_Call_immediate(void) C++
LeapSvc.exe!std::_Func_impl<struct std::_Callable_obj<class <lambda_2cb696077b3339a1ae8328ae0c6c0dec>,0>,class std::allocator<class std::_Func_class >,void>::_Do_call(void) C++
LeapSvc.exe!std::_Func_impl<struct std::_Callable_obj<class <lambda_76f314ecb5e1c9167539137e0dc2f350>,0>,class std::allocator<class std::_Func_class >,unsigned char>::_Do_call(void) C++
LeapSvc.exe!Concurrency::task::_InitialTaskHandle<void,class <lambda_781036f848fffa6eb15265e2650f848e>,struct Concurrency::details::_TypeSelectorNoAsync>::_Init(struct Concurrency::details::_TypeSelectorNoAsync) C++
LeapSvc.exe!Concurrency::details::_PPLTaskHandle<unsigned char,struct Concurrency::task::_InitialTaskHandle<void,class <lambda_781036f848fffa6eb15265e2650f848e>,struct Concurrency::details::_TypeSelectorNoAsync>,struct Concurrency::details::_TaskProcHandle>::invoke(void) C++
msvcr120.dll!Concurrency::details::_UnrealizedChore::_UnstructuredChoreWrapper(Concurrency::details::_UnrealizedChore * pChore) Line 293 C++
msvcr120.dll!Concurrency::details::InternalContextBase::Dispatch(Concurrency::DispatchState * pDispatchState) Line 1716 C++
msvcr120.dll!Concurrency::details::FreeThreadProxy::Dispatch() Line 203 C++
msvcr120.dll!Concurrency::details::ThreadProxy::ThreadProxyMain(void * lpParameter) Line 174 C++
kernel32.dll!BaseThreadInitThunk�() Unknown
ntdll.dll!RtlUserThreadStart�() Unknown
It seems that the issue is a result of some filters using type T, while others using std::shared_ptr. The problem was introduced by #712.
In cases where we manage our contexts using the ContextMap
, it would be nice if we could terminate and release the weak pointers in the map. For example:
void MyClass::Reset() {
for (auto ctxt : m_ctxtMap) {
ctxt->SignalShutdown();
}
m_ctxtMap.Clear();
}
AutoNet seems to be having some pretty serious problems as of v1.0.0. In particular, not all of the context information is correctly relayed to the front end, and it does not update continuously.
One possible problem is the recent update to websocketpp, another possibility is a change to how Autowiring reports context events to clients. Investigate, and fix the problem.
E.g. if c is a context and s is an instance of a class with an AutoFilter method, then the call
c->Snoop(s)
looks like it should cause c to snoop s, but it really means s will snoop c
. This is misleading.
The time has come...
As we are using AutoNetServer as the RPC messaging, we should look into adding TLS support so that AutoNetServer can communicate with web applications with a more secure protocol
AutowiringEnclosure now checks to ensure that GlobalCoreContext
is not leaked at the end of a test. This is a good thing to be checking, but some legacy tests are not written cleanly and so are failing.
Add a flag to optionally skip this check and preserve the old behavior until clients can fix these leaks.
I'm tired of having to update autowiring.io by hand. It should be possible to use a tag-based deploy trigger in Travis to have the build server generate and update our documentation as soon as a tag is laid in.
v1.2.3
, or exclude any tag that is not a release[ RUN ] AutoConfigTest.Double
/home/tombuilder/JenkinsSlaveHome/workspace/Autowiring_Build/J_ARCH/X86/J_PLAT/linux/src/autowiring/test/AutoConfigTest.cpp:117: Failure
Value of: strVal.c_str()
Actual: "-0.00992909999999999"
Expected: "-0.0099291"
It is a known bug that make_shared does not honor data alignment requirements.
converting this type of code:
auto ptr = std::make_shared(std::forward<T&&>(t));
To:
auto ptr = std::shared_ptr(new TActual(std::forward<T&&>(t)));
Will fix the issue(s)
We build with Autowiring with VS2017 (version 15.5.7) on Windows. But it failed with the error C2039, C2878, C2065, C2146, C3083. This issue can be reproduced from master revision fc48e3b. Could you please help take a look at this? Thanks!
Repro steps:
Error info:
The whole log file please see attachment.
log_x86_build.log
Build FAILED.
"D:\Autowiring\build_x86\Autowiring.sln" (Rebuild target) (1) ->
"D:\Autowiring\build_x86\ALL_BUILD.vcxproj.metaproj" (Rebuild target) (2) ->
"D:\Autowiring\build_x86\src\autowiring\test\AutowiringTest.vcxproj.metaproj" (Rebuild target) (10) ->
"D:\Autowiring\build_x86\src\autowiring\test\AutowiringTest.vcxproj" (Rebuild target) (21) ->
(ClCompile target) ->
D:\Autowiring\src\src.\autowiring/C++11/filesystem.h(9): error C2039: 'filesystem': is not a member of 'std' [D:\Autowiring\build_x86\src\autowiring\test\AutowiringTest.vcxproj]
D:\Autowiring\src\src.\autowiring/C++11/filesystem.h(9): error C2878: 'filesystem': a namespace or class of this name does not exist [D:\Autowiring\build_x86\src\autowiring\test\AutowiringTest.vcxproj]
D:\Autowiring\src\src\autowiring\test\FileSystemHeaderTest.cpp(16): error C3083: 'filesystem': the symbol to the left of a '::' must be a type [D:\Autowiring\build_x86\src\autowiring\test\AutowiringTest.vcxproj]
D:\Autowiring\src\src\autowiring\test\FileSystemHeaderTest.cpp(16): error C2039: 'path': is not a member of 'std' [D:\Autowiring\build_x86\src\autowiring\test\AutowiringTest.vcxproj]
D:\Autowiring\src\src\autowiring\test\FileSystemHeaderTest.cpp(16): error C2065: 'path': undeclared identifier [D:\Autowiring\build_x86\src\autowiring\test\AutowiringTest.vcxproj]
D:\Autowiring\src\src\autowiring\test\FileSystemHeaderTest.cpp(16): error C2146: syntax error: missing ';' before identifier 'p' [D:\Autowiring\build_x86\src\autowiring\test\AutowiringTest.vcxproj]
D:\Autowiring\src\src\autowiring\test\FileSystemHeaderTest.cpp(16): error C2065: 'p': undeclared identifier [D:\Autowiring\build_x86\src\autowiring\test\AutowiringTest.vcxproj]
D:\Autowiring\src\src\autowiring\test\FileSystemHeaderTest.cpp(17): error C3083: 'filesystem': the symbol to the left of a '::' must be a type [D:\Autowiring\build_x86\src\autowiring\test\AutowiringTest.vcxproj]
D:\Autowiring\src\src\autowiring\test\FileSystemHeaderTest.cpp(17): error C2039: 'path': is not a member of 'std' [D:\Autowiring\build_x86\src\autowiring\test\AutowiringTest.vcxproj]
D:\Autowiring\src\src\autowiring\test\FileSystemHeaderTest.cpp(17): error C2065: 'path': undeclared identifier [D:\Autowiring\build_x86\src\autowiring\test\AutowiringTest.vcxproj]
D:\Autowiring\src\src\autowiring\test\FileSystemHeaderTest.cpp(17): error C2065: 'p': undeclared identifier [D:\Autowiring\build_x86\src\autowiring\test\AutowiringTest.vcxproj]
D:\Autowiring\src\src\autowiring\test\FileSystemHeaderTest.cpp(17): error C2228: left of '.extension' must have class/struct/union [D:\Autowiring\build_x86\src\autowiring\test\AutowiringTest.vcxproj]
D:\Autowiring\src\src\autowiring\test\FileSystemHeaderTest.cpp(17): error C2512: 'testing::AssertionResult': no appropriate default constructor available [D:\Autowiring\build_x86\src\autowiring\test\AutowiringTest.vcxproj]
D:\Autowiring\src\src\autowiring\test\FileSystemHeaderTest.cpp(18): error C3083: 'filesystem': the symbol to the left of a '::' must be a type [D:\Autowiring\build_x86\src\autowiring\test\AutowiringTest.vcxproj]
D:\Autowiring\src\src\autowiring\test\FileSystemHeaderTest.cpp(18): error C2039: 'path': is not a member of 'std' [D:\Autowiring\build_x86\src\autowiring\test\AutowiringTest.vcxproj]
D:\Autowiring\src\src\autowiring\test\FileSystemHeaderTest.cpp(18): error C2065: 'path': undeclared identifier [D:\Autowiring\build_x86\src\autowiring\test\AutowiringTest.vcxproj]
D:\Autowiring\src\src\autowiring\test\FileSystemHeaderTest.cpp(18): error C2065: 'p': undeclared identifier [D:\Autowiring\build_x86\src\autowiring\test\AutowiringTest.vcxproj]
D:\Autowiring\src\src\autowiring\test\FileSystemHeaderTest.cpp(18): error C2228: left of '.filename' must have class/struct/union [D:\Autowiring\build_x86\src\autowiring\test\AutowiringTest.vcxproj]
D:\Autowiring\src\src\autowiring\test\FileSystemHeaderTest.cpp(18): error C2512: 'testing::AssertionResult': no appropriate default constructor available [D:\Autowiring\build_x86\src\autowiring\test\AutowiringTest.vcxproj]
Since a recent refactor on platform with the code
*packetOutput += [packetInputPtr, this] (const FlipDecision& flipDecision) {
packetInputPtr->Decorate(flipDecision);
};
we are getting this error every minute or so on OS X machines :
[Critical] Unhandled exception: Cannot decorate this packet with type auto_id<FlipDecision>, the requested decoration is already satisfied
[Critical] An unhandled exception occurred in a device context: Cannot decorate this packet with type auto_id<FlipDecision>, the requested decoration is already satisfied
They problem may lie in autowiring, although it's not clear.
ObjectPool
has terrible performance because we used std::shared_ptr
to track objects that are in the cache, when really we should be using std::unique_ptr
. This design choice was made in order to support libstdc, but because we no longer support it, we should probably fix ObjectPool
's current performance issue, especially if we are recommending that people use it in preference of operator new
.
https://github.com/fmtlib/fmt provides a mature, well tested, and extremely fast implementation that would avoid potential format conversion problems.
I'm tired of looking at the warning in PriorityBoost.cpp, it's about time we got around to implementing this.
It's likely all we need to do is to call the nice
function or near equivalent, we just need to make sure we do so in a way that will also work properly on Mac.
ObjectPool
has a constructor overload which allows callers to override default memory allocation. This makes two separate allocations necessary and can be very inefficient. Remove the allocating constructor completely, and then use alignof
to satisfy alignment requirements.
A call to CoreContext::SetUnlinkOnTeardown
is currently required to enable teardown unlinking in CoreContext
. To reduce the likelihood of context member leaks due to cyclic references, make teardown unlinking the default behavior.
This will require that we verify downstream consumers are not adversely impacted by this modification, as any unchecked references to an Autowired
field during teardown may potentially result in a null pointer dereference.
Build Autowiring with /std:c++17 with Visual studio 2017(version 15.5.7) on windows failed with following failures, could you help have a look?
D:\Autowiring\src\src.\autowiring/C++11/filesystem.h(20): error C2874: using-declaration causes a multiple declaration of 'std::experimental::filesystem::v1::path' [D:\Autowiring\build_x86\src\autowiring\test\AutowiringTest.vcxproj]
D:\Autowiring\src\src.\autowiring/C++11/filesystem.h(26): error C2874: using-declaration causes a multiple declaration of 'std::experimental::filesystem::v1::filesystem_error' [D:\Autowiring\build_x86\src\autowiring\test\AutowiringTest.vcxproj]
Fix this so we can deploy
Here's the output from gtest:
C:\Development\autowiring\src\autowiring\test\AutoSignalTest.cpp(630): error: Value of: magic
Actual: 15987178197214944733
Expected: 0xDEADBEEFC0FECAFE
Which is: 16045690984335330046
Right now, I must call subscribe to get custom events, which means a lot may be sent which is not required. It would be nice if custom events came through without the others.
If a user attempts to call parallel::begin
and the current context is not running, throw an exception.
The failure is due to our CoreThreadLinux
adjustments in #786. Here's the error:
src/autowiring/CoreThreadLinux.cpp: In member function 'void BasicThread::SetThreadPriority(ThreadPriority)':
src/autowiring/CoreThreadLinux.cpp:37:14: error: 'SCHED_IDLE' was not declared in this scope
policy = SCHED_IDLE;
We need to fix this, or turn off this feature on Android.
Example use case is with sliders, which use NotifyWhenAutowired
on Figure. When I start LeapSvc with a device plugged in, a couple frames will tend to get processed before Figure comes online.
However, once Figure is autowired, these are often triggered in a different order than the m_Params.NotifyWhenAutowired
line was called, which knocks sliders from their intended ordering.
This doesn't happen when I plug in a device after a few seconds, since at that point the calls to add sliders are processed immediately.
The changes to AutoNetServerTest.h in commit 441ddc1 breaks the compile for the autonet tests for me (linux, clang 3.4.2 & gcc 4.9.1). If I revert the file, the autonet tests compile & run for me.
In CmakeLists.txt, using linux with clang 3.4.2, I have to change:
set(CMAKE_CXX_FLAGS "-std=c++11 -stdlib=libc++")
to
set(CMAKE_CXX_FLAGS "-std=c++11")
in order for it to compile. If I use the "-stdlib" flag, the compile can't find standard library headers (e.g., ).
For example:
[ 1%] Building CXX object contrib/json11/CMakeFiles/json11.dir/json11.cpp.o
In file included from /home/ndoss/autowiring/autowiring/contrib/json11/json11.cpp:22:
/home/ndoss/autowiring/autowiring/contrib/json11/json11.hpp:53:10: fatal error:
'string' file not found
#include <string>
^
1 error generated.
If class A autowires class B, and class B autowires class A, the resulting cyclical dependency will keep them both alive even after context teardown.
This is bad behavior, and if at all possible, we should add some mechanism for automatically detecting this kind of thing to either autowiring itself (which should throw an exception, likely runtime if found) or to AutoNet
AutoFilterTest.DeferredRecieptInSubContext
fails after ~500 iterations.
run AutowiringTest --gtest_filter="AutoFilterTest.DeferredRecieptInSubContext" --gtest_break_on_failure --gtest_repeat=10000
There's a defect introduced in #866 which is causing a multi-decorate problem to appear on initialization in certain user build cases. This defect is serious enough to merit a patch release this week to correct the problem.
The issue is only reproduceable in platform. This is a copy of the error log:
[Critical] Unhandled exception: Cannot decorate this packet with type SubFrame, the requested decoration is already satisfied
[Critical] An unhandled exception occurred in a device context: Cannot decorate this packet with type SubFrame, the requested decoration is already satisfied
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.