[mod.mac] INFO-MAC Digest V5 #56

INFO-MAC@SUMEX-AIM.STANFORD.EDU.UUCP (02/23/87)

INFO-MAC Digest          Monday, 23 Feb 1987       Volume 5 : Issue 56

Today's Topics:
     Re: DB-9 to DB-25, and every other Apple cable, for that matter
                  Re: Pinouts for 9 pin socket to db25
                      Re: The Cache and cache bits
                          BeginUpdate/EndUpdate
                           Technical Note 106
                        Usenet Mac Digest V3 #14
                        Usenet Mac Digest V3 #15
                        Delphi Mac Digest V3 #12
                    More tidbits about Mac II and MPW
                              AI and ELIZA
                          Re: Lisp environments


----------------------------------------------------------------------

Date: Sat, 21 Feb 87 06:36:34 PST
From: halff@nprdc.arpa (Henry Halff)
Subject: Re: DB-9 to DB-25, and every other Apple cable, for that
Subject: matter

Here are is a message from long ago and far away.  Seems the
mailing list could profit from a reposting.

hh

From: p40001@mcomp.UUCP
Newsgroups: net.micro.apple
Subject: Apple Serial Connector Information
Date: 4 May 86 03:04:00 GMT

During the last few weeks I have come across numerous requests for
information about Apple's serial connectors, both on this network and on
others (BIX, Genie, etc.).  I had started compiling a list of Apple's
connectors a while ago, but had not got very far. Then the latest issue of
A+ magazine arrived, and there was all the info I needed.  The following is
a list of Apple Serial Connector Pin Assignments, as well as a chart
listing the major Apple cables and how they are configured.  If you have
any questions about connecting your Apple to some peripheral device, I
encourage you to get that magazine. More info at the end of this file.

Wolf N. Paul
{convex, texsun, infoswx}!mcomp!p40001
BIX: wnp
USPS: 290 Dogwood, Plano, TX 75075.


****           APPLE PIN ASSIGNMENTS              ****

Listing the pin assignments and signal names of
Apple computer and peripheral connectors.

Pins not listed are not connected, unless otherwise noted.

A. RS-232 Interfaces

SUPER SERIAL CARD -- DB25
1   Frame Ground
2   Transmit Data (TXD)
3   Receive Data (RXD)
4   Request to Send (RTS)
5   Clear to Send (CTS)
6   Data Set Ready (DSR)
7   Signal Ground (GND)
8   Data Carrier Detect (DCD)
19  Secondary Clear to Send (SCTS)
20  Data Terminal Ready (DTR)

APPLE //C SERIAL PORTS (both) -- DIN 5-pin
1   Data Terminal Ready (DTR)
2   Transmit Data (TXD)
3   Signal Ground (GND)
4   Receive Data (RXD)
5   Data Set Ready (DSR)

APPLE MODEM 300/1200 -- DB9
2   Data Set Ready (DSR)
3   Signal Ground (GND)
5   Receive Data (RXD)
6   Data Terminal Ready (DTR)
7   Data Carrier Detect (DCD)
8   Frame Ground
9   Transmit Data (TXD)

APPLE PERSONAL MODEM -- Mini-DIN 8-pin
1   Data Set Ready (DSR)
2   Data Terminal Ready (DTR)
3   Receive Data (RXD)
4   Signal Ground (GND)
5   Transmit Data (TXD)
6   Signal Ground (GND)
7   Data Carrier Detect (DCD)

LASERWRITER -- DB25
(See RS-422 section below for LaserWriter DB-9 Connector)
1   Frame Ground
2   Transmit Data (TXD)
3   Receive Data (RXD)
4   Ready to Send (RTS)
7   Signal Ground (GND)
20  Data Terminal Ready (DTR)

IMAGEWRITER I -- DB25
(See RS-422 section below for ImageWriter II Connector)
1   Frame Ground
2   Transmit Data (TXD)
3   Receive Data (RXD)
4   Request to Send (RTS)
7   Signal Ground (GND)
14  Fault
20  Data Terminal Ready (DTR)

