[mod.mac] Delphi Mac Digest V2 #45

SHULMAN@RED.RUTGERS.EDU (Jeffrey Shulman) (09/15/86)

Delphi Mac Digest          Monday, 15 September 1986      Volume 2 : Issue 45

Today's Topics:
     FileMaker Plus multi-valued fields
     RE: DataFrame, the first impression. (Re: Msg 12698)
     RE: Carrying cases for Mac and hard disk (Re: Msg 12678)
     RE: Assimilation MIDI problem
     RE: Problems with MORE
     RE: XLISP 1.6
     RE: MacDraw, bitmaps, and the LaserWriter
     RE: Model 100 formatting program
     RE: DataFrame 20 fixes
     Silicon Valley Expo
     Desktop Pub Expo followup
     RE: Copy Perversion Hall of Shame (Re: Msg 12588)
     RE: quickdraw 3-d (Re: Msg 12589) (3 messages)
     Servant .79
     RE: TextEdit Bugs & printing to laser printer from program
     RE: Prologs for the Mac (Re: Msg 12668)
     Problem with STR# vs. readability (3 messages)
     Disks / Drives
     Database applications (2 messages)
     2 Megabite Upgrades (2 messages)
     MacLightning
     Macs and a Cray
----------------------------------------------------------------------- 

From: MACINTOUCH (12689)
Subject: FileMaker Plus multi-valued fields
Date: 11-SEP 20:34 Business Mac
 
FileMaker Plus is a very nice product.  One of its features is something called
"repeating" fields, which are actually stored as multi-valued fields.  (You can
do calculations on these fields, such as sum and count, and they're ideal for
forms such as an invoice listing a number of items in one sale.)
 
If you save this data as text, there is a strange, non-printing character that
separates the values in a multi-valued field.  Has anyone figured out what the
character is?
 
Ric
 
------------------------------

From: INC (12701)
Subject: RE: DataFrame, the first impression. (Re: Msg 12698)
Date: 11-SEP 23:11 Hardware & Peripherals
 
Just some more info on the Dataframe...
 
I just had the PrintSpooler trash my system file.  Very nice.  I would
stay away from 1.2 and sources at SuperMac say that it's already way
out of date and a new one is soon to follow with backup software that
they've purchased from FWB software, makers of HD Util.
 
just some more stuff, without the fluff.
 
josh
MacInTouch
 
------------------------------

From: NANOCHIP (12708)
Subject: RE: Carrying cases for Mac and hard disk (Re: Msg 12678)
Date: 12-SEP 18:52 Mousing Around
 
Don>
If you only need to tote your Mac for short distances I highly recommend
the "Take Cover" (tm) Mac Carrying case from Tacklind Design of Palo Alto CA.
(415) 322-2257. I bought one at MacExpo for 35$. It is a gas!
  What is is basically, is a high quality nylon dust cover with side pockets
for the keyboard, which stands on it's end (Mac+ board fits just fine!)
and for an 800K drive; or a rear pocket for a 400K drive (the drive pocket
you don't use is for storage of power cord and mouse). The user carries the
Mac by the it's stock handle. A shoulder harness is not an option. This
unit is *perfect* for short hops though, since the Keyboard, Ext. Drive, Mouse
and Power cord are NEVER DISCONNECTED!!! I'm in love with it. I packed up
my Mac+ and was out the door the other nite in <2 1/2 minutes! Great Product!
<Chip
 
------------------------------

From: BMUG (12718)
Subject: RE: Assimilation MIDI problem
Date: 13-SEP 00:07 Network Digests
 
 To: gossc@acf2.UUCP (Clint Goss)
 Re: Assimilation MIDI problem
 
Most MIDI experts that I have talked to DO NOT recommend using the Assimilation
Process MIDI device because:
 
 >> Unlike all the rest, it is NOT opto-isolated
 >> It needs power, so it won't work without special cabling on the Mac+
 >> The company that put it out is out of business (last I heard)
 
-- Raines / BMUG
 
------------------------------

From: BMUG (12719)
Subject: RE: Problems with MORE
Date: 13-SEP 00:14 Network Digests
 
 To: ix21@sdcc6.ucsd.EDU (David Whiteman)
 Re: Problems with MORE
 
At last night's BMUG meeting, someone in the audience warned about
another MORE problem... if you have a big outline, and you HOIST a
topic several levels, you may get a crash ID=02 or 03 immediately
AFTER saving a document.  The document is apparently saved OK, but the
crash occurs while the disk is still spinning at the end of the
save... VERY SCARY!
 
BMUG has bought More and we use it for a "slide show" of announcements
at the beginning of our meetings.  We find it works pretty well, but I
prefer Acta for pure outlining... I managed to lose several items in
More because it lacks "Undo" (!)  In addition, it is much easier to
bring up a DA than to launch More.
 
  -- Raines Cohen
     Berkeley MUG
 
------------------------------

From: BMUG (12720)
Subject: RE: XLISP 1.6
Date: 13-SEP 00:17 Network Digests
 
 To: chuq@sun.uucp
 Re: XLISP 1.6.
 
Chuq -
 
XLisP is on BMUG disk #3, available for $5 from BMUG.  It may also be
on various commercial on-line services, such as Delphi.
 
-- Raines Cohen / BMUG
 
------------------------------

From: BMUG (12721)
Subject: RE: MacDraw, bitmaps, and the LaserWriter
Date: 13-SEP 00:22 Network Digests
 
 To: kearns@garfield.columbia.edu
 Re: MacDraw, bitmaps, and the LaserWriter
 
Steve -
 
MacDraw has lots of bugs (even in version 1.9, the latest).  One of them has to
do with bitmaps... they don't hang together very well.  We have found that the
most reliable way to get bitmaps to behave properly is:
 
 >> IMMEDIATELY "Group" a bitmap upon pasting
 >> Avoid rotating after stretching
 >> When stretching, Group with a box that you can keep aligned to make
    expansion even in both dimensions (to retain proportionality)
 
In addition, bitmaps often appear in slightly different locations on the
printout (LaserWriter) than they do on the screen, relative to text.
 
Good luck!
 
-- Raines Cohen / BMUG
 
P.S. All of this will soon be irrelevant, as soon as CRICKET DRAW, which I saw
at the Desktop publishing Expo in San Francisco, comes out.
 
------------------------------

From: BMUG (12722)
Subject: RE: Model 100 formatting program
Date: 13-SEP 00:25 Network Digests
 
 To: oster@lapis.berkeley.edu
 Re: Model 100 formatting program
 
Dave -
 
we'd love to get ahold of that program you mentioned to reformat files
ported from the Model 100 to the Mac.  We often use a Model 100 to
take minutes at BMUG meetings, and that would help a lot!
 
-- Raines Cohen / BMUG
 
[ There has been several other requests on Delphi for your program - Jeff ]

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

From: BMUG (12723)
Subject: RE: DataFrame 20 fixes
Date: 13-SEP 00:28 Network Digests
 
Herb -
 
Rather than doing the fix yourself to remove the brush from the DataFrame 20
Hard Disk, just bring it to your local DataFrame dealer... I brought mine to
ComputerWare with this symptom a couple of months ago, and they fixed it in 5
minutes... for free!
 
-- Raines Cohen / BMUG
 
------------------------------

From: BMUG (12724)
Subject: Silicon Valley Expo
Date: 13-SEP 00:31 MUGS Online
 
         BMUG has a booth at the Silicon Valley Expo, going on at the
Santa Clar a Expo Center (near City Hall), from today (Friday) through
Sunday... we'll report on anything exciting there... however, be
warned that Silicon Valley is the last place for anything exciting in
the computer industry to be going on.
 
-- Raines / BMUG
 
------------------------------

From: BMUG (12725)
Subject: Desktop Pub Expo followup
Date: 13-SEP 00:34 MUGS Online
 
One last item that I forgot to mention in my Desktop publishing expo summaries
posted before:
 
BMUG talked to a couple of publishers interested in printing the BMUG
NL, which, as you probably know, looks more like a book than a
newsletter and would probably be more economical for us to
offset-print or whatever. Anyhow, one of these publishers, when asked
to show us a sample of his work, whipped out:
 
"Turbo Pascal for the Macintosh: Users Manual" !!
 
Unfortunately, I didn't get to see the contents.  Oh, well...
 
-- Raines / BMUG
 
------------------------------

From: MACLAIRD (12734)
Subject: RE: Copy Perversion Hall of Shame (Re: Msg 12588)
Date: 13-SEP 06:38 Bugs & Features
 
To respond to the assertion that "to defeat copy protection, even for
registered owners, is illegal":
 
Let me preface this by mentioning that Copyright, in the States, is a privilege
granted by the Federal Government restricting the copying of literary works if
they are "fixed in a tangible medium".  Software is fixed once the first copy
is saved.  The Apple vs. Franklin case established that this copy can be in
ROM or similar machine-only readable form.
 
The Copyright holder may prevent anyone from selling copies of his work in two
ways.  First, if he never sells any himself, and second, by signing a contract
with everyone he does sell to with a term agreeing not to re-sell the copy the
buyer has.  In the second case, however, the buyer can sell without violating
the copyright law, but the seller can sue and collect whatever damages occured
due to the second sale.  Of course, the buyer cannot make copies for sale.
 
Once more I must quote, at length, from the current Copyright Act.
Fortunately, because there is no copyright in any work prepared by or
for the United States of America, I'm not violating the Act by doing
so.
 
Section 117 of the Act reads:
 
"Limitations on exclusive rights:  Computer programs
 
  Notwithstanding the provisions of section 106, it is not an infringement for
the owner of a copy of a computer program to make or authorize the making of
another copy or adaptation of that computer program provided:
 
      (1) that such a new copy or adaptation is created as an essential step
   in the utilization of the computer program in conjunction with a machine
   and that it is used in no other manner, or
 
      (2) that such new copy or adaptation is for archival purposes only and
   that all archival copies are destroyed in the event that continued
   possession of the computer program should cease to be rightful.
 
  Any exact copies prepared in accordance with the provisions of this section
may be leased, sold, or otherwise transferred, along with the copy from which
such copies were prepared, only as part of the lease, sale, or other transfer
of all rights in the program.  Adaptations so prepared may be transferred
only with the authorization of the copyright owner."
 
The only way I can see for actually copying the software to be illegal, or
for _adapting_ the software in order to copy it to be illegal, would be if
the vendors took the position that they were only leasing the software, or
licensing the right to use it.  I've read that this is the approach that
Lotus took with JaZz.  There is, however, a little precept of modern legal
deciding, to wit that the substance of a transaction is more important
than the exact form or formulas the parties may choose to characterize it.
 
The statute itself, above, seems to equate "owner of a copy" with
'rightful possessor of the computer program'.  This is in line with my
own thinking.  I mean, if it looks like a clam, smells like a clam, feels
like a clam, and tastes like a clam, then don't call it an oyster!
 
_Laird
 
------------------------------

From: JIMH (12747)
Subject: RE: quickdraw 3-d (Re: Msg 12589)
Date: 13-SEP 16:12 Programming
 
Well i see now why not a lot of people seem to be using the quickdraw
3d library, it is somewhat buggy.  rotating a simple grid causes it to
start spewing out bad lines from time to time, looks like the clipping
doesnt quite work.  Also it is really slow!  I have a project a lab at
the local airforce base has asked us to do if it is feasable which
involves among some other things a simple (real simple) rreal time
flight simulaton. it requires 3-d graphics.  does anyone know of a
decent 3d packag e for the mac.  Also if anyone has a package they
wrote fgor games ect the lab is willing to buy your 3d technology.
Anyway please leave me a message if you have anything!  Ill even take
'C' code but would prefer ASM or Pascal.  jim
 
------------------------------

From: PEABO (12750)
Subject: RE: quickdraw 3-d (Re: Msg 12747)
Date: 13-SEP 16:16 Programming
 
You want to talk to Sublogic, the authorw of Microsoft Flight Simulator.
 
peter
 
------------------------------

From: JIMH (12773)
Subject: RE: quickdraw 3-d (Re: Msg 12750)
Date: 13-SEP 23:10 Programming
 
Peter, i will although there graphics isnt that fast.  I have seen a
demo of the three de stuff someone on here has done which are really
increadable.  However he hasnt been on here in quite a while.  anyway
thanks for the advice
 
------------------------------

From: PEABO (12752)
Subject: Servant .79
Date: 13-SEP 17:07 SIG Business
 
Since Servant had been posted on ARPAnet, we got in touch with Andy
Hertzfeld to ask him for permission to post it here.  He says that he
wasn't really enthusiastic about putting it on ARPAnet, but that he
had told the fellow who asked him to use his discretion.  Andy
definitely does NOT want Servant .79 posted on any national network,
because it is too incomplete and buggy.  He says to look for a real
beta test version towards the end of October.
 
peter
 
------------------------------

From: DDUNHAM (12771)
Subject: RE: TextEdit Bugs & printing to laser printer from program
Date: 13-SEP 23:00 Network Digests
 
 > From: dubois@uwmacc.UUCP (Paul DuBois)
 > Subject: TextEdit Bugs
 
As far as the 2nd bug goes, it is a matter of taste.  TE breaks lines on
whitespace.  As you continue to type whitespace, it has no reason to move the
cursor to the next line.  On the other hand, showing the cursor inside the
viewRect would be wrong, because it's shoved to the right by spaces.
 
I tried to reproduce your first bug using Acta's TextEdit topics, and I
couldn't.
 
 > From: pwu@uwmacc.UUCP (Peter Wu)
 > Subject: printing to laser printer from program
 
All the print calls are device independent.  Text Streaming works just
fine on a LaserWriter, and I see no reason why iPrBitsCtl wouldn't
work.
 
------------------------------

From: TRAINBRAIN (12776)
Subject: RE: Prologs for the Mac (Re: Msg 12668)
Date: 14-SEP 00:48 Programming
 
Here is some dope on PROLOG/m.  I am the developer of said program for
Chalcedony Software, Inc.  So keep in mind that I am somewhat biased.
I have no knowledge of other Prologs for the Mac.
 
PROLOG/m is being shipped.  It is a port of PROLOG/i for the PC, but has been
extensively "Macintized" with menus, dialog boxes, windows, etc.  The interface
has a few nice twists such as a built-in editor (complete with a working UNDO)
and the abili ty to select text on the screen and have it processed as Prolog
input.  More interface features are being developed.
 
One of Chalcedony's goals is to maintain Prolog source code capability between
the Mac and PC versions.  Of course, some capabilities are machine dependent.
These are clearly identified in the documentation.
 
The implementation of both Chalcedony Prologs is, for lack of a better
term, an interpreter.  But this interpreter does not use the classic
technique of storing the program in human readable form and then
translating it as the program runs.  Instead the human readable form
is converted to linked structures as the program is loaded.  The
"interpretation" can then be quite fast and efficient.  It also
permits the "hands on" direct changes without going through an
edit-compile-link sequence.
 
This method also permits the flexibility and power inherent in the Prolog
language such as the ability to handle data of different types, handle data
whose type is not known when the program is written, ability for a program to
modify itself, ability
 of a program to use itself as data.  Chalcedony Prologs support the key
predicates op(), name(), functor(), clause(), and =..("Univ").  These are
essential for many AI and expert system applications.
 
Both Chalcedony Prologs use the Edinburgh syntax and implement the "core"
features defined in Clocksin and Mellish.  Floating point and a number of math
(abs, cos, sine, etc.) functions have been added.  The "toolbox" mentioned in
the ad is, as you g uessed, a nifty set of Prolog routines.  Access to the Mac
toolbox is in the works.
 
I was not involved in the development of the optional expert system,
called NFL X-Pert but, as far as I'm concerned, it is worth the price
of the whole package.  I follow pro football and have always been
fascinated with the wagering, calculating the odds, and predicting
results.  I'm the office football pool junkie.  I learned more about
odds making and predicting from reading the NFL X-Pert manual than I
ever did from the sports pages.
 
If you have any more questions, please ask via forum.  I get on almost every
night.
 
Steve Seidensticker
 
P.S.  NFL X-Pert predicts Chargers 30, Giants 22 tomorrow.  Also, if you call
Chalcedony, tell them I sent you for 10% off.
 
------------------------------

From: PEABO (770)
Subject: Problem with STR# vs. readability
Date:  14-SEP 10:32 Programming Techniques
 
I recently started converting one of my programs to use STR# resources instead
of hard-coded strings.  I solved the problem of dealing with Pascalized strings
in my C code, and some other technical difficulties, but now after doing one
menu function under the new scheme I am dissatisfied.
 
Basically I now have a program full of function calls with #define'd
parameters which while mnemonic, don't really ring a bell when reading
the program like seeing the actual strings in the code used to.  I am
concerned that even now I don't recognzie what the code is doing as
well as I used to, and I just made the change a few days ago!
 
Has anyone else had this problem and come up with any particularly neat
solutions?
 
peter
 
------------------------------

From: SAMURAICAT (774)
Subject: RE: Problem with STR# vs. readability (Re: Msg 770)
Date:  14-SEP 17:40 Programming Techniques
 
No answers here, just ideas.
 
I face a similar problem at work.  Coding for a certain Large
Cerulean box which doesn't have nice things like resource files,
I still need to make my code easily internationalized and OEM
modified.  So I keep all program messages in an external
*char[], and reference messages by index.  I don't like it a bit.
 
Resources on the Mac are a much cleaner solution.  Unfortunately
the programmer interface is still the same-- we're referring to
strings with a number.  I agree with you that Msg[MEMORY_ALLOC_FAILED]
isn't as comfortable as "Yow!  malloc(65535) failed!".
 
Little light bulb over programmer's head:
        How about hacking a spinoff of the Berkeley-UNIX "xstr" to handle
        this situation on the Mac?  (Xstr pulls strings out of C source
        files, replacing them with indices into an external array,
        to assist in implementing shared read-only text segments.)
 
Operation:
        Run the C preprocessor, then build a table of all char-string
        literals encountered in the source, replacing them wih calls to
        GetIndString(), with an index into the 'STR#' resource
        replacing the original.  Write out the massaged source, a
        resource file of the 'STR#' object generated, and an index
        to help go back and tidy up magic numbers, if desired.
 
Problem 1:
        Massaged C source is not terribly readable, being filled with
        magic numbers.  Operator will either have to go back and pretty
        up the sourcefile with manifest constants, or live with it
        (maybe only using this step just before compilation, as a
        rule in a makefile).
 
Problem 2:
        GetIndString() doesn't return a char *; rather, it loads the
        found toy into a preallocated buffer.  You'd find yourself
        allocating many small chunks of nonrelocatable space
        which could only be freed at the end of whatever closure the
        string was referenced within.  Some sort of XstrProlog() and
        XstrEpilog() code would be needed to implement this transparently,
        along with a DoXstr() to actually fetch the string and return
        a pointer to the allocated space.
 
Conclusion:
        Maybe this wasn't such a good idea after all; it would be an
        incredible pain in the ass to write and use.  Back to the drawing
        board.
 
I, too, would like to know how the Mac Pros deal with this.
 
        :- Ben.
 
------------------------------

From: PEABO (775)
Subject: RE: Problem with STR# vs. readability (Re: Msg 774)
Date:  14-SEP 18:41 Programming Techniques
 
What I'm doing right now is creating a separate STR# for each
functional module of the program (meaning for instance a function
invoked from the menu). When I enter the functional module, I
GetResource(...) and save the handle in a global.  This global never
gets erased, so on subsequent entries I can just do a LoadResource on
it in case it got purged.
 
I also HLock it dor the duration of the module so I don't have to worry about
dangling pointers.
 
Then, where I need to pass a string, I pass the (char *) result of a
little routine that takes as its arguments the handle to the STR# and
the index of the desired string in the STR#.  This routine passes back
a pointer to the string.  Since all my routines use the Pascalized
form of the string, I never have to deal with PtoCstr() or worrying
that I have corrupted the STR# by doing a string format conversion.  I
also have a single buffer stashed away for routines which need a C
format string, and which don't need to call the string finding
routines recursively.
 
This is what I meant by dealing with some technical problems.  I'm not entirely
happy with the idea of a shared buffer for PtoCstr conversions, but I like even
less the idea of having numerous memory allocations during string accesses.
 
Your idea of scanning the source is a nice one.  Another real gotcha I
forgot to mention is that ResEdit STR# editing is a joke.  It works OK
for small strings, but you can forget about using it for larger ones.
I was able to transfer the strings I had from the source code to the
STR# resource by pasting them into miniWRITER, then running miniWRITER
over ResEdit and pasting each line individually.  Howveer, many of
these strings are too long to display in the editing box, and the STR#
editor doesn't wrap the lines!
 
I'd also like the option of putting in non-displayable characters (which I am
doing via \xxx in C), and I've had to kludge my way around that a bit.
 
Maybe the thing to do is implement a macro like this:
 
#if MAKESTRING
#define S(h,n,s) s
#else
#define S(h,n,s) str_find(h,n)
#endif
 
With MAKESTRING set, the strinsg would be output into the code (for testing).
WIth it not set, the call to the magic routine would be output.  A scanner
program could then run through the sources and extract the macro invocations.
The scanner could diagnose dupliacte numbers or missing numbers.
 
hmmm
peter
 
------------------------------

From: MDELUGG (12787)
Subject: Disks / Drives
Date: 14-SEP 11:53 Hardware & Peripherals
 
Hi all,
 
I've upgraded to the MAC+ and am really happy.  I think I'd like to keep my old
SS ext. Mac drive(?), but I've got a couple of questions:
 
        o What DS disks do you like (so far I've been happy with FUJI)
& is ther e any vendor you're consistently happy with?
 
        o I do not need a hard disk, but I am thinking of buying
ext.800K -- Any particular manufacturer/dealer recommendations here?
Is anybody offering trade-ins on the old 400K that make any sense?
Will I ever be able to 'stack' the old 400K with an 800?!  How about
an 800 for the SCSI port?!
 
Thanks for your thougts,
 
                -mikey!
 
------------------------------

From: MDELUGG (12788)
Subject: Database applications
Date: 14-SEP 11:54 Business Mac
 
Hello AGAIN gang,
 
Here he is again with a pesky question, this time it's about data-base
applications:
 
I'm thinking of buying something that will allow me to generate a stand-alone
MAC data-base specific to my biz.  Do I go with "DBL HELIX", or "OMNIS 3" or
"OTHER" :)
 
Seriously, I've got a couple of friends & clients I could possibly sell to, and
I've enjoyed the _little_ bit of programming I've dabbled in so far. (Mostly
BASIC) -- Are any the available choices easier to learn?  (I guess dMAC III is
the only other??)  Who provides the best support?  Which is the best value?
 
Thanks for the help, I know this isn't a simple question to answer. BTW, file
compatiblility with other applications or systems is probably the _least_
important factor in this case.
 
                -mikey!
 
------------------------------

From: MACINTOUCH (12797)
Subject: RE: Database applications (Re: Msg 12788)
Date: 14-SEP 17:49 Business Mac
 
You could consider FileMaker Plus, which has "scripts" to make it slightly
programmable.  It's very easy to use, and extremely Mac-ish.  It has a lot of
capabilities and few limits on capacity.
 
dBase Mac from Ashton-Tate should be out by the end of the year.  Although it's
very powerful, it looks like it will be much easier than Omnis 3 or Helix to
program.
 
Ric Ford
 
------------------------------

From: RMORRIS (12796)
Subject: 2 Megabite Upgrades
Date: 14-SEP 17:08 Hardware & Peripherals
 
I'm thinking about upgrading my genuine Apple 512K board to 2megs.
Does anyone have any commenst on which upgrade to buy - which to stay
away from? Also where to mail order it? I would like to avoid an
upgrade that bank switches or needs a boot disk. Price IS a
consideration - as I can live with 512K for ever if I need to. I'm
overseas and CANNOT buy the upgrade locally - but I can get the new
ROM's (lo, a counterfeit of Apple's) if I need to.
 
