From: pottier@clipper.ens.fr (Francois Pottier) Subject: csmp-digest-v3-021 Date: Fri, 29 Apr 94 18:37:31 MET DST C.S.M.P. Digest Fri, 29 Apr 94 Volume 3 : Issue 21 Today's Topics: CW longjmp & destructor Complete File Directory Extensions-Patches w-PowerPC Help: SetEventMask, MacApp, Sub-launching Macintosh Disk Cache fix -- 25 times speedup PowerMac Programming & the data bus QuickDraw GX Questions Quitting faceless background applications 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 ueda@bug.co.jp (SHOJI UEDA) Subject: CW longjmp & destructor Date: Fri, 8 Apr 1994 12:57:45 GMT Organization: B.U.G. Inc. Hi, CodeWarrior users and Metrowerks guys I found a "longjmp & destructor" problem with CW 1.0a4 PPC/68K. Here is my test code. -- #include <Types.h> #include <setjmp.h> class CTest { public: long field; CTest(void); ~CTest(void); }; CTest::CTest(void) { field = 'CNST'; } CTest::~CTest(void) { field = 'DEST'; } class CTest2 { public: long field; CTest2(void); ~CTest2(void); }; CTest2::CTest2(void) { field = 'CNST'; } CTest2::~CTest2(void) { field = 'DEST'; } jmp_buf env; void Func(void) { CTest ctest; ctest.field = 'FUNC'; longjmp(env, 1); } void main(void) { CTest2 ctest2; ctest2.field = 'MAIN'; DebugStr("\pSTARTED"); if (setjmp(env) == 0) { Func(); DebugStr("\pSUCCEEDED"); } else DebugStr("\pFAILED"); DebugStr("\pEND"); } - - This code will cause crash. This is because ctest defined in Func() already was removed from stack frame but its destructor called. I tested this code with MPW CFront. CFront never call removed obejct's destructor. I don't understand removed object's destructor should be called or not. But MacApp3.1 failure mechanism uses longjmp() and destructor. Thanks, +++++++++++++++++++++++++++ >From Jens Alfke <jens_alfke@powertalk.apple.com> Date: Tue, 12 Apr 1994 20:11:04 GMT Organization: Apple Computer SHOJI UEDA, ueda@bug.co.jp writes: > This code will cause crash. This is because ctest defined in Func() already > was removed from stack frame but its destructor called. Something's wrong here. longjmp() does NOT call destructors of local variables. I've been using setjmp/longjmp in an exception library of my own with no problems, and PowerPlant also uses them. Take a look at the disassembly of your code and see what's happening around the call to longjmp... --Jens Alfke jens_alfke@powertalk Rebel girl, rebel girl, .apple.com Rebel girl you are the queen of my world +++++++++++++++++++++++++++ >From dpodwall@world.std.com (Dan Podwall) Date: Wed, 13 Apr 1994 16:36:43 GMT Organization: Metrowerks, Inc. SHOJI UEDA (ueda@bug.co.jp) wrote: : Hi, CodeWarrior users and Metrowerks guys : I found a "longjmp & destructor" problem with CW 1.0a4 PPC/68K. : Here is my test code. As you know, longjmp doesn't call destructors for objects in the stack frames that it pops. But there is a bug in the C++ runtime that causes it to get confused and try to destroy objects that were in frames that were popped by a longjmp. This will be fixed in DR3. I'm not sure if this is something that we can make an interim fix for or not. Dan Podwall Metrowerks, Inc. +++++++++++++++++++++++++++ >From johnmce@world.std.com (John McEnerney) Date: Thu, 14 Apr 1994 02:17:55 GMT Organization: The World Public Access UNIX, Brookline, MA Jens Alfke <jens_alfke@powertalk.apple.com> writes: >SHOJI UEDA, ueda@bug.co.jp writes: >> This code will cause crash. This is because ctest defined in Func() already >> was removed from stack frame but its destructor called. >Something's wrong here. longjmp() does NOT call destructors of local >variables. I've been using setjmp/longjmp in an exception library of my own >with no problems, and PowerPlant also uses them. This is actually a bug in CodeWarrior. The way the destruction of local objects is implemented it is possible for the destructors to be called if you exit the routine froma longjmp(). It will be fixed in DR3. -- John McEnerney, Metrowerks PowerPC Product Architect --------------------------- >From cowcorp@cairo.anu.edu.au (Matt Gallagher) Subject: Complete File Directory Date: 8 Apr 1994 03:52:46 GMT Organization: Australian National University I need to get a complete directory listing of an HFS volume in Think C 5.0.4. I've tried recursively calling PBGetCatInfo, but this is ridiculously slow on my 500mb hard drive. Does anyone have any tips on how to do this more quickly? Thanks in advance, Matt Gallagher cowcorp@cairo.anu.edu.au +++++++++++++++++++++++++++ >From Scott_Gruby@hmc.edu (Scott Gruby) Date: 8 Apr 1994 04:19:53 GMT Organization: Harvey Mudd College, Claremont CA In article <cowcorp-080494135647@150.203.60.160>, cowcorp@cairo.anu.edu.au (Matt Gallagher) wrote: > I need to get a complete directory listing of an HFS volume in Think C > 5.0.4. > I've tried recursively calling PBGetCatInfo, but this is ridiculously slow > on my 500mb hard drive. Does anyone have any tips on how to do this more > quickly? > > Thanks in advance, > Matt Gallagher > cowcorp@cairo.anu.edu.au Sorry I can't answer this question, but on a similar note, what is the easiest way to list all files in a directory...as fast as possible would be great, but not necessary? Thanks. -- Scott Allen Gruby (Scott_Gruby@hmc.edu) Macintosh Student System Manager Academic Computing, Harvey Mudd College Claremont, CA Finger ripem_public@eagle.st.hmc.edu for public key +++++++++++++++++++++++++++ >From jumplong@aol.com (Jump Long) Date: 9 Apr 1994 13:17:02 -0400 Organization: America Online, Inc. (1-800-827-6364) In article <cowcorp-080494135647@150.203.60.160>, cowcorp@cairo.anu.edu.au (Matt Gallagher) writes: > I need to get a complete directory listing of an HFS volume in Think C > 5.0.4. There are only a couple of methods you can use. If you want the directory struture (you want to know what files and subdirectories are in a directory), you'll have to use PBGetCatInfo (as you said you've already tried). I haven't tried this to find out if it makes any difference but... the Macintosh file system keeps a catalog hint when PBGetCatInfo is used with a positive index. That means that if you index through a directory using 1, 2, 3, 4..., the file system can find the next sequential directory entry a little faster. So, you might get a little better performance if you index through a complete directory level before dropping down a level to index through its subdirectories. I don't know because I haven't tried it. (This would be harder to code, though.) If you don't need the directory structure and only need a list of all of the objects (files and directories) on the volume, you can use PBCatSearch to get fill an array of FSSpecs. This will be a lot faster on local HFS hard disks but will probably be slower than the recursive search if the volume is an AppleShare volume. (I tested this when writing the Technical Note "Searching Volumes-Solutions and Problems" and found that the search time for finding all files and directories on a Developer CD was around 18 seconds with PBCatSearch. It took 6 minutes and 36 seconds with a recursive indexed search.) - Jim Luther +++++++++++++++++++++++++++ >From blob@apple.com (Brian Bechtel) Date: 14 Apr 1994 21:36:28 -0700 Organization: Apple Computer, Inc., Cupertino, California Scott_Gruby@hmc.edu (Scott Gruby) writes: >In article <cowcorp-080494135647@150.203.60.160>, cowcorp@cairo.anu.edu.au >(Matt Gallagher) wrote: >> I need to get a complete directory listing of an HFS volume in Think C >> 5.0.4. >> I've tried recursively calling PBGetCatInfo, but this is ridiculously slow >> on my 500mb hard drive. Does anyone have any tips on how to do this more >> quickly? >Sorry I can't answer this question, but on a similar note, what is the >easiest way to list all files in a directory...as fast as possible would be >great, but not necessary? MoreFiles. MoreFiles. MoreFiles. MoreFiles is an excellent collection of file manager sample code by Jim Luther of DTS. It's available from ftp://ftp.apple.com/dts/mac/sc/morefiles.1.1.1.hqx It has complete, working code which does both of the requested items above. --Brian Bechtel blob@apple.com "My opinion, not Apple's" --------------------------- >From gdl@stlawrence.maths (Greg Landweber) Subject: Extensions-Patches w-PowerPC Date: 09 Apr 1994 16:26:51 GMT Organization: (none) If I load and prepare a PowerPC code fragment from an INIT (using GetDiskFragment or loading it from a resource and calling GetMemFragment), will it be unloaded when my INIT exits? I want the fragment to persist until the Mac is shut down, as if I had loaded and detached a 680x0 code resource in the system heap. Basically, I have a code fragment containing a number of trap patches. The entry point is the routine that installs the trap patches and a Gestalt Selector routine also within the code fragment. Thanks for your help. -- Greg "Buttons" Landweber gdl@maths.ox.ac.uk +++++++++++++++++++++++++++ >From A.Lillich@AppleLink.Apple.com (Alan Lillich) Date: Mon, 11 Apr 1994 23:38:37 GMT Organization: Apple Computer, Inc. In article <GDL.94Apr9172652@stlawrence.maths>, gdl@stlawrence.maths (Greg Landweber) wrote: > > If I load and prepare a PowerPC code fragment from an INIT (using > GetDiskFragment or loading it from a resource and calling > GetMemFragment), will it be unloaded when my INIT exits? I want the > fragment to persist until the Mac is shut down, as if I had loaded and > detached a 680x0 code resource in the system heap. > > Basically, I have a code fragment containing a number of trap patches. > The entry point is the routine that installs the trap patches and a > Gestalt Selector routine also within the code fragment. > > Thanks for your help. > > -- Greg "Buttons" Landweber > gdl@maths.ox.ac.uk What you suggest works just fine. I would suggest using the fragment's init routine to install the patches, then your init just has to call GetDiskFragment and make sure there is no error. Note: If VM is on GetDiskFragment will use file mapping on the data fork. This may or may not be desirable, i.e. is your code only used at times when page faults are safe? Alan Lillich. +++++++++++++++++++++++++++ >From wdh@netcom.com (Bill Hofmann) Date: Tue, 12 Apr 1994 01:55:49 GMT Organization: NETCOM On-line Communication Services (408 241-9760 guest) gdl@stlawrence.maths (Greg Landweber) writes: >If I load and prepare a PowerPC code fragment from an INIT (using >GetDiskFragment or loading it from a resource and calling >GetMemFragment), will it be unloaded when my INIT exits? I want the >fragment to persist until the Mac is shut down, as if I had loaded and >detached a 680x0 code resource in the system heap. Once a fragment is loaded (at INIT time), it's open forever. Of course, if you load a fragment from a resource, you had best DetachResource... >Basically, I have a code fragment containing a number of trap patches. >The entry point is the routine that installs the trap patches and a >Gestalt Selector routine also within the code fragment. Yup, that'll work. If you want to install fat patches, **as you should** most of the time, your entry point should instead be a routine which returns addresses of patches and takes old trap addresses, since you'll need to build a fat routine descriptor for each patch, and to do that, you need to also have a 680x0 version. It's kind of an ugly mess, which can be archtected nicely with some effort. If your patch is big enough that a mixed mode switch is worthwhile (> a few hundred anyway, probably a few thousand) lines of compiled code, then you can just patch native, and try this: make your initialization routine do the initing and patching, and you don't have to do anything but load the fragment: the init routine gets called automatically! It's quite easy to do. >Thanks for your help. >-- Greg "Buttons" Landweber > gdl@maths.ox.ac.uk No problem. -- -Bill Hofmann wdh@netcom.COM Fresh Software and Instructional Design +1 510 524 0852 +++++++++++++++++++++++++++ >From leonardr@netcom.com (Leonard Rosenthol) Date: Tue, 12 Apr 1994 18:36:58 GMT Organization: Aladdin Systems, Inc. In article <wdhCo4Ip3.CEz@netcom.com>, wdh@netcom.com (Bill Hofmann) wrote: > gdl@stlawrence.maths (Greg Landweber) writes: > >If I load and prepare a PowerPC code fragment from an INIT (using > >GetDiskFragment or loading it from a resource and calling > >GetMemFragment), will it be unloaded when my INIT exits? I want the > >fragment to persist until the Mac is shut down, as if I had loaded and > >detached a 680x0 code resource in the system heap. > > Once a fragment is loaded (at INIT time), it's open forever. Of course, > if you load a fragment from a resource, you had best DetachResource... > True, it is open forever (well, assuming the file doesn't get closed ;) - HOWEVER the connection ID that you get back from GetMemFragment/GetDiskFragment is _PROCESS_ relative so that in order to use the fragment in multiple processes/application you have to either reload the fragment each time OR precompute and store the entry points at startup. Leonard - ------------------------------------------------------------------------ Leonard Rosenthol Internet: leonardr@netcom.com Director of Advanced Technology AppleLink: MACgician Aladdin Systems, Inc. GEnie: MACgician +++++++++++++++++++++++++++ >From zobkiw@datawatch.com (joe zobkiw) Date: Wed, 13 Apr 1994 12:26:38 GMT Organization: Datawatch Corporation In article <leonardr-120494103658@leonardr.slip.netcom.com>, leonardr@netcom.com (Leonard Rosenthol) wrote: > In article <wdhCo4Ip3.CEz@netcom.com>, wdh@netcom.com (Bill Hofmann) wrote: > > > gdl@stlawrence.maths (Greg Landweber) writes: > > >If I load and prepare a PowerPC code fragment from an INIT (using > > >GetDiskFragment or loading it from a resource and calling > > >GetMemFragment), will it be unloaded when my INIT exits? I want the > > >fragment to persist until the Mac is shut down, as if I had loaded and > > >detached a 680x0 code resource in the system heap. > > > > Once a fragment is loaded (at INIT time), it's open forever. Of course, > > if you load a fragment from a resource, you had best DetachResource... > > > True, it is open forever (well, assuming the file doesn't get closed ;) > - HOWEVER the connection ID that you get back from > GetMemFragment/GetDiskFragment is _PROCESS_ relative so that in order to > use the fragment in multiple processes/application you have to either > reload the fragment each time OR precompute and store the entry points at > startup. > >> reload the fragment each time OR precompute and store the entry points This sounds a bit confusing but...I load numerous fragments at startup (via an INIT), and call them all throughout the time the machine is on. Simply GetResource, DetachResource, GetMemFragment, and go...it works fine. ___________________________________________________________ _/_/_/_/ Joe Zobkiw ,,, _/ Senior Software Engineer - - _/ Datawatch Corporation L _/_/_/_/ zobkiw@datawatch.com - +++++++++++++++++++++++++++ >From wdh@netcom.com (Bill Hofmann) Date: Thu, 14 Apr 1994 00:35:40 GMT Organization: NETCOM On-line Communication Services (408 241-9760 guest) zobkiw@datawatch.com (joe zobkiw) writes: ... >>> reload the fragment each time OR precompute and store the entry points >This sounds a bit confusing but...I load numerous fragments at startup (via >an INIT), and call them all throughout the time the machine is on. Simply >GetResource, DetachResource, GetMemFragment, and go...it works fine. Yes, Leonard, Joe's right. I've done it too. You don't have to worry about the process-relative nature because, of course, you're in the system context at INIT time. But your general comment is well-taken. -- -Bill Hofmann wdh@netcom.COM Fresh Software and Instructional Design +1 510 524 0852 +++++++++++++++++++++++++++ >From zobkiw@datawatch.com (joe zobkiw) Date: Thu, 14 Apr 1994 12:21:47 GMT Organization: Datawatch Corporation In article <wdhCo84BG.4HH@netcom.com>, wdh@netcom.com (Bill Hofmann) wrote: > zobkiw@datawatch.com (joe zobkiw) writes: > ... > >>> reload the fragment each time OR precompute and store the entry points > > >This sounds a bit confusing but...I load numerous fragments at startup (via > >an INIT), and call them all throughout the time the machine is on. Simply > >GetResource, DetachResource, GetMemFragment, and go...it works fine. > > Yes, Leonard, Joe's right. I've done it too. You don't have to worry > about the process-relative nature because, of course, you're in the system > context at INIT time. But your general comment is well-taken. > Leonard responded to me: "That's because your code has a SINGLE entry point and you built it with a MixedMode Header on the resource. If you DON'T do that, and you resolve (FindSymbol) at runtime, the connection ID's are not valid across processes." Now, he is right, I have a single entry point. Maybe there is more to it with multiple entry points. I don't know since I've not had to deal with that yet. ___________________________________________________________ _/_/_/_/ Joe Zobkiw ,,, _/ Senior Software Engineer - - _/ Datawatch Corporation L _/_/_/_/ zobkiw@datawatch.com - +++++++++++++++++++++++++++ >From leonardr@netcom.com (Leonard Rosenthol) Date: Thu, 14 Apr 1994 19:01:42 GMT Organization: Aladdin Systems, Inc. In article <wdhCo84BG.4HH@netcom.com>, wdh@netcom.com (Bill Hofmann) wrote: > zobkiw@datawatch.com (joe zobkiw) writes: > ... > >>> reload the fragment each time OR precompute and store the entry points > > >This sounds a bit confusing but...I load numerous fragments at startup (via > >an INIT), and call them all throughout the time the machine is on. Simply > >GetResource, DetachResource, GetMemFragment, and go...it works fine. > > Yes, Leonard, Joe's right. I've done it too. You don't have to worry > about the process-relative nature because, of course, you're in the system > context at INIT time. But your general comment is well-taken. > Depends on whether you build a mixed mode header on the resource itself and whether you have one or multiple entry points. If the former situation (single entry point, with no callbacks, and built with an MM header), then you are correct - you can load and call and be just fine. BUT if you have a code frag with multiple entry points and you need to call FindSymbol, then the results are only relative to the process - you need the correct connectionID for the process or FindSymbol will fail :( Leonard - ------------------------------------------------------------------------ Leonard Rosenthol Internet: leonardr@netcom.com Director of Advanced Technology AppleLink: MACgician Aladdin Systems, Inc. GEnie: MACgician --------------------------- >From steve.herman%express@freedom.msfc.nasa.gov (Steve Herman) Subject: Help: SetEventMask, MacApp, Sub-launching Date: Wed, 13 Apr 1994 12:48:37 -0500 Organization: BCSS MacApp 3.0.1(bullet) calls SetEventMask in it's DoRealInitToolBox() function to set SysEvtMask to everyEvent (0xFFFF). According to Inside Mac the normal value of SysEvtMask is 0xFFEF which masks out keyUp events. Where I have seen a problem is when I sub-launch applications from a MacApp application. It appears that sub-launched applications "inherit" the value of SysEvtMask from the application which launched them. Can anyone confirm that this is true??? Does anyone know just how/when a *sub-launched* application's low memory globals get initialized? In my MacApp program I tried setting SysEvtMask to 0xFFEF, calling LaunchApplication() and then putting it back to 0xFFFF (to keep MacApp happy). But the sub-launched application still showed 0xFFFF after it launched. Do I perhaps need to leave my SysEvtMask set at 0xFFEF until WaitNextEvent has been called a few times and the sub-launch has *really* taken place???? If I set SysEvtMask back to 0xFFEF in my MacApp application (and leave it that way) am I asking for trouble (I briefly searched through the source and didn't see anything obvious which MacApp was doing with keyUps)? Despite all the documentation I've been able to find which states that apps which modify SysEvtMask should save it's previous value and then restore it before quitting, I can't find any indication that MacApp does this. As far as I can tell, however, this doesn't seem to cause a problem. The reason I brought all this up is that we use an apparently "brain-dead" off the shelf product which I need to sub-launch AND which seems to get confused when it has to deal with keyUp events. Thanks for any insight... Steve - -------------------------------------------------- - Steve Herman - BCSS - Boeing Computer Support Services - Huntsville, AL - -------------------------------------------------- +++++++++++++++++++++++++++ >From jonpugh@netcom.com (Jon Pugh) Date: Thu, 14 Apr 1994 07:10:56 GMT Organization: NETCOM On-line Communication Services (408 241-9760 guest) Steve Herman (steve.herman%express@freedom.msfc.nasa.gov) wrote: > MacApp 3.0.1(bullet) calls SetEventMask in it's DoRealInitToolBox() > function to set SysEvtMask to everyEvent (0xFFFF). According to Inside Mac > the normal value of SysEvtMask is 0xFFEF which masks out keyUp events. > Where I have seen a problem is when I sub-launch applications from a MacApp > application. It appears that sub-launched applications "inherit" the value > of SysEvtMask from the application which launched them. Can anyone confirm > that this is true??? Yes, I've dealt with this before and it is true. You've nailed it. I suspect your fix will work too, but I'll bet you've tried and know if it will work by now. I solved it by making the sublaunched application fix its event mask, which isn't an option for you apparently. > If I set SysEvtMask back to 0xFFEF in my MacApp application (and leave it > that way) am I asking for trouble (I briefly searched through the source > and didn't see anything obvious which MacApp was doing with keyUps)? You simply won't get keyUp method calls, but since you probably don't use them, it won't matter if you turn them off. Jon --------------------------- >From Stuart Cheshire <cheshire@cs.stanford.edu> Subject: Macintosh Disk Cache fix -- 25 times speedup Date: 9 Apr 1994 17:25:44 GMT Organization: Stanford University Here's a message I posted on Thursday to the Nuntius mailing list: - ---------------------------------------------------------------- Has anyone else noticed that at the end of extracting a binary in Nuntius the disk light comes on, stays on for a few seconds, and freezes the Mac for that duration? It gets unbearable if you have a large disk cache, but even with only a 256K cache it can freeze the Mac for up to 5 seconds. This is not the fault of Nuntius -- many other programs like BinHex decoders, uudecoders, archive expanders etc. seem to suffer the same problem. This really annoys me. One of the good features of Nuntius is the way it lets you continue working while it is doing other things in the background, so having it freeze like this is particularly galling. The problem is that Nuntius (and other programs) write their data to disk in chunks (say 4K each) and the Mac caches the blocks in its disk cache. When the file is closed the data is finally written to disk, and this is what causes the big freeze up. It would be much better if the data were written continually to disk, instead of in one big burst at the end. Yesterday morning I wrote a little INIT which sets the File Manager "don't cache" bit for disk writes of 1K or more. It does this by installing the following patch on the _Write system call: tst.w IOParam.ioRefNum(a0) ; Is this a file write? bmi.s @sys_write cmp.l #1024, IOParam.ioReqCount(a0); Is it at leask 1K? blo.s @sys_write ori.w #0x20, IOParam.ioPosMode(a0) ; Set "Don't cache" bit extern sys_write:jmp 0x12345678 ; Resume the system call One surprising artifact of this is that it not only amortises the disk time over all the writes, but it also makes it 25 times faster. What? Yes, it's true. I set my disk cache to 768K, and wrote a test program which wrote to a file in 32 blocks of 16K each, making a total of 512K. Without the INIT, the writes took almost no time, but the Close call took 11 seconds, averaging about 45K/second write rate. With the INIT, the whole thing took under half a second, averaging over a megabyte per second. Go figure. This may not make much difference to people connecting over modem, but for people on Ethernet it makes a huge difference. The INIT is below, in BinHex form. Decode it, install it, and let me know what you think. It has no ICON, because the total size of the INIT (including balloon help) is just under 1K, and it seemed a pity to spoil that with a big fat colour icon. (Besides, I couldn't be bothered to draw one.) - ---------------------------------------------------------------- Here is one reply I got, which proves I wasn't hallucinating: >> From: joanna@mail.utexas.edu (Joanna L. Castillo) >> Subject: Re: Long Mac freezes with Nuntius (and other program) >> >> Hi, Stuart - >> >> >Yesterday morning I wrote a little INIT [ ... ] >> >> Wow! I installed the INIT... I tried copying a folder that had several >> files and sub-folders (a little over 900K total) to a floppy. With the >> INIT installed, it took about 30 seconds. Without, it took 2 minutes. >> Thank you so much. >> >> Joanna. >> >> FYI: I'm running a Mac IIci, 24MB RAM, cache card, ethernet, tuned >> 7.0.1 system, several inits, and disk cache set at 512K. I'll post the source code for the INIT, and the test program, to a separate thread. This INIT itself is below. Stuart Cheshire <cheshire@cs.stanford.edu> * <A HREF="file://brubeck.stanford.edu/www/cheshire-bio.html">WWW</A> * Stanford Distributed Systems Group Research Assistant * Escondido Village Resident Computer Coordinator * Macintosh Programmer (This file must be converted with BinHex 4.0) :$&GbDA4P9'KbEh9RD!"*6NP89h*8D!!!!!!!!!!!!rJBk3!!!!!"!!!!!i8!!!+ &!!!!F`!)6Ud!3Le!!!`-J!#!!!"M"(!!B%)-VJ!!1TJ!$'3S$&GbDA4P9'KbEh9 RD&S#!!!!58j*9&Gb9'J"!2rrrrm!!%P1594AFP4S!3$rrrrr!!!!!!!!!!!!!!! !!!!!!!!!UFK3'J!!!!!!!!2i!)!!!'-'F!"J!!$L)!aQ$#m(6VVr(PL2B!!!dNU (CJi[$%kk!0"BMh!!B!!!`!J(!!"R!P+()%a`!$!J4N"Q!U!K9B!X!,b(Ba3U"`b '!!!kQ'8Q$)F!!$UBCA"JBVb(C"3U"Jb'!!!kQ'48$)F!!$UBC&KJ'#!-B()J6$) J)!D3!)F!!!%H,``[#+Q53IVrq#K)B3!!a#KI6R9+D!!BDa!-U!!!"!!!*'8'!'J !)!!X6[N50&Ci6R919[rm51F(!#`Z!!JZ"J+(!!!)!%U(C`4`!@!#F!!D!%U(Cd! Z2!!!"!"#Tbmm!3#SENkk!*`YArrm3UF[2!%!UQj1ZJ#-)#lrr,#ICJBZ2!!!!J! #KJ!!"rqqKQ)',$`!!+LI3UFr"Km&6VS!C#eIrra#Tbmm!3#SRdkk!&3J,[rmX*p @`%3!60m!i%jH6R@09(*KF%&fB@PXB@*XC3!!,`Y(q[p@-$bJ!k0'*SK"q[mb-$b J!k*(,c`!!+'B6VVr3%S!@)pR"%kk!"SQAdje)Pm5(c!I5J&R"+G'B!+M4Lk)6Y% LAh!"SCK1d3!!!2B!!J!!!!!!!!!!!!%!kJ!"j&4SC5"AFQPdC94SFQpeCfJJ4AK dC@jcD@pZ)'*jF'&cFf9c)(4SC5"6HA0dC@h9Fb"MEh"j,@*KBfXJC'PcDb"MB@0 SC5"QEh)JB@aX)(GbDA4PFb"dEb"NDA0V)'pQ)$&,)'pb)'GbC@&dCA)Z)%pZ)'e j)&&eB@4bB5!h-$!X)(GTG'JJB5"NDA0V)'0KBfKP)'pQ)$-i0%XX)(4SDA-JE@& VCA-JBf9bG'&TEL"KF("XD@0KG'P[ER-J-M8JG'PYCA-JCQ&cG'9b)(GSC@iJG'K PH5"hFQPdC5"dEb"NDA0V,J!!!!!E!3#!!!!!!c%Z-""AFQPdC94SFQpeCfJJ-5i `!!!!4J%!J!!!!!-a,M!lU5!fG'JJ3A"bD@`J-6Nj0#"6G(9KFR3J3fKPFfKTFQ8 J2'0SCA0SDA*P3'0c,R0dB@jQEh*N,Q9NG6i!!!%!!!!$K3!!!S8!!!"c!*@8'!Y N!!!!(!"Q!!**6NP8!!!!'QKQC()!!!!QGQ9bF`!"!$)!!!!!8!!!!!!!!!$T`2r r!!!")J!!!!!!![rr!!!#(!#9NM3!!Irr!!!#1`#9Nf`-9h*TG'98D(*[G@GS-U) : +++++++++++++++++++++++++++ >From rbauchsp@herbie.unl.edu (ROGER BAUCHSPIES) Date: 9 Apr 1994 21:26:54 GMT Organization: University of Nebraska--Lincoln Stuart Cheshire (cheshire@cs.stanford.edu) wrote: : Here's a message I posted on Thursday to the Nuntius mailing list: : ------------------------------------------------------------------ : Has anyone else noticed that at the end of extracting a binary in : Nuntius the disk light comes on, stays on for a few seconds, and : freezes the Mac for that duration? It gets unbearable if you have : a large disk cache, but even with only a 256K cache it can freeze : the Mac for up to 5 seconds. This is due to the design of the cache, which always writes cached blocks in 512 byte pieces, regardless of how large they were when they cache grabbed them. I am writing a highly intelligent disk cache and will be releasing it later this year. Depending on the marketplace at that time, I may release both the source code and object code as public domain. Steve Kiene MindVision Software +++++++++++++++++++++++++++ >From Cameron Esfahani <dirty@guest.apple.com> Date: Sun, 10 Apr 1994 05:27:14 GMT Organization: Apple Computer, Inc. In article <2o6oeo$8te@nntp2.Stanford.EDU> Stuart Cheshire, cheshire@cs.stanford.edu writes: > Has anyone else noticed that at the end of extracting a binary in > Nuntius the disk light comes on, stays on for a few seconds, and > freezes the Mac for that duration? It gets unbearable if you have > a large disk cache, but even with only a 256K cache it can freeze > the Mac for up to 5 seconds. There is a perfectly logical explanation of why the disk cache sucks so bad in cases like this. If the disk cache gets flushed, and there are a large number of dirty blocks in there, each block gets written out 1 at a time. This means if you have a 1Meg cache and it has 256K dirty, then you will write out 512 blocks to disk. Even if you have a fast drive this takes a little time. This gives me a chance to evangelize the use of the 'noCacheBit' which is defined in SysEqu.a. This tells the file system to not cache this transaction. Please use this bit if you know you are not going to use the information that you are reading or writing again. If you don't, the file system has to try to read your mind, and we all know how successfully that works. Another way to speed up your usage of the file system is to never, ever use the newline mode in reading from a file. The file system has to read data from the file 1 byte at a time. This is slow. If you want to simulate this, read from the file in large (>4K) chunks and search through it yourself. This leads me into my next tip: read and write in large chunks. It really is much more efficient to read and write in >4K chunks and pull your data out of there yourself. With these few tips, you can increase your enjoyment of the Mac file system. Cameron Esfahani dirty@apple.com General File-System Dude +++++++++++++++++++++++++++ >From d88-jwa@mumrik.nada.kth.se (Jon Wätte) Date: 10 Apr 1994 11:11:08 GMT Organization: The Royal Institute of Technology In <2o6oeo$8te@nntp2.Stanford.EDU> Stuart Cheshire <cheshire@cs.stanford.edu> writes: >Yesterday morning I wrote a little INIT which sets the File Manager >"don't cache" bit for disk writes of 1K or more. It does this by >installing the following patch on the _Write system call: This has long been needed. >Without the INIT, the writes took almost no time, but the Close call >took 11 seconds, averaging about 45K/second write rate. >With the INIT, the whole thing took under half a second, averaging >over a megabyte per second. >Go figure. That's because the disk cache flushes itself in 512 byte blocks. Yes, that's right, at this day and age, the disk cache still iterates over its 512 byte blocks, writing ONE AT A TIME. However, the next major system software release will have FINALLY fixed this problem. Yay! So your INIT should maybe check to see that the system version is < 7.2 or something? Cheers, / h+ -- -- Jon W{tte, h+@nada.kth.se, Mac Hacker Deluxe -- Not speaking for IBM. +++++++++++++++++++++++++++ >From Stuart Cheshire <cheshire@cs.stanford.edu> Date: 10 Apr 1994 19:14:06 GMT Organization: Stanford University In article <2o8msc$ro6@news.kth.se> Jon W!tte, d88-jwa@mumrik.nada.kth.se writes: >However, the next major system software release will have >FINALLY fixed this problem. Yay! So your INIT should maybe >check to see that the system version is < 7.2 or something? Hey, the INIT is <1K. This is not a major software development. This is simply the result of waking up at 6:00am due to getting drunk the night before. Don't install it if it's not appropriate for your system. Stuart Cheshire <cheshire@cs.stanford.edu> * <A HREF="file://brubeck.stanford.edu/www/cheshire-bio.html">WWW</A> * Stanford Distributed Systems Group Research Assistant * Escondido Village Resident Computer Coordinator * Macintosh Programmer +++++++++++++++++++++++++++ >From philip@cs.wits.ac.za (Philip Machanick) Date: Mon, 11 Apr 1994 14:13:39 +0200 Organization: Computer Science Dept, U of Witwatersrand In article <2o9j5u$nt@nntp2.Stanford.EDU>, Stuart Cheshire <cheshire@cs.stanford.edu> wrote: > Hey, the INIT is <1K. This is not a major software development. This is > simply the result of waking up at 6:00am due to getting drunk the night > before. Don't install it if it's not appropriate for your system. Clearly still having fun. I may be at Stanford somewhere around 18 April. Maybe I'll see you then. -- Philip Machanick philip@cs.wits.ac.za Department of Computer Science, University of the Witwatersrand 2050 Wits, South Africa phone 27(11)716-3309 fax 27(11)339-7965 >From eric.larson@f620.n2605.z1.fidonet.org (eric larson) Subject: Macintosh Disk Cache fix -- 25 times speedup Date: 11 Apr 94 18:12:03 -0500 Organization: FidoNet:* File Edit View Label Special ? D (1:2605/620) > This leads me into my next tip: read and write in large chunks. > It really is much more efficient to read and write in >4K chunks > and pull your data out of there yourself. > With these few tips, you can increase your enjoyment of the Mac > file system. How about a quick & -dare I say- dirty code snip? +++++++++++++++++++++++++++ >From Ron_Hunsinger@bmug.org (Ron Hunsinger) Date: Wed, 13 Apr 94 00:09:16 PST Organization: Berkeley Macintosh Users Group Stuart Cheshire <cheshire@cs.stanford.edu> writes: >Yesterday morning I wrote a little INIT which sets the File Manager >"don't cache" bit for disk writes of 1K or more. It does this by >installing the following patch on the _Write system call: Question: what happens in the following circumstance? 1) A program reads some data in several chunks of 512 bytes each (or even reads it all in one big chunk), having as a side effect that a copy of the data is now present in the cache. 2) The program modifies the data, and writes it out in one large chunk. Because of your patch, the cache is bypassed. 3) The program re-reads the data. Does the program get the stale data that was placed in the cache in step 1, or the updated data that was written in step 2? -Ron Hunsinger +++++++++++++++++++++++++++ >From jumplong@aol.com (Jump Long) Date: 14 Apr 1994 16:40:02 -0400 Organization: America Online, Inc. (1-800-827-6364) In article <0013ABED.fc@bmug.org>, Ron_Hunsinger@bmug.org (Ron Hunsinger) writes: > Question: what happens in the following circumstance? > > 1) A program reads some data in several chunks of 512 bytes each > (or even reads it all in one big chunk), having as a side effect > that a copy of the data is now present in the cache. > > 2) The program modifies the data, and writes it out in one large > chunk. Because of your patch, the cache is bypassed. > > 3) The program re-reads the data. > > Does the program get the stale data that was placed in the cache in > step 1, or the updated data that was written in step 2? You don't need to worry about this because the Macintosh file system cache code takes care of making sure you get the correct data. Any writes that bypass the cache will remove those blocks from the cache so the read in your step 3 would come from the disk driver, not the cache. So, the only way you can get data that's inconsistant with the file system cache is to bypass the file system and read directly from the disk driver. That's the reason we (Apple) tell developers of disk repair utilities to unmount a volume before they read the disk directly. Unmounting a volume flushes all dirty blocks (blocks that have been changes in the cache, but not on disk) to disk and then trashes all cache blocks associated with that volume. - Jim Luther +++++++++++++++++++++++++++ >From rbauchsp@herbie.unl.edu (ROGER BAUCHSPIES) Date: 15 Apr 1994 06:34:42 GMT Organization: University of Nebraska--Lincoln Jump Long (jumplong@aol.com) wrote: : So, the only way you can get data that's inconsistant with the file system : cache is to bypass the file system and read directly from the disk driver. : That's the reason we (Apple) tell developers of disk repair utilities to : unmount a volume before they read the disk directly. Unmounting a volume : flushes all dirty blocks (blocks that have been changes in the cache, but not : on disk) to disk and then trashes all cache blocks associated with that volume. Apple should tell developers to do the same for SCSI drivers with caches. RapidTrak and Iomega SCSI drivers contain their own cache, which they do NOT flush when a volume is unmounted. This causes problems with programs that bypass the SCSI driver and talk directly to the disk. As a rule, any cache should stop caching a volume if it is not online. Steve Kiene MindVision Software --------------------------- >From pburgess@netcom.com (Phillip Burgess) Subject: PowerMac Programming & the data bus Date: Thu, 14 Apr 1994 06:37:27 GMT Organization: NETCOM On-line Communication Services (408 241-9760 guest) A couple of questions about programming on the Power Macintosh... How can I best take advantage of the PowerMac's 64-bit path to memory when working with 32-bit integer values? If I'm writing a number of 32-bit values to a contiguous chunk of memory, do they (or can they) get stored in pairs about as quickly as storing half as many noncontiguous values? If so, what sort of flaming hoops, if any, do I need to jump through? If memory can be accessed in this fashion, what about writing 4 contiguous 16-bit values, or 8 contiguous bytes? Same effect? Also, how many integer and FP registers am I likely to actually have at my disposal when using a C compiler such as MetroWorks'? -- Phillip Burgess (pburgess@netcom.com) +++++++++++++++++++++++++++ >From zstern@adobe.com (Zalman Stern) Date: Thu, 14 Apr 1994 08:53:31 GMT Organization: Adobe Systems Incorporated Phillip Burgess writes > A couple of questions about programming on the Power Macintosh... > > How can I best take advantage of the PowerMac's 64-bit path to memory when > working with 32-bit integer values? If I'm writing a number of 32-bit > values to a contiguous chunk of memory, do they (or can they) get stored > in pairs about as quickly as storing half as many noncontiguous values? > If so, what sort of flaming hoops, if any, do I need to jump through? > If memory can be accessed in this fashion, what about writing 4 contiguous > 16-bit values, or 8 contiguous bytes? Same effect? On the 601 (which I assume is what we're talking about here), the the cache sits between the processor and the 64 bit databus. The path between the fixed-point unit and the cache is only 32 bits wide. There is a 64 bit datapath between the floating-point unit and the cache. The cache stores/fetches entire 32 byte blocks to/from memory (or secondary cache) at a time. Hence each 32 bit write from the fixed-point unit does not result in a memory transaction if you are writing to contiguous addresses. Unless you are writing to uncached memory. In that case the only way to get 64 bit bus transactions on at least some (if not all) current hardware is to use floating-point loads and stores. That may be a win even if you have to add a couple of cached loads and stores to make it work (e.g. to handle misaligned cases). For writing contiguous regions of cached memory, you'll want to look into the dcbz instruction. Normally when you write to an address that is not in the cache, the hardware fetches that block before handling the store. This is obviously necessary as the cache will want to store the entire 32 byte block later and if you only wrote 32 bits of that, the rest of the block has to be valid. The dcbz (data cache block zero) instruction says "I'm going to write the entire cache block around this address so just make me a cache block of zeros for that address." This has the effect of storing zero to all addresses covered by the cache block. There are a couple difficulties with dcbz. The first is discovering the cache block size. This is important as the correctness of your code will depend upon this size. A second difficulty is writing code that can do the dcbz instruction for each cache block for different block sizes. You can either put conditional code in your loop, or punt and write two versions of the code: a fast one that works for 32 byte blocks, and one that doesn't use dcbz for other block sizes. A third difficulty is accessing this instruction from C code. You'll either need a compiler that supports inline assembly, or you'll have to hand code the inner loop. The potential win of all this is reducing your applications memory bandwidth by up to a third. -- Zalman Stern zalman@adobe.com (415) 962 3824 Adobe Systems, 1585 Charleston Rd., POB 7900, Mountain View, CA 94039-7900 "Do right, and risk consequences." Motto of Sam Houston (via Molly Ivins) +++++++++++++++++++++++++++ >From d88-jwa@mumrik.nada.kth.se (Jon Wätte) Date: 14 Apr 1994 08:58:58 GMT Organization: The Royal Institute of Technology In <pburgessCo8L2F.DzG@netcom.com> pburgess@netcom.com (Phillip Burgess) writes: >A couple of questions about programming on the Power Macintosh... I would suggest a good book on processor architecture. >working with 32-bit integer values? If I'm writing a number of 32-bit >values to a contiguous chunk of memory, do they (or can they) get stored >in pairs about as quickly as storing half as many noncontiguous values? Pretty much. It's more notable when you read sequentially through memory. >If so, what sort of flaming hoops, if any, do I need to jump through? None. >If memory can be accessed in this fashion, what about writing 4 contiguous >16-bit values, or 8 contiguous bytes? Same effect? Yeah, but misaligned reads take some time fixing up, and you also need eight separate read/write instructions instead of two if you do bytes instead of long words. >Also, how many integer and FP registers am I likely to actually have at my >disposal when using a C compiler such as MetroWorks'? About 25 of each. Cheers, / h+ -- -- Jon W{tte, h+@nada.kth.se, Mac Hacker Deluxe -- There's no problem that can't be solved using brute-force algorithms and a sufficiently fast computer. Ergo, buy more hardware. (NOT!) --------------------------- >From hslari@gibbs.oit.unc.edu (Humayun Lari) Subject: QuickDraw GX Questions Date: 28 Mar 1994 19:03:43 GMT Organization: University of North Carolina, Chapel Hill I have a couple of user-oriented questions about writing a graphics program that uses GX. I don't have any obvious answers to these questions, so I'm hoping someone else does: 1. Since QuickDraw GX uses quadratic curves, it seems like it's going to be harder for users to edit GX paths than it is for users to edit Postscript paths that use cubic curves -- a la FreeHand or Illustrator. I asked this question a year ago, and Tom Dowdy replied to the effect that it didn't matter, since the application could present a different model (e.g. cubic curves) to the user. That's true, but how can cubic curves be converted into quadratic curves without loss of accuracy? The GX libraries have a routine that does the conversion, but its documentation indicates that the result can be slightly off. Is this error acceptable? 2. The GX libraries use a 1-pixel wide bitmap ramp to produce linear blends. Is there an effective way to produce radial blends that doesn't require a huge bitmap and thus large storage requirements? Appreciatively, Humayun Lari (lari@email.unc.edu) +++++++++++++++++++++++++++ >From dowdy@apple.com (Tom Dowdy) Date: Fri, 1 Apr 1994 17:51:35 GMT Organization: Apple Computer, Inc. In article <2n79mf$gcf@bigblue.oit.unc.edu>, hslari@gibbs.oit.unc.edu (Humayun Lari) wrote: > 1. Since QuickDraw GX uses quadratic curves, it seems like it's going to be > harder for users to edit GX paths than it is for users to edit Postscript > paths that use cubic curves -- a la FreeHand or Illustrator. I asked this > question a year ago, and Tom Dowdy replied to the effect that it didn't > matter, since the application could present a different model (e.g. cubic > curves) to the user. That's true, but how can cubic curves be converted > into quadratic curves without loss of accuracy? The GX libraries have a > routine that does the conversion, but its documentation indicates that the > result can be slightly off. Is this error acceptable? Well, since the result can be within 1 pixel (and you can't draw smaller than that, and GX is device independant), the error is generally acceptable. The libraries show the basics of what need to be done -- and are fairly accurate. But they are provided as SOURCE CODE, so it's easy to improve them from there. However, if you need to make sure that when converting to something that "supports" cubics native (like PostScript -- although actually PostScript always blits everything as lines, and has it's own error (curveerror) built in anyway) you attach to the shape a cubic tag, which GX will use in preference to the quadratic data when printing to a device that supports it (except if you apply a non-linear transform to it (see below)). As far as editing goes, you can present any model you wish to the user -- and I honestly think that users don't want to EDIT using control points (be they for quads or cubics) anyway. There are other editing models that are easier to use and that normal people will probably prefer. The question of quads vs. cubics has lots of history, but basically (as far as GX is concerned) ends up stopping when you consider the following: - cubics can't be intersected with other shape (the math is too difficult) - cubics can't be inset or outside mathematically, nor simplified - PostScript's implementation doesn't allow for perspective transformation, so the cubic data can't be used in this case. Developers of a GX savvy application will probably want to use many of these features to let the user create shapes by combining/removing and distorting exiting shapes to create new ones. And because it isn't mathematically possible to do this with cubics, these applications will need to convert shapes into quadratics for these operations. > 2. The GX libraries use a 1-pixel wide bitmap ramp to produce linear > blends. Is there an effective way to produce radial blends that doesn't > require a huge bitmap and thus large storage requirements? Well, traditionally, blends aren't done with a bitmap, but with a series of inset/outset shapes. For Version 1.0 this the only way to do radial blends. This is how most applications do blends today. Some do their blends in PostScript, when available, and you can still do this with GX. Simply attach a PostScript tag to the picture shape containing your blend -- this tag will be used when possible, and when it isn't possible, the picture shape data will be used. Note that either of these methods is by it's nature device DEPENDANT. This is no worse than today's world (with respect to these objects), and maybe a bit better (due to more properly allowing alternate representations). A future version of GX will very likely provide a "multi-color" model for shapes, which would also allow for this type of ramp. But for 1.0 we had to stop someplace :-) -- Tom Dowdy Internet: dowdy@apple.COM Apple Computer MS:302-3KS UUCP: {sun,voder,amdahl,decwrl}!apple!dowdy 1 Infinite Loop AppleLink: DOWDY1 Cupertino, CA 95014 "The 'Ooh-Ah' Bird is so called because it lays square eggs." +++++++++++++++++++++++++++ >From hslari@gibbs.oit.unc.edu (Humayun Lari) Date: 3 Apr 1994 00:17:21 GMT Organization: University of North Carolina, Chapel Hill In article <dowdy-010494090912@17.202.72.12>, Tom Dowdy <dowdy@apple.com> wrote: >As far as editing goes, you can present any model you wish to the >user -- and I honestly think that users don't want to EDIT using >control points (be they for quads or cubics) anyway. There are >other editing models that are easier to use and that normal >people will probably prefer. Tom, thank you for your detailed and thorough response. I'm very appreciative, but a couple of your answers invite a couple more questions... I've worked with most of the major Macintosh drawing programs, and as far as I know, none of them allow you to edit complex paths without using cubic (or spline) control points. Sure, some of them allow you to draw freehand and produce the path for you, but none provide a different editing model that "normal people" would like. What kind of model are you referring to? >> 2. The GX libraries use a 1-pixel wide bitmap ramp to produce linear >> blends. Is there an effective way to produce radial blends that doesn't >> require a huge bitmap and thus large storage requirements? > >Well, traditionally, blends aren't done with a bitmap, but with a >series of inset/outset shapes. For Version 1.0 this the only way >to do radial blends. This is how most applications do blends today. >Some do their blends in PostScript, when available, and you can still >do this with GX. Simply attach a PostScript tag to the picture >shape containing your blend -- this tag will be used when possible, >and when it isn't possible, the picture shape data will be used. > >Note that either of these methods is by it's nature device DEPENDANT. >This is no worse than today's world (with respect to these objects), >and maybe a bit better (due to more properly allowing alternate >representations). > >A future version of GX will very likely provide a "multi-color" model >for shapes, which would also allow for this type of ramp. But for >1.0 we had to stop someplace :-) But by using a bitmap, the ramp library converts colors into RGB; doesn't this make it device dependent? Or am I missing something? Similarly, if radial blends are produced using, say, a sequence of 32 circles, would it be appropriate to convert the blend colors into RGB before computing the circle colors? Or would a color system such as CIE be more desirable? Humayun Lari (lari@email.unc.edu) +++++++++++++++++++++++++++ >From 103t_english@west.cscwc.pima.edu Date: 4 Apr 94 20:38:42 MST Organization: (none) In article <dowdy-010494090912@17.202.72.12>, dowdy@apple.com (Tom Dowdy) writes: > A future version of GX will very likely provide a "multi-color" model > for shapes, which would also allow for this type of ramp. But for > 1.0 we had to stop someplace :-) > Speaking of stopping someplace, is there an AE Suite associated with the GX API in the works? Lawson +++++++++++++++++++++++++++ >From dowdy@apple.com (Tom Dowdy) Date: Fri, 8 Apr 1994 18:03:15 GMT Organization: Apple Computer, Inc. In article <2nl1uh$nj0@bigblue.oit.unc.edu>, hslari@gibbs.oit.unc.edu (Humayun Lari) wrote: > I've worked with most of the major Macintosh drawing programs, and as far > as I know, none of them allow you to edit complex paths without using > cubic (or spline) control points. Sure, some of them allow you to draw > freehand and produce the path for you, but none provide a different > editing model that "normal people" would like. What kind of model are you > referring to? Well, one such model is constructing curves and shapes via the mathematical joining and differencing of other shapes. Another is by "nudging" or "pulling" on areas of the curve using a shaped tool. These can easily be done using QuickDraw GX geometry operations, and for many types of editing may be more obvious for users. Without GX geometry doing the "hard work" for you, most applications writers have resorted to using cubic or quadratic editing. However, when cubic editing first came out -- artists couldn't figure out how to use it. This shows that the *users* changed towards the model that the applications provided rather than the other way around. I *still* can't edit shapes via splines of any kind. > >Note that either of these methods is by it's nature device DEPENDANT. > >This is no worse than today's world (with respect to these objects), > >and maybe a bit better (due to more properly allowing alternate > >representations). > > > >A future version of GX will very likely provide a "multi-color" model > >for shapes, which would also allow for this type of ramp. But for > >1.0 we had to stop someplace :-) > > But by using a bitmap, the ramp library converts colors into RGB; doesn't > this make it device dependent? Or am I missing something? Similarly, if > radial blends are produced using, say, a sequence of 32 circles, would it > be appropriate to convert the blend colors into RGB before computing the > circle colors? Or would a color system such as CIE be more desirable? Yes, this is device DEPENDANT in terms of resolution-- this is no worse than things are today. This is what I said about. However, it is still device indepedant with respect to color, even when expressing colors via RGB space. As far as what color space the colors should be expressed in -- this is up to the application. One of the wonderful things about GX is that applications can express color in spaces that work best for them and their users -- and GX takes care of converting to the correct display or output space for you. Included in this is GX's ability to correctly color match the results. For ramps, most folks work in HSV/HSL or other "intensity" or "value" type spaces. CIE space is a bit difficult to produce ramps in -- probably even more so than RGB space. But the important point here is that it doesn't really matter. Express the color as YOU want (note that this includes bitmaps, which can be in any GX's color spaces). Even though everything except the CIE family of spaces is technically a dependant color space, QuickDraw GX allows all spaces to be calibrated through use of a gxColorProfile. When you don't specifically provide a source color profile, QuickDraw GX makes use of the default monitor profile provide via ColorSync. -- Tom Dowdy Internet: dowdy@apple.COM Apple Computer MS:302-3KS UUCP: {sun,voder,amdahl,decwrl}!apple!dowdy 1 Infinite Loop AppleLink: DOWDY1 Cupertino, CA 95014 "The 'Ooh-Ah' Bird is so called because it lays square eggs." +++++++++++++++++++++++++++ >From lari@cs.unc.edu (Humayun Lari) Date: 15 Apr 1994 13:41:01 -0400 Organization: The University of North Carolina at Chapel Hill In article <dowdy-080494105252@17.202.72.12>, Tom Dowdy <dowdy@apple.com> wrote: >Well, one such model is constructing curves and shapes via the mathematical >joining and differencing of other shapes. Another is by "nudging" or >"pulling" on areas of the curve using a shaped tool. > >These can easily be done using QuickDraw GX geometry operations, and for >many types of editing may be more obvious for users. Without GX geometry >doing the "hard work" for you, most applications writers have resorted >to using cubic or quadratic editing. However, when cubic editing >first came out -- artists couldn't figure out how to use it. This >shows that the *users* changed towards the model that the applications >provided rather than the other way around. > >I *still* can't edit shapes via splines of any kind. Unfortunately, since existing applications *do* use splines, it seems likely that programmers are going to continue using cubics or quadratics. Users, as you say, have become accustomed to this model, so they may actually *dislike* replacements. Beta 3 of GX doesn't appear to have any examples of user interfaces that allow "nudging" or "pulling", which seem to have the potential to replace the spline model. Does anyone (Tom? :-)) know of papers on such interfaces or have examples of existing applications on other platforms that use better models? It would be ironic to have the power of GX limited by old paradigms. Humayun Lari (lari@cs.unc.edu) --------------------------- >From blume@twg.com (David Blume) Subject: Quitting faceless background applications Date: Wed, 13 Apr 1994 18:58:38 GMT Organization: Gokuraku Videos - Wollongong Dept. What is the prefered way for the user to quit a faceless background application? (Besides finding a way to generate a "Quit" Apple Event.) Also, and more importantly, once the faceless background application quits, how do we tell the finder to update the icon for the application? (Even when faceless background applications quit, their icons in the finder stay in the grayed out "in use" state.) For an example, try quitting the "ledApp" application from the Dec Dev. CD. Thanks! --David +---------------------------------------------------------------+ | David Blume | "I get tired thinking of all the things I | | blume@twg.com | don't want to do." --Bukowski, _Barfly_ | +---------------------------------------------------------------+ +++++++++++++++++++++++++++ >From Philippe.Casgrain@univ-rennes1.fr (Philippe Casgrain) Date: Wed, 13 Apr 1994 21:58:48 +0100 Organization: Universite de Rennes-1, Fac. de medecine dentaire In article <1994Apr13.185838.21434@twg.com>, blume@twg.com (David Blume) wrote: > What is the prefered way for the user to quit a faceless background > application? (Besides finding a way to generate a "Quit" Apple Event.) > I like the way Greg Robbins did it in his "SmallDaemon" sample: if a modifier key is detected at the same time an AppleEvent is received (he used Caps Lock, but it could be anything), then quit the app. Thus, you could quit the FBA by double-clicking on it with the Caps Lock key down. > Also, and more importantly, once the faceless background application > quits, how do we tell the finder to update the icon for the application? > (Even when faceless background applications quit, their icons in the finder > stay in the grayed out "in use" state.) > I don't think you can, it's a bug in the Finder (or so I remember reading... here ;-) Philippe -- Philippe.Casgrain@univ-rennes1.fr Mac Hacker Lite +++++++++++++++++++++++++++ >From markhanrek@aol.com (MarkHanrek) Date: 14 Apr 1994 03:11:07 -0400 Organization: America Online, Inc. (1-800-827-6364) >> What is the prefered way for the user to quit a faceless background >> application? Also, how do we tell the finder to update the icon for the >> application? The Finder icon for a faceless bkgnd task does not go back to normal after the bkgnd task terminates. This is a bug and there is no workaround that I have heard of. Also, I would say that there is no preferred way for a user to terminate a faceless bkgnd task, since these applications have no user interface, and if there was a way, that would imply a user interface. I would say that background-only applications should quit themselves and be more like "agents". That would be more fun, eh? :) In any case, I guess "it depends on the situation". (Dontcha hate answers like that? :) Mark Hanrek +++++++++++++++++++++++++++ >From rmcassid@uci.edu (Robert Cassidy) Date: Thu, 14 Apr 1994 10:16:10 -0700 Organization: TLG Project In article <2oiqab$e5o@search01.news.aol.com>, markhanrek@aol.com (MarkHanrek) wrote: > >> What is the prefered way for the user to quit a faceless background > >> application? Also, how do we tell the finder to update the icon for the > >> application? > > The Finder icon for a faceless bkgnd task does not go back to normal after the > bkgnd task terminates. This is a bug and there is no workaround that I have > heard of. > > Also, I would say that there is no preferred way for a user to terminate a > faceless bkgnd task, since these applications have no user interface, and if > there was a way, that would imply a user interface. > > I would say that background-only applications should quit themselves and be > more like "agents". That would be more fun, eh? :) > > In any case, I guess "it depends on the situation". (Dontcha hate answers like > that? :) > > Mark Hanrek Powertalk Manager runs as an appe all the time. I haven't found of any good way of killing it (other than running one of my buggier programs which kills EVERYTHING :-) FYI, Malph is a program which displays a list of all running processes. It also includes appe's in the list and using balloon help you can get such goodies as SIZE, Signature, location in memory, etc. - very cool. -- Robert Cassidy TLG Project UC Irvine Let's hope 'Information SuperTollroad' isn't the catchphrase of the next decade... +++++++++++++++++++++++++++ >From David Casseres <casseres@apple.com> Date: Thu, 14 Apr 1994 22:40:29 GMT Organization: Apple Computer, Inc. In article <2oiqab$e5o@search01.news.aol.com> MarkHanrek, markhanrek@aol.com writes: > >> What is the prefered way for the user to quit a faceless background > >> application? Also, how do we tell the finder to update the icon for the > >> application? > > The Finder icon for a faceless bkgnd task does not go back to normal after the > bkgnd task terminates. This is a bug and there is no workaround that I have > heard of. > > Also, I would say that there is no preferred way for a user to terminate a > faceless bkgnd task, since these applications have no user interface, and if > there was a way, that would imply a user interface. > > I would say that background-only applications should quit themselves and be > more like "agents". That would be more fun, eh? :) Yeah, I think the whole original question is a bit confused. If it's faceless then *by definition* the user has no way to interact with it. I'd say there are really two categories of faceless background apps: 1. System extensions, which are started by the system at startup and killed at shutdown (though they may also be designed to quit themselves). Their icons never change in appearance, and the user doesn't normally look at them since they're hidden away in the Extensions folder. 2. Programs that are launched by other programs and then controlled by them. The controlling program, assuming it has a user interface, might give the user a way to kill the faceless background process. When a program is launched by some other program (not the Finder), its icon does not change in appearance. I think maybe the original poster was thinking about a program with a *minimal* user interface. You can get away with no user interface except a menu, which could contain a "Quit" item. To do this the program should be a normal Mac application, type 'APPL', launched normally by the Finder. It should be able to run both in foreground and background, since of course its menu will only appear in the foreground. The user can bring it to the foreground by using the Finder's Application menu. - ----------- David Casseres Exclaimer: Hey! +++++++++++++++++++++++++++ >From jumplong@aol.com (Jump Long) Date: 15 Apr 1994 00:48:08 -0400 Organization: America Online, Inc. (1-800-827-6364) In article <1994Apr13.185838.21434@twg.com>, blume@twg.com (David Blume) writes: > What is the prefered way for the user to quit a faceless background > application? (Besides finding a way to generate a "Quit" Apple Event.) Since faceless background applications don't have a user interface, you'll have to send it a quit Apple event to tell it to shut down (or send it a signal some other way). > Also, and more importantly, once the faceless background application > quits, how do we tell the finder to update the icon for the application? > (Even when faceless background applications quit, their icons in the finder > stay in the grayed out "in use" state.) If the faceless background application is of file type 'APPL', then there's nothing you can do about the grayed out icon. The Finder doesn't track the state of faceless background applications correctly (as pointed out by others). However, there's nothing forcing you to use type 'APPL'. If you want the application automatically launched at system startup time, you can use a file type of 'appe'. If you use 'appe', then the Finder will automatically put the application in the Extensions folder when the application is dropped on the System Folder and the application will be launched a startup time. If you *don't* want the application launched at system startup time, you can use just about any other file type that makes sense to you (don't use anything goffy like 'TEXT'), but you'll have to launch the application yourself. Here's an real-life example... The File Sharing Extension is an 'INIT' file in the Extensions folder that implements Macintosh File Sharing. The File Sharing Extension contains an 'INIT' resource which installs the parts of the file server software that always need to be available including the _ServerDispatch (A094) trap. One of the routines implemented through _ServerDispatch is SCStartServer. When SCStartServer is called, the trap code launches the file server application. Guess where the file server application code is? It's in the File Sharing Extension file (if you don't believe me, just look). So, you could do something similar. You'd just need to use a small application to control your faceless background application. The controlling application would launch the faceless background application to start it and send the faceless background application a quit Apple event when it needed to shut it down. - Jim Luther --------------------------- End of C.S.M.P. Digest **********************