How can I enter APL on an i386/ASCII laptop keyboard?
Chris Jones
I downloaded the aplus-fsf packages on debian linux and started the
interpreter, from a shell prompt in an xterm but now I am stuck.
I guess a need to install an APL font such as the Kapl family, but then
what would be the preferred mechanism to enter the APL symbols?
Thanks.
Martin Neitzel
Hello Chris,
after 10 days I finally got around to compile some detailed answers
for you. The documentation coming with either the A+ sources, the
Debian packages, or the aplusdev.org web site are indeed very poor
in this respect.
Once you have things set up properly, "Alt+i" will give you the iota etc.
Here are all the gory details:
There are four obviously aplus-related debian packages available offhand:
$ cat /etc/debian_version
5.0.7
$ aptitude search aplus
i aplus-fsf - A+ programming language run-time environment
i aplus-fsf-dev - A+ programming language development environment
i aplus-fsf-doc - A+ programming language documentation
i aplus-fsf-el - XEmacs lisp for A+ development
Out of these, the "aplus-fsf-dev" appears to be the most appropriate
to us developers. A closer look reveals:
$ aptitude show aplus-fsf-dev
[...]
Depends: aplus-fsf, aplus-fsf-doc, aplus-fsf-el
Recommends: xfonts-kapl
[...]
So: doing an "aptitude install aplus-fsf-dev" will include the other
three, but you have to take care to install the fonts separately:
$ aptitude install xfonts-kapl
(If not done already; an "aptitude show xfonts-kapl" will reflect your
current status.)
The "aplus-fsf-doc" package has all the html-pages from the
aplusdev.org web site, which also include installation hints
regarding the font isseus. The material gets dropped into
/usr/share/doc/aplus-fsf-doc; Tell your browser to open the URL
file:///usr/share/doc/aplus-fsf-doc/html/index.html
The xfonts-kapl package will drop various APL fonts into one of
the standard X11 font directories. My firefox picks up the fonts
without further ado.
At any rate, your first step is make sure you have the fonts
installed and locatable under their short "alias" names. After
installing the xfonts-kapl package, you may want to verify:
Is /usr/share/fonts/X11/misc/Kaplcour-14.pcf.gz there?
Does "xset q" list that directory in your font path?
And finally:
Does "xfd -fn Kapl" show you the APL font?
Do not even think to proceed before this works. The debian package will
work in a simple "Linux-Desktop-PC" setting, but not in more complex ones.
For example, in my environment I use a centralized office server in
our server room (running the Debian with Aplus), but on my desk, my
diskless PC just runs a local X11 server, serving as the I/O frontend
for all applications. The fonts needs to be available *to my local X11
server*, and this needs some additional setup.
Once you have the APL font xfd'able, the next step is to run
to run a+ with the fonts.
The "a+" interpreter is supposed to be run in an xterm configured
(a) to use one of the supplied APL fonts
(b) to have key translations defined to make Mod1-combos (vulgo:
(the ALT-keys) adress the various APL chcaracters.
The packages include an XTerm application defaults file taking care
of all this. Unfortunately, it is a bit hidden in the aplus-fsf
distribution and just in compressed form:
/usr/share/doc/aplus-fsf-doc/app-defaults/XTerm.gz
The tricky part now is that there are serveral ways to make an xterm
actually use these definitions. What is best for you is highly dependent
on your local circumstances.
One fail-safe way to use it:
[once only:]
mkdir -p ~/lib/aplus
zcat /usr/share/doc/aplus-fsf-doc/app-defaults/XTerm.gz > ~/lib/aplus/XTerm
[daily use:]
env XAPPLRESDIR=$HOME/lib/aplus xterm -e a+
I for one already have my own ~/lib/app-defaults/XTerm in place, with
same settings I wouldn't want to miss for a+ programming, either.
I opted to incude the resources into my standard personalized XTerm
file, but with the "ressource class" specification changed into
a "ressource name" specification, so I can use them easily for running
a+. Here goes:
[once only:]
zcat /usr/share/doc/aplus-fsf-doc/app-defaults/XTerm.gz |
sed s/XTerm/aplus/ >> ~/lib/app-defaults/XTerm
[daily use:]
xterm -name aplus -e a+
How you proceed depends much on whether you have just a personal
system or a multi-user setup.
Hope this helps to get you started.
Martin Neitzel
If you think, all this is just too complicated: switch to straight-ascii
J. Alas, JSoftware has been neglecting the simple console interface
for years, ensuring that while you have access to all characters you
need, you cannot view script documentation or do all the online tutorials,
which at times even contain reference documentation. At the same
time, the GUI interfaces become more and more complex and let you run
into installation problems just like the ones above. Isn't it a pity.
Martin Neitzel
> Is /usr/share/fonts/X11/misc/Kaplcour-14.pcf.gz there?
> Does "xset q" list that directory in your font path?
> And finally:
> Does "xfd -fn Kapl" show you the APL font?
The last line is erroneous: there is no font called "Kapl".
Instead, use
xfd -fn kaplscreen
to check your font installation.
FWIW, I have a personal fontserver supplying me with non-standard
fonts. For APL, it currently serves the A+ and APLX fonts.
This makes it MUCH easier to run those APLs on whichever X11 display
I am sitting, including my OSX MacMini at home, because no local
font installations are required.
If you want to make use of this font server, too, you are welcome.
Just drop me a note and I'll arrange access through the firewall
for you.
Martin Neitzel
Chris Jones
> Chris Jones <cjns...@optimum.net> wrote:
>>I guess the subject sums it up.
Martin,
Thanks a bunch for this excellent mini-tutorial. Hopefully with the
above title, other potential users will find this thread via their
favorite search engine!
--- here removed excellent setup information - see previous post ---
It turns out I had three problems:
1. I had specified ‘XTerm*eightBitInput: false’ in my X resources
2. my locale is set to UTF-8
3. the xfonts-kapl package in debian ‘lenny’ does not play well with
fontconfig.
> For example, in my environment I use a centralized office server in
> our server room (running the Debian with Aplus), but on my desk, my
> diskless PC just runs a local X11 server, serving as the I/O frontend
> for all applications. The fonts needs to be available *to my local X11
> server*, and this needs some additional setup.
[..]
> The packages include an XTerm application defaults file taking care
> of all this. Unfortunately, it is a bit hidden in the aplus-fsf
> distribution and just in compressed form:
>
> /usr/share/doc/aplus-fsf-doc/app-defaults/XTerm.gz
As soon as I looked at this file with the ‘less’ pager, I realized that
one of the problems was my locale: most of the aplus non-alpha symbols
are in the invalid UTF-8 [0x80-0xff] range.
I switched the laptop's locale back to latin1, and rather brutally :-)
ran an ‘xrdb /tmp/XTerm’ on the gunzipped file. Then I started an xterm
with one of the kapl fonts and sure enough, I was able to enter all the
aplus arrows, Greek letters, mathematical symbols, etc. with the help of
my keyboard Alt keys.
> The tricky part now is that there are serveral ways to make an xterm
> actually use these definitions. What is best for you is highly
> dependent on your local circumstances.
> One fail-safe way to use it:
>
> [once only:]
> mkdir -p ~/lib/aplus
> zcat /usr/share/doc/aplus-fsf-doc/app-defaults/XTerm.gz > ~/lib/aplus/XTerm
>
> [daily use:]
> env XAPPLRESDIR=$HOME/lib/aplus xterm -e a+
That's a very useful trick I was not aware of.
> I for one already have my own ~/lib/app-defaults/XTerm in place, with
> same settings I wouldn't want to miss for a+ programming, either.
>
> I opted to incude the resources into my standard personalized XTerm
> file, but with the "ressource class" specification changed into
> a "ressource name" specification, so I can use them easily for running
> a+. Here goes:
>
> [once only:]
> zcat /usr/share/doc/aplus-fsf-doc/app-defaults/XTerm.gz |
> sed s/XTerm/aplus/ >> ~/lib/app-defaults/XTerm
>
> [daily use:]
> xterm -name aplus -e a+
That's even better!
>
> How you proceed depends much on whether you have just a personal
> system or a multi-user setup.
Just my home machine, so I really only have to worry about making as
seamless a possible for my own use.
> Hope this helps to get you started.
Oh, yes it did!
> If you think, all this is just too complicated: switch to
> straight-ascii J.
[..]
I don't really see this as complicated. :-)
I was ‘almost there’ but what did the trick was your saying something
about ‘complicated setups’ or something to that effect: that's where
I remembered I always disable the eighth bit so I can use ‘Alt’ for
various bash time savers (like Alt+. to retrieve the last word of the
previous command, one of my favorites). And of course seeing the
obviously 8-bit encoding, some form of extended ASCII specific to aplus,
I guess in the XTerm.gz file.
Now obviously, my next problem is to figure out a painless way of
running the xterm+APL interpreter in the correct locale, which I guess
I could do by writing a little wrapper script that sets shell
environment variable before invoking bash.
Or is there any way aplus could run in a UTF-8 locale?
Even though at first glance, APL and friends appear to be more useful
for number-crunching than string/text processing, it would look as if
‘aplus’ at least does not support unicode?
As to my problem with the KAPL fonts, I switched to a debian ‘squeeze’
install, and lo & behold, fontconfig picked it up and after switching
the ‘character set’ in seamonkey to ISO8859-1 instead of UTF-8, I was
able to display the aplus arrows and other symbols correctly. I had
looked for a possible bug with these fonts in debian distros, but I had
not found anything. Since debian ‘lenny’ will be replace by ‘squeeze’
next spring, I'm not sure I will bother sending them a bug report.
In any case, thanks to all your help, I now have a fully functional
‘aplus’ environment. It just needs a bit of tweaking to make it more
user-friendly.
cj
rustom
Hi Chris.
Ive hacked up something that works (somewhat) under gnu-emacs in
debian.
Its a small addition to Markus Triska's apl.el from
http://stud4.tuwien.ac.at/~e0225855/unicapl/apl.el
which makes it possible to run apl under emacs
If you are interested I can pass it on.
Rusi
Chris Jones
Hey Rusi,
Thanks for your comments.
Unfortunately, I do not use emacs and adding it to the A+/APL learning
curve would surely spell disaster :-)
On the other hand, it could be worth passing on your addition, in the
event other folks who bump into this discussion turn out to be emacs
users as well and might find it useful?
As to entering APL symbols, what I initially had in mind was creating an
‘apl’ variant of the XKB ‘us’ keyboard that would map the unicode values
to Mod3+Key combinations, using the keyboard layout in the A+ manual to
make sure they are in their usual locations.
It would then just be a simple matter of switching the keyboard to this
layout variant via the setxkbmap command, something that can be mapped
to a keyboard toggle for convenience sake.
Naturally, this would mean that any unicode fixed font with the required
glyphs could be used in lieu of the rather limiting KAPL: in other
words, the user could fire up the A+ interpreter in any xterm that he
happens to be currently running rather than use a different version
specifically configured for A+.
Unfortunately, as far as I understand it, this would also either require
a version of A+ that ‘speaks’ unicode (presumably the UTF-8 encoding
thereof), or implementing some kind of filter to translate aplus's input
from UTF-8 to the encoding that aplus expects and its output back to
UTF-8.
I guess that a quick and dirty approach would be to concoct a short
script (bash..? python....?) that translates the user input from unicode
to the A+ encoding, invoke aplus and translate A+'s output back to
unicode.
I shall have to take a closer look at the documentation, and see if
there is such a thing as a standard ‘official’ APL encoding, because if
there is, the transcoding might end up being be a simple matter of
invoking the ‘inconv’ utility.
Doesn't sound like yet another high mountain to climb, but since I know
nothing of A+, I suspect there may be a bit more to it than that...
What do you think?
cj
Martin Neitzel
CJ> from UTF-8 to the encoding that aplus expects and its output back to
CJ> UTF-8.
luit(1) does that.
Martin
rustom
> On Mon, 27 Dec 2010 10:41:47 -0800 (PST), rustom <rustompm...@gmail.com> wrote:
> > On Dec 13, 5:59 am, Chris Jones <cjns1...@optimum.net> wrote:
> >> I guess the subject sums it up.
>
> >> I downloaded the aplus-fsf packages on debian linux and started the
> >> interpreter, from a shell prompt in an xterm but now I am stuck.
>
> >> I guess a need to install an APL font such as the Kapl family, but then
> >> what would be the preferred mechanism to enter the APL symbols?
>
> >> Thanks.
>
> > Hi Chris.
> > Ive hacked up something that works (somewhat) under gnu-emacs in
> > debian.
>
> > Its a small addition to Markus Triska's apl.el from
> >http://stud4.tuwien.ac.at/~e0225855/unicapl/apl.el
> > which makes it possible to run apl under emacs
>
> > If you are interested I can pass it on.
>
> Hey Rusi,
>
> Thanks for your comments.
>
> Unfortunately, I do not use emacs and adding it to the A+/APL learning
> curve would surely spell disaster :-)
Yes, emacs is a pleasure to use and a bitch to set up.
I started using it (instead of vi) because it has (had?) nice
facilities for
intepreters running under it -- python, haskell, lisp etc.
>
> On the other hand, it could be worth passing on your addition, in the
> event other folks who bump into this discussion turn out to be emacs
> users as well and might find it useful?
My hacks are really not stable/fault-free enough for that, viz.
sharing in a general way
>
> As to entering APL symbols, what I initially had in mind was creating an
> ‘apl’ variant of the XKB ‘us’ keyboard that would map the unicode values
> to Mod3+Key combinations, using the keyboard layout in the A+ manual to
> make sure they are in their usual locations.
>
> It would then just be a simple matter of switching the keyboard to this
> layout variant via the setxkbmap command, something that can be mapped
> to a keyboard toggle for convenience sake.
>
> Naturally, this would mean that any unicode fixed font with the required
> glyphs could be used in lieu of the rather limiting KAPL: in other
> words, the user could fire up the A+ interpreter in any xterm that he
> happens to be currently running rather than use a different version
> specifically configured for A+.
>
> Unfortunately, as far as I understand it, this would also either require
> a version of A+ that ‘speaks’ unicode (presumably the UTF-8 encoding
> thereof), or implementing some kind of filter to translate aplus's input
> from UTF-8 to the encoding that aplus expects and its output back to
> UTF-8.
>
> I guess that a quick and dirty approach would be to concoct a short
> script (bash..? python....?) that translates the user input from unicode
> to the A+ encoding, invoke aplus and translate A+'s output back to
> unicode.
My elisp additions to apl.el basically does that
>
> I shall have to take a closer look at the documentation, and see if
> there is such a thing as a standard ‘official’ APL encoding, because if
> there is, the transcoding might end up being be a simple matter of
> invoking the ‘inconv’ utility.
Well the aplus family of debian packages could be described as
"needin' some love"
- shell support bundled but buried deep
- xemacs poorly documented
- gnuemacs not working
etc
Chris Jones
> > some kind of filter to translate aplus's input from UTF-8 to the
> > encoding that aplus expects and its output back to UTF-8.
>
> luit(1) does that.
Looks like an inexpensive (and already-tested - ie. reliable) way to
achieve something similar to what I had in mind. But what encoding would
you pass to luit?
cj
Chris Jones
[..]
> My hacks are really not stable/fault-free enough for that, viz.
> sharing in a general way
Same here ;-)
[..]
>> I guess that a quick and dirty approach would be to concoct a short
>> script (bash..? python....?) that translates the user input from unicode
>> to the A+ encoding, invoke aplus and translate A+'s output back to
>> unicode.
>
> My elisp additions to apl.el basically does that
Good news... so it sounds like I'm on the right track after all. I don't
know any lisp, unfortunately.. so I will have to reinvent that wheel..
see what happens.. :-)
>> I shall have to take a closer look at the documentation, and see if
>> there is such a thing as a standard ‘official’ APL encoding, because
>> if there is, the transcoding might end up being a simple matter of
>> invoking the ‘inconv’ utility.
>
> Well the aplus family of debian packages could be described as
> "needin' some love"
> - shell support bundled but buried deep
> - xemacs poorly documented
> - gnuemacs not working
> etc
Maybe not just limited to debian, unfortunately.. I could be wrong about
that, but from the start I had a vague yet distinct feeling that the
Unix world in general was somewhat prejudiced against APL and its
descendants.
Thanks for your help.
cj
rustom
> Maybe not just limited to debian, unfortunately.. I could be wrong about
> that, but from the start I had a vague yet distinct feeling that the
> Unix world in general was somewhat prejudiced against APL and its
> descendants.
>
I guess its both ways -- the APL community does not consider unix/
linux important to work under.
The loss may be for both sides but which is more is anybody's guess...
Bakul Shah
>
> Maybe not just limited to debian, unfortunately.. I could be wrong about
> that, but from the start I had a vague yet distinct feeling that the
> Unix world in general was somewhat prejudiced against APL and its
> descendants.
Remember that a) APL grew under IBM and b) Unix for a very long time
didn't have a graphics display of any sort and the typical cheap CRT
one used didn't have loadable fonts. People used what came with Unix
(which was C, awk, sed, sh). Later people added languages they were
interested in or researching but it was mostly all volunteer effort.
You could play with these languages and if you liked them enough, you
could use them for free. Once you wrote a few programs others liked,
the language took hold. This never seemed to happen with APL. I think
the character set issue was a huge impediment. And the cost. You
don't tend toplay with something if it requires too much effort to
get started or upfront investment. So I think it is just the way
things evolved than any prejudice.
Morten Kromberg
> On Dec 29, 10:39 am, Chris Jones <cjns1...@optimum.net> wrote:
>
> > Maybe not just limited to debian, unfortunately.. I could be wrong about
> > that, but from the start I had a vague yet distinct feeling that the
> > Unix world in general was somewhat prejudiced against APL and its
> > descendants.
> I guess its both ways -- the APL community does not consider unix/
> linux important to work under.
> The loss may be for both sides but which is more is anybody's guess...
Dyalog APL was born under Unix in 1983, and still has a very
significant Unix user base, with a number of very large applications
running under AIX and Linux (Solaris seems to be fading). However, APL
users do tend to focus on ease of use and availability of productivity
tools. More and more, our Unix customers are moving towards the use of
Windows as a development environment, even for the systems that run on
Unix servers.
Often, APL was chosen precisely because it allows you to write
applications without "studying the computer". Many APLers do not have
software engineering as their primary skill set. Although Unix systems
are improving, they do still seem to require rather more "systems
programming" ability than Windows, and are weak on "integration tools"
like those provided by Microsoft technologies like COM and in
particular Microsoft.Net. Unix systems seem to always have had too
many competing "eco-systems", making life very hard for the less
technically savvy developer.
I think the use under Linux is going to grow in the years to come -
but Windows is likely to remain the most important platform for APL
applications for some time to come.
Morten Kromberg
Technical Director
Dyalog Ltd.
rustom
Techncally: Today's world is very different from that even a few years
ago: Everyone uses bit-mapped (X)Windows and OSes are unicode-aware.
This means that the large hardware investment needed for APL is now
unnecessary. In short: Everyone can use Apl today
Ideologically: The linux world subsists on 'Free/OpenSource'
software. Much of this may be the empty antics of fanboys
(cheerleader-girls?) -- but thats the culture if Apl wants to be part
of it.
Aplus already is available for linux. If the less-than-satisfactory
state of the packages is cleaned up there could be a larger adoption
in the linux world. One may then assume that a small percentage of
these adoperts will be ready to pay for and use more professional
products like Dyalog...
Chris Jones
[..]
>> I guess its both ways -- the APL community does not consider unix/
>> linux important to work under.
>> The loss may be for both sides but which is more is anybody's guess...
>
> Dyalog APL was born under Unix in 1983, and still has a very
> significant Unix user base, with a number of very large applications
> running under AIX and Linux (Solaris seems to be fading). However, APL
> users do tend to focus on ease of use and availability of productivity
> tools. More and more, our Unix customers are moving towards the use of
> Windows as a development environment, even for the systems that run on
> Unix servers.
>
> Often, APL was chosen precisely because it allows you to write
> applications without "studying the computer". Many APLers do not have
> software engineering as their primary skill set. Although Unix systems
> are improving, they do still seem to require rather more "systems
> programming" ability than Windows, and are weak on "integration tools"
> like those provided by Microsoft technologies like COM and in
> particular Microsoft.Net. Unix systems seem to always have had too
> many competing "eco-systems", making life very hard for the less
> technically savvy developer.
Interesting remarks, thanks.
> I think the use under Linux is going to grow in the years to come -
> but Windows is likely to remain the most important platform for APL
> applications for some time to come.
Well, it would be a significant step forward if linux provided an APL
environment that runs out of the box. With the current state of affairs,
I'm sure 99% of those that might take an interest in APL would not even
bother taking a second glance.
In any case, my compliments on the remarkable tutorial available in PDF
format at the Dyalog web site.
More's the pity that Dyalog appears to be rather Windows-centric, since
your offering in general makes A+ look rather.. antiquated.
cj
rustom
> More's the pity that Dyalog appears to be rather Windows-centric, since
> your offering in general makes A+ look rather.. antiquated.
Thats normal, I would say. In any area if someone is the leader the
others can at most be runners-up.
If Dyalog is the leader its hardly expected that APlus be as good.
Brings me to the main point:
> Well, it would be a significant step forward if linux provided an APL environment that runs out of the box. With
> the current state of affairs, I'm sure 99% of those that might take an interest in APL would not even bother
> taking a second glance.
As "22 Laws of Branding" eloquently states:
A leading brand should promote the category not the brand.
Why?
Microsoft windows does not lose to but benefits from mono.
Likewise MSoffice to openoffice
Ultimately the best that runners-up can do is to point to the winner.
So if the leader-brand supports the category the benefits it reaps
from increased market interest
in the category outweighs the market share ceded to competition.
Or: Dyalog would certainly do us (and itself?) a favor by supporting
Aplus.
Some finer points:
Morten Kromberg wrote:
> Often, APL was chosen precisely because it allows you to write
> applications without "studying the computer". Many APLers do not
> have software engineering as their primary skill set. Although
> Unix systems are improving, they do still seem to require rather
> more "systems programming" ability than Windows, and are weak on
> "integration tools" like those provided by Microsoft technologies
> like COM and in particular Microsoft.Net. Unix systems seem to
> always have had too many competing "eco-systems", making life very
> hard for the less technically savvy developer.
Yes and no.
Yes in the past. But steadily decreasing with time.
What are the factors making for the success of ubuntu?
1. A geeky debian underbelly
2. Marketed with attractive freebies -- anyone can order a free CD
(until the success
became too runaway for Canonical to keep it up)
3. Windows-y eye-candy and install-friendliness
So: Success of ubuntu implies that the non-geek, non-computer-
scientist burgeoning market is waiting to be tapped.
In short:
The factors keeping Apl from being stuck in a very slim niche market
are no longer true.
Happy new Year everyone! May the coming year and decade bring us more
APL!
Morten Kromberg
> As "22 Laws of Branding" eloquently states:
> A leading brand should promote the category not the brand.
I agree with this and Dyalog is keen to support all uses of APL, and
also similar languages like Aplus, J and K. Have you looked at
Nars2000? We are also hoping to be able to build bridges to the
broader "Agile" and "Functional" communities; people using languages
like Python and F#.
> Or: Dyalog would certainly do us (and itself?) a favor by supporting
> Aplus.
To be perfectly honest, I don't know enough about Aplus to know
whether it would be worthy of support at this time (should we not be
pushing Nars2000 instead, for example)? ... Or what it would take to
support it.
One thing that Dyalog does intend to do in the next 12 months is to
put the font and keyboard technologies that we are developing for our
own product in the public domain. These should allow any Unicode-based
environment to display and edit APL with ease.
> Morten Kromberg wrote:
> > Often, APL was chosen precisely because it allows you to write
> > applications without "studying the computer". Many APLers do not
> > have software engineering as their primary skill set. Although
> > Unix systems are improving, they do still seem to require rather
> > more "systems programming" ability than Windows, and are weak on
> > "integration tools" like those provided by Microsoft technologies
> > like COM and in particular Microsoft.Net. Unix systems seem to
> > always have had too many competing "eco-systems", making life very
> > hard for the less technically savvy developer.
>
> Yes and no.
> Yes in the past. But steadily decreasing with time.
I agree with this; as I said in my previous posting, I believe that
the use of our product will grow on Linux. Our approach may not earn
us much applause from dyed-in-the-wool Linux geeks (certainly not
those who believe that Microsoft is evil): We are working on a new
development environment based on Silverlight and Moonlight, which will
allow us to provide the same "user experience" on all platforms where
our product is available. We are also exploring a number of ways to
allow cross-platform application development based on the same
infrastructure components.
(for a sneak preview of this project, see the recording of the
presentation titled "Taking APL for a Ride" by John Daintree at
http://video.dyalog.com/APL2010/)
When we have implemented these pieces, I believe that we will be able
to provide developers and users with a very similar experience on
Linux and Windows (and MacOS, Android, etc etc).
> In short:
> The factors keeping APL from being stuck in a very slim niche market
> are no longer true.
I totally agree with this - the future of APL and similar languages
looks bright! I think it will still be something of a niche market,
since APL favours people who think they have original ideas and favour
agility over the avoidance of risk by beating the trodden path. Most
people, including software developers, still prefer the latter. But
the niche should get a lot fatter if we can figure out how to play our
cards right.
rustom
> On Jan 1, 7:33 am, rustom <rustompm...@gmail.com> wrote:
>
> > As "22 Laws of Branding" eloquently states:
> > A leading brand should promote the category not the brand.
>
> I agree with this and Dyalog is keen to support all uses of APL, and
> also similar languages like Aplus, J and K. Have you looked at
> Nars2000?
myself who used and taught STSC (if I remember right) Apl 20 years ago
this may be ok. But if it is a question of infecting and converting
the younger generation this is a no-no.
But even technologically wine can be a headache to get running..
> We are also hoping to be able to build bridges to the broader "Agile" and "Functional" communities; people
> using languages like Python and F#.
Glad to hear that. I am working along similar lines
>
> > Or: Dyalog would certainly do us (and itself?) a favor by supporting
> > Aplus.
>
> To be perfectly honest, I don't know enough about Aplus to know
> whether it would be worthy of support at this time (should we not be
> pushing Nars2000 instead, for example)?
> ... Or what it would take to support it.
Let me speak for Aplus:
Aplus is directly available with linux (at least debian and ubuntu)
But it does not work easily. There are broadly 3 ways it could 'work'
1. The docs only talk of running it under xemacs but I could not get
that to work (had done so 5-6 years ago)
2. This thread talks of running it directly under the shell. Thats a
bit primitive but still better than nothing but that too seems to need
non-trivial acrobatics (start of this thread)
3. Finally there is gnuemacs. Markus Triska has a mode to type Apl
programs (but no execution)
Ive added some elisp to make it run as well. Obviously incomplete and
probably buggy.
If other interested-in-linux parties could test drive this I could
clean it up the code and then address the question of cleaning up the
Aplus related packages that come ready in debian/ubuntu.
>
> One thing that Dyalog does intend to do in the next 12 months is to
> put the font and keyboard technologies that we are developing for our
> own product in the public domain. These should allow any Unicode-based
> environment to display and edit APL with ease.
Very good. But as for Aplus it uses a latin-ish encoding (0-127 ASCII,
128-255 Apl )
Very unfashionable today but then APlus was written before unicode
(became standard)
>
> > Morten Kromberg wrote:
> > > Often, APL was chosen precisely because it allows you to write
> > > applications without "studying the computer". Many APLers do not
> > > have software engineering as their primary skill set. Although
> > > Unix systems are improving, they do still seem to require rather
> > > more "systems programming" ability than Windows, and are weak on
> > > "integration tools" like those provided by Microsoft technologies
> > > like COM and in particular Microsoft.Net. Unix systems seem to
> > > always have had too many competing "eco-systems", making life very
> > > hard for the less technically savvy developer.
>
> > Yes and no.
> > Yes in the past. But steadily decreasing with time.
>
> I agree with this; as I said in my previous posting, I believe that
> the use of our product will grow on Linux. Our approach may not earn
> us much applause from dyed-in-the-wool Linux geeks (certainly not
> those who believe that Microsoft is evil): We are working on a new
> development environment based on Silverlight and Moonlight, which will
> allow us to provide the same "user experience" on all platforms where
> our product is available. We are also exploring a number of ways to
> allow cross-platform application development based on the same
> infrastructure components.
>
> (for a sneak preview of this project, see the recording of the
> presentation titled "Taking APL for a Ride" by John Daintree athttp://video.dyalog.com/APL2010/)
>
> When we have implemented these pieces, I believe that we will be able
> to provide developers and users with a very similar experience on
> Linux and Windows (and MacOS, Android, etc etc).
>
> > In short:
> > The factors keeping APL from being stuck in a very slim niche market
> > are no longer true.
>
> I totally agree with this - the future of APL and similar languages
> looks bright! I think it will still be something of a niche market,
> since APL favours people who think they have original ideas and favour
> agility over the avoidance of risk by beating the trodden path. Most
> people, including software developers, still prefer the latter. But
> the niche should get a lot fatter if we can figure out how to play our
> cards right.
Great!
But please note the long tail http://en.wikipedia.org/wiki/Long_Tail
Ibeam2000
> significant Unix user base, with a number of very large applications
> running under AIX and Linux
Back in the mid 1980s, Unix systems were rather high-end. I still
have fond memories of APL68000, STSC APL*Plus/Unix, and SAX running on
small Unix timesharing machines and higher-end Apollo and Sun
workstations. Users were starting to come off timesharing, and for
medium sized applications which were too large for APL*Plus/PC, the
alternatives were an IBM 4381 mainframe with CMS and VSAPL (you could
lease one for about USD 8K per month) or a handful of minicomputers
(DEC Vax, Data General, etc.) or a large (usually 68000-based)
microcomputer. Bear in mind that a typical "small" timesharing
customer might spend $5-15K per month, leasing any of these
alternatives while consolidating and closing accounts with two or more
timesharing vendors yielded considerable savings.
> However, APL
> users do tend to focus on ease of use and availability of productivity
> tools. More and more, our Unix customers are moving towards the use of
> Windows as a development environment, even for the systems that run on
> Unix servers.
> Often, APL was chosen precisely because it allows you to write
> applications without "studying the computer". Many APLers do not have
> software engineering as their primary skill set. Although Unix systems
> are improving, they do still seem to require rather more "systems
> programming" ability than Windows, and are weak on "integration tools"
> like those provided by Microsoft technologies like COM and in
> particular Microsoft.Net. Unix systems seem to always have had too
> many competing "eco-systems", making life very hard for the less
> technically savvy developer.
There is a clash of various philosophies here which is gradually
working itself out. APL users typically have mainframe origins, and
the mainframe world was quite different from the usual computing world
of today. Amongst other things, as there was a lot more money
involved, writing software was a far more profitable proposition, far
more details were abstracted away, leaving, for its time, a high
productivity environment. This was even more true with APL. With the
rise of the PC, however, there emerged a sort of geek culture, one
which values knowledge of intricate details. I attended an OS/2
seminar in the late 1980s which among other things introduced the
"Presentation Manager" (i.e. Windows API) and later came to realize
that the real problem here was that a higher level of abstraction just
wasn't valued any more (what do you mean I have to learn some 500 API
calls to do the work of the 30 I used to know with GDDM?)
For me, it's very sad to look at Java development with something like
JSPX, then to compare it to ISPF scripting or whatever it was from IBM
for 3270 applications from 25 years ago. I think Microsoft did a
pretty good job in trying to keep the level of abstraction at least
going upwards.
APL users have come to expect nearly all of the mindless tedium to be
abstracted away, while the mindless tedium is the norm. I would not
call a comprehensive knowledge of Linux "software engineering", but
would suggest that there is a sort of generation gap, or perhaps
"abstraction gap" which defines the separation between Windows and
Linux users. One thing I have also come to realize is that a good
number of today's programmers have origins in web design, HTML, and so
on, which tends to give individuals a collective perspective (i.e.
culture) rather different than that of those who started with APL,
Fortran, mainframes, and so on. Microsoft has filled but not closed
this abstraction gap as well as it could, though I would think that
the flagship .Net language, C#, undoes some of the progress made with
COM, VB6, and ADO (not .Net) by catering to individuals and
institutions attracted to Java. I guess it's just good business.
Chris Jones
Thanks for your offer, but on current debian systems, shouldn't X fonts
be served by fontconfig? I have the /usr/share/fonts/X11/misc directory
right at the top of /etc/fonts/local.conf, and I do see the .ttf version
of the kapl font (KAPL.TTF) both when I do an fc-list and in the
seamonkey font selection dialog, but I don't see the bitmap fonts.
Odd, since other fixed bitmap fonts such as ‘terminus’ do show up
without any problems...
As to integrating A+ to my debian setup, I ran out of time and
eventually did the following:
1. ‘dpkg-reconfigure locales’ to gen' the en.US ISO8859-1 locale
2. created an 8-bit ‘apl’ keymap in /usr/share/X11/xkb/symbols
Now if I need an aplus-capable xterm, I just run this short script:
#!/bin/bash
setxkbmap apl
LC_ALL=en-US.ISO-8859-1 xterm -fn '-*-kapl-medium-*' &
This works very well in my context since my ‘apl’ keymap is compatible
with a plain US/ASCII keyboard, and I have set up mod3 to correspond to
my keyboard's windows keys rather than Alt or Control. As a result,
I can run GNU/screen on top of my xterm and switch between A+ sessions,
bash shells, the vim editor, or a text-mode web browser. And of course,
anything else I might be running in my X session is not affected in any
way.
I did the tutorials in /usr/share/doc/aplus-fsf-doc/tutorials, and my
keymap worked without a glitch: A+ recognized all the keycodes and
everything I typed was correctly echoed to the terminal.
Quick and dirty, of course, and I am not too happy with this solution,
but the difficulty was that I needed some knowledge of A+ to set up
a working environment, and I needed a working environment to acquire
some knowledge of A+ ...
So for the time being, and since everything is functional and there are
no side effects where the rest of my environment is concerned (and
I didn't have to change my working habits in any way), I guess I'll
stick with this ugly hack.
Once I'm a bit more fluent with A+, I'll see if I can come up with
a cleaner solution. Hopefully something more general, with a keymap that
uses the [U+2336-U+2395] range and lets me use any Unicode font that
features the required glyphs.
In any event, thanks much for helping me get started with this.
cj
phil chastney
>
> But please note the long tail http://en.wikipedia.org/wiki/Long_Tail
...which is similar to a point that was made (but ignored) before the
UK's railway passenger network was slashed
(in fairness, there were other factors to take into account, but these
were not made part of the public debate)
the terminology at that time was "feeder routes", i.e, routes which feed
passengers into the mainline services
once you've climbed into a car to drive to a mainline station, it
becomes difficult to justify parking the car, buying a train ticket, and
(possibly) arranging other transport the other end
/phil
Chris Jones
> On Jan 1, 7:33 am, rustom <rustompm...@gmail.com> wrote:
>> As "22 Laws of Branding" eloquently states:
>> A leading brand should promote the category not the brand.
>
> I agree with this and Dyalog is keen to support all uses of APL, and
> also similar languages like Aplus, J and K. Have you looked at
> Nars2000? We are also hoping to be able to build bridges to the
> broader "Agile" and "Functional" communities; people using languages
> like Python and F#.
>
>> Or: Dyalog would certainly do us (and itself?) a favor by supporting
>> Aplus.
>
> To be perfectly honest, I don't know enough about Aplus to know
> whether it would be worthy of support at this time (should we not be
> pushing Nars2000 instead, for example)? ... Or what it would take to
> support it.
Well A+ is native to the *nix world. Nars2000 apparently is not.
> One thing that Dyalog does intend to do in the next 12 months is to
> put the font and keyboard technologies that we are developing for our
> own product in the public domain. These should allow any Unicode-based
> environment to display and edit APL with ease.
Ah.. that's me :-)
>> Morten Kromberg wrote:
>> > Often, APL was chosen precisely because it allows you to write
>> > applications without "studying the computer".
.. which is probably why the average *nix geek regards it at best with
suspicion: I spent twenty years studying.. not really getting anywhere,
and now you are calling me an idiot.
>> > Many APLers do not have software engineering as their primary skill
>> > set.
Possibly perceived as yet another thing to worry about in terms of the
software professional's job security.
>> > Although Unix systems are improving, they do still seem to require
>> > rather more "systems programming" ability than Windows, and are
>> > weak on "integration tools" like those provided by Microsoft
>> > technologies like COM and in particular Microsoft.Net. Unix systems
>> > seem to always have had too many competing "eco-systems", making
>> > life very hard for the less technically savvy developer.
>> Yes and no. Yes in the past. But steadily decreasing with time.
> I agree with this; as I said in my previous posting, I believe that
> the use of our product will grow on Linux. Our approach may not earn
> us much applause from dyed-in-the-wool Linux geeks (certainly not
> those who believe that Microsoft is evil):
I believe Torvalds remarked.. no, not ‘evil’ .. just not very good at
writing operating systems.. something to that effect. Pleeease do not
get me started on this one... :-O
[..]
> I totally agree with this - the future of APL and similar languages
> looks bright! I think it will still be something of a niche market,
> since APL favours people who think they have original ideas and favour
> agility over the avoidance of risk by beating the trodden path. Most
> people, including software developers, still prefer the latter. But
> the niche should get a lot fatter if we can figure out how to play our
> cards right.
Deciding factors might be:
(1) the existence of a native state-of-the-art APL environement that
runs on GNU/Linux out of the box. From what I have experienced, A+ does
not quite fit the bill.. What I have seen of it felt more like something
out of a software museum and required quite a bit of hacking on my part
before I could even run the tutorials¹. A contradiction in terms given
APL's objectives.
(2) available at no cost. Otherwise, the user-base will be limited to
the very few proficient users of APL who for some reason need their
environment to run on GNU/Linux. I can't see anyone who is just curious
of the language (but all the same might fall in love and prove a major
contributor years ahead) forking out hundreds of dollars for a license.
And one-month trials don't cut it either: something more urgent turns
up.. then something else.. before you know it, you only have two days
left. Oh well..
(3) Open-source. Not only because the powers that be in the GNU/Linux
world would find it more palatable, but because once they fall in love,
our talented and ambitious young (wo)men will want to seriously hack the
beast.. If they cannot they'll be very frustrated and quickly move on to
something else.
So maybe what's needed where APL is concerned is a cultural revolution.
cj
¹ Not dissing A+, not by any means.. I love it... but then I'm probably
not typical.
rustom
> On Sat, 1 Jan 2011 08:25:10 -0800 (PST), Morten Kromberg <mk...@dyalog.com> wrote:
> > I totally agree with this - the future of APL and similar languages
> > looks bright! I think it will still be something of a niche market,
> > since APL favours people who think they have original ideas and favour
> > agility over the avoidance of risk by beating the trodden path. Most
> > people, including software developers, still prefer the latter. But
> > the niche should get a lot fatter if we can figure out how to play our
> > cards right.
>
> Deciding factors might be:
>
> (1) the existence of a native state-of-the-art APL environement that
> runs on GNU/Linux out of the box. From what I have experienced, A+ does
> not quite fit the bill.. What I have seen of it felt more like something
> out of a software museum and required quite a bit of hacking on my part
> before I could even run the tutorials¹. A contradiction in terms given
> APL's objectives.
Its important to distinguish two things here:
i. out of a software museum
ii. requiring quite a bit of hacking to run even the tutorials
For A+ (ii) is certainly true and therefore makes it look like (i) is
true
Chris Jones
Yes.. and so far, it looks like I've spent something like 90% of my time
and effort on getting my setup to work and about 10% on learning A+.
Should be the other way round, don't you think?
:-)
cj
rustom
> On Mon, 3 Jan 2011 21:36:05 -0800 (PST), rustom <rustompm...@gmail.com> wrote:
> > Its important to distinguish two things here:
> > i. out of a software museum
> > ii. requiring quite a bit of hacking to run even the tutorials
>
> > For A+ (ii) is certainly true and therefore makes it look like (i) is
> > true
>
> Yes.. and so far, it looks like I've spent something like 90% of my time
> and effort on getting my setup to work and about 10% on learning A+.
>
> Should be the other way round, don't you think?
>
> :-)
>
> cj
Objectively speaking I guess this means there is
(iii) Steep learning curve
in addition to (i) and (ii) above
Subjectively speaking I guess we are both on the down side of the
learning curve so we easily cant distinguish :-)
I can only re-state my earlier suggestion: emacs is cozier as a
development environment than the shell...
Chris Jones
> On Jan 5, 12:39 am, Chris Jones <cjns1...@optimum.net> wrote:
[..]
>> Yes.. and so far, it looks like I've spent something like 90% of my
>> time and effort on getting my setup to work and about 10% on learning
>> A+.
>>
>> Should be the other way round, don't you think?
>>
>> :-)
>>
>> cj
>
> Objectively speaking I guess this means there is (iii) Steep learning
> curve in addition to (i) and (ii) above
Indeed, but what bugs me at this point is that I am spending most of my
time ascending the ‘A+ in a shell’ curve and next to none on APL/A+
proper. And it's not even as if all my efforts will benefit anyone
either...
> Subjectively speaking I guess we are both on the down side of the
> learning curve so we easily cant distinguish :-)
Well, I have run into a bit of an issue with screen managemnt: For some
reason, my keyboard mappings of non-ASCII characters - ie. anything in
the 0x80-0xff range - are not working when I try to enter them in input
fields: stuff like Mod3+i (iota), Mod3+r (rho), Mod3+o (circle). The
cursor stays put as if nothing ever gets transmitted to the
interperter.. and naturally, the corresponding A+ variable only has the
7-bit stuff.. e.g. if I enter ‘abcÙabcMod3+r (rho), Mod3+o (circle). The
cursor stays put as if nothing ever gets transmitted to the
interperter.. and naturally, the corresponding A+ variable only has the
7-bit stuff.. e.g. if I enter ‘abcÙabc’ where the fourth character is
a non-ASCII A+ symbol.. (in a unicode locale, I see a capital U with
a grave accent), the input field will only contain ‘abcabc’, and the
associated A+ variable likewise. Now, I'm the only one around with my
odd setup.. so I'm not expecting anyone to help me fix this.. that's up
to me.. but I may spend a day, a week.. who knows.. fixing this problem..
And while I'm doing this, I just have to put the ‘s’ and the ‘graphs’
tutorials on the back burner. :-(
> I can only re-state my earlier suggestion: emacs is cozier as
> a development environment than the shell...
The more I look at it, the more I'm beginning to think that would be
a more sensible course of action.. on the other hand, while I know xterm
and the shell pretty well, I have zero familiarity with emacs.. and to
make it even more of a challenge, there's all the elisp stuff that comes
with it.. Hm.. I'll give emacs a try over the weekend.. see first-hand
what I would be getting into.
cj
’I tried to use EMACS and I liked it. The problem was I spent all my
time programming it because it was improving so fast that my programs
kept breaking. I got tired of maintaining my macros so I guess I'm
looking forward to an editor I can learn and then forget about.’
Bill Joy, Unix Review (August 1984)
Chris Jones
> On Tue, 4 Jan 2011 20:46:20 -0800 (PST), rustom <rusto...@gmail.com> wrote:
>> On Jan 5, 12:39 am, Chris Jones <cjns1...@optimum.net> wrote:
>
> [..]
Sorry.
The nonsensical..
> ... and naturally, the corresponding A+ variable only has the 7-bit
> stuff.. e.g. if I enter ‘abcÙabcMod3+r (rho), Mod3+o (circle)...
... should read:
> ... and naturally, the corresponding A+ variable only has the 7-bit
> stuff.. e.g. if I enter ‘abcÙabc’...
cj
rustom
> ’I tried to use EMACS and I liked it. The problem was I spent all my
> time programming it because it was improving so fast that my programs
> kept breaking. I got tired of maintaining my macros so I guess I'm
> looking forward to an editor I can learn and then forget about.’
>
> Bill Joy, Unix Review (August 1984)
Uncomfortably true!! Just dont use emacs as an editor but as an
interim hacking environment.
>
> > I can only re-state my earlier suggestion: emacs is cozier as
> > a development environment than the shell...
>
> The more I look at it, the more I'm beginning to think that would be
> a more sensible course of action.. on the other hand, while I know xterm
> and the shell pretty well, I have zero familiarity with emacs.. and to
> make it even more of a challenge, there's all the elisp stuff that comes
> with it.. Hm.. I'll give emacs a try over the weekend.. see first-hand
> what I would be getting into.
>
> cj
>
Ive put up some stuff at http://www.emacswiki.org/emacs/AplInDebian
Tell me if you need any other help
Chris Jones
[...]
>> > I can only re-state my earlier suggestion: emacs is cozier as
>> > a development environment than the shell...
Depends a lot on one's fluency with emacs vs. the shell. I installed it
and after about an hour, I realized I was not getting anywhere¹ and I'd
need to pick up a tutorial and use it for at least a couple of months
before I would be able to forget about it and focus on A+.
> Ive put up some stuff at http://www.emacswiki.org/emacs/AplInDebian
> Tell me if you need any other help
I found why the Mod3 symbols were not being recognized: the cause
appears to be a bug of sorts in s.+. My 'apl' keymap specifies the
Windows keys as Mod3.. It turns out that s.+ does not take any notice
and insists I use the Alt keys instead.. as if this was hard-coded
somewhere.
Now that I have figured that out, all I have to do is use the Windows
keys when typing in the A+ ‘shell’ - i.e. the session that runs in my
XTerm.. and the Alt keys when I'm typing in the s.+ widgets..
I can live with that for now.. although it looks like the solution that
Mr. Neitzel advocates with a specialized instance of XTerm and A+
mappings defined in a resource file may in the end prove more useable.
I also noted on the emacswiki.org page that one Markus Triska did in...
elisp is it..? pretty much what I initially thought I would do, down to
the GNU/unifont unicode font I had in mind :-)
So far, everything I threw at A+ works just fine under GNU/screen
running on top of a 256 color XTerm... And as a result, I can run all my
other stuff side by side with my A+ session.. Including Vim, which
should come in handy when I'm ready to start coding.
The only limitations I have run into are stuff like not being able to
retrieve statements that I previously typed in the A+ interactive
‘shell’ so I can edit them or fix typos (up arrow does not work as I had
hoped).. and not being able to change the PATH where A+ looks for the
scripts or functions I'm trying to load..
As far as I can tell, folks who are comfortable working with a shell and
know no emacs at all are better off using an XTerm-based environment as
their A+ playground. Maybe this should be advertised somewhere in the
event future potential users could benefit by it.. But then, this would
likely not belong in the emacswiki.org page and the aplusdev.org site
apparently does not feature a wiki..
So I'm not sure where I could document it.
Thanks much for your help and encouragements.
cj
¹ I was not even able to figure out how to open a ‘scratch’ buffer and
once I did manage to create one after about twenty minutes of googling
and fumbling (not even sure how I did it..), I was never able to get
my Fx keys (F2, F4, F5..) to do anything useful.. :-)
Chris Jones
>> Dyalog APL was born under Unix in 1983, and still has a very
>> significant Unix user base, with a number of very large applications
>> running under AIX and Linux
> Back in the mid 1980s, Unix systems were rather high-end. I still
> have fond memories of APL68000, STSC APL*Plus/Unix, and SAX running on
> small Unix timesharing machines and higher-end Apollo and Sun
> workstations. Users were starting to come off timesharing, and for
> medium sized applications which were too large for APL*Plus/PC, the
> alternatives were an IBM 4381 mainframe with CMS and VSAPL (you could
> lease one for about USD 8K per month)
You probably could buy one in working order for a couple of grand
nowadays.. Depending on your location, S&H could add up to more than the
price of the machine.
> or a handful of minicomputers (DEC Vax, Data General, etc.) or a large
> (usually 68000-based) microcomputer. Bear in mind that a typical
> "small" timesharing customer might spend $5-15K per month, leasing any
> of these alternatives while consolidating and closing accounts with
> two or more timesharing vendors yielded considerable savings.
>> However, APL users do tend to focus on ease of use and availability
>> of productivity tools. More and more, our Unix customers are moving
>> towards the use of Windows as a development environment, even for the
>> systems that run on Unix servers.
>
>> Often, APL was chosen precisely because it allows you to write
>> applications without "studying the computer". Many APLers do not have
>> software engineering as their primary skill set. Although Unix
>> systems are improving, they do still seem to require rather more
>> "systems programming" ability than Windows, and are weak on
>> "integration tools" like those provided by Microsoft technologies
>> like COM and in particular Microsoft.Net. Unix systems seem to always
>> have had too many competing "eco-systems", making life very hard for
>> the less technically savvy developer.
That's the rational side. Though never thus voiced, we're not paying you
to play with computers.. wear a suit, get a haircut.. I have a feeling
the deciding factor is often more along those lines.
> There is a clash of various philosophies here which is gradually
> working itself out. APL users typically have mainframe origins, and
> the mainframe world was quite different from the usual computing world
> of today. Amongst other things, as there was a lot more money
> involved, writing software was a far more profitable proposition, far
> more details were abstracted away, leaving, for its time, a high
> productivity environment. This was even more true with APL. With the
> rise of the PC, however, there emerged a sort of geek culture, one
> which values knowledge of intricate details.
Absolutely, but it's also a lot about a ‘do your own thing’ kind of
approach.. not a philosophy that easily fits in with the corporate scene.
> I attended an OS/2 seminar in the late 1980s which among other things
> introduced the "Presentation Manager" (i.e. Windows API) and later
> came to realize that the real problem here was that a higher level of
> abstraction just wasn't valued any more (what do you mean I have to
> learn some 500 API calls to do the work of the 30 I used to know with
> GDDM?)
> For me, it's very sad to look at Java development with something like
> JSPX, then to compare it to ISPF scripting or whatever it was from IBM
> for 3270 applications from 25 years ago. I think Microsoft did
> a pretty good job in trying to keep the level of abstraction at least
> going upwards.
>
> APL users have come to expect nearly all of the mindless tedium to be
> abstracted away, while the mindless tedium is the norm. I would not
> call a comprehensive knowledge of Linux "software engineering",
Linux or other.. not ‘software engineering’ per se.. but a sound basis
thereof. Having no knowledge of what goes on behind the scenes can be
costly.
> but would suggest that there is a sort of generation gap, or perhaps
> "abstraction gap" which defines the separation between Windows and
> Linux users. One thing I have also come to realize is that a good
> number of today's programmers have origins in web design, HTML, and so
> on, which tends to give individuals a collective perspective (i.e.
> culture) rather different than that of those who started with APL,
> Fortran, mainframes, and so on. Microsoft has filled but not closed
> this abstraction gap as well as it could, though I would think that
> the flagship .Net language, C#, undoes some of the progress made with
> COM, VB6, and ADO (not .Net) by catering to individuals and
> institutions attracted to Java. I guess it's just good business.
As in, ‘noone ever got fired for buying Microsoft’?
cj
Martin Neitzel
once more a reply after a long time:
>> > some kind of filter to translate aplus's input from UTF-8 to the
>> > encoding that aplus expects and its output back to UTF-8.
>>
>> luit(1) does that.
>
>Looks like an inexpensive (and already-tested - ie. reliable) way to
>achieve something similar to what I had in mind. But what encoding would
>you pass to luit?
Luit, like some of the other font/kbd related programs I dealt with
in the last weeks, likes to think in terms of (posix-style) locales.
I am not aware of any official or inofficial APL locale; perhaps
it's time to define one for our programming language, even though
all other locales I ever came across refer to natural languages.
Well, "all" with one exception: minimal locale-based systems can
get away with supporting only a single locale, that being the "C"
locale (yepp, "C" as in "K&R").
Doing the whole localedef(1) dance is a lot of work but I guess
worthwhile, be it for individual dialects or a common superset
as for example Adrian Smith's APL385 collection [Vector 19/3, 122pp].
What I could benefit from are []AV tables for various dialects,
but all pretty please in straight ascii and *without* any APL.
The APL FAQ tells me that Weigang's APL-ASCII transliteration
is available for most any dialect. If that's so, 256-element
lists of canonically transliterated []AVs would be most welcome.
Martin
Martin Neitzel
MN> fonts. For APL, it currently serves the A+ and APLX fonts. [...]
CJ> Thanks for your offer, but on current debian systems, shouldn't X fonts
CJ> be served by fontconfig?
I have little clue on this. All I understand from the documentation
is that fontconfig is yet another evil abstraction layer on top of
X11 (or other GUI systems). It provides one more way to specify
font names and match those names against the fonts you actually
have (or can compute) on your system. In particular, its job is
to match fonts you *don't* have, say, "Comic Sans MS" on a Unix
system, to substitute fonts.
I may err but I don't think fontconfig per se is would serve
a font across the network as xfs(8) will do. That is, people can
use the kapl fonts just by extending their font path:
xset +fp tcp/sco.gaertner.de:7100
(and asking for a hole in my firewall.)
>As to integrating A+ to my debian setup, I ran out of time and
>eventually did the following:
>
>1. ‘dpkg-reconfigure locales’ to gen' the en.US ISO8859-1 locale
>2. created an 8-bit ‘apl’ keymap in /usr/share/X11/xkb/symbols
Defining a proper A+ keymap was way to go! It's nice to have that
as an alternate solution to those xterm key bindings coming along
with A+. Could you send me your map?
Abusing the latin1 locale for APLs is not really the correct thing
but a working solution as interim hack. The kapl .bdf/.pcf fonts
have the same sin embedded and are listed as "ISO8859"-encoded. It
would have been possible and more appropriate to state the encoding
as "font-specific", given that we are lacking any specific APL
encoding [*]. These mis-representations tend to proliferate in ugly
ways.
Martin
[*]: Or have we APLers a (ISO 2375) registered character set already?
I came across this question when I researched the ANSI terminal escape
sequences for switching character sets. (Those G0 / G1 / ... things,
see ISO 2022 for the switching framework.)
Martin Neitzel
MN> I came across this question when I researched the ANSI terminal escape
MN> sequences for switching character sets. (Those G0 / G1 / ... things,
MN> see ISO 2022 for the switching framework.)
Indeed we have. The APL Working Group of the Canadian Standards
Association brought us
The APL Character Set for Workspace Interchange
ISO 2375 Registration number 68, June 1983
I found this document on http://www.itscj.ipsj.or.jp/ISO-IR/
To be specific: http://www.itscj.ipsj.or.jp/ISO-IR/068.pdf
It's a 94 char code set covering both uppercase-only A-Z and
all APL characters, assuming one uses overstrikes.
Martin
PLJ
offer now may not be of much use to you. In PLJsAPL, I based QuadAV
on Phil Chastney’s font. His work is also available at:
http://www.chastney.com/~philip/
I have his permission to include his font in my release at:
http://home.comcast.net/~paul.l.jackson/PLJsAPL/
As a result, my QuadAV is 65536 characters. I also included mapping
values for a few of the APL implementations I have access to.
QuadAvAPLse The PC DOS product I set out to replace so I
could buy a 64 bit machine
QuadAvEbcdic The IBM mainframe product, as published on the
web
QuadAvAPL2pc The current IBM Windows product
I find it quite nice to be able get around the old quarrels by having
all versions of APL map into one QuadAV. PLJsAPL also includes
QuadBytes that allows you to read and write files in your translate
table of choice.
Paul
On Jan 26, 7:48 pm, neit...@marshlabs.gaertner.de (Martin Neitzel)
wrote:
David Liebtag
invent a new 1 byte locale encoding.
David Liebtag
Chris Jones
> MN> FWIW, I have a personal fontserver supplying me with non-standard
> MN> fonts. For APL, it currently serves the A+ and APLX fonts. [...]
>
> CJ> Thanks for your offer, but on current debian systems, shouldn't X fonts
> CJ> be served by fontconfig?
> I have little clue on this. All I understand from the documentation
> is that fontconfig is yet another evil abstraction layer on top of
> X11 (or other GUI systems). It provides one more way to specify
> font names and match those names against the fonts you actually
> have (or can compute) on your system. In particular, its job is
> to match fonts you *don't* have, say, "Comic Sans MS" on a Unix
> system, to substitute fonts.
> I may err but I don't think fontconfig per se is would serve a font
> across the network as xfs(8) will do.
Good point.. in my very limited ‘one laptop per child’ :-) setup, I do
not use X remotely. I only have vague memories that X interfaces with
fontconfig via the Xft extension.. so maybe this would also include
xfs's remote font server capabilities. I don't have access to an
environment that would let me test this assumption.
> That is, people can use the kapl fonts just by extending their font
> path:
> xset +fp tcp/sco.gaertner.de:7100
>
> (and asking for a hole in my firewall.)
I had to add a something xset command to my ~/.xinitrc to enable the
APLX fonts because I installed them in /usr/local/share/fonts/X11/misc
rather than the system's /usr/share/fonts/X11/misc - just to make sure
they didn't get wiped out in the event of a debian upgrade.
Now the interesting point is that even after I had defined this
/usr/local/... directory to fontconfig.. I was never able to get either
xfd or the ‘startaplx’ GUI to find them.. fontconfig has the APLX fonts
in its cache, aliases and all.. but it sounds as if the clients need to
be fontconfig-aware for this to work.
>>As to integrating A+ to my debian setup, I ran out of time and
>>eventually did the following:
>>
>>1. ‘dpkg-reconfigure locales’ to gen' the en.US ISO8859-1 locale
>>2. created an 8-bit ‘apl’ keymap in /usr/share/X11/xkb/symbols
>
> Defining a proper A+ keymap was way to go! It's nice to have that
> as an alternate solution to those xterm key bindings coming along
> with A+. Could you send me your map?
Sent as an attachment to the ‘marshlabs’ address above.. Not sure this
qualifies as ‘software’ but feel free to amend, improve, redistribute,
or mangle in any way at your heart and soul's content. :-)
> Abusing the latin1 locale for APLs is not really the correct thing
> but a working solution as interim hack. The kapl .bdf/.pcf fonts
> have the same sin embedded and are listed as "ISO8859"-encoded. It
> would have been possible and more appropriate to state the encoding
> as "font-specific", given that we are lacking any specific APL
> encoding [*]. These mis-representations tend to proliferate in ugly
> ways.
How true.. I initially hoped that a standard tool such as iconv would do
the hard work for me.. but I have not been able to find any sign that
iconv knows anything about APL code pages.. But then ‘iconv -l’ lists
over one thousand different encodings on my current system.. so given
that I knew not exactly what I was looking for, I may have missed it.
cj
Martin Neitzel
> Does Luit support 2 byte Unicode? If so, I would use that rather than
> invent a new 1 byte locale encoding.
The "new 1 byte encoding" was already invented by A+. (And perhaps that
encoding is not even that new but just adapted from somewhere else).
Luit is just a translator interfacing the A+ interpreter with its
special 1-byte character set into a Unicode-based I/O environment.
In other words: running A+ under luit eliminates the need to switch
to some special font/encoding.
Martin
Martin Neitzel
I usually don't run Windows and it will take me some time until I
can a look at PLJsAPL. (I will!) In the meantime, I visitied Phil
Chastney's pages, in particular his paper relating to the "N 3067
APL Character Repertoire", containing the link to the Draft Standard.
That alone already helps me *a lot*. Thank you for referring me to
that particular foundation!
Martin
rustom
wrote:
The last (March 2nd) post of Chris Jones here may be of interest
http://groups.google.com/group/comp.lang.python/browse_thread/thread/ffba3b61cd0a821e/e902934bf11b2fef#e902934bf11b2fef
rustom
> The last (March 2nd) post of Chris Jones here may be of interest
> http://groups.google.com/group/comp.lang.python/browse_thread/thread/...
Sorry did not notice that Chris Jones was common to both threads :-)
Anyhow the whole thread may be of interest to others here.