Once you have written some code to solve your problem, you might want to make it available for others to use. Your users may be other specialists in your field, or other people looking to do similar processing or analysis as you. They may or may not also be APL users.
Deploy as a standalone application or service, or integrate your APL solution with your existing technology stack as a shared library or using an interface to external languages.
Delivering Your APLs
See materials for the talk “Delivering Your APLs” which demonstrates many ways to deploy a Dyalog application.
Dyalog Text Source Files
dyalog LOAD=/path/to/Function.aplf
dyalog CONFIGFILE=/path/to/run.dcfg
Learn more about launching Dyalog from text files in the Link User Guide section on setting up your application. Dyalog Workspace
Save your application code in a small, portable binary workspace file which can be run using the same or later versions of Dyalog on any supported platform.
)SAVE /path/to/myapp
Users can load the entire workspace application (overwrites the current active workspace)
)LOAD /path/to/myapp
or copy parts of one workspace into another.
)COPY /path/to/myapp fnname varname
Learn more about runtime applications and components on Microsoft Windows:
APL as a Shared Library
Call APL functions from C, C++ or any other language with an interface to native shared libraries (Foreign Function Interface).
Dyalog provides an SDK which can be used to package APL code along with the Dyalog interpreter as a shared or static library (.dll, .so, .dylib). This library can then be called by any language which is able to access native shared libraries.
The JSON_APL Shared Object offers a plug-and-play shared object with which users can call APL functions by passing character strings. It also functions as an example of using the shared library SDK.
Documentation:
Shell Scripts
Shell scripts are widely used to run sequences of shell commands under Linux and similar operating systems. Shell scripts that begin with the symbols #! (“hash bang”, or “shebang”) followed by the name of an interpreter allow the rest of the script to be handled by the named interpreter rather than the default script processor.
Video: Scripting in Dyalog v18.2
Docker Containers
Video: Dyalog’s Docker Containers by Morten Kromberg at Dyalog ’20
Containers provide a consistent environment across different machines and operating systems. The effect is similar to that of virtual machines, but more lightweight and efficient. Read the docker website to learn more about Docker containers and images.
Dyalog provides pre-made containers for:
Including support for interactive debugging using the Remote IDE.