Plugins will be delivered through a seperate installer
models will be delivered through the online gazebo model repository
Change-Id: Id9df358837460ae3956657327dbfeb6414b033c2
Conflicts:
eclipse-plugins/edu.wpi.first.wpilib.plugins.updatesite/site.xml
Change-Id: If2218df082bca93d25b88088696d6c2897732efd
Adding FRC Local new mdns name
Change-Id: I53d206879663b96009ba3a12de161b7a425ffd10
Adding rpath for new libstdc++
Change-Id: I0c022efb0b15f094d153b44f60215ca00d5f1924
using findAll form instead off whenAdded
fixed instances of network tables versions from 0.1.0 to 3.0.0
Change-Id: I01054d727259ea5dbf3ba8fae49764337d4f6cf9
This commit does a few things. First, we publish ntcore as a maven
artifact so the plugins can build with new networktables, and java
programs will depend on the correct version when compiled. We also revert
the changes to OutlineViewer for now. I got an exception when attempting
to start a server with the new network tables in OutlineViewer on Windows,
I will create a bug for this. Also, since we don't have the binaries
integrating properly yet and won't for the first beta, we need to be using
the platform agnostic version anyway.
Change-Id: I9960f25bc3f2b30bb59fce665eb914ef5e661c9c
I'm not 100% sure whether we want these, but they are a quick
find and replace to do.
Basically, there are two primary things that we have done
this summer that break existing user code:
-Changing GetInstance() calls to return references instead
of pointers. This forces users to change from doing something
like LiveWindow::GetInstance()->AddSensor() to LiveWindow::GetInstance().AddSensor().
-Making PIDGet() and related calls const, forcing users to change
the function signatures wherever they override them.
The GetInstance() calls don't really matter to me either way,
especially since there are no real ownership issues going on there,
unlike the rest of the smart pointer-related changes.
For the const stuff, it is certainly more correct to mandate that
user PIDGet() functions be const and the such, but at the same time,
I'm not sure that there is any strong need for it, and the errors
generated are not the most helpful. While this wouldn't necessarily
be an issue for more experienced teams or completely new teams (who
don't have any old code to be reusing), it may cause issues for more
average teams who aren't familiar with the intricacies of C++ anything.
Change-Id: I6e7007982069292ea70e6d0fc8ca40203340df1b
verified to work on real robots
adds sim eclipse plugins, fixed JavaGazebo, made wpilibC++Sim build on windows
- Java and C++ simulation robot programs run on windows
- simulation eclipse plugin delivers models and gazebo plugins
- Java Gazebo now respects GAZEBO_IP variables and can work across networks
- hal and network tables win32 hacked to work on windows
- smart dashboard broken on windows due to network tables hacks
- wpilibC++Sim, gz_msgs, and frcsim_gazebo_plugins build with CMake
- removed constexpr for cross platform compatibility
- msgs generated using .protos as a part of build process
- some spare and unused cmake/pom files deleted
- simulation ubuntu debians removed entirely
- refactored CMake project flags and macros
- updated to match non-sim C++ API
- fixed and updated documentation
- servo added to simulation
Change-Id: Ia702ff0f1fee10d77f543810ad88f56696443b05
Also added some references/smart pointers to a couple places
that seemed convenient to the user.
I haven't updated the constructors for RobotDrive() related
examples, pending the results of gerrit change https://usfirst.collab.net/gerrit/#/c/960/
A few things that we are noticing:
--It might be nice if ReturnPIDInput() didn't have to be const;
when people try to override it, they have to remember to put
the const in and if they don't, then the compiler error isn't the
most obvious (especially since this is a change). This would also
apply to PIDGet() in the PIDSource interface.
--SendableChooser still takes raw pointers. This could lead to an
issue I had to debug briefly where you accidentally call
GetSelected() on autoChooser and put the resulting raw pointer
into a unique_ptr, which destroys the pointer when it goes out of
scope. Specifically, I was testing the PacGoat example and
I ended up with a situation where if auto mode was run once, it
was fine, but if it was run twice, the selected command would
have been destroyed by the unique_ptr. I believe that this
just requires updating SendableChosser to take shared_ptr.
--When the samples are compiled with -pedantic, it points out that
START_ROBOT_CLASS macro expansion results in a redundant semicolon.
Change-Id: Ib4c025a61263d0d2780d4253faa31713e15333a5
This deals with the majority of the user-facing code
in wpilibC++Devices and a substantial portion of it in
wpilibC++. wpilibC++Sim and wpilibC++IntegrationTests
are untouched except where it is necessary to make them
work with the rest of the libraries.
There is still a lot to do in the following areas:
-The HAL (which we may not want to touch at all).
-The I2C, Serial, and SPI interfaces in wpilibC++Devices,
which I haven't gotten around to doing yet.
-Most wpilibC++Devices classes have void* pointers
for interacting with the HAL.
-InterruptableSensorBase passes a void *params for
the interrupt handler.
-I haven't converted all the const char* to std::strings.
-There are plenty of other cases of raw pointers still
existing.
-This doesn't fall directly under raw pointer stuff,
but move syntax and rvalue references could be introduced
in many places.
-I haven't touched vision code.
-The Resource classes conflict (one is in the hal, the other
in wpilibC++). Someone should figure out a more
permanent fix (eg, just renaming them), then doing
what I did (making a new namespace for one of them,
essentially the same as renaming it).
A few other things:
-I created a NullDeleter class which is marked as deprecated.
What this does is it can be passed as the deleter to a
std::shared_ptr so that when you are converting raw pointers
to shared_ptrs the shared_ptr doesn't do any deletion if
someone else owns the raw pointer. This should only be
used in making old raw pointer UIs.
-I had to alter the build.gradle so that it did not
emit errors when deprecated functions called deprecated
functions. Unfortunately, gradle doesn't appear to be
actually printing out gcc warnigns for some reason.
The best way I have found to fix this is to patch
the toolchains (https://bitbucket.org/byteit101/toolchain-builder/pull-request/5/make-gcc-not-throw-warnings-for-nested/diff)
so that a deprecated function calling a deprecated
function is fine but a non-deprecated function calling
a deprecated function will throw a warning (which we
then elevate with -Werror). I believe that clang
deals with this properly, although I have not
tried it myself.
Change-Id: Ib8090c66893576fe73654f4e9d268f9d37be06a2
Although I have tested this on my machine, further testing
to ensure that the problem really is solved may be helpful.
Change-Id: I892ad7d9f8fa7e791390a38036dafdba00d3a670
rm no longer throws a file not found error on deploy.
Also, throw in a sync command at the end of the deploy so that we don't get corrupted files.
Change-Id: I561916e4fec1b8449f9a70b7ee2155b0b62abc80
This adds gradle support for building wpilibj and wpilibc. At this
point, both of these libraries should be fully ready to go.
Gradle should give us a number of improvements, including less
dependencies for getting building up and running, and MUCH faster build
times. I'm noticing significantly faster build times already compared to
Maven, with neither system building the plugins. The changes here should
be pretty straight forward. The basic command for gradle is './gradlew'.
This is the gradle wrapper, and it will find and download the correct
gradle executable for your system. There is no need to install anything
yourself. To see every task available, run './gradlew tasks'. The
important tasks for us are listed under the WPILib header when the tasks
command is run. To generate unit test binaries, the
fRCUserProgramExecutable command will create the C++ tester, and the
wpilibjIntegrationTestJar command will create the Java tester. The Jenkins
deploy scripts have been modified to know the difference between maven
generated and gradle generated jars with an environment variable. Creating
the eclipse plugins still requires Maven, but gradle will handle calling
it correctly and generating the proper dependencies for it. Create the
plugins by calling ./gradlew eclipsePlugins.
Jenkins can now be modified to support the new build system. Unit tests
are run with ./gradlew test. Generating the integration tests uses the
above two commands, and then process proceeds exactly as it did before.
For publishing documentation, a new task has been created, ./gradlew
publishDocs, which handles putting the documentation where Jenkins expects
for publishing.
Change-Id: I9a260d391984f98ef9170993efe933e4026161dc
