How do I find out which OS Dyalog in running in?

[ray]

I am writing (and testing)some code under Dyalog APL/W for use on the Raspberry Pi running under Linux.

Is there something like APLVersion that will run in both Linux and Windows?

Is there any APL that I can run (without traps or reading error messages) that will allow me to distinguish?

For example "whoami" runs in both DOS/Windows and Linux
⎕CMD'whoami'
pi
⎕CMD'whoami'
win7-64\ray

Or ⎕CMD'echo $1'
Under Windows I get "$1" and Linux (,⊂'')

The first element of ⎕AI (0 for me under Windows as I don't set the network ID, 1000 under Linux)

Is there an ⌶ (I-beam) function?
Any suggestions?

[ray]

UH!

'.' ⎕wg'alpversion'

I did not realise one can use ⎕WG under Linux!

[Morten|Dyalog]

Writing cross-platform APL application code is something that is becoming very important to Dyalog. We have extended support for pieces of ⎕WG to UNIX platforms to make it easier to write portable code - and rudimentary support for ⎕SE to allow cross-platform user commands and SALT support. All of our recent utilities and frameworks like SALT, SAWS, MiServer, SQAPL (for ODBC) and the upcoming R interface, are cross-platform. We hope to add a Java bridge, similar to the current .NET bridge, to give access to a major framework across all platforms where APL runs (and that should be extended to include Mac OSX and perhaps also Android in the next year or so).

We will probably do more work in this area, adding more tools to let you understand the capabilities of the current platform, and hide some of the most common differences. We will be doing design work in this area during the summer, so this would be a good time to write to us with suggestions for features to deal with the cross-platform issues that you have experienced.

Please write to me direct if you would like to suggest features that you would like us to consider in this area (or to the Forum if you would like a public discussion).

[ray]

As a side issue, I am writing a "remote - controlled" (via keyboard) robot.

I want to use the Cursor Control Keys with and without Shift and Ctrl
UC UL US, DC DL DS, RC RL RS, LC LL LS
To control different parts of the robot, along with other keys.

EG
UC -Forward
DC -Adt
LC -Turn to port
RC -Turn to starboard
Q -Stop all motors
1 -Poweroff
2 -Reboot
3 -Exit APL

I have managed to get this working with single keystrokes via ⎕SM and ⎕SR.
However ⎕SR is unable to tell me when US (shift+up cursor) is pressed as I only get back the "UC".
(I wanted Shift Cursor and Ctrl Cursor keys to activate servos controlling Pan and Tilt movements.)

If I try to use ⎕ARBIN, I can see when US is sent, but I have ask ARBIN to read in a fixed number fg bytes.

So having a onKeyPress event that can trigger a call-back function, so one can determine that keys were pressed would be useful, to me.

[Geoff|Dyalog]

Ray: I would be careful of developing on APL/W for use on the Raspberry Pi. The keyboarding is very different. The Pi is a Linux box and the keyboard will have been processed by xkb (assuming you have a GUI desktop). This means it is character based. All of the shift, control, windows key aspects will have been removed by the time you see the keys.

Our traditional cursor control codes that you would expect from a normal keyboard will deliver escape sequences as defined by termio and our translate tables. What you eventually see are things like UC.

For our control sequences that termio would not normally handle there are pages in Unicode that are reserved for application use. We have defined our control codes into those pages. They are generated when the APL keyboard is selected and certain keys are pressed. The APL keyboard is, at the users choice, selected by a "while pressed" key. I normally use the "any Win key while pressed" but you can choose other possibilities. "Caps lock while pressed" is quite attractive as is "Left Alt while pressed". What is happening with any of these is that the 2nd keyboard is selected.

Documentation (with illustrative comments - use an editor that understands UTF-8) of how the key codes are matched to the keyboard is in /opt/mdyalog/14.0/32/unicode/opt/aplkeys/xterm (substitute version, bit width ... as appropriate).

For robot control purposes you may prefer to completely define an xkb keyboard for your own purposes. At that point you can allocate different Unicode code points to "cursor up", "ctrl+cursor up", "shift + ctrl + cursor up", "alt gr + cursor up" ... Not only that but if you are defining just one keyboard you can probably use it without bringing up a GUI desktop.

You can the react to each of those Unicode code points.

The key allocations for xkb are in /usr/share/X11/xkb/symbols/apl.

Both of these files can be changed but it will be, challenging, to get hold of the low level data of which shift keys have been pressed.
It has got better, in many ways, but I had to work quite hard to do the original Linux APL keyboard. In some ways it has got worse: Gnome3 is a bit of struggle. However, if you only need one keyboard and are not swapping, or expecting alternate layouts mapped to "groups" then it is not too difficult.

A bit of history. Back in the early 90s we had an X based product and to process the keyboard keystrokes on that product we did know which shift keys had been pressed. That was going in at a lot lower level than we currently do. It should be possible to use that old approach, wrap it up into a .so and ⎕NA to that interface. All of that low level X still exists.

[Geoff|Dyalog]

I ought to add a few things.

The ctrl/shift etc have been removed by the time apl itself sees the character.

If you read 1 byte at a time with ⎕ARBIN you can easily tell if the byte is part of a UTF-8 sequence. Indeed any byte will tell you how many more follow and how many preceded it.

The thing you want to avoid is allocating a meaning to ESC. If you do you will have a problem distinguishing between ESC by itself a and a control sequence that starts with an ESC. Resorting to timeouts to distinguish this is horrible.

[Geoff|Dyalog]

One other thing. The way xkb works is that shift cntrl etc control "levels" if you type a key for which the higher levels are not defined you get the highest level that is defined. This is probably why you keep seeing UC independent of how many shifts you are adding.

[ray]

Geoff

Thank you so much for your very useful keyboard notes. The .../symbols/apl file is most helpful.


Ray

[Geoff|Dyalog]

If you do define, or modify, a keyboard at the xkb level do keep a copy. The package management tools will overwrite the whole area as a unit as updates are brought in.