dcw@goldilocks.lcs.mit.edu (David C. Whitney) (09/07/90)
I wouldn't exactly call this a bug, but in can get a bit annoying... Ever do a single-drive disk to disk copy? I mean, say you have to back up SYSTEM.DISK, and you only have one drive. Pop in the source disk and eject it by hitting the button on the drive. The icon greys (if there are windows open, all those icons grey too). Now pop in the destination disk and drag the grey to the solid. The copy progresses. No problems here. The deal is, GS/OS remembers all the disk inserts/ejects that happen during the copy. When the copy is all done, it "plays out" all those ejects and inserts. Any displayed icons grey and solidify repeatedly - once for each disk switch. This can be amusing the first time, but it really shouldn't be happening... Shouldn't the copy routine be absorbing the disk insert/eject events for those disks being copied? Assuming that a Multifinder-like program will be available sooner or later, disk insert and eject events should not all be killed - only those correspoding to the disks being copied. Well? Huh? So? -- Dave Whitney | I wrote Z-Link and BinSCII. Send me bug Computer Science MIT 1990 | reports. I need a job. Send me an offer. dcw@goldilocks.lcs.mit.edu | My opinions, you hear? MINE! dcw@athena.mit.edu | Are you sure you know what you're doing?
unknown@ucscb.ucsc.edu (The Unknown User) (09/08/90)
Dave Whitney writes: >The deal is, GS/OS remembers all the disk inserts/ejects that happen >during the copy. When the copy is all done, it "plays out" all those >ejects and inserts. Any displayed icons grey and solidify repeatedly >- once for each disk switch. This can be amusing the first time, but >it really shouldn't be happening... Yeah, I've noticed this quirk and another one I'll describe in a minute.. For some reason I never connected the fact that it kept selecting and deselecting the icons because of the multiple switches, but it's obvious once you say so! [duhh!] Another one I've noticed is that if you eject a disk manually (and keep it's icon there.. I don't think the disk has to be actually opened.. i.e. a window for the disk's contents), then go around doing other file manipulation and such, it will ASK for that greyed out disk that has ABSOLUTELY NOTHING to do with the disk/file copying you're currently doing.. And no, I don't mean it'll ask for a system disk for tools or info or something.. it'll ask for any ol' disk in situations where it seems like it shouldn't care diddley about that disk. As I've implied, I don't have an exact set of instructions for making this happen, but it happens a fair amount. -- / Apple II(GS) Forever! unknown@ucscb.ucsc.edu \ \ Computer engineering student seeking a job. /
toddpw@tybalt.caltech.edu (Todd P. Whitesel) (09/08/90)
What you guys need to understand is the way these things are coded. Desktop programs can get pretty nastily complex, and when it comes to handling changes in the environment (like disks getting ejected without the O/S noticing it right away) it is often practically impossible to handle every case intelligently without _seriously_ rewriting a _lot_ of code. Often, finder (our main example) will call a generic routine because it needs some info or other. However, this generic routine was designed for more cases than what each call requires -- for instance, finder is doing something or other and calls a routine that checks up on all the online disks to make sure the important ones haven't disappeared. However, the routine isn't told WHICH disks can't have disappeared, it just asks the user to insert everything! So you hit cancel on the irrelevant disks and all is well. But it IS annoying. (NOTE! THIS IS ME SECOND GUESSING FINDER. I DON'T KNOW FOR SURE IF THIS IS THE ACTUAL REASON FINDER DOES IT.) What would it take to fix the problem? Rewriting the routine so that it is told which disks to make sure are online, and rewriting EVERY invocation of that routine so that the appropriate disks are checked. Depending on how the program is organized, this could be a real pain in the neck. Again, I do not know if this really applies to finder, but I am willing to bet that it is a similar mechanism that is causing the superfluous dialogs. Todd Whitesel toddpw @ tybalt.caltech.edu
jason@madnix.UUCP (Jason Blochowiak) (09/14/90)
toddpw@tybalt.caltech.edu (Todd P. Whitesel) writes: >What you guys need to understand is the way these things are coded. Desktop >programs can get pretty nastily complex, [...] [Deleted mention that he was only speaking figuratively, and not about the specific way that the Finder (tm) is coded] >What would it take to fix the problem? Rewriting the routine so that it is >told which disks to make sure are online, and rewriting EVERY invocation of >that routine so that the appropriate disks are checked. Depending on how the >program is organized, this could be a real pain in the neck. Ick! There are two simple ways around this sort of thing: 1) Write a macro. A macro facility is provided for every serious language available on the GS. The macro would automatically provide the "missing" parms (would could be NIL, or somesuch) for calls to the "old" routine (the name of which would be the name of the macro, and the new name would be some derivation). 2) Since some people take an (obviously) perverse pleasure in writing in odd languages, and since assembly programmers typically don't use macros for function calls, it would be possible to effectively make a "code macro." This would be pretty much the same thing as #1, but it would insert the parameters runtime... Now, if we just had a nice OOP system for the GS, this could all become irrelevant! >Todd Whitesel >toddpw @ tybalt.caltech.edu -- Jason B. - jason@madnix.UUCP or astroatc!nicmad!madnix!jason@spool.cs.wisc.edu I'm now working at SoftDisk, Inc. Of course, what I say is what I say, and not what they say... I will be calling this account for awhile & dealing with mail here, but I won't be calling nearly as frequently as I used to.
gwyn@smoke.BRL.MIL (Doug Gwyn) (09/16/90)
In article <1546@madnix.UUCP> jason@madnix.UUCP (Jason Blochowiak) writes: >Now, if we just had a nice OOP system for the GS, this could all become >irrelevant! When you consider that both Objective C and C++ are normally implemented to generate regular C code that is then compiled, it should be clear that C already offers sufficient support for object-oriented programming. All that is needed is a comprehensive plan backed up by programmer discipline. To achieve object-like encapsulation, that in itself would suffice. To implement inheritance, late binding is required and thus there must be a small run-time support module. An entire object-oriented framework can be constructed with one header file and one library module.
rhyde@ucrmath.ucr.edu (randy hyde) (09/18/90)
Have you *LOOKED* at the code C++ puts out? I'd hate to try and read that kind of code. :-) *** Randy Hyde O-)
gwyn@smoke.BRL.MIL (Doug Gwyn) (09/18/90)
In article <8678@ucrmath.ucr.edu> rhyde@ucrmath.ucr.edu (randy hyde) writes: >Have you *LOOKED* at the code C++ puts out? I'd hate to >try and read that kind of code. :-) What does that have to do with anything? As a matter of fact, I not only have *LOOKED* at the output of C++, but I even maintain "dmdpi" source code in both its original C++ form and in the resulting C output from cfront (which somebody was once nice enough to generate for me on another system -- we don't have a C++ license here).
bird@cbnewsd.att.com (j.l.walters) (09/18/90)
From article <8678@ucrmath.ucr.edu>, by rhyde@ucrmath.ucr.edu (randy hyde): > Have you *LOOKED* at the code C++ puts out? I'd hate to > try and read that kind of code. :-) > *** Randy Hyde O-) I wasn't aware that there was a version of C++ available for the IIgs or is this an oblique/funny reference that I fail to see? i.e., I don't think anyone expects you to look at the C++ output. the expectation is that you have an environment that supports C++ and protects you from that uglyness. If not, don't blame C++, blame the sucker that sold you cfront without an environment that supports it. -- Joe Walters att!ihlpf!bird IH 2A-227 (708) 979-9527
rhyde@ucrmath.ucr.edu (randy hyde) (09/18/90)
I believe you are expecting too much from people if you're expecting them to hand code like that. It's difficult for most people to maintain. Maybe you're the except. Most people go crazy when they start dealing with pointers like that.
gwyn@smoke.BRL.MIL (Doug Gwyn) (09/18/90)
In article <8703@ucrmath.ucr.edu> rhyde@ucrmath.ucr.edu (randy hyde) writes: >I believe you are expecting too much from people if you're expecting them to >hand code like that. It's difficult for most people to maintain. Maybe you're >the except. Most people go crazy when they start dealing with pointers like >that. As I said previously, I don't see the relevance of the thread you've started here. I never suggested that anyone code in the style of C++ output. What I suggested was that one can comfortably obtain object-oriented programming support C through use of a single header and run-time support module, plus programmer discipline (which is required anyway); the C language has all the necessary facilities and it is just a matter of organizing your use of them.
gwyn@smoke.BRL.MIL (Doug Gwyn) (09/20/90)
In article <1990Sep17.234307.7286@cbnewsd.att.com> bird@cbnewsd.att.com (j.l.walters) writes: >From article <8678@ucrmath.ucr.edu>, by rhyde@ucrmath.ucr.edu (randy hyde): >> Have you *LOOKED* at the code C++ puts out? I'd hate to >I wasn't aware that there was a version of C++ available for the >IIgs or is this an oblique/funny reference that I fail to see? Please don't respond to discussion threads that you haven't been following; it merely adds to the confusion. The thread started with an inquiry about availability of OOPS for the IIGS, which of course there aren't, at least not in the form that they are usually hyped. I remarked that standard C was actually already capable of supporting OOP, if one exercised the required discipline and came up with a small amount of support code. (In fact I plan to do this some day in the near future.) The note from rhyde that you cited was apparently intended as a comment on what OOP in standard C would look like, by comparing it to the C code produced by cfront. In a subsequent follow-up I noted that that was not what I had actually proposed as the OOP implementation method.