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

Text File | 2010-09-21 | 77KB | 1,979 lines

Received-Date: Fri, 13 May 1994 00:30:51 +0200
From: [e-mail] (Francois Pottier)
Subject: csmp-digest-v3-026
To: [e-mail]
Date: Fri, 13 May 94 0:30:43 MET DST
X-Mailer: ELM [version 2.3 PL11]
Errors-To: [e-mail]
Reply-To: [e-mail]
X-Sequence: 29

C.S.M.P. Digest             Thu, 12 May 94       Volume 3 : Issue 26

Today's Topics:

        Can I send Apple Event from Script Editor?
        Disk Cache performance evaluation test software
        Extension Shell 1.3 - Help for INIT writers
        FFT benchmark using CodeWarrior
        How do I find the window colour ???
        Private inheritance faulty in SC++ 7.0
        Source Control Questions
        Using xlc to generate PowerMacintosh code



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 as comp.sys.mac.programmer.src.


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

>From [e-mail] (Masaaki Iwasa)
Subject: Can I send Apple Event from Script Editor?
Date: Wed, 27 Apr 1994 09:03:56 GMT
Organization: Nippon Motorola Limited,  Tokyo  Japan

Dose someone know if an Apple Event can be sent from within Script Editor
to an Apple Event aware but not Apple Scriptable program?

I want to send Apple events to Microsoft Project 3.0 from Script Editor. I
know I can send them from HyperCard.

No way??

--
Masaaki Iwasa                    LMPS, Nippon Motorola Limited
Email: [e-mail]   /  [e-mail]

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

>From [e-mail] (John W. Baxter)
Date: Thu, 28 Apr 1994 07:28:26 -0700
Organization: Internet for the Olympic Peninsula

In article <RTY868-270494180057@180.3.150.33>, [e-mail]
(Masaaki Iwasa) wrote:

> Dose someone know if an Apple Event can be sent from within Script Editor
> to an Apple Event aware but not Apple Scriptable program?
>
> I want to send Apple events to Microsoft Project 3.0 from Script Editor. I
> know I can send them from HyperCard.

You can send arbitrary Apple events to any application which has the proper
bit set to say it accepts high level events.

The syntax in AppleScript for doing so is rather ugly...if you have Think
Project Manager 6 (or, likely 7, but I'm not sure of that), try turning
recording on in the Script Editor, then going into Think Project Manager
and changing the option regarding the generation of MacsBug symbols.  That
should record as a generic event, and give you an idea of the syntax.

UserLand Frontier provides a somewhat clearer syntax for sending such
events...in either scripting system, you can of course write subroutines
which hide the gory mess from the rest of your code.

--
John Baxter    Port Ludlow, WA, USA  [West shore, Puget Sound]
   [e-mail]

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

>From [e-mail] (Mike Cohen)
Date: Thu, 28 Apr 1994 18:29:22 GMT
Organization: ISIS International

[e-mail] (Masaaki Iwasa) writes:

>Dose someone know if an Apple Event can be sent from within Script Editor
>to an Apple Event aware but not Apple Scriptable program?

>I want to send Apple events to Microsoft Project 3.0 from Script Editor. I
>know I can send them from HyperCard.

>No way??

>--
>Masaaki Iwasa                    LMPS, Nippon Motorola Limited
>Email: [e-mail]   /  [e-mail]

you can send any event using something like:
 tell application "foo" to <<event XXXXYYYY>> directobject given
    <<class ZZZZ>> someotherparam

Note that the << and >> should really be opt-backslash & shift-opt-backslash.
--
Mike Cohen - [e-mail]
NewtonMail, eWorld: MikeC / ALink: D6734 / AOL: MikeC20

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

>From [e-mail] (Paul G Smith)
Date: Thu, 28 Apr 94 21:45:33 GMT
Organization: commstalk, & Full Moon Software Inc


In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (Mike Cohen) writes:
>
> >Dose someone know if an Apple Event can be sent from within Script Editor
> >to an Apple Event aware but not Apple Scriptable program?
>
> >I want to send Apple events to Microsoft Project 3.0 from Script Editor. I
> >know I can send them from HyperCard.
>
> >No way??
>
> >--
> >Masaaki Iwasa                    LMPS, Nippon Motorola Limited
> >Email: [e-mail]   /  [e-mail]
>
> you can send any event using something like:
>  tell application "foo" to <<event XXXXYYYY>> directobject given
>     <<class ZZZZ>> someotherparam
>

There is another way to do this... not guaranteed to be the best solution
for your needs, but it will make for easier scripting:

Why not create an 'aete' resource for Microsoft Project? It's not
a trivial task, admittedly, but it's not all that hard (especially
if you take one from another app to use as a starting point). There
is a template for ResEdit for editing aete resources. When you have
done this, and given a human-readable terminology to the apple events,
you'll find it _very_ easy to script them from the Script Editor.


best regards, Paul

- --------------------------------------------------------------
Paul G Smith, Commstalk HQ          ||  UK ph: [phone]
P O Box 116, ST ALBANS              ||    fax: [phone]
Hertfordshire. AL1 2RL. UK          ||  US ph: 408 253 7199
& Full Moon Software, Inc           ||    fax: [phone]
P O Box 700237, SAN JOSE, CA 95170  ||  AppleLink: COMMSTALK.HQ

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

>From Stuart Cheshire <[e-mail]>
Subject: Disk Cache performance evaluation test software
Date: 9 Apr 1994 17:38:54 GMT
Organization: Stanford University

The test program writes 512K to disk, using various block sizes, from 1024
FSWrite calls of 512 bytes each to 32 FSWrite of 16K each.

Each test is done three ways, firstly with simple FSWrite, then with FSWrite
alternating with PBFlushFile, and then with FSWriteNoCache.

The first is what you might naively write in a program which is trying to run
cooperatively in the background while transferring a file to disk. It results
in all the writes going to the cache, and then the Mac freezes solid for ten
seconds when the file is closed.

The second is an attempt to fix this by flushing the file to disk after every
write. It achieves the goal of spreading the delay over all the writes,
instead of having a big freeze at the end, but it still takes over 10 seconds.

The third method was pointed out to me by Jim Matthews (author of Fetch). It
uses the little known (but supported -- see IM:Files, page 89) non-caching
option of PBWrite.
Similarly, this achieves the goal of spreading the delay over all the writes,
but it also makes it go up to 25 times faster.

Results:

Tests were performed with a Macintosh Quadra 700, System 7.0.1/Tuneup 1.1.1,
768KB disk cache, 32 bit addressing, no virtual memory, 20MB RAM:

Testing Writing 512K in various block sizes
Testing 0.5K blocks
Standard writes:    Write:  39 (! 0s)  Close: 691 (!11s)  Total: 730 (!12s)
Write and flush:    Write: 689 (!11s)  Close:   1 (! 0s)  Total: 690 (!11s)
No-cache writes:    Write: 689 (!11s)  Close:   1 (! 0s)  Total: 690 (!11s)
Testing   1K blocks
Standard writes:    Write:  26 (! 0s)  Close: 691 (!11s)  Total: 717 (!11s)
Write and flush:    Write: 691 (!11s)  Close:   1 (! 0s)  Total: 692 (!11s)
No-cache writes:    Write: 346 (! 5s)  Close:   0 (! 0s)  Total: 346 (! 5s)
Testing   2K blocks
Standard writes:    Write:  23 (! 0s)  Close: 692 (!11s)  Total: 715 (!11s)
Write and flush:    Write: 691 (!11s)  Close:   0 (! 0s)  Total: 691 (!11s)
No-cache writes:    Write:  85 (! 1s)  Close:   0 (! 0s)  Total:  85 (! 1s)
Testing   4K blocks
Standard writes:    Write:  21 (! 0s)  Close: 692 (!11s)  Total: 713 (!11s)
Write and flush:    Write: 691 (!11s)  Close:   1 (! 0s)  Total: 692 (!11s)
No-cache writes:    Write:  51 (! 0s)  Close:   0 (! 0s)  Total:  51 (! 0s)
Testing   8K blocks
Standard writes:    Write:  21 (! 0s)  Close: 691 (!11s)  Total: 712 (!11s)
Write and flush:    Write: 690 (!11s)  Close:   1 (! 0s)  Total: 691 (!11s)
No-cache writes:    Write:  39 (! 0s)  Close:   0 (! 0s)  Total:  39 (! 0s)
Testing  16K blocks
Standard writes:    Write:  17 (! 0s)  Close: 692 (!11s)  Total: 709 (!11s)
Write and flush:    Write: 694 (!11s)  Close:   0 (! 0s)  Total: 694 (!11s)
No-cache writes:    Write:  26 (! 0s)  Close:   1 (! 0s)  Total:  27 (! 0s)

Notice that:

