reviving old STSC workspaces

[lyman]

I am collaborating with my father on reviving code written in APL
originally for a 360 and more recently (but not that recently) ported
to STSC APL in which it resides now. We do not have access to an APL
implementation which will read the old files which were last accessed
in DOS on a machine running Windows '95. The workspaces and data
appear to be in the form of ".aws" and ".asf" files.

I see by googling that there are some public domain implementations of
APL available but I have not found any that will run under Windows XP
or later (meaning I have not succeeded in getting them to run). Also,
once I locate an implementation I am not sure how interchangeable
workspace formats are.

Thanks for any advice.

Cheers,

Lyman Hurd

[crishog]

On Apr 22, 3:04 am, lyman <lyman.h...@gmail.com> wrote:

> I see by googling that there are some public domain implementations of
> APL available but I have not found any that will run under Windows XP
> or later (meaning I have not succeeded in getting them to run).  Also,
> once I locate an implementation I am not sure how interchangeable
> workspace formats are.
>
>

Try http://www.nars2000.org/ - I run it off a USB drive & it works
under both XP home & professional. Not tried it on Vista (then again I
avoid Vista like the plague) or 7

Chris

[Ibeam2000]

I would suggest the following:

0. Forget about workspace-level interchange. You will have to piece
this together by hand.
1. Locate a copy of the old APL*Plus/PC. This should run on XP etc,
although I haven't tried.
2. Write a small program to write the []VR of all the functions to a
standard DOS file.
[]NCREATE, []VR, []NAPPEND, []NUNTIE is what you will need to know.
3. Be sure to take a copy of []AV along and know what the elements
are. This is usually well documented
4. Write the contents of the variables to file as well
5. If there are any component files, be sure to get a copy of the
contents as well on file.

The idea is to move the contents to the least proprietary form
possible.

In the new APL, whatever it may be, you will need to do the reverse

6. Read the old []AV and prepare a translate table, the old []AV
elements in the new locations. This is probably the most difficult
thing and possibly has been done for you, check the supplied
workspaces in the new APL.
7. Read in the functions, variables, and component file contents,
using the translate table. The functions should be immediately
visible. If you see some strange characters, go back and check the
translate table.
[]AV[XLATE iota TEXT] to convert from old to new.
8. []FX all of the functions, assign the variables, and create new
component files
9. APL*Plus/PC had a lot of little functions, []PEEK, []POKE, []WIN,
etc. which resembled the offerings from Basic of the day. You will
need to understand what they did and convert the code accordingly.
Things like []WIN had no equivalent in the new systems and should be
rewritten using the new Windows features. This could be quite
involved.

[Rex Swain]

See http://forum.apl2000.com/viewtopic.php?p=22 to download APLSE
(APL*PLUS Special Edition): Freeware DOS APL, circa 1992. I believe
this is basically APL*PLUS/PC version 10, circa 1992. No Windows, no
nested arrays, etc. It will load .aws workspaces.

[del]

On Apr 22, 5:16 am, Ibeam2000 <ibeam2...@gmail.com> wrote:
> I would suggest the following:
>
> 0.  Forget about workspace-level interchange.  You will have to piece
> this together by hand.

...

> 9.  APL*Plus/PC had a lot of little functions, []PEEK, []POKE, []WIN,
> etc. which resembled the offerings from Basic of the day.   You will
> need to understand what they did and convert the code accordingly.
> Things like []WIN had no equivalent in the new systems and should be
> rewritten using the new Windows features.  This could be quite
> involved.

All this has already been done for some APLs.
See www.milinta.com/apl
There is even a way to translate some of the code automatically.
Not foolproof but better than starting from scratch.

[del]

What is your target APL?

[Richard]

I aggree, my experience with converting to APLPlus to APL+Win is that
it is quite do-able
and tools for this exist. BUT it is non-trivial if a large interactive
system.
Personally, I would not convert unless I needed features from the
newer APL,
eg to interface with Excel etc.
We have had old DOS apps running quite happily on our flagship dual
core 64bit
fast machine. (in a 32-bit virtual PC).
If you do want to convert to APL+Win, APL2000 have a conversion tool.
We ourselves developed a library of functions replacing {quad}peek
etc.
Happy to share these if they are of interest.
Note that converting printer commands can be an interesting exercise.
For some time we developed in parallel with the same APL app running
on some
clients DOS APLPlus and other clients APL+Win. Those days are over,
thankfully.
Richard Hill

