From: pottier@clipper.ens.fr (Francois Pottier) Subject: csmp-digest-v3-038 Date: Tue, 21 Jun 1994 14:04:20 +0200 (MET DST) C.S.M.P. Digest Tue, 21 Jun 94 Volume 3 : Issue 38 Today's Topics: CopyBits with PixMap Gestalt, SU3.0 & List Manager How to tell what kind of drive a volume is? Photoshop Plug-in Filters useable with other programs? Scheduling Sleep in WaitNextEvent What is "Clipping Extension"? allocating memory quickly -- how? sqrti() [Re: Faster Square Root Algorithm] The Comp.Sys.Mac.Programmer Digest is moderated by Francois Pottier (pottier@clipper.ens.fr). The digest is a collection of article threads from the internet newsgroup comp.sys.mac.programmer. It is designed for people who read c.s.m.p. semi- regularly and want an archive of the discussions. If you don't know what a newsgroup is, you probably don't have access to it. Ask your systems administrator(s) for details. If you don't have access to news, you may still be able to post messages to the group by using a mail server like anon.penet.fi (mail help@anon.penet.fi for more information). Each issue of the digest contains one or more sets of articles (called threads), with each set corresponding to a 'discussion' of a particular subject. The articles are not edited; all articles included in this digest are in their original posted form (as received by our news server at nef.ens.fr). Article threads are not added to the digest until the last article added to the thread is at least two weeks old (this is to ensure that the thread is dead before adding it to the digest). Article threads that consist of only one message are generally not included in the digest. The digest is officially distributed by two means, by email and ftp. If you want to receive the digest by mail, send email to listserv@ens.fr with no subject and one of the following commands as body: help Sends you a summary of commands subscribe csmp-digest Your Name Adds you to the mailing list signoff csmp-digest Removes you from the list Once you have subscribed, you will automatically receive each new issue as it is created. The official ftp info is //ftp.dartmouth.edu/pub/csmp-digest. Questions related to the ftp site should be directed to scott.silver@dartmouth.edu. Currently no previous volumes of the CSMP digest are available there. Also, the digests are available to WAIS users. To search back issues with WAIS, use comp.sys.mac.programmer.src. With Mosaic, use http://www.wais.com/wais-dbs/comp.sys.mac.programmer.html. ------------------------------------------------------- >From ragatz@nevada.edu (Steven Ragatz) Subject: CopyBits with PixMap Date: 5 Jun 1994 09:52:39 GMT Organization: University of Nevada System Computing Services I am working through the examples in D. Mark's second Primer book using Think C/C++ v. 6.xx. I am trying to use CopyBits to copy a PixMap to a window. I think that I have typed the code in correctly and I have looked at the appropriate header files but things are still wrong. Here is the code in question: #include #include #define NIL_POINTER 0L WindowPtr gColorWindow; Rect source, dest; ... /* Setup rects and stuff */ ... CopyBits( &((CGrafPtr)gColorWindow)->portPixMap, &((CGrafPtr)gColorWindow)->portPixMap, &source, &dest, srcCopy, NIL_POINTER ); The error that the compiler gives is: File ̉ColorTutor.c; Line 305 Error: first argument to function CopyBits does not match prototype so... I look up CopyBits and find it to be: pascal void CopyBits(const BitMap *srcBits,const BitMap *dstBits,const Rect *srcRect, const Rect *dstRect,short mode,RgnHandle maskRgn) I am under the impression that with QD, CopyBits uses PixMaps the same way as it used to use BitMaps. I looked up an example that uses a GrafPtr cast instead of a CGrafPtr and it works as: CopyBits (& ((GrafPtr)Port1)->portBits, &((GrafPtr)Port2)->portBits, &Rect1, &Rect2, 0, theregion); so, I am left confused and stumped. Could anyone tell me where I am going wrong with my data structures? - Steve +++++++++++++++++++++++++++ >From alex@metcalf.demon.co.uk (Alex Metcalf) Date: Sun, 5 Jun 1994 16:19:56 GMT Organization: Best Before Yesterday In article <2ss797$s80@post-office.nevada.edu>, ragatz@nevada.edu (Steven Ragatz) wrote: > I am working through the examples in D. Mark's second Primer book using > Think C/C++ v. 6.xx. I am trying to use CopyBits to copy a PixMap to a > window. I think that I have typed the code in correctly and I have > looked at the appropriate header files but things are still wrong. Here is > the code in question: > > #include > #include > > #define NIL_POINTER 0L > WindowPtr gColorWindow; > Rect source, dest; > ... > /* Setup rects and stuff */ > ... > CopyBits( &((CGrafPtr)gColorWindow)->portPixMap, > &((CGrafPtr)gColorWindow)->portPixMap, > &source, &dest, srcCopy, NIL_POINTER ); > > The error that the compiler gives is: > > File ColorTutor.c; Line 305 > Error: first argument to function CopyBits does not match prototype > Steve, Code looks OK: just typecast your portPixMap to a (BitMap *) like this: CopyBits ( (BitMap *) ((CGrafPtr)gColorWindow)->portPixMap, ... Alex -- Alex Metcalf, Best Before Yesterday Mac programmer in C, C++, HyperTalk, assembler Juggler, 3-ball tricks Internet: alex@metcalf.demon.co.uk Fax (UK): (0570) 45636 Fax (US / Canada): 011 44 570 45636 +++++++++++++++++++++++++++ >From kenlong@netcom.com (Ken Long) Date: Sun, 5 Jun 1994 16:22:58 GMT Organization: NETCOM On-line Communication Services (408 261-4700 guest) I download a working version of Dave Mark's "ColorTotor" from America Online, a couple years ago. It's currently in my floppy archives. someone else could probably answer your question before I log off, get it, log on and send you the fragment. But I was also amazed at the similaritios between that program and one called "CopyBits" which I got of ftp devtools.symantec.com. I'd heard mention of this source in a few conferences, but no one ever said where to find it. It's much more sophisticated and has greater scope than Dave's little ditty. -Ken- +++++++++++++++++++++++++++ >From arose@ATHENA.MIT.EDU (Alex Rosen) Date: 5 Jun 1994 17:30:33 GMT Organization: Massachusetts Institute of Technology [Confusion about copybits parameters] Here's a message I saved from Tim Dierks from quite a while ago, which explains it very cleary. --Alex In article , raffuj@aix.rpi.edu (Jose Raffucci) wrote: > > > I'm really curious about what parameters should actually passed to > copybits. IM V and think ref 1.0 say the first two should be address > of a pixmap or bitmap. The examples all show : > > CopyBits(&(GrafPtr)->portBits, ...); > > In IM VI however (21-19) it says that you can pass it the following: > > pixBase = GetGWorldPixMap(world); (pixbase is PixMapHandle) > CoypBits( *pixBase, ...); > > 1 worlds, and 2 doesn't. I looked and the addresses returned for 1&2 > are not the same. close, but not quite. I've played around with just about > every way toet the address of the pixmap for 2, and nothing works, and yes, > I locked my handles. > > Why the apparent inconsistency? CopyBits is definitely the wackiest call in the ToolBox. It can accept three different kinds of parameters for its "sourceBits" and "destBits" arguments: - A pointer to a BitMap - A pointer to a PixMap - A pointer to the spot in a CGrafPort where a BitMap is supposed to be if this port were actually a GrafPort It's got a little song and dance it does to figure out what it's getting, but that's not important. The weirdest thing is that you can pass in a pointer to a PixMap, which is the PixMapHandle dereferenced once. This PixMapHandle does not have to be locked; even though CopyBits can move memory, it won't do so until after it's figured out what kind of arguments it's getting and recovered the original handle, if necessary. I don't know if this will help you solve your problem, but it's certainly entertained me to tell you this. Tim Dierks absurd@apple.com I work for MacDTS, but I speak for myself. "If you can't lick 'em, put 'em on with a big piece of tape." - Negativland --------------------------- >From r4650001@nickel.laurentian.ca Subject: Gestalt, SU3.0 & List Manager Date: 4 Jun 94 16:36:53 -0500 Organization: Laurentian University Does anybody know if there is a Gestalt selector code to see if System Update 3.0 is installed? Specifically, I want to know if the new LDEF used by the StandardGetFile dialog box is available. (i.e. the one that puts an icon next to the item name.) Also, I would like to know what format the data should be in when I pass a handle to LSetCell(sic). E-mail is preferred, but if you post to the group, that's ok. --JA R4650001@nickel.laurentian.ca +++++++++++++++++++++++++++ >From wysocki@netcom.com (Chris Wysocki) Date: Sat, 4 Jun 1994 23:18:26 GMT Organization: Netcom Online Communications Services (408-241-9760 login: guest) In article <1994Jun4.163653.1@nickel.laurentian.ca> r4650001@nickel.laurentian.ca writes: >Does anybody know if there is a Gestalt selector code to see if System Update >3.0 is installed? Specifically, I want to know if the new LDEF used by the >StandardGetFile dialog box is available. (i.e. the one that puts an icon next >to the item name.) Call Gestalt with the "gestaltStandardFileAttr" ('stdf') selector and test the "gestaltStandardFileHasColorIcons" bit (2) in the response. >Also, I would like to know what format the data should be >in when I pass a handle to LSetCell(sic). I don't believe that the format of the data used by the Standard File LDEF has been documented. If this is in fact the case, I would recommend _not_ trying to reverse-engineer the format, as this is prone to breaking in the future. Instead, write your own LDEF that does what you want. LDEFs aren't very hard to write; I imagine that a reasonably competent Macintosh programmer could write such an LDEF in a few hours, if not less. Chris. +++++++++++++++++++++++++++ >From Alexander M. Rosenberg Date: Mon, 6 Jun 1994 02:14:33 GMT Organization: Hackers Anonymous In article Chris Wysocki, wysocki@netcom.com writes: > I don't believe that the format of the data used by the Standard File > LDEF has been documented. If this is in fact the case, I would > recommend _not_ trying to reverse-engineer the format, as this is > prone to breaking in the future. Instead, write your own LDEF that > does what you want. LDEFs aren't very hard to write; I imagine that a > reasonably competent Macintosh programmer could write such an LDEF in > a few hours, if not less. I agree with Chris. DO NOT REVERSE ENGINEER THE SYSTEM SOFTWARE AND USE THAT INFORMATION IN YOUR APPLICATIONS! WE WILL HUNT YOU DOWN AND KILL YOU. In this case, I was just speaking with the Software Mercenary responsible for including the Macintosh Easy Open version of Standard File in System Update 3.0. We were speaking of a way to increase the limit of items that can be displayed for a given directory. Doing so would specifically break people who "know" the format of the cell data. - ------------------------------------------------------------------------- - Alexander M. Rosenberg - INTERNET: alexr@apple.com - Yoyodyne - - 330 Waverley St., Apt B - UUCP:ucbvax!apple!alexr - Propulsion - - Palo Alto, CA 94301 - - Systems - - (415) 329-8463 - Nobody is my employer so - :-) - - - nobody cares what I say. - - --------------------------- >From mpcline@cats.ucsc.edu (Matthew Paul Cline) Subject: How to tell what kind of drive a volume is? Date: 2 Jun 1994 23:17:36 GMT Organization: University of California, Santa Cruz Is there any sort of system call that will tell you the type of a volume (flopyy driver, hard drive, or other)? Thanks in advance. -- Poodles have no honor. Have you hugged your shoggoth today? GE d? -p+ c++(+++) l++ u++ e+ m+ s/- n+(-) h+ f !g w+ t+ r y+ +++++++++++++++++++++++++++ >From mclow@coyote.csusm.edu (Marshall Clow) Date: 2 Jun 1994 16:59:01 -0700 Organization: California State University San Marcos Matthew Paul Cline (mpcline@cats.ucsc.edu) wrote: > Is there any sort of system call that will tell you the type >of a volume (flopyy driver, hard drive, or other)? Thanks in advance. Not in general, but you can infer a lot about a volume from looking at a few bits of information. 1) What driver talks to it? Is it '.Sony'? Then it's a floppy. 2) Is the driver in the range for SCSI devices? 3) Is the volume read-only? 4) Is the volume ejectable? 5) Is the volume "remote"? .. and so on. None of the information is conclusive, but you can figure out what you need to know >95% of the time. Marshall Clow Aladdin Systems mclow@san_marcos.csusm.edu +++++++++++++++++++++++++++ >From Jerry.Halstead@launchpad.unc.edu (jerry halstead) Date: 3 Jun 1994 00:45:39 GMT Organization: University of North Carolina Extended Bulletin Board Service reply to message from mpcline@cats.ucsc.edu: I got some help last week correlating between a vRefNum and the actual SCSI ID. I used PBHGetVInfo to get the refnum and the following formula to convert to a SCSI ID: HParamBlockRec volPB; volPB.volumeParam.ioVRefNum = 0; volPB.volumeParam.ioNamePtr = (StringPtr)name; volPB.volumeParam.ioVolIndex = i; // this is in a loop to get all drivers if (PBHGetVInfo(&volPB,FALSE) == noErr){ RefNum = abs(volPB.volumeParam.ioVDRefNum+1); scsiID = RefNum-32; } I then use the scsiID with the SCSI manager routines to obtain Inquiry data for the given drive, which includes, among other things, the device type. Here's the beginnings of the device type table from the SCSI spec: ____SCSI_Dev_types___ direct access (disk) 0 seq access (tape) 1 printer device 2 processor 3 worm 4 cd-rom 5 Of course this may not be the level of implementation you had in mind. Hope it helps. Big head Jerry and the demonstrables.... -- - ---------------------------------------------------------------------------- \ The above does not represent OIT, UNC-CH, laUNChpad, or its other users. / ------------------------------------------------------------------------ +++++++++++++++++++++++++++ >From blob@apple.com (Brian Bechtel) Date: 4 Jun 1994 07:00:36 -0700 Organization: Apple Computer, Inc., Cupertino, California mclow@coyote.csusm.edu (Marshall Clow) writes: >Matthew Paul Cline (mpcline@cats.ucsc.edu) wrote: >> Is there any sort of system call that will tell you the type >>of a volume (flopyy driver, hard drive, or other)? Thanks in advance. >Not in general, but you can infer a lot about a volume from looking >at a few bits of information. >1) What driver talks to it? Is it '.Sony'? Then it's a floppy. Or an HD 20. Or something which is trying to emulate either a floppy or an HD 20. (The HD 20 was the first Apple-labeled Macintosh hard drive. It did not use SCSI.) >2) Is the driver in the range for SCSI devices? With Asynchronous SCSI Manager 4.3, SCSI devices have can drivers outside the traditional range. >3) Is the volume read-only? >4) Is the volume ejectable? >5) Is the volume "remote"? >.. and so on. >None of the information is conclusive, but you can figure out what >you need to know >95% of the time. Yup. --Brian Bechtel blob@apple.com "My opinion, not Apple's" +++++++++++++++++++++++++++ >From dshayer@netcom.com (David Shayer) Date: Sun, 5 Jun 1994 22:36:37 GMT Organization: NETCOM On-line Communication Services (408 261-4700 guest) Brian Bechtel (blob@apple.com) wrote: : mclow@coyote.csusm.edu (Marshall Clow) writes: : >Matthew Paul Cline (mpcline@cats.ucsc.edu) wrote: : >> Is there any sort of system call that will tell you the type : >>of a volume (flopyy driver, hard drive, or other)? Thanks in advance. : >1) What driver talks to it? Is it '.Sony'? Then it's a floppy. : Or an HD 20. Or something which is trying to emulate either a floppy or : an HD 20. (The HD 20 was the first Apple-labeled Macintosh hard drive. : It did not use SCSI.) You can tell a floppy from an HD20 by driver refnum. The floppy driver has refnum -5, while the hd20 driver has refnum -2. +------------------------------------------------------------------------+ |David Shayer (415) 595-2523 | |Sentient Software / Symantec shayer@applelink.apple.com| |"Subvert the Dominant Paradigm." Applelink: SHAYER | +------------------------------------------------------------------------+ --------------------------- >From idowell@bbn.com (Ian Dowell) Subject: Photoshop Plug-in Filters useable with other programs? Date: 7 Jun 94 04:35:24 GMT Organization: Bolt, Beranek and Newman Inc. Are Photoshop Plug-in Filters useable with other programs? Is it possible to write a program which could use the filters to do transformations? Is there any documentation or example code available? Thanks in advance! Ian -- - ---------------------------------------------------------------------- Ian Dowell Bolt, Beranek & Newman, Cambridge, MA idowell@bbn.com (617) 873-2673 +++++++++++++++++++++++++++ >From tgaul@halcyon.com (Troy Gaul) Date: Mon, 06 Jun 1994 22:35:41 -0700 Organization: Infinity Systems In article , idowell@bbn.com (Ian Dowell) wrote: > Are Photoshop Plug-in Filters useable with other programs? > Is it possible to write a program which could use the filters > to do transformations? > Is there any documentation or example code available? Photoshop filters, in general, are usable by other programs. To write such a program, simply follow the interface given in the Adobe plug-in specification files (the same ones you need if you're writing plug-ins). You can find this specification in various places online, including from anonymous FTP at: ftp://export.acs.cmu.edu//pub/PSarch/misc-mac/PS2.5Developers_Kit.cpt.hqx The plug-ins _included_ with Photoshop, however, are not usable by other programs because of a passwording sceme they use to verify that they are talking to Photoshop. _troy //////// //////___Troy Gaul_________________________tgaul@halcyon.com__ // // // Infinity Systems ; Redmond, Washington // // // // "Insert witty quote here." // // //////________________________________________________________ // --------------------------- >From Ken Prehoda Subject: Scheduling Sleep in WaitNextEvent Date: 4 Jun 1994 02:54:55 GMT Organization: Univ of Wisc-Madison I have a number of questions concerning calling WaitNextEvent. First, it has been mentioned that WaitNextEvent should only be called about once a second (possibly when you aren't doing anything). What is the best way to accomplish this? Second, what is the best way to schedule the sleep parameter? I can envision four situations that may require different values for sleep: 1) I'm in the foreground and doing something. 2) I'm in the foreground and doing nothing. 3) I'm in the background doing something. 4) I'm in the background doing nothing. What are the best values in these situations? Thanks, Ken Prehoda kenp@nmrfam.wisc.edu +++++++++++++++++++++++++++ >From rmah@panix.com (Robert S. Mah) Date: Fri, 03 Jun 1994 23:38:47 -0500 Organization: One Step Beyond Ken Prehoda wrote: > I have a number of questions concerning calling WaitNextEvent. > > First, it has been mentioned that WaitNextEvent should only be called > about once a second (possibly when you aren't doing anything). What > is the best way to accomplish this? Not exactly. When people refered to fixed-time calling of WNE it was in the context of executing computationally intensive code and still giving time to other apps. IOW, being a nice coop multi-tasking app (NCMTA). When you're not doing anything that's computationally intensive, that is, you don't need idle time, just give the sleep value something really big. What will happen is that any time you're app gets a real event such as a mouse down or an update, WNE will return immediately after the event is posted (as long as the other apps are NCMTA's) so you can handle it. If you're app doesn't need to do anything (i.e. there are no events pending), then WNE won't bother returning until either 1) the sleepTime has passed or 2) none of the other apps need to do anything either. To sum up. The sleep parameter is a _suggestion_ to WNE about how much time you need between idle events. WNE may return before it has elapsed if the machine is not busy. It may return after it has elapsed if the machine is really busy. The fixed-timing technique for calling WNE is to assure your app gets a large timeslice when it is executing some critical and intensive code. Cheers, Rob ___________________________________________________________________________ Robert S. Mah -=- One Step Beyond -=- 212-947-6507 -=- rmah@panix.com +++++++++++++++++++++++++++ >From j-norstad@nwu.edu (John Norstad) Date: Fri, 03 Jun 1994 23:11:44 -0500 Organization: Northwestern University In article <2soqdv$jeu@news.doit.wisc.edu>, Ken Prehoda wrote: > I have a number of questions concerning calling WaitNextEvent. > > First, it has been mentioned that WaitNextEvent should > only be called about once a second (possibly when > you aren't doing anything). What is the best way to accomplish > this? > > Second, what is the best way to schedule the sleep > parameter? I can envision four situations that may > require different values for sleep: > > 1) I'm in the foreground and doing something. > > 2) I'm in the foreground and doing nothing. > > 3) I'm in the background doing something. > > 4) I'm in the background doing nothing. > > What are the best values in these situations? These are very good and very difficult questions, and not everyone agrees on the answers. (I just had a debate about this issue with Leonard Rosenthol today, in fact.) Here's what I do, in three different circumstances: (1) In my main event loop, when my program is idle, I call WNE with sleep = GetCaretTime(). This gives other non-idle processes plenty of time, and in the case where I'm in the foreground and my active window includes a text editing field, it keeps my caret blinking. I also pass a mouseRgn parameter to WNE in this call, to get woken up immediately if I'm in the foreground and the user moves the mouse and I need to adjust the cursor. (2) During CPU-intensive tasks, I call a "GiveTime" function periodically. This function calls WNE once every five ticks with sleep=0 and mouseRgn=nil. It handles at least update, activate, suspend, and resume events. It also checks for user cancel actions (Command-period, Escape, click on Cancel button in status window, or whatever). It also keep my animated cursor spinning. It's important to throttle your WNE calls in this case. Your GiveTime function should only call WNE every 4-6 ticks (Apple-recommended values). This avoids excessive process switching (thrashing), gives other CPU-intensive tasks plenty of time, makes the foreground process responsive to user actions when you are in the background, doesn't slow you down noticeable on an otherwise idle system, gives excellent response to user cancel operations, gives a smoothly animated cursor, and provides uniform behavior independent of CPU speed. It's a good balance. You mentioned only calling WNE once per second (60 ticks). That's way too long - you are really hogging the CPU. 5 ticks is much more appropriate. (3) When waiting for a network task to complete (e.g., during an asynchronous MacTCP send or receive call, while I'm polling the result code in the parameter block), I call WNE continuously with sleep=0 and mouseRgn=nil. The difference between (2) and (3) is that (3) doesn't throttle the WNE calls to every 5 ticks. This is because I have nothing to compute in this case, so I want to yield to other processes immediately to let them use the available CPU time while I'm waiting. I use the same GiveTime function as in (2), but I pass a parameter telling it to call WNE even if the 5 ticks hasn't expired. Notice that I don't do anything special when I'm in the background - the algorithm is the same. Some people use a non-zero sleep time when they're in the backgound doing CPU-intensive tasks. This slows you down quite a bit, even on an otherwise idle system, and I think it's wrong. The correct way to yield time to other processes when you are in the background is to make certain you call WNE at least every 5 ticks, not to use a non-zero sleep time. Indeed, this is always the correct way to yield time to other processes, and being in background or in the foreground really doesn't matter. As an example, here's my GiveTime function in NewsWatcher: /*---------------------------------------------------------------------------- GiveTime Give time to other processes during long operations and check for user cancels. Entry: waiting = true if waiting for MacTCP or something else. Exit: function result = error code (userCanceledErr if canceled by user, else noErr). - --------------------------------------------------------------------------*/ OSErr GiveTime (Boolean waiting) { EventRecord ev; Boolean gotEvt; static long nextTime = 0; if (!gLongOperation) { HiliteMenu(0); SpinCursor(0); ShowCursor(); gLongOperation = true; } if (TickCount() >= nextTime) { SpinCursor(16); nextTime = TickCount() + 5; waiting = true; } if (waiting) { gotEvt = WaitNextEvent(everyEvent, &ev, 0, nil); if (gotEvt) HandleEvent(&ev); } return gCancel ? userCanceledErr : noErr; } The "HandleEvent" function is the same event handling function called by my main event loop. "gCancel" is a global variable which is set to true by my event handlers when a user cancel event occurs. "gLongOperation" is a global variable which records whether I'm busy doing something or idle. Some of the event handlers need to know this information. I hope this is interesting and helps. -- John Norstad Academic Computing and Network Services Northwestern University j-norstad@nwu.edu +++++++++++++++++++++++++++ >From jumplong@aol.com (Jump Long) Date: 4 Jun 1994 23:42:05 -0400 Organization: America Online, Inc. (1-800-827-6364) In article , j-norstad@nwu.edu (John Norstad) writes: >(3) When waiting for a network task to complete (e.g., during an >asynchronous MacTCP send or receive call, while I'm polling the result >code in the parameter block), I call WNE continuously with sleep=0 and >mouseRgn=nil... If you're waiting for an asynchronous request to complete with a completion routine, then you can have the completion routine call WakeUpProcess using your application's process serial number. That way, you can give up more time to other processes and still have your application awaken when it needs to be awakened. - Jim Luther +++++++++++++++++++++++++++ >From j-norstad@nwu.edu (John Norstad) Date: Sun, 05 Jun 1994 08:48:16 -0500 Organization: Northwestern University In article <2srhid$572@search01.news.aol.com>, jumplong@aol.com (Jump Long) wrote: > If you're waiting for an asynchronous request to complete with a > completion routine, then you can have the completion routine call > WakeUpProcess using your application's process serial number. That > way, you can give up more time to other processes and still have your > application awaken when it needs to be awakened. But then you can't poll for user cancel events, which is very important when waiting for long network requests to complete. -- John Norstad Academic Computing and Network Services Northwestern University j-norstad@nwu.edu --------------------------- >From Paul Goyette Subject: What is "Clipping Extension"? Date: 5 Jun 1994 15:17:58 GMT Organization: (none) The title says it all - I've installed the Drag&Drop stuff, and when I reboot the Mac, I get a message that the Clipping Extension cannot be used because it is "too new". So, what is this Cliping Extension, and what version of what program do I need to be able to use it? - --------------------------------------------------------- Paul Goyette | PGP Public key available on request goyettep@ccnet.com | Fingerprint: 54 03 19 EE 99 57 FB 79 | 74 0A D0 E6 BE 84 0E DA - --------------------------------------------------------- +++++++++++++++++++++++++++ >From Richard Cardona Date: 5 Jun 1994 17:43:21 GMT Organization: UT-Austin In article <2ssqb6$apf@ccnet.ccnet.com> Paul Goyette, goyettep@ccnet.com writes: >So, what is this Cliping Extension, and what version of what program do I >need to >be able to use it? In System 7.0.x, you need to run Macintosh Drag and Drop and the clipping extension to have full clipping files support. What are clipping files? They are Drag and Drop data the finder can support and create files out of. Right now I believe the Finder only supports text, pictures and sound. Moovs are in the works. With the clipping extension, the finder can even open the clipping files and show you what they contain - neato! Example, highlight a piece of text from SimpleText and drag it over to the Finder, release it, and the Finder will create a text clipping file. You must have the clipping extension to do this. Similarly, a text clipping file can be dragged back into Simpletext and "pasted." In System 7.5,the clipping extension is useless and built in to the Finder, but you still need the Drag and Drop extension for now. I suggest you get a copy of both the Drag and Drop extension 1.1 and the Clipping extension from June's Developer CD. The documentation is also a little confusing, claiming you need Finder 7.1.3 also. (7 Pro's Finder is 7.1.4) But, I know this combo works together (at least on a Powermac). I don't have an on-line ftp site for the clipping extension, anyone? The WWDC contains the Drag and Drop extension for 7.5 I don't recommend this version for use without 7.5. Rick +++++++++++++++++++++++++++ >From Jens Alfke Date: Mon, 6 Jun 1994 20:29:54 GMT Organization: Apple Computer Paul Goyette, goyettep@ccnet.com writes: > So, what is this Cliping Extension, and what version of what program do I > need to > be able to use it? You need Finder 7.1.3 or 7.1.4. (7.1.4 is identical to 7.1.3 except for the size of a text field in the 'About This Mac' window, to support the PowerMacs.) Richard Cardona, rickc@mail.utexas.edu writes: > Right now I believe the Finder only supports text, pictures and > sound. Moovs are in the works. The Finder will make clipping files out of any kind of data an application can drop, and you can then take those clippings and drop them into another app. The only type limitations are what kinds of clippings the Finder can open up and display -- only text and pict, right now. > I suggest you get a copy of both the Drag and Drop extension 1.1 and the > Clipping extension from June's Developer CD. D&D 1.1 is also on the bookmark CD with 'develop' 18. This includes Finder 7.1.3. --Jens Alfke jens_alfke@powertalk Rebel girl, rebel girl, .apple.com Rebel girl you are the queen of my world --------------------------- >From valentin+@pitt.edu (Shawn V. Hernan) Subject: allocating memory quickly -- how? Date: 2 Jun 1994 20:28:04 GMT Organization: The University of Pittsburgh Greetings all, I want to allocate a large array (1000 elements) of pointers to characters the beginning of a program (it makes sense to do it this way in this case) . So, in a loop, I have code that looks like the following: array[i][j] = NewPtrClear(80); I have a similar Unix and VMS program that uses malloc in the same way I use NewPtr above. All three programs work pretty well, excpet that allocating the memory on the Macintosh is VERY SLOOOOOOW. Is there a faster way to allocate lots of little chunks of memory than NewPtr? malloc dies a cold death on the Mac, and I don't know why. I've looked through the faq's with no luck. Any help is deeply appreciated. Thanks, Shawn Shawn Valentine Hernan |Is the War on Drugs worth it? The University of Pittsburgh |Why does the government want your guns? valentin+@pitt.edu |Does RICO ring a bell? 412-624-6425 |Did you vote in the last election? +++++++++++++++++++++++++++ >From mgr@aggroup.aggroup.com (Mike Russell) Date: Thu, 02 Jun 1994 15:36:06 -0800 Organization: the ag group, inc. In article <2slfcl$78r@usenet.srv.cis.pitt.edu>, valentin+@pitt.edu (Shawn V. Hernan) wrote: > I want to allocate a large array (1000 elements) of pointers to > characters the beginning of a program (it makes sense to do it this way > array[i][j] = NewPtrClear(80); try allocating one giant block instead: char *p = NewPtrClear(80L * height * width); then in your loop array[i][j] = p + ((long)i * (long)j) * 80L; As for why - the reason goes back to the original tiny Mac that the Memory Manager was designed for. Call it a homage to history. +++++++++++++++++++++++++++ >From stk@uropax.contrib.de (Stefan Kurth) Date: 3 Jun 1994 04:06:01 +0200 Organization: Contributed Software GbR In article <2slfcl$78r@usenet.srv.cis.pitt.edu>, Shawn V. Hernan wrote: > that allocating the memory on the Macintosh is VERY SLOOOOOOW. Is there > a faster way to allocate lots of little chunks of memory than NewPtr? NewHandle might be a little bit faster than NewPtr, depending on how many relocatable blocks you have in your heap; however, I doubt that the difference will be very big. > malloc dies a cold death on the Mac, and I don't know why. What problems do you have with malloc? In the program that I'm currently writing, I have to deal with ten-thousands of very small blocks; at first I used handles for all of them, because, well, we're on a Mac, and "one uses" handles on a Mac. Later I have changed all the code to use malloc instead, and some portions of the program are now more than twice as fast (especially the routines that allocate lots of blocks). I'm not very happy about the fact that free() never releases the memory that has been allocated, but speed is more important for me than that (in this case at least - normally I don't use malloc in my programs). ________________________________________________________________________ Stefan Kurth Berlin, Germany stk@contrib.de +++++++++++++++++++++++++++ >From rang@winternet.com (Anton Rang) Date: 04 Jun 1994 23:45:19 GMT Organization: Minnesota Angsters In article coopem@panix.com (Marc Cooperman) writes: >In my limited experience in mac programming, I read somewhere that the Mac >memory manager was designed to manage a system with small memory (like 128K >- remember that). So basically any memory operation can cause the heap to >be compacted - the mac is trying to optimize memory utilization and >minimize fragmentation. This is true to some extent. If you use pointers much, you'll get quite a lot of memory shuffling, because the memory manager tries to keep all of the non-relocatable blocks together. If you use handles instead, and call MaxApplZone() at the beginning of your program, there won't be too much shuffling going on. I should also note that I got some information in the mail a couple of months ago from a company that makes a replacement for the whole malloc()/newptr()/newhandle() suite. I think it's called SmartHeap. Looked pretty interesting, for programs which need to do a *lot* of memory allocation. -- Anton Rang (rang@winternet.com) +++++++++++++++++++++++++++ >From shawn@greebe (shawn@mdli.com) Date: Mon, 6 Jun 1994 16:43:15 GMT Organization: HoloNet National Internet Access System: 510-704-1058/modem Shawn V. Hernan (valentin+@pitt.edu) wrote: > malloc dies a cold death on the Mac, and I don't know why. I've looked > through the faq's with no luck. Assuming that you are using Think C, the dead malloc may actually be a problem where you might be overrunning the limits of your allocated block. In Think C this can corrupt the next structure in such a way that is frequently locks up the machine at the next memory allocation call which tries to use this memory. Is it possible that you are trying to store 80 character strings in those character pointers ? The terminating null would them blow out the next allocation and cause just this sort of behavior. This is a long standing Think C behavior and lots of people have run into it, not really a bug (you are after all overrunning your allocation), but quite annoying. I agree with the original poster about allocation of a single large block and then assigning the addresses, this is often faster. Think actually uses a variation of this for malloc. Shawn Lavin (shawn@mdli.com) As always, my opinions are my own --------------------------- >From brandyn@apple.com (Brandyn Webb) Subject: sqrti() [Re: Faster Square Root Algorithm] Date: 27 May 1994 16:28:39 -0700 Organization: Apple Computer Inc, Cupertino, CA Here's the integer sqrt() code I use; it looks similar to some others posted, but may be a little faster (or slower; who knows). Hope someone finds it useful: #define iterate(e) \ y <<= 1; \ temp = (y|1)<<(2*e); \ if (temp <= X) { \ y |= 2; \ X -= temp; \ } unsigned sqrti(X) register unsigned X; { register unsigned yy, y, temp; y = 0; iterate(15); iterate(14); iterate(13); iterate(12); iterate(11); iterate(10); iterate(9); iterate(8); iterate(7); iterate(6); iterate(5); iterate(4); iterate(3); iterate(2); iterate(1); iterate(0); return y>>1; } -Brandyn (brandyn@brainstorm.com) +++++++++++++++++++++++++++ >From lakeland@mu.sans.vuw.ac.nz (Corrin Lakeland) Date: 6 Jun 1994 00:55:23 GMT Organization: SANS, Victoria University of Wellington, New Zealand. > [Another SQRT routine] I was just wondering, would it not be faster to set up a log table in memory and use that for calculating square roots. Depending on how much speed and or accuracy you need you could change the table (speed = greater range, accuricy = more choices). This should be very fast to look up if you are doing square roots extensivly - otherwise the memory use would make it not worth while. Disclaimer : I have not tested this meathod for speed, while it will work, it may turn out to be slower or use excessive amounts of ram. Corrin Lakeland (lakeland@mu.sans.vuw.ac.nz) +++++++++++++++++++++++++++ >From afcjlloyd@aol.com (AFC JLloyd) Date: 6 Jun 1994 02:51:02 -0400 Organization: America Online, Inc. (1-800-827-6364) In article <2sts5r$41e@st-james.comp.vuw.ac.nz>, lakeland@mu.sans.vuw.ac.nz (Corrin Lakeland) writes: >> [Another SQRT routine] > >I was just wondering, would it not be faster to set up a log table in >memory and use that for calculating square roots. Depending on how much >speed and or accuracy you need you could change the table (speed = >greater range, accuricy = more choices). This should be very fast to >look up if you are doing square roots extensivly - otherwise the memory >use would make it not worth while. > >Disclaimer : I have not tested this meathod for speed, while it will >work, it may turn out to be slower or use excessive amounts of ram. If you're willing to use a table lookup method, a technique that I have found to be very fast is to compute a table of square roots and use entries from it to seed Newton-Raphson. The trick is to estimate Log2(N) by finding the topmost set bit of N. Then use this estimate to "normalize" N into an index in the lookup table, lookup the value, and then "denormalize" the value back into the correct range. Once you have this estimate, you only need a very small number of iterations. For example, a table of 128 values provides initial seeds accurate enough to compute the square root of a 32-bit integer in just one iteration of Newton-Raphson. The same table can be used to do Fixed or Fract square roots in two iterations each. If a table of 128 values is too large then you can reduce the table down to 32 (maybe 16) entries and then do one more iteration of Newton-Raphson. Jim Lloyd afcjlloyd@aol.com --------------------------- End of C.S.M.P. Digest **********************