From: pottier@clipper.ens.fr (Francois Pottier) Subject: C.S.M.P. Digest, Issue 3.005 Date: Wed, 16 Mar 94 16:43:25 MET C.S.M.P. Digest Wed, 16 Mar 94 Volume 3 : Issue 5 Today's Topics: AppleScript: Compiled Script of Applets? Communications Tool Box Experts? Execution speed of compiled code How do I : find out more about an open resource file ? PopUpMenuControl v. 'mctb', help help TextEdit caret What language should I learn? The Comp.Sys.Mac.Programmer Digest is moderated by Francois Pottier (pottier@clipper.ens.fr). The digest is a collection of article threads from the internet newsgroup comp.sys.mac.programmer. It is designed for people who read c.s.m.p. semi- regularly and want an archive of the discussions. If you don't know what a newsgroup is, you probably don't have access to it. Ask your systems administrator(s) for details. If you don't have access to news, you may still be able to post messages to the group by using a mail server like anon.penet.fi (mail help@anon.penet.fi for more information). Each issue of the digest contains one or more sets of articles (called threads), with each set corresponding to a 'discussion' of a particular subject. The articles are not edited; all articles included in this digest are in their original posted form (as received by our news server at nef.ens.fr). Article threads are not added to the digest until the last article added to the thread is at least two weeks old (this is to ensure that the thread is dead before adding it to the digest). Article threads that consist of only one message are generally not included in the digest. The digest is officially distributed by two means, by email and ftp. If you want to receive the digest by mail, send email to listserv@ens.fr with no subject and one of the following commands as body: help Sends you a summary of commands subscribe csmp-digest Your Name Adds you to the mailing list signoff csmp-digest Removes you from the list Once you have subscribed, you will automatically receive each new issue as it is created. The official ftp info is //ftp.dartmouth.edu/pub/csmp-digest. Questions related to the ftp site should be directed to scott.silver@dartmouth.edu. Currently no previous volumes of the CSMP digest are available there. Also, the digests are available to WAIS users as comp.sys.mac.programmer.src. ------------------------------------------------------- >From yjc@po.cwru.edu (Jerome Chan) Subject: AppleScript: Compiled Script of Applets? Date: Sat, 26 Feb 1994 13:05:59 -0500 Organization: TofuSoft What are the advantages of Compiled scripts and Applets? Are they both the same? Can I run multiple scripts/applets at a time? -- The Evil Tofu (Only Human) +++++++++++++++++++++++++++ >From js12@gte.com (John Schettino) Date: Mon, 28 Feb 1994 13:02:42 GMT Organization: GTE Labs, Waltham MA In article yjc@po.cwru.edu (Jerome Chan) writes: > What are the advantages of Compiled scripts and Applets? Are they both the > same? Can I run multiple scripts/applets at a time? > > -- > The Evil Tofu (Only Human) compiled scripts correspond to reusable compiled libs in other languages. You cannot "run" them, you access them using: -- this is meant to be applescript set myfuncts to load script file "myhd:mylibs:functs" -- where "myhd:mylibs:functs" is the full path to the file you saved -- as a compiled script. -- assume that there are two handlers in the file functs called foo and bar. you -- access them using: myfuncts's foo() myfuncts's bar() -- 'load script' is an applescript extention (found in System Folder:Extentions:Scripting Additions:Load Script) and has a dictionary that you can see by droping this file on the script editor. John Schettino - js12@gte.com GTE Laboratories, Inc +++++++++++++++++++++++++++ >From minshull.m@applelink.apple.com (Mark Minshull) Date: Tue, 1 Mar 1994 23:02:53 GMT Organization: OpenDoc Engineering In article , js12@gte.com (John Schettino) wrote: > In article > yjc@po.cwru.edu (Jerome Chan) writes: > > > What are the advantages of Compiled scripts and Applets? Are they both the > > same? Can I run multiple scripts/applets at a time? > > > > -- > > The Evil Tofu (Only Human) > > compiled scripts correspond to reusable compiled libs in other > languages. You cannot "run" them, you access them using: > You *can* run compiled scripts by using the "run script" command, or "telling" the script object to run. For example, consider the script below, saved in the file "hd:folder:hello world" as a compiled script: display dialog "hello world" on foo(x) return x + 2 end foo on bar(y) return y - 2 end bar You can execute this as follows: run script file "hd:folder:hello world" which would display a dialog. If you want to load the script as a library and run it you would script: set myFooLib to load script file "hd:folder:hello world" tell myFooLib run -- display's a dialog foo(2) -- => 4 bar(2) -- => 0 end tell Finally, "applets" are AppleScripts saved as small applications. You can have any number of them running at once (up to the limit of memory). If it's a "stay open" script application one can access it's handlers as follows: tell application "hello world" -- launches application if not running run -- display's a dialog foo(2) -- => 4 bar(2) -- => 0 quit -- quit's the script application end tell Mark -- Mark Minshull : OpenDoc Engineering Manager : Apple usually doesn't care Apple Computer, Inc. : what I say... When they do 1 Infinite Loop, MS 303-3A : my opinions are my own. Cupertino, CA 95014 : +++++++++++++++++++++++++++ >From js12@gte.com (John Schettino) Date: Wed, 2 Mar 1994 12:36:36 GMT Organization: GTE Labs, Waltham MA In article minshull.m@applelink.apple.com (Mark Minshull) writes: > In article , js12@gte.com (John Schettino) wrote: > > > In article > > yjc@po.cwru.edu (Jerome Chan) writes: > > > > > What are the advantages of Compiled scripts and Applets? Are they both the > > > same? Can I run multiple scripts/applets at a time? > > > > > > -- > > > The Evil Tofu (Only Human) > > > > compiled scripts correspond to reusable compiled libs in other > > languages. You cannot "run" them, you access them using: > > > > You *can* run compiled scripts by using the "run script" command, or > "telling" the script object to run. For example, consider the script > below, saved in the file "hd:folder:hello world" as a compiled script: > > display dialog "hello world" > > on foo(x) > return x + 2 > end foo > > on bar(y) > return y - 2 > end bar > > You can execute this as follows: > > run script file "hd:folder:hello world" > > which would display a dialog. If you want to load the script as a library > and run it you would script: > > set myFooLib to load script file "hd:folder:hello world" > tell myFooLib > run -- display's a dialog > foo(2) -- => 4 > bar(2) -- => 0 > end tell > Yes, you can *load* a compiled script into your script and send it a run command, but I guessed that he meant "Can you run a compiled script *from the finder*" With this interpretation, the answer is "no". Your answer is correct, and (I think) so is mine! John Schettino - js12@gte.com GTE Laboratories, Inc --------------------------- >From tel@adimail.uucp (Terry Monks) Subject: Communications Tool Box Experts? Date: Mon, 28 Feb 1994 19:08:40 GMT Organization: Automata Design, Inc. Are there any CTB experts out there? I need to send a setup string to my USR modem from with a program. Not the CTB setup string, but a AT&B1&H1 sort of thing. I know I can change the modem type to Custom and change the modem setup string, but how do you do this from within a CTB program? And where (if anywhere) is this documented. How does the Apple Modem Tool know about the different modes, and can I add one of my own. I do (of course) have the Inside Mac CTB document, that is silent on these interesting points... Tel -- Terry Monks tel@adiva.com Automata Design Inc (703) 742-9400 +++++++++++++++++++++++++++ >From ejw@pacersoft.com (Erik James Walter) Date: 1 Mar 94 21:01:43 GMT Organization: Pacer Software, Inc. In article <1994Feb28.190840.25604@adimail.uucp> Terry Monks, tel@adimail.uucp writes: >Are there any CTB experts out there? I need to send a setup string >to my USR modem from with a program. Not the CTB setup string, >but a AT&B1&H1 sort of thing. I know I can change the modem type >to Custom and change the modem setup string, but how do you do >this from within a CTB program? And where (if anywhere) is this >documented. How does the Apple Modem Tool know about the different >modes, and can I add one of my own. > >I do (of course) have the Inside Mac CTB document, that is silent >on these interesting points... > For starters, you could simply use the Serial tool and send the data directly to the modem. If you look at GetConfig and SetConfig for tools, I think that you'll find the information you need on setting a custom modem and changing the tool settings. Inside CTB doesn't say it directly, but you can pass just one or two settings in the SetConfig call and it won't affect anything but the settings you pass to it. If you want to do it with a custom modem type, there is no way to change the modem file from CTB, but you can just open the file yourself if you so choose to (Not a good idea, however). If timing isn't critical, why not just send the string after opening the connection?? +-------------------------------------------++------------------------- ---+ | A man gazing at the stars is at the mercy || Erik Walter | | of every puddle on the road. || Macintosh Engineer | | "Travel is lethal to prejudice." || Pacer Software, Inc. | | MARK TWAIN || | +-------------------------------------------++------------------------- ---+ +++++++++++++++++++++++++++ >From gurgle@netcom.com (Pete Gontier) Date: Wed, 2 Mar 1994 00:36:05 GMT Organization: cellular I'm no CTB expert, but what the hell? This post has been here long enough that I might as well take a shot at it. tel@adimail.uucp (Terry Monks) writes: >Are there any CTB experts out there? I need to send a setup string >to my USR modem from with a program. Not the CTB setup string, but a >AT&B1&H1 sort of thing. I know I can change the modem type to Custom >and change the modem setup string, but how do you do this from within a >CTB program? You don't. The whole point of the CTB is that your program does not have any control over the connection that the connection tool doesn't want you to have. In most cases, this means you have very little control. This is a feature -- you don't *want* control, because not only is control a PITA, but what you get in exchange is the ability to use your software with AppleTalk, TCP, and any other sort of connection for which you have a tool. One thing you might try is to use the Serial tool to send AT commands, but if you'll watch the progress window as the modem tool opens a connection, you'll see it does a pretty thorough job of blowing away any previous configuration by using 'ATZ'. At least it does not do 'AT&F'; you might be able to slide something past it because of that. If I understand correctly, you might not be able to guess which serial port the modem is hooked up to, because the CTB allows programs to register serial ports which are not the modem port or the printer port. This would tend to foil attempts to tweak the modem with the Serial Manager, as well. You might just choose to skip the modem tool entirely and assume that the serial tool is connected to a modem. You would have to write your own code to send AT commands and parse responses. This is not particularly difficult but can be frustrating if you have never done it before. Getting it really robust is another story; there are hundreds of modems out there, each with its own interpretation of the Hayes command set. >And where (if anywhere) is this documented. It's not. It's implicit in the way the CTB works. To explain it would be to explicitly document how to bypass the CTB. >How does the Apple Modem Tool know about the different modes, and can I >add one of my own. In versions earlier than 1.5, I dunno. In 1.5, just select "Modify this Menu..." from the 'Modem' popup menu. In my limited experience I have done configurations for an Okitel 9600 and a Global Village TelePort Gold. It's not hard. It's definitely the way to go if you have the option. >I do (of course) have the Inside Mac CTB document, that is silent >on these interesting points... That's because it's a general-case document and tries to keep its grubby little fingers out of the domain of any particular tool. :-) -- Pete Gontier, CTO, Integer Poet Software; gurgle@netcom.com --------------------------- >From schiffer@dispair.stsci.edu (Francis H. Schiffer 3rd) Subject: Execution speed of compiled code Date: Tue, 1 Mar 1994 17:54:23 GMT Organization: Self I have noticed a number of posts recently asking about how to achieve the best speed of processing on a Macintosh. The responses have said little about the effects of your compiler, whereas the benchmarks published for workstations tend to focus on the effects of your compiler on benchmark speeds. I attempted to see what are the effects of the compiler on the execution speeds of a small number of benchmark programs using a IIfx running A/UX. I had four compilers that I could use: cc = the A/UX compiler supplied by Apple and Motorola, gcc = the Gnu compiler version 2.5.7 ported to A/UX, TC = Think C version 6.0.1, and SC++ = Symmantec C++ version 6.0.1. The programs were benchmarks that have been used for workstation benchmarking with the minimum modifications necessary to run within the MacOS and/or A/UX environment. For A/UX that means no modifications and for the MacOS usually only the inclusion of prototypes. As these are ANSI style programs, the Think console was used for output, but that processing was entirely outside the timed sections. In each case the benchmark times the computational portion of the program for a sufficient number of iterations to ensure that the total duration time was small compared to the timing quanta (typically 16.67 milliseconds). In each case the application was built using the best level of optimization offered by the compiler. The results are shown in the following table where I have normalized the results to the speed of the fastest program . The duration is the time it took the fastest version of the program to execute the timed portion of the benchmark. cc gcc TC SC++ Duration Towers of Hanoi 1.00 0.79 0.81 0.68 37.4 sec Heapsort 0.79 1.00 0.77 0.50 24.4 sec Sieve of Eratosthenes 0.91 1.00 0.97 0.76 83.3 sec It should be noted that part of the slowness of the MacOS compiled versions may well be due to the fact that the timing routines on the A/UX side discount the system time from the running time, whereas the MacOS run times include the system time. All of the runs were done on a lightly loaded system, so the effects should be small. I, unfortunately, do not have the option to take down A/UX to run on a purely native MacOS to get a measure of this bias. skip -- Francis H Schiffer 3rd schiffer@stsci.edu - my opinions only, those of skip@dispair.stsci.edu stscic::schiffer - my employer are unknown to me --------------------------- >From reinkeha@dunx1.ocs.drexel.edu (Harry A. Reinke) Subject: How do I : find out more about an open resource file ? Date: Wed, 23 Feb 1994 14:52:09 GMT Organization: Drexel University, Phila. Pa. I have been having problems with some resources, I do a CountResources and I get 2 or 3 more than are available in my resource file. The resource type is 'hdrs' so I know that the syste and other open resource files do not have any such resources. Am I writeing a resource without removing the old ? I remember something about if you're not carefull you can save a particular resource type and number without destroying the prvious which causes problems. I have used HomeResFile and its return numbers that I didn't expect (like 2546 instead of 2640) but is not part of the system/ROM. How do I find out more about an open res file if I have its ref num ? I would love to associate a filename with the numbers returned from HomeResFile. Thanks. +++++++++++++++++++++++++++ >From walrathw@rferl.org (WalrathW) Date: 28 Feb 94 11:18:29 -0500 Organization: RFE/RL Inc. In article reinkeha@dunx1.ocs.drexel.edu (Harry A. Reinke) writes: > I have been having problems with some resources, I do a CountResources and > I get 2 or 3 more than are available in my resource file. The resource > type is 'hdrs' so I know that the syste and other open resource files do > not have any such resources. > > Am I writeing a resource without removing the old ? I remember something > about if you're not carefull you can save a particular resource type and > number without destroying the prvious which causes problems. > > I have used HomeResFile and its return numbers that I didn't expect (like > 2546 instead of 2640) but is not part of the system/ROM. How do I find > out more about an open res file if I have its ref num ? I would love to > associate a filename with the numbers returned from HomeResFile. > > Thanks. > > You can use the FILE dcmd in Macsbug to accomplish this. If you don't have it, check ftp.apple.com. If you don't find it there, send mail and i'll dig it up for you. You could also just write a little hack to walk through the FCB data structures (or better yet use _PBGetFCBInfo). I presume there is info on this in New Inside Mac:Files, and you should also find something in ThinkRef. "Debugging Macintosh Software w/ Macsbug" is a book worth having, and also another source of info on these topics. I started writing a little app last week to display resource chains and the resMap's of open resource files, but kind of tabled the project after finding the tool I wanted already written. I have code for walking a resMap as well as getting the file name of an open res file, given its refNum. Mail me if you want any of this code. It's not polished since it wasn't for distribution, but I think I added some comments here and there :-) . cheers, ______o0o______ Wayne Walrath RFE/RL Inc. +++++++++++++++++++++++++++ >From jim@brunner.wf.com (Jim Brunner) Date: 1 Mar 94 17:16:59 GMT Organization: (none) In article <1994Feb28.111834.340@dcvaxb.rferl.org>, you write: > > In article > reinkeha@dunx1.ocs.drexel.edu (Harry A. Reinke) writes: > > > I have been having problems with some resources, I do a CountResources and > > I get 2 or 3 more than are available in my resource file. The resource > > type is 'hdrs' so I know that the syste and other open resource files do > > not have any such resources. > > > > Am I writeing a resource without removing the old ? I remember something > > about if you're not carefull you can save a particular resource type and > > number without destroying the prvious which causes problems. CountResources counts all resources in all resource files (you mention that the type you are counting is not in other resource files like system but you may want to do this anyway) "Count1Resources" only counts in the current resource file. As to if a resource file can contain the same resource type/id twice, the answer is YES! I had this problem once. If you do an AddResource and the resource already exists, there will be a second one added. You'll need to watch this. --- Jim Brunner (jim@brunner.wf.com) --------------------------- >From first.ascent@mindlink.bc.ca (Alex Curylo) Subject: PopUpMenuControl v. 'mctb', help help Date: 28 Feb 94 01:38:42 GMT Organization: MIND LINK! - British Columbia, Canada I have a DITL resource, used in a CTB setup, that has a popup menu control in it. Since the popup menu would look much more cool in color, I created a 'mctb' for it in ResEdit, which displays the menu correctly. But when the menu is popped up in the dialog courtesy of the Dialog Manager, it's in bogus black and white. Is there some trick to getting a popup menu control to know about an 'mctb' for its 'MENU'? +++++++++++++++++++++++++++ >From leonardr@netcom.com (Leonard Rosenthol) Date: Mon, 28 Feb 1994 18:33:43 GMT Organization: Aladdin Systems, Inc. In article <39602@mindlink.bc.ca>, first.ascent@mindlink.bc.ca (Alex Curylo) wrote: > I have a DITL resource, used in a CTB setup, that has a popup menu control in > it. Since the popup menu would look much more cool in color, I created a > 'mctb' for it in ResEdit, which displays the menu correctly. But when the > menu is popped up in the dialog courtesy of the Dialog Manager, it's in bogus > black and white. Is there some trick to getting a popup menu control to know > about an 'mctb' for its 'MENU'? > No trick - it doesn't work! The PopUpCDEF doesn't load the 'mctb' resource due to visual problems reported in earlier versions of same... Leonard P.S. Hey Jon - this should probably go in the FAQ! -------------------------------------------------------------------------- Leonard Rosenthol Internet: leonardr@netcom.com Director of Advanced Technology AppleLink: MACgician Aladdin Systems, Inc. GEnie: MACgician +++++++++++++++++++++++++++ >From t.g.finstad@fys.uio.no (Terje Finstad) Date: Mon, 28 Feb 1994 20:03:40 Organization: Dept. Physics, Univ. Oslo In article , leonardr@netcom.com (Leonard Rosenthol) wrote: > In article <39602@mindlink.bc.ca>, first.ascent@mindlink.bc.ca (Alex > Curylo) wrote: > > I have a DITL resource, used in a CTB setup, that has a popup menu control in > > it. Since the popup menu would look much more cool in color, I created a > > 'mctb' for it in ResEdit, which displays the menu correctly. But when the > > menu is popped up in the dialog courtesy of the Dialog Manager, it's in bogus > > black and white. Is there some trick to getting a popup menu control to know > > about an 'mctb' for its 'MENU'? > > No trick - it doesn't work! The PopUpCDEF doesn't load the 'mctb' > resource due to visual problems reported in earlier versions of same... I may have totally misunderstood, I _had similar problems to what Alex Curylo. _Now I always get colors as I want to in the PopUp. Am I currently doing things wrong then? I am just calling insertmenu(myMenuHandle, -1) on a hit in the popup area and then PopUpMenuSelect , ( I've heard this is outdated, is that it? ) On startUp I just do a myMenuHandle := getmenu(kPopUpMenuID); I had previously been led to belive I should call deletemenu after the menu had been closed/hidden by PopUpMenuSelect. This caused the color to disappear. Now it does not. The menu does not get inserted multiple times in the menu list as far as I can tell ) Terje +++++++++++++++++++++++++++ >From mspace@netcom.com (Brian Hall) Date: Tue, 1 Mar 1994 05:37:07 GMT Organization: Mark/Space Softworks t.g.finstad@fys.uio.no (Terje Finstad) writes: >I may have totally misunderstood, >I _had similar problems to what Alex Curylo. _Now I always get colors as I >want to in the PopUp. Am I currently doing things wrong then? No, you are just doing them differnt. Alex is using (and Leonard replied about) the Popup Menu CDEF that was introduced with the CTB and made it into system software as of 7.0. You are doing it "by hand" so to speak. There are valid reasons for doing it that way, but most CTB apps use the CDEF since they get it for "free". -- __________________________________________________________________________ Brian Hall Internet: mspace@netcom.com Mark/Space Softworks AppleLink, AOL: MARKSPACE Macintosh connectivity software. info via anon ftp netcom.com:pub/mspace +++++++++++++++++++++++++++ >From Alexander M. Rosenberg Date: Wed, 2 Mar 1994 08:58:25 GMT Organization: Hackers Anonymous In article Leonard Rosenthol, leonardr@netcom.com writes: > > I have a DITL resource, used in a CTB setup, that has a popup menu control in > > it. Since the popup menu would look much more cool in color, I created a > > 'mctb' for it in ResEdit, which displays the menu correctly. But when the > > menu is popped up in the dialog courtesy of the Dialog Manager, it's in bogus > > black and white. Is there some trick to getting a popup menu control to know > > about an 'mctb' for its 'MENU'? > > > No trick - it doesn't work! The PopUpCDEF doesn't load the 'mctb' > resource due to visual problems reported in earlier versions of same... Actually, the problem is that the Popup CDEF (as of System 7.1) doesn't keep the menu in the menulist. 'mctb' resources are menu id referential and since the popup doesn't keep and defend an id, then 'mctb's can't be used. Note that Inside the Macintosh Communications Toolbox and Inside Macintosh VI don't say anywhere that 'mctb' resources are supported for popups. It was a fluke. :-) The workaround is to manually load a menu and associate it with the popup. MacApp uses this technique. --------------------------------------------------------------------------- - Alexander M. Rosenberg - INTERNET: alexr@apple.com - Yoyodyne - - 330 Waverley St., Apt B - UUCP:ucbvax!apple!alexr - Propulsion - - Palo Alto, CA 94301 - - Systems - - (415) 329-8463 - Nobody is my employer so - :-) - - (408) 974-3110 - nobody cares what I say. - - --------------------------- >From cnowak@bonnie.ics.uci.edu (Chris) Subject: TextEdit caret Date: 19 Feb 1994 15:50:08 -0800 Organization: UC Irvine Department of ICS I am working on a program, and have run into a slight snag. I have a textedit field on a grey background, so the caret doesn't show up very well... I have looked for a way to maybe change its color, or make it thicker but to no avail. Any ideas? Thanx, Chris ------------------------------------------------------------------------------- Chris Nowak |Why, yes, the world does revolve around me! cnowak@bonnie.ics.uci.edu |Unfortunately I can't control how fast it rotates. eapu109@orion.oac.uci.edu | ...actually, it's giving me a headache... ------------------------------------------------------------------------------- +++++++++++++++++++++++++++ >From peter@ncrpda.curtin.edu.au (Peter N Lewis) Date: 21 Feb 1994 11:56:16 +0800 Organization: NCRPDA, Curtin University cnowak@bonnie.ics.uci.edu (Chris) writes: >I am working on a program, and have run into a slight snag. I have a textedit >field on a grey background, so the caret doesn't show up very well... Well, don't put the text on a grey background then! Seriously, you shouldn't really do this without the user at least having control over the field, since the text will also be less readable. Perhaps just use a very light grey to differentiate it from other fields or the background? >I have looked for a way to maybe change its color, or make it thicker but to >no avail. There is a TEHook for drawing the cursor if I remember correctly. It's presumably documented in NIM-TE. It must be documented in IM somewhere, otherwise I wouldn't know about it... Peter. -- _______________________________________________________________________ Peter N Lewis Ph: +61 9 368 2055 +++++++++++++++++++++++++++ >From Here@There (Someone) Date: 1 Mar 1994 21:25:19 GMT Organization: Large Fuzzy Room In article <2k68jg$cvq@bonnie.ics.uci.edu>, cnowak@bonnie.ics.uci.edu (Chris) wrote: > I am working on a program, and have run into a slight snag. I have a textedit > field on a grey background, so the caret doesn't show up very well... > I have looked for a way to maybe change its color, or make it thicker but to Write a caret hook routine. This allows you to draw the caret yourself, in this case you could change it to any color you like that would show up better against gray. Or you could change the size. Here's a small sample caret hook I writ a while ago, it's in assembly, sorry, but you get the point... /* install the hook in the textedit record */ (*WordHandle)->caretHook=myCaretDraw; ; The actual caret hook routine myCaretDraw proc export move.l (sp)+,d0 ; get the rectangle pointer movem.l a2-a4/d3-d7,-(sp) ; save registers move.l d0,d3 ; store rect someplace safe pea myBackColor _RGBBackColor * caretOn is a global that you use to keep track of the caret state * now check your caretOn flag. if true, turn it off, if false, turn it on move.w caretOn,d0 bne.s @itsOn * myForeColor is a global RGB color I was using pea myForeColor ; make the caret visible _RGBForeColor moveq #1,d0 bra.s @saveanddraw @itsOn pea myBackColor ; make the caret invisible _RGBForeColor moveq #0,d0 @saveanddraw move.w d0,caretOn(a5) ; update the flag move.l d3,-(sp) _PaintRect movem.l (sp)+,a2-a4/d3-d7 ; restore regs rts ; and go away endp Somewhere, sometime SPA FON --------------------------- >From lsweet@netcom.com (Lawrence Sweet) Subject: What language should I learn? Date: Mon, 21 Feb 1994 23:00:03 GMT Organization: NETCOM On-line Communication Services (408 241-9760 guest) Hello... I've been using the Mac for about two years and now am becoming interested in what is behind the curtain, so to speak... I have no programming experience but I would like to learn something about how to do so, more as a hobbyist than anything else. I have looked through a variety of introductory programming texts for the Mac at my local bookstore, but I'm unsure which language to pursue or what book is well written enough to learn from. Could you please give me some suggestions? Thanks in advance, Larry (email is appreciated, also) -- Lawrence Sweet "Every wave is new until it breaks"San Diego, CA lsweet@netcom.com --Neil Young (1981) +++++++++++++++++++++++++++ >From drickey@irus.rri.uwo.ca (Daniel W. Rickey) Date: 22 Feb 1994 16:59:48 GMT Organization: Imaging Research Labs For someone who has never programmed before, the language to start with is with Pascal. A good book to start learning macinitosh programming is "Macinitosh Pascal Programming Primer". I am not sure what books are good for learning to programme in Pascal. 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 103t_english@west.cscwc.pima.edu Date: 23 Feb 94 00:10:41 MST Organization: (none) In article , lsweet@netcom.com (Lawrence Sweet) writes: > Hello... > > I've been using the Mac for about two years and now am becoming interested in > what is behind the curtain, so to speak... > > I have no programming experience but I would like to learn something about how > to do so, more as a hobbyist than anything else. I have looked through a > variety of introductory programming texts for the Mac at my local bookstore, > but I'm unsure which language to pursue or what book is well written enough to > learn from. > > Could you please give me some suggestions? > > Thanks in advance, Larry > > (email is appreciated, also) > -- > Lawrence Sweet "Every wave is new until it breaks"San Diego, CA lsweet@netcom.com --Neil Young (1981) At the risk of flames: learn SmallTalk/V. It will give you access to the ToolBox, but at the same time, you will learn OOP from the ground up. Lawson +++++++++++++++++++++++++++ >From gasser@masg1.epfl.ch (Laurent Gasser) Date: 23 Feb 1994 13:02:49 GMT Organization: Ecole Polytechnique Federale de Lausanne DO NOT learn pascal from the reference given below. The author have never used the WITH statement. In QuickDraw environement, it is incredible. Moreover, many examples are exactly illustrating bad pascal design. Il looks like they just translated C code into pascal. If you want to learn pascal, get a book about pascal. Later on, when you consider yourself more at ease with the language, you can look around for a book about the Macintosh plateform. Don't mix both steps, you will get lost. In article <2kddm4$462@falcon.ccs.uwo.ca>, drickey@irus.rri.uwo.ca (Daniel W. Rickey) writes: |> |> For someone who has never programmed before, the language to start |> with is with Pascal. A good book to start learning macinitosh |> programming |> is "Macinitosh Pascal Programming Primer". I am not sure what books |> are |> good for learning to programme in Pascal. |> |> 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 -- Laurent Gasser (gasser@dma.epfl.ch) I know very few ideas worth dying for, none is worth killing. +++++++++++++++++++++++++++ >From drickey@irus.rri.uwo.ca (Daniel W. Rickey) Date: 23 Feb 1994 15:36:24 GMT Organization: Imaging Research Labs >DO NOT learn pascal from the reference given below. >The author have never used the WITH statement. In QuickDraw >environement, it is incredible. Moreover, many examples are exactly >illustrating bad pascal design. Il looks like they just translated C >code into pascal. >If you want to learn pascal, get a book about pascal. Later on, when >you consider yourself more at ease with the language, you can look >around for a book about the Macintosh plateform. Don't mix both steps, >you will get lost. >In article <2kddm4$462@falcon.ccs.uwo.ca>, drickey@irus.rri.uwo.ca (Daniel W. >Rickey) writes: |> |> For someone who has never programmed before, the language to start |> with is with Pascal. A good book to start learning macinitosh |> programming |> is "Macinitosh Pascal Programming Primer". I am not sure what books |> are |> good for learning to programme in Pascal. |> |> Daniel W. Rickey |> drickey@.irus.rri.uwo.ca |> I recommended the book as as a reasonable one for learning how to programme the macintosh. I agree that it is not a good one for learning Pascal. -- >Laurent Gasser (gasser@dma.epfl.ch) >I know very few ideas worth dying for, none is worth killing. 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 peter@ncrpda.curtin.edu.au (Peter N Lewis) Date: 24 Feb 1994 10:56:50 +0800 Organization: NCRPDA, Curtin University gasser@masg1.epfl.ch (Laurent Gasser) writes: >DO NOT learn pascal from the reference given below. >The author have never used the WITH statement. In QuickDraw >environement, it is incredible. Moreover, many examples are exactly Well, I know nothing about the book, so I can't comment on that. But I will say that not using the WITH statement is a good idea. The WITH statement leads to lots of very subtle errors, and generally should be avoided. Peter. -- _______________________________________________________________________ Peter N Lewis Ph: +61 9 368 2055 +++++++++++++++++++++++++++ >From drickey@irus.rri.uwo.ca (Daniel W. Rickey) Date: 24 Feb 1994 15:00:54 GMT Organization: Imaging Research Labs >In article <2kh51i$50q@ncrpda.curtin.edu.au> >peter@ncrpda.curtin.edu.au (Peter N Lewis) writes: > gasser@masg1.epfl.ch (Laurent Gasser) writes: > > >DO NOT learn pascal from the reference given below. > > >The author have never used the WITH statement. In QuickDraw > >environement, it is incredible. Moreover, many examples are exactly > > Well, I know nothing about the book, so I can't comment on that. But > I will say that not using the WITH statement is a good idea. The WITH > statement leads to lots of very subtle errors, and generally should > be avoided. > Peter. > -- > _______________________________________________________________________ > Peter N Lewis Ph: +61 9 368 2055 The with satement should not be avoided. It should, however, be used with care. One can get in trouble using it by not knowing what record a field belongs to. I usually use it only when a line of code becomes too long. 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 casgrain@ERE.UMontreal.CA (Casgrain Philippe) Date: Thu, 24 Feb 1994 16:25:05 GMT Organization: Universite de Montreal drickey@irus.rri.uwo.ca (Daniel W. Rickey) writes: >>In article <2kh51i$50q@ncrpda.curtin.edu.au> >>peter@ncrpda.curtin.edu.au (Peter N Lewis) writes: >> I will say that not using the WITH statement is a good idea. The WITH >> statement leads to lots of very subtle errors, and generally should >> be avoided. >The with satement should not be avoided. It should, however, be used with >care. One can get in trouble using it by not knowing what record a field >belongs to. I usually use it only when a line of code becomes too long. I agree with Peter: what if you use 'with' to de-reference a handle (a common use), and the code between the 'with' and its 'end' moves memory? Now that could lead to nasty errors, would'nt it! If you want to use the "with" statement, IMHO you better be sure that your code does not move memory inside the statement. If you are not sure, do not use "with". Philippe -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Philippe Casgrain Etudiant-Chercheur Casgrain@ERE.UMontreal.CA Departement des Sciences Biologiques Universite de Montreal "Imitation is the sincerest form of flattery" +++++++++++++++++++++++++++ >From cshotton@oac.hsc.uth.tmc.edu (Chuck Shotton) Date: Thu, 24 Feb 1994 11:37:20 -0600 Organization: Academic Computing, UT-Houston In article , casgrain@ERE.UMontreal.CA (Casgrain Philippe) wrote: > drickey@irus.rri.uwo.ca (Daniel W. Rickey) writes: > > >>In article <2kh51i$50q@ncrpda.curtin.edu.au> > >>peter@ncrpda.curtin.edu.au (Peter N Lewis) writes: > >> I will say that not using the WITH statement is a good idea. The WITH > >> statement leads to lots of very subtle errors, and generally should > >> be avoided. > >The with satement should not be avoided. It should, however, be used with > >care. One can get in trouble using it by not knowing what record a field > >belongs to. I usually use it only when a line of code becomes too long. > > I agree with Peter: what if you use 'with' to de-reference a handle (a > common use), and the code between the 'with' and its 'end' moves > memory? Now that could lead to nasty errors, would'nt it! > > If you want to use the "with" statement, IMHO you better be sure that > your code does not move memory inside the statement. If you are not sure, > do not use "with". Code moving memory has nothing to do with the "safety" of a with statement. "With" is a compile-time construct that allows a shorthand notation to be used for complex record references. The COMPILER uses the identifier specified in the with statement, coupled with the offsets of fields within the record to generate references for the record fields you refer to in the body of the with statement. It has ABSOLUTELY nothing to do with what happens at runtime. It is merely a shorthand convenience for the author of Pascal code to use. The same code is generated whether a with statement or fully qualified record reference is used. The single biggest problem I have with the with statement is that it makes porting Pascal code to some other language a real pain if you are trying to automate the conversion. Not to mention the obvious readability problems.... --_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_\_-_-_-_-_-_-_-_-_-_-_-_-_-_-_- Chuck Shotton \ Assistant Director, Academic Computing \ "Are we there yet?" U. of Texas Health Science Center Houston \ cshotton@oac.hsc.uth.tmc.edu (713) 794-5650 \ _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-\-_-_-_-_-_-_-_-_-_-_-_-_- +++++++++++++++++++++++++++ >From casgrain@ERE.UMontreal.CA (Casgrain Philippe) Date: Thu, 24 Feb 1994 19:38:38 GMT Organization: Universite de Montreal cshotton@oac.hsc.uth.tmc.edu (Chuck Shotton) writes: >Code moving memory has nothing to do with the "safety" of a with statement. That's not what Scott Knaster says (in "How to write Macintosh Software, 3rd edition). This book is the origin of my remarks. Knaster used MPW Pascal, and I re-did his examples with MPW and THINK, and you will be surprised to know that a "with" statement actually de-references the handle/pointer/whatever in the compiled code. Hence the "may move memory" warning. If you want, I will be happy to fish out the exact quotation for you. Philippe B >"With" is a compile-time construct that allows a shorthand notation to be B >used for complex record references. The COMPILER uses the identifier >specified in the with statement, coupled with the offsets of fields within >the record to generate references for the record fields you refer to in >the body of the with statement. >It has ABSOLUTELY nothing to do with what happens at runtime. It is merely >a shorthand convenience for the author of Pascal code to use. The same code >is generated whether a with statement or fully qualified record reference >is used. >The single biggest problem I have with the with statement is that it makes >porting Pascal code to some other language a real pain if you are trying to >automate the conversion. Not to mention the obvious readability >problems.... >--_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_\_-_-_-_-_-_-_-_-_-_-_-_-_-_-_- >Chuck Shotton \ >Assistant Director, Academic Computing \ "Are we there yet?" >U. of Texas Health Science Center Houston \ >cshotton@oac.hsc.uth.tmc.edu (713) 794-5650 \ >_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-\-_-_-_-_-_-_-_-_-_-_-_-_- -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Philippe Casgrain Etudiant-Chercheur Casgrain@ERE.UMontreal.CA Departement des Sciences Biologiques Universite de Montreal "Imitation is the sincerest form of flattery" +++++++++++++++++++++++++++ >From lylem@vax.sonoma.edu (Michael R. Lyle) Date: Thu, 24 Feb 1994 13:00:33 -0800 Organization: Sonoma State University > B > >"With" is a compile-time construct that allows a shorthand notation to be > B -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Philippe Casgrain Etudiant-Chercheur Casgrain@ERE.UMontreal.CA > Departement des Sciences Biologiques Universite de Montreal > "Imitation is the sincerest form of flattery" Please note that the Pascal _STANDARD_ says that _with_ is executable. The orignal (Wirth) documents implied that it was only syntactic sugar, but all implementations made it executable, so the standard was changed in about 1981. Note: This means that once you have done _with_ on any data item, its address is probably in a register and that address will be used to reference it from then until the end of the scope of the _with_ statement. If the actual data item moves, your reference may well be invalid. >From an old Pascal teacher who still prefers it to C and C++.... -- Michael R. Lyle Sonoma State University Rohnert Park, CA 94928 lylem@sonoma.edu +++++++++++++++++++++++++++ >From siegel@netcom.com (Rich Siegel) Date: Fri, 25 Feb 1994 01:44:43 GMT Organization: Bare Bones Software In article cshotton@oac.hsc.uth.tmc.edu (Chuck Shotton) writes: > >Code moving memory has nothing to do with the "safety" of a with statement. >"With" is a compile-time construct that allows a shorthand notation to be >used for complex record references. The COMPILER uses the identifier >specified in the with statement, coupled with the offsets of fields within >the record to generate references for the record fields you refer to in >the body of the with statement. > >It has ABSOLUTELY nothing to do with what happens at runtime. It is merely >a shorthand convenience for the author of Pascal code to use. The same code >is generated whether a with statement or fully qualified record reference >is used. Oh, you think so, do you? :-) Here is a simple counter-example. Given this Pascal code: program Main; type RecordType = record fieldA: Integer; fieldB: Integer; end; RecordPtr = ^RecordType; RecordHandle = ^RecordPtr; procedure P (r: RecordHandle); begin with r^^ do begin fieldA := 10; fieldB := 20; end; end; procedure Q (r: RecordHandle); begin r^^.fieldA := 20; r^^.fieldB := 40; end; var r: RecordHandle; begin r := RecordHandle(NewHandle(SizeOf(RecordType))); p(r); q(r); end. THINK Pascal 2.0 and later will generate the following code for P and Q, respectively: P +0000 *LINK A6,#$0000 +0004 MOVE.L A4,-(A7) +0006 MOVEA.L $0008(A6),A0 +000A MOVEA.L (A0),A4 +000C MOVE.W #$000A,(A4) +0010 MOVE.W #$0014,$0002(A4) +0016 MOVEA.L (A7)+,A4 +0018 UNLK A6 +001A MOVE.L (A7)+,(A7) +001C RTS Q +0000 LINK A6,#$0000 +0004 MOVEA.L $0008(A6),A0 +0008 MOVEA.L (A0),A0 +000A MOVE.W #$0014,(A0) +000E MOVEA.L $0008(A6),A0 +0012 MOVEA.L (A0),A0 +0014 MOVE.W #$0028,$0002(A0) +001A UNLK A6 +001C MOVE.L (A7)+,(A7) +001E RTS Note that in P, the generated code places p^ into a register (a4 in this case), and then stores relative to the register. In Q, p^ is repeatedly generated into a temp (a0, in this case) which is then used to store. The WITH-clause is not a simple syntactic shorthand. The compiler is free to use the presence of a WITH-clause as a hint to the code generator to generate more efficient code, and most 68K Pascal compilers I've seen avail themselves of this hint. R. -- Rich Siegel % siegel@netcom.com % Principal, Bare Bones Software --> For information about BBEdit, finger bbedit@world.std.com <-- "He then proceeded to give a history of the universe, in real time." +++++++++++++++++++++++++++ >From drickey@irus.rri.uwo.ca (Daniel W. Rickey) Date: 25 Feb 1994 15:21:20 GMT Organization: Imaging Research Labs In article siegel@netcom.com (Rich Siegel) writes: > The WITH-clause is not a simple syntactic shorthand. The compiler is > free to use the presence of a WITH-clause as a hint to the code > generator to generate more efficient code, and most 68K Pascal > compilers I've seen avail themselves of this hint. > > R. > > -- > Rich Siegel % siegel@netcom.com % Principal, Bare Bones Software Well, one learns something new everyday. I too thought the with statement did not affect the code generation. Does this mean that we should never use a With statement to dereference a handle? I tend to use the With statement only to dereference pointers. 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 pottier@galion.ens.fr (Francois Pottier) Date: 25 Feb 1994 16:27:09 GMT Organization: Ecole Normale Superieure, PARIS, France In article <2kh51i$50q@ncrpda.curtin.edu.au>, Peter N Lewis wrote: >I will say that not using the WITH statement is a good idea. The WITH >statement leads to lots of very subtle errors, and generally should >be avoided. Well, I beg to differ. I'd rather say: the Mac Memory Manager leads to lots of very subtle errors, and you should generally avoid using with theHandle do or with theObject do constructs, unless you are certain not to move memory. Also, OOP can be dangerous. Since every method contains a implicit "with Self do" construct, moving memory could move your object from under you. If you know about those pitfalls and carefully avoid them, there is nothing wrong with the with construct... For instance, when filling a parameter block, using a with construct is much more elegant than the C way: paramBlock.ioVRefNum = ... paramBlock.ioDirID = ... which is very redundant. Cheers, -- Francois Pottier ___ ___ _ _ / ___ ___ ___ pottier@dmi.ens.fr /_ /__/ /_| /| / / / / / / /__ / / \ / | / |/ /___ /__/ / ___/ _ / +++++++++++++++++++++++++++ >From mxmora@unix.sri.com (Matt Mora) Date: 25 Feb 1994 08:27:47 -0800 Organization: SRI International, Menlo Park, CA In article <2kl51g$9hb@falcon.ccs.uwo.ca> drickey@irus.rri.uwo.ca (Daniel W. Rickey) writes: >In article >siegel@netcom.com (Rich Siegel) writes: >> The WITH-clause is not a simple syntactic shorthand. The compiler is >> free to use the presence of a WITH-clause as a hint to the code >> generator to generate more efficient code, and most 68K Pascal >> compilers I've seen avail themselves of this hint. >Well, one learns something new everyday. I too thought the with >statement did not affect the code generation. Does this mean that we >should never use a With statement to dereference a handle? I tend to >use the With statement only to dereference pointers. Works with handles just fine. Just lock them first. I was supprised to see Peter bash this cool feature of Pascal. I was told that features like this help Pascal compilers optimize code better than c ever could. Xavier -- ___________________________________________________________ Matthew Xavier Mora Matt_Mora@qm.sri.com SRI International mxmora@unix.sri.com 333 Ravenswood Ave Menlo Park, CA. 94025 +++++++++++++++++++++++++++ >From casgrain@ERE.UMontreal.CA (Casgrain Philippe) Date: Fri, 25 Feb 1994 19:24:45 GMT Organization: Universite de Montreal pottier@galion.ens.fr (Francois Pottier) writes: >Well, I beg to differ. I'd rather say: the Mac Memory Manager leads to lots >of very subtle errors, and you should generally avoid using > with theHandle do >or > with theObject do >constructs, unless you are certain not to move memory. Well ;-> if you are not certain about the moving memory stuff (some toolbox calls move memory indirectly, by calling other toolbox calls that themselves move memory), you can always lock your handles before the "with" (HLock) and unlock them after (HUnlock). Be careful not to leave your handles locked for too long, as your heap will become fragmented. On a related note, the TB calls that move memory usually are documented as such (for example, there's the little "memory chip" icon in THINK Reference), but there are probably some errors and omissions, although I can't think of any offhand. Anyone? Anyone? Philippe -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Philippe Casgrain Etudiant-Chercheur Casgrain@ERE.UMontreal.CA Departement des Sciences Biologiques Universite de Montreal "Imitation is the sincerest form of flattery" +++++++++++++++++++++++++++ >From siegel@netcom.com (Rich Siegel) Date: Fri, 25 Feb 1994 20:20:44 GMT Organization: Bare Bones Software In article <2kl51g$9hb@falcon.ccs.uwo.ca> drickey@irus.rri.uwo.ca (Daniel W. Rickey) writes: > >Well, one learns something new everyday. I too thought the with >statement did not affect the code generation. Does this mean that we >should never use a With statement to dereference a handle? I tend to >use the With statement only to dereference pointers. "never" is a little strong. Use it any way you like, but just be aware of the implications when you do. R. -- Rich Siegel % siegel@netcom.com % Principal, Bare Bones Software --> For information about BBEdit, finger bbedit@world.std.com <-- "He then proceeded to give a history of the universe, in real time." +++++++++++++++++++++++++++ >From cshotton@oac.hsc.uth.tmc.edu (Chuck Shotton) Date: Fri, 25 Feb 1994 19:43:38 -0600 Organization: UT Houston Academic Computing In article , siegel@netcom.com (Rich Siegel) wrote: > In article cshotton@oac.hsc.uth.tmc.edu (Chuck Shotton) writes: > > Oh, you think so, do you? :-) > > Here is a simple counter-example. > [code snipped] > The WITH-clause is not a simple syntactic shorthand. The compiler is > free to use the presence of a WITH-clause as a hint to the code > generator to generate more efficient code, and most 68K Pascal > compilers I've seen avail themselves of this hint. You are correct. Mac compiler writers have implemented the "with" in a non-safe fashion. The Jensen & Wirth book never indicates how code is to be generated for this statement, but very clearly identifies it as a syntactic short cut rather than a cue to the code generator. To me, that should indicate that the non-safe code generated by Mac compilers when dereferenced pointers and handles are "withed" is not exactly compliant with the standard. ----------------------------------------------------------------------- Chuck Shotton cshotton@oac.hsc.uth.tmc.edu "I am NOT here." +++++++++++++++++++++++++++ >From peter@ncrpda.curtin.edu.au (Peter N Lewis) Date: 27 Feb 1994 12:46:09 +0800 Organization: NCRPDA, Curtin University mxmora@unix.sri.com (Matt Mora) writes: >Works with handles just fine. Just lock them first. I was supprised to see >Peter bash this cool feature of Pascal. I was told that features like >this help Pascal compilers optimize code better than c ever could. True, that and for loops and generally many fewer pointers (pointers confuse the heck out of optimizers in general). The with statement has its place, but it must be used very causiously. It can cause problems if you do "with h^" and the handle moves inside the with statement. It can cause problems if you "with rec", and rec contains fields that clash with global or local variables (this is especially painful when global or local variables clash with object variables, since THINK Pascal puts in a "with self" implicitly). It's also interesting to note that most compilers won't generate less efficient code for these two: pb.a := 1; pb.b := 2; .. as compared with with pb do begin a := 1; b := 2; ... end; In any event, my advice, especially to beginning programmers is to avoid the with statement as a general rule until you really understand what it does and what its dangers are. Of course, you can't avoid the implicit "with self", so you better learn about those dangers pretty quick! Peter. -- Peter N Lewis Ph: +61 9 368 2055 +++++++++++++++++++++++++++ >From peter@ncrpda.curtin.edu.au (Peter N Lewis) Date: 27 Feb 1994 12:49:57 +0800 Organization: NCRPDA, Curtin University casgrain@ERE.UMontreal.CA (Casgrain Philippe) writes: >On a related note, the TB calls that move memory usually are documented >as such (for example, there's the little "memory chip" icon in THINK >Reference), but there are probably some errors and omissions, although I >can't think of any offhand. Anyone? Anyone? My policy is to assume everything can move memory except BlockMove, PBRead and PBWrite (and FSRead and FSWrite). As a general rule, they are the only common routines that you use with handle data that are handle-safe. Remember that you aren't only dealing with what the OS does now, but also what it might do in the future (witness SysBeep), and also what broken inits (like some from Apple! ;-) that change the memory-safeness of routines. Peter. -- Peter N Lewis Ph: +61 9 368 2055 +++++++++++++++++++++++++++ >From quinn@uniwa.uwa.edu.au (Quinn "The Eskimo!") Date: 27 Feb 1994 13:29:06 +0800 Organization: The University of Western Australia mxmora@unix.sri.com (Matt Mora) writes: >[...] I was supprised to see >Peter bash this cool feature of Pascal. I was told that features like >this help Pascal compilers optimize code better than c ever could. But Pete uses Pascal because it's safer, not because it produces better code. The with statement is wildly unsafe because it brings identifiers into scope with very little warning. [In that respect it's very like Pascal's uses clause which is also braindead, especially wehn compared to Modula 2's import/export mechanism.] What I'd like to see is the with statement redone so that it doesn't introduce new identifiers invisibly. For example instead of doing this... with graf_ptr^.pnLoc do begin frog := h; end; (* with *) you get something more like this... with my_pn_loc ::= graf_ptr^.pnLoc do frog := my_pn_loc.h; end-with; The second version introduces a name for the temporary result, which you then use in a qualified fashion. Much safer IMHO. -- Quinn "The Eskimo!" "Support HAVOC!" Department of Computer Science, The University of Western Australia I hate unix!!! I hate nn!!! I wan't my static IP number back ): -- Quinn "The Eskimo!" "Support HAVOC!" Department of Computer Science, The University of Western Australia I hate unix!!! +++++++++++++++++++++++++++ >From peter@ncrpda.curtin.edu.au (Peter N Lewis) Date: 28 Feb 1994 11:25:24 +0800 Organization: NCRPDA, Curtin University cshotton@oac.hsc.uth.tmc.edu (Chuck Shotton) writes: >You are correct. Mac compiler writers have implemented the "with" in a It's not just Mac compilers, it's how every compiler I've ever seen (and indeed every compiler I've ever written!) has implemented the with statement. If thats not part of the standard, then it's the standard that is wrong. But the fact is that it doesn't matter which way it's implemented, this would still be dangerous: with p^ do begin Dispose(p); x := 5; end; Where x is a local variable and a field of p^. The only reason it is unsafe with handles is because of the Mac's treatment of handles as movable. But it would still be unsafe under other OSes if other conditions like the above happened. Peter. -- Peter N Lewis Ph: +61 9 368 2055 +++++++++++++++++++++++++++ >From D.A.G.Gillies@bradford.ac.uk (DAG GILLIES) Date: Mon, 28 Feb 1994 13:28:18 GMT Organization: University of Bradford, UK In article <2kl8u3$ao@unix.sri.com> mxmora@unix.sri.com (Matt Mora) writes: >In article <2kl51g$9hb@falcon.ccs.uwo.ca> drickey@irus.rri.uwo.ca (Daniel W. Rickey) writes: >>In article >>siegel@netcom.com (Rich Siegel) writes: > >>> The WITH-clause is not a simple syntactic shorthand. The compiler is >>> free to use the presence of a WITH-clause as a hint to the code >>> generator to generate more efficient code, and most 68K Pascal >>> compilers I've seen avail themselves of this hint. > >>Well, one learns something new everyday. I too thought the with >>statement did not affect the code generation. Does this mean that we >>should never use a With statement to dereference a handle? I tend to >>use the With statement only to dereference pointers. > > >Works with handles just fine. Just lock them first. I was supprised to see >Peter bash this cool feature of Pascal. I was told that features like >this help Pascal compilers optimize code better than c ever could. > Am I missing something here, or am I mistaken when I recall that in the first few pages of Volume I of (old) Inside Mac, there is a specific warning about locking handles before dereferencing them, and that the Pascal WITH statement can cause an implicit dereference. There was a code fragment along the lines of HLock(aHandle) WITH aHandle DO ... ... ... HUnlock(aHandle) I mean, if it's in IM, why all the controversy? ______________________________________________________ David A. G. Gillies (D.A.G.Gillies@bradford.ac.uk) (c) 1994 Wittgenstein's Amazing Underwater Supermarket ---------------REPLIES VIA EMAIL PLEASE--------------- _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ +++++++++++++++++++++++++++ >From neeri@iis.ee.ethz.ch (Matthias Neeracher) Date: 28 Feb 94 17:38:00 Organization: Integrated Systems Laboratory, ETH, Zurich In article , cshotton@oac.hsc.uth.tmc.edu (Chuck Shotton) writes: > In article , siegel@netcom.com (Rich Siegel) > wrote: >> The WITH-clause is not a simple syntactic shorthand. The compiler is >> free to use the presence of a WITH-clause as a hint to the code >> generator to generate more efficient code, and most 68K Pascal >> compilers I've seen avail themselves of this hint. > You are correct. Mac compiler writers have implemented the "with" in a > non-safe fashion. The Jensen & Wirth book never indicates how code is to be > generated for this statement, but very clearly identifies it as a syntactic > short cut rather than a cue to the code generator. To me, that should > indicate that the non-safe code generated by Mac compilers when > dereferenced pointers and handles are "withed" is not exactly compliant > with the standard. A few comments: - Jensen & Wirth is not the Pascal Standard. - At least one ETH Modula-2 compiler, which certainly was authorized by Wirth, does no register allocation except to use two of the address registers for the two innermost WITH statements. - I would suspect that something similar was done for many Pascal compilers. - The reason why this is not mentioned is probably that J&W were not concerned with such problems, and indeed, this problem is not very important outside of a handle based environment. Matthias ----- Matthias Neeracher neeri@iis.ee.ethz.ch "One fine day in my odd past..." -- Pixies, _Planet of Sound_ +++++++++++++++++++++++++++ >From peirce@outpost.SF-Bay.org (Michael Peirce) Date: Mon, 28 Feb 94 10:42:19 PST Organization: Peirce Software, Inc. In article (comp.sys.mac.programmer), cshotton@oac.hsc.uth.tmc.edu (Chuck Shotton) writes: > In article , siegel@netcom.com (Rich Siegel) > wrote: > > > In article cshotton@oac.hsc.uth.tmc.edu (Chuck Shotton) writes: > > > > Oh, you think so, do you? :-) > > > > Here is a simple counter-example. > > [code snipped] > > The WITH-clause is not a simple syntactic shorthand. The compiler is > > free to use the presence of a WITH-clause as a hint to the code > > generator to generate more efficient code, and most 68K Pascal > > compilers I've seen avail themselves of this hint. > > You are correct. Mac compiler writers have implemented the "with" in a > non-safe fashion. The Jensen & Wirth book never indicates how code is to be > generated for this statement, but very clearly identifies it as a syntactic > short cut rather than a cue to the code generator. To me, that should > indicate that the non-safe code generated by Mac compilers when > dereferenced pointers and handles are "withed" is not exactly compliant > with the standard. Don't blame just Mac Pascal compilers. I know of at least one PDP-11 Pascal compiler that does this same thing. I expect there are others. (I think the VAX Pascal compiler did this too) Frankly, I wish there was a similar construct in c - or at least C compilers that were smart enough to dereference a struct into a register instead of constantly redereferencing. The Pascal code is much more efficient in this case. (A good example of this is filling in a BIG parameter block). -- Michael Peirce -- peirce@outpost.sf-bay.org -- Peirce Software, Inc. -- 719 Hibiscus Place, Suite 301 -- -- San Jose, California USA 95117 -- Makers of: Smoothie & -- voice: +1.408.244.6554 fax: +1.408.244.6882 -- Peirce Print Tools -- AppleLink: peirce & America Online: AFC Peirce +++++++++++++++++++++++++++ >From platypus@cirrus.som.cwru.edu (Gary Kacmarcik) Date: 02 Mar 1994 01:01:15 GMT Organization: Case Western Reserve University, Cleveland, Ohio (USA) In article peirce@outpost.SF-Bay.org (Michael Peirce) writes: > In article (comp.sys.mac.programmer), cshotton@oac.hsc.uth.tmc.edu (Chuck Shotton) writes: > > In article , siegel@netcom.com (Rich Siegel) > > wrote: > > > > > > The WITH-clause is not a simple syntactic shorthand. The compiler is > > > free to use the presence of a WITH-clause as a hint to the code > > > generator to generate more efficient code, and most 68K Pascal > > > compilers I've seen avail themselves of this hint. > > > > You are correct. Mac compiler writers have implemented the "with" in a > > non-safe fashion. The Jensen & Wirth book never indicates how code is to be > > generated for this statement, but very clearly identifies it as a syntactic > > short cut rather than a cue to the code generator. To me, that should > > indicate that the non-safe code generated by Mac compilers when > > dereferenced pointers and handles are "withed" is not exactly compliant > > with the standard. > > Don't blame just Mac Pascal compilers. I know of at least one PDP-11 > Pascal compiler that does this same thing. I expect there are others. > (I think the VAX Pascal compiler did this too) > > Frankly, I wish there was a similar construct in c - or at least C > compilers that were smart enough to dereference a struct into a register > instead of constantly redereferencing. The Pascal code is much more > efficient in this case. (A good example of this is filling in a BIG > parameter block). ummm... i don't understand your comment that Pascal is "much more efficient" in this case. without the "with" statement, comparable compilers should generate code which is equally "bad". if you have the "with" statement in Pascal, then you need to add the equivalent in C: which is an assignment statement which saves the dereferenced handle/ptr. again, the code should be comparable. (if not, you should get a better compiler ;-) C expects you to explicitly store the value in a temp variable, which is exactly what the "with" statement (as described above) does. i don't see any real need for a "with" statement - it makes the code slightly less explicit and potentially confusing (eg: with multiple "with"s into structures that have fields/records with the same name). being explicit (either in C or Pascal) makes the code more readable: i detest reading Pascal code where the programmer uses multiple nested "with" statements because it makes it much more difficult to identify which struct the field belongs to. -gary j kacmarcik platypus@curie.ces.cwru.edu --------------------------- End of C.S.M.P. Digest **********************