[fa.info-mac] INFO-MAC Digest V3 #22

info-mac@uw-beaver (07/16/85)

From: Temporary Moderator Rich Alderson <INFO-MAC-REQUEST@SUMEX-AIM.arpa>


INFO-MAC Digest          Monday, 15 Jul 1985       Volume 3 : Issue 22

Today's Topics:
                                Re: OPS5
                         LaserWriter header file
                             Bug in MacDraw
                              Mac failures
                              Red Ryder 5.0
           Using Brother typewriter as Mac printer, a request


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

Date: 14 Jul 1985 23:30-EDT
From: George.Wood@CMU-CS-G.ARPA
Subject: Re: OPS5

I brought up OPS5 in Common lisp (based on Charles Forgy's franz lisp
version) and have maintained it for the last year.

The CMU common lisp OPS5 SOURCE is about 217 vms blocks (i.e. 108 k),
and compiles to a fasload file of about 230 blocks (in vax/vms common
lisp).  While I do not know how big the common lisp for MAC is, it
seems unlikely that any serious development could be done in what's
left of 512 k. This is because ops compiles rules into a
discrimination network, trading memory for time (a reasonable strategy
on a machine with virtual memory--and 20 meg of physical memory
available).

As an example I have appended some statistics garnered by loading a
VERY small production system. The system, a tic-tac-toe game, consists
of 27 rules.

In sum, loading and playing a single round of tic-tac-toe used 782
pages (i.e.  391 K), over and above that used by lisp and the ops
interpreter itself.

The complete log is in /usr/gdw/TTT.LOG on CMU-CS-G

