Article View: comp.sys.amiga.tech
Article #5683Editing Files larger than available memory
From: Mike (My Watch Has Windows) Meye...
Date: Mon, 08 Oct 1990 20:07
Date: Mon, 08 Oct 1990 20:07
61 lines
3365 bytes
3365 bytes
In article <6708@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes:
For allocating fixed size blocks like this, I'd call AllocMem and FreeMem
myself.
Using fixed-size blocks is a major lose. You either wind up breaking
large files into small chunks, or having small files chew up large
chunks of memory. Neither is acceptable in a buffer gap editor, and
it's even less acceptable if you use a linked list of lines.
> So you have to implement your own memory allocation
> strategy, that supports giving freed memory back to the system.
Why? It's already there.
Yes - and you get to choose one of two. The portable one that may or
may not actually give blocks back to the OS, or the non-portable one.
Some choice.
> This
> is going to add confusion to the editor, and is a worse than useless
> for systems that have real VM.
#ifdef Amiga
freeblock(b) { FreeMem(b, BLOCKSIZE); }
#else
freeblock(b) { free(b); }
#endif
Simply shocking!
Yeah, I'd expect you to produce useable code samples. I also figured
you wouldn't recommend writing a memory allocation system after
pointing out that one is already in place. As previously mentioned,
you really can't use a fixed size blocks. You're also making the code
uglier, and adding more code to the set of things that must be
explicitly dealt with for a port.
Obviously, _anything_ the machine can do can be made to work, if
you're willing to make the cord sufficiently painfull to port. I've
looked at and rejected making mg hand back unused buffers always. The
only way I've found to do it is to create a special type of memory
(which you apparently want to call a "block"), and add a memory
allocation manager that can (if possible) give back the memory to the
system. That's _exactly_ what you're doing above, though you forgot
the part of the code. The code is simple, but it is more code that
needs to be debugged. It's also in the non-portable section of the
code, which means that _everyone_ who wants to port the editor has to
at least decide whether to use the "portable" version, and possibly
debug their own versions.
That's a non-trivial hit on portability for a trivial functionality.
You want the editor to give all it's memory back to the system? Hit
the close gadget; it works like a charm. If you're running the editor
resident, then your code even stays in memory.
<mike
--
Estant assis, de nuit secrette estude, Mike Meyer
Seul, repose sur la selle d'airain, mwm@relay.pa.dec.com
Flambe exigue, sortant de solitude, decwrl!mwm
Fait proferer qui n'est a croire vain.
Technical Details
Message-ID:
<MWM.90Oct8130730@raven.pa.dec.com>Path:
arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!rutgers!ucsd!pacbell.com!decwrl!bacchus.pa.dec.com!granite.pa.dec.com!mwmReferences:
<924@ucsvc.ucs.unimelb.edu.au> <MWM.90Oct2160058@raven.pa.dec.com> <6694@sugar.hackercorp.com> <MWM.90Oct5145603@raven.pa.dec.com> <6708@sugar.hackercorp.com>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!rutgers!ucsd!pacbell.com!decwrl!bacchus.pa.dec.com!granite.pa.dec.com!mwm From: mwm@raven.pa.dec.com (Mike (My Watch Has Windows) Meyer) Newsgroups: comp.sys.amiga.tech Subject: Editing Files larger than available memory Message-ID: <MWM.90Oct8130730@raven.pa.dec.com> Date: 8 Oct 90 20:07:30 GMT References: <924@ucsvc.ucs.unimelb.edu.au> <MWM.90Oct2160058@raven.pa.dec.com> <6694@sugar.hackercorp.com> <MWM.90Oct5145603@raven.pa.dec.com> <6708@sugar.hackercorp.com> Sender: news@wrl.dec.com (News) Organization: Missionaria Phonibalonica Lines: 61 In-Reply-To: peter@sugar.hackercorp.com's message of 6 Oct 90 01:46:25 GMT