------------------------------

From: MACINTOUCH (12799)
Subject: RE: 2 Megabite Upgrades (Re: Msg 12796)
Date: 14-SEP 17:52 Hardware & Peripherals
 
Levco seems to be rather well-tested by this time.  I'd be very careful about
installing it, and make sure to adjust the power supply to exactly 5.0 V.
after-wards.
 
Ric
 
------------------------------

From: RMORRIS (12801)
Subject: MacLightning
Date: 14-SEP 18:35 Bugs & Features
 
Now back to one of my favorite peeves - MacLightning. I understand that Target
Software has come out with an updated version that allows you to remove
incorrect spellings from the dictionary. A couple of months ago I spent the
money on an international phone call to them asking about upgrades. The reply
was that they would be FREE to all registered users. But I've heard nothing -
neither have they replied to two letters I've sent. Has anyone actually been
upgraded to the new MacLightning?? What deal are they offering? How do you get
the upgrade??
 
------------------------------

From: MADMACS (12808)
Subject: Macs and a Cray
Date: 14-SEP 20:47 Hardware & Peripherals
 
I just thought that you all might be interested in this bit of news: A
friend of mine just returned from a workshop on using the San Diego
Supercomputer Center.  They have this itsy-bitsy thing they call a
Cray that has an entire floor for the cooling system.
 (And you thought your Mac ran hot!)
 
Anyway, guess what they used to talk to the Cray? You got it--Mac
Pluses--40 of them!  Apparently Apple had donated them to the SDSC.
He has a nice picture of them all lined up in their classroom.  They
used VersaTerm for communications.
 
-Doug Wood

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

End of Delphi Mac Digest
************************

-------