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

INFO-MAC-REQUEST@SUMEX-AIM.ARPA (Moderator David Gelphman...) (11/03/86)

INFO-MAC Digest           Sunday, 2 Nov 1986        Volume 5 : Issue 5

Today's Topics:
              Re: Prob: interpreting Pascal into C -- HELP
                        More on Application Icons
                            Re: MacDraw Bugs
                  Prologs, LISPs, and Unix environments
                            Re: Mac+ pinouts
                               DiskTimerII
                    QUICKSCRIPT 1.1  ( in two parts)
                        Dayton Fonts ( 2 parts )
                        Usenet Mac Digest V2 #89
                        Delphi Mac Digest V2 #56
                  Re: Imagewriters,PowerMath, Switcher
          Re: using Macros to do procedural changes in MacWrite
           Tempo / File Processing / Re: A desktop publ. prob.
             re:MS Word - problems with default paper sizes
                    EMACS-style editors for the Mac+
                           TeXtures on the Mac
                       Colby - Portable Macintosh


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

Subject: Re: Prob: interpreting Pascal into C -- HELP
Date: Sat, 01 Nov 86 20:44:43 +0100
From: Guido van Rossum <mcvax!guido@seismo.CSS.GOV>

A good C implementation on the Mac (e.g., MPW) provides a malloc
implementation which has some advantages over using NewPtr.  Pascal
programs using new/dispose, and C programs using malloc/free, often
allocate and deallocate lots of small blocks.  Having lots of small free
blocks in the heap slows down the Mac's memory manager and causes
considerable overhead (8 bytes per block -- often the blocks themselves
are that small).  The malloc implementation anticipates this behaviour,
and puts many small blocks in one larger block, with only 4 bytes
overhead each (MPW malloc uses 2K blocks).  Thus, it is perfectly OK to
translate Pascal's NEW into C's malloc.

	Guido van Rossum, CWI, Amsterdam <guido@mcvax.uucp>

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

Date: 31 Oct 86 14:43 EST
From: HALLETT JEFFREY A            <HALLETT@ge-crd.arpa>
Subject: More on Application Icons

Sorry to beat a dead horse, but...

   For those of you who missed this before, let me refresh you all:
I am creating icons for applications.  I create the resources and set the
bundle bit and signature using FEdit.  Only, the bundle bit never seems to
be changed permanently.  Once the doc is closed and FEdit is quit, the
new icon never comes up, and when re-opened, the Bundle bit is off again.

   The moderator made a good suggestion, so I tried it.  He suggested that
I create a resourse with the same name as the signature.  I did that, with
no avail; the bundle bit still keeps switching off on me and the Finder
doesn't get the new icon bundled in.

   HEEEEEELPP!

Thanx.
JAH

[ note from moderator: Inside Mac Volume III p. 10-12 has a discussion on
how to make an application use a given ICON and icon list. DAVEG ]

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

Date: Fri, 31 Oct 86 08:38 EST
From: CML5A9%IRISHMVS.BITNET@WISCVM.WISC.EDU
Subject: Re: MacDraw Bugs

I too have many interesting (?) and annoying (!) bugs that
crop up in MacDraw.  High on my list is that the Times font
doesnt appear to do tabs correctly (or should i say at all)
either on the screen or printout.

HOWEVER,
I have heard tales from Apple (and other sources) that the
folks at Apple have done little to no work on MacDraw in some
time.  Why is this you may ask?  Because the code is very convoluted
and confusing and has been patched so many times that nooone
wants to risk introducing new bugs in the process of fixing
the old ones.

If I had to play a guess, either Apple is re-writting Draw
from scratch or just aren't going to do anything to it and
let other companies fill the niche.

Just an opinion.

-Tom Dowdy
 CML5A9@IRISHMVS.BITNET
"I am increasingly of the opinion that a vast majority of
 wrong thinking people are right."

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

Date: Sat, 1 Nov 86 06:31:26 PST
From: Phil_Winne%SFU.Mailnet@MIT-MULTICS.ARPA
Subject: Prologs, LISPs, and Unix environments

  We are beginning a 3-year project to develop an expert planning system
