From: pottier@clipper.ens.fr (Francois Pottier) Subject: csmp-digest-v3-057 Date: Tue, 13 Sep 1994 15:09:42 +0200 (MET DST) C.S.M.P. Digest Tue, 13 Sep 94 Volume 3 : Issue 57 Today's Topics: Best Sprite Package? CW PASCAL vs THINK PASCAL Items in system menu bar Text searches. Ticks (was: Clover+. interrupt?) What is the point of MPW? Where have the standards gone? [a high level question] 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 gkm@jolt.mpx.com.au (Gavin K Maxwell) Subject: Best Sprite Package? Date: 19 Aug 1994 06:15:19 GMT Organization: Microplex Pty Ltd I would like to know peoples impressions of the available sprite animation libraries. The two I'm aware of are SpriteWorld and Sprite Animation Toolkit (SAT), are there any others? Which is the best? Are there any gotchas to watch out for? What are their limitations? Any help would be appreciated, -- Gavin, +---------------------+-----------------------------+ ||||||| | Gavin Maxwell, | "You can't have everything. | | _ _ | | gkm@jolt.mpx.com.au | Where would you put it!!" | | O O | | +61-2-3426236 | | | ^ | +---------------------+-----------------------------+ \ ~ / --- +++++++++++++++++++++++++++ >From mab22@po.cwru.edu (Mike Balfour) Date: 19 Aug 1994 14:47:14 GMT Organization: Overload Engineering In article <331iln$4fq@inferno.mpx.com.au>, gkm@jolt.mpx.com.au (Gavin K Maxwell) wrote: > I would like to know peoples impressions of the available sprite > animation libraries. The two I'm aware of are SpriteWorld and Sprite > Animation Toolkit (SAT), are there any others? Which is the best? > Are there any gotchas to watch out for? What are their limitations? > Well, it seems that more people out there are using SpriteWorld, just because it was released about a month before SAT. SpriteWorld is also more geared to C, where SAT was originally written for Pascal and has since been updated to be usable from C. Between the two, I'm very biased toward SAT. I beta-tested it for several months, and I found it was very easy to learn, easy to use, and just good quick code. It even makes my bad code run fast (who else can claim that?)! Somebody else recently posted the concern that SAT still has warnings in it from the author, Ingemar, about various kluges. I wouldn't be concerned - everything's actually amazingly stable. I should know, I tried some pretty strange things from time to time to try to make it break... MB -- - --------------------------------+-------------------------------- Mike Balfour, Partner | BS/MS Candidate - ECMP Overload Engineering | Case Western Reserve University "New Ideas for a Brighter Future" | Cleveland, OH +++++++++++++++++++++++++++ >From al@crucible.powertools.com (Al Evans) Date: 19 Aug 94 14:57:16 GMT Organization: PowerTools, Austin, Texas In article <331iln$4fq@inferno.mpx.com.au> gkm@jolt.mpx.com.au (Gavin K Maxwell) writes: >I would like to know peoples impressions of the available sprite >animation libraries. The two I'm aware of are SpriteWorld and Sprite >Animation Toolkit (SAT), are there any others? Which is the best? >Are there any gotchas to watch out for? What are their limitations? You might want to have a look at Graphic Elements. To my way of thinking, it offers a lot more flexibility than either SpriteWorld or SAT -- but then, I'm the author:-) As to which is best for you, that probably depends on what you want to do. Graphic Elements has lots of built-in features: buttons and sliders, horizontal and vertical mirroring, special effects. SpriteWorld has good performance with free licensing and complete source code. SAT has both C and Pascal interfaces and offers excellent support for older systems. Both Graphic Elements and SpriteWorld offer native PPC support; I'm not sure about SAT. --Al Evans-- -- Al Evans | Graphic Elements: A new standard for ________________________|__ high-performance interactive Macintosh graphics. al@crucible.powertools.com | Available from mac.archive.umich.edu - -------------------------| /mac/development/libraries/graphicelements2.sit.hqx +++++++++++++++++++++++++++ >From ez033265@ucdavis.edu (Will Iverson) Date: Fri, 19 Aug 1994 18:01:34 GMT Organization: University of California, Davis In article <479@crucible.powertools.com>, al@crucible.powertools.com (Al Evans) wrote: > In article <331iln$4fq@inferno.mpx.com.au> gkm@jolt.mpx.com.au (Gavin K Maxwell) writes: > > As to which is best for you, that probably depends on what you want > to do. Graphic Elements has lots of built-in features: buttons and > sliders, horizontal and vertical mirroring, special effects. SpriteWorld > has good performance with free licensing and complete source code. SAT > has both C and Pascal interfaces and offers excellent support for older > systems. Both Graphic Elements and SpriteWorld offer native PPC support; > I'm not sure about SAT. SAT (as of version 2.1.2) doesn't offer native PPC support. -Will Iverson +++++++++++++++++++++++++++ >From we37026@vub.ac.be (DICTUS ROY) Date: 20 Aug 1994 21:50:45 GMT Organization: Brussels Free Universities (VUB/ULB), Belgium I've looked at all three packages a while ago; SAT, SpriteWorld and Graphics Elements. I've written a few games using SAT and was most impressed with it. Good interface, logical structure, fast and reliable code. SpriteWorld looks good too, but seems much harder to use than SAT. Graphics Elements, to be frank, I wasn't very impressed with (no offense to the author). I liked SAT and SW better. I'll stick to SAT. I just like it the best and it has proven itself. Games on the Net that were written with SAT: - Asterax - Bachman 2 - CyberNation - Missions of the Reliant - Warbirds - ... How many games have been written with SpriteWorld? I don't recall ever having seen any reference to it in any game... Just my $0.02, - Roy +++++++++++++++++++++++++++ >From hamptn@uow.edu.au ( Dan Hampton ) Date: 25 Aug 1994 12:00:10 +1000 Organization: University of Wollongong, NSW, Australia. we37026@vub.ac.be (DICTUS ROY) writes: >I've looked at all three packages a while ago; SAT, SpriteWorld and >Graphics Elements. >I've written a few games using SAT and was most impressed with it. Good >interface, logical structure, fast and reliable code. >SpriteWorld looks good too, but seems much harder to use than SAT. >Graphics Elements, to be frank, I wasn't very impressed with (no offense >to the author). I liked SAT and SW better. >I'll stick to SAT. I just like it the best and it has pr >Games on the Net that were written with SAT: >- Asterax >- Bachman 2 >- CyberNation >- Missions of the Reliant >- Warbirds >- ... >How many games have been written with SpriteWorld? I don't recall ever >having seen any reference to it in any game... Yeah that is true, It'd be interesting to see if anything decent has been made with SpriteWorld. The latest version is very complete and packed with features, PPC native, and extremely fast. There can be a bit of fiddling around with things that you'd rather not have to deal with thou. Where can Graphic Elements be gotten from anyway? (ftp site {which one}) - -------------------------------------------------------------------- It is an important and popular fact that things are not always what they seem. For instance, on the planet Earth, man had always assumed that he was more intelligent than dolphins because he had achieved so much -- the wheel, New York, wars and so on -- whilst all the dolphins had ever done was muck about in the water having a good time. But conversely, the dolphins had always believed that they were far more intelligent than man -- for precisely the same reasons. -- Douglas Adams "The Hitch-Hikers' Guide To The Galaxy". - -------------------------------------------------------------------- Dan Hampton -- Austinmer, NSW, Australia. - -------------------------------------------------------------------- +++++++++++++++++++++++++++ >From al@crucible.powertools.com (Al Evans) Date: 25 Aug 94 14:29:13 GMT Organization: PowerTools, Austin, Texas In article <33gtva$gs7@wumpus.cc.uow.edu.au> hamptn@uow.edu.au ( Dan Hampton ) writes: >Yeah that is true, It'd be interesting to see if anything decent has been >made with SpriteWorld. The latest version is very complete >and packed with features, PPC native, and extremely fast. I have recently done some (contract) finishing work on a piece of educational software from a major educational publishing company that used SpriteWorld for its animation. >There can be a bit of fiddling around with things that you'd >rather not have to deal with thou. Although I did not deal directly with the animation routines in this package, it seemed to me that they required an enormous number of lines of code for what they did. >Where can Graphic Elements be gotten from anyway? (ftp site {which one}) See my .signature. --Al Evans-- -- Al Evans | Graphic Elements: A new standard for ________________________|__ high-performance interactive Macintosh graphics. al@crucible.powertools.com | Available from mac.archive.umich.edu - -------------------------| /mac/development/libraries/graphicelements2.sit.hqx +++++++++++++++++++++++++++ >From ingemar@lysator.liu.se (Ingemar Ragnemalm) Date: 28 Aug 1994 10:28:19 GMT Organization: (none) ez033265@ucdavis.edu (Will Iverson) writes: >SAT (as of version 2.1.2) doesn't offer native PPC support. This is true, and the reason is that CodeWarrior is so damn buggy! I've tried porting some smaller hacks to it, and I'm getting tired of rebooting over and over again, with the debugger not catching any problems at all. Actually, if there is some SKILLED programmer out there, with some experience with CodeWarrior Pascal, I'd be happy to let him/her try porting it. Perhaps a CodeWarrior version could skip the 68000 support and all blitters except 8-bit, just to get it running for PPC? Considering what package is BEST, I think it's a matter of needs and taste. SW is written as an Apple Manager. Fairly general, not too quick to get started with, handles sprite management only. I found it a little worrying to find out that it's made by a programmer who hasn't made a computer game in his life (that we know of). I mean, if HE can't make games with it, why should I believe I can? (The big problem I'm aiming at is the lack of a full game demo.) I'm not sure it has more USERS than SAT. More people have it, and I'm sure lots of people grab code from it, but who knows how many people uses it? It has some strong points, like staggered drawing (which isn't impossible in SAT, but a bit harder) and grouping the sprites in distinct so-called layers. SAT is written for kick-start coding, for getting up in the air quickly, with a very small set of calls for the beginner. It includes asynch sound, simply because 99.9% of the programmers will need that too, and you don't want all the hassle making it work with Sound Manager 2! Good support for Pascal as well as C is a must. Pascal is easier to work with, and SAT is made to be beginner-friendly. NONE of the others support Pascal to any extent that is worth mentioning. SAT clearly has the best support for Macs not supporting 8-bit color (i.e. old Macs and Powerbooks), and supports scrolling games. Graphical Elements, I've hardly had time to look at that at all, but I got the impression of a slightly different scope, not only at games. (I'll leave it to Al to make more specific statements.) -- - - Ingemar Ragnemalm, PhD Image processing, Mac shareware games E-mail address: ingemar@isy.liu.se or ingemar@lysator.liu.se +++++++++++++++++++++++++++ >From dwareing@apanix.apana.org.au (David Wareing) Date: 29 Aug 94 03:21:33 GMT Organization: Apanix Public Access Unix, +61 8 373 5485 (5 lines) mab22@po.cwru.edu (Mike Balfour) writes: >In article <331iln$4fq@inferno.mpx.com.au>, gkm@jolt.mpx.com.au (Gavin K >Maxwell) wrote: >> I would like to know peoples impressions of the available sprite >> animation libraries. The two I'm aware of are SpriteWorld and Sprite >> Animation Toolkit (SAT), are there any others? Which is the best? >> Are there any gotchas to watch out for? What are their limitations? >Well, it seems that more people out there are using SpriteWorld, just >because it was released about a month before SAT. SpriteWorld is also more >geared to C, where SAT was originally written for Pascal and has since been >updated to be usable from C. Between the two, I'm very biased toward SAT. >I beta-tested it for several months, and I found it was very easy to learn, >easy to use, and just good quick code. It even makes my bad code run fast >(who else can claim that?)! Somebody else recently posted the concern that >SAT still has warnings in it from the author, Ingemar, about various >kluges. I wouldn't be concerned - everything's actually amazingly stable. >I should know, I tried some pretty strange things from time to time to try >to make it break... I'm not sure about the "more people use SpriteWorld" claim, but there have been several shareware games released lately that use SAT. And there are several more on the way. Seems to be a fairly hip and happening product. -- David Wareing Adelaide, South Australia dwareing@apanix.apana.org.au - ------------------------------------------------------------ Freelance Macintosh Games & Multimedia Programming --------------------------- >From jc@ac.dal.ca (JOHN CHRISTIE) Subject: CW PASCAL vs THINK PASCAL Date: 18 Aug 94 11:57:04 -0300 Organization: Dalhousie University, Halifax, Nova Scotia, Canada PASCAL keeners read this Has anyone here used MW PASCAL and THINK PASCAL. I would be terribly interested in hearing how they compare from those who have used them. Thanks John +++++++++++++++++++++++++++ >From quinn@cs.uwa.edu.au (Quinn "The Eskimo!") Date: Fri, 19 Aug 1994 11:07:15 +0800 Organization: Department of Computer Science, The University of Western Australia In article <1994Aug18.115704.26744@dal1>, jc@ac.dal.ca (JOHN CHRISTIE) wrote: > Has anyone here used MW PASCAL and THINK PASCAL. I would be terribly >interested in hearing how they compare from those who have used them. The big difference between MW Pascal and Think Pascal is that MW Pascal is going somewhere, and Think Pascal isn't. MW Pascal still has it's problems (I'm still on 3.5 so my info may be out of date) but it's certainly a usable tool. [For 68K, the PPC one is very much a development version.] Think Pascal is, quite simply, the nicest development environment for the Macintosh. *However* MW is catching up quick and Think isn't going anywhere ): [for a variety of technical and marketting reasons] So it'll only be a matter of time before MW wins. -- Quinn "The Eskimo!" "Support HAVOC!" Department of Computer Science, The University of Western Australia +++++++++++++++++++++++++++ >From drickey@irus.rri.uwo.ca (Daniel W. Rickey) Date: 18 Aug 1994 19:06:11 GMT Organization: Imaging Research Labs I have tried both. Actually, I have not had a chance try out the latest release (CW4). Version 3.5 was still too buggy to evaluate properly. However, it looks like debugging in Think Pascal is much easier. CW has a different way of implementing writelns - it automatically creates an output window like TP, and it takes over the menu bar. This makes the writeln mechanism mostly useless for debugging (as far as I can tell). It will probably be a long time before the CW debugger is as nice as the ThinkP debugger...but we can hope! Moving code from ThinkP to CW is proving to be "interesting". A few library functions are missing in CW, although this is not too big of a deal. There may be a few other differences in the way typecasting/type conversions are done between the two compilers. One of the VERY nice features of CW is that it gives compile time warnings, e.g., variable declared but not used, etc. The CW pascal and C compilers are also very similar, unlike Symantec's compilers. This should make mixing of C and Pascal code in the same application much easier. Daniel W. Rickey drickey@.irus.rri.uwo.ca Imaging Research Laboratories The J.P. Robarts Research Institute 100 Perth Drive London, Ontario CANADA N6A 5K8 +++++++++++++++++++++++++++ >From ez033265@ucdavis.edu (Will Iverson) Date: Thu, 18 Aug 1994 20:25:20 GMT Organization: University of California, Davis In article <1994Aug18.115704.26744@dal1>, jc@ac.dal.ca (JOHN CHRISTIE) wrote: > PASCAL keeners read this > > Has anyone here used MW PASCAL and THINK PASCAL. I would be terribly > interested in hearing how they compare from those who have used them. > > Thanks > John I've used both, although I've used Think Pascal far more. I haven't been able to port my Think Pascal project over to MW Pascal yet because of (apparent) lack of full SANE support (and maybe something else I haven't found yet!) - although I'm not sure who to blame. The Think debugger is fully integrated with the editor. You want to set a breakpoint? Just click while you're in the editor. Lightsbugs lets you look at memory, data structures, etc. You can stop your program and change values, as well as write small pieces of code to be executed instantly from within the program. I find the entire programming cycle to be very short. The debugger for MW is a seperate program, which has advantages & disadvantages. The good news is that you can edit a program without resetting it, but it's a lot more of a pain to to set breakpoints. The Think Editor supports pretty-printing, which means you can basically forget about formatting and have it do it all for you. The MW Editor is sparser (keyword & comment coloring, no pretty-printing). It is smarter about things like having the cursor run off the right edge, however. Think Pascal hasn't seen an update in years. MW Pascal is being updated as we speak, but doesn't feel as complete. When I can switch my project over to MW Pascal, then my whole lab will switch over and we'll get a couple more copies of MW. Of course, which is better also depends on what you're trying to do. -Will Iverson +++++++++++++++++++++++++++ >From philip@cs.uct.ac.za (Philip Machanick) Date: 19 Aug 1994 12:17:47 +0200 Organization: Computer Science Department, University of Cape Town Will Iverson (ez033265@ucdavis.edu) wrote: : The Think debugger is fully integrated with the editor. You want to set a : breakpoint? Just click while you're in the editor. Lightsbugs lets you : look at memory, data structures, etc. You can stop your program and : change values, as well as write small pieces of code to be executed : instantly from within the program. I find the entire programming cycle to : be very short. The Think Pascal environment is wonderful. If only it had been developed properly - in same ways it is still the best but you can't allow something to languish for so long without losing your lead eventually. Another thing no one has mentioned in MW's favour: you get a free C and C++ compiler thrown in with it ;) -- Philip Machanick philip@cs.wits.ac.za Computer Science Department, University of he Witwatesrand 2050 Wits, South Africa 27(11)716-3309 fax 339-7965 (at University of Cape Town until November: 27(21)650-4058) +++++++++++++++++++++++++++ >From oberst@gov.nt.ca (David Oberst) Date: Fri, 19 Aug 1994 15:10:03 GMT Organization: Government of the NWT, Canada In article <3320sb$16f@cs.uct.ac.za> philip@cs.uct.ac.za (Philip Machanick) writes: >Another thing no one has mentioned in MW's favour: you get a free >C and C++ compiler thrown in with it ;) >-- >Philip Machanick philip@cs.wits.ac.za >Computer Science Department, University of he Witwatesrand >2050 Wits, South Africa 27(11)716-3309 fax 339-7965 >(at University of Cape Town until November: 27(21)650-4058) Of course, to the true Pascalite, this could be considered a drawback instead of a positive . David Oberst/GNWT Bureau of Statistics/Yellowknife, NWT, Canada oberst@gov.nt.ca +++++++++++++++++++++++++++ >From peter.lewis@info.curtin.edu.au (Peter N Lewis) Date: Sat, 20 Aug 1994 17:55:22 +0800 Organization: NCRPDA, Curtin University >version.] Think Pascal is, quite simply, the nicest development >environment for the Macintosh. *However* MW is catching up quick and >Think isn't going anywhere ): [for a variety of technical and marketting >reasons] So it'll only be a matter of time before MW wins. "a matter of time" likely being somewhere around about the end of the year when Metrowerks have said they will have their pascal compiler both supporting objects and compiling to PPC. Peter. -- Peter N Lewis - Macintosh TCP fingerpainter +++++++++++++++++++++++++++ >From quinn@cs.uwa.edu.au (Quinn "The Eskimo!") Date: Sun, 21 Aug 1994 14:52:23 +0800 Organization: Department of Computer Science, The University of Western Australia In article <330bf3$eia@falcon.ccs.uwo.ca>, drickey@irus.rri.uwo.ca (Daniel W. Rickey) wrote: >Moving code from ThinkP to CW is proving to be "interesting". A few >library functions are missing in CW, although this is not too big of a >deal. There may be a few other differences in the way typecasting/type >conversions are done between the two compilers. MW Pascal implements MPW Pascal, not Think Pascal. I've used both Think and MPW Pascal a lot and I know whether the differences lie. But there are lots of gotchas out there for hard-core Think Pascal users. Good luck. -- Quinn "The Eskimo!" "Support HAVOC!" Department of Computer Science, The University of Western Australia +++++++++++++++++++++++++++ >From quinn@cs.uwa.edu.au (Quinn "The Eskimo!") Date: Sun, 21 Aug 1994 14:53:05 +0800 Organization: Department of Computer Science, The University of Western Australia In article <3320sb$16f@cs.uct.ac.za>, philip@cs.uct.ac.za (Philip Machanick) wrote: >Another thing no one has mentioned in MW's favour: you get a free >C and C++ compiler thrown in with it ;) ^^^ I'm not sure whether I'd consider this an advantage (: -- Quinn "The Eskimo!" "Support HAVOC!" Department of Computer Science, The University of Western Australia +++++++++++++++++++++++++++ >From Vik_Rubenfeld@lamg.com (Vik Rubenfeld) Date: 21 Aug 1994 13:41:55 GMT Organization: Los Angeles Macintosh Group BBS Q> MW Pascal implements MPW Pascal, not Think Pascal. I've used both Q> Think and MPW Pascal a lot and I know whether the differences lie. Q> But there are lots of gotchas out there for hard-core Think Pascal Q> users. Good luck. Could you post a list describing some of the differences? Thanks in advance. +++++++++++++++++++++++++++ >From quinn@cs.uwa.edu.au (Quinn "The Eskimo!") Date: Mon, 22 Aug 1994 10:55:49 +0800 Organization: Department of Computer Science, The University of Western Australia In article <1088487199.6340968@lamgnet.lamg.com>, Vik_Rubenfeld@lamg.com wrote: >Could you post a list describing some of the differences? Thanks in advance. This is covered in one of the appendices in the Think Pascal reference manual. My personal favourite gotcha is the differences in the built-in string function copy. MPW (and MW) returns '' if any of the parameters are out of bounds whereas Think makes a best effort. eg copy('abcd', 3, 255) returns '' in MPW and MW and 'cd' in Think. -- Quinn "The Eskimo!" "Support HAVOC!" Department of Computer Science, The University of Western Australia +++++++++++++++++++++++++++ >From trentmd@scooby.beloit.edu (Michael Trent) Date: 22 Aug 1994 23:08:50 GMT Organization: Beloit College Quinn "The Eskimo! (quinn@cs.uwa.edu.au) wrote: : In article <1994Aug18.115704.26744@dal1>, jc@ac.dal.ca (JOHN CHRISTIE) wrote: : > Has anyone here used MW PASCAL and THINK PASCAL. I would be terribly : >interested in hearing how they compare from those who have used them. : The big difference between MW Pascal and Think Pascal is that MW Pascal is : going somewhere, and Think Pascal isn't. AMEN BROTHER! As cool as it is to have a "We will not be Emulated!" c/c++ compiler, it was a new Pascal that drove me to order MWCW Gold! I've spent too much time fighting the age of THINK Pascal to enjoy it anymore. -- Mike Trent | Macintosh Specialist | Beloit College trentmd@stu.beloit.edu | Academic Computing | Beloit Wisconsin +++++++++++++++++++++++++++ >From kn@doc.ic.ac.uk (Keng Ng) Date: 23 Aug 1994 11:46:16 GMT Organization: Imperial College, Dept. of Computing In article , peter.lewis@info.curtin.edu.au (Peter N Lewis) wrote: > >version.] Think Pascal is, quite simply, the nicest development > >environment for the Macintosh. *However* MW is catching up quick and > >Think isn't going anywhere ): [for a variety of technical and marketting > >reasons] So it'll only be a matter of time before MW wins. > > "a matter of time" likely being somewhere around about the end of the year > when Metrowerks have said they will have their pascal compiler both > supporting objects and compiling to PPC. ^^^^^^^ Does that mean that we'll be able to use it for MacApp 2.0.1 projects ? -Keng _________________________________________________________________ Keng T. Ng Email: kn@doc.ic.ac.uk Imperial College, Dept. of Computing, Phone: +44 71 594 8287 180 Queen's Gate, Fax: +44 71 581 8024 London SW7 2BZ, UK _________________________________________________________________ +++++++++++++++++++++++++++ >From quinn@cs.uwa.edu.au (Quinn "The Eskimo!") Date: Thu, 25 Aug 1994 11:30:54 +0800 Organization: Department of Computer Science, The University of Western Australia In article , kn@doc.ic.ac.uk (Keng Ng) wrote: >Does that mean that we'll be able to use it for MacApp 2.0.1 projects ? For PPC code? Unlikely without a lot of work. MacApp 2.0.1 is full of lots of skanky things that make taking it native tricky. Specifically: exception handling. -- Quinn "The Eskimo!" "Scout in a can. Simple, cheap, easy to use and it's expendable!" +++++++++++++++++++++++++++ >From peter.lewis@info.curtin.edu.au (Peter N Lewis) Date: Thu, 25 Aug 1994 12:38:05 +0800 Organization: NCRPDA, Curtin University In article , quinn@cs.uwa.edu.au (Quinn "The Eskimo!") wrote: >My personal favourite gotcha is the differences in the built-in string >function copy. MPW (and MW) returns '' if any of the parameters are out >of bounds whereas Think makes a best effort. > >eg copy('abcd', 3, 255) returns '' in MPW and MW and 'cd' in Think. Yeah, this is mind nummingly anoying (although not quite annoying as DR/2s behaviour of copy :-) function TPcopy (source: string; start, count: integer): string; var i: integer; begin if (start < 1) then begin count := count - (1 - start); start := 1; end; if start + count > length(source) then begin count := length(source) - start + 1; end; if count < 0 then begin count := 0; end; source[0] := chr(count); BlockMove(@source[start], @source[1], count); TPcopy := source; end; Non optiomal, but who cares? Enjoy, Peter. -- Peter N Lewis - Macintosh TCP fingerpainter +++++++++++++++++++++++++++ >From ingemar@lysator.liu.se (Ingemar Ragnemalm) Date: 28 Aug 1994 09:54:00 GMT Organization: (none) peter.lewis@info.curtin.edu.au (Peter N Lewis) writes: >>version.] Think Pascal is, quite simply, the nicest development >>environment for the Macintosh. *However* MW is catching up quick and >>Think isn't going anywhere ): [for a variety of technical and marketting >>reasons] So it'll only be a matter of time before MW wins. >"a matter of time" likely being somewhere around about the end of the year >when Metrowerks have said they will have their pascal compiler both >supporting objects and compiling to PPC. I doubt it. Even though PPC support is a strong point, they are so much behind in all other areas. No auto-indentation, not even on command. The debugger is a pain in the ass compared to Lightsbug - and where are Observe and Instant, my two favourite features? The debugger doesn't even seem to catch any errors to speak of. I hate when the program stops running, and the debugger says nothing, and I don't even know where it stopped. And the resource file is handled in the BRAIN-DAMAGED way that Think C used up to version 5. I hope they can make a decent product of it, but I can see my productivity going down... Back to the Lightspeed C days, when debugging took several times longer, since there were no decent debugger arund. -- - - Ingemar Ragnemalm, PhD Image processing, Mac shareware games E-mail address: ingemar@isy.liu.se or ingemar@lysator.liu.se +++++++++++++++++++++++++++ >From ingemar@lysator.liu.se (Ingemar Ragnemalm) Date: 28 Aug 1994 10:00:26 GMT Organization: (none) Vik_Rubenfeld@lamg.com (Vik Rubenfeld) writes: >Q> MW Pascal implements MPW Pascal, not Think Pascal. I've used both >Q> Think and MPW Pascal a lot and I know whether the differences lie. >Q> But there are lots of gotchas out there for hard-core Think Pascal >Q> users. Good luck. >Could you post a list describing some of the differences? Thanks in advance. Some obvious differences are that no managers are automatically used (thus, I'm building up a set of stuff to "uses" in all files - finding out exactly what standard managers to use is a pain), and initializations aren't automatic. All QuickDraw globals are in a "qd" record. -- - - Ingemar Ragnemalm, PhD Image processing, Mac shareware games E-mail address: ingemar@isy.liu.se or ingemar@lysator.liu.se +++++++++++++++++++++++++++ >From howarth@bromo.med.uth.tmc.edu (Jack W. Howarth) Date: 28 Aug 1994 18:28:52 GMT Organization: University of Texas Medical School In article <33pn7q$l5h@newsy.ifm.liu.se> ingemar@lysator.liu.se (Ingemar Ragnemalm) writes: > Some obvious differences are that no managers are automatically used (thus, > I'm building up a set of stuff to "uses" in all files - finding out exactly > what standard managers to use is a pain), and initializations aren't > automatic. All QuickDraw globals are in a "qd" record. Are you sure that some of your complaints are directed at the new Universal Headers from Apple and not MW Pascal itself? Jack W. Howarth, Ph.D. Univ. of Texas Medical School Research Fellow P.O. Box 20708 Department of Biochemistry Houston, Texas 77225 +++++++++++++++++++++++++++ >From peter.lewis@info.curtin.edu.au (Peter N Lewis) Date: Mon, 29 Aug 1994 10:10:52 +0800 Organization: NCRPDA, Curtin University >Some obvious differences are that no managers are automatically used (thus, >I'm building up a set of stuff to "uses" in all files - finding out exactly >what standard managers to use is a pain), and initializations aren't ObiWan will tell you which unit to include for a given procedure. I have the same problem, but a few compiles and it's fixed. Also, you can use stuff like this: {$IFC undefined THINK_Pascal} uses Events; {$ENDC} To avoid having to include all the dummy unix in THINK Pascal. Peter. -- Peter N Lewis - Macintosh TCP fingerpainter --------------------------- >From chrism@col.hp.com (Chris Magnuson) Subject: Items in system menu bar Date: 17 Aug 1994 20:17:44 GMT Organization: HP Colorado Springs Division I was reading about the Menu Manager last night, trying to figure out how to stick icons in the Finder's menu bar (right up there next to the balloon, for example). Anyone have any ideas on how to do this? Is this considered Menu #0 and you just GetMenuHandle() on that? Hmm. Any hints would be appreciated. Thanks, Chris Magnuson chrism@col.hp.com +++++++++++++++++++++++++++ >From spencerl@crl.com (Spencer Low) Date: Wed, 17 Aug 1994 15:33:08 -0800 Organization: LowTek Creations In article <32tr98$pfg@hp-col.col.hp.com>, chrism@col.hp.com (Chris Magnuson) wrote: > I was reading about the Menu Manager last night, trying to figure out > how to stick icons in the Finder's menu bar (right up there next to > the balloon, for example). Anyone have any ideas on how to do this? > Is this considered Menu #0 and you just GetMenuHandle() on that? If you want to install a System Menu (i.e. ColorSwitch, OtherMenu, Help menu, Application menu, etc.), check out the "star-menu" source at UMICH. Or read up on TSM menus in Inside Mac: Text. Spencer +++++++++++++++++++++++++++ >From Jens Alfke Date: Thu, 25 Aug 1994 00:27:15 GMT Organization: Apple Computer Chris Magnuson, chrism@col.hp.com writes: > I was reading about the Menu Manager last night, trying to figure out > how to stick icons in the Finder's menu bar (right up there next to > the balloon, for example). Anyone have any ideas on how to do this? > Is this considered Menu #0 and you just GetMenuHandle() on that? There are really two things you want: (1) How to give a menu an icon as a title. Simple: It has to have a five character name, of which the first byte is '\01' (Ascii 01) and the other four are a handle to an icon suite. Needless to say, don't dispose the icon suite before the menu goes away. (2) How to put a menu on the right side of the menu bar. There's a particular range of negative menu IDs that signal a system menu; if you add a menu with such an ID it automatically goes on the right side, and it automatically will be added to the menu bar of every app that's launched. This means it's best to install such menus as soon as the menu bar first comes up; e.g. by patching DrawMenuBar. Make sure you load the icon into the System heap, of course, otherwise it'll be disposed when the current app quits. I believe there is sample code somplace showing how to do this. Disclaimer: None of this stuff is supported by Apple (though it's cool) and these techniques may break in the future. --Jens Alfke jens_alfke@powertalk.apple.com "A man, a plan, a yam, a can of Spam ... Bananama!" +++++++++++++++++++++++++++ >From rollin@newton.apple.com (Keith Rollin) Date: Sun, 28 Aug 1994 18:39:36 -0800 Organization: Apple ][ -> Mac -> Taligent -> Newton -> Windows? In article <32tr98$pfg@hp-col.col.hp.com>, chrism@col.hp.com (Chris Magnuson) wrote: > I was reading about the Menu Manager last night, trying to figure out > how to stick icons in the Finder's menu bar (right up there next to > the balloon, for example). Anyone have any ideas on how to do this? > Is this considered Menu #0 and you just GetMenuHandle() on that? The following tips concerning being compatible with future Mac OSes were distributed (I think) at the last WWDC: 7. Extensions that try to modify menus in applications without their knowledge will no longer work. 8. Extensions that install menus in the system portion of the menu bar will break if they access Menu Manager data without using the Menu Manager API. 9. Extensions that augment or override the behavior of the Apple menu (like adding hierarchical menus) will break. That said, here's an INIT written by someone in Mac DTS that does what you're asking. Given the above warnings, I would consider the following hack to be unsupported, but about as best as you can do given today's Toolbox API. ; Sample INIT that puts up a system wide menu and installs a handler for it. ; The general idea of this is that it waits for the system to install a system menu and then ; when that menu is installed it installs its own menu. The patch to SystemMenu is what is ; used to determine what to do when an item is selected. ; ; Use the following MPW commands to build the INIT: ; ; asm SampleINIT.a -o SampleINIT.a.o ; Link -o SampleINIT -rt INIT=128 -ra Main=resSysHeap -t INIT SampleINIT.a.o ; duplicate SampleINIT "{SystemFolder}Extensions:aSampleINIT" ; ; Hack courtesy of Apple Developer Tech Support ; Change History: ; 12/10/93 JLM Created the INIT and made items beep with sysbeep ; PRINT PUSH,OFF ; don't print any of this stuff INCLUDE 'ToolEqu.a' INCLUDE 'Traps.a' INCLUDE 'PackMacs.a' INCLUDE 'QuickEqu.a' INCLUDE 'SysEqu.a' PRINT POP ; restore the PRINT options theStub proc Export Import ENTRY bra ENTRY EndP MyGlobals Record 0 OldInsertMenu ds.L 1 OldSystemMenu ds.L 1 MyMenuHand ds.L 1 MyMenuID ds.W 1 EndR tenderID equ $BF99 ; this looks like a good start Globals proc Export ds MyGlobals Export MyMenuStr MyMenuStr dc 'Item1;Item2' ; Export MyMenuTitle MyMenuTitle dc 'SMU' ; and our menu EndP MyInsertMenu proc Export InsMenuFrame Record {xA6Link},DECR xParmBegin equ * theMenu ds.L 1 before ds.W 1 xParmSize equ xParmBegin-* xRetAddr ds.L 1 xJumpThru ds.L 1 ; store the real address here on stack for unwinding xA6Link ds.L 1 * Insert local vars here ZoneSave ds.L 1 xLocalSize equ * endr with InsMenuFrame,MyGlobals clr.L -(sp) ; for the return address of this routine LINK A6,#xLocalSize movem.L D0-D2/A0-A4,-(sp) ; save these temp registers lea Globals,A4 ; get our globals pointer so we can test further move.L theMenu(A6),A0 ; get the menu handle being installed move.L (A0),A0 ; deref it tst.W (A0) ; see if its a system menu bpl.s @IgnorePatch ; if so ignore the patch stuff move.W MyMenuID(A4),D0 tst.W D0 ; see if we are installed yet... beq.s @InstallMe ; nope better install ourselves first cmp.W (A0),D0 ; see if our menu has the same ID as this menu bne.s @IgnorePatch ; it does not, we can leave now @IDConflict ; if we get here the system menu ID number we have choosen is in conflict with a system menu ; used by the system. We could try to change our number or bail out. I choose bailing out ; for this example. The proper thing to do might be to examine the menu list and try a different ; number. move.W MyMenuID(A4),-(sp) ; first delete the menu from the menu bar _DeleteMenu ; ok now the menu is deleted move.W #1,MyMenuID(A4) ; and reset our menu ID to not ever be a system menu but be non-zero move.L MyMenuHand(A4),-(sp) _DisposeMenu ; and dump the menu itself move.L #1,MyMenuHand(A4) ; and zots the menu handle as well bra.s @ignorePatch ; and exit @InstallMe move.L theZone,zoneSave(A6) move.L SysZone,A0 _SetZone ; insure that the new menu goes into the system heap clr.L -(sp) ; first create our menu move.W #tenderID,-(sp) ; move our projected ID on the stack pea MyMenuTitle ; and push our title pointer _NewMenu move.L (sp),MyMenuHand(A4) ; set up our menu handle in memory pea MyMenuStr _AppendMenu ; now we have built us a menu move.W #tenderID,MyMenuID(A4) move.L zoneSave(A6),A0 _SetZone ; switch back to the app heap move.L MyMenuHand(A4),-(sp) move.W #tenderID,-(sp) move.L OldInsertMenu(A4),A0 jsr (A0) ; call the real insert menu to insert us ; ok, now we are inserted and we will work just fine... ; @ignorePatch ; dummy up the stack to have the address of the real patch so's I can use RTS to jump to ; the real patch instead of A0 move.L OldInsertMenu(A4),xJumpThru(A6) movem.L (sp)+,D0-D2/A0-A4 ; restore the stack unlk A6 ; and A6 rts ; now call back the original EndP MySystemMenu proc Export InsMenuFrame Record {xA6Link},DECR xParmBegin equ * theItem ds.W 1 theMenuID ds.W 1 xParmSize equ xParmBegin-* xRetAddr ds.L 1 xJumpThru ds.L 1 ; store the real address here on stack for unwinding xA6Link ds.L 1 * Insert local vars here xLocalSize equ * EndR with InsMenuFrame,MyGlobals clr.L -(sp) ; for the return address of this routine LINK A6,#xLocalSize movem.L D0-D2/A0-A4,-(sp) ; save these temp registers lea Globals,A4 ; get our globals pointer so we can test further move.W theMenuID(A6),D0 cmp.W MyMenuID(A4),D0 ; see if its our menu bne.s @ignorePatch ; if not simply call thru to he other side ; else this is our menu, for right now we will simply beep at the user move.L #$00050005,-(sp) ; set up to beep twice _Sysbeep _SysBeep ; and since we handled the menu we will now return to the caller movem.L (sp)+,D0-D2/A0-A4 ; restore the stack unlk A6 ; and A6 addQ.L #4,sp ; remove the long we pushed on the stack earlier move.L (sp)+,(sp) ; and remove the return address and place it on top of the parms rts ; and return to our regularly scheduled app. @ignorePatch ; dummy up the stack to have the address of the real patch so's I can use RTS to jump to ; the real patch instead of A0 move.L OldSystemMenu(A4),xJumpThru(A6) movem.L (sp)+,D0-D2/A0-A4 ; restore the stack unlk A6 ; and A6 rts ; now call back the original EndP ENTRY proc export With MyGlobals _Debugger ; enter the debugger so's I can test this stuff out movem.L A0-A5/D0-D7,-(sp) ; save regs to be safe lea Globals,A4 ; set up our globals move.L SysZone,A0 _SetZone lea theStub,A0 ; now get our handle detach and lock it down its already _RecoverHandle ; in the system heap move.L A0,-(sp) _DetachResource ; and detach the bad boy... Move.W #$A935,D0 ; now insert my patch to InsertMenu $A935 _GetTrapAddress move.L A0,OldInsertMenu(A4) lea MyInsertMenu,A0 Move.W #$A935,D0 _SetTrapAddress Move.W #$A9B5,D0 ; now insert my patch to SystemMenu $A9B5 _GetTrapAddress move.L A0,OldSystemMenu(A4) lea MySystemMenu,A0 Move.W #$A9B5,D0 _SetTrapAddress moveQ #0,D0 move.W D0,MyMenuID(A4) Move.L D0,MyMenuHand(A4) move.L ApplZone,A0 _SetZone movem.L (sp)+,A0-A5/D0-D7 ; save regs to be safe rts EndP End - -------------------------------------------------------------------------- Keith Rollin --- Phantom Programmer --- Apple Computer, Inc. --- Team Newton --------------------------- >From zorro@cats.ucsc.edu (zorro) Subject: Text searches. Date: 16 Aug 1994 17:52:29 GMT Organization: University of California; Santa Cruz Constantly I find myself in the situation that Dina described... not knowing where to look for a particulat #define, variable, or function. So what I end up doing is uploading whole directories to my trusty Sparc and using the 'grep' command. I realize this is wrong on a very basic level and so what I want to ask is, does anyone know of an MPW Tool that duplicates the functionality of 'grep'? I could write one myself, all it would have to do is look through .c and .h files for a text pattern, but I would prefer it if I didn't have to. So, has anyone out there implemented 'grep'?? - Dan +++++++++++++++++++++++++++ >From mcrawfor@bio.ri.ccf.org (Mike Crawford) Date: Tue, 16 Aug 1994 19:08:16 GMT Organization: The Cleveland Clinic Foundation In article 2pg@darkstar.UCSC.EDU, zorro@cats.ucsc.edu (zorro) writes: > > >Constantly I find myself in the situation that Dina described... not knowing >where to look for a particulat #define, variable, or function. >So what I end up doing is uploading whole directories to my trusty Sparc >and using the 'grep' command. I realize this is wrong on a very basic level >and so what I want to ask is, does anyone know of an MPW Tool that duplicates >the functionality of 'grep'? >I could write one myself, all it would have to do is look through .c and .h >files for a text pattern, but I would prefer it if I didn't have to. > >So, has anyone out there implemented 'grep'?? > >- Dan > MPW  has a tool called 'search' which functions just like the 'grep' command. Ex. search "Str255" {CIncludes}*.h // searches all .h files in the current directory for // any occurance of 'Str255' ****  NOTE, the wildcard character is not an asterisk, it's a double skwiggly line and can be created by the option-x key combination... I just couldn't duplicate it in this message. Sorry for the crudity of my example. the search command is very useful... I use it daily good luck mwc - ---------- Internet: mcrawfor@bio.ri.ccf.org AOL: Marlin89@aol.com eWorld: Marlin89@eworld.com - ---------- "And the people all said, "Sit down!" your rockin the boat..." - ---------- +++++++++++++++++++++++++++ >From siegel@netcom.com (Rich Siegel) Date: Tue, 16 Aug 1994 23:01:36 GMT Organization: Bare Bones Software In article <32quct$2pg@darkstar.UCSC.EDU> zorro@cats.ucsc.edu (zorro) writes: >So what I end up doing is uploading whole directories to my trusty Sparc >and using the 'grep' command. I realize this is wrong on a very basic level >and so what I want to ask is, does anyone know of an MPW Tool that duplicates >the functionality of 'grep'? > >So, has anyone out there implemented 'grep'?? Time to read the fine manual, particularly the chapter which describes the "Search" tool. The MPW intrinsic "Help" has also proven safe and effective when used as directed, particularly when combined with the words "Expressions" and "Search". R. -- Rich Siegel % siegel@netcom.com % President & CEO, Bare Bones Software Inc. --> For information about BBEdit, finger bbedit@world.std.com <-- +++++++++++++++++++++++++++ >From bobo@reed.edu (Eric Bowman) Date: 17 Aug 1994 03:56:27 GMT Organization: Reed College, Portland, Oregon In article <32quct$2pg@darkstar.ucsc.edu>, zorro wrote: >Constantly I find myself in the situation that Dina described... not knowing >where to look for a particulat #define, variable, or function. >So what I end up doing is uploading whole directories to my trusty Sparc >and using the 'grep' command. I realize this is wrong on a very basic level >and so what I want to ask is, does anyone know of an MPW Tool that duplicates >the functionality of 'grep'? >I could write one myself, all it would have to do is look through .c and .h >files for a text pattern, but I would prefer it if I didn't have to. Well, "Search" has all the functionality of "grep", except it uses MPW's regular expression syntax instead of unix's. Other than that, though, it works great; better, even, than grep since it's so easy to jump to the results of the search by double-clicking lines spewed out by search. I just used it to do a very nasty search: I needed to "touch" every source file with an ASSERT, Debugger, or DebugStr (just got ETO 15!)...to do this you need only do the following: setfile -m . \d `grep -s /[AD][Se][Sb][Eu][Rg][TSg][te]*[r]*\d(/ \x.cp | \d streamedit -d -e '/File \d"(\x)\r1\d"\d;/ print \r1' | \d sort -unique` where \d = option-d \r = option-r \x = option-x Oh yeah, I have search aliased as "grep" :) Just try and do *that* in any other IDE... cheers, bobo +++++++++++++++++++++++++++ >From Bruce@hoult.actrix.gen.nz (Bruce Hoult) Date: Wed, 17 Aug 1994 15:26:30 +1200 (NZST) Organization: (none) zorro@cats.ucsc.edu (zorro) writes: > Constantly I find myself in the situation that Dina described... not knowing > where to look for a particulat #define, variable, or function. > So what I end up doing is uploading whole directories to my trusty Sparc > and using the 'grep' command. I realize this is wrong on a very basic level > and so what I want to ask is, does anyone know of an MPW Tool that duplicates > the functionality of 'grep'? > I could write one myself, all it would have to do is look through .c and .h > files for a text pattern, but I would prefer it if I didn't have to. What's wrong with "search"? Name too obscure, or something? search CloseWindow "{cincludes}"Å.h -- Bruce +++++++++++++++++++++++++++ >From zstern@adobe.com (Zalman Stern) Date: Wed, 17 Aug 1994 07:57:22 GMT Organization: Adobe Systems Incorporated writes > zorro@cats.ucsc.edu (zorro) writes: > > Constantly I find myself in the situation that Dina described... not knowing > > where to look for a particulat #define, variable, or function. > > So what I end up doing is uploading whole directories to my trusty Sparc > > and using the 'grep' command. I realize this is wrong on a very basic level > > and so what I want to ask is, does anyone know of an MPW Tool that duplicates > > the functionality of 'grep'? > > I could write one myself, all it would have to do is look through .c and h > > files for a text pattern, but I would prefer it if I didn't have to. > > What's wrong with "search"? Name too obscure, or something? There is a port of the GNU grep command to MPW. I picked it up off ftp.apple.com a year or two ago. Its faster and has more functionality than search. The Mac is still relatively slow at this sort of thing compared to a decent UNIX box though. -- Zalman Stern zalman@adobe.com (415) 962 3824 Adobe Systems, 1585 Charleston Rd., POB 7900, Mountain View, CA 94039-7900 It seems like once people grow up, they have no idea what's cool. - Calvin +++++++++++++++++++++++++++ >From Bruce@hoult.actrix.gen.nz (Bruce Hoult) Date: Thu, 18 Aug 1994 03:11:36 +1200 (NZST) Organization: (none) zstern@adobe.com (Zalman Stern) writes: > There is a port of the GNU grep command to MPW. I picked it up off > ftp.apple.com a year or two ago. Its faster and has more functionality than > search. The Mac is still relatively slow at this sort of thing compared to a > decent UNIX box though. "search" used to be slow. I wrote my own tool to search for literal strings and it ran at 1.5 MB/sec on a Q700 with Quantum LPS240 HD, searching 40 MB of 200K files, while "search" ran at 300 KB/sec or so. Then, a year or two ago, I got a new version of MPW and the search ran at the same 1.5 MB/sec as my simple program did. I've gone back to MPW Search ever since. -- Bruce +++++++++++++++++++++++++++ >From becker@Xenon.Stanford.EDU (Denizen of the Deep) Date: 17 Aug 1994 16:35:59 GMT Organization: Computer Science Department, Stanford University. In article <32quct$2pg@darkstar.UCSC.EDU>, zorro wrote: > > >Constantly I find myself in the situation that Dina described... not knowing >where to look for a particulat #define, variable, or function. >So what I end up doing is uploading whole directories to my trusty Sparc >and using the 'grep' command. I realize this is wrong on a very basic level >and so what I want to ask is, does anyone know of an MPW Tool that duplicates >the functionality of 'grep'? >I could write one myself, all it would have to do is look through .c and .h >files for a text pattern, but I would prefer it if I didn't have to. > >So, has anyone out there implemented 'grep'?? > >- Dan > If you are working in MPW, there are tools you can use to accomplish the same effect (though it's not as nice as grep IMHO). The "files" tool will list all the files in the specified directory, while the "search" tool will search all the given files for the specified pattern. In my worksheet, I have the following line marked as "Search in includes": search -s /Gestalt/ `files -o -f -t TEXT "{mpw}"Interfaces:CIncludes` This will search through all the MPW C header files for the given pattern. In this case, it is searching for Gestalt. To search for something else, just change what's inside the '/' delimiters. To search a different directory, replace the "{mpw}"Interfaces:Cincludes with the directory of your choice. You can also specify the -r option to the files tool, which will make the search recursively descend into subdirectories. Hope that helps. -Jon +++++++++++++++++++++++++++ >From timothys@hood.uucp (Timothy Sherburne) Date: 17 Aug 94 16:37:32 GMT Organization: University of Portland Bruce@hoult.actrix.gen.nz (Bruce Hoult) writes: >zorro@cats.ucsc.edu (zorro) writes: >> Constantly I find myself in the situation that Dina described... not knowing >> where to look for a particulat #define, variable, or function. >> So what I end up doing is uploading whole directories to my trusty Sparc >> and using the 'grep' command. I realize this is wrong on a very basic level >> and so what I want to ask is, does anyone know of an MPW Tool that duplicates >> the functionality of 'grep'? >> I could write one myself, all it would have to do is look through .c and .h >> files for a text pattern, but I would prefer it if I didn't have to. >What's wrong with "search"? Name too obscure, or something? > search CloseWindow "{cincludes}"Å.h >-- Bruce All these suggestions to use the "search" tool are fine, but you can also install the "poptag" tool (found on the May '94 Tool Chest CD, but I couldn't find it on ETO 15 :( It works like this: highlight some function name, etc. and type cmd-P. The definition will be given. Works well IF you've got some extra space on your HD and the time to install it. t -- | Timothy Sherburne | Software Engineer | | Internet: timothys@uofport.edu | Prometheus Products, Inc. | | AppleLink: D6164@applelink.apple.com | 1-800-477-3473 | *All comments are my own and in no way represent those of Prometheus Products* +++++++++++++++++++++++++++ >From sw@network-analysis-ltd.co.uk (Sak Wathanasin) Date: Thu, 18 Aug 94 10:35:34 BST Organization: Network Analysis Ltd In article <1994Aug17.075722.17513@adobe.com> (comp.sys.mac.programmer), zstern@adobe.com (Zalman Stern) writes: > There is a port of the GNU grep command to MPW. I picked it up off > ftp.apple.com a year or two ago. Its faster and has more functionality than > search. The Mac is still relatively slow at this sort of thing compared to a > decent UNIX box though. There's also "agrep" which is very fast; can't remember where I got this from, but I can post to macgifts if people want it. Unfortunately, it doesn't generate MPW-executable output like "Search", but it's dead useful just for seeing which header file contains which definition. Sak Wathanasin Network Analysis Limited 178 Wainbody Ave South, Coventry CV3 6BX, UK Internet: sw@network-analysis-ltd.co.uk uucp: ...!uknet!nan!sw AppleLink: NAN.LTD Phone: (+44) 203 419996 Mobile:(+44) 850 587411 Fax: (+44) 203 690690 +++++++++++++++++++++++++++ >From lsr@taligent.com (Larry Rosenstein) Date: Fri, 19 Aug 1994 17:30:55 GMT Organization: Taligent, Inc. In article , sw@network-analysis-ltd.co.uk wrote: > There's also "agrep" which is very fast; can't remember where I got > this from, but I can post to macgifts if people want it. Unfortunately, If it's the same one I'm thinking of, then this is a fast string searcher that allows for errors in the text (ie, it's more of a fuzzy match). The information I have says the source is available at ftp://cs.arizona.edu/agrep/. -- Larry Rosenstein Taligent, Inc. lsr@taligent.com +++++++++++++++++++++++++++ >From hammett@sbsu1.auckland.ac.nz (Tim Hammett) Date: 20 Aug 1994 23:25:41 GMT Organization: University of Auckland becker@Xenon.Stanford.EDU (Denizen of the Deep) writes: >search -s /Gestalt/ `files -o -f -t TEXT "{mpw}"Interfaces:CIncludes` Why not use: search -s /Gestalt/ "{CIncludes}=.h" (where = is option-x, i.e. the squiggly equals sign) -- Tim Hammett, School of Biological Sciences, Auckland University, New Zealand. t.hammett@auckland.ac.nz Phone: +64-9-373-7599 x7298 FAX: +64-9-373-7416 +++++++++++++++++++++++++++ >From rollin@newton.apple.com (Keith Rollin) Date: Wed, 24 Aug 1994 13:38:37 -0800 Organization: Apple ][ -> Mac -> Taligent -> Newton -> Windows? In article <32te9f$goj@Times.Stanford.EDU>, becker@Xenon.Stanford.EDU (Denizen of the Deep) wrote: > >If you are working in MPW, there are tools you can use to accomplish the >same effect (though it's not as nice as grep IMHO). I have a question for you, Jon: What does "grep" do that makes it so much nicer than "search"? >The "files" tool >will list all the files in the specified directory, while the "search" >tool will search all the given files for the specified pattern. > >In my worksheet, I have the following line marked as "Search in includes": > >search -s /Gestalt/ `files -o -f -t TEXT "{mpw}"Interfaces:CIncludes` > >This will search through all the MPW C header files for the given pattern. >In this case, it is searching for Gestalt. To search for something else, >just change what's inside the '/' delimiters. To search a different >directory, replace the "{mpw}"Interfaces:Cincludes with the directory >of your choice. You can also specify the -r option to the files tool, >which will make the search recursively descend into subdirectories. Geeze, you make it look so difficult. I simply use: search Gestalt "{CIncludes}" Actually, I fibbed. I never do that. I just select the item in my Edit menu that lets me search a common directory. In my UserStarup*Keith file, I have: Set FabFolders "`quote '{CIncludes}' '{PInterfaces}' '{AIncludes}' '{RIncludes}' '{MACPlusIncludes}' '{MALibraries}' '{MPWCustom}Scripts:' '{MPW}Scripts:' `" For f in {FabFolders} AddMenu "Find" "Search in {f}" "SearchIn "{f}" "{WorkSheet}"" End "SearchIn" is the following script: Set Expr "`Request 'Enter regular expression' || Echo ''`" Exit If "{Expr}" == "" open "{WorkSheet}" if "{expr}" =~ /[a-z0-9]+/ Search "{Expr}" "{1}" else Search /{Expr}/ "{1}" end - -------------------------------------------------------------------------- Keith Rollin --- Phantom Programmer --- Apple Computer, Inc. --- Team Newton +++++++++++++++++++++++++++ >From rollin@newton.apple.com (Keith Rollin) Date: Thu, 25 Aug 1994 16:06:09 -0800 Organization: Apple ][ -> Mac -> Taligent -> Newton -> Windows? In article , sw@network-analysis-ltd.co.uk wrote: >In article <1994Aug17.075722.17513@adobe.com> (comp.sys.mac.programmer), zstern@adobe.com (Zalman Stern) writes: > >> There is a port of the GNU grep command to MPW. I picked it up off >> ftp.apple.com a year or two ago. Its faster and has more functionality than >> search. The Mac is still relatively slow at this sort of thing compared to a >> decent UNIX box though. > >There's also "agrep" which is very fast; can't remember where I got >this from, but I can post to macgifts if people want it. Unfortunately, >it doesn't generate MPW-executable output like "Search", but it's dead >useful just for seeing which header file contains which definition. I got a copy, dated Jan 1992, from cs.arizona.edu as agrep/agrep-2.04.tar. Comes with source. I haven't tried it though. - -------------------------------------------------------------------------- Keith Rollin --- Phantom Programmer --- Apple Computer, Inc. --- Team Newton +++++++++++++++++++++++++++ >From rollin@newton.apple.com (Keith Rollin) Date: Sun, 28 Aug 1994 18:21:13 -0800 Organization: Apple ][ -> Mac -> Taligent -> Newton -> Windows? In article <3363dl$sil@ccu2.auckland.ac.nz>, hammett@sbsu1.auckland.ac.nz (Tim Hammett) wrote: >becker@Xenon.Stanford.EDU (Denizen of the Deep) writes: >>search -s /Gestalt/ `files -o -f -t TEXT "{mpw}"Interfaces:CIncludes` > >Why not use: > >search -s /Gestalt/ "{CIncludes}=.h" > >(where = is option-x, i.e. the squiggly equals sign) Using the following is much faster: search -s Gestalt "{CIncludes}=.h" The reason for this is that delimiting the search string with slashes tells the Shell to perform a regular expression search. But the Shell can also perform faster searches using a Boyer-Moore algorithm when it thinks it's OK. Right now, the only way it can tell this is when you feed it a straight string. It would be nice if the searching routines would look in the slashes and determine if it can use a Boyer-Moore search, but that's not the way it works right now. - -------------------------------------------------------------------------- Keith Rollin --- Phantom Programmer --- Apple Computer, Inc. --- Team Newton --------------------------- >From rmartin@luddites.tiac.net (Rich Martin) Subject: Ticks (was: Clover+. interrupt?) Date: Mon, 29 Aug 1994 14:58:16 -0500 Organization: Luddite Softwerks PMJI, but this Ticks thing still haunts me. A project I worked on recently was real-time intensive, and I assumed that Ticks would be incremented every 1/60th second. IM told me that this was not guaranteed to happen every time, but my assumption was that I would get no *more* than 60 ticks in a second. All my time measurements went haywire. After much hair pulling, we did some empirical tests and discovered that we were getting something like 3605 ticks per minute. Yow! Slightly more than 60 ticks per second! Over the course of 30 minutes, my program behaved as though it were late when it actually was not. Once we accounted for this unexpected Tick rate, timing improved sufficiently. Comments? -- ____________________________________________________________________ http://www.mps.ohio-state.edu/cgi-bin/hpp?RichMartin.html | Not | __________________________________________________________| Insane! | It's Easy to be Easy when You're Easy... |_________| +++++++++++++++++++++++++++ >From michael.martz@aldus.com (Michael Martz) Date: 29 Aug 1994 20:41:40 GMT Organization: Aldus Corporation, Seattle, WA USA I had the very same thing happen to me a while ago. I set up code using the time manager to count the number of ticks per second expecting to find 55-60. When it turned out that I was getting 60+, I double checked everything and then compared it to an external timing source. I concluded that IM was incorrect. I don't know why this occurs, but rest assured you are sane. For periods around 30 minutes you really should be using the new Time Manger rather than Ticks. _______________________________________________________________________ Michael Martz michael.martz@aldus.com Aldus Corp. +++++++++++++++++++++++++++ >From spector@bach.seattleu.edu (Mitchell S. Spector) Date: 30 Aug 1994 09:24:58 -0700 Organization: Seattle University, Seattle, Washington, U.S.A. In article , Rich Martin wrote: >PMJI, but this Ticks thing still haunts me. A project I worked on recently >was real-time intensive, and I assumed that Ticks would be incremented >every 1/60th second. IM told me that this was not guaranteed to happen >every time, but my assumption was that I would get no *more* than 60 ticks >in a second. All my time measurements went haywire. After much hair >pulling, we did some empirical tests and discovered that we were getting >something like 3605 ticks per minute. Yow! Slightly more than 60 ticks per >second! Over the course of 30 minutes, my program behaved as though it >were late when it actually was not. Once we accounted for this unexpected >Tick rate, timing improved sufficiently. Comments? I know IM says in various places that a tick is 1/60 of a second. But, according to the discussion of the video interface in IM vol. III, the vertical scan rate of the original Macintosh monitor was 60.15 Hz, not 60 Hz. I presume this implies that VBL interrupts were generated every 1/60.15 sec, a little faster than 1/60 sec. This would mean that there were 3609 ticks per minute. I have no idea if Apple has maintained compatibility with the original Mac to the point of generating VBL interrupts at exactly the same frequency as on the original Mac. But I take all this to mean that Apple does not guarantee the exact frequency of the VBL interrupt, and that no program should use ticks for exact timing. The Time Manager should be used for that. >-- >____________________________________________________________________ >http://www.mps.ohio-state.edu/cgi-bin/hpp?RichMartin.html | Not | >__________________________________________________________| Insane! | > It's Easy to be Easy when You're Easy... |_________| -- Mitchell Spector Dept. of Computer Science and Software Engineering Seattle University E-mail: spector@seattleu.edu +++++++++++++++++++++++++++ >From h+@nada.kth.se (Jon W{tte) Date: Tue, 30 Aug 1994 20:33:13 +0200 Organization: Royal Institute of Something or other In article , rmartin@luddites.tiac.net (Rich Martin) wrote: >were late when it actually was not. Once we accounted for this unexpected >Tick rate, timing improved sufficiently. Comments? Yeah, there are 60.15 ticks per second. This is documented. What you should do is use the NewImprovedREALLYDriftFreeTimeManager to install a ReallyDriftFree TimeManager task that increments a variable. The plus side of this is that you get to set the interval of the "ticks" Cheers, / h+ -- Jon Wätte (h+@nada.kth.se), Hagagatan 1, 113 48 Stockholm, Sweden Reality exists only in your imagination. +++++++++++++++++++++++++++ >From radixinc@aol.com (RadixInc) Date: 30 Aug 1994 18:16:06 -0400 Organization: America Online, Inc. (1-800-827-6364) In article <33vmgq$sqi@bach.seattleu.edu>, spector@bach.seattleu.edu (Mitchell S. Spector) writes: <> Apple has maintained compatibility; regardless of the actual monitor frequency, a "VBL" interrupt is synthesized, supposedly at the original 60.15/sec rate. As others have mentioned using the Ticks/VBL mechanism for accurate timing is not advised, because (a) the frequency is not guaranteed, and (b) VBL tasks (and updating Ticks) don't happen while interrupts are disabled. Gregory Jorgensen Radix Consulting Inc. --------------------------- >From tfullert@bottom.magnus.acs.ohio-state.edu (tfullert) Subject: What is the point of MPW? Date: 13 Aug 1994 15:39:41 GMT Organization: The Ohio State University Hi: I was given a copy of MPW 3.3 (not pirated, I was given all of the materials in the huge box),and have the current shell from CodeWarrior. I am doing all of my own work on CodeWarrior and I want to devote some energy to learning MPW. What priority should I give this, though. Exactly what can I do with MPW which I cannot do with CodeWarrior or SC++? Thanks; Tim +++++++++++++++++++++++++++ >From nagle@netcom.com (John Nagle) Date: Sat, 13 Aug 1994 20:06:23 GMT Organization: NETCOM On-line Communication Services (408 261-4700 guest) tfullert@bottom.magnus.acs.ohio-state.edu (tfullert) writes: >I was given a copy of MPW 3.3 (not pirated, I was given all of the >materials in the huge box),and have the current shell from CodeWarrior. > I am doing all of my own work on CodeWarrior and I want to devote some >energy to learning MPW. What priority should I give this, though. >Exactly what can I do with MPW which I cannot do with CodeWarrior or >SC++? The MPW compilers are so out-of-date that unless you have old software developed under MPW you need to maintain, don't bother. MPW is basically a UNIX-like command line oriented environment, under which you can run various UNIX-like tools. It's useful if you need to build UNIX-like tools to process data as part of your program-building process. MPW dates from when the Mac could only run one program at a time, and it has its own hack for running "MPW tools" under its own shell. John Nagle +++++++++++++++++++++++++++ >From mclow@san_marcos.csusm.edu (Marshall Clow) Date: Sat, 13 Aug 1994 13:53:09 -0800 Organization: Aladdin Systems In article <32ipft$18t@charm.magnus.acs.ohio-state.edu>, tfullert@bottom.magnus.acs.ohio-state.edu (tfullert) wrote: > Hi: > > I was given a copy of MPW 3.3 (not pirated, I was given all of the > materials in the huge box),and have the current shell from CodeWarrior. > I am doing all of my own work on CodeWarrior and I want to devote some > energy to learning MPW. What priority should I give this, though. > Exactly what can I do with MPW which I cannot do with CodeWarrior or > SC++? > Try this in CodeWarrior (or Think, for that matter). Build an application containing 4 LDEFs, 2 MDEFs, 3 WDEFs, as well as 12 plug in tools, putting the 'CODE' resources and the xDEF resources in a file of type 'APPL', while each of the tools goes in a seperate file. Don't forget to put the build date (and time) into the 'vers' resource so that testers can tell exactily what they have. After you have built the application, compress the resources in the application. Oh yes, do this by choosing a single menu option. -- Marshall Clow Aladdin Systems mclow@san_marcos.csusm.edu +++++++++++++++++++++++++++ >From afcjlloyd@aol.com (AFC JLloyd) Date: 13 Aug 1994 16:59:05 -0400 Organization: America Online, Inc. (1-800-827-6364) In article , nagle@netcom.com (John Nagle) writes: >tfullert@bottom.magnus.acs.ohio-state.edu (tfullert) writes: >>I was given a copy of MPW 3.3 (not pirated, I was given all of the >>materials in the huge box),and have the current shell from CodeWarrior. >> I am doing all of my own work on CodeWarrior and I want to devote some >>energy to learning MPW. What priority should I give this, though. >>Exactly what can I do with MPW which I cannot do with CodeWarrior or >>SC++? > > The MPW compilers are so out-of-date that unless you have old >software developed under MPW you need to maintain, don't bother. > > MPW is basically a UNIX-like command line oriented environment, >under which you can run various UNIX-like tools. It's useful if you >need to build UNIX-like tools to process data as part of your >program-building process. MPW dates from when the Mac could only run >one program at a time, and it has its own hack for running "MPW tools" >under its own shell. Although I agree a little with John Nagle's intent, I strongly disagree with his message. Although I use Think and CodeWarrior more than MPW, MPW is still my preferred development environment when working on large projects. The best thing about TPM and CodeWarrior is that they remove the need for make files. On small and medium sized projects, and even large projects where only a single application is to be built, the ability to let the environment deal with dependencies is a real blessing. The worst thing about TPM and CodeWarrior is that remove the ability to use custom make files. On large projects where many loosely related components must be built, the project-based environments are a pain. Maybe someday these enviroments will properly support subprojects or makefiles, but until then, MPW is still superior for this kind of development. As to the MPW compilers being out of date, I suppose this is true if by "MPW compilers" you mean Apple's C, Pascal, and CFront. However, both Symantec and Metrowerks have provided their compilers as MPW tools, and the hybrid MrC available on ETO 15 looks like it may be a real winner (I've only been using it for a couple days, so it's too soon for me to say). Jim Lloyd afcjlloyd@aol.com +++++++++++++++++++++++++++ >From hanrek@cts.com (Mark Hanrek) Date: Sat, 13 Aug 1994 15:10:32 -0800 Organization: The Information Workshop In article <32ipft$18t@charm.magnus.acs.ohio-state.edu>, tfullert@bottom.magnus.acs.ohio-state.edu (tfullert) wrote: > I was given a copy of MPW 3.3 (not pirated, I was given all of the > materials in the huge box),and have the current shell from CodeWarrior. > I am doing all of my own work on CodeWarrior and I want to devote some > energy to learning MPW. What priority should I give this, though. > Exactly what can I do with MPW which I cannot do with CodeWarrior or > SC++? Tim, For one thing, you will have the privilege of compiling and easily playing with example source code from Apple, which is quite often only available in MPW format. Apple is getting better at this, or perhaps it is because of the individuals at Apple who realize that... "If you want programmers out there to move quickly, don't make them jump through the hoop of having to convert MPW source code to their environment." ... and have graciously provided source code ready-to-compile for all the big-three environments. I am in the same situation as you are -- minus MPW. Personally, I am really pissed, because I have Symantec C++, and the PowerPC SDK, and I also have CodeWarrior 3.5, and that adds up to a good chunk of change and a major investment of time. For a while there, MPW was abandoned. But now, I have been unable to participate as an OpenDoc early adopter, or to even take advantage of the recent develop article on OSA -- which is critical to my work -- just because I can't afford to purchase MPW, who's price just went up to $450 the other day. It makes my head spin. I want to smash something. I have always felt that all would-be Mac developers should be alerted that it is not realistic to undertake developing software for the Macintosh without having a minimum of $10,000 to spend on the minimum things you need, and at least one year to write the simplest of programs (due to the incredible wastes of time). I wouldn't have then gone through all this anguish, and embarrassing myself in front of so many people ( you know... investors, friends, parents, c.s.m.p. ). I can't blame anyone except myself. I know that. Even so, the world can be a screwed up place to write Mac software in. So much needed talent -- wasted. Mark Hanrek The Information Workshop - --------------------------------------------------------- P.S. Tim: Keep it. You'll need it. +++++++++++++++++++++++++++ >From hanrek@cts.com (Mark Hanrek) Date: Sat, 13 Aug 1994 16:03:09 -0800 Organization: The Information Workshop In article , hanrek@cts.com (Mark Hanrek) wrote: > ...can't afford to purchase MPW, who's price just went up to $450 oops. After I went to check my facts, I realized that the $350 option still remains. But I can save money by spending a hundred dollars more! :) - --------- A humorous aside... The rich get extra "quantity discounts". The poor get extra "late fees". Crazy man, crazy. :) Mark Hanrek The Information Workshop +++++++++++++++++++++++++++ >From spencerl@crl.com (Spencer Low) Date: Sat, 13 Aug 1994 20:15:26 -0800 Organization: LowTek Creations In article , mclow@san_marcos.csusm.edu (Marshall Clow) wrote: > Try this in CodeWarrior (or Think, for that matter). Build an > application containing 4 LDEFs, 2 MDEFs, 3 WDEFs, as well as 12 plug in > tools, putting the 'CODE' resources and the xDEF resources in a file of... [more incredibly complex make stuff deleted :-] Isn't this possible to do with ToolServer and some of the MPW tools? Or does it get even more complex then? (The worse I've had to do is to get AppleScript to talk to ToolServer to Rez some files (with a special MPW/ToolServer script), open up my CW project, link and make it, etc.) Thanks, Spencer ________________________________________________________________________ Spencer "MaxRAM" Low ------ LowTek Creations ----- spencerl@crl.com +++++++++++++++++++++++++++ >From joseph@joebloe.maple-shade.nj.us (Joseph Nathan Hall) Date: Sat, 13 Aug 94 22:20:46 MST Organization: 5 Sigma Software In article (comp.sys.mac.programmer), nagle@netcom.com (John Nagle) writes: ) tfullert@bottom.magnus.acs.ohio-state.edu (tfullert) writes: ) >I was given a copy of MPW 3.3 (not pirated, I was given all of the ) >materials in the huge box),and have the current shell from CodeWarrior. ) > I am doing all of my own work on CodeWarrior and I want to devote some ) >energy to learning MPW. What priority should I give this, though. ) >Exactly what can I do with MPW which I cannot do with CodeWarrior or ) >SC++? ) ) The MPW compilers are so out-of-date that unless you have old ) software developed under MPW you need to maintain, don't bother. ) ) MPW is basically a UNIX-like command line oriented environment, ) under which you can run various UNIX-like tools. It's useful if you ) need to build UNIX-like tools to process data as part of your ) program-building process. MPW dates from when the Mac could only run ) one program at a time, and it has its own hack for running "MPW tools" ) under its own shell. Yeah, it's a bummer when a tool dies, since it takes the shell with it. Oh, well. But anyway, yes, the compilers are slow and have some inappropriately glib error messages that become less funny at 4 in the morning. However, there is no equivalent to MPW make in either TPM or CW. Applescripts are a somewhat awkward alternative, I guess, but for those of us who have special needs (yacc-generated sources, or perhaps some inputs generated by a perl script), MPW is basically the only way to automate the building of complex projects. I think that you will find many commercial developers using MPW to build auxiliary stuff even if they don't use it for compiles in general. Also, MPW gives you input redirection and piping for tools, which is handy and not available otherwise. The word from Apple, which I will take under advisement, is that the compilers are scheduled for a rev for speed later this year. =============== O Fortuna, velut Luna, statu variabilis =============== uunet!joebloe!joseph (602) 732-2549 day joseph%joebloe@uunet.uu.net 1400 N Alma School #163 Chandler, AZ 85224 Copyright 1994 by Joseph N. Hall. Commercial use prohibited. "The division-WINNING Phillies!" -- Section 236, Row 08, Seat 03 (well, those were the days) +++++++++++++++++++++++++++ >From wysocki@netcom.com (Chris Wysocki) Date: Sun, 14 Aug 1994 07:41:37 GMT Organization: NETCOM On-line Communication Services (408 261-4700 guest) In article , Mark Hanrek wrote: >I have always felt that all would-be Mac developers should be alerted that >it is not realistic to undertake developing software for the Macintosh >without having a minimum of $10,000 to spend on the minimum things you >need, and at least one year to write the simplest of programs (due to the >incredible wastes of time). Mark, would you care to enlighten all of us as to exactly how you arrived at this $10,000 figure? I personally have been programming the Macintosh since 1985, and over the course of these nine years I have not spent a combined $10k on all the development tools, books, documentation and other resources that I have purchased, and I own a fairly complete library of Macintosh development tools. Today anyone can go out and buy Code Warrior Bronze for $99, THINK Reference for $50, the new Inside Macintosh CD for $99, a subscription to develop for $30, and a few good tutorial books for $200, and they'll have an excellent set of tools for learning how to program the Macintosh, all for less than $500. One certainly could easily spend far more than this, but saying that $10k is needed to start programming the Macintosh is akin to saying that one must purchase a $90,000 BMW 850iL in order to learn how to drive a car. Chris. +++++++++++++++++++++++++++ >From sw@network-analysis-ltd.co.uk (Sak Wathanasin) Date: Sun, 14 Aug 94 11:45:04 BST Organization: Network Analysis Ltd In article (comp.sys.mac.programmer), mclow@san_marcos.csusm.edu (Marshall Clow) writes: > Try this in CodeWarrior (or Think, for that matter). Build an > application containing 4 LDEFs, 2 MDEFs, 3 WDEFs, as well as 12 plug in > tools, putting the 'CODE' resources and the xDEF resources in a file of > type 'APPL', while each of the tools goes in a seperate file. Don't forget > to put the build date (and time) into the 'vers' resource so that testers > can tell exactily what they have. After you have built the application, > compress the resources in the application. > > Oh yes, do this by choosing a single menu option. Never mind that - just building a fat PPC/68K application with CW is a pain in the nether regions. With CW you have to maintain 2 separate projects, one for 68K, one for PPC. With MPW, I have 1 makefile to look after. Another thing that gets me with the CW/Think approach is that you must include all of the srcs files for TCL, MacApp, PowerPlant, whatever into your project if you want symbolic debugging of the libs. That means a copy of the lib (with symbols) for every project that uses the class lib. OK, so 1 GB disks are ten a penny these days. But when I get a new release of TCL, MacApp, or whatever, it means recompiling every TC/CW project that uses these libs. So if you have 10 projects that use, say, MacApp, that means recompiling MacApp 10 times. With MPW, I recompile the class lib once, build a library, then relink; at most I only have to recompile my srcs (because of header changes). Much more civilized. Luckily, from CW 3.5 on, I have the best of both worlds. Sak Wathanasin Network Analysis Limited 178 Wainbody Ave South, Coventry CV3 6BX, UK Internet: sw@network-analysis-ltd.co.uk uucp: ...!uknet!nan!sw AppleLink: NAN.LTD Phone: (+44) 203 419996 Mobile:(+44) 850 587411 Fax: (+44) 203 690690 +++++++++++++++++++++++++++ >From partingt@fwi.uva.nl (Vincent Partington) Date: 14 Aug 1994 15:20:23 GMT Organization: FWI, University of Amsterdam spencerl@crl.com (Spencer Low) writes: >Isn't this possible to do with ToolServer and some of the MPW tools? Or >does it get even more complex then? I've written a small MPW Tool that can send a "Make Project" event to the CodeWarrior environment. I use a makefile for stuff that needs to be built by MPW Tools (Rez, Flex, Bison) and a CW project for the C code. I type the following in the ToolServer window to have everything updated automatically: Make >__commands __commands delete __commands MPWMake O yeah, the tool doesn't need AppleScript to do this. Funnily enough I got CW4 yesterday and it contains some sample code to send AppleEvents to the CW environment. Anyway the source can be gotten by fingering partingt@gene.fwi.uva.nl. Vincent. -- appel peer banaan baksteen ||| The Fingerware Project: schelp zon zand rolstoel ||| Put your code snippets in your .plan! groen wit geel flatgebouw ||| If you want to know more boer postbode bouwvakker roos ||| finger partingt@gene.fwi.uva.nl +++++++++++++++++++++++++++ >From nick+@pitt.edu ( nick.c ) Date: Sun, 14 Aug 94 18:19:05 GMT Organization: The Pitt, Chemistry In Article , hanrek@cts.com (Mark Hanrek) wrote: >Personally, I am really pissed, because I have Symantec C++, and the >PowerPC SDK, and I also have CodeWarrior 3.5, and that adds up to a good >chunk of change and a major investment of time. > >For a while there, MPW was abandoned. > >But now, I have been unable to participate as an OpenDoc early adopter, or >to even take advantage of the recent develop article on OSA -- which is >critical to my work -- just because I can't afford to purchase MPW, who's >price just went up to $450 the other day. Not sure if this helps (you might be talking about the Apple compilers), but there is a fully configured version of the MPW shell for use with CW on CW4 - I think it was there for 3.5 too. Interet: nick@pitt.edu _/ _/ _/ _/_/_/ _/ _/ eWorld: nick _/_/ _/ _/ _/ _/ _/_/_/ CIS: 71232,766 _/ _/_/ _/ _/ _/ _/ _/ _/ _/ _/_/_/ _/ _/ "Science is nothing but perception" - Plato +++++++++++++++++++++++++++ >From Ken Prehoda Date: 14 Aug 1994 21:29:19 GMT Organization: Univ of Wisc-Madison In article nick.c, nick+@pitt.edu writes: > Not sure if this helps (you might be talking about the Apple > compilers), but there is a fully configured version of the MPW > shell for use with CW on CW4 - I think it was there for 3.5 too. I think Mark was talking about the MPW compilers, since he said he has codewarrior AND the PPC SDK, both of which contain the MPW 3.3 shell. Currently, MPW C++ is pretty much required to do build opendoc part editors. I, and I'm sure many others, are waiting for the opendoc beta (that uses SOM instead of ASLM) so we can use MW C++ (or Symantec). However, there is a folder on the OpenDoc A6 CD for building opendoc with codewarrior which can get you a long way until the beta arrives. -Ken Prehoda kenp@nmrfam.wisc.edu +++++++++++++++++++++++++++ >From Gavriel State Date: 14 Aug 1994 18:36:49 GMT Organization: Metrowerks Inc. In article Sak Wathanasin, sw@network-analysis-ltd.co.uk writes: > Another thing that gets me with the CW/Think approach is that you must > include all of the srcs files for TCL, MacApp, PowerPlant, whatever > into your project if you want symbolic debugging of the libs. That In CW4 you can debug PPC shared libraries in source. Just build MacApp, Powerplant, or whatever as a shared library, include it in your project, and go. -- Gavriel State | 4A Systems Design Engineering/Economics | Univ. of Waterloo - --------------------------------------------------------------------------- Email: grstate@metrowerks.ca | "Sentence fragment. Another. Good device. - ------------------------------| Will be used more later." - This is the Metrowerks CodeWarrior Pascal | title of the story, which is also found Co-Op Engineering Student Person| several times in the story itself. +++++++++++++++++++++++++++ >From chrism@col.hp.com (Chris Magnuson) Date: 15 Aug 1994 04:07:20 GMT Organization: HP Colorado Springs Division Chris Wysocki (wysocki@netcom.com) wrote: : In article , : Mark Hanrek wrote: : Mark, would you care to enlighten all of us as to exactly how you : arrived at this $10,000 figure? I personally have been programming : the Macintosh since 1985, and over the course of these nine years I : have not spent a combined $10k on all the development tools, books, : documentation and other resources that I have purchased, and I own a : fairly complete library of Macintosh development tools. Today anyone : can go out and buy Code Warrior Bronze for $99, THINK Reference for : $50, the new Inside Macintosh CD for $99, a subscription to develop : for $30, and a few good tutorial books for $200, and they'll have an : excellent set of tools for learning how to program the Macintosh, all : for less than $500. One certainly could easily spend far more than : this, but saying that $10k is needed to start programming the : Macintosh is akin to saying that one must purchase a $90,000 BMW 850iL : in order to learn how to drive a car. Well, you forgot to buy a Mac for one thing. :) Chris Magnuson chrism@col.hp.com +++++++++++++++++++++++++++ >From quinn@cs.uwa.edu.au (Quinn "The Eskimo!") Date: Mon, 15 Aug 1994 14:30:46 +0800 Organization: Department of Computer Science, The University of Western Australia In article <01050166.75ttt1@joebloe.maple-shade.nj.us>, joseph@joebloe.maple-shade.nj.us wrote: >Yeah, it's a bummer when a tool dies, since it takes the shell with it. >Oh, well. The tool has to die pretty badly for "g sysrecover" to fail. -- Quinn "The Eskimo!" "Support HAVOC!" Department of Computer Science, The University of Western Australia +++++++++++++++++++++++++++ >From quinn@cs.uwa.edu.au (Quinn "The Eskimo!") Date: Mon, 15 Aug 1994 14:33:32 +0800 Organization: Department of Computer Science, The University of Western Australia In article , spencerl@crl.com (Spencer Low) wrote: >Isn't this possible to do with ToolServer and some of the MPW tools? Or >does it get even more complex then? I've built things in MPW that would make your hair curl. Specifically trying to hack MW or TPM to build something as complicated as LabMaster would have been defeating the point of these environments. Use the right tools for the job. If you're building an application then using MW or TPM. If you're building something hideous then MPW is your friend. Besides [warning, holy way bait!] MPW's editor is *sooo* much better than any other editor on the Mac. -- Quinn "The Eskimo!" "Support HAVOC!" Department of Computer Science, The University of Western Australia +++++++++++++++++++++++++++ >From tree@bedford.symantec.com (Tom Emerson) Date: 15 Aug 1994 11:41:55 GMT Organization: Symantec Development Tools Group In article , quinn@cs.uwa.edu.au (Quinn "The Eskimo!") wrote: > Besides [warning, holy way bait!] MPW's editor is *sooo* much better than > any other editor on the Mac. So, what features of the MPW editor do you prefer over those provided by any other editor? -tre -- Tom Emerson Software Engineer Development Tools Group Symantec Corporation tree@bedford.symantec.com "I dreamed I had to take a test, in a Dairy Queen, on another planet." +++++++++++++++++++++++++++ >From neal@farallon.com (Neal Trautman) Date: 15 Aug 1994 14:04:01 GMT Organization: Farallon Computing, Inc. In article , mclow@san_marcos.csusm.edu (Marshall Clow) writes: > > Try this in CodeWarrior (or Think, for that matter). Build an > application containing 4 LDEFs, 2 MDEFs, 3 WDEFs, as well as 12 plug in > tools, putting the 'CODE' resources and the xDEF resources in a file of > type 'APPL', while each of the tools goes in a seperate file. Don't forget > to put the build date (and time) into the 'vers' resource so that testers > can tell exactily what they have. After you have built the application, > compress the resources in the application. > > Oh yes, do this by choosing a single menu option. > I agree. Timbuktu has two applications, a Desk Accessory, an Extension with an INIT, a DRVR and stand-alone code resources, an AOCE catalog template, an Installer script, and two help files. Most all of these files are also compressed. AND, I can build all this in 4 languages (English, French, German, and Kanji) by selecting one menu command. Now, on the other hand, for the Metroweks Profiler viewer application, I used CodeWarrior and PowerPlant there was only one piece to build. ========================================================================== Neal Trautman I climbed to the top of the ladder Timbuktu Lead Software Engineer of success only to realize it was Metrowerks CodeWarrior Profiler co-author leaning against the wrong wall. ========================================================================== +++++++++++++++++++++++++++ >From hanrek@cts.com (Mark Hanrek) Date: Mon, 15 Aug 1994 09:36:04 -0800 Organization: The Information Workshop In article <32m2bf$ilh@news.doit.wisc.edu>, Ken Prehoda wrote: > In article > nick.c, nick+@pitt.edu writes: > > Not sure if this helps (you might be talking about the Apple > > compilers), but there is a fully configured version of the MPW > > shell for use with CW on CW4 - I think it was there for 3.5 too. > > I think Mark was talking about the MPW compilers, since he said he > has codewarrior AND the PPC SDK, both of which contain the MPW 3.3 > shell. > > Currently, MPW C++ is pretty much required to do build opendoc part > editors. I, and I'm sure many others, are waiting for the opendoc > beta (that uses SOM instead of ASLM) so we can use MW C++ (or > Symantec). > > However, there is a folder on the OpenDoc A6 CD for building opendoc > with codewarrior which can get you a long way until the beta arrives. > > -Ken Prehoda > kenp@nmrfam.wisc.edu Thanks, Ken, for clarifying that for me. And thanks for the reference to that folder! I quadruple-checked for anything to do with CodeWarrior on the A6 CD, and found a read-me that referred to a folder that does not exist, at least on the WWDC version of OpenDoc A6. So, is it the case that this folder does exist on another version of the OpenDoc A6 release? I looked on eWorld, but those files come in clumps. :) Still trying... Mark Hanrek +++++++++++++++++++++++++++ >From mclow@san_marcos.csusm.edu (Marshall Clow) Date: Mon, 15 Aug 1994 10:14:05 -0800 Organization: Aladdin Systems In article , tree@bedford.symantec.com (Tom Emerson) wrote: > In article , > quinn@cs.uwa.edu.au (Quinn "The Eskimo!") wrote: > > > Besides [warning, holy way bait!] MPW's editor is *sooo* much better than > > any other editor on the Mac. > > So, what features of the MPW editor do you prefer over those provided by > any other editor? > Tom -- My _favorite_ MPW editor feature is the "double click on open paren/brace/bracket/slash/quote and select everything up to the matching symbol. (Also works with 2x-clicking on the closing symbol. If you hold the mouse button down after the second click, you can move the cursor around and see the selection change to show differing "matches" MUCH, much better than the "Balance" command in Think. -- Marshall [ Who's trying to turn an potential flame war into a rational discussion. ] -- Marshall Clow Aladdin Systems mclow@san_marcos.csusm.edu +++++++++++++++++++++++++++ >From kenp@tuli (Kenneth Prehoda) Date: 15 Aug 1994 18:31:25 GMT Organization: Division of Information Technology Mark Hanrek (hanrek@cts.com) wrote: : Thanks, Ken, for clarifying that for me. And thanks for the reference to : that folder! : I quadruple-checked for anything to do with CodeWarrior on the A6 CD, and : found a read-me that referred to a folder that does not exist, at least on : the WWDC version of OpenDoc A6. : So, is it the case that this folder does exist on another version of the : OpenDoc A6 release? I looked on eWorld, but those files come in clumps. : :) : Still trying... : Mark Hanrek The "Building Opendoc with Codwarrior" Folder is only on the OpenDoc A6 with source disk, I believe (Jens, can you help me out here?). This is because to use codewarrior you currently have to build your part editor inside of opendoc and hence requires building opendoc in CW. -Ken Prehoda kenp@nmrfam.wisc.edu +++++++++++++++++++++++++++ >From lambert_l@measurex.com (Leon Lambert) Date: Mon, 15 Aug 1994 17:58:53 GMT Organization: measurex In article <32ipft$18t@charm.magnus.acs.ohio-state.edu> tfullert@bottom.magnus.acs.ohio-state.edu (tfullert) writes: > Hi: > > I was given a copy of MPW 3.3 (not pirated, I was given all of the > materials in the huge box),and have the current shell from CodeWarrior. > I am doing all of my own work on CodeWarrior and I want to devote some > energy to learning MPW. What priority should I give this, though. > Exactly what can I do with MPW which I cannot do with CodeWarrior or > SC++? > > Thanks; > > Tim I find the scripting language in MPW to be great. It takes quite an investment to learn but really pays off if you have a lot of tedious repetative editing to do. I do a lot of porting of code to other platforms and find it very useful. The comparefiles script is worth its weight in Gold. I have not found a better file comparison utility on any platform out there. Since switching to CW I find myself spending about 85% of my time there, but still need to switch to MPW to do some fancy stuff. MPW allows you to hook your own functions to keys to do fancy editing. For instance I can double click a function name and do a cmd 0 and the proper #include is inserted at the top of my C file. I wish CW would put some sort of scripting/macro ability into their editor. lambert_l@measurex.com (Leon Lambert) lambertlb@aol.com +++++++++++++++++++++++++++ >From quinn@cs.uwa.edu.au (Quinn "The Eskimo!") Date: Tue, 16 Aug 1994 11:10:30 +0800 Organization: Department of Computer Science, The University of Western Australia In article , tree@bedford.symantec.com (Tom Emerson) wrote: >So, what features of the MPW editor do you prefer over those provided by >any other editor? [On no, I'm gonna get in twubble again... (: ] #1 most important feature... it edits arbitrary sized files. I get *really* annoyed when I edit a file and programs go "not enough memory to edit this document". But I recognise that this feature is a) hard and b) unnecessary for programming. It's just that MPW has it and no one else does. I also like the way MPW's command, option & shift arrow keys all seem to work they way I expect. And, if worst comes to worst, I can use SetKey to fix them (: Double-clicking on brackets to match them! [Although that's supposed to have arrived in CW4.] I *really* like MPW's search and replace system, especially the way that shift works to search backwards. I just can't get the the hang of any Think editor's search and replace. CW is good but the non-modal dialog just confuses me (: I also like the power of MPW's regular expressions. [And unlike most of my unix-raised bretheren, I understand them better than unix regexs.] I also make quite a bit of use adding scripts into menus. I suspect that Alpha provides most of the flexibility that I need in an editor. But unfortunately Alpha is both ugly (IMHO of course) and Dvorak keyboard unfriendly. [Yes I know you can tweak it but that's *no* excuse.] I want MPW's editor ripped out of MPW so that I can use it with CW and TPM without blowing away multiple megabytes!!! We have ToolServer and SourceServer, why not EditorServer (: Share and Enjoy. -- Quinn "The Eskimo!" "Support HAVOC!" Department of Computer Science, The University of Western Australia Who's just come from one flame war in c.s.m.hardware and doesn't really want to start another here ): +++++++++++++++++++++++++++ >From Bruce@hoult.actrix.gen.nz (Bruce Hoult) Date: Tue, 16 Aug 1994 16:24:50 +1200 (NZST) Organization: (none) mclow@san_marcos.csusm.edu (Marshall Clow) writes: > My _favorite_ MPW editor feature is the "double click on open > paren/brace/bracket/slash/quote and select everything up to the matching > symbol. (Also works with 2x-clicking on the closing symbol. If you hold > the mouse button down after the second click, you can move the cursor > around and see the selection change to show differing "matches" > > MUCH, much better than the "Balance" command in Think. Holy cow! I've been using MPW since 1987, and have used the "double-click on a bracket" feature forever, but I've never discovered the "hold the button down" feature. Cool! -- Bruce +++++++++++++++++++++++++++ >From stevec@jolt.mpx.com.au (Stephen F Coy) Date: 16 Aug 1994 10:23:29 GMT Organization: Microplex Pty Ltd Quinn "The Eskimo! (quinn@cs.uwa.edu.au) wrote: : In article , tree@bedford.symantec.com : (Tom Emerson) wrote: : >So, what features of the MPW editor do you prefer over those provided by : >any other editor? : [On no, I'm gonna get in twubble again... (: ] : #1 most important feature... it edits arbitrary sized files. I get : *really* annoyed when I edit a file and programs go "not enough memory to : edit this document". But I recognise that this feature is a) hard and b) : unnecessary for programming. It's just that MPW has it and no one else : does. : I also like the way MPW's command, option & shift arrow keys all seem to : work they way I expect. And, if worst comes to worst, I can use SetKey to : fix them (: : Double-clicking on brackets to match them! [Although that's supposed to : have arrived in CW4.] : I *really* like MPW's search and replace system, especially the way that : shift works to search backwards. I just can't get the the hang of any : Think editor's search and replace. CW is good but the non-modal dialog : just confuses me (: I also like the power of MPW's regular expressions. : [And unlike most of my unix-raised bretheren, I understand them better : than unix regexs.] : I also make quite a bit of use adding scripts into menus. : I suspect that Alpha provides most of the flexibility that I need in an : editor. But unfortunately Alpha is both ugly (IMHO of course) and Dvorak : keyboard unfriendly. [Yes I know you can tweak it but that's *no* : excuse.] : I want MPW's editor ripped out of MPW so that I can use it with CW and TPM : without blowing away multiple megabytes!!! We have ToolServer and : SourceServer, why not EditorServer (: : Share and Enjoy. : -- : Quinn "The Eskimo!" "Support HAVOC!" : Department of Computer Science, The University of Western Australia : Who's just come from one flame war in c.s.m.hardware and doesn't : really want to start another here ): I could not have said this better myself. In fact, one of the reasons I like Object Master so much is that it emulates (mostly anyway) the keyboard and search/replace behaviour of MPW. Everytime I fire up the Symantec C++ IDE, the editor drives me nuts in short order. - ------ Steve Coy Resolve Software (WA) Pty Ltd Sydney Australia +++++++++++++++++++++++++++ >From Willie Abrams Date: 16 Aug 1994 13:21:15 GMT Organization: OU Health Sciences Center In article Tom Emerson, tree@bedford.symantec.com writes: >So, what features of the MPW editor do you prefer over those provided by >any other editor? Tom, hate to make a pointed remark...MPW can open up files to just look at and edit individually (unlike TPM, where I can't unless I have a project open.) It is a small, but modal inconvenience that keeps me from even going to TPM look at hardly any source files - I find myself dragging and dropping on to BBEdit Lite. Willie Abrams willie-abrams@uokhsc.edu Telemedicine Software Guy OU Health Sciences Center It's a classic Pincer's Movement. It can't fail against a ten-year-old! +++++++++++++++++++++++++++ >From Willie Abrams Date: 16 Aug 1994 13:22:35 GMT Organization: OU Health Sciences Center In article Quinn, quinn@cs.uwa.edu.au writes: >unnecessary for programming. It's just that MPW has it and no one else >does. BBEdit hardly ever has this problem... Willie Abrams willie-abrams@uokhsc.edu Telemedicine Software Guy OU Health Sciences Center It's a classic Pincer's Movement. It can't fail against a ten-year-old! +++++++++++++++++++++++++++ >From tree@bedford.symantec.com (Tom Emerson) Date: Tue, 16 Aug 1994 15:30:56 -0500 Organization: Symantec Development Tools Group In article <32qegb$36f@romulus.ucs.uoknor.edu>, Willie Abrams wrote: > In article Tom Emerson, > tree@bedford.symantec.com writes: > >So, what features of the MPW editor do you prefer over those provided by > >any other editor? > > Tom, hate to make a pointed remark...MPW can open up files > to just look at and edit individually (unlike TPM, where I can't > unless I have a project open.) Sure, I understand. But that is an environment issue, not an editor issue. Just picking nits ;-) This is something that is, contrary to many peoples belief, something that is non-trivial to change in the design of the TPM, not that it hasn't been discussed. Who knows what the future may hold, though. -tre -- Tom Emerson Software Engineer Development Tools Group Symantec Corporation tree@bedford.symantec.com "I dreamed I had to take a test, in a Dairy Queen, on another planet." +++++++++++++++++++++++++++ >From quinn@cs.uwa.edu.au (Quinn "The Eskimo!") Date: Wed, 17 Aug 1994 10:12:19 +0800 Organization: Department of Computer Science, The University of Western Australia In article <32qeir$36f@romulus.ucs.uoknor.edu>, Willie Abrams wrote: >BBEdit hardly ever has this problem... Yeah, I know, BBEdit uses temporary memory. But it still bites me. I only have 20MB (: and when I'm programming and documenting XCMDs I need MPW, HyperCard and my documentation tools open all at once which means that I regularly run out of temporary memory. Then I got to poke around in a PostScript file at the same time... Just one of those inconveniences that I can do without. And given the other advantages of MPW's editor. -- Quinn "The Eskimo!" "Support HAVOC!" Department of Computer Science, The University of Western Australia And don't even mention LabView. +++++++++++++++++++++++++++ >From Manuel Veloso Date: Wed, 17 Aug 1994 07:35:44 GMT Organization: Ibex Productions In article <32qeir$36f@romulus.ucs.uoknor.edu> Willie Abrams, willie-abrams@uokhsc.edu writes: >Quinn, quinn@cs.uwa.edu.au writes: >>unnecessary for programming. It's just that MPW has it and no one else >>does. > >BBEdit hardly ever has this problem... Actually, I was dealing with Postscript files a while back, and MPW is the only editor (besides MS Word) that would open them - no matter how big (ie: a couple of megs). Of course, I could have changed BBEdit's partition size, but I use it as my 'normal' editor and wouldn't want to keep changing it. BBEdit's major strength, IMO, is its multi-file search browser. Too bad you can't edit in it, though. +++++++++++++++++++++++++++ >From Manuel Veloso Date: Wed, 17 Aug 1994 07:43:10 GMT Organization: Ibex Productions In article <32ipft$18t@charm.magnus.acs.ohio-state.edu> tfullert, tfullert@bottom.magnus.acs.ohio-state.edu writes: >Exactly what can I do with MPW which I cannot do with CodeWarrior or >SC++? Well, there are three main things: (1) you can do a multitude of incredibly complicated things with MPW's scripting language/makefiles. In essence, you have complete control over the shell, and can issue commands, etc. (2) you can have completely integrated projector support (how many times have you moved a ProjectorDB file and gotten the "can't check in file blah because the project was not found" using the TPM/SS combo? This never happens w/Projector. Plus, check in active/check out active work, and the checkin window doesn't take forever in MPW.) (3) You can be macho <-- arguably the most important thing you can't do if you use CW/SymC +++++++++++++++++++++++++++ >From Manuel Veloso Date: Wed, 17 Aug 1994 07:46:44 GMT Organization: Ibex Productions In article Quinn, quinn@cs.uwa.edu.au writes: >>Yeah, it's a bummer when a tool dies, since it takes the shell with it. >>Oh, well. > >The tool has to die pretty badly for "g sysrecover" to fail. You can also use "g stoptool". I'm not sure which one's recommended, though. +++++++++++++++++++++++++++ >From bix.com!dvanhoozer Date: 17 Aug 1994 08:53:26 GMT Organization: Mad Bomber Software In article <2859899090@hoult.actrix.gen.nz> Bruce@hoult.actrix.gen.nz (Bruce Hoult) writes: >mclow@san_marcos.csusm.edu (Marshall Clow) writes: >> the mouse button down after the second click, you can move the cursor >> around and see the selection change to show differing "matches" >> >> MUCH, much better than the "Balance" command in Think. > >Holy cow! > >I've been using MPW since 1987, and have used the "double-click on a bracket" >feature forever, but I've never discovered the "hold the button down" >feature. My face is just as red BH, like you that one has some how got past me. I wonder what else I don't know.... :-) Dewayne o-* +++++++++++++++++++++++++++ >From Bruce@hoult.actrix.gen.nz (Bruce Hoult) Date: Thu, 18 Aug 1994 03:17:32 +1200 (NZST) Organization: (none) Manuel Veloso writes: > Actually, I was dealing with Postscript files a while back, and MPW > is the only editor (besides MS Word) that would open them - no matter > how big (ie: a couple of megs). Of course, I could have changed > BBEdit's partition size, but I use it as my 'normal' editor > and wouldn't want to keep changing it. BBEdit lets you open any size file without changing the partition size -- it uses System memory. In my moonlighting job as a consultant to a DTP company, I often use BBEdit to edit PostScript files of up to 80 or 100 MB in size. It handles it without a complaint, with very good performance (once the file is all read into memory), in the standard BBEdit memory partition. MPW and Word simply can't cope with files this size with any sort of performance at all. You done good, Rich. This *is* on a Q950 with 136 MB of RAM, mind you. -- Bruce +++++++++++++++++++++++++++ >From mem@pha.jhu.edu (Mel Martinez) Date: Wed, 17 Aug 1994 15:57:25 -0500 Organization: The Johns Hopkins Univ. - Dept. of Physics In article <2860024652@hoult.actrix.gen.nz>, Bruce@hoult.actrix.gen.nz (Bruce Hoult) wrote: > Manuel Veloso writes: > > Actually, I was dealing with Postscript files a while back, and MPW > > is the only editor (besides MS Word) that would open them - no matter > > how big (ie: a couple of megs). Of course, I could have changed > > BBEdit's partition size, but I use it as my 'normal' editor > > and wouldn't want to keep changing it. > > BBEdit lets you open any size file without changing the partition > size -- it uses System memory. > > In my moonlighting job as a consultant to a DTP company, I often use > BBEdit to edit PostScript files of up to 80 or 100 MB in size. It > handles it without a complaint, with very good performance (once the > file is all read into memory), in the standard BBEdit memory partition. > > MPW and Word simply can't cope with files this size with any sort of > performance at all. You done good, Rich. > > This *is* on a Q950 with 136 MB of RAM, mind you. > > -- Bruce Err.. thank you. You may sit down now, please. :-) Now back to dealing with problems for 'the rest of us' (with single & double digit memory)... Sheesh! Mel +++++++++++++++++++++++++++ >From siegel@netcom.com (Rich Siegel) Date: Wed, 17 Aug 1994 19:36:24 GMT Organization: Bare Bones Software In article <2860024652@hoult.actrix.gen.nz> Bruce@hoult.actrix.gen.nz (Bruce Hoult) writes: >In my moonlighting job as a consultant to a DTP company, I often use >BBEdit to edit PostScript files of up to 80 or 100 MB in size. It >handles it without a complaint, with very good performance (once the >file is all read into memory), in the standard BBEdit memory partition. > >MPW and Word simply can't cope with files this size with any sort of >performance at all. You done good, Rich. I appreciate the compliment, but in good conscience can't take -all- the credit. The text engine was original written by Jon Hueras, with modifications by me, and Jon also did the rewrite for PowerPC. (That won't stop me from taking -some- of the credit, though. :-]) R. -- Rich Siegel % siegel@netcom.com % President & CEO, Bare Bones Software Inc. --> For information about BBEdit, finger bbedit@world.std.com <-- +++++++++++++++++++++++++++ >From mxmora@unix.sri.com (Matt Mora) Date: 17 Aug 1994 13:43:17 -0700 Organization: SRI International, Menlo Park, CA In article tree@bedford.symantec.com (Tom Emerson) writes: >Sure, I understand. But that is an environment issue, not an editor issue. >Just picking nits ;-) This is something that is, contrary to many peoples >belief, something that is non-trivial to change in the design of the TPM, >not that it hasn't been discussed. Who knows what the future may hold, >though. We have seen the future (rainbow that is) and you better hurry up and make it so or else you won't have a market left. Xavier -- ___________________________________________________________ Matthew Xavier Mora Matt_Mora@sri.com SRI International mxmora@unix.sri.com 333 Ravenswood Ave Menlo Park, CA. 94025 +++++++++++++++++++++++++++ >From ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) Date: 19 Aug 94 16:05:30 +1200 Organization: University of Waikato, Hamilton, New Zealand In article , tree@bedford.symantec.com (Tom Emerson) writes: > In article , > quinn@cs.uwa.edu.au (Quinn "The Eskimo!") wrote: > >> Besides [warning, holy way bait!] MPW's editor is *sooo* much better than >> any other editor on the Mac. > > So, what features of the MPW editor do you prefer over those provided by > any other editor? Of course, one of the things that gets me waxing so lyrical is that MPW is so much more than just an editor. On more than one occasion now, I've been involved in upgrading our departmental AppleShare server. We've been through 2-3 hard disk upgrades and one change of machine over the past couple of years. Each time, of course, I've had to copy all the files from the old hard disk to the new one, and preserve all their folder protections. I've never bothered getting any proper backup software to do this, since I've made it quite clear to our users that they have to back up their own data, all I'm responsible for is the server configuration itself. The file-copying part was never a big deal: I just drag everything across in the Finder, and leave it copying for a few hours, or overnight, or whatever. For transferring the folder protections (and for backing them up), I use MPW. The MPW Shell has this neat convention in some commands: it uses the same command for both examining a setting and for changing it. The clever thing is, when you ask the command to display the existing setting, it outputs a command which can be used to set the setting to that value. For example, the SetPrivilege tool lets you examine and change folder protections. The command "SetPrivilege -i" displays the current protections in the form of "SetPrivilege" commands. So to dump out all the existing protections on the old volume, I issued the command: SetPrivilege -i -r "OldVolume:" (the -r option says to recursively list subfolders as well). Then I did a global search and replace on the output, replacing all occurrences of OldVolume with NewVolume, and finally I selected the result and pressed Enter to execute it. Voila! All the protections transferred with a minimum of work. As I keep saying, if you can't do it with MPW, it isn't worth doing. :-) Lawrence D'Oliveiro fone: +64-7-856-2889 Info & Tech Services Division fax: +64-7-838-4066 University of Waikato electric mail: ldo@waikato.ac.nz Hamilton, New Zealand 37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00 +++++++++++++++++++++++++++ >From Jens Alfke Date: Fri, 19 Aug 1994 23:32:41 GMT Organization: Apple Computer Kenneth Prehoda, kenp@tuli writes: > The "Building Opendoc with Codwarrior" Folder is only on the > OpenDoc A6 with source disk, I believe (Jens, can you help > me out here?). This is because to use codewarrior you currently > have to build your part editor inside of opendoc and hence > requires building opendoc in CW. You're 100% right. I guess it might have been possible to precompile all the OD code into a library that you'd link into an app along with your part implementation, but I didn't have time to do that. Of course the beta release will work fine with CodeWarrior (in fact that's what we do our primary development with now, with brief excursions to MPW to run the SOM compiler.) --Jens Alfke jens_alfke@powertalk.apple.com "A man, a plan, a yam, a can of Spam ... Bananama!" +++++++++++++++++++++++++++ >From quinn@cs.uwa.edu.au (Quinn "The Eskimo!") Date: Sun, 21 Aug 1994 14:58:28 +0800 Organization: Department of Computer Science, The University of Western Australia In article , tree@bedford.symantec.com (Tom Emerson) wrote: >This is something that is, contrary to many peoples >belief, something that is non-trivial to change in the design of the TPM [...] Working as designed ): -- Quinn "The Eskimo!" "Support HAVOC!" Department of Computer Science, The University of Western Australia >From eric.larson@f620.n2605.z1.fidonet.org (eric larson) Subject: What is the point of MPW? Date: 18 Aug 94 19:11:49 - Organization: FidoNet: Shockwave Rider, USR V.Everything +1(908)294-0659 >>MPW and Word simply can't cope with files this size with any sort of >>performance at all. You done good, Rich. > I appreciate the compliment, but in good conscience can't take -all- > the credit. The text engine was original written by Jon Hueras, with > modifications by me, and Jon also did the rewrite for PowerPC. I've had similar experiences with BBEdit. When making literally thousands of changes using search and replace on a 10 MB text file, every other editor I've tried chokes. BBEdit handles the job smoothly, without complaint. +++++++++++++++++++++++++++ >From khatt@shell.portal.com (Judy Ann Kettenhofen) Date: 28 Aug 1994 21:52:51 GMT Organization: Portal Communications Company -- 408/973-9111 (voice) 408/973-8091 (data) eric larson (eric.larson@f620.n2605.z1.fidonet.org) wrote: : >>MPW and Word simply can't cope with files this size with any sort of : >>performance at all. You done good, Rich. : > I appreciate the compliment, but in good conscience can't take -all- : > the credit. The text engine was original written by Jon Hueras, with : > modifications by me, and Jon also did the rewrite for PowerPC. : I've had similar experiences with BBEdit. When making literally thousands of : changes using search and replace on a 10 MB text file, every other editor I've : tried chokes. BBEdit handles the job smoothly, without complaint. Sorry, I didn't see the first part of this message. In general, MPW should have problems with large files in two cases: 1) Where there are a large number of markers 2) Where you make a lot of changes. For the first, you are out of luck, to the best of my knowledge. For the second, you can do some things to help. 1. Save your file frequently after changes. This helps MPW Shell to basically do garbage collection, and requires less of the file to be resident in memory. 2. There is a way to change the size of the editor heap. I don't recall what it is right now. If you know you are going to have large files, you can try enlarging the editor heap. The MPW Shell has code to create subsequent editor heaps if it runs out of space in the first one, but I don't think that code has been exercised much. --Judy --former MPW hack. +++++++++++++++++++++++++++ >From dlopez@sailsun (Dean Lopez) Date: 30 Aug 1994 13:00:34 GMT Organization: NASA Johnson Space Center, Houston, TX, USA eric larson (eric.larson@f620.n2605.z1.fidonet.org) wrote: > I've had similar experiences with BBEdit. When making literally thousands of > changes using search and replace on a 10 MB text file, every other editor I've > tried chokes. BBEdit handles the job smoothly, without complaint. I just started using BBEdit Lite (v2.3? - whatever the latest rev is), and I've noticed whenever I open an existing file, BBEdit promptly puts a single garbage character at the end of my file. It doesn't mark the file as 'dirty' though, so if I close the file, the garbage character doesn't get saved to the file. If I make any edits to the file and THEN save, the garbage character ends up at the end of my file, which promptly causes my compiler to complain. Has anyone had this problem with the commercial BBEdit? -- +--------------------------------------+------------------------------+ | Dean Lopez | | | SAIL DPS Engineer | dlopez@sailsun.jsc.nasa.gov | | Rockwell Space Operations Co. | deanlopez@aol.com | | JSC Shuttle Avionics Integration Lab | dean_lopez@maclair.sccsi.com | +--------------------------------------+------------------------------+ #include /* The opinions expressed are all mine. RSOC doesn't speak for me and I don't speak for RSOC After all, I'm only an engineer - what do I know? */ --------------------------- >From netcom.com!kira!davidjohn (David John Burrowes) Subject: Where have the standards gone? [a high level question] Date: Fri, 19 Aug 1994 03:17:20 GMT Organization: No organization at this time. I was reading the article about System 7.5 in the September 1994 issue of MacUser (p. 79-84), and it raised a gigantic question in my mind. After some thought, I decided to see what opinions others (yourselves) might have. The 'screenshots' on pages 80-81 and 82-83 of the above issue shows several new features of this system software release. In them, I noted five new window styles: - a strange little thing for 'post-it' notes - a green one for the CD player (the title bar is similar to the standard document titlebar, but not the same) - the Find File windows have a funky styled background - the Launcher window gives us a window with, presumably, a standard pink background with square/tile/chicklet(sp?) icons - A window that is reminiscent of the 'palette' titlebar, but with close and zoom boxes. (the TV stuff in another article has yet another window style variation). For buttons, I notice these new styles (in *addition* to standard flat Mac push-buttons) - '3D' buttons in the Launcher window, - two types of CD player-like buttons in the CD player window (also found on the TV control panel in that other article) - plus, two other '3D' styles for the help system (one with icons, and one that looks like 'shallow' buttons at the bottom of the palette-ish windows. (plus, what looks like another '3d'ish style is seen in the TV control panel) Individually, many of these don't look that bad, I suppose (but, that's another issue, really). However, as I recall, one of the advertised strengths of the Macintosh, in past years, was its highly consistent interface. Buttons looked and behaved the same everywhere. Windows with a particular style almost always behaved the same as other windows with the same style. Etc. I find myself concerned, therefore, with all of these new innovations. I do not see a great deal of consistency here. What kind of message is this sending to developers? It seems to me it's something like, 'Sure, go ahead, bypass the toolbox (as I assume some or much of the above stuff is). Make up whatever non-standard user interface features you want so your app looks unusual and snazzy. Users will figure it out eventually.' Sure, I know, some developers have always felt compelled to do things their own way. But, since this is Apple doing non-standard things, many more people will feel justified in going off and doing *their own* things. By itself, I find this to be a depressing prospect. But, with Microsoft coming out with a significantly improved user interface for Windows soon (Chicago), this all strikes me as Apple shooting itself in the foot, bigtime, which I find more depressing still. If you've read this far, I'm curious what your thoughts are, either through personal email or on the newsgroup. Maybe I'm very much in the minority, and folks generally think the 'highly consistent' interface was too constraining? Thanks. david john burrowes davidjohn@kira.net.netcom.com +++++++++++++++++++++++++++ >From wysocki@netcom.com (Chris Wysocki) Date: Fri, 19 Aug 1994 09:51:10 GMT Organization: NETCOM On-line Communication Services (408 261-4700 guest) In article <1994Aug19.031720.1465@kira.net.netcom.com>, David John Burrowes wrote: >I find myself concerned, therefore, with all of these new innovations. I do >not see a great deal of consistency here. What kind of message is this >sending to developers? It seems to me it's something like, 'Sure, go ahead, >bypass the toolbox (as I assume some or much of the above stuff is). Make up >whatever non-standard user interface features you want so your app looks >unusual and snazzy. Users will figure it out eventually.' >Sure, I know, some developers have always felt compelled to do things their >own way. But, since this is Apple doing non-standard things, many more