LZW

LZW

[Vicious]

Anyone can tell me where I can find LZW ada source?

Re: LZW

[Doug Haseltine]

"Vicious" <vicious@hol.fr> wrote:

>Anyone can tell me where I can find LZW ada source?
>

Sir:

We did a search a couple years ago when we had a such a need
and could not found any public source.  We ended up using
the C source code from the un*x world, and running it
through a C to Ada translator, then cleaning up the
resultant mess.  It worked fine for our purposes
(compressing some boot code into non-volatile memory, and
transferring compressed downloadable images when upgrading
embedded software), but perhaps you'll have better luck
finding a clean port.

Re: LZW

[Robert Dewar]

<<We did a search a couple years ago when we had a such a need
and could not found any public source.  We ended up using
the C source code from the un*x world, and running it
through a C to Ada translator, then cleaning up the
resultant mess.  It worked fine for our purposes
(compressing some boot code into non-volatile memory, and
transferring compressed downloadable images when upgrading
embedded software), but perhaps you'll have better luck
finding a clean port.
>>


What on earth is the point of translating the C to Ada in a case like this?
Why not simply interface to the C code.

Sounds like a lot of work that (a) achieves nothing and (b) substantially
increases the risks.

Re: LZW

[Doug Haseltine]

dewar@merv.cs.nyu.edu (Robert Dewar) wrote:

>What on earth is the point of translating the C to Ada in a case like this?
>Why not simply interface to the C code.
>
>Sounds like a lot of work that (a) achieves nothing and (b) substantially
>increases the risks.

Both very good points.  I believe those were amongst the
myriad of reasons for dropping the Ada mandate.  We,
however, had no contractual choice in the matter at the
time.

Re: LZW

[John M. Mills]

haseltine@onramp.net (Doug Haseltine) writes:
>"Vicious" <vicious@hol.fr> wrote:
>>Anyone can tell me where I can find LZW ada source?

>Sir:
>We did a search a couple years ago when we had a such a need
>and could not found any public source.
 ...
>It worked fine for our purposes
>(compressing some boot code into non-volatile memory, and
>transferring compressed downloadable images when upgrading
>embedded software), but perhaps you'll have better luck
>finding a clean port.

I would be cautious about incorporating LZW into a current development, due
to patent considerations.  The following paragraphs are excerpted from
ftp://rtfm.mit.edu/pub/usenet/comp.answers/graphics/fileformats-faq/part1:
***
...(much material elided)...
"Subject: 1. Is it now illegal to use CompuServe's GIF format?

"It is not illegal to own, transmit, or receive GIF files (provided that no
unlicensed compression and/or decompression of the files occurs). You must
realize, however, that GIF files are not the issue. The issue is, in fact,
the LZW data compression algorithm.

"In 1984, while working for Sperry Corporation, Terry Welch modified the
Lempel-Ziv 78 (LZ78) compression algorithm for greater efficiency for
implementation in high-performance disk controllers. The result was the
LZW algorithm. The world was informed of the existence of LZW by the
following journal article, published by Mr. Welch after he left the
employment of Sperry:

  Welch, T. A., "A Technique for High Performance Data Compression,"
  IEEE Computer, Volume 17, Number 6, June 1984.

"In 1985, Sperry Corporation was granted a patent (4,558,302) for the Welch
invention and implementation of the LZW data compression algorithm. Since
that time, this LZW patent has been publicly available for all to see in
the US Patent Office and many public libraries, and is available through
many on-line services."

...(balance of FAQ elided)...
***

I am sorry to contribute 'FUD' (Fear-Uncertainty-Doubt) here, but the issue
of the LWZ patent is widely mentioned.  I would _certainly_ seek legal advice
before incorporating it into any application where I was unsure of Sperry's
patent and license applicability.  I'm surprised no one else mentioned this,
and would be happy to receive more current and/or authoritative information
on the subject.  In any case, I would be cautious.

Thanks -- john mills




-- 
 John M. Mills, Senior Research Engineer   --   john.mills@gtri.gatech.edu
   Georgia Tech Research Institute, Georgia Tech, Atlanta, GA 30332-0834
        Phone contacts: 404.894.0151 (voice), 404.894.6258 (FAX)
           "Lies, Damned Lies, Statistics, and Simulations."

Re: LZW

[Vicious]

Thanx for your answer.
I've not found any clean port of LZW in ADA.
So can you send me please the result of your C to ADA translation?

Re: LZW

[Markus Kuhn]

Vicious wrote:
> I've not found any clean port of LZW in ADA.
> So can you send me please the result of your C to ADA translation?

I think, the best approach is to use an off-the-shelf
high-quality compression library in C such as the GNU zlib
available from the usual archives and call it using Ada95's
standardized C interfacing capabilities. If you are working
in a project where there is some "pure Ada" mandate that does
not even allow to reuse high-quality reusable widely-available
C components, then your bosses have something thoroughly
missunderstood about how to use Ada95 effectively in a project.

A reasonable mandate that you have to write your own new code in
Ada95 should never ban you from including existing C libraries. Note
that GNAT uses libc in the runtime library and that there exist
many useful C libraries out there (for JPEG compression,
LZW compression, bignum arithmetic, encryption, etc.) that
contain highly optimized assembler parts for quite some
architectures, etc. Given the excellent C interfacing capabilities
that Ada has, it would be a tremendous waste to reimplement these
just tohave them in Ada to fullfil some braindamaged pure-Ada
requirement.

Use Ada intelligently to get your project done quickly and do
not waste time to fulfill a silly mandatory buerocratic
doctrine by recoding existing highly optimized C code into
Ada.

It would be useful to write Ada95 wrappers for many of the
popular C libraries available from the GNU project and others.

Markus

-- 
Markus G. Kuhn, Security Group, Computer Lab, Cambridge University, UK
email: mkuhn at acm.org,  home page: <http://www.cl.cam.ac.uk/~mgk25/>

Re: LZW

[Brian Rogoff]

On Fri, 20 Feb 1998, Markus Kuhn wrote:
... snip...
> A reasonable mandate that you have to write your own new code in
> Ada95 should never ban you from including existing C libraries. Note
> that GNAT uses libc in the runtime library and that there exist
> many useful C libraries out there (for JPEG compression,
> LZW compression, bignum arithmetic, encryption, etc.) that
> contain highly optimized assembler parts for quite some
> architectures, etc. Given the excellent C interfacing capabilities
> that Ada has, it would be a tremendous waste to reimplement these
> just tohave them in Ada to fullfil some braindamaged pure-Ada
> requirement.

Well put Markus! This should probably be an FAQ. The C interfaces are IMO 
the most important new feature of Ada 95 (new as in "not in Ada 83"), and
there are now very few good reasons to recode working C into Ada. 

-- Brian

> Use Ada intelligently to get your project done quickly and do
> not waste time to fulfill a silly mandatory buerocratic
> doctrine by recoding existing highly optimized C code into
> Ada.
> 
> It would be useful to write Ada95 wrappers for many of the
> popular C libraries available from the GNU project and others.
> 
> Markus
> 
> -- 
> Markus G. Kuhn, Security Group, Computer Lab, Cambridge University, UK
> email: mkuhn at acm.org,  home page: <http://www.cl.cam.ac.uk/~mgk25/>
> 
>