info-mac@uw-beaver (05/22/85)
From: Moderator John Mark Agosta <INFO-MAC-REQUEST@SUMEX-AIM.ARPA>
INFO-MAC Digest Wednesday, 22 May 1985 Volume 2 : Issue 49
Today's Topics:
MacPaint Scratch Files
Floating point benchmarks on the Mac
setfile da and new system
more on clock, battery, and changing dates.
a switcher question
Technical WP on the Mac
arabic mac?
----------------------------------------------------------------------
Date: Mon, 20 May 85 15:26:33 pdt
From: Larry Rosenstein <lsr%apple.csnet@csnet-relay.arpa>
Subject: MacPaint Scratch Files
I believe that the latest MacPaint (1.5) will not create its scratch
files if run on a 512K Macintosh. Earlier versions would create the
scratch files but never use them.
Not only can you run that version from a locked disk, but the start up
should be a bit faster since it doesn't have to create the 2 files.
Larry Rosenstein Apple Computer
UUCP: {nsc, dual, voder, ios}!apple!lsr CSNET: lsr@Apple.CSNET
------------------------------
Date: Mon, 20 May 85 23:44:46 EDT
From: lewis@harvard.ARPA (Harry Lewis)
Subject: Floating point benchmarks on the Mac
This is a preliminary report and a request for further benchmarks of
floating-point speed of higher-level language systems on the Mac. It
seems that every producer of higher-level languages for the Mac is
implementing its own floating point library, with vastly different
degrees of efficiency. (None, to my knowledge, is using SANE.) I and
my friends have run the following benchmark on 4 systems:
Compute the sum of the first 10,000 terms of the harmonic
series; i.e. compute the sum of 1/i for i=1 to 10,000.
(If you have a choice, use 32-bit floats.) The results so
far:
Megamax C 63 seconds
Aztec C 36 seconds
MacModula 9 seconds
MacFortran 4 seconds This incredible variation isn't the whole
story; Aztec C is the only one of the 4 that got the "right" answer,
i.e. the answer my VAX 11/780 with hardware FPU got (in 0.2 seconds
using C): 9.787613.
I would be happy to summarize and report the results of this FP
benchmark on other systems if readers would care to run it and report
the results directly to me.
------------------------------
Date: Tue, 21 May 85 10:40:13 EDT
From: Andrew Malis <malis@BBNCCS.ARPA>
Subject: setfile da and new system
A warning:
The SetFile desk accessory bombs when installed in the new system
(dated 4/8/85) now being distributed by Apple. FEDIT gives you the
same functionality, just not in a da.
Andy
------------------------------
Date: Tue 21 May 85 10:16:38-CDT
From: Werner Uhrig <CMP.WERNER@UTEXAS-20.ARPA>
Subject: more on clock, battery, and changing dates.
On page 135, the Macintosh manual states:
"The battery will probably last about 2 years. If the clock
begins to lose accuracy, replace the battery"
Several people have suggested to me that a run-down battery might be
my problem. Now, if I interpret the manual correctly, a run-down
battery would be indicated by a slowly drifting clock, running slow, I
assume.
What I experience, however, is that I notice files with "strange
dates" cropping up in directory listings, which cause me to check the
Control-Panel, where I find totally changed dates and times, with
years like 1914, 1949, 2010, etc.
The occurances are rare and erratic and so far had not caused me much
grief, and I had, therefore, not much motivation to spend much time
trying to find the source of the problem. However, I am concerned
that such date-changes can be a significant problem under many
circumstances and for many people relying on correct dates, so I
decided to report the problem to the group as a warning and,
hopefully, to bring it to the attention of people in Apple, or others
who have the knowledge to speculate about or investigate possible
reasons for the malfunction, or any usage-habits of mine which might
cause the problem.
I'll try to find the time for some systematic exploration in the near
future and will report on what I find.
Cheers, Werner
------------------------------
Date: Tue 21 May 85 10:38:59-EDT
From: Dan Tappan <Tappan@BBNG.ARPA>
Subject: a switcher question
Does anyone know why memory management in the application switcher was
done the way it is (that is, with a fixed allocation for each
application) instead of something more dynamic, say a minimum size for
each application with the leftover passed around as needed? Is it a
deficency with the ROM memory management routines? If so will they fix
it in the rumored new ROMs?
I don't have any real reason for asking, it's just that the fixed size
partitions stick out like a sore thumb on an otherwise nice program.
Dan
------------------------------
Date: Mon, 20 May 85 22:55:36 EDT
From: lewis@harvard.ARPA (Harry Lewis)
Subject: Technical WP on the Mac
I would like to assess the state of the art of using the Mac for
technical (especially mathematical) word processing. If you have used
Macwrite or Word for setting equations and have a bag of tricks that
make the process easier, send me your advice. Also, of course, I
would like to hear of any other packages (or plans to develop one)
better suited to the task. Reply directly to me, and I will summarize
for the net.
------------------------------
Date: Sat, 18 May 85 09:44:13 edt
From: mrkgross%mit-artemis@mit-athena.ARPA (Mark Gross)
Subject: arabic mac?
Does anyone know of software that will enable the editing of arabic
text?
------------------------------
End of INFO-MAC Digest
**********************