Frontier exploration in ROS noetic - ros

I want to use frontier explanation in Ros noetic.
http://wiki.ros.org/frontier_exploration
Is there a way to use in this Ros package?

It looks like the developer doesn't have time to update it and is looking for volunteers.
It might not be a terrible amount of work to do it yourself. Usually it involves:
Cloning the repo and updating the dependencies for Noetic.
Compiling it yourself and fixing the errors.
Testing it.
Once it's good, making a pull request, so other people can use it.

Related

How to upgrade NuGet packages without breaking my project?

I have an old MVC application I need to make changes to. It would be nice to update all the recommended NuGet packages, but I know from experience that this can break a project.
In particular, I'm troubled by the following:
If one reads this a certain way, it appears that it's actually suggesting I upgrade to Twitter Bootstrap 5.1.2. I know for a fact that numerous breaking changes have been implemented since my current version.
I prefer not to have to rewrite the site. I thought Updates might have been a little smarter. Do I really need to know each package well enough to know if it would include breaking changes? Is there no way to specify compatible updates? Did Microsoft consider this aspect?
You do need to know each package well enough. Why? Because there's not a single way of doing versioning. Some packages, probably a lot of packages even, follow Semantic Versioning, but there's nothing to stop anyone from using any versioning they want (even if it doesn't make sense). There's nothing preventing you from going 3.0.1 to 15.14.13 with a change in an unimportant .txt file.
It's your responsibility to know what to update and when. Look at this Q&A to see how you can restrict the versions suggested: NuGet Limit max major version of a package

build research and use it as an external package for research project

I want to perform some research regarding quantization/sparsification, I would like to use run_experiment.py script as a template, to do so in a clean matter as research is not part of the pip package I was wondering if it is possible to build it myself and then reuse it as a dependency (as in run_experiment.py some functions from research are used). I am not sure however how to do it. I am not familiar with bazel. I was able to install it and run the script, that's all. Any guidance would be highly appreciated! Or if it's not possible it would be good to know as well! Thank you for any advice in this matter.
EDIT:
I built something using bazel and I have it in bazel-bin I don't know now however how to reuse it in my script, as if I just wanted to do it in a python manner
from research.compression import compression_process_adapter
or somehthing similar in my script
Using TFF for Federated Learning Research gives a rough introduction on suggestions for organizing the experiment conceptually.
From there, seeing how "run scripts" are setup in various sub-directories under tensorflow_federated/python/research/ might be good examples. If there is an sub directory that is close to what you want to accomplish, forking/copying it might be a good place to start.
For instance, tensorflow_federated/python/research/gans/experiments/emnist/run_experiments.py might be a useful example for how to setup an experiment grid. This iteratively runs tensorflow_federated/python/research/gans/experiments/emnist/train.py, which has an example of how to import libraries under the research/ directory. Note that all of these uses bazel, and the depedencies for the imports are decalred in the tensorflow_federated/python/research/gans/experiments/emnist/BUILD file.
Finally, this script can be run with (from the git repo root directory):
bazel run -c opt tensorflow_federated/python/research/gans/experiments/emnist:run_experiments

Handling complex and large dependencies

Problem
I've been developing a game in C++ in my spare time and I've opted to use Bazel as my build tool since I have never had a ton of luck (or fun) working with make or cmake. I also have dependencies in other languages (python for some of the high level scripting). I'm using glfw for basic window handling and high level graphics support and that works well enough but now comes the problem. I'm uncertain on how I should handle dependencies like glfw in a Bazel world.
For some of my dependencies (like gtest and fruit) I can just reference them in my WORKSPACE file and Bazel handles them automagically but glfw hasn't adopted Bazel. So all of this leads me to ask, what should I do about dependencies that don't use Bazel inside a Bazel project?
Current approach
For many of the simpler dependencies I have, I simply created a new_git_repository entry in my WORKSPACE file and created a BUILD file for the library. This works great until you get to really complicated libraries like glfw that have a number of dependencies on their own.
When building glfw for a Linux machine running X11 you now have a dependency on X11 which would mean adding X11 to my Bazel setup. X11 Comes with its own set of dependencies (the X11 libraries like X11Cursor) and so on.
glfw also tries to provide basic joystick support which is provided by default in Linux which is great! Except that this is provided by the kernel which means that the kernel is also a dependency of my project. Now I shouldn't need anything more than the kernel headers this still seems like a lot to bring in.
Alternative Options
The reason I took the approach I've taken so far is to make the dependencies required to spin up a machine that can successfully build my game very minimal. In theory they just need a C/C++ compiler, Java 8, and Bazel and they're off to the races. This is great since it also means I can create a Docker container that has Bazel installed and do CI/CD really easily.
I could sacrifice this ease and just say that you need to have libraries like glfw installed before attempting to compile the game but that brings the whole which version is installed and how is it all configured problem back up that Bazel is supposed to help solve.
Surely there is a simpler solution and I'm overthinking this?
If the glfw project has no BUILD files, then you have the following options:
Build glfw inside a genrule.
If glfw supports some other build system like make, you could create a genrule that runs the tool. This approach has obvious drawbacks, like the not-to-be-underestimated impracticality of having to declare all inputs of that genrule, but it'd be the simplest way of Bazel'izing glfw.
Pre-build glfw.o and check it into your source tree.
You can create a cc_library rule for it, and put the .o file in the srcs. Even though this solution is the least flexible of all because you not only restrict the target platform to whatever the .o was built for, but also make it harder to reproduce the whole build, the benefits are sometimes worth the costs.
I view this approach as a last resort. Even in Bazel's own source code there's one cc_library.srcs that includes a raw object file, because it was worth it, as the commit message of 92caf38 explains.
Require that glfw be installed.
You already considered this option. Some people may prefer this to the other approaches.

Purescript - Unable to build with drawing and signals libraries

I'm trying to start a purescript project that uses the purescript signal and drawing libraries. When I try to bower install with both of them as dependencies, bower's interactive prompt asks to resolve several dependency versions. I admittedly pick the versions somewhat arbitrarily since most of the issues are several layers of dependencies deep. Then when I pulp build a basic hello world piece of code that doesn't even use the dependencies, pulp gives around 40 errors depending on which versions I selected.
How do I resolve these dependency versions correctly? Sifting through forty errors and all of the dependencies for both projects doesn't seem feasible. Is there some non-arbitrary way of picking the versions that will resolve the conflicts? From the choices it gave me, it didn't seem like there was any clear resolution. Or are their dependencies too conflicting and you just can't use them together?
This may actually be more of an question about bower, but it may also be something about purescript and pulp that I am just unaware of. They both seem like libraries that should be able to work together, and I can't imagine that other people are having too much difficulty using two or more libraries in a single project.
Purescript 0.10 has breaking changes. If you have the latest compiler, it's likely that it's not compatible with some libraries. From what I see, signal lib is updated but the drawing is not. You can update the lib and use your own version. Or, send a PR, Phil and purescript community in general, is really fast on responding to pull requests.
Another temporary solution is to use the old compiler (0.9) and wait a couple months till everything is back to normal.
also see 0.10 migration guide.

How to customize a Bower package locally?

So if i’m using a Bower package (specifically, this one: https://github.com/DmitryBaranovskiy/raphael/ ) and there’s a tiny bug in it. It’s not really a big deal, and there’s a PR for it: https://github.com/DmitryBaranovskiy/raphael/pull/645 but it seems like the PR won't be merged anytime soon... Is there a way to incorporate this fix into (at least) my local version of the package without theoretically losing all the Bower-goodness? I’m a Bower newbie. I guess I’m asking is there a way to ‘customize’ a Bower package?
(For context, I’m using Bower hooked into the Rails asset pipeline as described here: http://dotwell.io/taking-advantage-of-bower-in-your-rails-4-app/ )
Thanks!
I feel your pain in regards to pull-requested patches :) Unfortunately, there's not really a clean way to do this.
One way to do this would be to:
Fork Raphel
Incorporate the fix you need
Update your bower.json to point raphel to your personal github fork"raphael": "yourusername/rapheal#branch_name"
Switch back to the "cannonical" raphel once the fix is merged
Edit
My original answer was given without realizing the original PR was 3 years old. I've updated to advocate for forking Raphel.

Resources