[cl-typesetting-devel] Final zlib fix, and CLISP support

Marc Battyani marc.battyani at fractalconcept.com
Sat Apr 24 20:46:02 UTC 2004


"Klaus Weidner" <kw at w-m-p.com> wrote:

Hi Klaus,

> yet another attempt at fixing the annoying zlib issue...
>
> My new approach is the following:
>
> - in cl-pdf.asd, attempt to load the uffi library in an ignore-errors
>   clause. If successful, add :uffi to *features*.
>
> - conditionalize the zlib dependent code using #+uffi
>
> - if uffi is not present or zlib is not loaded successfully,
>   automatically set *compress-streams* to NIL.
>
> I have verified that this works with CMUCL and SBCL.
>
> But in addition, this change makes cl-pdf work on CLISP, and probably any
> other common lisp as well.
>
> cl-typesetting mostly works on CLISP, including my XHTML renderer. There
> are still a few portability issues in the table code to resolve that I
> haven't tracked down yet, nil values end up in max calls somehow. It's
> also complaining about floating point contagion, which may be a useful
> pointer towards potential optimizations for other platforms.
>
> BTW, I also removed the #+(or ...) from cl-typesetting.asd, which I
> haven't included in this patch. I think it is inappropriate anyway since
> that code should run on any common lisp.
>
> Marc, can you please verify if this patch breaks compatibility for
> LispWorks? If it works, I strongly suggest adding it. I assume most
> people would rather have a working system without compression rather than
> obscure error messages...

The problem here is with delivered images or executables.
By putting a compile time conditionnal (a :uffi feature) in
cl-typesetting.asd you will decide at compile time if you have or not zlib
(and where it is). This will break if you tranfert the Lisp software to
another PC and zlib is not at the same place. The way it is now is to be
completely dynamic. A (load-zlib) at run time would load it if it finds it.

Marc





More information about the cl-typesetting-devel mailing list