Also make sure table listeners stop listening in their destructors. This
might be better handled by moving the table itself into ITableListener and
providing cleanup functionality there.
A submodule is used to pull in ntcore.
Change-Id: I3031c1a768595cf0f8754c47e15cd423e2dbcce5
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
The HAL will remain untouched in order to maintain C-style
compatibility. A few places in wpilibc were left as
C-style strings, especially if special formatting (eg,
elaborate uses of snprintf or sscanf) was being used.
In general, const char* was changed to std::string.
character buffers used for formatting were either
untouched, changed to std::stringstream, or changed
to std::string, depending on what was done with
the buffer.
Change-Id: I5e431ddf1cc4d9a6d534e1f21b16ea23be26e7f1
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
Removed unused variable from DigitalInput class
Removed extraneous explicit std::string conversions in Preferences class
Change-Id: Ia445abfd136a7b3e7f0491ed22aaa057814bcc8f
Loops were converted to their range-based equivalents, variable types were replaced with auto where the type was already specified on the same line, the override keyword was added, and instances of NULL and assignments of 0 to pointers were replaced with nullptr.
Change-Id: If281e46a2e2e1c37f278d56df9915236d4b2c864
The changes made in this commit do not affect any actual code,
they are purely aesthetic. I ran clang-format with google style
over all .h/.cpp files in wpilibc that weren't in wpilibC++Sim
or gtest, and the eclipse formatter over all of the Java files
using the Google eclipse formatting configuration.
Change-Id: I9627bca0bc103c398ecc1c5ba17467193291ae63
This commit squashes all of Patrick's eleven commits into one
so that things are a bit more sane. The original commit messages
and change ids (for gerrit) can be found below.
Testing Motor Inversion Feature (Java tests only so far)
Change-Id: I44cd9b5a3fe066e1071316831dde14bff5ec3bd9
Test 2 of java testing for Motor Inverting
Change-Id: I96cc0534bb1d28a70d10c582f0b40ea3a2d83cab
Added another test to try to track down issue with InvertingMotor jaguar and Talon
Change-Id: I9b5292315c93ec0d568d53a6bcdac5b998a6d857
More Testing on the Inverting motors with jaguars and talons.
Change-Id: I896210a54903e3c0af68e8c41360c165cf9c3122
Added C++ integration Tests for the motor inversion.
Change-Id: I81af5d4aab78d755340d99608b838046bf7ddda1
C++ tests for Motor Inversion now without crashing
Change-Id: Ifdecdbfc1aeb18aafb2b4c63709b27636074a274
More testing of inverted motors (now with c++ tests)
Talon seems not to be working on test rig
Also added a CANJaguartest file in java since was missing
Currently porting the CANJaguar tests from c++ to java
Change-Id: Ib578d6ee1256ac31ddf20603aa6f24adde08065b
Another attempt at adding java tests for can jaguar inversion.
Change-Id: I971a886a4e555ada5bd15a814094da2a1eb5c8e1
Minor changes and attempt to rerun tests after yesterday's jenkins crash.
Change-Id: I7ed0904d4243499c3246e9c39e5493d0d9c962c5
All motor inversion tests should be working now. Talon on the test rig has been fixed.
Change-Id: I20bd6d7486b758ce1ce47ac799150475b3152b6f
Updated Inversion tests again. Should work this time. (worked on the test rig prior)
Change-Id: Ifdf222d5e5733fe802f29e7d939b72e84972e8da
Added tests for motor inversions.
This commit squashes all of Patrick's eleven commits into one
so that things are a bit more sane. The original commit messages
and change ids (for gerrit) can be found below.
Testing Motor Inversion Feature (Java tests only so far)
Change-Id: I44cd9b5a3fe066e1071316831dde14bff5ec3bd9
Test 2 of java testing for Motor Inverting
Change-Id: I96cc0534bb1d28a70d10c582f0b40ea3a2d83cab
Added another test to try to track down issue with InvertingMotor jaguar and Talon
Change-Id: I9b5292315c93ec0d568d53a6bcdac5b998a6d857
More Testing on the Inverting motors with jaguars and talons.
Change-Id: I896210a54903e3c0af68e8c41360c165cf9c3122
Added C++ integration Tests for the motor inversion.
Change-Id: I81af5d4aab78d755340d99608b838046bf7ddda1
C++ tests for Motor Inversion now without crashing
Change-Id: Ifdecdbfc1aeb18aafb2b4c63709b27636074a274
More testing of inverted motors (now with c++ tests)
Talon seems not to be working on test rig
Also added a CANJaguartest file in java since was missing
Currently porting the CANJaguar tests from c++ to java
Change-Id: Ib578d6ee1256ac31ddf20603aa6f24adde08065b
Another attempt at adding java tests for can jaguar inversion.
Change-Id: I971a886a4e555ada5bd15a814094da2a1eb5c8e1
Minor changes and attempt to rerun tests after yesterday's jenkins crash.
Change-Id: I7ed0904d4243499c3246e9c39e5493d0d9c962c5
All motor inversion tests should be working now. Talon on the test rig has been fixed.
Change-Id: I20bd6d7486b758ce1ce47ac799150475b3152b6f
Updated Inversion tests again. Should work this time. (worked on the test rig prior)
Change-Id: Ifdf222d5e5733fe802f29e7d939b72e84972e8da
Currently, the JNI bindings are generated by Swig and, unfortunately,
the interface available through Java is lower-level than that for C++
(ie, direct access to the ctre code through the JNI bindings, rather
than an interface on top of that), but it does work.
See eclipse plugins for some short samples.
There are a couple of short unit tests as placeholders.
Still needs some cleaning up.
Change-Id: Iae2f74693ca6b80bf7d5aca0625c66aa6e0b7f85
Added quick samples for C++/Java CAN Talon stuff.
Change-Id: I3acb27d6fd5568d88931e0d678c09973d436735d
Fleshed out CANTalon interface; it currently works just to write a
throttle. The firmware doesn't fully support everything yet, so we are
still significantly limited.
Change-Id: I2868c4c168a8cb42cda754589777beef31ffd354
CANSpeedController is a subinterface of SpeedController that adds method
prototypes and enums for all of the common smart speed controller features.
CANJaguar implements this interfaces. CANTalon does too, but
most methods are stubs right now.
Change-Id: I67e0177d91e45444657280502a247d787ad5c74c