[lyman]

Thank you for your responses. I will try my best to implement several
of them.

I should give a bit of background. My father is a retired theologian
and the code is a system to teach New Testament Greek interactively.
Many of the contortions that had be exercised in the dark days prior
to Unicode are no longer necessary. I am an ex-math professor turned
software engineer who took enough Greek in high school to be
dangerous.

I should explain that my primary goal is to extract the data including
lots of textual data and tables of word stems etc. The eventual aim
is to recode the algorithms into a compiled language at the moment the
primary candidates being Java, C# and Objective C. My first goal is
to extract the data in the workspaces to something neutral like UTF-8
encoded XML! APL was actually my first serious computer language but
I do not want to mention when that was :-).

Cheers,

Lyman Hurd

[del]

Dyalog has both Unicode and []XML which could save you time.
I believe that a personal licence is fairly cheap too (50£?)

[PLJ]

Your situation sounds similar to the one which caused me to write a
compiled APL object model in Visual Basic. I have been using STSC's
APLSE for some years, and provide a DOS font for it. Both can be
found at
http://home.comcast.net/~paul.l.jackson/APL/
Click on APLSE for the APL interpreter, and tools for the DOS font.

You might also want to look at
http://home.comcast.net/~paul.l.jackson/PLJsAPL/
and click on PLJsAPL to get a copy. If you write out a function from
APLSE with the function in my tool kit, you can read them back in with
_x.FromAPLse("FileName.txt")
in ShellAPL.

Paul

[dh...@shawcross.ca]

"Rex Swain" <r...@rexswain.com> wrote in message
news:bde8420f-060d-4cad...@u34g2000yqu.googlegroups.com...

--------------------------------------------------
With 64 bit win 7 you will have to also use something like DOSBox because
this version doesn't support 16 bit programs. I don't know about the 32 bit
version. However. 32 bit Vista and XP do work with APLPLUS/PC version 11
(and should work with 10) - but there is a problem with characters unless
you use a "window" rather than full screen.

--
-----
Don Kelly
cross out to reply

[lyman]

I have made a lot of progress thanks to contributors to this thread.
I downloaded aplse and the aplplus demo (for the documentation). I
have not yet hooked thing sup to a printer but that is a secondary
consideration at the moment. My current roadblock is accesisng my
old .asf files. The workspace appears to load but when I execute:

[]FLIB 9

for example I get a list:

9 GKEDEFS
...

but when I try to say:

'9 GKEDEFS' []FTIE 1

I get:

FILE ACCESS ERROR

I have library 9 linked to a subdirectory:

lib 9 = C:\APL\DISKS\GKTUTOR\APL\GKTUTOR

and I have no problem executing a )LOAD or a workspace from that
directory or listing its contents; I just cannot retrieve file data.

Cheers,

Lyman

[Björn Helgason, j-programming]

On 24 Apr, 04:11, <d...@shawcross.ca> wrote:
> With 64 bit win 7 you will have to also use something like DOSBox  because

Thanks for the tip!
Dosbox works great for a game I have been addicted to for years and
does not run in newer computers.
I see that dosbox is supposed to run in Linux too so I will try that
too.
I can at least throw away some of my oldest computers I have kept just
to be able to run sherlock.
There are actually many new versions available of sherlock but none
can compare with the old version.

[Doug White]

<dh...@shawcross.ca> wrote in news:mcuAn.142518$gF5....@newsfe13.iad:

You can run APLSE in full screen mode in XP. I forget all of the
details, but the instructions & files required are available here:
http://marthallama.org/apl/APLXP_SETUP.zip

Doug White

[Doug White]

Björn Helgason, j-programming <gos...@gmail.com> wrote in news:c0860b29-
9cfd-4a6a-90d...@g30g2000yqc.googlegroups.com:

Dosbox is good, but the standard version used to have the emulation of
the numeric coprocessor shut off. When I was playing with it several
years ago, I had to ask somebody to compile it with the switch set to
enable that feature. Otherwise you get a lot of weird results. They may
have fixed that by now, or made it a command line switch.

Doug White

[Ibeam2000]

> FILE ACCESS ERROR

Please try the following:

Use []FSTIE instead of []FTIE

Use the physical location instead of the library number, i.e.

'C:\test\gkedefs' []FSTIE 1

