🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.sys.ibm.pc.programmer
Article #1445

Re: Editing Huge Files, and strategies therein

#1445
From: Ralf.Brown
Date: Sat, 03 Mar 1990 11:24
53 lines
3262 bytes
In article <77832@tut.cis.ohio-state.edu>, schanck@harmonica.cis.ohio-state.edu (Christopher Schanck) wrote:
}With the recent discussion on comp.sys.ibm.pc on which editors will
}handle files larger than memory, no one has discussed any of the
}strategies used by these editors.  Blackbeard's, Norton's, Sprint,
}Multimate, Brief, and others were mentioned as editors which could do
}this. 
}
}Could somebody enlighten me as to how this is accomplished in some of
}these cases, or a general strategy for doing so for an editor?  I have
}not a lot of desire to reinvent the wheel, or reinvent it
}inefficiently, so I would appreciate some info on the topic itself, or
}on where I could find such info.

From my poking around in Sprint's swap file,  I was able to determine the
following:

	  the swap file is divided into 1K pages, which may hold up to 1018
	  bytes of data (six bytes are used for "next" and "prev" pointers
	  and a count of the actual amount of data stored in the page)

	  each file is stored as a doubly-linked circular list, whose head is
	  in a special control page (which themselves are in a d-l circular
	  list whose head is the first page in the swap file)

	  any memory available above the 220K needed for the Sprint executable
	  and fixed scratch space is used as a cache for the swap file

	  insertion of new text can cause the addition of a new page containing
	  only a few bytes into the middle of the file's linked list; thus,
	  it is possible for the file to use up considerably more space in
	  the swap file than when stored as plain text.  In my experience, the
	  swap file tends to grow by 20-25% over the course of editing a file
	  (even after accounting for the file's growth).

	  deletion of text presumably only changes the page(s) on which the
	  deleted text resided, leaving unused space at the end of the page.


Unless BlackBeard has changed its strategy since v7.39, it edits files larger
than the 50K edit buffer by reading in a chunk at a time and rewriting the
entire file from that point on when you move out of the current section of
the file.  Gets rather tedious when editing the start of a large file
(particularly since BB shares the edit buffer with its internal line pointers--
editing a 25000-line file means that a "current section" is less than 1K in
size!)

--
UUCP: {ucbvax,harvard}!cs.cmu.edu!ralf -=- 412-268-3053 (school) -=- FAX: ask
ARPA: ralf@cs.cmu.edu  BIT: ralf%cs.cmu.edu@CMUCCVMA  FIDO: Ralf Brown 1:129/46
"How to Prove It" by Dana Angluin              Disclaimer? I claimed something?
16. proof by cosmology:
    The negation of the proposition is unimaginable or meaningless.  Popular
    for proofs of the existence of God.
Technical Details
Message-ID: <25efb778@ralf>
Path: arc1-ca.pugleaf.net!utzoo!censor!geac!torsqnt!jarvis.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!pt.cs.cmu.edu!b.gp.cs.cmu.edu!Ralf.Brown@B.GP.CS.CMU.EDU

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!censor!geac!torsqnt!jarvis.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!pt.cs.cmu.edu!b.gp.cs.cmu.edu!Ralf.Brown@B.GP.CS.CMU.EDU
From: Ralf.Brown@B.GP.CS.CMU.EDU
Newsgroups: comp.sys.ibm.pc.programmer
Subject: Re: Editing Huge Files, and strategies therein
Message-ID: <25efb778@ralf>
Date: 3 Mar 90 11:24:24 GMT
Sender: ralf@b.gp.cs.cmu.edu
Organization: Carnegie Mellon University School of Computer Science
Lines: 53
In-Reply-To: <77832@tut.cis.ohio-state.edu>