to help teachers plan and analyze lessons.  We hope to use the (hopefully)
soon-to-be-announced open architecture Mac for a delivery machine following
development on a SUN 3.  I'd appreciate information anyone can provide about
Prologs, LISPs, and Unix presently available and under development for Macs,
including accurate assessments of their advantages and faults.  Please
include address for the distributor and price if known.
  Dr. Phil Winne
  Instructional Psychology Research Group
  Faculty of Education, Simon Fraser University
  Burnaby, B.C.   V5A 1S6   Canada
           or
  USERPWIN@SFU.Bitnet

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

Date: Thu, 30 Oct 86 19:25:00 EST
From: Martin Resnick <mlr0%gte-labs.csnet@CSNET-RELAY.ARPA>
Subject: Re: Mac+ pinouts


The pinouts for the new serial ports, SCSI connector, Peripheral-8 cable
and the Mac+ Adapter Cable are described in Tech Note #65.

There is a description of the Mac+ SCC and SCSI interfaces in Volume IV of
Inside Macintosh (Chapter 28  Mac+ Hardware).

Tech Note #10 lists the pinouts for most of the other Macintosh related
hardware: DB-9 serial and mouse, keyboard, external drive, XL serial A & B,
Apple 300/122 modem, Imagewriter DB-25, and LaserWriter DB-9 & DB-25.
It also covers various cables: Imagewriter, Modem, Mac to Mac, External drive,
XL null modem and Mac to IBM PC.

Chapter 2 of Inside Macintosh Volume III describes the non Mac+ hardware
and pinouts.

The Tech Notes are available in the INFO-MAC archives on Sumex.  They can also
be ordered from APDA (back issues and new subscription).

(APDA = Apple Professional Developer's Association. APDA info is on Sumex also.)

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

Date: 2 Nov 86 14:36:42 EST
From: Jeffrey Shulman <SHULMAN@RED.RUTGERS.EDU>
Subject: DiskTimerII

[ Uploaded from Delphi by Jeff Shulman ]

Name: DISKTIMERII
Date: 2-NOV-1986 07:13 by BRECHER

DiskTimerII -- replaces DiskTimer.  Hard disk performance benchmark.  Does not
alter contents of disk.  Please report results to BRECHER.  HyperDrive users
note:  the access time test is valid only if DiskTimerII is run from a drawer
which is greater than 1MB in size and *contiguous*.  The test can take a few
minutes -- maybe up to 10 for slower (non-SCSI) disks.

[ archived as

[SUMEX-AIM.Stanford.EDU]<INFO-MAC>UTILITY-DISKTIMER-2.HQX

DAVEG
]

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

Date: 2 Nov 86 10:39:11 EST
From: Jeffrey Shulman <SHULMAN@RED.RUTGERS.EDU>
Subject: QUICKSCRIPT 1.1  ( in two parts)

[ Uploaded from Delphi by Jeff Shulman ]

Name: QUICKSCRIPT 1.1
Date: 1-NOV-1986 19:42 by LARRYZ

QuickScript is a post-processor that turns a specially formatted Microsoft Word
document into a professional quality video production script.  Both audio and
video segments are lined up no matter their length in two column format.
Segments are auto-numbered and elapsed time is calculated automatically.
Shareware fee is $30 to Dantz Software Development in Berkeleley, Californaia.
QuickScript was written by Richard C. Zulch.

[ archived as

[SUMEX-AIM.Stanford.EDU]<INFO-MAC>UTILITY-QUICKSCRIPT-11-PART1.HQX
[SUMEX-AIM.Stanford.EDU]<INFO-MAC>UTILITY-QUICKSCRIPT-11-PART2.HQX

These two parts must be joined together before unbinhexing

DAVEG
]

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

Date: 2 Nov 86 14:35:53 EST
From: Jeffrey Shulman <SHULMAN@RED.RUTGERS.EDU>
Subject: Dayton Fonts ( 2 parts )

[ Uploaded from Delphi by Jeff Shulman ]

Name: DAYTON FONTS
Date: 1-NOV-1986 12:30 by APPLEDAYTON

These fonts are a very complete set of mathematical fonts (bitmapped).  They
were formerly shareware, the author has released them for free distribution.
See the file ReadMeFirst for restrictions.

[ archived as

[SUMEX-AIM.Stanford.EDU]<INFO-MAC>FONT-DAYTON-PART1.HQX
[SUMEX-AIM.Stanford.EDU]<INFO-MAC>FONT-DAYTON-PART2.HQX

These two parts must be joined before unbinhexing.
DAVEG
]

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

Date: 1 Nov 86 13:48:58 EST
From: Jeffrey Shulman <SHULMAN@RED.RUTGERS.EDU>
Subject: Usenet Mac Digest V2 #89

Usenet Mac Digest        Saturday, 1 November 1986      Volume 2 : Issue 89

     (wanted) software to make PostScript from plain text files
     (wanted) a way to spool PostScript files through a VAX
     Re: Password protection for HD20
     MacDraw Bug
     Mac penetrates corp. world (Was Re: New Apple ad campaign)
     TML Pascal ver 2.01 bug
     Stat80
     Our Lisa's problem disk
     Imagewriter II compatible printers on Mac+
     Re: (wanted) software to make PostScript from plain text files
     Re: What's Nu with VME for Mac?
     Re: Command Keys for Openning Desk Accs.
         (Was: Changing Fonts from the keyboard)
     Patch cursor shape in MacKermit 0.8(34)?
     Re: Lisp on Macs
     Edit ver2.0
     Changing a grafPort's portBits?
     Driving a plotter from a MAC
     Re: What's Nu with VME for Mac?
     Re: TML Pascal ver 2.01 bug
     Software Project Management (a compendium)
     graph-drawing program wanted
     Re: What's Nu with VME for Mac?
     Re: Delphi Digest V2 #55
     Re: WORD fonts

[ archived as

[SUMEX-AIM.Stanford.EDU]<INFO-MAC>USENETV2-89.ARC

DAVEG
]

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

Date: 1 Nov 86 23:57:54 EST
From: Jeffrey Shulman <SHULMAN@RED.RUTGERS.EDU>
Subject: Delphi Mac Digest V2 #56

Delphi Mac Digest          Sunday, 2 November 1986      Volume 2 : Issue 56

Today's Topics:
     RE: Usenet Mac Digest V2 #88 (Re: Msg 14313)
     RE: PhoneNet/LaserWriter+ problems (Re: Msg 14319) (4 messages)
     Finder/many-file copy bug? (6 messages)
     Word 3.0, Intro. (5 messages)
     RE: TRS-100/102 <-> macintosh
     RE: Word / WriteNow (Re: Msg 14300) (2 messages)
     MPW C (Green Hills) "feature" (10 messages)
     RE: Dataframe Squeal (Re: Msg 14316)
     RE: TeX (Re: Msg 14163) (2 messages)
     RE: what do people think of the max-2 memory expansion?
     Macsbug (2 messages)
     How to reboot your Mac and Hard Disk (qu
     RE: LightSpeed C/Loadseg hangs! (Re: Msg 940)
     Apple's interface

[ archived as

[SUMEX-AIM.Stanford.EDU]<INFO-MAC>DELPHIV2-56.ARC

DAVEG
]

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

Date: Thu, 31 Oct 1986 11:15 CST
From: PHYS300%UNLCDC3.BITNET@WISCVM.WISC.EDU
Subject: Re: Imagewriters,PowerMath, Switcher

Not being too organized as of late (it must be the stack of papers on
my desk that need grading :-) ), I haven't responded to some queries
on this sig in a timely fashion.  Anyway here are a few of mine comments
for what they are worth:

Re: Imagawriter II vs. I.  I was very disappointed with the II as compared
with the I.  My output just was not dark enough.  I eventually took it
to a dealer for servicing.  He told me that there was an engineering defect
in many earlier ones that required a shem (shim?) kit from Apple to fix.
He installed it and now everything works fine.  The output is nicer than that
of the I.  I have Applecare so I don't know what the repair cost, but one
person indicated that it was free from Apple since it was their defect.

Re: Computer algebra programs on the Mac (a USENET query).  I have used
the program POWERMATH that was mentioned by someone.  (I have forgotten the
producers of it.)  I was quite disappointed by it.  It was a nice toy with
a good Mac interface, but there is no power in it, despite its name.  My
biggest complaint is the lack of control structures.  There is no looping
possible, no if-then constructs.  Only simple, one-line function definitions
are possible.  I was not expecting a program like MACSYMA of course.  But
I was hoping for something more like muMath for the IBM PC.  In its present
form I would not recommend it for any serious work.

Next is a query of my own.  I am using Switcher 5.01B on an 512E Mac.  It
occasionaly bombs on me.  I seem to remember complaints earlier about the
incompatiblity of Switcher and the disk cache.  I usually turn off the
cache when using Switcher but it doesn't always help.  The machine still
hangs and funny things happen to the screen.  Is there a newer version of
Switcher out that works reliably with or without the cache?

And finally, I want to say that I really enjoy reading this sig.  The
moderator is doing an excellent job.  (Now can I get my message sent?? :-) )

