1 / 90

SALT in Dyalog

SALT in Dyalog V1.17 is a toolkit for managing source code of classes and namespaces in Dyalog APL. It consists of functions stored in []SE to manipulate object source code stored in .dyalog files. Functions enable saving, listing, exploring, loading, and more. SALT stores in Unicode files, automatically opens with Notepad in Windows, and is enabled by default in V12. You can store objects using SALT's Save function in specific or relative paths. Explore and modify settings, including file view options. Manage source code with ease using SALT in Dyalog.

prichards
Download Presentation

SALT in Dyalog

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. SALT in Dyalog V1.17

  2. Introduction SALT is a Simple APL Library Toolkit Itis a source code management system for Classes and script-based Namespaces in Dyalog APL.

  3. 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

  4. Commands All SALT functions are monadic. They • Save objects in files • List files • Explore them • Load them • and more…

  5. 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.

  6. 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.

  7. Enabling SALT in V12 By default SALT is enabled when V12 is installed. To disable SALT you can use the configuration menu.

  8. Enabling SALT in V12 The configuration menu:

  9. Enabling SALT You can also use the included SALT workspace to enable or disable SALT: )load SALT enableSALT disableSALT

  10. Storing using SALT We can now store any sourced object:

  11. The Save function Save takes a string as argument. To find its syntax give it a single ‘?’:

  12. The Save function Ask SALT to store it in a specific path:

  13. The Save function Ask SALT to store it in a relative path: mine\test’ C:\Program Files\Dyalog\V12\SALT\mine\test.Dyalog

  14. 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.

  15. 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

  16. 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

  17. Viewing the file in Notepad Double click the file opens with Notepad

  18. Listing folder contents List takes a pathname as argument and displays its contents:

  19. Listing folder contents Example, list the contents of study\GUI:

  20. Listing folder contents Example, list Samplesrecursively:

  21. Explore Explore allows to look at a script with an external editor or to browse using the OS’ explorer:

  22. Exploring folders Exploring a folder merely opens up the disk Explorer. Example, exploring folder Samples:

  23. Exploring folders Example, exploring folder Samples\GUI:

  24. Exploring files Exploring a file opens up the file with Notepad. Example, exploring file Samples\GUI\Othello:

  25. 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’

  26. Loading from file Objects can be brought back from file through the use of Load:

  27. Loading from file By default objects are brought in the current namespace. To select a different namespace use the –target modifier:

  28. Loading from file By default all the functions and variables in a namespace are kept in their namespace: WS fn1 fn1 fn2 fn2 Target=#

  29. Loading from file To bring them separately you can use the –disperse modifier: WS fn1 fn2 fn1 fn2 Specific elements can be selected Target=#

  30. Loading from file You can bring several files at once using a pattern: WS Fn1 fn1 fn2 Fn2 []SE.SALT.Load ‘Fn*’ Target=#

  31. 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.

  32. 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.

  33. Settings This function takes ‘’ or ‘a_name’ or ‘a_name followed by a value’. With ‘’ it returns all the settings and their values:

  34. Settings With a_name it returns the value associated with that particular setting name. Here the path to the editor to use:

  35. Settings With a name & value it associates the value with the name. Here we change the editor setting to use for the session to “WordPad”:

  36. Ws Registry Settings The settings can be permanently stored in the registry using the –permanent modifier:

  37. Ws Registry Settings The settings can be restored from the registry using the –reset modifier:

  38. Settings Settings can also be overridden temporarily for the duration of a statement, for example to use temporarily another editor while exploring:

  39. 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

  40. 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.

  41. 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 –pattern=U’ All (remaining) functions: []SE.SALT.Snap ‘\my\fns –class=3 ’

  42. 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 objects where they belong.

  43. 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:

  44. 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

  45. 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:

  46. Keeping several versions of a script Every time you modify a script SALT stores the definition in a new file: V0 V1

  47. 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

  48. =? 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)

  49. =? 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.

  50. =? Comparing versions externally For example, to use Compare It!, a third party program available from the net, you can use the SALT command Settings to set it to [ProgramFiles]\Compare It! or the full pathname to its location

More Related