Attention: Saving workspaces

[Dr . Jürgen Sauermann]

Hi everybody,

I am currently doing some rework of the )SAVE and )LOAD commands.

Before updating GNU APL from SVN the next time (and in the near future), please make sure
that you have made a backup of all your workspaces.

If you prefer )DUMP over )SAVE to store your workspaces, then you are fine because
nothing will be changed there.

If you normally )SAVE your workspaces, then please note the following.

A.  )SAVE and )LOAD are intended for short term storage, i.e. the )SAVEd workspace
  should be be )LOADed with the same (SVN-) version of the interpreter. Even tthough
I am   trying my best to keep these commands backward-compatible, I cannot guarantee
that I will always succeed.

B. The only advantage of )SAVE over )DUMP is that it stores the )SI stack. This is
   sometimes necessary when:

B1. sending a workspace for trouble-shooting (and only if the )SI stack is relevant), or
B2. to interrupt APL code troubleshooting and continue the next day.

In contrast to the old days (where a )SAVEd  APL session) could be completely
restored) this is no longer the case. There are more and more components that
do not allow their state to be serialized, and as a consequence the workspace
)LOADed will increasingly differ from the workspace )SAVEd before. That, in
turn, will make the )LOAD and )SAVE commands more and more meaningless.

C. If you want to stay with )SAVE then I would recommend the following procedure
for updating GNU APL:

C1.  )DUMP the workspace as a precaution for one of the subsequent steps failing.
C2.  If appropriate: )SIC. This will not only make the saved workspace smaller but will
       also significantly reduce the probability that something will go wrong later.
C3.  )SAVE the workspace.
C4.  update the interpreter (typically from SVN).
C5.  )LOAD the workspace again and check that it still works.
C6.  )SAVE the workspace again.
C7.  repeat the steps above (except C4 ) for all your workspaces.

D. The reason for the ongoing changes is that a specific case (a derived function lurking
     on the )SI stack) is currently not handled properly by )SAVE and )LOAD. Currently you
     get a warning if that happens, but in the long run this should work. That is somewhat
     difficult, though, and therefore it will take a while before this is fixed.

Best Regards,
Jürgen