This is increasingly difficult to maintain, and has very limited
benefit. Modern coprocessors with enough horsepower to run Java
applications can use the Gradle or Bazel build systems instead.
`SetNowImpl` is used somewhat often in unit tests. It is a little bit
goofier to wrap because it takes a C function, so a little bit more work
has to be done to get that wrapped in pybind.
Claude helped.
The initial build file generation for robotpy projects was relatively
naive and purpose built to get `allwpilib` compiling, without supporting
all the available features.
This modifies the generation scripts to be able to support multiple
embedded libraries, which will be necessary for #8858, since `mrclib.so`
will need to be bundled along with the hal libraries. In addition some
cleanup was done to get the wheels looking more like what is in pypi.
There were 3 cases failing before.
1. An OpModeRobot with no annotation.
2. An OpModeRobot with an annotation but a parameterless constructor.
3. An OpMode with a UserControls constructor
This PR solves both of these issues. The first one is solved by adding
the null check before setting the user controls instance. That one will
never have an opmode instance.
The second one is solved by falling back to a parameterless constructor
if one with a parameter is not found.
The 3rd one is solved by using the annotation type rather than the
instance for constructor lookup.
Also fixes ExpansionHubSample's missing annotations.
This lets us remove the unmaintained StackWalker library and its hacky
upstream_utils script.
@Gold856 reported that StackWalker gives blank stacktraces:
https://discord.com/channels/176186766946992128/368993897495527424/1261940029287301150.
They also reported an earlier version of this PR giving the following
stacktrace instead:
```
D:\allwpilib\developerRobot\src\main\native\cpp\Robot.cpp(18): developerRobotCpp!Robot::RobotInit+0xB6
D:\allwpilib\wpilibc\src\main\native\cpp\TimedRobot.cpp(22): wpilibcd!frc::TimedRobot::StartCompetition+0x4F
D:\allwpilib\wpilibc\src\main\native\include\frc\RobotBase.h(36): developerRobotCpp!frc::impl::RunRobot<Robot>+0xC8
D:\allwpilib\wpilibc\src\main\native\include\frc\RobotBase.h(106): developerRobotCpp!frc::StartRobot<Robot>+0x17E
D:\allwpilib\developerRobot\src\main\native\cpp\Robot.cpp(60): developerRobotCpp!main+0xB
D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl(79): developerRobotCpp!invoke_main+0x39
D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl(288): developerRobotCpp!__scrt_common_main_seh+0x132
D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl(331): developerRobotCpp!__scrt_common_main+0xE
D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_main.cpp(17): developerRobotCpp!mainCRTStartup+0xE
KERNEL32!BaseThreadInitThunk+0x1D
ntdll!RtlUserThreadStart+0x28
```
People generally have expressed a dislike for the Hungarian notation
used in member variables, especially in examples/templates, and our
styleguide shouldn't be forced on downstream consumers, so this removes
all Hungarian notation from the examples/templates.
There are _some_ benefits to Hungarian for private member variables
(like knowing what's a member vs. local in a PR review) so we'll keep
private member variables the same for now, but public variables should
no longer use Hungarian notation, since it looks much worse. A new PMD
XPath rule has been added to accomplish this goal. Some other
non-compliant variables were fixed for the new rule.
There were complaints about no patch files being created from CI when
the examples pre-gen fails for people who don't build with bazel. This
adds a new action step to run just the non-robotpy pregen.
I also added an argument to the diff tests to make it a unified diff,
which might make it easier to hand fix.
Part of the `semiwrap` process that hasn't been ported over yet is
generating pyi stubs. It is possible to not have your semiwrap setup
correctly and "leak" native types into the generated python docstrings,
which causes the process to
[fail](https://github.com/pjreiniger/mostrobotpy/actions/runs/24618640845/job/71985311682#step:12:3652).
semiwrap also has a tool you can run, 'create-imports' that will read
the symbols from a build pybind library and automatically create and
sort the imports in the `__init__.py` file. This step is not enforced by
CI, which is why it hasn't been failing in `mostrobotpy` land.
This PR fixes the stubgen problems and runs reorganizes the imports. I
will have a follow up PR that can bring these automatically into the
build system after this lands. I'd do a fancy new `gh stack` but I can't
figure out if it works on forks.
Commands v3 had a few changes due to the upgrade:
- Java 24 removed the Pinned: MONITOR IllegalStateException when
yielding in a synchronized block, so we no longer need to special case
for it
- Lambda method name generation was tweaked, requiring tests to be
updated
- Bazel java_rules needed to be bumped to support Java 25
Closes#8425
This primarily fixes up the bazel publishing to match the gradle
publishing again, as some new libraries were added but not hooked up to
the maven publishing.
During the process, I noticed that the 3rd party libraries (googletest,
catch2, and imgui_suite) were still getting published on the old
`edu.wpi` namespace. I tried to clean up all the other references to
that that I could. Note: opencv and libssh are handled outside
`allwpilib` so they need to be updated separately.
Jackson is a very heavy library; it supports loads of features that we
don't need, and historically has caused issues due to long class loading
times (a little over 2 seconds to load AprilTagFieldLayout). This often
manifests as a help request in the form of "my robot disables when I do
X, but doesn't disable when doing X in subsequent attempts until code
restart." While SC has brought down Jackson loading times significantly,
with AprilTagFieldLayout loads taking only 330 milliseconds, that's
still a rather long delay, and while libraries should handle any JSON
loading ahead of time to prevent delays in auto/teleop, it would still
be good to make the worst case better to reduce user frustration.
Benchmarks indicate using [Avaje
Jsonb](https://github.com/avaje/avaje-jsonb) to load AprilTagFieldLayout
only takes ~70 ms, a fair chunk of which isn't actually in Avaje Jsonb
(~4 ms is spent on using getResourceAsStream to retrieve the JSON file,
~8 ms is spent on just loading the AprilTag class and its dependencies).
Note that all times listed are end-to-end, meaning nothing else was done
except for the operation being benchmarked, and doing arithmetic on them
can be flawed due to some classes being loaded twice, i.e.,
getResourceAsStream and `new AprilTag()` likely load some of the same
JDK classes and so subtracting both from the Avaje Jsonb load time is
likely slightly incorrect because class loading is being double counted.
For our purposes, it's likely accurate enough and is mostly just for
contextualization.
Benchmarks were run on a Raspberry Pi CM5 with 2 GB of RAM. Source code
for the
[results](https://github.com/user-attachments/files/26471452/benchmark.txt)
can be found in the "Fastjson2" commit
(2456d15ca8ebd17635e607cd40bf8816e77869a1).
Avaje Jsonb uses code generation via annotation processors to generate
the classes needed to do JSON serde and uses service providers to find
them, which will require downstream changes in robot projects, as the
different service providers in each library must be merged together for
Avaje Jsonb to function. We will use the Gradle shadow plugin, as its
already used by the installer and therefore adds zero additional
dependencies.
`Color::FromHSV` didn't match the Java `Color.fromHSV` in some saturated
edge cases, introducing an off-by-one error when the HSV color should
correspond complete saturation of one or two of the primary colors.
Example:
- Java: `Color.fromHSV(0, 255, 255) -> (255, 0, 0)`
- C++: `Color::FromHSV(0, 255, 255) -> (255, 1, 1)`
This also means the following methods are also transitively affected:
- `AddressableLED::LEDData::SetHSV`
- `LEDPattern::Rainbow`
This off-by-one error is introduced by a rounding error from the chroma
calculation, which was dividing by 256 rather than the appropriate
maximum value of 255 like in Java:
7ca35e5678/wpilibj/src/main/java/edu/wpi/first/wpilibj/util/Color.java (L176-L177)
Also port appropriate tests from Java to C++ to catch this bug.
I found this bug when I tried to port `AddressableLEDBuffer` to RobotPy.
Codex found the root cause :)
Some discussion with the tech team showed that there were some real
advantages to being able to pass a 2nd type. It allows separating the DS
and Robot. Additionally, we can make the DriverStationBase class
actually usable instead of the existing DriverStation class which is
impossible to handle in intellisense because it has too much.
This won't fully be doable in C++, but we will need to implement
something similar in python.
This hooks up the bazel build to the robotpyExamples. It can use the
(formly pyfrc or whatever) automatic unit tests for an example, as well
as exposing the ability to run the example in simulation, with or
without `halsim_gui` with a command such as `bazel run
//robotpyExamples:AddressableLED-sim`
This required building and using wheels instead of just a normal
`py_library`, so that things like `ENTRY_POINTS` can be used. I took a
bare bones approach to building and naming the wheels (for example the
native ones don't have the OS info or python version in them, so they
wouldn't be suitable publish to pypi, but that can always be updated
later.
