AWCTTYPA@UIAMVS.BITNET ("David A. Lyons") (03/06/89)
>Date: Mon, 6 Mar 89 01:06:02 GMT >From: Jeff Erickson <claris!krazy@APPLE.COM> >Subject: Re: GS/OS and programming standard >> This seems obvious, but I do _not_ recommend you test your >> _under-development_ applications under GS/OS with a hard drive turned >> on, unless the volume is expendable. I have trouble feeling >> sympathetic for you since you let it happen SEVEN TIMES. > >That's great, but my application has to run under GS/OS. This means >I have to test it under GS/OS. Period. I understand the problem: >GS/OS doesn't checksum its cache. In the light of the fact >that new application HAVE to be tested under this operating system, >that's unforgivable. I didn't say not to test it with GS/OS. I said not with a non-expendable hard drive! If you don't want to boot GS/OS off of 3.5 drives, surely your employer can afford extra HDs for testing purposes, so you can keep your important ones offline during testing. >In any case, my disk cache has been set at 0k for as long as I can >remember, at least according to the NDA. When you set the cache size to 0, there is still a 16K cache inside. You can't turn it off completely. (This info comes from the team that wrote it, from Apple II Development chats on ALPE in recent months.) >Now I know. But if it's so trivial, why don't the tools do it for >you, like the Mac tools do. Sure, the application CAN eject the disk >itself, but I don't know of any that DO. That's news to me--I always assumed that applications on the Mac were responsible for asking the system to eject disks. If not, how does/should it work? Should GS/OS eject a disk, chosen at random?, whenever it would report "volume not found"? How can it know whether the disk you're about to insert is a 3.5, a 5.25, a CD-ROM disk, etc, given only the disk's name? >>I once asked Apple's Developer Tech Support why the standard file >>dialogs didn't have an "Eject" button.... >When I asked, I was wondering why they weren't being more consistent >with the Mac interface they are trying to emulate. No need, per se, >I just thought it would be NICE. I object to the implication that there's nothing more behind the GS toolbox design than wanting to be the Mac's little brother. Things like the SF Eject button aren't strictly necessary for the GS, so there is a difference in the way Standard File looks. (That's not the only difference.) But there are things the GS has done better than the Mac, too--like window scroll bars that show you how much of the content you're seeing, and TaskMaster. >> It isn't terribly useful to assert that the system is "very buggy." >> I don't agree. I've worked with the machine for just as long [...] > >Please, let's not get into "I'm more qualified to talk about the machine >than you are" arguments. I've reported bugs in prerelease system software, >and most of them have been fixed. Not all. That wasn't my intention--sorry if it sounded that way. My point was that if System 4.0 is as buggy as you make it sound, I'd much rather hear _specific_ bug reports. I haven't had many problems. >Most recently, the responses sounded something like "yeah, that's a >bug, but it's too late, we've already released the system. You'll >have to figure out some way to work around it. Sorry." That sounds like a reasonable _partial_ response to me. They can't fix it _retroactively_...you have to work around it until the next system disk release. I have a lot of trouble imagining them saying "Yeah, it's a bug, and we like it. We're keeping it." > Any opinions you read here are only opinions in my opinion. >Jeff Erickson krazy@claris.com --David A. Lyons bitnet: awcttypa@uiamvs DAL Systems CompuServe: 72177,3233 P.O. Box 287 GEnie mail: D.LYONS2 North Liberty, IA 52317 AppleLinkPE: Dave Lyons
krazy@claris.com (Jeff Erickson) (03/07/89)
From article <8903060413.aa11956@SMOKE.BRL.MIL>, by AWCTTYPA@UIAMVS.BITNET ("David A. Lyons"):
>>> This seems obvious, but I do _not_ recommend you test your
>>> _under-development_ applications under GS/OS with a hard drive turned
>>> on, unless the volume is expendable.
>>That's great, but my application has to run under GS/OS. This means
>>I have to test it under GS/OS.
> I didn't say not to test it with GS/OS. I said not with a
> non-expendable hard drive! If you don't want to boot GS/OS off of
> 3.5 drives, surely your employer can afford extra HDs for testing
> purposes, so you can keep your important ones offline during testing.
Wait. "During testing"? Perhaps we disagree on methodology here. I
fix a bug. I run it on my system immediately to see if it works. I don't
generally have TIME to turn of my hard drive just to see if my fix worked.
I considered switching back to P16 on my source drive the first time it
died. The speed gains outweighed the time it takes to re-initialize and
restore my hard drive. (Daily backups are your friend...)
> When you set the cache size to 0, there is still a 16K cache inside.
> You can't turn it off completely.
So I have since been told by wombat@claris.
>>Now I know. But if it's so trivial, why don't the tools do it for
>>you, like the Mac tools do. Sure, the application CAN eject the disk
>>itself, but I don't know of any that DO.
>
> That's news to me--I always assumed that applications on the Mac
> were responsible for asking the system to eject disks. If not, how
> does/should it work? Should GS/OS eject a disk, chosen at random?,
> whenever it would report "volume not found"? How can it know
> whether the disk you're about to insert is a 3.5, a 5.25, a CD-ROM
> disk, etc, given only the disk's name?
No. I think the rule when the Mac OS wants a disk is it ejects the
least recently used one.
Okay, you got me here. I keep forgetting about those damn 5 1/4"
floppies. Your point.
> I object to the implication that there's nothing more behind the GS
> toolbox design than wanting to be the Mac's little brother. Things
> like the SF Eject button aren't strictly necessary for the GS, so
> there is a difference in the way Standard File looks. (That's not
> the only difference.) But there are things the GS has done better
> than the Mac, too--like window scroll bars that show you how much
> of the content you're seeing, and TaskMaster.
I wasn't implying that. I was implying that if Apple does eventually
want Apple II users to move over to the Mac (likely), they ought to
make the interfaces consistent. I agree that there are some things
the GS does much better interface-wise. The Mac should adopt them.
> ...if System 4.0 is as buggy as you make it sound, I'd much rather
> hear _specific_ bug reports. I haven't had many problems.
Three bugs come to mind immediately:
1. If a scaled font gets purged, and you request the same font again,
you get garbage.
2. If you call DrawPicture when there is not enough memory to duplicate
the picture, the tool dies rather than returning a memory error. This
situation commonly occurs while printing.
3. If you call ChooseFont, and there is a non-empty update region in
the frontmost window, it tries to update it by calling the update routine
stored in the window record. If you aren't using TaskMaster, there's
usually a zero there, and ChooseFont doesn't check. It just dies.
All of these bugs have been reported to Apple II DTS, and confirmed.
> That sounds like a reasonable _partial_ response to me. They can't
> fix it _retroactively_...you have to work around it until the next
> system disk release. I have a lot of trouble imagining them saying
> "Yeah, it's a bug, and we like it. We're keeping it."
These bugs would probably have been found before release if Apple hadn't
pushed so hard to get GS/OS released. Fortunately, last I heard, they are
fixing them.
> --David A. Lyons
--
Jeff Erickson \ Internet: krazy@claris.com AppleLink: Erickson4
Claris Corporation \ UUCP: {ames,apple,portal,sun,voder}!claris!krazy
415/960-2693 \________________________________________________________
____________________/ "I'm so heppy I'm mizzabil!"c08_d042@jhunix.HCF.JHU.EDU (Stdnt 42) (03/08/89)
In article <9011@claris.com> krazy@claris.com (Jeff Erickson) writes: >Okay, you got me here. I keep forgetting about those damn 5 1/4" >floppies. Your point. This discussiu`on brings something to mind. There's ways to check to see if there's a disk in a 5.25" drive so that it *doesn't* slamm the r/w head. Most well written games and older utilities (like create with garfield) used it. It only takes about 3/4 second, or faster even, to find if there is a disk in the drive ready to be read. and what's important here is that the drive doesn't make that *annoying as all hell* four second slamming and re- trying noise. It requires custom routine, however, since Prodos uses the retard method. If Prodos did it this way tho...nobody would be bitchin about 5.25" drives not being suitable for gs's. >-- >Jeff Erickson \ Internet: krazy@claris.com AppleLink: Erickson4 >Claris Corporation \ UUCP: {ames,apple,portal,sun,voder}!claris!krazy >415/960-2693 \________________________________________________________ >____________________/ "I'm so heppy I'm mizzabil!" Chris Coleman c08_d042@jhunix