Providing workspaces for a older version

[jwied]

Here is on of the "silly" questions:
How can I easily provide workspaces, which have been saved with a newer version of Dyalog APL (e.g. 13.2) for older versions (e.g. 13.1 or 12.x)?

Even in the case of an 13.2 workspace, we get an "this WS requires a later version of the interpreter" message, whan )loading it with 13.1.

Probably I´m not the only one, who has to deal with more then one version.
So I hope, a discussion about this could help others, too.
Jürgen

[Phil Last]

You might try:

      ]OUT filepath

in your latest version followed by:

      ]IN filepath

in an earlier version but I can't give any further advice as I don't seem to be able to use it with my code in 13.1 that might have something to do with the depth or complexity of the namespace tree or the presence of derived functions.

Phil

[DanB|Dyalog]

]in and ]out will only work if you don't have any exotic objects like namespaces of derived functions.
]inX and ]outX will deal (up to a certain extent) with those. Forms for ex won't be exported.
You should read the instructions by doing ]??outx but quickly you can do

in 13.1
)XLOAD yourws
]outx \path\file\name
then
in any version
)CLEAR
]inx \path\file\name.XDW -replace <-the extension XDW is important

if you don't add -replace the system vars []LX, []IO, etc. won't be replaced.

Hope this helps.

[Dick Bowman]

My response might not help your current issue but for a degree of future-proofing it might be worth thinking about saving your code in the scripted form of namespaces. That way you can load them up using SALT (or equivalents), and you can (assuming the code is valid for the other APL) load them up into different vendor's APL products.

It's certainly also a good way to share your utility code across multiple applications.

[DanB|Dyalog]

Actually, Dick, this is not a bad idea and it might help.

Another way to "export" a ws would be to ']snap' it out by doing
]snap \good\location\for\this\ws -makedir

If there are no funny objects in the ws everything will be put onto .dyalog files in that folder (-makedir is to make sure the folder exists, see ]??snap for details).

You can then go to the other APL version and assuming SALT/UCMDS exists there you can do
]load \good\location\for\this\ws\*

You won't get the system vars with this method but you will have a copy of everything and each time you edit a fn or a script you'll be able to get SALT to save the object onto file.

[jwied]

Thank you all.

Working with the scripted form would help, but it might be difficult, when sharing workspaces with other people that don´t want to work with spripted workspaces.

In my daily work as a consultant, I often have to provide workspaces to a customer in that form, he is familiar with. Normally, this is the standard dws-format.
For this purpose, I have to do some kind of "downgrading" with some steps of ]outx (in the newer version), ]inx and )save (in the older version).

By the way, the workspaces, delivered with Dyalog APL v13.2 (like SQAPL, Conga, ...) can be )LOADed with older versions (at least with 13.0).
Dan, how are these workspaces built and with which version of Dyalog APL are they saved?


Jürgen

[Morten|Dyalog]

By the way, the workspaces, delivered with Dyalog APL v13.2 (like SQAPL, Conga, ...) can be )LOADed with older versions (at least with 13.0). Dan, how are these workspaces built and with which version of Dyalog APL are they saved?

Public APL code is typically maintained using the earliest supported version of Dyalog APL, so that updated code can be supplied to customers who are still on earlier versions. We should perhaps re-save them using the latest version each time we build the product, because there can be a small conversion cost when )LOADing or )COPYing old code, but for those components which have version numbers of their own (Conga, SQAPL, SALT) we do not always do this.