This changes the HAL notifier interface to:
- Use wpiutil signal objects. This means waiting is done through the
`WPI_WaitObject` API instead of a dedicated function and allows for
higher level code to simultaneously wait on notifiers and other events.
- Interval timers are supported at the HAL layer
- Handlers are now required to acknowledge notifications. This is
invisible to users unless they're directly using the HAL API.
- For interval timers, an overrun count is maintained to detect if the
handler didn't acknowledge
The underlying implementation still uses condition variables for the
actual waiting. In basic testing using this approach seemed to be lower
jitter than timerfd.
Currently, the simulation and systemcore implementations are nearly
identical except for a few additional sim hook bits. This could be
refactored, but keeping them separate may make sense to keep the
systemcore implementation easy to read and reason about, or if we ever
choose to use a different underlying timer implementation on systemcore.
The simulation side API is unchanged in form but does change in
function--waiting for notifiers now only waits for currently running (or
newly signaled) notifiers to acknowledge. To avoid a race condition in
sim stepTiming, users of the low level API must make any alarm updates
(especially for one-shot alarms) prior to acknowledging the previous
alarm.
The only current use of the interval timer feature is the `Notifier`
class. The `TimedRobot` implementation still uses a single notifier and
its own interval timing logic to ensure consistent callback order. Using
separate notifiers for each user-level interval would substantially
increase complexity. `Watchdog` also doesn't use the interval timer, as
it's looking for an amount of time since the last `set` call rather than
a recurring interval time.
To reduce flicker, the sim GUI uses a fade out when a timeout goes from
set to unset.
This fixes tsan for wpilib and commands, and also fixes some spurious
test failures.
#8363 split all the cross-compilation into separate jobs, however these
jobs are still also building the world (including the tests) targeting
the host.
Since `//:publish` and its dependencies are transitioned to target the
desired platforms for each artifact, `bazel build //:publish` in the CI
jobs that aren't running tests to only build what we actually care about
in these jobs.
This saves around 1 to 1.5 minutes for each cross-compile job with 100%
cache hit rates.
I'm not entirely sure why Java header compilation is disabled for the
macOS build. But this option will be causing rebuilds to happen more
often than strictly necessary.
[Turbine](https://github.com/google/turbine) takes Java class sources
and spits out .class files with all method bodies, and private fields
and methods stripped. This provides a .jar with sufficient information
on the classpath to build dependent Java libraries without depending on
the implementation in the build graph.
The update yaml step _might_ cause changes that would affect the build
file generation. Since `bazel run //:write_robotpy_update_yaml_files`
runs them all at once, user that was using the github action to fix
their python stuff would end up having to run it twice.
By running the steps individually in series, this should be able to get
it in one swoop.
We are running out of disk space. If we split the
build up more in parallel, that'll use less space in each build.
Signed-off-by: Austin Schuh <austin.linux@gmail.com>
Offline conversations have pointed out that the bazel output is very noisy upon a failure. The -k that was there for a while was recently deleted in another PR, and this one removes --verbose_failures. --verbose_failures prints all of the command line arguments, which can be quite lengthy and make it harder to find the actual compiler error.
This also removes the -vv from the clang-tidy step. I have found it very hard to find the actual errors when its printing out all of the debug information.
This uses all the infrastructure we put together earlier to actually build and publish all the artifacts.
We might still want to adjust what is built by default to control CI times.
Signed-off-by: Austin Schuh <austin.linux@gmail.com>
Co-authored-by: PJ Reiniger <pj.reiniger@gmail.com>
Co-authored-by: David Vo <auscompgeek@users.noreply.github.com>
This is owned by WPI, so we can make it as big or small as we want.
This lets us check in more of the bazel build.
Signed-off-by: Austin Schuh <austin.linux@gmail.com>
clang-format 21 made some formatting changes. Since wpiformat's stdlib
task was removed, I removed NOLINT comments for it and removed some
std:: prefixes it added to comments.
We build docs in three different places, which is annoying to deal with, and it means we build docs two more times than necessary. Now, docs are built just once in the main Gradle workflow, with warnings promoted to errors, eliminating the need for the separate job in lint-format.yml. The uploaded docs artifact is then unpacked and commited to the GitHub Pages repo like normal.
libprotobuf is a very annoying dependency to deal with, and with the switch to nanopb for generated C++ code, libprotobuf is only used for dynamic decode in the GUI apps. libprotobuf has been swapped out with upb, a much smaller C-based library that supports reflection and can therefore do dynamic decode. This means we can remove the libprotobuf dependency and stop dealing with build issues because of it.
Windows is proving to be a *lot* slower than everything else. I supect
this is because we are building both arm64 and x86 every time, which
ends up being twice the work. Leave those builds in place, but skip
doing them in CI. This should be a 2x speedup when building Windows
code.
Signed-off-by: Austin Schuh <austin.linux@gmail.com>
This follows the gradle build accurately. Gradle copies debug symbols
into a second file (libfoo.so.debug) and links it back into the .so
file. Disable this behavior when gradle doesn't do it today.
Also, name everything correctly. When building debug builds, most
libraries get a 'd' at the end of them. Do that here too.
