Follow-up to #361. The original fallback silently mapped unknown numpy
dtypes to torch.float32, which would reinterpret the memcpy'd bytes in
the wrong dtype and corrupt data (e.g. fp16 tensors from some TTS
engines) rather than erroring loudly.
- Hoist dtype_map out of the inner function so it's built once
- Add float16, complex64, complex128 mappings
- Raise TypeError on unknown dtype instead of silent float32 fallback
Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>
torch is compiled against numpy 1.x. numpy 2.x changed the ABI version
returned by PyArray_GetNDArrayCVersion() (0x01000009 → 0x02000000), so
torch's is_numpy_available() always returns False and torch.from_numpy()
raises RuntimeError. This causes TTS generation to fail with:
ValueError: Unable to create tensor, you should probably activate
padding with 'padding=True'
Two fixes:
1. Pin numpy<2.0 in requirements.txt so new builds bundle a compatible
numpy version. (The existing comment already flagged this intention
but the upper bound was never added.)
2. Add a PyInstaller runtime hook (pyi_rth_numpy_compat.py) that installs
a ctypes memmove fallback for torch.from_numpy() at startup. Runtime
hooks run after FrozenImporter is registered so frozen torch is
importable. The fallback catches RuntimeError from the C-level ABI
check and copies the numpy array into a new tensor via raw memory copy,
bypassing the check entirely. This is a belt-and-suspenders fix that
works regardless of the bundled numpy version.
Co-authored-by: aimaaaimaa <[email protected]>
Co-authored-by: Claude Sonnet 4.6 <[email protected]>
