Dyalog Forums

[Updated 2017-06-30 to include 16.0 details]

This list details the base executables that appear in the release of each version of Dyalog APL for Windows. It details the version number, the date the file was created and the buildIDs for the (up to 4) different editions/widths of interpreter.

The patching mechanism needs to start with the appropriate executable, otherwise you will get Error 404s and other error messages.

From V12.0 onwards Dyalog creates a separate subdirectory, called Base, which contains amongst other things a copy of the base dyalog.exe. For V11 and prior it is advisable to take a copy of the original dyalog.exe and use that as the start point for patching.

The date of files is what the operating system will reports. The BuildID and version number can be found in the Help -> About box in the session, or by running +2 ⎕nq '.' 'GetbuildID' and '.' ⎕wg 'APLVersion' respectively.

Or, for the less archaically-minded...

#.GetBuildID 0
e49218e2
#.APLVersion
Windows-64 12.1.1.4305 W Development

... except that these expressions only work with "Expose properties of root" enabled - which is not the default setting.

and given that their accessibility is quite important could Root Properties be added as a third bit to the value of ⎕WX so that given a current value of 3, assigning it 7 would automatically expose root properties in the local environment?

I could imagine making something like []SYSTEM.GetBuildID available from anywhere, but I think it would be a mistake to extend the support for exposing these methods as "part of the workspace". I have never felt comfortable with the flag which adds these potential name conflicts with user code.

Morten|Dyalog wrote:... except that these expressions only work with "Expose properties of root" enabled - which is not the default setting.

I wish I understood why the default setting is what it is. I have run with it enabled "for ever" - the only problems I ever get with it are having to undo the default every time there's a new version.

Morten|Dyalog wrote:I have never felt comfortable with the flag which adds these potential name conflicts with user code.

So if it were made available under program control we could control it:
{
    ...
    ⎕WX←4+4|⎕WX
    ver←#.APLVersion
    ⎕WX-←4
    ...
}
As it is, if we need it we're stuck with it all the time.

GetBuildID *is* already "available under program control":

{2 ⎕NQ '.' 'GetBuildID'}

I don't see the advantage of messing with more and more bits in ⎕WX (which is another one of those features that one would ideally want to retire eventually, rather than add to) in order to be able to write #.GetBuildID. The potential for future name conflicts with existing names in your workspace as we add more root methods just doesn't make this an attractive approach (to me).

Oh, now I get it - name conflicts.

I wonder whether stuff like GetBuildID belongs in a "system" namespace, something other than quadSE (that's too full already)? That way we only have one name to conflict with, and a suitably obtuse name might reduce the chances still further.

Yup - ⎕system.GetBuildID. ⎕.GetBuildID looks good to me, but won't work so long as ⎕ is "evaluated input".