amit@umn-cs.cs.umn.edu (Neta Amit) (03/29/88)
I.P.Sharp & Assoc (IPSA) is releasing their APL implementation for the PC as a shareware. Roland Pesch of IPSA (...snoopy!pesch) is coordinating this release. Since his connection to the network is somewhat flaky, and since I have a strong interest in helping spread around an inexpensive version of APL, I have volunteered to help him distribute SAPLPC. In a short time (the next few hours) I'll be posting SAPLPC to the comp.binaries.ibm.pc newsgroup. SIMTEL20 administrators are urged to make SAPLPC available on the PD1:<MSDOS> area. I will add saplpc.arc to ~ftp/pub/ for anonymous FTP on umn-cs.cs.umn.edu [128.101.224.1]. Please transfer in Binary mode during off-peak hours; our machine is heavily loaded. The posting will consist of 10 parts, most of which in the 62KB range. Each part begins and ends with a "---cut here---" line. To get a working version, assuming you're on a Unix machine, 1. Store portion between "---cut here---" lines e.g. in saplpc[a-j] 2. "cat saplpc.[a-j] > saplpc.uue" (a 609025 bytes file). 3. uudecode saplpc.uue 4. Transfer the resulting saplpc.arc (442012 bytes) to your PC. 5. PKXARC it there. 6. Follow the Installation instructions. There is an IBM-370 emulator between the APL code and your PC. As a result, SAPLPC is (1) not as fast as other APL-PC implementations, but (2) a mature and reliable product. Anyway, this is what IPSA says. I didn't test it thoroughly, but I tend to believe them. On our true blue 8MHz ATs it ran just fine on some simple test cases. IPSA's definition of Shareware is both liberal and reasonable. If you are learning APL, or want to play with it occasionally, stick to Standrad APL (including Del editor) and you're ok. You owe IPSA nothing. If you are into serious application development, it is quite obvious that you will NEED the complete documentation set, with descriptions of several utility workspaces distributed with saplpc. You register directly with IPSA, pay $59, and receive the docs. Adress and phone numbers are in the package. In my opinion, this is the right way to distribute major shareware packages. -------------------- All questions, proposals, bug reports, thanks and such should be addressed to ...!snoopy!pesch . ("Uupath snoopy" will show you how to get to snoopy from your Unix machine). I'll take the opportunity and say a big Thanks, Roland, and post two questions: 1. IPSA is requesting registered users not to photocopy manuals. This is reasonable in the commercial world, but one cannot expect students taking a Programming Languages class with 4 languages to have to pay $60 each. So: has IPSA set a policy for students learning APL? What is it? 2. On systems with EGA type display cards, saplpc loads soft APL fonts to the graphics RAM. When exiting APL, the previous fonts are not restored (e.g. type "*"). Bug or feature? --- Enjoy ! --- -- Neta Amit U of Minnesota CSci Arpanet: amit@umn-cs.cs.umn.edu
Pesch@cup.portal.com (04/07/88)
Neta Amit posted two questions with the announcement of SHARP APL/PC's availability: >1. IPSA is requesting registered users not to photocopy manuals. > This is reasonable in the commercial world, but one cannot expect > students taking a Programming Languages class with 4 languages to > have to pay $60 each. So: has IPSA set a policy for students learning > APL? What is it? I've been pursuing this with the people at IPSA who decide these things. I've succeeded in persuading them that it is reasonable to prepare a machine-readable version of the PC-product manual, to be distributed as shareware on the same basis as the interpreter; so one thing students may do is read the docn on their own machine, or print out whatever portions of it they have the patience to wait for. Beyond this, the policy remains unchanged. (The downside of this is that I got them to agree to the plain-ascii docn by dint of volunteering to convert it from its arcane internal markup language myself. So it may take a few weeks to actually make an appearance; conceivably longer). >2. On systems with EGA type display cards, saplpc loads soft APL > fonts to the graphics RAM. When exiting APL, the previous fonts > are not restored (e.g. type "*"). Bug or feature? We tend to regard this as a feature; if you happen to want to edit 8-bit text containing APL special glyphs, some editors will work fine with the font once it's loaded. For instance you might want to read the upcoming docn that way, so APL examples look the same way as in the interpreter. PC's in our environment tend to have the APL font loaded most of the time. However, I gather you can reset it by invoking the DOS "mode" command, something like "mode co80"---which you can of course add to the BAT file if that suits your work habits best. Neta also kindly said--- >I'll take the opportunity and say a big Thanks, Roland Thank *you*, Neta!