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

Text File | 2010-09-21 | 47KB | 1,319 lines

Received-Date: Tue, 10 May 1994 17:15:15 +0200
From: [e-mail] (Francois Pottier)
Subject: csmp-digest-v3-025, resend
To: [e-mail]
Date: Tue, 10 May 94 17:15:09 MET DST
X-Mailer: ELM [version 2.3 PL11]
Errors-To: [e-mail]
Reply-To: [e-mail]
X-Sequence: 28


Hi,
Issue 25 of the digest contains some binhexed files, which reportedly
caused some dumb mailers to extract the binhex codes and delete the rest.
I have removed the faulty thread; here is a "clean" digest.

Francois
[e-mail]

------

C.S.M.P. Digest             Tue, 10 May 94       Volume 3 : Issue 25

Today's Topics:

        CodeWarrior GOLD DR-2 - Can't seem to generate fast FP code
        Determining if user is on a network
        Sample Think C AE Code
        drawing arrowheads
        writing an INIT... a few questions



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] (Brian  Corrie)
Subject: CodeWarrior GOLD DR-2 - Can't seem to generate fast FP code
Date: 15 Apr 94 20:51:55 GMT
Organization: University of Victoria

G'day,

I just recently got my CodeWarrior Gold. I wrote a simple application that
does a bunch of floating point calculations (sin, cos, sqrt, *, / etc.)
to test the speed of my PowerMac 6100/60 compared to an RS6000 and SPARC
10 at work. Timings below:

RS6000         2.4 seconds
SPARC10     4.8 seconds
Quadra840AV    40 seconds
PowerMac 6100    53 seconds???????

Now obviously this code is running in emulation mode (at least I hope so
or I will be a bit bummed out 8-). The weird thing is that I CAN NOT get
this to change. I am running the PPC version of the compiler, I set the
preferences to what I think they should be to generate native PowerPC code,
use what I think are the right libraries, and lo and behold, it runs slow.

Now I am probably missing something obvious, and you are probably saying
RTFM, but really, I have spent the last two days trying to figure this out!
Reading the manual, talking to someone who has a bit more Mac expereince
than I do, etc. Still no luck. What am I doing wrong???? Any ideas?
Is there something obvious that I have to do. Did I install things
incorrectly? Is there a special library I need to use to take advantage
of the PPC floating point hardware? ARGGGHHHH. I want to say "look how
fast my machine is" but I can't at the moment!!!!!

Any and all pointers, even those exposing my stupidity, are welcome.

Cheers,

    Brian


--
                  Brian Corrie ([e-mail])
Under the most rigorously controlled conditions of pressure, temperature,
volume, humidity and other variables, the organism will do as it damn well
pleases. Sounds like some of the code I have written......  8-)

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

>From [e-mail] (Brian Lowry)
Date: 15 Apr 1994 22:12:20 GMT
Organization: Chem Eng - Univ of Alberta

In article <bcorrie.766443115@tara>, [e-mail] (Brian  Corrie)
wrote:

> I just recently got my CodeWarrior Gold. I wrote a simple application that
> does a bunch of floating point calculations (sin, cos, sqrt, *, / etc.)
> to test the speed of my PowerMac 6100/60 compared to an RS6000 and SPARC
> 10 at work. Timings below:
>
> RS6000         2.4 seconds
> SPARC10     4.8 seconds
> Quadra840AV    40 seconds
> PowerMac 6100    53 seconds???????

  Since sin, cos, and sqrt aren't supported by the PPC601, what sort of
speed did you expect?  Obviously you're calling SANE routines while the IBM
is calling efficent PPC routines.  You'd probably see a speed improvement
with even relatively inefficient sin/cos/sqrt algorithms.

--

Brian Lowry

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

>From [e-mail] (Brian  Corrie)
Date: 16 Apr 94 00:20:22 GMT
Organization: University of Victoria

[e-mail] (Brian Lowry) writes:
>In article <bcorrie.766443115@tara>, [e-mail] (Brian  Corrie)
>wrote:

>> I just recently got my CodeWarrior Gold. I wrote a simple application that
>> does a bunch of floating point calculations (sin, cos, sqrt, *, / etc.)
>> to test the speed of my PowerMac 6100/60 compared to an RS6000 and SPARC
>> 10 at work. Timings below:
>>
>> RS6000         2.4 seconds
>> SPARC10     4.8 seconds
>> Quadra840AV    40 seconds
>> PowerMac 6100    53 seconds???????

>  Since sin, cos, and sqrt aren't supported by the PPC601, what sort of
>speed did you expect?  Obviously you're calling SANE routines while the IBM
>is calling efficent PPC routines.  You'd probably see a speed improvement
>with even relatively inefficient sin/cos/sqrt algorithms.

Care to elaborate a bit on that? Like I said, I am not a Mac programmer
and don't know a lot about SANE, but it doesn't make much sense that
my PowerMac is SLOWER than a Quadra840 when the code on the PowerMac
is native PowerPC code. Surely the sin and cos functions are implemented
using the native PowerPC code and isn't being implemented as emmulated
020 code!?!?!?

How does one expect to take advantage of the floating point speed of the
PowerPC architecture if basic mathematical functions like sin, cos, and
sqrt are not implemented natively. Seems rather silly to me. Am I out to
lunch on this one???? Is their not a native implementation of SANE? I was
expecting to get an execution time of below ten seconds based on what I
have read about the PowerPC specs.

Any insights. Can someone set me straight, this doesn't make sense to me.

    Brian (stressed about his slow PowerMac) Corrie



    Brian

