Date: Tue 19 Jun 84 12:43:24-PDT
From: Joseph I. Pallas <PALLAS@SU-SCORE.ARPA>
Subject: QD and QDVar
To: croft@SUMEX-AIM.ARPA
cc: sumacc@SUMEX-AIM.ARPA

The pascal programs don't explicitly allocate a struct QDVar and
assign QD to point at it. Is there some reason that you don't have a
statically allocated struct QDVar and statically initialized global
QD pointing at it in the library?

Such a scheme would still allow you to modify QD if you wanted to, and
save one extra step that's VERY easy to forget.

joe
-------
21-Jun-84 12:18:10-PDT,3333;000000000000
Return-Path: <croft@safe>
Received: from safe by SUMEX-AIM.ARPA with TCP; Thu 21 Jun 84 12:18:01-PDT
Date: Thu, 21 Jun 84 12:20:55 pdt
From: Bill Croft <croft@safe>
To: info-mac@sumex
Subject: using MACSBUG with SUMACC
Cc: croft, sumacc@sumex

----
Date: 20 Jun 1984 20:27-EST
From: David.Anderson@CMU-CS-G.ARPA
I picked up my copy of the SUMacC disk today, and it included MacsBug
and Disassembler. I can't figure out what they do -- can someone
enlighten me? They sound terribly useful.
----
David,

Your SUMACC disk as distributed has MACSBUG named xMACSBUG, this prevents
it from being loaded at boot time. If you want to debug something you
should follow these steps:

Ensure that Macsbug is NOT loaded; i.e. the name in the system
folder should read "xMACSBUG". If this is not true, then rename it,
attempt eject (to flush), and reboot. MacTerminal and the Finder don't
work well when the large MACSBUG and DISASSEMBLER are loaded; Finder
runs out of space and MacTerminal crashes.

AFTER you have downloaded and/or converted your program, then
rename "xMACSBUG" to "MACSBUG", eject, and reboot. This will load
the debugger/disassembler at the top of memory.

Make sure that you have an ASCII terminal connected to the
"printer" port at 9600 baud.

Double click your program, pause a half-second, then hold down
the mouse button. When you hear a beep, release the mouse button.
What this does is: (1) load your program, (2) tells the "C runtime
startoff" (lib/crtmac.s, the first part of your program to
get control after loading) to "pause" before entering your main
program. This will give you time to set breakpoints or alter
memory before your program starts.

The "beep" means crtmac is waiting in a tight loop for register
D0 to become zero. It will just sit there forever. Now on
the side of your Mac, carefully press the "INTERRUPT" (not the
"RESET") button once. The debugger should print out a register
dump on your terminal.

I assume you have read the section "ROM 7.0 MacsBug Summary" in
your Inside Macintosh. This is located somewhat behind the "Misc"
tab in my copy. Other sections that are helpful are "Pascal Program
Debug Strategy" and "Toolbox Names"; the latter is useful for setting
breakpoints on toolbox calls.

To MACSBUG, type "d0 0"; this clears register D0 and will allow
the program to proceed. Now you might want to set a breakpoint on
a location or a trap; use the appropriate "br" or "at" command.
You will probably want to have an assembler listing of your
program; use the "-S" switch of cc68. After you are ready to
proceed, type "g" or "t". This will go to the next breakpoint
or trace each instruction before execution.

When finished debugging you will (unfortunately) need to rename
MACSBUG back to xMACSBUG and reboot if you want to use MacTerminal.

BETTER DEBUGGERS: Soon Apple will be releasing their two-Mac debugger/
assembler system. Instead of an ascii terminal on the printer port, you
use another Mac with a nice window based debugging package. And instead
of MACSBUG/DISASSEMBLER there is just a tiny "stub" that lives on the
system heap which interfaces to the "remote" window debugger. This idea
is very similar to David Bogg's old "TeleSwat" protocol on the Alto.
21-Jun-84 12:38:44-PDT,1064;000000000000
Return-Path: <croft@safe>
Received: from safe by SUMEX-AIM.ARPA with TCP; Thu 21 Jun 84 12:38:41-PDT
Date: Thu, 21 Jun 84 12:41:47 pdt
From: Bill Croft <croft@safe>
To: info-mac@sumex
Subject: utilities on SUMACC disk
Cc: sumacc@sumex

Date: Wed 20 Jun 84 00:37:38-EDT
From: BERGER@CMU-CS-C.ARPA
Subject: SetFile and resource mover questions
I can't get SetFile to set the creator field of a file. Am I
doing something wrong, or is it just broken?
Also, how do you get the Resource Mover to do anything?
Robert Berger
Berger@CMU-CS-C

Somewhere in the Monitor/Workshop/Inside Mac document set was a "hint"
on how to use SETFILE. There is a bug in SETFILE and you have to use
the "tab" key (rather than the mouse) to select the text field(s) that you
want to edit. After changing all the stuff you are interested in, then
you mouse "SET IT" and exit.

For a discussion of the Resource Mover, see the section "Working with
Resource Files on the Macintosh" in the "Putting Together an Application"
document dated 1/13/84.
22-Jun-84 16:49:10-PDT,1566;000000000000
Return-Path: <croft@safe>
Received: from safe by SUMEX-AIM.ARPA with TCP; Fri 22 Jun 84 16:49:06-PDT
Date: Fri, 22 Jun 84 16:51:41 pdt
From: Bill Croft <croft@safe>
To: info-mac@sumex
Subject: debugging new icons
Cc: croft, mikes@cit-vax, sumacc@sumex

The finder has a "cache" of the icon information that it gleans
from your application resource file when it is installed for the first
time. This means that the finder runs faster, but there is also
a finder bug here: there is currently no way to tell the finder
to refresh his cached icon pictures.

This situation where this is most painful is when you are debugging
the icon for your application. Even though you change the icon in
your program's resource file, the finder won't see the change.
Currently the only solution is to force the finder to rebuild his
DeskTop file by rebooting with command-option held down. (Since this
cache is indexed by filetype/creator, you should also ensure that
ALL your applications on the disk have the new definition in their
resource file's because you don't know which one the finder will
encounter first to make his cache entry).

One solution might be to have the finder compare the date when he
made his cache entry to the "modified" date of the file being
considered. If the file is newer than the cache, that entry in
the cache should be rebuilt.

When I mentioned this to Bruce Horn, he said that he had once
considered checking the (SETFILE) "init" bit for this purpose, but
didn't have time at the moment to implement it.

Date: 1 Jul 84 (Sun) 11:59:06 EDT
From: Dave Johnson <ddj%Brown@csnet-relay.arpa>
To: Bruce.Lucas@cmu-cs-ius.arpa, info-mac@sumex-aim.arpa
Subject: Re: debugging icons

I tried using the Resource Mover to edit bad icons out of the Desk Top,
as was suggested, with only partial success. At first I was using a new
author-identifier for each new try at an icon, but this seems wasteful
and would probably require eventually building a new desktop when it
becomes too full.

My original strategy for using rmover was to throw away the application with
the old icon, or turn off the bundle bit using Set File if the application
already had the new icon (but was showing the previous version), then go
into rmover on the Desk Top, and cut out the resource named by the author
string (ie, CCOM, or safer, TEST). When the bundle bit was turned back on,
the new icon did appear, but unfortunately the previous mask was still
there.

I believe removing one of the ICN# resources would solve the problem, but
don't have any idea which one to remove (there were about 16 ICN# resources
on the disk I was playing with). I did try cutting out all of them (pasting
them in a handy MacTerminal document), but this resulted it a "Ghost Disk"
where all of the fancy icons had vanished, and I couldn't get them to come
back using the usual Bundle Bit trick. They did return when I pasted the
resources back into the desk top, but it still gave me the bad mask . . .
back where I started. (the folder, generic document, and generic
application
or "hand" icons are probably in the System file -- only they survived
without
any ICN# resources in the DeskTop). The disk was also in bad shape after
this
ordeal; with a messed up free list, it eventually had to be erased.

Until someone figures out how the Finder maps reference idents, the best way
might be to debug icons on a scratch disk with no folders and only MacTerm,
SetFile, and the application being worked on, so you could blow away the
DeskTop any time without much pain. Then once the icon is finished, move it
to a more stable disk.

Nicer would be a version of the icon editor that could install the icon
directly into the application's resource (and the finder?), so we don't
have to muck about sending the icon to the VAX, installing it in the .rc
file, rebuilding the application, and sending it back to the Mac again.
Even a utility that would do nothing but install icons into applications
would be better than the current situation.