Glenn Sowell <PHYS300@UNLCDC3.BITNET>
Dept. of Physics & Astronomy
University of Nebraska - Lincoln
Lincoln, NE 68588-0111

(402) 472-2790

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

Subject: Re: using Macros to do procedural changes in MacWrite
Date: 31 Oct 86 11:12:01 EST (Fri)
From: "Steven B. Munson" <sbm@purdue.edu>

     Actually, there is nothing wrong with WYSIWYG editors, but the
people that write them are too narrow-minded to include macro
capabilities in them.  No editor will ever have enough features for
everybody until it contains a universal programming language.  This
requires giving names to all the functions you do with the mouse and
menus, so that they can be done in a textual program, along with if,
case, for and while statements.  I am still waiting for someone to do
this, although MEdit came pretty close (a nice text editor, except that
it cannot handle tabs).

     In addition, word processors need to have a different kind of macro
which is represented in the document as a call to the macro and is only
expanded when the document is formatted on the screen or on the printer.
This is the kind of macro we are probably all used to seeing in troff,
which allows, for example, subheadings all to be displayed the same way
and to change all at once when the subheading macro is changed.  I
imagine at least some of the new Mac word processors have this kind of
macro.

     The universal characteristic of Macintosh programs seems to be that
they are narrow-minded.  How can MacWrite call itself a word processor
if it can't even do overstrikes?  Would that I had enough time to write
all my own software.

					Steve Munson
					sbm@Purdue.EDU
					sbm@Purdue.CSNET

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

Date: Fri, 31 Oct 86 23:52 PST
From: "Skinner Darr"@LLL-MFE.ARPA
Subject: Tempo / File Processing / Re: A desktop publ. prob.


Tempo / File Processing / Re: A desktop publ. prob.

  Tempo macros can easily be used to reformat all lines in a file.  I
often use Tempo macros to massage things listed to my Mac-as-a-terminal
into another form which I then feed back to Mac's big brothers.  More
about that later, but first, here was the problem recently posted:

>   Date: Mon, 27 Oct 86 16:32:11 pst
>   From: Mike Wirth <mcw@lll-crg.ARPA>
>   Subject: A desktop publishing problem
>
>   I have a fixed-format text file on the Mac (125 char. per line,
>   followed by a carriage return), downloaded from a host computer
>   ...each line has (in fixed columns) a name, an extension,
>   a room number, a secretary's name, etc.
>   What I want to do is to "prepare" this file (change certain fonts
>   so that I can publish a company phonebook
>   that looks better than the current lineprinter listing.....
>   ...
>   What about using Tempo to format one line in MS Word, then turning
>   it loose on the rest of the file.  Is it smart enough
>   to keep track of character positions within a line?

   When you use Tempo to iteratively reformat something, you MUST design
a macro around the central fact that Tempo macros work on absolute
screen positions.  Whatever you do to fields in the first line as you
generate the macro, you must arrange text in all subsequent lines so
that the same fields lie in the same horizontal positions in the window.
Then, your macro must somehow scroll the lines through the window, since
all the action will be taken on the same line position(s) in the open
window.

   Handling the columns in this phone directory problem is not very
hard.  In an editor such as Macwrite, the text must initially be in a
nonproportional font (e.g., Monaco).  The Tempo macro could easily
change this, though.  For example, you could insert a tab at the right
of a field which sets the rest of the line on fixed positions, then
drag-click the field and change it to any font (and size and other
characteristics) by menu selections.

   I have settled on the following method to scroll through lines.  It
works identically in all the editors I normally use.  First, I add a
blank line at the very end.  Then I position the beginning of the file
in the window, and add blank lines at the beginning until the first
line of the file is positioned at the bottom of the window.  I massage
this first line, making the Tempo macro as I go.  Then -- here is the
trick -- I click at the beginning of the line and hit Return and then
Backspace, which moves the next line up into position.  The 125
char/line in the directory would probably be wrapped into two lines.
The macro for this problem would have to work over two lines in the
window before being iterated, which would complicate things only
slightly.

   You would finish making the Tempo macro by choosing the "Repeat for"
(some number greater than the number of lines in the file) option.  When
the new Tempo macro is invoked, the rest of your file will be (slowly)
transformed.  When finished, Tempo will endlessly mangle the last line
until you type <command-.> or the "Repeat for" is satisfied.  (Actually,
Tempo provides a "Repeat until" option which could terminate in a more
sophisticated way, for example, by terminating macro processing at the
first blank line.)

   Once you start thinking this way, you can do all sorts of transformations.
For example, if you have a file containing a list of words, you can
combine them several words to a line.  You can keep bumping words up into
the bottom screen position and cutting them, adding them to the next-to-
the-bottom line.  When it is full, you open a new line and bump things
so that the next word appears at the bottom line.  A chunk of work like
this which leave things positioned in a window just as at the beginning is
the basic unit of a Tempo iterative procedure.

   Mainly I use my Mac as a "terminal" for bigger computers.  I use the
Mockwrite window as a scratch space, where I constantly copy output from
the mainframe or complicated command strings I'm current using.  I
manipulate that text, copy it, and "paste" it back to the mainframe in
the terminal emulator window.  Red Ryder has enough options (Ascii
upload options govern the pasting) that I am able to safely (but again,
slowly) paste/upload multiple line selections to even the klutziest
mainframe software.  My Mockwrite window is always open. I used Resedit
so that Mockwrite opens a thin horizontal strip (even thinner than you
can make it with the mouse and size box) positioned at the top of the
terminal emulator screen and abutting the left edge of the physical
screen.  A tiny strip always is visible to the left of the terminal
screen, so I can bring this scratchpad strip forward by just clicking
at the upper left edge of the screen.  If the mainframe is sending stuff
at me, I can work in the Mockwrite area while text scrolls past below.
I have found Tempo a very useful tool for some of the things I do to
text in this Mockwrite window.  A Tempo macro can also transfer
material back and forth between two or more windows (Mockwrite and Red
Ryder, for example, or windows of a multiple-window editor, or DAs'
windows and an application's windows) as it scrolls the windows and
transforms/combines/separates out fields.

   I have never tried this, but you might be able to do character-
oriented editing under Tempo.  You would need some Emacs-like editor or
some other character editor which lets you can use keyboard commands to
do all positioning and text selecting.  Tempo would record those
keyboard commands along the with any dropdown menu commands.

   Darrell Skinner
                 (Disclaimer:  I've no connections to Tempo,
                  (other than as a sort-of satsified owner)
                  or, unfortunately, to other $-making software)

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

Date: Fri, 31 Oct 86 10:04:37 n
From: <LANGOWSKI%FREMBL51.BITNET@WISCVM.WISC.EDU>
Subject: re:MS Word - problems with default paper sizes


Re: Problems with MS Word
In general, creating a startup document with the desired settings helps
with many Mac applications. Not so with _stupid_ MS Word. It will startup
any document that you've created in US letter, vertical orientation, no
matter what settings you've used.

Since our lab received copies of MS Word with the US-default Imagewriter
file on it (and Finder 1.1g - can you believe it?), and we're mainly using
the US keyboard but DIN A4 size paper, no wonder the Mac installation has
its teething troubles. Especially since people really expect to have a
disk that they can plug in and use, without having to grab for some other
master disk, so in addition you have to think of a hack to get the MS Word

protection file on an HFS volume...
There are several ways to change the default printing setup, so that even
MS Word will acknowledge it:

a. copy a German- or French-version Imagewriter file on your MS Word
working disk. MS Word seems to always take one particular paper size from
the PREC resource (#3?) in the Imagewriter file. From those other versions,

it'll take the A4 as a default. Disadvantage: you end up with a bilingual
system unless you change the dialogs in the Imagewriter file as well.

b. use the PREC installer (from Quick and Dirty Utilities, by Dreams of
the Phoenix, Inc., P.O.Box 10273, Jacksonville FL 33247, (904) 396-6952)
which will allow you to create any paper size and put it into the PREC
as you like.

Still there is no way to make MS Word display a horizontally-oriented
document with the correct page settings when you reopen it... you always
have to reset them by hand. Microsoft, please take note for your next
update.

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

Date: 2 Nov 1986 07:10-EST
From: Vijay.Saraswat@k.cs.cmu.edu
Subject: EMACS-style editors for the Mac+

Having lived for years on UNIX and TOPS-20 EMACS, I find it very
inconvenient to have to do all my editing on a MAc+ using a WYSIWYG like
MacWrite. Is there something remotely resembling an EMACS available on
these machines? At the very least, I would like to have facilities for
at least two windows up on the screen, multiple buffers, keyboard
macros, keyboard commands for everything e.g. scrolling and searching
(forward AND reverse),  smart "modes" (TeX, Lisp), invoking programs
from within the editor, collecting their output in a buffer...

If there are already any products out there that fit the bill, I'd be
real glad to have some pointers. If someone is working on such a
product, I would like to find out about  it.  Am I the only one who
prefers EMACS style editors, or are there others like me?

Vijay (saraswat@k.cs.cmu.edu.arpa)

[ note from moderator:  There is a version of EMACS available for the
Mac and it is archived as   MICROEMACS-BETA-0PT6.HQX. I can't comment
about the completeness of the implementation but it certainly is worth
having a look at.  DAVEG ]

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

Date: 31 Oct 86 15:22:00 EST
From: <bouldin@ceee-sed.ARPA>
Subject: TeXtures on the Mac
Reply-to: <bouldin@ceee-sed.ARPA>

There have been requests here for comments on TeX on the Mac. Based on
about 2 hours use of TeXtures (it arrived today) here is what I can say.
I immediately downloaded a TeX file from the vax 780 and ran it thru
TexTures. Input file was a 26 page physics paper and fairly heavily
mathematical.

Time to TeX 26 pages was about 4:30, or just about 10 secs/page. Time on
the vax (moderately loaded) was about 1:20. _Total_ vax time, that is,
from input of .tex file to having laserprinted output in my hands so I could
start doing corrections, etc, was 7:30. So the Mac allows you to start seeing
your ouput almost twice as fast as the vax.

It is trivial to open the .tex input window and typesetting output window so
that you can find errors in the typeset window and correct them in the .tex
input window. I think that this would speed up the initial iterations on
a manuscript far more than just the above comparison of vax:mac execution
times indicates.

The preview is excellent. I use the 'actual size' preview mode where you can
just see the full horizontal extent of a line on 8.5" paper without hor.
scrolling. Characters are readable, as are sub and superscripts. Sub-subscripts
and super-super are not, but if you hold down the mouse button the cursor
switches to a 1 sq. in. 'magnifying glass' with full laserprinter resolution.
The magnify is so fast that it almost seems to be realtime.

I rate this implementation of TeX as somewhere between excellent and awesome.
I could really have used this when doing my thesis.

Caveats:
1. this is running on a 1 meg Mac+ with 20 meg HD.
2. TeX plus fonts plus example files is 1.6 megs on disc. This can be cut down
   for use on floppy systems, but I don't know how much.
3. Even K&S admit that TeX will not run as well in a 512K mac. I will test
   this tonight on my 512E.
4. As I said, this is based on about 2 hours use. For example, pasting
   in Mac graphics via the \special command is supported and an example
   file is included, but I haven't tried it yet.
5. Sorry, but I can't compare this with the FTL product, MacTex, since
   I haven't seen it.
6. This is based on the 0.92 pre-release of TexTures.

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

Date: Fri, 31 Oct 86 16:15:43 PST
From: gunther.pa@Xerox.COM
Subject: Colby - Portable Macintosh

According to InfoWorld, Colby Systems of Fresno, CA planned to
demonstrate a portable Mac at the MacWorld Exposition a couple of weeks
ago.  It is due to be available by early '87.  They are currently
negotiating with Apple for parts.

Did anyone see it or does anyone know anything more about it?

 Neil.

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

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