Last and hopefully least, now that you can look at it, check the APL
code to see if there is a file tie with a passnumber, i.e.

'thefile' []FSTIE 1 1234567

or

'thefile' []FREAD 1 13 1234567

Have a look at the inside of the file with Notepad. (But be sure
NEVER to save!)

[lyman]

Looking at the code the file was intended to be opened with a
password, however when the code to access it is autoloaded there
appears to be something amiss about the way the password is being
calculated (yes, it is not a constant!). Is there any chance of
recovering a file's password by looking at it in a binary editor, for
example? Is the file encrypted? And if all else fails would it be
worth looping over possible passwords?

Cheers,

Lyman

[Rex Swain]

Execute "0 []POKE 94" before your []FTIE. My comment says that this
is to "disregard access matrix until after next []FTIE".

(I found this in an ancient utility workspace in a function named
FILEHELPER. I'm not sure if this feature was documented or not.)

[apl.explorer]

Curious,

Did you finally salvage the workspaces? Are they available?

--- William Gallant

[gemesy...@gmail.com]

Hi Lyman;
I had a friend ping me about your query.
It is possible to get all the old STSC APL stuff running quite nicely on a Window-XP box. I even have sAPL (the old P/C version of the I.P. Sharp APL) running on XP. DOSbox-0.74 (the Win32 version) also works nicely. If you are running in DOSbox, you will need to run the little "APLFONT.COM" program to get the APL characters. But if you run in Windows, you can install the "STSCAPL.FON" fonts into Windows-XP, and then for whatever shortcut you use to start APLSE, you just select "properties", (by clicking on the top of the window frame, and then "font", and select one of the STSC fonts, which will show up in the list, if you have installed "STSCAPL.FON" in the C:\Windows\Fonts directory (to install a font in windows, just navigate to \windows\fonts and then click "file", and select "Install new font"...)

With the fonts installed and working - using either DOSbox or Windows CMD shell box, you get a nice, usable little APL.

I built a DOSbox for Android, and it runs on Android-5 tablets. I also have a version of the APLSE for Android, which you can download from the Google PlayStore, on to your Android tablet. If you have old *.AWS STSC workspaces, then you should be able to load these directly into the Android tablet version of APLSE, and run them. You can find my APL's for Android by searching "GEMESYS" on the Google Playstore.

You need an Andriod device to download the APLSE app (it is an .APK file) and run it, but you can look at the details from any browser, at the Google Playstore URL for it:

https://play.google.com/store/apps/details?id=org.gemesys.android.aplse&hl=en

I also have "sAPL" and IBM's "TryAPL2", and the old P/C Watcom APL, all available as Apps from the Playstore, to run on Android. You can run them on Android phones also.

To load and run a workspace in APLSE, you don't need a special keyboard (unless you are using Android 5.1.1, apparently), but if you want to use APL characters (ie generate them, eg. see the iota, for example), you will need to download something called the "Hacker's Keyboard", which allows the "ALT" key to be used correctly. In APLSE, you have to use the "unified keyboard", so APL characters have to be generated via "ALT-x" sequences, where "x" is the key-paired ascii key for the APL character. (eg: ALT-L is the APL Quad, ALT-[ is the "<-" assignment operator, ALT-i is iota, the index-generator function,etc.)

"Hacker's Keyboard" is available free from the Google Playstore, and is the one written by Klaus Weidner. His code is available for inspection on Github.

When you download a keyboard, you have to do *two* things on Android. First, you download and install the keyboard. Then, to see it, you must use "Settings" (the little gear icon), and option "Language an input", to set the default keyboard, to the one you have installed. (I also disable all the "text to speech" and "voice input" options..)

If running my Apps on some Android versions, you will need the "Hacker's Keyboard", as I have just learned there can be problems with the latest Google keyboard, on some versions of Android (eg. Android 5.1.1 on a Huawei phone). The default Google keyboard does not work with my "gDOSbox for Android" app, but the app works fine with the "Hacker's Keyboard". If you are using "TryAPL2", or Watcom P/C APL, you can download my "gKeyboard", which has the APL characters as images on each key. Note: gKeyboard is fairly basic, and does not generate ALT-x sequences, so it is not useful with APLSE. But it works nice with TryAPL2.

All of the GEMESYS Android APL versions are free of charge, and do not contain any "in-app" monitoring, or advertisements. I also built a "GNUPlot37" app, which runs GNUplot on Android. The Apps are basically research projects into what can be done with emulation software, in a small-form-factor device. They all run under gDOSbox. The Android gDOSbox project grew out of my efforts to develop DOSbox code on the Blackberry Playbook which could support a small APLv52-based application, which made use of the APL Runtime system, running withing DOSbox. Right before RIM killed it, the Blackberry Playbook had become a very stable and attractive platform.

Recently, as a proof-of-concept, I put Borland-C version 3 for MS-DOS, on my gDOSbox, running on a Samsung Tab-A tablet, and have successfully compiled the .exe for the Blowfish encryption algorithm, and verified that it matches my original .exe version that can still be run inside a Windows CMD shell on any version of Windows. In order to achieve this level of compatibility, I had to enhance some of the low-level data-storage procedures within DOSbox, and these changes also allowed the APL's to do their math processing correctly. The gDOSbox app is basically my version of DOSbox, which has data representation fixes which allows the math to work correctly.

You mentioned that you have original 360 APL code. The "sAPL" App is a version of the original I.P. Sharp APL P/C, and seems to run reliably on both Windows CMD shell, and within gDOSbox. Depending on the files that you have access to, you might have some luck loading them into sAPL. The Sharp P/C APL is available free of charge, as it was originally offered by IP Sharp with a licence which specifically encouraged people to copy and distribute it.

I have converted STSC *.aws workspaces to Manugistics APLv52, and then moved those to APL-2000 APLwin. I even down-converted some APLv52 workspaces back to STSC APLSE workspaces, to address licencing restrictions for some experimental code. There are several methods one can use to migrate workspaces, but I have generally used the old conversion code that was provided with the original STSC, Manugistics and APL-2000 products.

Best of luck with your project. Old, reliable, debugged code can be very valuable. Even if you don't go into production with it, it can provide critically useful benchmark results for modern development work. Some major financial firms, for example, have these "secret stashes" of ancient code that they know works correctly to address very complex problems. The results produced by this old, accurate code can provide the competitive "DNA" that successful businesses can use to drive modern design, development & test efforts. I hope some of my old APL's can be helpful to your migration efforts.
All the best..
- Mark Langdon,
GEMESYS Ltd.

[apl.explorer]

Still curious about the Lyman workspaces...
Can they be made available or are they copyrighted?
Also, does anyone have old workspaces they can share?

--- William Gallant

[ArrayMac]

On Thursday, 22 April 2010 06:16:09 UTC-3, Lobachevsky wrote:
> I would suggest the following:
>
> 0. Forget about workspace-level interchange. You will have to piece
> this together by hand.

Workspaces are not a good place to store programs. They are better used as a platform to run programs.

> 6. Read the old []AV and prepare a translate table, the old []AV
> elements in the new locations. This is probably the most difficult
> thing and possibly has been done for you, check the supplied
> workspaces in the new APL.

In the more likely case that 'someone should have solved this' is of no use, are there translate tables available somewhere?

[b.mcgui...@gmail.com]

If you can find copies of Jim Weigang's APLASCII package or Johann Mitlöhner's APL transliteration code for the APL implementations of interest, this might be of help in porting your APL workspaces. These packages translate APL characters to and from ASCII representations.

However, note that different versions of APL have different enhancements of their own, so some manual editing may still be necessary to port functions between platforms. For example, native file access varies quite a bit from one APL to another.

[ArrayMac]

On Thursday, 2 June 2016 16:07:58 UTC-3, b.mcgui...@gmail.com wrote:
> If you can find copies of Jim Weigang's APLASCII package or Johann Mitlöhner's APL transliteration code for the APL implementations of interest, this might be of help in porting your APL workspaces. These packages translate APL characters to and from ASCII representations.

Jim Weigang seems to have material here:

http://www.chilton.com/~jimw/a2apapr2.html

and for Mitlöhner, possibly this:

http://www.sigapl.org/Archives/waterloo_archive/apl/workspaces/pp/

> However, note that different versions of APL have different enhancements of their own, so some manual editing may still be necessary to port functions between platforms. For example, native file access varies quite a bit from one APL to another.

The conversion need is for a .ATF file generated from an STSC workspace, which may be possible from what I can now see. Further investigation required.

[DanB]

You can also use the transfer workspaces at www.milinta.com.
See http://www.milinta.com/xfrpc.htm for the documentation.