1. With the simple writes, every block size, even 16K, incurs a Mac-crippling
ten second freeze when the file is closed.

2. Using write and flush takes the same time as simple writes, but spread
over all the Write calls instead of in a single big freeze at the end.

3. In BOTH of the above cases, it takes at best 691 ticks to write 512K,
making a data rate of 44.5K/sec.

4. Using No-cache writes incurs no freeze for the close call, and if you are
writing 4K blocks it achieves 602K/sec, more than ten times faster than the
simple writes. If you are prepared to go to 16K blocks, it exceeds a
megabyte per second -- more than 25 times faster than simple writes with
the same block size.

If anyone wishes to run the test program and give me results for other
configurations, why not post those results here.

Stuart Cheshire <[e-mail]>
 * <A HREF="file://brubeck.stanford.edu/www/cheshire-bio.html">WWW</A>
 * Stanford Distributed Systems Group Research Assistant
 * Escondido Village Resident Computer Coordinator
 * Macintosh Programmer
>From Stuart Cheshire <[e-mail]>
Subject: Disk Cache performance evaluation test software
Date: 9 Apr 1994 18:48:06 GMT
Organization: Stanford University

// Copyright (C) 23rd November 1993
// Stuart Cheshire <[e-mail]>

#include <stdio.h>
#include <stdlib.h>

#define FILE_SIZE      0x80000
#define MAX_BLOCK_SIZE 0x4000
static char *buffer;
static SysEnvRec sysenvirons;
static const unsigned char filename[] = "\pFlusherTestFile";
static IOParam fileflusher;

static OSErr FSWriteNoCache(short refnum, long *count_p, const Ptr buffer_p)
    {
    OSErr retcode;
    ParamBlockRec pb;
    pb.ioParam.ioCompletion = 0;
    pb.ioParam.ioRefNum     = refnum;
    pb.ioParam.ioBuffer     = buffer_p;
    pb.ioParam.ioReqCount   = *count_p;
    pb.ioParam.ioPosMode    = fsAtMark | 0x20; /* don't cache */
    pb.ioParam.ioPosOffset  = 0;
    retcode = PBWrite(&pb, false);
    *count_p = pb.ioParam.ioActCount;
    return(retcode);
    }

static void filetest(unsigned long block_size, short testcase)
    {
    long inOutCount, t1, t2, t3;
    short fRefNum, i, num_blocks = FILE_SIZE / block_size;
    FSDelete(filename, sysenvirons.sysVRefNum);
    if (Create(filename, sysenvirons.sysVRefNum, '????', '????'))
        { printf("Create failed\n"); exit(1); }
    if (FSOpen(filename, sysenvirons.sysVRefNum, &fRefNum))
        { printf("FSOpen failed\n"); exit(1); }
    fileflusher.ioCompletion = NULL;
    fileflusher.ioResult     = noErr;
    fileflusher.ioRefNum     = fRefNum;
    t1 = TickCount();
    for (i=0; i<num_blocks; i++)
        {
        inOutCount = block_size;
        switch (testcase)
            {
            case 0: FSWrite(fRefNum, &inOutCount, buffer);
                    break;
            case 1: FSWrite(fRefNum, &inOutCount, buffer);
                    if (fileflusher.ioResult == noErr)
                        PBFlushFile((ParmBlkPtr)&fileflusher, TRUE);
                    break;
            case 2: FSWriteNoCache(fRefNum, &inOutCount, buffer);
                    break;
            }
        }
    t2 = TickCount();
    if (FSClose(fRefNum)) { printf("FSClose failed\n"); exit(1); }
    t3 = TickCount();
    FSDelete(filename, sysenvirons.sysVRefNum);
    printf("Write:%4ld (!%2lds)  ", t2-t1, (t2-t1)/60);
    printf("Close:%4ld (!%2lds)  ", t3-t2, (t3-t2)/60);
    printf("Total:%4ld (!%2lds)\n", t3-t1, (t3-t1)/60);
    }

static void blocktest(unsigned long block_size)
    {
    printf("Standard writes:    "); filetest(block_size, 0);
    printf("Write and flush:    "); filetest(block_size, 1);
    printf("No-cache writes:    "); filetest(block_size, 2);
    }

void main(void)
    {
    buffer = NewPtr(MAX_BLOCK_SIZE);
    if (!buffer) { printf("Not enough memory\n"); exit(1); }
    SysEnvirons(curSysEnvVers, &sysenvirons);
    printf("Testing Writing %ldK in various block sizes\n", FILE_SIZE / 1024);
    printf("Testing 0.5K blocks\n"); blocktest( 0x200);
    printf("Testing   1K blocks\n"); blocktest( 0x400);
    printf("Testing   2K blocks\n"); blocktest( 0x800);
    printf("Testing   4K blocks\n"); blocktest(0x1000);
    printf("Testing   8K blocks\n"); blocktest(0x2000);
    printf("Testing  16K blocks\n"); blocktest(0x4000);
    }


Stuart Cheshire <[e-mail]>
 * <A HREF="file://brubeck.stanford.edu/www/cheshire-bio.html">WWW</A>
 * Stanford Distributed Systems Group Research Assistant
 * Escondido Village Resident Computer Coordinator
 * Macintosh Programmer

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

>From [e-mail] (Peter Kocourek)
Date: Sun, 10 Apr 1994 15:45:39 +0100
Organization: (none)

Stuart Cheshire wrote in a message on 09 Apr 94

[... test results deleted]

 SC> Notice that:
 SC> 1. With the simple writes, every block size, even 16K, incurs
 SC> a Mac-crippling ten second freeze when the file is closed.

Actually, this depends on the size of the cache; the smaller the cache, the
sooner you'll get decent performance with increasing block size. Once a certain
threshold is passed (in terms of blocksize vs. cachesize), the performance will
improve enormously. Unfortunately, even with just a 32K cache, you need a
fairly large blocksize (I forget the exact figures). I have run similar tests
with a port of the Unix iozone program, which benchmarks file system
performance, and that's how I discovered the rather useless nature of the
cache. I did not know about the no-cache bit, though...


YHS:QSI!


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

>From [e-mail] (Bill Benson)
Date: Tue, 12 Apr 1994 15:13:52 -0800
Organization: Lawrence Berkeley Lab

Does anyone know if there would be any (significant) performance gain from
disabling the cache while reading? (as opposed to writing)
-Bill Benson, Lawrence Berkeley Lab, [e-mail]

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

>From [e-mail] (Alan B. Harper)
Date: Tue, 12 Apr 94 02:04:15 PST
Organization: Berkeley Macintosh Users Group

There was an interesting note by Mike Scanlin in MacTech magazine (April 1993,
p. 75)
about the Apple disk cache.  I can't quote the entire article, but a relevant
section is

> The formula [Apple] uses to decide if any given read or write should
> be cached is:
>   numCacheBlocks = user-defined cache size DIV 512;
>   maxCachedReadWrite = (numCacheBlocks - 1) * 16;
> So with a cache size of 256K you get
>     numCacheBlocks = 512;
>   maxCachedReadWrite = 8176
> That means that any read/write larger than 8176 bytes will not be cached.  So
in
> my test app [described in the article], nothing was being cached until the
cache
> was 384K or larger, at which time my 8K writes were being cached (and I got
> a 13x performance slow-down).

Basically, this means that if your app either does its own caching, or if it
writes something it knows it won't need again, always set the no-cache bit.

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

>From [e-mail] (Peter N Lewis)
Date: Thu, 14 Apr 1994 16:08:37 +0800
Organization: NCRPDA, Curtin University

In article <[e-mail]>, [e-mail] (Alan B.
Harper) wrote:

>Basically, this means that if your app either does its own caching, or if it
>writes something it knows it won't need again, always set the no-cache bit.

Not entirely.  Even if you know it will be read again, it is often better
to disable the cache.  For example, I get better performance out of
Anarchie downloading files and then feeding them to StuffIt Expander if
the cache is inhibited during the download even though I know Expander
will read the file as soon as I'm finished.

Basically, disable the cahce unless you are writing 10 byte blocks, and
*DONT* write ten byte blocks!  If you write lots of small blocks, the
FSClose time goes exponential, at least in tests I did.  Writing a 1 Meg
file could end up with close times measured in minutes.
   Peter.
_______________________________________________________________________
Peter N Lewis <[e-mail]>       Ph: [phone]

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

>From [e-mail] (Gary Kacmarcik)
Date: 16 Apr 1994 17:03:25 GMT
Organization: Case Western Reserve University, Cleveland, Ohio (USA)

In article <[e-mail]> [e-mail] (Bill Benson) writes:
>
> Does anyone know if there would be any (significant) performance gain from
> disabling the cache while reading? (as opposed to writing)

