Much sporadic hacking has resulted in Lisp code that will uncompress
gzip files. Compression is not done yet.
The code is vile and not fit for human consumption, but before
re-writing it, I thought I'd ask if anyone has any comments on
what the programming interface to such functionality ought to
look like.
Just (gzip-uncompress-file instream outstream)? Should there
be some stream-based interface to it? What would that look like?
How should error handling work?
-matt
From: Christopher C Stacy
Subject: Re: design suggestions for gzip in lisp
Date:
Message-ID: <x8l905wt0o8.fsf@world.std.com>
Symbolics has an implementation of this, I think.
There was a COMPRESSION-UTILITIES package, and command-line interfaces to it.
From: Christopher R. Barry
Subject: Re: design suggestions for gzip in lisp
Date:
Message-ID: <87zoyb1o0y.fsf@2xtreme.net>
Christopher C Stacy <······@world.std.com> writes:
> Symbolics has an implementation of this, I think.
> There was a COMPRESSION-UTILITIES package, and command-line
> interfaces to it.
Not gzip. Not that I know of, anyways. There is very good support for
the LZW "compress" compression method (*.Z files), but not for gzipped
files.
Christopher
* Christopher R Barry wrote:
> Not gzip. Not that I know of, anyways. There is very good support for
> the LZW "compress" compression method (*.Z files), but not for gzipped
> files.
I don't think gzip was really around until after symbolics were
more-or-less gone -- I forget when it really became common, but it
can't have been until 90 or 91, perhaps later. I have vague memories
from about that period of the FSF having a vote on whether the
extension should be .z (which it originally was, but which was already
used by pack) or .gz, perhaps at the same time as the vote on + or --
for switches.
--tim
In article <···············@lostwithiel.tfeb.org>,
Tim Bradshaw <···@tfeb.org> wrote:
>* Christopher R Barry wrote:
>
>> Not gzip. Not that I know of, anyways. There is very good support for
>> the LZW "compress" compression method (*.Z files), but not for gzipped
>> files.
>
>I don't think gzip was really around until after symbolics were
>more-or-less gone -- I forget when it really became common, but it
>can't have been until 90 or 91, perhaps later. I have vague memories
>from about that period of the FSF having a vote on whether the
>extension should be .z (which it originally was, but which was already
>used by pack) or .gz, perhaps at the same time as the vote on + or --
>for switches.
In any case, if you can get your hands on the Symbolics code, it was
presumably written in an OO fashion (probably using New Flavors, but it
shouldn't be too hard to convert it to CLOS) so adding new compression
methods shouldn't be too difficult.
--
Barry Margolin, ······@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Barry Margolin <······@bbnplanet.com> writes:
> In article <···············@lostwithiel.tfeb.org>,
> Tim Bradshaw <···@tfeb.org> wrote:
> >* Christopher R Barry wrote:
> >
> >> Not gzip. Not that I know of, anyways. There is very good support for
> >> the LZW "compress" compression method (*.Z files), but not for gzipped
> >> files.
> >
> >I don't think gzip was really around until after symbolics were
> >more-or-less gone -- I forget when it really became common, but it
> >can't have been until 90 or 91, perhaps later.
>
> In any case, if you can get your hands on the Symbolics code, it was
> presumably written in an OO fashion (probably using New Flavors, but it
> shouldn't be too hard to convert it to CLOS) so adding new compression
> methods shouldn't be too difficult.
I'd sure like to learn more about Symbolics's compression package.
If the package documentation is available in soft-copy form on the
lispm, maybe someone could mail it to me?
-matt
* R Matthew Emerson wrote:
> Just (gzip-uncompress-file instream outstream)? Should there
> be some stream-based interface to it? What would that look like?
> How should error handling work?
For Gray streams, you could make an UNCOMPRESSING-STREAM which would
be pretty cool.
--tim
Tim Bradshaw <···@tfeb.org> writes:
> * R Matthew Emerson wrote:
> > Just (gzip-uncompress-file instream outstream)? Should there
> > be some stream-based interface to it? What would that look like?
> > How should error handling work?
>
> For Gray streams, you could make an UNCOMPRESSING-STREAM which would
> be pretty cool.
I think you might need/want at least three interfaces:
1.) The simple (gzip-uncompress-file instream outstream)
2.) Gray encapsulating streams and macrology like this:
(with-uncompressing-stream (stream instream) ...)
and
(with-compressing-stream (stream outstream) ...)
3.) Something lower-level, that gives the application more control and
feed-back on what is going on, so that the user could write each
of the other two interfaces himself. This allows the user to
write all the other interfaces he might want or need, especially
for those systems that don't have gray streams.
How should error handling work? Via conditions and restarts. Or do
you have a more detailed problem in mind?
Well, just my 2 cents, anyway...
Regs, Pierre.
--
Pierre Mai <····@acm.org> PGP and GPG keys at your nearest Keyserver
"One smaller motivation which, in part, stems from altruism is Microsoft-
bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]