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
This is because obects wt and wt1 at row 3 and 4 are using the same .tmpsqw object, Row 5 deletes temporarty sqw file wt object uses after which operation wt1 at row 6 does not have underlying file to work with.
Current solution for that is to use copy operation to create deep copies of filebacked sqw objects. Filebacked sqw objects are usuallt used this way by advanced users so this is not a big problem.
It we implement unique references and reference counting for instruments, detectors and samples, this problem would occur for all sqw objects in operations like that:
>>w1= sqw(filename);
>>w2=w1; % shallow copy. Solution w2 = copy(w1); -- currently not implemented but must be.
>>w1=w1.set_mod_pulse(…);
>>w2=w2.set_mod_pulse(…); % FAIL!
This will be immediately noticed and we have to retrain users to use copy for all similar operations, which is usually a problem.
Ultimate solution would be to overload = operator, but Matlab does not allow us to do it. There is matlab.mixin.Copyable superclass, which have sealed signature for copy method and protected method copySingle to overload. This looks like all what is necessary to overload = so may be = is also overloaded by Matlab in matlab.mixin.Copyable. Matlab does not says this anywhere but worth checking the thing.
Purpose of the ticket:
The ticket it to check matlab.mixin.Copyable operations and make political decision of what to do with deep copying if = is impossible to overloaded.
Number of places marked in tests by referencing this ticket are actually test implementation of reference counting. These tests should be enabled if decided to implement reference counting
The text was updated successfully, but these errors were encountered:
Problem description:
Currently Horace would fail if one use asignment to duplicate temporarty filebacked objects. E.g.:
This is because obects
wt
andwt1
at row 3 and 4 are using the same.tmp
sqw
object, Row 5 deletes temporartysqw
filewt
object uses after which operationwt1
at row 6 does not have underlying file to work with.Current solution for that is to use
copy
operation to create deep copies of filebackedsqw
objects. Filebackedsqw
objects are usuallt used this way by advanced users so this is not a big problem.It we implement unique references and reference counting for instruments, detectors and samples, this problem would occur for all sqw objects in operations like that:
This will be immediately noticed and we have to retrain users to use
copy
for all similar operations, which is usually a problem.Ultimate solution would be to overload
=
operator, but Matlab does not allow us to do it. There ismatlab.mixin.Copyable
superclass, which have sealed signature forcopy
method and protected methodcopySingle
to overload. This looks like all what is necessary to overload=
so may be=
is also overloaded by Matlab inmatlab.mixin.Copyable
. Matlab does not says this anywhere but worth checking the thing.Purpose of the ticket:
The ticket it to check
matlab.mixin.Copyable
operations and make political decision of what to do with deep copying if=
is impossible to overloaded.Number of places marked in tests by referencing this ticket are actually test implementation of reference counting. These tests should be enabled if decided to implement reference counting
The text was updated successfully, but these errors were encountered: