Debugging

I have for a few months had the pleasure of relearning APL.(Dyalog)
I am gradually picking up on all the new tools that have been added
since I have been away.
There are several items of interest like the debugging which has
impressed me a lot.
I think we are not talking enough about all the positive things that
have happened in the APL world.
Yes there are a lot of major new tools and utilities but there are
also a number of small things that as a constant user of APL you may
not think of.
I am not alltogether happy about the current documentation and some of
the things you need for daily life as a developer is so common that it
is not explained.
I think newcomers have a hard time finding their way.
I try to look at Dyalog as a newcomer and report my findings to
Dyalog.
They seem willing to change the docs and are working on it.
Changing the product is relatively easy compared to changing the docs.
I remember that we sometimes did changes and it took for ever to get
those changes into the docs and very often they never made it into the
docs.
Over a long period of time a hell of a lot may very well be well
hidden in the product and only a handful of people know about it.

"Gosi" <gosinn@gmail.com> wrote in message
news:8ff85b0d-1395-40f3-aa0f-9facd881ae09@d45g2000hsc.googlegroups.com...
>I have for a few months had the pleasure of relearning APL.(Dyalog)
[...]
> Changing the product is relatively easy compared to changing the docs.
[...]

I think this is a well-known phenonemon. Changing docs is far less
interesting than changing the product. It's - in general - often
"forgotten" rather than difficult. I never had a complaint on Dyalog's
docs, neither on new manuals nor on patches or debugs. I found Digital's
VAX-APL documentation superior, the User Guide as well as the Reference
Manual.
IBM APL2/PC's Reference Manual is as you may expect from that company:
every detail is treated and explained completely & formally - excellent!
Their User Guide was sort of Punjab to me (type setting and all those
AP's ...).

ps. Björn, please explain me one more time those <Alt> combinations (I'm
familiar with the keypad nums). E.g. how do I type in the hexa values?
<Alt> with letters is tied to shortcuts on my system (Windows XP + OE).

On May 27, 9:09Â*am, "jk" <aq...@planet.nl (not the q's)> wrote:
> "Gosi" <gos...@gmail.com> wrote in message
>
> news:8ff85b0d-1395-40f3-aa0f-9facd881ae09@d45g2000hsc.googlegroups.com...>I have for a few months had the pleasure of relearning APL.(Dyalog)
> [...]
> > Changing the product is relatively easy compared to changing the docs.
>
> [...]
>
> I think this is a well-known phenonemon. Changing docs is far less
> interesting than changing the product. It's - in general - often
> "forgotten" rather than difficult. I never had a complaint on Dyalog's
> docs, neither on new manuals nor on patches or debugs. I found Digital's
> VAX-APL documentation superior, the User Guide as well as the Reference
> Manual.
> IBM APL2/PC's Reference Manual is as you may expect from that company:
> every detail is treated and explained completely & formally - excellent!
> Their User Guide was sort of Punjab to me (type setting and all those
> AP's ...).
>
> ps. Björn, please explain me one more time those <Alt> combinations (I'm
> familiar with the keypad nums). E.g. how do I type in the hexa values?
> <Alt> with letters is tied to shortcuts on my system (Windows XP + OE).

I did work for IBM many years and I know how they write documentation.
There are a number of people who only write docs.
We were not always very quick of telling them about everything that
was possible.
Also even if we did tell them it took a long time before it was
published.
It would be great if they decided to make APL2 more visible again.

Regarding word and Unicode it is easy
Place the cursor behind the char and press alt+x
Same press alt+x behind the number and get the char again

a�2 3�'þæöð'
a
þæö
ðþæ

0061 2190 0032 0033 2374 0027 00FE 00E6 00F6 00F0 0027
0061
00FE 00E6 00F6
00F0 00FE 00E6

This is straight from Dyalog into word and then here after alt+x
treatment in word
I put spaces between the numbers to make it clearer

On May 27, 10:06Â*am, Gosi <gos...@gmail.com> wrote:
> On May 27, 9:09Â*am, "jk" <aq...@planet.nl Â*(not the q's)> wrote:
>
>
>
> > "Gosi" <gos...@gmail.com> wrote in message
>
> >news:8ff85b0d-1395-40f3-aa0f-9facd881ae09@d45g2000hsc.googlegroups.com...>Ihave for a few months had the pleasure of relearning APL.(Dyalog)
> > [...]
> > > Changing the product is relatively easy compared to changing the docs.
>
> > [...]
>
> > I think this is a well-known phenonemon. Changing docs is far less
> > interesting than changing the product. It's - in general - often
> > "forgotten" rather than difficult. I never had a complaint on Dyalog's
> > docs, neither on new manuals nor on patches or debugs. I found Digital's
> > VAX-APL documentation superior, the User Guide as well as the Reference
> > Manual.
> > IBM APL2/PC's Reference Manual is as you may expect from that company:
> > every detail is treated and explained completely & formally - excellent!
> > Their User Guide was sort of Punjab to me (type setting and all those
> > AP's ...).
>
> > ps. Björn, please explain me one more time those <Alt> combinations(I'm
> > familiar with the keypad nums). E.g. how do I type in the hexa values?
> > <Alt> with letters is tied to shortcuts on my system (Windows XP + OE).
>
> I did work for IBM many years and I know how they write documentation.
> There are a number of people who only write docs.
> We were not always very quick of telling them about everything that
> was possible.
> Also even if we did tell them it took a long time before it was
> published.
> It would be great if they decided to make APL2 more visible again.
>
> Regarding word and Unicode it is easy
> Place the cursor behind the char and press alt+x
> Same press alt+x behind the number and get the char again
>
> Â* Â* Â* Â* Â* Â* Â*aâ†�2 3â�´'þæöð'
> Â* Â* Â* a
> þæö
> ðþæ
>
> Â* Â* Â* Â* Â* Â* Â*0061 2190 0032 Â*0033 2374 0027 00FE 00E6 00F6 00F0 0027
> Â* Â* Â* 0061
> 00FE 00E6 00F6
> 00F0 00FE 00E6
>
> This is straight from Dyalog into word and then here after alt+x
> treatment in word
> I put spaces between the numbers to make it clearer

⎕UCS'a�2 3�''þæöð'''
97 8592 50 32 51 9076 39 254 230 246 240 39

⎕ucs 97 8592 50 32 51 9076 39 254 230 246 240 39
a�2 3�'þæöð'

The Unicodes should be easy to make APL code transfer

Gosi wrote:
>
> ⎕UCS'a�2 3�''þæöð'''
> 97 8592 50 32 51 9076 39 254 230 246 240 39
>
> ⎕ucs 97 8592 50 32 51 9076 39 254 230 246 240 39
> a�2 3�'þæöð'
>
> The Unicodes should be easy to make APL code transfer

definitely -- cut&paste between documentation, scripts and immediate
execution should be a doddle ...provided they come from the same vendor

cut&paste from vendor A's documentation to vendor B's interpreter will
work only if vendors A and B use the same mapping from APL symbols to
Unicode values (that is a necessary but not a sufficient condition)

I believe this to be 99.4% true, but I'm not sure what Unicode values
have been generally adopted for the diamond statement separator

there may also be differences on asterisks, hyphens, etc, but tolerant
input should be able to handle any discrepancies

EBCDIC-oriented systems like Soliton's will probably still cause problems

and cut&paste from PDFs cannot be guaranteed to work

/phil

On 27 May, 13:58, phil chastney
<phil.hates.s...@amadeus.munged.eclipse.co.uk> wrote:
>
> definitely -- cut&paste between documentation, scripts and immediate
> execution should be a doddle ...provided they come from the same vendor
>
> cut&paste from vendor A's documentation to vendor B's interpreter will
> work only if vendors A and B use the same mapping from APL symbols to
> Unicode values (that is a necessary but not a sufficient condition)
>

Phil, this simply isn't true, at least in the case of pasting into
APLX, and (I believe) the other major APL vendors.

At the risk of repeating myself, it is possible and sensible to have
multiple Unicode values mapping to a single APL symbol. This is what
APLX does, and I believe others do as well. So, yes, you CAN paste
from (say) IBM APL2 or Dyalog APL sessions directly into APLX, and I
believe the other way round.

Where there is a problem, it is most likely to be caused by
documentation which still uses non-Unicode encodings. Sadly, this
currently includes our PDF manuals, not because we are stupid, but
because many PDF readers out there do not fully support Unicode.

The problem won't occur for Unicode-encoded web pages, provided any
reasonable set of choices of character encodings has been made.

If anyone is interested in the details, see the very last page of the
APLX Language Manual, (http://www.microapl.co.uk/apl/APLXLangRef.pdf)
"Alternative Unicode Mappings".

The bottom line is: embrace Unicode, it's a great thing for APL!

Richard Nabavi
MicroAPL

microapl@microapl.demon.co.uk wrote:
> On 27 May, 13:58, phil chastney
> <phil.hates.s...@amadeus.munged.eclipse.co.uk> wrote:
>> definitely -- cut&paste between documentation, scripts and immediate
>> execution should be a doddle ...provided they come from the same vendor
>>
>> cut&paste from vendor A's documentation to vendor B's interpreter will
>> work only if vendors A and B use the same mapping from APL symbols to
>> Unicode values (that is a necessary but not a sufficient condition)
>>
>
> Phil, this simply isn't true, at least in the case of pasting into
> APLX, and (I believe) the other major APL vendors.
>
> At the risk of repeating myself, it is possible and sensible to have
> multiple Unicode values mapping to a single APL symbol. This is what
> APLX does, and I believe others do as well. So, yes, you CAN paste
> from (say) IBM APL2 or Dyalog APL sessions directly into APLX, and I
> believe the other way round.

....which is what is known as "tolerant input" in some quarters, which,
in case I forget to mention it, should be able to handle any discrepancies

> Where there is a problem, it is most likely to be caused by
> documentation which still uses non-Unicode encodings. Sadly, this
> currently includes our PDF manuals, not because we are stupid, but
> because many PDF readers out there do not fully support Unicode.

even PDF readers which fully support Unicode may encounter problems with
documents prepared using proper Unicode values

> The bottom line is: embrace Unicode, it's a great thing for APL!

I have never suggested otherwise . . . /phil