--
                  Brian Corrie ([e-mail])
Under the most rigorously controlled conditions of pressure, temperature,
volume, humidity and other variables, the organism will do as it damn well
pleases. Sounds like some of the code I have written......  8-)

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

>From [e-mail] (Brian  Corrie)
Date: 16 Apr 94 01:18:07 GMT
Organization: University of Victoria

Dave Falkenburg <[e-mail]> writes:
>In article <[e-mail]> Brian Lowry,
>[e-mail] writes:
Brian Corrie originally wrote:
>>> I just recently got my CodeWarrior Gold. I wrote a simple application that
>>> does a bunch of floating point calculations (sin, cos, sqrt, *, / etc.)
>>> to test the speed of my PowerMac 6100/60 compared to an RS6000 and SPARC
>>> 10 at work. Timings below:
>>>
>>> RS6000         2.4 seconds
>>> SPARC10     4.8 seconds
>>> Quadra840AV    40 seconds
>>> PowerMac 6100    53 seconds???????
>>
>>  Since sin, cos, and sqrt aren't supported by the PPC601, what sort of
>>speed did you expect?  Obviously you're calling SANE routines while the IBM
>>is calling efficent PPC routines.  You'd probably see a speed improvement
>>with even relatively inefficient sin/cos/sqrt algorithms.
>>
>>--
>>
>>Brian Lowry

>Remember that MW DR/2 doesn't generate really optimal code (yet). You're not
>calling SANE, you are just executing non-optimzied code on a RISC machine.

I realize that the code optimization isn't the best, but surely running
native code on a PowerPC should run faster than a Quadra840 with a
68881?2.  If not, I want my money back!!!! Seriously, if the sin, cos,
sqrt are running as native code and not being emulated as 020 through
SANE or some such bizarre twist, then why can't the PowerPC beat a
Quadra 840. Even if I turn off optimization and turn on debugging
and profiling on the SPARC10 I get a run time of 7.9 seconds. Still a
ton and a half less than 53. We are talking an order of magnitude
difference when I would expect them to be in the same ball park.

Almost all 3D graphics use sin, cos, and sqrt extensively. How can all
those native 3D programs claim massive speedups over high end Quadras
when I am getting worse performance!?! It just don't make sense mon,
I am still convinced that I am doing something ridiculously stoopid.
Please, someone just tell me what it is!  8-)

>If you compile on AIX with "-lm" and ship the code back over to your PowerMac
>you should see VERY nice performance improvements.

>Also: Were you using the Apple mathlib?

I was using the MathLib that comes with the CW DR/2 release, whatever
that is. It seems to me that I must be using the wrong library, but
its beyond me which one I should be using....

I will play some more with the compiler tonight and report further on
this "drama"

Cheers,

    Brian

--
                  Brian Corrie ([e-mail])
Under the most rigorously controlled conditions of pressure, temperature,
volume, humidity and other variables, the organism will do as it damn well
pleases. Sounds like some of the code I have written......  8-)

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

>From Chuck Browne <[e-mail]>
Date: Sat, 16 Apr 1994 02:37:14 GMT
Organization: Drexel Univ. Physics

In article <[e-mail]> Brian Lowry,
[e-mail] writes:
>  Since sin, cos, and sqrt aren't supported by the PPC601, what sort of
>speed did you expect?  Obviously you're calling SANE routines while the
IBM
>is calling efficent PPC routines.  You'd probably see a speed improvement
>with even relatively inefficient sin/cos/sqrt algorithms.

Well, in the MW manual, it says about SANE for the PowerMacs:

"SANE is dead."

Are you using the math library with <fp.h>? I believe that is what you
should be using. Not that I would really know, as I don't have a PowerMac
(although I will be able to test some calcs next week on one), but
since when has not knowing what you're talking about been a crime on
usenet? :-)

Anyway, I don't know if you're using the ANSI libs. They're probably
slower than the math library...

Chuck

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

>From Dave Falkenburg <[e-mail]>
Date: Fri, 15 Apr 1994 23:58:13 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]> Brian Lowry,
[e-mail] writes:
>> I just recently got my CodeWarrior Gold. I wrote a simple application
that
>> does a bunch of floating point calculations (sin, cos, sqrt, *, / etc.)
>> to test the speed of my PowerMac 6100/60 compared to an RS6000 and
SPARC
>> 10 at work. Timings below:
>>
>> RS6000         2.4 seconds
>> SPARC10     4.8 seconds
>> Quadra840AV    40 seconds
>> PowerMac 6100    53 seconds???????
>
>  Since sin, cos, and sqrt aren't supported by the PPC601, what sort of
>speed did you expect?  Obviously you're calling SANE routines while the
IBM
>is calling efficent PPC routines.  You'd probably see a speed improvement
>with even relatively inefficient sin/cos/sqrt algorithms.
>
>--
>
>Brian Lowry

Remember that MW DR/2 doesn't generate really optimal code (yet). You're
not
calling SANE, you are just executing non-optimzied code on a RISC machine.

If you compile on AIX with "-lm" and ship the code back over to your
PowerMac
you should see VERY nice performance improvements.

Also: Were you using the Apple mathlib?

-Dave Falkenburg
-Apple Computer, Inc.

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

>From [e-mail] (Anton Rang)
Date: 16 Apr 1994 01:56:31 GMT
Organization: Minnesota Angsters

