Clojure yagni "could not find any references" to a proxy Callable instance - clojure

I'm trying to use https://github.com/venantius/yagni
When I run it, I get the following error:
=================== WARNING: Parents ======================
== Could not find any references to the following ==
===========================================================
my-proj.my-ns/my-proj.my-ns.proxy$java.lang.Object$Callable$7da976d4
From what I found online, nothing can explain the meaning of this error
Update
Thanks for the comments asking me to give more context.
I was able to understand that the error is coming from a macro I'm using.
In my code, I'm using the time! macro, from the metrics lib.
As you can see herethis macro is using proxy
But this is not my code, is there a way to tell yagni not to look at it? (I guess not since it is a macro and compiled before yagni reads it)

Related

(ROS) Failed to create global planner

My setup is: ROS melodic, Ubuntu: 18.04
I want simulate turtlebot3 moving with my own global planner and have been following this tutorial to get started: http://wiki.ros.org/navigation/Tutorials/Writing%20A%20Global%20Path%20Planner%20As%20Plugin%20in%20ROS#Running_the_Plugin_on_the_Turtlebot. The tutorial seem to be made for ROS hydro, but as it was the best source of guidance I could find I hoped it would work.
The error I'm having is:
Failed to create the global_planner/GlobalPlanner planner, are you sure it is properly registered and that the containing library is built? Exception: MultiLibraryClassLoader: Could not create object of class type global_planner::GlobalPlanner as no factory exists for it. Make sure that the library exists and was explicitly loaded through MultiLibraryClassLoader::loadLibrary()
To my knowledge I've followed the tutorial as much as possible with a only a few things done differently because I wanted to test it, couldn't do as the tutorial asked, or because I thought it wouldn't impact the results. What I have done differently is:
I use the carrot_planner.h and carrot_planner.cpp files in the tutorial section 1 to test that it works before trying with my own code to avoid confusion about where possible errors come from. It's not 'different' from the tutorial to my knowledge, but figured I'd mention it. They are placed in catkin_ws/src/carrot_planner/src/global_planner/
The ros package I'm working from is in catkin_ws/src and is called the carrot_planner. In the tutorial step 1.3 I use add_library(global_planner_lib src/global_planner/carrot_planner.cpp). Would not imagine it affects the results either.
In section 3 of the tutorial it mentions that 'First, you need to copy the package that contains your global planner (in our case global_planner) into the catkin workspace of your Turtlebot (e.g. catkin_ws).' Since my package was already in catkin_ws/src/ I haven't moved it since I guess I didn't need to.
I've altered the 'move_base.launch' file in '/opt/ros/melodic/share/turtlebot3_navigation/launch/' instead of the 'move_base.launch.xml' in '/opt/ros/hydro/share/turtlebot_navigation/launch/includes/' as there doesn't seem to be a destination '...turtlebot3_navigation/launch/includes/'. There are files in launch, but no includes folder. Maybe that a difference from Hydro to Melodic, I don't know. There may be a whole lot of things that need to be done differently from the tutorial when using Melodic, or with turtlebot3, but I don't know.
I haven't made my own launch file for bringup of the turtlebot, but have instead followed this tutorial (https://emanual.robotis.com/docs/en/platform/turtlebot3/nav_simulation/) to guide me with turtlebot3. After finishing this step in the global planner tutorial 'Save and close the move_base.launch.xml. Note that the name of the planner is global_planner/GlobalPlanner the same specified in global_planner_plugin.xml. Now, you are ready to use your new planner' I tested whether it worked by running: 'roslaunch turtlebot3_gazebo turtlebot3_world.launch' and then I tried running: 'roslaunch turtlebot3_navigation turtlebot3_navigation.launch map_file:=$HOME/map.yaml' which led to the error I showed above. I have created the map-yaml, so there's no misunderstanding whether that's missing.
I would be very glad for any help, thank you ^^
Edit: My system only had 'navfn' on it, not 'global_planner' or 'carrot_planner', if that makes a difference.
After looking over the code I found a solution. It doesn't make everything work perfectly yet, but seems to solve the immediate problem.
The problem was that in my 'global_planner_plugin.xml' I just used the code provided in the tutorial:
<library path="lib/libglobal_planner_lib">
<class name="global_planner/GlobalPlanner" type="global_planner::GlobalPlanner" base_class_type="nav_core::BaseGlobalPlanner">
<description>This is a global planner plugin by iroboapp project.</description>
</class>
</library>
But in the carrot_planner.cpp file it says:
PLUGINLIB_EXPORT_CLASS(carrot_planner::CarrotPlanner, nav_core::BaseGlobalPlanner)
Changing type="global_planner::GlobalPlanner to type="carrot_planner::CarrotPlanner and then launching turtlebot3 doesn't give the same error anymore.

Alternative of CreateVideoSource() in webrtc