the simple answer is that you aren't likely to see any performance gain, and
(and if do this indiscriminantly) you'll make things much worse.

when you read a chunk from the disk, if it's not in the cache, the disk
_must_ be accessed.  there's no way around this, and disk accesses are
slow.

of course, if the data is in the cache, then the read is quite fast.  this
is the basic idea of caches - keep useful data in the cache to avoid
having to access the disk.

knowing what data is going to be useful is difficult, but a few rules of
thumb have proved useful:
  if it was accessed recently, it is likely to be accessed again soon
  if an area was accessed, the surrounding area is likely to be accessed
    in the near future

thus, whenever you access the disk, cache it somewhere because you're likely
to need it again. and grab a little bit more than you need, because you're
likely to need that, too.

turning off the caches effectively disables this optimization.  the only
time it may be useful is if you know _absolutely_ that you'll never need
it again.  even then, you probably won't notice the speed benefit (since
the disk access is the most significant part, and you can't avoid that).

if you load something into the cache that isn't used, it'll eventually
get swapped out for useful data. it's usually not worth worrying about.


WRT writes, turning off the cache can be useful because it _does_ "eliminate"
the disk access by deferring it until later.


hope this clears things up,


-gary j kacmarcik
[e-mail]

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

>From Cameron Esfahani <[e-mail]>
Date: Sun, 17 Apr 1994 09:20:34 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]> Gary Kacmarcik,
[e-mail] writes:
> knowing what data is going to be useful is difficult, but a few rules of
> thumb have proved useful:
>   if it was accessed recently, it is likely to be accessed again soon
>   if an area was accessed, the surrounding area is likely to be accessed
>     in the near future
>
> thus, whenever you access the disk, cache it somewhere because you're likely
> to need it again. and grab a little bit more than you need, because you're
> likely to need that, too.
>
> if you load something into the cache that isn't used, it'll eventually
> get swapped out for useful data. it's usually not worth worrying about.
>

One problem with this is that you have to get the space in the
cache from someplace!  Then you have to decide what information to
throw out, just so you can read in this extra information which
might never be used...

>
> WRT writes, turning off the cache can be useful because it _does_ "eliminate"
> the disk access by deferring it until later.
>

I think you have this backwards; by turning off the cache how does
that eliminate the disk access?  If anything, having a cache will
eliminate the write out to disk by sticking it in the cache and
deferring the write until later...

Cameron Esfahani
[e-mail]
I make things go faster...

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

>From [e-mail] (Gary Kacmarcik)
Date: 18 Apr 1994 22:21:20 GMT
Organization: Case Western Reserve University, Cleveland, Ohio (USA)


In article <[e-mail]> Cameron Esfahani <[e-mail]> writes:
>
> In article <[e-mail]> Gary Kacmarcik,
> [e-mail] writes:
> >
> > WRT writes, turning off the cache can be useful because it _does_ "eliminate"
> > the disk access by deferring it until later
>
> I think you have this backwards; by turning off the cache how does
> that eliminate the disk access?  If anything, having a cache will
> eliminate the write out to disk by sticking it in the cache and
> deferring the write until later...

whoa!  what was i smoking when i wrote that...

Cameron is, of course, correct in his correction.

-gary

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

>From [e-mail] (Larry Rosenstein)
Date: Wed, 20 Apr 1994 23:07:56 GMT
Organization: Taligent, Inc.

In article <[e-mail]>,
[e-mail] (Peter N Lewis) wrote:

> Basically, disable the cahce unless you are writing 10 byte blocks, and
> *DONT* write ten byte blocks!  If you write lots of small blocks, the
> FSClose time goes exponential, at least in tests I did.  Writing a 1 Meg

This is good advice for other reasons as well.  If the file lives on a
server being accessed via ARA, then writing small-sized blocks will be
extremely slow.

--
Larry Rosenstein
Taligent, Inc.

[e-mail]

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

>From [e-mail] (Jump Long)
Date: 28 Apr 1994 12:51:06 -0400
Organization: America Online, Inc. (1-800-827-6364)

In article <[e-mail]>, [e-mail] (Larry
Rosenstein) writes:

>> Basically, disable the cahce unless you are writing 10 byte blocks, and
>> *DONT* write ten byte blocks!  If you write lots of small blocks, the
>> FSClose time goes exponential, at least in tests I did.  Writing a 1 Meg
>
> This is good advice for other reasons as well.  If the file lives on a
> server being accessed via ARA, then writing small-sized blocks will be
> extremely slow.

Here's a little more information about AppleShare...

I'm not sure about AppleShare Pro and AppleShare 4.0 (I suspect it hasn't
changed), but the AppleShare 3.0.x, Macintosh File Sharing and AppleShare 2.0
file servers always set the noCache bit for all file access on the server
system. They do that because if there are multiple users hitting multiple files
on the server, any blocks cached by one user tend to be flushed by I/O by from
another user.  On the AppleShare client system, the noCache bit is ignored (the
AppleShare foreign file system does not use the File Manager's cache *at*
*all*).  The only thing cached by the AppleShare foreign file system is entries
returned by AFPEnumerate which is used to get information in response to
indexed GetFInfo and GetCatInfo calls (and the cached directory entries are
only kept for a very short period of time).

Since the AppleTalk Filing Protocol (AFP) is built on top of the AppleTalk
Transaction Protocol (ATP), the amount of data transferred from server to
client or client to server is limited to around 4K per AFP request (the maximum
size of an ATP reply). Larger requests to AFP are broken up by the protocol
code. For example, If you do a PBRead asking for 8K of data from a file on an
AppleShare server, AFP will ask the server for 8K and will get back around 4K.
So, it will ask for the remaining 4K to finish up the request.  So, with the
AppleShare 3.0.x, Macintosh File Sharing and AppleShare 2.0 file servers, the
server reads everything in 4K chunks and writes everything in 4K chunks, no
matter how large the requests were on the client side.

AppleShare Pro and AppleShare 4.0 improve performance dramatically by caching
data on the server.  For example, if an 8K read request is received from a
client, the server reads 8K into its cache and returns 4K (because of the ATP
limitation).  When the AFP client asks for the remaining 4K, the server gets it
from its cache which saves a hit to the disk.

So, with file access to an AppleShare volume:

o  The noCache bit in your Reads and Writes makes no difference whatsoever.

o  Using large Read and Writes from the client will improve performance -
especially with AppleShare Pro and AppleShare 4.0.

-- Jim Luther


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

>From [e-mail] (Dair Grant)
Subject: Extension Shell 1.3 - Help for INIT writers
Date: Wed, 27 Apr 1994 16:45:51 GMT
Organization: Computing Science Dept., Glasgow University, Glasgow, Scotland

Extension Shell is a library of source code for writing System 7
Extensions. Full source code is provided, as well as six sample
Extensions demonstrating how to write Extensions with Extension
Shell.


Extension Shell acts as an Extension-independent loading mechanism.
It takes care of the generic stuff needed by all Extensions (showing
icons, installing things into the System Heap, posting Notification
Manager messages), and reduces the amount of coding needed to produce
new Extensions.


To write an Extension with Extension Shell, you just decide what you
want installed, compile it into a code resource, and paste in
Extension Shell. Trap patches, VBL tasks, Shutdown tasks, Time
Manager tasks, Gestalt selectors, low-memory filters (e.g., jGNEFilter),
and blocks of code can all be installed through a simple
"fill out the details in a table" mechanism. It requires THINK C 6.0.



-dair

- -------------------+--------------------------------------------------------
Dair Grant           | There are two major products that come out of Berkeley:
[e-mail] | LSD and Unix. We don't believe this to be a
Finger for PGP Key   | coincidence.                          - Jeremy Anderson
- -------------------+--------------------------------------------------------

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

>From [e-mail] (Dair Grant)
Date: Wed, 27 Apr 1994 17:30:24 GMT
Organization: Computing Science Dept., Glasgow University, Glasgow, Scotland

[e-mail] (Dair Grant) writes:

>Extension Shell is a library of source code for writing System 7
>Extensions. Full source code is provided, as well as six sample
>Extensions demonstrating how to write Extensions with Extension
>Shell.

    [munch]


Ooops. I forgot to mention that I've sent it off to macgifts. It
should be showing up there within a couple of days. Too many
late nights trying to get my final year project finished... :-(



-dair

- -------------------+--------------------------------------------------------
Dair Grant           | There are two major products that come out of Berkeley:
[e-mail] | LSD and Unix. We don't believe this to be a
Finger for PGP Key   | coincidence.                          - Jeremy Anderson
- -------------------+--------------------------------------------------------

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

>From [e-mail]
Subject: FFT benchmark using CodeWarrior
Date: 26 Apr 94 08:58:24 PST
Organization: National Systems & Research, Vancouver WA

I ran the FFT benchmark which was posted to comp.sys.powerpc by
[e-mail]. I ran this on several computers
including a PowerMac 6100/60. I compiled the program using
CodeWarrior DR2 which uses the Apple math library. I also am
including the SpecInt and SpecFP results which [e-mail]
posted earlier:

these FFT results are from [e-mail]:

                                  FFT Time     SpecInt   SpecFP

    RS6000 Model 320                 55.0       20.9      39.4
    RS6000 Model 530                 41.0       28.5      64.6
    RS6000 Model 250                 40.0       62.6      72.2
    RS6000 Model 590                 18.0      117.0     242.4

These are the results from the tests I ran. Notice I ran with
and without the compilers optimizer turned on:

    RS6000 Model 550 (Opt)           25.0       35.4      71.7
    RS6000 Model 550 (No-Opt)        61.0       35.4      71.7
    Decstation 5000/260 (Opt)        46.0       57.1      54.5
    Decstation 5000/260 (No-Opt)     56.0       57.1      54.5
    Decstation 5000/240 (Opt)        99.0       27.9      35.8
    Dec3000 Alpha 300L (OVMS-Opt)    54.0       45.9      63.6
    Dec3000 Alpha 300L (OVMS-NoOpt) 125.0       45.9      63.6
    Dec3100/90 (VMS No-Opt)         133.0       ????      ????
    Dec3100/90 (VMS Opt)            108.0       ????      ????

    PowerMac 6100/60 (No-Opt)        66.0      ~55.0     ~73.0
    PowerMac 6100/60 (Opt)           65.0      ~55.0     ~73.0
    PowerMac 6100/60 (Opt/double_t)  77.0      ~55.0     ~73.0

I think this is very interesting because it tells me that the
CodeWarrior optimizer has a LONG way to go. Notice what the
RS6000 Model 550 did using xlc with and without the optimizer.
The optimizer gave a 244% speedup. The PowerMac with no optimization
did almost as well as the RS6000 Model 550 without optimization.
I think we have a lot to look forward to as CodeWarrior progesses!!

Another note, the FFT program uses floats, I tried to change these
floats to double_t and the time came out to 77.0 with the optimizer
turned on. I also tried changing the struct alignment just for
the heck of it and all three settings [PowerPC, 68k, 68k 4-byte]
all came out with the same times.

One more note, when I say optimizations above I meant I turned on
the highest level of optimization each compiler has.


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

>From [e-mail] (Brian Lowry)
Date: 26 Apr 1994 22:39:43 GMT
Organization: Chem Eng - Univ of Alberta

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

> I think this is very interesting because it tells me that the
> CodeWarrior optimizer has a LONG way to go.

  I was under the impression that the DR2 CodeWarrior C compiler did not
actually have optimization implemented, regardless of the project settings.
 You might want to contact MetroWerks and ask them.  I haven't seen any
evidence of optimization in low-level stuff...

--

Brian Lowry

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

>From [e-mail] (Ian R. Ameline)
Date: 27 Apr 1994 00:09:05 GMT
Organization: C-Set++ Development, IBM Canada Laboratory.

In <[e-mail]>, [e-mail] writes:

[Performance Numbers deleted]

>I think this is very interesting because it tells me that the
>CodeWarrior optimizer has a LONG way to go. Notice what the
>RS6000 Model 550 did using xlc with and without the optimizer.

   Well, IBM has been writing optimizing compilers for over 20 years.
I believe the current XLC optimizer has been in development for around
10 years, with some really bright people involved with it. There
should be little surprise that we're good at this sort of thing.

>The optimizer gave a 244% speedup. The PowerMac with no optimization
>did almost as well as the RS6000 Model 550 without optimization.
>I think we have a lot to look forward to as CodeWarrior progesses!!

   I've heard an unconfirmed rumour on the net that they've licenced
some IBM optimization technology. I don't know if it's true or not,
but if it is, perhaps your last sentence is correct.

Regards,                  | "Once you have flown, you will walk the earth with
Ian R. Ameline, PP-ASEL   |  your eyes turned skyward, for there you have been,
(speaking for myself only)|  and there you long to return" -- Leonardo DaVinci
ViaCrypt PGP Key fingerprint = 3B B8 CF E9 CA 1B 9C 75  01 7F B2 64 10 7F 96 85


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

>From Tigger <[e-mail]>
Date: Tue, 26 Apr 1994 03:45:25 GMT
Organization: Pomona College

In article <2pkaf1$[e-mail]> Ian R. Ameline,
[e-mail] writes:
>
>    I've heard an unconfirmed rumour on the net that they've licenced
> some IBM optimization technology.

I read it in at least two different trade rags, and it was reported
as news, not rumors.  I believe one of the articles included quotes
from a higher-up at Metrowerks.  Sounds like more than a rumor to me.

--
|  Greg Orman                         [e-mail]  |
|     A man's best friends:  a Harley, a Beretta and a Gund.     |

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

>From [e-mail] (John McEnerney)
Date: Wed, 27 Apr 1994 15:54:38 GMT
Organization: The World Public Access UNIX, Brookline, MA

>Another note, the FFT program uses floats, I tried to change these
>floats to double_t and the time came out to 77.0 with the optimizer
>turned on.

On the PowerPC, 'float' is usually faster than 'double', particularly
with multiply/divide instructions.

>The PowerMac with no optimization
>did almost as well as the RS6000 Model 550 without optimization.

This is definitely attributable to the 550 being faster. When
optimizations are turned off, CodeWarrior handily outperforms xlc (xlc
makes little use of registers when optimization is turned off)

>I think we have a lot to look forward to as CodeWarrior progesses!!

The current version so CodeWarrior actually do almost no optimization
beyond global register allocation. This can make some programs faster,
but because of the plentiful registers on the PowerPC it does not make an
improvement in many cases. Future versions wil include all of
the usual optimizations.

-- John


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

>From [e-mail] (Gary Kacmarcik)
Date: 27 Apr 1994 19:48:49 GMT
Organization: Case Western Reserve University, Cleveland, Ohio (USA)

In article <[e-mail]> Tigger <[e-mail]> writes:
>
> In article <2pkaf1$[e-mail]> Ian R. Ameline,
> [e-mail] writes:
> >
> >    I've heard an unconfirmed rumour on the net that they've licenced
> > some IBM optimization technology.
>
> I read it in at least two different trade rags, and it was reported
> as news, not rumors.  I believe one of the articles included quotes
> from a higher-up at Metrowerks.  Sounds like more than a rumor to me.

John McEnerey (from Metrowerks) attempted to clarify the articles that
were published.  these articles implied that Metrowerks has licensed
some of IBM's code.  this is not the case.

included is an excerpt from John's original post.

-gary


[QUOTED MESSAGE FOLLOWS]

Newsgroups: comp.sys.mac.programmer
Path: usenet.ins.cwru.edu!eff!news.kei.com!world!johnmce
From: [e-mail] (John McEnerney)
Subject: Re: Metrowerks News from MacWEEK
Message-ID: <[e-mail]>
Organization: The World Public Access UNIX, Brookline, MA
References: <[e-mail]> <[e-mail]>
Date: Sat, 9 Apr 1994 09:03:06 GMT
Lines: 44

> Metrowerks has formed an agreement with IBM which gives Metrowerks
> access to Big Blue's compiler optimization technology for current and
> future PowerPC processors. As a result, Mac developers will have access
> to the best PowerPC code generators available, said Jean Belanger,
> Metrowerks' chairman. "In addition to having the fastest compiler, we'
> ll be able to generate the fastest code," he said.

So that the rumours don't fly to far too fast on this one, let me clarify
the situation as it will affect you, the users.

We have an agreement which says that as I develop the next version
of our PowerPC code generator, I'm free to ask for advice, experiences,
etc. from some of the guys at IBM's Watson Research Center where the
POWER architecture was originally designed. It turns out much of my
current code generator design is already based on some papers that they
wrote at Watson anyway. They are willing to be pretty free with their
experience, but I imagine they will also keep some tricks to themselves.

No source code is involved, at least not to my knowledge.

[... rest deleted ...]



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

>From [e-mail] (Zalman Stern)
Date: Wed, 27 Apr 1994 21:59:22 GMT
Organization: Adobe Systems Incorporated

John McEnerney writes
> This is definitely attributable to the 550 being faster. When
> optimizations are turned off, CodeWarrior handily outperforms xlc (xlc
> makes little use of registers when optimization is turned off)

I've observed that if you have debugging information turned on and
optimization turned off, xlc goes out of its way to generate *exactly* the
seqeunce of operations you wrote in your program. This means that variables
are "homed" to their memory locations at the end of each line of code if
they are modified. Variables also seem to be preserved as live to the end of
their declared scope. The result of these things is a rather inefficient but
easy to debug program. I never compile with both optimization and debug
symbols off so I don't know if this is a property of turning optimization
off, or a property of turning debugging on with optimization off.
--
Zalman Stern           [e-mail]            [phone]
Adobe Systems, 1585 Charleston Rd., POB 7900, Mountain View, CA 94039-7900
          There is no lust like the present.

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

>From [e-mail] ()
Date: Thu, 28 Apr 1994 02:40:14 GMT
Organization: McGill University

[e-mail] wrote:
: I ran the FFT benchmark which was posted to comp.sys.powerpc by
: [e-mail]. I ran this on several computers
: including a PowerMac 6100/60.

: I think this is very interesting because it tells me that the
: CodeWarrior optimizer has a LONG way to go.

I have also draw this conclusion, but this well known.
One has be careful on what conclusions one draws from this simple
benchmark. My intention was to use it as sanity check against
the numbers I have in magazines and on the net. The benchmark
was intended to simulate the number crunching efforts of researchers
in our respiratory research lab. We have data sets that usually
larger than most caches so I included that in my benchmark. Those
that takes benchmarks seriously would say that this makes the benchmark
meaningless and that it does little more than detect the presence
or absence of a 512 K cache. ( Perhaps it is the case that all our
research efforts amount to little more than detecting 512K caches :-) )
Of course, running code in a memory bound fashion tends to diminish the
advantage of the super-scalar designs particularly more sophisticated
designs such as the POWER2 machines ( as seen the benchmarks ).

