Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!haven!decuac!shlump.nac.dec.com!shodha.enet.dec.com!elvira!ridder From: ridder@elvira.enet.dec.com (Hans Ridder) Newsgroups: comp.sys.amiga.tech Subject: Re: Files larger than available memory. Message-ID: <1719@shodha.enet.dec.com> Date: 26 Sep 90 22:35:57 GMT References: <924@ucsvc.ucs.unimelb.edu.au> <1990Sep23.174736.16118@lavaca.uh.edu> <83986@tut.cis.ohio-state.edu> <14646@cbmvax.commodore.com> Sender: news@shodha.enet.dec.com Organization: Digital Equipment Corporation, Customer Support Center Lines: 62 In article mwm@raven.pa.dec.com (Mike (My Watch Has Windows) Meyer) writes: >I've just started poking at this, because one of the changes to mg3 >before the release is going to be ditching the linked list of lines in >favor of a buffer gap editor. Ahhh, finally! That "line too long" stuff is bogus. TECO used a buffer gap, and I *think* GNU Emacs does too. It's a great idea, the performance is quite good. >Making the editor page to disk after this is done would be simple, but >it's not clear even that's worth the trouble. But it would be nice to be able to edit large files, even when memory is low. After all, this is a multitasking machine. I'd hate to have to shut down everything just to edit a large file. >With memory mapping of some kind, doing everything in memory requires >a contiguous chunk of memory as big as the file. This is clearly >unacceptable on the Amiga, especially for an editor like mg. The >solution is a "paged" buffer, where the file buffer is a linked list >of pages, each of a fixed size (or each with a gap...hmmmm). I was thinking about this once, and I decided that I'd have one gap, which would be copied between "pages". When the gap gets too small, you just insert a new "page" in the linked list, and when the gap is as big as a page, you delete/remove it from the list. I thought that having a gap in each page would get messy rather quickly. But, maybe not. The one-buffer, one-gap you scheme can move the gap anywhere in the editing buffer in a single move (copy) operation. However, the multiple page buffer scheme requires multiple copy operations to move the gap to any point in the buffer. I think you could probably optimize this after thinking about it a bit, and reasonably large pages, say 1K to 4K (dynamic?), would help. Perhaps if you came up with a huristic as to when to compress multiple gaps into one, then it would be resonable. I just have this vision of many pages each with only a few bytes and a hugh gap. I'll stew on it. >The obvious "tmp" place is ram, which doesn't buy anything. Likewise, >paging to floppy doesn't buy much. I tend to agree with Dave - with a >1 meg nominal minimum machine, and those with hard disks probably >having more, there's not much reason to want to page to disk, and the >space/time spent on that code can probably be put to better use. I understand Dave's point, but I still think that even with a 1 meg machine, you'll still be multitasking other things. I sure like being able to keep my file(s) in the editor while I run the compiler and linker! Sure, paging to a floppy won't be as nice as a hard disk, but then that would be just another reason for a person to buy a hard disk. >Anyone have any comments? Nope, none. :-) Actually, sounds like a great idea! >