Hi all I had seen one webrtc old source code which has this method called CreateVideoSource() for adding streams after an CreateAudioTrack() call.
rtc::scoped_refptr<webrtc::VideoTrackSourceInterface> video_source =
peer_connection_factory_->CreateVideoSource(std::unique_ptr<cricket::VideoCapturer>(
media_source->GetVideoCapturer()),
NULL);
What's happening is whenever I try to build it gives an error for the above CreateVideoSource() that it is undefined. And the reason behind that is the latest webrtc-checkout has deprecated this.
So my question is, I wanted to know the alternative which they have introduced after deprecating this method. So can anyone tell me what the alternate approach is.
Okay, Finally I was able to come up with an alternative(i.e the current implementation of libwebrtc) after looking into bundle examples and tests.
Line 71 is a good point to start

In Clang, can I access the SourceManager when writing a custom ASTMatcher?

I'm trying to upgrade my AutoFFI project by making it more elegant and use Clang's ASTMatchers more extensively. I'd like to create a matcher that filters on the file path that was specified. Is it possible to do such a thing, or do I need to add custom logic outside of the matcher for this to work? As far as I can see, there's no way to get the SourceManager and use it to create a FullSourceLoc, but maybe I'm missing something.
Some relevant links:
https://clang.llvm.org/doxygen/classclang_1_1FullSourceLoc.html
https://github.com/llvm-mirror/clang/blob/f3b7928366f63b51ffc97e74f8afcff497c57e8d/include/clang/ASTMatchers/ASTMatchersMacros.h#L28
If someone could tell me whether this is a limitation to Clang's ASTMatcher API or not I'd be very grateful!
Never mind, I've found the answer by looking at the source of isExpansionInMainFile:
AST_POLYMORPHIC_MATCHER(isExpansionInMainFile,
AST_POLYMORPHIC_SUPPORTED_TYPES(Decl, Stmt, TypeLoc)) {
auto &SourceManager = Finder->getASTContext().getSourceManager();
return SourceManager.isInMainFile(
SourceManager.getExpansionLoc(Node.getBeginLoc()));
}
Turns out I missed the getASTContext in MatchFinder, which holds on to the source manager.

Implementation of active appearance models

I'm having an internship in the field of computer vision, and i am really interested to know some details about the implementation of the Active Appearence Models aam-opencv that exists in the Google Code site.
In fact, i downloaded aam-opencv.tar.gz then built it with cmake and i solved some syntax problems but the only error that i am still having when i try to generate the solution is the following :
This function should return something:
aamImage* delaunay:: warpImageToMeanShape(aamImage*input)
{
}
I wonder if there is something missing in that function, or is it a compiler problem.
Please give me an answer or just guide me to complete the missing part of that function.
I would really appreciate if anyone kindly help me.
Thank you.
I suppose that is not used in code function, so it is not important what it return. Some C++ compilers allow to write such code and give only warning, another treat as errors:
ReturnType f()
{
}
looks like you use not the same compiler as author of source code. So just add something like:
aamImage* delaunay:: warpImageToMeanShape(aamImage*input)
{
return NULL;
}

What has to be Glib::init()'ed in order to use Glib::wrap?

So I'm trying to make use of a GtkSourceView in C++ using GtkSourceViewmm, whose documentation and level of support give me the impression that it hasn't been very carefully looked at in a long time. But I'm always an optimist :)
I'm trying to add a SourceView using some code similar to the following:
Glib::RefPtr<gtksourceview::SourceLanguageManager> source_language_manager = gtksourceview::SourceLanguageManager::create();
Glib::RefPtr<gtksourceview::SourceLanguage> source_language = Glib::wrap(gtk_source_language_manager_guess_language(source_language_manager->gobj(), file, NULL));
Glib::RefPtr<gtksourceview::SourceBuffer> source_buffer = gtksourceview::SourceBuffer::create(source_language);
gtksourceview::SourceView* = m_source_view = new gtksourceview::SourceView(source_buffer);
m_vbox.pack_start(*m_source_view);
Unfortunately, it spits out the warning
(algoviz:4992): glibmm-WARNING **:
Failed to wrap object of type
'GtkSourceLanguage'. Hint: this error
is commonly caused by failing to call
a library init() function.
and when I look at it in a debugger, indeed the second line above (the one with the Glib::wrap()) is returning NULL. I have no idea why this is, but I tried to heed the warning by adding Glib::init() to the begining of the program, but that didn't seem to help at all either.
I've tried Google'ing around, but have been unsuccessful. Does anyone know what Glib wants me to init in order to be able to make that wrap call? Or, even better, does anyone know of any working sample code that uses GtkSourceViewmm (not just regular GtkSourceView)? I haven't been able to find any actual sample code, not even on Google Code Search.
Thanks!
It turns out, perhaps not surprisingly, that what I needed to init was:
gtksourceview::init();
After this, I ran into another problem with one of the parameter to gtksourceview::SourceLanguageManager, but this was caused by a genuine bug which I subsequently reported and was promptly fixed. So everything's working great now!
I use gtkmm. Typically you have to initialize things with something like :
_GTKMain = new Gtk::Main(0, 0, false);
Of course do not forget :
delete _GTKMain;
Check here for details :
http://library.gnome.org/devel/gtkmm/2.19/classGtk_1_1Main.html
(Sorry but the link option does not work ...)