You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Original bug ID: 3986 Reporter:@mmottl Status: resolved (set by @xavierleroy on 2012-08-02T06:51:40Z) Resolution: suspended Priority: normal Severity: feature Version: 3.09.1 Category: otherlibs Monitored by:@mmottl
Bug description
Even when marshalling functions are called with sharing of data allowed, bigarrays that share data due to "slice" and "sub" are not reconstructed in a semantically equivalent way. It's surely not that easy to efficiently implement extraction and reconstruction of the exact shared data ranges used by some bigarrays without including superfluous data. The "quick" solution of just including the whole initial data would, however, still be better than not have any sharing at all, which may lead to subtle bugs.
I have attached a file that demonstrates the problem. It prints "2 42 42 42" but should print "2 42 42 2".
Six years later, we still don't have any answer to this feature wish: preserving this sharing would require either major changes to the marshaller (so that custom marshallers have somehow access to the re-sharing machinery) or reimplementing Bigarrays so that proxies are represented by OCaml data structures. Plus, there would be a potential problem with a large bigarray being marshalled in full while all the user asked was to marshal a small subarray. I'm "suspending" this PR.
Original bug ID: 3986
Reporter: @mmottl
Status: resolved (set by @xavierleroy on 2012-08-02T06:51:40Z)
Resolution: suspended
Priority: normal
Severity: feature
Version: 3.09.1
Category: otherlibs
Monitored by: @mmottl
Bug description
Even when marshalling functions are called with sharing of data allowed, bigarrays that share data due to "slice" and "sub" are not reconstructed in a semantically equivalent way. It's surely not that easy to efficiently implement extraction and reconstruction of the exact shared data ranges used by some bigarrays without including superfluous data. The "quick" solution of just including the whole initial data would, however, still be better than not have any sharing at all, which may lead to subtle bugs.
I have attached a file that demonstrates the problem. It prints "2 42 42 42" but should print "2 42 42 2".
File attachments
The text was updated successfully, but these errors were encountered: