The tools described here are a variation on the earlier APL Utilities approach to delivering common code across a number of Dyalog APL applications. It uses functionality introduced in APL/W Version 11 (specifically namespace and class scripts), with the benefits
⎕OR has proven unreliable as a format for holding code, and while Dyalog are not decommitting, they are advising against its use for this purpose.
Note that the code described here is a simplistic alternative to the SALT code management tools included in the Dyalog APL/W Version 11 product.
Essentially nothing has changed since the earlier paper
Workspaces hold application-specific code, which is augmented by general-purpose code loaded at startup time
If any of the general-purpose code is changed during an application development session it may be written back to the main utility repository during normal application shutdown.
This load/save mechanism may be overriden in a production environment, so that production applications are insulated from (irrelevant?) development activities.
Note that, at the moment, this work is in a shakedown phase and may be subject to change (this document should be updated to keep in step, but it's worth checking).
Scripts are held as Unicode files, read/write code is a minor modification of code supplied by Dyalog as part of the APL/W product. Notice the implication that not only can these files be displayed meaningfully outside of the APL environment, they may also be changed there - this is not recommended.
Over and above the default Dyalog script format there's some use of stylised comments.
⍝:Saved 2006 9 12 14 2 51 921
This commenting convention may be modified (or scrapped) in the future.
As with the earlier utility approach, scripts are loaded into nominated namespaces and ⎕path is extended as loading takes place.
A goal is to minimise the amount of code which needs to be manually copied into each application (and recopied in the event of changes). The previous utility code relied on two functions and a variable, this has been reduced to
Using the ⎕SEUnicodeFile class included in APL/W.
These three lines in the latent
loadfile←⎕NEW #.⎕SE.UnicodeFile loadfile
The (present) assumption is that utility load/save code is held in a file called utilloader.dyalog one step up the folder structure from the application (this is probably going to be rethought)
At present this is somewhat crude.
At application startup UtilLoad loads all required scripts which are not in the “already loaded” list. The name of any script loaded at this stage is appended to this list.
Interrupting or resetting the application and making changes does not affect the “already loaded” list. Changes can be made within the (utility) namespaces and/or classes. The workspace can be saved at this point.
Subsequent restarts will not load the “change-pending” scripts, because their names are on the list.
At clean shutdown UtilSave saves all scripts and, as it does so, removes their names from the “already loaded” list. As scripts are saved a “saved” timestamp is appended as a comment. During development (when application code is held in the workspace) it is normal to save the workspace at this point.
At some future date it is intended that this mechanism will be made more sophisticated – for now, it serves its (carefully-used) purpose of getting development with scripts off the ground.
There's a class maintenance application which lets you review what classes you have, and their internals. Although script files are viewable and editable within NotePad (and other extra-APL editors) it seems wisest to try to keep active script editing within the APL development environment – at least for now.
The script maintenance application displays this form...
The left pane shows all script files held within the currently-selected folder. File/Open allows the user to select a different folder.
Right-clicking over a file name shows the file contents (the script) in the right pane.
Some pseudo-globals are used (they are actually defined as functions within the script-handling script, but used as globals therein).
Default folder containing scripts
A table of script names and intended in-workspace location (the namespace the script is loaded into)
Dogon Script Maintenance is available on a no-charge as-is basis; there is no formal support, but queries and suggestions may be sent to Dogon Research.
The APL code (which may be obtained on request from Dogon Research) is copyright © Dogon Research 2003-2006, but may be copied for personal use; commercial use is strictly prohibited. The executable version may not be reverse-engineered.
Copyright © Dogon Research Ltd., 2003-2006