Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!spool2.mu.edu!sol.ctr.columbia.edu!caen!news.cs.indiana.edu!know!daemon
From: C506634@UMCVMB.MISSOURI.EDU (Eric Edwards)
Newsgroups: comp.sys.amiga.datacomm
Subject: A more memory efficient compress
Message-ID: <20680@know.pws.bull.com>
Date: 27 Jan 91 05:27:57 GMT
Sender: daemon@pws.bull.com
Lines: 14
Approved: warren@pws.bull.com

Does such a beast exist?  The current version of compress (4.0) still
wants a big chunk of contiguous ram.  On my system, the largest block available
after I boot up and start a shell is 372k.  This is still not enough!

Surely if lharc and Zip can run under such conditions under the same conditions
using the same compression algorithm, compress ought to be able to.  Actually,
I wouldn't really mind if compress took 550k to run, just so long as it
doesn't have to be contiguous.

So.  Any pointers?

Eric Edwards: c506634 @    "The 3090.  Proof that by applying state of the
Inet: umcvmb.missouri.edu   art technology to an obsolete architecture,
Bitnet: umcvmb.bitnet       one can achieve mediocre performance."