In article <bcorrie.766443115@tara> [e-mail] (Brian  Corrie) writes:
>I just recently got my CodeWarrior Gold. I wrote a simple application that
>does a bunch of floating point calculations (sin, cos, sqrt, *, / etc.)
>to test the speed of my PowerMac 6100/60 compared to an RS6000 and SPARC
>10 at work. Timings below:

  Aha!  You have discovered Apple's Incredibly Inefficient Trig
Functions.  They're so bad that, as you discovered, the 840AV is
faster.  The cure is to write your own, snarf the library from the
RS/6000 (probably legal issues involved), or curse Apple until they
fix it.  (Hmm.)

  Check the timing of add/multiply and you'll see it's way faster than
any 68000.  So if Apple even used the same algorithms that the 68882
uses (or heck, even SANE) it would be faster.  :(
--
Anton Rang ([e-mail])

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

>From [e-mail] (John McEnerney)
Date: Sat, 16 Apr 1994 07:16:19 GMT
Organization: The World Public Access UNIX, Brookline, MA

[e-mail] (Brian Lowry) writes:

>In article <bcorrie.766443115@tara>, [e-mail] (Brian  Corrie)
>wrote:

>> I just recently got my CodeWarrior Gold. I wrote a simple application that
>> does a bunch of floating point calculations (sin, cos, sqrt, *, / etc.)
>> to test the speed of my PowerMac 6100/60 compared to an RS6000 and SPARC
>> 10 at work. Timings below:
>>
>> RS6000         2.4 seconds
>> SPARC10     4.8 seconds
>> Quadra840AV    40 seconds
>> PowerMac 6100    53 seconds???????

>  Since sin, cos, and sqrt aren't supported by the PPC601, what sort of
>speed did you expect?  Obviously you're calling SANE routines while the IBM
>is calling efficent PPC routines.  You'd probably see a speed improvement
>with even relatively inefficient sin/cos/sqrt algorithms.

This should not be true. When using sin(), cos() etc. one normally links
against the MathLib shared library from Apple. These routines were
supposedly coded for high performance.

-- John McEnerney, Metrowerks PowerPC Product Architect


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

>From [e-mail] (John W. Baxter)
Date: Fri, 15 Apr 1994 20:36:24 -0700
Organization: Internet for the Olympic Peninsula

In article <bcorrie.766459087@tara>, [e-mail] (Brian  Corrie)
wrote:

> I was using the MathLib that comes with the CW DR/2 release, whatever
> that is. It seems to me that I must be using the wrong library, but
> its beyond me which one I should be using....

That should be the right one (and should actually mean that you're running
the ROM-based fragment).

What data type are you using for your floating point?  float and double are
good (supported, except for some operations, by the chip)...long double is
not (done in software).  If you are using long double (and even more if you
are using one of the extended types left over from the old days), I'd
suggest you switch to double_t.  When compiled for PPC, that gives you
double (64-bit); when compiled for 68K Mac, it gives you long double (80 or
96 bit depending upon FPU setting).  On PPC compiles, long double is the
[somewhat strange] 128-bit format.

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

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

>From [e-mail] (Stephan Somogyi)
Date: Sat, 16 Apr 1994 17:24:31 GMT
Organization: MacUser Magazine US

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

> When using sin(), cos() etc. one normally links  against the MathLib
> shared library from Apple. These routines were  supposedly coded for
> high performance.

A fellow from Apple said in the PowerPC Talk area on AppleLink that they
are aware of MathLib's bad trig performance and are working on resolving
the problem. For the time being, the prudent thing to do seems to be to
get another trig implementation.

__________________________________________________________________________
Stephan Somogyi                 "Davidian Inside"                  MacUser

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

>From [e-mail] (Stephen C. Gilardi)
Date: Sat, 16 Apr 1994 20:20:08 GMT
Organization: SQ Software via The World Public Access UNIX, Brookline, MA

[e-mail] (Bill Oliver) writes:

>I've also been looking at the floating point performance of CodeWarrior
>C code on my Centris 660AV Mac. I've compiled a test program using the
>various ANSI881 libraries with what I believe are the appropriate
>compiler options. The program takes *twice* as long to exectute than
>the same program compiled on a NeXT Cube, which has the same CPU (25MHz
>68040).Obviously, I must be doing something wrong. Are there any
>example programs available (with projects) that illustrate how to get
>fast FP code from CW?

If you just include math.h, then all trig functions, logs, etc. will
be calculated using SANE.  If you #define __FASTMATH__ and/or
__HYBRIDMATH__ before include math.h, then the 68881 will be used
directly for those functions (at the expense of the extra error
checking and control which you get with SANE).

However, I believe there is a bug in the DR/2 math.h which makes those
#defines not have the desired effect.

Here's a portion of the bug report I sent:

[I think math.h is wrong...]

Here's how I think the relevant portion of math.h should read:

#ifdef __FASTMATH__
#define log(x)        _log(x)
#define log10(x)    _log10(x)
#endif

#ifdef    __HYBRIDMATH__
#define sin(x)        _sin(x)
#define cos(x)        _cos(x)
#define tan(x)        _tan(x)
#define asin(x)        _asin(x)
#define acos(x)        _acos(x)
#define atan(x)        _atan(x)
#define sinh(x)        _sinh(x)
#define cosh(x)        _cosh(x)
#define tanh(x)        _tanh(x)
#define exp(x)        _exp(x)
#define sqrt(x)        _sqrt(x)
#define fabs(x)        _fabs(x)
#define fmod(x,y)    _fmod((x),(y))
#define ldexp(x,n)    _ldexp((x),(n))
#endif

I believe that the underscores indicate direct calls to the 68881.
With it defined as I suggest, the MATH macros work as documented.

--Steve

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

>From [e-mail] (Anton Rang)
Date: 17 Apr 1994 02:39:15 GMT
Organization: Minnesota Angsters

In article <[e-mail]> [e-mail] (John McEnerney) writes:
>This should not be true. When using sin(), cos() etc. one normally links
>against the MathLib shared library from Apple. These routines were
>supposedly coded for high performance.

  Hmm.  Well, they ought to be, but another poster earlier (on
c.s.powerpc) gave me a benchmark to run on the 8100/80, and it
indicated that sin/cos are *very* slow compared to almost any other
implementation.  A few selected rows from the table he sent --

Machine                    MFLOPS        FLOPS/sin()
- -----                    ------        -----------

Cray-2                                   45.06             18.43
PowerMac 8100/80 (Apple SDK beta)        37.50            1223.88
IBM RS6000/550                 22.22              25.89
PowerMac 8100/80 (Metrowerks 1.0a1)      14.28             464.98
IBM RS6000/320H                     13.51              28.15

The MFLOPS is calculated in a tight loop where the multiply-add can be
used to advantage, thus the relatively high performance.  The compiler
makes a considerable difference here due primarily to loop unrolling,
which allows better instruction scheduling, and the use of the
load-with-update instructions by the Apple SDK compiler.

FLOPS/sin() is the relative performance of a loop which calls sin()
instead of doing multiplication/addition.  Note the incredibly slow
performance....
--
Anton Rang ([e-mail])

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

>From Dave Falkenburg <[e-mail]>
Date: Mon, 18 Apr 1994 21:08:56 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]> John McEnerney,
[e-mail] writes:
>This should not be true. When using sin(), cos() etc. one normally links
>against the MathLib shared library from Apple. These routines were
>supposedly coded for high performance.
>
>-- John McEnerney, Metrowerks PowerPC Product Architect

My bet is that they are coded to be highly accurate, so that when someone
decides to build a bridge or an airplane using a Mac it won't fail due to
a rounding error.

Lawyers are great, aren't they?

BTW: One of the NuCalc guys typed up a REALLY fast version of mathlib
that is less accurate, but MUCH faster. Think about table lookup and
interpolation. He probably wouldn't want you to design his next car with
it, however.

-Dave Falkenburg
-Apple Computer, Inc.

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

>From [e-mail] (Brian  Corrie)
Date: 20 Apr 94 20:39:44 GMT
Organization: University of Victoria

[e-mail] (Jonathan Hess) writes:
>In article <bcorrie.766459087@tara>
>[e-mail] (Brian  Corrie) writes:

>> Almost all 3D graphics use sin, cos, and sqrt extensively. How can all
>> those native 3D programs claim massive speedups over high end Quadras
>> when I am getting worse performance!?! It just don't make sense mon,
>> I am still convinced that I am doing something ridiculously stoopid.
>> Please, someone just tell me what it is!  8-)

>While it is besides the point of this thread I would tend to disagree
>with the statement that "almost all 3D graphics use sin, cos, and sqrt
>extensively."  Successfully fast packages avoid sin, cos, and sqrt as
>much as possibly.  You can rewrite the basic tranform and projection
>equations to where the 1 required trig operation can be computed and
>stored in a constant once per projection.

Hmm, I guess my previous post demonstrates that my
fingers do fly faster than my brain (which implies my brain ain't
to fast because I can't type!!! 8-). On thinking about it, I agree,
sin and cos are not used very often in graphics code. I was thinking
of shading calculations that can use trig functions, but on reflection
they rarely use sin/cos as there are usually more efficient ways
of doing the computation (on reflection, shading...hmmm, a bit of a pun...!)

>Ray tracers are another story since they have to do a lot more
>calculations with angles of incidence and things.

Even ray tracers can get away with using dot product, cross product etc.
and rarely use sin/cos. It is just convenient to think of them as sin/cos
as I did above.

Anyway, back to the thread of hacking down the slow sin/cos routines on
the PowerMacs. I still say that it is ridiculous for a Quadra 840 to
be faster than a PowerMac on native floating point sin/cos calculations.
Still no insights as to what I am doing wrong, if anything. Are sin/cos
really that slow on the PowerMacs???

Cheers,

    Brian


--
                  Brian Corrie ([e-mail])
Under the most rigorously controlled conditions of pressure, temperature,
volume, humidity and other variables, the organism will do as it damn well
pleases. Sounds like some of the code I have written......  8-)
>From [e-mail] (eric larson)
Subject: CodeWarrior GOLD DR-2 - Can't seem to generate fast FP code
Date: 20 Apr 94 18:52:00 -0500
Organization: FidoNet:* File Edit View Label Special                 ? D (1:2605/620)

 > In article <[e-mail]> John McEnerney,

 >>This should not be true. When using sin(), cos() etc. one normally links
 >>against the MathLib shared library from Apple. These routines were
 >>supposedly coded for high performance.

 > My bet is that they are coded to be highly accurate, so that when
 > someone decides to build a bridge or an airplane using a Mac it won't
 > fail due to a rounding error.

Butbutbut why would Seymour Cray ship a machine that produces lousy floating
point results? These things are generally used for simulations far more heavily
than an Mac ever is.

Meethinks this should be investigated carefully.

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

>From [e-mail] (Robert Cassidy)
Date: Thu, 21 Apr 1994 12:41:21 -0800
Organization: TLG Project

In article <bcorrie.766874384@tara>, [e-mail] (Brian  Corrie)
wrote:

[stuff deleted]

> Even ray tracers can get away with using dot product, cross product etc.
> and rarely use sin/cos. It is just convenient to think of them as sin/cos
> as I did above.
>
> Anyway, back to the thread of hacking down the slow sin/cos routines on
> the PowerMacs. I still say that it is ridiculous for a Quadra 840 to
> be faster than a PowerMac on native floating point sin/cos calculations.
> Still no insights as to what I am doing wrong, if anything. Are sin/cos
> really that slow on the PowerMacs???

Since sometimes you *have* to do a lot of sin/cos work I don't think these
functions should be ignored. I'm toying with the idea of writing a fp
library (probably mostly trig) that would calculate w.r.t. a determined
precision. I remember writing programs on the VAX at school that seemed
unbelievably slow at sin/cos. It turned out that I was getting far more
precision than I needed. I rewrote the routines and got something like a
10x speed improvement. Often you don't need a lot of precision
(particularly with graphics) so why do all of the work of calculating what
you don't use? If there is interest in this I may pursue it further (of
course I have to get a PM first! :-)

--
Robert Cassidy
TLG Project
UC Irvine

Let's hope 'Information SuperTollroad' isn't the catchphrase of the next
decade...

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

>From [e-mail] (Gordon Apple)
Date: 22 Apr 1994 12:16:21 -0800
Organization: (none)

Since sometimes you *have* to do a lot of sin/cos work I don't think these
functions should be ignored. I'm toying with the idea of writing a fp
library (probably mostly trig) that would calculate w.r.t. a determined
precision. I remember writing programs on the VAX at school that seemed
unbelievably slow at sin/cos. It turned out that I was getting far more
precision than I needed. I rewrote the routines and got something like a
10x speed improvement. Often you don't need a lot of precision
(particularly with graphics) so why do all of the work of calculating what
you don't use? If there is interest in this I may pursue it further (of
course I have to get a PM first! :-)


    The fastest way to generate sin and cos is with a look-up table.  If
you're doing statistical communications simulations, or doing a software
modem, the table size deoesn't have to be very large for your error noise to
be swamped by the input noise.  You can build the table from SANE or whatever
else is handy when you need it.  If you need more precision, use of the above
table in conjunction with the double-angle formula gives highly accurate
results with minimal computation. We have used these techniques for years in
simulations and in DSPs.  They are extremely computationally efficient.  In
fact, if you write it for a PowerPC processor, you could pipeline the
process, using both the integer and floating point units at the same time.
That sucker should scream with that type algorithm.


G. Gordon Apple, PhD
Advanced Communications Engineering, Inc.
Redondo Beach, CA

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

>From [e-mail] (Brian Lowry)
Date: 24 Apr 1994 00:08:46 GMT
Organization: Chem Eng - Univ of Alberta

  It really isn't so hard to code efficent sin/cos/sqrt routines.  There
are complete reference books with excellent algorithms (for much more
difficult functions than sin or cos).  If anyone wants simple sin, cos, and
sqrt routines which are on the order of optimal (in C, no doubt assembly
would be faster), then just send me e-mail.

--

Brian Lowry

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

>From [e-mail] (Michael A. Kelly)
Subject: Determining if user is on a network
Date: 25 Apr 1994 15:26:26 -0700
Organization: High Risk Ventures


Hey,

Is there any way to determine if a machine is on a local network?  I can
find out if AppleTalk is on, but that doesn't tell me if the machine is
part of a network.

Thanks,

Mike.
--
_____________________________________________________________________________
Michael A. Kelly                                                President/CEO
[e-mail]                                      High Risk Ventures
_____________________________________________________________________________

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

>From [e-mail] (Matt Mora)
Date: 26 Apr 1994 10:44:04 -0700
Organization: SRI International, Menlo Park, CA

In article <2phg2i$[e-mail]> [e-mail] (Michael A. Kelly) writes:
>
>Hey,
>
>Is there any way to determine if a machine is on a local network?  I can
>find out if AppleTalk is on, but that doesn't tell me if the machine is
>part of a network.


Here you go.

/*
    Sample code to demonstrate use of the LAP Manager call to determine
    the current connection type i.e LocalTalk, EtherTalk phase 1/2, or
    TokenTalk phase 2.
    Rich Kubota
    DTS
*/

#include <Types.h>
#include <string.h>

#define LGetATalkInfo     0x09        /* Get AppleTalk info */

/* 'atlk' resource ID's of Apple supplied driver software. */
#define    LTalk        0
#define    ETalkPh1    2
#define    TTalkPh2    5
#define    ETalkPh2    10
#define LAPMgrPtr             0xB18
#define LAPMgrCall            2

#include "GetADEVType.h"

pascal long CallLAPMgr(short selector)
{
    asm{
        MOVE.W        selector,D0        ; move selector parameter into D0
        MOVE.L        A2,-(A7)        ; store A2 on stack
        MOVEA.L        LAPMgrPtr,A2    ; Set A2 to address of LAP Mgr.
        JSR            LAPMgrCall(A2)    ; Call LAP Manager
        MOVE.L        D1,0x0A(A6)        ; Place result onto stack
        MOVE.L        (A7)+,A2        ; Restore A2
        UNLK        A6                ; restore stack frame
        MOVEA.L        (A7)+,A0        ; put return address into A0
        ADDQ.W        #0x02,A7        ; clear off the parameter
        JMP            (A0)            ; return to caller
        RTS
    }
}
void CheckNetType(char * resultStr)
{
    long    result;
    char    adevType;
    char    slot;

    //Debugger();
    result = CallLAPMgr(LGetATalkInfo);
    adevType = result & 0x000000FF;    /* atlk resource id is return in LSB */
    slot = result>>24;                 /* card slot returned in MSB */

    switch (adevType) {
        case LTalk:
                strcpy(resultStr,"LocalTalk");
                break;
        case ETalkPh1:
                strcpy(resultStr,"EtherTalk phase 1");
                break;
        case ETalkPh2:
                strcpy(resultStr,"EtherTalk phase 2");
                break;
        case TTalkPh2:
                strcpy(resultStr,"TokenTalk");
                break;
        default:
                strcpy(resultStr,"Unrecognized connection");
                break;
        }

}

