Reputation: 63
At least one of the single-letter languages (certainly q
) has a facility for interprocess communication, a kind of parallel execution of longer-running processes on multiple computers. These sessions could be on the same computer or on a server on a different continent.
With q, I would simply start a server to listen to a particular port, something like q -p 8510
, then access it from another q session or other software. Impressively easy.
I remember, in the very distant past, using a mainframe APL system with Shared Variables
where I could share a variable with another user. This may have been IBM APL.SV
. I didn't think much of that at the time, but today, decades later, Shared Variables
sounds like the basis for parallel sessions. Share a variable with another computer.
How could or would I do this today with Dyalog APL, or any other APL, where I could
invoke an APL session on another physical computer
send it a command or an expression
receive a result
potentially do this in parallel on many other computers
Upvotes: 4
Views: 320
Reputation: 566
yes, but ⎕SVO comes from a time where IP addresses were not commonly used (or even present). The left argument of ⎕SVO is a "processor ID", a concept similar to file descriptors.
GNU APL follows IBM APL2 except that APL2 allows a mapping from local processor IDs to remote processor IDs and IP addresses, That mapping is (in APL2) provided as an external config file and support for that config file is the missing bit in GNU APL.
In GNU APL, ⎕SVO was only provided for some backward compatibility with IBM APL2, so extending its syntax does not make much sense. For new APL applications it is much simpler to use UDP or TCP connections between processes directly, and ⎕FIO provides all that is needed for that.
Upvotes: 1
Reputation: 566
If you want to do it in the old-fashioned way (and trust me, you don't) then here is an example of how to do it (in principle):
http://svn.savannah.gnu.org/viewvc/apl/trunk/src/testcases/APnnn.tc?view=log
Have a look at all files APnnn*. In GNU APL the example only works with two APL workspaces that are running on the same machine, but with IBM APL2 they could reside on different machines. In the IBM case some additional configuration for the processor IDs on the remote machines will be required, so the example needs to be adapted a little.
Upvotes: 1
Reputation: 788
In fact, "Old Fashioned" Shared Variables are still supported in Dyalog APL under Microsoft Windows via the DDE protocol, but they are considered deprecated.
Recent versions of Dyalog APL support parallel or asynchronous execution through isolates, which are separate processes that appear as extensions of the active workspace. Any expression executed within an isolate immediately returns a future. Futures can be passed as arguments to functions, and be manipulated by structural primitives without blocking; if they are passed to a primitive function which needs to know the value they will automatically block until the computation of the result is completed.
The documentation for futures and isolates is online, and there are a number of videos online - for example there is the talk where they were introduced at Dyalog'14 here:
Parallel Programming with Dyalog 14.0 on YouTube
In version 17.0 we will be including support for the APLSSH class, which will make it straightforward to launch isolates on remote machines.
Finally, if you want to communicate between APL processes which are already running, the TCP library "Conga" (which is also included in a standard Dyalog installation) allows you to pass APL arrays between processes using TCP/IP, even if the processes are running on different machine architectures. Documentation for Conga is also online.
Upvotes: 5
Reputation: 7530
Nice question! In a recent Webinar Dyalog's CXO illustrated one way to do this (handling how to easily setup Docker Containers running your code on aws or elsewhere). Also Isolates might be useful - see i.e. this example.
Upvotes: 3