SALT in Dyalog V1.16
Introduction SALT is a Simple APL Library Toolkit Itis a source code management system for Classes and script-based Namespaces in Dyalog APL.
Basics • SALT consists in a series of functions stored in SE to manipulate the source (SRC) of objects. • The source code for each object (function or namespace) is stored in a single Unicode text file with a file extension of “.dyalog”. • All functions take a string to do their work. • This string describes the arguments and possibly some -modifiers for the function
Commands All SALT functions are monadic. They • Save objects in files • List files • Explore them • Load them • and more…
Storage SALT stores source in Unicode (UTF-8) files whose extension is .Dyalog .Dyalog files are configured to be opened automatically with Notepad under Windows upon installation Under Unix, the naming of the files is case sensitive.
Requirements There are NO special requirements (not even .Net) V11 is the minimum version SALT will run under SALT is packaged and comes in already available with V11.
Enabling SALT in V12 By default SALT is enabled when V12 is installed. To disable SALT you can use the configuration menu.
Enabling SALT in V12 The configuration menu:
Enabling SALT You can also use the included SALT workspace to enable or disable SALT: )load SALT enableSALT disableSALT
Starting SALT Upon starting Dyalog SALT will identify itself:
Storing using SALT We can now store any sourced object:
The Save function Save takes a string as argument. To find its syntax give it a single ‘?’:
The Save function Ask SALT to store it in a specific path:
The Save function Ask SALT to store it in a relative path: mine\test’ C:\Program Files\Dyalog\V12\SALT\mine\test.Dyalog
Storing using SALT By default SALT will store the source under [Dyalog]\SALT where [Dyalog] is the installation location. SALT will replace[Dyalog]by whatever location Dyalog is installed.
Storing using SALT Here Dyalog was installed under C:\Program Files\Dyalog\V12 and the installation location was [Dyalog]\SALT so the sources will all be stored under C:\Program Files\Dyalog\V12\SALT Since we asked to store test under mine\test the final path, after adding the extension, is C:\Program Files\Dyalog\V12\SALT\mine\test.Dyalog
Storing using SALT If a different location is desired the workdir setting must be modifiedto specify the location. For example you could decide that all scripts go under \CMS\DYW instead of the default
Viewing the file in Notepad Double click the file opens with Notepad
Listing folder contents List takes a pathname as argument and displays its contents:
Listing folder contents Example, list the contents of study\GUI:
Listing folder contents Example, list Samplesrecursively:
Explore Explore allows to look at a script with an external editor or to browse using the OS’ explorer:
Exploring folders Exploring a folder merely opens up the disk Explorer. Example, exploring folder Samples:
Exploring folders Example, exploring folder Samples\GUI:
Exploring files Exploring a file opens up the file with Notepad. Example, exploring file Samples\GUI\Othello:
Exploring files Notepad is the program used by default. To change this use the SALT setting editor, e.g. SE.SALT.Setting ’editor ...\WordPad’ To use another program for just this time use the modifier –use with the name of the program to use e.g. SE.SALT.Explore’Othello –use=...\WordPad’
Loading from file Objects can be brought back from file through the use of Load:
Loading from file By default objects are brought in the current namespace. To select a different namespace use the –target modifier:
Loading from file By default all the functions and variables in a namespace are kept in their namespace: WS fn1 fn1 fn2 fn2 Target=#
Loading from file To bring them separately you can use the –disperse modifier: WS fn1 fn2 fn1 fn2 Specific elements can be selected Target=#
Loading from file You can bring several files at once using a pattern: WS fn1 fn1 fn2 fn2 SE.SALT.Load ‘fn*’ Target=#
Settings Some functions assume global settings, e.g. Explore assumes Notepad to view files. Settings come from the registry and are brought into the session at start-up. They can be modified for the session or even for the time a function is used. Modifications can be saved back for the next APL session.
Settings A particular setting has a name and a value, just like in the registry. The value can only be a string. It may be empty.
Settings This function takes '', 1 name or 1 name followed by a value. With '' it returns all the settings and their values:
Settings With 1 name it returns the value associated with that particular name. Here the path to the editor to use:
Settings With a name & value it associates the value with the name. Here we change the editor to use for the session to “WordPad”:
Ws Registry Settings The settings can be permanently stored in the registry using the –permanent modifier:
Ws Registry Settings The settings can be restored from the registry using the –reset modifier:
Settings Settings can also be overridden temporarily for the duration of a statement, for example to use temporarily another editor while exploring:
Features SALT has a number of features that make it more interesting than a simple store and retrieve utility. It can • save entire workspaces at once • store several versions of a script • compare them • remove versions • run scripts without fixing them in the ws • start automatically
Snapping workspaces Instead of using Save to store each function/namespace in the workspace you can use <Snap> to do the work: SE.SALT.Snap ‘\my\location’ Will store everything to \my\location, one script per function/namespace.
Snapping workspaces <Snap> can be used on a subset: All namespaces: SE.SALT.Snap ‘\my\scripts –class=9’ All objects starting with the letter ‘U’: SE.SALT.Snap ‘\my\utils –stem=U’ All (remaining) functions: SE.SALT.Snap ‘\my\fns –class=3 ’
Snapping workspaces <Snap> remembers what has been saved and won’t save again what hasn’t been modified. It also remembers where objects have been saved so “Snapping” again will put changed or new objects where they belong.
Storing several versions of a script SALT can save back a script on file right after it has been modified. Modify <test> After modification you are prompted to confirm saving over the present script file:
Storing several versions of a script This also happens if you modify a fn of a class on the stack. Stack shows up Edit the function After modification you are prompted to confirm saving over the present script file. Once saved both the script and the class are modified and you can resume execution. Error happens
Keeping several versions of a script You can store and KEEP several versions of a script. By using the –version modifier you tell SALT to start using version numbering:
Keeping several versions of a script Every time you modify a script SALT stores the definition in a new file: V0 V1
Keeping several versions of a script List can show the various versions: But you need to supply the –version modifier: The latest (using date) version is always visible and on top If started without version numbering, the original has no version number
=? Comparing versions Compare is used for that. You must give it the name of the script(s) and the versions to compare. If no version is specified the 2 highest versions are used. If a single number is specified it is compared with the highest version. Ex: SE.SALT.Compare ‘fileA –version=5’ will compare version 5 of <fileA> with its highest version (probably also most recent)
=? Comparing versions Normally, Compare will use its own comparing code to perform the comparison. If a different program is wanted it should either be specified on the statement line with the –use modifier or in the settings. The Setting to use then is compare It should specify the path of the program to use or ‘APL’ if SALT is to do it itself.