Furthermore the fft implementation is a very simple one. It has
not been reworked for data that exceeds the cache size. Again
this was deliberate on my part. More often than not we use simple
coding techniques.

: One more note, when I say optimizations above I meant I turned on
: the highest level of optimization each compiler has.

I used cc -O only because we may move binaries from
machine to machine - perhaps from the RS6000 to the PowerMac.

Whitney

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

>From [e-mail]
Date: 27 Apr 94 23:06:02 MST
Organization: (none)

In article <[e-mail]>, Tigger <[e-mail]> writes:
> In article <2pkaf1$[e-mail]> Ian R. Ameline,
> [e-mail] writes:
>>
>>    I've heard an unconfirmed rumour on the net that they've licenced
>> some IBM optimization technology.
>
> I read it in at least two different trade rags, and it was reported
> as news, not rumors.  I believe one of the articles included quotes
> from a higher-up at Metrowerks.  Sounds like more than a rumor to me.
>
> --
> |  Greg Orman                         [e-mail]  |
> |     A man's best friends:  a Harley, a Beretta and a Gund.     |



On AOL, the architect of the CodeWarrior C/C++ came out and clarified issues.
He won't be able to do much until next year at the earliest...

Lawson

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

>From [e-mail] (John McEnerney)
Date: Thu, 28 Apr 1994 06:24:57 GMT
Organization: The World Public Access UNIX, Brookline, MA

[e-mail] (Brian Lowry) writes:

>  I was under the impression that the DR2 CodeWarrior C compiler did not
>actually have optimization implemented, regardless of the project settings.
> You might want to contact MetroWerks and ask them.  I haven't seen any
>evidence of optimization in low-level stuff...

The DR2 and DR3 versions of CodeWarrior (for PowerPC) have no real
optimizations. I use the Global Optimization option as a catch-all for
anything that is likely to slow down the compiler. For now, it only
controls global register allocation. This does quite a nice job of
cleaning up your register usage (for example, variables with disjoint
lifetimes will get the same register, and it does a pretty good job with
function calls) but usually does not provide a significant performance
increase because there are so many registers on the PowerPC.

Although this is not a huge optimization, the algorithm is O(N^2) so it
tends to slow the compiler down quite a bit, which is why the smart
register allocator isn't used all the time.

DR4 will probably add some common subexpression elimination.

Future versions will add the traditional global optimizations, which will
slow down the compiler quite a bit more when they are enabled.

-- John McEnerney, Metrowerks PowerPC Product Architect


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

>From [e-mail] (Roger Clark)
Subject: How do I find the window colour ???
Date: Thu, 28 Apr 1994 11:05:40 GMT
Organization: Crosfield, Hemel Hempstead, UK

Hi,
   I'm trying to find out what "Window colour" has been set by the "Colour"
control panel.  I have tried using GetAuxWin(nil,&theAuxWinHandle); in
an attempt to get the "default" window information, but this gives colours
of black or white (0xffff,0xffff,0xffff or 0x0,0x0,0x0) for the various
components (like content,frame,text,highlight and title bar).

Does anyone know what I'm doing wrong, or have a better solution.


Thanks in advance.
            Roger Clark.

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

>From Carl R. Osterwald <[e-mail]>
Date: Thu, 28 Apr 94 17:10:45 GMT
Organization: National Renewable Energy Laboratory

In article <[e-mail]> Roger Clark,
[e-mail] writes:
>   I'm trying to find out what "Window colour" has been set by the
"Colour"
>control panel.  I have tried using GetAuxWin(nil,&theAuxWinHandle); in
>an attempt to get the "default" window information, but this gives
colours
>of black or white (0xffff,0xffff,0xffff or 0x0,0x0,0x0) for the various
>components (like content,frame,text,highlight and title bar).

Two items on ftp.apple.com should give you the information you require:

  *  Tech Note TB 33 - "Color, Windows and 7.0"
  *  DTS code snippet "WDEFColorSample"

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

>From [e-mail] (Devon Hubbard)
Date: Thu, 28 Apr 1994 17:32:40 GMT
Organization: Taligent, Inc.

In article <[e-mail]>, [e-mail]
(Roger Clark) wrote:

> Hi,
>    I'm trying to find out what "Window colour" has been set by the "Colour"
> control panel.  I have tried using GetAuxWin(nil,&theAuxWinHandle); in
> an attempt to get the "default" window information, but this gives colours
> of black or white (0xffff,0xffff,0xffff or 0x0,0x0,0x0) for the various
> components (like content,frame,text,highlight and title bar).
>
> Does anyone know what I'm doing wrong, or have a better solution.
>
>
> Thanks in advance.
>             Roger Clark.

Have you seen Infinity Windoid yet?  He supports the floating window being
the color that the system has assigned and, giving full credit here to Troy
Gaul, here's how he does it.

- ---
static void
GetWctbColor(WindowPeek window, short partCode, RGBColor *theColor) {
    //    Given a partCode, return the RGBColor associated with it. (Using the
    //    default window color table.)
    AuxWinHandle awHndl;
    short count;

    //    Get the Color table for the window if it has one.

    (void) GetAuxWin((WindowPtr) window, &awHndl);
    count = (**(WCTabHandle) ((**awHndl).awCTable)).ctSize;


    //    If the table didn't contain the entry of interest, look to the
    //    default table.

    if (count < partCode) {
        GetAuxWin(nil, &awHndl);
        count = (**(WCTabHandle) ((**awHndl).awCTable)).ctSize;
    }


    //    If the entry is there, use it, if not make a best guess at a default
value.

    if (count < partCode)
        UseDefaultColor(partCode, theColor);
    else
        *theColor = (**(WCTabHandle)
((**awHndl).awCTable)).ctTable[partCode].rgb;
}
- ----

You might want to get his cool Infinity Windoid archive from your nearest
site so you can see everything he's doing.

- ------------------------------------------------------------------------
Devon Hubbard                                                Silicon Pilot
[e-mail]                                   Taligent, Inc

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

>From [e-mail] (Tony Mann)
Subject: Private inheritance faulty in SC++ 7.0
Date: Wed, 27 Apr 1994 21:58:51 GMT
Organization: NETCOM On-line Communication Services (408 241-9760 guest)

Using SC++ 7.0, the following code should not compile, but it does:

class Bag
{
public:
  Bag();
  int GetCount() { return count; }
private:
  int count;
};

class Set: private Bag  // note "private" keyword
{
public:
  Set();
};

int foo(Bag& b)
{
  return b.GetCount();
}

main()
{
  Bag *b = new Set;     // ** should generate error; it does not
  Set s;
  foo(s);               // ** should generate error; it does not
  return 0;
}

The compiler is allowing a Set to be implicitly converted to a Bag;
this should not be allowed, since Set privately inherits from Bag.

Symantec has been notified.

- Tony Mann

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

>From David Plumpton <[e-mail]>
Subject: Source Control Questions
Date: Tue, 19 Apr 1994 03:12:09 GMT
Organization: NorTel

Are there any real alternatives to using MPW projector?
If you had to manage a multiplatform project using Macintosh,
Unix and Windows, which source control system on which
platform would you choose?

Thanks in advance.
- -----------
David Plumpton: [e-mail]
"I'm a New Zealand Zoo Official, and this monkey's going to Newton!"

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

