info-mac@uw-beaver.UUCP (07/21/84)
From: mclure@Sri-Unix.arpa I have been working with the latest Beta release of Instant Pascal and am totally overwhelmed by this development system. It is the best development environment I have ever worked in. Period. I have been a systems programmer on Unix for a number of years and am used to nice tools. But these tools and this environment totally blows away any C development environment I have used on Unix. The ease of use, speed of debugging, and general pleasure associated with this package is nearly orgasmic. (!) Soon we will see similar environments springing up for other high-level languages. I predict that the Mac will become the de facto standard software development environment for people "in the know." Once you have tasted of window-debugging, nothing else is adequate. My congratulations go to authors Lucas and Maruhnic. Stuart
info-mac@uw-beaver (info-mac) (07/25/84)
From: mclure@Sri-Unix.arpa
When MacTerminal and MacPut/MacGet work properly, it will be simple
to load stuff to/from a Macintosh. One will regularly edit textfiles
or programs (debugging with MacPascal, MacC, MacForth, MacBasic).
Then, when an edit is complete, the file can be sent in the proper
direction. And the program can be run on the other machine.
This will be very useful for avoiding the lengthy daytime response
that most overloaded mainframes have. The beauty of the personal
computing is that the response is always the same. While I feel that
the Macintosh processor should be at least 4-8 mhz faster to be truly
useful, at the moment it is usable for textediting, simple debugging,
etc. I hope that future Macintoshes will have faster versions of the
68000.
And while it is true that most Unixen don't take advantage of
special terminal capabilities such as windowing, there are a few that
do. The lack of a real standard is the problem. Everyone has their
own special "standard".
Stuartinfo-mac@uw-beaver (info-mac) (07/25/84)
From: Richard Furuta <Furuta@washington.arpa>
Could someone please explain to those of us out here in the sticks what
Instant Pascal is and if it is related to MacPascal? Who is producing
this and what is the estimated availability information?
--Rick
-------
Return-Path: <Mclure@Sri-Unix>
Received: from sri-unix by SUMEX-AIM.ARPA with TCP; Tue 24 Jul 84 16:47:48-PDT
Date: 24 Jul 84 16:36-PDT
From: mclure@Sri-Unix
To: Furuta@WASHINGTON.ARPA
CC: info-mac@sumex-aim
Subject: Re: Instant Pascal
Instant Pascal is by Think Technologies. I don't know exactly what
relation this company has to Apple but I have heard they were
comissioned by Apple to write an interpreter Pascal for the Macintosh.
It is not yet available commercially although Beta versions are
floating around.
Instant Pascal has been reviewed in both MacWorld and St.Mac
magazines. The current newstand issue of the latter carries a
comprehensive review that I recommend.
I have heard it will be available "soon." "Soon" ranges from 3
weeks to 3 months. The price will be $125. The documentation is
excellent and comprehensive. The documentation on Quickdraw access is
little short of amazing.
In short, it is an excellent software package. The only problem is
that the hardware isn't fast enough for substantial problems. The Mac
should really be running at 2x its current speed along with a good,
fast Winchester in order to get useful work done (e.g. programming and
non-trivial number computation and crunching). I consider a
well-configured PDP-11/70 with split instruction/data space to be the
minimum machine for doing good research problems on. The Macintosh is
not quite at this level, but if it were sped up by a factor of 2 or 3,
we'd sure be getting close.
I know nothing about MacPascal. There is a rumor that Apple has an
internal development effort going for a true compiler, but I have not
heard much about it.
Ideally, we would like to have something like Instant Pascal
well-integrated with a compiler. That way, you could develop your
programs in the comfortable interpreter development environment. Then,
for true systems applications and everyday running of your program, you
would pass your Pascal program to the optimizing compiler to get a
reasonably fast compiled version.
Stuartinfo-mac@uw-beaver (info-mac) (07/25/84)
From: BILLW@SRI-KL People interested in writing combined applications on mainframes and microcomputers should read the MIT paper on LEP - The local editor protocol. Although designed mostly for dual processing screen editors, this would at least be a good place to start. Actually, there are a number of programs such as this. I wrote a (primarilly local) interface to a tele-conferenceing system for the HP150, and (more complicated) i beleive there is a program for IBMPCs that simulates the dialog database locally, creating sort of script files that can later be sent to the main system, thereby minimizing the (very expensive) connect time. BillW
info-mac@uw-beaver (info-mac) (07/26/84)
From: Scott M. Hinnrichs <SMH@SRI-KL.ARPA> You may want to do some more research on what the tty drivers and other system services are able to do as far as blocked and character data. It is easily possible to make a IBM type interface for a UNIX system where it is not as easily possible to go the other way. Just ask AMDAHL. Admittedly it is the hardware philosophy getting in the way, but nevertheless it is an inherent problem when dealing with IBM shops. You are on the right track though. We are trying to establish, through the use of a standard terminal line, a dialogue which can occur between an intelligent user interface such as the MAC and any mainframe. The goal is to make a definition of the protocol for MAINFRAME <-> MAC handshaking, take the idea from there and implement an application on top of that link. One possibility is to take the idea of sockets/ports and treat the connection like a network protocol using the line as the base medium. First, construct a command protocol to run on one stream as in a remote-procedure calling mechanism. This can be made to be flexible enough to provide basic communication requests, and yet provide the needed hooks to quote more application specific requests. Second, provide the data channel needed to transmit the data requests made in the command stream. There are some considerations in this that would suggest that it should use some standard graphics protocol other than what is currently available. Initially it can merely move the data in checksummed datagrams. This is to be implemented soon, so if anyone has any ideas I would appreciate hearing from you now. Scott -------
info-mac@uw-beaver (info-mac) (07/26/84)
From: Scott M. Hinnrichs <SMH@SRI-KL.ARPA> As for the Dialog system it is more of a simple-minded system that extends the terminal from the local shop that Dialog runs to a remote terminal access. The request is established on the XT and then is made to a remote XT which is connected to the IBM mainframe. There is a simple ftp/telnet system which I wrote for them to transfer data and emulate a terminal from the remote XT through the local XT to the mainframe. The XT's are used merely to support a highspeed 9600 baud (half-duplex) modem on the phone lines. The software allows an emulation of full-duplex via multi-stream support. It approaches 70% of 9600 baud in an average interactive session, but with a full 9600 baud for one-way data transfer. Scott -------
info-mac@uw-beaver (info-mac) (07/26/84)
From: Randy Frank <FRANK@UTAH-20.ARPA> Instant Pascal and MacPascal are one in the same: Think Technologies is doing Instand Pascal for Apple, and it will come out as an "Apple labeled" product called MacPascal. Apple has said that they will also come out with a compiled Pascal at some point in the future that will obviate the need for a Lisa do to cross development; supposedly this environment will require a 512K Mac. -------
info-mac@uw-beaver (info-mac) (07/26/84)
From: Rick McGeer (on an aaa-60-s) <mcgeer%ucbchip@Berkeley> Well, since you asked.... The ideal programming environment would permit me the full power of Gosling's emacs, with load intelligently shared between my Mac and the mainframe. As I write this, I have two shells and a Lisp running within my emacs; as well I'm reading and responding to my mail, editing a major program, and touching up that program's documentation. This obviously requires more than a simple protocol. However, for this to work, the protocol would have to permit the Mac to have more than one window multiplexed over a single data line, since ideally each interactive process would would deal with a separate window. Further, block data would have to go down the same line, since I presume that it's preferable to most of us to do editing locally. Finally, it would be nice if processes on the other end could open up more than one window on the Mac, so that error messages (say) weren't intermixed with output... Frankly, the dividing line between the layers of application are a little fuzzy to me at this point.