----- begin attached log summary -----

 Dribbling to SYS$USER:[GDW]FOO.;1
 ()
 CLops: (room)

 Dynamic-0 Storage Total Size: 2973, Current Allocation: 1249, Free: 58%

 CLops: (load '[gdw.opsl]ttt)
 ; Loading contents of file SYS$USER:[GDW.OPSL]TTT.LSP;1
 ***************************
 ; Finished loading SYS$USER:[GDW.OPSL]TTT.LSP;1
 T
 CLops: (room)
 Dynamic-0 Storage Total Size: 2973, Current Allocation: 1511, Free: 49%

 CLops: ; NOTE -- 27 rules, 262 pages used in loading
 (make ready)
 ()
 CLops: (room)

 Dynamic-0 Storage Total Size: 2973, Current Allocation: 1546, Free: 48%

 CLops: ; 1 wme made, 35 blocks used
 (run)

 ; remaining game excised from log

 end -- no production true
  27 productions (209 // 523 nodes)
  59 firings (114 rhs actions)
  14 mean working memory size (17 maximum)
   5 mean conflict set size (15 maximum)
  60 mean token memory size (99 maximum)
 ()
 CLops: (room)

 Dynamic-0 Storage Total Size: 2973, Current Allocation: 2031, Free: 32%

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

Date: Fri, 12 Jul 85 15:23:41 edt
From: Alan Crosswell <alan%cucca@columbia.arpa>
Subject: LaserWriter header file

Here's a copy of version 12 of the Apple LaserPrep file which has been
decompiled with rekamr and cleaned up some for downloading via RS232.
It is not commented like Brian Reid's version 13 one is; I use Brian's
one whenever I try to figure out what is going on.

First, some new things I've learned since my last posting:

EEXEC and the PSHX resource

The mysterious "eexec" command IS documented, but not in Inside
LaserWriter.  It is only documented in Adobe's PostScript manual in
the Printer Fonts appendix on pages 146-7 (which is not included in
ILW).  (Thanks to Guy Riddle for pointing this out to me.)  Eexec
executes encrypted code.  Eexec reads the next line and following up
to EOF so you can't follow it with any more PostScript commands (maybe
-- you may be able to explicitly open %stdin but I'm not sure...).

It turns out that the hex does contain the "smooth" function as I had 
suspected.  I don't know what else it may contain if anything.  So, if
you do want the smoothing function (for MacPaint bitmaps or anything
else that invokes "dobits") then you will have to install the "md"
dictionary in the machine's permanent VM so that it will be available
to subsequent jobs.  This is because eexec eats up everything up to
the EOF as stated above.  If you're going to be using this stuff,
that's probably the prefered method anyhow since it saves you the time
and trouble of sending the "md" dictionary down with each job.

Doing it with Scribe

Michael Fryd sent me some mail saying he had a version of Laser prep
that almost worked with Scribe and that he would be getting back with
more info shortly.  Apparently, Unilogic has expressed some interest
in doing whatever is necessary to support sticking Mac pictures in
with the @picture command.  Meanwhile, here's what I've discovered:

The PostScript preamble use by Scribe is defined in the
DeviceInitialization in POSTSC.DEV.  This means you can go in and
modify the definitions if you need some feature not currently
provided.  A feature that immediately comes to mind is to have the
size of the picture box available to the picture code that gets pulled
in so that it can scale the picture to fit inside the box.

The @picture(size=nn,ScaleableLaser="foo.ps") command generates the
following PostScript:

        size x y PB
        <<foo.ps included here>>
        PE

The PB macro does a "save" of the current state into the variable PV
and then does a "translate" to set the picture origin.  The three
arguments are integers giving the size, and (x,y) position of the
bottom left corner.  The size is currently not used by PB; It gets
discarded (popped).

The units used appear to be points * 100.  For example, giving a
"size= 7 inch" results in 50400 on the stack (7 * 72 * 100).  I guess
they multiply points by 100 so all can be done as integers (this is
all done by a CVTXY macro).

PE just does a "PV restore" to restore Scribe's state.

The LaserPrep file
[is archived in [SUMEX]<INFO-MAC>LASERWRITER-12.POSTSCRIPT.  --RMA]

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

Date: Mon, 15 Jul 85 07:32:15 pdt
From: preese%ucblapis.CC@Berkeley
Subject: Bug in MacDraw

Has anyone else run into this bug in MacDraw?

 1. Draw a vertical line and place a single arrow head on one end.
 2. Select and copy to clipboard.
 3. Paste into the scrapbook.
 4. Copy the line from the scrapbook.
 5. Paste back into MacDraw.

Interesting result.  Any known fixes or work arounds?  Apple, will
this be fixed?

Phil Reese

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

Date: Mon, 15 Jul 85 07:32:15 pdt
From: preese%ucblapis.CC@Berkeley
Subject: Mac failures

Over the past year we have taken delivery on some 35 512k Macs.  Of
these we have had to have service on 7 machines.  Two were old macs
that had been upgraded, two failed after less then two months use and
three failed right out of the box (within 48 hours of being on).
*ALL* failed with power supply/video board problems.  We like the Mac
but hope that the service record improves.  (My arms grow long
carrying Macs back and forth accross campus.)

Phil Reese

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

Date: Wed, 10 Jul 85 7:40:54 EDT
From: Robert E. Yellen (MISD-SEAD) <ryellen@Ardc.ARPA>
Subject: Red Ryder 5.0

This file was created by packing each individual file with PackIt then
runing the packed file through BinHex4.0

The PackIt file consists of:

 1. Red Ryder 5.0 application program
 2. Red Ryder Doc # 1
 3. Red Ryder Doc # 2
 4. Red ryder Doc # 3
 5. Red Ryder Doc # 4

note the document files are MacWrite 2.2 files.

Red Ryder 5.0 is written by Scott Watson of FreeSoft Company. Red
Ryder is a user-supported asynchronous communications package for the
Apple Macintosh having at least 1 disk drive and 128 k memory. You
have 45 days to evaluate the package and if at the end of that time
you decide to continue to use it, you should register your copy for
$40.

The four MacWrite files contain complete documentation and
registration information. (33 pages)

[The BinHex 4.0 file containing the results of PackIt as described
above is archived in [SUMEX]<INFO-MAC>RED-RYDER-5.HQX.  Note that this
file is more than 198,000 bytes in length, and plan your transfers
accordingly.  --RMA]

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

Date: Sat 13 Jul 85 23:56:36-PDT
From: Frank Chen <Frank@SU-CSLI.ARPA>
Subject: Using Brother typewriter as Mac printer, a request

I am interested in knowing if it is possible to use a Brother
COMPACTRONIC-58 electronic typewriter as a printer for the Mac.  The
CE-58 is a daisy wheel typewriter with 3K memory.  I already have the
Brother IF-50 external interface unit (which has 2K buffer memory and
an RS232C serial port), which allows the typewriter work as a printer
for several other (non bit-map) computers.

I have seen a Macintosh daisy wheel converter at a local computer
store.  Would getting that in addition to the IF-50 make printing with
the typewriter possible?  Or perhaps I just need to configure the
IF-50 correctly?  I have no idea how to set this up, but I was just
thinking it would sure be nice to be able to make my typewriter serve
as a printer for my Mac (kinda in-between an ImageWriter and a
LaserWriter).

If you have successfully gotten this to work, or know for a fact that
this is utterly impossible, please reply to FRANK@SU-CSLI.ARPA.
Thanks!

-Frank

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

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