>From [e-mail] (Bob Carpenter)
Date: 20 Apr 1994 19:42:23 GMT
Organization: A World of Information at Your Fingertips

In article <[e-mail]>,
David Plumpton  <[e-mail]> wrote:
>Are there any real alternatives to using MPW projector?
>If you had to manage a multiplatform project using Macintosh,
>Unix and Windows, which source control system on which
>platform would you choose?
>

 I'd use SCCS under Unix. It's fairly powerful, and with scripts
 you can tailor it to your liking.

 See the sccs man pages for the details.

--BobC

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

>From [e-mail] (Sak Wathanasin)
Date: Thu, 21 Apr 94 09:52:55 GMT
Organization: Network Analysis Ltd


In article <2p40iv$[e-mail]> (comp.sys.mac.programmer), [e-mail] (Bob Carpenter) writes:
> In article <[e-mail]>,
> David Plumpton  <[e-mail]> wrote:
> >Are there any real alternatives to using MPW projector?
> >If you had to manage a multiplatform project using Macintosh,
> >Unix and Windows, which source control system on which
> >platform would you choose?
> >
>
>  I'd use SCCS under Unix. It's fairly powerful, and with scripts
>  you can tailor it to your liking.

You cannot be serious: the contortions you have to go through just to
mark a set of versions as belonging to a particular release! (Yes, I
know about the

    what prog > prog.slist

trick :-()

Anyway, I've just come off a Windows/Mac project straight into another one, so
the issue is very much on my mind. The main problems with using a non-Mac source
control system are

a) filename lengths

For the first project, we used PVCS on a PC-compatible. Using LAN Mgr for
the Mac, we mounted the PC vols on the Mac desktop, and saved our src files
there. We then hopped on to a PC to check stuff in and out. Even though LAN
Mgr lets you use full Mac filenames, when we came to use PVCS we discovered
very quickly that we had to use 8.3 filenames. That meant chasing through
all our makefiles, .r files &c - bugs from which are still haunting me (some
of the files, like .r files only get rebuilt very occasionally).

b) they destroy the Mac rez fork

I knew that we couldn't save rsrc files in PVCS, so I had a couple of small
MPW scripts that derez'ed rsrc files before saving them on the PC volume.
Well, that worked, but we then found that when we checked stuff back out of
PVCS that we had lost all our tab settings, font settings, and most important,
our MPW markers in every source file. (Sound of grinding teeth...)

My current project uses SCCS, and we are going to have similar problems.
Anyway, the last time this subject came up, Tom Emerson of Symantec pointed
me at

      SourceSafe by
          OneTree Software
          P.O. Box 11639
          Raleigh, NC 27604
          USA

          (919)-821-2300
          fax [phone]

I didn't get a chance to follow this up, though I will do this time (promise,
really, honest :-).

Another possiblility you might like to look at is RCS - there is a Mac port
by Tim Endres, available from nic.switch.ch or ftp.msen.com (in /pub/vendors/ice).
Please report any experiences with this, especially if you've used it on a
real project.

Actually, I quite like Projector, especially when backed up with suitable MPW
scripts (look for DTS Goodies on a developer CD). I don't see why it can't
be used for storing Unix and Windows src files, since Projector, unlike SCCS
can hold binary files.


Sak Wathanasin
Network Analysis Limited
178 Wainbody Ave South, Coventry CV3 6BX, UK

Internet: [e-mail]
uucp:     ...!uknet!nan!sw                       AppleLink: NAN.LTD
Phone: [phone] Mobile:[phone]  Fax: [phone]

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

>From xxx (Christoph Reichenberger)
Date: Mon, 25 Apr 1994 07:10:27 GMT
Organization: Uni Software Plus

In article <2p40iv$[e-mail]>, [e-mail] (Bob
Carpenter) wrote:

> In article <[e-mail]>,
> David Plumpton  <[e-mail]> wrote:
> >Are there any real alternatives to using MPW projector?
> >If you had to manage a multiplatform project using Macintosh,
> >Unix and Windows, which source control system on which
> >platform would you choose?
> >

Voodoo (the name stands for Versions Of Outdated Documents Organized
Orthogonally) is a (Mac) version management tool for the simple and clear
management of projects in which files are created in numerous versions
(variants and revisions). Since Voodoo is capable of managing
arbitrary files, the program can be employed for more than just the
organization of software projects in a narrow sense (program
development). Even the writing of a book, for example, is a project in
which multiple elementary building blocks (the individual chapters,
illustrations, etc.) evolve in various revisions. Using Voodoo can
also pay off here.

Voodoo allows both variant and revision control, and it
manages not only variants and revisions of single files, but
of a whole software project (multi files, multi users,
multi variants, access rights, ...).

The tool offers a neat graphical user interface and is not only
suitable for mere source code control but can handle all
different kinds of files with amazing compression rates:

          typical size of delta between arbitrary files
               5% (in words:  five per cent)  !!!!

no matter whether the files are plain text or any other
documents - e. g. MSWord, WriteNow, Canvas, FileMaker ...).
Contrary, if you try to manage non-text-files with Projector
or SCCS you will not get any space reduction.

Voodoo differs from previous source code control systems in its
orthogonal approach to version management. This means that for
every component of a project hierarchy you can not only store
its revision history but also different variants of the same
component.The orthogonal organization of revisions and
variants leads to a much clearer organization that with other
RCS/SCCS-based tools like Projector/SourceServer and others.

A lite version of Voodoo is being distributed on a shareware basis (30 $).
The package included contains VoodooLite 1.5 together with a
readme document and a manual.

You can get the current version directly from our ftp-server at:
  ftp.swe.uni-linz.ac.at    in /pub/voodoo

Additionally it should be available via ftp at least at the
following sites:
  sumex-aim.stanford.edu    in /info-mac/dev
  mac.archive.umich.edu     in /mac/util/organization

The full (commercial) version of Voodoo is being distributed
world-wide by:

   UNI Software Plus
   Softwarepark Hagenberg
   A-4232 Hagenberg
   AUSTRIA (Europe)
   Fax.: [phone]
   EMail: [e-mail]

For further information on Voodoo Lite or on the full version
please contact the author:

    Christoph Reichenberger      Tel:      [phone]
                 Erlenweg 2      Fax:      [phone]
       A-4320 Perg, Austria      Internet: [e-mail]


Feel free to contact me, if you have further questions concerning Voodoo.

Christoph, the author of Voodoo


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

>From [e-mail] (Hoshi Takanori)
Date: 27 Apr 94 11:34:50
Organization: Software Research Associates, Inc.,Japan

In article <[e-mail]> David Plumpton <[e-mail]> writes:

> Are there any real alternatives to using MPW projector?
> If you had to manage a multiplatform project using Macintosh,
> Unix and Windows, which source control system on which
> platform would you choose?

I've just started using RCS on my MacMiNT.  It's great!

hoshi

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

>From Ken Prehoda <[e-mail]>
Subject: Using xlc to generate PowerMacintosh code
Date: 15 Apr 1994 00:36:24 GMT
Organization: Univ of Wisc-Madison

I have access to an RS/6000 with the xlc compiler.  My
question is how do I use this compiler to generate
code for the mac.  Could someone with experience in
this area please give me some pointers?

Thanks,
Ken Prehoda
[e-mail]

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

>From [e-mail] (Charlie Reiman)
Date: Fri, 15 Apr 1994 07:15:24 GMT
Organization: NETCOM On-line Communication Services (408 241-9760 guest)

Ken Prehoda <[e-mail]> writes:

>I have access to an RS/6000 with the xlc compiler.  My
>question is how do I use this compiler to generate
>code for the mac.  Could someone with experience in
>this area please give me some pointers?

You can't, really. The xlc that apple is giving to developers is
modified to support the pascal keyword (ignored), #pragma align=68k
(very important), and pascal strings (also important). Also, their xlc
generates instructions for the PowerPC which probably isn't an option
on older versions of xlc.

If you don't need any of these, then you can generate .o files, then
drop those into an MPW development environment and use the usual
makepef, ppclink, et al. If you can get the inside track SDK, it's
actually pretty cool (if you are an unix hacker, anyway).  I've
always wanted to cross compile my mac apps under unix. Now, I can.

--
"You can't cancel the project! We already made the T-shirts!"
Charlie Reiman
[e-mail]

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

>From [e-mail] (Mike Gleason)
Date: 15 Apr 1994 11:13:39 GMT
Organization: NCEMRSoft

[e-mail] (Charlie Reiman) writes:

|Ken Prehoda <[e-mail]> writes:
|>I have access to an RS/6000 with the xlc compiler. My question is how
|>do I use this compiler to generate code for the mac. Could someone with
|>experience in this area please give me some pointers?

