Hi everyone,
I’ve been experiencing a freeze whenever I open the Script Editor or double-click a Script component in Grasshopper on my Apple Silicon Mac. Rhino becomes completely unresponsive and I have to force-quit.
I’m not deeply familiar with Python internals, so I fed my log inside .rhinocode folder to Claude to help diagnose it, and it spotted the root cause right away. Sharing here in case others hit the same issue.
Environment
-
MacBook (Apple Silicon, macOS 15.4 Sequoia)
-
Rhino 8 SR25 (8.25.25314.11002)
-
Rhino’s embedded CPython is x86_64 (runs via Rosetta 2)
Symptom
Opening ScriptEditor or placing a Script/Python 3 component on the GH canvas causes Rhino to hang indefinitely.
Root cause
When the script editor initializes, it launches a background language server process:
Running background process: ~/.rhinocode/py39-rh8/python3.9 utils/pyminilsp_server.py
This process is not started with the -I (isolated) flag, so it picks up packages from the user’s local site-packages directory (~/Library/Python/3.9/lib/python/site-packages/).
In my case, I had previously installed Python packages via pip install --user on my system, which installs arm64 native binaries. The language server (running as x86_64 under Rosetta) tries to import black, which imports regex, which tries to load the arm64 .so from my user site-packages:
Error [RhinoCode] ImportError: dlopen(.../regex/_regex.cpython-39-darwin.so, 0x0002):
tried: '.../regex/_regex.cpython-39-darwin.so'
(mach-o file, but is an incompatible architecture (have 'arm64', need 'x86_64'))
The language server crashes, and the editor hangs waiting for a response that never comes.
Solution (workaround)
Removing the conflicting user-level packages fixed it immediately:
bash
rm -rf ~/Library/Python/3.9/lib/python/site-packages/regex*
Then restart Rhino.
Suggested fix
It seems like pyminilsp_server.py should be launched with the -I flag (or PYTHONNOUSERSITE=1) so that it doesn’t pick up packages from the user’s local site-packages. Rhino already bundles its own x86_64-compatible regex wheel (regex-2022.9.13-cp39-cp39-macosx_10_9_x86_64.whl), so the user directory should never need to be on the search path for the language server.
This would prevent the architecture mismatch entirely, regardless of what the user has installed system-wide.
Thanks!
4 posts - 2 participants