Warning. I never could get this to work on all systems.

Xavier



--
___________________________________________________________
Matthew Xavier Mora                       [e-mail]
SRI International                       [e-mail]
333 Ravenswood Ave                    Menlo Park, CA. 94025

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

>From [e-mail] (Ian Neath)
Subject: Sample Think C AE Code
Date: Wed, 20 Apr 1994 13:18:15 GMT
Organization: Purdue University

As an amateur programmer trying to stay on the cutting edge
of yesterday's technology, I'm trying to implement AE and
custom AE into some apps.  I can't find much sample C code,
though.  Any suggestions for locations (already tried
sumex, etc.) greatly appreciated.  (We rarely get alt.sources.
mac here)


--
      Ian Neath        | There are four kinds of people in this world:
[e-mail] | cretins, fools, morons and lunatics - U. Eco

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

>From Deirdre Maloy <[e-mail]>
Date: Wed, 20 Apr 1994 18:24:07 GMT
Organization: Metro Information Services, Raleigh NC

I remember that I found precious little about SENDING custom apple
events. On the off chance this'll help, here's a sample sending code and
receiving code (which go in two different apps). Despite the debug code,
they do work -- one app sends another app the info about a file to
launch, waits for an acknowledgement from the receiving app, then renames
itself and quits. When the first app detects that the other app quit, it
eats it. I had to do this for complicated reasons relating to auto-update
version control experimentation. <g> All our applications are launched by
the program we call "Itty" which is a faceless app that acts as a
switchboard for apple events between our applications -- you can send an
apple event to the Itty for an application that's not launched. It will
then launch the app and forward the message when the app is ready to
receive. This set of events is just designed for one app to tell the Itty
to launch another app and when--though the when is controlled elsewhere.

_Deirdre

On receiving end:
#include    "Launcher.h"
#include    <Aliases.h>

extern    Boolean                highPriority;
extern    launchRecord            myLaunchInfo[MAX_SUBLAUNCHES];        //    info on where
app is located
extern    short                currentLaunch;
extern    Str255                myFile;                        //    name of current document


pascal OSErr myHandleItty(AppleEvent *ittyEvent, AppleEvent *replyEvent,
long refCon)
{
        OSErr        myErr;
        AEDesc        myDesc;
        long            actualSize;
        DescType        actualType;
        long            count;
        AEDescList    myIttyList;
        AEKeyword    myKeyword;
        DescType        myType;
        Str32        myString;

    highPriority = TRUE;

    myErr = AEGetParamPtr(ittyEvent, 'app ', 'fss ',
                    &myType, (Ptr) &myLaunchInfo[currentLaunch].appName,
                    (long) sizeof(FSSpec), &actualSize);

    myErr = HGetVol(myString,&myLaunchInfo[currentLaunch].appName.vRefNum,
                    &myLaunchInfo[currentLaunch].appName.parID);

    myErr = AEGetParamPtr(ittyEvent, 'doc ', 's255',
                    &myType, (Ptr) &myFile, (long) sizeof(Str255), &actualSize);

    if (myErr != noErr)
        myFile[0] = 0;

    CopyPString("\pHowdy",myString);

    myErr = AEPutParamPtr(replyEvent, keyErrorString, typeChar,
(Ptr)&myString[1], myString[0]);

    SysBeep(3);

    return (noErr);
}


#include "Teeny.h"
#include    <EPPC.h>
#include    <AppleEvents.h>

extern    FSSpec                myAppLoc;        //    info on where doc to open is located
extern    Str255                myDocPath;
extern    ProcessSerialNumber    PSN;
extern    Boolean                gQuit;

void    getIttyPSN(ProcessSerialNumber *ittyPSN, OSType ittySig);
pascal Boolean MyIdleFunction(EventRecord *event,
                    long *sleepTime, RgnHandle *mouseRgn);

