ftp.mactech.com 2010/ftp.mactech.com.tar/ftp.mactech.com/csmpdigest/csmp-digest-v3-044

Text File | 2010-09-21 | 55KB | 1,411 lines

Received-Date: Tue, 12 Jul 1994 14:08:59 +0200
From: [e-mail] (Francois Pottier)
Subject: csmp-digest-v3-044
To: [e-mail]
Date: Tue, 12 Jul 1994 14:08:55 +0200 (MET DST)
X-Mailer: ELM [version 2.4 PL23]
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Errors-To: [e-mail]
Reply-To: [e-mail]
X-Sequence: 47

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
([e-mail]).

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 [e-mail] 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 [e-mail]
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
[e-mail]. 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 [e-mail] (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 [e-mail] (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 - [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Nathan Y Pearlstein)
Date: 27 Jun 1994 18:03:42 GMT
Organization: The Ohio State University

In article <2un3td$[e-mail]>,
Nathan Y Pearlstein <[e-mail]> 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 - [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Jump Long)
Date: 28 Jun 1994 03:28:05 -0400
Organization: America Online, Inc. (1-800-827-6364)

In article <2un3td$[e-mail]>,
[e-mail] (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 [e-mail] (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                   [e-mail]
Department of Computer Science, University of the Witwatersrand
2050 Wits, South Africa
phone [phone]  fax [phone]

+++++++++++++++++++++++++++

>From "Andrew C. Plotkin" <[e-mail]>
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 [e-mail] (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 [e-mail] (John McEnerney)
Date: Sun, 26 Jun 1994 23:36:29 GMT
Organization: The World Public Access UNIX, Brookline, MA

[e-mail] (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 [e-mail] (Philip Machanick)
Date: 27 Jun 1994 13:32:23 GMT
Organization: Computer Science Dept, U of Witwatersrand

In article <[e-mail]>, [e-mail] (John
McEnerney) wrote:

> [e-mail] (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                   [e-mail]
Department of Computer Science, University of the Witwatersrand
2050 Wits, South Africa
phone [phone]  fax [phone]

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

>From [e-mail] (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 [e-mail] (Robert S. Mah)
Date: Fri, 24 Jun 1994 11:02:39 -0500
Organization: One Step Beyond

[e-mail] (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  -=-  [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (David Phillip Oster)
Date: Fri, 24 Jun 1994 21:01:47 GMT
Organization: Netcom Online Communications Services (408-241-9760 login: guest)

In article <[e-mail]> [e-mail] (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 [e-mail] (Rick Holzgrafe)
Date: Fri, 24 Jun 1994 20:33:33 GMT
Organization: Semicolon Software

In article <[e-mail]>,
[e-mail] (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
   [e-mail]
   [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (John Nagle)
Date: Sat, 25 Jun 1994 17:44:48 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

[e-mail] (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 [e-mail] (Jump Long)
Date: 25 Jun 1994 17:15:02 -0400
Organization: America Online, Inc. (1-800-827-6364)

In article <[e-mail]>,
[e-mail] (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 [e-mail]
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 <[e-mail]>
Date: Tue, 28 Jun 1994 21:25:19 GMT
Organization: Apple Computer

[e-mail] 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 [e-mail] (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 [e-mail]
    Thanks
        Graham


+++++++++++++++++++++++++++

>From [e-mail] (Ted Rypma)
Date: 23 Jun 1994 20:53:01 GMT
Organization: H-P Panacom Div, Waterloo, ON Canada

graham hesselroth ([e-mail]) 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  :  [e-mail]  :  Tel. [phone]
% Ontario Telepresence Project,2670 Queensview Dr.,Ottawa,ON,K2B 8K1,CANADA

Ted Rypma
Waterloo, Ontario

+++++++++++++++++++++++++++

>From [e-mail] (Mark D. Nagel)
Date: Fri, 24 Jun 1994 18:14:28 GMT
Organization: Relational Data Systems, Irvine, CA

In <2ucsnd$[e-mail]> [e-mail] (Ted Rypma) writes:

>graham hesselroth ([e-mail]) 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 <[e-mail]>      Relational Data Systems
                                             30 Executive Park, Suite 260
Eat right.  Exercise.  Die anyway.           Irvine, CA 92714
                                             [phone]

+++++++++++++++++++++++++++

>From [e-mail] (Charlie Reiman)
Date: Sat, 25 Jun 1994 05:43:44 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

[e-mail] (Mark D. Nagel) writes:

>In <2ucsnd$[e-mail]> [e-mail] (Ted Rypma) writes:

>>graham hesselroth ([e-mail]) 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
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Jim Browne)
Date: 28 Jun 94 02:44:22 GMT
Organization: University of Illinois at Urbana

[e-mail] (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         [e-mail]
    There are more stoplights in Sunnyvale, CA. than people in my hometown.

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

>From [e-mail] (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:

"0%%%%%%/% | % % P %%%"|%%"Q"%%%0%"

Uhhhhh...what is this?  Hex, right?  How do/can I see the
actual Roman script (i.e., legible) name of the app/init/
whatever that went out of control?  A helpful sequence of
commands would be most appreciated.

What I'd like to do is either A) isolate the offender and
remove it, or B) figure out how to make it get along with
everything else.

Also, What do the files MrBusError and EvenBetterBusError
do, actually (in newbie-ease, please)?  The ReadMes with
these files indicated each would *help* with debugging, but,
like their names imply (and from experience, now) I realize
they actually *cause* a BusError, not prevent one.  Am I
wrong?  On separate occasions I've had each in my System
folder, but found they caused more problems then I'm
presently capable of handling.

I'm thinking maybe there's just something I haven't done to
configure MacsBug so it's customized to my system...

LCIII, 8/120+270, 7.1w/HSU3.0, MacsBug 6.5d6

All pointers humbly accepted with appreciation.

-tpg

^^
Tim Guinn
Austin, Texas US                  ~ Sine Metu ~
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Robert S. Mah)
Date: Fri, 24 Jun 1994 03:14:55 -0500
Organization: One Step Beyond

[e-mail] (Tim Guinn) wrote:

> 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:
>
> "0/ |   P "|"Q"0"
>
> Uhhhhh...what is this?  Hex, right?  How do/can I see the actual
> Roman script (i.e., legible) name of the app/init/whatever that
> went out of control?  A helpful sequence of commands would be most

First, the address "000360980" is the location of the _instruction_
that caused the bus error, not the location of the name of the
application.  The second number is the probable address (usually
bogus) that the instruction was trying to access.

The current application is always displayed in the status area on the
left, just under the title "CurApName".  Alternatively, you can type
CurApName to display it.  P.S. the app's name is always at 0x0910.

To find out what caused the problem, you have to be pretty knowledgable
about the OS.  You can fool around with the "wh" command, which tells
you memory block containing the address or the location of a trap.  If
it's in the system heap, it _may_ be an extension that's causing the
problem.  Then again, maybe not...you have to examine the code to be
sure.  Other useful commands include "sc" or "sc7" which do a stack
crawl so you can see the call chain.

The long and the short of it is, however, that if you don't know the
internals of the code that crashed, and "es" doesn't work, then you'll
probably have to reboot.


> Also, What do the files MrBusError and EvenBetterBusError do,
> actually (in newbie-ease, please)?  The ReadMes with these files
> indicated each would *help* with debugging, but, like their names
> imply (and from experience, now) I realize they actually *cause*
> a BusError, not prevent one.  Am I wrong?  On separate occasions

No, you are right.  Both extensions are tools to aid programmers in
finding bugs in their programs by intercepting or causing certain
common errors to maniftest themselves.  If you're not developing some
sort of software, remove them.

Cheers,
Rob
___________________________________________________________________________
Robert S. Mah  -=-  One Step Beyond  -=-  212-947-6507  -=-  [e-mail]

+++++++++++++++++++++++++++

>From Jens Alfke <[e-mail]>
Date: Fri, 24 Jun 1994 20:46:09 GMT
Organization: Apple Computer

Okay, here's a tutorial on your friend EvenBetterBusError:

Tim Guinn, [e-mail] writes:
> Also, What do the files MrBusError and EvenBetterBusError
> do, actually (in newbie-ease, please)?  The ReadMes with
> these files indicated each would *help* with debugging, but,
> like their names imply (and from experience, now) I realize
> they actually *cause* a BusError, not prevent one.

Yes. EBBE (which supersedes MrBE) is your friend -- it turns some types of
bugs that ordinarily cause intermittent and hard-to-reproduce crashes, into
guaranteed crashers. The types of bugs it catches are (a) dereferencing a
NULL handle; and (b) writing to a NULL pointer. For instance:

PicHandle p = GetPicture(128);
Rect r = (**p).picFrame ;

Oops, I forgot to put a PICT 128 resource in my application, so the second
line is dereferencing a NULL pointer. Ordinarily location zero, which isn't
used by anything on the system, contains some random garbage left over from
startup. So the effect of the second line is to read eight bytes of stuff
from some random location in memory. This is bad and may cause a crash later.
And occasionally the garbage at location zero points to a nonexistent memory
address, in which case you get a bus error.
  What EBBE does is periodically (60x per second) write a particular garbage
value, 0x50FF8001, into location 0. This value has the characteristic that
it's not a valid memory address on any Mac configuration, so dereferencing it
(by dereferencing a NULL pointer) will always cause a crash. So if you get a
bus error and notice 50FF8001 (or some nearby value) in the register in
question, suspect a NULL handle in your code.
  Incidentally, you can often recover from a crash caused by EBBE by writing
a valid address into the register that has 50FF8001 in it, and continuing.
Just enter:
  A0=@rombase; g
but using the appropriate trashed register instead of A0.
  EBBE also warns you of jumps to NULL (calling a procedure pointer whose
value is NULL, or jumping into a purged code resource) since 50FF is an
invalid 68000 instruction. Jumps to NULL will almost certainly kill you in
any case, but with EBBE yor code stops immediately and it's easier to tell
what happened.

The second thing EBBE does is, when it periodically writes the magic value
into NULL, it first checks whether the value it last wrote has been changed.
If so, this means somebody wrote to NULL, and it will then warn you via a
DebugStr reading "Write to NIL!". Unfortunately up to one tick may have
elapsed since the offending write, so it's harder to track down what's wrong,
but it's still good to know. You can continue after this; it's just a warning.
Here's an example of code that writes to NULL:

long *p = NewPtr(sizeof(long));
*p = 0x12345678;

If you're out of memory, or your heap is hosed, NewPtr will fail and return
NULL, whereupon the second line will write into location zero. One tick later
EBBE will tell you about this. If you do a "dm 0" and look at the value
there, it might tip you off...

--Jens Alfke
  jens_alfke@powertalk              Rebel girl, rebel girl,
            .apple.com              Rebel girl you are the queen of my world

+++++++++++++++++++++++++++

>From [e-mail] (Wayne Walrath)
Date: Mon, 27 Jun 1994 15:02:35 +0100
Organization: RFE/RL Inc.

In article <[e-mail]>,
[e-mail] (Tim Guinn) wrote:

> 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.

<snip>

> All pointers humbly accepted with appreciation.
>
> -tpg
>
> ^^
> Tim Guinn
> Austin, Texas US                  ~ Sine Metu ~
> [e-mail]

Tim,
  If you are interested in understanding a little better what Macsbug is
showing you, and being able to maneuver a bit better in that "underworld",
pick up a copy of the book, "Debugging Mac Software with Macsbug" by Straus
and Othmer $34.95 and available from APDA. It's a great reference and
tutorial to have around.

-wayne

________)|(________
[e-mail]
   RFE/RL Inc.

+++++++++++++++++++++++++++

>From [e-mail]
Date: 27 Jun 1994 16:41:27 GMT
Organization: Institute of Space and Atmospheric Studies, Univ. of Sask.

In article <[e-mail]> [e-mail] (Wayne Walrath) writes:
>  If you are interested in understanding a little better what Macsbug is
>showing you, and being able to maneuver a bit better in that "underworld",
>pick up a copy of the book, "Debugging Mac Software with Macsbug" by Straus
>and Othmer $34.95 and available from APDA.

Would anyone happen to have the ISBN number for that book?

Thanks in advance,
Greg.

- ------------------------------------------------------------------------
|     Greg Hammel :  [e-mail] or [e-mail]      |
|                                                                        |
|     Disclaimer: I'm not quite sure who I speak for.                    |
|                                                                        |
|     "I'm a citizen of Legoland travellin Incommunicado" - Fish         |
- ------------------------------------------------------------------------

+++++++++++++++++++++++++++

>From [e-mail] (Tim Guinn)
Date: Mon, 27 Jun 1994 22:30:05 -0600
Organization: The University of Texas at Austin, Austin, Texas

In article <2umvfn$[e-mail]>, [e-mail] wrote:

> In article <[e-mail]> [e-mail] (Wayne Walrath) writes:
> >  If you are interested in understanding a little better what Macsbug is
> >showing you, and being able to maneuver a bit better in that "underworld",
> >pick up a copy of the book, "Debugging Mac Software with Macsbug" by Straus
> >and Othmer $34.95 and available from APDA.
>
> Would anyone happen to have the ISBN number for that book?
=======================================

0-201-57049-1

I'm *SLOWLY* working my way through it 8-)  The only problem
I have with it is that it comes with the older MacsBug.  But
you can get v6.5d6 in two places I know of:

a. develop
b. ftp.apple.com (sorry, don't know the path)

-tpg

^^
Tim Guinn
Austin, Texas US                  ~ Sine Metu ~
[e-mail]

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

>From Ricardo Marimon <[e-mail]>
Subject: Receiving Events in AppleScript
Date: 28 Jun 1994 01:30:00 GMT
Organization: Stanford University

Hi people,

I want to know if there is any way in which I could write a
Script (using Apple's ScriptEditor) that accepts events send
to it from other applications.  My particular use would be to
instruct Eudora to send my Script a message whenever it
receives a new message.

I know that Eudora sends an 'eNot' event with parameters the
references to all the newly received messages.  Then my script
could do some processing on this messages, such as delete
them, or automatically reply to some of them; things easily
done using AppleScript and Eudora.

I will appreciate any help on this issue.  Thanks in advance,


Ricardo Marimon
[e-mail]

- -
I type my signature every time.  And you?  :-)

+++++++++++++++++++++++++++

>From Jens Alfke <[e-mail]>
Date: Tue, 28 Jun 1994 21:11:25 GMT
Organization: Apple Computer

Ricardo Marimon, [e-mail] writes:
> I want to know if there is any way in which I could write a
> Script (using Apple's ScriptEditor) that accepts events send
> to it from other applications.

You add a handler for that event to the script, then save it as an app. There
are sample scripts that come with AS (on the CD at least) that illustrate
this. It gets trickier when the event is non-standard, since AS doesn't know
the terminology for the event. You probably have to use the << ... >>
notation with the raw 4-letter codes, and I can never remember where that
syntax is documented...

--Jens Alfke
  jens_alfke@powertalk              Rebel girl, rebel girl,
            .apple.com              Rebel girl you are the queen of my world

+++++++++++++++++++++++++++

>From [e-mail] (Hector Levesque)
Date: 28 Jun 94 17:19:49 GMT
Organization: U. of Toronto

In article <2unueo$[e-mail]>, Ricardo Marimon
<[e-mail]> wrote:
> I want to know if there is any way in which I could write a
> Script (using Apple's ScriptEditor) that accepts events send
> to it from other applications.  My particular use would be to
> instruct Eudora to send my Script a message whenever it
> receives a new message.
>
> I know that Eudora sends an 'eNot' event with parameters the
> references to all the newly received messages.  Then my script
> could do some processing on this messages, such as delete
> them, or automatically reply to some of them; things easily
> done using AppleScript and Eudora.

Yup.  Write a script with a handler like this

     on <<event CSOmeNot>> msgList
        --
        -- actions to take when notified
        --
     end <<event CSOmeNot>>

where << means option-\ and >> means option-shift-\, then save it as a
stay-open application. Then you need to tell Eudora to send its notify
message to this application, at which time your handler will be called.
Note that the application needs to be a stay-open application, so that if
you want to quit after you've handled the notification, you need to inlcude
a quit command.

--
Hector Levesque
U. of Toronto
[e-mail]

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

>From [e-mail] (Carlo Martino)
Subject: [Q] ReleaseResource, PICTs and handles
Date: 24 Jun 94 02:37:19 GMT
Organization: Harvard University, Cambridge, Massachusetts

I began programming for the Mac less than a week ago, although
I have some prior familiarity with C and C++ for DOS/Windows.

I am using Symantec C++.  My question regards PictHandles and
generic resource handles and the relations between them.  I get
a PICT using GetPicture(int ResID).  When it comes time to
release said PICT, ReleaseResource will not accept the PictHandle
returned by GetPicture.  This is somewhat sensible, as
ReleaseResource is defined as accepting a Handle, not a
PictHandle.  But I assume there is some way to release my PICT
resource.

Any help would be greatly appreciated.

Thank you in advance.

+++++++++++++++++++++++++++

>From [e-mail] (John W. Baxter)
Date: Fri, 24 Jun 1994 08:37:37 -0700
Organization: Internet for the Olympic Peninsula

In article <[e-mail]>,
[e-mail] (Carlo Martino) wrote:

> I began programming for the Mac less than a week ago, although
> I have some prior familiarity with C and C++ for DOS/Windows.
>
> I am using Symantec C++.  My question regards PictHandles and
> generic resource handles and the relations between them.  I get
> a PICT using GetPicture(int ResID).  When it comes time to
> release said PICT, ReleaseResource will not accept the PictHandle
> returned by GetPicture.  This is somewhat sensible, as
> ReleaseResource is defined as accepting a Handle, not a
> PictHandle.  But I assume there is some way to release my PICT
> resource.

Cast the PicHandle to a generic Handle:

   ReleaseResource ((Handle)myPictureHandle);

Yes...casts are evil.  For things like this, they are necessary.
--
John Baxter    Port Ludlow, WA, USA  [West shore, Puget Sound]
   No hablo Intel.
   [e-mail]

+++++++++++++++++++++++++++

>From Mark Hanrek <[e-mail]>
Date: Sun, 26 Jun 1994 07:02:32 GMT
Organization: The Information Workshop

In article <[e-mail]> Carlo Martino,
[e-mail] writes:

> I am using Symantec C++.  My question regards PictHandles and
> generic resource handles and the relations between them.  I get
> a PICT using GetPicture(int ResID).  When it comes time to
> release said PICT, ReleaseResource will not accept the PictHandle
> returned by GetPicture.  This is somewhat sensible, as
> ReleaseResource is defined as accepting a Handle, not a
> PictHandle.  But I assume there is some way to release my PICT
> resource.

When there is a type mismatch, it helps to think of it as simply the
signal that a human must intervene and decide what to do.

Unfortunately, there are no clear cut rules, otherwise, the compiler
could handle it.  The rules are ones that humans can easily deal with,
but only once we have learned what they are.

Chicken or the egg.

In order to learn, you must have working example source code handy, so
you can see what others have done.  I don't know of any reference book
that can help you with this, and when you think about it, the best
language to communicate such things is "example source code".

I and many others live by the approach of always keeping an eye peeled
for example source code that covers certain areas of programming that we
either need at the moment or will be needing, and downloading it when we
come across it.

- ---

There is no convenient way to declare types for things, yet also indicate
when certain types are "equivalent" in given certain situations.

In your case, it is 100% okay to ReleaseResource a PicHandle obtained
from GetResource.  A handle is a handle from ReleaseResource and
DisposeHandle's point of view, yet in the real programming world we also
have sub-types of handles based on what is in them, such as PicHandles.

Casting is a way the language allows us to temporarily change the type of
something, in a given situation, to get the COMPILER out of the fix of
not being able to understand "programming" adequately.


Hope this helps clarify things.

Mark Hanrek

P.S. Another really helpful thing to do is:  you should ALWAYS have
enabled "Check Pointer Types" and "Require Prototypes".

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

>From [e-mail] (Joshua Grass)
Subject: computer strategy
Date: 27 Jun 1994 21:34:30 GMT
Organization: University of Massachusetts, Amherst

I finished writing a mac game that is a pretty fun to play with two
people, but I would like to make it so that the computer can play as
well.  I'm pretty well versed in AI so I understand how hard it can
be for a computer to play any game, but I was curious if anyone had
any experience on computer strategy and possible "cheats" in the sense
of fairly simple algorithms that make the computer play (or appear to
play) a game well.  My game is cross between spaceward ho! and strategic
conquest if that helps any.  Any ideas about small memory, fairly quick
time algorithms that would help the computer would be great.  Thanks

                        Joshua



+++++++++++++++++++++++++++

>From [e-mail] (Robert S. Mah)
Date: Tue, 28 Jun 1994 00:24:34 -0500
Organization: One Step Beyond

[e-mail] (Joshua Grass) wrote:

> I finished writing a mac game that is a pretty fun to play with two
> people, but I would like to make it so that the computer can play as
> well.  I'm pretty well versed in AI so I understand how hard it can
> be for a computer to play any game, but I was curious if anyone had
> any experience on computer strategy and possible "cheats" in the sense
> of fairly simple algorithms that make the computer play (or appear to
> play) a game well.  My game is cross between spaceward ho! and strategic
> conquest if that helps any.  Any ideas about small memory, fairly quick
> time algorithms that would help the computer would be great.  Thanks

Ooooh, sounds like a game I would love!

I think it would help a lot if you could describe the game a bit more,
but here are some off-the-cuff suggestions.

First is to have different behaviours associated with each unit, depend-
ing upon it's condition, locality of allied units and locality of enemy
units.  For example, a unit could have three modes: aggressive, defensive,
"dig in", retreat, etc.  Based on relative strengths and this mode, one
could determine the unit's behaviour.

As for attacks, have the unit do some sort of calculation on enemy units
to the unit to attack.  Note that, the algorithm used is dependent upon
what kinds of military tactics you subscribe to.  Or possibly let the
choice of algorithm be based on the kind of virtual general.

Finally, there is a book called "Computer Games" or somesuch that
describes a wide variety of tactics that computer games can take vs
human beings.  Can't remember the title, but I _know_ it had sections
on military style simulations.  Another book I remember reading was
one that did simulations based on "spheres of infulence".  This may
help the computer set up global level strategies.

Cheers,
Rob
___________________________________________________________________________
Robert S. Mah  -=-  One Step Beyond  -=-  212-947-6507  -=-  [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Doctor Caligari)
Date: 28 Jun 1994 13:38:56 GMT
Organization: Cesare Somnambulisms

In article <[e-mail]>, [e-mail]
(Robert S. Mah) wrote:

> [e-mail] (Joshua Grass) wrote:

[...]

> Finally, there is a book called "Computer Games" or somesuch that
> describes a wide variety of tactics that computer games can take vs
> human beings.  Can't remember the title, but I _know_ it had sections
> on military style simulations.  Another book I remember reading was
> one that did simulations based on "spheres of infulence".  This may
> help the computer set up global level strategies.
>
    Could you dig out the names of those books?

+++++++++++++++++++++++++++

>From [e-mail] (Nick Parlante)
Date: 28 Jun 1994 22:41:47 GMT
Organization: Stanford University

In article <[e-mail]>, [e-mail]
(Robert S. Mah) wrote:

> [e-mail] (Joshua Grass) wrote:
>
> > I finished writing a mac game that is a pretty fun to play with two
> > people, but I would like to make it so that the computer can play as
> > well.  I'm pretty well versed in AI so I understand how hard it can
> > be for a computer to play any game, but I was curious if anyone had
> > any experience on computer strategy and possible "cheats" in the sense
> > of fairly simple algorithms that make the computer play (or appear to
> > play) a game well.  My game is cross between spaceward ho! and strategic
> > conquest if that helps any.  Any ideas about small memory, fairly quick
> > time algorithms that would help the computer would be great.  Thanks
>
> Ooooh, sounds like a game I would love!
>
> I think it would help a lot if you could describe the game a bit more,
> but here are some off-the-cuff suggestions.
>
> First is to have different behaviours associated with each unit, depend-
> ing upon it's condition, locality of allied units and locality of enemy
> units.  For example, a unit could have three modes: aggressive, defensive,
> "dig in", retreat, etc.  Based on relative strengths and this mode, one
> could determine the unit's behaviour.
>
> As for attacks, have the unit do some sort of calculation on enemy units
> to the unit to attack.  Note that, the algorithm used is dependent upon
> what kinds of military tactics you subscribe to.  Or possibly let the
> choice of algorithm be based on the kind of virtual general.
>
> Finally, there is a book called "Computer Games" or somesuch that
> describes a wide variety of tactics that computer games can take vs
> human beings.  Can't remember the title, but I _know_ it had sections
> on military style simulations.  Another book I remember reading was
> one that did simulations based on "spheres of infulence".  This may
> help the computer set up global level strategies.
>
> Cheers,
> Rob
> ___________________________________________________________________________
> Robert S. Mah  -=-  One Step Beyond  -=-  212-947-6507  -=-  [e-mail]

Here's a technique that's worked well for me (I used it to create
a strategy for playing Tetris well, but it should work for any
game)--

1) Code up a BestMove() or whatever function which
numerically evaluates the quality of a given move or position.
Internally, the function should rely liberally on numeric
constants such as...

kTankOffense // the offensive value of a "tank"
kTankOffenseDecay // how much the threat of a tank decreases
the further you are from it

// A squadron of planes has a net offense which is a linear
function of the number of planes
kPlaneY  // the y-intercept
kPlaneSlope  // the slope


etc. etc.

So the point is, you structure a strategy which seems
reasonable, but any time there's a tradeoff or something you're
not sure about, you defer it to a float constant.

2) So now the problem is reduced to finding values for the
constants which yield a good strategy. Traditional hill-climbing
methods to optimize the constants will have problems because
the search space has a large number of dimensions (one for
each constant) and whatever "rating" function you make up to
rate the quality of a particular strategy is likely to be
discontinuous.

Fortunately, Genetic Algorithms are ideal for searching this sort
of large, discontinuous space. Here's the 10-second guide to
genetic algorithms: create a population of maybe 500 different
randomly generated strategies. Rate them all in some way by
having them all play a fixed strategy, or by having them play
each other. And finally recombine/breed the best individuals
from the old generation to make children for a new generation.
Just as it goes in the real world according to Darwin, the
individuals from the old generation with the highest ratings
should be proportionately more likely to be chosen as parents.

Genetic algorithms are not too hard to code up, but they can
consume a lot of CPU time. Check out Goldberg's book Genetic
Algorithms in Optimization and Somethingorother. Koza's
mammoth GA book describes a more flexible but potentially
more costly approach.

The quality of the strategy you get will depend very much on
the metrics and insights which you encode in the BestMove()
function in step (1) as well as the "rating" function you use to
guide the optimization in step (2). I've used this technique to
create a strategy which plays Tetris an order of magnitude
better than anything I was able to code up on my own without
the genetic algorithm doing the optimization.

Cheers,

Nick

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

End of C.S.M.P. Digest
**********************