dillon@PAVEPAWS.BERKELEY.EDU (Matt Dillon) (06/10/86)
Description: Disk cache fails to write it's buffers Repeat-By: Only happens when you select 'save' from preferences. I've tried using a different disk (thinking the disk might be causing the trouble), but the problem still seems to occur. Fix: -- Possible_Cause: Since no other application causes this problem to happen, I would guess the problem lies somewhere in Preferences. Misc: Would appreciate being told if this happens to other 1.2BII'ers
dillon@PAVEPAWS.BERKELEY.EDU (Matt Dillon) (06/10/86)
Description: Disk Fonts don't seem to be removed. Repeat-By: Go into some program which uses disk fonts, NotePad, for instance. Use several disk fonts. When you exit NotePad, they are still around in memory. Fix: -- Possible_Cause: It is definately NOT a bug in NotePad. I wrote a program which opens and closes diskfonts, and the fonts were not removed from memory when I closed them. Misc: Question: should they be removed automagically with the last close, or do they stick around until you begin to run out of memory (a senerio I have not tested)
dillon@PAVEPAWS.BERKELEY.EDU (Matt Dillon) (06/10/86)
Description: The BII AutoDocs disk does not contain complete documentation. For example, the console device, diskfont device (and probably more). Repeat-By: looking at the disk and seeing what's there (I couldn't resist) Fix: be sure future revisions Alpha's or Beta's have complete docs Possible_Cause: Inept or rushed (deadline?) slap together of diskettes, or Amiga didn't think we needed the docs.
dillon@PAVEPAWS.BERKELEY.EDU (Matt Dillon) (06/10/86)
Description: Sizing gadget without borders, though it no longer crashes the system, still does not work properly. When you size a window larger, the old position of the sizing gadget is not always cleared. When you size a window smaller, the border area which exists due to the sizing gadget doesn't always get cleared (you had a lot of junk in the window when you sized it down). Repeat-By: Open standard intuition window: Custom screen (640x200) Custom window (640x200.. doesn't matter) with sizing gadget, close gadget, NO borders Write some junk in it (say, with the console device) Fool around resizing the window. Fix: shouldn't be too hard. Just make your window code NOT dependant on the existance of borders. Possible_Cause: programming error in resize routines. Misc:
dillon@PAVEPAWS.BERKELEY.EDU (Matt Dillon) (06/10/86)
Description: memory masher, really strange stuff. The program eventually crashes the machine. Here is a list: (1) Select the 'Copy To'... this works fine, but sometimes when your in Copy-to mode, and you use the right menu button to get the menu, garbage appears on the screen when the pointer is over some of the headers. (2) Saving fonts always seems to work, but something in FontEd seems to permanently screw the machine. After a while, when you try to load a font you've just saved (even by getting out of FontEd and re-executing FontEd and THEN reloading the font), it comes up a previous version of the font???!!? Rebooting the machine via ctl-A-A and re-executing FontEd and THEN reloading the font seems to work ok. Repeat-By: In above description. Specifically for #2: Get a font (topaz 8), resized to 7x7. cleared it, created a '!', saved it. Added stuff alltheway up to 'K', saved it. Reloaded the font (didn't work... got just the '!'). Rebooted the machine and reloaded the font (did work). Possible_Cause: Something in FontEd is mashing memory, I would guess.
dillon@PAVEPAWS.BERKELEY.EDU (Matt Dillon) (06/10/86)
Description: If you say 'Load', and while it's reading the directory in you play with some of the gadgets, it will crash the program and machine. Repeat-By: above
louie@umd5.UUCP (Louis Mamakos) (06/11/86)
In article <8606101815.AA15352@pavepaws> dillon@PAVEPAWS.BERKELEY.EDU (Matt Dillon) writes: >Description: > Disk cache fails to write it's buffers > >Repeat-By: > Only happens when you select 'save' from preferences. I've tried > using a different disk (thinking the disk might be causing the trouble), > but the problem still seems to occur. > > Would appreciate being told if this happens to other 1.2BII'ers This same thing happens to me. With a rather full disk, it sure grinds on it for a while recovering/rebuiding things. -- Louis A. Mamakos WA3YMH University of Maryland, Computer Science Center Internet: louie@trantor.umd.edu UUCP: {seismo!umcp-cs, ihnp4!rlgvax}!cvl!umd5!louie
higgin@cbmvax.UUCP (06/12/86)
In article <8606101837.AA15535@pavepaws> dillon@PAVEPAWS.BERKELEY.EDU (Matt Dillon) writes: >Description: >(2) > Saving fonts always seems to work, but something in FontEd seems > to permanently screw the machine. After a while, when you try to > load a font you've just saved (even by getting out of FontEd and > re-executing FontEd and THEN reloading the font), it comes up > a previous version of the font???!!? Rebooting the machine via > ctl-A-A and re-executing FontEd and THEN reloading the font seems > to work ok. > >Repeat-By: > In above description. Specifically for #2: > > Get a font (topaz 8), resized to 7x7. cleared it, created a '!', > saved it. Added stuff alltheway up to 'K', saved it. Reloaded > the font (didn't work... got just the '!'). Rebooted the machine > and reloaded the font (did work). > >Possible_Cause: > Something in FontEd is mashing memory, I would guess. > I seem to recall talking with the author about this, and he said if you save a font with the same name as it was loaded, you're going to get the old one, because it's still loaded into the machine. Which leads me to my next point. Yes, I believe fonts do stick around until no-one is using them and Exec needs the memory. Fix to above "bug" - save the modified font under a different name than you loaded it with. Regards, Paul Higginbottom Note: please don't shoot me, I haven't verified the above. Disclaimer: I might not know what I'm talking about, so only I'm responsible for this!
pariseau@well.UUCP (Robert S. Pariseau) (06/13/86)
This is not a bug. The memory usage model in the Amiga keeps disk-loaded items in memory until a request for free memory exceeds the size of the largest available free chunk. This eliminates unecessary reloads from the disk when an item is frequently closed and re-opened. Disk-loaded fonts will stay in memory until AllocMem() goes through its Expunge algorithm. When AllocMem() decides to Expunge, it will attempt to remove any disk-loaded font which currently has zero "openers". Note that the process of Expunging fonts was BUGGY in V1.1. It should work correctly under V1.2. Some programs use the trick of attempting to allocate a chunk of memory which is larger than can possibly be available in order to force AllocMem() to Expunge things that happen to be lying around. Note that if the Expunge processing actually removes anything, then AvailMem() will return a larger number after the fake AllocMem() call than before.
pariseau@well.UUCP (Robert S. Pariseau) (06/13/86)
Maybe if Commodore hired back some of the Los Gatos QA people...(grin!)
richr@pogo.UUCP (06/13/86)
In article <8606101821.AA15403@pavepaws> dillon@PAVEPAWS.BERKELEY.EDU (Matt Dillon) writes: >Description: > Disk Fonts don't seem to be removed. > > I have not tested) Yes, but you should have. This was discussed on the net earlier. When a resource like this is brought into RAM, it stays there unless a program asks for more RAM than is otherwise available. This makes a lot of sense. I for one want to see as little disk access as possible, even if I (** SEEM **) to have less memory than is actually available. -- Rich Rodgers tektronix!pogo!richr
mitsu@well.UUCP (06/17/86)
In re: disk fonts not being removed after a CloseFont() Disk fonts have never been removed after a CloseFont() (see Best of BIX, sometime around April or May 1986 BYTE). They are supposed to hang around in the system in case another application wants them, UNLESS a memory allocation is done, in which case the fonts are closed and cleaned out automatically if the allocation needs to use the font memory. Unfortunately, there is a bug in 1.1 that causes this procedure to fail, and it would be nice if someone tested 1.2 to determine whether this bug remains. For a description of the bug, please refer to the Best of BIX in BYTE (same issue, sorry I don't have it with me so I can't tell you the exact date---it was the first issue that carried Amiga BIX conference notes.) The bug essentially consists of AllocMem() clearing out the font, but the font not being removed from the list of fonts available in RAM, so that if another application opened that font, it would think it is still in RAM (even though it has been cleared out by AllocMem()) and the system would do something nasty and unpleasant. -Mitsu (mitsu@well.UUCP) **** I am not affiliated with C-A in any way ****