APPLE SCRIBE PRINTER -- DB25
1   Frame Ground
2   Transmit Data (TXD)
3   Receive Data (RXD)
4   Request to Send (RTS)
7   Signal Ground (GND)
20  Data Terminal Ready (DTR)

APPLE DAISYWHEEL PRINTER -- DB25
1   Frame Ground
2   Transmit Data (TXD)
3   Receive Data (RXD)
4   Request to Send (RTS)
5   Clear to Send (CTS)
6   Data Set Ready (DSR)
7   Signal Ground (GND)
8   Data Carrier Detect
20  Data Terminal Ready (DTR)

B. RS-422 INTERFACE

MACINTOSH SERIAL PORTS -- DB9
(Old Mac 128/512)
1   Frame Ground
2   +5V *See note below
3   Signal Ground (GND)
4   Tansmit Data (TXD+)
5   Transmit Data (TXD-)
6   +12V *See note below
7   Handshake
8   Receive Data (RXD+)
9   Receive Data (RXD-)
*Note: Apple Computer does not recommend
using these voltages to power external devices.

MACINTOSH PLUS SERIAL PORTS -- Mini DIN 8-pin
1   Handshake Output (HSKo +12V)
2   Handshake Input (HSKi)
3   Transmit Data (TXD-)
4   Frame Ground
5   Receive Data (RXD-)
6   Transmit Data (TXD+)
8   Receive Data (RXD+

IMAGEWRITER II -- Mini DIN 8-pin
1   Data Terminal Ready (DTR)
2   Data Set Ready (DSR)
3   Transmit Data (TXD-)
4   Signal Ground (GND)
5   Receive Data (RXD-)
6   Transmit Data (TXD+)
8   Receive Data (RXD+)

LASERWRITER -- DB9
(See RS-232 section above for LaserWriter DB-25 Connector)
1   Ground (GND)
3   Ground (GND)
4   Transmit Data (TXD+)
5   Transmit Data (TXD-)
8   Receive Data (RXD+)
9   Receive Data (RXD-)

C. SCSI INTERFACE

MACINTOSH PLUS SCSI PORT -- DB25
CAUTION: Do not confuse this connector with
a RS-232 Interface connector!!
1   Request (REQ-)
2   Message (MSG-)
3   I/O-
4   Reset (RST-)
5   Acknowledge (ACK-)
6   Busy (BSY-)
7   Ground (GND)
8   Data Line 0 (DB0-)
9   Ground (GND)
10  Data Line 3 (DB3-)
11  Data Line 5 (DB5-)
12  Data Line 6 (DB6-)
13  Data Line 7 (DB7-)
14  Ground (GND)
15  Carrier Detect (C/D-)
16  Ground (GND)
17  Attention (ATN-)
18  Ground (GND)
19  Select (SEL-)
20  Parity (DBP-)
21  Data Line 1 (DB1-)
22  Data Line 2 (DB2-)
23  Data Line 4 (DB4-)
24  Ground (GND)

Note: The SCSI port uses -5V logic levels; the minus sign in the signal
names indicates negative signal voltage levels.


****         APPLE CABLE GUIDE             ****

ABBREVIATIONS:

SSC = Super Serial Card;   2CS = //c Serial Ports;
IWR = Image Writer I;      IWR2 = Image Writer II;
LWR = Laser Writer;        DWP = Apple Daisywheel Printer
MDM = Modem 300/1200;      PMDM = Personal Modem;
MAC = Macintosh 128/512;   MAC+ = Macintosh Plus

In the following cable descriptions, which are identified as
"Device 1 => Device 2", each group of two numbers indicates a pin on Device 1
and a pin on Device 2 which need to be connected.
I.e., in "SSC => IWR", the notation "1-1" means "connect pin 1 on the SSC
to pin 1 on the IWR".

A. APPLE ][, ][+, //e CABLES

1. SSC => IWR      (Apple Cable # 590-0037)      (See note 1)
  (DB25 => DB25)
   1-1, 13-13, 19-19, 23-23.

2. SSC => IWR2     (Apple Cable # 590-0335)      (See note 1)
  (DB25 => Mini DIN 8-pin)
   1-20, 2-8, 3-2, 4-7, 5-3, 8-7.
   Jumper pins 8 & 6 on DB-25 connector.

3. SSC => LWR      (no Apple cable available)    (See notes 1, 2)
  (DB25 => DB25)
   1-1, 2-2, 3-3, 7-7.

4. SSC => DWP      Identical to #1, SSC => IWR

5. SSC => MDM      (Apple Cable # 590-0212)      (See note 3)
  (DB25 => DB9)
   6-2, 7-3, 3-5, 20-6, 8-7, 1-8, 2-9.
   Jumper pins 8 & 5 on DB-25 connector.

6. SSC => PMDM     (Apple Cable # 590-0331)      (See note 3)
  (DB25 => Mini DIN 8-pin)
   8-1, 20-2, 3-3, 7-4, 2-5, 7-8.
   Jumper pins 8 & 6 on DB-25 connector.

7. SSC => MAC      (Apple Cable # 590-0169)      (See note 3)
  (DB25 => DB9)
   1-1, 3-7, 5-3, 7-20, 9-2.

B. APPLE //c CABLES

8. A2C => IWR      (Apple Cable # 590-0191)
  (DIN 5-pin => DB25)
   1-6, 2-3, 3-7, 4-2, 5-20.

9. A2C => IWR2     (Apple Cable # 590-0333)
  (DIN 5-pin => Mini DIN 8-pin)
   1-1, 5-2, 2-3, 3-4, 4-5, 3-8.

10. A2C => DWP     (Identical to #8, A2C => IWR)

11. A2C => MDM     (Apple Cable # 590-0192)
   (DIN 5-pin => DB9)
    1-6, 2-9, 3-3, 4-5, 5-2.
    Jumper pins 3 & 8 on DB-9 connector.

12. A2C => PMDM    (Identical to #9, A2C => IWR2)

C. MACINTOSH CABLES

13. MAC => IWR     (Apple Cable # 590-0169)
   (DB9 => DB25)
    1-1, 3-7, 5-3, 7-20, 9-2.

14. MAC => IWR2    (Apple Cable # 590-0332)
   (DB9 => Mini DIN 8-pin)
    1-7, 2-6, 3-9, 4-1, 5-5, 6-8, 7-7, 8-4.

15. MAC => MDM     (Apple Cable # 590-0197)
   (DB9 => DB9)
    3-3, 5-9, 6-6, 7-7, 8-8, 9-5.
    Jumper pins 3 & 8 on both ends.

16. MAC => PMDM    (Identical to # 14, MAC => IWR2)

17. MAC => Generic Modem (No Apple Cable available)
   (DB-9 => DB25)
    1-1, 3-7, 5-2, 7-20, 9-3.
    Jumper pins 3 & 8 on DB-9 connector.

D. MACINTOSH PLUS CABLES

18. MAC+ => IWR    (No Apple Cable available)
   (Mini DIN 8-pin => DB25)
    2-20, 3-3, 4-1, 5-2, 8-7.

19. MAC+ => IWR2   (Apple Cable # 590-0340)
   (Mini DIN 8-pin => Mini DIN 8-pin)
    1-2, 2-1, 3-5, 4-4, 5-3, 6-8, 7-7, 8-6.

20. MAC+ => MDM    (No Apple Cable available)
   (Mini DIN 8-pin => DB9)
    1-6, 2-7, 3-9, 4-3&8, 5-5, 8-7.

21. MAC+ => PMDM   (Identical to # 19, MAC+ => IWR2)

22. MAC+ => Generic Modem (No Apple Cable available)
   (Mini DIN 8-pin => DB25
    1-20, 4-7, 3-2, 2-5, 5-3.

E. SPECIAL

23. DB25 => DB25 Modem Eliminator Cable  (Apple Cable # 590-0166)
    1-1, 2-3, 3-2, 4&5-8, 6-20, 7-7, 8-4&5, 20-6.

24. Mini DIN 8-pin => DB-9 Adapter (Apple Cable # 590-0341)
    1-6, 2-7, 3-5, 4-3, 5-9, 6-4, 8-8.
    Jumper pins 1 & 3 on DB-9 connector.

NOTES:

1. The SSC must be in PRINTER mode: triangle on jumper block pointing towards
   TERMINAL, SW1-5 off, SW1-6 on.

2. Requires Xon/Xoff handshaking. SSC SW1-4,6,7 on; SW2-1,4 on.

3. The SSC must be in COMMUNICATIONS mode: triangle on jumper block pointing
   towards MODEM, SW1-5,6 on.


****        CONNECTOR PIN NUMBERS           ****

The numbers shown are for male connectors, and are reversed (left to right)
for female connectors.

A. DB-25

  1    2    3    4    5    6    7    8    9   10   11   12   13
    14   15   16   17   18   19   20   21   22   23   24   25

B. DB-9

  1    2    3    4    5
    6    7    8    9

C. DIN 5-pin

        *
   1         5
     2     4
        3

( * indicates the notch)

D. Mini DIN 8-pin

          *
     6    7    8
    3    4     5
    *  1    2  *

(* indicates the notches in the connector)

WARNING: The above information is provided for your reference only, and no
responsibility is assumed for its accuracy. You are encouraged to verify the
Cable Listings by means of the Pin Assignment listings.

SOURCE and further REFERENCE:

This listing was inspired and greatly facilitated by an article in the
June 1986 A+ magazine: The Right Connections, by Brian Cutter. You are
encouraged  to refer to the magazine article for a lot of helpful hints and
additional information on connecting Apple Computers and peripherals.

Most of the information included was obtained from AppleLink, Apple Computer's
on-line service for dealers.

Further Information can be found in the following books:

Kim G. House & Jeff Marble, THE PRINTER CONNECTIONS BIBLE.
 (Howard E. Sams & Co. Inc., 4300 W. 62nd St., Indianapolis, IN 46268)

Carolyn Curtis & Daniel L. Majhor, THE MODEM CONNECTIONS BIBLE.
 (Howard E. Sams & Co. Inc., 4300 W. 62nd St., Indianapolis, IN 46268)

MICRO MATCH
 (Command Computer Corporation, 36 Columbia Terrace, Weehawken, NJ 07087)

THE APPLE INTERFACE MANUAL
 (Apple Computer, Inc., 20525 Mariani Avenue, Cupertino, CA 95014)

------------------------------

Date: Sat, 21 Feb 87 08:54:05 PST
From: <KINGLEON@humber.bitnet>
Reply-to: KINGLEON%HUMBER.BITNET@forsythe.stanford.edu
Subject: Re: Pinouts for 9 pin socket to db25

I think what you are asking is:"How can I hook up a Hayes compatible
modem to an old-style Mac."

I have a 512K Mac with a (cheap) Alpha-Concord (Hayes compatible)
modem.  My cable connection is as follows:

  MODEM (db25)        MAC (db9)
  2 - REC             5 - TXO
  3 - XMIT            9 - RCD
  5 - CTS             7 - CTS
  7 - GND             3 - GND
Good Luck!

------------------------------

Date: Thu, 19 Feb 87 09:55:05 pst
From: Larry Rosenstein <lsr%apple.csnet@RELAY.CS.NET>
Subject: Re: The Cache and cache bits

In article <8702190809.AA16259@ucbvax.Berkeley.EDU> you write:
>
>INFO-MAC Digest         Wednesday, 18 Feb 1987     Volume 5 : Issue 54
>
>Date: Tue, 17 Feb 87 17:26:28 est
>From: levine@eniac.seas.upenn.edu (Jonathan M. Levine)
>Subject: The Cache and cache bits.
>
>me to suspect that something is amiss with the cache.  Should I not be setting
>the Cache bit on for certain applications?  If so, is there a list of
>applications for which setting the bit is advisable/ill-advised?
>

If you look in ResEdit or FEdit you will see 2 files bits labeled cached
and shared.  (Tech Note #40 describes these bits as well.)  Unfortunately,
the labels of these bits are reversed.

The bit labeled cached tells Finder 5.3 and later to launch an application
in read-only mode (vs. read-write).  The bit labeled shared is currently
unused and reserved.

The next batch of Tech Notes will correct Tech Note #40; presumably later
versions of ResEdit and FEdit will be changed as well.

Larry

------------------------------

Date: 21 Feb 87  0928 PST
From: Tovar <TVR%CCRMA-F4@SAIL.Stanford.EDU>
Subject: BeginUpdate/EndUpdate

Perhaps it's just a matter of style (i don't feel like delving through
Inside Mac in great detail right now), but i feel uncomfortable with
recommending the following:

  GetPort(oldwindow);
  BeginUpdate(window);
  SetPort(window);
  MyDrawWindowRoutine;
  SetPort(oldwindow);
  EndUpdate(window);

I would suggest this instead:

  GrafPtr oldwindow;                  /* Saved copy of previous window */

  ...

  /* Save old grafport, just in case,  and tell QuickDraw about new one. */
  GetPort(oldwindow);
  SetPort(window);

  /* Ask window manager to set visRgn to just that area needed redrawing */
  /* and then restore normal visRgn when we're finished doing redraw.    */
  BeginUpdate(window);
  MyDrawWindowRoutine;
  EndUpdate(window);

  /* Restore grafport.
  SetPort(oldwindow);

It's worth noting here that the type for GetPort and SetPort is NOT a
window pointer, but a pointer to a GrafPort.  It works anyway because
the first field in a window is a GrafPort.  Note that there may well
be some speedup if and when QuickDraw realizes that an operations is a
no-op, but there's no magic involved.  The redraw routine needs to redraw
everything and do those calculations necessary for that.  It might look
at visRgn itself to decide what really is necessary, though.  It also
should NOT take the opportunity to do other updates due to things that
may have happened since the screen was last drawn, unless it is willing
to look at visRgn and perhaps (carefully) adjust.  That kind of update
if it is not entirely inside (or outside) visRgn could result in an
inconsistent display.

Perhaps someone else could explain it better, but it seems to me the major
reason for BeginUpdate/EndUpdate is to make redrawing look better if it
only changes those areas that need changing.  My experience is that if there
is alot of text involved, it isn't subjectively alot faster than redrawing
the whole screen, but is much less distruptive.

While i'm standing on a soap-box, i'll remind people that 'c' is far from
a "self-documenting" language (if such exists); you need to comment your
code.  Besides seeing much too much unscrutible 'c' code, the Mac system
calls often sufficiently inobvious things as to really demand explanation.
When you get to the point of fixing difficult bugs in your own code that
you haven't touched in several years (or had to fix someone else's), then
you'll understand why you should to comment it when you first type it in.

By the way, i've never run across a machine which does window management
in hardware.

------------------------------

Date: Sat 21 Feb 87 11:29:04-AST
From: Peter Gergely <GERGELY@DREA-XX.ARPA>
Subject: Technical Note 106

TN106 cannot be restored using BINHEX without a CRC error.

 Peter

[
I have removed the damaged Tech Note 106 and requested another copy.
Thanks.

DoD
]

------------------------------

Date: 21 Feb 87 11:21:51 EST
From: Jeffrey Shulman <SHULMAN@RED.RUTGERS.EDU>
Subject: Usenet Mac Digest V3 #14

Usenet Mac Digest        Saturday, 21 February 1987    Volume 3 : Issue 14

Today's Topics:
  Re: INFO NEEDED - Kinetics Fastpath Box
  Macput/MacTerminal/Finder problem; has anybody else seen this?
  Re: Making a Mac talk SCSI to a Sun
  Re: Let's do _Launch
  {_FRACTALS
  FKEY for interrupt button
  Re: Shar for the mac?
  Mac PSU (HELP)
  Problem writing a CDEF.
  Initialization in Turbo Pascal
  Re: Making a Mac talk SCSI to a Sun (2 messages)
  Caller Log
  Hard drive comparison
  Re: Pop Up Menus....
  info request - string length function (not len)
  UNIX & LaserWriters (long)
  How to change font size in dialogs?
  Re: UNIX & LaserWriters (long)
  Macintalk
  Re: UNIX & LaserWriters (long)

[
archived as [SUMEX-AIM.Stanford.EDU]<INFO-MAC>USENETV3-14.ARC

DoD
]

------------------------------

Date: 21 Feb 87 11:22:47 EST
From: Jeffrey Shulman <SHULMAN@RED.RUTGERS.EDU>
Subject: Usenet Mac Digest V3 #15

Usenet Mac Digest        Saturday, 21 February 1987    Volume 3 : Issue 15

Today's Topics:
  More on MPW Tool vs. Stand Alone
  icons from MacPascal
  Icon bar Problem in MPW
  Re: Macintalk
  Power-Up failure
  Changing Icons.
  Re: Possible bug in AppleShare, System 3.3/Finder 5.4
  Question on useritems.
  Re: Coral Object Logo
  Jasmine
  Response Summary: Resource Decompiler Wanted!
  Changing plot symbols in Cricketgraph
  Re: Power-Up failure
  Apple: New Machines Break Software (long)
  Mac SCSI disks compatability questions
  Desktop drawing
  Re: UNIX and laserwriters (now VMS and lw's)
  Database for MAC+
  Modems for the MAC and Printer Feeder problems !
  Desktop Publishing and Chess
  MRP Software Wanted

[
archived as [SUMEX-AIM.Stanford.EDU]<INFO-MAC>USENETV3-15.ARC

DoD
]

------------------------------

Date: 22 Feb 87 08:50:49 EST
From: Jeffrey Shulman <SHULMAN@RED.RUTGERS.EDU>
Subject: Delphi Mac Digest V3 #12

Delphi Mac Digest        Sunday, 22 February 1987      Volume 3 : Issue 12

Today's Topics:
  Government Forms on the Mac (6 messages)
  Hardware Help: Human Touch 3 to 1 (2 messages)
  Font Lib/HFS unauthorized
  RE: Investigations into Memory Usage
  Lightspeed Pascal (3 messages)
  MDS Edit 2.0 (2 messages)
  RE: protected files
  RE: TMON with FPD
  Rodime Drives (2 messages)
  RE: Multi-tasking and macDraw error
  RE: help on configuring system with davong
  New Jazz for a New Mac?
  RE: Carrying Case Warning
  Color Transparencies (3 messages)
  The Cache and cache bits.
  RE: non Chicago default font & temporary DA's
  Now I believe it too! (3 messages)
  ChemDraw (2 messages)
  bug
  GAUSS programming language (2 messages)
  RE: Reformatting "dead" Mac disks.
  RE: Icon bar Problem in MPW
  SF + List Manager

[
archived as [SUMEX-AIM.Stanford.EDU]<INFO-MAC>DELPHIV3-12.ARC

DoD
]

------------------------------

Date: Sun, 22 Feb 87 20:56 N
From: <FRUIN%HLERUL5.BITNET@wiscvm.wisc.edu>
Subject: More tidbits about Mac II and MPW

Yesterday, saturday the 21st, VAMP (the Dutch Macintosh Programmers' Group)
had its first real meeting since it was founded last year.  One of the more
interesting things at the meeting in The Hague was a lecture given by Fred
Zuydendorp from Apple.  He was scheduled to talk about MPW, but obviously
some "other" things were discussed too.  Read "other" as "the new Macs".

The talk about MPW was very enlightening, but I won't go into details here
since the information is probably well known to all users of MPW.  Afterwards
some of us played around with it and quickly managed to port a TML Pascal
program to MPW Pascal.  A version 2.0 of MPW exists and will be announced
shortly.  It is especially meant to work with the "other Macs", as Fred put it.

Both new Macintoshes will be announced on March 2nd, although the bigger one
is not being produced yet and won't be shipped for a while.  When Apple first
tried to run some Mac software on their new machine only about 10% would run!
Including some of companies whose software had trouble were Microsoft and
Aldus.  Most problems were caused by bad programming techniques.  As a result
of this the ROMs were changed and Apple expects 80% - 90% of all Macintosh
software to run OK once the machine is released.  They have notified the
developers whose software caused trouble.

Apple has given priority to support of third-party hardware developers and
expects a lot of interesting hardware products (i.e. cards) to come out soon
after the announcement of the slotted Mac.  The announcement is expected to
be a major event.  Apple has even gone so far as to fly executives from some
big companies in Europe to the States for it.

Of course nothing was disclosed on the matter of prices or upgrades.  We'll
just have to wait and see.

P.S.  I'm desperately trying to reach Eric Mazur... does anyone have his
      address?  I have one but my mails simply don't get through.  Can
      someone help?  The address I have is:

        mazur%endor.harvard.edu@harvunxt.BITNET

 Thomas

   FRUIN@HLERUL5.BITNET

------------------------------

Date: Sat, 21 Feb 87 19:19 EST
From: Tom Dowdy              <CML5A9%IRISHMVS.BITNET@wiscvm.wisc.edu>
Subject: AI and ELIZA

Thought that I would pipe up here since I'm in an AI class right now and
just last lecture we talked about ELIZA.  ELIZAs (its really a whole class
of programs) work by recognizing keywords.  This is very simple to do in
lisp with the attribute lists associated with objects and a main event loop
that looks startlingly similar to that which one sees in every mac program.
In any case, the eliza class of programs works by keying on lists of verbs
that are in the typed in list, such as "hate" in the following sentence:
   "I hate computers"
ELIZA can very easily key on the word "hate" and respond with
   "Why do you (hate computers)" (the words in () represent
    words copied from the typed sentence)

While noone knows exactly what AI is, one would be inclined to say that
keyword recognision hardly counts as "intelligence"...  However, when the
user is not hostile (in the case of poor ELIZA most people try to "beat"
the program) keyword recognision goes a long way to providing an
"intelligent" interface.

A classic example of this is the "BlockWorld" program (written at MIT I
beleive) that allows the user to manipulate blocks with a robot arm in an
imaginary world.  The program is able to pick up on reqests such as "Stack
the blue block on the red block" simply by keying on words such as "Stack"
and "on"...A relativly small amount of lisp and a few words can quickly
provide what looks to the user to be a very intelligent machine.  In
reality, most of the words he is typing are being thrown away.

However, while ELIZA (and BlockWorld) are not overly intelligent, they form
the basis for a good chunk of the area known as "natural language
recognition"

If your friend has any questions, they can ask me directly.  (I am posting
this to infomac because it is an interesting topic that may provoke someone
into making a really neat mac program, and because of the similarity to the
mac event loop)

 Tom Dowdy
 CML5A9@IRISHMVS.BITNET

------------------------------

Date: Thu, 19 Feb 87 09:30:20 PST
From: cpd@CS.UCLA.EDU (Charles Dolan)
Subject: Re: Lisp environments

Comments on MacScheme+ToolSmith Version 1.00 Beta

[These are my comment on using the beta test version of MacScheme+Toolsmith
which were sent to the folks at Semantic Micro Systems.  I have removed
some referenceto specific implementation details of MacSchem+Toolsmith.
This is a long, long message.]

My Application

I am implementing a semantic net editing tool on the Mac.  This
implementation in MacScheme+ToolSmith will be the third one, the other
two were in ExperLisp and MacScheme respectively.  In neither of the
two previous implementations have I had sufficient access to both the
ToolBox and the development environment of the implementation language
simultaneously.  I now have a working prototype working which has a
browser window for looking at the concept hierarchy, and which pops up
graphics windows for manipulating the internal definitions of concepts
and text window for changing attributes which are not represented in
the graphical representation.  The knowledge representation which is
being edited is a KL-ONE style representation.

Overall Impression

This product is a very usable interface to the Mac ToolBox.  I was
able to convery my application, which uses the mouse and QuickDraw and
took me 3 months to develop into MacScheme in less than 3 weeks.  I
was also able to add many enhancements because I now had convenient
access to the event queue and menus.

I was more interested in having access to the ToolBox in my
delvelopment environment than in building an application.  However I
am sure that I could easily convert my semantic net editor into a
stand alone application with little effort.

There are still some data type conversion problems which don't seem
like they will be too hard to work out, but I found it terribly
annoying to have to allocate an deallocate data structures in LISP.
Programming the ToolBox doesn't need to be this painful.

I liked the basic structure of the high level interface but I didn't
like the implementation of the object oriented programming.

Data Type Conversion Problems

There will always be a problem here.  This is a Pascal machine and
even C programmers complain about this problem. Here are the what I
view as outright bugs (very few I might add again):

1. [Small bug, easily fixed]

2. [Another small bug, easily fixed]

3. I don't like having to allocate structures all the time, and the
remember to deallocate them. It took me 3 days to find a routine which was
not returning its Mac heap data structures and causing havoc.  The other
problem is that you can't save Mac data structures in the SCHEME.DUMP.  I
always end up allocating a MacScheme data stucture, vector or bytevector,
to hold the data and then stuffing it into a pointer or handle to call the
ToolBox routine, then deallocating the data structure.  This costs me both
in extra coding effort and in execution time.  I have three partial
solutions.

   [The three soloutions are not particularly interesting for this group.]

Little Things

  [This section was a set of five little function or menu command
   I thought should be added.]

Slightly Major Things

These are things for which I know no good solution

1.  How does one deal with ToolBox Routines which want a procedure.
For example, you can't really use TrackControl because you can't pass
it a  procedure.  Perhaps MacScheme could supply a small number of
fixed memory location procedures which would call a Scheme procedure
of your choice.

2. MacScheme doesn't seem to do very well at mouse tracking.  The
response if fine but the garbage collection is awful.  I found one
work around which was to add a handler which removes itself so that I
could get exactly one mouse down event.  I had a problem though when
trying to get a mouse up event, it never came.  Does MacScheme filter
out mouse up events.  This however does not solve the mouse tracking
problem.  If you want to have mouse sensitive objects on the screen,
you are out of luck.

[MacScheme produces garbage even in tight loops used for mouse
tracking because even ToolBox calls produce garbage.  About 5 seconds
of mouse tracking forces a garbage collection which takes from 0.5 to
1.5 seconds on a 2Meg Mac.  The solution I finally adopted was to
write the mouse tracking in asembly language and call it from
MacScheme.]


Object Oriented Programming

[MacScheme does not provide any object oriented programming cababilty
at this time, but object orient programming is very easy to implement
in Scheme.]


Conclusion

Sorry this is such a rambling report, but I didn't have alot of time
to clean it up.  For all my suggestions I think this is a very clean
interface to the ToolBox and I have completely scraped my own
interface in favor of this one.

Thank you for the opportunity of evaluating MacSchem+ToolSmith.

[I have some additional comments on MacScheme.

(1) I have never had a crash which I didn't trace to my own ToolBox
hacking, and I have been using this product daily over 1 year and have
developed over 800K of source code in the environment.

(2) The garbage collector is perfect.

(3) With the very first release of the software, over a year before
Toolsmith, they provided complete documentation on how to access the
ToolBox.  This was great as long as you were willing to hand assemble
all your assembly language functions.

(4) The development environment could stand some help.  It has paren
matching and auto-indent, but no search menu.  Also when loading code,
the compiler is super fast but the reader is very very slow.  It takes
two orders of magnitude longer to read a piece of code than to compile
it after it has been read. (The total time to read and compile a peice
of code is stil comparable to ExperLisp.)

(5) The heap dumping facility is very robust.  Only once or twice in a
year have I been able to do something funny which corrupted the heap
and forced me to re-load from source.

(6) Its a bargain!]

Charles Dolan
cpd@hera.cs.ucla.edu

------------------------------

End of INFO-MAC Digest
**********************