From: pottier@clipper.ens.fr (Francois Pottier)
Subject: csmp-digest-v3-044
Date: Tue, 12 Jul 1994 14:08:55 +0200 (MET DST)
C.S.M.P. Digest Tue, 12 Jul 94 Volume 3 : Issue 44
Today's Topics:
"Power Mac Programming Starter Kit", by Tom Thompson
AppleTalk Prefered vs. Alternate Interface?
CodeWarrior inline problem
Mac Pathname Syntax
MacTCP Berkeley socket wrapper?
MacsBug-How Do I...
Receiving Events in AppleScript
[Q] ReleaseResource, PICTs and handles
computer strategy
The Comp.Sys.Mac.Programmer Digest is moderated by Francois Pottier
(pottier@clipper.ens.fr).
The digest is a collection of article threads from the internet newsgroup
comp.sys.mac.programmer. It is designed for people who read c.s.m.p. semi-
regularly and want an archive of the discussions. If you don't know what a
newsgroup is, you probably don't have access to it. Ask your systems
administrator(s) for details. If you don't have access to news, you may
still be able to post messages to the group by using a mail server like
anon.penet.fi (mail help@anon.penet.fi for more information).
Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject. The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
nef.ens.fr). Article threads are not added to the digest until the last
article added to the thread is at least two weeks old (this is to ensure that
the thread is dead before adding it to the digest). Article threads that
consist of only one message are generally not included in the digest.
The digest is officially distributed by two means, by email and ftp.
If you want to receive the digest by mail, send email to listserv@ens.fr
with no subject and one of the following commands as body:
help Sends you a summary of commands
subscribe csmp-digest Your Name Adds you to the mailing list
signoff csmp-digest Removes you from the list
Once you have subscribed, you will automatically receive each new
issue as it is created.
The official ftp info is //ftp.dartmouth.edu/pub/csmp-digest.
Questions related to the ftp site should be directed to
scott.silver@dartmouth.edu. Currently no previous volumes of the CSMP
digest are available there.
Also, the digests are available to WAIS users. To search back issues
with WAIS, use comp.sys.mac.programmer.src. With Mosaic, use
http://www.wais.com/wais-dbs/comp.sys.mac.programmer.html.
-------------------------------------------------------
>From nagle@netcom.com (John Nagle)
Subject: "Power Mac Programming Starter Kit", by Tom Thompson
Date: Tue, 28 Jun 1994 00:14:57 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)
Just bought "Power Macintosh Programming Starter Kit", by Tom
Thompson (ISBN 1-56830-091-3). This is a cute little book, but
it's not quite what the title indicates. You get a 418-page book,
and a CD-ROM with a very limited version of the MetroWerks compilers.
(You can't do anything but work with the sample code on the CD-ROM.)
This book has attitude. It's not one of those "The Mac is easy"
books; it's a macho programming book by an old-time low-level Mac hacker.
The first real sample application isn't something like a draw program;
it's a program to eject the currently mounted CD while file sharing is active.
The second sample application is an INIT which changes the screen depth when
some funny character combination is hit. There's
trap patching, mixed 68K/PPC code, accessing of low-memory globals,
and 68K code that manipulates the stack pointer. All the resources are
written in Rez, by hand. There's even some inline assembly 68K assembly
code written in hex. No PPC machine code, though.
The approach taken is strictly C. No new-fangled object-oriented
programming here. None of that exotic class library stuff. You do things
by calling the Toolbox, like Bill Atkinson intended.
But if you want a readable explaination of how to do fat trap patches,
this is the book for you.
John Nagle
---------------------------
>From npearl@magnus.acs.ohio-state.edu (Nathan Y Pearlstein)
Subject: AppleTalk Prefered vs. Alternate Interface?
Date: 27 Jun 1994 17:57:01 GMT
Organization: The Ohio State University
Hi, According to THINK Reference there are 2 ways of using AppleTalk,
the prefered or the alternate interface. If I use the alternate
interface I don't have to write a socket listener, but if I use the
prefered method I do. What would be the drawbacks of using the
alternate interface? Please don't send guesses.
Thanks
--
DarkNater - pearlstein.1@osu.edu
+++++++++++++++++++++++++++
>From npearl@magnus.acs.ohio-state.edu (Nathan Y Pearlstein)
Date: 27 Jun 1994 18:03:42 GMT
Organization: The Ohio State University
In article <2un3td$83d@charm.magnus.acs.ohio-state.edu>,
Nathan Y Pearlstein <npearl@magnus.acs.ohio-state.edu> wrote:
>Hi, According to THINK Reference there are 2 ways of using AppleTalk,
>the prefered or the alternate interface. If I use the alternate
>interface I don't have to write a socket listener, but if I use the
>prefered method I do. What would be the drawbacks of using the
>alternate interface? Please don't send guesses.
>Thanks
Silly me, I should also mention that I have to use DDP.
--
DarkNater - pearlstein.1@osu.edu
+++++++++++++++++++++++++++
>From jumplong@aol.com (Jump Long)
Date: 28 Jun 1994 03:28:05 -0400
Organization: America Online, Inc. (1-800-827-6364)
In article <2un3td$83d@charm.magnus.acs.ohio-state.edu>,
npearl@magnus.acs.ohio-state.edu (Nathan Y Pearlstein) writes:
>Hi, According to THINK Reference there are 2 ways of
>using AppleTalk, the prefered or the alternate interface.
>If I use the alternate interface I don't have to write
>a socket listener, but if I use the prefered method I do.
>What would be the drawbacks of using the alternate
>interface? Please don't send guesses.
Drawbacks...
1) Apple has dropped all support of the alternate interface.
2) It has bugs that'll never be fixed.
3) I have already written a socket listener that does everything the
one supplied with the alternate interface does, plus mine buffers
packets. It is in the Tech Note "AppleTalk, the Rest of the Story"
and in the sample "Network Watch (DMZ)"
4) The alternate interface uses network events which aren't supported
any longer.
Is that enough?
- Jim Luther
---------------------------
>From philip@cs.wits.ac.za (Philip Machanick)
Subject: CodeWarrior inline problem
Date: 26 Jun 1994 16:58:49 GMT
Organization: Computer Science Dept, U of Witwatersrand
Even though a member function is declared incline in the class, if I have a
call
to it before its code actually appears, the compiler complains "illegal
inline function" when it sees the code with inline in front of it.
Moving the code to before the call makes the compiler happy.
In my opinion this is a bug since other C++ compilers can deal with this
with no problem.
The workaround of moving the inline function to before it's called is no
big problem (I can't imagine anyone wanting mutually recursive inlines -
what would they expand to?). But it's irritating because it means I can't
keep my source file in the order I want it.
--
Philip Machanick philip@cs.wits.ac.za
Department of Computer Science, University of the Witwatersrand
2050 Wits, South Africa
phone 27(11)716-3309 fax 27(11)339-7965
+++++++++++++++++++++++++++
>From "Andrew C. Plotkin" <ap1i+@andrew.cmu.edu>
Date: Sun, 26 Jun 1994 13:53:10 -0400
Organization: Information Technology Center, Carnegie Mellon, Pittsburgh, PA
Excerpts from netnews.comp.sys.mac.programmer: 26-Jun-94 CodeWarrior
inline problem Philip Machanick@cs.wits (828)
> Even though a member function is declared inline in the class, if I have a
> call
> to it before its code actually appears, the compiler complains "illegal
> inline function" when it sees the code with inline in front of it.
> Moving the code to before the call makes the compiler happy.
> In my opinion this is a bug since other C++ compilers can deal with this
> with no problem.
It's very likely that the other C++ compilers are dealing with it by
ignoring the "inline" -- that is, they generate a normal member function
which is called with the usual calling mechanism. This is easier than
going through the rest of the compilation to find the inline definition,
and then going back to compile the function that calls the inline
function.
I'm not certain that they're doing it this way, but you might want to
create a test case and examine the assembly code to see. It's something
to consider; it's possible for a C++ programmer to get silently horked
by this, where the compiler isn't giving him the inlining optimizations
that he wants.
If CodeWarrior isn't willing to do that, it's a problem (what you're
doing is legal C++, I believe) but it does point out the silent problem
you would have with some other compilers.
--Z
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
+++++++++++++++++++++++++++
>From johnmce@world.std.com (John McEnerney)
Date: Sun, 26 Jun 1994 23:36:29 GMT
Organization: The World Public Access UNIX, Brookline, MA
philip@cs.wits.ac.za (Philip Machanick) writes:
>Even though a member function is declared incline in the class, if I have a
>call to it before its code actually appears, the compiler complains "illegal
>inline function" when it sees the code with inline in front of it.
>Moving the code to before the call makes the compiler happy.
>In my opinion this is a bug since other C++ compilers can deal with this
>with no problem.
This is a hazy area. See ARM p. 104 for some examples. It is an error to
define a member function as 'inline' after it has already been called. It
is not clear from the notes whether it is legal if the function was
declared 'inline' (but not defined) in the class. I'd say it is probably
legal, and we are being too strict; I'll pass it on to the C++ front-end
architect.
-- John McEnerney, Metrowerks PowerPC Product Architect
+++++++++++++++++++++++++++
>From philip@cs.wits.ac.za (Philip Machanick)
Date: 27 Jun 1994 13:32:23 GMT
Organization: Computer Science Dept, U of Witwatersrand
In article <Cs12wu.Cyn@world.std.com>, johnmce@world.std.com (John
McEnerney) wrote:
> philip@cs.wits.ac.za (Philip Machanick) writes:
>
> >Even though a member function is declared incline in the class, if I have a
> >call to it before its code actually appears, the compiler complains "illegal
> >inline function" when it sees the code with inline in front of it.
> >Moving the code to before the call makes the compiler happy.
>
> >In my opinion this is a bug since other C++ compilers can deal with this
> >with no problem.
>
> This is a hazy area. See ARM p. 104 for some examples. It is an error to
> define a member function as 'inline' after it has already been called. It
> is not clear from the notes whether it is legal if the function was
> declared 'inline' (but not defined) in the class. I'd say it is probably
> legal, and we are being too strict; I'll pass it on to the C++ front-end
> architect.
You're right - it is hazy. However I don't think an error should be
reported. In commentary on p 102, see the list of reasons an ordinary call
may be generated for an inline function:
- An inline function was invoked in a program before it was defined
In a case like this the compiler has the option of either backpatching the
inline in if a call is seen before the function definition, or generating
code for a non-inline version of the function. My version of cfront on UNIX
does the latter, and switches to using inlining after it's seen the
definition of the inline function.
The key here is that the "inline" can be ignored (p 99). This is what a
compiler should do if it sees "inline" then can't honour it - for whatever
reason.
--
Philip Machanick philip@cs.wits.ac.za
Department of Computer Science, University of the Witwatersrand
2050 Wits, South Africa
phone 27(11)716-3309 fax 27(11)339-7965
---------------------------
>From russell.m.brill@ccmail.jpl.nasa.gov (Russ Brill)
Subject: Mac Pathname Syntax
Date: 24 Jun 1994 14:14:27 GMT
Organization: JPL
I've written a portable program which uses IOstreams and no toolbox calls.
What
syntax is allowable for Mac pathnames? I have discovered that the
following work:
filename (same folder)
:folder1:folder2...:filename (starting at same folder)
:::folder1...:filename (up 3 folders)
disc:folder1...:filename (absolute path)
and I've discovered that there can't be any spaces in the pathname. Are
there any other syntaxes or restrictions. In particular, is there a way to
refer to the desktop?
+++++++++++++++++++++++++++
>From rmah@panix.com (Robert S. Mah)
Date: Fri, 24 Jun 1994 11:02:39 -0500
Organization: One Step Beyond
russell.m.brill@ccmail.jpl.nasa.gov (Russ Brill) wrote:
> I've written a portable program which uses IOstreams and no toolbox
> calls. What syntax is allowable for Mac pathnames? I have discovered
> that the following work:
>
> filename (same folder)
> :folder1:folder2...:filename (starting at same folder)
> :::folder1...:filename (up 3 folders)
> disc:folder1...:filename (absolute path)
>
> and I've discovered that there can't be any spaces in the pathname.
> Are there any other syntaxes or restrictions. In particular, is
> there a way to refer to the desktop?
No spaces? Spaces never bothered my pathnames before -- what compiler
and/or ANSI library are you using?
Anyway, to refer to the desktop, use something like...
"disk:Desktop Folder:file"
The desktop displays the union of all Desktop Folder's on all mounted
volumes. The trash folder is similar in nature.
Cheers,
Rob
___________________________________________________________________________
Robert S. Mah -=- One Step Beyond -=- 212-947-6507 -=- rmah@panix.com
+++++++++++++++++++++++++++
>From oster@netcom.com (David Phillip Oster)
Date: Fri, 24 Jun 1994 21:01:47 GMT
Organization: Netcom Online Communications Services (408-241-9760 login: guest)
In article <russell.m.brill-240694070926@mac8.jpl.nasa.gov> russell.m.brill@ccmail.jpl.nasa.gov (Russ Brill) writes:
If your program does not allow spaces in pathnames, your program is wrong.
If your program does not allow the user to name all his hard disks and
floppies "untitled" and still allow the user to specify which file on which
hard disk she meant, then your program is wrong. (This is what the standard
file dialog, and also Macintosh Drag & Drop are for.)
The desktop is represented by an invisible folder with a name something like
"Desktop", in the English Language version of System 7 and later.
In systems earlier than 7, it was a bit in the FinderFlags portion of the
directory entry. In languages other than English, it may not be called
"Desktop", you need to call FindFolder() to get the dirID, which is a long,
and the volRef, which is a short for the desktop folder.
+++++++++++++++++++++++++++
>From Rick_Holzgrafe@taligent.com (Rick Holzgrafe)
Date: Fri, 24 Jun 1994 20:33:33 GMT
Organization: Semicolon Software
In article <russell.m.brill-240694070926@mac8.jpl.nasa.gov>,
russell.m.brill@ccmail.jpl.nasa.gov (Russ Brill) wrote:
> I've written a portable program which uses IOstreams and no toolbox calls.
> What
> syntax is allowable for Mac pathnames? I have discovered that the
> following work:
>
> filename (same folder)
> :folder1:folder2...:filename (starting at same folder)
> :::folder1...:filename (up 3 folders)
> disc:folder1...:filename (absolute path)
>
> and I've discovered that there can't be any spaces in the pathname. Are
> there any other syntaxes or restrictions. In particular, is there a way to
> refer to the desktop?
Spaces should not be a problem. In general any character is allowable
except for colons, which are used only as separators. The Mac itself uses
Pascal strings and probably wouldn't be bothered even by a null byte, but
if you are working in C or C++ you may not be able to cope with null bytes
because they'll be interpreted as end-of-string markers.
-- Rick Holzgrafe, a member of the Taligentsia
Rick_Holzgrafe@taligent.com
rmh@taligent.com
+++++++++++++++++++++++++++
>From nagle@netcom.com (John Nagle)
Date: Sat, 25 Jun 1994 17:44:48 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)
Rick_Holzgrafe@taligent.com (Rick Holzgrafe) writes:
>Spaces should not be a problem. In general any character is allowable
>except for colons, which are used only as separators. The Mac itself uses
>Pascal strings and probably wouldn't be bothered even by a null byte, but
>if you are working in C or C++ you may not be able to cope with null bytes
>because they'll be interpreted as end-of-string markers.
But be aware that under A/UX, the "/" is used as a separator, following
UNIX conventions, and this can reach your program. And under MPW,
"/" is used to indicate regular expression expansion.
John Nagle
+++++++++++++++++++++++++++
>From jumplong@aol.com (Jump Long)
Date: 25 Jun 1994 17:15:02 -0400
Organization: America Online, Inc. (1-800-827-6364)
In article <russell.m.brill-240694070926@mac8.jpl.nasa.gov>,
russell.m.brill@ccmail.jpl.nasa.gov (Russ Brill) writes:
>What syntax is allowable for Mac pathnames?
In Inside Macintosh: Files pages 2-23 through 2-32, you'll find a
section "Identifying Files, Directories, and Volumes" that includes
the naming rules for pathnames. The only omission I know of in this
section of Inside Macintosh: Files is that consecutive colon (:)
separator characters ascend a level in the catalog tree (for example,
the pathname 'HD:System Folder:Extensions::' refers to the System
Folder). Using partial pathnames is discouraged because if a user
moves things around, they break. Using full pathnames is discouraged
for the same reason as partial pathnames and for another good reason
- the Macintosh allows multiple volumes to be mounted with the same
volume name. If you have multiple volumes mounted with the same
volume name and use a full pathname, the file system uses the first
volume with a matching name that it finds by searching the VCB queue
and that might not be the volume you wanted.
- Jim Luther
+++++++++++++++++++++++++++
>From misc173@csc.canterbury.ac.nz
Date: 28 Jun 94 14:24:13 +1200
Organization: University of Canterbury, Christchurch, New Zealand
> for the same reason as partial pathnames and for another good reason
> - the Macintosh allows multiple volumes to be mounted with the same
> volume name. If you have multiple volumes mounted with the same
> volume name and use a full pathname, the file system uses the first
> volume with a matching name that it finds by searching the VCB queue
> and that might not be the volume you wanted.
I'm writing a program somewhat like Xtree gold on the IBM, where you
get a tree view of the files, without having to worry about windows. At the
moment it works by using full path names. I'm using the list manager and
simply steeping back up the tree to work out the path. What alternatives are
there to full path names, I know a bit about directory numbers and volume
numbers, cant you just specify a volume number and a partial ( no volume name )
or full path.
I really dont want to have to rewrite the list manager to include file
numbers.
Thanks,
Jon.
+++++++++++++++++++++++++++
>From Jens Alfke <jens_alfke@powertalk.apple.com>
Date: Tue, 28 Jun 1994 21:25:19 GMT
Organization: Apple Computer
misc173@csc.canterbury.ac.nz writes:
> I'm writing a program somewhat like Xtree gold on the IBM, where you
> get a tree view of the files, without having to worry about windows.
Hmm, is this really any better than the list view in the Finder, in which you
can open subfolders in an outline?
> At the
> moment it works by using full path names. I'm using the list manager and
> simply steeping back up the tree to work out the path. What alternatives are
> there to full path names, I know a bit about directory numbers and volume
> numbers
The preferred way to deal with files is by volume refNum, directory ID and
filename. The volume refNum is not persistent across volume mounts but the
other two are. There is a structure called an FSSpec that encapsulates this
info. Most of the file manager functions that deal with files have versions
that take FSSpecs.
You probably really want to get the "MoreFiles" sample code, which has all
kinds of routines for dealing with files and directories, such as enumerating
through all the files in a directory. Also be sure to read Inside Macintosh:
Files.
> I really dont want to have to rewrite the list manager to include file
> numbers.
Huh? Don't tell me you're just displaying a textual list of pathnames. Ewwwww!
--Jens Alfke
jens_alfke@powertalk Rebel girl, rebel girl,
.apple.com Rebel girl you are the queen of my world
---------------------------
>From ankh@leland.Stanford.EDU (graham hesselroth)
Subject: MacTCP Berkeley socket wrapper?
Date: 23 Jun 1994 17:48:39 GMT
Organization: Stanford University, CA 94305, USA
Hello,
I was looking for some library of C or C++ code that
acted as a simplified interface to the MacTCP calls, preferably
compliant with the Berkeley sockets API. Does any such beast exist,
or anyother package that provides socket like calls on the Mac
(socket, bind, connect, recvrfrom, sendto, etc)?
Pls send replies to ankh@leland.stanford.edu
Thanks
Graham
+++++++++++++++++++++++++++
>From rypma@waterloo.hp.com (Ted Rypma)
Date: 23 Jun 1994 20:53:01 GMT
Organization: H-P Panacom Div, Waterloo, ON Canada
graham hesselroth (ankh@leland.Stanford.EDU) wrote:
: Hello,
: I was looking for some library of C or C++ code that
: acted as a simplified interface to the MacTCP calls, preferably
: compliant with the Berkeley sockets API. Does any such beast exist,
>From an earlier post...
% Get sockets.hqx from explorer.dgp.utoronto.ca in /pub/macsockets.
%
% Be warned, though, you have to build it yourself (MPW), and it is imcomplete.
% For just connecting to some server, snarf data, and close, it works fine.
% One of these days I'll get around to supplying Tom with a list of patches
% and then someday he'll get around to supplying an updated .hqx file of
% compiled libraries and headers.
%
% enjoy!
% --
% !@$^&*)($#$@!@#$^&*()_+_)(*&^$#@!$^&*()_+)(*&^$#@$^&*+_(*&^$#@#^&*()&*$#@(*&
% Dominic Richens : dominic@oeg.carleton.ca : Tel. (613) 820 0764
% Ontario Telepresence Project,2670 Queensview Dr.,Ottawa,ON,K2B 8K1,CANADA
Ted Rypma
Waterloo, Ontario
+++++++++++++++++++++++++++
>From nagel@Rdatasys.COM (Mark D. Nagel)
Date: Fri, 24 Jun 1994 18:14:28 GMT
Organization: Relational Data Systems, Irvine, CA
In <2ucsnd$73m@hppadbk.waterloo.hp.com> rypma@waterloo.hp.com (Ted Rypma) writes:
>graham hesselroth (ankh@leland.Stanford.EDU) wrote:
>: I was looking for some library of C or C++ code that
>: acted as a simplified interface to the MacTCP calls, preferably
>: compliant with the Berkeley sockets API. Does any such beast exist,
>From an earlier post...
>% Get sockets.hqx from explorer.dgp.utoronto.ca in /pub/macsockets.
There's also GUSI (Grand Unified Socket Interface), available from
nic.switch.ch in /software/mac/src/mpw_c. Here'e the .info file:
- ----------------------------------------------------------------------------
G U S I -- Grand Unified Socket Interface
INTRODUCTION
GUSI is an extension and partial replacement of the MPW C runtime
library. Its main objective is to provide a more or less simple and
consistent interface across the following communication domains:
Files Ordinary Macintosh files and MPW pseudo devices.
Unix Memory based communication within a single machine
Appletalk ADSP communication over a network.
PPC Local and remote connections with the System 7 PPC Toolbox
Internet TCP and UDP connections over MacTCP.
Additionally, GUSI adds some UNIX library calls dealing with files which
were missing, like chdir(), getcwd(), symlink(), and readlink(), and changes
a few other library calls to behave more like their UNIX counterparts.
REQUIREMENTS
To use GUSI, you need MPW C 3.2 or later. To modify it, you additionally need
MPW C++ 3.2 or later and Perl. GUSI_120.doc.sit.bin provides the documentation
for non-postscript printers. Documentation in Postscript format is included.
- ----------------------------------------------------------------------------
There's also a port to THINK C in the info-mac archives.
--
Mark D. Nagel <mark.nagel@rdatasys.com> Relational Data Systems
30 Executive Park, Suite 260
Eat right. Exercise. Die anyway. Irvine, CA 92714
(714) 263-3899
+++++++++++++++++++++++++++
>From creiman@netcom.com (Charlie Reiman)
Date: Sat, 25 Jun 1994 05:43:44 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)
nagel@Rdatasys.COM (Mark D. Nagel) writes:
>In <2ucsnd$73m@hppadbk.waterloo.hp.com> rypma@waterloo.hp.com (Ted Rypma) writes:
>>graham hesselroth (ankh@leland.Stanford.EDU) wrote:
>>: I was looking for some library of C or C++ code that
>>: acted as a simplified interface to the MacTCP calls, preferably
>>: compliant with the Berkeley sockets API. Does any such beast exist,
>>From an earlier post...
>>% Get sockets.hqx from explorer.dgp.utoronto.ca in /pub/macsockets.
>There's also GUSI (Grand Unified Socket Interface), available from
>nic.switch.ch in /software/mac/src/mpw_c.
My old BSD library is also still available at ftp.ncsa.uiuc.edu, in
/misc/unsupported. It is, believe it or not, shipping inside NCSA
Mosaic. I assume they fixed some bugs along the way, but the Macsbugs
symbols show no signifigant changes.
My code, being hammered by hundreds (thousands?) of thousands of
users every day, and do I get any credit? No. Of course not.
What? Me bitter? Nah. It comes with the territory of working as an
undergrad.
Sorry. I'll pack up my spite and regret and move along to the next
newsgroup.
--
"You can't cancel the project! We already made the T-shirts!"
Charlie Reiman
creiman@netcom.com
+++++++++++++++++++++++++++
>From jbrowne@zaphod.ncsa.uiuc.edu (Jim Browne)
Date: 28 Jun 94 02:44:22 GMT
Organization: University of Illinois at Urbana
creiman@netcom.com (Charlie Reiman) writes:
>My code, being hammered by hundreds (thousands?) of thousands of
>users every day, and do I get any credit? No. Of course not.
What did you expect, Charlie? This is NCSA we're talking about here.
>What? Me bitter? Nah. It comes with the territory of working as an
>undergrad.
...and the list keeps growing...
--
Jim Browne Random net.person for this season jbrowne@uiuc.edu
There are more stoplights in Sunnyvale, CA. than people in my hometown.
---------------------------
>From tpguinn@utxvms.cc.utexas.edu (Tim Guinn)
Subject: MacsBug-How Do I...
Date: Fri, 24 Jun 1994 01:27:47 -0600
Organization: The University of Texas at Austin, Austin, Texas
As always, please forgive the uninformed newbie nature
of this post. I'm still learning.
I've gotten to where I'm pretty comfortable entering
MacsBug [by choice 8-)] and using it to <es> out of crashed
applications and save things before <rb> or <rs>. However...
Because it's such a new experience (entering the debugger
versus a screen freeze) I've noticed I seem to be entering
it a lot. Well, I'd like to avoid that, of course. Most of
the time, I get Bus Error messages.
An example:
BusError at 00036090 while reading longword from 01A50190
in Supervisor data space
I understand the *what* here, I just don't understand the
*why*. So I did this:
dm 36090 applname
...thinking it would tell me the name of the offender.
Nope. I got: