Saving handles to nested functions

test_hnf2.m (168 Bytes)

As discussed in the online meeting today, here’s an example function that can be used to demonstrate the way handles to nested functions share call stack frames and how that should work even after saving and reloading the handles.

Try the following:

[fh1, fh2] = test_hnf2 ();  %% create handles to nested functions
fh2 ()                      %% should display captured value  ==> 1
fh1 ()                      %% increment and display ==> 2
fh1 ()                      %% again ==> 3
fh2 ()                      %% display ==> 3
[fha, fhb] = test_hnf2 ();  %% independent set of handles
fhb ()                      %% note that the values shared belong to the
fha ()                      %% stack frames active when the handles

Octave can’t save these objects yet but if you save them in Matlab then clear all and reload them, you should be able to continue execution from the point where you saved them:

save nested-handles.mat fh1 fh2
clear all                        %% or start a new session 
load nested-handles.mat
fh2 ()                           %% display ==> 3
fh1 ()                           %% increment and display ==> 4

One question that came up in the meeting was what Matlab file formats can be used to save handles to nested functions. I expect only -v7.3, but could someone try saving them using -v7, -v6, and -v4? I expect failures with all of these, but just to be sure…

save nested-handles-v7-3.mat fh1 fh2 -v7.3
save nested-handles-v7.mat fh1 fh2 -v7
save nested-handles-v6.mat fh1 fh2 -v6
save nested-handles-v4.mat fh1 fh2 -v4

seems everything in matlab behaves the same as octave, but for the saving question at the end, saving works in all but v4

also, seems you can’t attach a no extension or .txt text diary file. @siko1056

Thanks for checking. I would still be in favor of focusing primarily on the v7.3 format since that uses HDF5.

Good catch, now I allowed txt files to be uploaded. In general you can compress anything into a zip and upload it avoid unnecessarily large files.

Yes, I agree to your ideas from the online meeting. Octave should strive to support HDF5 and larger data sets. Maybe we can “out source” several old data formats by maintaining a “convert old format X to v7.3” tool. And if load ("old_data.dat") fails, that Octave tries to convert the file to something new. Thus effectively discouraging users from using super old formats while not giving up reading “prehistoric” data sets. Maybe an extra discussion thread? :innocent: