Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!rochester!kodak!elmgate!jdg
From: jdg@elmgate.UUCP (Jeff Gortatowsky CUST)
Newsgroups: comp.sys.atari.st
Subject: Re: LHARC source and UNIX
Keywords: No source, no like.
Message-ID: <1182@elmgate.UUCP>
Date: 24 Dec 89 04:54:39 GMT
References: <51989@ccicpg.UUCP>
Reply-To: rg@aurora.UUCP
Organization: Eastman Kodak Company, Rochester NY
Lines: 39

In article <51989@ccicpg.UUCP> paulm@ccicpg.UUCP (tmp Paul Moreau usenet acct) writes:
>Well it seems that the LHARC is going to take over the atari archiving
>world.  I for one use a UNIX system for posting and recieving news
>and binaries.   I uudecode, and unarc on the unix system and examine
>the stuff before going through the expense of going home, making a 
>LONG DISTANCE call to work and download the stuff.  If LHARC is to be
>the new standard (which I can see the benefit in smaller archives) I'd
>like to get the source so I can port it to our UNIX system.
>If the source is protected (which it seems to be) then I don't think
>I'll be downloading any more files unless I know what to expect in them.
>
>I hope that the source is available!
>I think that the majority of readers on the net here are on UNIX machines
>and would also like to get LHARC on thiers also.

Sources to LHARC on the IBM are readily available on any half-inept IBM
BBS. I have heard mention that the ST version is incompatible. If this is
the case, someone should port the PC source instead of creating confusions
between the two (the MAC has it too I think). I have glazed over the sources
on several occasions (and to be honest, the "idea" itself of
Lempel->Ziv->Huffman coding is a natural, so obvious its funny it wasnt
discovered quite some years back) and do believe it could be sped up, and
could get better compression yet (although not "drastic") by using a
run-length-encode after the huffman squeeze. Since it's just bufferin'
a byte of output bits, then writing the byte out, it'd be nothin' to buffer
"more" bits before the output, and RLE the bits. MANY storage devices
(that have any sorta brains about em') do exactly that, in hardware. Since
LHARC is already slow (due to it's iterative nature and semi-efficient trees)
whats a few seconds more?. And as I stated, I do beleive LHARC in itself can
be sped up. While using arrays for tree's is fast on access times, it is not
in insertions and deletions. I beleive a "pre-formed" dynamic tree ala'
pointers couls speed it up (and some other tiny items).


-- 
Jeff Gortatowsky-Eastman Kodak Company  .....rochester!kodak!elmgate!jdg
(use uuhosts or such to find path to rochester)
Eastman Kodak makes film not comments.  Therefore these comments are mine
not theirs.