void    sendIttyAE(void)
{
    //    Here's all the garbage you will need.

            OSType                ittyType = 'I???', ittyMsg = 'l8tr';
            AEAddressDesc            ittyDesc;
            AEDescList            myIttyList;
            AEDesc                myApp, myDoc;
            AppleEvent            myAppleEvent, myAEreply;
            short                iErr;
            ProcessSerialNumber    ittyPSN;
            EventRecord            myEvent;

    //    create the address descriptor record.

        iErr = AECreateDesc(typeApplSignature, (Ptr)&ittyType,
sizeof(ittyType), &ittyDesc);

    //    exit if there's an error

        if (iErr != noErr)
            goto Sayonara;

    //    For the IttyBitty, the Apple Event TYPE should be 'I???',
    //    which is also IttyBitty's signature. The Event ID should be one of
the following:
    //        'imed'    Launch this application IMMEDIATELY.
    //        'delo'    Delete file.
    //        'l8tr'    Launch this application when I quit.
    //        (no other events defined)
    //
    //    in all cases, a parameter list is required
    //        'app '    for application to launch (fsspec expected)
    //        'doc '    for document to launch with app (Str255 expected)
    //        'fss '        for any other fsspec

        iErr = AECreateAppleEvent(ittyType, ittyMsg, &ittyDesc,
kAutoGenerateReturnID,
                kAnyTransactionID, &myAppleEvent);

        if (iErr != noErr)
            goto Sayonara;

        iErr = AEPutParamPtr(&myAppleEvent, 'app ', 'fss ', (Ptr) &myAppLoc,
(long) sizeof(FSSpec));

        if (myDocPath[0] > 2)
            iErr = AEPutParamPtr(&myAppleEvent, 'doc ', 's255', (Ptr) myDocPath,
(long) sizeof(Str255));

    //    We should be OK to send the apple event now.

        iErr = AESend(&myAppleEvent, &myAEreply, kAEWaitReply+kAECanInteract,
                    kAEHighPriority, 720, &MyIdleFunction, 0L);

        WaitNextEvent(0x2, &myEvent, 40L, 0);

        if (iErr == noErr)    SysBeep(3);    //    to let user know AppleEvent was sent

        gQuit = TRUE;                    //    our task is done, the AppleEvent was sent

Sayonara:
        AEDisposeDesc(&ittyDesc);
        AEDisposeDesc(&myAppleEvent);
        AEDisposeDesc(&myAEreply);
}



// prototype your routine like this prior to calling it
// NOTE that it uses pascal calling conventions since it is called
// from the AESend routine
pascal Boolean MyIdleFunction(EventRecord *event,
                    long  *sleepTime, RgnHandle *mouseRgn);

// Application global variable to keep track of cursor rgn

RgnHandle gCursorRgn;

pascal Boolean MyIdleFunction(EventRecord *event,
                    long *sleepTime, RgnHandle *mouseRgn)
{
    char         hiByte;
    OSErr     myErr;

    switch ( event->what )
    {
        case updateEvt:
        case activateEvt:            // every idle function should handle
        case app4Evt:                // these kinds of events
            SetFrontProcess(&PSN);
            break;
        case nullEvent:
                                // set the sleeptime and mouseRgn parameters
            *mouseRgn = gCursorRgn;
            *sleepTime = 10;        // use the correct value for your app
            SystemTask();            // the application's idle handling
            SystemTask();            // the application's idle handling
            SystemTask();            // the application's idle handling
            break;
    }
    return FALSE;
}



In article <[e-mail]> Ian Neath,
[e-mail] writes:
>As an amateur programmer trying to stay on the cutting edge
>of yesterday's technology, I'm trying to implement AE and
>custom AE into some apps.  I can't find much sample C code,
>though.  Any suggestions for locations (already tried
>sumex, etc.) greatly appreciated.  (We rarely get alt.sources.
>mac here)
--
Deirdre Maloy, Metro Information Services, Raleigh NC
"My employer pays me for my opinions; you get them free."

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

>From [e-mail] (John40)
Date: 22 Apr 1994 19:25:02 -0400
Organization: America Online, Inc. (1-800-827-6364)

In article <[e-mail]>, [e-mail] (Ian
Neath) writes:

>As an amateur programmer trying to stay on the cutting edge
>of yesterday's technology, I'm trying to implement AE and
>custom AE into some apps.  I can't find much sample C code,
>though.  Any suggestions for locations (already tried
>sumex, etc.) greatly appreciated.  (We rarely get alt.sources.
>mac here)

Get yourself a copy of UserLand Frontier's SDK 3.0.  It's packed with useful
Apple Events stuff.  The code is even free to use in your own programs
(no royalty, and its source code can even by distributed if you don't change it
- this is
according to their documentation).  You can get the SDK from BBSs such as
America Online
or by buying Frontier.

John Schlack


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

>From [e-mail] (Art Eschenlauer)
Date: Sun, 24 Apr 1994 18:04:22 GMT
Organization: University of Minnesota, Twin Cities

Today I noted in the MERIT Macintosh software archives at umich:

/mac/development/libraries/aebuilder1.1.cpt.hqx  (134K)
A ThinkC 5.0 kit to help construct and call Apple Events.
Very thorough and helpful. [Description theirs, not mine.]
--
[e-mail] (Art Eschenlauer,
U of M Agronomy and Plant Genetics Dept.)

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

>From [e-mail] (Dan Acton)
Subject: drawing arrowheads
Date: 25 Apr 1994 08:36:10 -0600
Organization: Beak Consultants Ltd.

Has anyone out there figured out how to draw nice arrowheads on the ends of
lines similar to MacDraw, SuperPaint, Canvas, etc.?  I've written a routine
which uses QuickDraw arcs and some trigonometry and everyone says they look
terrible.
********************************************
 Sent via BeakNet
 Beak Consultants Limited, Electronic Mail Network
   42 Arrow Road
   Guelph, Ontario, CANADA
   (519) 763-BEAK (voice)
   [phone] (FAX)
********************************************

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

>From [e-mail] (Sak Wathanasin)
Date: Tue, 26 Apr 94 00:12:12 GMT
Organization: Network Analysis Ltd


In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (Dan Acton) writes:
> Has anyone out there figured out how to draw nice arrowheads on the ends of
> lines similar to MacDraw, SuperPaint, Canvas, etc.?  I've written a routine
> which uses QuickDraw arcs and some trigonometry and everyone says they look
> terrible.

Oh well, I might as well get my code pulled apart. It's not
particularly efficient, but I only have to draw these occasionally. All
suggestions for improvement gratefully received. This has been pulled
from a MacApp prog; just assume that everything has been declared
appropriately. The consts were worked out using a desk calculator...

