Peter Johnson

Without a use case, I'm not seeing the value in removing validation that to date has not been an issue for teams.

Isn’t allowing it near certain to cause a resource conflict though? Since running any other command on the same subsystem would instantly conflict.

This would be a very breaking change, as SimValue's are also used by the device implementation, and "read only" values are written by the device implementation for reading by simulation...

There's no such thing as a read-only SimValue. Direction is a state of mind :). SimValues are always writable. Source trace: - Java: https://github.com/wpilibsuite/allwpilib/blob/main/hal/src/main/java/edu/wpi/first/hal/SimValue.java#L41-L43 - JNI: https://github.com/wpilibsuite/allwpilib/blob/main/hal/src/main/native/cpp/jni/SimDeviceJNI.cpp#L221-L226 - C API...

Direction also shows up in the HAL websockets interface (it determines whether values are prefixed with "", or ""). And yes, I think it's the desired behavior for them to...

We likely have several classes affected by this, essentially what's happening is we use the simDevice return value as a proxy for is-simulation. A relatively low impact change would be...

I'm thinking some of these "helper" classes, particularly the Command ones, are designed for specific use cases and thus should be entirely final (e.g. SequentialCommandGroup or InstantCommand)--what's the reason to...

/wpiformat

To be clear, you're only expecting to record autonomous? The stop in disabled will stop the recording after autonomous (as the robot will spend a short time in disabled mode...

Given how much time is spent importing the hal, I suspect a lot of time is spent in ctypes overhead. Creating a Python C module shim .so might speed this...