INFO-MAC@SUMEX-AIM.STANFORD.EDU (Moderator David Gelphman...) (12/22/86)
INFO-MAC Digest Sunday, 21 Dec 1986 Volume 5 : Issue 30
Today's Topics:
Re: Stack sniffer question, Novy board comments and more
Re: more on bugs in Apple software
Apple's Product Testing
Mac Nosy/Heap Show
Re: disk insertion ignored
Prolog evaluation
reply to inquiry re running parallel daisywheel from MAC
problems with BeepSound
BUGS in DataFrame 20 Print Spooler 3.1
Problems with Quik Circuit
Interchanging CAPS LOCK and Command Keys
Mac ==> unix ==> Imagen?
----------------------------------------------------------------------
Date: Fri, 19 Dec 86 23:48:09 PST
From: hoptoad!tim@lll-crg.ARPA (Tim Maroney)
Subject: Re: Stack sniffer question, Novy board comments and more
Several unrelated responses. I know, I know, but what do you want, good
grammar or good taste?
First, to disable the stack sniffer and run on a stack located somewhere
inside or underneath the application heap, set the undocumented low-memory
global StkLowPt to zero. This works (I've verified it), but it may stop
working with a future OS or ROM release.
Second, I believe my backdrop file has been incorrectly described here. It
is not a desk accessory, and does not belong in the desk accessory archives.
It is simply a file which you drag to the system ("blessed") folder on an
HFS disk. It contains two INIT resources, and is itself of type INIT, so it
will be run automatically by the INIT 31 mechanism. No explicit
installation, other than copying it to the system folder, is needed. It
works only with new ROMs.
[ note from moderator: The file DA-BACKDROP.HQX has been renamed to
INIT-BACKDROP.HQX DAVEG ]
Third, about the new 68020 board from Novy. This sounds good. A few months
ago, I added up the chip cost for the Prodigy 4; with each chip purchased in
quantity one, there is no way the hardware cost could be more than $2500.
This is even with the currently overpriced 1 megabit chips. This made me
lose a lot of respect for Levco. Unfortunately, it seems unlikely that
either the Prodigy or the Novy board will be competitive much longer, since
the rumor mill has it that it will be possibly to do a logic board swap via
Apple from a Mac to a 68020 "Alladdin". (Someone who claims to have seen an
Alladdin says it's only a 68010, though.)
Fourth, according to the Bay Area computer freebie "Computer Currents", the
X68000 does run Mac software. However, it doesn't say that it runs *all*
Mac software. Still, if it's popular, other developers will be making
compatible versions available.
--
Tim Maroney, Electronic Village Idiot
{ihnp4,sun,well,ptsfa,lll-crg,frog}!hoptoad!tim (uucp)
hoptoad!tim@lll-crg (arpa)
------------------------------
Date: Sat, 20 Dec 86 10:15:40 pst
From: gould9!joel@nosc.ARPA (Joel West @ Western Software Technology)
Subject: Re: more on bugs in Apple software
R. Young (Young@RSCSDY) wrote about the philosophy of reliable
software, and Apple's supposed failure in that regard.
I can agree whole-heartedly with him that any company that wants to
be taken seriously must produce well-tested software. If they screw
up there, they should have good support and fix it quickly.
However, I cannot agree with his assessment of Apple's efforts so
far and wonder if he really understands the constraints involved.
Based on 5 years of supporting and maintaining a VAX-based software
package with only a few hundred sites, I think it is quite possible
for many kibbutzers to underestimate the difficulty of the problem.
In the slightly less than 3 years I have owned a Mac, and the 5 months
I've been using my Mac full-time, I've had very few problems associated
with software (or ROM's) from Apple:
1) MacWrite, the original, and 4.5 have been very reliable.
A pre-release (3.3) tended to crash, but I didn't get
it through official channels.
2) MacPaint and MacTerminal 100% reliable.
3) MacDraw never crashes, although it does have 6 or 7 very
annoying non-fatal bugs.
4) The development software (pre-MPW) has been somewhat
troublesome. ResEdit in particular likes to crash at
inopportune times (is there ever an opportune time?)
5) Finally, Finder 4.1 and 5.3 have never given me a problem.
Don't ask me to remember back to 1.1 or 1.1g, although
my main problem then was 128k and too many disk swaps.
Given Young's emphasis on the Fortune 500, there's certainly nothing
in my experience to suggest they're doing anything wrong. If anything,
my biggest software-wise complaint is that they initially devoted
inadequate resources to Mac-based development software, although I
understand this was related to underestimating the task and perhaps
a judgement error by a former CEO.
I don't know how many Macintoshes there are out there, but I'd have
to guess it's 750,000 to 1 million. The thought of supporting that
many users is mind-boggling. I'd like to point out a few constraints:
* Multiple ROM, memory, peripheral configurations
* No guarantees as to whether users will upgrade to a new
finder or system or printer driver, etc.
* Infeasibility of directly supporting these users
* A dealer base of varying degrees of sophistication, including
many dealers who must also support IBM, Compaq, AT&T, etc.
* 3rd-party developers who sometimes write software that
works without understanding why. By using an un-documented
side-effect, their software breaks later.
And having dealt with smaller update cycles, I feel that one system
software update a year is about right. More, and it's hard to make sure
that everyone gets the message (NEW VERSION!) and the latest version
because the update cycles begin to overlap.
About the only suggestion I'd offer is to adopt a realistic view of
software shelf life and make sure that everyone gets the latest version
with their new machine. If 4.1 (or 5.3) is the latest version of the
finder, make sure that it ships with every machine after that, even
if it means re-making 100,000 kits. ('Just in time' would help.)
Perhaps, force dealers to hand out newer software if the machine's
box was already in the distribution chain when the update was released.
Joel West
joel%gould9.UUCP@NOSC ihnp4!gould9!joel
I have no financial connection with Apple, other than they sometimes
get some of my hard-earned money for hardware or software.
------------------------------
Date: Sat, 20 Dec 86 17:10:54 PST
From: ucscc!ucsck.carl@ucbvax.Berkeley.EDU (Carl C. Hewitt)
Subject: Apple's Product Testing
I am finding a lot of people think that Apple is not worrying about
testing their products before they are distributed. I am sorry,
but I must say that you could not be farther from the truth. Apple
has a division of 200+ people whose sole job is to make sure that
there are no serious bugs in not only Apple's software or hardware,
but most third-party software and hardware as well! That is one of
Apple's main concerns about releasing products. Unless you are a
Macintosh programmer, you may not realize how complex some of these
programs you are complaining about are, and what an incredible task
it is to check every single possible combination of every single
command on every machine in every single situation. If a bug is found, it
is reported, and the bug is fixed before release. Or, in the case that
it is after release, a new version is created.
It may have been true in the past that Apple has been less able to
make sure their quality control is up to the fullest standard, but
tell me the last company that went from $0 income to a member of
the fortune 500 in seven years! Not many companies have ever had
to expand at this rate, and only in the last couple years have they
been able to. I just want the few that are thinking without looking
at all the facts to open their mind and see a little more without
expecting everything to be perfect (as, of course, I'm sure these
people are).
-- Carl Hewitt
------------------------------
Date: Thu, 18 Dec 86 09:06 EDT
From: Joe Mastroianni <JDM%SMVL%rca.com@RELAY.CS.NET>
Subject: Mac Nosy/Heap Show
Hi,
as someone who is always interested in learning more about
Mac programming I have a quick question. I have TMON, and use it
for debugging my C and PASCAL programs. I think its just a wonderful
tool, and couldnt imagine what Mac code development would be like without
it. But Im wondering if there are additional tools out there that might
also be of use. Can someone tell me what Heap Show and Mac Nosy do?
Do I need them if I already have TMON? Are they complementary to TMON?
And - A Comment/Question.
I dont know if any of you out there tried to implement the animation
example that was in Mac Tutor a few months ago, but I did. I had a few
minor problems. The first was, I tried to use Lightspeed C. I couldnt
get the assembly routines (vidwait, vidstart, and vbl) to work, so I
had to rewrite them in C. After I did that all was cool (the getaltscreen()
routine that relaunches the application with the appropriate bit set
worked AOK.)
Now when I run the "bouncing square" animation, it looks like it
runs allright. Only, when the square is moved to the top of the screen,
there is an appreciable flicker. It looks as if the square is not being
drawn in the alternate screen's bit map.
For those of you who are not familiar with this example, it is
a program that simply puts up a gray screen, and sends a black square
bouncing from edge to edge of the screen. You do the animation by alternately
drawing into a "default" and "alternate" screen, and displaying the
screens via a VBL proceedure to avoid flicker. The problem seems to be, that
when the square is being drawn at the top of the screen, it isnt appearing
in one of the two screens.
Anyone have a similar experience, or have any ideas?
Joe
------------------------------
Date: Sat, 20 Dec 86 00:41:40 mst
From: dlc%a@LANL.ARPA (Dale Carstensen)
Subject: Re: disk insertion ignored
I believe two subjects are being discussed under one name here:
1. A known bug in 3.2 will be fixed that does not automatically switch
disks in the Standard File dialogs.
Workaround: click the mouse button in the vicinity of the list window
2. The .Sony driver (or its interrupt processor, if that is considered to
be a separate entity) truncates processing of an inserted floppy. This
bug only seems to appear in rare configurations, perhaps >1M RAM. It
never appeared before the 3.x/5.x System/Finder, but did appear with 64K
ROM and no Hard Disk 20 file.
Workaround: use system, application, and all application files from
ramdisk, use paper clip eject, select eject in the "eject or
initialize" modal dialog, copy new/modified ramdisk files
to SCSI disk or serial port, reboot
------------------------------
Subject: Prolog evaluation
Date: Sun, 21 Dec 86 07:30:08 -0500
From: tjohnson@ATHENA.MIT.EDU
I finally can respond to all you Macintosh PROLOG users (and future users)
that have been wondering what's hot and what's not (and how to go about
evaluating the many PROLOGs that are on the Macintosh market) . In a word,
Advanced A.I. Systems' PROLOG Version M-1.1 is HOT, and Expertintelligence's
ExperPROLOG II is not....
We (MIT Department of Architecture) just went through the rounds of evaluating
what's out there. The criteria that was used was:
It had to:
1. be Fast (PROLOG is infamous for being slow)
2. support Quickdraw and the ToolBox
3. have a large predicate set
4. use the Macintosh interface well
5. use Edinburgh standard syntax
A word about the last point. This is obvioulsy a personal statement. For me
the other syntaxes (such as Marseilles) are not as readable. But the major
point is the Edinburgh syntax is now the quasi-standard syntax (since
thousands of applications have been written in this syntax). That immediately
leaves out Expertintelligence's ExperPROLOG II out since it uses a radically
different syntax (it is also outrageously expensive at $495.00, and doesn't
adhere to the Macintosh interface).
Most of the other contenders fell by the wayside because of limited Quickdraw
and ToolBox support, and what's worse, a limited predicate set.
Advanced A.I. Systems' PROLOG Version M-1.1 ($150.00, P.O. Box 39-0360,
Mountain View, CA 94039-0360) of course meets our criteria, and I must say
very well. First of all, this interpreter is FAST. A simple count down speed
test composed of:
f(X):-
Y is X-1,
Y @> 0,
f(Y).
run for 10,000 loops by the query:
?-f(10000).
takes 28 seconds. This PROLOG program does 30,000 Logical Inferences, or
nearly 1100 LIPS (Logical Inferences Per Second). To put that in perspective,
ARITY's PROLOG runs the same program at 1200 LIPS on an IBM XT, and that
PROLOG is a compiler! (other compiled PROLOGs run faster on the IBM at the
expense of a reduced predicate set). We also tested Advanced A.I. Systems'
PROLOG more heavily on a family tree (by forming new relationships from simple
facts about parenthood), which we also found to run at the same 1100 LIPS.
Advanced A.I. Systems' PROLOG Version M-1.1 accesses most of the ToolBox and
all of Quickdraw. The system comes with many built in predicates to do this,
including the handling of mouse (and event) queues. The programmer can
access the rest by relating trap calls to user defined PROLOG predicates.
What's more, by using another definition statement, one can specify that a
given address is the start of a 68000 machine code routine which is attached
to a user defined symbol (use the code resources to do this), which means...
users can make new predicates like the big PROLOGs do on the minis. The
graphics are suitably fast (we are displaying PROLOG data bases as graphical
networks.
Not counting the Quickdraw and the ToolBox predicates, Advanced A.I. Systems'
PROLOG has over 300 predicates (much more than anyone else) including BagOf
and Setof, and great IO routines. You can also pass statements to it via the
clipboard.
Lastly, it's syntax is compatible with Dec 10 and 20 PROLOG and other
Edinburgh based PROLOGs (and it has very nice debugging aids).
I must sign off with the following story. We trustingly bought AAIS version
1.0 in October 1986 even though it was slow and didn't support the ToolBox at
the time because AAIS promised they would have a no-cost update out in
November that did all of the above. The promised update did indeed come (it
was a month late which is nothing is this world) and worked even better than
we anticipated (FAST!). I sure like that: a company that keeps their promises
and works hard to improve the product.
Tim Johnson
Department of Architecture
M.I.T
Cambridge MA
Also of :
Johnson and Johnson Design/Build
------------------------------
Date: Sat, 20 Dec 86 15:15 EDT
From: <FABER%BCVAX3.BITNET@WISCVM.WISC.EDU>
Subject: reply to inquiry re running parallel daisywheel from MAC
The best way to connect the daisy wheel printer
is to use the Thunderscan adaptor box for
the MacPlus. This will provide
the necessary voltages to rum the Assimilation
Port Adaptor. I am using this set-up and it is working
fine.
Otmar K.E. Foelsche, Dartmouth College
German Department
------------------------------
Date: Fri, 19 Dec 86 17:51:14 PST
From: <DAVEG@slacvm.bitnet>
Reply-to: DAVEG%SLACVM.BITNET@forsythe.stanford.edu
Subject: problems with BeepSound
Lately I really have gotten used to the beep sound init which was
posted recently and comes from the people who wrote the MacNifty
Soundcap software. I have had some problems which I wanted to warn
others about. The worst problem is that it when I tried to hook up
two DataFrame disks to my one Mac+ (which I had done before successfully
before using the beepsound init) the system was *VERY* unstable. Sometimes
it would crash while booting, sometimes it would wait for a floppy disk
insertion, etc. Once the BeepSound init was removed everything worked
OK. I think the problem is in the use of the System heap (although I haven't
had a chance yet to look at the init with MacNosy). I remember reading that
some volume information is stored in the system heap. I'm guessing that
the init installs some patches in the System heap which uses up this
valuable space. Seems to me that Knaster in his book gives a prefered way
of accomplishing this by using the space at BufPtr and below and if
the BeepInit file used this technique I wouldn't be seeing these problems.
I have been OK (as far as I know) when using just the one DataFrame.
The second 'feature' I have noticed is that the sound which is emitted
seems to fade with time until the next bootup. I've also noted that
if you do sysbeep many times quickly in succession it can cause problems.
Hope this saves someone else from going through the discovery of these
problems.
David Gelphman BITNET address: DAVEG@SLACVM
Bin #88 SLAC ARPANET address: DAVEG@SLACVM.BITNET
Stanford, Calif. 94305 UUCP address: ...psuvax1!daveg%slacvm.bitnet
415-854-3300 x2538
usual disclaimer #432 applies: my employer apologies for the fact
that I have access to this net.
------------------------------
Date: Sat, 20 Dec 86 14:59:44 pst
From: Bernard Aboba <bernard@ararat>
Subject: BUGS in DataFrame 20 Print Spooler 3.1
The following lesson was learned the hard way; I had written a program to
read from the printer port, and it was working fine, and then all of a sudden,
it wouldn't run anymore. Neither would Thunderscan, or anything else that
used the printer port other than my imagewriter. I finally figured out the
culprit -- SuperMac's Print Spooler 3.1. Yes, that's correct. You will get
a system error if you attempt to write to the printer port while Print Spooler
is installed.
My advice is DO NOT set the Print Spooler as your startup application if you
intend to use your printer port for other than your imagewriter. I don't
know if it interferes with AppleTalk, though.
------------------------------
Date: Fri, 19 Dec 86 16:45:52 PST
Reply-to: BINEZ%SLACVM.BITNET@forsythe.stanford.edu
Subject: Problems with Quik Circuit
Has anyone been able to get Quik Circuit (a PC board layout program) working
with a Houston Instruments 40 series plotter? We have been trying for several
months. I have had numerous conversations with Douglas Electronics(the
developers), but they have been unable to help me. Despite the fact that
Douglas claims the program works with this plotter, they have been unable to
tell me whether they ever tested it on the plotter.
The problem we are having is that the plotter, which has an internal buffer
and XON/XOFF handshakes with the Mac, plots one buffer of data and then
stops, with the Mac hung in the plotting routine. It seems that the Mac is
not seeing the XON come back from the plotter. We have looked at the data
going between the Mac and the plotter. The plotter is sending both
an XOFF (which the Mac sees) and an XON (which it doesn't seem to see).
I have tried changing the parity, number of stop bits, and number of data
bits on both the plotter and the Mac, but could not get it to work correctly.
We have purchased the "required" cable to connect the Mac+ to the plotter, so
I don't think that the cable is the problem.
Finally, does anyone know of a good PC board layout program for the Mac?
Quik Circuit would be tolerable (if I could get it to work with the plotter),
but its implementation is extremely poor. The program spends a LOT of
unnecessary time redrwaing the screen after each dialog box, and each time
a window is scrolled. It even appears that ALL display windows are
redrawn after a dialog box, even those that are completely hidden! Use
of CopyBits and only redrawing visible regions would help out substantially.
Thanks in advance.
Tim Bienz
------------------------------
Date: Sat, 20 Dec 86 11:24:54 PST
From: David G Kay <kay@LOCUS.UCLA.EDU>
Subject: Interchanging CAPS LOCK and Command Keys
I find it cumbersome to reach the Command (clover{eaf)
key on my Mac Plus's keyboard; I would like to interchange its
function with that of the CAPS LOCK key, which I almost never
use.
I understand that there are two tasks involved:
---physically disabling the locking mechanism on the CAPS LOCK
key (which I've already had done), and
---remapping the codes transmitted by the two keys. It's this
latter task that I don't know how to do, and that I'd
like some advice on.
How does one remap keys on the Mac?
--DGK
------------------------------
Date: Fri, 19 Dec 86 10:11:44 est
From: Franklin Davis <davis%wanginst.edu@RELAY.CS.NET>
Subject: Mac ==> unix ==> Imagen?
What software is available on unix to print Mac output on an Imagen?
Is there any that is PD or cheap? Is there any that is well
maintained (and expensive :-) ?
Apologies if this is an old question...
--
Love's mysteries in souls do grow,
But yet the body is his book. --John Donne
------------------------------
End of INFO-MAC Digest
**********************