Converting workspaces and using SALT & subversion to maintain them. V1.01
Introduction This is an example of converting an existing application to SALT and using a version control system afterwards to maintain it.
What is SALT? SALT is a tool to deal with code outside the workspace in text (Unicode) format.
Script form Up until V11 namespaces came in a single form. They contained functions, variables and other namespaces.
Script form Starting with V11 namespaces also came in a script form. The contained functions, etc. are listed in text format:
Script form The script and the functions in it can be edited via the editor, e.g. )ED ns2 )ED ns2.tfn1
How do we do it? • We'll see the conversion process and • how to use subversion, a third party product, to control its versioning
The situation • BAAD is a military weapons manufacturing company • One of its best sellers is the SD2, a device used to search and destroy specific targets
BAAD's SD2 product • This unit is self contained: its behaviour is set once and does not require external input. • There are several (possibly 1000s) models, each with a different code name. The logic (code) of each is unique.
BAAD's SD2 product • Unit is made of 2 main components: • a driving component • a weapons component
Testing the product • Obviously, testing these devices in real life presents a problem • In its infinite wisdom the company has decided to use a simulator written in (what else?) Dyalog APL • A single workspace holds all the system
The simulator Battlefield Units' Consoles Battling units
The simulator's structure • The workspace is divided into namespaces • One namespace contains all the units' logic, here its name is 'R' (for Robots) • Each unit's logic is also contained in a namespace whose name is the name of the unit (like CARLA or AI2)
The simulator's structure Here, namespace R is where all the Units' logic reside
Updating the workspace • This involves modifying individual units' code in their respective namespaces • and resaving the entire workspace when finished with the changes • This prevents other users from updating the workspace at the same time
Acceptable updating timeline Tester A change save load Time save load change Tester B Sequential updates
Unacceptable updating timeline Tester A change save load Time save load change Tester B Tester A's changes are overwritten by Tester Beven if the modified namespace is different
Tracking changes Another problem with this model is that changes are irreversible. Even tracking changes is difficult. Finding differences in code is hard to document.
Dyalog V11.0 This version allows namespaces to exist in script format. Instead of having a series of namespaces each with functions and variables
Dyalog V11.0 You can have everything in script form, including the definition of variables
workspace Scripts files Keeping namespaces in scripted form allows us to save them in (Unicode) text files outside the workspace.
Updating can now be done in parallel for different namespaces change Tester A namespace A save load Time save load namespace B Tester B change Tester A's changes are NOT overwritten by Tester B
Tracking changes It is easier to track changes now that files are in human readable format. By saving multiple copies we can see the difference between each modification. workspace
Tracking changes Comparing files can be done easily in APL by SALT or by any 3rd party program. Line a Line b Line c Line a Line X Line c
Doing it The first step is to convert the workspace to the new form
Converting the workspace Start Dyalog, SALT should be there:
Converting the workspace If it isn’t we have to make sure SALT is enabled:
Converting the workspace )LOAD our workspace:
Converting the workspace Bring in the conversion tools:
Converting the workspace ConvertCode is a namespace containing code to perform conversion of regular (non sourced) namespaces. The function to use in it is <Convert>.
Converting the workspace For example, to convert namespace 'UTIL':
Converting the workspace To convert several namespaces first )CS where the namespaces are:
Converting the workspace Then use an expression like:
Converting the workspace Explorer now shows us the namespaces with the new icons:
Converting the workspace The workspace has the same functionality as before. It can be )SAVEd in this new format
Filing away The next step is to store those namespaces in Unicode files. Altho is it relatively simple to read/write text to file, their management is a bit more complex. Again, SALT comes in handy.
Saving the scripts as text files • decide where to put them • use the SALT Save function
Saving the scripts as text files The Save function takes a string argument of: 'namespacelocation':
Saving the scripts as text files To save all the namespaces at once do:
Saving the scripts as text files If you want to save everything at once you can do instead
Saving the scripts as text files Either way you should now have a folder with many scripts in it:
Making changes SALT 'remembers' where each script was saved. Changing one of them now means SALT will change the file as soon as the script is modified through the editor.
Making changes Here's what one of the units' logic looks like:
Making changes And here we make a change:
Making changes SALT detected the change and offers to change the script file:
Making changes You should )SAVE the workspace here. Like this SALT will remember where the edited namespaces are stored and detect if changes have been made outside APL (e.g. with Notepad)
Version Control This is the 2nd part of the work to do. SALT comes with its own versioning of files and comparison functions but it is primitive compared to state of the art version control systems like subversion.
Version Control For a company like BAAD it is preferable to use existing software like subversion. To use subversion we first need somewhere to put the scripts files.
Version Control We picked folder \weapons as repository