From: pottier@clipper.ens.fr (Francois Pottier) Subject: csmp-digest-v3-025, resend Date: Tue, 10 May 94 17:15:09 MET DST 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 pottier@dmi.ens.fr ------ 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 (pottier@clipper.ens.fr). The digest is a collection of article threads from the internet newsgroup comp.sys.mac.programmer. It is designed for people who read c.s.m.p. semi- regularly and want an archive of the discussions. If you don't know what a newsgroup is, you probably don't have access to it. Ask your systems administrator(s) for details. If you don't have access to news, you may still be able to post messages to the group by using a mail server like anon.penet.fi (mail help@anon.penet.fi for more information). Each issue of the digest contains one or more sets of articles (called threads), with each set corresponding to a 'discussion' of a particular subject. The articles are not edited; all articles included in this digest are in their original posted form (as received by our news server at nef.ens.fr). Article threads are not added to the digest until the last article added to the thread is at least two weeks old (this is to ensure that the thread is dead before adding it to the digest). Article threads that consist of only one message are generally not included in the digest. The digest is officially distributed by two means, by email and ftp. If you want to receive the digest by mail, send email to listserv@ens.fr with no subject and one of the following commands as body: help Sends you a summary of commands subscribe csmp-digest Your Name Adds you to the mailing list signoff csmp-digest Removes you from the list Once you have subscribed, you will automatically receive each new issue as it is created. The official ftp info is //ftp.dartmouth.edu/pub/csmp-digest. Questions related to the ftp site should be directed to scott.silver@dartmouth.edu. Currently no previous volumes of the CSMP digest are available there. Also, the digests are available to WAIS users as comp.sys.mac.programmer.src. ------------------------------------------------------- >From bcorrie@csr.UVic.CA (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 (bcorrie@csr.uvic.ca) 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 usenet@lowry.eche.ualberta.ca (Brian Lowry) Date: 15 Apr 1994 22:12:20 GMT Organization: Chem Eng - Univ of Alberta In article , bcorrie@csr.UVic.CA (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 bcorrie@csr.UVic.CA (Brian Corrie) Date: 16 Apr 94 00:20:22 GMT Organization: University of Victoria usenet@lowry.eche.ualberta.ca (Brian Lowry) writes: >In article , bcorrie@csr.UVic.CA (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 (bcorrie@csr.uvic.ca) 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 bcorrie@csr.UVic.CA (Brian Corrie) Date: 16 Apr 94 01:18:07 GMT Organization: University of Victoria Dave Falkenburg writes: >In article Brian Lowry, >usenet@lowry.eche.ualberta.ca 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 (bcorrie@csr.uvic.ca) 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 Date: Sat, 16 Apr 1994 02:37:14 GMT Organization: Drexel Univ. Physics In article Brian Lowry, usenet@lowry.eche.ualberta.ca 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 ? 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 Date: Fri, 15 Apr 1994 23:58:13 GMT Organization: Apple Computer, Inc. In article Brian Lowry, usenet@lowry.eche.ualberta.ca 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 rang@winternet.mpls.mn.us (Anton Rang) Date: 16 Apr 1994 01:56:31 GMT Organization: Minnesota Angsters In article bcorrie@csr.UVic.CA (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 (rang@winternet.mpls.mn.us) +++++++++++++++++++++++++++ >From johnmce@world.std.com (John McEnerney) Date: Sat, 16 Apr 1994 07:16:19 GMT Organization: The World Public Access UNIX, Brookline, MA usenet@lowry.eche.ualberta.ca (Brian Lowry) writes: >In article , bcorrie@csr.UVic.CA (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 jwbaxter@olympus.net (John W. Baxter) Date: Fri, 15 Apr 1994 20:36:24 -0700 Organization: Internet for the Olympic Peninsula In article , bcorrie@csr.UVic.CA (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] jwbaxter@pt.olympus.net +++++++++++++++++++++++++++ >From somogyi@macuser.ziff.com (Stephan Somogyi) Date: Sat, 16 Apr 1994 17:24:31 GMT Organization: MacUser Magazine US In article , johnmce@world.std.com (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 squeegee@world.std.com (Stephen C. Gilardi) Date: Sat, 16 Apr 1994 20:20:08 GMT Organization: SQ Software via The World Public Access UNIX, Brookline, MA oliver@psy.fsu.edu (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 rang@winternet.mpls.mn.us (Anton Rang) Date: 17 Apr 1994 02:39:15 GMT Organization: Minnesota Angsters In article johnmce@world.std.com (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 (rang@winternet.mpls.mn.us) +++++++++++++++++++++++++++ >From Dave Falkenburg Date: Mon, 18 Apr 1994 21:08:56 GMT Organization: Apple Computer, Inc. In article John McEnerney, johnmce@world.std.com 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 bcorrie@csr.UVic.CA (Brian Corrie) Date: 20 Apr 94 20:39:44 GMT Organization: University of Victoria ViviStar@ACM.org (Jonathan Hess) writes: >In article >bcorrie@csr.UVic.CA (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 (bcorrie@csr.uvic.ca) 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 eric.larson@f620.n2605.z1.fidonet.org (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 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 rmcassid@uci.edu (Robert Cassidy) Date: Thu, 21 Apr 1994 12:41:21 -0800 Organization: TLG Project In article , bcorrie@csr.UVic.CA (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 AppleGG@lamg.com (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 usenet@lowry.eche.ualberta.ca (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 mkelly@cs.uoregon.edu (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 mkelly@cs.uoregon.edu High Risk Ventures _____________________________________________________________________________ +++++++++++++++++++++++++++ >From mxmora@unix.sri.com (Matt Mora) Date: 26 Apr 1994 10:44:04 -0700 Organization: SRI International, Menlo Park, CA In article <2phg2i$9lb@majestix.cs.uoregon.edu> mkelly@cs.uoregon.edu (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 #include #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 Matt_Mora@sri.com SRI International mxmora@unix.sri.com 333 Ravenswood Ave Menlo Park, CA. 94025 --------------------------- >From neath@brazil.psych.purdue.edu (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: neath@psych.purdue.edu | cretins, fools, morons and lunatics - U. Eco +++++++++++++++++++++++++++ >From Deirdre Maloy 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. 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 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 #include 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 Ian Neath, neath@brazil.psych.purdue.edu 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 john40@aol.com (John40) Date: 22 Apr 1994 19:25:02 -0400 Organization: America Online, Inc. (1-800-827-6364) In article , neath@brazil.psych.purdue.edu (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 eschen@molbio.cbs.umn.edu (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.] -- eschen@molbio.cbs.umn.edu (Art Eschenlauer, U of M Agronomy and Plant Genetics Dept.) --------------------------- >From dacton@beak.com (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) (519) 763-2378 (FAX) ******************************************** +++++++++++++++++++++++++++ >From sw@network-analysis-ltd.co.uk (Sak Wathanasin) Date: Tue, 26 Apr 94 00:12:12 GMT Organization: Network Analysis Ltd In article <1407844318.11694@beaknet1.beak.com> (comp.sys.mac.programmer), dacton@beak.com (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: sw@network-analysis-ltd.co.uk uucp: ...!uknet!nan!sw AppleLink: NAN.LTD Phone: (+44) 203 419996 Mobile:(+44) 850 587411 Fax: (+44) 203 690690 --------------------------- >From jadams@eng.umd.edu (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 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 Adams@eng.umd.edu (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 Adams@eng.umd.edu (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 Adams@eng.umd.edu (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 Adams@eng.umd.edu (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 **********************