Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!usc!apple!uokmax!servalan!epmooch!ben
From: ben@epmooch.UUCP (Rev. Ben A. Mesander)
Newsgroups: comp.sys.amiga.datacomm
Subject: Re: A more memory efficient compress
Message-ID: <ben.4650@epmooch.UUCP>
Date: 26 Jan 91 14:39:46 GMT
References: <20680@know.pws.bull.com>
Lines: 32

>In article <20680@know.pws.bull.com> C506634@UMCVMB.MISSOURI.EDU (Eric Edwards) writes:
>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?

I've heard the MINIX folks have made a "small" compress. I'm not sure of
its contiguous memory requirements, but it's worth looking into.

I've had another problem with compress. I run AmigaUUCP 1.06D, and when I
get a compressed tar archive, I normally unpack it with:

uncompress <ruru.tar.Z | tar xvf -

But with large archives, say bigger than 600K, this hangs. Right before it
hangs, I see some garbage graphics appear at random on my screen, implying
that a wild pointer has hit chip memory. Has anyone else seen this? If it's
less than about 1.5 megabytes, I can uncompress the file, and then untar
it in seperate steps. If it's more than 2 megs, I have to transfer it to
a unix system, unpack it, and rearchive it with zoo. I have a 2.5MB Amiga
1000.

--
| ben@epmooch.UUCP   (Ben Mesander)       | "Cash is more important than |
| ben%servalan.UUCP@uokmax.ecn.uoknor.edu |  your mother." - Al Shugart, |
| !chinet!uokmax!servalan!epmooch!ben     |  CEO, Seagate Technologies   |