This checked that individual char arrays in the MJCF schema were not null, which would never really happen, and triggered some compiler warnings
PiperOrigin-RevId: 520348916
Change-Id: Ic8b82737460ed3bcf44d9629cd0c7de5782bee8c
Previously, it returned a view into the internal rgb array, which can be confusing to the user.
PiperOrigin-RevId: 517630186
Change-Id: Ibc1e86b6b6345269523bb4c82c37dd325961a8ec
- Schema table now has attribute links and is open by default.
- Attributes are in 4 columns.
- Fixed various documentation bugs made visible by this change.
- Removed distance equality constraint from xml_native_reader.cc
PiperOrigin-RevId: 517558035
Change-Id: Ibc7715587dd4e72253231bfd55bd037f0193b3fd
- Find Python functions in the interpreter binary itself rather than trying to find libpython.dylib, because this doesn't exist when using Conda. (https://github.com/conda-forge/python-feedstock/issues/595#issuecomment-1311275470)
- Increase the stack size of both the Python main thread and the OS main thread to 16MiB, to match what Python normally uses on macOS. (https://github.com/python/cpython/blob/3.11/configure#L11038)
- Check whether dlfcn and pthread function calls actually succeeds. Emit error messages and exit on failure rather than continuing the program (which generally leads to segfaults).
- Fix pixelated shadow in the icon.
PiperOrigin-RevId: 517390522
Change-Id: Ib91679b4baa63bac5f6b5893e634712d72161ea5
Add -Wgnu-empty-initializer to Clang builds to catch this issue in the future. Initialising arrays with empty braces is not part of the C standard and fails on MSVC. This commit should catch the issue earlier by detecting it in Clang.
PiperOrigin-RevId: 517373961
Change-Id: I518006e84151e8d5b45a7fe00ba7675dfb031ca0
It is quite possible that there are a few other fields still missing since we currently do not yet have automated testing of struct field existence.
Fixes#747.
PiperOrigin-RevId: 517189048
Change-Id: I7c1d95e700eaea05aaa3cde1fd05e1a259553117
The bug was introduced in 2f0fb1e4ef. The glfwSwapBuffers call should occur on the main UI thread, not the CoreVideo DisplayLink thread.
PiperOrigin-RevId: 517172202
Change-Id: I2491f2194765019748198cd0cc61ca9263331b01
The `launch_passive` function launches the GUI viewer in a non-blocking manner, allowing the Python script or REPL to continue execution. The viewer is automatically kept up to date with any subsequent modifications to mjModel and mjData.
Note that when run inside a REPL (including IPython), `launch_passive` is functionally identical to `launch_repl`.
On Linux and Windows, this is achieved by spawning a new thread and launching the GUI there.
On macOS, this is not possible as all Cocoa API calls must be made on the "macOS main thread", which is always the first thread launched in a process and carries the `com.apple.main-thread` dispatch queue. We also cannot simply trampoline from a Python script on the main thread into the user's script on a side thread because CPython's signal handler can only be installed on the "Python main thread". Putting the user's script in a side thread means that it cannot e.g. gracefully handle SIGINT by catching a KeyboardInterrupt exception. To work around this, we ship a custom Python launcher on macOS called `mjpython`. This launcher is a native binary that spawns a pthread and initialize the Python interpreter on that thread, thus allowing "Python main thread" and "macOS main thread" to represent two distinct threads. From Python's point of view, the "macOS main thread" is a secondary thread that runs a loop that continuously empties a Queue of (mjModel, mjData) and launches a viewer.
PiperOrigin-RevId: 517167868
Change-Id: Icac9d2126bbb4760d47e0b9300e0a979cffa4338
Yuval Tassa