[cl-pdf-devel] CMUCL compatibility fixes and new colorhandlingcode

[Marc Battyani]

"Klaus Weidner" <klaus at atsec.com> wrote:


> That reminds me - would there be a clean way to make zlib support a
> compile-time feature rather than a run-time selection via the global
> variable? The CMUCL build broke when loading, before it got a chance to
> look at the variable, so the only way to disable zlib support would have
> been to actually rip out the offending code (which is what I did on my
> first attempt).

Yes, it's what load-zlib is suppoed to do  :(

Have you tried an ignore-errors like this:

(defun load-zlib (&optional force)
  (when force (setf *zlib-loaded* nil))
  (unless *zlib-loaded*
    (let ((zlib-path (find-zlib-path)))
      (if zlib-path
   (ignore-errors
     (format t "~&;;; Loading ~s" zlib-path)
     (uffi:load-foreign-library zlib-path
           :module "zlib"
           :supporting-libraries '("c"))
     (uffi:def-function ("compress" c-compress)
  ((dest (* :unsigned-char))
   (destlen (* :long))
   (source :cstring)
   (source-len :long))
       :returning :int
       :module "zlib")
     (setf *zlib-loaded* t *compress-streams* t))
   (progn
     (warn "Unable to load zlib. Disabling compression.")
     (setf *compress-streams* nil))))))

> Since the package does work without compression, and getting zlib to work
> is apparently a large stumbling block for people who want to try the
> package, I'd even suggest keeping compression off by default (or
> determine at compile time if it will work), so that people who try the
> code don't run into unpleasant portability issues. Of course, those who
> use it in production are encouraged to use compression, but they are
> presumably willing to invest some time into getting it working.

It's better to find a way of gracefully remove the compression if it's not
available.

> <rant mode="on">
>
> This kind of thing is IMHO one of the really unpleasant parts of the Lisp
> experience - all too often, my attempts to run new code resulted only in
> cryptic error messages. I spent hours trying to get simple CLIM programs
> to work, and still haven't succeeded in getting gsharp and closure
> running properly. That annoys me despite being a fan of the language, and
> I hate to think what impression that makes on people who are less
> enthusiastic about it...
>
> BTW, I'm not picking specifically on CMUCL here, I've had similar
> experiences with other implementations I've tried. To paraphrase
> Spiderman, "with great power comes great fragility"?
>
> </rant>

Hum it's rather (with-rant (:mode t) ...)
;-)

IMO, it's more a problem of open source v.s. commercial software.
(documentation and support)
Have you tried to ask in the CMUCL mailing lists ?

Marc