|You can't, really. The xlc that apple is giving to developers is
|modified to support the pascal keyword (ignored), #pragma align=68k
|(very important), and pascal strings (also important). Also, their xlc
|generates instructions for the PowerPC which probably isn't an option
|on older versions of xlc.

Too bad... one could write a preprocessor that could handle the 'pascal'
and pascal strings, then use that before the cpp for xlc.  Can't get
around the #pragma align=68k or PowerPC generation, though.

|If you don't need any of these, then you can generate .o files, then
|drop those into an MPW development environment and use the usual
|makepef, ppclink, et al. If you can get the inside track SDK, it's
|actually pretty cool (if you are an unix hacker, anyway).  I've
|always wanted to cross compile my mac apps under unix. Now, I can.

Me too.  One thing I did just figure out how to do, which has nothing
to do with PowerPC, is send my mac code over to a unix box and run
lint on it, or actually "compile" my mac code with gcc for sole purpose
of seeing all the cool warnings it spews.  Seems kind of silly, but
the only mac compiler I can use right now is Think C 5, which doesn't
give me warning messages.

--
--mg                                                      [e-mail]

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

>From Ken Prehoda <[e-mail]>
Date: 15 Apr 1994 14:58:51 GMT
Organization: Univ of Wisc-Madison

<[e-mail]> Charlie Reiman, [e-mail] writes:
>You can't, really. The xlc that apple is giving to developers is
>modified to support the pascal keyword (ignored), #pragma align=68k
>(very important), and pascal strings (also important). Also, their xlc
>generates instructions for the PowerPC which probably isn't an option
>on older versions of xlc.

Thanks for the info.  The version of xlc that I have will
align=68k and will also generate instructions for the 601.
Also, I can get rid of the pascal keyword easy enough.
In other words, I think I can get it to do all of the things
that you say.  However, is it possible to compile a complete
mac application on the RS/6000 (i.e. I don't have MPW)?


>If you don't need any of these, then you can generate .o files, then
>drop those into an MPW development environment and use the usual
>makepef, ppclink, et al. If you can get the inside track SDK, it's
>actually pretty cool (if you are an unix hacker, anyway).  I've
>always wanted to cross compile my mac apps under unix. Now, I can.

Me too.  And that's the main reason I'm even bothering with all this.
Not to mention how much I like xlc.

Thanks again,
Ken Prehoda
[e-mail]

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

>From [e-mail] (Phil Roth)
Date: Fri, 15 Apr 1994 16:10:22 GMT
Organization: Picasso Group, DCS, University of Illinois, Urbana-Champaign

In article <2olst3$[e-mail]>, [e-mail] (Mike Gleason) writes:
|> [e-mail] (Charlie Reiman) writes:
|>
|> |Ken Prehoda <[e-mail]> writes:
|> |>I have access to an RS/6000 with the xlc compiler. My question is how
|> |>do I use this compiler to generate code for the mac. Could someone with
|> |>experience in this area please give me some pointers?
|>
|> |You can't, really. The xlc that apple is giving to developers is
|> |modified to support the pascal keyword (ignored), #pragma align=68k
|> |(very important), and pascal strings (also important). Also, their xlc
|> |generates instructions for the PowerPC which probably isn't an option
|> |on older versions of xlc.
|>
|> Too bad... one could write a preprocessor that could handle the 'pascal'
|> and pascal strings, then use that before the cpp for xlc.  Can't get
|> around the #pragma align=68k or PowerPC generation, though.


The last version of xlc I installed on our research RS/6000 supposedly
has PowerPC code generation support ( using -qarch=ppc ).
The man page claims that it will

    "Produce an object that contains instructions that will
    run on any of the 32-bit PowerPC hardware platforms."

Also, one can specify an alignment option for aligning structs and unions.
The choices are 'power' for the POWER architecture, 'twobyte' for two
byte alignment, and 'packed' for one byte alignment.
How would this relate to the 'align=68k' pragma discussed above?

Pascal strings would be an interesting addition, nevertheless.

Phil Roth
[e-mail]


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

>From [e-mail] (Zalman Stern)
Date: Fri, 15 Apr 1994 10:15:09 GMT
Organization: Adobe Systems Incorporated

Ken Prehoda <[e-mail]> writes
> I have access to an RS/6000 with the xlc compiler.  My
> question is how do I use this compiler to generate
> code for the mac.  Could someone with experience in
> this area please give me some pointers?

Both Metrowerks and Apple's Macintosh on RISC SDK will accept XCOFF object
files from the RS/6000. And if you have the very latest version of IBM's
compilers, you should be able to compile with the Universal headers. (I
believe Charlie Reiman's comment that the Mac specific features are not in
the shipping version of IBM's compiler is incorrect.) You'll likely need to
muck with the xlc configuration though. You can either do this by hand
feeding in a bunch of flags on the command line, or by making a custom
xlc.cfg file. (Which is only slightly more fun than smacking yourself in the
head with an axe repeatedly.) The important compiler options you'll need
are:

-qmacpstr -qpascal -qenum=small -qcpluscmt -qldbl128 -qchars=signed
-D__powerc=1 -Dpowerc=1 -DUSE68KINLINES=0 -U_AIX

You'll need a -I directive pointing to the Universal headers somewhere on
your AIX box. (Unless the code doesn't rely on Macintosh interfaces in which
case its a lot easier. For example if you just have some computation
intensive routines you want to compile.) You might also want to add a
-qNOSTDINC to tell xlc not to search the standard system include
directories.

You can link on the AIX box as well if you have the right libraries, which
can probably be snagged off Apple's SDK. You'll have to move the XCOFF
result over to a Mac and run makepef in MPW. Optionally, it may be easier to
haul the .o files over to your Mac (being sure to use a binary transfer
method that preserves every last bit in its pristine natural form) and use
Apple's PowerPC linker within MPW. (I've never used Apple's SDK, so I really
have no idea how that works.) Once you've gotten a fully linked XCOFF file,
you can feed it to makepef to produce your PEF container. (And you'll have
to do that in MPW 'cause I doubt Apple is distributing the RS/6000 version
of makepef anywhere.)

I'll let John McEnerney detail how you use AIX generated objects with
CodeWarrior. So far I've figured out that you need a file of type XCOF and
creator UNIX which is a shared reuseable XCOFF library. I believe this
implies that CodeWarrior will only link against shared libraries this way,
that you can't link the code directly into your app. (Then again I really
have no idea how it works.) If that's true, you'll need to make a shared
library out of the code you compile on AIX. (The specific process of making
a shared library is a a bit involved, but on AIX, you'll need to give ld at
least the -bM:SRE switch and an exports file. You feed the output of that to
makepef and shove a cfrg resource in the resource fork of the result.)

Suffice it to say, this is not a trivial task. Though realistically, it is
probably the best development environment for Power Macintosh right now.
Especially if you have a really huge app, or are working in C++.
--
Zalman Stern           [e-mail]            [phone]
Adobe Systems, 1585 Charleston Rd., POB 7900, Mountain View, CA 94039-7900
Remember Y'all, in Arizona immigration lawyers are in season year 'round!

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

>From [e-mail] (Zalman Stern)
Date: Sat, 16 Apr 1994 01:31:01 GMT
Organization: Adobe Systems Incorporated

Phil Roth writes
> In article <2olst3$[e-mail]>, [e-mail] (Mike
Gleason) writes:
> |> [e-mail] (Charlie Reiman) writes:
> |>
> |> |Ken Prehoda <[e-mail]> writes:
> |> |>I have access to an RS/6000 with the xlc compiler. My question is how
> |> |>do I use this compiler to generate code for the mac. Could someone
with
> |> |>experience in this area please give me some pointers?
> |>
> |> |You can't, really. The xlc that apple is giving to developers is
> |> |modified to support the pascal keyword (ignored), #pragma align=68k
> |> |(very important), and pascal strings (also important). Also, their xlc
> |> |generates instructions for the PowerPC which probably isn't an option
> |> |on older versions of xlc.
> |>
> |> Too bad... one could write a preprocessor that could handle the
'pascal'
> |> and pascal strings, then use that before the cpp for xlc.  Can't get
> |> around the #pragma align=68k or PowerPC generation, though.
>
>
> The last version of xlc I installed on our research RS/6000 supposedly
> has PowerPC code generation support ( using -qarch=ppc ).
> The man page claims that it will
>
>     "Produce an object that contains instructions that will
>     run on any of the 32-bit PowerPC hardware platforms."
>
> Also, one can specify an alignment option for aligning structs and unions.
> The choices are 'power' for the POWER architecture, 'twobyte' for two
> byte alignment, and 'packed' for one byte alignment.
> How would this relate to the 'align=68k' pragma discussed above?

