GH Script component freezes on Apple Silicon Mac

Scripting
, ,
1

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!

3

Oh this is great catch. Thanks for the workaround and suggested fix. I created the ticket below and will push a fix for this.

@Takuya_ITABASHI Would you mind giving me a bit more context on why python subprocess is running on x86_64 architecture? Rhino 8 itself is a Universal app so it has both arm and x86 binaries. Same is with the python that is shipped with Rhino. So they should be both running in native mode.

Are you somehow enforcing the app to run over Rosetta?

RH-94776 Launch python3 subprocess with -I flag

5

Hi Ehsan, sorry for the late reply and thanks for digging into this.

You’re right. I had the “Open using Rosetta” checkbox enabled on Rhinoceros.app in Finder’s Get Info panel. I’d completely forgotten about it, but I turned it on a while back to get Anemone working in a class; it’s compiled x64-only and wouldn’t load on ARM64 otherwise. The setting just carried over and I didn’t realize Rhino 8 was still being forced into x86_64 mode because of it.

So the sequence in my case was:

  1. Rhino.app → launched under Rosetta (because of the Get Info checkbox) → embedded python3.9 subprocess runs as x86_64

  2. Meanwhile, pip install --user on my system (outside Rhino) had installed arm64 wheels of regex, black, etc. into ~/Library/Python/3.9/...

  3. pyminilsp_server.py picked up those user site-packages and hit the architecture mismatch

Disabling the Rosetta checkbox alone would also have fixed my symptom, since the native arm64 Python would happily load the arm64 regex wheels.

6

Sweet. I pushed a fix to 8.x that now launches the script with -I flag included. Thanks for digging into this.

7

RH-94776 is fixed in Rhino 8 Service Release 32 Release Candidate