forums.dyalog.com

From Phil Last on the DyalogUsers forum:

Version 12.1 sees the version in APLVersion extended to 4 nodes from 3.
I currently have:

APLVersion
Windows 12.0.5 W Development

APLVersion
Windows 12.1.1.3889 W Development

I know the first (12) and second (0 and 1) nodes are but I can't now
remember whether the third is significant in putting a saved ws out of
reach of older versions.

My reason for wanting to know is that although )SAVE prompts with a
msgbox if I ask 12.1 to save my ws that was last saved by 12.0, ⎕SAVE
doesn't afford me the same consideration.

Will 12.1.2 wss (if such ever exist) be inaccessible from 12.1.1 and is
the answer algorithmic?

I can easily write a condition into my Save function but need to know
what the criterion is.

Phil

The (new) fouth segment of APLVersion is the revision number (in SubVersion) from which the version was built.

Unfortunately, there are no elements of APLVersion which give you the answer that you are looking for. There is an internal workspace structure version number which we increase every time we change the structure of the workspace in a way which means older versions cannot load the workspace.

I think this has happened every time there was a change in the first two nodes, and occasionally on a change in third node. In VERY rare occasions, it can happen as the result of a patch. We do what we can to avoid this (I cannot remember the last time it happened except during Alpha/Beta testing), but sometimes a fix requires a change to the structure which means we need to bump the internal version number.

Hope this is helpful, even if it doesn't really give you the information you want.

Morten

Is there a way we can get hold of this internal version number?

Jane

No, I'm afraid not - and it isn't something that we are contemplating making available. In principle, you should not attempt to exchange workspaces (or ⎕ORs, which are wrapped-up pieces of workspaces) with back versions, no matter how small the difference is... Even when the workspace version number has not changed, we might have missed something and there COULD be a problem.

So the workspace version information isn't really very useful, and we do not want to be bound to the way that it is currently implemented. If you want to exchange code across multiple versions, we recommend using (Unicode) text files.

Hello Jane

Morten is quite right in what he says: we do not provide nor intend to provide a language mechanism to find the workspace version number. However, this UNIX programmer has one or two tricks up his sleeve that will allow you to get that information, albeit in a slightly roundabout way !

The location of the version number is documented in the magic file which is supplied with our UNIX products; this allows the UNIX file command to display information about Dyalog APL file types.

Look at the 2↑2↓ of the first few bytes of a saved workspace. They tell you the workspace major/minor number. You would have to ⎕save a workspace from your current interpreter in order to tell what the current version number is.

I've included the contents of the magic file which is supplied with our AIX-based releases: the 1st column specifies which byte in the file, the 3rd column the values, and the 4th column the description. The magic ">" tells you that it's a continuation line, so a file starting with 0x aa 03 01 02 would be a workspace with type (aka version) 1.2. Be careful of byte swapping though !


As Morten points out, we reserve the right to change the location of this information, and the workspace version number is NOT a totally reliable indicator of the ability of two versions of APL to share workspaces.

Also (and this is solely for our Linux users) the version of the magic file which comes with the operating system contains an outdated version of the Dyalog magic numbers; you should always use file -m $DAYLOG/magic, or incorporate the $DYALOG/magic entries with into the operating system-supplied one.

Code: Select all

# Dyalog: file(1) magic for Dyalog APL V12.1

0       short           0xaa03          Dyalog APL
>2      byte            x               workspace type %d
>3      byte            x               subtype %d
>7      byte            &0x28=0x00      32-bit
>7      byte            &0x28=0x20      64-bit
>7      byte            &0x0c=0x00      classic
>7      byte            &0x0c=0x04      unicode
>7      byte            &0x88=0x00      big-endian
>7      byte            &0x88=0x80      little-endian

0       byte            0xaa            Dyalog APL
>1      byte            0x00            aplcore
>1      byte            0x01            component file 32-bit non-journaled non-checksummed
>1      byte            0x02            external variable exclusive
>1      byte            0x06            external variable shared
>1      byte            0x07            session
>1      byte            0x08            mapped file 32-bit
>1      byte            0x09            component file 64-bit non-journaled non-checksummed
>1      byte            0x0a            mapped file 64-bit
>1      byte            0x0b            component file 32-bit level 1 journaled non-checksummed
>1      byte            0x0c            component file 64-bit level 1 journaled non-checksummed
>1      byte            0x0d            component file 32-bit level 1 journaled checksummed
>1      byte            0x0e            component file 64-bit level 1 journaled checksummed
>1      byte            0x0f            component file 32-bit level 2 journaled checksummed
>1      byte            0x10            component file 64-bit level 2 journaled checksummed
>1      byte            0x11            component file 32-bit level 3 journaled checksummed
>1      byte            0x12            component file 64-bit level 3 journaled checksummed
>1      byte            0x13            component file 32-bit non-journaled checksummed
>1      byte            0x14            component file 64-bit non-journaled checksummed
>1      byte            0x80            DDB

0       short           0x6060          Dyalog APL transfer