"#pragma options align=mac68k" is a synonym for "#pragma options
align=twobyte". Try using the mac68k syntax with the shipping 1.03 version
of xlc and I bet it will work. By the way, I left out the "-qarch=ppc"
switch in my previous message in this thread. You should give that to xlc to
prevent it from generating POWER architecture only instructions.
--
Zalman Stern           [e-mail]            [phone]
Adobe Systems, 1585 Charleston Rd., POB 7900, Mountain View, CA 94039-7900
Remember Y'all, in Arizona immigration lawyers are in season year 'round!

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

>From [e-mail] (Jon Wdtte)
Date: 16 Apr 1994 09:39:13 GMT
Organization: The Royal Institute of Technology

In <[e-mail]> [e-mail] (Zalman Stern) writes:

>You can link on the AIX box as well if you have the right libraries, which
>can probably be snagged off Apple's SDK. You'll have to move the XCOFF
>result over to a Mac and run makepef in MPW. Optionally, it may be easier to

Actually, you CAN execute an XCOFF as well (I haven't tried but heard
it from an engineer who should know) It's just that they're 3 times the
size of a PEF...

--
 -- Jon W{tte, [e-mail], Mac Hacker Deluxe --
 "If people bought cars according to the same principles they buy computers,
  cars would behave like Lamborghinis but would be built and look like Yugos."
                     -- Craig Fields

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

>From [e-mail] (Charlie Reiman)
Date: Mon, 18 Apr 1994 02:53:13 GMT
Organization: NETCOM On-line Communication Services (408 241-9760 guest)

[e-mail] (Jon Wdtte) writes:

>In <[e-mail]> [e-mail] (Zalman Stern) writes:

>>You can link on the AIX box as well if you have the right libraries, which
>>can probably be snagged off Apple's SDK. You'll have to move the XCOFF
>>result over to a Mac and run makepef in MPW. Optionally, it may be easier to

>Actually, you CAN execute an XCOFF as well (I haven't tried but heard
>it from an engineer who should know) It's just that they're 3 times the
>size of a PEF...

3??? Try 40 times larger. I have a 2 meg pef that I makepef from an xcoff
that is 70-80megs.

Yes, linking takes forever.

--
"You can't cancel the project! We already made the T-shirts!"
Charlie Reiman
[e-mail]

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

>From [e-mail] (Zalman Stern)
Date: Mon, 18 Apr 1994 04:16:26 GMT
Organization: Adobe Systems Incorporated

Charlie Reiman writes
[XCOFF vs. PEF.]
> 3??? Try 40 times larger. I have a 2 meg pef that I makepef from an xcoff
> that is 70-80megs.
>
> Yes, linking takes forever.

You build with full debug symbols right? XCOFF is a pig, but not that much
of a pig. PEF doesn't contain any debug info of course. the .xSYM file for
your XCOFF is probably measured in tens of megabytes though.

Likewise, IBM linker is dramatically faster if you turn off debug info for
the compiler. (Unfortunately, there is no switch to the linker to ignore
debug info for all but a few object files.) On a pretty hefty RS/6000, I can
link in 15 minutes with full symbols and 1 minute with no symbols. I leave
in traceback tables (the moral equivalent of Macsbug names) and debug a lot
of stuff that way. And at the end of the day, if I'm lucky I manage to club
some small mammal on the way back to the cave so I can have dinner :-)
--
Zalman Stern           [e-mail]            [phone]
Adobe Systems, 1585 Charleston Rd., POB 7900, Mountain View, CA 94039-7900
Remember Y'all, in Arizona immigration lawyers are in season year 'round!

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

>From [e-mail] (Maynard James Handley)
Date: Wed, 20 Apr 1994 22:59:21 GMT
Organization: University of Otago

Apart from issues like 68K alignment and pascal strings, are there not
fundamental problems at the "OS" level?
For examples, doesn't AIX have conventions about using the first N registers
to pass variables between functions. I don't know if MacOS on PowerPC has
such conventions, but it expectects one of the registers always to point
to the code fragment TOC thingie---would it not be very bad if xlc used
said register for something else.

Are these valid issues or not? I don't yet have a copy of IM: RISC system
software, so please be gentle if I'm spouting nonsense.

Maynard Handley

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

>From [e-mail] (Quinn "The Eskimo!")
Date: Thu, 21 Apr 1994 11:22:55 +0800
Organization: Department of Computer Science, The University of Western Australia

In article <[e-mail]>, [e-mail]
(Maynard James Handley) wrote:

>Apart from issues like 68K alignment and pascal strings, are there not
>fundamental problems at the "OS" level?
>
>[lots of talk about calling conventions]

My understanding is that Apple block-copied IBM's runtime architecture for
their PowerMacs.  [This is not a criticism, just an observation.  The
run-time architecture is kinda cool -- apart from the *extreme* silliness
of allocating two GPRs for each FP parameter just to support
prototype-less C calling!]
--
Quinn "The Eskimo!"      <[e-mail]>     "Support HAVOC!"
Department of Computer Science, The University of Western Australia

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

>From [e-mail] (Zalman Stern)
Date: Thu, 21 Apr 1994 05:53:08 GMT
Organization: Adobe Systems Incorporated

Maynard James Handley writes
> Apart from issues like 68K alignment and pascal strings, are there not
> fundamental problems at the "OS" level?
> For examples, doesn't AIX have conventions about using the first N
registers
> to pass variables between functions. I don't know if MacOS on PowerPC has
> such conventions, but it expectects one of the registers always to point
> to the code fragment TOC thingie---would it not be very bad if xlc used
> said register for something else.

The runtime architecture you are refering to was developed by IBM and
adopted basically without change by Apple. Binaries running on the RS/6000
have used r2 as a TOC pointer for more than four years now. (And that
particular convention pretty much came from the IBM RT which shipped in
'86.) The PowerPC code in the Power Macintosh ROMs is compiled with xlc.
--
Zalman Stern           [e-mail]            [phone]
Adobe Systems, 1585 Charleston Rd., POB 7900, Mountain View, CA 94039-7900
Remember Y'all, in Arizona immigration lawyers are in season year 'round!

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

>From [e-mail] (Ron Beloin)
Date: Thu, 21 Apr 1994 11:57:00 -0500
Organization: Boyce Thompson Inst. for Plant Research

In article <[e-mail]>, [e-mail] (Zalman
Stern) wrote:
> [XCOFF vs. PEF.]
> [other stuff about XCOFF]

Sorry for the basic question, but how does one link XCOFF format
files from an RS6K in MPW? E.G., what version of Link do i need, what
options or swithches are required. I already have the RS6K and E.T.O.
Thanks.
--
Ron Beloin ([e-mail])
[who works, but doesn't speak, for the]
Boyce Thompson Inst.
Ithaca, NY

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

>From [e-mail] (Zalman Stern)
Date: Thu, 21 Apr 1994 23:31:46 GMT
Organization: Adobe Systems Incorporated

Ron Beloin writes
> In article <[e-mail]>, [e-mail] (Zalman
> Stern) wrote:
> > [XCOFF vs. PEF.]
> > [other stuff about XCOFF]
>
> Sorry for the basic question, but how does one link XCOFF format
> files from an RS6K in MPW? E.G., what version of Link do i need, what
> options or swithches are required. I already have the RS6K and E.T.O.
> Thanks.

You need ppclink off the Macintosh on RISC SDK.
--
Zalman Stern           [e-mail]            [phone]
Adobe Systems, 1585 Charleston Rd., POB 7900, Mountain View, CA 94039-7900
Remember Y'all, in Arizona immigration lawyers are in season year 'round!

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

>From [e-mail] (Jon Wdtte)
Date: 23 Apr 1994 10:40:51 GMT
Organization: The Royal Institute of Technology

In <[e-mail]> [e-mail] (Ron Beloin) writes:

>Sorry for the basic question, but how does one link XCOFF format
>files from an RS6K in MPW? E.G., what version of Link do i need, what
>options or swithches are required. I already have the RS6K and E.T.O.

You need the Mac on RISC SDK CD which comes with PPCLink and
MakePEF. It also comes with the right headers and libraries.

Cheers,
--
 -- Jon W{tte, [e-mail], Mac Hacker Deluxe --

  "Never mistake a clear view for a short distance"
                     -- Saffo

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

>From Dave Falkenburg <[e-mail]>
Date: Thu, 28 Apr 1994 17:03:33 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]> Maynard James Handley,
[e-mail] writes:
>For examples, doesn't AIX have conventions about using the first N
registers
>to pass variables between functions. I don't know if MacOS on PowerPC has
>such conventions, but it expectects one of the registers always to point
>to the code fragment TOC thingie---would it not be very bad if xlc used
>said register for something else.

The PowerMac runtime environment is dervied from the AIX runtime model--
we used special versions of xlc to build the native portions of the
toolbox.

-Dave Falkenburg
-Apple Computer, Inc.

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

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