Outputs.share() fails on Windows: shape/dim wires are sized as int32 but always read as int64

[prawnsgupta]

While working on a code block that shares a plain numeric array with outputs.share(), I found that the call fails immediately on Windows, before any block logic runs.

What happens

Outputs.share() sizes the _shape and _dim wires from arrays built without an explicit dtype:

https://github.com/JdeRobot/VisualCircuit/blob/master/backend/staticfiles/synthesis/lib/outputs.py#L47-L48

shape = np.array(data.shape)
dim = np.array([len(shape)])

np.array([...]) uses the platform's default integer, which is int32 on Windows and int64 on Linux/macOS. Both buffers are then read back — here and in inputs.py — as np.int64:

self.outputs[name]["dim"] = create_ndbuffer((1,), np.int64, dim_wire.buf)

So on Windows the wire gets 4 bytes and numpy is asked for an 8-byte view of it.

Reproduction

import multiprocessing, numpy as np
from lib.outputs import Outputs

print("numpy default int on this platform:", np.array([1]).dtype)

o = Outputs({"Out": {"wire": "demo_a", "lock": multiprocessing.Lock()}})
o.share("Out", np.arange(100, dtype=np.float64))

Output (Windows 11, Python 3.11, numpy 1.26.4), with a print added inside _create_wire to show the requested sizes:

numpy default int on this platform: int32
  allocated demo_a_shape        4 bytes
  allocated demo_a_dim          4 bytes
  allocated demo_a_type        24 bytes
  allocated demo_a            800 bytes
Traceback (most recent call last):
  File "repro_a.py", line 16, in <module>
    o.share("Out", np.arange(100, dtype=np.float64))
  File "lib\outputs.py", line 72, in share
    self.outputs[name]["dim"] = create_ndbuffer((1,), np.int64, dim_wire.buf)
  File "lib\utils.py", line 5, in create_ndbuffer
    return np.ndarray(shape, dtype=dtype, buffer=buffer)
TypeError: buffer is too small for requested array

This is not data-dependent — every share() call fails the same way, so no circuit using a generic share() output can run on Windows at all. It goes unnoticed on the maintainers' side because on Linux the default int is already int64 and the sizes happen to line up.

Why the other paths are fine

_share_npy_matrix() (used by share_image and share_array) already pins the dtype explicitly:

dim = np.array([len(matrix.shape)], dtype=np.int64)

and share_image() passes np.array(shape, dtype=np.int64). So it is only the generic share() that is inconsistent with the rest of the file.

Suggested fix

Make share() match _share_npy_matrix():

shape = np.array(data.shape, dtype=np.int64)
dim = np.array([len(shape)], dtype=np.int64)

I have this verified locally and am happy to send a PR with it. There is a second, independent sizing bug in the same function that this fix exposes — I'll file that separately so the two can be reviewed on their own.