The method computes a QD poly, and is called whenever the start/end
points change. When I have to refresh the view, I call
PaintPoly(fArrowHead) after I draw the connecting line.

Set tabstops=4 for proper alignment.

pascal void
TEPConnection::CalcArrows    (void)
{
    const extended    kDeg2Rad     = 0.01745329252;        // for converting degrees to radians
    const extended    kArrowLength = 10.0;                // length of arrowhead
    const extended    kArrowAngle  = kDeg2Rad * 30.0;        // angle arrow makes with line
    short            angle;                                // angle between connecting line & vertical axis
    Rect            r;
                                                        // bounding box of agent
    Point            apex          = fEndPt;                // point of the arrow
    Point            pt2, pt3;                            // corners of the arrow

    r.left    = fStartPt.h - 10;
    r.top    = fStartPt.v - 10;
    r.right    = fStartPt.h + 10;
    r.bottom= fStartPt.v + 10;                            // concoct a square around the start pt
    PtToAngle(&r, apex, &angle);                        // calc angle of connecting line
    extended    rangle = (extended)(90-angle) * kDeg2Rad;
                                                        // the angle in radians                                                        // the angle in radians
    extended    temp    = rangle - kArrowAngle;
    pt2.h    = (short)((extended)apex.h - (kArrowLength * cos(temp)));
    pt2.v    = (short)((extended)apex.v + (kArrowLength * sin(temp)));
    temp     = rangle + kArrowAngle;
    pt3.h    = (short)((extended)apex.h - (kArrowLength * cos(temp)));
    pt3.v    = (short)((extended)apex.v + (kArrowLength * sin(temp)));

    if (fArrowPoly != NULL) {
        KillPoly(fArrowPoly);                            // get rid of prev arrow
        fArrowPoly = NULL;
    }
    PolyHandle    arrowPoly = OpenPoly();
    FailNULL(arrowPoly);
    MoveTo(apex.h, apex.v);
    LineTo(pt2.h, pt2.v);
    LineTo(pt3.h, pt3.v);
    LineTo(apex.h, apex.v);
    ClosePoly();
    fArrowPoly    = arrowPoly;

    // reset the bounding box
    // ... some code to compute the bounding box, which you probably don't need
}

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 [e-mail] (Josh Adams)
Subject: writing an INIT... a few questions
Date: 22 Apr 1994 16:14:32 GMT
Organization: Project GLUE, University of Maryland, College Park

Hi,
I am a somewhat new Mac programmer. I have written some apps, but now I want
to write an INIT (I think). I was wondering a few things:
1) Is there some info somewhere that documents how to do this and ant
background info I should have about things like memory and registers
and such?
2) If I want to patch a trap for all applications, but I want to have a
window constantly displaying stuff, should I have an init to patch the
trap(s) and then have it launch an app at startup, then send info from
the patched trap to my app with Apple Events? Would there be a better
way? I couldn't imagine that it would be good to have the init make
a window...
3) What does it mean to detach a resource? Would this affect me?
4) What registers do I have to care about?
5) Is there a way to access the small black line at the bottom of the
menu bar? Like if I drew something there, the menu would just erase
over it, right? Is there a way to change the line to be more than one
color? (Just wondering... I probably won't need to, but it is interesting
to know.

Thanks for all replies and info,
Stu


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

>From Aaron Wohl <[e-mail]>
Date: Mon, 25 Apr 1994 07:18:46 -0400
Organization: Systems Group 97, Carnegie Mellon, Pittsburgh, PA

For the source code to three inits look in host akutaktak.andrew.cmu.edu
[128.2.35.1] /aw0g/*.hqx.

Excerpts from netnews.comp.sys.mac.programmer: 22-Apr-94 writing an
INIT... a few qu.. Josh [e-mail] (1094)

> 1) Is there some info somewhere that documents how to do this and ant
> background info I should have about things like memory and registers
> and such?


Not that I know of.   I guess I should write a how to write an
INIT/DRVR/CDEV faq...

Excerpts from netnews.comp.sys.mac.programmer: 22-Apr-94 writing an
INIT... a few qu.. Josh [e-mail] (1094)

> 2) If I want to patch a trap for all applications, but I want to have a
> window constantly displaying stuff,

The patch code needs to live in the system heap (otherwise multifinder
will swap the patch out when it switches applications).  The patch
should probably post it's information to a device driver.  The
application should read it from the driver.   I don't know enough about
apple events to know what problems there would be in using them.  I
suspect that there would be difficulties in getting the port for apple
events to not be closed when the applicaiton that was running when it
was opened quit.

Excerpts from netnews.comp.sys.mac.programmer: 22-Apr-94 writing an
INIT... a few qu.. Josh [e-mail] (1094)

> 3) What does it mean to detach a resource? Would this affect me?


A code resource (the code for an INIT) is still attached to the resource
map for the init file.   If you don't detach it (with DetachResource)
the code block will be reused when the mac os cleans up after your init
starts and it goes on to the next init.  Rather than detach the init
code I prefer to have the init install anouther code resource.  That way
the installation part of the init code is freeed as it should be.

Excerpts from netnews.comp.sys.mac.programmer: 22-Apr-94 writing an
INIT... a few qu.. Josh [e-mail] (1094)

> 4) What registers do I have to care about?


For an init in general you don't have to worry about it.  Except if you
are using think c (which I recommend) you need to set up the A4
register.   See the init code in the softkiss driver for a good example
of dealing with this.

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

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