This is the Dyalog APL keyboard, which Dyalog provides for the GNU-APL. (Click on image to enlarge it.)
GNU-APL - It Seems to Work Well! - For production-grade data-bashing, we use an old Manugisitcs APL - but an associate mentioned he was using GNU-APL, and it has the advantage of crazy-large workspaces (ie. measured in gigabytes) and
also uses SQL-Lite as the back-end database. This fellow is capturing all daily trading from a particular exchange, and this results in roughly 1 gigabyte of data each day - and so running an SQL query might generate a 100,000 row table, with a
fair bit of data for each row.
So, I was intrigued by this, and found and downloaded the GNU-APL last night, and compiled it and got it running on one of the CentOS-7 boxes.
The current details about GNU-APL should be here:
Damn thing seems to work pretty good. I had to hack around with the keyboard stuff for a while, as the first configuration I tried - using Linux "xmodmap" to configure
the ALT-whatever key to create the APL characters, caused the loss of all the ALT-function features needed to control the XTERM Linux sessions - and even switch contexts between X-Windows in GNOME (and this managed to blow up the Firefox session, and wipe
out a bunch of webpage sessions, of course).
To use "Xmodmap", you can just run:
But maybe don't use this. The loss of "Alt-TAB" (to
switch between Xterm window sessions in Gnome) is lethal to Firefox, and will also prevent ALT-F1, ALT-F2 ... etc. from switching between sessions outside of GNOME. So this approach (which works fine for generating APL characters in Xterm) is no good.
(Note! On older Fedora boxes, I have to use this method.)
But what does work, is this trick (on the latest CentOS Linux boxes:)
xkbcomp ./support-files/old-Keyboard/apl.xkb :0 -w 0
and this works great. (The ":0" is your X-session, "-w 0" means suppress warnings.) On my Fedora/CentOS-7 Linux box, it sets up ONLY the right-side ALT key on the keyboard, to be the ALT key for generating APL characters.
The left-side ALT key still works as it is supposed to, so that ALT-TAB can switch between running Windows in GNOME.
Using the right-side ALT key, allows APL chars to be generated and displayed correctly. For example, ALT(right)-R
creates the "rho" character, ALT(right)-i creates the "iota", and ALT(right)-[ will create the left-arrow for APL assignment operator, ALT(right)-] is the right-arrow, for APL branching, etc. This is the same as the ALT-xx operation of the various GEMESYS
APL apps on Android (using the Android "Hacker's Keyboard"), and yet it still allow the ALT(left-side) key to operate as is required by Xterm and GNOME and Linux. (eg: ALT-CTRL-F7 lets you jump right out of GNOME/X-windows into regular command-line Linux
sessions, and ALT-<Fsession#> lets you jump back into Xwindows/GNOME session. ALT(leftside)-TAB is needed to just switch between Windows - and restore minimized Xwindows/GNOME sessions.)
The GNU-APL has several other methods of creating
the APL keyboard, which I have not tried yet. But the method described here is quite satisfactory, and lets all the APL characters be displayed correctly..
Also, to start APL, in a normal, standard APL interactive workspace session, you run "apl"
with the option "--noColor", which makes the interactive APL session behave in a sane way, like any standard interactive APL.
Eg: - To start GNU-APL after it has been installed:
[Your-System-Prompt-in-Xterm-Window]$ apl --noColor
and you will get a working APL with a big workspace (up to gigabytes, it looks like, if you need this much...). On my CentOS-7 box, if you start without "--noColor" option, you
get an awful video mess, and cannot even see the APL interpreter results. Just enter ")off" to exit APL, an then enter "reset" and to fix your borked X-term session (it might be blank, no video chars visible!), and the virtual terminal will reset
correctly. But if you enter "--noColor", it works fine. Note there are "two" dashes for this critical parameter, not one.
How to Install GNU-APL:
[ I am running an old gcc (GCC) 4.8.5 20150623 (Red-Hat
4.8.5-28) with all the associated development utilities need to build anything now on Linux... ] So, to build GNU-APL:
- download the APL-1.7 gunzipped tarball from the GNU-APL ftp site. Note that this
can be seriously slow sometimes:
Download apl-1.7.tar.gz from site: https://ftp.nluug.nl/pub/gnu/apl/
Create directory in /home (ie. become root, cd /home, mkdir gnuapl, cd gnuapl)
cp /home//Downloads/apl-1.7.tar.gz . (copy file to
gunzip apl-1.7.tar.gz (create .tar file, ie. removes the .gz compression)
(untar the package)
cd apl-1.7 (connect to build directory where you will compile source)
(if running a modern Linux, this should just work, and setup build defaults)
make ( run the Makefile to do the compile of the
(Check the apl executable... cd src, ./apl --noColor (to run the GNU APL)
(Try something like 234+3, press return, and confirm you see: 237 as the response)
(If the exectuable runs ok, you may as well just install it and experiment
make install ( if the compile ran without errors, you can just install the apl executable)
For now, I am running the APL-1.7. I will try the
1.8 version tonite on a different machine and see if it works. My associate who has been working on this says that the 1.7 (circa 2017) is very stable, but he could not get APL 1.8 to run without getting segfaults.
Initial experiments with the
GNU APL 1.7 look quite promising. Very promising, actually.
Coda: How to check the GNU APL signature file (or any GNU project Signature)
1) ensure you have gpg on your machine. If a modern Linux
(ie. since 2008!) it should be there.
2) Assume you put the files APL source and .sig files in /home//Downloads
Go to your broweser,
and download the keyring signature file for GNU projects. Just cllck this link:...
This gets the file gnu-keyring.gpg file into Downloads directory. Run a gpg with --verify to check that the .sig file matches what was signed on the .tar.gz file:
--verify --keyring ./gnu-keyring.gpg apl-1.7.tar.gz.sig apl-1.7.tar.gz
This command says "Look in gnu-keyring.gpg to confirm the .sig is a real sig file, and verify that the apl-1.7.tar.gz file was signed with this
signature. You should get a "Good Signature from..." response, in this case: "Jurgen Sauermann (Programmer) <email@example.com>". Note that you also get a WARNING saying there is no certainty that this key is actually a trusted
key (you have to fiddle with GPG stuff more to get a "web-of-trust" thing setup, and that is another thing..)
Also, you can run the MD5 hash against the apl-1.7.tar.gz file, and I get this value, when I run it against mine:
gpg --print-md md5 apl-1.7.tar.gz
(should respond with:)
A0 64 56 F4 AA 9E 34 97 00 DA 51 C8 EF D1 41 50
(BLah blah blah - MD5 is not the most
secure message digest - blah blah blah blah.)
and for MD5 hash check (message digest check) for "apl-1.8.tar,gz",
gpg --print-md md5 apl-1.8.tar.gz
71 FF 2D 30 7C F2 26 80 67 DE ED 50 26 EC
I like MD5 becuase it is simple and fast and is better than no security at all, guys.
And this GNU-APL seems to work good.
Update: To get the APL Libraries
in wslib3, wslib4 and wslib5 to be visible to the interpreter, I had to create a local "preferences" file in ~/.gnu-apl directory, and remove the references that are in the default build-preferences file (see build-directory "gnu-apl.d" for the standard default
preferences file, and just copy it to your local .gnu-apl directory). Replace the @GNU_APL_LIBS@ strings in each of the LIBREF-n statemetns with "." to point to your local directory, and then create local directory copies of each of the subdirs wslib3,
wslib4, wslib5 that are in the GNU-AP build directory.
Just cd to build directory (in my case, I used: /home/gnuapl), and then copy the directories for each of the APL libraries to your local user directory:
cd /home/gnuapl (connect to your build directory...)
cp ./wslib3 /home// -v -R (make local copies of each of the APL Library directories,
3, 4 and 5. )
Then, when you start GNU-APL, and enter ")libs" you should see that your three APL Libraries show up a "present" instead of "missing",
GNU-APL - Latest SVN Version
Note: It is a good idea to install the latest SVN version. You need to install (or already have, like most Linux installations do), the SVN code version management tool.
If SVN is installed on your local machine, you can get all the code
with this command below. Just create a new directory (I used "mkdir /home/gnuapl" to create a directory under the "/home" top level Linux directory.) Then, "cd /home/gnuapl", and with that as your default directory, just run this:
and that above command will create a directory "trunk" with the very latest GNU-APL code in it, and you can just "cd trunk" and try the "./configure". If it runs ok, run "make", and if that
works, you can just run: "make install", as described above.
If there are errors or problems you will have to resolve them.